ETSI GR MEC 022 V2.1.1 (2018-09)

Multi-access Edge Computing (MEC); Study on MEC Support for V2X Use Cases

DGR/MEC-0022V2X.Support

General Information

• Status: Published
• Publication Date: 03-Sep-2018
• Technical Committee: MEC - Multi-access Edge Computing
• Current Stage: 12 - Completion
• Due Date: 20-Sep-2018
• Completion Date: 04-Sep-2018

Standards Content (Sample)

ETSI GR MEC 022 V2.1.1 (2018-09)






GROUP REPORT
Multi-access Edge Computing (MEC);
Study on MEC Support for V2X Use Cases
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.

---------------------- Page: 1 ----------------------
2 ETSI GR MEC 022 V2.1.1 (2018-09)



Reference
DGR/MEC-0022V2X.Support
Keywords
MEC, V2X

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 2018.
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 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 022 V2.1.1 (2018-09)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Overview . 6
5 Use cases . 6
5.1 Introduction . 6
5.2 V2X use case group "safety" . 7
5.2.1 Description . 7
5.2.2 Recommendations . 7
5.2.3 Evaluation . 8
5.3 V2X use case group "convenience" . 8
5.3.1 Description . 8
5.3.2 Recommendations . 8
5.3.3 Evaluation . 9
5.4 V2X use case group "advanced driving assistance" . 9
5.4.1 Description . 9
5.4.2 Recommendations . 9
5.4.3 Evaluation . 10
5.5 V2X use case group "vulnerable road user" . 10
5.5.1 Description . 10
5.5.2 Recommendations . 10
5.5.3 Evaluation . 11
6 Key issues and solutions. 11
6.1 Key issue 1: mobility and QoE support . 11
6.1.1 Introduction. 11
6.1.2 Solution 1-1: predictive QoS support . 12
6.1.2.1 Description . 12
6.1.2.2 Gap analysis . 13
6.2 Key issue 2: low latency communication support with multi-operator operation . 13
6.2.1 Introduction. 13
6.2.2 Solution 2-1: shared underlying network . 14
6.2.2.1 Description . 14
6.2.2.2 Gap analysis . 14
6.2.3 Solution 2-2: independent underlying network . 15
6.2.3.1 Description . 15
6.2.3.2 Gap analysis . 15
6.3 Key issue 3: communication traffic coordination with vehicles . 16
6.3.1 Introduction. 16
6.3.2 Solution 3-1: inform communication traffic congestion to vehicles . 16
6.3.2.1 Description . 16
6.3.2.2 Gap analysis . 17
7 Conclusion and Recommendations . 17
7.1 Prioritized V2X use cases . 17
7.2 Consolidated recommendations . 17
7.3 Recommendations for future work . 18
History . 19
ETSI

