IMS Signaling

Deploying IMS can create some big signaling challenges for telecom operators. Here's how next-gen signaling gateways could help

December 6, 2006

20 Min Read
IMS Signaling

One of today’s big telecom themes is the beginning of a global migration to IP-based next-generation networks (NGNs) that will rest heavily on the IP Multimedia Subsystem (IMS) to support a wide range of advanced services. But it isn’t going to happen overnight, and it’s already leaving service providers and telcos asking themselves how are they going to:

  • Leverage existing services and infrastructure?

  • Deal with complex legacy signaling while moving to simplified NGN solutions?

  • Provide service continuity across different existing networks?

  • Manage dramatically increased signaling message volumes?

  • Supply services in rural as well as in developed markets?

  • Avoid leaving 2G mobile subscribers behind?

This report looks at the signaling issues that the transition to IMS raises, and how they feed back into some of the other issues of the transition. While the huge and rapid growth in VOIP has pushed softswitching and media gateways into prominence, it’s worth remembering that IMS-based services will generate about five to six times the signaling message volumes of VOIP – which in turn produces about the same increase in signaling message volumes compared to good old POTS.

So a carrier’s IMS signaling architecture had better be good. And there’s that little issue of managing next-gen and legacy signaling simultaneously while making the transition to NGN IMS – voted as the No. 1 issue by 40 percent of respondents to an online poll during the recent Webinar on which this report is based.

Here’s a hyperlinked contents list:

Webinar

This report is based on a Webinar, The Role of Signaling Gateways in Next-Gen Networks, moderated by John Longo, Senior Analyst, Heavy Reading, and sponsored by Continuous Computing Corp. , Radisys Corp. (Nasdaq: RSYS), and Tekelec . An archive of the Webinar may be viewed free of charge by clicking here.Related Webinar archives:

— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.

Next Page: Migrating Signaling to IMS – I

The complexity of the IMS architecture will have a significant impact on signaling control, and the development of IMS services will considerably increase the number of messages compared to traditional telephony services.

“In the IMS network, the signaling payload is much larger, and combining that with all the establishing and maintaining of sessions in a stateful environment – rather than in the existing telephony stateless signaling environment – will cause a tremendous growth in the amount of messages in the network,” says Steve French, Tekelec's senior manager of product marketing.

The complexity of IMS and the number of network elements that will have to be deployed mean that the only feasible approach is a gradual evolution, as no carrier can afford to completely wipe out its standing network and start afresh. So carriers must continue to derive revenues from their existing subscribers on the traditional networks, and evolve the network gradually.

This means moving away from today’s basically three-layered architecture – running from top to bottom as:

  • Applications and services

  • Signaling control based on SS7

  • Circuit-switched voice switching – access and transport

...through a number of transitional architectures. Figure 1 shows the first transitional step, driven by the need for cost savings and expansion, from the circuit-switched network to NGN VOIP. This stage is happening now and has been in progress for some time.

In this approach, NGN VOIP has connectivity to the signaling/control and application/services layers in the current network, but carriers are now also deploying new applications with IP access. These multimedia applications are being deployed vertically on top of the VOIP network, in an application-by-application fashion. So each application has its own specific control function, and is tightly tied to the resources of the specific solution.

According to French, carriers have been somewhere like this before – in the early days of moving the PSTN to SS7 itself. Then, as now, control functions were being distributed down to the access and transport layers on individual switches, and also up to the application layer.

“This model became extremely complicated once the network tried to scale. All the additional features required by carriers for the control space had to be paid for and deployed onto all the access and transport devices and also to each of the application devices,” he says. “Upgrading was very difficult, and maintaining a consistent network became virtually impossible. Hence the birth of the device called the signaling transfer point (STP), which is basically the heart of today’s signaling and control layer. It is stateless in nature, and its function is to provide the central point of control between the access/transport layer and the applications in the SS7 space.”

Crucially, the STP provides an economical point for new software releases and operational control by vastly reducing the number of network elements to upgrade and control. This same philosophy will form the second stage of the transition to IMS, as shown in Figure 2.

In this stage, two generic standards-based horizontal layers – IMS services and IMS session control – are added to complete the IMS framework. This “reusable” horizontal framework for delivering multimedia applications replaces the stack of application-specific multimedia control solutions. IMS is based on the 3rd Generation Partnership Project (3GPP) standard, so the IMS session control layer can be multi-vendor in nature and will let carriers more easily and cost-effectively add applications via new application servers, thereby reusing the horizontal IMS framework for each application and not having to set up the session control layers over and over again. This model should provide carriers with much more scaleable and economical solutions than the distributed-vertical model of Figure 1.

Next Page: Signaling Protocols for Migration

There are three key protocols involved in the migration of signaling to IMS NGNs:

  • SS7

  • Sigtran

  • SIP

SS7

SS7 is now a mature, but complex, technology that is fully embedded in the world’s telecom networks and will continue as the predominant technology for many years. Its complexity derives from three main sources:

  • SS7 is subject to a lot of standards bodies and country-specific variations. For example, the International Telecommunication Union, Standardization Sector (ITU-T) , American National Standards Institute (ANSI) , European Telecommunications Standards Institute (ETSI) , NTT Group (NYSE: NTT)/JTT, and Telcordia Technologies Inc. have all produced SS7 specifications, and there are differences in implementation in many parts of the world.

  • SS7 makes great use of multilevel stacks of subprotocols – essentially, there are various protocols to move signaling messages around, others to compose and analyze signaling messages, others to organize transactions based on signaling messages, and yet others to handle particular network applications, such as ISDN or Advanced Intelligent Network (AIN). These can be mixed and matched in various ways into protocol stacks. For example, common stacks are INAP/TCAP/SCCP/MTP3 for AIN; ISUP/MTP3 for ISDN; BICC for wireless infrastructure (for example, HLRs and soft switches); and BB/NB-Networking/B-ISUP/MTP3-B for broadband.

  • There is a split between narrowband and broadband services, which is made more complicated by a close integration with ATM, developed because ATM was seen as the natural broadband Layer 2 when SS7 was extended to broadband during the 1980s. This caused additional protocol changes, new protocols to be developed, and integration with different types of hardware than those suited to narrowband applications.

Nonetheless, carriers need to take advantage of the benefits of IP transport even while maintaining existing SS7-based services. This leads to Sigtran.

Sigtran

Sigtran is a suite of protocols that puts SS7 signaling onto IP transport. Its basic structure (stacked like SS7) is shown in Figure 3 in blue; the orange blocks are elements of SS7 that Sigtran transports.

Working up the protocol stack from the IP transport layer, Sigtran comprises:

  • SCTP (Stream Control Transmission Protocol) – A reliable transport protocol operating on top of a connectionless packet network such as IP. Developed to eliminate deficiencies in TCP.

  • M2PA (MTP2-User Peer-to-Peer Adaptation Layer) – Provides MTP3 (a message transport protocol in SS7) with MTP2 (another message transport protocol in SS7) equivalent service over IP by using the services of SCTP. It is used typically in the core infrastructure between the network elements and the control layer, such as between STPs.

  • M3UA (MTP3-User Adaptation Layer) – Designed for signaling gateways that enable seamless interworking between the SS7 and IP domains. This protocol supports the transport of any SS7 MTP3-user signaling (for example, ISUP and SCCP) over IP by using the services of SCTP.

  • SUA (SCCP-User Adaptation Layer) – Supports the transport of SCCP user signaling over IP by using services of SCTP. A typical use is in accessing a mobile switching center.

Figure 4 shows how Sigtran works in the transition to IP-based networks.

On the right of Figure 4, the SS7/wireless circle illustrates a traditional circuit-switched SS7-based/wireless PSTN, where the call control is provided by a standard ISUP/MPT3/MPT2 SS7 protocol stack. The signaling gateway function is in the middle, and the SS7-over-IP (SS7oIP) network is on the left. The signaling gateway function provides a mechanism to transition from SS7 signaling to SS7oIP. The signaling gateway is fed SS7-based signaling information on one side and uses a network interworking function (NIF) to translate SS7 into Sigtran. Finally, the signaling gateway communicates the Sigtran signaling to a suite of Application Server Processors (ASPs), which emulate the role of the SSP/STP for a specific range of callers, on the IP network on the left of Figure 4.

“When carriers want to take advantage of the efficiencies and cost savings of IP transport without interrupting service or removing existing SS7-related network equipment, they will need to use the signaling gateway function to transfer from the SS7/wireless space to the IP-Network.” says Todd Mersch, Continuous Computing's Trillium product marketing manager. “The ASPs mirror the responsibilities of an SSP (service switching point) or STP in legacy networks. This is the most common core application of the Sigtran technology. It allows carriers to transition to an IP network with incremental investment and minimized risk.”

Figure 5 shows how a complete SS7oIP signaling network might be implemented. The idea is to introduce a Sigtran infrastructure to benefit from the economical, scaleable capacity growth it permits. The underlying IP infrastructure will then be in place for the parallel evolution from SS7 to SIP during a gradual migration to IMS. Once the M2PA is set up in the core of the signaling network, carriers can introduce MTP3 for the A-links for connectivity between the STPs and the endpoints.

SIP

SIP forms the core signaling technology of the NGN IMS. It is based on IETF standards, and is intended to simplify the integration of multimedia into the telecom environment. It does this by broadening the signaling paradigm from handling just a call to managing a session that may include voice, video, and data simultaneously and independently.

