BSC告警分析ppt課件

1、BSC/RXCDR/PCU告警分析摩托羅拉昆明分公司寬帶及挪動網(wǎng)絡(luò)事業(yè)部, 2021-07內(nèi)容簡介告警格式與組成告警處置的優(yōu)先級別常見的BSS告警告警的格式與組成告警的種類和格式告警可以分為硬件告警和軟件告警兩種：硬件告警是由于BSS內(nèi)的硬件缺點所引起的告警。軟件告警是由GPROC檢測到軟件進程運轉(zhuǎn)出錯所引起的告警。只需GPROC設(shè)備BSP，CSFP，DHP，BTP，pool GPROC才會產(chǎn)生軟件告警息。軟件告警Software Fault Management或SWFM分為兩類。 告警舉例：#0 NEW *NONE*.CommuncationFailureEvent - CAGE - BS

2、S01(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：告警IDNEW：告警形狀NONE：正在處置此告警的人員 CommuncationFailureEvent：告警的類型CAGE：告警級BSS01(BSS01:SITE-0:): 0 CAGE 1：發(fā)生告警的位置30/03/1999 14:23:56：告警發(fā)生時間18：告警編號Ex

3、pansion KSWX Slot 22 Communication Failure：告警描畫FMIC：告警的去除類型Major：告警嚴重等級(BSS01:SITE-0:): 0 SITE Impacted to Major:告警附加信息 告警的類型告警編號對于每種設(shè)備都有獨一的一個十進制數(shù)表示。每種設(shè)備的告警編號從0到254。對于不同的設(shè)備告警編號能夠反復(fù)，但與設(shè)備相關(guān)的編號是獨一的。有些情況下同樣的告警編號表示類似的告警。 例如254號告警表示設(shè)備fail。在OMC-R上將告警分成不同的六種類型，可以在OMCR的告警闡明中找到“FailureEvents 字段，其為不同類型告警的稱號。 它

4、們分別是：告警的等級告警嚴重級別闡明此缺點發(fā)生對系統(tǒng)的影響程度，系統(tǒng)將告警的等級分為六級：告警處置的優(yōu)先級我們可以根據(jù)告警的嚴重級別，以及出現(xiàn)告警的網(wǎng)元在系統(tǒng)中的重要性，對不同的告警情況進展相應(yīng)的處置。在此我們提供普通原那么下的優(yōu)先級別。對于基站來說從RXCDR到BSC，再到BTS；信令鏈路按照MTL、RSL、XBL的次序；告警嚴重級別由高到低分別是Critical、 Major、 Minor、 Warning、 Investigate、Clear。在一樣的告警級別中，Critical告警按照以下順序All RXCDR-All MTL -All BSC-All RSL-All BTS-All

5、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 Station Controller (BSC)Base Transceiver Station (BTS). The linksMessage Transfer part Link (MTL) Radio Sign

6、alling Link (RSL)X.25 link. Critical告警按照以下順序：All RXCDR - Critical alarmsAll MTL - Critical alarmsAll BSC - Critical alarmsAll RSL - Critical alarmsAll BTS - Critical alarmsAll X.25 link - Critical alarmsAll other Critical alarms常見的BSS告警1、OML為E-U或D-U的問題 在BSC或RXCDR看到此景象時，還能夠看到相關(guān)的一些告警，如OML 242號告警等。背景原理

7、： OML鏈路是OMCR到RXCDR或BSC的信令鏈路，主要用于BSS的操作維護。OML運用X.25協(xié)議。OMCR經(jīng)過Router與BSS相連，在BSS端，操作數(shù)據(jù)在2M線的某些時隙中傳輸，到達Router后，Router中的虛擬交換電路把它們分門別類送往OMCR進展處置。同時OMCR的數(shù)據(jù)也經(jīng)過Router交換后發(fā)往相應(yīng)的NE。能夠引起此類告警的緣由：相關(guān)的MMS口退出效力主用MSI板沒有插數(shù)據(jù)庫中關(guān)于OML鏈路的定義不對DTE地址定義不對路由器定義不對軟件進程問題處理思緒： 假設(shè)OML鏈路從來沒有起來過，那么首先應(yīng)該檢查硬件銜接能否正確，特別是主用的MSI板能否插上了，由于主用MSI板上定

8、義了NE起來時用于從OMCR下載軟件和數(shù)據(jù)庫的OML鏈路。然后核對DTE地址及路由器的設(shè)置能否正確。假設(shè)OML鏈路以前是好的，那么首先要搞清能否有人對OML相關(guān)的參數(shù)改動過，如數(shù)據(jù)庫中關(guān)于OML鏈路的定義、DTE地址、路由器設(shè)置等。在確認沒有改動過后，應(yīng)檢查硬件問題，如MMS口能否退服、MSI板能否缺點等。 參考操作步驟： OML鏈路的問題涉及的設(shè)備比較多，例如：OMCR，路由器，RXCDR等，為了正確定位缺點應(yīng)結(jié)合數(shù)據(jù)搜集來處置問題。進入BSC鍵入state 0 命令查看BSC的形狀；進入RXCDR鍵入state 0 查看RXCDR的OML形狀；在RXCDR鍵入disp_links 查看RX

9、CDR內(nèi)的鏈路銜接，以確定與OML相關(guān)的MMS位置；在出現(xiàn)問題的BSC或RXCDR中鍵入disp_p 0查看哪個GPROC控制OML鏈路；鍵入disp_act_a 0 查看能否有相關(guān)的告警；鍵入disp_eq 0 oml * * 查看每條OML的配置情況。處置步驟進入BSC鍵入state 0 命令查看BSC的形狀；進入控制OML的GPROC；運用msg_send命令；lock/unlock OML，看OML的形狀；再運用msg_send命令；lock/unlock OML所屬的MMS，查看OML的形狀；lock/unlock OML所屬的MSI，查看OML的形狀；假設(shè)OML仍為E-U形狀，繼續(xù)

10、以下步驟。鍵入命令以停頓和激活A(yù)GENT進程，然后lock/unlock此OML鏈路；鍵入命令以停頓和激活A(yù)GENT進程、X.25 PLP進程然后 unlock/lock 此 OML；(10)排除硬件缺點，思索是軟件進程問題呵斥OML缺點，可以思索激活掛OML的GPROC，假設(shè)還是不能處理可以思索reset BSC。2、GCLK無法鎖相的問題 GCLK無法鎖相時會產(chǎn)生GCLK Failed Phase Lock的提示，并能夠伴隨出現(xiàn)4、14、13號等告警。背景原理： GLCK 的功能是使得系統(tǒng)與更準(zhǔn)確的時鐘同步，對于BSS來說，GCLK要與MSC的時鐘同步。時鐘同步的目的是在射頻部分提供0.0

11、5ppmppm為百萬分之一。即如時鐘為16.384M，那么頻率誤差為16.3840.05 = 0.8192Hz 的高精度的時間同步。因此要提供參考時鐘的E1/T1鏈路要盡量減少滑幀和失同步。 GCLK要與上一級時鐘同步必需求有上一級時鐘的參考信號，時鐘參考信號是根據(jù)數(shù)據(jù)庫的定義從指定的MMS口上提取的。在database中需求定義不同MMS口的時鐘提取優(yōu)先等級。 GCLK在任務(wù)時有四種不同的形狀：自在振蕩形狀：此形狀是當(dāng)GCLK剛上電時，其內(nèi)部的晶體振蕩器OCXO需求有預(yù)熱的過程，以堅持其正常的任務(wù)環(huán)境。此時間是固定不變的30分鐘，無法更改。在自在振蕩形狀下，GCLK內(nèi)的DAC輸入為80H，時

12、鐘輸出堅持在0.05ppm的精度內(nèi)。Hold Frequency：此形狀是GLCK與2M失鎖時的形狀。此時GCLK運用前一次ADC輸出的值輸入DAC以控制時鐘，此形狀是一個過渡形狀，普通繼續(xù)10秒。Set Frequency：此形狀普通在Hold Frequency之后。運用LTALong Term Average值輸入DAC以控制時鐘。 正常鎖相任務(wù)時GCLK每30分鐘采樣一個ADC輸出值2位16進制數(shù)，存入內(nèi)部存儲器，存儲器最大可以存放48個值，采用先入先出原那么更新。這48個值也可以被GPROC經(jīng)過MCAP總線讀取或設(shè)置。所謂LTA就是指將這48個值取平均輸入到DAC。Set Frequ

13、ency形狀下，GCLK不再往存儲器中存放新值，只是運用以前的舊值，存儲器停頓更新，這是與鎖相形狀的不同之處。鎖相形狀：此形狀分為兩個子形狀，Acquiring Frequency Lock State，此形狀是一個過渡形狀，由硬件決議。Frequency Lock State，此形狀內(nèi)GCLK已與E1/T1鎖相，但需等待一段時間，以確定鎖相穩(wěn)定之后就進入鎖相形狀。能夠引起此類告警的緣由：因傳輸問題引起MMS退服MSI板或MMS口硬件缺點數(shù)據(jù)庫定義不合理GCLK本身的問題，需求校正或改換 處理思緒： 當(dāng)出現(xiàn)GCLK無法鎖相的告警時首先要搞清楚參考時鐘是從哪里來的。檢查一下數(shù)據(jù)庫中有關(guān)GCLK的

14、參數(shù)設(shè)置能否合理，如鎖相應(yīng)向上鎖，即RXCDR向MSC鎖、BSC向RXCDR鎖、BTS向BSC或上一級的BTS只需菊花鏈的情況鎖，向下一端的MSI口的時鐘提取優(yōu)先級應(yīng)設(shè)為0，另外也不能只允許一個MMS口可以提取時鐘。假設(shè)數(shù)據(jù)庫設(shè)置沒有明顯不合理之處，應(yīng)留意一下與時鐘提取有關(guān)的MMS口和MSI板的形狀，MMS口退服能夠是傳輸問題引起的，也能夠是MSI板或MMS口硬件缺點引起的，假設(shè)MSI板任務(wù)正常那么應(yīng)著重檢查傳輸質(zhì)量。在排除了數(shù)據(jù)庫、MSI硬件和傳輸緣由之后，應(yīng)校正或改換GCLK板。參考操作步驟：為了利于問題的分析應(yīng)搜集以下數(shù)據(jù)：state gclk * * 查看GCLK的形狀disp_el

15、phase_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能否處于正常形狀，能否有E1的相關(guān)告警產(chǎn)生，能否有MMS作為時鐘源。查看提供時鐘的MMS

16、能否與上一級的鏈路銜接，上一級的時鐘能否正常任務(wù)。查看提供時鐘的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)絡(luò)。這是由于MTP第二層出現(xiàn)問題，而退出效力。但系統(tǒng)會不斷嘗試恢復(fù)此鏈路。另外當(dāng)一條MTL鏈路退出效力時，其負荷會分配到其它MTL上，加重其它MTL的負擔(dān)，而由于GPROC的處

