BSC告警分析课件

BSC/RXCDR/PCU告警分析内容简介告警格式与组成告警处理的优先级别常见的BSS告警告警的格式与组成告警的种类和格式告警可以分为硬件告警和软件告警两种：硬件告警是由于BSS内的硬件故障所引起的告警。软件告警是由GPROC检测到软件进程运行出错所引起的告警。只有GPROC设备（BSP，CSFP，DHP，BTP，poolGPROC）才会产生软件告警息。软件告警（SoftwareFaultManagement或SWFM）分为两类。告警的类型告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从0到254。对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的告警编号表示类似的告警。例如254号告警表示设备fail。在OMC-R上将告警分成不同的六种类型，可以在OMCR的告警说明中找到“FailureEvents”字段，其为不同类型告警的名称。它们分别是：告警的等级告警严重级别表明此故障发生对系统的影响程度，系统将告警的等级分为六级：告警处理的优先级我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进行相应的处理。在此我们提供一般原则下的优先级别。对于基站来说从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的顺序进行处理。常见的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板是否故障等。处理步骤⑴进入BSC键入state0命令查看BSC的状态；⑵进入控制OML的GPROC；⑶运用msg_send命令；⑷lock/unlockOML，看OML的状态；⑸再运用msg_send命令；⑹lock/unlockOML所属的MMS，查看OML的状态；⑺lock/unlockOML所属的MSI，查看OML的状态；如果OML仍为E-U状态，继续以下步骤。⑻键入命令以停止和激活AGENT进程，然后lock/unlock此OML链路；⑼键入命令以停止和激活AGENT进程、X.25PLP进程然后unlock/lock此OML；(10)排除硬件故障，考虑是软件进程问题造成OML故障，可以考虑激活挂OML的GPROC，如果还是不能解决可以考虑resetBSC。2、GCLK无法锁相的问题

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秒。可能引起此类告警的原因：①因传输问题引起MMS退服②MSI板或MMS口硬件故障③数据库定义不合理④GCLK本身的问题，需要校正或更换解决思路：当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。检查一下数据库中有关GCLK的参数设置是否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS（只有菊花链的情况）锁，向下一端的MSI口的时钟提取优先级应设为0，另外也不能只允许一个MMS口可以提取时钟。如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的，也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常则应着重检查传输质量。在排除了数据库、MSI硬件和传输原因之后，应校正或更换GCLK板。参考操作步骤：⑴为了利于问题的分析应收集以下数据：①state<location>gclk**（查看GCLK的状态）②disp_elphase_lock_gclk<location>（查看是否允许锁相）③disp_eq0mms<id1><id2><id3>（查看MMS的参数，主要是时钟提取优先级）④disp_elwait_for_reselection<location>（查看时钟提取切换时间）⑤disp_ellta_alarm_range<location>（查看LTA告警范围）⑥disp_gclk_avgs<location><gclk_id>（查看GCLK的长期平均值）⑦disp_eq<location>gclk<id_1><id_2><id_3>full（查看GCLK硬件版本信息）⑵当GCLK无法锁相时可采用以下的方法：①reattempt_pl<location><gclk_id1>②使用lock/unlock命令看是否能使得GCLK锁相恢复。③查看MSI，MMS是否处于正常状态，是否有E1的相关告警产生，是否有MMS作为时钟源。④查看提供时钟的MMS是否与上一级的链路连接，上一级的时钟是否正常工作。⑤查看提供时钟的MMS的等级是否设置正确（一般为255）。⑥试着使用其它的MMS作为时钟源。（对于M-CELL可更换NIU）。可能引起此类告警的原因：①MSC传来的MTP第二层LSSU信息出现错误。②MSC端拥塞超时③MSU确认消息超时④序列号出现错误⑤SUERM的错误门限值超出⑥收到不正常的FIB解决思路：先检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出服务，再查与MSC的信令点码是否正确，在确认上述方面无问题后检查GPROC是否有硬件问题，必要时复位该GPROC。参考操作步骤：⑴根据告警消息找到出现问题的站号，MTL的设备编号。⑵在RXCDR键入：disp_linksdisp_bss_conn

以确定MTL链路的连接情况。⑶键入disp_equip0MTL**得到MTL的配置情况。⑷查看与MTL相关的设备是否正常工作state0mms**查看MMS的状态state0msi**查看MSI的状态disp_p0查看MTL由那个GPROC控制disp_act_a0查看是否有相关的告警出现了相关的设备告警时应先处理这些相关问题。⑸使用lock／unlock、ins命令试着恢复链路。⑹检查RXCDR或MSC是否在rebooting，等到其正常工作后再检查MTL是否恢复了。⑺在BSC键入：disp_eledpc0disp_eleopc0此命令查看MTP的第三层的信令点码。比较此点码与MSC处设置的点码是否对应。⑻找到控制此MTL的GPROC。ins0gproc**如无效则键入：reset_de0gproc**⑼将BSC

