ETSI GS MEC 040 V3.2.1 (2024-03)

Multi-access Edge Computing (MEC); Federation enablement APIs

RGS/MEC-0040v321FederationAPI

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Due Date: 10-Apr-2024
• Completion Date: 21-Mar-2024

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Federation enablement APIs
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 040 V3.2.1 (2024-03)

Reference
RGS/MEC-0040v321FederationApi
Keywords
API, interworking, MEC, service

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 040 V3.2.1 (2024-03)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Overview . 8
4.1 Introduction . 8
4.2 GSMA Operator Platform and its interfaces . 9
5 Description of the services (informative) . 10
5.1 Federation enablement service introduction . 10
5.2 Sequence diagrams . 10
5.2.1 Introduction. 10
5.2.2 Request/Response model . 11
5.2.2.1 Registration/Update/Deregistration of MEC system to the MEC federator . 11
5.2.2.1.1 Registration . 11
5.2.2.1.2 Update . 11
5.2.2.1.3 Deregistration . 11
5.2.2.2 MEC system discovery . 12
5.2.2.3 MEC application instance discovery . 13
5.2.2.4 MEC service discovery . 14
5.2.2.5 Application package management and Application instance lifecycle management . 16
5.2.2.5.1 Introduction . 16
5.2.2.5.2 On-boarding application package . 16
5.2.2.5.3 Application Instantiation . 17
5.2.2.6 Providing MEC system-wide MEC application instance information updates to MEF . 18
5.2.2.7 Forwarding MEC system-wide MEC application instance information updates to another MEC
system of MEC federation . 18
5.2.3 REST based subscribe-notify model . 19
5.2.3.1 Subscribing to federation event notifications . 19
5.2.3.2 Receiving notification on expiry of federation event subscription . 20
5.2.3.3 Updating subscription for federation event notifications . 20
5.2.3.4 Unsubscribing from federation event notifications . 21
5.2.3.5 Receiving MEC system registration/update notifications . 21
5.2.3.6 Receiving MEC application instance registration/ registration update/ deregistration notifications . 21
5.2.4 Creation/Update/Removal of MEC federation between two partners . 22
5.2.4.1 Introduction . 22
5.2.4.2 Create MEC Federation between partners . 22
5.2.4.3 Update MEC Federation between partners . 23
5.2.4.4 Remove MEC Federation between partners . 23
6 Data model . 24
6.1 Introduction . 24
6.2 Resource data types . 24
6.2.1 Introduction. 24
6.2.2 Type: SystemInfo . 24
6.2.3 Type: SystemInfoUpdate . 24
6.2.4 Type: FedServiceInfo . 25
6.2.5 Referenced simple data types. 25
ETSI
4 ETSI GS MEC 040 V3.2.1 (2024-03)
6.2.5.1 Introduction . 25
6.2.5.2 Simple data types . 25
6.3 Subscription data types . 25
6.3.1 Introduction. 25
6.3.2 Type: SystemUpdateNotificationSubscription . 25
6.3.3 Type: SubscriptionLinkList . 26
6.4 Notifications data types . 26
6.4.1 Introduction. 26
6.4.2 Type: SystemUpdateNotification . 26
6.5 Referenced structured data types . 27
6.5.1 Introduction. 27
6.5.2 Type: TimeStamp . 27
7 API definition . 27
7.1 Introduction . 27
7.2 Global definitions and resource structure . 27
7.3 Resource: A list of system_info . 28
7.3.1 Description . 28
7.3.2 Resource definition . 28
7.3.3 Resource methods . 29
7.3.3.1 GET . 29
7.3.3.2 PUT . 29
7.3.3.3 PATCH . 30
7.3.3.4 POST . 30
7.3.3.5 DELETE . 30
7.4 Resource: Individual system. 31
7.4.1 Description . 31
7.4.2 Resource definition . 31
7.4.3 Resource methods . 31
7.4.3.1 GET . 31
7.4.3.2 PUT . 32
7.4.3.3 PATCH . 32
7.4.3.4 POST . 33
7.4.3.5 DELETE . 33
7.5 Resource: subscriptions . 34
7.5.1 Description . 34
7.5.2 Resource definition . 34
7.5.3 Resource methods . 34
7.5.3.1 GET . 34
7.5.3.2 PUT . 35
7.5.3.3 PATCH . 35
7.5.3.4 POST . 35
7.5.3.5 DELETE . 37
7.6 Resource: existing subscription . 37
7.6.1 Description . 37
7.6.2 Resource definition . 37
7.6.3 Resource methods . 37
7.6.3.1 GET . 37
7.6.3.2 PUT . 38
7.6.3.3 PATCH . 40
7.6.3.4 POST . 40
7.6.3.5 DELETE . 40
7.7 Resource: A list of MEC services for federation on the Mfm and Mff reference points . 40
7.7.1 Description . 40
7.7.2 Resource definition . 40
7.7.3 Resource methods . 41
7.7.3.1 GET . 41
7.7.3.2 PUT . 42
7.7.3.3 PATCH . 42
7.7.3.4 POST . 42
7.7.3.5 DELETE . 42
7.8 Resource: Individual MEC service for federation on the Mfm and Mff reference points . 43
ETSI
5 ETSI GS MEC 040 V3.2.1 (2024-03)
7.8.1 Description . 43
7.8.2 Resource definition . 43
7.8.3 Resource methods . 43
7.8.3.1 GET . 43
7.8.3.2 PUT . 44
7.8.3.3 PATCH . 44
7.8.3.4 POST . 44
7.8.3.5 DELETE . 44
Annex A (informative): Enabling MEC App providers to access MEC federation services . 45
A.1 Introduction . 45
Annex B (informative): Complementary material for API utilization . 46
Annex C (informative): Data models of EWBI defined by GSMA OPG . 47
C.1 Introduction . 47
C.2 Interface Management API . 47
History . 48

