SIGTRAN PROTOCOLS

M2PA
M2UA
M3UA

MTP2 User Peer-to-Peer Adaptation Layer.

MTP2 User Adaptation Layer
MTP3 User Adaptation Layer

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

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
User Data
2
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

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
Management Messages (MGMT)
3
ASP State Maintenance Messages (ASPSM)
4
ASP Traffic Maintenance Messages (ASPTM)
5
MTP2 User Adaptation Messages (MAUP)

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

ASP State Maintenance:

1
ASP Up (UP)
2
ASP Down (DOWN)
4
ASP Up Ack (UP ACK)
5
ASP Down Ack (DOWN ACK)
ASP Traffic Maintenance:
1
ASP Active (ACTIVE)
2
ASP Inactive (INACTIVE)
3
ASP Active Ack (ACTIVE ACK)
4
ASP Inactive Ack (INACTIVE ACK)
MTP2 User Adaptatation:
1
Data
2
Establish Request
3
Establish Confirm
4
Release Request
5
Release Confirm
6
Release Indication
7
State Request
8
State Confirm
9
State Indication
10
Data Retrieval Request
11
Data Retrieval Confirm
12
Data Retrieval Indication
13
Data Retrieval Complete Indication
14
Congestion Indication
15
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

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 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
Management (MGMT)
1
Transfer Messages
2
SS7 Signalling Network Management (SSNM)
3
ASP State Maintenance (ASPSM)
4
ASP Traffic Maintenance (ASPTM)
9
Routing Key Management (RKM)

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

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
Reserved
1
Network Appearance
2
Protocol Data 1
3
Protocol Data 2
4
Info String
5
Affected Destinations
6
Routing Context
7
Diagnostic Information
8
Heartbeat Data
9
User/Cause
10
Reason
11
Traffic Mode Type
12
Error Code
13
Status Type/ID
14
Congestion Indications
15
Concerned Destination
16
Routing Key
17
Registration Result
18
De-registration Result
19
Local_Routing Key Identifier
20
Destination Point Code
21
Service Indicators
22
Subsystem Numbers
23
Originating Point Code List
24
Circuit Range
25
Registration Results
26
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 applicationlevel 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
00000001
0000001
00000011
00000100
00000101
00000110
00000111
00001000
00001001
00001010
00001011
00001100
00001101
00001110 to
11111110
11111111

Payload Data (DATA)

Initiation (INIT)
0Initiation Acknowledgment (INIT ACK)
Selective Acknowledgment (SACK)
Heartbeat Request (HEARTBEAT)
Heartbeat Acknowledgment (HEARTBEAT ACK)
Abort (ABORT)
Shutdown (SHUTDOWN)
Shutdown Acknowledgment (SHUTDOWN ACK)
Operation Error (ERROR)
State Cookie (COOKIE)
Cookie Acknowledgment (COOKIE ACK)
Reserved for Explicit Congestion Notification Echo (ECNE)
Reserved for Congestion Window Reduced (CWR)
11111101 - reserved by IETF
Vendor-specific Chunk Extensions
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
Initiate Tag
Receiver Window Credit
Number of Outbound Streams
Number of Inbound Streams
Initial TSN

Status
Mandatory
Mandatory
Mandatory
Mandatory
Mandatory

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

Status
Optional
Optional
Optional
Optional
Optional
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.