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

EXCSA switching from working to protection and viceversa due to fiber instability

Publication Date:  2012-07-25 Views:  34 Downloads:  0
Issue Description
Around 12:07:31 p.m. local on 29/09/2010 local, there was an automatic switching event APS_INDI located in EXCSA boards from OSN 3500. This NE is configured
 with an MSPRing.
The MSPRing switched from slot 9 to slot 10 and few seconds later MSPRing switched back and the MS_APS_INDI_EX alarm was reported.
NE details: OSN3500
Host: 5.21.16.13
Main subrack only
The information collected in the OSN 3500 Black Box, according to Huawei R&D, confirmed that there is no register of misoperating events in EXCSA boards from
 slot 9 and 10.
Alarm Information
MS_APS_INDI_EX, APS_INDI, TU_AIS_VC12, TU_AIS, HP_RDI, MS_RDI.
Handling Process
1. In the Picture you can check both directions; East (E) and West (W) from site 510-GDL, where 510-GDL is the ID 6 from the MSPRing Protection. The switching state from the MSPRing is identified by APS_INDI alarm in slots 9-EXCSA and 10-EXCSA:
  512944      10    APS_INDI              MJ          end         2010-09-29 11:07:32  2010-09-29 11:12:36  0x02   0x01   0x00   0x00   0x00   
  512947      10    MS_APS_INDI_EX        MJ          end         2010-09-29 11:07:36  2010-09-29 11:12:36  0x02   0x01   0x0b   0x01   0x00   
  513229      9     APS_INDI              MJ          end         2010-09-29 11:07:33  2010-09-29 11:12:37  0x02   0x01   0x00   0x00   0x00   
  513231      9     MS_APS_INDI_EX        MJ          end         2010-09-29 11:07:37  2010-09-29 11:12:37  0x02   0x01   0x0b   0x01   0x00   
2. On the other hand, in the Performance Monitoring the errors registered in the Multiplex Section from slot 8 and slot 10 (ssn1sl16 boards) showed an high 
increased counter number of FEBE and BBE as follows:
BID  PERIOD  STARTTIME                 EID      OPPORT   CHAN   VALUE 
11      15m    29/09/2010        11:00:00          msfeses             1       1 4
8 15m 29/09/2010 11:00:00 mses 1        1 1
11 15m 29/09/2010 11:00:00 mses 1   1 1
8 15m 29/09/2010 11:00:00 msbbe 1   1 30967
11       15m     29/09/2010        11:00:00           msfebbe       1 1 19683
Performance Monitoring is attached in the report that was sent to the customer. The time registered in T2000 is one hour forwarded delayed with the time 
registered in the NE.
This is 11:07 hrs in NE corresponds to 12:07 hrs in the iManager T2000.
3. The following is the K Bytes registered log from ID 513 & 510. 
K byte Site 513: 
  1      1663      SF_DETECTED          0x0000      2010-09-30 01:09:42  0x019a0881  //Detected SF event 
  1      1681      K_SENDS              0xb67a      2010-09-30 01:09:42  0x019a5212   
  1      1682      K_DIR                0x0002      2010-09-30 01:09:42  0x019a5213   
  1      1683      XC_EXECUTE           0x0002      2010-09-30 01:09:42  0x019a522b   
  1      1684      STATE_TRANS          0x240b      2010-09-30 01:09:42  0x019a52c2 
  1      1697      SF_CLEARS            0x0000      2010-09-30 01:09:46  0x01e03df8  //SF event cleared after 4 seconds 
K byte Site 510: 
  1      2868      K_DIR                0x0000      2010-09-29 11:07:32  0x039ed0bd   
  1      2869      XC_EXECUTE           0x0003      2010-09-29 11:07:32  0x039ed172  //East direction switched 
  1      2870      STATE_TRANS          0x241b      2010-09-29 11:07:32  0x039ed77e   
  1      2871      K_RECEIVED           0xb67a      2010-09-29 11:07:32  0x039f0420   
  1      2872      K_DIR                0x0000      2010-09-29 11:07:32  0x039f042b   
  1      2873      SF_DETECTED          0x0000      2010-09-29 11:07:32  0x03a01cec  //West direction detected SF event 
  1      2874      K_SENDS              0xb560      2010-09-29 11:07:32  0x03a022d7   
  1      2875      K_DIR                0x0000      2010-09-29 11:07:32  0x03a022ef   
  1      2878      XC_EXECUTE    0x0000    2010-09-29 11:07:32  0x03a024fd  //East and west, two directions switched, and service down. 
  1      2880      STATE_TRANS          0x0110      2010-09-29 11:07:32  0x03a02c9b   
  1      2881      SF_CLEARS            0x0000      2010-09-29 11:07:36  0x03de9323  //SF event cleared after 4 seconds
Root Cause
As shown in the figure, two directions (west and east) of site 510-GDL both switched at same time, but can not find any abnormal alarm. Analyzed K byte events, we found that SF event just reported 4 seconds, and Delay Function
 for SF event is four seconds, so SF event just remained 1 second, because Delay Function for alarm is 2.5 seconds, there was no alarm reported.
Suggestions
By the information collected in K Bytes, we identified that there was instability in the fiber during 1 second, this made that OSN 3500 were isolated for 1 second. 
Performance Monitoring events showed high increased number of FEBE and BBE errors in the Multiplex Section.

END