ETSI GR MEC 018 V1.1.1 (2017-10)

Mobile Edge Computing (MEC); End to End Mobility Aspects

DGR/MEC-0018E2EMobility

General Information

• Status: Published
• Publication Date: 17-Oct-2017
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 25-Oct-2017
• Completion Date: 18-Oct-2017

Standards Content (Sample)

ETSI GR MEC 018 V1.1.1 (2017-10)






GROUP REPORT
Mobile Edge Computing (MEC);
End to End Mobility Aspects
Disclaimer
The present document has been produced and approved by the Mobile 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 018 V1.1.1 (2017-10)



Reference
DGR/MEC-0018E2EMobility
Keywords
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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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 2017.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GR MEC 018 V1.1.1 (2017-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 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 Mobility requirements and use cases . 7
4.1 Requirements and scenarios for mobility in ME system . 7
4.1.1 Requirements for mobility in ME system . 7
4.1.2 Mobility scenarios in ME system . 8
4.2 Use case for optimization of application state relocation . 9
4.3 Use case for prediction of relocation timing. 10
4.4 Use case for mission critical low latency application relocation . 11
4.5 Use case for service continuity with the UE moves in/out of ME host serving area . 12
4.6 Use case for initial or/and simple deployment . 13
4.7 GW based use case . 13
5 End to end information flows to support mobility . 14
5.1 An overview . 14
5.2 A flow for intra-ME host mobility . 16
5.3 A flow for inter-ME host mobility . 16
5.4 A flow for terminating an application instance . 17
5.4.1 Terminate a dedicated service produced by application instance . 17
5.4.2 Terminate a shared service produced by application instance . 18
5.4.3 Gaps identified by information flow . 20
5.4.3.1 App instance life cycle change/creation/deletion notification . 20
5.4.3.2 Shared application instance creation and deletion . 20
5.5 Evaluation of application instance relocation . 21
5.5.1 General . 21
5.5.2 Relocation notations . 21
5.5.3 High-level information flows for relocation procedure . 22
5.5.4 Overview for a specific relocation method . 22
5.5.5 Evaluation for a specific relocation method. 23
5.5.6 Gaps identified by information flow . 23
6 Key issues and potential solutions . 24
6.1 Introduction . 24
6.1.1 Roles and functions in service provisioning . 24
6.1.2 Problems and Assumptions . 25
6.1.3 Characterization of Service Continuity . 26
6.2 Key Issues . 27
6.2.1 Key Issue: The optimization of application state relocation . 27
6.2.1.1 Description . 27
6.2.1.2 Solution 1: MEH assisted state relocation without RNIS. 27
6.2.1.3 Solution 2: MEH assisted proactive state relocation for UE in connected mode . 28
6.2.1.4 Solution 3: UE assisted state relocation . 29
6.2.1.5 Solution 4: User plane optimization function . 30
6.2.1.6 Gaps identified by the key issue . 30
6.2.1.6.1 ME application relocation detection . 30
6.2.1.6.2 New function of user plane optimization function in MEPM . 31
6.2.2 Key Issue: UE IP address change . 31
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR MEC 018 V1.1.1 (2017-10)
6.2.2.1 Description . 31
6.2.2.2 Solution 1 . 31
6.2.2.3 Gaps identified by the key issue . 32
6.2.3 Key Issue: Updating downlink traffic rules . 32
6.2.3.1 Description . 32
6.2.3.2 Solution 1: Update bearer information between different RNIS within one host . 32
6.2.3.3 Solution 2: Update bearer information by RNIS within one host . 33
6.2.3.4 Solution 3: Update bearer information between different ME hosts . 34
6.2.3.5 Gaps identified by the key issue . 35
6.2.4 Key Issue: Updating forwarding path inter ME host . 35
6.2.4.1 Description . 35
6.2.4.2 Solution . 35
6.2.4.3 Gaps identified by the key issue . 35
6.2.5 Key Issue: Application instance relocation . 35
6.2.5.1 Description . 35
6.2.5.2 Solutions . 36
6.2.5.2.1 Assumption . 36
6.2.5.2.2 Solution for stateless application instance relocation . 36
6.2.5.2.3 Solution for stateful application instance relocation . 38
6.2.5.3 Gaps identified by the key issue . 40
6.2.5.3.1 ME application mobility service . 40
6.2.5.3.2 Enhancement of platform application enablement . 41
6.2.6 Key Issue: Update traffic routing rules . 41
6.2.6.1 Description . 41
6.2.6.2 Solution 1: update traffic routing rules triggered by RNIS . 41
6.2.6.3 Solution 2: update traffic routing rules triggered by UE UL Traffic . 43
6.2.6.4 Solution 3: update traffic routing rules triggered by Mobile Edge Orchestrator . 45
6.2.6.5 Gaps identified by the key issue . 46
6.2.7 Key Issue: Connectivity architecture . 47
6.2.7.1 Description . 47
6.2.7.2 Solutions . 48
6.2.8 Key Issue: Session and service continuity mode indication to network . 48
6.2.8.1 Description . 48
6.2.8.2 Solutions . 49
6.2.8.3 Gaps identified by the key issue . 49
6.2.9 Key Issue: Application relocations in case of ping-pong handovers . 49
6.2.9.1 Description . 49
6.2.9.2 Solutions . 49
7 Gap Analysis and Recommendations . 49
7.1 Gap analysis . 49
7.2 Recommendations . 51
History . 52


ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR MEC 018 V1.1.1 (2017-10)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document 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) Mobile 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 018 V1.1.1 (2017-10)
1 Scope
The present document focuses on mobility support provided by Mobile Edge Computing. It documents mobility use
cases and end to end information flows to support UE and Application mobility for Mobile Edge Computing. When
necessary, the present document describes new mobile edge services or interfaces, as well as changes to existing mobile
edge services or interfaces, data models, application rules and requirements. The present document identifies gaps to
support mobility that are not covered by existing WIs, documents these gaps and recommends the necessary normative
work to close these gaps.
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 GS MEC 001: "Mobile Edge Computing (MEC) Terminology".
[i.2] ETSI GS MEC 003: "Mobile Edge Computing (MEC); Framework and Reference Architecture".
[i.3] ETSI GS MEC 013: "Mobile Edge Computing (MEC); Location API".
[i.4] ETSI GS MEC 010-2: "Mobile Edge Computing (MEC); Mobile Edge Management;
Part 2: Application lifecycle, rules and requirements management".
[i.5] ETSI GS MEC 011: "Mobile Edge Computing (MEC); Mobile Edge Platform Application
Enablement".
[i.6] ETSI GS MEC 012: "Mobile Edge Computing (MEC); Radio Network Information API".
[i.7] ETSI GS MEC 002: "Mobile Edge Computing (MEC); Technical Requirements".
[i.8] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS MEC 001 [i.1] and the following
apply:
application instance: realized software program executed in mobile edge host, which can provide service to serve
consumer(s)
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR MEC 018 V1.1.1 (2017-10)
application instance relocation: procedure of moving an application instance running on a mobile edge host to another
mobile edge host, to support service continuity over underlying network
application instance state transfer: procedure of transferring the operational state of application instance from the
source mobile edge host to the instance of the same application in the target host
application mobility: part of mobility procedure for mobile edge system
NOTE: It relocates an application dedicated to a service consumer or shared by multiple service consumers from
one mobile edge host to another. Application mobility may include application instance relocation and/or
application instance state transfer from one mobile edge host to another.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.1] and the following apply:
App Application
CPN Connectivity Provider Network
DP Data Plane
GW Gateway
FFS For Further Study
MAMS ME Application Mobility Service
ME Mobile Edge
MEH Mobile Edge Host
MEO Mobile Edge Orchestrator
MEP Mobile Edge Platform
MEPM Mobile Edge Platform Manager
PDN Packet Data Network
RNIS Radio Network Information Service
S-DP Date Plane of Source MEH
S-MEH Source MEH
S-MEP MEP of Source MEH
T-DP Data Plane of Target MEH
T-MEH Target MEH
T-MEP MEP of Target MEH
UE User Equipment
VIM Virtualization Infrastructure Manager
VM Virtual Machine
4 Mobility requirements and use cases
4.1 Requirements and scenarios for mobility in ME system
4.1.1 Requirements for mobility in ME system
ME mobility is an important Mobile Edge Computing feature in a mobile environment, since UE mobility supported by
the underlying network can result in UE moving to a network entity associated with a different ME host from the
current serving ME host. ME system needs to support the following:
• continuity of the service;
• mobility of application (VM), i.e. relocation of application instance; and
• mobility of application-specific user-related information, i.e. transfer application instance state related to UE.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR MEC 018 V1.1.1 (2017-10)
To support ME service continuity, ME application mobility may involve multiple ME functional entities in order to
relocate application instances and transfer user and application-specific information within the ME system. Relocation
decisions may be based on UE mobility, customer profiles and/or ME infrastructure capability. The requirements
related to ME application mobility are listed as Mobility-01, 02, 03, Connectivity-01, 02, 03, 04, Routing-01, 02, 03, 04,
06, 10, 14, SmartReloc-01, 02, 03, 04,05, 06 in ETSI GS MEC 002 [i.7]. Table 4.1.1-1 summarizes the architecture
requirements related to ME mobility in ETSI GS MEC 003 [i.2].
Table 4.1.1-1: Requirements for ME mobility
Numbering Functional requirement description
Arch-01 The mobile edge system should support the mobility of application:
• as a consequence of UE moving within the ME system; or
• at a certain condition that requires to move the ME applications to different ME
host.
Arch-02 The mobile edge system should support the ME service continuity of UE as the
consequence of the application movement within the ME system, and support the
mobility of application-specific and user-related information.
Arch-03 The mobile edge system should support application mobility for ME applications not
sensitive to UE mobility.
See note 1.
Arch-04 The mobile edge system should support application mobility for the ME applications
sensitive to UE mobility:
• Maintaining connectivity between UE and mobile edge application instance.
• Application state relocation.
• Application instance relocation within the mobile edge system.
Arch-05 The mobile edge system should support:
• application instance or state relocation in MEC system.
• application instance relocation between the mobile edge system and/or an
external cloud environment.
See note 2.
NOTE 1: UE mobility means IP session mobility supported by underlying network.
NOTE 2: This requires FFS.

