In this section:

Overview

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:

  • Operator inserts module(s) on active system.
  • Operator performs a graceful system shutdown, inserts/removes a module and powers on the system (preferred method).

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.

Note

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.

 

 

DSP20 card

For more information on the DSP Channel Densities, see SBC 5400 DSP Densities.

Parts and Tools Required to Insert/Remove Module

The required parts and tools are:

    • Electrostatic discharge strap
    • Replacement DSP20 module
    • A #2 Phillips-head screwdriver.

To prevent damage from electrostatic discharge, an ESD strap is provided in the accessory kit. See Connecting ESD Wrist Strap to install it.

Inserting/Removing the DSP20 Module

Perform the following procedure to replace the DSP20 module:

  1. Attach an Electrostatic Discharge wrist strap using the ESD grounding point on the front panel of the chassis (see Connecting ESD Wrist Strap for details).

  2. Loosen the screws securing the DSP20 module (or slot 1 cover) at the rear of the SBC 5400 chassis.

    SBC 5400 Chassis Rear

     
  3. Remove the DSP20 module (or remove slot cover) from slot 1 of the chassis and place it into the ESD protective bag.
  4. Insert/replace the DSP20 module in slot 1.
  5. Tighten the two captive fasteners to 10 in/lbs.
  6. Enable the DSP Software.
  7. Run SBC HW Diags and observe results after the installation is completed.

Fundamental DSP20 Module Behavior

  • An uncontrolled DSP20 module removal will always trigger a node reboot.
  • If the DSP slot is not administratively disabled, the entire server (OS and application) is rebooted to ensure recovery from any potential impaired hardware/FPGA states caused by the removal of an active module with packet traffic present on its interfaces.
  • Inserting a module which is administratively enabled results in the module booting up normally without further user intervention.
  • For an HA pair, when a node restarts or reboots, the nodes exchange DSP system capacity information as part of re-establishing HA connectivity.
  • For total or partial DSP20 module slot configurations, the populated slots on both the active and standby must be identical for preservation of redundancy protection of matching slots.

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.

Up to three reboots may occur before the module is declared failed.

For CLI command details to enable/disable DSP slot, see Daughter Board Admin - CLI. For EMA, see System - Daughter Board Admin.

Enabling the DSP Software

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.

EMA Daughter Board Admin Enabled Screen

 

Disabling the DSP Software

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.

Daughter Board Admin Disabled

Replacing DSP20 Module Due to Hardware Failure (HA Configuration)

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.

  1. A DSP20 module is replaced on a failed SBC.
    1. Ideally the system is gracefully shut down, the module is replaced, and the system is powered back up.
  2. The failed SBC returns to service and is now a viable secondary.
    1. If the primary SBC was configured to preserve redundancy, it starts using the module that being held in the dry-up state and/or cancel an uncompleted dry-up procedure since there is now DSP20 hardware alignment between the primary and secondary SBC.
    2. If the primary SBC was configured to preserve capacity, full redundancy is now in effect.

HA Configuration Preferences in Case of Module Failure

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.

Preserving Redundancy (default behavior)

  • If active node discovers that the standby has less DSP capacity, the SBC does not use the extra hardware; if active calls are present, default behavior is to dry-up in order to bring DSP capacity into alignment and restore full redundancy. During the dry-up period, calls using DSPs on the active node that correspond to the disabled slot on the secondary are not protected during switchover (that is, partial redundancy).
  • If standby node discovers that the active has less DSP capacity, this 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.
Failure Scenario
  1. An SBC node experiences a hardware failure which triggers the functioning node to remain (or become) the primary SBC.
  2. The SBC with the failed DSP20 module reboots, detects the DSP20 module failure during startup and returns to service with the DSP20 module disabled.
    1. Multiple reboot attempts may occur before the module is declared as failed.
    2. The module is disabled via hardware primitives (such as slot power-down or hold in reset) to ensure that a misbehaving board cannot interfere with system operation.
  3. When establishing HA connectivity, the primary SBC discovers that the secondary has less DSP capacity.
  4. The primary SBC automatically triggers a graceful dry-up in an attempt to align DSP hardware capabilities.
    1. During the dry-up period, active calls on the "extra" DSP module are not protected in the event that a switchover occurs before dry-up completes.
  5. Once the dry-up completes, the primary SBC no longer uses the "extra" DSP module.
  6. The pair is now redundant with reduced capacity.

