guidance for day 2 and beyond roadmap · the day1 deployment phase uses cooperative awareness (ca)...

CAR 2 CAR Communication Consortium

C2CCC_WP_2072_Roadmap

Day2AndBeyond.doc 25/09/2019 of 42

Guidance for day 2 and beyond roadmap CAR 2 CAR Communication Consortium

About the C2C-CC

Enhancing road safety and traffic efficiency by means of Cooperative Intelligent Transport Systems and Services (C-ITS) is the dedicated goal of the CAR 2 CAR Communication Consortium. The industrial driven, non-commercial association was founded in 2002 by vehicle manufacturers affiliated with the idea of cooperative road traffic based on Vehicle-to-Vehicle Communications (V2V) and supported by Vehicle-to-Infrastructure Communications (V2I). Today, the Consortium comprises 73 members, with 12 vehicle manufacturers, 33 equipment suppliers and 28 research organisations.

Over the years, the CAR 2 CAR Communication Consortium has evolved to be one of the key players in preparing the initial deployment of C-ITS in Europe and the subsequent innovation phases. CAR 2 CAR members focus on wireless V2V communication applications based on ITS-G5 and concentrate all efforts on creating standards to ensure the interoperability of cooperative systems, spanning all vehicle classes across borders and brands as well as other road users. As a key contributor, the CAR 2 CAR Communication Consortium works in close cooperation with the European and international standardisation organisations such as ETSI and CEN.

Disclaimer

The present document has been developed within the CAR 2 CAR Communication Consortium and might be further elaborated within the CAR 2 CAR Communication Consortium. The CAR 2 CAR Communication Consortium and its members accept no liability for any use of this document and other documents from the CAR 2 CAR Communication Consortium for implementation. CAR 2 CAR Communication Consortium documents should be obtained directly from the CAR 2 CAR Communication Consortium. Copyright Notification: No part may be reproduced except as authorised by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2019, CAR 2 CAR Communication Consortium.




Document information

Number: 2072 Version: 1.1.0 Date: 25/09/2019

Title: Guidance for day 2 and beyond roadmap Document Type:

White Paper

Release: N.a.

Release Status:

Public

Status: Final




Changes since last version

Title: Guidance for day 2 and beyond roadmap

Explanatory notes:

25/09/2019 Initially published

Release Management Steering Committee

Date Changes Edited by Approved

Table 1: Changes since last version




Content

About the C2C-CC...................................................................................................................... 1

Disclaimer .................................................................................................................................. 1

Document information ................................................................................................................ 2

Changes since last version ......................................................................................................... 3

Content ....................................................................................................................................... 4

List of figures .............................................................................................................................. 5

List of tables ............................................................................................................................... 5

1 Introduction ......................................................................................................................... 6 1.1 Abstract ........................................................................................................................ 6 1.2 Summary of the document ........................................................................................... 6 1.1 Structure of the document ............................................................................................ 8

2 The C2C-CC Roadmap at a glance ..................................................................................... 9 2.1 Use cases and services roadmap ............................................................................... 10

3 The Day 2 vision ................................................................................................................ 15 3.1 Day 2 services and use cases .................................................................................... 15

3.1.1 Improved Infrastructure-support services ........................................................................... 15 3.1.2 Cooperative Awareness and Decentralized Notification Service extensions ..................... 16 3.1.3 Collective perception .......................................................................................................... 20

3.2 Short-term technology requirements ........................................................................... 24 3.2.1 Application and Application-related facilities layer requirements ....................................... 24 3.2.2 Security requirements ......................................................................................................... 24 3.2.3 Communication-related Facilities and Networking requirements ....................................... 24 3.2.4 Access layer requirements ................................................................................................. 25

4 The vision beyond day 2 .................................................................................................... 26 4.1 Intention sharing and negotiation: the first steps towards cooperative automated driving 26 4.2 Maneuver Coordination for seamless cooperative automated driving ......................... 28

5 Appendix 1 ........................................................................................................................ 31 5.1 Sample use case list .................................................................................................. 31 5.2 Application-to-Message matrix ................................................................................... 37

6 Appendix 2 ........................................................................................................................ 39 6.1 List of abbreviations ................................................................................................... 39 6.2 References ................................................................................................................. 41




List of figures

Figure 2-1: C2C-CC Use cases and services roadmap ............................................................ 10

Figure 3-1: (a) Intersection scenario, (b) Left turn with oncoming traffic .................................... 18

Figure 3-2: Warning situation for intersection left turn with oncoming traffic. ............................. 19

Figure 3-3: Example for day 2 MAW warning in critical situations. ............................................ 20

Figure 3-4: General structure of a CPM [13] ............................................................................. 21

Figure 3-5: Sample scenario of the cooperative merging on highways use case. The blue car sends a CPM (orange arrow) with information on the detected grey car. .................................. 22

Figure 3-6: Sample scenario of the cooperative overtaking on rural roads use case. The truck sends a CPM (yellow arrow) with information on the detected red car. ..................................... 23

Figure 4-1: Lane change of subject vehicles in target area ...................................................... 27

Figure 4-2 MAVEN I2V interactions ......................................................................................... 28

Figure 4-3 Example of cooperative maneuver execution employing the MCM [25] .................. 29

Figure 4-4 Example of situation challenging the V2V MCS proposal [20] ................................. 30

List of tables

Table 3-1: Behavior description of MAI/MAW in the two scenarios. .......................................... 19




1 Introduction

1.1 Abstract

The Competence Group Roadmap of the C2C-CC is aimed at generating and continuously updating an automotive-based strategical roadmap for C-ITS deployment in Europe. The scope covers guidelines, R&D needs and implementation options for C-ITS systems to be deployed on both short and long term. For this purpose, this competence group works in close cooperation with the other functional and technical competence groups of the C2C-CC and, when needed, establishes links with ongoing European R&D projects, other stakeholders (e.g. C-Roads) as well as standardization bodies on C-ITS.

In this context, this white paper provides the C2C-CC with guidance about activities that are needed or have to be prioritized for preparing the future C-ITS deployment phases beyond Day1. In particular, this white paper highlights the C2C-CC C-ITS deployment strategy organized in subsequent phases of deployment in which new generations’ use cases and supporting functionalities are increasingly introduced on top of the pre-existing ones and evolve in such a way to gradually enable cooperative automated driving. For next generation deployment, the so-called Day2, this white paper already indicates specific concepts to be better developed and associated issues to be addressed by dedicated C2C-CC competence groups. For deployment beyond Day2, the white paper summarizes the future scenarios to be considered as result of the many ongoing R&D activities on related topics. Taking inputs from the use cases and requirements described in this white paper, a roadmap highlighting how supporting technologies shall evolve to enable the C2C-CC deployment vision is under construction in the Working Group Technical.

1.2 Summary of the document

The C2C-CC roadmap is organized in subsequent deployment phases named Day1, Day 2, …, Day N (Figure 2-1). The sequence of these deployment phases will allow transition from dissemination of local status information and warnings to cooperative automated driving. The C2C-CC roadmap associates, to each phase, introduction of specific application-related services as well as representative examples of use cases/applications that can leverage them. Application-related services are ETSI ITS architecture facilities administrating message management for data exchange between C-ITS stations. At a given deployment phase, different types of information will be exchanged by the application related services.

The Day1 deployment phase uses Cooperative Awareness (CA) and Decentralized Environmental Notification (DEN) services to disseminate vehicle state information as well as occurrence of dangerous situations. Exchanging this type of information allows realizing V2V warning applications. At the same time, infrastructure-based services providing static and dynamic information about the road infrastructure are introduced (In-Vehicle Signage, Traffic light signal phase and time, Road Topology description services) allowing implementation of other traffic safety, efficiency or information applications.

In the Day2 phase, vehicles and RSUs will take advantage of being equipped with environment-sensing technologies to share information about detected objects. This capability will enable receiving vehicles to be aware of obstacles they would not otherwise detect with their own sensors (e.g. pedestrians or cyclists hidden behind a corner in intersection areas). In this way, enhanced safety applications compared to the Day1 ones can be introduced. Enhanced applications will also be possible thanks to extension of information conveyed in the messages shared via cooperative awareness and decentralized notification services. These applications will not necessarily aim at warning drivers but will, wherever possible, implement semi-automated reactions like automated braking for Vulnerable Road User (VRU) protection or control functions like Cooperative Adaptive Cruise Control (C-ACC). Finally, Day2 applications will take advantage from new infrastructure-related services extended to provide more precise




and articulated information to vehicles (e.g. more complex road topologies and/or combined warning and signage information).

A third phase of deployment, namely Day3+, will take advantage of the introduction of vehicles with increasingly automated driving capabilities (level 3-4) and their ability to share planned trajectories/routes and maneuver intentions with other traffic participants and the infrastructure. Sharing this information will unblock implementation of cooperative automated driving use cases in which automated cars can implicitly or explicitly coordinate the execution of maneuvers to avoid conflicts and hence ensuring safety (cooperative lane change, cooperative merging, advanced C-ACC applications like C-ACC strings where follower vehicles gets longitudinally and laterally automatically controlled, or management of C-ACC strings including dynamic joining and leaving vehicles, string break-up, and so on). Moreover, in the Day3+ phase, VRUs are expected to be V2X-equipped and play a more “active” role in announcing their presence and detect risky situations, hence contributing to further increase in road traffic safety.

Each subsequent phase will inherit the capabilities of the previous ones in a backwards- compatible manner. In other words, newer vehicles will keep transmitting the information needed by older vehicles to run their supported applications. New services will be coexisting with old ones at a given deployment phase and new use cases will make use of old and new services, if needed.

The current work done in the C2C-CC, C-Roads and ETSI TC ITS for introduction of Day2 services and use cases has allowed identification of some core technological concepts that need to be better studied and specified as well as technical issues that need to be addressed. At application level, new triggering conditions and message generation rules must be tailored to the requirements of new use cases. As an example, even if it is clear that the main innovation for Day2 will be the Collective Perception (CP) service, more work is needed for the specification of the rules for inclusion of detected objects in transmitted messages (e.g. at the moment there is no harmonized definition for confidence or plausibility levels of detected objects justifying their inclusion in CP messages among different vendors’ implementations). Taking into account communication aspects, more work needs to be done in understanding how Day2 message sets can coexist in the same communication channel as used by the Day1 system and how they can be allocated to alternative channels of the ITS band. In the former case, new and more effective techniques for Decentralized Congestion Control (DCC) need to be integrated by taking into account the requirements of Day2 applications (e.g. more frequent transmission of messages for safety-critical or safety-relevant applications like pre-crash exchange of information or C-ACC). In the latter case, Multi-Channel Operation (MCO) techniques need to be defined and developed. Another important aspect is the use of improved radio access technologies. Even though it is unclear at the moment of writing as to when alternative or improved short range ad-hoc radio access technologies will be ready for real introduction, one fundamental requirement is that those technologies must support backwards-compatibility with already deployed systems (previous generation messages transmitted with the new technologies must be received also by old systems already in place). Finally, new requirements are also expected to be posed to security. Day2 use cases might impose new pseudonym changing rules and security management functionalities like dedicated misbehaviour detection and handling, cryptoagility, confidentiality, tamper-proof solutions, etc.

