Timing is everything: Why telecom industry visions get it wrong

Introduction

One of the things I find most frustrating about technology forecasts and visions – especially in telecoms and mobile – is the lack of awareness of adjacent issues and trends, or consideration of "gotchas" and alternative scenarios.

So for example, when telcos, vendors or policymakers predict what 5G deployment, or network-slicing, or edge-computing or anything else might result in – applications, uptake, revenue opportunities and so on – they often fail to ask two critical questions:

• Distractions: What are the prerequisites for this to happen? What are the bits of the overall wider system that are forgotten but necessary, to make the headline technology feasible and useful? And when will they be achieved? What's the weakest link in the chain? Is delay inevitable?

• Disruptions: What else is likely to happen in the meantime, which could undermine the assumptions about demand, supply or value-chain structure? What's going on in adjacent or related sectors? What disruptions can be predicted?

This post has an accompanying podcast, on my SoundCloud:

Internal distractions & pre-requisites

So for example, for 5G to be successful to the degree that many predict (“trillions of $ of extra GDP”, millions of extra jobs etc) there first needs to be:

• Almost ubiquitous 5G coverage, especially indoors, in sparse rural areas, and in other challenging locations
• Enough fibre or other backhaul connectivity for the cell-sites
• Suitable software and hardware platforms to run the virtualised core and other elements
• Enough physical sites to put antennas, at low-enough costs & with easy-enough planning
• Many more engineers trained and qualified to do all of the above
• A decent business case, for instance in remote areas
• 3GPP release 16 & 17 to be completed, commercialised and deployed, especially for the ultra-low latency & high-reliability applications.
• Optimisation and operational systems, perhaps based on as-yet-unproven AI

Yet vendors and policymakers often gloss over these "annoying" practicalities. There seems to be an attitude of “oh, they’ll have to make it work somehow”. Well, yes, perhaps they will. But when? And at what cost? What changes does that imply? How will the gaps and limitations be bridged? And what happens if firms go bust while waiting for it all to happen? What other ways to solve problems can users pursue sooner, that don't involve 5G?

A key implication of this is that timing and profitability of massmarket adoption is often much later than expected. While Amara's Law might eventually apply (we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long term), that doesn't mean that early initial adopters and investors make the returns they'd hoped for.

External disruptions and substitutes

Perhaps even more pernicious is the lack of situational awareness about parallel developments elsewhere in the broader tech ecosystem. These undermine both demand (as alternative solutions become viable in place of the hoped-for technology) and supply / operation (by throwing up new complexities and gotchas to deal with). 

These are often not just “what ifs" but “highly likelies” or "dead-on certainties".

So for instance, the visions of network slicing, or edge-computing for 5G (which will really only crystallise into large-scale commercial reality in maybe 4-5 years) will have to contend with a future world where:

• 5G networks are still patchy. There will still be lots of 4G, 3G and “no G” locations. What happens at the boundaries, and how can you sell QoS only in certain places?
• There will be a patchwork of “uncontrolled” locations – they might be 5G, but they could be owned by roaming partners, indoor network providers, private localised cellular operators and so on. How will a slice work on a neutral-host's network?
• An ever-greater number of devices spend an ever-greater amount of time on Wi-Fi – usually connected to someone else’s fixed-line infrastructure and acting as either uncontrolled, or a direct arbitrage path. 
• Telcos have to cap their energy use and associated CO2 emissions, or source/generate clean power of their own.
• Wi-Fi 6 will emerge rapidly & is hugely improved for many use-cases, but most 5G predictions only compare against legacy versions
• Hardware based on "commodity hardware" runs against the current tide of semiconductor fragmentation and specialisation (see recent post, here)
• Devices will often have VPN connections, or use encryption and obfuscation techniques, which means the network won't be able to infer applications or control traffiic.
• Users and devices will use multiple connections together, either for arbitrage, aggregation, or more-sophisticated SD-WAN type models.
• Pricing, billing, customer support and security will be challenging on "federated" 5G or edge-compute networks. Who do you call when your network-slice doesn't deliver as expected - and how can they diagnose and fix the problem?
• Liability and accountability will become huge issues, especially if 5G or slicing is used for business-critical or life-critical functions. Are your lawyers and insurers prepared? 
• AI will be used for instant price-comparison, quality monitoring & fault reporting, collective purchasing and even contractual negotiations. "Hey, Siri, mimic my voice and get me the best discount possible with the customer-retention agents"

These are just some basic examples. Once you get into individual verticals, particular geographies or even specific companies, a whole host of other issues start to crop up  - sector regulation, value-chain shifts, government involvement, expectations of 20-30 year tech cycles and so on. Sure, in theory 5G might fit into various industries' own transformation journeys - but they won't design around it.


Conclusions

I find this all very frustrating. So many company boards, strategy departments or lower-level product/service management teams seem to operate on the basis of "all other things being equal..." when the one certainty is that they won't be. 

