Operating ITS-G5 DSRC over Unlicensed Bands: A City-Scale Performance Evaluation

TL;DR

This study evaluates the performance of ITS-G5 vehicular communication systems operating over unlicensed ISM bands, comparing them to licensed DSRC, and finds that 2.4 GHz band offers comparable performance, while 5.8 GHz shows reduced packet delivery.

Contribution

The paper provides the first comprehensive experimental comparison of ITS-G5 performance over unlicensed bands versus licensed DSRC in a city-scale environment.

Findings

2.4 GHz band achieves similar performance to licensed DSRC.

5.8 GHz band has 30% lower packet delivery rate.

Operating over unlicensed bands is a viable alternative.

Abstract

Future Connected and Autonomous Vehicles (CAVs) will be equipped with a large set of sensors. The large amount of generated sensor data is expected to be exchanged with other CAVs and the road-side infrastructure. Both in Europe and the US, Dedicated Short Range Communications (DSRC) systems, based on the IEEE 802.11p Physical Layer, are key enabler for the communication among vehicles. Given the expected market penetration of connected vehicles, the licensed band of 75 MHz, dedicated to DSRC communications, is expected to become increasingly congested. In this paper, we investigate the performance of a vehicular communication system, operated over the unlicensed bands 2.4 GHz - 2.5 GHz and 5.725 GHz - 5.875 GHz. Our experimental evaluation was carried out in a testing track in the centre of Bristol, UK and our system is a full-stack ETSI ITS-G5 implementation. Our performance investigation compares key communication metrics (e.g., packet delivery rate, received signal strength indicator) measured by operating our system over the licensed DSRC and the considered unlicensed bands. In particular, when operated over the 2.4 GHz - 2.5 GHz band, our system achieves comparable performance to the case when the DSRC band is used. On the other hand, as soon as the system, is operated over the 5.725 GHz - 5.875 GHz band, the packet delivery rate is 30% smaller compared to the case when the DSRC band is employed. These findings prove that operating our system over unlicensed ISM bands is a viable option. During our experimental evaluation, we recorded all the generated network interactions and the complete data set has been publicly available.

Tables

Table 1. TABLE I: NTP server and GPS receiver specifications.

NTP Server [14]
NTP Accuracy
NTP Requests/sec	$>100.000$
Stratum Level	Stratum 1
GNSS GPS receiver [15]
GPS Precision
Position Acquisition Time
Oscillator Type	Crystal (Real-time clock support)
Update Rate	up to $5\mathrm{Hz}$

Table 2. TABLE II: Wireless network interface controllers Specifications.

	LP-RSU	LP-OBU	HP-RSU	HP-OBU
Model	Mikrotik R52H [17]		Mikrotik R5SHPn [18]
Chipset	AR5414		AR9220
Linux Driver	ath5k		ath9k
Operational Frequency	$2.192\mathrm{GHz}\text{ to }2.539\mathrm{GHz}$		$4.800\mathrm{GHz}\text{ to }6.075\mathrm{GHz}$
	$4.920\mathrm{GHz}\text{ to }6.100\mathrm{GHz}$
TX Power	$25\mathrm{dBm}$		$29\mathrm{dBm}$
Antenna Gain	$7\mathrm{dBi}$	$5\mathrm{dBi}$	$7\mathrm{dBi}$	$5\mathrm{dBi}$
Channel Bandwidth	$10\mathrm{MHz}$
$C{W}_{\min },C{W}_{\max }$	$[15,1023]$
MCS	QPSK $1/2$

Table 3. TABLE III: Name and description of the fields found in the logged CAM messages, both at the TX and RX sides.

TX Fields	Description	RX Fields	Description
TX-REQ-CAM	Type of packet	RxMAC	MAC address of the CAM source node
Protocol	Dummy field (is always 1) [19]	RX-REQ-CAM	Type of packet
StationID	Dummy field with random value [19]	Validation	Show if constraints failed in ASN.1 [19]
GenDeltaTime	The remainder of $\mathrm{Timestamp}/65546$ [19]	Protocol	Dummy field (is always 1) [19]
SeqNum	Sequence number of transmitted packet	StationID	The StationID of the transmitter [19]
GpsLon	Current longitude of the node	GenDeltaTime	The remainder of $\mathrm{Timestamp}/65546$ at the moment of transmission [19]
GpsLat	Current latitude of the node	SeqNum	Sequence number of received packet
CamLon	Quantized value of GpsLon – the value encapsulated in a CAM	GpsLon	Current longitude of the node
CamLat	Quantized value of GpsLat – the value encapsulated in a CAM	GpsLat	Current latitude of the node
GpsSpeed	Current speed of the node	GpsSpeed	Current speed of the node
CamSpeed	Quantized value of GpsSpeed – the value encapsulated in a CAM	SpeedConf	The way that speed is encoded [19]
Timestamp	Timestamp when CAM is generated (in epoch time)	VehHeading	GPS-acquired heading of the node
CamLength	The length of the transmitted CAM	CamLon	Encapsulated longitude value in a CAM
		CamLat	Encapsulated latitude value in a CAM
		CamSpeed	Encapsulated speed value in a CAM
		Timestamp	Timestamp when a CAM is received

