TD—SCDMA無(wú)線網(wǎng)絡(luò)控制器—DSP內(nèi)存異常分析

紀(jì)力+宋京

摘 要：測(cè)試發(fā)現(xiàn)呼通失敗事件分析中發(fā)現(xiàn)很多呼通失敗原因是由于主叫或被叫用戶rab指派失敗，，該現(xiàn)象沒(méi)有規(guī)律性，造成CS接通率低下。本文通過(guò)對(duì)此問(wèn)題的分析定位，總結(jié)出DSP1bit改寫故障，同時(shí)能廣泛推廣至現(xiàn)網(wǎng)類似故障排查。

關(guān)鍵詞：TDSCDMA；rab指派失?。籇SP1bit改寫

1 緒論

1.1 問(wèn)題描述

在現(xiàn)網(wǎng)運(yùn)行中，測(cè)試發(fā)現(xiàn)呼通失敗事件分析中發(fā)現(xiàn)很多呼通失敗原因是由于主叫或被叫用戶rab指派失敗，原因值為214顯示原因?yàn)閞equested circuit/channel not available，該現(xiàn)象沒(méi)有規(guī)律性，造成CS接通率低下。在網(wǎng)管上檢查所有單板狀態(tài)正常，數(shù)據(jù)配置未見(jiàn)異常，沒(méi)有異常告警產(chǎn)生

本文通過(guò)對(duì)此問(wèn)題的分析定位，總結(jié)出DSP1bit改寫故障，同時(shí)能廣泛推廣至現(xiàn)網(wǎng)類似故障排查。

1.2 主要方法和研究進(jìn)展

本論文主要使用信令跟蹤及結(jié)合DSP內(nèi)存查看等方法，針對(duì)主叫或被叫用戶rab指派失敗大量異常事件，進(jìn)行定位分析。

最終通過(guò)逐步排查給出了針對(duì)此類特點(diǎn)故障整體完整的排查思路，能夠很好的指導(dǎo)具體故障分析定位。

2 組網(wǎng)環(huán)境

IU-CS IP化組網(wǎng)與IU-PS IP化組網(wǎng)幾乎相同，但也有一些差異 ，包括：

1.在IU-PS中，RNC連接的是SGSN，在SGSN上合成了用戶面和STCP偶聯(lián)地址。而IU-CS中，RNC連接的是MGW和MSCSERVER，在MGW上分配用戶面地址，在MSCSERVER上分配STCP偶聯(lián)地址。

2. 在數(shù)據(jù)規(guī)劃上，如果該RNC IU-CS和IU-PS都采用IP組網(wǎng)，那么前面IU-PS中分配在RPU上的用戶面地址共用。網(wǎng)絡(luò)外貌和標(biāo)志字段共用。

3. 在數(shù)據(jù)配置中，IU-CS比IU-PS多了一個(gè)傳輸路徑配置，每個(gè)GIPI單板一個(gè)路徑組。

3 問(wèn)題原因分析

通過(guò)核心網(wǎng)側(cè)信令跟蹤分析故障原因

通過(guò)核心網(wǎng)側(cè)信令跟蹤分析直接原因是RNC和MGW Iu UP初始化失敗導(dǎo)致核心網(wǎng)側(cè)跟蹤RNC和MGW信令消息如下：

RNC與MGW之間的 Iu UP初始化過(guò)程間或失敗，因此導(dǎo)致現(xiàn)網(wǎng)呼叫不成功，失敗的過(guò)程中MGW發(fā)給RNC的響應(yīng)消息里指示失敗原因?yàn)镮u UP Mode version not supported。

上圖中消息方向?yàn)椤癛ECV”的消息為RNC發(fā)給MGW的初始化消息；消息方向?yàn)椤癝END”的消息為MGW返回給RNC的響應(yīng)消息。

定位過(guò)程

考慮到呼叫失敗與成功交錯(cuò)出現(xiàn)，該過(guò)程中相關(guān)網(wǎng)元RNC和MGW均未發(fā)生配置變化，因此引發(fā)MGW返回不同響應(yīng)的原因只可能有兩個(gè)方面：

- 收到的RNC輸入消息存在差異，導(dǎo)致MGW輸出不同

- RNC的輸入沒(méi)有變化，MGW內(nèi)部處理導(dǎo)致輸出不同

可以看到，成功的Iu UP初始化過(guò)程與失敗的Iu UP初始化過(guò)程其區(qū)別在于RNC發(fā)給MGW的輸入消息存在差異：

同時(shí)，可以看到，各個(gè)Iu UP初始化成功的過(guò)程，RNC發(fā)給MGW的輸入消息均相同；同樣地，各個(gè)Iu UP初始化失敗的過(guò)程，RNC發(fā)給MGW的輸入消息也相同：

綜上所述，可以得到如下結(jié)論：

