In this section:

Overview

The DSP25 module shown in the figure below is the second-generation Signal Processing Server (SPS) for SBC 5400 providing increased signal processing capabilities by incorporating the latest DSP technology.

DSP25 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 DSP25 module is accessible from the rear of the chassis and connects to the DSP2x tray. The DSP25 module contains five DSP devices. The product codes for DSP25 modules are SBC-5400-DSP25 and SBC-5400-DSP25-S.

A DSP25 module is inserted/removed to either increase/decrease DSP capacity or to replace a faulty module. DSP25 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 (within a chassis and between Active/Standby servers) is not supported. For example, if SBC-A contains DSP25 in slots 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.


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.



DSP25 card

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

Parts and Tools Required to Insert/Remove Module

  • Electrostatic discharge strap
  • Replacement DSP25 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 DSP25 Module

The following procedure describes the basic steps to replace the DSP25 module. If your system is in a production environment, more detailed steps are provided further down on this page.

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

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

    SBC 5400 Chassis Rear View
  3. Remove the DSP25 module (or remove the slot cover) from the chassis and place it into the ESD protective bag.

  4. Insert the new/replacement DSP25 module into the empty DSP slots.

    SBC 5400 with DSP25 in Slot 1

    On HA server pairs, the modules should be installed in matching physical slot locations to maintain redundancy protection. Install the DSP25 modules in order of slots 1, 2, 3, and 4. For example, if you install two DSP modules in slots 1 and 2 on Active SBC and 2 DSP modules in slots 2 and 3 on Standby SBC, a mismatch will result, and calls will get dropped.

  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 DSP25 Module Behavior

  • An uncontrolled DSP25 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 potentially impaired hardware/FPGA states caused by the removal of an active module with packet traffic present on its interfaces.
  • Inserting a module that 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 DSP25 module slot configurations, the populated slots on both the active and standby must be identical to preserve redundancy protection of matching slots.

The SBC operator interface allows the operator to gracefully or forcefully dry up calls on a module and turn off a DSP25 slot.

Removing a DSP25 module not administratively disabled in a non-HA configuration triggers a service-impacting reboot. This is to prevent an indeterminate FPGA/bus state on the standard hardware (that is, motherboard). In other words, predictable behavior cannot be guaranteed if the system can run without reboot.

A detectable DSP25 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 DSP25 module failure during initialization and returns to service with the DSP25 module disabled.

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

For CLI command details to turn DSP slot on/off, see  Daughter Board Admin (CLI). For EMA, see System - Daughter Board Admin.

Enabling the DSP Software

Use the following CLI syntax to enable the DSP2x module administratively:

% set system daughterBoardAdmin <system name> <slot #> state enabled

The DSP software can also be enabled from the All > System > Daughter Board Admin path in the SBC main screen.
From the Daughter Board Admin screen, select "enabled" in the State field.

Daughter Board Admin screen Enabled

Disabling the DSP Software

Use the following CLI command syntax to administratively turn off the DSP2x module. By default, the disable cleanup type is set to "graceful."

% set system daughterBoardAdmin <system name> <slot #> state disabled

On the SBC main screen, navigate to the Daughter Board Admin screen and select "disabled" from the State field.

Daughter Board Admin Screen Disabled

Replacing DSP25 Module Due to Hardware Failure (HA Configuration)

The steps below describe the module replacement procedure in an HA pair configuration for a DSP25 module that experiences a hardware failure. This procedure assumes that the loss is detected at run-time and during subsequent start-up diagnostics.

  1. A DSP25 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 held in the dry-up state and cancel an uncompleted dry-up procedure since there is now DSP25 hardware alignment between the primary and secondary SBC.
    2. If the primary SBC was configured to preserve capacity, complete redundancy is now in effect.

HA Configuration Preferences in Case of Module Failures

The following HA configurations are available to dictate SBC behavior in case a DSP25 module fails, or mismatched DSP hardware is detected between active/standby nodes using the set system admin dspMismatchAction command. For CLI details, see  Admin (CLI); for EMA, see  System - Admin.

Preserving Redundancy (default behavior)

  • If the active node discovers that the standby has less DSP capacity, the SBC does not use the extra hardware; if active calls are present, the default behavior is to dry up in order to align DSP capacity 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 is not protected during switchover (that is, partial redundancy).
  • If the 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 DSP25 module reboots, detects the DSP25 module failure during startup and returns to service with the DSP25 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 to align DSP hardware capabilities.
    1. During the dry-up period, active calls on the "extra" DSP module are not protected if a switchover occurs before the dry-up completes.
  5. Once the dry-up is completed, the primary SBC no longer uses the "extra" DSP module.
  6. The pair is now redundant with reduced capacity.

Preserving Capacity

  • 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).
  • 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 DSP25 module reboots, detects the DSP25 module failure during startup and returns to service with the DSP25 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 the 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 the switchover (that is, partial redundancy).

Changing DSP Capacity (HA Configuration)

Adding DSP25 Module to Increase Capacity

The procedures below describe two methods of adding DSP25 modules to an in-service SBC 5400 HA pair to increase DSP capacity. In these procedures, "SBC-A" represents the currently active SBC and "SBC-B" is the current standby.

Preserving Redundancy

  1. Insert a DSP25 module into the lowest numbered empty slot 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.
  4. Insert a DSP25 module into an empty slot of SBC-A.
  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 DSP25 module into the lowest numbered empty slot of SBC-B and enable the place.
  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 DSP25 module into an empty slot 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 DSP25 Module to Decrease Capacity

The procedures below describe removing DSP25 modules from an in-service SBC 5400 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.

Preserving Redundancy (preferred method)

  1. Remove the DSP25 module from the highest numbered slot 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 has less DSP capacity.
  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" DSP25 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" DSP25 module (same slot as SBC-B).
  7. Remove the disabled DSP25.

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 DSP25 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 has less DSP capacity.
  4. SBC-A continues to use all available DSP capacity, as needed.
  5. Perform a graceful dry-up on SBC-A for the DSP25 module to remove.
  6. Remove the "extra" DSP25 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 DSP25 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 DSP25 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: DSP25.
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 DSP25 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 DSP25 SPI Flash [SLOT 1]... Complete
Programming DSP25 SPI Flash [SLOT 1]... Complete

CRU Storage

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

The storage environment requirements for these CRUs are:

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


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.

  • No labels