ETSI GS MEC 021 V2.1.1 (2020-01)

Multi-access Edge Computing (MEC); Application Mobility Service API

DGS/MEC-0021AppMobility

General Information

• Status: Published
• Publication Date: 20-Jan-2020
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 31-Jan-2020
• Completion Date: 21-Jan-2020

Standards Content (Sample)

GROUP SPECIFICATION
Multi-access Edge Computing (MEC);
Application Mobility Service API
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 021 V2.1.1 (2020-01)

Reference
DGS/MEC-0021AppMobility
Keywords
application, MEC, mobility
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 GS MEC 021 V2.1.1 (2020-01)
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 . 8
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 Specification level requirements . 9
4.1 Introduction . 9
4.2 Functional requirements . 9
5 Description of the services (informative) . 10
5.1 Introduction . 10
5.2 End to end application mobility information flows . 10
5.3 Application mobility enablement . 11
5.4 Application relocation initiation . 12
5.4.1 Overview . 12
5.4.2 MEC assisted application mobility information flow . 13
5.4.2.1 S-MEP triggered application mobility using RNIS . 13
5.5 Application relocation verification and validation . 14
5.6 User context transfer . 14
5.6.1 Introduction. 14
5.6.2 Application self-controlled user context transfer . 14
5.6.3 Device application assisted user context transfer . 14
5.6.4 MEC assisted user context transfer . 15
5.7 Application traffic path update . 15
5.8 Application relocation completion . 15
6 Sequence diagrams . 15
6.1 Introduction . 15
6.2 Register to application mobility service . 16
6.3 Deregister to application mobility service . 16
6.4 Update application mobility service . 17
6.5 User context transfer completion . 17
6.6 Subscribe to notifications of application mobility service . 18
6.7 Unsubscribe to notifications of application mobility service . 18
6.8 Update subscription to application mobility service notifications . 19
7 Data Models . 19
7.1 Introduction . 19
7.2 Registration data types . 19
7.2.1 Introduction. 19
7.2.2 Type: RegistrationInfo . 19
7.2.3 Type: AdjacentAppInstanceInfo . 20
7.3 Subscription data types . 20
7.3.1 Introduction. 20
7.3.2 Type: MobilityProcedureSubscription . 20
7.3.3 Type: AdjacentAppInfoSubscription . 21
7.3.4 Type: SubscriptionLinkList . 21
7.4 Notification data types . 22
7.4.1 Introduction. 22
ETSI
4 ETSI GS MEC 021 V2.1.1 (2020-01)
7.4.2 Type: MobilityProcedureNotification . 22
7.4.3 Type: AdjacentAppInfoNotification . 22
7.4.4 Type: ExpiryNotification . 23
7.4.5 Type: AppMobilityServiceLevel . 23
7.5 Referenced structured data types . 24
7.5.1 Introduction. 24
7.5.2 Type: CommunicationInterface . 24
8 API Definition . 24
8.1 Introduction . 24
8.2 Global definitions and resource structure . 24
8.3 Resource: application mobility services . 26
8.3.1 Description . 26
8.3.2 Resource definition . 26
8.3.3 Resource methods . 26
8.3.3.1 GET . 26
8.3.3.2 PUT . 27
8.3.3.3 PATCH . 27
8.3.3.4 POST . 27
8.3.3.5 DELETE . 28
8.4 Resource: individual application mobility service . 28
8.4.1 Description . 28
8.4.2 Resource definition . 29
8.4.3 Resource methods . 29
8.4.3.1 GET . 29
8.4.3.2 PUT . 30
8.4.3.3 PATCH . 31
8.4.3.4 POST . 31
8.4.3.5 DELETE . 31
8.5 Resource: deregister application mobility service task. 32
8.5.1 Description . 32
8.5.2 Resource definition . 32
8.5.3 Resource methods . 33
8.5.3.1 GET . 33
8.5.3.2 PUT . 33
8.5.3.3 PATCH . 33
8.5.3.4 POST . 33
8.5.3.5 DELETE . 34
8.6 Resource: subscriptions . 34
8.6.1 Description . 34
8.6.2 Resource definition . 34
8.6.3 Resource methods . 35
8.6.3.1 GET . 35
8.6.3.2 PUT . 35
8.6.3.3 PATCH . 35
8.6.3.4 POST . 36
8.6.3.5 DELETE . 37
8.7 Resource: individual subscription . 37
8.7.1 Description . 37
8.7.2 Resource definition . 37
8.7.3 Resource methods . 37
8.7.3.1 GET . 37
8.7.3.2 PUT . 38
8.7.3.3 PATCH . 40
8.7.3.4 POST . 40
8.7.3.5 DELETE . 40
8.8 Resource: adjacent application instances . 41
8.8.1 Description . 41
8.8.2 Resource definition . 41
8.8.3 Resource methods . 41
8.8.3.1 GET . 41
8.8.3.2 PUT . 43
ETSI
5 ETSI GS MEC 021 V2.1.1 (2020-01)
8.8.3.3 PATCH . 43
8.8.3.4 POST . 43
8.8.3.5 DELETE . 43
Annex A (informative): Key concepts . 44
A.1 Application mobility. 44
A.1.1 Introduction . 44
A.1.2 Application availability in the target host . 45
A.1.3 User context transfer . 45
A.2 Mapping of permissions for RESTful API and resources . 45
History . 47

ETSI
6 ETSI GS MEC 021 V2.1.1 (2020-01)
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 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 021 V2.1.1 (2020-01)
1 Scope
The present document provides a specification for end-to-end MEC application mobility support in a multi-access edge
system. The present document describes information flows, required information and operations. The present document
also specifies the necessary API with the data model and data format.
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] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[3] ETSI GS MEC 003: "Multi-access Edge Computing (MEC); Framework and Reference
Architecture".
[4] ETSI GS MEC 009: "Multi-access Edge Computing (MEC); General principles for MEC Service
APIs".
[5] ETSI GS MEC 011: "Multi-access Edge Computing (MEC); Edge Platform Application
Enablement".
[6] ETSI GS MEC 012: "Multi-access Edge Computing (MEC); Radio Network Information API".
[7] ETSI GS MEC 010-2: "Multi-access Edge Computing (MEC); MEC Management;
Part 2: Application lifecycle, rules and requirements management".
[8] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available at https://tools.ietf.org/html/rfc6749.
[9] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available at https://tools.ietf.org/html/rfc6750.
ETSI
8 ETSI GS MEC 021 V2.1.1 (2020-01)
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 016: "Multi-access Edge Computing (MEC); UE application interface".
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 [1].
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:
AMS Application Mobility Service
API Application Programming Interface
GTP GPRS Tunnelling Protocol
HTTP HyperText Transfer Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
JSON JavaScript Object Notation
RFC Request For Comments
RNIS Radio Network Information Service
S-App Source - Application instance
S-DP Source - Data Plane
S-MEP Source - MEC Platforms
S-MEPM Source - MEC Platform Manager
T-App Target - Application instance
T-DP Target - Data Plane
T-MEP Target - MEC Platforms
T-MEPM Target - MEC Platform Manager
TEID Tunnel End point IDentifier
URI Uniform Resource Indicator
VIM Virtualization Infrastructure Manager
ETSI
9 ETSI GS MEC 021 V2.1.1 (2020-01)
4 Specification level requirements
4.1 Introduction
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, especially when the MEC host is attached
to mobile operator's networks. As a mobile device connected to a mobile network moves around within the network, it
can result in the device connecting to the network entity associated to a different MEC host from the serving host.
Consequently, there is necessity of relocating the application instance and/or user context associated to the device to a
new MEC host to continue offering the best performance of service.
ETSI GS MEC 002 [2] describes some use cases related to application mobility or smart relocation, and associated
requirements for MEC system to relocate the application instance and/or context to the "right" MEC host for optimizing
the performance.
Application mobility may involve multiple MEC functional entities to relocate application instances and transfer user
and application specific information within or between the MEC systems. Relocation decisions may be based on device
mobility, customer profiles, application preferences and/or MEC infrastructure capability.
4.2 Functional requirements
Table 4.2-1 summarizes the functional requirements related to application mobility specified in ETSI GS MEC 002 [2].
Table 4.2-1: Functional requirements
Numbering Functional requirement description
AppMobility01 [Mobility-01] The MEC system shall be able to maintain connectivity between a UE and an
application instance when the UE performs a handover to another cell associated
with the same MEC host.
AppMobility02 [Mobility-02] The MEC system shall be able to maintain connectivity between a UE and an
application instance when the UE performs a handover to another cell not
associated with the same MEC host.
AppMobility03 [Mobility-03] The MEC platform may use available radio network information to optimize the
mobility procedures required to support service continuity.
AppMobility04 [Mobility-04] The MEC platform may use available core network information to optimize the
mobility procedures required to support service continuity
AppMobility05 [Connectivity-02] The MEC system shall support two instances of a MEC application running on
different MEC hosts to communicate with each other.
AppMobility06 [Connectivity-03] The MEC platform shall be able to allow an authorized MEC application to
communicate with another MEC application located on another MEC host.
AppMobility07 [SmartReloc-03] When the MEC system supports the feature SmartRelocation, the MEC
management shall support the relocation of a MEC application instance from one
MEC host to a different host within the system.
AppMobility08 [SmartReloc-04] When the MEC system supports the feature SmartRelocation, a MEC host may
support the relocation of a MEC application instance from a different host (within the
system) to this particular host, and from this particular host to a different host (within
the system).
AppMobility09 [SmartReloc-05] When the MEC system supports the feature SmartRelocation, the system shall be
able to move MEC application instances between MEC hosts in order to continue to
satisfy the requirements of the MEC application.
AppMobility10 [SmartReloc-06] When the MEC system supports the feature SmartRelocation, and based on a
request from the UE, the system shall be able to relocate a MEC application running
in a cloud environment to a MEC host fulfilling the requirements of the MEC
application, and relocate a MEC application from a MEC host to a cloud environment
outside the MEC system.
NOTE: The numbering of requirement in [ ] refers to the corresponding requirement in ETSI GS MEC 002 [2].

