MEC – Are we getting closer?!

Multi-access edge computing (MEC) or previously mobile edge computing has been a popular term in the past few years, especially as 5G technology entered the commercial stage last year. MEC is often used to describe the concept of pushing services to the edge of the network, and there is conflict with other terms such as fog computing. As this technology is associated with infrastructure technologies such as 5G and containers, various confusions are increasing. This article demystifies this technology from the perspective of telecommunications companies.

[[241121]]

The definition and framework of MEC comes from ETSI, the European Telecommunications Standards Institute, as part of the MEC Industry Specification Group (ISG), which began work in December 2014. Below is the definition from ETSI.

Multi-access edge computing (MEC) provides application developers and content providers with cloud computing capabilities and an IT service environment at the edge of the network. This environment is characterized by ultra-low latency and high bandwidth as well as real-time access to wireless network information that applications can utilize.

This definition lays out a roadmap for telecom operators to deliver cloud computing capabilities at the edge through an IaaS/PaaS model. So let’s stop here and point out that the concept of MEC is not combined with 5G, although it can play an important role in meeting the ultra-latency and gigabit experience requirements of 5G. ETSI MEC initially provided a framework and an interesting reference architecture, as shown below.

The specification was released in March 2016 and has raised many question marks among mobile operators. Some of the frequently asked questions are listed below, along with the author’s perspective.

What is the MEC host location in the network? Can it exist at the BTS? Regional DC? Can it reside at the end-user premises?

MEC is considered to be one step away from the end user, but it is not explicitly stated that it should reside in the BTS or Edge DC. Therefore, we can assume that it does not touch the terminal device or IoT device, it is just one hop in the network, matching the BTS and Edge DC.

What are the mechanisms for placing the data plane of network functions at the edge?

With CUPS, it is now possible to deploy user plane functions separately at the edge. I think 5G UPF and SGW/PGW-U are perfectly aligned. In addition, with proper service/resource orchestration, some VNFs can be deployed at the edge, such as Gi-LAN functions and value-added services (caching, FW, Parental Control, etc.).

What services (MEC Apps) can be run on a MEC host, and do they require special infrastructure requirements?

These can be third-party applications developed by third-party developers. So, operators can basically provide IaaS/PaaS to those companies or developers to develop special-purpose applications that require MEC characteristics such as ultra-latency. VR/AR, IoT, and V2I applications are an example.

For infrastructure, these applications will most likely be container-based. Therefore, operators must leverage environments that can host and “manage” containers.

How does a VIM (such as Openstack) manage a remote infrastructure environment with hundreds or thousands of DCs?

It's not clear, there are some open source initiatives, groups and forums, but nothing concrete so far. Two trends:

• Centralized Management - All OpenStack control components are deployed only in the primary DC, while the agents and message bus span across all DCs.
• Distributed management - Each DC deploys the entire OpenStack control component

What kind of infrastructure should be deployed at the edge?

It should be lightweight, small footprint, and cheap infrastructure with low power consumption and relatively good computing power. White boxes seem to be a suitable solution.

Will the workload run on a VM? Container? Bare metal?

For some reason, containers are always in the table above and below MEC workloads. However, workloads can run on anything. The above figure is the survey results of SDx Central's 2017 Edge Computing and MEC Report, where the question is "What will be used to manage edge platforms?" The respondents are from vendors and operator teams.

Is MEC a component of 5G?

It can be, but is it mandatory? I don't think so. The 5G ITU requirements are very clear that if operators manage to provide 5G services/features to end users, they don't have to deploy ETSI MEC concepts. There is no close connection between them.

How does MEC relate or match up with the ETSI NFV reference architecture?

One of the recently released ETSI MEC specifications is GR MEC 017 Mobile Edge Computing (MEC); Deploying Mobile Edge Computing in an NFV Environment. Interestingly, new network elements have been introduced, such as MEAO, Multi-Access Edge Application Orchestration, which raises many questions about the functionality of this orchestration and how it integrates with NFVO.

MEAO should manage the uploading of mobile edge application packages, resource orchestration across edge DCs, selection of appropriate mobile edge hosts for application instantiation, and triggering of application instantiation, termination, and relocation using the following reference points.

• The Mm1 reference point between the mobile edge orchestrator and the OSS is used to trigger the instantiation and termination of mobile edge applications in the mobile edge system.
• The Mm9 reference point between the User Application Lifecycle Management Agent and the Mobile Edge Orchestrator of the Mobile Edge System is used to manage the Mobile Edge Applications requested by the UE applications.
• The Mm3 reference point between the Mobile Edge Orchestrator and the Mobile Edge Platform Manager is used to manage the application lifecycle, application rules and requirements, and to track available Mobile Edge Services.
• The Mv1 reference point connects MEAO and NFVO. It is related to the Os-Ma-NFVO reference point as defined in ETSI NFV and is still under evaluation.

It is too early to see this integration commercialized. Like any other standard or open source initiative, it will require community support.

Original link: https://www.netmanias.com/en/?m=view&id=blog&no=13893