ETSI MEC Standard Explained – Part II

by Dario Sabella, Intel, ETSI MEC Chair


This is Part II of a two part article series on MEC.  Part I may be accessed here.

Access to Local and Central Data Networks (DN):

Figure 5. below illustrates an example of how concurrent access to local and central DN (Data Networks) works.  In this scenario, the same UP session allows the UE to obtain content  from both the local server and central server (service continuity is enabled by IP address anchoring at the centralized UPF, with no impact on UE by using Uplink Classifier -ULCL).

Figure 5. Concurrent access to local and central Data Networks (DN)

In this context it is assumed that MEC is deployed on the N6 reference point, i.e. in a data network external to the 5G system. This is enabled by flexibility in locating the UPF. The distributed MEC host can accommodate, apart from MEC apps, a message broker as a MEC platform service, and another MEC platform service to steer traffic to local accelerators. Logically MEC hosts are deployed in the edge or central data network and it is the User Plane Function (UPF) that takes care of steering the user plane traffic towards the targeted MEC applications in the data network.

The locations of the data networks and the UPF are a choice of the network operator who may choose to place the physical computing resources based on technical and business parameters (such as available site facilities, supported applications and their requirements, measured or estimated user load etc). The MEC management system, orchestrating the operation of MEC hosts and applications, may decide dynamically where to deploy the MEC applications.

In terms of physical deployment of MEC hosts, there are multiple options available based on various operational, performance or security related requirements (for more details, see the ETSI paper “MEC in 5G networks” [6] and the more recent study on “MEC 5G integration” [7]).

Moving forward with 5G (3GPP Release 17 onwards):

Given the increase of 5G adoption, and the progressive migration of network operators towards 5G SA (Stand Alone) networks this above MEC deployment is naturally becoming a long-term option considering the evolution of the networks. A major joint opportunity for MEC 5G integration, is on one hand for MEC to benefit from the edge computing enablers of the 5G system specification, and for 3GPP ecosystem to benefit from the MEC system and its APIs as a set of complementary capabilities to enable applications and services environm5 ents in the very edge of mobile networks. IN this perspective, also in the view of more mature 5G deployments, ETSI MEC is aligning with 3GPP SA6, defining from Rel.17 an EDGEAPP architecture (ref. 3GPP TS 23.558).

In this perspective, an ETSI white paper [3] provides some first information on this ongoing alignment, which is introducing a Synergized Mobile Edge Cloud architecture supported by 3GPP and ETSI ISG MEC specifications. This is an ongoing alignment, also in the view of future Rel.18 networks, and with respect to MEC federation and the related expansion (for MEC Phase 3 specifications) from intra-MEC communication to inter-MEC and MEC-Cloud coordination (as depicted in Figure 6). A very first study in this field has been published by ETSI MEC with the ETS GR 035 report [8].

Figure 6.  MEC Phase 3: Expansion from intra-MEC to inter-MEC and MEC-Cloud

The MEC 035 study on “Inter-MEC systems and MEC-Cloud systems” was a major effort in ETSI MEC, mainly driven by the need of operators to form federated MEC environments.  For example, to achieve V2X (vehicle to X) service continuity in multi-operator scenarios, to enable edge resource sharing among the federating members, and in general offer edge computing infrastructure as an asset to provide global services benefiting of better performance and low latency environments.  Many use cases in MEC 035 are in need of MEC federation.  Many are also based on the ETSI MEC requirements in MEC 002 (e.g. use cases like “V2X multi-stakeholder scenario” and “Multi-player immersive AR game,” among others).

This work carefully aligns with a GSMA publication introducing requirements for their “Operator Platform” concept.  [The GSMA Operator Platform defines a common platform exposing operator services/capabilities to customers/developers in the 5G-era in a connect once, connect to many models. The first phase of the platform focuses on Edge which will be expanded in future phases with other capabilities such as connectivity, slicing and IPComms.]  In this scenario, multiple operators will federate their edge computing infrastructure to give application providers access to a global edge cloud which may then run innovative, distributed and low latency services through a set of common APIs.

