PDA

View Full Version : TAU Failure



mounir34
2017-08-29, 12:04 AM
dear
please any suggestion to solve the TAU reject from Umts to LTE after Call.


thanks
BR

plannerguy
2017-09-07, 06:25 PM
Hi

Pls check the TAU Request message value of OLD GUTI.

Rgds
Plannerguy

mounir34
2017-09-07, 06:48 PM
check below snap

40843



Hi

Pls check the TAU Request message value of OLD GUTI.

Rgds
Plannerguy

samuraial
2017-09-08, 06:04 PM
Basically you need to check this:

3GPP TS 23.003 version 14.3.0 Release 14 21 ETSI TS 123 003 V14.3.0 (2017-05)
2.8.2.2.2 Mapping in the UE
When the UE moves from the GERAN/UTRAN to the E-UTRAN, the UE needs to map the RAI and P-TMSI to a
GUTI to be sent to the MME. The P-TMSI signature is sent intact to the MME.
The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN shall be performed as follows:
GERAN/UTRAN <MCC> maps to E-UTRAN <MCC>
GERAN/UTRAN <MNC> maps to E-UTRAN <MNC>
GERAN/UTRAN <LAC> maps to E-UTRAN <MME Group ID>
GERAN/UTRAN <RAC> maps into bit 23 and down to bit 16 of the M-TMSI
The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.
GERAN/UTRAN <P-TMSI> maps as follows:
- 6 bits of the GERAN/UTRAN <P-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and
down to bit 24 of the E-UTRAN <M-TMSI>;
- 16 bits of the GERAN/UTRAN <P-TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and
down to bit 0 of the E-UTRAN <M-TMSI>.
The values of <LAC> and <MME group id> shall be disjoint, so that they can be differentiated.
The most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set
to one. Based on this definition, the most significant bit of the <MME group id> can be used to distinguish the node
type, i.e. whether it is an MME or SGSN. The UE copies the received old SGSN’s <LAC> into the <MME Group ID>
when sending a message to an MME, regardless of the value of the most significant bit of the <LAC>.


Also this one is an important part of your investigation:

In networks where this definition is not applied (e.g. in networks already configured with LAC with the most significant
bit set to 1 before LTE deployment), the information in the TAU/RAU request indicating whether the provided
GUTI/P-TMSI is "native" (i.e. no system change) or "mapped" (i.e. system change) can be used to distinguish the node
type for UEs implemented according to this release of the specification (see 3GPP TS 24.301 [90] and 3GPP TS 24.008
[5]). Specific network implementations still satisfying 3GPP standard interfaces can be used for pre-Rel-10 UEs to
distinguish the node type.
NOTE 1: As an example, at NAS level, the MME/SGSN can retrieve the old SGSN/MME by using additional
GUTI/additional RAI/P-TMSI with double DNS query to solve the first time the UE moves between EUTRAN
and GERAN/UTRAN. As another example, the MME/SGSN can retrieve the old SGSN/MME
by using double DNS query.

If you are ok till here check billing strategy.

B/R

mounir34
2017-09-08, 08:00 PM
thanks dear for your support

Basically you need to check this:

3GPP TS 23.003 version 14.3.0 Release 14 21 ETSI TS 123 003 V14.3.0 (2017-05)
2.8.2.2.2 Mapping in the UE
When the UE moves from the GERAN/UTRAN to the E-UTRAN, the UE needs to map the RAI and P-TMSI to a
GUTI to be sent to the MME. The P-TMSI signature is sent intact to the MME.
The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN shall be performed as follows:
GERAN/UTRAN <MCC> maps to E-UTRAN <MCC>
GERAN/UTRAN <MNC> maps to E-UTRAN <MNC>
GERAN/UTRAN <LAC> maps to E-UTRAN <MME Group ID>
GERAN/UTRAN <RAC> maps into bit 23 and down to bit 16 of the M-TMSI
The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code.
GERAN/UTRAN <P-TMSI> maps as follows:
- 6 bits of the GERAN/UTRAN <P-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and
down to bit 24 of the E-UTRAN <M-TMSI>;
- 16 bits of the GERAN/UTRAN <P-TMSI> starting at bit 15 and down to bit 0 are mapped into bit 15 and
down to bit 0 of the E-UTRAN <M-TMSI>.
The values of <LAC> and <MME group id> shall be disjoint, so that they can be differentiated.
The most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set
to one. Based on this definition, the most significant bit of the <MME group id> can be used to distinguish the node
type, i.e. whether it is an MME or SGSN. The UE copies the received old SGSN’s <LAC> into the <MME Group ID>
when sending a message to an MME, regardless of the value of the most significant bit of the <LAC>.


Also this one is an important part of your investigation:

In networks where this definition is not applied (e.g. in networks already configured with LAC with the most significant
bit set to 1 before LTE deployment), the information in the TAU/RAU request indicating whether the provided
GUTI/P-TMSI is "native" (i.e. no system change) or "mapped" (i.e. system change) can be used to distinguish the node
type for UEs implemented according to this release of the specification (see 3GPP TS 24.301 [90] and 3GPP TS 24.008
[5]). Specific network implementations still satisfying 3GPP standard interfaces can be used for pre-Rel-10 UEs to
distinguish the node type.
NOTE 1: As an example, at NAS level, the MME/SGSN can retrieve the old SGSN/MME by using additional
GUTI/additional RAI/P-TMSI with double DNS query to solve the first time the UE moves between EUTRAN
and GERAN/UTRAN. As another example, the MME/SGSN can retrieve the old SGSN/MME
by using double DNS query.

If you are ok till here check billing strategy.

B/R