Table 4. TABLE IV: The frequencies used throughout the four days of trials.

Day	HP Transceiver	LP Transceiver	Band
Day 1	$5.9\mathrm{GHz}$	$5.89\mathrm{GHz}$	DSRC
Day 2	$5.2\mathrm{GHz}$	$2.437\mathrm{GHz}$	ISM
Day 3	$5.18\mathrm{GHz}$	$2.412\mathrm{GHz}$	ISM
Day 4	$5.32\mathrm{GHz}$	$2.462\mathrm{GHz}$	ISM

Table 5. TABLE V: MAD and MSE comparison between the ISM and DSRC bands

Day	MAD HP	MAD LP	MSE HP	MSE LP
Day 2	$0.2246$	$0.1473$	$0.1048$	$0.0496$
Day 3	$0.2978$	$0.1525$	$0.1676$	$0.0538$
Day 4	$0.2257$	$0.1552$	$0.1082$	$0.0559$

Full text

I Introduction

By the end of 2020, recent forecasts estimate that fifty billion devices will require internet connectivity to operate. Among these devices, around ten million vehicles equipped with multiple communication systems and autonomous capabilities are expected to be rolled out into the global market [1]. In particular, there is global consensus around the fact that future automotive services for Connected and Autonomous Vehicles (CAVs) are expected to rely heavily on reliable broadband connectivity on the move [2]. This is confirmed by the National Highway Traffic Safety Administration (U.S. Department of Transportation) and the European Commission’s Connected-Intelligent Transportation System (C-ITS) initiative [3, 4]. In particular, the latter, along with the 5G-PPP Partnership, argues how reliable Vehicle-to-Everything (V2X) connectivity will empower future CAVs to deliver advanced automotive services, such as See-Through, Automated Overtake and High-Density Platooning [5, 6].

As identified by the C-ITS initiative, future CAVs are expected to be equipped with over 200 sensors. These sensors will generate a potentially substantial data stream to be shared with surrounding CAVs [7]. Given the expected market penetration of CAVs and their need of reliable communications links, Dedicated Short Range Communications (DSRC) systems based on the IEEE 802.11p Physical Layer [8] are expected to become more and more congested. This directly follows from the fact that users will access the channel on a contention-based way, similar to IEEE 802.11a [9], sharing a very narrow licensed frequency band (namely, $5.85\text{\,}\mathrm{GHz}$-$5.925\text{\,}\mathrm{GHz}$). What is more, there are plans for operating Cellular-V2X (C-V2X) systems on at least fractions of the band dedicated to DSRC systems, which will impact on the network resources available for ITS-G5 systems [10].

In an effort of addressing the pressing concern of the expected reduction of network resource over the DSRC licensed band, we investigate the possibility of using unlicensed bands in conjunction with the licensed DSRC band for supporting V2X communications. In particular, we establish a performance evaluation of a full-stack implementation of the ETSI’s ITS-G5 DSRC system over Industrial, Scientific, and Medical (ISM) bands. In our experiments, we considered the ISM bands $2.4\text{\,}\mathrm{GHz}$-$2.5\text{\,}\mathrm{GHz}$ (hereafter referred to as “ISM-2.4”) and $5.725\text{\,}\mathrm{GHz}$-$5.875\text{\,}\mathrm{GHz}$ (hereafter referred to as “ISM-5”). In order to do so, we deployed multiple ITS-G5 Road-Side Units (RSUs) along a $5\text{\,}\mathrm{km}$ long testing track located in the centre of Bristol, UK. We equipped two vehicles with ITS-G5 On-Board Units (OBUs) that has been driven around the testing track for $4\text{\,}\mathrm{h}$ per day, over a period of time of four days ($16\text{\,}\mathrm{h}$ in total). During our experiments, every network interaction between the OBUs and RSUs has been recorded along with the positioning information of both transmitter and receiver. The resulting data set is the first to record the whole set of ITS-G5 network interactions over a large-scale environment across both licensed and unlicensed bands.

