Hello, everyone!
I would like to share with you an issue about OTU4_LOF alarm on an OChM (Optical Channel Multi-Carrier) established between NS4M board housed in an OSN 8800 T32 and LSCM board housed in an OSN 1800 II.
Description:
The network scenario is as follows:
and the network scheme with more details about internal fiber is belows:
The LSCM optical transponder board is a wavelength conversion board. In the receive direction, the board receives one 100GE/OTU4 optical signal from the client equipment, maps the optical signal into an OTU4 signal. The LSCM board uses four DWDM wavelengths to transmit one channel of OTU4 signals in the short-haul IDC interconnection scenario (as a Multi-Carrier Line Board).
Our LSCM type is TNF1LSCM01 (even wavelengths C-Band):
As a type of line board, the NS4M board converts 80 ODU0, 40 ODU1,ten ODU2, ten ODU2e, two ODU3, one ODU4, or 80 ODUflex into one ITU-T G.694.1 OTU4 signal. The board supports hybrid transmission of the ODU0 service, ODU1 service, ODU2/ODU2e service, ODU3 service and the ODUflex service. The NS4M board uses four wavelengths to transmit one channel of OTU4 signals in the short-haul IDC interconnection scenario (Multi-Carrier Line Board).
Our NS4M type is TN54NS4M01 (even wavelengths C-Band):
During the commissioning, first we configure wavelengths in single-site mode (74/192.40/1558.17; 76/192.30/1558.98; 78/192.20/1559.79; 80/192.10/1560.61) and then create OChM trail in search mode for management.
The challenge is to establish a 100GE service between the client ports (TX/RX) of the LSCM optical transponder board housed on OSN 1800 II and TSC tributary board housed on OSN 8800 T32.
Condition:
After create an OChM, we detect the loss of OTU4 frame (on the WDM Side).
Symptom:
The OTU4_LOF appears on LSCM optical transponder board.
Impact:
100GE service is interrupted (appears R_LOS on the Client Side).
Severity:
Critical
Root Cause:
The possible causes of the OTU4_LOF alarm are as follows:
Solution:
We discarded the last 3 reasons because these were already verified by the network administrators and field technicians.
Therefore, it only remained to analyze the first reason:
- The signals transmitted by the corresponding board at the opposite end do not have frame structure.
If the OTU4_LOF alarm is reported constantly, the better way is to make a physical loop test to the OTU board to isolate the unavailable board at the opposite end, that is, on the NS4M multi-carrier line board at Site 2 (taking advantage of the fact that we had field technicians in site).
As a result of the physical loop test, the OTU4_LOF alarm clears on the LSCM board and appears on the NS4M board.
It's clear that the NS4M board is faulty and the solution is replace it to solve this issue.
As a resut of replacing the NS4M board, the OTU4_LOF alarm dissapears and 100GE service is active in normal state without any alarm.
Issue solved!!
References:
- HedEx
BR
