TD—SCDMA無線網絡控制器—DSP內存異常分析

紀力+宋京

摘 要：測試發現呼通失敗事件分析中發現很多呼通失敗原因是由于主叫或被叫用戶rab指派失敗，，該現象沒有規律性，造成CS接通率低下。本文通過對此問題的分析定位，總結出DSP1bit改寫故障，同時能廣泛推廣至現網類似故障排查。

關鍵詞：TDSCDMA；rab指派失??；DSP1bit改寫

1 緒論

1.1 問題描述

在現網運行中，測試發現呼通失敗事件分析中發現很多呼通失敗原因是由于主叫或被叫用戶rab指派失敗，原因值為214顯示原因為requested circuit/channel not available，該現象沒有規律性，造成CS接通率低下。在網管上檢查所有單板狀態正常，數據配置未見異常，沒有異常告警產生

本文通過對此問題的分析定位，總結出DSP1bit改寫故障，同時能廣泛推廣至現網類似故障排查。

1.2 主要方法和研究進展

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

最終通過逐步排查給出了針對此類特點故障整體完整的排查思路，能夠很好的指導具體故障分析定位。

2 組網環境

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

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

2. 在數據規劃上，如果該RNC IU-CS和IU-PS都采用IP組網，那么前面IU-PS中分配在RPU上的用戶面地址共用。網絡外貌和標志字段共用。

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

3 問題原因分析

通過核心網側信令跟蹤分析故障原因

通過核心網側信令跟蹤分析直接原因是RNC和MGW Iu UP初始化失敗導致核心網側跟蹤RNC和MGW信令消息如下：

RNC與MGW之間的 Iu UP初始化過程間或失敗，因此導致現網呼叫不成功，失敗的過程中MGW發給RNC的響應消息里指示失敗原因為Iu UP Mode version not supported。

上圖中消息方向為“RECV”的消息為RNC發給MGW的初始化消息；消息方向為“SEND”的消息為MGW返回給RNC的響應消息。

定位過程

考慮到呼叫失敗與成功交錯出現，該過程中相關網元RNC和MGW均未發生配置變化，因此引發MGW返回不同響應的原因只可能有兩個方面：

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

- RNC的輸入沒有變化，MGW內部處理導致輸出不同

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

同時，可以看到，各個Iu UP初始化成功的過程，RNC發給MGW的輸入消息均相同；同樣地，各個Iu UP初始化失敗的過程，RNC發給MGW的輸入消息也相同：

綜上所述，可以得到如下結論：

當RNC的輸入消息相同時，MGW返回相同的響應消息

由于RNC發給MGW輸入消息不同，造成MGW對Iu UP初始化過程的不同響應。

第4章 問題解決方案

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

可以看到，不同之處體現在3點：

- headerCRC

- payloadCRC

- TI

其中headerCRC和payloadCRC不影響對消息結構的解析，而TI會對消息結構的解析造成影響，如果TI指示“ipti Present”，表明在本消息中攜帶信元IPTI，MGW會根據協議對消息結構的定義在本消息的相關處解析IPTI值；若該處指示“ipti Absent”則表明在本消息中不包含信元IPTI，MGW會略過對IPTI值的解析，把相關地方的數據解析為下一信元。

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

這就造成MGW進行消息解析時，把不應攜帶的IPTI部分解析為它的下一個比鄰信元，也就是Iu UP Mode Versions supported。如下圖所示，在當TI=1時，0x11被解析為IPTI，解析得到的其為ox00 03；當TI=0時，IPTI為NULL， 解析得到其為0x1100，而0x1100為非法值，因此MGW返回錯誤原因為Iu UP Mode version not supported。

綜上，問題的根本原因是由于RNC發出的消息內容非法，不符合25.415協議導致的，需要在RNC上對各RUB單板的DSP狀態進行排查分析解決 。

RNC側分析定位為特定DSP內存出現異常改寫造成IU UP初始化失敗。

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

通過對疑似代碼段改寫的DSP內存和正常DSP內存進行分析比較，

發現一個DSP（4框15槽位第10個DSP）內存代碼有1bit改寫：

經過分析，內存改寫原因如下：

1、個性RUB單板硬件DSP問題引起，存在1bit跳變，造成該DSP發生內存改寫

2、由于內存非法訪問造成1bit變化

5 結論

如果存在異常通知消息，則網管將存在SLAVE軟校驗的異常的通知消息顯示。其詳細信息包含異常通知的RUB單板槽位，DSP編號信息，可根據詳細信息內容找到故障DSP。

1、 針對DSP復位操作，會引起相應的DSP不可用告警上報，期間該DSP不會接納業務；

2、 針對閉塞故障DSP操作，網管不上報告警，但業務不會接納該DSP。

作者簡介

紀力，男，中國普天信息產業北京通信規劃設計院，工程師，研究方向：TDD無線網絡。

宋京，男，中國普天信息產業北京通信規劃設計院，工程師，研究方向：TDD無線網絡。