BSS Alarm Analyse Guidelineupdate.docx

BSS Alarm Analyse Guidelineupdate.docx

《BSS Alarm Analyse Guidelineupdate.docx》由会员分享，可在线阅读，更多相关《BSS Alarm Analyse Guidelineupdate.docx（13页珍藏版）》请在冰豆网上搜索。

BSSAlarmAnalyseGuidelineupdate

告警故障日常分析

与处理流程

摩托罗拉全球电信运营方案解决部

杭州分公司

2004年2月

一、概述

在无线网络日常维护优化中，对于系统告警和故障设备能否及时发现和分析处理，不仅关系到系统运行的稳定和安全，而且及时处理告警故障设备也能解决其他优化方式无法发现的网络问题，对整个网络的优化，提高全网系统性能都很有帮助。

我们在日常维护优化工作中碰到的告警事件，有些告警是系统运行、操作维护过程中自然产生的，例如insdri、resetsite、更换设备等都会产生告警；有些告警是瞬时性的，例如传输闪断；有些告警可能对系统性能、安全影响不大，例如部分EAS外部告警、IAS基站主设备内部告警、DRI冗余备份链路告警等，但这些大量产生的告警会产生大量的告警垃圾数据，同时在OMCR上生成巨大的eventlog，占用OMCR的空间，使BSS维护人员花更多时间来分析处理，并影响了日常维护工作中对真正有用、必要的告警信息的甄别筛选；而有些告警可能一天只出现一两次，却会给系统带来致命后果，严重些的会导致BSS系统复位，甚至造成系统瘫痪，例如GPROC、BTP告警；有些告警严重程度可大可小，需要通过调查分析确认其危害程度、是否会破坏系统安全；同时，有些每时每刻频繁重复发生的BTS或BSC/RXCDR的告警也会大大增加rsl/oml的负担，额外增加系统的信令负荷和处理进程。

通过对这些告警事件的分析、过滤、处理、解决，可以进一步提高系统运行的稳定和可靠，排除故障隐患，并可以及早发现、定位、解决系统故障，达到优化无线通信网络系统性能的目的。

二、告警信息

对于无线网络中存在的所有告警，种类繁多，有些是正常操作造成的，有些可能是无关紧要的，我们不可能全部都予以处理解决，所以需要对告警的信息进行分析，萃取真正有用、重要的告警信息。

告警信息的详细描述在OMCR的eventlog文件中，除告警设备ID和产生时间等必要信息外，还包含了以下4部分内容：

1，告警状态（5种）；2，告警范畴（6类）；3，告警危急程度（6级）；4，告警清除方式（3种）。

1.告警状态（5种）

ØNEW——新告警

ØSEEN——已出现告警

ØHANDLING——在处理

ØDEFERRED——告警延时

ØCLEARED——已清除

2.告警范畴（6类）

ØCommunication——通讯类，信令或呼叫建立出错时发生

ØQualityofService——服务质量类，影响服务

ØProcessing——进程类，软件或进程错误、缓存溢出

ØEquipment——设备类，硬件故障

ØEnvironment——环境类，外部周边告警

ØLink——X.25链路告警

3.告警危急程度（6级）

ØCritical——紧急，危害系统安全，需立即解决

ØMajor——重要，影响系统性能，需及时解决

ØMinor——次要，可能影响系统性能，建议解决

ØWarning——警告，指示某些故障已达到门限，需注意

ØInvestigate——调查，需研究分析故障的危害程度，此类告警可能危害系统安全

ØClear——清除，先前出现的告警已解决

4.告警清除方式（3种）

ØFMIC——FaultManagementInitiatedClear

当故障解决后，系统可自动清除告警。

FM进程管理一张现有告警的列表，只有当告警产生的原因消失后FM才会产生‘clear’消息将此告警从告警列表中删除。

ØOIC——OperatorInitiatedClear

故障被解决后，需在OMCR上人工清除该告警，这类告警系统仅汇报一次。

FM进程检测到告警产生并判断为OIC类型时，将此告警加入现有告警列表中。

此后FM不再进行任何处理。

当操作人员将告警产生的原因解决后，必须将此告警清除。

ØIntermittent——

这类告警会间断地、频繁重复出现多次，说明某些设备运行不稳定，告警不时产生又自动恢复。

此类告警可由数据库定义告警上报周期。

命令格式如下：

chg_throttle

其中的单位为时间——分钟。

**********************************************************************************************

告警信息的文本格式如下

下面是一个OMCR上显示的告警实例。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

#0–NEW–*NONE*.

CommuncationFailureEvent-CAGE-BSS01（BSS01:

SITE-0:

）:

0CAGE1-30/03/199914:

23:

56.

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

（BSS01:

SITE-0:

）:

0SITEImpactedtoMajor.

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

上面的的告警信息表示在BSC01的CAGE1半尺寸22槽的扩容KSWX有故障，需排障。

三、处理流程

图－1故障处理流程图

