What's Up With IMS?

AT&T Inc. (NYSE: T)

BEA Systems Inc. (Nasdaq: BEAS)

BT Group plc (NYSE: BT; London: BTA)

Continuous Computing Corp.

Data Connection Ltd. (DCL)

ECI Telecom Ltd.

Empirix Inc.

Ericsson AB (Nasdaq: ERIC)

iBasis Inc. (Nasdaq: IBAS)

Infonetics Research Inc.

JacobsRimell Ltd.

Mavenir Systems Inc.

Metaswitch Networks

Nokia Networks

Nortel Networks Ltd.

Openet Telecom Ltd.

Radvision Ltd. (Nasdaq: RVSN)

Sonus Networks Inc. (Nasdaq: SONS)

Sprint Corp. (NYSE: S)

Tekelec

“If you want to take an IMS and make it into a carrier-grade network, there are a good number of things that are missing; and so we are working on those, and we would hope that over time they would become standards.”
— Siroos Afshar, Assistant VP, Services Core & Premises Architecture, AT&T

“IMS will meet success if we go back to the business basics. Global mobile operators have worked hard to build unique market positions, brands, and service differentiation based on existing subscribers and rich services in their respective markets. Vendors cannot ignore this market power by forcing operators to start from scratch and compete effectively with the new convergence and Web players. IMS service deployments need to incorporate current mobile subscribers, their legacy devices, and existing set of services to enhance the IMS business case. Bottom-line: IMS should be made simple, universal, and end-user focused.”
— Shubh Agarwal, Director of Marketing, Mavenir Systems

“Some traditional mobile-infrastructure-only vendors have pushed operators to implement IMS straight away, even before having a real business case for it. They tried to convince the community about the value of POC or video sharing justifying IMS by itself. In fact, it was far from being sufficient to justify such a major move with global core networks – and an application like POC can easily be done without IMS... What we see now is a much more pragmatic SIP and IMS evolution from the wireless and wireline operators based on FMC and VOIP business. Typically, these SIP applications in IMS-ready mode or full IMS environment provide a positive ROI within a year or two maximum.”
— Eric Bezille, Product Marketing Prime for IMS, Nortel

"As a framework for, at the low level, doing network access control and user authentication and so on, IMS is very powerful. There is value in having that security infrastructure – for maintaining billing relationships with customers and third-party suppliers, for example. And it provides a very nice infrastructure for core operator services, and for things like voicemail and so on. With that said, IMS won’t live up to the hype of providing a ubiquitous framework for all applications.”
— Jonathan Cumming, Director of VOIP/IMS PLM, Networking Protocols Division, Data Connection

“People have unrealistic expectations of where IMS is going to be at this point of the game. Everyone says that they don’t hear about large-scale deployments. There are a lot of folks saying, IMS is a failure, it’s not going anywhere, it’s dead, it’s like the Advanced Intelligent Network. But it is unreasonable to think that operators are going to throw a billion dollars out there and just build a whole new network. That’s not the way it works. The transition to IMS is going to be very slow and incremental, just like every other network migration heretofore.”
— Steve French, Senior Manager, Product Marketing, Tekelec

“Two years ago you couldn’t stop equipment vendors with huge displays at telecoms shows talking endlessly about IMS. Things have gone quiet because I think that companies are starting to finally get serious about rolling it out. The IMS cores are already in the process of being built – in some of the more progressive operators, have already been built – and there are significant financial commitments being made. IMS on-line charging systems are part of this initial spend as they are now a preliminary consideration rather than something left to later phases of IMS rollouts.”
— Joe Hogan, CTO and Founder, Openet

“At the moment, operators are in trials and evaluation to try and understand whether or not the technology is robust enough for deployment. Prime motivation for deployment is to be able to aggregate internal and external services with a view to creating new products. As with any new technology, initial product offerings are substitution products with just a few more bells and whistle – for example, voice with presence and buddy lists.”
— David Jacobs, CTO, JacobsRimell

“The role that iBasis sees for IMS in its network is for new services and rapid service creation.”
— Ajay Joseph, VP, Network Architecture and Engineering, iBasis

“Service providers are now rolling out service products into production deployment, where they are generating revenue using IMS. They may not talk about it as IMS, because customers don’t buy IMS, they buy products. But the implementations are IMS, and that – probably over the last six months – is a true rollout of IMS-based services.”
— Chris King, Senior Director, Worldwide, Telecommunications Markets, BEA Systems

“The innovation in IMS enablers is where the next step needs to occur. Building applications with a limited set of enablers of today is alright. I think it gets your service launched, and it will drive some incremental revenues. But for IMS to become more mainstream requires enablers that address regional tendencies.”
— Ken Lee, Director, Worldwide Product Marketing, BEA WebLogic Communications Platform, BEA Systems

“We don't see full IMS implementations in the next two to three years. However, elements of the system are already in place today.”
— Ron Levin, Director of Product Marketing, Network Solutions, ECI

“I would say we have not fully utilized the overall vision of IMS just yet. I think there is still a lot of room to go before we can say, yes, the original promises of IMS have been met.”
— Manish Mangal, Director of Technology Development Planning, Sprint Nextel.

“People hear or see that there is ETSI Tispan IMS, and there is PacketCable IMS, and the ITU has its NGN where they have used IMS. I don’t think there is immaturity in those standards as much as there is a general market confusion over what part of the network each one is really addressing.”
— Todd Mersch, Product Marketing Manager, Continuous Computing

“The focus has slightly shifted from deploying IMS as a holistic architecture to zeroing in on the applications that would be key to the initial rollout. The earlier thought was that it is an architecture for the future, and carriers were looking to put it in their infrastructure without paying too much attention to what was going to ride over it.”
— Vikram Saksena, CTO, Sonus Networks

“Different carriers are taking slightly different positions. Some are OK to be bitpipes; some do not want to be relegated as mere bitpipes, and they want to put in more control, more applications that provide a better user experience. So those looking at putting more interesting applications in the core are the ones who are backing IMS.”
— Manish Singh, VP, Field Engineering, Continuous Computing

“We perceive IMS services as an optimal mix of third-party and operator services. We believe that IMS is the right service architecture to enable efficient time-to-market of services and to optimize opex and capex... IMS has gone 80 percent of the way toward becoming a mainstream implementation, but it is still evolving. We feel that there are still some tweaks, changes, and additions that will be made to the standards before it can be considered final.”
— Sagi Subocki, Product Manager, Technology Business Unit, Radvision

“We are going to have to wait and see how operators move to converge several services. Today you see islands of services – some services are on IMS, others are not. At some point you are going to see the services merge together on the IMS platform.”
— Stéphane Téral, Principal Analyst, Service Provider VOIP, IMS & FMC, Infonetics Research

Next Page: IMS Now: What, Why & Where

It’s worth recapping what IMS has become, and why it is important enough to have so much industry effort thrown at developing and standardizing it. According to the IMS Forum , one of the many industry bodies involved in developing and promoting IMS:

Although this reads like a telco’s dream service portfolio, it's jumping the gun a little, since it's flagging up the applications and services that IMS will help to enable – crucial to the point of implementing IMS, of course, but not actually what IMS itself is. For that, it is necessary to stand back a little.

IMS is – deep breath! – an architectural framework for enabling, controlling, and managing service and application sessions in an IP converged multimedia network, fixed or mobile. [Ed. note: Exhale. Please.]That is to say, IMS is not a complete network or service architecture – for example, it has nothing to say about the internals of service or application logic, nor about how all the different service logics would be supported or interact (there’s no runtime environment in IMS, for example), nor how operators would do essential things such as service bundling and packaging.

Of course, the word service is elastic, and the abilities to, say, converge two or more originally separate services into a single device, or to add further functions to existing services – such as network presence or location – are easily seen as creating or supporting new services. As IMS is, in principle, excellent at this sort of thing, it’s easy to slip into the way of talking that assumes IMS is a full-service architecture. But it isn’t, and it isn’t even needed to deliver many services of this type, as vendors and operators have already demonstrated.

Another possible misapprehension is to go too far in the opposite direction and see IMS as just a narrow telco thing – particularly, the Advanced Intelligent Network (AIN) brought up to date. This is not really apposite, as AIN was developed as a circuit-switched voice-centric architecture with very limited capabilities in present-day terms.

