Metro5000 SSA1EGT2单板MSP倒换业务中断

问题描述

2007年1月30日上午9：22分XX站点＃126网元(OptiX 10GV2设备)的9号SSA1EGT2单板出现了FCS_ERR告警不停上报的现象，并且业务中断不能恢复，直到下午1点15分现场工程师启停了一下LCAS协议，故障才消失

处理过程

1．现场出现故障以后，研发人员在现场工程师的帮助下取得了现场数据，主要包括

现场的组网配置MO数据，现场网管操作日志，现场的历史告警和性能信息以及LCAS协议组件协商信息。从现场信息分析结果如下：

（1）将现场MO数据导入到网管，分析数据发现现场在出现FCS_ERR告警上报业务中断之前＃126网元线路板发生过MSP保护倒换，当保换倒换恢复的时候出现了FCS_ERR告警不停上报的现象

(2)从现场返回的历史告警以及性能数据可以看出，当保护倒换恢复的时候现场有大量误码

(3) 从现场返回的LCAS协议组件的协商信息来看，没有发现异常情况，上层软件协商正常

2．从现场返回的数据有两个突破口，一个是发生的MSP保护倒换引起发业务中断，还有一个突破口就是现场出现的FCS_ERR告警，试验室针对两者都进行了系统的测试

（1）首先是测试MSP保护倒换和LCAS 配合问题，按照现场组网在实验室搭建环境进行测试，通过反复的MSP保换倒换测试，发现在光功率比较低有误码的情况下会产生FCS_ERR告警，但是和现场数据比对发现现场在发生MSP保护倒换以及恢复的时间断有误码，但是保换倒换恢复以后的10点后就没有误码了，这个就和试验室模拟的一直有误码才会上报FCS_ERR告警的情况不符合，因此直接进行倒换测试没有能够成功重现问题

（2） 在实验室直接进行MSP倒换测试不能重现问题的情况下，召集数据专家一起讨论出另

一条思路，就是从现场返回的FCS_ERR告警入手，分析现场条件什么可能造成FCS_ERR告警，于是进行了根据FCS_ERR告警的针对性模拟测试：

通过测试软件多次的模拟测试，发现进行模拟现场误码产生SQ出错的时候出现了和现场完全一致的告警上报情况，如下：

并且发现，如果SQ受到误码影响产生一定的变化规律的话，就会出现误码消失以后业务一直不恢复的情况，并伴随有不停的FCS_ERR告警上报，并且只能通过重新启停LCAS协议才能使业务恢复正常。反复测试终于找出SQ变化规律为：

1） 由于误码影响使得一端EGT2单板接收的SQ为大于或者等于0x3f的值

2） 当保护倒换恢复的时候该单板又由于误码影响使得个别时隙的SQ号出现了错位

3） 当误码消失后，虽然能够正常接收到正确的SQ号，但是此时业务已经不能恢复，并伴随有FCS_ERR告警

整个SQ变化过程中对应的现象为：数据单板性能统计有过误码，单板出现FCS_ERR告警不停上报, 业务中断不恢复，重新启停LCAS协议业务恢复告警消失。

根因

验室模拟故障的时候采用的操作步骤如下：

1）对1、2号时隙下发大小为0x3f的SQ后，业务中断(相当于现场误码导致全1)

2）将1、2号时隙的SQ号交换下发以后，业务仍然中断（相当于误码导致SQ错位）

3）下发正确的SQ号以后，业务仍然中断（相当于误码消失,SQ恢复正常）

4）启停LCAS协议后，业务恢复

现在针对每一步操作以及现场分析如下：

1）现场由于误码导致了SQ号被错误的改写为全1,(对于EGT2单板来说就是0x3f因为单板最大支持0x3f)，对于大小为0x3f的SQ号芯片处理如下：

PMC5397芯片只有6个bit的寄存器表示SQ号，对于大小等于0x3f的SQ表示没有使用的SQ号（Each entry of the sequence RAM specifies four expected sequence numbers as explained in the ECBI register section. The four sequence numbers corresponds to four consecutive timeslots.For unused timeslots (including those for contiguous concatenation), the value must be set to0x3F.）。

在LCAS使能状况下（芯片LCAS一直处于使能状态）当收到大小为0x3f的SQ后，接收的

CTRL域会变成5（IDLE状态，表示该时隙不用）,从FPGA读出来的SQ保持以前的值不会

变，因为收到CTRL=IDLE这个时候就会通过LCAS适配层接口下发一次时隙配置关系，

其中包括下行方向SQ的值。由于下发的SQ的值是以前的值，和接收的实际SQ不一致，

所以业务中断并且上报FCS_ERR告警。

2）现场MSP恢复的时候由于误码干扰，导致一端EGT2单板接收到的SQ出现了错位，这种情

况下业务仍然中断，原因如下：

当1、2号时隙的SQ号由原来的0x3f成有效的SQ号以后（虽然两个SQ位置反了，但是在合理范围以内），这个时隙又会进行恢复，恢复的时候同样会下发一次下行SQ配置,但是这个时候下发的SQ配置关系是交换了位置的SQ，就是说1号时隙的SQ原本应该是0,现在下成了1，而2号时隙的SQ原本是1，现在下成了0，由于PMC5397芯片下发时隙绑定的时候SQ必须按照顺序排列，这样下发下去的时隙配置也是有问题的，所以业务仍然不恢复。

3）当SQ正确恢复以后，业务仍然不能恢复，原因如下：

造成不能恢复的关键原因是PMC5397不支持下行方向的SQ自适应。由于在第二步下发了错位的SQ号，现在虽然能够收到正确的SQ号，但是芯片不支持SQ自适应，使得芯片配置的下行SQ和接收到的正确的SQ不同，同样导致了业务的中断。

4）启停LCAS协议，业务恢复，原因如下：

重新启动LCAS协议后，会重新计算下发SQ，这样就会把当前正确的SQ重新下发到芯片配置寄存器，配置的SQ和接收的SQ一致了，业务就正常了。

总结：

通过上述的分析定位，得到该事故的根本原因是：由于MSP保护倒换产生的误码导致了SQ号

按照上述的规律被改写，并且由于PMC5397芯片不支持SQ自适应功能，导致误码消失SQ恢复以后

芯片的下行SQ配置和实际接收SQ不一致，从而导致业务中断并且不停上报FCS_ERR告警。

解决方案

紧急恢复措施：

无

彻底解决措施：

经过了解，OSN产品的EGT2单板也出现过因为误码影响SQ的类似问题，和OSN相关人员交流得知他们的EGT2单板在LCAS使能情况下也做了SQ调整任务，而SSA1EGT2单板只做了在LCAS不使能情况下的SQ调整任务，这个问题的根源也正式SQ自适应问题，于是我们也可以参照OSN做法，在LCAS使能情况下同样进行下行方向的SQ调整，这样再出现下行配置SQ和实际接收SQ不一致的时候就能够通过SQ的调整使得业务得到恢复。

本章相关技术资料和SDH设备故障处理流程由深圳市鼎为网络技有限公司收集整理（www.szdingwei.net），转载请保留!本公司专注华为SDH光传输设备,SDH传输设备的销售。