各项KPI指标处理思路结合告警处理 联系客服

发布时间 : 星期六 文章各项KPI指标处理思路结合告警处理更新完毕开始阅读462b9f0503d8ce2f006623af

8、 9、 10、

突发干扰导致的高SDCCH掉话请参考Abis掉话中的干扰处理过程。 屏蔽小区的SDCCH高掉话不做处理。

如果仍未恢复,可稍降基站功率,将SDCCH掉话次数降低,避免影响网络性能,并发维护工单至基站维护中心,及时修故故障。

11、 是否近期该地区或该小区有影响SD话务的试验。如有,与试验负责人沟通,权衡是否恢复参数等。

1.3.4 TCH高掉话

【观测手段】

话务网管统计表——NPMDB_V_P_严重问题小区监控表,见GSM性能指标。

【建议措施】

一般常见原因:

1. 高于100次的掉话常见由于强干扰或严重的硬件故障,查看是否有大量7744、7745等告警(ZEOL/ZERO)

2. 同时可以通过对比SDCCH和TCH的掉话率判断是各种故障导致还是人为因素导致,

当SDCCH和TCH掉话率具有相同的变化规律时,大致可认为是非人为因素导致,而如果SDCCH掉话率没有明显变化,TCH掉话率异常,则基本是由于人为因素导致,与无线网络无关。

3. 对于暂时无法修复的故障,可暂时降功率缓解,但调整功率的幅度要兼顾客户感知,

对于人为因素,可以先记录在案,待现场重要事件结束后进行分析处理。 4. 可能造成掉话的重要参数:MO/MS(主从bts)、RXP、PLMN、BAR、RLT、PMAX1/PMAX2(SEG)。 ? 掉话处理流程:

? TR掉话高

TR掉话高可通过以下方式处理:

? 如有告警2992或2993重起载频通常无效。使用如下命令查看ZAHP::NR=2993:;

ZAHP::NR=2992:;来查看是哪些站或BSC TC出现这种问题。

2993告警:一般为单个基站故障。通常伴随7745告警。

BSC132 MCMU-1 TRANSM 2005-04-26 14:08:50.97

** ALARM ........ RRM_BX

(0416) 2993 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON ABIS INTERFACE

90d 10d 06 135d 20d 4d

其中红色的90代表BTS号码,黄色的10代表载频号码,紫色的6代表时隙。 找到出问题的站后可以进行相关的操作。

? ? ?

考虑重起该载频 考虑关闭该载频 考虑关闭该时隙

同时检查trx数据是否正确,如果因工程、割接等造成trx数据时隙做错,重起是无效的。判断是BTS现场还是BSCtrx数据时隙做错,重做trx数据纠正。

? 出现2992告警时一般为BSC TC故障,现象是BSC多个BTS出现少量TR掉话,分布比

较均匀。当BSC反复出现此告警时,可以确定是BSC TC板故障,需要及时通知网优值班经理、网运集中监控中心(小号73121~73126)进行处理,并跟踪后续时段

性能。极特殊情况时,也可能不触发2992或2993,但bsc多个站有少量TR掉话,请网运集中监控中心加强监控,找到故障所在。必要时请网运技术支援中心专家协查13901112000。

2992告警:一般为BSC TC故障,现象是BSC多个BTS出现少量TR掉话,不像2993告警,单个BTS大量TR掉话。

BSC132 MCMU-1 TRANSM 2005-04-26 14:08:50.97

** ALARM ........ RRM_BX

(0416) 2992 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON A INTERFACE

12 34 56 78 90 AB CD EF GH IJ

? 通过调节BSC参数ITCF,可以对TR掉话有所缓解,建议设为最大值5。(不建议随意

调整)

? LAPD掉话高

LAPD掉话高可通过以下方式处理:

(1) 用指令ZEOL:BCF号;或ZEOH:日期时间,BCF=*;查看告警确定是否为载频退服导致,并查看相关原因,如需要更换载频或做基站硬件处理,与网优基站维护工程师合作处理。

(2) (3)

ZYMO指令查看是否存在传输误码导致传输闪断。 确定基站是否出现过断电原因造成的退服。

? A口掉话高

A口掉话可通过以下方式处理:

1、 如果A口掉话均匀分布在BSC内所有小区上,A口电路存在故障,向网运集中监控中心(小号73121~73126)反映解决。

2、 A口掉话一般都是由于跨MSC的切换引起,可检查相关切换指标和切换参数以及目标小区的工作是否正常。

? BTS以及OTHER掉话高

1、BTS掉话一般在基站告警上有所体现,基本由于基站硬件故障导致,需要与网优基站维护工程师沟通解决。

2、USER掉话由于重起基站导致,不做处理。用用指令ZEOH查看是否有人重起触发告警7710 OBJECT ADMINISTRATIVE STATE CHANGED。

? Abis掉话高

Abis掉话高可通过以下方式处理:

1、 用指令ZEOL或ZEOH,查看告警是否相关载频存在7745告警,可通过重起载频观察。如重起载频后,7745高告警仍然存在,仍然存在高掉话,可尝试锁住载频观察掉话情况,在确定由于某载频故障导致ABIS高掉话后,向网优基站维护工程师发送工单要求更换。

如朝阳二堡子DCS1(ULTRASITE)案例:相关告警,历史告警7745频繁。 BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 15:21:20.63

** ALARM TRX -008 DCYERPUZI1

(17477) 7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 02 01 00 00 00 00 00 00 00 00 00 100d

BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 15:21:20.63

** ALARM TRX -008 DCYERPUZI1

(17476) 7745 CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD 01 00 01 01 01 01 01 01 01 03 02 100d

BSC194 BCF-0101 BTS-0101 QUAL 2008-07-20 12:20:54.56

** ALARM TRX -008 DCYERPUZI1

(17445) 7743 MEAN HOLDING TIME BELOW DEFINED THRESHOLD 00 01 01 01 01 01 01 01 02 02 1d

重起TRX8后出现下面告警,且7606频繁出现:为防止trx自己频繁重起造成掉话,暂关闭TRX8,需要基站维护工程师现场检查。

BSC194 BCF-0101 BTS-0101 PROCES 2008-07-20 16:48:16.43

** ALARM TRX -008 DCYERPUZI1

(17504) 7606 TRX FAULTY Interface problems between O&M and DSP SW. 02 01 04 97 00 00

2、 结合trx质量统计查看每个TRX上分步的掉话情况。如单TRX比小区内其他trx明显掉话次数高,也说明该TRX有故障。如重起无效,需要基站维护工程师现场检查。

3、 4、

检查小区本站或它与临近站是否存在严重的同邻频干扰问题。

BSC指令ZERO查看是否小区TCH信道存在严重上行干扰,干扰处理参考如下:“RF

掉话”中干扰排查过程。

备注:由于7745告警原因重起载频时,有时重起BTS和重起载频效果不一样,可能重起BTS不能恢复,但重起载频却恢复正常,如果小区开有BB或RF跳频,也建议在锁住BTS后,对问题载频进行一次解锁操作后,再解锁BTS。 ? RF掉话高

RF掉话高常规处理方式请参考如下建议: