Signaling

Managing Signaling over SCTP/IP on Network
Level
USER GUIDE
3/1553-HSC 113 01/15-V4 Uen B

Copyright
© Ericsson GmbH 2018, 2019. All rights reserved. No part of this document may
be reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to
continued progress in methodology, design and manufacturing. Ericsson shall
have no liability for any error or damage of any kind resulting from the use of
this document.
Trademark List
All trademarks mentioned herein are the property of their respective owners.
These are shown in the document Trademark Information.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Contents
Contents
1 Revision Information 1
2 Overview 3
2.1 Scope 3
2.2 Introduction 3
2.2.1 Documentation Structure 3
3 General 5
3.1 Concepts 5
3.1.1 Application Server 5
3.1.2 Application Server Process 7
3.1.3 ESP 7
3.1.4 IP Load Balancing 8
3.1.5 IP-SEP 8
3.1.6 IPSP 8
3.1.7 Remote Host 8
3.1.8 Routing Context 8
3.1.9 Routing Key 8
4 Signaling over SCTP/IP Overview 9

4.1 IP Layer 12
4.2 SCTP Layer 13
4.3 Signaling over Adaptation Layers 15
4.3.1 Signaling over M3UA 15
4.3.2 Signaling over M2PA 21
4.3.3 PRA Signaling over IUA 22
4.4 GCP over SCTP 23
4.5 SGsAP over SCTP 24
4.6 Redundancy in the Signaling Network 25
4.6.1 Redundancy on IP and MPLS Level 25
4.6.2 Redundancy on SCTP Level 26
4.6.3 Redundancy on MTP3 over M2PA Level 27
4.6.4 Redundancy on M3UA Level 27
4.6.5 Redundancy on SCCP Level 28
4.6.6 Redundancy for SGsAP 28
4.6.7 IP to TDM/ATM Failover 29
4.6.8 Load Sharing 29
4.7 Infrastructure Overview 32
4.7.1 Traffic to or from SPXs and External Nodes 33
4.7.2 Traffic to or from MSC Blades and External Nodes 36
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Managing Signaling over SCTP/IP on Network Level
4.7.4 Signaling over M2PA 37

4.7.5 GCP over SCTP 38
4.7.6 Signaling over IUA 38
4.7.7 SGsAP over SCTP 38
4.8 M-MGw Overview 38
4.8.1 Signaling Architecture 38
4.8.3 Signaling over IUA 41
4.8.4 GCP over SCTP 41
5 Network Solution Implementation 43

5.1 Recommended Site and Network Structure 43
5.1.1 Ethernet and IP Connectivity 44
5.1.2 IP Redundancy, Path Diversity and Addressing 45
5.2 IP Backbone Recommendations 50
5.2.1 Network Separation 50
5.2.2 Path Diversity 50
5.2.3 Transport Requirements 51
5.2.4 Traffic Prioritization 52
6 How to Use 53
6.1 SCTP Parameter Settings 53
6.1.1 Parameters for Path Handling 53
6.1.2 Timers and Counters for Path Handling 55
6.1.3 Buffers and Windows 60
6.1.4 Protocol Data Unit 63
6.1.5 Number of Streams 64
6.1.6 SCTP Bundling 65
6.1.7 Zero Receiver Window Supervision 65
6.1.8 Tailoring of SCTP Parameters 66
6.2 Network Configuration Examples 73
6.2.1 Configuration in M3UA Network 73
6.2.2 IP-STP in SPX Connectivity 78
Glossary 83
Reference List 89
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Revision Information
1 Revision Information
Changes in MSC-S 18.1

This document is based on User Guide Managing Signaling over SCTP/IP on
Network Level, 3/1553-HSC 113 01/14-V4 Uen Uen Rev. D.
This document has been revised as follows:

— Rev. B
• Editorial changes only.
— Rev. A
Changes in MSC-S 18A

This document is based on User Guide Signaling over SCTP/IP,
3/1553-HSC 113 01/13 Uen Rev A.

— Rev. D
• ‘‘Documentation Improvement’’:
Stream numbers for M2PA clarified.
MTP3 level functions dependency on 3GPP TS 29.202 clarified.
• Added sections: ‘‘Signaling over M2PA’’ and ‘‘IP-STP Connectivity’’
— Rev. C
• Added sections: ‘‘Signaling over M2PA’’ , ‘‘Redundancy on MTP3 over
M2PA Level’’, ‘‘Traffic to or from SPXs and External Nodes’’ and ‘‘Traffic
to or from MSC Blades and External Nodes’’
— Rev. B
— Rev. A
• Title change because of merging core network and node level CPI libraries.

This document is based on the User Guide for Signalling over SCTP/IP,
3/1553-HSC 113 01/11 Uen Rev C.
Other than editorial changes, this document has been revised as follows:
— Rev. A
• ‘‘System Improvement’’: Introduction of User Guide Managing the Stream
Control Transmission Protocol on MSC-S level.
• ‘‘System Improvement’’: Consolidation of Concepts section.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 1


This document is based on the User Guide for Signalling over SCTP/IP,
3/1553-HSC 113 01/10 Uen Rev A.

— Rev. C
— Rev. B
• Multi Application Support in BSP: MSC-S BC using BSP, Compact MSC-S,
and Compact IP-STP introduced.
• ‘‘System Improvement’’: Switchback modes recommendations are
modified (Section 6.1.1.2 on page 53).
• ‘‘System Improvement’’: RTO recommendations are modified (Section
6.1.2 on page 55).
• ‘‘System Improvement’’: ‘‘Zero Window Supervision’’ function introduced.
2 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Overview
2 Overview
2.1 Scope
This document provides guidance for the transport of Signaling over SCTP/IP
in CNCS.
The following aspects are out of the scope of this document:
— IP transport design (see User Guide Managing IP Transport in the Core

Network)
— Node dimensioning (see Description Core Network Design Guideline

Overview)
— Configuration of IuCS-Interface and A-Interface over IP (AoIP) (see

Description Core Network Design Guideline Overview)
2.2 Introduction
This document guides the reader through the network-level aspects of configuring
Signaling over SCTP/IP and provides network design guidelines.
Section 4 on page 9 describes the basics of Signaling over SCTP/IP using concrete
scenarios.
Section 5 on page 43 is dedicated to the connectivity aspects down to IP and

Ethernet layers.
Section 6 on page 53 describes SCTP parameter setting for fine-tuning to the IP

network characteristics and configuration examples.
By the time readers finish this document, they will have reached a good
understanding of the network level aspects. The next step is then to understand
the node level aspects for which this User Guide provides a rich reference list.
2.2.1 Documentation Structure

The list of most relevant documents is provided per level in Table 1.
Table 1 Documentation Overview

CNCS Level
User Guide Managing IP Transport in the Core Network
User Guide Managing Local Switching for Sites Connected over Satellite
Application Information List of IP Backbone Recommendations
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 3

CNCS Level
User Guide Managing and Optimizing SS7 Congestion Control and SIGTRAN
Performance
Description Core Network Overview
User Guide Managing Security on Core Network Level
User Guide Managing Primary Rate Access on Core Network Level
MSC-S Level
User Guide Managing IP Integration
User Guide Managing the Stream Control Transmission Protocol
User Guide MSC-S Configuration Management
User Guide Message Transfer Part 3 User Adaptation Layer
User Guide M3UA Relay (SPX specific document)
User Guide Message Transfer Part 2 User Peer-to-Peer Adaptation Layer
User Guide Primary Rate Access in MSC Server
User Guide Gateway Control Protocol over SCTP
User Guide SGs-Interface Configuration and Enabling of SMS over
SGs-Interface and LTE to CS Fallback
M-MGw Level
User Guide for Signalling, Reference [42]
User Guide for Physical Interfaces, Reference [40]
User Guide for Primary Rate Access, Reference [41]
User Guide for Virtual Media Gateway Handling, Reference [43]
4 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

General
3 General
3.1 Concepts
This section lists the concepts specific for this document. See Description Concepts
and Terminology on Circuit Switched Core Network Level, User Guide Message
Transfer Part 3 User Adaptation Layer, and User Guide for Signalling, Reference
[42], for other CN and SS7 over IP-related abbreviations.
The following concepts are described in the Concepts and Terminology on Circuit
Switched Core Network Level:
— Associated Signaling Mode
— Quasi-Associated Signaling Mode
— Signaling End Point
— Signaling Mode
— SS7-SEP
3.1.1 Application Server
3.1.1.1 M3UA Application Server
An M3UA Application Server (AS) is a logical entity in an IP-SEP that receives and
sends MTP3 User messages with an MTP routing label corresponding to a specific
Routing Key.
An IP-SEP can contain several ASs.
Figure 1 shows an IP-SEP with one AS.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 5

IP-SEP
AS
Application
M3UA
SCTP
IP
Figure 1 IP-SEP with One AS
Figure 2 shows a node with multiple ASs.
IP-SEP
AS 1 AS 2 AS N
Application Application Application
1 2 N
M3UA
SCTP
IP
Figure 2 IP-SEP with Many ASs
By an IP-SEP⇔IP-SEP communication scenario, where each IP-SEP behaves

over the SCTP Association as IP Server Process (IPSP), there are two ASs, one
defined on each of the peers as shown in Figure 3. These two ASs are defined by
mirrored Routing Keys and identical Routing Context values. Routing Keys and
Routing Context values must be configured statically in both peers.
6 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

General
IP-SEP 1 IP-SEP 2
AS 1 AS 2
Application Application
M3UA M3UA
SCTP SCTP
IP IP
Figure 3 ASs in IPSP-IPSP Configuration
In a distributed node architecture, an AS can be distributed over some IP-SEPs,

each of them hosting an instance of the AS (either Application Server Process
(ASP) or IPSP depending on the communication scenario), where one or many of
the instances are normally actively receiving and sending traffic.
An AS in an IP-SEP has similar functionality to an SS7-SEP in the SS7 terminology.
An AS in an IP-SEP is, for example, a switch element handling all call processing
for a signaling relation, identified by an SS7 Signaling Point Code (SPC). Another
example is a database element, handling all HLR transactions, which is identified
by a specific SS7 SPC.
By an IP-SEP⇔SGW communication scenario the AS data must be statically

configured in both the IP-SEP and SGW.
3.1.1.2 IUA AS
IUA AS is a logical entity serving a specific application. An example is an AS in a

node handling the Q.931 signaling and call processing for D-Channels terminated
by the SGW.
3.1.2 Application Server Process

An ASP is an IETF RFC 4666, Reference [47] compliant M3UA signaling process
which defines the behavior over an SCTP association of an AS in an IP-SEP⇔SGW
communication scenario.
3.1.3 ESP
An E-SIGTRAN Signaling Process (ESP) is a 3GPP TS 29.202, Reference [44],
compliant M3UA signaling process.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 7

3.1.4 IP Load Balancing
IP Load Balancing is a mechanism that allows a node to expose one or more virtual
IP addresses to external nodes, while enabling distributed node architecture
with multiple components sharing the virtual IP addresses for their external
connections. IP Load Balancing is only needed for distributed systems. The IP
Load Balancer (IPLB) distributes incoming IP datagrams to the application blades.
3.1.5 IP-SEP
An IP-SEP is a Signaling End Point (SEP) residing in the IP network, which uses
adaptation layer protocols such as M3UA and M2PA to transport application
signaling messages over SCTP.
By M3UA, a given IP-SEP can simultaneously behave as different signaling

process types (ASP, SGP, IPSP, and ESP) over the SCTP associations towards
its different M3UA peer nodes.
3.1.6 IPSP
An IPSP is an IETF RFC 4666, Reference [47] compliant M3UA signaling
process which defines the behavior over an SCTP association of an AS in an
IP-SEP⇔IP-SEP communication scenario.
3.1.7 Remote Host

A remote host is a managed object in the MSC-S which contains the Fully Qualified
Domain Name (FQDN) of a remote host, for example the FQDN of a remote MME
node.
3.1.8 Routing Context

Routing Context is a value that uniquely identifies an M3UA AS using an SCTP
association when the same association is serving several ASs.
The Routing Context is used to determine an M3UA AS for incoming MTP3 User
messages. Use of the Routing Context is mandatory when an SCTP association is
configured to carry traffic for multiple ASs.
3.1.9 Routing Key

A Routing Key is a set of SS7 parameters and parameter values that uniquely
define the portion of signaling traffic handled by a particular M3UA AS.
The Routing Key is used for routing MTP3 User messages in an SGW or IP-SEP.
8 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Signaling over SCTP/IP Overview
4 Signaling over SCTP/IP Overview
Signaling over SCTP/IP as described in this document is based on the framework

architecture described in IETF RFC 2719, Reference [45], the application of which
in a PLMN is described in 3GPP TS 29.202, Reference [44]. The Signaling over
SCTP/IP described in this document uses the SCTP protocol defined in IETF RFC
4960, Reference [46] as transport control protocol.
Signaling over SCTP/IP is implemented in several CN nodes in the CNCS. Figure

4 provides the logical relation between CNCS nodes and other nodes. See
Description Core Network Overview for further information.
SMS-SC/ gsmSCF
SCP HLR/AuC FNR LCS
SMS-C /CCN
INAP CAP
MAP
MME
SGsAP MAP, CAP, BSSAP,
BICC/ RANAP, ISUP, BICC and INAP
SGSN BSSAP+ ISUP
BSSAP STP/SGW/SRP
BSC MSC-S MSC-S
RANAP
RNC GCP ISUP

Q.931
PABX POI
M- M- ISUP
MGw MGw
CNCS Nodes VM
Figure 4 Signaling over SCTP/IP in CNCS
Signaling over SCTP/IP as described in this document covers what is commonly

referred to as SS7oIP (which in CNCS is the transport of BSSAP, RANAP, MAP,
CAP, ISUP, INAP, BSSAP+ and BICC SS7 Signaling Application Protocols over IP)
and the transport of Q.931, GCP, and SGsAP Signaling Application Protocols. In
the remainder of this document, the term Signaling over SCTP/IP is used to see
all these signaling protocols unless there is a need to address specific SS7oIP
aspects. The term Signaling over SCTP/IP used in this document does not cover
the complete spectrum of Signaling Application Protocols running over IP in
a CNCS network.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 9

External nodes such as HLR/AuC, FNR, LCS, gsmSCF/CCN, SCP, and SMS Center
which do not convey user plane traffic can be connected directly to the MSC-S
using TDM, ATM, or IP transport.
Nodes such as BSC, RNC, SGSN, Voicemail (VM), and POI which convey signaling
and user plane traffic over TDM or ATM are preferably connected to MSC-S
through the M-MGw that in this case acts as SGW. This has the advantage that
signaling and user plane traffic types are directed to the common M-MGw node
simplifying cabling and hardware used.
The MME as such can only be connected by IP.
One of the major benefits that Signaling over SCTP/IP offers, compared to TDM,
or ATM signaling, is that the available bandwidth is better utilized because it can
be accessed by all logical SCTP links and only when data packets are transmitted.
New high-speed IP interfaces connect the nodes directly to a site LAN or site
routers in the multi service IP network. Thanks to the bandwidth capabilities
of the IP interfaces, much less equipment needs to be deployed and signaling
capacity management is simplified.
The IP signaling terminals, in contrast to TDM or ATM signaling terminals,

are connected in a fully meshed topology, as shown in Figure 5, which allows
achieving the best connectivity and use of hardware resources. Moreover, the
same hardware can typically be shared by many Signaling Application Protocols.
Applications that use Signaling Protocols with high-bandwidth demands, such

as GCP, also benefit from Signaling over SCTP/IP because of less expensive IP
transport.
IP-SEP
IP-SEP M3UA
IP SGW ATM/TDM
IP-SEP
Figure 5 Fully Meshed M3UA Network Topology
A hierarchical structure can also be introduced within large networks for better
scalability. This means that any configuration changes in one SEP access segment
does not necessarily require reconfiguration in other SEP access segments.
Moreover, it can be used to centralize certain functions, such as Global Title
10 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Translation (GTT), FNR, accounting, policing and Generic Message Screening and
rerouting (STP functions, SPC-based routing).
The framework architecture is defined in IETF RFC 2719, Reference [45].
The different layers are now introduced which provide the foundation of
transporting Signaling Application Protocols over IP according to the framework
architecture defined in IETF RFC 2719, Reference [45].
Transporting Signaling Application Protocols over IP involves the following three

layers (see also Figure 6):
— The IP network layer
— SCTP transport protocol
— The adaptation layers
The adaptation layers support the specific primitives required by a particular

Signaling Application Protocol. There are many Signaling Application Protocols in
CNCS nodes which can be supported by the modular structure described in Figure
6. Since all Signaling Application protocols have similar transport requirements,
the protocol-specific considerations are all treated in the adaptation modules.
Signaling Application Protocols
Adaptation Layers
SCTP
IP
Figure 6 IP Signaling Transport Components
GCP and SGsAP are exemptions to the transport of Signaling Application protocols
as previously described: As described in Section 4.4 on page 23 and Section 4.3.1
on page 15, CNCS offers the option to transport GCP either directly over SCTP
or over M3UA. As described in Section 4.5 on page 24, CNCS transports SGsAP
only directly over SCTP.
Aside from these exemptions, all other Signaling Application Protocols are
transported on a dedicated adaptation layer.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 11