---------------------- Page: 3 ----------------------
4 ETSI GR MEC 022 V2.1.1 (2018-09)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing
(MEC).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GR MEC 022 V2.1.1 (2018-09)
1 Scope
The present document focuses on identifying the MEC features to support V2X applications. It collects and analyses the
relevant V2X use cases (including the findings from external organizations), evaluates the gaps from the defined MEC
features and functions, and identifies the new requirements including new features and functions. When necessary, this
may include identifying new multi-access edge services or interfaces, as well as changes to existing MEC services or
interfaces, data models, application rules and requirements. It will also recommend the necessary normative work to
close these gaps if identified.
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] National Highway Traffic Safety Administration (NHTSA) / Department of Transportation (DOT),
"Federal Motor Vehicle Safety Standards; V2V Communications".
NOTE: Available at: https://www.gpo.gov/fdsys/granule/FR-2017-01-12/2016-31059
[i.2] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Definitions".
[i.3] 3GPP TR 22.885: "Study on LTE support for Vehicle to Everything (V2X) services".
[i.4] ETSI GS MEC 012: "Mobile Edge Computing (MEC); Radio Network Information API".
[i.5] ETSI GS MEC 013: "Mobile Edge Computing (MEC); Location API".
[i.6] ETSI GR MEC 018: "Mobile Edge Computing (MEC); End to End Mobility Aspects".
[i.7] 5G Automotive Association (5GAA) White Paper: "Toward fully connected vehicles: Edge
computing for advanced automotive communications".
NOTE: Available at http://5gaa.org/wp-content/uploads/2017/12/5GAA_T-170219-whitepaper-
EdgeComputing_5GAA.pdf.
[i.8] ETSI GS MEC 001: "Multi-access Edge Computing (MEC); Terminology".
[i.9] ETSI GS MEC 002: "Multi-access Edge Computing (MEC); Phase 2: Use Cases and
Requirements".
[i.10] ETSI TS 123 285: "Universal Mobile Telecommunications System (UMTS); LTE; Architecture
enhancements for V2X services (3GPP TS 23.285)".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GR MEC 022 V2.1.1 (2018-09)
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.8].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS MEC 001 [i.8] and the following apply:
5G Fifth Generation
API Application Programming Interface
IMA Intersection Movement Assist
LS Location Service
MNO Mobile Network Operator
OEM Original Equipment Manufacturer
OSS Operational Support System
PER Packet Error Rate
PLMN Public Land Mobile Network
QoE Quality of Experience
QoS Quality of Service
QW Queue Warning
RAB Radio Access Bearer
RAN Radio Access Network
RAT Radio Access Technology
RNI Radio Network Information
RNIS Radio Network Information Service
TNL Transport Network Layer
V2I Vehicle-to-Infrastructure
V2V Vehicle-to-Vehicle
V2X Vehicle-to-Everything
VRU Vulnerable Road User
WLAN Wireless Local Area Network
4 Overview
The present document identifies the MEC features in order to enable the necessary support for V2X applications.
Clause 5 collects and analyses the relevant V2X use cases (including the findings from external organizations). The
recommendations on the services and features are identified for each use case. Evaluation is provided for each
recommendation to identify the issues to be solved.
Clause 6 discusses the key issues and the corresponding solutions and further identifies the gaps from the existing MEC
functions and features.
Clause 7 concludes the study with the prioritized V2X use cases to be supported in this phase, and the consolidated
recommendations. The recommendations for necessary normative work are provided in order to close the identified
gaps.
5 Use cases
5.1 Introduction
This clause discusses four use case groups that are commonly known to the V2X communities [i.7], namely "safety",
"convenience", "advanced driving assistance" and "vulnerable road user".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GR MEC 022 V2.1.1 (2018-09)
5.2 V2X use case group "safety"
5.2.1 Description
The V2X use case group "Safety" includes several different types of use cases (relevant to MEC) to support road safety
using the vehicle-to-infrastructure (V2I) communication in addition to the vehicle-to-vehicle (V2V).
Intersection Movement Assist (IMA)
This type of use cases was specifically listed in the US DOT NHTSA publication 2016-0126 [i.1], and
ETSI TR 102 638 [i.2]. The main purpose of IMA is to warn drivers of vehicles approaching from a lateral direction at
an intersection. IMA is designed to avoid intersection crossing crashes, the most severe crashes based on the fatality
counts. Intersection crashes include intersection, intersection-related, driveway/alley, and driveway access related
crashes. Figure 5.2.1-1 illustrates two typical scenarios:
a) intersection collision warning, and
b) intersection management.

       a) intersection collision warning                         b) intersection management

