The Role of IMS in PSTN-to-VOIP MigrationThe Role of IMS in PSTN-to-VOIP Migration

How IMS and TISPAN promise to help telcos move to next-generation networks * How TISPAN builds on IMS * PSTN emulation or simulation? * Gaps in the standards

December 2, 2005

25 Min Read
Light Reading logo in a gray background | Light Reading

IMS – the IP Multimedia Subsystem (see IMS Guide) – developed originally by the 3G mobile community, is now seen by many service providers (not just by vendors) as the key to migrating legacy wireline networks towards IP, next-generation networks, and voice over IP.

In an online poll, more than a third of the participants in the recent Light Reading Webinar on which this report is based rated IMS as the “central element” in the migration of the PSTN to NGNs, and more than half thought that it would be an “important part” of this migration.

There are a lot of reasons for this wide interest. In principle, IMS offers service providers benefits such as:

  • Layered architecture that separates transport, control, and applications

  • Access-agnosticism, allowing service providers to converge fixed and mobile networks

  • Real-time IP applications with QOS, security, charging, and other key needs of telcos

  • New kinds of applications that blend features from different applications together – for example, online gaming and telephony

  • More applications, much more quickly and at much lower cost, while still retaining control over QOS, tariffing, billing, and revenues

  • Access resources, applications, and customers in legacy networks – meaning that IMS can be deployed gradually, not just as a costly overlay

Inevitably, this network nirvana is not going to be reached overnight. Although the transition to NGNs is beginning to accelerate, there’s still a massive standards effort going on to develop IMS for this converged wireline/mobile role and to fit it into the wider framework of NGN standards. In particular, this means TISPAN, which is the European Telecommunications Standards Institute (ETSI)'s increasingly dominant NGN service architecture, and which builds in additional functions to IMS to handle PSTN migration. And close attention is now also being paid to regulatory, security, and border-control issues, which are crucial in any practical PSTN migration.

So service providers have a lot to think about, ranging from the almost philosophical “What will an evolved telephony architecture look like?” to the grittily technical “Which is more appropriate – PSTN emulation or PSTN simulation?”

Here’s a hyperlinked table of contents:

  • NGN Drivers & Key Issues
    Money and money

  • IMS Features & Benefits
    Creation and control of high-value, real-time IP applications

  • IMS Standards Support
    The world and his dog

  • IMS & TISPAN
    Go together like a horse and carriage

  • PSTN Emulation & Simulation
    The big choice for telcos

  • Evolving Telephony
    The longer-term goal

  • Session Border Controllers & Security Issues
    Where the holes are

Conference

Many of these topics will be discussed in detail at a Light Reading Live conference to be staged in London on December 8, entitled "IMS:Blueprint for an Applications Revolution", hosted by the author of this report, Graham Finnie. Click on this link for more information.

Webinar

This report was previewed in a Webinar hosted by Graham Finnie, Senior Analyst, Heavy Reading, and sponsored by {dirlink 2|9} (NYSE: ALA; Paris: CGEP:PA), {dirlink 2|32} (Nasdaq: ERICY), and {dirlink 2|53}. It may be viewed free of charge in our Webinar archives by clicking here.

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

For a comprehensive look at how IMS is driving network convergence, check out IMS: Blueprint for an Applications Revolution, to be held at the Langham Hotel in London on December 8, 2005.

Hosted by Graham Finnie, Heavy Reading Senior Analyst, IMS: Blueprint for an Applications Revolution will ensure that attendees understand both the opportunities and threats the IMS revolution presents.

For more information, click here.



There are two distinct sets of drivers pushing carriers towards next/new-generation networks (NGNs) and VOIP. One is related to lowering operating expenses (opex) and rebuilding the existing PSTN – at least for the incumbents. The other is to making sure that carriers can create new revenue streams, and in a very cost-effective way.

Lowering opex means such things as:

  • Preparing for projected telephony revenue declines

  • Leveraging current broadband network rollouts

  • Replacing aging PSTN equipment

  • Ensuring service transparency in the migration to NGNs

  • Minimizing risks in the migration to NGNs

New revenue streams means such things as:

  • Low incremental cost for adding new services

  • Fixed/mobile convergence

