ETSI GR MEC 031 V2.1.1 (2020-10)

Multi-access Edge Computing (MEC) MEC 5G Integration

DGR/MEC-00315GIntegration

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 20-Oct-2020
• Completion Date: 23-Oct-2020

Standards Content (Sample)

ETSI GR MEC 031 V2.1.1 (2020-10)





GROUP REPORT
Multi-access Edge Computing (MEC)
MEC 5G Integration
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 031 V2.1.1 (2020-10)



Reference
DGR/MEC-00315GIntegration
Keywords
5G, 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 2020.
All rights reserved.

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.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GR MEC 031 V2.1.1 (2020-10)
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 . 8
4.1 Introduction . 8
4.2 MEC interactions with 5GS. 8
4.3 MEC platform in 5G common API framework . 9
4.3.1 Integrating MEC and CAPIF . 9
4.3.2 Option #1: Providing access to MEC APIs via an external CAPIF instance . 10
4.3.3 Option #2: CAPIF and MEC unified . 11
4.4 MEC as Application Function(s) of 5G system . 12
4.5 Management of MEC applications in a 5G data network . 12
5 Key issues and potential solutions . 13
5.1 Key issue #1: Traffic path update for mobility support . 13
5.1.1 Description . 13
5.1.1.1 Introduction . 13
5.1.1.2 Intra-operator MEC application mobility support . 13
5.1.1.3 Inter-operator MEC application mobility support . 14
5.1.2 Solution proposal #1: 5GC control plane solution . 15
5.1.2.1 Obtaining the mandatory input parameters . 15
5.1.2.2 High level message flow to influence traffic path for intra-operator case. 16
5.1.2.3 High level message flow to update the traffic path for inter-operator case . 18
5.1.3 Solution proposal #2: D-Plane overlay and AF use for N6 traffic steering policy alignment and
enforcement . 20
5.1.3.1 General design objectives and deployment aspects . 20
5.1.3.2 Proposed Functional Architecture . 20
5.1.3.3 Operational aspects - Traffic steering for intra-MEC Application Mobility . 21
5.1.3.4 Operational aspects - Traffic steering for inter-MEC Application Mobility . 22
5.1.4 Evaluation . 23
5.2 Key issue #2: Ping-pong handover mitigation . 24
5.2.1 Description . 24
5.2.2 Solution proposal #1: Make use of Nnef_trafficinfluence update. . 24
5.2.3 Evaluation . 25
5.3 Key issue #3: Enablers for local access to a DN in a 5GS . 25
5.3.1 Description . 25
5.3.2 Solution proposal #1: UE capability and use case-aware traffic redirection . 26
5.3.3 Evaluation . 26
5.4 Key issue #4: Support for the Radio Network Information Service . 27
5.4.1 Description . 27
5.4.2 Solution proposal #1: O-RAN RIC . 27
5.4.3 Evaluation . 28
5.5 Key Issue #5: AF Influence on traffic routing . 28
5.5.1 Description . 28
5.5.2 Solution Proposal #1: AF request targeting an individual UE . 28
5.5.3 Solution Proposal #2: AF request targeting a group of UEs . 29
5.5.4 Evaluation . 30
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR MEC 031 V2.1.1 (2020-10)
5.6 Key Issue #6: Mapping MEC API framework to CAPIF . 30
5.6.1 Description . 30
5.6.2 Solution proposal #1: Mapping of the APIs . 30
5.6.2.1 Overview . 30
5.6.2.2 Mapping of the resource structures . 31
5.6.2.3 Mapping of the service discovery queries . 31
5.6.2.4 Data models for service API discovery and publication . 32
5.6.2.4.1 MEC: Data model for MEC services . 32
5.6.2.4.2 CAPIF: Data model for service APIs . 34
5.6.2.5 Data models for service API announcement/notification . 37
5.6.2.5.1 MEC: Data model for service availability subscriptions and notifications. 37
5.6.2.5.2 CAPIF: Event subscription and event notification . 38
5.6.3 Evaluation . 40
5.7 Key Issue #7: MEC application consumes 5GC exposed capabilities . 40
5.7.1 Description . 40
5.7.2 Solution proposal #1: MEC application accesses NEF directly . 40
5.7.3 Solution proposal #2: MEP proxies MEC application to access NEF . 41
5.7.4 Evaluation . 42
5.8 Key issue #8: Information exposure for MEC Application Instances . 42
5.8.1 Description . 42
5.8.2 Solution proposal #1: MEC Platform exposes the information of all running instances . 42
5.8.3 Evaluation . 43
6 Gap analysis and recommendations . 44
Annex A: Change History . 45
History . 47


ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR MEC 031 V2.1.1 (2020-10)
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 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 031 V2.1.1 (2020-10)
1 Scope
The present document describes the key issues, solution proposals and recommendations for MEC integration into
3GPP 5G system. The following aspects are addressed: MEC System interactions with the 5G System, including the
correspondence of the current MEC procedures to procedures available in 3GPP 5G system specification, options for
the functional split between MEC and 5G Common API framework, realization of MEC as 5G Application Function(s).
In addition the present document addresses the scope and the preferred way of proceeding with the identified future
technical work, as well as the identification of any missing 5G system functionality for MEC integration.
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 TS 123 501: "5G; System architecture for the 5G System (5GS) (3GPP TS 23.501
Release 16)".
[i.2] ETSI TS 123 502: "5G; Procedures for the 5G System (5GS) (3GPP TS 23.502 Release 16)".
[i.3] ETSI TS 129 522: "5G; 5G System; Network Exposure Function Northbound APIs; Stage 3
(3GPP TS 29.522 Release 16)".
[i.4] ETSI TS 123 222: "LTE; 5G; Common API Framework for 3GPP Northbound APIs (3GPP
TS 23.222 Release 16)".
[i.5] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[i.6] ETSI White Paper No. 28: "MEC in 5G networks".
[i.7] ETSI GR MEC 018: "Mobile Edge Computing (MEC); End to End Mobility Aspects".
[i.8] ETSI GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[i.9] ETSI TS 129 571: "5G; 5G System; Common Data Types for Service Based Interfaces; Stage 3
(3GPP TS 29.571 Release 16)".
[i.10] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[i.11] ETSI TS 129 222: "5G; LTE; Common API Framework for 3GPP Northbound APIs (3GPP
TS 29.222 Release 16)".
[i.12] ETSI GS MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.13] ETSI GS MEC 016: "Multi-access Edge Computing (MEC); Device application interface".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR MEC 031 V2.1.1 (2020-10)
[i.14] ETSI GS MEC 021: "Multi-access Edge Computing (MEC); Application Mobility Service API".
[i.15] ETSI TS 129 501: "5G; 5G System; Principles and Guidelines for Services Definition; Stage 3
(3GPP TS 29.501 Release 16)".
[i.16] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles, patterns and
common aspects of MEC Service APIs".
[i.17] RIC Measurement Campaign application.
NOTE: Available at https://docs.o-ran-sc.org/projects/o-ran-sc-ric-app-mc/en/latest/overview.html.
[i.18] RIC Application Architecture.
NOTE: Available at https://wiki.o-ran-sc.org/display/RICA/Architecture.
[i.19] ETSI TS 129 514: "5G; 5G System; Policy Authorization Service; Stage 3 (Release 16)"5G; 5G
System; Policy Authorization Service; Stage 3 (3GPP TS 29.514 Release 16)".
[i.20] ETSI TS 129 500: "5G; 5G System; Technical Realization of Service Based Architecture; Stage 3
(3GPP TS 29.500 Release 16)".
[i.21] ETSI TS 129 523: "5G; 5G System; Policy Control Event Exposure Service; Stage 3 (3GPP
TS 29.523 Release 16)".
[i.22] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
NOTE: Available at https://tools.ietf.org/html/rfc4122.
[i.23] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
NOTE: Available at https://tools.ietf.org/html/rfc3986.
[i.24] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[i.25] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
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.12] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.12] and the following apply:
5GC 5G Core network
5GS 5G System
AF Application Function
AMF Access and Mobility management Function
AS Application Server
BM-SC Broadcast Multicast-Service Center
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR MEC 031 V2.1.1 (2020-10)
BSF Binding Support Function
CAPIF Common API Framework for 3GPP northbound APIs
CCF CAPIF Core Function
CU Central Unit
DN Data Network
DNAI Data Network Access Identifier
DNN Data Network Name
GPSI Generic Public Subscription Identifier
LADN Local Area Data Network
LBO Local Break Out
MBMS Multimedia Broadcast Multicast Service
NEF Network Exposure Function
NF Network Function
NRF Network Repository Function
NSSAI Network Slice Selection Assistance Information
PCC Policy and Charging Control
PCF Policy Control Function
PDU Protocol Data Unit
PLMN Public Land Mobile Network
R-NIB Radio-Network Information Base
RIC RAN Intelligent Controller
RNIS Radio Network Information Service
RRM Radio Resource Management
RSRP Reference Signal Receive Power
RT Real Time
RU Radio Unit
SCEF Service Capability Exposure Function
SMF Session Management Function
SRv6 Segment Routing over IPv6
UDR Unified Data Repository
UE User Equipment
UL UpLink
UL CL UpLink CLassifier
UPF User Plane Function
4 Overview
4.1 Introduction
The present document describes the key study areas in the MEC 5G integration.
Clause 4 provides the description of each identified study area.
Clause 5 contains all identified key issues and their related solution proposals.
Clause 6 contains evaluation of proposed solutions. Based on identified gaps, recommendations for further work are
provided.
4.2 MEC interactions with 5GS
3GPP 5G system supports the exposure of network information and capabilities to external consumers. MEC as an
Application Function (AF) may interact with the 5G system for the following reasons as specified in ETSI
TS 123 501 [i.1], clause 6.2.10:
• to influence the application traffic routing decisions, including User Plane Function (UPF) (re)selections;
• to access the Network Exposure Function (NEF) for network capabilities;
• to interact with the policy framework for policy control.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GR MEC 031 V2.1.1 (2020-10)
AFs that are not allowed by the operator to access directly the target Network Functions (NFs) use the NEF for their
interactions. These AFs can be termed as an untrusted AF, outside the trust domain of a network operator, as compared
to a trusted AF or trusted Network Functions (NFs) that is inside the trust domain, e.g. owned or operated by a network
operator. An untrusted AF may be owned and operated by operator external entities such as a cloud or edge service
provider, a gaming service provider, etc. It is out of scope of the present document to define which kind of information
may be exposed to MEC, as an untrusted AF, to support better operation while maintaining security and privacy of
operator's network. While the NEF is used for untrusted AFs, a trusted AF may interface with the 5GS via NEF or
interface directly with 5GS functions, such as SMF, etc.
The NEF is the 5G NF in charge of securely exposing the network capabilities and events to AFs and other consumers
as defined in ETSI TS 123 501 [i.1], clause 6.2.5. External exposure can be categorized as monitoring capability,
provisioning capability, and policy/charging capability. The details of the external exposure of the capabilities are
defined in ETSI TS 123 502 [i.2]. The Restful APIs for capability exposure are defined in ETSI TS 129 522 [i.3].
An AF can get services from multiple NEFs and an NEF can provide service to multiple AFs. Any instance of an NEF
may support only a subset or all of the available NEF functionality.
An NEF may support Common API Framework (CAPIF) functionality, and more specifically the CAPIF API provider
domain functions, for external exposure ETSI TS 123 222 [i.4].
4.3 MEC platform in 5G common API framework
4.3.1 Integrating MEC and CAPIF
In 3GPP, there are multiple northbound API-related specifications (e.g. APIs for SCEF, API for the interface between
MBMS service provider and BM-SC, and also the current most important APIs for NEF). To avoid duplication and
inconsistency of approach between different API specifications, 3GPP has considered the development of a common
API framework for 3GPP northbound APIs (CAPIF) that includes common aspects applicable to any northbound
service APIs.
The functional model for the common API framework (CAPIF) is organized into functional entities to describe a
functional architecture which enables an API invoker to access and invoke service APIs and supports API exposing
functions in publishing the API towards the API invokers. The CAPIF functional model can be adopted by any 3GPP
functionality providing service APIs.
The relationship between the MEC API framework and the CAPIF is shown in figure 4.3.1-1.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GR MEC 031 V2.1.1 (2020-10)

