.comment-link {margin-left:.6em;}

Wednesday, April 26, 2006

IMS 'Reality Check' - Part 2

My good friend Martin Geddes' comments (see post IMS 'Reality Check') have caused quite a stir...

Christophe Gourraud, from Swisscom, who knows more about IMS than anyone I've met so far, sent in this great response:

"I found the last entry written by Martin Geddes (www.telepocalypse.com) very interesting and stimulating. It includes very good points, but for me a lot of the statements Martin is making seem to be based on assumptions about how IMS will be used in the future, rather than what IMS really is or can support.

I am personally of the opinion that the IMS genes (specifications) can lead to several potential futures, and that IMS will eventually be what the industry will make out of it. The issue might therefore be more about culture than technology.

Here follow some elements which may help to redefine the (technical) potential of IMS:

The fact that IMS is a telco specification does not mean that it defines a new telco world apart from the Internet. It is true that there is an IMS network architecture, and that there exist IMS-specific extensions to SIP. However, this architecture and these extensions do not prevent simple interworking between SIP devices and applications in the IMS domain and SIP devices and applications in the Internet space.

An important point about IMS and SIP is that, unlike previous telco standardization efforts (like MMS with regards to SMTP), it did not reuse a snapshot of IETF SIP specifications to define pure telco ones. What it did was to integrate/reference IETF specifications into the telco ones, together with a few extensions (for which there also exist IETF RFCs). This means that most extensions to SIP made in the IETF sphere can directly be used into an IMS network. This is very important for openness and extendibility aspects (see Martin's "Promise 4" below).

It is also a chance to redefine the relationship between those telco and Internet service providers who are willing to establish partnerships.

The fact that IMS is strongly based on the SIP protocol does not mean that IMS applications are limited to the usage of SIP. Other service-oriented protocols like SOAP or HTTP can be used for the delivery of services over or through IMS. Moreover, SIP itself should not be limited to session control. This is a very powerful, multifacet and extensible Internet protocol whose application may largely evolve in the coming years, both in the IMS and the Internet spheres.

The fact that IMS is defined as a "multimedia" network does not mean that it will only support streaming or conversational (multi)media sessions. It will support them, but may also support file transfer and other types of services, based on SIP and its potential combination with other more adapted protocols (e.g. HTTP, FTP, XML). Martin mentions user data and the possibility to share and federate it with 3rd parties. This is actually a very important opportunity for IMS, based on mechanisms supported by the combination of SIP and a protocol like HTTP, for which presence is a good example.

The fact that IMS standardization focused so far on 1) the core network and 2) a few network based services and enablers, does not mean that IMS has to support only network based service logic. IMS is based on Internet protocols like SIP, which were specified in the IETF for edge-based intelligence. It is not the doomed telco destiny of SIP and other Internet protocols to suddently become network-centric once they are referenced into telco specifications. The IMS core network tree should not hide the potential IMS service forest.

The fact that the IMS core network is quite complex does not mean that the IMS application layer and IMS services have to be complex. IMS specifications have the advantage to clearly separate the heavy duty core network entities from the potentially more IT-centric service entities (devices and application servers). I personally think that the complexity of the IMS core network can be totally hidden to IMS services, and even that part of this core network complexity can make the application layer even simpler.

In this context time to market for IMS services may essentially become a matter left to the Suns, IBMs, BEAs, HPs, Microsofts or Oracles of the world. Martin makes a good point about the potential difficulty for next generation developers to deal with operators: this is right on the cultural issue and the need for operators to evolve.

The fact that IMS specifications include a lot of control mechanisms in the network does not mean that eventual IMS networks will end up inspecting every packet running through it (actually IMS itself does not include packet inspection) or generate charging information for every single service usage attempt. I think it is nice to have quite sophisticated control and charging mechanisms in the specifications, but it will be up to the future and specific operator's requirements to define if and how they will be used in practice.

The usage of IMS for fixed mobile convergence assumes that you still need a control network (IMS) in the fixed mobile converged world. Once this is achieved, you can deploy or access services independent from the access technology. IMS defines a SIP control layer on top of IP. Such a layer originates from the Internet (IETF) so it can be said that even in the Internet this layer is perceived as having some potential interest. It is true that the future of IMS is linked to how "interesting" the SIP control layer (or service protocol) really is.

Likening IMS to IN is a big mistake. IN permits to plug application servers on top of a voice-centric network through a dedicated telco protocol which essentially permits to control calls. On the other hand, the IMS service architecture can be seen in a nutshell as a way to enrich IETF-based SIP routing with (user or service) profile-based mechanisms. Once you understand that SIP is not the typical ISUP or INAP/CAP, and that it can support much more that session control, alone or with sister Internet protocols, you can start to think otherwise about IMS.

To conclude, I will say that for me the future of IMS is tightly linked to the future of SIP as a service protocol in the Internet and the IT world, to the ability of the telco industry to change its culture, and to its ability to use the full power of IMS specifications and select which parts are more relevants than other (see my article in the February issue of IMS Insider - [for subscriptions and back copies go to www.ims-insider.com or email editor@ims-insider.com ]."

Thank you, Christophe, for a tremendous piece. More on this debate to follow (subscribe to our Spring bumper edition of IMS Insider for more in-depth analysis).

The Editor, IMS Insider

See http://corporaterat.blogspot.com/2006/04/3gpp-ims-how-real-is-it.html for a very interesting hands-on opinion
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?