Merging NFV and MEC, the 5GCity approach
Gabriele Baldoni
To achieve is promises, of low latency and high bandwidth, 5G networks will rely on flexible programmable networks, leveraging well known technologies such as Software Defined Networking (SDN) and Network Function Virtualization (NFV), but a key aspect of 5G is be the possibility to provide low latency connectivity to a diverse set services and application, to achieve this promise 5G as to leverage also on network devices that typically are at the Edge of the Network, and will also provide an abstraction over the actual infrastructure that will be composed by essentially two tiers, the core of the network, providing a cloud-fashion infrastructure, and the edge of the network, that provide also computation, storage and networking capabilities as well as services that are related to the proximity with the end users.
In such kind of architecture we found the need to integrate a well-known framework like NFV with the emerging one of Multi-Access Edge Computing (MEC), which is related to enable the virtualization of networking, storage and computing fabrics at the edge, closest possible to the location of end users, allowing offloading of tasks that have latency constraints from the core to the edge, as well as enabling a new set of network services, such as Radio Network Information Service (RINS), that can provide useful information to applications.
These two frameworks have some similarity, both defines a Virtual Infrastructure Manager (VIM), an Orchestrator and a Manager, but as said the targeted environment is different, as one is more focused in providing virtualization capabilities to the core network, while the latter one is focused on the edge, to allow integration of the two frameworks, an investigation on the proposed European Telecommunication Standard Institute (ETSI) solution [1] (reference to ETSI GR MEC 017 https://www.etsi.org/deliver/etsi_gr/MEC/001_099/017/01.01.01_60/gr_MEC017v010101p.pdf ) has been performed, in [1] there are some issues related to the integration as well as some proposed solutions, the 5GCity approach is based on the proposed ETSI solutions with some changes.
Figure 1
The 5GCity appoarch to MEC-NFV integration is decipted in Figure 1, the core orchestration functionalities, namely onboarding and instantiation of 5G services is handled by the NFV Orchestrator (NFVO), but in order to allow a smooth integration of orchestrators that handle different portion of the 5G service lifecycle, using different descriptors, the 5GCity architecture has a layer of orchestration of top of the domain-specific orchestrators that enable the split of functionalities based on the descriptor of the 5G service dispatch the job to the appropriate orchestrator, the Multi-layer Orchestrator exposes a simplified API that create an abstraction layer on top of the two different frameworks.
The actual integration is achieved with the partial implementation of some specific MEC components:
- The Multi-Access Edge Application Orchestrator (MEAO)
- The Muli-Access Edge Platform Manager – NFV (MEPM-V)
- The Multi-Access Edge Platform (ME-Platform)
The MEAO and MEMP-V implementation are based on the Eclipse fog05 [2] (https://github.com/eclipse/fog05) open source project. Eclipse fog05 aims to provide an IaaS Software for MEC and Fog Computing, is has a fully pluggable architecture that has allowed to add the functionalities that are needed for provide an MEAO and a MEMP-V, while the ME-Platform has been developed to allow communication between different Multi-Access Edge Application (ME App) that also expose services to other ME Apps. The deployment of a Network Service (NS) is depicted in Figure 2, more in detail the request of NS deployment is sended to the Multi-Layer Orchestrator that operate a formal check on the NS descriptor, if the ME App descriptor is present within the NS descriptor then the Multi-Layer Orchestrator start two parallel work flows: (i) the first one consist in a NFV descriptor sended to the NFVO, (ii) the second flow consist in the interaction between MEAO, MEMP-V and ME Platform to activate the service needed or provided by the ME App.
Figure 2
As described before, the role of the master orchestrator is taken by the Multi-Layer Orchestrator, while final decision about placing is taken by the 5G service placement algorithms, and the actual deployment is always performed by the NFVO, as the MEAO as no direct connection to the VIM/NFVI. The MEPM-V is responsible of the Life Cycle Management (LCM) for the ME Platform, this component has the same role of an Element Manager in a NFV ecosystem, and communicates with the NFVO through the Mm3* reference point. The are some other reference point that is worth to mention, one of this is Mm5 which is used for sending and receiving information about the ME Platform configuration so it is used for enabling services as well as requests of traffic redirection that will be activated by the NFVO.
This integration between MEC and NFV will be present in the first release of the 5GCity orchestration platform that is under development and will be available in Q1, 2019.