In contrast, IMS, with its IP base, leans much more to the mainstream of Internet-style services and applications development. So IMS vendors are putting Web 2.0 support into their SIP servers, for example, and supplying SIP software containers that will support widely understood and used programming models, such as HTTP and Enterprise JavaBeans. This makes IMS capabilities much more accessible to both programmers and applications and so offers the prospect of becoming a mainstream software resource.

IMS Capabilities

So what IMS does offer are very complex and sophisticated capabilities for service and application session management, combined with standardized interfaces among applications, network layers, and back-office systems. Among the perceived benefits of this are:

Improved operator network and service control, as it combines both session or call control with interfaces to lots of nice management features for controlling bandwidth across the core, what users are allowed to do, making appropriate charges, and so on.

Avoidance of service silos by allowing different services to be combined and interact, and to share common data (such as user profiles, location, and presence information). A key aim here is ultimately to make the end service as independent as possible of the method of access.

Creation of new services rapidly, and the potential for supporting advanced services such as adding real-time collaboration and communications capabilities to voice. Ultimately, it should be possible to create mash-ups involving both Web and telecom applications.

Lower costs and improved investment efficiency by using standard off-the-shelf gear and being able to reuse a common platform for multiple services. One aspect of this is to use a common platform to provide services over wireless and wireline assets, with the potential to reduce operational expenditures – one reason why operators such as AT&T and Sprint Nextel were the first to begin trials and evaluation of IMS in the U.S.

Better BSS/OSS network interfacing through the enhanced authentication, charging, and other functions of IMS.

Providing a good fit with IP to the edge. This is becoming a big concern of many operators in the evolution of mobile and FMC, and is driving the importance of femtocells and UMA.

Understanding and assessing a big and complex technology. IMS presents operators with a huge task in understanding and assessment. The present incomplete standards already fill several DVDs, and IMS has passed the stage where any single person can hope to be an expert on all of it. So operators are necessarily feeling their way, with a lot of product testing and so on. One particular problem is trying to identify gaps in the standards and assess their consequences, as this creates much uncertainty – for example, over the potential for service interactions. And there is always the suspicion that some vendors may be doing a bit of IMS buzzword repackaging of products.

Confusing array of specifications from many standards bodies. IMS involves a huge array of specifications from most of the major global network standards bodies, and many are at different stages of development and, hence, maturity. Further, the initial standards work was inevitably on the big, overarching architectural aspects, and it has only recently moved to the more nitty-gritty real-world deployment issues such as QOS, security, performance, reliability, and, of course, management and back-office integration. This is naturally making many carriers and others in the industry somewhat more cautious than was perhaps the case a couple of years ago.

True interoperability. Interoperability is always crucial to the widescale deployment of a new technology by operators, but for IMS it is still work in progress – inevitably, as the standards are still developing and the products are still relatively new. The issue is perhaps particularly sharp for IMS because the control and management of multimedia service sessions is inherently very complicated; there are a lot of standards involved; and some service providers have had interoperability issues on earlier, non-IMS architectures running in a much simpler service environment. And, of course, IMS will have to accommodate the existing plethora of non-IMS devices – standards work is already under way, for example, on the issues involved with delivering IMS services to a simple mobile handset.

There may be alternatives. As already pointed out, IMS is not the only way of delivering IP-based services. Some operators may feel they could manage without IMS, at least until there is longer-term experience available.

Business cases. Following on from the possibilities of alternatives to going down the IMS route, operators these days need strong business cases for big investments like IMS. Given that the whole future of multimedia services is still anyone’s guess, and is massively influenced by regulation, competition, and global economics, it is not surprising that IMS business cases are not always easy to make. And, as pointed out already, IMS can be implemented in a piecemeal fashion, so the extent and phasing of its introduction create further variables.

Next Page: Current IMS Standards

There is still a huge amount of ongoing activity in IMS standards and related matters, such as establishing standards profiles and ensuring interoperability. Much of the core standards work is about filling the gaps to make IMS implementable in real-world networks (for example, to provide interoperator security) and to extend the functionality to cover a wider set of services and capabilities of high interest to operators (for example, real-time video services). And it is also important that IMS should embrace some of the newer wireless technologies around fixed/mobile convergence, such as the use of femtocells, as with UMA/GAN.

Core Standards

Key players in IMS standards remain the 3rd Generation Partnership Project (3GPP) and its CDMA equivalent, 3rd Generation Partnership Project 2 (3GPP2) , which has based its CDMA2000 MMD architecture on IMS, the International Telecommunication Union (ITU) , the European Telecommunications Standards Institute (ETSI) , and the Internet Engineering Task Force (IETF) .

A major organizational step occurred in June 2007, when ETSI Tispan formally began the migration of its fixed IMS requirements to 3GPP, where a Common IMS will be developed. The idea is to prevent fragmentation between the fixed and mobile IMS standards, and to save time, effort, and money. The aim is to make Common IMS developments part of 3GPP Release 8, which is scheduled to be functionally frozen for its Stage 1 service requirements by the end of 2007.

3GPP, which initiated IMS and plays a very large role in its development, works through a series of Releases, which themselves go through a long series of editions. Release 7 is now frozen except for essential corrections, and, together with the earlier Release 6 (noted in our original IMS Guide), forms the basis on which the industry currently works. Work is already in progress on Release 8.

Generally, each Release adds further features and capabilities, and addresses some of the gaps identified in previous Releases. For example, Release 6 addressed features such as conferencing, messaging, and presence. Release 7 added such items as:

Much of this development has focused on fleshing out the basic call control model, fixing some inadequacies of the earlier Releases, and improving basic and IN call handling.

“Release 7, from a protocol point of view, was dedicated to IMS enhancements based on the extensions developed in the IETF,” says Eric Bezille, Product Marketing Prime for IMS, Nortel. "Additionally, IMS has evolved significantly since Release 5. In Release 6, the core IMS was enhanced and also corrected. Additionally, features such as conferencing, messaging, and presence were included. In Release 7, further features were added, including combinational services over IMS and CS, VCC, emergency calls using IMS, and supplementary services. On top of this, in Release 7, the requirements for fixed broadband access via Tispan and CableLabs were also added. Release 8 continues to further evolve IMS due to IETF enhancements and further CableLabs requirements.”

Release 8 is also adding the capability for IMS centralized services to allow the delivery of enhanced telephony by controlling legacy mobiles from the IMS core.

“This will dramatically improve the justification for IMS deployment as a truly ‘converged core’ – unlike the current proposition of an overlay service network,” says Shubh Agarwal, Director of Marketing, Mavenir Systems.

As a further example of the improvements, IMS now allows a subscriber to maintain a single public identity associated with many different pieces of equipment (such as a notebook PC) or different handsets. VCC, which deals with call handover between the access domain and the IMS core, is particularly important in a 3G and looming 4G mobile world.

“VCC is gaining a great deal of importance because of technologies like UMA and femtocells,” says Todd Mersch, Product Marketing Manager, Continuous Computing. “Carriers are faced with the huge challenge of indoor coverage – hence the activity going on around femtocells and UMA. They need to bring this traffic into IMS core and be able to hand it off as the consumer moves in and out of a hotspot. These are the kinds of applications we see supported by IMS.”

However, as Sagi Subocki, Product Manager, Radvision Technology Business Unit, points out, such an intense ongoing evolution has a cost:

“As the standard is evolving and deployed, previous standard-based solutions are being modified – and this is not always done in a backward-compatible way. For example, signaling compression. The core IMS elements, such as x-CSCFs, media gateways, and controllers, are reasonably solid, even though they do support different Releases. Other areas of the IMS network, such as application servers, are in a more evolutionary stage. Because IMS standards are evolving, when announcing IMS products as ready, compatible, or certified, it is important that the product should be interoperable and future proof. The key to deploying IMS solutions while IMS standards are still evolving is interoperability. Interoperability is achieved through testing in public forums, such as the IMS Forum Plugfest, IMTC, ETSI, and in real-time interoperability tests on service providers’ premises.”

