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.

Scroll to top