IMS is emerging as a key enabler for these goals.

“Of all these, low costs for new services and enabling fixed/mobile convergence is really what drives the need for IMS,” says Ragnar Erkander, head of the IP Softswitch and Networks Unit at Ericsson.

Carl Rijsbrack, Marketing Director, Service Delivery, Alcatel, takes a similar view of the role of IMS in NGNs. He points out that NGNs are evolving through three stages, starting with basic cost reduction, then moving through immediate service innovation with VOIP and multimedia, and finally entering a stage of providing telcos and carriers with the means to compete successfully in the new marketplace by using IMS.

“With an IMS architecture, we take in these market trends. It gives improved customer service, a reduction in churn because you provide more value to the customer, and cost reduction because of the ability to increase value and the fact that you can offer converged services,” he says. “So IMS really handles the business issues currently faced by the service providers.”

IMS was developed initially by the 3rd Generation Partnership Project (3GPP), the umbrella standards body for the UMTS family of 3G mobile standards. It was initially specified in IMS Release 5 in 2002, but there have since been further releases.

IMS was designed to handle any IP-based service or application but, in particular, real-time, session-based applications. So 3GPP decided to base IMS on the IETF Session Initiation Protocol standard, already widely used for VOIP. (See SIP Guide.) However, 3GPP added various extensions for important concepts in the mobile world that it wanted to retain during the transition to IP. These included QOS, the ability to handle mobile radio bearers efficiently, and authentication and profile management.

Overall, the main purpose of IMS is the creation and control of high-value, real-time IP applications, such as telephony, conferencing, messaging, and multiplayer games. The objective is to build a more powerful mechanism for the all-important tasks of building valuable applications that retain customers and induce them to increase spending.

IMS Architecture

Figure 1 shows the fundamental principle of IMS: It is built on a layered architecture, this is the key to its power. There are three layers: a transport plane, a control plane, and a service plane. The control plane is the heart of IMS.83597_1.gifThe strength of this architecture is that it extends the IP network from user equipment, through the control layers, to the service or called party, while remaining agnostic both as to the type of access network and to the type of service. Because it is access agnostic, IMS is not limited just to 3G networks – it is for legacy networks and new access networks as well. This is important for understanding why IMS has moved beyond 3G into other types of access network, such as DSL/IP.

The core new element created in IMS is the Call Session Control Function, which serves as a centralized routing engine, policy manager, and policy enforcement point, facilitating the delivery of multiple real-time applications using IP transport. This function is application-aware, uses dynamic session information to manage network resources (feature servers, media gateways, and edge devices), and provides advance allocation of these resources for each application and user context.

At the upper layer, 3GPP has defined a variety of applications servers, including both SIP-based applications servers and legacy applications servers.

Other important elements, not shown in Figure 1, are the Breakout Gateway Control Function (BGCF), which picks the network where PSTN breakout is to occur, and the Media Gateway Control Function (MGCF), which provides the signaling interworking with the PSTN, or with the circuit-switched side of 3GPP.

But there is another key new element in IMS – the Home Subscriber Server (HSS).

Home Subscriber Server

The HSS offers open access to service-related data for each subscriber, and so supports the sharing of data (such as presence status) among multiple services. This makes the HSS an important feature of the IMS architecture, as it eases innovation and addresses a range of service-logic interaction issues that have bedeviled earlier service architectures, such as the Advanced Intelligent Network (AIN). The HSS is very flexible, and supports open read/write access to subscriber data from various front ends, such as the Web, phone, SMS, and set-top box.

“If we had to pick out one thing that sets IMS apart from earlier next-gen telephony architectures, it is the Home Subscriber Server,” says Martin Taylor, VP for Product Management and Technology Strategy at MetaSwitch. “The HSS makes a big difference to our ability to develop and deploy new services over an IMS infrastructure. For the first time, we have an open interface that lets different application servers share information about subscribers such as their presence status.”

