System - Congestion

The congestion objects provide a facility for managing the call congestion on the

server. Following system congestion levels are defined in this section, with each level representing an increasing severity of congestion within the :

• adaptive – Specifies the congestion level at which the adaptive congestion control algorithm activates. The adaptive algorithm iteratively adjusts the call acceptance rate up or down to maximize call throughput while maintaining target performance metrics throughout the overload event. The algorithm is self-tuning to automatically adjust to the
  Unable to show "metadata-from": No such page "_space_variables"
  nominal capacity (and to non-call-rate related events consuming unpredictable amounts of CPU) and is independent of call scenario mix, signaling types, and user retry behavior. There is a single default configuration for all system configurations. Emergency calls may optionally be given preference over non-priority calls.
• Level MC1 –  Specifies limited congestion level. By default, no calls are rejected due to congestion in this level.
• Level MC2 – Specifies moderate congestion level. By default, the adaptive congestion controls activate when this level of congestion is reached.
• Level MC3 – Specifies critical congestion level. By default, this level is disabled since the adaptive congestion controls (which activate at levelMC2) prevent the box from reaching this level.
• Mode – Mode (adaptive or monitor) for the system congestion control.
• Policer – Specifies the system congestion Call Rate Policer configuration.

In levels MC1 and MC2, the

software will attempt to balance traffic by assigning H.323 and SIP calls to non-congested modules. In levels MC1, MC2, and MC3, all INFO event log messages are suppressed. These congestion levels only apply to the packet calls. You define the threshold at which these congestion levels are trigger by associating each level with an Overload Profile. Independent congestion criteria thresholds and durations are specified in the Overload Profile:

• CPU utilization on server
• Memory utilization on server

By configuring the Overload Profile appropriately, some of the congestion criteria can trigger a change in the congestion level.

During a sustained system load, the

accepts calls at a smooth rate, avoiding behavior such as accepting all calls for a short period of time, and then rejecting all calls for the remaining sampling period. This is accomplished with system-level policers. Unlike IP Traffic Policers--which control the allowed rate of incoming IP packets, congestion policers control the allowed rate of incoming calls in a system. Individually configurable bucket sizes (POLICER BUCKETSIZE) control the call burst handling capability. The policer fill rate controls the sustained rate (the rate at which tokens are added to the bucket). In this case, the fill rate is the sustained call rate allowed at calls per second (CPS). Fill rates are not configurable when using congestion policers; instead, they are dynamically adjusted based on resource usage, to maximize those resources.

On SBC main screen, go to All > System > Congestion.

The Congestion window is displayed

The following fields are displayed:

Make the required changes and click Save at the right hand bottom of the panel to save the changes made.

Congestion Commands

The

detects congestion by monitoring a time-decaying average of the CPU utilization. It also monitors the Internal Round-Trip Time (IRTT) during call setup for determining whether the is in congestion. When congestion (for either reason) is detected and the congestion level reaches MC2, the SBC activates a control algorithm which adaptively throttles calls to eliminate the congestion while still maximizing the call throughput.

On SBC main screen, go to All > System > Congestion. The Congestion window is displayed. The Congestion Commands panel appears at the bottom

The following options are displayed:

setSysCongestion

This command helps you to simulate resources for appropriate CPU usage.

On the Congestion Commands panel, choose setSysCongestion as the Command from the drop-down list and click Select. A pop up window appears with the respective command parameters.

Choose the Resource and the Level at which the congestion should happen and click setSysCongestion.

The result of the action is displayed:

setDebugSysCongestion

This command helps you to set the debug flag along with the system congestion.

On the Congestion Commands panel, choose setDebugSysCongestion as the Command from the drop-down list and click Select. A pop up window appears with the respective command parameters.

Select enabled for Debugflag and click setDebugSysCongestion.

The result of the action is displayed:

setSysIpInstance

This command help you to direct all the calls to a specific instance of call processing engine.

On the Congestion Commands panel, choose setSysIpInstance as the Command from the drop-down list and click Select. A pop up window appears with the respective command parameters.

Select the Ip Type from the drop-down list and add the instance value and click setSysIpInstance.

The result of the action is displayed:

cpuhistory

This command helps you to view the CPU usage history.

On the Congestion Commands panel, choose cpuhistory as the Command from the drop-down list and click Select. A pop up window appears with the respective command parameters.

Select the desired Type from the drop-down list and click cpuhistory.

The result of the action is displayed:

memhistory

This command helps you to view the Memory usage history.

On the Congestion Commands panel, choose memhistory as the Command from the drop-down list and click Select. A pop up window appears with the respective command parameters.

Select the desired Type from the drop-down list and click memhistory.

The result of the action is displayed: