No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

CSFB suscriber can not perform location update in other MSC in backup and recovery mode

Publication Date:  2015-09-03 Views:  85 Downloads:  0
Issue Description

When there is a fail in one MSC from the Pool, accoding to the feature of backup and recovery, if the MME can not select the MSC based on the V value it will use the default MSC/VLR to choose it. The MSC that is not faulty, should send PAGING REQUEST message to the UE to instruct it to reattach to the network. The normal flow is like this: 

1. The MSC server 3 is the backup for the MSC server 1. The HLR sends the PRN message to the MSC server 3, that was originally destinated to MSC server 1.
2. Based on the load-sharing, the MSC server 3 distribute de PRN message to the MSC server 2. The message contains the name of the MME that is serving the UE.
3. The MME determines that the SGsAP-PAGING-REQUEST message does not contain the LAI. So the MME sends a PAGING REQUEST message to instruct the UE in order to reattach to the network.
4. The MME sends the SGsAP-LOCATION-UPDATE-REQUEST message to MSC server 2 that is the one that sends te SGsAP-PAGING-REQUEST message.

The problem was that when the the subscriber was attached in the USNUIO in which was configured as example:

ADD LAIVLR: BGNLAI="740029D08", VLRNO="593996099915", DFLVLR=YES;
ADD LAIVLR: BGNLAI="740029D08", VLRNO="593996099912", DFLVLR=NO;

If the subscriber according to the V value of the IMSI hash, belong to MSCUIO that is faulty, as the line form command said that the VLR 593996099912 is no the default VLR, the subscriber was not migrated to the that VLR.

Alarm Information
There were no alarms related to this issue.
Handling Process

Analysing the traces that were taken in the USN9810, is possible to see that that the USN sends a LOCATION_UPDATE_REQ, as is possible to see in the Figure 4.

 

Figure 4 Message MM_SGSAP_LOCATION_UPDATE_REQ USN UIO.

 

 

After the Location Update Request is sent, we receive a message SGSAP_MM_ABORT_IND from the MSC, telling that the abort is because the VLR is down (Figure 5). Then, the USN sends again another Location Update Request but get again as answer the abort, so the subscriber can not attach to the EPS domain and never fallback.

 

Figure 5 Message SGSAP_MM_ABORT_IND USN UIO.

 

 

Root Cause
 HQ analyzed traces and as solution we got that is a bug for the version V900R011C01SPH327, so the procedure was to update it to the version V900R011C01SPH330.
Solution

After the upload of the patch mentioned above, in the USN were modified the bits 3 and 16 in the software parameters 16, the description below:

 

a)      SET SOFTPARAOFBIT: DT=DWORD_EX, PARANUM=6, VALUE=VALUE_1, POSITION=16;

 

According the information taken from the file HUAWEI USN9810 V900R011C01SPH330 Patch Notes.doc, the bit 16 of the software parameter 6 fixes the described below.

 

After a CSFB procedure, the UE performs a combined TAU to the LTE network. However, the USN9810 initiates an SGs interface detach procedure and thereby cannot page the UE.

 

Basic Information

Trouble Ticket No. (INTERNAL)

Customer Requirement No.: N/A

GCRMS No.: N/A

ICARE No.: 2007418

Original Ticket SN: DTS2013071901580

Source (INTERNAL)

Banco site in Costarica

 

Symptom

After a successful combined TAU procedure, the UE performs a CSFB procedure to a GSM or UMTS network. Then, the UE performs another combined TAU to the LTE network again. Because the two TAU procedures are carried in two SPP processes, the USN9810 synchronizes the subscriber's information after the second TAU procedure and deletes the information about the first TAU procedure. The USN9810 initiates an SGs interface detach procedure and thereby cannot page the UE.

 

Impact of the Defect

The USN9810 initiates an SGs interface detach procedure and cannot page the UE.

 

Solution

Bit 16 of DWORD_EX6 is used to control whether the USN9810 initiates an SGs interface detach procedure when the USN9810 synchronizes the subscriber's information in the preceding scenario.

 

Impact of Rectification

After bit 16 of DWORD_EX6 is set to 1, the values of the counters "Times of MME-sent SGsAP paging reject messages" and "Times of MME-received SGsAP paging request messages for CS call indicator" may increase.

 

b)      SET SOFTPARAOFBIT: DT=DWORD_EX, PARANUM=6, VALUE=VALUE_1, POSITION=3;

 

According the information taken from the file HUAWEI USN9810 V900R011C01SPH330 Patch Notes.doc, the bit 3 of the software parameter 6 fixes the described below.

 

When a UE in an LTE network initiates a CSFB procedure to a UMTS network, the cause value mapped by the MME does not comply with 3GPP specifications.

 

Basic Information

Trouble Ticket No. (INTERNAL)

Customer Requirement No.: N/A

GCRMS No.: N/A

ICARE No.: 1801024

Original Ticket SN: DTS2013050808829

Source (INTERNAL)

Orange site in Moldova

 

Symptom

When a UE in an LTE network initiates a CSFB procedure to a UMTS network, the MME receives a Handover Required message with the cause value of "CS Fallback Triggered" and maps the cause value to "Unspecified Failure." Then, the MME sends a Forward Relocation Request message containing the mapped cause value to the Gn/Gp SGSN. In this case, the Gn/Gp SGSN forwards a Relocation Request message with the cause value "Unspecified Failure" to the RNC. The mapping of cause values does not comply with 3GPP specifications.

 

Impact of the Defect

In the preceding scenario, the mapping of cause values does not comply with 3GPP specifications.

 

Solution

Bit 3 of DWORD_EX6 is used to control the mapped cause value contained in the GTPv1 message Forward Relocation Request sent from the MME to the Gn/Gp SGSN in the preceding scenario. When bit 3 of DWORD_EX6 is set to 1, the cause value mapped from "CS Fallback Triggered" is "Resource Optimisation Relocation."

 

Impact of Rectification

None

 

 

Also for the configuration of default VLR was moved the line that had as default VLR with flag No. For all the LACs that exist in the current network of the customer.

 

RMV LAIVLR: BGNLAI="740029D08", VLRNO="593996099912", DFLVLR=NO;

 

After the modifications described, the problem was fixed, obtaining the following traces:

 

Figure 6 Detach from EPS

 

There is a message Abort, when the MSC in which the subscriber was registered fails.

Figure 7 SGSAP MM ABORT IND

After the MSC is down, the subscribers that belong to that MSC will be migrated to the active MSCin this case the MSC GYE. The roughly time it takes for the migration is 5 seconds. If the subscriber performs a 3G service, after it is finished, the UE will send a Location Update request as in show in Figure 8.

 

Figure 8 SGSAP_LOCATION_UPDATE_REQ

 

After the message mentiones above, the MSC sends a Location Update acceptance, as show in Figure 9.

 

Figure 9 SGSAP_LOCATION_UPDATE_ACC

 

 

 

 

 

 

 

 

Figure 10 SGSAP_TMSI_REALLOC_CMP

 

Suggestions

 In the USN it is only possible to configure one default VLR for each corresponding LAC, it is very important to take into considerantion for the distribution of subscribers in case of fail of a MSC from the Pool. The mentioned distribution will depend on the weight assigned to each MSC from the pool in the CSFB solution.

Verify the version of the USN9810, before the deployment of the CSFB solution. In the patch V900R011C01SPH330, many bugs are already corrected.

END