2.1 Introduction

2.2 Signaling Point Types

2.3 MTP 3 Message Handling

2.3.1 Inbound Messages

2.3.2 Outbound Message Routing

2.3.3 Routing Masks

2.4 Contexts and Queues

2.5 Signaling Network Management

2.5.1 Changeover/Changeback

2.5.2 Forced/Controlled Rerouting

2.5.3 MTP Restart

2.5.4 Signaling Link Management

2.5.5 Signaling Link Test

2.5.6 Signaling Route Management

2.6 MTP Layer 3 Service Users

2.7 Entity and Instance IDs

2.8 API Primitives

2.9 Initialization and Binding

2.10 Data Transfer

2.11 Status Indications

2.12 Extended Status Indications

2.13 Congestion Control

2.13.1 Outbound Congestion

2.13.2 Inbound Congestion

2.13.3 Application Flow Control

2.1 Introduction

The MTP 3 API is implemented as a Natural Access service. Natural Access is a development environment for telephony and signaling applications that provides a standard application programming interface for services, such as signaling protocol stacks, that is independent of the underlying hardware.

Natural Access is described in detail in the Natural Access Developer's Reference Manual. Understanding of the basic Natural Access programming concepts - services, queues, contexts, and asynchronous events - is critical to developing applications which utilize the MTP 3 API service.

The SS7 MTP layer 3 has two primary functions.

• Message routing and distribution

• Signaling network management

Message routing and distribution includes both the routing of outgoing messages to their specified destinations and the distribution of incoming messages to the appropriate user part or application. The SS7 MTP implementation uses a flexible configuration capability to support a wide variety of network routing and addressing requirements.

Signaling network management's job is to reconfigure the signaling network as needed to maintain signaling capability in the case of failures or congestion. This includes redirecting traffic away from failed links and/or signaling points (SPs), restoring traffic to restored links/SPs, and exchanging route status with adjacent SPs. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of destination signaling points, the onset and abatement of congestion, and signaling point restarts.

The primary objects represented by MTP layer 3 are Network Service Access Points (NSAPs), signaling links, linksets, combined linksets, and routes.

Network service access points (NSAPs) define the SS7 user parts, or applications, that are users of the MTP service. Each NSAP is associated with one user part or application (as identified by the service indicator field of a message) and one protocol variant (ITU-T or ANSI). Figure 2 illustrates the concept of NSAPs.

Figure 2. Network Service Access Points (NSAPs)

If multiple protocol variants are configured on the same MTP 3 instance (same board) then two NSAPs are required for each user part: one for ANSI, one for ITU-T. In this case, a single user part/application may associate itself with both NSAPs for that service, or separate user part/applications may be used for each protocol variant.

Links define physical signaling links between the TX board and the adjacent signaling points. One link configuration must be performed for each physical signaling link. The attributes of a link include the point code of the adjacent signaling point, protocol variant employed on the link (ITU-T or ANSI), point code length, maximum packet length, various timer values, membership in a linkset, and others.

Linksets are groups of from one to 16 links that directly connect two signaling points. Although a linkset usually contains all parallel signaling links between two SPs, it is possible to define parallel linksets. Each signaling link defined is assigned membership in exactly one linkset.

A combined linkset is a group of all linksets that can be used to reach a particular destination or group of destinations (routes). Each linkset may be associated with up to 16 combined linksets. For each combined linkset that a linkset is a member of, it may be assigned a priority relative to other linksets belonging to that combined linkset.

Routes specify the destination signaling points (or subnetworks - clusters - when route masks are employed) that are accessible from the target node. Each route is assigned a direction - up or down. One up route is required for the actual point code assigned to the signaling point being configured and for each point code that is to be emulated. Up routes are used to identify incoming messages that are to be routed up to the applications/user parts. One down route is required for each remote signaling point/network/cluster that is to be accessible from the SP being configured.

Down routes are used to route outgoing messages to the appropriate signaling links. Each down route is assigned to one combined linkset, which in turn identifies all linksets which may be used to reach that destination. Each linkset within the route's associated combined linkset may have an optional priority assigned, such that MTP routing will choose the highest priority available linkset when routing an outgoing packet to a particular destination. Any number of routes may be assigned to a combined linkset.

Figure 3 illustrates the relationship between links, linksets, combined linksets, and routes.

Figure 3. Links, Linksets, and Routes

2.2 Signaling Point Types

The MTP 3 layer can be configured as either a signal transfer point (STP) or as a signaling endpoint, referred to simply as an SP. The primary difference between STP operation and SP operation is in the handling of messages received from signaling links by the MTP 3 layer but addressed to other destinations.

When configured as an STP, MTP 3 searches for an outbound route to the message's destination and, if found, routes the message over an outbound link. When configured as an SP, the MTP 3 layer discards such messages.

When configured as an STP, the MTP 3 layer also performs the additional signaling route management procedures required of an STP. These primarily involve notifying adjacent SPs when they must no longer route messages to a particular destination through that STP due to failures or congestion (transfer prohibited/restricted), and notifying them again when normal communication with the concerned destination is restored (transfer allowed).

2.3 MTP 3 Message Handling

The following subsections describe how the MTP 3 layer handles inbound messages, outbound messages, and routing masks, as well as the congestion priorities supported.

2.3.1 Inbound Messages

When an inbound message is received, the MTP 3 layer searches its routing tables for a route that matches the destination point code in the message. If a matching UP route is found for the message, it is distributed to the appropriate user part/application based on the service indicator value in the incoming message and the link type (protocol variant) attribute of the link that the message was received on. This is illustrated in Figure 4.

Note: Only the link type of the incoming link and the service indicator portion of the SIO octet in the incoming message are used to choose the NSAP to receive the incoming message; the sub-service field of the SIO octet (national/international indicator and optional message priority) is not used.

Figure 4. Inbound Message Distribution

If a matching DOWN route is found for the message instead, the message is either routed as an outbound message (if the MTP 3 layer is configured as an STP) or the message is discarded. If no matching route is found, the message is always discarded.

2.3.2 Outbound Message Routing

For outbound messages originated by local user parts/applications (or received messages being routed outbound when in STP mode), message routing is based on the destination point code and signaling link selection (SLS) field associated with the message.

When an outbound message is ready for routing, the MTP 3 layer searches its routing tables for a route that matches the destination point code specified for the message. If a matching DOWN route is found for the message, message routing depends on the value specified for the SLS field, as follows:

• If the MTP 3 layer has recently routed a message with the same combination of DPC and SLS value, the same linkset and link are chosen for transmission, to maintain the order of delivery for messages between the same user parts/applications in the same direction with the same SLS value. This combination of DPC/SLS value is called a route instance. A route instance remains in effect until a configurable amount of time elapses, with no new messages containing the same DPC/SLS values.

• If no current route instance is in effect, the MTP 3 layer finds all active linksets belonging to the combined linkset associated with the target route and chooses the highest priority for transmission. If multiple linksets of the same priority are active, the linkset is chosen on a round-robin basis from all those at the same (highest) priority. Within the linkset, the actual link to transmit the message on is also chosen on a priority basis (again round- robin when multiple links of the same priority are available).
  Note: The user part/application is responsible for assigning SLS values for outgoing messages such that related messages that must be delivered in order get the same SLS value, but for unrelated messages the SLS value is varied to achieve the desired degree of load sharing. For example, the ISDN User Part (ISUP) typically uses the least significant 4 bits of its circuit identification code (CIC) as the SLS value so that all messages related to a particular circuit use the same link/linkset, but that messages for different circuits are reasonably load shared across all available links/linksets.

2.3.3 Routing Masks

The MTP 3 layer allows for the use of routing masks to help decrease the size of the routing tables that must be configured. Routing masks are bit masks that specify a subset of a destination point code to be matched against the routing table when searching for a route for either an inbound or outbound message.

Routing masks may be used to implement network and cluster routing in ANSI networks. For example, consider the following network diagram (Figure 5). Rather than specifying explicit routes to each of the seven remote SPs, the following routing masks and routes can be used (note that all point codes and routing masks, regardless of point code length, are stored internally as 32-bit unsigned integers).

Routing Mask	Comment
0xFFFFFFFF	Always specify exact match as first mask.
0xFFFF00	Match on network ID + cluster ID next.
0xFF0000	Match on just network ID last.

