AoI

    Area of Interest

ARQ

    Automatic Repeat Request

CACC

    Cooperative Adaptive Cruise Control

CAM

    Cooperative Awareness Message

CBR

    Channel Busy Ratio

CA

    Cooperative Awareness

CBF

    Contention-Based Forwarding

CCAM

    Cooperative, Connected and Automated Mobility

C-ITS

    Cooperative Intelligent Transport Systems

CP

    Collective Perception

CPM

    Collective Perception Message

DCC

    Decentralized Congestion Control

DEN

    Decentralized Environmental Notification

DENM

    Decentralized Environmental Notification Message

DPD

    Duplicate Packet Detection

DPL

    Duplicate Packet List

EDCA

    Enhanced Distributed Channel Access

ETSI

    European Telecommunications Standards Institute

FCD

    Floating Car Data

ITS

    Intelligent Transport Systems

LocT

    Location Table

LocTE

    Location Table entry

MC

    Maneuver Coordination

MCO

    Multi-channel Operation

MCM

    Maneuver Coordination Message

mmWave

    millimiter wave

PAM

    Platooning Awareness Message

PCM

    Platooning Control Message

PDR

    Packet-delivery Ratio

RadCom

    Radar-Based Communication

RSU

    Road-side Unit

RHW

    Road Hazard Warning

SHB

    Single-Hop Broadcasting

S-CBR

    Smoothed Channel Busy Ratio

TC

    Traffic Class

TDC

    Transmit Data Rate Control

TLS

    Transport Layer Security

TPC

    Transmit Power Control

TRC

    Transmit Rate Control

TTL

    Time-to-Live

VA

    Vulnerable Road User awareness

VANET

    Vehicular ad hoc Network

V2X

    Vehicle-to-anything

V2V

    Vehicle-to-Vehicle

# The Smart Highway to Babel: the Coexistence of Different Generations of
Intelligent Transport Systems

Oscar Amador
María Calderón
School of Information Technology
Halmstad University
Halmstad, Sweden
email<EMAIL_ADDRESS>Departamento de Ingeniería de Sistemas Telemáticos
ETSI Telecomunicación
Universidad Politécnica de Madrid
Madrid, Spain
email<EMAIL_ADDRESS>Ignacio Soto
Manuel Urueña
Departamento de Ingeniería de Sistemas Telemáticos
ETSI Telecomunicación
Universidad Politécnica de Madrid
Madrid, Spain
email<EMAIL_ADDRESS>Escuela Superior de Ingenieros y Tecnología
Universidad Internacional de la Rioja
Logroño, Spain
email<EMAIL_ADDRESS>
###### Abstract

The gap between technology readiness level in Cooperative Intelligent
Transport Systems (C-ITS) and its adoption and deployment has caused a
phenomenon where at least two types of network access technologies have to
coexist. Furthermore, for the case of the European Telecommunications
Standards Institute (ETSI) Intelligent Transport Systems protocols, work is
being completed in Release 2 of the specification while Release 1 deployments
are still underway. This, coupled with industry and consumer trends in the
vehicle industry, is bound to cause a scenario where fully C-ITS-enabled
vehicles have to coexist with non-C-ITS road users and, at the very least,
with different versions of C-ITS. In this paper, we analyze the performance in
terms of efficiency and safety of two releases of the ETSI GeoNetworking
protocol and we discuss possible paths to tackle the upcoming compatibility
and coexistence problems.

###### Index Terms:

Coexistence, Contention Based Forwarding, ETSI, GeoNetworking

##  I Introduction

The use of C-ITS to maximize road safety and traffic efficiency has been one
of the cornerstones upon which future mobility is built. The final stage of
Cooperative, Connected and Automated Mobility (CCAM) depends on the presence
of C-ITS on all roads and at all times, exchanging information and
coordinating their maneuvers [1].

