ETSI GS MEC 002 V1.1.1 (2016-03)

Mobile Edge Computing (MEC); Technical Requirements

DGS/MEC-002TechReq

General Information

• Status: Published
• Publication Date: 30-Mar-2016
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 05-Apr-2016
• Completion Date: 31-Mar-2016

Standards Content (Sample)

GROUP SPECIFICATION
Mobile Edge Computing (MEC);
Technical Requirements
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.

2 ETSI GS MEC 002 V1.1.1 (2016-03)

Reference
DGS/MEC-002TechReq
Keywords
MEC, requirements
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.

© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI GS MEC 002 V1.1.1 (2016-03)
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 . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Generic principles . 9
4.1 Introduction . 9
4.2 NFV alignment . 9
4.3 Mobility support . 9
4.4 Deployment independence . 9
4.5 Simple and controllable APIs . 10
4.6 Smart application location . 10
4.7 Representation of features . 10
5 Generic requirements . 11
5.1 Requirements on the framework . 11
5.2 Application lifecycle . 11
5.3 Applications environment . 11
5.4 Support of mobility . 12
6 Services requirements. 12
6.1 General . 12
6.2 Platform essential functionality . 12
6.2.1 Mobile edge services . 12
6.2.2 Connectivity . 13
6.2.3 Storage . 13
6.2.4 Traffic routing . 13
6.2.5 DNS support . 14
6.2.6 Timing . 14
6.3 Features . 15
6.3.1 Feature UserApps . 15
6.3.2 Feature SmartRelocation . 15
6.3.3 Feature RadioNetworkInformation . 16
6.3.4 Feature LocationService . 16
6.3.5 Feature BandwidthManager. 17
6.3.6 Feature UEIdentity . 17
7 Operation and management requirements . 17
8 Security, regulation, charging requirements . 17
Annex A (informative): Use cases . 18
A.1 Use case categorization . 18
A.2 Mobile video delivery optimization using throughput guidance for TCP . 19
A.2.1 Description . 19
A.2.2 Use of Mobile Edge Computing . 19
A.2.3 Related requirements . 19
A.3 Local content caching at the mobile edge . 20
A.3.1 Description . 20
A.3.2 Use of Mobile Edge Computing . 20
ETSI
4 ETSI GS MEC 002 V1.1.1 (2016-03)
A.3.3 Related requirements . 20
A.4 Security, safety, data analytics . 20
A.4.1 Description . 20
A.4.2 Use of Mobile Edge Computing . 21
A.4.3 Related requirements . 21
A.5 Augmented reality, assisted reality, virtual reality, cognitive assistance . 21
A.5.1 Description . 21
A.5.2 Use of Mobile Edge Computing . 22
A.5.3 Related requirements . 23
A.6 Gaming and low latency cloud applications . 23
A.6.1 Description . 23
A.6.2 Use of Mobile Edge Computing . 24
A.6.3 Related requirements . 24
A.7 Active device location tracking . 25
A.7.1 Description . 25
A.7.2 Use of Mobile Edge Computing . 25
A.7.3 Related requirements . 25
A.8 Application portability . 25
A.8.1 Description . 25
A.8.2 Use of Mobile Edge Computing . 25
A.8.3 Related requirements . 25
A.9 SLA management . 26
A.9.1 Description . 26
A.9.2 Related requirements . 26
A.10 MEC edge video orchestration . 26
A.10.1 Description . 26
A.10.2 Use of Mobile Edge Computing . 26
A.10.3 Related requirements . 26
A.11 Mobile backhaul optimization . 27
A.11.1 Description . 27
A.11.2 Use of Mobile Edge Computing . 27
A.11.3 Related requirements . 27
A.12 Direct interaction with Mobile edge application . 27
A.12.1 Description . 27
A.12.2 Use of Mobile Edge Computing . 28
A.12.3 Related requirements . 28
A.13 Traffic deduplication . 29
A.13.1 Description . 29
A.13.2 Use of Mobile Edge Computing . 29
A.13.3 Related requirements . 29
A.14 Vehicle-to-infrastructure communication . 29
A.14.1 Description . 29
A.14.2 Use of Mobile Edge Computing . 30
A.14.3 Related requirements . 30
A.15 Location-based service recommendation . 30
A.15.1 Description . 30
A.15.2 Use of Mobile Edge Computing . 31
A.15.3 Related requirements . 31
A.16 Bandwidth allocation manager for applications . 31
A.16.1 Description . 31
A.16.2 Use of Mobile Edge Computing . 31
A.16.3 Related requirements . 31
A.17 Mobile edge platform consuming information from operator trusted mobile edge application . 32
ETSI
5 ETSI GS MEC 002 V1.1.1 (2016-03)
A.17.1 Description . 32
A.17.2 Use of Mobile Edge Computing . 33
A.17.3 Related requirements . 33
A.18 Video caching, compression and analytics service chaining . 33
A.18.1 Description . 33
A.18.2 Use of Mobile Edge Computing . 33
A.18.3 Related requirements . 33
A.19 Radio access bearer monitoring . 34
A.19.1 Description . 34
A.19.2 Use of Mobile Edge Computing . 34
A.19.3 Related requirements . 34
A.20 Mobile edge host deployment in dense-network environment . 34
A.20.1 Description . 34
A.20.2 Use of Mobile Edge Computing . 34
A.20.3 Related requirements . 35
A.21 Radio network information generation in aggregation point . 35
A.21.1 Description . 35
A.21.2 Use of Mobile Edge Computing . 35
A.21.3 Related requirements . 35
A.22 Unified enterprise communications . 35
A.22.1 Description . 35
A.22.2 Use of Mobile Edge Computing . 36
A.22.3 Related requirements . 37
A.23 Application computation off-loading . 37
A.23.1 Description . 37
A.23.2 Value proposition . 37
A.23.3 Use of Mobile Edge Computing . 38
A.23.4 Related requirements . 38
Annex B (informative): Operator trusted mobile edge applications . 39
History . 40

