Congestion control

Understanding the TCAP service congestion control mechanisms and developing an effective application congestion control strategy is a critical step in developing a reliable system.

The TCAP service implements a four-level congestion control strategy. Level zero (0) indicates that TCAP is not congested and level three reflects the most congested state. The TCAP service further distinguishes between outbound and inbound congestion and maintains a separate congestion level for each direction.

Congestion control mechanisms include notifications to applications of congestion conditions and congestion control actions within the TCAP layer itself. Congestion notifications allow the application to take some corrective action, such as reducing the traffic load that it generates, before the congestion becomes severe and impacts the operation of the service. Congestion control actions within TCAP maintain the operation of the SS7 stack (possibly at a reduced capacity), including the operation of other SS7 layers and/or applications, during periods of congestion.

Outbound congestion

Outbound congestion in TCAP occurs when the:

• Application generates TCAP traffic at a rate greater than the capacity of the SS7 links or downstream network, resulting in network overload.

• Application generates TCAP requests faster than they can be processed by the TCAP layer, resulting in the TCAP service send queue building up beyond pre-determined thresholds (TCAP service congestion).

• Overall memory available to the TCAP layer drops below pre-determined thresholds (TCAP layer congestion).

Network overload

Network overload occurs when the MTP layer's outbound queues build up beyond configured limits due to:

• A traffic load that exceeds the capacity of the available signaling links

• Receipt of a transfer controlled message (TFC) regarding a congested destination

In either case, the application receives a TCAP PC-STATE indication containing the affected pointed code and the current congestion level. The application should reduce its traffic load toward the affected destination until the congestion abates. How the reduction is accomplished is up to the application. The TCAP layer itself takes no action to prevent further congestion. The following illustration shows a network overload condition.

In ANSI networks and in other national networks employing multiple congestion levels, the application must not generate any new traffic towards the affected destination with a priority lower than the current destination congestion level, as it will be discarded at the MTP layer.

For the international signaling network, and other ITU-based networks without multiple congestion priorities, it is important for the application to reduce the traffic load toward the affected destination, as the MTP layer only discards outgoing packets in cases of excessive queuing of traffic to congested signaling links. If the application fails to reduce its traffic load toward the congested destination, it can escalate the congestion condition.

When the network overload condition ceases, the application receives a TCAP PC-STATE indication containing the affected point code and a status value of SP_CONG_OFF, indicating that the application can resume normal traffic towards the affected destination.

TCAP service congestion

TCAP service congestion occurs when the application generates traffic faster than it can be accepted by the TCAP layer, resulting in the TCAP service transmission queue building beyond pre-determined thresholds. The application is notified of congestion when it receives a TCAPEVN_CONGEST event that includes the current TCAP congestion level. The congestion level can be between 0 - 3. Zero (0) indicates that congestion has ceased. As the TCAP congestion level increases, the application is expected to reduce its traffic load proportionately until the congestion ceases.

Note: The application receives the TCAPEVN_CONGEST event in the case of either TCAP service congestion or TCAP layer congestion. If it is necessary to distinguish between these two causes, the application can call TCAPGetApiStats to check the current congestion level for each of the possible causes to determine the cause of the current congestion.

By default, the TCAP service allocates a buffer pool for up to 128 requests to be queued to the TCAP layer. If the application fails to reduce its traffic load enough to ease the congestion, the TCAP service buffer pool eventually becomes depleted and the TCAP functions fail with a CTAERR_OUT_OF_MEMORY return code. When opening the TCAP service, the application can increase the number of buffers in the pool by setting service argument array element six to a number between 128 and 1024. Increasing the number of buffers in the pool allows a larger burst of traffic to be absorbed without triggering congestion, at the cost of more host memory used. Congestion onset and abatement thresholds are always set to a fixed percentage of the in-use (queued to the TCAP layer) regardless of the total size of the pool, as shown in the following table:

TCAP layer congestion

TCAP layer outbound congestion occurs when the amount of memory available to the TCAP layer for processing new transaction requests falls below configurable thresholds. For the embedded TX board-based TCAP this is the total percentage of available free memory on the board.

Similar to TCAP service congestion, the application is notified of TCAP layer outbound congestion when it receives a TCAPEVN_CONGEST event that includes the current TCAP congestion level. The congestion level can be between 0 - 3. Zero (0) indicates that congestion has ceased. As the TCAP congestion level increases, the application is expected to reduce its traffic load proportionately until the congestion ceases. The TCAP layer also takes action to protect the integrity of the SS7 stack and minimize the impact of the congestion on other services. The following table shows the TCAP layer reaction to outbound congestion:

Note: Applications are notified of a change in the outbound congestion level with a TCAPEVN_CONGEST event, and an alarm is generated.

The congestion onset thresholds for TCAP layer congestion can be adjusted with TCAPGenCfg or with the tcapcfg utility TCMEM_THRESH_X parameters. The congestion abatement thresholds for each congestion level are set midway between the previous two congestion onset thresholds. Refer to the NMS SS7 Configuration Manual for information.

Inbound congestion

TCAP inbound congestion is caused by one of two possible conditions:

• The TCAP application is not reading incoming messages as fast as they are generated by the network, resulting in build-up of the user queue.

• The overall memory available to the TCAP layer drops below pre-determined thresholds.

The inbound congestion level of each TCAP user SAP at any given point in time is defined to be the more severe of the current TCAP layer memory congestion level and the user SAP queue congestion level. A low memory condition affects the inbound and outbound congestion level of all user SAPs. A queue build-up congestion condition affects the inbound congestion level of only the user SAP whose queue is building or receding.

Unlike outbound congestion, the TCAP application is not notified directly of inbound congestion level changes, to prevent escalation of the congestion condition. An alarm is generated when a change in a TCAP user SAP's inbound congestion level occurs. The current inbound congestion level of a user SAP can also be determined by calling TCAPSapStats or by using the tcapmgr utility STATS command.

For inbound congestion, the TCAP layer cannot rely on the application to reduce its traffic load to ease the congestion, as the source of the traffic bursts is generally other network nodes. Instead, the TCAP layer acts directly to control inbound congestion by restricting the types of traffic that are allowed at the various congestion levels. These actions are described in the following table:

The memory onset and abatement thresholds can be adjusted with the same configuration parameters described in TCAP service congestion.

By default, the user SAP queue congestion thresholds are set to absorb a short burst of approximately 600 messages without the application retrieving a message before congestion control is triggered.