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.


TQX Report R_LOS Under Normal Input Power Due to XFP Standard

Publication Date:  2012-07-25 Views:  144 Downloads:  0
Issue Description
At  S country J customer test lab, it is found that the TQX client side report R_LOS when there is a fiber broken at Line Side (52 ND2).  However, this is out of expectation as there is NO ALS enabled at the client side and the remote end.  Thinking that  might be a false alarm due to wrong justification by U2000, Navigator is then used to check the TQX alarm, it is also found that TQX is exactly reported R_LOS, pleaser refer to attached Navigator Result "TQX report R_LOS even though power is normal".  However, the input power level at TQX is normal at -6 dBm.  To further justify this, the fiber is restored and the 10GE LAN with MAC Transparent (10.7G) service is deactivated and deleted, and then, the 10 GE LAN with Bit Transparent (11.1G) service is created and activated.  The Line side fiber is then broken again, and this time the TQX reported the minor alarms for REM_SF and LOCAL FAULT without R_LOS.  This is a normal stated we expect.  Again, we restored the fiber, and the same testing is repeated but with STM-64 and 10GE WAN traffic respectively, the alarm reported by TQX is R_LOF when the line side is broken again.  Again, this is also normal.  After investigating with R & D they claim that this is decided by the XFP manufacturer and also the transponder type. 

Please refer to attached screen shot and network illustration  for further reference.

The OSN8800 (T32) plaltform is (V1R6C01SPC200) , TQX is TN55 (3.33 software version) and the U2000 version is V1R5C00SPC200.

Alarm Information
After investigating the ITU-T G.783 Standard (2006 release), the interpretation of the R_LOS also inclusive of the absent of incoming signal.  Please refer to below extraction from G,783: Loss Of Signal defect (dLOS)

STM-N optical interfaces: This parameter should take on the value "incoming signal absent" when
the incoming power level at the receiver has dropped to a level which corresponds to a high error
condition. The purpose of monitoring this parameter is to indicate either:
i) transmitter failure;
ii) optical path break.
NOTE – This is a functional specification referring only to the quality of the incoming signal. It does not
necessarily imply either the measurement of optical power or BER. The timing requirements for detection of
the LOS defect is the province of regional standards. One example is the following: An LOS defect occurs
upon detection of no transitions on the incoming signal (before descrambling) for time T, where
2.3 ≤ T ≤ 100 μs. The LOS defect is terminated after a time period equal to the greater of 125 μs or 2.5 T'
containing no transition-free intervals of length T', where 2.3 ≤ T' ≤ 100 μs. 

Handling Process
As per mentioned over Phenomenon Description.

Root Cause

Under such cicumstance, the engineer and customer are confused about the reporting of R_LOS under the normal input power condition and there is NO ALS enabled at client side.   In most of the situation, the maintenance engineers will directly investigate the connectivity and normality of the fiber cable connection at the port that directly report the R_LOS NOT at the Line side.  It is because when there is line side failure at input power -60dBm, the client side shall report the absent of client signal payload like reporting the R_LOF by STM-N ands 10GE WAN or LOCAL FAULT by 10GE LAN (Bit Transparent). 

It is suggested that we should enforce a standard requirement to our XFP manufacturer on alarm reporting.  A more comprehensive alarm is needed which is match with the actualy scenario.  The only difference between 10 GE LAN Bit Transparent and MAC transparent is the way how does the digital signal is transferred at the Layer 2.  The former is by Bit while the later is by Frame.  If the former can report the absent of the actual signal by reporting LOCAL FAULT, then it is also reasonable the later can report the similar alarm under the same cicumstance rather than a confusing R_LOS.