BSC告警分析PPT课件

1、APAC China Customer Network Resolution Center BSC/RXCDR/PCUBSC/RXCDR/PCU告警分析告警分析 内容简介内容简介 告警格式与组成 告警处理的优先级别 常见的BSS告警 告警的格式与组成告警的格式与组成 u 告警的种类和格式 告警可以分为硬件告警和软件告警两种： 硬件告警是由于BSS内的硬件故障所引起的告警。 软件告警是由GPROC检测到软件进程运行出错所引起的告警。 只有GPROC设备（BSP，CSFP，DHP，BTP，pool GPROC）才会产生软件告警 息。软件告警（Software Fault Management或SW

2、FM）分为两类。 告警举例：告警举例： #0 NEW *NONE*. CommuncationFailureEvent - CAGE - BSS01(BSS01:SITE-0:): 0 CAGE 1 - 30/03/1999 14:23:56. Expansion KSWX Slot 22 Communication Failure - FMIC - Major - -/-. (BSS01:SITE-0:):0 SITE Impacted to Major. #0：告警ID NEW：告警状态 NONE：正在处理此告警的人员 CommuncationFailureEvent：告警的类型 CAGE

3、：告警级 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:告警附加信息 u 告警的类型 告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从0到254。 对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的 告警编号表示类似

4、的告警。 例如254号告警表示设备fail。 在OMC-R上将告警分成不同的六种类型，可以在OMCR的告警说明中找到 “FailureEvents” 字段，其为不同类型告警的名称。 它们分别是： u 告警的等级 告警严重级别表明此故障发生对系统的影响程度，系统将告警的等级分为六级： u 告警处理的优先级 我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警 情况进行相应的处理。在此我们提供一般原则下的优先级别。对于基站来说从RXCDR 到BSC，再到BTS；信令链路按照MTL、RSL、XBL的次序；告警严重级别由高到低分 别是Critical、 Major、 Minor

5、、 Warning、 Investigate、Clear。在相同的告警级别 中，Critical告警按照以下顺序All RXCDR-All MTL -All BSC-All RSL-All BTS-All X.25 link-All other Critical alarms。Major 告警按照以下顺序All RXCDR-All BSC-All BTS-All other Major alarms。其它告警按照Minor、Warning 、Investigate、Clear alarms的顺 序进行处理。 The sites Remote Transcoder (RXCDR) Base St

6、ation Controller (BSC) Base Transceiver Station (BTS). The links Message Transfer part Link (MTL) Radio Signalling Link (RSL) X.25 link. Critical告警按照以下顺序：告警按照以下顺序： All RXCDR - Critical alarms All MTL - Critical alarms All BSC - Critical alarms All RSL - Critical alarms All BTS - Critical alarms All

7、X.25 link - Critical alarms All other Critical alarms 常见的常见的BSSBSS告警告警 1、OML为为E-U或或D-U的问题的问题 在BSC或RXCDR看到此现象时，还可能看到相关的一 些告警，如OML 242号告警等。 背景原理： OML链路是OMCR到RXCDR或BSC的信令链路，主要 用于BSS的操作维护。OML使用X.25协议。OMCR通 过Router与BSS相连，在BSS端，操作数据在2M线的 某些时隙中传输，到达Router后，Router中的虚拟交换 电路把它们分门别类送往OMCR进行处理。同时OMCR 的数据也通过Rout

8、er交换后发往相应的NE。 可能引起此类告警的原因：可能引起此类告警的原因： 相关的MMS口退出服务 主用MSI板没有插 数据库中关于OML链路的定义不对 DTE地址定义不对 路由器定义不对 软件进程问题 解决思路解决思路： 如果OML链路从来没有起来过，那么首先应该检查硬件 连接是否正确，特别是主用的MSI板是否插上了，因为 主用MSI板上定义了NE起来时用于从OMCR下载软件和 数据库的OML链路。然后核对DTE地址及路由器的设置 是否正确。如果OML链路以前是好的，那么首先要搞清 是否有人对OML相关的参数改动过，如数据库中关于 OML链路的定义、DTE地址、路由器设置等。在确认没 有改

9、动过后，应检查硬件问题，如MMS口是否退服、 MSI板是否故障等。 参考操作步骤参考操作步骤： OML链路的问题涉及的设备比较多，例如：OMCR，路由器， RXCDR等，为了正确定位故障应结合数据收集来处理问题。 进入BSC键入state 0 命令查看BSC的状态；进入RXCDR 键入state 0 查看RXCDR的OML状态；在RXCDR键入 disp_links 查看RXCDR内的链路连接，以确定与OML相 关的MMS位置；在出现问题的BSC或RXCDR中键入 disp_p 0查看哪个GPROC控制OML链路；键入 disp_act_a 0 查看是否有相关的告警；键入disp_eq 0 o