Figure 4.3.1-1: Relationship between MEC and 5G common API framework
MEC platform includes API-related platform functionality such as service registry. In addition the MEC platform can
also expose MEC service APIs for consumption by MEC applications.
The API provider domain in CAPIF collectively represents the service APIs available for consumption in any 5G NF
rd
and any trusted 3 party AF. A MEC service produced by a MEC application or the MEC platform can be mapped into
the API provider domain in CAPIF.
A MEC application or MEC platform consuming a service is an API invoker in CAPIF.
The existing MEC platform functionality related to API enablement, can be mapped into the CAPIF core function.
The MEC platform also supports traffic rules control and DNS handling. These functionalities are outside the scope of
CAPIF. Instead in 5GS the traffic rules control by an AF has been defined as a procedure between the AF and the SMF,
possibly involving the NEF, as defined in ETSI TS 123 502 [i.2], clause 4.3.6.
4.3.2 Option #1: Providing access to MEC APIs via an external CAPIF
instance
In this option, it is assumed that a MEC platform and a CAPIF deployment co-exist in the network, and that CAPIF API
invokers want to access MEC services provided by the MEC platform or by MEC applications via the RESTful MEC
service APIs.
In that case, the following applies:
• It needs to be possible to announce MEC APIs in CAPIF registry.
• It needs to be possible to use the CAPIF flavour of authorization when accessing MEC APIs. This might be
realized via a gateway, or by updating the MEC API exposing functions to understand the CAPIF flavour of
authorization.
This use case can be fulfilled by announcing the same service API redundantly in both the registry of the CAPIF core
function in the network, and in the MP1 registries in the MEC platform(s).
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GR MEC 031 V2.1.1 (2020-10)
NOTE 1: In MEC, location of the API producer matters. It has not been elaborated in the present document how to
signal multiple instances of the same service available at different locations (e.g. different MEC
platforms) when using CAPIF.
The following figure 4.3.2-1 illustrates the loosely coupled deployment.
The MEC reference point Mp1 supports publication of MEC services ("M-Publication"), discovery/announcement of
MEC services ("M-Discovery") and further MEC application support ("Support") such as activation of traffic rules. The
CAPIF core function supports publication ("C-Publication") and discovery ("C-Discovery") of CAPIF APIs.
The simplest integration possibility is to re-publish the MEC service APIs via CAPIF.
NOTE 2: Consumption/invocation of APIs is out of scope in this figure, but would need to be addressed separately.

Figure 4.3.2-1: Loosely-coupled deployment of CAPIF and MEC
4.3.3 Option #2: CAPIF and MEC unified
In this option, it is assumed that a deployment exists that unifies MEC and CAPIF.
In such realization, CAPIF replaces those Mp1 parts that are overlapping with CAPIF (such as the MEC service registry
of RESTful MEC services). The registry for the MEC services will be based on CAPIF; the same applies to
authorization. The MEC platform can benefit from further CAPIF core function (CCF) support such as logging.
All invocations of RESTful A
...