調整RB重配置相应定时器解决PS掉话问题.docVIP

案例：调整RB重配置相应定时器解决PS掉话问题案例 问题简述 近期抚州RNC3034一些双载波站点PS掉线率持续较高，从话统中统计出的PS掉话原因均为NoReply，并且无任何告警信息。 发生时间和地点 发生时间：2012年9月 发生地点：临川区。 原因分析 分析TOP小区中的PS掉话，并没有发现个别异常终端引起的掉话，IMSI分布比较平均，但也有个别IMSI经常出现。因此针对经常出现的IMSI进行信令跟踪。 目前网络中的双载频站点中的F1打开了FACH功能，并且支持D2F功能。 分析信令，并分类统计失败原因发现，主要集中在RNC收到了RRC_CELL_UPDATE消息，但迟迟没能回复RRC_CELL_UPDATE_CONFIRM消息，导致UE无法完成RB RECFG流程，直至H2F状态迁移超时掉话。 分析此种现象产生掉话的原因 首先要明确H2F过程中的RB重配流程：目前华为设备的状态迁移的RB重配流程是这样实现的： ① 下发RB RECFG消息（会每隔2秒下发一条，一共连发3条）； ② 在RB重配超时前，RNC会等待UE回复RB RECFG CMP消息。RB重配等待时间计算方法如下： RB重配等待时间=RB RECFG消息的发送间隔时间+等待RB重配置失败响应定时器时长 =2s + 2s + RBRECFGRSPTMR时长 （目前的RB重配等待时间是2s+2s+5s=9s） ③ 如果在RB重配超时前，RNC收到了RB RECFG CMP消息，则继续执行后续流程；如果直到RB重配超时时，RNC仍未收到RB RECFG CMP消息，RNC就会执行状态回退（例如，在H2F状态迁移时，若RNC未能在RB重配超时前收到RB RECFG CMP消息，它就会将状态回退到DCH态），不再等待状态迁移的响应。此后如果RNC与UE再有信令或数据交互，就会因为双方状态不一致而出现数据解析错误，而导致后续流程失败，并最终导致掉话。 分析掉话前的信令 其特点是：RNC总是在RB重配流程已经超时（9秒）后才收到UE上报的CELL UPDATE消息（此时，RNC回退到DCH态，而UE已经迁移到FACH态）。如前所述，此时，双方状态已经不一致，所以后续流程无法正常进行，最终掉话 解决方案 建议RNC3034修改RB重配置相应定时器从5s到10s，并且这个措施并不会如想象中那样影响用户感受的，因为既然发生了H2F状态迁移说明用户已经没数传了，RB重配等待时间稍长，用户也不会明显感觉得到。而且，在DCH态的时候，如果因为覆盖原因导致RB重配流程一直在等待超时，那其他流程（如SRB复位）也会先行发生触发掉话，不会让用户一直处于无效等待中。 该参数为RNC级参数，具体命令如下： SET USTATETIMER:RBRECFGRSPTMR=10000; 效果验证 RNC3034的RB重配置定时器改为10S后指标提升明显，下面是参数修改前后PS掉线率趋势图。 经验总结 RB重配置定时器修改，并不会如想象中那样影响用户感受的，因为既然发生了H2F状态迁移说明用户已经没数传了，RB重配等待时间稍长，用户也不会明显感觉得到。而且，在DCH态的时候，如果因为覆盖原因导致RB重配流程一直在等待超时，那其他流程（如SRB复位）也会先行发生触发掉话，不会让用户一直处于无效等待中。