ETSI
6 ETSI GS MEC 002 V1.1.1 (2016-03)
Intellectual Property Rights
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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Mobile 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 002 V1.1.1 (2016-03)
1 Scope
The present document specifies the requirements for Mobile Edge Computing with the aim of promoting
interoperability and deployments. It contains normative and informative parts.
The present document also contains an annex describing example use cases and their technical benefits, for the purpose
of deriving requirements.
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.
Not applicable.
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] Mobile-Edge Computing - Introductory Technical White Paper. Sept. 2014.
NOTE: Available at https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing_-
_Introductory_Technical_White_Paper_V1%2018-09-14.pdf.
[i.3] Flinck H. et al. (September 2015): "Mobile Throughput Guidance Inband Signaling Protocol,
Internet draft, Internet Engineering Task Force".
NOTE: Available at https://tools.ietf.org/html/draft-flinck-mobile-throughput-guidance-03 (Work in progress).
[i.4] ETSI GS NFV 002: "Network Functions Virtualisation (NFV); Architectural Framework".
[i.5] Byte Caching in Wireless Networks.
NOTE: Available at http://researcher.ibm.com/researcher/files/us-aruni/ByteCachingicdcs2012.pdf.
[i.6] A Protocol-Independent Technique for Eliminating Redundant Network Traffic.
NOTE: Available at https://djw.cs.washington.edu/papers/spring-sigcomm00.pdf.
ETSI
8 ETSI GS MEC 002 V1.1.1 (2016-03)
[i.7] Sprecher N. et al.: "Requirements and reference architecture for Mobile Throughput Guidance
Exposure, Internet draft, Internet Engineering Task Force", September 2015.
NOTE: Available at https://tools.ietf.org/html/draft-sprecher-mobile-tg-exposure-req-arch-02 (Work in progress).
[i.8] Small Cells Forum White Paper SCF081: "Enterprise unified communications services with small
cells".
NOTE: Available at http://www.scf.io/en/documents/081-
Enterprise_unified_communications_services_with_small_cells.php.
[i.9] IEEE 1588™: "IEEE Standard for a Precision Clock Synchronization Protocol for Networked
Measurement and Control Systems".
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] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.1] and the following apply:
API Application Programming Interface
BYO Bring Your Own
DSRC Digital Short-Range Communications
EAB Edge Accelerated Browser
GNSS Global Navigation Satellite System
GPRS General Packet Radio Service
GPS Global Positioning System
GTP GPRS Tunnelling Protocol
HTTP Hyper Text Transfer Protocol
IM Instant Messaging
LAN Local Area Network
NTP Network Time Protocol
PBX Private Branch Exchange
PTP Precision Time Protocol
QCI Quality Class Indicator
QoE Quality of Experience
RAT Radio Access Technology
SLA Service Level Agreement
SMS Short Message Service
SPID Subscriber Profile ID
TCP Transmission Control Protocol
TEID Tunnel Endpoint ID
VNF Virtualised Network Function
ETSI
9 ETSI GS MEC 002 V1.1.1 (2016-03)
4 Generic principles
4.1 Introduction
The following principles are important to understand in the context of Mobile Edge Computing.
4.2 NFV alignment
Mobile Edge Computing uses a virtualisation platform for running applications at the mobile network edge. Network
Functions Virtualisation (NFV) provides a virtualisation platform to network functions. The infrastructure that hosts
their respective applications or network functions is quite similar.
In order to allow operators to benefit as much as possible from their investment, it would be beneficial to reuse the
infrastructure and infrastructure management of NFV to the largest extent possible, by hosting both VNFs (Virtual
Network Functions) and mobile edge applications on the same or similar infrastructure. Subject to gap analysis, this
might require a number of enhancements (e.g. regarding the sharing of resources with NFV Management and
Orchestration, etc.).
4.3 Mobility support
Mobility is an essential functionality of 3GPP networks. Most devices connected to a 3GPP network are moving around
within the mobile network. Even fixed devices can "move", especially when located at cell edge, but also when
changing RATs, etc., or during exceptional events (e.g. power cut from a base station, etc.).
Some mobile edge applications are state-independent and do not need to keep state information related to the UEs they
are serving. For example, an application in the category "network performance and QoE improvements" will only
improve the performance of the UE traffic when the traffic goes through that mobile edge host. When the UE moves to
a different location covered by another mobile edge host, it will be the application hosted on that mobile edge host that
will take care of the UE after a brief transition period. Past interaction is not useful for the application.
Other mobile edge applications, notably in the category "consumer-oriented services", are specifically related to the
user activity. Either the whole application is specific to the user, or at least it needs to maintain some application-
specific user-related information that needs to be provided to the instance of that application running on another mobile
edge host.
As a consequence of UE mobility, the mobile edge system needs to support the following:
• continuity of the service;
• mobility of application (VM); and
• mobility of application-specific user-related information.
4.4 Deployment independence
For reasons of performance, costs, scalability, operator preferred deployments, etc., different deployment scenarios need
to be supported:
• deployment at the radio node;
• deployment at an aggregation point;
• deployment at the edge of the Core Network (e.g. in a distributed data centre, at a gateway);
• etc.
In order to fulfil all these deployment options, the framework of the MEC architecture needs to allow all these scenarios
and the requirements need to be able to address all these deployment options. Requirements that cannot be fulfilled for
all deployment options cannot be made mandatory, but might be conditional or optional.
ETSI
10 ETSI GS MEC 002 V1.1.1 (2016-03)
When a mobile edge platform is deployed on a host located in a cell aggregation site, mobile edge services running on
that platform might need to retrieve information from the radio node(s), for instance, to readout the traffic load and
resource block usage of a specific cell.
In order to prevent the illegal access from dishonest terminals and mobile edge application developers, authentication
and secure tunnel communication are necessary between the radio node(s) and the mobile edge service.
NOTE: The interface between the radio node(s) and the mobile edge service is not specified in Mobile Edge
Computing Group Specifications.
4.5 Simple and controllable APIs
In order to enable the development of a strong ecosystem for Mobile Edge Computing, it is very important to develop
APIs that are as simple as possible and are directly answering the needs of applications. To the extent this is possible,
Mobile Edge Computing specifications need to reuse existing APIs that fulfil the requirements.
In particular circumstances, operators might need to be able to control dynamically the access to certain APIs by a
mobile edge application. Examples include the mitigation of high load of a radio node or mobile edge host, or when the
information of a specific radio node or cell cannot be provided.
4.6 Smart application location
Mobile edge applications have a number of requirements, in terms of computing, storage and network resources. More
importantly, some applications might have requirements in terms of latency (including latency fairness), etc.
For a certain number of mobile edge applications, the conditions might evolve over time and require the mobile edge
system to change the location of the application, e.g. as the UEs are moving from cell to cell.
Also, different locations may have different "costs" (in terms of resource availability, etc.), and it might not be always
the best choice to run a mobile edge application at the "best" location (to the detriment of other applications).
For these reasons, mobile edge applications need to run "at the right place" at the right moment, and might have to
move when the conditions evolve. In order to support this, the mobile edge system needs to provide a system-wide
lifecycle management of applications.
4.7 Representation of features
The present document describes requirements towards the framework and architecture of Mobile Edge Computing.
In addition to the definition of requirements applicable to all deployments, this specification introduces the concept of
features in order to cater for the different needs of different deployments. A feature is defined as a group of related
requirements and is assigned a unique name.
Support for a feature can be mandatory, optional or conditional. Where feature level support is optional or conditional,
all other requirements (mandatory or optional) related to that feature are themselves dependent upon support for the
feature itself.
The following example illustrates an optional feature with a conditional mandatory and a conditional optional
requirement.
EXAMPLE: [Req-1] The Mobile edge system may support a feature called XYZ.
[Req-2] When the Mobile edge system supports the feature XYZ, the system shall…
[Req-3] When the Mobile edge system supports the feature XYZ, the system may…
The architectural framework needs to support mechanisms to identify whether a specific feature is supported. Such
information might need to be considered when executing certain tasks, such as the instantiation of an application.
ETSI
11 ETSI GS MEC 002 V1.1.1 (2016-03)
5 Generic requirements
5.1 Requirements on the framework
[Framework-01] The design of the mobile edge system should attempt to reuse the NFV virtualisation infrastructure and
its management functionality, as described in the NFV architecture framework in ETSI GS NFV 002 [i.4], possibly with
some enhancements. Concepts that have been developed or studied in NFV Group Specifications and that are needed
for Mobile Edge Computing should be reused whenever possible. This might require some enhancements specific to
Mobile Edge Computing.
[Framework-02] It shall be possible to enable the deployment of mobile edge applications on the same infrastructure as
ETSI NFV-based VNFs.
[Framework-03] It shall be possible to deploy the mobile edge platform on mobile edge hosts in various locations,
including radio nodes, aggregation points, gateways, and in a distributed data centre at the edge of the Core Network.
NOTE: Some requirements might not be fulfilled by certain deployment options.
5.2 Application lifecycle
[Lifecycle-01] The mobile edge host shall be available for the hosting of mobile edge applications.
[Lifecycle-02] The mobile edge management shall support the instantiation of an application on a mobile edge host
within the mobile edge system.
[Lifecycle-03] The mobile edge management shall support the instantiation of an application on a mobile edge host
when required by the operator. This may be in response to a request by an authorized third-party.
[Lifecycle-04] The mobile edge management shall support the termination of a running application when required by
the operator. This may be in response to a request by an authorized third-party.
[Lifecycle-05] The mobile edge management shall be able to identify which features and mobile edge services a mobile
edge application requires to run, and which additional features and mobile edge services it can use if available.
NOTE 1: This allows the mobile edge system to decide whether and on which mobile edge host to instantiate the
application.
[Lifecycle-06] The mobile edge management shall be able to identify which features and mobile edge services are
available on a particular mobile edge host.
NOTE 2: This allows the mobile edge management to decide whether a particular application can be instantiated on
that host.
5.3 Applications environment
The applications environment describes the security, packaging and run-time environment models for hosting mobile
edge applications on the mobile edge host.
[AppEnvironment-01] It shall be possible to deploy mobile edge applications on different mobile edge hosts in a
seamless manner, without a specific adaptation to the application.
[AppEnvironment-02] The mobile edge management shall be able to verify the authenticity of a mobile edge
application.
[AppEnvironment-03] The mobile edge management shall be able to verify the integrity of a mobile edge application
(integrity protection).
ETSI
12 ETSI GS MEC 002 V1.1.1 (2016-03)
5.4 Support of mobility
[Mobility-01] The mobile edge 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 mobile edge host.
[Mobility-02] The mobile edge 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 mobile edge host.
[Mobility-03] The mobile edge platform may use available radio network information to optimize the mobility
procedures required to support service continuity.
EXAMPLE: Using UE mobility information to optimize the handling of mobility events by the application (see
clause 6.2.2, Connectivity) and of application mobility (see clause 6.3.2, Feature
SmartRelocation).
6 Services requirements
6.1 General
The mobile edge platform on a mobile edge host provides a framework for delivering mobile edge services and
platform essential functionality to mobile edge applications running on the mobile edge host.
A mobile edge service is provided and consumed. Both the mobile edge platform itself and authorized mobile edge
applications can provide services. Similarly, both the mobile edge platform itself and authorized mobile edge
applications can consume services.
In some cases, and especially in a multi-vendor environment, the service can be provided concurrently by multiple
sources. This allows the platform or the applications consuming the service to receive all information required for
executing their tasks.
Many of the applications require accurate time information synchronized to the time domain of the operator or
application provider. Such applications require exact time of specific events occurrence for analytics information
collection and pre-processing, time tagging of the location information, synchronized time intervals for the SLA
throughput reports, platform performance monitoring for latency and response times and many others.
Since the platform is located in the synchronized environment required for the mobile network operation, accurate time
of day information can be delivered to the platform by the same means as it is provided to the mobile Base Stations.
Known techniques include usage of GNSS receivers, running IEEE 1588™ [i.9] PTP protocol, NTP protocol or a
combination of the above.
The mobile edge platform will have a means to acquire accurate Time of Day information and make this information
available to the hosted applications.
6.2 Platform essential functionality
6.2.1 Mobile edge services
[Services-01] The mobile edge platform shall have the capability to provide mobile edge services that can be consumed
by authorized mobile edge applications.
[Services-02] The mobile edge platform shall allow authorized mobile edge applications to provide services that can be
consumed by the platform or by authorized mobile edge applications running on the mobile edge host.
NOTE 1: Providing a service by an application to the mobile edge platform includes that the platform can receive
information from that application. This information can be used by the mobile edge platform to provide
other services.
[Services-03] The mobile edge platform shall provide functionality to allow authorized mobile edge applications to
communicate with mobile edge services provided by the platform.
[Services-04] The mobile edge platform shall allow authentication and authorization of providers and consumers of
mobile edge services.
ETSI
13 ETSI GS MEC 002 V1.1.1 (2016-03)
[Services-05] When necessary, the mobile edge system shall allow operators to dynamically control the access of
running mobile edge applications to certain services.
[Services-06] The mobile edge platform shall provide a secure environment for providing and consuming mobile edge
services when necessary.
NOTE 2: Specific services can require end-to-end mechanisms for security.
NOTE 3: A service can be provided concurrently by multiple sources. It depends on the actual service whether the
multiple sources are visible to the service consumers or are consolidated and presented as a single source.
This will be described as part of the service description.
[Services-07] The mobile edge platform shall allow mobile edge services to announce their availability. The platform
shall allow the discovery of available mobile edge services.
[Services-08] The mobile edge platform shall provide functio
...