Contrary to what identified for the Day2 deployment phase at the moment of writing this document, it is still premature to identify stable common set of functionalities and requirements for Day3 and beyond systems. For this reason, this document is not including a list of technological requirements for them. Nevertheless, this document lists relevant examples of Day3 and beyond use cases as studied in past and current R&D activities. It is recognized that cooperative maneuvering (both V2V- distributed and I2V-centralized/infra-assisted) can be an important enabler for automated driving. At the same time, the road infrastructure can have an important role in providing additional/complementary/redundant support, via V2X, to some fundamental technological aspects that will be key for automated driving (position correction, map update, collective perception, are just a few examples). On this basis, a new work item has been recently opened in the C2C-CC that is collecting investigated approaches for




cooperative and connected automated driving with the aim of identifying an initial set of common functionalities (services) and technical aspects (technologies) to be considered as starting point for future C2C-CC harmonization and specification.

1.1 Structure of the document

The rest of this document is organized in the following way. Section 2 provides an overall description of the C2C-CC phased deployment roadmap. Section 3 more accurately describes the Day2 deployment phase by providing a detailed description of the application-related services to be introduced in this phase and an explanation of some of the most representative use cases. A list of technological requirements associated to these services and use cases is also provided. Section 4 includes an introduction to possible use cases and services to be introduced at later deployment phases more related to cooperative automated driving. As Appendix 1 of this document, a matrix is reported that maps sample Day1, Day2 and Day3+ use cases to possible sets of application-related services (messages) that can support them.




2 The C2C-CC Roadmap at a glance

Over the past years, the C2C-CC has worked at specifying the so-called Day 1 V2X system running on vehicles and has identified the first set of applications that can be run thanks to V2V communications in a first phase of deployment announced to happen from 2019 [1]. At the same time, road operators and road authorities in various European countries have joined efforts for the specifications and pre-deployment of C-ITS communication infrastructure and services. The experience initiated in the Amsterdam Group [2] with the C-ITS infrastructure pre-deployment projects C-ITS Corridor (in Germany, Netherlands and Austria) and SCOOP (France) has been consolidated and harmonized in the context of the C-ROADS platform [3], which is facilitating a European-wide deployment of C-ITS by 2019 as mentioned in the Memorandum of Understanding signed with the C2C-CC [4].

The specifications of the Day 1 V2X vehicular system are collected in the C2C-CC Basic System Profile (BSP) [5]. The BSP is based on the ETSI TC ITS set of standards defining suitable protocols from access- up to facilities layer to support the Day 1 applications. The BSP indicates the standards considered by the C2C-CC Day1 system, profiles them in the most suitable way and defines HW and SW requirements that must be respected to ensure that different implementations provide the needed interoperability support and quality to form part of a trusted ad-hoc vehicular network. In addition, the C2C-CC has defined a set of triggering conditions for the Day1 applications [5]. Similarly, the V2X infrastructure-related system and Day 1 applications have been specified by C-ITS infrastructure experts in C-ROADS and available at [6]. The C2C-CC and the C-Roads specifications have been harmonized in order to provide I2V interoperability and are considered as the basis for the publically available European Commission delegated act on C-ITS [7].

The Day 1 applications are essentially safety applications aimed at increasing the awareness horizon in both time and space, in a way for the driver or the vehicle to have more time to react to dangerous and unexpected situations. Examples of these applications are the stationary/slow vehicle warning, intersection collision warning, emergency electronic brake light, emergency vehicle approaching, adverse weather conditions, etc. (Figure 2-1). These applications are based on the exchange of the Day 1 messages, namely Cooperative Awareness Message (CAM) and Decentralized Environment Notification Message (DENM), over the ETSI ITS G5 radio access technology in a single channel scenario (the service channel SCH0 between 5.895 and 5.905GHz). CAMs are continuously broadcasted to convey dynamic information of the transmitter such as vehicle speed, position, and heading, etc. with a variable frequency between 1 and 10 Hz depending on vehicle dynamics and the experienced channel load conditions. DENMs are event-triggered and are broadcasted to notify environmental situations detected by the ego vehicle whose knowledge is beneficial for receivers located in a specific zone of relevance (e.g. vehicles approaching roadworks from a specific traffic direction). Unlike CAMs, DENMs can be multi-hopped over the relevance area and their transmission repeated until the event is detected or considered valid. In principle, both CAMs and DENMs can be transmitted by vehicles as well as roadside units (RSUs). In this context, the previously mentioned C2C-CC triggering conditions documents define the way a given anomalous or dangerous event (e.g. a stationary vehicle) shall be recognized by the vehicle system (e.g. monitoring specific CAN signals), outline which V2X messages must be transmitted accordingly, and how they must be populated in the available data fields/elements. Similarly, the C-ITS pre-deployment projects have defined and tested, in collaboration with the automotive industry, profiling specifications for CAM and DENM, as well as Signal Phase and Timing (SPAT)/Map (MAP) and Infrastructure to Vehicle Information (IVI) messages transmitted by RSUs and road infrastructure-related vehicles (e.g. roadworks trailers) to ensure their exploitability at the vehicle reception side. All these standardization and pre-deployment activities have focused on specifying the requirements at the transmitting side for ensuring quality and interoperability. The implementation of the receiving side (including applications) is left open to automakers in a way




to allow competitiveness while accounting for liability on how the received information is handled.

It can be seen that the Day 1 system and applications are based on the paradigm of sharing basic individual vehicle and infrastructure status information in order to increase awareness of the receivers’ surrounding with the final aim to deliver improved traffic safety. At the same time, vehicles are nowadays being equipped with more and more technologies enabling automated driving functions. An increasing penetration of on-board sensors (e.g. radars and cameras) allows vehicles to have a better perception of their close surroundings. Advanced algorithms use the achieved environmental perception to compute control outputs that can support or even substitute some driver tasks.

In this context, while in a first deployment phase, the V2X information is just complementing on board sensor inputs to extend the vehicle environmental perception, for subsequent V2X deployment phases it is reasonable to let vehicles exchange the results of perception (detected objects) and control algorithms (intentions or trajectories) in order to gradually enable cooperative automated driving scenarios. The way in which V2X can be used to support the transition from manual driving with improved awareness towards cooperative/coordinated automated driving is described in the next sections. The traffic scenarios resulting from deployment of such systems are expected to provide a gradual increase of safety and efficiency.

2.1 Use cases and services roadmap

The C2C-CC conceives a V2X deployment roadmap organized in subsequent phases named after the time of deployment (Day1, Day 2, …, Day N). As visible in Figure 2-1, this roadmap is based on the already visible increase of vehicle automation functions as well as an expected rising penetration of V2X equipped vehicles. As previously mentioned, this will allow transition from phases in which V2X is a technology primarily used for dissemination of local status information towards phases where V2X is a key factor to enable cooperative automated driving.

Figure 2-1: C2C-CC Use cases and services roadmap




The C2C-CC roadmap reports, the application-related services that are expected to be deployed in subsequent phases, as well as representative examples of use cases/applications implementable and deployable based on those services. In this context, it is an individual choice of each OEM to decide which applications to deploy at which time. Following the definitions of [8], the application-related services provide, at facilities level, support for common message management for data exchange between ITS stations. In the C2C-CC roadmap, application-related services allow vehicles, infrastructure, and other road users to exchange, in subsequent phases, different classes of data which are specific to that phase and in turn enable implementation of applications with increasing level of complexity.

Even if each phase is associated a given class of data, services and applications, each subsequent phase will inherit the capabilities of the previous ones in an increasing way. Therefore, newer generations’ vehicles must still provide support for older generations’ vehicles in a backward compatible manner. In other words, newer vehicles will keep transmitting the information needed by older vehicles to run their supported applications. This concept is reflected in Figure 2-1 by grouping services and example use cases into dedicated boxes that are overlapping over subsequent deployment phases. This indicates that new services will be coexisting with old ones at a given deployment phase and that new use cases can make use of old and new services, if needed. In addition, services must ensure backwards compatibility in case they get extended at a given phase compared with the previous one. For example, a possible Day 2 extended cooperative awareness service with additional capabilities has to ensure that Day1 use cases based on reception of Day 1 CAMs are still supported when receiving Day 2 CAMs.

As previously mentioned, the use cases reported in Figure 2-1 are just examples of what can be deployed by any OEM at a given deployment phase. For the Day1 use cases, the naming has been harmonized with the terminology used by the EU C-ITS Delegated Act [7]. For the Day 2 and 3+ use cases, examples are taken from ETSI WG1, relevant R&D projects, and inputs from individual OEMs. Again, the use of overlapping boxes to group the use cases indicates that new use cases will be incrementally added on the top of existing ones and will coexist with them. Also, it is a valid assumption that use cases based on a previous set of services can be introduced in later phases when new services are already available. This is represented in Figure 2-1 by having the use cases grouped in separate columns in a given use case box. For example, the red light violation protection use case, which in general relies on the Day 1 SPAT/MAP service, might be introduced by an OEM when Day 2 services are already available.

Although the use case examples reported in Figure 2-1 are in general applicable to any vehicle category, other use cases specifically applicable to a particular vehicle category can be considered. This is the case for platooning applications currently considered by Truck OEMs. Truck platooning applications and platooning-supporting services have been widely tested and showcased over the last years and are currently being specified and harmonized in the ongoing EU funded ENSEMBLE project [9]. Platooning will be implemented by Truck OEMs using the services indicated in Figure 2-1 and also dedicated platooning-supporting services whose specifications are not finalized at the moment of writing this document. The platooning services and use case evolution will anyhow follow a similar roadmap as the one depicted in the figure, which is an introduction of platooning of increasing performance levels as automation and communication capabilities increase. Due to the above mentioned explanation, platooning is represented in separate, but not totally detached, boxes. It is currently under discussion in the C2C-CC the possibility to outline separate parallel roadmaps for vehicles of different types (passenger cars, trucks, Powered Two Wheelers (PTW) / motorcycles).




The C2C-CC roadmap phases are the following:

1. Day 1 phase – Awareness driving based on status data

As described in the previous section, in this phase vehicles and infrastructure will transmit information regarding their status (e.g. vehicle dynamics for cars, PTWs, information about tolling stations from RSUs), as well as information describing unexpected events (e.g. adverse weather conditions, dangerous situations). The application-related services adopted for generation and management of this information are the Cooperative Awareness Service [10] handling CAMs, and Decentralized Environmental Notification Service [11] handling DENMs. Exchanging this type of information allows realizing V2V applications like Emergency Vehicle Warning, Electronic Emergency Brake Light Warning, Stationary Vehicle Warning, Traffic-Jam Warning, Pre-Crash info exchange, Adverse Weather Warning, Intersection Collision Warning, Short Term Road works Warning, Hazardous Location Warning, and so on.

The Day 1 phase will also be characterized by the introduction of infrastructure-based services providing static and dynamic information about the road infrastructure [12]. Examples of these services are the SPAT/MAP conveying information about topology and signal time and phasing at signalized road intersections, as well as the In-Vehicle Signage service informing about dynamically changing and vehicle type-specific information on highways. Processing and fusing this information at the receiving side allows implementing new applications for traffic safety (e.g. red light violation protection), efficiency (e.g. GLOSA), or information (e.g. about traffic light, dynamic speed limits, specific vehicle restrictions).

Through the above services, receiving vehicles will increase their awareness of the surroundings (even beyond their line of sight) in terms of transmitting vehicles’ and infrastructure’s status and presence of road hazards. In this way, applications processing the received information will permit providing suitable warnings and information to the driver.

To understand how PTWs can be included in the Day 1 concept, some considerations are needed. The, triggering conditions for certain applications cannot be applied for PTWs in the same way as defined for cars. The following two examples give an impression of the differences:

A car may notify other vehicles about the end of a traffic jam, whereas a group of motorcycles may pass this traffic jam on the corridor for emergency vehicles. As a result, following vehicles may interpret this situation incorrect.

Motorcycles typically have no doors and no hand brakes. This way, the trigger of a breakdown vehicle will not be possible by using the trigger conditions defined for cars.

PTW-related use cases are basically triggered by PTWs, but the main action needs to be taken at the receiving vehicle. As a consequence, in this first phase, PTW-related use cases will be introduced as a Motorcycle Approaching Information (MAI) that will be based on the already specified CAM format for Day 1 use cases. However, only those data fields that can be provided by PTWs will be used. MAI basically works as a simple “beaconing function” using CAMs. The goal is that surrounding vehicles are informed about the presence of an approaching PTW. The information is mainly triggered based on the relative distance between the motorcycle and the receiving vehicle1.

1 In this context, the C2C-CC CG PTW provides guidelines on what needs to be considered at the

receiving side, because car manufacturers may not necessarily be aware of typical PTW situations. For example, for MAI some more context information may be important: if a car will only considers the relative distance between car and PTW, the car driver may be permanently informed about approaching PTWs in typical “PTW cities” like Rome or Paris, unless the number of surrounding PTWs, their headings and the ego and relative speed is considered.




2. Day 2 phase – Sensing driving based on sensor data

In this phase, the V2X system will be extended to additionally permit vehicles and RSUs to share information about objects detected via on-board sensors such as cameras, lidars or radars. This information, conveyed into Collective Perception Messages (CPMs), is generated and managed by the Collective Perception Service [13][14]. This additional information enables receiving vehicles to be aware of objects that would otherwise not be locally detectable (e.g. standing VRUs behind a corner in intersection areas, or vehicles behind a truck on interurban roads). The effect of this extension is twofold. On one hand, it mitigates the limitation deriving from coexisting with road users that are not equipped with V2X technologies and hence are unable to advertise their presence (VRUs, legacy vehicles, etc.). On the other hand, it allows implementing new or enhanced safety applications compared to the Day 1 system (e.g. VRU protection, Overtaking Warning, Advanced Intersection Collision Warning).

In the Day 2 deployment phase, Infrastructure services will also be extended. Firstly, they will provide the possibility to support prioritization of special categories of vehicles (e.g. public transport) via the Signal Request Extended Message (SREM) and Signal Request Status Extended Message (SSEM) [12]. Secondly, the Day 1 Infrastructure supporting services will be extended or even applied in a combined way for allowing more precise warning and information applications. This is in particular the case of the Long-term Roadworks warning applications, whose implementation is being studied in the ECo-AT project, seeking for solutions leveraging combination and extensions of DENMs and IVI messages [15]. Providing more detailed and precise information about a long-term roadworks zone can also be beneficial for the implementation of semi-automated applications in those zones. This may include also guidance information through the work zone based on very accurate geographic location information in IVIM, complemented with additional information useful to support in-lane positioning in work zones by automated vehicles.

Finally, the Day 2 deployment is also expected to introduce extensions of the CA Service. CAMs will be extended to allow the implementation of specific applications accounting for PTWs, as well as semi-automated functionalities such as the Cooperative Adaptive Cruise Control (C-ACC).

3. Day 3+ phase – Cooperative Driving based on intention and coordination data

After the Day 2 deployment Phase, a so-called Cooperative Driving phase is expected to follow. This deployment phase will take advantage of the introduction of vehicles with increasing automated driving capabilities (level 3-4). The particularity of these Cooperative Automated Vehicles (CAVs) is their expected capability to share intentions with other traffic participants as well as to communicate messages in order to coordinate specific maneuvers for avoiding conflicts. At this moment, it is not clear whether applications relying only on intention sharing will be deployed before those relying on coordination data exchange. For this reason, the current C2C-CC roadmap does not make a distinction between the two and conceives a generic Day3+ phase making use of both services.

An early example of how exchanging intentions and coordination messages can support cooperative automated driving is represented by the Cooperative Lane Merging (CLM) service as experimented in the Autonet2030 project [16]. Through this service, the merging vehicle communicates its intention to merge on a given section of the road (Target driving area reservation). The merging is then coordinated with the incoming vehicles by an exchange of reply/request CLM messages that finally allow executing the desired maneuver safely.

Exchanging messages for intention sharing is also envisioned in the context of I2V scenarios. As under study in the MAVEN project [17], cooperative automated vehicles heading towards a signalized cooperative intersection can explicitly communicate their intended maneuver (ingressing/egressing lane) in forms of additional information included in extended CAMs. By analysing this information, the traffic light controller can more effectively and precisely compute




its phases for the benefit of a smoother overall traffic flow (Traffic light Info optimizations with V2I). A more precise computation of traffic light phases can additionally enable stable traffic light signal plans and communication of speed advices to be automatically followed by receiving automated vehicles (Automated GLOSA).

In addition to the above mentioned examples, the IMAGinE project [18] is defining a Maneuver Coordination Service (MCS) that uses exchange of V2V messages for the unambiguous coordination of CAVs’ Maneuvers [19]. Coordination is needed whenever a CAV’s future planned trajectory is in conflict with the planned trajectory of another CAV that possesses the right of way. In this situation, the MCS allows both CAVs to exchange information about their currently planned and desired trajectories, which implicitly enables a negotiation solving the conflict. Through the use of the MCS, a number of cooperative automated driving applications are possible such as Cooperative Merging, Cooperative Lane Change, Cooperative Overtaking just to mention a few.

The IMAGinE MCS concept is focused on V2V interactions only. Extending this approach, the TransAID and INFRAMIX projects [20][26] envision that the road infrastructure can coordinate CAVs‘ maneuvers in a centralized way, or at least influence their behavior, when needed in order to improve the overall traffic flow. This is done by an I2V coordination service, where the infrastructure can send individualized suggestions to CAVs (e.g. lane change advice or speed advice). Besides this, TransAID takes into account the possibility for CAVs to interrupt their automated status at any time and identifies the need to announce this Transition of Control (ToC) intention to the surrounding road users (ToC Notification).

It is envisioned that in the Day3+ phase, cooperative services like the above mentioned will be leveraging advanced C-ACC applications like C-ACC strings where follower vehicles gets longitudinally and laterally automatically controlled, or management of C-ACC strings including dynamic joining and leaving vehicles, string break-up, and so on.

Moreover, while in the previous deployment phases protection of VRUs is covered with applications where the VRUs have just a “passive” role (being detectable by vehicles or infrastructure sensors and advertised via CPMs), in the Day 3+ phase, VRUs are expected to play a more “active” role. VRUs are expected to be in fact V2X-equipped and be able to explicitly announce their presence whenever necessary (e.g. upon detecting that a vehicle is approaching in a dangerous way [21]).




3 The Day 2 vision

This section is divided into two subsections. The first one highlights the enhanced Day 2 services and some examples of use cases that can be supported by them. The second subsection lists the Day 2 technology requirements that have to be addressed for the realization of those services and use cases.

3.1 Day 2 services and use cases

Following the representation adopted in Figure 2-1, this section provides a list of expected Day2 services and some example of associated use cases. Each of the following subsection starts with a description of the service(s) and is complemented by some examples of use cases enabled by the service(s). At the end of each use case description, a list of technological requirements is included. This list describes the needed technologies that the Day 2 system should support in case of going beyond the capabilities of the Day 1 system.

3.1.1 Improved Infrastructure-support services

3.1.1.1 Definition

As already mentioned in Section 2.1, in the Day 2 deployment phase Infrastructure services will be extended to support prioritization of special categories of vehicles as well as for allowing more precise I2V warning and information applications, also with the intention to start leveraging vehicle automation.

3.1.1.2 Use cases

3.1.1.2.1 Long-term RWW

In comparison to short-term road works, long-term road works can include significant changes in road topology: not only lane closings but also usage of additional lanes from the other driving direction and/or an additional lane next to the original road. They may also include multiple shifts of topology along the way, including different driving speed regulations.

Such a complex scenario cannot be adequately described by the message formats used for short-term road works warning (DENMs) but needs other message formats, possibly multiple messages, which need to be semantically linked.

A candidate message format supporting this additional information is the IVIM. In this context, the Austrian Eco-AT project is currently investigating a suitable profiling of the IVIM to support the requirements of this use case [15]. Here, a very important requirement is that this I2V Use Case be backwards compatible, meaning that receiving vehicles belonging to the earlier Day 1 deployment phase are still informed about the roadworks via DENMs. In order to fulfil this requirement, long-term roadworks shall be notified, in addition to the IVIM, with a DENM including the roadworks information expected by a Day 1 vehicle.

