摩托羅拉BSS系統(tǒng)安全監(jiān)控手冊(motorola)

1、摩托羅拉BSS系統(tǒng)安全監(jiān)控手冊摩托羅拉浙江分公司協維組內容提要本部分內容綜述GSM BSC級系統(tǒng)網絡的硬件告警處理及一些日常監(jiān)控方法，提供維護過程中分析問題的一般思路，對常見告警的處理，實際故障解析等。對一些工具的使用，還有常見故障的案例和日常維護工作的注意事項。通過本部分的學習讀者將具有GSM BSC級網絡維護的一般知識，掌握BSS系統(tǒng)基本維護技能，能夠承擔日常的網絡維護工作。目錄 TOC o 1-3 h z u HYPERLINK l _Toc141006367 序論 PAGEREF _Toc141006367 h 4 HYPERLINK l _Toc141006368 維護工作的要旨-防

2、患未燃 PAGEREF _Toc141006368 h 4 HYPERLINK l _Toc141006369 分析問題的一般思路 PAGEREF _Toc141006369 h 5 HYPERLINK l _Toc141006370 第一章日常監(jiān)控數據收集 PAGEREF _Toc141006370 h 6 HYPERLINK l _Toc141006371 一、ECT PAGEREF _Toc141006371 h 6 HYPERLINK l _Toc141006372 二、EVENT LOG ： PAGEREF _Toc141006372 h 7 HYPERLINK l _Toc1410

3、06373 第二章BSS系統(tǒng)安全監(jiān)控 PAGEREF _Toc141006373 h 8 HYPERLINK l _Toc141006374 一、告警定義 PAGEREF _Toc141006374 h 8 HYPERLINK l _Toc141006375 二、監(jiān)控列表及描述 PAGEREF _Toc141006375 h 8 HYPERLINK l _Toc141006376 GPROC告警 PAGEREF _Toc141006376 h 9 HYPERLINK l _Toc141006377 GCLK告警 PAGEREF _Toc141006377 h 10 HYPERLINK l _T

4、oc141006378 KSW告警 PAGEREF _Toc141006378 h 11 HYPERLINK l _Toc141006379 LAN告警 PAGEREF _Toc141006379 h 13 HYPERLINK l _Toc141006380 BSP告警 PAGEREF _Toc141006380 h 14 HYPERLINK l _Toc141006381 MSI告警 PAGEREF _Toc141006381 h 15 HYPERLINK l _Toc141006382 MTL告警 PAGEREF _Toc141006382 h 15 HYPERLINK l _Toc141

5、006383 XBL告警 PAGEREF _Toc141006383 h 17 HYPERLINK l _Toc141006384 數據總線告警 PAGEREF _Toc141006384 h 17 HYPERLINK l _Toc141006385 BSS告警 PAGEREF _Toc141006385 h 19 HYPERLINK l _Toc141006386 第三章故障處理分析 PAGEREF _Toc141006386 h 20 HYPERLINK l _Toc141006387 一、常見故障分析處理 PAGEREF _Toc141006387 h 20 HYPERLINK l _T

6、oc141006388 GPROC的故障處理 PAGEREF _Toc141006388 h 20 HYPERLINK l _Toc141006389 GCLK的故障處理 PAGEREF _Toc141006389 h 21 HYPERLINK l _Toc141006390 KSW的故障處理 PAGEREF _Toc141006390 h 22 HYPERLINK l _Toc141006391 KSWX/DSWX板的故障： PAGEREF _Toc141006391 h 22 HYPERLINK l _Toc141006392 LANX的故障處理 PAGEREF _Toc141006392

7、 h 23 HYPERLINK l _Toc141006393 MSI的故障處理 PAGEREF _Toc141006393 h 24 HYPERLINK l _Toc141006394 MTL的故障處理 PAGEREF _Toc141006394 h 24 HYPERLINK l _Toc141006395 BSP的故障處理 PAGEREF _Toc141006395 h 25 HYPERLINK l _Toc141006396 數據總線的故障處理 PAGEREF _Toc141006396 h 26 HYPERLINK l _Toc141006397 單通故障的處理 PAGEREF _To

8、c141006397 h 29 HYPERLINK l _Toc141006398 二、日常維護的注意事項 PAGEREF _Toc141006398 h 29 HYPERLINK l _Toc141006399 三、典型問題匯總 PAGEREF _Toc141006399 h 30序論維護工作的要旨-防患未然系統(tǒng)建設完成經過驗收后，就轉入系統(tǒng)維護工作。由于此時系統(tǒng)已經給終端用戶提供服務，網絡的任何故障均可能對終端用戶產生影響，從而對運營商的形象產生影響。所以維護工作的要旨是防患于未燃，將系統(tǒng)隱患盡早排除，不要使其成為系統(tǒng)故障而影響系統(tǒng)的性能。預防性維護是我們的最佳選擇，定期對任何一個BSS網

