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 see recent presentations, and discuss Dean Bubley's appearance at a specific event, click here

Thursday, February 06, 2014

The big problem for VoLTE...

... is that there are at least 10 completely separate problems for VoLTE.

I've long said that VoLTE is a good idea in principle (ie having a standardised "plain vanilla" carrier telephony service for wireless IP networks). Over six years ago, I predicted this was necessary, but would face many practical difficulties, so getting started ASAP was important, even on old HSPA networks before LTE.

It took years before fixed VoIP worked well. It was invented around 1997, but it was a least 7 years later that it even started to be reliable on enterprise Gigabit Ethernet LANs, where the CIO was free to use whatever equipment and QoS tools were needed. The first carrier broadband VoIP was launched by Softbank Yahoo in Japan in 2002. Twelve years later, we're still at less than 30% replacement of global circuit PSTN today.

The idea that adding not just cellular and mobility, but a completely new radio, RAN & EPC architecture to the mix would make 4G VoIP any quicker to launch/deploy/adopt is wishful thinking of the highest order.

And so it goes.

I keep getting pitched by vendors with solutions to bits of the VoLTE puzzle I hadn't even realised existed. Yesterday was the turn of Stoke, talking about latency inside routers and gateways from packets having multiple hops between functional blades doing DPI, encryption, routing and so on. Apparently the impact on small packets (step forward, voice calls) is particularly bad. I'm not a router-architecture specialist, but it sounds plausible. Apparently it's also a problem that will get worse as NSA-inspired paranoia inspires telcos to put harder crypto in various bits of their IMS/voice networks in future. 2048bit-wrangling won't be quick or easy, especially if it needs to be done sequentially with all the other functions in the chassis.

I'm just adding that to the ever-growing list of serious obstacles that VoLTE faces in actually getting to widespread launch and adoption.

An incomplete list of VoLTE's problems, some technical & some non-technical, includes:

- LTE coverage & capacity being good enough (including indoors)
- LTE backhaul being good enough
- SR-VCC not working very well
- Handset availability
- Handset battery life
- Handset client UI
- The need for some sort of IMS platform & all that entails
- Roaming- 911 / 999 / 112 emergency calling
- Internal VoLTE network security (vs hacking, DDoS etc)
- Integration with billing & OSS & support systems
- Multiple layers of QoS mechanisms, from the radio to the core
- DIAMETER to handle all the signalling from all of the above bits & pieces
- Making all the "furniture" like ringtones & voicemail work OK
- API exposure platforms if needed
- Handoff back to 2G/3G circuit (& coverage, RF etc etc)
- The normal interop issues between vendors' & OEMs' gear
- How does a VoLTE MVNO work, exactly? (Anyone heard of one? No, me neither)

Oh, and if fixed-VoIP is anything to go by, we'll probably be dealing with a host of new & exciting acoustic failure modes that require a black-belt network & device media-engine ninja to diagnose.

Most of these issues are completely orthogonal to each other - and are being fixed by vendors who are probably mutually unaware of the existence of each other, or each other's problems. The likelihood of inter-dependence is probably high. All the fun new stuff coming down the 4G/5G pipeline like coordinated multi-point networks, small cell overlays, carrier aggregation & so forth probably won't help either.

Meanwhile, in most advanced markets there is now flat or declining demand for vanilla telephony (& revenues/profit associated with it), even in perfectly-working GSM guise. Except where previous high prices & elasticity means a bit of latent demand still lurking, usage minutes are going to fall in future. And no, so-called "HD" voice won't make a blind bit of difference - it's available for 3G already, if it mattered that much ,and it doesn't.

In other words, VoLTE is now very late, with new problems emerging all the time, which are likely to be ever more expensive to fix. It's serving a declining market for a 120-year old product that consumers are starting to desert and dislike. It's based on a clunky, expensive and complex application platform (IMS) which isn't fit for the 21st century's communications trends. And all the old networks & CS systems will need to be kept in place for at least a decade (maybe two) in most countries, adding to the overall OPEX.

Not pretty.

And in other news, I've had inbound calls on both FaceTime Audio and Skype on my LTE iPhone in the last couple of days. Both needed a couple of seconds juggling with the UI to unlock the screen & answer the call, but seemed to work fine (with HD & optional video, obviously) once they got going. And I'm not even going to mention WebRTC's inevitable rise over the next couple of years.

I'm sure we'll hear lots about VoLTE in Barcelona. But as of yesterday there were 268 LTE networks operating in 100 countries (source: GSA), yet I count only 4 "proper" VoLTE (3 Korean telcos + MetroPCS) launches and a couple of press-release face-savers. That's a big enough red flag.

