Network Scenarios and Carrier Grade

Solutions with SUA

This note provides an overview of different

architectures for the use of SUA protocol
in VoIP, 3G and converged networks. It also
describes how to use SUA to achieve carrier
grade solutions for high availability and message
distribution. This information is intended to help
network designers and customers to build
products for 3G/VoIP networks. It would also
give an idea of what to do to have more visibility
in a converged network. The broad scenarios
covered are:
■ Only IP network
■ Interface between IP nodes and SS7 network.
■ Simultaneously interfacing with SS7 network
and other IP nodes

TECHNICAL NOTE

©2003 Hughes Software Systems Ltd.

 2003 Hughes Software Systems Ltd. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means, electronic or
otherwise, including photocopying, reprinting, or recording, for any purpose, without the express written
permission of Hughes Software Systems Ltd.

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.

Hughes Software Systems Ltd.

Plot 31, Electronic City
Sector 18, Gurgaon – 122015
Haryana (INDIA)
Tel: +91-124-2346666/2455555
Fax: +91-124-2342415/2342810
E-mail: info@hssworld.com
Visit us at: http://www.hssworld.com
 Contents

Chapter 1. Architecture of a Converged Network ............................................................................ 5

SUA Overview ..................................................................................................................... 6
Chapter 2. Network Placement ........................................................................................................... 7
SSP-SCP scenarios ............................................................................................................ 7
Routing SS7 traffic to/from IP-based SCP to Softswitch............................................................7
Routing SS7 traffic to/from Legacy SCP....................................................................................9
Routing from/to IP-based SCP to both, Softswitch and legacy SS7 network ..........................10
3G scenarios ..................................................................................................................... 12
Routing SS7 traffic to/from IP based RNC in a converged network to IP based MSC ............12
Routing SS7 traffic to/from RNC in a 3G network to IP based MSC........................................14
Routing SS7 traffic to/from IP based HLR/VLR in a converged network to IP based MSC .....15
Chapter 3. Carrier Grade Solutions.................................................................................................. 17
Redundancy Architectures presented by SUA protocol.................................................... 17
ASP level redundancy..............................................................................................................18
SG level redundancy................................................................................................................18
SGP level redundancy .............................................................................................................18
Load balancing architecture.....................................................................................................18
Load balancing of multiple SGP...............................................................................................18
Load Balancing to multiple ASP...............................................................................................18
References...............................................................................................................................19
Acronyms .................................................................................................................................19
Chapter 4. About HSS........................................................................................................................ 21

Contact HSS

PRIVATE & CONFIDENTIAL

Technical Note 3
 Chapter 1

Architecture of a Converged Network

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

PRIVATE & CONFIDENTIAL

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.

PRIVATE & CONFIDENTIAL

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.

Routing SS7 traffic to/from IP-based SCP to Softswitch

A legacy SCP would talk over SS7 to an SSP. In a converged network, the Softswitch can
talk over SUA to an IP-based SCP. In order to have an SCP that can directly talk to a
softswitch over IP, the IP-based SCP and softswitch should be able to support SUA over
SCTP communication in an IPSP-IPSP configuration.

PRIVATE & CONFIDENTIAL

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

Figure 1: Network Scenario for IP-SCP to Softswitch communication

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.

PRIVATE & CONFIDENTIAL

8 Technical Note
 Chapter 2: Network Placement

Routing SS7 traffic to/from Legacy SCP

If a softswitch is attached to a legacy SCP that has only SS7 links, then the softswitch can
talk to a Signaling gateway over SUA and to the legacy SCP over SS7.

SCP

SS7 Network

STP STP

SS7 SG Node

SUA/SCTP

IP Network

SUA/SCTP

Softswitch
Legend:
Data Flow
SS7 Links
MG MG
Ethernet

Figure 2: Network Scenario for Softswitch to Legacy SCP

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.

PRIVATE & CONFIDENTIAL

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.

Routing from/to IP-based SCP to both, Softswitch and legacy SS7

network
A legacy SCP may serve many SS7 SSPs. If the SCP is changed with an IP-based SCP to
serve a softswitch, it must be upgraded to serve the existing SS7 nodes as well. In this
case, the IP SCP interfaces with an IP-based softswitch as well as to a signaling gateway
for interfacing with an SSP. Thus, the IP SCP needs to support both, IPSP-IPSP and
ASP-SGP configurations.

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

PRIVATE & CONFIDENTIAL

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.).

PRIVATE & CONFIDENTIAL

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.

Routing SS7 traffic to/from IP based RNC in a converged network to

IP based MSC
In a converged network, the link from, say an RNC to an MSC, is over IP. RANAP
messages over SCCP can be transported on SUA using SIGTRAN between RNC and
MSC. Here the RNC and MSC communicate with each other over SUA in an IPSP-IPSP
configuration.

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.

PRIVATE & CONFIDENTIAL

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 RNC IP Network

IP-based MSC -1

MG MG

Figure 4: Network Scenario for IP-based MSC in converged network interfacing

