Possible cause of the OTU3_LOF alarm that is transiently reported by the NS3 board on the OSN 8800

9

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.

Other related questions:
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.

Possible causes for the CHAN_ADD alarm on the MCA board of the OSN 6800/8800
The CHAN_ADD alarm indicates that single-wavelength signals are added. This alarm is generated when the MCA board detects wavelength addition after it scans the optical spectrum. The possible causes of the CHAN_ADD alarm are as follows: 1. The configurations for wavelength monitoring are incorrect. The received wavelengths are not configured as the monitored wavelengths. 2. The MCA board is faulty. The procedure for handling the CHAN_ADD alarm is as follows: 1. On the U2000, check whether the configurations for wavelength monitoring of the MCA board are incorrect. If the configurations are incorrect, modify the configurations to ensure that the monitored wavelengths and the number of monitored wavelengths are consistent with the received wavelengths and the number of received wavelengths. 2. If the alarm persists, test the optical spectrum data of the input optical signals using an optical spectrum analyzer. If the data is normal, the optical spectrum analyzer module of the MCA board may be faulty. When this occurs, replace the MCA board.

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.

Possible causes of an ODUK_PM_OCI alarm on a board
The possible causes of an ODUK_PM_OCI alarm on a board are as follows: 1. An ODUK_PM_OCI alarm occurs on the corresponding board in the upstream. 2. A loopback occurs on the peer board. 3. No cross-connections or incorrect cross-connections are configured on the peer board.

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