deliverable d5.1 5g-carmen pilot plan · 2020. 9. 28. · 2 project details call h2020-ict-18-2018...

1

5G for Connected and Automated Road Mobility in the European UnioN

Deliverable D5.1 5G-CARMEN Pilot plan

2

Project Details

Call H2020-ICT-18-2018 Type of Action IA Project start date 01/11/2018 Duration 36 months GA No 825012

Deliverable Details

Deliverable WP: WP5 Deliverable Identifier: D5.1 Deliverable Title: 5G-CARMEN Pilot plan Editor(s): Michela Apruzzese (CNIT) Author(s): Mauro Dell’Amico (CNIT), Filippo Visintainer (CRF),

Ana Cantarero (BMW), Panagiotis Vlacheas, Andreas Georgakopoulos Vassilis Laskaridis, Orestis Zekai, Charis Kalavrytinos, Kostas Tsagkaris, Vera Stavroulaki, Panagiotis Demestichas (WINGS), Dimitri Marandin (CMA), Orestis Mavropoulos (CLS), Joachim Hillebrand (VIF), Gianfranco Burzio (DSEC), Zarrar Yousaf (NEC), Silvia Capato, Thomas Novak (SWARCO), Peter Utasi (QUALCOMM), Ilaria De Biasi (BRE), Juergen Knapp (NOKIA.,

Reviewer(s): Seilendria A. Hadiwardoyo (IMEC) Roberto Fantini (TIM), Marco Liebsch (NEC), Juergen Knapp (NOKIA), Filippo Visintainer (CRF), Seilendria Hadiwardoyo (IMEC), Andreas Haider-Aviet (DTAG).

Contractual Date of Delivery: 31/10/2019 Submission Date: 19/11/2019 Dissemination Level: PU

Disclaimer The information and views set out in this deliverable are those of the author(s) and do not

necessarily reflect the official opinion of the European Union. Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the

use which may be made of the information contained therein.

3

Table of Contents LIST OF ACRONYMS AND ABBREVIATIONS ............................................................................................................ 5 LIST OF FIGURES .............................................................................................................................................................. 6 LIST OF TABLES ................................................................................................................................................................ 6 EXECUTIVE SUMMARY .................................................................................................................................................. 7 1 INTRODUCTION ............................................................................................................................................................. 9 2 REVIEW OF THE RELEVANT PROJECTS FOR THE PILOTING ACTIVITY ................................................ 10

PROJECTS WITH RELEVANCE WITH 5G-CARMEN USE CASE TESTING AND EVALUATION ......................................... 10 OTHER RELEVANT INITIATIVES ................................................................................................................................... 13 LESSONS LEARNT ........................................................................................................................................................ 15

3 OVERALL METHODOLOGY USED IN USE CASE TESTING ............................................................................. 16 OBJECTIVES OF 5G-CARMEN USE CASES TESTING .................................................................................................... 16

Cooperative Manoeuvrings ................................................................................................................................ 16 Situation Awareness ............................................................................................................................................ 16 Video Streaming .................................................................................................................................................. 17 Green Driving ..................................................................................................................................................... 17

5G-CARMEN KPIS .................................................................................................................................................... 18 DRIVING TESTS ............................................................................................................................................................ 19 LAB TESTS ................................................................................................................................................................... 20 SIMULATION TESTS ..................................................................................................................................................... 21

4 DESIGN OF EXPERIMENTS ....................................................................................................................................... 22 COOPERATIVE MANOEUVRINGS: COOPERATIVE LANE MERGING ............................................................................... 22

Overview ............................................................................................................................................................. 22 Deployment ......................................................................................................................................................... 22 Cooperative Lane Merging Pilot Plan ............................................................................................................... 23

SITUATION AWARENESS ............................................................................................................................................. 27 Overview ............................................................................................................................................................. 27 Deployment ......................................................................................................................................................... 27 Situation awareness Pilot Plan ........................................................................................................................... 29

VIDEO STREAMING ..................................................................................................................................................... 36 Overview ............................................................................................................................................................. 36 Deployment ......................................................................................................................................................... 36 Video Streaming Pilot Plan ................................................................................................................................ 37

GREEN DRIVING .......................................................................................................................................................... 39 Overview ............................................................................................................................................................. 39 Deployment ......................................................................................................................................................... 39 Green Driving Pilot Plan .................................................................................................................................... 40

5 DATA COLLECTION METHODOLOGY .................................................................................................................. 42 VEHICLE DATA COLLECTION ....................................................................................................................................... 42 ROAD INFRASTRUCTURE DATA COLLECTION .............................................................................................................. 42 5G NETWORK DATA COLLECTION ............................................................................................................................... 43 COMMON LOGGING FORMAT ....................................................................................................................................... 43

6 VALIDATION METHODOLOGY ............................................................................................................................... 44 7 EXEMPTION PROCEDURES AND SAFETY ISSUES ............................................................................................. 46

ANALYSIS OF THE CURRENT CCAM POLICIES AND REGULATIONS AT EUROPEAN AND MEMBER STATE LEVEL ......... 46 Italian pilot site ................................................................................................................................................... 46 German pilot site ................................................................................................................................................ 48 Austrian pilot site ................................................................................................................................................ 50

4

8 ACKNOWLEDGMENTS ............................................................................................................................................... 52 REFERENCES ................................................................................................................................................................... 53

5

List of Acronyms and Abbreviations Term Description ADAS Advanced Driving Assistance System AMQP Advanced Message Queuing Protocol API Application Program Interface BSAF Back situation Awareness Function C2X Car to Everything CAD Connected and Automated Driving CCAM Cooperative Connected and Automated Mobility C-ITS Cooperative Intelligent Transport Systems C-V2X Cellular Vehicle to Everything emV emergency Vehicle EPC Evolved Packet Core ETA Estimated time of Arrival ETSI European Telecommunications Standards Institute ETSI ITS G5 Peer-to-peer Communication Standard based on IEEE802.11p FOT Field Operational Test gNodeB 5G Base station HMI Human Machine Interface IMM Identity Management Module IoT Internet of Things KPI Key Performance Indicators LTE Long Term Evolution MANO Management and Orchestration MEC Multi-access Edge Computing MNO Mobile Network Operator NS3 Simulation Tool Used in Telecommunications NSA Non-standalone OBU On Board Unit OEM Original Equipment Manufacturer PC5 Peer-to-peer Communication standard interface in LTE-V2X/5G PLMN Public Land Mobile Network PPP Public-Private Partnership RAN Radio Access Network RNIS Radio Network Information Service SAE Society of Automotive Engineers V2N Vehicle to Network VNFs Virtual Network Functions VS Video Streaming VSSS Vehicle Sensors and State Sharing WP Work Package

6

List of Figures Figure 1 5G-CARMEN Pilots ............................................................................................................................... 9 Figure 2 FESTA "V" Diagram ............................................................................................................................ 14 Figure 3 Lab Trials set-up ................................................................................................................................... 20 Figure 4 Cooperative Lane Merging overview ................................................................................................... 22 Figure 5 Cooperative Lane Merging use case deployment ................................................................................. 23 Figure 6 Cooperative Lane Merging: communication between the MECs ........................................................ 25 Figure 7 Cooperative Lane Merging use case testing areas ................................................................................ 27 Figure 8 Situation Awareness use case overview ............................................................................................... 27 Figure 9 Back Situation Awareness sub-use case deployment (AT-DE border example) ................................. 28 Figure 10 Vehicle Sensor and State Sharing Awareness sub-use case deployment ........................................... 29 Figure 11 Situation Awareness use case vehicle schema (note: vehicle model is not indicative) ..................... 30 Figure 12 DSEC wearable solution for security credential, applicable to emergency vehicle drivers ............... 33 Figure 13 Back situation Awareness use case testing areas ............................................................................... 35 Figure 14 Vehicle Sensors and State Sharing use case testing areas .................................................................. 35 Figure 15 5G-CARMEN Video Streaming use case HMI overview .................................................................. 36 Figure 16 Video Streaming use case deployment ............................................................................................... 37 Figure 17 Video Streaming use case testing areas .............................................................................................. 38 Figure 18 Green Driving use case overview ....................................................................................................... 39 Figure 19 Green Driving use case deployment ................................................................................................... 40 Figure 20 Green Driving use case testing areas .................................................................................................. 41 Figure 21 5G System Layers .............................................................................................................................. 44

List of Tables Table 1 Linked Projects ...................................................................................................................................... 10 Table 2 Use cases target KPIs ............................................................................................................................. 18 Table 3 Use Cases core groups ........................................................................................................................... 19 Table 4 Data to be recorded (initial plan) ........................................................................................................... 43

D5.1 5G-CARMEN Pilot Plan

5G CARMEN (H2020-ICT-18-2018) Page 7 / 53

Executive Summary This deliverable illustrates the methodology used in piloting, the addressed KPI’s, the design of experiments and a detailed plan of the tests along the 5G-CARMEN Corridor Munich-Bologna, according to the Project Milestone MS28 “Detailed pilots test plan ready”. In addition, it includes the exemption procedures needed to test Connected and Automated Driving, as required for the Project Milestone MS27 “Preliminary security and exemption procedures plan ready”. 5G-CARMEN aims at achieving worldwide impact on future cooperative, connected and automated mobility by conducting extensive trials across a 5G-enabled corridor from Bologna to Munich, spanning 600 km of roads across three countries.

This document reports on the activities of tasks T5.1, which takes input mainly from T2.2 “Use case definition and requirements analysis”, from T4.4 “Use cases Integration and Testing” and from T3.6 “Services and applications for CCAM” and collaborate with T5.4 for exemption procedures and safety issues, to deliver a viable plan for T5.2 “Test execution” and T5.3 “Test validation and use case benchmarking”. The pilot plan set-up performed in T5.1 has required the following steps:

• Definition of technical KPIs; • Design and plan of the experimentations; • Define data and meta-data recording methodologies, procedures and management; • Design and plan of the subsequent evaluation.

5G-CARMEN pilot sites involve different areas of the highway connecting the cities of Bologna, Trento, Innsbruck, and Munich with the goal of creating a smart mobility space, encompassing all road networks. Pilots will involve automated vehicles in real scenarios, with an efficient cross-border handover of connectivity and services. Prototypes of connected and automated vehicles will be tested exhaustively in the target use cases. Cross-border testing is included to address service continuity and prove the concept of a 5G European corridor, serving road users across member states. The 5G-CARMEN experimentations will address WP2 target use cases in real life and simulated environments, in order to:

• Evaluate the performance and trade-offs of 5G and C-V2X enabling technologies developed in WP3

• Demonstrate how 5G connectivity can greatly expand the automotive services offer • Validate the use cases in different driving conditions, focusing on cross-border scenarios • Demonstrate complementarity of PC5 and the Uu interface • Evaluate how 5G contributes to fulfilling the requirements of autonomous driving, towards

highly automated driving The main structure of this deliverable can be summarized as follows:

• Chapter 1 introduces task T5.1; • Chapter 2 contains a review of projects and initiatives that are relevant for the 5G-CARMEN

testing phase and for the evaluation framework that will be adopted; • Chapter 3 contains an overview of the 5G-CARMEN evaluation framework, including the use

cases’ testing objectives, the KPIs that will be monitored and the methodology for testing, focused on real life piloting and supported by laboratory tests and simulations;

• Chapter 4 provides the actual plan of the 5G-CARMEN use cases’ tests, along with detailed storyboards;



• Chapter 5 gives an overview the data collection methodology, addressing both in-vehicle data and infrastructure data;

• Chapter 6 contains the evaluation methodology, to be followed when analysing collected data, laboratory and simulation results;

• Chapter 7 reports the exemption procedures needed to test Connected and Automated Driving along the 5G-CARMEN corridor.



1 Introduction The 5G CARMEN project objective is to address the cross-border aspects of 5G communication applied to connected cars and automated driving. Task T5.1 is dedicated to the pilot planning, and will evaluate, in real life conditions and supported by synthetic environments, the use cases of Cooperative Lane Merging, Situation Awareness, Green Driving and Video Streaming. For the real-life pilot trials, 5G-CARMEN has identified five locations along the Munich-Bologna corridor. The two cross-border pilots along the corridor are located near Kufstein (Germany-Austria) and at Brennero (Italy-Austria). These pilots are the focus of 5G-CARMEN and will show continuous service provision when passing from one country to another. In addition, three in-country “integration sites” will host integration work and collect data supporting the 5G-CARMEN evaluation: 1) the Munich pilot, near the BMW premises; 2) the Trento pilot, motivated by the presence of CRF-FCA, FBK and the A22 traffic management centre; 3) the Modena pilot due to the peculiar weather characteristics and the presence of CNIT.

