Understanding the Sigtran Protocol Suite

SS7 has been the tried and true signaling mechanism for providing signaling in traditional PSTN networks. But, with voice-over-IP (VoIP) becoming a more important technology for carriers, carriers are starting to look for more IP friendly signaling schemes to use in their network architectures.

Enter Sigtran. Developed by the Internet Engineering Task Force (IETF), the Sigtran protocol suite lets operators carry SS7 signaling traffic between a signaling gateway (SG) and a media gateway controller (MGC) or IP-enabled signaling control point (IP-SCP), thus allowing carriers to maintain their SS7 signaling schemes while being able to tap into the IP network for transport.

In this tutorial, we'll take a look at the key elements that make up the Sigtran protocol. During the discussion, we'll show how Sigtran's new transport protocol matches up with TCP. We'll also take a detailed look at each of Sigtran's user adaptation layers.

Sigtran Basics
Sigtran is a suite of networking protocols consisting of toshe stream control transport protocol (SCTP) and a set of user adaptation (UA) layers (which transform the look and feel of SCTP into the lower layers of SS7). The Sigtran architecture is shown in Figure 1.

Figure 1: Diagram illustrating the Sigtran layers.

Sigtran currently defines four SS7-related adaptation layers. These include:

1. The message transfer part level 2 user adaptation (M2UA) layer provides the services of MTP2 in a client-server situation, such as SG to MGC. Its user would be MTP3.
2. The message transfer part level 2 peer-to-peer adaptation (M2PA) layer provides the services of message transfer part level 2 (MTP2) in a peer-to-peer situation, such as SG-to-SG connections. Its user would be MTP3.
3. The message transfer part level 3 user adaptation (M3UA) layer provides the services of MTP3 in a client-server situation, such as SG to MGC. Its users would be SCCP and/or ISUP.
4. The SS7 SCCP user adaptation (SUA) layer provides the services of the signaling connection control part (SCCP) in a client-server architecture, such as SG-to-IP SCP. Its user would be TCAP, or another transaction-based application part.

There are other UA layers defined for ISDN (IUA) and V.5.2 (VUA). While important, these will not be covered in this article.

SCTP versus TCP
The stream control transport protocol (SCTP) is a new transport protocol defined by the Sigtran specification as a a replacement for TCP. SCTP is designed to cope with time-sensitive signaling data while remaining flexible enough for general use.

SCTP has been designed to counter some features of TCP that make it unsuitable for transporting real-time signaling data, such as:

• TCP is byte-streamed—TCP provides a single stream of data and guarantees that data to be delivered in byte-sequence order. This makes it ideal for delivery of large, unstructured pieces of data, such as a file or email message. TCP is particularly sensitive to delays caused by network errors cause by loss of bytes, messages or sequence violation. When this occurs, TCP will hold up delivery of all data (for all applications) until the correct sequence is restored. Because of this, data for one application may be delayed due to problems in transporting data from an unrelated application.
• TCP timers are defined in terms of many seconds. In particular, the length of the connection, keep alive, and retransmission timers may result in excessive delays.
• There are no inherent security features in TCP itself.

SCTP is very similar to TCP, but has a number of features which aim to overcome the limitations listed above. These include:

• It defines timers of much shorter duration than TCP.
• It supports multi-homing. Each SCTP endpoint may be known by multiple IP addresses. Routing to one address is independent of all others and, if one route becomes unavailable, another will be used.
• It uses an initialization procedure, based on cookies, to prevent denial of service attacks.
• It supports bundling, where a single SCTP message may contain multiple 'chunks' of data. Each chunk contains a whole signaling message.
• It supports fragmentation, where a single signaling message may be split into multiple SCTP messages in order to be accommodated within the underlying packet data unit (PDU).
• It is message-oriented, defining structured frames of data. TCP, conversely, imposes no structure on the transmitted stream of bytes.
• It has a multi streaming capability. Data is split into multiple streams, each with independent sequenced delivery. TCP has no such feature.

Multi-streaming is the main attraction. This feature allows users to partition a single IP connection between two endpoints into separate logical streams of data, assigning each stream to a particular application or resource. The principle is that errors or delays on one stream will not interfere with normal delivery on another.

Consider the example of SS7's ISDN user part (ISUP) protocol. ISUP carries signaling messages for many PSTN resources (essentially trunk circuits). If three calls are in progress, then one of the calls experiencing a loss of data should not cause a delay in transmission of messages relating to another call. Figure 2 shows a situation where ISUP is carried over TCP. A single 'pipe' of data carries all ISUP messages for all three calls.

Figure 2: Diagram illustrating the transport of three ISUP messages over a TCP link.

