Your Network's Edge®
Blog Post
You are here
Distributed NFV and Multi-access Edge Computation
NFV: Not just centralized
Nov 19, 2023
Back in 2012 a group of leading communications service providers joined forces to form the Network Functions Virtualization Industry Specification Group (NFV ISG) under the aegis of ETSI. Since then this group has grown to more than 300 companies and has produced scores of publications. The goal that united all of these companies was implementing networking functionalities in software running on standard server platforms, rather than on dedicated hardware purchased from vendors, in order to reduce operational expense and to accelerate adoption of new networking technologies.
The RAD approach was acknowledged in the NFV ISG’s original October 2012 NFV whitepaper, which stated:
Network Functions Virtualisation aims to address these problems by leveraging standard IT virtualisation technology to consolidate many network equipment types onto industry standard high volume servers, switches and storage, which could be located in Datacentres, Network Nodes and in the end user premises.
Today, the hosting of VNFs in CPEs, variously called vCPE or uCPE, is recognized as the most attractive NFV use case.
RAD realized at the time the importance of this aim but was troubled by the emphasis being placed by the majority of NFV ISG participants on centralization of all functionalities in data centers, in order to achieve economies of scale.
Being a CPE vendor, we perhaps understood better than others that certain network functionalities must, and some should, be left at the customer premises, including:
- performing functions that are required to be local (FM, PM, encryption, etc.)
- reducing delay from source to processing
- reducing requirements for high bandwidth for long distances
- maintaining locality of data.
MEC: Mobile (Multi-Access?) D-NFV
Two years later another ISG was formed in ETSI, focusing on edge computing for mobile networks. Mobile Edge Computing (MEC) originated with the introduction of servers capable of running VNFs inside cellular base stations, but over time was extended to servers somewhat further into the radio access network (RAN). In 2016 ETSI changed the meaning of the MEC acronym from Mobile Access Computing to Multi-access Edge Computing, coming full circle back to RAD’s original Distributed NFV concept.
Distributed Network Functions Virtualization (D-NFV) is an advanced approach within the broader Network Functions Virtualization (NFV) framework. It aims to virtualize and distribute network functions across various locations rather than centralize them in data centers. This model brings network functions closer to the edge of the network, enhancing performance, reducing latency, and increasing flexibility in deployment.
The original MEC paradigm provides an edge-located “cloudlet” server for hosting mobile end-user application close to the cellular subscribers, in order to drastically reduce response time, increase availability and QoE, while also reducing congestion in the RAN and mobile core. The MEC platform further provides persistent local storage and provides APIs over which applications may obtain mobile infrastructure information such as location, UE identity, and RAN information (such as the cell identifier or whether a handoff has occurred). Finally, MEC defined a service platform whereby third-party applications may discover, consume, and advertise services.
From NFV to MEC
So what is needed to integrate MEC functionality into a network?
Starting from the Network Functions Virtualization (NFV) architecture:
A first attempt at a MEC architecture supporting virtualized application functions might look something like this:
Here we have augmented the standard NFV architecture (in black) with non-network application functions and mobile services (in blue). However, this does not take into account the services that retrieve information from the mobile network needed for some mobile applications.
Adding these and the mobile network infrastructure itself to the infrastructure we obtain:
Note that we leveraged Network Functions Virtualization concepts by implementing the “services” as virtualized functions over the NFVI, and connected them to the mobile network infrastructure in order to access the needed information. As in NFV the end-user may communicate with the OSS using a user portal, but in MEC cases we added a direct link to the AFVO to enable an application running on the UE to directly interact with the AFVO.
But how do the applications and services communicate? We certainly do not want a VAF requiring a service to escalate the requirement to the AFVO, nor for every interaction to traverse switching in the NFVI. Here is where the service based design of the MEC platform comes to the rescue.
We’re almost done. Translating terminology AFVO → Mobile Edge Orchestrator, VAFM → Mobile Edge Platform Manager, we almost get the MEC architecture
The first difference is that the VNFs and their related support elements do not appear here (but they reappear in MEC documents dealing with coexistence of MEC and NFV). More significantly, the MEC architecture adds direct communication between neighboring MEPs, a lifecycle management proxy between the UE and the MEO, and the ability to insert VAFs by redirecting user packets via DNS proxy.
To MEC or not to MEC?
How much of the Mobile Edge Computation architecture is actually required for non-mobile multi-access edge computation? The services (UE identification, RNIS, location awareness, etc.) are either irrelevant or inherent in the wireline environment. Without these services, the platform can be replaced with standard NFV service chaining (with the exception of the service based elements) and the proxies are mostly superfluous. So, we return to something akin to our initial attempt at adding VAFs.
So, do we ever need the full-blown MEC framework for non-mobile cases? The answer depends on how application functions are triggered. If VAFs, like VNFs, are ordered via the orchestration system then the service-based platform is not needed, and the NFV architecture furnishes the required tools. If the application requires triggering of VAFs directly from end-user applications, then the proxies and the service platform greatly simplify operations.
Interestingly, the close association between mobile networks and the service platform has recently been reinforced. 3GPP has incorporated a Service Based Architecture (SBA) as part of 5G. The SBA can be considered either a MEC enabler (the MEC ISG view), or an alternative that renders MEC superfluous.
We anticipate future developments in NFV, subsequent releases of 5G, and innovations in cloud services frameworks to rewrite this story.
About RAD's Blog
We’ll be blogging on a wide range of hot topics affecting service providers and critical infrastructure network operators. Our resident experts will be discussing vCPE, Cyber Security, 5G, Industrial IoT and much, much more.