A couple of years ago there were lots of hand-wringing comments about how the proliferation of handset OS's was harming the chances of any consistency in mobile applications development and uptake of data services. Operators like Vodafone made pronouncements of how they intended to rationalise their software platform base.
At the time, I was skeptical that there would be any easy way to meaningfully reduce the number of smartphone OS's as well as proprietary featurephone platforms. And in fact, if anything the number has risen, with the continued growth of RIM, the emergence of Apple's OS, Google/Android on the horizon and a continued plethora of other Linux platforms vying for attention. Meanwhile, none of the major handset vendors has committed to phasing out their proprietary platforms like Nokia S40 or the various Moto / Samsung / LG / S-E equivalents.
On the merchant-featurephone software stack there have been a few changes to be fair, with Qualcomm's BREW/UIone appearing on some more devices, but with TTPCom's Ajar being absorbed into Motorola's software maelstrom. Others like OpenWave and Obigo and Intrinsyc are still around too.
There is no obvious emerging contender to sweep away all others, especially at a global level. I can't see Nokia pushing S60 much further down into S40's domain. I can't see Apple or Google making a huge mark outside North America. I can't see RIM or Microsoft abandoning the enterprise sector. UIQ and a couple of the Linux players are not the strongest, but if they disappear I'm sure there will be plenty of newcomers to take their place - isn't it about time we saw a reincarnated Java/SavaJe-type player, for instance?
Meanwhile, all the real action seems to be migrating to the presentation layer - Webkit browser, Adobe Flash, Microsoft Silverlight and so forth. There seems to be at least a vague semblance of homogeneity emerging there, at least on high-end devices. Sure, even at that level there won't be "one platform to rule them all", but some variation of Web+Widgets+XML+various extensions is perhaps not as tricky as the current app-porting challenges.
There are some interesting side-effects of all this - even propagating through to the network side of the industry, despite the fact it likes to think itself divorced from developments with mere handset software.
In particular, the industry seems to be moving even further away from fully IMS-capable handsets. Sure, in some ways the IMS client framework is starting to get a little more realistic, but with the shift in value (and certainly the shift in innovation) towards the browser it's starting to look a little irrelevant. Yes, we might get some IMS-based apps on the phone - IM, presence, even full VoIP - but that's not where the cool stuff is, and I think that the web aspects of the handset are moving too fast to be captured in even a next-gen IMS/Web architecture.
In particular, the chance for VoIP to become an "anchor tenant" for IMS has diminished, with the standardisation of the fairly-pointless MMTel Multimedia Telephony. As I've mentioned before, 3GPP has totally missed the point with MMTel: next-gen mobile telephony will be about integration, mashups & web services.... not video-calling/sharing and other "media".
Given that some sort of VoIP is mandatory with LTE (unless operators want to run GSM/UMTS networks in parallel forever), somebody really needs to get working on a more useful mobile VoIP standard NOW, and work out how to implement it in phones. In fact, whoever does the work should start from the standpoint of the user, with a phone in his/her hand and then work backwards to determine what the network has to look like to support a proper version of Mobile Telephony v2.0.
One of the themes I've discussed with a few companies recently has been the impact this could have on cellular network architecture. In particular, I've been looking at the current converging mess at the edge of the network that is some combination of SBC, security gateway, softswitch, GGSN and assorted other functions. I've been speaking to companies like Stoke, Acme Packet, Sonus, Nextpoint, Mavenir etc recently, and I'm starting to wonder if the required aggregation models will be driven indirectly by device type & usage cases, as much as they are by infrastructure-based decisions for multi-access.
If the traffic delivered by handsets - and the capabilities valued by end-users - moves away from session-based services like voice & IM, and towards more web/browser/widget functionality - what effect does that have on the boxes at the edge? I haven't got a full answer to this yet, but it's definitely something I'm looking into closely.
Dean Bubley's Disruptive Wireless: Thought-leading wireless industry analysis
Your comment on the need for a mobile VoIP standard is very intriguing. I wonder if the IETF or 3GPP/3GPP2/UMA guys have though about this. If VoIP providers really want to replace legacy voice, then they have to address inter-operability urgently. The beauty of PSTN/PLMN is that one can call any number from anywhere irrespective of which service provider the caller and callee are attached to. VoIP services on the other hand however still operate on closed platforms. Why cany I call my Skype contacts from Yahoo?
ReplyDeleteThank you for the article and yes, we need a VoIP concept apart from video telephony and media sharing. Those are a part of the integration with other services, not the point. I wonder though how much of it can take place in the browser and on platforms like Silverlight or Flash which are limited in regard to VoIP on the desktop and nearly unusable on the mobile phone.
ReplyDeleteAll of these can't beat the level of integration one can achieve with a native application and right now we're talking about the W3C proposing standards to have access to a few underlying cellphone functions such as system events and using the cellphone radio. So in spite of all the OS fragmentation there's a good chance that it will be a native application that delivers this level of integration.
And as for arbit_bloggers comment: You have to discriminate closed platform services like Skype (which becomes irrelevant on many levels because of this) from those that use open standards like SIP and are very well interconnectable by simply entering a SIP-URI. Some providers might try to block out these possibilities, but in general that is how it works.
My name is Daniel Enström and I work at Ericsson Research. As you might guess I am one of the co-writers to the MMTel book you referenced the other day in your blog. However, I have a few comments which might (or might not) interest you in relation to MMTel (no surprise... right?)
ReplyDeleteFirst of all I am a bit surprised that you missed completly the point of the PSTN replacement ambition of MMTel. If we talk about convergence in the telecom and broadband business, i.e. in terms of everything running over IP with no CS legacy, we need to decide if we want to keep a telephony service at all. By telephony service I mean a real-time voice service with guaranteed reliability, reachability, interoperability and quality with an efficient transmission resource utilization. If the answer to that question is yes, then standardization is required. A standard which is clear, detailed and adopted by telecommunication standardization bodies (in the MMTel case both ETSI TISPAN and 3GPP). A service which users can rely on and feel secure with without using a CS fallback solution. If you interpret the MMTel standard as that it is pure VoIP with the addition of video you have imho only discovered 5% of what MMTel really is.
If you want to create such a standard you start with some assumptions. In the MMTel case, it was that it should be IMS based. Now, if you make a completly IP based real-time communication service, SIP based, and the total multimedia machines called mobile phones is the major target platform, why on earth wouldn't you make sure you have (non-mandatory btw.) support for other media than speech? From a standard point of view, the addition of video and real-time text is easy, as well as the support on the control plane. Voice is of course the target media but to totally neglect support for other media types seems really shortsighted at least if we are talking about a converged telecommunication service for an IP based future.
For the service itself, IMS Multimedia Telephony might or might not be the service which is markted. The purpose of the standard is to define the tools (i.e. the layer below the ones used in the webkit browser, web mash-up) that are needed to provide a CS replacement service. We are not talking about a 5+ million community of users, we are talking e.g. about the 3.5 billion mobile users which will, eventually (if we believe the convergence vision) migrate to the PS world. This is of course not something that will happen over night but the MMTel standard is in my view the first real step which tries to give some technical foundation to the convergence vision. I guess history will show if this is the case or not.
Further, I fully agree with what you are writing about next generation of voice (there is much more you could add to that list!)
1. Better quality, coverage, pricing. MMTel has built in support from start for wide-band speech. Discussions have already started in 3GPP for next gen voice codecs with even better quality. Ultimately, MMTel coverage needs to be at least as good as CS speech but that is a radio network issue, not a service issue.
2. MMTel voice provides the technical foundation which is needed for any embedded voice app including context sensitive applications. The context sensitivity is the "top layer" which easily (if you have the ideas!) can be built on MMTel voice.
3. Voice mashups, fine. MMTel plug-in for a browser (with todays technology, see e.g. the Ribbit solution) or with some other future technology, no problem. The core issue is the same, you anyway need the technology behind the surface. MMTel can give you that, why would you settle for less?
Finally, your comment about MMTel voice not being best-optimized and/or efficient really needs some more elaboration from your side. An IMS system as a requirement to run MMTel, which might (or might not!) pose a certain technology threshold but I really challenge you to show me a better optimized service in terms of quality and bandwidth efficiency!
To summarize, I agree with a lot of things that you are writing, but efficient, cool applications embedded Voice, Skype-like applications etc. needs to be based on open, efficient and well specified technology which guarantess interoperability. The web interface, the mashup technology, the context sensitive applications, will happen, they will probably be huge, but they all need the fundamental technology beneath the surface. MMTel is so far the only fully specified standard solution to achieve this.
MMTel is not about the shiny surface, it is about the technology beneath the cool web apps (or cheap voice-only, LTE-only terminals).
Best regards
Daniel Enström
Dean, don't do a wholesale inclusion of widgets with web apps. Having actually brought both to market in the US, there are essentially two types of widgets, those that run in a browser and those that do not (C based may or may not use HTML rendering engines, J2ME based). Any widget that runs in the idle screen and its own framework is very much like a traditional app with its own porting challenges and session management. Chris
ReplyDeleteArbit - you make a good point, but interoperability is only important for "traditional phone calls".
ReplyDeleteWhat seems clear is that there is also a growing angle to VoIP which is "non-telephony", such as enhanced IM, conferencing, community-based chat, or voice embedded in business processes or social networking mashups etc.
This is a discussion I've had a lot recently - and while it would be sort-of nice for all forms of VoIP to interoperate, it's far from essential.
While some VoIP providers *do* want to replace "legacy voice", others view it is much less relevant to their proposition.
Falk - I agree that full browsers. Flash & Silverlight are still immature on handsets, especially for massmarket use with session-based services. That will change over time, but it'll take a few years to percolate through the market.
ReplyDeleteThe W3C proposed standards sound interesting & I'd like to follow up. Do you have any public reference points?
Daniel
ReplyDeleteThanks for your comprehensive comment. I've spoken to Ericsson several times about MMTel, and I certainly do understand its ambitions to replace the PSTN.
I'm just unconvinced it's the *right* replacement. It should be Open Telephony, or Extensible Telephony, not Multimedia Telephony. And there should also be a standardised “Basic IP Telephony” variant for operators wanting to cheaply deploy no-frills VoIP.
It's worth pointing out first that I'm a mobile analyst, so my views are driven primarily about what makes sense to replace mobile circuit voice, rather than fixed/cable telephony. The two are very different worlds (still) and network-centric views of convergence that fail to consider realities about devices & user experience are doomed to failure. I don’t have a particular view on fixed-PSTN replacement, although it seems that various NGN VoIP deployments seem to work pretty well without MMTel.
My thoughts on MMTel stems from my research for my recent report into VoIPo3G technologies & business models.
Yes, any replacement will (probably) benefit from standardisation. But as I discuss above, there will also be various forms of VoIP that are *not* about PSTN replacement but about new, non-telephony applications for Voice. These do not need numbers, and certainly don't need IMS or even traditional service providers. They may be Internet- or enterprise-based, or peer to peer, or browser-driven. Ideally, any proposed PSTN replacement would recognise the existence of such alternative islands and embrace them, rather than ignore them or attempt to force them onto a wholly unrealistic IMS path.
I’m not one of the many people who view IMS as a complete failure. I think that in mobile it will have *some* relevance, especially in transport & control, but it will not be the dominant mechanism for delivering application value. It will also not be adopted by all operators. However, LTE & WiMAX are likely to arrive in advance of IMS in many operators’ networks, and they will need some form of VoIP unless they are to be pure data services. As IMS will not be ubiquitous, a next-gen telephony standard cannot assume it as a basis for VoIP.
“why on earth wouldn't you make sure you have (non-mandatory btw.) support for other media than speech?” Simple – because basic telephony is about voice, and enhanced telephony is about more general (rather than specific) extensibilities. The main problem with MMtel is that it attempts to be “IMS for IMS”. It bundles a random set of other peripheral applications (video, text, presence etc) into what ought to be a simple application. These could be standalone, or provided as enhancements on a general basis. The mere fact it is called “multimedia” telephony indicates that the priorities were in the wrong place – I don’t think it’s just a poor choice of name.
“first real step which tries to give some technical foundation to the convergence vision”. Perhaps the vision is wrong?
I agree about wideband speech – that’s fairly important. But I disagree that many people (especially developers of Internet or enterprise applications) will view an IMS/MMTel exposed API as the best way to create new applications when there are many simpler alternatives. Ribbit, Broadsoft, Sylantro, Skype, AePona and many other platforms have also done work here, as have operator-sponsored initiatives like BT’s Web21C.
Re: efficiency – I’m not quite sure exactly what you’re referring to about bandwidth efficiency. Some of the future gains to be made in the radio network are independent of the application layer, hence the work on CS voice over HS bearers, or advanced receivers, for example. I haven’t really scrutinised the details of MMTel vs other VoIP technologies in terms of signalling overhead, codec choice etc – that’s a bit outside the scope of my usual analysis.
Thanks once again for your contribution
Dean