BSS常见告警分析.docx

BSS常见告警分析.docx

《BSS常见告警分析.docx》由会员分享，可在线阅读，更多相关《BSS常见告警分析.docx（29页珍藏版）》请在冰豆网上搜索。

BSS常见告警分析

引言

机房运行维护人员经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致BSS复位，对移动通信系统造成严重影响。

因此对于运维人员来说，了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。

本文档正是从这个角度出发，简单介绍了MOTOROLA移动系统产品的告警系统和告警格式，并详细分析了常见的十类BSS告警。

我们希望通过告警分析，能够帮助运维人员提高分析处理告警的能力。

本文档包括两部分主要内容，前一部分介绍了MOTOROLA产品的告警系统和告警格式，后一部分深入分析了常见的十类BSS告警。

在本文结束前给出了在处理告警时一些需要注意的东西。

第一部分MOTOROLA移动系统产品的告警系统和告警格式

MOTOROLA的告警系统是为了故障定位，系统性能分析及方便维护而设置的。

告警信息可以在OMCR的告警窗口上显示，也可以在本地维护终端（LMT）上显示。

BSS产生的告警信息，以字符的形式发往OMCR。

也可以通过命令设置使告警显示在LMT上。

告警可以分为硬件告警和软件告警两种：

·硬件告警是由于BSS内的硬件故障所引起的告警。

·软件告警是由GPROC检测到软件进程运行出错所引起的告警。

只有GPROC设备（BSP，CSFP，DHP，BTP，poolGPROC）才会产生软件告警信息。

软件告警（SoftwareFaultManagement或SWFM）分为两类。

Fatal和non-fatal软件告警

软件告警

SWFM类型

等级

影响

SWFM

NON-fatal

警告

SWFM调用相应的进程来恢复软件错误

Fatal

严重

SWFM将GPROCreset

下面通过一个告警实例来了解MOTOROLA产品的告警格式。

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

#0–NEW–*NONE*.

CommuncationFailureEvent-CAGE-BSS01（BSS01:

SITE-0:

）:

0CAGE1-30/03/199914:

23:

56.

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

（BSS01:

SITE-0:

）:

0SITEImpactedtoMajor.

字段意义：

#0：

告警ID

NEW：

告警状态

NONE：

正在处理此告警的人员

CommuncationFailureEvent：

告警的类型

在OMCR将告警分成六种不同的类型，可以在OMCR的告警说明中找到"FailureEvents"字段，其为不同类型告警的名称。

类型

含义

举例

Communication

数据从一点传到另一点时发生错误而产生的告警

一般当信令丢失或呼叫建立出错时发生此种告警

QualityofService

系统的服务质量下降时产生此告警

一般当消息响应超时或带宽减少时会发生此种告警

Processing

当软件或进程出现错误时产生此告警

一般当进程数据被破坏或系统内存溢出时产生此种告警

Equipment

当硬件出错时产生此告警。

一般当出现配置错误，传输、电源等问题时产生此种告警

Environment

当设备所处的环境不利于正常工作时产生告警

一般当出现烟雾，火光被检测到时产生此种告警

Link

当OMCR与BSS间的X.25链路出现问题时产生此告警

CAGE：

告警级

BSS01（BSS01:

SITE-0:

）:

0CAGE1：

发生告警的位置

30/03/199914:

23:

56：

告警发生时间

[18]：

告警编号

告警编号对于每种设备都有唯一的一个十进制数表示。

每种设备的告警编号从0到254。

对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。

有些情况下同样的告警编号表示类似的告警。

例如254号告警表示设备fail。

ExpansionKSWXSlot22CommunicationFailure：

告警描述

FMIC：

告警的清除类型

告警的清除类型可分为三类：

⒈Intermittent

⒉FaultManagementInitiatedClear（FMIC）

⒊OperatorInitiatedClear（OIC）

第一类：

表示告警是偶发性的，对系统没有危害。

因此此告警发生后在OMCR会自动消除。

当此类告警产生太频繁，会造成到OML链路负担过重。

因此用户可以使用两条命令查看，调节此类告警向OMCR报告的量。

disp_throttle

chg_throttle

第二类和第三类为持续性的告警，当告警原因消失后需要将此告警清除。

第二类：

告警的清除由系统的错误管理进程（FaultManagermentProcess）自动将其清除。

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

第三类：

需要由操作人员手动将告警清除。

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

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

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

Major：

告警严重等级

告警严重级别表明此故障发生对系统的影响程度。

系统将告警的等级分为6级。

影响

行动

举例

严重

（Critical）

已经影响了系统的服务

应该立即采取措施

当系统的某一功能出现此种告警而退出服务，应立即将其恢复。

