Yesterday, I attended the session on voice over LTE, and this morning I hosted a roundtable analyst breakfast. In the former, the speakers were fairly monochromatically IMS-advocates; the GSMA talking up its VoLTE initiative, followed by Ericsson and ALU.
One interesting thing was the GSMA referring to "migratory solutions" before operators reach the "target" of IMS-based VoIP. Conspicuously, it was fairly even-handed about both VoLGA and CS Fallback. Together with some other anecdotes I've heard recently, there definitely seems to be a softening of enthusiasm for CSFB as the Plan B. [For my views on its deficiencies, see white paper here]
Another audience member asked about the viability of using Skype as a solution. The answer was that it should certainly be possible over a broadband connection... but that it would not benefit from the QoS enabled by an operator-based solution.
My own realisation is that this might be completely the wrong way around. In fact, Skype and Google may well be in a position to guarantee *better* quality of experience for voice on LTE than the operator's in-house solutions, of whatever type.
Basically, we are moving from a world of handset "certainty" for voice, to a world of handset uncertainty, which operators and their network vendors are poorly positioned to control.
The nice, new policy-managed IP core and radio network is the easy bit.
The big half-truth coming from the network vendors is claim that they can guarantee "end to end" QoS for voice. I believe this to be very wrong, especially on higher-end devices. The specifications, as far as I can see, give very little guidance for how to create or enact QoS right down to the client application level.
Remember - old-style CS voice is guaranteed in quality on the handset itself ("certainty"), because it runs on the baseband chip, with a real-time operating system. Nothing gets in its way. The telephony stack is, essentially, baked into the hardware - an evolution from Alexander Graham Bell's architecture.
But this is not true if the VoLTE application runs on top of the handset's OS and applications processor - where it will implicitly compete for resources with all the other apps and services. These may well be "gating factors" on overall QoE, well as radio coverage . Over time, VoIP might migrate "lower" into the OS itself, although it will likely be integrated with higher-layer apps like the advanced phonebook or social network client. I can't see it being buried deep in the baseband for a long time.
This inter-dependence with the OS was brought home to me using Skype recently - and seeing an unexpected red icon, before I went to make a call. I clicked on it, and up popped Skype's QoE window - which shows that the application itself not just measures the quality of the network (and its ability to support VoIP), but also checks the load on the processor, and whether the microphone and headset are working OK.
It told me that I had insufficient processor speed available for a decent VoIP call - I realised I had a looping script running in a browser window. I closed it, and then made my call.
This was a real illustration of a problem I expect to see for LTE Voice: if the telephony application runs on top of the OS, rather than being baked into lower-level parts of the software stack and hardware, it is going to have to deal with the vagaries of the new "computing" style enviroment. It is not obvious to me that handsets will automatically be able to prioritise VoIP as well they have handled CS voice operations in the past, especially on multi-tasking phones.
This has many knock-on implications. It makes it much more difficult to test and certify the voice performance on the device, because the number of extra variables and dimensions increases (plus also for LTE of course, others relating to frequency bands also further complicate the issue). It also makes the performance sensitive to OS updates and versions.
It also means that there may be unexpected interactions with other software components - for example if an enterprise installs a VPN client to tunnel all of an employee's handset IP traffic via the company network. Does the VoIP / VoLTE client avoid this, or comply? Is that secure for all concerned?
And who owns the algorithm for prioritising the apps in terms of the resources they can access? The operator, the OEM or the user? What if the user decides that a data application is more important than voice (eg for healthcare, or anti-virus, or a financial trading app)? What is the "policy management" architecture for the handset's internal operation?
None of these issues appear for normal CS voice in GSM, as it is all essentially hardwired into a different part of the chipset. Nor does it occur in fixed VoIP, where most handsets are relatively "dumb". It does exist on PCs with VoIP client - hence my Skype experience.
This means that it is likely not possible for an operator to claim control over end-to-end performance and quality of voice on LTE, even where coverage is complete.
The most likely response is to "leave it up to the handset vendors", but in my view that is abdication of responsibility to at least define *requirements*, if not actual full standards.
Instead, coupled with other variables in the LTE ecosystem, this means that voice is likely to be less reliable, and less test-able than is the case with 2G and 3G. It might have more fine-grained control in the transport part of the system - but that's of little benefit to a user who can't make a call for other reasons.
(QoE also includes battery life of course - another variable outside operators' control, and which has not been a primary focus in VoLTE to date, although the GSMA is now looking at related areas like "fast dormancy" on the radio network).
So we are making a move from device "certainty" to "uncertainty", irrespective of the performance and policy cleverness of the infrastructure. This, to me, suggests that VoIP players that are most-capable of coping with device uncertainty will have an advantage.
This means companies that can look out for processor performance, measure and manage battery life, let the user make easy choices ("Switch to GSM to preserve battery?", "switch to HD voice for this call?"), handle application mashups and conflicts etc. will be in a much stronger position for voice than those that just "leave it up to the IMS client".
NEW Mobile Broadband Traffic Management Paper
2 comments:
Dean, very interesting analysis and a you raise a valid set of points, especially that if user QoE is impacted by how a SIP client runs on a phone (processor competing with other apps), it doesn’t matter what the network can do. Given how tightly handset vendors and service providers have worked historically and despite the trend for device openness, I think this will be something solved by that cooperation.
Kevin - I agree, I'm expecting to see some cooperation to help solve this.
However, there are some issues here - especially with non-operator devices like PCs or "vanilla" smartphones or tablets bought unsubsidised through retail. In those cases, there is no reason why voice should pre-empt other apps by default; the "prioritisation engine" would be controlled by the user.
Moreover, it seems that any cooperation is (a) outside the remit of any of the current standards bodies, (b) likely to be proprietary in nature, (c) perform differently with different OS's and processors, and (d) take several years to get into handset platforms, and then ultimately the market.
It would be nice to see someone take "ownership" of this problem, in contrast to previous attempts at creating/defining IMS handsets.
In an ideal world, this process would have started 4-5 years ago - and not (as I suspect) 2 years in the future.
Post a Comment