Currently ETSI MEC is working on the related normative work to enable and support this concept of MEC Federation, by defining a suitable MEC architecture variant in MEC GS 003, updating other impacted MEC specifications in Phase 3, and by introducing proper “MEC Federation Enablement APIs” (MEC GS 040) [9].

Enablement of MEC Deployment and Ecosystem Development:

MEC adoption is critical for the ecosystem. In this perspective, ETSI ISG MEC has established a WG DECODE dedicated to MEC Deployment and Ecosystem engagement activities. As a part of that (but not limited to it!) MEC is publishing and maintaining a MEC Wiki page (, including links to several examples of MEC adoption from the ecosystem:

MEC Ecosystem, with 3rd party MEC Applications and Solutions

Proof of Concepts (PoCs), with a list and description of past and ongoing PoCs, including the ISG MEC PoC Topics and PoC Framework (and Information about process, criteria, templates….)

MEC Deployment Trials (MDTs), with a list and description of past and ongoing MDTs (and the MDT Framework, clarifying how to participate)

Additionally, the MEC Wiki also includes: information on MEC Hackathons, MEC Sandbox, OpenAPI publications for ETSI MEC ISG API specifications, and outreach activities (e.g. MEC Tech Series of video and podcasts).

Summary and Conclusions:

MEC (Multi-access Edge Computing) “offers to application developers and content providers cloud-computing capabilities and an IT service environment at the edge of the network” (see Ref 1. below).
The nature of the ETSI MEC Standard (as emphasized by the term “Multi-access” in the MEC acronym) is access agnostic and can be applicable to any kind of deployment, from Wi-Fi to fixed networks.
MEC is also serving multiple use cases and providing an open and flexible standard, in support of multiple deployment options, especially for 5G networks.
MEC is focused on Applications at the Edge, and the specified MEC service APIs include meaningful information exposed to application developers at the network edge, ranging from RNI (Radio Network Information) API (MEC 012), WLAN API (MEC 029), Fixed Access API (MEC 028), Location API (MEC 013), Traffic Management APIs (MEC015) and many others. Additionally, new APIs (compliant with the basic MEC API principles) can be added, without the need for ETSI standardization.
The ongoing ETSI MEC work in alignment with 3GPP includes aspects related to MEC 5G Integration and future evolution, including the standardization work on MEC Federation.  Also, carefully aligning the MEC work with requirements from GSMA OPG (Operator Platform Group).

Finally, since MEC adoption is critical for the IT ecosystem, ETSI ISG MEC has established a WG dedicated to MEC Deployment and Ecosystem engagement activities.

There is also a dedicated MEC Wiki page ( which provides several examples of MEC adoption from the ecosystem (PoCs, trials, MEC implementations).  It also includes information on MEC Hackathons, MEC Sandbox, OpenAPI publications for ETSI MEC ISG API specifications, and outreach activities (e.g. MEC Tech Series of video and podcasts).


Previous References (from Part I):

[1]     ETSI MEC website,

[2]     ETSI GS MEC 003 V2.1.1 (2019-01): “Multi-access Edge Computing (MEC); Framework and Reference Architecture”,

[3]     ETSI White Paper #36, “Harmonizing standards for edge computing – A synergized architecture leveraging ETSI ISG MEC and 3GPP specifications”, First Edition, July 2020,

[4]     ETSI GS MEC 009 V3.1.1 (2021-06), “Multi-access Edge Computing (MEC); General principles, patterns and common aspects of MEC Service APIs”,

[5]     ETSI White Paper No. 24, “MEC Deployments in 4G and Evolution Towards 5G”, February 2018,

[6]     ETSI White Paper No. 28, “MEC in 5G network”, June 2018,

[7]     ETSI GR MEC 031 V2.1.1 (2020-10), “Multi-access Edge Computing (MEC); MEC 5G Integration”,

[8]     ETSI GR MEC 035 V3.1.1 (2021-06), “Multi-access Edge Computing (MEC); Study on Inter-MEC systems and MEC-Cloud systems coordination”,

[9]     ETSI DGS/MEC-0040FederationAPI’ Work Item, “Multi-access Edge Computing (MEC); Federation enablement APIs”,


Additional References:


The post ETSI MEC Standard Explained – Part II appeared first on Technology Blog.

,Read More