無線內部培訓講義BSC告警和告警處理課件

MOTGSM無線設備培訓

——BSC告警和告警處理——中國聯(lián)通有限公司廣州分公司·覃道滿MOTGSM無線設備培訓

——BSC告警和告警處理——中國1學習目標掌握告警格式與組成23熟悉告警處理流程學習目標掌握告警格式與組成23熟悉告警處理流程學習內容告警格式和組成

告警處理流程

BSC非正常重啟分析

學習內容告警格式和組成簡述機房運行維護人員經常會碰到告警，有些告警是操作維護過程中自然產生的，有些告警是瞬時性的，不會影響系統(tǒng)正常運行，但大多數告警是會影響系統(tǒng)性能的，有的甚至會導致BSS復位，對移動通信系統(tǒng)造成嚴重影響。因此對于運維人員來說，了解告警系統(tǒng)，掌握一定的告警分析和處理技能，顯得非常重要。告警系統(tǒng)是為了故障定位，系統(tǒng)性能分析及方便維護而設置的。告警信息可以在OMCR的告警窗口上顯示，也可以在本地維護終端（LMT）上顯示。BSS產生的告警信息，以字符的形式發(fā)往OMCR。簡述機房運行維護人員經常會碰到告警，有些告警是操作維護過程中告警的種類和格式告警可以分為硬件告警和軟件告警兩種：硬件告警是由于BSS內的硬件故障所引起的告警。軟件告警是由GPROC檢測到軟件進程運行出錯所引起的告警只有GPROC設備（BSP，CSFP，DHP，BTP，poolGPROC）才會產生軟件告警信息。

告警的種類和格式告警可以分為硬件告警和軟件告警兩種：告警舉例#0

–

NEW

–

*NONE*.

CommuncationFailureEvent-CAGE-BSS01(BSS01:SITE-0:):0CAGE1-30/03/199914:23:56.

[18]ExpansionKSWXSlot22CommunicationFailure-FMIC-Major--/-.

(BSS01:SITE-0:):0SITEImpactedtoMajor.

告警舉例#0–NEW–*NONE*.告警解析#0：告警IDNEW：告警狀態(tài)NONE：正在處理此告警的人員CommuncationFailureEvent：告警的類型CAGE：告警級BSS01(BSS01:SITE-0:):0CAGE1：發(fā)生告警的位置30/03/199914:23:56：告警發(fā)生時間[18]：告警編號ExpansionKSWXSlot22(見框架配置表)CommunicationFailure：告警描述FMIC：告警的清除類型Major：告警嚴重等級(主要告警)(BSS01:SITE-0:):0SITEImpactedtoMajor:告警附加信息

告警解析#0：告警ID附:BSC機框配置圖附:BSC機框配置圖告警編號告警編號對于每種設備都有唯一的一個十進制數表示。每種設備的告警編號從0到254。(見附錄)對于不同的設備告警編號可能重復，但與設備相關的編號是唯一的。有些情況下同樣的告警編號表示類似的告警。例如242號告警表示設備退出服務(MMS\MTL\RSL)。

告警編號告警編號對于每種設備都有唯一的一個十進制數表示。每種告警消除類型告警的清除類型可分為三類：IntermittentFaultManagementInitiatedClear（FMIC）OperatorInitiatedClear（OIC）

Intermittent表示告警是偶發(fā)性的，對系統(tǒng)沒有危害。此告警發(fā)生后在OMCR會自動消除。當此類告警頻繁產生時，會增加OML鏈路的負荷。我們可以使用disp_throttle命令來查看告警門限設置，還可用chg_throttle命令調節(jié)其門限值。

FMIC告警的清除由系統(tǒng)的錯誤管理進程（FaultManagermentProcess）自動進行。FM進程管理一張現(xiàn)有告警的列表，只有當告警產生的原因消失后FM才會產生‘clear’消息將此告警從告警列表中刪除。

OIC需要由操作人員手動將告警清除。FM進程檢測到告警產生并判斷為OIC類型時，將此告警加入現(xiàn)有告警列表中。此后FM不再進行任何處理。當操作人員將告警產生的原因解決后，必須將此告警清除。告警消除類型告警的清除類型可分為三類：清除告警步驟在OMCR和BSC上均能夠清除告警。OMCR上清除告警按以下步驟進行：打開告警窗口，單擊鼠標左鍵選中要清除的告警項

單擊鼠標右鍵彈出快捷菜單

選擇快捷菜單的“Handle”

選擇快捷菜單的“Clear”確認告警已被清除

在BSS上清除告警，先使用disp_act_alarm命令查看有哪些OIC告警。然后使用del_act_alarm命令將告警清除。清除命令如下:del_act_alarm<location><device_name><dev_id1><dev_id2><dev_id3><alarm_code>(只對OIC告警)清除告警步驟在OMCR和BSC上均能夠清除告警。OMCR上清告警的類型

OMCR將告警分成六種不同的類型，可以在OMCR的告警說明中找到"FailureEvents"字段，其為不同類型告警的名稱。告警的類型OMCR將告警分成六種不同的類型，可以在O附:告警類型表

類型含義舉例Communication數據從一點傳到另一點時發(fā)生錯誤而產生的告警一般當信令丟失或呼叫建立出錯時發(fā)生此種告警1、mmssynloss2、frameslipdaily3、biterror4、dri-ctuactivelinkcommunicationfailure(critical)QualityofService系統(tǒng)的服務質量下降時產生此告警一般當消息響應超時或帶寬減少時會發(fā)生此種告警：多見于時鐘失鎖gclk_mcufphaselockfailure（major）Processing當軟件或進程出現(xiàn)錯誤時產生此告警一般當進程數據被破壞或系統(tǒng)內存溢出時產生此種告警dri-CTUchannelcoderinternalmessageerror—intermittent(warning)Equipment當硬件出錯時產生此告警。一般當出現(xiàn)配置錯誤，傳輸、電源等問題時產生此種告警dristandbylinkcommunicationfailure(minor)Environment當設備所處的環(huán)境不利于正常工作時產生告警一般當出現(xiàn)煙霧，火光被檢測到時產生此種告警Link當OMCR與BSS間的X.25鏈路出現(xiàn)問題時產生此告警

