SIGTRAN

SIGTRAN (Signaling Transport) is a working

group within the IETF Standard Organization.
The SigTran Working Group defined the
framework architecture and performance
requirements in RFC 2719
Main Network Elements (SS7-IP interface)
a.MG
b.MGC
c.SG

Internet Telephony

Internet Telephony

Sigtran Advantages
o
o
o
o
o

Ease of deployment
Less costly equipment
Better efficiency
Higher bandwidth
Enhanced Services

Internet Telephony

SIGTRAN Architecture RFC 2719

Signaling over standard IP uses a common

transport protocol that ensures reliable
signaling delivery.

Error-free and in-sequence

Stream Control Transmission Protocol (SCTP)

An adaptation layer is used to support specific

primitives as required by a particular signaling
application.

The standard SS7 applications (e.g., ISUP) do not

realize that the underlying transport is IP.

Internet Telephony

SIGTRAN Protocol Stack

SCTP: fast delivery of messages (error-free, in
sequence
delivery), network-level fault tolerance

Internet Telephony

Internet Telephony

Why SCTP? (SCTP RFC 2960)

To offer the fast transmission and

reliability required for signaling carrying.

SCTP provides a number of functions that are

critical for telephony signaling transport.

It can potentially benefit other applications needing

transport with additional performance and reliability.

SCTP must meet the Functional Requirements

of SIGTRAN.

Internet Telephony

Why not use TCP?

TCP provides both reliable data transfer and

strict order-of-transmission, but SS7 may not
need ordering.

TCP will cause delay for supporting order-oftransmission.

TCP parameters have large values and are not

tunable.
TCP is relatively vulnerable to DoS attack,
such as SYN attacks.
Internet Telephony

What Supported By Using SCTP?

To ensure reliable, error-free, in-sequence

delivery of user messages (optional).
To support fast delivery of messages and
avoid head-of-line blocking.
To support network-level fault tolerance that is
critical for carrier-grade network performance
by using multi-home hosts.
To provide protection against DoS attack by
using 4-way handshake and cookie.

Internet Telephony

SCTP Endpoint & Association

Endpoint

The logical sender/receiver of SCTP packets.

Transport address = IP address + SCTP port number
An endpoint may have multiple transport addresses
(for multi-homed host, all transport addresses must
use the same port number.)

Association

A protocol relationship between SCTP

endpoints.
Two SCTP endpoints MUST NOT have more
than one SCTP association.

Internet Telephony 10

Multi-Homed Host

Host A

Host B

SCTP User

SCTP User

SCTP

SCTP

One IP address

One IP address

One IP address

One SCTP association with

multi-homed redundant

Internet Telephony 11

SCTP Streams

A stream is a one-way logical channel

between SCTP endpoints.

The number of streams supported in an

association is specified during the
establishment of the association.

To avoid head-of-line blocking and to

ensure in-sequence delivery

In-sequence delivery is ensured within a

single stream.

Internet Telephony 12

SCTP Functional View

SCTP User Application

Association
startup
and
takedown

Sequenced delivery
within streams
User Data Fragmentation
Acknowledgement
and
Congestion Avoidance
Chunk Bundling
Packet Validation
Path Management

Internet Telephony 13

SCTP common header format

Internet Telephony 14

Chunk building

Internet Telephony 15

SCTP Packets & Chunks

A SCTP packet can comprise several

chunks.
Chunk

Common
Header

Data0 or control
. . .

15 16

Source Port Number

. . .

31

Destination Port Number

Verification Tag
Checksum

Chunk Type

Chunk Flags

Chunk Length

Chunk 1
Chunk Value

Chunk N

. . .
Internet Telephony 16

Chunk Type

ID Value
-------0
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Chunk Type
--------------- Payload Data (DATA)
- Initiation (INIT)
- Initiation Acknowledgement (INIT ACK)
- Selective Acknowledgement (SACK)
- Heartbeat Request (HEARTBEAT)
- Heartbeat Acknowledgement (HEARTBEAT ACK)
- Abort (ABORT)
- Shutdown (SHUTDOWN)
- Shutdown Acknowledgement (SHUTDOWN ACK)
- Operation Error (ERROR)
- State Cookie (COOKIE ECHO)
- Cookie Acknowledgement (COOKIE ACK)
- Reserved for Explicit Congestion Notification Echo (ECNE)
- Reserved for Congestion Window Reduced (CWR)
- Shutdown Complete (SHUTDOWN COMPLETE)
- Reserved for IETF
Internet Telephony 17