The coexistence of IEEE 802.11p-based systems has been extensively investigated for what concerns the possibility of operating DSRC systems over unlicensed DVB-T2 bands [11]. On the other hand, [9, 12] investigated the coexistence of IEEE 802.11a/n/ac technologies as secondary systems over the band dedicated for DSRC applications. To the best of knowledge, no large-scale performance investigation across both the ISM-5 and ISM-2.4 bands exists. In particular, the original contributions of this paper are summarized as follows:

• •

We compare the network performance in terms of Packet Delivery Rate (PDR) and Received Signal Strength Indicator (RSSI) across ISM bands commonly used for operating WiFi networks. In particular, we observe that, on average, when the system is operated over the considered ISM-5 bands, the PDR is no more than $30\%$ lower compared to the correspondent case when the system is operated over the licensed DSRC band, while our system achieved almost comparable performance in the ISM-2.4 band.

• •

We released the entire data set of network interactions to enable future network comparisons. In particular, the structure of our data set two-folded: (i) a Comma-Separated Values (CSV) database to provide agile access to positioning information and transmission metrics and, (ii) A set of Packet Capture (PCAP) traces enabling to extract further system metrics (not previously included in the CSV database).

The remainder of the paper is organized as follows. Section II presents the considered experimental setup. Section III presents the structure of our car trials. Our findings are discussed in Section IV. In Section V, we draw our conclusions.

II System Description

For our experimentation, we prototyped an open-source IEEE 802.11p/DSRC testbed (Fig. 1). Our testbed consists of four different components. The core of our system is our vehicular communication nodes (Figs. 1a and 1c). These devices are responsible for generating, transmitting and receiving all the ITS-G5 network interactions between the vehicles and the road-side infrastructure. Sec. II-A will present both devices with further details.

Our communication devices record all the ITS-G5 interactions onto a data storage unit. As for the RSUs, this is a server connected to the network of the University of Bristol. In the case of the OBUs, the data storage facility is provided by a Raspberry Pi connected to a Solid-State Drive (SSD) hard drive, and then interfaced to the communication node by means of a $100\text{\,}\mathrm{Mbit}$ Ethernet link (Fig. 1a).

The onboard clock pertaining to each device are usually prone to drift, typically because of the inexpensive crystal oscillator circuits they employ. Moreover, different devices may exhibit vastly different behaviors when subject to vibration or shocks. In order to reduce the drifting on each clock, we connected both our communication nodes to a Network Time Protocol (NTP) unit. We chose LeoNTP [14] as our NTP server solution, which is a Stratum 1 NTP server synchronized via Global Positioning System (GPS). That is, we ensured a high degree of synchronization between the devices. Also, to account for the drifting due to vibrations or shocks (especially for the mobile devices), we forced each device to periodically re-synchronize its clock with the NTP server (every $30\text{\,}\mathrm{s}$).

Finally, our system was equipped with a Global Navigation Satellite System (GNSS) GPS receiver [15]. The GPS receiver has been used to both fulfill the time synchronization task and providing accurate positioning information. In the next section, we will present how we encapsulated the position and the timestamps within each ITS-G5 message. Detailed specifications of the NTP server and the GPS receiver can be found in Table LABEL:table:gpsNTP.

II-A Vehicular Communication Infrastructure

Our vehicular communication nodes consist of the following three key components. A single-board computer and two wireless transceivers connected to their accompanied antennas. The single board computer provides the processing power needed to operate the ITS-G5 stack. For that, we adopted a Mikrotik RB433 RouterBoard (with CPU $300\text{\,}\mathrm{MHz}$, $64\text{\,}\mathrm{MB}$ RAM, $64\text{\,}\mathrm{MB}$ storage space, x3 Ethernet slots, x3 MiniPCI slots) [16]. As for the transceivers, we employed two types of mini-PCI Network Interface Controllers (NICs) that were responsible for the exchange of the ITS-G5 Cooperative Awareness Messages (CAMs). Both the NICs have been operated by means of customized Linux Kernel drivers making the NICs IEEE 802.11p/DSRC-compliant. The first NIC model was a Mikrotik R52H [17] operating at $25\text{\,}\mathrm{dBm}$, and regarded as the low-power (LP) NIC for the remaining of the paper. The second NIC, regarded as the high-power (HP) transceiver, was a Mikrotik R5SHPn [18] with $29\text{\,}\mathrm{dBm}$ maximum transmission power. These two wireless interfaces were installed on both the RSUs and the OBUs.