Routes	Comment
1.1.100, UP	Always specify an UP route to self.
1.1.1, DOWN, Linkset 1	Explicit route to STP for network 1, cluster 1.
1.1.0, DOWN, Linkset 1	Cluster route to network 1, cluster 1.
1.2.1, DOWN, Linkset 2	Explicit route to STP for network 1, cluster 2.
1.2.0, DOWN, Linkset 2	Cluster route to network 1, cluster 2.
2.1.1, DOWN, Linkset 3	Explicit route to STP for network 2.
2.0.0, DOWN, Linkset 3	Network route to network 2.

Note: Routing masks are global to all links, linksets, and user parts, and are applied to both incoming and outgoing messages. Although the previous example is specific to ANSI networks, routing masks can be applied equally to other networks (ITU-T based networks with 14- or 24-bit point codes) to reduce the size of routing tables.

Figure 5. Network/Cluster Routing

2.4 Contexts and Queues

Natural Access organizes services and their associated resources around a processing object known as a context. Each instance of an application binding to an MTP 3 service SAP comprises a unique Natural Access context. Contexts are created with ctaCreateContext.

All events and messages from the MTP 3 service are delivered to the application through a Natural Access queue object. Queues are created with ctaCreateQueue. Each context is associated with a single queue through which all events and messages belonging to that context are distributed. More than one context can be assigned to the same queue.

Different application programming models are possible depending on how many MTP 3 service SAPs (how many subsystems) are implemented by the application and how the application is organized.

An application that uses a single MTP 3 SAP uses a single-context, single-queue model as shown in Figure 6.

Figure 6. Single-Context, Single-Queue Model

For a single-threaded application which uses multiple MTP 3 SAPs (implements multiple MTP 3 subsystems), a multiple-context single-queue model is recommended, as shown in Figure 7. In this case the application has a single event loop with events from all SAPs delivered via the same queue. The application determines which SAP a particular event is associated with from a
service user ID (suID) value returned with each event.

Figure 7. Multiple-Context, Single-Queue Model

For multi-threaded applications using multiple MTP 3 SAPs (one per thread), a multiple-context multiple-queue model (shown in Figure 8) is recommended. In this case each thread has its own independent event loop, receiving only the events associated with its MTP 3 SAP on its Natural Access queue.

Note: For this programming model, each thread/event queue must be assigned its own entity ID, which must be unique among all applications on that host accessing any of the SS7 services.

Figure 8. Multiple-Context, Multiple-Queue Model

2.5 Signaling Network Management

Signaling network management provides the functions necessary to maintain signaling service during failures and congestion and restore normal signaling service after recovery from these conditions. The MTP 3 layer supports all required ANSI and ITU-T network management procedures without intervention from the user parts/applications. It does, however, notify user parts and applications of significant network events that might impact their operation, such as changes in the accessibility status of remote signaling points, the onset and abatement of congestion, and signaling point restarts.

2.5.1 Changeover/Changeback

The MTP 3 layer automatically initiates changeover procedures whenever a link fails, is deactivated, is remotely blocked, or is inhibited. No user part/application action is required nor is the user part/application notified when the changeover occurs.

Likewise, when a signaling link is restored, unblocked, or uninhibited, the MTP 3 layer automatically performs the changeback function, again without interaction with the user parts/applications.

2.5.2 Forced/Controlled Rerouting

The MTP 3 layer also handles forced and controlled rerouting upon receipt of the transfer prohibited and transfer allowed/transfer restricted messages. On receipt of a transfer prohibited message (TFP), the MTP 3 layer attempts to redirect all traffic for the prohibited destination to an alternate route. If no alternate routes are available, the destination is declared inaccessible and each user part/application is notified with a StatPaused status indication for the concerned destination. Note that destinations may also be declared inaccessible for other reasons, such as signaling link or signaling point failures, which result in similar StatPaused status indications to the user parts.

Traffic routing over an unavailable or restricted route is automatically restored upon receipt of the transfer allowed (TFA) or transfer restricted (TFR) message for that route. If the TFA/TFR causes a previously inaccessible destination to become accessible, each user part is notified with a StatResumed status indication for that destination.

2.5.3 MTP Restart

