ETSI GS MEC 003 V2.1.1 (2019-01)

Multi-access Edge Computing (MEC); Framework and Reference Architecture

RGS/MEC-0003v211Arch

General Information

• Status: Published
• Publication Date: 23-Jan-2019
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 30-Jan-2019
• Completion Date: 24-Jan-2019

Standards Content (Sample)

ETSI GS MEC 003 V2.1.1 (2019-01)






GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Framework and Reference Architecture
Disclaimer
The present document has been produced and approved by the Multi-access Edge Computing (MEC) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

---------------------- Page: 1 ----------------------
2 ETSI GS MEC 003 V2.1.1 (2019-01)



Reference
RGS/MEC-0003v211Arch
Keywords
architecture, MEC
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2019.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS MEC 003 V2.1.1 (2019-01)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Overview . 7
5 Multi-access Edge Computing framework . 8
6 Reference architecture . 9
6.1 Generic reference architecture . 9
6.2 Reference architecture variant for MEC in NFV . 10
6.2.1 Description . 10
6.2.2 Architecture diagram . 10
7 Functional elements and reference points . 11
7.1 Functional ele me nts . 11
7.1.1 MEC host . 11
7.1.2 MEC platform . 11
7.1.3 MEC application . 12
7.1.4 MEC system level management. 12
7.1.4.1 Multi-access edge orchestrator . 12
7.1.4.2 Operations Support System (OSS) . 12
7.1.4.3 User application lifecycle management proxy . 12
7.1.5 MEC host level management . 13
7.1.5.1 MEC platform manager . 13
7.1.5.2 Virtualization infrastructure manager . 13
7.1.6 Device application . 13
7.1.7 Customer facing service portal . 13
7.1.8 Specific functional elements in the MEC in NFV architecture variant . 14
7.1.8.1 Overview . 14
7.1.8.2 MEC application orchestrator . 14
7.1.8.3 MEC platform manager – NFV . 14
7.1.8.4 NFVO . 14
7.1.8.5 VNFM (MEC Platform LCM) . 14
7.1.8.6 VNFM (MEC App LCM) . 14
7.2 Reference points . 14
7.2.1 Reference points related to the MEC platform . 14
7.2.2 Reference points related to the MEC management . 15
7.2.3 Reference points related to external entities . 15
7.2.4 Reference points related to the MEC in NFV architecture variant . 15
8 MEC services . 16
8.1 General . 16
8.2 Radio Network Information . 16
8.3 Location . 17
8.4 Bandwidth Manager . 17
Annex A (informative): Key concepts . 18
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS MEC 003 V2.1.1 (2019-01)
A.1 MEC host selection . 18
A.2 DNS support . 18
A.3 Application traffic filtering and routing . 19
A.4 Support of application and UE mobility . 19
A.4.1 Background: UE mobility . 19
A.4.2 MEC application scenarios for UE mobility . 19
A.4.2.1 MEC applications not sensitive to UE mobility . 19
A.4.2.2 MEC applications sensitive to UE mobility . 19
A.4.2.2.1 Maintaining connectivity between UE and MEC application instance . 19
A.4.2.2.2 Application state relocation . 19
A.4.2.2.3 Application instance relocation within the MEC system . 20
A.4.2.2.4 Application instance relocation between the MEC system and an external cloud environment . 20
A.5 Void . 20
A.6 Data Plane . 20
A.7 Inter-MEC system communication . 20
History . 21

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS MEC 003 V2.1.1 (2019-01)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge
Computing (MEC).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS MEC 003 V2.1.1 (2019-01)
1 Scope
The present document provides a framework and reference architecture for Multi-access Edge Computing that describes
a MEC system that enables MEC applications to run efficiently and seamlessly in a multi-access network. The present
document also describes the functional elements and the reference points between them, and a number of MEC services
that comprise the solution. It finally presents a number of key concepts related to the multi-access edge architecture.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference/.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Use Cases and Requirements".
[2] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[3] ETSI GS NFV-IFA 013: "Network Functions Virtualisation (NFV); Management and
Orchestration; Os-Ma-Nfvo reference point - Interface and Information Model Specification".
[4] ETSI GS NFV-IFA 008: "Network Functions Virtualisation (NFV); Management and
Orchestration; Ve-Vnfm reference point - Interface and Information Model Specification".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI GS MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.2] Void.
[i.3] "OpenStack++ for Cloudlet Deployment".
NOTE: Available at http://reports-archive.adm.cs.cmu.edu/anon/2015/CMU-CS-15-123.pdf.
[i.4] Void.
[i.5] ETSI GR MEC 017: "Mobile Edge Computing (MEC); Deployment of Mobile Edge Computing in
an NFV environment".
[i.6] ETSI TS 123 501: "System Architecture for the 5G System, Stage 2 (Release 15)".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS MEC 003 V2.1.1 (2019-01)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS MEC 001 [i.1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.1] and the following apply:
CFS Customer Facing Service
LCM LifeCycle Management
MEAO MEC Application Orchestrator
MEPM-V MEC Platform Manager - NFV
NFV Network Functions Virtualization
NFVO NFV Orchestrator
NFVI Network Functions Virtualization Infrastructure
NS Network Service
OSS Operations Support System
VIM Virtualization Infrastructure Manager
VNF Virtualized Network Function
VNFM VNF Manager
4 Overview
The present document presents a framework and a reference architecture to support the requirements defined for
Multi-access Edge Computing in ETSI GS MEC 002 [1].
The framework described in clause 5 shows the structure of the Multi-access Edge Computing environment.
The reference architecture described in clause 6 shows the functional elements that compose the multi-access edge
system, including the MEC platform and the MEC management, as well as the reference points between them.
The functional elements and reference points listed in clause 7 describe the high-level functionality of the different
functional elements and reference points.
Clause 8 describes the high-level functionality of a number of MEC services, comprising the solution for Multi-access
Edge Computing.
Annex A describes at a high-level a number of key concepts that underlie the principles used to develop the framework
and reference architecture described in the present document.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS MEC 003 V2.1.1 (2019-01)
5 Multi-access Edge Computing framework
Multi-access Edge Computing enables the implementation of MEC applications as software-only entities that run on top
of a virtualization infrastructure, which is located in or close to the network edge. The Multi-access Edge Computing
framework shows the general entities involved. These can be grouped into system level, host level and network level
entities.

