You are here: CSP Developer’s Guide: Common Channel Signaling > 2 Introduction to SS7 > SS7 Signaling Stack Congestion Control
SS7 Signaling Stack Congestion Control
Overview
The Signaling Stack Congestion Control feature prevents the SS7 card from failing due to call traffic overload. Congestion Control is enabled by default and Dialogic recommends that you do not disable it.
Automatic congestion control monitors inbound and outbound traffic (from the CSP perspective). Congestion (at the CSP) is not invoked as a result of an adjacent CSP entering a congested state. When an adjacent platform enters a congested state, Dialogic-initiated calls to that platform will fail. A Release Message (REL) will be received in the backward direction in response to the Initial Address Message (IAM). The cause parameter within the REL message will indicate congestion. It is the host's responsibility to examine the cause parameter in the Channel Released with Data API, and throttle (stop) traffic for a host-determined amount of time.
If the CSP encounters congestion in the outbound direction, attempts to Outseize will result in a negative acknowledgment of 0x0C (Outbound Congestion). In this case no IAM is sent to the network.
The level of congestion on each signaling stack is monitored by the Signaling Procedure Control (SPRC) component. Internal "Queue Probe" messages are periodically sent to measure the amount of delay (backup) in the SS7 message queue.
Each time a "Queue Probe" is returned to SPRC, the delay for that probe is recorded, as well as an average delay for n number of probes. If either delay reaches the configured threshold, a congestion condition is determined to exist and action is taken to relieve the congestion.
Figure 2-12 Calculating Congestion Level
There are three congestion statuses:
• No Congestion
• Level 1
• Level 2
The transition between congestion statuses and the associated thresholds with default settings is shown in the next figure.
Figure 2-13 Congestion Levels
The default threshold values are as follows:
• Probe Delay: 10 seconds
• Average Delay: 5 seconds
• Probe Delay: 12 seconds
• Average Delay: 6 seconds
• Average Delay: < 1 seconds
The default values for congestion Level 2 are not configurable. The number of probes used to calculate the Average Delay is 10 and the time between probes is one second.
System Busy, Host Overload, and Exchange Overload
A Congestion Indication may also be sent by MTP for both ANSI and ITU-TS. In this case, a General alarm of SS7 Signaling Network Congestion (0x0E) is sent to the host. It is the responsibility of the host to implement the proper reaction for Congestion Indications.
For ANSI, the congestion level byte in the alarm has a value from 0–3, where 0 represents no congestion.
For ITU, the congestion level byte is always 1 [no alarm received after a given amount of time (for example, ITU-TS T30) indicates no congestion]. For ITU, see Q.767 D.2.11. For ANSI, see T1.113-1992 2.11.
The CSP may generate a System Busy alarm when it is processing a heavy call load. In addition, there may times when the host application experiences overload conditions. In either of these cases, the host should initiate procedures to try to reduce incoming traffic to the CSP. ISUP supports a mechanism for presenting a level of exchange overload to other connected SS7 exchanges as described below.
After detecting a System Busy Alarm or host application overload, the host should insert the Automatic Congestion Level parameter into all outgoing REL messages (for a description, see ANSI T1.113.4-1992 section 2.11, Annex D and ITU Q.767 Section D.2.12.) This parameter relays a level of exchange overload to the other exchanges. The other exchanges in turn, attempt to reduce the volume of traffic to the CSP.
Upon receiving an Alarm Cleared message or if the host application becomes less overloaded, the host can discontinue including the Automatic Congestion Level parameter in the REL messages. The distant exchanges then return to normal traffic to the CSP after a predetermined period of time.
Just as the host should be able to generate REL messages with the Automatic Congestion Level parameter, the host should also scan incoming Channel Released With Data messages for Automatic Congestion Level parameters. If Automatic Congestion Level parameters are received in the incoming REL messages, the host should attempt to reduce the volume of traffic to the DPC that generated the Automatic Congestion Level parameter until the DPC stops inserting Automatic Congestion Level parameters into its outgoing REL messages (see ANSI T1.113.4 Annex D, or ITU Q.767 Section D2.12).