Like 5G, O-RAN is being positioned as the pièce de résistance platform for the next generation of hardware for the RAN. And there certainly seems to be a ration of organizations hopping on the O-RAN bandwagon, especially of late.
Brushing aside the hype, O-RAN is an attractive solution to the daunting challenge faced by 5G and wireless networks in general. However, using my favorite meme, all that glitters is not gold, has some applicability to the state of O-RAN.
Before we drill down on this, just for the fun of it, let us do a quick review of O-RAN. The particular definition varies slightly from organizations like the O-RAN alliance to major players involved in it (like Nokia). However, no matter how you slice and dice it, O-RAN is all about disaggregation of the RAN and open architecture. By doing that it offers an environment for any piece of O-RAN-compliant hardware to work with any other piece of O-RAN hardware – that is the bottom line.
One would think that would get everyone on board. However, there is so much more to this beyond the technology. The situation is not unique to O-RAN. Similar situations exist with openAI, various compute platforms, and dozens of others. Even elements that have achieved accepted open status, Unix for example, are not necessarily the de facto go-to for everything and everyone. However, with 5G it would definitely be smart for everyone to be on a common hardware platform, open or otherwise. And, in a perfect world, open hardware would be the best solution.
There are a lot of places where open standards exist and work well. Car parts are an excellent example. With tires, a certain size tire, regardless of who makes it will fit any vehicle that can run that size. Other parts, alternators, belts, batteries, etc. as well. If a battery is specified as a certain group, no matter who makes it, it will fit the particular vehicle that uses that group.
The same should be true for O-RAN. With O-RAN the focus is on its three main building blocks – the radio unit (RU), the distributed unit (DU), and the centralized unit (CU). The idea being that any manufacture’s O-RAN RU will work in another manufacturer’s DU, or CU O-RAN, system that complies with the O-RAN standard. There are other layers, of course, but these are the critical ones.
Open hardware systems bring to the table more competition, better designs, lowered CAPEX, and user benefits such as adding features, increasing deployment flexibility, capacity scaling, and upgrading components. As well new services, such as AI layers and virtualization are easier to integrate.
However, proponents of the other camp, proprietary hardware, take some pretty strong positions and present similarly strong arguments. Proprietary hardware has better profitability because there is less competition. There is also the question of reliability across multiple vendors.
Proprietary hardware locks in a particular vendor – job security if you will. Deals are made, hardware is locked in and the marriage between the vendor and user is inked. It provides a known supply chain, service sector, and responsibility platforms. It is a mature model and is very well understood and has been accepted since the beginning of wireless time.
Proprietary hardware is always more expensive than open hardware. Tertiary elements such as service, parts, warranties, and the like are locked in as well. Simply put, because proprietary hardware is more profitable than open hardware, vendors find the proprietary model much more desirable.
With open hardware, much of this becomes a free-for-all. For example, who will service the equipment? If a third party is involved in service and something goes wrong, there is often a lot of finger-pointing that happens. And who do you hold responsible when something goes wrong? The vendor? The servicer? Or do you simply self-service and fight with the vendor whether it was their equipment or some other cause.
What about longevity? Say a particular vendor goes out of business and its hardware is no longer available. The user is stuck with replacing that particular hardware with someone else’s proprietary hardware. That can be a nightmare. And, quite honestly, vendors like being locked in. Users, not so much.
There are also the issues of stability, capacity, and scalability. These have been challenging to all open platforms since the idea evolved. Some, such as computer software and hardware have conquered these, but it takes time and the more complex the platform is (such as O-RAN and openAI) the longer it takes to achieve stability. And even mature open platforms continue to have occasional (some regular) burps.
Next, there are peripheral components. AI is set to play a huge role in wireless. It is critical that AI understand the complexities that accompany 5G – ultra-reliable low-latency communications (URLLC), dynamic spectrum sharing (DSS), Massive MIMO, dynamic and intelligent, software-driven spectrum allocation, virtualization, software-defined networks (SDN) and many of the other new characteristics of 5G.
The use of AI in the RAN presents the same challenges as with other domains. AI has natural biases due to the way algorithms function. By nature, it has errors and dependencies. It is more visible in platforms such as facial recognition, but it also exists in stock analysis, hiring, employment, and others. There is no reason not to assume it will have similar issues in the RAN.
And, of course, let us not forget security. The more open the interface the more difficult security becomes and the larger the threat surface. Add to that the eventual massive deployment surface of this platform and its tangential vectors (Internet of Anything/Everything (IoX), for example),and it certainly becomes critical.
Also, in the 5G space, strict latency requirements, for example, are added to the queue. That requires similarly strict encryption requirements (that is a very interesting discussion but too lengthy for this column). And, with the tens and eventually, hundreds of billions of devices expected on networks as 5G matures, keeping rogue devices and bad actors at bay will be challenging.
So, what else is holding up the rapid deployment of O-RAN, which will be essential for 5G? The technical issues remain quite challenging regardless of how rah-rah some proponents of it, are. Some even claim it will never happen. But there are other issues as well.
But, all of that aside, just getting all the players on board will be tantamount to herding cats. There are a lot of different players with a variety of angles and getting everyone to agree is difficult. This is a cooperative environment. For the manufacture, open interfaces require best practices among ALL manufacture to ensure the integrity of the link – the play nice, everybody, scenario. And frankly, this is a big change to a very well entrenched and mature industry – resistance to change will be hard to overcome.
Beyond that, there is also the issue of retrofit. That is not a problem with the greenfield segment of 5G. However, in existing equipment that is a significant challenge.
A recent report from the Dell’Oro Group predicted that O-RAN will not account for more than 10 percent of the overall market by 2025. ABI Research does not expect the CAPEX of O-RAN hardware to surpass traditional RAN until close to the end of this decade.
In the end, and down the road, O-RAN will, most likely, get the issues ironed out and, unless an unknown platform suddenly emerges, become the standard hardware platform for 5G. The really tricky part is for 5G development to start buying into O-RAN, or at least prep for it, and not keep adding proprietary hardware just to get 5G out.
So, while the noise about O-RAN seems to be making it the answer to all of our deployment problems, that really is not the case. It has a bit of a haul in front of it. But it is fun to follow the various threads.
Ernest Worthman is an executive editor with AGL Media Group, a senior member of IEEE and an adjunct professor at the CSU Walter Scott Jr. College of Engineering.