Overload Handling

The SBC Core supports signaling and media overload protection when the call load exceeds the specified performance and capacity limits. Overload protection works best when the IP ACL policers and the congestion/overload controls are configured according to overload control best practices:

  1. Create a whitelist IP ACL for each valid non-registering peer
  2. Compute each whitelist IP ACL fill rate measurements:
    1. Expected calls/sec x Expected ingress pkts/call
    2. Expected non-call ingress pkts/sec
    3. Expected calls/sec x 5 x 2

      A close-enough heuristic in most cases is expected CPS x 10 for the fill rate.
  3. Use default values for all congestion controls and overload profiles.

  4. Set TrunkGroup CAC controls appropriate to the associated customer.

The SBC checks CPU utilization against a predefined threshold to decide whether to allow resource allocation. This check is performed in two phases:

Phase 1: Allocation – Once the resource allocation message is received, the SBC checks if the CPU idle time for that second is within the predefined threshold or not. If the CPU is within the threshold, the call is allowed. Otherwise, the SBC fails the call.

Phase 2: Activation – All allocated calls may not be activated at the same time, which may lead to transient calls in answering state. To manage this situation, overload state is checked at the activation time. The transient calls are not allowed if the system is in CPU overload condition during activation.

Overload handling is supported separately for Pass-through, SRTP, and DSP calls.

  • Pass-through—Congestion is checked in the allocation of resources.
  • DSP—Congestion is checked both in allocation and activation of media resources.
  • SRTP—Congestion is checked during the time of resource activation.

Key highlights:

  • Overload controls for most resource types are enabled by default. While it is possible to disable overload controls, Sonus strongly recommends that they be left enabled unless directed otherwise by Sonus personnel. 
  • Overload controls aim to maintain a good call throughput of at least 60% of the engineered call rate even when the box is subjected to moderate levels of overload. This target only applies during periods of moderate overload (up to 3x engineered load).
  • Emergency calls are given preference over normal calls during overload. If the SBC is configured to properly recognize emergency calls based on dialed digits, then the system will attempt to preferentially accept emergency calls over normal calls. Note that emergency calls are still subject to overload controls (i.e. some emergency calls will be rejected during overload), but they have higher priority than non-emergency calls.
  • During an overload scenario, the SBC checks signaling load first, followed by media load for their respective resource allocations depending on the type of call.

Overload Profile

Modified: for 6.2.1

 

 

The Overload Profile controls SBC signaling overload by specifying a set of congestion thresholds, congestion durations, and overload controls. When a particular threshold is exceeded for a particular duration for any of the call processing related processes, the congestion level is raised to a higher level and the overload control is applied to help alleviate the congestion. The profile also specifies clear congestion thresholds and durations. These values require that the overload conditions fall below their configured clear threshold values for a specific duration in order to return to the previous congestion level. These minimum clear durations prevent repeatedly switching in and out of congestion levels.

Note

SBC SWe media overload cannot be governed by the Overload Profile settings. Its thresholds are fixed depending on the type of hardware used.

When assigning an Overload Profile to the system (throughout the SBC), you may specify and manage CPU utilization congestion criteria through this facility:

The following default Overload Profiles are automatically created for system congestion levels 1-3 for SBC 5000 and 7000 Series:

  • defaultMC1
  • defaultMC2
  • defaultMC3

The SBC supports to include two sets of MC level overload profiles based on the activated traffic profile for SBC SWe and SBC SWe Cloud. The following Overload Profiles are automatically created and associated for system congestion levels 1-3:

  • defaultMC1
  • defaultMC2
  • defaultMC3
  • sweOverloadProfileMC1
  • sweOverloadProfileMC2
  • sweOverloadProfileMC3

In case SBC SWe and SBC SWe Cloud, the Overload Profiles are mapped automatically with the traffic profiles when a traffic profile is activated. The defaultMC1, defaultMC2, defaultMC3 overload profile set is associated with the standard or custom traffic profile. The sweOverloadProfileMC1, sweOverloadProfileMC2, sweOverloadProfileMC3 overload profile set is associated with the default traffic profile.

For more information on the SWe Active Profile, refer to SWe Active Profile - CLI and SBC SWe Traffic Profiles.

Note

The defaultMC1, defaultMC2, defaultMC3 overload profile set is associated with SBC 5000/7000 Series, SBC SWe, and SBC SWe Cloud. However, the sweOverloadProfileMC1, sweOverloadProfileMC2, sweOverloadProfileMC3 overload profile set is associated only with SBC SWe and SBC SWe Cloud.

You must disable an Overload Profile to change its configuration. When you disable a profile, the SBC application continues to utilize the previous profile values for congestion control processing.

Once you enable the profile, all parameter values get validated and applied to the (system) congestion level that references the profile. In this situation, the system congestion level is cleared if the Overload Profile was being referenced. Standby modules also perform congestion processing but the module settings are
not configurable.

For more information on configuring overload profiles, refer to:

For details of assigning an Overload Profile to a system congestion configuration, refer to: