Home / Blogs

Why 5G Is in Trouble (and How to Fix It)

I have a somewhat unconventional view of 5G. I just happen to believe it is the right one. It is trapped inside a category error about the nature of packet networking, and this means it is in trouble.

As context, we are seeing the present broadband Internet access model maturing and begin to reach its peak. 5G eagerly anticipates the next wave of applications.

The 5G Difference: “Purpose-for-Fitness” to “Fitness-for-Purpose”

As such, 5G is attempting to both extend and transcend the present “undifferentiated data sludge” model of mobile broadband.

Firstly, it pumps the “undrinkable” mucky bandwidth harder and faster, to give a modified version of what we have today with 4G. We will gloss over the minor miracle that needs to happen with backhaul, or that the mobility protocols today with 4G struggle when you get on the train (and 5G makes it worse).

Secondly, its other goal is to deliver differentiated “drinkable” access for different enterprise cloud and industrial applications. This essentially is a generic version of the very specific VoLTE solution developed for voice telephony in 4G, extended to any cloud application. It can be expressed as being for low-latency applications, or packed in a variety of other guises.

The Slow Evolution Towards General-Purpose Assured APP Access

The conventional wisdom is that packet networks enable networked computing (“join devices”), and networks do “work”. As such, the job of the network is to forward as many packets as fast as possible, and what matters most is “speed”. 5G fits this.

The unconventional wisdom is that packet networks enable interprocess communications (“join computations”), and networks don’t do “work”. As such, the job of the network is to trade resources around to deliver the “just right” quantity of quality to optimise the trade-offs of QoE risk.

The former model is “pipe”, the latter is “futures and options trading”. The former works with TCP/IP, the latter needs new packet architectures (RINA). The former can extend radio network protocols from 2G, 3G and 4G; the latter needs new ones. The former has a low-frequency resource trading model, the latter a high-frequency trading one.

A Paradigm Change in Engineering is Needed for 5G to Succeed

5G is making the network far more dynamic, without having the mathematics, models, methods or mechanisms to do the “high-frequency trading”. The whole industry is missing a core performance engineering skill: they can do (component) radio engineering, but not complete systems engineering. When you join all the bits, you don’t know what you get until you turn it on!

The result will not be pretty.

In particular, 5G is primarily delivering into the tail of the last S curve of generic unassured broadband Internet access; it is not on its present path fit-for-purpose for assured cloud application access (inc VR/AR and IoT), which is the new S curve of growth.

Telephony is virtual reality. VoLTE wasn’t solving the problem of how to extend the life of the past; it was solving a corner case of how do we communicate in future. Understand this, and the future and fate of 5G makes more sense.

The key question is whether 5G is aimed at extending the VoLTE part of 4G (fit-for-purpose voice) or improving the rest (purpose-for-fitness Internet access). It is trying to serve two strategic masters, the past and the future, at once.

Is 5G trying to “buy back up the curve”, implying doom for its makers and buyers?
Watch the video presentation: The Death of Cellular by Francis McInerney

So, what to do about it? I see three key industry actions.

Firstly, we need to narrow the intentional semantics. 5G is trying to do too many things.

The focus of the generic broadband access should not be peak speed, or even “antipeak” latency under ideal conditions. It should be to establish a consistent quality floor under real-world conditions with graceful degradation in overload. That floor should be adjustable so that you can segment the market by quality.

This is a precursor to a 6G, where the two sides of unassured and assured can be unified through a shared framework for managing the quality floor.

Whilst we need a “generic VoLTE”, only about 5 people on the planet know how to do it (and we’re all busy on other things). So for the assured access part, it should not attempt to make the leap from singular VoLTE to a generic offer in one go.

There needs to be a series of smaller and less ambitious steps that allow the coexistence of a modest number of managed services with different latency and throughput needs. However, the real issue is to assure complete supply chains, not just one part (the access) or sub-part (the radio link).

Which brings us to the second issue, the denotational semantics. As an industry, we’ve yet to agree on the standard units for broadband supply and demand (if you can believe it). So the next thing 5G has to fix is the lack of a shared requirements specification language for performance.

The good news is that this is a solved problem.

Key Action Needed: Upgrade Engineering to Align Supply to Demand/span>

Finally, the operational semantics. If 5G is going to be of any use to anyone but equipment salespeople, it has to demonstrate the difference it makes. That implies it needs to have improved mechanisms that allow for high-fidelity measurement of what QoE was being delivered, high-frequency control to deliver it, and new architectures that appropriately join these together.

This QoE control is a paradigm change. Today the radio people constructing a bandwidth supply, and the packet people chopping up whatever is there, using whatever transport protocols they inherited from the IETF.

The future is a demand-led model that is the antithesis of the IETF’s “rough consensus and running code” approach. That means a deep rethink because at present the radio folk are running the show, as they have always done. It’s a supply-led industry.

The problem has to be reframed as a distributed computing one that makes the radio subservient to the computational outcome. That’s going to ruffle a lot of feathers and upset a lot of power structures. The limiting factor in my experience is always human, never technical.

The alternative is that 5G gets stuck between two mutually incompatible goals, and serves neither well. Then eventually the whole ecosystem eventually gets bypassed in the 2020s, say by an IoT specialist player being bought by an Amazon, rather like how the iPhone overtook the handset space a decade ago.

Couldn’t ever happen? Ask him…

By Martin Geddes, Founder, Martin Geddes Consulting Ltd

He provides consulting, training and innovation services to telcos, equipment vendors, cloud services providers and industry bodies. For the latest fresh thinking on telecommunications, sign up for the free Geddes newsletter.

Visit Page

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

DNS

Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Cybersecurity

Sponsored byVerisign

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix