I’ve blogged a lot about the relationship between 5G and edge computing. In most of my blogs I’ve focused on the importance of coming up with a common software model, a kind of PaaS, that would allow 5G deployment to pull through infrastructure that would support generalized edge computing. Most of those who have chatted with me on that point feel that “the cloud” offers the path to success, but a few wonder why 5G’s NFV (Network Function Virtualization) reference doesn’t mean that NFV is the solution. Obviously, we need to look at that question.
The fundamental goal of NFV was to convert network appliances (devices) from physical network functions or PNFs to virtual network functions or VNFs. The presumption inherent in the goal is that what is hosted in NFV is the equivalent of a device. There may be chains of VNFs (“service chaining”), but these chains represent the virtual equivalent of a chain of devices. Not only that, service chains were presumably connected by “interfaces” just like real devices, and that means that the concept of a “network” or “service” had to be applied from the outside, where knowledge of the (popularly named) “gozintos” (meaning “this goes into that”) is available.
One reason for this was that the NFV ISG wanted to preserve the management/operations framework of the network through the PNF-to-VNF transition. In short, a VNF should appear to a management system that managed PNFs as just another device. The only incremental management/operations requirement that NFV should create is associated with the aspects of a VNF that don’t apply to PNFs. You don’t “deploy” a PNF in a software sense, nor do you have to manage the hosting resources, so stuff like that was consigned to the Management and Orchestration (MANO) or VNF Manager (VNFM), and the Virtual Infrastructure Manager (VIM).
5G specifications from the 3GPP, which have evolved over a period of years, evolved as other 3GPP work did, meaning they assumed that the functional elements were devices with device-like interfaces. 5G used NFV because 5G defined what NFV was virtualizing, in short. If we could say that generalized edge applications were (like 5G) based on virtualizing devices, this model would work, at least to the same extent that NFV works overall.
Well, maybe not totally. One issue with NFV that emerged more from the evolution of the proof-of-concept trials and vendor interests was that NFV turned out to be focused on services deployed one-off to customers. The most popular concept in NFV is universal CPE (uCPE), which is a generalized device host for an inventory of per-customer service features. NFV didn’t really address the question of how you’d deploy shared functionality.
I’ve said many times that I do not believe that NFV created a useful model for virtual function deployment, so I won’t recap my reasons here. Instead, let me posit that if NFV were the right answer, we would first see a bunch of NFV adoptions, and we’d see NFV incorporated in 5G broadly. Neither is the case, but let me focus on the second point here.
O-RAN is the most successful virtual-function initiative in all of telecom. What’s interesting about it from the perspective of edge computing is that O-RAN’s virtualization model (O-Cloud) is explicitly not based on NFV elements. Yes, you could probably map O-Cloud to the NFV Infrastructure (NFVi) of the NFV ISG specs, but the actual connection point is described in current material using terms like “cloud stack”. That means that just as you could map O-Cloud to NFV, you could also map it to VMs, containers, Kubernetes, and so forth. It’s cloud and not PNF in its model.
One obvious consequence of this philosophical shift is that the MANO and VNFM elements of NFV are pushed down to become part of the infrastructure. Whether it says so or not, O-RAN is really defining a PaaS, not the server farm which is the presumptive NFVi framework. The VIM function in O-RAN is part of O-Cloud, and there is no reason why “O-Cloud” is anything other than some generalized cloud computing framework. Thus, at this level at least, O-RAN is a consumer of edge services where NFV defines device virtualization services.
From this so far, you might be inclined to argue that the differences between the cloud and NFV approaches are little more than semantics. Couldn’t you consider any feature/function as a device? Isn’t NFV already pushing to accept containerization and not just virtual machines? Well, that’s the problem with simplification; it can lead you astray. To understand what the issues are, we have to do some further digging.
NFV, strictly speaking, is about deploying virtual devices more than creating services. The service management functions required by operators are presumably coming from the outside, from the OSS/BSS systems. In the cloud world, an “application” is roughly synonymous with “service”, and orchestrators like Kubernetes or Linkerd deploy applications using a generalized tool.
O-RAN, strictly speaking, deploys 5G RAN elements, so it’s a bit of a one-trick pony. Its service knowledge is embedded in the RAN/Radio Intelligent Controller (RIC) components, both the near-real-time and non-real-time pieces. The responsibility for management and orchestration of the pieces of O-RAN rest with them, and so you could argue that the RICs combine to act almost like an OSS/BSS would act in the NFV world, were we talking about a customer service (what NFV targeted, you’ll recall) and not a multi-tenant service like 5G.
In order to make NFV work for O-RAN, and for 5G overall, you’d need to add service knowledge, a model of the service. Even ONAP, which presumes to be the layer above NFV’s elements in the ETSI approach to virtualized functions, doesn’t have that (which is why I told the ONAP people I wouldn’t take further briefings till they supplied and properly integrated the model concept). That would be possible, but in the end all it would to is allow other deeper issues with NFV to emerge.
The long and short of NFV is that it isn’t a cloud-centric approach to hosting functions, and since hosting functions of any sort is really a cloud function, that’s a crippling problem. The cloud has advanced enormously in the decade since NFV came along, and NFV has struggled to advance at all. Some of that is due to the fact that NFV efforts aren’t staffed by cloud experts, but most is due to the fact that there are simply not very many people working on NFV relative to the number working on the cloud. A whole industry has developed around cloud computing, and you can’t beat an industry with a cottage industry. That’s what NFV is, in the end.
Technically, what should NFV be doing? There is really nothing useful that could be done at this point, other than to admit that the initiative took the wrong path. Whatever progress we make in function hosting in the future, in 5G, edge computing, IoT, or anywhere else, is going to be made in the cloud.