You are here: CSP Developer’s Guide: Overview > 4 EXS API Application Development > Line Card Overload Logic

Line Card Overload Logic

Introduction

Dialogic has developed this Line Card Overload Logic to detect, prevent, and react to overload (busy) conditions. Similar logic resides on the Matrix Controller, which detects the overload condition and sends System Busy messages to reduce the load. Similar overload detection logic is implemented directly on the 16-span line cards and SS7 PQ cards. The logic on these cards stops traffic from the host and network, and tries to bring the cards gracefully back into a normal state. Highlights of the Line Card Overload Logic feature are as follows:

• The detection logic is common to all line cards.

• Existing calls are preserved.

• Busy conditions are handled gracefully.

• The host can configure all thresholds and parameters for the logic.

• The logic minimizes processing, memory usage, and inter-task messages during a busy condition.

Purpose

The purpose of this feature is to prevent cards from faulting due to overload. The Line Card Overload Logic allows messages to be grouped for more efficient processing. If the card does become overloaded, the situation is handled gracefully, until the overload condition resolves.

When the card’s traffic reaches the Approaching Busy threshold, the CSP sends an alarm to the host, signifying that the card is at risk of becoming overloaded. If the condition persists and progresses to "Real Busy," all new calls from the host and network are rejected, and idle channels are taken out of service. This way, existing calls remain intact and they are allowed to complete.

To reduce traffic that can lead to overloads, inter-task and inter-card messages (such as DS0 Status Change messages) are grouped for greater efficiency. The host can enable and disable message grouping, and it can configure various thresholds. A line card reports resource usage in response to a host request. A line card can also be configured to send this report at regular intervals.

The logic is common to all relevant cards, but the action differs, depending on the card. Timer 1 interrupt monitors the memory, Message Control Blocks (MCB), and CPU usage. To determine CPU usage, profiling on all cards is always ON. The average usage for the cards is sampled and checked against the configured thresholds.

When either of these tests shows usage above the Approaching Busy or Real Busy thresholds, an Alarm message is generated. When the resource usage falls back below Safe Level, the alarm is cleared. If the card usage drops from Approaching Busy down to Safe Level, the Approaching Busy alarm is cleared.

Configuring Thresholds

The host can configure two threshold levels for each line card. The Matrix Controller sends a message to the line card, with a value indicating the thresholds for CPU use and Resource use (MCB and Memory). The line card then sets values for the Approaching Busy and Real Busy thresholds.

Table 4-1 Threshold Parameters

Usage Designation | Meaning
Real Busy threshold | The maximum usage allowed
Approaching Busy threshold | The intermediate level. The card is approaching a busy condition
Safe Level | 20% less usage than the Approaching Busy threshold. Usage is considered normal

Reporting Resource Usage

The host can turn the Resource Utilization Report ON and OFF (OFF is the default) using the System Configuration message. Within the message, the line card is specified in an Address Information Block (AIB) and the time interval for reporting is also specified. When the timer expires, the report is sent and it contains the value accumulated since the last report.

Grouping DS0 Status Changes

A channel and span's status can change because of hardware problems, or it can be changed by the host. For example, the host can bring up all channels on a span all at once, generating many simultaneous status change messages. To reduce this internal traffic, these messages are put into a single group for each span.

Line Cards

Every time a span on a 16-span line card goes out of service or comes back into service, a message is generated for each channel on the span. This is true whether the change is initiated by the CSP or by the host.

SS7

For this feature, SS7 CICs can be considered equivalent to DS0 channels on line cards. Now, Channel Status messages are grouped and handled the same way as the DS0 Status Change messages are handled.

See Signaling System Number Seven.
AIB. A standardized block that allows address data to be inserted in a standard way into API messages.
See Address Information Block.