Beruflich Dokumente
Kultur Dokumente
TECHNICAL NOTE
DISCLAIMER
Information in this document is subject to change without notice and should not be construed as a
commitment on the part of Hughes Software Systems. Hughes Software Systems does not assume
any responsibility or make any warranty against errors that may appear in this document and disclaims
any implied warranty of merchantability or fitness for a particular purpose.
Contact HSS
Technical Note 3
Chapter 1
The combination of various technologies that enable SS7 to operate over IP requires the
division of various protocols over the SS7 and IP signaling planes.
In a signaling network, point-to-point circuit connections (using SS7 links) between SS7
nodes, form the "SS7 plane" of the converged network. The network nodes that reside on
the SS7 plane include:
•= local/tandem/trunking exchanges having SS7 connectivity which act as SSPs or
STPs
•= Mobile Switching Centers (MSCs)
•= Database query nodes, which act as SCPs etc.
Any node that connects over SS7 links or circuits, resides on the SS7 plane.
The IP plane includes all signaling devices with native IP interfaces. Each layer of SS7
can be divided into two parts:
•= Signaling part
•= Transport of user data.
User data is transported by the SIGTRAN layer counterparts, and have their own
procedures for signaling messages to peers. The user data remains unchanged. IP nodes
include, among others:
•= Softswitches
•= IP-based SCP,
•= IP-based MSC
•= IP-based HLR/VLR/RNC
•= IP-based SCCP relay nodes
Technical Note 5
Chapter 1: Architecture of a Converged Network
In converged networks, devices on the SS7 Plane connect to the signaling gateway
located at the logical boundary between the SS7 and IP planes. From the SS7 plane, the
signaling gateway can be seen as one of the following two broad categories:
1. Signaling Gateway sharing point code with ASP: The signaling gateway presents
itself as an SS7 signaling point to the SS7 plane and also “collapses” multiple IP
signaling applications on the IP Plane within that signaling point. In other words,
the signaling gateway presents a single point code to the SS7 Plane on behalf of
several back-end applications running in the IP Plane.
2. Signaling Gateway acting as an IP-STP: The signaling gateway has a different
point code from that of the AS. The signaling gateway, thus, acts as an STP where
the SS7 signaling messages are routed to IP nodes that cater to that particular point
code.
Note: Here, the MTP3 (and SCCP) functionality as defined by SS7 protocol would
have to be modified such that they can handle multiple self point codes.
SUA Overview
The SCCP User Adaptation (SUA) layer transport protocol is one of the layers within the
SIGTRAN protocol suite. All SIGTRAN protocols are standardized by the SIGTRAN
working group in IETF. SCCP user messages are transported using SUA between peer IP
nodes. The peer IP nodes in an SUA environment could be an SGP-ASP or IPSP-IPSP
combination.
In an SGP-ASP scenario, the SS7 links terminate on an SGP and the SCCP user messages
are transported to the IP network using SUA over SCTP. An IPSP-IPSP scenario is used
when two IP network nodes want to communicate SCCP user messages over IP. Here too
SUA over SCTP is used as the transport.
The advantage of using SUA over other competing UAs such as M2UA, M2PA and
M3UA are as follows:
1. A minimum number of SS7 layers (only SCCP user layers and above) are present on
ASP/IPSP. Fewer SS7 layers on the ASP/IPSP means more processing power is
available for other layers and applications on ASP/IPSP.
2. The SUA layer understands IP as well as SS7 nodes, thus GT translation done on
SUA would have resultant route to the SS7 or IP network, implying that it could
also have IP addresses in the routing table.
3. SUA understands SCCP routing parameters such as SSN, transaction Ids, etc. The
SUA can thus route user messages to different nodes based on these routing
parameters, in addition to OPC/DPC etc.
6 Technical Note
Chapter 2
Network Placement
This section discusses the various network locations at which SUA can be deployed in
VoIP, 3G and converged networks. All different node placements (SGP, ASP and IPSP)
are considered in the following network scenarios. There could be many more scenarios
for SUA placement. These examples are just to help explore other related areas where
customers could fit their products using SUA as the transport layer protocol. The two
scenarios considered in this note for SUA usage are:
•= SCP-SSP
•= 3G
There are many such nodes where SCCP user messages could be used. HSS would be
glad to help the customer visualize other network scenarios as well.
SSP-SCP scenarios
The different scenarios for SSP-SCP network placements are shown below, where SUA
over SCTP can be used. The advantages and network placements are described in detail.
Technical Note 7
Chapter 2: Network Placement
Network Scenario
The network scenario in Figure 1 shows a softswitch connected to an SS7 network for
call control. The softswitch communicates with the IP-SCP over SUA for SCP triggers.
With no SS7 links in the path, IP-SCP could be placed geographically far from the
softswitch.
SUA/SCTP
IP-SCP IP Network
Softswitch
Legend:
Data Flow
MG MGC
Ethernet
Advantages
The advantage this presents, is that the SS7 layers below TCAP would not figure in this
flow, thus increasing processing speed. The SUA layer could perform GT translation to
give the IP address that would be used to route the SCCP user message from Softswitch
to the IP-based SCP. It could use the Transaction ID to route the messages to different IP-
SCP. It could also use the SSN value to route to different IP-SCP, which could host
different services. For example, there could be one IP-SCP that handles address
translation services such as Local Number Portability (LNP), and another IP-SCP that
could host query-based services like 8yy calls. The SUA on softswitch could have
connections to both these IP-SCPs, with routing keys configured to initiate a dialogue
with the first IP-SCP for LNP triggers, and initiate a dialogue with the second IP-SCP for
8yy triggers, without any change to the TCAP layers.
8 Technical Note
Chapter 2: Network Placement
SCP
SS7 Network
STP STP
SS7 SG Node
SUA/SCTP
IP Network
SUA/SCTP
Softswitch
Legend:
Data Flow
SS7 Links
MG MG
Ethernet
Network Scenario
The scenario in Figure 2 shows how the IP-based softswitch can communicate with an
SCP which has SS7 links. In this case, there would be a signaling gateway that terminates
SS7 links and the lower layers of SS7 to transport the SCCP user messages over IP, using
SUA over SCTP to the softswitch. The softswitch and the signaling gateway should have
support for SUA over SCTP.
Technical Note 9
Chapter 2: Network Placement
Advantages
The advantage this presents, is that the SS7 links would terminate at the Signaling
Gateway. There could be multiple softwitches in the IP network. They would interface
with a common set of SCPs. The signaling gateways could be placed near the SCP, and
hence the IP connectivity would extend over a wider geographic area as compared to the
SS7 links. Since the bandwidth over IP can be greater than over SS7 links, there is greater
erlang capacity handling in the system.
Network Scenario
The scenario depicted in Figure 3 shows how the IP-based SCP can communicate with an
IP-based softswitch, and communicate with multiple SS7 link-based SSPs. In such a case,
the SS7 links and lower layers of SS7 would terminate at signaling gateways to transport
the SCCP user messages over IP, using SUA over SCTP to IP-based SCP.
The IP-based SCP, softswitches, and the signaling gateway should have support for SUA
over SCTP. There could be multiple signaling gateways through which the SCP is
interfacing. The signaling gateways could be placed near the SSPs.
The IP-based SCP must support the IPSP-IPSP configuration of SUA when interfacing
with softswitch, and should support ASP-SGP configuration when interfacing with SSP
via a signaling gateway.
Advantages
The advantage this presents, is that an IP-based SCP would be able to interface with an
IP-based softswitch while also interfacing over SS7 links with legacy SSPs. Thus the
same node could interface for existing and future switches. When interfacing with
softswitches, the advantages mentioned in the first scenario would hold true here too.
When interfacing with SS7 link-based SSPs, the IP-SCP would interface with a signaling
gateway over SUA. The SS7 links from SSPs would terminate at a Signaling Gateway.
There could be multiple SSPs in the SS7 network. They would be interfacing with a
common set of IP-based SCPs. There could be multiple signaling gateways through
10 Technical Note
Chapter 2: Network Placement
which the SCP interfaces. The signaling gateways could be placed near the SSPs, hence
the IP connectivity would extend over a wider geographical area as compared to the SS7
links. Since the bandwidth over IP layer can be greater than that of SS7 links, the system
will have better erlang capacity handling.
Legend:
Data Flow
SS7 Links SSP
Ethernet
SS7 Network
STP STP
SS7 SG Node
SUA/SCTP
IP Network
SUA/SCTP
Softswitch
IP-based SCP
MG MG
Figure 3: Network Scenario for Softswitch interface to an IP node and legacy SS7 node
Also, since the IP-based SCP is over SUA, it can be easily scaled by adding more of such
systems, with each supporting a different SSN. This way, each IP-SCP could eventually
execute a different service (such as 8yy, LNP, etc.).
Technical Note 11
Chapter 2: Network Placement
3G scenarios
The following section describes various network scenarios in which SUA over SCTP
replaces SCCP and lower layers between various 3G nodes. The network placement and
advantages are described in detail.
The 3GPP specifications suggest the use of M3UA in a converged network, though
discussions are still ongoing and SUA is being considered for the transport of SCCP user
data. This information assumes that SUA is used, instead of SCCP/M3UA, to transport
SCCP user (RANAP/MAP) data.
Network Scenario
The scenario in Figure 4 depicts an RNC and MSC in a 3G network residing in a packet
network and placed far apart. The IP layer replaces the SS7 links between them, using
SIGTRAN for the transport of SCCP user messages. Since multiple RNCs would be
talking to a single MSC, the IP-based MSC would have multiple IPSP-IPSP connections
with the IP-based RNCs.
The SS7 layer above SCCP would be used for communication. The GT translation (if
required) would be done by SUA. In a normal placement, an RNC would know the point
code of an MSC and would therefore use direct destination point code addressing. The
IP-based RNC and IP-based MSC should both be able to support IPSP-IPSP
configuration with SUA as the transport for SCCP user messages. In the following
network scenario, the IP-based MSC still communicates with other 3G nodes (such as
HLR and SCP) over SS7 links via the signaling gateway. The IP-based MSC, therefore,
needs to support an ASP-SGP setup to communicate with the signaling gateway.
Advantages
The advantage this presents is that the SS7 layers below, including SCCP, would not
figure in message flow between the IP-based RNC and MSC, thus increasing the
processing speed. If RNC and MSC are connected over SS7 links, then MSC would have
as many SS7 links to reach many RNCs, which cover different areas. If the connection
between them is IP-based, then the MSC would have IP connectivity, possibly to multiple
RNCs, thus making it less bulky and offering more erlang traffic handling capacity.
12 Technical Note
Chapter 2: Network Placement
Legend:
Data Flow
SS7 Links
Ethernet HLR HLR
SS7 Network
STP STP
SS7 SG Node
SUA/SCTP
IP-based MSC -1
MG MG
Technical Note 13
Chapter 2: Network Placement
Legend:
Data Flow
SS7 Links RNC
Ethernet
SS7 Network
SS7 SG Node
SUA/SCTP
IP Network
IP-based MSC - 1
MG MG
Network Scenario
The scenario in Figure 5 depicts an SS7 network depicts an MSC with SS7 connectivity
to multiple 3G nodes like RNC, HLR, SCPs, other MSCs, etc. This would have multiple
SS7 links and terminating all these SS7 links would make the system very bulky and
difficult to maintain. If the MSC is IP-based, the SS7 links from other nodes could be
terminated on signaling gateways.
14 Technical Note
Chapter 2: Network Placement
Advantages
IP-based MSC as per this network configuration would have IP connectivity to multiple
signaling gateways. The SS7 links are terminated on signaling gateways. Only SCCP user
messages are transported to MSC. This way, the MSC could have only IP connectivity
and thus have processing of larger message capacity over the IP connection for SCCP
user messages onwards.
Network Scenario
The scenario in Figure 6 depicts an HLR and MSC placed far apart in a 3G network that
resides in a packet network. The IP layer replaces the SS7 links between them, with
SIGRAN as the transport for SCCP user messages. The SS7 layer above SCCP would be
used for communication. The GT translation (if required) would be done by SUA.
Though in a normal placement, an HLR would know the point code of an MSC and hence
would use direct destination point code addressing. The IP-based HLR and IP based MSC
should both be able to support IPSP-IPSP configuration with SUA as the transport for
SCCP user messages. In following network scenario, the IP-based MSC still
communicates with other 3G nodes ( HLR and SCP) over SS7 links via the signaling
gateway. The IP-based MSC must therefore support ASP-SGP setup for communication
with the signaling gateway.
Technical Note 15
Chapter 2: Network Placement
Legend:
Data Flow
SS7 Links
RNC
Ethernet SCP
SS7 Network
STP STP
SS7 SG Node
SUA/SCTP
IP-based MSC -1
MG MG
Figure 6: Network scenario for HLR and MSC placed far apart in
a 3G network that resides in a packet network
Advantages
The advantage this presents, is that the SS7 layers below, including SCCP, would not
figure in message flow between the IP-based HLR and MSC, thus increasing the
processing speed. A single physical IP-based HLR could serve many MSCs by having a
logical partition.
16 Technical Note
Chapter 3
Each telecom node that is to be placed in a telecom network is expected to support the
following generic features:
•= Scalability
•= High Availability
Scalability: Nodes should be able to support more traffic by increasing resources. Since
any single system has limited resource, in order to support scalability, it must support a
distributed architecture where the single system should be able to support multiple sub-
nodes and have load-sharing between these nodes.
High Availability: In any telecom system, it is highly desirable that the system should
support 99.999% availability. To do this, the system should have a standby copy that
takes over when the active system fails. The switchover should be fast and have minimal
impact on on-going calls.
Support for these features is built into the SIGTRAN protocol. In order to achieve these,
multiple traffic modes are defined and there are well-built procedures for switchover,
distribution, etc. These are briefly discussed with reference to SUA, in the following
sections.
Technical Note 17
Chapter 3: Carrier Grade Solutions
SG level redundancy
There could be more than one SG, each with a different point code.
The ASP could have a different point code. The ASP would route the message via one
SG. If that SG is down, it could route the messages via another SG, which acts as another
STP node. If there is more than one SG through which the ASP could route messages to
the SS7 node, it could be configured with the priority of choosing the SG through which
it could route the messages to the SS7 node.
All SGPs must share the same network appearance. These SGPs share redundancy data
via internal SGP communication. ASP is aware of the multiple SGP configurations.
Based on which SGP is active, messages are routed via that SGP. In this case, the links
could be shared between both SGP nodes, and the common network appearance is
maintained using the distributed MTP-3 feature.
18 Technical Note
Chapter 3: Carrier Grade Solutions
References
1.) J. Loughney, G. Sidebottom, L. Coene, G. Verwimp, J. Keller,
B. Bidulock, "Signaling Connection Control Part User Adaptation Layer (SUA)",
Internet Draft, Internet Engineering Task Force, <draft-ietf-sigtran-sua-014.txt>.
2.) RFC 2960, "Stream Control Transport Protocol", R. Stewart et al , October 2000.
Acronyms
Acronym Expansion
ASP Application Server Process
DPC Destination Point Code
GT Global Title
HLR Home Location Register
IETF Internet Engineering Task Force
IP Internet Protocol
IPSP IP Server Process
LNP Local Number Portability
M2PA MTP-2 Peer to Peer Adaptation Layer
M2UA MTP-2 User Adaptation Layer
M3UA MTP-3 User Adaptation Layer
MAP Mobile Application Part
MSC Mobile Switching Centers
MTP-2 Message Transfer Part Layer 2
MTP3 Message Transfer Part Layer 3
OPC Originating Point Code
RANAP Radio Access Network Application Part
RFC Request for Comments
RNC Radio Network Controller
SCCP Signaling Connection Control Part
SCP Service Control Point
SCTP Stream Control Transport Protocol
SG Signaling Gateway
SGP Signaling Gateway Process
SIGTRAN Signaling transport
SS7 Signaling System 7
SSN Sub-System Number
SSP Service Switching Point
STP Signal Transfer Point
SUA SCCP User Adaptation
Technical Note 19
Chapter 3: Carrier Grade Solutions
20 Technical Note
Chapter 3: Hughes Software Systems: A global leader
Hughes Software Systems (HSS) is the global leader in the convergence marketplace, providing
solutions for Voice over Packet, SS7, Broadband and Wireless. More than 200 customers worldwide
are using technology solutions from HSS. HSS offers both licensable technologies and outsourcing
services to meet its customers’ needs.
HSS constantly invests in building new technology and expertise, with a cherished customer base
consisting of global leaders such as Avaya, ADC Telecommunications, Alcatel, Coppercom,
Convergys, ip.access, Cisco, Ericsson, Veraz Networks, Italtel, Lucent Technologies, Marconi
Corporation, Motorola, NEC Corporation, NTT Commware, Nokia Networks, OKI, Santera Systems,
Sylantro Systems and more.
With a constant emphasis on evolution, HSS is a member of and an active participant in industry
forums such as IETF, 3GPP, International Softswitch Consortium, National Convergence Alliance,
SIP Forum, and ITU-T.
HSS has global operations as part of the Hughes group, and has more than 2100 employees
worldwide. HSS has offices in the US, the UK, Germany, Japan and India. HSS is represented through
its distribution channels in China, Taiwan, Korea, Japan, Australia, New Zealand and Brazil, with
development centers in New Delhi and Bangalore in India, and Nuremberg in Germany.
Recognized globally as the leader in communications software, HSS offers the most comprehensive
range of full-spectrum software development services and enabling technologies.
NEPs across the world are facing the challenge of reducing costs and increasing profitability even as
the competitive landscape throws up more competition. They are addressing these challenges by:
HSS offers comprehensive software for building any of the following solutions:
•= Application Servers
•= Base Station Controllers
•= Call State Control Function (CSCF)
•= Charging Gateway Function (CGF)
•= Class 4 switches
•= Class 5 switches
Technical Note 21
Chapter 3: Hughes Software Systems: A global leader
HSS offers you the unique benefit of licensing software products and carrying out customized
development. Alternatively, the products supplied by HSS can be enhanced and integrated by
customers’ teams as per their requirements.
22 Technical Note
Chapter 3: Contact HSS
Contact HSS
For more information, please contact HSS at:
Europe
United Kingdom +44-208-6223859
Germany +49-89-83999-751
+49-172-410-9349
Japan +81-90-9370-9579
+81-90-3233-8891
India +91-124-2455151
Email : Info@hssworld.com
Technical Note 23