本例分享的是在RAU过程中的CC10---隐式去附着。先来看一下故障现象,MS收到了RAU Reject消息,CC为10。如下图所示:
图一 CC10隐式去附着故障现象 失败原因分析:
隐式分离(Implicitly detached)是指SGSN不发送任何消息通知MS的情况下把用户状态置为不可及。从CHR日志的失败原因看,对应“Implicitly detached”的CHR失败码包括“IMPLICITY_DETACHED”,“MM_GN_RET_MS_DETACHED”, “GN_RET_IMSI_UNKNOWN”和“PEER_SGSN_NO_RSP”。
- GN_RET_MS_DETACHED:用户在旧SGSN里已被隐式分离,但该用户还认为自己attach,到新的SGSN就发起了Inter RAU,旧SGSN上找不到用户上下文的情况下,旧SGSN认为用户已经被分离,返回SGSN CONTEXT RESPONSE消息中携带原因值为MS DETACHED,新SGSN于是返回用户隐式分离。
- GN_RET_IMSI_UNKNOWN:SGSN解析到MS之前所在OLD SGSN后,向OLD SGSN取用户上下文失败。分两种情况:
第一种情况是DNS服务器对用户Inter RAU带上来的OLD RAI解析对应SGSN的IP地址有误,这样新SGSN找到的老SGSN并非用户Inter RAU前所在的SGSN,也就无法找到用户上下文,老SGSN 向新SGSN返回的SGSN CONTEXT RESPONSE消息中携带失败原因值“IMSI NOT KNOWN”,对端SGSN没有MS的信息,所以新SGSN返回隐式分离。
第二种情况是当PURGTMR 定时器超时后(GMM上下文删除定时时长,SZ SGSN配置的是12小时),SGSN彻底删除用户的上下文信息,此时如果用户发起INTER RAU,由于就的SGSN里已经没有用户的上下文信息了,返回“RET_IMSI_UNKNOWN”的失败原因。
- PEER_SGSN_NO_RSP:新SGSN需要向老的SGSN发出SGSN上下文请求(包含原RAI、TLLI、原P-TMSI签名或IMSI、新SGSN地址),以获得该MS的MM上下文和PDP上下文。但由于新SGSN到旧SGSN的Gn接口链路原因,导致无法获取MS的上下文。
优化思路:
- 对于IMPLICITY_DETACHED”,“MM_GN_RET_MS_DETACHED”,如果因移动可及定时器超时导致的隐式分离,适当延长移动可及定时器取值。
- 对于“GN_RET_IMSI_UNKNOWN”, 分析CHR原因值失败记录,整理路由区列表如下,建议到DNS核查下列路由区是否正确配置了路由区到归属SGSNIP地址的解析数据。
- 对于“PEER_SGSN_NO_RSP”,找出发生这种错误的SGSN如下,建议检查到新SGSN到旧SGSN的链路状态是否正常。
|