重大

（Major）

已经影响了系统的服务

应该马上采取措施

系统的服务容量降低，此时应采取措施恢复容量。

较轻

（Minor）

此错误不会对系统的服务造成影响

应该采取措施减少更多的此类告警产生

当此种告警数量不断增加时，系统的容量可能受到影响。

警告

（Waring）

潜在产生影响系统服务的告警的可能

如果必要应该进行必要的分析，采取措施避免产生更严重的告警

清除

（Clear）

告警已经被清除

无

待定

（Investigate）

表明此错误的等级无法确定，需要人工进一步分析

进一步查找原因

告警的等级可以查看也可以根据要求改变。

使用以下两条命令可以查看和改变告警的等级：

查看告警的等级

disp_severity

改变告警的等级

chg_severity

例如：

disp_severityDRI12

DRIAlarmCode12severity:

WARNING

chg_severityDRI12major

COMMANDACCEPTED

（BSS01:

SITE-0:

）:

0SITEImpactedtoMajor:

告警附加信息

在OMCR上按以下步骤可以清除告警：

·打开告警窗口，选中要清除的告警项。

·单击鼠标右键弹出快捷菜单。

·选择快捷菜单的“Handle”。

·选择快捷菜单的“Clear”。

·确认告警已被清除。

也可在BSS清除告警，先使用disp_act_alarm命令查看有哪些OIC告警。

然后使用del_act_alarm命令将告警清除，格式如下：

del_act_alarm

第二部分常见的十类BSS告警

不同的告警只在其特定的告警条件下才会发生，但是有些告警发生得多一些比较普遍，而有些告警出现得很少，在一个短短几十页的文档中想要把所有的告警都包括进来是不可能的。

这里我们根据现有的资料和经验，分析了经常碰到并具普遍意义的十类BSS告警，通过这些告警的分析，希望能够拓宽读者的思路，帮助读者提高处理告警、排除故障的能力。

一.OML为E-U或D-U的问题。

在BSC或RXCDR看到此现象时，还可能看到相关的一些告警，如OML242号告警等。

背景原理：

OML链路是OMCR到RXCDR或BSC的信令链路，主要用于BSS的操作维护。

OML使用X.25协议。

OMCR通过Router与BSS相连，在BSS端，操作数据在2M线的某些时隙中传输，到达Router后，Router中的虚拟交换电路把它们分门别类送往OMCR进行处理。

同时OMCR的数据也通过Router交换后发往相应的NE。

可能引起此类告警的原因：

①相关的MMS口退出服务

②主用MSI板没有插

③数据库中关于OML链路的定义不对

④DTE地址定义不对

⑤路由器定义不对

⑥软件进程问题

解决思路：

如果OML链路从来没有起来过，那么首先应该检查硬件连接是否正确，特别是主用的MSI板是否插上了，因为主用MSI板上定义了NE起来时用于从OMCR下载软件和数据库的OML链路。

然后核对DTE地址及路由器的设置是否正确。

如果OML链路以前是好的，那么首先要搞清是否有人对OML相关的参数改动过，如数据库中关于OML链路的定义、DTE地址、路由器设置等。

在确认没有改动过后，应检查硬件问题，如MMS口是否退服、MSI板是否故障等。

硬件也没有问题时，可初步确定为软件进程问题，可以设置一些Filter收集进程数据，并对相关的几个进程作一些操作（如重启进程）来恢复OML链路。

参考操作步骤：

OML链路的问题涉及的设备比较多，例如：

OMCR，路由器，RXCDR等，为了正确定位故障应结合数据收集来处理问题。

⑴进入BSC键入state0命令查看BSC的状态。

进入RXCDR键入state0查看RXCDR的OML状态。

在RXCDR键入disp_links查看RXCDR内的链路连接，以确定与OML相关的MMS位置。

在出现问题的BSC或RXCDR中键入disp_p0查看哪个GPROC控制OML链路。

键入disp_act_a0查看是否有相关的告警。

键入disp_eq0oml**查看每条OML的配置情况。

⑵进入控制OML的GPROC

filtercreatedest72htag2101h

filtercreatedest72htag2104h

filtercreatedest42htag2103h

filtercreatedest80htag1f64h

filtercreatedest72htag1f65h

filtercreatedest80htag0xx63h

filtercreatedest72htag2111h

（以上命令为获取发往72h，42h，80h进程的某些消息）

iir_mod72h4h

（此命令为获得AGENT进程的配置信息和出错数据）

等待5分钟不进行任何的操作，

⑶键入以下命令

msg_send80h5h001fffh00（输出PLP进程的信息）

msg_send72h14h0021ffh（输出AGENT进程的信息）