SCTP control chunks

INIT chunk

INIT ACK

Initiate an SCTP association between two

endpoints
Cannot share an SCTP packet with any other
chunk
Acknowledge the initiation
Must not share a packet with any other chunk

SACK

Acknowledge the receipt of Data chunks

Inform the sender of any gaps

Only the gaps need to be resent

Internet Telephony 18

HEARTBEAT

HEARTBEAT ACK

When no chunks need to be sent

Send periodic HEARTBEAT messages
Contain sender-specific information
Containing heartbeat information copied form
HEARTBEAT

ABORT

End an association abruptly

Cause information
Can be multiplexed with other SCTP control
chunks

Should be the last chunk, or

Internet Telephony 19

SHUTDOWN

A graceful termination of an association

Stop sending any new data
Wait until all data sent has been acknowledged
Send a SHUTDOWN to the far end

Upon receipt of a SHUTDOWN

Indicate the chunk received

Retransmit data that are not acknowledged
Send a SHUTDOWN ACK

SHUTDOWN ACK
SHUTDOWN COMPLETE
Internet Telephony 20

ERROR

Some error condition detected

COOKIE ECHO

Used only during the initiation of an association

An INIT ACK includes a cookie parameter
Information specific to the endpoint, a timestamp, a
cookie lifetime
Upon receipt of an INIT ACK

E.g., a chunk for a non-existent stream

Return the cookie information in COOKIE ECHO

Can be multiplexed; must be the first chunk

COOKIE ACK

Can be multiplexed; must be the first chunk

Internet Telephony 21

INIT Chunk
0

. . .
Type = 1

15 16

. . .

Chunk Flags

31

Chunk Length

Initial Tag
Advertised Receiver Window Credit (a_rwnd)
Number of Outbound Streams

Number of Inbound Streams

Initial TSN (Transmission Sequence Number)

Optional / Variable-Length Parameter
. . .

Internet Telephony 22

Association Establishment

INIT [I-Tag=Tag_A]

INIT ACK [V-Tag=Tag_A, I-Tag=Tag_Z,

Cookie_Z]
COOKIE [Cookie_Z]

COOKIE ACK

allocating
resources
Internet Telephony 23

User Data Transfer

SCTP user

User
Messages

SCTP DATA Chunks

SCTP Control
Chunks

SCTP
packets
SCTP

Connectionless Packet Transfer Service (e.g.

IP)
Internet Telephony 24

DATA Chunk

. . .
Type = 0

15 16

. . .

Reserved U B E

31

Chunk Length

TSN
Stream ID = S

Stream Sequence Number = n

Payload Protocol ID

User Data (Sequence n of Stream S)

. . .

U : unordered
B : begin
E : end
Internet Telephony 25

Payload data chunk

Carry information to and from the ULP

U: unordered bit

B and E: beginning and end bits

The information should be passed to the ULP

without regard to sequencing
Segment a given user message

TSN: Transmission Sequence Number (32-bit)

Independent of any streams

Assigned by SCTP
An INIT has the same TSN as the first DATA chunk
TSN ++ for each new DATA chunk
Internet Telephony 26

S: Stream Identifier (16-bit)

n: stream sequence number (16-bit)

Begins at zero
Increments for each new message

Payload protocol identifier

For the users to pass further information about

the chunk but is not examined by the SCTP

Internet Telephony 27

SACK Chunk
0

. . .
Type = 3

15 16

Chunk Flags

. . .

31

Chunk Length

Cumulative TSN Ack

Advertised Receiver Window Credit (a_rwnd)
Number of Gap Ack Blocks
=n
Gap Ack Block #1 Start

Number of Duplicate TSNs = x

Gap Ack Block #1 End

. . .
Duplicate TSN #1

. . .

Internet Telephony 28

Transferring data

Reliable transfer
SACK chunk

Cumulative TSN

The number of Gap Ack Blocks

The highest TSN value received without any gaps

4
The number of fragments received after the
unbroken sequence
2

