ThesisPDF Available

Analysis of V2X Performance and Rollout Status with a Special Focus on Austria


Abstract and Figures

Vehicle to Everything (V2X) has the potential to make road traffic safer and further advance autonomous driving. The goal of this work is to evaluate the performance and roll-out status of V2X in real life. Previous work shows very different results, both with simulations and with real hardware. To evaluate the performance of V2X in real life, six test runs were performed: (i) three scenarios to evaluate official V2X projects, (ii) two scenarios to evaluate V2X performance under optimal conditions, and (iii) one scenario to evaluate the VW Golf 8. The data was collected using a V2X monitor and analyzed in order to answer three questions: (i) the roll-out status, (ii) the difference between practical applications and specification and (iii) the performance of V2X. The results show that V2X works well and meets expectations, but the roll-out is slow.
Content may be subject to copyright.
Andrea Ulbel, BSc
Analysis of V2X Performance
and Rollout Status with a Special Focus on Austria
to achieve the university degree of
Master’s degree programme: Information and Computer Engineering
submitted to
Graz University of Technology
Daniel Watzenig, Univ.-Prof. Dipl.-Ing. Dr.techn.
Institute of Automation and Control
Graz, April 2021
I declare that I have authored this thesis independently, that I have not
used other than the declared sources/resources, and that I have explicitly
indicated all material which has been quoted either literally or by content
from the sources used. The text document uploaded to TUGRAZonline is
identical to the present master’s thesis.
Date, Signature
Vehicle to Everything (V2X) has the potential to make road traffic safer and further
advance autonomous driving. The goal of this work is to evaluate the performance and
roll-out status of V2X in real life. Previous work shows very different results, both with
simulations and with real hardware. To evaluate the performance of V2X in real life, six
test runs were performed: (i) three scenarios to evaluate official V2X projects, (ii) two
scenarios to evaluate V2X performance under optimal conditions, and (iii) one scenario
to evaluate the VW Golf 8. The data was collected using a V2X monitor and analyzed
in order to answer three questions: (i) the roll-out status, (ii) the difference between
practical applications and specification and (iii) the performance of V2X. The results
show that V2X works well and meets expectations, but the roll-out is slow.
This master thesis was realized at the Institute of Automation and Control at the Graz
University of Technology in cooperation with VIRTUAL VEHICLE Research Center in
I would like to thank everyone at Virtual Vehicle who supported me. Thanks to Joachim
Hillebrand, who is always available with advice and knowledge. I would also like to
extend my gratitude to Christoph Pilz, who supported me every step along the way, not
only during the test drives but also during the lengthy process of writing this thesis.
Thank you to Daniel Watzenig for making this thesis possible and providing me with
Lastly, I would like to thank my family and friends who brought endless coffee and
This thesis was funded by InSecTT and COMET K2 Competence Centers. InSecTT
( has received funding from the ECSEL Joint Undertaking (JU) under
grant agreement No 876038. The JU receives support from the European Union’s Hori-
zon 2020 research and innovation programme and Austria, Sweden, Spain, Italy, France,
Portugal, Ireland, Finland, Slovenia, Poland, Netherlands, Turkey. The document re-
flects only the author’s view and the Commission is not responsible for any use that may
be made of the information it contains.
The thesis was written at Virtual Vehicle Research GmbH in Graz and partially funded
within the COMET K2 Competence Centers for Excellent Technologies from the Aus-
trian Federal Ministry for Climate Action (BMK), the Austrian Federal Ministry for
Digital and Economic Affairs (BMDW), the Province of Styria (Dept. 12) and the
Styrian Business Promotion Agency (SFG). The Austrian Research Promotion Agency
(FFG) has been authorised for the programme management.
Acronyms 17
1 Introduction 21
1.1 MotivationandGoals ............................. 22
1.2 Outline ..................................... 22
2 Problem Formulation 23
3 V2X Communication 25
3.1 General ..................................... 25
3.1.1 V2XApplications ........................... 26 RoadSafety ......................... 26 Traffic Efficiency Management . . . . . . . . . . . . . . . 26 Infotainment . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.2 V2XMessages ............................. 27 CAM ............................. 27 DENM ............................ 28 IVIM ............................. 29 Intersection Protocols . . . . . . . . . . . . . . . . . . . . 29
3.2 ETSIC-ITS................................... 30
3.2.1 Origin: IEEE 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 AccessLayer .............................. 32 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . 32 Data Link Layer . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Network and Transport Layer . . . . . . . . . . . . . . . . . . . . . 33
3.2.4 FacilityLayer.............................. 33
3.2.5 ApplicationLayer ........................... 34
3.2.6 ManagementLayer........................... 34
3.2.7 SecurityLayer ............................. 34
3.2.8 Decentralized Congestion Control (DCC) . . . . . . . . . . . . . . 34 DCC Algorithms . . . . . . . . . . . . . . . . . . . . . . . 35 DCC Architecture . . . . . . . . . . . . . . . . . . . . . . 36
3.3 C-V2X...................................... 37
3.3.1 Communication Interfaces . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Architecture .............................. 38
3.4 Evolution .................................... 39
3.4.1 802.11bd ................................ 39
3.4.2 5GNRC-V2X ............................. 40
3.4.3 Regulations............................... 40
4 Preparation 41
4.1 Hardware .................................... 41
4.2 Software..................................... 42
4.2.1 C-ITS Communication Logger . . . . . . . . . . . . . . . . . . . . 42
4.2.2 C-ITS Communication Data Extraction Tool . . . . . . . . . . . . 44
4.3 TestDrives ................................... 45
4.3.1 GrazA2Motorway........................... 45
4.3.2 Vienna.................................. 45
4.3.3 Italy - South Tyrol . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4 Distance Measurement Under Optimal Conditions . . . . . . . . . 47
4.3.5 Distance Measurement in an Urban Environment . . . . . . . . . . 47
4.3.6 Test Drive of a V2X Equipped Car . . . . . . . . . . . . . . . . . . 47
5 Results 49
5.1 GrazA2Motorway............................... 49
5.2 Vienna...................................... 53
5.3 Italy ....................................... 57
5.4 Distance Measurement Under Optimal Conditions . . . . . . . . . . . . . 59
5.5 Distance Measurement in an Urban Environment . . . . . . . . . . . . . . 63
5.6 Signal Strength Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.7 Test Drive of a V2X Equipped Car . . . . . . . . . . . . . . . . . . . . . . 65
6 Discussion 67
6.1 The Actual Roll Out Status of ITS-G5 . . . . . . . . . . . . . . . . . . . . 67
6.2 How do Practical Applications Differ from Theoretical Specifications? . . 68
6.3 What is the Real Life Performance of ITS-G5? . . . . . . . . . . . . . . . 69
6.3.1 Maximum Transmission Distance . . . . . . . . . . . . . . . . . . . 69
6.3.2 Connection Quality . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3.3 MissingChecksum ........................... 70
7 Conclusion and Future Work 71
7.1 Conclusion ................................... 71
7.2 FutureWork .................................. 71
Bibliography 73
List of Figures
3.1 V2X communication [7] [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Structure of the Cooperative Awareness Message (CAM) [14] . . . . . . . 27
3.3 Structure of the Decentralized Environmental Notification Message (DENM)
[16]........................................ 28
3.4 Structure of the Infrastructure to Vehicle Information Message (IVIM) [18] 29
3.5 European Telecommunications Standards Institute (ETSI) Intelligent Trans-
port System (ITS) architecture [8] . . . . . . . . . . . . . . . . . . . . . . 31
3.6 System architecture of ETSI ITS [8] . . . . . . . . . . . . . . . . . . . . . 32
3.7 ETSI ITS architecture stack with DCC [34] . . . . . . . . . . . . . . . . . 34
3.8 The reactive approach[35] . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.9 C-V2X communication interfaces [37] [38] . . . . . . . . . . . . . . . . . . 37
3.10 The ETSI ITS architecture using C-V2X for the access layer[43] . . . . . . 38
4.1 The Siemens ESCoS Roadside Unit . . . . . . . . . . . . . . . . . . . . . . 42
4.2 The Cohda MK5 with an antenna . . . . . . . . . . . . . . . . . . . . . . 42
4.3 The Setup of the V2X Monitor . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Car with Mounted Cohda Antenna on the Roof . . . . . . . . . . . . . . . 43
4.5 Program flow of the ITS Communication Logger . . . . . . . . . . . . . . 44
4.6 V2X stations at A2 motorway at Graz. Created with . 45
4.7 V2X stations at S1, A4 and A23 motorway and at Handelskai in Vienna . 46
4.8 Route of the test drive in South Tyrol . . . . . . . . . . . . . . . . . . . . 46
4.9 Overview of the distance measurement campaign . . . . . . . . . . . . . . 47
4.10 Two positions of the RSU during the test drive . . . . . . . . . . . . . . . 48
5.1 Position of the RSUs (green) and one V2X-capable car (purple) along the
A2nearGraz[54]................................ 50
5.2 The achieved network coverage along the A2 near Graz. (Created with
Excel3DMap) ................................. 51
5.3 Screenshot of the weather on the day of the test drive [56] . . . . . . . . . 52
5.4 Screenshot from the DENM warning from heavy rain in Wireshark . . . . 52
5.5 The RSU positions in Vienna (in blue) and on the motorway (in red) [58] 53
5.6 Positions of encountered V2X capable cars in Vienna . . . . . . . . . . . . 54
5.7 Photo of an RSU mounted next to a traffic light at Handelskai and
Chrastekgasse.................................. 55
5.8 Visualized data from a MAPEM at Handelskai and Roman K¨ohler Steg
inVienna .................................... 56
5.9 RSU 12 with an underpass and the Rannersdorf tunnel in front . . . . . 56
5.10 The achieved network coverage along the test track on the S1, A4 and
A23aroundVienna............................... 57
5.11 The RSU positions between the Brenner and Stierzing on the A22 [59] . . 58
5.12 The achieved network coverage between the Brenner and Stierzing on the
A22 ....................................... 58
5.13 Map with the RSU position (green), the cut off points (blue) and the
maximum distance points (red) . . . . . . . . . . . . . . . . . . . . . . . . 60
5.14 The RSU with the straight road ahead . . . . . . . . . . . . . . . . . . . . 60
5.15 The signal quality degradation from the start left, to the stop right, at
trip#2 ..................................... 61
5.16 Histogram of the received packages at different distances of the car to the
RSU ....................................... 62
5.17 Positions where a DENM packet was received with the RSU positioned
attheground.................................. 63
5.18 Positions where a DENM packet was received with the RSU positioned
attheroof.................................... 63
5.19 Signal strength degradation over growing distances . . . . . . . . . . . . . 64
5.20 “Privacy and services was terminated unexpectedly. Please try again
later.” - VW Golf 8 Error Message . . . . . . . . . . . . . . . . . . . . . . 65
List of Tables
3.1 Adaptions of IEEE 802.11p in Europe, USA and Japan . . . . . . . . . . 32
3.2 ITS frequencies in Europe. [22][28][25] . . . . . . . . . . . . . . . . . . . . 33
5.1 Average CAM frequency and standard deviation, sample size, range, pro-
tocols and C-ITS versions sent per RSU in Graz . . . . . . . . . . . . . . 51
5.2 Average CAM frequency and standard deviation, sample size, range, pro-
tocols and C-ITS versions sent per RSU in Vienna . . . . . . . . . . . . . 54
5.3 Average CAM frequency and standard deviation, sample size, range, pro-
tocols and C-ITS versions sent per RSU in Italy . . . . . . . . . . . . . . . 59
5.4 Distances and signal strength at the cut off points and the furthest packet
receivedpertrip ................................ 61
5.5 Average, variance and standard deviation of cut off points and the furthest
packetreceived ................................. 61
5.6 The maximum distance between the RSU and the monitor where a packet
wasreceived................................... 64
5.7 The correlation and covariance between the distance and the signal strength
ofthreetestdrives ............................... 65
3GPP 3rd Generation Partnership Project 37
5G Fifth Generation 21, 39, 40
BSM Basic Safety Message 28
BSS Basic Service Set 31
BTP Basic Transport Protocol 33
C-ITS Cooperative Intelligent Transport Systems 30–36, 38, 39, 46, 49, 55, 58, 67, 68,
C-V2X Cellular Vehicle to Everything 21, 22, 25, 37–40, 71, 72
CA Cooperative Awareness 34
CAM Cooperative Awareness Message 27–29, 33, 34, 36, 49, 50, 53, 55, 57–59, 65, 67,
68, 71
CAN Controller Area Network 41
CBR Channel Busy Ratio 36, 39
CL Channel Load 36
CR Channel Occupancy Ratio 39
D2D Device-to-Device 37, 38
DCC Decentralized Congestion Control 27, 33, 35, 36
DENM Decentralised Environmental Notification Message 28, 29, 33, 36, 47, 50, 53,
57–59, 65, 67, 68, 70, 71
ETSI European Telecommunications Standards Institute 13, 23, 27–39, 68, 71
GPS Global Positioning System 41, 55
GUI Graphic User Interface 41
HF High Frequency 28
ID identifier 28
IEEE Institute of Electrical and Electronics Engineers 30–32
ISO International Organization for Standardization 30
ITS Intelligent Transport System 13, 28–32, 34, 41, 42, 49, 50, 53
ITS-G5 Intelligent Transport Systems - 5.9 GHz Vehicular Ad Hoc Network Physical
Layer 21–23, 25, 30, 32, 39, 40, 67–69, 71, 72
ITS-S Intelligent Transport System - Station 30, 35, 36, 46
IVIM In Vehicle Information Message 29, 50, 53, 58, 67, 71
LF Low Frequency 28
LLC Logical Link Control 33
LTE Long Term Evolution 21, 37–41, 71
MAC Media Access Control 33, 67
MAP Map Data 30, 53, 67, 72
MAPEM Map Data Extended Message 30, 55, 71
NR New Radio 39, 40
OBU On Board Unit 30, 41
OCB Outside the Context of a BSS 31, 32
OFDM Orthogonal Frequency-Division Multiplexing 31, 32
OSI Open Systems Interconnection model 32
PC5 Proximity-based Communication 5 37, 38
PDU Protocol Data Unit 28–30, 50
POI Point of Interest 47, 49, 53, 55
ProSe Proximity Services 38
PRR Package Receive Ratio 40
QAM Quadrature Amplitude Modulation 39
QPSK Quadrature Phase Shift Keying 39
RAT Radio Access Technology 25, 30, 37
RLAN Radio Local Area Network 33
RSU Road Side Unit 23, 27, 30, 37, 41, 45–51, 53, 55–59, 63–65, 67–71
SAE Society of Automotive Engineers 27, 29
SCI Sidelink Control Information 39
SPaT Signal Phase and Timing 30, 53, 67, 72
SPaTEM Signal Phase and Timing Extended Message 30, 55, 71
SREM Signal Request Extended Message 30, 67
SRM Signal Request Message 30
SSEM Signal Status Extended Message 30, 53, 67
SSH Secure Shell 43
SSM Signal Status Message 30
TB Transport Block 39
TC Traffic Class 36
TDC Transmit Datarate Control 35
TPC Transmit Power Control 35
TRC Transmit Rate Control 35
UDP User Datagram Protocol 33, 43
UE User Equipment 37–40
USB Universal Serial Bus 41
V2I Vehicle to Infrastructure 25, 37
V2N Vehicle to Network 26, 37
V2P Vehicle to Pedestrian 26
V2V Vehicle to Vehicle 25
V2X Vehicle to Everything 5, 13, 21–23, 25–27, 30, 31, 37–41, 45–49, 55, 65, 67, 70–72
1 Introduction
Traffic accidents are still a significant problem. In the EU, for example, 18,800 people
died in road accidents in 2020. This means that every half an hour, a person dies on the
road in the EU 1. Even though those numbers are going down over the last decades, the
EU set the goal to cut deaths on the road by 50% between 2010 and 2030 2. To achieve
this goal, new cars are equipped with many advanced technologies, such as distance
sensors, blind-spot detection, and lane change assistant, to increase road safety. To
reduce the fatalities even further, V2X could be a leading technology. V2X enables
vehicles to link and exchange information with each other, as well as infrastructure,
pedestrians, and the internet. With V2X awareness can be raised beyond the capabilities
of on board sensors to prevent accidents, such as rear-end collisions at the end of traffic
jams on the highway. Additionally, warnings from overhead displays could be displayed
for the driver, thereby increasing safety and driving experience.
V2X can also be an important building block for the steady progress of automated driv-
ing. While many new high-end cars now come with traffic sign recognition, it still has
significant problems recognizing additional information on road signs and crossed-out
signs. Road signs equipped with V2X could bring much progress to autonomous driving
development. Furthermore, V2X can help make complicated and confusing intersections
more understandable for autonomous driving. This is achieved by describing the inter-
section layout, including all the lanes and the status of the traffic lights. Lastly, V2X
can warn of hazardous events and communicate priority at intersections.
For both of these use cases — cooperative awareness and traffic information — V2X is
a key issue as it enables vehicles to communicate with each other and the environment.
V2X works on broadcast-based, wireless packets that can be received and sent by vehi-
cles, infrastructure, by global networks such as the internet, and in the future possibly by
pedestrians. Currently, there are two V2X technologies fighting for the market: Intelli-
gent Transport Systems - 5.9 GHz Vehicular Ad Hoc Network Physical Layer (ITS-G5),
which is based on the WiFi technology, and Cellular Vehicle to Everything (C-V2X),
which is based on the Long Term Evolution (LTE) technology (and subsequently on the
Fifth Generation (5G) technology).
1 accessed 21.04.2021
accessed 20.03.2021
1.1 Motivation and Goals
Although the use of V2X is starting to grow, it is still challenging to find information.
Additionally, there are currently two competing technologies, ITS-G5 and C-V2X, and
it is not yet decided which technology will prevail. Hence, this thesis wants to give the
theoretical background on both implementations, focusing on ITS-G5.
Because of the competition between ITS-G5 and C-V2X, many papers compare the
two technologies’ performance. Sometimes in favor of one, while others prefer the other
technology. Additionally, many sources only use simulations to evaluate the performance.
Therefore, another goal of this thesis is to find out more about the real-life performance
of V2X.
Finally, many Europe-wide projects are testing ITS-G5 in the field. These projects test
a wide variety of parameters on V2X-enabled devices on real roads. The final objective
is to log the information sent by these devices and evaluate the data.
1.2 Outline
Chapter 2 starts with the definition of central research questions. Chapter 3 then con-
tinues with a description of the idea behind V2X, the general use-cases, and the most
important V2X messages. Subsequently, the background of the two V2X technologies
are explained. Chapter 4 shows the preparation of the hardware needed for gathering
ITS-G5 data and the software developed for the project. Lastly, the location and goals of
six test campaigns are outlined. In Chapter 5 the data of the test drives is analyzed and
presented. Chapter 6 discusses the collected measurement data and described the data
described in the previous chapter. Lastly, Chapter 7 closes the thesis with a summary
and an outlook for future works.
2 Problem Formulation
In the last years, more and more research projects evaluated V2X functionality and
Europe’s ITS-G5 technology. The EU project C-Roads1alone covers 100.000 km of roads
with services involving ITS-G5. Additionally, VW rolled out the first V2X-capable mass-
produced car in 2019. Now it would be important to not only simulate ITS-G5 vehicles
but to measure real-world performance and collect data about real-world deployed Road
Side Units (RSUs).
Therefore three main objectives have been defined and are evaluated in this thesis:
(i) what is the actual rollout status of ITS-G5, (ii) how do practical applications differ
from theoretical specifications, and (iii) what is the real-life performance of ITS-G5?.
Actual Roll Out Status of ITS-G5 The ITS-G5 standard already looks back on ten
years of experience, with its standardization in 2010 [1]. Recently, in December 2019,
the first mass-produced car equipped with ITS-G5 was launched. How well has the
technology been adopted since then? What is the actual roll out status to date?
Difference Between Practical Application and Specification Theoretical specifica-
tions and practical applications usually differ at least a little. How much room for
interpretation does the ETSI standard leave? Are there even parameters of the actual
applications that violate the standard?
Real World Performance of ITS-G5 Many different publications are evaluating the
performance of ITS-G5. However, many of them are calculations and simulations, with
a broad gap in-between the estimations. For example, [2] shows in a simulation that to
receive every packet from a moving node, the distance to the sender should be smaller
than 138 meters. Anwar et al. [3] show a packet receive rate for 100-byte packets of zero
after 500 meters. Contrary to that [4] shows that a transmission range of 700 meters
should be achievable. Teixeira et al. [5] shows a drastic drop of the bitrate between 300
and 400 meters.
With all this different information, this work’s essential questions are: What is the
real-world performance of ITS-G5? How does the real-world data differ from the results
discussed above?
1 accessed 19.03.2021
3 V2X Communication
In this chapter, V2X communication will be discussed. First, the general architecture,
applications, and messages will be reviewed in Chapter 3.1. Afterwards the two com-
peting Radio Access Technologies (RATs) are analysed: (i) the wifi derived standard
802.11p, in Europe known as ITS-G51in Chapter 3.2, and (ii) the mobile network de-
rived standard Cellular Vehicle to Everything (C-V2X) in Chapter 3.3.
3.1 General
Cars are being equipped with more and more sensors to be able to perceive their sur-
roundings better and better. V2X was developed to share this environmental information
with other road users. In general, V2X describes all forms of communication between a
vehicle and any end point such as the infrastructure or another vehicle [6]. This com-
munication architecture with the four most important communication nodes is shown in
Figure 3.1.
Figure 3.1: V2X communication [7] [8]
Using Vehicle to Infrastructure (V2I), the car should gain the possibility to communi-
cate with road-infrastructure like traffic lights in order to get information, such as: the
current colour, or the seconds until it will be turning green again [9]. Other connected
infrastructure are traffic signs in order to communicate speed limits, construction sites
or the risk of congestion on highways.
Vehicle to Vehicle (V2V) is the communication link between vehicles [9]. They can
broadcast their position and inform each other about traffic conditions.
1Intelligent Transport Systems - 5.9 GHz Vehicular Ad Hoc Network Physical Layer (ITS-G5)
Vehicle to Network (V2N) enables cars to get information from the internet, like traffic
updates or infotainment data [10].
Lastly, Vehicle to Pedestrian (V2P) can be used to get information about pedestrians
(or other vulnerable road users) in order to prevent accidents [11].
3.1.1 V2X Applications
In order to utilize the full potential of V2X, a wide variety of applications and require-
ments have been defined.
To get a good overview in this thesis, the applications have been grouped like in [9].
The only adjustment made is that infotainment was added to the list. Road Safety
The applications most often associated with V2X are road safety use cases. These
V2X use cases have been defined in order to prevent road fatalities, reduce harm when
accidents are inevitable and lessen material damage.
Potential use cases in the road safety category, such as collision risk warning, stationary
vehicle warning, vulnerable road user, roadworks warning and hazardous location are
mentioned in [9]. Depending on the application, the minimum frequency of the message
broadcast and the maximum tolerable latency varies. For instance, a pre-crash sensing
warning is very time-critical since human reaction time needs to be taken into account.
Here, the minimum frequency is 10 Hz, and the latency needs to be less than 50 ms [9].
Depending on the type of warning, one can generalize that latency of tens of milliseconds
are needed in order to deploy road safety applications successfully [12]. Traffic Efficiency Management
Many different applications are covered by traffic efficiency management. It describes a
variety of applications that all have the goal to make traffic more efficient by preventing
traffic jams, minimizing waiting times at traffic lights and optimizing routes according
to current traffic.
Some examples for traffic efficiency management, according to [9], are traffic light opti-
mal speed advisory, intersection management and co-operative adaptive cruise control.
Compared to road safety, traffic efficiency management is less time-critical and have a
latency between 100 and 500 ms and a frequency between 1 and 10 Hz [9]. Infotainment
Infotainment or comfort applications provide data that enhance the driving experience,
but ,contrary to traffic efficiency management, do not influence the roads chosen [12].
Infotainment can be media download, streaming of music and videos, or maybe online
games for co-drivers.
In comparison to the applications mentioned before, low latency is not very important
for comfort applications; however, the amount of data that needs to be downloaded is
higher [12]. In [9] several applications are described that allow cars to access the internet
over RSUs.
3.1.2 V2X Messages
In order to provide data for the implementation of the applications described in Chapter
3.1.1, a variety of messages have been defined. However, these messages have been
regionally standardized and therefore differ from country to country. In the US, they have
been mostly defined by Society of Automotive Engineers (SAE). In Europe, ETSI is in
charge of defining V2X messages. This thesis focuses on the European implementations. CAM
According to [13], the Cooperative Awareness Message (CAM) is the central piece of
the ETSI protocol suite. The ETSI standard [14] specifies that the CAM informs other
road users about the vehicle’s position, driving direction, vehicle type (e.g. passenger
car, motorcycle, truck, ...) and should be used for road safety and traffic efficiency
management applications.
A CAM should be sent with a rate of 1 to 10 Hz, where 1 Hz is the default value [14].
Besides, the standard also states that CAMs are sent as broadcasts and are single hop,
which means they are not forwarded by other vehicles. It is important to know that
the default rate of 1 Hz is problematic and allows for inaccurate data when driving
with higher speeds, as mentioned by [15]. The CAM transmission frequency can also
be influenced by the Decentralized Congestion Control (DCC), which is described in
Chapter 3.2.8.
Figure 3.2: Structure of the Cooperative Awareness Message (CAM) [14]
The general structure of a CAM is shown in Figure 3.2. The ITS Protocol Data Unit
(PDU) Header provides very general information like the protocol version and the mes-
sage identifier (ID) as defined in [14]. The basic container includes information about
the vehicle type and the position and is mandatory [14]. The standard [14] defines, that
the High Frequency (HF) container consists of fast-changing data like heading, and is
also mandatory. The Low Frequency (LF) container, on the other hand, is optional and
contains static and slow-changing information like headlights information. Lastly, the
standard states that vehicles with special roles shall make use of the Special Vehicle
Container and provide further information.
The US-american pendant to CAM is the Basic Safety Message (BSM) [15]. DENM
Decentralised Environmental Notification Messages (DENMs) are event-driven messages
to inform, for instance, about a collision, road works or weather conditions [16]. The
ETSI standard defines that DENMs can be forwarded as long as the illustrated event is
still ongoing. Message termination can happen for two reasons: (i) a pre-defined timer
expires and (ii) a termination message is sent [16].
In order to keep messages about the event as up to date as possible, four types have
been defined that allow altering the event message [16]:
1. New DENM: the original DENM sent by a vehicle describing the event.
2. Update DENM: is used to update event information and must be sent by the
originated sender.
3. Cancellation DENM: informs about the event termination and must be sent by the
originated sender.
4. Negotiation DENM: works like the cancellation DENM but is sent by another
Figure 3.3: Structure of the Decentralized Environmental Notification Message (DENM)
Figure 3.3 depicts the structure of a DENM message. Similar to the CAM, the ITS
PDU Header of the DENM provides general information like protocol version and mes-
sage ID. The management container includes all information needed for the management
of the event, like detection time and event position [16]. The standard [16] defines that
the situation container gives further information about the event, such as the informa-
tion quality and a cause code which describes the kind of event that happened. ETSI
states that the location container includes further location information and the road
type. Lastly, the `a la carte container provides space for any further information and is
optional [16]. IVIM
In Vehicle Information Message (IVIM) is originally standardized in CEN ISO/TS 1932
[17]. In addition to the message the ETSI standard [18] also defines a facility layer
protocol and requirements. IVIMs are used to communicate the content of static and
dynamic road signs, such as (temporary) speed limits and road works warnings[18].
Figure 3.4: Structure of the Infrastructure to Vehicle Information Message (IVIM) [18]
The structure of the IVIM can be seen in figure 3.4. Apart from the ITS PDU header, the
message consists of three containers: (i) the management container that contains general
information about the IVIM in order for vehicles to decide if they want to further process
the message, (ii) the location container that informs about the zones where the IVIM
is valid, and (iii) the application container that adds additional information as well as
the spacial validity [18] [17]. There can be one or more of each location and application
container [18] . Intersection Protocols
Intersections are often particularly dangerous because lane routing is not always intuitive,
intersections can be confusing and sometimes vehicles have to yield despite green traffic
lights. Therefore 4 protocols have been standardized originally by SAE [19] and the
International Organization for Standardization (ISO) [20] with a focus on intersection
safety: Signal Phase and Timing (SPaT), Map Data (MAP), Signal Status Message
(SSM) and Signal Request Message (SRM). ETSI also included those 4 protocols in
their protocol suite [21]. Since ETSI added the ITS PDU headers to the message,
they are called Signal Phase and Timing Extended Message (SPaTEM), Map Data
Extended Message (MAPEM), Signal Status Extended Message (SSEM) and Signal
Request Extended Message (SREM) in the ETSI architecture [21].
Map Data (MAP) MAP describes the topology of the intersection: the width of the
road, the direction of each lane, connecting lanes, what kind of vehicles may use the lane
and also what signal group the lane belongs to [19][20]. Of course the information pro-
vided by MAP only makes sense if the vehicle has accurate and up-to-date geographical
data of the intersection.
Signal Phase and Timing (SPaT) SPaT includes information about the state of the
traffic light and at least the time until the current state will change [19][20]. This is done
by defining a Movement State container for every signal group.
Signal Request Message (SRM) and Signal Status Message (SSM): SRM allowes
vehicles to request a signal change and the answer of the ITS station is then sent using a
SSM, this enables the prioritization of traffic (e.g. public transport or ambulances) [19].
In order to enable V2X communication, ETSI standardized the ETSI Cooperative Intel-
ligent Transport Systems (C-ITS) architecture in [8]. It builds upon the RAT ITS-G5,
which makes some very minor changes to the original Institute of Electrical and Elec-
tronics Engineers (IEEE) 802.11p RAT standard [22]. The full protocol stack can be
seen in Figure 3.5.
The hardware system architecture of ETSI C-ITS can be seen in Figure 3.6. ITS-G5
capable network devices are usually called Intelligent Transport System - Station (ITS-
S). Figure 3.6 shows the two most frequently used ITS-S: a RSU and an On Board Unit
RSUs are fixed ITS-S that are usually attached to the road infrastructure. They
inform, among others, about road signs, construction works or speed limits using the
ITS-G5. They can be connected to a central traffic server, where they are controlled.
As mentioned in Section 3.1.1, RSUs might also be used for infotainment services and
connect vehicles to the internet. An OBU must be equipped with at least one ITS-G5
capable network device, but can also use other network technologies. In addition to the
ETSI C-ITS protocol stack, there must also be an interface to the car’s sensors as well
as an HMI interface to inform the driver can additionally be included.
Figure 3.5: ETSI ITS architecture [8]
The following chapters will first introduce IEEE 802.11p and its implementations in
Europe, the USA and Japan in Chapter 3.2.1. Later the layers of the ETSI C-ITS will
be explained starting at Chapter 3.2.2 about the access layer. Chapter 3.2.3 describes the
networking and transport layer, Chapter 3.2.5 the application layer, Chapter 3.2.6 the
management entity and Chapter 3.2.7 the security entity. Lastly Chapter 3.2.8 describes
the congestion control of ETSI ITS.
3.2.1 Origin: IEEE 802.11p
IEEE 802.11 [23] was first introduced in 1990 as a multipurpose WiFi standard. It
already included multiple options for various physical layer such as infrared. However,
802.11 has two major drawbacks that made the development of 802.11p necessary in
order to enable V2X communication: The connection setup takes a lot of time, and each
station can only be part of one Basic Service Set (BSS) at any given time [24].
Therefore, the WiFi standard was finally extended in 2010 by 802.11p. The amend-
ment allows communication in the allocated 5.9GHz band in 10 MHz channels [22]. The
Orthogonal Frequency-Division Multiplexing (OFDM) layer specification was adapted
from 802.11a. However, 802.11p uses a half-clock variant, and the channel size is halved
(from 20 MHz to 10 MHz) [22]. Additionally 802.11p introduced Outside the Context of
a BSS (OCB) Mode that allows communication without authentication, association, or
data confidentiality services. This means communication is possible without being part
of a BSS. Therefore, OCB Mode enables ad-hoc communication [22].
Table 3.1 shows the implementation of 802.11p in Europe, USA and Japan. The Euro-
pean and American implementations are very similar. In Japan, only a single channel
Figure 3.6: System architecture of ETSI ITS [8]
Europe [25] USA [26] Japan [27]
RAT standard ITS-G5 IEEE 802.11p ARIB STD-T109
Frequency range 5.855 GHz-5.925 GHz 5.850-5.925 GHz 755–765 MHz
Number of channels 7 7 1
Upper layer
protocol(s) ETSI C-ITS WAVE (IEEE 1609) ARIB STD-T109,
ITS Forum RC-013
Table 3.1: Adaptions of IEEE 802.11p in Europe, USA and Japan
in the 700 MHz band has been reserved for C-ITS applications.
3.2.2 Access Layer
The access layer of ITS-G5 consists of two Open Systems Interconnection model (OSI)
model layers: a physical layer and a data link layer [25]. Physical Layer
As defined in IEEE 802.11p the ITS-G5 physical layer uses 10 MHz channels, the half-
clock variant and OFDM. Different modulation schemes can be implemented, producing
a transfer rate around 3 to 27 Mb/s [25]. Additionally, OCB Mode needs to be enabled.
Seven channels are available for C-ITS applications [22]. These have been grouped
according to the type of application intended to use the frequency band. The ITS-G5A
channels are reserved for road safety applications and may only be used by ITS-G5
stations [28]. ITS-G5B channels are reserved for non-safety relevant applications (e.g.
traffic efficiency) [28]. Additionally, the standard [28] defines the two channels in ITS-
G5D are reserved for future applications. This can be seen in Table 3.2. When looking
at the naming of the C-ITS frequency band, ITS-G5C seems to be missing. However,
the name was previously used for Radio Local Area Network (RLAN) that also enables
ad-hoc communication [29].
frequency band
Number of
channels Application
ITS-G5A 5875-5905 MHz 3 ITS road safety
ITS-G5B 5855-5875 MHz 2 ITS non safety
ITS-G5D 5905-5925 MHz 2 future ITS applications
Table 3.2: ITS frequencies in Europe. [22][28][25] Data Link Layer
The data link layer consists of Logical Link Control (LLC) and Media Access Control
(MAC) [25]. While LLC is responsible for distinguishing network level protocols, MAC
schedules transmissions and deploys the access layer part of the DCC. DCC will be
discussed thoroughly in Chapter 3.2.8.
3.2.3 Network and Transport Layer
The tasks of the network and transport layer are routing the packets and packing the
data into individual data units. These tasks are performed by GeoNetworking and the
Basic Transport Protocol (BTP) at ETSI C-ITS. In addition, the protocol stack also
enables IPv6 packets to be sent via GeoRouting [30].
GeoNetworking GeoNetworking enables two particularly important services:
geographic addressing and geographic forwarding. Each node evaluates a received packet,
and if it is not the destination, the packet is forwarded. A location table is also main-
tained by every node for this purpose. GeoNetworking supports different addressing
types: GeoUnicast, GeoBroadcast and Topologically scoped broadcast. The latter sets
restrictions such as a single hop restriction. Additionally, an algorithm is used that de-
tects duplicated packets and does not forward them to avoid overloading the network.[31]
Basic Transport Service BTP is designed to be very lightweight and only provides
unreliable transport like User Datagram Protocol (UDP), which means packets may
arrive out of order, duplicated or not at all [32]. The main task of the BTP is multiplexing
different messages from the facility layer (e.g. CAM, DENM) for the transmission over
GeoNetworking [32].
3.2.4 Facility Layer
The facility layer is responsible for providing services to execute the messages described
in Section 3.1.2. In addition, it makes an Information Support Facility available, which
provides database management functions (e.g. to create a local dynamic map) [33].
The standard [33] also defines a Communication Support Facility, which takes care of
session management, for example [33]. Finally, there is a Management Facility, which is
responsible for communication with the management block [33].
An example for a service running in the facility layer is the Cooperative Awareness
(CA) basic service. In general, its tasks are encoding and decoding of CAMs, CAM
generation, management of the CAM transmission frequency, and handle information
from received CAM messages [14].
3.2.5 Application Layer
The application layer provides the services for the use cases defined in Section 3.1.1 by
using the ETSI C-ITS protocol stack [33].
3.2.6 Management Layer
The management entity is responsible for cross-layer exchange among different layers
and tasks, which is, for instance, important for congestion control. The management
entity supports, among others, an ITS service advertisement, which is responsible for
ITS application management like updating software and error handling [8].
3.2.7 Security Layer
The Security entity provides security and privacy functions for the whole protocol
stack. Examples include, firewall, authentication and authorisation, identity manage-
ment, hardware security modules [8].
3.2.8 Decentralized Congestion Control (DCC)
Figure 3.7: ETSI ITS architecture stack with DCC [34]
Figure 3.8: The reactive approach[35]
ETSI C-ITS deploys a cross-layer congestion control DCC, which is a mandatory part
for all ITS-Ss. The goal of the DCC is to maintain network stability, throughput, and
fair resource allocation. Furthermore, it should be possible to prioritize messages and
the sending of messages should be based on the current channel load [34].
The DCC architecture can be seen in Figure 3.7. The DCC CROSS entity is con-
nected to the DCC entities of the different layers with interfaces, depicted as 1-4 in
Figure 3.7. At the heart of the DCC architecture are the algorithms described in Chap-
ter, which calculate parameters to keep the network load within well-defined
limits. Chapter then goes into the individual layers of the DCC architecture and
explains which parameters are used and how. DCC Algorithms
ETSI TS 102 687 [35] defines three parameters that can be used to control the network
Transmit Power Control (TPC): If the network load is high, transmission power
can be reduced. This leads to a shorter transmission range of the ITS-S, which
means that the channel is free for farther away stations.
Transmit Rate Control (TRC): When the load is high, the time between two con-
secutive packets (called Tof f ) can be increased.
Transmit Datarate Control (TDC): A higher data rate can also be used to reduce
Ton time of a station.
The ETSI standard [35] defines two approaches to adjust the three parameters above
in order to reduce channel load:
Reactive Approach For the reactive approach different states are defined that go from
”Relaxed” (light load) to ”Restrictive” (overload), with n active states in between. For
every state, one or a mix of the three parameters from above are defined. The state
transitions are defined using Channel Busy Ratio (CBR) values. The state machine for
the reactive algorithm can be seen in Figure 3.8. a0to anare values for the CBR, these
state transitions are defined in [35] and [36].
Adaptive Approach The adaptive approach does not only take the current CBR values
as input, but also past calculations. The adaptive approach in [35] calculates a value
δthat describes the maximum fraction of time an ITS-S is allowed to use the channel.
The value of δdepends on the current CBR, a past δ, and constants defined in [35]. The
upper bound of δis defined with 3%, and the lower bound is 0.06%. DCC Architecture
The DCC architecture spans over most layers of the ETSI C-ITS stack. As depicted
in Figure 3.7, the entities of the DCC architecture are called: DCC ACC, DCC NET,
According to [34] the tasks of the DCC ACC entity are
The calculation of the CBR from the Channel Load (CL).
The prioritization of messages to be sent according to their Traffic Class (TC).
Temporarily storing of messages that cannot be sent right now in DCC queues. If
their lifetime expires during the waiting time, the messages are deleted and the
originating layer is notified of the dropping of the message via DCC CROSS.
Sending the message using the power control parameters and flow control param-
eters provided by DCC CROSS.
The DCC NET entity, as defined in [34], stores global DCC parameters received from
other ITS-S. Furthermore, local DCC parameters are distributed to other ITS S by
including them in the GeoNetworking header. Finally, the GeoNetworking Forwarding
Algorithm receives the required DCC parameters.
In DCC FAC the network load generated by CAMs and DENMs is controlled. In
addition, the message priority is written to the TC field [34].
The DCC CROSS layer performs various calculations and passes this information to
the DCC entities of the layers. For DCC ACCESS the power control parameter and
the flow control parameter is calculated with one of the algorithms described in Chapter The DCC NET layer receives the available resources and for DCC FAC a channel
resource limit for registered applications is calculated and communicated [34].
3.3 C-V2X
In contrast to the WiFi offshoot 802.11p, another RAT has now emerged: C-V2X. C-
V2X is based on cellular technology and has the advantage of being able to connect
directly to the internet using the existing wide-spread cellular infrastructure [37]. This
means that not only V2N can be established directly, without a RSU as middle man.
Also infrastructure V2X stations (V2I) could be superfluous, because vehicles could
potentially get that information over the internet. In addition the network could be
used to communicate with vehicles further away.
C-V2X is developed by the 3rd Generation Partnership Project (3GPP), which consists
of seven standardization organizations that develop mobile communication protocols;
ETSI is also part of 3GPP 2.
3.3.1 Communication Interfaces
Figure 3.9: C-V2X communication interfaces [37] [38]
In general, V2X communication is enabled by User Equipment (UE), which describes
any device that enables an end-user to communicate using LTE services [12]. C-V2X
uses two LTE radio interfaces for V2X communication: the cellular interface called Uu
and the Proximity-based Communication 5 (PC5) interface for direct communication,
based on LTE Sidelink [39]. These two different communication paths are shown in 3.9.
Sidelink was first introduced in 3GPP Release 12 [40] under the name Device-to-Device
(D2D) as part of the Proximity Services (ProSe) and was intended for public safety use
cases. D2D includes two modes: Mode 1 and Mode 2. In order to support V2X safety
use cases and enable vehicular communication at high speeds, both have been revised
and the V2X versions are called Mode 3 and Mode 4 [39] [41].
For PC5 Mode 3 the radio resources are allocated via the base station. The scheduling
of the UEs works by means of control messages via the Uu interface [42]. Therefore Mode
3 only works when the UE is in coverage of a base station. The advantage of Mode 3 is
that it allows for very efficient usage of sub-channel utilization.
In Mode 4 the UE is not in network coverage and manages the parameters of the
radio resource autonomously. The UE chooses the parameters from pre-defined, zone-
dependent resource pools according to its position, since the parameters can have regional
differences. If no positioning is possible, the UE must not initiate V2X communication
[42]. Mode 4 is therefore most similar to the communication in 802.11p.
In Figure 3.9, Mode 3 is shown with gray arrows and Mode 4 with blue arrows. If
one car is in-coverage of a base station and one is not, the communication could work
as pictured. This case is not specified in [42].
The cellular interface Uu can be used for indirect communication. Using the LTE base-
station V2X messages can be distributed to UE out of reach for direct communication
3.3.2 Architecture
Figure 3.10: The ETSI ITS architecture using C-V2X for the access layer[43]
C-V2X Release 14 was standardized for the ETSI C-ITS architecture in 2020. The
architecture is shown in Figure 3.10. The Aces Layer from Figure 3.5 has been replaced
by an LTE Access Layer, but the remaining entities are, as far as possible, the same as
in the ETSI C-ITS protocol stack (see Figure 3.5).
Access Layer The C-V2X physical layer uses frequency-division multiple access on its
10 and 20 MHz channels. The frequency bands used for this purpose are defined in Eu-
rope in the same way as for ITS-G5 (see Table 3.2) [43]. This means both technologies
have to share the same frequencies. Two types of packets are used for C-V2X: Transport
Block (TB) and Sidelink Control Information (SCI). While the TB contain the appli-
cation data, the SCI (also called Scheduling Assignment) includes information about
modulation, coding schemes, data length and resource reservation for semi-permanent
scheduling. TBs are modulated with Quadrature Phase Shift Keying (QPSK) or 16
Quadrature Amplitude Modulation (QAM) and for SCI QPSK is always used [39]. For
Sidelink Mode 3, the base station manages the resources and selects the sub-channels.
In Mode 4 this is not possible. Pre-configured parameters are used instead [42]. There
is also a congestion control implemented: CBR and Channel Occupancy Ratio (CR) are
measured. If the CR is greater than a defined CRlimit, the UE must take steps to reduce
it [44].
Other Layers The other access layer protocols for C-V2X in Figure 3.10 are from the
LTE protocol stack and are defined in ETSI TS 136 300 [41].
3.4 Evolution
Both V2X standards have been extensively simulated and tested. Their weaknesses
have been well researched and therefore two successors have been introduced. These are
discussed in this chapter, first 802.11bd in Chapter 3.4.1 and then 5G New Radio (NR)
C-V2X in Chapter 3.4.2. Lastly in Chapter 3.4.3 the regulatory steps taken by the USA
and Europe are discussed.
3.4.1 802.11bd
Over the years, it has been shown that 802.11p has its weaknesses, especially with higher
vehicle density, there can be larger delays in sending and receiving messages [45][46].
This could lead to safety critical messages not being delivered in time. Even congestion
control only helps to a limited extent in this case.
Therefore, a task group was developed in 2019 to develop the successor 802.11bd. The
goals for the new standard are to allow higher relative speeds of vehicles, double the range
provided by 802.11p, co-existence with 802.11p, to be partially backwards compatible,
and interoperability [47]. Since 802.11a was the base for 802.11p, its successor 802.11ac
was chosen as the base for 802.11bd [47].
3.4.2 5G NR C-V2X
The new cellular vehicle-network standard 5G NR C-V2X is not intended to replace LTE
C-V2X , but to extend and coexist in order to cover more use cases [47].
Among other things, the following goals have been set: both communication inter-
faces are to be improved, a mechanism to select the best possible RAT (there is now a
choice between LTE Uu, LTE PC5, NR PC5 and NR Uu) and the co-existence of both
standards. Since 5G NR C-V2X is not backwards compatible and LTE C-V2X is already
deployed newer vehicle will need UEs from both versions [47].
3.4.3 Regulations
Until a November 2020, neither Europe nor the U.S. made a commitment between C-V2X
and the respective 802.11p standard. Unlike China, which is pushing the development
and deployment of C-V2X [48] [49].
This ambiguity means that the decision is highly contested. Different stakeholders hold
different opinions and try to substantiate them with publications. This can be observed
for example in [50], where a possible transmit distance of ITS-G5 of 400m is demonstrated
with a Package Receive Ratio (PRR) of 90%, [3] shows a PRR of only 10% at 400 meters
distance. According to [51] the PRR is 0% at this distance. [3] and [51] obtained their
results in a simulation, while [50] uses real measured values.
In the meantime, however, the US has made a decision and opted for C-V2X. One half
of the frequency band reserved for 802.11p will bee freed for WiFi, the other half will be
dedicated for C-V2X applications [49]. The EU is also considering freeing further parts
of the 5.9 GHz frequency band for WiFi, but this will probably not affect V2X [52]. In
the EU, both C-V2X and ITS-G5 are allowed to use the 5.9 GHz frequency band, since
the EU defines the spectrum usage in a technology neutral way [53].
4 Preparation
In this chapter the preparation done before the test drives will be discussed. First, the
hardware used is described in Chapter 4.1, then the software to log and analyse received
V2X messages is described in Chapter 4.2. Finally, in Chapter 4.3 the planned test
drives and their goals are illustrated.
4.1 Hardware
For the test drives two ITS devices are needed: (i) a V2X sender, and (ii) a V2X receiver.
The V2X sender should be a RSU that allows messages to be modified and sent. The
other device will be used as part of the V2X monitor. Besides receiving and forwarding
messages the Global Positioning System (GPS) module should also be usable on its own
in order to get the position of the vehicle when receiving a message. The following
pages contain a summary of the equipment that used in order to conduct the test drives
described in Chapter 4.3.
Siemens ESCoS Roadside Unit It offers connectivity using WiFi, Bluetooth, GPS,
802.11p, LTE and Ethernet. Additionally it offers a service Graphic User Interface
(GUI) that allows the user to modify V2X messages, monitor received messages, send
messages, and change other RSU dependant settings 1. The Siemens RSU is shown in
Figure 4.1.
Cohda MK 5 The Cohda MK 5 was selected for the V2X Monitor. It is an OBU, can
send and receive 802.11p, has a GPS receiver and runs Linux. It can be connected via
Ethernet, Controller Area Network (CAN) or Universal Serial Bus (USB). The Cohda
MK5 has some pre-installed programs, one of them is a monitor mode 2. Cohda MK5
is shown in Figure 4.2.
Laptop A laptop running Ubuntu was used to form the V2X monitor together with
the Cohda MK5. The laptop runs the ITS Communication Logger described in Chapter
1SIEMENS ESCoS Roadside Unit User Manual V1.1 (2019)
2Cohda MK5 “MK5 OBU.” Cohda Wireless,
mk5-obu/ (Accessed 04.02.2021.)
Figure 4.1: The Siemens ESCoS Roadside Unit
Figure 4.2: The Cohda MK5 with an antenna
Monitor Setup The monitor setup consisted of the Cohda MK5 and the laptop. These
two devices were connected using Ethernet as shown in Figure 4.3. During test drives
both devices were powered through the automobile auxiliary power outlet using an in-
verter. For best radio reception the Antenna was placed at the roof of the vehicle, as
shown in Figure 4.4.
4.2 Software
4.2.1 C-ITS Communication Logger
The program flow of the ITS communication logger is shown in Figure 4.5. In the main
function four threads are created, three are given a shared stop variable. One is set as
a daemon thread, which means it will be killed when the main program exits. After the
four threads are started, the main program sleeps until the user exits the program using
Figure 4.3: The Setup of the V2X Monitor
Figure 4.4: Car with Mounted Cohda Antenna on the Roof
CTRL + C, which will raise a keyboard interrupt exception in the main program. Once
the exception is caught the three stop variables are set the three threads are joined and
the main program exits.
The four threads all have one job each. The send GP S thread connects to the Cohda
module using Secure Shell (SSH) and gets information about the current position using
the program gpspipe. Using the pipe command the output is directed to the netcat tool,
which sends it to the laptop at port 41097 using UDP packets. Once the stop variable
is set, the thread closes the ssh connection and returns.
The counterpart is the receive GP S thread, it binds port 41097, when empty GPS
data is received an error message is displayed to the user. If the data is not empty it is
written to a file including a timestamp.
The send monitor thread connects to the Cohda module using SSH, starts the mon-
itor program and configures it to forward received 802.11p packets to the laptop. If the
stop variable is set the thread closes the SSH connection and returns.
Lastly, the receive monitor thread starts tcpdump, a command line packet capture
Figure 4.5: Program flow of the ITS Communication Logger
tool, and instructs it to save the data in a pcap file. When the stop variable is set, the
thread kills tcpdump and returns.
4.2.2 C-ITS Communication Data Extraction Tool
This python programs takes the pcap file and the file containing the gps data created by
the C-ITS Communication Logger as input. The programm creats a csv file containing
the most important parameters for further data processing using Excel.
With the help of the Python library pyshark the data of the pcap files are extracted.
Then the position of the car at the time of the arrival of the message is read from the
gps file. Finally the following data are stored in the output file: timestamp, longitude
and latitude of the car, ITS version, protocol, signal strength, speed of the car according
to GPS, the station ID and the position of the sender.
4.3 Test Drives
A total of six test drives were planned. Three of them analyze test tracks from different
projects. The other three test drives were planned with the Siemens RSU. In all cases
the V2X monitor described before was used to record messages and the current position
of the car.
4.3.1 Graz A2 Motorway
Figure 4.6: V2X stations at A2 motorway at Graz. Created with
12 RSUs were set up as part of C-Roads and ICT4CART by Asfinag. They are
positioned at the A2 motorway between Laßnitzh¨ohe and Unterpremst¨atten, this route
can be seen in Figure 4.6.
The specific goals for the test drive were: (i) to find out if the RSUs are turned on,
(ii) to find out what they are sending and if this information is useful, (iii) to find out if
the density of the different RSUs is high enough to achieve seamless network coverage,
(iv) and finally, what is the maximum distance for reliable message transmission?
4.3.2 Vienna
In Vienna, Asfinag has set up several RSUs for C-Roads. A test section has been set
up, along the freeway into the city (S1 from the V¨ossendorf junction, A4 and A23); it is
marked in red in Figure 4.7. Along the Handelskai there are additional RSUs at traffic
lights; these are marked in purple in Figure 4.7.
Figure 4.7: V2X stations at S1, A4 and A23 motorway and at Handelskai in Vienna
Since there are some shorter tunnels on the highway route, it would be interesting
to see how they influence the reception of V2X messages. In addition, the RSUs at
Handelskai should provide information about the intersections and traffic light status,
here it is interesting whether this information is correct and which protocols are used.
4.3.3 Italy - South Tyrol
Figure 4.8: Route of the test drive in South Tyrol
In Italy, C-ITS stations were set up along the motorway Brennero by “Autostrade
del Brennero” as part of C-Roads, ICT4CART and BrennerLEC. In this test drive, the
section between Brennero and Sterzing was covered. The route can be seen in Figure
Interesting for this test drive was if the Italian ITS-Ss differ from Austrian ITS-Ss and
if so, how.
4.3.4 Distance Measurement Under Optimal Conditions
Figure 4.9: Overview of the distance measurement campaign
The primary objective of this test drive was to measure the possible distance a V2X
message can be received over. For this purpose, an optimal test setup was chosen: a
straight road with as little traffic as possible. The RSU was set up at the point marked
with a red Point of Interest (POI) flag in Figure 4.9. Its power supply was esnured with
a high capacity lead gel accumulator. The RSU was set to send a DENM message every
100 milliseconds. The route provides 800 meters of direct line of sight to the RSU, which
is marked in green in Figure 4.9. Afterwards there is a corner with bushes for about
150m until the line of sight gets obstructed by buildings.
4.3.5 Distance Measurement in an Urban Environment
In the urban measurement, the RSU was placed at two different positions: first at the
parking lot (red marker in Figure 4.10) and then at the roof of a three-story building
(green marker in Figure 4.10). Afterwards, the immediate surroundings were scanned
by driving around with a vehicle, in which the V2X monitor was installed.
The aim of this test drive was to find out the maximum reception range in an urban
environment. It is also interesting to see how strongly the signal is shielded by buildings
and whether interference from WiFi signals can be detected.
4.3.6 Test Drive of a V2X Equipped Car
The VW Golf 8 was launched in December 2019 and was the first mass-produced car
to be equipped with 802.11p. The V2X feature is called Car2X by VW and is said to
bring many features that provide more safety on the road. For example, a ”stationary
vehicle” warning is sent out when the car’s alarm is on and the car has been stationary
Figure 4.10: Two positions of the RSU during the test drive
for more than a minute, or a critical driving situation warning is sent out in the event
of heavy braking 3 4.
The aim of this test drive is to borrow and test a VW Golf 8 using the V2X monitor
setup and the RSU. The main questionsare: Are the promised features really sent out
and if so, what exactly do the messages say? And how does the car react to messages
from the RSU?
3 visitied
02.02.2021 (German source)
4 visited 02.02.2020 (German
5 Results
This chapter presents the results of the test drives described in Chapter 4.3.
For the evaluation of the test data, the csv files of the python tool were processed in
Excel. For the calculation of the distance between two geographical points, the Spherical
Law of Cosines1was used, since it can be programmed as a one-liner with Excel. The
equation is shown in Equation 5.1. lat1 and long1 represent the coordinates of the
vehicle and lat2 and long2 represent the coordinates of the RSU that send the message.
Rrepresents the mean radius of the Earth and was chosen to be 6371000 meters.
d=acos(sin(lat1)sin(lat2) + cos(lat1)cos(lat2)cos(long1long2))R(5.1)
For the following results only messages were used that were received correctly. Mes-
sages that arrived in parts (i.e. were corrupted) were always discarded. However, some-
times this was difficult to detect because only a few bits were shifted or flipped. Those
messages were sorted out as good as possible by hand. This entails, that messages with
an ITS version other than 1 or 2 were deleted, since no other version exists. Messages
with message IDs bigger than 13 were also discarded because message IDs have only been
defined from 1 to 13. Messages with stationtypes not between 0 and 15 were also deleted.
Lastly, messages with strange positions in the GeoNetworking Layer were deleted. This
includes messages with negative coordinates and messages with latitudes and longitudes
that should not occur in the specific test drives.
Lastly, to calculate the frequency of the transmitted CAMs of the RSUs, the average
over the CAM frequencies of all received CAMs in a radius of 200 meters was chosen.
This distance was chosen because [3] shows that even with unexpectedly high data rates,
the packets should arrive at a high proportion.
5.1 Graz A2 Motorway
Before further processing received the messages were filtered out as described in Chapter
5. In addition messages where the RSU’s latitudes were not between 46.9 and and 47.1
were deleted. Messages with RSU longitudes smaller than 15.3 and bigger than 15.6
were deleted.
In Figure 5.1, the positions of the transmitting RSUs were mapped with green POI
markers. The red POI marker shows a V2X-enabled car detected in the C-ITS log. The
detected car is transmitting CAMs at a frequency of 3.3 Hz. It is identifiable as a car
because stationType in the Basic Container is set to passenger car in the CAM. In the
GeoNetworking layer it can be observed, that the position of the detected car changes.
Figure 5.1: Position of the RSUs (green) and one V2X-capable car (purple) along the
A2 near Graz [54]
In Table 5.1, details of the individual RSUs along the route can be found. fCAM de-
scribes the average frequency of the received CAM messages, where the distance between
the car and the RSU was smaller than 200 meters. The next column is the associated
standard deviation. Sample size describes the number of CAM messages that were re-
ceived in the defined 200 meter radius. Max range describes the maximum distance
between RSU and test vehicle at which a message was received. MessageID specifies the
parameter in the ITS PDU header that describes the protocol. Most RSUs send DENMs
(1), CAMs (2) and IVIMs (6).
Noticeable is that the frequency of RSU 9 is only 0.64 Hz, however only 19 packets
were received by that RSU and only 4 of those were CAMs.
It is also worth noting that all packets have a 1609.2 Secure Packet in the GeoNe-
towking protocol, as defined in [55].
At first glance, the received DENMs do not seem to make sense. Despite the sunny
weather, a heavy rain warning was sent. The weather from the test drive can be seen
in Figure 5.3. The weather warning is marked yellow in the Wireshark screenshot in
Figure 5.4. Also warnings of stationary vehicles, and shed loads are constantly sent, these
warnings could not be verified while driving and seem to be sent randomly. All warnings
have informationQuality 2, this is recommended by [57] when only one automated source
alerts to an event. Higher values must come from multiple sources and even validation
of the information is demanded.
RSU avg. fCAM
max range
(m) messageID version
1 1.00 0.07 13 608.6 1, 2, 6 2
2 1.00 0.00 17 852.0 1, 2 2
3 1.00 0.00 16 1794.5 1, 2, 6 2
4 1.01 0.00 17 1916.9 1, 2 2
5 0.99 0.02 16 1729.7 1, 2 2
6 1.00 0.02 17 1714.4 1, 2, 6 2
7 1.00 0.00 18 2020.6 1, 2, 6 2
8 1.00 0.01 18 1071.4 1, 2, 6 2
9 0.64 0.29 3 96.5 1, 2, 6 2
10 1.01 0.00 18 1743.4 1, 2, 6 2
11 1.00 0.00 18 1713.5 1, 2, 6 2
12 1.00 0.03 21 1013.4 1, 2 2
Table 5.1: Average CAM frequency and standard deviation, sample size, range, protocols
and C-ITS versions sent per RSU in Graz
Figure 5.2: The achieved network coverage along the A2 near Graz. (Created with Excel
3D Map)
Figure 5.2 shows the ”network coverage” of the RSUs. At each position of the test
vehicle where a message from an RSU was received, a blue dot was drawn.
Figure 5.3: Screenshot of the weather on the day of the test drive [56]
Figure 5.4: Screenshot from the DENM warning from heavy rain in Wireshark
5.2 Vienna
Figure 5.5: The RSU positions in Vienna (in blue) and on the motorway (in red) [58]
As described in Chapter 5 erroneous messages were filtered. Additionally messages
where the received sender latitude was not between 48.10 and 48.3 were discarded. The
received sender longitude was also restricted to values between 16.3 and 16.5. Figure
5.5 shows 18 RSUs from which data was received. RSUs in the city were marked with a
blue POI marker, RSUs on the S1, A4 and A23 motorway were marked with a red POI
marker. Additionally, two RSUs were encountered, which were marked with a yellow
POI marker. Both were not analysed in detail since RSU a was not known to us when
planning the route and RSU b sent only very limited messages. One RSU encountered
in the city can be seen in Figure 5.7. Additionally, CAMs from passenger cars were
received with seven different station ids during the test drive in Vienna, their positions
can be seen in Figure 5.6.
Table 5.2 shows the corresponding data of the RSUs. fCAM describes the frequency of
the received CAMs, as in Chapter 5.1, only CAMs where the distance between RSU and
receiver was less than 200 meters were included, the number of CAM that full fill this
requirements can be found under sample size. The max range describes the maximum
distance between RSU and receiver at which a message was received. The messageID
describes the protocols that an RSU sends: DENM (1), CAM (2), SPaT (4), MAP (5),
IVIM (6), SSEM (10). The protocol version describes the ITS protocol version used by
the RSU and can be either 1 or 2.
Table 5.2 shows no average fcam and standard deviation for RSUs 6 and 10 since no
Figure 5.6: Positions of encountered V2X capable cars in Vienna
RSU avg. fCAM
max range
(m) messageID version
1 1.00 0.01 58 2256.5 1, 2, 4,5 2
2 1.00 0.01 56 1596.8 2,4,5 2
3 1.00 0.01 79 869.1 1, 2, 4, 5 2
4 1.00 0.02 36 1696.9 1, 2, 4, 5, 10 2
5 0.67 0.3 12 1484.3 1, 2 2
6 0 433 2 1
7 1.00 0.01 8 2300 1, 2 2
8 0.60 0.29 3 955.4 2 1
9 0.75 0.25 12 1660.4 1, 2 2
10 0 1167.7 2 1
11 0.67 0.33 4 1.059 2 1
12 1.00 0.01 13 785.5 1, 2 2
13 0 791.6 6 2
14 1.00 0.00 19 1240.1 1, 2 2
15 0.94 0.13 17 1257 1, 2 2
16 1.00 0.02 12 1548 1,2, 6 2
Table 5.2: Average CAM frequency and standard deviation, sample size, range, protocols
and C-ITS versions sent per RSU in Vienna
Figure 5.7: Photo of an RSU mounted next to a traffic light at Handelskai and Chrastek-
messages were received in the 200m radius defined before. RSU 13 did not send out
CAMs at all. Additionally RSU 6, 8, 10 and 11 used C-ITS version 1 as opposed to
version 2.
Figure 5.8 shows visualized MAPEM data from RSU 1. In the figure incoming lanes
have been colored orange and exiting lanes white, parking space has been marked yellow
and crosswalks blue. The MAPEM maps every lane to a number and also specifies for
incoming lanes which exiting lanes can be taken (marked with arrows in Figure 5.8)
and to which signaling group of the SPaTEM the lane belongs to (which is indicated by
the color of the arrow). Each lane is described by at least three points. All points are
described by their distance from the reference point (marked with the red POI marker)
in north and east direction. To express southern or western directions the corresponding
values are negative.
In order to get information about V2X connectivity inside a tunnel the example pic-
tured in Figure 5.9 was extracted from the data. The red POI marks the position of
RSU 12. The blue square marks a 118 meter long underpass and the green square the
Rannersdorf tunnel of 1880m. 29 messages from RSU 12 where received inside the Ran-
nersdrof tunnel with a CAM frequency of 1. Since no GPS signal was received inside the
tunnel, the position of the car when receiving the messages was not able to be recovered,
due to the measurement setup having only GPS as positional input. Inside the blue
underpass also a CAM frequency of 1 was received, which suggests that no message was
Figure 5.10 shows the network coverage achieved on the motorway. Since the tasks
of the RSUs in the city is to organize a single intersection each, it does not make sense
Figure 5.8: Visualized data from a MAPEM at Handelskai and Roman K¨ohler Steg in
Figure 5.9: RSU 12 with an underpass and the Rannersdorf tunnel in front
to show a coverage map. Also worth mentioning is that the coverage around RSU 11
looks off because only messages before the position of the RSU were received and not
after. Notable is that the signal strength becomes strongest when the test vehicle is still
more than 300 meters away from the RSU. It is possible that the location of the RSU is
incorrectly entered in the GeoNetworking Layer or that the RSU antenna was shielded
in one direction, but more data needs to be recorded to verify this assumption.
Figure 5.10: The achieved network coverage along the test track on the S1, A4 and A23
around Vienna
5.3 Italy
As described in Chapter 5 erroneous messages were discarded from the log files. Fur-
thermore values for the received RSU latitude was restricted to fall between 46.80 and
47.01 degrees. Longitudes had to be greater than 11.41 and smaller than 11.51 degrees.
The map shown in Figure 5.11 shows the RSUs from which data was received. On
the day of the test drive, data was received from 4 different RSUs. The positions of the
RSUs were extracted from the source position container in the GeoNetworking layer.
Figure 5.12 shows the positions where messages were received from RSUs. It is notable
that packages from RSU 1 dispaly two issues: The positions where messages were received
from the RSU do not overlap with the position of the RSU and secondly 480 meters before
reaching the position of the RSU no more packages are received. Messages from RSU
2 look very similar: no packages were received at the location of the RSU. The reliable
package transmission stops 300 meters before the RSU’s position, however a burst of
10 messages is received 40 meters before the RSU’s location. Lastly, also the messages
received from RSU 3 seem abnormal, compared to stations in Vienna and Graz. The
CAM frequency is consistent at 1 Hz until 350m before the RSU position. After the RSU
position a few more sporadic CAMs are received. However, the receiving of DENMs was
never impaired.
Why RSU 1, 2 and 3 displayed the behaviour described is unknown. They could be
mounted in a way, that the signal is reflected and shielded. However, these are only
speculations and would need to be verified with further test drives.
Figure 5.11: The RSU positions between the Brenner and Stierzing on the A22 [59]
Figure 5.12: The achieved network coverage between the Brenner and Stierzing on the
Table 5.3 shows the average CAM frequency and standard deviation for CAMs received
in a 200 meter radius from the RSU position. The number of CAMs that meet this
criteria can be found in sample size. the maximum distance between sender and receiver
for every RSU. All of them sent DENM (1), CAM (2) and IVIM and used C-ITS version
RSU avg. fCAM
SD sample
max range
(m) messageID version
1 0 1801 1, 2, 6 1
2 1 2117.5 1, 2, 6 1
3 0.24 0.20 4 2902.5 1, 2, 6 1
4 1.00 0.00 62 3283.7 1, 2, 6 1
Table 5.3: Average CAM frequency and standard deviation, sample size, range, protocols
and C-ITS versions sent per RSU in Italy
1. Since no CAMs have been received from RSU 1 in the 200 meter radius used for the
average cam frequency in Chapter 5.1 and Chapter 5.2 the fCAM was not calculated.
From RSU 2 one CAM was received in the 200 m range, therefore also no fCAM could
be calculated. Additionally, for RSU 3 the average and standard deviation of fCAM was
calculated, however only four messages were received in the 200 meter radius defined
above. The sample size for RSU 4 is so large because the test vehicle had to stop at a
tollgate in range of the RSU.
Lastly, it is noticeable, that the InformationQuality parameter in DENMs is always
set to 4, unlike to Chapter 5.1 and 5.1 where it was set to 2. The DENMs include rainy
weather warnings and warnings for general traffic conditions and stationary vehicles.
However, since it did rain 2that day, it is not possible to determine if the precipitation
warning was set intentionally.
5.4 Distance Measurement Under Optimal Conditions
For this test drive, the route (marked in orange) in the Figure 4.9 was driven four times.
A photo of the RSU and the road can be seen in Figure 5.14. Results from all four trips
are presented first, and then the focus is placed on a single one.
Before calculating the results, incorrect messages had to be discarded. These are
often captured shortly before the connection is lost and contain incorrect data. Since
it is known what the RSU is sending, sorting erroneous captures out is easy. Messages
where the message ID, station ID or protocol version did not correspond to the set values
were discarded.
Figure 5.13 shows the position of the RSU (green) as well as the cut off points (blue)
and the maximum distance points (red) at which a message was received. The cut off
points describes the last point at which all messages of the RSU were received consis-
tently. Only a few meters after these points, the last messages are received before the
connection is completely lost. In Table 5.4, the cut off distances and the maximum dis-
tances can are shown. The largest distance between the monitor set up and the RSU at
which a message was still received is 891.2 meters. Table 5.5 shows the average maximum
and cut off distance, including variance and standard deviation.
11129&timeframe=10y accessed 17.03.2021
Figure 5.13: Map with the RSU position (green), the cut off points (blue) and the max-
imum distance points (red)
Figure 5.14: The RSU with the straight road ahead
In Figure 5.15, the data of one trip of the test track was used to show the development
of the signal strength. In order to present the negative signal strength more intuitively,
the signal quality was calculated by adding 100 to the recorded signal strength, which
was in dBm. While the signal strength decreases linearly, this is not the case for the
received messages. Received messages are shown in Figure 5.16. There, the number of
received packets by distance is shown from the same trip. Between 0 and 50 meters the
vehicle had to accelerate to the driving speed, therefore more messages were received.
After that, the driving speed was kept the same and differs only by a few km/h. In
Figure 5.16 it can be seen that the reception of messages does not slowly fade, but
ceases quite suddenly and only a few messages are received after. This might be due to
local circumstances which will be discussed in Chapter 6.
Round Cut off Maximum
Signal Strength
Signal Strength
1829.5 -94 871.3 -96
2828.4 -96 887.1 -99
3820.0 -94 891.2 -97
4826.3 -95 867.9 -96
Table 5.4: Distances and signal strength at the cut off points and the furthest packet
received per trip
Standard Deviation
Cut Off 826.0 17.9 4.2
Maximum 879.4 98.6 9.9
Table 5.5: Average, variance and standard deviation of cut off points and the furthest
packet received
Figure 5.15: The signal quality degradation from the start left, to the stop right, at trip
Figure 5.16: Histogram of the received packages at different distances of the car to the
5.5 Distance Measurement in an Urban Environment
As described in Chapter 5.4, corrupt messages were filtered out first. Then the maximum
distance and the signal strengths were examined. Here it is noticeable that the data
differs in comparison to the optimal measurements with direct line of sight to the RSU
in Chapter 5.4. These differences are summarized in Chapter 5.6.
Figure 5.17: Positions where a DENM packet was received with the RSU positioned at
the ground
Figure 5.18: Positions where a DENM packet was received with the RSU positioned at
the roof
Max Distance
Urban Ground 250.8
Urban Roof 603.4
Table 5.6: The maximum distance between the RSU and the monitor where a packet
was received
Figure 5.17 shows the points where at least one packet was received from the RSU
while the RSU was positioned at the parking lot. In comparison, Figure 5.18 shows the
received packets when the RSU was standing on the roof of the three-story building.
Table 5.6 shows the maximum distances at which a correct message was received.
5.6 Signal Strength Comparison
For this chapter the signal strength progression was compared between Chapter 5.4 and
5.5. This progression can be seen in Figure 5.19. In Table 5.7 the co-variance and
correlation between the distance of the RSU and the monitor and the signal strength is
Figure 5.19: Signal strength degradation over growing distances
Covariance Correlation
Optimal Conditions -2701 -0.9
Urban Ground -707.7 -0.8
Urban Roof -570.5 -0.6
Table 5.7: The correlation and covariance between the distance and the signal strength
of three test drives
5.7 Test Drive of a V2X Equipped Car
Figure 5.20: “Privacy and services was terminated unexpectedly. Please try again later.”
- VW Golf 8 Error Message
For this test, the RSU was set up to send a DENM warning of a traffic accident.
The monitor was used to record the behavior of the VW Golf 8. However, not a single
CAM could be recorded from the Golf 8. Neither in standstill with active ignition nor in
driving mode nor during a test drive on the road and highway. Overall, three different
cars were tested. The system constantly failed and turned off the V2X services, the error
message shown can be seen in Figure 5.20. A request to VW was never answered.
6 Discussion
This chapter will answer the problems formulated in Chapter 2 with the aid of the results
presented in Chapter 5. This chapter will also deal with conspicuous results pointed out
in Chapter 5.
6.1 The Actual Roll Out Status of ITS-G5
Since the roll out status can be measured on many parameters, this work focuses on
three questions: (i) which types of ITS-G5 capable hardware exist in the field, (ii) what
V2X functionality is implemented in the field, and (iii) how well does the implemented
functionality work?
Many vendors sell ITS-G5 capable hardware, which is evident when using a vendor
lookup on the MAC addresses of received V2X messages. In Graz (Chapter 5.1) and
Vienna (Chapter 5.2) RSUs from Siemens have been deployed. Additionally, RSUs
sending C-ITS Version 1 in Vienna are from MPL. Italy (Chapter 5.3) uses RSUs from
Cohda Wireless. Hardware used by passenger cars could not be identified using a MAC
vendor lookup.
A handful of V2X services are currently supported by RSUs deployed in Graz, Vienna,
and Italy. Mainly, three different protocols are live: CAM, DENM and IVIM. In the
city of Vienna MAPs, SPaTs and SSEMs are also sent. DENMs received in Graz and
Vienna seem to contain only test messages. MAPs and SPaTs in Vienna are defined
correctly and describe intersections, as shown in 5.8. Whether also the traffic light
status is correctly implemented needs to be tested with another test drive. The RSUs
in Graz and Vienna seem to be configured statically, as the current weather or traffic do
not seem to influence DENMs. It is also an open question whether these RSUs react to
incoming messages, e.g. if they forward incoming DENMs or react to SREMs.
In general, C-ITS works in a real-world environment. Messages can be received over
a maximum distance of 2250 meters in Vienna, as shown in Table 5.2. The average
driving speed at motorways does not seem to have an impact on message transmission.
However, a stumbling block for correct RSU functionality seems to be the exact location
an RSU is mounted to: the poor results in Chapter 5.3 could be caused by shieldings
from infrastructure and reflections. Also, in Graz and Vienna, isolated RSUs seem to
have problems sending messages. This can be seen in Table 5.1 when looking at RSU
9, from which only 3 CAM messages were received. In Vienna, only very few CAM
messages were received from RSU 8 and 11, which can be seen in Table 5.2. In all these
cases an unfavorable mounting position could lead to these results.
Lastly, the implementation of VW also seems to have its flaws. As shown in Chapter
5.7, no data could be obtained during the whole test with the VW Golf 8. Nevertheless,
it cannot be concluded that the system never works. During the test drives in Graz and
Vienna, multiple CAMs from passenger cars were received; however, it is impossible to
tell which car brand and model sent those messages.
To conclude, ITS-G5 seems to be in a test phase in Europe at the moment. Although
the RSUs are in place, many seem to be sending mostly test messages. Then again, the
fact that different test sites use different C-ITS versions and in Vienna two are used
seems to underline the statement further. Additionally, VW’s implementation does not
seem to be working flawlessly yet, which further confirmed that it is in a test phase.
6.2 How do Practical Applications Differ from Theoretical
This chapter discusses the extent to which practical applications comply with the specifi-
cations. Three points have been noticed in Chapter 5: (i) the transmission of CAMs, (ii)
the InformationQuality parameter in DENMs, and (iii) the specified position of RSUs.
The CAM transmission rules defined by ETSI in [14] are not adhered to by all RSUs. The
standard [14] defines: ”Sending CAMs as part of the CA basic service shall be present in
all ITS-S, which take part in the road traffic (vehicle ITS-S, personal ITS-S, etc.).” In
Vienna (Chapter 5.2) no CAMs were received from RSU 6, 10 and 13 as shown in Table
5.2, in Italy no CAM was received from RSU 1 as shown in Table 5.3. Additionally, as
stated in Chapter, CAMs must be sent with a frequency of 1 to 10 Hz. All RSUs
in Chapter 5, that we received CAMs from, seem to comply with this. Discrepancies in
the results are due to interference, but looking through the data by hand, one can see
that the attempt to transmit at 1 Hz was made. However, the question arises whether
1 Hz is enough on the highway. Many RSUs are affected by interfering factors, for
example from RSU 9 in Table 5.1 in Chapter 5.1 only three CAMs were received. A
higher transmission frequency would be especially important for cars on the highway
since otherwise oncoming cars can hardly be registered at driving speed.
Secondly, the usage of the InformationQuality parameter is questionable. The parameter
is set to 2 in Graz (Chapter 5.1) and Vienna, although only test messages are sent.
The standard [16] does not define which level should be selected in which scenario.
There is only the recommendation of Lubrich et al. This devalues the significance of the
InformationQuality parameter.
Lastly, also RSU position seems to not always adhere to the standard. In Graz and
Italy, the RSU positions change slightly with every message. This is to be expected if
the position is read from a GPS module. In Vienna, however, the position that RSUs
send is fixed and always the same for each message of the respective RSU. There is a
”manual” bit in the GeoNetworking layer to indicate such behavior, which signals that
the geographic address has been set manually. However, this bit is not set for the stations
in Vienna. Additionally, as mentioned in Chapter 5.2 the location of RSU 11 might not
be set to the actual position of the RSU.
In summary, it can be said that the tested stations mostly comply with the standard.
However, it sometimes leaves leeway when considering the informationQuality param-
eter or the acceptable range of CAM transmission frequency. However, sometimes the
definitions of the ETSI standards are not adhered to, for instance, when RSUs do not
send CAMs at all.
6.3 What is the Real Life Performance of ITS-G5?
Since the real life performance of ITS-G5 can be linked to many different factors, this
chapter focuses on three aspects: (i) the maximal transmission distance discussed in
Chapter 6.3.1, (ii) the connection quality discussed in Chapter 6.3.2, and (iii) the missing
checksum discussed in Chapter 6.3.3.
6.3.1 Maximum Transmission Distance
Maximum transmission distance is strongly dependent on the position of the RSU and
how much the a direct line of sight between sender and receiver is obstructed. When
looking at the Results in Graz and Vienna, a maximum distance surpasses 2 km; in Italy,
even 3 km were possible. In these tests, the RSUs were usually mounted to overhead
displays on motorways or next to traffic lights. In Chapter 5.4 the RSU was standing on
the ground, and the maximum range was 890 meters, although then hedges obstructed
the direct line of sight.. In the urban environment (Chapter 5.5) with lots of interferences,
the maximum distance was 600 meters when the RSU was placed on the roof and 200
meters when placed on the ground.
When looking at the maximum distance possible, another question arises: what is the
maximum distance between RSUs to achieve a continuous network coverage? According
to Gr¨afling et al. RSUs should be placed every kilometer. This can be confirmed in Graz
in Figure 5.2, RSUs with a distance less than one kilometer could provide continuous
network coverage.
6.3.2 Connection Quality
For a reliable connection, the maximum achievable distance between sender and receiver
plays a subordinate role since the packet receive rate is usually already relatively low
when reaching the maximum distance. More important is what distances can be covered
with a reliable connection. However, as seen in Italy (Chapter 5.3), this question cannot
be answered by a number alone since different interference factors can influence the
transmission. Sometimes no messages are received even in the smallest radius around
the RSU. Therefore, the quality of the connection is examined in this chapter based on
two parameters: (i) the packet drop rate and (ii) the signal quality.
In the campaign in Chapter 5.4, there is no packet drop up to a distance of about 800
meters when sender and receiver are positioned in a direct line of sight as shown in
Figure 5.16. However, at that distance, the smallest objects in the direct line of sight
lead to a very drastic packet drop, as shown in Figure 5.16. Here, bushes blocked the
direct line of sight, which immediately lead to a drastic packet loss.
In contrast to the 800 meters without packet loss above, when looking at the signal
strength as a connection quality indicator, V2X can cover about 300 meters when sender
and receiver are in direct line of sight and about 90 meters when not. This claim can
be made under the assumption that at least -80 dBm signal strength is needed for a
reliable connection. For WiFi, for example, various sources state that a signal strength
of -80 dBm is the absolute minimum for a connection 1 2. When applying this to V2X
and looking at Figure 5.19, this threshold was reached at 90 meters when the RSU was
placed on the ground in an urban environment and also when the RSU was placed on
the roof. However the maximum distances (Table 5.6) are vastly different. This might
be due to interference, less obstructions and antenna characteristics.
6.3.3 Missing Checksum
Lastly, it is noticeable that manual filtering of the messages is necessary in all tests.
No checksum can be used to check messages for correctness. Each recipient must check
and validate the received messages themselves. While this path was probably chosen for
standardization, due to timing constraints, this could lead to erroneous data in messages,
like a DENM that contains the wrong accident location.
1 accessed: 17.03.2021
accessed: 17.03.2021
7 Conclusion and Future Work
This chapter concludes the findings of this thesis and provides an outlook for future work.
The conclusion can be found in Chapter 7.1 and future research topics are discussed in
Chapter 7.2.
7.1 Conclusion
Currently, two competing V2X standards are trying to conquer the automotive market:
C-V2X based on LTE and ITS-G5 based on WiFi. ITS-G5 has been around for ten
years, and the associated standard from ETSI is still regularly updated. Many research
projects and publications deal with the performance of ITS-G5. V2X technology has
also received a new boost from the VW Golf 8, which is equipped with an ITS-G5
Since many of the existing publications show partly contradictory results and many of
them are only simulations, this thesis aimed to determine the actual behavior of ITS-G5.
This was realized by six different test drives. Two routes of the Asfinag in Graz and
Vienna and one in South Tyrol were visited. Two further tests were set up with an RSU,
and finally, an attempt was made to examine a real VW Golf 8.
The evaluation of the data shows that despite the last ten years that ITS-G5 has been
around, the roll-out status is still in a testing phase. CAMs, DENMs, IVIMs, MAPEMs,
and SPaTEM have been received. However, the content is mostly fixed and mostly does
not adapt to current events. Furthermore, VW seems to have some problems with the
V2X in their initial roll out.
The definitions in the standard are predominantly adhered to but leave some room for
free interpretation. The work also shows that RSUs can send messages over a distance
of one kilometer, should there be no transmission interference. If it is essential that no
packets are lost, this distance must be reduced. Shielding and interferences constitute a
significant problem, especially in urban environments. However, at the motorway, it is
simply a matter of RSU placement, and in the city, smaller transmission distances are
probably acceptable due to slower speeds and more stops.
7.2 Future Work
Evaluating the results, it becomes clear that two issues need to be addressed in future
works: (i) testing of real-world congestion scenarios and (ii) adequacy of protocols in
the context of autonomous driving.
In regards to congestion Mannoni et al. [46], for example, show the simulated behavior
of ITS-G5 as a function over number of users per square kilometer, compared to C-V2X,
ITS-G5 performs rather poorly. A real life analysis of the behavior of ITS-G5 at a
higher receiver density would be interesting. How does the congestion control behave,
and what influence does this have on the transmitters’ range? Additionally, how many
V2X-equipped cars can be expected on the road in the next ten years? Is a density of
200 transmitters per square kilometer even realistic in that time frame?
Regarding autonomous driving, it would be important to evaluate to what extent the
data in C-ITS protocols are adequate for autonomous driving. Are the intersections’
descriptions in MAP and SPaT messages sufficient, or would more data be needed? Can
other autonomous driving use cases be supported by V2X? Moreover, how well are these
new use cases already supported with the existing V2X protocols?
[1] ETSI ES 202 663 V1.1.0 (2010-01) Intelligent Transport Systems (ITS); Euro-
pean profile standard for the physical andmedium access control layer ofIntelligent
Transport Systems operatingin the 5 GHz frequency band. Standard. Sophia An-
tipolis, France: ETSI, Jan. 2010.
[2] A. Jafari, S. Al-Khayatt, and A. Dogman. “Performance evaluation of IEEE 802.11p
for vehicular communication networks”. In: 2012 8th International Symposium on
Communication Systems, Networks Digital Signal Processing (CSNDSP). 2012,
pp. 1–5. doi:10.1109/CSNDSP.2012.6292712.
[3] W. Anwar, N. Franchi, and G. Fettweis. “Physical Layer Evaluation of V2X Com-
munications Technologies: 5G NR-V2X, LTE-V2X, IEEE 802.11bd, and IEEE
802.11p”. In: 2019 IEEE 90th Vehicular Technology Conference (VTC2019-Fall).
2019, pp. 1–7. doi:10.1109/VTCFall.2019.8891313.
[4] T. T. Almeida et al. “IEEE 802.11p Performance Evaluation: Simulations vs. Real
Experiments”. In: 2018 21st International Conference on Intelligent Transporta-
tion Systems (ITSC). 2018, pp. 3840–3845. doi:10.1109/ITSC.2018.8569676.
[5] Fernando A. Teixeira et al. “Vehicular networks using the IEEE 802.11p standard:
An experimental analysis”. In: Vehicular Communications 1.2 (2014), pp. 91–96.
issn: 2214-2096. doi:
[6] Christoph Sommer and Falko Dressler. “Introduction”. In: Vehicular Networking.
Cambridge University Press, 2014, pp. 1–11. doi:10.1017/CBO9781107110649.
[7] C2C-CC System: CAR 2 CAR Communication Consortium Manifesto Version 1.1.
Report. Braunschweig, Germany: CAR 2 CAR Communication Consortium, Aug.
[8] Intelligent Transport Systems (ITS);Communications Architecture. Standard. Sophia
Antipolis, France: ETSI, Sept. 2010.
[9] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Ap-
plications; Definitions. Standard. Sophia Antipolis, France: ETSI, June 2007.
[10] ETSI TS 122 185 V14.3.0 (2017-03) LTE;Service requirements for V2X services
(3GPP TS 22.185 version 14.3.0 Release 14). Standard. Sophia Antipolis, France:
ETSI, Apr. 2017.
[11] ETSI TR 103 300-1 V2.1.1 (2019-09) Inntelligent Transport System (ITS); Vul-
nerable Road Users (VRU) awareness; Part 1: Use Cases definition; Release 2.
Standard. Sophia Antipolis, France: ETSI, Sept. 2019.
[12] Christoph Sommer and Falko Dressler. “Inter-vehicle communication”. In: Vehic-
ular Networking. Cambridge University Press, 2014, pp. 38–105. doi:10.1017/
[13] Christoph Sommer and Falko Dressler. “Information dissemination”. In: Vehicu-
lar Networking. Cambridge University Press, 2014, pp. 136–228. doi:10.1017/
[14] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Ap-
plications; Part 2: Specification of Cooperative Awareness Basic Service. Standard.
Sophia Antipolis, France: ETSI, Nov. 2014.
[15] Zachary MacHardy et al. “V2X Access Technologies: Regulation, Research, and
Remaining Challenges”. In: IEEE Communications Surveys Tutorials 20.3 (2018),
pp. 1858–1877. doi:10.1109/COMST.2018.2808444.
[16] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Ap-
plications; Part 3: Specifications of Decentralized Environmental Notification Basic
Service. Standard. Sophia Antipolis, France: ETSI, Nov. 2014.
[17] Intelligent transport systems - Cooperative ITS - Dictionary of in-vehicle informa-
tion (IVI) data structures. Standard. ISO, Aug. 2015.
[18] Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Ap-
plications; Facilities layer protocols and communication requirements for infras-
tructure services. Standard. Sophia Antipolis, France: ETSI, Nov. 2016.
[19] V2X Communications Message Set Dictionary J2735202007. Standard. SAE In-
ternational, July 2020.
[20] Intelligent transport systems — Cooperative ITS — Using V2I and I2V commu-
nications for applications related to signalized intersections. Standard. ISO, June
[21] Intelligent Transport Systems (ITS); Users and applications requirements; Part 2:
Applications and facilities layer common data dictionary. Standard. Sophia An-
tipolis, France: ETSI, Aug. 2018.
[22] 802.11p-2010 - IEEE Standard for Information technology– Local and metropoli-
tan area networks– Specific requirements– Part 11: Wireless LAN Medium Access
Control (MAC) and Physical Layer (PHY) Specifications Amendment 6: Wireless
Access in Vehicular Environments. Standard. New York, USA: IEEE, July 2010.
[23] 802.11-1997 - IEEE Standard for Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications. Standard. New York, USA: IEEE, Nov.
[24] Christoph Sommer and Falko Dressler. “Access technologies”. In: Vehicular Net-
working. Cambridge University Press, 2014, pp. 106–135. doi:10.1017/CBO9781107110649.
[25] ETSI EN 302 663 V1.3.1 (2020-01) Intelligent Transport Systems (ITS); ITS-G5
Access layer specification for Intelligent Transport Systems operating in the 5 GHz
frequency band. Standard. Sophia Antipolis, France: ETSI, Jan. 2020.
[26] Dedicated Short Range Communications Report and Order. Report and Order.
Washington, USA: Federal Communications Commission, Feb. 2004.
[27] ARIB STD-T109 700 MHz Band Intelligent Transport Systems. Report and Order.
Japan: ARIB, Feb. 2004.
[28] ETSI EN 302 571 V2.1.1 (2017-02)Intelligent Transport Systems (ITS); Radio-
communications equipment operating in the 5 855 MHz to 5 925 MHz frequency
band; Harmonised Standard covering the essential requirements of article 3.2 of
Directive 2014/53/EU. Standard. Sophia Antipolis, France: ETSI, Feb. 2017.
[29] ETSI EN 301 893 V2.1.1 (2017-05)5 GHz RLAN; Harmonised Standard covering
the essential requirements of article 3.2 of Directive 2014/53/EU. Standard. Sophia
Antipolis, France: ETSI, May 2017.
[30] ETSI EN 302 636-3 V1.2.1 (2014-12) Intelligent Transport Systems (ITS);Vehicular
Communications; GeoNetworking; Part 3: Network Architecture. Standard. Sophia
Antipolis, France: ETSI, Dec. 2014.
[31] ETSI EN 302 636-4-1 V1.4.1 (2020-01); Intelligent Transport Systems (ITS);Vehicular
Communications; GeoNetworking; Part 4: Geographical addressing and forward-
ing for point-to-point and point-to-multipoint communications; Sub-part 1: Media-
Independent Functionality. Standard. Sophia Antipolis, France: ETSI, Jan. 2020.
[32] ETSI EN 302 636-5-1 V2.2.1 (2019-05)Intelligent Transport Systems (ITS); Ve-
hicular Communications; GeoNetworking; Part 5: Transport Protocols; Sub-part 1:
Basic Transport Protocol. Standard. Sophia Antipolis, France: ETSI, May 2019.
[33] ETSI TS 102 894-1 V1.1.1 (2013-08) Intelligent Transport Systems (ITS);Users
and applications requirements; Part 1: Facility layer structure, functional require-
ments and specifications. Standard. Sophia Antipolis, France: ETSI, May 2019.
[34] ETSI TS 103 175 V1.1.1 (2015-06) Intelligent Transport Systems (ITS);Cross
Layer DCC Management Entity for operation in the ITS G5A and ITS G5B
medium. Technical Report. Sophia Antipolis, France: ETSI, June 2015.
[35] ETSI TS 102 687 V1.2.1 (2018-04)Intelligent Transport Systems (ITS); Decentral-
ized Congestion Control Mechanisms for Intelligent Transport Systems operating
in the 5 GHz range; Access layer part. Standard. Sophia Antipolis, France: ETSI,
Apr. 2018.
[36] ETSI TR 101 612 V1.1.1 (2014-09) Intelligent Transport Systems (ITS); Cross
Layer DCC Management Entity for operation in the ITS G5A and ITS G5B
medium; Report on Cross layer DCC algorithms and performance evaluation. Tech-
nical Report. Sophia Antipolis, France: ETSI, Sept. 2014.
[37] Li Feng. V2X White Paper v 1.0. White Paper. NGMN, June 2018.
[38] 3rd Generation Partnership Project; Technical Specification Group Radio Access
Network; Vehicle-to-Everything (V2X) services based on LTE; User Equipment
(UE) radio transmission and reception (Release 14). Technical Report. Sophia
Antipolis, France: 3GPP, Mar. 2017.
[39] R. Molina-Masegosa and J. Gozalvez. “LTE-V for Sidelink 5G V2X Vehicular
Communications: A New 5G Technology for Short-Range Vehicle-to-Everything
Communications”. In: IEEE Vehicular Technology Magazine 12.4 (2017), pp. 30–
39. doi:10.1109/MVT.2017.2752798.
[40] ETSI TS 136 201 V12.2.0 (2015-04) LTE; LTE; Evolved Universal Terrestrial
Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); LTE physical layer; General description (3GPP TS 36.201 version
12.2.0 Release 12). Technical Specification. Sophia Antipolis, France: ETSI, Nov.
[41] ETSI TS 136 300 V14.2.0 (2017-04) LTE; Evolved Universal Terrestrial Radio
Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-
UTRAN); Overall description; Stage 2 (3GPP TS 36.300 version 14.2.0 Release
14). Technical Specification. Sophia Antipolis, France: ETSI, Apr. 2017.
[42] ETSI TS 124 386 V14.0.0 (2017-05) LTE;User Equipment (UE) to V2X control
function; protocol aspects; Stage 3 (3GPP TS 24.386 version 14.0.0 Release 14).
Technical Specification. Sophia Antipolis, France: ETSI, May 2017.
[43] ETSI EN 303 613 V1.1.1 (2020-01) Intelligent Transport Systems (ITS);LTE-V2X
Access layer specification for Intelligent Transport Systems operating in the 5 GHz
frequency band n. Standard. Sophia Antipolis, France: ETSI, Jan. 2020.
[44] ETSI TS 103 574 V1.1.1 (2018-11) Intelligent Transport Systems (ITS); Conges-
tion Control Mechanisms for the C-V2X PC5 interface;Access layer part. Technical
Specification. Sophia Antipolis, France: ETSI, Nov. 2018.
[45] S. Eichler. “Performance Evaluation of the IEEE 802.11p WAVE Communication
Standard”. In: 2007 IEEE 66th Vehicular Technology Conference. 2007, pp. 2199–
2203. doi:10.1109/VETECF.2007.461.
[46] V. Mannoni et al. “A Comparison of the V2X Communication Systems: ITS-G5
and C-V2X”. In: 2019 IEEE 89th Vehicular Technology Conference (VTC2019-
Spring). 2019, pp. 1–5. doi:10.1109/VTCSpring.2019.8746562.
[47] G. Naik, B. Choudhury, and J. Park. “IEEE 802.11bd 5G NR V2X: Evolution of
Radio Access Technologies for V2X Communications”. In: IEEE Access 7 (2019),
pp. 70169–70184. doi:10.1109/ACCESS.2019.2919489.
[48] Yu Shengbo. “Introduction of China C-V2X Industry and Standards”. In: China
Society of Automotive Engineers(CSAE) (). url:
T / extcoop / cits / Documents / Meeting - 20200909 - e - meeting / 17R1 _ CSAE _
Status-report.pdf (visited on 12/14/2020).
[49] Kelly Hill. “It’s official: DSRC is out, C-V2X and Wi-Fi-sharing is in at 5.9 GHz”.
In: RCR Wireless News (Nov. 19, 2019). url:https : / / www . rcrwireless .
com /20201119 / wireless/ its - official- dsrc - is- out - c - v2x- and - wi - fi-
sharing-is-in-at-5-9-ghz (visited on 12/14/2020).
[50] Andrew Turley et al. C-ITS: Three observations on LTE-V2X and ETSI ITS-
G5—A comparison. White Paper. NXP, 2019.
[51] Qualcomm. Accelerating C-V2X Commercialization. Presentation. Qualcomm, 2017.
[52] John Walko. “Europe Looks to Open Up 6GHz Band for Wi-Fi”. In: EET Asia
(Oct. 30, 2020). url: up-
6ghz-band-for-wi-fi/ (visited on 12/14/2020).
[53] ECC Decision (08)01 The harmonised use of Safety-Related Intelligent Transport
Systems (ITS) in the 5875-5935 MHz frequency band. ECC Decision. ECC, Mar.
[54] V2X Stations on the A2 near Graz.https : / / www . google . com / maps / d / u /
0 /edit ? mid= 1SGe- - AREHa6njaSiatBPwF0LngJvGeU6& usp =sharing. Accessed:
[55] “IEEE Standard for Wireless Access in Vehicular Environments–Security Services
for Applications and Management Messages”. In: IEEE Std 1609.2-2016 (Revision
of IEEE Std 1609.2-2013) (2016), pp. 1–240. doi:10 . 1109 / IEEESTD . 2016 .
[56] Weather archive data from the test drive in Graz.https://www.timeanddate.
de / wetter / oesterreich / graz / rueckblick ? month = 9 & year = 2020. Accessed:
[57] Peter Lubrich et al. EU EIP SA 4.1: Determining Quality of European ITS Ser-
vices. EU EIP Website. 2020.
[58] V2X Stations in Vienna and on the S1, A4 and A23 motorways.https://www.
google. com/maps /d/u/0/edit?mid=1rTaTKPl5z_uAMi1nZMkRdtu - yD- zeAaO&
usp=sharing. Accessed: 26.02.2021.
[59] V2X Stations between Brenner and Stierzing on the A22.
com / maps / d / u / 0 / edit ? mid = 1gmEAyNnXEqOfzjHZM22iCIUNEkqzt0fw & usp =
sharing. Accessed: 26.02.2021.
[60] S. Gr¨afling, P. M¨ah¨onen, and J. Riihij¨arvi. “Performance evaluation of IEEE 1609
WAVE and IEEE 802.11p for vehicular communications”. In: 2010 Second Inter-
national Conference on Ubiquitous and Future Networks (ICUFN). 2010, pp. 344–
348. doi:10.1109/ICUFN.2010.5547184.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Vehicular communications have an eminence potential to improve the road safety by exchange of information with their surrounding. To enable vehicular communications, IEEE 802.11p and LTE-V2X are the state of the art technologies. A number of studies and field trials are carried out to evaluate their performance in various vehicle-to-everything (V2X) communications scenarios. On the one hand, 3GPP (3rd Generation Partnership Project) is working on the next generation V2X technology (i.e., 5G NR-V2X) to address new use cases and improve the performance. On the other hand, an IEEE 802.11 study group NGV (next generation V2X) is identifying new use cases and requirements, to define a possible amendment named IEEE 802.11bd. In this paper, we evaluate and compare the physical layer performance of these upcoming technologies for vehicle-to-vehicle (V2V) communications. The main motivation of this work is to identify which technology is more suitable for V2V communications. Our results show that NR-V2X is expected to outperform all other standards (even IEEE 802.11bd) in terms of reliability, range, latency, and data rates. However, IEEE 802.11bd is expected to be more reliable with improved range and throughput compared to IEEE 802.11p.
Full-text available
With the rising interest in autonomous vehicles, developing radio access technologies (RATs) that enable reliable and low latency vehicular communications has become of paramount importance. Dedicated Short Range Communications (DSRC) and Cellular V2X (C-V2X) are two present-day technologies that are capable of supporting day-1 vehicular applications. However, these RATs fall short of supporting communication requirements of many advanced vehicular applications, which are believed to be critical in enabling fully autonomous vehicles. Both DSRC and C-V2X are undergoing extensive enhancements in order to support advanced vehicular applications that are characterized by high reliability, low latency, and high throughput requirements. These RAT evolutions—IEEE 802.11bd for DSRC and NR V2X for C-V2X—can supplement today’s vehicular sensors in enabling autonomous driving. In this paper, we survey the latest developments in the standardization of 802.11bd and NR V2X. We begin with a brief description of the two presentday vehicular RATs. In doing so, we highlight their inability to guarantee the quality of service requirements of many advanced vehicular applications. We then look at the two RAT evolutions, i.e., IEEE 802.11bd and NR V2X and outline their objectives, describe their salient features and provide an in-depth description of key mechanisms that enable these features. While both, IEEE 802.11bd and NR V2X, are in their initial stages of development, we shed light on their preliminary performance projections and compare and contrast the two evolutionary RATs with their respective predecessors.
Conference Paper
Full-text available
IEEE 802.11p is an emerging standard which provides vehicular safety communication through wireless networks. In this paper, we will study the architecture of Wireless Access for Vehicular Environment (WAVE) and IEEE 802.11p standard. The key parameters of this standard are implemented in ns-2 network simulator to accurately simulate vehicular ad hoc networks (VANETs). The performance of this standard will be evaluated in the network simulation environment using realistic vehicular mobility models. Throughput, End-to-End delay, and packet loss metrics will be analysed for our scenario, since they are the main performance metrics for vehicular safety communication. In addition, the effect of varying vehicle speed and different message sizes on the performance metrics will be examined.
As we edge closer to the broad implementation of intelligent transportation systems, the need to extend the perceptual bounds of sensor-equipped vehicles beyond the individual vehicle is more pressing than ever. Research and standardization efforts toward V2X, or vehicle to everything, technology is intended to enable the communication of individual vehicles with both one another and supporting road infrastructure. The topic has drawn interest from a large number of stakeholders, from governmental authorities to automotive manufacturers and mobile network operators. With interest sourced from many disparate parties and a wealth of research on a large number of topics, trying to grasp the bigger picture of V2X development can be a daunting task. In this tutorial survey, to the best of our knowledge, we collate research across a number of topics in V2X, from historical developments to standardization activities and a high-level view of research in a number of important fields. In so doing we hope to provide a useful reference for the state of V2X research and development for newcomers and veterans alike.
This article provides an overview of the long-term evolution-vehicle (LTE-V) standard supporting sidelink or vehicle-to-vehicle (V2V) communications using LTE's direct interface named PC5 in LTE. We review the physical layer changes introduced under Release 14 for LTE-V, its communication modes 3 and 4, and the LTE-V evolutions under discussion in Release 15 to support fifth-generation (5G) vehicle-to-everything (V2X) communications and autonomous vehicles' applications. Modes 3 and 4 support direct V2V communications but differ on how they allocate the radio resources. Resources are allocated by the cellular network under mode 3. Mode 4 does not require cellular coverage, and vehicles autonomously select their radio resources using a distributed scheduling scheme supported by congestion control mechanisms. Mode 4 is considered the baseline mode and represents an alternative to 802.11p or dedicated shortrange communications (DSRC). In this context, this article also presents a detailed analysis of the performance of LTE-V sidelink mode 4, and proposes a modification to its distributed scheduling.
The IEEE 802.11 working group proposed a standard for the physical and medium access control layers of vehicular networks called 802.11p. In this paper we report experimental results obtained from communication between vehicles using 802.11p in a real scenario. The main motivation is the lack of studies in the literature with performance data obtained from off-the-shelf 801.11p devices. Our study characterizes the typical conditions of an 802.11p point-to-point communication. Such a study serves as a reference for more refined simulation models or to motivate enhancements in the PHY/MAC layers. Field tests were carried out varying the vehicle's speed between 20 and 60 km/h and the packet length between 150 and 1460 bytes, in order to characterize the range, throughput, latency, jitter and packet delivery rates of 802.11p links. It was observed that communication with vehicles in motion is unstable sometimes. However, it was possible to transfer data at distances over 300 m, with data rates sometimes exceeding 8 Mbit/s.
Conference Paper
In order to provide Dedicated Short Range Communication (DSRC) for future vehicle-to-vehicle (V2V) communication the IEEE is currently working on the IEEE 802.11p Wireless Access in Vehicular Environments (WAVE) standard. The standard shall provide a multi-channel DSRC solution with high performance for multiple application types to be used in future Vehicular Ad Hoc Networks (VANETs). We provide a performance evaluation of the standard, considering collision probability, throughput and delay, using simulations and analytical means. WAVE can prioritize messages, however, in dense and high load scenarios the the troughput is decreases while the delay is increasing significantly.
Conference Paper
In this paper we study the performance of the IEEE 1609 WAVE and IEEE 802.11p trial standards for vehicular communications. We have implemented key components of these standards in a simulation environment also supporting realistic vehicular mobility simulation. We study both the overall capacity of vehicular networks utilizing the said standards, as well as delay performance, which is an extremely important performance metric especially for safety applications. Our results show that the traffic prioritization schemes selected for the standards work well, and even in the presence of multi-channel operation implemented by the IEEE 1609.4 the delay of control messages of highest priority remains on the order of tens of milliseconds. Thus even with high densities of vehicles these standards should yield a stable platform a variety of vehicular applications can be built on.