1.1 why was ims developed? - elsevier · 1.1 why was ims developed? ... that the ip multimedia...

1IMS Application Developer’s Handbook: Creating and Deploying Innovative IMS Applications.© Elsevier Ltd. All rights reserved.

CHAPTER

2011

Introduction 1 1.1 WHY WAS IMS DEVELOPED? The communications industry has undergone profound changes over the past decades, driven by similar economic forces across mobile, fi xed, and IT/computing networks. Econ-omies of scale and scope have stimulated equipment vendors and operators alike to pursue lower cost technologies, most often based on IP technology. It was within this atmosphere that the IP Multimedia Subsystem (IMS) was initially designed.

At its simplest, the IMS is a set of IP-based technologies that allow for ubiquitous access to multimedia services from any terminal, be it a mobile, landline phone, or PC. It is designed from the same conceptual basis as any mobile network technology, to provide global interoperability between all handsets and all operators worldwide. In addition, how-ever, the IMS is designed to handle universal service access – wherever you are roaming in the world, your handset should provide you with the same set of services. With the IMS, this happens automatically, without the developer – or, more importantly, the user – needing to do anything; the standards handle this complexity without the developer needing to worry about anything except his or her own service logic.

Like any technology, the IMS grew out of the existing political landscape of the indus-try in which it was developed. This book will help explain the reasoning that went into the development of this architecture, with particular focus on how it enables developers to cre-ate innovative services. In addition, this book will explain how developers can create busi-ness models within the value chain of the telecommunications world.

The IMS was designed to provide a wide range of possibilities for service creation. This means that it covers two fundamentally different market needs: fi rstly, what we all expect in terms of standardized services, where we can reach anyone without having to worry what operator the person at the other end has chosen, what device he or she prefers. Secondly, the operator – possibly together with content and service partners – can choose to provide innovative, differentiating services that make that operator the most attractive choice for end-users in the market. From an operator perspective, the IMS is also about reducing transaction costs: delivering innovative services while reducing time to market. Throughout this book, we will show how we can pull these rabbits out of the IMS hat. If you wish, you can fi nd out about some of the detailed magic that the standardization people have designed to make this happen, but if not we will guide you to what you need

CH001.indd 1CH001.indd 1 6/29/2011 4:20:50 AM6/29/2011 4:20:50 AM

2 CHAPTER 1 Introduction

to know – and only what you need to know – to build applications on top of the IMS platform.

1.2 OBSERVATIONS In a very real sense, the IMS is the response by the telecommunications community to the emergence of a number of key technologies. So, let’s take a look at the key properties of any modern communication infrastructure:

● IP technology is the basis for all present and future mass market communication. ● Communications are becoming multimodal, including voice, video, presence, messaging,

etc, sometimes on appliances that might not even support voice. ● End-users expect quality of service to increase (HD video, high-quality audio); this

requires negotiation capabilities and a network that actively assures that this is delivered. ● The market expects rapid creation and introduction of multiple services, fully utilizing

the capabilities of access network technology.

There is only one comprehensive, multi-vendor, multi-operator, internationally standardized architecture that fulfi lls all of the above requirements: the IMS.

A number of initiatives have appeared over the years that address one or more of these requirements. However, they tend to miss various parts of the puzzle: for instance, voice-over-IP (VoIP) solutions that assume pure IP connectivity have no means to assure the proper bearer handling in resource-constrained networks such as cellular systems. Other examples are systems that work well as long as you need to reach only the ones that have made the same technology selections as you, e.g. with a Skype client, you can talk to another Skype user but not one using Windows Live. In a sense, therefore, the IMS is about evolutionary necessity – once you reach a certain number of end-users on a technology, a global standard becomes more cost effective and more reliable.

However, as history has repeatedly shown, it is not always the perfect technology that prevails, but rather the alternative that is capable of attracting real market support. In the case of the IMS, this means being an attractive development platform. We will show that IMS clearly has the right qualities to be the tool of choice for application developers. In par-ticular, we explore how the advanced and varied features of the IMS can be packaged and exposed simply and effectively to the developer and user communities.

1.3 NETWORK VISION: ENABLE AND SIMPLIFY How does the IMS network support the vision described above? In the preceding section, we talked about future communications networks in terms of the need for them to allow every-one to choose their operator freely, and still achieve global reachability, i.e. multi-operator support. Figure 1.1 illustrates two more such “multi” aspects. Firstly, multi-access : all


31.3 Network Vision: Enable and Simplify

Servicenetwork

Control,media processing

Transport backbone

Metronetwork

PSTNPLMN

WLAN

2G/3G/LTE

Standardservices

FIGURE 1.1

Reference architecture.

services can be delivered over all access forms: fi xed, wireless, even legacy devices. Note that this does not mean that we need to bring all services down to the level of the lowest common denominator; if a certain access has capabilities that the service can utilize, it is allowed to do so. The negotiation capabilities and ability to announce intentions that allow this are a fundamental part of IMS.

Secondly, Figure 1.1 illustrates the multi-device aspect. Users are allowed to choose whatever device they want, and at the same time expect the communications system to adapt to whatever device – or indeed devices – that they have chosen to be reachable on at any given time. Again, negotiation and the ability to signal capabilities are essential to support this level of end-user choice. It should be noted that we do not link the term ‘devices’ to the connectivity mechanism that they are using to access the network. A mobile phone nowa-days can be attached via WiFi, making it essentially part of the fi xed access world. To blur things even more, it could actually still provide telephony services that the user perceives as plain old cellular services, using bridging architectures like UMA (Unlicensed Mobile Access; the ability to use a WLAN to connect a phone to the GSM/WCDMA core network). Conversely, a laptop can be connected over mobile broadband, which means that even though its services are defi ned by PC expectations, it belongs to the wireless side as far as connectivity is concerned.



You might argue that the property of being used by a wide variety of devices is not that unusual: after all, a basic property of IP technology allows for the delivery of anything to any-one over any access. An IP connection, however, only identifi es a network connection point – an IP address. The IMS, however, focuses on the end-user or the individual that you want to reach, irrespective of their IP address. The network fi nds the correct person that you wish to establish a connection with and selects the correct device, even when multiple devices are active. As an example, it will not attempt to establish a video session to a mobile handset that does not support video. The IMS is designed to handle this complexity seamlessly.

The IMS ensures that the level of complexity associated with handling all the differences and combinations of operator, access, and handset manufacturers is not something an appli-cation developer needs to concern themselves with – it is handled automatically on his or her behalf. The application designer is left to concentrate on the actual logic of the service. As will be seen later, this happens on two levels: the core IMS network provides functions concerning the fi nding, authenticating, charging, and managing of the end-user. “Finding” across network boundaries using a uniform naming scheme is the key concept, as the main role of the network is to provide reachability, “fi nd-and-connect” being the basic service as experienced by the end-user.

The second level – the service layer, as it were – adapts, personalizes, and delivers content. The interplay between user, subscription, devices, bearers, and media fl ows is extremely inter-esting, because this is where person-to-content and person-to-person services overlap. This illustrates rather vividly the aspect that IMS is not just another voice replacement technology (although that certainly is a very viable use), but enables a much richer set of opportunities. New approaches are needed to fulfi ll the promise of new access technology without creating an unmanageable tangle of options and restrictions for the end-user. Therefore, the two key value propositions for the IP multimedia subsystem (IMS) are essentially what was stated in the heading of this section, enable and simplify: “enable” as it supports such a wide range of access, service and interconnectivity options; “simplify” as it provides one and the same infra-structure across all these technology variants.

Before we get into more technical detail, at this point it might be useful to examine a few of the relevant current technical trends.

1.3.1 Billions of Mobile Handsets While a handset is the most personal device imaginable – it is always with you, it is the way you are reached as a person, it is becoming the preferred way of keeping in touch with your social network(s) – it is also important to realize that for the majority of people, a mobile device will defi ne how they use the Internet. This level of personalization provides opportuni-ties for tailoring services and service behavior to the needs and wishes of the user, as well as the means to provide context and user profi le adapted content. Mobile device identifi ers do not identify a place (as is the case with classical phone numbers) but rather a person. We can thus associate several attributes to a person by way of the identity of the device.



FIGURE 1.2

Relationship circles.

Extending the argument above, it is also very clear that communication occurs in many dif-ferent contexts. You want to keep in touch with your inner circle – family and close friends – as well as with acquaintances, colleagues, business contacts, shops, companies they deal with as private customers, health services, offi cials of various kinds, banks, and so on. Applications that are created must be able to manage these different contexts in a coherent and understand-able fashion without trying to squeeze them all into one mold. Additionally, the mechanisms that keep track of these partially overlapping circles cannot be application specifi c: each new application should not need to be told who your friends are. Conversely, a set of contacts you want to keep track of – say, the parents of your child’s classmates – is not defi ned by what applications they prefer, but rather from the contact network that you share. Coupling this idea of multiple spheres of infl uence ( Figure 1.2 ) with the desire to keep information from leak-ing from one circle to another, you realize that the communications infrastructure should also allow you – when you so desire – to use different identities for different purposes. The IMS provides such mechanisms in a standardized and consistent fashion.

1.3.2 The Multi-Talented Mobile Handset These days, a mobile handset is so much more than merely a phone. It is a camera, a cal-endar, a music player, a radio, a note-taker, a voice memo recorder, a game console, and a credit card. And on top of that, mobile Internet devices are also increasingly general-purpose computing platforms. Indeed, it is just about anything you might carry in your pocket except possibly a handkerchief and a comb (but of course a mobile with a front-facing camera works quite well as a mirror!).

However, as mobile application developers have discovered – often painfully – over the years, the diversity of platforms and device capabilities is also a major problem: either you produce literally hundreds of build variants of your application, or you fi gure out some way



of detecting and adapting to your environment. Ideally, your code should not have to con-sider platform differences that are of no consequence to your application; at the same time, you also want to be able to exploit the capabilities of a given platform that can give your app that extra edge. Of course all this should happen without the end-user ever needing to under-stand or deal with the peculiarities of how his or her handset happens to be built in terms of low-level detail. Thus, a very important facet of any IMS device-side application develop-ment environment is how it handles device diversity.

1.3.3 Extending Existing Behavior When implementing radically new technology, it is quite important that users can relate to the new functionality by referring to something well known. Telephony may be an (almost) ancient concept, but the fi nd-and-connect and human-centric way of thinking about commu-nication is the basis for both the SIP protocol and the IMS. Of course, the IMS provides all the relevant support for well-known addressing schemes. Telephone numbers (known in the trade as “E.164”), and mail-style addressing must be supported. Additionally, it helps tre-mendously if there is someone to contact from day one; thus, interoperability with existing networks is a must. It is, however, most certainly not restricted to the “I-call-you” model; the IMS also encompasses many other forms of communication popularized by the ubiq-uitous social networks: publish-and-subscribe for presence-style posting of what I want the world to know about me; instant messaging – multimedia enabled, of course – for chatting with friends and people with shared interests, etc. More importantly, however, it can be used in conjunction with the existing social networks – it enhances web technologies by provid-ing a global standard for multimedia connectivity.

1.3.4 Voice-Over IP Over Broadband Voice-over IP (VoIP) has clearly moved from being a technical possibility to a market real-ity. New entrants and incumbents like Skype, Vonage, and TeliaSonera have implemented fi rst-, second-, and third-line telephony services with considerable market impact.

Why has this happened now? Obviously, the main enabler is the availability of ubiqui-tous broadband access, over whatever medium that happens to be convenient (xDSL, cable, Metro Ethernet, fi ber, mobile broadband). Also, the fact that the average (even the below-average) PC of today has the capability to handle the media plane without resorting to spe-cial hardware has helped move this area from the hardware to the software domain.

Assume, then, that you are signing up for a VoIP service. Then you try to phone a friend, and fi nd out that he or she hasn’t signed up for that vendor, but s/he has an ordinary phone – can’t you try that? With a bit of luck, your provider will allow you to dial out – for a fee – to the public telephony system (Public Switched Telephony Network: PSTN, if you are into alphabet soup, and as you will see we are – but we will try to explain everything as we go along). But should your friend want to call you, you want to be reachable, so – for a higher fee – you can also typically get a phone number to post on your Facebook page.