The MTP 3 layer may be configured with or without the MTP restart capability. The MTP restart function allows a signaling point just becoming available (such as after a failure) to bring up sufficient links to handle the expected traffic load before receiving new traffic.

If configured to do so, the MTP 3 layer will perform the restart function whenever the first signaling link becomes active (such as at system startup or after a total failure affecting all links), or on command from a management primitive. At the beginning of an MTP restart, each user part/application is notified with a StatRestart status indication. User parts should not generate new traffic requests during the restart. When the restart is complete and the MTP 3 layer is ready for traffic, each user part/application receives a StatRestartEnds status indication.

2.5.4 Signaling Link Management

The MTP 3 layer provides the basic link management functions and, optionally, the signaling link management procedures based on automatic allocation of signaling terminals described in the ANSI and ITU-T MTP standards.

Each link set has a minNmbActLnk attribute which determines the normal number of active links in the linkset. Typically this number will include all links in the linkset, but it is possible to configure extra alternate links that are activated only in the presence of failures of other links.

Whenever a linkset is activated (such as at system startup time), the MTP 3 layer will attempt to activate the minNmbActLnk highest priority links in that linkset. If a link fails, or cannot be aligned successfully, the MTP layer will periodically attempt to restore the link until successful or until the link is manually disabled via a management primitive.

If the current number of active links in a linkset drops below the minNmbActLnk threshold, the MTP 3 layer will attempt to activate the highest priority inactive link that is not currently inhibited, remotely blocked, or manually disabled. If no other links in the linkset meet this criteria, the MTP 3 layer will attempt to uninhibit the highest priority inhibited link in the linkset, if any.

If the current number of active links in a linkset goes above the minNmbActLnk threshold due to a link restoration, the MTP 3 layer will attempt to deactivate the lowest priority active link to return the number of active links in the linkset to its normal condition.

This automatic activation/deactivation of links is normally performed without interaction with the user parts/applications, unless it results in one or more destinations becoming accessible/inaccessible, in which case the user parts are notified with a StatResumed or StatPaused status indication, as described earlier.

If no automatic activation/deactivation of links is desired, then minNmbActLnk threshold can be set to the actual number of links in the linkset (or greater).

2.5.5 Signaling Link Test

The MTP 3 layer requires a successful signaling link test (SLTM generated and SLTA response expected) as part of link activation before considering a signaling link active. Thereafter the signaling link test is performed periodically on each active signaling link, at a configurable period (link timer T34 - corresponds to ANSI T1.111.7/ITU-T Q.707 timer T2). Signaling link testing is performed with no user part/application interaction.

2.5.6 Signaling Route Management

When configured as an STP, the MTP 3 layer implements the signaling route management procedures - transfer prohibited, transfer allowed, transfer restricted, signaling route set test, and signaling route set congestion test - described in the ANSI and ITU-T MTP standards. These procedures are performed without interaction with the user parts/applications.

2.6 MTP Layer 3 Service Users

The MTP Layer 3 data application interface supports one or more user applications by way of Service Access Points, or SAPs. One SAP is defined for each application that may use the MTP layer 3 service. A user application binds to a particular SAP at initialization time, specifying the SAP ID that it wishes to bind to. Each SAP is associated with a Service Information Octet (SIO) value, which in turn identifies the upper layer protocol in use on that SAP (for example ISUP, TUP, SCCP). Therefore, there may be at most one application process handling incoming messages for a particular upper layer protocol (at most one process receiving incoming ISUP messages).

The number of SAPs (MTP Layer 3 users - MAX_USERS) and the characteristics of each SAP are specified in the MTP 3 configuration file. See Mtp3InitNSapCfg and the Signaling System 7 (SS7) Installation and Configuration Manual for details.

2.7 Entity and Instance IDs

Each user application must also have a unique entity and instance number, which is used to route messages among the various processes in the system. Entity IDs are single byte values in the range 0x00 to 0x3F, assigned as desired by the application developer. Entity IDs are allocated as follows:

Range	Usage
0x00 - 0x1F	Reserved for use by system utilities, configuration utilities, and management utilities.
0x20 - 0x3F	Available for use by applications.

Instance IDs identify the processor on which the entity executes. The host is always processor 0 (zero), so for all host-resident MTP 3 user applications this value should be coded to zero. All tasks on TX board number one receive an instance ID of one, all tasks on TX board number two receive an instance ID of two, and so on.