In this document the following adaptation layers are discussed:
— M3UA (IETF RFC 4666, Reference [47]):
Suitable for the transport of ISUP, SCCP Users, TUP, BICC, GCP Signaling
Application Protocols over the IP network.
— M2PA (IETF RFC 4165, Reference [48]):
Allows for full MTP3 message handling and network management capabilities
between any two IP-SEPs.
— IUA (IETF RFC 4233, Reference [49]):
Suitable for the transport of ISDN Q.921 user messages (Q.931) over the
IP network.
All adaptation layers use the services of the underlying reliable common SCTP
protocol defined in IETF RFC 4960, Reference [46], which is a transport protocol
that provides error control, sequence control and flow control functions required
for the reliable transport of signaling messages over IP networks.
4.1 IP Layer
The IP network provides IP connectivity through some IP routers. As shown
in Figure 7, the IP network is typically divided in several sites hosting various
network nodes (in Figure 7: MSC-S, M-MGw, and HLR) and a common IP
transport backbone.
SITE SITE
MSC-S MSC-S
Router Router Router

Switch Switch
Router
M-MGw Router
M-MGw
Switch Router Router Switch
Router IP
HLR HLR
Figure 7 The IP Network
12 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

The basic site infrastructure includes site routers and LAN switches. This site
equipment provides the connectivity, aggregation, and traffic separation. The
LAN switch provides Ethernet interfaces and the site router provides a wide range
of interface types towards the IP backbone.
The site routers and the LAN switches are expected to be duplicated to achieve
redundant site configuration. It is also advisable to use a pair of Gigabit Ethernet
(GE) or 10GE links between LAN switches to achieve a link redundant solution.
Optionally, the site infrastructure can include Firewalls and Security Gateways
to protect the network nodes from malicious attacks and to provide encryption
for enhanced security.
CNCS nodes support Differentiated Services as Quality of Service (QoS)

mechanism in line with what is specified in IETF RFC 4594, Reference [50]. The
sender of an IP packet sets a 6-bit field in the IP header of the IP packet to a
particular value called the Differentiated Services Code Point (DSCP) and the
routers processing the packet on its way to the receiver of the packet handle the
packet according to the DSCP of the packets. The handling of packets typically
includes the selection of a queue inside the router and possibly the change of the
DSCP value. Service class definitions are normally based on the different traffic
characteristics and required performance of the applications or services. IETF
RFC 4594, Reference [50], recommends using use class CS5 binary ‘‘101000’’
for signaling.
The IP infrastructure is expected to fulfill the characteristics for signaling transport

regarding limited delay and packet loss, details can be found in Section 5.2.3 on
page 51. Another important aspect is to ensure that there is no common point of
failure on IP level.
Section 5 on page 43 discusses the IP connectivity for the transport of Signaling

over SCTP/IP.
An overview of the solution for IP and Ethernet connectivity and basic resilience
for the transport of signaling over SCTP/IP is given in the User Guide Managing IP
Transport in the Core Network.
4.2 SCTP Layer

SCTP is a connection-oriented transport layer protocol defined in IETF RFC 4960,
Reference [46].
SCTP provides reliable transfer of user messages between peer SCTP Users.
It is designed to allow the transport of signaling traffic over IP networks and
operates on top of the IP layer. It performs this service based on multiple Streams
within an SCTP Association, established between two SCTP EPs. SCTP offers a
sequenced delivery of user messages within multiple Streams with an option to
bypass the sequenced delivery for individual messages. The advantage of using
multiple Streams within an SCTP association is that while one Stream can be
blocked waiting for the next in-sequence user message, the delivery from other
Streams can proceed.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 13

Figure 8 depicts a reference connectivity scenario, also referred to as Full

Connectivity scenario, which is established between an MSC-S and an M-MGw,
however, the same connectivity scenario can be used for communication between
any Multi-Homed SCTP Endpoints.
IP-1 IP-3
SCTP MH EP SCTP MH EP
IP-2 SCTP Association IP-4
MSC-S M-MGw
Figure 8 SCTP Multi-Homing, Full Connectivity Scenario
The details about how IP Path management is implemented in CNCS nodes are
further detailed in Section 6.1.1.1 on page 53.
The scenario depicted in Figure 8 is the more common scenario, but in some
networks it is possible that only connectivity of the direct IP Paths (IP1⇔IP3
and IP2⇔IP4) is available as shown in Figure 9. This is referred to as Reduced
Connectivity scenario.
IP-1 IP-3
SCTP MH EP SCTP MH EP
IP-2 SCTP Association IP-4
MSC-S M-MGw
Figure 9 SCTP Multi-Homing, Reduced Connectivity Scenario
One of the basic functions provided by SCTP is congestion control. Under adverse
network conditions, congestion situations arise which can lead to partial or, in the
worst case, full network outages. SCTP provides mechanisms to adapt to such
conditions avoiding message loss and spreading congestion into the network. The
basic idea behind SCTP congestion control is to regulate the SCTP transmission
rate. SCTP congestion control is applied to the SCTP association and not to
individual Streams.
The User Guide Managing and Optimizing SS7 Congestion Control and SIGTRAN
Performance provides the reader with an overview of how SCTP congestion
control is implemented in CNCS nodes and guidance for an accurate configuration
of the SCTP Congestion Control functions.
Another aspect considered in this document is the Stream setting. The number
of Streams to be supported by an SCTP association is specified by the SCTP user
at SCTP association establishment, or by values of MIS and MOS parameters,
depending on the SCTP O&M model used. Both SCTP EPs include in the INIT and
INIT ACK chunks the number of Streams the sender wants to create (number
14 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

of outbound streams) in the SCTP association and the maximum number of

Streams its peer sender allows to create (number of inbound streams) in the SCTP
association. After receiving the Stream configuration information from the other
side, each SCTP EP sets the number of usable Streams equal to the minimum
between the number of Streams the sender wants to create, and the maximum
number of Streams its peer sender allows to create. For example, if the number of
Streams the sender wants to create is 256 and the maximum number of Streams
its peer sender allows to create is 17, the number of Streams the sender uses
within the SCTP association is 17. The details about number of Streams used
by the different SCTP user in CNCS nodes are further described in Section 6.1.5
on page 64.
Section 6.1 on page 53 discusses extensively the setting of SCTP parameters in

CNCS nodes based on the IP network characteristics.
4.3 Signaling over Adaptation Layers
4.3.1 Signaling over M3UA

This section provides an overview of the most typical interconnection scenarios
for the transport of Signaling Application Protocols over M3UA.
Figure 10 shows the different Signaling Application Protocols that are possible
users of the M3UA layer.
(*)
GCP ISUP BICC SCCP
M3UA
SCTP
LL
(*) RANAP, BSSAP and BSSAP+ over SCCP,

MAP, CAP and INAP over TCAP/SCCP
Figure 10 M3UA Protocol Stack
Table 2 lists all possible IP-SEP⇔SS7-SEP and IP-SEP⇔IP-SEP combinations

and associated Signaling Application Protocol.
Table 2 End-Point Node Combinations and Associated Signaling Application

Protocols
IP-SEP SS7-SEP or IP-SEP Protocol
MSC-S RNC RANAP
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 15

IP-SEP SS7-SEP or IP-SEP Protocol

MSC-S BSC BSSAP
MSC-S SGSN BSSAP+
MSC-S SMS-SC MAP
MSC-S HLR MAP
MSC-S FNR MAP
MSC-S LCS MAP
MSC-S gsmSCF CAP
MSC-S CCN CAP
MSC-S SCP INAP
MSC-S POI ISUP
(1)
MSC-S STP /SGW RANAP/BSSAP/MAP/CAP/INAP/ISUP
MSC-S VM ISUP
(2)
MSC-S MSC-S BICC/ISUP/MAP
(1) STP is not valid for IP-SEP to IP-SEP scenario.
(2) Not valid for Single Gateway scenario.
4.3.1.1 Multiple Gateway Scenario
Figure 11 depicts a scenario where the IP-SEP, in this case an MSC-S, is connected
through two M-MGws to several SS7-SEPs residing in a TDM- or ATM-based
network, in this case HLRs residing in a TDM-based network. Figure 11 shows
the use of M-MGws but the traffic scenario is valid also if instead of M-MGw,
STP/SGWs from other vendors are used.
16 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

M-MGw HLR
IP TDM
MSC-S
M-MGw HLR
MAP MAP
TCAP TCAP
NIF
SCCP SCCP
M3UA M3UA MTP3 MTP3
SCTP SCTP MTP2 MTP2
LL_ip LL_ip LL_tdm LL_tdm
Figure 11 Multiple Gateway Scenario
The two M-MGws act as SGWs for the conversion between TDM and IP transport
technologies. The M-MGws are transparent to the Signaling Application Protocol.
The M-MGw pair can also be replaced by an SGW pair of any other vendor. This
scenario provides node level redundancy avoiding single point of failure.
The scenario applies to the case where the SS7-SEPs support Quasi-Associated
Signaling Mode; the SS7-SEPs are provisioned with the M-MGw and MSC-S SPCs.
From the SS7-SEPs viewpoint, the two M-MGws are seen as STPs.
Two signaling links between the HLRs and the pair of M-MGws are created
following the physical links. The signaling interfaces are used in load-sharing
mode. On the IP network side, one or two SCTP Associations are defined between
the MSC-S and each M-MGw.
If M-MGws are used as illustrated in Figure 11, only direct routing must be used.
Even if there is a link between the M-MGws, no routing between them must
be used because the M-MGw does not support M3UA Relay, although it does
not prevent such configuration. In other words, even if an SCTP association is
available between the M-MGws no routing of the previously mentioned protocols
must be used over that SCTP association, otherwise it can result in circular routing
of application messages between the two M-MGws and traffic loss.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 17

Figure 11 illustrates one of the possible IP-SEP⇔SS7-SEP combinations. Table

2 lists all possible IP-SEP⇔SS7-SEP combinations and associated Signaling
Application Protocol.
4.3.1.2 Single Gateway Scenario
Figure 12 illustrates the scenario where the IP-SEP, in this case an MSC-S, is
connected through one M-MGw to one SS7-SEP residing in a TDM- or ATM-based
network, in this case a POI residing in a TDM-based network.
POI
TDM
MSC-S M-MGw
NIF
ISUP
M3UA M3UA MTP3 ISUP
SCTP SCTP MTP3
LL_tdm
LL_ip LL_ip LL_tdm
Figure 12 Single Gateway Scenario
The M-MGw acts as SGW to convert between TDM or ATM and IP transport
technologies. The M-MGw can also be replaced by an SGW of any other vendor.
The M-MGw is transparent to the Signaling Application Protocols.
This scenario applies to the case where the SS7-SEP supports ‘‘Associated
Signaling Mode’’ and it requires the activation of ‘‘Associated Signaling Mode in
SGW’’ feature in M-MGw. The feature is supported for ANSI, ITU, TTC, and CCSA
standards. The SS7-SEP is connected to the MSC-S through the M-MGw so that
the MSC-S is seen as adjacent node in the SS7-SEP node.
This scenario does not provide node-level redundancy and therefore has the
disadvantage that it creates a single point of failure.
Figure 12 illustrates one of the possible IP-SEP⇔SS7-SEP combinations. Table

2 lists all possible IP-SEP⇔SS7-SEP combinations and associated Signaling
It is also possible to connect an SS7 STP node to the M-MGw using the Associated
Signaling Mode feature so that the MSC-S is seen as adjacent node in the SS7 STP
as shown in Figure 13. This scenario is only useful to save additional SPCs of the
M-MGw, for instance in international networks.
Recommendation:
18 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

In cases where the SPCs are available, it is recommended to use two M-MGws
that act as STP/SGW.
Acts as SPC=A
towards SPC=C
IP TDM STP POI

SPC=C
MSC-S M-MGw
SPC=A SPC=B
NIF
ISUP
M3UA M3UA MTP3 ISUP ISUP
SCTP SCTP MTP3 MTP3
LL_tdm
LL_ip LL_ip LL_tdm LL_tdm
Figure 13 Associated Signaling Mode in SGW, SS7 STP
The M-MGw is seen as ordinary SGW (also performing the STP function) from
MSC-S but the SS7-SEP or SS7 STP is configured as if the signaling links were
terminated in the SP of the MSC-S.
Recommendation:
Configure several signaling links in the link set towards the SS7-SEP and to
provide redundancy and load sharing. Distribution of the signaling links from
the SS7-SEP and STP to two redundant M-MGws must not be used because
such configuration results with disturbed MTP3 management procedures.
4.3.1.3 IP-SEP to IP-SEP over M3UA
Figure 14 illustrates the communication scenario between two IP-SEPs, in this

case an MSC-S connected to an SCF of another vendor.
Recommendation:
M3UA is the recommended adaptation layer for signaling between IP-SEPs.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 19

IP gsmSCF
MSC-S
CAP CAP
TCAP TCAP
SCCP SCCP
M3UA M3UA
SCTP SCTP
LL_ip LL_ip
Figure 14 Peer-to-Peer over M3UA
Figure 14 illustrates one of the possible IP-SEP⇔IP-SEP combinations. Table 2

lists other possible IP-SEP⇔IP-SEP combinations and the associated Signaling
4.3.1.4 M3UA Relay
Ericsson IP-STPs support M3UA relay function, which is illustrated in Figure 15.
MSC-S IP-STP
IP
MSC-S IP-STP
BICC
M3UA M3UA
SCTP SCTP SCTP
LL_ip LL_ip LL_ip
Figure 15 Single M3UA Relay Stage
20 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

For the configuration of M3UA Relay, see User Guide M3UA Relay (SPX specific
document).
Recommendation:
Although it is possible to create a cascade of M3UA Relay stages, this is not

recommended.
The reason for the previous recommendation is that with M3UA Relay MTP-level
functions such as point code mapping, accounting and policing are not available.
4.3.2 Signaling over M2PA

Figure 16 shows the different Signaling Application Protocols that are possible
users of the M2PA Adaptation Layer.
(*)
GCP ISUP BICC SCCP
MTP3/MTP3b
M2PA
SCTP
LL
(*) RANAP, BSSAP and BSSAP+ over SCCP,

MAP, CAP and INAP over TCAP/SCCP
Figure 16 M2PA Protocol Stack
M2PA is valuable in signaling networks with STP nodes and inter-operator

connectivity which use IP-STPs because it supports the standard MTP3 network
management functions. Additional functions such as MTP accounting, MTP
policing, and SPC mapping, which are part of MTP3, are available in this case as
well, for more details about M2PA connections in cluster architecture see User
Guide MSC-S Configuration Management. Moreover, 3GPP TS 29.202, Reference
[44] defines a minimum set of M2PA requirements to be supported between IP
nodes and between IP capable SRP nodes in a 3GPP network.
Recommendation:
M2PA connections are recommended for the signaling between nodes with
‘‘IP-STP’’ function.
Use redundant M2PA links between IP-STPs deployed as mated IP-STP pair.
Use at least two M2PA-based links per link set between the nodes with
‘‘IP-STP’’ function.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 21

The reason for the previous recommendation is that there is a one-to-one relation
between an M2PA link and an SCTP association.
Note: Use of multiple SCTP associations between nodes has no adverse effect
on the nodes or SCTP performances as long as the used number of SCTP
associations can be supported by the hardware resources.
The use of a single M2PA-based link in a link set between the IP-STPs is not
encouraged because it introduces head-of-line blocking by retransmissions on
SCTP level, as M2PA does not use multiple SCTP Streams for traffic messages.
Recommendation:
At migration of installed MTP TDM- and ATM-based signaling link to IP

transport, the use of MTP3/M2PA/SCTP stack can be a better option than
using M3UA/SCTP stack, when both peers support M2PA. This option retains
MTP3 configuration and corresponding MTP3 functions, and reduces the
configuration effort needed for migration to IP transport.
User Guide Managing and Optimizing SS7 Congestion Control and SIGTRAN
Performance provides dimensioning guidelines for M2PA links.
4.3.3 PRA Signaling over IUA
This section provides an overview of the transport of the Q.931 Signaling

Application protocol over IUA.
Figure 17 shows the Signaling Application Protocol that is the user of the IUA
Layer.
Q.931
IUA
SCTP
LL
Figure 17 IUA Protocol Stack
Figure 18 shows the scenario where a Private Branch Exchange (PBX) is

connected through the M-MGw which acts as SGW to an MSC-S.
The PRA is physically connected to the M-MGw where the user plane (B-Channels)
is handled. The D-Channel signaling messages are backhauled on the IUA
protocol stack between M-MGw and MSC-S. The B-Channels are controlled from
the MSC-S over the existing GCP interface to the M-MGw.
22 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

IP TDM
PABX
MSC-S M-MGw
NIF
Q.931
IUA IUA
SCTP SCTP Q.921 Q.931
LL LL_ip Q.921
Figure 18 IUA for Q.931 Signaling
The Q.931 messages from the PBX are carried by the LAPD (Q.921) and
backhauled on the IUA/SCTP/IP stack towards the MSC-S by the ‘‘Nodal
Interworking Function’’ (NIF). This means the Q.931 protocol is transparent
for the M-MGw. In the M-MGw, all D-Channels associated with one MSC-S are
backhauled over one SCTP association. IUA and GCP traffic use different SCTP
associations. The association for GCP traffic is not shown in Figure 18.
One PBX can communicate with one MSC-S. One MSC-S can communicate with
several PBXs connected to one or several M-MGws.
4.4 GCP over SCTP

