IMS client

This is a reponse to the question 'What exactly constitutes an IMS Client' that was posted by various people on ForumOxford.

The main components of an IMS client, consist of the following:

OS functions:

IMS specified protocols, such as SIP, SDP, XCAP, RTP etc. that are essential for IMS based services

IMS core functions, such as registration,session control, authentication , authorization, accounting, QoS etc.

IMS enablers for services, such as presence, IM, location, PoC etc.

API support:

IMS core APIs for the standard interfaces specified in the IMS framework

IMS enabler APIs for the standard enablers for services specified in the IMS framework

Application support:

IMS service enabler based applications, such as an IM client, presence client etc.

IMS core enabler based applications, where applications are not based on standard IMS service enablers

Applications that are hybrids consisting of customized combinations of IMS services enablers and IMS core enablers

The harmonization work in the IMS specifications is currently a work-in-progress with multiple standards development organizations on an industry-wide scale, and will have impacts on the evolution of the IMS client. Ericsson, PCTEL, and others have advertised various flavours of IMS clients. Overall both vendors and providers have a significant interest in the IMS framework, and the adoption timeframes are expected to be over the next few years, since it is a significant paradigm shift from the existing service delivery models.

Vendors with IMS clients include Ericsson Mobile Platforms, Movial, Ecrio, Comneon (part of Infineon) and a bunch of others. Nokia probably has its own one in development as part of a future version of S60.

Typically, the IMS software on a phone will consist of a 'framework' platform into which are plugged a bunch applications like PTT, IM, VCC, VoIP etc. The framework has a bunch of 'plumbing' protocols like the 3GPP flavour of SIP

Unfortunately, there are no standards for how the framework-application integration works. You can't put Movial application easily on top of an Ericsson framework. Until that's fixed, there will be very few IMS handsets, because developers will not want to have to port IMS apps to a dozen different IMS frameworks.

The OMTP has released some specifications about IMS phones which should help matters. There's also still a lot of questions about how the IMS part of the phone integrates with the non-IMS bits (SMS, browser, TV, IT applications , non-IMS SIP applications etc).

Given the current membership of companies in the OHA initiative, it is anticipated that the IMS client will be supported. The IMS framework is expected to be enhanced to support both SIP, and non-SIP based applications in the future. The browser enabler is a standardized service enabler specified by OMA, which leverages the underlying IMS framework, and can be integrated with an IMS client. (For instance, NetFront has a client that supports the OMA browsing enabler as well as IMS.)

The IMS framework provides a high-level of abstraction that enables applications to be developed and integrated without being impeded by the access technology specific nuances. SIP applications, or any other applications that are implemented without the IMS framework will be subject to both implementation and integration complexities, particularly in the mobile space, where the complexities of the RF link impact the implementation, integration, and the user-experience.

Note: the IMS framework has several aspects to it in terms of hooks into the various underlying access technologies, as well as a common layer of abstraction and information hiding, which is invaluable for widespread third-party application development, as well for a reduction of integration complexities. The bearer-level aspects are being addressed with respect to the various prominent access technologies such as LTE, UMB, WiMAX and Packet Cable.

According to Dean Bubley, entire Internet & IT community is negative towards IMS - Google, Microsoft, Yahoo, Skype et al.

IMS = walled-garden SIP, or perhaps more amusingly an "Internet Monetisation System".


The problem is that IMS views everything as a billable 'service' - it doesn't seem to accept that certain applications are based on the customer owning or operating their own software. In the real world, customers want certain capabilities delivered as ongoing sbillable ervices (opex) and certain things bought, owned & used outright (capex)


The current setup of the Internet is that centrally-controlled QoS and charging is anathema. IMS harks back to the legacy days of bundling access & service. That's fine for certain things, but totally inappropriate for the Internet, as that control adds latency & friction to development & innovation. I've heard IMS vendors talk about developers and "2 men & a dog in a garage", when what they actually meant was "2 men, a dog & a 30-person legal department".


As a simple example - could you imagine that anything as mindbogglingly useful as PDF would have evolved had the Internet been based on IMS principles? Download the client for free & then use it in perpetuity as a browser plug-in? No, we would all have been charged for a usage-based 'document viewing service', and it would never have got the traction.


The one thing that could change the situation is if one of the vendors - perhaps Cisco or Avaya - invented a private IMS architecture, that enterprises or large Internet firms could own. It would be deeply amusing if Merrill Lynch or GlaxoSmithKline deployed their own IMS's, and started charging interconnect fees to the telcos.