ETSI
10 ETSI GS MEC 021 V2.1.1 (2020-01)
5 Description of the services (informative)
5.1 Introduction
Application mobility service support may be considered as part of the service continuity support, for which the service
to the user will resume and continue when the application instance is made available in the target MEC host and the
user context, if needed, is transferred to the application instance there.
The characteristics of the service produced by the server application determines whether or not user context transfer is
required for service continuity. For a stateless server application there is no state, i.e. user context, to transfer. For a
stateful server application the user context may have to be transferred to the target application instance.
NOTE 1: The specification of the user context is outside the scope of the present document.
Application mobility support includes the following high level actions: the instantiation of the application in the target
MEC host, if needed, and the transfer of user context, if needed, to the target application instance.
NOTE 2: The scenario of application mobility between two MEC systems and between the MEC system and an
external cloud system is not specified in the present document.
Application mobility may involve multiple functional entities in MEC system, depending on different implementation
approaches:
1) Application self-controlled user context transfer: The application itself, i.e. the server application instance
(i.e. MEC application), or the client side application instance, or the centralized cloud instance, if available,
may synchronize the user context in the target server application instance when necessary.
NOTE 3: For server application instances to resynchronize the user context the precondition is for MEC to enable
the connectivity between the peer server application instances.
NOTE 4: The determination of the need for synchronization as well as the synchronization of the user context are
application implementation dependent, and are outside the scope of the present document.
2) Device application assisted user context transfer: Device application initiates/triggers the application mobility
and keeps the user context in the client during the relocation. The MEC system is the decision maker about the
application mobility. Once the application is instantiated on the new MEC host, the application client will
communicate with the server application instance directly to transfer and synchronize the user context.
NOTE 5: The user context transfer and synchronization are outside the scope of the present document.
3) MEC assisted user context transfer: MEC system triggers the application mobility. MEC system may facilitate
the transfer of the user context to the target application instance.
Support of application mobility also depends on the application capability. An application instance may be dedicated to
serve a single user; or it may serve multiple users simultaneously, such as multicast service to a group of users, or
broadcast service to all the users associated to the MEC host.
Clause 5 provides descriptions of service for the three high level approaches described above. In addition, high level
information flows for application mobility in different scenarios are provided. The high level information flows are then
split into individual procedures to be defined in the present specification or in other MEC specifications. When possible,
it is recommended to reuse the existing procedures, data models and APIs for application mobility.
5.2 End to end application mobility information flows
The high level application mobility service information flow for intra MEC system is shown in figure 5.2-1.
ETSI
11 ETSI GS MEC 021 V2.1.1 (2020-01)