We adopted the system design for both RSUs or OBUs, with the only difference between them being the adopted antennas. For each RSU, antennas are bolted onto the device while each OBU, being secured in the boot of each vehicle (Fig. 1b), is connected to an antenna set magnetically attached on its rooftop (Fig. 1d). In particular, as for the RSU, each NIC was connected to a dipole antenna with a gain of $7\text{\,}\mathrm{dBi}$. On the other hand, each OBU NIC was connected to a dipole antenna with a gain of $5\text{\,}\mathrm{dBi}$. Our RSU devices were powered up via Power-over-Ethernet (PoE), while a battery pack was used for the OBUs to avoid fast fluctuations in current as a result of using inverters connected to lighter-style sockets. For simplicity, we will refer to the different transceivers and devices by means of a combination of their abbreviations (for e.g., LP-RSU will stand for the low power transceiver of an RSU). The specifications of each device used in our trials are summarized in Table II.

II-B Vehicular Communication Operative System

The operating system chosen for our devices was a low-latency OpenWRT Linux distribution111OpenWRT Barrier Breaker Release no. 14.07 - https://openwrt.org/. Each transceiver operates on top of a different Atheros chipset and requires a different driver. The HP transceivers, operating via the AR9220 chipset, require the ath9k Linux driver while the LP ones, hosting an AR5414 chipset, require the ath5k Linux driver. Both were modified accordingly to enable IEEE 802.11p/DSRC functionalities [13]. The Linux kernel modules that we modified have been summarized in Fig. 2.

The software modules cfg80211 and nl80211 bridge the user and kernel space and offer the utility functionalities associated with 802.11. The mac80211 subsystem is the general driver framework and allows finer control of the hardware. The iw tool is used for configuring the utility of the NIC and is based on the nl80211 netlink interface. Furthermore, cfg80211_ops and ieee80211_ops define the operations and the callbacks between the different blocks. The Outside the Context of a BSS (OCB) mode was enabled in the MAC layer, allowing all NICs within range to communicate, without being authenticated/associated. Besides, the OCB mode commands were added in a modified version of the iw utility to enable the functionality mentioned above. The values for the contention windows and the MCSs were chosen to follow the regulations for the ITS-G5 standard specifications.

II-C IEEE 802.11p/DSRC CAMs and Logging Interfaces

In our system, IEEE 802.11p/DSRC CAMs are exchanged between all the devices. All CAMs are generated in the Facilities layer of the ITS-G5 stack [19]. The Facilities layer is responsible for handling all the packets generated from the different ITS application, such as the CAMs or the Decentralized Environmental Messages (DENMs). Then, the Facilities layer forwards all the generated messages to the lower protocol layers that are responsible for the actual transmission.

In our testbed, we built on top of a pre-existing ITS-G5 stack [13] and we implemented a beaconing interface in charge of generating CAMs. To log all these network interactions we designed two different logging interfaces. The first one records the exchanged CAMs as CSV-formatted files, while the second stores them as PCAP traces. The first format enabled us to easily reconcile the sequences of received and transmitted CAMs – thus enabling us to quickly extract preliminary communication metrics. Then, PCAP traces enable experts to investigate further key performance indicators not considered in this paper and not already included in the CSV-formatted part of our dataset.

Considering the CSV-formatted part of our dataset, the data are organized in a tabular format with their fields summarized in Table III. In particular, for what concerns the transmitted CAMs (namely, TX side), the position acquired from the GPS is represented as GpsLon and GpsLat, these being the longitude and latitude values of the transmitter, respectively. The fields CamLon and CamLat are the quantized values of the GPS that are encapsulated in a CAM. The sequence number of the generated CAMs is shown in the SeqNum field (starting from zero when each device boots up). This value can be later used to correlate the list of transmitted and received CAMs. The GpsSpeed and CamSpeed represent the speed of the vehicle, with the first being the acquired value from the GPS and the latter the quantized value encapsulated in the CAM. The Timestamp is the time that the packet is generated, given in Unix Epoch format. Finally, the CamLength is the length of the transmitted CAM in bytes.