日常硬件告警处理主要通过以下三种途径：

Ø告警log文件分析

Ø统计性能指标分析

ØDT/CQT

其中告警log文件来源于：

ECTlog文件、Eventlog文件、disp_act_alarmlog文件等；而性能指标来源于：

cell指标ma_fail_from_ms和carrier指标path_balance/BER；DT/CQT来源于实际路测和拨打测试中发现的故障现象，例如载频故障和天馈故障等。

以下对上述流程举例分析。

1.告警log文件分析

通过ECT告警事件的统计功能，它可将系统中某几天的告警事件次数按照告警类型或告警级别分类统计累加。

根据ECT可很快统计出系统在某天出现的各种告警事件，可以分析无线网络的每日的各类告警分布和总量，掌握网络的运行情况。

但ECTlog仅统计各类告警产生的次数和告警号，而且ECT仅记录当日出现的告警，对以前发生至今仍存在的告警也不记录，所以更详细的告警信息需参考Eventlog、disp_act_alarm或进入BSS的emon状态filter出相关进程信息。

Ø系统安全相关

BSP、BSS、GPROC、CAGE、CELL、GCLK、KSW、LAN等类告警，需参考GSR5手册告警处理单元对此类告警深入分析并立即解决。

Ø影响系统性能统计

BTP、CELL、DRI、GCLK、MMS、SITE、RCI等类告警一般会影响本基站或周边基站的性能，需及时解决。

Ø大量频繁出现的

这类告警大部分是IAS、EAS、DRI、MMS等告警，解决这些告警会大大提高系统运行的稳定性，同时大大降低网络告警总量，便于网络维护人员对告警的过滤。

Ø处理器类型

Ø传输断站类型

Ø时钟类型

Ø载频类型

ØBSS设备类型电路类型－陆地链路与空中接口，trauloss和RCI等（结合GSR6新功能）

Ø设备电源风扇等类型－IAS等

Ø外部告警类型－注意非motorola的告警提取方式时对系统的影响

Ø

2.性能指标分析

vma_fail_from_ms

ma_fail_from_ms是手机在分配信道时因底层错误而返回的消息，当相应基站无信道拥塞且IOI和BER都正常时，说明该站有载频故障，需利用工具软件从该站emon进程中filter出相关信息，定位出故障载频。

建议门限值为故障小区ma_fail_from_ms与该小区total_call比值小于5％且忙时该小区ma_fail_from_ms小于50。

当发现某小区MA_FAIL_FROM_MS很高时，先检查该小区TCH是否拥塞、载频的IOI是否正常。

如果小区拥塞，建议扩容或降低基站发射功率；如果是载频的IOI高，说明该小区存在严重干扰，导致较多的TCH信道分配失败，必须到现场用仪器查找干扰源。

若不拥塞且IOI正常，先reset基站后再继续观察；如果问题仍存在，检查该小区的percarrier的path_balance、rf_loss、BER等是否正常；若有载频不正常，则根据以上载频问题对载频进行排障。

如果上述检查都正常，则可能是载频有故障。

接下来，我们必须定位是哪个载频的问题。

首先，我们通过MMI登录到该小区的BSC，chg_l到level3，set_mmiexec_mon到BSC的emon（executemonitor）状态，再rloginsite_No+11015h到基站，然后开始做filter。

先createfilter，命令如下：

先进3级状态：

1：

set_mmiexec_mon

2:

rlogin站号加11015h

filtercreatetag0xxxx0201hmsg[9]6msg[10]2eh

filtercreatetag0xxxx0202hmsg[9]6msg[10]29h

filtercreatetag0xxxx0202hmsg[9]6msg[10]2fh

filterstartall

结束：

filterstopall

filterdeleteall

filterlist

f7退出

filter开始后，在OMCR终端上将所出现的filter信息log成文件。

在这里，我们需要根据话务量的忙闲程度来确定filter时间，目的是收到尽量多的filterlog以便分析。

同时为了准确，在做以上的filter时，尽量安排在系统的最忙时，以便在该站的所有载频都能充分被利用来分配信道时收集数据。

因为在基站比较空闲时，可能有些有问题的载频根本就没有什么机会被分配TCH信道，即使该载频有问题也难以发现。

最后，将filterlog通过ftp下载到自己的便携机，通过运行邬兵武老师编的程序来查找是哪个载频存在问题。

在找出载频后，可以先ins该载频，再观察下一段时间该载频是否还存在MA_FAIL_FROM_MS高的情况；假如仍然偏高，则需更换载频。

vpath_balance

path_balance是衡量载频上下行损耗是否平衡的指标。

通过观察该指标，我们可以发现潜在的天馈线、载频、数据库等是否存在问题。

对于采用两路以上分集接收的无线系统，path_balance指标的正常值在100～110之间，最好在105左右；而对于仅用单路接收的系统，path_balance的最佳值为110。

vBER