The road to CCAM is divided in three different fronts: connection (the ability
to exchange information through networks), cooperation (the protocols that
define how intelligent vehicles react to information and each other’s
actions), and automation (the level of human intervention on the driving
task). These fronts have particular stages (e.g., levels of automation [2]),
but they share common stages, such as the Days in Vision Zero [1]. These Days
(1–4) are incremental steps toward the realization of full CCAM:

  * •

On Day 1, awareness starts, and vehicles share their status using messages
like Cooperative Awareness Message (CAM) and Decentralized Environmental
Notification Message (DENM) (i.e., in the framework established by the ETSI);

  * •

on Day 2, cooperation starts, and vehicles exchange information from their
sensors using, e.g., Collective Perception Messages;

  * •

on Day 3, road users communicate their intentions; and

  * •

on Day 4, road users execute coordinated maneuvers.

These days take into account the evolution of technology. For example, in the
connection front, Day 1 considers the use of Vehicular ad hoc Networks
supported on cellular communications (i.e., LTE) or in WiFi (e.g., ETSI
ITS-G5, based on IEEE 802.11p). From Day 2 onward, C-ITSs expect the use of
evolved technologies (e.g., 5G, 802.11bd, and technologies beyond these two).
The choice between cellular or WiFi is the first hurdle towards the harmonic
coexistence of different types of intelligent vehicles, and ETSI develops
media-dependent protocols for both approaches [3, 4]. Thus, manufacturers and
transportation authorities are given the chance to select one or many
technologies.

However, industry an consumer patterns are likely to cause a scenario where
vehicles that are produced in 2023, with the technological features present
this year, will share the road with fully CCAM-enabled vehicles in 2050 [5].
Even now, figures from the industry show that the average age for a vehicle in
Europe ranges from 12 to 14.7 years for cars and trucks respectively, and some
countries have even larger mean values [6]. This means that is highly likely
to have a fleet with 1) different technological capabilities, and 2) different
versions of the same technology.

In this paper, we present the effect of the coexistence of two versions of one
safety-critical protocol: Release 1 of ETSI Contention-Based Forwarding (CBF)
[7], and the changes proposed to Release 2, which were originally presented in
[8] and [9]. We evaluate efficiency metrics such as the number of
transmissions and its variation with larger penetration rates of the newer
protocol in scenarios where a message has to be distributed within a
Destination Area. Finally, we discuss the likely scenarios for coexistence and
possible compatibility between two versions of one protocol.

The rest of the paper is organized as follows: in Section II, we present the
two releases of the ETSI CBF protocol; in Section III, we perform an
experimental assessment of the penetration rate of the updated protocol on
effectivity and efficiency; Section IV presents a discussion on scenarios and
alternatives to paliate the problem of having a mixed fleet; and finally,
conclusions and future work are presented in Section V.

##  II Background

###  II-A ETSI ITS Architecture

Figure 1: ETSI ITS Architecture.

Figure 1 shows the layers and entities of the ETSI ITS architecture. At the
very top, the Application layer hosts systems that pursue the goals of all
C-ITSs — road safety and traffic efficiency — as well as other functions
(e.g., related to infotainment). These applications are supported by the
Facilities layer, e.g., by safety-critical Day 1 services like the Cooperative
Awareness (CA) and Decentralized Environmental Notification (DEN) basic
services. These services exchange messages with other nodes (vehicles and the
infrastructure) that allow applications fulfill their roles: for example, a
DENM warns road users about roadworks ahead of the road, and an application
can suggest or take a new route.

Messages are generated by services at the Facilities layer and then get sent
down the stack to the Networking & Transport layer. Depending on the use case
and requirements from applications, a message can be broadcast to neighbors
one hop away (i.e., Single-Hop Broadcasting (SHB)), or towards a specific area
of interest (Destination Area). The latter is achieved through GeoNetworking
[7]. In either case, packets are encapsulated and sent down to the Access
layer for transmission.