If the establishment messages for all three calls are received correctly, then the calls are in progress. If the calls are then released in the same order, but the release message for Call 1 is lost, then the release messages for the other two calls will be delayed while TCP recognizes the loss of the message and recovers the data. This has the potential to delay the release of Calls 2 and 3 for a large number of seconds, which is unacceptable in today PSTN world.

Consider now ISUP carried over SCTP. This is shown in Figure 3.

Figure 3: Diagram illustrating the delivery of ISUP messages over SCTP.

In this case, loss of a message relating to Call 1 affects only that stream of data. Calls 2 and 3 are serviced as normal.

The Four UA Layers
The Sigtran protocol defines four UA layers: the M2UA, M2PA, M3UA, and SUA. All four of these layers service a common purpose: to carry a higher layer's protocol messages from the point of termination in the SS7 network, over an IP network, to the point of presence of the higher layer itself.

Figure 4 is a generic depiction of where the UAs lie in the Sigtran architecture.

Figure 4: Diagram illustrating Sigtan's four UA layers.

The higher SS7 layer would be message transfer part level 3 (MTP3) or above (as described in the following sections) and would reside on either an MGC or an IP-SCP. The purpose of the Nodal Interworking Function (NIF) is defined by the UA in use. In general, it provides a mapping of management, data and control messages from the UA to the specific lower SS7 layer.

Let's take a look at each of the four user layers in more detail. We'll start with the M2UA layer.

1. The M2UA Layer
M2UA is used to transfer MTP2 user data between the MTP2 instance on a SG and the MTP3 instance on an MGC. As such, it operates a client-server model, where the MGC is the client and the SG is the server.

M2UA provides a means by which an MTP2 service may be provided on an MGC—in essence, extending SS7 into the IP network. Effectively, the MTP3 instance on the MGC is the user of the MTP2 instance on the SG. Neither MTP2 nor MTP3 are aware that they are remote from one another. This process, by which signaling messages are passed over IP from the top of one SS7 layer to the bottom of another, is described as backhauling.

The MTP3 user at the MGC would usually be ISUP. This architecture is most applicable when there is a low density of SS7 links at a particular physical point in the network (perhaps as low as one) and when there are a large number of physically separate SG functions (due to the SS7 links being physically located remotely from each other).

In this case, it makes sense to host MTP3 in the MGC. The SS7 address (the pointcode) of the system resides with MTP3. If each SG had its own MTP3 layer, a large number of pointcodes would be required to implement a (logically) single gateway.

2. The M2PA Layer
M2PA is the peer-to-peer equivalent of M2UA. Rather than provide a link between remotely located MTP2 and MTP3 instances, it replaces an MTP2 link beneath MTP3. The user of M2PA is MTP3 at both ends of the connection (with M2UA, one user is MTP3 and the other is an SG IWF). This is not typical of the overview given in Figure 4.

M2PA provides a means for peer MTP3 layers in SGs to communicate directly. In essence, it extends the reach of SS7 over the IP network.

The M2PA architecture is most applicable for a SG-to-SG connection, used to bridge two SS7 network 'islands'. In this case, each SG may connect to multiple other SGs, none of which need to know about the upper layer that they are supporting.

MTP3 is present on each SG to provide routing and management of the MTP2/M2PA links. Because of the presence of MTP3, each SG would require its own SS7 pointcode.

Replacing MTP2 links with M2UA is a distinct case from accessing an IP-SCP from an SG (the service provided by SUA). In the SUA case, it is known that the higher layer is TCAP and the SCCP services can be explicitly provided. M2PA, on the other hand, has no knowledge of the upper SS7 layer.

3. The M3UA Layer
M3UA is similar to M2UA, in that it operates in a client-server way to provide an upper layer SS7 with protocol remote access to the lower layers. M3UA, however, operates between an SG and an MGC, providing an MTP3 service on the MGC.

The MTP3 in the SG is unaware that the user is located on a different node. Similarly, the user layer at the MGC will be unaware that it is not served by a local MTP3. This is another example of the MGC backhauling signaling messages from the SG.

This architecture is most appropriate when there is a high enough density of SS7 links to make a standalone SG viable. It is also useful when the SS7 links are physically accessible at a single point.

Both situations highlighted in the paragraph above are common in North American networks, where the SS7 links are physically separate from the voice circuits. In this case, a number of links are gathered together into a single physical medium (for example, a T1 line). Here, each SG has a local MTP3 instance, and so must have its own SS7 pointcode.

4. The SUA Layer
SUA provides a means by which an application part (such as transaction application capabilities part [TCAP]) on an IP-SCP may be reached via an SG. The network architecture associated with SUA allows for multiple IP-SCPs to be reached via a single SG. The IP-SCP(s) do not have local MTP3 instances, and so do not require their own SS7 pointcodes (MTP3, and the pointcode, reside on the SG).

