by Dario Sabella, Intel, ETSI MEC Chair, with Alan J Weissberger

Introduction (by Alan J Weissberger):

According to Research & Markets,  the global Multi-access Edge Computing (MEC) market size is anticipated to reach $23.36 billion by 2028, producing a CAGR of 42.6%.  Reduced Total Cost of Ownership (TCO) due to integration of MEC in network systems as compared to legacy systems and subsequent ability to generate faster Return on Investment (RoI) is further expected to encourage smaller retail chains to leverage MEC technology.

Multi-access Edge Computing Market Highlights (from Research & Markets):

• The software segment is anticipated to be the fastest-growing segment owing to emerging demand among service providers to use software that can be deployed for various applications without making changes to existing 3GPP hardware infrastructure specifications.
• The energy and utilities segment is expected to witness the fastest growth rate over the forecast period owing to increasing demand among companies to quickly access insights and analyze data generated from remote locations
• The Asia Pacific region is expected to emerge as the fastest-growing regional market due to strong support from the government to encourage advanced network infrastructure

A few important MEC applications/ use cases include:

• Streaming video and pay TV: Increasing number of users adopting the Over the Top (OTT) video delivery model is expected to promote telecom companies and mobile networks to upgrade their existing infrastructure to cache video/audio content closer to the user.  Using the multi-access edge computing (MEC) architecture system brings backend functionality closer to the user network, which is expected to aid Multichannel Video Programming Distributors (MVPD) to meet their customers’ demands.  Users pay subscription fees for a specified duration of time to access the content offered by the MVPD.
• Deployment of MEC technology is expected to enable retail and on line stores to improve the performance of in-store systems and reduce data processing time, thus ensuring faster resolving of customer grievances. Furthermore, adoption of this technology is expected to reduce the load on external macro sites, thus offering a seamless in-store experience for users.
• Increasing number of IoT devices and the emerging need to gain access to real-time analysis of data generated by them is expected to drive MEC market growth. Leveraging this technology in IoT can facilitate reduced pressure on cloud networks and result in lower energy consumption, which is expected to offer significant growth opportunities to the market.
• Multi-access edge computing is expected to enhance manufacturing practices and thus facilitate the advent of connected cars ecosystem. Connected cars are equipped with computing systems, wireless devices, and sensing, which have to work together in a coordinated fashion, thus facilitating the need to adopt MEC.
• 5G MEC technology can be used to exchange critical operational and safety information to enhance efficiency, safety, and enhance value-added services such as smart parking and car finder.

Previously referred to as Mobile Edge Computing, MEC raises a lot of questions.  For example:

• Can MEC be used with wireline and fixed access networks?
• Is 5G Stand Alone (SA) core network with separate control, data, and management planes required for MEC to be effective?
• Finally, why should MEC (and multi-cloud) matter to infrastructure owners and application developers?

Dario Sabella, Intel, ETSI MEC Chair, answers those questions and provides more context and color in his two part article.

………………………………………………………………………………………………..

ETSI MEC Standard Explained, by Dario Sabella, Intel, ETSI MEC Chair

ETSI MEC – Foundation for Edge Computing:

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” [1].

The MEC ISG (Industry Specification Group) was established by ETSI to create an open standard for edge computing, allowing multiple implementations and ensuring interoperability across a diverse ecosystem of stakeholders: from mobile operators, application developers, Over the Top (OTT) players, Independent Software Vendors (ISVs), telecom equipment vendors, IT platform vendors, system integrators, and technology providers; all of these parties are interested in delivering services based on Multi-access Edge Computing concepts.

The work of the MEC initiative (see the architecture in Figure 1. above) aims to unite the telco and IT-cloud worlds, providing IT and cloud-computing capabilities at the edge: operators can open their network edge to authorized third parties, allowing them to flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments (e.g. automotive).

Author’s Note:

From a deployment point of view, a natural question is “where exactly is the edge?”  In this perspective, the ETSI MEC architecture supports all possible options, ranging from customer premises, 1st wireless base station/small cell, 1st network compute point of presence, internet resident data center/compute server or edge of the core network. The MEC standard is flexible, and the actual and specific MEC deployment is really an implementation choice from the infrastructure owners.

Additionally, the MEC architecture (shown in Figure 2 and defined in the MEC 003 specification [2]) has been designed in such a way that a number of different deployment options of MEC systems are possible:

