Among the enterprises and network operators I talk with, respect for the current level of government functionality is limited. Given that, it’s interesting that according to a Light Reading piece, the DoD and other agencies are looking at promoting open 5G deployment by holding a forum on advancing the RIC, or RAN Intelligent Controller. This is one of those ideas that has plusses and minuses, so we need to take a look at the overall 5G RAN and virtualization scenario to see how the two play out.
In the acronym, the “R” stands for RAN, which pretty much tells us that a RIC is an element in the radio network and not in 5G overall. It’s a part of the Open RAN model, not a requirement of the 3GPP 5G architecture, and most of the vendors and operators I talk with agree that the underlying goal of Open RAN is to reduce the advantage that radio network incumbency and skills offer traditional mobile network vendors in 5G deployments. It’s worthwhile to expand the competitive field, of course, but the whole Open RAN initiative raised some questions that needed answers, and haven’t so far been even addressed.
The baseline 5G model, and the majority of current deployments, have presumed an appliance-centric model for the functional elements in the RAN, and in 5G overall. The presumption is that virtual functions would make up the majority if not all of the boxes in the architecture model, and that NFV would be the approach taken to deployment. Open RAN, when it looked at the pieces of the RAN that the 3GPP model didn’t decompose, took essentially the same approach, but had to deal with the fact that the decomposition of the RAN presented both similar issues to that of 5G overall, and a few that were very different.
The similar side is that we have to look at function hosting carefully when deciding just how device-like or software-like it has to be. NFV had this issue with virtual functions that were customer-specific rather than shared. An IP network is a shared resource. A firewall is customer-specific, and from the first many of these customer-specific feature elements were located on premises. There is no resource pool on premises, so you either have to pull the function inward to a place where you could justify a resource pool (meaning a point that handles traffic for a significant number of users) or you have to host your virtual function on a device.
NFV quickly moved toward the latter approach, with the notion of “universal CPE” or uCPE. Essentially, uCPE is a kind of cross between a white box and a small server, and it’s platform software is designed to permit NFV practices to deploy and manage the customer-specific features needed. Whatever the specific architecture of uCPE, it’s essentially a general-purpose virtual-function host. Truth be told, it’s far from clear that this approach moves the ball very much, since all it really does is marry open software to open hardware without addressing any other set of benefits.
It’s likely that uCPE was a kind of concept of convenience, since centralized VNF hosting can’t be done without enough work to justify a resource pool, which means that there’d likely be a high first-cost commitment needed by operators to get VNF-based services started. And that, friends, is where the “different” side of the 5G/Open-RAN issues come in.
A RAN starts with (you guessed it) the radio, which starts with the tower and antenna system, or the “fronthaul” piece of 5G. The three components of the RAN (the Radio Unit, Distributed Unit, and Centralized Unit) are all “real-time” elements, meaning that they are latency sensitive to the point where response times have to be kept to less than 10 milliseconds. The RIC is a two-component element of Open RAN, the first being a “Near-Real-Time” RIC with a response time of 10-100ms and the second a “Non-Real-Time” RIC whose response time could be greater than a second. The former is part of provisioning and management, and it runs what are called “rApps”, while the latter manages the components of the RAN and runs “xApps”. Some vendors and analysts say that the rApps and non-real-time RIC are like “policy control points” and the xApps and near-real-time RIC are like policy enforcement points.
From this description alone, it seems to me it would be better to characterize the RIC as an application, a piece of distributed middleware, than as an element, since the only sensible reason why you’d break functionality up like that is that you’re going to distribute some pieces toward the edge and pull others inward. Presumably the hosting rules for the two spaces would be different, and presumably the xApps would be functionally limited to a greater degree than the rApps. I think you could argue that managing rApps would/could be fully NFV-like and dealing with pooled resources, and that managing xApps might be more like uCPE.
The problem with this is that we’ve moved into defining a RIC as a distributed model for 5G service policy management within what’s still an appliance-centric model. NFV went astray because it started with a functional specification that generated boxes, and those boxes then became what were essentially virtual appliances. The whole Open RAN framework is supposed to be microservice-based, cloud-native. We need to look at the whole 5G picture, perhaps the whole notion of virtual-function-based services, from the top and see what elements are needed to make everything work.
I’ve said from the start that NFV should have been visualized as a model-driven, intent-structured, state/event machine or graph. Services would be decomposed to functions, each deployed and lifecycle-managed as the services were at the top level. The old-line device-centric notion of “interfaces” can’t be used unless these interfaces are really event-based APIs. Anything that could generate an “event” could then provide input to a model element. The combination of event and the state of the referenced element would then activate a microservice that would use the event information and the current model state data for the target element to do something. If we’re going to build microservice-based functionality for 5G, this is what it has to look like at the high level.
What, in this model, is the RIC? I would argue that it’s still two pieces, one representing functions that have to be run with low latency and another that can tolerate fairly significant latency. Could you argue that each of these pieces is represented by a model element; let’s call them “xAppRIC” and “rAppRIC”? I don’t think that’s optimum for Open RAN, any more than an appliance-centric approach was optimum for NFV. I think that each xApp and rApp would have a state/event table/graph and a set of microservices representing the processes to be run at each intersection. The difference between the xApp and rApp functions is what they function as. Where they run is an element of the deployment decision, which is (or should be) something made by software like Kubernetes.
But what about the NFV uCPE version? That seems to be what the Open RAN RIC model was designed to support. I think we could then say we had an xAppRIC and rAppRIC. I think the xAppRIC has to be considered the platform software for the RAN uCPE element. I think that the rAppRIC should be a container/cluster Kubernetes framework, but I think that the focus should be less on those two frameworks than on the lifecycle management of the virtual functions that have to run, the xApp/rApp functions. The RIC should be viewed as the shim between the important stuff you run and the deployment and connection of that stuff, and as long as you look at the RIC rather than at what it’s controlling in application terms, you’ll never really get an effective structure.
Some RIC vendors have told me that they agree with all of this, but also that they have no interest in trying to convince operators or other vendors to change the way that either NFV or Open RAN work. If those changes were made, they’d be able to adapt to them, but fixing collective standards isn’t their current mission, or in their interest. Most say they doubt that it could be done now.
If you want Open RAN to expand radically and create strong justifications for its adoption, you have to make it an effective overall strategy at generating wireless 5G revenue at a low cost. The RIC can’t do that by itself. I’m a big fan of open network models, and I think that 5G adoption could be improved by a good one. I just don’t think that the fundamental problem with 5G and Open RAN is the RIC. It’s the way that 5G was approached, and that Open RAN has inherited.
You can’t define an open-model network inefficiently and expect it to succeed, particularly if there are incumbents who can implement 5G RAN more efficiently without adhering to the Open RAN model. In fact, the big question IMHO is whether vendors like Ericsson and Nokia, who commit (to varying degrees) to support of open-model 5G, will end up falling into the old NFV trap trying to live up to that commitment. If they do, then we either have to get Open RAN right, or accept that we’re compromising 5G implementation in the long term, and everything else we do that follows that fatal appliance-centric thinking.
Network people, particularly network operator people, are not software people. Add to that the fact that any collective activity tends to be as much about competition among the participants as cooperation between them, and it’s no surprise that the framework for things like NFV and Open RAN end up being at least a bit sub-optimal. The chances that the government can fix it, IMHO, is minimal, and I think NFV’s evolution has proved that early errors in design are almost impossible to fix down the line. I guess we’ll have to hope that 6G manages to get it right.
