No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

FAQ-Why Are the Services at the Ports on Certain L4G Boards Normal Even If the R_LOS Alarm Has Occurs on the Client Sides of the Boards

Publication Date:  2012-07-25 Views:  55 Downloads:  0
Issue Description
Q:
During the deployment or routine maintenance, the services at the related port on a certain L4G board of the OptiX OSN 6800 are still normal although the R_LOS alarm is generated on the client side of the board and the opposite end reports the CLIENT_SF event. Why? 
 
Alarm Information
Null
Handling Process
A:
If an optical interface reports the R_LOS alarm, the traditional SDH equipment inserts all 1s for the payloads in the path, and the services are interrupted. Why are the services on the port normal when certain L4G boards report the R_LOS alarm on the client side? The possible causes are as follows:
(1) The problem is caused by the OTN principle. After the OTU detects the R_LOS alarm on the port of the client side, the equipment does not insert all 1s for the information payloads, but inserts the SF event in the overheads of the payloads. After the opposite end detects the SF event, it reports the CLIENT_SF alarm. Although the OTU client side of the equipment reports the R_LOS alarm, the equipment encapsulates the faint signals received on the port.
(2) Although the client side reports the R_LOS alarm, certain boards can still receive the valid information. This is because the L4G boards in different lots use different chips. The quality of the chips is different. The sensitivity of certain chips is high (that is, the quality is well). Therefore, although the optical signals are weaker than the configured R_LOS threshold, the chips can process the received signals normally. 
 
Root Cause
Null
Suggestions
Null

END