The Access layer executes Medium Access Control as well as Congestion Control
functions. This layer accommodates both WiFi-based and cellular-based access
technologies. For the case of WiFi-based access (i.e., ETSI ITS-G5), channel
occupation (i.e., Channel Busy Ratio (CBR)) is measured at this layer and,
using Decentralized Congestion Control (DCC) [10], each station calculates the
share of the medium it can use, which ranges from 0.06% to 3% of the medium,
or a message rate between 1 and 40 Hz. This means that, even in extremely low
congestion conditions, consecutive messages must wait in the DCC queues for at
least 25 ms between each dequeuing. From these queues, frames are then sent to
the Enhanced Distributed Channel Access (EDCA) queues where they wait for
their time to contend for access to the medium.

The road a message takes from generation to transmission and the possible
bottleneck or sinkhole effects that different phenomena, e.g., at the Access
layer, can have on protocol performance is accounted for by ETSI protocols.
E.g., a CAM can only be generated if the message rate is less or equal to the
one allowed by DCC. However, the appearance of new services and the expected
effect of having a high number of nodes in proximity of each other has
prompted the research community to study these effects continuously [11].

###  II-B GeoNetworking in ETSI ITS

Routing protocols in conventional computer networks rely on Layer 3 addresses
to send data between hosts in remote locations. This is typically achieved
through IP addressing. In the context of VANETs, where use cases sometimes
require the dissemination of information to a given area, geographical
awareness is required for a routing protocol. Hence, GeoNetworking
functionalities are included, e.g., in the Networking & Transport layer of the
ETSI ITS protocol stack [7]. GeoNetworking allows for messages to reach a
Destination Area without the need of maintaining a record of the network
addresses of nodes in that area, which would be difficult due to the dynamic
nature of vehicular networks.

ETSI defines mechanisms to broadcast information to a geographical Destination
Area when:

  * •

the source is outside the Destination Area and the message has to arrive in it
(e.g., using Greedy Forwarding or CBF); or

  * •

the message originates from or arrives into the Destination Area and is
disseminated using CBF or Simple Forwarding.

Non-Area mechanisms are out of the scope of this paper, but we can summarize
Greedy Forwarding as a mechanism where each hop selects its farthest known
neighbor and determines it as the next hop toward the Destination Area. These
type of mechanisms have been widely studied, and the ETSI-defined version of
Greedy Forwarding is evaluated in-depth in [12] and [13].

Regarding Area forwarding mechanisms, Simple Forwarding can be described as a
brute-force mechanism where every node that receives a message forwards it
immediately (i.e., simple flooding). CBF, on the other hand, makes receivers
start a contention timer that is proportional to their distance from the last
hop before they decide to forward the message. If they listen to a forwarding
while they are waiting for their timer to expire, they cancel the timer and
drop their copy of the packet.

####  II-B1 Inefficiencies in Release 1 of ETSI CBF

Efforts from the research community have evaluated the performance of ETSI
CBF. While the theoretical frame which supports CBF makes it more optimal
than, e.g., simple forwarding, the way it interacts with other layers in the
ETSI ITS architecture causes phenomena that affect its efficiency.

The interaction between ETSI CBF and the DCC mechanism at the Access layer
causes an undesired effect: even if the CBF timer expires, and the decision to
forward the packet is made, if there is congestion in the channel or if
another packet has just been transmitted, the forwarding is stopped at the DCC
queues (for ETSI ITS-G5) or the scheduler (for C-V2X). This means that the
actual transmission may not occur when CBF has decided, and this phenomenon
can occur in any station, so even if a copy of the message is received during
contention, it is not guaranteed that it comes from an optimal forwarder.
Furthermore, Release 1 of ETSI GeoNetworking relies Duplicate Packet Detection
(DPD) to CBF, so, if a backlogged message from a DCC-affected forwarder is
received at a neighbor which had already forwarded or even cancelled its copy
will enter the loop once again.

####  II-B2 ETSI CBF Release 2

The issues with DPD and the effect of DCC on Release 1 for ETSI CBF had been
studied widely in the literature [12, 14, 15]. Yet, it was the work in [8] and
[9] that was presented to ETSI as a change request that was iterated and
matured before it reached the necessary consensus to be Release 2 of ETSI CBF.

