IP Multimedia Subsystem (IMS)

What is IMS?

Everyone agrees on the need for new and innovative communication services. People use an increasing variety of communication methods, from traditional voice calls to text messages, instant messages, pictures, video and online gaming. Many of these new services were born on the Internet while others emerged from cellular phone networks. As communication networks migrate universally to IP technology, these services are converging and becoming available on an increasing variety of devices, from laptops to cell phones, Blackberrys, PDAs and smart phones.

Naturally, network operators are keen to offer customers as many of these services as possible and develop yet more features that people will pay for. New products not only generate revenue, but also help a service provider stand out in an increasingly congested and commoditized market.

The IP Multimedia Subsystem (IMS) is a specification of an environment where these kinds of new services can flourish. It is an area dedicated to innovation in a service provider network. IMS is designed to make the development, deployment and delivery of new applications as quick and simple as possible in a standardized fashion. In particular, IMS is concerned with a network within which communication is in real time between peers. IMS is much less concerned with applications for the consumption of multimedia content, delivered in a synchronous, browser-based fashion.

SIP is the Key

The key technology behind IMS is the SIP protocol; the 3GPP have chosen SIP as the protocol underlying many of the important interfaces between elements in an IMS-based network. Carriers and service providers have been using SIP to build new products for sometime. Why? There are several big advantages to building a new feature or service using SIP:

• Simple. SIP is based on a straightforward request-response interaction model, making life simple and comprehensible for developers. The messages are also text-based which makes them easy to parse, create, read, understand and debug.
  
  
• Extensible. SIP can set up sessions for any media type, be it voice, video, application sharing or teleportation (once we invent it!)
  
  
• Flexible. SIP allows developers to interact with the individual protocol messages (within limits) without breaking anything. This means that developers can perform a lot of neat tricks that make development much easier.
  
  
• Familiar: In large part because SIP borrows heavily from HTTP and other internet standards from the IETF, lots of web-like technologies can be used to build SIP applications. SIP development looks and feels a lot like web development, and there are a lot of web developers out there.
  

So clearly, there are many reasons you would want to build your applications in the land of SIP. The only problem with this approach is that few networks, and even fewer phones, speak SIP today (although they will in the future). Most cell phones, office phones and home phones don’t understand it. So if we build applications in SIP, how do can we use the new services using our old, non-SIP phones?

The answer is to surround our SIP development ‘oasis’ with gateways which convert SIP signaling to protocols that the rest of the network can understand, including your cell phone and my home phone. If we put these gateways in the right place, then everyone is happy: developers get a great environment in which to build new applications and we get to use their new features using our existing phones. The diagram below shows this gateway architecture in action. Bob has a new feature, find-me-follow-me, which his service provider decided to build in SIP space and deploy using IMS. Bob isn’t aware of SIP or IMS of course: he just gets a great new feature which ensures Alice can always find and speak to him.

Today, this is really the essence of IMS: a standardized way of embedding a SIP oasis into a non-SIP network in order to create a happy place for applications developers. It’s important to do this in a standard way so that network equipment vendors, software companies and service providers can mix-and-match components. IMS is the specification to which all these companies are working.

IP on Everything

This oasis architecture is not the endgame for IMS. Eventually, everything in the network will be IP-based, or as Vint Cerf said, there will be “IP on everything”. Fourth generation (4G) cell phone networks will be pure IP and SIP, all the way to the handset. All calls and other interactions from your cell phone will be entirely IP based. Eventually even the old phone in the kitchen will be an IP phone. Once this happens, we won’t need gateways to perform protocol conversion to and from IMS anymore. In this case IMS become the specification for the entire network architecture and endpoints will connect directly to it using pure IP and SIP. We’re not there yet of course, so IMS will remain as an oasis in a non-IP network for a while. But someday we may be able to say “Everything on IMS” (and Vint Cerf will doubtless say “I MS with Everything”).

Wireless or Wireline? Both.

IMS was originally conceived as part of the 3rd Generation Partnership Project (3GPP) specification for third generation (3G) cell phone networks. The forebears of the 3GPP organization were responsible for specifying the GSM second generation (2G) system and their work helped it become the most widely deployed cellular technology in the world. Standardization made possible some remarkable features for GSM customers, such as international roaming and interchangeable handsets. Clearly IMS is an important specification with a distinguished heritage and pedigree.

3GPP is specifying IMS to deliver new services and applications to 3G cell phone users. Part of the specification ensures that IMS is independent of the access network, so that network operators can offer new services over different types of radio interface and different types of cell phones. This is the essence of the gateway architecture we’ve already discussed – delivering new SIP-based services to any kind of device, and by extension, to any kind of network. Because this design cleanly separates applications from user access, IMS has become attractive to other service providers outside the wireless industry, who can simply swap the radio access interface for their own access network.

As IP technology is adopted across all kinds of networks and industries, network architectures are converging so that wireless, wireline, voice, video and data network designs look essentially the same. As network architectures converge, IMS has become attractive to anyone who wants to offer advanced services, from mobile phone operators to traditional phone companies to internet service providers and cable companies. Indeed, it is likely that wireline operators will be in the vanguard of IMS adoption and deployment because they often face more competition than mobile operators, and thus have a greater need for the kind of high-value, differentiating services IMS can deliver.

