MOTO系統告警簡介

MOTOROLA系統告警簡介我們在日常維護和優(yōu)化中經常會碰到告警，有些告警是操作維護過程中自然產生的，有些告警是瞬時性的，不會影響系統正常運行，但大多數告警是會影響系統性能的，有的甚至會導致BSS復位，對系統造成嚴重影響。因此了解告警系統，掌握一定的告警分析和處理技能，顯得非常重要。1MOTOROLA

GSM系統的告警格式2告警可以分為硬件告警和軟件告警兩種：■引起·硬件告警是由于BSS內的硬件故障所引起的告警?！ぼ浖婢怯蒅PROC檢測到軟件進程運行出錯所的告警。只有GPROC設備（BSP，CSFP，DHP，BTP，poolGPROC）才會產生軟件告警信息。軟件告警（Software

Fault

Management或SWFM）分為兩類。MOTOROLA移動系統產品的告警系統和告警格式3Fatal和non-fatal軟件告警軟件告警

SWFM類型等級影響NON-fatal警告SWFM調用相應的進程來恢復軟件錯誤Fatal嚴重SWFM將GPROC

resetMOTOROLA移動系統產品的告警系統和告警格式－告警實例4#0

–

NEW

–

*NONE*.CommuncationFailureEvent

-

CAGE

-

BSS01(BSS01:SITE-0:):

0

CAGE

1

-

30/03/1999

14:23:56.[18]

Expansion

KSWX

Slot

22

Communication

Failure

-

FMIC

-

Major

-

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

SITE

Impacted

to

Major.字段意義：

#0：告警IDNEW：告警狀態(tài)NONE：正在處理此告警的人員

CommuncationFailureEvent：告警的類型在OMCR將告警分成六種不同的類型，可以在OMCR的告警說明中找到“FailureEvents”字段，其為不同類型告警的名稱。CAGE：告警級BSS01(BSS01:SITE-0:):0

CAGE

1：發(fā)生告警的位置30/03/1999

14:23:56：告警發(fā)生時間

[18]：告警編號告警編號對于每種設備都有唯一的一個十進制數表示。每種設備的告警編號從0到254。對于不同的設備告警編號可能重復，但與設備相關的編號是唯一的。有些情況下同樣的告警編號表示類似的告警。例如254號告警表示設備fail。Expansion

KSWX

Slot

22

Communication

Failure：告警描述

FMIC：告警的清除類型MOTOROLA移動系統產品的告警系統和告警格式類型含義舉例Communication數據從一點傳到另一點時發(fā)生錯誤而產生的告警一般當信令丟失或呼叫建立出錯時發(fā)生此種告警Quality

ofServiceProcessingEquipment系統的服務質量下降時產生此告警當軟件或進程出現錯誤時產生此告警當硬件出錯時產生此告警。一般當消息響應超時或帶寬減少時會發(fā)生此種告警一般當進程數據被破壞或系統內存溢出時產生此種告警一般當出現配置錯誤，傳輸、電源等問題時產生此種告警Environment當設備所處的環(huán)境不利于正常工作時產生告警一般當出現煙霧，火光被檢測到時產生此種告警Link當OMCR與BSS間的X.25鏈路出現問題時產生此告警5告警的清除類型6告警的清除類型可分為三類：⒈Intermittent⒉Fault

Management

Initiated

Clear（FMIC）⒊Operator

Initiated

Clear（OIC）告警的清除類型--Intermittent71.

Intermittent表示告警是偶發(fā)性的，對系統沒有危害。因此此告警發(fā)生后在OMCR會自動消除。當此類告警產生太頻繁，會造成到OML鏈路負擔過重。因此用戶可以使用兩條命令查看，調節(jié)此類告警向OMCR報告的數量。disp_throttle

<device_name>

<alarm_code>chg_throttle

<device_name>

<alarm_code><throttle_count>告警的清除類型--FMIC82.

Fault

Management

Initiated

Clear（FMIC）為持續(xù)性的告警，當告警原因消失后需要將此告警清除。告警的清除由系統的錯誤管理進程（Fault

ManagermentProcess）自動將其清除。FM進程管理一張現有告警的列表，只有當告警產生的原因消失后，FM才會產生‘clear’消息將此告警從告警列表中刪除。告警的清除類型--OIC9⒊ Operator

Initiated

Clear（OIC）為持續(xù)性的告警，當告警原因消失后需要將此告警清除。需要由操作人員手動將告警清除。FM進程檢測到告警產生并判斷為OIC類型時，將此告警加入現有告警列表中。此后FM不再進行任何處理。當操作人員將告警產生的原因解決后，必須將此告警清除。先使用disp_act_alarm命令查看有哪些OIC告警。然后使用del_act_alarm命令將告警清除，格式如下：del_act_alarm

<location>

<device_name>

<dev_id1><dev_id2>

<dev_id3>