17、置才干的緣由，MTL鏈路的平均利用率不能超越30。因此MTL鏈路負擔(dān)過重，會使得GPROC退出效力，從而導(dǎo)致更多的鏈路退出效力。 此告警與BSS 0號告警的區(qū)別為：MTL 0號告警表示一條MTL退出效力，而一個BSS能夠有多條MTL鏈路，BSS 0號告警表示此BSS系統(tǒng)的最后一條MTL鏈路也退出效力，此時BSS完全癱瘓了。能夠引起此類告警的緣由：MSC傳來的MTP第二層LSSU信息出現(xiàn)錯誤。MSC端擁塞超時MSU確認音訊超時序列號出現(xiàn)錯誤SUERM的錯誤門限值超出收到不正常的FIB處理思緒： 先檢查數(shù)據(jù)庫內(nèi)關(guān)于MTL鏈路定義有無問題，然后檢查有關(guān)的MMS口、MSI板能否退出效力，再查與MSC的

18、信令點碼能否正確，在確認上述方面無問題后檢查GPROC能否有硬件問題，必要時復(fù)位該GPROC。參考操作步驟： 根據(jù)告警音訊找到出現(xiàn)問題的站號，MTL的設(shè)備編號。在RXCDR鍵入：disp_links disp_bss_conn 以確定MTL鏈路的銜接情況。鍵入disp_equip 0 MTL * * 得到MTL的配置情況。 查看與MTL相關(guān)的設(shè)備能否正常任務(wù)state 0 mms * * 查看MMS的形狀state 0 msi * * 查看MSI的形狀disp_p 0 查看MTL由那個GPROC控制disp_act_a 0 查看能否有相關(guān)的告警出現(xiàn)了相關(guān)的設(shè)備告警時應(yīng)先處置這些相關(guān)問題。運用l