In principle, SIP has a much simpler protocol stack than either SS7 or Sigtran, since it is just basically SIP sitting on top of UDP, TCP, or SCTP, which provide the appropriate transport protocol over the underlying IP layer. This drastically simplifies the integration and maintenance of the signaling portion of the application. SIP itself uses 15 methods to manage a session, including basic steps like Invite, ACK, and Publish.

On top of SIP, however, are three generic applications that effectively tailor it to specific purposes by creating specific personalities. These are:

  • Server – Proxy or Redirect – to allow dumb or intelligent session control

  • Registrar – to handle the user/entity authorization activities

  • UA (B2BUA) – to act as the terminal points in the network

While simplifying the approach to signaling, SIP does add some hidden complexities, and these are now becoming mainstream issues because SIP is central to IP NGNs (whether IMS-based or not).One problem may be considered one of simple logistics – there are lots and lots of IETF RFCs and Drafts defining different capabilities and different extensions to SIP for even more specific applications and uses of the protocol. Keeping on top of all this material is a major task.

“The constantly evolving SIP standards require a similarly constant investment to keep your SIP up to date and relevant in the marketplace. In addition, the rapid progression of the standards also contributes to a lot of interoperability challenges, both in the sheer volume of specifications and the openness of how exactly to implement those specifications,” says Mersch. “Finally, by taking advantage of Internet technology in the telecom space, SIP inherits the challenges of security and enhanced network management that comes with Internet technology. These challenges are, however, being met in the marketplace by companies – like Continuous Computing – providing standards-based and interoperability-proven SIP protocol software.”

Next Page: Migrating Signaling to IMS – II

The IMS Call Session Control Function (CSCF) provides the session control between the access/transport and application layers of IMS. It exploits the same underlying QOS-enabled IP infrastructure as set up for Sigtran (see Figure 6). There are several personalities for the CSCF – serving, interrogating, proxy – and the deployment of these elements will be based on how the carrier designs its network. The serving and interrogating aspects will be more appropriate at the core of the IMS network, while the proxy will be more appropriate at the edge. The CSCF is the heart of the control layer and needs to provide the same high performance carriers expect from their existing SS7 control.

Three critical characteristics of a CSCF are its throughput (the number of sessions per second it can support), its scaleability, and its latency. Low latency is very important, because it directly affects the user’s experience, and the CSCF has a lot to do – establishing sessions, checking with the authentication server, accessing the home subscriber server for the subscriber profile, and so on. This has to be done very, very quickly (and irrespective of the nature of the access device), or the user will quickly get a bad impression of the service.

“One of the critical aspects of latency is access to the back-end systems in order to establish the session,” says Tekelec’s French. “Given that the back-end systems may be accessing across the WAN to a data center, there must be a way for the signaling and control layer to contact them in a low-latency fashion. The standards bodies address this with the notion of what they call the Generic User Profile (GUP) server, which came out of the 3GPP standards. The GUP server is essentially a local cache inside the CSCF, so that once you have registered your subscriber and have accessed that information initially, you don’t have to go back to the data center each time you need to establish a session for that subscriber.”

Before operators deploy CSCF functionality as part of their IMS cores, they need to determine how they are going to provide existing services to subscribers who will be served by the CSCF. One option would be to replicate all existing network services and applications over on the new SIP infrastructure – potentially a logistical and financial nightmare for a major carrier. Another option would be to add SIP to all existing application servers – again, potentially another costly and unrealistic option.

A third, and less costly and disruptive option, is to use transitional technologies (that is, service mediation) to provide a “bridge” between the SIP-based IMS network and SS7-based PSTN and 2G mobile networks. The bridge will allow SIP-based terminals to access legacy PSTN/2G services, and PSTN/2G terminals to access (some) IMS services – thus helping to provide revenues from existing subscribers to help fund the capital expenditure that will be needed to pay for the evolution to the NGN.

While undertaking the migration to IMS, operators need to minimize or cap their investments in legacy technologies in order to focus resources on new technology. They will have to operate hybrid networks with both intelligent network (IN/AIN) and IMS services for years to come as networks make the transition. And, as IMS-based networks are deployed, carriers will need to orchestrate the service interactions of multiple SIP-based services.

A service mediation solution enables service interaction among legacy, mobile, VOIP, and IMS networks. It bridges technologies, allowing SS7-based, IN service platforms to coexist and interact with SIP-based platforms to deliver unified services across virtually any network type. There are three major flavors of service mediation:

  • IN service mediation – Consolidates mediation and interworking of IN service platforms with different technologies and protocols.

  • SIP/SS7 service mediation – Extends IN/AIN services to the IMS domain and delivers next-gen SIP-based services to legacy subscribers.

  • SIP service mediation – Mediates multiple services in the IMS domain to create a rich, multimedia user experience.

