OSN3500为何SNCP正常误码倒换了BIP_SD告警仍上报了36秒钟

问题描述

A－B－C－A三个OSN7500设备组10G速率SNCP环，主环方向为A－>B－>C，其中A通过无保护链下带A'，C通过无保护链下带C'，A'、C'都是OSN3500设备，所有网元的主机版本为5.**.18.50P01，某日B收A方向光路衰减突变，导致B收A方向光板闪报了6秒钟的B3_SD告警，从网管的异常事件中看C站点同时也发生了SNCP误码倒换，但C'网元支路板却上报了35～37秒的BIP_SD告警，同时用户交换侧也反馈业务也出现了几秒钟的中断。

告警信息

B3_SD、BIP_SD

处理过程

1、检查C站点SNCP属性设置，都已经打开了SD误码倒换，排除SD倒换开关未设造成业务中断；

2、检查网管异常事件，用户反馈有中断的业务当时都已经发生了SNCP误码倒换，当前所有业务都工作在SNCP备用通道上，排除SNCP监测点异常；

3、查询误码的检测原理，发现VC12级别业务的SD检测条件是“在40S的滑动窗口内，平均误码率超过10-6才上报BIP_SD告警”，而SD告警的消失条件为“在40S的滑动窗口内，平均误码率小于10-7 SD告警结束”，VC4级别业务的SD检测条件与2M业务类似，只是滑动窗口为10S；

4、我们假定一条2M业务出现10－5误码率，那从误码开始出现到上报SD告警，中间需要4S时间（因为只有至少持续4S，除以40S后才能不低于10-6），而当业务出现10-5的误码率时，是很可能造成业务中断的；如果要求从误码出现的100MS内上报SD告警，则要求这100MS内的平均误码率不低于4*10-4；

5、40秒内平均误码率的计算公式=(40S内总误码数量)/（40S内传送的总BIT数量），误码数量与性能中统计的误码个数相同（因为采用BIP2误码校验，实际误码数量很可能比性能中统计的误码数量更大），40S内总BIT数量=40（时间）×8000（1秒8000帧）×35（一个VC12 35个字节）×8（一个字节8bit）=89600000， 如果要达到SD的条件，89600000×10-6约等于90，也就是40S内超过90个误码才会达到BIPSD条件；同理40S内低于9个误码SD告警才会消失；

6、通过调节可调光衰进行实验验证，发现在不同的调节方法下,在实际误码消失后，SD告警的持续时间有长有短，一般在出现误码后慢慢降低可调光衰的衰减，在误码消失后SD告警的持续时间比较短，在出现误码后迅速降低可调光衰的衰减，SD告警的持续时间就比较长，最长时间可在误码消失后仍持续40S，实验结果与理论推断一致；

7、由于现场故障只出现了一次，且不具备再次测试的条件，我们无法判断现场到底是误码出现多长时间后才上报了SD告警并触发SNCP倒换，也无法判断故障发生时的误码率到底是多少，但从当时上报了SD告警并发生了sncp误码倒换判断，SNCP倒换是正常的。但从上面的理论中可以确认，对于误码倒换，是无法保证不中端业务的，除非对接设备能给出更宽的保证业务不中端的范围，比如交换机保证“在45S的滑动窗口内，平均误码率超过10-6才中断业务”，目前看对接设备不能保证上面的条件；

8、既然如此，为何不把SD的检测窗口缩短，比如缩短到1S，当然这样设置是能更快的触发倒换，但如果检测周期只有一秒，根据上面的计算公式，当1S内大于等于3个误码时，就会触发SD倒换，这样可能造成频繁的倒换，另外缩短检测周期对设备的硬件性能要求也更高，硬件未必能够承受。

根因

VC12级别业务的SD检测条件是“在40S的滑动窗口内，平均误码率超过10-6才上报BIP_SD告警”，而SD告警的消失条件为“在40S的滑动窗口内，平均误码率小于10-7 SD告警结束”，VC4/MS/RS级别业务的SD检测条件与2M业务类似，只是滑动窗口为10S。

不同门限、不同级别业务的滑动窗口周期如下：

检测器门限 STM-N/VC-4-Xc/VC-4/VC-3级别业务  VC-2VC-12/VC-11级别业务

10-3 10 ms 40 ms

10-4 100 ms 400 ms

10-5 1 s 4 s

10-6 10 s 40 s

10-7 100 s 400 s

10-8 1000 s 4000 s

10-9 10000 s 

建议与总结

误码倒换是不能完全保证不中端业务的，即便我们将SD门限设置成10-7，但检测周期同时被拉长到了400S，需要在400S内平均误码率超过10-7才上报SD告警，但如果误码集中在某个时间段，还是可能造成实际业务已中断、但传输设备还未达到倒换的门限，所以不要随意向用户承诺传输设备可以保证误码倒换不中端业务；如果用户非要承诺，至少也要对接先给出类似承诺：“在40S的滑动窗口内，如果平均误码率不超过10-6不会中断业务”。