INTERNAL
V200R009 C01B072
Approved by Case Symptom RAU reject on the SGSN causes a low PS inter-RAT handover success rate.
In an office, RAN equipment is provided by Huawei, and SGSNs are provided by Vendor N. The PS inter-RAT handover success rate (PS IRAT HO SR) is about 84% (90% is required in KPI acceptance). The causes for PS IRAT HO failure are timer expiry and physical channel failure, and more than 60% failures are caused by timer (RelocIuRelCmdTmr) expiry.
PS IRAT HO SR
None.
According to IOS tracing, most PS IRAT HO failures are caused by
RelocIuRelCmdTmr expiry. Therefore, we changed the timer value from 20s to 40s on September 15, and found the PS IRAT HO SR rose from about 80% to 84%. The target value 90% in KPI acceptance is not still reached. According to the DT, the typical signaling process of PS IRAT HO failure is as follows:
2013-07-0804
Huawei Confidential
Page 1 of 5
A Low PS Inter-RAT Handover Success Rate Caused by RAU Reject on the SGSN
INTERNAL
As shown in the preceding signaling process, after the RNC sends the message Cell Change Order From UTRAN, the UE camps on a GPRS cell through cell reselection and initiates LAU and RAU requests. The LAU request is accepted. The RAU request, however, is rejected, with the cause implicitly detached, as shown in the following figure.
2013-07-0804
Huawei Confidential
Page 2 of 5
A Low PS Inter-RAT Handover Success Rate Caused by RAU Reject on the SGSN
INTERNAL
As shown in the signaling process of PS IRAT HO, the data configuration and signaling process at the 3G network side are proper. When 3G signals are poor, the UE reports event 2D to start the compressed mode. The RNC then decides 2G signals and initiates IRAT HO. The UE camps on the 2G network by cell reselection. When the UE initiates an RAU request, the SGSN in the 2G network rejects the request. It indicates the cause is improper RA configuration at the SGSN in the 2G network. We tested PS IRAT HO in 12 RAs in the entire network, and found RAU Accept (PS IRAT HO succeeds) in only two RAs (RAC=199/198) and RAU Reject (PS IRAT HO fails) in other 10 RAs, as shown in the following table.
LAC
RAC
5636 5536 6036 1538 1338 1138 1738 1238 1038 5836 1438 1838
199 198 111 113 204 202 115 203 201 109 112 116
95.02% 92.02% 79.38% 89.43% 89.08% 88.55% 86.60% 86.19% 84.94% 82.74% 81.42% 73.33%
62.50% 83.53% 28.57% 35.14% 30.77% 51.67% 78.57% 50.00% 31.25% 39.69% 23.53% 17.50%
37.50% 16.47% 71.43% 64.86% 69.23% 48.33% 21.43% 50.00% 68.75% 60.31% 76.47% 82.50%
RAU Accept. RAU Accept. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached. RAU Reject due to implicitly detached.
In Nastar, we grouped cells in the entire network under RAC cells, and then measured PS IRAT HO SR by the cell group. According to the measurement result, the PS IRAT HO SRs in two RAs (RAC=199/198) are higher (95.02% and 92.02%), and those in other RAC cells range from 73.33% to 89.43%.
2013-07-0804
Huawei Confidential
Page 3 of 5
A Low PS Inter-RAT Handover Success Rate Caused by RAU Reject on the SGSN
INTERNAL
In PS IRAT HO, RAU Reject shall cause PS handover failure. Why do the PS IRAT HO SRs in 10 RAC cells still reach about 80%? According to DT and CDT tracing, even for RAU Reject in PS IRAT HO, the SGSN of Vendor N still sends IU Release Command messages to the RNC in most scenarios. The cause value contained in the IU Release Command message is Normal release. In this case, the RNC deems that PS IRAT HO succeeds. Sometimes, the SGSN does not send any message, which causes timer (RelocIuRelCmdTmr) expiry. In this case, the RNC deems that PS IRAT HO fails. We suspected RAC configuration on the SGSN of Vendor N was improper.
Handling Process
Notify Vendor N to check RAC configuration on the SGSN. The following table lists DNS configuration provided by Vendor N: LAC.RAC lac0001.rac0001 lac040C.rac00BF lac0470.rac00C0 lac06C8.rac0060 lac0790.rac005D lac1604.rac00C7 lac15A0.rac00C6 lac16CC.rac00CA lacAAAA.rac0002 lacBBBB.rac0003 DNS1 Configuration 41.196.27.5 41.196.27.5 41.196.27.6 41.196.27.5 41.196.27.5 41.196.27.6 41.196.27.37 41.196.27.38 41.196.27.6 41.196.27.6 41.196.27.6 41.196.27.6 Not existing in DNS
According to the data format in the preceding table, we converted LAC and RAC data on the RNC, and found RAC data configuration in only two RAs instead of in other 10 RAC cells. It indicates that the RAC configuration on the SGSN is improper.
LAC 5636 5536 6036 1538 1338 1138 1738 1238 1038 5836 1438 1838 RAC 199 198 111 113 204 202 115 203 201 109 112 116 LAC.RAC lac1604.rac00C7 lac15A0.rac00C6 lac1794.rac006F lac0602.rac0071 lac053A.rac00CC lac0472.rac00CA lac06CA.rac0073 lac04D6.rac00CB lac040E.rac00C9 lac16CC.rac006D lac059E.rac0070 lac072E.rac0074 Remarks This is matched in DNS list. This is matched in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list. It cannot be found in DNS list.
2013-07-0804
Huawei Confidential
Page 4 of 5
A Low PS Inter-RAT Handover Success Rate Caused by RAU Reject on the SGSN
INTERNAL
According to our feedback, the SGSN engineer of Vendor N modified DNS configuration on the SGSN at night on November, 18. On November 19, the PS IRAT HO SR rose to about 93%, compliant with the target 90% in KPI acceptance.
PS IRAT HO SR
2008-10-13
2008-10-22
2008-10-31
2008-11-15
2008-11-24
2008-9-1
2008-9-7
2008-9-10
2008-9-16
2008-9-19
2008-9-25
2008-9-28
2008-10-1
2008-10-4
2008-10-10
2008-10-16
2008-10-19
2008-10-25
2008-10-28
2008-11-3
2008-11-6
2008-11-12
2008-11-18
2008-11-21
2008-11-27
The problem is found earlier, but it takes a long time for solution. The SGSN is provided by Vendor N; so we must show enough evidence for improper data configuration on the SGSN. It takes us long to solve the problem. During problem location based on multi-vendor cooperation, it is necessary to collect enough evidence and actively promote related departments for cooperation.
Attachment Reference
2013-07-0804
Huawei Confidential
Page 5 of 5
2008-11-30
2008-9-13
2008-9-22
2008-10-7
2008-11-9