The GCP is a Signaling Application Protocol which can run directly on top of the
SCTP transport layer.
Note: The STC (described in ITU-T Q.2150.3, Reference [52]) is not a real
protocol layer as it does not add protocol control information to
the Message Signal Unit (MSU). It is however used from a protocol
perspective to hide the underlying layers from GCP.
GCP
STC
SCTP
LL
Figure 19 GCP over SCTP Protocol Stack
In CNCS, the only communication scenario which involves GCP over SCTP is
between the MSC-S and the M-MGw as illustrated in Figure 20.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 23

IP
MSC-S M-MGw
GCP GCP
STC STC
SCTP SCTP
LL-ip LL-ip
Figure 20 GCP over SCTP
In this scenario, only Multi-Homed SCTP Associations must be used. The reason is
that there is no redundancy supported at GCP level.
Only one MH SCTP association can be defined for one remote virtual M-MGw.
If more than one virtual M-MGw exists on a physical M-MGw, one MH SCTP
association must be configured for each virtual M-MGw.
4.5 SGsAP over SCTP

The SGsAP protocol is another Signaling Application Protocol which runs directly
on top of the SCTP transport layer. It uses the concept of remote host to define a
group of transport connections to achieve redundancy and scalability.
SGsAP
SCTP
LL
Figure 21 SGsAP over SCTP Protocol Stack
In CNCS, the only communication scenario which involves SGsAP over SCTP is
between the MSC-S and the MME as illustrated in Figure 22.
24 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

MME
IP
MSC-S
SGsAP SGsAP
SCTP SCTP
LL-ip LL-ip
Figure 22 SGsAP over SCTP
In this scenario, one or two MH SCTP associations can be used.
4.6 Redundancy in the Signaling Network

Resilience and high availability of the signaling network can be achieved using
redundancy mechanisms on different levels. These mechanisms are in principle
not mutually exclusive.
This section illustrates redundancy mechanisms applicable on the following levels:
— IP and MPLS levels
— SCTP and M3UA levels
— SCCP level
— SGsAP level
A more detailed description of the possible combinations of IP and MPLS, SCTP,

and M3UA redundancy mechanisms and recommendations are given in Section
5.1.2 on page 45.
4.6.1 Redundancy on IP and MPLS Level

The IP and MPLS layers provide recovery mechanisms to handle network failures.
These cover various measures such as, configuring alternative routes in the
routers to reach the same destination or relying on IP routing convergence to
find alternative IP Paths through the network (this approach is relatively slow or
requires tuning of timing parameters) or using MPLS mechanisms.
Since IP and MPLS redundancy mechanisms strongly depend on multivendor

backbone equipment and the overall backbone realization, they are not further
treated within this document.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 25

4.6.2 Redundancy on SCTP Level
Redundancy is achieved on SCTP level by SCTP multi-homing. Path Diversity in

the IP backbone is a prerequisite to achieve SCTP redundancy.
In the MH SCTP configuration, an endpoint has two or more IP addresses from

which one is selected for Primary Path and is used by default for data transmission
to its peer.
When the Primary Path becomes inactive, the Failover to a Secondary Path
occurs. If Switchback Mode is set to ‘‘Immediate’’ or ‘‘Exponential Switchback’’,
the Primary Path is used for data transmission whenever it is available or after
some successful heartbeats.
However, if switchback mode is set to ‘‘No Switchback’’, the Primary Path is used
for data transmission only at establishment of the association and it remains in
use until it fails. At that point, data transmission is permanently migrated to a
Secondary Path.
The IP Failover guarantees zero packet loss for failures in the IP network.
Note: However, ‘‘zero packet loss’’ is only guaranteed for IP backbone or LAN
infrastructure failures but not for failures of interface boards, in which
case all messages in the send buffer are lost.
Ericsson nodes are MH and details about IP Path Management can be found in
Section 6.1.1 on page 53 and in Section 6.1.2 on page 55.
Recommendation:
SCTP multi-homing is the recommended configuration.
The architecture of the remote node might impose use of multiple MH SCTP
Associations for M3UA connectivity. For instance, MSC-S BC requires two MH
SCTP Associations.
GCP over SCTP and IUA signaling can use only one SCTP Association from
MSC-S to an M-MGw. See User Guides MSC-S Configuration Management, and
Managing and Optimizing SS7 Congestion Control and SIGTRAN Performance
for more details.
There are situations where CNCS nodes communicate with nodes that support
Single-homed SCTP EPs only. Node that supports Single-homed SCTP EPs only
can communicate with nodes that support Multi-homed SCTP EPs, such as CNCS
nodes, that is, it can use the different IP Paths provided by the nodes that support
Multi-homed SCTP EPs according to the previous description.
Recommendation:
In this case, CNCS nodes must use MH SCTP EPs for associations to such nodes
according to the previous recommendation.
26 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

There are situations where CNCS nodes communicate with nodes of other vendors
that do not provide sufficient redundancy on transport level alone and rely on
redundancy mechanisms of layers above SCTP. For instance, such nodes can rely
on multiple M3UA signaling processes in their transport redundancy solutions.
Recommendation:
In this case, an MH SCTP association is used from CNCS nodes to each M3UA
process at the remote node.
4.6.3 Redundancy on MTP3 over M2PA Level

Redundancy is achieved on MTP3 level by configuring multiple M2PA links in a
link-set between adjacent MTP3 nodes.
Each M2PA link uses its dedicated SCTP Association, which can be either SH or MH.
Recommendation:
Use of multiple M2PA links is recommended.
MSC-S can be configured to use MTP3 routes to a destination either in

load-sharing mode (multiple routes with same priority) or active-standby mode
(multiple routes with different priorities). Recommendations on how to configure
load sharing on network level are given in Section 4.6.8 on page 29.
4.6.4 Redundancy on M3UA Level

Redundancy on M3UA level is achieved by configuring two or more SCTP
associations for routing to a destination node, where the M3UA layer controls the
load distribution over the SCTP associations.
The redundancy mode can be either load-sharing mode (distribution of the

traffic messages among two or more SCTP associations) or active-standby mode
(routing of traffic over one SCTP association, while the others act as backup).
Recommendations on how to configure load sharing on network level are given in
Section 4.6.8 on page 29.
More details on M3UA level redundancy are provided by User Guide Message
Transfer Part 3 User Adaptation Layer and User Guide for Signalling, Reference
[42].
Recommendation:
Use load-sharing redundancy mode for signaling sent to more than one SGW or
IP-STP.
Recommendation:
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 27

For M3UA peer-to-peer communication, it is recommended to use one MH SCTP

association.
Recommendation:
If an SH SCTP association is configured between CNCS nodes and SH-only

capable nodes of other vendors, then redundancy must be provided on M3UA
level.
Redundancy on M3UA level can be also needed when CNCS nodes use MH SCTP
associations depending on the node architecture (see Section 4.6.2 on page 25).
4.6.5 Redundancy on SCCP Level

On SCCP level, redundant peer nodes can work in a load sharing or in
active-standby mode and the GTT has to be configured accordingly. The
active-standby mode on SCCP level can be required by certain network features
such as HLR redundancy. For ANSI standard, active-standby mode on SCCP
level is possible only.
Global Title Routing Cases (GTRCs) must be configured in dominant mode (no load
sharing defined) for traffic destined to a pair of redundant SCCP nodes working in
active-standby mode, so that Primary Signaling Point (PSP) designates the active
node while Secondary Signaling Point (SSP) designates the standby node.
It is possible to define active-standby mode by priority groups (available through

SCCP Global Title Routing Extension (GTRE) feature, for further information see
Function Specification SCCP Global Title Routing Extension (ITU-T, MPT, TTC)).
Maximum 64 SCCP nodes in up to four priority levels can be defined per one GTRC.
SCCP nodes configured in group with highest available priority level represent
Active nodes, while nodes configured in groups with lower priority levels (currently
not available in traffic) represent standby nodes.
For the redundant peer nodes working in load sharing mode, see Section 4.6.8.1
on page 29.
For further details, see Adaptation Direction Traffic Data: Handling of Global
Title Routing Cases.
4.6.6 Redundancy for SGsAP

Redundancy on SGsAP level is achieved by defining two SCTP associations that
are bound to the same remote host (representing the remote MME node). Load
distribution and association selection based on availability are automatically
applied by an internal function in SGsAP, per remote host.
For further details, see User Guide SGs-Interface Configuration and Enabling of
SMS over SGs-Interface and LTE to CS Fallback.
28 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

4.6.7 IP to TDM/ATM Failover

CNCS nodes can be configured to use a combination of transport technologies
(TDM, ATM, and IP) for signaling relations to a peer node. It is possible to
configure failover of transport from M3UA to MTP3 over TDM, ATM, or IP
transport (over M2PA). When M3UA to MTP3 failover is configured, the traffic is
normally transferred over M3UA and fails over to MTP3 if the destination SEP
becomes unavailable through the M3UA network. When the destination becomes
available through the M3UA network again, traffic falls automatically back from
MTP3 to M3UA.
For more information see User Guide Message Transfer Part 3 User Adaptation
Layer and User Guide for Signalling, Reference [42].
4.6.8 Load Sharing
The benefits of load sharing are more equal use of the nodes and an in-service
performance impact reduced to a portion of the traffic if there is a failure. Load
sharing can be configured on different levels in the signaling network.
The principles for load sharing depend on the protocol used, but the load sharing
mechanisms in all layers are based on the principle of considering SS7 parameters
such the Signaling Link Selection (SLS) field for selecting the routes and links
(for MTP), SCTP associations (for M3UA), or Destination Point Codes (DPCs) (for
SCCP).
Recommendation:
Use load sharing whenever possible in the network.
4.6.8.1 Load Sharing at SCCP Level
On SCCP level, two load sharing schemes are offered:
Note: The feature is supported for ITU, CCSA, and TTC standards.
— Basic
This load sharing scheme is achieved by configuring two alternative DPCs

(PSP and SSP) in load sharing mode in the GTRC.
— Extended (for CL traffic only and available through SCCP GTRE feature)
This load sharing scheme is achieved by configuring up to 64 alternative DPCs

(SPs) in up to 4 priority groups. Load sharing is performed among SPCs of the
highest available priority group. This feature also offers possibility to achieve
basic capacity weighted load sharing by configuring the same SPC value for
more than one routing alternative.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 29

Note: Such configuration reduces the number of alternative SPCs among

which load sharing can be performed since the number of routing
alternatives is fixed to 64.
Recommendation:
Use SCCP load sharing instead of load sharing on MTP3/M3UA level in cases
when multiple nodes in the network share the SPC value.
Example:
HLR-FEs can be configured to share a same SPC value to load share TCAP
dialogs among HLR-FEs on M3UA/MTP3 level. Avoid such configurations.
For further details, see Adaptation Direction Traffic Data: Handling of Global
Title Routing Cases.
4.6.8.2 Load Sharing at MTP3 or M3UA Level
The SLS field is provided by the users of MTP3 or M3UA similarly to SCCP to
guarantee in-sequence delivery. It is used by the M3UA and MTP3 layers as a
basis for the load sharing scheme.
In the MTP3 ITU-T and China standards, load sharing can be performed between
up to four routes towards a destination.
In ANSI, the MSC-S can perform load sharing between up to two routes, while the
M-MGw is able to load share over a maximum of four routes.
The M3UA load sharing scheme is node-dependent. MSC-S offer three load
sharing schemes which differ in the maximum number of SCTP associations to
load share over and the algorithm used for traffic distribution over these SCTP
associations. With the predefined pattern scheme, it is possible to load share over
a maximum of 16 SCTP associations, while for the other two schemes it is possible
to load share over a maximum of 64 SCTP associations.
It is not recommended to use Capacity Weighted Round Robin scheme in MSC-S,

although it can be used at load sharing among HLR-FE nodes, which share a
same SPC.
Note: SCCP load sharing is preferred for this scenario.
For more information about the M3UA load-sharing schemes, see User Guide
Message Transfer Part 3 User Adaptation Layer.
For more information about load-sharing in ANSI MTP3, see Function

Specification SS7 Message Transfer Part, MTP.
For other MTP3 standards, see Function Specification CCITT7 Signalling System
No. 7, Message Transfer Part.
30 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

In the M-MGw, it is possible to load share over a maximum of four SCTP

associations.
For more information about load-sharing schemes in the M-MGw see User Guide
for Signalling, Reference [42].
Recommendation:
To achieve equal use of signaling routes in a node, the number of routes of the
same priority to a destination is recommended to be a power of 2.
To achieve optimal load sharing on network level, a coordinated approach to load

distribution schemes is needed in SEPs.
In MSC-S, at load sharing over two routes in MTP3 networks (ITU-T, China and
TTC standards), it is possible to control the SLS bit used for load sharing in a
signaling route set.
The selection of the SLS bit that is used as a basis for load sharing is important by
an intermediate STP node scenario as the one depicted in Figure 23, because it
can cause uneven load distribution in non-adjacent STPs when on a transfer path
through the network (route) several nodes (for instance SEPs and their adjacent
STPs/SGWs) use the same SLS bit for load sharing.
STP/SGW STP/SGW
A C
MSC-S MSC-S
SEP SEP
STP/SGW STP/SGW
B D
Figure 23 Intermediate STP Node Scenario
Recommendation:
At load sharing on two MTP3 routes, it is recommended to set the SLS bit
differently in the following cases:
— a: On link sets at SS7-SEPs
— b: On link sets between STP/SGW nodes
For example, the load sharing bit could be configured to value 3 in SS7-SEPs
(previously item a), and 2 at the first STP/SGWs nodes on the route to a
destination (previously item b).
Recommendation:
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 31

In general it is recommended that, all nodes on a message transfer path (route)

load sharing over two routes to a destination use different SLS-bits for load
sharing.
Recommendation:
At load sharing on more than two MTP3 routes, for instance when a SS7-SEP is
connected to four STPs and all routes through the STPs have the same priority,
the MTP3 load sharing has to be set to use the extended load sharing option.
In MSC-S, at load sharing over up to four routes in M3UA networks, for each
MTP3-User protocol it is possible to configure an SLS bit pattern for load sharing
of the protocol messages by a node.
Recommendation:
The nodes on a message transfer path (route) to a destination have to use

different SLS bit patterns for load sharing, to achieve optimal load sharing
on network level.
See User Guide Message Transfer Part 3 User Adaptation Layer for
recommendations on use of predefined patterns at M3UA load-sharing in MSC-S.
Note: At each STP/SGW, the M3UA and MTP3 routes to a SEP defined on a link
between mated STPs (STP A - STP B and STP C - STP D in Figure 23)
must be assigned lower priority than routes from the STP/SGW to the
SEP. This secures that links between mated STPs are used for alternative
routing only at failure of direct routes of higher priority to SEPs.
4.6.8.3 Load Sharing for SGsAP
Load sharing on SGsAP level is achieved by defining two SCTP associations that
are bound to the same remote host object (representing the remote MME node).
Load distribution and association selection based on availability are automatically
applied by an internal function on SCTP User level per remote host.
On CNCS side, an adaptive load sharing mechanism is applied, that is, if one SCTP
association is congested then the load sharing method shifts more traffic to the
non-congested association.
For further details, see User Guide SGs-Interface Configuration and Enabling of
SMS over SGs-Interface and LTE to CS Fallback.
4.7 Infrastructure Overview

Despite its architecture, MSC-S BC is seen from the network as a single node.
Externally visible addresses represent the deployed MSC-S as a whole. The SPXs
are the entry points into the MSC-S for all SS7 signaling. Two SPXs achieve
redundancy on network level, if the peer nodes can be connected to both SPXs.
For information on L2 and L3 integration of the MSC-S, see the User Guide
Managing IP Integration.
32 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

For more information on the specifics of the architecture and configuration, see
the Function Specification Cluster Overview and User Guide MSC-S Configuration
Management, respectively.
4.7.1 Traffic to or from SPXs and External Nodes

M3UA traffic always transits through a pair of redundant SPXs which act towards
the MSC Blades as either of the following:
— SUA Gateway for SCCP (MAP, CAP, RANAP, BSSAP, BSSAP+ and INAP) traffic
— M3UA Relay for trunk signaling traffic (ISUP and BICC) or GCP over M3UA
— MTP3 or M3UA SGW for trunk and GCP signaling traffic
— MTP3 or M3UA SEP for GCP
Remote M3UA peer must have SCTP Associations configured to both SPXs for
redundancy reasons. Exception to this rule is the SCTP association for GCP/M3UA
traffic used for PRA.
M2PA traffic is used when SPXs are configured as STP or SRP between two
external nodes.
IUA traffic is terminated on one of the SPXs only and remote IUA peer must have
SCTP association configured to one SPX.
GCP traffic that is used for PRA and is defined between M-MGw and the SPX, can
be defined over SCTP/IP or M3UA/SCTP/IP stack.
The MSC-S can be configured as one of the following two configurations or both
of them concurrently:
— Multiple SPC Configuration
— Single SPC Configuration (only applicable for ITU-T based signaling,

excluding TTC markets)
In case of multiple SPC configuration, MSC-S uses a dedicated own SPC for GCP
over M3UA and trunk signaling traffic (ISUP, BICC, and China TUP). MSC-S uses
another dedicated own SPC for SCCP (MAP, CAP, RANAP and BSSAP) signaling
traffic. Figure 24 illustrates the point code allocation in MSC-S for multiple SPC
configuration.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 33