Figure 5.2.1-1: V2X "safety" use cases
Queue Warning (QW) [i.3]
In a lot of situations, a queue of vehicles on the road may pose a potential danger and cause delay of traffic, e.g. when a
turning queue extends to other lanes. Using the V2I service, the queue information can be made available to other
drivers beforehand. This minimizes the likelihood of crashes and allows for mitigation actions.
5.2.2 Recommendations
This group of V2X use cases requires the support of roadside infrastructure for the V2V and V2I communications. In
the case that the Multi-access Edge Computing system is used to provide the V2X support, the related recommendations
on the services and features enabled in the system include:
[R-5.2.2-1] It is recommended that the MEC system provides feedback information from the network to the vehicle in
support of V2X functions, predicting whether a communication channel is currently reliable or not (e.g. in terms of
fulfilling latency requirements and 100 % packet arrival).
[R-5.2.2-2] It is recommended that the MEC system provides interoperability by supporting V2X information exchange
among road users connected through different access technologies or networks or mobile operators.
[R-5.2.2-3] It is recommended that the MEC system enables multi-operator operation for V2X mobiles/users to provide
service continuity across access network coverage nationwide and across borders of different operators' networks.
[R-5.2.2-4] It is recommended that the MEC systems provide interoperability in a multi-operator scenario, enabling
MEC apps in different systems to communicate securely with each other, in order to enable synchronization in multi-
TM
operator systems also in absence of cellular coverage (outside of 3GPP domain).
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GR MEC 022 V2.1.1 (2018-09)
[R-5.2.2-5] It is recommended that the MEC system provides interoperability in a multi-operator scenario, enabling
TM
MEC apps to communicate securely with the V2X-related 3GPP core network logical functions (e.g. V2X control
TM
function) and gathering PC5 [i.10] V2X relevant information (e.g. PC5 configuration parameters) from 3GPP
network.
5.2.3 Evaluation
[R-5.2.2-1] In current MEC system, the RNI API can provide up-to-date radio network information to the service
consumer, i.e. the V2X functions. However, current QoS-related information in RNI API is not sufficient in order to
allow necessary prediction regarding the QoS performance (e.g. latency, throughput, reliability). Therefore, potential
enhancements on RNI API for the prediction should be considered including both relevant measurements in RAN or
processed results for the prediction. This enhanced service could also be provided by a new API.
TM TM
[R-5.2.2-2] In current MEC definition, MEC system includes not only 3GPP access, but also other non-3GPP
access. Therefore the MEC system is RAT agnostic and will be enhanced for multi-access if needed. There is no need to
consider the different access networks within an operator's system in this study. Moreover, the information exchange
among MEC system from different operators may require potential enhancement on the horizontal communication for
the MEC system.
[R-5.2.2-3] The operator network is normally region specific or country specific. The V2X service requires a seamless
coverage of the communication, and unified service regardless the subscription of the users. In previous experience,
network sharing and roaming agreement could help to achieve this. However, each of them have its own limitations,
which may not meet the requirements. Normally the MEC system could be shared by operators, but the interaction with
the underlying networks from different operators may need more efforts in business coordination rather than technical
obstacles. It is also possible that the MEC system could also be operator-specific, thus the horizontal communication
enhancements among different operators may be considered to provide a sort of "MEC platform as a service" paradigm.
[R-5.2.2-4] The MEC system can be a preferred environment for hosting V2X application server functions in charge of
the authorization for the usage of V2X services. Thus, in order to ensure alignment across different operators' domains
(also in absence of cellular coverage), the MEC system hosts V2X application functions (with at least one MEC Host
for each operator domain hosting such functions). In order to ensure interoperability, the MEC apps should
TM TM
communicate securely with 3GPP core network in order to gather relevant information from 3GPP network (i.e.
the list of authorized UEs, the relevant information about the authorization based on the UE subscription and the
relevant PC5 configuration parameters).
5.3 V2X use case group "convenience"
5.3.1 Description
Software updates and other telematics use cases are typically included in this group, which can technically be
implemented with existing access technology and are partly already supported by car manufacturers.
5.3.2 Recommendations
This group of V2X use cases requires cost effective communication to be enabled between the vehicles and the backend
server (e.g. car OEM's server). In the case that the Multi-access Edge Computing system is used, the related
recommendations on the services and features enabled in the system include:
[R-5.3.2-1] It is recommended that the MEC system enables multi-operator operation for V2X mobiles/users to provide
service continuity across access network coverage nationwide and across borders of different operators' networks.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GR MEC 022 V2.1.1 (2018-09)
5.3.3 Evaluation
[R-5.3.2-1] The operator network is normally region specific or country specific. The V2X service requires a seamless
coverage of the communication, and unified service regardless the subscription of the users. In previous experience,
network sharing and roaming agreement could help to achieve this. However, each of them have its own limitations,
which may not meet the requirements. Normally the MEC system could be shared by operators, but the interaction with
the underlying networks from different operators may need more efforts in business coordination rather than technical
obstacles. It is also possible that the MEC system could also be operator-specific, thus the horizontal communication
enhancements among different operators may be considered to provide a sort of "MEC platform as a service" paradigm.
5.4 V2X use case group "advanced driving assistance"
5.4.1 Description
Advanced driving assistance represented by the two use cases (related to MEC) collects the most challenging
requirements for V2X. It can require distribution of a relative large amount of data with high reliability and low latency
in parallel. Additionally, the advanced driving use cases would benefit from predictive reliability. This means that
vehicles moving along should have the possibility to receive a prediction of the network availability to plan ahead.
Real Time Situational Awareness & High Definition (Local) Maps
Real time situational awareness is essential for autonomous vehicles especially at critical road segments in cases of
changing road conditions (e.g. new traffic cone detected by another vehicle some time ago). In addition, the relevant
high definition local maps need to be made available via downloading from a backend server.
The use case for real time situational awareness and High Definition (Local) Maps should not only be seen as a case to
distribute information on relatively slow changing road conditions. The case should be extended to distribute and
aggregate locally available information in real time to the traffic participants via road side units.
See-Through (or High Definition Sensor Sharing)
In this type of use cases vehicles such as trucks, minivans, cars in platoons are required to share camera images of road
conditions ahead of them to vehicles behind them.
5.4.2 Recommendations
In the case that the Multi-access Edge Computing system is used, the related recommendations on the services and
features enabled in the system include:
[R-5.4.2-1] It is recommended that the MEC system enables the support for locally aggregating the real-time
information from the connected nodes with very low latency.
[R-5.4.2-2] It is recommended that the MEC system enables the support for locally distributing the real-time
information to the connected nodes with very low latency.
NOTE: Examples of connected nodes are base stations in a mobile network or access points in a WLAN, which
are connected to the MEC system.
[R-5.4.2-3] It is recommended that the MEC system provides predictive quality related information to the vehicle when
the various connectivity parameters (like Latency, PER, signal-strength …) are going to change.
[R-5.4.2-4] It is recommended that the MEC system provides interoperability by supporting V2X information exchange
among road users connected through different access technologies or networks or mobile operators.
[R-5.4.2-5] It is recommended that the MEC system enables multi-operator operation for V2X mobiles/users to provide
service continuity across access network coverage nationwide and across borders of different operators' networks.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GR MEC 022 V2.1.1 (2018-09)
5.4.3 Evaluation
[R-5.4.2-1] The MEC system is supposed to serve only local area, which is several connected nodes in the underlying
network. To serve several connected nodes, the MEC system should be deployed in an aggregating position. There is no
extra standard work needed to specify the information aggregation.
[R-5.4.2-2] The MEC system is supposed to serve only local area, which is several connected nodes in the underlying
network. To serve several connected nodes, the MEC system should be deployed in an aggregating position. There is no
extra standard work needed to specify the information distribution.
[R-5.4.2-3] In current MEC system, the RNI API can provide up to date radio network information. The various
connectivity parameter including PER, signal-strength are not in the list of the RNI API. The parameters are rather
timely changed, may not be useful considering other network information including the network topology, policy and
even the scheduler algorithm, etc. Therefore, this service could also be provided by a new API designed to expose
appropriately pre-processed information for applications' consumption, but may not be useful for the end user if there is
no much detailed radio network running information. The extra processing o
...