BER是衡量载频的上下接收质量的指标，BER高的载频，说明该载频上行质量差，会造成通话断续、噪音、单通、金属声、切换失败、掉话等现象。

BER的门限值建议为平均不高于1且该载频任一时隙不高于2。

有两种可能会造成BER偏高：

1，载频故障；2，频率规划。

这种情况下，我们先检查该站的所有载频IOI是否正常。

假如不正常，说明该站存在干扰，需干扰排障或改频。

假如IOI正常，则可能是载频故障，需更换载频。

目前，有一些载频存在一种“奇偶效应”现象。

也就是只在奇数或偶数时隙，BER不正常，但其他时隙则正常。

这种情况目前也只能采取更换载频的方式解决。

vIOI分析

IOI是interferenceonidle的简称，即载频在信道空闲时期监测该时隙的上行干扰级别，用于衡量系统的干扰情况。

IOI高的小区说明存在内部或外部干扰，会导致较多的信道分配失败、呼叫失败、话音断续、切换失败、掉话等现象。

在CMCC系统指标考核忙时，统计全网的载频IOI指标，过滤出IOI高的载频，分析其是因系统内部还是外部干扰引起的。

如果确实存在内部或外部干扰，则建议改频；否则可能是载频或接收通路的器件问题，需要现场排障解决。

vGPROC统计－

vMTL统计－信令收发，断续等

vRSL统计－信令收发，断续等

vCarrier统计－BER,IOI,PB等

vCell统计

v

3.DT/CQT分析

在DT/CQT时，有时会发现占上同扇区的不同载频手机时，MSRxlev突然陡降或者MSQuality极差；或者发现存在不该有的切换、越区覆盖、扇区交叉或相反等现象。

通过对这些问题的分析处理，可以解决无线网络现场实测中碰到的问题，从而优化、提高网络性能。

以下几张图就是杭州现网CQT时发现的“温州村”基站天馈线问题实例分析。

图－2

图－3

图－4

由第一张图可以看出，手机在sdcch信道时收到“温州村”基站2扇区的MAIO为0（经事后核对现网数据得知是DRI11）载频的信号强度为-70dBm左右，分配TCH信道后，手机收到MAIO为3、4（事后查基站数据库为DRI14/15）的载频信号强度都很低，低于-100dBm，而且此时下行Quality很差，造成话音断续。

因为这两个载频刚好合路共用同一根天馈线，所以可能是该基站合路器或天馈线问题（天馈线接反、天馈线断、天线端口坏等）。

小结：

在采取以上告警分析流程后，对现网告警故障的分析结果按对系统的危害程度排出优先级，列出故障告警表，提出处理建议和处理期限，并跟踪处理进展。

每个月月底总结提交当月的告警故障月报。

四、协维工作

1，协助客户解决各类疑难故障；

2，观察系统忙时的GPROC/MTL/RSL/TCH_BLOCKING等网络负荷，提供解决方案，协助客户预防BSC处理器过载导致退服；

3，对rf_loss_tch、tch_blocking相关的最差小区进行分析及优化。

五、工作周期、日程及进度安排建议

1，对于ECTLOG的分析只需每2周或1个月做一次，平时跟踪其告警总量及波动趋势即可；EVENTLOG用于协助分析更具体详细故障；disp_act_alarm则可在线观察现网当前告警，实时发现问题。

由于disp_act_alarm观察及分析起来较慢，每隔一段时期，轮流查看分析几个BSS的状态即可。

2，对于指标类分析，一般以2周为周期，统计分析、处理建议及处理进度跟踪。

3，关于路测的问题分析按路测时间来定。

4，每隔一段时间安排一种专项优化方向，例如path_balance专项优化、IOI专项优化、BER专项优化、rf_loss_tch专项优化等等。

5，在日常工作中同时关注如chan_req_fail、handover_failure的指标，协助其他优化function分析故障

6，最后，在非常时期，优先考虑协维工作应负责的客户紧急请求技术支持、疑难工单处理、节假日通信系统运行保障及预防等事项。

六、杭州2004’MOTOVIP年度计划（硬件与告警处理）

第1阶段：

2月初至3月底中旬。

降低杭州无线网络日均产生告警总量，期望将市区和郊区的日均告警总量分别由3.5万、7.5万左右都降到2万以下；解决对系统安全有严重威胁或隐患的故障；协助客户解决疑难故障，处理协维工单。

第2阶段：

3月中旬至7月。

监控每日全网告警，解决严重、重要的故障，保障网络运行安全、稳定；分析告警分布及趋势，保持全网日均产生的告警总量的平稳下降；分析对小区性能和统计有负面影响的BSP/BTP、GPROC、GCLK、载频、天馈系统等设备，优化网络性能；协助客户解决疑难故障，处理协维工单。

第3阶段：

7月份至年底。

协助客户日常的系统维护、优化，保障系统安全运行；跟踪分析系统每日告警分布及趋势，保持系统告警总量稳定在一定范围；日常优化工作，协助客户解决疑难故障，处理协维工单。