TD全网“12秒位置区更新Reject故障”的分析与解决案例.doc

TD全网“12秒位置区更新Reject故障”的分析与解决案例 摘要：佛山公司在对4月省公司第三方TD路测巡检问题点的分析过程中，发现由于位置区更新被拒、时延过长导致了大量的未接通事件的问题。再结合对全网CT文件的剖析，发现这更是一个全网性的重大故障。最终通过LAU的信令流程，成功定位是中兴公司RNC的bug问题。 关键词： 位置区更新；12秒位置区更新Reject故障； T3260 1 问题描述 佛山在对4月省公司第三方TD路测巡检log文件进行分析的时候，发现引起拉网测试的20多次未接通，都是由于被叫在做位置区更新时被寻呼所导致的。 2 问题分析 2.1 路测log分析 一开始凭借经验，我们判断可能是由于是23G重选过多带来的频繁位置区更新所致。但是当我们对每一次未接通事件进行详细的分析的时候，发现情况并非当初想象的那么简单。我们发现每一次的未接通事件中，被叫的位置区更新都会失败，而且耗时非常长。整个异常流程如下图所示。LAU Reject的原因是Network Failure。 图1：12秒LAU Reject现象 图2：故障发生时的无线环境 我们发现一个有趣的规律：从UE发起LAU Request到收到网络侧下发LAU Reject，一般都是12-13秒钟左右。我们给这种故障起了个名字，叫“12秒位置区更新Reject”故障。 2.2 CT文件分析 除了路测文件的分析，我们还想到了CT文件。因为路测文件只能提供Uu口的消息和空口质量情况，对于Iu口的消息是缺失的；而且，路测文件仅仅反映了路测终端的性能，不具备代表性。 我们抽取4月某天某RNC的CT文件，发现这种“12秒位置区更新Reject”故障在全网也是大面积存在的！由于整个Reject的流程较长，在这里不做截图显示。 2.3 LAU流程分析 结合正确的LAU流程和海量的路测log、CT文件分析，我们发现每当出现这种“12秒位置区更新Reject”故障的时候，CN下发了“Authentication Request”给UE，但是UE没有上报“Authentication Response”给CN。如下图所示： 图3：CT文件分析 再结合上面的路测log文件，也可以看到，UE并没有接收到Authentication Request。而第二次成功的位置区更新则可以清楚地看到Authentication的整个过程。 图4：正常LAU流程 2.4 定位故障 我们在解析CN下发给RNC和RNC透传给UE的Authentication Request消息时候，发现，两条消息中的NAS层信息不一致，如下图所示： 图5：异常鉴权信令解析 Authentication Request是NAS层信令，RNC是应该不做任何处理直接透传给UE的，这两条消息中所包含的信息应该是一致的。而且，这两条信令显示的时间也是应该一样的。但是我们在上图看到，两条信令之间相差了113－23＝90ms，显然是发生了RNC改动NAS层消息的动作。这显然是不允许的。 在某次正常的LAU流程中，我们可以清楚看到，CN下发给RNC和RNC透传给UE的Authentication Request消息中的NAS消息是一样的，而且，两条信令显示的时间也是一模一样的，如下图所示： 图6：正常鉴权信令解析 问题很明显是出在RNC身上。我们最终定位“12秒位置区更新Reject”故障是由于RNC错误修改NAS层信令中的所包含的信息造成的。修改过后的Authentication Request即便下发给了UE，UE也会因为解码不出来而无法在层三消息中显示，也就是为什么我们在路测软件的层三消息中无法看到“Authentication Request”信令。 2.5 12秒的原因 还有一个问题：为什么从UE发起LAU Request到收到网络侧下发LAU Reject，一般都是12-13秒钟左右？我们从3GPP 24.008中找到了答案。 图7：3GPP关于T3260的解释 “The network initiates the authentication procedure by transferring an AUTHENTICATION REQUEST message across the radio interface and starts the timer T3260.” 即当CN下发了Authentication Request后，就会立即启动定时器T3260。当收不到Response超时T3260后，CN就会下发Iu Release Command和Authentication Reject。而我们在3GPP 24.008中看到，T3260=12s，与我们所发现的“12秒位置区更新Re