So the two sets of factors tend to be multiplicative:

• Distractions are internal to a new concept, and lead to delays in technology launch, market maturity and revenue.
• Disruptions are external and often inevitable, but any extra delay increases their range and impact yet further.

It's never possible to predict everything that might get delayed, or every possible disruption from adjacency. But it seems to me that many companies in telecoms don't even bother to try. 

Companies accept the "hype cycle" as inevitable, even if it might be possible to flatten it out.

By coincidence, while writing this post I started reading "Range" by David Epstein (link) which talks about the importance of "analogising widely", and the risks of narrow expertise and superficial analysis, rather than looking for implications of cross-sector / cross-discipline similarities and lessons. 

When evaluating new technologies and service concepts, CEOs and CFOs need to rely less on familiar industry echo-chambers and consensus hype, and instead seek out critics who can find hidden assumptions, both internal and external to their plans. This isn't just a negative exercise either - often, a "ranging" exercise throws up unexpected positives and opportunities from adjacency as well risks.



This post has an accompanying audio podcast - click here & please subscribe!

 
Footnote
 
I sometimes get asked to "stress test" ideas and plans, and help companies avoid expensive mistakes, get started on future glitches today, or prepare for and avoid contingencies and unintended consequences. 

Often, that exercise will throw up new opportunities as well. Usually, a collaborative (but candid) group workshop ensures this isn't a blame-game, but a path to smoother growth and innovation. The skills and mindsets can be learned and replicated, too.

If that type of approach sounds interesting, please get in touch with me, either by email (information AT disruptive-analysis DOT com) or via LinkedIn (link).

Publications & Upcoming Events

This is an "administrative" post, covering my recent and upcoming publications & events. Please get in touch if you'd like any more details about booking me for speaking/workshops, or for considering published output - information AT disruptive-analysis DOT com.


Events
I speak at, or attend, about 30 public events per year, plus a number of private workshops, executive off-sites and online webinars. Recent notable events have included:

• Keynote on Futurism at Ofcom's spectrum workshop day (link)
• Presenting at TMForum's Action Week (on blockchain - link)
• Keynote on new wireless & spectrum models at WiFi Now in Washington DC (link)
• Chairing Total Telecom's Connected Britain event
• My own workshops, run jointly with Caroline Gabriel, on Enterprise/Private Cellular Networks, and AI + Blockchain for the Telecoms Industry (link)

The next few months are looking pretty hectic for events I'm speaking at, attending or moderating. My schedule always a bit of a work-in-progress, and some things may change a bit, so please get in touch with me if you want to arrange meetings/briefings, or need a speaker for other events. 

• 3 Sep, London, London Futurists: Agenda for the Future (link)
• Presentation: "Anti-Forecasting"
• 4-7 Sep, Shanghai, Huawei Connect (link)
• Attending as an analyst
• 18-19 Sep, Bangkok: PTC Spectrum Futures (link)
• Presentation: "A Futuristic View of Spectrum: Where Are We Going?"
• CBRS Workshop
• 25-27 Sep, Busan, S Korea: ITU Telecom World (link)
• Panel Moderator: Reinventing Telcos
• 3-5 Oct  Orlando, US: Astricon (link)
• Keynote on "What the Future Holds for Asterisk - And What's Overhyped"
• 5 Oct (TBA), Webinar: IBwave (link to follow)
• Presenting on Convergence & Evolution in Indoor Wireless
• 11-12 Oct, Brussels: IICom Annual Conference (link)
• Presenting on "Innovation in connectivity technologies - embracing heterogeneity"
• 23-24 Oct, Phoenix, US: Broadsoft Connections (link)
•  Attending as an analyst
• 25-26 Oct, San Francisco: GE Minds & Machines (link)
• Attending as an analyst
• 31 Oct - 1 Nov, London: Total Telecom Congress (link)
• Speaking "Optimising Spectrum Regulation in the 5G era"
• Chairing Day 2
• 02 Nov, The Hague, Netherlands: WiFi Now Europe (link)
• Keynote + Panel
• 14-15 Nov, Lisbon: TADSummit (link)
• Presenting on Enterprise & Industrial IoT mobile networks
• 28-29 Nov, Bangkok: WiFi Now APAC (link)
• Keynote + Panel
• 30 Nov, London: Great Telco Debate (link)
•  Speaker, topic TBA
• 01 Dec, London DB + CG Private Cellular Workshop #2 (link to follow)
• 1-day workshop on Enterprise / Private mobile networks
• Contact: information AT disruptive-analysis DOT com for details

Publications

For my written output, I work through three main channels:

