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

Cross connect boards showed switching alarms after software degraded on 9&10 UXCSB boards

Publication Date:  2012-07-24 Views:  53 Downloads:  0
Issue Description
APS_INDI alarm appeared on OSN3500 after software degradation on 9&10 UXCSB boards. NE version is 5.21.13.47. Old version of UXCSB was 3.19 which is de-graded to 3.16 according to version matching table of osn3500. Also FPGA was changed from 220 to 210 of both 9&10 UXCSB boards. First i de-graded the standby cross connect board. Then i cold reset that board and switch that to active/protection. After switching, i de-graded the other standby cross connect board. After de-gradation, APS_INDI alarms appeared on both UXCSB. This APS_INDI was on Ring MS. 
Alarm Information
APS_INDI on both 9&10 UXCSB
PARA1  PARA2  PARA3  PARA4  PARA5
 0x02       0x01     0x00       0x00      0x00 
Handling Process
After that i use navigator to start the protocol. First used this command to query protocol status for protection group
:cfg-get-rmsprotocol:PgId;
 Then i stopped that protocol from command 
:cfg-stop-rms:pgid , 
then i started protocol from command 
:cfg-start-rms:pgid 
which successfully started the protocol. After protocol is started, APS_INDI alarms were removed
Root Cause

After analysis i found that protocol was unstarted in Protection Group. I tried to start that protocol from T2000, but it failed to start the protocol. I deleted that ring from NM layer and then created again, but still protocol was unstarted for this particular NE. Protocol of other NEs in this ring were started and normal. 

After anlysed the cause deeply, we found the issue was caused by the inconsistent software. When the slave XCS board which is used the lower version than that of working board, it will make the data synchronization from the working board automatically in case of hard reset or power on. But the slave XCS board which is used the later version than that of working board will not make the activity in that case.
Because the vesions between the active board and the standby board are different and the format of files partition are also different, so the data synchronization will be out-of-order and leads to the abnormal state of MSP. 

Suggestions
The problem will occur during the cross-connect boards' degradation if you degrade the standby one firstly. 
The problem can be evaded if you degrade the active one firstly. and the problem can be restored by stop/restart the MSP protocol or soft reset the active one.

END