Additionally, for vehicles that are capable of processing the newly available long-term roadworks information, the IVIM and the DENM shall be linked together. This possibility is not currently supported by the current standards, and hence needs to be enabled with backwards compatible standard extensions.

3.1.1.2.2 Support for (semi) automated functions

Starting from Day2 deployment, the infrastructure will support single vehicles and vehicles in CACC strings or platoons with information about applicable regulations which are specific to one or more automation levels. Such information may include clearance information for a certain sections to automated driving, as well as minimum, maximum or recommended speed, and minimum and recommended inter-vehicle distance, per automation level. This information will be provided by an extension of the IVIM [27].




3.1.1.3 Technological requirements

From the above descriptions, technological requirements associated to improved infrastructure support services can be identified from the open issues listed as following. They are classified according to the addressed technological level.

APP: For the implementation of new infrastructure-related applications (e.g. Long-term RWW), identify which information needs to be provided, and of what quality, from that currently supported by the available standard message sets (e.g. IVIM, DENM).

APP: For the implementation of new infrastructure-related applications (e.g. Long-term RWW), identify which additional information needs to be provided, and of what quality, which is not included in the definitions of the currently available message sets

APP: For the implementation of new infrastructure-related applications, make sure that provision of new information does not prevent reception of information expected by older generation’s V2X systems.

APP: For the implementation of new infrastructure-related applications, identify a backwards-compatible method to link different messages (e.g. IVIM, DENM) when intended to describe the same event.

3.1.2 Cooperative Awareness and Decentralized Notification Service extensions

3.1.2.1 Definition

The CA and DEN service are defined in the ETSI ITS standards [10] and [11], respectively. Thanks to their broadcast nature and support for transmission of relevant information such as vehicle position and dynamics, as well as hazards location and characteristics, CAMs and DENMs will support future vehicular applications with increasing level of automation. It can in fact be imagined that the information contained in these messages can be reused not only for triggering drivers’ warning, but also to support automated reactions in case of danger or control for increasing passengers’ comfort. Although CAMs and DENM already contain the fundamental information for running use cases relevant for semi-automation, new possibilities can be opened by extending these messages with additional set of information as well as by modifying their transmission properties (different rate and/or channel).

Taking into account PTWs, although many parts of CAM and DENM can also be adopted, both message types have data fields that are not suitable for PTWs. The steering angle is just one example to show the difference of PTW dynamics for prediction purpose: whereas the curvature a car drives can be easily determined by the steering angle, the curvature of a motorcycle is basically determined by the PTW’s speed and the lean angle.

In this context, the following subsections will highlight some applications that can take advantage of extensions of CAMs and DENMs in the Day 2 deployment phase.

3.1.2.2 Use cases

3.1.2.2.1 C-ACC

One of the applications that will highly benefit from an extended CAM is Cooperative Adaptive Cruise Control (C-ACC). C-ACC is a driving assistance system that adjusts automatically the

vehicle speed to keep a target time gap t with the preceding vehicle, while keeping a minimum safety distance d from it at a given velocity v, as shown on Figure 3-1 [22].




Figure 3-1 Example use case scenario for C-ACC [22]

C-ACC makes use of data received from other vehicle ITS stations and/or from roadside ITS stations, in addition to the vehicle on-board sensors. Based on these, the C-ACC system automatically determines the optimal ego-vehicle speed and acceleration, and accordingly transmits control commands to the longitudinal control systems. In addition and optionally, the C-ACC application may be operating simultaneously with other in-vehicle assistance systems or applications, such as pre-crash system, lateral control system, etc. [22].

The main motivation of C-ACC is to further reduce the time gap between vehicles compared to an Adaptive Cruise Control (ACC) system and to improve the response to the speed variation of the target vehicle. This would bring benefits to the driver (e.g. enhanced comfort), road operator (e.g. increased road capacity and traffic efficiency) and potentially to society (e.g. increased road safety, reduction in traffic jams and environmental benefits).

Both the AutoNet2030 [16] and the MAVEN research projects [17] proposed an extension of the standardized CAM with new automatedVehicle high and low frequency containers to support several cooperative automated driving applications, including C-ACC string and convoy driving. These extensions are the basis for a pre-standardization study of the C-ACC application within the ETSI ITS Working Group 1, which is currently drafting the technical report ETSI TR 103 299 [22].

Extended CAMs for C-ACC are expected to be transmitted at a generally higher frequency than standard CAMs, such as a fixed frequency of 10 Hz or at a variable frequency between 10 and 30 Hz, depending on the target distance to the preceding vehicle [22]. It is also under consideration whether extended CAMs are transmitted on a service channel, instead of the control channel as standard CAMs.

The new data fields which are proposed to extend the standard CAM are the following [22]:

- AutomatedVehicleContainerHighFrequency: measured time gap and azimuth angle between the ego-vehicle and its preceding vehicle.

- AutomatedVehicleContainerLowFrequency: target speed and longitudinal acceleration of ego-vehicle, braking capacity, target distance to preceding and following vehicles, predicted path of the ego-vehicle, group ID and measured speed of the C-ACC string, etc.

- RoadSideSupportedAutomatedDriving: recommended target time gap for C-ACC vehicles, starting position and lane where the C-ACC service is available, recommended speed limit for C-ACC vehicles, length limitation of C-ACC strings, etc.

A list of functional requirements for the C-ACC application for each layer of the C-ITS stack can be found in the report ETSI TR 103 299 [22].

3.1.2.2.2 PTW applications




A typical example of Day 2 application for PTW is the Motorcycle Approaching Warning (MAW): MAW is focusing on the same scenarios of the Motorcycle Approach Information application, but the respective vehicles will be warned about a dangerous situation only in case of a potential collision with a PTW. As a result, both the PTW and the other vehicle must be able to calculate the probability of a collision (based on the “time-to-collision”).

For PTW applications, the two most dangerous scenarios for PTWs are considered: The intersection scenario, and left turn manoeuvers at intersections with oncoming traffic. Both scenarios are illustrated in Figure 3-1. In the intersection scenario (a), a PTW and a car approach an intersection from different directions. This is a potentially dangerous situation, because there may be a building (blue) at a corner of the intersection. Hence, the visibility of both the motorcycle rider and the car driver is limited and they may not see each other. In the same figure, (b) shows the left turn scenario at an intersection with oncoming traffic. Here, the motorcyclist wants to drive ahead, whereas the blue car wants to turn left at the intersection. This is also a dangerous situation with a high probability of collision between motorcyclist and the driver of the blue car, especially if another (grey) car may hide the motorcycle, so the driver of the blue car probably cannot see the motorcyclist.

Figure 3-1: (a) Intersection scenario, (b) Left turn with oncoming traffic

Both situations are highly dangerous for PTWs, because they may result in potential collisions between PTW and car. The following table indicates how the MAW differs from the MAI for the same scenarios.

Intersection Scenario Left Turn at Intersection

MAI In case of approaching an intersection, both the car and the motorcycle calculate the relative distance between them. If this distance falls below a respective

In this scenario, MAI will inform the motorcyclist and the car driver if the car driver sets the turn lever to left, and the relative distance between car and motorcycle falls below a respective




threshold, both the car driver and the motorcycle rider will be informed. If the car driver then reacts appropriately (e.g., by releasing the gas pedal or by braking), the information will be canceled. The scenario is considered until both the motorcycle and the car passed the intersection safely.

threshold. If the car driver then reacts appropriately (e.g., by releasing the gas pedal or by braking), the information will be canceled on both the motorcycle and the car. This scenario is considered until both the motorcycle passed the car and the car turned safely to the left.

MAW In contrast to MAI, MAW will warn the car driver and the motorcyclist only in case of a potential collision. Therefore, both the car and the motorcycle calculate the “time to collision” (TTC) for the potential collision area. If TTC falls below critical threshold (i.e., a collision may occur), both the car driver and the motorcyclist will be warned via their HMI. If the car driver will react appropriately, both warnings will be canceled. This situation is over when both the motorcycle and the car have passed the intersection safely.

In contrast to MAI, MAW will warn the car driver and the motorcyclist only in case of a potential collision. If the car driver sets the turn lever to the left in this scenario, both the motorcycle and the car will calculate the TTC for the potential collision area. If TTC for this situation falls below a respective threshold (Twarn in Figure 3-2), the situation is considered as critical and the car will warn the driver about the approaching motorcycle from the opposite direction. Additionally, the motorcycle will warn the car driver with audio-visual features (e.g., warning LED bars, horn, etc.), as illustrated in Figure 3-2. If the car driver will react accordingly, the warnings will be canceled. After the motorcycle passes the car safely, the car will turn to the left, and the situation is finished.

Table 3-1: Behavior description of MAI/MAW in the two scenarios.

Figure 3-2: Warning situation for intersection left turn with oncoming traffic.

There are other factors, which are relevant for the notification of the driver in the receiving vehicle. The MAW aims to improve intersection safety significantly for PTWs, because it identifies the critical situations, which may result in an accident if the car driver does not react to this situation. As already mentioned, MAW as a Day 2 application will warn only in critical situations. However, this also means that the information cannot be based on the relative distance only, but has to leverage several other types of information from the situational context. As shown in Figure 3-3, MAW also has to consider additional traffic rules (here: right of way rule for the PTW), the current lane used by the car and the PTW, the exact position of both the car and the PTW, including a prediction of the expected path for car and PTW.




Figure 3-3: Example for day 2 MAW warning in critical situations.


From the above descriptions, technological requirements associated to extensions of CAMs and DENMs can be identified from the open issues listed as following. They are classified according to the addressed technological level.

APP: identify which information is needed, of what quality, and which extensions to CAM and DENM are required in order to support MAW

APP: identify needed quality of the information necessary for MAW, especially in terms of localization accuracy and vehicle dynamics: reliable warning functionality also results in more stringent requirements. Such requirements may be even stricter compared to cars, because they are needed in order to describe respective parameters which can be easily determined by cars (such as the curvature).

3.1.3 Collective perception

3.1.3.1 Definition

Collective Perception allows the exchange of perceived environmental information among ITS stations, in the form of objects (other vehicles, obstacles, etc.) detected by the on-board sensors of the ITS station. In contrast to Cooperative Awareness, an ITS station broadcasts information about its neighbourhood rather than about itself. This information exchange allows vehicles to “see” their environment beyond their sensors range and can improve the quality of their




