6G won't wait. Will traditional MNOs still be the main customers when it arrives?

This post originally appeared in September 2023 on my LinkedIn feed, which is now my main platform for both short posts and longer-form articles. It can be found here, along with the comment stream. Please follow / connect to me on LinkedIn, to receive regular updates (about 1-3 / week)

 One line I heard yesterday at #ConnectedBritain that really struck me came from BT Group Network/Security head Howard Watson during his keynote.

He was hoping #6G arrived later rather than earlier, "For the Brisbane Olympics, not LA", ie 2032.

This is not the first time I've heard an MNO exec expressing a desire to let #5G run longer, before 6G prompts more Capex and infrastructure changes. They want to get payback on existing investments before thinking about the next round.

This is unsurprising. The industry itself now recognises that it overhyped 5G before launch, and completely forgot to mention that it would arrive in phases, with all the "cool stuff" really only arriving in later versions, with the features in 3GPP Releases 16, 17 & 18.

Instead, we started with 4G++ (ie non-standalone 5G, with sometimes higher speeds but not much else) and then the first versions of "proper 5G" with the Release 15 standalone cloud-native core.

5G SA gives somewhat lower latency, and some rudimentary QoS and other features, but it's far from the ubiquitous millisecond / gigabit / slicing nirvana that everyone promised in 2018.

I was skeptical from the beginning - and I'm still a "slice denier". (I think #networkslicing remains a critical strategic error and distraction for the industry). But my view is that the really useful stuff in 5G, such as time-synchronous networking, RedCap and vertical-specific elements such as FRMCS for railways, are still a long way from mainstream.

So I can understand that MNOs look at the proposed 6G timeline of 2030, and think "we're still making heavy work of moving to cloud-native 5G standardalone. How are we going to do successive iterations of R15 SA, R16, R17, R18, R19... and make money, all within 6 years?"

