1、TD全網(wǎng)“12秒位置區(qū)更新Reject故障”的分析與解決案例摘要：佛山公司在對4月省公司第三方TD路測巡檢問題點(diǎn)的分析過程中，發(fā)現(xiàn)由于位置區(qū)更新被拒、時(shí)延過長導(dǎo)致了大量的未接通事件的問題。再結(jié)合對全網(wǎng)CT文件的剖析，發(fā)現(xiàn)這更是一個(gè)全網(wǎng)性的重大故障。最終通過LAU的信令流程，成功定位是中興公司RNC的bug問題。關(guān)鍵詞： 位置區(qū)更新；12秒位置區(qū)更新Reject故障； T32601 問題描述佛山在對4月省公司第三方TD路測巡檢log文件進(jìn)行分析的時(shí)候，發(fā)現(xiàn)引起拉網(wǎng)測試的20多次未接通，都是由于被叫在做位置區(qū)更新時(shí)被尋呼所導(dǎo)致的。2 問題分析2.1 路測log分析一開始憑借經(jīng)驗(yàn)，我們判斷可能是由于

2、是23G重選過多帶來的頻繁位置區(qū)更新所致。但是當(dāng)我們對每一次未接通事件進(jìn)行詳細(xì)的分析的時(shí)候，發(fā)現(xiàn)情況并非當(dāng)初想象的那么簡單。我們發(fā)現(xiàn)每一次的未接通事件中，被叫的位置區(qū)更新都會(huì)失敗，而且耗時(shí)非常長。整個(gè)異常流程如下圖所示。LAU Reject的原因是Network Failure。圖1：12秒LAU Reject現(xiàn)象 圖2：故障發(fā)生時(shí)的無線環(huán)境我們發(fā)現(xiàn)一個(gè)有趣的規(guī)律：從UE發(fā)起LAU Request到收到網(wǎng)絡(luò)側(cè)下發(fā)LAU Reject，一般都是12-13秒鐘左右。我們給這種故障起了個(gè)名字，叫“12秒位置區(qū)更新Reject”故障。2.2 CT文件分析除了路測文件的分析，我們還想到了CT文件。因?yàn)槁?/p>

3、測文件只能提供Uu口的消息和空口質(zhì)量情況，對于Iu口的消息是缺失的；而且，路測文件僅僅反映了路測終端的性能，不具備代表性。我們抽取4月某天某RNC的CT文件，發(fā)現(xiàn)這種“12秒位置區(qū)更新Reject”故障在全網(wǎng)也是大面積存在的！由于整個(gè)Reject的流程較長，在這里不做截圖顯示。2.3 LAU流程分析結(jié)合正確的LAU流程和海量的路測log、CT文件分析，我們發(fā)現(xiàn)每當(dāng)出現(xiàn)這種“12秒位置區(qū)更新Reject”故障的時(shí)候，CN下發(fā)了“Authentication Request”給UE，但是UE沒有上報(bào)“Authentication Response”給CN。如下圖所示：圖3：CT文件分析再結(jié)合上面的

4、路測log文件，也可以看到，UE并沒有接收到Authentication Request。而第二次成功的位置區(qū)更新則可以清楚地看到Authentication的整個(gè)過程。圖4：正常LAU流程2.4 定位故障 我們在解析CN下發(fā)給RNC和RNC透傳給UE的Authentication Request消息時(shí)候，發(fā)現(xiàn)，兩條消息中的NAS層信息不一致，如下圖所示：圖5：異常鑒權(quán)信令解析Authentication Request是NAS層信令，RNC是應(yīng)該不做任何處理直接透傳給UE的，這兩條消息中所包含的信息應(yīng)該是一致的。而且，這兩條信令顯示的時(shí)間也是應(yīng)該一樣的。但是我們在上圖看到，兩條信令之間相差了

5、1132390ms，顯然是發(fā)生了RNC改動(dòng)NAS層消息的動(dòng)作。這顯然是不允許的。在某次正常的LAU流程中，我們可以清楚看到，CN下發(fā)給RNC和RNC透傳給UE的Authentication Request消息中的NAS消息是一樣的，而且，兩條信令顯示的時(shí)間也是一模一樣的，如下圖所示：圖6：正常鑒權(quán)信令解析問題很明顯是出在RNC身上。我們最終定位“12秒位置區(qū)更新Reject”故障是由于RNC錯(cuò)誤修改NAS層信令中的所包含的信息造成的。修改過后的Authentication Request即便下發(fā)給了UE，UE也會(huì)因?yàn)榻獯a不出來而無法在層三消息中顯示，也就是為什么我們在路測軟件的層三消息中無法看

6、到“Authentication Request”信令。2.5 12秒的原因 還有一個(gè)問題：為什么從UE發(fā)起LAU Request到收到網(wǎng)絡(luò)側(cè)下發(fā)LAU Reject，一般都是12-13秒鐘左右？我們從3GPP 24.008中找到了答案。圖7：3GPP關(guān)于T3260的解釋“The network initiates the authentication procedure by transferring an AUTHENTICATION REQUEST message across the radio interface and starts the timer T3260.”即當(dāng)CN下發(fā)了Authentication Request后，就會(huì)立即啟動(dòng)定時(shí)器T3260。當(dāng)收不到Response超時(shí)T3260后，CN就會(huì)下發(fā)Iu Release Command和Authentication Reject。而我們在3GPP 24.008中看到，T3260=12s，與我們所發(fā)現(xiàn)的“12秒位置區(qū)更新Reject故障”中的12-13秒鐘的時(shí)延剛好吻合。3 問題解決當(dāng)我們將該故障的詳細(xì)分析反饋給中興公司后，確認(rèn)這是中興RNC的一個(gè)bug問題。中興承諾將盡快對所有的RNC進(jìn)行打補(bǔ)丁升級，以消除該類故障。4 總結(jié)“12秒位置區(qū)更新Reject”故障對巡檢路測接通率和用戶感知均產(chǎn)生了重大的