9、元的巡檢和對基站的安裝調測都進行嚴格的檢測調整，保證系統(tǒng)及其附屬外圍設備工作在正常狀態(tài)，通過集中性預防維護，可以及時發(fā)現系統(tǒng)隱患并加以排除，最大限度地提高現行系統(tǒng)設備的利用率，增強系統(tǒng)設備的可靠性，從而減輕平時日常維護的壓力。由于各個方面的原因，諸如傳輸、不同廠家設備配合、各個廠家硬件的穩(wěn)定性、軟件、氣候、環(huán)境等，使得系統(tǒng)會出現一些不可預知的問題。如何解決此類問題，盡快恢復系統(tǒng)工作。 分析問題的一般思路遇到問題時，保持清醒的頭腦，認真仔細的分析問題，做好必要的檢查，收集相關數據，最大限度的掌握材料對于我們迅速準確的判斷問題是有很大的幫助。首先我們要分清是局部問題，還是系統(tǒng)問題，是單個基站的問題

10、，還是整個BSC的問題，是一個BSC的問題還是MSC下所有的BSC問題。通過初步的故障定位，進行初步的處理與測試，縮小故障范圍，直到找到最終的故障原因。其次我們要通過各種方法，尋找問題可能有的規(guī)律，如特定的時間，具有周期性等等。尋找出規(guī)律，就能加快故障定位，在日常的維護中出現的最多是硬件故障，而系統(tǒng)的硬件又是整個網絡運行的最基本保障，有些硬件故障是我們可以解決的，而有些硬件故障是需要CNRC來協助解決，所以就需要收集一些SWFM、LOG等數據。每次出現的故障及處理好后都要做記錄，以便為以后出現故障提供參考。 日常監(jiān)控數據收集機房維護人員經常碰到告警，有些告警是操作維護過程中自然產生的，有些告警

11、是瞬時性的，不會影響系統(tǒng)正常運行，但頻繁的出現也會加大系統(tǒng)的負荷，因此對于我們維護人員來說，怎么發(fā)現告警，怎么來定義告警，有些告警是需要通過歷史事件來發(fā)現跟蹤，還有一些告警故障是需要CNRC來協助我們解決，在CNRC處理的過程中當然會需要一些數據分析說明，所以需要我們來收集一些告警事件，SWFM、MMI LOG、EVENT LOG等數據，因此我們有必要知道日常維護中的一些命令和工具的使用。一、ECTEvent count tool 是COP的工具之一，該Tool只統(tǒng)計ALARM 告警，可以統(tǒng)計出整個OMC的告警次數，也可以具體統(tǒng)計出某個設備產生告警的次數，所以我們可以通過ECT了解現網的告警趨

12、勢，對于一些EVENT如傳輸、信令的閃斷，和硬件板主備用的倒換這樣告警事件是無法統(tǒng)計的，而ECT保留的數據一般是一星期，所以我們在日常的維護中如何應用該工具、如何從ECT里發(fā)現告警、如何分析告警，具體操作可參考附件： 目前，如果杭州EMS系統(tǒng)沒有故障的話，也可以使用EMS報表來統(tǒng)計各類告警。二、EVENT LOG ：Event log是網元產生的所有告警信息，存放了所有的告警歷史件，存放的時間一般一星期，因此當網元出現故障時，我們一般要去收集幾天的Event log 數據來進行分析，從Event log里可以發(fā)現具體的告警信息時間及出現的次數來找出故障的原因，對于現網中EVENT數據的收集，我

13、們可以采用CEL命令和OMC-R上的Event Logs的窗口來收集，具體方法參考附件。 三、SR數據收集由于目前浙江沒有簽署NSP合同，因此只能通過以下兩個途徑才能開SR。1.內部途徑：需要上報領導批準；2.外部途徑：浙江移動客戶上報省公司網絡部批準。SR開通后，通常需要現場協助收集故障網元的一些SWFM、MMI LOG、EVENT LOG，如還需要其他數據，CNRC會給出詳細的操作說明，具體操作說明詳見附件。 BSS系統(tǒng)安全監(jiān)控日常的網絡維護中，發(fā)現有些告警對系統(tǒng)影響不大， 如EAS外部告警、IAS內部告警；而有些告警出現次數很少，往往出現會給系統(tǒng)帶來嚴重后果，嚴重會導致系統(tǒng)重起，如 GP

14、ROC、BSP、KSW等一些的告警，因此日常對這些嚴重的告警(BSC級以上網元)要實時監(jiān)控，對于這些監(jiān)控的告警內容要熟悉掌握，這樣才能在發(fā)現告警后做出準確的判斷處理，對這些告警盡早發(fā)現、分析、定位、解決，讓網絡保持良好的運行。一、告警定義在維護中一些實時告警是需要我們時時關注的，這些告警我們定義在OMC-R上Event Mgt窗口上，如何在OMC-R上Event Mgt窗口定義告警、如何在該窗口查看告警，請參考附件：二、監(jiān)控列表及描述日常的安全監(jiān)控應該從軟件、硬件及信令負荷來分析處理，我們現在監(jiān)控的主要是BSC級的告警，因為網絡正常運行最基本的條件是硬件正常工作，如果網元都不能正常運行，所有的

