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

【資料作者】：匿名

【資料日期】：2010年9月

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

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

分析進展:
1.問題在現(xiàn)場的現(xiàn)象:
最初懷疑呼建成功率的下降是由時隙不可用導致。在監(jiān)控窗口觀察到一些不可用的時隙。在研究不可用時隙的規(guī)律并分析了數(shù)據(jù)庫配置以后，發(fā)現(xiàn)這些不可用的時隙是打開ITS（FR 25262）功能以后的正常現(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相關的。我們認為ITS伴隨的所有小區(qū)的重啟是解決了問題的原因。


2. 從alarm日志可以看到， 0框24槽和18槽，1框的18槽中的GOIUB板爆出了告警：20240 Tributary Unit Alarm Indication Signal (TUAIS)。報告警時間00:20:29，清告警時間00:21:15. 這導致了基站到這些板子上傳輸?shù)闹袛�。相關基站可以看到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相關RSL上的所有時隙. 如果會的話為什么在檢測窗口沒有看到這樣的現(xiàn)象? 如果不會的話，是不是BSC仍然會在這些時隙上分assignment?
-從log里是否可以看到為什么有一些RSL不能自動回復。

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

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

建議:

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


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

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

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