Figure 5-1: Multi-access Edge Computing framework
Figure 5-1 illustrates the framework for Multi-access Edge Computing consisting of the following entities:
• MEC host, including the following:
- MEC platform;
- MEC applications;
- virtualization infrastructure;
• MEC system level management;
• MEC host level management;
• external related entities, i.e. network level entities.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS MEC 003 V2.1.1 (2019-01)
6 Reference architecture
6.1 Generic reference architecture
The reference architecture shows the functional elements that comprise the multi-access edge system and the reference
points between them.
Figure 6-1 depicts the generic multi-access edge system reference architecture. There are three groups of reference
points defined between the system entities:
• reference points regarding the MEC platform functionality (Mp);
• management reference points (Mm); and
• reference points connecting to external entities (Mx).

Figure 6-1: Multi-access edge system reference architecture
The multi-access edge system consists of the MEC hosts and the MEC management necessary to run MEC applications
within an operator network or a subset of an operator network.
The MEC host is an entity that contains a MEC platform and a virtualization infrastructure which provides compute,
storage, and network resources, for the purpose of running MEC applications. The MEC host is further described in
clause 7.1.1.
The MEC platform is the collection of essential functionality required to run MEC applications on a particular
virtualization infrastructure and enable them to provide and consume MEC services. The MEC platform can also
provide services. The MEC platform is further described in clause 7.1.2.
MEC applications are instantiated on the virtualization infrastructure of the MEC host based on configuration or
requests validated by the MEC management. MEC applications are further described in clause 7.1.3.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS MEC 003 V2.1.1 (2019-01)
The MEC management comprises the MEC system level management and the MEC host level management.
The MEC system level management includes the Multi-access edge orchestrator as its core component, which has an
overview of the complete MEC system. The MEC system level management is further described in clause 7.1.4.
The MEC host level management comprises the MEC platform manager and the virtualization infrastructure
manager, and handles the management of the MEC specific functionality of a particular MEC host and the applications
running on it. The MEC host level management is further described in clause 7.1.5.
6.2 Reference architecture variant for MEC in NFV
6.2.1 Description
Multi-access Edge Computing (MEC) and Network Functions Virtualization (NFV) are complementary concepts. The
MEC architecture has been designed in such a way that a number of different deployment options of MEC systems are
possible. A dedicated Group Report, ETSI GR MEC 017 [i.5], provides an analysis of solution details of the
deployment of MEC in an NFV environment.
In clauses 6.2.2, 7.1.8 and 7.2.4 of the present document, a MEC architecture variant is specified that allows to
instantiate MEC applications and NFV virtualized network functions on the same virtualization infrastructure, and to re-
use ETSI NFV MANO components to fulfil a part of the MEC management and orchestration tasks.
6.2.2 Architecture diagram
Figure 6-2 depicts a variant of the multi-access edge system reference architecture for the deployment in a Network
Functions Virtualization (NFV) environment [2].
In addition to the definitions for the generic reference architecture in clause 6.1, the following new architectural
assumptions apply:
• The MEC platform is deployed as a VNF.
• The MEC applications appear as VNFs towards the ETSI NFV MANO components.
• The virtualization infrastructure is deployed as an NFVI and is managed by a VIM as defined by ETSI
GS NFV 002 [2].
• The MEC platform manager (MEPM) is replaced by a MEC platform manager - NFV (MEPM-V) that
delegates the VNF lifecycle management to one or more VNF managers (VNFM).
• The MEC orchestrator (MEO) is replaced by a MEC application orchestrator (MEAO) that relies on the NFV
orchestrator (NFVO) for resource orchestration and for orchestration of the set of MEC application VNFs as
one or more NFV network services (NSs).
The new reference points shown in figure 6-2 are further described in clause 7.2.4.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS MEC 003 V2.1.1 (2019-01)