[Note: technically 6G should start with Release 21, but based on past experience we'll see R20, or maybe even R19, marketed as 6G by some MNOs]

There is a possible uncomfortable answer that's starting to get discussed quietly. What if 6G isn't primarily about MNOs, at least at first?

6G will happen in 2030, one way or another. The world's universities and R&D labs aren't going to down tools for two years, while MNOs are still trying to "monetise" 5G. There will be a bunch of technologies and standards that get called IMT2030 / 6G.

There might even be multiple standards, either because of geopolitics leading to regional versions, or because my niggling of IEEE and Wi-Fi Alliance eventually prompts them to submit a candidate 6G technology (#WiFi 9 or 10, I guess).

So the question then becomes - will traditional MNOs be the main buyers of 6G in the 2028-2030 timeframe? Or will it be enterprises, new-entrant and niche MNOs, infracos, neutral-hosts, satcos, governments and others building greenfield wireless networks?

Is the failure of 5G to live up to inflated expectations actually going to be the pivot point for the (slow) demise of the legacy MNO model? Are we watching #pathdependency effects in play?

 

Network Slicing is a huge error for the 5G industry

(Initially posted on LinkedIn, here. Probably best to use LI for comments & discussion)

I've started calling myself a "Slice Denier" or "Slicing Skeptic" on client calls and conference speeches on #5G.

Increasingly, I believe that #NetworkSlicing is one of the worst strategic errors made by the #mobile industry, since the catastrophic choice of IMS for communications applications. The latter has led to the fiascos of #VoLTE and #RCS, and loss of relevance of telcos in communications more broadly.

At best, slicing is an internal toolset that might allow telco operations or product teams (or their vendors) to manage their network resources. For instance, it could be used to separate part of a cell's capacity for FWA, and dynamically adjust that according to demand. It might be used as an "ingredient" to create a higher class of service for enterprise customers, for instance for trucks on a highway, or as part of an "IoT service" sold by MNOs. Public safety users might have an expensive, artisanal "hand-carved" slice which is almost a separate network. Maybe next-gen MVNOs.

(I'm talking proper 3GPP slicing here - not rebranded QoS QCI classes, private APNs, or something that looks like a VLAN, which will probably get marketed as "slices")

But the idea that slicing is itself a *product*, or that application developers or enterprises will "buy a slice" is delusional.

Firstly, slices will be dependent on [good] coverage and network control. A URLLC slice likely won't work reliably indoors, underground, in remote areas, on a train, on a neutral-host network, or while roaming. This has been a basic failure of every differentiated-QoS monetisation concept for many years, and 5G's often-higher frequencies make it worse, not better.

Secondly, there is no mature machinery for buying, selling, testing, supporting. price, monitoring slices. No, the 5G Network Exposure Function won't do it all. I haven't met a Slice salesperson yet, or a Slice-procurement team.

Thirdly, a "local slice" of a national 5G network will run headlong into a battle with the desire for separate private/dedicated local 5G networks, which may well be cheaper and easier. It also won't work well with the enterprise's IT/OT/IP domains, out of the box.

Also there's many challenges getting multi-operator slices, device OS links to slice APIs, slice "boundary controllers" between operators, aligning RAN and core slices, regulatory questionmarks and much more.

To use an appropriate analogy, consider an actual toaster, with settings for different timing, or a setting for bagels. Now imagine Toaster 5.0 with extra software smarts, perhaps cloud-native. Nobody wants to buy a single slice of toast, or a software profile. They'll just buy a toaster for their kitchen, or or get an "integrated breakfast solution" including toast in a cafe. They won't care about the slicing software. The chef might, but it's doubtful.

If you see 5G Network Slicing as a centrepiece of future "monetisation", you're in for an unpleasant smell of burning, and probably a blaring smoke alarm too.

 

Blockchain for telecoms and networks: the emergence of ICOs & token-based platforms

There's a new trend I'm currently seeing emerge: ICOs (Initial Coin Offerings) for network/Internet-related businesses and communities. These use blockchain-based "tokens" (or coins) as a way to build decentralised marketplaces, for Internet connectivity or other communications capabilities like phone calls. Most have visions for long-term disruption of existing models, although they tend to start from more humble niches.

ICOs both establish a "currency" for these future markets, and provide funding for organisations responsible for their creation and maintenance. At least five network-related ICOs have been announced already, and more seem likely to follow in due course. (Disclosure: I'm an advisor to one of these five - more details below).

Note: If you've found this post through a link from a mainstream ICO/Bitcoin site or link, a quick introduction: I'm primarily a mobile and telecoms analyst. I study and advise on technology and business-model trends relating to network evolution and communications applications. I cover areas like 5G, IoT-oriented networks, voice & video communications, regulatory policy, the future role of telecom operators, and the impact of "futures" innovations like AI / ML, blockchain and drones on telecoms. Most of my clients are telcos or network equipment/software vendors. I'm not a fintech or blockchain generalist.

Note 2: I am also not an investment advisor of any sort. I'm not making recommendations here.

I've been covering the role of blockchains and distributed ledgers in telecoms and networks for well over a year now. I've spoken at events run by TMForum, IIT, Comptel and others about the telecom-sector use-cases (and complexities), and ran a recent public workshop in London alongside Caroline Gabriel (link). I recently participated in a webinar for Juniper Networks (link) and have a forthcoming white-paper in preparation for Juniper as well.

My general stance is "pragmatic optimism": Blockchain technology has many possible touch-points with the telecoms industry, from data-integrity management to back-office systems to billing - but maturity will take time. Some of the utopian "it'll change the world" and "telcos are obsolete" rhetoric is overblown. Distributed ledgers will have many uses and opportunities in telecoms/networking - but are unlikely to overturn or radically-disrupt industry structures, at least on a 5-10 year view.

Most of the uses I've seen discussed until recently have been around private (permissioned) blockchains, intended to improve processes and security within or between telcos and their suppliers. Another set have been around new services/capabilities to be delivered by telcos - for example, using smart contracts to enforce SLAs (service-level agreements), or for identity-management in IoT networks.

The ICO trend is different - this is about public blockchain-based functions that anyone can participate in - hence the "offering". The idea is to create common, distributed, dynamic ways of storing (and pricing) network-related value - especially for Internet access, but also voice communications and potentially other capabilities. 

Actually, telecoms is lagging here: there's been a much broader rush towards ICOs across many sectors over the past year. This website (link) lists hundreds, while this article from the Economist is a useful intro (link). It should also be acknowledged that they have attracted not-always-favourable attention from financial regulators, as there is limited official oversight and most are launched as "crowdsales" on the back of a white paper and some PR, rather than a regulated prospectus and well-monitored issuance on a specific stock exchange. There are some questionable-quality ICOs and a few dubious individuals involved, it seems. Nevertheless, they are a popular way for blockchain-based initiatives to get funding and early traction - and some will undoubtedly becomes stars, even if others flame-out like supernovae.

In a way, a system for exchanging telecoms capacity or data quotas already exists - it's possible to send prepay account "top-ups" between people or companies today, although those are usually in monetary form (ie PAYG credit), rather than being denominated in minutes or MB. That is unsurprising, given the diversity of different pricing models and network operators - it would be hard for me to gift a GB of data to a friend on a different network, but I can send them a £5 / $5 / €5 credit and let them buy the data themselves. There are also other ways to share network capacity, such as FON's WiFi community.

The various ICOs are attempting to "tokenise" aspects of networks and communications, allowing different models of monetisation, with pricing driven by an external market rather than telcos' / ISPs' internal marketing functions. Some link to an existing cryptocurrency and blockchain like Ethereum, while others are trying to create something new.

The ones I've discovered that are clearly related to telecoms/networks include:

• DENT Wireless (The website is here & white paper is here): This aims to act as a clearinghouse for mobile data quotas / allocations, between users, between MNOs, or for roaming "local breakout" via visited networks, using its tokens as a common currency. Its ICO, based on Ethereum, was in July. It is aiming to build up enough members as a "buying consortium" to exert pressure on operators to cooperate. It's got some interesting execs and advisors, notably including Rainer Deutschmann who has been instrumental in getting Reliance Jio off the ground in India. One of the use-cases is "donating GB of data to Africa" as a way to improve Internet access in emerging markets. One interesting angle is a tie-up with sponsored-data software company Aquto, which works with AT&T and others. My longterm doubts about the general sponsored-data model continue (the concept of "1-800 apps" is palpable nonsense), but this could be a possible workable use-case. The key differentiator appears to be its willingness (& knowledge) of partnering with operators rather than trying to displace them. Given the wide variations of mobile data pricing (& conditions) by operator, country and tariff - especially postpaid vs prepaid - I'm not sure there's an easy common denominator, though. The inbound roaming scenario may be very tough as well, especially as it may need users to manually select networks, which they may be locked-out from doing on subsidised/customised handsets.
• AirFox (The website is here & the white paper is here): This platform attempts to draw a link between mobile prepay credits, advertising, user-data and potentially micro-loans in future. It extends the current model of gifting or sending "recharges" to many international mobile operators' prepay customers, by shifting from normal payments to a cryptocurrency bought in a marketplace or earned by viewing ads. The model of "watch these ads and get free calls/credit/data" is not a new one (eg Blyk in the UK between 2007-09), but this is the first decentralised and tokenised one I've seen, linked to a global recharge network. It relies on a customised browser and also a dedicated ad-viewer/recharge app. The browser blocks native ads and replaces them with its own (and can also fingerprint the user by looking at other apps installed). Users can thus earn Ethereum-based "AirTokens" or alternatively they can buy them at market rate, to exchange for prepay credit / recharges. It's not obvious to me how AirFox proposes to "bulk buy" data from operators without wholesale/MVNO deals - in most cases I suspect it'll have to use the usual recharge channels. Its aspiration to "replace the current mobile ecosystem (applications, sites, advertisers, data purchases) with a more efficient new decentralized AirFox mobile ecosystem" seems unrealistic given that most mobile users prefer native apps (or web-pages rendered in apps). Nevertheless, the existing model of sending real ("fiat") money or top-ups seems to work, so there's a basis for an ad-supported model, although its existing stats imply a revenue of 1/17th of a US cent per ad. The ICO / crowdsale launches on August 29th.
• Ammbr (The website is here & the white paper is here): [Note - I am an advisor - see below]. This is an attempt to blend custom mesh-network silicon and hardware units, with a blockchain and token-based model for identity and a marketplace. While AirFox and DENT focus on sharing credits/quotas for normal personal mobile access, Ammbr wants to share the access network itself, and ultimately encourage build-out of extra coverage and capacity. Its network units (initially WiFi but with other radios in future) support decentralised micropayments, allowing the node owners to earn tokens and essentially act as their own local ISPs with very little friction or setup cost. While these will obviously need backhaul from normal telcos (fixed and/or mobile), once sufficient density is reached, meshes may reduce the total number of wide-area connections needed. An initial use-case is likely to be in developing countries, where micro-loans and other local (and often informal) sharing-model businesses have grown. The hardware-based model is obviously ambitious, but also means future potential to support multiple radios (imagine a CBRS-type shared spectrum or LPWAN module), and could also potentially host distributed edge-computing or NFV capabilities. There are both opportunities and various complexities and possible pitfalls I can imagine, plus there are alternative options for community/rural connectivity (I'm writing a piece on Facebook's Telco Infra Project & OpenCellular for my STL Partners research stream at present [link]). One aspect that's interesting, but which I'm not able to comment on authoritatively, is the unique blockchain model, based on Proof of Elapsed Time / Velocity, which differs from Bitcoin & Ethereum's Proof of Work. In Ammbr is it linked to a custom silicon processor, with claims of much better power consumption than other approaches. The ICO is upcoming in September.
• EncryptoTel: (Web page is here and white paper is here. This is very different from the other network-type ICOs, as it's more about (business) voice communications than data access. It is a version of an enterprise cloud PBX / UCaaS platform, with encryption, privacy protections and (anonymous) cryptocurrency payments. It allows both on-net VoIP calls (using standard SIP endpoints or dialler apps) and integration with the public phone network, as well as (in future) interconnecting with various messaging applications. It will offer both monthly subscriptions and a pay-as-you-go model. The white paper references video calls, but it does not appear to offer full-fledged UC functions. The roadmap describes a progressive roadmap of development and deployment, with full commercial launch expected in Summer 2018. The ICO occurred in May 2017.
• Mysterium (Web page is here and white paper is here) is a distributed VPN and data-encryption platform - essentially a higher-performing, blockchain-based version of Tor. It uses an Ethereum-based token system of micropayments. In its earliest phases it retains some central control, with the intention of removing this further down the roadmap. It will compete with commercial VPN products. Its ICO started at the end of May 2017.

[Note: some white papers get updated, so the URL might change with the version number - check the main websites for the latest versions] 

There are also various other ICOs relating to cloud-computing, storage and other related areas, such as Filecoin and Internxt. Another company called Crypviser (link) is developing a secure messaging app and also references secure voice calls in its white paper, although with few details.

So - will any of these, or future, ICOs lead to commercial, scalable networking or communications platforms? It's too early to tell. While the white papers typically given enough "vision" and a tentative roadmap, it's likely that most or all of these projects will encounter challenges and pitfalls, and may end up pivoting as events unfold (and customers'/users' behaviour develops).

One of the risks is that tokenisation itself may limit the possible business and pricing models - for example, how can any of them offer hybrid centralised/decentralised services, if that's what the market seems to want? Can they support sponsored/free models, or allow more granular differentiation? What happens if they contravene other services' T's & C's? How is customer support provided for decentralised capabilities? It is also unlikely that any such proprietary mechanisms or payment instruments will become globally dominant, so there will need to be paths to standardisation - as well as deal with the beady eyes of regulators if they become successful.

Nevertheless, this is an interestingly different direction-of-travel for telecoms/network blockchain, as it sits separately to the main thrust of work around private/permissioned use-cases I'm seeing from some vendors, various operators, bodies like TMForum etc. I still think that some of the back-office applications for blockchain in the telecoms sector have more short-to-medium term opportunity, but it's possible we could see a break-out here by a new entrant of the type discussed in this post. I'll definitely be keeping a watching eye on all of these. 

Please drop me a message at information AT disruptive-analysis DOT com if you want to discuss this more, or want a telecom/blockchain speaker or analyst for an event or workshop.


Footnote on Ammbr: Close contacts may have noticed I recently added an advisory role to my LinkedIn profile, for an organisation called Ammbr, mentioned above. At present, I'm just working on a consultative basis, but unlike most of my other advisory clients, it's not purely "behind the scenes" with execs in private under-NDA workshops, but has a public aspect to it as well. It's got a genuinely interesting combination of technologies (mesh, blockchain, custom silicon, potentially private cellular etc), some talented people, and while that means a lot of moving parts to fit together, there are some intriguing possibilities I'm glad to be able to help refine and prioritise.

Internally, my role is as a telecoms-sector expert and (to nobody's surprise) a general curmudgeon pointing out any risks, technical or commercial "gotchas", competition/substitution threats and anything that seems like wishful thinking. I should point out that this is a small part of my overall activities, I'm not "endorsing" it as such, and my normal Disruptive Analysis work on all areas of analysis & futurism is continuing. It's also not going to bias my views on other wireless technologies or business models, many of which are more-developed and which I'm also enthused about (eg private cellular). Drop me a message if you want to discuss this further (or want to discuss other consulting or advisory roles).

Both sides are wrong in the Net Neutrality debate

I've been watching the ongoing shouting-match about Net Neutrality (in the US & Europe) with increasing exasperation. Recently there was a "day of action" by pro-neutrality activists, which raised the temperature yet further.

The problem? Pretty much everyone, on both sides (and on both sides of the Atlantic), is dead wrong a good % of the time. They're not necessarily wrong on the same things, but overall the signal-to-noise ratio on NN is very poor.

There are countless logical fallacies perpetrated by lobbyists and commentators of all stripes: strawman arguments, false dichotomies, tu-quoque, appeals to authority and all the rest. (This is a great list of fallacies, by the way. Everyone should read it). 

Everyone's analogies are useless too - networks aren't pipes, or dumb. Packets don't behave like fluids. Or cars on a road. There are no "senders". It's not like physical distribution or logistics. Even the word "neutrality" is dubious as a metaphor. The worst of all is "level playing field". Anyone using it is being duplicitous, ignorant, or probably both. (See this link).

I receive lots of exhortations from both sides - I get well-considered, but too-narrow network-science commentary & Twitter debates from friend & colleague Martin Geddes. I read detailed and learned regulatory snark and insider stories from John Strand. I see telco/vendor CEOs speaking (OK, grandstanding) at policy conferences. I get reports of egregious telco- and state-based blocking of certain Internet services from Access Now, EFF and elsewhere. I see VCs and investors lining up on both sides, depending on whether they have web interests, or network vendor/processing positions. I watch comments from the FCC, Ofcom, EU Commission, BEREC, TRAI and others - as well as politicians. And I read an absolute ton of skewed & partial soundbites from lobbyists on Twitter or assorted articles/papers.

And I see the same, tired - often fallacious or irrelevant - arguments trotted out again and again. Let me go through some of the common ones:

• Some network purists insist routers & IP itself are (at core) non-neutral, because there are always vagaries & choices in how the internals, such as buffers, are configured. They try to use this to invalidate the whole NN concept, or claim that the Internet is broken/obsolete and needs to be replaced. Other Internet purists insist that the original "end-to-end" principle was to get as close as possible to "equal treatment" for packets, and either don't recognise the maths - or suggest that the qualitative description should be treated as a goal, even if the precise mechanisms involve some fudges. Everyone is wrong.
• In the US, the current mechanism for NN was to incorporate it under the FCC's Title II rules. That was a clunky workaround, after an earlier NN ruling was challenged by Verizon in 2011. In many ways, the original version was a much cleaner way to do it, as it risked less regulatory creep. Everyone is wrong.
• Many people talk about prioritisation of certain traffic (eg movies) and how that could either (a) allow innovative business models, or (b) disenfranchise startups unable to match web giants' payments. Yet the technology doesn't work properly (and won't), it's almost impossible to price/market/sell/manage in practice, and there is no demand. Conspicuously, there have been no lobbyists demanding the right to pay for priority. There is no market for it, and it won't work. It's irrelevant. Everyone is wrong.
• Some people assert that NN will reduce "investment" in networks, as it will preclude innovation. Others assert that NN increases overall investment (on networks plus servers/apps/devices). When I tried to quantify the possible revenues from 25 suggested non-neutral business models (link), I concluded the incremental revenue would barely cover the extra costs of implementation, if that. There are many reasons for investments in networks (eg 4G then 5G deployment cycles), while we also see CapEx being replaced by OpEx or software licences for managed or virtual networks. Drawing meaningful correlations is hard enough, let alone causation from an individual issue out of dozens. Everyone is wrong.
• Most of the debate seems to centre on content - notably video streaming. This ties in with operators wanting to bundle TV and related programming, or Netflix and YouTube seen as dominating Internet traffic and therefore being pivot-points for neutrality. Yet in most markets, IPTV is not delivered via the public Internet anyway, and is considered OK to prioritise as it's a basic service. On the opposite side, upgrades to high-speed consumer broadband is partly driven by the desire for streaming video - revenues would fall if it was blocked, while efforts to charge extra fees to Netflix and co would likely backfire - they'd insist on opposite fees to be carried, like TV channels. Meanwhile, most of the value in the Internet doesn't come from content, but from applications, communications, cloud services and data transmission. However, they are all much techier, so get mostly overlooked by lobbyists and politicians entranced by Hollywood, Netflix or the TV channels. Everyone is wrong.
• Lots of irrelevant comments on all sides about CDNs or paid-peering being examples of prioritisation (or of craven content companies paying for special favours). Fascinating area, but irrelevant to discussion about access-network ISPs. Everyone is wrong.
• Lots of discussion about zero-rating or "sponsored data" paid for by 3rd-parties and whether they are right/wrong/distortions. Lots of debate whether they have to be offered to all music / video streaming services, whether they should just be promotional or can be permanent. And so on. Neither relate to treatment of data transmission by the network - and differential treatment of pricing is, like CDNs, interesting but irrelevant to NN. And sponsored data models don't work technically or commercially, with a handful of minor exceptions. Ignore silly analogies to 1-800 phone numbers - they are totally flawed comparisons (see my 2014 rant here). Upshot: zero-rating isn't an NN issue, and sponsored data (with prioritisation or not) doesn't work (for at least 10 reasons). Everyone is wrong.
• Almost everyone in the US and Europe regulatory scene now agrees that outright blocking of certain services (eg VoIP) or trying to force specific application/web providers to pay an "access" toll fee is both undesirable or unworkable. It would just drive use of VPNs (which ISPs would block at their peril), or amusingly could mean that Telco1.com could legally block the website of Telco2.com, which would make make future marketing campaigns a lot of fun. In other words, it's not going to happen, except maybe for special cases such as childrens' use, or on planes. It's undesirable, regulatorily unacceptable, easy to spot and impossible anyway. Forget about it. Everyone is wrong.
• Lots of discussion about paid-for premium QoS on broadband, and whether or not it should apply to IoT, 5G, NFV/SDN, network-slicing, general developer-facing APIs and therefore allow different classes of service to be created, and winners/losers to be based on economic firepower. Leaving aside enterprise-grade MPLS and VPN services (where this is both permissible and possible), there's a lot of nonsense talked here. For consumer fixed broadband, many of the quality issues relate to in-home wiring and WiFi interference, for which ISP-provided QoS is irrelevant. For mobile, the radio environment is inherently unpredictable (concrete walls, sudden crowds of people, interference etc). Better packet scheduling can tilt the odds a bit, but forget about hard SLAs or even predictability. Coverage is far more a limiting factor. Dealing with 800 ISPs around the world with different systems/pricing is impossible. The whole area is a non-starter: bigger web companies know how much of a minefield this is, and smaller ones don't care. Everyone is wrong.

In summary - nearly anyone weighing in on Net Neutrality, on either side, is talking nonsense a good % of the time. (And yes, probably me too - I'm sure people will pick holes in a couple of things here).

So what's the answer?

• First, tone down the rhetoric on both sides. The whole thing is a cacaphony of nonsense, mostly from lobbyists representing two opposing cheeks of the same arse. Acknowledge the hyperbole. Get some reputable fact-checkers involved, and maybe sponsored by government and/or crowdsourcing.
• Second, recognise that many of the threatened non-neutral models are either impossible or obviously unprofitable. Arguing about them is sophistry and a waste of everyone's time. There are more important things at stake.
• Thirdly, design and create proper field-trials to try to prove/disprove assertions about innovation, cost structures etc. Select a state, a city or a class of users, or speciallly-licensed ISPs to run prototypes and actually get some proper data. Don't try to change anything on a national or international basis overnight, no matter how many theoretical "studies" have been done. Create a space for operators and developers to try out creating "specialised services", see if they work, and see what happens to everything else. Then develop policy based on evidence - and yes, you'll have to wait a few years. You should have done it sooner instead of arguing. I suspect it'll prove my point 2 above, anyway
• Fourth, consider "inevitabilities" (see this link for discussion). VPNs will get more common. NFV and edge-computing will get more common. Multiple connections will get more common. New networks (eg private cellular, LPWAN) will get more common. Multi-hop connections with WiFi and ZigBee & meshes will get more common. Devices & applications will fragment, cloudify, become "serverless", being componentised with micro-services, and be harder to decode and classify in the network. AI will get more common, to "game" the network policies, as well as help manage the infrastructure. All this changes the landscape for NN over the next couple of years, so we'll end up debating it all again. Think about these things (and others) now.
• Six, try some rules on branding Internet / other access. Maybe allow specialised services, but force them to be sold separately from Internet access, and called something else (Ain'ternet? I Can't Believe it's Not Internet?)
• Seven, get ISP executives (and maybe web/content companies' execs too) to make a public promise about acting in consumers' interests on Internet matters, as I suggested a few years ago - an IPocratic Oath. (link)
• Eight, train and empower the judiciary to be able to understand, collect data and adjudicate quickly on Internet-related issues. It may be that competition law could be applied, or injunctions granted, even in the absence of hard NN laws. Let's get 24x7 overnight Internet courts able to take an initial view on permissibility of traffic management - not wait 2 years and appeals during which time an app-developer slowly dies.
• Nine, let's get more accountability on traffic-management and network configurations, so that neutrality/competition law can be applied at a later date anyway. We already have rules on data-retention for customer calls & access to networks. Let's have all internal network configuration & operational data in ISPs' networks securely captured, encrypted, held in escrow and available to prosecutors if needed, under warrant. A blockchain use-case, perhaps? We're going to need that data anyway, to guarantee that customer data hasn't been tampered with by the network. 
• Ten, ask software (and content and IoT device and cloud) developers what they actually want from the networks. Most seem to be absent from the debate - the forgotten stakeholders. Understand how important "permissionless innovation" actually is. Query whether they care about network QoS, or understand how it links to overall QoS which covers everything from servers to displays to device chipsets to user-interfaces. Find out how they deal with network glitches, dodgy coverage - and whether "fallback" strategies mean that the primary network is getting more or less important. Do they want better networks, are they prepared to pay for them - or would they just rather have better visibility and predictability of when problems are likely to occur?

Apologies for the length of this piece. I'll happily pay someone 0.0000001c for it to load faster, as long as the transaction cost is less than 5% of that.

Get in touch with me at information AT disruptive-analysis dot com if you'd like to discuss it more, or have a sane discussion about Neutrality and what it really means for broadband, policy, 5G, network slicing, IoT and all the rest.

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.