reset。解决思路：首先确定是哪块GPROC出现239告警，根据这块GPROC的功能来确定存在问题的进程或硬件范围。如BTP239告警，出现问题的进程可能运行于MCU，也可能运行于TCU，还可能是BTP与TCU的通信进程。然后检查相应的硬件是否有问题，不能进一步判断原因所在时，应收集数据再作分析。参考操作步骤：⑴在出现告警的基站键入state以确定发生告警的GPROC、BSP、DHP、BTP的状态。⑵如果显示为B-U，则键入device_audit<location>all<device_name>

<device_id1><device_id2><device_id3>⑶如果device_audit成功则继续观察此设备。如果device_audit失败则键入ins<location><device_name><devid><dev_id><dev_id>如果ins失败，则进行如下操作，收集数据。Ⅰ如果出现问题的是BSP，则通过直连或远程登录进入GPROC，如果没有响应则可能为GPROC太忙，TTY进程来不及响应。键入disp_mms_ts_usage查看A接口上是否有TCH被分配，如果有则收集GPROC的SWFM和event。如果没有则将GPROCreset，当BSCreset后，收集GPROC的FatalandNonFatalSWFMs，以及在告警发生前和BSCreset后的event。Ⅱ如果出现问题的不是BSP，则通过直连或远程登录进入GPROC，收集GPROC的FatalandNonFatalSWFMs，以及在告警发生前后的event。5、IAS1号告警

IAS1号告警——SerialBusConnectionFailure，多出现在BSC或RXCDR基站内。背景原理：

在BSSC机柜中有一块的告警板，此板的作用为报告熔丝和风扇等设备的告警。此告警板的PL2和PL3连接到CAGE背板的左上角AI0/AI1口。如果BSS为两个CAGE，上面的CAGE一般是不连接告警线的。数据库定义CAGE时需要定义告警线是否接到这个CAGE中。disp_eq0cage00

IdentifierfortheCAGE:0

KSWpairthatmanagestheCAGE:0

KSWXconnectingcagetoKSWforTDM0:

KSWXconnectingcagetoKSWforTDM1:

Cabinettowhichthecagebelongs:0

IASConnected:YES

最后一项如果定义为YES，则软件尝试将告警信号送到此CAGE，但是如果物理上并没有将告警线连接到此CAGE，则会产生IAS1号告警。一般配置CAFE时都将下面的CAGE定义为连接告警线，上面的CAGE不连接。如果在equipcage时将上面的CAGE也定义了IASConnected:YES，则会产生大量的IAS1告警。6、BSS22号告警：TrunkCriticalThresholdExceeded

此告警表示被BLOCK的CIC数目超过了紧急告警门限值。背景原理：

CIC是MSC经由RXCDR到BSC的陆地电路。XCDR（GDP）板及内部的DSP处理器和MSI板的故障都会使得CIC的数目减少。另外由于传输等问题也会使得CIC被block，但传输恢复正常后，CIC不一定能自动起来，此时需要人工干预才能恢复。可能引起此类告警的原因：①由于MSI板和MMS口的硬件问题导致可用的CIC数目减少②由于E1链路的问题，包括传输问题，导致CIC数目减少③由于RXCDR中GDP、XCDR板的DSP处理器出现问题使得CIC数目减少④MSI、XCDR、GDP板可能被人为lock了⑤database中关于此告警的门限值设置得太低解决思路：首先查硬件问题，如E1连接是否正常，MSI、XCDR、GDP板是否有问题，有没有被LOCK，再检查是否因传输问题而使MMS口退服。同时应注意一下数据库中有关参数的定义是否合理，如果MSC端将CICblock，应手动将CIC复位。参考操作步骤：⑴键入state0msi**state0mms**

disp_act_a0disp_act_a0检查MSI，MMS状态是否正常，是否有相关的告警。⑵在BSC找到对应的连接到MSC的2M链路的MMS板键入disp_mms_ts_usage0mms**查看此MMS的各时隙是否有被block的。如发现大量的CIC被block，首先确定是否为MSC边将其block的。如果不是则使用以下命令将CIC释放。先进入BSC的emon提示符下，键入以下命令 msg_s64399990f0eh0eh01h00xx030h02h00h01h其中xx---CICnumber⑶使用以下命令检查关于告警的门限值。

disp_elementcic_error_gen_threshold0查看cic告警的门限值。如发现设置过低，使用

chg_elementcic_error_gen_threshold<value>0调整cic告警门限值。7、GPROC254号告警此告警表示一个GPROC或BTP退出服务。背景原