當(dāng)RNC的輸入消息相同時(shí)，MGW返回相同的響應(yīng)消息

由于RNC發(fā)給MGW輸入消息不同，造成MGW對(duì)Iu UP初始化過(guò)程的不同響應(yīng)。

第4章 問(wèn)題解決方案

比較RNC輸入的不同部分（DC D6 16 V.S DE 4A C6），對(duì)照協(xié)議3GPP TS 25.415中對(duì)Iu UP初始化消息結(jié)構(gòu)的定義

可以看到，不同之處體現(xiàn)在3點(diǎn)：

- headerCRC

- payloadCRC

- TI

其中headerCRC和payloadCRC不影響對(duì)消息結(jié)構(gòu)的解析，而TI會(huì)對(duì)消息結(jié)構(gòu)的解析造成影響，如果TI指示“ipti Present”，表明在本消息中攜帶信元IPTI，MGW會(huì)根據(jù)協(xié)議對(duì)消息結(jié)構(gòu)的定義在本消息的相關(guān)處解析IPTI值；若該處指示“ipti Absent”則表明在本消息中不包含信元IPTI，MGW會(huì)略過(guò)對(duì)IPTI值的解析，把相關(guān)地方的數(shù)據(jù)解析為下一信元。

因此，在失敗的初始化過(guò)程中，RNC發(fā)給MGW的消息中TI為0，指示本消息不攜帶IPTI值。正常情況下，在該消息中不應(yīng)該攜帶IPTI值，即該消息的后半段數(shù)據(jù)應(yīng)該與指示攜帶IPTI（TI為1）的消息有所不同。但是可以看到，該消息的后半段數(shù)據(jù)與指示攜帶IPTI（TI為1）的消息一摸一樣。

這就造成MGW進(jìn)行消息解析時(shí)，把不應(yīng)攜帶的IPTI部分解析為它的下一個(gè)比鄰信元，也就是Iu UP Mode Versions supported。如下圖所示，在當(dāng)TI=1時(shí)，0x11被解析為IPTI，解析得到的其為ox00 03；當(dāng)TI=0時(shí)，IPTI為NULL， 解析得到其為0x1100，而0x1100為非法值，因此MGW返回錯(cuò)誤原因?yàn)镮u UP Mode version not supported。

綜上，問(wèn)題的根本原因是由于RNC發(fā)出的消息內(nèi)容非法，不符合25.415協(xié)議導(dǎo)致的，需要在RNC上對(duì)各RUB單板的DSP狀態(tài)進(jìn)行排查分析解決 。

RNC側(cè)分析定位為特定DSP內(nèi)存出現(xiàn)異常改寫造成IU UP初始化失敗。

Iu UP初始化失敗，IUUP同樣的配置參數(shù)，IPTI都有填寫，TI有時(shí)候有有時(shí)候沒(méi)有，察看出問(wèn)題的信令內(nèi)部媒體面IP地址固定Usr_UcpmcUp_Message.ptSUciuInstSetupResp.tUciuIpAddress.data = 7F D8 C7 D4，與特定DSP相關(guān)，懷疑該DSP代碼段改寫。

通過(guò)對(duì)疑似代碼段改寫的DSP內(nèi)存和正常DSP內(nèi)存進(jìn)行分析比較，

發(fā)現(xiàn)一個(gè)DSP（4框15槽位第10個(gè)DSP）內(nèi)存代碼有1bit改寫：

經(jīng)過(guò)分析，內(nèi)存改寫原因如下：

1、個(gè)性RUB單板硬件DSP問(wèn)題引起，存在1bit跳變，造成該DSP發(fā)生內(nèi)存改寫

2、由于內(nèi)存非法訪問(wèn)造成1bit變化

5 結(jié)論

如果存在異常通知消息，則網(wǎng)管將存在SLAVE軟校驗(yàn)的異常的通知消息顯示。其詳細(xì)信息包含異常通知的RUB單板槽位，DSP編號(hào)信息，可根據(jù)詳細(xì)信息內(nèi)容找到故障DSP。

1、 針對(duì)DSP復(fù)位操作，會(huì)引起相應(yīng)的DSP不可用告警上報(bào)，期間該DSP不會(huì)接納業(yè)務(wù)；

2、 針對(duì)閉塞故障DSP操作，網(wǎng)管不上報(bào)告警，但業(yè)務(wù)不會(huì)接納該DSP。

作者簡(jiǎn)介

紀(jì)力，男，中國(guó)普天信息產(chǎn)業(yè)北京通信規(guī)劃設(shè)計(jì)院，工程師，研究方向：TDD無(wú)線網(wǎng)絡(luò)。

宋京，男，中國(guó)普天信息產(chǎn)業(yè)北京通信規(guī)劃設(shè)計(jì)院，工程師，研究方向：TDD無(wú)線網(wǎng)絡(luò)。