Sunday, 14 February 2016

LTE FDD Network Planning & Optimization System-LTE system TAU reject issue analysis

One FDD-LTE network, there some TAU reject during use Apple UE test CSFB function in some eNodeB,need to check the failure and solved.The Apple UE test log as following:
-> UE releases the call in UMTS
-> moves to LTE
-> Sends TAU
-> Gets TAU Accept
-> The Next TAU is rejected with cause 10

And another TAU reject log as following:
1> Service Reject for Extended Service REQ from UE for CSFB call
PCI 408 & PCI 317
[00]  0xB0EC  LTE NAS EMM Plain OTA Incoming Message  --  Service reject Msg
pkt_version = 1 (0x1)
rel_number = 9 (0x9)
rel_version_major = 5 (0x5)
rel_version_minor = 0 (0x0)
security_header_or_skip_ind = 0 (0x0)
prot_disc = 7 (0x7) (EPS mobility management messages)
msg_type = 78 (0x4e) (Service reject)
lte_emm_msg
  emm_service_rej
    emm_cause
      cause_value = 10 (0xa) (Implicitly detached)
    T3442_incl = 0 (0x0)
    t3346_incl = 0 (0x0)
2> PCI 406 : device sent ESR went to UE and got RAU REJ 10
   GMM_ROUTING_AREA_UPDATE_REJECT
      gmm_cause
        gmm_cause_val = 10 (0xa) (Implicitly detached)
      force_stby
        force_standby_value = 0 (0x0)
      t3302_value_incl = 0 (0x0)
      t3346_value_incl = 0 (0x0)
3> [58]  0x713A  UMTS UE OTA
      Message Direction = To UE
      NAS OTA Message Contents:
chan_type = 0 (0x0)
prot_disc_check = 8 (0x8)
trans_id_or_skip_ind = 0 (0x0)
prot_disc = 8 (0x8) (GSM_GMM_MESSAGES)
msg_type = 11 (0xb)
prot
  gprs_mob_man_prot
    GMM_ROUTING_AREA_UPDATE_REJECT
      gmm_cause
        gmm_cause_val = 9 (0x9) (MS identity cannot be derived by the network)
      force_stby
        force_standby_value = 0 (0x0)
      t3302_value_incl = 0 (0x0)
      t3346_value_incl = 0 (0x0

   Analysis the UE log, we find UE releases the call in UMTS is normal, re-election to LTE, after handover is completed, send the TAU request, there was a TAU reject when receive and complete, It’s 3G CS fall back to 4G, the issue reason cause #10.
    First we need konw UE in the end after the CS fall back to LTE, then TAU update procedure, as following:
Setp20 signal explain:
The MME sends a TAU Accept (GUTI, TAI list, EPS bearer status, NAS sequence number, NAS-MAC, IMS Voice over PS session supported Indication) message to the UE. If the active flag is set the MME may provide the eNodeB with Handover Restriction List.  GUTI is included if the MME allocates a new GUTI. If the "active flag" is set in the TAU Request message the user plane setup procedure can be activated in conjunction with the TAU Accept message.
Setp21 signal explain:
If GUTI was included in the TAU Accept, the UE acknowledges the received message by returning a TAU Complete message to the MME.When the "Active flag" is not set in the TAU Request message and the Tracking Area Update was not initiated in ECM-CONNECTED state, the new MME releases the signalling connection with UE.
    According the above TAU update signaling, UE call end and move to LTE network, the normal TAU update process should be like this: UE send TAU Request to SGSN, SGSN feedback TAU Accept, after UE send NAS signaling TAU Complete, it’s meaning the TAU procedure is finish.But check the Apple UE test log, while The SGSN feedback TAU Accept, does not contain GUTI information, lead to no complete message from UE, shown as The Next TAU is rejected with cause10.
TAU normal or abnormal procedure as follow:
Check the TAU rejected reason, the reason from EMM, rejected NAS message to EMM. 

   Check the cause 10 from 3GPP.24301 by 5.5.3.2.5, the reason explain as follow:
    If the tracking area updating cannot be accepted by the network, the MME sends a TRACKING AREA UPDATE REJECT message to the UE including an appropriate EMM cause value.
    If the MME locally deactivates EPS bearer contexts for the UE (see subclause 5.5.3.2.4) and no active EPS bearer contexts remain for the UE, the MME shall send the TRACKING AREA UPDATE REJECT message including the EMM cause value #10 "Implicitly detached".
 
After TAU rejected the UE action:
#10  (Implicitly detached);
      The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED.NORMAL-SERVICE. If the rejected request was not for initiating a PDN connection for emergency bearer services, the UE shall delete any mapped EPS security context or partial native EPS security context and perform a new attach procedure.
NOTE 3:   User interaction is necessary in some cases when the UE cannot re-activate the EPS bearer(s) automatically.
         If A/Gb mode or Iu mode is supported by the UE, the UE shall handle the GMM state as specified in 3GPP TS 24.008 [13] for the case when the normal routing area updating procedure is rejected with the GMM cause with the same value.
 
According to the above explaination, the rejected cause by MME from 3G, need check MME set. Because the 3G and 4G’s MME, EPC equipment from another company, so need the custom to push the issue solved and test.
If the rejected from BS, the main reason as follow:
1.    RRC establishment failure;
2.    CN rejected;
3.    eNB can not get Initial context setup request message and time out;
4.    RRC Re-configuration lost or UE configur error security parameter or not connect the N-GBR bear.
5.    eNB set up bearing failure
6.    eNB set up the default bearing failure
 
Another Apple UE test log analysis and explain as follow:
1) UE test CSFB function, UE send Extended Service REQ, but rejected from UMTS, the cause reason is “cause_value = 10 (0xa) (Implicitly detached)”, need 3G engineer to solved;
2) Cause #10, same with above explaination;
3) Cause #9, cause from GMM, need 3G engineer to check; explain as follow:
#9   (UE identity cannot be derived by the network);
The UE shall set the EPS update status to EU2 NOT UPDATED (and shall store it according to subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and eKSI. The UE shall enter the state EMM-DEREGISTERED.
If the rejected request was not for initiating a PDN connection for emergency bearer services, the UE shall subsequently, automatically initiate the attach procedure.
NOTE 5:   User interaction is necessary in some cases when the UE cannot re-activate the EPS bearer(s) automatically.
If A/Gb mode or Iu mode is supported by the UE, the UE shall handle the GMM parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as specified in 3GPP TS 24.008 [13] for the case when the service request procedure is rejected with the GMM cause with the same value.
A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation which is already IMSI attached for non-EPS services is still IMSI attached for non-EPS services.
A UE operating in CS/PS mode 1 or CS/PS mode 2 of operation shall set the update status to U2 NOT UPDATED.
Accord the cause #9 we konwMS identity cannot be derived by the network” is usually due to failure in host resolution when handing from SGSN/MME
TAU rejected from EMM, the main reason as follow:  
Apple UE test CSFB function, we found some problem like as handover failure, attach and detached action abnormal or TAU rejected, need know the CSFB procedure is good for us to analysis and solved.



Knowledge supplement
1.    cause10-Implicitly detachedSGSN do not send any message to UE, then UE detached;
2.    GUTI,TMSI mean TINtemp identity used in next update,The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities




Budi Prasetyo

About Budi Prasetyo

All About LTE

Subscribe to this Blog via Email :

2 comments

Write comments
25 March 2017 at 22:25 delete This comment has been removed by the author.
avatar
25 March 2017 at 22:26 delete

Useful post, but difficult to understand

Reply
avatar