19、ockunlock、ins命令試著恢復(fù)鏈路。檢查RXCDR或MSC能否在rebooting，等到其正常任務(wù)后再檢查MTL能否恢復(fù)了。在BSC鍵入：disp_ele dpc 0disp_ele opc 0此命令查看MTP的第三層的信令點碼。比較此點碼與MSC處設(shè)置的點碼能否對應(yīng)。找到控制此MTL的GPROC。ins 0 gproc * *如無效那么鍵入：reset_de 0 gproc * * 將BSCreset。4、BSP 239號告警 此告警表示GPROC的平安檢測進程檢測到進程錯誤。背景原理： 平安檢測進程是擔(dān)任對GPROC內(nèi)運轉(zhuǎn)的進程檢查以確定能否運轉(zhuǎn)正常。當(dāng)被檢測的進程沒有呼應(yīng)時就產(chǎn)生

20、此告警。不同功能的GPROC所產(chǎn)生的239號告警表現(xiàn)為：239 BSP 239 BTP 239 DHP 239 BTP (MCU) 平安檢測進程對系統(tǒng)進展周期性的檢測，可以經(jīng)過參數(shù)來調(diào)整檢測的時間間隔。缺省的時間間隔為10分鐘。能夠引起此類告警的緣由：GPROC、BSP、BTP板子損壞被檢測的GPROC、BSP、BTP軟件進程出現(xiàn)錯誤被檢測的硬件出錯GPROC沒插但數(shù)據(jù)庫中作了定義從TCU到BTP的HDLC鏈路能夠出錯BTP的輸入輸出鏈路出錯TCU的運轉(zhuǎn)軟件出錯處理思緒： 首先確定是哪塊GPROC出現(xiàn)239告警，根據(jù)這塊GPROC的功能來確定存在問題的進程或硬件范圍。如BTP 239告警，出現(xiàn)

