|
GROUP REPORT
Multi-access Edge Computing (MEC);
Study on Inter-MEC systems and
MEC-Cloud systems coordination
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 GR MEC 035 V3.1.1 (2021-06)
Reference
DGR/MEC-0035InterMEC
Keywords
handover, interworking
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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:
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
If you find errors in the present document, please send your comment to one of the following services:
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
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
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 2021.
All rights reserved.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI GR MEC 035 V3.1.1 (2021-06)
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
4.1 Introduction . 7
4.2 Inter-MEC system communication . 8
4.3 MEC-Cloud system communication . 9
4.4 Patterns of Business relationship between MEC and external systems . 10
5 Use cases . 11
5.1 Use case #1: MEC federation scenario of V2X services . 11
5.1.1 Description . 11
5.1.2 Recommendations . 12
5.1.3 Evaluation . 12
5.2 Use case #2: multi-operator agreements enabling MEC Federation for V2X services . 13
5.2.1 Description . 13
5.2.2 Recommendations . 13
5.2.3 Evaluation . 13
5.3 Use case #3: Application instance transfer between MEC and Cloud systems . 14
5.3.1 Description . 14
5.3.2 Recommendations . 15
5.3.3 Evaluation . 16
5.4 Use case #4: Inter-system communication involving a MEC system in an MNO's network . 17
5.4.1 Description . 17
5.4.2 Recommendations . 19
5.4.3 Evaluation . 19
5.5 Use case #5: MEC federation scenario for connecting different services . 20
5.5.1 Description . 20
5.5.2 Recommendations . 20
5.5.3 Evaluation . 21
5.6 Use case #6: MEC federation scenario for immersive AR game . 21
5.6.1 Description . 21
5.6.2 Recommendations . 24
5.6.3 Evaluation . 25
5.7 Use case #7: MEC federation scenario for Edge Service availability on visited networks . 25
5.7.1 Description . 25
5.7.2 Recommendations . 26
5.7.3 Evaluation . 26
5.8 Use case #8: MEC federation scenario for edge node sharing . 27
5.8.1 Description . 27
5.8.2 Recommendations . 28
5.8.3 Evaluation . 28
6 Solutions for closing the gaps . 28
6.1 Gap/Key issue #1 - Structuring the needed signalling for secure communication among different MEC
systems . 28
6.1.1 Description . 28
ETSI
---------------------- Page: 3 ----------------------
4 ETSI GR MEC 035 V3.1.1 (2021-06)
6.1.2 Solution proposal #1-1 . 28
6.2 Gap/Key issue #2 - Considering entities for MEC federation . 29
6.2.1 Description . 29
6.2.2 Solution proposal #2-1: Federation Manager . 29
6.2.3 Solution proposal #2-2: Federation Broker . 30
6.3 Gap/Key issue #3 - MEC system discovery . 31
6.3.1 Description . 31
6.3.2 Solution proposal #3-1: Federation Manager interactions . 32
6.4 Gap/Key issue #4 - MEC platform discovery. 33
6.4.1 Description . 33
6.4.2 Solution proposal #4-1: MEC platform discovery via direct MEO-to-MEO interactions . 33
6.4.3 Solution proposal #4-2: MEC platform discovery involving Federation Manager modules . 34
6.5 Gap/Key issue #5 - Information exchange for MEC service consumption or for MEC app-to-app
communication . 35
6.5.1 Description . 35
6.5.2 Solution proposal #5-1: overall solution addressable to key issues #1-2-3-4-5 involving information
exchange at MEC platform level . 36
6.5.3 Solution proposal #5-2: overall solution addressable to key issues #1-2-3-4-5 involving information
exchange at MEC federation management level . 40
6.6 Gap/Key issue #6 - Way to request the instantiation of application on Cloud system . 43
6.6.1 Description . 43
6.6.2 Solution proposal #6-1: leveraging OSS . 44
6.6.3 Evaluation . 45
6.7 Gap/Key issue #7 - Exposure of information to Cloud system/Edge Cloud . 45
6.7.1 Description . 45
6.7.2 Solution proposal #7-1 Exposure via Federation Manager . 45
6.7.3 Evaluation . 46
6.8 Gap/Key issue #8 - Discovery between MEC app instances . 46
6.8.1 Description . 46
6.8.2 Solution proposal #8-1: MEC application instance discovery . 46
7 Conclusion and recommendation . 48
History . 52
ETSI
---------------------- Page: 4 ----------------------
5 ETSI GR MEC 035 V3.1.1 (2021-06)
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 Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing
(MEC).
Modal verbs terminology
In the present document "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 GR MEC 035 V3.1.1 (2021-06)
1 Scope
The present document studies the applicability of MEC specifications to inter-MEC systems and MEC-Cloud systems
coordination that supports e.g. application instance relocation, synchronization and similar functionalities. Another
subject of this study is the enablement and/or enhancement of functionalities for application lifecycle management by
third parties (e.g. application developers).
2 References
2.1 Normative references
Normative references are not applicable in the present document.
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] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.3] ETSI GS MEC 030: "Multi-access Edge Computing (MEC); V2X Information Service API".
[i.4] GSMA White Paper: "Operator Platform Concept - Phase 1: Edge Cloud Computing", Jan. 2020.
NOTE: Available at https://www.gsma.com/futurenetworks/resources/operator-platform-concept-whitepaper/.
[i.5] XW2-200048, Huawei, Intel: "High-level Architectural Considerations on MEC in Multi-MNO
Scenarios", Attachment for LS to GSMA on High-level Architectural Considerations on MEC in
Multi-MNO Scenarios (XW2-200047), presented at 5GAA 'F2F'/Virtual WG Meeting Week #14
(11 - 15 May 2020).
[i.6] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management; Part 2:
Application lifecycle, rules and requirements management".
[i.7] ETSI GS MEC 016: "Multi-access Edge Computing (MEC); Device application interface".
[i.8] ETSI GS MEC 021: "Multi-access Edge Computing (MEC); Application Mobility Service API".
[i.9] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.10] ETSI TS 122 186: "5G; Service requirements for enhanced V2X scenarios (3GPP TS 22.186)".
ETSI
---------------------- Page: 6 ----------------------
7 ETSI GR MEC 035 V3.1.1 (2021-06)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
MEC federation: federated model of MEC systems enabling shared usage of MEC services and applications
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:
API Application Programming Interface
APP APPlication
AR Augmented Reality
CAPEX CAPital EXpenditure
DNS Domain Name System
FOTA Firmware Over The Air
GSMA Global System for Mobile Communications Association
IMA Intersection Movement Assist
IP Internet Protocol
LBO Local Break Out
LCM Life Cycle Management
MEO MEC Orchestrator
MEP MEC Platform
MEPM MEC Platform Manager
MNO Mobile Network Operator
NEF Network Exposure Function
NF Network Function
OEM Original Equipment Manufacturer
OSS Operations Support System
PDU Protocol Data Unit
QoE Quality of Experience
RNIS Radio Network Information Service
SMF Session Management Function
SOTA Software Over The Air
UE User Equipment
UPF User Plane Function
V2X Vehicle-to-everything
4 Overview
4.1 Introduction
The present document studies the applicability of MEC specifications to inter-MEC systems and MEC-Cloud systems
coordination. Firstly, the study analyses the current ETSI MEC specifications (clause 4). Secondly, the study documents
the use cases that require inter-system coordination, including those in multi-MNO environments (clause 5). Thirdly,
the study clarifies the requirements and any missing parts (clause 5). Finally, the study indicates possible solutions to
close the gaps (clause 6). The document considers the relevant work of other industry bodies relating to inter system
coordination and all relevant work done in ETSI.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI GR MEC 035 V3.1.1 (2021-06)
4.2 Inter-MEC system communication
Inter-MEC system communication has been identified by ETSI ISG MEC as an important technical topic, primarily
impactful to Mobile Network Operators (MNOs). ETSI GS MEC 003 [i.2] specifies three high-level requirements for
inter-MEC system communication, along with a hierarchical framework for inter-MEC system discovery and
communication as described by the following excerpt (clause 9 of [i.2]):
"Inter-MEC system communication addresses the following high-level requirements:
1) A MEC platform should be able to discover other MEC platforms that may belong to different MEC systems.
2) A MEC platform should be able to exchange information in a secure manner with other MEC platforms that
may belong to different MEC systems.
3) A MEC application should be able to exchange information in a secure manner with other MEC applications
that may belong to different MEC systems.
To enable the inter-MEC system communication, the following hierarchical inter-MEC system discovery and
communication framework is assumed:
• MEC system level inter-system discovery and communication.
• MEC host level inter-system communication between the MEC platforms.
NOTE: It is for further study if MEC platforms in different MEC systems should be able to discover each other
without the involvement of the MEC system level functional elements."
In parallel, driven by the MNOs' interest to form federated MEC environments, e.g. to achieve V2X service continuity
in multi-operator operation scenarios, as per ETSI GS MEC 030 [i.3], clauses 5.1 to 5.3, ETSI ISG MEC has introduced
the present document on "Study on Inter-MEC systems and MEC-Cloud systems coordination".
At the same time, GSMA has published a White Paper on the "Operator Platform" concept with focus on "Phase 1" of
Edge Cloud Computing in January 2020 [i.4]. In this White Paper, GSMA envisages that "operators will collaborate to
offer a unified "operator platform". In Phase 1, the Operator Platform will federate multiple Operators' edge computing
infrastructure to give application providers access to a global edge cloud to run innovative, distributed and low latency
services through a set of common APIs".
Figure 4.2-1: High level GSMA Operator Platform building blocks (source: [i.4])
ETSI
---------------------- Page: 8 ----------------------
9 ETSI GR MEC 035 V3.1.1 (2021-06)
From all the above, it is concluded that inter-MEC system communication is an imperative need in today's as well as
future's edge computing industry and ecosystem. However, to unlock the full potential of federated MEC environments
(as the exemplary one in Figure 4.2-1), an effective and well-defined signalling framework among MEC system entities,
is needed, both at system level and at host level. Such a framework has not yet been proposed so far, and the present
document is the appropriate place to discuss this topic.
4.3 MEC-Cloud system communication
MEC-Cloud communication is recognized as another important technical topic. ETSI GS MEC 003 [i.2], has referred to
application instance relocation between the MEC system and an external cloud environment, (clause A.4.2.2.4 of [i.2]),
which is applicable in the context of MEC applications sensitive to UE mobility. According to that, the application
instance relocation is conducted under the supervision of MEO.
In some cases, and when it is supported, the UE can request the MEC system to move application instances out of the
MEC system to an external cloud environment, or from an external cloud environment to the MEC system. In that case,
the application instance relocation is triggered between the MEC system and the external cloud environment under the
supervision of MEO.
Furthermore, OSS is responsible for receiving requests from device applications for relocating applications between
external clouds and the MEC system (clause 7.1.4.2 of [i.2]) and for receiving a request to run applications from the
third parties. In the case of relocation between MEC and Cloud systems, it may include a request from the third parties.
Virtualization infrastructure manager is expected to interact with external cloud manager to perform the application
relocation (clause 7.1.5.2 of [i.2]). As for the interfaces, ETSI GS MEC 003 [i.2] specifies the reference points
connecting to external entities, i.e. Mx1 and Mx2 (clause 6.1 of [i.2]).
As a summary, MEO supervises the application relocation between external cloud and MEC system. For that purpose,
OSS interacts with external Cloud system via Mx1 or the combination of Mx2 and Mm8.
NOTE: The blue-coloured reference points are specified by ETSI GS MEC 003 [i.2].
Figure 4.3-1: Interactions between a MEC and a Cloud system
Application mobility is a unique feature of MEC system, which supports relocation of user context and/or application
instance from one MEC host to another, or between a MEC host and a Cloud system.
In the present document, all the works should align with the current ETSI MEC specifications. The further
recommendations should be clarified based on the use case. Then, the gap from the current ETSI MEC specifications
will be clarified as well. Then, solutions will be introduced.
As a matter of fact, there exist many de-facto specifications for cloud systems. Therefore, proposing recommendations
for the operation of the cloud system is outside the scope of the present document. The intention is to rather clarify the
involved reference points and functional entities in the MEC system. Figure 4.3-2 illustrates the high-level architecture.
NOTE 1: Infrastructure level communication is out of scope in the present document.
NOTE 2: An architecture of Cloud system is out of scope of the present document.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI GR MEC 035 V3.1.1 (2021-06)
NOTE: The blue-coloured reference points are specified by ETSI GS MEC 003 [i.2].
Figure 4.3-2: High-level architecture
...