Reason why an OTU board still reports the R_LOS alarm when receiving optical signals normally

22

The possible cause is that alarm inversion is manually enabled.
During network deployment, some alarms may be reported but are meaningless. For example, a LOS alarm is reported even though no cable is connected to a board on which a service has been provisioned. After alarm inversion is enabled, such an alarm can be not reported to prevent disturbance on maintenance engineers. Alarm inversion needs to be disabled after commissioning is complete.

Other related questions:
R_LOS alarm reported on an LWX2 board when its optical module normally receives optical signals
Question: One OSN 1800 NE is used for point-to-point networking at each of sites A and B. According to a hardware loopback test on the client-side and WDM-client optical ports of LWX2 boards at site A, an R_LOS alarm is reported on the NMS. Site B has the same issue. Analysis: 1. The receive optical power is lower than the lower limit. 2. The optical module is faulty. Root cause: None Answer: 1. Use an optical power meter to measure the receive optical power of the optical module. It is found that the receive optical power is normal. 2. Replace the relevant optical module. The alarm is cleared. 3. According to relevant documents, if the WDM side emits light forcibly when no scrambled optical signal is added to the client side, the emitted light is white light. If the client side emits light forcibly when no scrambled optical signal is received on the WDM side, the emitted light is also white light. The current alarm detection mechanism cannot extract valid information from the white light. Therefore, the R_LOS alarm is reported. 4. Change the client-side service access rate of site A to 622 Mbit/s and add STM-4 optical signals from an SDH NE to site A. Then the R_LOS alarm is cleared on the client side of site A and the R_LOS alarm on the corresponding WDM side of site B is also cleared. Perform a hardware loopback using a fiber on the client side of site B. Then the R_LOS alarm is cleared on the client side of site B and the R_LOS alarm on the corresponding WDM side of site A is also cleared. After the preceding steps, this issue is resolved. Suggestion and conclusion: If the WDM side of an LWX2 board emits light forcibly when no scrambled optical signal is added to the client side, the emitted light is white light. If the client side emits light forcibly when no scrambled optical signal is received on the WDM side, the emitted light is also white light. The current alarm detection mechanism cannot extract valid information from the white light. Therefore, the R_LOS alarm is reported.

Cause for the R_LOS alarm during normal light receiving of the optical module on the LWX2 board
1. When an optical meter is used to measure the receive optical power of the optical module, the receive optical power is normal. 2. After the related optical power is replaced, the alarm persists. 3. When no scrambled optical signal is received on the client side, the light is white if light is forcibly emitted on the WDM side. When the WDM side does not receive any optical signal scrambled by the peer end, the light is also white if light is forcibly emitted on the client side. Based on the alarm detection mechanism, no valid information can be abstracted from white light. Therefore, an R_LOS alarm is reported. 4. When the client-side access rate of point A is changed to 622 Mbit/s and optical signals of SDH devices at the STM-4 rate level are received, the client-side R_LOS alarm is cleared on point A and the corresponding WDM-side R_LOS alarm on point B is cleared. When a hardware loopback is performed on the client side of point B, both the client-side R_LOS alarm on point B and the WDM-side R_LOS alarm on point A are cleared and the optical module fault is removed.

Causes for the issue that services are still normal at the client-side port on an L4G board where an R_LOS alarm is reported
As to a traditional SDH device, if an optical port reports an R_LOS alarm, the device will check all 1s in the payload of the channel, resulting in service interruptions. Why services of the port are still normal when an L4G board reports an R_LOS alarm on the client side? There are two causes: 1. The first cause is related to OTN principles. When an OTU board detects an R_LOS alarm on the client-side port, the device will not check all 1s in information payload. Instead, it will insert an SF event into its overhead. When the opposite end detects the SF event, the CLIENT_SF indication alarm will be reported. Although the OTU board reports the R_LOS alarm on the client side, the device will still encapsulate the weak signals received at the port. 2. Some boards can still receive valid information even when R_LOS alarms are reported on the client side. The L4G boards from different manufacturing batches use different chips, which have different sensitivity values. For some of them, although optical signal is lower than the preset R_LOS threshold, the received signals are still processed normally due to good quality of the chips.

Cause why the alarm indicator of the OTU board is red even after the HARD_ERR alarm is suppressed
Question: An OTU board on an OSN 6800 NE reports a HARD_ERR or HARD_BAD alarm. After the alarm is suppressed on the T2000, the board indicator on the T2000 is still red. When other alarms are suppressed and there is no additional alarm on the board, the board indicator is green. Analysis: The HARD_ERR and HARD_BAD alarms are at the hardware maintenance level. In general, the alarms indicate board hardware faults and the boards need to be replaced. Therefore, the alarm indicator is still on even when the HARD_ERR and HARD_BAD alarms are suppressed to instruct onsite engineers to replace the boards. Root cause: None Answer: The OSN 6800 is designed in this manner to instruct onsite engineers to replace faulty boards.

Trigger alarms of optical-layer service rerouting
Optical-layer service rerouting can be triggered when alarms such as R_LOS, OTUk_LOF, and OTUk_LOM are reported only on OTU boards.

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