4.1.2 Mobility scenarios in ME system
Mobility in ME system is concerned with service continuity when the service to UE is relocated to another ME host
within the ME system. ME service relocation may be triggered by UE's bearer path change in underlying network, or
MEC system optimization to reduce service latency to UE, and procedure of relocation depends on:
• topology of ME host deployment in underlying network;
• scope (to be defined below) of application instances being served to UE(s); and
• aspects of applications.
Scenario 1:
A UE moves in underlying network, but is still in the coverage of serving ME host, i.e. intra ME host mobility. In this
scenario, the ME system does not need to relocate service (i.e. application instance being served to UE, and/or UE
context) to keep service continuity.
Scenario 2:
A UE moves out of coverage area of source ME host to the coverage area of another ME host (target), i.e. inter ME host
mobility. This scenario may result in interrupt of service to the UE. In order to provide service continuity to UE, the ME
system needs to relocate the service to UE from source ME host to target ME host.
Relocation of service to UE may need to further consider application scope:
• Dedicated application: An ME application instance is dedicated to serving a specific UE. When the UE moves
to another entity of underlying network which is associated to different ME host from the serving ME host, the
ME application instance being served to the UE should be relocated to the new ME host from the current
serving ME host.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GR MEC 018 V1.1.1 (2017-10)
• Shared application: An ME application instance at the serving ME host may not be dedicated to serving a
specific UE. Instead, it may serve multiple UEs (such as multi-cast), or all UEs associated with the ME host
(broadcast). When a UE moves to another entity of underlying network which is associated to a different ME
host from the serving ME host, the ME application may not need to be instantiated at the target ME host, but
require transfer the UE context to the application instance if it has been instantiated at the target ME host
already. For example, a broadcast service may be provided by the shared application instance. When a UE
subscribing to the broadcast service at the serving ME host moves to a new location in the underlying network,
UE context related to the broadcast service is transferred from the serving ME host to the broadcast service at
the new ME host so that the UE can continue being served by the broadcast service at the new location of
underlying network. As the application instance at the source ME host may still be required to serve other
UEs, the application instance at the source ME host is not torn down after the UE is served at the target ME
host.
In addition, ME mobility also needs to consider aspects of the application instance being served to a UE:
• Stateless: A stateless application is an application that does not memorize the service state or recorded data
about UE for use in the next service session; or
• Stateful: A stateful application is an application that can record the information about service state during a
session change. The state information may be stored in the UE app or ME app instance in the serving ME host,
which can be used to facilitate service continuity during the session transition.
ME mobility for stateless application does not require transferring UE state information to the application instance at
target ME host, while ME mobility for stateful application does need to transfer UE context to support service
continuity to UE.
Table 4.1.2-1 summarizes relocation of application instance and state information involved in different service mobility,
application scopes and aspects.
Table 4.1.2-1: Application instance relocation and UE state informat
...