SPX1
MSC Blade SCCP
M3UA MTP3
MTP3- SCCP- SPC-C SPC-C
Users Users
SPC-B SPC-A
MTP3 Traffic
M3UA Traffic
SPX2
SCCP
M3UA MTP3
SPC-D SPC-D
SPC for SCCP Traffic SPC-A MTP3 Traffic

SPC for Trunk & GCP Traffic SPC-B
SPC of SPX1 for MTP3 SPC-C M3UA Traffic
SPC of SPX2 for MTP3 SPC-D
Figure 24 SPC Representation in MSC-S BC (Multiple SPC Configuration)
In case of single SPC configuration, MSC-S can use one own SPC for GCP over
M3UA, SCCP (MAP, CAP, RANAP BSSAP, BSSAP+ and INAP) and trunk (ISUP,
BICC, and China TUP) signaling traffic. Figure 25 illustrates the point code
allocation in MSC-S BC for single SPC configuration.
Note: When PRA is required for a single SPC, two additional SPCs can be needed
for communication between SPX and blades. Additional SPC can be
needed in M-MGw, if GCP over M3UA is used. More information can be
found in User Guide MSC-S Configuration Management.
34 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

SPX1
MSC Blade SCCP
M3UA MTP3
MTP3- SCCP- SPC-A SPC-A
Users Users
SPC-A SPC-A
MTP3 Traffic
M3UA Traffic
SPX2
SCCP
M3UA MTP3
SPC-A SPC-A
MTP3 Traffic
SPC for SCCP, Trunk,
SPC-A
GCP and MTP3 Traffic
M3UA Traffic
Figure 25 SPC Representation in MSC-S BC (Single SPC Configuration)
MSC-S allows the use of multiple own SPCs towards a same DPC for trunk
signaling traffic (ISUP, BICC, and China TUP).
Each SPX must have configured its own SPC, but these SPCs can remain hidden
from the other nodes when M3UA is used for transport of signaling traffic to and
from external nodes.
When MSC-S takes part in several SS7/SIGTRAN networks, then the dedicated
own SPC must be configured for each NI of those networks. For example, if trunk
signaling is used in several networks then a dedicated own SPC must be used for
trunk signaling in each network. Similarly, dedicated own SPCs are needed for
SCCP signaling in multiple networks.
See User Guide MSC-S Configuration Management for further details on use of
point codes in MSC-S and related configuration.
For further information about the signaling capabilities in MSC-S, see Function
Specification IP Based Functions on CP, Protocol Stack.
Path Diversity in egress direction is achieved by the fact that the IP addresses of
the SPXs are allocated to a separate physical interface.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 35

4.7.2 Traffic to or from MSC Blades and External Nodes
GCP or SGsAP over SCTP traffic does not transit through the SPXs.
One or more Multi-Homed SCTP Endpoints are configurable through a pair of

Virtual IP addresses (VIPs) common to the cluster of MSC Blades.
Path Diversity in egress direction is achieved by the fact that the MSC Blades VIP
addresses are associated to a separate physical interface.
For further information, see User Guide MSC-S Configuration Management.

An MSC-S can act in the IP network as IP-SEP, M3UA SGW or as SGW with M3UA
Relay node types. These node types can coexist in the same MSC-S.
All nodes connected to an MSC-S must be connected to each SPX using at least one
SCTP association. That is, at MSC-S, two sets of SCTP associations are configured
for M3UA connectivity – one set of associations at each SPX. For example, when
two MSC-Ss are connected to each other, they use at least four SCTP associations,
where each SPX of an MSC-S is connected to both SPXs of the peer MSC-S.
MSC-S supports ASP, SGP, IPSP, or ESP process types where ASP, SGP, and IPSP
are compliant with IETF RFC 4666, Reference [47], while ESP complies with
3GPP TS 29.202, Reference [44]. The process type is configured on a per SCTP
association basis. All process types can coexist on an MSC-S. Although the process
type has to be configured according to the role of a node in M3UA network –
the MSC-S usually acts as IP-SEP – it must be chosen based on the peer node
capabilities.
There are no restrictions on process type (ASP, SGP, IPSP, or ESP) configured in a
node but it is more natural to follow M3UA IETF RFC 4666, Reference [47], and
configure IPSP process type for IP-SEP to IP-SEP communication, and ASP for
IP-SEP to M3UA SGW communication. See User Guide MSC-S Configuration
Management, for recommendations on process type configuration.
Recommendation:
Use the ESP process when communicating to M-MGw or any other Ericsson
node, see 3GPP TS 29.202, Reference [44].
Note: ESP process type can be used for communication to nodes of other
vendors which follow 3GPP TS 29.202, Reference [44].
Use of ESP process is valid for M3UA relations configured up to R14.0, which
means that ESP process type is already in use, and there are no reasons to modify
configuration from ESP to another process type.
Recommendation:
36 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

If the nodes of other vendors do rely on either Notify procedures or on sending

of Routing Context parameter from MSC-S, then IETF M3UA compliant
process types must be used.
Recommendation:
On SCTP associations where the MSC-S acts as an IP-SEP towards nodes

of other vendors, it is recommended to use the IPSP process type when
communicating to IP-SEP nodes of other vendors, and the ASP process type
when communicating to M3UA SGW nodes of other vendors.
Recommendation:
On SCTP associations where the MSC-S acts as M3UA SGW or as SGW with
M3UA Relay towards nodes of other vendors, it is recommended to use the SGP
process type for connectivity from each SPX to IP-SEP nodes of other vendors.
When an IETF M3UA compliant process type is configured for an SCTP

association, it is possible to use multiple NIs over that SCTP association. Separate
SCTP associations must be used for different protocol variants (ANSI, TTC, ITU,
and CCSA).
If ESP process type is configured for an SCTP association, only a single NI can
be used.
For further information about the M3UA layer configuration, see User Guides
Message Transfer Part 3 User Adaptation Layer, and M3UA Relay (SPX specific
document), for further information on process type configuration at M3UA Relay.
For further information about the M3UA layer functionality and capabilities, see
the following Function Specifications:
— MTP3 User Adaptation Layer
— MTP3 User Adaptation Layer, Signalling Gateway
— M3UA Relay (SPX specific document)
— M3UA, Event Reporting and Disturbance Supervision
— Counters in the Measurement Database for M3UA
— MTP3 User Adaptation Layer Protocol
4.7.4 Signaling over M2PA

Recommendation:
For further information about the M2PA layer configuration, see User Guide
MSC-S Configuration Management.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 37

For further information about the M2PA layer functionality and capabilities, see
the following SPX specific documents:
— Function Specification Message Transfer Part 2 (MTP2)-User Peer-to-Peer

Adaptation Layer (M2PA)
— Function Specification Counters in the Measurement Database for M2PA
— Interwork Description Signalling System 7 (SS7) Message Transfer Part 2

(MTP2) - User Peer-to-Peer Adaptation Layer (M2PA) Protocol
4.7.5 GCP over SCTP

For information about the configuration of GCP over SCTP, see User Guides MSC-S
Configuration Management, and Gateway Control Protocol over SCTP.
For information about the functionality and capabilities for the transport of GCP
over SCTP, see Function Specification Signalling Transport Converter over SCTP.
4.7.6 Signaling over IUA
IUA uses dedicated single SCTP Association between remote peer and one and
only one SPX component of the node.
For information about configuration of PRA, see User Guides Managing Primary
Rate Access on Core Network Level and MSC-S Configuration Management.
4.7.7 SGsAP over SCTP

For information about the configuration of SGsAP over SCTP, see User Guides
MSC-S Configuration Management, and SGs-Interface Configuration and
Enabling of SMS over SGs-Interface and LTE to CS Fallback.
4.8 M-MGw Overview
4.8.1 Signaling Architecture

A simplified view of the M-MGw architecture is illustrated in Figure 26.
38 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

M-M G w node
GGPP B GGPP B GGPP B GGPP B

aacctiv
tivee ssta
ta n d-by
d -b y aacctiv
tivee ssta
ta n d-by
d -b y
GCP IU A
STC
GGPP B GGPP B GGPP B GGPP B GGPP B

aacctiv
tivee aacctiv
tivee ssta
ta n d-by
d -b y aacctiv e ssta
ta n d-by
d -b y
M 3U A M 3U A
SCTP SCTP SCTP

IP host IP host IP host
IP 1 IP 2 IP 3 IP 4 IP 5 IP 6
EET-IPG
T -IP G EET-IPG
T -IP G
1G E thernet 1G E thernet
Figure 26 M-MGw Signaling Architecture
Figure 26 shows the allocation of two stacks in an M-MGw and GCP over SCTP
and IUA protocols. Signaling over SCTP/IP is supported over FE, GE, and 10GE
interfaces. Different configurations can be applied for the physical connectivity,
see User Guide for Signalling, Reference [42], for further information.
The node is MH where up to two IP addresses can be configured. The IP, SCTP,
and M3UA layers are protected from board failures by having active – stand-by
General Purpose Board (GPB) configuration.
The combined MTP3b-M3UA layer instance supports one standard (ANSI,

ITU-T, CCSA (China), or TTC) at a time. The protocol layers connected to the
MTP3b-M3UA layer instance are said to form one SS7 signaling stack. To support
two standards in the node in parallel, or to increase the processing capacity of one
standard, two or three MTP3b-M3UA layer instances and its underlying layers are
supported in the node. These two variants of configuration are called dual stack
configuration and triple stack configuration.
Each stack hosts own MTP3b SPs. Each MTP3b SP, and thus each stack, needs to
manage its own resources (such as signaling link sets, M3UA SCTP Associations)
and these cannot be shared between the SPs.
For further information about the M-MGw signaling architecture, see User Guide
for Signalling, Reference [42].
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 39

Two M3UA standard variants are supported in M-MGw. The protocol variant that
is compliant with 3GPP TS 29.202, Reference [44], is described in this document
as it is the default and recommended configuration for M-MGw. M-MGw is also
compliant with IETF RFC 4666, Reference [47], where the M3UA process types
ASP, SGP, and IPSP are supported. Further information about this variant can be
found in User Guide for Signalling, Reference [42].
Recommendation:
Use 3GPP TS 29.202, Reference [44], variant of M3UA in M-MGw.
M-MGw supports up to 45 own SPs, 15 per signaling stack. Each SP is seen

as an independent node in the signaling network. Therefore dedicated SCTP
associations for M3UA must be created under each own SP if IP transport
technology is used to reach this SP. The SCTP, IP, and physical layers can be
shared between the SPs within the same signaling stack. The physical layer can
be shared between SPs belonging to different stacks as shown in Figure 27.
M-M G w n o de
S tack 1 S tack 2
SP SP SP
3-111 2-111 2-444
SRS SRS SRS SRS SRS SRS

D P C 3-222 D P C 3-666 D P C 2-222 D P C 2-333 D P C 2-222 D P C 2-555
SR SR SR SR SR SR
M 3U A M 3U A M 3U A M 3U A M 3U A M 3U A
SCTP SCTP
IP host IP host
IP 1 IP 2 IP 3 IP 4
ET-IPG
E T -IP G ET-IPG
E T -IP G
1G E thernet 1G E thernet
Figure 27 Signaling Point Representation in M-MGw
For further information about the M3UA layer configuration, functionality and
capabilities, see User Guide for Signalling, Reference [42].
40 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

4.8.3 Signaling over IUA

For information about the IUA configuration, functionality and capabilities, see
User Guide for Primary Rate Access, Reference [41].
4.8.4 GCP over SCTP

For information about the GCP over SCTP configuration, functionality and
capabilities, see User Guide for Virtual Media Gateway Handling, Reference [43].
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 41

42 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Network Solution Implementation
5 Network Solution Implementation
5.1 Recommended Site and Network Structure

Figure 28 illustrates the network reference scenario used in this document which
consists of two sites (Site 1 and Site 2) connected through the IP backbone.
The description applies to all kind of nodes.
The site structure provides redundant connections for each pair of communicating
nodes within and between sites and enables Path Diversity when the nodes reside
in different sites.
Note: The site transport infrastructure solution (physical connectivity)

introduced in this section represents the recommended solution also for
other traffic types (for example, O&M) so that the Signaling over SCTP/IP
traffic can share the equipment and no dedicated infrastructure has to
be installed.
S ite 1 S ite 2
A A
B AB AB B M S C -S
M S C -S
1 .. n 1 .. n
Switch A
R o u te r R o u te r Switch A
A A A
A
B IP B
A AB AB A
M-MGw M-MGw
B B
1 .. n 1 .. n
Switch B R o u te r R o u te r Switch B
A B B A
H LR B B H LR
1 .. n 1 .. n
Figure 28 Recommended Network Structure for Signaling over SCTP/IP
Each site hosts the nodes that communicate using Signaling over SCTP/IP. Figure
28 depicts MSC-Ss, HLRs, and PNFs M-MGws. The nodes are connected to the site
L2 infrastructure which consists of a pair of L2 (Ethernet) switches denoted as
Switch A and Switch B in Figure 28. The L2 switches are connected to the pair of
the Site Routers (Router A and Router B). The Site Routers enable communication
between the sites through the IP backbone.
Note: Sometimes, there are no standalone L2 switches and L2 functions

are included in the site routers. From a Signaling over SCTP/IP
perspective, however, this configuration is treated in the same way as the
configuration with standalone L2 switches.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 43

The nodes are connected to the site L2 infrastructure with two groups of physical
interfaces (referred to as Interface Group A and Interface Group B).
Within the site, and from the perspective of each site pair in the network, the IP
signaling transport infrastructure is logically divided into two parts:
— Network Part A, which includes Interface Group(s) A, L2 Switch(es) A and

Router(s) A
— Network Part B consisting of Interface Group(s) B, L2 Switch(es) B, and

Router(s) B
Note: The final L2 connectivity configuration is influenced by the redundancy

options described in Section 5.1.2 on page 45.
M-MGw provides a link protection mechanism if there is a failure so that it can

connect different interface groups (see dotted lines in Figure 28). For further
details, see User Guide for Signalling, Reference [42].
Node connectivity on Ethernet and IP levels is not discussed in this document. For
further information, see User Guides: Managing IP Transport in the Core Network
and MSC-S Configuration Management.
5.1.1 Ethernet and IP Connectivity

Considering the network scenario illustrated in Figure 28, the logical network on
L2 can be implemented per site as either of the following:
a Two IP subnets over one (or two) L2 VLAN. One Ethernet interface of the
node interface board or router pair belonging to one IP subnet.
b One IP subnet over one L2 VLAN. All node interfaces and router interfaces
are in one subnet.
The selection of one of the previous options must be combined with the selection
of the redundancy option described in Section 5.1.2 on page 45 and also by
considering the intra-site traffic.
With option a, in cases of failure, it is possible that Multi-Homed SCTP Associations

want to establish a transmission path between the two subnetworks. Therefore,
routing between the IP subnets has to be ensured. The L3 IP routing can be
implemented in small networks in the LAN Switches, but in the general case the
routing is implemented in the site routers.
With option b, in cases of failure, it is possible that MH SCTP associations want

to establish a transmission path between the two subnetworks, the traffic has to
be routed on the same subnet.
Since the IP signaling transport infrastructure is logically divided into two parts,
it is assumed that the IP backbone infrastructure can be associated to Network
Part A or Network Part B (or providing equivalent redundancy level). The required
44 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

two direct IP Paths between each two communicating nodes can be then easily
identified: one is within the Network Part A and the second within the Network
Part B.
In normal operation, the traffic generated on a certain Interface Group must be

kept within the related Network Part. This is valid for both intra-site and inter-site
traffic.
If two Single-Homed SCTP Associations are configured between the nodes (that
is, SCTP-application level redundancy is used), one SCTP Association is configured
within Network Part A and the second SCTP association is configured within
Network Part B, and they should use different IP Paths.
Note: With SCTP-application level redundancy and during normal operation

both SCTP associations are used in load sharing mode, this is not the
case when SCTP level redundancy is used where within the MH SCTP
association only one IP Path is active (Data Transfer Path) and the others
are standby (Secondary Paths).
Recommendation:
SCTP multi-homing is recommended unless communicating with nodes of other

vendors which do not implement multi-homing.
When communicating with a node that does not support multi-homing, SH

SCTP associations must be used. SCTP-application level redundancy is then
needed.
5.1.2 IP Redundancy, Path Diversity and Addressing

Fault resilience on transport layer can be addressed by two methods:
a SCTP-application-controlled resilience. Two SH SCTP associations between

any two communicating nodes. The two SCTP Associations work in load
sharing mode. The redundancy mechanism is controlled by SCTP-application
protocol layer.
b SCTP-controlled resilience. One MH SCTP association between any two

communicating nodes. Faults in communication paths are controlled and
handled by SCTP protocol layer.
These methods must be combined with redundancy options on the IP layer

