【資料名稱】：BSC6000傳輸設備故障導致傳輸呼建成功率下降問題階段性分析報告

【資料作者】：匿名

【資料日期】：2010年9月

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

問題描述:
7月16日上午，客戶收到用戶投訴，并且發(fā)現(xiàn)一些小區(qū)的呼建成功率下降。懷疑問題是由于當天凌晨0:20產(chǎn)生的傳輸故障導致。然而在傳輸問題消失以后，有一些小區(qū)仍然存在呼建成功率低的問題。在CNRC值班工程師的建議下，晚上22:00時客戶關(guān)掉了ITS功能從而觸發(fā)所有基站的重啟，隨后問題消失。

分析進展:
1.問題在現(xiàn)場的現(xiàn)象:
最初懷疑呼建成功率的下降是由時隙不可用導致。在監(jiān)控窗口觀察到一些不可用的時隙。在研究不可用時隙的規(guī)律并分析了數(shù)據(jù)庫配置以后，發(fā)現(xiàn)這些不可用的時隙是打開ITS（FR 25262）功能以后的正�，F(xiàn)象。以下面的截圖26號站為例進行說明：


(1)
數(shù)據(jù)庫的配置如下圖所示：



(2)

上邊的TRX是carrier A,下邊的TRX是carrier B。 在carrier A的時隙為PDTCH的時候，在B邊對應的時隙會被置成不可用，這是符合設計的現(xiàn)象。

從圖1可以看到carrier 3的6和7時隙是OOS的狀態(tài)。carrier 3是carrier B, 對應的carrier A是TRX0. 可以看到TRX0上的6和7時隙都是PDTCH, 所以carrier3上的6和7時隙OOS是正常的. carrier 6 timeslot 6 and 7也是同樣情況, 對應的carrier 1上的6和7時隙是PDTCH. TRX 9的6和7時隙對應在carrier 2的6和7時隙 is PDTCH, 同樣的carrier 11的4時隙, 對應的carrier A，TRX10’的4時隙也是PDTCH. 所以所有的OOS時隙都是在打開ITS功能以后正常的時隙OOS.

ITS引起的OOS只會對DCR有影響，不會對呼建成功率造成影響。 BSC 不會發(fā)送assignment command 消息給這樣OOS了的時隙, 所以也不會收到assignment. I.E., 所以這個問題是不會跟ITS相關(guān)的。我們認為ITS伴隨的所有小區(qū)的重啟是解決了問題的原因。


2. 從alarm日志可以看到， 0框24槽和18槽，1框的18槽中的GOIUB板爆出了告警：20240 Tributary Unit Alarm Indication Signal (TUAIS)。報告警時間00:20:29，清告警時間00:21:15. 這導致了基站到這些板子上傳輸?shù)闹袛唷Ｏ嚓P(guān)基站可以看到LAPD OML Fault。7/16/2010 0:20出現(xiàn)， 7/16/2010 0:21消失。

所有基站的恢復時間是 00:21.
然而, 368條 RSL disconnected告警中, 只有 69條 alarms自動清除； 42 條被配置清除，是從10:30 到12:00由客戶重啟基站的操作導致。23， 6， 8號站等。257條 RSL 在19:00點鐘收集這次告警的時候仍然是disconnect的狀態(tài)。. (附件是19:00收集的告警日志)

3. 雖然從截圖的檢測窗口看到時隙狀態(tài)時正常的。（圖 (1) 所示14:57）.

然而從BTS的調(diào)測窗口可以看到有一些RSL不在工作狀態(tài)。并且從統(tǒng)計可以看到, 因為RSLs不工作導致了56和 57號站的呼叫建立成功率下降。
26號站 小區(qū)55 的ARSL狀態(tài):
B-U means busy unblocked.
ARSL 0 0 0 B-UNO REASON16/0700:20:51 None
ARSL 0 3 0 B-UNO REASON07/0703:59:50 None
ARSL 0 4 0 B-UNO REASON16/0700:20:52 None
ARSL 0 5 0 B-UNO REASON16/0700:20:52 None



26號站小區(qū)56的 ARSL狀態(tài):
B-U是正常工作狀態(tài)，E-U是配置了的但是沒有在工作。.
ARSL 1 1 0 B-UNO REASON16/0700:20:51 None
ARSL 1 6 0 B-UNO REASON07/0704:00:00 None
ARSL 1 7 0 B-UNO REASON16/0700:20:51 None
ARSL 1 8 0 E-UNO REASON16/0700:20:50 None


26號站小區(qū) 57的 ARSL 狀態(tài):
ARSL 2 2 0 B-UNO REASON07/0703:58:07 None
ARSL 2 9 0 B-UNO REASON07/0703:59:56 None
ARSL 2 10 0E-UNO REASON16/0700:20:50 None
ARSL 2 11 0E-UNO REASON16/0700:20:51 None


從上述發(fā)現(xiàn)我們認為問題的發(fā)生是因為:
在RSL是E-U但是時隙是INS的狀態(tài)的時候,因為SDCCH是正常狀態(tài), 所以assignment命令會占用 DRI’s RSL是E-U的時隙. 但是因為實際上時隙不可用，所以TCH assignment會失敗, 導致CSSR降低.

我們在華為開了ticket，在等他們對下面問題進行答復:
-BSC是知道那些RSL仍然在disconnect狀態(tài)的情況下. BSC會不會OOS相關(guān)RSL上的所有時隙. 如果會的話為什么在檢測窗口沒有看到這樣的現(xiàn)象? 如果不會的話，是不是BSC仍然會在這些時隙上分assignment?
-從log里是否可以看到為什么有一些RSL不能自動回復。

4. 從BTS測我們由已有的數(shù)據(jù)得不到更多的信息。問題已經(jīng)消失，并且沒有提供出根本原因的信息。并且在發(fā)生問題的時候很多跟CSSR相關(guān)的BIN值沒有打開。因為觸發(fā)點是不容易得到的，所以也沒有有效的DCP可以提供。

所以目前可以得到的結(jié)論是在某特定情況下，RSL從BSC看是E-U的。如果RSL是好的，則不應該出現(xiàn)現(xiàn)在的問題。目前希望從華為可以得到更多解釋。

建議:

1.重啟基站可以解決問題
客戶在白天的時候已經(jīng)重啟了部分基站，從日志來看這些基站問題已經(jīng)恢復，CSSR也已經(jīng)變好。晚上關(guān)閉ITS觸發(fā)了所有氣站的重啟，然后所有基站的問題都得到恢復。所以ITS本身的開和關(guān)跟這個事情無關(guān)，伴隨的基站的重啟是恢復問題的原因。
2.在LMT上觀測RSL告警和檢測RSL工作狀態(tài)。
RSL可以顯示哪些信令鏈路出現(xiàn)了故障，如果RSL出現(xiàn)問題，那么信令的傳輸可能會中斷，相關(guān)時隙也會OOS，進而會導致?lián)砣��?br /> 下邊查看RSL狀態(tài)的方法：


選擇所有基站并點Query鍵查看所有基站的RSL狀態(tài)。

3.打開ITS功能。
ITS功能與EDGE能力有關(guān)，如果關(guān)掉這個功能，EDGE能力就會丟失，客戶同樣會有投訴，因為下載速率會慢。像我們提到的，這次的問題跟ITS沒有關(guān)系，所以建議重新打開ITS功能。 如果客戶對此有質(zhì)疑，可以建議先打開一些基站進行觀察，觀察到?jīng)]有問題之后打開所以基站的ITS。

[ 本帖最后由 fwj129 于 2011-11-9 10:18 編輯 ]