ETSI
6 ETSI GS MEC 040 V3.2.1 (2024-03)
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
7 ETSI GS MEC 040 V3.2.1 (2024-03)
1 Scope
The present document focuses on the functionalities enabled over the relevant reference points (i.e. Mfm and Mff) to
support MEC federation. It describes the information flows, required information, and specifies the necessary
operations, data models and API definitions. The present document carefully considers the relevant work of other
industry bodies relating to MEC federation (e.g. GSMA OPG, 5GAA, etc.) and all relevant work done in ETSI.
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 001: "Multi-access Edge Computing (MEC); Terminology".
[2] Void.
[3] Void.
[4] Void.
[5] GSMA Permanent Reference Document OPG.04: "Operator Platform - East-Westbound Interface
APIs", V2.0, March 2023.
rd
[6] 3GPP TS 23.502: "3 Generation Partnership Project; Technical Specification Group Services and
System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 18)".
[7] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management;
Part 2: Application lifecycle, rules and requirements management".
[8] Void.
[9] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
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] GSMA Official Document OPG.02: "Operator Platform Requirements and Architecture", V5.0,
July 2023.
ETSI
8 ETSI GS MEC 040 V3.2.1 (2024-03)
[i.2] ETSI GR MEC 035: "Multi-access Edge Computing (MEC); Study on Inter-MEC systems and
MEC-Cloud systems coordination".
[i.3] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Use Cases and Requirements".
[i.4] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.5] Void.
[i.6] Void.
[i.7] OpenAPI™ Specification.
[i.8] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
[i.9] Void.
3 Definition of terms, symbols and abbreviations
3.1 Terms
Void.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [1] and the following apply:
App Application
CHF CHarging Functions
CR Cloud Resources
E/WBI East/West Bound Interface
GSMA GSM Association
MEF MEC Federator
MNO Mobile Network Operator
NBI NorthBound Interface
NR Network Resources
OEM Original Equipment Manufacturer
OP Operator Platform
SBI SouthBound Interface
UNI User Network Interface
4 Overview
4.1 Introduction
The present document specifies Federation enablement APIs that enable the shared usage of MEC services and
applications across different systems (e.g. MEC system, Cloud system).
Clause 4 introduces the relevant work of other industry bodies e.g. GSMA OPG.
ETSI
9 ETSI GS MEC 040 V3.2.1 (2024-03)
Clause 5 presents the reference scenarios for the MEC federation, and introduces the functionalities enabled via the
relevant reference points (i.e. Mfm and Mff). It provides the high-level information flows and describes the necessary
operations.
Clause 6 describes the data models that can be exchanged over the Federation enablement APIs, which provide detailed
descriptions of all information elements used for MEC federation.
Clause 7 defines the actual Federation enablement APIs providing detailed information of how information elements are
mapped into a RESTful API design.
4.2 GSMA Operator Platform and its interfaces
According to the GSMA Permanent Reference Document (PRD), "Operator Platform Telco Edge Requirements" [i.1],
an Operator Platform (OP) is a facilitator of subscribers' seamless access to edge applications instantiated within a
federation of edge networks involving multiple owners. Such seamless access is needed either when subscribers roam to
visited networks or when a partner network is a better choice for edge application instantiation.
The objective of the OP concept is to guide the industry ecosystem, i.e. MNOs, vendors, OEMs and service providers
towards shaping a common solution for the exposure of network capabilities. As an initial step, [i.1] provides both an
end-to-end definition and requirements of the OP for the support of edge computing. In further details, the GSMA
defines OP requirements as well as OP architecture and functional modules. Therefore, aim of GSMA is to engage with
standardization and open source communities that will undertake the standard definition of the OP. As depicted in
Figure 4.2-1, the following OP interfaces have been defined in [i.1].

