1. 概 述 告警信息可以反映网络设备的运行状况,记录了网络运行过程中产生过的故障或影响设备运行的信息,通过对网内告警数据的分析,可以了解网络的运行状况。大家将对一些影响网络运行指标的重要告警进行分析,并分析影响此类告警的主要原因及相关的解决方案。 2. 主要历史告警数据分析2.1 告警分类情况为了对现网的告警进行分析大家对告警进行了分类汇总,南昌移动全网的BTS告警信息分为基站告警(7000~7999)和传输故障告警(8000~8999),这两种告警直接反映了网络的运行状况,对网络指标和客户感知度的影响都非常大。具体告警数量统计情况如下: | | | | | | | | 合路器反射功率高告警,可通过测试驻波,更换合路器解决 | | | | | | | | | | | | | | LOSS OF INCOMING 2M SIGNAL | | | | | | 帧定位丢失,上站检查2M,时钟同步、传输单元、传输侧接收与发射,可解决 | | | | LOSS OF CRC MULTIFRAME ALIGNMENT | CRC复帧定位丢失,上站检查传输侧接收与发射、时钟同步,可解决 | | | | RECEIVED BIT ERROR RATIO (BER) > 1E-3 | 接收比特误码率> 1E-3,上站检查传输侧接收与发射、时钟同步,可解决 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TRAFFIC CHANNEL ACTIVATION FAILURE | | | | | CONFIGURATION OF BCF FAILED | BCF配置失败,上站处理后可解决(DAP数据不一致) | | | | BCCH IS NOT AT PREFERRED BCCH TRX | | | | | | | | | | INCONSISTENT DATA IN RADIO RESOURCE MANAGEMENT STATE FILES | 无线资源管理状态文件中有冲突数据,需上站处理后可解决 (重启,实在不行做本调) | | | | | | | | | MEAN HOLDING TIME ABOVE DEFINED THRESHOLD | 信道未使用但同时未被释放,重启载频或更换问题载频可解决 | | | | MEAN HOLDING TIME BELOW DEFINED THRESHOLD | 话务信道平均占用时长低于门限,可能频点、干扰、TRX、RTC、馈线问题,可解决 | | | | EXCESSIVE TCH INTERFERENCE | | | | | CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD | TCH和SDCCH信道掉话率高于门限,可能频点、干扰、TRX、RTC、馈线问题,可解决 | | | | CH CONGESTION IN CELL ABOVE DEFINED THRESHOLD | | | | | ALARM INDICATION SIGNAL (AIS) RECEIVED | 传输告警,一般是传输设备或线路故障或设备的环路激活(即传输线路环着)需配合解决 | | | | RECEIVED BIT ERROR RATIO (BER) > 1E-6 | | | | | | 2M丢失或AIS 2M或帧定位丢失或BER> 1E-3,需配合解决 | | | | | 串传输时,存在冗余数据未删除,删除传输侧冗余数据,告警消除,可解决 | | | | | | | | | | 告警重复出现次数导致门限值后产生的告警,可部分解决 | |
2.2 现网告警数多的相关告警l 7601、7604、7607:其中包含风扇告警、上下行不平衡告警、驻波告警等等,风扇告警需维护部分上站逐个处理,由于室分设备从基站出来只接主集而未接分集故导致上下行不平衡告警。该告警需与室分配合起来协调解决。(室分:把分集功能关掉,或者在基站侧把分集连上) l 7704:7704告警数现网中有大量基站处于闭锁状态且传输处于中断状态故出现此类告警,建议删除长期闭锁基站,可消除告警。 l 7725:信道激活失败产生的告警,此类告警的产生必将导致出现此类告警的载频无法提供数据业务,数据业务监控组在处理休眠小区时可发现此类告警的存在,可通过倒换PCU解决。 7738:7 2.3 现网主要告警分析及处理建议下面将对现网告警中所占比例大、对网络运行指标影响严重的重要告警进行分析,并分析影响此类告警的主要原因及提出相关的解决方案。 2.3.1 7738告警分析及处理建议7738(BTS WITH NO TRANSACTIONS) 此告警的含义为:在监控时段,BTS没有成功终止的呼叫或者SDCCH的事物。告警用来监控BTS话务容量。出现7738告警的小区话务量减少甚至没有,需要关注。 对现网7738告警进行分析: 1、绝大部分为室分小区,对于此类小区需室分配合处理 2、对于无话务或话务低的宏站首先进行功控参数的检查并且找出BTS无话务的原因(基站地理位置,天线倾角,板件故障,基站严重告警),如果这些情况都正常则建议对这些小区进行重启看看这些小区能否恢复话务占用,最后检查其BCSU板是否有故障并进行更换 2.3.2 7743告警分析及处理建议7743(MEAN HOLDING TIME BELOW DEFINED THRESHOLD) 此告警的含义为:在测量时段内,在信道上的平均占用时间低于定义的门限值(BSC参数MINHTT)。该告警用来监控话务信道的功能,并检测可能出故障的信道。 7743是基站常见的告警之一,如果小区反复出现该告警会影响到指标中的SD和TCH掉话率。 2.3.3 7744告警分析及处理建议7744(EXCESSIVE TCH INTERFERENCE) 此告警的含义为:在监控时段内,TCH时隙在空闲模式下遭受的干扰太大,已经等于或超过定义的告警门限(BSC级参数HIFLVL)。也就是说,在时隙内的干扰的持续时间超出可接受的值。 7744干扰告警常见处理手段:首先确定干扰范围,查看附近的基站有无干扰。如果发现附近的几个基站都出现干扰,干扰级别较高(3、4级),基本可以确定是外部干扰,需要带上干扰测试设备(安捷伦)去现场测试,找出干扰源。 如果只是某个频段出现干扰,比如同一小区使用低频点载频有干扰,而高频点载频没有干扰,则可能是附近的联通基站对大家产生干扰。也需要现场测试,如果确定是联通干扰,通知互联互通部门,与联通企业协调在其基站加装滤波器。 如果只有一个小区某个载频出现干扰,则可能是内部干扰。内部干扰产生的原因可能是载频故障,也可能是频点干扰。 使用BB跳频或是无跳频的小区,将干扰载频的频点与无干扰载频的频点互换。如果干扰仍出现在同一载频上,则可以判断是载频故障,需要通知维护人员更换载频。否则,干扰出现在同一频点上,则是频点问题。需要通知频率规划人员,检查附近有无使用同邻频频点的小区,调整载频的频点来解决。 2.3.4 7745告警分析及处理建议7745(CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD) 此告警的含义为:在一个信道中,呼叫因失败而终止的比例超出了门限值(BSC级参数TCHFR和SCHFR)。该告警用来监控话务和信令信道的功能,并检测可能出故障的信道。 7745也是基站常见的告警之一,本次采集的现网告警数为54条 ,其中TCH高掉话小区占大多数。 7745告警常见处理手段:出现掉话告警时,先查看是否伴随有其它的告警,比如7744干扰、或是其它硬件故障告警。如果7745告警同时伴随有其它告警,则先解决相关的告警,一般情况下,相关的告警消除后,7745告警也会自动消除。 如果无其它告警,则可判断是载频出现故障,可以先试着重启载频,如果重启后告警依然存在,需要通知维护人员更换硬件。 2.3.5 7746告警分析及处理建议7746(CH CONGESTION IN CELL ABOVE DEFINED THRESHOLD) 此告警的含义为:基站中由于拥塞被拒绝信道占用的请求与所有信道请求之间的比例超出定义的告警门限(BSC级参数CNGS和CNGT)。该告警用来监控基站的话务量。 处理7746告警原则是首先判断该告警是否是由于载频故障所引起的,如果是,先对故障载频进行处理;如果一些小区的载频全部可用并且话务量确实很高而导致拥塞的情况下则建议对这些小区进行扩容。2.3.6 7730告警分析及其处理建议 7730(CONFIGURATION OF BCF FAILED) 此告警通常是由于硬件或者App配置错误导致,根据附加信息查找故障.。出现该告警BCF无法正常工作。处理此告警应该将现网数据与基站端数据进行核对,EDAP SIZE不一致引起的该告警,可以通过修改EDAP SIZE使基站端与现网SIZE一致,清除此告警。开启EGNEA能能小区,并且没有辅BTS,开启GTRX功能载频没有绑定DAP引起的该告警,可以通过关闭GTRX功能,或是将该载频绑定DAP (基站端也需做相应数据改变) 2.3.7 7725告警分析及其处理建议7725(TRAFFIC CHANNEL ACTIVATION FAILURE) 此告警的含义为:呼叫控制在启动时失败了多次,系统将无限时隙锁闭,即信道激活失败,0代表TCH,1代表SDCCH,2代表PDTCH。 此告警一般可以依次,开关GENA或倒换PCU来解决。 2.3.8 7735告警分析及其处理建议7735(TRX TEST FAILED) 此告警的含义是载频测试失败,此告警单独存在时可以通过重启载频,BTS 或BCF来解决,若同时存在载频故障告警,则通过更换载频来解决 2.3.9传输告警分析及处理建议传输故障告警(8000~8999) BTS告警中8000~8999的全部为传输故障告警,产生传输告警的原因主要是传输设备故障,传输信号的高误码也可以引起传输告警。现网中传输告警可以直接影响网络的多种考核指标和客户感知度并且传输告警还会引起一些基站告警出现,对网络的干扰很大。本次提取的历史告警统计中传输告警共有35条,占全部告警总数的2.39%。在8月30日所提取的现网告警中还存在35条传输告警。处理传输告警只能在现网监控的基础上及时发现及时处理,所以需要网维部门加大力度保障及时处理才能避免传输告警对网络的影响。 2.3.10 8050告警分析及其处理方法8050(LOSS OF INCOMING 2M SIGNAL) 此告警含义为:2M信息丢失,传输故障或打开了为使用的传输端口 此告警处理方法为:通过远程登录或通过直连BTS检查告警信息中所在端口,是否存在使用中的数据,若无可以通过关闭该端口清楚此告警,若有数据则检查2M线接头,或是传输板是否存在故障,另外伴随此告警的清除,会出现8020告警,是因为做了时隙分配,但没有使用时隙分配的BANK,删除没用的数据可解决。 2.3.11 8102告警分析及其处理方法8102(RECEIVED BIT ERROR RATIO (BER) > 1E-6) 此告警的含义为:传输误码高,该告警会影响到指标中的上下行话音质量,SD掉话率,TCH掉话率。 此告警的处理方法为:若近端误码高则检查2M线接头,重做2M线接头,检查传输走线是否存在问题,远端误码则转向传输请求协助。
|