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

U2980 CIU board problem

Publication Date:  2018-01-29 Views:  78 Downloads:  0
Issue Description

After some E1 connection break, SS7 signalling link left in „failed” state. E1 connection had recovered after the issue was reported and customer claims there is no problem in transmission line by telecom provider. 


CIU board reset solved the problem in this case

 

%%DSP N7LNK: MN=56;%%

RETCODE = 0  Operation succeeded.

 

Display N7LNK status

--------------------

Link number  In use      Failed   Blocked      Activated  Locally inhibited      Remotely inhibited      Congested      Swappingover       Swappingback       SLS code                                      

 

0            Not In Use  Failed   Not Blocked  Activated  Not Locally Inhibited  Not Remotely Inhibited  Not Congested  Not Swapping Over  Not Swapping Back  NULL                                          

 1            In Use      Healthy  Not Blocked  Activated  Not Locally Inhibited  Not Remotely Inhibited  Not Congested  Not Swapping Over  Not Swapping Back  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

(Number of results = 2)

 

---    END



Handling Process

We have required from the customer the following:

 

1.export the ME=0 and ME=5 element all alarm log

2.export the configuration file(CVT MML)

3.export the ‘important” log for issue CIU board. Which save in “\\OMUIP\huawei\cgp\workshop\omu\share\run_log\dev_log\Sys\Importance\CIU number’’

4. login ME=5 and execute the “GET HWLOG: SRN=1, SN=X;” (replace the X as bad CIU board) command. Waiting about 5 minutes and export the log . which save in “\\OMUIP\huawei\cgp\workshop\omu\share\run_log\dev_log\Sys\Normal\CIU number’’

 

From the log provided ,it can be seen the board reset at JAN 15 13:38:23 2018.but the alarm log didn’t include this period .


Line 29850:  LEVEL: EMERGENCY 00136846 | 100 | 1 | tRootTask| printRebootReason|811| Last time Reboot reason: SD5000 | MON JAN 15 13:38:23 2018

Line 29852:  LEVEL: EMERGENCY 00136846 | 100 | 1 | tRootTask| printRebootReason|820| Extern bootrom start at: MON JAN 15 13:38:23 2018

Line 29874:  LEVEL: EMERGENCY 00136846 | 100 | 1 | tRootTask| printRebootReason|823| OS start at: MON JAN 15 13:38:49 2018


Alarm log.

%%LST ALMLOG: MEID=0, SGT=2018&01&14&16&00&59, EGT=2018&01&15&03&18&59;%%

Line 23472:  LEVEL:EMERGENCY  00134720|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2555,Type:2,Lv:3,Len:24,Fra:1,Slot:9,OPT:0,Para:3.

Line 23475:  LEVEL:EMERGENCY  00134721|129|1|t100MsChkTa|ALARM_InfoLog|226|[ALM]:ID:2550,Type:2,Lv:3,Len:28,Fra:1,Slot:9,OPT:0,Para:2555,3.

Line 23787:  LEVEL:EMERGENCY  00134825|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:3.

Line 23790:  LEVEL:EMERGENCY  00134826|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:5.

Line 23793:  LEVEL:EMERGENCY  00134827|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:4.

Line 23799:  LEVEL:EMERGENCY  00134829|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:2,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:5.

Line 23802:  LEVEL:EMERGENCY  00134830|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:2,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:4.

Line 23805:  LEVEL:EMERGENCY  00134831|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2552,Type:2,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:3.

Line 30030:  LEVEL:EMERGENCY  00136901|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:6.

Line 30033:  LEVEL:EMERGENCY  00136902|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:7.

Line 30036:  LEVEL:EMERGENCY  00136903|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:8.

Line 30039:  LEVEL:EMERGENCY  00136904|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:9.

Line 30042:  LEVEL:EMERGENCY  00136905|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:10.

Line 30045:  LEVEL:EMERGENCY  00136906|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:11.

Line 30048:  LEVEL:EMERGENCY  00136907|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:12.

Line 30051:  LEVEL:EMERGENCY  00136908|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:13.

Line 30054:  LEVEL:EMERGENCY  00136909|129|1|t100MsChkTa|ALARM_InfoLog|218|[ALM]:ID:2550,Type:1,Lv:1,Len:24,Fra:1,Slot:9,OPT:0,Para:15.

 

From the alarm log ,there is only E1 alarm . it didn’t have CIU board alarm.

I have requested the customer to export all alarm information as below:


LST ALMLOG: MEID=0

LST ALMLOG: MEID=5

And the following debug log:

 

\\omuip\huawei\cgp\workshop\omu\share\run_log\dev_log\V100R001C10SPC400B017\ME5\RUN\DEBUG


Root Cause

I have concluded that from the debug and alarm log, there is no error information that would identify any hardware issues however we believe that there was a process that failed to reset when the E1 signal recovered.

Solution

At the moment there was a process that failed to reset when the E1 signal recovered and issue needs to be occur again on customer’s live environment and afterwards follow the requested procedures/logs to be extracted to further analyze.


The restart of the CIU Board fixed the reported issue.

Suggestions

If the following procedure occurs in the future we have asked customer to do the following:

 

1.       Do not restart the CIU board.

2.       Collect MTP2 capture for both links.

END