21、問題的進程能夠運轉(zhuǎn)于MCU，也能夠運轉(zhuǎn)于TCU，還能夠是BTP與TCU的通訊進程。然后檢查相應(yīng)的硬件能否有問題，不能進一步判別緣由所在時，應(yīng)搜集數(shù)據(jù)再作分析。 參考操作步驟：在出現(xiàn)告警的基站鍵入state以確定發(fā)生告警的GPROC、BSP、DHP、BTP的形狀。假設(shè)顯示為B-U，那么鍵入device_audit all 假設(shè)device_audit勝利那么繼續(xù)察看此設(shè)備。假設(shè)device_audit失敗那么鍵入ins 假設(shè)ins失敗，那么進展如下操作，搜集數(shù)據(jù)。假設(shè)出現(xiàn)問題的是BSP，那么經(jīng)過直連或遠程登錄進入GPROC，假設(shè)沒有呼應(yīng)那么能夠為GPROC太忙，TTY進程來不及呼應(yīng)。鍵入disp

22、_mms_ts_usage查看A接口上能否有TCH被分配，假設(shè)有那么搜集GPROC的SWFM和event。假設(shè)沒有那么將GPROC reset，當(dāng)BSC reset后，搜集GPROC的Fatal and Non Fatal SWFMs，以及在告警發(fā)生前和BSC reset后的event。假設(shè)出現(xiàn)問題的不是BSP，那么經(jīng)過直連或遠程登錄進入GPROC，搜集GPROC的Fatal and Non Fatal SWFMs，以及在告警發(fā)生前后的event。 5、IAS 1號告警 IAS 1號告警Serial Bus Connection Failure，多出如今BSC 或RXCDR基站內(nèi)。背景原理：

