IMS - What about the client?

In the world of "next generation" and "converged" networks, IMS is currently looking to become king. One of the aspects of IMS that gets talked up is the so-called "combinatorial services" idea. The concept here is a mix-and-match services built upon a variety of underlying services, such as a bit of push-to-talk, a bit of presence, a bit of IM, a bit of this and a bit of that. It is good that the ethos of IMS is committed to this idea from the start. In essence, it is the same as the current trend for open-APIs via "web services", such as the way Flickr can be accessed by other services. Google maps is another example.

However, unlike in the web world, in the world of SIP-based IMS, the delivery of these combined services is more problematic. The fulcrum of the web is really the browser because it is a universal client - it can present any data from any site. One client for potentially millions of services on the web. However, there is no universal client for IMS. This makes the client the weak link in the system.

Of course, I'm not talking necessarily about combining services in the client. A lot of the "combining" will be done at the server, in the same way that Google-map derivatives are created. However, some combining can be done on the client and this is offered in some approaches toward IMS client solutions, such as the inclusion of a presence-API on the client to enable any app developed for that client to be presence-enabled. an example could be the much talked about presence-enabled phonebook - see if the person you're calling is available or not etc. Some combined services are inevitable on the phone because the application needs access to native phone applications and data stores, such as the text messaging inbox and address book. Although, one has to ask to what extend more and more of these functions can be migrated to the network.

Application portability is affected if these client-APIs are not standardised. Of course, there is a degree of standardisation through the Java MIDP process, but we all know that for many applications the "write once run anywhere" promise is sorely broken.

One wonders to what extent operators might be ready to push their handset vendors towards a standard "platform" so that development of services can truly flourish, notwithstanding all the other hindrances, such as the "walled garden" business models. Many operators are about to invest in IMS networks. At the moment, their general mentality towards apps still revolves around "killer app" concepts, or very much NOT the long-tail: a few apps making big bucks. I can't imagine an operator really thinking beyond a few tens of services at most. But, when it becomes apparent, as eventually I think it will, that a world of thousands of services might be possible, then standardising the handset platform might become inevitable. The forthcoming "IMS client" problem might make this realisation come sooner, although we still need various technical advances towards the "universal client" idea.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book