For what concerns the received CAMs (namely, RX side), the most important fields are the following. The RxMAC is the source MAC address. CamLon and CamLat are the source node position coordinates encapsulated in the received packet. The GpsLon and GpsLat values represent the current longitude and latitude of the receiver, acquired from the GPS receiver and quantized later. The Timestamp field is the time that a CAM is received, given in Unix Epoch format and SeqNum is the encapsulated sequence number of the CAM received.

On both sides, the fields TX-REQ-CAM and RX-REQ-CAM, are used to tell if a specific log entry refers to a transmitted or received CAM. Finally, fields such as Protocol, Validation, GenDeltaTime, VehHeading and StationID have not been considered in our performance investigation.

As for the PCAP traces, they include all the exchanged network interactions. PCAP traces, being the industrial and scientific format for raw-data recording for network applications, are compatible with a wide variety of programs and provides direct access to the binary-level of the network exchanges. In addition, every received message is recorded along with its RSSI value, which is one of the key metrics that will be considered in our performance investigation. The entire database with our exchanged network interactions can be found in [20]. More details about the way these data are stored or could be potentially used in the future can be found in [21]. Finally, a repository with all the scripts used to parse and process the results can be found in [22].

III Vehicular Trials

For our experimental evaluation, we deployed four RSUs around the campus of the University of Bristol. The positions of the RSUs are shown in Fig. 3 (marked with the red X’s). To maximize the heterogeneity in terms of the road and building layout and investigate how these factors affect the network performance, we positioned our RSUs in the four positions shown on the map with the following characteristics:

• •

Merchant Ventures Building (MVB): The RSU is mounted at a balcony of the building, close to a blind T-junction, on a curvy road at a height of ~$8\text{\,}\mathrm{m}$.

• •

Dorothy Hodgkin (DH) building: Curvy wide road, one of the main arteries of the City of Bristol, UK. The RSU is mounted at the balcony at ~$12\text{\,}\mathrm{m}$, providing good Line-of-Sight (LOS) coverage on the curved road.

• •

Hawthorns (HW) building: Straight road with light foliage on one side of the RSU. The RSU is mounted on a wall of a building at ~$5\text{\,}\mathrm{m}$.

• •

Students Union (SU) building: Straight road, RSU mounted at a balcony at ~$25\text{\,}\mathrm{m}$. This site provides full coverage on the road in front of the building and between the two roundabouts.

For simplicity, in the rest of this paper, we will refer to all the RSUs with their abbreviation.

During our trials, two vehicles have been used. Both the vehicles followed the same route that is shown in Fig. 3. One vehicle was driving in a clockwise direction, while the other one was driving anti-clockwise. Each vehicle was equipped with an OBU as discussed before.

During the four days of trials, we measured the performance of the system over different frequencies. More specifically, during the first day, we tested the performance over the DSRC frequency band. The findings from this day were later compared against the measurements from days 2-4, where we operated our system over three different ISM-2.4 and ISM-5 bands. Details about the center frequency where our system has been operated is summarized in Table IV.

IV Performance Investigation

Various Key Performance Indicators (KPIs) were used to observe the impact of operating an ITS-G5 system over ISM bands, from the perspective of both the OBUs and RSUs. As discussed in Sec. III, our experimental trials lasted for four days. Every day, we conducted our trials during two different sessions (morning/afternoon). All the results presented in this section, will be the average of each day, namely, the average of both the morning and the afternoon session.

All the devices in our system generated and transmitted one ITS-G5 CAM per NIC every $10\text{\,}\mathrm{ms}$. Each CAM was then logged in a two-way fashion, as discussed in Sec. II-C. The overall CAM size CamLength was always 109 bytes. During our field trials, there was no provision for cyber-security related features. Each day a different frequency was chosen (Table IV). The LP transceiver was operated at the ISM-2.4 frequency band while the HP one was operated at the ISM-5.

Fig.5 shows the PDR as it is perceived at the RSU-side. This particular figure refers to the experiments run in the DSRC band (day 1) and the HP transceivers. The displayed PDR is the average of all the packet delivered over the packets transmitted from each OBU, when driving within the boundaries of a map squared tile that are $$5\text{,}\mathrm{m}$^{2}$ wide. As such, each tile covers roughly the width of a road lane. As expected, being the DH-RSU installed higher up on the building, it provides the best coverage amongs all the RSUs. DH-RSU is followed by the SU-RSU, MVB-RSU and finally by the HW-RSU providing the worst coverage range and PDR. In addition, compared to the HP tranceiver, the performance of the LP transceiver is on average $25\%$ lower for the first day.

