|
2009年10月9日，某局在进行第三方测试时，存在FTP业务在多处掉线的情况，似乎和无线侧无关，问题出在核心网。 因为是第三方测试，而且问题可复现，所以对该用户进行用户跟踪。 分析GGSN的用户消息跟踪，在16:15:15收到SGSN发送过来的Delete PDP Context Request消息。 GGSN收到SGSN发送过来的Delete PDP Context Request消息,按照标准协议规定进行相关的动作。从现象看，只可能是两个原因： 第一，用户主动下线，去激活上下文； 第二，SGSN因为一些异常，主动去激活用户。 总之和GGSN没有关系。排除第一种情况，似乎问题出在SGSN上？ 分析SGSN的用户消息跟踪。在16:15:16收到GGSN的error indication消息，随后在16:15:16马上给MS发送去活用户的消息。 根据3GPP的23060规定，SGSN收到GGSN发来的error indication消息，应给MS和GGSN发送去活消息。SGSN感觉自己很冤！ GGSN一般在在处理GTP-U消息找不到对应上下文时，给SGSN发送error indication消息。注意到在16:15:16 SGSN给GGSN发了一个上行报文后，就收到了错误标识消息，莫非这个报文的GTP的TEID在GGSN上已经没有了？难道真是GGSN的问题？ 详细查看下这个上行包，发现UTP-U的TEID是0x7023e34。 如下图。 GGSN在16:15:16 刚刚删除掉一个PDP，通过查询发现被删除的上下文是0x16c4f0e8（TEID-C），那么这个TEID-C和上面的TEID-U是否是同一个PDP呢？ 注意到删除之前有个更新PDP消息（消息序号46和47），可以通过更新消息查看两者之间的关系。 分析第47行的Update PDP Context Response消息，可以看到上下文更新后的TEID-U是0x7023e34，分析第46行的Update PDP Context Request消息，可以看到对应的TEID-C是0x16c4f0e8。也就是说0x7023e34（TEID-U和0x16c4f0e8（TEID-C）对应的是同一个用户的上下文。也就是说，从GGSN的角度看，在上下文更新后，这个上下文马上被去激活了。到底是谁给GGSN发了删除PDP的消息？用户跟踪中式无法看到三层IP地址。 问题到这就已经清楚了。用户在发生业务期间，从SGSN1切换到SGSN2，在更新完GGSN上的上下文后，SGSN1又主动将GGSN上的用户上下文删除了，导致SGSN2发送业务报文给GGSN时，GGSN找不到对应的上下文，而给SGSN2回error indication消息。那么SGSN1为什么会主动去激活GGSN上的上下文呢？会不会是GGSN和SGSN1的某些消息交互存在问题导致的呢？ 继续分析SGSN1的相关报文，我们发现：新侧SGSN回SGSN CONTEXT ACK较慢，花了20S，原因是新侧SGSN给UE发鉴权请求UE多次才回响应，浪费20S（14：55－15：05）。导致旧侧SGSN收到CANCEL location消息也是20S以后，而SGSN侧的切换T3定时器默认只有10S，于是在CANCEL LOCATION前已经导致T3超时，后续在IDLE态下就出现了往GGSN删除用户的处理（T3未超时时仅在旧侧SGSN内部删除用户。）SGSN2的相关报文：从16:14:55（消息序号3012）开始进行切换，并且在16:14:55（3015行）开始给终端进行鉴权处理。 但是终端没有响应。于是SGSN2连续发起多次鉴权（消息序号3041、3044和3049），一直到16:15:15（消息序号3051），终端才响应鉴权请求。 本案例中完整的故障信令过程如下图： GGSN一般是在处理GTP-U消息找不到对应上下文时，给SGSN发送error indication消息。 - 找到导致用户被去活的第一现场。比如本例中，是SGSN2收到error indication消息后，才真正去激活终端用户。而GGSN用户消息跟踪里观察到的去活上下文的消息，是SGSN1发送的，此时并没有真正去激活终端用户。 - 尽量在GGSN和SGSN上同时跟踪用户的整个信令流程，或者在Gn口捉包。因为某些关键的异常消息在GGSN的用户消息跟踪中无法跟到。建议在GGSN和SGSN上同时建立用户消息跟踪。 - 根据用户被去活的第一现场和用户完成的信令跟踪，逐步反推导致用户被去活的根因。 | 
窥视卡
雷达卡
发表于 2012-10-16 16:41:42
一键分享
收藏
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2012-12-1 20:21:57
发表于 2013-10-17 15:09:23