Cause for transient alarm reporting on TOM boards

On the OSP platform, alarm reporting has anti-jitter mechanisms. The anti-jitter time for alarm reporting is 2.5s and that for alarm clearing is 10s.
If a board alarm task can be reported to the platform at least two consecutive times within 2.5s, alarms may not be transiently reported. If the alarm task reporting interval of a board is greater than 2.5s, transient alarm reporting probably occurs. The alarm task reporting interval of most boards is 1s and alarm status can be reported twice in 2.5s. If an alarm is found during the first detection but cleared during the second detection, the alarm will not be reported. In this manner, transient alarm reporting can be effectively avoided.
To reduce the CPU usage, the alarm task reporting interval of TN11TOM boards is 2s but that of TN52TOM boards. As a result, the alarm status may be reported only once in the 2.5s anti-jitter period. Consequently, the alarm anti-jitter mechanism does not take effect and an alarm is reported and lasts 1s. If a higher-priority task preempts the alarm task, the alarm task reporting interval may be longer and the alarm may last for more than 1s.
Therefore, TOM boards are prone to report alarms in case of transient service interruption. When bit errors are present on a line, a TOM board may falsely detect that the BDI byte is reset to 1 and therefore transiently reports alarms such as ODU1_PM_BDI. As a result, alarms such as ODU1_PM_DEG may be transiently reported upon SNCP protection switching.

Scroll to top