The differences in Release 2 of Area CBF are:

  * •

The inclusion of DPD inside the CBF algorithm.

  * •

Interfacing with the cross-layer DCC mechanism to offer awareness of the time
before DCC allows the next transmission, and account for it when calculating
the contention timer (optional for cellular-based communications).

  * •

A procedure to determine if a copy received during contention actually comes
from a better forwarder.

  * •

An updated timer formula to account for receptions beyond the maximum expected
distance.

However, since Release 2 services might have different requirements and
characteristics, it is not clear if Release 1 nodes will be able to receive
messages originating from Release 2 nodes, even for safety-critical
applications. If this is the case, and nodes executing Release 2 of ETSI CBF
coexist with nodes executing Release 1, there might be effects on awareness
and efficiency metrics. In the following section, we evaluate these effects in
Area CBF in a highway scenario.

##  III Experimental Evaluation of Coexistent Releases

###  III-A Simulation Scenario

We evaluate the effect of different ratios of nodes executing Release 1 and 2
of ETSI CBF in a highway scenario where a vehicle is stationary on the
shoulder of a road. It starts sending DENMs [16] at 1 Hz with a Destination
Area covering 4 km of a road with 4 lanes per direction. The vehicular density
is 30 veh/km on each lane. We take measurements for 30 s after a warm-up
period of 120 s. We evaluate:

  1. 1.

Packet-delivery Ratio (PDR): the number of successful individual receptions of
a message in the Destination Area divided by the total number of vehicles in
the area at the time of DENM generation.

  2. 2.

Number of transmissions: how many transmissions (i.e., from the source and
forwarders) have occurred.

Our toolkit consists of the OMNET++-based simulator Artery [17], which
implements the ETSI ITS protocol stack using Vanetza and Veins [18] for the
physical model of ETSI ITS-G5. Mobility is controlled by SUMO [19]. A set of
vehicles execute ETSI CBFRelease 1 [7], and an increasing number of vehicles
(see the penetration rate parameter) execute the improvements included in
Release 2 as described in [9]. In our set-up, and due to the nature of the
message (i.e., Road Hazard Warning (RHW)), we consider Release 2 and Release 1
messages to be mutually understandable. The rest of the parameters are
specified in Table I.

TABLE I: Simulation Parameters Parameter | Values
---|---
Access Layer protocol | ITS-G5 (IEEE 802.11p)
Channel bandwidth | 10 MHz at 5.9 GHz
Data rate | 6 Mbit/s
DCC | ETSI Adaptive DCC
Transmit power | 20 mW
Path loss model | Two-Ray interference model [20]
Maximum transmission range | 1500 m
CAM packet size | 285 bytes
CAM generation frequency | 1–10 Hz (ETSI CAM [21])
CAM Traffic Class | TC2
DENM packet size | 301 bytes
DENM Traffic Class | TC0 (Source) and TC3 (Forwarders)
DENM lifetime | 10 s
DPL size | 32 packet identifiers per Source
Default Hop Limit | 10
Rel. 2 penetration rate | 0, 25, 50, 75, 100%

###  III-B Results

Figure 2: Number of transmissions in different Release 2 penetration rates.
Figure 3: Packet Delivery Ratio for different Release 2 penetration rates.

Figure 2 shows the effect of even a minority portion of nodes executing a non-
optimized protocol. There is beyond an order of magnitude in executed
transmissions between the 0% and the 25% penetration rate for Release 2. From
there, there is a linear increase until the almost 30:1 ratio between Release
1 and Release 2 in line with the results in [8] and [9].

However, this issue is not reflected in awareness. Figure 3 shows the PDR over
the distance in the 4 km-long Destination Area. Lines overlap for most of the
distance, up to the last segment where they fan out in favor of higher
penetration rates. However, this phenomenon is due to an unbalance in the
turnover rate (i.e., the ratio between vehicles entering and exiting the
Destination Area after the DENM was generated). These extra vehicles are
accounted for since the message is still within validity, and it is relevant
to newcomers into the Destination Area.