⑷lock/unlockOML，看OML的状态。

⑸键入以下命令

msg_send80h5h001fffh00

msg_send72h14h0021ffh

当站空闲时进行6，7的操作。

⑹lock/unlockOML所属的MMS，查看OML的状态。

⑺lock/unlockOML所属的MSI，查看OML的状态。

如果OML仍为E-U状态，进行如下操作。

⑻键入以下命令（停止和激活AGENT进程）。

msg_s68111272h（停止AGENT进程）

msg_s68111172h（激活AGENT进程）

然后lock/unlock此OML链路。

⑼键入以下命令（停止和激活AGENT进程、X.25PLP进程）：

msg_s68111272h（停止AGENT进程）

msg_s68111280h（停止PLP进程）

msg_s68111172h（激活AGENT进程）

msg_s68111180h（激活PLP进程）

然后unlock/lock此OML。

⑽如果OML仍然无法恢复，将前面加的Filter都删除，加入以下的Filter。

filtercreatedest13hsrc80h（获取从80h进程到13h进程的消息）

filtercreatedest80hsrc13h（获取从13h进程到80h进程的消息）

⑾保持10秒钟，将两个Filter删除。

如果OML仍然无法恢复，先收集此GPROC的SWFM，然后reset此GPROC。

如仍不能解决问题将BSCreset。

二.GCLK无法锁相的问题。

此时会产生GCLKFailedPhaseLock的提示，并可能伴随出现4、14、13号等告警。

背景原理：

GLCK的功能是使得系统与更准确的时钟同步，对于BSS来说，GCLK要与MSC的时钟同步。

时钟同步的目的是在射频部分提供0.05ppm（ppm为百万分之一。

即如时钟为16.384M，则频率误差为16.384×0.05=0.8192Hz）的高精度的时间同步。

因此要提供参考时钟的E1/T1链路要尽量减少滑帧和失同步。

GCLK要与上一级时钟同步必须要有上一级时钟的参考信号，时钟参考信号是根据数据库的定义从指定的MMS口上提取的。

在database中需要定义不同MMS口的时钟提取优先等级。

GCLK在工作时有四种不同的状态：

①自由振荡状态：

此状态是当GCLK刚上电时，其内部的晶体振荡器（OCXO）需要有预热的过程，以保持其正常的工作环境。

此时间是固定不变的（30分钟），无法更改。

在自由振荡状态下，GCLK内的DAC输入为80H，时钟输出保持在0.05ppm的精度内。

②HoldFrequency：

此状态是GLCK与2M失锁时的状态。

此时GCLK使用前一次ADC输出的值输入DAC以控制时钟，此状态是一个过渡状态，一般持续10秒。

③SetFrequency：

此状态一般在HoldFrequency之后。

使用LTA（LongTermAverage）值输入DAC以控制时钟。

正常锁相工作时GCLK每30分钟采样一个ADC输出值——2位16进制数，存入内部存储器，存储器最大可以存放48个值，采用先入先出原则更新。

这48个值也可以被GPROC通过MCAP总线读取或设置。

所谓LTA就是指将这48个值取平均输入到DAC。

SetFrequency状态下，GCLK不再往存储器中存放新值，只是使用以前的旧值，存储器停止更新，这是与锁相状态的不同之处。

④锁相状态：

此状态分为两个子状态，

AcquiringFrequencyLockState

此状态是一个过渡状态，由硬件决定。

FrequencyLockState

此状态内GCLK已与E1/T1锁相，但需等待一段时间，以确定锁相稳定之后就进入锁相状态。

GCLK要与E1/T1同步必须有合适的时钟提取端口，这些端口的优先级按以下原则确定：

①MMS是否为B-U

②MMS的等级（在database中定义）

③在一定时间内MMS处于OOS状态的次数

④如果以上都相同，则轮流作为时钟源

除了MMS口的等级外，在DATABASE中还有一些参数与GCLK有关：

chg_elphase_lock_gclk<*>

<*>0Disablephaselocking

1Enablephaselocking

此命令设置是否允许时钟同步。

chg_elwait_for_reselection

1to255（缺省值为10）

此命令设置当一个MMS的时钟提取出现问题时，多长时间后切换到其它的MMS口提取时钟。

modify_valuemms_priority<*>mms

<*>0to255

此命令设置MMS的优先级，其中0表示禁止从此口提取时钟。

chg_ellta_alarm_range

1to255（缺省值为7）

此命令设置当存储器内的值有25%超出LTA值的时产生告警。

reattempt_pl

此命令要求GCLK尝试重新锁相（只有当GCLK前一次锁相失败时才能使用此命令）。