附:告警類型表類型含義舉例Communication數據告警的等級

影響行動舉例嚴重(Critical)已經影響了系統(tǒng)的服務應該立即采取措施當系統(tǒng)的某一功能出現(xiàn)此種告警而退出服務，應立即將其恢復。重大(Major)已經影響了系統(tǒng)的服務應該馬上采取措施系統(tǒng)的服務容量降低，此時應采取措施恢復容量。較輕(Minor)此錯誤不會對系統(tǒng)的服務造成影響應采取措施減少更多的此類告警產生當此種告警數量不斷增加時，系統(tǒng)的容量可能受到影響。警告(Waring)潛在產生影響系統(tǒng)服務的告警的可能如果必要應該進行必要的分析，采取措施避免產生更嚴重的告警

清除(Clear)告警已經被清除無

待定(Investigate)表明此錯誤的等級無法確定，需要人工進一步分析進一步查找原因

告警的等級

影響行動舉例嚴重已經影響了系統(tǒng)的服務應發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM按鈕

在OMCR桌面圖形界面GUI上雙擊告警按鈕，打開告警窗口，可以看到所有網元（NE）的告警信息；第二種方法：通過GUI上的EVENTMANEGMENT

點擊GUI上的EVENTMAMT按鈕，打開DisplaySubscriptionList窗口，選擇窗口中告警中的一項，選擇open按鈕就打開告警窗口；第三種方法：打開MAP圖，然后選中對應的單元節(jié)點

從NETWORKMAP上查看告警，單擊GUI上的NETWORKMAP按鈕，打開MAPLIST窗口，選定其中的一個網元，雙擊鼠標左鍵打開MAP窗口，在MAP圖上用鼠標左鍵點擊要查看的網絡單元節(jié)點，選中后接點會變?yōu)樽仙?，單擊鼠標右鍵在快捷菜單內選擇ALARM項，此時會出現(xiàn)告警窗口顯示此節(jié)點單元的所有告警。用disp_act_alarm命令行查看告警.發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM告警處理優(yōu)先級別我們可以根據告警的嚴重級別，以及出現(xiàn)告警的網元在系統(tǒng)中的重要性，對不同的告警情況進行相應的處理。在此我們提供一般原則下的優(yōu)先級別。對于基站來說從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的順序進行處理。告警處理優(yōu)先級別我們可以根據告警的嚴重級別，以及出現(xiàn)告警的網附:告警優(yōu)先級別圖告警處理優(yōu)先級別:Thesites

RemoteTranscoder(RXCDR)

BaseStationController(BSC)

BaseTransceiverStation(BTS)Thelinks

MessageTransferpartLink(MTL)

RadioSignallingLink(RSL)

X.25link

Critical告警按照以下順序：

AllRXCDR-Criticalalarms

AllMTL-Criticalalarms

AllBSC-Criticalalarms

AllRSL-Criticalalarms

AllBTS-Criticalalarms

AllX.25link-Criticalalarms

AllotherCriticalalarms

附:告警優(yōu)先級別圖告警處理優(yōu)先級別:ThesitesCr設備之間的從屬關系（parent-child）當某個設備或鏈路處于OOS等非正常狀態(tài)時，不僅與起本身相關，而且與其上一級（parent）設備有關，對parent設備進行進行必要的處理是解決問題的重要手段。如果某個設備處于OOS等狀態(tài)下，此設備下一級（child）設備將也不能正常工作。Device1stparentdev2ndparentdev3rdparentdev4thparentdevRSLMMSMSICAGECABSITEBSSMTLMMSMSICAGECABSITEBSSOMLMMSMSI

TCUDRICABSITEBSS

XBLMMSMSICAGECABSITEBSS設備之間的從屬關系（parent-child）告警處理的流程

查看告警分清告警的級別明確與告警有關的設備根據告警手冊或經驗對告警進行處理解決問題，消除告警

