第三方的设备的延时导致CES业持续误码问题分析

发布时间:  2012-09-03 浏览次数:  73 下载次数:  14
问题描述
 客户反映某站点BTS经常出现托管,某段时间在BSC上告警(见附件中  图1-1)
处理过程
1、 在该站点AQ_PCS_923查看告警,发现业务666在UNI侧有DOWN_E1_AIS告警,而另外一端业务并不是到PTN3900而是到AQ_PCS_903_16站点的,排查发现在该端口有UP_E1_AIS,因此怀疑是上游链路有问题导致的。当时经过排查初步判定:UP_E1_AIS和DOWN_E1_AIS时间能对应上,应该是903_16站点的接入侧2#1口输入了全‘1’导致,上游CE设备或中间链路有问题; DOWN_E1_AIS没有对应的UP_E1_AIS, 那么应该是在923网元网络侧有丢包,向接 入侧下插‘1’,从而产生告警。请分析下微波链路是否有中断?

2、经过排查,发现903_16站点的2#1口和2#2口是对接的。而由另外一条业务5108从903_16的2#2到PTN3900. 检查903_16的2#2口,这个端口根本上就没有UP_E1_AIS。这根本上就说不通为什么2#1口会有DOWN_E1_AIS告警。检查CES业务的性能发现有上下溢而没有丢包,却了解到当前版本丢包计数并没有用。因此有没有丢包无从得知。检查在基站掉线的时间点附近,没有发现有相关的其他告警。 此时问题分析没有新的思路,不管怎么样,把666和5108业务的30分钟历史性能打开,同时设置数量为50,这样就能够监控25h的性能情况。同时一线反映这个问题只有在特定的时间段容易出现,基本在当地的白天时间出现。
 
3、 过了24小时,从903_16的5108业务的历史性能中看有上下溢,上下溢的时间和2#1端口的UP_E1_AIS是吻合的。我认为是下溢导致2#1有UP_E1_AIS, 至于2#2为什么没有DOWN_E1_AIS是个奇怪的问题,后续由RTN研发跟踪。由于UP_E1_AIS持续时间有1~2分钟,怀疑下溢是丢包导致的。5108的业务并不是到组网图上的MSO1_LSR01,而是MSO1_LSR02,在3900上5108业务的历史性能没有任何计数,也就是没有问题。因此现在问题应该出在MS01_LSR02 à 903_16这个方向上。目前我们需要解决的就是这个方向CES业务为什么会有上下溢的问题。

4、整理了相关的组网图(见附件图2-2),得出如下结论:1) 5108业务的Tunnel OAM已经使能,发送周期为50ms。同时配置有APS保护,APS没有倒换。

5、倒换到保护链路后,BTS再没有掉线了!检查告警,在903_16站点没有UP_E1_AIS告警,但在923网元还有DOWN_E1_AIS告警,在两个站点检查历史性能,发现都有下溢,而且时间一致。 见下表。因此应该还是上下溢引起的923站点的告警。红色部分同时又上下溢。
根因
经过分析, 根因是因为客户的中间网络的有丢包或延时加大,需要客户去排查中间网络的第三方的设备的延时和告警
解决方案

1,规避方法,在有APS保护情况下,倒换到保护链路
2、解决方法,排查中间链路,排查并解决中间链路的时延问题。

建议与总结
1、问题发生时应该尽可能快的了解组网,并提供组网图。
2、可以使用APS来检测链路抖动或丢包。最小敏感度可以达到10ms。
3、对于CES业务误码问题,尽量早的使能30m/30s历史业务性能检测。并有目的性的做对比测试。


END