Figure 4.2-1: High-level OP reference architecture
(source: [i.1])
• Northbound Interface (NBI);
• Southbound Interface (SBI); Cloud Resources (SBI-CR);
• Southbound Interface (SBI); Network Resources (SBI-NR);
• Southbound Interface (SBI); Charging Functions (SBI-CHF);
• User Network Interface (UNI);
• East/West Bound Interface (E/WBI).
ETSI
10 ETSI GS MEC 040 V3.2.1 (2024-03)
5 Description of the services (informative)
5.1 Federation enablement service introduction
Federation enablement APIs offers services such as discovery, information exchange and application life cycle
management to enable the inter-work of one MEC system with another MEC system. The related requirements were
carefully studied and extracted from various use cases in ETSI GR MEC 035 [i.2] including V2X services scenario,
multi-operator environment, Application instance transfer between a MEC system and a MEC/Cloud system,
connecting different services, immersive AR game scenario, edge service delivery through visited network and edge
node sharing.
The extracted requirements are listed as follows, summarized from ETSI GS MEC 002 [i.3]:
• MEC system discovery ([Federation-02])
• MEC platform discovery ([Federation-03])
• Information exchange between MEC systems ([Federation-04])
• Information exchange between MEC platforms ([Federation-05])
• Support handling direct/indirect MEC system communication ([Federation-06])
• MEC application discovery ([Federation-07])
• MEC application on-boarding/instantiation ([Federation-08])
• Information exchange among MEC applications ([Federation-09])
• MEC service discovery ([Federation-10])
NOTE: Reusing the data models and APIs for MEC-Cloud coordination is considered if applicable, but its
information flow is out of scope of the present document.
5.2 Sequence diagrams
5.2.1 Introduction
The rest of clause 5.2 introduces the following sequence diagrams based on the extracted requirements.
• Registration of MEC system(s) to the federation (clause 5.2.2.1)
• Discovery:
- MEC system discovery (clause 5.2.2.2)
- MEC application discovery (clause 5.2.2.3)
- MEC service discovery (clause 5.2.2.4)
• Application package management and Application instance lifecycle management (clause 5.2.2.5)
NOTE 1: Support handling direct/indirect MEC system communication is satisfied by MEC Federator as defined in
ETSI GS MEC 003 [i.4].
NOTE 2: The requirement for registration is based on the premise that multiple MEOs can register to a single MEF.
ETSI
11 ETSI GS MEC 040 V3.2.1 (2024-03)
5.2.2 Request/Response model
5.2.2.1 Registration/Update/Deregistration of MEC system to the MEC federator
5.2.2.1.1 Registration
The registration information flow is used for enabling a MEO to register its MEC system information with a MEC
Federator over Mfm reference point, as depicted in Figure 5.2.2.1.1-1.

