ETSI GS MEC 021 V2.2.1 (2022-02)

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

RGS/MEC-0021V221AppMobility

General Information

• Status: Not Published
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 05-Feb-2022
• Completion Date: 11-Feb-2022

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.2.1 (2022-02)

Reference
RGS/MEC-0021V221AppMobility
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 - 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:
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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2022.
All rights reserved.
ETSI
3 ETSI GS MEC 021 V2.2.1 (2022-02)
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 . 8
4.1 Introduction . 8
4.2 Functional requirements . 9
5 Description of the services (informative) . 9
5.1 Introduction . 9
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 from 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
6.9 Query adjacent application instance information from Application Mobility Service . 19
7 Data Models . 20
7.1 Introduction . 20
7.2 Registration data types . 20
7.2.1 Introduction. 20
7.2.2 Type: RegistrationInfo . 20
7.2.3 Type: AdjacentAppInstanceInfo . 21
7.3 Subscription data types . 21
7.3.1 Introduction. 21
7.3.2 Type: MobilityProcedureSubscription . 21
7.3.3 Type: AdjacentAppInfoSubscription . 22
7.3.4 Type: SubscriptionLinkList . 23
7.4 Notification data types . 23
ETSI
4 ETSI GS MEC 021 V2.2.1 (2022-02)
7.4.1 Introduction. 23
7.4.2 Type: MobilityProcedureNotification . 23
7.4.3 Type: AdjacentAppInfoNotification . 24
7.4.4 Type: ExpiryNotification . 24
7.4.5 Type: AppMobilityServiceLevel . 25
7.4.6 Type: TestNotification . 25
7.5 Referenced structured data types . 25
7.5.1 Introduction. 25
7.5.2 Type: CommunicationInterface . 25
7.5.3 Type: TimeStamp . 26
7.5.4 Type: LinkType . 26
7.5.5 Type: MECHostInformation . 26
7.5.6 Type: KeyValuePairs . 26
7.5.7 Type: WebsockNotifConfig . 26
8 API Definition . 27
8.1 Introduction . 27
8.2 Global definitions and resource structure . 27
8.3 Resource: application mobility services . 29
8.3.1 Description . 29
8.3.2 Resource definition . 29
8.3.3 Resource methods . 29
8.3.3.1 GET . 29
8.3.3.2 PUT . 30
8.3.3.3 PATCH . 30
8.3.3.4 POST . 30
8.3.3.5 DELETE . 31
8.4 Resource: individual application mobility service . 31
8.4.1 Description . 31
8.4.2 Resource definition . 32
8.4.3 Resource methods . 32
8.4.3.1 GET . 32
8.4.3.2 PUT . 33
8.4.3.3 PATCH . 34
8.4.3.4 POST . 34
8.4.3.5 DELETE . 34
8.5 Resource: deregister application mobility service task. 35
8.5.1 Description . 35
8.5.2 Resource definition . 35
8.5.3 Resource methods . 36
8.5.3.1 GET . 36
8.5.3.2 PUT . 36
8.5.3.3 PATCH . 36
8.5.3.4 POST . 36
8.5.3.5 DELETE . 37
8.6 Resource: subscriptions . 37
8.6.1 Description . 37
8.6.2 Resource definition . 37
8.6.3 Resource methods . 38
8.6.3.1 GET . 38
8.6.3.2 PUT . 38
8.6.3.3 PATCH . 38
8.6.3.4 POST . 39
8.6.3.5 DELETE . 40
8.7 Resource: individual subscription . 40
8.7.1 Description . 40
8.7.2 Resource definition . 40
8.7.3 Resource methods . 40
8.7.3.1 GET . 40
8.7.3.2 PUT . 41
8.7.3.3 PATCH . 43
8.7.3.4 POST . 43
ETSI
5 ETSI GS MEC 021 V2.2.1 (2022-02)
8.7.3.5 DELETE . 43
8.8 Resource: adjacent application instances . 44
8.8.1 Description . 44
8.8.2 Resource definition . 44
8.8.3 Resource methods . 44
8.8.3.1 GET . 44
8.8.3.2 PUT . 46
8.8.3.3 PATCH . 46
8.8.3.4 POST . 46
8.8.3.5 DELETE . 46
8.9 Resource: notification endpoint . 47
8.9.1 Description . 47
8.9.2 Resource definition . 47
8.9.3 Resource methods . 47
8.9.3.1 GET . 47
8.9.3.2 PUT . 47
8.9.3.3 PATCH . 47
8.9.3.4 POST . 47
8.9.3.5 DELETE . 48
Annex A (informative): Key concepts . 49
A.1 Application mobility. 49
A.1.1 Introduction . 49
A.1.2 Application availability in the target host . 50
A.1.3 User context transfer . 50
A.2 Mapping of permissions for RESTful API and resources . 50
History . 53

ETSI
6 ETSI GS MEC 021 V2.2.1 (2022-02)
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 021 V2.2.1 (2022-02)
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, patterns and
common aspects of 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.
[10] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://tools.ietf.org/html/rfc5246.
[11] IETF RFC 8446: "The Transport Layer Security (TLS) Protocol Version 1.3".
NOTE: Available at https://tools.ietf.org/html/rfc8446.
[12] IETF RFC 8259: "The JavaScript Object Notation (JSON) Data Interchange Format".
NOTE: Available at https://www.rfc-editor.org/info/rfc8259.
ETSI
8 ETSI GS MEC 021 V2.2.1 (2022-02)
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); Device application interface".
TM
[i.2] OpenAPI Specification.
NOTE: Available at https://github.com/OAI/OpenAPI-Specification.
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] apply.
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
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
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
9 ETSI GS MEC 021 V2.2.1 (2022-02)
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].

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.
ETSI
10 ETSI GS MEC 021 V2.2.1 (2022-02)
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.2.1 (2022-02)

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.2.1 (2022-02)

Figure 5.3-1: Application Mobility Service enablement and registration
The steps 1 to 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,
...