modify_valuephase_lock_duration

mms

0to255（缺省值为0）、

此命令表示当GCLK与E1/T1链路在多长时间内能锁住，并保持在+/-0.05ppm内.就认为可以选取此MMS作为时钟源。

可能引起此类告警的原因：

①因传输问题引起MMS退服

②MSI板或MMS口硬件故障

③数据库定义不合理

④GCLK本身的问题，需要校正或更换

解决思路：

当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。

检查一下数据库中有关GCLK的参数设置是否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS（只有菊花链的情况）锁，向下一端的MSI口的时钟提取优先级应设为0，另外也不能只允许一个MMS口可以提取时钟。

如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的，也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常则应着重检查传输质量。

在排除了数据库、MSI硬件和传输原因之后，应校正或更换GCLK板。

参考操作步骤：

⑴为了利于问题的分析应收集以下数据：

①stategclk**（查看GCLK的状态）

②disp_elphase_lock_gclk（查看是否允许锁相）

③disp_eq0mms（查看MMS的参数，主要是时钟提取优先级）

④disp_elwait_for_reselection（查看时钟提取切换时间）

⑤disp_ellta_alarm_range（查看LTA告警范围）

⑥disp_gclk_avgs（查看GCLK的长期平均值）

⑦disp_eqgclkfull（查看GCLK硬件版本信息）

⑵当GCLK无法锁相时可采用以下的方法：

①reattempt_pl

②使用lock/unlock命令看是否能使得GCLK锁相恢复。

③查看MSI，MMS是否处于正常状态，是否有E1的相关告警产生，是否有MMS作为时钟源。

④查看提供时钟的MMS是否与上一级的链路连接，上一级的时钟是否正常工作。

⑤查看提供时钟的MMS的等级是否设置正确（一般为255）。

⑥试着使用其它的MMS作为时钟源。

（对于M-CELL可更换NIU）。

⑦重新校准GCLK的时钟，具体校准的过程可见MOTOROLA手册（68P02901W43，第二章为GCLK调测，第三章为MCU时钟调测，第四章为MCUm的时钟调测）。

⑧如果出现无法校准，备用端的GCLK也不能用，并且没有备件。

用仪表检查上行和下行链路的时钟，看是否为2.048M。

可使用hp37717C分析仪。

以确定是那一端出现问题。

注意：

在151X版本软件中将GCLK的锁相精度要求被额外提高了，所以容易产生失锁告警，但并不一定表明此GCLK有问题，对系统正常工作也没有影响。

此问题只存在于M_CELL，在160X版本中已经将此解决。

三.MMS告警和退出服务

背景原理：

在MOTORLOA系统中除了硬件问题有四种与传输相关的情况会导致MMS告警或退出服务。

1BER（BitErrorRate）误码率

MMS通过监测0时隙的固定位来计算误码率，ber_loss_daily和ber_loss_hourly分别定义了24小时和1小时误码率的门限值，误码率超出门限值时，就会产生误码率告警。

ber_oos_mon_period定义了误码率监测时间长度，在这个时间长度内误码率超过1‰（由MMS硬件决定），MMS将要退出服务。

②Syncloss失同步

MMS通过检测同步位来与对端同步，当同步位出错时，算失同步一次。

失同步时间超过sync_time_oos设定的值时，MMS将退出服务。

重新同步后，时间超过sync_time_restore设定的值后，MMS重新进入服务。

当24小时和1小时内的失同步次数分别超出sync_loss_daily和sync_loss_hourly定义的值时，MMS会产生sync_loss告警。

此外24小时内失同步的次数超出sync_loss_oos定义的值时，MMS也会退出服务，同样恢复正常后时间超过sync_loss_restore定义的时间，MMS重新进入服务。

③Remotealarm对端失同步告警

对端MMS失同步后，会回送一个失同步标志。

MMS检测到此标志后开始计时，对端失同步时间超过remote_time_oos定义的时间，MMS就退出服务。

对端失同步恢复后，超过remote_time_restore定义的时间，MMS就重新进入服务。

24小时和1小时内对端失同步的次数分别超出remote_loss_daily和remote_loss_hourly定义的值时，MMS会产生remote_alarm告警。

24小时内对端失同步次数超出remote_loss_oos设定的值时，MMS也会退出服务，对端恢复后超出remote_loss_restore定义的时间，MMS就重新进入服务。

④Frameslip滑码

24小时和1小时内滑码的次数分别超出slip_loss_daily和slip_loss_hourly定义的值时，MMS会产生frame_slip告警。

24小时内滑码次数超出slip_loss_oos设定的值时，MMS会退出服务，滑码恢复后超出slip_loss_rest