The number of duplicate TSNs

Internet Telephony 29

Gap Ack Block number 1 start

Gap Ack Block number 1 end

The offset of the first segment from the unbroken

sequence
3 (7-4)
The offset of the first segment from the unbroken
sequence
8 (8-4)

a_rwnd

The updated buffer space of the sender

Internet Telephony 30

Internet Telephony 31

SCTP Robustness

Robustness is a key characteristic of any

carrier-grade network.

INIT and INIT ACK chunks may optionally

include one or more IP addresses (a primary
address + several secondary addresses).

To handle a certain amount of failure in the network

without a significant reduction in quality

Multi-homes hosts

SCTP ensures that endpoint is aware of the

reachability of another endpoint through the
following mechanisms.

SACK chunks if DATA chunk have been sent

HEARTBEAT chunks if an association is idle

Internet Telephony 32

User Adaptation Layers

M2UA: SS7 MTP2 user adaptation layer (RFC

3331)
M2PA: SS7 MTP2 user peer-to-peer adaptation
layer (RFC 4165)
M3UA: SS7 MTP3 user adaptation layer (RFC
4666)
IUA: ISDN user adaptation layer (RFC 4233)
DUA: DPNSS/DASS 2 extensions to the IUA
protocol (RFC 4129)
V5UA: V5.2 user adaptation layer (RFC 3807)
SUA: signaling connection part user adaptation
layer (RFC 3868, Implementer's guide)
Internet Telephony 33

The
adaptation
layers
all serve
aa
To Sigtran
carry upper
layer Signaling
Protocols
over
number
of common
purposes:
reliable IP-based
transport.

To provide the same class of service offered at

the interface of the PSTN equivalent.
To be transparent: The user of the service
should be unaware that the adaptation layer
has replaced the original protocol (although
this is largely dependant on the
implementation).
To remove as much need for the lower SS7
layers as possible.

Internet Telephony 34

Transport Adaptation Layer

Interface (TALI)
Proprietary solution by Tekelec

RFC 3094
same functionality as M3UA and SUA
uses TCP as its transport layer.

Internet Telephony 35

M2UA

Transfer MTP2-user data

Extend SS7 into the IP network
Used for backhauling of signalling
messages.
provides an interface to a remote MTP2
service

Internet Telephony 36

There is a low density of SS7 links at a

This architecture is most applicable
particular physical point in the network
in (perhaps
the following
circumstances:
as low as one)
There are a large number of physically
separate SG functions (due to the SS7
links being physically located remotely
from each other)
The SG function is co-located with an
MG (usually due to one or more of the
previous conditions)

Internet Telephony 37

Internet Telephony 38

M2PA

Peer-to-peer equivalent of M2UA

replaces an MTP2 link beneath MTP3
extends the reach of SS7 over the IP
network
No interworking function architecture
most applicable for an SG to SG
connection
MTP3 is present on each SG to provide
routing and management
Can be considered as IP SS7 link
Internet Telephony 39

Provides an MTP2-like service itself

This means that M2PA is responsible for:
Link activation/deactivation (in response
to requests from MTP3)
Maintaining link status information
Maintaining sequence numbers and
retransmit buffers, for retrieval by MTP3
Maintaining local and remote processor
outage status

Internet Telephony 40

M2PA allows the classical SS7 link to be replaced by SS7 over IP

while maintaining the SS7 link topology.

Internet Telephony 41

Internet Telephony 42

Internet Telephony 43

Internet Telephony 44

Internet Telephony 45

M3UA

Transports MTP3 user message

extend the reach of SS7 into the IP
network.
maintain the MTP3-MTP3 user interface
across an SCTP connection.

Internet Telephony 46

This architecture is most appropriate

There is a high enough density of SS7
in the following circumstances:

links to make a standalone SG viable

The SS7 links are physically accessible at
a single point
These conditions 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.)
Internet Telephony 47

Internet Telephony 48

Internet Telephony 49

SUA

Transports SCCP users

Application part (such as TCAP) on an IP SCP
may be reached via an SG.
Multiple IP SCPs to be reached via a single
SG(IP SCPs do not require their own S7
pointcodes )
provides the mapping between SCCP addresses
and IP addresses (at the SG).
services of individual databases are addressed
via Subsystem Number (SSN).
Service Databases in the SS7 network can be
accessed from the IP network.
Internet Telephony 50