10、ml * * 查看每条OML的配置情况。 处理步骤处理步骤 进入BSC键入state 0 命令查看BSC的状态； 进入控制OML的GPROC； 运用msg_send命令； lock/unlock OML，看OML的状态； 再运用msg_send命令； lock/unlock OML所属的MMS，查看OML的状态； lock/unlock OML所属的MSI，查看OML的状态；如果OML仍为E-U状态， 继续以下步骤。 键入命令以停止和激活AGENT进程，然后lock/unlock此OML链路； 键入命令以停止和激活AGENT进程、X.25 PLP进程然后 unlock/lock 此 OML；

11、(10)排除硬件故障，考虑是软件进程问题造成OML故障，可以考虑激活挂 OML的GPROC，如果还是不能解决可以考虑reset BSC。 2、GCLK无法锁相的问题无法锁相的问题 GCLK无法锁相时会产生GCLK Failed Phase Lock的提 示，并可能伴随出现4、14、13号等告警。 背景原理：背景原理： GLCK 的功能是使得系统与更准确的时钟同步，对于 BSS来说，GCLK要与MSC的时钟同步。时钟同步的目 的是在射频部分提供0.05ppm（ppm为百万分之一。 即如时钟为16.384M，则频率误差为16.3840.05 = 0.8192Hz ）的高精度的时间同步。因此要提供参

12、考时 钟的E1/T1链路要尽量减少滑帧和失同步。 GCLK要与上一级时钟同步必须要有上一级时钟的参考信号，时钟参 考信号是根据数据库的定义从指定的MMS口上提取的。在 database中需要定义不同MMS口的时钟提取优先等级。 GCLK在工作时有四种不同的状态： 自由振荡状态：此状态是当GCLK刚上电时，其内部的晶体振荡器 （OCXO）需要有预热的过程，以保持其正常的工作环境。此时间 是固定不变的（30分钟），无法更改。在自由振荡状态下，GCLK 内的DAC输入为80H，时钟输出保持在0.05ppm的精度内。 Hold Frequency：此状态是GLCK与2M失锁时的状态。此时GCLK 使用

13、前一次ADC输出的值输入DAC以控制时钟，此状态是一个过 渡状态，一般持续10秒。 Set Frequency：此状态一般在Hold Frequency之后。使用LTA （Long Term Average）值输入DAC以控制时钟。 正常锁相工作时GCLK每30分钟采样一个ADC输出值2位16进 制数，存入内部存储器，存储器最大可以存放48个值，采用先入先 出原则更新。这48个值也可以被GPROC通过MCAP总线读取或设 置。所谓LTA就是指将这48个值取平均输入到DAC。Set Frequency状态下，GCLK不再往存储器中存放新值，只是使用以 前的旧值，存储器停止更新，这是与锁相状态的不

14、同之处。 锁相状态：此状态分为两个子状态， Acquiring Frequency Lock State，此状态是一个过渡状态，由硬件决 定。 Frequency Lock State，此状态内GCLK已与E1/T1锁相，但需等待一 段时间，以确定锁相稳定之后就进入锁相状态。 可能引起此类告警的原因可能引起此类告警的原因： 因传输问题引起MMS退服 MSI板或MMS口硬件故障 数据库定义不合理 GCLK本身的问题，需要校正或更换 解决思路解决思路： 当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来 的。检查一下数据库中有关GCLK的参数设置是否合理，如锁相应 向上锁，即RXCDR向

15、MSC锁、BSC向RXCDR锁、BTS向BSC或 上一级的BTS（只有菊花链的情况）锁，向下一端的MSI口的时钟 提取优先级应设为0，另外也不能只允许一个MMS口可以提取时钟。 如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关 的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的， 也可能是MSI板或MMS口硬件故障引起的，如果MSI板工作正常则 应着重检查传输质量。在排除了数据库、MSI硬件和传输原因之后， 应校正或更换GCLK板。 参考操作步骤参考操作步骤： 为了利于问题的分析应收集以下数据： state gclk * * （查看GCLK的状态） disp_el phas