Table V presents the Mean-Squared Error (MSE) and the Mean Absolute Difference (MAD) of the PDR per-tile. This table compares the results from the first day of experiments (DSRC experiment) against the results from the remaining days (ISM experiments). In particular, for the LP transceivers, we observe that both KPIs are comparable for all days, showing marginal variations. On the other hand, in the case of HP transceivers, we observe a more significant alteration during the third day, which can be caused by a different level of interference in the considered ISM frequency (namely, the IEEE 802.11a channel 36).

Fig. 5 also shows the MSE per tile, for the area around the DH-RSU and the HP transceiver. This figure is the comparison of the ISM-5 band with the DSRC one, for the worst case scenario we observed before (Table V). The MSE significantly increases as we move away from the DH-RSU. The increased interference from the surrounding WiFi networks and the attenuated signal because of the RSU-OBU distance increases the packet loss. A similar behavior can be observed around the surrounding areas of the remaining RSUs and for all days. The above behaviour shows that on both frequency bands, the PDR performance for closer distances is comparable. Of course, for longer distances impact of the interference from the surrounding devices is more observable.

Figs. 9 – 9 show the awareness horizon from the perspective of one vehicle. The awareness horizon is defined as the PDR perceived from an OBU as a function of the Euclidean distance to an RSU. Having the average PDR per distance interval, we can have an indication of the perceived awareness at the receiver side, based on the sensor data that the transmitter managed to successfully send. Fig. 5 and Table V show that the worst system behavior, compared a system operated onto the DSRC band, was on our third day of trials. The best RSU (in terms of PDR and coverage) was the DH-RSU, while the worst being the HW-RSU. Figs. 9 and 9 refer to the first day, for DH-RSU (top) and HW-RSU (bottom) and both transceivers. On the other hand, Figs. 9 and 9 are equivalent results referring to the third day. As expected, the HP transceivers, due to their increased transmission power manage to achieve increased PDR for longer distances, compared to the LP ones. For the HP transceiver and a distances smaller than $80\text{\,}\mathrm{m}$, we see that the DH-RSU has comparable performance for all the different frequencies. However, for a distance greater than $80\text{\,}\mathrm{m}$, the impact of the interference is considerably worse. However, this is not the case for the LP transceiver. Even though the ISM-2.4 is heavily congested, we see that due to the lower operational frequency, we get comparable results on both days and RSUs. For distances smaller than $80\text{\,}\mathrm{m}$, HW-RSU performs slightly better in the DSRC frequency band. This behavior is believed to be due to the position of the RSUs. HW-RSU, located very close to various university’s buildings and students accommodations, is heavily impaired by interferences. However, as shown, for longer distances, the decreased signal attenuation due to the frequency almost compensates with the effects of the existing interference. The decreased signal attenuation due to the frequency is confirmed in Figs. 11 and 11. These figures show the perceived average RSSI for each map-tile. In particular, we observe that the RSSI of CAMs transmitted when the system is operated at the ISM-2.4 frequency band is significantly higher compared to the case when we refer to DSRC or ISM-5 bands, as expected.

V Conclusions

In this work we presented a large-scale performance investigation for the feasibility of operating an ITS-G5 system over unlicensed frequency bands. We conducted our performance evaluation using our prototyped real-world ITS-G5 testbed. Our experimental testbed was operated on both the licensed DSRC and the corresponding unlicensed ISM frequency bands. We compared the performance using different communication metrics, such as the PDR and the RSSI. From the presented results we showed that our system achieved comparable performance against DSRC, over the ISM-2.4 frequency band, while having an increased PDR of roughly $30\%$, when operated over the ISM-5 band. During the time of the trials, we were the only users over the DSRC band. Given the expected market penetration of CAVs, the licensed band results are expected to be worse in the future. Taking that into account, and given our experimental results we believe that operating an ITS-G5 system over the ISM frequency bands, and especially over the ISM-2.4 band, is a viable option for the future. To increase the reproducibility of the results, as well as pave the way for future research avenues (e.g. on deriving empirical models or exploiting cyber-security attacks), we recorded all the network interactions in a two-folded fashion and made our generated database publicly available.

Acknowledgment

This work is part of the FLOURISH Project, which is supported by Innovate UK, under Grant 102582.