BSC告警分析課件

BSC/RXCDR/PCU告警分析內(nèi)容簡介告警格式與組成告警處理的優(yōu)先級別常見的BSS告警告警的格式與組成告警的種類和格式告警可以分為硬件告警和軟件告警兩種：硬件告警是由于BSS內(nèi)的硬件故障所引起的告警。軟件告警是由GPROC檢測到軟件進(jìn)程運(yùn)行出錯所引起的告警。只有GPROC設(shè)備（BSP，CSFP，DHP，BTP，poolGPROC）才會產(chǎn)生軟件告警息。軟件告警（SoftwareFaultManagement或SWFM）分為兩類。告警的類型告警編號對于每種設(shè)備都有唯一的一個十進(jìn)制數(shù)表示。每種設(shè)備的告警編號從0到254。對于不同的設(shè)備告警編號可能重復(fù)，但與設(shè)備相關(guān)的編號是唯一的。有些情況下同樣的告警編號表示類似的告警。例如254號告警表示設(shè)備fail。在OMC-R上將告警分成不同的六種類型，可以在OMCR的告警說明中找到“FailureEvents”字段，其為不同類型告警的名稱。它們分別是：告警的等級告警嚴(yán)重級別表明此故障發(fā)生對系統(tǒng)的影響程度，系統(tǒng)將告警的等級分為六級：告警處理的優(yōu)先級我們可以根據(jù)告警的嚴(yán)重級別，以及出現(xiàn)告警的網(wǎng)元在系統(tǒng)中的重要性，對不同的告警情況進(jìn)行相應(yīng)的處理。在此我們提供一般原則下的優(yōu)先級別。對于基站來說從RXCDR到BSC，再到BTS；信令鏈路按照MTL、RSL、XBL的次序；告警嚴(yán)重級別由高到低分別是Critical、Major、Minor、Warning、Investigate、Clear。在相同的告警級別中，Critical告警按照以下順序AllRXCDR-AllMTL-AllBSC-AllRSL-AllBTS-AllX.25link-AllotherCriticalalarms。Major告警按照以下順序AllRXCDR-AllBSC-AllBTS-AllotherMajoralarms。其它告警按照Minor、Warning、Investigate、Clearalarms的順序進(jìn)行處理。常見的BSS告警1、OML為E-U或D-U的問題在BSC或RXCDR看到此現(xiàn)象時(shí)，還可能看到相關(guān)的一些告警，如OML242號告警等。背景原理：

OML鏈路是OMCR到RXCDR或BSC的信令鏈路，主要用于BSS的操作維護(hù)。OML使用X.25協(xié)議。OMCR通過Router與BSS相連，在BSS端，操作數(shù)據(jù)在2M線的某些時(shí)隙中傳輸，到達(dá)Router后，Router中的虛擬交換電路把它們分門別類送往OMCR進(jìn)行處理。同時(shí)OMCR的數(shù)據(jù)也通過Router交換后發(fā)往相應(yīng)的NE?？赡芤鸫祟惛婢脑颍孩傧嚓P(guān)的MMS口退出服務(wù)②主用MSI板沒有插③數(shù)據(jù)庫中關(guān)于OML鏈路的定義不對④DTE地址定義不對⑤路由器定義不對⑥軟件進(jìn)程問題解決思路：如果OML鏈路從來沒有起來過，那么首先應(yīng)該檢查硬件連接是否正確，特別是主用的MSI板是否插上了，因?yàn)橹饔肕SI板上定義了NE起來時(shí)用于從OMCR下載軟件和數(shù)據(jù)庫的OML鏈路。然后核對DTE地址及路由器的設(shè)置是否正確。如果OML鏈路以前是好的，那么首先要搞清是否有人對OML相關(guān)的參數(shù)改動過，如數(shù)據(jù)庫中關(guān)于OML鏈路的定義、DTE地址、路由器設(shè)置等。在確認(rèn)沒有改動過后，應(yīng)檢查硬件問題，如MMS口是否退服、MSI板是否故障等。處理步驟⑴進(jìn)入BSC鍵入state0命令查看BSC的狀態(tài)；⑵進(jìn)入控制OML的GPROC；⑶運(yùn)用msg_send命令；⑷lock/unlockOML，看OML的狀態(tài)；⑸再運(yùn)用msg_send命令；⑹lock/unlockOML所屬的MMS，查看OML的狀態(tài)；⑺lock/unlockOML所屬的MSI，查看OML的狀態(tài)；如果OML仍為E-U狀態(tài)，繼續(xù)以下步驟。⑻鍵入命令以停止和激活A(yù)GENT進(jìn)程，然后lock/unlock此OML鏈路；⑼鍵入命令以停止和激活A(yù)GENT進(jìn)程、X.25PLP進(jìn)程然后unlock/lock此OML；(10)排除硬件故障，考慮是軟件進(jìn)程問題造成OML故障，可以考慮激活掛OML的GPROC，如果還是不能解決可以考慮resetBSC。2、GCLK無法鎖相的問題

