BSS高级维护V20.docx

BSS高级维护V20.docx

《BSS高级维护V20.docx》由会员分享，可在线阅读，更多相关《BSS高级维护V20.docx（141页珍藏版）》请在冰豆网上搜索。

BSS高级维护V20

BSS高级维护

目录

序论……………………………………………………………………1

维护工作的要旨——防患于未然……………………………2

分析问题的一般思路……………………………………………4

第一章告警处理……………………………………………………7

一、告警格式与组成……………………………………………10

告警的种类和格式……………………………………10

告警编号和消除类型…………………………………12

告警的类型……………………………………………14

告警的等级……………………………………………15

二、告警处理流程………………………………………………18

告警的查看……………………………………………18

告警处理优先级别……………………………………20

三、常见的十类BSS告警………………………………………24

OML为E-U或D-U的问题…………………………24

GCLK无法锁相问题…………………………………30

MMS告警和退出服务………………………………35

DRI12号告警………………………………………39

BSP239号告警……………………………………41

MTL告警……………………………………………43

IAS1号告警………………………………………46

BSS22号告警………………………………………48

GPROC245号告警…………………………………50

TIMESLOT0号告警………………………………51

四、注意要点……………………………………………………53

第二章实际故障处理解析………………………………………55

一、TCU故障处理………………………………………………57

TCU问题与原因分析………………………………58

MCELL、TCU简介……………………………………60

故障处理流程…………………………………………62

一些有用的命令………………………………………65

实例……………………………………………………70

附录……………………………………………………76

二、BTS启动分析………………………………………………78

BTS启动TroubleShooting的主要工作流程………79

怎样用PCMCIA卡起站………………………………82

MIP的分析……………………………………………86

传输问题的一般检查步骤和注意点…………………93

三、BSCreset分析………………………………………………94

BSCreset的原因概括………………………………95

处理BSCreset的简单流程…………………………97

处理BSCreset的命令………………………………99

BSCreset的具体分析………………………………103

BSCreset的分析实例………………………………112

日常维护的注意事项………………………………116

第三章典型操作精解……………………………………………117

一、时钟校准……………………………………………………118

BSC&RXCDR时钟校准……………………………118

MCU时钟校准………………………………………122

附录：

常见告警的分类……………………………………………125

BCUP………………………………………………………126

BSS…………………………………………………………126

CAGE………………………………………………………127

CBL…………………………………………………………128

CBUS………………………………………………………128

CELL…………………………………………………………129

COMB………………………………………………………130

EAS…………………………………………………………137

GCLK………………………………………………………138

GPROC………………………………………………………139

IAS…………………………………………………………140

KSW…………………………………………………………141

LAN…………………………………………………………142

MMS…………………………………………………………143

MSI…………………………………………………………145

MTL…………………………………………………………146

OMC…………………………………………………………147

OML…………………………………………………………148

PATH…………………………………………………………148

PBUS…………………………………………………………149

RSL…………………………………………………………149

SBUS…………………………………………………………150

SITE…………………………………………………………150

TBUS…………………………………………………………151

TDM…………………………………………………………151

TIMESLOT…………………………………………………152

TRU…………………………………………………………152

XBL…………………………………………………………152

第一章告警处理

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

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

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

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

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

本章还给出了在处理告警时一些需要注意的东西。

一、告警格式与组成

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

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

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

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

1、告警的种类和格式

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

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

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

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

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

（如右表所示）

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

Fatal和non-fatal软件告警

软件告警

SWFM类型

等级

影响

SWFM

NON-fatal

警告

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

Fatal

严重

SWFM将GPROCreset

告警举例：

#0–NEW–*NONE*.

CommuncationFailureEvent-CAGE-BSS01（BSS01:

SITE-0:

）:

0CAGE1-30/03/199914:

23:

56.

ExpansionKSWXSlot22CommunicationFailure-FMIC-Major--/-.

（BSS01:

SITE-0:

）:

0SITEImpactedtoMajor.

#0：

告警ID

NEW：

告警状态

NONE：

正在处理此告警的人员

CommuncationFailureEvent：

告警的类型

CAGE：

告警级

BSS01（BSS01:

SITE-0:

）:

0CAGE1：

发生告警的位置

30/03/199914:

23:

56：

告警发生时间

[18]：

告警编号

ExpansionKSWXSlot22CommunicationFailure：

告警描述

FMIC：

告警的清除类型

Major：

告警严重等级

（BSS01:

SITE-0:

）:

0SITEImpactedtoMajor:

告警附加信息

2、告警编号和消除类型

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

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

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

有些情况下同样的告警编号表示类似的告警，例如254号告警表示设备fail。

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

Intermittent、FaultManagementInitiatedClear（FMIC）、OperatorInitiatedClear（OIC）。

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

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

当此类告警频繁产生时，会增加OML链路的负荷。

我们可以使用disp_throttle命令来查看告警门限设置，还可用chg_throttle命令调节其门限值。

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

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

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

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

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

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

在OMCR和BSC上均能够清除告警。