Figure 7 shows such a transitional bridge in action. The IMS cloud on the left contains a subset of IMS functions that provide the ability to bridge a session from IMS into a PSTN-based call. The serving CSCF routes the signaling and data associated with the session to the Media Gateway Control Function (MGCF) in the center of the IMS cloud. At this point, the paths for signaling and media separate, and the MGCF provides the signaling information over Sigtran to a signaling gateway, which translates it into SS7 and puts it into the PSTN. In parallel to transferring the signaling information, the MGCF provides media control and the actual data to the IMS Media Gateway (MGW), which then sends the media over TDM to the PSTN.

The exploded view of the MGCF protocol stack in Figure 7 illustrates how the next generation of gateways will be complex devices, and, consequently, vendors are putting a lot of effort into developing flexible systems based on standardized components.

NGN Signaling Platforms

The architectural complexity and performance requirements of IMS are encouraging a move away from proprietary hardware platforms to those based on open standards, particularly the PCI Industrial Computer Manufacturers Group (PICMG) ’s AdvancedTCA Specifications for Next Generation Telecommunications Equipment (ATCA) and its most recent offshoot – MicroTCA (covered in detail in an upcoming report).

“Openness was one of the key requirements of IMS – that was actually done at a network level,” says Eric Gregory, senior manager for ATCA product line management at Radisys. "ATCA takes openness to the box level. All the platform interfaces and a lot of the technology within the switching backplane have been defined by PICMG."

IMS network elements generally are affected by a stiff set of requirements. Some of the main ones are:

  • Architectural simplicity

  • Support for next-generation capacity and performance requirements, as it is no longer acceptable for vendors to put out a new platform and meet only legacy requirements

  • Feature-rich to enable cost-effective new services, yet must be standards based – so one platform has to be able to support SS7, Sigtran, and SIP technologies

  • Carrier-grade reliability

  • Serviceability

  • Integrated management interfaces

  • Security – SIP makes heavy use of IPSec, for example

  • Low total cost of ownership – this was the initial big push behind the ATCA specification

  • Regulatory requirements

Figure 8 shows how a full platform for a signaling gateway function for high-density requirements would look, using a standards approach to meet the typical requirements. It has:

  • Application processing blades running ISUP and Sigtran protocol stacks

  • Modular termination of SS7 links using PMC/AMC modules on redundant blades

  • Redundant storage on switch/OAM blades or storage on each application blade

On the far left of Figure 8 is the shelf management function, providing the basic functions to maintain the shelf and its components, such as loading and unloading BIOS. The modular termination of the SS7 links, which allows the use of both PMC and AMC modules, provides scaleability for higher densities, as well as being able to scale as the market requires.

The green blades in the middle are a base and fabric switching components, which in this scenario are exploited to provide the OAM functions as well as redundant storage for the applications. On each is shown a local swappable AMC disk, used to store the configuration and boot data required on any platform. Finally, on the far right, there is a cluster of the high-end performance blades for handling the Ethernet terminations. A high-density signaling gateway configuration such as this provides a scaleable black-box solution to allow for a staged migration of users from the existing SS7 carrier network to new, lower-cost, IP-based networks. The staged migration is made possible by the built-in platform scaleability, making regular capacity upgrades or the addition of more signaling gateways unnecessary.

Reaching the Goal

Overall, many operators view a gradual migration to IMS at the signaling layer as the most realistic, technically feasible, and cost-effective approach – both for migrating to IMS and also for managing a hybrid SS7/SIP signaling network for years to come.

Introducing Sigtran (SS7oIP) into the signaling network provides a stepping stone for migrating to SIP signaling in an IMS architecture. The idea is to introduce standards-based Sigtran, which is fully compatible with the existing SS7 signaling network, for increased signaling capacity at a lower cost. The underlying IP infrastructure can then be leveraged for the parallel evolution from SS7 to SIP – as SIP signaling will traverse the same QOS-enabled IP network.

As operators move to IMS, they will have to deal with myriad financial, technological, and network issues. Operators will need to minimize or cap their investments in existing technologies to focus resources on new technology. And they will have to operate hybrid networks with both intelligent network (IN/AIN) and IMS services for years. A key part of their transition strategy would be to use transitional technologies to provide a SIP/SS7 service mediation function between the SS7-based TDM and 2G wireless networks and the SIP-based IMS network. And, as IMS-based networks are deployed, carriers will need to orchestrate service interaction of multiple SIP-based services.

“The IMS architecture should provide operators with a reuseable, standards-based framework, thereby enabling operators more quickly and cost-effectively to develop and deliver new, multimedia services,” says Tekelec's French. “The complexity of this IMS architecture will have a significant impact on signaling control and will create many issues for operators. A carefully planned transition strategy – from both network and business perspectives – will be a key competitive advantage for operators migrating into the IMS space.”

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like