New: Future of Video & RTC Workshop Series, starting May 19th

 "Why do people make phone calls?"

... the opening question at my old Future of Voice workshops. 

 It stumped many attendees and also many of my telco consulting clients during private engagements.

Most just looked blank, or perhaps suggested "to speak to people?". To be fair, the answer isn't obvious. Which is rather odd, given the need or desire for phone calls is the basis for the entire industry.

Few people think broadly about "purpose" of communications. What is the participant trying to achieve? How does the service or application help them do that? How can it be improved? What are the real sources of value?

In reality, there are 100s of uses for phone calls: To get information. Catch up with a friend. Buy something. Complain. Get help. All deserve a different, optimised experience. Yet a phone call is basically a one-size-fits-all, common denominator product. 

Telco's don't do "voice". They just do "telephony" - a single 140-year old, clunky, unnatural, heavily-regulated voice applications

Instead, they should have considered the 1000s of types of voice communication that are NOT phone calls. Audio chat, push-to-talk, karaoke, voice assistants and so on. All designed for particular purposes, with user-interaction models and technology stacks. Some dependent on the network, some on apps, some on devices, some in learned human behaviour.

The same is happening now for video. It's more than just video conferencing.

It's training, collaboration, security, education, medicine, machine vision, infra-red, social broadcast or 1000s of other uses, applications & business models.

There are platforms, enablers & APIs. Developer tools & design & test capabilities. WebRTC is important but not alone.

If telcos, service-providers, cloud/platform players, developers, enterprises and investors really want to understand the value and timelines for future communications - they need to ask the real questions. Not get blinded by ancient standards, or regulatory mandates to measure things in "minutes".

RTC (realtime communications) is getting more complicated, diverse - and has huge opportunities, as well as risks to incumbent providers of old/poor products. We all know which are the good/bad WFH conferencing products, or messaging services these days. 

What does the future bring? New models for UCaaS & cPaaS? Innovative video services for the smart home? New audio drop-in chat apps? AR/VR conferencing? What are the impacts of 5G, edge-computing and AI?

So I'm announcing: 

A new 3-part / 2-timezone "Future of Video & RTC" workshop series with WebRTC maven Tsahi Levent-Levi from May 19th. Early-bird rates end soon.

 

Sign up here.

 

Voice: So much more than Phone Calls

 [Originally published on LinkedIn. Please subscribe to my new LinkedIn Newsletter here]

Trivia Question: When was the first example of network-based music streaming launched?

I'll bet many of you guessed that it was Spotify in 2006, or Pandora in 2000. Maybe some of you guessed RealAudio, back in 1995.

But the actual answer is over a century earlier. It was the Théâtrophone, first demonstrated in 1881 in Paris, with commercial services around Europe from 1890. It allowed people to listen to concerts or operas with a telephone handset, from another location across town. It even supported stereo audio, using a headset. It finally went out of business in the 1930s, killed by radio. Although by then, another form of remote audio streaming - Muzak, delivering cabled background music for shops and elevators - was also popular.

Why is this important? Because these services used "remote sound" (from the Greek tele+phonos) over networks. They were voice/audio communications services.

Yet they were not "phone calls".

Over the last century, we've started to use the words "voice communications", "telephony" and "phone calls" interchangeably, especially in the telecoms industry. But they're actually different. We often talk about "voice" services being a core component of today's fixed and mobile operators' service portfolios.

But actually, most telcos just do phone calls, not voice in general. One specific service, out of a voice universe of hundreds or thousands of possibilities. And a clunky, awkward service at that - one designed 100+ years ago for fixed networks, or 30+ years ago for mobile networks.

*Phone rings, interrupting me*

"Hello?"

"Oh, is that Dean Bubley?"

"Yes, that's me"

"Hi, I'm from Company X. How are you today?"

"I'm fine, thanks. How can I help you?"

... and so on.

It's unnatural, interruptive and often unwanted. A few years ago a 20-something told me some words of wisdom "The only people who phone me are my parents, or people I don't want to talk to". He's pretty much right. Lots of people hate unsolicited calls, especially from withheld numbers. They'll leave their phones on silent. (They also hate voicemails even more).

I used to go into meetings at operators and ask them "Why do people make phone calls? Give me the top 10 reasons". I'd usually get "to speak to someone" as an answer. Or maybe a split between B2B and B2C. But never a list of actual reasons - "calling a doctor", "chatting to a relative", "politely speaking to an acquaintance but wishing they'd get to the point".

Now don't get me wrong - ad-hoc, unscheduled phone calls can still be very useful. Person A calling Person B for X minutes is not entirely obsolete. It's been good to speak to friends and relative during lockdown, or a doctor, or a bank or prospective client. There's a lot of interactions where we don't have an app to coordinate timings, or an email address to schedule a Zoom call.

But overall, the phone call is declining in utility and popularity. It's an undifferentiated, lowest-common denominator form of communications, with some serious downsides. Yet it's viewed as ubiquitous and somehow "official". Why do web forms always insist on a number, when you never want to receive a call from that organisation?

Partly this relates to history and regulation - governments impose universal service obligations, release numbering, collect stats & make regulations about minutes (volume or price), determine interconnect and wholesale rates and so on. In turn, that has driven revenues for quite a lot of the telecom industry - and defined pricing plans.

But it's a poor product. There are no fine-grained controls - perhaps turning up the background noise-cancellation for a call from a busy street, and turning it down on a beach so a friend can hear the waves crashing on the shore. There's no easy one-click "report as spam" button. I can't give cold-callers a score for relevance, or see their "interruption reputation" stats. I can't thread phone calls into a conversation. Yes, there's some wizardry that can be done with cPaaS (comms platforms-as-a-service) but that takes us beyond telephony and the realm of the operators.

Beyond that, there's a whole wider universe of non-call voice (and audio) applications that operators don't even consider, or perhaps only a few. For instance:

• Easy audioconferencing
• Push-to-talk
• Voice-to-text transcription (for consumers)
• Voice analytics (e.g. for behavioural cues)
• Voice collaboration
• Voice assistants (like Alexa)
• Audio streaming
• Podcasts
• Karaoke
• One-way voice / one-way video (eg for a doorbell)
• Telecare and remote intercom functions for elderly people
• Telemedicine with sensor integration (eg ultrasound)
• IoT integrations (from elevator alarms to smartwatches)
• "Whisper mode" or "Barge-in" for 3-person calls
• Stereo
• De-accenting
• Voice biometric security
• Data-over-sound
• In-game voice with 3D-positioning
• Veterinary applications - who says voices need to be human?

There are dozens, maybe hundreds of possibilities. Some could be blended with a "call" model, while others have completely different user-interaction models. Certain of these functions are implemented in contact-centre and enterprise UCaaS systems, but others don't really fit well with the call/session metaphor of voice.

I've talked about contextual communications in the past, especially with WebRTC as an enabling technology, which allows voice/video elements to be integrated into apps and browser pages. I've also written before about the IoT integration opportunities - something which is only now starting to pick up (Disclosure: I'm currently working with specialist platform provider iotcomms.io to describe "people to process" and event-triggered communications).

But what irritates me is that the mainstream telecoms industry has just totally abdicated its role as a provider and innovator of voice services and applications. You only have to look at the mobile industry currently talking about Vo5G ("5G Voice") as a supposed evolution from the VoLTE system used with 4G. It's basically the same thing - phone calls - that we've had for over 100 years on fixed networks, and 30 years on mobile. It's still focused on IMS as a platform, dedicated QoS metrics, roaming, interconnection and so on. But it's still exactly the same boring, clunky, obsolescent model of "calls".

There was a golden opportunity to rethink everything for 5G and say "Hey, what *is* this voice thing in the 2020s? What do people actually want to use voice communications *for*? What interaction models and use-cases? What would make it broader & more general-purpose?" In fact, I said exactly the same thing around 10 years ago, when VoLTE was being dreamed up.

Nothing's changed, except better codecs (although HD voice was around on 3G) and lame attempts to integrate it with the even-worse ViLTE video and perennially-useless RCS messaging functions. The focus is on interoperability, not utility. Interop & interconnection is a nice-to-have for communications. Users need to actually like the thing first.

Some of the vendors pay lip-service to device integration and IoT. But unless you can tune the underlying user interface, codecs, acoustic parameters, audio processing, numbering/identity and 100 other variables in some sort of cPaaS, it's useless.

I don't want a phone call on a smartwatch - I want an ad-hoc voice-chat with a friend to ask what beer he wants when I'm at the bar. I want tap-to-record-and-upload of conversations, from my sunglasses, when someone's trying to sell me something & I suspect they're scamming me. I want realtime audio-effects like an audio Instagram filter that make me sound like I'm a cartoon character, or 007. (I don't want karaoke, but I imagine millions do)

So remember: the telecoms industry doesn't do "voice". It just does one or two voice applications. VoLTE is actually ToLTE. It's not too late - but telcos and their suppliers need to take a much broader view of voice than just interoperable PSTN-type phone calls. Maybe start with Théâtrophone 2.0?

This post was first published via my LinkedIn Newsletter - see here + also the comment stream on LI

#voice #telecoms #volte #phone #telephony #IMS #VoLTE #telcos #cPaaS #conferencing

If you're interested in revisiting your voice strategy, get in touch via email or LinkedIn, to discuss projects, workshops and speaking engagements. We can even discuss it by phone, if you insist.

I got it slightly wrong - NFC mobile payments are not a complete dud

I have long been a critic of NFC-based mobile payments from smartphones. It was originally touted as a mobile operator service, debiting value (or adding to your monthly bill) with a tap. I was deeply skeptical.

Almost 10 years ago, I wrote that for it to work, "I ought to be able to check my balance from the phone screen, look at recent transactions and so on. At present, the UI/app side of NFC appears woefully weak to me". (link)

Six years ago, I was more emphastic still: "the tap-to-pay thing is a nonsense, a solution looking for a problem. The involvement of a telco adds zero value and lots of friction". (link)

I have to admit to being partly wrong. Yes, I know, it's rare for me to issue a mea culpa, but here, I have to hold my hands up!

I do actually see (some) people paying for things with their smartphones, as well as using them for stored tickets / travelcards. I also know that in China, South Korea and some other places, QR codes are popular, but that's a different technology. But for the most part, I was right about MNOs being an obstacle rather than a catalyst.

A few things have changed:

• Linking NFC chips to native-OS capabilities like Apple and Android Pay, allowing the creation of good apps & UIs.
• Integration with on-device biometrics, notably fingerprint- and facial-recognition
• People commonly carrying charger cables or USB power banks, so there's less fear that running out of power = running out of money.
• Very wide adoption of contactless plastic-card payments. In many UK and other European countries, a huge bulk of low-value retail and services-sector payments have moved to this model. This has allowed the broader concept of tap-to-pay to be normalised with plastic, and then a (currently small) % switch further to phones. It has also catalysed merchants to move to tap-to-pay terminals.
• Most telcos bowing out of the payments value-chain, replaced by banks (old & new fintech ones), plus Apple, Google & Samsung. This has taken out cost, friction - and put the user back in control with familiar, mostly-trusted payment brands.

But it's still definitely not a "revolution". It's one of those secondary things that some people have adopted, without becoming universal. It's a bit like wearing a FitBit - people don't look at you weirdly any more, but they mostly don't intend getting one themselves. (If you pay with a watch, though, you're definitely still weird). 

NOTE: I realise that "normal" is a very geo-specific culture judgement. Within a country or even city, you may find greater levels of acceptance or scorn depending where you shop or drink coffee / beer. 

NFC phone-payment is now somewhere on the geek spectrum in between using a voice assistant (fairly normal), and wearing an AR/VR headset in public (not). There are some fairly clear demographics about who does/doesn't use NFC, as well.

This morning, for an entirely unscientific experiment, I counted 9 out of 100 people exiting my local tube station in central London using a phone rather than a card. Among card users, I couldn't tell how many used a proprietary TFL Oyster card vs. a normal credit/debit card that is now accepted at Oyster terminals. 

On closer inspection however, some of those people had phone-cases which also held some plastic cards as a physical wallet (like these - link), so given not all had been thumb-ing the screens, the actual number of proper NFC users was probably 5-7%. And that is among commuters who mostly travel every day, at 9am, so we can perhaps expect routines to be optimised. I might try another time to see how daytime "casual" usage differs.

Without having done a similar count at shops and restuarants, but having been generally observant over recent months, I'd guess that about the same percentage applies for retail transactions. Common-ish, but certainly atypical.

(As a sidenote - I'm writing this in a very nice cafe in London, which is having to apologise to customers that its card/NFC reader isn't working at all. Cash is still a critical backup).