Internet Telephony 51

Internet Telephony 52

Internet Telephony 53

UAs in Detail

Internet Telephony 54

M3UA Operation

M3UA over SCTP

Application Server

A logical entity handling signaling for a

scope
A CA handles ISUP signaling for a SS7
DPC/OPC/CIC-range
An AS contains a set of Application Server
Processes (ASPs)

ASP

A process instance of an AS
Can be spread across multiple IP addresses
Active ASPs and standby ASPs
Internet Telephony 55

Routing Key

A set of SS7 parameters that identifies the

signaling for a given AS
OPC/DPC/CIC-range

Network Appearance

A mechanism for separating signaling traffic

between an SG and an ASP
E.g., international signaling gateway

Internet Telephony 56

Signaling Network Architecture

No single point of failure

SGs should be set up at least in pairs

ASPs

A redundant or load-sharing configuration

Spread over different hosts

Point code

All ASPs and the connected SG share the same

PC

All ASPs share a PC != that of the SG

A single SS7 signaling endpoint

ASPs: a signaling endpoint; SG: an STP

A group of ASPs share a PC

Internet Telephony 57

Services Provided by M3UA

Offer the same primitives as offered by

MTP3

MTP-Transfer request
MTP-Transfer indication
MTP-Pause indication

MTP-Resume indication

Signaling to a particular destination should be

suspended
Signaling to a particular destination can resume

MTP-Status indication

Some change in the SS7 network

E.g., network congestion or a destination user part
becoming unavailable
Internet Telephony 58

Transferring application message

A CA sends an ISUP message

MTP-Transfer request
A SCTP DATA chunk
Transmitted to a SG
M3UA MTP3
To the SS7 network

Internet Telephony 59

M3UA Messages

Messages between peer M3UA entities

A header + the M3UA message content
The entities can communicate information
regarding the SS7 network

If a remote destination becomes unavailable

The SG becomes aware of this through SS7
signaling-network management messages
The SG pass M3UA messages to the CA
The ISUP application at the CA is made aware

MTP-Pause indication

Internet Telephony 60

Signaling Network Management

MSGs

S7ISO SS7 Network Isolation

When all links to the SS7 network have been lost

DUNA Destination Unavailable

Sent from the SG to all connected ASPs

Destination(s) within the SS7 network is not
available

DUNA is generated at the SG

Allocate 24 bits for each DPC

It determines from MTP3 network management
message

The M3UA of the ASP

Create MTP-Pause indication

Internet Telephony 61

DAVA - Destination Available

DAUD Destination State Audit

Sent from SG to all concerned ASPs

Mapped to the MTP-Resume indication
Sent from an ASP to an SG
To query the status of one or more destination
The SG responds with DAVA, DUNA, or SCON

SCON SS7 Network Congestion

Sent from the SG to ASPs

The route to an SS7 destination is congested
Mapped to the MTP-Status indication

Internet Telephony 62

DUPU Destination User Part Unavailable

Sent from the SG to ASPs

A given user part at a destination is not available
The DPC and the user part in question
Mapped to MTP-Status indication
Cause codes

DRST Destination Restricted

Sent from the SG to ASPs

One or more SS7 destinations are restricted from
The M3UA may use a different SG

Internet Telephony 63

ASP management

ASPUP ASP Up

ASPDN ASP Down

Used between M3UA peers

The adaptation layer is ready to receive
traffic or maintenance messages
An ASP is not ready

UP ACK ASP Up Ack

DOWN ACK ASP Down Ack

Internet Telephony 64

ASPAC ASP Active

Sent by an ASP
Indicate that it is ready to be used
To receive all messages or in a load-sharing
mode
Routing context

Indicate the scope is applicable to the ASP

DPC/OPC/CIC-range

ASPIA ASP Inactive

ACTIVE ACK ASP Active Ack
INACTIVE ACK ASP Inactive Ack
Internet Telephony 65

BEAT Heartbeat

Between M3UA peers

Still available to each other
When M3UA use the services of SCTP

The BEAT message is not required at the M3UA level

ERR Error message

SCTP includes functions for reachability information