environmental model. Collective Perception enhances the vehicle’s cooperative awareness and safety, enabling applications such as overtake warning, enhanced intersection collision warning, accounting with detection of non-connected road users (such as pedestrians, cyclists or legacy vehicles) and safety-critical objects (such as obstacles on the road) which are outside the driver’s view and/or beyond the range of the vehicle’s on-board sensors.

The sharing of object data among ITS stations is done via Collective Perception Messages (CPMs), specified in the Collective Perception Service which is currently under standardisation within the ETSI ITS Working Group 1 [13][14]. CPMs are broadcasted periodically, with a variable transmission frequency depending on the detection of new objects and change in their position, speed and heading.

A CPM is composed of a common ITS Protocol Data Unit (PDU) header and multiple containers, as shown in Fig. 3-4 [13]:

- The Management Container provides information regarding the originating Station Type and the Reference Position.

- The Station Data Container contains the dynamic information of the originating vehicle or detailed information of the originating RSU.

- The Sensor Information Container provides descriptive information about the sensory capabilities of the sending ITS station, including the opening angle and range of the individual sensors mounted to the ITS station.

- Finally, the Perceived Object Container provides a detailed description of the dynamic state (distance, speed, etc.) and properties (dimensions, classification, etc.) of the detected objects, in a coordinate system relative to the sending station.

Figure 3-4: General structure of a CPM [13]

The following subsection describes some applications unveiling the potential of the CP service in the Day 2 deployment phase.

3.1.3.2 Use cases

3.1.3.2.1 Cooperative Merging on Highways

One of the use cases where Collective Perception brings a clear added value is the cooperative merging on highways. In areas where lanes end or merge, drivers must change lanes under spatial and time constraints. Different tasks such as looking for a suitable gap in traffic or




signaling the wish to change lanes are accomplished simultaneously in part. The high complexity of this driving task often leads to accidents at these junctions.

The research project IMAGinE [18] is designing a cooperative merging function based on V2X communication (see Figure 3-5) in which he range of the on-board environmental sensors is increased by means of Collective Perception.

As shown in Figure 3-5, the red car wants to merge onto the highway. The non-connected grey cars may not be detected by the red car’s on-board sensors, since they are driving in a different lane. Therefore, the red car may have an incomplete environmental model, which might result in an unsafe merging maneuver. However, the blue car detects the grey car in front of it and sends its data to the red car via a CPM (orange arrow). The red car then incorporates the grey car into its environmental model and can perform a safe merge maneuver. One of the main technological requirements for this use case is a large communication range, in order to allow merging vehicles to receive CPMs from oncoming vehicles several hundred meters behind the merging lane, thereby allowing sufficient time for the merging vehicle to update its environmental model and adapt comfortably its merging maneuver, if required.

Figure 3-5: Sample scenario of the cooperative merging on highways use case. The blue car sends a CPM (orange arrow) with information on the detected grey car.

3.1.3.2.2 Cooperative Overtaking or Rural Roads

Another use case where Collective Perception plays a key role is cooperative overtaking on rural roads. During an overtaking maneuver on a road with one driving lane per direction, it is often difficult to recognize dangerous situations in a timely manner and evaluate the behavior of other road users due to limited fields of view.

The research project IMAGinE [18] is developing technical solutions that allow vehicles to exchange information about objects in the environment so that drivers can be warned about oncoming traffic during overtaking maneuvers. In case of a sudden danger, both overtaking and oncoming cars can contribute to accident prevention by cooperatively executing the collective perception and triggering warning application or automated reactions.

In Figure 3-6, the white car is trying to overtake the truck in a two-way rural road. The oncoming non-connected red car is not detected by the white car’s sensors, since their field of view is obstructed by the truck in front. The truck detects the red car with its own on-board sensors and sends its information to the white car using a CPM. The white car then becomes aware of the oncoming vehicle and can choose to postpone its overtaking maneuver until the opposite lane becomes free.




One of the main technological requirements for this use case is a short latency, due to the high relative velocity of the vehicles travelling in opposite directions. Since CPMs contain the object dynamics data relative to the sender, they need to reach the receiver vehicle with a very short latency after the object measurement. Otherwise, the receiver vehicle would include outdated data in its environmental model, which would lead to a suboptimal application outputs.

Figure 3-6: Sample scenario of the cooperative overtaking on rural roads use case. The truck sends a CPM (yellow arrow) with information on the detected red car.


APP: identify message generation rules capturing expected usefulness of transmitted information at receivers based on perceived dynamic properties and confidence of detected object

APP: identify criteria for object extraction from sensing framework (e.g. object extraction from single sensor or from sensor fusion, based on minimum confidence level)

APP: define standardized quality/confidence levels that are transversal for distinct sensing framework implementations

APP: based on afore-mentioned study, define a complete set of data elements to be exchanged to perform the CPS, with each data element characterized by meaningful ranges of settable values (e.g. is information about V2X connectivity capability of a detected object needed to be additionally exchanged?)

APP: identify the best strategy for message dissemination, e.g. reusing existing service CAM, defining new service

COM/ARCH: identify spectrum requirements and priority level compared to other existing services

COM/ARCH: identify best channel for CPM dissemination, e.g. static channel allocation or using parallel channel based on load

COM/ARCH: identify best approach for CPM inclusion in DCC




3.2 Short-term technology requirements

Based on the above described services and use cases, this section collects the technology requirements to be addressed by dedicated activities at the different C2C-CC WGs.

3.2.1 Application and Application-related facilities layer requirements

Need to modify triggering conditions for Day 2 applications at the transmitting side (e.g. extensions of Day1 for PTW applications)

Need to define suitable generation rules for new service messages specific for distinct services

Need to identify application requirements at the receiving side (max latency, frequency, reliability requirements, applicable range) to dimension the behaviour of the transmitting system

Need to define quality indicators and minimum quality level requirements for the information to be disseminated by the Day 2 services (e.g. for collective perception: requirements on individual sensor sources or on sensor fusion, for IVI and in general topology-related information: level of precision to gradually support vehicle automation)

Need to investigate the need of using SAM (service announcement message) related to MCO (multi-channel operation)

Need to identify functional safety standards extensions

3.2.2 Security requirements

Evaluate pseudonym changing rules, based on interim test results from Day 1 as well as added requirements for Day 2.

Security Management o Required misbehaviour detection and handling. o Required revocation handling. o Required support for crypto agility capability to update algorithms, curves, and

key sizes. This includes update of related security processes (key management systems, protocols, etc.)

o Security requirements to support software and firmware update management features

New Security Requirements

o Confidentiality of the control message

o Requirements for end-to-end enrolment process

Require to evaluate the security risk and security controllers of hybrid solutions.

Require to update the Risk Assessment on the new features and the updated system

Required enhancements for a mechanism that verifies that the SW has not been tampered with

Require to define isolation mechanism between SW modules (software as well as hardware based solutions).

Require to assess relevance of ISO standard (e.g. 21434)

3.2.3 Communication-related Facilities and Networking requirements

Need to extend congestion control management at facilities layer

Need to extend congestion control to offload the available channels in the context of multi-channel operation

Need for definitions for application priority management in the context of multi-channel operation and facilities layer congestion control




Need to define suitable functionalities to reduce the channel occupation at facilities level by trying to aggregate information about similar or concatenated events that are concurrently transmitted (e.g. one DENM only to transmit information specific to Impact Reduction Container (IRC) and emergency braking)

3.2.4 Access layer requirements

Need for an MCO approach to distribute different services on different channels in a coordinated way. This includes identifying a proper solution from the HW (e.g. multi transceiver) and SW (rules for possibly switching dynamically on distinct channels, using SAMs) needs

Requirements as set for IEEE Next Generation Vehicular (NGV) (including mechanism for coexistence between ITS G5 and NGV while ensuring backward compatibility)




4 The vision beyond day 2

While the Day 2 phase takes advantage from the presence of vehicles with enhanced sensing capabilities to deliver use cases adopting shared sensor data, the rising introduction of automated driving will create the basis to support sharing of vehicle control decisions. Automated driving path planning algorithms continuously adjust their trajectories based on the up-to-date and predicted knowledge of the nearby environment achieved by perception and prediction algorithms. Nowadays, automated vehicle trajectories are calculated in a conservative way. They account for increased space/time gaps because of using on-board sensors that can only “interpret” the behaviour of the surrounding detected traffic participants (other vehicles or VRUs) in the immediate future. With the use of V2X, automated vehicles can continuously and explicitly share their planned trajectories or manuevers. In this way, receiving vehicles can use this information as an additional input to calculate more reliable trajectories allowing reduced gaps. In case of trajectory conflicts, cooperative automated vehicles can talk to each other to coordinate the actions to be undertaken at each vehicle. All this will enable cooperative automated driving scenarios where vehicles can autonomously anticipate or prevent dangerous situations, react faster to unexpected dangers, and drive closer to each other, thus increasing the road traffic safety and efficiency.

In this context, the C2C-CC vision beyond Day 2 is to deliver V2X services to foster vehicle automated functions relying on the knowledge of other vehicles’ intentions, trajectories and maneuvers. In some cases for local automated functions, it might be sufficient to rely only on knowledge of other vehicles’ future trajectory or maneuver intentions. In some other cases, on the other hand, two or more vehicles will need to negotiate their maneuvers when a conflicting situation arise (e.g. lane merging) or when required by the application (e.g. dynamic management of a C-ACC string). Compared to the day 2 deployment phase, the vision for the Day3+ subsequent phases does not yet rely on conceptually consolidated V2X services. On the contrary, the envisioned services and associated use cases are based on theoretical or prototypical concepts that have been proposed in several R&D projects following various approaches.

4.1 Intention sharing and negotiation: the first steps towards cooperative automated driving

The use of V2X to support cooperative automated driving has been and is being demonstrated in a number of R&D activities.

As a first and representative example, the AutoNet2030 research project [16] designed and demonstrated a Cooperative Lane Change Service, which plans, prepares and executes a cooperative lane change by one or a group of subject vehicles which aim to change their driving lane [15]. A particular lane change is initiated and coordinated by an originating station, which can either be the lead subject vehicle or a nearby roadside unit. Subject vehicles are automated vehicles that plan in advance a lane change by selecting a geographical target area to which they intend to change to. The target area is selected based on the road topology (e.g. the merging area of a highway on-ramp) or an obstacle on the road (e.g. roadworks). The Cooperative Lane Change Service does not aim to reserve a fixed target area exclusively for certain subject vehicle(s). This approach might rule out other subject vehicles to perform a similar lane change during the reserved period. Instead, a negotiation process is started which involves a relative target area in front of a target vehicle which will be driving in the target area during the lane change. Figure 4-1 shows the target area of two subject vehicles entering the highway and the corresponding target vehicle.




