Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Monday, May 08, 2006

What's an IMS handset? And who cares? I've already got one with "Naked SIP"

5 years ago this week, the Economist published this article. 3G services, it commented, were going to be delayed by the slow development of 3G handsets.

It's time to lift the lid on the area I've been researching for some considerable time - IMS handsets. I'm just putting the finishing touches to a major research study on IMS- and SIP-capable phones. I'll be publishing it in the next week or so, and I'll put some highlights up on my blog (and finally get around to updating the main Disruptive Analysis website....)

Let's just say that the Economist should republish the same article, transposing the term IMS for 3G.

Only this time round, we're not even at the stage of operators standing up and saying "Er..... you know these IMS networks we're deploying? Well, we've got a small problem....."

This morning I did a Google search on a number of IMS-related terms. The results give a pretty clear idea of the relative focus of the industry on the infrastructure, rather than the devices:

"IMS applications" - 63,900
"IMS services" - 61,300
"IMS networks" - 25,400
"IMS handsets" - 103
"IMS phones" - 84

Look at any vendor presentation on IMS, and you'll see a small box in one corner labelled "UE". This is a phone - "User Equipment" in the IMS standards jargon. Now look at the standards that have been developed for these phones. Yes, they've got SIP. And some 3GPP extensions.

Now try & find anywhere that says how these phones should actually work in the hands of the user. How does the "IMS client framework" work with all the other applications on the phone? What are the standards for the user interface - telling the other presence user that your videocamera is switched off, or that the phone's in your pocket & you're using a Bluetooth headset? Does the phone need to be multi-tasking capable if you want several IM sessions, video-sharing and a buddy list working simultaneously? While listening to the MP3 player too? How should it behave differently if it's got WiFi in it? Should the applications be "bearer aware"?

The bottom line is that once phones ship that are properly IMS-capable (probably late 2007-early 2008), we should expect another 2 years of fiddling around trying to get them to be decently useable. Especially as the earliest ones will have operator-proprietary software stacks and applications. Reliable interoperability between handset brands (or operators) for anything other than the most basic push-to-talk or video-sharing applications is a LONG way off. And I haven't even factored in any unexpected problems with battery consumption or end-to-end service latency.

Oh, and if you think this is bad, the news gets considerably worse for IMS proponents.

You see, the comparatively "easy bit" of all this IMS handset software & UI stuff is installing a SIP stack in the phone. That is standardised. And there's a bunch of other good reasons to put SIP in the phone well before "full IMS" is needed - and not just the 3GPP/IMS version of SIP, but the Internet-friendly IETF version as well.

So, well before we get IMS handsets, we have SIP-enabled ones. They're already shipping - the latest versions of Windows Mobile and Symbian OS both include SIP. Future versions of handset Java will as well. Not only that, but 3rd party developers can access the SIP stack, and write their own applications that exploit it. VoIP, or IM, for example. IP-PBX clients. Conferencing tools. Open-Source SMS replacement applications. Cool Web 2.0 stuff. Use your imagination.

These are "Off-portal SIP applications", using mobile devices equipped with "Naked SIP".

I've done the numbers in my new report. I estimate that between now and the end of 2011, there will be, cumulatively, 980m more "Naked SIP" cellphones sold than "Closed IMS" handsets which restrict the user to the operator's billable IMS services.

That's a billion extra mobile devices capable of supporting disruptive non-operator SIP applications, developed by 3rd parties, over the next 5 years.

I've said before that IMS is less a "walled garden" than an "open prison". Well, the inmates have already started jumping over the fence, even before they've been shown to their cells.

The report includes comprehensive market forecasts, analysis of SIP/IMS usage cases and market drivers, and profiles of key handset IMS/SIP companies. It is around 160 pages long, and has been based on well over 100 interviews. If you want to know more about purchasing Disruptive Analysis' new "SIP- and IMS-capable Handsets" report, please email imsphonesreport@disruptive-analysis.com

2 comments:

Donselaar said...

I fully agree with your view. There is a clear gap in between:
The device manufacturers offer (and what already existing terminals are available) in terms of IP Communications and the lack of IMS capable "stacks" and even proper applications other than the traditional silo thinking ie "PoC" and "Presence" client seperately on the handset...
- what end users are expecting (end users are now Internet users, not Telecom users and they expect integrated services also in their terminal; not the silo services)
- and Ultimately the gap is between the above two and what the operator would like to launch NOW, as they are competing more heavily than ever before.

Donselaar said...

One thing I forgot to mention is that even though there will be "IMS stacks" on the terminal, the standard is still relatively new and we are seeing that with every new server environment we test against, where both us and them follow the standard, still requires significant changes to be IOT. So not only if there are SIP stacks available, the next problem is IOT with operators IMS and(or IP networks which will be another hurdle to overcome.