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)

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.

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
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
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
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
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
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
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
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
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
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 APIs will be facilitated using CAPIF. This means that MEC applications would need to
consume MEC APIs using CAPIF support and would need to support CAPIF's authorization. In addition, further MEC
application support ("Support") is still provided. Figure 4.3.3-1 illustrates this option. The entity that exposes the
interfaces is a deployment that combines capabilities defined for the MEC platform and capabilities defined for the
CAPIF core function.
Figure 4.3.3-1: Fully-integrated hybrid deployment of CAPIF and MEC
ETSI
12 ETSI GR MEC 031 V2.1.1 (2020-10)
Such a fully-integrated deployment would however not support the MEC concept of alternative transports; it would
only apply to RESTful APIs. For additional support of alternative transports, a MEC service registry would still need to
be supported. There is no need for redundancy, however, unlike in option #1 (clause 4.3.2), all RESTful service APIs
are published and discovered via CAPIF; those services that are accessed via alternative transports are part of the MEC
service registry.
Figure 4.3.3-2 illustrates a hybrid deployment.

Figure 4.3.3-2: Hybrid deployment of CAPIF and MEC with support for MEC alternative transports
An alternative is the evolution of CAPIF by adding an extension mechanism, which would enable MEC to specify
alternative transports as a MEC-specific CAPIF extension. Interaction with 3GPP is required for this.
4.4 MEC as Application Function(s) of 5G system
MEC system appears as an Application Function or Application Functions to a 5G system. This clause describes the
study area for the MEC as an Application Function(s) of 5G system.
The MEC reference architecture is defined in ETSI GS MEC 003 [i.5]. MEC consists of functions at host level and
system level. Host level functions include MEC Platform, MEC apps, and Virtualization Infrastructure. Host level
management functions include MEC Platform Manager and Virtualization Infrastructure Manager. System level
functions include MEC Orchestrator and OSS function. When MEC is integrated into the 5G system, the key definitions
of MEC in ETSI GS MEC 003 [i.5] should be maintained.
The following examples illustrate the principle of MEC integration in the 5G system. An individual MEC application
may appear as an AF to the 5G system. Similarly, a MEC platform that influences the traffic routing of the MEC
application's traffic would appear as an AF to the 5G system. In yet another example the MEC orchestrator being
notified of a UPF change would appear as an AF to the 5G system. These examples illustrate the principle of MEC as
an AF; the 5G system exposes capabilities and information through a set of APIs to the AFs. Depending on the API in
question the MEC AF may be represented by a different functional entities of the MEC system.
The MEC system has been defined and is deployed to enable application hosting in a secure, managed environment in
the network. The impacts from the integration of MEC into a 5G system on MEC applications should be minimized.
That is, the same functionality and APIs should be available for the application irrespective of the way how MEC has
been deployed to avoid the need for deployment specific implementations of the same application.
Clause 5 of the present document contains the related key issues and proposed solutions.
4.5 Management of MEC applications in a 5G data network
The management of the MEC specific functionality of a particular MEC host and the applications running on it may be
handled by the MEC management.
ETSI
13 ETSI GR MEC 031 V2.1.1 (2020-10)
5 Key issues and potential solutions
5.1 Key issue #1: Traffic path update for mobility support
5.1.1 Description
5.1.1.1 Introduction
As described in the white paper "MEC in 5G networks" [i.6], in the extension from EPC to 5GC, 5GC has a new
application function, i.e. the traffic influence service that realizes more flexible control of traffic paths as defined in
ETSI TS 123 502 [i.2]. Since the function is exposed to the outside 5GC as described in ETSI TS 123 501 [i.1], MEC
system becomes able to flexibly choose UPF(s) and the corresponding DN according to MEC operators' and/or MEC
application providers' operation policy or unstable physical conditions. For instance, as for the mobility support, it
enables to flexibly steer the u-plane traffic to keep connectivity between UE and application instance on source MEC
host even in the case when the target MEC host is not able to host the application or the application instance in the
source MEC host can still provide a satisfactory service. The present document considers two cases of mobility support,
one is for the intra-operator case and the other one is for the inter-operator case.
5.1.1.2 Intra-operator MEC application mobility support
Regarding mobility support, in 5GC, UE mobility may cause gNB handover, then it may cause UPF changes. If
required, the user context is transferred to the application instance in the target DN in accordance with UPF changes. In
this case, traffic path would be updated accordingly as explained in ETSI GR MEC 018 (V1.1.1) [i.7], clauses 6.2.6.2,
6.2.6.3 and 6.2.6.4.
Figure 5.1.1.2-1: Mobility support
However, user context may not be transferred to the T-MEC for various reasons, e.g.:
1) in the case when the target MEC host (T-MEC host) is not able to host the application, e.g. the T-MEC host
does not have sufficient resources;
2) the application instance in the source MEC host (S-MEC host) can provide a moving user with satisfactory
service.
ETSI
14 ETSI GR MEC 031 V2.1.1 (2020-10)
Even in these cases, the traffic path should be updated as it steers the application data to the S-MEC host via either of
the T-MEC host (as depicted in figure 5.1.1.2-2 (b)) or the original UPF that associates with the S-MEC host (as
depicted in figure 5.1.1.2-2 (c)). Note that figure 5.1.1.2-2 depicts only the case of user context transfer.

