Multi-Access Edge Computing: An Overview of ETSI MEC ISG

Fabio Giust, NEC Laboratories Europe, Germany, Xavier Costa-Perez, NEC Laboratories Europe, Germany, and Alex Reznik, Hewlett Packard Enterprise, US 

IEEE 5G Tech Focus: Volume 1, Number 4, December 2017 

Abstract

The introduction of vertical industries use cases in future 5G networks imposes major architectural changes to current mobile networks in order to simultaneously support a diverse variety of stringent requirements (e.g. automotive, ehealth, public safety, etc.). Multi-access Edge Computing (MEC) is widely accepted as a key technology in order to enable ultra low-latency requirements as well as a rich computing environment for value-added services closer to end users. In this article we provide an overview of MEC as per the activities carried out in the ETSI MEC Industry Specification Group (ISG).

1. Introduction 

In late 2014, the European Telecommunications Standards Institute (ETSI) launched the Mobile Edge Computing Industry Specification Group (MEC ISG) to develop a standardized, open environment for efficient and seamless integration of applications from vendors, service providers, and third-parties across multi-vendor computing platforms at the edge of mobile networks. Starting with use case driven requirements, the ISG has defined a reference architecture and a set of APIs for key MEC interfaces. These include specifications relating to the essential functionality of

• the application enablement platform (API framework),
• specific service-related APIs and
• management and orchestration-related APIs.

These APIs are designed to be friendly to application developers and easy to implement so as to stimulate innovation and foster the development of applications [the list of published specifications is available here].

Recently, ETSI’s MEC ISG has expanded the scope of its activities to include additional access technologies besides cellular, hence the renaming into Multi-Access Edge Computing. This phase, known as MEC Phase 2, leverages on the industry acceptance of the first phase of specifications and is aimed at strengthening the engagement with developers and service providers, which are ultimately the stakeholders that exploit MEC for their value added product propositions.

In the remainder of this article we summarize the main technical output from ETSI MEC Phase 1 and showcase the planned activities in scope of phase 2.

2. MEC Framework and Reference Architecture 

ETSI’s MEC framework and reference architecture is defined in the Group Specifications (GS) MEC 003 [1] which is generic enough to be able to cover the new multi-access scope in phase 2. These group of specifications are known to be widely used as a reference architecture for many early MEC implementations, to be updated in the future based on more detailed specifications which have been recently published.

Figure 1: MEC framework 

 

A. MEC framework

The MEC framework (depicted in Figure 1) identifies and groups the high-level functional entities in the system.

• Network level entities comprising connectivity to local area networks, cellular networks and external networks such as Internet. Extending them to include non-cellular networks is a major goal of the current MEC activities.
• MEC host level where the MEC host sits along with its asso-ciated management subsystem. The MEC hosts is constituted by the platform and the virtualization infrastructure where the applications run.
• MEC system level management which retains the global view of the whole MEC system, i.e., the collection of MEC hosts and the associated management subsystem.

Figure 2: Mobile edge computing reference architecture 

B. MEC reference architecture

The MEC reference architecture (depicted in Figure 2) highlights the system level and host level components; the network level is not visible as there are no MEC-specified reference points to access those entities. Solid lines represent reference points which are in scope of MEC specifications, whereas dotted lines are deemed out of scope, either left to proprietary implementation or in scope of other SDOs.

The MEC host is a logical construct which embraces the MEC platform and the virtualization infrastructure that provides compute, storage and network resources to the MEC applications. The virtualization infrastructure includes a data plane element that enforces the forwarding rules received by the MEC platform and routes the traffic between the applications, services and the networks.

MEC applications run as virtual machines on top of virtualization infrastructure provided by the MEC host. The applications interact with the MEC platform over Mp1 reference point to handle the MEC services available in that MEC host (see Section 3). In fact, applications may consume MEC services but also provide them to the MEC platform, which can further provide those to other applications. At the time of instantiating a MEC application in the system, the system level management validates the service and resource requirements that may be indicated by the MEC application, e.g., its constraints on maximum allowed latency. The selection of target MEC host(s) as well as the decision to relocate applications are performed based on these requirements.

The MEC platform encompasses a collection of baseline functionalities that are required to run applications on the MEC host and enable MEC applications to discover, advertise, provide and consume the MEC services. Such essential functionalities include traffic steering, provision of persistent storage, and time references. In addition, the MEC platform supports configuring the local DNS proxy/server, in order to direct the user traffic to the MEC applications. Different MEC platforms may communicate to each other through the Mp3 reference point.

The MEC platform manager, still at the host level, consists of the MEC platform element management, the MEC application lifecycle management (LCM) and MEC application policy management functions. The application LCM is responsible for instantiating, terminating and relocating a MEC application, as well as providing indications to the MEC orchestrator on some application related events. The policy management includes authorizations, traffic rules, DNS configurations and resolving issues when set of policies are in conflict.

The Virtualization Infrastructure Manager (VIM) is responsible of managing the virtualized resources for the MEC applications, like allocating and releasing virtualized compute, storage and network resources, therefore it has the Mm7 reference point towards the Virtualization Infrastructure for this purpose - OpenStack is a widely known example of a VIM.

