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

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

GCLK無法鎖相時會產生GCLKFailedPhaseLock的提示，并可能伴隨出現4、14、13號等告警。背景原理：

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

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

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

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

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

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

IAS1號告警——SerialBusConnectionFailure，多出現在BSC或RXCDR基站內。背景原理：

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

IdentifierfortheCAGE:0

KSWpairthatmanagestheCAGE:0

KSWXconnectingcagetoKSWforTDM0:

KSWXconnectingcagetoKSWforTDM1:

Cabinettowhichthecagebelongs:0

IASConnected:YES

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

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

CIC是MSC經由RXCDR到BSC的陸地電路。XCDR（GDP）板及內部的DSP處理器和MSI板的故障都會使得CIC的數目減少。另外由于傳輸等問題也會使得CIC被block，但傳輸恢復正常后，CIC不一定能自動起來，此時需要人工干預才能恢復。可能引起此類告警的原因：①由于MSI板和MMS口的硬件問題導致可用的CIC數目減少②由于E1鏈路的問題，包括傳輸問題，導致CIC數目減少③由于RXCDR中GDP、XCDR板的DSP處理器出現問題使得CIC數目減少④MSI、XCDR、GDP板可能被人為lock了⑤database中關于此告警的門限值設置得太低解決思路：首先查硬件問題，如E1連接是否正常，MSI、XCDR、GDP板是否有問題，有沒有被LOCK，再檢查是否因傳輸問題而使MMS口退服。同時應注意一下數據庫中有關參數的定義是否合理，如果MSC端將CICblock，應手動將CIC復位。參考操作步驟：⑴鍵入state0msi**state0mms**

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

disp_elementcic_error_gen_threshold0查看cic告警的門限值。如發現設置過低，使用

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