2.8 API Primitives

The MTP Layer 3 data API consists of the following primitives:

Primitive	Direction	Description
Data Request	Application -> MTP 3	Requests MTP 3 to transfer a data packet.
Extended Status Request	Application -> MTP 3	Registers/Deregisters the application to receive extended status indications.
Data Indication	MTP 3 -> Application	Notifies the application of an incoming data packet.
Status Indication	MTP 3 -> Application	Notifies the application of change in status of SS7 network.
Extended Status Indication	MTP 3 -> Application	Notifies the application of a change in the status of MTP layer components.
Flow Request	Application -> MTP 3	Requests MTP 3 to start or stop flow control on a network SAP.

2.9 Initialization and Binding

Before calling any MTP 3 API primitives, the application must first perform the following steps to set up the environment and bind itself to the desired MTP 3 SAPs:

1. Call ctaInitialize (once per application) to initialize the Natural Access environment.

2. Create one or more Natural Access queues.

3. Create one Natural Access context per SAP and associate it with the appropriate queue.

4. Open the MTP 3 service, binding the user application to the specified
   MTP 3 SAP and associating that SAP with a Natural Access context and queue (done once for each context used by the application).
   Note: These steps are described in detail in Chapter 3.

2.10 Data Transfer

MTP 3 is a connectionless protocol. Therefore, once an application has bound to the MTP 3 layer, it may begin sending data. This is accomplished with MTP3SendData. This call may succeed or fail immediately. If the call succeeds there may be a future status indication denoting that the message could not be delivered. Refer to Section 2.11, Status Indications, for more information. There is no future indication that the message was transferred successfully.

Figure 9. Sending data

Asynchronous notification and polling are two methods for an application to receive incoming data and/or status indications. Status indications are covered in the next section but the following information applies to both data and status indications.

Polling requires the application to continually check for incoming messages by periodically calling MTP3RetrieveMessage. The application must make sure to call this function regularly to avoid excessive queuing of messages in the TX driver or the MTP 3 layer task. MTP3RetrieveMessage will return MTP3_NO_MSG until a message is available. It will return MTP3_SUCCESS when a message is available.

The following diagram shows the asynchronous notification method of receiving data:

Figure 10. Receiving Data (async notification)

2.11 Status Indications

Status indications may be received by an application through one of the receiving mechanisms described in the previous section. A status indication is sent to all applications when the corresponding network status changes. The possible status indications are described in the following table:

Status Indication	Description
StatPaused	Indicates that delivery to the specified destination point code is not currently possible. It can mean that there is no route configured for the destination point code or that all routes to that point code are currently unavailable. The StatPaused indication does not specify which of the above was the case.
StatResumed	Occurs after a StatPaused indication if one or more routes to a particular destination point code become available.
StatCongested	Indicates that delivery to the destination SP failed due to network congestion at some point along the route. This implies that the user part/application should reduce traffic to that destination.
StatCongestionEnds	Occurs after a StatCongested indication when network congestion has abated.
StatUsrUnavail	Indicates that the message was delivered to the remote MTP 3 layer but that no application was registered to receive data with the service information octet (SIO) contained in the message. For example, data was sent with an SIO indicating an ISUP message, but there was no ISUP application running at the destination. The remote MTP 3 layer has discarded the message.
StatRestart	Indicates that the local MTP 3 layer is going through a restart. This will be followed at some point by a StatRestartEnds. The application should not send any data messages after receiving this indication.
StatRestartEnds	Indicates that the local MTP 3 layer has completed its restart. The application may resume sending data messages.
StatPrimary	Indicates the local MTP 3 is the primary in a redundant configuration.
StatBackup	Indicates the local MTP 3 is the backup in a redundant configuration.
StatStandAlone	Indicates MTP is not in a redundant configuration.

2.12 Extended Status Indications

Extended status indications may be received by an application through one of the receiving mechanisms described in Section 2.10, Data Transfer. An extended status indication is sent to all applications registered to receive extended status indications when certain components of the MTP layer change state. Currently, MTP 2 links are the only components that support this feature. The possible extended status indications are described in the following table:

Ext. Status Indication	Description
XStatLinkUp	Indicates a link has finished aligning and is now available to the MTP 3 layer. This means traffic can now be carried over the available link.
XStatLinkDown	Indicates a link has gone out of service. The MTP 3 layer will now use other links, if available, to carry traffic.
XStatLinkInh	Indicates a link has become inhibited. Links become inhibited by management requests. The network (MTP layer) will never inhibit a link by itself, although it may uninhibit the link. An inhibited link is no longer used by the MTP 3 layer to carry traffic.
XStatLinkInhDen	Indicates an MTP 3 management entity attempted to inhibit a link, but the inhibition was denied. A possible cause would be that inhibiting the link would cause a destination to become inaccessible.
XStatLinkUninh	Indicates that a link has become uninhibited and is now available to the MTP 3 layer for carrying traffic. Links may be uninhibited by MTP 3 management entities or by the MTP 3 layer automatically.
XStatLinkUninhDen	Indicates the uninhibition of a link has been denied. This usually happens when the local MTP 3 layer is not able to negotiate the uninhibition of the link with the remote MTP layer. The link is still unavailable to the MTP 3 layer to carry traffic.
XStatLinkRemBlock	Indicates a link has become remotely blocked. This is a result of a processor outage on the remote side of the link. The link is no longer available to carry traffic.
XStatLinkRemUnblock	Indicates the link is no longer remotely blocked. The link is now available to carry traffic unless inhibited or locally blocked.
XStatLinkLocBlock	Indicates a link has become locally blocked. This is a result of a local processor outage. The link is no longer available to carry traffic.
XStatLinkLocUnblock	Indicates the link is no longer locally blocked. The link is now available to carry traffic unless inhibited or remotely blocked.

2.13 Congestion Control

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

MTP tracks and controls both inbound and outbound congestion. When outbound congestion occurs, upper layers that have bound to MTP are notified. This allows them to take some corrective action, such as reducing the traffic load that they generate, before the congestion becomes severe and impacts the operation of the service. In addition, MTP takes action on its own during both inbound and outbound congestion to assure that even a poorly behaved application or very high network traffic does not overwhelm normal operation.

In most places, MTP uses a 4-level congestion control strategy, where level 0 indicates that the destination is not congested and level 3 indicates the most congested state. This matches the ANSI standards.

2.13.1 Outbound Congestion

In MTP, there are two possible causes of outbound congestion:

• The user application generates MTP traffic at a rate greater than the capacity of the SS7 links or downstream network, resulting in network overload.

• The user application generates MTP requests faster than they can be processed by the MTP layer, resulting in the MTP API send queue building up beyond pre-determined thresholds.

Network Overload

Network overload occurs when the MTP layer's outbound queues build up beyond configured limits due to a traffic load which exceeds the capacity of the available signaling links, or due to receipt of a transfer controlled message (TFC) regarding a congested destination.

When outbound traffic is exceeding the total link capacity, transmission queues in the MTP 2 layer begin to build up. When the MTP 2 transmission queue for a link becomes full (layer 2 configuration parameter L2_TXQ_THRESH2), the MTP 3 layer ceases sending to the congested link. This causes MTP 3 queues to begin building up. There are four configurable levels at which congestion indications of that priority are generated. Defaults and the correct parameter names (in the LINK section in the MTP 3 configuration file) are displayed in the following table:

Parameter	Default
P0QUE_LENGTH	16
P1QUE_LENGTH	32
P2QUE_LENGTH	64
P3QUE_LENGTH	128

Note: These are MTP 3 queue levels in addition to the L2_TXQ_THRESH2 messages queued at layer 2.

Whether MTP 3's transmit queues have built due to network overload or a transfer controlled (TFC) was received about a remote destination, the user application is notified by receipt of an MTP status indication. This manifests itself as a Natural Access event MTP3EVN_DATA with a message code of MTP3_STAT_IND and status of StatCongested. This indication contains the affected pointed code and the current congestion level (0 to 3). The application should then reduce its traffic load toward the affected destination until the congestion abates.

In ANSI networks and in other national networks employing multiple congestion levels, the user 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 especially important for the user 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. Failure of the application to reduce its traffic load toward the congested destination may escalate the congestion condition.

