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

FAQ-The alarm report rule for BD_STATUS and COMMUN_FAIL when board resetting

Publication Date:  2012-07-25 Views:  55 Downloads:  0
Issue Description
Customer found the board reported different alarm at R3 and R8 version when SSN1SL16/SSN3SL16 board hard resetting, sometimes BD_STATUS,sometimes COMMUN_FAIL alarm reported.
Customer want to know the alarm report rule for these alarms.
Alarm Information
BD_STATUS
COMMUN_FAIL
Handling Process
Normally, Give cold reset to the board, BD_STATUS alarm will report first, then COMMUN_FAIL alarm reports.This is a standard report rule, such as R8 main maintenance version(in third scenario).

Two issues in R3 version lead to the results in first and second scenarios:
1.As specification limitation, the BD_STATUS alarm may not report when we hard reset SSN11SL16/SSN1SL16A board. On the NE, the SCC board determines whether a service board is in position based on the voltage of the board in-position bus. Low level of the voltage indicates in-position and high level indicates not-in-position.This signal on the in-position bus is output buy the fpga of service board. when hard reset service board, the output of fpga will become high resistance state, then the signal voltage will be decided by the pull-up resistance. Due to ssn1sl16/ssn1sl16a board without pull-up resistance, so the signal voltage of these boards will be a random value. This is the reason that the SCC does not report BD_STATUS alarm sometimes in first scenario.
2.The time interval of detection for COMMUN_FAIL alarm is different between nscc and gscc.
the interval is short for nscc, so it can report COMMUN_FAIL alarm quickly.
the interval is a little longer for gscc, so if the board can be online very quickly (fpga output a normal signal value again within the interval), gscc wont report COMMUN_FAIL alarm
Root Cause
Doing the test in our lab and find follow results for three different scenarios:
1.For NSCC with R3 version, whether give cold reset or warm reset to ssn1sl16 board,the COMMUN_FAIL reports everytime and BD_STATUS reports sometimes.
2.For GSCC with R3 version, whether give cold reset or warm reset to SSN3SL16 board(configured as SSN2SL16), the COMMUN_FAIL doesn't report and BD_STATUS reports only when cold resetting.
3.For GSCC with R8 version, the COMMUN_FAIL alarm reports when give cold reset or warm reset to SSN3SL16, and BD_STATUS alarm reports only when give cold reset to SSN3SL16 board.


Suggestions
This is an introduction of the in-position detection on SCC board for the service board, If the SCC boards are not online, the alarms will not report also.

END