Figure 5.1.1.2-2: Mobility support, where the target MEC host cannot be used
Whichever application instance is successfully transferred to T-MEC host or not, the traffic path is supposed to be
updated appropriately.
5.1.1.3 Inter-operator MEC application mobility support
As an extended use case from the previous one, MEC is also expected to support inter-operator MEC application
mobility support that includes both inter-MEC operator case and inter-PLMN case. Similarly, in the intra-operator case,
if required, the user context may be transferred to the application instance in the target DN. This is depicted in
figures 5.1.1.3-1 and 5.1.1.3-2. Note that figures 5.1.1.3-1 and 5.1.1.3-2 depict only the case of user context transfer.

Figure 5.1.1.3-1: Inter-operator mobility support
ETSI
15 ETSI GR MEC 031 V2.1.1 (2020-10)

Figure 5.1.1.3-2: Inter-operator mobility support
In the case when the T-MEC host is not able to host the application, e.g. it does not have sufficient resources, or the
application instance in the S-MEC still provides satisfactory service, the user context may not be transferred to the
T-MEC host. Two options of the application's behaviour are possible.
• The application instance stays on the S-MEC host in the source operator side as depicted in
figure 5.1.1.3-3 (b).
• The application instance is transferred to alternative MEC host (A-MEC host) in the target operator side as
depicted in figure 5.1.1.3-3 (c).
In both options, the traffic path should be updated, which steers the application data from the target UPF to the source
UPF in the same MNO's network as the source MEC host, or alternative UPF in the same MNO's network as the
T-MEC host.
Figure 5.1.1.3-3: Inter-operator mobility support, where the T-MEC host cannot be used
Inter-PLMN coordination is out of scope for the present document.
5.1.2 Solution proposal #1: 5GC control plane solution
5.1.2.1 Obtaining the mandatory input parameters
For both cases, traffic path can be maintained or updated by using the Application Function influence on traffic routing
procedures specified in ETSI TS 123 502 [i.2]. To use it, how to obtain the mandatory input parameters and how to call
it in each case should be clarified.
When MEC system calls the Application Function influence on traffic routing procedure, it requires to know 4
mandatory input parameters:
• UE identifier;
ETSI
16 ETSI GR MEC 031 V2.1.1 (2020-10)
• potential locations of applications;
• AF transaction identifier; and
• traffic description (see ETSI TS 123 501 [i.1]).
Each parameter can be obtained as follows:
• UE identifier:
Referring to ETSI TS 123 501 [i.1], "UE identifier" could be individual UE identifier or UE group identifier.
Regarding the individual UE identifier, it is not clearly specified either of IMSI, GUTI, or IP address. All of
them are possible and practical since 5GS is supposed to be capable of resolving from one to the other. The
MEC system can obtain one of them from MNO, UE or application.
• Potential locations of applications:
Once MEC system can specify DNAI(s), 5GS can resolve the corresponding UPF, then, steer UP path to the
target UPF. The MEC system is supposed to know the appropriate DNAI(s) in advance. The information might
require to be provided by MNOs because DNAI is the pre-configured value that is generated by MNO.
• AF transaction identifier:
According to ETSI TS 123 501 [i.1], AF transaction identifier is an internal ID that is generated by AF when
AF receives a request from outside. Therefore, from the MEC's point of view, the MEC system does not need
to take care of this ID.
• Traffic description:
According to ETSI TS 123 501 [i.1], the information defines the target traffic to be influenced, represented by
the combination of DNN and optionally S-NSSAI, and application identifier or traffic filtering information.
The application identifier can be obtained from MNOs since the identifier is preconfigured by them. If MEC
system knows more detailed information, e.g. IP addresses, it provides detailed traffic description for fine-
grained UP steering.
5.1.2.2 High level message flow to influence traffic path for intra-operator case
Figure 5.1.2.2-1 depicts the detailed function blocks in intra-operator case. Interactions between these blocks make it
possible to resolve the required traffic path update. The MEO acts as AF to interact with NEF as an example.