Figure 5.2-1: High level application mobility service information flow
The information flow of intra MEC system application mobility service may be divided into several sub-procedures that
may or may not be present in the actual mobility scenario:
1) Application mobility enablement and registration: this sub-procedure illustrates the general procedure on
enabling the application mobility service and allowing the application instances to register to the required
application mobility services.
2) User context transfer initiation: this sub-procedure illustrates various detecting and triggering mechanisms for
transferring the user context to the target application instance.
3) User context transfer preparation: this is an optional sub-procedure for MEC assisted user context transfer, and
used for MEC system to prepare for the transfer.
4) User context transfer execution: this sub-procedure illustrates how the user context is transferred to and
synchronized on the application instance running on the target MEC host.
5) Application traffic path update: this sub-procedure illustrates how MEC system reconfigures the data plane to
redirect the traffic to the application instance on the target MEC host.
6) User context transfer completion: this sub-procedure illustrates how MEC system to clean-up the user context
and/or application instance at source MEC host after the user context has been transferred.
The services like RNIS on the source MEC host and the target MEC host may be involved in the application mobility
procedures. The detailed involvement will be described in the individual sub-procedures.
5.3 Application mobility enablement
The application mobility capability (e.g. UserContextTrasnferCapability) information may be included in the
application descriptor (AppD) to indicate the stateful/stateless characteristic, the support of user context transfer, and
the application mobility service dependency.
A suitable MEC host is selected based on the application requirements (including the application mobility support
requirements) to instantiate the application. The application instance can register to the available AMS for application
mobility support. The MEC system may also instantiate the same applications in other MEC host to assist the
application mobility.
The information flow of application mobility service enablement and registration is shown in figure 5.3-1.
ETSI
12 ETSI GS MEC 021 V2.1.1 (2020-01)