ETSI Tispan also works through Releases, and has concentrated its IMS work on fixed networks and core service convergence for voice, video, and data. Release 1 is frozen, and Release 2 is expected to be working-group approved by the end of 2007 (all Stages 1, 2, and 3). As noted above, work is already being migrated to 3GPP Common IMS, and this will continue as a phased approach. Key features of Release 2 include enterprise services, ISDN support for IMS-based PSTN emulation, IPTV, and extensions for RACS.

As always, the IETF provides the main source for all the IP-related standards development that is ultimately bundled into IMS, such as for SIP.

Cast of Thousands

A lot of people beyond the earlier 3GPP/IETF/ETSI/ITU core have got into the IMS/IMS-related standards arena and other standards-related activities, particularly in the highly practical business of defining standards profiles and ensuring interoperability. However, all this activity can give the misleading impression that there are a lot of fundamentally different versions of IMS appearing. In practice, these initiatives are usually effectively rubber-stamping the core 3GPP IMS standard, and looking instead at what its implementation means in particular practical access environments (such as cable), and so on.

Such initiatives include:

Advances to IMS (A-IMS): A-IMS is a slightly mysterious initiative launched in July 2006 by Verizon Communications Inc. (NYSE: VZ) with the support of a group of vendors -- Cisco Systems Inc. (Nasdaq: CSCO), Lucent Technologies, Motorola Inc. (NYSE: MOT), Nortel, and Qualcomm Inc. (Nasdaq: QCOM). The basic aim seems to be to develop enhancements to IMS to address issues thrown up by real-world IMS deployments in mobile works.

In the launch announcement, Dick Lynch, Executive Vice President and Chief Technical Officer at Verizon Wireless, stated, “We applaud the visionaries who have done a great job developing IMS over the last few years. But as we approached implementation planning, it became apparent that there are some practical, real-world issues that need to be addressed if we are to transparently and completely deploy and maximize the use of this new architecture.”

However, Verizon and its supporting vendors are reluctant to comment further publicly, and, after the initial fuss of the announcement, matters have gone very quiet. The general feeling within the wider industry seems to be that this is really a Verizon implementation issue, that it may not signal a substantial fragmentation in the IMS standards, and that 3GPP and 3GPP2 are well aware of Verizon’s concerns and may be able to accommodate them in the usual standards process anyway. Many of the issues hardly appear to be new – for example, a lack of interconnection between SIP and non-SIP-based services, and a need for robust security, QOS, and charging mechanisms.

CableLabs: CableLabs has based its PacketCable 2.0 architecture and specifications (now complete) on IMS, and has migrated some of its requirements into 3GPP Release 7. Further CableLabs requirements are being handled in Release 8. PacketCable 2.0 is intended to extend cable IP services beyond today’s VOIP to embrace wireless, fixed/mobile convergence, business communications, video communications, and other cross-platform features. PacketCable is also integrating TLS with IPSec – a unique requirement. A series of interoperability tests has just started.

GSM Association: The mobile operators’ GSM Association (GSMA) is running a program of SIP trials to ensure advanced SIP/IMS services function across networks, terminals, platforms, and national boundaries. Video Share is the most recent service for which such interoperability has been demonstrated.

MultiService Forum (MSF): The MultiService Forum is an industry body whose goal is “to promote multivendor interoperability as part of a drive to accelerate the deployment of next generation networks.” It does this by “developing Implementation Agreements, Product Specifications or Architectural Frameworks, which can be used by developers and network operators to ensure interoperability between components from different vendors.”

Part of this involves producing a Reference Architecture, now on Release 3.0, issued in mid-2006, and which is closely tied to IMS. The MSF is running an NGN certification and interoperability program.

IMS Forum: The IMS Forum is the inevitable industry association for promoting IMS applications generally and for their interoperability. It organizes the series of IMS Plugfest events for IMS services interoperability verification and certification, and, among other activities, is developing a certification program for IMS interfaces, including pre-certification in qualified labs. Table 3 gives some details of recent Plugfest activities.

Table 3: Recent IMS Plugfest Roadmap

Open Mobile Alliance (OMA): The Open Mobile Alliance (OMA) is the main standardization body for mobile service enablers in the NGN environment. It has an extensive program of service enablers (for example, charging, client provisioning, digital rights management, email notification, and so on – there are about 50 of them) that provide architectures and interfaces that are independent of the underlying wireless networks and platforms and are intended “to work across devices, service providers, operators, networks, and geographies.” There is also a program of interoperability testing.

One current focus of development is Push-to-X (more formally OMA POC v2.0), which is the IMS-based multimedia evolution of today’s Push-to-Talk for cellular networks (POC). IMS itself is included as IMS in OMA Enabler Release v1.0, which contains general requirements and guidelines but does “not specify detailed requirements that should be tested or that by themselves can be implemented in products.”

SIP Forum: Another industry body, the SIP Forum concentrates on SIP and related matters. It runs an ongoing program of "SIPit" interoperability tests.

Next Page: The IMS Architecture Now

IMS still acts as described in the basic overview of the functional components of 3GGP Releases 5 and 6 in our original IMS Guide. However, the subsequent Release 7 has added further aspects, and the ETSI Tispan Release 1 has also extended the architecture by embedding it into the wider carrier domain. Readers may like to refer to an earlier Light Reading report, Tispan: IMS Plus, where its Figures 3, 4, and 5 give a high-level overview of the basic 3GPP IMS and ETSI Tispan architectures and functional components.

Figure 1 shows a simplified view, omitting various functions and interfaces, of how the resulting expanded IMS architecture looks, indicating which body initially defined the functional components.

IMS does not specify how these (and other) components are to be implemented or combined into real products, but vendors tend to talk in terms of natural product categories, and Figure 2 shows one scheme for this.

For comparison, Figure 3 shows the MSF Release 3.0 architecture and its close similarity to 3GPP Release 7.

Compared to the earlier description of Releases 5 and 6 given in the IMS Guide, Figures 1 and 2 note some additional 3GPP charging components and various components from Tispan, as follows...

Charging: Charging in IMS can be offline or online. Offline charging merely collects real-time network usage data for later processing for postpaid services, while online charging provides real-time validation and charging for prepaid services.

Charging introduces a number of functional components into IMS:

Border Gateway components: As might be expected from Tispan’s broad carrier-network perspective, Release 1 adds a lot of border devices to allow IMS to work with a wide range of access-network types, such as the PSTN and WiMax. These border devices are represented by the following functional components:

In addition, Tispan introduces two important functional blocks around IMS – the NASS and the RACS.

Network Attachment Subsystem (NASS): This provides registration at access level and initialization of user equipment (UE) for access to Tispan NGN services. So NASS handles network-level identification and authentication, manages the IP address space of the access network, and authenticates access sessions. NASS also announces the contact point of the Tispan NGN service/applications subsystems to the UE. Network attachment via NASS is based on implicit or explicit user identity and authentication credentials stored in the NASS.

Resource and Admission Control Subsystem (RACS): This provides applications with a mechanism to request and reserve resources from the access and aggregation networks. To achieve this, real-time multimedia services (such as VOIP, videoconferencing, VOD, and online gaming) must be able to trigger the QOS resource reservation, admission-control, and policy-control capabilities of the network. RACS allows an operator to enforce admission control and set the respective bearer service policies, and thus allows value-added services to obtain the network resources that are needed to offer end-user services. RACS is session-aware but service-agnostic.

The Light Reading Report, Tispan: IMS Plus, gives more details of Tispan Release 1.

IMS in Operation

The huge number of functional components, with their uncouth acronyms, makes it very easy to lose sight of what is supposed to be happening within an IMS network. So here is an extremely brief and simplified summary of what is often called Core IMS – a minimal capability on which carriers and service providers can build a working IMS network.

Session control is the key point of what IMS does. IMS is a session-control architecture, not a service architecture. So the absolutely core component is the CSCF. This registers IMS UE to the network and handles the SIP signaling when the user makes or receives a call or participates in a multimedia session. The SIP signaling eventually involves the appropriate application server (for example, for VOIP) or non-IMS network (in which case a signaling gateway or interworking device will be used, and various media gateways will have to be activated to handle the media streams between the IMS and non-IMS networks).

It is important to appreciate that session routing is different from basic call routing, as it is concerned with finding and establishing routes to the appropriate application servers. Figure 4 puts SIP into context in terms of OSI and other common protocols.

