7745告警浅谈.doc

7745告警浅谈 一: 引言 运营商一直追求的目标“追求客户满意度”，随着2G网络的资金投入，GSM网络已基本达到全面覆盖。客户的感知度也有所改变，不在是考虑可否使用，而在意网络质量。在3G技术即将到来的时候，2G网络必然受到冲击，在和其他运营商竞争的时候，除了优惠的资费，良好的网络也会吸引客户的眼球。而7745告警就是反映出网络的弊端，必须及时有效的解决。 二: 告警解释 7745告警我们查阅资料，字面解释显示为： CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 告警的含义：在一个信道中，呼叫因失败而终止的比率超出了操作员设置的门限值。该告警用来监控话务和信令信道的功能，并检测可能出故障的信道。 首先要看告警的补充信息 1 表示告警是涉及TCH信道还是涉及SDCCH信道 01: TCH 02: SDCCH 2 表示信道故障率是否高于时隙n(n=0、1、2..7)中定义的门限 00: 低于门限值（无告警） 01: 高于门限值（告警） 3 故障率最高的时隙 4 子信道标识TCH: 00: TCH/H – 子信道0 01: TCH/H – 子信道1 子信道标识SDCCH 00 – 07: SDCCH – 子信道0 – 7 5 指定信道中，测量期间因故障造成的TCH或SDCCH子信道释放占全部信道的比例。 此告警是由BSC管理员在MML中用EEO设置的无线网络监督参数的值，默认值为TCH故障率大于20%，或SDCCH大于80%时出现此告警。取样时长为一小时。出现此告警大部分原因都是有TCH故障率大于20%引起的。 用MML命令中的ERS锁定然后再解锁这个方法基本上是没用的。 三: 案例 1:民权林场为NOKIA DE34基站，此基站为O（3）站。此站TRX2出现7745告警，此基站的MBCCH在TRX1上，让BSC把MBCCH换到TRX3上，在赶到基站时让网优提取报告，TRX2告警依然为7745，把TRX1与TRX2硬件位置更换了一下，就赶往下一个站。一小时后再次让网优提取报告，发现此时TRX1掉话较高。可以确定现在TRX1所在位置的载频坏掉。 2: 柘城大仵乡是一ULTRASITE基站（3/3/3）TRX11出现7745告警，在更换TSGB、DVGA和 WCGA均无效，最后仔细检查发现TSGB和 WCGA之间的电缆线连错（扩容造成），这个乃低级错误，处理告警时一定要细心，不能经验主义。 3: 柘城慈圣为NOKIA DE34基站，第三扇区有3个TRXA,在更换TRXA和AFEA均无效，然后把TRX3位置移至TRX4后依然不行，然后检查所有连线也都没有问题，然后测量天线驻波比也没有问题，此时怀疑为2、3层母板之间的BUS线有问题，更换BUS线后，超过取样时间观察告警依然存在，最后倒换主分集接收天线，告警出现在1、2载频上，原来分集天线是坏的。此告警原因较多，处理时一定要有耐心。 四：基站维护人员 基站维护人员判断7745的告警是某一TRX的告警还是多个TRX的告警。首先对整扇区的TRX都有7745告警的小区进行处理，然后对其它小区进行处理。对于此类告警，一次现场处理一般不能彻底解决问题，需要有观察等待的时间，所以每次现场的停留时间最多不超过两个小时，可以多个基站并行处理。 此告警出现在DE34基站中较多，由于此站型使用的时间长，各种板件都有不同程度的老化。所以一定要做好预防性维护工作。ULTRASITE基站中出现7745告警多为载频原因，基带单元BB2X也是主要故障点。 高掉话的原因很多，偶发恶劣天气，地形地貌，天线性能，此现象反映出的告警多为7745。所以处理7745告警时要从多方面入手，不能总是凭经验处理。经验只是指引我们少走弯路，不是一劳永逸。