IMS Guide

IMS is a label that has started springing up all over the telecom industry, whether on individual products, or as vendor systems platforms or interoperability programs. It’s the acronym for IP Multimedia Subsystem, and it is very, very important – a big vision of the future of telecommunications hangs on it. It’s also very, very complicated and pretty abstract.

This tutorial aims to resolve some of that unfortunate conjunction by providing a quick and easy guide to some questions that are frequently asked about IMS. In the report's initial form, answers to a number of basic questions are given, one per page. But the idea is that readers can ask further questions on the message board attached to this article. If you want to send a private message, please email us, and include "IMS Guide" in the subject field. Frequently posed questions will be answered by adding pages to this report.

For a basic understanding of IMS, here are the key starting points:

  • IMS started as a technology for 3G mobile networks (under the auspices of the 3rd Generation Partnership Project (3GPP)), but it is now spreading to next-generation wireline networks and is going to be a key to fixed/mobile convergence. It builds on the Session Initiation Protocol (SIP), which has emerged as the crucial technology for controlling communications in IP-based next-generation networks (NGNs).

  • IMS is about services and applications, enabling telcos, mobile operators, and other service providers to offer rich multimedia services across both next-generation packet-switched and (within obvious limits) traditional circuit-switched networks. It is standards-based and uses open interfaces and functional components that can be assembled flexibly into hardware and software systems to support real-time interactive services and applications.

  • IMS will have a major impact on the telecom industry – including telcos, mobile operators, service providers, vendors, and others – because it will lead to new business models and opportunities, and (hopefully) lower costs through standards-based procurement. It simultaneously lets network owners derive added value from their networks, while opening these networks to third parties (including enterprise customers) to develop and offer enhanced and tailored services and applications of their own. The full exploitation of mass-market broadband will depend on it.

  • The basic set of standards for IMS implementation were released in 2004, and the first implementations are in hand or planned. Both the International Telecommunication Union (ITU) and the European Telecommunications Standards Institute (ETSI) are heavily involved, and IMS standards are still developing to fill in the inevitable gaps and to add new capabilities. However, IMS is still untested in real-life major carrier networks, and its widescale implementation is some years away.

Support for IMS even at this early stage in its development seems to be fairly hard-nosed, if the results of a poll taken during the Light Reading Webinar on which some of this report is based – IMS: A Blueprint for Fixed-Mobile Convergence – are typical:

  • Just over 40% of respondents thought that the most important catalyst for IMS deployment was the service providers’ need to create a more flexible environment for the deployment of applications.
  • 18% thought it was service providers’ need to create a converged fixed and mobile network.
  • 17% thought it was service providers’ need to deploy blended or combinational multimedia applications.
In other words, a large majority in favor of pragmatic flexibility, rather than any fancy and/or more futuristic possibilities.

Here's a hyperlinked list of the questions and answers in this report:

This report is based partly on material drawn from various Light Reading resources, including:

Archived Webinar on IMS:

Paid research reports on IMS:

Light Reading news analysis on IMS:

To learn more about IMS, check out the coming Light Reading Live! conference:

IMS: Blueprint for Fixed-Mobile Convergence
at The Sheraton Hotel (Buckhead) in Atlanta, on Wednesday, March 30, 2005

  • For more information, click here.
  • To register, click here.

— Tim Hills is a freelance telecommunications writer and journalist

1 of 10
Next Page
Page 1 / 11   >   >>
[email protected] 12/5/2012 | 3:49:36 PM
re: IMS Guide There's a list of some such operators in Table 1 of the recent Light Reading update on IMS at http://www.lightreading.com/do...
ebrahimi 12/5/2012 | 3:49:36 PM
re: IMS Guide I want to know how many NGN operators use IMS in their network and what is their name.
shmalhotra 12/5/2012 | 3:29:14 PM
re: IMS Guide Can IMS be used with VOIP phones ? If yes can you suggest how and what areas it would be helpful in ?

Thanks and Regards
hzaman 12/5/2012 | 3:02:04 PM
re: IMS Guide Can some one explain how web service and IMS are related, specially what is the role of web service in Service layer of IMS?

If you have some idea, please mail me at [email protected]

tomposz 12/5/2012 | 3:42:14 AM
re: IMS Guide GǣMost interestingly, the "Profile" schema is designed to hold "transparent" application data also associated with the Public ID used to identify the concerned party fopr any given request/dialog. In this sense, the "Profile" extends beyond the schema and application defined by the 3GPP into areas which overlap with the schema's for enablers like Presence, Group List Management and even other non-standard applications. The fine-grained access to these related Profile parts is not facilitated by any of the 3GPP application usages of DIAMETER, but is made possible through a combination of SIP and XML Configuration Access Protocol.Gǥ

