GSM硬件故障排查-MOTO分册.docx

中国移动.四川公司.网络管理.技术支援Technical Support Centre of SCMCCMOTO硬件故障分析排查目录第1章概述3第2章BSS告警分析处理32.1告警分类32.1.1按告警类型分类32.2.2按告警严重程度分类42.2.3按告警网元分类52.2 查看告警信息62.2.1用事件窗口查看事件日志记录62.2.2 OMCR告警及事件信息识别92.2.3在事件日志窗口中过滤相关事件112.2.4相关事件/告警的显示122.2.5用行命令cel查看事件日志文件142.2.6用qfes进行相关事件的过滤152.3 常见告警处理162.3.1设备常见告警处理162.3.2内部告警处理212.3.3外部告警处理212.3.4常见告警代码及告警信息21第3章隐性告警排查处理233.1发现隐性故障的的方法233.1.1话务统计233.1.2 路测293.1.3历史告警记录303.1.4用户投诉31第1章 概述在无线网络的日常优化维护中，硬件设备是我们关注的最基本部分，因此对于硬件告警和设备故障是否能及时发现和处理，不仅关系到系统运行的稳定，而且也关系到系统性能的好坏与是否能提供各种业务服务。及时处理告警故障设备也能解决其他优化方式无法发现的网络问题，对整个网络的优化，提高全网系统性能都有很帮助。对于硬件的各种故障按照不同的呈现方式可以分为显现故障和隐形故障两大类。第2章 BSS告警分析处理在日常维护优化中碰到的告警事件，有些事系统运行，操作维护中产生的，例如新加网元、客户巡检、更换设备等都会产生告警；有时告警是瞬时性的，如传输闪断；有些告警对网络系统影响不大。如部分EAS外部告警、IAS内部告警；而有些告警虽然出现的次数较少，但是往往一出现就给系统带来严重的后果，如果严重将导致系统重启，如GPROC、BSP、KSW等的一些告警，因此在日常优化过程中对这严重的告警要实时监控，对这些告警尽早发现、分析、定位、解决，让网络保持良好的运行。2.1告警分类硬件故障按照起告警类型、告警的严重程度以及网元可以进行不同层面的分类。通过分类以便针对不同的告警类型制定不同的处置策略。2.1.1按告警类型分类BSS告警就是可以通过OMS-R终端查看的告警。BSS告警可分为故障告警和事件告警两类。 故障告警设备出现故障和异常后向网管设备上报的告警（如单板故障）。通过采取相应的处理措施，可以使产生此类告警的故障和异常恢复。 事件告警设备运行时的偶然性事件告警，是设备运行时的一个瞬间状态，只表明系统在某一时刻发生了某一预定义的特定事件（如通路拥塞），不一定代表故障状态。一些事件告警是定时重发的，比如资源核查类事件告警，因为会定时核查，发现资源还是不满足的话，就会重发告警。事件告警只起知会作用，无需处理。2.2.2按告警严重程度分类告警级别用于标识一条告警对业务的影响的严重程度。BSC告警按严重程度递减分为四级：紧急告警、重要告警、次要告警和提示告警。如下表所示：告警级别的定义及处理方法告警级别定义处理方法紧急告警此类级别的告警影响到系统提供的服务，必须立即进行处理。即使该告警在非工作时间内发生，也需立即采取措施。如某设备或资源完全不可用，需对其进行恢复。需要紧急处理，否则系统有瘫痪危险。重要告警此类级别的告警影响到服务质量，需要在工作时间内处理，否则会影响重要功能的实现。如某设备或资源服务质量下降，需对其进行恢复。需要及时处理，否则会影响重要功能的实现。次要告警此类级别的告警未影响到服务质量，但为了避免更严重的故障，需要在适当时候进行处理或进一步观察。发送此类告警的目的是提醒维护人员及时查找告警原因，消除故障隐患。提示告警此类级别的告警指示可能有潜在的错误影响到提供的服务，此类告警无需处理。只是对系统的运行状态的报告。2.2.3按告警网元分类不同的告警属于不同的网管类型。按照各种告警的网元类型可以将告警分为以下几类，如下表所示： 网管分类说明网管分类相关告警电源系统有关电源系统的告警。环境系统有关机房环境（温度、湿度、门禁等）的告警。信令系统有关随路信令和共路信令的告警。中继系统有关中继电路及中继板的告警。硬件系统有关单板设备的告警（如时钟、CPU等）。软件系统有关软件方面的告警。运行系统系统运行时产生的告警。通信系统有关通信系统的告警（如前后台通信）。业务质量有关服务质量的告警。处理出错其它异常情况的告警。2.2 查看告警信息OMCR上提供了无线网络和OMCR系统本身的事件/告警日志记录和管理功能，使运维人员能及时方便的了解系统在运行过程中所发生的故障和事件。事件/告警管理窗口在OMCR的图形用户界面上的位置如下图所示2.2.1用事件窗口查看事件日志记录1、用鼠标左键点击图形用户界面上的事件日志窗口，弹出下图所示事件日志查询窗口。如下图：2、如下图所示，在事件日志记录窗口中点击菜单Options-Load Event Log选项，选择装载事件日志文件。如下图：3、在弹出的文件选择窗口上选择想打开的日志记录文件的路径/usr/gsm/ne_data/ev_logs/和相应的文件名，将其变黑，点击OK按键，打开日志文件。备注：事件日志记录文件名的形式为“enyyyymmddhhmmss”，其中时间戳为时间日志文件生成时间。摩托罗拉OMCR一个事件日志文件只能记录5000个事件记录，超过5000个记录时系统会自动生成下一个日志记录文件。4、打开事件记录窗口如下所示，可以在事件记录窗口中对事件进行事件分类、排序、相关告警事件及过滤等预处理。2.2.2 OMCR告警及事件信息识别 OMCR上事件/告警的格式第1行： OMC id number：事件标识号 Alarm State：告警状态 Operater：事件操作者第2行： Alarm type：告警类型 Device type：设备类型 Device id：设备id号 Date：日期 Time：时间第3-5行： Error id：告警出错id号 Alarm message：出错告警消息 Alarm clearing type：告警清除类型 Severity：告警严重级别 5Additional Info：其他消息事件的可分类型在事件记录窗口中点击Sort菜单，可看到Sort的下拉菜单如下图所示： 由分类排序菜单可以看到事件可按下列类型分类排序： id：事件id号 state：事件操作状态 operator：事件操作者 comment：事件注释 type：事件类型 class：告警的设备类型 instance：具体的告警设备 date/time：告警的日期和时间 alarm type：具体的告警类型说明 severity：告警的级别 ascend：由低到高的升序排列 desecend：由高到低的降序排列2.2.3在事件日志窗口中过滤相关事件在打开的事件日志窗口里点击菜单Option-Filter弹出Define Filter Criteria窗口，在该窗口里定义想过滤的事件特性，点击OK。2.2.4相关事件/告警的显示1、在事件记录窗口中用鼠标左键点击一事件，使其颜色变红。选中的事件日志如下图：2、点击事件窗口菜单Logs Search-Associated Alarms选项，弹出下图所示的相关告警事件窗口。2.2.5用行命令cel查看事件日志文件1 在omc_splat上点击用户图形界的xterm图标或用鼠标右键点击CDE桌面选择New Windows打开xterm窗口。2 改变系统的当前路径到/usr/gsm/ne_data/ev_logs/目录下 cd /usr/gsm/ne_data/ev_logs3 在/usr/gsm/ne_data/ev_logs目录下用ls行命令找到需打开的事件日志文件。4 用cel命令即可打开相应的事件日志文件。cel ev20000201000005 2.2.6用qfes进行相关事件的过滤格式： cel ev qfes “event type” “device type” “device instance” “startTime” “endTime” “infostring”例：查看2000年1月21日BSS02上发生的critical告警somcsys1:omcadmin cel ev20000121* | qfes BSS02 Critical | more#0 - NOT APPL - *NONE*. communicationFailureEvent - MTL - BSS02(BSS02:SITE-0:): 0 MTL 0 - 21/01/2000 00:05:47. 0 Signalling Link Failure - FMIC - Critical -/-. Config Tag 801232 00 00 00 00 FF FF .#1 - NOT APPL - *NONE*. communicationFailureEvent - MTL - BSS02(BSS02:SITE-0:): 0 MTL 0 - 21/01/2000 00:05:54. 0 Signalling Link Failure - FMIC - Critical -/-. Fault - Enable - MTL 0 - Reconfig Pending - Config Tag 801232 At the time of the alarm the subscriber impact was : SITE 0 : Pending 00 00 00 00 FF FF .2.3 常见告警处理常见告警故障处理及分析MOTOROLA基站的告警按故障设备可分为三类：设备告警、内部告警、外部告警。以下就对这三类告警中的常见多发告警进行分析处理。 2.3.1设备常见告警处理设备告警是硬件告警最常见也是最重要的告警，告警设备一般为基站的主要器件，它的告警类型就是它的设备类型。 1. DRI 29：Front End Processor Failure - Watchdog Timer Expired前端处理器故障DRI硬件故障，出现此告警时DRI可能会反复自启，可能会退服，应先reset or ins DRI应进行INS或RESET处理，若告警未消失，更换TCU。2 DRI 40-47 ：Channel Coder Timeslot 0（-7）Failure0-7时隙信道编码器失败。M-CELL基站经常出现此类告警，应进行INS或RESET处理，不行再更换TCU900。3 DRI 51 ：Baseband Hopping TDM Link Error基带跳频TDM链路错误。此告警有几种可能性：TDM-Highway BUS或KSW可能有问题。DRIM的FEP，CCDSP可能有问题。此告警须在现场具体测试分析。测试后判定故障点。4. DRI 81：Transmitter Synthesizer Failure收发单元故障此告警为收发单元TCU故障，故障原因有可能为：l 接收Calibration频点丢失l 信道盘的CEB故障l 射频电缆连接失败处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU 5. DRI 86 ：Transmitter Failure输出功率失败，引起DRI退出服务。状态：D-U。此告警是信道盘的功率放大器失败。应更换信道盘。 6 DRI 91 ：Power Amplifier Power Low But Functioning信道盘的功率放大器输出功率低于门限，状态B-U。此告警有可能由于高温等原因引发，有些站经常性出现DRI91的盘则需要更换，以免因小区功率不平造成掉话。有时侯在现场看不见此告警，须从OMC的事件窗口检查。 7 DRI 92 ：Power Amplifier Temperature High But Funncioning信道盘的功率放大器高温告警，但可以工作。 信道盘的功率放大器的高温多数是因机房高温，或机箱内的风扇故障造成的。在出现此告警后，信道盘的性能会下降。如温度过高，信道盘会自动闭塞。因此常出现此告警的信道盘应于以更换 8 DRI 112 （114） Receiver Synthesizer Failure接收单元合成器故障此告警为收发单元内部故障，其主要原因大概有：l 收发信单元内部直流供电故障l 收发信单元内部硬件故障处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU 9 DRI 150: Receive Matrix Branch 1 control Link Failure接收矩阵支路控制失败，状态: B-U此告警M-CELL和Horizon中均有出现，伴随切换掉话，切换成功率低，呼叫建立成功率低导致的话务量减少。有时也会导致信道盘的path_balance值偏高。 其主要原因有：l 有故障的接收矩阵即SURF；l 收发信单元与接收矩阵之间的同轴电缆断路；l 收发信单元与接收矩阵之间的同轴电缆短路；l 信道盘中的均衡器板控制电路出现故障；l SURF内部前-后端接口短路；l SURF内部前-后端接口断路处理方法：根据现场判断具体情况更换硬件。 10 DRI 152: Control Processor to Power Amplifier Communication Failure 处理器与功率放大器的通信失败此告警是信道盘中的CEB及对PA的控制失败。首先对信道盘进行INS或RESET处理，不行再更换信道盘。11 DRI 209 : Timeslot Configuration Failure信道分配失败 D-U小区资源管理器CRM为MS分配无线信道时在射频硬件上分配时隙失败。 产生的原因有：l 收发信单元TCU故障；l DRI软件故障；处理方法：远程ins或reset TCU,告警消失并监测；若告警未消失，更换TCU 12 DRI 218 ：Timeslot Configuration Failure不健全的信道接收校验数值此告警的出现时用指令：disp_cal_data 看到基站接收数据校准值中出现80（错误的校准数据），还找到根本的原因，远程对硬件reset或ins均无作用，现场人员有时需更换新硬件设备而有时只需对信道盘开关电即可恢复，初步判断为硬件TCU(Horizon目前还未发现)接收单元问题。13 DRI 234 ：Active Link Connection Failure主用链路与BTP的链接失败。状态：D-U此告警主要发生在M-CELL上，是主用BTP到DRI/TCU900的链接失败。其原因主要分为：l FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。l TCU900/FOX/FMUX/BTP本身的问题。l 还有则是由于某种原因，使处理机运行过程出现问题，使其与TCU900失去联系。处理方法：这类情况可用LOCK-UNLOCK恢复。14 DRI 235 ：Standby Link Connection Failure备用链路与BTP的链接失败。对网络不造成影响。但如果出现整个机柜告警应当引起重视。以免基站主用出现故障倒换到备边时，出现整个机柜不能工作。此告警只出现在M-CELL，是备用BTP到DRI/TCU900的链接失败。其原因主要分为：l FOX/FMUX/BTP之间的连接和使用的光纤类型的问题。l TCU900/FOX/FMUX/BTP本身的问题l 有时侯如有大部分DRI出现此告警，有可能是没将BTP做成冗余形式。 DRI 239 ：Process Safe Test Audit Failure有可能是因为机房内高温造成，若不及时进行处理，会继续出现92#告警。15 DRI 243 ：Unlocked Device Not In Service信道盘退服，状态：D-U此告警出现在没有主告警的情况下信道盘退服可能的原因是：系统错误导致的信道盘退服。处理方法：发现告警后,RESET THE DRI观察，如果告警仍然存在这更换信道盘。116. GCLK 2 : Clock Reference Failure时钟参考失败此告警为基站MSI板的时钟提取丢失其主要原因有：l E1/T1链路故障l 没有MSI/NIU的时钟信号l 没有XCDR的时钟信号l GCLK 时钟提取电路失败处理方法：更换MCU或NIU,若仍然出现告警则需通过传输处理 17.GCLK 4 : Phase Lock Lost时钟参考信号锁相丢失此告警有时会引起切换掉话或切换成功率低，有时没有影响，大多数是因为传输大网与移动网对时钟要求相距较大引起。其主要原因有：l 大多数情况是在E1/T1链路上偏移或不稳定的时钟超过所允许的极限而引起的时钟失锁。l 不正确的时钟源或GCLK硬件故障l GCLK 晶体振荡器由于老化不能长时间对信号源进行锁相处理方法：一般情况下先进行时钟重新校准或SWAP BTP到备边,若无作用则请传输中心处理。18. GCLK 8 ：主备时钟频差过大。此告警是由BTS的本振时钟主备频率偏差过大，应及时对时钟进行校准。M-CELL: 8000HZ.19. GCLK 14 : Phase Lock Failure时钟参考信号锁相失败此告警有大多数时间会引起切换掉话或切换成功率低，其主要原因有：l GCLK硬件故障l 有问题的前时钟源l 规范问题 20 GCLK 18: Not Operational主时钟不工作此告警是由于基站主控板MCU不能建立正常的同步时钟初始化。出现的原因：可能是由于固件故障，或是硬件老化。出现此问题时应reset MCU,若告警未消失则需更换MCU；若告警消失，则不需在作进一步的观察。21.GCLK 24 Bad Clock Source or OCXO (oscillator) :不精准的时钟源或有故障的时钟振荡器。出现此告警时先reset site 或主控倒到备边，若还存在告警则需传输帮助解决。22. GCLK 26: GCLK Calibration Request GCLK校准失败此告警有大多数时间会引起切换掉话或切换成功率低其主要原因有：l GCLK 校准超出要求范围（即不能进行校准）l 有问题的GCLK时钟源或时钟源超出传输要求规范l 在MCU第一次加电时不能进行校准，因此不能计算LTA值l GCLK长时间不能进行锁相，超出允许时间l GCLK 硬件故障处理方法：更换MCU23.BTP 39: 软件故障此告警出现时会引起BTP D-U Code Load Failure或反复code load，其主要原因有：l 下载的软件故障l 主控GPROC故障处理方法：l 进emon reset site,并观察l 更换MCU（或SWAP BTP） 2.3.2内部告警处理内部告警的告警设备一般为基站的辅助设备如风扇、保险、开关、电源模块等。1 IAS 86#cabinet fan failure：基站风扇故障2 IAS 81 ：PSU供电单元输出失败。通过计算机检测电源模块，判定故障及时更换。3 IAS 95 ：低噪音放大器保险坏。M-CELL对于G*900的选件中没有采用低噪音放大器。所以此告警对DCS1800基站有影响。解决措施为：更换对应的保险。对于内部告警，除一般的高温和风扇告警，其他一些内部告警一般为假告警，不与处理。2.3.3外部告警处理外部告警一般为假告警，一般不作处理。 2.3.4常见告警代码及告警信息常见告警代码及告警信息如下表：类型序号设备告警号告警内容描述级别BSC1GCLK232GCLK: Processor Bus Communication FailureGCLK退服高2GPROC35GPROC: LAN Connection FailureGPROC退服高3KSW232KSW: Processor Bus Communication FailureKSW退服高4KSW225KSW: Internal Loopback Audit FailureKSW自检失败高5KSW224KSW: Safe Test Audit FailureKSW自检失败高6LAN1LAN: LAN FailureLAN退服高7MTL0MTL: Signalling Link FailureMTL退服高8PCU0PCU: Last GSL FailedPCU退服高9BSS27BSS: Last GBL Failed所有GBL退服高10BSS21BSS: Trunk Major Threshold Exceeded过多的CIC退服,通常由于A口中断中11XBL10XBL: Link DisconnectedXBL退服高BTS1Site00. SITE: Last RSL Link Failure对应基站退服。高2Site2121. SITE: No Clock References Available基站不能获取时钟。中3CELL11. CELL: Cell Radio Timeslot Capacity Loss无线信道资源减少：通常由Path中断造成。高4CELL88. CELL: GPRS unavailable - No PRP availablePRP容量不足/退服造成 GPRS不可用高5CELL99. GPRS unavailable - No GDS availableGDS时隙不足/退服造成 GPRS不可用高6DRI40. 47.40. 47. DRI: Channel Coder Timeslot (07) Failure载频时隙退服 ：载频Channel Coding Digital Signal Processor（CCDSP）与Front End Processor (FEP)通讯出错。高7DRI234234. DRI: Active Link Connection Failure载频退服高8DRI243243. DRI: Unlocked Device Not in Service载频退服 或 BSC定义了多余载频数据高9DRI218218. DRI: Invalid Transceiver Calibration Data载频调测值中有 80中10DRI150150. DRI: Receive Matrix Branch 1 Control Link Failure载频接收矩阵出错： 通常由SURF板出错造成。高11GCLK1414. GCLK: Phase Lock Failure时钟失锁，可通过命令 reattempt_pl 0 使时钟进行锁相工作。中12GCLK44. GCLK: Phase Lock Lost时钟失锁，建议检查传输、MCU、NIU中13IAS83Low Voltage Disconnect Imminent基站电源过低产生的告警低第3章 隐性告警排查处理在OMCR上只能提供无线网络和OMCR本身的事件和告警，然而除此以外还有一部分硬件故障，影响着网络的性能却没有在告警和事件信息中体现出来。这部分硬件故障即为隐性故障。3.1发现隐性故障的的方法硬件隐性故障会影响网络性能，降低系统性能指标和用户感受。通过隐性故障的影响我们可以从逆向寻找设备存在的隐性故障。由于这部分故障具有较强的隐蔽性，在排查这类故障时，一般可以通过统计指标分析、现场测试、历史告警分析、用户投诉等方面去查找。3.1.1话务统计 话务统计提供了各种指标去衡量系统服务的好坏。很多硬件隐性敀障都会反映到话务统计的某顷指标上来。常用的指标有信道完好率，掉话，切换，无线接入性等。如果某个硬件存在问题，则有可能影响到其中一顷戒者几顷指标。因此如果返些指标的发化，特别是在没做任何参数修改的情况下发生了发化，我们应该考虑可能是硬件的因素。 硬件问题主要是BTS 射频方面存在的故障，包括载频校准值、射频各部件产品本身、天线安装等方面的问题。总的说来，基站的发射部分产生的问题对系统指标的影响更大一些。这些问题主要反映在关于载频的统计指标中，我们常用的三个观察指标为：BER、PATH_BALANCE、和RF_LOSSES_TCH。BERBER是比特误码率（Bit Error Rate）的简写，它是一个normal distribution统计，每个SACCH复帧（480ms）上报一次，反应了激活信道（时隙）的下行接收质量。我们都知道，在TCH上一个SACCH复帧内移动台接收100个下行帧，得出每帧的BER。这100个BER通过非加权的算法得出一个该SACCH复帧内的总体平均BER，并把该平均值转换为GSM定义的八个质量级别（quality bands）之一，把上行测量报告中报告给BSS。BSS在进一步交由HDPC平均处理前可将服务级别转化成相应的假定值。在数据库参数中可定义不采用假定值，而直接采用报告的服务级别值来进行处理。在数据库参数中alt_qual_proc=0采用BER，alt_qual_proc=1采用quality bands。HDPC决定了MS是否需要进行功率控制（Power Control）或切换（Handover）。一般观察较长时间后，若该载频的每个时隙的BER一直都较高（BER值的正常范围应视系统而定，系统市区平均（BER_MEAN）值比郊区高，一般正常值在1.6以下，最大不应大于3）时，反映该载频的下行链路质量存在问题，需检查该载频的校准、频率干扰及载频本身是否存在问题。PATH_BALANCE:path_balance是每480ms更新一次的反映链路平衡情况的normal distribution统计。路径损耗（path loss）等于发射台的发射功率与接收台的接收功率的差值。基于每sacch复帧基础上计算该统计的公式如下：Path_balance = uplink Pathloss- downlink Pathloss其中：uplink Pathloss = actual MS txpwr rxlev_uldownlink Pathloss = actual BTS txpwr rxlev_dlrxlev_ul/dl是当前报告的最新值，而不是平均值。上面的结果再以110为基准衡量，即实际的path_balance统计项等于上面的Path_balance加上110。一般理论上上行和下行的路径损耗应相同，考虑到分集接收的增益，上行路径损耗应低一些，所以该统计项应低于110。考虑到无线信号在一般空间传播的不稳定性和多径效应，根据实际经验，该统计项在100-115之间时，我们认为都是正常的。该统计的平均值高于115表明BTS接收通路可能存在 问题，如天线、射频电缆、接收分路器等等，低于100表明BTS发射通路可能存在问题，如天线、射频电缆、滤波器、合路器等等。RF_LOSSES_TCH:RF_LOSSES_TCH和RF_LOSSES_SD都属于呼叫清除统计。我们知道在专用模式下，MS每480ms向BSS发送一次测量报告。当在规定时间未收到测量报告时，HDPC中的计数器link_fail将减1。Link_fail的最大值可在数据库中利用add_cell命令定义。如果一段时间的测量 报告未送达BSS则明显表明MS的上行连接丢失了。在这种情况下，link_fail连续减1，并最终达到0，当达到0时，RSS宣布链路连接失败，并送一个错误指示信息来通知RRSM。RRSM则指示RRS停用此TCH，并发送一无线信道释放（Radio Channel released）消息给SSM。SSM向MSC发送一清除请求（Clear Request）。RF_ LOSSES_TCH属于counter统计类型，是当RRSM接收到信道类型为TCH的错误指示信息时基于每时隙统计的。它统计了由于RF问题导致通话非正常结束的次数。当一个载频的RF