Figure 1 5G-CARMEN Pilots

In the 5G-CARMEN pilots, cars will demonstrate driving use cases up to SAE Level 3 automation, supported by 5G connectivity. The impact of 5G towards higher levels of automation (Level 4 and beyond) will be derived from experimental data in the field and complemented by simulations. Level 4 Automation means the driver can be completely distracted from the driving task, no need to monitor what the vehicle is doing. This automation level is still forbidden on public road, and thus it will not be possible to demonstrate Level 4 Automated driving along the 5G Carmen corridor. Nevertheless, a manoeuvre like a lane merge is identical for both Level 3 and Level 4 automation. The impact of 5G to Level 4 is important to anticipate any possible problem that will require the intervention of the driver, in advance to give him/her enough time to take vehicle control (10-20 seconds).



2 Review of the relevant Projects for the piloting activity The 5G-CARMEN pilot planning requires, as a first step, a review of past and current linked projects and a literature review. This step is needed to provide an overview of the most relevant existing methodologies and guidelines for the evaluation of projects addressing 5G and/or Vehicle Automation.

Projects with relevance with 5G-CARMEN Use Case Testing and Evaluation The table below provides an overview of a selection of projects that are linked to 5G-CARMEN due to the nature of their implementations or for the evaluation methodology for some specific use cases.

Table 1 Linked Projects

Project acronym

Period

Main Focus

Relevance to 5G CARMEN use case testing plan

DRIVE C2X [1]

EU Seventh Framework Programme 01/2011 - 07/2014

To implement tests in seven national sites and creating a harmonized testing environment for C2X technologies.

The Back Situation Awareness use case in 5G-CARMEN is an evolution of the Emergency Vehicle use case that was tested in DRIVE C2X along the A22. 5G-CARMEN provides a range extension through cellular connectivity, and shows cross-border continuity of service.

AutoNet2030 [2]

EU Seventh Framework Programme 11/2013 - 10/2016

To develop and test a co-operative automated driving technology, based on a decentralized decision-making strategy which is enabled by mutual information sharing among nearby vehicles. The inter-vehicle co-operation is meant not only among automated vehicles but extends also to manually driven vehicles.

The technology developed in AutoNet2030 has been validated through drive-testing in test track and simulation tools. System tests have been performed at system level (use case definition), vehicle level (real life) and module level (simulation). AutoNet2030 results are relevant for 5G-CARMEN testing of the Cooperative Lane Merging use case, although they are based on different standards and on convoy-driving assumptions [3][4].

HIGHTS

EU HORIZON 2020 05/2015 - 04/2018

To produce advanced and highly accurate positioning technologies for C-ITS by combining traditional satellite systems with an on-board sensing and infrastructure-based wireless communication technologies

The set-up of 5G-CARMEN tests related to the Cooperative Lane Merging and of all the Situation Awareness use cases will consider the relevant HIGHTS use case requirements.



COHERENT [5]

EU HORIZON 2020 07/2015 - 03/2018

To research and develop a unified control and coordination framework for 5G heterogeneous radio access networks. It has implemented 6 types of use cases.