Emphasis added above (bolding) is mineGǪ

I remember a few carrier deployments of LDAP a number of years back wherein what the carrier was deciding should be in the schema was not completely able to support the application, in this case a large scale Voice Messaging application supporting the carrierGs residential customers G we are talking millions of users and many hundredGs of calls per second for the large scale deployment we were doing.

Case in point: user password. Should it be in the GǣdirectoryGǥ maintained by the HSS? Sure it should, customer support (ala OSS) is going to interact with user during a phone call for help when they forget that password and want it reset.

Should the application get the password from the HSS? Sure, but what about encryption of the password, i.e. stored in the GǣclearGǥ; stored encrypted; and where is the type and logic surrounding the access methods? GǪ

This detail could never get agreed to during the previous implementation discussions surrounding a carrier wide LDAP directory for services and I suspect it will not be agreed to during the GǣHSS acting as a brokerGǥ philosophy discussions in a pure IMS deployment.

End of the day? G a directory (in the past proprietary, today probably LDAP) local to the application to support a complete set of fields necessary to support the application (one such as Voice Messaging) while the subset of this set is maintained on the HSS. And for performance reasons in large deployments, this LDAP directory is probably in RAM with disk recovery features upon server failure. It may even have separate LDAP search mechanisms with cut-down directory sizes so that even Gǣin RAMGǥ searches can perform to the level that proprietary solutions can do today. In the old days, one might have called this index-sequential, but this is only a description at the macro level, since LDAP mechanisms must still be supported, if only to take advantage of the rest of the open-source paradigm.

In this way, hashing of the user password (or any other encryption method) could be implemented locally along with the logic resident in the application itself. There are other examples, of data that no one would want in the HSS, but they would, by definition be information on the user and should almost by definition be in the HSS.

At the end, implementation decisions around performance or usage will perhaps force this to be stored locally, in LDAP, and maintained there under application control, because it has to be accessed very quickly and/or it may not be used anywhere else except that application.
optodoofus 12/5/2012 | 3:22:00 AM
re: IMS Guide All this is well and good, but I'm curious how billing and settlement would work in such an environment. The writeup indicates that new service providers with no network could be formed to just offer a service layer. But of course, to access the service layer, the subscriber must go over someone's network. Would the subscriber also need to separately buy access through someone else's network (kind of how I can access my corporate VPN over my cable mode today - but only if I buy cable modem service first)? Or would the service provider establish a series of realtionships where they provided compensation to the carrier network for each session terminated on their service infrastructure (like how the IXCs pay the ILECs for terminating calls on their local networks today)?

What are the thoughts on the business model opportunities? And are the standards in place to support billing and CDR (the way Bellcore AMA format is used in the PSTN)?
dljvjbsl 12/5/2012 | 3:21:56 AM
re: IMS Guide Is anyone still wondering why the traditional telcos are going to fade away?
standardsarefun 12/5/2012 | 3:21:53 AM
re: IMS Guide What's this business about ITU-T having a role in IMS? Their NGN fokus group pretends to cover it but even its own members question the assumption that their work should be based on 3GPP spec's.

Anyone got any real proof that ITU-T should be listed here as "involved" (=actually doing real standards making work)
standardsarefun 12/5/2012 | 3:21:53 AM
re: IMS Guide optodoofus asks: "..I'm curious how billing and settlement would work in such an environment.."

All of this stuff, including the relationships between an access provider and an end users service provider, is covered by the 3GPP core specs for IMS and this is part of the reason why it's so interesting for many service providers because it is one of the fe VoIP systems that you can actually make money with by selling service.

dljvjbsl 12/5/2012 | 3:21:52 AM
re: IMS Guide The article states that a service provider can supply a personal calendar service. Can anyone think of an application that is more suitable to being provided by a user-owned device than his personal calendar.

Actually there is one, service providers do offer speed dial services from their switches. Instead of storing speed dials locally on a $20 telephone and activating a number with a labeled button, the service provider stores them on its switch and forces the subscriber to remember a 1 or 2 digit code for each. On top of that it charges $4 a month for the service.

Both these examples show the futility of supplying what are naturally local services with a centralized architecture. There is nothing novel about this architecture. Centralized service logic is just the AIN rehashed. When with that zombie finally return to the grave?
Page 1 / 11   >   >>
Sign In