Is there a reason to have proprietary technology in the 5G RAN? Is virtualization and disaggregation a good idea, or are there real costs and risks? Ericsson was quoted in an SDxCentral piece that outlines the case for a balance between open and proprietary. I want to come down on the issue a bit differently.
The sense of the Ericsson position is “‘There’s no doubt that when you build an integrated, purpose built system-on-a-chip (SoC) that you’re going to get better performance and get a better cost profile in the network,’ Jejdling said. As such, he expects vRAN and tightly integrated RAN, which comprises the vast majority of network infrastructure today, to operate in parallel in a hybrid environment.” I could agree with that, but still with qualifications, if the implied position it represents were true, but it isn’t.
If we build 5G based on a monolithic model, where appliances implemented both the control and user planes of 5G, then proprietary SoC technology might well offer some benefits. I would argue that such a model is a fundamental mistake, that the right model for the network of the future would separate control and data/user plane handling. The only problem with the vision of open RAN (O-RAN) in 5G is that we’re not taking the separation far enough. The core issue is that “data/user plane” point.
5G defines a “control plane” that represents the exchanges among the APIs defined for 5G by the 3GPP and by O-RAN. The “user plane” is really rooted in IP connectivity, and IP has its own control plane and data plane separation. Concepts like OpenFlow, and vendors like DriveNets, have touted the separation of control and data planes in IP networks as a benefit, and I believe it is, because it allows the performance-critical process of packet forwarding to be separated from the control-plane handling that’s much more like traditional event processing.
We have a number of excellent high-performance switching chips, notably the Jericho like from Broadcom, and if you separate data and control plane you can use them for the former, and the traditional hosted (x86) cloud processes for the latter. I believe firmly that the benefits of an open cloud-native implementation of the IP control plane outweigh any advantages of custom chips there. The best 5G implementation, then, might well be a combination of a white-box user/data plane and a cloud-hosted control plane. That’s obviously not what Ericsson is proposing.
It’s also not exactly what either the 3GPP or O-RAN is promoting. Prevailing-think on 5G is that virtual functions would provide the implementation of many/most features, which presumably would include the “user plane” and IP. You could implement the UP on white boxes, of course, but the standards are vague on how a decision to do that might impact deployment and management. That’s a problem in itself, IMHO.
Virtualization that fixes the relationship between virtual functions and real hardware is a bit of a paper tiger. Ideally, 5G should be based on the presumption that each of the boxes in the 3GPP or O-RAN diagrams are abstractions that could be implemented in the way that best fit operator requirements. There’s no reason to say that everything has to follow the same model, only that any loss of efficiency (capital or operational) that would be created by multiple models was considered and accommodated in the business case.
One thing this means is that concepts like NFV shouldn’t be a requirement for 5G, or for O-RAN. NFV dictates deployment and management relationships and that violates our theory that the abstractions associated with 5G (or any other carrier cloud or edge application) should be compatible with any useful realization. However, it doesn’t mean that we can just shout “cloud-native” and wave garlic at the operations werewolf to fend it off. There needs to be some attention given to the question of just how we create “universal” abstractions that can be deployed on whatever works and managed through whatever is available.
We also need to be thinking about the relationship between the various “control planes”. IP and 5G/O-RAN have their own control planes, but O-RAN defines the notion of a RAN Intelligent Controller or RIC, and there’s both a near- and a non-real-time RIC defined, which implies two levels of control plane for 5G, giving us three planes in total. Other services, including streaming video, would introduce their own “control planes”, meaning layers of functionality designed for service control and not for packet data movement. If everything in a data network comes down to pushing packets, which arguably it does, then we have to make sure that all these bosses don’t give conflicting instructions to the packet-pushers.
In fact, we should be thinking about how “layers” in networking work in the current age. The venerable OSI model was designed to describe open systems interconnect, but even a cursory look at the layers (all seven, not counting the layers that have been subdivided) shows that the definition is really about application-to-user communication overall. What is the overall model for a separate-control-plane world?
Is it possible to define abstractions for the control planes that, like the OSI model, are represented by interfaces between the layers? It seems to me that any attempt to create specific interfaces or features to abstractions in a virtual world limits the world you’ve worked to create. However, there could be “administrative” exchanges that could be defined. Could some rules about how layers communicated by possible and helpful at the same time? I don’t know, frankly, but I suspect that it would be possible…with a big “if”.
The “if” is “if we could create some high-level models of control behaviors. We know that control planes in IP exercise route control. We know that in 5G, they manage mobility. We know that CDNs work in part because a user’s request for content is redirected to an IP address that represents the optimum source. There are behavioral models we could identify, and we might be able to generalize them to create some of those high-level abstractions.
This is a process that has to be thought through carefully, so we don’t accidentally limit the opportunity scope of the cloud by limiting the abstract features and services it can support when we define models. Still, it’s a process that’s essential to guide thinking and development of both edge computing and carrier cloud. We’re on the verge of creating an edge mission with 5G RAN, and we can’t afford to get off to a bad start.