The functionality of SUA could be provided by M2UA or M3UA. However, SUA provides the mapping between SCCP addresses and IP addresses (at the SG). Without such a function, SCCP would have to be present at each IP-SCP and the external SS7 network would require knowledge of each such SCCP instance. SUA can abstract the presence of each IP SCP, thus providing one SCCP address to cover all nodes.

SUA is also flexible enough to support application parts running between two network nodes wholly within the IP network. This is particularly relevant to emerging networks, where there may be no need for an underlying 'traditional' SS7 network. In this case, the IP-SCP stack would be the same on both (IP based) nodes.

sigtran

SIGTRAN (SS7 over IP)

Common Channel Signaling System #7 (SS7) transports SS7 messages over an SS7 network (normally a DS0A connection) and then there is SIGTRAN. SIGTRAN is a set of protocols defined to transport SS7 messages over IP networks. SIGTRAN allows IP networks to inter-work with the Public Switched Telephone Network (PSTN) and vice versa.

Notes: There are two other IETF standards which define transport of PSTN signaling (non-SS7) over IP networks: ISDN User Adaption (IUA) which provides adaption at the Q.921 layer to allow transparent transport of Q.931 messages to, say, a VoIP gateway. IUA is defined by RFC4233. V5.2 User Adaption (V5UA) which provides for the transport of ETSI standard V5.2 messages in an IP network by adaption at the LAPV5 level. V5UA is defined by RFC3807.

The SIGTRAN Protocol Stack, RFC 2719

The SIGTRAN protocol stack consists of 3 components:

• A standard IP layer.
• A common signaling transport protocol, Stream Control Transmission Protocol (SCTP): SCTP provides connection oriented reliable transfer of user messages between peer SCTP users (Adaptation layer protocols). Note: The SCTP layer replaces a normal TCP/UDP layer.
• An Adaptation layer: Protocols defined for this layer are M2PA, M2UA, M3UA, and SUA.

Figure 1: SIGTRAN Protocol Stack Model

SCTP (Stream Control Transmission Protocol)

SCTP is designed to transport SS7 signaling messages over IP networks. It operates directly on top of IP at the same level as TCP. SCTP's basic service is connection oriented reliable transfer of messages between peer SCTP users. SCTP offers the following services (not exhaustive) that may be used by SIGTRAN:

• Multi-homing: is the ability of an association (that is, a connection) to support multiple IP addresses or interfaces at a given end point. In case of network failures, use of more than one address can allow re-routing of packets, and also provide an alternate path for retransmissions. End-points exchange lists of addresses during initiation of the connection. One address is designated as the primary address to receive data. A single IP port number is used across the entire address list at an endpoint for a specific session.
• Multi-streaming (Chunking): Allows for multiple virtual connections on the same physical line. Each user application might be assigned its own stream (virtual connection). SCTP's multi-streaming allows data to be delivered in multiple, independent streams, so that if there is data loss in one stream, delivery will not be affected for the other streams. The SCTP user can specify at startup time the number of streams to be supported by the association.
• Sequenced Delivery: Allows for messages to be delivered in the order in which there was sent.
• Block-Level: Unlike TCP in which transmission is viewed as a continuous stream of data, SCTP transmits blocks.
• Self-Fragmentation: SCTP uses MTU path discovery to ensure that messages are not fragmented by intermediate nodes.
• Heart-Beat: SCTP uses periodic heart-beat messages to confirm the status of each end point.

Adaptation Layer / SCTP Boundary

Primitives for this interface are defined in the RFC 2960, Section 10.

M2PA (MTP2 Peer-to-Peer Adaptation Layer)

MP2A is a protocol which supports the transport of SS7 MTP3 signaling messages over IP using the services of the SCTP. M2PA operates similarly to MTP2 so as to provide peer-to-peer communication between SS7 endpoints. M2PA extends the SS7 network into the IP network in a manner transparent to the SS7 network. Because the MTP3 layer (which routes on point codes) is present in all Signaling Points each IPSP requires a point code.

Figure 1 - M2PA Adaption Layer

SEP = Signaling End Point (for example, an SSP)
IPSP = IP Signaling Point
SG = Signaling Gateway

Notes:

1. MTP3, which is preserved in every IPSP with M2PA, uses Point Codes as its address mechanism and thus all IPSP require a Point Code.
2. The term UL (Upper Layer) has been used to indicate any layer which runs over TCAP, for example, MAP.
3. With M2PA the SG may act as an STP simply routing messages (based on Point Codes) from the SS7 network to the IPSP (IP Signaling Point).
4. In essence M2PA adaption allows SS7 functionality to be located within an IP network.
5. The Signaling Gateway (SG) will be a fully function SS7 SP and therefore can have any SS7 functionality such as SCP, STP or SSP.
6. If ISUP is supported by any IPSP then it would be acting as a SSP and have a VoIP stack, such as SIP, which is not shown to keep the diagram simple.
7. Other STPs may be present in the path between the SEP (SSP) and the SG.
8. M2PA allows for one or more IPSP in the network. Each IPSP must have its own point code.
9. M2PA can transport any MTP3 user messages, for example, SCCP and ISUP).
10. M2PA supports all primitives between MTP3 and MTP2 and is essentially transparent to MTP3.
11. M2PA provides MTP2 functionality that is not provided by SCTP, so that together M2PA and SCTP provide functionality similar to that of MTP2.