15、性能指標也毫無意義，所以在日常的網絡維護中，掌握一定的告警分析和處理技能，顯得非常重要，這里就對我們監(jiān)控的告警進行說明解釋。GPROC告警GPROC:Generic Processor board 完成BSC站和RXCDR站的基站控制功能，如故障管理、交換控制等，支持第3層呼叫處理能力，支持信令鏈路，包括支持MTL、RSL、OML、XBL、CBL等信令鏈路239號告警：“ Process Safe test Audit Failure”處理器自檢失敗，處理板存在軟件或硬件故障，應該去檢查軟件版本或硬件的相關連接，GPROC的CUP也有一定的工作極限，當BSP的CPU使用率達到100%，出現BS

16、P239告警，BSC就會自動reset。24號告警：“ Bad Clock Source or SYNC OCXO(oscillator) Replacement Required”晶振震蕩器的故障引起GPROC退服，檢查SYNC硬件及更換。35號告警:“ LAN Connection Failure”主用GPROC和某個GPROC的LAN連接失敗，可能導致該GPROC重起，因為GPROC下掛的信令或BTS，所以GPROC的重起會引起其它設備的重起，因此在監(jiān)控中要重點去分析處理，出現該告警要去檢查LAN連接及LANX、GPROC硬件。254號告警:“ Device Failure”GPROC管

17、理系統(tǒng)的故障引起GPROC退服，如果該GPROC是BSP會導致BSC重起，檢查處理板的連接、復位該硬件板無效、進行更換。39號告警：“Software Failure” 此告警表明GPROC出現一個fatal SWFM，檢查該系統(tǒng)的軟件版本。GCLK告警GCLK：Generic Clock board產生時鐘信號，向上一級時鐘鎖相，對于BSS來說GCLK要與MSC的時鐘同步，因此出現了該告警我們逐步往上查如提供時鐘的MMS、GCLK硬件板等相關硬件。0號告警：“Reference distribution module failure”此告警說明GCLK晶振電路模塊故障，將導致GCLK OOS

18、。需要更換GCLK板。2號告警：“Clock reference failure”此告警說明GCLK無法從傳輸端口提取時鐘，需要檢查傳輸或傳輸參數。3號告警：“Hardware Fault Detected”此告警說明GCLK存在不可恢復的硬件故障，需要更換。4號告警：“Phase lock lost ”此告警GCLK鎖相電路無法鎖相，RXCDR或BSC出現該告警，會導致下面的所有的BTS時鐘丟失，結果會引起切換失敗，掉話等一些現象，所以在日常的監(jiān)控中我們要重點關注。5號告警:“125 s reference count overow”此告警說明GCLK板125s參考時鐘延時超過125s，GC

19、LK將自動切換到備用側。如果7秒鐘內出現2次，這塊GCLK將 OOS?？赡苁荊CLK硬件故障。6號告警:“60 ms reference count overow”此告警說明GCLK板60s參考時鐘延時超過60s，GCLK將自動切換到備用側。如果7秒鐘內出現2次，這塊GCLK將 OOS?？赡苁荊CLK硬件故障。7號告警:“6.12 seconds reference count overow”此告警說明GCLK板6.12 s參考時鐘延時超過6.12 s，GCLK將自動切換到備用側。如果7秒鐘內出現2次，這塊GCLK將 OOS?？赡苁荊CLK硬件故障。9號告警:“Hard reset”此告警說明

20、GCLK板發(fā)生了復位。14號告警:“Phase lock failure”此告警說明GCLK板鎖時鐘失敗，可能是傳輸故障或GCLK硬件故障。15號告警:“ Watchdog Timer Expired ”此告警說明SYNC處理器在MCU板上的Watchdog計數器超時，檢查SYNC硬件及MCU板。16號告警:“ Clock Output Failure”在系統(tǒng)里GCLK的同步硬件沒有產生16.384MHz時鐘信號，導致時鐘輸出失敗，檢查SYNC硬件及MCU板。17號告警:“ SYNC Shutdown Request”該告警表明GCLK同步嚴重失敗，檢查GCLK狀態(tài)、SYNC硬件及MCU板。1

21、8號告警:“ Not Operational”MCU與GCLK的同步功能失敗，無法操作，檢查GCLK板及SYNC硬件。19號告警:“ Warmup Failure”此告警表明GCLK不能在即定的時間內完成預熱，檢查SYNC處理器及硬件。20號告警:“ Invalid Mode”此告警表明MCU的FM進程檢測到GCLK完成初始化和預熱后進入的操作模式不正確232號告警:“ Processor Bus Communication Failure”GCLK板與MUAP總線通信失敗，檢查GCLK板和相關的MCAP總線。24號告警: “Bad clock source此告警表明GCLK的同步時鐘超出的范

22、圍會影響系統(tǒng)性能，或時鐘源需要校準。KSW告警KSW ：Kiloport SWitch board 千端交換板，執(zhí)行TDM HIGHWAY 上1024 個64Kb/s時隙的交換，還可以執(zhí)行32kb/s 或16kb/s的交換，KSW在BSC站中完成16kb/s的動態(tài)交換功能，在RXCDR中完成靜態(tài)交換功能。當BSC超過一個CAGE時就需要KSWX板來擴展KSW板的1024個Ts到另外的CAGE ，KSWX板它支持TDM highway的擴展和擴容，接受擴展時鐘。KSWX Error時，有可能是KSWX板子的硬件問題，也有可能是連接KSWX板的光纖故時，應該先確認故障的原因。當KSW OOS時，K