So, how many more "big problems" still need to be fixed for VoLTE? That's the problem. We don't know. And worse, most of the problem-solvers don't even know each other. I wouldn't want to be a vendor dependent on this space, as you're relying on many many other peoples' ingenuity rather than your own. I'd be investigating alternative sources of business too.

13 comments:

Jan Sladky said...

Dean,
I'm not so pessimistic as you - realistically I see just one big problem: "interop issues between vendors" - SIP evil is hidden in details, like npdi, rn, forking, ...

The rest you talk about is just normal telecom stuff that just needs some time to get it running.

- SR-VCC not working very well:JUST MATTER OF SHORT TIME TO GET IT READY
- Handset availability: MATTER OF SHORT TIME - testing possible with S3,S4,Z1,G1.
- Handset battery life: VOLTE UE HAS BETTER BATTERY LIFE.
- Handset client UI: IRRELEVANT
- The need for some sort of IMS platform & all that entails; OF COURSE
- Roaming- 911 / 999 / 112 emergency calling: EASY
- Internal VoLTE network security (vs hacking, DDoS etc); NORMAL PROTECTION LIKE ANY OTHER
- Integration with billing & OSS & support systems: EASY
- Multiple layers of QoS mechanisms, from the radio to the core: YOU CARE MOSTLY ABOUT EPC QoS only - NOT DIFFICULT
- DIAMETER to handle all the signalling from all of the above bits & pieces: NOT DIFFICULT
- Making all the "furniture" like ringtones & voicemail work OK: NOT DIFFICULT
- API exposure platforms if needed: WHAT YOU MEAN ? OTHERWISE JUST BUZZ-WORDING
- Handoff back to 2G/3G circuit (& coverage, RF etc etc): NOT UNDERSTOOD - YOU HAVE SRVCC
- The normal interop issues between vendors' & OEMs' gear: ONLY POINT YOU ARE RIGHT
- How does a VoLTE MVNO work, exactly? (Anyone heard of one? No, me neither) SEVERAL MODELS EXIST - NOT DIFFICULT, NOT EVEN WITH THE MVNO USING LEGACY IN VIA IM-SSF

regards, Jan

Dean Bubley said...

Nice try Jan. Try to leave the IMS fanboysism at the door next time.

I notice you missed the LTE coverage issues, which actually are #1 at the top of the problem list.

Ironically, interop is not a "big problem" - that's the classic "normal telecom stuff" that network people deal with - the easy stuff.

The big problems here are at the application level. Your comment that handset client UI is "irrelevant" is truly laughable. Unless and until the user experience IN THE HANDS OF THE USER is worthwhile, the rest of it will never have a chance to show if it works or not.

This is the core problem with IMS - it left the "UE" as a small undescribed box in the bottom-left hand corner of the architecture diagram, despite it being where 70-80% of the complexity & value resides. That was true in 2006, and even more so in 2014, given the evolution of communications apps and user behaviour in the interim.

Similarly, QoS and packet-scheduling in the RF domain is MUCH more important than EPC.

As for VoLTE "UE" has better battery life... that's total BS. Especially as in most cases the VoLTE stack & client needs to run on the apps processor, not the baseband.

API platforms are necessary for VoLTE if it has any chance of generating fresh revenue, rather than just being extra cost. Plain-vanilla phone calls are in decline. Unless operators enable new voice applications to be created, the whole concept of VoLTE is just a "distress purchase" to enable old telephony to carry on working.

I'm guessing you're a core networks guy? You need to recognise that the hard parts of mobile are on the device, and RF domains. The network bit is easy by comparison.

Dean

Anonymous said...

Hello,

dear Dean, please be more polite. Too much agrressivness in your post.


I think you are missing some info. Delivering QoS in LTE and EPC world is much easier than at 3G. Most of the carriers already installed PCRF and are implementing diamiter routers (even for the sake of LTE roaming).


Most of the parts are easy, really, normal telco stuff. Even battery problem. Frankly speaking its ADVENTAGE. VoLTE will be "hardcoded" Did you read that?
http://www.fiercewireless.com/tech/story/st-ericsson-battery-issues-not-problem-newer-volte-devices/2013-01-02

This means that OTT will have problems, not operators. This will be volte adventage.

Jan Sladky said...

Dean,¨

with all respect - I think that you are not right in 80% of your arguments. Once again:

LTE coverage - and what ? you have SRVCC, area of coverage is not important (and is still growing)