Figure 2 shows how the HSS fits into IMS, where it acts as an open repository of all data about each subscriber and that subscriber’s services: What services are subscribed to, what activation state they are in, and what parameters the subscriber has set to control them. IMS is the first standard architecture that provides these kinds of open interfaces to all the subscriber data. In earlier NGN architectures, such as MSF Release 2 architecture (and in legacy architectures like AIN, and also in all the currently deployed softswitch architectures), subscriber data has always been implicitly owned by the Call Agent and is not easily accessible to other network functions such as Application Servers. Having open subscriber data in IMS thus helps with some real service development and deployment issues.

83597_2.gif“Imagine we are trying to develop a new service whose logic varies according to whether a subscriber has a call forwarding service activated or not. We couldn’t have solved this problem with AIN [Advanced Intelligent Network] technology, or with earlier generations of VOIP architectures, but we can – in principle, anyway – with IMS,” says Taylor. “And having open access to subscriber data makes it easier for a service provider to develop and deploy new kinds of front-end interfaces that let subscribers view, interact with, and update their service-related data – such as the IPTV set-top box, for example.”

Application Architecture

As Figure 3 indicates, the IMS Application Architecture is potentially fairly complex, but a key point is that it allows a lot of flexibility in the way that services are created with different applications servers, and it integrates with legacy services.

83597_3.gifFor example, a messaging environment could integrate traditional voice features, such as callback, or call waiting, for an Internet call. To do that, the IMS architecture allows the triggering of multiple application services and manages the transactions among them.

“The value we see now in working with real IMS deployments with customers is that you can glue together your traditional environment and service experience with the new application experience,” says Alcatel’s Rijsbrack. “You can provide the biggest value for IMS in really having a VOIP strategy for the future.”

IMS has attracted an unusually wide consensus in the standards community on its role in the transition to NGNs. Table 1 lists some of the principal standards bodies that are either working on IMS or incorporating it into their work.

Table 1: Standards Bodies Supporting or Involved With IMS

Body

Network Type

Name

Status

IETF

Any IP network

Session Initiation Protocol (SIP), Diameter

SIP approved in early 1999; IETF has worked closely with 3GPP on IMS

3GPP

UMTS mobile networks; being extended to other access networks

IP Multimedia Subsystem (IMS)

Initially defined in 3GPP Release 5; refined in Release 6; Release 7 now in preparation

3GPP2

CDMA2000 mobile networks; being extended to other access networks

Multimedia Domain (MMD)

Mirroring developments in 3GPP; interoperable with 3GPP IMS

CableLabs

Cable IP networks

PacketCable 2.0

IMS expected to form the core of SIP-based control layer

ETSI

Next-generation wireline networks

TISPAN

Release 1 to be approved in December 2005, and is heavily based on IMS

ATIS

North American wireline networks

NGN

Basing its work heavily on TISPAN

ITU

Next-generation wireline networks

ITU SG13 NGN

Largely based on TISPAN work

OMA

All mobile networks

OMA POC

Focused on standard definition of services



Historically, the 3GGP worked closely with the IETF to standardize the basics of IMS. This work was subsequently used by the 3rd Generation Partnership Project 2 (3GPP2) for its CDMA 2000 Multimedia Domain, which is based largely on IMS.

CableLabs is using – or is expected to use – IMS in the core of its SIP-based control layer for the cable MSO business. And, very importantly, ETSI used IMS as a basis for its TISPAN NGN architecture, which aims to provide a universal structure for all NGN-based telecom services.

This is important, because TISPAN looks to become the NGN service architecture, as both the North American wireline standards organization the Alliance for Telecommunications Industry Solutions (ATIS) and the International Telecommunication Union (ITU) internationally are basing their own NGN architectures on TISPAN, and hence on IMS. So, clearly, it is important to understand what TISPAN is and its relation to IMS.

TISPAN is quite a mouthful, being no less than Telecommunications and Internet Services and Protocols for Advanced Networking. Basically, to avoid reinventing the wheel, TISPAN uses IMS for what ETSI defines as "conversational" services – essentially any call session of the SIP type. TISPAN also adds a series of subsystems that better meet the broader needs of those migrating to NGNs, especially those like incumbent telcos running PSTN (and broadband DSL) services. So IMS is very much at the core of what ETSI is trying to achieve with NGNs.

TISPAN is working through a series of releases, of which Release 1 was scheduled for the summer of 2005; it has been put back several times, but will definitely be approved in December 2005. This delay partly reflects the increasing importance of these standards, which is getting more and more people involved in helping to define IMS.