described in the following subsections. Therefore the network design can consider
two alternative redundancy approaches:
— Signaling over SCTP/IP without IP network redundancy
— Signaling over SCTP/IP with IP network redundancy
These two approaches are described thoroughly in Section 5.1.2.1 on page 46 and
Section 5.1.2.2 on page 48 but the fundamental difference is highlighted here.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 45

The first approach leads to a rather strict separation between Network Part A
and Network Part B. Although the advantages of introducing the concept of
Network Parts in network design have been discussed to enable Path Diversity, a
strict separation can lead to loss of connectivity between peer nodes in certain
conditions which are described in Section 5.1.2.1 on page 46.
Recommendation:
Implement SCTP-controlled resilience. Then any of the two scenarios (with

or without IP redundancy) can be used, assuming that the advantage and
disadvantages with each of them are carefully evaluated.
5.1.2.1 Signaling over SCTP/IP without IP Network Redundancy
This design approach puts stronger requirements on separation between Network

Part A and Network Part B and thus better control on Path Diversity. There are
two separate subnetworks configured on site as seen from the client (nodes) and
the routers perspective. The IP connectivity between Network Part A and Network
Part B is only possible through the routers (indicated by (1) in Figure 29).
The requirement for the existence of separate physical paths does not exclude
connectivity between these different paths. On the contrary, the SCTP
implementation works best when there is full connectivity between all involved
IP addresses.
Figure 29 shows as an example the traffic flow between an MSC-S and an M-MGw
in the same site and between M-MGws in different sites. Full and dashed lines
indicate two alternative paths. Similar traffic flows would apply also towards
other nodes that are connected to MSC-S or M-MGw by SCTP.
46 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Traffic from Interface A sent to Router A attracts and delivers

other Interface A or Router A traffic for Interface Group A
S ite S ite
A A
M S C -S B B M S C -S
1 .. n 1 .. n
R outer R outer
A Switch A A IP A Switch A A
1
M-MGw B B M-MGw
1 .. n 1 .. n
R outer R outer Switch B
A Switch B B B A
H LR B B H LR
1 .. n 1 .. n
Traffic from Interface B sent to Router B attracts and delivers

other Interface B or Router B traffic for Interface Group B
Figure 29 Signaling over SCTP/IP Network Design with SCTP-Application or

SCTP Controlled Fault Resilience (Without Additional IP Redundancy)
The SCTP layer (if there is one MH SCTP association between the nodes) or
the SCTP-application layer (if there are two Single-Homed SCTP Associations
between the nodes) handles the failure case without assistance from the IP layer
(no IP redundancy applied in the client nodes).
If redundancy is handled by the SCTP layer, when unavailability of one

(active) interface is detected SCTP automatically finds an alternative route to
communicate between the nodes. This can be done by either using the cross paths
(that is, A-B) through the routers (indicated by (1) in Figure 29) or by switching
to an alternative direct IP Path completely (that is, B-B). This applies to both
intra-site and inter-site traffic.
If the redundancy is handled by SCTP-application, the two SH SCTP associations

are configured using different direct IP Paths each. One SCTP association uses
interfaces from Interface Group A and the second from Interface Group B. If
one SCTP association becomes unavailable, the whole traffic is sent over the
remaining one.
With SCTP-application level redundancy, and during normal operation, both SCTP
associations are used in load sharing mode, this is not the case when SCTP level
redundancy is used where within the MH SCTP association only one path is active
(primary) and the others are standby (alternative).
This relatively simple design approach conformant with IP network configuration

common practices must be weighted with the possibility of concurrent failures in
different parts of the network.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 47

This risk can become important in large networks, where control of equipment on
different sites is not always coordinated and there is a relatively high chance
that equipment is taken out of operation simultaneously, for example because
of maintenance.
As an example, consider in Figure 29 the communication between the MSC-S in

Site 1 and the M-MGw Site 2. Consider redundancy on SCTP-application level
and the failure situation where both the Router A in Site 1 and the Router B in
Site 2 are not working at the same time. The two possible communication paths
through the two SCTP associations are not available and there is no signaling
communication possible even though the physical path between the peer nodes
can exist (over Router B (Site 1) – Router A (Site 2)).
As it can be seen from the previous example, communication loss occurs when
two specific routers are taken out of operation at the same time. For networks
where such an event can be ruled out (that is, networks with central control of
IP infrastructure network-wide) and for networks where conformance with IP
configuration common practice is of high value, the solution described in this
section can be used.
Recommendation:
If such conditions (central control of IP infrastructure network-wide,

conformance with IP configuration common practice) are not fulfilled then IP
redundancy, (where an alternative path on IP level is provided if there is a
failure), is the preferred solution. This solution is described in Section 5.1.2.2
on page 48.
5.1.2.2 Signaling over SCTP/IP with IP Network Redundancy
With this network design approach redundancy on IP layer is provisioned in

addition to SCTP or SCTP-application level redundancy. In particular, IP Address
Migration is enabled in the MSC-S which means that IP address can be moved
from Interface Group A to Interface Group B. Moreover, addressing is done in a
way that the traffic flow between Network Part A and Network Part B over the L2
switches within one site is possible. The principle is illustrated in Figure 30.
48 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Traffic from Interface A preferentially sent Router A preferentially attracts and delivers
to other Interface A or Router A, but it can traffic for Interface Group A, but it can also
reach also Interface B or Router B deliver traffic for Interface Group B
S ite S ite
A A
M S C -S B B M S C -S
1 .. n 1 .. n
R outer R outer
A Switch A A IP A Switch A A
2 2
1
M-MGw B B M-MGw
1 .. n 1 .. n
R outer R outer Switch B
A Switch B B B A
H LR B B H LR
1 .. n 1 .. n
Traffic from Interface B preferentially sent Router B preferentially attracts traffic

to other Interface B or Router B, but it can for Interface Group B, but it can also
reach also Interface A or Router A deliver also traffic for Interface Group A
Figure 30 Signaling over SCTP/IP Network Design with Additional IP

Redundancy
The bridge between Network Part A and Network Part B can be realized on L2,
basically placing all client node interfaces on the same IP subnetwork, so that they
can directly communicate over the L2 Switches ((2) in Figure 30) and configuring
appropriate routing entries in the routers. In this case, more attention has to be
paid to ensure Path Diversity.
Path Diversity can be achieved by configuring the IP layer in a way that client
nodes interfaces are placed in the same IP subnetwork thus allowing direct
communication between Network Part A and Network Part B within the same site,
but to configure the routers so that they see two separate IP-subnetworks.
Detailed description on how to configure subnets can be found in User Guide

Managing IP Integration.
When Path Diversity is combined with IP redundancy, the chance that in case
of failure the path between communicating nodes is found is higher. Moreover,
this network design is capable of handling a broader spectrum of failure cases.
This can be illustrated with the same fault scenario example as discussed in
the previous section (simultaneous failure of both the Router A in Site 1 and
the Router B in Site 2): IP connectivity between the two remaining routers is
used to run SCTP traffic (for example Router B on the left side takes over the
incoming/outgoing traffic that was handled by Router A before the failure).
In addition, the MSC-S can use IP Address Migration since both Interface A and
Interface B of the MSC-S are in the same IP subnetwork. This increases resilience
if there is a board or cable failure in the node as complement to other equipment
in the site failure.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 49

Comparing to the network solution described in Section 5.1.2.1 on page 46

this solution caters for networks where, for example sites are not under one
administration, or large networks where, for example, maintenance of the routers
cannot be coordinated.
Drawback of the solution is that it deviates from common practice used in IP

network configuration (setting different network masks for node and router
interfaces). Configuration and network behavior is more complex which in turn
makes the solution more vulnerable for configuration mistakes and more difficult
to debug if there is a failures.
5.2 IP Backbone Recommendations

This section provides an overview of the IP Backbone recommendations.
For further details, see Application Information List of IP Backbone
Recommendations.
5.2.1 Network Separation
The entire IP backbone has to be divided into several ‘‘logical’’ networks in such a
way that the logical networks can be designed independently. This means that
on top of the shared IP infrastructure, additional measures must be taken so that
different logical networks interfere with each other as little as possible.
As an example a network could be divided into the following logical networks:
1. Voice Network (User plane and signaling)
2. OAM Network
3. Data Network
It must be possible that the IP addresses of different logical networks overlap,

that is, the same IP address can be used in different logical networks (by different
nodes). As a consequence, the routing in one logical network must be separated
from the routing in another logical network. Propagation of traffic or routing
information from one logical network into another logical network must be
required to be explicitly enabled by policies and only be enabled where needed.
Typical techniques to achieve this network separation are MPLS and BGP/MPLS
IP Virtual Private Networks (VPNs).
5.2.2 Path Diversity

The network must provide a means for Path Diversity, so that every Multi-Homed
SCTP Association between two endpoints (each endpoint thus providing at least
two IP addresses to the SCTP Association) is composed of at least two different
paths that have no common equipment (interfaces, cables, routers, L2 switches,
power supplies, and so on) and hence no common point of failure.
50 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Note: The typical mechanisms to provide Path Diversity are MPLS and routing
protocols (metrics).
Path Diversity is required for solutions that rely on SCTP or M3UA/SGsAP

redundancy mechanisms. If also the Signaling over SCTP/IP relies on resilience
of the underlying IP transport, the backbone has to implement fast recovery
mechanisms such as standby Label-Switched Path (LSP), Fast Reroute, or
Node-Link protection.
5.2.3 Transport Requirements

The following table summarizes the expected network Key Performance
Indicators (KPIs) for an Optimal Network, as detailed in Application Information
List of IP Backbone Recommendations.
Table 3 Transport Requirements for Signaling over SCTP/IP

Transport Parameter Required Value Note
Average Backbone < 50 ms This is the one-way delay
(1)
delay to be fulfilled by at least
95% of packets out of a
sample of at least 10,000
packets.
Maximum Backbone < 100 ms Exceeding this value
delay can cause unwanted
retransmission
(one way)
Packet loss ratio < 10-4 Packet reordering
must not occur more
frequently than a packet
loss.
(2)
Failover time None There is no specific
requirement on failover
times of the underlying
IP transport as long as
redundancy is handled
on SCTP or M3UA level.
Path Diversity (non fate
sharing paths) has to
be provided by the IP
backbone.
(1) This is the maximum tolerable average delay. Recommended delay depends on network scale:
International IP connections < 50ms, geographically large networks < 30 ms, geographically
medium networks < 20 ms, geographically small networks < 15 ms.
(2) It is a good design practice to provide a failover time below 3 seconds in the transport network.
Operations can be supported also in networks not fulfilling these requirements

but with different behavior and performance. In such a case, SCTP settings must
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 51

be tuned to accommodate the network characteristics. For further information,

see Section 6.1.8 on page 66.
5.2.4 Traffic Prioritization

CNCS nodes support setting of DSCP as mechanism for QoS. IETF RFC 4594,
Reference [50], recommends using class CS5 binary ‘‘101000’’ for signaling.
This is the suggested configuration; however it is not mandated to change to

this value if the network is already set up using a different class. It is however
important that all signaling packets have the same DSCP value consistently used
end-to-end and that the routers are able to separate them from the other traffic.
5.2.4.1 DSCP Setting
The DSCP setting in MSC-S is described in User Guide Managing IP Integration.
5.2.4.2 DSCP Setting in M-MGw
The DSCP setting in M-MGw is described in the following User Guides:
— For M3UA: User Guide for Signalling, Reference [42]
— For IUA: User Guide for Primary Rate Access, Reference [41]
— For GCP: User Guide for Virtual Media Gateway Handling, Reference [43]
52 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
6 How to Use
6.1 SCTP Parameter Settings

There is no unique range of SCTP parameter values able to suit all possible
scenarios. The effectiveness and the correctness of such values is highly influenced
by the node configuration (SH or MH), and by the network conditions (see Section
5.2.3 on page 51 for transport requirements). Also, the operator can require a
rather aggressive setting to detect failures as soon as possible but, on the other
hand, this can cause unwanted retransmissions.
This section provides several different parameter value sets, encompassing SH,
and MH scenarios. The basic assumption is that transport requirements are
fulfilled. If they are not fulfilled, the set of parameters must be adapted on a
case-by-case basis to the network conditions.
All listed parameters are specified in IETF RFC 4960, Reference [46] unless
differently indicated.
Section 6.1.8 on page 66 is dedicated to provide recommendations when the

network characteristics do not fulfill the recommended transport requirements
introduced in Section 5.2 on page 50.
For additional details about other SCTP parameter settings, see User Guide
Managing the Stream Control Transmission Protocol
6.1.1 Parameters for Path Handling
6.1.1.1 Path Selection Scheme
The IP Path selection is an independent procedure performed at each node.
It can operate in two Path Selection Schemes (PSSs) or modes:
— SCTP Path mode
— IP Path mode
Detailed description of IP path management and impact of configuration

parameters can be found in Function Specification IP Based Functions on CP,
SCTP Details.
Recommendation:
Use IP Path mode as PSS.
Note: Availability of this parameter depends on used SCTP O&M model in

MSC-S. If parameter is not available, IP Path mode is used.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 53

6.1.1.2 Switchback Modes
The following Switchback Modes are possible:
— No Switchback
— Immediate Switchback
— Exponential Switchback
Table 4 shows the IP Path management functions supported on SCTP

implementations.
Table 4 Path Management Functions on Different SCTP Implementations

Node Type SCTP Path Mode IP Path Mode
Supported Potentially Supported Potentially
Switchback Failed Function Switchback Failed Function
Modes Modes
CP Based SCTP • No switchback Supported • No switchback Supported
• Immediate • Immediate
• Exponential • Exponential
M-MGw • Immediate Not supported • No switchback Supported
• Exponential • Immediate
• Exponential
Recommendation:
Use Exponential Switchback as Switchback mode.
6.1.1.3 Potentially Failed (or Quick Failover) Function
The response time of IP Path Failover detection can be improved by enabling the
‘‘Potentially Failed’’ function. Potentially Failed function enables failover to take
place at an earlier phase before PMR is exceeded.
Potentially Failed function is enabled by configuring ‘‘potentially failed’’ threshold

PFMR (see Potentially Failed Maximum Retransmissions) to a value which is
below PMR value.
Recommendation:
Set PFMR threshold to value 0 (failover after first T3 time-out).
See User Guide Managing and Optimizing SS7 Congestion Control and SIGTRAN
Performance for more details.
54 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
6.1.1.4 Exponential Switchback Mode Thresholds for HEARTBEAT Probing Sequence
In case of Exponential Switchback Mode (as explained in Switchback Mode)

switchback to Primary Path is performed after successful execution of HBs
sequence. The length of this sequence is limited by lower (QSMIT) and upper
threshold (QSMAT).
Table 5 Recommended Settings for QSMIT and QSMAT

Parameter Recommended Value
QSMIT 1
QSMAT 120
See User Guide Managing and Optimizing SS7 Congestion Control and SIGTRAN
Performance for more details.
6.1.2 Timers and Counters for Path Handling
Counters in SCTP are dependent on whether Single-Homed SCTP Associations or

Multi-Homed SCTP Associations are deployed, and on the PSS. The difference is in
the parameter value for the SCTP Association retransmission (Assoc.Max.Rtx)
and path retransmission (Path.Max.Rtx) counters.
As explained further in Table 6, these two parameter values control the number of
retransmission attempts that are done after transmission time-outs.
In the SH case, there is only one SCTP Path to be attempted, thus Assoc.Max.Rtx
equals to Path.Max.Rtx.
In the MH case, more IP Paths can be attempted and the strategy is to give each
IP Path equal chance, thus Assoc.Max.Rtx equals to Path.Max.Rtx * no. of
SCTP Paths (SCTP Path Mode) or equals to Path.Max.Rtx * no. of IP Paths (IP
Path Mode).
In case two Single-Homed SCTP Associations are defined between two nodes,
redundancy is handled on M3UA level with two routes towards the same
destination, each link tied to an SCTP association residing on one interface.
For multi-homing, the network scenario is the one where an MH SCTP association
is defined between two nodes and redundancy is handled at SCTP level.
Recommendation:
The following ranges of SCTP and M3UA parameter values are recommended
to achieve failover times below three seconds and to ensure correct protocol
behavior.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 55

Note: Individual nodes have default parameter values widely covering general
cases. Therefore, for certain parameters different default values to
those listed in Table 6 can be found in node documentation. If there is
a mismatch with the parameter values indicated in this User Guide, the
values stated here apply.
The suggested parameter values are based on the transport requirements

in Section 5.2.3 on page 51. By different transport characteristics, the
parameter values can and have to be further tuned and adapted to these
conditions.
Table 6 Recommended SCTP Parameters

Parameter Recommended Recommended Recommended Description
Value for SH Value for MH Value for MH
Scenario Scenario (SCTP Scenario (IP
(1) (1)
Path Mode) Path Mode)
RTO.Min 200 ms 200 ms 200 ms Lower bound for
the Retransmi
ssion Time-out
(RTO). If this
value is too small,
fluctuations of
the Round-Trip
Time (RTT) can
cause spurious
time-outs.
Setting it higher
increases the
minimum failure
detection time
and limits
the maximum
throughput
during the
failover detection
period.
56 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use