• This blog and cross-posts on my LinkedIn & Medium. Recent topics have included:
• Blockchain/ICOs (link and link)
• Mobile connection bonding & SD-WAN (link)
• Net Neutrality (link)
• Sensors (link)
• Amazon / Edge-Computing (link)
• Data-over-Sound (link)
• UCaaS (link)
• Spectrum Sharing / Enterprise Cellular (link)
• STL's Future of The Network research stream, which I run as associate director. My own recently-contributed reports include: 
• Facebook's Telecom Infra Project (link)
• Edge Computing (link)
• VoLTE (link)
• 5G Spectrum (link)
• eSIM (link)
• Other reports in the stream written by others have covered 4G in Asia, NFV and other topics. 
• My next reports will look at LPWAN, cRAN/vRAN, and WiFi's strategic implications for Telcos.
• Disruptive Analysis branded reports & papers, which include both open-market reports such as last year's eSIM study (link), and client-commissioned papers - some of which are internal and kept under NDA. Recent public documents include
• Blockchain for Telcos, written for Juniper Networks (link)
• Integrating IoT & Video Comms, written for Dialogic (link)
• Data-over-Sound, written for Chirp (link)
• IoT + Voice/Messaging Comms, written for Metaswitch (link) 
• Upcoming paper on consumer communications privacy

TelcoFuturism: Will AI & machine-learning kill the need for network QoS?

Following on from my introductory post about TelcoFuturism (link), this is a forward-looking "what if?" scenario. It arises from one impending technology intersection - the crossover between network policy-management, real-time applications (especially voice & video) and machine-learning/artificial intelligence (AI)

One of the biggest clichés in telecoms is that every new network technology allows the creation of special "quality of service" characteristics, that potentially enable new, revenue-generating, differentiated services. But while QoS and application-based traffic-engineering certainly is useful in some contexts - for example, managed IPTV on home broadband lines, or prioritisation of specific data on enterprise networks - its applicability to a wider audience remains unproven. 

In particular, end-to-end QoS on the public Internet, paid-for by application or content providers and enforced by DPI and in-network policy engines, remains a fantasy. Not only does Net Neutrality legislation prohibit it in many cases, but the concept is an undesirable and unworkable fallacy to begin with. 

App-specific QoS doesn't work technically on most shared networks (ask colleague Martin Geddes, who'll enlighten you about the maths of contention-management). There's no way to coordinate it all the way from server-to-user-access. While CDNs and maybe future mobile edge nodes might help a bit, that's only a mid-point, for certain applications. On mobile devices, the user is regularly using one of millions of 3rd-party WiFi access points, over which the app-provider has no control, and usually no knowledge. The billing and assurance systems aren't good enough to charge for QoS and ensure it was delivered as promised. Different apps behave differently on different devices and OS, and there's no native APIs for developers to request network QoS anyway. And increasing use of end-to-end encryption makes it really hard to separate out the packets for each application, without a man-in-the-middle.

There's also another big problem: network quality and performance isn't just about throughput, packet-loss, latency or jitter. It's also about availablility - is the network working at all? Or has someone cut a fibre, misconfigured a switch, or just not put radio coverage in the valley or tunnel or basement you're in? If you fall off of 4G coverage back to 3G or 2G, no amount of clever policy-management is going to paper over the cracks. What's the point of 5-9's reliability, if it only applies 70% of the time?

Another overlooked part of QoS management is security. Can DDoS overload the packet-scheduling so that even the "platinum-class" apps won't get through? Does the QoS/policy infrastructure change or expand the attack surface? Do the compromises needed to match encryption + QoS introduce new vulnerabilities? Put simply, is it worth tolerating occasionally-glitchy applications, in order to reduce the risks of "existential failure" from outages or hacks? 

There are plenty of other "gotchas" about the idea of paid QoS, especially on mobile. I discussed them in a report last year (link) about "non-neutral" business models, where I forecast that this concept would have a very low revenue opportunity.

There's also another awkwardness: app developers generally don't care about network QoS enough to pay for more of it, especially at large-enough premiums to justify telcos' extra cost and pain of more infrastructure and IT (and lawyers). 

While devs might want to measure network throughput or latency, the general tendency is to work around the limitations, not pay to fix them. That's partly because the possibility isn't there today, but also because they don't want to negotiate with 1000 carriers around the world with different pricing schemes and tax/regulatory environments (not to mention the 300 million WiFi owners already mentioned). Most would also balk at paying for networks' perceived failings, or possibly to offset rent-seeking or questionable de-prioritisation. Startups probably don't have the money, anyway. 

Moreover - and to the core of this post - in most cases, it's better to use software techniques to "deal with" poor network quality, or avoid it. We already see a whole range of clever "adaptive" techniques employed, ranging from codecs that change their bit-rate and fidelity, through to forward error-correction, or pre-cacheing of data in advance if possible. A video call might drop back to voice-only, or even messaging as a fallback. Then there's a variety of ways of repairing damage, such as packet-loss concealment for VoIP. In some cases, the QoS-mitigation goes up to the UI layer of the app: "The person you're talking to has a poor connection - would you like to leave a voicemail instead?"