<alarm_code>告警嚴重等級影響行動舉例嚴重

(Critical)已經影響了系統的服務應該立即采取措施重大

(Major)已經影響了系統的服務應該馬上采取措施當系統的某一功能出現此種告警而退出服務，應立即將其恢復。系統的服務容量降低，此時應采取措施恢復容量。較輕

(Minor)此錯誤不會對系統的服務造成影響應該采取措施減少更多的此類告警的產生當此種告警數量不斷增加時，系統的容量可能受到影響。警告

(Waring)潛在產生影響系統服務的告警的可能清除

(Clear)告警已經被清除如果必要應該進行必要的分析，采取措施避免產生更嚴重的告警無待定

(Investigate)表明此錯誤的等級無法確定，需要人工進一步分析進一步查找原因10告警嚴重等級11告警的等級可以查看也可以根據要求改變。使用以下兩條命令可以查看和改變告警的等級：查看告警的等級disp_severity

<device_name>

<alarm_code>改變告警的等級chg_severity

<device_name>

<alarm_code>

<severity>例如：disp_severity

DRI

12DRI

Alarm

Code

12

severity:

WARNINGchg_severity

DRI

12

majorCOMMAND

ACCEPTED硬件故障及告警的處理流程STEP1:嚴重影響系統安全的告警STEP2:出現次數較高的告警STEP3:

影響系統的PERFORMANCE的告警12系統硬件故障的數據收集13數據收集渠道：ACT

ALARMS每天對系統做一遍系統的告警檢查，主要查看是否有影響系統穩(wěn)定的告警存在，發(fā)現此類告警應及時處理。ECT

TOOLS每3天收一次ECT的數據，并對影響系統安全及告警次數非常高的告警進行過濾，并盡快處理，以減輕OML的負荷以及減少大量的告警出現。SYSTEM

PERFORMANCE（定位硬件故障）

每周收集3－5天的getpm數據，并主要通過rawcar和rawcel的數據進行過濾分析，定位出存在的硬件故障，并根據其優(yōu)先級別安排處理。通過告警分析系統硬件故障舉例－BSS

22號告警BSS

22號告警：Trunk

Critical

Threshold

Exceeded首先查硬件問題，如E1連接是否正常，MSI、XCDR、GDP板是否有問題，有沒有

被LOCK，再檢查是否因傳輸問題而使MMS口退服。同時應注意一下數據庫中有關參數的定義是否合理。由于傳輸等問題會使得CIC被block，但傳輸恢復正常后，

CIC不一定能自動起來，此時需要人工干預才能恢復。在BSC找到對應的連接到MSC的2M鏈路的MMS板鍵入disp_mms_ts_usage

0

mms

*

*查看此MMS的各時隙是否有被block的。如發(fā)現大量的CIC被block，首先確定是否為MSC邊將其block的。如果不是則使用以下命令將CIC釋放。先進入BSC的emon狀態(tài)，鍵入以下命令msg_s

64

3

99

99

0f0eh

0eh

01h

00

xx

030h

02h

00h

01h其中xx---CIC

number查看cic告警的門限值。如發(fā)現設置過低，使用下列命令調整cic告警門限值。disp_element

cic_error_gen_threshold

0（2－chg_element

cic_error_gen_threshold

<value>

0255）14通過告警分析系統硬件故障舉例－MTL

0號告警15MTL

0號告警：SignallingLinkFailureMTL最多的告警一般為0號告警，出現此告警時MTL為D-U。此告警表示MTL鏈路與MSC已經失去聯系。這是由于MTP第二層出現問題，而退出服務。但系統會不斷嘗試恢復此鏈路。另外當一條MTL鏈路退出服務時，其負荷會分配到其它MTL上，加重其它MTL的負擔，而由于GPROC的處理能力的原因，

MTL鏈路的平均利用率不能超過30％。因此MTL鏈路負擔過重，會使得

GPROC退出服務，從而導致更多的鏈路退出服務。此告警與BSS

0號告警的區(qū)別為：MTL

0號告警表示一條MTL退出服務，而一個BSS可能有多條MTL鏈路，BSS

0號告警表示此BSS系統的最后一條MTL鏈路也退出服務，此時BSS完全癱瘓了。檢查數據庫內關于MTL鏈路定義有無問題，然后檢查有關的MMS口、

MSI板是否退出服務，再查與MSC的信令點碼是否正確，在確認上述方面無問題后檢查GPROC是否有硬件問題，必要時復位該GPROC。通過告警分析系統硬件故障舉例－IAS

1號告警16IAS

1號告警——Serial

Bus

Connection

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

0

cage

0

0IAS

Connected:

YES最后一項如果定義為YES，則軟件嘗試將告警信號送到此CAGE，但是如果物理上并沒有將告警線連接到此CAGE，則會產生IAS

1號告警。一般配置CAGE時都將下面的CAGE定義為連接告警線，上面的CAGE不連接。如果在equip