The main takeaway of this experiment is that, as long as Release 1 and Release
2 GeoNetworking messages are mutually intelligible, there is an effect on
efficiency but not in safety (for the case of multi-hop DENMs from a single
source). However, inefficient forwarding will occupy the medium with
unnecessary repetitions of messages. Thus, in scenarios where there is more
than one source trying to disseminate safety-critical messages, unnecessary
transmissions are bound to cause collisions or, at least, to block access to
the medium for more necessary messages waiting to be forwarded. Further work
needs to be performed on how non-mutually intelligible messages affect
performance, since Release 1 is likely to reach higher PDR using brute force,
while Release 2 will either yield access to the medium or might find a path to
transmit immediately. What is sure is that, in that scenario, safety will be
compromised.

##  IV Discussion

We present a study of how the coexistence of two different releases of a
protocol, one being an incremental improvement of the other, affects
efficiency. For our case, packets were compatible, and Release 1 nodes could
understand Release 2 messages and vice versa. However, the road to full CCAM
is long, and this might not be the case even in the near future. In this
section, we present a discussion on the upcoming scenarios when multiple types
and generations of technologies have to coexist.

###  IV-A The upcoming Tower of Babel

Vehicles equipped with ETSI ITS nodes are already on the road communicating
with large deployments. Just in the first three quarters of 2023, above
250,000 C-ITS-equipped Volkswagen ID. cars were delivered [22]. These cars can
communicate with each other, with other ETSI ITS-compatible vehicles, and with
current deployments such as the one covering the entire Austrian motorway
network [23].

However, these vehicles and deployments all use Release 1 services. While some
Release 2 features are software-dependant, e.g., new services such as the
Vulnerable Road User awareness (VA) basic service, and can be installed during
car services or using over-the-air updates, some others will likely require a
deeper update (e.g., compatibility with Multi-channel Operation (MCO)).

While backwards-compatibility is a common issue in computer networks, the
characteristics of the vehicular market and industry make it specially more
difficult. This is one of the first cases where a massive number of legacy
nodes will likely share spaces with nodes up to 20 years more modern [6]. This
will create a scenario where pockets of segregated nodes are bound to
destabilize the system, at the very least make it more inefficient, while
compromising efficacy and safety.

####  IV-A1 Past experiences with backwards compatibility

One example of backwards compatibility is the jump between Transport Layer
Security (TLS) 1.2 and 1.3. The 1.3 version was released in RFC 8446 in August
2018 [24]. Its benefits over past versions have been widely studied [25], but
there are known examples of problems with its adoption [26].

The main problem with TLS 1.3 is protocol ossification. This phenomenon occurs
when deployed equipment (e.g., middleboxes) does not recognize new protocols
or even extensions to known protocols that were released after they were
installed. This causes them to interrupt packets that are valid, but
unrecognizable for the middlebox.

The solution for TLS 1.3, and for other examples of ossification, was to
encapsulate new messages so that the wire image of the packets is acceptable
for older middleboxes. This could be a path to follow with safety-critical
messages exchanged by nodes executing different releases of ETSI ITS.

At the Access layer, 802.11p (upon which ETSI ITS-G5 is based) and its
evolution 802.11bd are somewhat compatible. One of the main differences
between 802.11bd and 802.11p is the channel bandwidth — 20 MHz up from 11p’s
10 MHz. However, 11bd can also work in 10 MHz, and does so if it detects nodes
using only 10 MHz, thus, falling back into 11p when needed. However, this
approach might not be efficient in Future Mobility scenarios, when 11p’s
channel capacity might not be able to accommodate the myriad of applications
that will try to use the medium.

