BSC告警分析PPT課件

1、APAC China Customer Network Resolution Center BSC/RXCDR/PCUBSC/RXCDR/PCU告警分析告警分析 內(nèi)容簡介內(nèi)容簡介 告警格式與組成 告警處理的優(yōu)先級別 常見的BSS告警 告警的格式與組成告警的格式與組成 u 告警的種類和格式 告警可以分為硬件告警和軟件告警兩種： 硬件告警是由于BSS內(nèi)的硬件故障所引起的告警。 軟件告警是由GPROC檢測到軟件進程運行出錯所引起的告警。 只有GPROC設(shè)備（BSP，CSFP，DHP，BTP，pool GPROC）才會產(chǎn)生軟件告警 息。軟件告警（Software Fault Management或SW

2、FM）分為兩類。 告警舉例：告警舉例： #0 NEW *NONE*. CommuncationFailureEvent - CAGE - BSS01(BSS01:SITE-0:): 0 CAGE 1 - 30/03/1999 14:23:56. Expansion KSWX Slot 22 Communication Failure - FMIC - Major - -/-. (BSS01:SITE-0:):0 SITE Impacted to Major. #0：告警ID NEW：告警狀態(tài) NONE：正在處理此告警的人員 CommuncationFailureEvent：告警的類型 CAGE

3、：告警級 BSS01(BSS01:SITE-0:): 0 CAGE 1：發(fā)生告警的位置 30/03/1999 14:23:56：告警發(fā)生時間 18：告警編號 Expansion KSWX Slot 22 Communication Failure：告警描述 FMIC：告警的清除類型 Major：告警嚴重等級 (BSS01:SITE-0:): 0 SITE Impacted to Major:告警附加信息 u 告警的類型 告警編號對于每種設(shè)備都有唯一的一個十進制數(shù)表示。每種設(shè)備的告警編號從0到254。 對于不同的設(shè)備告警編號可能重復(fù)，但與設(shè)備相關(guān)的編號是唯一的。有些情況下同樣的 告警編號表示類似

4、的告警。 例如254號告警表示設(shè)備fail。 在OMC-R上將告警分成不同的六種類型，可以在OMCR的告警說明中找到 “FailureEvents” 字段，其為不同類型告警的名稱。 它們分別是： u 告警的等級 告警嚴重級別表明此故障發(fā)生對系統(tǒng)的影響程度，系統(tǒng)將告警的等級分為六級： u 告警處理的優(yōu)先級 我們可以根據(jù)告警的嚴重級別，以及出現(xiàn)告警的網(wǎng)元在系統(tǒng)中的重要性，對不同的告警 情況進行相應(yīng)的處理。在此我們提供一般原則下的優(yōu)先級別。對于基站來說從RXCDR 到BSC，再到BTS；信令鏈路按照MTL、RSL、XBL的次序；告警嚴重級別由高到低分 別是Critical、 Major、 Minor

5、、 Warning、 Investigate、Clear。在相同的告警級別 中，Critical告警按照以下順序All RXCDR-All MTL -All BSC-All RSL-All BTS-All X.25 link-All other Critical alarms。Major 告警按照以下順序All RXCDR-All BSC-All BTS-All other Major alarms。其它告警按照Minor、Warning 、Investigate、Clear alarms的順 序進行處理。 The sites Remote Transcoder (RXCDR) Base St

6、ation Controller (BSC) Base Transceiver Station (BTS). The links Message Transfer part Link (MTL) Radio Signalling Link (RSL) X.25 link. Critical告警按照以下順序：告警按照以下順序： All RXCDR - Critical alarms All MTL - Critical alarms All BSC - Critical alarms All RSL - Critical alarms All BTS - Critical alarms All

7、X.25 link - Critical alarms All other Critical alarms 常見的常見的BSSBSS告警告警 1、OML為為E-U或或D-U的問題的問題 在BSC或RXCDR看到此現(xiàn)象時，還可能看到相關(guān)的一 些告警，如OML 242號告警等。 背景原理： OML鏈路是OMCR到RXCDR或BSC的信令鏈路，主要 用于BSS的操作維護。OML使用X.25協(xié)議。OMCR通 過Router與BSS相連，在BSS端，操作數(shù)據(jù)在2M線的 某些時隙中傳輸，到達Router后，Router中的虛擬交換 電路把它們分門別類送往OMCR進行處理。同時OMCR 的數(shù)據(jù)也通過Rout