A received message with invalid contents

NFTY Notify

Between M3UA peers

To communicate the occurrence of certain
events
Internet Telephony 66

Routing Key Management

Messages

Registration Request (REG REQ)

An ASP = a DPC/OPC/CIC range

Registration Response
Deregistration Request
Deregistration Response

Internet Telephony 67

Adaptation Layer [3/3]

M3UA (MTP3-User Adaptation Layer)

SUA (SCCP-User Adaptation Layer)

Applications such as TCAP use the services of SUA.

IUA (ISDN Q.921-User Adaptation Layer)

V5UA (V5.2-User Adaptation Layer)

Internet Telephony

M2UA Operation

MTP3/M2UA/SCTP
The CA has more visibility of the SS7
network

MTP3

More tightly coupled to the SG

Routing and distribution capabilities

M2UA uses similar concepts to those used

by M3UA

ASPUP, ASPDN, ASPAC, ASPIA and ERR

Exactly the same functions
In M2UA, the ASP is an instance of MTP3
Internet Telephony 69

Adaptation Layer [1/3]

M2UA (MTP-2 User Adaptation Layer)

Internet Telephony 70

M2UA-specific messages

DATA

ESTABLISH REQUEST

To establish a link to the SG

ESTABLISH CONFIRMATION
RELEASE REQUEST

Carry an MTP2-user Protocol Data Unit

Request the SG to take a particular signaling link

out of service

RELEASE CONFIRM
RELEASE INDICATION

The SG autonomously take a link out of service

Internet Telephony 71

STATE REQUEST

Sent from a CA to the SG to cause the SG to

perform some action on a signaling link

STATE CONFIRM
STATE INDICATION

Link alignment, or flushing transmit buffers

The SG can autonomously send

During link changeover

The CA must retrieve certain information

from the SG
DATA RETRIEVAL REQUEST
DATA RETRIEVAL CONFIRM
DATA RETRIEVAL INDICATION
Internet Telephony 72

M2PA Operation

IP-based SS7 links

No FISUs sent; only LSSUs and MSUs
Establish SCTP associations between
M2PA peers

Two streams
One for MSU
The other for LSSU

Internet Telephony 73

Adaptation Layer [2/3]

M2PA (MTP-2 Peer-to-Peer Adaptation Layer)

An SG that utilizes M2PA is a signaling node for the

MGC.

It is effectively an IP-based STP.

SG can processing higher-layer signaling functions,

such as SCCP GTT.

Internet Telephony 74

More on M2UA and M2PA

M2UA
M2PA
Differences between M2UA and M2PA
Conclusion
References

Internet Telephony

Introduction (M2UA)

M2UA is a protocol for transporting SS7

MTP2-User signaling e.g., MTP3
messages over IP using the services of
the Stream Control Transmission
Protocol (SCTP).

The M2UA protocol is the layer between

SCTP and MTP3 that separates the
physical SS7 termination from the
actual signaling point within the
network.
Internet Telephony

M2UA Overview
M2UA deployments consist of 2 entities,
the client and the server.
The server provides physical SS7
termination and communicates with the
client over an SCTP association using IP.
The client houses the MTP3 and thus is
the point code addressable element
within the SS7 network.

Internet Telephony

M2UA in the SG to MGC

Application

Internet Telephony

Architecture of M2UA

Internet Telephony

Common Message Header

Internet Telephony

M2UA Message Header

Internet Telephony

Applications

M2UA serves several purposes.

The first purpose is to provide a
mechanism for the transport of SS7
MTP2 user signaling (e.g., MTP3
messages) over IP using SCTP.
The second purpose is to allow remote
placement of SS7 link terminations and
back haul SS7 traffic to a centralized
point in the network.

Internet Telephony

Services Provided by the

M2UA
Adaptation
Layer
The SS7 MTP3/MTP2(MTP2-User) interface is

retained at the termination point in the IP

network, so that the M2UA protocol layer is
required to provide the equivalent set of
services to its users as provided by the MTP
Level 2 to MTP Level 3.
Support for MTP Level 2 / MTP Level 3
interface boundary
Support for communication between Layer
Management modules on SG and MGC
Support for management of active
associations between SG and MGC
Internet Telephony

Functions Provided by the

