顺序错掉话处理案例.doc

“顺序错误”类型掉话解决案例
1、问题描述
在平常质差社区的持续性优化过程中，发既有绍兴孙端碧波庄园_1社区浮现TCH掉话次数较多，并且该社区的下行链路均无异常，分别在互换侧和BSC侧进行信令跟踪发现无任何异常，在平常问题解决过程中以及“顺序错误”类型掉话解决案例
1、问题描述
在平常质差社区的持续性优化过程中，发既有绍兴孙端碧波庄园_1社区浮现TCH掉话次数较多，并且该社区的下行链路均无异常，分别在互换侧和BSC侧进行信令跟踪发现无任何异常，在平常问题解决过程中以及DT测试或CQT测试中也遇到类似问题，相对棘手，对网络KPI指标以及客户感知度影响较大亟需解决。
2、问题分析与解决
观测该社区KPI记录值发现该社区在晚忙时浮现TCH掉话次数单时段在10到25次之间，其他时段话务量低时基本无掉话，并且掉话因素集中为M3100C:稳态下收到错误批示掉话次数（顺序错）（TCHF）（业务信道）。
检查社区的故障和告警信息，没有浮现异常，到基站实地检查主设备、天馈系统等，发现无任何故障级异常，排除硬件显性故障；对社区进行复位后掉话状况仍旧存在。
检查该社区浮现掉话时的上下行链路接受质量状况，基本在0级，现场DT测试该社区信号，下行链路质量0-1级，下行信号强度-60dbm左右，但是浮现下行链路N200超时掉话，于是怀疑因上行链路存在异常导致下行链路超时发生，决定尝试修改上下行链路呼喊控制有关参数。重要修改的参数有：SACCH复帧数从31到63、T200 FACCH/F从150到250、T200 FACCH/H从150到250、T200 SACCH TCH SAPI0从150到200、T200 SACCH TCH SAPI3从200到250、全速率呼喊上行DTX从应当使用到不能使用、全速率呼喊下行DTX从是到否。修改参数后，观测同步段相称话务量状况下的TCH掉话状况，单时段掉话次数基本控制在0-1次，并且M3100C：稳态下收到错误批示掉话次数（顺序错）（TCHF）（业务信道）的掉话次数为0.
通过参数修改后对指标的观测，发现该类掉话明显被控制，但还不能拟定具体何种参数对该类掉话影响较大，分别将参与调节的参数倒回判断，一方面将SACCH复帧数的值倒回，观测忙时掉话次数仍然为0；然后将T200系列呼喊控制计数器数值倒回，忙时掉话仍旧为0，接着将全速率呼喊下行DTX开关打开，掉话状况还为零；最后将全速率呼喊上行DTX开关打开，TCH掉话状况有所上升，忙时达到17次左右，来回关闭启动全速率呼喊上行DTX开关实验，拟定为影响顺序错掉话的重要参数。
拟定全速率呼喊上行DTX会影响TCH顺序错掉话，那么什么是“顺序错”掉话？在GSM网络中，无线Um口采用的是LAPDm的帧构造，其帧构造如下图：
地址1Byte
控制1Byte
0~21Byte
,`6F(L#U3N+
|  国内领先的通信技术论坛+O0J;x'{!h)_3O:B$i
SAPI
N（S）(3bit)!j-D1r(K3Y*V-T
N（R）(3bit)移动通信,通信工程师的家
信息
其中N（S）：发信机发送序列号；N（R）：接受机接受序列号
在收发双方