Handset UI: there is simply no problem with UI as the UI is still the same - there is just one more item in the setting: "Use VoLTE when availble". That's it. You don't type any APN as there is no APN configured in UE, you don't care about access network, you just use your VoLTE phone.(I don't know if you ever had a VoLTE phone in your hands. If I did did not get your point, then I'm sorry.) If you would talk about underlaying functions and SIP then it would be slightly different story but definitely not critical. BTW. China Mobile launched live VoLTE with eSRVCC in Shenzhen district this January.

Interop is quite an issue - if you wait several months to fix an issue between to well known telco suppliers and if you done't have just one such issue, then interoperability as a PROBLEM.

QoS once again: there is no special QoS configuration on RF for VoLTE - everything is handled from EPC - the bearers are between eNodeB and the P-GW and this stuff is not a "problem". But I may be wrong.

Once again. The VoLTE UE has better battery life.

API platforms necessary for VoLTE - nice buzzword ;-) but who knows, may be you are right.

Yes, I'm core network guy - you must know, if you checked my profile on linkedin ;-)


Summary - you described 15 VoLTE problems, but it seems that just 1-2 are really relevant.

regards, Jan

Dean Bubley said...

Anonymous: "Be more polite". Thanks for the advice, but I take a confrontational tone because that's what gets me noticed.
As a solo analyst/consultant I need to be forthright and occasionally offend people by pointing out their flaws and problems. Being correct but invisible would not earn me any money.

However, in private consulting & advisory settings, I can obviously adopt a different tone. If you'd like to hear me being "non-aggressive", I suggest you get your employer to hire me for an internal project or workshop.

Delivering QoS in LTE is (partly irrelevant), firstly because the gating factor in overall QoE will relate to coverage, but also because the QoS/PCRF suppliers continually suggest they can offer those features to 3rd parties like OTT players, as well as internal applications like VoLTE. (regulation permitting). Are they lying? Is the idea of selling QoS to OTT players a total fraud then?

This also completely misses the point (again) that many of the so-called OTT players are *better* than VoLTE because of functionality or user-interaction for specific use-cases.

Voice comms will come in a 1000 different varieties & use-cases. Phone calls (whether CS or VoIP/VoLTE) only cover a few of those.

As for that article about power consumption, you're being selective. Try this one from a senior director at Qualcomm, published 3 months later: http://www.telecoms.com/136672/changing-the-conversation/

"while the complexity of VoLTE might not mark it out as unique, it is hardly trivial. Problems with power consumption in the device, inefficiencies inherent in the LTE standard (due in part to its immaturity), interoperability and roaming challenges all combine to mean that VoLTE will “take years to work out, not months,” Carson says"

Dean Bubley said...

Jan

Firstly, thanks for the China Mobile heads-up.

Obviously time will tell, but I think the fact we've seen so few VoLTE launches after 4 years of LTE suggests it's difficult.

Read the link with the Qualcomm guy I linked to in the previous comment - surely a company that would *love* VoLTE to happen faster as it drives demand for mobile chipset capability.

SRVCC - complex, disliked, adds latency & cost & more interoperability issues, plus also means that 2G/3G coverage has to overlap precisely with holes in LTE.

UI - depends if it's done purely as an invisible CS telephony replacement, or if the operator is trying some new "multimedia communicator" approach with video or messaging etc integrated. The latter has huge scope for design errors, especially if it tried to incorporate RCS.

UE battery life - remains to be proven, and will likely depend on the specific implementation. Also will depend whether there's additional app/UI elements running on the apps processor.

QoS on radio is *hard* and will need lots of work on compromises, especially where the user is at the edge of a cell. Also don't forget that uplink & downlink involve different problems, and QoS can't do much about RF interference either.

Plus network QoS doesn't help you deal with the acoustic glitches and flaws when packets ARE dropped and delayed. This is where Skype & Google have years of experience - echo cancellation, noise suppression, forward error correction, packet loss concealment etc. Yet the original IR92 document did not even include the word "acoustic"!!!

It's no good just saying "prevention is better than cure" (ie QoS) with VoIP. You need an acoustic "cure" as well, because packets WILL get dropped or delayed. This stuff is *hard* and probably has all sorts of new & interesting effects from mobility.

Oh, and I forgot to mention cell-too-cell handoff performance (especially if one is a small cell). That took plenty long enough for 3G voice telephony to fix, so I can't imagine it's any easier here.

And, lastly, there's still the business case problem. Telephony is a creaky 120-year old product that is being substituted by new behaviours & alternative services/features. Together with competition & regulation, prices are falling, along with profitability. What's the justification for CFOs to spend money for a near-end-of-life service?

