MOTO系统告警简介

MOTOROLA系统告警简介我们在日常维护和优化中经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致BSS复位，对系统造成严重影响。因此了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。1MOTOROLA

GSM系统的告警格式2告警可以分为硬件告警和软件告警两种：■引起·硬件告警是由于BSS内的硬件故障所引起的告警。·软件告警是由GPROC检测到软件进程运行出错所的告警。只有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：告警状态NONE：正在处理此告警的人员

CommuncationFailureEvent：告警的类型在OMCR将告警分成六种不同的类型，可以在OMCR的告警说明中找到“FailureEvents”字段，其为不同类型告警的名称。CAGE：告警级BSS01(BSS01:SITE-0:):0

CAGE

1：发生告警的位置30/03/1999

14:23:56：告警发生时间

[18]：告警编号告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从0到254。对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的告警编号表示类似的告警。例如254号告警表示设备fail。Expansion

KSWX

Slot

22

Communication

Failure：告警描述

FMIC：告警的清除类型MOTOROLA移动系统产品的告警系统和告警格式类型含义举例Communication数据从一点传到另一点时发生错误而产生的告警一般当信令丢失或呼叫建立出错时发生此种告警Quality

ofServiceProcessingEquipment系统的服务质量下降时产生此告警当软件或进程出现错误时产生此告警当硬件出错时产生此告警。一般当消息响应超时或带宽减少时会发生此种告警一般当进程数据被破坏或系统内存溢出时产生此种告警一般当出现配置错误，传输、电源等问题时产生此种告警Environment当设备所处的环境不利于正常工作时产生告警一般当出现烟雾，火光被检测到时产生此种告警Link当OMCR与BSS间的X.25链路出现问题时产生此告警5告警的清除类型6告警的清除类型可分为三类：⒈Intermittent⒉Fault

Management

Initiated

Clear（FMIC）⒊Operator

Initiated

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

Intermittent表示告警是偶发性的，对系统没有危害。因此此告警发生后在OMCR会自动消除。当此类告警产生太频繁，会造成到OML链路负担过重。因此用户可以使用两条命令查看，调节此类告警向OMCR报告的数量。disp_throttle

<device_name>

<alarm_code>chg_throttle

<device_name>

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

Fault

Management

Initiated

Clear（FMIC）为持续性的告警，当告警原因消失后需要将此告警清除。告警的清除由系统的错误管理进程（Fault

ManagermentProcess）自动将其清除。FM进程管理一张现有告警的列表，只有当告警产生的原因消失后，FM才会产生‘clear’消息将此告警从告警列表中删除。告警的清除类型--OIC9⒊ Operator

Initiated

Clear（OIC）为持续性的告警，当告警原因消失后需要将此告警清除。需要由操作人员手动将告警清除。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每天对系统做一遍系统的告警检查，主要查看是否有影响系统稳定的告警存在，发现此类告警应及时处理。ECT

TOOLS每3天收一次ECT的数据，并对影响系统安全及告警次数非常高的告警进行过滤，并尽快处理，以减轻OML的负荷以及减少大量的告警出现。SYSTEM

PERFORMANCE（定位硬件故障）

每周收集3－5天的getpm数据，并主要通过rawcar和rawcel的数据进行过滤分析，定位出存在的硬件故障，并根据其优先级别安排处理。通过告警分析系统硬件故障举例－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的。如发现大量的CIC被block，首先确定是否为MSC边将其block的。如果不是则使用以下命令将CIC释放。先进入BSC的emon状态，键入以下命令msg_s

64

3

99

99

0f0eh

0eh

01h

00

xx

030h

02h

00h

01h其中xx---CIC

number查看cic告警的门限值。如发现设置过低，使用下列命令调整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号告警的区别为：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类，前四类的信道按照优先顺序被分配，而第五类信道因为干扰强，系统不会将其分配出去。这样有利于避免受干扰大的信道被使用，从而保证了通话的质量。但是干扰较大时，大部分信道成为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口的时钟提取优先等级.有的基站需要两个2M传输

提供话务服务，第二个传输同样需要优先级定义，不然在第一个传输断的情况下，造成基站没有时钟源，产生失锁。下面的命令设置当一个MMS的时钟提取出现问题时，多久后切换到其它的MMS口提取时钟chg_ele

wait_for_reselection

<element_value>

<location><element_value>1

to

255（缺省值为10）有部分基站的时钟开关未打开，此种基站的时钟为自由震荡状态，长时间会造成与上级时钟不能同步，造成切换不成功甚至产生掉话的问题。下面命令设置是否允许时钟同步chg_ele

phase_lock_gclk

<*>

<site

No.><*>Disable

phase

lockingEnable

phase

locking通过告警分析系统硬件故障举例－载频20载频类告警概述载频告警主要有硬件、通讯链路、载频高温、放大器、发射接收同步系统、编解码处理器、电源供给等告警类型，载频的告警类型多达150多种，严重告警90多种。对载频告警的处理主要考虑其对网络稳定和网络指标的影响程度，有些载频出现某类告警，但是告警次数很少，（不会同时出现DRI

35告警）我们只需要ins载频观察，如果ins后每天仍不停出现就要将其更换；某些告警的出现会使系统将其软件重启或退服，哪怕一天有几次，也要将其更换，如DRI

[35]、DRI[254]等，因为载频重启会影响到正在通话的中断，造成掉话，切换失败等，如果是BCCH载频还会使整个小区暂时不能工作。通过告警分析系统硬件故障举例－IAS21IAS告警此类告警占所有告警的比例比较高，此类告警比较好判断，一般可直接根据告警的说明直接判断硬件的故障，这类告警主要有风扇、电源模块

的输入输出、告警，告警板的连接，电源模块温度告警，模块的熔丝告警，

VSWR告警等。在出现载频的告警线连接类型告警时，应检查载频与告警板

间的连接线是否松动（只限Mc