01 诺西掉话问题案例.doc

掉话问题
参数设置问题
前梁(20349)出现高掉话
在周一指标监控是发现前梁(20349)出现高掉话,但并未出现告警及干扰,且掉话几乎全部来自无线掉话,进一步分析发现该站是在周末扩容后开始出现高掉话情况,因此怀疑扩容造成该问题,但是通过对该站硬件检查后并未发现异常,而在数据分析时发现扩容后,该站话务量增长为平时的两倍, SD话务增长为平时的4倍,但切换尝试呈急剧下降趋势,,并且通过了解当地并无任何活动,综上考虑怀疑参数的设置方面有问题,经过检查发现该站的参数当前被置于极不合理的值上(如:RXP=-109db,RLT=0 等),怀疑该站参数被异常重置,建议对该站数据进行重建,问题得到解决。
Date
Cell ID
h Traffic BH
h traffic Avg
Tch available Avg
Tch traffic BH
HO attempt_1 Daily
MS Power in cell
distance
07_01
20349




25477
31
2055
07_02
20349




8595
32
2636
07_03
20349


41

1944
33
3328
07_04
20349




1797
33
3329
07_05
20349




2025
32
3378
PERIOD_STOP_TIME
NAME
CELL_ID
NW_NAME
DCN
TCH_RADIO_FAIL
8:00
LHBSC9
20349
QIANLIANG
103
1084
101
9:00
LHBSC9
20349
QIANLIANG
163
1633
151
10:00
LHBSC9
20349
QIANLIANG
185
1331
177
11:00
LHBSC9
20349
QIANLIANG
156
1078
150
12:00
LHBSC9
20349
QIANLIANG
112
1060
105
13:00
LHBSC9
20349
QIANLIANG
68
653
66
14:00
LHBSC9
20349
QIANLIANG
77
651
75
15:00
LHBSC9
20349
QIANLIANG
56
616
52
16:00
LHBSC9
20349
QIANLIANG
12
199
10
17:00
LHBSC9
20349
QIANLIANG
19
480
16
18:00
LHBSC9
20349
QIANLIANG
14
508
13
驻马店数据配置错误造成34209小区掉话
原因:参数
在监控时,发现34209小区17:00到18:00的掉话高达2963次,大部分掉话是由TRANSCODER引起的,如下表所示:并有大量2993告警产生。
PERIOD_START_TIME
NAME
CELL_ID
NW_NAME
DCN
TCH_RADIO_FAIL
TCH_TR_FAIL
12-Jul-05
ZMBSC10
34209
ZYLEIZHAI
2963
2742
0
2962
因检查天馈系统,值班人员将该基站删除,天馈检查完毕后又增加该基站,所以首先怀疑是基站数据配置有问题,查看基站数据:发现该小区的话音信道占用的是1、3、5、7时隙,而信令配置在26、27时隙(此时对应的话务信道时隙为17、19、21、23),造成了信令时隙和话务时隙不匹配,从而引起大量的TRANSCODER掉话。将基站数据重新配置后,基站恢复正常。下表为基站修改数据前后,掉话对比情况:
PERIOD_START_TIME
NAME
BTS_ID
CELL_ID
NW_NAME
DCN
TCH_TR_FAIL
12-Jul-05
ZMBSC10
58
34209
ZYLEIZHAI
2963
2962
13-Jul-05
ZMBSC10
5