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>


To have a better experience, please upgrade your IE browser.


The Switching of the OptiX OSN 3500 Cannot Be Restored Due to the Timeout Failure of T2

Publication Date:  2012-07-25 Views:  35 Downloads:  0
Issue Description
The OptiX OSN 3500s in a network form the MSP ring. The ring network is switched normally, but after the optical cable restores normal, the network fails to restore normal. 
Alarm Information
Handling Process

1. The engineers modify the J1 byte to check whether the optical cable connection is faulty. It is found that the optical cable connection is correct.

2. The engineers collect K bytes for analysis:

1    5644    SD_CLEARS    0x0002     2008-7-31 12:33:14   0x018f2820  //The SD switching condition is cleared at 12:33:14

1    5645    T2_START      0x0001      2008-7-31 12:33:14   0x018f2995  //Start the T2 timer

1    5646      K_SENDS     0x5ba2      2008-7-31 12:33:14   0x018f29ed

1    5647      K_DIR        0x0002      2008-7-31 12:33:14   0x018f29f5

1    5648      K_SENDS        0x5baa      2008-7-31 12:33:14   0x018f2a55

1    5649      K_DIR           0x0000      2008-7-31 12:33:14   0x018f2a5d

1    5650      STATE_TRANS   0x2415      2008-7-31 12:33:14   0x018f2b55

1    5651      K_RECEIVED     0x5aba      2008-7-31 12:33:14   0x018f5d56

1    5652      K_DIR           0x0000      2008-7-31 12:33:14   0x018f5d5e

1    5653      K_RECEIVED     0xb328      2008-7-31 17:23:34   0x031e7b52

It can be seen that the transmission of K bytes is normal and the T2 timer is started normally. However, the T2 timer cannot time out. As a result, the switching cannot be restored.

3. The engineers perform the following analysis: After the WTR timer (T2_START) is started, because the timeout event cannot be received, the WTR timer maintains in the WTR state and is aborted by the algorithm module abnormally. Because the crossover algorithm module does not set the timeout timer for writing the reserved memory to an invalid value after the timer times out, the algorithm module regards the timer as a valid timer. The platform times out the non-periodic timer and then releases the resource and adds the ID of the timer to the end of the unused timer linked list.

The MS starts a timer every two minutes for active and standby state synchronization. The timer IDs are applied and then released repeatedly. Other tasks also need to apply for timer IDs. If the MS applies for the ID successfully at the moment and service is delivered, the crossover algorithm module stores the ID and the cross algorithm actively stops the timer. Because timer started by the MS has been deleted, the timeout event can no longer be received and the MS enters the WTR state. However, the crossover algorithm still thinks that the MS has a timer and does not start a new timer for the MS. Instead, the crossover algorithm module directly adds the ID to ID list that the MS has applied for. Because the crossover algorithm module cannot receive the timeout event, the MS cannot switch to the idle state from the WTR state. When the T2 is started, this problem will occur again.

It is very difficult to reproduce this problem for the following reason: This problem involves a timer ID that has been used to deliver a service and the ID must be applied for the algorithm module for writing the reserved memory. This ID must be also applied for by the MS module at the same time and a service operation must be delivered to stop the timer ID for writing the reserved memory That is started in the last service delivery.

4. Solution: When the non-periodic timer times out, the upper layer software should set the timer ID to an invalid value to prevent incorrect timer stopping. This problem can be solved by upgrading the version to the R7C02B019.
Root Cause
1. The optical cable connection is incorrect.
2. The K byte is abnormal.