Sua
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Sua as PDF for free.
More details
- Words: 4,492
- Pages: 23
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: [email protected] 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 Ethernet
MG
MGC
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 IPSCP. 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 Ethernet
MG
MG
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
SSP
SS7 Links Ethernet
SS7 Network
STP
STP
SS7 SG Node
SUA/SCTP IP Network SUA/SCTP Softswitch
MG
IP-based SCP
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
RNC
SS7 Links Ethernet
SS7 Network
STP
STP
HLR
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 Ethernet
RNC
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 subnodes 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,. 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 : [email protected]
You can visit us at http://www.hssworld.com
PRIVATE & CONFIDENTIAL Technical Note
23
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: [email protected] 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 Ethernet
MG
MGC
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 IPSCP. 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 Ethernet
MG
MG
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
SSP
SS7 Links Ethernet
SS7 Network
STP
STP
SS7 SG Node
SUA/SCTP IP Network SUA/SCTP Softswitch
MG
IP-based SCP
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
RNC
SS7 Links Ethernet
SS7 Network
STP
STP
HLR
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 Ethernet
RNC
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 subnodes 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,
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 : [email protected]
You can visit us at http://www.hssworld.com
PRIVATE & CONFIDENTIAL Technical Note
23