Definition of the M2PA / MTP3 boundary

The primitives are described in Q.703, Q.704, T1.111, and Q.2140. These are the same primitives that define the MTP2/MTP3 boundary.

M2PA receives the primitives sent from MTP3 to its lower layer. M2PA processes these primitives or maps them to appropriate primitives at the M2PA/SCTP interface. Likewise, M2PA sends primitives to MTP3 like those used in the MTP3/MTP2 interface.

M2UA (MTP2 User Adaptation Layer)

M2UA is a protocol for the backhauling of SS7 MTP3 messages over IP using the services of SCTP. This protocol is used between a Signaling Gateway (SG) and a Media Gateway Controller (MGC) such as a VoIP gateway but it could equally well be SCP.

Figure 2 - M2UA Adaption Layer

SEP = Signaling End Point (An SSP)
SG = Signaling Gateway
NIF = Nodal Inter-working Function
IPSP = IP Signaling Point
MGC = Media Gateway Controller: A device that converts from one protocol to another.

Notes:

1. With M2UA the SG functions as a transparent relay that converts SS7 messages to IP format.
2. All SPs in the SS7 domain have Point codes. Only the MGC (IPSP) in the IP domain has a Point Code (it has an MTP3 layer). The SG does not have a Point Code (since it has no MTP3 Layer).
3. Other STPs may be present in the SS7 path between the SEP and the SG.
4. The SG cannot have upper ISUP/SCCP layers because it has no MTP3 layer
5. The Nodal Inter-working Function (NIF) simply accepts messages from the MTP2 layer and writes them to the M2Ua layer. It is a 'glue' layer and its functionality is not defined by the standards.
6. With M2UA the IPSP's MPT3 uses the SG's MPT2 as its lower SS7 layer. Both MTP2 on the SG and MTP3 on IP signaling point remain unaware of the fact that their upper and lower layer respectively is not running locally.
7. The whole IP network is represented by a single point code that addresses the MGC at the network edge. Therefore all messages from the SS7 side going to the IP side are sent to the MGC through the SG. The MGC converts from the M2UA protocol to another protocol (such as SIP or Megaco) and vice versa.
8. M2UA allows for only one IPSP (MGC) in the network.
9. Any messages that arrive at the SG, from the IP domain or SS7 domain are simply relayed to the SS7 or IP domain respectively.
10. While Figure 2 shows a SIP stack this would only be present is the IPSP were providing VoIP gateway functionality in the case of an SCP this function would not be present.

Definition of the M2UA / MTP3 boundary

Q.703, Q.704, Q.2140 ITU Recommendations

1. DATA
2. ESTABLISH
3. RELEASE
4. STATE
5. DATA RETRIEVAL
6. DATA RETRIEVAL COMPLETE

Definition of the M2UA / MTP2 boundary

Q.703, Q.704, Q.2140 ITU Recommendations

1. DATA
2. ESTABLISH
3. RELEASE
4. STATE
5. DATA RETRIEVAL
6. DATA RETRIEVAL COMPLETE

M2PA and M2UA Compared

M2PA and M2UA similarities:

1. Both transport MTP3 messages.
2. Both present an MTP2 upper interface to MTP3.

M2PA and M2UA differences:

1. M2PA: IPSP processes MTP3-to-MTP2 primitives.
   M2UA: IPSP transports MTP3-to-MTP2 primitives between the SG's MTP2 and the IPSP's MTP3 (via the interworking function) for processing.
2. M2PA: SG is an SS7 node with a point code.
   M2UA: SG is not an SS7 node and has no point code.
3. M2PA: SG can have upper SS7 layers, e.g., SCCP.
   M2UA: SG does not have upper SS7 layers since it has no MTP3.
4. M2PA: may have one or more IPSPs.
   M2UA: can only have one IPSP.
5. M2PA: SG can route to other SPs, perform Global Title Translation as well as provide application layer services.
   M2UA: SG's single function is to relay MTP3 messages.

M3UA (MTP 3 User Adaptation Layer)

M3UA supports the transport of any SS7 MTP3-User signaling (for example, ISUP and SCCP messages) to an IP Signaling Point (IPSP) using the services of SCTP. M3UA is IP aware in that it translates the contents of the incoming SS7 MSU using a Routing Key (a glorified routing table) to map to the relevant IP address.

