Is an open 5G infrastructure model really possible? Many (and, of course, most of the 5G vendors) have said it’s not. There are providers of pieces of the 5G software in open-source form, but one area that’s been particularly challenging has been the 5G New Radio (NR). Now, just perhaps, it might be possible, thanks to an announcement by the ONF on August 25th, but there are still some rivers to be crossed on the way to a true, open, 5G.
The ONF is launching an open project for Software-Defined RAN, which will be an exemplar implementation of the 3GPP open-RAN and “consistent with” the O-RAN specification. The key piece of this is an ONOS (this is the open-source project for a white-box operating system that came out of AT&T’s DANOS) implementation of the RAN Intelligent Controller (RIC). The RIC implements interfaces to the O-RAN Central Unit and Distributed Unit (O-CU and O-DU, respectively) of the 5G NR protocol stack, often provided by the RAN hardware vendors.
You may wonder why it’s important to have this project at all, given all the noise we’ve been hearing around O-RAN. Remember that O-RAN is a specification, not a software package. You can implement O-RAN as a spec without using open-source software for any piece of it, and the current market model is largely focused on that. Even the SD-RAN group will support “closed-source” components. What the ONF is hoping to do is create an open-source software implementation of O-RAN, which would then support open-model 5G radio networks. Combine this with other open stuff in the 5G Core software space, and you have a complete open-source-based 5G implementation.
There are two pieces of this story that we need to look at. The first is why it’s going to be important, which in part relates to how this concept fits in with other 5G developments, and the second is just how the new project, and in particular the new RIC, work. We’ll take them in that order.
One truth about 5G projects that permeates every possible 5G deployer is that nobody wants to self-integrate. 5G, like any network technology, is a rather vast ecosystem, and getting all its clocks to chime at the same time is a formidable effort. Even Tier One operators have been reluctant to try to do a best-of-breed 5G story, to the point where companies who attempt it get a lot of ink (Dish, recently). For Tier Twos and below, there’s little hope they could acquire and retain the skill sets.
So 5G in any semi-open form cries out for an integrator? Get one, you might think. The problem there is that it’s hard to be an integrator with stuff that you don’t have rights to. If we could build 5G from totally open-source software, any company could set out to be the “Red Hat of 5G”, but that’s not been the case. This new initiative could make it happen.
Even public cloud provider efforts to get into 5G would be facilitated by the availability of a fully open 5G NR implementation. All of the public cloud providers are now interested in becoming the “carrier cloud” hosting point for operator 5G Core implementations. Full 5G will require that there also be a 5G NR available, and if this new initiative really does what it promises to do, it will make a cloud-native 5G NR software stack a reality. That might then augment the current drive toward mobile-edge computing (MEC) and allow public cloud providers to offer MEC hosting.
There are plenty who think this is essential for 5G. A Light Reading article by Telefonica’s CTIO is all about the importance of having operators take advantage of open 5G strategies, and it’s obvious that this is a sincere hope. The challenge is that we’ve had plenty of hoping in the past, and the results haven’t measured up to expectations. We have to go into the technology details of this announcement with that in mind. Not discouraged or dismissive, but wary.
That gets us through the “Why? of this discussion, so it’s time to move into the “How?” To do that we have to start with the O-RAN architecture, the best reference for which is HERE and HERE. The architecture shows a service management layer (which might be any of a number of things we’ll get to in a bit), and a RIC layer that make up a central piece, and a set of distributed pieces that represent the RAN head-end elements. In the classic 5G stack, the structure is monolithic, and the goal of the SD-RAN process is to open up the critical pieces, which is done by supporting an open “xApps” model for features, interfacing to the RIC, which then handles the down-the-stack interfaces. This is a more disaggregated and cleaner approach, frankly, than the classic 5G NR stack, even discounting the open goals.
The specific things being implemented are pieces of the “near-real-time” layer of 5G NR, including the nRT-RIC built on the ONOS platform (µONOS-RIC), and “exemplar” xApps (starting with handover and load balancing). Radio Resource Management (RRM) is handled at this level, and it’s the functional core of 5G NR capabilities, so it makes sense to quickly offer an open platform to provide useful/necessary features. The RIC is also the element that controls (via the 5G CU-C and CU-U) the control- and user-plane connections between the RAN and the 5G Core. That makes this approach particularly interesting in terms of creating 5G-wide service feature control.
That, usually, is the province of the orchestrator layer, and that raises one of the points we have to consider regarding the future of the initiative. I’ve already noted the point that traditional vendors don’t like O-RAN or SD-RAN much (the bodies involved in the initiatives admit as much). There is strong support from operators, software vendors, and other telecom projects (like TIP), but there’s a big chunk of telco-land that this will have to work with, including orchestration.
The “big chunk” point is important, because many of the projects aimed at telco infrastructure have suffered from myopia; they see only what’s close. Any carrier service is based on a fairly vast ecosystem, and that’s especially true of mobile services. Vast ecosystems make difficult projects, so even telco standards tend to break things into pieces, and that’s particularly true of projects like SD-RAN, which has an explicitly limited scope.
Pieces mean integration, though, and that’s always a boondoggle. Operators hate to have to piece stuff together, and hate finger-pointing when something goes wrong. That makes it essential that a new piece to a puzzle like 5G infrastructure gets fit somehow into the Glorious Whole, and the ONF material can’t really take on that task.
The dependency on other elements also put a new concept at risk for “failure by association”. The diagrams you see in presentations about SD-RAN focus on things like ONAP and NFV MANO for orchestration, and some of the diagrams show an NFV component within the 5G NR stack implementation. These are at best big-carrier concepts, and at worst, useless burdens. Certainly, enterprise 5G, which an ONF slide cites as a market with “lots of untapped potential” isn’t going to see much tapping if all this telco-centric baggage is part of the implementation.
A kind of associative failure would be a shame here, because the concept behind the ONF RIC is insightful, forward-looking, and cloud-modern, at a time when none of those attributes can be claimed by much in the carrier space. I’d love to see the whole of 5G Core done this way, rethought to true cloud-native-and-service-mesh form. Perhaps some eager cloud developers will take that on.
I think that this open-source approach to O-RAN is potentially a great step, but it’s going to have to get more populist in order to be accessible to even Tier Three operators (and some Tier Twos) much less the enterprise. People will want open-model hardware suggestions, and most of all, lighter-weight, less big-telco-standards-centric operations elements. Get that in place and this initiative could do something important and profound to the 5G space.