The foreseeable scenario if nodes cannot process packets from newer releases
(i.e., if Release 1 nodes cannot handle Release 2 GeoNetworking traffic) can
cause a disruption in Non-Area GeoNetworking [7] if Greedy Forwarding is used.
Since it is likely that beacons (e.g., CAMs) will always be compatible, a
Release 2 node can select a Release 1 neighbor as the next hop for a message.
The next hop will not process the message, and thus it will not reach the
Destination Area, since there are no fallback nodes in ETSI Greedy Forwarding.
This phenomenon can be avoided, for example, using CBF, where multiple nodes
become the next hop and contend to forward the message, increasing the chances
of nodes from both releases hearing the forwarded message. Further work will
address the impact of this phenomenon on Non-Area forwarding.

####  IV-A2 Nodes with different technologies

In the network side, even at Day 1, there is an identified risk of non-
interoperability [27]. Since ETSI ITS is media-independent, it does not
mandate that one access technology shall be used. Thus, there are vehicles and
road-side equipment that use, e.g., LTE or 802.11p. ETSI recognizes the
scenario and proposes co-existance methods [28] where, for example, vehicles
using different technologies share the time domain. This means that cellular-
based nodes occupy the C-ITS band for a fraction of the time and WiFi-based
nodes use it for the complement. This, however, is not full inter-operability,
since nodes using different access technologies will not ”listen” to each
other, and this approach compromises every metric: efficiency (diminishing the
amount of resources), efficacy (messages are not delivered to all connected
road users), and thus, safety.

Further work has to be performed within the research and industry communities
to 1) determine whether WiFi and cellular can possibly inter-operate, and 2)
whether inter-operability is possible, search for a path to evolve in a way
that newer versions of access technologies account for older nodes. One
possible approach is to adopt approaches such as Software-defined Radio (SDR),
which would allow equipment to be updated over the air as long as hardware
supports newer features, such as different modulation and coding schemes.

This phenomenon will be aggravated when technologies from different Days
coexist. For example, a legacy node that cannot interpret or even receive
intention-sharing or maneuver-coordination message exchanges will likely
affect the way CCAM-enabled vehicles converge to a solution. Once again, this
will affect traffic efficiency and might hinder road safety. Further work is
being performed to assess the effect of a mixed fleet in the optimal
performance in CCAM.

###  IV-B The case for ETSI CBF Release 2

For the specific phenomenon in this work, the differences between ETSI CBF
Release 1 and 2 are purely software-based. There is no need for extra fields
in the headers, or new values in the existing fields. The main differences
come in what the algorithm does with information it already used, namely, the
position vector from the last hop and the source. It also uses an existing
interface to the Management entity to consult the cross-layer DCC mechanism
and account for transmission rate control information when calculating a
contention timer (although this feature is optional).

We foresee two simple solutions: 1) existing equipment that is able to receive
an update adopts Release 2, or 2) Release 2 GeoNetworking messages are
encapsulated as Release 1, as was the case for TLS 1.3. Both approaches will
ensure safety in given scenarios, but approach 1 guarantees more efficiency,
and thus, more availability of resources for other applications.

##  V Conclusions and Future Work

We have presented a study of the coexistence of two releases of a
GeoNetworking protocol in the context of ETSI ITS — Release 1 and 2 of ETSI
CBF. We have proved that, as long as releases are compatible and nodes can
understand each other, safety metrics stay high even if resource efficiency is
compromised. Then, we presented a discussion of possible settings that are
likely to happen when Future Mobility is completely mature (i.e., Day 4 of
Vision Zero), where a Tower of Babel scenario might occur, and road users are
segregated into pockets of nodes speaking different languages (and some not
speaking at all). Even when the first C in CCAM stands for cooperative, this
cooperation is not likely to occur when agents are not able to hear and
understand each other. Future work includes a more in-depth analysis of the
effect of multi-modal road users (e.g., disconnected users, legacy fleet) in
the optimal performance of the CCAM-enabled fleet (i.e., connected and
automated vehicles).

## Acknowledgment

