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 184.108.40.206 and the version of the OI4 board is 1.01.
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.
ALM REPORT -- 018
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 4.02.06.10 or later.
2. Mitigation measure:
Set the NE alarm inversion mode to automatic inversion, that is, set alm-set-invmode to 2.
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.