TISPAN Architecture

The TISPAN Reference Architecture, even when looked at from a high level, is pretty complicated, as Figure 4 indicates. It is important to note in this context that TISPAN is concerned in a wide sense with NGNs, and it is not just about adding IMS capabilities to them.

83597_4.gifLike IMS, TISPAN is a layered architecture, but more elaborate. In Figure 4, end users are on the left, and the fixed wireless access network and the common IP core transport network (the transport plane) are at the bottom. To the right are the network-to-network interfaces and gateways (only the PSTN is shown). In the upper part is the service control plane, where there are different clouds for different service types – for example, for softswitch PSTN emulation, or for IMS services.

In the middle is the Resources and Admission Control Function, which controls the capacity available for the different services. There is also the Network Attachment subsystem for user authentication and location data for emergency calls and so on.

Figure 5 shows in more detail the relationship between 3GPP’s IMS work and TISPAN. There are the three IMS planes: transport (yellow), session control (purple), and application (green). It emphasizes that TISPAN, which is extending IMS towards fixed networks, can be viewed as part of the IMS progression of releases. So Release 5 covered mobile access, Release 6 added wireless LAN access, and now Release 7 (which equals TISPAN Release 1) adds a fixed component, DSL.

83597_5.gifRelease 7 adds only two main functions that are crucial to fixed networks:

  • Network attachment, which means basically "who are you?" and is needed on a fixed line because there is no SIM card to identify the user

  • Resource admission to reserve resources in the fixed network to support the session

“Basically, it is IMS extended towards the fixed world, but leveraging 95 percent of the full IMS standardization, which is therefore the guarantee that this is the environment for having a fixed/mobile converged network in the future,” says Ericsson’s Erkander.

There are two important service subsystems that ETSI has defined, referred to as PSTN Emulation and PSTN Simulation. According to ETSI the distinction is:

  • PSTN/ISDN Emulation – "Provides PSTN/ISDN-like service capabilities using session control over IP interfaces and infrastructure"

  • PSTN/ISDN Simulation – "Provides PSTN/ISDN service capabilities and interfaces using adaptation to an IP infrastructure"

The idea of PSTN Emulation is to create a service in an NGN that is effectively identical to the PSTN, with the same feature set and user ergonomics. This means that, as far as the end user is concerned, nothing has changed. In contrast, PSTN Simulation provides something that looks generally like a PSTN or ISDN service, but doesn’t resemble it in all respects. For example, it can use a variety of new terminal types, offer new value-added features, but also not offer some old ones. Simulation is more about allowing evolution into a new NGN environment than replicating the old environment exactly.

Crucially, the Emulation/Simulation distinction gives telcos and service providers a choice in their NGN migration strategy, and Table 2 shows some of the issues. According to Alcatel’s Rijsbrack, a key factor for telcos in making this choice will be their current competitive situation.

Table 2: TISPAN Supports Two Kinds of VOIP

Simulation ...

Emulation ...

Broadband voice over IP

Type

PSTN replacement

● Alternative provider ● Incumbent in tit-for-tat mode

Service Provider

● Incumbent with investment in futureproof solution for PSTN replacement/growth

Early adopter: intelligent device, techy

End User

Mass telephony users: black phone, conservative

Now

Timeline

Over some years

● Telephony subset ● Part of multimedia

Features

● PSTN emulation ● Voice per se



“This is not about having two systems, nor about having two architectures; this is about introducing [IP] voice capability at the time when it is most business justifiable,” he says. “Both simulation and emulation are part of the IMS picture. It is critical to understand when an operator would introduce which type of VOIP. This is clearly derived from their competitive position and market, and also on the status and behavior of the existing PSTN.”

He argues that, where telcos face strong competition, and a lot of pressure to include VOIP in their broadband service bundles, PSTN simulation is the better choice, because the overriding need is to respond quickly and build a position in the new, and evolving, multimedia market. Conversely, where competitive pressures are less, and the telco’s main interest is in moving to a lower-cost NGN base for its voice services, then PSTN emulation makes more sense.

PSTN Emulation