When using M3UA, IPSPs (ASs) may, or may not, require point codes depending on the application. If the application uses, say, SCP functionality then the SSN may be used to address the required IPSP without any need for Point Codes. Alternatively if the application is a VoIP gateway (an SSP) whose point code is visible within the SS7 network then clearly a point code is required at the IPSP (AS).

NIF = Nodal Inter-working Function
SEP = Signaling End Point (SSP)

Figure 3 - M3UA Adaption Layer

Notes:

1. The SS7 SG in the M3UA scenario functions as an STP and can provide SCCP based services which could include Global Title Translation which may cause redirection to either the SS7 or IP network.
2. The SS7 SPs and the SG have Point Codes. The IPSPs may, or may not, have Point Codes depended on the supported application(s). If the supported applications are entirely SCP-oriented then message routing may be done within the IP network based on the SSN (and/or Transaction ID) in which case no Point Codes are required for IPSP functioning as SCPs. If the application(s) being supported use ISUP (for example, a VoIP gateway) and the end point is visible to the SS7 network then point codes are required for each IPSP functioning in this manner.
3. MTP3 and M3UA both provide routing capabilities. MTP3 routes from point code to point code. M3UA maps and routes point codes to IP addresses and vice versa using a Routing Key.
4. The Nodal Inter-working Function (NIF) (not defined by the standards) allows messages to be routed to a local SCCP based service, such as Global Title Translation, or to an IPSP based on the Routing Key.
5. When a message arrives at the SG, MTP3 or M3UA examines the DPC/OPC or the SIO/DPC/OPC set and routes the message via the NIF to the appropriate location. If the DPC is the same as the SG's Point Code, the message is sent to the layer above. If the DPC differs from the SG's Point code, the message is routed by the SG to its proper destination via the NIF.
6. ISUP messages are always routed by the SG; they can never be destined for the SG (or any STP).
7. An ISUP message from the SS7 network destined for the IP network is sent by the SG's MTP3 to the local M3UA via the NIF. M3UA then routes the message to the appropriate IPSP. Similarly, an ISUP message from the SS7 network destined for the IP domain is sent by the SG's M3UA to the local MTP3 also via the NIF. MTP3 routes the message back to the origination SP.
8. In the SG, if the result of an application request or a GTT yields an SCP address located in the SS7 domain or the IP domain, the resulting request is sent to the local MTP3 or M3UA respectively for proper routing.
9. M3UA provides functionality similar to MTP3 but routing is IP aware through the use of the Routing Key.

Boundary between M3UA and an MTP3-User (ISUP /SCCP)
From ITU Q.701:

• MTP-TRANSFER request
• MTP-TRANSFER indication
• MTP-PAUSE indication
• MTP-RESUME indication
• MTP-STATUS indication

SUA (SCCP-User Adaptation Layer)

SUA defines a protocol for the transport of any SS7 SCCP-user signaling message such as TCAP, RANAP or MAP over IP using SCTP services.

NIF = Nodal Inter-working Function
SEP = Signaling End Point (SCP)
MGC = Media Gateway Controller

Figure 4 - SCCP User Adaption Layer (SUA)

Notes:

1. SUA can only transport SCCP-User messages
2. The SS7 SP and the SG both have Point Codes. The IPSPs do not require point codes.
3. SUA cannot support ISUP and thus the IPSP cannot be an SSP.
4. SCCP and SUA layers interface at the SG
5. The NIF is not defined by the standards and acts as an intelligent router from UL's to either the SCCP or SUA.
6. It is assumed that using the Global Title, SSN (and/or Transaction IDs) the messages can be routed to one or more IPSPs which thus do not require point codes.
7. SG can either act as an end point (SCP) or an STP
8. Together with SCTP, SUA replaces SCCP & MTP.

Definition of SUA/SCCP the Boundary

Recommendation: ITU Q.711

SUA and M3UA Comparison

In general, the protocol stack based on SUA is less complex compared to the protocol stack based on SCCP and M3UA. SUA can enhance the efficiency of the network and provides a means for simpler implementations.

M3UA and SUA Differences:

1. M3UA: Needs the SCCP services.
   SUA: Does not need SCCP services, reducing the complexity of the node and thereby reducing cost.
2. M3UA: Supports ISUP services.
   SUA: Cannot support ISUP services.
3. M3UA: Each IP node is required to have a point code and an IP address.
   SUA: Each IP node does not require a point code.
4. M3UA: Messages are handled from point code to point code.
   SUA: Allows the IP network to route the messages using global title information or SSN.

Sigtran Protocols

M2PA (MTP2-User Peer-to-Peer Adaptation Layer)