23、SWX的故障也將不能被監(jiān)控。KSWX的問題一樣會導致BSC自動reset，因為它負責了TDM highway的擴展和擴容，當它出現問題時，擴展的CAGE有可能就是失去時鐘源，或者是沒有了時隙分配，當然就不能正常工作了，所以系統(tǒng)為了盡可能恢復工作，會自動進行reset。對于KSW告警的出現我們在日常監(jiān)控中也進行了分析處理并及時的派發(fā)了工單。4號告警:“ Clock A Signal Loss”主時鐘信號丟失，表明一個KSW的CLOCK A 失敗，可能引起B(yǎng)SS的重起，檢查KSWX的相關連接及GCLK板，一般該告警都是GCLK板的故障引起。5號告警:“ Clock B Signal Loss”該告

24、警是相對與上面的4號告警，處理方法同4號告警，對于這兩個告警任何一個告警出現我們都要綜合分析處理。7號告警:“ Re-Initialized Unexpectedly”此告警此告警表明KSW意外地重新初始化或reset。引起告警是KSW板的硬件故障或軟件版本，處理器及MMS的連接板都可能導致KSW的Reset.8號告警:“ Hard Reset”此告警表明KSW硬件reset了,是KSW的硬件故障及軟件版本引起。10號告警:“ Lost Communication with KSW”KSW和Fault Management通信失敗，檢查KSWX連接及硬件、MCAP底板的數據連接線、MCAP主處

25、理器的GPROC板。11號告警:“ Local Cage KSW TDM Loopback Test Failure” 本地KSW TDM循環(huán)測試失敗，檢查KSW硬件及TDM數據線。224號告警:“ Safe Test Audit Failure”KSW安全自檢AUDIT失敗，檢查KSW軟硬件、MCAP數據線。232號告警:“ Processor Bus Communication Failure”此告警表明KSW無法通過MCAP總線與某個GPROC通信，處理器數據線通信失敗，該告警是由KSW或GPROC板不在機架上引起的或KSW/GPROC板連接的MCAP數據線的故障引起的。9號告警:“Wa

26、tchdog timer Expired” KSW的Watchdog計數器超時，檢查KSW硬件、處理器及外圍設備板。254號告警:“ Device Failure”KSW硬件失敗主KSW FAIL 導致KSW重起，會引起B(yǎng)SS重起，是KSW硬件設備引起，檢查KSW硬件板及進行更換。 LAN告警LAN 網是BSC 站/RXCDR 站中各GPROC/GPROC2 處理器板之間通信的局域網，幾個CAGE的GPROC是否工作在同一LAN上是區(qū)分這幾個CAGE是否是一個站的標志，LAN網上GPROC和LANX 串聯在一起，由LANX 控制本CAGE 的LAN 自成環(huán)網還是與其它CAGE 的LAN 組成一

27、個網，BSSC 機柜中有一主一備兩個LAN 網。0號告警:“ Active & Standby LAN Failure”此告警表明LAN的檢測進程無法將active LAN SWAP到另一個LAN，主備LAN OOS，檢查主備LAN板及光纖連接。1號告警:“ LAN Failure” LAN設備故障OOS，GPROC的重起及硬件故障、LAN板、LANX板及相連接的光纖都可能引起該告警。X25 告警：“X25CircuitDown”BSP告警BSP：Base Station Processor ,被定義在GPROC上是BSSC總處理器，分主備用，出現問題時，整個BSSC都要受到嚴重影響，BSP

28、RESET 后，整個BSSC都會RESET,因此在日常維護中對該處理器的監(jiān)控及處理是非常重要的。20號告警：“Lapd Controller Failure ” BSP上的Lapd控制器出現嚴重錯誤。30號告警:“ Clock A Signal Loss”BSP監(jiān)察到TDM Clock A Failure 引起B(yǎng)SC OOS,檢查KSWXA板、CLOCK A在GPROC上的接受電路、光纖及相關連接。31號告警:“ Clock B Signal Loss”BSP監(jiān)察到TDM Clock B Failure 引起B(yǎng)SC OOS，檢查KSWXB板、CLOCK B在GPROC上的接受電路、光纖及相關連

29、接。32號告警:“ TDM Interface Failure”分配時隙的記數器溢出引起TDM接口失敗，檢查分配時隙的記數器、MCAP接口及MCAP的地址數據總線。34號告警:“ TDM Interface Failure TDM Parity Error”TDM奇偶校驗錯誤，檢查和GPROC、KSW/KSWX 相連接的TDM 數據線。35號告警:“ LAN Connection Failure”主用的GPROC和備用的BSP通信失敗，不在同一LAN上，檢查GPROC硬件、LANX連接及硬件。39號告警:“ Software Failure”處理器的軟件故障，檢查處理器的軟件版本、GPROC硬

