1 Motivation and Technical Background

In recent years, various Advanced Drivers Assistance Systems (ADAS) have been developed [1], while automated vehicles with an increasing different level of autonomy are being extensively tested and deployed on the roads. It is commonly assumed that safety, comfort, and efficiency on the road can be enhanced by the introduction of automated and fully autonomous vehicles, especially utilizing cooperative driving capabilities.

Cooperation among traffic participants is essential to reach a high level of automation. The cooperation requires interaction, which can be implicit or explicit. With implicit interaction, a vehicle infers the desired information of another traffic participant based on its behavior and actions. For example, it can recognize the intention of another vehicle by its local sensors and predict its future driving intentions when the other participant slows down. With explicit interaction, traffic participants exchange information by different means, such as by light projections in front of an automated vehicle for pedestrians. Communications can be regarded as a specific type of explicit interaction enabling an automated vehicle to warn others, exchange detailed information about the perceived environment or even negotiate maneuvers.

Vehicle-to-everything (V2X) communication enables the direct information exchange among traffic participants in an ad hoc network, as opposed to the typical communication with a communication infrastructure. It comprises communication among vehicles and with the road infrastructure as well as with pedestrians, bicyclists, etc. V2X communication operates in the 5.9 GHz frequency band, which has been specifically allocated for road safety and traffic efficiency applications in Europe and other regions of the world. Two access technologies have reached a mature status of research and development towards widespread deployment: WLAN-V2X and Cellular-V2X [37, 44]. Both facilitate an information exchange based on messages carrying application-specific content.

The development and deployment of V2X communications are commonly divided into three subsequent phases that rely on communication services with increasing complexity and requirements using dedicated, standardized message types (Fig. 1):

  1. 1.

    The Cooperative Awareness Message (CAM) and the Decentralized Environmental Notification Message (DENM) for the exchange of information about the vehicle state (position, speed, heading, acceleration) and about safety-critical events, respectively (Day 1);

  2. 2.

    The Collective Perception Message (CPM) for exchange of sensor data as lists of detected and classified objects in the perception range of a vehicle (Day 2); and

  3. 3.

    The Maneuver Coordination Message (MCM) for the exchange of intended maneuvers and coordination data among Connected and Automated Vehicles (CAVs) (Day 3+).

In Europe, these messages types and corresponding protocols are standardized by the European Telecommunications Standards Institute (ETSI): The specification of Day-1 message types CAM [15] and DENM is completed, CPM is close to completion [14], while the MCM is still very early in the research and standardization phase [17].

Fig. 1
A pyramid is divided into 4 stages, observation, status information, sensor data, and intention and coordination data, from the bottom to top. Degree of cooperation and communication requirements points upward. Stages 1 and 2 are day 1, up to stage 3 are day 2, and day 3 plus the last stage.

Evolution of V2X communication in phases: Day 1, Day 2 and Day 3+

For performance evaluation of the studied V2X communication protocols, the discrete-event simulator Artery [42] is applied. The simulator relies on Vanetza, INET, and OMNeT++ [48] to implement the ETSI Cooperative-Intelligent Transport System (C-ITS) communication protocol stack. Furthermore, Artery realizes an environmental model and sensor models that represent vehicles to perceive objects, such as vehicles and bicycles, in their vicinity. To model node mobility, Artery is coupled with microscopic traffic simulator SUMO [31]. To model realistic traffic and vehicle movement, the traffic scenario of the city of Ingolstadt (Bavaria, Germany), referred to as InTAS [30], is chosen. The InTAS scenario lasts 24 hours long and relies on real daily data traffic from Ingolstadt. Figure 2 illustrates the road topology of the InTAS scenario.

Fig. 2
A map of Ingolstadt depicts roads.

Road topology for the studied scenario of the city Ingolstadt

This chapter is divided into two main parts. The first part considers the sensor data sharing based on the exchange of CPMs with lists of detected and classified objects. The second part focuses on cooperative maneuver coordination relying on the exchange of intention and coordination data among the vehicles. These parts are structured as follows:

  • In the first part about sensor data sharing, an overview is provided in Sect. 2.1 along with the description of the state of the art and research questions in Sect. 2.2. Section 2.3 reviews the protocol design from research and current standardization efforts. Sections 2.4 and 2.5 present in detail the proposed changes to the current protocol design, followed by an analysis of the obtained results in Sect. 2.6.

  • The maneuver coordination part consists of three sections. Section 3.1 presents an overview that also includes maneuver coordination use cases and a description of the state of the art in the field. Section 3.2 presents the Priority Maneuver (PriMa) coordination protocol design including the maneuver coordination message, communication patterns, and an example scenario. An overview of the simulation framework and a discussion of the results for the studied coordination scenarios are presented in Sect. 3.3.

Finally, a summary and outlook of both parts, Collective Perception (CP) and cooperative maneuver coordination are given in Sect. 4.

2 V2X Communications-Based Sensor Data Sharing

This section presents an overview of V2X communications-based sensor data sharing, i.e., CP, followed by its state of the art, protocol designs, and our proposed improvements with performance evaluations.

2.1 Overview

Sensor data sharing for V2X communications has been studied extensively during the last few years. European research and standardization activities, e.g., in ETSI, commonly refer to it as “Collective Perception (CP)”. The protocol design of CP slowly reaches a stable state and is further used as a baseline. We investigate two remaining and relevant problems of CP: First, the information to be included in a CPM—the detected and classified objects—needs to be carefully selected to avoid overloading the bandwidth-limited wireless channel. This can be achieved by applying smart filtering approaches to reduce the number of objects to transmit, called filtering rules within the rest of this chapter. The problem with the current design of these filtering rules is that they do not take into account the available channel resources, e.g., objects are unnecessarily filtered even when the channel usage is low. Our first research question to improve CP is, therefore, how and when object filtering should be modified to adapt to the available channel resources. The second problem addresses information redundancy. Currently, many vehicles can send information about the same object, unnecessarily dissipating channel resources. To diminish it, the second research question is how to address information redundancy by filtering objects considering the information received by other traffic participants. The following sections will focus on these two main research questions. Figure 3 gives a brief overview of the addressed research problems and the studied solutions (Fig. 4).

Fig. 3
A flow chart starts with protocol design for collective perception from pre standardization, splits to reduce information redundancy to redundancy mitigation rules, and adapt to channel resource to E D A F rules.

Overview of the addressed research problems and studied solutions for Collective Perception

Fig. 4
An illustration displays 2 cars approaching an intersection. Both cars sense a pedestrian.

Intersection use case for sensor data sharing based on V2X communication

2.2 State of the Art in Collective Perception

Initial work on sensor data sharing or Collective Perception dates back to 2012 [39]. Ideas developed in [20] and others have led to standardization activities, the publication of the ETSI study item TR 103 562 [14], and draft versions of a European standard for CP in TS 103 324 [16]. Besides message format, [14] defines different design aspects of CP such as message format as well as the CPM dissemination concept to determine when to generate a CPM, i.e., the CPM generation rules. These rules determine which objects to include in a message and the triggering conditions to generate a CPM. Several publications, such as [7, 18, 46, 51], have reviewed the design for CP and elaborated on algorithms for message generation and object filtering.

The problem of information redundancy has been already considered in [14] and several redundancy mitigation approaches were defined but not evaluated. Only a few studies have addressed the redundancy problems. [6] has investigated two approaches, Dynamic and Self-Announcement redundancy mitigation rules (see Sect. 2.5), before [14] was published but applied different CPM generation rules than the currently designed ones [14, 16]. The authors of [47] focused on the redundancy mitigation approach using the object dynamics to filter objects, i.e., the dynamics-based redundancy mitigation rule (see Sect. 2.5). In [25], the authors reduce redundant object information on the wireless channel using a probabilistic object filtering approach based on the perceived density of vehicles, market penetration, and road geometry. The paper showed the efficiency of object filtering using a highway scenario and a minimal urban scenario with two roads. In [4], objects are filtered taking into account three criteria: channel load, and the number as well as the type of V2X stations that have already provided information about these objects. The main idea is to adapt the number of V2X stations that send information about the same object to the channel load. The lower the channel load is, the larger the number of stations that can send information about this object.

Congestion control algorithms in the context of safety applications have been the subject of intense research and resulted in ETSI standards such as the ETSI TS 102 687 [13] which specifies two different types of congestion control mechanism: reactive and adaptive. Both congestion control mechanisms rely on the perceived channel load to estimate available channel resources and enforce the respect of the channel access limitations imposed by the European norm [12]. These mechanisms attempt to share channel resources fairly among V2X stations by imposing constraints on the message transmission parameters, e.g., by reducing the allowed message transmission rate. The performance of CP with the constraints imposed by the reactive congestion control mechanism was initially studied in [19, 21] and later used in the evaluations realized in [14]. Our work [9] distinguishes itself by being the first to evaluate the CP performance with the adaptive approach and propose to adapt the filtering of objects based on the current channel access constraints.

In comparison to other works, we assess the performance of four redundancy mitigation approaches, the impact of their parameter settings, and the congestion control aware object filtering with the Artery framework in a complex and diverse urban scenario. We design and use novel metrics for a fair comparison, and compute the information value brought by the different message generation rules while considering the object dynamics. For an assessment of all redundancy mitigation approaches considered in the standardization process [14], we refer to our publication in [10].

2.3 Protocol Design

The published standardization document ETSI TR 103 562 [14] is considered as the baseline for the protocol design of Collective Perception. The corresponding dedicated message type CPM is composed of distinct containers with different purposes. The containers relevant for this paper are the Sensor Information Container (SIC), Perceived Object Container (POC), and the Station and Management Container (SMC) (Fig. 5). The SIC contains information about the sensing capabilities of a transmitting V2X station. The sensing capabilities are described using a list of capability descriptions of each of the sensors mounted on the vehicle, e.g., by indicating the Field of View (FOV) and the mounted position of the sensor. Since this information is static, the SIC does not need to be repeated with a high frequency and is included only once every second. The second and most relevant container is the POC, which contains all objects that a vehicle perceives with its local sensors. An object is selected for inclusion in the POC if it fulfills at least one of the following conditions [14]:

  1. 1.

    The object was never sent previously, i.e., it is considered new for the transmitting station.

  2. 2.

    The object’s position changed by more than 4 m (absolute euclidian distance) since its last inclusion in a CPM of the transmitting station.

  3. 3.

    The object’s speed changed by more than 0.5 m/s since its last inclusion.

  4. 4.

    The object’s heading changed by more than 4 degrees since its last inclusion.

  5. 5.

    The object was previously included in a CPM of the transmitter more than one second ago.

The SMC contains information about vehicle mobility such as position and velocity.

Fig. 5
A chart presents C P M format. I T S P D U header and C P M parameters connect to management, station data, sensor information, perceived object, and free space addendum containers below.

\(\copyright \) ETSI 2019. All rights reserved

CPM format and data elements as defined in [14].

Following the message generation rules in [14], a CPM is generated whenever the SIC needs to be transmitted, the POC contains at least one object for transmission or both. However, the CPM generation interval cannot be higher than 1 000 ms or lower than 100 ms. Following these message generation rules, the size and frequency of generated CPMs can considerably vary within the interval.

These rules were originally proposed in [18] with the idea that an object is included in a CPM whenever it would generate a CAM, presuming that the object is capable to generate messages, e.g. it is a vehicle capable of V2X communication. CP helps increase awareness of unconnected vehicles, especially in the first years of V2X deployment. However, it can overreach the goal when the V2X market penetration ratio grows over the years and it can start overusing the communication channel. On the opposite, at a low market penetration rate and when a few vehicles with V2X capabilities are within communication range, the hypothesis is that object filtering does not bring significant value (see Sect. 2.1).

Figure 6 shows an example of how to realize the CPM generation process as described in [14]. The Collective Perception Service (CPS) checks every \(T_ check \) if a CPM has to be generated. The common value for \(T_ check \) is 100 ms. Then, the CPS checks if any congestion control mechanism prevents the generation of a CPM (see Sect. 2.4.1), referenced as “Triggering” in Fig. 6. If allowed, the filtering rules and generation rules as described above are applied to the detected objects. Finally, the CPM is generated and passed to the lower layers for transmission.

Our contributions are the following:

  1. 1.

    To adapt the object filtering to the available channel resources, works have been realized in [9] and in [8]. The modification in the protocol design happens in the “Add filtered objects*” step of Fig. 6.

  2. 2.

    To address information redundancy, several redundancy mitigation approaches have been analyzed following the relevant approaches in ETSI TR 103 562 [14]. The resulting modifications occur in the “Filtering rules” step in Fig. 6.

Fig. 6
A flow diagram starts with start, goes to wait T, triggering, filtering rules, objects filtered, objects to transmit, and generate C P M, proceeds to add filtered objects, generate C P M, to lower layers. Objects detected goes to filtering rules. Objects filtered goes to add filtered objects.

Figure derived from [9]

CPM generation process.

2.4 Adapting Object Filtering to the Available Channel Resources

In the 5.9 GHz bandwidth in which V2X communications are deployed, channel resources are scarce and have to be used mindfully. The default data rate for WLAN-V2X is 6 Mb/s [26]. Communication services, such as Cooperative Awareness or Collective Perception with semi-periodic message generation consume a large amount of the wireless bandwidth. Moreover, the availability of resources for a service depends on two main factors: the presence of other V2X stations transmitting messages and the number of services of a V2X station attempting to generate messages on the same channel. To adapt to these two factors, congestion control mechanisms are being considered. For WLAN-V2X in Europe, these mechanisms are referred to as Decentralized Congestion Control (DCC). We review the main DCC mechanisms in Sect. 2.4.1. To adapt the CPM generation rules to the current DCC restrictions, we propose an algorithm following a principle explained in Sect. 2.4.2. The objective is to allow more objects to be transmitted when channel resources can support it.

2.4.1 Decentralized Congestion Control (DCC)