The MEC orchestrator plays a central role as it has the visibility over the resources and capabilities of the entire MEC system. In many ways it is similar to the ETSI Network Functions Virtualization Orchestrator [2] and has similar responsibilities, like coordination and control of instantiation, healing, resolving resource conflicts, etc. Uniquely to MEC, however, the MEC Orchestrator is also responsible for managing the MEC applications and the related procedures by supporting on-boarding the applications, checking their integrity and authenticity, validating the policies associated to them and maintaining a catalog of the available applications. It is up to the orchestrator to ensure that application requirements (e.g. latency, user throughput, etc.) are fulfilled, with the selection of the appropriate target MEC host, and, if required, also to trigger the application relocation.

From the MEC system point of view, the operator’s Operations Support System is the highest level management system to assist in getting the MEC applications running in the desired location of the network. OSS receives requests to instantiate and terminate the mobile edge applications from the Customer Facing Service portal (CFS) and from the clients in the user equipment and works with the orchestrator to fulfill these.

The CFS acts as an entry point for the 3rd parties and is envisioned to be similar to other such portals in cloud platforms. The User application lifecycle management proxy (User app LCM proxy) is a function that MEC application clients can use to request services related to on-boarding, instantiation and termination of the applications. For example, it can be used to request application relocation from an external cloud into the MEC system. The User app LCM proxy can be only accessed from the mobile network - including from the UE - using the Mx2 interface.

3. MEC Functional Interfaces and APIs Specification 

In addition to the MEC framework and reference architecture, the characterization of the system has been further enriched by the release of a number of GSs, aiming at defining the MEC functional interfaces and some of the service APIs.

A MEC system is designed to offer enhanced services to MEC applications. GS MEC 009, “General principles for Mobile Edge Service APIs” [3], describes how such services should be exposed through appropriate RESTful APIs. Although the GS does not provide any API definition per se, it clarifies the philosophy of the APIs exposed by the MEC system which is required in order to develop future MEC APIs.

Among the above mentioned MEC services, the Radio Network Information Service (RNIS) is a key feature offered by MEC, as it enables MEC Applications to adjust the data transmission rate for a particular user flow based on actual radio information. In combination with RNIS, MEC Location Service (LS) is a powerful tool for applications to exploit user proximity information, e.g., to retrieve and monitor the list of users connected to a particular cell. Moreover, the Bandwidth Management Service allows applications to reserve networking resources in the host. The description and API of such services are available respectively in GS MEC 012 [4], GS MEC 013 [5] and GS MEC 015 [6].

Since MEC services (current and future) are a key added value, a service handling functional block in the platform is of paramount importance in order to allow applications to discover or expose them. The purpose of GS MEC 011 [7], “Mobile Edge Platform Application Enablement”, is precisely to specify the set of environmental interfaces over the Mp1 reference point enabling applications to discover the services they wish to consume, or to register the services they intend to offer.

Beyond the API specifications showcased above, ETSI MEC has released specifications for management interfaces. They come bundled as a Part 1 document (GS MEC 010-1 [8]), which focuses on host and platform management, targeting Mm2 reference point; and Part 2 (GS MEC 010-2 [9]) which focuses on application LCM over reference points Mm1 and Mm3. Additionally, GS MEC 016 [10], describes the interfaces over Mx2 reference between an application running on the user device and the MEC system, through the User app LCM proxy.

4. Going Beyond Mobile: Embracing Multi-Access Edge Computing 

Despite the amount of work done so far in ETSI MEC, there is much more yet to do ahead. Finalizing the incomplete specifications and ongoing study items is only a part of the current work. In this regard, it is worth mentioning the ISG effort aimed at evaluating the potential integration of MEC into the ETSI NFV environment. This work is documented in the Group Report (GR) MEC 017, of which a pre-release draft is already available in the MEC open area.

New activities target the MEC system enhancement in order to support multiple access technologies and the use cases that thereby arise. Among these, special focus is given to the V2X use cases and those related to network slicing, for both of which a dedicated study item is ongoing. Furthermore, ETSI MEC is seeking collaboration with other industry organizations in order to accelerate the adoption of MEC technology to support the relevant use cases envisioned by e.g., GSM Association (GSMA), Broadband Forum (BBF), Open Fog Consortium (OFC), Small Cell Forum (SCF), 5G Automotive Association (5GAA), Virtual Reality/Augmented Reality Association (VRARA).

In addition, the ISG tasked a work item to focus on describing the ETSI MEC RESTful APIs utilizing the OpenAPI specification. The motivation is to enhance the accessibility of the APIs, particularly to the MEC development community, in order to engage this latter to collaborate for the API further improvement. To this end, ETSI has already made available a public repository where the machine-readable API definitions can be downloaded and used by developers.

Among the technical aspects that are envisioned as future activities, we remark the efforts foreseen to close the normative gaps that are supposed to emerge from the ongoing study item about NFV integration, application mobility, and support to application implemented as containers.

Moreover, it is crucial for ETSI MEC to start working on testing specifications, in order to give guidelines for compliance to vendors.

