【資料名稱(chēng)】：BSC6000傳輸設(shè)備故障導(dǎo)致傳輸呼建成功率下降問(wèn)題階段性分析報(bào)告

【資料作者】：匿名

【資料日期】：2010年9月

【資料語(yǔ)言】：中文

【資料格式】：DOC

【資料目錄和簡(jiǎn)介】：

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

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


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



(2)

上邊的TRX是carrier A,下邊的TRX是carrier B。 在carrier A的時(shí)隙為PDTCH的時(shí)候，在B邊對(duì)應(yīng)的時(shí)隙會(huì)被置成不可用，這是符合設(shè)計(jì)的現(xiàn)象。

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

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


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

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

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

然而從BTS的調(diào)測(cè)窗口可以看到有一些RSL不在工作狀態(tài)。并且從統(tǒng)計(jì)可以看到, 因?yàn)镽SLs不工作導(dǎo)致了56和 57號(hào)站的呼叫建立成功率下降。
26號(hào)站 小區(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號(hào)站小區(qū)56的 ARSL狀態(tài):
B-U是正常工作狀態(tài)，E-U是配置了的但是沒(méi)有在工作。.
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號(hào)站小區(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)我們認(rèn)為問(wèn)題的發(fā)生是因?yàn)?
在RSL是E-U但是時(shí)隙是INS的狀態(tài)的時(shí)候,因?yàn)镾DCCH是正常狀態(tài), 所以assignment命令會(huì)占用 DRI’s RSL是E-U的時(shí)隙. 但是因?yàn)閷?shí)際上時(shí)隙不可用，所以TCH assignment會(huì)失敗, 導(dǎo)致CSSR降低.

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

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

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

建議:

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


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

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

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