PUBLIC NETWORKS IMS 101: What You Need To Know Now John G. Waclawsky Ph.D Can the IP Multimedia Subsystem enable new services, converge wireless and wireline networks and keep service providers firmly in the driver s seat? Out of the wireless standards consortium called 3rd Generation Partnership Project (3GPP) comes a slow-growing and complicated collection of carrier network functions and processes that collectively are referred to as IMS, which stands for the IP (or Internet) Multimedia Subsystem. The IMS standards promise an operator-friendly environment for real-time, packet-based calls and services that not only will preserve traditional carrier controls over user signaling and usage-based billing, but also will generate new revenue via deep packet inspection of protocols, URI and content. IMS was conceived for the evolution of cellular telephony networks, but the benefits of user signaling and billing controls have attracted the endorsement and involvement of wireline network operators and standards makers, including the European Telecommunications Standards Institute (ETSI), the U.S.-based Alliance for Telecommunications Industry Solutions (ATIS) and the UN-sponsored International Telecommunication Union (ITU). In the U.S., cable multiple systems operators (MSOs) are also showing interest in IMS as part of the recent CableLabs PacketCable initiative, and network operators recently approached the WiMAX Forum s Network Working Group, asking that IMS be included in its forthcoming reference architecture. Meanwhile, prominent telco network equipment suppliers also are becoming big IMS boosters. Many of them including Alcatel, Ericsson, Lucent, NEC, Nokia, Nortel and Siemens already have well-defined IMS strategies and will soon announce commercial IMS products. FIGURE 1 Very High Level View Of A 3G System Network and Systems Manaagement Operations and Control IMS Core Walled Garden Applications John G. Waclawsky, Ph.D., is Senior Technical Staff, Mobile Wireless Group, Cisco Systems. He can be reached via email at jgw@cisco.com or by phone at 301/662-0703 18 BUSINESS COMMUNICATIONS REVIEW / JUNE 2005 SIP control plane Media and Signaling conversion Billing and Back Office Functions Use BCR s Acronym Directory at www.bcr.com/bcrmag
FIGURE 2 Simplified IMS Reference Architecture Applications and Services 2G Mobile Networks Cx I-CSCF Cx S-CSCF Mm Roaming Gateway Mw P-CSCF Mr Mg Mi HSS CSCF Gc (PDF) Go Gm Mobile Terminal SIP IP Networks SIP PSTN Gateway PSTN RAN SGSN Notes: Signaling and Data Transfer Interface Signaling Interface Cx, Gc, Mi, Mw, Go, etc. = Reference Points PDF = Policy Decision Function HSS = Home Subscriber Server RAN = Radio Access Network GGSN SGSN = Serving GPRS Signaling Node GGSN = Gateway GPRS Support Node CSCF = Call Session Control Function I-CSCF = Interrogating CSCF P-CSCF = Proxy CSCF S-CSCF = Serving CSCF Legacy Networks Source: Cisco Systems The attention being focused on IMS can confuse people outside the 3GPP environment, especially if they think that IMS is a complete system for converged, multimedia networking. It s not; in fact, IMS is only a part of such a system, as defined by 3GPP and shown in Figure 1. The entire 3G system can be briefly summarized in five pieces: 1. The IMS, or SIP/SDP control plane, at the core. 2. The media and signal conversion layer wrapped around the core. 3. The embedded walled garden, defined by the applications or services the operator offers to its subscribers and the limits it also sets on their behavior and signaling. 4. The billing and back office function layer. 5. An array of network, systems management and operations tools. With this high-level view in mind, we can take a closer look at how IMS works and its history, which should give us a clearer idea of how it is expected to deliver the converged, multimedia future its proponents are talking about. IMS Basic Architecture As an architecture, IMS decomposes current and future networking devices into a plethora of functions, joined to one another conceptually by reference points. Some of these functions have been specified, while others are still under development for one of 3GPP s numbered UMTS Releases. The use of reference points, rather than interfaces, is typical in the telco world. Reference points describe all the traffic between two resources, including multiple protocols for the different types of traffic. IMS reference points not only specify how to interact with a resource but also which endpoints are allowed to interact with a specific resource. In contrast, the interface specifications common outside the telco world specify how any endpoint is allowed to interact with a given BUSINESS COMMUNICATIONS REVIEW / JUNE 2005 19
IMS functions signal and track usage, but IMS doesn t provide features or services resource. Reference points provide more tightly controlled and restrictive specifications. Because IMS is still being defined, and because there are so many function and reference points, it is hard to depict a complete IMS system. IMS reference architecture diagrams quickly become very confusing if they attempt to show more than a few functions and reference points. The most likely deployment scenario will be for equipment vendors to bundle multiple functions into various gateways and servers, as shown in Figure 2. Notice the central position occupied by the Call Session Control Function (CSCF), and its further decomposition into Interrogating, Serving and Proxy Session Control Functions. In IMS, every user signaling event be it feature activation, call session initiation, resource allocation, or requests for any other application or service first stops at the P-CSCF, which is the user device s first contact point within the IMS core network. As shown in the figure, the P-CSCF forwards SIP messages received from the User Equipment to the Interrogating Call Session Control Function (I-CSCF) and/or the Serving Call Session Control Function (S-CSCF), depending on the type of message and procedure. The I-CSCF provides a contact point within an operator s network allowing subscribers of that network operator, and roaming subscribers, to register. Once registered, the S-CSCF maintains session state for all IMS services. The I-CSCF normally acts as a SIP proxy, but its main purpose in IMS is to provide a service locator function. There may be multiple I-CSCFs within an operator's network, performing the following major functions: Registration: Assigning a S-CSCF to a user performing SIP registration Session Flows: Routing a SIP request received from another network to the S-CSCF, or routing intra-domain SIP requests between users on different S-CSCFs. Charging and resource utilization: i.e., the generation of call detail records (CDRs) Acting as a Topology Hiding Internetwork Gateway (THIG): A special case I-CSCF, which hides the configuration, capacity, and topology of the network from the outside. The S-CSCF is essentially a SIP server that provides session control for subscribers. It is responsible for, among other things, interacting with network databases such as the Home Subscriber Server (HSS) for mobility and the Access, Authorization and Accounting (AAA) servers for security. Acting as a SIP proxy, the S-CSCF also relays signals generated by a roaming user for confirmation with the HSS in the roamer s Home Public Land Mobile Network (HPLMN), where the subscriber s profile is held. Once the user signaling event has been processed by the S-CSCF, it can be forwarded to whatever application servers and/or gateways are required to complete the user-requested action or session. These may include signaling and media conversion stops, especially if the call is destined for a different network. Until recently, specifications for the P-CSCF included the Policy Decision Function (PDF), which stores policies and consults them to make decisions about IP bearer resource allocation requests. The PDF has been separated from the P- CSCF to make it more accessible to WLANs and other so-called access networks. P-CSCFs also generate CDR or billing records that can be consolidated at a Charging Gateway Function (CGF). Taken together, IMS functions and reference points can be used to signal and keep track of any number of network features and services but IMS itself doesn t provide these features and services. Instead, IMS supports the delivery of new services. Perhaps a brief history of IMS evolution will help readers better understand this approach. Seven Years Of IMS IMS concept discussions began around 1998, during the time in which the Universal Mobile Telecommunications System (UMTS) third-generation (3G) specifications were being developed. IMS formally became part of this 3G system definition activity at the June 2000 3GPP SA Meeting #8 in Düsseldorf Germany. At this time, General Packet Radio Services (GPRS, or 2.5G) were being deployed, offering throughput rates as high as 56 kbps, depending on distance and radio conditions. With GPRS and other early packet data technologies (remember WAP?), users were able to get limited Internet access from mobile phones. In the same time period, W-CDMA was being introduced for more packet data capacity (up to 384 kbps was expected at that time). The Dusseldorf meeting didn t actually specify any IMS functions, but served to kick off the IMS specification effort, confirming the telcos twin objectives: to avoid the commodity fate of becoming bit haulers and to cash in on the Internet. IMS was expected to satisfy those objectives. In March 2003, the first IMS specifications were completed by 3GPP in UMTS Release 5, but they were complete only in a relative sense of making progress towards the 3G vision. Rel-5 generally described IMS, SIP and the desirability of end-to-end quality of service (QOS) as part of the All IP future, and it fleshed out descriptions of voice over IP (VOIP) services. However, sending VOIP packets over existing radio access networks (RANs) was considered inefficient and still is today by 3GPP due to the number of headers and the unwieldy ratio between header size and data content. Rel-5 took only a short step toward a common QOS and billing infrastructure, by introducing IMS as a control structure for the UMTS Packet Domain. The focus was to control and bill for any 20 BUSINESS COMMUNICATIONS REVIEW / JUNE 2005
new applications running over the GPRS/UMTS bearer. Rel-5 said that SIP would be used for call control and introduced QOS concepts, including Service Based Local Policy (SBLP, the authorization of QOS requests and the definition of the policies to be enforced by the bearer service network elements). Rel-5 also described where QOS and common billing functions might reside. Finally, Rel-5 mandated the use of IPv6. This is changing today, however, as equipment vendors are proceeding with IPv4 implementations. Since 2003, IMS has continued to evolve as various equipment vendors and network operators describe new functions by bringing in contributions to the IMS definition process. Depending on the desirability of the contribution and its impact on existing function schedules and ongoing work, new functions have been included, or approved as change requests (CRs) to current release definitions, or scheduled for the next release. The 3GPP has approved so many change requests (CRs) for IMS in each UMTS release that it is hard to determine if/when any release is fully baked. Of course, by starting with large and general descriptions, such efforts always require more work, and CRs are inevitable as mistakes/omissions are found and corrected. Simply put, the UMTS Releases are just steps in the migration towards full implementation of third-generation (3G) UMTS networks (Table 1). To take one example, IMS was enhanced for instant messaging and presence (IMPRES) in 2003 as part of Rel-6, but the operators didn t expect enough revenue from these services to justify the IMS investment. So 3GPP went back to work in late 2003, changing IMS again in an attempt to improve its value, this time making push-to-talk over cellular (PoC) its first target application. But 3GPP s PoC, as designed, has a basic flaw: Too many round trip times (RTTs) make performance undependable, and the system doesn t operate as well as the Nextel system it hopes to compete against. It now appears that 3GPP operator systems will use IMS for Web data and signaling, while maintaining circuit-switched voice bearers for the foreseeable future. IMS Rel-5 is likely to be limited to experimentation in laboratory settings, while production deployments of IMS, when they become feasible, will probably include devices with an aggregate of IMS functions selected by vendors from Rel-5, Rel-6 and Rel-7. Clearly then, the complete vision of IMS invoked by network operators and equipment suppliers lies in the future, but exactly when is unknown. In this vision, IMS is described as the means to integrate voice and data services over a packet-based infrastructure, to deliver end-to-end QOS for toll-quality VOIP, and to converge wireline and wireless infrastructures under a common set of end-to-end signaling and billing mechanisms. IMS architectural complexity and its gradual accretion of capabilities in each new Release isn t just the byproduct of its slow evolution through the standards-setting process. It also reflects the need to accommodate cellular providers as they gradually move away from their circuit-oriented voice networks and toward packet-oriented data networks. Recently, cellular providers are also looking for ways to include Wi-Fi and WiMAX technologies in their sweeping vision of IMS. At the same time, service providers with very different infrastructures, including wireline telephony and cable TV, also are becoming interested in IMS (see BCR, April 2005, pp. 16 17). What all these providers have in common is a desire to bring packet-based voice, data and video to their subscribers in such a way that they can control and charge for those services. For a number of reasons, however, this will be difficult even if all the different network operators and equipment providers agree to support IMS. IMS And The ITU: Drawbacks, Detours Or Dead Ends? It must be stressed that there is an unprecedented support, worldwide, among existing telephony service providers and their equipment suppliers UMTS Releases are just steps in the migration toward full 3G implementation TABLE 1 Important UMTS Releases Release 97 (1997): Often called 2.5G, this release introduced GPRS for data delivery over GSM (2G). Release 99 (1999, UMTS R3 3GPP): First release of the (3G) UMTS standard, in 1999. Included W-CDMA. UMTS Release 4 (2001): Separated the system into Circuit Switched and Packet Switched domains UMTS Release 5 (March 2003): First IMS Release, introduced the IP Multimedia Subsystem (IMS) as control structure of the Packet Domain, based on SIP for call control and mandatory IPv6. Introduced End-to-end QOS and Service-Related Local Policy (SRLP). Purpose: to enable new applications over the GPRS/UMTS bearer. UMTS Release 6 (December 2004 to March 2005): Includes some leftover IMS issues from Release 5.0, such as QOS Improvements (SRLP Control), and decoupling of PDF and P-CSCF for QOS Policy Control (allows non-ims application services authorization). Introduces support for IMS Access Independence, Instant Messaging and Presence Service, Push to talk over Cellular Service, WLAN integration, MMS (Multi-media Messaging Services), plus Enhancements to use SIP, Multicast and Broadcast Service (MBMS), and Event-Based Charging (which will now interact with Data Traffic Plane for online/offline charging). UMTS Release 7: Just getting under way in mid 2005, and is currently expected to focus on leftovers from Release 6, as well as defining fixed broadband access via IMS, policy issues, voice call handover between CS, WLAN/IMS and end-to-end QOS. It is likely that this list will expand. BUSINESS COMMUNICATIONS REVIEW / JUNE 2005 21
TISPAN wants to generate specs soon that will reference 3GPP s work on IMS through virtually all their standards bodies, for the IMS billing and control vision, and for using this as a basis for the ITU s overarching concept called the Next Generation Network (NGN). The work of fitting IMS into the ITU s NGN is being done by European Telecommunication Standards Institute s (ETSI) Telecoms & Internet Converged Services & Protocols for Advanced Networks (TISPAN). This work consists of nomenclature adjustments, as well as substantial changes that are intended to make IMS align with the wireline carriers existing architectures and planned migrations. In a sense, IMS is just one of several hard parts of the ITU s NGN effort, focusing as it does on convergence, signaling, multimedia and billing. Other difficult aspects that could hamper the advance of the NGN, as conceived by the ITU under the auspices of the United Nations, include government policy issues having to do with internationalizing Internet governance and closing the so-called digital divide between more and less technologically advanced countries. But international technical progress on IMS continues, albeit at a snail s pace. In March, the U.S. carrier standards body ATIS hosted a multiday workshop on IMS in Herndon, VA, which attracted nearly 170 participants (a previous meeting in June, 2004, attracted only about 80). The main objective of this meeting was to discuss IMS re-use by ETSI TISPAN. Very little real work was done, as this meeting focused on identifying issues, collaboration opportunities and discussions of working methods. Most of the discussion, however, was centered on rediscovering and rehashing old 3GPP and IETF issues, and discussion was often cut off due to time constraints. The main friction between 3GPP and TISPAN comes down to this: Many 3GPP participants (especially the GSM mobile operators) see TISPAN as the wireline carriers effort to save their declining business model by adopting IMS and forcing changes to it. Some consider this a distraction and a waste of time and effort. In general, however, the 3GPP attitude toward TISPAN has mellowed from politically correct resistance to acceptance that either 3GPP maintains control of IMS or it suffers the alternative of letting TISPAN proceed with their own IMS variation (which is likely to precipitate interoperability problems). 3GPP now considers TISPAN IMS work as part of 3GPP s IMS Rel-7 and will handle TISPAN IMS needs as CRs against that release, which is just getting started. For its part, TISPAN wants to generate specifications soon that include references to the 3GPP IMS work. So far, however, it s hard to see how TISPAN can meet their current timetable. ITU members also hope that using IMS as a basis for the NGN will help limit the number of different IMS variations, or facilitate their working together. But the 3GPP effort has a history of forking on technical advancements, as wireless innovation keeps outrunning the standards process, and everyone is used to multiple variations (see BCR, October 2004, pp. 57 61, and BCR March 2005, pp. 38 44). Neither ITU nor 3GPP have a reputation for rapid standards development, and, even if everyone agrees to some selected subset of IMS to pursue, there are still a number of details to be ironed out if it is to succeed. In general, these have to do with rationalizing the architecture and the migration path so that service providers with many different types of infrastructures can participate. Wireless vs. Wireline: Two Different Worlds? For example, everyone is finding out that wireless and wired environments differ significantly due to simple facts such as: The amount of control you have over the end user device leads to huge differences in perspectives on control and management. Mobile wireless devices are controlled by mobile operators, have limited functions, have issues with power, range and noise, etc.; while fixed wired operators do not control the user terminals, which have unlimited power and many functions. As a more specific example, there is no equivalent in wireline networks to the so-called smart cards used to identify mobile customers and trigger billing activity when they make calls from within another wireless operator s service territory. This is just the tip of the iceberg in terms of differences between the wireless and wireline worlds. There are different regulatory constraints, compliance requirements, QOS and location definitions, support requirements for legacy devices, not to mention the many differences in security and network management details. Specific changes to accommodate wired environments already have been identified as being needed in the HSS, S-CSCF, P-CSCF, Media Gateway Control Function (MGCF), Subscription Locator Function (SLF), Interconnection Border Control Function (IBCF ) as well as other Charging/Accounting functions. Only the I-CSCF, Media Resource Function Controller (MRFC) and Media Resource Function Processor (MRFP) can be taken unchanged from 3GPP-IMS, although this too could change as CRs proliferate. In addition, the wireline carriers face numerous issues with adapting IMS architecture to their own circuit-to-packet network migrations, including emergency calling, connectivity to legacy services, networks and CPE, and provisioning for streaming video on demand. These and other issues constitute a growing delta between the 3GPP s IMS, and the ETSI TISPAN s proposed use of IMS functions as the core of NGN. This delta is the subject of ongoing discussion, and may eventually challenge the basic premise that a common IMS core will provide all the expected benefits. 22 BUSINESS COMMUNICATIONS REVIEW / JUNE 2005
In the meantime, TISPAN s anticipated (and unrealistically aggressive) schedule for NGN is Release 1 by mid 2005, R2 by end of 2007 and R3 by end of 2009. Bear in mind that the ITU s concept of nomadicity (see below) is intended to give fixed line and mobile users completely seamless communication. Simply put, this means the underlying technology is expected to be invisible to the user in a multi-service, multi-protocol, multi-vendor environment. Briefly then, the TISPAN NGN releases currently plan to include the following: 1. Release 1: Multimedia services with nomadicity/user-controlled roaming based on use of an Network Attachment Subsystem (NASS). This TISPAN defined subsystem (or group of devices) supports user nomadicity and roaming with an xdsl access focus. The NASS can be distributed between a visited and home network. It does provisioning of IP addresses, user authentication, authorization of network access based on user network profile, access network configuration based on user profile, location management for emergency call, etc. Basically it is some glue boxes that allow a user to detach and then reattach to a new access network. 2. Release 2: Expected to optimize resources usage according to user subscription profile and service use. 3. Release 3: Expected to introduce full nomadicity with inter-network domain nomadicity/usercontrolled roaming and higher bandwidth access (e.g., VDSL, FTTH, WiMAX). Although the ETSI board expects eventually to have one wireless/wireline IMS spec owned by 3GPP and TISPAN together, that is asking a lot of the two groups. TISPAN works top-down from the services to the protocols needed to support them, while 3GPP could be considered mostly a technology-driven, bottom-up organization. Combining the different working processes and procedures of these two organizations will be difficult, especially when added to the already-mentioned technical differences. In other words, the bottom line about IMS is this: There is a lot of work to do, it is going to take a while, and it may not end up where its promoters think it is headed today. Conclusion IMS is a result of the telephony carriers growing interest (at 3GPP) in data applications, the Internet in general and the emerging wireless Internet in particular. IMS is part of a huge 3G gamble by the mobile telephony operators around the world, with assistance from traditional telephony vendors, to obtain control of the vast new Internet medium and monetize it. Due to different service environment needs of different network operators (wired, wireless and cable), IMS complexity, and the operators desire for differentiation, it is very likely that multiple IMS derivatives will exist if and when systems are actually deployed. One must say if, because IMS is complex and costly, provides very little (if any) end user value, offers little (if any) in the way of new applications (PoC is recycled Push-to- Talk ) and plans to use several new and unproven technologies (e.g. QOS, SIP, IPv6, policy-based networking ) on a grand scale. There are performance concerns already. Perhaps most ominously for IMS, there is no end-user (consumer) pull similar to what the market experienced with cell phones or Wi-Fi. In other words, IMS is a VERY high-risk strategy. As if that weren t enough to discourage IMS promoters, there is the obvious speed mismatch among the release schedules of the 3GPP s IMS and TISPAN s NGN, and the fact that both of these efforts, even with their delays, are still faster than the traditional carrier networks and their suppliers can implement, yet much slower than the ongoing actual evolution of technologies and business models. In other words, and as always, real innovators are outside the standards process. Clearly, however, IMS is part of a grand plan of sorts by incumbent network operators and supported by entrenched telephony vendors. As such, and in spite of the drawbacks and delays, it seems one or more variations of IMS could become the norm for all broadband access. This is the emerging, consensus view: That IMS will let broadband industry vendors and operators put a control layer and a cash register over the Internet and creatively charge for it. It is this monetization of the Internet that makes IMS extremely appealing to all communications operators and all but guarantees that it, and its numerous derivatives, are likely to spread Companies Mentioned In This Article 3GPP (www.3gpp.org) 3GPP2 (www.3gpp2.org) Alcatel (www.alcatel.com) ATIS (www.atis.org) CableLabs (www.cablelabs.com) Ericsson (www.ericsson.com) ETSI (www.etsi.org) IETF (www.ietf.org) ITU (www.itu.int) Lucent (www.lucent.com) NEC (www.nec.com) Nokia (www.nokia.com) Nortel (www.nortelnetworks.com) Siemens (www.siemens.com) WiMAX Forum (www.wimaxforum.org) The desire to monetize the Internet means some form of IMS will probably be implemented BUSINESS COMMUNICATIONS REVIEW / JUNE 2005 23