Yesterday, I talked about the problems of 5G and their possible solution. Today, I want to talk about a piece of 5G evolution, Open RAN. Open technology generally does well, but Open RAN seems to be bucking the trend, to the point where some are even attributing the overall spending slump for 5G to Open RAN’s failure. The question isn’t so much whether Open RAN failed, but why. Another question is whether it could have succeeded at all. Let’s try to answer both.
Of 51 network operators I’ve chatted with in 2024, 47 say that Open RAN has not delivered on their expectations, and 42 say they don’t believe it will. But what were the expectations it didn’t meet? Of those 47 operators, “driving new service revenues from 5G” was the big miss, and you can see how this leads to a view that it was an Open RAN failure that’s created the 5G problems. I don’t think that’s true.
Everyone in mobile networking knows that the biggest jumps in mobile infrastructure spending come when the 3GPP releases new standards. Given that mobile services are perhaps a lone beacon of satisfactory ROI, it’s no surprise that these upgrades to standards result in budgeted spending increases, and of course vendors love that. But with 5G, there was a perception that while the 3GPP 5G specs were fairly open and admitted to a wider variety of vendor participation, the RAN piece was still too monolithic. That gave a big boost to traditional mobile vendors with a strong RAN history and product set. The big problem was the next-gen eNodeB, in 5G gNodeB or gNB, which the 3GPP spec didn’t open up as much as some had hoped.
There were a number of initiatives a decade ago, aimed at opening RAN, some relating more to small cells and some with more general goals, these agreed to combine, in 2018, to form the O-RAN Alliance, which launched Open RAN as we see it today. The motivation, from an operator perspective, was to improve competition in mobile infrastructure, but of that 47 operators who said Open RAN hasn’t delivered, 45 said that the push was really coming from equipment-vendor competitors to Ericsson, Huawei, and Nokia, the incumbent mobile giants. I believe that Open RAN got its real start from vendors who wanted a piece of the 5G budget pie.
In today’s world, the credibility of an open initiative (and most everything else in tech) depends on media coverage. Imagine those eager mobile-equipment competitors going to the media with a story like “Eager 5G Infrastructure Vendor Wannabes Form Alliance to Take a Big Bite of 5G Equipment Budgets.” How many ad-serving clicks does that generate? So there was a race to “create” broad service benefits from the opening of the RAN to competition, benefits derived from the notion that competing Open RAN vendors would vie for market share with innovative features.
Open RAN technically focused on defining components within the gNB 3GPP element, with standard interfaces between them. The central concept was a RAN Intelligent Controller, which is kind of an orchestrator (somewhat like the NFV MANO element) for hosted features. A lot of competing vendors did RICs.
The problem was that it’s opportunity that creates competition, not interfaces. What features were provided to generate new services, new revenues. Open RAN permitted those features but didn’t provide them. And, truth be told, it’s not clear whether any truly valuable features could have been provided, because of the role the RAN plays.
A RAN is an element of connectivity. Some sources make the point that the Open RAN goal was to separate OSI Levels 1-3 for implementation, and those are very basic elements of network connectivity. What’s the biggest network service revolution of the modern age? The Internet, and it lives above all the layers of the OSI model. The value of the Internet is created on top of the connectivity, not within it. That model of OTT has in fact generated a huge opportunity with many new competing players, because it aimed competition at opportunity. There is none to be had at OSI Layers 1, 2, or 3. Open RAN is a mission impossible.
At least its stated mission was. But what it did do was to let operators indulge their desire to avoid integration and finger-pointing by settling on a single vendor source for mobile infrastructure, safe in the confidence that the open framework would prevent them from getting hurt by vendor lock-in. The single vendor choice, of course, was drawn from that same Big Three of 5G. So competing vendors failed? No, because Open RAN let them tell Wall Street they could hope to get a bigger piece of the mobile pie, which could help fend off a problem with stock prices.
Could the concept of RICs and feature hosting have worked? Yes, if we had a true edge computing opportunity, because it’s that which could have justified co-locating features with the RAN. I believe, as I noted in yesterday’s blog, that such opportunities exist, but making them a reality involves a lot more than defining how you’d deploy and manage them if they were real. We committed Open RAN to a mission to support something that itself had not been committed to.
Does this mean that Open RAN could still be redeemed? I’d love to say it could, but I think it’s too late. The hype cycle, the cycle that’s surely been involved with 5G in general and Open RAN specifically, cannot ever accommodate failure. Instead, it taints what didn’t live up to impossible expectations. In any event, edge computing is probably best handled as a projection of cloud concepts to a physical point closer to the user. On the far side of the 5G RAN, the side opposite the gNB, is in the spec the 5G Core, but what’s really there is the Internet. Why not move the edge not into the RAN, but to the place where the RAN connects to the Internet? Or, if you demand generality, into the edge of the IP network?
The network, whichever OSI layers you consider, connects things. The Internet revolution said that the role of connecting people that phones and texts demonstrate was no longer compelling. Today, it’s about delivering services and experiences that are, in a connectivity sense, just a user of the network like the real users are. That’s the challenge that the Open RAN model faces. Developers of the software to create those services and experiences are more likely to be rewarded on the Internet model than if they try to make their offerings a part of a connection service. I think Open RAN can’t fulfill that new-service mission, because no part of the connectivity network can.
