BSC告警分析ppt课件

1、BSC/RXCDR/PCU告警分析摩托罗拉昆明分公司宽带及挪动网络事业部, 2021-07内容简介告警格式与组成告警处置的优先级别常见的BSS告警告警的格式与组成告警的种类和格式告警可以分为硬件告警和软件告警两种：硬件告警是由于BSS内的硬件缺点所引起的告警。软件告警是由GPROC检测到软件进程运转出错所引起的告警。只需GPROC设备BSP，CSFP，DHP，BTP，pool GPROC才会产生软件告警息。软件告警Software Fault Management或SWFM分为两类。 告警举例：#0 NEW *NONE*.CommuncationFailureEvent - CAGE - BS

2、S01(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：告警IDNEW：告警形状NONE：正在处置此告警的人员 CommuncationFailureEvent：告警的类型CAGE：告警级BSS01(BSS01:SITE-0:): 0 CAGE 1：发生告警的位置30/03/1999 14:23:56：告警发生时间18：告警编号Ex

3、pansion KSWX Slot 22 Communication Failure：告警描画FMIC：告警的去除类型Major：告警严重等级(BSS01:SITE-0:): 0 SITE Impacted to Major:告警附加信息 告警的类型告警编号对于每种设备都有独一的一个十进制数表示。每种设备的告警编号从0到254。对于不同的设备告警编号能够反复，但与设备相关的编号是独一的。有些情况下同样的告警编号表示类似的告警。 例如254号告警表示设备fail。在OMC-R上将告警分成不同的六种类型，可以在OMCR的告警阐明中找到“FailureEvents 字段，其为不同类型告警的称号。 它

4、们分别是：告警的等级告警严重级别阐明此缺点发生对系统的影响程度，系统将告警的等级分为六级：告警处置的优先级我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进展相应的处置。在此我们提供普通原那么下的优先级别。对于基站来说从RXCDR到BSC，再到BTS；信令链路按照MTL、RSL、XBL的次序；告警严重级别由高到低分别是Critical、 Major、 Minor、 Warning、 Investigate、Clear。在一样的告警级别中，Critical告警按照以下顺序All RXCDR-All MTL -All BSC-All RSL-All BTS-All

5、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 Station Controller (BSC)Base Transceiver Station (BTS). The linksMessage Transfer part Link (MTL) Radio Sign

6、alling Link (RSL)X.25 link. Critical告警按照以下顺序：All RXCDR - Critical alarmsAll MTL - Critical alarmsAll BSC - Critical alarmsAll RSL - Critical alarmsAll BTS - Critical alarmsAll X.25 link - Critical alarmsAll other Critical alarms常见的BSS告警1、OML为E-U或D-U的问题 在BSC或RXCDR看到此景象时，还能够看到相关的一些告警，如OML 242号告警等。背景原理

7、： 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板上定

8、义了NE起来时用于从OMCR下载软件和数据库的OML链路。然后核对DTE地址及路由器的设置能否正确。假设OML链路以前是好的，那么首先要搞清能否有人对OML相关的参数改动过，如数据库中关于OML链路的定义、DTE地址、路由器设置等。在确认没有改动过后，应检查硬件问题，如MMS口能否退服、MSI板能否缺点等。 参考操作步骤： OML链路的问题涉及的设备比较多，例如：OMCR，路由器，RXCDR等，为了正确定位缺点应结合数据搜集来处置问题。进入BSC键入state 0 命令查看BSC的形状；进入RXCDR键入state 0 查看RXCDR的OML形状；在RXCDR键入disp_links 查看RX

9、CDR内的链路衔接，以确定与OML相关的MMS位置；在出现问题的BSC或RXCDR中键入disp_p 0查看哪个GPROC控制OML链路；键入disp_act_a 0 查看能否有相关的告警；键入disp_eq 0 oml * * 查看每条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形状，继续

10、以下步骤。键入命令以停顿和激活AGENT进程，然后lock/unlock此OML链路；键入命令以停顿和激活AGENT进程、X.25 PLP进程然后 unlock/lock 此 OML；(10)排除硬件缺点，思索是软件进程问题呵斥OML缺点，可以思索激活挂OML的GPROC，假设还是不能处理可以思索reset BSC。2、GCLK无法锁相的问题 GCLK无法锁相时会产生GCLK Failed Phase Lock的提示，并能够伴随出现4、14、13号等告警。背景原理： GLCK 的功能是使得系统与更准确的时钟同步，对于BSS来说，GCLK要与MSC的时钟同步。时钟同步的目的是在射频部分提供0.0

11、5ppmppm为百万分之一。即如时钟为16.384M，那么频率误差为16.3840.05 = 0.8192Hz 的高精度的时间同步。因此要提供参考时钟的E1/T1链路要尽量减少滑帧和失同步。 GCLK要与上一级时钟同步必需求有上一级时钟的参考信号，时钟参考信号是根据数据库的定义从指定的MMS口上提取的。在database中需求定义不同MMS口的时钟提取优先等级。 GCLK在任务时有四种不同的形状：自在振荡形状：此形状是当GCLK刚上电时，其内部的晶体振荡器OCXO需求有预热的过程，以坚持其正常的任务环境。此时间是固定不变的30分钟，无法更改。在自在振荡形状下，GCLK内的DAC输入为80H，时

12、钟输出坚持在0.05ppm的精度内。Hold Frequency：此形状是GLCK与2M失锁时的形状。此时GCLK运用前一次ADC输出的值输入DAC以控制时钟，此形状是一个过渡形状，普通继续10秒。Set Frequency：此形状普通在Hold Frequency之后。运用LTALong Term Average值输入DAC以控制时钟。 正常锁相任务时GCLK每30分钟采样一个ADC输出值2位16进制数，存入内部存储器，存储器最大可以存放48个值，采用先入先出原那么更新。这48个值也可以被GPROC经过MCAP总线读取或设置。所谓LTA就是指将这48个值取平均输入到DAC。Set Frequ

13、ency形状下，GCLK不再往存储器中存放新值，只是运用以前的旧值，存储器停顿更新，这是与锁相形状的不同之处。锁相形状：此形状分为两个子形状，Acquiring Frequency Lock State，此形状是一个过渡形状，由硬件决议。Frequency Lock State，此形状内GCLK已与E1/T1锁相，但需等待一段时间，以确定锁相稳定之后就进入锁相形状。能够引起此类告警的缘由：因传输问题引起MMS退服MSI板或MMS口硬件缺点数据库定义不合理GCLK本身的问题，需求校正或改换 处理思绪： 当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。检查一下数据库中有关GCLK的

14、参数设置能否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS只需菊花链的情况锁，向下一端的MSI口的时钟提取优先级应设为0，另外也不能只允许一个MMS口可以提取时钟。假设数据库设置没有明显不合理之处，应留意一下与时钟提取有关的MMS口和MSI板的形状，MMS口退服能够是传输问题引起的，也能够是MSI板或MMS口硬件缺点引起的，假设MSI板任务正常那么应着重检查传输质量。在排除了数据库、MSI硬件和传输缘由之后，应校正或改换GCLK板。参考操作步骤：为了利于问题的分析应搜集以下数据：state gclk * * 查看GCLK的形状disp_el

15、phase_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作为时钟源。查看提供时钟的MMS

16、能否与上一级的链路衔接，上一级的时钟能否正常任务。查看提供时钟的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链路退出效力时，其负荷会分配到其它MTL上，加重其它MTL的负担，而由于GPROC的处

17、置才干的缘由，MTL链路的平均利用率不能超越30。因此MTL链路负担过重，会使得GPROC退出效力，从而导致更多的链路退出效力。 此告警与BSS 0号告警的区别为：MTL 0号告警表示一条MTL退出效力，而一个BSS能够有多条MTL链路，BSS 0号告警表示此BSS系统的最后一条MTL链路也退出效力，此时BSS完全瘫痪了。能够引起此类告警的缘由：MSC传来的MTP第二层LSSU信息出现错误。MSC端拥塞超时MSU确认音讯超时序列号出现错误SUERM的错误门限值超出收到不正常的FIB处理思绪： 先检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板能否退出效力，再查与MSC的

18、信令点码能否正确，在确认上述方面无问题后检查GPROC能否有硬件问题，必要时复位该GPROC。参考操作步骤： 根据告警音讯找到出现问题的站号，MTL的设备编号。在RXCDR键入：disp_links disp_bss_conn 以确定MTL链路的衔接情况。键入disp_equip 0 MTL * * 得到MTL的配置情况。 查看与MTL相关的设备能否正常任务state 0 mms * * 查看MMS的形状state 0 msi * * 查看MSI的形状disp_p 0 查看MTL由那个GPROC控制disp_act_a 0 查看能否有相关的告警出现了相关的设备告警时应先处置这些相关问题。运用l

19、ockunlock、ins命令试着恢复链路。检查RXCDR或MSC能否在rebooting，等到其正常任务后再检查MTL能否恢复了。在BSC键入：disp_ele dpc 0disp_ele opc 0此命令查看MTP的第三层的信令点码。比较此点码与MSC处设置的点码能否对应。找到控制此MTL的GPROC。ins 0 gproc * *如无效那么键入：reset_de 0 gproc * * 将BSCreset。4、BSP 239号告警 此告警表示GPROC的平安检测进程检测到进程错误。背景原理： 平安检测进程是担任对GPROC内运转的进程检查以确定能否运转正常。当被检测的进程没有呼应时就产生

20、此告警。不同功能的GPROC所产生的239号告警表现为：239 BSP 239 BTP 239 DHP 239 BTP (MCU) 平安检测进程对系统进展周期性的检测，可以经过参数来调整检测的时间间隔。缺省的时间间隔为10分钟。能够引起此类告警的缘由：GPROC、BSP、BTP板子损坏被检测的GPROC、BSP、BTP软件进程出现错误被检测的硬件出错GPROC没插但数据库中作了定义从TCU到BTP的HDLC链路能够出错BTP的输入输出链路出错TCU的运转软件出错处理思绪： 首先确定是哪块GPROC出现239告警，根据这块GPROC的功能来确定存在问题的进程或硬件范围。如BTP 239告警，出现

21、问题的进程能够运转于MCU，也能够运转于TCU，还能够是BTP与TCU的通讯进程。然后检查相应的硬件能否有问题，不能进一步判别缘由所在时，应搜集数据再作分析。 参考操作步骤：在出现告警的基站键入state以确定发生告警的GPROC、BSP、DHP、BTP的形状。假设显示为B-U，那么键入device_audit all 假设device_audit胜利那么继续察看此设备。假设device_audit失败那么键入ins 假设ins失败，那么进展如下操作，搜集数据。假设出现问题的是BSP，那么经过直连或远程登录进入GPROC，假设没有呼应那么能够为GPROC太忙，TTY进程来不及呼应。键入disp

22、_mms_ts_usage查看A接口上能否有TCH被分配，假设有那么搜集GPROC的SWFM和event。假设没有那么将GPROC reset，当BSC reset后，搜集GPROC的Fatal and Non Fatal SWFMs，以及在告警发生前和BSC reset后的event。假设出现问题的不是BSP，那么经过直连或远程登录进入GPROC，搜集GPROC的Fatal and Non Fatal SWFMs，以及在告警发生前后的event。 5、IAS 1号告警 IAS 1号告警Serial Bus Connection Failure，多出如今BSC 或RXCDR基站内。背景原理：

23、在BSSC机柜中有一块的告警板，此板的作用为报告熔丝和风扇等设备的告警。此告警板的PL2和PL3衔接到CAGE背板的左上角AI0/AI1口。假设BSS为两个CAGE，上面的CAGE普通是不衔接告警线的。数据库定义CAGE 时需求定义告警线能否接到这个CAGE中。disp_eq 0 cage 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

24、which the cage belongs: 0 IAS Connected: YES 最后一项假设定义为YES，那么软件尝试将告警信号送到此CAGE，但是假设物理上并没有将告警线衔接到此CAGE，那么会产生IAS 1号告警。普通配置CAFE时都将下面的CAGE定义为衔接告警线，上面的CAGE不衔接。假设在equip cage时将上面的CAGE也定义了IAS Connected: YES，那么会产生大量的IAS 1告警。能够引起此类告警的缘由：告警板缺点告警线衔接错误数据库定义错误告警线损坏处理思绪：先确定告警线衔接在哪个CAGE中，查看数据库中定义的能否与物理衔接相一致。不一致时修正数据库

25、。假设数据库定义没有问题，检查告警板和告警线能否损坏。 参考操作步骤：检查告警线衔接与数据库中的定义能否相符 假设不符，运用命令： modify_value 0 ias_connected cage ( # ) yes/no ( # ) cage号检查告警板能否完好，告警线能否损坏。必要时改换有关硬件。 6、BSS 22号告警：Trunk Critical Threshold Exceeded 此告警表示被BLOCK的CIC数目超越了紧急告警门限值。背景原理： CIC是MSC经由RXCDR到BSC的陆地电路。XCDRGDP板及内部的DSP处置器和MSI板的缺点都会使得CIC的数目减少。另外由于

26、传输等问题也会使得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端将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释放。 先进入BSC 的emon