23、在BSSC機柜中有一塊的告警板，此板的作用為報告熔絲和風(fēng)扇等設(shè)備的告警。此告警板的PL2和PL3銜接到CAGE背板的左上角AI0/AI1口。假設(shè)BSS為兩個CAGE，上面的CAGE普通是不銜接告警線的。數(shù)據(jù)庫定義CAGE 時需求定義告警線能否接到這個CAGE中。disp_eq 0 cage 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

24、which the cage belongs: 0 IAS Connected: YES 最后一項假設(shè)定義為YES，那么軟件嘗試將告警信號送到此CAGE，但是假設(shè)物理上并沒有將告警線銜接到此CAGE，那么會產(chǎn)生IAS 1號告警。普通配置CAFE時都將下面的CAGE定義為銜接告警線，上面的CAGE不銜接。假設(shè)在equip cage時將上面的CAGE也定義了IAS Connected: YES，那么會產(chǎn)生大量的IAS 1告警。能夠引起此類告警的緣由：告警板缺點告警線銜接錯誤數(shù)據(jù)庫定義錯誤告警線損壞處理思緒：先確定告警線銜接在哪個CAGE中，查看數(shù)據(jù)庫中定義的能否與物理銜接相一致。不一致時修正數(shù)據(jù)庫

25、。假設(shè)數(shù)據(jù)庫定義沒有問題，檢查告警板和告警線能否損壞。 參考操作步驟：檢查告警線銜接與數(shù)據(jù)庫中的定義能否相符 假設(shè)不符，運用命令： modify_value 0 ias_connected cage ( # ) yes/no ( # ) cage號檢查告警板能否完好，告警線能否損壞。必要時改換有關(guān)硬件。 6、BSS 22號告警：Trunk Critical Threshold Exceeded 此告警表示被BLOCK的CIC數(shù)目超越了緊急告警門限值。背景原理： CIC是MSC經(jīng)由RXCDR到BSC的陸地電路。XCDRGDP板及內(nèi)部的DSP處置器和MSI板的缺點都會使得CIC的數(shù)目減少。另外由于

26、傳輸?shù)葐栴}也會使得CIC被block，但傳輸恢復(fù)正常后，CIC不一定能自動起來，此時需求人工干涉才干恢復(fù)。能夠引起此類告警的緣由：由于MSI板和MMS口的硬件問題導(dǎo)致可用的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ù)的定義能否合理，假設(shè)MSC端將CIC block，應(yīng)手動將CIC復(fù)位。參考操作步驟：鍵入state 0 msi * * state 0 mms * *disp_act_a 0 disp_act_a 0 檢查MSI，MMS形狀能否正常，能否有相關(guān)的告警。在BSC找到對應(yīng)的銜接到MSC的2M鏈路的MMS板鍵入disp_mms_ts_usage 0 mms * *查看此MMS的各時隙能否有被block的。如發(fā)現(xiàn)大量的CIC被block，首先確定能否為MSC邊將其block的。假設(shè)不是那么運用以下命令將CIC釋放。 先進入BSC 的emon