(1) (1)
RTO.Max 800 ms 800 ms 800 ms Upper bound for
the RTO. If this
value is chosen
smaller than the
maximum RTT
that occurs on the
path, spurious
time-outs result
that reduce
performance
and can trigger
unnecessary
failover decisions.
On the other
hand, choosing
smaller values
reduces the
failure detection
time. Reducing
RTO.Max also
results in making
SCTP more
aggressive than
TCP, since it limits
the exponential
timer back-off.
RTO.Init 400 ms 400 ms 400 ms Initial RTO that
is used before
the first RTT
measurement.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 57


(1) (1)
SACK.Delay 40 ms 40 ms 40 ms Maximum time
an SCTP receiver
can wait after
the arrival of a
packet before it
acknowledges
this packet.
This can help
to reduce traffic
on the return
path. However,
setting this value
too high can
increase the
effective RTT and
leads to spurious
time-outs in case
of aggressively
chosen RTO
parameters.
Path.Max.Rtx 2 4 2 for M-MGw Number of
consecutive RTOs
4 for MSC-S after which an
SCTP EP decides
that a destination
(path) is inactive.
This together
with RTO.Min
determines the
minimum failover
detection period.
Setting the value
higher increases
the failover
detection time,
setting it lower
increases the risk
that spurious
time-outs lead to
an unnecessary
failover decision.
58 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use

(1) (1)
Assoc.Max.Rtx 2 8 8 Number of
consecutive RTOs
after which an
SCTP EP decides
that an SCTP
Association is
unavailable.
Max.Init.Rtx 8 8 8 Number of
consecutive
SCTP association
establishment
trials at the STCP
level after an
SCTP association
establishment
request from
SCTP User.
(1) See Section 6.1.1.1 on page 53
Applying the parameter previous values results in the following fault detection
time (assuming that the RTO in the exact moment of the failure is equal to
RTO.Min):
Single-Homed SCTP Endpoints

The first retransmission happens after RTO, the second happens after RTO *2 and
up to RTO.Max as from retransmission rules in IETF RFC 4960, Reference [46].
The destination is thus declared unreachable after 200 + 400 (first retry)
+ 800 (second retry) = 1400 ms.
Note: The factor 2 is actually the back-off factor indicated in the IETF RFC 4960,
Reference [46]. For the CP-based SCTP, this value is calculated from
configuration parameter RTOBF (depending on the SCTP O&M model
used, default value of parameter RTOBF, gives back-off factor lower than 2
(1.57) and this lowers the overall computation for such implementation).
Multi-Homed SCTP Endpoints

In this scenario, the fault detection time is less important because the failure of
one destination is handled internally in SCTP and typically is within an RTO.
A non-acknowledged packet is in fact always retransmitted towards a different

destination and, before declaring a destination unavailable, all possible
combinations of source-remote address are attempted.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 59

The RTO value is kept for each destination and, assuming that the RTO in the
exact moment of the failure is equal to the RTO.Min, if there is a complete failure
of the remote end, the following applies:
The first retransmission happens after RTO, the second happens after RTO *2
and up to RTO.Max as specified in IETF RFC 4960, Reference [46]. In the worst
case of one single packet to be sent, all the timers run sequentially and the fault
detection time would be > 7 seconds.
However, in the normal case different packets can be sent to a different SCTP
path. This causes the retransmission timer to be started and run in parallel to
another path retransmission timer. This brings the detection time below 6 seconds
and typically in the range 2.5–2.8 seconds.
Note: The factor 2 is actually the back-off factor indicated in the IETF RFC 4960,
Reference [46]. For the CP-based SCTP, the value of back-off factor is
calculated from configuration parameter RTOBF (depending on the SCTP
O&M model used, default value of parameter RTOBF, gives back-off factor
lower than 2 (1.57) and this lowers the overall computation for such
implementation).
Recommendation:
If the node is configured with both SH and MH SCTP associations, node-specific

capabilities apply. If the node allows different settings for different SCTP
associations, each SCTP association must have its own setting. If the node
allows one common setting for all the SCTP associations, then the setting for
MH associations applies.
6.1.3 Buffers and Windows

Proper dimensioning of window and buffer size allows controlling the stability
of SCTP associations and the degree of resilience against adverse network
conditions causing burst and delay of incoming data.
The parameter values Table 7 are not influenced by the configuration as MH or

SH SCTP association. However, in case of MH configuration, the fault detection
time is longer because all possible paths are attempted. Therefore the buffer
dimensioning has to consider this longer fault detection time.
Note: The possible parameter values depend on the number of SCTP

associations defined on a single board and the available memory on the
board itself. For instance, the sum of the SCTP buffer sizes for all SCTP
associations cannot exceed a certain value. The exact value is subject to
revision therefore it is recommended to consult node level documentation
for further information.
60 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
Table 7 Recommended Values for Buffers and Windows

Parameter Recommended Value Description
BUF 256 Kibibytes SCTP send buffer size.
Sets the size of the buffer used
to store user-data pending to
send or retransmit in an SCTP
association, that is, establish
the maximum amount of
data that SCTP stores before
discarding user messages.
(1)
THR 128 Kibibytes Send buffer threshold.
Sets the value of the threshold
used to ask the SCTP User to
stop the delivery of data on an
SCTP association. Once THR
or more bytes are queued and
are pending to send, the SCTP
layer issues an indication to
the user.
Congestion abatement 40 Send Buffer congestion
(1)
threshold abatement threshold
(LOLEVCONG, LOWTHRESH,
LOWTHRESHOLD).
Only for CP Based SCTP

Congestion abatement 40 Send Buffer congestion
(1)
threshold abatement threshold (CATHR).
(1)
Congestion onset threshold 50 Send Buffer congestion
abatement threshold (COTHR).
(2)
A_RWND • 32 Kilobytes Initial value of advertised
receiver window.
The initial value of A_RWND
together with the RTT
(network property) reflects the
maximum data consumption
performance of the receiver.
It has to be set so that each
SCTP association can exploit
the maximum performance of
the receiver.
(1) Availability of this parameter depends on the SCTP O&M model used.
(2) RBS – Receiving Buffer Size for CP Based SCTP and specific SCTP O&M model
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 61

Note: The advertised receiver window and the RTT control the throughput
of an SCTP association. Any sender cannot have more than A_RWND
outstanding data (that is, data not yet acknowledged) towards a given
destination. The acknowledgment comes within RTT. Therefore a peer
can send A_RWND data per RTT interval according to the formula:
Throughput = A_RWND / RTT
RTT is not simply 2*one_way_delay but also includes internal delays such
as scheduling delays. This User Guide simplifies the formula, however,
real calculation take all the contributions into consideration.
RTT = 10 ms
A_RWND = 8 Kbytes
Throughput = 8 Kbytes/10 ms = 800 kbyte/s = 6.4 Mbit/s
RTT = 10 ms
A_RWND = 32 Kbytes
RTT = 100 ms
A_RWND = 64 Kbytes
Example 1
Example 2
But also:
RTT = 10 ms
A_RWND = 64 Kbytes
Throughput = 64 Kbytes/10 ms = 6400 kbyte/s = 51 Mbit/s
As seen, the last setting could cause bursts of signaling toward one node, thus the
changing of A_RWND must be considered carefully. Even though 51 Mbit/s could be
considered a high value, it is only the theoretical throughput over the transport
network. In reality, the speed is limited by the consumption speed of the receiver.
The consumption speed is how fast the receiver SCTP layer can deliver data to
its users.
In any case, the throughput calculation around A_RWND is highly theoretical.

A_RWND must be set to well above what is needed to achieve the theoretical
throughput of A_RWND/RTT.
If the calculated throughput is too low, given the current maximum value for
A_RWND, multiple parallel SCTP associations can be used. In this case SCTP rules
must be observed: at least one of the values for the tuple source IP address,
remote IP address, and port number must be changed.
During congestion situations (that is, when A_RWND is zero) the sending node
probes the receiving node to check if the congestion situation has ceased. One
SCTP packet is sent. The receiver sends a SACK: if congestion situation persists,
62 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
the SACK does not step the Cumulative TSN Ack Point, otherwise the TSN is
stepped up and communication resumes.
MSC-S and M-MGw send spontaneous SACK when A_RWND changes from 0 to a
higher value. 0 here is any value in the range [0 - MTU size], that is whenever
the amount of free receive buffer space exceeds 1 Maximum Transmission Unit
(MTU), a spontaneous SACK is generated.
In M-MGw, the spontaneous SACK is generated when 50% threshold for free
receiver window has been crossed.
Note: Not all older M-MGw releases have this feature.
6.1.4 Protocol Data Unit
The size of the SCTP packet is referred to as Protocol Data Unit (PDU) in this
document.
The following relationship expressed in octets (Bytes) must be kept when IPv4
is used:
Protocol data unit size + IP header size <= IP MTU size ⇒
- IPSec header size
Where:
— The IPsec header size can vary but a typical value is 64 octets (IPsec with
AH/ESP tunnel, Authentication Header (AH) MD5, and ESP 3DES).
— The IP header size is in the range between 20 and 60 octets, depending on

the Options field, where a typical value is 20 octets.
— The data chunk header is 16 octets.
— The common SCTP header is 12 octets.
— IP MTU size can vary but a typical value is 1500 octets.
If the IPsec header size is 64 octets, IP header size is 20 octets and the IP MTU
size is 1500, the PDU size must be set as follows:
Protocol data unit <= 1500 - 64 - 20 = 1416 octets.
Table 8 shows the parameter names used in nodes for setting the previously
explained PDU size.
Table 8 Parameters for PDU Size Configuration

MSC-S M-MGw
MTU maxUserdataSize
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 63

6.1.5 Number of Streams
SCTP can specify at SCTP association startup time the number of Streams to be
supported by the SCTP association. This number is negotiated with the remote
end.
Depending on the SCTP O&M model used, maximum number of Streams allowed
by the SCTP User can be set for selected SCTP EP and SCTP associations without
impacting the signaling traffic over other SCTP users.
Recommendation:
In some nodes (depending on the SCTP O&M model used) the Stream setting
is global for all associations, therefore if more protocols have to be deployed
(M3UA, GCP, and so on, except the M2PA) the highest needed Stream number
must be used.
Proper planning is needed because if the addition of a new protocol is done when
the node is already in operation, depending on the SCTP O&M model used, the
existing connections must be undefined before changing the Stream number.
Number of Streams Setting for M3UA

In ITU standards, the SLS field of the MTP3 Routing Label is used to select an
SCTP Stream. The ITU and China standards support 16 SLS values, and thus a
maximum of 16 SCTP Streams is needed for transferring DATA messages. The
SCTP Stream identifier 0 is reserved for M3UA management messages. Therefore,
17 Streams is the maximum number of Streams that can be used in ITU and China
markets by M3UA.
In ANSI market, up to 257 Streams can be used by M3UA.
Table 9 Recommended Value for Number of Streams at SCTP Association

Startup (for ITU, CCSA, TTC, and ANSI Standards)
Parameter Recommended Value Description
Incoming Stream 17 Maximum number of
incoming streams for an
SCTP association
Outgoing Stream 17 Maximum number of
outgoing Streams for an
SCTP association
Number of Streams Setting for IUA

For PRA IUA ensures in-sequence delivery by sending the messages for one
D-Channel over one SCTP Stream. When the number of negotiated streams is
lower than the number of D-Channels handled by the association, IUA uses one
stream for more than one D-Channel, still achieving the in-sequence delivery
for all D-Channels.
64 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
Number of Streams Setting for SGsAP

For SGsAP, no particular fixed number of incoming/outgoing streams is
recommended. Any number >= 8 is deemed sufficient to prevent head-of-line
blocking problems. The default value of 16 for SGs on MSC-S is therefore good
enough to be used.
Number of Streams Setting for GCP over SCTP

MSC-S and M-MGw choose the Stream differently and the setting is therefore
bound to node individual limit. The general rule is that as many Streams as
possible must be used.
Note: An asymmetric configuration does not harm because, in theory, IP routing

in incoming and outgoing direction can be such that two different
paths in the IP network are followed. The following setup is therefore
recommended:
Recommendation:
If the Stream setting is global for all associations, MIS and OS or MOS, depending
on the SCTP O&M model used, must be set to the maximum allowed value in
MSC-S and M-MGw. The SCTP protocol then negotiates the number of Streams.
Number of Streams Setting for M2PA

The SCTP association used for an M2PA link uses two Streams in each direction.
Recommendation:
Both incoming and outgoing Stream value must be set to 2.
6.1.6 SCTP Bundling

Recommendation:
SCTP bundling is highly recommended for performance reasons. Both

individual nodes and the whole network benefit from bundling.
Note: SCTP bundling denotes the encapsulation of more than one SCTP MSU
into one SCTP packet. SCTP bundling can reduce the number of packets
thus can increase throughput and reduce the load (on the nodes that
concentrate traffic similarly to MSC-S). Therefore, it is recommended
that peer nodes also use SCTP bundling on SCTP associations towards
the MSC-S.
6.1.7 Zero Receiver Window Supervision

The Zero Receiver Window Supervision feature allows SCTP to limit the duration
of the Zero Window. The feature is controlled by the ‘‘Zero Receiver Window
Supervision timer’’ parameter (see Zero Receiver Window Supervision Timer).
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 65

The timer is started at entering into zero window condition and stopped at
termination of zero window condition.
SCTP ungracefully closes the association (ABORT is sent with cause code ‘‘User
Initiated Abort’’) at the expiration of this timer.
Recommendation:
Use the Zero Receiver Window Supervision feature.
Set the Zero Receiver Window Supervision timer to the following value:
4 * RTO.Max * Assoc.Max.Rtx.
6.1.8 Tailoring of SCTP Parameters

As mentioned in Section 5.2.3 on page 51, Signaling over SCTP/IP traffic requires
certain transport characteristics from the underlying IP or MPLS network.
When the IP network does not fulfill such transport characteristics, SCTP protocol
can be adapted by tuning certain parameters. This adaptation has consequences,
for example, for performance and fault detection.
An important aspect to highlight is that proper node dimensioning must be done

for buffering if needed. For example, in MSC-S appropriate setting of file sizes (for
more information see SAE 500 in Application Information M3UADR) is needed.
Node-specific documentation must be checked.
6.1.8.1 Long Delay
SIGTRAN itself is relatively robust against delay of up to a few hundred

milliseconds. It can also work over satellite links where one-way delay is typically
more than 300 ms (RTT in the range of 1 second). As indicated further below,
a longer delay influences the throughput therefore the performances in such
conditions can be limited.
When longer delays (and also likely larger delay variations) occur then a trade-off
between sensitivity to detect packet loss and the ability for fast detection of SCTP
association loss must be considered. Increasing the round-trip timer thresholds
leads to less sensitivity against long delays but also increases failure detection
time and delay for application messages when retransmissions occur.
By just considering longer delays, sensitivity is ranked higher than long application
delays and failure detection times, based on the assumption that the IP network
has only minor packet loss even with longer delays. For high packet loss, see
Section 6.1.8.2 on page 69.
In case of longer delay, the round-trip timer thresholds must be tailored

accordingly.
The generic rule is the following:
66 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
Recommendation:
RTO.Min > 2*average_one_way_delay
(and in any case not lower then 100ms).
Note: Even for the case where no delay exists (for example LAN), the lower
limit is still set to 100 ms. Below that value, possible delay variation can
cause too many spurious time-outs.
RTO.Max >> 2*maximum_one_way delay + sack delay on

remote end
(and in any case not lower than 400ms).
Note: Even for the case where no delay exists (for example LAN), the upper
limit is still set to 400 ms. Above that value, possible delay variation can
RTO.Init (RTO.Min =< RTO.Init =< RTO.Max)
Average delay (one way) < 200 ms

Max delay (one way) < 400 ms
SACK delay 40 ms
RTO.Init → 600 RTO.Min → 400 RTO.Max → 900
Example 3

SACK delay 20 ms
Example 4
The values of RTO, RTO.Min, and RTO.Max strictly govern the fault detection time
of an SCTP association, with the values of AMR and PMR. In the two previous
examples, and generally speaking in all cases where a longer RTT is needed, the
fault detection time is longer accordingly. In other words, in case of failure it takes
longer for SCTP to realize that the SCTP association has to be turned down.
Although the operator should know the expected minimum and maximum packet
delays from network design, it is recommended to fine-tune RTO.Init, RTO.Min,
and RTO.Max parameters based on delay measurements.
— The value of Smoothed SCTP Round-Trip Time (SRTT) can be obtained from
the result printout of command IHSSP.
Another parameter to consider is the advertised receiver window (A_RWND). The

combination of A_RWND and RTT determines the maximum throughput of an SCTP
association according to the formula:
Throughput = A_RWND / RTT
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 67

For a given A_RWND value, the throughput decreases when the RTT increases.
Therefore, it is important to adapt A_RWND to the increased delay.
Some examples:
RTT = 400 ms
A_RWND = 8 Kbytes
Throughput = 8 Kbytes/400 ms = 20 kbyte/s = 160 kbit/s
Example 5
RTT = 600 ms
A_RWND = 8 Kbytes
Throughput = 8 Kbytes/600 ms = 13,3 kbyte/s = 106 kbit/s
Example 6
The generic rule is the following:

A_RWND > max_wanted_throughput * (2*avg_one_way_delay)