8、er交換后發(fā)往相應(yīng)的NE。 可能引起此類告警的原因：可能引起此類告警的原因： 相關(guān)的MMS口退出服務(wù) 主用MSI板沒有插 數(shù)據(jù)庫中關(guān)于OML鏈路的定義不對 DTE地址定義不對 路由器定義不對 軟件進程問題 解決思路解決思路： 如果OML鏈路從來沒有起來過，那么首先應(yīng)該檢查硬件 連接是否正確，特別是主用的MSI板是否插上了，因為 主用MSI板上定義了NE起來時用于從OMCR下載軟件和 數(shù)據(jù)庫的OML鏈路。然后核對DTE地址及路由器的設(shè)置 是否正確。如果OML鏈路以前是好的，那么首先要搞清 是否有人對OML相關(guān)的參數(shù)改動過，如數(shù)據(jù)庫中關(guān)于 OML鏈路的定義、DTE地址、路由器設(shè)置等。在確認沒 有改

9、動過后，應(yīng)檢查硬件問題，如MMS口是否退服、 MSI板是否故障等。 參考操作步驟參考操作步驟： OML鏈路的問題涉及的設(shè)備比較多，例如：OMCR，路由器， RXCDR等，為了正確定位故障應(yīng)結(jié)合數(shù)據(jù)收集來處理問題。 進入BSC鍵入state 0 命令查看BSC的狀態(tài)；進入RXCDR 鍵入state 0 查看RXCDR的OML狀態(tài)；在RXCDR鍵入 disp_links 查看RXCDR內(nèi)的鏈路連接，以確定與OML相 關(guān)的MMS位置；在出現(xiàn)問題的BSC或RXCDR中鍵入 disp_p 0查看哪個GPROC控制OML鏈路；鍵入 disp_act_a 0 查看是否有相關(guān)的告警；鍵入disp_eq 0 o

10、ml * * 查看每條OML的配置情況。 處理步驟處理步驟 進入BSC鍵入state 0 命令查看BSC的狀態(tài)； 進入控制OML的GPROC； 運用msg_send命令； lock/unlock OML，看OML的狀態(tài)； 再運用msg_send命令； lock/unlock OML所屬的MMS，查看OML的狀態(tài)； lock/unlock OML所屬的MSI，查看OML的狀態(tài)；如果OML仍為E-U狀態(tài)， 繼續(xù)以下步驟。 鍵入命令以停止和激活A(yù)GENT進程，然后lock/unlock此OML鏈路； 鍵入命令以停止和激活A(yù)GENT進程、X.25 PLP進程然后 unlock/lock 此 OML；

11、(10)排除硬件故障，考慮是軟件進程問題造成OML故障，可以考慮激活掛 OML的GPROC，如果還是不能解決可以考慮reset BSC。 2、GCLK無法鎖相的問題無法鎖相的問題 GCLK無法鎖相時會產(chǎn)生GCLK Failed Phase Lock的提 示，并可能伴隨出現(xiàn)4、14、13號等告警。 背景原理：背景原理： GLCK 的功能是使得系統(tǒng)與更準確的時鐘同步，對于 BSS來說，GCLK要與MSC的時鐘同步。時鐘同步的目 的是在射頻部分提供0.05ppm（ppm為百萬分之一。 即如時鐘為16.384M，則頻率誤差為16.3840.05 = 0.8192Hz ）的高精度的時間同步。因此要提供參

12、考時 鐘的E1/T1鏈路要盡量減少滑幀和失同步。 GCLK要與上一級時鐘同步必須要有上一級時鐘的參考信號，時鐘參 考信號是根據(jù)數(shù)據(jù)庫的定義從指定的MMS口上提取的。在 database中需要定義不同MMS口的時鐘提取優(yōu)先等級。 GCLK在工作時有四種不同的狀態(tài)： 自由振蕩狀態(tài)：此狀態(tài)是當(dāng)GCLK剛上電時，其內(nèi)部的晶體振蕩器 （OCXO）需要有預(yù)熱的過程，以保持其正常的工作環(huán)境。此時間 是固定不變的（30分鐘），無法更改。在自由振蕩狀態(tài)下，GCLK 內(nèi)的DAC輸入為80H，時鐘輸出保持在0.05ppm的精度內(nèi)。 Hold Frequency：此狀態(tài)是GLCK與2M失鎖時的狀態(tài)。此時GCLK 使用

