ETSI GS MEC 003 V3.2.1 (2024-04)

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

RGS/MEC-0003v321Arch

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 15-Apr-2024
• Completion Date: 15-Apr-2024

Standards Content (Sample)

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.

2 ETSI GS MEC 003 V3.2.1 (2024-04)

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

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://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
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2024.
All rights reserved.
ETSI
3 ETSI GS MEC 003 V3.2.1 (2024-04)
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
6.3 Reference architecture variant for MEC federation . 11
6.3.1 Description . 11
6.3.2 Architecture diagram . 12
7 Functional elements and reference points . 12
7.1 Functional ele me nts . 12
7.1.1 MEC host . 12
7.1.2 MEC platform . 12
7.1.3 MEC application . 13
7.1.4 MEC system level management. 13
7.1.4.1 MEC orchestrator . 13
7.1.4.2 Operations Support System (OSS) . 13
7.1.4.3 User application lifecycle management proxy . 14
7.1.5 MEC host level management . 14
7.1.5.1 MEC platform manager . 14
7.1.5.2 Virtualisation infrastructure manager . 14
7.1.6 Device application . 14
7.1.7 Customer facing service portal . 15
7.1.8 Specific functional elements in the MEC in NFV architecture variant . 15
7.1.8.1 Overview . 15
7.1.8.2 MEC application orchestrator . 15
7.1.8.3 MEC platform manager - NFV . 15
7.1.8.4 NFVO . 15
7.1.8.5 VNFM (MEC platform LCM). 15
7.1.8.6 VNFM (MEC application LCM) . 15
7.1.9 MEC federator . 15
7.2 Reference points . 16
7.2.1 Reference points related to the MEC platform . 16
7.2.2 Reference points related to the MEC management . 16
7.2.3 Reference points related to external entities . 17
7.2.4 Reference points related to the MEC in NFV architecture variant . 17
7.2.5 Reference points related to the MEC federation architecture variant . 17
8 MEC services . 18
8.1 General . 18
8.2 Radio Network Information . 18
ETSI
4 ETSI GS MEC 003 V3.2.1 (2024-04)
8.3 Location . 18
8.4 Traffic Management Services . 18
9 Other considerations . 19
9.1 Inter-MEC system communication . 19
9.2 Security of the Mp3 reference point . 19
Annex A (informative): Key concepts . 20
A.1 MEC host selection . 20
A.2 DNS support . 20
A.3 Application traffic filtering and routing . 21
A.4 Support of application and UE mobility . 21
A.4.1 Background: UE mobility . 21
A.4.2 MEC application scenarios for UE mobility . 21
A.4.2.1 MEC applications not sensitive to UE mobility . 21
A.4.2.2 MEC applications sensitive to UE mobility . 21
A.4.2.2.1 Maintaining connectivity between UE and MEC application instance . 21
A.4.2.2.2 Application state relocation . 21
A.4.2.2.3 Application instance relocation within the MEC system . 22
A.4.2.2.4 Application instance relocation between the MEC system and an external cloud environment . 22
A.5 Void . 22
A.6 Data Plane . 22
A.7 API gateway support . . 22
Annex B (informative): Relationship with 3GPP SA6 EDGEAPP architecture . 23
B.1 Introduction . 23
B.2 Edge Enabler Server (EES) . 23
Annex C (informative): Relationship with GSMA OP architecture . 25
C.1 Introduction . 25
C.2 E/WBI. 26
C.3 NBI . 26
Annex D (informative): Relationship with both 3GPP SA6 EDGEAPP and GSMA OP
reference points . 27
History . 29

ETSI
5 ETSI GS MEC 003 V3.2.1 (2024-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
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
6 ETSI GS MEC 003 V3.2.1 (2024-04)
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".
[5] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
[6] ETSI GS MEC 040: "Multi-access Edge Computing (MEC); Federation enablement APIs".
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 GR MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.2] Void. ®
[i.3] OpenStack : "OpenStack++ for Cloudlet Deployment". ®
NOTE: The OpenStack Word Mark and OpenStack Logo are either registered trademarks/service marks or
trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are
used with the OpenStack Foundation's permission. ETSI is not affiliated with, endorsed or sponsored by
the OpenStack Foundation, or the OpenStack community.
ETSI
7 ETSI GS MEC 003 V3.2.1 (2024-04)
[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: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501
Release 17)".
[i.7] ETSI GR MEC 035: "Multi-access Edge Computing (MEC); Study on Inter-MEC systems and
MEC-Cloud systems coordination".
[i.8] GSMA Official Document OPG.02: "Operator Platform: Requirements and Architecture", v6.0,
February 2024.
[i.9] ETSI TS 123 558: "5G; Architecture for enabling Edge Applications (3GPP TS 23.558
Release 17)".
[i.10] ETSI TS 133 310: "Universal Mobile Telecommunications System (UMTS); LTE; 5G; Network
Domain Security (NDS); Authentication Framework (AF) (3GPP TS 33.310 Release 17)".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GR MEC 001 [i.1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GR MEC 001 [i.1] and the following apply:
CFS Customer Facing Service
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
8 ETSI GS MEC 003 V3.2.1 (2024-04)
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 Virtualisation 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;
- virtualisation infrastructure;
• MEC system level management;
• MEC host level management;
• external related entities, i.e. network level entities.
ETSI
9 ETSI GS MEC 003 V3.2.1 (2024-04)
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 Virtualisation 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
Virtualisation 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 and run on the Virtualisation infrastructure based on configuration or based on
requests validated by the MEC management. MEC applications are further described in clause 7.1.3.
The MEC management comprises the MEC system level management and the MEC host level management.
ETSI
10 ETSI GS MEC 003 V3.2.1 (2024-04)
The MEC system level management includes the MEC 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 Virtualisation 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
MEC and Network Functions Virtualisation (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 virtualised network functions on the same Virtualisation 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 an 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 Virtualisation 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 (VNFMs).
• 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
11 ETSI GS MEC 003 V3.2.1 (2024-04)

Figure 6-2: Multi-access edge system reference architecture variant for MEC in NFV
6.3 Reference architecture variant for MEC federation
6.3.1 Description
The MEC architecture has been designed in such a way that a number of different MEC system deployment options are
possible. ETSI GR MEC 035 [i.7] provides an analysis of solutions for enabling inter-MEC system communication, as
described in clause 9 of the present document. ETSI GR MEC 035 [i.7] also introduces the concept of a MEC
federation, defined as "a federated model of MEC systems enabling shared usage of MEC services and applications"
(see also clause 3.1 of [i.7]). In this environment, different stakeholders collaborate for joint business purposes, and
"federate" their edge computing resources, by offering/exposing their MEC service capabilities, not only for mutual
consumption, but also offering those to application developers and end customers (e.g. vertical market segments). The
solutions identified by ETSI GR MEC 035 [i.7] are also influenced by the Operator Platform Requirements and
Architecture (see GSMA Official Document OPG.02 [i.8]).
In clause 6.3.2 of the present document, a variant of the generic MEC architecture is presented that enables the
establishment of a MEC federation and, through that, interworking between a MEC system and another MEC system or
non-MEC system.
ETSI
12 ETSI GS MEC 003 V3.2.1 (2024-04)
6.3.2 Architecture diagram
Figure 6-3 depicts a variant of the multi-access edge system reference architecture for the deployment in a MEC
federation.
In addition to the definitions for the generic reference architecture in clause 6.1, the MEC Federator (MEF) functional
element is introduced, including MEC Federation Broker (MEFB) and MEC Federation Manager (MEFM)
functionalities. The MEF provides the functionality required to interface with other MEFs and in that capacity can act as
a broker between MEFs. It interfaces to at least one MEO.

Figure 6-3: Multi-access edge system reference architecture variant for MEC federation
NOTE: Non-MEC systems may support Mff reference point. How this is implemented in the other system is out
of the scope of the present document.
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 Virtualisation infrastructure which provides compute,
storage and network resources for the MEC applications. The Virtualisation 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 application instances 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);
• receiving traffic rules from the MEC platform manager, applications, or services and instructing the data plane
accordingly. When supported, this includes the translation of tags representing UEs in the traffic rules into
specific IP addresses;
ETSI
13 ETSI GS MEC 003 V3.2.1 (2024-04)
• 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;
• support for MEC application instance registration to the platform, enabling instances to provide their runtime
information.
The MEC platform may be accompanied by API gateway functionality for MEC application instances to access the
MEC service APIs.
7.1.3 MEC application
A MEC application is instantiated and run as a virtualised software application, within for instance a Virtual Machine
(VM) or OS containers provided as part of the application package as a software image(s), on top of the Virtualisation
infrastructure of the MEC system. Once instantiated, a MEC application instance can also potentially interact with the
MEC platform to consume and provide MEC services (described in clause 8).
In certain cases, a MEC application instance 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. A MEC application instance can register to the MEC platform to provide its runtime related information.
Registration enables discovery also in case the instance is not instantiated by the MEC management.
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 MEC orchestrator
The MEO is the core functionality in MEC system level management.
The MEO 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 Virtualisation 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;
• coordinating with the OSS the application instantiation lifecycle management operations.
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 MEO for further processing.
When supported, the OSS also receives requests from device applications for relocating applications between external
clouds and the MEC system.
ETSI
14 ETSI GS MEC 003 V3.2.1 (2024-04)
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.
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 MEO 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 responsible for the following functions:
• managing the lifecycle of applications including informing the MEO of relevant application related events;
• providing element management functions to the MEC platform;
• managing the application rules and requirements including service authorizations, traffic rules, DNS
configuration and resolving conflicts.
The MEC platform manager also receives Virtualised resources fault reports and performance measurements from the
Virtualisation infrastructure manager for further processing.
7.1.5.2 Virtualisation infrastructure manager
The Virtualisation infrastructure manager is responsible for the following functions:
• Allocating, managing and releasing Virtualised (compute, storage and networking) resources of the
Virtualisation infrastructure.
• Preparing the Virtualisation infrastructure to run a software image. The preparation includes configuring the
infrastructure and can include receiving and storing the software image.
• When supported, rapid provisioning of applications, as described in "Openstack++ for Cloudlet Deployments"
[i.3].
• Collecting and reporting performance and fault information about the Virtualised resources.
• When supported, performing application relocation. For application relocation from/to external cloud
environments, the Virtualisation infrastructure manager interacts with the external cloud manager to perform
the application relocation, for example using the mechanism described in "Adaptive VM Handoff Across
Cloudlets" [i.3], possibly through a proxy.
The functionality provided by the Virtualisation infrastructure manager in the present document and the functionality
provided by the Virtualised infrastructure manager described in ETSI GS NFV 002 [2], clause 7.2.5, overlap to a large
extent.
7.1.6 Device application
Device applications as defined in the present document are applications in the device (e.g. UE, laptop with internet
connectivity) that have the capability to interact with the MEC system via a user application lifecycle management
proxy, as defined in clause 7.1.4.3.
ETSI
15 ETSI GS MEC 003 V3.2.1 (2024-04)
7.1.7 Customer Facing Service (CFS) portal
The Customer Facing Service (CFS) portal allows operators' third-party customers (e.g. commercial enterprises) to
select and order a set of MEC applications that meet their particular needs, and to receive back service level information
from the provisioned applications.
7.1.8 Specific functional elements in the MEC in NFV architecture variant
7.1.8.1 Overview
The MEC in NFV architecture variant introduces two specific functional blocks which replace the MEO and the MEPM
in the generic architecture. These specific blocks realize MEC-specific functionality and delegate tasks that can be
fulfilled by ETSI NFV MANO to the related MANO functional blocks NFVO and VNFM.
7.1.8.2 MEC application orchestrator
The MEAO has the same responsibilities as the MEO (see clause 7.1.4.1), however, it delegates the management of the
set of MEC applications to an NFVO which manages these as part of one or more NFV network services. Similarly, it
can delegate the management of the MEC application VNF packages to the NFVO.
7.1.8.3 MEC platform manager - NFV
The MEPM-V has the same responsibilities as the MEPM (see clause 7.1.5.1), however, it does not perform LCM
actions itself, but delegates these to a VNFM. Also, it does not receive Virtualised resources fault reports and
performance measurements directly from the VIM, but these are routed via the VNFM.
7.1.8.4 NFVO
This functional block, as defined by ETSI GS NFV 002 [2], is responsible for managing the lifecycle of the network
services that include the MEC application instances, treating each MEC application instance as a VNF instance.
7.1.8.5 VNFM (MEC platform LCM)
This functional block, as defined by ETSI GS NFV 002 [2], is responsible for managing the lifecycle of the MEC
platform using standard NFV LCM procedures.
7.1.8.6 VNFM (MEC application LCM)
This functional block, as defined by ETSI GS NFV 002 [2], is responsible for managing the lifecycle of the MEC
applications, treating each MEC application instance as a VNF instance. There may be more than one instance of this
block in a deployment. Likewise, this block may be the same as the VNFM (MEC platform LCM) as defined in
clause 7.1.8.5.
7.1.9 MEC federator
The MEC federator enables a MEC federation between MEC systems. It is applicable in the reference architecture
variant for MEC federation, as depicted in clause 6.3.2.
Each MEF enables information exchange with at least one other MEF through support of the Mff reference point.
Furthermore, a MEF may serve as a single point of contact (again via the Mff reference point) for multiple MEFs in the
MEC federation, thereby acting as a broker between different MEFs. Such a MEF is considered to be "broker capable"
and in that case contains MEFB functionality.
MEFs are considered as "manager capable", containing MEFM functionality and supporting the Mfm reference point. A
MEF with MEFM and MEFB functionality is both "manager capable" and "broker capable". There may be more than
one MEF that is "broker capable" in an overall MEC federation.
The MEF provides the federation enablement service which is further specified in ETSI GS MEC 040 [6].
ETSI
16 ETSI GS MEC 003 V3.2.1 (2024-04)
7.2 Reference points
7.2.1 Reference points related to the MEC platform
Mp1: The Mp1 reference point between the MEC platform and the MEC applications provides service
registration, service discovery, and communication support for services. It also provides other
functionality such as application instance registration, application availability, session state
relocation support procedures, traffic rules and DNS rules activation, access to persistent storage
and time of day information, etc. This reference point can be used for consuming services and
providing service specific functionality.
Mp2: The Mp2 reference point between the MEC platform and the data plane of the Virtualisation
infrastructure is used to instruct the data plane on how to route traffic among applications,
networks, services, etc. This reference point is not further specified.
Mp3: The Mp3 reference point between MEC platforms is used for control communication between
MEC platforms.
NOTE: Optionally control signalling can be exchanged between two MEC platforms in different MEC systems in
order to facilitate feature specific inter-MEC system coordination. Such features include application
mobility support and V2X support.
7.2.2 Reference points related to the MEC management
Mm1: The Mm1 reference point between the MEO and the OSS is used for triggering the instantiation
and the termination of MEC applications in the MEC system. This reference point also supports
coordination of application instantiation lifecycle procedures.
Mm2: The Mm2 reference point between the OSS and the MEC platform manager is used for the MEC
platform configuration, fault and performance management.
Mm3: The Mm3 reference point between the MEO and the MEC platform manager is used for the
management of the application lifecycle, application rules and requirements and keeping track of
...