【摘要】本文主要針對當前軟交換網絡下出現單通現象的排查方式進行了一個簡單的概述,主要是通過追蹤單通通話,找出設備占用的共性,我們通過對MSC-S、MGW、BSC進行一系列的實時追蹤,發現單通通話都集中在愛立信MGW的某一塊MSB板上,而后我們對MGW進行一系列的深度檢查,包括ET板、MSB板、SCB\SXB板\ISL連線進行程序檢查,發現某一塊MSB板出現問題,而這一塊MSB板出現問題并未通過告警來呈現,因此,我們最后給出了愛立信MGW隱性故障導致單通后續的解決方案。
【關鍵詞】單通MGW定位MSB
一、概述
近日陸續接到投訴反映在南海桂城通話有單通的情況出現。單通跟掉話、電話無法呼入呼出等又有所不同,單通的發生對網絡指標如接通率無任何影響,從信令上看無任何異常,并且當前復雜的網絡架構又給本次故障定位帶來了一定的干擾。當出現單通投訴時,我們只能追蹤單通通話,找出共性,首先我們要定位用戶所在的小區,看是否集中在小區,排除無線方面的原因。其次需定位是否集中在核心網的某個交換機中。
二、處理方法
2.1MSC-S、MGW上監聽用戶A口設備
由于有部份投訴號碼位于FSM21B2(雙連至FSM06及FSM21)下,于是在FSM21B2下掛微蜂窩撥測,經過統計發現38次撥測中有5次出現單通復現,分別對這5次通話進行跟蹤,統計其所占用的MSC-S的A口信息、MGW上的MSB板等信息。
MGW上:CALL PATH TRACEING EMAS->Troubleshooting->Call path trace彈出的對話框中輸入MSC上CTRAI得到的Context ID(需留意后面選擇的是DEC),得出本次通話所占用的MSB板。
經過對相應的單通通話進行監聽,對其所占用的TRA、ABIS口、小區、A口、MGW、MSB板進行統計,發現只有一個共性,即所有的單通通話都占用了FSM21中的1-17這塊MSB單板。
2.2可疑故障網元FSM21深度檢查
ET板或MSB板的故障引起。對于這種類型的單通故障,故障診斷方法是在MSC-S和MGW上做call path trace,如果單通總出現在某塊ET板或MSB板上,可把故障點定位到該ET板或MSB板。如果單通故障是由MSB板故障引起,通常會伴隨著NB init fault,可lhsh到定位的MSB板用指令gra_info_stat查看。如果出現數量較多的NBinitfault,證明該MSB板有故障。如果單通故障出現在某塊ET板,可通過MSP1+1轉換把話務轉換到備用板。如果通過call path trace顯示單通分散在多塊ET板或MSB板,則有可能是switch plane出現故障。如果通過call path trace發現單通集中在某個機框的多塊ET板或多塊 MSB板,則可能是由該框的SCB板或與該SCB板連接的主機框SXB板故障引起的,SCB/SXB板故障有可能伴隨大量的gcp error(error code 500或510),這些gcp error在各塊負責mesc功能的GPB板均有出現,可通過指令mesc_counters_gcp查看。
三、故障原因分析
根據“先搶通后搶修”的故障處理原則,我們對FSM21進行了冷啟操作,但從撥測結果及信令數據上來看,并不是整個網元出現問題。
根據FSM21當時的日志,發現在單通故障期間FSM21 MSB板3307出現大量的“SAI Egress Discard. Cells”事件。對比之前的撥測結果發現每次單通通話都占用到了FSM21的2-7這塊MSB板。Pool內其他MGW無類似故障,而此次單通故障的很大程度是MSB4 3307出現問題是造成。
四、改善計劃
對于MSB板故障,部分監控方法與MRW R5相比有所變化,而為了更好地解決MGW的單通問題,全網對MGW進行了升級,在R6.2.2版本中,新增了UPS功能,可以對相應的單板所占用的通話時長進行監控,將疑似單通的板通過告警的形式呈現出來。
UPS的將兩種類型的板-ETIPG/MFG、MSB按物理上的框定義成相應的資源組,每個資源組里各個板邏輯上賦予了三種顏色:黑灰白,通過對各個板占用時常的監測,各個板的顏色會有一定的變化,黑色情況時發生單通的概率較高,各個板狀態正常時為白色,狀態異常時會由白變成灰,灰變成黑,三種顏色的變化只能是以下四種情況:
可以通過以下三條CLI指令查看相應的資源組及各個板的狀態:
(1)ups_get_peergroups
查看各種類型單板分組情況
(2)ups_get_safs查看各板當前的顏色(黑、白灰)
(3)ups_get_saf_details查看各板狀態的統計值
由于UPS功能正在調測階段,有時受到騷擾電話的影響,單板的狀態也可能會發生變化,導致有些告警信息不正確,后續將進行不斷的完善。