Figure 5.2.2.1.1-1: Information flow of Registration
Registration procedure consists of the following steps:
1) The MEO sends a registration request to the MEC federator.
2) The MEC federator responds with a unique ID among federation members.
5.2.2.1.2 Update
Information flow of update of MEC system(s) to the federation is depicted in Figure 5.2.2.1.2-1.

Figure 5.2.2.1.2-1: Information flow of Update
Update procedure consists of the following steps:
1) The MEO sends an update request to MEC Federator.
2) MEC Federator returns an acknowledgement to MEO.
5.2.2.1.3 Deregistration
Information flow of deregistration of MEC system(s) from the federation is depicted in Figure 5.2.2.1.3-1.
ETSI
12 ETSI GS MEC 040 V3.2.1 (2024-03)

Figure 5.2.2.1.3-1: Information flow of Deregistration
Deregistration procedure consists of the following steps:
1) The MEO sends an update request to MEC Federator.
2) MEC Federator returns an acknowledgement to MEO.
5.2.2.2 MEC system discovery
Information flow of MEC system discovery is used for enabling MEO to be aware of another MEC system. MEC
system discovery is the primitive and essential procedure for enabling the other functionalities relating to Feature
MECFederation. The information flow is depicted in Figure 5.2.2.2-1.

Figure 5.2.2.2-1: Information flow of MEC system discovery
As a prerequisite of this flow, MEC Federator Discovery is conducted among MEC Federators, which means MEC
Federators are aware of each other in advance:
1) The MEO #1 sends a MEC system information request to MEC Federator #1 over Mfm reference point. This
request is triggered by MEC platform or MEC Application instance.
2) MEC Federator #1 forwards the request to MEC Federator #2.
3) In case where MEC Federator #2 does not have the desired information (which means MEO #2 does not
register its own information in advance), MEC Federator #2 sends a MEC system information request to MEO
#2 over Mfm reference point.
4) MEO #2 responds with the information of its own system to MEC Federator #2.
ETSI
13 ETSI GS MEC 040 V3.2.1 (2024-03)
5) MEC Federator #2 forwards the response to MEC Federator #1.
6) MEC Federator #1 forwards the response to MEO #1.
5.2.2.3 MEC application instance discovery
MEC application instance discovery refers to a process triggered by a MEC application instance or the MEC
management (MEPM or MEO), which discovers one or more MEC application instances in the MEC federation of the
application from which it was instantiated. For example, the discovery may be based on information of a specific MEC
application instance or of the corresponding application descriptor , may be with restriction information on target
location. This process can be triggered, for instance, in the cases calling for MEC application instance-to-instance
communication (e.g. neighbouring vehicles communicating with different MEC application instances may need to
cooperate via those MEC application instances. grouped users communicating with different MEC application instances
may need to communicate with each other via those MEC application instances, or grouped users may be gathered from
different MEC systems and served by a single MEC application instance). This process can be triggered by the MEC
management, for instance, in the cases the MEC management decides to find a target application instance in other MEC
system after receiving information about the user device associated to a MEC application instance moving out of the
service area of the current MEC system (e.g. the AF receives notification about User Plane change as described in
clause 4.3.6.3 of 3GPP TS 23.502 [6]). The information flow is depicted in Figure 5.2.2.3-1.

