TD全网三种不同特征的位置区更新超长时延故障之分析与解决.docVIP

TD全网三种不同特征的位置区更新超长时延故障之分析与解决 （佛山分公司） 摘要：佛山公司在对4月省公司第三方TD路测文件与全网CT文件的分析中，率先发现三种不同特征的位置区更新故障：1、位置区更新12-13秒钟失败；2、位置区更新12-13秒钟成功；位置区更新8-9秒钟失败。最终通过LAU的信令流程与核心网定时器的研究，成功定位出这三种故障的原因所在。在此总结成文，以供参考。 关键词： 位置区更新； T3260； T3270； TIMSECURYTM 1 问题描述 佛山公司在对4月省公司第三方TD路测文件与全网CT文件（全网异常信令文件）的分析中，率先发现三种不同形式的位置区更新故障： （1）、位置区更新持续12-13秒钟，最终失败； （2）、位置区更新持续12-13秒钟，最终成功； （3）、位置区更新持续8-9秒钟，最终失败。 以4月21日的佛山RNC03的CT为例，统计出三种故障出现的频率： （1）、第一种故障：101次 （2）、第二种故障：27次 （3）、第三种故障：13次 注：第二种故障统计的次数可能低估，因为CT文件只记录了全网异常信令。可能存在很多12-13秒钟LAU成功，但RNC认为是正常信令并未计入CT文件的流程。 这三种故障表现的形式各不相同，但在全网来讲不是个案，而是普遍、大面积存在，并且在位置区更新持续时间方面呈现出惊人的规律性和一致性。以下是三种故障的发现过程与详细描述。 1.1 12-13秒钟位置区更新失败 佛山在对4月省公司第三方TD路测巡检log文件进行分析的时候，发现引起拉网测试的20多次未接通，都是由于被叫在做位置区更新时被寻呼所导致的。我们发现每一次的未接通事件中，被叫的位置区更新都会失败，而且耗时非常长。整个异常流程如下图所示。LAU Reject的原因是Network Failure。 图1：第一种故障表现形式 图2：第一种故障发生时的无线环境 我们发现一个有趣的规律：从UE发起LAU Request到收到网络侧下发LAU Reject，一般都是12-13秒钟左右。（请各位读者先记住这个有趣的数字，最后会作解释，为什么都是12-13秒钟） 除了路测文件的分析，我们还想到了CT文件。CT文件记录了全网所发生的异常信令，有助于我们复现已有的故障。另外，路测文件只能提供Uu口的消息和空口质量情况，对于Iu口的消息是缺失的；而且，路测文件仅仅反映了路测终端的性能，不具备代表性。 我们再抽取了4月21日佛山RNC03的CT文件分析，发现该现象的故障在全网大面积存在。我们统计该天RNC03的12-13秒钟位置区更新失败一共出现了101次。 1.2 12-13秒钟位置区更新成功 我们在分析CT文件的时候，又发现了另外一个全新的故障：12-13秒钟位置区更新成功。这种故障耗时也是12-13秒钟，与第一种故障不同的是，其位置区更新成功了，但是也是耗时12-13秒钟（请各位读者也记住这个有趣的数字，稍后会解释为什么是12-13秒钟）。 其CT文件中故障点的信令截图如下：  图3：第二种故障表现形式 我们统计4月21日佛山RNC03的CT文件，发现总共出现了27次“第二种故障”。 1.3 8-9秒钟位置区更新失败 在对CT文件的分析中，我们还发现一种十分有趣的故障现象，就是存在大量的8-9秒钟位置区更新失败现象，如下图所示： 图4：第三种故障表现形式 我们在针对4月21日佛山RNC03的CT文件的分析中，该种故障现象一共出现了13次，如下图所示： 图5：4月21佛山RNC3的第三种故障统计 2 第一种故障分析 2.1 鉴权问题 参照正确的LAU流程和CT文件分析，我们发现每当出现第一种故障（即12-13秒钟位置区更新失败）的时候，CN下发了“Authentication Request”给UE，但是UE没有上报“Authentication Response”给CN。如下图所示： 图6：CT文件分析 再结合上面的路测log文件，也可以看到，UE并没有接收到Authentication Request。而第二次成功的位置区更新则可以清楚地看到Authentication的整个过程。 图7：正常LAU流程 我们在解析CN下发给RNC和RNC透传给UE的Authentication Request消息时候，发现，两条消息中的NAS层信息不一致，如下图所示： 图8：第一种故障异常鉴权信令解析 Authentication Request是NAS层信令，RNC是应该不做任何处理直接透传给UE的，这两条消息中所包含的信息应该是一致的。而且，这两条信令显示的时间也是应该一样的。但是我们在上图看到，两条信令之间相差了113－23＝90ms，显然是发生了RNC改动NAS层消息的动作。这显然是不允许的。