In this section:
The DSP20 module shown in the following figure, is the second generation Signal Processing Server (SPS) for SBC 5400 providing signal processing capabilities by incorporating the latest DSP technology. Only one DSP20 can be used in an SBC 5400, and it cannot be mixed with DSP25 cards in the same chassis.
DSP20 modules are considered hot-swappable. They may be removed and replaced without powering down the node. The SBC with the failed DSP20 module reboots, detects the DSP20 module failure during startup and returns to service with the DSP20 module disabled. Appropriate alarms are raised and automatically cleared by the system. The current node continues to deliver service (if Active SBC) or provide protection (if Standby SBC).
The DSP20 module is accessible from the rear of the chassis and connects to the DSP2x tray. The DSP20 module contains a single DSP device. The product codes for DSP20 modules are SBC-5400-DSP20 and SBC-5400-DSP20-S.
A DSP20 module is inserted/removed either to increase/decrease DSP capacity, or to replace a faulty module. Before removing a DSP20 module, the module must be software disabled using by CLI or EMA GUI to avoid a node reboot. DSP20 modules are added to or removed from the SBC 5400 platforms using one of the following methods:
Only one DSP20 is allowed in SBC 5400 chassis, and it must reside in slot 1. Mixing DSP20 and DSP25 modules (both within a chassis and between Active/Standby servers) is not supported. For example, if SBC-A has a DSP20 in slot 1, SBC-B should not have anything other than a DSP20 in slot 1.
In case of a DSP failure, the SBC supports reloading the faulted DSP in one second without a system switchover while restoring channels, if any, and collecting coredumps. If the DSP reload fails or if the number of DSP failure exceeds the set threshold (default two) for the given time interval (default 24 hours), the SBC performs a system switchover.
For more information on the DSP Channel Densities, see SBC 5400 DSP Densities.
The required parts and tools are:
To prevent damage from electrostatic discharge, an ESD strap is provided in the accessory kit. See Connecting ESD Wrist Strap to install it.
Perform the following procedure to replace the DSP20 module:
Loosen the screws securing the DSP20 module (or slot 1 cover) at the rear of the SBC 5400 chassis.
The SBC operator interface allows the operator to gracefully or forcefully dry up calls on a module and disable a DSP20 slot.
Removing a DSP20 module that has not been administratively disabled in a non-HA configuration triggers a service-impacting reboot. This is to prevent an indeterminate FPGA/bus state on the common hardware (that is, motherboard). In other words, predictable behavior cannot be guaranteed if the system is allowed to run without reboot.
A detectable DSP20 module failure triggers the SBC node to reboot and return to service in a degraded state (that is, less DSP capacity). The SBC node reboots, detects the DSP20 module failure during initialization and returns to service with the DSP20 module disabled.
For CLI command details to enable/disable DSP slot, see Daughter Board Admin - CLI. For EMA, see System - Daughter Board Admin.
From CLI, use the following CLI syntax to administratively enable the DSP2x module:
% set system daughterBoardAdmin <system name> <slot #> state enabled
From EMA UI, the DSP software can also be enabled from the All > System > Daughter Board Admin path in SBC main screen.
From the Daughter Board Admin screen, select "enabled" in the State field.
From the CLI, use the following CLI command syntax to administratively disable the DSP2x module. By default, the disable cleanup type is set to "graceful".
% set system daughterBoardAdmin <system name> <slot #> state disabled
From the EMA UI, navigate to the Daughter Board Admin screen and select "disabled" from the State field.
The steps below describe module replacement procedure in an HA pair configuration for a DSP20 module that experiences a hardware failure. This procedure assumes that the failure is detected at run-time and during subsequent start-up diagnostics.
The following configuration preferences are available for HA configuration to dictate SBC behavior in case of DSP20 module failure or mismatched hardware between active/standby nodes using the command:
set system admin dspMismatchAction
For CLI command details, see Admin - CLI,
For EMA command details, see System - Admin.
Active Node
If the active node discovers that the standby has less DSP capacity, the behavior will be to use the extra hardware; while operating in this mode, calls using DSPs on the primary that correspond to the disabled slot on the secondary will not be protected during switchover (that is, partial redundancy).
Secondary Node
If the secondary node discovers that the active has less DSP capacity, it is a non-issue since the secondary can fully back up the primary; if a switchover occurs the behavior in the first bullet then applies.
If a switchover occurs while operating in this mode, calls using DSPs on the primary SBC that correspond to the disabled slot on the secondary are not protected during switchover (that is, partial redundancy).
The procedures below describe two methods of adding DSP20 module to an in-service SBC 5400 HA pair to increase DSP capacity. In these procedures, "SBC-A" represents the Active SBC and "SBC-B" the Standby SBC. These procedures assume that the HA pair do not currently contain DSP20 modules.
Full redundancy is now in effect.
Steps 2 and 3 in the procedures above are not required, but are included to trigger the switchover in a more standard way with predictable behavior. Additionally, these steps cause the preserve-redundancy/preserve-capacity logic to take effect.
The procedures below describe removing DSP20 modules from an in-service SBC 5400 HA pair to decrease the DSP capacity. In these procedures, "SBC-A" represents the currently active SBC and "SBC-B" the current standby.
If the SBC is configured to 'preserve capacity', this procedure is service impacting, and calls may be dropped.
Calls using DSPs on the primary SBC corresponding to the disabled slot on the secondary are not protected during a switchover (that is, partial redundancy). Loss of active calls can be avoided by performing a dry-up prior to module removal.
The DSP20 module includes a Field-Programmable Gate Array (FPGA) that may occasionally require reprogramming. The reprogramming is fully autonomous and occurs during system reboot process. The only noticeable effect to the system is a slight increase to the duration of the system reboot. For each DSP20 installed, expect an additional 1-2 minutes added to the length of a normal reboot process.
Log messages pertaining to FPGA reprogramming are stored in the following files:
/var/log/sonus/sbx/openclovis
directory. This file contains all logs related to system startup as well as a log of other scripts that call this FPGA reprogramming utility./var/log/messages
file.Example Log Messages:
No upgrade is needed for a slot
updateAll:: key: 1, value: DSP20. NO ACTION REQUIRED FOR SLOT 1. version 2013/03/20 18:03:52, minVersionRequired 2013/03/20 18:03:52
Upgrade is needed for a slot:
updateAll:: Require update for slot 1 version :: 2013/03/20 18:03:52 and minVersionRequired 2013/03/20 18:03:53 upgradeFpgaForSlot Upgrading FPGA for Slot 1 Loading DSP20 FPGA File to memory [rr_dsp_mux3_routed.rom]...Complete Design Name: rr_dsp_mux3_routed.ncd;HW_TIMEOUT=FALSE;UserID=0xFFFFFFFF Device Name: 6vlx75tff484 Version: 2013/03/20 18:03:52 Image Length: 0x00320c2c Erasing DSP20 SPI Flash [SLOT 1]... Complete Programming DSP20 SPI Flash [SLOT 1]... Complete
All SBC 5400 CRUs are shipped in ESD bags and must be handled using appropriate ESD precautions.
The storage environment for these CRUs are:
For more information on the DSP Channel Densities, see SBC 5400 DSP Densities.
The ESD Susceptibility symbol warns of the presence of Sonus devices susceptible to electrostatic discharge. Do not handle equipment without wearing a properly grounded ESD wrist strap.