30、件。231號告警:“ TDM Interface Configuration Failure”BSP在TBUS時隙指定配置出現程序錯誤，該告警是軟件或GPROC硬件板引起。239號告警:“ Process Safe Test Audit Failure”處理板的軟硬件故障引起處理器自檢失敗，檢查處理器的連接及GPROC硬件板。254號告警:“ Device Failure”該告警表明BSP Failure，檢查GPROC硬件及相關連接。MSI告警MSI板實現E1 信號與TDM HIGHWAY 上信號的相互轉換。1 塊MSI 板終端2 個E1，提取2M 時鐘參考信號。對于RXCDR 站8#、10

31、#槽位是主用槽位，對于BSC 站14#、16#槽位是主用槽位，主用槽位上定義了起站時用來從OMC 下載軟件和數據庫的缺省OML 鏈路。 MSI 11- MSI 40 “DSP Channel (029) Audit Failure”此告警表明MSI（XCDR，GDP）的DSP audit fail。 MSI 232“ Processor Bus Communication Failure”此告警表明MSI (XCDR, GDP)無法通過MCAP 總線與GPROC 通信。MTL告警MTL鏈路是MSC與BSC的信令鏈路，其在整個系統(tǒng)中起著MSC與MS、BSS連接的作用。MTL出現問題會導致其下屬所

32、有的BSS癱瘓。 MTL最多的告警一般為0號告警，出現此告警時MTL為D-U。此告警表示MTL鏈路與MSC已經失去聯系。這是由于MTP第二層出現問題，而退出服務。但系統(tǒng)會不斷嘗試恢復此鏈路。另外當一條MTL鏈路退出服務時，其負荷會分配到其它MTL上，加重其它MTL的負擔，因此MTL鏈路負擔過重，會使得GPROC退出服務，從而導致更多的鏈路退出服務，在杭州的現網中建議MTL的利用率不要超過40%（40%的MTL利用率是指TX或RX中的任意一條都建議工作在不大于此門限之下）。 0號告警：“Signalling link failure”； MTL 0號告警表示一條MTL退出服務，而一個BSS可能有

33、多條MTL鏈路，一條MTL退出服務不會導致系統(tǒng)重起，如出現頻繁就要去檢查數據庫內關于MTL鏈路定義有無問題，然后檢查有關的MMS口、MSI板是否退出服務，再查與MSC的信令點碼是否正確，在日常的監(jiān)控中發(fā)現很少是數據庫，MMS口、MSI板的問題，大部分是MSC傳來的MTP第二層LSSU信息引起的。1號告警：“ MSC Processor Outage”； 是MSC處理器遠端的MTP第二層LSSU鏈路故障導致MTL被BLOCK掉，該告警幾乎很少出現，在監(jiān)控中也沒有發(fā)現該問題。3號告警：“ LinkTraffic Too High”；MTL信令負荷超過門限，系統(tǒng)擁塞，會影響GSM的服務，建議去增加M

34、TL鏈路，MTL擴容。BSS0 告警：Last MTL link Failure Signalling Point Inaccessible一個BSS可能有好多條MTL鏈路，BSS0告警表示此BSS系統(tǒng)的最后一條鏈路也退出服務，此時BSS完全癱瘓。此時我們要去檢查數據庫內關于MTL鏈路定義有無問題，然后檢查有關的MMS口、MSI板是否退出服務，再查與MSC的信令點碼是否正確，在確認上述方面無問題后檢查GPROC是否有硬件問題，必要時復位該GPROC。XBL告警XBL: Transcoder to BSS Link.是通過MMS E1/T1鏈路連接，BSC和RXCDR 是通過幾條XBL信令鏈路通

35、信的，如果其中某條中斷會增加其它信令的負荷，如果負荷超過極限會導致BSSC系統(tǒng)重起，在現網摩托羅拉建議此項指標的預警門限設定在50%。10號告警:“ Link Disconnected ”XBL中斷，BSC與RXCDR失去通信，檢查XBL所在的傳輸及協議。 12號告警:“ Link Traffic Too High” XBL鏈路的業(yè)務量太大而使的鏈路中斷，建議對該鏈路進行擴容。13號告警:“ LAPD Protocol Error Threshold Exceeded”該告警是在一分鐘內LAPD layer二層協議出錯超出30次，檢查傳輸及相關的協議。數據總線告警BSS在軟件上存在著PBUS、

36、SBUS、TBUS和CBUS四種總線，這四種總線我們可以在BSC的MMIRAM狀態(tài)下通過state命令來查看它們的工作狀態(tài)。TBUS它由KSW控制，有1024個Ts，分配給GPROC、MSI、XCDR、KSW，可擴展擴容。0號告警：TBUS: Remote KSW Loopback Test Failure此告警表明在擴展cage內的50%GPROC和remote KSW間的TDM自環(huán)測試fail。3號告警：Local KSWX/DSWX TDM Error 本地KSWX/DSWX的TDM錯誤，一般是KSWX/DSWX的光纖連接或硬件板的故障引起。 4號告警：Remote KSWX/DSWX