Figure 6-2: Multi-access edge system reference architecture variant for MEC in NFV
7 Functional elements and reference points
7.1 Functional elements
7.1.1 MEC host
The MEC host is an entity that contains the MEC platform and a virtualization infrastructure which provides compute,
storage, and network resources for the MEC applications. The virtualization infrastructure includes a data plane that
executes the traffic rules received by the MEC platform, and routes the traffic among applications, services, DNS
server/proxy, 3GPP network, other access networks, local networks and external networks.
7.1.2 MEC platform
The MEC platform is responsible for the following functions:
• offering an environment where the MEC applications can discover, advertise, consume and offer MEC
services (see clause 8), including, when supported, MEC services available via other platforms (that may be in
the same or a different MEC system);
ETSI

---------------------- Page: 11 ----------------------
12 ETSI GS MEC 003 V2.1.1 (2019-01)
• receiving traffic rules from the MEC platform manager, applications, or services, and instructing the data plane
accordingly. When supported, this includes the translation of tokens representing UEs in the traffic rules into
specific IP addresses;
• receiving DNS records from the MEC platform manager and configuring a DNS proxy/server accordingly;
• hosting MEC services, possibly including services that are described in clause 8;
• providing access to persistent storage and time of day information.
7.1.3 MEC application
MEC applications are running as virtual machines (VM) on top of the virtualization infrastructure provided by the MEC
host, and can interact with the MEC platform to consume and provide MEC services (described in clause 8).
In certain cases, MEC applications can also interact with the MEC platform to perform certain support procedures
related to the lifecycle of the application, such as indicating availability, preparing relocation of user state, etc.
MEC applications can have a certain number of rules and requirements associated to them, such as required resources,
maximum latency, required or useful services, etc. These requirements are validated by the MEC system level
management, and can be assigned to default values if missing.
7.1.4 MEC system level management
7.1.4.1 Multi-access edge orchestrator
The multi-access edge orchestrator is the core functionality in MEC system level management.
The multi-access edge orchestrator is responsible for the following functions:
• maintaining an overall view of the MEC system based on deployed MEC hosts, available resources, available
MEC services, and topology;
• on-boarding of application packages, including checking the integrity and authenticity of the packages,
validating application rules and requirements and if necessary adjusting them to comply with operator policies,
keeping a record of on-boarded packages, and preparing the virtualization infrastructure manager(s) to handle
the applications;
• selecting appropriate MEC host(s) for application instantiation based on constraints, such as latency, available
resources, and available services;
• triggering application instantiation and termination;
• triggering application relocation as needed when supported.
7.1.4.2 Operations Support System (OSS)
The Operations Support System (OSS) in figure 6-1 refers to the OSS of an operator. It receives requests via the CFS
portal and from device applications for instantiation or termination of applications, and decides on the granting of these
requests. Granted requests are forwarded to the multi-access edge orchestrator for further processing.
When supported, the OSS also receives requests from device applications for relocating applications between external
clouds and the MEC system.
7.1.4.3 User application lifecycle management proxy
A user application is a MEC application that is instantiated in the MEC system in response to a request of a user via an
application running in the device (device application).
The user application lifecycle management proxy allows device applications to request on-boarding, instantiation,
termination of user applications and when supported, relocation of user applications in and out of the MEC system. It
also allows informing the device applications about the state of the user applications.
ETSI

---------------------- Page: 12 ----------------------
13 ETSI GS MEC 003 V2.1.1 (2019-01)
The user application lifecycle management proxy authorizes requests from device applications in the device (e.g. UE,
laptop with internet connectivity) and interacts with the OSS and the multi-access edge orchestrator for further
processing of these requests.
The user application lifecycle management proxy is only available when supported by the MEC system.
7.1.5 MEC host level management
7.1.5.1 MEC platform manager
The MEC platform manager is responsi
...