The M2PA protocol supports the transport of Signaling System Number 7 (SS7) Message Transfer Part (MTP) Level 3 signaling messages over Internet Protocol (IP) using the services of the Stream Control Transmission Protocol (SCTP). M2PA is also used between SS7 Signaling Points using the MTP Level 3 protocol. The SS7 Signaling Points may also use standard SS7 links using the SS7 MTP Level 2 to provide transport of MTP Level 3 signaling messages.

There is a need for Switched Circuit Network (SCN) signaling protocol delivery over an IP network. This includes message transfer between the following:

• A Signaling Gateway (SG) and a Media Gateway Controller (MGC)
• A SG and an IP Signaling Point (IPSP)
• An IPSP and an IPSP

This could allow for convergence of some signaling and data networks. SCN signaling nodes would have access to databases and other devices in the IP network domain that do not use SS7 signaling links. Likewise, IP telephony applications would have access to SS7 services. There may also be operational cost and performance advantages when traditional signaling links are replaced by IP network "connections".

The delivery mechanism described here allows for full MTP3 message handling and network management capabilities between any two SS7 nodes, communicating over an IP network. An SS7 node equipped with an IP network connection is called an IP Signaling Point (IPSP). The IPSPs function as traditional SS7 nodes using the IP network instead of SS7 links.

The delivery mechanism supports:

• Seamless operation of MTP3 protocol peers over an IP network connection.
• The MTP Level 2 / MTP Level 3 interface boundary.
• Management of SCTP transport associations and traffic instead of MTP2 Links.
• Asynchronous reporting of status changes to management.

The structure of the M2PA protocol header is as follows:

0										1										2										3
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Version								Spare								Message Class								Message Type
Message Length
unused								BSN
unused								FSN

Version
The version field contains the version of M2PA. The supported version is
1 - Release 1.0 of M2PA protocol.

Message Class
The only allowed value is 11 for M2PA Messages.

Message Type The following list contains the message types for the defined messages.
1 2	User Data Link Status

Message Length
The Message Length defines the length of the message in octets, including the Common Header.

BSN
Backward Sequence Number - This is the FSN of the message last received from the peer.

FSN
Forward Sequence Number -
This is the M2PA sequence number of the User Data message being sent.

 

M2UA

M2UA is used for backhauling of SS7 MTP2-User signalling messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol is used for communication between a Signalling Gateway (SG) and Media Gateway Controller (MGC). It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport. The SG acts as a Signalling Link Terminal.
The M2UA header structure is as follows:

0										1										2										3
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Version								Spare								Message class								Message type
Message length
M2UA header structure

Version
The version field contains the version of the M2UA adapation layer. The supported version is 1.0.

Spare
This field should be set to zero.

Message class The values for message class can be any of the following:
0 3 4 5	Management Messages (MGMT) ASP State Maintenance Messages (ASPSM) ASP Traffic Maintenance Messages (ASPTM) MTP2 User Adaptation Messages (MAUP)

Message type Management:
0 1	Error (ERR) Notify (NTFY)

ASP State Maintenance:
1 2 4 5	ASP Up (UP) ASP Down (DOWN) ASP Up Ack (UP ACK) ASP Down Ack (DOWN ACK)

ASP Traffic Maintenance:
1 2 3 4	ASP Active (ACTIVE) ASP Inactive (INACTIVE) ASP Active Ack (ACTIVE ACK) ASP Inactive Ack (INACTIVE ACK)

MTP2 User Adaptatation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15	Data Establish Request Establish Confirm Release Request Release Confirm Release Indication State Request State Confirm State Indication Data Retrieval Request Data Retrieval Confirm Data Retrieval Indication Data Retrieval Complete Indication Congestion Indication TTC Data

Message length
The message length defines the length of the message in octets (including the header) and includes parameter padding bytes (if there are any).

Variable-length parameter format
M2UA messages consist of a common header (described above) followed by zero or more variable-length parameters, as defined by the message type. The variable-length parameter format is as follows:

0										1										2										3
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Parameter tag																Parameter length
Parameter value
M2UA format of variable-length parameters

M3UA

M3UA supports the transport of any SS7 MTP3-User signalling (such as ISUP and SCCP messages) over IP, using the services of the Stream Control Transmission Protocol (SCTP). The protocol is used for communication between a Signalling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident database. It is assumed that the SG receives SS7 signalling over a standard SS7 interface using the SS7 Message Transfer Part (MTP) to provide transport.
The protocol consists of a common message header followed by parameters as defined by the message type.
The M3UA header structure is as follows:

0										1										2										3
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Parameter tag																Parameter length
Parameter value
M3UA header structure

Version
The version field contains the version of the M3UA adapation layer. The supported version is 1.0.

Reserved
This field should be set to zero.

Message class The values for Message class can be any of the following:
0 1 2 3 4 9	Management (MGMT) Transfer Messages SS7 Signalling Network Management (SSNM) ASP State Maintenance (ASPSM) ASP Traffic Maintenance (ASPTM) Routing Key Management (RKM)