IMS divides the CSCF into three sub-types to handle the three main and fundamentally different tasks of routing SIP request and response messages from the UE; of querying the HSS (below); and of user registration and end-to-end session control.

To control calls and sessions in a converged multimedia environment, the CSCF, as well as the AS, has to know a lot about the people making and receiving them – where they are, for example. So the second core IMS component is the HSS, which provides a central database, which stores each subscriber’s service preferences and information – for example, the current IP address that is registered to the user, current roaming information, and call-forwarding information. But the list is potentially almost endless, as services become more complex and preferences and options grow.

Three more components – the MRCF, MGCF, and BGCF – allow the core IMS to work with the outside world by managing sessions across multiple media gateways and media servers of various types, and of breaking out into other networks, such as the PSTN or peer IMS networks.

Once a carrier or service provider has such a core IMS, in principle it can be extended by adding the necessary application servers, charging servers, and so on. IMS now introduces many different types of standardized AS to perform specific functions. For example:

Next Page: IMS Technology: Progress & Issues

A technology as complex and ambitious as IMS inevitably requires a huge amount of standards work that has to progress on many fronts and gradually reach down into all the detail needed for a robust and implementable system. A lot has been achieved in key areas, but there are still important holes to be filled.

SIP and Diameter

SIP and Diameter are two of the key IMS protocols, as they handle the fundamental requirements for controlling both sessions (SIP) and user access to sessions (Diameter). Both are IETF creations, and this body continues to develop them. Diameter is essentially an enhanced replacement for the well-known Radius Authentication, Authorization and Accounting (AAA) protocol [ed. note: and the diameter is twice the radius, ho! ho!], but it plays a big role in policy control as well. 3GPP Releases 6, 7, and 8 continue to enhance SIP by adopting various SIP extensions developed by the IETF.

IMS puts a huge requirement on SIP, as SIP is the key signaling protocol that is preferred for setting up calls and other services supported by IMS, such as messaging, presence, and so on. Further, session management for anything beyond simple voice calls can involve a lot of complicated routing tasks, as the call and session routing can be driven by the subscriber’s service profile, various business and policy requirements (such as time of day and least-cost routing), the needs of the applications and user devices involved, and dynamic network events (such as equipment failures or congestion).

In consequence, IMS envisages SIP being used very widely by many different network elements. This has meant that SIP has needed a lot of development and extension from its high-bandwidth, pure IP-world beginnings to enable it to cope with the very heterogeneous, multiprotocol, and legacy world of the fixed and mobile PSTN and its telecom operators. And this world is still evolving as various flavors of 3G and 4G mobile, for example, are added to the mix.

The use of SIP in the core network provides operators with the opportunity to see how SIP scales and performs in large-scale network deployments – and not just in the lab, according to Steve French, Senior Manager, Product Marketing, Tekelec:

“As operators deploy SIP, they are starting to run into some issues. SIP was not made to be deployed in the core of the network. For example, what are the recovery mechanisms if you have a failure with a CSCF in the network? What about SIP compression? What if you have overload conditions in the control plane? How are these going to be handled with SIP?”

Such issues have presented a fairly complex series of challenges for SIP development to adapt the protocol to what is needed in a real IMS environment. They fall into three main areas:

These challenges are being (or have been) addressed in the standards work. For example:

Some of these standards developments are fairly mature (for example, authentication, NAT and firewall traversal, and SIGCOMP). However, commercial availability and deployment can be more spotty – SIGCOMP, for example, seems so far to have seen very little deployment.

Nevertheless, putting all this together with corresponding applications enhancements in network entities such as SBCs is not trivial. The SBC, for example, may be interworking between different SIP variants, between SIP and legacy protocols, and between IMS and non-IMS variants of SIP – as well as providing an IMS reference point for billing and policy enforcement.

In a different direction, further developments in SIP are needed – and are being made – to support more advanced applications, such as presence services.

SCIM

The SCIM function still suffers from being fairly hazily defined within the standards, as noted in our earlier IMS Guide. This is unfortunate, as it is going to perform a key role in service orchestration and managing integration between legacy applications and services. The SCIM is envisaged as a standalone control element between the application servers and the CSCF, although complicating the issue is that some SCIM-type functionality appears within application servers and, at a very low level (for example, in service sequencing) within the CSCF. So it looks likely that compatibility problems could emerge in this area until something is finally standardized, as vendors do have established SCIM-like products.

From an architectural perspective, it does not make sense to have multiple, logically separate modules playing similar roles in the network. It adds unnecessary interfaces among these elements, which adds the overhead of interoperability and general confusion over the responsibility of each element. So the SCIM is tending to emerge as a specialized application service or a feature of the AS itself – for example, AppTrigger’s Ignite ASC.

A difficulty with standardizing the IMS SCIM is that it was conceived originally purely for use within an IMS network, which is totally unrealistic for most operators, and so has to be extended to non-IMS services, which adds more complexity.

In an interesting twist, it seems as if some operators are interested in deploying SCIM-like functionality in their intelligent networks, to mix existing services such as prepaid, corrective dialing, ringback tones, and so on. This capability allows operators to reuse existing service control points (SCPs) to provide richer, blended services to their customers. This objective is in line with what IMS SCIM is intended to do.

Security

Much of the security built into IMS so far is pretty basic and is in an early stage. One additional problem that IMS has had to solve for fixed (not mobile) networks is the use of non-SIM-based handsets, as this makes fixed networks inherently less secure than mobile ones. It also introduces another, very practical issue, in that IMS assumes that every end user has the ability to register with the network – as intelligent SIM-based handsets can do.

“Of course, a good number of our customers, particularly business customers behind existing PBXs, as well as a good majority of our consumers, do not have that kind of capability,” says Siroos Afshar, Assistant Vice President, Services Core and Premises Architecture, AT&T. ”Nevertheless, since we would like to drive everybody from the same application servers and service logic, we have to have a solution that allows non-registering endpoints to be supported inside our network that is based on IMS. So we have produced some proposals for that particular case, as well as a lot of other things."

At an even more basic level, 3GGP Release 5 did not specifically consider interoperator security in the core IP network – by default this was assumed to be an IPv6 network in which all parties trusted each other and were prepared to share customer data, and so on. This is clearly not going to happen in real deployments, especially in the fixed-network world.

Insecurity can rear its ugly head all over IMS – in service logic, for example. One obvious way of encouraging and simplifying the development of IMS applications by third parties is by using scripting languages, but there are some concerns that this could make things too easy for amateur hackers or disaffected employees. And security can also become intertwined with commercial awkwardness, as vendors may well refuse to open the APIs of the ASs, for example, to third parties.

Charging and Policy

The basic IMS standards charging structure is now settled for 3GPP Release 7 (barring last-minute errors or problems). This is an important step, as real services cannot be delivered without a means for charging for them, even though the delivery mechanism itself is available.

The policy side, however, is another matter – 60 percent complete is the current official estimate. This should not be too surprising, as policy is a big topic, and a difficult one whose ramifications have grown. What started off as essentially making decisions on bandwidth delivery and QOS now embraces many more parameters.

“It is a lot more than QOS,” says Joe Hogan, CTO and Founder of Openet. ”There are policies for roaming inbound, policies on roamers, location policies, presence policies, and filtering policies. For example, you may subscribe to have certain types of content removed automatically for a fee per month. Alternatively, you may not want a particular content-type delivery when you’re roaming in another country or when you have set your presence indicator on your phone to indicate that you’re in a meeting.”

The application of so many different types of policy can become extremely complicated, particularly if a user is roaming from one operator’s network to another. For example: What is the policy for advertisements? Does the roaming user want to receive any? To have content filtered? To be brought to the visited network portal or to the user’s usual home portal?

The IMS Policy Charging Rules Function (PCRF) is the key element that is supposed to pull the policy and online-charging functions together and handle such issues. However, with the slow progress of IMS policy standardization, there is a risk that operators will implement separate systems to bridge the gap. So there could be one handling basic policy decisions, another that deals with traffic filtering, and another that decides on bandwidth. The result would begin to resemble the vertical service stovepipes that IMS is supposed to help eliminate.

Performance

