DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
The DSP20 module shown in the following figure, is the second generation Signal Processing Server (SPS) for SBC 5x10 providing signal processing capabilities by incorporating the latest DSP technology.
DSP20 modules are considered hot-swappable. They may be removed and replaced without powering down the node. For example, inserting a DSP25 module which is administratively enabled results in the module booting up as normal without user further intervention. 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-5X10-DSP20 and SBC-5X10-DSP20-S.
A DSP20 module is inserted/removed to either 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 5x10 platforms using one of the following methods:
Only one DSP20 is allowed in SBC 5x10 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 contains DSP25 in slot 1-3, SBC-B should also have a DSP25 in slots 1-3. As another 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 failures exceeds two within 24 hours, the SBC performs a system switchover.
For more information on the DSP Channel Densities, see DSP Channel Densities for SBC 5xx0 and 7000.
The required parts and tools are:
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 5x10 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.
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 5000 series 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 5000 series HA pair to decrease 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 DSP2x 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 DSP2x 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: DSP25. 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 DSP2X 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 DSP2x SPI Flash [SLOT 1]... Complete Programming DSP2x SPI Flash [SLOT 1]... Complete
All SBC 5x10 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 DSP Channel Densities for SBC 5xx0 and 7000.
The ESD Susceptibility symbol warns of the presence of Ribbon devices susceptible to electrostatic discharge. Do not handle equipment without wearing a properly grounded ESD wrist strap.