Wanted throughput 1 Mbit/s
A_RWND → 50 Kbytes
Example 7

Wanted throughput 1 Mbit/s
A_RWND → 75 Kbytes
Example 8
Here, node-specific limitations can apply (for example the A_RWND limit in MSC-S is
64K) thus a lower throughput is achieved. Node documentation must be consulted
for the possible values.
Throughput limitation can cause buffer exhaustion of the SCTP send buffer and
congestion indication sent from SCTP to SCTP user as the individual node can still
try to send at higher speed than SCTP can reach.
Note: Thus careful dimensioning must be done and in the extreme case more
SCTP associations must be defined.
Moderate increase (for example 25%) of BUF (and THR accordingly) can be done
to compensate the lower throughput after a packet loss (slow start procedure in
SCTP). Still, congestion cannot be avoided in all cases, but that is a consequence
of the packet drop.
68 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
Note: The amount of available memory is specific to the node; therefore any
change in this area must be done by considering the available resources
because of the potential impact on the number of sustainable SCTP
associations.
6.1.8.2 High Packet Drop Ratio
SCTP handles packet retransmission, thus it is able to deal with packet loss.
Note: There are two types of packet loss. One is random single packet loss
caused by Random Early Deletion algorithms frequently used by routers
to prevent congestion. The second one can be characterized by bursts
of packet loss which, for example, can be caused by (frequently) failing
equipment.
SCTP detects packet loss by expiration of RTO for any packet that is retransmitted.
A high packet loss ratio has impacts on SCTP association throughput. In these
conditions, the slow-start procedure of SCTP reduces the performance as it
considers the IP network congested.
This section proposes adaptation of parameters prioritizing SCTP association

throughput and stability of SCTP associations as target.
The throughput can be improved by increasing A_RWND so that during the

error-free times performance can be maximized.
Note: Thus setting A_RWND to a higher value (64 kilobytes) is recommended.
Stability analysis of SCTP association needs to consider how long the error bursts
can be. Engineer RTO timers so that the error bursts are detected fairly exactly,
specifically detecting the end of the error burst well.
Since RTO.Min and RTO.Max are limiting the time period between two probes to
detect that the error burst has ended again, it is suggested to decrease RTO.Max
and RTO.Min to a lower value. Reducing SACK_delay also reduces the RTT and
thus improves throughput.
However, this must be balanced by an increasing of AMR and PMR, otherwise the
SCTP association can go down because of spurious time-out.
Recommended setting (MH SCTP association taken as reference):

SACK_delay = lowest allowed value
RTO.Max = 200 ms
RTO.Min = 50 ms
PMR = 6
AMR =12
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 69

6.1.8.3 Long Delay and High Packet Drop Ratio
A combination of high packet loss ratio and long delay makes things worse
because the slow start period is longer (for example it takes longer for the SCTP
association to resume its maximum throughput).
If a combination of packet loss and long delay exists, RTO.Max must be set to the
maximum given by the formula for long delay, and RTO.Min set to a low value
(for example 50 ms). In this case, RTO is governed by the actual calculation of
RTT made by SCTP without imposing any strict MIN limit. This can allow early
detection of packet loss by SCTP if the average delay improves in the IP network.
The following setting is recommended:

SACK_delay = lowest allowed value
RTO.Max = > 2*maximum_one_way delay + sack delay on
remote end
RTO.Min = 50 ms
For the long delay case, throughput limitation affects buffering so the same
considerations apply.
6.1.8.4 Satellite Connections
SCTP over satellite connection can be considered as subset of the ‘‘long delay’’ use
case described in Section 6.1.8.1 on page 66, where one-way delays are typically
in the range of >300 ms (RTT in the range of 1 second).
Therefore the same rule applies:

- RTO.Min > 2*average_one_way_delay
(and in any case not lower then 100ms).
Note: Even for the case where no delay exists (for example LAN), the lower
limit is still set to 100 ms. Below that value, possible delay variation can
- RTO.Max >> 2*maximum_one_way delay + sack delay on

remote end
(and in any case not lower than 400ms).
Note: Even for the case where no delay exists (for example LAN), the upper
limit is still set to 400 ms. Above that value, possible delay variation can
- RTO.Init (RTO.Min =< RTO.Init =< RTO.Max)

SACK delay 40 ms
Example 9
70 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
As explained earlier, long delay reduces the throughput to a low value. Therefore,
A_RWND must be set to the highest possible value and SACK_delay must be set
to the lowest possible value.
For further information, see and User Guide for Signalling, Reference [42] for
M-MGw.
6.1.8.5 Bundling
Bundling efficiency (expressed in number of MSUs per SCTP packet), depends

on the outgoing message rate and the Local Bundling Timer (LBT) value set
on an SCTP association. It is therefore critical to set the bundling timer to a
value which can guarantee bundling of high number of MSUs per SCTP packet
thus reducing number of packets needed to achieve the required MSU rate per
second. Otherwise, bundling (although enabled) does not help in increasing the
performance of both the individual node and the whole network.
Note: The maximum number of MSUs in one SCTP packet is limited by the
maximum size of the SCTP packet (see Section 6.1.4 on page 63).
In Example 10 the effect of LBT on the number of transmitted packets per second
is presented:
Outgoing traffic rate=100 MSU/s

Bundling timer = 10ms
number_of_MSUs_per_SCTP_packet = 1 MSUs
number_SCTP_packet_per_second = 100 packets

number_of_MSUs_per_SCTP_packet = 5 MSUs
number_SCTP_packet_per_second = 20 packets

number_of_MSUs_per_SCTP_packet = 8 MSUs (this might be limit due to SCTP packet size)
number_SCTP_packet_per_second = 100 packets (this might be higher value due to limited
number of MSUs in SCTP packet)

number_of_MSUs_per_SCTP_packet = 40 MSUs (this might be limit due to SCTP packet size)
number_SCTP_packet_per_second = 20 packets (this might be higher value due to limited
number of MSUs in SCTP packet)
Example 10
As illustrated, by configuring the bundling timer to the proper value the number of
packets in the network can be reduced.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 71

In Table 10 the effect of LBT=50ms is shown for different values of MSU rate and
MSU length. Cells where the number of octets received from SCTP User exceed
MTU (see Section 6.1.4 on page 63) are grey filled. In these cases, it is likely that
SCTP transmits fully seized (MTU) packet before LBT expiry.
Table 10 Bytes Sent during LBT Period (LBT=50ms)

Outgoing MSU
100 200 300 400 500 1000 2000 5000
Rate (MSUs/s)
Sent MSUs Duri
5 10 15 20 25 50 100 250
ng LBT=50ms
Octets Sent
During LBT
300 600 900 1200 1500 3000 6000 15000
(MSU=60
octets)
Octets Sent
During LBT
500 1000 1500 2000 2500 5000 10000 25000
(MSU=100
octets)
Octets Sent
During LBT
750 1500 2250 3000 3750 7500 15000 37500
(MSU=150
octets)
Recommendation:
For applications that are sensitive to additional delay introduced by bundling,

it is recommended to set LBT to a value that fulfills the requirement of the
applications on delay.
For applications that are not sensitive to additional delay introduced by

bundling, it is recommended to set LBT according to Equation 1.
MT U
LBT
MSU rate 2 MSU average length
Equation 1 Recommended LBT Setting
72 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
6.2 Network Configuration Examples
6.2.1 Configuration in M3UA Network
HLR
SGW 1
TDM POI
MSC-S
Compact
SGW 2
IP
TDM
SPX2
M-MGw BSC
1
SPX1
MSC-S
BC
ATM
M-MGw
2 RNC
Figure 31 Configuration in M3UA Network
Figure 31 shows the following network layout:
— The POI node supports Quasi-Associated Signaling Mode and is connected in

a multiple SGW scenario to SGWs of other vendors.
— The BSC supports Associated Signaling Mode and is connected in a single

SGW scenario to an M-MGw. The control signaling relation for the A-Interface
is between the Compact MSC-S and the BSC. For this purpose, the feature
‘‘Associated Mode of Signaling’’ is configured in M-MGw.
— The RNC supports Quasi-Associated Signaling Mode and is connected in a

multiple SGW scenario to the two M-MGws. The control signaling relation for
the Iu-Interface is between the MSC-S BC and the RNC.
— The M-MGws, SGWs of other vendors and the HLR are connected to the
Compact MSC-S using one Multi-Homed SCTP Association. If the SGWs are
SH, two Single-Homed SCTP Associations are needed between each SGW
and Compact MSC-S .
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 73

— The M-MGws, SGWs of other vendors and the HLR are connected to the
MSC-S BC using two MH SCTP associations, each one towards one of the two
SPXs. If the SGWs are SH, two SH SCTP associations are needed between
each SGW and each SPX in MSC-S BC.
— The same MH SCTP association between MSC-S DB and M-MGw and MSC-S
BC and M-MGw can be shared for all signaling application protocols.
6.2.1.1 Configuration in MSC-S
This section describes MSC-S BC configuration only, as shown in Figure 31.
The feature ‘‘Signaling Transport over IP (SIGTRAN)’’ must be activated.
The SCTP configuration requires the following steps:
— Multi-Homed SCTP Endpoint definition in each SPX of the MSC-S to be used

by M3UA
Configure the following parameters:
• Mode behavior (‘‘client’’ or ‘‘server’’)
IETF RFC 4666, Reference [47], recommends that one endpoint takes the
role of ‘‘client’’ and the other endpoint takes role of ‘‘server’’. Therefore,
the following scenarios are possible:
Note: The used scenario depends on the mutual agreement between

operator or vendor of peer node.
MSC-S Peer Node

‘‘client’’ ‘‘server’’
(1)
‘‘client’’ ‘‘peer’’
‘‘server’’ ‘‘client’’
(1) This scenario is recommended towards other Ericsson nodes.
The behavior mode defined for the SCTP EP automatically applies to any
SCTP association defined on the SCTP EP.
— SCTP association definition from the MH SCTP EP in each SPX of the MSC-S
to each peer SCTP EPs in HLR, SGWs, and M-MGws
• IP address(es) and port number of the peer SCTP EP
The M3UA configuration requires the following steps:
— Own SPC definition. If multiple NIs are used, one own SPC for each NI value
is needed.
74 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
— Definition of SPC of the peer nodes (HLR, RNC, and POI) reachable by IP
network only.
— Route definition.
• Two routes in load-sharing mode from each SPX of the MSC-S to the POI
through the two SGWs. The load-sharing scheme is according to the
predefined pattern. On these routes, MSC-S can be configured to behave
as either ESP or ASP depending on M3UA protocol support in the SGWs.
ASP can always be used in this case, but it can complicate configuration.
If ESP is used, then the M3UA behavior must be configured. In this case,
the behavior towards SGWs of other vendors must be configured as
‘‘peer’’.
Recommendation:
Use ESP process type whenever possible.
• Two routes in load sharing mode from each SPX of the MSC-S to the
RNC through the two M-MGw. Load sharing scheme is according to the
predefined pattern so that each M-MGw receives an equal amount of odd
and even SLS values. MSC-S is configured to behave as ESP.
• One route from each SPX of the MSC-S to BSC connected through one
M-MGw. MSC-S is configured to behave as ESP. The M3UA behavior
must be configured and it has to be ‘‘peer’’.
• One route from each SPX of the MSC-S to HLR. MSC-S is configured to
behave as ESP. The M3UA behavior must be configured. The behavior
can be configured as either ‘‘peer’’ or ‘‘server’’.
Note: Configuration of M3UA behavior mode is only available in MSC-S. The

M3UA behavior and SCTP behavior are independent: the SCTP behavior
determines which side initiates SCTP association establishment whereas
M3UA behavior determines which M3UA process can send certain M3UA
messages. So it is perfectly legal to have the SCTP behavior as ‘‘client’’
and M3UA behavior as ‘‘server’’, although it is an easier approach to align
configurations on M3UA and SCTP level for the same SCTP association.
For a detailed description of configuration in MSC-S, see User Guides MSC-S

Configuration Management and Message Transfer Part 3 User Adaptation Layer.
6.2.1.2 Configuration in M-MGw
This section describes the configuration in M-MGw connected to MSC-S BC.
Each M-MGw connected to MSC-S BC shown in Figure 31 requires the following

configuration.
The SP configuration requires the following steps:
— Own SPC definition:
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 75

• If multiple signaling stacks are used, own SPC(s) is needed for each
signaling stack. Recommendations for distribution of traffic across
multiple stacks are provided in User Guide for Signalling, Reference [42].
• If multiple NIs are used within a signaling stack, one own SPC for each
NI value is needed.
• When the Associated Signaling Mode feature is configured in SGW, the

own SPC is needed for this feature. This SPC is not visible externally and
can be shared with other M-MGw nodes as own SPC for ‘‘Associated
Mode of Signaling’’. This own SPC cannot be used for other signaling
traffic than for the nodes requiring support for ‘‘Associated Signaling
Mode’’ (BSC). For a detailed description and configuration in M-MGw, see
User Guide for Signalling, Reference [42].
— Definition of destinations reachable through IP network:
• Signaling Route Sets for Own SPC ‘‘Radio Access Network’’ (SPX1 and
SPX2 of MSC-S).
Note: The routing configuration towards BSC and RNC is out of the
scope of this document. See User Guide for Signalling, Reference
[42], for further information.
• Signaling Route Sets for Own SPC ‘‘Core Network’’ (SPX1 and SPX2 of
MSC-S).
• Signaling Route Sets for Own SPC ‘‘Associated Signaling Mode in SGW’’
(SPX1 and SPX2 of MSC-S).
Note: The routing configuration towards BSC and RNC is out of the
scope of this document. See User Guide for Signalling, Reference
[42], for further information.
— SCTP EP definition to be used by M3UA adaptation layer. In a multiple stack

configuration, a dedicated SCTP EP is created for each stack.
— SCTP association definition from the SCTP EP in M-MGw towards peer SCTP
EPs in SPXs in MSC-S
The following SCTP associations are needed for each own SPC:
• SCTP association definition for SPX1
• SCTP association definition for SPX2
— Configure the following parameters:
• Local port number and endpoint instance. This defines the local SCTP EP.
76 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
• Behavior of local SCTP EP (‘‘SH’’ or ‘‘MH’’)
Recommendation:
Recommended as MH.
• IP address(es) and port number of the peer SCTP EP
Recommendation:
Recommended as ‘‘client’’ towards SPXs.
Note: If the behavior mode is set to ‘‘client’’, M-MGw operates as

client-peer. That is, client on M-MGw provides the same level of
functionality as peer mode on MSC-S or IP-STP.
— Route definition
The following definitions are needed for each own SPC:
• One route to SPX1.
• One route to SPX2.
• Two routes in load sharing mode to the MSC-S through the two SPXs.
The ‘‘Associated Signaling Mode in SGW’’ configuration requires the following

steps:
— Definition of mapping between SS7-SEP or SS7-STP SPCs and MSC-S SPCs

under the own SPC for ‘‘Associated Signaling Mode’’:
• Map MSC-S towards BSC
Note: The name BSC is used to highlight the fact that there can be
several BSCs connected to the M-MGw. Different BSCs can be
controlled by MSC-Ss of different architecture, and the mapping
is done accordingly. In Figure 31, these BSCs are called ‘‘BSC’’
for editorial convenience.
Note: This SPC can be used only for traffic to or from BSC. SEP or STP/SGW
signaling traffic to or from other nodes (M-MGw and RNC) must not be
transferred through this SPC.
For a detailed description of configuration in M-MGw, see User Guide for

Signalling, Reference [42].
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 77

6.2.2 IP-STP in SPX Connectivity
This section describes the recommended configuration of links between IP-STPs

configured in SPXs. Figure 32 shows an example where IP-STP A and IP-STP B
are mated Ericsson IP-STPs configured in SPXs. IP-STP A and IP-STP B have
connectivity to both IP- and TDM-based access segments (ATM would also be
possible instead of TDM). IP-STP A and IP-STP B have connectivity also to the
mated IP-STPs pair of another vendor, IP-STP/SGW C and IP-STP/SGW D.
The description in the rest of this section is from the perspective of the mated
Ericsson IP-STPs. Connectivity of the mated IP-STPs of other vendors is not
further considered.
M2PA STP/SGW
3 A
TP C
M
IP-STP
SS7-SEP
PA
MT
M2
P3
M2PA
UA
M3
M2
PA
IP-SEP
M3 B M2PA STP/SGW
UA D
IP-STP
Figure 32 IP-STP Connectivity
Recommendation:
Use M2PA between:
— IP-STP A and IP-STP/SGW C
— IP-STP A and IP-STP/SGW D
— IP-STP B and IP-STP/SGW C
— IP-STP B and IP-STP/SGW D
Only consider using M3UA if IP-STP C and IP-STP D do not support M2PA.
78 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
The link between IP-STP A and IP-STP B is not always needed, as detailed in
Section 6.2.2.1 on page 79 and Section 6.2.2.2 on page 79.
Recommendation:
Use several redundant M2PA links between IP-STP A and IP-STP B when this is
needed.
Only consider M3UA if one IP-STP A or B is mated to the IP-STP of another vendor
which does not support M2PA and no SS7-SEP is present in the access segment.
The presence of SS7-SEP in the access segment excludes the possibility to use
M3UA because an Ericsson IP-STP does not allow switchback from TDM/ATM to
IP type of bearer if the TDM/ATM link goes out of service because of hardware
failure.
6.2.2.1 Single Hardware Failure Protection
In line with Ericsson recommendations, the connectivity between IP-SEP and