This work was partially supported by SAFER in the project “Human Factors,
Risks and Optimal Performance in Cooperative, Connected and Automated
Mobility”, the Knowledge Foundation in the project “SafeSmart – Safety of
Connected Intelligent Vehicles in Smart Cities” (2019-2024), and the ELLIIT
Strategic Research Network in the project “6G wireless” – sub-project
“vehicular communications”

## References

  * [1] European Commission (EC), “Towards a European road safety area: policy orientations on road safety 2011-2020,” July 2010.
  * [2] SAE, “Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles,” SAE International, Standard, Apr. 2021.
  * [3] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4. Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Media-dependent Functionalities for ITS-G5,” ETSI TS 102 636-4-2 - V1.4.1, February 2021.
  * [4] ——, “Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4. Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Media-dependent Functionalities for LTE-V2X,” ETSI TS 102 636-4-3 - V1.2.1, August 2020.
  * [5] D. Milakis, M. Snelder, B. Arem, B. Wee, and G. Homem de Almeida Correia, “Development and transport implications of automated vehicles in the Netherlands: Scenarios for 2030 and 2050,” _European Journal of Transport and Infrastructure Research_ , vol. 17, pp. 63–85, 01 2017.
  * [6] European Automobile Manufacturers’ Association, “Average age of the EU vehicle fleet, by country,” accessed: 2024-01-31. [Online]. Available: https://www.acea.auto/figure/average-age-of-eu-vehicle-fleet-by-country/
  * [7] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4. Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 1: Media-Independent Functionality,” ETSI EN 302 636-4-1 - V1.4.1, January 2020.
  * [8] O. Amador, M. Urueña, M. Calderon, and I. Soto, “Evaluation and improvement of ETSI ITS Contention-Based Forwarding (CBF) of warning messages in highway scenarios,” _Vehicular Communications_ , vol. 34, p. 100454, 2022, accessed: 2024-01-31. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S2214209622000018
  * [9] O. Amador, I. Soto, M. Calderon, and M. Urueña, “Studying and improving the performance of ETSI ITS contention-based forwarding (CBF) in urban and highway scenarios: S-FoT+,” _Computer Networks_ , vol. 233, p. 109899, 2023, accessed: 2024-01-31. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1389128623003444
  * [10] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Decentralized congestion control mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer part,” ETSI EN 102 687 - V1.2.1, April 2018.
  * [11] Ó. Amador Molina, “Decentralized congestion control in etsi intelligent transport systems and its effect on safety applications,” 2020.
  * [12] R. Riebl, _Quality of Service in Vehicular Ad Hoc Networks: Methodical Evaluation and Enhancements for ITS-G5_. PhD Thesis. De Montfort University, 2021. [Online]. Available: https://dora.dmu.ac.uk/handle/2086/21186
  * [13] V. Sandonis, I. Soto, M. Calderon, and M. Urueña, “Vehicle to internet communications using the etsi its geonetworking protocol,” _Transactions on Emerging Telecommunications Technologies_ , vol. 27, no. 3, pp. 373–391, 2016. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/ett.2895
  * [14] S. Kühlmorgen, H. Lu, A. Festag, J. Kenney, S. Gemsheim, and G. Fettweis, “Evaluation of Congestion-Enabled Forwarding With Mixed Data Traffic in Vehicular Communications,” _IEEE Transactions on Intelligent Transportation Systems_ , vol. 21, no. 1, pp. 233–247, 2020.
  * [15] T. Paulin and S. Ruehrup, “On the Impact of Fading and Interference on Contention-Based Geographic Routing in VANETs,” in _2015 IEEE 82nd Vehicular Technology Conference (VTC Fall)_ , 2015, pp. 1–5.
  * [16] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service,” ETSI EN 302 637-3 - V1.3.1, April 2019.
  * [17] R. Riebl, H. Günther, C. Facchi, and L. Wolf, “Artery: Extending Veins for VANET Applications,” in _2015 International Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS)_ , 2015, pp. 450–456.
  * [18] C. Sommer, R. German, and F. Dressler, “Bidirectionally Coupled Network and Road Traffic Simulation for Improved IVC Analysis,” _IEEE Transactions on Mobile Computing_ , vol. 10, no. 1, pp. 3–15, 2011.
  * [19] D. Krajzewicz, J. Erdmann, M. Behrisch, and L. Bieker, “Recent Development and Applications of SUMO - Simulation of Urban MObility,” _International Journal On Advances in Systems and Measurements_ , vol. 5, no. 3&4, pp. 128–138, December 2012.
  * [20] C. Sommer, S. Joerer, and F. Dressler, “On the applicability of Two-Ray path loss models for vehicular network simulation,” in _2012 IEEE Vehicular Networking Conference (VNC)_ , 2012, pp. 64–69.
  * [21] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 2: Specifications of Cooperative Awareness Basic Service,” ETSI EN 302 637-2 - V1.4.1, April 2019.
  * [22] Volkswagen Group, “Volkswagen Group delivers 45 percent more all-electric vehicles in first 9 months,” accessed: 2024-01-31. [Online]. Available: https://www.volkswagen-newsroom.com/en/press-releases/volkswagen-group-delivers-45-percent-more-all-electric-vehicles-in-first-9-months-17771/
  * [23] C-ITS Deployment Group, “ASFINAG, Managing everyday traffic situations more easily with C-ITS / Car2X,” accessed: 2024-01-31. [Online]. Available: https://c-its-deployment-group.eu/news-events/news/2022-07-27-asfinag-c-its-imagevideo
  * [24] E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, Aug. 2018. [Online]. Available: https://www.rfc-editor.org/info/rfc8446
  * [25] O. Levillain, “Implementation flaws in tls stacks: Lessons learned and study of tls 1.3 benefits,” in _Risks and Security of Internet and Systems_ , J. Garcia-Alfaro, J. Leneutre, N. Cuppens, and R. Yaich, Eds. Cham: Springer International Publishing, 2021, pp. 87–104.
  * [26] S. Lee, Y. Shin, and J. Hur, “Return of version downgrade attack in the era of tls 1.3,” in _Proceedings of the 16th International Conference on Emerging Networking EXperiments and Technologies_ , ser. CoNEXT ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 157–168. [Online]. Available: https://doi.org/10.1145/3386367.3431310
  * [27] C-ROADS, “C-ROADS platform position paper on 5.9 GHz band,” accessed: 2024-01-31. [Online]. Available: https://www.c-roads.eu/fileadmin/user_upload/media/Dokumente/C-Roads_Position_paper_on_59GHz_final.pdf
  * [28] European Telecommunications Standards Institute (ETSI), “Intelligent Transport Systems (ITS); Pre-standardization study on co-channel co-existence between IEEE- and 3GPP- based ITS technologies in the 5 855 MHz - 5 925 MHz frequency band ,” ETSI TR 103 766, September 2021.

  *[C-ITS]: Cooperative Intelligent Transport Systems
  *[ETSI]: European Telecommunications Standards Institute
  *[CCAM]: Cooperative, Connected and Automated Mobility
  *[CAM]: Cooperative Awareness Message
  *[DENM]: Decentralized Environmental Notification Message
  *[CBF]: Contention-Based Forwarding
  *[C-ITSs]: Cooperative Intelligent Transport Systems
  *[CA]: Cooperative Awareness
  *[DEN]: Decentralized Environmental Notification
  *[SHB]: Single-Hop Broadcasting
  *[CBR]: Channel Busy Ratio
  *[DCC]: Decentralized Congestion Control
  *[EDCA]: Enhanced Distributed Channel Access
  *[VANETs]: Vehicular ad hoc Network
  *[DPD]: Duplicate Packet Detection
  *[DENMs]: Decentralized Environmental Notification Message
  *[PDR]: Packet-delivery Ratio
  *[RHW]: Road Hazard Warning
  *[VA]: Vulnerable Road User awareness
  *[MCO]: Multi-channel Operation
  *[TLS]: Transport Layer Security