PTN和无线基站对告警抖动处理不一致导致现网语音业务产生流水声的故障分析

发布时间:  2012-10-30 浏览次数:  73 下载次数:  0
问题描述
软件版本:PTNV100R002C00
客户反馈在使用3G打电话的时候概率出现流水声问题,一般是用户在打电话的过程中声音突然变成了像流水的声音哗啦哗啦的,如果主叫和被叫都是3G的话会同时出现流水声,而且流水声就一直存在直到挂机。
(组网图见附件)











处理过程

最根本的原因是因为E商的微波链路不稳定导致了IMA组重启,然后ptn产生信元的突发,最后导致了无线加解密出错从而出现持续的流水声。
原因:E商的微波不稳定有LOF告警,导致PTN跟NODEB之间的IMA组重启,在IMA组成员逐个重启期间PTN有部分信元进入缓存中,在链路恢复正常后PTN把这些缓存的信元突发出去,导致无线加解密出错而出现了持续的流水声。该问题同时暴露了无线、PTN和传输3种设备产品对这种告警抖动的处理不够完善,在发生链路抖动的时候大都没有告警上报,也没有任何告警记录。最后是使用SDH分析器监控和PTN的串口监控才能确认根本的原因是链路的抖动。 





根因
最根本的原因是因为E商的微波链路不稳定导致了IMA组重启,然后ptn产生信元的突发,最后导致了无线加解密出错从而出现持续的流水声。
解决方案

1、 首先确认端到端配置是否一致。
首先无线根据抓取到的log分析并给出了结论: 当发生流水声的时候,无线发现下行时延抖动很大,所以NodeB会发一个时间调整给RNC,当CFN调整大于一个CNF周期(2.56s),RNC 和UE之间的HFN维护不一致,最终导致了流水声的产生。
然后围绕这个时延抖动的结论, 在PTN两侧配置了1条CES业务进行时延测试,挂接了24小时没有误码,时延在30ms左右符合要求。期间发现PTN的QOS配置不合理,现场所有的业务都配置成UBR业务,而且一个基站上所有的业务都汇聚到一个业务上。通过分析,该配置在业务不拥塞的时候不会额外增加时延,仅在网络侧拥塞的时候会引入3-5ms的时延,所以确认此配置不是引起时延抖动的原因。为了清除这个隐患,我们先修改这个PTN的流量策略,结果第二天测试队伍仍然能测试到流水声。
2、 在没有其他怀疑点的情况下我们通过仪表一段一段的测试排查。首先是排查RNC的可能性,使用湾流仪表在RNC出口侧挂上仪表测试,结果表明在发生流水声的时候RNC侧出来的报文还是保持在20ms的时间间隔。
3、 继续挂接湾流仪表测试是否NodeB本身引起时延抖动。把仪表放在进入NodeB之前, 结果表明当发生流水声的时候在报文进入NodeB之前已经产生了时延。(测试结果见附件)
4、 通过了上面的测试排除了RNC和NodeB的可能性,那么这个时延只能是在中间网络引入的。同样的测试方法把湾流表挂在PTN1900的出口(与NodeB对接的出口),同时直接连上网元打开串口监控一些告警。
在测试点3和5这个地方我们发现如下问题:
1)、 当发生流水声的时候PTN侧监控到该基站的IMA组发生了抖动。
PTN tracing data at Feb 13 (12:49)
CDrvLlpSysAL::SysEventCallback[eventType = 0x00000207] - Not handle.
//此调试命令执行的结果表明告警有抖动
2)、结合在测试点5的地方SDH分析仪的数据,我们得到的结论是由于链路有LOF告警导致IMA组抖动的。
PTN在12:49发生过一次抖动,同时对应SDH仪表上也有一个LOF告警,而在2月13号的测试中我们发现有13次这样的抖动,PTN同时也因为物理链路的抖动而导致链路的抖动发生了13次,每次抖动的时间跟SDH仪表是一致的。
解决方案:PTN需要清除IMA组重启期间缓存的信元; 无线修改加解密算法的完整性。 





建议与总结
这个问题是我司PTN、无线产品和E商产品之间配合的问题,充分暴漏了各个产品之间对抖动的处理不够完善。因此在处理各种产品对接的问题的时候,首先要弄清楚各种产品对某个特性的处理是否一致,然后逐个分析,找到原因。



END