诺西BTS常见告警结构解析及处理思路 - 图文

更新时间:2023-09-10 10:21:01 阅读量: 教育文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

深圳市网信联动技术有限公司

资料编码 使用对象 编写部门 密 级 网络优化工程师 技术服务部/培训部 内部公开 设备名称 设备版本 资料版本 状态 NOKIA S12 V1.0 有效

诺西BTS常见告警结构解析及处理思路

拟 制: 审 核: 审核批准: 入 库: 张肖恒/技术事业部 /技术服务部 邓传玲/技术资源及培训部 培训部 日 期: 日 期: 日 期: 日 期: 2010-06-12

网 信 联 动 技 术 有 限 公 司

版权所有 侵权必究

第 1 页 共 14 页

深圳市网信联动技术有限公司

关键字:BTS,BCF

摘要:在诺西系统的日常网络优化过程中,我们常常通过HIT软件远程登录到OSS使用MML命令查询

BSC 及BTS的历史告警和当前处于激活状态的告警,HIT软件会输出告警的相关信息,本文档是我查阅资料及结合工作中的经验体会总结的一些常见的BTS告警信息结构的解析,并对部分告警的处理思路进行说明。希望对大家的工作有所帮助,互相学习,共同进步。

第 2 页 共 14 页

深圳市网信联动技术有限公司

目录

1 NOKIA系统查看告警的常用MML命令 ........................................................................................................ 4 2 BTS告警结构 .................................................................................................................................................... 4 3 BTS常见告警附加消息详细图解及处理思路 ................................................................................................. 5 3.1 (7743)告警 .............................................................................................................................................. 6 3.2 (7745)告警 .............................................................................................................................................. 6 3.3 (7746)告警 .............................................................................................................................................. 8 3.4 (7767)告警 .............................................................................................................................................. 9 3.5 (7601)告警 .............................................................................................................................................. 9 3.6 (7604)告警 ............................................................................................................................................ 10 3.7 (7606)告警 .............................................................................................................................................11 3.8 (7607)告警 ............................................................................................................................................ 12 3.9 (7744)告警 ............................................................................................................................................ 13 4 总结 ............................................................................................................................................................... 14

第 3 页 共 14 页

深圳市网信联动技术有限公司

本文档主要总结了NOKIA BTS常见的7743、7744、7745、7746、7767、7749、7606、7607、7605、7604、7601等告警信息的结构及处理思路。

1 NOKIA系统查看告警的常用MML命令有以下几个:

(1)查看BTS当前告警:ZEOL: BCF IDENTIFICATION: BTS ALARM NUMBER, ALARM CLASS; 例如:ZEOL: 21:NR=7745; 查看BCF号为21、告警号为7745、且未被cancel的告警。 ZEOL:30:CLS=AL3; 查看BCF号为30、告警级别为3星、且未被cancel的告警。

(2)查看BTS历史告警:ZEOH: DATE, TIME: BCF IDENTIFICATION, OBJECT TYPE, CURRENT STATE OF OBJECT, ALARM NUMBER, ALARM CLASS;

例如:ZEOH:2006-3-8,8-30-0; 查看2006年6月8日8时30分之后的告警历史,包括已经cancel的和未被cancel的;

ZEOH::NR=7745; 查看今天的7745告警历史,包括已经cancel的和未被cancel的。 另外,查询BSC告警的命令为ZAHO和ZAHP。其使用方法如下:

(1)查看BSC当前告警:ZAHO: UNIT IDENTIFICATION: ALARM PARAMETER;

例如:ZAHO:OMU:CLS=AL2; 查看当前告警级别为2星级、告警对象为OMU、且状态为ON(即未被cancel的)。

ZAHO; 查看当前所有状态为ON的告警。

(2)查看BSC历史告警:ZAHP: UNIT IDENTIFICATION: ALARM PARAMETER: DATE, TIME; 例如:ZAHP::CLS=AL3:2006-3-8; 查看2006年3月8日0时以后的所有3星级告警,包括已经cancel的和未被cancel的;

ZAHP:OMU:NR=690:2006-3-9,8-0-0; 查看2006年3月9日8时之后的所有告警号为690的告警(OMU状态改变的告警),已经cancel的和未被cancel的。

注:本文档主要对列出了工作中经常见到的一些需要处理的BTS告警,并对这些告警信息的结构进行了详细的图解,给出了处理这些告警的思路。

