Wednesday, 28 October 2015

LAC out of range causes Inter-RAT TAU procedure to fail when subscriber moves from 3G to 4G

Problem Description
A subscriber roaming from 3G to 4G performs a Inter-RAT TAU procedure. This procedure is rejected by USN9810 working as an MME.
The reject cause is "implicitly-detached". After this, the UE requests an Attach procedure, which is successful.
The user experience is affected because there is a long delay when roaming from 3G to 4G.
Also, CSFB services cannot be delivered to the UE while roaming between technologies, which affects network performance and user satisfaction.
USN9810 version is V900R011C02SPC200. SGSN and RNC belongs to NSN.
There are no alarms reported on the USN9810 or any other network elements in the LTE network.
Handling Process
A User trace and a S1-MME interface trace were performed on USN9810. From the User trace,
it was found that the TAU procedure did not appear on the trace. On the S1-MME interface trace, we could see the Inter-RAT TAU procedure. The image below shows the signaling related.

From the trace, we found the mapped MME Group ID containing the LAC the subscriber was registered to on 3G. The LAC value is 0xA056.
This value conflicts with the current USN9810 SGSN/MME selection policy, which states that, according to 3GPP TS 23.003 in section 2.8.2.2.2, the LAC most significant bit should not be 1.

The LAC value 0xA056 converts to binary format into 1010  0000  0101  0110. The most significant bit (the bit most at the left) on this LAC is 1,
which conflicts with the SGSN selection policy configured on USN9810 by default. Because of this, USN9810 considers this mapped GUTI value as an identifier for another MME,
instead of a LAC. Then, USN9810 performs a DNS query trying to find the MME with MME Group ID 0xA056,
the query fails and the USN9810 sends an TAU reject with cause "implicitly-detached". Then the UE has to Attach again to the 4G network.
The affectation to the service is restricted to those TACs whose corresponding LAC follows the same format described above.
Root Cause
N/A
Solution
By running the command LST PESELPLCY, we can display the configured SGSN/MME selection policy.
+++    USN/*MEID:8*/        2013-07-22 22:22:05-05:00 DST
O&M    #48
%%LST PESELPLCY:;%%
RETCODE = 0  Operation succeeded The result is as follows:
-------------------------
  Peer Identifier Mode  =  Mask Mode
              Bit Mask  =  0x8000
          MME Group ID  =  0x0
    MME Group ID Range  =  0x0
Use RNC ID Domain Name  =  YES
(Number of results = 1)
---    END
By using the mask mode, USN9810 complies with 3GPP TS 23.003 section 2.8.2.2.2, where the rule for LAC definition is stated as:
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>.
After the analysis, two solutions were presented to customer for their consideration.
The first solution is to change the LAC value in order to comply with 3GPP TS 23.003 rule definition.
This solution has impact to the 3G network because it requires all network elements to modify the LAC values consistently.
The second solution is to modify the USN9810 SGSN/MME selection policy,
by running the command SET PESELPLCY and modifying the selection policy to SECTION MODE or ROLLBACK MODE.
After the modification, the SGSN/MME selection policy was configured as follows.
%%LST PESELPLCY:;%%
RETCODE = 0  Operation succeeded
The result is as follows:
-------------------------
  Peer Identifier Mode  =  Section Mode
              Bit Mask  =  0x0
          MME Group ID  =  0x8081
    MME Group ID Range  =  0x8081
Use RNC ID Domain Name  =  YES
(Number of results = 1)
---    END
The service was validated after the configuration change and the TAU procedure can be seen on the USN9810 User Trace. Below are the traces captured.





After the modification, the USN9810 performs a DNS query to find the SGSN serving the LAC A056 and the TAU can be successful.
Suggestions and Summary
During the design phase, it is important to remind customer of this rule in order to avoid the definition of new LACs that do not follow the 3GPP rule and may affect reselection procedures when a subscriber is roaming between technologies.

Budi Prasetyo

About Budi Prasetyo

All About LTE

Subscribe to this Blog via Email :