5G-CARMEN Cooperative Lane Merging and Video Streaming evaluation methodology will consider the comparison with the COHERENT KPIs [6].

BrennerLec [7]

EU LIFE 09/2016 - 04/2021

To create a "low-emission corridor along the Brennero motorway axis in order to achieve a clear environmental benefit in the fields of air protection, climate protection and noise pollution.

The BrennerLec experimentations are addressed to evaluate the system performance in terms of environmental and mobility KPIs [8]. The 5G-CARMEN tests of the Green Driving in the Italy-Austria pilot sites will consider evaluating similar KPIs in order to allow a comparison among the two projects results.

5G NetMobil [9]

German Federal Ministry of Education and Research 03/2017 - 02/2020

To develop a comprehensive communication infrastructure for tactile connected driving and to demonstrate the advantages of tactile connected driving in terms of traffic safety, traffic efficiency and environmental impact compared to autonomous driving based solely on local sensor data.

In 5G NetMobil, the validation of the developed solutions and concepts is planned by means of simulations, system modelling and demonstrations in real life scenarios. 5G-CARMEN testing of the Cooperative Lane Merging, Vehicle Sensors and State Sharing and Video Streaming use cases will be compared with results of the 5G NetMobil use cases in real life demonstrations.

C-ROADS [10]

EU Connecting Europe Facility 2017-2020

C-ROADS has developed a platform addressed to European Member States and road operators for testing and implementing V2X in light of cross-border harmonization and interoperability.

C-ROADS planned to pilot a set of C-ITS services in the 5G-CARMEN pilot sites areas. These “Day 1” C-ITS service pilots will contribute to the implementation of 5G-CARMEN Use Cases testing from the infrastructure side (C-ITS-S) and also be the reference basis for C-V2X applications on the vehicle, especially Vehicle Sensors and State Sharing.

AUTOPILOT [11]

EU HORIZON 2020 01/2017 - 12/2019

To exploit the automotive and the IoT value chains in order to develop IoT-architectures and platforms that will enhance automated driving.

The AUTOPILOT tests related to highway pilots are relevant for the 5G-CARMEN Vehicle Sensors and State Sharing use case tests. In addition, the data logging and data share methodology can be taken as input.



INFRAMIX [12]

EU HORIZON 2020 06/2017 - 05/2020

To design, upgrade, adapt and test both physical and digital elements of the road infrastructure, ensuring an uninterrupted, predictable, safe and efficient traffic.

INFRAMIX tests infrastructure technologies in Spanish and an Austrian test sites: results and outcomes of the implementations are related to the 5G-CARMEN Cooperative Lane Merging use cases.

5G-ESSENCE [13]

EU HORIZON 2020 06/2017 - 11/2019

Mobile Edge Cloud computing and Small Cell as a Service issues are addressed by developing a platform able to support new business models and revenue streams.

5G-CARMEN tests of Video Streaming implementations are related to the 5G-ESSENCE results, especially those related to the testing and demonstration of the 5G In-flight Communications and Entertainment System use case.

CLASS [14] EU HORIZON 2020 01/2018 - 12/2020

To develop a novel software architecture framework to help big data developers to efficiently distributing data analytics workloads along the compute continuum (from edge to cloud) in a complete and transparent way, while providing sound real-time guarantees.

Vehicle Sensors and State Sharing use case tests demonstrations results will be compared to CLASS demonstrations of autonomous driving in the Modena experimentations.

PRYSTINE [15]

EU HORIZON 2020 05/2018 - 04/2021

To realize Fail-operational Urban Surround perceptION (FUSION) which is based on robust Radar and LiDAR sensor fusion and control functions in order to enable safe automated driving in urban and rural environments.

Vehicle Sensors and State Sharing use case tests demonstrations results will be compared to the relevant PRYSTINE demonstrations.

ICT4CART [16] EU HORIZON 2020 09/2018 - 08/2021

To provide the ICT infrastructure to enable the transition towards road transport automation in four specific high-value use cases, which will be tested under real-life conditions at project sites in Austria, Germany, Italy and at the Italian-Austrian border.

ICT4CART cross-border testing, which mainly focusses on data exchange in the cloud, will be extended in 5G-CARMEN approach, which addresses the edge-computing aspects and the vehicle-network connectivity

5G-HEART [17]

EU HORIZON 2020 06/2019 - 05/2022

In the transport area, 5G-HEART will validate autonomous/ assisted/ remote driving and vehicle data services.

The transport trials are related to the 5G-CARMEN Vehicle Sensors and State Sharing use case tests.



Other relevant initiatives Several organizations committed to establish specific working groups aiming to develop guidance for the set-up and implementation of connected and automated driving pilots and in their consequent evaluation:

• In 2019, ERTRAC (European Road Transport Research Advisory Council) has updated the Roadmaps for Connected and Automated Driving;

• The 5G-PPP initiative has established a working group on Test, Measurement, and KPIs Validation that have developed guidelines and recommendations, for instance, the “Validating 5G Technology Performance” whitepaper (2019) and the Living document on 5G PPP use cases and performance evaluation models (started in 2016).

• The US Department of Transport has released a report in 2018 to describe a framework for establishing sample preliminary tests for Automated Driving Systems, with focus on light duty vehicles exhibiting higher levels of automation.

The most relevant initiative promoting the development of common frameworks for testing evaluating connected and automated driving have been developed firstly by the FESTA Project (2007-2008) and recently updated by the FOT-Net (Field Operational Test Networking and Methodology Promotion) and CARTRE (Coordination of Automated Road Transport Deployment for Europe) projects (2017). The FESTA methodology defines in detail the steps, the roles and the risks for the implementation of Field Operational Test (FOT).

According to the FESTA Handbook (2017), a Field Operational Test is defined as “a study undertaken to evaluate a function, or functions, under normal operating conditions in road traffic environments typically encountered by the participants using study design so as to identify real-world effects and benefits”. Typically, with the FESTA approach, the steps that need to be carried out during an FOT are presented in the form of a V diagram (Figure 2), where there is correspondence between the levels on the left-hand and right-hand sides. Additionally, the FOT implementation plan takes up all the steps and integrates them into a detailed table, which can be used as a reference when carrying out an FOT.



Figure 2 FESTA "V" Diagram

It is also worth considering the methodology suggested by the CONVERGE Project. CONVERGE was a supporting project providing the essential tools for the management, co-ordination and exploitation of the road, rail, air, waterborne and multi-modal activities of the Transport Telematics Applications Program. The project provided a co-ordination and expert support platform to exploit key synergy between projects in order to maximize the value, quality and range of Program achievements.

According to CONVERGE, “Assessment is the process of determining the performance and/or impacts of a candidate application, usually in comparison to a reference case (existing situation or alternative applications), and usually including an experimental process based on real-life or other trials, often involving users.” In this context, validation can be defined as the process of verifying that an application performs as expected, often based on assessment results. Within the project, two important documents have been provided in order to set-up guidelines for project evaluation and validation purposes: the “Guidebook for Assessment of Transport Telematics Applications” [18] and the “Checklist for Preparing a Validation Plan”. Whilst the guidebook is intended to give more general guidance and recommendations regarding the assessment or validation process, the updated checklist provides detailed advice on how to produce draft and final validation plans. The “Guidebook for Assessment of Transport Telematics Applications” defined seven key stages which constitute a generic assessment process; CONVERGE focused on telematics projects, but they can still be used as a role model for other types of projects assessment:

1. Definition of user needs 2. Describing the applications 3. Defining assessment objectives: Technical assessment (system performance, reliability);

Impact assessment (safety, environment, transport efficiency, user behaviour, modal split etc.);



