BSS

nullBSS高级维护 BSS高级维护 目 录目 录序论 第一章 告警处理 一、告警格式与组成 二、告警处理流程 三、常见的十类BSS告警 四、注意要点 第二章 实际故障处理解析 一、TCU故障处理 二、BTS启动分析 三、BSC reset分析 四、快速故障定位、故障处理小窍门 第三章 典型操作精解 一、时钟校准 1、          BSC&RXCDR时钟校准 2、          MCU时钟校准 附录：常见告警的分类 附录 内容提要 内容提要 本部分内容综述GSM BSS子系统网络的维护技术，主要介绍网络维护应当具有的理念，提供维护过程中分析问题的一般思路，对常见告警的处理，实际故障解析等。还有常见操作精解和维护工作的建议等内容。通过本部分的学习读者将具有GSM BSS网络维护的一般知识，掌握BSS基站子系统基本维护技能，能够承担日常的网络维护工作。 序 论序 论维护工作的要旨——防患于未然维护工作的要旨——防患于未然系统建设完成后，就转入系统维护工作。由于此时系统已经给终端用户提供服务，网络的任何故障均可能对终端用户产生影响，从而对运营商的形象产生影响。所以维护工作的要旨是防患于未然，将系统隐患尽早排除，不要使其成为系统故障而影响系统的性能。 预防性维护是我们的最佳选择，定期对任何一个基站进行严格的检测调整，保证系统及其附属外围设备正常工作，并将正常运行时的所有系统数据整理归档，以供日常维护参考。通过集中性预防维护，可以及时发现系统隐患并加以排除，最大限度地提高现行系统设备的利用率，增强系统设备的可靠性，从而减轻平时日常维护的压力。 由于各个方面的原因，诸如传输、不同厂家设备配合、各个厂家硬件的稳定性、软件、气候、环境等，使得系统会出现一些不可预知的问题。如何解决此类问题，尽快恢复系统工作，是我们需要学习的技术。这也是本资料所要讲述的内容。null维护工作的最高境界：防患于未然 不断学习系统知识 掌握必要的维护技术 日常巡检 集中性预防维护 系统会出现不可预知问题的原因 传输 不同厂家设备配合 各个厂家硬件的稳定性 软件 气候 环境 分析问题的一般思路 分析问题的一般思路 遇到问题时，保持清醒的头脑，认真仔细地分析问题，作好必要的检查，收集相关数据。最大限度地掌握材料对于我们迅速准确地判断问题是很有帮助的。 首先我们要分清问题是局部问题,还是系统问题。是单个载频的问题还是整个CELL下所有载频的问题；是一个CELL的问题还是整个BTS基站的问题；是一个基站的问题还是整个BSC的问题；是一个BSC的问题还是MSC下所有BSC的问题。通过初步的故障定位，进行初步的处理与测试，缩小故障范围，如此循环，直到找到最终的故障原因。 其次我们要通过各种方法，寻找问题可能具有的规律。比如是否发生在特定的地点，特定的时间，具有周期性等等。这样就会迅速定位故障。 通过检查系统状态，进行路测，客户访问，故障反馈登记，问题分类等等。及时、准确地记录发生的事件，使得后续的工程师能够尽快地进入工作。 在检查系统状态时，应当作好LOG文件，即利用所使用的终端通讯软件，将数据记录成文件保存，以便上级技术支持工程师能够根据这些数据来分析问题。 总 则总 则保持冷静，迅速作出反应 组织人力进行必要的检查、测试 分清是系统问题还是局部问题 逐步缩小故障范围 作好LOG，注意保存数据 第一章 告警处理 第一章 告警处理 null 机房运行维护人员经常会碰到告警，有些告警是操作维护过程中自然产生的，有些告警是瞬时性的，不会影响系统正常运行，但大多数告警是会影响系统性能的，有的甚至会导致BSS复位，对移动通信系统造成严重影响。因此对于运维人员来说，了解告警系统，掌握一定的告警分析和处理技能，显得非常重要。本章正是从这个角度出发，介绍移动系统产品的告警系统和告警格式，并详细分析了常见的十类BSS告警。我们希望通过告警分析，能够帮助运维人员提高分析处理告警的能力。 null 本章包括两部分主要内容，前一部分介绍了产品的告警系统和告警格式，后一部分深入分析了常见的十类BSS告警。本章还给出了在处理告警时一些需要注意的东西。 告警可以使我们监控系统的运行状况 分析告警的不同级别 重视严重的告警 学习告警处理方法 告警的格式 一、 告警格式与组成 一、 告警格式与组成 告警系统是为了故障定位，系统性能分析及方便维护而设置的。 告警信息可以在OMCR的告警窗口上显示，也可以在本地维护终端（LMT）上显示。BSS产生的告警信息，以字符的形式发往OMCR。也可以通过命令设置使告警显示在LMT上(各县所用软件为cindy)。 1、告警的种类和格式 1、告警的种类和格式 告警可以分为硬件告警和软件告警两种： 硬件告警是由于BSS内的硬件故障所引起的告警。 软件告警是由GPROC检测到软件进程运行出错所引起的告警。 只有GPROC设备（BSP，CSFP，DHP，BTP，pool GPROC）才会产生软件告警信息。软件告警（Software Fault Management或SWFM）分为两类。 告警举例告警举例 #0 – NEW – *NONE*. CommuncationFailureEvent- CAGE - 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. null#0：告警ID NEW：告警状态 NONE：正在处理此告警的人员 CommuncationFailureEvent：告警的类型 CAGE：告警级 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:告警附加信息 null2、告警编号和消除类型 2、告警编号和消除类型 告警编号对于每种设备都有唯一的一个十进制数表示。每种设备的告警编号从0到254。(见附录)对于不同的设备告警编号可能重复，但与设备相关的编号是唯一的。有些情况下同样的告警编号表示类似的告警。 例如242号告警表示设备退出服务(MMS\MTL\RSL)。 null告警的清除类型可分为三类： Intermittent Fault Management Initiated Clear（FMIC） Operator Initiated Clear（OIC） Intermittent表示告警是偶发性的，对系统没有危害。此告警发生后在OMCR会自动消除。当此类告警频繁产生时，会增加OML链路的负荷。我们可以使用disp_throttle命令来查看告警门限设置，还可用chg_throttle命令调节其门限值。 FMIC告警的清除由系统的错误管理进程（Fault Managerment Process）自动进行。FM进程管理一张现有告警的列表，只有当告警产生的原因消失后FM才会产生‘clear’ 消息将此告警从告警列表中删除。 OIC需要由操作人员手动将告警清除。FM进程检测到告警产生并判断为OIC类型时，将此告警加入现有告警列表中。此后FM不再进行任何处理。当操作人员将告警产生的原因解决后，必须将此告警清除。清除告警步骤 清除告警步骤 在OMCR和BSC上均能够清除告警。OMCR上清除告警按以下步骤进行： 打开告警窗口，单击鼠标左键选中要清除的告警项 单击鼠标右键弹出快捷菜单 选择快捷菜单的“Handle” 选择快捷菜单的“Clear” 确认告警已被清除 在BSS上清除告警，先使用disp_act_alarm命令查看有哪些OIC告警。然后使用del_act_alarm命令将告警清除。清除命令如下: del_act_alarm (只对OIC告警)3、告警的类型 3、告警的类型 OMCR将告警分成六种不同的类型，可以在OMCR的告警说明中找到"FailureEvents" 字段，其为不同类型告警的名称。 null4、告警的等级 4、告警的等级 告警严重级别表明此故障发生对系统的影响程度。系统将告警的等级分为6级。 null 告警的等级可以查看也可以根据要求改变。使用以下两条命令可以查看和改变告警的等级，命令如下： 查看等级disp_severity 改变等级chg_severity 例如： MMI-RAM0115> disp_severity DRI 12 系统显示：DRI Alarm Code 12 severity: WARNING MMI-RAM0115>chg_severity DRI 12 major 系统显示：COMMAND ACCEPTED 二、告警处理流程 二、告警处理流程 有关告警的窗口不论是打开还是处于最小化，当有新的告警产生时，都会自动添加在告警的窗口中。在OMCR上可以用多种方法查看告警。 第一种方法：OMCR桌面图形界面GUI上的ALARM按钮 在OMCR桌面图形界面GUI上双击告警按钮，打开告警窗口，可以看到所有网元（NE）的告警信息； 第二种方法：通过GUI上的EVENT MANEGMENT 点击GUI上的EVENT MAMT按钮，打开Display Subscription List窗口，选择窗口中告警中的一项，选择open按钮就打开告警窗口； 第三种方法：打开MAP图，然后选中对应的单元节点 从NETWORK MAP上查看告警，单击GUI上的NETWORK MAP按钮，打开MAP LIST窗口，选定其中的一个网元，双击鼠标左键打开MAP窗口，在MAP图上用鼠标左键点击要查看的网络单元节点，选中后接点会变为紫色，单击鼠标右键在快捷菜单内选择ALARM项，此时会出现告警窗口显示此节点单元的所有告警。 用disp_act_alarm 命令行查看告警（县cindy软件）。 null 打开告警窗口之后，查看告警的状态项，新产生的告警状态项为NEW，操作者为NONE。新告警被选中后会改变颜色，比如：Critical告警的告警字为红色，背景为白色，对于其它种类告警的告警字为黑色，背景为白色，并且告警的状态项变为SEEN，表明有工程师已经阅读了该项告警。如果人工clear后,告警字变绿,背景为白色. 告警窗口中状态项为“NEW”的告警是新产生需要处理的告警。 2、告警处理优先级别 2、告警处理优先级别 我们可以根据告警的严重级别，以及出现告警的网元在系统中的重要性，对不同的告警情况进行相应的处理。在此我们提供一般原则下的优先级别。对于基站来说从RXCDR到BSC，再到BTS；信令链路按照MTL、RSL、XBL的次序；告警严重级别由高到低分别是Critical、 Major、 Minor、 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 Station 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 X.25 link - Critical alarms All other Critical alarms null 当某个设备或链路处于OOS等非正常状态时，不仅与起本身相关，而且与其上一级（parent）设备有关，对parent设备进行进行必要的处理是解决问题的重要手段。如果某个设备处于OOS等状态下，此设备下一级（child）设备不能正常工作。在此我们给出常见的设备之间的从属关系（parent-child）： 总 则总 则查看告警 分清告警的级别 明确与告警有关的设备 根据告警手册或经验对告警进行处理 解决问题，消除告警 三、常见的十类BSS告警 三、常见的十类BSS告警 某些的告警只在特定的告警条件下才会发生，有些告警发生得多一些，比较普遍。我们无法把所有的告警都进行详细的分析，并且这也没有必要。这里我们根据掌握的资料和经验，列举了经常碰到并具普遍意义的十类BSS告警，通过这些告警的分析，希望能够拓宽工程师的思路，帮助帮助提高处理告警、排除故障的能力。我们在本文的附录中列举了其它告警的扼要信息，供工程师查考。 1、OML为E-U或D-U的问题 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的数据也通过Router交换后发往相应的NE。 null可能引起此类告警的原因： ①相关的MMS口退出服务 ②主用MSI板没有插 ③数据库中关于OML链路的定义不对 ④DTE地址定义不对 ⑤路由器定义不对 ⑥软件进程问题 null解决思路： 如果OML链路从来没有起来过，那么首先应该检查硬件连接是否正确，特别是主用的MSI板是否插上了，因为主用MSI板上定义了NE起来时用于从OMCR下载软件和数据库的OML链路。然后核对DTE地址及路由器的设置是否正确。 如果OML链路以前是好的，那么首先要搞清是否有人对OML相关的参数改动过，如数据库中关于OML链路的定义、DTE地址、路由器设置等。在确认没有改动过后，应检查硬件问题，如MMS口是否退服、MSI板是否故障等（根据菊花链、拓扑图）。硬件也没有问题时，可初步确定为软件进程问题，可以设置一些Filter收集进程数据，并对相关的几个进程作一些操作（如重启进程）来恢复OML链路(注意:在OMC上,如果不能确认另一条(OML1)是正常的(E-U NO REASON),一定不能LOCK在用的OML0(B-U NO REASON)。 BSC533拓扑图BSC533拓扑图菊花链菊花链null参考操作步骤： OML链路的问题涉及的设备比较多，例如：OMCR，路由器，RXCDR等，为了正确定位故障应结合数据收集来处理问题。 ⑴进入BSC键入state 0 ,disp_p 0命令查看BSC的状态以及带OML的GPROC板状态，如GPROC板坏,则更换 (bsc:gproc 0 0 slot18;rxcdr:bsp 0 0 slot25)； (2)state 0 oml * *，看OML的状态； (3)根据菊花链或disp­_link(rxcdr)查找相关连接 (4)在rxcdr上用state 0 mms * *及state 0 msi * *查相关MSI板,如为硬件故障,则更换MSI板; (5)在bsc上disp_conn查bsc与rxcdr相关连接,找故障范围; (6)disp_eq 0 oml 0 0查看OML所属的MMS，查看OML的状态; (7)根据mms查看MSI板状态；如为硬件故障,则更换MSI板; (8)根据相关连接查是否为传输物理路由故障; (9)如果物理路由正常,检查相关数据或路由器。 2、GCLK无法锁相的问题 2、GCLK无法锁相的问题 GCLK无法锁相时会产生GCLK Failed Phase Lock的提示，并可能伴随出现4、14、13号等告警。 背景原理： GLCK 的功能是使得系统与更准确的时钟同步，对于BSS来说，GCLK要与MSC的时钟同步。时钟同步的目的是在射频部分提供0.05ppm（ppm为百万分之一。即如时钟为16.384M，则频率误差为16.384×0.05 =  0.8192Hz ）的高精度的时间同步。因此要提供参考时钟的E1/T1链路要尽量减少滑帧和失同步。 GCLK要与上一级时钟同步必须要有上一级时钟的参考信号，时钟参考信号是根据数据库的定义从指定的MMS口上提取的。在database中需要定义不同MMS口的时钟提取优先等级（可在设备上用state 0 mms * *查看时钟提取的MMS口，再根据msi拓扑图查看物理路由）。 nullGCLK在工作时有四种不同的状态： ①自由振荡状态：此状态是当GCLK刚上电时，其内部的晶体振荡器（OCXO）需要有预热的过程，以保持其正常的工作环境。此时间是固定不变的（30分钟），无法更改。在自由振荡状态下，时钟输出保持在0.05ppm的精度内。 ② Hold Frequency：此状态是GLCK与2M失锁时的状态。此时GCLK使用前一次ADC输出的值输入DAC以控制时钟，此状态是一个过渡状态，一般持续10秒。 null③Set Frequency：此状态一般在Hold Frequency之后。使用LTA（Long Term Average）值输入DAC以控制时钟。 正常锁相工作时GCLK每30分钟采样一个输出值存入内部存储器，存储器最大可以存放48个值，采用先入先出原则更新。所谓LTA就是指将这48个值取平均输入到DAC。Set Frequency状态下，GCLK不再往存储器中存放新值，只是使用以前的旧值，存储器停止更新，这是与锁相状态的不同之处。 ④锁相状态：此状态分为两个子状态， Acquiring Frequency Lock State，此状态是一个过渡状态，由硬件决定。 Frequency Lock State，此状态内GCLK已与E1/T1锁相，但需等待一段时间，以确定锁相稳定之后就进入锁相状态。 nullGCLK要与E1/T1同步必须有合适的时钟提取端口，这些端口的优先级按以下原则确定： ①MMS是否为B-U ②MMS的等级（在database中定义） ③在一定时间内MMS处于OOS状态的次数 ④如果以上都相同，则轮流作为时钟源 null 除了MMS口的等级外，在DATABASE中还有一些参数与GCLK有关： 设置是否允许时钟同步 chg_el phase_lock_gclk <*> <*> 0 Disable phase locking、1 Enable phase locking 设置时钟同步端口切换时间 chg_el wait_for_reselection 1 to 255（缺省值为10） 如果2Moos,而在10s内又恢复,则仍做为时钟源 设置时钟同步端口优先级 modify_valuemms_priority<*>mms <*>0 to 255 255: 优先级最高,同步于，0:不被选 1: 优先级最低 设置LTA告警门限 chg_el lta_alarm_range 1 to 255（缺省值为7） 每30分钟对gclk进行一次轮询当前48个值(8bit)与以前48个的平均值相比,有25%超出范围 +_10,则产生gclk告警 GCLK尝试重新锁相 reattempt_pl null可能引起此类告警的原因： ①因传输问题引起MMS退服 ②MSI板或MMS口硬件故障 ③数据库定义不合理 ④GCLK本身的问题，需要校正或更换 null解决思路： 当出现GCLK无法锁相的告警时首先要搞清楚参考时钟是从哪里来的。 检查一下数据库中有关GCLK的参数设置是否合理，如锁相应向上锁，即RXCDR向MSC锁、BSC向RXCDR锁、BTS向BSC或上一级的BTS（只有菊花链的情况）锁，向下一端的MSI口的时钟提取优先级应设为0。另外也不能只允许一个MMS口可以提取时钟。 如果数据库设置没有明显不合理之处，应注意一下与时钟提取有关的MMS口和MSI板的状态，MMS口退服可能是传输问题引起的，也可能是MSI板或MMS口硬件故障引起的。如果MSI板工作正常则应着重检查传输质量。 在排除了数据库、MSI硬件和传输原因之后，应校正或更换GCLK板。null参考操作步骤： ⑴为了利于问题的分析应收集以下数据(为今后分析提供依据)： ①state gclk * * （查看GCLK的状态） ②disp_el phase_lock_gclk （查看是否允许锁相） ③disp_eq 0 mms （查看MMS的参数，主要是时钟提取优先级） ④disp_el wait_for_reselection （查看时钟提取切换时间） ⑤disp_el lta_alarm_range （查看LTA告警范围） ⑥disp_eq gclk full（查看GCLK硬件版本信息）null⑵当GCLK无法锁相时可采用以下的方法： ①reattempt_pl ②使用lock/unlock命令（在上BSC倒换GCLK）看是否能使得GCLK锁相恢复。 ③查看MSI，MMS是否处于正常状态，是否有E1的相关告警产生，是否有MMS作为时钟源。 ④查看提供时钟的MMS是否与上一级的链路连接，上一级的时钟是否正常工作。 ⑤查看提供时钟的MMS的等级是否设置正确（一般为255）。 ⑥试着使用其它的MMS作为时钟源。（对于M-CELL可更换NIU）。 ⑦重新校准GCLK的时钟，或更换时钟板，具体校准的过程可见手册（68P02901W43，第二章为GCLK调测，第三章为MCU时钟调测，第四章为MCUm的时钟调测）。 ⑧如果出现无法校准，备用端的GCLK也不能用，并且没有备件。用仪表检查上行和下行链路的时钟，看是否为2.048M。可使用hp37717C 分析仪。以确定是那一端出现问题。 3、MMS告警和退出服务 （MTL XBL CIC OML PATH RSL） 3、MMS告警和退出服务 （MTL XBL CIC OML PATH RSL） 背景原理： 在MOTORLOA系统中除了硬件问题有四种与传输相关的情况会导致MMS告警或退出服务。 BER（Bit Error Rate） 误码率 Sync loss 同步丢失 Remote alarm 对端失同步告警 Frame slip 滑码 null①BER（Bit Error Rate）误码率 MMS通过监测0时隙的固定位来计算误码率，ber_loss_daily和ber_loss_hourly分别定义了24小时和1小时误码率的门限值，误码率超出门限值时，就会产生误码率告警。ber_oos_mon_period定义了误码率监测时间长度，在这个时间长度内误码率超过1‰（由MMS硬件决定），MMS将要退出服务。 null②Sync loss 同步丢失 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重新进入服务。 null③Remote alarm 对端失同步告警 对端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就重新进入服务。 null④Frame slip 滑码 24小时和1小时内滑码的次数分别超出slip_loss_daily和slip_loss_hourly定义的值时，MMS会产生frame_slip告警。24小时内滑码次数超出slip_loss_oos设定的值时，MMS会退出服务，滑码恢复后超出slip_loss_restore定义的时间，MMS就重新进入服务。 Daily –Waring：表示在24小时内告警门限超出，一般在此告警之前就会有其它更敏感的告警产生。此告警不会对系统的服务产生影响。 Hourly - minor alarm ：表示在1小时内有大量的问题产生。链路的性能降低，对系统的服务可能会产生影响。 OOS - Critical alarm ：MMS退出服务。 null可能引起此类告警的原因： MSI板或MMS口硬件故障（包括T43、MSI、NIU、XCDR板） 因传输问题（包括光路、微波、SDH、PDH传输路由等）引起的MMS性能告警或退服 2M线断路 null解决思路： 当出现MMS告警但并不退出服务时，问题一定在传输方面。如果MMS退出服务，则应先检查2M路由(光路、微波、SDH、PDH传输路由)是否断路，然后查看MMS在退出前是否有其它告警，有其它告警如误码率、滑码、失同步、对端告警时，应着重检查传输的问题，否则应是MSI板或MMS口的硬件故障问题。 null参考操作步骤： ⑴查看产生告警的site的MSI、MMS的工作状态。 Disp_eq State (举例:rsl-path-mms-msi-site) ⑵如果产生告警的MMS或MSI为B-U，检查告警是否已经消除。如果MSI或MMS不是B-U，使用lock/unlock、ins命令尝试将MSI或MMS恢复。 ⑶如果链路没有恢复，检查对端的MSI、MMS是否工作正常。 ⑷如果对端没有问题，在T43板处自环，查看MMS是否为B-U。如果MMS不为B-U，检查T43、MMS、MSI（NIU）等。 ⑸如果MMS为B-U，检查传输是否有问题。 ⑹如果仍不能恢复，将MSI（NIU）插拔一下，或替换MSI、T43板。另外注意检查MMS的背板的插座是否完好，MSI（NIU）与T43间的连接是否正常。 ⑺将site进行硬件或软件reset，最后可进行断电再起。 注意：在更换、插拔MSI（NIU）时，要先将MSI lock住。在BTS因MMS OOS退服或其他经过长途传输而到达BSC的中继电路,必先逐级排除传输线路或设备故障。4、DRI 12号告警4、DRI 12号告警 此告警表示信道编码失去TRAU帧同步（Channel Coder Lost TRAU Frame Synchronization）。此告警一般与其它告警共同出现，会影响系统的服务（单通问题）。null背景原理： 此告警表明CCDSP（TCU内信道编码数字处理单元）至少与RXCDR失步1秒。这是因为TDM链路错误使得帧失步。 可能引起此类告警的原因： ①RXCDR可能出现问题。 ②在切换时BSC没有把原DRI的相应CCDSP置为空闲。 此告警可能伴随着以下两个告警： [9] MSI (XCDR): TRAU Frame Synchronization Loss. [11] DRI: Channel Coder TDM Link Error. null解决思路： 查看XCDR板硬件是否有问题，如果没有问题，则等到该DRI没有被占用时ins一下。 参考操作步骤： ⑴查看告警信息，看是否同时有MSI 9号告警和DRI 11号告警。 ⑵如果在BTS有DRI 11号告警，则可能为DRI的问题。进入[3]。如果在RXCDR有MSI 9号告警，则可能为RXCDR的问题。 ⑶在BTS键入state命令，查看DRI的状态。如果DRI为B-U，则先检查是否告警已经消失，如果没有消失，就更换TCU。如果DRI不是B-U，使用lock/unlock命令设法使DRI恢复正常工作。 5、BSP 239号告警 5、BSP 239号告警 此告警表示GPROC的安全检测进程检测到进程错误。 背景原理： 安全检测进程是负责对GPROC内运行的进程检查以确定是否运行正常。当被检测的进程没有响应时就产生此告警。不同功能的GPROC所产生的239号告警表现为： [239] BSP [239] BTP(MCUF) [239]GPROC [239] BTP (MCU) 安全检测进程对系统进行周期性的检测，可以通过参数来调整检测的时间间隔。缺省的时间间隔为10分钟。 null可能引起此类告警的原因： ①GPROC、BSP、BTP板子损坏 ②被检测的GPROC、BSP、BTP软件进程出现错误 ③被检测的硬件出错 ④GPROC没插（但数据库中作了定义） ⑤从TCU到BTP的HDLC链路可能出错 ⑥BTP的输入输出链路出错 ⑦TCU的运行软件出错 null解决思路： 首先确定是哪块GPROC出现239告警，根据这块GPROC的功能来确定存在问题的进程或硬件范围。如BTP 239告警，出现问题的进程可能运行于MCU，也可能运行于TCU，还可能是BTP与TCU的通信进程。然后检查相应的硬件是否有问题，不能进一步判断原因所在时，应收集数据再作分析。 null参考操作步骤： ⑴在出现告警的基站键入state以确定发生告警的GPROC、BSP、BTP的状态。 ⑵如果显示为B-U，则键入 device_audit all ⑶如果device_audit成功则继续观察此设备。如果device_audit失败则键入 ins 如果还未正常则将GPROC 、BTS、BSC reset（注意：一般不重启设备） 或更换硬件。6、MTL告警 6、MTL告警 背景原理： MTL链路是MSC与BSC的信令链路，其在整个系统中起着MSC与MS、BSS连接的作用。MTL出现问题会导致其下属所有的BSS瘫痪。 MTL最多的告警一般为0号告警，出现此告警时MTL为D-U。此告警表示MTL链路与MSC已经失去联系。这是由于MTP第二层出现问题，而退出服务。但系统会不断尝试恢复此链路。另外当一条MTL链路退出服务时，其负荷会分配到其它MTL上，加重其它MTL的负担，而由于GPROC的处理能力的原因，MTL链路的平均利用率不能超过30％。因此MTL链路负担过重，会使得GPROC退出服务，从而导致更多的链路退出服务。 此告警与BSS 0号告警的区别为：MTL 0号告警表示一条MTL退出服务，而一个BSS可能有多条MTL链路，BSS 0号告警表示此BSS系统的最后一条MTL链路也退出服务，此时BSS完全瘫痪了。 null可能引起此类告警的原因： 1）MSC传来的MTP第二层LSSU信息出现错误。 2）MSC端拥塞超时 3）在要求时间内系统对MSU响应fail次数超出门限，确认消息超时 4）序列号出现错误 5）SUERM的错误门限值超出 6）收到不正常的FIB 7）硬件方面：检查GPROC、及相关MSI板 8）检查MTL相关databasenull解决思路： 先检查数据库内关于MTL链路定义有无问题，然后检查有关的MMS口、MSI板是否退出服务，再查与MSC的信令点码是否正确，在确认上述方面无问题后检查GPROC是否有硬件问题，必要时复位该GPROC。 null参考操作步骤： ⑴根据告警消息找到出现问题的站号，MTL的设备编号。 ⑵为确定MTL链路的连接情况，在RXCDR键入如下命令： disp_links add_link 6 1 16 17 0 16 (MTL) disp_conn add_bss_conn 10 0 1 0 0 (RXCDR-BSC) ⑶键入disp_equip 0 MTL * * 得到MTL的配置情况。 ⑷查看与MTL相关的设备是否正常工作，如有告警，应先处理这些问题。 state 0 mms * * 查看MMS的状态 state 0 msi * * 查看MSI的状态 disp_p 0 查看MTL由那个GPROC控制 disp_act_a 0 查看是否有相关的告警 ⑸使用lock／unlock、ins命令试着恢复链路。 ⑹检查RXCDR或MSC是否在rebooting，正常工作后检查MTL是否恢复。 ⑺比较MTP的第三层的信令点码与MSC处设置的点码是否对应。在BSC键入： disp_ele dpc 0（OMC信令点） disp_ele opc 0 (BSC信令点) ⑻找到控制此MTL的GPROC。 ins 0 gproc * * 如无效则键入： reset_de 0 gproc * * ⑼将BSC　reset。 7、IAS 1号告警 7、IAS 1号告警 IAS 1号告警——内部告警系统Serial Bus Connection Failure，多出现在BSC 或RXCDR基站内。 null背景原理： 在BSSC机柜中有一块的告警板，此板的作用为 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 熔丝和风扇等设备的告警。此告警板的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 which the cage belongs: 0 IAS Connected: YES 最后一项如果定义为YES，则软件尝试将告警信号送到此CAGE，但是如果物理上并没有将告警线连接到此CAGE，则会产生IAS 1号告警。一般配置CAGE时都将下面的CAGE定义为连接告警线，上面的CAGE不连接。如果在equip cage时将上面的CAGE也定义了IAS Connected: YES，则会产生大量的IAS 1告警。 null可能引起此类告警的原因： ①告警板故障 ②告警线连接错误 ③数据库定义错误 ④ 告警线损坏 ⑤ 风扇告警 解决思路： 先确定告警线连接在哪个CAGE中，查看数据库中定义的是否与物理连接相一致。不一致时修改数据库。如果数据库定义没有问题，检查告警板和告警线是否损坏。 null参考操作步骤： ⑴检查告警线连接与数据库中的定义是否相符 如果不符，使用命令： modify_value 0 ias_connected < * > cage ( # ) < * > yes/no ( # ) cage号 ⑵检查告警板是否完好，告警线是否损坏。必要时更换有关硬件。 (3)检查风扇 BSS 22号告警： BSS 22号告警： Trunk Critical Threshold Exceeded 此告警表示被BLOCK的CIC数目超过了紧急告警门限值。 null背景原理： 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中关于此告警的门限值设置得太低null解决思路： 首先查硬件问题，如E1连接是否正常，MSI、XCDR、GDP板是否有问题，有没有被LOCK，再检查是否因传输问题而使MMS口退服。同时应注意一下数据库中有关参数的定义是否合理，如果MSC端将CIC block，应手动将CIC复位。 null参考操作步骤： ⑴检查MSI，MMS状态是否正常，是否有相关的告警，键入如下命令： state 0 msi * * state 0 mms * * disp_act_a 0 disp_act_a 0 ⑵在BSC找到对应的连接到MSC的2M链路的MMS板，键入 disp_mms 0 * * 查看此MMS的各时隙是否有被block的。如发现大量的CIC被 block，首先确定是否为MSC边将其block的。如果不是则使用以下 方法将CIC释放。 ins 0 mms * * (rxcdr) ins 0 mms * * (bsc) ins 0 cic * * (bsc) 交换释放话路9、GPROC 245号告警 9、GPROC 245号告警 此告警表示一个GPROC或BTP退出服务。 背景原理： 此告警的不同形式为： [254] BSP: Device Failure [254] BTP: Device Failure [254] GPROC: Device Failure 如果主用的BSP或BTP出现此告警时，site已经reset了。如果不是主用端的BSP或BTP，则它会reset，并且系统会尽量将它恢复起来。如果一般的GPROC出现此告警，它会RESET，并会影响相应的信令链路，导致有关BTS退出服务。null可能引起此类告警的原因： ①其它设备或其本身的故障使得其退出服务 ②MMI命令使其退出服务 reset_site, soft_reset, reset_device和 csfp_swap等。 null参考操作步骤： ⑴如果为主用的BSP或BTP，则等待site reboot完成。 ⑵如果不是主用的BSP或BTP，过5分钟等待GPROC reset完成。 ⑶键入state，检查site内的状态。确定发生问题的site_id,设备号，槽位号。 ⑷使用lock/unlock、ins等命令尝试使GPROC 进入服务。 ⑸更换GPROC板(MCU板) ⑹进入GPROC的emon提示下，收集SWFM，同时收集告警发生前后的event。 注意： 一些GCLK、LANX、KSW等设备的告警可能会使GPROC退出服务，当出现GPROC 245号告警前出现大量相关设备的告警时应该注意及时排除，以免引起GPROC reset。同时注意CPU工作时的使用率，如果出现使用率超出60%时，应该引起注意，适当地将工作量移到其他的GPROC上。10、TIMESLOT 0号告警 10、TIMESLOT 0号告警 此告警表明因为RF的问题而使得呼叫失败的统计值（包括无法建立通话）超出告警门限。 背景原理： 在分配信道时，系统会检测空中各信道的信噪比。在数据库中定义了interfer_bands 1-4参数，此为四类信噪比的界限，以将信道分成不同的5类，前四类的信道按照优先顺序被分配，而第五类信道因为干扰强，系统不会将其分配出去。这样有利于避免受干扰大的信道被使用，从而保证了通话的质量。但是干扰较大时，大部分信道成为5类信道而无法使用，严重时会造成大量通话无法建立，产生告警。 null可能引起此类告警的原因： ①  RF干扰 ②数据库中有关参数设置不合理 解决思路： 应先寻找并排除干扰源，找不到干扰源时，如果允许通话干扰稍大一些，可以修改数据库的参数，将4类信道的干扰标准适当降低，这两种方法都行不通时，应考虑频率调整，或使用跳频。 null参考操作步骤： ⑴确定出现问题的site和RTF，在此site中输入 disp_rtf_channel [] 如果出现类似下页的输出，则 ⑵查找干扰源，首先确定此扇区内的各频点间是否存在干扰，再检查邻小区间是否存在干扰。最后可使用仪表检查外载波的干扰。 ⑶如果暂时查不到干扰或无法解决，可以使用以下命令 chg_ele interfer_bands,4 39 all 适当放宽4类信道的标准，以换取有较多的信道能被使用，减少通话阻塞。 ⑷将受影响的信道的频点改变，但操作时要注意，不要造成对其它频点的干扰。 ⑸在消除了干扰之后，要将interfer_bands,4改回原值。 nullMMI-RAM 0216 -> disp_rtf_channel 5 2 0 Start of report for RTF 2 0 at location 5: TIMESLOT SUB-CHAN STATE ---------------------------------------------------------------- 0 BCCH BCCH ACTIVE 1 (TCH/F) 0 ACTIVE 2 (SDCCH/8) 0 UNAVAIL (IBAND) 1 UNAVAIL (IBAND) 2 UNAVAIL (IBAND) 3 UNAVAIL (IBAND) 4 UNAVAIL (IBAND) 5 UNAVAIL (IBAND) 6 UNAVAIL (IBAND) 7 UNAVAIL (IBAND) 3 (TCH/F) 0 UNAVAIL (IBAND) 4 (TCH/F) 0 UNAVAIL (IBAND) 5 (TCH/F) 0 UNAVAIL (IBAND) 6 (TCH/F) 0 UNAVAIL (IBAND) 7 (TCH/F) 0 ACTIVE 其中UNAVAIL (IBAND)表示此信道因为干扰无法使用。 四、 注意要点 四、 注意要点 在处理告警问题时不可固守既定模式，要结合数据收集，具体问题具体分析，灵活应变，同时注意以下几点。 （1）要规范操作流程，按照正确的操作步骤进行。熟悉BSS命令。 （2）对告警发生的site、device、function要有正确的定位。 （3）清楚告警的含义。注意告警的等级和其对系统可能造成的影响。尤其注意对系统服务、正常工作已经发生影响或将要产生较大影响的告警。注意反复出现的告警。