37、TDM Error該告警是和3號告警相對的，遠端KSWX/DSWX的TDM錯誤。CBUS即Clock Distribution Bus，通過此總線將GXLK時鐘傳到CAGE背板。給GPROC、KSW、MSI、XCDR等提供時鐘，這些BUS都是每個CAGE一主一備的。0號告警 ：Over 50% Of Boards Detected Clock Failure ”此告警表明一個cage中有超過50%GPROC和全尺寸板無法使用CBUS總線。2號告警：“Master CBUS Signal Provided By Slave GCLK ” 此告警表明因為GCLK被取走使得CBUS無法工作。此時CB

38、US為OOS。4號告警：“ Local KSWX/DSWX Clock Fibre Failure”此告警表明連到lclKSWX的CBUS光纖出現問題或DSWX板的硬件問題。PBUS即Processor Bus ，它是MCAP總線在軟件上的一種表示，它負責GPROC與其他全尺寸板（XCDR、GCLK、KSW、DRI）之間的通信。254號告警：PBUS: Device Failure 此告警表明active PBUS fail BSS告警 BSS5 號告警：“No MSC Acknowledgement for Circuit Block” 從MSC側得不到電路BLOCK的確認應答B(yǎng)SS6 號告

39、警：“No MSC Acknowledgement for Circuit Unblock”從MSC側得不到電路UNBLOCK的確認應答B(yǎng)SS7 號告警：“No MSC Acknowledgement for Reset Circuit”從MSC側得不到RESET電路的確認應答B(yǎng)SS8 號告警：“Unequipped Circuit at the MSC MSC”增加該CIC或BSC刪除該CICBSS12 號告警：“Unequipped Circuit at the BSS BSC”增加該CIC或MSC刪除該CICBSS39 號告警：“Circuit Fault Detected on Rad

40、io Channel” RCI的TRAU同步丟失BSS43 號告警：“Circuit Fault Detected on PCM Circuit” MSC與BSC側的告警BSS47 號告警“Circuit Fault Detected on PATH Channel” PCI的TRAU同步丟失故障處理分析 在日常的維護中，會遇到各種各樣的故障，為了對現場處理故障有更多的了解，我們選擇一些平時處理故障的的案例，分析一些故障產生的原因，并對一些故障的分析思路、最總解決手段進行分析說明。一、常見故障分析處理GPROC的故障處理 根據日常的維護發(fā)現，GPROC出現的告警最多是“35 LAN Conne

41、ction Failure”GPROC是BSC機柜中數字處理板，它支持與MSC的信令鏈路（MTL）、與BTS的信令鏈路（RSL）、CBC接口的CBL鏈路以及與RXCDR接口的XBL鏈路，支持以上這些鏈路的協議，支持第三層呼叫處理功能，以及BSC的許多如故障管理、開關控制等的控制功能。 GPROC可被定義成BSP、CSFP和普通的GPROC，當主用的GPROC板也就是BSP，出現問題時，整個BSC的工作就受到嚴重影響，將主用GPROC reset后，就有可能使整個BSC都reset，而35告警說明該GPROC不工作在整個BSC的LAN上了。該故障的可能原因是：GPROC板通過軟件操作或硬件操作被

42、Reset；GPROC板的故障；LANX硬件的故障或光纖物理損壞。 如果是BSS上的某個GPROC出現35號告警，應該可以判斷是該GPROC的故障，建議更換。GCLK的故障處理 GCLK產生時鐘，向上一級的時鐘鎖相，GCLK最多的告警是Phase Lock Lost。 GLCK 的功能是使得系統(tǒng)與更準確的時鐘同步，對于BSS 來說，GCLK 要與MSC 的時鐘同步。GCLK 要與上一級時鐘同步必須要有上一級時鐘的參考信號，時鐘參考信號是根據數據庫的定義從指定的MMS 口上提取的。在database 中需要定義不同MMS 口的時鐘提取優(yōu)先等級。 該故障的可能原因是：因傳輸問題引起MMS 退服MS

43、I 板或MMS 口硬件故障數據庫定義不合理GCLK 本身的問題，需要校正或更換當出現GCLK 無法鎖相的告警時首先要搞清楚參考時鐘是從哪里來的。檢查一下數據庫中有關GCLK 的參數設置是否合理，如鎖相應向上鎖，即RXCDR 向MSC 鎖、BSC 向RXCDR鎖、BTS 向BSC 或上一級的BTS（只有菊花鏈的情況）鎖，如果數據庫設置沒有明顯不合理之處，應注意一下與時鐘提取有關的MMS 口和MSI 板的狀態(tài)，MMS 口退服可能是傳輸問題引起的，也可能是MSI 板或MMS 口硬件故障引起的，如果MSI 板工作正常則應著重檢查傳輸質量。在排除了數據庫、MSI 硬件和傳輸原因之后，應校正或更換GCLK

44、 板，而日常的時鐘失鎖基本上都是傳輸問題引起，雖然GCLK失鎖不會給系統(tǒng)帶來致命后果，但也會給網絡的指標帶來負面影響。由于4月23日HZBSC163發(fā)生了GCLK問題導致BSC退服事件，因此現在開始，需要對GCLK Phase Lock Lost或GCLK Phase Lock Failure的BSC/XCDR重點監(jiān)控，發(fā)現GCLK Phase Lock Failed的，應該及時派發(fā)工單給杭分處理。KSW的故障處理KSW Kiloport SWitch board.執(zhí)行TDM HIGHWAY 上1024 個64Kb/s 時隙的交換。也能進行32Kb/s 或16Kb/s 的交換，RXCDR 站中