13、前一次ADC輸出的值輸入DAC以控制時鐘，此狀態(tài)是一個過 渡狀態(tài)，一般持續(xù)10秒。 Set Frequency：此狀態(tài)一般在Hold Frequency之后。使用LTA （Long Term Average）值輸入DAC以控制時鐘。 正常鎖相工作時GCLK每30分鐘采樣一個ADC輸出值2位16進 制數(shù)，存入內(nèi)部存儲器，存儲器最大可以存放48個值，采用先入先 出原則更新。這48個值也可以被GPROC通過MCAP總線讀取或設(shè) 置。所謂LTA就是指將這48個值取平均輸入到DAC。Set Frequency狀態(tài)下，GCLK不再往存儲器中存放新值，只是使用以 前的舊值，存儲器停止更新，這是與鎖相狀態(tài)的不

14、同之處。 鎖相狀態(tài)：此狀態(tài)分為兩個子狀態(tài)， Acquiring Frequency Lock State，此狀態(tài)是一個過渡狀態(tài)，由硬件決 定。 Frequency Lock State，此狀態(tài)內(nèi)GCLK已與E1/T1鎖相，但需等待一 段時間，以確定鎖相穩(wěn)定之后就進入鎖相狀態(tài)。 可能引起此類告警的原因可能引起此類告警的原因： 因傳輸問題引起MMS退服 MSI板或MMS口硬件故障 數(shù)據(jù)庫定義不合理 GCLK本身的問題，需要校正或更換 解決思路解決思路： 當(dāng)出現(xiàn)GCLK無法鎖相的告警時首先要搞清楚參考時鐘是從哪里來 的。檢查一下數(shù)據(jù)庫中有關(guān)GCLK的參數(shù)設(shè)置是否合理，如鎖相應(yīng) 向上鎖，即RXCDR向

15、MSC鎖、BSC向RXCDR鎖、BTS向BSC或 上一級的BTS（只有菊花鏈的情況）鎖，向下一端的MSI口的時鐘 提取優(yōu)先級應(yīng)設(shè)為0，另外也不能只允許一個MMS口可以提取時鐘。 如果數(shù)據(jù)庫設(shè)置沒有明顯不合理之處，應(yīng)注意一下與時鐘提取有關(guān) 的MMS口和MSI板的狀態(tài)，MMS口退服可能是傳輸問題引起的， 也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常則 應(yīng)著重檢查傳輸質(zhì)量。在排除了數(shù)據(jù)庫、MSI硬件和傳輸原因之后， 應(yīng)校正或更換GCLK板。 參考操作步驟參考操作步驟： 為了利于問題的分析應(yīng)收集以下數(shù)據(jù)： state gclk * * （查看GCLK的狀態(tài)） disp_el phas

16、e_lock_gclk （查看是否允許鎖相） disp_eq 0 mms （查看MMS的參數(shù)，主要是時鐘提取優(yōu)先級） disp_el wait_for_reselection （查看時鐘提取切換時間） disp_el lta_alarm_range （查看LTA告警范圍） disp_gclk_avgs （查看GCLK的長期平均值） disp_eq gclk full（查看GCLK硬件版本信息） 當(dāng)GCLK無法鎖相時可采用以下的方法： reattempt_pl 使用lock/unlock命令看是否能使得GCLK鎖相恢復(fù)。 查看MSI，MMS是否處于正常狀態(tài)，是否有E1的相關(guān)告警產(chǎn)生，是否有MMS

17、作為時 鐘源。 查看提供時鐘的MMS是否與上一級的鏈路連接，上一級的時鐘是否正常工作。 查看提供時鐘的MMS的等級是否設(shè)置正確（一般為255）。 試著使用其它的MMS作為時鐘源。（對于M-CELL可更換NIU）。 3、MTL告警告警 背景原理背景原理： MTL鏈路是MSC與BSC的信令鏈路，其在整個系統(tǒng)中起著MSC與MS、 BSS連接的作用。MTL出現(xiàn)問題會導(dǎo)致其下屬所有的BSS癱瘓。 MTL最多的告警一般為0號告警，出現(xiàn)此告警時MTL為D-U。此告警表示 MTL鏈路與MSC已經(jīng)失去聯(lián)系。這是由于MTP第二層出現(xiàn)問題，而退出服 務(wù)。但系統(tǒng)會不斷嘗試恢復(fù)此鏈路。另外當(dāng)一條MTL鏈路退出服務(wù)時，其