Certainly, with 180 million existing PSTN lines in the U.S. in need of an IMS-based solution for complete migration to NGNs, telcos face a major long-term task.

“We see PSTN emulation as absolutely critical to the adoption of IMS in fixed networks. It’s going to take a very long time to migrate the [existing] POTS terminals,” says MetaSwitch’s Taylor. “We think there is going to be a need to modernize the telephony infrastructure – and IMS is the architecture we want to use to do that. But we want that migration to go much faster than the endpoints are going to migrate from POTS to IP. So it’s essential that IMS supports PSTN emulation as a native built-in function.”

He points out that the PSTN service logic must be distributed between PSTN access adaptation and the PSTN emulation server, as shown in Figure 6. With more than 100 features requiring complex SIP call flows, this is not easy, especially as there are no effective standards.

83597_6.gifWhile it is easy to map PSTN signaling to SIP for simple call setup, it becomes much harder when trying to emulate the entire library of standard PSTN services by using SIP signaling. One of the fundamental problems is the architectural mismatch between PSTN and SIP. The PSTN uses a stimulus/response protocol, where the terminal is completely dumb, and all the intelligence is in the network. In contrast, SIP is a peer-to-peer session control protocol, where the terminal is expected to be highly intelligent and capable of performing call processing, while the network may be relatively dumb. So there are widely used PSTN services which fundamentally depend on centralized intelligence (such as remote access to call forwarding) and which cannot practically be implemented by using intelligence in the terminal.

“The IMS standards do not help us at all in this area,” says Taylor. “IMS does not define SIP call flows for even the most basic calling services, so there is nothing for us to call upon here. There is more activity in this area in the IETF, and there are many RFCs and Internet drafts that discuss SIP call flows for basic calling services, but these are not standards, and most of these documents define multiple different call flows for the same basic feature. In working with a large number of different SIP endpoints, including IADs, analog telephone adapters, SIP phones, and most recently Broadband Loop Carriers, we have found numerous differences in the way these devices support calling features, and we have had to adapt our application server logic accordingly.”

He points to a recent trend in SIP endpoint implementations for handling hookflash. This is an important aspect of PSTN signaling, required for services such as call transfer and three-way calling. Instead of handling hookflash and the session manipulations that it implies locally, these endpoints simply send a SIP message indicating that a hookflash has taken place, and expect an application server to take care of things.

“This is a pretty horrifying development for SIP purists, but it’s a direct reflection of the real-world difficulties that implementers face when trying to emulate PSTN services using SIP."

In such an environment, success needs “unprecedented” cooperation between access vendors and softswitch vendors. Says Taylor: “The reality is that this problem is being solved on the ground today purely by bilateral agreements between softswitch vendors and access network vendors. So this problem is getting solved, and we are confident that PSTN emulation can be delivered from a core IMS network, and that this is the right thing to do.”

PSTN Simulation

Even PSTN simulation, with its less ambitious PSTN feature set and flexibility to create new features and services, faces call-control issues over endpoint/network interactions. Typical users today are early adopters and business users, and one of the main drivers here is the replacement of Centrex feature phones. SIP business phones have a lot of local service intelligence, but need to combine this with a considerable amount of intelligence in the network. For example, there are many business features – such as hunt groups – that cannot implement in the phone alone, because they need knowledge of a number of different phones in order to operate. For many other call features, there is still a lot of debate about where and how to implement the service logic – and plenty of divergent views.

This can lead to a wide variation in the details of how features are implemented. For example, a Do Not Disturb feature could be implemented differently by two phones as follows:

  • Phone A returns 480 Temporarily Unavailable – rejects call entirely

  • Phone B returns 302 Moved Temporarily – call forwarded per local phone configuration

While this is OK for early adopters, who don’t mind a bit of trial and error, it is not really acceptable for mainstream business users who are looking for consistent and predictable service behavior. So the message seems to be that phone intelligence needs to be combined with network intelligence as well, in order to normalize the services and ensure that users get a predictable and consistent service experience.

Putting PSTN emulation and simulation together into one network produces the picture of Figure 7, which shows the full evolution of voice telephony into a potentially more internationally standardized environment.

