Description of the problem

OSN3500 has a high order service coming from a third party equipment doing VC4 pass-through on our equipment. The line veneers passing through are SSN3SL16A, SSN1SL64,SSN2SLQ16. SSN3SL16A veneer does not detect SES but SSN1SL64,SSN2SLQ16 veneer detects 2 SES; or SSN3SL16A veneer detects 5 SES but SSN1SL64, SSN2SLQ16 veneer detects 18 SES. there may be a momentary AUO. SSN2SLQ16 veneer detects 18 SES. there may be a momentary AUAIS alarm, which may not be observed because of alarm filtering.

Processing

There are two sources of SES performance: the first is BER generation, if there is a serious BER on the channel, it will generate SES. the second is SES from alarms, the channel level alarms that will lead to SES performance are as follows: AUAIS, AULOP, HPTIM, HPUNEQ. when the performance module goes to inspect the alarm module to see if there is any alarm, if there is no alarm at the sampling time point, the performance module will not consider that there is an alarm, and therefore no SES will be generated. If there is no alarm at the sampling time point, the performance module will not consider that there is an alarm, and therefore no SES will be generated. Therefore, the record of SES performance generated by an alarm depends on the status of the alarm and the read time of the software patrol task.

The alarm patrol task of the product software in the SSN3SL16A board is 200ms, while the alarm patrol task of the product software in the SSN1SL64 and SSN2SLQ16 boards is 1 second. If the alarm is pulsed, for example, a 100ms alarm is generated, for SSN3SL16A single board at this time, the product is reported to the platform, the next cycle of no alarm, this time the alarm is reported to the platform is over, if the platform samples at this time, the alarm will not be read, and therefore does not record the SES, but for the SSN1SL64,SSN2SLQ16 single board even if the 100ms alarm is generated, the next alarm is reported to the platform, the next alarm is reported to the platform is over, if the platform samples at this time, it will not be read, so it does not record the SES. However, for SSN1SL64,SSN2SLQ16, even if an alarm is generated for 100ms, the next alarm reporting cycle is 1 second later, but the platform sampling will read the alarm within this 1 second, so the SES performance will be recorded.

Root Cause

The root cause of this problem is that when the alarms are pulsed, the alarm patrol cycles of different boards are different, resulting in different alarm states detected by different boards when the platform is doing performance sampling, and thus different numbers of SESs are recorded.