1.  The MEC 003 specification includes also a MEC in NFV (Network Functions Virtualization) variant, which is a MEC architecture that instantiates MEC applications and NFV virtualized network functions on the same virtualization infrastructure, and to reuse ETSI NFV MANO components to fulfil a part of the MEC management and orchestration tasks. This MEC deployment in NFV (Network Functions Virtualization) is also coherent with the progressive virtualization of networks.
2. In that perspective, MEC deployment in 5G networks is  a main scenario of applicability (note that the MEC standard is aligned with 3GPP specifications [3]).
3. On the other hand, 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.
4. A major effort of the MEC standardization work is dedicated to publishing relevant and industry-driven exemplary specifications of MEC service APIs, that are using RESTful principles, thus exposed to application developers in a universally recognized language.

The ETSI MEC initiative is focused on Applications at the Edge, and the specified MEC APIs (see above Figure 2.) 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 [4]) can be added, without the need of being standardized in ETSI.

In this perspective, MEC truly provides a new ecosystem and value chain, by opening up the market to third parties, and allowing not only operators and cloud providers but any authorized software developers that can flexibly and rapidly deploy innovative applications and services towards mobile subscribers, enterprises and vertical segments.

MEC in 4G (and 5G NSA) Deployments:

ETSI has already clarified how MEC can be deployed in 4G networks, given its access-agnostic nature [5], with many approaches:

From “bump in the wire” (where the MEC sits on the S1 interface of the 4G system architecture), to “distributed 4G-Evolved Packet Core” (EPC -where the MEC data plane sits on the SGi interface), to “distributed S/PGW” (where the control plane functions such as the MME and HSS are located at the operator’s core site) and “distributed SGW with Local Breakout” (SGW-LBO) -where the MEC system and the distributed SGW are co-located at the network’s edge.

Figure 3.  MEC deployment options with distributed EPC (a), distributed S/PGW (b) and SGW-LBO (c)

Depending on the selected solution, MEC Handover is executed in different ways:

In the “bump in the wire approach,” mobility is not natively supported. Instead, in the EPC MEC, SGW + PGW MEC, and CUPS MEC, the MEC handover is supported using 3GPP specified S1 Handover with SGW relocation by maintaining the original PGW as anchor.

The same considerations apply for the SGW-LBO MEC deployment. In the latter case, the target SGW enforces the same policy towards the local MEC application.

Finally, the solutions that include an EPC gateway, such as EPC MEC, SGW+PGW MEC, SGW-LBO MEC, and CUPS MEC are compliant with LI (Lawful Interception) requirements.

This last aspect is also very relevant for MEC adoption, since public telecommunications network and service providers are legally required to make available to law enforcement authorities information from their retained data which is necessary for the authorities to be able to monitor telecommunications traffic as part of criminal investigations.

In that perspective, MEC deployment options are also chosen by infrastructure owners in the view of their compliance to Lawful Interception requirements.

Distributed SGW with Local Breakout (SGW-LBO):

A mainstream for the adoption of MEC is given by the progressive introduction of 5G networks.

Among the various 5G deployment options, local breakout at the SGWs (Figure 3c above) is a solution for MEC that originated from operators’ desire to have a greater control on the granularity of the traffic that needs to be steered. This principle was dictated by the need to have the users able to reach both the MEC applications and the operator’s core site application in a selective manner over the same APN.

The traffic steering uses the SGi – Local Break Out interface which supports traffic separation and allows the same level of security as the network operator expects from a 3GPP-compliant solution.

This solution allows the operator to specify traffic filters similar to the uplink classifiers in 5G, which are used for traffic steering. The local breakout architecture also supports MEC host mobility, extension to the edge of CDN, push applications that requires paging and ultra-low latency use cases.

The SGW selection process performed by MMEs is according to the 3GPP specifications and based on the geographical location of UEs (Tracking Areas) as provisioned in the operator’s DNS.

The SGW-LBO offers the possibility to steer traffic based on any operator-chosen combination of the policy sets, such as APN and user identifier, packet’s 5-tuple, and other IP level parameters including IP version and DSCP marking.

Integrated MEC deployment in 5G networks (3GPP Release 15 and later):

Edge computing has been identified as one of the key  technologies required to support low latency together with mission critical and future IoT services. This was considered in the initial 3GPP requirements, and the 5G system was designed from the beginning to provide efficient and flexible support for edge computing to enable superior performance and quality of experience.

