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.


Fail to query MSP(Multiplex Section Protection) Ring Switching status after GSCC upgrade

Publication Date:  2019-07-09 Views:  105 Downloads:  5

Issue Description

During the upgrade process of the T OSN 3500 Equipment from V1R2 to V1R3 and error message appeared related one of the SL4 boards that had a Ring MSP(Multiplex Section Protection) configured. The upgrade of the N1GSCC board had just been finished, the nesoft, FPGA and extended BIOS were correctly uploaded to the board and the Basic BIOS was uploaded and activated apparently with no problems. But when querying the MS parameters of the protection subnet through T2000 to know the switching status of the Ring, the following error message appeared (picture attached):

Querying of the MS maintenance parameter failed. Error code: 1090603123

As a result the status of the MS protocol was not updated (picture attached). The protection did actually exist; it was checked by T2000 and Navigator). But as did not refresh it, we did not know if the ring was switched or on idle state which put under risk the traffic of the node considering that the upgrade process was not finished and line boards would need to hard reset.

Alarm Information

Querying of the MS maintenance parameter failed. Error code: 1090603123

Query of switching status not updated:

Handling Process

First we tried to query the status of the ring several times on the Protection subnet parameters with the same result. Then we performed upload in all the equipments of the ring and query the switching status again but this was not refreshed.

After that we queried the status of the protocol in each node belonging to the ring, we noted that on one of the equipments B 9500 belonging to that ring,the status of one of the line interfaces related to that MSP(Multiplex Section Protection) appeared as unknown. Picture attacted.

We tried then to stop and restart the protocol under the Protection Subnet Maintenance menu of the T2000 but the status did not refresh. Next we tried to stop and restart the protocol but this time in each one of the equipments, but the same result was obtained, it did not refresh the switching status of the ring.

We decided then to delete the MS Protection subnet and perform the search of the protection subnet. This process succeded partially showing a similar error message than the one referenced before (picture attached):

This time the error code was: 1090603116 (Checking network-wide MS parameters failed). Then it was decided to delete it again and create it but this time node by node creating the respective protection group. To do this we put especial atention to the connections among sites, node IDs, SD, WTR, mapping direction, etc. After this was done and the switching status was queried again it finally showed the current status as idle. (picture attached)

After this was executed, no further problems were presented and the upgrade process could be continued and successfully ended with no services reported as affected.

Root Cause

During the upgrade process an inconsistency between the NMS and the NE information related to the configured MS parameters occurred. During the upgrade a consistency check was required before continuing with the process, this consistency check was not completely successful and some invalid path ID errors related to the J2 byte configuration were shown (picture attached). We consider this


When upgrading a NG-SDH Equipment from V1R2 to V1R3 that has MSP(Multiplex Section Protection) Rings configured, you have to be especially careful with the switching status of the configured protections. An upload to all the equipments of the ring is suggested and also to perform a query on all the MSP(Multiplex Section Protection) protections subnets configured on that ring and check that the switching status is coherent with the network conditions before proceding with the upgrade.

If abnormalities are found on the protection subnets parameters, first try to solve them before perform the upgrade. If cannot solve them and the upgrade is required, backup information is crucial in case protection subnets need to be recreated as in this case. If this is necessary, query again the switching status of the rings to confirm they are related with the network conditions.