IMS introduces a lot of processing into service delivery, both on-server and between servers. Fast, low-latency performance is therefore crucial. It is notable that some early trials of POC using other architectures and approaches ran into latency problems, thereby somewhat negating the whole point of walkie-talkie-type communications: near-instant access to a group of colleagues. However, modern IMS SIP application servers appear to have eliminated this problem.

Charging and policy will introduce huge performance requirements into IMS, too, typically on the order of thousands of charging events per second. Openet, for example, points to the experience of working with existing deep-packet inspection devices in non-IMS networks, where they have to identify the subscriber, the service, the relevant payment plan (postpaid or prepaid), the balance if prepaid, spending-limits control, and content control. In one North American operator, 3.9 billion events a day go through this system, at around 36,000 events per second.

“So the decision-making latency has to be pretty small, and that boils down to an interface from one of the blades being able to receive and turn around answers at 2,000 to 3,000 events per second, with a latency that is in the 5ms to 10ms range," says Openet's Hogan. “And that client is telling us that they are going to be doing 10 billion events per day in two years time from their network. So you need to integrate these platforms closely together. That’s the real challenge, which only few software platforms are designed to meet.”

Indeed, when it comes to full-blown IMS in Tier-1-sized networks, the jury still seems to be out on just how well they will perform. Says AT&T’s Afshar, “What is not yet proven, by anybody, is the loading of an IMS-based network with the kind of traffic we anticipate – millions of users and each user taking on multiple personalities and using multiple devices, and then actuating the existing traffic of PSTN. That is a huge load, and none of the existing equipment has been tested even within two orders of magnitude of that load level.”

Further, he points out that IMS doesn’t support zoning, which is one method for easing the handling of high loads by partitioning the network into separate zones, each handling a smaller load. Instead, the IMS architecture is flat, with a single HSS, for example, supporting the entire network. AT&T is thus thinking of introducing zoning into its implementation of IMS to allow partitioning of the network, both for response to disasters, as well as for closer control over traffic management.

Naturally, vendors are putting a lot of effort into addressing the performance and latency requirements of IMS. BEA Systems, for example, combines the BEA real-time Java Virtual Machine (JVM), called BEA JRockit, and the dual-tiered deployment architecture of its converged Java EE-SIP-IMS application server, BEA WebLogic SIP Server. The engine tier of BEA WebLogic SIP Server executes the SIP Servlet (JSR 116/289)-based IMS application logic, and is tuned for throughput to optimize SIP message processing. The state tier stores the session data, is managed and clustered separately, and is deployed in geographically redundant fashion. This means that multiple data centers throughout a given country host the same synchronized session state, thereby eliminating a single point of failure.

On the hardware side, high-performance and highly scaleable ATCA-based packet-processing blades are emerging as a key approach to handling IMS in hardware. Also, as Continuous Computing points out, on ATCA there is a prevalence of multicore processor blades, which means that the software needs to be enhanced to take advantage of this – through multi-threading the software so that it can parallelize processor-intensive tasks and spread them across the multiple cores or threads being provided by the silicon. The company has thus developed a scaleable multi-threading architecture for its IMS protocol software.

Operations

Related to the questions of performance are some aspects of operations. For example, the HSS is crucial to the entire IMS enterprise, but is likely to prove more awkward to handle than operators might like – at least until the technology matures.

“Operationalization of the capability is still very weak,” says David Jacobs, CTO at JacobsRimell. “Interfaces for populating the HSS are still proprietary and look like they will continue to be so for the foreseeable future. The HSS Sh and Cx interfaces are seen to be weak when trying to perform bulk reads and writes, resulting in the need for caching/copying of HSS data in application servers and SDPs.”

Additionally, standards to enable access to HSS and AS data by external parties are still in their infancy. GUP has been overtaken by CSP in the latest 3GPP specifications, and although it is an improvement, there is still a lot of ambiguity, according to Jacobs.

Such concerns are of fundamental importance to the practical application of IMS, as it requires the efficient implementation of services on a mass scale to consumers and business users alike. The OSSs will have to configure the IMS core, the application servers, and the SDPs to create new services – a potentially huge task.

Non-SIP Services and OTT Alternatives

There are a lot of services – including some massively common ones, such as email, Web browsing and downloading, P2P services such as VOIP and video, and (potentially) IPTV – that do not use, or need, SIP, since they can be offered directly over the top of an IP connection. Indeed, with the rise of the Web 2.0 world and its SOA software, and associated standard protocols such as SOAP, there is a vociferous school of thought that argues that SIP-based services belong to the past.

It is not the purpose of this report to argue the merits of this case, but rather to look at how IMS might relate to these alternatives. Two points seem to stand out.

One is that IMS can add desirable capabilities to non-SIP services. Consider IPTV, where ETSI’s DVB-IP workgroups are developing standards for IMS/Tispan networks. IMS can bring bandwidth management, QOS, charging functions, lots of user profile data held in the HSS, and (when sorted out) SCIM control of interactions with other services. So, for example, a customer could see on the TV screen who is calling his mobile that has been left in the adjacent room – and choose to ignore the call because he's watching the big game over IPTV. Further, IMS helps operators create a highly functional network within which non-SIP services can operate more effectively.

“Non-SIP services don’t need to touch any of the SIP components, but they still need the network capabilities to enhance the service experience, such as presence and location,” says Manish Mangal, Director of Technology Development Planning, Sprint Nextel. “You can argue whether those are IMS capabilities or just service enablers, but IMS as an architecture allows us to put all of them in a good architectural context, and allows us to handle APIs being exposed to application developers, who may not need the SIP – but the other capabilities could be valuable to them.”

The second point is thus the need to integrate IMS and alternative approaches, perhaps ultimately through the creation of platforms where they can all be blended together so that developers can create mash-ups between Web 2.0 applications and the SIP-oriented applications.

“It is possible, but it requires a good deal of innovation,” says Vikram Saksena, Sonus Networks' CTO. “We are trying to do that, but it is still in very early stages – very early thought process. IMS has to get a foothold in the networks before we can start doing these kinds of services.”

Next Page: How IMS Is Affecting the Network & Services

Currently, the IMS network role depends very much on the type of operator and its specific circumstances and business goals. IMS is so multifaceted that it is unlikely that an operator will deploy it in only a single role – for example, as a core enabler for supporting its own or third-party enhanced multimedia services; as a way of driving down costs; or as a key method of supporting fixed/mobile convergence.

IMS can also play some highly specific roles that may prove to be particularly important. For example, the implementation of the Policy Enforcement Point (PEP) part of the Border Gateway Function (BGF) in the access node, together with the implementation of the Ra interface could be very useful. (Ra is an interface to the RACS, which is defined and explained here.) Since the access node is closest to the customers, it has full visibility into real-time service conditions, requirements, and faults. So it is a good location for policy enforcement based on real-time information, with the Ra interface being used to communicate with the other IMS elements.

“Implementing the PEP in the access node will allow network operators to introduce new, dynamic, and innovative services, business models, and maintenance procedures into their networks,” says Ron Levin, Director of Product Marketing for the Network Solutions Division of ECI.

But a picture of sorts may be emerging. Some operators may eschew IMS altogether because they see their business as essentially supplying bitpipes, over which others run the end-applications. In contrast, as Table 1 suggests, small, greenfield mobile or broadband operators may be more receptive to IMS straight from the beginning of their network rollouts.

“We see more hesitance from the larger operators and less in the greenfield or near-greenfield scenarios,” says Todd Mersch, Product Marketing Manager, Continuous Computing. “You see a lot of IMS announcements in more rural areas, where smaller operators have a less extensive existing network or have not already invested a considerable amount on a softswitch-based NGN architecture. The greenfield operators are moving quicker and having more success than in situations where you have a large operator trying integrate IMS into their more expansive legacy networks.”

For such small, greenfield deployments, IMS holds out both the promise of immediate competitive advantage from its enhanced service capabilities, and also the avoidance of legacy technologies.

The caution of some larger operators is reasonable, and accords with the commercial realities facing many of them.

“I think that it has become very much business driven, and people are now looking at IMS not simply as an architecture, but as a set of solutions, which could be deployed for very business-case-oriented reasons,” says Sonus's Vikram Saksena.

Further, large operators need more than IMS, as it is only one element, though a crucial one, of telco-type converged NGNs.Eric Bezille, Product Marketing Prime for IMS, Nortel, thus summarizes much current IMS activity by operators under three main profiles:

A risk is that, if vendors push IMS to operators without first examining their business needs, it can result in trial-grade installations that may not deliver concrete ROI, Bezille says. “The best approach to implementing IMS is through a step-by-step installation of applications that are justified business-wise. Very often it starts with a focus on applications in a pre-IMS or IMS-ready mode, and then evolves to IMS when operators decide it is the right time based on business assessment.”

IMS Migration

For a large operator, with a large legacy network, IMS migration is a major issue. Unsurprisingly, much effort is aimed at implementing IMS incrementally. The idea here is to use a two-stage process: first, to migrate, say, the PSTN to softswitches; second, to migrate from softswitches to IMS. In principle, this might be stated as: First migrate to a limited, proprietary NGN, and then migrate to a full, open IMS-based NGN. As many larger operators already have a base of softswitches, this would seem a practical approach.

“Softswitching is a good first step towards IMS. It is a much smoother evolution if you use softswitching as an intermediate stage, rather than try to take a big leap from a TDM network to an IMS network,” says Saksena. “I don’t believe anybody has successfully done that. There are too many risks and moving parts to jump from a PSTN network to a full IMS network in one step.”

As major operators have been aware of IMS developments for many years now, some have been working towards IMS-type approaches with their existing softswitches anyway – for example, Sprint Nextel.

Such phased migrations from earlier to later forms of NGN are creating opportunities for vendors to release products aimed at smoothing the transition. As wireless and wireline operators are starting to move towards using SIP in the core of their existing non-IMS NGNs, Tekelec, for example, argues that this creates the need for a centralized, access-independent device to provide an independent SIP signaling and session control framework at the core of the NGN to facilitate signaling and session management between the various NGN network elements.

Current non-IMS NGN architectures have no core signaling infrastructure, as SIP edge devices signal directly to each other, creating a virtual mesh architecture, similar to the PSTN of many years ago. This limits expansion capabilities, among other disadvantages, partly because it requires the distribution of large amounts of user data and routing decisions to network edge devices. This limitation limits the NGN to voice services only.

Such a function does, of course, exist within IMS – it’s the CSCF. Tekelec’s approach is to adapt the standard IMS CSCF protocols and procedures to work with non-IMS-compliant devices in the NGN environment. Tekelec’s product for this solution is the TekCore Session Manager, which supports SIP signaling and session management in both IMS and NGN operating environments. The idea is to adhere to 3GPP IMS CSCF definitions, but make the device adaptable to the changing environment of the NGN.

“Essentially, it is taking the concept from IMS – a standalone SIP signaling session framework – and applying it to the NGN as an incremental step. So it is much easier to prove in the business case versus having to deploy a full-blown IMS infrastructure,” says Tekelec's French. Additionally, the implementation of a bearer-independent signaling control plane enables operators to deploy multimedia services, which is a primary objective of IMS.

An issue in migration to IMS will therefore be to interwork the CSCF with existing SIP edge-signaled networks – it cannot just be dropped straight into current non-IMS NGNs. A further point is that IMS will generally involve operators in a two-sided migration, because the standing SS7-based TDM PSTN obviously has to be considered as well. Tekelec argues that its approach will also allow CSCF signaling devices to interwork with both SS7 and non-IMS SIP networks – creating a unified signaling control plane and supporting the sharing of services across multiple network domains.

Tekelec claims that operators are already testing and deploying similar solutions, and it has shipped product for this purpose – indicating that operators are using some of the concepts of IMS for current implementation in their networks, without the cost of deploying a complete IMS network.

A similar example is provided by mobile networks. Hosted PBX or Centrex service has emerged as one of the key target applications for mobile operators, according to Mavenir Systems, as it leverages its presence and sales channel into small and medium-size businesses. However, there are still issues in extending Centrex features to existing customers’ standard 2G mobiles while providing a converged service seamlessly across both mobile and broadband networks via IMS. The problem is that the obvious way of doing this is to keep the IMS and 2G networks separate and to use IMS Voice Call Continuity (VCC) and interworking gateways. However, standards are still incomplete for this, and running two networks adds to costs. Mavenir’s interim approach is thus to provide direct IMS to 2G/3G(CS) domain connection through its 2G P-CSCF device. The company says that three European mobile operators are planning to follow this approach.

What Is IMS Used For?

Talk of IMS roles and migration is all very well, but what effect does IMS have on services, which comprise one of the major motives for the whole IMS exercise?

There’s no shortage of ideas for services and applications that rest wholly or partly on IMS. Indeed, cynics might wonder how people will find any time not to be using one IMS service or another. AT&T, for example, is thinking along the following lines for its planned CARTS-based NGN (see IMS Deployment Examples):

Different types of operator will have different priorities for IMS-based services. Mobile operators are evidently interested in extending corporate-style communications such as Centrex to mobiles, and in exploiting things like video, messaging, and presence. VOIP per se is of less interest, given the existing voice capabilities and the QOS and other technical aspects as they are affected by wireless.

According to Radvision's Subocki, the main services currently deployed are Video Share, VCC (for FMC), Instant Messaging, and Presence-aware services.

“We also see a lot of V2OIMS services being introduced,” he adds. “All of the carriers are committed to IMS; some have already announced actual IMS services, others are deploying IMS services, and others are in the planning stages. We see two segments emerging in this market: service providers who require IMS vendors to comply with their IMS specifications; and those that choose a main vendor and ensure that all the other vendors are interoperable with that vendor.”

Push-to-talk-over-cellular (POC), which enables traditional walkie-talkie-type services over a cellular mobile network, is another corporate service that can be supported by IMS through a combination of presence, instant messaging, billing, single sign-on, and centralized OA&M functions.

IMS has particular appeal for POC service, as it can be rolled out by installing the appropriate application onto an AS, and then downloaded to the POC client to customers’ mobiles as they sign up for the service. However, Subocki believes that operator interest in POC has recently died down somewhat.

IMS also enables Corrective Dialing, a neat addition to the mobile operator’s repertoire in a prepaid environment. The idea is to avoid failed high-revenue calls that occur because the user is roaming internationally but forgets to add the necessary country code. The IMS SCIM both mediates the protocols and services, and handles the interactions among the prepaid service, the corrective dialing, and so on, to ensure that the call goes through as intended.

In contrast, cable operators have already built their business on residential video, and so are more motivated to look to new areas to help them challenge the telcos, especially in voice and messaging and in business services.

“The carriers, I think, are really focused on the more conventional subscriber-oriented services, in some cases as an FMC offer to bundle fixed and mobile endpoints under a single user identity,” says Sonus Networks’ Saksena.

Examples of such fixed-oriented services include Click-to-Dial, Voice Video Messaging, and Multimedia Conferencing.

Finally, and potentially very importantly, Web services can also reach into IMS (using Parlay-X), through a layer on top of the application server that interfaces between IMS services and Web services/SDPs. This is a similar approach to the SOA trend in enterprise Web 2.0 services.

“We see the Web 2.0 side as being more complementary than competing with IMS,” says Nortel’s Bezille. "With our new Web services features on our IMS application server, and through strategic partnerships with companies such as IBM, our intention is clearly to serve customers with both Web 2.0 and IMS. We believe the winning strategy is IMS plus Web 2.0 rather than one or the other."

Fly in the Ointment: Service Development

Where the IMS service and applications story gets slightly sticky is in applications development, particularly by third parties. Despite the extensive visions that some operators profess for future services and applications, and also for early current deployments, it does seem that the development of IMS standards and technologies is running considerably ahead of actual applications.

“What is missing is that there are very few applications that have been specifically built for IMS. And there certainly isn’t a wide community of applications builders,” says Openet's Hogan. “The value of IMS is not in the technologists rolling out a new core; rather it’s in the ability of operators to be able to introduce new application services, get them into production pretty easily, and, if not successful, get them out of production fast. That is the nirvana of marketing within operators, which IMS is designed to ultimately achieve.”

Part of the problem is a current lack of available software tools to allow third-party application developers to readily devise and deploy new IMS applications. Greater cooperation among operators and developers to strengthen the service development environment may be one way of filling this gap.