18、 負荷會分配到其它MTL上，加重其它MTL的負擔(dān)，而由于GPROC的處理 能力的原因，MTL鏈路的平均利用率不能超過30。因此MTL鏈路負擔(dān)過 重，會使得GPROC退出服務(wù)，從而導(dǎo)致更多的鏈路退出服務(wù)。 此告警與BSS 0號告警的區(qū)別為：MTL 0號告警表示一條MTL退出服務(wù)，而 一個BSS可能有多條MTL鏈路，BSS 0號告警表示此BSS系統(tǒng)的最后一條 MTL鏈路也退出服務(wù)，此時BSS完全癱瘓了。 可能引起此類告警的原因：可能引起此類告警的原因： MSC傳來的MTP第二層LSSU信息出現(xiàn)錯誤。 MSC端擁塞超時 MSU確認消息超時 序列號出現(xiàn)錯誤 SUERM的錯誤門限值超出 收到不正常的FI

19、B 解決思路：解決思路： 先檢查數(shù)據(jù)庫內(nèi)關(guān)于MTL鏈路定義有無問題，然后檢查有關(guān)的MMS 口、MSI板是否退出服務(wù)，再查與MSC的信令點碼是否正確，在確 認上述方面無問題后檢查GPROC是否有硬件問題，必要時復(fù)位該 GPROC。 參考操作步驟參考操作步驟： 根據(jù)告警消息找到出現(xiàn)問題的站號，MTL的設(shè)備編號。 在RXCDR鍵入： disp_links disp_bss_conn 以確定MTL鏈路的連接情況。 鍵入disp_equip 0 MTL * * 得到MTL的配置情況。 查看與MTL相關(guān)的設(shè)備是否正常工作 state 0 mms * * 查看MMS的狀態(tài) state 0 msi * * 查

20、看MSI的狀態(tài) disp_p 0 查看MTL由那個GPROC控制 disp_act_a 0 查看是否有相關(guān)的告警 出現(xiàn)了相關(guān)的設(shè)備告警時應(yīng)先處理這些相關(guān)問題。 使用lockunlock、ins命令試著恢復(fù)鏈路。 檢查RXCDR或MSC是否在rebooting，等到其正常工作后再檢查 MTL是否恢復(fù)了。 在BSC鍵入： disp_ele dpc 0 disp_ele opc 0 此命令查看MTP的第三層的信令點碼。比較此點碼與MSC處設(shè)置的點 碼是否對應(yīng)。 找到控制此MTL的GPROC。 ins 0 gproc * * 如無效則鍵入： reset_de 0 gproc * * 將BSCreset

21、。 4、BSP 239號告警號告警 此告警表示GPROC的安全檢測進程檢測到進程錯誤。 背景原理背景原理： 安全檢測進程是負責(zé)對GPROC內(nèi)運行的進程檢查以確定是否運行正常。當(dāng)被檢測的 進程沒有響應(yīng)時就產(chǎn)生此告警。不同功能的GPROC所產(chǎn)生的239號告警表現(xiàn)為： 239 BSP 239 BTP 239 DHP 239 BTP (MCU) 安全檢測進程對系統(tǒng)進行周期性的檢測，可以通過參數(shù)來調(diào)整檢測的時間間隔。缺 省的時間間隔為10分鐘。 可能引起此類告警的原因：可能引起此類告警的原因： GPROC、BSP、BTP板子損壞 被檢測的GPROC、BSP、BTP軟件進程出現(xiàn)錯誤 被檢測的硬件出錯 GP

22、ROC沒插（但數(shù)據(jù)庫中作了定義） 從TCU到BTP的HDLC鏈路可能出錯 BTP的輸入輸出鏈路出錯 TCU的運行軟件出錯 解決思路解決思路： 首先確定是哪塊GPROC出現(xiàn)239告警，根據(jù)這塊GPROC的功能來確定存在問題的進程或硬件范 圍。如BTP 239告警，出現(xiàn)問題的進程可能運行于MCU，也可能運行于TCU，還可能是BTP與 TCU的通信進程。然后檢查相應(yīng)的硬件是否有問題，不能進一步判斷原因所在時，應(yīng)收集數(shù)據(jù) 再作分析。 參考操作步驟參考操作步驟： 在出現(xiàn)告警的基站鍵入state以確定發(fā)生告警的GPROC、BSP、DHP、BTP的狀態(tài)。 如果顯示為B-U，則鍵入 device_audit

23、all 如果device_audit成功則繼續(xù)觀察此設(shè)備。如果device_audit失敗則鍵入 ins 如果ins失敗，則進行如下操作，收集數(shù)據(jù)。 如果出現(xiàn)問題的是BSP，則通過直連或遠程登錄進入GPROC，如果沒有響應(yīng)則可能為GPROC太 忙，TTY進程來不及響應(yīng)。鍵入 disp_mms_ts_usage 查看A接口上是否有TCH被分配，如果有則收集GPROC的SWFM和event。 如果沒有則將GPROC reset，當(dāng)BSC reset后，收集GPROC的Fatal and Non Fatal SWFMs，以及 在告警發(fā)生前和BSC reset后的event。 如果出現(xiàn)問題的不是BSP