45、完成靜態(tài)交換功能（釘連），BSC 站中完成16Kb/s 動態(tài)交換功能。KSW出現最多的告警是Clock A / B Signal Loss該故障的可能原因：GCLK/KSWXA/B 可能損壞；接受電路引起KSW FAIL；MCAP或則TDM處理總線接口。當KSW出現這些告警時，我們要收集近幾天的eventlog數據來發(fā)現問題，因為該告警的出現也許不僅僅是KSW板的問題，根據日常出現的故障發(fā)現，如果同時出現時鐘失鎖，應該首先定位在GCLK上，如果時鐘沒有失鎖，而出現了TDM的閃斷，這時候我們應該關注半尺寸板KSWX，所以在這些告警出現時，要綜合的去考慮分析，定位出故障。 KSWX/DSWX板的故

46、障：當BSC超過一個CAGE時就需要KSWX板來擴展KSW板的1024個Ts到另外的CAGE ，KSWX板它支持TDM highway的擴展和擴容，接受擴展時鐘。KSWX Error時，有可能是KSWX板子的硬件問題，也有可能是連接KSWX板的光纖故障，也有可能是與它通信的另一CAGE的KSWX板有問題。所以當我們發(fā)現有KSWX的Alarm時，應該先確認故障的原因。當KSW OOS時，KSWX的故障也將不能被監(jiān)控。 KSWX的問題一樣會導致BSC自動reset，因為它負責了TDM highway的擴展和擴容，當它出現問題時，擴展的CAGE有可能就是失去時鐘源，或者是沒有了時隙分配，當然就不能正

47、常工作了，所以系統(tǒng)為了盡可能恢復工作，會自動進行reset。如 24 KSWX/DSWX in Slot 9 Detected Expanded ；25 KSWX/DSWX in Slot 21 Detected Expanded；26 KSWX/DSWX in Slot 22 Detected Expanded KSW Matrix Failure，出現這些告警，首先考慮CAGE 0 上的CLKX與相對應的CAGE的KSWX/DSWX板的光纖、光纖連接及半尺寸的硬件板，通過日常的故障處理，這些告警基本都是半尺寸的問題引起，而這些硬件板的故障率也較大。LANX的故障處理LANX板是每個BSU/

48、RXU CAGE 里所必須要有的板子，它由兩條串行總線連接與GPROC板之間的通信，以及不同CAGE之間的通信。當LANX出現問題變?yōu)镈-U時，GPROC之間的通信就不能進行，整個BSC的就不能正常工作，在這種情況下，BSC有可能會試圖修復故障，重新建立LAN，它就會自動reset。如果確實為板子硬件問題，當然reset也好不了，這時候我們就必須更換LANX才能解決問題了。一般每個CAGE配兩塊LANX，為一主一備，這樣工作就比較保險，不至于一個LANX一壞就整個BSC OOS。如：LAN Failure告警。 該故障的可能原因：某GPROC的故障也會引起LAN OOSLAN或LANX硬件板的

49、故障LANX的光纖故障在某時段LAN的信息超過負荷MSI的故障處理MSI出現的最多告警就是MSI-GDP的DSP Channel (029) Audit Failure，GDP是完成話音的壓縮編碼和速率適配，支持增強型語音編碼和話音控制，雖然該告警不會導致BSS系統(tǒng)Reset，但是出現DSP Channel Audit Failure 會引起單通，在日常的監(jiān)控中，如發(fā)現該故障建議更換硬件板MTL的故障處理MTL鏈路是MSC與BSC的信令鏈路，其在整個系統(tǒng)中起著MSC與MS、BSS連接的作用。MTL直接與BSC與MSC相連，或者是經過Remote XCDR與MSC相連。它使用C7協議，MTL提供

50、了MSC與BSC、MSC與MS之間的控制信息。MTL是MTP的Layer 2鏈路，當MTL OOS 時，Local MTP Layer 2與Remote MTP Layer 2之間的通信也就Fail了。該故障的可能原因： 連接MTL的MSI板FailMSC的處理器ailBSC端GPROC的FailMSC 傳來的MTP 第二層LSSU 信息出現錯誤。在出現告警時首先要判斷是傳輸、MSI的問題還是MSC的問題。disp_eq 0 MTL * * 查看 MTL所在的MMS，用state 0 mms * *查看MMS的狀態(tài)，如果MMS出現過閃斷應該是傳輸問題引起，如果沒有出現閃斷，應該是MSC傳來的M