In that perspective, the design approach taken by 3GPP allows the mapping of MEC onto Application Functions (AF) that can use the services and information offered by other 3GPP network functions based on the configured policies.

In addition, a number of enabling functionalities were defined to provide flexible support for different deployments of MEC and to support MEC in case of user mobility events. The new 5G architecture (and MEC deployment as AF) is depicted in the Figure 4 below.

Figure 4. – MEC as an AF (Application Function) in 5G system architecture

In this deployment scenario, MEC as an AF (Application Function) can request the 5GC (5G Core network) to select a local UPF (User Plane Function) near the target RAN node.  Then use the local UPF for PDU sessions of the target UE(s) and to control the traffic forwarding from the local UPF so that the UL traffic matching with the traffic filters received from MEC (AF) is diverted towards MEC hosts while other traffic is sent to the Central Cloud.

In case of UE mobility, the 5GC can re-select a new local UPF more suitable to handle application traffic identified by MEC (AF) and notify the AF about the new serving UPF.

In summary, MEC as an AF can provide the following services with a 5GC:

• Traffic filters identifying MEC applications deployed locally on MEC hosts in Edge Cloud
• Target UEs (one UE identified by its IP/MAC address, a group of UE, any UE)
• Information about forwarding the identified traffic further e.g. references to tunnels toward MEC hosts

………………………………………………………………………………………………………………………………………………………………………………………….

Part II. of this two part article will illustrate and explain concurrent access to local and central Data Networks.  The enablement of MEC deployments and ecosystem development will also be presented.

Importantly, Part II will explain how MEC is evolving to the next phase of 5G– 3GPP Release 17.  In particular, ETSI MEC is aligning with 3GPP SA6 which is defining an EDGEAPP architecture (ref. 3GPP TS 23.558). 

Part II will also explain how MEC is evolving to multi-cloud support in alignment with GSMA OPG requirements for the MEC Federation work. 

ETSI MEC Standard Explained – Part II

…………………………………………………………………………………………………………………………………………………………………………………………..

References:

1.  Introduction:

https://www.globenewswire.com/en/news-release/2021/11/25/2340948/28124/en/Global-Multi-access-Edge-Computing-Markets-Report-2021-Drivers-Include-Implementation-of-5G-Growing-Adoption-of-IoT-Forecast-to-2028.html

https://www.accenture.com/_acnmedia/PDF-128/Accenute-MEC-for-Pervasive-Networks-PoV.pdf

PowerPoint Presentation (etsi.org)

2.  Main body of this article (Part I and II):

[1]     ETSI MEC website, https://www.etsi.org/technologies/multi-access-edge-computing

[2]     ETSI GS MEC 003 V2.1.1 (2019-01): “Multi-access Edge Computing (MEC); Framework and Reference Architecture”, https://www.etsi.org/deliver/etsi_gs/mec/001_099/003/02.01.01_60/gs_mec003v020101p.pdf

[3]     ETSI White Paper #36, “Harmonizing standards for edge computing – A synergized architecture leveraging ETSI ISG MEC and 3GPP specifications”, First Edition, July 2020, https://www.etsi.org/images/files/ETSIWhitePapers/ETSI_wp36_Harmonizing-standards-for-edge-computing.pdf

[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”, https://www.etsi.org/deliver/etsi_gs/MEC/001_099/009/03.01.01_60/gs_MEC009v030101p.pdf

[5]     ETSI White Paper No. 24, “MEC Deployments in 4G and Evolution Towards 5G”, February 2018, https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp24_MEC_deployment_in_4G_5G_FINAL.pdf

[6]     ETSI White Paper No. 28, “MEC in 5G network”, June 2018, https://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp28_mec_in_5G_FINAL.pdf

[7]     ETSI GR MEC 031 V2.1.1 (2020-10), “Multi-access Edge Computing (MEC); MEC 5G Integration”, https://www.etsi.org/deliver/etsi_gr/MEC/001_099/031/02.01.01_60/gr_MEC031v020101p.pdf

[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”, https://www.etsi.org/deliver/etsi_gr/MEC/001_099/035/03.01.01_60/gr_mec035v030101p.pdf

[9]     ETSI DGS/MEC-0040FederationAPI’ Work Item, “Multi-access Edge Computing (MEC); Federation enablement APIs”, https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=63022