無線內(nèi)部培訓(xùn)講義BSC告警和告警處理課件

MOTGSM無線設(shè)備培訓(xùn)

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

——BSC告警和告警處理——中國1學(xué)習(xí)目標(biāo)掌握告警格式與組成23熟悉告警處理流程學(xué)習(xí)目標(biāo)掌握告警格式與組成23熟悉告警處理流程學(xué)習(xí)內(nèi)容告警格式和組成

告警處理流程

BSC非正常重啟分析

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

告警的種類和格式告警可以分為硬件告警和軟件告警兩種：告警舉例#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：告警級(jí)BSS01(BSS01:SITE-0:):0CAGE1：發(fā)生告警的位置30/03/199914:23:56：告警發(fā)生時(shí)間[18]：告警編號(hào)ExpansionKSWXSlot22(見框架配置表)CommunicationFailure：告警描述FMIC：告警的清除類型Major：告警嚴(yán)重等級(jí)(主要告警)(BSS01:SITE-0:):0SITEImpactedtoMajor:告警附加信息

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

告警編號(hào)告警編號(hào)對(duì)于每種設(shè)備都有唯一的一個(gè)十進(jìn)制數(shù)表示。每種告警消除類型告警的清除類型可分為三類：IntermittentFaultManagementInitiatedClear（FMIC）OperatorInitiatedClear（OIC）

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

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

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

單擊鼠標(biāo)右鍵彈出快捷菜單

選擇快捷菜單的“Handle”

選擇快捷菜單的“Clear”確認(rèn)告警已被清除

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

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

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

附:告警類型表類型含義舉例Communication數(shù)據(jù)告警的等級(jí)

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

清除(Clear)告警已經(jīng)被清除無

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

告警的等級(jí)

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

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

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

從NETWORKMAP上查看告警，單擊GUI上的NETWORKMAP按鈕，打開MAPLIST窗口，選定其中的一個(gè)網(wǎng)元，雙擊鼠標(biāo)左鍵打開MAP窗口，在MAP圖上用鼠標(biāo)左鍵點(diǎn)擊要查看的網(wǎng)絡(luò)單元節(jié)點(diǎn)，選中后接點(diǎn)會(huì)變?yōu)樽仙?，單擊鼠?biāo)右鍵在快捷菜單內(nèi)選擇ALARM項(xiàng)，此時(shí)會(huì)出現(xiàn)告警窗口顯示此節(jié)點(diǎn)單元的所有告警。用disp_act_alarm命令行查看告警.發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM告警處理優(yōu)先級(jí)別我們可以根據(jù)告警的嚴(yán)重級(jí)別，以及出現(xiàn)告警的網(wǎng)元在系統(tǒng)中的重要性，對(duì)不同的告警情況進(jìn)行相應(yīng)的處理。在此我們提供一般原則下的優(yōu)先級(jí)別。對(duì)于基站來說從RXCDR到BSC，再到BTS；信令鏈路按照MTL、RSL、XBL的次序；告警嚴(yán)重級(jí)別由高到低分別是Critical、Major、Minor、Warning、Investigate、Clear。在相同的告警級(jí)別中，Critical告警按照以下順序AllRXCDR-AllMTL-AllBSC-AllRSL-AllBTS-AllX.25link-AllotherCriticalalarms。Major告警按照以下順序AllRXCDR-AllBSC-AllBTS-AllotherMajoralarms。其它告警按照Minor、Warning、Investigate、Clearalarms的順序進(jìn)行處理。告警處理優(yōu)先級(jí)別我們可以根據(jù)告警的嚴(yán)重級(jí)別，以及出現(xiàn)告警的網(wǎng)附:告警優(yōu)先級(jí)別圖告警處理優(yōu)先級(jí)別: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)先級(jí)別圖告警處理優(yōu)先級(jí)別:ThesitesCr設(shè)備之間的從屬關(guān)系（parent-child）當(dāng)某個(gè)設(shè)備或鏈路處于OOS等非正常狀態(tài)時(shí)，不僅與起本身相關(guān)，而且與其上一級(jí)（parent）設(shè)備有關(guān)，對(duì)parent設(shè)備進(jìn)行進(jìn)行必要的處理是解決問題的重要手段。如果某個(gè)設(shè)備處于OOS等狀態(tài)下，此設(shè)備下一級(jí)（child）設(shè)備將也不能正常工作。Device1stparentdev2ndparentdev3rdparentdev4thparentdevRSLMMSMSICAGECABSITEBSSMTLMMSMSICAGECABSITEBSSOMLMMSMSI

TCUDRICABSITEBSS

XBLMMSMSICAGECABSITEBSS設(shè)備之間的從屬關(guān)系（parent-child）告警處理的流程

查看告警分清告警的級(jí)別明確與告警有關(guān)的設(shè)備根據(jù)告警手冊(cè)或經(jīng)驗(yàn)對(duì)告警進(jìn)行處理解決問題，消除告警

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

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

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

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

——BSC告警和告警處理——中國46學(xué)習(xí)目標(biāo)掌握告警格式與組成23熟悉告警處理流程學(xué)習(xí)目標(biāo)掌握告警格式與組成23熟悉告警處理流程學(xué)習(xí)內(nèi)容告警格式和組成

告警處理流程

BSC非正常重啟分析

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

告警的種類和格式告警可以分為硬件告警和軟件告警兩種：告警舉例#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：告警級(jí)BSS01(BSS01:SITE-0:):0CAGE1：發(fā)生告警的位置30/03/199914:23:56：告警發(fā)生時(shí)間[18]：告警編號(hào)ExpansionKSWXSlot22(見框架配置表)CommunicationFailure：告警描述FMIC：告警的清除類型Major：告警嚴(yán)重等級(jí)(主要告警)(BSS01:SITE-0:):0SITEImpactedtoMajor:告警附加信息

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

告警編號(hào)告警編號(hào)對(duì)于每種設(shè)備都有唯一的一個(gè)十進(jìn)制數(shù)表示。每種告警消除類型告警的清除類型可分為三類：IntermittentFaultManagementInitiatedClear（FMIC）OperatorInitiatedClear（OIC）

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

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

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

單擊鼠標(biāo)右鍵彈出快捷菜單

選擇快捷菜單的“Handle”

選擇快捷菜單的“Clear”確認(rèn)告警已被清除

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

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

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

附:告警類型表類型含義舉例Communication數(shù)據(jù)告警的等級(jí)

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

清除(Clear)告警已經(jīng)被清除無

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

告警的等級(jí)

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

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

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

從NETWORKMAP上查看告警，單擊GUI上的NETWORKMAP按鈕，打開MAPLIST窗口，選定其中的一個(gè)網(wǎng)元，雙擊鼠標(biāo)左鍵打開MAP窗口，在MAP圖上用鼠標(biāo)左鍵點(diǎn)擊要查看的網(wǎng)絡(luò)單元節(jié)點(diǎn)，選中后接點(diǎn)會(huì)變?yōu)樽仙?，單擊鼠?biāo)右鍵在快捷菜單內(nèi)選擇ALARM項(xiàng)，此時(shí)會(huì)出現(xiàn)告警窗口顯示此節(jié)點(diǎn)單元的所有告警。用disp_act_alarm命令行查看告警.發(fā)現(xiàn)告警第一種方法：OMCR桌面圖形界面GUI上的ALARM告警處理優(yōu)先級(jí)別我們可以根據(jù)告警的嚴(yán)重級(jí)別，以及出現(xiàn)告警的網(wǎng)元在系統(tǒng)中的重要性，對(duì)不同的告警情況進(jìn)行相應(yīng)的處理。在此我們提供一般原則下的優(yōu)先級(jí)別。對(duì)于基站來說從RXCDR到BSC，再到BTS；信令鏈路按照MTL、RSL、XBL的次序；告警嚴(yán)重級(jí)別由高到低分別是Critical、Major、Minor、Warning、Investigate、Clear。在相同的告警級(jí)別中，Critical告警按照以下順序AllRXCDR-AllMTL-AllBSC-AllRSL-AllBTS-AllX.25link-AllotherCriticalalarms。Major告警按照以下順序AllRXCDR-AllBSC-AllBTS-AllotherMajoralarms。其它告警按照Minor、Warning、Investigate、Clearalarms的順序進(jìn)行處理。告警處理優(yōu)先級(jí)別我們可以根據(jù)告警的嚴(yán)重級(jí)別，以及出現(xiàn)告警的網(wǎng)附:告警優(yōu)先級(jí)別圖告警處理優(yōu)先級(jí)別: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)先級(jí)別圖告警處理優(yōu)先級(jí)別:ThesitesCr設(shè)備之間的從屬關(guān)系（parent-child）當(dāng)某個(gè)設(shè)備或鏈路處于OOS等非正常狀態(tài)時(shí)，不僅與起本身相關(guān)，而且與其上一級(jí)（parent）設(shè)備有關(guān)，對(duì)parent設(shè)備進(jìn)行進(jìn)行必要的處理是解決問題的重要手段。如果某個(gè)設(shè)備處于OOS等狀態(tài)下，此設(shè)備下一級(jí)（child）設(shè)備將也不能正常工作。Device1stparentdev2ndparentdev3rdparentdev4thparentdevRSLMMSMSICAGECABSITEBSSMTLMMSMSICAGECABSITEBSSOMLMMSMSI

TCUDRICABSITEBSS

XBLMMSMSICAGECABSITEBSS設(shè)備之間的從屬關(guān)系（parent-child）告警處理的流程

查看告警分清告警的級(jí)別明確與告警有關(guān)的設(shè)備根據(jù)告警手冊(cè)或經(jīng)驗(yàn)對(duì)告警進(jìn)行處理解決問題，消除告警

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

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