Figure 4-1: Lane change of subject vehicles in target area

A cooperative lane change has three phases: search, preparation and execution:

- Search phase: the originating station tries to find potential target vehicles. A target vehicle is a vehicle in the target area during the target lane change time, and which is capable of opening the required gap for the subject vehicle(s) allowing them to change their lane in front of the target vehicle.

- Preparation phase: the originating station requests a target vehicle to open the required space gap to facilitate the lane change. The subject vehicles physically align to the space opened by the target vehicle in order to execute the lane change.

- Execution Phase: the subject vehicle(s) and target vehicle automatically perform the lane change while using perception sensors and V2X communication to ensure its safe execution.

The Cooperative Lane Change Service is based on the exchange of request/reply Cooperative Lane Change Messages (CLCM) among the involved ITS stations. The CLCM includes data related to the planned lane change maneuver, such as the subject vehicles and target vehicle, the target area and lane, the target time and speed at which the lane change is performed, and the minimum required gap. It is proposed that the involved ITS stations in a lane change maneuver broadcast CLCMs periodically with a transmission frequency of 2 Hz.

Another example of how V2X messages can include planned maneuvers to support automated driving functionalities is provided by the MAVEN project [17]. The objective of MAVEN is to deliver solutions for managing Cooperative Automated Vehicles (CAVS) or a platoon of CAVs at signalised intersections and intersection corridors with the aim of increasing traffic efficiency and safety. These solutions include, among others, Infrastructure-to-Vehicle (I2V) interactions for optimal coordination of vehicle transit at cooperative intersections (CIs). In this context, CAVs and CIs interact by executing a negotiation process in which speed change advisory and lane change advisory are provided following the approach depicted in Figure 4-2 MAVEN I2V interactions.




Figure 4-2 MAVEN I2V interactions

As first phase of the negotiation (1), an isolated (not belonging to a C-ACC string) CAV and/or a C-ACC string of CAVs continuously transmit information describing intentions (like the planned route at intersection) or vehicle/string characteristics (like desired speed, string size, etc.). Accordingly, the CI updates its queue model and calculates new infrastructure advisories that result in transmitted suggestions for CAVs or platoons to adapt speed and/or change lane (2). In the last stage of the negotiation, CAVs and/or strings communicate if the suggestions can be executed by updating their own transmitted messages (3). This feedback can be used by the CI to put priority at the validity of the advice, e.g. ensure a stable time to green prediction. If this would not be prioritized, the traffic light controller would recalculate the timing schedule every second, resulting in constant acceleration and deceleration for the addressed vehicles.

To allow the above mentioned use case, MAVEN proposes I2V and V2I communications services for intersection/corridor management which enable coordination/scheduling (I2V) and probing (V2I) of CAVs. For the first purpose, MAVEN has introduced a new profiling of the SPaT service supporting lane-specific speed advices, and developed a novel I2V service for lane change advisory at road intersections. For the second purpose, extensions of the standard ETSI ITS CAM are provided. These allow CAVs to explicitly communicate the planned intentions to the infrastructure and provide feedbacks on the compliance of the advised speeds or lane changes (explicit probing). The lane change advisory services uses LAM (Lane change advisory messages) to indicate to a specific target vehicle in the target lane that it should move together with some supporting information like optimal time and distance from the stop line to start the lane change maneuver. The MAVEN extended CAMs adopt a MAVEN-defined SpecialVehicle container called MAVENAutomatedVehicleContainer including information like CAV and/or string features (planned route in terms of ingressing/egressing lane, desired speed, platoon ID, participants, etc.) that can be reused by CI for its intersection traffic coordination. Thanks of the use of an optional SpecialVehicleContainer, the MAVEN CAM extensions are backward compatible: Day1 vehicles can ignore them while still reusing the rest of the CAM message. Interoperability with cooperative infrastructure is also fostered by the MAVEN services: many of the data fields and elements contained in the CAM extensions as well as in the LAM belong to the SAE J2735 vocabulary [24].

4.2 Maneuver Coordination for seamless cooperative automated driving

The previous section has shown how the use of ad-hoc messages can support individual use cases where cooperative automated driving is applied in confined areas or situations. As the level and penetration of vehicle automation grows, it can be thought that a V2X service to support seamless coordination of CAVs in every situation can be adopted.

As previously mentioned, the IMAGinE project [18] is developing V2X solutions for allowing the execution of cooperative maneuvering between CAVs. Based on this approach, the ETSI TC ITS is currently specifying a Maneuver Coordination Service (MCS) to generalize its adoption [19].

The current MCS concept is exclusively based on V2V interactions and consists of a three stage process. First, the need for a given maneuver coordination is detected. Second, the type of coordination is agreed upon by the involved partners. Finally, the coordinated maneuver is executed. Coordination between CAVs is needed whenever a CAV wants to perform a maneuver which collides with the future planned trajectory of another CAV which possesses the right of way. In this situation, both CAVs can communicate and negotiate. The negotiation of a coordinated maneuver is governed by the right of way rules. The CAV that possesses the right of way must agree to modify its future trajectory. Otherwise, the coordinated maneuver will not be executed.




In order to detect the need for coordination, all CAVs continuously broadcast a Maneuver Coordination Message (MCM) including the “planned trajectory”. In this way, a CAV can compare its planned trajectory with the received trajectories and compute if these intersect. In that case, vehicles without the right of way will need to modify their planned trajectories. In order to negotiate a coordination of maneuvers, a new trajectory is introduced in the MCM and referred to as “desired trajectory”. A CAV that detects a need for coordination can send a desired trajectory together with the planned trajectory. At the receiving side, the presence of a desired trajectory is interpreted as a request for coordination. Any CAV that receives a desired trajectory will determine if it is capable of modifying its planned trajectory to allow the transmitting CAV to follow its desired trajectory. In case of holding the right of way, the receiving CAV has to also determine if it is willing to leave way. If the receiving vehicle agrees with the coordination, it will modify its planned trajectory accordingly. Once the transmitting vehicle receives the new planned trajectories from the surrounding CAVs, its desired trajectory will become its new planned trajectory in the MCM. Note that this can imply a cascade process where, in order to allow a desired trajectory of another CAV, a CAV must send a desired trajectory itself.

Figure 4-3 shows an example of coordinated maneuver executed by employing MCMs. In the top subfigure, the red CAV wants to overpass a broken down vehicle. However, it cannot directly update its planned trajectory (in green) because the new trajectory (in yellow) would intersect with the planned trajectory of the grey CAV, which possesses the right of way. For this reason, the red CAV sends a desired trajectory (in yellow) in the MCM in order to request for coordination. The receiving grey CAV receives the desired trajectory and, even if it has the right of way, it decides to cooperate by adjusting its planned trajectory (reducing its current speed). This allows the grey vehicle to employ its desired trajectory as a planned trajectory as shown in the second subfigure.

Figure 4-3 Example of cooperative maneuver execution employing the MCM [25]

The current MCS is focused on V2V interactions only. In some cases, this can lead to decisions that could negatively affect to the traffic flow and safety. Figure 4-4 shows one of these cases.




In front of a road works area, vehicles on the left lane need to merge to the right lane in order to overpass the road works. However, the vehicles on the right lane have right of way. Therefore, if the CAVs on the right lane are just “automatically” respecting the traffic rules, they will not leave way and modify their planned trajectories. As a consequence, all the vehicles on the left lane would get stuck in front of the road works area.

Planned Trajectory Desired Trajectory

Road Works Area

Figure 4-4 Example of situation challenging the V2V MCS proposal [20]

In this context, the infrastructure can play an important role by providing suggestions to the CAVs so that they can take better decisions (i.e. more efficient decisions in terms of the overall traffic flow). For example, in the situation described in Figure 4-4, an authorized RSU could coordinate the merging of the vehicles in a single lane by temporary giving the right of way to vehicles on the left lane. In other situations as described by TransAID [20], the infrastructure could send suggestions to individual CAVs (e.g. lane change advices or speed advices) in order to increase the overall traffic flow and safety. On the contrary, the INFRAMIX project [26] envisions that the road infrastructure could send policy suggestions to all CAVs like gaps to be maintained with preceding vehicles in order to favour merging of vehicles at highway entrances. The TransAID project proposes to extend the current ETSI MCS approach by allowing the road infrastructure to participate in the MCS service. This is done by proposing an MCM format differentiating between MCMs sent by a vehicle and MCMs sent by the infrastructure. The vehicle is envisioned to send MCMs including their future planned and desired trajectories. Moreover, in order to notify about situations where control is given back to the driver, Transition of Control (ToC) and eventual Minimum Risk Maneuver (MRM) are also included. On the other hand, the infrastructure is envisioned to send MCMs including information about coordinating local traffic decisions if needed. This is done by transmitting generic vehicle advice data field to individual CAVs. This generic advice can include different specific advice types (speed, lane change, gap keeping and the ToC advices). On the contrary, INFRAMIX envisions the road infrastructure to adopt IVIM extensions aimed at addressing all CAVs in an equal way.




5 Appendix 1

5.1 Sample use case list

ID Name Description Category Communication pattern

Expected deployment phase

Related projects

References

EEBL Electronic Emergency Break Light Warning

This use case consists for any vehicle to signal its hard breaking to its local followers. In such case, the hard braking is corresponding to the switch on of emergency electronic brake lights.

Safety V2V Phase 1 SimTD, SCOOP@F

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 C2C-CC, "Triggering Conditions and Data Quality - Dangerous Situation"

EVAW Emergency Vehicle Approaching Warning

This use case allows an active emergency vehicle to indicate its presence. In many countries the presence of an emergency vehicle imposes an obligation for vehicles in the path of the emergency vehicle to give way and to free an emergency corridor.

Safety V2V Phase 1 SimTD Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 C2C-CC, "Triggering Conditions and Data Quality - Special Vehicle Warning"

AWC Adverse Weather conditions

This use case informs vehicles of any hazardous location either temporary or permanent (i.e. long term). (including Adverse Weather Conditions)

Safety V2V, I2V Phase 1 SimTD, SCOOP@F, Eco-AT, C-Roads

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06) C2C-CC, "Triggering Conditions and Data Quality - Adverse Weather Conditions", C-Roads, Common C-ITS Service Definitions