Jan Sladky said...

Dean,

not having much time as working on VoLTE, therefore just briefly:

1. so few VoLTE lunches so far- I'm not surprised, it just needs time - same time as switch from analog mobile networks to GSM. There is lot of work that has to be done - with VoLTE you overlay all three domains - CS, PS and IMS. UE must be powerful enough (quad processors)


2. I will read it, thanks

3. SRVCC - latency is about 200ms - it is actually no latency for handover

4. UI - I have VoLTE Samsung Galaxy S4 - you can't recognize it is VoLTE. As far as I know there is no " new communicator". Otherwise I understand.

5. battery life - I'm just trying to find the slides from Verizon showing better battery life of VoLTE UE


6. QoS on radio - according to me still not big issue, VoLTE also has a better results then Skype in poor coverage, including user experience (acoustic glitches) I will try come with more info soon

Dean, maybe you underestimate VoLTE - VoLTE behaves very good on radio, surely better then Sype - I have a measurements from our radio guys.

Don't forget there is Robust Header Compresion between UE and PDN-GW that makes the over on RTP/UDP/IP packect from 40-60bytes to just 3-4bytes. Sound is not definitely an issue, at least so far.

You must be provocative, I understand but VoLTE is not end of life service - it is a future of comunications ;-)

Check what is going on in AT&T and Verizon, China mobile - you think their CEOs are crazy ?

regards, Jan

Dean Bubley said...

Jan

Yes, CEOs often make mistakes.

AT&T certainly seems to do "crazy" things - see its recent "sponsored data" launch as an example. T-Mobile US's John Legere has had a few choice words about the CEO too. They'd expected to launch VoLTE in 2013 originally, so that target has been missed already.

As for Verizon, they originally demo'd VoLTE in Feb 2011 (more than 3 years ago!) and promised commercial launch in 2012. I'll leave it up to you to decide the credibility & capability of execs who failed to predict a 2+ year delay. http://www.verizonwireless.com/news/article/2011/02/pr2011-02-09f.html

Clearly, VoLTE IS difficult, or else we would have had it launched by now. Sure, the various big problems will EVENTUALLY be fixed... probably.

And when it is finally deployed, it still faces the reality that we're now past "peak telephony" and on the way back down.

Anonymous said...

Dean, you always rubbishing out IMS but what is the alternative? The Operators have an obligation to maintain quality of service,emergency service and of course the LI stuff. How do you propose to do that with OTT/Webrtc???

Dean Bubley said...

Alternatives to IMS:

- NGN SIP, as used on many fixed networks
- Decouple the control layer of IMS from applications & treat each completely separately, with APIs between them which can also be addressed by alternative systems
- Move to a WebRTC-type model where "on the wire" protocols are stipulated, but signalling left up to the application
- Move to an OTT model + exposed QoS/policy APIs from network layer

No reason that 911/LI can't be done in that model as well - or even be offered as a wholesale managed service.

The other thing is to engage regulators to *change* the rules. A complete rethink of emergency comms is decades overdue, in particular. At the moment, most regulaory lobbying is defensive ("stop those guys doing XYZ") rather than liberalising ("let us do it that way too")

InfoStack said...

Dean is there a distinction in coverage between radio and application? Meaning is the usable distance/coverage smaller for VoLTE than the 4G radio for other IP sessions/apps? And corresponding TDM voice in 3G? Just asking because I heard rumor to that effect and wanted some clarity. It might be another (big) reason and not just lack of geographic 4G coverage.
ME

Dean Bubley said...

Infostack - yes, VoLTE will likely be quite demanding in terms of "suitable coverage".

Ericsson has an idea of "app coverage" which is quite a good way of visualising the problem, although it mostly focuses on speed/throughput rather than latency and jitter I think.

I'm not sure exactly how the algorithms for packet scheduling in LTE work (especially at cell-edge) but there's probably something that allocates radio resource to users with the best transient connection strength / least interference. I'm sure reliability & consistency reduce the further you are from the cell-site.

Unknown said...

The biggest issue to date has to be idle reselection due to mobility between the 4G and 3G/2G layers. I'm not talking about srvcc that's the easy bit. Default behaviour for a VoLTE device in 3G is to DEREGISTER and then on most occasions come back up to 4G and register again ... all this movement causing authentication and IPSec establishment which has massive bearing on the network. That action in and old 3G network is the same as users power cycle there phone on every RAT change ... crazy eh? Ok ran optimisation but that will never get to a place of stability unless we remove other RATs but it's not possible during this period of change .... any thoughts ?