Separating the control and user/data planes is a fixture of 5G, but it opens some questions. One is whether the implementation of the two is also separate, whether software and hardware are disaggregated or co-dependent, and another is what specific hardware platform(s) might be considered for each. Perhaps the most important is just what a virtual 5G deployment should look like. There are no firm answers to these questions, but there are plenty of important points we can review.
Let’s start by contrasting the 5G virtualization approach to the NFV approach. NFV necessarily started with the appliances, the physical network functions (PNFs) that were the presumptive source of the logic to be virtualized and deployed. That was the mandate of the NFV ISG from the first. There was no current technology set for 5G to start with, but the presumption of 5G was that NFV would be used to deploy the virtual elements. NFV may therefore have influenced how the 3GPP framed 5G features.
There is no mandate for control/data-plane separation in NFV, but despite the fact that the control and user planes are separated in 5G, the 5G user plane contains both the IP control and data planes. The 5G user plane elements (RAN, UPF, XUF) are really bridging points between 5G and the presumptive IP network. 5G control plane elements are therefore really “service-plane” functions, at a higher level than anything we’d have traditionally considered the control plane.
For the service/control plane pieces, the 5G and O-RAN diagrams depict a series of functional elements that could be viewed as monolithic VNFs. These VNFs have interfaces that tend to look a bit more transactional than event-driven, and so a literal interpretation of the diagrams could lead to an implementation of 5G/O-RAN that wouldn’t be componentized below the level of the blocks in the standards diagrams. The structure has clearly influenced how people think about functions in 5G/O-RAN.
A LinkedIn post on O-RAN cites a Heavy Reading survey on “four types of Open RAN deployment options”, and the types are differentiated by what standard-box elements are put where. There is no discussion of how the functionality of a standard-box itself could be implemented as a set of microservices. Interestingly, the responses to the poll on which was the preferred approach showed nearly equal support for each, which to me suggests that people actually didn’t understand the issue and simply picked an option at random. Whatever the reason behind the poll, though, it’s the boxes and not microservices that are being distributed, and that could create a model of deployment that didn’t fully realize the benefits of the cloud.
What would the 5G cloud actually be, though? I think 5G features should be considered to be a set of distributed microservices from which “applications” that represent each of the functional boxes in the specs are assembled. The microservices themselves would be hosted on something appropriate for the performance, scalability, and availability goals of each microservice. Thus, there would be no need to look at types of deployment options; stuff deploys to where it has to.
5G functionality is really likely to be concentrated in metro and access networks. As we move inward from cell sites, we would first encounter places where hosting could deliver low latency but where pools of resources were unlikely to be cost-effective. These locations, from the tower inward to the backhaul, would likely be served by some sort of appliance or white box. Within the actual metro aggregation network, resources to host features in a true cloud resource pool could likely be made available. Thus, the stuff that 5G specs or O-RAN specs call the “control plane” could be hosted there.
There is no question that the 5G control plane (or service plane) can be run on fairly traditional hardware, either on dedicated devices or in the cloud as IaaS or containers. There is also ample evidence that the IP control plane can be run that way too. The question with regard to hardware arises with the user/data plane.
We know from the old days of NFV that even a decade ago it was possible to support data-plane handling with an x86 processor and the proper network adapter, at least for moderate data rates. We know from white-box design today that you can stuff a switching chip into a white box and build a competitive router (DriveNets has done it all the way to the core router level, through cluster routing). The only issue for metro 5G hardware in the data plane is the issue of resource pool efficiency.
As I pointed out earlier in this blog, resource pools exist where there’s enough activity to justify them, which means that they’re unlikely to be helpful close to the tower but could be helpful in the metro, particularly if you believe that 5G hosting is an on-ramp to justifying edge infrastructure that would serve other missions. The resource pool is most efficient where resources are homogeneous; a pool of disjoint resources is really a disjoint set of pools, and less efficient as the size of the individual “sub-pools” declines. So specialization of hardware in the pool could reduce efficiency, and also make edge missions that didn’t require special switching chips less profitable because those chips add to cost.
Separating the control/service planes from the data plane is a help in this sense, because it means that the more traditional control/service-handling missions are decoupled from the specialized data switching missions by design. It’s also true that since higher-volume trunks pass through data-plane devices, the device relationships to the trunks tends to mean that you can’t simply scale or replace a data-plane element by redeployment/orchestration. Something physical has to be done. Thus, you could imagine that the data plane would be supported by white-box configurations controlled by a cloud-hosted, pooled-resource control/service plane.
Perhaps the biggest question is how all this would look within a metro area. A metro area is almost certainly made up of multiple aggregation points that could be connected in a hierarchy, a mesh, or any number of ways. If we viewed each of these aggregation points as a hosting point for 5G (RAN and Core), then we might see each as a kind of single virtual element. O-RAN divides 5G RAN hosting according to latency demand—we have RAN Intelligent Controllers (RICs) for near-real-time and non-real-time features. That implies that the connectivity performance of the former differs from that of the latter, which suggests that perhaps each aggregation point has a “near-real-time” internal set of paths and a non-real-time external one.
It looks to me like the efficiency of an O-RAN deployment for 5G would be higher the more elements were supported within it, which means that connection performance could determine O-RAN implementation efficiency. That would mean that a fabric-like metro connectivity framework with high bandwidth and low latency could be highly valuable. If that’s the case, then there’s a mission for specialized network configurations and perhaps specialized network products in 5G metro deployments.
This same metro-cluster concept might be critical for edge computing, particularly missions like gaming. Remember that the location of “the edge” for any set of applications and users depends on the distribution of the users. If an entire metro looks like a single hosting point with full resource equivalence, then the number of potential users within that metro is its total population, and the number of credible applications that could be hosted entirely within the metro deployment would be larger.
There’s obviously some thinking required on the nature of 5G hosting, including not only the hardware but the topology and performance of the resource interconnection. There’s even more thinking required when we toss in the notion that 5G leads to a general edge capability that has to support a set of missions we can’t yet fully define or even characterize. Horizontal traffic within “the edge” is a critical element in setting the limits of latency there, and how we support that traffic may decide whether the edge has enough suitable missions to make a business case.