现象描述:
国内某省客户在进行测试的时候发现2、3G 切换成功率很低只有60% ,无线侧反馈是收到核心网SGSN下发的RAU reject消息(原因值为:Implicit detach),但是从SGSN上的用户跟踪没有下发RAU reject 消息,整个测试范围包括intra SGSN和inter SGSN(SGSN06 2、3G融合局;SGSN16 2G局)。
场景如下图一所示:
告警信息:
无
原因分析:
可能原因:
1、DNS 切换数据配置错误导致。
2、SGSN之间GTPC隧道问题导致。
3、SGSN与RNC QOS 协商问题导致。
4、无线侧原因导致。
处理过程:
1、分析SGSN06的用户跟踪消息发现,所有的SGSN间切换均是SGSN06至SGSN16的3G到2G的切换,没有SGSN06到SGSN16的RAU消息和RAU reject 消息,而且每次终端回到SGSN06时都是通过重新附着到SGSN06,SGSN06内的2、3G切换均成功。
2、分析SGSN16的用户跟踪消息发现,SGSN06至SGSN16的3G to 2G的切换都是成功的(见图2);SGSN06内的2、3切换也是成功的(见图3)。
图二 SGSN06至SGSN16的3G to 2G的切换都是成功的 图三 SGSN06内的2、3切换也是成功的
3、根据无线侧反馈的信息为SGSN16向SGSN06切换时收到核心网的RAU reject消息,原因值为:Implicit detach (见图4)。
图四 SGSN16向SGSN06切换时收到核心网的RAU reject消息
4、根据RAU拒绝原因推测,只有在SGSN间的GTPC路径中断或目标SGSN无法获取此用户的MM 上下问题时SGSN才回复Implicit detach原因值。
5、分析SGSN16 和 SGSN06 的配置信息,发现同一个“LAC 8007 RAC 01” 在两个SGSN上都存在。
a、根据路由区更新流程,手机在从SGSN16 2G网络漫游到SGSN06 3G网络覆盖区域时,RAN将向SGSN06发起Routing area update 流程,携带老的RAI(46000800701)和PTMSI 签名等信息,SGSN06 收到请求后查询2G paging 表,由于SGSN06 配置中有 RAI (46000800701),这样判断为SGSN 内切换,然后查询此用户的MM文件,因为SGSN06根本就没有此用户的MM上下文(此时用户的MM在SGSN16上),这样SGSN06无法获取用户的MM上下文就会给MS下发RAU REJECT 消息原因值为:Implicit detach,另外,由于SGSN06没有此用户的MM 上下文,这样在SGSN06上的IMSI用户跟踪跟不到 Routing area update request 和 RAU REJECT 消息的(SGSN需要通过P-TMSI 查找MM 上下文对应IMSI来进行消息解析),只有通过接口跟踪才能看作到此消息。由于此用户在SGSN06 RAU 失败了,所以只能重新发起ATTACH 流程和激活流程完成业务(见图5)。
图五 用户遭拒绝后重新发起附着和激活流程
b、 根据路由区更新流程,手机在从SGSN16 2G网络下漫游到SGSN06 2G网络覆盖区域时,由于OLD RAI 和 NEW RAI 是相同,所以终端是不会发起Routing area update 流程,这样业务会中断重新进行附着、激活流程。
6、由于无线侧错误将同一个RAI规划在两个SGSN下导致了2、3切换的失败,建议无线侧重新规划RAI或将同一个RAI的BSC割入同一个SGSN下解决此问题。
|