16、e_lock_gclk （查看是否允许锁相） disp_eq 0 mms （查看MMS的参数，主要是时钟提取优先级） disp_el wait_for_reselection （查看时钟提取切换时间） disp_el lta_alarm_range （查看LTA告警范围） disp_gclk_avgs （查看GCLK的长期平均值） disp_eq gclk full（查看GCLK硬件版本信息） 当GCLK无法锁相时可采用以下的方法： reattempt_pl 使用lock/unlock命令看是否能使得GCLK锁相恢复。 查看MSI，MMS是否处于正常状态，是否有E1的相关告警产生，是否有MMS

17、作为时 钟源。 查看提供时钟的MMS是否与上一级的链路连接，上一级的时钟是否正常工作。 查看提供时钟的MMS的等级是否设置正确（一般为255）。 试着使用其它的MMS作为时钟源。（对于M-CELL可更换NIU）。 3、MTL告警告警 背景原理背景原理： MTL链路是MSC与BSC的信令链路，其在整个系统中起着MSC与MS、 BSS连接的作用。MTL出现问题会导致其下属所有的BSS瘫痪。 MTL最多的告警一般为0号告警，出现此告警时MTL为D-U。此告警表示 MTL链路与MSC已经失去联系。这是由于MTP第二层出现问题，而退出服 务。但系统会不断尝试恢复此链路。另外当一条MTL链路退出服务时，其

18、 负荷会分配到其它MTL上，加重其它MTL的负担，而由于GPROC的处理 能力的原因，MTL链路的平均利用率不能超过30。因此MTL链路负担过 重，会使得GPROC退出服务，从而导致更多的链路退出服务。 此告警与BSS 0号告警的区别为：MTL 0号告警表示一条MTL退出服务，而 一个BSS可能有多条MTL链路，BSS 0号告警表示此BSS系统的最后一条 MTL链路也退出服务，此时BSS完全瘫痪了。 可能引起此类告警的原因：可能引起此类告警的原因： MSC传来的MTP第二层LSSU信息出现错误。 MSC端拥塞超时 MSU确认消息超时 序列号出现错误 SUERM的错误门限值超出 收到不正常的FI

19、B 解决思路：解决思路： 先检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS 口、MSI板是否退出服务，再查与MSC的信令点码是否正确，在确 认上述方面无问题后检查GPROC是否有硬件问题，必要时复位该 GPROC。 参考操作步骤参考操作步骤： 根据告警消息找到出现问题的站号，MTL的设备编号。 在RXCDR键入： disp_links disp_bss_conn 以确定MTL链路的连接情况。 键入disp_equip 0 MTL * * 得到MTL的配置情况。 查看与MTL相关的设备是否正常工作 state 0 mms * * 查看MMS的状态 state 0 msi * * 查

20、看MSI的状态 disp_p 0 查看MTL由那个GPROC控制 disp_act_a 0 查看是否有相关的告警 出现了相关的设备告警时应先处理这些相关问题。 使用lockunlock、ins命令试着恢复链路。 检查RXCDR或MSC是否在rebooting，等到其正常工作后再检查 MTL是否恢复了。 在BSC键入： disp_ele dpc 0 disp_ele opc 0 此命令查看MTP的第三层的信令点码。比较此点码与MSC处设置的点 码是否对应。 找到控制此MTL的GPROC。 ins 0 gproc * * 如无效则键入： reset_de 0 gproc * * 将BSCreset

21、。 4、BSP 239号告警号告警 此告警表示GPROC的安全检测进程检测到进程错误。 背景原理背景原理： 安全检测进程是负责对GPROC内运行的进程检查以确定是否运行正常。当被检测的 进程没有响应时就产生此告警。不同功能的GPROC所产生的239号告警表现为： 239 BSP 239 BTP 239 DHP 239 BTP (MCU) 安全检测进程对系统进行周期性的检测，可以通过参数来调整检测的时间间隔。缺 省的时间间隔为10分钟。 可能引起此类告警的原因：可能引起此类告警的原因： GPROC、BSP、BTP板子损坏 被检测的GPROC、BSP、BTP软件进程出现错误 被检测的硬件出错 GP

22、ROC没插（但数据库中作了定义） 从TCU到BTP的HDLC链路可能出错 BTP的输入输出链路出错 TCU的运行软件出错 解决思路解决思路： 首先确定是哪块GPROC出现239告警，根据这块GPROC的功能来确定存在问题的进程或硬件范 围。如BTP 239告警，出现问题的进程可能运行于MCU，也可能运行于TCU，还可能是BTP与 TCU的通信进程。然后检查相应的硬件是否有问题，不能进一步判断原因所在时，应收集数据 再作分析。 参考操作步骤参考操作步骤： 在出现告警的基站键入state以确定发生告警的GPROC、BSP、DHP、BTP的状态。 如果显示为B-U，则键入 device_audit