5. Concluding Remarks 

Formerly known as Mobile Edge Computing, Multi-access Edge Computing is widely recognized as one of the key pillars for 5G, and definitely one of the most promising technologies to bring cloud-based applications and services into the business of network operators.

In this article we have explored the MEC technology from the point of view of ETSI, the MEC ISG being the first community tasked to produce specifications for MEC. The framework and reference architecture is, in addition to the API and management interfaces specifications, the most remarkable output of the group during the first phase of MEC. Expanding the scope of MEC to multiple access technologies brings new use cases and requirements that the ISG is now endeavoring to explore to augment the capabilities of MEC in its second phase.

References

1. ETSI MEC ISG, “Mobile Edge Computing (MEC); Framework and reference architecture,” ETSI, DGS MEC 003, April 2016. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/003/01.01.01_60/gs_MEC003v010101p.pdf
2. ETSI NFV ISG, “Network Functions Virtualisation (NFV); Architectural Framework,” ETSI, DGS NFV 002, December 2014.
3. ETSI MEC ISG, “Mobile Edge Computing (MEC); General principles for Mobile Edge Service APIs,” ETSI, DGS MEC 009, July 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/009/01.01.01_60/gs_MEC009v010101p.pdf
4. ——, “Mobile Edge Computing (MEC); Radio Network Information API,” ETSI, DGS MEC 012, July 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/012/01.01.01_60/gs_MEC012v010101p.pdf
5. ——, “Mobile Edge Computing (MEC); Location API,” ETSI, DGS MEC 013, July 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/013/01.01.01_60/gs_MEC013v010101p.pdf
6. ——, “Mobile Edge Computing (MEC); Bandwidth Management API,” ETSI, DGS MEC 015, October 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/015/01.01.01_60/gs_mec015v010101p.pdf
7. ——, “Mobile Edge Computing (MEC); Mobile Edge Platform Application Enablement,” ETSI, DGS MEC 011, July 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/011/01.01.01_60/gs_MEC011v010101p.pdf
8. ——, “Mobile Edge Computing (MEC); Mobile Edge Management; Part 1: System, host and platform management,” ETSI, DGS MEC 010-1, October 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/01001/01.01.01_60/gs_mec01001v010101p.pdf
9. ——, “Mobile Edge Computing (MEC); Mobile Edge Management; Part 2: Application lifecycle, rules and requirements management,” ETSI, DGS MEC 010-2, July 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/01002/01.01.01_60/gs_MEC01002v010101p.pdf
10. ——, “Mobile Edge Computing (MEC); UE application interface,” ETSI, DGS MEC 016, September 2017. [Online]. Available: http://www.etsi.org/deliver/etsi_gs/MEC/001_099/016/01.01.01_60/gs_mec016v010101p.pdf

 

Fabio Giust received a MSc degree in Telecommunications Engineering at University of Padova, Italy, in 2011 and a PhD in Telematics Engineering at University Carlos III of Madrid, Spain, in 2015. Currently he is working as Research Scientist in NEC Laboratories Europe, where is carrying out R&D activities in the area of 5G mobile networks, mobile edge computing and network virtualization. He is an active contributor in the ETSI MEC Industry Specifications Group, leading the activities for some of the API definitions. As a IEEE ComSoc member, he has authored several papers about IP mobility and wireless systems in IEEE international conferences and journals, as well as served as TPC and reviewer. He is also a contributor to IETF in the IP mobility area.

 

Xavier Costa-Perez is Head of 5G Networks R&D and Deputy General Manager of the Security & Networking R&D Division at NEC Laboratories Europe. His team contributes to NEC projects for products roadmap evolution as well as to European Commission R&D collaborative projects and has received several Awards for successful technology transfers. In addition, the team contributes to related standardization bodies: 3GPP, ETSI NFV, ETSI MEC, IETF and OPNFV. Xavier has served on the Program Committees of several conferences (including IEEE Greencom, WCNC, and INFOCOM), published at top research venues and holds several patents. He received both his M.Sc. and Ph.D. degrees in Telecommunications from the Polytechnic University of Catalonia (UPC) and was the recipient of a national award for his Ph.D. thesis.

 

Alex Reznik is currently an Enterprise Account Architect on Hewlett Packard Enterprises telco strategic account team. He is engaged in making Tier 1 telcos evolve towards a flexible infrastructure capable of delivering the full promises of 5G. Since March 2017, he is the Chairman of ETSIs Multi-Access Edge Computing (MEC) ISG, the leading international standards group on edge computing. Previously, he served also as the Vice-Chair of the Services Working Group at the Small Cells Forum. Prior to May 2016 Alex was a Senior Principal Engineer at InterDigital, leading the company's R&D in the area of wireless internet evolution. He is inventor of over 140 granted U.S. patents and has been awarded numerous awards for Innovation at InterDigital. Alex earned his B.S.E.E. Summa Cum Laude from The Cooper Union, S.M. in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology, and Ph.D. in Electrical Engineering from Princeton University. 

 

Editor: Anwer Al-Dulaimi