Personally, I don't use my phone for retail payments. I use my contactless bank or credit cards, and I have a proper pre-pay Oyster. I prefer to keep my various payment and online relationships completely separate - Apple doesn't even have my credit card details.

I'm curious what the situation is elsewhere, and I'll keep an eye out when I'm travelling. My expectation is that phones will become somewhat more common for payments over time, but there's not going to be a sudden flip, as there was with contactless cards. I think geographic differences will persist too - I'd be surprised if Germany was a fast adopter of phone-based NFC, while China could well move much mor decisively. 

There might even be one or two places with telcos in the NFC-payments loop, as they are in some developing markets for messaging-based payments - but I don't see that in markets with existing high % of banking and card adoption.

Bottom line: I was definitely a bit too negative 10 years ago about the long-term future of NFC. But the transition remains slow, patchy, and dependent on the UX skills of the smartphone manufacturers. Also, few saw the behavioural acceptance of consumers being driven by tap-to-pay plastic cards as a first (and for many, last) step.

Thoughts on roaming, local SIM cards and eSIMs

I spend a large part of my life travelling, both for work and leisure. But while I find connectivity to be hugely important, I refuse to pay ludicrous per-MB data roaming prices.

So until a couple of years ago, this meant that I had a large collection of (mostly non-functioning) local mobile SIM cards I'd bought in various countries. Typically, I'd use them in a spare phone, so I could keep me normal phone on my home SIM to get inbound SMS or missed voice-call notifications. I'd also often use the second phone as a WiFi tether for my primary iPhone.

At one point I found old SIMs from the US, Singapore, Mozambique, Vanuatu, UAE and Australia in my wallet. In some places it was easy to get local SIMs, while in others it involved cumbersome registration with a passport or other documents. Places like India and Japan were a real pain, and I just didn't bother, relying on WiFi & an occasional extortionate SMS.

That has changed in recent years - and there are now multiple options for travellers:

• Local SIMs are often easier to obtain. Booths at airports are well-practised at registering documents, sorting APN setting and so on, in a couple of minutes
• In the EU, roaming prices have fallen progressively to zero - often including non-EU European countries as well. Various other groups of countries or regional operator groups have also created free-roaming zones.
• Some operators offer customers flat-rate or even free roaming to other countries, such as T-Mobile US's free (but 2G-only) international data, or $5/day for capped LTE (link). I use Vodafone UK's £6/day "roam further" plan quite a lot, especially when visiting the US (link).
• Many travellers can get dual-SIM phones, so they can easily switch between home and local SIMs without fiddling about with trays & pins. (There's no dual-SIM iPhone though. Grrrr. More on this later). 
• Various companies (eg Truphone) offer global/roaming SIMs, and have hoped that frequent travellers would use these as their primary/only SIM. The problem with this is that they typically rely on MVNO relationships in each country, including the user's home market - which often means poorer data plans than can be bought domestically from the main MNOs. You also don't get to benefit from multi-play plans, bundled content and so forth. I'm also not entirely convinced that MVNO traffic always gets as well-treated as the host MNO's own customer data - and that's likely to get worse with 5G and network-slicing.
• Some providers pitch global SIMs alongside rented/bought portable WiFI hotspots, such as TEP Wireless (link). The problem is that these often just cover the same countries as the better roaming plans from normal mobile operators. 

So... in July I went on holiday to the Cape Verde islands, off the coast of West Africa. Beautiful archipelago of 9 inhabited islands, with beaches, mountains, volcanoes, hiking trails and small villages nested in sheer-sided valleys. Neither Vodafone nor any of the travel-SIM companies seemed to cover either of its two main networks. So I went and bought an unlocked WiFi hotspot (from TP-Link), and hoped to get a local SIM on arrival, as I'd read a few suggestions it was possible.

It wasn't just possible, but remarkably easy. Walking through the arrivals door from customs at the airport, I was handed a free SIM by a representative of one of the operators (Unitel) within seconds. When I unwrapped it later in the day, I found it had 200MB of data included for free. No registration needed, no upfront payment, nothing. 3G network only, but that was fine to assure myself it worked OK. The next day I found a branded store & decided to stick with that network rather than check the other one (good marketing / customer acquisition strategy!) as the price-plans seemed fine. 

I paid €12 for 5GB of data, valid for a month. There was also a 7GB and maybe a 10 or 12GB one, but I wasn't planning on streaming video. In other words, €1 a day with about 500MB available per day, for normal mobile usage during my 11-day visit. The helpful lady in the shop sorted it all out for me, including temporarily switching my new SIM into her phone to send the setup / dataplan-purchase messages, which were tricky from a device with no keypad.

This compared to the roaming-advice SMS telling me that data would cost £0.60/MB [about €0.70]. In other words, roaming data was about 300x overpriced - quite astonishing, in 2018. And the mobile industry wonders why users have such little loyalty and respect.

(It's also worth noting that WiFi was ubiquitous in any hotel, cafe, restaurant or other places that visitors might go. There were telephone cable strung along all the valleys on poles, and decently-fast broadband was common. Given the moutainous topography, you could sometimes get WiFi more readily than cellular).
 

How would eSIM change things?

But this experience got me thinking about how the experience might be different in the coming era of eSIMs and remote-provisioning. Firstly, let's assume that one or both Cape Verdean operators actually had the requisite server-side gear for RSP. And let's assume that my future iPhone either has a multi-profile eSIM capability, or has dual removable/embedded SIM capability. (Remember, I still want to get my normal SMS's from my UK Vodafone number). Potentially, a future WiFi Hotspot could be eSIM-enabled too.

But then the question is, how does the user find out about the available networks, and the available plans on those networks? What's the user journey?

And there are lots of other questions too:

• Would I get a popup alert when I switched my phone on after the flight? 
• Would it give me menus for all the available plans or just a subset? 
• Would I need to have signed up in advance, either with a local CV telco, or perhaps facilitated by Apple, Vodafone or a third party? 
• When and how would I download the new profile? What data would that require me to send back (or what would be collected automatically?). 
• Would it be easier to get an eSIM-capable WiFi device? 
• But would that just be the same global MVNO providers who didn't have a Cape Verde relationship for roaming?
• What happens if something goes wrong, or you need to buy more data? Can local stores give you any help, or top-ups?

Bottom line: this whole experience would likely have been worse with eSIM, not better. And probably more costly too. Maybe in a less unusual country, with MVNOs and better roaming partnerships, it could be much more slick.

But for most "normal" countries, I'll probably stick to the £6/day plan from Vodafone for ease, even if that's 5x overpriced and should really be £1-2/day. It's annoying, but basically the equivalent of  beer, and there's probably other ways I can save money faster when on a trip. That said, now I've got my new WiFi puck, I might switch back to SIMs sometimes though, if they're easy and available at the airport. I'll certainly take it along with me as a Plan B.

Telco use-cases for AI: A simple categorisation model

The coming years will see the application of AI technology across all sectors of the economy and life. The telecoms industry is no different. Although I’ve been commenting on telco-sector AI in the context of “TelcoFuturism” for some time (link), and co-ran a workshop on it in May 2017 (link), the last few months have seen a notable upswing in interest. I’d say that the public use-cases now seem to be significantly in advance of those for blockchain, in terms of potentially-transformational technologies.

That said, it can still be hard for many executives to grasp exactly what is likely to change, and when, for AI/telecoms combinations. This is highlighted by the surge in AI-related panels, presentations and even complete streams at industry conferences – although sometimes I see more interest from generalist AI people about the telecoms vertical, versus telecom specialists looking at what’s new. 

Both sides of the equation have large volumes of obscure acronyms, multi-layered technology stacks, and complex volume chains – which can mean that mutual understanding is often confined to narrow niches. AI covers machine- and deep-learning, language processing, machine-vision and much more. Telecoms includes vast realms of internal systems and processes that are unknown to most who are not insiders – domains like core networks, OSS/BSS, network optimisation, toll fraud and service-assurance are alien to those not steeped in the industry.

One of the ways I’ve been using to “set the scene” for describing AI/telecoms intersections is to simplify and categorise the use-case areas. I count three, possibly four, large “buckets” into which a variety of telecom AI impacts will fit. These buckets are not based on either specific AI or telecoms technology slices, but more on understandable business functions and roles:

• Dealing with customers
• Managing operations
• Creating new services
• (External risks)

 Within each of these areas, there are many, many sub-sectors – and also some overlap.

“Dealing with customers” can include everything from voice/text chatbots for customer-service, through to predictions of which customers are least-happy and may “churn” to competitors. Where telcos have retail outlets, it could incorporate various in-store technologies, or it could be about smarter web-consoles for B2B customers running complex managed services.

“Managing operations” is even more diverse – it could be fault prediction for network elements, optimising the 100s of configuration variables for radio networks, spotting fraudulent traffic to international premium-rate numbers, allocating engineering resources more productively, or protecting against hackers and malware. There are hundreds of possible uses here, which mostly overlay on top of existing operational/business support systems (OSS/BSS) See also my recent post (link)

“New services” also spans a range of areas, but broadly splits between AI-enabled and AI-enabling services. An AI-enabled service could be a local-language voice assistant added to a cable operator’s set-top box or remote control. Or it could be the provision of integrated “smart city” solutions including video-cameras and security analytics. AI-enablement could include offering “edge” servers for hosting local processing, milliseconds transport-time away from a device, or it could be the provision of anonymised bulk data for others to apply algorithms to. Telco opportunities with IoT+AI include both enablement and enabled services, in numerous manifestations.

The “risks” category includes a diffuse set of possibilities by which AI might harm the telecom industry, or dampen demand for services. Smarter devices (eg autonomous vehicles) will be able to host their own offline image processing & route-planning locally, rather than needing realtime connectivity at 5G speeds/latencies. Another threat could be customers’ smart assistants renegotiating price-plans on their behalf – after crowdsourcing millions of conversations to deduce how best to game the retention staff’s scripts and objections. (Of course in the latter example, the customer-retention team could themselves be bots). Numerous types of automated “least-cost X” and arbitrage engines are likely to emerge. Various security risks are also probable here too.

Clearly, using just these four "buckets" misses much of the fine-grained detail. But I find it helpful as a starting point, as most top-level industry issues apply differently to each. 

Consider input data, for example – for both customer management and operations, telcos have abundant historical records and ongoing data collection that may generate terabytes per day. But for the former, privacy considerations often come to the fore in terms of regulation and risk, while this is far less of a concern for internal operational data, for example on how the network is running. For new services, almost by definition the focus is on collecting/processing/transporting new data, rather than deriving conclusions from existing sets. 

This four-way framework is also useful for thinking about different types of ROI model - split broadly between impacting existing revenues, existing costs, new revenues and potential changes to underlying assumptions. 

I'll be covering these topics in more depth in various upcoming presentations and reports, as well as looking at other areas of telco-linked innovation such as blockchain, 5G and enterprise verticals. Please get in touch if you would like more detail, or are interested in internal workshops, external support through events or white papers, or are seeking ongoing strategic advisory support.

Debunking the Network QoS myth

Every few years, the network industry - vendors, operators & industry bodies - suffers a mass delusion: that there is a market for end-to-end network QoS for specific applications. The idea is that end-users, application developers - or ideally both - will pay telcos for prioritised/optimised connections of specific "quality", usually defined in terms of speed, latency & jitter (variability).

I've watched it for at least a dozen years, usually in 3-year waves:

• We had enterprise networks promising differentiated classes of service on VPNs or the corporate connection to the Internet. Avoid the impact of the marketing department watching cat videos!
• We had countless failed iterations of the "turbo boost" button for broadband, fixed or mobile.
• We had the never-realised "two-sided markets" for broadband, featuring APIs that developers would use to pay for "guaranteed QoS"
• We had numerous cycles of pointless Net Neutrality arguments, talking about "paid prioritisation", a strawman of massive proportions. (Hint: no content or app developer has ever had lobbyists pleading for their right to buy QoS, only telcos asking to be able to sell it. Compare with, say, campaigns for marijuana decriminalisation).
• We currently have 5G "network slicing" concepts, promising that future MNOs will be able to "sell a slice" to an enterprise, a car manufacturer, a city or whatever.
• My long-standing colleague & interlocutor Martin Geddes is pitching a concept of app-focused engineering of networks, including stopping "over-delivering" broadband to best-efforts applications, thus forcing them to predict and right-size their demands on the network.

In my view, most of these attempts will fail, especially when applied to last-mile Internet access technologies, and even more-especially to wireless/mobile access. There isn't, nor ever will be, a broad and open market for "end-to-end network QoS" for Internet applications. We are seeing network-aware applications accelerating much faster than application-aware networks. (See this paper I wrote 2 years ago - link).

Where QoS works is where one organisation controls both ends of a connection AND also tightly-defines and controls the applications:

• A fixed-broadband provider can protect IP telephony & IPTV on home broadband between central office & the home gateway.
• An enterprise can build a private network & prioritise its most important application(s), plus maybe a connection to a public cloud or UCaaS service.
• Mobile operators can tune a 4G network to prioritise VoLTE.
• Telco core and transport networks can apply differential QoS to particular wholesale customers, or to their own various retail requirements (eg enterprise users' data vs. low-end consumers, or cell-site timing signals and backhaul vs. user data). 
• Industrial process & control systems use a variety of special realtime connection protocols and networks. Vendors of "OT" (operational technology) tend to view IT/telecoms and TCP/IP as quaint. The IT/OT boundary is the real "edge".

Typically these efforts are costly and complex (VoLTE was frequently-described as one of the hardest projects to implement by MNOs), make it hard to evolve the application rapidly because of dependencies on the network and testing requirements, and often have very limited or negative ROI. More importantly, they don't involve prioritising chunks of the public Internet - the telco-utopian "but Netflix will pay" story.

There are a number of practical reasons why paid-QoS is a myth. And there's also a growing set of reasons why it won't exist (for the most part) in future either, as new techniques are applied to deal with variable/unpredictable networks.

An incomplete list of reasons why Internet Access QoS isn't a "market" include:

• Coverage. Networks aren't - and won't be - completely ubiquitous. Self-driving cars need to be able to work offline, whether in a basement car-park, during a network outage in a hurricane, or in the middle of a forest. The vehicle won't ask the cloud for permission to brake, even if it's got promised millisecond latency. Nobody pays for 99.99% access only 80% of the time.
• The network can't accurately control or predict wireless effects at micro-scale, ie RF absorption or interference. It can minimise the damage (eg with MIMO, multiple antennas) or anticipate problems (weather forecast of rain = impact on mmWave signals).
• End-user connections to applications generally go via local WiFi or LAN connections, which service providers cannot monitor or control.
• No application developer wants to cut QoS deals with 800 different global operators, with different pricing & capabilities. (Or worse, 800 million different WiFi owners).
• 5G, 4G, 3G and zero-G all coexist. There is no blanket coverage. Nobody will pay for slicing or QoS (if it works) on the small islands of 5G surrounded by an ocean of lesser networks.

• "Applications" are usually mashups of dozens of separate components created by different companies. Ads, 3rd-party APIs, cloud components, JavaScript, chunks of data from CDNs, security layers and so on. Trying to map all of these to separate (but somehow linked) quality agreements is a combinatorial nightmare.
• Devices and applications have multiple features and functions. A car manufacturer wouldn't want one slice, but ten - engine telemetry, TV for the kids in the back seat, assisted-driving, navigation, security updates, machine-vision uploads and so on all have very different requirements and business models.
• Lots of IoT stuff is latency-insensitive. For an elevator maintenance company, a latency of a week is fine to see if the doors are sticking a bit, and an engineer needs to arrive a month earlier than scheduled.
• I don't know exactly how "serverless computing" works but I suspect that - and future software/cloud iterations - take us even further from having apps asking the network for permission/quality on the fly. 
• Multiple networks are becoming inevitable, whether they are bonded (eg SD-WANs or Apple's use of TCP Multipath), used in tandem for different functions (4G + SigFox combo chips), meshed in new ways, or linked to some sort of arbitrage function (multi-IMSI MVNOs, or dual-SIM/radio devices).  See also my piece on "Quasi-QoS" from last year (link)

• Wider use of VPNs, proxies and encryption will mean the network can't unilaterally make decisions on Internet QoS, even if the laws allow it.
• Increasing use of P2P technologies (or D2D devices) which don't involve service providers' control infrastructure at all.
• Network APIs would probably have to be surfaced to developers via OS/browser functions. Which then means getting Apple, Google, Microsoft et al to act as some sort of "QoS storefront". Good luck with that.
• No developer will pay for QoS when "normal" service is running fine. And when it isn't, the network has a pricing/delivery challenge when everyone tries to get premium QoS during congestion simultaneously. (I wrote about this in 2009 - link) 
• Scaling the back-end systems for application/network QoS, to perhaps billions of transactions per second, is a non-starter. (Or wishful thinking, if you're a vendor).
• There's probably some extra horribleness from GDPR privacy regulations in Europe and information-collection consent, which further complicates QoS as it's "processing". I'll leave that one to the lawyers, though.
• It's anyone's guess what new attack-surfaces emerge from a more QoS-ified Internet. I can think of a few.

But the bigger issue here is that application and device developers generally don't know or care about how networks work, or (in general) have any willingness to pay. Yes, there's a handful of exceptions - maybe mobile operators wanting timing sync for their femtocells, for example. Safety-critical communications obviously needs quality guarantees, but doesn't use the public Internet. Again, these link back to predictable applications and a willingness to engineer the connection specifically for them.

But the usually-cited examples, such as videoconferencing providers, IoT specialists, car companies, AR/VR firms and so on are not a viable market for Internet QoS. They have other problems to solve, and many approaches to delivering "outcomes" for their users.

A key issue is that "network performance" is not considered separately and independently. Many developers try to find a balance between network usage and other variables such as battery life / power consumption together. They also think about other constraints - CPU and screen limitations, user behaviour and psychology, the costs of cloud storage/compute, device OS variations and updates, and so on. So for instance, an app might choose a given video codec based on what it estimates about available network bandwidth, plus what it knows about the user, battery and so on. It's a multi-variable problem, not just "how can the network offer better quality".

Linked to this is analytics, machine learning and AI. There are huge advances in tuning applications (or connection-managers) to deal with network limitations, whether that relates to performance, cost or battery use. Applications can watch rates of packet throughput and drops from both ends, and make decisions how to limit the impact of congestion. (see also this link to an earlier piece I wrote on AI vs. QoS). 

Self-driving vehicles use onboard image-recognition. Data (real-world sensed data and "training" data) gets uploaded to the cloud, and algorithms downloaded. The collision-avoidance system will recognise a risk locally, in microseconds.

 They can focus resources on the most-important aspects: I saw a videoconference developer last week talk about using AI to spot "points of interest" such as a face, and prioritise "face packets" over "background packets" in their app. Selective forwarding units (SFUs) act as video-switches which are network-aware, device-aware, cost-aware and "importance-aware" - for example, favouring the main "dominant" speaker.
 
Another comms developer (from Facebook, which has 400 million monthly users of voice/video chat) talked about the variables it collects about calls, to optimise quality and user experience "outcome": network conditions, battery level before & after, duration, device type & CPU patterns, codec choice and much more. I suspect they will also soon be able to work out how happy/annoyed the participants are based on emotional analysis. I asked about what FB wanted from network APIs and capabilities - hoping for a QoS reference - and got a blank look. It's not even on the radar screen.

At another event, GE's Minds and Machines, the "edge" nodes have a cut-down version of their Predix software which can work without the cloud-based mothership when offline - essential when you consider the node could be on a locomotive in a desert, or on a plane at 35000ft.

The simple truth is that there is no "end to end QoS" for Internet applications. Nobody controls every step from a user's retina to a server, for generic "permissionless innovation" applications and services. Paid prioritisation is a nonsense concept - the Net Neutrality crowd should stop using that strawman.

Yes, there's a need for better QoS (or delta-Q or performance management or slicing or whatever other term you want to use) in the middle of networks, and for very specific implementations like critical communications for public safety. 

The big unknown is for specific, big, mostly mono-directional flows of "content", such as streaming video. There could be an argument for Netflix and YouTube and peers, given they already pay CDNs, although that's a flawed analogy on many levels. But I suspect there's a risk there that any QoS payments to non-neutral networks get (more than?) offset by reverse payments by those networks to the video players. If telcos charge Netflix for QoS, it wouldn't surprise me to see Netflix charge telcos for access. It's unclear if it's zero-sum, positive or negative net.

But for the wider Public Internet, for consumer mobile apps or enterprise cloud? Guaranteed (or paid) QoS is a myth, and a damaging one. Yes, better-quality, better-managed networks are desirable. Yes, internal core-network use of better performance-management, slicing and other techniques will be important for telcos. Private wireless or fixed broadband networks, where the owner controls the apps and devices, might be an opportunity too.

But the concept of general, per-app QoS-based Internet access remains a dud. Both network innovation and AI are taking it ever-further from reality. Some developers may work to mark certain packets to assist routing - but they won't be paying SPs for an abstract notion of "quality". The notion of an "application outcome" is itself a wide and moving target, which the network industry only sees through a very narrow lens.