Figure 5.2.2.3-1: Information flow of MEC application discovery
Procedure of MEC application instance discovery consists of the following steps:
1) MEC application instance #1 sends a query to MEP #1 to discover a MEC application instance.
NOTE 1: MEC application instance #1 may know either the identifier of the requested application instance or
identifier of application descriptor.
2) In the case where the desired MEC application instance is not available via MEP #1, MEP #1 forwards the
query to MEO #1 via MEPM #1.
NOTE 2: How to handle the query between MEP #1 and MEO #1 is not further specified in the present document.
3) MEO #1 examines if the requested MEC application instance is available in MEC system #1. In case where
the MEC application instance is not available in MEC system #1, MEO #1 forwards the query to MEF #1.
Otherwise, go to step 10.
ETSI
14 ETSI GS MEC 040 V3.2.1 (2024-03)
Alternatively, MEC management triggers application discovery, the following step 4 is executed:
4) If the MEC management takes a decision to find application from other MEC system, MEO#1 sends a query to
MEF #1 to discover a MEC application instance.
NOTE 3: The decision mechanism in the MEC management is not further specified in the present document. The
trigger reason could be e.g. MEC management subscribes to event notification based on 3GPP standards.
5) MEF #1 forwards the query to MEF #2.
6) If the information of MEC application instance, i.e. the list of active MEC application instances, is not
registered to MEF #2, MEF #2 forwards the query to MEO #2.
7) MEO #2 responds with the information of MEC application instance(s). If no available MEC application is
discovered, void would return.
NOTE 4: In the case where multiple MEC application instances are found, the information of a list of MEC
application instances is returned. In this case, the information of the MEC platform associated with each
instance might be useful for the selection of MEC application instances. However, for security reasons,
the information of MEC platform should be hidden between federated MEC systems. Based on the
agreement among federated MEC systems, the information of MEC platform, e.g. available MEC
services, can be included in the response.
8) MEF #2 responds with the information of MEC application instance(s) to MEF #1.
9) MEF #1 responds with the information of MEC application instance(s) to MEO #1.
10) MEO #1 responds with the information of MEC application instance(s) to MEP #1 via MEPM #1.
11) MEP #1 responds with the information of MEC application instance(s) to MEC application instance #1.
5.2.2.4 MEC service discovery
MEC service discovery in a MEC federation can be performed when a MEC system of the MEC federation wants to
obtain MEC service availability. This process could be triggered in the case where the service consumer (e.g. a MEC
application or a MEC platform of a MEC system the service discovery query originates from) needs the specific MEC
service that is not available at the collocated MEC platform. The information flow is depicted in Figure 5.2.2.4-1.
NOTE 1: The desired MEC service could be provided by multiple MEC platforms. The service consumer that
triggers the discovery may select one service instance.
ETSI
15 ETSI GS MEC 040 V3.2.1 (2024-03)

Figure 5.2.2.4-1: Information flow of MEC service discovery
Procedure of MEC service discovery consists of the following steps:
1) MEP#1 sends a request to query the availability of a MEC service or a list of MEC services.
2) MEPM #1 forwards the query to MEO #1.
NOTE 2: How to handle the request between MEP, MEPM and MEO is not further specified in the present
document.
3) MEO #1 examines if the requested service(s) are available in MEC system #1. In case where the service(s) are
not available, MEO #1 forwards the query to MEF #1. Otherwise, MEO#1 responds with the information of
MEC service(s) to MEPM #1.
NOTE 3: The case where the requested service(s) are available in the MEC system is out of scope of the present
document.
4) Subject to federation agreements and operator policies, MEF #1 forwards the query to MEF #2.
5) Optionally, MEF #2 forwards the query to MEO #2. Otherwise, go to step 7.
NOTE 4: MEF is assumed to subscribe MEC service availability.
NOTE 5: The case where MEF is not able to subscribe MEC service availability is not considered in the present
document.
6) MEO #2 responds with the information of MEC service(s). If the requested MEC service(s) are not available
in MEC system #2, MEO #2 returns void.
NOTE 6: For security reasons, the information of the corresponding MEC platform information should be hidden
between the federated MEC systems.
7) MEF #2 responds with the information of MEC service(s) to MEF #1.
8) MEF #1 forwards the information of MEC service(s) to MEO #1.
9) MEO #1 forwards the information of MEC service(s) to MEPM #1.
10) MEPM #1 forwards the information of MEC service(s) to MEP #1.
ETSI
16 ET
...