24、，則通過直連或遠程登錄進入GPROC，收集GPROC的Fatal and Non Fatal SWFMs，以及在告警發(fā)生前后的event。 5、IAS 1號告警號告警 IAS 1號告警Serial Bus Connection Failure，多出現(xiàn)在BSC 或RXCDR基站內(nèi)。 背景原理背景原理： 在BSSC機柜中有一塊的告警板，此板的作用為報告熔絲和風(fēng)扇等設(shè)備的告警。此告 警板的PL2和PL3連接到CAGE背板的左上角AI0/AI1口。如果BSS為兩個CAGE， 上面的CAGE一般是不連接告警線的。數(shù)據(jù)庫定義CAGE 時需要定義告警線是否接 到這個CAGE中。 disp_eq 0 cage

25、 0 0 Identifier for the CAGE: 0 KSW pair that manages the CAGE: 0 KSWX connecting cage to KSW for TDM 0: KSWX connecting cage to KSW for TDM 1: Cabinet to which the cage belongs: 0 IAS Connected: YES 最后一項如果定義為YES，則軟件嘗試將告警信號送到此CAGE，但是如果物理上并 沒有將告警線連接到此CAGE，則會產(chǎn)生IAS 1號告警。一般配置CAFE時都將下面 的CAGE定義為連接告警線，上面的C

26、AGE不連接。如果在equip cage時將上面的 CAGE也定義了IAS Connected: YES，則會產(chǎn)生大量的IAS 1告警。 可能引起此類告警的原因：可能引起此類告警的原因： 告警板故障 告警線連接錯誤 數(shù)據(jù)庫定義錯誤 告警線損壞 解決思路：解決思路： 先確定告警線連接在哪個CAGE中，查看數(shù)據(jù)庫中定義的 是否與物理連接相一致。不一致時修改數(shù)據(jù)庫。如果數(shù) 據(jù)庫定義沒有問題，檢查告警板和告警線是否損壞。 參考操作步驟參考操作步驟： 檢查告警線連接與數(shù)據(jù)庫中的定義是否相符 如果不符，使用命令： modify_value 0 ias_connected cage ( # ) yes/no

27、 ( # ) cage號 檢查告警板是否完好，告警線是否損壞。必要 時更換有關(guān)硬件。 6、BSS 22號告警：號告警：Trunk Critical Threshold Exceeded 此告警表示被BLOCK的CIC數(shù)目超過了緊急告警門限值。 背景原理背景原理： CIC是MSC經(jīng)由RXCDR到BSC的陸地電路。XCDR（GDP）板及內(nèi)部的 DSP處理器和MSI板的故障都會使得CIC的數(shù)目減少。另外由于傳輸?shù)葐?題也會使得CIC被block，但傳輸恢復(fù)正常后，CIC不一定能自動起來，此 時需要人工干預(yù)才能恢復(fù)。 可能引起此類告警的原因：可能引起此類告警的原因： 由于MSI板和MMS口的硬件問題導(dǎo)

28、致可用的CIC數(shù)目減少 由于E1鏈路的問題，包括傳輸問題，導(dǎo)致CIC數(shù)目減少 由于RXCDR中GDP、XCDR板的DSP處理器出現(xiàn)問題使得CIC數(shù)目減少 MSI、XCDR、GDP板可能被人為lock了 database中關(guān)于此告警的門限值設(shè)置得太低 解決思路：解決思路： 首先查硬件問題，如E1連接是否正常，MSI、XCDR、GDP板是否 有問題，有沒有被LOCK，再檢查是否因傳輸問題而使MMS口退服。 同時應(yīng)注意一下數(shù)據(jù)庫中有關(guān)參數(shù)的定義是否合理，如果MSC端 將CIC block，應(yīng)手動將CIC復(fù)位。 參考操作步驟參考操作步驟： 鍵入 state 0 msi * * state 0 mms * * disp_act_a 0 disp_act_a 0 檢查MSI，MMS狀態(tài)是否正常，是否有相關(guān)的告警。 在BSC找到對應(yīng)的連接到MSC的2M鏈路的MMS板鍵入 disp_mms_ts_usage 0 mms * * 查看此MMS的各時隙是否有被block的。如發(fā)現(xiàn)大量的CIC被block， 首先確定是否為MSC邊將其block的。如果不是則使用以下命令將 CIC釋放。 先進