respectively IP-STP A and IP-STP B in Figure 32 is assumed to be based on
MH SCTP associations. It is further assumed that over an MH SCTP association
hardware redundancy is applied at IP-SEP and IP-STP. Therefore protection from
single hardware failure is ensured by multi-homing and hardware redundancy
within the MH SCTP association. Under these conditions, the use of redundant
M2PA links between IP-STP A and IP-STP B does not bring any additional benefit
and therefore these can be avoided if no SS7-SEP is present in the access segment.
Recommendation:
If SS7-SEPs are present in the access segments as illustrated in Figure 32 and if

these nodes do not support hardware redundancy, then it is recommended to
configure the redundant M2PA links between IP-STP A and IP-STP B.
The routes defined through the redundant M2PA links must be assigned lower
priority so that they are not used in load-sharing mode with the M3UA routes.
6.2.2.2 Double Hardware Failure Protection
In case protection against double hardware failure is wanted, the use of redundant
M2PA links between IP-STP A and IP-STP B depends on whether these nodes
support SRP or FNR functions.
In case IP-STP A and IP-STP B do not support SRP or FNR functions, then the
use of redundant M2PA links between IP-STP A and IP-STP B does not bring
any additional benefit because at double hardware failure on a link in the access
segment, MTP3 Network Management messages between the IP-STPs trigger
network rerouting towards the link on the access segment which is still in service.
Recommendation:
If IP-STP A and IP-STP B support SRP or FNR functions, then it is recommended

to configure redundant M2PA links between IP-STP A and IP-STP B.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 79

The routes defined through the redundant M2PA links must be assigned lower
priority so that they are not used in load-sharing mode with the M3UA routes.
6.2.2.3 Configuration in IP-STP
The features ‘‘Signaling Transport over IP (SIGTRAN)’’, ‘‘Support of M2PA’’ and

‘‘Signaling Gateway’’ must be activated in SPXs.
The function ‘‘IP to TDM/ATM failover’’ must be enabled in SPXs if the M2PA link
between IP-STP A and IP-STP B is used.
— MH SCTP EP definition for M3UA and M2PA. Configure the following

parameters:
IETF RFC 4666, Reference [47], recommends that one endpoint takes the
role of ‘‘client’’ and other endpoint takes role of ‘‘server’’. Therefore, the
following scenarios are possible:
Note: The used scenario depends on the mutual agreement between

operator or vendor of peer node.
IP-STP Peer Node

‘‘client’’ ‘‘server’’
(1)
‘‘client’’ ‘‘peer’’
‘‘server’’ ‘‘client’’
(1) This scenario is recommended towards other Ericsson nodes. This scenario is not
possible in case of M2PA.
Recommendation:
Recommended as ‘‘server’’ towards IP-SEP.
— SCTP association definition from the Multi-Homed SCTP Endpoints of the

IP-STP to each peer SCTP EPs in STP/SGW C and STP/SGW D
• IP address(es) and port number of the peer SCTP EPs
The M2PA configuration requires the following steps:
— Definition of the M2PA links. Up to 16 signaling links can be defined in one

link set. User Guide Managing and Optimizing SS7 Congestion Control and
SIGTRAN Performance provides dimensioning guidelines.
80 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

How to Use
The prerequisite for initialization of M2PA links is to configure the following parts
at MTP3 level:
— Own SPC definition
— Destination SPC definition
— Link Set Definition
For a detailed description of SCTP and M2PA configuration in IP-STP, see User
Guide Message Transfer Part 2 User Peer-to-Peer Adaptation Layer.
— Own SPC definition.
— Definition of SPC in peer nodes.
Note: If the redundant M2PA links between IP-STP A and IP-STP B are
used, then the definition of SPC in IP-SEP requires additionally the
definition of IP-SEP as reachable through both M3UA and MTP3
networks with preference for the M3UA network.
— M3UA behavior over the SCTP association. IP-STP must be configured to

behave as SGP.
— AS definition at the IP-SEP.
This requires setting the following parameters:
• Routing Key. In this case the Routing Key consists of the IP-SEP DPC the
AS is associated to.
• Priority of the implicitly defined route to the IP-SEP DPC.
• Additionally the following parameters can be set:
Routing Context. This parameter is needed if multiple ASs are connected

over the same SCTP association.
The definition of the AS at the IP-SEP automatically defines a route to the IP-SEP
DPC. If this is the first route towards the IP-SEP DPC, the following data is defined:
— Load Sharing Method for destination declared by DPC parameter.
If this is the first AS created in the node, the following data is defined:
— Traffic Mode Type (TMT) for the AS
For a detailed description of SCTP and M3UA configuration in IP-STP, see User
Guide Message Transfer Part 3 User Adaptation Layer.
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 81

82 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Glossary
Glossary
3GPP CAP
3rd Generation Partnership Project CAMEL Application Part
AH CCN
Authentication Header Cost Control Node
AMR CCSA
Association Maximum Retransmissions China Communications Standards Association
ANSI CL
American National Standards Institute Connectionless
AoIP CN
A-Interface over IP Core Network
AS CP
Application Server Central Processor
ASP CS
Application Server Process Circuit Switched
ATM CNCS
Asynchronous Transfer Mode Circuit Switched Core Network
AuC DES
Authentication Center Data Encryption Standard
AXE DNS
Public Telephone Exchange System Domain Name System
BGP DPC
Border Gateway Protocol Destination Point Code
BICC DSCP
Bearer Independent Call Control Differentiated Services Code Point
BSC DTA
Base Station Controller Destination Transport Address
BSP DTP
Blade Server Platform Data Transfer Path
BSSAP EGEM
Base Station System Application Part Enhanced Generic Ericsson Magazine
BSSAP+ EP
Base Station System Application Part + End Point
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 83

E-SIGTRAN GTT
Ericsson SIGTRAN Global Title Translation
ESP HLR
E-SIGTRAN Signaling Process Home Location Register
ET-IP HLR-FE
Exchange Terminal - IP Home Location Register Front End
ET-IPG IETF
Exchange Terminal - Internet Protocol Internet Engineering Task Force
Gateway
INAP
FE Intelligent Network Application Protocol
Fast Ethernet
IP
FNR Internet Protocol
Flexible Numbering Register
IP-FE
FQDN IP Front End
Fully Qualified Domain Name
IPLB
GCP IP Load Balancer
Gateway Control Protocol
IPsec
GE Internet Protocol Security
Gigabit Ethernet
IP-SEP
GEM Signaling End Point
Generic Ericsson Magazine
IPSP
GESB IP Server Process
Gigabit Ethernet Switching Board
IPv4
GMSC-S Internet Protocol version 4
Gateway MSC Server
IPU
GPB Instruction Processor Unit
General Purpose Processor Board
ISDN
GPRS Integrated Services Digital Network
General Packet Radio Service
ISUP
gsmSCF ISDN User Part
GSM Service Control Function
ITU
GTRC International Telecommunication Union
Global Title Routing Case
ITU-T
GTRE International Telecommunication Union
Global Title Routing Extension Telecommunication Standardization Sector
84 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Glossary
IUA MPT
ISDN Q.921 User Adaptation Layer Ministry of Posts and Telecommunications of
the People's Republic of China
KPI
Key Performance Indicator MSC
Mobile Switching Center
L2
Layer 2 MSC-S
MSC Server
LL
Link Layer MSC-S BC
MSC Server Blade Cluster
LAN
Local Area Network MSU
Message Signal Unit
LAPD
Link Access Procedures - channel D MTP
Message Transfer Part
LBT
Local Bundling Timer MTP2
Message Transfer Part Level 2
LCS
Location Services MTP3
Message Transfer Part Level 3
LSP
Label-Switched Path MTP3b
Message Transfer Part Level 3 with Broadband
LTE Enhancements
Long Term Evolution
MTU
M2PA Maximum Transmission Unit
MTP2 User Peer-to-Peer Adaptation Layer
NI
M3UA Network Indicator
MTP3 User Adaptation Layer
NIF
MAP Nodal Interworking Function
Mobile Application Part
O&M
MH Operation and Maintenance
Multi-Homed
PBX
MME Private Branch Exchange
Mobility Management Entity
PDU
M-MGw Protocol Data Unit
Ericsson Media Gateway for Mobile Networks
PFMR
MPLS Potentially Failed Maximum Retransmissions
Multiprotocol Label Switching
PLMN
Public Land Mobile Network
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 85

PMR SGW
Path Maximum Retransmissions Signaling Gateway
POI SH
Point of Interconnect Single-Homed
PRA SIGTRAN
Primary Rate Access Signaling Transport over IP
PSP SLS
Primary Signaling Point Signaling Link Selection
PSS SMS
Path Selection Scheme Short Message Service
QoS SMS-SC
Quality of Service Short Message Service Center
RANAP
SP
Radio Access Network Application Part
Signaling Point
RNC
Radio Network Controller SPC
Signaling Point Code
RTO
Retransmission time-out SPX
Signaling Proxy
RTT
Round-Trip Time SPU
Signal Processor Unit
SCCP
Signaling Connection Control Part SRP
Signaling Relay Point
SCF
Service Control Function SR
Site Router
SCP
Service Control Point SS7
Signaling System No. 7
SCTP
Stream Control Transmission Protocol SS7oIP
Signaling System No. 7 over IP
SEP
Signaling End Point SSP
Secondary Signaling Point
SGP
Signaling Gateway Process STC
Signaling Transport Converter
SGsAP
SGs Application Part STP
Signaling Transfer Point
SGSN
Serving GPRS Support Node
86 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Glossary
SUA
Signaling Connection Control Part User
Adaptation Layer
TCAP
Transaction Capabilities Application Part
TCP
Transmission Control Protocol
TDM
Time Division Multiplexing
TMT
Traffic Mode Type
TSC
Transit Switching Center
TSC-S
TSC Server
TTC
Telecommunication Technology Committee
(Japan)
TUP
Telephony User Part
ULP
Upper Layer Protocol
VIP
Virtual IP
VLR
Visitor Location Register
VM
Voicemail
VPN
Virtual Private Network
VR
Virtual Router
WCDMA
Wideband Code Division Multiple Access
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 87

88 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Reference List
Reference List
CPI Library Internal References
[1] CCITT7 Signalling System No. 7, Message Transfer Part

FUNCTION SPECIFICATION
[2] Cluster Overview

[3] Concepts and Terminology on Circuit Switched Core Network Level

DESCRIPTION
[4] Core Network Overview

DESCRIPTION
[5] Counters in the Measurement Data Base for IUA

FUNCTION SPECIFICATION, SPX specific document
[6] Counters in the Measurement Database for M2PA

[7] Counters in the Measurement Database for M3UA

[8] Event Reporting and Disturbance Supervision in IUA

[9] Gateway Control Protocol over SCTP

USER GUIDE
[10] IP Based Functions on CP, Protocol Stack

[11] IP Based Functions on CP, SCTP Details

[12] ISDN Q.921-User Adaptation Layer (IUA)

[13] ISDN Q.921 - User Adaptation Layer (IUA) Protocol

INTERWORK DESCRIPTION, SPX specific document
[14] List of IP Backbone Recommendations

APPLICATION INFORMATION
[15] M3UA Relay

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 89

[16] M3UA Relay

USER GUIDE, SPX specific document
[17] M3UA, Event Reporting and Disturbance Supervision

[18] Managing and Optimizing SS7 Congestion Control and SIGTRAN

Performance
USER GUIDE
[19] Managing IP Integration

USER GUIDE
[20] Managing IP Transport in the Core Network

USER GUIDE
[21] Managing Local Switching for Sites Connected over Satellite

USER GUIDE
[22] Managing Primary Rate Access on Core Network Level

USER GUIDE
[23] Managing Security on Core Network Level

USER GUIDE
[24] Managing the Stream Control Transmission Protocol

USER GUIDE
[25] Message Transfer Part 2 (MTP2) - User Peer-to-Peer Adaptation Layer

(M2PA)
[26] Message Transfer Part 2 User Peer-to-Peer Adaptation Layer

USER GUIDE, SPX specific document
[27] Message Transfer Part 3 User Adaptation Layer

USER GUIDE
[28] MSC-S Configuration Management

USER GUIDE
[29] MTP3 User Adaptation Layer

[30] MTP3 User Adaptation Layer, Signalling Gateway

[31] MTP3 User Adaptation Layer Protocol

[32] Primary Rate Access in MSC Server

USER GUIDE
90 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Reference List
[33] Product Overview

DESCRIPTION
[34] SCCP Global Title Routing Extension (ITU-T, MPT, TTC)

[35] SGs-Interface Configuration and Enabling of SMS over SGs-Interface and

LTE to CS Fallback
USER GUIDE
[36] Signalling System 7 (SS7) Message Transfer Part 2 (MTP2) - User

Peer-to-Peer Adaptation Layer (M2PA) Protocol
INTERWORK DESCRIPTION, SPX specific document
[37] Signalling Transport Converter over SCTP

[38] SS7 Message Transfer Part, MTP

[39] Traffic Data: Handling of Global Title Routing Cases

ADAPTATION DIRECTION
M-MGw CPI References
[40] User Guide for Physical Interfaces

USER GUIDE
[41] User Guide for Primary Rate Access

USER GUIDE
[42] User Guide for Signalling

USER GUIDE
[43] User Guide for Virtual Media Gateway Handling

USER GUIDE
Standard References
[44] 3GPP, 29.202, Signalling System No. 7 (SS7) signalling transport in core
network; Stage 3
[45] IETF, RFC 2719, Framework Architecture for Signaling Transport
[46] IETF, RFC 4960, Stream Control Transmission Protocol
[47] IETF, RFC 4666, Signaling System 7 (SS7) Message Transfer Part 3 (MTP3)
- User Adaptation Layer (M3UA)
[48] IETF, RFC 4165, Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
- User Peer-to-Peer Adaptation Layer (M2PA)
3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 91

[49] IETF, RFC 4233, Integrated Services Digital Network (ISDN) Q.921-User
Adaptation Layer
[50] IETF, RFC 4594, Configuration Guidelines for DiffServ Service Classes
[51] IETF Draft, Quick Failover Algorithm in SCTP (draft-ietf-tsvwg-sctp-fail

over-13.txt)
[52] ITU-T, Q.2150.3, Signalling transport converter on SCTP
92 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Signaling

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Signaling

Uploaded by

Copyright:

Available Formats

Managing Signaling over SCTP/IP on Network

3/1553-HSC 113 01/15-V4 Uen B

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

4 Signaling over SCTP/IP Overview 9

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

4.7.4 Signaling over M2PA 37

5 Network Solution Implementation 43

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

Changes in MSC-S 18.1

This document has been revised as follows:

Changes in MSC-S 18A

This document has been revised as follows:

Changes in MSC-S 17A

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 1

Changes in MSC-S 15A

This document has been revised as follows:

2 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

The following aspects are out of the scope of this document:

— IP transport design (see User Guide Managing IP Transport in the Core

— Node dimensioning (see Description Core Network Design Guideline

— Configuration of IuCS-Interface and A-Interface over IP (AoIP) (see

Section 5 on page 43 is dedicated to the connectivity aspects down to IP and

Section 6 on page 53 describes SCTP parameter setting for fine-tuning to the IP

2.2.1 Documentation Structure

Table 1 Documentation Overview

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 3

4 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

— Associated Signaling Mode

— Quasi-Associated Signaling Mode

— Signaling End Point

3.1.1 Application Server

3.1.1.1 M3UA Application Server

An IP-SEP can contain several ASs.

Figure 1 shows an IP-SEP with one AS.

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 5

Figure 1 IP-SEP with One AS

Figure 2 shows a node with multiple ASs.

Figure 2 IP-SEP with Many ASs

By an IP-SEP⇔IP-SEP communication scenario, where each IP-SEP behaves

6 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

In a distributed node architecture, an AS can be distributed over some IP-SEPs,

An AS in an IP-SEP has similar functionality to an SS7-SEP in the SS7 terminology.

By an IP-SEP⇔SGW communication scenario the AS data must be statically

IUA AS is a logical entity serving a specific application. An example is an AS in a

3.1.2 Application Server Process

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 7

3.1.4 IP Load Balancing

By M3UA, a given IP-SEP can simultaneously behave as different signaling

3.1.7 Remote Host

3.1.8 Routing Context

3.1.9 Routing Key

8 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26

4 Signaling over SCTP/IP Overview

Signaling over SCTP/IP as described in this document is based on the framework

Signaling over SCTP/IP is implemented in several CN nodes in the CNCS. Figure

RNC GCP ISUP

Figure 4 Signaling over SCTP/IP in CNCS

Signaling over SCTP/IP as described in this document covers what is commonly

3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26 9

The MME as such can only be connected by IP.

The IP signaling terminals, in contrast to TDM or ATM signaling terminals,

Applications that use Signaling Protocols with high-bandwidth demands, such

Figure 5 Fully Meshed M3UA Network Topology

10 3/1553-HSC 113 01/15-V4 Uen B | 2019-09-26