Versions Compared

Old Version 2

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c85b00e8, userName='null'}
REV5UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26ca7e0466, userName='null'}
REV6UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c7cd0042, userName='null'}
REV3UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c82800c1, userName='null'}
REV1UserResourceIdentifier{userKey=8a00a02355cd1c2f0155cd26c85700d0, userName='null'}

...

borderColorgreen
bgColortransparent
borderWidth2

Back to Table of Contents

Back to Customer Replaceable Units

...

Panel

In this section:

Table of Contents
maxLevel3

Overview

Tooltip
tipUse ESD protective device

Image Modified

The DSP20 module shown in the following figure, is the second generation Signal Processing Server (SPS) for 

Spacevars
0model5
providing signal processing capabilities by incorporating the latest DSP technology. Only one DSP20 can be used in an
Spacevars
0model5
, 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

Spacevars
0product
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

Spacevars
0model5
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).
Note

Only one DSP20 is allowed in 

Spacevars
0model5
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.

Include Page
One DSP Note
One DSP Note

Caption
0Figure
1DSP20 card

Image Modified

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

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

    Spacevars
    0model5
    chassis.

    Caption
    0Figure
    1SBC 5400 Chassis Rear
    Image Modified 
  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.
Note

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.

Note
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:

Code Block
languagenone
% 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.

Caption
0Figure
1EMA Daughter Board Admin Enabled Screen
 Image Modified

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

Code Block
languagenone
% 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.

Caption
0Figure
1Daughter Board Admin Disabled
Image Modified

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:

Code Block
languagenone
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.
Info
titleFailure 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.

 

Info
titleFailure 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 

Spacevars
0model5
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.

Note

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 

Spacevars
0model5
HA pair to decrease the DSP capacity. In these procedures, "SBC-A" represents the currently active SBC and "SBC-B" the current standby.

Warning

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

Warning

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

    Code Block
    languagenone
    updateAll:: key: 1, value:

...

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

    Code Block
    languagenone
    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

Tooltip
tipESD protective device

Image Modified

All 

Spacevars
0model5
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.

 

Include Page
ESD_footnote
ESD_footnote