Here, emulation is used to progressively modernize customers’ primary PSTN service to lower-cost NGNs, and simulation provides broadband-bundled secondary voice service to increasing numbers of mutltimedia customers. In both these cases, IMS plays a major role.

83597_7.gif“It’s also clear that IMS will play a major role now in many operators’ networks as the first-line replacement,” says Ericsson’s Erkander. “The question is: How will this be done? This is being debated now between vendors and operators. One focus could be to have a fully emulated service and bring all the legacy features into IMS for an emulated service, focusing on providing exactly the same service again. Or another approach is to ensure that the IMS telephony is the same not just for SIP but also for mobile.”

Both ETSI and 3GPP are working on developing a standardized form of telephony that uses PSTN simulation and avoids the need to make any changes to existing standards. This emphasizes the point that telcos would really like to preserve as much as possible of their existing access infrastructures, and TISPAN and IMS do provide flexibility to help telcos leverage current access networks. Figure 8 shows the very wide range of access networks and mechanisms able to support IMS services, and this allows telcos to follow flexible replacement and cap-and-grow strategies to preserve existing investments as much as possible.

83597_8.gif“Service providers will have the flexibility to introduce the necessary gateway capabilities inside their access environments, as well as the necessary trunking gateway capabilities to glue together the traditional world with the new IMS world,” says Alcatel’s Rijsbrack. “Offering different flexibility points by having cards or DLCs or integrated DSLAMs makes IMS very strong in adapting to any local situation.”

Despite all the positives about IMS, there are still some significant gaps in the standards when it comes to real-world telco networks and operations. Two big ones are (almost inevitably, these days) security related: Session Border Controllers (SBCs) and Emergency Services. A lot of work is now being directed to fix them.The SBCs are not even mentioned in the 3GPP IMS specifications, but it is a very important function for fixed networks. It is needed to protect the network from various kinds of abuse, to handle traversal of NAT firewalls in customer networks (not an issue in the 3GPP world because all mobiles have a public IPv6 address), and to support the requirement for legal call interception.

“We haven’t seen much recognition of these kinds of security risks in the IMS standards to date. Indeed, the IMS specifications make no explicit reference to Session Border Control,” says MetaSwitch’s Taylor. “The Proxy-CSCF is the nearest equivalent to an SBC, but the Proxy-CSCF is not mandated by the IMS specs to provide protection of the network against signaling overload, for example. Maybe this is because it is harder to hook up a PC to a 3G mobile access network to inject malicious signaling, and maybe it’s because the IMS does not need to address other kinds of problems that SBCs handle, such as dealing with traversal of customers' network address translation firewalls.”

One possibility is for SBC functions to become more distributed and more integrated with other network elements. (See Figure 9.) So the signaling functions of SBCs could be more integrated with the call processing aspect, while media policing would move out into devices such as edge routers. There needs to be a control interface between these two, and Megaco or H.248 could support it.

83597_9.gifThis may look more complicated than the standalone SBC solution, but it does eliminate an expensive box from the edge of the network, and this enhanced functionality also seems to be quite well aligned with the direction that TISPAN is taking in this area.

TISPAN has not forgotten an extensive range of regulatory-related security and legal requirements. These include such things as:

  • E112 Emergency Speech, Malicious Communication Identification, and Anonymous Communication Rejection

  • Validated location information

  • NGN IMS should support identifiers for fixed lines as well as 3GPP IMS-type user identifier

  • Solutions should support the presence of NAT and firewalls in the access network user premises, and assignment of IP addresses to the user equipment by the access network

  • Management and operational needs including charging and accounting (off-line, on-line, flow-based)

“We see a lot of interest from operators for such requirements as emergency call for VOIP, which is not well specified today,” says Ericsson’s Erkander. “One of the clear requirements is for geographic location – to know where the call comes from. In the PSTN that is easy because the location is defined by the phone number. In VOIP, this is where the Network Attachment Function (NAF) subsystem comes in, from where this information is retrieved and an IP address is registered. This is not a fully standards solution though, but there are first implementations coming out on the market.”

A second key requirement is a callback capability. In the PSTN, this is simple, because Calling Line Identification gives a fixed number to call back to. How VOIP will do this is not yet standardized, and the TISPAN work is possibly leading in this area.

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

You May Also Like