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>Search


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


The OptiX Metro 1000 V2 Equipment Frequently Reports an R_LOS Alarm Due to the Problems of Version

Publication Date:  2012-07-25 Views:  92 Downloads:  0

Issue Description

In an office 161-Haizeluyouju, the NMS continuously reports the historical R-LOS alarm of the No.12 optical interface. Other sites do not use the optical interface and the R-LOS alarm is reported every two to ten minutes. The alarm is no longer reported after the self-loop is performed on the optical interface. The version of the NE software is and the version of the OI4 board is 1.01.  

Alarm Information


Handling Process

1. Judgment method
This fault occurs if the following conditions are met at the same time:
A. The NE alarm inversion mode is set to manual inversion on site.
B. The PARA2 and PARA3 parameters are set to 0x00 for the R_LOS alarm whose start and end are reported frequently.
NUM   BID   EID       SEVE    STATE     TIME                        PARA1   PARA2   PARA3
54       11   R_LOS   critical   end        2007-2-5 16:6:45   0x02       0x00        0x00
53       11   R_LOS   critical   end        2007-2-5 16:6:49   0x01       0x00        0x00
C. The current NE version is or later.
2. Mitigation measure:
Set the NE alarm inversion mode to automatic inversion, that is, set alm-set-invmode to 2. 

Root Cause

1.The optical interface frequently reports the start and end of the R_LOS alarm only when the manual alarm inversion mode is set and the alarm inversion is set to Enabled for the optical interface on which the services are available or the self-loop is performed on the fiber. This R_LOS alarm, however, is a fake R_LOS alarm generated when the alarm module is in manual inversion mode. That is, the R_LOS alarm does not actually exist on the board.

2.The R_LOS alarm occurs periodically and lasts about three minutes. In addition, the alarm is immediately reported again after it ends. The reason is that the alarm module verifies the alarms on the board. If the NE software fails to receive the start or end of the same alarm reported from the board in continuous three minutes, the NE software deems that the alarm ends on the board, and the alarm module actively terminates the alarm. 
3.The implementation of the alarm verification function on the board is as follows: The alarm module has a task (TBAV) of verifying the alarms on the board. The task increases the verification count of the board alarms received on the NE software by 1 about every one minute. Another task (TBAC) of collecting alarms on the board clears the verification count of an alarm each time the NE software receives the start of the alarm from the board. If the accumulated verification count reaches 3 (within about three minutes) and if the NE software fails to receive the start or end of the same alarm from the board, the NE software deems that the alarm ends on the board. In this case, the alarm module ends the alarm actively. Then, the start of the R_LOS alarm is reported again because the alarm module has one scheduled task to continuously insert the R_LOS alarm to the NE software. This is the phenomenon that you see.
4.The problem occurs on the NE software of only this version instead of the earlier versions because the alarm module fails to clear the verification count in time owing to the rectification of another problem. 


In the actual network environment, use the automatic alarm inversion mode.