5G specifications have addressed the growing interest in “alternative technologies” in networking, embracing things like NFV and (some say) SDN. What is less clear is how effective the initiatives will be in the real world. A lot will depend on how vendors interpret the specifications, and in particular how far we take the concept of “abstraction” or “intent modeling” in defining implementations.
If you look at 5G or O-RAN diagrams, one thing that’s clear is that they usually represent boxes within boxes, meaning that there may be a big outer box, some middle-level boxes, and finally some detailed boxes. The traditional implementation approach would be to treat the outer boxes as simple functional groupings and implement the innermost boxes. In open-model 5G, the advantage of this is that it assures that in any implementation, the smallest functional elements are interchangeable.
Yes, that’s good, but we should have learned from past work in the telecom space that specifications can lead you astray. In the case of 5G, there seem to be three risks that must be considered.
The first (and easiest-to-understand) is that the specifications are calling out a sub-optimal technology. NFV is my favorite example here; the fact is that 5G is largely a cloud-native application, and what isn’t cloud-native might well be white boxes. NFV is not cloud-native, whatever its supporters say.,
The second risk is that that a given mid-or-high-level functional box could be “wired” to traditional technology concepts when it’s dissected into low-level boxes. 5G specifically calls out IP transport, but does that mean that the transport interface has to look like IP, or that the interior elements have to be routers? The latter would risk ruling out optimal use of SDN, for example.
The final risk is that the specifications, which view 5G as being created by virtual devices, imposes a software implementation model that may not be the right one. If we go back to NFV, we could argue that most of its sub-optimalism goes back to a literal interpretation of what was intended to be (and was stated as) a functional specification.
Let’s look at the O-RAN diagram (from the O-RAN Alliance) as a reference here.
The box inside the gray dashed boundary is O-RAN, and there’s a defined interface between O-RAN and the management and orchestration stuff above. Inside the O-RAN box we have five other boxes, many of which are subdivided into other boxes. One particular box, labeled “NFVI Platform: Virtualization layer and COTS platform”, doesn’t really fit into a functional diagram at all, nor does it present interfaces as the other boxes do. This one diagram demonstrates all three of my risks.
In my view, you have to embrace the notion that 5G hosting is an application of “edge computing”, and in fact is the application that’s likely to drive the baseline deployments there. Few would say that edge computing is anything other than a special case of cloud computing, and yet we’re calling out a network specification for 5G function hosting. NFVI, meaning NFV Infrastructure, is obviously NFV, which isn’t a generalized model for hosting functions. If it were, the ISG wouldn’t be discussing the difference between “containerized” and “virtual” network functions and trying to shoehorn cloud-native into the NFV model.
The next point that jumps out to me is that there should be no reason why someone couldn’t implement an entire higher-level box, filling in the interior any way they like, as long as the external interfaces to the box were satisfied. It might not be equivalently “open” in comparison with an implementation that separated every box, but it might offer benefits relative to those completely open approaches. Buyers would have to be aware that they couldn’t substitute things within the higher-level box (so implementations at that higher level shouldn’t show the elements within), but if the benefits outweighed the risks, buyers should have the option.
Another obvious point is that we have a RAN Intelligent Controller (RIC) in two places, one inside the O-RAN dashed-box and the other in the higher layer. If the only difference between these two RICs (the real-time and non-real-time RICs) is the latency of the stuff each supports, should they be separated at all? If they are, for performance reasons, separated, might there not be some mechanism required to coordinate their behavior?
A less-obvious, but perhaps more significant, point is whether some or all of the interior boxes are functions rather than explicitly separate virtual elements. If we were to review 4G Evolved Packet Core material, for example, we’d find that the Packet Network Gateway (PGW) and the Serving Gateway (SGW) are described as separate elements, but some material notes the two might be combined in a single device. Do specifications, including 5G and O-RAN, encourage separation when there’d be a significant benefit to considering consolidation?
The least-obvious and most significant question is whether any of the boxes should be considered separate devices/components at all, or whether everything should be a set of orchestrated microservices, which is what “cloud-native” would suggest. Remember my comment about how a “functional specification” for NFV ended up driving a stake a decade deep into the ground and tying the market to it?
The reason this is most significant is that “openness” implies the existence of fully interchangeable parts. If a true cloud-native implementation of O-RAN doesn’t divide itself into virtual boxes, then we’d have to know a lot about how the APIs and platform tools that hosted everything were defined, in order to know whether two separate parts would interwork. Do all microservices in cloud-native O-RAN have to be interchangeable?
We’ve still got way too many network thinkers involved in this and not enough cloud-thinkers. In the cloud, it’s critical to get missions aligned with technology early on. If we understand the basic notion of a “service” as a set of coordinated behaviors presented to a user as an experience rather than as pieces of discrete technology, we understand that coordinating the behaviors is central. We can dissect the behaviors, and the coordination, from that starting point. What the past proves is that when we try to describe something functionally, with no specific notion of that coordination to guide us, we tend to create an implicit implementation that we might fight for a decade or more to overcome.
Just as service lifecycle automation is inherently event-driven, so service lifecycle coordination is inherently hierarchical. We therefore have to assess just how far down the hierarchy we’ll push the concept of interchangeability versus simply openness. Is a black box representing all of 5G Core, presenting all the external interfaces, “open” if it can be substituted for another black box similarly presenting interfaces? Even if neither, or only one, can be fully decomposed into deeper interchangeable elements? That may prove to be a big question as we move forward with hosted service elements.
