One thing that I think the last couple weeks have made clear is that, while there’s a clear business relationship between 5G hosting and multi-access edge computing (MEC), the technical relationship has been difficult to pin down. One reason is that most of 5G hosting discussions have centered on 5G RAN, and the open O-RAN model, and the MEC edge has to be more comprehensive. Can we find a broader perspective?
Fortunately, there are often multiple sources of insight for new technology implementations these days. For 5G, the core specifications are from the 3GPP but as THIS blog from Red Hat shows, there have been a number of initiatives to open up the 3GPP model. The best-known of these is from the O-RAN Alliance, which has done key work on creating an open model for the RAN. A less-known source, the Open Networking Foundation (ONF) has also supplied a reference architecture relating to 5G and multi-service edge computing (MEC). Unlike other specifications, the ONF ones go all the way from high-level functions to the elements of open-model hardware, so they offer an interesting view of what a totally open 5G/MEC strategy might look like. To do that, we have to take a brief look at 5G itself.
Mobile networks have historically been made up of three high-level elements, the radio access network (RAN), the mobility management piece (Evolved Packet Core in 4G, or 5G Core in 5G), and the subscriber management framework that was supported by the IP Multimedia Subsystem or IMS in 4G. For 4G networks, these were all normally built on proprietary elements that conformed to open (3GPP) interfaces, but more often than not came from a single vendor.
5G was designed to make use of open, hosted, components, though the support for that approach was weak in the 5G New Radio (NR, which is 5G RAN). The O-RAN Alliance strengthened the open-model RAN piece considerably, and this is important because early 5G deployments are what’s called “non-standalone” or NSA, meaning that 5G sits on the IMS/EPC mobility management piece. Full 5G implementation would require 5G Core, which is just getting to the point where vendors and operators are willing to bet on implementation.
The reason 5G Core is important is that most 5G functionality, and in particular most of the elements likely to be hosted in a server pool, are part of 5G Core. As I’ve said in prior blogs, 5G feature hosting is logically concentrated in metro areas, because metro areas are the roaming range of most users, and in particular the area where sessions would have to be maintained during roaming. Because 5G Core is metro-centric, it covers the same area that edge computing would likely focus, which is what makes 5G a potential driver for edge infrastructure.
The “however” here is that when 5G RAN and O-RAN are included, 5G reaches all the way to the towers and involves places where user density is too low to justify a server resource pool. Thus, open 5G appliances are important to fully realizing an open 5G deployment, and that means that not only do we need open interfaces, but common management practices that can span both traditional servers and specialized devices. This is one reason looking at the ONF approach is helpful; they offer a full solution architecture for open infrastructure. They also include 5G Core, which means that their stuff would definitely either sow the framework for MEC, or create a silo that would make MEC evolution more complicated.
The ONF approach to 5G/MEC has two components. Aether, the high-level 5G and mobile model, and it sits on top of the SD-RAN and SD-Core elements that map 5G/mobile to SDN. Those in turn sit on top of SD-Fabric, which is the network-layer model. SD-Fabric is in turn made up of four pieces, the ONOS SDN controller with broad capabilities, the P4 forwarding language, the PINS “adapter” element that creates a hybrid IP/SDN control plane and P4 compatibility, and the Stratum white-box operating system.
To put this into a more familiar perspective, the O-RAN specifications of the O-RAN Alliance map to the SD-RAN piece of the ONF model. The greater scope of the ONF story is one differentiator, and the fact that ONF (not surprisingly) focuses on SDN is another. The O-RAN model can be mapped to an SDN implementation of the user/data plane, but that’s not mandatory. With the ONF model, you can support a hybrid SDN/adaptive-routing model (via PINS) but SDN is the presumptive architecture.
White-box elements would normally run the Stratum operating system and the P4 language driver to provide flow-switching support for custom chips. On top of that is ONOS, which is both a distributed SDN control model and an application platform. While ONOS is modular and distributed, it’s “logically centralized”, and can be distributed to both servers and white boxes. This stack makes white boxes a logical part of the “edge cloud”, and unifies operations.
Functionally, as I’ve noted, the ONF 5G/MEC approach is a superset of the O-RAN model. At the RAN level, they are functionally compatible in that they both support a more elegant and open disaggregated RAN model than the 3GPP 5G NR RAN specifications would, they both include both near- and non-real-time RAN Intelligent Controllers (RICs) and they both include an explicit cloud-hosting element. The ONF model is what the ONF calls an “exemplar” of the O-RAN approach, so the correspondence isn’t a surprise.
The biggest difference between the two is that O-RAN allows an open-model implementation where the ONF defines one. That accounts for all the extra elements in the ONF model, and for the fact that the ONF model describes more at the implementation level, all the way down to devices. That, in turn, makes it extremely useful when we want to consider exactly how an open-model 5G deployment would look, and how it might relate to edge computing in general.
The ONF model defines the “edge cloud” in an implementation sense, and that lays out the way that edge-cloud applications are connected and sustained. It does not mandate a specific application architecture for edge-cloud applications, though it encourages modular, even cloud-native, approaches as well as supporting NFV at the connection level. The way this is done is best related by looking at the ONOS RIC.
The real-time RAN Intelligent Controller is the heart of the open-model O-RAN architecture. The ONF approach creates a multi-layer real-time RIC whose top is the A interface defined by O-RAN and whose bottom is the southbound E2 interface. The first layer above the bottom is the distributed ONOS core functions of the RIC, which present their own API upward to RAN applications, and those in turn feed the northbound A-interface API. You can imagine the adaptation of this structure to generalized MEC requirements, but there’s no diagram of that in the ONF material (at least none I could find).
5G RAN and O-RAN specialization is built around the ONOS layer, so we could imagine a lower layer to ONOS that would present MEC connectivity APIs to underlying infrastructure, and APIs to edge applications running above and in parallel with the RAN components. The edge applications would not be expected to work like 5G RAN would work, but they’d have the same configuration, management, scaling and resilience, and connectivity options available.
This is, I think, a step forward in defining 5G as an edge application, and defining how other edge applications could be created. It’s not a complete picture because it doesn’t define the structure of such an application. 5G, arguably, isn’t a general edge application, but an application of a generalized edge, so perhaps that’s not something we should expect. What we do have is a picture of how edge applications could be structured/orchestrated, and how a 5G RIC model could be generalized to provide that.
A step, but not an arrival in force. What still remains is a framework for edge applications that addresses all the issues those applications might create. For example, can components shift from one edge to another if the user moves or user distributions in multi-user applications change? How does the optimum edge position get calculated? It seems likely that there’s another layer of tools needed to avoid application-specific silos, and we still don’t have a full understanding of what that new layer might look like. I’d sure like to see someone take a stab at it.