2 BTS告警结构

如图所示:

第 4 页 共 14 页

深圳市网信联动技术有限公司

说明:如上面两张图所示,使用ZEOH和ZEOL命令分别查询了BTS的历史告警和当前告警,图中红色字样是对输出的告警信息整体结构结构的注释。

3 BTS常见告警附加消息详细图解及处理思路

下面对BTS常见告警的含义及输出信息的附加信息字段进行详细的图解,有助于帮助我们定位故障的原因

第 5 页 共 14 页

深圳市网信联动技术有限公司

及故障发生的位置。

3.1 (7743)告警

告警含义:在测量时段内,在信道上的平均占用时间低于定义的门限值(BSC参数MINHTT)。该告警用来监控话务信道的功能,并检测可能出故障的信道。其告警信息输出如下图:

说明:该告警补充信息(附加消息)字段:

第1~8字段:指示时隙0~7平均占用时间是否低于定义的门限值。 第9字段:标出平均占用时间最短的时隙

第10字段:标出在时隙中平均占用时间最短的子信道,00--半速率TCH子信道0,01--半速率TCH子信道1,02--全速率TCH信道。

第11字段:在测量时段内TCH最短平均占用时间,以秒计。

处理思路:可以先试着重启一下载频,如果重启后告警依然存在,需要通知维护人员更换硬件。 注:上图中的黄色字样是BTS告警信息里都会出现的一些信息,在下文中不再赘述。

3.2 (7745)告警

告警的含义:在一个信道中,呼叫因失败而终止的比例超出了门限值(BSC级参数TCHFR和SCHFR)。该告警用来监控话务和信令信道的功能,并检测可能出故障的信道。

第 6 页 共 14 页

深圳市网信联动技术有限公司

(图1:TCH信道7745告警)

注:上图中告警信息的补充信息(附加消息)字段的第一个字段为01,可以判断该告警为TCH信道的信道失败率高于告警门限导致的。

(图2:SDCCH信道7745告警)

注:上图中告警信息的补充信息(附加消息)字段的第一个字段为01,可以判断该告警为TCH信道的信道失败率高于告警门限导致的。

说明:该告警补充信息(附加消息)字段:

第1字段:标志掉话告警是关于TCH信道还是SDCCH信道,01--TCH信道,02--SDCCH信道 第2~9字段:标志0~7时隙掉话率是否高出定义的门限值,00--低于门限值(无告警),01--高出门限值(告警)。

第10字段:掉话率最高的时隙。

第11字段:子信道标识,对于TCH信道告警:00--半速率TCH子信道0,01--半速率TCH子信道1,

第 7 页 共 14 页

深圳市网信联动技术有限公司

02--全速率TCH信道;对于SDCCH信道告警:00~07--SDCCH子信道1~8。

第12字段:指定信道中,测量期间因故障造成的TCH或SDCCH子信道释放占全部信道释放的比例,即掉话率。

处理思路:出现掉话告警时,先查看是否伴随有其它的告警,比如7744干扰、或是其它硬件故障告警。如果7745告警同时伴随有其它告警,则先解决相关的告警,一般情况下,相关的告警消除后,7745告警也会自动消除;如果无其它告警,则可判断是载频出现故障,可以先试着重启载频,如果重启后告警依然存在,需要通知维护人员更换硬件。

3.3 (7746)告警

告警的含义:在一个信道中,呼叫因失败而终止的比例超出了门限值(BSC级参数TCHFR和SCHFR)。该告警用来监控话务和信令信道的功能,并检测可能出故障的信道。

说明:该告警补充信息(附加消息)字段:

第1字段:拥塞的对象,01--SDCCH,02--TCH,03--扩展小区SDCCH,04--扩展小区TCH 第2字段:测量期间,最后一次观测到拥塞的时间(小时,分钟) 第3字段:测量期间信道占用次数

第4字段:测量期间,因拥塞而被拒绝的SDCCH或TCH占用请求占全部信道占用请求的百分比(即拥塞率)。TCH百分比包括所有的半速率、全速率和推荐速率信道占用请求。

第5字段:测量期间,因拥塞造成的被拒绝的半速率信道占用请求与全部占用请求的百分比;只有拥塞对象是TCH时才有意义。

第6字段:测量期间,因拥塞造成的被拒绝的全速率信道占用请求与全部占用请求的百分比;只有拥

第 8 页 共 14 页

深圳市网信联动技术有限公司