There is an IMS variation tailored for the requirements of wireline operators. The Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN) specification is controlled by the European Telecommunications Standards Institute (ETSI).

The Specification

So what does the IMS standard describe? How does IMS recommend we build our oasis for new applications? The specification essentially describes two things:

• A selection of logical network functions. IMS defines a set of logical elements that are required to deliver new services: It’s rather like a tool box for developers of new services. One of the key aims of IMS is to offer a reusable ‘kit of parts’ that are shared among applications to ensure new applications don’t require separate disconnected silos of data and functions. The kit inventory includes everything an application developer needs, including application servers, media servers, gateways and data stores. A key IMS concept is shared customer data, to which all applications have access.
  
  
• The interfaces between these functions. By making the interaction between the logical elements standard, we can mix and match different components from different manufacturers, or even build our own (at least, that’s the idea).
  

It’s the Software, Stupid!

By standardizing components and interfaces, IMS describes a network that is very different from those in use today. Before IP networks and IMS, telecom networks were typically composed of closed, vertical silos of components that didn’t interact with each other, with no reuse of components and no possibility of mixing and matching elements from different sources. As a result, IMS is set to create a very different commercial, as well as technical environment. Network equipment vendors (NEVs) will find it much harder to lock-in operators with closed, proprietary technology. IMS solutions will typically be a collaboration of many companies, each bringing their individual expertise to the environment. This is particularly important as the role of software becomes fundamental in the network. IP networks in general - and IMS in particular - will swing the focus of development towards software folks and away from traditional hardware manufacturers who have previously dominated the industry. Hardware and software expertise and culture are rarely easily combined.

In addition, IMS also offers the opportunity to expose standard software interfaces to third-party software developers so that they can take part in the creation of new applications. Again, this is in direct contrast to today’s closed systems which are accessible to only a handful of developers, using arcane, complex interfaces - proprietary to each manufacturer. As we have already seen, SIP technology looks very familiar to the multitude of software developers working with Internet technologies. IMS aims to embrace this community of developers by offering them standard interfaces, like web services, that are both familiar and simple to use.

What the User Gets

Of course customers don’t care about reusable components, standard interfaces and shared data. They only care about much higher-level behaviors they can interact with directly, such as the quality of their voice call, or easy access to their email and instant messaging contacts. As well as standardizing lower-level functions, IMS specifies higher level behaviors too. These behaviors benefit the customer and make the difference between using a paid IMS service over a similar, freely available service on the Internet. For example:

• Security. IMS ensures proper user authentication and authorization, and privacy. Users are authenticated once, and this single-sign-on is used to access the entire range of services to which they subscribe.
  
  
• Roaming. Services can be offered across separate networks via roaming mechanisms specified by IMS. Users of GSM phones can already roam between different networks run by different operators. IMS enhances the roaming experience by allowing users seamless access to their services, data and applications from another network.
  
  
• Quality of Service. IMS makes sure that communication sessions are of guaranteed quality. One of the problems with public Internet-based communications is that it is typically ‘best effort’. The Internet offers no guarantees of bandwidth or latency and the communication experience varies widely as a result. The IMS specification makes sure there are always enough resources available for your communication session by dynamically reallocating as required, prioritizing your important video conference over my frivolous ringtone download.
  

Network-centric in a Peer-to-Peer World

An interesting feature of IMS is that it represents a very network-centric view of the world, while SIP is fundamentally a peer-to-peer protocol. One of the design goals of SIP was to produce a highly scalable communication model by pushing intelligence to the edge of the network. The dumber the center of the network, the faster it can operate and the more scalable it becomes. Traditional telephone networks operate in the opposite way: An intelligent center with dumb telephones at the edge. The traditional network model gives service providers ultimate control, and IMS is clearly rooted in this approach and it defines only the network core and has little to say about edge devices.

Service providers must find a role to play in the center of the network to avoid disintermediation by pure peer-to-peer technologies (of which Skype is a prime example). Although SIP can operate in a pure peer-to-peer mode, it is enhanced by the addition of central network elements. Proxies, registrars and other SIP network elements offer basic functionality to make the routing of calls much simpler and the user experience can be enhanced yet further by the addition of more sophisticated SIP applications. This is where service providers aim to add value, and to make money. SIP can be forced out of a pure peer-to-peer model by the insertion of back-to-back user agents (B2BUAs) and other constructs which return control to the network center. The IMS specification makes extensive use of these kinds of techniques for network-centric control.

Part Two

In Part 2, we will take a deeper technical dive into each of the major functional elements standardized by IMS. We will look at the purpose of each element, their interactions and standard interfaces between them.

By Matt Darby, Avaya.

The Avaya SIP Application Server works seamlessly with the J2EE and service oriented architectures of today's 2.5G networks, while also integrating with 3G IP Multimedia Subsystem (IMS) architectures - future proofing today's deployments.

Mobile service providers can deliver high margin, end-to-end next generation applications quickly and cost effectively by utilizing Avaya Professional Services as well as our strategic IMS, J2EE, and handset partners, including HP, IBM, Nokia, Nortel, Qualphone, and Siemens.

Further information >>>