And this is where machine-learning and AI comes in. Because no matter how fast network technology is evolving - NFV & SDN, 5G, "network-slicing" or anything else - the world of software and cognitive intelligence is evolving faster still. 

I think that machine-learning and (eventually) AI will seriously damage the future prospects for monetising network QoS. As Martin points out regularly, you can't "put quality back into the network" once it's lost. But you can put quality, cognitive smarts or mitigation into the computation and app-logic at each end of the connection, and that's what already occurring and is about to accelerate further.

At the moment, most of the software mitigation techniques are static point solutions - codecs built-into the media engines, for instance. But the next generation is more dynamic. An early example is that of enterprise SD-WAN technology, which can combine multiple connections and make decisions about which application data to send down which path. It's mostly being used to combine cheap commodity Internet access connections, to reduce the need to spend much more on expensive managed MPLS WANs. In some cases, it's cheaper and more reliable to buy three independent Internet connections, mark and send the same packets down all of them simultaneously, and just use whichever arrives first at the other end to minimise latency. As I wrote recently (link), SD-WAN allows the creation of "Quasi-QoS".

Furthermore, an additional layer of intelligence and analytics allows the SD-WAN controller (sitting in the cloud) to learn which connections tend to be best, and under which conditions. The software can also learn how to predict warning-signs of problems and what the best fixes are. Potentially it could also signal to the app, to allow preventative measures to be taken - although this will obviously depend on the timescales involves (it won't be able to cope with millisecond transients, for instance).

But that is just the start, and is still just putting intelligence into the network, albeit an overlay.

What happens when the applications themselves get smarter? Many are already "network-aware" - they know if they're connected via WiFi or 4G, for example, and adapt their behaviour to optimise for cost, bandwidth or other variables. They may be instrumented to monitor quality and self-adapt, warn the user, or come up with mitigation strategies. They have access to location, motion-sensor and other APIs, that could inform them about which network path to choose.

But even that is still not really "learning" or AI. But now consider the next stage - perhaps a VoIP application spots glitches, but rather than an inelegant drop, it subtly adds an extra "um" or "err" in your voice (or just a beep) to buy itself an extra 200ms to wait for the network to catch up? Perhaps it is possible to send voice-recognised words and tone to a voice-regenerating engine at the far end, rather than the modulated wave-forms of your actual speech?

Or look forward another few years, and perhaps imagine that you have a "voice bot" that can take over the conversation on your behalf, within certain conversational or ethical guidelines. Actually, perhaps you could call it an "ambassador" - representing your views and empowered to take action in your absence if necessary. If two people in a trusted relationship can send their ambassadors to each others' phone, the computers can take over if there's a network problem. Your "mini-me" would be an app on your friend's or client's device and create "the illusion of realtime communications".
   
Obviously it would need training, trust and monitoring, but in some cases it might even generate better results. "Siri, please negotiate my mobile data plan renewal for the best price, using my voice". "Cortana, please ask this person out on a date, less awkwardly than I normally do" (OK, maybe not that one...)

Investment banks already use automated trading systems, so there are already examples of important decisions being made robotically. If the logic and computation can be extended locally to "the other end" - with appropriate security and record-keeping - then the need for strict network QoS might be reduced. 

Machine-learning may also be useful to mitigate risks from network unavailability, or security exploits. If the app knows from past experience that you're about to drive through a coverage blackspot, it can act accordingly in advance. The OS could suggest an alternative app or method for acheiving your underlying goal or outcome - whether that is communication or transaction - like a SatNav suggesting a new route when you miss a turn.



For some applications, maybe the network is only used a secondary approach, for error-correction or backup. In essence, it takes the idea of "edge computing" to its ultimate logical extension - the "edge" moves right out to the other user's device lor gateway, beyond the network entirely. (This isn't conceptually much different to a website's JavaScript apps running in your browser). 

Obviously, this approach isn't going to work ubiquitously. Network QoS will still be needed for transmitting unpredictable real-time data, or dealing with absolutely mission-critical applications. Heavy-lifting will still need to be done in the cloud - whether that's a Google search, or a realtime lookup in a sales database. Lightweight IoT devices won't support local computing and maintain low power consumption. But clever application design, plus cognitively-aware systems, can reduce the reliance on the access network for many cases. It could just be argued that this is just a lower quality threshold, but at a certain point that coincides with what is routinely available from a normal Internet connection, or perhaps two or three bonded or load-balanced together.

But overall, just as we expect to see robots taking over from humans in "automatable jobs", so too will we see computation and AI taking over from networks in dealing with "automatable data". The basis for the network "translocating" data becomes less of an issue, if the same data (or a first-approximation) can be generated locally to begin with.