GCLK無法鎖相時(shí)會產(chǎn)生GCLKFailedPhaseLock的提示，并可能伴隨出現(xiàn)4、14、13號等告警。背景原理：

GLCK的功能是使得系統(tǒng)與更準(zhǔn)確的時(shí)鐘同步，對于BSS來說，GCLK要與MSC的時(shí)鐘同步。時(shí)鐘同步的目的是在射頻部分提供0.05ppm（ppm為百萬分之一。即如時(shí)鐘為16.384M，則頻率誤差為16.384×0.05=0.8192Hz）的高精度的時(shí)間同步。因此要提供參考時(shí)鐘的E1/T1鏈路要盡量減少滑幀和失同步。

GCLK要與上一級時(shí)鐘同步必須要有上一級時(shí)鐘的參考信號，時(shí)鐘參考信號是根據(jù)數(shù)據(jù)庫的定義從指定的MMS口上提取的。在database中需要定義不同MMS口的時(shí)鐘提取優(yōu)先等級。

GCLK在工作時(shí)有四種不同的狀態(tài)：①自由振蕩狀態(tài)：此狀態(tài)是當(dāng)GCLK剛上電時(shí)，其內(nèi)部的晶體振蕩器（OCXO）需要有預(yù)熱的過程，以保持其正常的工作環(huán)境。此時(shí)間是固定不變的（30分鐘），無法更改。在自由振蕩狀態(tài)下，GCLK內(nèi)的DAC輸入為80H，時(shí)鐘輸出保持在0.05ppm的精度內(nèi)。②HoldFrequency：此狀態(tài)是GLCK與2M失鎖時(shí)的狀態(tài)。此時(shí)GCLK使用前一次ADC輸出的值輸入DAC以控制時(shí)鐘，此狀態(tài)是一個過渡狀態(tài)，一般持續(xù)10秒?？赡芤鸫祟惛婢脑颍孩僖騻鬏攩栴}引起MMS退服②MSI板或MMS口硬件故障③數(shù)據(jù)庫定義不合理④GCLK本身的問題，需要校正或更換解決思路：當(dāng)出現(xiàn)GCLK無法鎖相的告警時(shí)首先要搞清楚參考時(shí)鐘是從哪里來的。檢查一下數(shù)據(jù)庫中有關(guān)GCLK的參數(shù)設(shè)置是否合理，如鎖相應(yīng)向上鎖，即RXCDR向MSC鎖、BSC向RXCDR鎖、BTS向BSC或上一級的BTS（只有菊花鏈的情況）鎖，向下一端的MSI口的時(shí)鐘提取優(yōu)先級應(yīng)設(shè)為0，另外也不能只允許一個MMS口可以提取時(shí)鐘。如果數(shù)據(jù)庫設(shè)置沒有明顯不合理之處，應(yīng)注意一下與時(shí)鐘提取有關(guān)的MMS口和MSI板的狀態(tài)，MMS口退服可能是傳輸問題引起的，也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常則應(yīng)著重檢查傳輸質(zhì)量。在排除了數(shù)據(jù)庫、MSI硬件和傳輸原因之后，應(yīng)校正或更換GCLK板。參考操作步驟：⑴為了利于問題的分析應(yīng)收集以下數(shù)據(jù)：①state<location>gclk**（查看GCLK的狀態(tài)）②disp_elphase_lock_gclk<location>（查看是否允許鎖相）③disp_eq0mms<id1><id2><id3>（查看MMS的參數(shù)，主要是時(shí)鐘提取優(yōu)先級）④disp_elwait_for_reselection<location>（查看時(shí)鐘提取切換時(shí)間）⑤disp_ellta_alarm_range<location>（查看LTA告警范圍）⑥disp_gclk_avgs<location><gclk_id>（查看GCLK的長期平均值）⑦disp_eq<location>gclk<id_1><id_2><id_3>full（查看GCLK硬件版本信息）⑵當(dāng)GCLK無法鎖相時(shí)可采用以下的方法：①reattempt_pl<location><gclk_id1>②使用lock/unlock命令看是否能使得GCLK鎖相恢復(fù)。③查看MSI，MMS是否處于正常狀態(tài)，是否有E1的相關(guān)告警產(chǎn)生，是否有MMS作為時(shí)鐘源。④查看提供時(shí)鐘的MMS是否與上一級的鏈路連接，上一級的時(shí)鐘是否正常工作。⑤查看提供時(shí)鐘的MMS的等級是否設(shè)置正確（一般為255）。⑥試著使用其它的MMS作為時(shí)鐘源。（對于M-CELL可更換NIU）?？赡芤鸫祟惛婢脑颍孩費(fèi)SC傳來的MTP第二層LSSU信息出現(xiàn)錯誤。②MSC端擁塞超時(shí)③MSU確認(rèn)消息超時(shí)④序列號出現(xiàn)錯誤⑤SUERM的錯誤門限值超出⑥收到不正常的FIB解決思路：先檢查數(shù)據(jù)庫內(nèi)關(guān)于MTL鏈路定義有無問題，然后檢查有關(guān)的MMS口、MSI板是否退出服務(wù)，再查與MSC的信令點(diǎn)碼是否正確，在確認(rèn)上述方面無問題后檢查GPROC是否有硬件問題，必要時(shí)復(fù)位該GPROC。參考操作步驟：⑴根據(jù)告警消息找到出現(xiàn)問題的站號，MTL的設(shè)備編號。⑵在RXCDR鍵入：disp_linksdisp_bss_conn