PCSW Pre-crash sensing warning

Prepare for imminent and unavoidable collision by exchanging vehicles attributes after unavoidable crash is detected.

Safety V2V Phase 1 ETSI TR 102 638 V1.1.1 (2009-06) C2C-CC, "Triggering Conditions and Data Quality – exchange of IRC"

PVD Probe Vehicle Data Vehicle information is received by road side units and forwarded to traffic management centres for detection of traffic situations

efficiency V2I Phase 1 ITS-Korridor, ECo-AT

Report DG MOVE MOVE/C.3./№ 2014-794, Eco-AT consortium, "SWP 2.1 Use Cases, CAM Aggregation, WP 2 – System Definition

RWW ST

Road Work Warning (Short term)

Via road infrastructure to vehicle communication, provides information on current valid roadwork and associated constraints. The information can be send by a standalone trailer, by a trailer connected with the traffic management center (which increases the set of disseminated information), or by an RSU backbone-connected with the traffic management center

Safety I2V Phase 1 SimTD, ITS-Korridor, SCOOP@F, ECO-AT, C-Roads

"Message Set and Triggering Conditions for Road Works Warning Service" from the Amsterdam Group, ETSI TR 102 638 V1.1.1 (2009-06) Eco-AT consortium, "SWP 2.1 Use Cases, Road works warning, WP 2 – System Definition; C-Roads, Common C-ITS Service Definitions




SSVW Slow or stationary Vehicle Warning

Slow-VW: This use case consists from any slow vehicle to signal its presence (vehicle type) to other vehicles. Stationary-VW: This use case consists for any vehicle being dangerously immobilized on the road (consecutive to an accident, a breakdown or any other reason) to alert other approaching vehicles of the risk for them associated to this dangerous situation.

Safety V2V, I2V Phase 1 SimTD, ECO-AT

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06) C2C-CC, "Triggering Conditions and Data Quality – hazardous location notification" Eco-AT consortium, "SWP 2.1 Use Cases, other DENMs, WP 2 – System Definition; C-Roads, Common C-ITS Service Definitions

RLVP Red light violation protection

This use case allows warning or protecting affected users that they are about to violate a red signal and increase the risk of an accident.

Safety I2V Phase 1

SimTD, Eco-AT, C-Roads

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06) Eco-AT consortium, "SWP 2.1 Use Cases,red light violation warning, WP 2 – System Definition; C-Roads, Common C-ITS Service Definitions

TJAW Traffic Jam Ahead Warning

This use case allows any vehicle or roadside station to warn about the presence of a traffic Jam ahead

Safety V2V, I2V Phase 1 SimTD, SCOOP@F, Eco-AT, C-Roads

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06) C2C-CC, "Triggering Conditions and Data Quality - traffic jam", Eco-AT consortium, "SWP 2.1 Use Cases, other DENMs, WP 2 – System Definition; C-Roads, Common C-ITS Service Definitions

CGR Co-operative glare reduction

This use case enable a capable vehicle from automatically switching from high-beams to low-beams when detecting a vehicle arriving in the opposite direction.

Safety, Comfort

V2V Phase 1 ETSI TR 102 638 V1.1.1 (2009-06)

TSPR Traffic Signal Priority Request/Preemption

In a signalized environment (e.g. intersection) vehicles and the infrastructure interact for requesting/preempting and releasing traffic light signal priority (public transport) or signal preemption (public safety). The service may not only be requested for the approaching signalized it but also for a sequence of e.g. intersections along a defined traffic route.

Efficiency, Safety

V2I/I2V Phase 1 C-Roads Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794 ETSI TS 103 301, C-Roads, Common C-ITS Service Definitions

ICW Intersection Collision Warning

By exchanging information about their position and dynamics two vehicle can detect the risk of an intersection collision and warn the driver accordingly

Safety V2V Phase 1 SimTD Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06)




VRUP Vulnerable Road User Protection

Provides warning to vehicles of the presence of vulnerable road users, e.g. pedestrian or cyclist, in case of dangerous situation. For Day1 application, the infrastructure can recognize the risk and send notifications to vehicles. For day 2, vehicles and infrastructure can share information about pedestrians or cyclists detected via local sensors, and let receiving vehicles detect the occurrence of risky situations associated to VRU presence

Safety I2V, V2V Phase 1 Phase2

ECO-AT, MAVEN

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06) ETSI draft TR 103 562 Eco-AT consortium, "SWP 2.1 Use Cases, other DENMs, WP 2 – System Definition;

TLI Traffic light information

A traffic light broadcasts timing data associated to its current state (e.g. time remaining before switching between green, amber, red). The vehicle displays this information in the vehicle for drivers’ usage

Comfort, safety

I2V Phase 1 ECO-AT, C-Roads

Eco-AT consortium, "SWP 2.1 Use Cases, Traffic light information – System Definition; C-Roads, Common C-ITS Service Definitions

GLOSA Green Light Optimum Speed Advisory

This use case allows a traffic light to broadcast timing data associated to its current state (e.g. time remaining before switching between green, amber, red) as well as speed advices that vehicles can follow to pass the intersection without stopping. In an alternative implementation, the vehicle computes the GLOSA locally based on the received time and phase information

Efficiency I2V Phase 1 SimTD, Compass4D, ECO-AT, C-Roads

ETSI TR 102 638 V1.1.1 (2009-06) Eco-AT consortium, "SWP 2.1 Use Cases, GLOSA – System Definition; C-Roads, Common C-ITS Service Definitions

GWI Green Wave Information

This use case allows a traffic light to broadcast timing data associated to its current state (e.g. time remaining before switching between green, amber, red) as well as indication about available green wave in addition to GLOSA

Efficiency, Comfort

I2V Phase 1

IVS In-Vehicle Signage A Road Side Unit broadcasts the current local speed limits (regulatory and contextual) and/or information on current valid traffic signs. The vehicle displays this information in the vehicle for drivers’ usage.

Safety, Comfort

I2V Phase 1 SimTD, SCOOP@F; ECO-AT, C-Roads

Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794; CEN/ISO ISO TS 19321 (2015): IVI standard, currently in revision. ISO 14823(2017): Gaphic Data Dictionary used by IVI, currently in revision ETSI TS 103 301 V1.2.1: facility layer protocol for IVI, currently in revision Eco-AT consortium, "SWP 2.1 Use Cases, In-vehicle Signage – System Definition;

MAI Motorcycle Approaching Information

Inform the driver on approaching motorcycle in selected traffic situations. This is especially useful in case of reduced visibility.

Safety V2V Phase 1 DRIVE C2X Study on the Deployment of C-ITS in Europe: Summary Report DG MOVE MOVE/C.3./№ 2014-794, ETSI TR 102 638 V1.1.1 (2009-06)




APCSW Advanced Pre-crash sensing warning

Prepare for imminent and unavoidable collision by exchanging vehicles attributes after unavoidable crash is detected. Differently from PCSW, in this case the risk of detection, as well as additional information about the imminent crash is achieved thanks to use of local sensors

Safety V2V Phase 1 Phase 2

Currently under development in C2C-CC dedicated WI

C-ACC Cooperative ACC This use case is based on the use of V2X to obtain lead vehicle dynamics and general traffic ahead in order to enhance the performances of current ACC. The infrastructure can play a role in suggesting the speed to be adopted in CACC mode as well as the point from where CACC is allowed

Efficiency V2V/I2V Phase 2 ETSI ITS TR 103 299, ETSI TR 102 638 V1.1.1 (2009-06)

C-ACC S Cooperative ACC string

Extends the CACC by allowing multiple vehicles to organize a string of C-ACC enabled vehicles

Efficiency V2V Phase 2 AutoNET 2030 MAVEN

ETSI ITS TR 103 299 Autonet2030 Deliverable D3.2 MAVEN deliverable D5.1

MAW Motorcycle Approaching warning or protection

Inform the driver about a possible collision with approaching motorcycle in selected traffic situations. In extreme cases, the vehicle can automatically react via automated braking

Safety V2V Phase 2 Currently under development in C2C-CC dedicated WI

OVW Overtaking vehicle warning

An overtaking vehicle detects the risk of collision thanks to information about vehicles coming from the other direction, which are detected by other vehicles

Safety V2V Phase 2

IMAGinE ETSI TR 102 638 V1.1.1 (2009-06) IMAGinE, deliverables

AICW Advanced Intersection Collision Warning

By receiving information about non-cooperative vehicles detected by environmental sensors, vehicle can detect the risk of an intersection collision and warn the driver accordingly

Safety V2V, I2V Phase 2

RWW LT Road Work Warning (long term)

Via road infrastructure to vehicle communication, provides information on current valid roadwork and associated constraints. The information refers to long term roadworks and can include signaling information such as forbidden overtaking, forbidden access to special vehicle categories, alternative routes, as well as topological information about modified road layouts

Safety I2V Phase 2 Currently under development in C2C-CC dedicated WI

ACACC Advanced Cooperative ACC (String)

This use case is based on the use of V2X to obtain lead vehicle dynamics and general traffic ahead in order to enhance the performances of current ACC. Compared to the normal CACC it includes support for lateral vehicle control in addition to longitudinal one

Efficiency V2V Phase 3+ MAVEN, Autonet 2030, IMAGinE

IMAGinE, MAVEN, Autoner2030 deliverables




TDAR Target Driving Area reservation

for a vehicle that is going to perform a maneuver aimed at occupying a given road section, this use case provides the possibility to notify other vehicles about the maneuver imminent occurrence

Safety V2V Phase 3+ IMAGinE, Autoner2030

ETSI Draft TS 103 561, IMAGinE, Autoner2030 deliverables

AGLOSA Automated Green Light Optimum Speed Advisory

Extends the GLOSA by implementing automated functions for adaptation to the speed suggested by the infrastructure or computed by the vehicle

Efficiency I2V Phase 3+ MAVEN ETSI TC 103 301 (draft); ISO TS 19091 MAVEN deliverable D5.1

OTLI Optimized Traffic light information with V2I

In proximity of urban signalized intersections, isolated CAVs and/or CAVs organized in CACC strings continuously transmits information describing intentions (like planned route at intersection) or vehicle/string characteristics (like desired speed, string size, etc.). By collecting this explicit probing V2I information, the traffic light controller updates its queue models and calculates more efficient traffic light phases, durations and GLOSA that are communicated to vehicles.

Efficiency, Comfort

I2V, V2I Phase 3+ MAVEN MAVEN deliverable D5.1