51、TP第二層LSSU信息出現錯誤，在日常的監(jiān)控中大部分是MSC傳來的MTP第二層LSSU信息出現錯誤引起的。BSP的故障處理 BSP是BSC/RXCDR的處理器，都是配置一主一備，如果BSP 出現reset，整個網元也就reset了，因此在日常維護中對該處理器的監(jiān)控及處理是非常重要的。根據日常出現過的故障發(fā)現，有時候BSP硬件故障會突然導致BSS復位，BSP的故障發(fā)生率是很低，如：RXCDR自動重啟，CNRC的分析說明：故障分析：經過分析，發(fā)現在故障發(fā)生時，主用011bh報告了下列fatal 和 nonfatal SWFM process_user_interrupts，這說明RXCDR的重啟是

52、由主用BSP的硬件故障引起的。SWFM Log Entry 2 182 FATAL SWFM ERROR: SOFT RESET Routine: process_user_interrupts 182 Area: 0 x00000001 Error: 0 x00000000 PC: 0 xd00261ae PID: 0 x00 (Null) 182 24-Apr-2006 05:01:50.865 Subsystem: 0 x01 CPU: 0 x011b Board: GPROC3 RAM 182 T7130 reset for recovery timeout. Recovery Typ

53、e:29SWFM Log Entry 121 179 Nonfatal SWFM Error Routine: process_user_interrupts 179 Area: 0 x00000001 Error: 0 x0000001d PC: 0 xd002656e PID: 0 x00 (Null) 179 24-Apr-2006 05:01:45.865 Subsystem: 0 x01 CPU: 0 x011b Board: GPROC3 RAM179 Channel: 5 179 HDLC: T7130 ALARM 29 179 Channel State: 8 179 Read

54、 Address: 15 179 Write Address: 9ea2a 179 Internal Stack: 179 422d 1927 1ff9 3930 27a3 179 通過進一步對swfm log的分析，我們發(fā)現在RXCDR重啟之前系統(tǒng)的主用BSP有如下swfm：121 179 24-Apr-2006 05:01:45.865 d002656e 00 Null process_user_interrupts122 17a 24-Apr-2006 05:01:45.870 c0000de2 13 LAP DLSP dl_data_req123 17b 24-Apr-2006 05:

55、01:45.875 c0001496 13 LAP DLSP dl_flowcontrol_req124 17c 24-Apr-2006 05:01:46.080 c0001496 13 LAP DLSP dl_flowcontrol_req125 17d 24-Apr-2006 05:01:46.125 c00004ae 45 Validate perform_hdlc_config.c126 17e 24-Apr-2006 05:01:46.290 c0001496 13 LAP DLSP dl_flowcontrol_req 127 17f 24-Apr-2006 05:01:46.33

56、5 c00004ae 45 Validate perform_hdlc_config.c 0 180 24-Apr-2006 05:01:46.335 c0044a64 42 CA gproc_hdlc_recover.c 1 181 24-Apr-2006 05:01:46.500 c0001496 13 LAP DLSP dl_flowcontrol_reqSWFM Log Entry 12717f Nonfatal SWFM Error Routine: perform_hdlc_config.c17f Area: 0 x00000309 Error: 0 x00000003 PC: 0

57、 xc00004ae PID: 0 x45 (Validate)17f BSS Release: 1.7.6.f0.36 Obj Version: .b Exec Version: 7.117f 24-Apr-2006 05:01:46.335 Subsystem: 0 x01 CPU: 0 x011b Board: GPROC3 RAM17f Return code from hdlc_init = 253 #define T7130_CODE_LOAD_FAIL 253從以上log文件，我們看到在T7130重啟恢復的過程中，SWFM指明failed to code load T7130 c

58、hip，所以GPROC板最終因T7130恢復失敗而重啟。因此我們可以得出這是T7130硬件問題導致的主用BSP重啟，從而造成系統(tǒng)重啟。數據總線的故障處理BSC在軟件上存在著PBUS、SBUS、TBUS和CBUS四種總線，這四種總線我們可以在BSC的MMIRAM狀態(tài)下通過state命令來查看它們的工作狀態(tài)。PBUS即Processor Bus ，它是MCAP總線在軟件上的一種表示，它負責GPROC與其他全尺寸板（XCDR、GCLK、KSW、DRI）之間的通信。 當PBUS Device Failure時，BSC就會Reboot，在這個初始化過程中，BSC OOS。PBUS Device Fail

59、ure的原因可能是：LANX 板Faulty；可能是FTP（故障傳輸部分）和FCP（故障收集部分）之間的錯誤引起的。SBUS即Serial Bus ,它上面的通信由GPROC控制，主要負責GPROC與半尺寸板（如LANX、KSWX、GLKX、DRIX）之間的通信。每個CAGE也是一主一備的SBUS，但它們被分配不同的任務，Standby 不享有Active SBUS的功能。 當SBUS fail后，BSC就會自動reset。reset結束后，如果SBUS仍然是OOS，那么就必須去檢查具體原因了。SBUS有故障時，你必須考慮所有被主GPROC控制的SBUS上的通信。SBUS Failure的原因可能如下：LANX板子沒有插好，與背板的連接不正確。LANX板子Fail.GPROC板Fail，使SBUS上的通信不正常。BTC板不能給背板供電。半尺寸板在背板得不到電源。當我們發(fā)現SBUS OOS時，可以從以上幾方面來考慮檢查故障，不讓