But can’t you just get your friend to download the same software? Of course, but she might have already selected another, and you don’t really want to give up your choice, do you? And cluttering up your entire desktop with clients seems a bit unnecessary (and even more cumbersome if you try to do it on a small screen device). So you end up connecting, but via a PSTN link connecting the two IP networks, delivering 3.1 kHz audio. And that seems such a shame, when both of you were going digital. Again, IMS comes to the rescue, having fi g-ured out all the details of how you connect not just within a network, but also between them, including also how you interconnect with PSTN when needed.

At this point, we should also point out that a key value of IMS – one that we will return to – is the fact that it is deliberately built on trusted authentication mechanisms. Between the network and the user, authentication mechanisms (based on SIM cards for the mobile side) are used to ensure that the person connecting is who they say they are; between peering net-works it is based on IPSec and contractual trust relations. This is actually one of the ways to combat unwanted and/or malicious communications; it is not nearly as attractive to misbe-have if you can’t be anonymous.

In a sense, what we have described above is an interesting illustration of the fact that communications solutions are not created by protocols alone, but by careful development of architectures in which the protocols operate. In addition to providing the framework for multi-access, multimedia, multi-operator, multi-vendor (important for the operators!) and multi-device operations, it is also designed from the ground up for massive scalability (bil-lions of connected devices), with the possibility to charge for services. The latter is still an important factor: one way or another, infrastructure must be paid for. However, this does not necessarily mean the traditional “subscriber pays” model: it could be sponsored, ad-fi nanced, revenue shared, or any other interesting new business model. Whatever the case, the network still needs the ways and means to keep track of what is delivered to whom and what is con-sumed in the process. Again, this is something the standardization groups have considered.

A word of caution while we are still on the subject of VoIP: a fi xed operator can typi-cally consider implementing voice over IMS as a way of delivering telephony at lower cost, phasing out obsolete legacy equipment and replacing it with IP-based infrastructure. One way of achieving this is to connect legacy end-user equipment through various kinds of gate-ways converting from IP connectivity to classical two-wire analog technology. The end-user should not really notice anything: the same services and the same devices are being used (see Figure 1.3 ). Recently, this strategy has been mimicked by the creation of the VoLTE way of delivering voice over LTE (which does not have any circuit-switched bearers in its arsenal). Interestingly, the “invisible change” property implies a very interesting set of requirements; of course, reliability, scalability, and performance of the new way of doing business must match or preferably exceed the classical methods. This means that IMS had to be designed to allow instant very-large-scale implementation, something not easily achieved when creating new technology.

Now, if voice were all we wanted to do, the problem would be much simpler. However, voice-over IMS is not called VoI (or whatever); it is known as MMTel (Multimedia



FIGURE 1.3

Replacing the switch.

Telephony). Of course, it can deliver voice only, but as the name implies the whole control machinery is available for you to add other media streams to the call. Thus, you can start with something fairly simple, but the machinery is ready for bigger and better things, such as the applications we expect you to create, once you have fi nished reading this book!

1.3.5 The Mobile Phone, Boosted Having considered fi xed access above, what about mobile multimedia? In a sense, there are no fundamental differences between the access forms (disregarding speed, latency, and error rates for the time being). However, the mobile device has evolved over the past few years, from a simple voice device through messaging (SMS) and simple email to a veritable pock-etful of entertainment and information options. So, it does not come as a surprise that you might want to use those capabilities to add to the communication experience. Extending the concept even further, you may well compare the resulting device with something coming from a directly opposite direction: any kind of consumer electronics is nowadays likely to be upgraded with the ability to talk to its surroundings, turning it into a CCE (Connected Consumer Electronics) device. At some point, it will be tricky (and maybe irrelevant!) to decide if a device is a phone with a camera or if it is a camera that you happen to be able to talk into.

All this obviously couldn’t happen if it wasn’t for the almost unbelievable improvements in processing power, battery life, display capacity, user interface fl exibility, bit rates, etc. Downloadable applications – and the app stores to fi nd them in – have appeared to exploit the opportunity to treat the handset more like a general-purpose computing platform than a phone. However, note that in order to manage essential capabilities like, for example, secure authentication and audio/video streams, you still need platform support in the device, as improper use of such functions may jeopardize the stability and integrity of the device, or in extreme cases the network itself. And as the network is in a very real sense – particularly in the mobile case – a shared resource, it needs to be protected.


1.1 why was ims developed? - elsevier · 1.1 why was ims developed? ... that the ip multimedia...

Documents