ToCN Transition of Control Notification

A CAV that is about to give the control back to the driver can inform other traffic participants about this possibly risky event, or about the occurrence of a minimum risk maneuver in case the driver is not reacting accordingly

safety V2V Phase 3+ TransAID TransAID Deliverable D5.1

IVRUP Improved Vulnerable Road User protection

A VRU is equipped with active C-ITS notification capabilities to alert other traffic road users or to let them automatically react to prevent risky situations

safety P2V Phase 3+

Platoon Platooning This use case is based on the use of V2X for trucks to operate safely as a platoon on a highway implementing longitudinal and/or lateral control depending on the level of automation supported by the interested vehicles

Efficiency, Safety

V2V Phase 3+ Konvoi, COMPANION, AutoNET2030, ENSEMBLE

ETSI ITS TR 103 298, ETSI TR 102 638 V1.1.1 (2009-06) Autonet2030 Deliverable D3.2 ENSEMBLE deliverables




CM Co-operative merging assistance

This use case considers that CAVs involved in a merging negotiate together the merging process to avoid collision. The road infrastructure can in special case participate in the coordination process.

Efficiency, Safety

V2V, I2V Phase 3+ AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS, TransAID

ETSI TR 102 638 V1.1.1 (2009-06) AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS, TransAID deliverables

CLC Cooperative lane change

This use case considers that CAVs involved in a lane change negotiate together the maneuvering process to avoid collision. The road infrastructure can in special case participate in the coordination process

Efficiency, Safety

V2V, I2V Phase 3+ AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS, TransAID

ETSI TR 102 638 V1.1.1 (2009-06) AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS, TransAID deliverables

CO Cooperative overtaking

This use case considers that the CAVs involved in an overtaking negotiate together the maneuvering process to avoid collision.

Efficiency, Safety

V2V Phase 3+ AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS,

ETSI TR 102 638 V1.1.1 (2009-06) AutoNet2030, IMAGinE, KoHAF, i-GAME, AFAS deliverables

CACCSM

Cooperative ACC string management

Extends the CACC by allowing multiple vehicles to organize a string of C-ACC enabled vehicles that can dynamically administrate operation such as forming, leaving, break-up, or merging strings

Efficiency V2V Phase 3+ MAVEN, IMAGinE

IMAGinE deliverables MAVEN deliverable D5.1

CToC Cooperative Transition of Control

CAVs can cooperate in organizing a transition of control such that minimizes the risks. The road infrastructure can participate in this cooperation by suggesting time or space where to safely trigger a ToC

Efficiency V2V Phase 3+ TransAID TransAID Deliverable D5.1

AGLOSA+N

Automated GLOSA with negotiation

CAVs and/or CAVs strings communicate if the GLOSA advices can be executed by updating their own transmitted messages. This feedback can be used by the traffic light controller to further refine the traffic light phase and time algorithms (e.g. to put priority at the phases whose GLOSA advices that can be applied, e.g. ensure a long enough and stable time to green for a big string of CAVs to pass the stop line before the next red starts.

Efficiency V2I/I2V Phase 3+ MAVEN MAVEN deliverable D5.1




5.2 Application-to-Message matrix

Messages

Day1 CAM

Day2 CAM extensions

Day3+ CAM extensions

Day1 DENM

Day2 DENM extensions

Day3+ DENM extensions MAPEM SPATEM

Day1 IVIM

Day2 IVIM extensions

Day3+ IVIM extensions SREM SSEM CPM MCM

Platoon messages

Ap

plic

atio

ns

EEBL

x

EVAW x

x

AWC

x

PCSW x

PVD x

RWW ST

x

SSVW

x

RLVP

x x

TJAW x

x

TSPR

x

x x

ICW x

VRUP

x

x

TLI x x

GLOSA x x

GWI x x

IVS

x

MAI x

APCSW

x

CACC (S) x x

x

MAW x x

OVW

x

AICW

x RWW LT

x x

x x

ACACC (S) x x x

x

TDAR

x

AGLOSA

x x

OTLI x x x

x x

ToCN

x

x

IVRUP x

x

Platoon x x

CM x x

CLC x x




CO x x

CACCSM x x x x

CToC x x

AGLOSAN x x x x x




6 Appendix 2

6.1 List of abbreviations

BSP Basic System Profile

C2C-CC Car-2-Car Communication Consortium

CA Cooperative Awareness

C-ACC Cooperative Adaptive Cruise Control

CAM Cooperative Awareness Message

CAN Controller Area Network

CAV Cooperative Automated Vehicle

CI Cooperative Intersection

C-ITS Cooperative Intelligent Transport Systems

CLCM Cooperative Lane Change Message

CLM Cooperative Lane Merging

CG Competence Group

CP Collective Perception

CPM Collective Perception Message

DCC Decentralized Congestion Control

DEN Decentralized Environment Notification

DENM Decentralized Environmental Notification Message

ETSI European Telecommunications Standard Institute

GLOSA Green Light Optimal Speed Advisory

I2V Infrastructure-to-Vehicle

IRC Impact Reduction Container

ITS Intelligent Transportation Systems

IVI Infrastructure to Vehicle Information

IVIM Infrastructure to Vehicle Information Message

LAM Lane Change Advice Message

MAI Motorcycle Approaching Information

MAW Motorcycle Approaching Warning

MCO Multi-Channel Operation

MCM Maneuver Coordination Message

MCS Maneuver Coordination Service

MRM Minimum Risk Maneuver

NGV New Generation Vehicular

OEM Original Equipment Manfacturer

PTW Powered Two-Wheeler

RSU Roadside Unit

RWW Roadworks Warning

SAM Service Announcement Message

SPAT Signal Time and Phase




SREM Signal Request Status Extended Message

SSEM Signal Request Extended Message

TC Technical Committee

ToC Transition of Control

TTC Time to Collision

V2I Vehicle-to-Infrastructure

V2V Vehicle-to-Vehicle

V2X Vehicle-to-everything

VRU Vulnerable Road User




6.2 References

[1] https://www.volkswagenag.com/en/news/2017/06/pwlan.html

[2] https://amsterdamgroup.mett.nl/default.aspx

[3] https://www.c-roads.eu/platform.html

[4] https://www.c-roads.eu/platform/about/news/News/entry/show/c-its-cooperation-between-c2c-cc-and-c-roads-platform-1.html

[5] https://www.car-2-car.org/documents/released-documents/

[6] https://www.c-roads.eu/platform/documents.html

[7] https://ec.europa.eu/info/law/better-regulation/initiatives/ares-2017-2592333_en#isc-2018-08207

[8] ETSI EN 302 665, Intelligent Transport Systems (ITS); Communications Architecture

[9] https://platooningensemble.eu/

[10] ETSI EN 302 637-2, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specification of Cooperative Awareness Basic Service

[11] ETSI EN 302 637-3, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service

[12] ETSI TS 103 301, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services

[13] ETSI draft TS 103 324, Intelligent Transport System (ITS); Vehicular Communications; Basic Set of Applications; Specification of the Collective Perception Service

[14] ETSI draft TR 103 562, Intelligent Transport System (ITS); Vehicular Communications; Basic Set of Applications; Informative Report for the Collective Perception Service

[15] http://eco-at.info/Specification_request.html

[16] The Autonet2030 project, http://www.autonet2030.eu/

[17] The MAVEN project, http://maven-its.eu/

[18] The IMAGinE project, https://imagine-online.de/en/

[19] ETSI Draft TS 103 561. Intelligent Transport Systems (ITS); Vehicular Communication; Basic Set of Application; Maneuver Coordination Service

[20] The TransAID project, https://www.transaid.eu/

[21] ETSI TR 103 300: Intelligent Transport System (ITS): Vulnerable Road Users (VRU) awareness; Part 1: Use Cases definition

https://www.volkswagenag.com/en/news/2017/06/pwlan.html

https://amsterdamgroup.mett.nl/default.aspx

https://www.c-roads.eu/platform.html

https://www.c-roads.eu/platform/about/news/News/entry/show/c-its-cooperation-between-c2c-cc-and-c-roads-platform-1.html

https://www.c-roads.eu/platform/about/news/News/entry/show/c-its-cooperation-between-c2c-cc-and-c-roads-platform-1.html

https://www.car-2-car.org/documents/released-documents/

https://www.c-roads.eu/platform/documents.html

https://portal.etsi.org/webapp/WorkProgram/Report_WorkItem.asp?WKI_ID=50633&curItemNr=61&totalNrItems=284&optDisplay=284&titleType=all&qSORT=HIGHVERSION&qETSI_ALL=&SearchPage=TRUE&qWKI_REFERENCE=ITS&qINCLUDE_SUB_TB=True&qINCLUDE_MOVED_ON=&qSTOP_FLG=N&qKEYWORD_BOOLEAN=OR&qCLUSTER_BOOLEAN=OR&qFREQUENCIES_BOOLEAN=OR&qSTOPPING_OUTDATED=&butExpertSearch=Search&includeNonActiveTB=FALSE&includeSubProjectCode=FALSE&qREPORT_TYPE=SUMMARY

http://www.autonet2030.eu/

http://maven-its.eu/

https://imagine-online.de/en/

https://www.transaid.eu/




[22] ETSI TR 103 299, Intelligent Transport System (ITS); Cooperative Adaptive Cruise Control (CACC); Pre-standardization study

[23] Autonet2030 project, Deliverable D3.2 “Specifications for the enhancement to existing LDM and cooperative communication protocol standards”, http://www.autonet2030.eu/wp-content/uploads/2015/02/D3.2-Specifications-cooperative-communication-protocol-standards-draft-for-approval.pdf

[24] SAE J2735_201603, Dedicated Short Range Communications (DSRC) Message Set Dictionary, March 2016

[25] B. Lehman, H-J. Gunther, L. Wolf, “A generic approach towards maneuver coordination for automated vehicles”, C2C Forum 2018

[26] The INFRAMIX project, https://www.inframix.eu/

[27] Revision of ISO TS 19321:2015 (currently ongoing)

■ End of Document ■

http://www.autonet2030.eu/wp-content/uploads/2015/02/D3.2-Specifications-cooperative-communication-protocol-standards-draft-for-approval.pdf

http://www.autonet2030.eu/wp-content/uploads/2015/02/D3.2-Specifications-cooperative-communication-protocol-standards-draft-for-approval.pdf

https://www.inframix.eu/

guidance for day 2 and beyond roadmap · the day1 deployment phase uses cooperative awareness (ca)...

Documents