OMCR上清除告警按以下步骤进行：

打开告警窗口，选中要清除的告警项；单击鼠标右键弹出快捷菜单；选择快捷菜单的“Handle”；选择快捷菜单的“Clear”；确认告警已被清除。

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

然后使用del_act_alarm命令将告警清除。

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

Intermittent

FaultManagementInitiatedClear（FMIC）

OperatorInitiatedClear（OIC）

%OMCR清除告警步骤：

打开告警窗口，单击鼠标左键选中要清除的告警项

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

选择快捷菜单的“Handle”

选择快捷菜单的“Clear”

确认告警已被清除

BSS清除告警，格式如下：

del_act_alarm

3、告警的类型

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

类型

含义

举例

Communication

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

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

QualityofService

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

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

Processing

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

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

Equipment

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

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

Environment

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

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

Link

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

4、告警的等级

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

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

影响

行动

举例

严重

（Critical）

已经影响了系统的服务

应该立即采取措施

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

重大

（Major）

已经影响了系统的服务

应该马上采取措施

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

较轻

（Minor）

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

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

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

警告

（Waring）

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

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

清除

（Clear）

告警已经被清除

无

待定

（Investigate）

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

进一步查找原因

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

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

查看等级disp_severity（device_name就是告警属于什么类，比如DRI\KSW\BSS等）

改变等级chg_severity

例如：

MMI-RAM0115>disp_severityDRI12

系统显示：

DRIAlarmCode12severity:

WARNING

MMI-RAM0115>chg_severityDRI12major

系统显示：

COMMANDACCEPTED

二、告警处理流程

1、告警的查看

有关告警的窗口不论是打开还是处于最小化，当有新的告警产生时，都会自动添加在告警的窗口中。

在OMCR上可以用多种方法查看告警。

第一种方法是在OMCR桌面图形界面GUI上双击告警按钮，打开告警窗口，可以看到所有网元（NE）的告警信息；第二种方法是点击GUI上的EVENTMAMT按钮，打开DisplaySubscriptionList窗口，选择窗口中告警中的一项，选择open按钮就打开告警窗口；第三种方法是从NETWORKMAP上查看告警，单击GUI上的NETWORKMAP按钮，打开MAPLIST窗口，选定其中的一个网元，双击鼠标左键打开MAP窗口，在MAP图上用鼠标左键点击要查看的网络单元节点，选中后接点会变为紫色，单击鼠标右键在快捷菜单内选择ALARM项，此时会出现告警窗口显示此节点单元的所有告警。

打开告警窗口之后，查看告警的状态项，新产生的告警状态项为NEW，操作者为NONE。

新告警被选中后会改变颜色，比如Critical告警的告警字为黑色，背景为红色，对于其它种类告警的告警字为白色，背景为黑色，并且告警的状态项变为SEEN，表明有工程师已经阅读了该项告警。

如果需要对告警的处理添加说明，可以在快捷菜单里选择commence项，加入文字解释。

%打开告警窗口的三种方法

OMCR桌面图形界面GUI上的ALARM按钮

通过GUI上的EVENTMANEGMENT

打开MAP图，然后选中对应的单元节点

告警窗口中状态项为“NEW”的告警是新产生需要处理的告警。

2、告警处理优先级别：

我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进行相应的处理。

在此我们提供一般原则下的优先级别。

对于基站来说从RXCDR到BSC，再到BTS；信令链路按照MTL、RSL、XBL的次序；告警严重级别由高到低分别是Critical、Major、Minor、Warning、Investigate、Clear。

在相同的告警级别中，Critical告警按照以下顺序AllRXCDR-AllMTL-AllBSC-AllRSL-AllBTS-AllX.25link-AllotherCriticalalarms。

Major告警按照以下顺序AllRXCDR-AllBSC-AllBTS-AllotherMajoralarms。

其它告警按照Minor、Warning、Investigate、Clearalarms的顺序进行处理。

%告警处理的优先级别

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

当某个设备或链路处于OOS等非正常状态时，不仅与起本身相关，而且与其上一级（parent）设备有关，对parent设备进行必要的处理是解决问题的重要手段。

如果某个设备处于OOS等状态下，此设备下一级（child）设备不能正常工作。

在此我们给出常见的设备之间的从属关系（parent-child）：

Device

1stparentdev

2ndparentdev

3rdparentdev

4thparentdev

RSL

MMS

MSI

CAGE

CABSITEBSS

MTL

MMS

MSI

CAGE

CABSITEBSS

OML

MMS

MSI

COMB

DRI

RCU

DRI

CAGE

CAB

SITEBSS

XBL

MMS

MSI

CAGE

CABSITEBSS

三、常见的十类BSS告警

某些的告警只在特定的告警条件下才会发生，有些告警发生得多一些，比较普遍。

我们无法把所有的告警都进行详细的分析，并且这也没有必要。

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

我们在本书的附录中列举了其它告警的扼要信息，供工程师查考。

1、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。

filtercreatedest13hsrc