cage時將上面的

CAGE也定義了IAS

Connected:YES，則會產生大量的IAS

1告警。先確定告警線連接在哪個CAGE中，查看數據庫中定義的是否與物理連接相一致。不一致時修改數據庫。如果數據庫定義沒有問題，檢查告警板和告警線是否損壞。modify_value

0

ias_connected

<

*

>

cage

(

#

)<*

>yes/no；(#)

cage號通過告警分析系統硬件故障舉例－GPROC

25417■GPROC

254號告警

Device

Failure此告警表示一個GPROC或BTP退出服務。此告警的不同形式為：■■■[254]

BSP:

Device

Failure[254]

BTP:

Device

Failure[254]

GPROC:

Device

Failure一些GCLK、LANX、KSW等設備的告警可能會使GPROC退出服務，當出現GPROC

254號告警前

出現大量相關設備的告警時應該注意及時排除，以免引起GPROC

reset。同時注意CPU工作時

的使用率，如果出現使用率超出60%時，應該引起注意，適當地將工作量移到其他的GPROC上。每個BSC上必須至少有一個備用的GPROC2（用disp_p

0)查看是否有至少一個E_U的

GPROC2。如果存在GPROC告警，應及時解決，有故障的應及時更換。通過告警分析系統硬件故障舉例－TIMESLOT

018TIMESLOT

0號告警此告警表明因為RF的問題而使得呼叫失敗的統計值（包括無法建立通話）超出告警門限。在分配信道時，系統會檢測空中各信道的信噪比。在數據庫中定義了interfer_bands

1-4參數，此為四類信噪比的界限，以將信道分成不同的5類，前四類的信道按照優(yōu)先順序被分配，而第五類信道因為干擾強，系統不會將其分配出去。這樣有利于避免受干擾大的信道被使用，從而保證了通話的質量。但是干擾較大時，大部分信道成為5類信道而無法使用，嚴重時會造成大量通話無法建立，產生告警。查看時隙占用情況時出現：(TCH/F)

UNAVAIL

(IBAND)可能引起此類告警的原因：干擾、參數設置應先尋找并排除干擾源，找不到干擾源時，如果允許通話干擾稍大一些，可以修改數據庫的參數，將4類信道的干擾標準適當降低，這兩種方法都行不通時，應考慮頻率調整。通過告警分析系統硬件故障舉例－SITE

21號告警19SITE

21號告警

No

Clock

References

AvailableGCLK要與上一級時鐘同步必須要有上一級時鐘的參考信號，時鐘參考信號是根據數據庫的定義從指定的MMS口上提取的。modify_value

<

location>

mms_priority

<*>

mms

<mms_id1><mms_id2><*> 0

to

255在database中需要定義不同MMS口的時鐘提取優(yōu)先等級.有的基站需要兩個2M傳輸

提供話務服務，第二個傳輸同樣需要優(yōu)先級定義，不然在第一個傳輸斷的情況下，造成基站沒有時鐘源，產生失鎖。下面的命令設置當一個MMS的時鐘提取出現問題時，多久后切換到其它的MMS口提取時鐘chg_ele

wait_for_reselection

<element_value>

<location><element_value>1

to

255（缺省值為10）有部分基站的時鐘開關未打開，此種基站的時鐘為自由震蕩狀態(tài)，長時間會造成與上級時鐘不能同步，造成切換不成功甚至產生掉話的問題。下面命令設置是否允許時鐘同步chg_ele

phase_lock_gclk

<*>

<site

No.><*>Disable

phase

lockingEnable

phase

locking通過告警分析系統硬件故障舉例－載頻20載頻類告警概述載頻告警主要有硬件、通訊鏈路、載頻高溫、放大器、發(fā)射接收同步系統、編解碼處理器、電源供給等告警類型，載頻的告警類型多達150多種，嚴重告警90多種。對載頻告警的處理主要考慮其對網絡穩(wěn)定和網絡指標的影響程度，有些載頻出現某類告警，但是告警次數很少，（不會同時出現DRI

35告警）我們只需要ins載頻觀察，如果ins后每天仍不停出現就要將其更換；某些告警的出現會使系統將其軟件重啟或退服，哪怕一天有幾次，也要將其更換，如DRI

[35]、DRI[254]等，因為載頻重啟會影響到正在通話的中斷，造成掉話，切換失敗等，如果是BCCH載頻還會使整個小區(qū)暫時不能工作。通過告警分析系統硬件故障舉例－IAS21IAS告警此類告警占所有告警的比例比較高，此類告警比較好判斷，一般可直接根據告警的說明直接判斷硬件的故障，這類告警主要有風扇、電源模塊

的輸入輸出、告警，告警板的連接，電源模塊溫度告警，模塊的熔絲告警，

VSWR告警等。在出現載頻的告警線連接類型告警時，應檢查載頻與告警板

間的連接線是否松動（只限Mc