23、all 如果device_audit成功则继续观察此设备。如果device_audit失败则键入 ins 如果ins失败，则进行如下操作，收集数据。 如果出现问题的是BSP，则通过直连或远程登录进入GPROC，如果没有响应则可能为GPROC太 忙，TTY进程来不及响应。键入 disp_mms_ts_usage 查看A接口上是否有TCH被分配，如果有则收集GPROC的SWFM和event。 如果没有则将GPROC reset，当BSC reset后，收集GPROC的Fatal and Non Fatal SWFMs，以及 在告警发生前和BSC reset后的event。 如果出现问题的不是BSP

24、，则通过直连或远程登录进入GPROC，收集GPROC的Fatal and Non Fatal SWFMs，以及在告警发生前后的event。 5、IAS 1号告警号告警 IAS 1号告警Serial Bus Connection Failure，多出现在BSC 或RXCDR基站内。 背景原理背景原理： 在BSSC机柜中有一块的告警板，此板的作用为报告熔丝和风扇等设备的告警。此告 警板的PL2和PL3连接到CAGE背板的左上角AI0/AI1口。如果BSS为两个CAGE， 上面的CAGE一般是不连接告警线的。数据库定义CAGE 时需要定义告警线是否接 到这个CAGE中。 disp_eq 0 cage

25、 0 0 Identifier for the CAGE: 0 KSW pair that manages the CAGE: 0 KSWX connecting cage to KSW for TDM 0: KSWX connecting cage to KSW for TDM 1: Cabinet to which the cage belongs: 0 IAS Connected: YES 最后一项如果定义为YES，则软件尝试将告警信号送到此CAGE，但是如果物理上并 没有将告警线连接到此CAGE，则会产生IAS 1号告警。一般配置CAFE时都将下面 的CAGE定义为连接告警线，上面的C

26、AGE不连接。如果在equip cage时将上面的 CAGE也定义了IAS Connected: YES，则会产生大量的IAS 1告警。 可能引起此类告警的原因：可能引起此类告警的原因： 告警板故障 告警线连接错误 数据库定义错误 告警线损坏 解决思路：解决思路： 先确定告警线连接在哪个CAGE中，查看数据库中定义的 是否与物理连接相一致。不一致时修改数据库。如果数 据库定义没有问题，检查告警板和告警线是否损坏。 参考操作步骤参考操作步骤： 检查告警线连接与数据库中的定义是否相符 如果不符，使用命令： modify_value 0 ias_connected cage ( # ) yes/no

27、 ( # ) cage号 检查告警板是否完好，告警线是否损坏。必要 时更换有关硬件。 6、BSS 22号告警：号告警：Trunk Critical Threshold Exceeded 此告警表示被BLOCK的CIC数目超过了紧急告警门限值。 背景原理背景原理： CIC是MSC经由RXCDR到BSC的陆地电路。XCDR（GDP）板及内部的 DSP处理器和MSI板的故障都会使得CIC的数目减少。另外由于传输等问 题也会使得CIC被block，但传输恢复正常后，CIC不一定能自动起来，此 时需要人工干预才能恢复。 可能引起此类告警的原因：可能引起此类告警的原因： 由于MSI板和MMS口的硬件问题导

28、致可用的CIC数目减少 由于E1链路的问题，包括传输问题，导致CIC数目减少 由于RXCDR中GDP、XCDR板的DSP处理器出现问题使得CIC数目减少 MSI、XCDR、GDP板可能被人为lock了 database中关于此告警的门限值设置得太低 解决思路：解决思路： 首先查硬件问题，如E1连接是否正常，MSI、XCDR、GDP板是否 有问题，有没有被LOCK，再检查是否因传输问题而使MMS口退服。 同时应注意一下数据库中有关参数的定义是否合理，如果MSC端 将CIC block，应手动将CIC复位。 参考操作步骤参考操作步骤： 键入 state 0 msi * * state 0 mms * * disp_act_a 0 disp_act_a 0 检查MSI，MMS状态是否正常，是否有相关的告警。 在BSC找到对应的连接到MSC的2M链路的MMS板键入 disp_mms_ts_usage 0 mms * * 查看此MMS的各时隙是否有被block的。如发现大量的CIC被block， 首先确定是否为MSC边将其block的。如果不是则使用以下命令将 CIC释放。 先进