with IP-based RNC, legacy HLR and legacy SCP

PRIVATE & CONFIDENTIAL

Technical Note 13
Chapter 2: Network Placement

Routing SS7 traffic to/from RNC in a 3G network to IP based MSC

The link from an RNC to an MSC in a 3G network is over SS7 link. If an MSC is over IP,
then the RANAP over SCCP can be transported on SUA using SIGTRAN. The SS7 links
are terminated on a signaling gateway. From signaling gateway the RANAP messages
over SCCP are transported over SUA to an IP based MSC.

Legend:
Data Flow
SS7 Links RNC
Ethernet

SS7 Network

HLR STP STP SCP

SS7 SG Node

SUA/SCTP

IP Network

IP-based MSC - 1

MG MG

Figure 5: Network Scenario for IP-based MSC in converged network interfacing

with IP-based HLR, legacy RNC and legacy SCP

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.

PRIVATE & CONFIDENTIAL

14 Technical Note
 Chapter 2: Network Placement

There could be multiple signaling gateways connected to IP-based MSCs. These

signaling gateways could be placed geographically closer to the other 3G nodes and thus
reducing the physical SS7 connectivity. MSC to SG would be ASP-SGP scenario with
support of SUA.

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.

Routing SS7 traffic to/from IP based HLR/VLR in a converged

network to IP based MSC
In a converged network, the link from an HLR to an MSC is over IP. MAP messages over
SCCP can be transported on SUA using SIGTRAN between HLR/VLR and MSC. This is
similar to the configuration of IP-based RNC communicating with IP-based MSC. Here,
the IP-based HLR would have IPSP-IPSP support. The MSC would have support for both
IPSP-IPSP as well as ASP-SGP scenario.

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.

PRIVATE & CONFIDENTIAL

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 HLR IP Network

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.

PRIVATE & CONFIDENTIAL

16 Technical Note
 Chapter 3

Carrier Grade Solutions

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.

Redundancy Architectures presented by SUA protocol

The following section presents the different network node redundancy procedures as
supported by SUA protocol level features.

PRIVATE & CONFIDENTIAL

Technical Note 17
Chapter 3: Carrier Grade Solutions

ASP level redundancy

The SG can cater to a redundant ASP by having the ASP in override traffic mode.
Multiple ASPs could be registered for the same routing information. Only one ASP is
marked as active. The SG sends all SS7 messages to the active ASP. If the active ASP
goes down, the inactive ASPs are also informed of the same. Any other ASP can become
active and inform the SG through SUA messages. The SS7 messages will now start
flowing to the newly active ASP.

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.

SGP level redundancy

There could be two SGPs with the same network configurations.

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.

Load balancing architecture

The following section presents the different distribution procedures as supported by SUA
protocol level feature.

Load balancing of multiple SGP

The ASP knows about the multiple SGPs through which to route to the SS7 network.
Based on the routing information, the messages are routed to multiple SGPs.

Load Balancing to multiple ASP

The SG has multiple ASPs configured in load balancing mode. Based on the message
routing information received, the SUA on SG can distribute the messages to multiple
ASPs.

PRIVATE & CONFIDENTIAL

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

PRIVATE & CONFIDENTIAL

Technical Note 19
Chapter 3: Carrier Grade Solutions

TCAP Transaction Capabilities Application Part

UA User Adaptation
VLR Visiting Location Register
VoIP Voice Over Internet Protocol

PRIVATE & CONFIDENTIAL

20 Technical Note
 Chapter 3: Hughes Software Systems: A global leader

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.

Incorporated in 1991, HSS is an ISO 9001certified company, assessed at SEI-CMMI Level 5.

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.

HSS’ Comprehensive Solutions

HSS is the leading provider of outsourcing services and products to Network Equipment Providers
(NEP), worldwide.

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:

•= Reducing costs by outsourcing software development and maintenance

•= Developing Next Generation Network elements on standard COTS hardware and off-the-shelf
software, or reusing current hardware platforms with off-the-shelf third-party software

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

PRIVATE & CONFIDENTIAL

Technical Note 21
Chapter 3: Hughes Software Systems: A global leader

•= Enhanced Service Platforms

•= Gateway GPRS Support Node (GGSN)
•= Home Location Register (HLR)
•= Intelligent Peripheral (IP)
•= IP-Centrex
•= IP-PBX
•= Media Gateway/ Media Servers
•= Mobile Switching Center (MSC)
•= Node B
•= Radio Network Controller (RNC)
•= Service Control Point (SCP)
•= Serving GPRS Support Node (SGSN)
•= SIP Server
•= Softswitch
•= Test and Measurement products
•= Wireless Softswitch

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.

PRIVATE & CONFIDENTIAL

22 Technical Note
 Chapter 3: Contact HSS

Contact HSS
For more information, please contact HSS at:

United States +1-866-HSS-0247

(301)-212-7988

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

You can visit us at http://www.hssworld.com

PRIVATE & CONFIDENTIAL

Technical Note 23