告警處理的流程查看告警常見告警及其處理辦法常見告警及其處理方法.doc常見告警及其處理辦法常見告警及其處理方法.docBSC非正常重啟分析BSC在網絡中的位置和作用重啟分類原因分析實例分析BSC日常維護應注意的事項BSC穩(wěn)定運行的條件BSC非正常重啟分析BSC在網絡中的位置和作用BSC在網絡中的位置和作用在GSM無線通信系統(tǒng)中，BSC作為基站控制器，是BSS子系統(tǒng)的關鍵節(jié)點，一套BSC管理幾十個基站和GPRS網絡關鍵節(jié)點PCU。BSC同時作為GSM語音業(yè)務和GPRS數據業(yè)務的無線關鍵設備，其作用可歸納為：無線管理、電路交換和接續(xù)以及協(xié)議轉換。BSC重啟，即BSC退出服務的過程，將中斷BSS子系統(tǒng)目前正在進行的工作，受該BSC所控制的語音業(yè)務和數據業(yè)務將不能提供服務，影響相當嚴重。BSC在網絡中的位置和作用在GSM無線通信系統(tǒng)中，BSC作附:BSC在網絡中的位置圖BSC在網絡中的位置:MSCXCDRBSCBTS2BTS1PCUSGSNGPRSGSM附:BSC在網絡中的位置圖BSC在網絡中的位置:MSCXCD重啟原因分類系統(tǒng)因故障自動重啟人為操作導致系統(tǒng)重啟重啟原因分類系統(tǒng)因故障自動重啟重啟原因分析機房環(huán)境和動力。BSC硬件故障。各種LINK的故障。總線的Failured。BSC軟件故障。改變數據庫和參數設置。重啟原因分析機房環(huán)境和動力。機房環(huán)境和動力主要是頻繁出現(xiàn)高溫告警，或灰塵比較大，或電源供給中斷或不穩(wěn)定造成的。高溫或灰塵比較大的時候，對那些運行時間已比較長的設備威脅比較大，當某個芯片因灰塵積累得比較多而又散熱不充分時，芯片有可能因過熱被燒毀，芯片所在的插板將會退出服務，當系統(tǒng)容錯機制失效時，為了排除故障，系統(tǒng)將不可避免地自動重啟，若系統(tǒng)不能自己排除故障，在人為干預之前，系統(tǒng)將會一直處于重啟狀態(tài)。機房環(huán)境和動力主要是頻繁出現(xiàn)高溫告警，或灰塵比較大，或電源BSC硬件故障這里說的硬件主要是插在BSC機框中的各種插板，每個插板的功能不同，出現(xiàn)故障時對整個BSC的影響也是不同的。從機框的背板到插槽上的每一塊插板的故障都有可能導致系統(tǒng)退出服務，特別是系統(tǒng)不能識別故障板件時，重啟將不可避免地發(fā)生，其中GPROC（處理器板）、GCLK（時鐘）、LANx和KSWx（時隙交換擴展板），因數量多或作用關鍵，出現(xiàn)故障時容易引起B(yǎng)SC的重啟。這其中又以時鐘板最為重要。BSC硬件故障這里說的硬件主要是插在BSC機框中的各種插板各種LINK的故障與BSC相連的LINK有MTL、RSL、OML、XBL、GSL。對BSC影響最大的是MTL和GSL兩種鏈路，有可能導致BSC自動重啟或BSC中有死進程存在，有死進程時系統(tǒng)運行將非常緩慢，命令無法執(zhí)行，需要人為重啟BSC來清除。各種LINK的故障與BSC相連的LINK有MTL、RSL、總線的Failured(1)PBUS：PBUS即ProcessorBus，它是MCAP總線在軟件上的一種表示，負責GPROC與其他大的插板（XCDR、GCLK、KSW、DRI）之間的通信。PBUSDeviceFailured的原因可能是：①LANx板Faulty；