M2UA
Layer
Mapping

Flow Control / Congestion

SCTP Stream Management
Seamless SS7 Network Management
Interworking
Active Association Control

Internet Telephony

Security

M2UA is designed to carry signaling

messages for telephony services. As such,
M2UA MUST involve the security needs of
several parties: the end users of the
services; the network providers and the
applications involved.
As a transport protocol, M2UA has the
following security objectives:
* Availability of reliable and timely user
data transport.
* Integrity of user data transport.
* Confidentiality of user data.
Internet Telephony

Threats
*
*
*
*

Blind Denial of Service Attacks

Flooding
Masquerade
Improper Monopolization of Services

When the network in which M2UA runs in

involves more than one party, it MAY NOT be
reasonable to expect that all parties have
implemented security in a sufficient manner.
In such a case, it is recommended that
IPSEC is used to ensure confidentiality of
user payload.
Internet Telephony

M2PA-Message Transport protocol peer-topeer adaptation layer

M2PA is the peer-to-peer equivalent of M2UA.

M2PA allows communication between SS7
systems over IP rather than T-1 or E-1 TDM
links.
An M2PA link may be used in place of an
MTP2 link, removing the need for dedicated
and expensive SS7 hardware.
The M2PA protocol is the layer between SCTP
and MTP Level 3.
M2PA provides a means for peer MTP3 layers
in SGs to communicate directly, it extends
the reach of SS7 over the IP network.

Internet Telephony

M2PA allows the classical SS7 link to be

replaced by SS7 over IP while
maintaining the SS7 link topology.

Role of M2PA in Evolution to SS7

over IP
Internet Telephony

Purpose of M2PA

Provides a mechanism for the transport

of SS7 MTP2 user signaling (e.g., MTP3
messages) over IP using SCTP.
Enables seamless operation between
MTP2 user peers in the SS7 and IP
space.

Internet Telephony

M2PA Symmetrical Peer-to-Peer

Architecture

Internet Telephony

M2PA Symmetrical Peer-to-Peer

Architecture

MTP3 is adapted to the SCTP layer using

M2PA.
All primitives between MTP3 and MTP2
are supported by M2PA.

Internet Telephony

Architecture of M2PA in a
Signaling Gateway

Internet Telephony

M2PA in IP Signaling Gateway

Internet Telephony

Architecture of M2PA in a
Signaling
Gateway
SG is an IPSP that is equipped with both

traditional SS7 and IP network connections.

Architecture is applicable for an SG to SG
connection, used to bridge SS7 network
islands.
SG and the IPSP communicate through an IP
link using the M2PA protocol. Messages sent
from the SEP to the IPSP (and vice versa) are
routed by the SG.
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 point code.
M2PA has no knowledge of the upper SS7 layer.

Internet Telephony

M2PA in IP Signaling Gateway

The IPSP's MTP3 uses its underlying

M2PA as a replacement for MTP2.
Communication between the two layers
MTP3/M2PA is defined by the same
primitives as in SS7 MTP3/MTP2.
M2PA uses the SCTP association as an
SS7 link. The M2PA/SCTP/IP stack can be
used in place of an MTP2/MTP1 stack.

Internet Telephony

Functions Provided by M2PA

MTP2 Functionality: M2PA provides MTP2

functionality that is not provided by SCTP;
thus, together M2PA and SCTP provide
functionality similar to that of MTP2.
SCTP provides reliable, sequenced delivery of
messages.
M2PA functionality includes:
Data retrieval to support the MTP3 changeover
procedure.
Reporting of link status changes to MTP3.
Processor outage procedure.
Link alignment procedure.
Internet Telephony

SCTP Association Management

SCTP allows a user-specified number of streams to be

opened during initialization.
Responsibility of M2PA to ensure proper management
of the streams.
M2PA uses two streams in each direction for each
association.
- Stream 0 is designated for Link Status messages.
- Stream 1 is designated for User Data messages, as
well as Link Status messages that must remain in
sequence with the User Data messages.
Separating results in M2PA to prioritize the messages
in a manner similar to MTP2.
Internet Telephony

M2PA Association State

Transition Diagram

Internet Telephony

Description of M2PA
Association
states
IDLE: State of the association during

