The Role of Hype and Exaggeration in 5G Evolution

While it’s not an argument made out in the open very often, sellers have always debated the value of “truth” relative to the value of hype and exaggeration. The debate has increased in volume in the last decade as sellers competed for media visibility, given that the media is focused on what gets the most clicks not what’s the objective truth. One of those objective truths is that often hype and exaggeration end up hurting things. “Bulls**t has no inertia”, as I’ve often said, so it gets out there faster than any real product, and changes with the whim of interests faster than anything tangible could change.

So it is with mobile network evolution, 5G and beyond. Talking with vendors, network operators, and even enterprises over the last year has let me identify some specific ways where hype and exaggeration has hurt 5G and mobile services, and the hurt is continuing. The question is whether the hurt will be just pain, or be fatal.

The first of my hype issues is 5G was hot in the media years before there was any hope of deploying it. What’s the difference between a modern stealth fighter and a UFO? Answer: A UFO isn’t going to land nearby and present itself for inspection, so everyone is free to assign UFOs any characteristics they find interesting. Well, 5G was a UFO, and so all manner of promises were made for it. The chance of any of them being realized in the near term was zero, and many of these early myths continue to be featured in 5G stories and even marketing. All of this set up expectations in the market, and all of this also influenced both vendors and network operators to base future growth on 5G.

This first hype issue was a driver for the second issue, because you can’t keep saying the same thing to the tech media and expect to get continued coverage. To make things worse, the fact that 5G was hyped prematurely was no barrier to stories criticizing 5G progress. That encouraged our second issue, the promise that 5G Standalone would finally realize 5G’s potential.

5G has always had two potential models, the “standalone” and “non-standalone” or SA and NSA. The latter model deployed 5G’s radio network on top of 4G/LTE packet core, and the latter deployed the full 5G core. Many of the 5G features promised were in truth attributes of the 5G Core technology, but the features that were visible to the average smartphone user were almost entirely delivered in the NSA version. Today, there is almost zero chance you’d know, as a consumer, which 5G model you were using, but there are stories that promise that when 5G SA deploys, all will be grand. This has the effect of pushing unrealistic views of 5G impact into the future.

A further obfuscation of the impact of mobile standards changes is the growing 6G hype. We do not, at this point, have fully resolved 5G specifications and there’s already a wave of publicity on 6G. Obviously, if 5G’s UFO properties are waning in the face of actual service deployment, it makes sense to move on to the next thing. The troublesome thing about the 6G hype is that it’s coming when we know less about 6G than we did about 5G at the same point in its evolution.

6G stories have the same impact as 5G stories did, with regard to the actual progress of 6G deployment. They also have a new and truly unfavorable impact on 5G, something that didn’t happen with 5G and its predecessor 4G/LTE. When 5G came along we had already deployed 4G/LTE, but because 5G isn’t really fully deployed at this point, there’s a risk that 6G stories will overhang 5G. The good news is that such an overhang might actually help by diverting the “UFO” stories to a technology that’s not going to happen for years, and letting both operators and vendors get on with the uninteresting task of actually deploying something.

But then there’s the next of our hype-and-exaggeration points, 5G deployment is moving forward by applying cloud-native technology to networking. Every step we take in 5G, so the story goes, takes us closer to moving telcos to the “telco cloud” and cloud-native technology. That, by implication, moves us closer to edge computing and the expansion of applications that the edge would bring about. But is any of this true? No, probably not.

The first problem is that even within the cloud community there’s some debate on what “cloud-native” means, and there’s even more uncertainty within the telecom community. The fact that the term isn’t even reliably and consistently defined makes surveys difficult, but an analysis of my interactions with telcos over 2022 suggests that well over 70% still believe that 5G uses NFV. About the same percentage believe that “cloud-native” means “containerized” as opposed to virtual machines. Almost all of those who believe that 5G uses NFV think that the NFV ISG’s initiative toward “containerized network functions” will make everything cloud-native.

If there’s more to “cloud-native” than containers, it’s arguable that it has to be related to serverless or functional computing. A function is fully scalable, totally stateless, and in many respects an ideal element of a state/event processing model. That’s what most protocol handling is like, and in particular it’s a good approach to handling signaling versus data path, which is the primary mission of hosted functions in 5G. But unlike containers, which have largely settled on Kubernetes for the operationalization/orchestration model, there is no single model for functions and the suitability of serverless/functional computing for telecom issues varies with the implementation.

The second problem is that 5G feature hosting doesn’t necessarily mean hosting in the telco cloud. Some of the RAN features, for example, would likely run in places where little else was being hosted, and thus could well end up simply being white boxes or server-hosted features, not depending on a resource pool. Many telcos are looking at using public cloud providers to host features, which could mean that “telco cloud” isn’t going to happen at all, and thus won’t drive edge computing.

The third problem is that we can’t really define what “edge computing” is beyond saying it’s at the edge. Why is it there? If we can’t answer that question, we face the problem of justifying deployment of a more highly fragmented resource pool, which is inevitable if we host at the edge. If there really is a special class of applications that require edge hosting, we need to ask what specific features make that true, and how platform software in the edge locations would support those features.

All of this combines to drive us toward a messy evolution of 5G infrastructure, and the truly sad thing is that this was unnecessary. The cloud existed very early in the 5G standardization process, and it existed before NFV was launched. A reasonable architectural vision of feature hosting could have given us an abstract model of service feature hosting that we could have specificized to any new cloud thinking as well as applying it to the cloud’s state of the art.

Is it too late for that? That’s a hard question to answer. We have a lot of 5G deployed, which might have to be retrofitted if our abstract model didn’t conform to the current implementations. On the other hand, we also have only limited 5G Core implementations deployed, and it’s likely that the major impact of 5G on edge computing would come at the point where RAN and Core link, which is the metro area. That, as it happens, is also the sweet spot for edge hosting, because it’s close enough to the edge to ensure latency is low, but deep enough to serve the number of users needed to justify a real resource pool. We may still have time to think about “5G/6G”, “cloud native”, “telco cloud”, and “edge computing” in a realistic and holistic way, and that would be a good thing for all.