③某塊板件故障。②可能是FTP（故障傳輸部分）和FCP（故障收集部分）之間的錯誤引起的。第三種情況屬于軟件故障，需要人為重啟BSC來重啟這兩個進程?？偩€的Failured(1)PBUS：PBUS即Proce總線的Failured(2)SBUS：SBUS即SerialBus,它上面的通信由GPROC控制，主要負責GPROC與小插板板（如LANx、KSWx、CLKx）之間的通信。每個機框的SBUS也是一主一備的，但它們被分配不同的任務，Standby不享有ActiveSBUS的功能。 當SBUSfailured后，BSC有可能會重啟，部分故障不會引起重啟。重啟結束后，如果SBUS仍然是不可用狀態(tài)，那么就必須去檢查具體原因了。SBUS有故障時，必須考慮所有被主GPROC控制的SBUS上的通信。導致SBUSFailured的原因有以下幾種可能：①LANx插板沒有插到位，與背板的連接不正確，或光纖沒有連接好或連接了錯誤的光纖。②LANx插板Failured。③GPROC板Failured，導致SBUS上的通信不正常。④BTC板不能給背板供電?？偩€的Failured(2)SBUS：SBUS即Seria總線的Failured(3)TBUS：TBUS即TDMBUS。它由KSW控制，每對KSW為系統(tǒng)提供1024個交換時隙，分配給其它大的插板如GPROC、MSI、XCDR、KSW使用，時隙可擴展和擴容。在TDM高速總線故障的情況下，系統(tǒng)的主用TBUS將會退出服務，系統(tǒng)將要求TDMhighway做倒換，進而將會使所有機框里的的TBUS一起做倒換，如果此時備用的TBUS不可用，倒換將不能成功，機框將會退出服務，系統(tǒng)將會要求整個BSC重啟。引起TBUSFailured的原因可能如下：①連接本地與遠端KSWx的光纖有問題，或者斷了。②KSWx插板Failured。③KSW插板故障或不可用?？偩€的Failured(3)TBUS：TBUS即TDMB總線的Failured(4)CBUS：CBUS即ClockDistributionBus，通過此總線系統(tǒng)將時鐘信號傳送到機框背板。給各種大的插板GPROC、KSW、MSI、XCDR等插板提供時鐘，CBUS在整個系統(tǒng)一主一備的。當主用的CBUS有故障時，系統(tǒng)會自動倒換到備用的CBUS，當然備用的CBUS在此時是必須可用的。當備用的CBUS不可用而系統(tǒng)倒換時，BSC將重啟。引起CBUSDisabled的原因可能如下：①GCLK板硬件故障。②擴展時鐘信號的光纖有問題。③擴展時鐘信號的KSWx插板和CLKx插板故障?？偩€的Failured(4)CBUS：CBUS即ClockBSC軟件故障GPROC的內存問題。我們知道，GPROC在BSC中處于相當重要的位置是因為它擔任了控制處理功能，GPROC的CUP也有一定的工作極限，當用作BSP的GPROC的CPU使用率達到100%，出現(xiàn)BSP[239]processsafetestauditfailure(檢測不到BSP板)告警，此時軟件故障可以稱為進程吊死。遇到這種告警時，需要在BSC現(xiàn)場關掉OML，即將Slot16、Slot14板開關下置為“disable”，重啟BSC。為了節(jié)省故障恢復時間，可進入第3層，等待出現(xiàn)[waitingforOMC-R]的提示時輸入如下命令：Msg_send800001978h---跳過從OMC-R下載數據以加快啟動過程。導致BSC重啟的原因是因為BSC的SSM與BTS的CRM間通信量太大，使得產生的SMSWFMs過多所致。最直接的原因是基站的業(yè)務量太大，TCH擁塞所致。通過調整cp_messages.cSWFMs的量，可以解決此問題。為了減少此類故障的發(fā)生，建議用處理能力更強大的GPROC3做BSP，減少重啟的可能，當BSP負荷很高時，可以考慮設置單獨的OMF，把OML分離出去，降低BSP的負荷。在系統(tǒng)話務忙時避免執(zhí)行大批量的命令，也可減少BSP重啟的機會。降低單個GPROC的負荷，避免某個GPROC因負荷太大時自動重啟后，負荷被其它GPROC分擔后出現(xiàn)多米諾骨牌效應，最終導致整個BSC重啟的悲劇的發(fā)生。有時侯內存并沒有問題而是當使用內存時GPROC被locked了。這時可有三種方法來處理：①將此可能故障的GPROC（BSP）與其它的GPROC交換，即使此GPROC再次重啟，也不會使BSC重啟。②換一塊好的GPROC。③UNLOCKGPROCBSC軟件故障GPROC的內存問題。我們知道，GPROC在改變數據庫和參數設置有時數據庫某些參數做了改動后也需要BSC重啟，才能正常工作或發(fā)生作用，特別是一些影響基站正常工作的參數，平時不要隨意改動。另外還有可能因為本身新版本軟件的缺陷也會偶爾出現(xiàn)問題，需要使BSC重啟。改變數據庫和參數設置有時數據庫某些參數做了改動后也需要BS事例分析(1)BSC的3個GPROCs(0116,0117,0118)在不同時間自動reset，造成BSCreset。 解決：從收集的數據發(fā)現(xiàn)MTL不穩(wěn)定，時好時壞，有告警產生。CA向GPROC發(fā)送fast_reset,將GPROCreset。 因為GPROC控制的MTL和RSL負荷過大，使得MTL時好時壞。當一條MTL斷了，造成其超負荷，就會使得其他MTL退出服務。這時可檢查此MTL的統(tǒng)計數據，或檢查PGROC的CPU的使用率。 因為處理能力的限制使得他們拒絕更多的消息進入。建議用戶重新配置BSC的容量;如某MSC下只有某BSC范圍電話難打，可考慮reset_sitebsc;如只有部分RSL負荷過大，造成電話難大打，可reassignlcf。事例分析(1)BSC的3個GPROCs(0116,0117事例分析(2)Disable第二個GPROC后BSCreboot

解決：分析發(fā)現(xiàn)：發(fā)現(xiàn)GCLK退出服務，使得BSCreset。因此使得BSCreset的原因不是lockGPROC。而是GCLK的故障產生的，及時處理GCLK的問題，以防再次ResetBSC。事例分析(2)Disable第二個GPROC后BSCreBSC日常維護的注意事項(1)更換MSI板時，先用命令查看MSI板的工作狀態(tài)，如果是未閉鎖狀態(tài)，則應該先將插板閉鎖，替換后再解鎖，避免在未閉鎖狀態(tài)下直接操作。GPROC板出現(xiàn)故障或告警需要拔出時，應該先重啟此GPROC，確認GPROC不能恢復正常，再將GPROC的面板上的按鍵撥到Disable，再操作。GCLK板出現(xiàn)問題且需更換時，先倒換到備用GCLK，將面板上的按鍵撥到Disable后再操作。安裝扳子要到位，要確保插板與背板能連接正確，這樣插板才能正常工作，也不會影響與其他插板之間的通信。BSC日常維護的注意事項(1)更換MSI板時，先用命令查看BSC日常維護的注意事項(2)要注意光纖的清潔，特別是與半尺寸板連接的光纖，如果光纖不干凈也會導致插板Disabled，成為系統(tǒng)隱患。機柜和各種插板應定期按照規(guī)范進行清洗和除塵。一些GCLK、LANx、KSW等設備的告警和某些死進程可能會使GPROC退出服務，特別注意GPROC245號告警，此告警表示一個GPROC或BTP退出服務。如果主用的BSP出現(xiàn)此告警時，BSC已經重啟了。如果一般的GPROC出現(xiàn)此告警，該板會重啟，并會影響相應的信令鏈路，導致有關BTS退出服務。當在出現(xiàn)GPROC245號告警前出現(xiàn)大量相關設備的告警時應該注意及時排除，以免引起GPROC重啟。同時注意CPU工作時的負荷，超過60%或負荷值異常時，應該排查原因，適當地將工作量移到其他的GPROC上或換用處理能力更強的板件。BSC日常維護的注意事項(2)要注意光纖的清潔，特別是與半BSC日常維護的注意事項(3)注意日常的告警信息，經常用disp_act_alarm和state0oosall命令查看系統(tǒng)，發(fā)現(xiàn)有告警或不在服務狀態(tài)的設備應該及時進行處理。要及時收集故障記錄數據，因為系統(tǒng)的存儲有一定的限度，到一定的時間或者一定的數量它就會被覆蓋掉。板件插錯槽位會引起B(yǎng)SC不停的重啟。小插板的螺絲一定要擰到位，以免留下隱患。BSC的每個機框至少要有2塊GPROC板和2塊MSI板處于正常狀態(tài)，以避免當只有一塊GPROC和一塊MSI板時，如果其中的GPROC或MSI板有故障都會引起整個BSC重啟。在更換GPROC和MSI板時要特別注意：保持最少有一塊GPROC和MSI是B-U狀態(tài)。如果連續(xù)更換GPROC（在其它GPROC還未恢復正常B-U狀態(tài)時）板則整個BSC會重啟。BSC日常維護的注意事項(3)注意日常的告警信息，經常用dBSC日常維護的注意事項(4)更換BTC（總線終結）時，只能一塊一塊地操作，操作之前，先將一個可用的BTC板替換與將更換的BTC板在同一個機框同一側的KSW板，在狀態(tài)正常后再開始之后的更換操作，并在所有的更換操作完成后，插回KSW板，恢復原狀。通過集中性預防性維護，可以及時發(fā)現(xiàn)系統(tǒng)隱患并加以排除，最大限度地提高現(xiàn)行系統(tǒng)設備的利用率，增強系統(tǒng)設備的可靠性，從而減輕平時日常維護的壓力。此類維護有：定期進行主備用總線系統(tǒng)的倒換測試，以檢驗備用系統(tǒng)的可靠性；定期在合適的時間里主動重啟設備，清除可能存在的死進程；周期性地對信令負荷和GPROC板的CPU負荷進行統(tǒng)計，對存在異常的GPROC板及時分析原因并采取適當措施；定期對BSC機房進行巡檢，檢查溫度、濕度和電源系統(tǒng)，進行告警驗證，使機房環(huán)境滿足穩(wěn)定運行的需要。加強專業(yè)技能的培訓和實踐，提高維護人員的維護技能，盡量減少人為的操作失誤。BSC日常維護的注意事項(4)更換BTC（總線終結）時，只BSC穩(wěn)定運行的條件一是穩(wěn)定的符合設備運行規(guī)范的機房環(huán)境，包括適宜的溫度和濕度，堅固結實的房屋架構，機房位置沒有水患和具有完善的報警和消防系統(tǒng)。二是安全穩(wěn)定的動力供給。包括滿足要求的設備備品備件，多路供電技術和停電后快速的發(fā)電措施。三是設備包括所有插板和連接光纖沒有隱患或可能影響設備運行的告警存在，同時需要24小時的告警監(jiān)控、齊全的備品和備件和及時的處理措施。四是完善的操作維護和施工規(guī)范，完備的應急處理流程和措施。五是建立一支具有一定維護技能的穩(wěn)定的維護隊伍也相當重要。BSC穩(wěn)定運行的條件一是穩(wěn)定的符合設備運行規(guī)范的機房環(huán)境，包BSC非正常重啟案例故障處理報告實錄.docBSC非正常重啟案例故障處理報告實錄.doc習題分析BSC產生X.25中斷告警的原因。習題分析BSC產生X.25中斷告警的原因。——中國聯(lián)通有限公司廣州分公司·覃道滿編制ThankYou!——中國聯(lián)通有限公司廣州分公司·覃道滿編制ThankYou44演講完畢，謝謝觀看！演講完畢，謝謝觀看！45MOTGSM無線設備培訓

——BSC告警和告警處理——中國聯(lián)通有限公司廣州分公司·覃道滿MOTGSM無線設備培訓

——BSC告警和告警處理——中國46學習目標掌握告警格式與組成23熟悉告警處理流程學習目標掌握告警格式與組成23熟悉告警處理流程學習內容告警格式和組成

告警處理流程

BSC非正常重啟分析

學習內容告警格式和組成簡述機房運行維護人員經常會碰到告警，有些告警是操作維護過程中自然產生的，有些告警是瞬時性的，不會影響系統(tǒng)正常運行，但大多數告警是會影響系統(tǒng)性能的，有的甚至會導致BSS復位，對移動通信系統(tǒng)造成嚴重影響。因此對于運維人員來說，了解告警系統(tǒng)，掌握一定的告警分析和處理技能，顯得非常重要。告警系統(tǒng)是為了故障定位，系統(tǒng)性能分析及方便維護而設置的。告警信息可以在OMCR的告警窗口上顯示，也可以在本地維護終端（LMT）上顯示。BSS產生的告警信息，以字符的形式發(fā)往OMCR。簡述機房運行維護人員經常會碰到告警，有些告警是操作維護過程中告警的種類和格式告警可以分為硬件告警和軟件告警兩種：硬件告警是由于BSS內的硬件故障所引起的告警。軟件告警是由GPROC檢測到軟件進程運行出錯所引起的告警只有GPROC設備（BSP，CSFP，DHP，BTP，poolGPROC）才會產生軟件告警信息。

告警的種類和格式告警可以分為硬件告警和軟件告警兩種：告警舉例#0

–

NEW

–

*NONE*.

CommuncationFailureEvent-CAGE-BSS01(BSS01:SITE-0:):0CAGE1-30/03/199914:23:56.

[18]ExpansionKSWXSlot22CommunicationFailure-FMIC-Major--/-.

(BSS01:SITE-0:):0SITEImpactedtoMajor.

告警舉例#0–NEW–*NONE*.告警解析#0：告警IDNEW：告警狀態(tài)NONE：正在處理此告警的人員CommuncationFailureEvent：告警的類型CAGE：告警級BSS01(BSS01:SITE-0:):0CAGE1：發(fā)生告警的位置30/03/199914:23:56：告警發(fā)生時間[18]：告警編號ExpansionKSWXSlot22(見框架配置表)CommunicationFailure：告警描述FMIC：告警的清除類型Major：告警嚴重等級(主要告警)(BSS01:SITE-0:):0SITEImpactedtoMajor:告警附加信息

告警解析#0：告警ID附:BSC機框配置圖附:BSC機框配置圖告警編號告警編號對于每種設備都有唯一的一個十進制數表示。每種設備的告警編號從0到254。(見附錄)對于不同的設備告警編號可能重復，但與設備相關的編號是唯一的。有些情況下同樣的告警編號表示類似的告警。例如242號告警表示設備退出服務(MMS\MTL\RSL)。

告警編號告警編號對于每種設備都有唯一的一個十進制數表示。每種告警消除類型告警的清除類型可分為三類：IntermittentFaultManagementInitiatedClear（FMIC）OperatorInitiatedClear（OIC）

Intermittent表示告警是偶發(fā)性的，對系統(tǒng)沒有危害。此告警發(fā)生后在OMCR會自動消除。當此類告警頻繁產生時，會增加OML鏈路的負荷。我們可以使用disp_throttle命令來查看告警門限設置，還可用chg_throttle命令調節(jié)其門限值。

FMIC告警的清除由系統(tǒng)的錯誤管理進程（FaultManagermentProcess）自動進行。FM進程管理一張現(xiàn)有告警的列表，只有當告警產生的原因消失后FM才會產生‘clear’消息將此告警從告警列表中刪除。

OIC需要由操作人員手動將告警清除。FM進程檢測到告警產生并判斷為OIC類型時，將此告警加入現(xiàn)有告警列表中。此后FM不再進行任何處理。當操作人員將告警產生的原因解決后，必須將此告警清除。告警消除類型告警的清除類型可分為三類：清除告警步驟在OMCR和BSC上均能夠清除告警。OMCR上清除告警按以下步驟進行：打開告警窗口，單擊鼠標左鍵選中要清除的告警項

單擊鼠標右鍵彈出快捷菜單

選擇快捷菜單的“Handle”

選擇快捷菜單的“Clear”確認告警已被清除

在BSS上清除告警，先使用disp_act_alarm命令查看有哪些OIC告警。然后使用del_act_alarm命令將告警清除。清除命令如下:del_act_alarm<location><device_name><dev_id1><dev_id2><dev_id3><alarm_code>(只對OIC告警)清除告警步驟在OMCR和BSC上均能夠清除告警。OMCR上清告警的類型

OMCR將告警分成六種不同的類型，可以在OMCR的告警說明中找到"FailureEvents"字段，其為不同類型告警的名稱。告警的類型OMCR將告警分成六種不同的類型，可以在O附:告警類型表

類型含義舉例Communication數據從一點傳到另一點時發(fā)生錯誤而產生的告警一般當信令丟失或呼叫建立出錯時發(fā)生此種告警1、mmssynloss2、frameslipdaily3、biterror4、dri-ctuactivelinkcommunicationfailure(critical)QualityofService系統(tǒng)的服務質量下降時產生此告警一般當消息響應超時或帶寬減少時會發(fā)生此種告警：多見于時鐘失鎖gclk_mcufphaselockfailure（major）Processing當軟件或進程出現(xiàn)錯誤時產生此告警一般當進程數據被破壞或系統(tǒng)內存溢出時產生此種告警dri-CTUchannelcoderinternalmessageerror—intermittent(warning)Equipment當硬件出錯時產生此告警。一般當出現(xiàn)配置錯誤，傳輸、電源等問題時產生此種告警dristandbylinkcommunicationfailure(minor)Environment當設備所處的環(huán)境不利于正常工作時產生告警一般當出現(xiàn)煙霧，火光被檢測到時產生此種告警Link當OMCR與BSS間的X.25鏈路出現(xiàn)問題時產生此告警

附:告警類型表類型含義舉例Communication數據告警的等級

影響行動舉例嚴重(Critical)已經影響了系統(tǒng)的服務應該立即采取措施當系統(tǒng)的某一功能出現(xiàn)此種告警而退出服務，應立即將其恢復。重大(Major)已經影響了系統(tǒng)的服務應該馬上采取措施系統(tǒng)的服務容量降低，此時應采取措施恢復容量。較輕(Minor)此錯誤不會對系統(tǒng)的服務造成影響應采取措施減少更多的此類告警產生當此種告警數量不斷增加時，系統(tǒng)的容量可能受到影響。警告(Waring)潛在產生影響系統(tǒng)服務的告警的可能如果必要應該進行必要的分析，采取措施避免產生更嚴重的告警

清除(Clear)告警已經被清除無

待定(Investigate)表明此錯誤的等級無法確定，需要人工進一步分析進一步查找原因

告警的等級

影響行動舉例嚴重已經影響了系統(tǒng)的服務應發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM按鈕

在OMCR桌面圖形界面GUI上雙擊告警按鈕，打開告警窗口，可以看到所有網元（NE）的告警信息；第二種方法：通過GUI上的EVENTMANEGMENT

點擊GUI上的EVENTMAMT按鈕，打開DisplaySubscriptionList窗口，選擇窗口中告警中的一項，選擇open按鈕就打開告警窗口；第三種方法：打開MAP圖，然后選中對應的單元節(jié)點

從NETWORKMAP上查看告警，單擊GUI上的NETWORKMAP按鈕，打開MAPLIST窗口，選定其中的一個網元，雙擊鼠標左鍵打開MAP窗口，在MAP圖上用鼠標左鍵點擊要查看的網絡單元節(jié)點，選中后接點會變?yōu)樽仙瑔螕羰髽擞益I在快捷菜單內選擇ALARM項，此時會出現(xiàn)告警窗口顯示此節(jié)點單元的所有告警。用disp_act_alarm命令行查看告警.發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM告警處理優(yōu)先級別我們可以根據告警的嚴重級別，以及出現(xiàn)告警的網元在系統(tǒng)中的重要性，對不同的告警情況進行相應的處理。在此我們提供一般原則下的優(yōu)先級別。對于基站來說從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的順序進行處理。告警處理優(yōu)先級別我們可以根據告警的嚴重級別，以及出現(xiàn)告警的網附:告警優(yōu)先級別圖告警處理優(yōu)先級別:Thesites

RemoteTranscoder(RXCDR)

BaseStationController(BSC)

BaseTransceiverStation(BTS)Thelinks

MessageTransferpartLink(MTL)

RadioSignallingLink(RSL)

X.25link

Critical告警按照以下順序：

AllRXCDR-Criticalalarms

AllMTL-Criticalalarms

AllBSC-Criticalalarms

AllRSL-Criticalalarms

AllBTS-Criticalalarms

AllX.25link-Criticalalarms

AllotherCriticalalarms

附:告警優(yōu)先級別圖告警處理優(yōu)先級別:ThesitesCr設備之間的從屬關系（parent-child）當某個設備或鏈路處于OOS等非正常狀態(tài)時，不僅與起本身相關，而且與其上一級（parent）設備有關，對parent設備進行進行必要的處理是解決問題的重要手段。如果某個設備處于OOS等狀態(tài)下，此設備下一級（child）設備將也不能正常工作。Device1stparentdev2ndparentdev3rdparentdev4thparentdevRSLMMSMSICAGECABSITEBSSMTLMMSMSICAGECABSITEBSSOMLMMSMSI

TCUDRICABSITEBSS

XBLMMSMSICAGECABSITEBSS設備之間的從屬關系（parent-child）告警處理的流程

查看告警分清告警的級別明確與告警有關的設備根據告警手冊或經驗對告警進行處理解決問題，消除告警

告警處理的流程查看告警常見告警及其處理辦法常見告警及其處理方法.doc常見告警及其處理辦法常見告警及其處理方法.docBSC非正常重啟分析BSC在網絡中的位置和作用重啟分類原因分析實例分析BSC日常維護應注意的事項BSC穩(wěn)定運行的條件BSC非正常重啟分析BSC在網絡中的位置和作用BSC在網絡中的位置和作用在GSM無線通信系統(tǒng)中，BSC作為基站控制器，是BSS子系統(tǒng)的關鍵節(jié)點，一套BSC管理幾十個基站和GPRS網絡關鍵節(jié)點PCU。BSC同時作為GSM語音業(yè)務和GPRS數據業(yè)務的無線關鍵設備，其作用可歸納為：無線管理、電路交換和接續(xù)以及協(xié)議轉換。BSC重啟，即BSC退出服務的過程，將中斷BSS子系統(tǒng)目前正在進行的工作，受該BSC所控制的語音業(yè)務和數據業(yè)務將不能提供服務，影響相當嚴重。BSC在網絡中的位置和作用在GSM無線通信系統(tǒng)中，BSC作附:BSC在網絡中的位置圖BSC在網絡中的位置:MSCXCDRBSCBTS2BTS1PCUSGSNGPRSGSM附:BSC在網絡中的位置圖BSC在網絡中的位置:MSCXCD重啟原因分類系統(tǒng)因故障自動重啟人為操作導致系統(tǒng)重啟重啟原因分類系統(tǒng)因故障自動重啟重啟原因分析機房環(huán)境和動力。BSC硬件故障。各種LINK的故障?？偩€的Failured。BSC軟件故障。改變數據庫和參數設置。重啟原因分析機房環(huán)境和動力。機房環(huán)境和動力主要是頻繁出現(xiàn)高溫告警，或灰塵比較大，或電源供給中斷或不穩(wěn)定造成的。高溫或灰塵比較大的時候，對那些運行時間已比較長的設備威脅比較大，當某個芯片因灰塵積累得比較多而又散熱不充分時，芯片有可能因過熱被燒毀，芯片所在的插板將會退出服務，當系統(tǒng)容錯機制失效時，為了排除故障，系統(tǒng)將不可避免地自動重啟，若系統(tǒng)不能自己排除故障，在人為干預之前，系統(tǒng)將會一直處于重啟狀態(tài)。機房環(huán)境和動力主要是頻繁出現(xiàn)高溫告警，或灰塵比較大，或電源BSC硬件故障這里說的硬件主要是插在BSC機框中的各種插板，每個插板的功能不同，出現(xiàn)故障時對整個BSC的影響也是不同的。從機框的背板到插槽上的每一塊插板的故障都有可能導致系統(tǒng)退出服務，特別是系統(tǒng)不能識別故障板件時，重啟將不可避免地發(fā)生，其中GPROC（處理器板）、GCLK（時鐘）、LANx和KSWx（時隙交換擴展板），因數量多或作用關鍵，出現(xiàn)故障時容易引起B(yǎng)SC的重啟。這其中又以時鐘板最為重要。BSC硬件故障這里說的硬件主要是插在BSC機框中的各種插板各種LINK的故障與BSC相連的LINK有MTL、RSL、OML、XBL、GSL。對BSC影響最大的是MTL和GSL兩種鏈路，有可能導致BSC自動重啟或BSC中有死進程存在，有死進程時系統(tǒng)運行將非常緩慢，命令無法執(zhí)行，需要人為重啟BSC來清除。各種LINK的故障與BSC相連的LINK有MTL、RSL、總線的Failured(1)PBUS：PBUS即ProcessorBus，它是MCAP總線在軟件上的一種表示，負責GPROC與其他大的插板（XCDR、GCLK、KSW、DRI）之間的通信。PBUSDeviceFailured的原因可能是：①LANx板Faulty；