Preserving Capacity

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.

 

Failure Scenario
  1. An SBC node experiences a hardware failure, which triggers the functioning node to remain (or become) the primary.
  2. The SBC with the failed DSP20 module reboots, detects the DSP20 module failure during startup and returns to service with the DSP20 module disabled.
    1. Multiple reboot attempts may occur before the module is declared as failed.
    2. The module is disabled via hardware primitives (such as slot power-down or pressing and holding in reset button) to ensure that a misbehaving module cannot interfere with system operation.
  3. While establishing HA connectivity, the primary SBC discovers that the secondary SBC has less DSP capacity.
  4. The primary SBC continues to use all DSP capacity as needed.

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).

Changing DSP Capacity (HA Configuration)

Adding DSP20 Module to Increase Capacity

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.

Preserving Redundancy

  1. Insert a DSP20 module into slot 1 of SBC-B, and enable the slot.
  2. Perform a switchover to return SBC-B to service and make it the primary.
  3. SBC-B discovers that its HA peer (SBC-A) has less DSP capacity, and thus does not use the new DSP capacity at this time.
  4. Insert a DSP20 module into slot 1 of SBC-A, and enable the slot.
  5. Perform a switchover to return SBC-A to service and make it the primary.
  6. SBC-A discovers that SBC-B has equivalent DSP capacity via an automated HA link establishment procedure, and enables usage of the new DSP module assuming the appropriate session licenses are in place.

Preserving Capacity

  1. Insert a DSP20 module into slot 1 of SBC-B, and enable the slot.
  2. Perform a switchover to return SBC-B to service and make it the primary.
  3. SBC-B discovers that its HA peer (SBC-A) has less DSP capacity, but uses the new DSP capacity assuming the appropriate session licenses are in place; partial redundancy is in effect.
  4. Insert a DSP20 module into slot 1 of SBC-A, and enable the slot.
  5. Perform a switchover to return SBC-A to service and make it the primary.

  6. 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.

Removing DSP20 Module to Decrease Capacity

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.

Preserving Redundancy (preferred method)

  1. Remove the DSP20 module from slot 1 on SBC-B. This triggers a node reboot.
  2. SBC-B returns to service.
  3. While re-establishing HA connectivity, SBC-A discovers that SBC-B is without any DSP capacity as only one DSP20 is allowed in the system.
  4. SBC-A automatically triggers a graceful dry-up in an attempt to align DSP hardware capabilities.
    1. During the dry-up period, active calls on the "extra" DSP20 module are not protected in the event that a switchover occurs before dry-up completes (that is, partial redundancy).
  5. Once the dry-up completes, the SBC-A no longer uses the "extra" DSP module.
  6. Disable SBC-A's "extra" DSP20 module.
  7. Remove the disabled DSP20.

Preserving Capacity

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.

  1. Remove the DSP20 module from the highest numbered slot on SBC-B. This triggers a node reboot.
  2. SBC-B returns to service.
  3. When re-establishing HA connectivity, SBC-A discovers that SBC-B is without any DSP capacity as only one DSP20 is allowed in the system.
  4. SBC-A continues to use all available DSP capacity, as needed.
  5. Perform a graceful dry-up on SBC-A for the DSP20 module to remove.
  6. Remove the "extra" DSP20 module from SBC-A which triggers a reboot and switchover.
  7. SBC-B returns to service.
  8. Full redundancy is now in effect.

Field Programmable Gate Array

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:

  • sbx_start.log_<timestamp> file located in /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:

  1. 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

  2. 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

CRU Storage

All SBC 5400 CRUs are shipped in ESD bags and must be handled using appropriate ESD precautions.

The storage environment for these CRUs are:

  • Humidity must be less than 95% (non-condensing)
  • Temperature must be between -40C and +70C.

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.