“As a network operator, we think we can, as we deploy IMS, expose a lot of network capabilities out to the third parties, and there are software extensions available – new Java extensions, for example – for us to do that. But how the extensions get bundled together to create a really easy development environment for the third party is an area where there is more and more work to be done,” says Manish Mangal, Director of Technology Development Planning, Sprint Nextel.

In a sense, this ties IMS to another current industry concern – service delivery platforms (SDPs). IMS can be viewed as one of the components that allows network capabilities to be exposed to the SDP, and the SDP in turn can expose the capabilities to the actual application developers.

However, carriers clearly need control over the release of IMS capabilities to third parties.

“It’s going to be a very controlled release of IMS capabilities, either straight via SIP or via Web services or via Java or whatever the ecosystem requires,” says Ken Lee, Director, Worldwide Product Marketing, BEA WebLogic Communications Platform, BEA Systems. “Our WebLogic Network Gatekeeper does that very well for SDPs today, and we see a very similar level of interest in rolling out the IMS services layer in a very controlled and managed way.”

The point of products like the BEA WebLogic Network Gatekeeper is to provide policy enforcement, SLA management, partner relationship management, and a very controlled and secure Web services interface to various IMS enablers.

Lee also points out that carriers need more customized and regional enablers to exploit IMS fully. For example, regional search engines dominate the Chinese and Korean markets, not Google.

“Then you can have a lot of custom enablers that are unique to you as an operator, so you can roll out a lot of new services rapidly and see which one sticks. And the services that do stick will attract a lot of business partners, and then can then be monetized,” he says.

Next Page: IMS Deployment Examples

Generally, the Tier 1 carriers and service providers that are implementing IMS are doing so as part of a much bigger program of next-generation network and service architecture development. However, often the first visible sign to customers of the use of IMS is through the appearance of a new service that the provider sees as fulfilling a key strategic or competitive requirement. Similarly, smaller providers that deploy IMS often do so to obtain an immediate service advantage in a specific area.

So the result in both cases tends to be the emergence of a small group of initial key or no-brainer services that are fairly obvious: residential and business voice fixed/mobile convergence, IP Centrex, and so on. But many of the bigger carriers are doing much more work under the surface, and this will greatly affect their service offerings in future.

This page looks at a few examples of IMS deployments from both aspects to give a flavor of what carriers and service providers of various types are doing – or hope to do – with IMS.

Initial Key Services

A growing number of operators of different types worldwide are offering at least a few key services based on IMS, even if this is done initially in some cases with a fairly minimal configuration of an IMS core and a few application servers. Table 2 lists many examples, and this section gives some more details on a few of them.

Far EasTone Telecommunications Co. Ltd. claims to be the first Taiwanese operator to offer services that use IMS. The mobile operator has deployed IMS and HSPA to support voice FMC, and in August 2007 launched a voice service using VOIP over WiFi over HSPA via a fixed wireless terminal. Customers can use a WiFi phone, PC client, and mobile phone on a single number, and it is also possible to access the service via public WiFi hotspots. A strategic rationale for the service is to target its existing mobile customers who take their broadband service from other providers.

Service features include personalized ringtones and intelligent voice mail, which provides different answering messages depending on the status of the phone, such as “no answer,” “busy,” or “turned off.”

The Danish incumbent, TDC A/S (Copenhagen: TDC), is using IMS to support IP Centrex services targeted at SMEs as a replacement for PBXs, which TDC no longer supplies. The customer buys a basic package and can then customize the solution via a Website.

Telefónica SA (NYSE: TEF) says it has been running commercial service traffic in Spain with IMS since mid-2005 as part of its strategy to offer IP-based multimedia services. Services include residential telephony, teleworking services, and enterprise voice services, such as IP Centrex. New services are to be added; a video call service was launched in June 2007, allowing video calls between fixed videophones, 3G mobile phones, and TVs (via a set-top box).

Building the Bigger Picture

For a major operator, such as a large incumbent, IMS is likely to be only a part of a much larger network and service restructuring for an IP-oriented world.

AT&T provides a good example of IMS’s role in such a transformation in a U.S. context, illustrating the need of this type of provider for something that provides IMS-type functionality. Years ago, the company decided that it needed to integrate and consolidate all of its networks into a single global MPLS-enabled IP network. In turn, this meant creating a layer on top of that IP/MPLS network to support both existing and future services of all types – voice, video, and data.

AT&T concluded that there was then no currently available architecture for a carrier of its size that could handle the services that it was then offering and was also planning to offer. So the company started a program to design an architecture for that layer, which it called Real-Time Services Over IP (RSOIP). But the subsequent arrival of IMS standards and their extension from mobile to fixed networks persuaded AT&T to modify RSOIP and adopt IMS into it. (See AT&T Defines Service Creation Platform.)

“We realized that IMS can meet almost – not all – of our requirements as we have defined them in RSOIP. It also had the advantage of almost universal acceptance from the vendor community; and being ‘standard’ had a lot of advantages for us. So last year we decided to change that architecture [RSOIP] and incorporate IMS conventions and interfaces,” says AT&T's Siroos Afshar. “That architecture, which we call CARTS now, embraces a lot more than just IMS. IMS is a part of that architecture – to be specific, it provides the way we manage the sessions.”

Figure 5 shows how CARTS (Common Architecture for Real-Time Services, now approaching Version 2) fits within AT&T’s layered network and services approach, and the role that IMS plays within CARTS. An important aspect of the CARTS architecture is that it treats all existing networks and accesses – such as TDM, PSTN, GSM, cable, WiFi, and DSL – purely as access technologies to CARTS itself, never as peer networks. This means that, for any service, the corresponding service logic resides on top of the CARTS infrastructure.

A crucial non-IMS piece of CARTS is the Service Execution Runtime Functionality (SERF), which contains and runs the service logic, providing such capabilities as service bundling and allowing external service logic to drive the network through an external application gateway

“It provides a lot of what we call 'enablers' that are common functions that are not by themselves services, but can, and in most cases will, be used by various service logics – like location management and preference management,” says Afshar. “These are all parts of the architecture, but they are not part of IMS. IMS deals with the session – how to manage sessions, how to set up session legs, and connect them and drop them, and so on.”

In addition to using a single converged MPLS/IP network and being access-network agnostic, CARTS is to have the following characteristics:

The CARTS roadmap envisages the following rollout:

“This is a huge project, and it is going to take time, but there is a decision and determination at all levels of AT&T to build this as soon as possible,” says Afshar. “The major problem is not building new services and some of the existing services on CARTS. That is not as complicated as how to get off the PSTN TDM, because there are lots of implications in terms of going off the PSTN and into CARTS. But we have a taskforce focused on that, and activities going on with the objective of doing it as soon as possible.”

BT is also using IMS-enabled services as part of a massive current migration of its entire U.K. network to a converged IP-based NGN in its 21st Century Network (21CN) program. This went live in a limited pilot area of the U.K. (in South Wales) in November 2006, and is scheduled to be completely rolled out across the Kingdom by 2010. Among other things, the 21CN will involve delivering the standing PSTN service via call servers and a converged multiservice access, as illustrated in Figure 6. IMS will provide a crucial block in this architecture.

The initial service focus will be:

BT sees a positive business case for IMS from the cost reductions that it will generate in terms of platform consolidation, reductions in operational expenditures and training costs, and so forth. The customer experience should be improved (for example, through convergent and blended services and QOS management); and, of course, both the company and customers should gain from the potential for new services and their faster time to market.

IMS, however, is only part of a much bigger scheme that BT envisages for 21CN, embracing support for a universal SDP that integrates both telco-type services/applications and Web 2.0 approaches. IMS would form part of the basic functional enablers, but above it would be a layer of larger "reusable capabilities," such as home environment, authentication, customer profile and preferences, application-driven QOS, session control, presence, instant messaging, directories, and the like. In turn, above this, would be a layer of BT service components that would be potentially reusable for all customer segments and would include an end-to-end series of high-level components:

Above this would be a layer of BT services based on these components. Finally, above the BT services layer and using published BT APIs, would be a layer of third-party and end-user applications and services created as mash-ups. BT describes this approach as Web21C Service Execution.

Essentially, the architecture is based on IMS, but is extended with SOA and reusable capabilities. Service execution will deliver consumer, SME, major corporate solutions, and wholesale carrier-to-carrier interconnect. 21CN and Web21C are an open architecture, intended to work with industry and developers.

Natural Evolution

Sprint Nextel is currently using IMS as an enabler for converged voice and data services. The first IMS application, dubbed WirelessIntegration and launched in late 2006, is for enterprise voice FMC to provide an extension of PBX functionality to mobile phones. The service is aimed at medium-to-large businesses and supports features such as:

The company’s approach to IMS might be conveniently termed natural evolution, as opposed to the huge architectural shift envisaged by AT&T.

“Our network today is performing very well in the context of an intelligently designed SIP softswitching and service orchestration environment,” says Michael Logan, Group Manager for IP Network Core Development at Sprint Nextel. “I almost view it as an evolution from our original softswitches. We had an eye towards where IMS was going, so our initial network deployment was a form of pre-IMS and was friendly to the IMS idea.”

Thus the ongoing evolution of the network from the circuit to the packet environment and eventually IMS has been through an evolution of softswitches. Once the basic softswitch architecture was installed, Sprint Nextel added new capabilities – such as CSCFs and app servers – which were increasingly IMS-compliant as the standards and products developed, with the goal of reaching a full-blown IMS architecture eventually.

According to Logan, the main challenge of this approach lies more in network operations and back-office functions than in the network/service architecture per se.

“I haven’t seen it as so much of a disruptive change, although I think there are disruptive concepts baked into it,” he says. “If anything, it is just the transition of our ops teams and our back office. It is an organizational transition as much as anything – and we have been doing that for some time. I think that, for anyone entertaining this from the ground up, there is quite a learning curve, but it can be traversed.”

IMS and Fixed/Mobile Convergence

As Table 1 and some of the preceding examples show, FMC is an obvious application of IMS, and the technology was always intended to support it. Indeed, some see FMC as being crucial to IMS. However, IMS is not the only way of supporting FMC – and, anyway, FMC is itself a somewhat vague term. It makes a big difference whether it refers to all services being offered seamlessly over fixed or mobile networks (within certain technical limitations, of course), or whether it means only a range of key services, such as voice, email, Web, and so on. The more extensive the service set, the closer the potential fit with IMS.

Either way, the market forecasts for FMC are huge. Infonetics Research Inc. 's October 2007 forecast on FMC equipment says the worldwide FMC equipment market, including UMA network controllers, multi-access convergence gateways, and dualmode cellular/WiFi phones, will reach $46.3 billion in 2010, and the number of subscribers will have increased from 188,000 in 2006 to 38.2 million in 2010. As this forecast is restricted to voice convergence, the potential market for full multimedia convergence should be considerably larger.

But dualmode cellular/WiFi phones form the vast bulk of the FMC market, as the equipment part is tiny because it just emerging. Worldwide total dualmode cellular/WiFi phone revenues reached $15.7 billion in 2006, and they are expected by Infonetics Research to grow at a five-year CAGR of 31 percent to reach $46.1 billion by 2010.

However, many of the early voice-only FMC approaches are still more of the traditional service-silo model based on proprietary systems than the more open approach ultimately envisaged by IMS. Also, although numbers of operators are beginning to deploy Core IMS components such as the HSS and CSCF, that doesn’t necessarily mean that FMC is driving IMS adoption.

“These deployments of the HSS and CSCF are part of major network transformations. NTT DoCoMo, for example, is moving everything to IMS, but it is not fully correlated with FMC. In fact, there is no seamless FMC in Asia/Pacific at all,” says Stéphane Téral, Principal Analyst for Service Provider VOIP, IMS, and FMC at Infonetics.

But vendors believe that FMC will move inevitably in the IMS direction. Huawei Technologies Co. Ltd. , for example, launched its IMS-based FMC 3.0 solution to much fanfare late in 2006.

“FMC is probably one of the first places we will actually see the impact of IMS. What we see now in the FMC market is proprietary solutions in a lot of places, providing mainly voice call convergence. Since it is proprietary, it is not going to scale very well,” says Todd Mersch, Product Marketing Manager, Continuous Computing. “At some point, operators will need to use the core network to support increasing consumer demand; and, further, if they intend to provide multimedia FMC services, IMS can bridge the gap. Adding a new network element that just handles one service is simply not scaleable.”

Next Page: Summary: A Partial Future?

This survey cannot foretell the future of such a colossal telecom standards effort as IMS in one of the world’s largest and most dynamic industries, but it can suggest some pointers. The main ones seem to be:

Overall, it looks as if IMS will spread largely in the background, in fits and starts, as different operators make different business cases. Gradually, this process could lead to a large mass of Core IMS being implemented almost by default, from which operators and service providers could build as experience and opportunities dictate. In other words, IMS may adapt to becoming a pragmatic response to the needs of the evolving NGN, rather than being a holistic architecture applied from the top down.

As Chris King, Senior Director, Worldwide, Telecommunications Markets, BEA Systems puts it:

“The service providers are now rolling out products into deployment, where they are generating revenue by using IMS. They may not talk about it as IMS, because customers don’t buy IMS, they buy products. But the implementations are IMS, and that is where you are starting to see – probably over the last six months – a true rollout of IMS-based services. And I think that in two years from now we will be looking back and saying: 'Why did we ever doubt this?' ”

Next Page: Acronym Glossary

AAA: Authentication, Authorization & Accounting

A-BGF: Access Breakout Gateway Function

ABMF: Account Balance Maintenance Function

AS: Application Server

ATCA: Advanced Telecom Computing Architecture

BGCF: Border Gateway Control Function

BSS: Business SIP Services

CCCF: Call Connection Continuity Function

CDF: Charging Data Function

CDMA: Code Division Multiple Access

CGF: Charging Gateway Function

CS: Circuit Switched

CSCF: Call Session Control Function

CTF: Charging Trigger Function

CUG: Closed User Group

DSL: Digital Subscriber Line

FMC: Fixed/Mobile Convergence

GAN: Generic Access Network

GLMS: Group List Management System

GPRS: General Packet Radio Service

GRUU: Globally Routable User-Agent URI

GSM: Global System for Mobile communications

GUI: Graphical User Interface

HSS: Home Subscriber Server

I-BCF: Interconnect Border Control Function

I-BGF: Interconnect Border Gateway Function

I-CSCF: Interrogating Call Session Control Function

IMS: No idea

IMS-MGW: IP Multimedia Subsystem – Media Gateway Function

IN: Intelligent Network

IP: Internet Protocol

ISP: Internet Service Provider

IVR: Interactive Voice Response

IWF: Interworking Function

Java EE: Java Platform, Enterprise Edition

JVM: Java Virtual Machine

LAN: Local Area Network

MAC: Medium Access Protocol

MGCF: Media Gateway Control Function

MRFC: Multimedia Resource Function Controller

MRFP: Multimedia Resource Function Processor

MS: Mobile Station

MVNO: Mobile Virtual Network Operator

NASS: Network Attachment Subsystem

NAT: Network Address Translation

NGN: Next-Generation Network

OCF: Online Charging Function

OSS: Operations Support System

P-CSCF: Proxy Call Session Control Function

PDF: Policy Decision Function

PHG: Phil Harvey's Goat

PLMN: Public Land Mobile Network

POC: Push-to-talk Over Cellular

PS: Packet Switched

PSTN: Public Switched Telephone Network

QOS: Quality of Service

RACS: Resource and Administration Control Subsystem

RAN: Radio Access Network

RF: Rating Function

ROI: Return on Investment

SCIM: Service Capability Interaction Manager

S-CSCF: Serving Call Session Control Function

SDP: Service Delivery Platform

SGF: Signaling Gateway Function

SIM: Subscriber Identity Module

SIP: Session Initiation Protocol

SLF: Subscriber Locator Function

SLP: Subscription Locator Function

SME: Small to Medium Enterprise

SOA: Service Oriented Architecture

STUN: Simple Traversal of UDP through NAT

TAS: Telephony Application Server

TLS: Transparent LAN Service

T-MGF: Trunking Media Gateway Function

UDP: User Datagram Protocol

UE: User Equipment

UMA: Unlicensed Mobile Access

UMTS: Universal Mobile Telecommunications System

VCC: Voice Call Continuity

VOIP: Voice Over Internet Protocol

WLAN: Wireless Local Area Network