User acceptance assessment (users' opinions, preferences, willingness to pay); Socio-economic evaluation (benefits and costs of system implementation); Market assessment (demand and supply); and Financial assessment (initial and running costs, rate of return, payback period).

4. Defining expected impacts: “Pre-assessment” 5. Assessment methodology: Selection and definition of indicators; Reference case; Data

collection (measurement and/or simulation); Measurement or simulation conditions; Statistical considerations/sampling; Defining the measurement plan; Integrity of measurement and/or simulation.

6. Data analysis 7. Reporting results

Relevance is given to the way projects contribute to create a “European added-value”: in fact, the real “customers” for the results of projects include both the direct participants and a broad audience of potential users, purchasers, manufacturers and operators. For them it is important to know how the various systems and applications perform, how much they cost to buy and to operate, and what impacts they might produce if implemented locally.

Lessons Learnt 5G-CARMEN overall piloting framework will rely on the FESTA methodology: this approach to implement Field Operational Test provides the main steps to prepare and plan pilots in CAD projects. In 5G-CARMEN, the “V” step approach defined in the FESTA Handbook is performed in different project work packages and tasks. For what concerns the specific preparation of the evaluation plan, 5G-CARMEN will also adopt some processes from the CONVERGE Project: the 5G-CARMEN use case testing approach will compare a baseline scenario with some “controlled” scenarios. The “Checklist for Preparing a Validation Plan” will also be taken as a base for the test case definition. However, the 5G-CARMEN project will not deal with large-scale users’ test.

Last, but not the least, 5G-CARMEN pilots’ set-up will deal with the experience of past and current projects that have developed systems, projects or technologies that are linked to our use cases. 5G-CARMEN will have a continuous link with the other European projects that are currently implementing experimentations involving both autonomous driving and 5G technologies: 5G-CARMEN goal is to adopt a methodological evaluation framework that will allow comparisons among project results. During the project duration, efforts will be made to liaise with the other 5G-PPP phase 3 funded projects in order to measure, when possible, same KPIs.



3 Overall methodology used in use case testing Deliverable 2.1 provides a detailed description of the use cases which 5G-CARMEN aims to implement, test and evaluate; these are:

• Cooperative Manoeuvrings • Situation Awareness • Video Streaming • Green Driving

In general, the plan to implement 5G-CARMEN tests implies defining, for each use case:

• Why we perform the test, i.e. the use case experimentation objectives and the related KPIs; • Who are the partners involved in the use case tests; • Where the use case is experimented, i.e. the exact location and the relation with other pilot

sites, considering that 5G-CARMEN emphasizes the tests implementation in cross-country areas;

• When the experimentation is planned to start, the expected duration of the experimentation, the planned number of experimentations repetitions needed;

• What is required for the test implementation, what is provided by the partners, what is missing; • How the experimentations will be actually carried on, i.e. all the practical details on how the

tests will be implemented, and how the KPIs will be measured.

The following sections will cover the first bullet point and will explain the objectives and the KPIs for the tests of the four 5G-CARMEN use cases.

Objectives of 5G-CARMEN use cases testing Cooperative Manoeuvrings

The 5G-CARMEN use case addressing Cooperative Manoeuvrings aims to coordinate the trajectories of a group of vehicles in close proximity, thus to share information produced locally by a vehicle, e.g., from radar, LIDAR, and on-board cameras, in a privacy-aware and secure fashion with other vehicles and to combine vehicles’ information with precise positioning and traffic information to provide the driver (or the autonomous driving system) with a more comprehensive view of the surrounding environment. This allows to improve the drivers’ comfort and safety and to improve driving behaviour (reducing emissions and fuel consumption due to avoidance of hard braking events and supporting the drivers’ decision-making process). In particular, the use case tests will analyse the Cooperative Lane Merging sub-use case that implies the coordination of two vehicles with the aim to provide a sufficiently large gap so that a third vehicle can merge into the lane in a safe and efficient manner.

The Cooperative Manoeuvrings tests objectives are:

• To enable and shape an ecosystem that allows safer and more efficient transportation • To showcase the benefits of different OEMs and MNOs cooperating in a cross-border scenario

in the context of cooperative manoeuvrings • Demonstrate how different communication links (PC5 and UU) complement each other, when used in

combination

Situation Awareness In 5G-CARMEN, the Situation Awareness use case considers two sub-use cases: “Back Situation Awareness” and “Vehicle Sensors and State Sharing”. Back Situation Awareness implies providing in-advance warning and information about the time of arrival of emergency vehicles and ensuring early warning of approaching emergency vehicles to only those vehicles which are on their route. Vehicle



Sensors and State Sharing implies making vehicles aware of external events (weather or traffic) receiving a direct communication from other vehicles or through a Cloud Service (possibly running on a MEC) which can merge information originating from different sources in the relevant area.

The objectives of all the sub-use cases are:

• To assess the 5G potential to enhance C-ITS, through a combination of the air interface between devices (vehicles), the RAN and side-link interfaces, targeting cross-border scenarios and dangerous spots/events

• To address efficient lane clearance and presence awareness for Emergency Vehicles (Back Situation Awareness)

• To advance information for ADAS and Automated Vehicles safe operation (Vehicle Sensors and State Sharing)

Video Streaming The Video Streaming use case will explore different network architectures and configurations, aiming to satisfy users’ Quality of Experience (QoE); it aims to test the prediction of the expected network Quality of Service (QoS) and the proactive adaptation of streaming applications in order to avoid interruptions in the service whenever possible, with the attempt of having the highest quality service always available, even in cross-country border situations and inter-operator scenarios. To implement it, the best mobile network options between LTE, 5G, C-V2X and other technologies are investigated in order to guarantee not only the data rate requirements but also the needed coverage at all times. The objectives of the Video Streaming use case tests are:

• To propose a technical solution which satisfies the vehicle users’ Quality of Experience (QoE) expectations

• To enable a high-quality streaming service in situations which are usually demanding, such as cross-country borders and inter-operator scenarios

Green Driving In 5G-CARMEN, the Green Driving use case involves two sub use cases: “Electric Vehicle Zones” and “Dynamic Speed Limit”. The overall intention is to monitor and improve the air quality in environmentally sensitive areas. Examples are valleys in the Alps with permanent heavy traffic and additional peaks during holiday seasons: due to the geographical location and special weather conditions (e.g. stationary temperature inversions), these areas are especially affected by air pollution. With the introduction of “Green Driving” modes these environmentally sensitive areas will be relieved due to responsible and environmentally friendly driving, resulting in an improved quality of life. An environmental analysis aims to influence the drivers’ behaviour by gathering environmental data to produce descriptive analytics showcasing the overall air quality situation and initializing prescriptive and predictive analytics facilitating the uptake of (further) actions towards the reduction of vehicle emissions. The Electric Vehicle Zones sub-use case addresses the ability of 5G-CARMEN to communicate with the vehicles on alerts to switch to electric driving mode (applicable to hybrid vehicles only) for a specific stretch along the route (i.e. environmentally sensitive areas specified as electric zones), on charging the battery and keeping sufficient power before entering an electric zone, and on selecting an alternative route with less environment-related restrictions if the adherence is not possible. The Dynamic Speed Limit sub-use case is meant to provide driving behaviour suggestions by collecting vehicle information and optimizing the speed profile to target environmental savings. The Green Driving tests have the following objectives:

• To exploit current 5G and C-V2X technologies for fast data collection from vehicles nearby, as well as via monitoring sensitive areas by Road Operators and Public Authorities



• To provide high-quality data streams via a hybrid Cloud/MEC infrastructure for traffic management and emission control purposes

• To demonstrate how green driving related advice and prescriptions can be distributed across the border via standardized workflows

5G-CARMEN KPIs In order to monitor and evaluate the impact of the 5G-CARMEN systems, a set of high-level criteria has been established and the specific target impact of each type of use case (and sub-use case) testing has been defined. The high-level evaluation criteria can be summarized as follows:

• Mobility, i.e. the ability of the system to provide connectivity dynamically • Coverage, i.e. the ability to cover urban, extra-urban and highway scenarios • Bandwidth, which should be flexible according to the scenario needs (i.e. up to 100 Mbit/s per

vehicle) • Latency, i.e. the capacity to minimize the roundtrip time, keeping it in the order of (tens of)

milliseconds • Resilience, i.e. the ability to maintain the operations in case of noise • Reliability, i.e. the ability to guarantee ultra-reliable communications for safety critical

applications • Security: in terms of protection of the vehicle systems’ and users’ data • Safety: in term of avoiding unacceptable risks for road users including vehicle occupants

According to this, before the tests’ implementations, 5G-CARMEN has clarified the specific target which the experimentations are expected to achieve, in terms of expected KPIs:

Table 2 Use cases target KPIs

Use case Use case target KPIs

Cooperative Manoeuvrings

(Cooperative Lane Merging) Agreed KPIs • packet sizes of up to 100 bytes for the request to merge, request ACK, and safe-to-

merge/denial messages • status updates take the regular CAM sizes of up to 588 bytes. • exchange delay requirement of less than 100ms from generation time to reception

time • accurate position information (within 1 m of the actual position) • 90% reliability requirement for the negotiation Other KPIs in discussion • PC5 communication range from 20 meters (traffic jam scenario with slowly moving

vehicles) to 1000 meters (highway without a speed limit) in line-of sight conditions • complete manoeuvre should take no longer than 5-6 seconds

Situation Awareness

(Back Situation Awareness; Vehicle Sensors and State Sharing) Agreed KPI • position accuracy

o information: 10-20 m o warning: 1-4 m

• relevance area (meters) o information: 800-2000 (Back Situation Awareness); 400-10000 (Vehicle

Sensors and State Sharing);



o warning: 0-800 (Back Situation Awareness,); 0-400 (Vehicle Sensors and State Sharing)

• situation update (seconds)/refresh rate (Hz) o in information relevance area: 1s/1Hz o warning: 0.1s/10Hz (at highest relative speed)

• 95-99% reliability

Other KPIs in discussion • predictive service interruption or discontinuity in advance at least 20s/700m to

guarantee safe stop in



Situation awareness UC Leader: CRF Deputy: SWARCO

Back-situation awareness of an emergency vehicle arrival

CRF, NEC, BMW, QCGER

Vehicle sensors and state sharing SWARCO, CNIT-UNIMORE, QCGER

Video Streaming UC Leader: BMW Deputy: DTAG

BMW, QCGER, DTAG

Green Driving UC Leader: WINGS Deputy : SWARCO

Electric vehicle zones BMW, SWARCO, WINGS

Dynamic speed limit BRE, SWARCO, WINGS, QCGER, CRF

In addition to these partners, telecom operators and network hardware/software providers need to ensure 5G deployments in specific locations of the corridor, as well as other enabling components, as reported in 5G-CARMEN deliverable D3.2.

Lab tests In order to explore and validate the use cases in the controlled environment before setting up pilots in the corridor, lab trials will be conducted. It is very important that that 5G-CARMEN use cases are tested and validated in the lab before the deployment for pilots can start. Lab trials aim to emulate the pilot scenarios as closely as possible, for example by using as many real hardware and software components suitable for pilots as possible, and thus validating the integration and interfaces of components coming partly from different project partners. Additionally, the lab trials will allow to test and validate 5G features which otherwise will be not possible to demonstrate in the pilot corridor e.g. due to business and security constraints, limitations in the initial 5G deployment or a limited number of vehicles available for pilots.

Figure 3 shows the features considered in the 5G-CARMEN lab trials setup:

• Two EPCs to replicate cross-border aspects in the pilot where two different operators are involved as each operator maintains the separate EPC with different PLMN configuration in pilots.

• Two base stations connected to different EPC, replicating the situation in the pilots where base stations close to the border connected to EPC of different operators. The base stations in the lab

Figure 3 Lab Trials set-up



trials can provide real-time radio network information to MEC applications, e.g. over the RNIS API, to enable cutting-edge MEC applications. In pilots, MEC application will rely on the QoS prediction Cloud API while RNIS may be not available in the initial 5G deployment. The base stations in the lab setup can be modified to provide parameters beyond RNIS depending on MEC application needs.

• Two MECs located at different operators connected for inter-MEC communication. • 5G NSA modems replicating modems located in the vehicles and being able to provide connection

to 5G NSA base stations • Test tool that generates V2X-messages and can log recommendations issued by MEC applications • MANO(s): MANO system, designed as part of the CCAM platform in WP4 which is shared across

different MNOs, network equipment providers and research institutes. The MANO system will manage and orchestrate the services and resources e.g. instantiating applications on the MEC platforms.

Thus, this setup will allow testing the whole chain of components produced by different partners in different WPs. It will be realized in distributed locations: RAN block, MEC, MANO can be hosted by different partners connected over the Internet. This replicates the real situation as these domains are typically in different geographical locations and need inter- and intradomain orchestration. The remote access will be organized based on the need, e.g. for uploading, configuring and starting new MEC applications, or to access and manage monitoring and test tools.

Simulation tests Although simulations are extensively treated in WP6, it is worth to highlight the objective and usefulness of this complementary assessment: Simulation can complete field trials in all aspects which cannot be tested in real life or are too risky or effort demanding to test, namely:

• Simulations can scale up use cases with several connected vehicles, to evaluate the overall network and system performance and effects on the driving experience. It can also take into account phase-in periods of mixed connected and non-connected vehicles, and also different technology enablers (which might not be available yet in the field) on different vehicle segments (premium, basic C-V2X).

• Simulations can forecast how the system will behave in relation to the planned 5G network evolution: while the corridor trial is limited by the actual technology availability (e.g. no 5G Core, no interfaces for a cross-border cross-operator network handover), different assumptions can be made for the future.

• Simulations can easily change the assumptions (set as boundary conditions) and evaluate the 5G-CARMEN use cases effectiveness accordingly. Simulations can address specific conditions which are safety critical and cannot be easily replicated in the actual corridor, for instance speed limits/prescriptions on the production infrastructure back-end (Variable Message Signs), real emergency situations, assured protection of live traffic participants etc.



4 Design of experiments This chapter aims to define the instructions for the implementation of the real-life experiments, in order to have a detailed plan of the use case tests that will start in October-November 2019 along different segments of the A22 highway. The design of the experiments is “use case focused” and not “pilot site focused”: the 5G-CARMEN project aims to implement solutions which have a cross-country relevance. For this reason, the tests planning phase has defined working groups composed by partners from the different pilot site areas, being each working group led by a “Use Case Leader”. The following sections provide the tests plan of each 5G-CARMEN use case.

Cooperative Manoeuvrings: Cooperative Lane Merging Overview

Figure 4 Cooperative Lane Merging overview

In a lane change due to a merging of lanes, the vehicle performing the lane change needs to ensure the availability of enough spatial gaps in the target lane. This gap can be facilitated by the vehicles independently following some rules overcoming the fact that sometimes individuals’ behaviour could lead to non-fluid traffic. Cooperative lane changing can help creating the needed gaps for a smoother transition. This can be achieved either in a localized or a centralized manner. The former involves direct exchanges between the vehicles, while the latter builds upon a MEC/back-end server and a cellular network, which support the vehicles’ systems in determining the optimal behaviour to either execute or pass on to the driver as a recommendation.

Deployment Figure 5 depicts the pilot deployment on Cooperative Lane Merging. A manoeuvrings service will run on each of the MNOs MEC platforms. These will have a logical interconnection at application level to achieve cross-border availability. The manoeuvrings service will send instructions to each of the vehicle`s manoeuvrings management application. On the Italian side, a localized approach is shown, with direct exchanges between the vehicles.



Figure 5 Cooperative Lane Merging use case deployment

Cooperative Lane Merging Pilot Plan

The tests will be executed for both localized and centralized approaches (D2.1 provides the description of the two cases). A localized approach refers to the direct communication and information exchange between two vehicles, while the centralized approach has a MEC/back-end service and a cellular network which receives the information from the involved vehicles and supports them in determining the optimal behaviour in this situation.

4.1.3.1 Localized Approach

Vehicles from both BMW and CRF will be equipped with a QCGER C-V2X on-board unit for PC5 short range communication. This interface allows the direct exchange of Cooperative Awareness Messages (CAM) which provide periodic status update messages on each vehicle`s current position, speed and on their respective lanes - all required for the manoeuvring decision. Additionally, a manoeuvre management application will be present in all vehicles involved. This will be the one in charge of processing all the input and determining the best action to take.

The idea is that the current status between all involved vehicles is known, and when one intends to merge into the lane of the other two, it signals its intention beforehand. This intention will be represented by the blinker status, which will also be contained in the CAM messages. Before performing the merging action, the vehicle has to wait for the acknowledgment that the necessary actions for safely creating a gap have been performed by the other two. The algorithm details which will run in the manoeuvre management application are currently being discussed and will be fine-tuned in the upcoming months; however, the plan is to have the vehicle in the front coordinating the whole manoeuvre. This will periodically collect CAM status updates from the other vehicles and send necessary instructions. Due to the simplicity of implementation, we will show the scenario where the vehicle on the rear receives the instruction from front vehicle´s manoeuvre management application to slow down in order to create the necessary gap for the third vehicle to merge (DENM:



LocationContainer à event Speed). For lower levels of automation, the slow down instruction will be shown directly to the driver via the vehicle`s Human Machine Interface (HMI). For higher levels of automation, the command will be sent directly to the vehicle`s ADAS system. After the rear vehicle has slowed down, the manoeuvre management application in charge will double check all vehicles´ current status and determine if it is safe for a merge to be performed.

As this approach is independent of the location since the network is not involved, there is flexibility as to where the testing will take place. The project decided to perform it at the Austrian-Italian (Brennero) border.

4.1.3.2 Centralized Approach

The centralized approach involves both BMW and CRF on the vehicle side. The mobile network infrastructure will be provided by DTAG on the German side, TMA on the Austrian side and TIM on the Italian side. A MEC platform provided by Nokia is placed in the DTAG and TIM networks (an external supplier is used for TMA), with a manoeuvre management application provided by BMW. This application will oversee computing the information provided by the vehicles involved in the manoeuvre and determining the optimal behaviour. This is then sent to the vehicles to either execute or pass on to the drivers as a recommendation, depending on their automation level.

In this scenario, the manoeuvre management application will receive periodical status updates in the form of CAM messages as input from each of the three vehicles. These messages will include information on their current position, speed and on their respective lanes. Additionally, the blinker status information will be provided within the CAM. The vehicle which intends to merge into the lane is expected to turn the blinker on. The manoeuvre management application interprets this information as an intention from this vehicle to merge, and in which direction. After all this information has been obtained, the application will calculate the distances between the vehicles, their expected speeds and directions. It will then provide a manoeuvre recommendation in order to allow enough space for the vehicle to merge into the lane. This recommendation could be for example an indication to the vehicle behind to slow down to a certain speed. When the space between the front and the rear vehicles is sufficient, the manoeuvre management application will indicate the third vehicle that it is allowed to merge. In case the space between vehicles is not sufficient, even after the rear one slowing down, the application will deny the request to merge. The communication from the application to the vehicles will be handled through Decentralized Environmental Notification Messages (DENM). Specifically, the instruction to slow down will be sent via the LocationContainer à eventSpeed field.

Testing will take place in both German-Austrian (Kufstein) and Austrian-Italian (Brennero) borders, each with different MEC deployments on the network. Further details are explained below.

Additional details on Cross-Border Testing

The manoeuvre management application running on each MEC will also handle the cross-border aspect. For this we can assume that there can be a scenario where two vehicles are served by a Service on MEC A which runs in a certain MNO´s network and another vehicle served by a Service on MEC B located on a network originated from the other side of the border. The final algorithm details are in discussion, the goal for the pilot being that only one of these MEC Services will coordinate the manoeuvre if required. This may be for instance the one which already has the most connections to the vehicles or the least latency; however, depending on the network situation it may also be decided to switch to V2V manoeuvre management via PC5. The CAMs from the vehicle which is currently on the foreign network will be forwarded to the coordinating MEC through a logical tunnel at application level. Only when all CAMs from all involved vehicles are available an action can be performed.



Figure 6 depicts a snapshot of how the CAM messages could be forwarded between the MECs when required.

Figure 6 Cooperative Lane Merging: communication between the MECs

As cooperative manoeuvring is a complex scenario, the pilot testing plan will consist of several stages. First, simulation tests based on NS3 and an application emulator with real vehicle data will be performed (CEA, UPV). As a second step, the possibility of Service instantiation and orchestration laboratory tests is planned, as this is the key to handling larger amounts of parallel cooperative manoeuvres as well as gaining expertise concerning the service interruption times while the vehicle changes its connection from one network to the other.

As to the field tests, we will start with MEC services from a single MNO, and after that, move to the cross-border scenario, where a MEC interconnection is required.

In Kufstein, the goal of 5G-CARMEN is to show how the centralized approach works even if cars are connected to different networks and MEC servers; this is a key aspect of service continuity. Here two MEC instances will be in use, one per each network provider. We will recreate the scenario mentioned in the section above, where one vehicle (CRF or BMW) will be connected to a Service running on the in TMA network and two others (CRF or BMW) will be connected to the one in DTAG network. These two MEC Services will be synchronized at application level, allowing the forwarding of CAM messages between each other when needed. This implementation will show interoperability between different OEMs and MNOs as well.

In Brennero 5G-CARMEN will demonstrate the fact that, even when V2N service continuity is not guaranteed, we can assist the driver by (1) preventively informing about the incoming events and (2) still running a basic feature of lane merge based on side-link (PC5) connectivity. This feature is useful also in case of problems with the mobile network.



High level Storyboard

Case 1.1: no traffic on the public road (or on closed track)

• INITIAL condition: Connected vehicles A, B, C are moving on a highway. o Vehicles A, C are on the left lane at moderate speed (90-100km/h) with some distance

between them (e.g. 40m) o Vehicle B is on the right lane moving at approximately the same speed (90-100km/h,

as vehicles A and C. o Vehicles A, B and C periodically share their status to the manoeuvre management

application via CAM messages (speed, direction, location, current lane) • EVENT: Vehicle B signals its intention to merge to the left lane by setting the left blinker on.

o Vehicle B sends a request to merge to the manoeuvre management application in the MEC.

o Vehicle B receives a request acknowledgment from manoeuvre management application

• REACTION: A sufficient gap needs to be created between vehicles A and C, therefore: o Manoeuvre management application calculates the distances between the vehicles, their

expected speeds and directions. o It provides a manoeuvre recommendation in order to allow enough space for the vehicle

to merge into the lane. In this case, Vehicle C needs to slow down. o Vehicle C receives the instruction to slow down via DENM message

LocationContainer à eventSpeed field. EventSpeed could be between 70-80km/h o Manoeuvre management application receives status updates from the three vehicles

again and determines if it is safe to perform the lane merge o Request approval or denial is sent to Vehicle B

• CONCLUSION: Depending on the gap distance and speed differences: o Adequate gap and speeds: Vehicle B safely merge to left lane o Gap too small and inadequate speeds: Vehicle B continues in its current lane

The storyboard may depend on traffic conditions. In heavy traffic there will most likely be vehicles in both the overtaking lane and the first lane. In general, these may be sensed by other means such as radar, cameras, etc. but a careful analysis should be made when defining the algorithms to check what are the trade-off conditions of traffic in which cooperative manoeuvres can be planned – and make sense – considering a mixed cooperative car and non-cooperative car scenario.

Planned Locations and Time plan

• M18-M23: end-to-end functional testing o complete service for PC5 (localized) and Uu+MEC (centralized) with a single MNO (non

cross-border) o manoeuvre recommendation via HMI

• M24-M29: start of integration testing on cross-border scenario in a centralized approach o Local centralized tests with MEC Service o inter-MEC operation tests

• M30-M36: data gathering and evaluation o 4G/5G network German-Austrian border o final tests cross-border tests with complete solution o Demo events



Figure 7 Cooperative Lane Merging use case testing areas

Situation Awareness Overview

Figure 8 Situation Awareness use case overview

The general framework of the Back Situation Awareness sub use case implies the awareness of emergency vehicles in advance, even before they are visible/audible, to create safety corridor allowing to keep the highest possible speed for the Emergency Vehicle. The Vehicle Sensors and State Sharing sub-use case is meant to create awareness about adverse weather conditions or other hazards in advance, exploiting knowledge shared by a preceding vehicle or road-side sensors.

Deployment 4.2.2.1 Back Situation Awareness



Figure 9 Back Situation Awareness sub-use case deployment (AT-DE border example)

Figure 9 depicts the pilot deployment for Back Situation Awareness sub use case, considering the border from Austria to Germany as example. A Back Situation Awareness Function (BSAF) application instance will be instantiated on the MNOs’ MEC platforms as soon as these platforms receive the trigger from an emergency vehicle (emV). The BSAF instances in two MEC platforms on each side of the border shall connect in order to transfer the latest state information about the emergency vehicle that is being sent periodically by the emV towards the BSAF instance via the cellular network infrastructure. The BSAF instances shall continue to calculate the estimated time of arrival (ETA) of the emergency vehicle and then disseminate it to the vehicles at the front via the cellular network infrastructure. When the vehicles are at some hundreds of meters, they will also communicate through the PC5 interface.

4.2.2.2 Vehicle Sensors and State Sharing Figure 10 highlights how many data-sources and interconnections are possible through Vehicle Sensors and State Sharing. From the 5G deployment perspective, the service is provided through the AMQP brokers deployed in the MEC’s of Italy and Austria, synchronized through a specific interface. AMQP can dispatch to vehicles (consumers) messages coming from different sources (producers), e.g. vehicles or infrastructure backend (IoT approach). C-ITS-S are the road operators’ (or in case of SWM, service providers’) services that, upon events, can generate Decentralized Notification Messages (DENM) and dispatch them via AMQP and/or RSU. Side-link is available between the main vehicle prototypes and also at specific experimental roadside units deployed in Italy. Since in Austria the usage of PC5 roadside units is currently not planned on public road sections, ETSI ITS G5 is used instead, to communicate with other vehicles prototypes. This allows also demonstrating interoperability, which is achieved through the C-ITS-S back-end.



Figure 10 Vehicle Sensor and State Sharing Awareness sub-use case deployment

Situation awareness Pilot Plan

This use case relies on the combination of V2N and side-link connectivity to provide input to ADAS systems and automated driving functions with connectivity. The objective is to evaluate how information from hazards can be used by the vehicle, considering the novel 5G potential: low latency edge-computing, extended coverage, integration of multiple information sources (IoT data sharing). Special attention will be paid to the cross-border scenario, where potential network and thus information gaps can happen, affecting the service. The goal is to have a flexible application that aids an automated vehicle on board unit based on the available information source and related quality (data availability, accuracy, security and trust).

As basic customer need, back situation awareness enables safe lane merge operations (linked to the Cooperative Lane Merging use case) thanks to an early information of incoming Emergency Vehicle; Vehicle Sensors and State Sharing enables the car to constantly monitor the surroundings, in order to assess the Operational Design Domain (ODD) and possibly allow for higher SAE levels (L3 and basic L4 functionality of “safe stop”).

The idea is to have a link independent application which receives the events (surrounding cars, weather events, road modifications, traffic jam) as digital objects, independent from the 5G link. It is expected, however, that V2N supports the car in the “information area” (>10 s in advance, >300-400 m) where the event information allows manoeuvrings and control, while both technologies work in the warning area (



Figure 11 Situation Awareness use case vehicle schema (note: vehicle model is not indicative)

A prototype on board unit for Advanced Driver Assistance Systems receives the C-V2X information and combines it with the vehicle’s own sensors (front, surrounding) in order to warn the driver or influence the automated vehicle’s behaviour. In dangerous cases it can downscale the automation level, or even trigger a safe stop manoeuvre in case of no intervention. BMW will also provide a vehicle but currently the plan is only for Back situation awareness. Using Qualcomm prototype units, the vehicle is connected to the 5G-CARMEN vehicle-to-network services and applications residing on MEC platform and can also communicate peer-to-peer to the other vehicles and roadside units. At the MEC the situation awareness application can inform about emergency vehicles; an AMQP broker on the MEC in Italy is connected to the BRE-A22 C-ITS-S back-end to dispatch road events, while another AMQP broker on the MEC in Austria will support in demonstrating the cross-border scenario. For the Vehicle Sensors and State Sharing use case, roadside sensors will be used (e.g. A22 fog sensors) and in turn, the vehicle can share a subset of the vehicle data via C-V2X, leverage results from previous projects such as Autopilot [19]. The following picture provides a synthesis of 5G-CARMEN partners’ contributions for the different components. In addition, TIM, TMA and QGER will take care of network connectivity in the three countries. The use cases will be first tested by means of in-country trials mainly in Trento and Modena, for practical reasons, and then tested at Brennero and Kufstein borders. In Trento, for Vehicle Sensors and State Sharing, the MEC and PC5 connectivity will be tested, addressing also 5G and ETSI ITS G5 interoperability through a back-end at A22 (see D2.1 annex on interoperability Use Case), and while for Back situation awareness only the PC5 link will be used. In Modena, due to the peculiar site characteristics, fog information sharing, and warning will be tested.

At the Brennero, the Vehicle Sensors and State Sharing use case will be tested. In addition, simulation facilities by CEA and VIF are foreseen.

High level Storyboard

Rationale: evaluate 5G potential in C-ITS services (priority Services); other Hazardous Notifications V2I (slow stationary vehicle, traffic jam, adverse weather conditions, etc.), maybe Road Works Warning (V2V applications e.g. Forward Collision Warning and Emergency Electronic Brake Lights).



1. Back Situation Awareness

Case 1.1: no traffic on the public road (or on closed track)

• INITIAL condition: Connected vehicles A, B, C, and the Emergency Vehicle EV are moving on a highway.

o Vehicles B, C are on the right lane at moderate speed (90-100km/h) with some distance between them (e.g. 100m)

o Vehicle A approaches on the left lane (10-20 seconds away) moving a bit faster (110-130 km/h, eventually will overtake

o EV is some 20-30 seconds away from A moving at 130 km/h • EVENT: EV turns its emergency state on (electronically)

o This triggers an emergency vehicle warning with Estimated Time of Arrival (ETA). • REACTION: The overtaking lane needs to be cleared by the cooperative vehicles, therefore:

o Vehicle A needs to shift lane and then slowdown to a moderate speed. o Depending on the ETA and speed differences

§ ETA much bigger than overtaking time: Vehicle A ends the overtake § ETA much smaller than overtaking time: Vehicle A shifts lane and queues

behind vehicles B and C § ETA in between: B and C keep on the right lane, and do a lane shift operation

with Vehicle A (PC5-based lane change, simplified with respect to CLM) • CONCLUSION: EV passes undisturbed on the cleared overtaking way. • NOTE: when the EV is in range, vehicles A, B and C have an improve awareness of the EV

from its messages sent over PC5.

Case 1.2: traffic on public road

• INITIAL condition: (most likely) cooperative Vehicles A, B, C, and the Emergency Vehicle EV are moving on a highway, on the overtaking lane.

o Vehicles A, B, C are proceeding at a distance permitted from the situation: other non-cooperative vehicles are present on the overtaking lane and most likely the first lane is busy, too.

o EV is some 20-30 seconds away from A moving at 130 km/h • EVENT: EV turns its emergency state on (electronically)

o This triggers an emergency vehicle warning with Estimated Time of Arrival (ETA). • REACTION: The overtaking lane needs to be cleared by the cooperative vehicles,

therefore: o Vehicle A, B, C try to find space and shift lane and then slow down to a moderate

speed. • CONCLUSION: EV passes undisturbed on the cleared overtaking way.

2. Vehicle Sensors and State Sharing:

• INITIAL condition: Vehicle A and B are on the motorway. Vehicle A (ahead) is proceeding. Vehicle B drives 20-30 s after Vehicle A.

• EVENT 1: the infrastructure sends a hazard information to Vehicle A (e.g. generic fog information)

o DENM1 by infrastructure • REACTION 1: Vehicle A slows down



• EVENT 2: Vehicle A detects another hazard on the way (e.g. extremely low visibility traffic jam, emergency braking), thus it downscales automation level or turns in manual mode and moves very slowly

o DENM2 by vehicle: sensors and state sharing o Possible aggregation of DENM 1 and DENM 2 at MEC service o DENM1, DENM2, and CAM of Vehicle A are received by Vehicle B

• REACTION 2: Vehicle B, coming after, controls the speed optimally, having received the following:

o A general warning signal from the infrastructure o A specific event warning from Vehicle A o Cooperative Awareness Messages from Vehicle A

• CONCLUSION: Vehicle B can optimize the speed and keep AD level. • VARIATIONS ON MAIN THEME:

o A Cooperative Vehicle C drives between A and B o A Non cooperative Vehicle D drives also between A and B (hinders sensors’ field

of view) o Road Works Warnings with lane change are needed

• MAIN AD TARGETS/KPI’s: o Smoothness of Vehicle B manoeuvre o Autonomous Driving Operational Design Domain: how it is changed based on

warning advance and quality o (not shown, only analysed) possibility to implement L4 functionality of safe stop

thanks to advance warning

Interoperability testing storyboard ETSI ITS-G5 versus C-V2X (PC5/Uu) is still to be discussed, but the baseline was already illustrated in D2.1.

Steps and assets to achieve the storyboard

Back situation awareness

First, tests in a laboratory environment will be performed for the edge orchestration, and on the precise positioning solution.

In the meantime, software components needed for the use case will be developed and tested in the lab:

• On Board software for “emV approach” message generation, either on the C-V2X unit of a vehicle prototype or on a test tool which can be hosted on a car

• On Board software for “emV approach” message reception, based on V2N and PC5 • On Board software based on PC5 and on V2N which suggests clearing the lane asap • MEC software which receives notifications from emV, computes the ETA and dispatches

related information to relevant vehicles • Localization software

Next, the software will be integrated into vehicles for piloting, and software/piloting specifications will be shared with WP6 which carries out simulations, especially targeting the impact of latency on the Use Case effectiveness.

On the final pilot solution, a connected car is expected to play the emV, while both BMW and CRF cars will receive notifications and perform lane shifts. The MEC based service calculates ETA and



works seamlessly through the border thanks to MEC orchestration and interconnection. When coming nearer the vehicles, PC5 will also be available, so that the EV presence will be more accurately sensed by the vehicle thanks to cooperative messages. The whole storyboard and related cross-border aspects will be most likely piloted in Kufstein southbound, going from Germany to Austria.

For the emergency vehicle a very high level of security is needed, in order to avoid any type of misuse. Only authorised user, not just vehicles, can have access to this service. To implement this, a specific wearable device, a bracelet will be considered. The bracelet will provide the needed security information (certificates, type of authorisation, etc.) to protect the communication between the EV and infrastructure and other vehicles. The bracelet is realised with the highest possible level of security, then impossible to be hacked.

The bracelet can store information provided from different countries, allowing emergency vehicles to travel cross border using always the right authorization information for the specific country. This, linked with 5G cloud services, allows authorities to guarantee the complete secure control of the emergency vehicles along 5G corridors.

Figure 12 DSEC wearable solution for security credential, applicable to emergency vehicle drivers

Vehicle Sensors and State Sharing

Vehicle Sensors and state sharing will be based on shared C-V2X information among vehicles and infrastructure. The groundwork are the C-ITS priority services, provided through V2N based on local MEC AMQP broker (instead of having a cloud service), and when in proximity side-link instead of IEEE802.11p can be used (only in one case we will involve 802.11p, namely the interoperability use case). Among the priority services a focus is on adverse weather conditions (fog, rain, and snow) whereby the infrastructure-based information is fused with the on-board system detection, and the data fusion result is shared in a cooperative way to improve the overall hazard detection.

To demonstrate this, CRF will provide at least two vehicle demonstrators (one connected and one connected and automated) and maybe one additional vehicle with a lightweight OBU installed, to have the cooperation among three vehicles.

Concerning environmental detection, this is planned with the on-board sensors, dedicated roadside systems attached to a portable Road Side Unit, and from the legacy system of A22. At the backend the Road Operators need to adapt their C-ITS-S system on the Italian and Austrian infrastructure respectively, in order to send priority services through the 5G-CARMEN network.

The C-V2X services will be available through PC5 and also through AMQP message brokers running on the MEC in Italy and Austria. In Austria, ETSI ITS G5 interoperability testing is planned, as PC5 cannot be used on these RSUs. The software and hardware components to be developed are



• On Board C-V2X software featuring priority services • On Board ADAS application on DSpace MabX prototype platform • Dedicated on-board sensors and another vehicle installations • Roadside infrastructure sensors and PC5 RSUs • Portable weather stations and PC5 RSU’s • AMQP message broker running on MEC • Localization software • ETSI ITS G5 roadside units: no dedicated development, adaptation/usage only

CRF has started testing software and hardware component to address both visibility detection (fog sensors) and driving assistance systems in adverse weather conditions, to plan the subsequent in-vehicle integration. Next steps will be to develop the C-V2X applications needed to share relevant data with 5G-CARMEN vehicles and infrastructure, which will be performed as part of T3.6 Services and applications for CCAM and then integrated into the demonstrator in T4.4.

In parallel SWM and TIM will address the MEC service aspects in order to have message relay across borders as outlined in D3.2.

In the laboratory, CNIT will run a V2X simulator while CMA will address eNB, EPC, RNIS.

First test trials are planned in Trento (M18), Modena and then cross-border (AMQP synchronization) while the final use case storyboard will be piloted near Brennero, most likely northbound from Italy to Austria.



Planned Locations

Back situation Awareness

Figure 13 Back situation Awareness use case testing areas

Vehicle Sensors and State Sharing

Figure 14 Vehicle Sensors and State Sharing use case testing areas

Time plan

• M18-M23: start piloting



o Back Situation Awareness: complete service and real vehicle, cloud mock-up of MEC Back Situation Awareness functionality.

o Vehicle Sensors and State Sharing: full chain (roadside sensors to the vehicle) and first integration of AMQP on MEC.

• M24-M29: start of integration testing on cross-border scenario o Back Situation Awareness: MEC Back Situation Awareness functionality integration

and testing in cross-border. o Vehicle Sensors and State Sharing: complete integration functionalities on the various

sites and test cross border. • M30-M36: data gathering and evaluation

o Final tests cross-border tests with complete solution. o Demo events

Video Streaming Overview

Figure 15 5G-CARMEN Video Streaming use case HMI overview

5G-CARMEN will explore different network architectures and configurations, aiming to satisfy the users’ Quality of Experience (QoE). Key in this regard is the prediction of the expected network QoS and the proactive adaptation of streaming applications in order to avoid interruptions in the service whenever possible. High quality service should always be available, even in cross-country border situations and inter-operator scenarios.

Deployment Figure 15 shows the pilot deployment for the video streaming use case. The video streaming server and the predictive QoS service will be located in the cloud. Input from the RAN and core network is used by a predictive QoS Application and made available for client applications such as a video streaming App. This triggers an adaptation on the streaming application located in the vehicle´s video client.



Figure 16 Video Streaming use case deployment

Video Streaming Pilot Plan

This use case test consists of three parties:

• the vehicle equipped with a video streaming client who will

deliverable d5.1 5g-carmen pilot plan · 2020. 9. 28. · 2 project details call h2020-ict-18-2018...

Documents