以確定MTL鏈路的連接情況。⑶鍵入disp_equip0MTL**得到MTL的配置情況。⑷查看與MTL相關(guān)的設(shè)備是否正常工作state0mms**查看MMS的狀態(tài)state0msi**查看MSI的狀態(tài)disp_p0查看MTL由那個GPROC控制disp_act_a0查看是否有相關(guān)的告警出現(xiàn)了相關(guān)的設(shè)備告警時(shí)應(yīng)先處理這些相關(guān)問題。⑸使用lock／unlock、ins命令試著恢復(fù)鏈路。⑹檢查RXCDR或MSC是否在rebooting，等到其正常工作后再檢查MTL是否恢復(fù)了。⑺在BSC鍵入：disp_eledpc0disp_eleopc0此命令查看MTP的第三層的信令點(diǎn)碼。比較此點(diǎn)碼與MSC處設(shè)置的點(diǎn)碼是否對應(yīng)。⑻找到控制此MTL的GPROC。ins0gproc**如無效則鍵入：reset_de0gproc**⑼將BSC

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

<device_id1><device_id2><device_id3>⑶如果device_audit成功則繼續(xù)觀察此設(shè)備。如果device_audit失敗則鍵入ins<location><device_name><devid><dev_id><dev_id>如果ins失敗，則進(jìn)行如下操作，收集數(shù)據(jù)。Ⅰ如果出現(xiàn)問題的是BSP，則通過直連或遠(yuǎn)程登錄進(jìn)入GPROC，如果沒有響應(yīng)則可能為GPROC太忙，TTY進(jìn)程來不及響應(yīng)。鍵入disp_mms_ts_usage查看A接口上是否有TCH被分配，如果有則收集GPROC的SWFM和event。如果沒有則將GPROCreset，當(dāng)BSCreset后，收集GPROC的FatalandNonFatalSWFMs，以及在告警發(fā)生前和BSCreset后的event。Ⅱ如果出現(xiàn)問題的不是BSP，則通過直連或遠(yuǎn)程登錄進(jìn)入GPROC，收集GPROC的FatalandNonFatalSWFMs，以及在告警發(fā)生前后的event。5、IAS1號告警

