Pages

Pages

Thursday, February 22, 2007

IMS handsets and IMS proxies

At 3GSM last week, I caught up with a number of providers of phones, SIP/IMS-related handset software, and their counterparts on the network side. I wanted to see how far things had moved on since I wrote my SIP- and IMS-capable Handsets report*. In the middle of last year, it was very evident that mobile operators' possible deployments of IMS faced a fairly insurmountable problem (in addition to all the other problems with IMS...) in the lack of IMS-capable phones, and the lack of any agreed standards or consistent specifications to create them. (And how to to integrate IMS and non-IMS apps on the phone, and myriad other issues).

Although numerous vendors have pitched "IMS client frameworks" for handsets, they have used proprietary interfaces internally with few open APIs and limited developer support, meaning that any innovating operator or application vendor would face a nightmarish porting challenge, if they wanted to get a cool new IMS app across multiple phones. While a few, very large and prescriptive carriers could possibly "standardise" on one specific framework, insisting that all handset suppliers used it, this is unlikely for the majority of service providers.

The net result - a bottleneck in handset development for IMS services. A few things have been standardised - PoC (push to talk) for example. The GSMA was highlighting its video-sharing interop trials in Barcelona last week. Big deal. Neither of these are going to generate even a small % of the revenues needed to build a business case for a mobile operator deploying IMS infrastructure. What is needed is either proper cellular VoIP (which has other issues), or some way for the "next MySpace" to be developed for IMS and adopted virally across a broad range of operators, handsets and IMS client software variants.

My discussions in Barcelona last week suggested that not much had changed, unfortunately. There's still no "alliance of IMS client framework suppliers" to foster interoperability. There's still no broadly-agreed basis of operator requirements for IMS phones (I know that OMTP was working on something, although no details are apparent yet). There's still a lack of developer support for software vendors wanting to write IMS applications that actually give a decent user experience on a range of phones.

Meanwhile, adoption of handsets which include a "naked" SIP stack, addressable by non-IMS 3rd party applications, continues to increase rapidly.

The only movement around IMS handsets appeared to be a growing consensus (OK, OK, perhaps a forlorn hope....) that a new Java API, JSR281, could fix the problem. The idea is that developers (operator-internal or 3rd party) could just write normal Java applets that use IMS capabilities. In principle this seems reasonable... apart from the fact that much of the cool stuff on handsets is now migrating to the browser rather than the Java engine, or else is in completely separate "domains" like a music or TV section of the phone's software. I'm somewhat pessimistic that JSR281 is a complete answer to the problem.

One alternative approach I've started to see is the possibility of using "IMS proxies" - basically embedding some form of IMS user agent in a home gateway, femtocell, PBX or something else, converting applications or content so that it can be used on "normal" non-IMS handsets. Clearly, this isn't an ideal option either, but it might end up being seen as a more practical choice in the short-to-medium term.

(*my IMS handset report is still the most in-depth published analysis available covering these issues. Contact me via info at disruptive-analysis.com for details)

4 comments:

  1. Anonymous10:14 am

    I was also at 3GSM and what really surprised me was how quiet the show was about IMS. I think that the "penny is beginning to drop" that IMS is going to be complex, very complex and perhaps mobile operators are ill prepared for it.

    Dean, apart from the handset issue and naked SIP proposal, do you think that the SIP-focused suppliers (SONUS/Veraz etc) can sneak in and show how its done in the large-scale SIP deployments : Vonage/TalkTalk/eAccess etc.

    Will the big operators listen???

    NB

    ReplyDelete
  2. Anonymous1:06 pm

    Hi Dean,

    Interesting article. Just to let you know that the word from the grapevine is that OMTP will be ready to publish their agreed operator requirements at the end of this month.

    It looks like a good first effort however, with standardisation in 3GPP moving on to another proposed release and a lot of topics yet to be tackled, OMTP IMS version 2 will probably be the one to look out for in S2 2007...

    ReplyDelete
  3. Anonymous1:18 pm

    ...just to continue, I would agree that JSR-281 is not the be-all-and-end-all. In fact it is just the beginning of IMS on handsets...and even the production of JSR-281 is faltering somewhat (did someone mention delivery in Q4 2006?).

    I'd also agree that an open environment where applications and services could be distributed virally across devices, operators and countries will be critical to the success of a technology like IMS.

    With a common and well-defined IMS framework this would be possible but operators are nervous of the effects of opening access to major internet players...what with operators currently seeing the money in IMS coming from service bundles and packages.

    Someone's not asking the big questions here. What is being promised with IMS is network convergence...but with what limitations and strings attached this will come with is anyones guess and critical to the success or failure of IMS vs. Naked SIP access.

    ReplyDelete
  4. Here's some advancement with JSR 281: Nokia Siemens Networks released a JavaME client SDK which provides an IMS library with JSR 281 interface. It can be used on any (powerful) MIDP 2.0 phone.
    https://www.ims-developer-program.com/index.php?id=29

    ReplyDelete