Figure 5.1.2.2-1: Function blocks in intra-operator case
Figure 5.1.2.2-2 depicts the option 1 of high-level information flow to influence the traffic flow, the MEO acts as AF to
interact with NEF as an example.
ETSI
17 ETSI GR MEC 031 V2.1.1 (2020-10)

Figure 5.1.2.2-2: Option 1 of high-level information flow to influence the traffic flow
in intra-operator case
The high level information flow to influence the traffic flow consists of the following steps:
(1) In the case where the MEC Orchestrator (MEO) subscribes the UP path management event notifications, MEC
orchestrator receives the notification from SMF(s) directly or via NEF, which means UP and corresponding
DN have changed according to the UE mobility.
(1') In the case of RNIS, the source MEC platform (S-MEC platform), on behalf of application instances,
subscribes the cell change notification associated with a UE. After S-MEC platform receives the notification, it
determines whether the UE has moved out of the coverage. If this is the case, S-MEC platform sends an
application mobility request to MEO.
(2) MEO selects the target MEC host.
(3) In the case where the target MEC host is not available due to any reason, e.g. target MEC host does not have
sufficient resources, the application instance should continue on the source MEC host and UP path should be
redirected to the UPF associated with the S-MEC host.
(4) MEO sends Nnef_trafficinfluence update request with appropriate input parameters according to the
notification from S-MEC platform manager and reply from T-MEC platform manager.
These steps provide the continuity of the connection between UE and MEC application that is located on the S-MEC
host.
Figure 5.1.2.2-3 depicts the option 2 of high-level information flow to influence the traffic flow.
ETSI
18 ETSI GR MEC 031 V2.1.1 (2020-10)

Figure 5.1.2.2-3: Option 2 of high-level information flow to influence the traffic flow
in intra-operator case
NOTE: MEC system in this option can be MEO, MEC platform or MEPM.
The high level information flow to influence the traffic flow consists of the following steps:
1. Precondition: The MEC system has already informed the 5GC control plane the potential positions of the
application instances. The MEC system requests to be subscribed to notifications about UP path management
events. The "AF acknowledgment to be expected" indication is included. This request is sent to the PCF
directly or via the NEF.
2. A condition for an AF notification has been met, for example the DNAI is going to be changed.
3. The SMF sends the notification to the MEC system directly or via the NEF. The notification type may be early
notification or late notification. The source and destination DNAI are included if the DNAI will be changed.
The SMF will wait for the acknowledgement from the MEC system.
4. The MEC system sends the positive response after application relocation is completed. The MEC system may
also send the positive response immediately if it expects the UP path change but does not need application
relocation.
5. The SMF activates the UP path towards the new DNAI.
6. The MEC system rejects the DNAI change by sending a negative response to the SMF directly or via NEF, in
cases of the application relocation cannot be completed on time or the current application instance can satisfy
the service requirement.
7. The SMF keeps using the original DNAI and may cancel related PSA relocation or addition. The SMF may
perform DNAI reselection afterwards if needed.
5.1.2.3 High level message flow to update the traffic path for inter-operator case
Figure 5.1.2.3-1 depicts the detailed function blocks in inter-operator case. Interactions between these blocks make it
possible to continue MEC application and to resolve the required traffic path update. Figure 5.1.2.3-2 depicts the high
level information flow to update the traffic flow in inter-operator case.
ETSI
19 ETSI GR MEC 031 V2.1.1 (2020-10)
NOTE 1: The presented flow is just one of the possible alternatives. Other possibil
...