Message type Management:
0 1	0 Error (ERR) 1 Notify (NTFY)
Transfer:
1	Payload Data (DATA)
SS7 Signalling Network Management:
1 2 3 4 5 6	Destination Unavailable (DUNA) Destination Available (DAVA) Destination State Audit (DAUD) SS7 Network Congestion State (SCON) Destination User Part Unavailable (DUPU) Destination Restricted (DRST)
ASP State Maintenance:
1 2 3 4 5 6	ASP Up (UP) ASP Down (DOWN) Heartbeat (BEAT) ASP Up Ack (UP ACK) ASP Down Ack (DOWN ACK) Heartbeat Ack (BEAT ACK)
ASP Traffic Maintenance:
1 2 3 4	ASP Active (ACTIVE) ASP Inactive (INACTIVE) ASP Active Ack (ACTIVE ACK) ASP Inactive Ack (INACTIVE ACK)
Routing Key Management:
1 2 3 4	Registration Request (REG REQ) Registration Response (REG RSP) Deregistration Request (DEREG REQ) Deregistration Response (DEREG RSP)

Message length
The message length defines the length of the message in octets, including the common header.

Variable-length parameters
M3UA messages consist of a common header followed by zero or more variable-length parameters, as defined by the message type. The format of variable-length parameters is as follows:

0										1										2										3
0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1	2	3	4	5	6	7	8	9	0	1
Version								Reverved								Message class								Message type
Message length
M3UA format of variable-length parameters

Parameter tag The Parameter tag identifies the type of parameter.

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Reserved Network Appearance Protocol Data 1 Protocol Data 2 Info String Affected Destinations Routing Context Diagnostic Information Heartbeat Data User/Cause Reason Traffic Mode Type Error Code Status Type/ID Congestion Indications Concerned Destination Routing Key Registration Result De-registration Result Local_Routing Key Identifier Destination Point Code Service Indicators Subsystem Numbers Originating Point Code List Circuit Range Registration Results De-registration Results

Parameter length
Parameter length indicates the size of the parameter in bytes. The length includes the Parameter Tag, Parameter Length and Parameter Value fields.

Parameter value
The value of the parameter.

SCTP

The Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signalling messages over IP networks, but is capable of broader applications. SCTP is an application-level datagram transfer protocol operating on top of an unreliable datagram service such as UDP. It offers the following services to its users:

• Acknowledged error-free non-duplicated transfer of user data.
• Application-level segmentation to conform to discovered MTU size.
• Sequenced delivery of user datagrams within multiple streams, with an option for order-of-arrival delivery of individual datagrams.
• Optional multiplexing of user datagrams into SCTP datagrams, subject to MTU size restrictions.
• Enhanced reliability through support of multi-homing at either or both ends of the association.

The design of SCTP includes appropriate congestion avoidance behaviour and resistance to flooding and masquerade attacks. The SCTP datagram is comprised of a common header and chunks. The chunks contain either control information or user data.

The following is the format of the SCTP header:

2 bytes	2 bytes
Source Port Number	Destination Port Number
Verification Tag
Adler 32 Checksum

Source Port Number
This is the SCTP sender's port number. It can be used by the receiver, in combination with the source IP Address, to identify the association to which this datagram belongs.

Destination Port Number
This is the SCTP port number to which this datagram is destined. The receiving host will use this port number to de-multiplex the SCTP datagram to the correct receiving endpoint/application.

Verification Tag
The receiver of this 32 bit datagram uses the Verification tag to identify the association. On transmit, the value of this Verification tag must be set to the value of the Initiate tag received from the peer endpoint during the association initialization.

For datagrams carrying the INIT chunk, the transmitter sets the Verification tag to all 0's. If the receiver receives a datagram with an all-zeros Verification tag field, it checks the Chunk ID immediately following the common header. If the chunk type is not INIT or SHUTDOWN ACK, the receiver drops the datagram. For datagrams carrying the SHUTDOWN-ACK chunk, the transmitter sets the Verification tag to the Initiate tag received from the peer endpoint during the association initialization, if known. Otherwise the Verification tag is set to all 0's.

Adler 32 Checksum
This field contains an Adler-32 checksum on this SCTP datagram

Chunk Field Descriptions

The following is the field format for the chunks transmitted in the SCTP datagram. Each chunk has a chunk ID field, a chunk specific Flag field, a Length field and a Value field.

1 byte	1 byte	2 bytes
Chunk ID	Chunk Flags	Chunk Length
Chunk Value (variable)

Chunk ID
The type of information contained in the chunk value field. The values of the chunk ID are defined as follows:

ID ValueChunk Type