DCC is a cross-layer functionality with interacting entities at all layers. The DCC entities at the access layer [13] provide different control for the outgoing packets. Practically, a “gatekeeper” is implemented and it realizes a first-in-first-out (FIFO) packet queuing system for each channel. A gatekeeper relies on multiple simple priority queues for the packets to be selected for transmission and acts as a single server. The non-empty queue with the highest priority is dispatched first. If a queue is full and a packet arrives or if the lifetime of a packet expires inside the queue, the packet is discarded. The gatekeeper acts as a switch by opening and closing its gate repetitively. When a packet passes the opened gate to the lower layers, the gate is closed by the gatekeeper for a period of time depending on the current channel condition and the size of the packet. To determine the closing time of the door, ETSI TS 102 687 [13] specifies two DCC access layer strategies: reactive and adaptive. Both strategies respect the following DCC-related regulatory requirements for operation in the 5.9 GHz frequency band as specified in [12]:

  • \(0 < T_{on} < 4\,ms\): \(T_{on}\) is the duration of a packet transmission.

  • \(\delta <= 3\,\%\), whereas \(\delta \) is the duty cycle defined as the allowed ratio of the transmitter’s total “on” time relative to 1 s. \(3\,\%\) means that a station can occupy at most \(3\%\), i.e., 30 ms, of channel time within 1 s.

  • \(T_ off >= 25\,ms\): \(T_{off}\) is the duration before the gatekeeper re-opens its gate after the transmission of packet. In another word, the maximum packet transmission frequency is 40 Hz for a V2X station on a channel.

  • if \(CBR >= 0.62\), \(T_ off >= min(1000\,ms, T_{on}(4000\times \frac{CBR-0.62}{CBR}-1)\), see Sect. 2.6.1 for the definition of the Channel Busy Ratio (CBR).

LIMERIC is the adaptive DCC algorithm approach proposed in ETSI TS 102 687 [13]. Every 200 ms, it updates the duty cycle \(\delta \). Table 3 from [13] is used to parametrize LIMERIC. To improve the convergence time of LIMERIC and fairness during transition phases, [45] proposes a dual-\(\alpha \) approach which we used for the simulations in this paper.

To enforce the allowed duty cycle \(\delta \) determined by LIMERIC, the following equations from [13] are used:

$$\begin{aligned} T_ off = \min (\max (\frac{T_{ on _ pp }}{\delta }, 25\, ms ), 1\,{ s }), \end{aligned}$$
(1)

where \(T_{on_{pp}}\) denotes the transmission time of the previous packet. If \(\delta \) is updated during the \(T_ off \) interval, the closing time of the gatekeeper needs to be updated as per \(T_ off *\) given by (2).

$$\begin{aligned} T_ off * = \min (\max (\frac{T_{ on _ pp }}{\delta } \times \frac{t_ remain }{T_ off }, 25\, ms ), 1\, s - t_ passed ) \end{aligned}$$
(2)

\(t_ remain \) is the remaining time to wait with respect to the unmodified \(T_ off \) and \(t_ passed \) the time since the gatekeeper closed.

An interesting feature of the gatekeeper implementation is the fact that it takes into account the size of the previously transmitted packet to determine the time to wait between two transmissions. Thus, \(T_{on_{pp}}\) is also affected by the size of CPMs directly, and indirectly by the applied filtering rules. This characteristic is exploited to adapt the size of a CPM to the closing time of the gatekeeper.

2.4.2 Congestion-Aware Collective Perception

Principle: We propose to enhance the current generation rules such that the Collective Perception service avoids filtering objects when the channel resources are sufficient to transmit them. The modifications brought to the current design of the CPS [14] add a new step into the CPM generation algorithms (Fig. 6) marked as “Add filtered objects” box. This new step is motivated by two observations.

First, services such as the CPS are currently not specified to adapt to the DCC constraints. It is expected that with the Release 2 set of standards for V2X communications, mechanisms such as the one proposed here to adapt to the available channel resources and DCC restrictions will be specified or suggested. In particular for CP, when channel resources are sufficiently available, objects should not be filtered as rigorously as in congested situations.

Second, following the CPM generation rules (see Sect. 2.3), if there is no object to transmit then no CPM is generated in most of the cases. Therefore, the filtering of objects influences the message generation procedure. Moreover, the current object filtering approach relies on object dynamics, and including more objects in a message increases the probability of having none of them transmitted at the next attempt at CPM generation. The expected result is to generate a smaller number of CPMs containing more objects. The advantage of reducing the CPM generation rate is the reduction of the overhead created by the lower layer headers.

To address the two points discussed above, we worked on the following principle: if a CPM is to be generated and the addition of an object from the set of filtered objects does not directly impact the CPM generation rate, the object will be included in the CPM. This principle is possible thanks to \(T_ check \) and the gatekeeper as explained in Sect. 2.4.1.

The following example illustrates the principle: Let’s consider that \(T_ check \) equals 100 ms. If a generated CPM just passed the gatekeeper, and the resulting \(T_ off \) is 115 ms, the next potential CPM generation will be not earlier than 200 ms later. At the first occurrence of \(T_ check \), the \(T_ off \) interval has not elapsed yet. Hence, the CP service has to postpone the message generation to the next \(T_ check \) cycle, which is 200 ms after the preceding CPM generation. The resulting gap of 85 ms remains unused. If by adding filtered objects, the increased CPM size causes the gatekeeper to extend \(T_ off \) by less than those 85 ms, the effective CPM generation rate would not get reduced at all. As a result, the CPM generation at an interval of 200 ms is not prevented by DCC, independently of some additional filtered objects included.

Effects on the Collective Perception Service: With consideration of the channel congestion, the previously described principle has three possible effects on the CP service:

  1. 1.

    The CPM includes all objects (filtered and non-filtered) without restrictions from DCC on the CPM generation rate. This will occur when channel resources are largely available. We refer to this effect as ”One-For-All”, i.e., all objects are included if a CPM is to be generated.

  2. 2.

    Part of the filtered objects is included in the generated CPM. This occurs when DCC would start delaying packet transmissions if all objects, filtered and non-filtered, would be included. As result, the CPM contains some filtered objects chosen randomly.

  3. 3.

    No filtered objects are included. The CPMs generated using the current ETSI rules are sufficient for DCC to restrict the generation rate.

Process: The principle elaborated in the previous section was analyzed and evaluated in [9]. We enhanced the algorithm developed in [9] by simplifying its implementation and limiting its application. This enhancement was proposed in [8]. The main modification is to avoid adding filtered objects if the DCC restrictions before the next message to generate are higher than \(Toff_ thresh \) with a default value of 100 ms, which is the minimum time to wait between two consecutive messages. In this chapter, we evaluate additional values for \(Toff_ thresh \) as shown in Table 1. Figure 7 shows the resulting process to include filtered objects considering DCC, named Enhanced DCC Aware Filtering (EDAF) rules. First, the CPM containing the objects that have passed the POC inclusion rules and other containers is created. Second, the highest \(Toff_ worst \) that DCC could impose is computed. The steps to compute \(Toff_ worst \) are not included in this book but the reader is kindly invited to find them in [9]. Then, if \(Toff_ worst \) is lower than \(T_ GenCpmMin \), one of the objects filtered is added. These steps are repeated until either there are no more objects or \(Toff_ worst \) exceeds \(T_ GenCpmMin \).

2.5 Redundancy Mitigation Rules

A problem remaining with the current CP protocol design is that many vehicles can send information about the same object without any control. Information redundancy is not bad in itself and could help to improve the perception of the surrounding. However, in the context of limited channel resources, a too-high information redundancy does not bring any benefit. Moreover, it may even decrease the perceived quality of the object by adding extra processing delay. To address this problem, different techniques were elaborated in [14] and analyzed in other documents (see Sect. 2.2). Based on [14], parts of the techniques established for the RMRs are described in the following:

The Distance-based RMR: An object is filtered if it was already received from another V2X station within the R_Redundancy range during the last time window W_Redundancy. The parameter R_Redundancy needs to be carefully tuned such that the RMR efficiently allow enough object transmissions while controlling the channel load. CAMs and CPMs are considered sources of information for this RMR. A benefit of this RMR is that it attempts to maintain the awareness range by distributing in space the sources of information.

Table 1 Summary of the simulation parameters
Fig. 7
A flow diagram starts with objects to transmit, goes to C P M, compute T of f worst, T of f worst less than T of f thresh, splits to objects filtered empty and removes last filtered object added, and merges to generate C P M. Objects filtered empty goes to add one object into C P M and objects filtered.

The Enhanced DCC Aware Filtering (EDAF) rules

The Dynamics-based RMR:The logic behind this RMR is inspired by the “POC inclusion rules” of the CPM and the CAM triggering rules [15]. If the last update received time, position, or absolute speed of an object changed less than P_Redundancy meters or S_Redundancy meters per second, respectively, the object is filtered. As for the ”POC inclusion rules”, the advantage of this rule is that the updates of objects will depend on their dynamics, avoiding too many objects of non or slow-moving vehicles.

The Self-Announcement-based RMR:If an object is detected as capable of transmitting V2X messages (e.g., CAM or CPM), the object is filtered.

The Frequency-based RMR:An object is filtered if it is subject to a number of updates higher than N_Redundancy during last time window W_Redundancy.

2.6 Simulation Results

The following of this section describes the evaluation framework used for the performance evaluations of the different proposed CP protocol designs.

2.6.1 Evaluation Framework

We review in this section the relevant parameters and components of our simulation framework. Table 1 summarizes the parameters used.

Communication: The insertion of V2X devices into the market is expected to increase slowly over the coming years. For our simulations, the following V2X market penetration rates (MPRs), i.e., the rate of vehicle able to generate and receive V2X messages, were investigated: 0.1, 0.2, ..., 1.

For communication, vehicles operate a WLAN-V2X-compatible transceiver capable of working on two channels simultaneously without co-channel interference. For DCC, the adaptive approach described in Sect. 2.4.1 is deployed for all V2X capable vehicles.

Messages: CAM and CPMs are transmitted on all vehicles with enabled V2X capabilities. The CAMs are assigned to the control channel (SCH0) (or IEEE channel # 180) and generated according to ETSI EN 302 637-2 [15]. The CPMs are assigned to the SCH1 (IEEE channel # 176) and triggered following Sect. 2.3 and according to the studied filtering rules. In a CPM, the itsPduHeader, the managementContainer, and the stationDataContainer counts for 44 B together. A SIC is included once a second and is 12 B large. A POC in a CPM is 35 B after encoding. The FreeSpaceAddendumContainer is omitted.

Sensor Configuration: In Artery, object perception is assumed idealistic, i.e., there are no inaccuracies, and all the object information, such as dimensions, position, and speed, are available to the perceiving vehicle. Sensors can be allocated with a defined field of view, range, and attachment point to vehicles in the simulations. A direct line of sight between the sensor and one of the object corners is required for successful detection. Buildings and other vehicles are obstacles to the perception.

In our simulations, vehicles have two radars: one with 80 m range and 325\(^{\circ }\) FOV facing backward and one with 160 m range and 35\(^{\circ }\) FOV facing forwards. This configuration is inspired by the one Tesla states to use for their autopilot on its vehicles.Footnote 1

EDAF Rules: With the sensor configuration used in our simulation, vehicles detect with their mounted sensors around 7.5 objects on average. In [9], only the configuration \(Toff_ thresh \)=100ms was investigated with a different sensor configuration. In this book chapter, different \(Toff_ thresh \) values are investigated: 25, 50, 75, 100 ms. The objective is to find a threshold allowing enough filtered objects to reduce the number of CPMs to generate while avoiding high information redundancy by including too many filtered objects. The sensor-equipped configuration on the vehicle is similar to the study performed in [10] and presented in Sect. 2.5.

Metrics: The following metrics were used to assess the performance of the different object filtering techniques and CPM generation rules:

  • Channel Busy Ratio (CBR): Fraction of time that the radio channel is perceived as busy to the total period under observation.

  • CPM rate: The number of CPMs generated per second.

  • CPM size: The size in bytes of the generated CPMs.

  • Environmental Awareness Ratio (EAR): The ratio of vehicles known within a delimited area around a vehicle. The area considered in our simulation is a circle centered on the vehicle with a diameter of 500 m.

  • Redundancy Level (RL): During the last second, the number of updates received about an object is divided by the number of updates that the object would have sent if it would have generate CAMs. More details on this metric can be found in [10].

  • Score: This metric is realized using (3). The Gompertz function G is the valuation of the RL score measured for each object and has the following parametrization: \(a\,=\,1, b\,=\,7, c\,=\,2.31337\). The objective is to facilitate the comparison among the CPM generation and filtering rules. More details on this metric are explained in [10].

    $$\begin{aligned} Score = (1-CBR) \times G(RL) \times EAR \end{aligned}$$
    (3)

2.6.2 Results for Enhanced DCC Filtering (EDAF) Rules

Results to adapt the object filtering to the available channel resources were initially presented in [9] and [8]. Because the scenario and part of the metrics used for simulation in [9] are different from the ones presented in Sect. 1, simulations were performed again to align the simulation configuration.

To evaluate the EDAF rules, we compare them to two default configurations: the “No Filtering” for which all the objects are included every 100 ms and the ETSI rules as defined in Sect. 2.3. The EDAF rules were explained in Sect. 2.4 and its parameter \(Toff_ thresh \) is configured for different values as indicated in Table 1.

Fig. 8
A line graph of C B R versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit increasing trend, with no filtering being the highest.

Average CBR perceived by vehicles on SCH1 for different CPM generation rules

Figure 8 shows the obtained results for the CBR with the different CPM generation rules. In general, the higher the MPR, the higher the CBR. This is expected as more vehicles transmit messages. Considering the greediest approach, the “No Filtering” strategy results in the highest average CBR perceived within the scenario (up to CBR around 0.55 at MPR=100 %).

In contrast, the ETSI filtering approach, which is the most conservative regarding the inclusion of objects in CPMs, shows the second lowest obtained CBR independently of the MPR. The CBR starts at around 0.04 at MPR = 0.1 and increases up to 0.42 at MPR = 1.0.

All EDAF configurations result in a lower channel usage than the No Filtering approach. With the EDAF-100 ms configuration, the CBR reaches a maximum of 0.45 at MPR = 1.0. We can observe that the EDAF-50,75,100 ms have similar CBR values up to different MPRs. For example, for MPR higher than 0.4, the EDAF-50 ms starts obtaining a lower CBR than the two other configurations. It indicates that the rules are in different phases as explained in Sect. 2.4.2. First, the three configurations are in the “One-for-All” phase. Then, as DCC starts to impose a higher closing gate delay, not all filtered objects are included in a CPM for the EDAF-50 ms. The phase change occurs at MPR = 0.4 for EDAF-50 ms and at MPR = 0.6 for EDAF-75 ms.

In contrast to the other EDAF configurations, the EDAF-25 ms results in a slightly lower CBR than the ETSI rules while being more permissive for object inclusion.

To explain this phenomenon, Figs. 9 and 10 show the resulting tradeoff between CPM size and rate obtained with both the ETSI and EDAF rules. The CPM size obtained at low MPR for the EDAF-50, –75, –100 ms is around 2.5 times higher (\(\approx \)250 B) and 1.7 higher (\(\approx \)170 B) for the EDAF-25 ms than for the ETSI rules (\(\approx \)100 B). On the opposite, the obtained CPM rate is on average higher for the ETSI rules (\(\approx \)9 CPM/s) than for the EDAF-50,75,100 ms rules (\(\approx \)4.8 CPM/s) and EDAF-25 ms (\(\approx \)5.3 CPM/s). This tradeoff between CPMs containing more objects but with a lower message generation rate is due to the nature of the filtering rules. For example, let’s consider the scenario of a V2X vehicle perceiving two objects requiring to be transmitted every 500 ms (due to their dynamics). There are two possible scenarios of CPM generation for these objects. In the first scenario, two CPMs are transmitted every second containing both objects. In the second scenario, four CPMs are generated per second containing each one of the objects. The second scenario is what happens in many cases with the ETSI rules, as the objects are not grouped for transmission. The first scenario is an example of what happens with the EDAF rules. As there are enough channel resources, the station creates a CPM for both objects, even if one of them shouldn’t have been transmitted at that time due to its last transmission. The advantage of the first scenario is to reduce the communication overhead from the lower layer headers. For the No filtering strategy, the CPM rate stays at a high value (around 10 CPM/s) with most of the included objects.

Fig. 9
A line graph of C P M rate versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit horizontal and near horizontal, with no filtering being the highest.

Average CPM rate in [CPM/s]

Fig. 10
A line graph of C P M size versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit horizontal and slightly decreasing trend, with no filtering being the highest.

Average CPM size in [B]

As shown b Fig. 11, the resulting EAR is similar, independently of the employed generation rules. The lowest EAR is obtained at MPR = 0.1 with around 67 % of the detected objects. At MPR = 0.3, the obtained EAR is around 92 %.

Fig. 11
A line graph of E A R versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit increasing trend passing through same points.

EAR for the studied filtering strategies

Figure 12 for the Redundancy Level metric, the No filtering strategy results in the highest RL. Independently of the rules, the higher the MPR, the higher the RL is. Moreover, with the No Filtering rules, the RL can go up to 20 on average, i.e., a vehicle has 20 times more updates about an object than if this object would have sent CAMs following the CAM generation rules. This underlines the necessity to have RMR. We point out again that the tradeoff proposed by the EDAF-25ms creates more data redundancy, for a lower channel load, and a similar EAR than the ETSI rules.

Fig. 12
A line graph of redundancy versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit slightly increasing trend, with no filtering being the highest.

Redundancy level for the different filtering strategies

The resulting scores depend only on RL and CBR. Indeed, the EAR does not differ significantly among the filtering rules for the same MPR. Figure 13 shows the obtained scores. At MPRs < 0.15, the EDAF-50, 75, 100 ms rules resulted in the best score of around 0.64. At the same MPRs, the No Filtering scored better (0.61) than the EDAF-25 ms (0.56) and the ETSI one (0.46). This result shows that at low MPRs, greedier approaches than the ETSI one could and should be applied. At higher MPRs, the No Filtering approach does not score well and finishes with a score of around 0.45 at MPR = 1.0. This score is expected from the high RL and CBR obtained. At MPR > 0.2, the EDAF-25 ms rule performs the best with the highest score of 0.8 obtained at MPR = 0.3. The maximum score obtained by the different filtering approaches is reached between MPR = 0.2 and MPR = 0.3. For higher MPR, the RL is too high, resulting in a reduced gain from the Gompertz function compared to the generated channel load.

Fig. 13
A line graph of score versus M P R. Lines E T S I, E D A F 25 milliseconds, E D A F 50 milliseconds, E D A F 75 milliseconds, E D A F 100 milliseconds, and no filtering are plotted. All lines exhibit increasing then decreasing trend, with E D A F 25 milliseconds being the highest.

Score as defined by (3) obtained for the different filtering strategies

2.6.3 Results for Redundancy Mitigation Rules (RMRs)

The RMRs as described in Sect. 2.5 have been evaluated in [10] using the parameters indicated in Table 1 with the metrics: CBR, EAR, RL, and Score. By lack of place, only the score is shown here as a summary of the results. We did not evaluate the RMR “confidence level” proposed in [14] because they required detailed and realistic modeling of the environmental data capturing. The current version of Artery used in our study provides detailed modeling of the communication but does not have the capabilities for realistic sensor modeling yet. Therefore, the assumed ideal perception (no delay and no errors) in the object measurement is not suitable to study the confidence level. To better understand the impact of realistic sensor models on the RMR performance, enhanced simulation models and alternative simulation tools such as [49] would need to be used.

Figure 13 shows the obtained score for the RMRs and their respective parametrizations. Similarly to the results of the EDAF rules, the score is not affected by the EAR. Consequently, the score is influenced mostly by the CBR and the RL. Note that the None RMR is equivalent to the ETSI rules of Sect. 2.6.2. In the experiments performed for these RMRs, the highest CBR was obtained with the None RMR. The results do not match exactly between the two sets of simulations. The reason is that two slightly different implementations of the CP Service and InTAS scenario were used to collect the results, which lead to the differences observed between Figs. 13 and 14.

The obtained score for the None RMR goes from 0.385 at MPR = 0.1 up to 0.77 at MPR = 0.5 and decreases down to 0.62 at MPR = 1. In comparison to the other RMRs, the None-RMR rule performs best at an MPR lower or equal to 0.25.

For the Self-Announcement-based RMR, the score evolves from 0.38 at MPR = 0.1 to 0.83 at MPR = 0.75 then decreases until 0.66 at MPR = 1. Relatively to the other rules, this rule performs as one of the best scorers up to MPR = 0.5. At a higher MPR, it starts to underperform compared to others.

The best scores relative to other RMRs obtained with the Frequency-based RMR are between MPR = 0.1 to 0.5 with N_Redundancy = 3. At higher MPRs, this rule underperforms in comparison to the best scores obtained at each MPR.

The scores obtained by the Dynamics-based RMR are lower than the best-performing RMRs at MPRs lower than 0.5. At MPR = 0.5 and higher, independently of the chosen parameter value, this RMR obtains some of the best scores from around 0.83 at MPR = 0.5 to 0.875 at MPR=1.

For the Distance-based RMR, the results differ predominantly for R_Redundancy = 200 and the other configurations. For R_Redundancy = 200, the obtained score is the same as for the Frequency-based RMR with N_Redundancy = 1, even by behaving differently. The reason is that both rules allow only a single vehicle to transmit information about an object. Still, both configurations result in some of the lowest scores obtained independently of the MPRs. With R_Redundancy = 50 m, the scores are some of the best at MPR higher and equal to 0.25, which corresponds to one of the best performing rules independently of the MPR. The other remaining configurations perform in general well but are either better at low or at high MPRs.

Fig. 14
A line graph of score versus M P R. 4 distances, 4 dynamics, 5 frequencies, none, and self announcement are plotted. Dynamics exhibit increasing trend, and the rest exhibit generally abruptly increasing then gradually decreasing trend.

Scores obtained for the different RMRs. The score is based on the obtained performance for the CBR, EAR, and RL. To ease the readability, an offset in the x axis has been applied to each line

2.6.4 Conclusion

We made proposals to address two problems of the current protocol design for CP: adapt the filtering of objects on the available resources and reduce the problem of information redundancy by applying filtering rules considering objects received by other stations.

We conclude that within this evaluation framework, the EAR is not affected by the filtering rules. The score, as currently configured, shows that at low MPR, i.e., \(MPR \le 0.25\), an RMR is not necessary. By allowing the inclusion of all or part of the filtered objects in CPMs, the EDAF rules have shown better performance than the current CP protocol design with a carefully chosen value for the parameter \(Toff_ thresh \). At higher MPRs, RMRs relying on either distance or dynamics criteria perform well to decrease the number of objects included and maintain a balance between channel usage and information redundancy. Combining EDAF rules with RMRs is the next logical step for this research and is considered future work. The end objective is to have an approach addressing both problems simultaneously. The presented research opens a clear path to the following works. We expect to derive a new approach combining and using the advantages of both EDAF and some of the RMRs to obtain the best of CP, independently of the available channel resources.

Furthermore, more work is required to analyze these filtering rules with a focus on perception. Indeed, in this research, measurement inaccuracies were not considered while being a critical factor for the development of CP. Further investigations are needed to understand how error-prone perception would impact the operation and choice of the RMRs and EDAF rules.

3 V2X Communication-Based Maneuver Coordination

After the detailed presentation of the sensor data sharing service, the following part of the chapter presents the V2X service for sharing intention and coordination data.

3.1 Overview

Cooperative Maneuver Coordination (CMC) represents a V2X-based application for exchanging of intentions and coordination data among the CAVs through V2X communication. Through this process, the vehicles can broadcast their planned maneuvers, request and negotiate a coordinated maneuver or accordingly accept a coordination offer from other CAVs which is presented by Fig. 15. Increased safety, comfort and traffic optimization are the main goals of V2X enabled CMC. The standardization process of the Maneuver Coordination Service (MCS) is still in a very early stage at ETSI [17].

Fig. 15
An illustration displays 4 cars on the road. 1 car has speech balloon that says, can I change lane please? The other car has speech balloon that says, yes, I will decelerate.

Illustration of a maneuver coordination process

CMC applications can be classified based on different criteria. One of them is to divide the applications into use case specific and generic ones where the former can only be used for one traffic use case, while the latter can be applied to multiple use cases.

Another way to categorize the CMC applications is by centralized and decentralized coordination. Centralized coordination involves a central unit, mostly a Road Side Unit (RSU) that receives all the information from the involved vehicles and accordingly calculates and distributes the coordinated maneuvers to all involved vehicles. Infrastructure-controlled CMC can be applied to different use cases especially for signalized or non-signalized intersections, roundabouts and junctions, as well as cooperative merging situations through Vehicle-to-Infrastructure (V2I) communication. Decentralized CMC utilizes only Vehicle-to-Vehicle (V2V) communication among CAVs to negotiate and coordinate maneuvers.

Furthermore, the coordination can be implicit and explicit. In an implicit coordination, the vehicles broadcast messages with intention and coordination data without specifying which vehicles are included in the negotiation. This can lead to a conflicted situation if more vehicles are negotiating a maneuver. Explicit coordination involves the IDs of the negotiating and coordinating vehicles that leads to an explicit agreement among the vehicles for an acknowledged maneuver.

3.1.1 Use Cases

Various use cases exist [34] where CMC can bring certain benefits to increase the traffic safety, comfort and efficiency as well as the road capacity. Some of these use cases are presented in Fig. 16:

Cooperative-Adaptive Cruise Control (C-ACC): V2X communication enhanced ACC that enables additional information exchange between the vehicles to synchronize their velocities.

Platooning: A platoon consists of a group of vehicles driving in a stable formation, usually trucks, that can keep small distances among each other by sharing V2X messages that include their current state information. Typically, there is a master vehicle that leads and manages the platoon consisting of following vehicles.

Fig. 16
Six illustrations of multiple cars on the road, a, C A C C platooning, b, cooperative lane change, c, cooperative lane merging, d, cooperative overtaking, e, cooperative junction, and, f, cooperative intersection.

Cooperative driving use cases

Cooperative lane change: Two or more vehicles can cooperate to create a gap for a safe and efficient lane change maneuver.

Cooperative lane merging: Common highway situation that can be facilitated by V2X communication to allow safe and comfortable lane merging for the CAVs.

Cooperative overtaking: Another common maneuver that occurs frequently on highways and rural roads that can be utilized especially for heavy loaded trucks.

Cooperative driving at intersections, roundabouts and junctions: Such traffic use cases can often cause conflicted outcomes. By exchanging the planned and desired intentions, the involved CAVs can coordinate each other in a safe and efficient way.

3.1.2 State of the Art in Maneuver Coordination

The topic of cooperative maneuver coordination is a relatively new field with a lot of open research gaps. Much of the earlier research was done on use case-specific coordination, whereas in the recent years more work emerged on generic maneuver coordination. Platooning [50] and C-ACC [11] represent typical examples for use case-specific cooperative driving applications that have been more extensively researched and analyzed. These approaches utilize V2V communication to achieve coordination that is mostly focused on longitudinal acceleration and deceleration. Numerous approaches exist with different control strategies and characteristics presented in [11, 40, 50]. A research on driving in a convoy is presented in [35] where the vehicles adjust their longitudinal and lateral dynamics to keep a stable driving formation. Certain applications like lane change, merging and overtaking require coordination in both longitudinal and lateral direction in order to create the needed space. Such a lane change approach is presented in [24] consisting of three different phases: search, preparation and execution, where dedicated lane change messages are broadcast in each phase. C-ACC have been used for lane change and merging scenarios, as presented in [2]. Various message sets are utilized by distributed resource reservation protocols in [3] to analyze distributed intersection and roundabout management without infrastructure support.

Generic decentralized maneuver coordination focuses on using one protocol to achieve coordination in different traffic use cases. There are different approaches presented in the last several years, however a lot of gaps in the protocol design, testing and evaluation still exist. Maksimovski et al. already published surveys [33, 34] that analyze the up to date proposed coordination approaches and their advantages and limitations. Comparison of the approaches was performed as well. Several research gaps were highlighted focusing on the detection and decision logic, the maneuver coordination protocol and the V2X communication. The detection and decision logic part includes research questions related to: decision when to request a maneuver on the side of the requesting vehicles as well as when to accept a maneuver coordination on the side of the accepting vehicle. In the maneuver coordination protocol section, the following research questions are discussed: the message type and format, additional use case-specific information in the message, message generation rules, number of messages, number of vehicles included in a coordination, maneuver cascading, data security and privacy as well as a question related to the implementation, testing and evaluation of the maneuver coordination protocol. The V2X communication section discusses the communication requirements for CMC, the improvement of the access technologies, the communication type as well as multi-channel operation.

The early standardization work by ETSI [17] is based on the work presented in [27] that proposed a Maneuver Coordination Service that utilizes periodic broadcast of dedicated Maneuver Coordination Messages (MCMs) consisting of trajectory related data, namely planned and desired trajectories, further enhanced by an explicit coordination approach and a safety analysis [28]. An explicit approach with extended communication pattern based on [27] with three new MCMs is proposed in [52] where a lane merge scenario was also used to evaluate the approach in different situations with and without coordination among the vehicles. An implicit approach utilizing MCMs is presented in [29], where the trajectory data have cost values representing the need or willingness to cooperate with the surrounding vehicles. A space time reservation protocol (STRP) using reservations of position and time constraints has been presented in [23] and continuously upgraded and evaluated for different traffic scenarios [38]. This protocol uses an extended CAM message in an event based manner to broadcast the request in comparison to the other approaches that propose periodic MCM with trajectory data. Extended CAM message to include future vehicle trajectories in an event based manner is presented in [41] as well to be used in hazardous situations to mitigate or avoid an accident. An additional maneuver suggested container in the MCM is presented in [5] to be used by the infrastructure through V2I communication to send suggestions to the CAVs, which was also demonstrated on real world tests in [43]. The Complex Vehicular Interactions Protocol (CVIP) is another explicit approach presented in [22], utilizing four different messages in an event based manner also involving joint maneuver negotiation. The maneuvers in the message can be represented with standardized names, functions or trajectories. Maneuver Coordination Service with abstracted functions for automated driving is proposed in [36] consisting of seven messages that demonstrates reduced communication bandwidth and increases the speed of the participating vehicles in the coordination.

The Priority Maneuver Coordination (PriMa) approach is proposed in [32] which relies on decentralized and explicit exchange of MCMs introducing three levels of maneuver requests and accordingly different negotiation process among the CAVs. Different communication patterns depending on the number of included vehicles in the coordination are also proposed, including cascading scenario. The current work is based on this approach and will be presented in more details in the next section.

3.2 Protocol Design

This section presents the PriMa coordination [32] protocol design. Three different priority levels are introduced that describe the different maneuver types. Communication patterns for different cooperative driving situations depending on the number of involved vehicles are studied too. The proposed MCM format is also introduced consisting of intention and coordination data required to complete a coordination.

3.2.1 Priority Maneuver Request

The proposed PriMa coordination relies on an explicit exchange of MCMs using different communication patterns with additional three levels of maneuver requests that facilitate the decision-making process of the involved CAVs in the negotiation phase. Three different levels of priority requests were defined in the concept that are based on different metrics and costs which vary depending on the use case. The following type of maneuver requests are defined:

Low priority—desired maneuvers that the vehicle wants to execute in order to improve time efficiency.

Medium priority—necessary maneuvers that the vehicle needs to perform in order to stay on the route or significantly improve time efficiency.

High priority—critical maneuvers to avoid an emergency maneuver or accident.

A thorough analysis of cooperative driving use cases is required to determine the priority of the requested maneuvers utilizing metrics and cost values based on the road rules, velocity, acceleration, time efficiency, conflicted traffic situations, as well as potential collisions and emergency situations. Such a different level of requests will also lead to a different negotiation process between the involved participants. On the side of the accepting vehicles, similar metrics can be used to evaluate whether a request is feasible and worthy to accept because in most of the cases the vehicles that accept the maneuvers will be disadvantaged. In [32] estimated values were used for a lane change scenario where the priority level of the request was based on the time gap to the front vehicle. On the other side, the accepting vehicles were evaluating the request based on the required deceleration and velocity reduction. Three different thresholds for reducing the velocity were used based on the priority level of the request. However, a high priority critical maneuver is accepted whenever the vehicle can plan and execute a conflict free trajectory.

Fig. 17
A chart presents maneuver coordination message. M C M, P D U points to I T S P D U header, timestamp, basic container, and vehicle maneuver container.

Maneuver Coordination Message

3.2.2 Maneuver Coordination Message

The MCM consists of vehicle state information, trajectory related data that represent the planned movement of the vehicle as well as trajectories included in the negotiation process. Figure 17 presents the MCM which includes several containers and is similar to the already standardized ETSI message formats. The ITS PDU (protocol data unit) header includes the version of the protocol, the ID of the station sending the message as well as the message type, in this case the MCM subtypes which are introduced below. Along the header, the timestamp when the MCM was generated is also included in each message. The basic container consists of the current reference position and the station type that can also be a vehicle or a RSU. The main container of the message is the vehicle maneuver container that includes the required vehicle dynamics, namely the planned (PT), requested (RT) and offered (OT) trajectories. The data type that represents the trajectory is a sequence of data points that includes the vehicle pose (position and orientation), the velocity as well as the time step between the trajectory points. The pose includes the longitude and latitude values, alongside the heading of the vehicle. Furthermore, the lane ID that the vehicle is currently driving on is also included. In a request MCM, the priority level as well as the request ID are also included alongside the IDs of the potential accepting vehicles. Accordingly, during negotiation the replying vehicles also include the ID of the request they refer to. The inclusion of the ID of the request and the IDs of the vehicles involved in the negotiation makes the coordination process explicit and unambiguous.

3.2.3 Communication Pattern

PriMa proposes three different communication patterns depicted in Fig. 18 representing coordination between two, more than two (in this case three) vehicles and a cascading situation using the following MCM subtypes explained below: regular, request, offer, confirm, accept, reject, execute, cancel, abort, emergency, cascading request, cascading accept and cascading reject.

Fig. 18
Three diagrams display message flows. a, Request goes from V 1 to V 2, back with accept, then back to V 2 with execute. b and c, Flow within 3 vehicles with request, confirmation, and execution from V 1 go to V 2 and V 3, and offer, accept, and cascading back to V 1.

Message flow in coordination between two vehicles (a), three vehicles (b) and cascading situation with three vehicles (c)

As an intention sharing message, the vehicles regularly broadcast MCMs. In a coordination between two vehicles, only two MCMs are required to complete the negotiation process: request and accept. However, in a situation involving three or more vehicles, additional MCM subtypes like offer and confirm are needed in order to ensure an unambiguous and efficient negotiation process. This avoids a divergent situation that can lead to conflicted and inefficient maneuvers between the involved vehicles. In such a way, the influence of the lost message packets on the negotiation process can also be limited. The impact of the unreliable communication is also discussed in more detail in [32] and will be analyzed in the next section too. In a cascading situation, the accepting vehicle in order to accept the incoming request, has to send a cascading request to another vehicle which prolongs the negotiation process. PriMa proposes a limited cascading coordination involving three vehicles. Additional subtypes are cancel, abort and emergency messages that can be used to cancel a request, to abort an agreed maneuver from the requesting vehicle as well as to send an emergency MCM involving an emergency trajectory that the vehicle is going to take without a negotiation. The final execute message from the requesting vehicle is not needed in order to complete the negotiation, however can be useful to confirm that the vehicle is executing the request.

3.2.4 PriMa Example Scenario

Figure 19 depicts a proof of concept scenario presented in [32] that includes four CAVs. In the scenario, the ego vehicle V1 needs to change a lane or decelerate because the vehicle V2 in front of V1 is stopping. In order to avoid a critical decelerating maneuver, V1 sends a high priority request message to vehicle V3. However, at the same time vehicle V4 also sends a low priority lane change request to V3 (Fig. 19b). In this situation V3 broadcasts an accept message to the high priority request and allows V1 to avoid the decelerating maneuver and perform a lane change. V4 also receives the accept message, however the message includes the station ID and request ID of V1, therefore showing the benefit of explicit and unambiguous communication. In an implicit coordination, V3 only sends an accept message that can lead to a conflicting situation where both V1 and V4 start to execute the lane change maneuvers. Furthermore, this scenario also demonstrates the benefit of the PriMa coordination to perform maneuvers that have a higher priority.

Fig. 19
Four diagrams display PriMa coordination, a, before coordination t 1, b, V 1 and V 4 send requests t 2, c, V 1 executes the request t 3, and, d, V 1 completes the maneuver t 4.

PriMa coordination [32]

3.3 Simulation Results

In order to design and evaluate the proposed coordination approach, a simulation was performed for a highway lane merging scenario. The simulation is performed in the discrete-event simulator Artery [42], see Sect. 1.

Fig. 20
A map displays road. Main road has 80 kilometers per hour connected to the road that allows 100 kilometers per hour. In between is a merging lanes point, diverging to merging road, to a perpendicular road with 80 kilometers per hour.

SUMO scenario map

3.3.1 Scenario Description and Evaluation Metrics

Scenario description: Figure 20 shows the map of the SUMO scenario taken from InTAS [30] which is modeled based on a highway in the outside parts of Ingolstadt, including the speed limits. The main highway road with a driving direction to the right has a total length of 705,78 m, of which on the first 251,86 m the speed limit is 80 km/h (22.22 m/s), while the rest of the road has a speed limit of 100 km/h (27.77 m/s). The first merging road on the bottom has a total length of 146.2 m and also has a speed limit of 80 km/h. However, the vehicles coming from this lane must give way to the vehicles on the main highway road. The merging point of the two roads is shown as well. The vehicles coming from the main road drive a total length of 158,84 m until the merging point, while the vehicle coming from the first merging road drive a similar length of 145.2 m. The simulation is run for 22 s.

Scenarios: Three different situations are considered:

  • Scenario without coordination—SUMO simulation following the right of way rules.

  • Scenario without right of way rules—the vehicle coming from the merging road drives without giving way to the vehicles on the main road.

  • Coordinated scenario—the vehicle coming from the merging road coordinates a merging maneuver with the vehicles driving on the main road.

Evaluation metrics: To evaluate the coordination protocol the following metrics are considered:

  • Safety metrics: The time gap between the negotiated and executed trajectories of the cooperative vehicles needs to be bigger than 1 s. The results also show the position of the vehicles and the distance between them during the merging maneuver.

  • Comfort metrics: the car following models from SUMO are used in the simulation with desired acceleration of up to 3 m/s\(^2\) and deceleration of up to 4 m/s\(^2\) to keep the comfort values according to the ACC standard.

  • Efficiency metrics: The results show the time loss of each cooperating vehicle in the simulation. SUMO calculates the time loss as the time that the vehicle spends in the simulation driving below the desired speed, in this case the maximum speed limit on the road.

  • Communication related metrics—The results present the total negotiation time between the vehicles to complete the coordination. Additionally, the unreliable communication effect on the coordination is analyzed too by introducing a package loss rate of 10, 20 and 30%. The average negotiation time for different packet reception rate (PRR) is calculated based on ten simulation runs for each scenario using random number generators with different seeds. It has to be noted that the processing delays of the motion planning system that plans a maneuver request or evaluates an incoming request are not considered, as well as the additional delay and latency that can arise due to the communication device or communication channel (Decentralized Congestion Control—DCC). More details on DCC can be found in the first part of the chapter about collective perception.

3.3.2 Coordination Protocol Implementation

The maneuver coordination protocol is implemented as a V2X service based on the ETSI ITS-G5 protocol and is analyzed for coordination involving two and three negotiating vehicles. The priority request analysis was not performed in this evaluation. MCMs are broadcast every 100 ms (broadcasting interval of 10 Hz) by each of the involved CAVs in the simulation. The broadcast trajectories include 20 points with a time step of 0.25 s between the points representing the intention of the vehicles in the next 5 s. Cartesian coordinates (x, y) are used to represent the position of the vehicle in the local coordinate system, however they can be transformed to the global coordinate system with longitude and latitude values as used in the ETSI standards. The trajectory is calculated based on the constant velocity model, in this case joining the highway with 22.22 m/s. A very important part of the coordination is the time when the ego vehicle starts to send the request. The negotiation needs to be completed at a certain distance before the merging point, to let the requesting vehicle decelerate on time with a comfortable deceleration in case if the negotiation is not successful. The required distance to stop the vehicle with the current speed and desired deceleration can be calculated using the generic braking distance formula: \(d = (V_{f}^2 - V_{i}^2) / (2 (-a))\), where \(V_{f}\) is final velocity, \(V_{i}\) is initial velocity, and a is the deceleration. Additionally, a timeout of 1 s is added to complete the negotiation. Therefore, the vehicle starts sending a request once it is away from the merging point at a distance equal to the braking distance + the distance required for driving 1 s with the current speed. Since the vehicle is driving with 22.22 m/s, and has a desired comfortable deceleration of 4 m/s\(^2\), it starts sending requests around 4 s before reaching the merging point with the current speed.

Fig. 21
Three line graphs of Vego and V 1 plotted in velocity meter per second versus time in seconds, a, an uncoordinated scenario, b, no right of way scenario, and, c, a coordinated scenario.

Velocity change—two coordinating vehicles

3.3.3 Coordination—Two Vehicles

This simulation involves two vehicles: the ego vehicle Vego and V1. In the first scenario, Vego decelerates to let V1 that has the right of way which leads to a big reduction of the velocity as shown on the velocity-time graph in Fig. 21a. The second situation involves the same vehicles without following the right of way rules, which leads to a conflict and an emergency deceleration from V1, which is also shown in Fig. 21b. Vego, on the other side, joins the road with a small deceleration that is required to drive in the curve. The position of the vehicles during the emergency deceleration at t = 7.0 s is also shown in Fig. 22a.

Fig. 22
Two illustrations display V 1 going to Vego in, a, no right of way scenario at t equals 7 seconds, emergency braking, and, b, coordinated scenario at t equals 7 seconds.

Coordination scenario comparison—two coordinating vehicles

Fig. 23
A flow diagram has 2 starting points. Vego goes to regular, regular from V 1 within t 1, request within t 2, accept from V 1 within t 3, to execute within t 4, then t 5 after. V 1 goes to regular, accept, to execute.

Message flow in a coordination between two vehicles

The third situation, involves the implemented maneuver coordination service. The message flow during the negotiation is shown in Fig. 23. Two regular messages at time steps t \(_1\) and t \(_2\) are included as well to show the periodic flow of the messages. Since the vehicles broadcast MCMs, Vego detects a conflict between its desired trajectory and the PT from V1. In order to avoid deceleration, once Vego arrives at the required distance before the merging point, it broadcasts a request MCM (t \(_3\)) including the RT that starts at the merging point. After performing collision check, V1 broadcasts an accept message and starts adapting the new PT (t \(_4\)). After receiving the acceptance from V1, Vego broadcasts an execute message at t \(_5\), completing the negotiation in 100 ms, in a situation with 100% communication reliability. In case of repeating the request, Vego accordingly updates the time when the RT should start, as the vehicle is getting closer to the merging point. If there is no accept message or if Vego receives a reject message, it will follow the right of way rules and decelerate before the merging point. After accepting the request, V1 is reducing the speed with a small comfortable deceleration as depicted in Fig. 21c. Figure 22b shows the already coordinated merging of the vehicles at t = 7.0 s with a safe distance between the vehicles, in comparison with the emergency maneuver situation. The PT from Vego is calculated with constant velocity of 22.22 m/s, however it differs little bit in the execution since Vego requires small deceleration in the curve before merging to the highway. Because of that, it can be observed from the velocity-time graph that it leads to an additional small deceleration from V1, as can be seen at around 9 s. This also shows that keeping a time gap bigger than 1 s between the negotiated trajectory points also allows for safe adjustment of the these trajectories without causing further conflicts. The acceleration and deceleration values are also kept within the comfort interval as it can also be observed from the velocity change graph.

Table 2 Time loss—coordination of two vehicles

Table 2 includes the time loss of the vehicles in the different situations. It can be observed that in the uncoordinated SUMO simulation, Vego experienced time loss of 4.8 s, in comparison with the other two situations where the time loss is only 0.21 s, however, the second scenario leads to emergency braking from V1. As expected, since V1 needs to decelerate, it will be disadvantaged and the coordination leads to a time loss of 1.53 s due to the deceleration. The total time loss is however reduced by half in comparison without coordination, equaling 2.51 s, thus making the cooperative maneuver more time efficient.

Table 3 Average negotiation time—coordination of two vehicles

The average negotiation time was also analyzed by introducing the packet reception rate. Table 3 shows that for 70% reliability the negotiation time doubles to 210 ms, however is still well below 1 s that is set as a negotiation timeout.

3.3.4 Coordination—Three Vehicles

The scenario with three coordinating vehicles involves a longer negotiation process utilizing the communication pattern for a coordination with three or more vehicles, in order to ensure unambiguous and effective coordination. Figure 24 shows the coordinated scenario involving all of the vehicles in the simulation. The vehicles involved in the coordination are Vego, V1 and V2. V3 is included in the scenario to show the effect of the coordination on the other traffic participants but it is not participating in the coordination process. In this scenario, the ego vehicle is introduced 1.4 s after V1 into the simulation. Vehicles V2 and V3 are also introduced after V1 in the same lane and they have smaller speed than V1 in the beginning of the simulation since they need to keep the gap with the vehicle in front: Therefore, these vehicles experience a bigger time loss while driving below the desired speed. In the uncoordinated SUMO scenario, the ego vehicle decelerates in a similar way as in the scenario with two vehicles. Hence the velocity-time graph is not shown, but this time Vego needs to wait longer because there are three vehicles driving on the main road. Figure 25a depicts the velocity-time graph for the second situation without the right of way. Also, the position of the vehicles at time t = 8.3 s is shown in Fig. 26a. Vego needs to perform emergency deceleration due to V1 which is not affected by Vego now, since Vego was introduced 1.4 s later in the simulation. V2 needs to perform emergency deceleration due to Vego, while V3 also performs a high deceleration because of the emergency braking of V2.

Fig. 24
An illustration displays a coordinated scenario where V 3 at the tail of V 2, with Vego coming from merging road with V 1 in front.

Coordinated scenario

Fig. 25
Two line graphs of velocity meter per second versus time in seconds, a, no right of way scenario and, b, coordinated scenario. Vego, V 1, V 2, and V 3 start at different points, exhibit increasing trend, and end at 1 point.

Velocity change—three coordinating vehicles

Fig. 26
Two illustrations depict 2 scenarios, a, no right of way at t equals 8.3 seconds, emergency braking, and, b, coordinated scenario at t equals 8.3 seconds.

Coordination scenario comparison—three coordinating vehicles

Fig. 27
Three flow diagrams. 1, Vego goes to request, confirm at t 1, to execute at t 4, then t 7 after. 2, V 1 goes to offer, accept at t 2, then t 5 after. 3, V 2 goes to offer, accept at t 3, then t 6 after.

Message flow in a coordination between three vehicles

The message flow in the coordination is depicted in Fig. 27. It can be observed that the negotiation time is increased to 200 ms for perfect communication conditions. Since the ego vehicle is introduced later, the request is sent at t = 4.35 s, once the vehicle is at the same distance from the merging point as in the previous scenario. In this situation, Vego requires a merging gap between V1 and V2, hence the longer communication pattern is required for the negotiation process, meaning Vego needs to wait for the offer and accept messages from both of the vehicles in order to start the requested maneuver. After receiving the offer messages from V1 and V2 which include their offered trajectories and confirming that there is no conflict, Vego sends the confirm message at t \(_4\). However, it still needs to wait for the negotiated maneuvers to be acknowledged by both of the accepting vehicles. The maneuver negotiation process is finally over after the accept messages from V1 and V2 are received and the requested maneuver can be performed. In the end, the execute message is sent, but it is not needed to complete the coordination. After the negotiation, the vehicles keep sending the regular MCMs with their new PTs. Figures 25b and 26b present the velocity-time graph and position of the vehicles at the merging point, showing the smooth velocity change as well as the safe time gap between the involved vehicles in the coordinated maneuver.

Table 4 Time loss—coordination three vehicles

The time loss of all included vehicles in the simulation is shown in Table 4. In an uncoordinated situation Vego experiences significant time loss because it has to let three vehicles pass. As mentioned, V2 and V3 experience higher time loss in the uncoordinated SUMO scenario due to driving with lower speeds in the beginning of the scenario. In the no right of way scenario, the vehicles experience higher time loss and additionally need to perform emergency deceleration. In the coordinated scenario, Vego has almost no time loss, similar as V1 that only changes the lane in the coordinated scenario, therefore does not experience any additional time loss. V3 is also included in the time loss table in order to show the oscillating effect of the coordination on the other traffic participants as it also has to decelerate in this situation to keep the safe time gap to the vehicle in front. However, the maneuver for Vego was highly optimized with no waiting time to merge into the lane, and in this situation required small deceleration from V2, and a lane change with no time loss from V1. The total time loss for the three vehicles in the coordination, as well as the one with V3 (in brackets) is also presented in Table 4, which shows that the total time loss for all of the vehicles is significantly reduced in comparison with the uncoordinated scenario. The coordination makes the merging maneuver much more efficient without compromising the safety or comfort of driving as the vehicles also keep safe time gaps between each other and comfortable acceleration and deceleration values.

Table 5 Average negotiation time—coordination three vehicles

The effect of the unreliable communication on the negotiation process was also analyzed and is presented in Table 5. Since the vehicles require in total six messages to complete the negotiation process (without the execute message), the negotiation will be much more affected by the unreliable communication. With increased number of vehicles, the negotiation will become more complicated. However, the results show that for this traffic scenario, even with a PRR of 70%, the negotiation can still be completed under 1 s, as the average negotiation time is 500 ms and in each of the ten runs the negotiation was completed under 1 s. However, considering the processing delays of the motion planning system, the communication device and communication channel, the negotiation time will be increased and needs to be taken into account when designing the coordination protocol for real world applications. Further analysis is required to have an approximation of the negotiation time in different traffic situations.

3.3.5 Conclusion

Cooperative maneuver coordination represents a V2X communication enabled application that has the potential to significantly improve the safety, comfort and efficiency of the CAVs on the road. By exchanging the intention and coordination data, the CAVs will be able to detect and perform cooperative maneuvers that can improve the traffic flow in different traffic situations. The proposed decentralized Priority Maneuver (PriMa) Coordination approach introduces three different levels of maneuver requests: low, medium and high priority differentiating between desired, necessary and critical maneuvers that can improve the decision making process of the cooperating vehicles. The Maneuver Coordination Message that includes trajectory related data is also presented with additional subtypes. Different communication patterns are proposed that can be utilized depending on the number of included vehicles in the coordination, whether there are two vehicles, more than two vehicles, or cascading situation. Such a designed protocol aims to ensure safe, fast, efficient and unambiguous coordination in different traffic situations.

This work shows a proof of concept and evaluation of the coordination protocol as a V2X service in the simulation framework Artery for a coordination involving two and three vehicles utilizing different communication patterns. A highway merging scenario was simulated in three different situations: uncoordinated, scenario with no right of way rules and a coordinated scenario. The evaluation is based on metrics regarding the safety, comfort, efficiency and communication. The results show the potential that the coordination offers to perform safe and comfortable maneuvers that can significantly improve the traffic flow and time efficiency of the vehicles. The impact of the unreliable communication on the coordination was evaluated for different packet reception rates as an important part in the protocol design that ensures enough time to complete the negotiation and coordination process. The presented work can be seen as a contribution to further research and development of generic decentralized maneuver coordination applications based on V2V communication.

Future work will include enhancement of the coordination protocol and implementation and evaluation for different traffic scenarios. The communication requirements will also be specified for various cooperative driving use cases. An analysis will be performed to define the threshold values for different priority maneuvers. Furthermore, the simulation results will also be verified in a real world testing environment.

4 Summary and Outlook

In this chapter, we presented, analyzed, and enhanced two key V2X communication protocols for cooperatively interacting automobiles. The first one, Collective Perception, is part of the Day 2 development of V2X applications and is expected to be deployed in the coming years. We investigated the adaption of information included in CPMs depending on the channel load and the observed information redundancy on the channel. We proposed approaches to address independently each of these problems. In future work, we plan to develop a combination of the developed solutions.

The second one, Maneuver Coordination, is part of the Day 3+ development of V2X applications. It is expected to be deployed later in the mass market and is still at an early stage of development. In this book chapter, we proposed a new maneuver coordination approach introducing three different levels of maneuver priorities. The potential of this approach was analyzed and we showed its capacity to perform safe, efficient, and comfortable maneuvers. Future works include enhancements of this protocol considering more traffic scenarios and proof of concept in a real-world testing environment.