power up initialization
ASSOCIATING: M2PA is attempting to
establish an SCTP association.
ESTABLISHED: SCTP association is
established.

Internet Telephony

M2PA Link State Control

M2PA link moves from one state to
another in response to various events.
The events that may result in a change
of state include:
- MTP3 primitive requests
- Receipt of messages from the peer
M2PA
- Expiration of timers
- SCTP notifications

Internet Telephony

M2PA Applications

Internet Telephony

M2PA Applications

M2PA used in SS7 offloading applications

Communication between node SEP1 and SEP2 is done via
two SGs. Both SEP1 and SEP2 are connected to two
different Signaling Gateways via SS7 interface. These
Signaling Gateways are connected to each other via
SIGTRAN (M2Pa + SCTP) and acts as STP Nodes.
Signaling messages from SEP1 and SEP2 are passed via
these two Signaling Gateways. This application can be
termed as SS7 offload.

M2PA used in IP based signaling points

In this case Signaling Points are connected to each other
using IP network. These IP based signaling points (IPSP)
uses M2PA links instead of MTP2 links. These IP bases
signaling points can also connect to signaling points in
SS7 network, via M2PA based Signaling Gateway.
Internet Telephony

Services provided by M2PA

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.
Also M2PA sends primitives to MTP3
similar to those used in the MTP3/MTP2
interface.

Internet Telephony

Types of messages

Message Signal Units (MSUs)

Link Status Signal Units (LSSUs)
Fill-In Signal Units (FISUs)

Internet Telephony

Types of messages (contd..)

MSUs originate at a higher level than MTP2, and are

destined for a peer at another node. M2PA passes these
messages from MTP3 to SCTP as data for transport across
a link. These are called User Data messages in M2PA.
LSSUs allow peer MTP2 layers to exchange status
information. Analogous messages are needed for M2PA.
The Link Status message serves this purpose.
FISUs are transmitted continuously when no other signal
units are waiting to be sent. FISUs also carry
acknowledgement of messages. Since an IP network is a
shared resource, it would be undesirable to have a
message type that is sent continuously as is the case with
FISUs. Furthermore, SCTP does not require its upper layer
to continuously transmit messages. Therefore, M2PA does
not provide a protocol data unit like the FISU. The M2PA
User Data message is used to carry acknowledgement of
messages. If M2PA needs to acknowledge a message, and
it has no MTP3 message of its own to send, an empty User
Data message can be sent.
Internet Telephony

SIGTRAN RFCs
o

Framework Architecture for Signaling Transport-RFC 2719

Stream Control Transmission Protocol-RFC 2960

ISDN Q.921-User Adaptation Layer-RFC 3057

Tekelec's Transport Adapter Layer Interface-RFC 3094

Stream Control Transmission Protocol Applicability Statement-RFC 3257

Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)-User Adaptation LayerRFC 3331

Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)-User Adaptation Layer

(M3UA)-RFC 3332

Security Considerations for Signaling Transport (SIGTRAN) Protocols-RFC 3788

Internet Telephony106

V5.2-User Adaptation Layer (V5UA)-RFC 3807

Signaling Connection Control Part User Adaptation Layer (SUA)-RFC 3868

Stream Control Transmission Protocol (SCTP) Management Information Base

(MIB)-RFC 3873

Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)-User Peer-to-Peer

Adaptation Layer (M2PA)-RFC 4165

Telephony Signaling Transport over Stream Control Transmission Protocol (SCTP)

Applicability Statement-RFC 4166

Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)-User Adaptation Layer

(M3UA)-RFC 4666

Stream Control Transmission Protocol-RFC 4960

Internet Telephony107

References

SS7 over IP Signalling Transport & SCTP from

http://www.iec.org
DRAFT NATIONAL STANDARDS FOR SIGTRAN No. SD/ SGT-01/01
DRAFT 2007 by DEPARTMENT OF TELECOMMUNICATIONS
TELECOMMUNICATION ENGINEERING CENTRE
Why is SCTP needed given TCP and UDP are widely available?
ISOC MEMBER BRIEFING #17 from http://www.isoc.org
SS7 by Travis Russel
Cisco Press, Signaling System No.7 SS7 C7 Protocol ,
Architecture and Services(2004)

Internet Telephony108