00000000	Payload Data (DATA)
00000001	Initiation (INIT)
0000001	0Initiation Acknowledgment (INIT ACK)
00000011	Selective Acknowledgment (SACK)
00000100	Heartbeat Request (HEARTBEAT)
00000101	Heartbeat Acknowledgment (HEARTBEAT ACK)
00000110	Abort (ABORT)
00000111	Shutdown (SHUTDOWN)
00001000	Shutdown Acknowledgment (SHUTDOWN ACK)
00001001	Operation Error (ERROR)
00001010	State Cookie (COOKIE)
00001011	Cookie Acknowledgment (COOKIE ACK)
00001100	Reserved for Explicit Congestion Notification Echo (ECNE)
00001101	Reserved for Congestion Window Reduced (CWR)
00001110 to	11111101 - reserved by IETF
11111110	Vendor-specific Chunk Extensions
11111111	IETF-defined Chunk Extensions

Chunk Flags
The type of chunk flag as defined in the chunk ID defines whether these bits will be used. Their value is generally 0 unless otherwise specified.

Chunk Length
The size of the chunk in octets including the Chunk ID, Flags, Length and Value fields.

Chunk Value
This field contains the actual information to be transferred in the chunk. This is dependent on the chunk ID.

Chunk Types

Initiation (INIT)
This chunk is used to initiate a SCTP association between two endpoints. The INIT chunk contains the following parameters. Unless otherwise noted, each parameter is only be included once in the INIT chunk.

Fixed Parameters	Status
Initiate Tag	Mandatory
Receiver Window Credit	Mandatory
Number of Outbound Streams	Mandatory
Number of Inbound Streams	Mandatory
Initial TSN	Mandatory

Variable Parameters	Status
IPv4 Address/Port	Optional
IPv6 Address/Port	Optional
Cookie Preservative	Optional
Reserved For ECN Capable	Optional
Host Name Address	Optional
Supported Address Types	Optional

Initiate Acknowledgement (INIT ACK)
The INIT ACK chunk is used to acknowledge the initiation of a SCTP association. The parameter part of INIT ACK is formatted similarly to the INIT chunk. It uses two extra variable parameters: The Responder Cookie and the Unrecognized Parameter.

Selective Acknowledgement (SACK)
This chunk is sent to the remote endpoint to acknowledge received Data chunks and to inform the remote endpoint of gaps in the received subsequences of Data chunks as represented by their TSNs.
The selective acknowledgement chunk contains the highest consecutive TSN ACK and Rcv Window Credit (rwnd) parameters. By definition, the value of the highest consecutive TSN ACK parameter is the last TSN received at the time the Selective ACK is sent, before a break in the sequence of received TSNs occurs; the next TSN value following this one has not yet been received at the reporting end. This parameter therefore acknowledges receipt of all TSNs up to and including the value given.
The Selective ACK also contains zero or more fragment reports. Each fragment report acknowledges a sub-sequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by fragment reports are higher than the value of the Highest Consecutive TSN ACK.

Heartbeat Request (HEARTBEAT)
An endpoint should send this chunk to its peer endpoint of the current association to probe the reachability of a particular destination transport address defined in the present association. The parameter fields contain the time values.

Heartbeat Acknowledgement (HEARTBEAT ACK)
An endpoint should send this chunk to its peer endpoint as a response to a Heartbeat Request. The parameter field contains the time values.

Abort Association (ABORT)
The Abort Association chunk is sent to the peer of an association to terminate the association. The Abort chunk may contain cause parameters to inform the receiver the reason for the abort. Data chunks are not bundled with the abort, control chunks may be bundled with an abort, but must be placed before the abort in the SCTP datagram or they will be ignored.

SHUTDOWN
An endpoint in an association uses this chunk to initiate a graceful termination of the association with its peer.

Shutdown Acknowledgement (SHUTDOWN ACK)
This chunk is used to acknowledge the receipt of the SHUTDOWN chunk at the completion of the shutdown process. The SHUTDOWN ACK chunk has no parameters.

Operation Error (ERROR)
This chunk is sent to the other endpoint in the association to notify certain error conditions. It contains one or more error causes.

State Cookie (COOKIE)
This chunk is used only during the initialization of an association. It is sent by the initiator of an association to its peer to complete the initialization process. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same datagram.

Cookie Acknowledgement (COOKIE ACK)
This chunk is used only during the initialization of an association. It is used to acknowledge the receipt of a COOKIE chunk. This chunk precedes any Data chunk sent within the association, but may be bundled with one or more Data chunks in the same SCTP datagram.

Payload Data (DATA)
This contains the user data.

Vendor Specific Chunk Extensions
This chunk type is available to allow vendors to support their own extended data formats not defined by the IETF. It must not affect the operation of SCTP. Endpoints not equipped to interpret the vendor-specific chunk sent by a remote endpoint must ignore it. Endpoints that do not receive desired vendor specific information should make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.