One area of 5G and cloud intersection is the 5G User Plane, a component of the 5G Core architecture. My readers know of my skepticism about 5G Core deployment overall, but I’m going to set that aside for a bit to deal with how the 5G User Plane could be considered a poster child for cloud-native thinking. It’s also, in my own view, a poster child for why “network virtualization” is different from “virtual devices”. In fact, the 5G UP may contain an example of how we got stuck in box networks in past virtual-network specification attempts.
In 4G, the Evolved Packet Core handles information exchange, the user plane function, and mobility management, the control plane function. EPC with CUPS (Control-User-Plane Separation) provides a semi-independent planar structure, but there are a lot of interfaces between the control and user planes, to the point where most agree that CUPS is “S-in-name-only”. 5G’s Non-Stand-Alone (NSA) model glues 5G’s New Radio onto the EPC model, making many of the 5G benefits (increased user speed and cell capacity) available quickly. This is the model of mobile 5G now deploying in most areas.
5G Core proposes a new model, one that simplifies control/user-plane separation and also simplifies the user plane overall. In theory, the 5G Core model would offer an easier way to introduce cloud-native behavior, because the control plane that really is a natural cloud-native application is less fettered by continual interfaces with the data plane. The data plane, or “user plane” of 5G core, is also potentially easier to assess for cloud support because it’s more purely “data”.
There are two points of interface between the 5G CP and UP functions. The first is the Access and Mobility Management Function (AMF) and the second is the Session Management Function (SMF). These interface with the User Plane through three defined interfaces. The User Plane in 5G is really a single dual-function element, the User Plane Function (UPF), which connects between the RAN and the data network. This singular UPF has, in the 3GPP diagrams, a “side” facing the RAN and another facing the public data network (PDN)
Referencing the 3GPP diagram of the UPF, we see the Access Network (usually RAN) connecting to the data network (like the Internet) through a UPF that’s decomposed as an Access network element and a PDN session anchor element. Obviously, these elements are likely distributed to the point where the terminations of their respective networks occur. In an appliance/device view, they can be mapped to individual VMs or containers, as they are in the model shown in Intel’s material, which would imply a “UPF network” made up of hosted UPF instances, meaning virtual devices. This same “virtual UPF instance” approach is widely referenced to illustrate selective traffic routing to different data networks or to different on-ramps of a data network.
The advantage of this literal approach to UPF is that if we presume that everyone implements a UPF as either a device or a virtual device, then the implementations could be interchangeable. If we were to assume that the UPF was a network-level abstraction with multiple inputs from the (R)AN and multiple PDN outputs, then the implementation of that abstraction would be a potentially proprietary black box, and at the least would probably not be open to internal substitution of parts or vendors.
The question is whether, to avoid catching cold, we expose ourselves to a more serious disease. If we want element-per-element substitution within our virtual UPF, then we must define an internal structure of elements, which means we now create that box network and turn a functional specification or picture into an implementation architecture.
It’s hard, given that we have few if any full-scale 5G UPF deployments, to say how serious our box disease would really be, but we can refer to an example I’ve used in the past to get a hint as to what we might be losing with it. Google’s core network is SDN with a layer of BGP around it. An SDN core with a layer of UPF interfaces around it could serve as a virtual UPF network, without dictating the structure of the interior. This would open the UPF implementation not only to SDN, but also to any form of cloud-native hosting that could deliver the edge functionality. It doesn’t say you can’t have virtual-device UPFs, even.
A virtual UPF network could attach to all ANs and all PDNs, do all the selective routing internally, and present a very simple vision—essentially one huge PDN—to the control plane. We would be free to adopt any set of internal behaviors that would meet those external interfaces, which means we could do more to optimize cloud-native elements. This, I think, is how cloud-centric players would do a 5G UPF.
If we were to pick something like SDN as the implementation, we could reference a standard SDN implementation, such as one based on OpenFlow with a central controller, to avoid the lock-in problem. Further, a central controller could provide the linkage between the virtual UPF network and the control-plane elements (AMF and SMF). This, I believe, would simplify the creation of a virtual control plane and the use of cloud-native elements.
One reason to consider this is that with all the usual nomenclature changes we’ve come to expect from new standards, 5G UPF retains a lot of the concepts of EPC, including the tunneling. SDN could manage session connections to the right cells without explicit tunnels, particularly if the mobility management control plane piece talked to a central SDN controller. I argued even before 5G that we really needed to think about how to use SDN to implement a virtualization of the whole of EPC rather than using VNFs to replace appliances in the various EPC element roles. I believe that’s even more true of 5G. Why is it that we can’t seem to shake box-think, anyway?
I’m not necessarily against the notion of having an abstract black-box UPF that is implemented in the way that Intel and others (who do UPF-instance hosting) have described. What I’m against is making the decomposed contents of the black-box UPF visible when the box isn’t being recognized. Virtualization should always be abstraction and decomposition, and in the 5G Core UPF model, we’re seeing only the decomposition. The NFV ISG went wrong by taking a functional architecture literally, because it foreclosed a true cloud solution. The same could happen to 5G if we’re not careful.