IAS1號告警——SerialBusConnectionFailure，多出現(xiàn)在BSC或RXCDR基站內(nèi)。背景原理：

在BSSC機(jī)柜中有一塊的告警板，此板的作用為報(bào)告熔絲和風(fēng)扇等設(shè)備的告警。此告警板的PL2和PL3連接到CAGE背板的左上角AI0/AI1口。如果BSS為兩個CAGE，上面的CAGE一般是不連接告警線的。數(shù)據(jù)庫定義CAGE時(shí)需要定義告警線是否接到這個CAGE中。disp_eq0cage00

IdentifierfortheCAGE:0

KSWpairthatmanagestheCAGE:0

KSWXconnectingcagetoKSWforTDM0:

KSWXconnectingcagetoKSWforTDM1:

Cabinettowhichthecagebelongs:0

IASConnected:YES

最后一項(xiàng)如果定義為YES，則軟件嘗試將告警信號送到此CAGE，但是如果物理上并沒有將告警線連接到此CAGE，則會產(chǎn)生IAS1號告警。一般配置CAFE時(shí)都將下面的CAGE定義為連接告警線，上面的CAGE不連接。如果在equipcage時(shí)將上面的CAGE也定義了IASConnected:YES，則會產(chǎn)生大量的IAS1告警。6、BSS22號告警：TrunkCriticalThresholdExceeded

此告警表示被BLOCK的CIC數(shù)目超過了緊急告警門限值。背景原理：

CIC是MSC經(jīng)由RXCDR到BSC的陸地電路。XCDR（GDP）板及內(nèi)部的DSP處理器和MSI板的故障都會使得CIC的數(shù)目減少。另外由于傳輸?shù)葐栴}也會使得CIC被block，但傳輸恢復(fù)正常后，CIC不一定能自動起來，此時(shí)需要人工干預(yù)才能恢復(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口退服。同時(shí)應(yīng)注意一下數(shù)據(jù)庫中有關(guān)參數(shù)的定義是否合理，如果MSC端將CICblock，應(yīng)手動將CIC復(fù)位。參考操作步驟：⑴鍵入state0msi**state0mms**

disp_act_a0disp_act_a0檢查MSI，MMS狀態(tài)是否正常，是否有相關(guān)的告警。⑵在BSC找到對應(yīng)的連接到MSC的2M鏈路的MMS板鍵入disp_mms_ts_usage0mms**查看此MMS的各時(shí)隙是否有被block的。如發(fā)現(xiàn)大量的CIC被block，首先確定是否為MSC邊將其block的。如果不是則使用以下命令將CIC釋放。先進(jìn)入BSC的emon提示符下，鍵入以下命令 msg_s64399990f0eh0eh01h00xx030h02h00h01h其中xx---CICnumber⑶使用以下命令檢查關(guān)于告警的門限值。

disp_elementcic_error_gen_threshold0查看cic告警的門限值。如發(fā)現(xiàn)設(shè)置過低，使用

chg_elementcic_error_gen_threshold<value>0調(diào)整cic告警門限值。7、GPROC254號告警此告警表示一個GPROC或BTP退出服務(wù)。背景原