Cause for transient alarm reporting on TOM boards

17

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.

Other related questions:
Possible cause of the OTU3_LOF alarm that is transiently reported by the NS3 board on the OSN 8800
The possible cause is that the embedded TDC module on the NS3 board is faulty. In general, the alarm can be cleared after the NS3 board is replaced.

Functions of the TOM board
The TOM board is an 8-channel Any service processing board. It supports various applications: 1. Functions as a tributary board to perform mutual conversion between ODU0/ODU1 signals and signals at arbitrary rates in the range of 100 Mbit/s to 2.67 Gbit/s. 2. Functions as an OTU board to perform mutual conversion between OTU1 signals and signals at arbitrary rates in the range of 100 Mbit/s to 2.67 Gbit/s. 3. Converges multiple channels of services into one channel of ODU0/ODU1 services.

Possible cause of the BUS_ERR alarm that is reported on an NS2 board after OptiX OSN 6800 is upgraded
The possible cause of the BUS_ERR alarm is that the board mode is incorrect. You are advised to modify the value of the line mode parameter.

Possible cause of the BUS_ERR alarm that is reported on a TDX board after OptiX OSN 6800 is upgraded
The possible cause of the BUS_ERR alarm is that the board mode is incorrect. You are advised to modify the value of the line mode parameter.

Causes for reporting the LASER_MODULE_MISMATCH alarm when the WDM side of the LEX4 board is interconnected with the client side of the LBFS board
By default, a colored optical module is configured on the WDM side of the LEX4 board, and the board software will automatically create a logical colored optical module for this WDM-side optical module. During practical application, you need to create the correct logical optical module based on the actual type of physical optical module that is used.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top