跨RNC切换(重定位)信令及定时器分析.doc

跨RNC切换（重定位）信令及定时器分析1. 案例分析在分析投诉过程中，好几次遇到用户起呼在T网，可能在接通过程中发生跨RNC的切换（重定位），但遇到重定位失败导致的未接通，重定位失败原因为：trellocalloc-expiry，典型的重定位失败信令为：17:36:43143 CSGS06-9192 RANAPRelocationPreparationFailure OPC 8991 DPC 9192 Service Indicator : 3 Network Indicator : 3 Message Indicator : 0 Signaling Link Selection : 1 Message Type : Data Form 1 Destination Location Reference : 222280 Segmenting/Reassembling : No more data Spare : 0 Pointer to Data Parameter : 1 Parameter Length : 13RANAP Message Type : RelocationPreparationFailure RANAP PDU : unsuccessfulOutcome Procedure code : id-RelocationPreparation criticality : reject value protocolIEs protocolIE1 id : id-Cause criticality : ignore radioNetwork CauseRadioNetwork : trellocalloc-expiry针对此类定时器超时的重定位失败，目前还没有什么好的方法，全网的重定位失败的定时器均是统计配置的，从交换机侧取到的信令如下：17:36:33416 0 9192-CSGS06 DTAPCM Service Request17:36:33463 47 CSGS06-9192 SCCP_NGNConnection Confirm17:36:33463 47 CSGS06-9192 RANAPCommonID17:36:33463 47 CSGS06-9192 DTAPAuthentication Request17:36:33867 451 9192-CSGS06 DTAPAuthentication Response17:36:33893 477 CSGS06-9192 RANAPSecuritModeCommand17:36:34206 790 9192-CSGS06 RANAPSecurityModeComplete17:36:34486 1070 9192-CSGS06 DTAPSetup ,6625517:36:34553 1137 CSGS06-9192 DTAPCall Proceeding17:36:36333 2917 CSGS06-9192 RANAPRAB-AssignmentRequest17:36:37786 4370 9192-CSGS06 RANAPRAB-AssignmentResponse17:36:38057 4641 9192-CSGS06 RANAPRelocationRequired17:36:38057 4641 9192-CSGS06 SCCP_NGNData Form 117:36:38134 CSGS06-9193 SCCP_NGNConnection Request17:36:38176 9193-CSGS06 SCCP_NGNConnection Confirm17:36:38214 4798 CSGS06-9193 RANAPRelocationRequest17:36:38214 4798 CSGS06-9193 SCCP_NGNData Form 117:36:38214 4798 CSGS06-9193 SCCP_NGNData Form 117:36:43143 9727 CSGS06-9192 RANAPRelocationPreparationFailure17:36:43144 9728 CSGS06-9193 RANAPIu-ReleaseCommand17:36:43186 9193-CSGS06 RANAPIu-ReleaseComplete17:36:43213 9797 CSGS06-9192 SUPSNofifySS17:36:43214 9798 CSGS06-9193 SCCP_NGNReleased17:36:43246 9830 9193-CSGS06 SCCP_NGNRelease Complete17:36:50744 CSGS06-9192 DTAPConnect17:36:51057 9192-CSGS06 DTAPConnect acknowledge17:37:07048 9192-CSGS06 DTAPDisconnect17:37:07084 CSGS06-9192 DTAPRelease17:37:15085 CSGS06-9192 DTAPRelease17:37:23085 CSGS06-9192 DTAPRelease complete17:37:23085 CSGS06-9192 RANAPIu-ReleaseCommand17:37:23149 9192-CSGS06 RANAPIu-ReleaseComplete17:37:23195 CSGS06-9192 SCCP_NGNReleased17:37:23258 9192-CSGS06 SCCP_NGNRelease Complete我们可以看到，在源小区发起RelocationRequired之后，MSC已经与无线侧完成了信令交互，Connection Request和Connection Confirm就是证明，之后MSC向目标RNC下发RelocationRequest，但只见MSC下发信令，未收到RNC侧的反馈，4.929秒之后，MSC向源RNC下发RelocationPreparationFailure，可见，问题应该出在目标小区上，用户与目标小区同步出现问题导致重定位定时器超时，CN拆线导致重定位失败。2. 重定位定时器及信令对比分析既然联想到重定位定时器，我们来研究下涉及到重定位的RNC级定时器：筛选私有表中：“TIMER配置”表，目前认为可能与重定位有关的定时器如下： TIMERNAMETIMER（ms）wTRelocPrep10000wTRelocCanceling10000wTRelocIn10000wTWaitRelocCmp12000Trelocoverall28000 且全网均是统一配置，但是目前对于定时器的触发点还未明确，毕竟是私有表。 Ok，那我们结合正常信令，初步研究下正常信令下，重定位的时间（可能需要验证许多正常信令，重定位的时间应该是一个范围）。一次源小区信令：Iu_ReleaseCommand信令解码：successful_relocation重定位成功。计算此次源小区重定位时间，如果从RelocationRequired开始，Iu_ReleaseCommand结束，时间为1.62s如果从RelocationRequired开始，Iu_ReleaseComplete结束，时间为1.64s。一次目标小区信令：计算此次目标小区重定位时间，如果从RelocationRequest开始，RelocationComplete结束，时间为1.23s。结合源小区和目标小区正常重定位过程中，我们可以看到，在不完全统计的前提下，1.6+1.2=2.8s，结合我们前面看到的定时器值，Trelocoverall=2.8s，猜测在整个重定位的过程中，如果响应时间在4-5s时间的，肯定会造成定时器超时，而归根到底的原因应该为UE与目标小区同步不上，导致UE与RNC及CN侧的信令无法接续，重定位失败。前面提到的案例中也是如此，RelocationPreparationFailure之后4.8s都无响应肯定超时了。3. 总结3.1 信令总结在分析重定位的过程中，我们总是以RelocationRequire作为源小区的标示、以RelocationRequest作为目标小区的标示，可以看到，RelocationRequire在2/3G切换过程中也涉及到了，但2者还是存在区别的，在2/3G切换（重定位）过程中，在Ue上报MR之后，RelocationRequire信令解码中是带有源小区和目标小区完整信息的，包括MNC/LAC/CI等，而在3G的跨RNC重定位过程中，未带有目标小区的CI，如果要查询目标小区的CI，在跨RNC重定位信令流程中，第一可以参考：MR中的主频点和扰码，第二可以参考：RelocationCommand信令解码：图中的cell_id最好将二进制码转化为十进制，括号中的编码方式未知。重定位过程中，还要主要到的地方是，重定位采用RB重配置的方式重配传输信道，所以，信令流程中：源RNC下发radioBearerReconfiguration，而重定位完成之后，UE向目标RNC上发radioBearerReconfigurationComplete，在异常信令中，常常碰到RB重配置失败导致的定时器超时，而这些往往也是无线侧的问题。3.2 案例总结本次案例中，后来跟踪源小区的3G外部邻区，发现该源小区共配置2个3G外部邻区，且切换失败时段，跨RNC间的硬切换次数较少，失败也就1-2次