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. 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. 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 [2, 3]. 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 .
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 . 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  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 , sharing a very narrow licensed frequency band (namely, -). 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 .
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 - (hereafter referred to as “ISM-2.4”) and - (hereafter referred to as “ISM-5”). In order to do so, we deployed multiple ITS-G5 Road-Side Units (RSUs) along a 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 , over a period of time of four days. 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 . On the other hand, [7, 10] 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 overage, when the system is operated over the considered ISM-5 bands, the PDR is no more than 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).
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. (a)a and (c)c). 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 Ethernet link (Fig. (a)a).
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  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 ).
Finally, our system was equipped with a Global Navigation Satellite System (GNSS) GPS receiver . 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.
|NTP Server |
|Stratum Level||Stratum 1|
|GNSS GPS receiver |
|Position Acquisition Time|
|Oscillator Type||Crystal (Real-time clock support)|
|Update Rate||up to|
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 the ITS-G5 stack to operate. For that, we adopted a Mikrotik RB433 RouterBoard (with CPU , RAM, storage space, x3 Ethernet slots, x3 MiniPCI slots) . As for the transceivers, we employed two kinds 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 , regarded as the low-power (LP) NIC and operating at . The second NIC, regarded as the high-power (HP) transceiver, was a Mikrotik R5SHPn  with 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. (b)b), is connected to an antenna set magnetically attached on its rooftop (Fig. (d)d). In particular, as for the RSU, each NIC was connected to a dipole antenna with a gain of . On the other hand, each OBU NIC was connected to a dipole antenna with a gain of . 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 . 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 . 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  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 the easly 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.
|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) ||RX-REQ-CAM||Type of packet|
|StationID||Dummy field with random value ||Validation||Show if constraints failed in ASN.1 |
|GenDeltaTime||The remainder of ||Protocol||Dummy field (is always 1) |
|SeqNum||Sequence number of transmitted packet||StationID||The StationID of the transmitter |
|GpsLon||Current longitude of the node||GenDeltaTime||The remainder of
at the moment of transmission
|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 |
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|
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. Being PCAP the industrial and scientific format for raw-data recording for network applications, it is 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 . More details about the way these data are stored or could be potentially used in the future can be found in . Finally, a repository with all the scripts used to parse and process the results can be found in .
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 ~.
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 ~, 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 ~.
Students Union (SU) building: Straight road, RSU mounted at a balcony at ~. 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.
|Day||HP Transceiver||LP Transceiver||Band|
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 . 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.
|Day||MAD HP||MAD LP||MSE HP||MSE LP|
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 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 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 , we see that the DH-RSU has comparable performance for all the different frequencies. However, for a distance greater than , 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 , 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.
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 , 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 cybersecurity attacks), we recorded all the network interactions in a two-folded fashion and made our generated database publicly available.
This work is part of the FLOURISH Project, which is supported by Innovate UK, under Grant 102582.
-  D. Evans, “The Internet of Things,” Cisco IBSG, Tech. Rep., Apr. 2011. [Online]. Available: https://www.cisco.com/c/dam/en_us/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf
-  “Preliminary Statement of Policy Concerning Automated Vehicles,” U.S. Department of Transportation, National Highway Traffic Safety Administration (NHTSA), Tech. Rep., 2013. [Online]. Available: http://www.nhtsa.gov/staticfiles/rulemaking/pdf/Automated_Vehicles_Policy.pdf
-  “C-ITS Platform,” European Commission, Tech. Rep., Jan. 2016. [Online]. Available: http://ec.europa.eu/transport/themes/its/doc/c-its-platform-final-report-january-2016.pdf
-  “5G-PPP White Paper on Automotive Vertical Sector,” 5G Infrastructure Public Private Partnership, Tech. Rep., Oct. 2015. [Online]. Available: https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-White-Paper-on-Automotive-Vertical-Sectors.pdf
-  N. Lu, N. Cheng, N. Zhang, X. Shen, and J. W. Mark, “Connected Vehicles: Solutions and Challenges,” IEEE Internet Things J., vol. 1, no. 4, pp. 289–299, Aug. 2014.
-  E. G. Strom, “On Medium Access and Physical Layer Standards for Cooperative Intelligent Transport Systems in Europe,” Proc. of the IEEE, vol. 99, no. 7, pp. 1183–1188, Jul. 2011.
-  J. Lansford, J. B. Kenney, and P. Ecclesine, “Coexistence of Unlicensed Devices with DSRC Systems in the 5.9 GHz ITS Band,” in Proc. of IEEE VNC 2013, Boston, Massachusetts, USA, Dec. 2013, pp. 9–16.
-  P. Wang, B. Di, H. Zhang, K. Bian, and L. Song, “Cellular V2X Communications in Unlicensed Spectrum: Harmonious Coexistence With VANET in 5G Systems,” IEEE Trans. Wireless Commun., vol. 17, no. 8, pp. 5212–5224, Aug. 2018.
-  M. Fadda, M. Murroni, and V. Popescu, “Interference Measurements for Unlicensed 802.11p Communication in the TV Bands,” in Proc. of IEEE International Symposium on Broadband Multimedia Systems and Broadcasting 2015, Ghent, BE, Jun. 2015.
-  B. Cheng, H. Lu, A. Rostami, M. Gruteser, and J. B. Kenney, “Impact of 5.9 GHz Spectrum Sharing on DSRC Performance,” in Proc. of IEEE VNC 2017, Torino, IT, Nov. 2017, pp. 215–222.
-  I. Mavromatis, A. Tassi, R. J. Piechocki, and A. Nix, “A City-Scale ITS-G5 Network for Next-Generation Intelligent Transportation Systems: Design Insights and Challenges,” in Ad-hoc, Mobile, and Wireless Networks, N. Montavont and G. Z. Papadopoulos, Eds. Cham: Springer International Publishing, 2018, pp. 53–63.
-  “LeoNTP Networked Time NTP Server Data Sheet.” [Online]. Available: http://www.leobodnar.com/shop/index.php?main_page=product_info&cPath=120&products_id=272
-  “GNSS GPS receiver u-blox NEO-6P Data Sheet.” [Online]. Available: https://www.u-blox.com/en/product/neo-6p-module
-  “Mikrotik RB433 Data Sheet.” [Online]. Available: https://mikrotik.com/product/RB433
-  “Mikrotik R52H Data Sheet.” [Online]. Available: https://mikrotik.com/product/R52H
-  “Mikrotik R5SHPn Data Sheet.” [Online]. Available: https://routerboard.com/R5SHPn
-  “Specification of Cooperative Awareness Basic Service – EN 302 637-2,” ETSI, Tech. Rep., Nov. 2014.
-  R. Piechocki, I. Mavromatis, and A. Tassi, “Database: Operating ITS-G5 DSRC over Licensed and Unlicensed Bands: A City-Scale Performance Evaluation,” mar 2019. [Online]. Available: https://doi.org/10.5523/bris.eupowp7h3jl525yxhm3521f57
-  I. Mavromatis, A. Tassi, and R. J. Piechocki, “A Dataset of Full-Stack ITS-G5 DSRC Communications over Licensed and Unlicensed Bands Using a Large-Scale Urban Testbed,” arXiv e-prints, Mar 2019, [Online]. Available: https://arxiv.org/abs/1903.10289.
-  “ITS-G5 Trials scripts – Files to Parse and Process the Dataset files.” [Online]. Available: https://github.com/v2x-dev/ITS-G5_trials