③某塊板件故障。②可能是FTP（故障傳輸部分）和FCP（故障收集部分）之間的錯誤引起的。第三種情況屬于軟件故障，需要人為重啟BSC來重啟這兩個進程?？偩€的Failured(1)PBUS：PBUS即Proce總線的Failured(2)SBUS：SBUS即SerialBus,它上面的通信由GPROC控制，主要負責GPROC與小插板板（如LANx、KSWx、CLKx）之間的通信。每個機框的SBUS也是一主一備的，但它們被分配不同的任務，Standby不享有ActiveSBUS的功能。 當SBUSfailured后，BSC有可能會重啟，部分故障不會引起重啟。重啟結束后，如果SBUS仍然是不可用狀態(tài)，那么就必須去檢查具體原因了。SBUS有故障時，必須考慮所有被主GPROC控制的SBUS上的通信。導致SBUSFailured的原因有以下幾種可能：①LANx插板沒有插到位，與背板的連接不正確，或光纖沒有連接好或連接了錯誤的光纖。②LANx插板Failured。③GPROC板Failured，導致SBUS上的通信不正常。④BTC板不能給背板供電?？偩€的Failured(2)SBUS：SBUS即Seria總線的Failured(3)TBUS：TBUS即TDMBUS。它由KSW控制，每對KSW為系統(tǒng)提供1024個交換時隙，分配給其它大的插板如GPROC、MSI、XCDR、KSW使用，時隙可擴展和擴容。在TDM高速總線故障的情況下，系統(tǒng)的主用TBUS將會退出服務，系統(tǒng)將要求TDMhighway做倒換，進而將會使所有機框里的的TBUS一起做倒換，如果此時備用的TBUS不可用，倒換將不能成功，機框將會退出服務，系統(tǒng)將會要求整個BSC重啟。引起TBUSFailured的原因可能如下：①連接本地與遠端KSWx的光纖有問題，或者斷了。②KSWx插板Failured。③KSW插板故障或不可用。總線的Failured(3)TBUS：TBUS即TDMB總線的Failured(4)CBUS：CBUS即ClockDistributionBus，通過此總線系統(tǒng)將時鐘信號傳送到機框背板。給各種大的插板GPROC、KSW、MSI、XCDR等插板提供時鐘，CBUS在整個系統(tǒng)一主一備的。當主用的CBUS有故障時，系統(tǒng)會自動倒換到備用的CBUS，當然備用的CBUS在此時是必須可用的。當備用的CBUS不可用而系統(tǒng)倒換時，BSC將重啟。引起CBUSDisabled的原因可能如下：①GCLK板硬件故障。②擴展時鐘信號的光纖有問題。③擴展時鐘信號的KSWx插板和CLKx插板故障。總線的Failured(4)CBUS：CBUS即ClockBSC軟件故障GPROC的內存問題。我們知道，GPROC在BSC中處于相當重要的位置是因為它擔任了控制處理功能，GPROC的CUP也有一定的工作極限，當用作BSP的GPROC的CPU使用率達到100%，出現(xiàn)BSP[239]processsafetestauditfailure(檢測不到BSP板)告警，此時軟件故障可以稱為進程吊死。遇到這種告警時，需要在BSC現(xiàn)場關掉OML，即將Slot16、Slot14板開關下置為“disable”，重啟BSC。為了節(jié)省故障恢復時間，可進入第3層，等待出現(xiàn)[waitingforOMC-R]的提示時輸入如下命令：Msg_send800001978h---跳過從OMC-R下載數據以加快啟動過程。導致BSC重啟的原因是因為BSC的SSM與BTS的CRM間通信量太大，使得產生的SMSWFMs過多所致。最直接的原因是基站的業(yè)務量太大，TCH擁塞所致。通過調整cp_messages.cSWFMs的量，可以解決此問題。為了減少此類故障的發(fā)生，建議用處理能力更強大的GPROC3做BSP，減少重啟的可能，當BSP負荷很高時，可以考慮設置單獨的OMF，把OML分離出去，降低BSP的負荷。在系統(tǒng)話務忙時避免執(zhí)行大批量的命令，也可減少BSP重啟的機會。降低單個GPROC的負荷，避免某個GPROC因負荷太大時自動重啟后，負荷被其它GPROC分擔后出現(xiàn)多米諾骨牌效應，最終導致整個BSC重啟的悲劇的發(fā)生。有時侯內存并沒有問題而是當使用內存時GPROC被locked了。這時可有三種方法來處理：①將此可能故障的GPROC（BSP）與其它的GPROC交換，即使此GPROC再次重啟，也不會使BSC重啟。②換一塊好的GPROC。③UNLOCKGPROCBSC軟件故障GPROC的內存問題。我們知道，GPROC在改變數據庫和參數設置有時數據庫某些參數做了改動后也需要BSC重啟，才能正常工作或發(fā)生作用，特別是一些影響基站正常工作的參數，平時不要隨意改動。另外還有可能因為本身新版本軟件的缺陷也會偶爾出現(xiàn)問題，需要使BSC重啟。改變數據庫和參數設置有時數據庫某些參數做了改動后也需要BS事例分析(1)BSC的3個GPROCs(0116,0117,0118)在不同時間自動reset，造成BSCreset。 解決：從收集的數據發(fā)現(xiàn)MTL不穩(wěn)定，時好時壞，有告警產生。CA向GPROC發(fā)送fast_reset,將GPROCreset。 因為GPROC控制的MTL和RSL負荷過大，使得MTL時好時壞。當一條MTL斷了，造成其超負荷，就會使得其他MTL退出服務。這時可檢查此MTL的統(tǒng)計數據，或檢查PGROC的CPU的使用率。