塞对象是TCH时才有意义。

处理思路:出现7746告警时,表示基站出现拥塞。处理方法可参考拥塞小区的处理办法。

3.4 (7767)告警

告警的含义:基站系统出现故障,BSC无法为BTS重新配置一个能够工作的BCCH。如果相关的BTS处于正常工作状态,但BTS未配置BCCH-TRX,或者用户锁定了BTS的BCCH-TRX,系统也会发出该告警。若没有可工作的BCCH,基站就无法传输话务。

说明:该告警没有补充信息(附加消息)字段。

处理思路:通常该告警是由BTS或者BSC检测到的BTS故障引起的。查看影响BTS的其它告警,解决故障单元,即可使BCCH-TRX恢复到WO状态。当用户对基站进行重启时,也会出现7767告警,一般在此告警之后会cancel其他告警的。

3.5 (7601)告警

告警的含义:在基站中出现一个或多个主要故障。

第 9 页 共 14 页

深圳市网信联动技术有限公司

说明:该告警补充信息(附加消息)字段: 第1字段:机架(机柜)编号 第2字段:支撑架编号 第3字段:插槽 第4字段:单元类型 第5字段:单元编号 第6字段:子单元编号

处理思路:检查是否伴随有7606(TRX FAULTY),7607(TRX OPERATION DEGRADED),7603(BTS FAULTY),7604(BTS OPERATION DEGRADED)告警,根据活跃告警补充信息字段定位故障单元判断故障原因。通知维护人员检查硬件。

3.6 (7604)告警

告警的含义:告警代表的扇区内的某个(或几个)单元出现了一个或多个主要故障。查看告警的补充信息字段,可了解故障原因。

说明:该告警补充信息(附加消息)字段: 第1字段:机架(机柜)编号 第2字段:支撑架编号 第3字段:插槽 第4字段:单元类型 第5字段:单元编号 第6字段:子单元编号

处理思路:检查是否伴随有7606(TRX FAULTY),7607(TRX OPERATION DEGRADED)告警,根据活跃告警判断故障原因。通知维护人员检查硬件。7601和7604一起出现的话,基本上就可以肯定是天馈线的故障。

第 10 页 共 14 页

深圳市网信联动技术有限公司

这是现网中四代站的常见告警,处理方法应根据告警提示有针对性地进行:1,首先检查硬件数据库与实际的配置是否一致,若不一致则须重新下载,然后重起基站;2,是否为风扇告警,风扇告警则主要查看电源连接线是否正常,不行则进行更换;3,检查基站天馈及收发连接线是否正确,对于提示说收发电平差异的告警则需重点检查此项;4,载频是否正常,有些载频的告警通过指示灯便可判断,但有些通过得TRX的环路测试才能判断;5,合路器是否工作正常,若是RTXX的问题,会有黄灯告警,若是DVXX,须进行更换尝试;6,对于提示说串行DL BUS障碍或BUS线断裂的告警,则该详细检查后背板及厚背板的BUS线;7,对于时钟飘移的告警,则带上频率计,将DAC值调至2000左右既可;8,一些载频低功告警或接收支路告警,确认是载频自身问题之后,应予以更换;9,对于反射功率过高的告警,可关闭调频观察,对调合路器或更换合路器

BTS中一个TRX故障系统自动重启后引起整个小区掉话

根据目前提供log,分析如下:

BTS68和BTS28 都是其中某一个非BCCH出现硬件告警7606: 7606 TRX FAULTY

mscbsc 移动通信论坛拥有30万通信专业人员,超过50万份GSM/3G等通信技术资料,是国内领先专注于通信技术和通信人生活的社区。3b5q&t&K-l\

www.mscbsc.com:m9D\D\Interface problems between O&M and DSP SW.02 01 01 97 00 00

www.mscbsc.com%b'H%v/|\

然后两个小区自动重起,出现7723 7730 告警,BCCH载频出现7606告警。

mscbsc 移动通信论坛拥有30万通信专业人员,超过50万份GSM/3G等通信技术资料,是国内领先专注于通信技术和通信人生活的社区。+l!M,B/F%mscbsc 移动通信论坛拥有30万通信专业人员,超过50万份GSM/3G等通信技术资料,是国内领先专注于通信技术和通信人生活的社区。*}.B\*y/H;t!`

7723 FAILURE IN SENDING SYSTEM INFORMATION TO BTS SITE 03 13028d 15973d7606 TRX FAULTY

TRX is stuck in waiting for system information state. 05 02 01 98 00 00

+@-s-z4u.R*j8P3DMSCBSC 移动通信论坛4E,B'? f&O M5`www.mscbsc.com2z1a\W

7730 CONFIGURATION OF BCF FAILED

2Q\2Y;c5u4V1E8x0g+~

所以到此说明基站自动重起后,BSC的系统信息不能重新配置到BTS,所以基站不能正常工作,造成大量掉话, 这时必须手动重起基站,掉话情况恢复正常。

,o!f*@2_:B(A$H)X移动通信通信工程师的家园通信人才求职招聘网络优化通信工程出差住宿通信企业黑名单!B4I#X1z%h#D5A

问题焦点:

一个TRX出现7606故障后,导致基站自动重启,重启后基站大量掉话,BTS伴有7745告警,但由于7745是一个统计告警,不能反映问题的严重性

导致用户大量投诉后才发现故障,对用户的影响也非常大。人工做基站重启后,掉话消失。

'h(^9

3.7 (7606)告警

告警的含义:在TRX中出现严重故障,此告警会闭锁TRX。该告警的补充信息字段指明故障位置及原因。

第 11 页 共 14 页

深圳市网信联动技术有限公司

说明:该告警补充信息(附加消息)字段: 第1字段:机架(机柜)编号 第2字段:支撑架编号 第3字段:插槽 第4字段:单元类型 第5字段:单元编号 第6字段:子单元编号

处理思路:载频故障,或是天线连接故障,通知维护人员检查硬件。

3.8 (7607)告警

告警的含义:在TRX中出现严重故障。该告警的补充信息字段指明故障位置及原因。

说明:该告警补充信息(附加消息)字段: 第1字段:机架(机柜)编号 第2字段:支撑架编号

第 12 页 共 14 页

深圳市网信联动技术有限公司

第3字段:插槽 第4字段:单元类型 第5字段:单元编号 第6字段:子单元编号

处理思路:载频故障,通知维护人员检查硬件。

3.9 (7744)告警

告警的含义:在监控时段内,TCH时隙在空闲模式下遭受的干扰太大,已经等于或超过定义的告警门限(BSC级参数HIFLVL)。也就是说,在时隙内的干扰的持续时间超出可接受的值。

说明:该告警补充信息(附加消息)字段:

第1~8字段:在监控时段,0~7时隙处于过分干扰状态的百分比。该值为十六进制,范围是0~64%。如果某个时隙不是TCH时隙,则对应的值为0。 第9 字段:遭受干扰的级别,范围是0~4。

第10 字段:TCH信道处于过度干扰状态的时间百分比。范围是1~100%。

处理思路:首先确定干扰范围,查看附近的基站有无干扰。如果发现附近的几个基站都出现干扰,干扰级别较高(3,4级),基本可以确定是外部干扰,需要带上干扰测试设备(安捷伦)去现场测试,找出干扰源。

如果只是某个频段出现干扰,比如同一小区使用低频点载频有干扰,而高频点载频没有干扰,则可能是附近的联通基站对我们产生干扰。也需要现场测试,如果确定是联通干扰,通知互联互通部门,与联通公司协调在其基站加装滤波器。

如果只有一个小区某个载频出现干扰,则可能是内部干扰。内部干扰产生的原因可能是载频故障,也可能是频点干扰。

第 13 页 共 14 页

深圳市网信联动技术有限公司

使用BB跳频或是无跳频的小区,将干扰载频的频点与无干扰载频的频点互换。如果干扰仍出现在同一载频上,则可以判断是载频故障,需要通知维护人员更换载频。否则,干扰出现在同一频点上,则是频点问题。需要通知频率规划人员,检查附近有无使用同邻频频点的小区,调整载频的频点来解决。

对于RF跳频的小区,如果出现某个载频干扰,则可判断是硬件问题,直接通知维护人员更换载频。

注:干扰告警的产生通常会伴随着大量的7745掉话告警,只要将解决问题解决,掉话告警自然也会随之消除。

4 总结

本文档目前只总结了常见的一部分BTS告警的结构解析及处理思路,有错误和不当之处,希望大家指正,互相探讨学习,不断完善相关内容。

技服事业部:张肖恒 2010-6-12

第 14 页 共 14 页

本文来源:https://www.bwwdw.com/article/umqh.html

Top