RNC间切换丢失CONNECT消息导致未接通.docVIP

RNC间切换丢失CONNECT消息导致未接通 故障现象： 在日常DT拉网测试过程中，发现跨RNC切换时，被叫上发了CONNECT消息，但是主叫一直未收到CONNECT消息，从而等待超时，造成未接通，测试采用180S（通话时长）+30S（通话间隔）的方式，专门组织人员在RNC边界进行反复测试，发现此类现象很频繁。 原因分析： 流程图： 原因排查： RNC间的切换过程采用的是重定位过程，由于目前RNC之间没实现Iur 接口，RNC之间无法直接进行通信，需通过CN 来进行转发方式进行联系，此过程比较复杂，涉及各个网元各个接口。故分别针对无线侧，RNC侧和CN侧进行分析定位。 完整跨RNC重定位信令流程如下图： 一：无线侧分析定位。经过大量测试发现UU口无线环境很好，分别抓到了跨RNC切换成功接通和未接通的UU口信令，其中UE1为主叫，UE2为被叫： 信令图（图1）：跨RNC切换成功接通 抓到的UE trace消息如下： 信令图（图2）：跨RNC切换未接通 从uu口信令截图可以看出： 被叫接通和未接通两种情况的UU口信令相同； 但是主叫有时能收到CONNECT消息，有时收不到CONNECT消息。 收不到CONNECT消息时，无线环境很好，上下行都没有干扰。据此，可以排除无线侧问题。进一步排查RNC侧情况。二：RNC侧分析定位。 根据LDT跟踪的IMSI信令情况如下： 信令图（图1）：跨RNC切换成功接通 被叫信令 主叫信令 信令图（图2）：跨RNC切换未接通 被叫信令 主叫信令 从RNC侧信令截图可以看出： 如果被叫上报CONNECT消息后，再发生跨RNC重定位请求和允许，则主叫能收到CONNECT消息，正常接通； 如果被叫上报CONNECT消息前，先发生跨RNC重定位请求和允许，则主叫不能收到CONNECT消息，导致未接通；且收到CN回复的Errorindication消息。 可见此种情况，CN处理出了问题，并未透传CONNECT消息至主叫。 由于涉及到CN侧，为了更能说明问题，进一步分析定位CN侧。 三：CN侧分析定位。现场在IUCS口挂信令仪跟踪IUCS口信令，查看RNC和CN间交互信令。由于LDT信令已经发现问题出现在被叫，故抓取被叫IUCS口信令如下： 信令图（图1）：跨RNC切换成功接通 信令图（图2）：跨RNC切换未接通 从IUCS口信令截图可以看出： 如果被叫在上报CONNECT消息之后，发起跨RNC重定位请求和允许，则主叫可以收到CONNECT消息，正常接通； 如果被叫在上报CONNECT消息之前，发起跨RNC重定位请求和允许，则CN回复Errorindication消息，主叫收不到CONNECT消息，出现未接通； 由此进一步确定问题出现在CN侧，和CN工程师沟通，其答复会尽快打补丁处理这种情况。 解决措施： CN打补丁后复测，问题解决，跨RNC切换正常接通。 CN打补丁后测试正常信令如下： 被叫信令 主叫信令 经验总结： 出现的网络问题由于涉及到多网元操作，必须分层分级，逐层逐级的进行分析，确定问题出现关键位置，快速定位，决绝问题。