When the network overload condition ceases, the user application receives a Natural Access event MTP3EVT_DATA with a message code of MTP3_STAT_IND and status of StatCongestionEnds, indicating that the application may resume normal traffic towards the affected destination.

MTP API Congestion

MTP 3 API congestion occurs when an application generates traffic faster than it can be accepted by the MTP layer, resulting in the MTP 3 API transmission queue building beyond pre-determined thresholds. This only applies to applications that use the MTP 3 API to communicate with MTP directly. The application is notified of API congestion by receipt of an MTP3EVN_CONGEST Natural Access event which includes the current MTP 3 congestion level (0 to 3, where 0 indicates that congestion has ceased). As the MTP 3 congestion level increases, the application is expected to reduce its traffic load proportionately until the congestion ceases.

By default, the MTP 3 API allocates a buffer pool for up to 256 requests to be queued to the MTP layer. If the application fails to reduce its traffic load enough to ease the congestion, eventually the MTP 3 API buffer pool will become depleted and the MTP 3 API send primitives will fail with a CTAERR_OUT_OF_MEMORY return code. The application can increase the number of buffers in the pool (allowing a larger burst of traffic to be absorbed without triggering congestion, at the cost of more host memory used) by setting service argument array element six to a number between 128 and 1024 when opening the MTP service (see Section 3.2.3). Congestion onset and abatement thresholds are always set to a fixed percentage of the buffers in use (queued to the MTP layer) regardless of the total size of the pool, as shown in the following table:

Congestion Level	Onset Threshold (to reach this level)	Abatement Threshold (to next lower level)
1	Greater than 75% of pool in use.	Less than 50% of pool in use.
2	Greater than 85% of pool in use.	Less than 80% of pool in use.
3	Greater than 95% of pool in use.	Less than 90% of pool in use.

2.13.2 Inbound Congestion

MTP inbound congestion is caused by the MTP user application not reading incoming messages as fast as they are being generated by the network, resulting in build-up of the user SAP queue and/or a depletion of the layer 1 limited pools used to receive incoming messages on each link.

Unlike outbound congestion, the MTP user application is not notified directly of inbound congestion level changes in order to prevent escalation of the congestion condition. However, an alarm is always generated when a change in an MTP user SAP's inbound congestion level occurs.

For inbound congestion, the MTP layer cannot rely on the user application to reduce its traffic load to ease the congestion, as the source of the traffic bursts is generally other network nodes. Instead, the MTP layer acts directly to control inbound congestion in two ways.

First, as the NSAP queues to upper layers build up, configurable thresholds are crossed which set the NSAP's congestion priority. For national networks, MTP discards inbound messages having a priority lower than the current NSAP congestion level. This ensures that a slow or dead upper layer cannot starve out other upper layers. No such discarding is done for international networks which have no message priorities. The limited pools will ensure that all board memory is not used up in that case, but a slow or dead upper layer could starve out other upper layers.

Second, once the level 1 limited pools reach a defined threshold of allocated buffers, MTP 2 will begin generating SIB's (Status Indication Busy) out that link. Enough buffers remain in the limited pool to handle an additional window of 127 messages after SIB's are started. These limited pools disallow a renegade link from using up all of MTP's memory.

There are four configurable levels at which discarding of lower priority national messages occurs. Defaults and the correct parameter names (in the NSAP section in the MTP 3 configuration file) are displayed in the following table:

Parameter	Default
P0QUE_LENGTH	0
P1QUE_LENGTH	512
P2QUE_LENGTH	798
P3QUE_LENGTH	896

For example, when there are 512 messages queued to an upper layer, the NSAP's congestion priority becomes 1 and thereafter national messages of priority 0 are discarded rather than being queued. Similarly, when the queue size reaches 798, messages of priority 0 and 1 are discarded.

The number of inbound messages discarded due to NSAP congestion can be determined with Mtp3NSapStatus or through the mtpmgr utility with the command Mtp3NSapStatus x.

2.13.3 Application Flow Control

An application that cannot keep up with incoming messages may use flow control to force queuing of messages in the lower layers until it can again accept incoming data. The use of MTP3Flow is used as shown in the following diagram:

Figure 11. Application Flow control

When flow control is in effect, messages build up in the MTP 3 NSAP queue and are handled as described in Section 2.13.2.