Figure 5.3-1: Application mobility service enablement and registration
The steps 1 - 5 are existing procedures specified in ETSI GS MEC 010-2 [7] and ETSI GS MEC 011 [5]:
6) The application instance sends the application mobility service registration request to the AMS running on the
MEC host.
7) The AMS sends the application mobility service registration response to the application instance with the
application mobility service ID to confirm the service registration success. The application mobility service is
then enabled to serve to this application instance.
5.4 Application relocation initiation
5.4.1 Overview
Application mobility service support may rely on many factors, and may be initiated by different functional entities in
the MEC system, including:
1) A combination of source and target MEPs and their associated services. Specific combinations include S-MEP
& S-RNIS, S-MEP & S-DP, T-MEP & T-RNIS, T-MEP & T-DP, and the MEO.
2) A MEC application instance.
3) A UE application client.
A service of particular relevance to application mobility is RNIS which provides the services of radio network
information to AMS. The information used to trigger application mobility services may include:
• information about UEs connected to the radio node(s) associated with the MEC host, and the related radio
access bearers;
• changes in information related to UEs connected to the radio node(s) associated with the MEC host and the
information related radio access bearers.
Using RNIS, the AMS is able to query for radio information or subscribe to notifications related to special events, a
particular UE, or to radio node(s) attached to the MEC host.
ETSI
13 ETSI GS MEC 021 V2.1.1 (2020-01)
RNIS uses a service consumer specified associateId to identify a particular UE or UE(s). The identifiers of the
associateId by RNIS are:
• UE IPv4 address;
• UE IPv6 address;
• NATed IP address; or
• GTP TEID.
5.4.2 MEC assisted application mobility information flow
5.4.2.1 S-MEP triggered application mobility using RNIS
The first step in this flow is the AMS in the serving MEP (S-MEP) subscribing to cell change notifications for a UE or
UEs in the cell(s) (radio nodes) associated to the MEC host. When a tracked UE moves across cells’ boundary of the
underlying network, the RNIS of serving MEC host (i.e. S-RNIS) will send event notifications about cell changes to the
AMS in S-MEP. This may trigger application mobility procedures. Based on the received cell change notifications, the
AMS in S-MEP verifies whether the UE has moved out of the coverage area of the source MEC host. If it does, the
AMS in S-MEP will initiate application mobility procedures toward the T-MEH. The AMS in S-MEP uses the
associateId in the notification to identify the target UE.
The S-MEP (i.e. AMS) initiated application mobility information flow regarding to UE cell change (handover) is
depicted in figure 5.4.2.1-1.
Figure 5.4.2.1-1: The information flow of S-MEP initiated application mobility
The information flow of S-MEP (i.e. AMS) initiated application mobility consists of following steps:
0) The AMS in S-MEP, registered by the application instance, subscribes the cell change notification associated
with a UE or UEs in the cells under the MEC host. The AMS in S-MEP maps the appInstanceId with the
associateId(s) after subscription. When a specified UE moves within the underlying network and triggers a cell
change event, the S-RNIS sends a RNI cell change notification that indicates the handover status of the UE.
1) The associateId in the cell change notification can identify the UE that is performing the handover. The AMS
in S-MEP processes the received cell change notification, mapping the notification to the application
instance(s) serving the UE. The AMS in S-MEP may correlate different notifications to determine whether the
UE has moved out of the coverage area of the S-MEH. If it does, the AMS in S-MEP sends to the MEO
through the S-MEPM the MobilityProcedureNotification including the UE ID (associateId), the application
instance IDs (appInstanceId), the source radio node ID (srcEcgi) and the target radio node ID (trgEcgi) which
are all reported in the RNI cell change notification.
2) The S-MEPM relays the MobilityProcedureNotification to the MEO.
ETSI
14 ETSI GS MEC 021 V2.1.1 (2020-01)
5.5 Application relocation verification and validation
When a UE moves to the service area of another MEC host, the MEC may instantiate on that MEC host the same
application as the one serving to the UE, if an instance of the same application does not exist. The application relocation
verification and validation are not addressed in the present document.
5.6 User context transfer
5.6.1 Introduction
For service continuity of a stateful application service, it is necessary to import the user context from the source
application instance into the target application instance in the target MEC host. The user context includes user specific
runtime data. The user context can be associated with a specific user or a group of users.
As specified in clause 5.1, there are three high level implementation approaches for user context transfer where the
MEC system is the decision maker and selects appropriate MEC application instance:
1) Device application assisted state transfer
2) MEC assisted state transfer
3) Application self-controlled state transfer
The user context transfer is dependent on the capabilities of the application itself and of the underlying operating system
of the MEC host. Both of these aspects are outside the scope of MEC specifications.
5.6.2 Application self-controlled user context transfer
The application self-controlled user context tran
...