Julia Mandana Horvath
Analysing the Proposed Communication
Protocol for Multi-Brand Truck Platooning in
Europe
Bachelor Thesis in Business Informatics
29 November 2021
Please cite as:
Julia Mandana Horvath, “Analysing the Proposed Communication Protocol for Multi-Brand Truck Platooning in Europe,”
Bachelor Thesis (Bachelorarbeit), Institute of Telecommunication Systems, Technische Universität Berlin, Germany,
November 2021.
Fachgebiet Telekommunikationsnetze
Technische Universität Berlin, Germany
Einsteinufer 25 ·10587 Berlin ·Germany
https://www.tkn.tu-berlin.de/
Analysing the Proposed Communication
Protocol for Multi-Brand Truck Platooning in
Europe
Bachelor Thesis in Business Informatics
vorgelegt von
Julia Mandana Horvath
angefertigt in der Fachgruppe
Fachgebiet Telekommunikationsnetze
Institut für Telekommunikationsnetze
Technische Universität Berlin
Betreuer: Julian Heinovski
Dominik S. Buse
Max Schettler
Gutachter: Falko Dressler
Thomas Sikora
Abgabe der Arbeit: 29. November 2021
Erklärung
Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer
als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder
ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser
als Teil einer Prüfungsleistung angenommen wurde.
Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind als
solche gekennzeichnet.
(Julia Mandana Horvath)
Berlin, den 29 November 2021
Abstract
In platooning multiple vehicles are organized in convoys driving autonomously with
a minimized safety gap. In order to support the global deployment of platooning, an
integrated multi-brand approach is required. The European HORIZON 2020 project
ENSEMBLE tries to address this issue by unifying and standardizing platooning
within Europe. To this end, ENSEMBLE published a new communication protocol and
within proposed a concrete implementation of communication for truck platooning
in Europe. We conduct an extensive simulation study of the proposed communication
protocol, showing that the protocol, even with packet loss, works reliable in all tested
scenarios and guarantees a certain level of road safety. Considering the protocol
performance from the application layer perspective, we evaluate how effective the
protocol fulfills the requirements of the controller. By doing that, we additionally
provide a key performance indicator to measure how well the protocol ensures
constant information flow. That can be used to determine whether a different
controller would be reliable with the proposed communication protocol.
iii
Kurzfassung
Beim Platooning werden mehrere Fahrzeuge in Konvois organisiert, die autonom
und mit möglichst geringem Sicherheitsabstand fahren. Um den globalen Einsatz
von Platooning zu unterstützen, ist ein integrierter Mehrmarkenansatz erforderlich.
Das europäische HORIZON 2020 Projekt ENSEMBLE versucht, dieses Problem durch
Vereinheitlichung und Standardisierung von Platooning in Europa zu lösen. Zu die-
sem Zweck hat ENSEMBLE ein neues Kommunikationsprotokoll veröffentlicht und
eine konkrete Implementierung der Kommunikation für LKW-Platooning in Europa
vorgeschlagen. Wir führen eine umfassende Simulationsstudie des vorgeschlagenen
Kommunikationsprotokolls durch, die zeigt, dass das Protokoll selbst bei Nachrich-
tenverlusten in allen getesteten Szenarien zuverlässig funktioniert und ein gewisses
Maß an Verkehrssicherheit gewährleistet. Wir betrachten die Leistung des Protokolls
aus der Perspektive der Anwendungsschicht und bewerten, wie effektiv das Protokoll
die Anforderungen des Controllers erfüllt. Auf diese Weise stellen wir zusätzlich
einen Leistungsindikator bereit, um zu messen, wie gut das Protokoll einen kon-
stanten Informationsfluss gewährleistet. Damit lässt sich feststellen, ob eine andere
Steuerung mit dem vorgeschlagenen Kommunikationsprotokoll zuverlässig wäre.
iv
Contents
Abstract iii
Kurzfassung iv
1 Introduction 1
2 Fundamentals 3
2.1 Platooning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Platoon Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Cruise Control: CACC . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 IEEE 802.11p . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4 ETSI ITS-G5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2
ENSEMBLE: Platooning protocol definition and Communication strategy
11
2.3 Simulation Framework: PLEXE . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Implementation 19
3.1 Implementation in PLEXE . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Platoon Control Message (PCM) . . . . . . . . . . . . . . . . . . 19
3.1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.4 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Testing and Validating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Test Cases: Steady State Platooning . . . . . . . . . . . . . . . . 25
3.2.2 Test Cases: Acceleration/Deceleration . . . . . . . . . . . . . . . 28
3.2.3 Test Cases: Emergency Brake . . . . . . . . . . . . . . . . . . . . 30
4 Evaluation 32
4.1 Simulation Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Evaluation Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Network Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
v
Contents vi
4.3.1 Scenario: One Platoon . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2 Scenario: Three, six, and nine Platoons . . . . . . . . . . . . . . 38
4.4 Impact of Communication on CACC Performance . . . . . . . . . . . . 44
4.4.1 Scenario: Sinusoidal . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.2 Scenario: Emergency Brake . . . . . . . . . . . . . . . . . . . . . 46
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5 Conclusion 50
Bibliography 56
Chapter 1
Introduction
Vehicle transportation takes a major share in the transportation sector. In the EU
road transport for example continues to have the largest portion of inland freight
transport and accounted in 2018 for over 75 % of the total volume. In the area of
passenger transport a similar picture emerges, where in 2017 the passenger cars had
a share of over 80 % of inland passenger transport. [1]Next to the public transport,
the privately owned car is still the most used transportation system. Furthermore, the
overall traveled distance, as well as the number of privately owned cars, increased.
[2]Having such a high density on the road results in more road traffic and thus in
more traffic congestion, accidents, and pollution [3]. This also effects the efficiency of
transportation systems. To solve these problems, researchers and car manufacturers
are continuously trying to improve and innovate driving, using, e.g., Intelligent
Transportation System (ITS). One promising development in this field is platooning.
With platooning, multiple vehicles are organized in groups driving behind each
other with a minimized safety gap. These convoys are called platoons. The vehicles
of a platoon are driving autonomously using Cooperative Adaptive Cruise Control
(CACC) to maintain the small safety gap. CACC utilizes data from build-in sensors
and information from other vehicles via Inter-Vehicle Communication (IVC). By
reducing the inter-vehicle gap, but keeping the same cruise velocity, platooning can
increase the road utilization, improve the traffic flow and, due to less air drag, reduce
the fuel consumption and therefore emissions. Furthermore, having the vehicles
drive autonomously increases safety and can lead to an improved, less stressful
driving experience [4]–[6].
The introduction of platooning in the transportation sector is less complex for
trucks than for passenger cars. Since trucks travel more kilometers per year than
other road vehicles, the fuel and time savings would be significantly higher [7],[8].
In Europe fuel cost make approximately one-third of all operational costs for long
haulage heavy duty vehicles (HDVs), which is a strong economical incentive for
1
1 Introduction 2
truck operators, who can expect a faster return on investment. In 2011, driving
experiments were conducted, showing fuel savings of approximately 4 - 5 % for
the leader of the platoon and 10 - 14 % for the following vehicles. [9]In addition,
automated driving could potentially decrease workforce expenses in the long run,
which are particularly high in the trucking sector. [10]In order to support the global
deployment of platooning, an integrated multi-brand approach is required. For such
an approach, a standardized protocol is needed to regulate, e.g., the use of the
wireless channel and provide interoperable protocols between Original Equipment
Manufacturers (OEMs). This would avoid vendor lock-in and support forming
platoons of different vehicle types and brands, which is necessary to reach the full
potential of platooning. The European HORIZON 2020 project ENSEMBLE tries to
address this issue by unifying and standardizing platooning within Europe. To this
end, they published a new communication protocol and within proposed a concrete
implementation of communication for truck platooning in Europe, which is currently
under review at the European Commission (EC).
The need to analyze the proposed protocol derives from the fact that it is based
on theoretical considerations and since the protocol is the first of its kind, one can
not simply assume that all given specifications integrate without any complications.
Hence, it needs to be investigated if the proposed protocol behaves in practice as
desired. To do this we are going to conduct a simulation study, which enables
us to evaluate many scenarios in a flexible manner. We use this to evaluate two
main aspects of the proposed communication protocol, i.e., the communication
and the impact of the communication on the CACC performance and therefore on
the mobility. Therefore, the analysis will focus on regular operation, leaving other
aspects defined by the protocol, e.g., security and maneuvers, out of scope.
In this thesis we started by analyzing and implementing the proposed communi-
cation protocol as defined by the ENSEMBLE project, using PLEXE as the simulation
framework. Furthermore, several test cases were implemented to test and validate
the proposed communication protocol. Lastly, we implemented scenarios to eval-
uate the network layer and application layer performance and the impact of the
communication on the CACC and, therefore, on the mobility.
We contribute an in-depth study of the communication protocol proposed by the
ENSEMBLE project. For this we did an extensive performance evaluation, showing
that the protocol, even with packet loss, works reliable in all tested scenarios, and
guarantees a certain level of road safety. Considering the protocol performance
from the application layer perspective, we evaluate how effective the protocol fulfills
the requirements of the controller. By doing that, we additionally provide a key
performance indicator to measure how well the protocol ensures constant information
flow. That can be used to determine whether a different controller would be reliable
with the proposed communication protocol.
Chapter 2
Fundamentals
In this chapter, we will describe the fundamentals on which this thesis is based. We
start by describing the most important aspects of platooning, including mobility and
vehicular communication (Section 2.1). Then, we will give an overview of the content
of the proposed communication protocol itself (Section 2.2) and finally, briefly
describe the simulation framework PLEXE, which was used in the implementation
(Section 2.3).
2.1 Platooning
Platooning is an application fully relying on IVC, which at its core coordinates a
group of vehicles called a platoon. For platooning to be able to build and maintain a
platoon, multiple technologies are necessary. Essential are two components, which
work closely together. The first one is the control algorithm, which is needed to, e.g.,
regulate the relative inter-vehicle gap and coordinate all vehicles in order to stabilize
the platoon. The second one is the communication network, which is needed to
exchange information between the vehicles. [11]The control algorithm is realized
with a specific type of cruise control, which in order to function properly relies on
data received from other vehicles in the platoon. This causes the need for commu-
nication between these vehicles. The design of the control algorithm itself defines
the control topology [11]. It indicates which data from which vehicle the controller
takes into consideration, e.g., if the controller exploits data from the leader, the front
vehicle or even of vehicles behind.
In the following sections, we will first consider platoon control in Section 2.1.1
and 2.1.2 and then the communication network in Section 2.1.3 and 2.1.4.
3
2.1 Platooning 4
2.1.1 Platoon Control
Platoon control consists of two fundamental components, longitudinal and lateral
control. These are the two main aspects forming the regulation control of an au-
tomated vehicle. Longitudinal control is about maintaining a desired speed and
inter-vehicle gap, and lateral control is about lane keep and lane change. As de-
scribed in Section 2.2, the ENSEMBLE project defines different levels of platooning,
focussing on platooning level A first. It describes longitudinal automation but not
lateral automation yet, for which reason the lateral control is out of scope for this
thesis. The main control aim in platooning regarding longitudinal control is to
ensure that all vehicles move at almost the same speed while maintaining a given
inter-vehicle distance. Therefore the ENSEMBLE project defines Adaptive Cruise
Control (ACC) for the leader of the platoon and CACC for the following vehicles in
the platoon. ACC is an advanced longitudinal control system. It adapts the vehicle’s
velocity to the desired velocity or if there is a vehicle driving in front of it, to a
velocity that yields a desired distance to the preceding vehicle. To detect vehicles in
front and measure the relative velocity as well as the inter-vehicle distance the ACC
uses a radar or a scanning laser (lidar). [12]CACC is an enhanced version of ACC
and additionally uses wireless communication, so that information such as speed
and acceleration can be shared among multiple vehicles. This enables the possibility
to reduce the inter-vehicle gap without compromising safety. [11]In general, it is
expected that vehicles that can build a platoon will always have both CACC and ACC
functionalities.
Two essential performance indicators for the control of CACC are the level of
string stability and how well the controller handles actuation lag. Actuation lag
is defined as the time between a control impulse and the point in time where the
desired effect occurs, e.g., the time between the controller deciding to accelerate and
the actual acceleration of the vehicle. Actuation lag occurs because of factors like a
delay of sensors, engine response time and sampling delay, etc., which need to be
considered. [12],[13]A platoon is considered string stable if any error in position,
velocity, or acceleration of an individual vehicle is not amplified towards the end
of the platoon. [14],[15]A consequence of a lack of string stability would be that
errors are amplified within a platoon, such that the traffic flow, fuel consumption,
and the scalability concerning platoon length might be negatively affected. Various
CACCs can be found in the literature, which differ in design, requirements, and
characteristics [11]–[13],[16],[17]. As a result, the performance indicators, e.g.,
how much errors are attenuated, differ between CACCs.
2.1 Platooning 5
2.1.2 Cruise Control: CACC
In the following, we will describe the CACC selected for analyzing the proposed
communication protocol in detail. The protocol itself specifies that the leader is using
an ACC and the followers are using CACCs, but it does not define which controllers in
particular to use. A decisive aspect of the protocol is that it defines the inter-vehicle
gap as a time period instead of a length unit, for which reason we chose the CACC
described in [12]. This controller defines distances in the same way as a headway
time, which is the time a vehicle needs to travel a certain distance at the current
speed. Its main objective is that each vehicle follows its preceding vehicle at the
desired distance. The controller design is based on a standard ACC system and the
most common spacing policy [18]. This spacing policy is defined with a constant
part and a velocity part and determines the desired distance
dr,i
for a given point in
time. The desired distance is
dr,i=ri+hvi,2im, (2.1)
where
m
is a string of vehicles,
h
is the headway time,
vi
is the velocity of vehicle
i
, and
ri
is the constant part defined as the desired distance at standstill [12]. Due
to this spacing policy the string stability of the controller is ensured. The control law
for the CACC is defined as [12]
˙
ui=1
h(ui+kp(xi1xi(ri+hvi)) + kd(vi1vihzi)+ui1), (2.2)
where
ui
is the control input (i.e., desired acceleration) for the i-th vehicle in the
platoon, which is received by means of wireless communication.
xi
is the position of
the i-th vehicle in the platoon in
m
,
vi
is the velocity of the i-th vehicle in
m/s
,
zi
is
the acceleration of the i-th vehicle in the platoon in
m/s2
, and
kp
and
kd
are gains
used to tune the behavior of the controller. The controller defines that each vehicle
exploits only the data of the preceding vehicle and of the leader of the platoon. The
distance and relative speed are obtained from the radar and the desired acceleration
is received via the radio interface. By using wireless communication, there is an
advantage in system reactivity because each vehicle receives information on the
future actions of other vehicles.
2.1.3 IEEE 802.11p
In the following, we will consider the communication network, more precisely the
IVC. Even though there are various short-range radio technologies, which can be
used for IVC, we are only introducing those used in the proposed communication
2.1 Platooning 6
protocol and their main aspects. The proposed communication protocol uses the
higher layer protocol stack ETSI ITS-G5 [19], based on IEEE 802.11p [20]. IEEE
802.11p, in turn, is an amendment to IEEE 802.11 [21], also called Wireless LAN
(WLAN), which adds missing parts of the functionality needed for an efficient IVC.
This is, for instance, and most importantly, the operation at around 5.9 GHz.
First, we will look at some important aspects of wireless LAN (WLAN), which
have been adopted to IEEE 802.11p. This mainly affects the data transmission.
In the MAC layer, WLAN uses a network multiple access method, called Carrier
Sensing Multiple Access with Collision Avoidance (CSMA/CA). CSMA/CA means
that devices, e.g., vehicles, try to avoid collisions by only starting to transmit after
they sensed the channel to be idle for the duration of an interframe space (IFS).
Therefore they have to continuously observe the channel to identify whether that is
the case or not.
In the case a device wants to start a transmission but cannot yet transmit, because,
e.g., the channel is not idle yet or the channel is idle but the IFS is not over yet,
a backoff procedure is initiated, and the frame gets queued. This ensures that as
soon as the channel becomes idle, synchronous access will be avoided. To do so, a
random backoff time from a pre-configured interval called contention window gets
drawn. During every interval, the channel is idle this backoff time is decremented
until it reaches zero, or the channel becomes busy again. If the backoff time reaches
zero, the transmission can be performed, and in the case the channel becomes busy,
the reduction of the backoff time pauses until the channel becomes idle again for
an IFS. At the same time, the contention window is increased if a transmit attempt
fails. As soon as the transmit attempt succeeds, the contention window is reset.
If a transmission is finished, the backoff procedure gets invoked as well, so other
vehicles frames, which are still in backoff, get a chance to be transmitted. [22]
Another important aspect is Enhanced Distributed Channel Access (EDCA). EDCA
provides Quality of Service (QoS) mechanisms, which by setting levels of priority
enables to differentiate better between high-priority and low-priority data. These
levels of priority are called Access Categorys (ACs) and are divided into AC_VO,
AC_VI, AC_BE, and AC_BK, AC_VO being the one with the highest priority. The
channel-access parameters, e.g., minimum and maximum contention window size
and the IFS length, corresponding to the ACs are set according to its priority and,
therefore, according to the traffic expected in each AC. This is done so that higher-
priority frames can access the channel more likely as well as are retried sooner
than others. Therefore new introduced IFS lengths are called AIFS or arbitration
interframe space. As shown in Figure 2.1, every AC has its own queue with its own
backoff timer in which the frames will be stored. In the case that two or more backoff
timers are reaching zero simultaneously, this will be handled like a collision by the
2.1 Platooning 7
map frame to AC
from higher layer
AC3
AC0AC1AC2
pick frame for transmission, trigger backoff where appropriate
winning frame
Figure 2.1 – An illustration of the EDCA queue management from [22].
lower-priority queue.
Before IEEE 802.11p got developed, the available bandwidth was too little to
support some of the existing ITS applications and also the spectrum had to be shared
with other applications. In order to solve this problem, the 5.9-GHz frequency
band and thus a dedicated spectrum for ITS applications got reserved. The exact
partitioning of it differs in the respective areas of application. In Europe, three
10-MHz channels (176, 178, and 180) for safety-related communications and two
(172 and 174) for non-safety communications were reserved. An overview of the
channel allocation is given in Figure 2.2. To use the new frequency band efficiently,
the amendment IEEE 802.11p was developed. It contains the necessary adjustments
to IEEE 802.11, not only for an efficient use of the 5.9-GHz band but also to fulfill
the requirements of vehicular networks.
2.1.4 ETSI ITS-G5
Worldwide three different IVC protocol stacks for Europe [19], Japan [23], and the
USA [24]have been developed, which mainly differ in their number of available
channels. Because we are looking at a communication protocol proposed for Europe,
2.1 Platooning 8
5.860
172
SCH 4
0
5.870
174
SCH 3
23
5.880
176
SCH 1
33
5.890
178
SCH 2
23
5.900
180
CCH
33
5.910
182
SCH 5
0
5.920
184
SCH 6
0
f(GHz)
channel #
designation
power (in dBm)
Figure 2.2
– Frequencies and maximum transmit power as assigned in Europe
according to ETSI EN 302 663. The spectral masks are not to scale. [22]
we will only consider the European protocol stack for IVC, leaving the others out of
scope. The protocol stack for Europe got standardized by ETSI and is called ETSI
ITS. Regarding the available channels, the Electronic Communications Committee
(ECC) has allocated up to five dedicated channels in the 5.9 GHz band for ITS. As
mentioned earlier, ETSI ITS is based on IEEE 802.11p and, therefore, on IEEE 802.11
WLAN. These have been adapted to the ECC regulations, and by that got extended to
a family of standards, which gets referred to as ETSI ITS-G5. To avoid any confusion,
we will call it from now on ETSI ITS-G5 as well.
Another important aspect that distinguishes ETSI ITS-G5 from the other protocol
stacks is that it utilizes a multi-radio multi-channel system. This means that it assumes
that multiple channels are available. Regarding the multi-radio, ETSI ITS has defined
that a vehicle wanting to exchange safety information shall be additionally equipped
with an ETSI ITS-G5, i.e., an IEEE 802.11p, transceiver, which is constantly tuned to
the Control Channel (CCH) (a.k.a. channel 180). Service Channels (SCHs) on the
other hand can freely be used by additional IEEE 802.11p transceivers, to e.g., use
services offered via regular WiFi or cellular technologies. [22]
Figure 2.3 shows the different layers of the ETSI ITS protocol stack. ETSI ITS
abstracts from channel-access technologies, i.e., the used MAC and physical layers
of the various installed transceivers, introducing the concept of an access layer. Part
of the access layer is the Decentralized Congestion Control (DCC) access control
mechanism, which was also standardized by ETSI [25]–[27]. Because it is a rather
complex set of different concepts, we will only briefly outline the main idea behind it.
The objective of DCC is to prevent the channel from being overloaded and therefore
provide congestion control. To do so, the wireless channel’s access becomes restricted
and depends on the current channel state. This is done by the ETSI ITS DCC access
control mechanism [25]. The algorithm is based on a state machine, consisting of
three states between which the state machine is switching, RELAXED, ACTIVE, and
2.1 Platooning 9
Management
Security
Applications
Efficiency Comfort ...
Safety
Facilities
DENM LDM ...
CAM
Application Information ...
Transport and Network
Access
ITS-G5 Wi-Fi 3G
ITS-G5
BTP
IP
GeoNetworking
...
Figure 2.3 – An excerpt from the ETSI ITS protocol stack from [22].
RESTRICTIVE. Each state uses a different transmit power, modulation, beacon rate,
and Clear Channel Assessment (CCA). Depending on the observed Channel Busy
Ratio (CBR) the current active state is decided. The management and security layers
are available to all layers of the protocol stack and are therefore depicted vertically in
Figure 2.3. They provide cross-layer services for, e.g., choosing an access technology
or changing pseudonyms at ideal times. Above the access layer is the networking and
transport layer. On the one side, it provides TCP/UDP over IP services, and on the
other side, the Basic Transport Protocol (BTP) over a GeoNetworking (GN) service.
[22]BTP is a connectionless transport protocol to pass protocol data units (PDU) to
the GN protocol and, therefore, to the network layer. GN itself supports different
kinds of communication technologies. Two crucial aspects of these technologies
are the geographical addressing, which means that for forwarding packets among
ITS stations, the addresses are based on geographical positions of the ITS station
and that the forwarding relies on each station knowing its environment in the
network. The next layer on top of the networking and transport layer is the facilities
layer. Subdivided into information support, communication support, and application
support, the facility layer provides common support functionality for all layers of
the ETSI ITS stack. For example, Cooperative Awareness Messages (CAMs) and
Decentralized Environmental Notification Messages (DENMs) are about the sending
and receiving of generic messages. As an example there are CAMs and DENMs,
which are about the sending and receiving of generic messages. CAMs, for example,
2.1 Platooning 10
ensure that vehicles on the road and infrastructure beside it are informed about each
other’s dynamics, position, and attributes. A vehicle, by receiving CAMs, can detect
approaching vehicles not yet seen by the driver or by line-of-sight sensors such as
radar and camera. [26]DENMs, on the other side, are triggered on behalf of an ITS
application when other in-vehicle sensors detect a dangerous situation. [28]
2.2 ENSEMBLE: Platooning protocol definition and Communication strategy11
2.2 ENSEMBLE: Platooning protocol definition and
Communication strategy
The ENSEMBLE project is an EU co-funded project coordinated by TNO, the Nether-
lands Organisation for Applied Scientific Research. Their main objective is, do
fundamental work to enable the adoption of multi-brand truck platooning in Europe.
They try to do this by unifying and standardizing Platooning within Europe. The
project started in June 2018 and is officially a 3.5 year EU project. At the time this
thesis was written, the project did a public demonstration taking place in Barcelona
of trucks from seven different manufacturers driving in a fully coordinated platoon
for the first time
1
. This demonstration offered the opportunity to perform various
measurements. As a next step, the ENSEMBLE project is doing an impact analysis to
predict the effect of platooning on traffic flow, fuel consumption, as well as studies
into the experience of drivers and other road users.
The ENSEMBLE project itself is structured in 6 work packages, illustrated in
Figure 2.4. With regard to the simulation study in this thesis, the focus is on WP2 and
WP5. WP2 defines the specifications of the multi-brand truck platooning concept
and WP5 the testing, validation, and demonstration of the multi-brand platoon
implementation. The current status of the work packages is published in deliverables
on which this thesis is based. In these deliverables, ENSEMBLE notes that they
constantly validate and modify the specification during the whole project, for what
reason they announced to publish updated versions of the deliverables. We use
only the deliverables existing at the time of writing this thesis. Therefore future
modifications can not be included.
1https://platooningensemble.eu/events/23-september6054b64811568
WP6
Exploitation and
Dissemination
WP2
Specification of a
generic solution
WP5
Testing and Demonstration
WP3
Platooning In-Vehicle Technology
WP4
Infrastructure, Logistics, Impact analysis
WP1
Management
Figure 2.4 – Project structure of ENSEMBLE. [29]
2.2 ENSEMBLE: Platooning protocol definition and Communication strategy12
The ENSEMBLE project defines three different platooning levels in order to break
down the complexity and enabling a stepwise approach of the deployment of multi-
branded truck platooning. [30]These levels are called platooning level A, B, and C.
The project describes platooning level A, which is implemented first. For platooning
level B and C only an initial outlook is given and these will be build on top of level A.
Platooning level A is defined with a manual or advanced assist system (e.g. ACC) for
the leading truck of the platoon and an autonomous longitudinal control (e.g. CACC)
for the following vehicles. The lateral functions are not coordinated on platoon
level. The inter-vehicle distance is at minimum 0.8s at maximum cruise velocity
as long as string stability and vehicle performance is given. ENSEMBLE considers
up to 7 trucks as a maximum number for platooning level A. Which means that for
simulation and testing purposes a maximum number of 7 trucks will be considered.
The proposed communication protocol itself is a proposal for a concrete im-
plementation of communication for truck platooning in Europe and is defined in
document D2.8 [29]. The proposed communication protocol describes a facilities
layer protocol to support the platooning application using the wireless technology
ITS-G5 (i.e. IEEE 802.11p) at 5.9 GHz band (see Figure 2.5). This protocol utilizes
functionality such as CAMs or DENMs from ETSI ITS-G5, while using the same
lower layer protocols as for transmitting CAMs and DENMs. A vehicle is announc-
ing its platooning capability in its CAMs, which for that reason, are extended by a
platooning container. Therefore to enable the functionality of platooning, a set of
preconditions must be fulfilled. If that is the case and a vehicle wants to platoon,
EN 302 637-2
CAM
ENSEMBLE
platooning
TS 102 687 DCC
EN 302 636-5-1 BTP
SecurityEN 302 636-4-1 GN
EN 302 663 (ITS-G5)
Facilities layer
Networking &
Transport layer
Access layer
EN 302 637-3
DENM
= Developed in ENSEMBLE
= Standardized
Figure 2.5
– C-ITS protocol stack with standardized protocols and the ENSEM-
BLE platooning protocol. [29]
2.2 ENSEMBLE: Platooning protocol definition and Communication strategy13
the vehicle will indicate this through the CAM. In the following, we will describe
this procedure in detail. The protocol itself consists of four components, which
are IDLE, JOIN, PLATOON, and LEAVE. The IDLE mode is for individual operation
isJoinable = TRUE
isJoinable = FALSE
CAM
JOIN REQUEST
JOIN RESPONSE
PCM
PCM
..
LEAVE
Leading vehicle Following vehicle
Travelling direction
isJoinable = TRUE
Figure 2.6
– Overview of the platooning procedure from join to leave according
to the proposed communication protocol in [29].
with regular CAMs or for looking for a platoon to join. Therefore the newly added
container of the CAM includes the flag isJoinable stating if the vehicle is interested
in receiving join requests or not. In the JOIN mode platoons are built by performing
join maneuvers. They are sending JOIN REQEUSTs and JOIN RESPONSEs as well
as setting the isJoinable Flag. In the PLATOON mode, Platoon Control Messages
(PCMs) are getting exchanged continuously between members of the platoon to
share information about the current state and which actions should be performed. If
vehicles in the platoon do not receive PCMs for a certain amount of time the platoon
must dissolve and re-initiate again. In the LEAVE mode vehicles separate from the
platoon and continue on an individual basis by sending a LEAVE message and setting
the isJoinable flag to its desired state, which will bring them back to IDLE mode.
The protocol defines the message types control and management and new data
elements. The management frames include join request, join response and leave
messages and the control frame consists of the described PCMs, which contain the
signals for the operations performed by the platoon. For the content of the messages
the protocol defines existing DE (data elements) and DF (data frames) from TS 102
894-2 [31], as well as new data elements introduced by the platooning protocol.
2.2 ENSEMBLE: Platooning protocol definition and Communication strategy14
With respect to security the ENSEMBLE project published a separate document
(D2.9 [32]), in which they describe that the protocol will be part of the public key
infrastructure (PKI) developed for C-ITS where messages are signed and verified
using a temporarily authorization ticket. In addition, the PCMs will also be encrypted
using symmetric keys. Because the security is out of scope we will not go into details
here.
2.3 Simulation Framework: PLEXE 15
2.3 Simulation Framework: PLEXE
We decided to use the simulation software PLEXE
2
[33],[34], which is an extension
of the simulation framework Veins
3
[35], adding platoon support. Veins itself is
used for running vehicular network simulations. Therefore it couples networking
from OMNeT++
4
[36]and mobility from Simulation of Urban MObility (SUMO)
5
[37]and extends these to offer several models for the IVC simulation, such as IEEE
802.11p [20]and IEEE 1609.4 [38]. OMNeT++ is an event-based network simulator
to model communication networks, written in C++ [36]. It can be used to design and
evaluate, e.g., wired and wireless networks as well as communication protocols. With
SUMO on the other side, realistic vehicle mobility and traffic simulation are possible.
It provides routing algorithms, vehicle definitions, and car-following models, e.g.,
the car-following model by Krauss [39], which with some modifications is the default
model used in SUMO. Scenarios with road networks of varying scope with not only
vehicular but also human traffic can be simulated. [37]For a better understanding of
how these simulators are working together, Figure 2.7 shows a schematic overview.
Veins creates a network node in OMNeT++ for each vehicle in SUMO. Each of these
nodes is associated with a network stack. This includes an IEEE 802.11p wireless
network interface, plus a beaconing protocol and one or more applications running
on top of it. The communication between the network and the traffic simulator takes
place via the TraCI interface provided by SUMO. On the one side, whenever vehicles
are moved in SUMO Veins mirrors that movement in the corresponding OMNeT++
nodes, and on the other side, Veins can query SUMO regarding the current simulation
status (e.g., speeds, positions, number of vehicles, etc.), or change traffic dynamics
by, for example, re-routing vehicles via TraCI. [33]Furthermore, PLEXE extends
TraCI interactions to access vehicle data from SUMO as well. These, for instance,
can be used by platooning protocols and applications, meaning such data can be
sent to e.g., the CACCs in SUMO, if a vehicle, equivalent to an OMNeT++ node,
receives it.
The main arguments for using PLEXE are that the most common controllers are
already implemented and come with the WLAN 802.11p as a basis. Furthermore,
the ability to perform mixed traffic scenarios and the realistic simulation of both
wireless networking and vehicle dynamics will be beneficial.
2http://plexe.car2x.org
3http://veins.car2x.org
4https://omnetpp.org
5https://www.eclipse.org/sumo/
2.4 Related Work 16
TraCI Interface
Car-following Models
SUMO
Krauss
CC/ACC
CACC
KraussIDM
Cruise Controllers
OMNeT++ Network Simulation
Veins Framework
Platooning
application
Application prot.
Beaconing prot.
802.11p NIC
Mobility
Network Stack
TraCI Interface
Figure 2.7 – Schematic structure of the simulator. [33]
2.4 Related Work
In this chapter we describe the work that has been made in the field of analyzing com-
munication protocols for platooning based on IEEE 802.11p/IEEE 1609.4 PHY/MAC,
as well as evaluating the impact of communication on the performance of CACC. In
[40]the authors discuss different beaconing solutions for platooning by comparing
four proposed approaches with adaptive beaconing protocols, i.e., DynB [41],[42]
and ETSI DCC [25]–[27]. For the proposed approaches they introduce a standard
static beaconing approach with and without transmit power control, called STB and
STBP, as well as a slotted approach with and without transmit power control, called
SLB and SLBP. They investigate these different communication strategies comparing
the network and application layer performance by taking the requirements of the
controller, transmit power adaptation, and using synchronized communication slots
into account. As a result they demonstrate that even on very crowded freeway
scenarios the approach of having synchronized communication slots with transmit
power adaptation is well suited for platooning. Furthermore, they prove, that the
consideration of high-level requirements from the application layer perspective can
improve the performance, while also avoiding network congestion, and, finally, they
investigate the impact of the communication on the CACC performance. In order to
do that they considered an emergency brake scenario and obtained the requirements
2.4 Related Work 17
of the CACC application. As metric they consider the minimum inter-vehicle gap
after the platoon stands still in relation to the beacon interval for different leader
decelerations, showing that the maximum tolerable delay depends on the dynamics
of the maneuver and that the maximum delay should not be bigger than 0.2 to 0.3 s.
Another analysis using similar methods has been made in [43]. In which another
dynamic beaconing approach for platooning, called Jerk Beaconing, was developed.
Jerk Beaconing is coupled with a reliable delivery mechanism and uses the vehicle
dynamics to only send beacons when needed. While analyzing it, they compare
the protocol with commonly used 10 Hz static beaconing using similar methods
as in [40], considering, e.g., the CBR or the inter-message delays. Additionally,
they also compute the minimum distance between any pair of consecutive vehicles,
to analyze the safety. As a result, compared to static beaconing, Jerk Beaconing
shows benefits regarding network resource saving, safety and also in keeping the
inter-vehicle distance closer to the desired one even in highly demanding scenarios.
The work in this paper raises the further question, if a theoretical link between the
performance of the controller and the beacon interval can be found. This could lead
to the development of an optimal algorithm, which could be configured according
to the desired performance of the controller.
In the literature there has also been done some work explicitly regarding the
impact of communication on the CACC performance. In [44]the authors consider
the impact of dynamic wireless channel conditions on the CACC performance. They
provide an insight in the performance of 802.11p protocol, characterizing the perfor-
mance in terms of different metrics, using the CBR, latency, throughput, packet loss,
mean burst length and reliability. As a result their initial tests show the performance
of throughput and latency of 802.11p radios. Furthermore, from a testbed on a cam-
pus they depict metric results and thus show proof for correlated loss. By that they
confirm that assumptions in studies about a Bernoulli loss process are not realistic.
This leads to the idea of developing robust loss models, which can parameterize the
range of expected loss process dynamics.
In [45]the authors discuss the impact of communication explicitly on the string
stability of CACC. To do so they evaluate its performance with various beaconing
intervals, packet loss ratios, and time headways. As a result they show that lower
beaconing intervals and/or higher packet loss ratios prevent vehicles from receiving
new information, which lowers the performance of the controller on string stability.
Therefore the beaconing interval and packet loss ratio have a significant influence
on the performance. Given a required time headway, the beaconing interval as well
as the packet loss ratio have to be set according to it, to be able to guarantee string
stability.
The proposed communication protocol by ENSEMBLE is another static beaconing
approach for platooning, which hasn’t been analyzed yet. Even though we won’t
2.4 Related Work 18
compare the protocol to other ones, we will use similar methods in the scope of
this thesis to evaluate it with regard to the network layer and application layer
performances as well as the impact of communication on the CACC performance.
Chapter 3
Implementation
In the following chapter we will describe how we extended the implementation of
PLEXE by the proposed communication protocol and how we tested the implementa-
tion as well as validated the protocol. The following implementations rely on PLEXE
version 3.0, based on Veins 5.1, SUMO 1.4.0, and OMNeT++ 5.6.2.
3.1 Implementation in PLEXE
3.1.1 Platoon Control Message (PCM)
As mentioned in Chapter 2.2 PCMs are continuously getting send during the PLA-
TOON mode and therefore are building the core of the proposed communication
protocol. For this reason we extended PLEXE by that message type. The start time
of the PCM transmissions depends on the time of the join procedure. From there
on the PCMs are getting send at a rate of 20Hz, i.e., every 50 ms to every platoon
member. However, since no join procedures are used in the simulation, the start
time is set randomly. In general the PCMs of one vehicle are always getting send
to every member of the platoon. The protocol defines that no Acknowledgements
(ACKs) are used and instead refers to implicit ACKs, implying that around every 50
ms a vehicle of the platoon can expect a new message from all the other platoon
members.
The PCM itself contains all necessary data for the longitudinal as well as lateral
control of the vehicle. In the document D2.8 [29]the ENSEMBLE project provides a
first draft of an ASN.1 file describing the content of the PCM in detail. However, since
most of the data contained in the PCMs is regarding geographical information or,
e.g., is a preparation for the lateral control being used in the future, these are values
which are not necessary for the simulation and wouldn’t be used. For that reason
19
3.1 Implementation in PLEXE 20
we implemented the PCM only with values which are relevant in the simulation. To
create a realistic simulation, the packet size of PCMs got set to a realistic value.
With regard to the packet size of PCMs the proposed communication protocol
doesn’t define a size or size range for it and there couldn’t be found any studies
regarding it neither. Therefore we determined a realistic packet size by encoding a
PCM created after the given ASN.1 schemas. To do so we used the ASN.1 Playground
of the OSS Nokalva website
6
, which is a program to compile, encode and decode
ASN.1 schemas. To encode these messages different encoding rules exist. The
proposed communication protocol doesn’t define any encoding rules for the ASN.1
structure containing the PCMs, however in document D2.9 [32]the encoding rule
for the security information is given as COER. Therefore we assume this encoding
rule is used for the PCMs as well. In addition the PCMs will be encapsulated in
lower layers headers and trailers which results in a larger packet size of the actual
send message. Figure 3.1 shows an overview of the packet encapsulation of the
platooning PDU. As mentioned in Chapter 2.3 Veins as part of PLEXE contains an
implementation of 802.11p, for what reason regarding the PHY and MAC header
and trailer the PCM will be encapsulated as required. However, the other headers
shown in Figure 3.1 are not implemented in the simulation and would only be used
to add on to the packet size, but not be used at any other point. That’s why we
summed up the remaining header sizes as defined by the protocol and added it as a
total to the packet size of the PCMs. This is shown in detail in Table 3.1. For that we
used the headers as outlined in document D2.8 [29]. For the security of platooning,
the PCMs are getting encrypted using a symmetric encryption key. Even though the
security aspect is out of scope, this is adding up on the packet size of the PCMs as
well, for what reason this must be taken into account. The security is part of the GN
headers (GN secured header) and are described in detail in document D2.9 [32].
Regarding the security certificates as shown in Figure 3.1 no further details could
be found for what reason it got left out of the computation. For each of the listed
parameters in Table 3.1 we chose the maximum possible values to get a rather larger
PCM packet size. In order for the vehicles to be able to send and receive PCMs in the
6https://asn1.io/asn1playground/
Parameter Value
PCM/Platooning PDU 126 Bytes
LLC header 8 Bytes
GN headers 105 Bytes
BTP header 4 Bytes
Total 243 Bytes
Table 3.1 – Values for the computation of the PCM packet size.
3.1 Implementation in PLEXE 21
PHY
header
MAC
header
LLC
header
GN
headers
BTP
header
Platooning
PDU
Security
certificates
MAC
trailer
Layers Access Network Transport Facilities Network Access
Figure 3.1 – Packet encapsulation of the platooning PDU. [29]
simulation, a protocol and application specifically for sending and receiving PCMs
got implemented as well.
3.1.2 Requirements
In addition to the structure of the proposed communication protocol itself the
ENSEMBLE document D2.8 [29]describes 25 requirements which need to be fulfilled
according to the ENSEMBLE project specifications. There are some preliminary
requirements only used for the ENSEMBLE project, which will be modified for
the regular use of the proposed communication protocol. Requirement REQ001,
e.g., defines that no DENMs will be implemented, because they are not necessary
during platooning for the proposed communication protocol, however in real life
applications vehicles might have the capabilities to receive and transmit DENMs. In
requirement REQ002 it is defined that no DCC will be implemented. This is because
the ENSEMBLE project assumes that the DCC algorithm will not be activated due to
very low CBR values. Again for real life applications DCC needs to be investigated
for platooning.
The proposed communication protocol assumes that the channel load on channel
180 (CCH) will be high due to many ITS-G5 equipped vehicles transmitting CAMs
and DENMs. Therefore the DCC will reduce the number of packet transmissions. To
avoid disrupting the platooning application the protocol defines a separate channel
for the platooning communication, i.e., the PCMs. For this purpose they propose
channel 176 (a.k.a., Service Channel 1 (SCH1)). This will not be the case in the
ENSEMBLE projects test scenarios, therefore requirement REQ006 defines that all
communication will take place on channel 180 (CCH). However, since the protocol
defines the use of two separate channels for real life applications, we assumed the
use of two channels as well. Since we focus on the PLATOON mode and CAMs as
well as DENMs are transmitted on a separate channel we won’t implement any other
message type than PCMs. Hence, we will drop all requirements regarding CAMs and
DENMs. The same applies to requirements regarding the security as well as platoon
management messages. Latter are as mentioned in Section 2.2, e.g., join or leave
messages, which are not part of the PLATOON mode neither. The requirements we
took into account are listed in Table 3.2 as defined in the document [29].
3.1 Implementation in PLEXE 22
Requirement
No.
Description
REQ001
No specific triggering of DENMs will be implemented in ENSEM-
BLE.
REQ002 No DCC will be implemented in ENSEMBLE.
REQ003 The output power is set to 23 dBm e.i.r.p.
REQ004
The ENSEMBLE platooning communication system needs to fol-
low the duty cycle requirements outlined in Clause 4.2.10 of EN
302 571 V2.1.1.
REQ005
The ENSEMBLE platooning communication system needs to im-
plement the database solution found in TS 102 792 V1.2.1.
REQ006
All ITS-G5 communication in ENSEMBLE will take place on chan-
nel 180 (CCH).
REQ010 Platooning PDUs shall use the BTP-B header.
REQ012
Platooning control PDU shall set the field destination port TBD
and destination port info to 0.
REQ013
The single-hop broadcast packet header as outlined in Clause
9.8.4 of ETSI EN 302 636-4-1 V1.3.1 shall be used.
REQ014
The parameter setting of the single-hop broadcast packet with
its different headers shall be as outlined in Table 2.
REQ015
The LLC and SNAP headers as outlined in Table 3 shall be used.
REQ016
The default rate for all messages transmitted in ENSEMBLE is 6
Mbps.
REQ017 The platoon control message shall use access category AC_VO.
Table 3.2 – Selected requirements as defined by [29].
3.1.3 Communication
As defined in requirement REQ017 the PCMs are using access category AC_VO, being
the messages with the highest priority. Additionally, we set the bitrate to 6 Mbit/s
and the transmit power to 200 mW. By reading the standards mentioned in the
requirements of the proposed communication protocol, several values regarding the
communication, which were not defined by the protocol, needed to be set as well.
This concerns parameters like sensitivity, noise floor or CCA-threshold, which got set
according to values defined by underlying standards. These values are summarized
in Table 4.1 together with all necessary network simulation parameters.
3.1.4 Mobility
As mentioned in Chapter 2.1 the CACC described in [12]will be used as the controller.
This controller is already implemented in PLEXE and only its parameters need to
be set. The two gain values
kp
and
kd
are set to 0.2 and 0.7. The headway time
h
as specified by the protocol is set to 0.8 s and the actuation lag
⌧
is set to 0.5 s.
This time constant was chosen as a worst-case delay, taking the delay of sensors,
3.1 Implementation in PLEXE 23
Parameter Value
Path loss model Free space (↵=2.0)
PHY/MAC model IEEE 802.11p/1609.4 single channel
Frequency 5.89 GHz (CCH)
Bitrate 6 Mbit/s
Access category AC_VO
MSDU size 200 B
Transmit power 200mW
Sensitivity -94 dBm
Noise floor -95 dBm
CCA-threshold -65 dBm
PCM frequency 20 Hz
Table 3.3 – Network simulation parameters.
response of the engine, sampling delay, etc. into account. [12]The desired distance
at standstill
ri
is set to 2 m, which also defines that the inter-vehicle distance will be
the headway time plus the 2 m distance at standstill.
In order to simulate trucks a couple of parameters like the truck size or the engine
characteristics are needed to be set and as described later on in Chapter 3.2 there is
not only one type of truck, but at least seven different truck types needed. As an
orientation and for the first test cases we used the default values of the vehicle type
truck given by SUMO
7
, which are defined as shown in Table 3.4. Based on these
values, we created the other truck types, whose values may differ due to different
truck loads or engine characteristics. Overall, we try to create a range of values
which cover most of the cases. The truck with the worst values has an acceleration
of 0.8
m/s2
and a deceleration of 4
m/s2
and the one with the best values has an
7https://sumo.dlr.de/docs/Vehicle_Type_Parameter_Defaults.html
Parameter Value
vClass truck
length 7.1 m
width 2.4 m
height 2.4 m
minGap 2.5 m
amax accel 1.3 m/s2
bdecel 4 m/s2
beemergency decel 7 m/s2
vmax maxSpeed 130 km/h
speed deviation 0.05
Table 3.4 – Default values of the vehicle type truck.
3.2 Testing and Validating 24
acceleration of 1.6
m/s2
and a deceleration of 6
m/s2
. All 7 different truck types are
defined with values evenly distributed within these boundaries. Since the default
value for the deceleration of trucks given by SUMO is already 10 to 20 % under the
minimum deceleration stated by the StVZO in Germany (§41 Abs. 4 S. 1 StVZO, §41
Abs. 9 S. 1 StVZO), we used 4 m/s2as the worst value.
3.2 Testing and Validating
To test the implementation of the proposed communication protocol and to validate,
whether the protocol in its execution delivers the results as ENSEMBLE claims, we
implemented several test cases defined by the ENSEMBLE project. Document D5.1,
called "First version Demonstration and test plan" [46], published by the ENSEMBLE
project, defines the first states of their test plan, including a list of test cases. These
test cases are subdivided into three different levels:
• Mono-brand testing
• Three-brand testing
• Multi-brand testing
The Mono-brand testing contains test cases, which are defined for a platoon with
vehicles of only one brand, the Three-brand testing defines a platoon with vehicles of
three different brands and the Multi-brand testing defines a platoon with vehicles
of multiple brands. The main idea behind these testing levels is to ensure the
interoperability between different brands on the road. This aspect can not be tested
in a simulation, but testing the interaction between vehicles with different parameters
is reasonable as well. By setting different values for the engine characteristics, it is
possible to simulate vehicles with different engines or loads. This lets us evaluate
how the protocol is behaving under different vehicle conditions. The different vehicle
parameters were set as described in Section 3.1.4. The Mono-brand testing is using
the vehicle with the default values, while the remaining vehicles are distributed
randomly on the other testing levels.
The following Table 3.5 shows the test cases, which have been chosen to test
the implementation and validate the proposed communication protocol. The test
cases 0.2, 1.2, 1.3 and 1.7 are from Mono-brand testing, 2.2, 2.3 and 2.12 are
from Three-brand testing and 2, 5 and 7 are from Multi-brand testing. They were
classified into three categories: Steady State Platooning,Acceleration/Deceleration
and Emergency Brake. Steady State Platooning stands for regular platooning without
any influencing factors, Acceleration/Deceleration includes a couple of test cases
regarding accelerating and decelerating during platooning and Emergency Brake
describes an emergency brake test case for each level. The test cases will be described
3.2 Testing and Validating 25
in the following sections in detail. They were chosen to cover the same aspects for
each level, which except of minor exceptions is the case. ENSEMBLE for instance
doesn’t define a Steady State Platooning test case for Three-brand testing. As shown
in the following, these test cases make it possible to test and validate the mobility
and network behavior during regular platooning, acceleration and decelerations as
well as during an emergency brake.
The test document D5.1 defines, according to the official description of platooning
level A (D2.2 [30]), a couple of general conditions, which apply to all of the test
cases: A platoon consists of 7 trucks, which are driving with a minimum headway
time of 0.8 seconds at maximum cruise velocity on a highway. The maximum cruise
velocity is depending on country regulations. In Germany the speed limit for trucks
is 22.22 m/s, for what reason the maximum cruise velocity in the test cases will be
22.22 m/s as well.
3.2.1 Test Cases: Steady State Platooning
Steady State Platooning is defined by ENSEMBLE as a platoon operating with a
short inter-vehicle distance and within the longitudinal control limits described for
platooning. To test Steady State Platooning and hence regular platooning, the test
cases 0.2 and 2 got chosen. Test case 0.2 is defined at design gap (0.8 s) and at
maximum design speed (22.22 m/s). Test case 2 is defined in the same way, except
for speed, which is set to 25 m/s. Because this exceeds the maximum cruise velocity
of 22.22 m/s we defined in the previous section (Section 3.2), this test case was
performed at 22.22 m/s instead. As mentioned in Section 2.1.2 the chosen controller
Name No./ID Testing Level
Steady State Platooning 0.2 Mono-brand testing
2 Multi-brand testing
Acceleration/Deceleration 1.2 Mono-brand testing
1.3 Mono-brand testing
2.2 Three-brand testing
2.3 Three-brand testing
5 Multi-brand testing
Emergency Brake 1.7 Mono-brand testing
2.12 Three-brand testing
7 Multi-brand testing
Table 3.5 – Test cases selected from the test document D5.1 [46].
3.2 Testing and Validating 26
requirers a set desired distance at standstill, which we set to 2 meters. These 2 meters
will be added to the expected inter-vehicle gap, which results in
ri+h·vi=2m+(0.8s·22.22m/s)=19.77m. (3.1)
First of all it is necessary to look at the communication between the vehicles of
the platoon and check if it is working as expected by the protocol. Therefore we
will consider the sending and receiving of PCMs. As mentioned in Section 2.2 the
proposed communication protocol defines that each vehicle of a platoon is sending a
PCM every 50 ms to every other member of the platoon. Figure 3.2a shows a section
(a) sending PCMs
(b) receiving PCMs
Figure 3.2
– An excerpt of the vehicle communication showing the sending
and receiving of PCMs. Plot (a) showing the timestamps PCMs send by each
member of the platoon within 100 ms; plot (b) showing the PCMs received by
each member of the platoon within 100 ms. A missing point indicates that the
vehicle self was sending.
3.2 Testing and Validating 27
of the timeline indicating which vehicle sent a PCM at what time. Looking at it, it is
clear to see that every vehicle is sending messages every 50 ms. Outside the cut-out
the values looked the same. Figure 3.2b shows related to the sent PCMs at what
time which vehicle is receiving them. The horizontal axis represents the time (s) and
the vertical axis the vehicle id of the receiving vehicle, starting at 0 for the leader
vehicle. It can be seen that the sending vehicle is sending the PCM to every other
vehicle of the platoon (in this case 6) and each one of these vehicles is receiving the
messages as expected. This also implicates that no messages were lost during these
test cases. Furthermore, no collisions appeared.
We were able to verify that the communication functions independent from
the mobility by comparing the communication of test cases with different mobility
behavior. As a result the communication was behaving exactly the same in every test
(a) speed
(b) distance
Figure 3.3
– Vehicle dynamics of test case 0.2 (Steady State Platooning).
Plot (a) shows the speed of each vehicle; plot (b) shows the distance to the
respective front vehicle.
3.2 Testing and Validating 28
case. Therefore the verification of the working communication is representative for
all test cases and it is not considered in the remaining test cases, assuming it works
properly.
Regarding the mobility aspects, in Figure 3.3 the results of test case 0.2 are
depicted. As shown in Figure 3.3a the speed of all 7 vehicles of the platoon is as
expected constantly at 22.22 m/s, keeping the inter-vehicle distance of 19.77 m as
shown in Figure 3.3b.
3.2.2 Test Cases: Acceleration/Deceleration
For testing accelerating and decelerating during platooning the test cases 1.2, 1.3,
2.2, 2.3 and 5 were chosen. Test cases 1.2 and 2.2 as well as 1.3 and 2.3 describe
the same scenario, which differs only in the number of brands that are part of
the platoon. In the cases 1.2 and 2.2 the leader of the platoon decelerates from
22.22 m/s to 16.67 m/s and in the cases 2.2 and 2.3 the leader accelerates from
16.67 m/s back to 22.22 m/s. Test case 5 however is defined as the leader of the
platoon decelerating from 22.22 m/s to 6.94 m/s and then accelerating back to
22.22 m/s. Because test case 5 turned out to be a more interesting case to look at,
we additionally implemented it for the Mono-brand and Three-brand testing. In the
following we will look at its results for the Mono-brand testing, which can be seen
in Figure 3.4. The description of test case 5 doesn’t define any point in time at what
the deceleration is supposed to start and no amount of time after which the leader of
the platoon is supposed to accelerate again. Therefore we chose appropriate values
and implemented the test case such that the platoon drives at a velocity of 22.22
m/s until it starts its deceleration after 50 seconds. After another 50 seconds the
leader starts to accelerate again to get back to its original velocity of 22.22 m/s.
For a better evaluation of the graphs these time points, as well as the target speed
and distance of the vehicles, were marked with a dotted line in the graphs. These
target values for speed are 22.22 m/s and 6.94 m/s and for distance are 19.77 m
and 7.56 m. Figure 3.4a and Figure 3.4b respectively show these results. Here we
can see that it took approximately 15 seconds to get from 22.22 m/s to 6.94 m/s.
Looking at the leader after the deceleration process in Figure 3.4a, the speed is 0.1
m/s below the target speed and at the end of the acceleration process it is exceeding
the target speed by 0.9 m/s before it gets corrected. Compared to the other vehicles
regulating their speed perfectly, this is a noticeable behavior. It can be explained by
the fact, that the leader is using an ACC whereas the following vehicles are all using
CACCs. The control algorithm of the controllers in general computes the control
input, i.e., the acceleration of the vehicle, based among other on the target speed.
The ACC does not regulate without errors, which is why we have these outliers.
3.2 Testing and Validating 29
(a) speed
(b) distance
(c) acceleration
Figure 3.4
– Vehicle dynamics of test case 5 for Mono-brand testing (Accelera-
tion/Deceleration). Plot (a) shows the speed of each vehicle; plot (b) shows
the distance to the respective front vehicle; plot (c) shows the acceleration of
each vehicle.
3.2 Testing and Validating 30
Doing multiple tests with a platoon consisting only of the leader, the same behavior
can be observed. Therefore we can assume that it is due to the controller.
3.2.3 Test Cases: Emergency Brake
The test cases 1.7, 2.12 and 7 are describing an emergency brake for each testing
level. They are defined as a platoon which drives at a speed of 22.22 m/s, where
the leader of the platoon performs an emergency brake. The other vehicles of the
platoon follow that behavior and perform an emergency brake as well until every
vehicle stands still (0 m/s). The braking acceleration is defined as
5
m/s2
. These
test cases got implemented as defined, except of the acceleration value. The defined
acceleration of
5
m/s2
is a better value than the default truck value for what reason
we used the default. As mentioned in Section 3.2.1 we set the desired distance at
standstill to 2 meters, for what reason we expect a distance at standstill of 2 meters
also after an emergency bake and therefore no accidents.
Figure 3.5 shows the results of test case 1.7 in three different graphs. Again
we marked the point in time, where the leader of the platoon starts the emergency
brake with a dotted line at second 50 after simulation start. First of all the test case
can be classified as successful. Every vehicle comes to a stop (see Figure 3.5a) with
a distance at standstill of 2 meters (see Figure 3.5b) and no accidents occur. The
emergency brake itself is performed within approximately 20 seconds. Looking at
Figure 3.5c between second 58 and second 65 every vehicle, except of the leader of
the platoon, is again accelerating after the emergency brake was performed. This
behavior can be explained by the desired distance at standstill of the controller. After
performing an emergency brake the inter-vehicle distance is greater than 2 meters
for what reason after the vehicles have come to a stop they accelerate again to reach
their desired distance at standstill of 2 meter.
In conclusion the testing and validation has proven, that the communication
between the vehicles is working as defined by the proposed communication protocol.
All PCMs are getting send and received as they are supposed to be and the mobility
of the platoon in different scenarios is working as well. The behavior of speed,
distance and acceleration is as expected and no accidents occur during the emergency
scenarios. It is important to say that in some test cases we could see a noticeable
behavior of the controller, which is due to the CACC and ACC controller we chose.
With different versions of the controllers a different mobility behavior could occur.
With these results, we will now proceed with the evaluation.
3.2 Testing and Validating 31
(a) speed
(b) distance
(c) acceleration
Figure 3.5
– Vehicle dynamics of test case 1.7 (Emergency Brake). Plot (a)
shows the speed of each vehicle; plot (b) shows the distance to the respective
front vehicle; plot (c) shows the acceleration of each vehicle.
Chapter 4
Evaluation
The main goal of this chapter is to evaluate the proposed communication protocol
and to gain insights in how well the communication performs in different scenarios.
As mentioned before the focus of our analysis will be on regular operation leaving
other aspects defined by the protocol, e.g., security and maneuvers out of scope.
First, we will describe a general simulation setup, which is used for all following
scenarios (Section 4.1), followed by a description of the used metrics (Section 4.2).
We will then go through the different scenarios, first looking at scenarios regarding
the network layer and application layer performance (Section 4.3) and second at
scenarios regarding the impact of communication on the CACC performance (Section
4.4), finished by a discussion (Section 4.5).
4.1 Simulation Setup
All of the following scenarios take place on a highway with four lanes. The duration
of the simulations is 90 seconds, in which the vehicles are driving straight ahead the
entire time. Since we only look at scenarios for the PLATOON mode and as mentioned
in Section 3.1.2 CAMs as well as DENMs are transmitted on a separate channel, it
won’t be necessary to add additional road traffic. We are using a warm-up period of
30 seconds to not include interfering factors at the beginning of the scenarios, that
occur due to possible deviations during the spawning process. In each scenario we
are doing 30 simulation runs to obtain statistical confidence for the results. These
are done with the same parameters but different random number seeds. The most
relevant network and road traffic simulation parameters are summed up in Table
4.1.
32
4.2 Evaluation Metrics 33
Parameter Value
Path loss model Free space (↵=2.0)
PHY/MAC model IEEE 802.11p/1609.4 single channel
Frequency 5.89 GHz (CCH)
Bitrate 6 Mbit/s
Access category AC_VO
Transmit power 200 mW
Sensitivity -94 dBm
Noise floor -95 dBm
CCA-threshold -65 dBm
PCM frequency 20 Hz
Number of lanes 4
Number of trucks 7, 21, 42 and 63
Platoon size 7
Truck length 7.1 m
Intra-platoon distance 19.78 m
Inter-platoon distance 21.78 m
Leader’s average speed 22.22 m/s
Max acceleration 1.3 m/s2
Max deceleration 4 m/s2
Oscillation frequency (sinus. scenario) 0.1 Hz
Oscillation amplitude (sinus. scenario) 1.39 m/s
ACC headway time h0.89 s
CACC headway time h0.8 s
CACC kp0.2
CACC kd0.7
CACC actuation lag ⌧0.5 s
CACC desired distance at standstill ri2m
Simulation time 90 s
Warm-up period 30 s
Repetitions/Number of seeds 30
Table 4.1 – Network and road traffic simulation parameters.
4.2 Evaluation Metrics
With regard to getting a holistic insight on the performance of the communication
and the impact of the communication on the CACC performance we chose the
following metrics:
•
Channel busy ratio (CBR): The CBR is a value between zero and one repre-
senting the fraction of time that a single radio channel is declared busy with
transmissions by the physical layer with respect to a given time interval. In
the simulation each vehicle determines the CBR for time intervals of 10 ms.
This resolution is sufficient to detect the PCMs that are sent every 50 ms.
4.2 Evaluation Metrics 34
•
Latency: An important metric to evaluate the communication quality is the
latency. We measure the time between the moment the message gets created
and send and the moment it gets received and encapsulated. Messages which
are not arriving are not getting recorded at this point.
•
PCM-loss ratio: As a reliability metric for the communication we chose the
PCM-loss ratio. Over a recorded simulation time of 60 seconds each vehicle
sends 1200 PCMs, meaning that a vehicle should receive in average 7200
PCMs of other members of its platoon. For the calculation of the PCM-loss
ratio we count the number of sent PCMs as well as the number of the received
ones. Afterwards, we compute the proportion of lost PCMs for each vehicle
within a platoon. Therefore we get one representative value for each vehicle
per seed. To aggregate these values we took the arithmetic mean value.
•
Inter-message delay: For each vehicle we record the timestamps when a PCM
from within the platoon is received. This enables us to determine, how long it
has been since the last message arrived. By doing that we can see for how long
in a row the controller does not get any information from, e.g., the leader.
•
Safe time ratio: The safe time ratio
rsafe
is an application layer metric developed
by [40]measuring the amount of time a vehicle is in a safe state depending
on the delay requirement req of the controller. It is defined as
rsafe =
Pds2Dsafe ds
Pd2Dd(4.1)
where D is the set of all inter-message delays collected by a vehicle.
Dsafe
is
the subset of D satisfying the delay requirement defined as
Dsafe ={d:d2D^dreq +}(4.2)
req
is the maximum tolerable delay and
is a small grace period that accounts
for uncertainties like MAC layer backoffs. As an example, if all delays in D
are 200 ms long and the delay requirement
req
is 300 ms, the resulting safe
time ratio would be
rsafe
=1, meaning that all information was received in
time. They consider the safe time ratio for leader as well as preceding vehicle
messages.
•
Error: The error is intended to show deviations in the mobility behavior. It is
computed by comparing separately each vehicle of a platoon with the vehicles
of the reference platoon at the same position. We calculate for each timestamp
the absolute difference in speed and then aggregate these errors over all 30
simulation runs and every timestamp by calculating the arithmetic mean.
4.3 Network Performance 35
•
Inter-vehicle gap: As a road safety metric, we chose the inter-vehicle gap. For
the evaluation we record the minimum inter-vehicle gap among any pair of
consecutive vehicles.
4.3 Network Performance
In this section we want to analyze the communication of the proposed protocol
looking at the network layer and the application layer performance. Therefore we are
looking at a scenario with one platoon first to evaluate how the network is behaving.
Afterwards, in Section 4.3.2, the goal is to understand the characteristics and the
behavior of the protocol and network in a more stressful condition. Therefore we
add more platoons to the highway, looking at scenarios with three, six, and nine
platoons. By using a dedicated platooning channel, as defined by the protocol, we
can ease the interpretation of the results. We analyze the scenarios considering the
network metrics: CBR, latency, PCM-loss ratio, inter-message delay and the safe
time ratio.
4.3.1 Scenario: One Platoon
In the first scenario we implemented, similar to Section 3.2.1, a Steady State Pla-
tooning scenario with one platoon. While doing that we are looking more closely
at the communication during regular platooning. Here, we maintain a constant
speed to focus on network analysis only. With one platoon we have seven vehicles
transmitting their PCMs every 50 ms on the channel. Looking at the CBR first, we
have a channel load span from 0 %, in the best case, to 33.61 % in the worst case,
with a median of 5.6 %. These results are depicted in Figure 4.1.
As mentioned in Section 3.1.2 in REQ002 the ENSEMBLE project does not
implement DCC for now, because they assume that the CBR values will be too low
to activate any DCC algorithm. We want to look into this statement by comparing
our CBR results with the default threshold values of the DCC given in [25]. As
defined in Section 2.1.4 there are three different states between which the state
machine is switching, RELAXED, ACTIVE and RESTRICTIVE. According to [25]the
default threshold values for G5CC, i.e. CCH, as well as G5SC, i.e. SCH, are defined
differently, as shown in Table 4.2. The ENSEMBLE project so far only proposed SCH1
RELAXED ACTIVE RESTRICTIVE
G5CC 0 - 15 % 15 - 40 % 40% or higher
G5SC 0 - 20 % 20 - 50 % 50% or higher
Table 4.2 – DCC thresholds of the state machine according to [25].
4.3 Network Performance 36
Figure 4.1
– eCDF showing the CBR results of each scenario, including the
DCC thresholds dividing the graph into the states RELAXED, ACTIVE, and
RESTRICTIVE.
for transmitting PCMs, while CAMs as well as DENMs are send on CCH. Therefore
it makes sense to use the threshold values defined for SCH. Additionally, these
threshold values are higher than those for CCH, which raises the possibility that if
SCH thresholds got exceeded, the CCH thresholds would have been exceeded as well.
Even though the ACTIVE state of SCH is subdivided into up to 4 sub states, we will
only consider the threshold values for the three main states, leaving the sub states
out of scope. As shown in Table 4.2, the state machine for G5SC switches to the
RELAXED state for channel loads lower than 20 %, to the ACTIVE state for channel
loads between 20 % and 50 % and to the RESTRICTIVE state for channel loads higher
than 50 %. With respect to the results of the CBR values, we would be in 96.66 % of
the cases in the RELAXED state, and in 3.34 % of the cases switching to the ACTIVE
state. With a maximum of 33.61 % we would not reach the RESTRICTIVE state.
Due to the high transmission power of 200 mW (23 dBm, REQ003) as set by the
proposed communication protocol, every vehicle in the simulation is recording the
same CBR at each timestamp. With a platoon of 7 trucks with a length of 7.1 m and a
distance of 19.78 m between the trucks, we reach a total length of 188.16 m. In the
following scenario with nine platoons, where we have at maximum three platoons
driving behind each other, we reach a total length of 608.04 m. From [47]we know
that with a transmission power of 100 mW (20 dBm) a transmission of nearly 600
m is possible and therefore a transmission with 200 mW over the length of three
4.3 Network Performance 37
consecutive platoons is likely possible. In the simulation this conjecture could be
confirmed by each vehicle measuring the same CBRs, which are then distributed
as shown in Figure 4.1. This means that no PCM is lost due to the transmission
distance and no collisions through hidden terminal problems should appear.
Next to the CBR we recorded the latency of the PCMs, which in 94.5 % of the
cases is at 0.57 ms and in 5.5 % between 0.57 ms and 2.07 ms (see Figure 4.2).
Outliers in the latency with, for example, 2.07 ms are due to the randomly set start
times of the PCM transmissions, which can result in vehicles sending their PCMs
quite close to each other and therefore having an overlay or almost overlay when
sending. As a possible result they spend more time in backoff and, hence, have a
larger latency. However, most latencies are near the average of 0.58 ms and overall
platooning is not effected by the smaller proportion of high latency messages.
As the third metric we consider the PCM-loss ratio, which in 93.33 % of the
vehicles in all 30 simulation runs is 0 %. For the remaining 6.67 % it is between 1.01
% and 2.39 % as depicted in Figure 4.3. The upper 6.67 % of PCM-loss ratios are
on the one side due to signal-to-noise-plus-interference-ratio (SNIR) packet losses,
which are collisions and bit errors, and on the other side due to messages not getting
received because vehicles were sending while receiving, which we will call TXRX
packet losses. These are distributed as shown in Figure 4.4, in which we can see
that the packet loss due to SNIR packet loss is significantly higher than due to TXRX
packet loss. As a result of the high transmission power the PCM-loss is approximately
Figure 4.2 – eCDF showing the PCM latency results of each scenario.
4.3 Network Performance 38
Figure 4.3 – eCDF showing the PCM-loss ratio results of each scenario.
equally distributed over the vehicles, meaning that there are no positions within
a scenario with multiple platoons where the PCM-loss is significantly higher. In
general, the PCM-loss ratio is for the most part at zero and the remaining cases still
have a low PCM-loss ratio, so there are no effects on the platooning.
4.3.2 Scenario: Three, six, and nine Platoons
After looking at the network performance during regular platooning with one platoon,
we want to evaluate the behavior of the protocol and network in a more stressful
condition. For this purpose we add more platoons to the highway, creating scenarios
with three, six, and nine platoons, which results in a density of 21, 41, and 63
vehicles. The goal of this configuration is to simulate the most common realistic
scenarios on highways with up to 3 lanes for each direction and also worst case
scenarios to push the protocol’s limits. By doing that no requirements of the proposed
communication protocol are getting violated.
As a result the CBR, as depicted in Figure 4.1, is increasing with the density of
the scenarios. Compared to one platoon with a channel load being at 0 % in 18
% of the cases, with three platoons driving next to each other, the CBR is already
starting with a channel load of 5.6 %, having its median at 22.4 %, and a maximum
at 50.41 % . When the amount of platoons on the highway is doubled from three
to six platoons, having two rows of three platoons driving next to each other, the
minimum CBR is 16.8 %, its median is at 45.68 %, and the maximum at 82.18 %.
4.3 Network Performance 39
Figure 4.4
– Plot showing the ratio of SNIR packet loss and TXRX packet loss
within the PCM-loss ratio for each scenario.
As the scenario with the highest density we have nine platoons, where three rows of
three platoons driving next to each other. These result in the highest channel load,
starting at 24.67% and going up to 83.93 %.
With respect to the DCC and considering three platoons, we would be in the
RELAXED state in 36.75 % of the cases, in the ACTIVE state in 62.66 % of the
cases, and with a maximum channel load of 50.41 % in 0.59 % of the cases in the
RESTRICTIVE state. Looking at six platoons, we already have a CBR of 16.8% as the
minimum and, thus, are in 0.83 % of the cases in the RELAXED state. In 58.87 % of
the time we are in the ACTIVE state and in 40.3 % in the RESTRICTIVE state. The
channel load of nine platoons is even higher, starting with a minimum of already
24.67 % and, therefore, is never in the RELAXED state. In 9.55 % of the cases we
are in the ACTIVE state and in 90.45 % of the cases in the RESTRICTIVE state.
Having a higher channel load, the latency of the PCMs increases. Instead of
a latency of at most 0.57 ms in 94.5 % of the cases, adding two more platoons,
as shown in Figure 4.2, lowers that value to 74.8 % of the cases. This value goes
further down with an increasing amount of platoons on the highway. Hence, we
have a latency of 0.57 ms in the six platoons scenario in 47.7 % and in the nine
platoons scenario only in 25.57 % of the time. Looking at three platoons, in 20.2 %
the PCM latency is between 0.57 ms and 1.31 ms and the upper 5 % are between
1.31 ms and the maximum latency of 3.96 ms. With six platoons in 47.3 % the PCM
latency is between 0.57 ms and 2.24 ms and the upper 5 % are between 2.24 ms
4.3 Network Performance 40
and the maximum latency of 6.22 ms. Due to the fact that nine platoons created the
highest channel load, we are having the highest PCM latency as well. Therefore in
69.43 % the PCM latency is between 0.57 ms and 3.65 ms and the upper 5 % are
between 3.65 ms and the maximum latency of 10.11 ms. As we will see in Section
4.4 missing PCMs and therefore an inter-vehicle delay of 100 ms or higher does not
have a significant influence on the mobility. Therefore if the PCM is received with a
latency of over 10 ms in the worst case scenario, this is a small value compared to
the larger inter-message delays, when PCMs are lost.
With regard to the PCM-loss ratio a similar behavior can be seen in Figure 4.3.
In general, the higher the number of platoons the higher the PCM-loss ratio. As a
result of one platoon we had a PCM-loss ratio of 0 % in 93.33 % of the cases. With
three platoons this value decreases to 52.86 % of the cases. The 95 % quantile is
at 5.86 % and the last 5 % of the distribution rise up to 14.93 %. Considering six
platoons, the PCM-loss ratio is in 10.16 % of the cases at 0 %. The 95 % quantile is at
8.61 % and the upper 5 % are between 9.13 % and the maximum of 33.61 %. With
nine platoons, the PCM-loss ratio starts at 0.07 %, has its 95 % quantile at 15.82
% and the maximum at 31.6 % . These packet losses are again due to SNIR packet
losses and TXRX packet losses, whose distribution within the PCM-loss is shown in
Figure 4.4. Here we can observe that the distribution with the growing density of
the scenario is changing to an increase in SNIR packet loss and decrease in TXRX
packet loss. Therefore we can say that with a higher channel load a larger share
of the PCM-loss is due to SNIR packet losses, having relatively more bit errors and
collisions appearing. To further evaluate the PCM-loss ratio we are going to look at
the resulting inter-message delay for the highest density scenario. The controller we
are using, as defined in Section 2.1.2, exploits data from the leader of the platoon
and the vehicle driving immediately in front. Therefore missed or omitted messages
by them can be harmful for the platooning application. We recorded the amount of
missing messages of the leader and front vehicle, to be able to see for how long the
controllers are actually staying without information and how much of the PCM-loss
is a loss of leader and of the front vehicle messages. For that reason the metric is
split between the messages of the leader of the platoon and the messages of the
vehicle driving directly in front. The results are shown in Figure 4.5a for the leader
messages and in Figure 4.5b for the messages of the vehicle in front. They show
the distribution of how long vehicles didn’t receive a PCM from the leader or the
vehicle immediately in front, respectively. As we can see the PCMs from the leader
and vehicle in front were received after 50 ms in 91.28 % and 95.41 % of the cases,
respectively, which is the time interval defined by the proposed communication
protocol. The remaining PCMs were received after more than 50 ms in 8.72 % and
4.59 %, respectively. The PCM-loss from the leader or the vehicle immediately in
front is not necessarily happening at the same time, except for the second vehicle of
4.3 Network Performance 41
(a) inter-message delay (leader) (b) inter-message delay (front)
Figure 4.5
– Horizontal bar plot showing the the inter-message delay for the
leader messages and for the messages of the vehicle immediately in front of
the scenario with the highest density (nine platoons).
a platoon, which ensures that the controller still gets information, even though a
larger inter-message delay occurs. In Section 4.4 we will further evaluate the impact
a higher inter-message delay can have on the platooning application.
To understand the effectiveness of the protocol from the application layer perspec-
tive, we want to use the application layer metric by [40], called safe time ratio
rsafe
.
Therefore we will use the results of the inter-message delay and choose
=10
ms
,
i.e., the CACC controller sampling time [12],[33]. The safe time ratio
rsafe
measures
the amount of time a vehicle is in a safe state, meaning that their requirements of
how often PCMs are received are fulfilled. The results of the leader and the vehicle
in front messages are depicted in Figure 4.6. These show the safe time ratio with
respect to the delay requirement given by a controller for each scenario (one, three,
six, and nine platoons). Considering the scenario with the highest density, having a
delay requirement of, e.g., 50 ms, the proposed communication protocol ensures
that vehicles are in a safe state 82.5 % of the time regarding the leader messages.
For a delay requirement of 100 ms and 150 ms the safe time ratio is at 95.57 %
and 98.73 %, respectively. All safe time ratios of higher delay requirements are
4.3 Network Performance 42
approximately or equal to 1. Considering the messages of the vehicle immediately in
front vehicles are in a safe state 90.64 % of the time and for a delay requirement of
100 ms as well as 150 ms the safe time ratio is at 98.35 % and 99.58 %, respectively.
In the scenarios with less platoons, the protocol manages to deliver the leader and
front vehicle messages even more reliable.
4.3 Network Performance 43
(a) leader messages
(b) front messages
Figure 4.6
– Safe time ratios for both leader and front messages of all four
scenarios with one, three, six, and nine platoons.
4.4 Impact of Communication on CACC Performance 44
4.4 Impact of Communication on CACC Performance
In the following sections we want to evaluate the impact of the communication
designed by the proposed communication protocol on the CACC performance and
therefore on the mobility. In principle, an important aspect in traffic is road safety.
When a new technology is introduced, it has to be ensured that even under worst case
conditions a certain level of safety is guaranteed. As shown in the previous section
PCM-loss ratios of over 30 % were observed, potentially leading to situations in
which the controller doesn’t get any information. In that case CACC would perform
a blind control action, i.e., assume that the input variables are unchanged. This
could result in instabilities or crashes. Hence, we need to evaluate if road safety can
be ensured under such conditions.
4.4.1 Scenario: Sinusoidal
We implemented a sinusoidal scenario for nine platoons with the objective to inves-
tigate, if the higher load on the channel and, associated with it, the higher PCM-loss
has any effects on the mobility of the vehicles in the platoons.
A sinusoidal scenario is described as a scenario where the leader of a platoon
gets the instructions to alternately accelerate and decelerate by the same value in a
specified period, which creates a sinusoidal input for the controllers of the platoon
members. The reason we chose this kind of scenario is, that because of the repeating
accelerating and decelerating, there are more often changes in the driving behavior
than during regular platooning. A higher number of missing messages could show a
bigger impact on the mobility in a sinusoidal scenario than during regular platooning.
At the same time the response of a controller to a sinusoidal input is a standard
approach to analyze string stability.
In the implemented sinusoidal scenario the platoon is traveling on a highway at
a speed of 22.22 m/s. Since the platoon consists of trucks, which have worse engine
characteristics than, e.g., passenger cars, we implemented a sinusoidal scenario
adjusted to these values. Therefore the leaders speed follows a sinusoidal disturbance
profile with a frequency of 0.1 Hz and an amplitude of 1.39 m/s, which the followers
will try to adapt. A frequency of 0.1 Hz gives the vehicles enough time to reach
the speed goal of 23.61 m/s or 20.83 m/s, respectively. Additionally this goal can
be reached without using the full acceleration power of 1.3
m/s2
the entire time,
but with 0.86
m/s2
. These results are depicted in Figure 4.7. They show the speed,
distance, and acceleration of the sinusoidal scenario with one platoon, which will be
used as a point of comparison. With respect to the string stability, as shown in Figure
4.7a, the oscillation of the speed between the first and second vehicle is attenuated
by the following vehicles of the platoon. Therefore the controller is string stable.
4.4 Impact of Communication on CACC Performance 45
(a) speed
(b) distance
(c) acceleration
Figure 4.7
– Vehicle dynamics of the sinusoidal scenario with one platoon.
Plot (a) shows the speed of each vehicle; plot (b) shows the distance to the
respective front vehicle; plot (c) shows the acceleration of each vehicle.
4.4 Impact of Communication on CACC Performance 46
To be able to evaluate the mobility behavior in a sinusoidal scenario under a high
channel load we need to look at the mobility behavior under normal conditions as a
reference. Therefore we implemented the sinusoidal scenario for one platoon, as
well. Now, we need to compare each platoon to the reference platoon in the following
way. We compare the vehicles within the platoon separately and for that chose the
vehicle in the reference platoon at the same position. In this comparison we first
calculate for each timestamp the absolute difference in speed and then aggregate
these errors over all 30 simulation runs and every timestamp by calculating the
arithmetic mean. Overall, the errors are so small, that there is no significant impact
on the mobility. The results from the platoon with the highest errors, together with
the corresponding relative errors, are shown in Table 4.3. The low error values
can be explained due to inter-message delays of leader and front vehicles being not
necessarily synchronous, which means that the controller still receives information.
4.4.2 Scenario: Emergency Brake
To gain more insights in the possible impact of communication on the CACC per-
formance we implemented an emergency brake scenario with nine platoons. Again
following the idea, that if it works reliable in the high density scenario, we can
assume it will work in scenarios with a lower density as well. After looking at the
results of the sinusoidal scenario, having a small error value at continuously changing
the driving behavior, an emergency brake at a randomly set timestamp would not
show any impact on the mobility, except when the emergency brake happens at the
exact point in time where the inter-message delay is very high. This leads us to the
question how harmful the impact of PCM-loss can be to the CACC performance if a
large inter-message delay from the leader and preceding vehicle at the same time
appears. Even though these cases may be rare, they can still occur, which is why
we want to evaluate, what impact they might have on the CACC performance and,
furthermore, possibly on the road safety. To construct this scenario, we picked the
Vehicle ID Absolute Error (m/s) Relative Error (%)
Leader 0.0276 0.12
Vehicle 02 0.0281 0.13
Vehicle 03 0.0283 0.13
Vehicle 04 0.0295 0.13
Vehicle 05 0.0295 0.13
Vehicle 06 0.03 0.14
Vehicle 07 0.03 0.14
Table 4.3 – The average absolute and relative error in speed, with respect to
the reference platoon, of the platoon from the nine platoons scenario with the
highest errors.
4.4 Impact of Communication on CACC Performance 47
second vehicle of a platoon with the highest inter-message delay (300 ms), having
the exact same PCM-loss for the leader as well as the vehicle in front messages.
We implemented the emergency brake scenario to start at the exact point in time
where the 300 ms time interval without any messages starts. The platoons drive
with a cruise velocity of 22.22 m/s and perform a full-stop braking maneuver. As
a reference we considered an emergency brake scenario with one platoon, at a
simulation run with no extraordinary PCM-loss, and recorded the distance to the
preceding vehicle at standstill to compare it. The results regarding the mobility of
this reference scenario are shown in Section 3.2.3 in Figure 3.5. Looking at the
second vehicle of the platoon, after performing the braking maneuver, we can see
that the vehicle comes down to an inter-vehicle distance of 3.08 m and then more
slowly adjusts to a minimum inter-vehicle distance of 2 m, which is the same as
the desired distance at standstill. For the constructed emergency brake with nine
platoons, starting the maneuver at the exact point in time, where an inter-message
delay of 300 ms for the second vehicle of a platoon exists, a minimum inter-vehicle
distance of 1.63 m was recorded.
Even with an PCM-loss of 300 ms no crash occurred and the remaining distance
at standstill of 1.63 m has still an acceptable size. This scenario is a constructed
worst case scenario, unlikely to happen, to demonstrate what kind of impact the
communication can have on the mobility. With the inter-vehicle gap as defined
by the proposed communication protocol the mobility can cope with that kind of
message loss. If one wants to reduce the inter-vehicle distance further, this would
have to be investigated again.
4.5 Discussion 48
4.5 Discussion
When we look at the results of the network layer performance we see, as expected,
that there is a positive correlation between the number of platoons and the recorded
network metrics. Due to more vehicles on the highway sending PCMs, the CBR,
latency as well as the PCM-loss ratio increases. The objective of the DCC is to prevent
the channel from being overloaded and therefore provide congestion control. The
CBR results of the scenario with one platoon show, that the DCC state machine would
have switched to the ACTIVE state and therefore would have started to regulate
the channel. This is something the ENSEMBLE project claims to not happen. They
expect the CBR values to be too low to activate any DCC algorithm. On the other
hand, considering the results of this thesis, we would not reach the RESTRICTIVE
state with one platoon. A realistic real life scenario in the near future could be three
platoons driving on the highway behind each other. With three platoons we would
reach the RESTRICTIVE state in 0.59 % of the cases, which could be avoided by
using DCC.
The vehicles in a platoon only need to share their information with the vehicle
immediately behind. Therefore the leader is the only one needing to reach every
vehicle in the platoon, which raises the question if a transmit power that high is
necessary. A lower transmit power could reduce the interference domain, i.e., avoid
to transmit on the channel from other platoons nearby, which would not have any
use in receiving such data, and, therefore, increase the spatial reuse of the channel. It
can also be differentiated between the transmit power of the leader and the followers,
having the leader use a higher power to reach all vehicles of the platoon. Segata
et. al. [40],[48],[49]investigate the use of adaptive transmit power control in the
context of platooning and show that the use can be very beneficial. This could be
further investigated for the proposed communication protocol.
As mentioned in the first scenario, outliers in the latency can be explained due to
randomly set start times resulting in a possible overlay or almost overlay transmitting
PCMs. This and additionally having a higher density on the highway resulting in
a higher channel load in the other scenarios (three, six, and nine), leads to PCMs
spending more time in backoff and therefore having a larger latency. This could be
avoided by spacing out the start times within the PCM interval of 50 ms. However, the
latency of over 10 ms in the worst case scenario is compared to the lager inter-vehicle
message delays an insignificant small value.
The PCM-loss ratio is due to SNIR and TXRX packet losses, in which especially
the share of SNIR packet loss and, therefore, the bit errors and collisions increases
with an increase of the channel load. To discuss the PCM-loss it must be seen in
context of its effects. Considering the protocol performance from the application
layer perspective, we can see that the proposed protocol manages to deliver leader
4.5 Discussion 49
messages within 150 ms in 98.73 % of the cases and front messages in 99.57 % of the
cases in the scenario with the highest density. In the scenario with one platoon, the
protocol manages to deliver the leader and front vehicle messages even more reliable.
These results additionally provide a key performance indicator to measure how well
the protocol ensures constant information flow, which can be used to determine
whether a different controller would be reliable with the proposed communication
protocol.
To investigate further into the possible impact of the communication on the CACC
performance and therefore on the mobility, the sinusoidal scenario shows that the
resulting errors are too small to have a significant impact on the mobility behavior
of platooning. The emergency scenario, on the other hand, is a forced worst case
scenario, proving that the PCM-loss can have an impact on the mobility. Due to
how the proposed protocol is defined, with an inter-vehicle gap of 0.8 s, this doesn’t
effect the road safety. Apart from the fact that this scenario is unlikely to happen.
The scenarios regarding the impact of communication on the CACC performance
show that there can be an impact in rare worst case scenarios, whereas in general,
the impact is not harmful to platooning. This is shown for the scenarios with the
highest road density and therefore we can conclude that the impact in scenarios
with less density would be even less. Overall, we can conclude that the proposed
communication protocol works reliable.
Chapter 5
Conclusion
In this thesis, we present a first simulative performance analysis of the proposed
communication protocol for multi-brand truck platooning in Europe published by
the ENSEMBLE project. The aim of the thesis is to evaluate the network layer and
application layer performance in a normal as well as in a high density condition.
Additionally, we investigate the impact of the communication on the CACC perfor-
mance and therefore on the mobility aspects. By using the simulation framework
PLEXE we implement the proposed protocol and simulate several scenarios. In order
to analyze them, often used metrics for platooning were chosen.
Our analysis shows that the proposed communication protocol works reliable.
Even with a higher amount of platoons on the highway sending PCMs and therefore
increasing the CBR, latency and PCM-loss ratio, the communication functions reliable.
In the scenario with the highest density the protocol manages to timely deliver, i.e.
150 ms, the for the controller necessary information in 98.73 % of the cases regarding
the leader messages and in 99.58 % of the cases regarding the messages of the vehicle
immediately in front. Considering these results for one platoon, we have an even
more reliable information flow with 100 % of the PCMs being transmitted within 50
ms. These results additionally provide a key performance indicator to measure how
well the protocol ensures constant information flow, which can be used to determine
whether a different controller would be reliable with the proposed communication
protocol. A similar result is also reflected in the scenarios regarding the impact of the
communication on the CACC performance. The sinusoidal scenario performed under
the same level of density shows that the resulting error in the mobility behavior is
too small to have a significant impact on it and the emergency brake scenario shows
that there can be an impact in constructed worst case scenarios, but road safety was
not effected. Therefore, the proposed communication protocol seems to be safe even
with a high density of platoons on the highway.
50
5 Conclusion 51
With respect to the DCC the ENSEMBLE project states that it is applicable, but
would need investigation. The results of this thesis show, that the proposed commu-
nication protocol does work without DCC, even in the most demanding scenario. An
investigation of the proposed communication protocol using DCC as a preventive
measure could still give insights in its impact on the network performance. Addi-
tionally, to be able to better classify the protocol itself, a comparison with other
protocols, similar to what was done in [40],[43], can be made. Furthermore, the
protocol uses a transmit power, which reaches over the length of three platoons
driving behind each other. This raises the question, if a transmit power that high
is necessary. Especially, because research shows, that an adaptive transmit power
control can be very beneficial in the context of platooning. This is an aspect which
could be investigated for further improvements of the proposed communication
protocol.
List of Abbreviations
AC Access Category
ACC Adaptive Cruise Control
ACK Acknowledgement
BTP Basic Transport Protocol
CACC Cooperative Adaptive Cruise Control
CAM Cooperative Awareness Message
CBR Channel Busy Ratio
CCA Clear Channel Assessment
CCH Control Channel
CSMA/CA Carrier Sensing Multiple Access with Collision Avoidance
DCC Decentralized Congestion Control
DENM Decentralized Environmental Notification Message
EC European Commission
ECC Electronic Communications Committee
EDCA Enhanced Distributed Channel Access
GN GeoNetworking
ITS Intelligent Transportation System
IVC Inter-Vehicle Communication
LLC Logical Link Control
OEM Original Equipment Manufacturer
PCM Platoon Control Message
QoS Quality of Service
SCH Service Channel
SCH1 Service Channel 1
SUMO Simulation of Urban MObility
52
List of Figures
2.1 An illustration of the EDCA queue management from [22]....... 7
2.2
Frequencies and maximum transmit power as assigned in Europe
according to ETSI EN 302 663. The spectral masks are not to scale.
[22]........................................ 8
2.3 An excerpt from the ETSI ITS protocol stack from [22].. . . . . . . . . 9
2.4 Project structure of ENSEMBLE. [29].................... 11
2.5
C-ITS protocol stack with standardized protocols and the ENSEMBLE
platooning protocol. [29]........................... 12
2.6
Overview of the platooning procedure from join to leave according to
the proposed communication protocol in [29]............... 13
2.7 Schematic structure of the simulator. [33]................. 16
3.1 Packet encapsulation of the platooning PDU. [29]............ 21
3.2
An excerpt of the vehicle communication showing the sending and
receiving of PCMs. Plot (a) showing the timestamps PCMs send by
each member of the platoon within 100 ms; plot (b) showing the
PCMs received by each member of the platoon within 100 ms. A
missing point indicates that the vehicle self was sending. . . . . . . . . 26
3.3
Vehicle dynamics of test case 0.2 (Steady State Platooning). Plot (a)
shows the speed of each vehicle; plot (b) shows the distance to the
respective front vehicle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4
Vehicle dynamics of test case 5 for Mono-brand testing (Accelera-
tion/Deceleration). Plot (a) shows the speed of each vehicle; plot (b)
shows the distance to the respective front vehicle; plot (c) shows the
acceleration of each vehicle. . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.5
Vehicle dynamics of test case 1.7 (Emergency Brake). Plot (a) shows
the speed of each vehicle; plot (b) shows the distance to the respective
front vehicle; plot (c) shows the acceleration of each vehicle. . . . . . 31
53
List of Figures 54
4.1
eCDF showing the CBR results of each scenario, including the DCC
thresholds dividing the graph into the states RELAXED, ACTIVE, and
RESTRICTIVE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 eCDF showing the PCM latency results of each scenario. . . . . . . . . 37
4.3 eCDF showing the PCM-loss ratio results of each scenario. . . . . . . . 38
4.4
Plot showing the ratio of SNIR packet loss and TXRX packet loss within
the PCM-loss ratio for each scenario. . . . . . . . . . . . . . . . . . . . . 39
4.5
Horizontal bar plot showing the the inter-message delay for the leader
messages and for the messages of the vehicle immediately in front of
the scenario with the highest density (nine platoons). . . . . . . . . . . 41
4.6
Safe time ratios for both leader and front messages of all four scenarios
with one, three, six, and nine platoons. . . . . . . . . . . . . . . . . . . . 43
4.7
Vehicle dynamics of the sinusoidal scenario with one platoon. Plot (a)
shows the speed of each vehicle; plot (b) shows the distance to the
respective front vehicle; plot (c) shows the acceleration of each vehicle.
45
List of Tables
3.1 Values for the computation of the PCM packet size. . . . . . . . . . . . 20
3.2 Selected requirements as defined by [29].................. 22
3.3 Network simulation parameters. . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Default values of the vehicle type truck................... 23
3.5 Test cases selected from the test document D5.1 [46]..........25
4.1 Network and road traffic simulation parameters. . . . . . . . . . . . . . 33
4.2 DCC thresholds of the state machine according to [25].. . . . . . . . . 35
4.3
The average absolute and relative error in speed, with respect to the
reference platoon, of the platoon from the nine platoons scenario
with the highest errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
55
Bibliography
[1]
“Energy, transport and environment statistics – 2020 edition,” European
Commission, Luxembourg City, Luxembourg, Product Code KS-DK-20-001,
Nov. 2020. DOI:10.2785/522192.
[2]
European Automobile Manufacturers’ Association, “Vehicles in use Europe,”
acea.auto, pp. 1–20, Jan. 2021.
[3]
European Commission. (2017). “Hours spent in road congestion annu-
ally,” [Online]. Available:
https://ec.europa.eu/transport/facts-
fundings / scoreboard / compare / energy - union - innovation / road -
congestion_en#2017 (visited on 06/04/2021).
[4]
C. Bergenhem, H. Pettersson, E. Coelingh, C. Englund, S. E. Shladover, and
S. Tsugawa, “Overview of Platooning Systems,” in 19th World Congress on
Intelligent Transport Systems (ITS 2012), Vienna, Austria: Transportation
Research Board, Oct. 2012.
[5]
U. Franke, F. Bottiger, Z. Zomotor, and D. Seeberger, “Truck Platooning in
Mixed Traffic,” in IEEE Intelligent Vehicles Symposium (IV 1995), Detroit, MI:
IEEE, Sep. 1995. DOI:10.1109/ivs.1995.528248.
[6]
S. E. Shladover, C. A. Desoer, J. K. Hedrick, M. Tomizuka, J. Walrand, W.
-
B.
Zhang, D. H. McMahon, H. Peng, S. Sheikholeslam, and N. McKeown, “Auto-
mated Vehicle Control Developments in the PATH Program,” IEEE Transactions
on Vehicular Technology (TVT), vol. 40, no. 1, pp. 114–130, Feb. 1991. DOI:
10.1109/25.69979.
[7]
Kraftfahrt-Bundesamt, “Verkehr in Kilometern - Inländerfahrleistung (VK),”
kba.de, pp. 1–9, 2020.
[8]
A. A. Alam, A. Gattami, and K. H. Johansson, “An Experimental Study on
the Fuel Reduction Potential of Heavy Duty Vehicle Platooning,” in 13th IEEE
International Conference on Intelligent Transportation Systems (ITSC 2010),
Funchal, Portugal: IEEE, Sep. 2010, pp. 306–311. DOI:
10.1109/ITSC.
2010.5625054.
56
Bibliography 57
[9]
X.
-
Y. Lu and S. E. Shladover, “Automated Truck Platoon Control,” University
of California, Berkeley, Berkeley, CA, Research Report UCB -ITS -PRR -2011-
13, Jun. 2011.
[10]
S. Tsugawa, S. Jeschke, and S. E. Shladover, “A Review of Truck Platooning
Projects for Energy Savings,” IEEE Transactions on Intelligent Vehicles (T-IV),
vol. 1, no. 1, pp. 68–77, Mar. 2016. DOI:10.1109/tiv.2016.2577499.
[11]
S. Santini, A. Salvi, A. S. Valente, A. Pescapè, M. Segata, and R. Lo Cigno,
“A Consensus-based Approach for Platooning with Inter-Vehicular Commu-
nications,” in 34th IEEE Conference on Computer Communications (INFO-
COM 2015), Hong Kong, China: IEEE, Apr. 2015, pp. 1158–1166. DOI:
10.1109/INFOCOM.2015.7218490.
[12]
J. Ploeg, B. Scheepers, E. van Nunen, N. van de Wouw, and H. Nijmeijer,
“Design and Experimental Evaluation of Cooperative Adaptive Cruise Control,”
in 14th IEEE International Conference on Intelligent Transportation Systems
(ITSC 2011), Washington, D.C.: IEEE, Oct. 2011, pp. 260–265. DOI:
10.
1109/ITSC.2011.6082981.
[13]
R. Rajamani, Vehicle Dynamics and Control, 2nd ed. Springer, 2012, p. 498.
DOI:10.1007/978-1-4614-1433-9.
[14]
A. Bose and P. Ioannou, “Analysis of Traffic Flow with Mixed Manual and
Intelligent Cruise Control Vehicles: Theory and Experiments,” University of
California, Berkeley, Berkeley, CA, California PATH Research Report UCB-ITS-
PRR-2001-13, Apr. 2001.
[15]
D. Swaroop and J. Hedrick, “String Stability of Interconnected Systems,” IEEE
Transactions on Automatic Control, vol. 41, no. 3, pp. 349–357, Mar. 1996.
[16]
A. Ali, G. Garcia, and P. Martinet, “The Flatbed Platoon Towing Model for Safe
and Dense Platooning on Highways,” IEEE Intelligent Transportation Systems
Magazine, vol. 7, no. 1, pp. 58–68, Jan. 2015. DOI:
10.1109/MITS.2014.
2328670.
[17]
V. Milanés, S. E. Shladover, J. Spring, C. Nowakowski, H. Kawazoe, and M.
Nakamura, “Cooperative Adaptive Cruise Control in Real Traffic Situations,”
IEEE Transactions on Intelligent Transportation Systems (TITS), vol. 15, no. 1,
pp. 296–305, Feb. 2014. DOI:10.1109/TITS.2013.2278494.
[18]
G. J. Naus, R. P. Vugts, J. Ploeg, M. Van de Molengraft, and M. Steinbuch,
“String-stable CACC Design and Experimental Validation: A Frequency-domain
Approach,” IEEE Transactions on Vehicular Technology (TVT), vol. 59, no. 9,
pp. 4268–4279, Nov. 2010. DOI:10.1109/TVT.2010.2076320.
Bibliography 58
[19]
European Telecommunications Standards Institute, “Intelligent Transport
Systems (ITS); European profile standard for the physical and medium access
control layer of Intelligent Transport Systems operating in the 5 GHz frequency
band,” ETSI, ES 202 663 V1.1.0, Nov. 2009.
[20]
IEEE, “Wireless Access in Vehicular Environments,” IEEE, Std 802.11p-2010,
Jul. 2010. DOI:10.1109/IEEESTD.2010.5514475.
[21]
——, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications,” IEEE, Std 802.11-2016, Dec. 2016. DOI:
10.1109/IEEESTD.
2016.7786995.
[22]
C. Sommer and F. Dressler, Vehicular Networking. Cambridge University
Press, 2014. DOI:10.1017/CBO9781107110649.
[23]
ARIB, “700 MHz Band Intelligent Transport Systems,” ARIB, Chiyoda, Japan,
STD T109-v1.3, Jul. 2017.
[24]
IEEE, “IEEE Guide for Wireless Access in Vehicular Environments (WAVE) -
Architecture,” IEEE, Std 1609.0-2013, Mar. 2014. DOI:
10.1109/IEEESTD.
2014.6755433.
[25]
ETSI, “Intelligent Transport Systems (ITS); Decentralized Congestion Control
Mechanisms for Intelligent Transport Systems operating in the 5 GHz range;
Access layer part,” ETSI, TS 102 687 V1.1.1, Jul. 2011.
[26]
——, “Intelligent Transport Systems (ITS); Vehicular Communications; Basic
Set of Applications; Part 2: Specification of Cooperative Awareness Basic
Service,” ETSI, TS 302 637-2 V1.3.1, Sep. 2014.
[27]
European Telecommunications Standards Institute, “Intelligent Transport
Systems (ITS); Harmonized Channel Specifications for Intelligent Transport
Systems operating in the 5 GHz frequency band,” ETSI, TS 102 724 V1.1.1,
Oct. 2012.
[28]
ETSI, “Intelligent Transport Systems (ITS); Vehicular Communications; Basic
Set of Applications; Part 3: Specification of Decentralized Environmental
Notification Basic Service,” ETSI, TR 302 637-3 V1.2.1, Sep. 2014.
[29]
B. Atanassow and K. Sjöberg, “Platooning protocol definition and Communi-
cation strategy,” HORIZON 2020 project ENSEMBLE, Deliverable D2.8, Dec.
2018, pp. 1–55.
[30]
J. Vissers, J. Banspach, V. Liga, T. Tang, H. Nordin, S. Julien, S. Martinez,
and C. Villette, “V1 Platooning use-cases, scenario definition and Platooning
Levels,” HORIZON 2020 project ENSEMBLE, Deliverable D2.2, May 2020,
pp. 1–51.
Bibliography 59
[31]
European Telecommunications Standards Institute, “Intelligent Transport
Systems (ITS); Users and applications requirements; Part 2: Applications and
facilities layer common data dictionary,” ETSI, TS 102 894-2 V1.2.1, Sep.
2014.
[32]
B. Atanassow, P. Sandström, D. Millard, R. Alieiev, S. Gherekhloo, R. Prenzel,
W. Whyte, J. van Doorn, S. Guarnich, and A. Manilla, “Security framework
of platooning,” HORIZON 2020 project ENSEMBLE, Deliverable D2.9, May
2020, pp. 1–30.
[33]
M. Segata, S. Joerer, B. Bloessl, C. Sommer, F. Dressler, and R. Lo Cigno,
“PLEXE: A Platooning Extension for Veins,” in 6th IEEE Vehicular Networking
Conference (VNC 2014), Paderborn, Germany: IEEE, Dec. 2014, pp. 53–60.
DOI:10.1109/VNC.2014.7013309.
[34]
M. Segata, “Platooning in SUMO: An Open Source Implementation,” in SUMO
User Conference 2017, Berlin, Germany: DLR, May 2017, pp. 51–62.
[35]
C. Sommer, R. German, and F. Dressler, “Bidirectionally Coupled Network
and Road Traffic Simulation for Improved IVC Analysis,” IEEE Transactions
on Mobile Computing (TMC), vol. 10, no. 1, pp. 3–15, Jan. 2011. DOI:
10.1109/TMC.2010.133.
[36]
A. Varga, “The OMNeT++ Discrete Event Simulation System,” in European
Simulation Multiconference (ESM 2001), Prague, Czechia, Jun. 2001.
[37]
D. Krajzewicz, G. Hertkorn, C. Rössel, and P. Wagner, “SUMO (Simulation
of Urban MObility); An Open-source Traffic Simulation,” in 4th Middle East
Symposium on Simulation and Modelling (MESM 2002), Sharjah, UAE, Sep.
2002, pp. 183–187.
[38]
IEEE, “IEEE Standard for Wireless Access in Vehicular Environments (WAVE)
- Multi-channel Operation,” IEEE, Std 1609.4-2010, Feb. 2011.
[39]
S. Krauß, “Microscopic Modeling of Traffic Flow: Investigation of Collision
Free Vehicle Dynamics,” PhD Thesis, Mathematical Institute, Köln, Germany,
Apr. 1998.
[40]
M. Segata, B. Bloessl, S. Joerer, C. Sommer, M. Gerla, R. Lo Cigno, and F.
Dressler, “Towards Communication Strategies for Platooning: Simulative and
Experimental Evaluation,” IEEE Transactions on Vehicular Technology (TVT),
vol. 64, no. 12, pp. 5411–5423, Dec. 2015. DOI:
10.1109/TVT.2015.
2489459.
Bibliography 60
[41]
C. Sommer, S. Joerer, M. Segata, O. K. Tonguz, R. Lo Cigno, and F. Dressler,
“How Shadowing Hurts Vehicular Communications and How Dynamic Bea-
coning Can Help,” in 32nd IEEE Conference on Computer Communications
(INFOCOM 2013), Mini-Conference, Turin, Italy: IEEE, Apr. 2013, pp. 110–
114. DOI:10.1109/INFCOM.2013.6566745.
[42]
——, “How Shadowing Hurts Vehicular Communications and How Dynamic
Beaconing Can Help,” IEEE Transactions on Mobile Computing (TMC), vol. 14,
no. 7, pp. 1411–1421, Jul. 2015. DOI:10.1109/TMC.2014.2362752.
[43]
M. Segata, F. Dressler, and R. Lo Cigno, “Jerk Beaconing: A Dynamic Approach
to Platooning,” in 7th IEEE Vehicular Networking Conference (VNC 2015), Kyoto,
Japan: IEEE, Dec. 2015, pp. 135–142. DOI:10.1109/VNC.2015.7385560.
[44]
A. Rayamajhi, Z. A. Biron, R. Merco, P. Pisu, J. M. Westall, and J. Martin, “The
Impact of Dedicated Short Range Communication on Cooperative Adaptive
Cruise Control,” Kansas City, MO, USA, Tech. Rep., May 2018, pp. 1–7. DOI:
10.1109/ICC.2018.8422309.
[45]
C. Lei, E. van Eenennaam, W. Wolterink, G. Karagiannis, G. Heijenk, and
J. Ploeg, “Impact of Packet Loss on CACC String Stability Performance,” in
11th International Conference on Intelligent Transportation Systems Telecom-
munications (ITST 2011), Saint Petersburg, Russia, Aug. 2011, pp. 381–386.
DOI:10.1109/ITST.2011.6060086.
[46]J. Blasco, N. Parera, X. Sellart, H. Nordin, S. Ellwanger, J. Stephane, V. Liga,
D. Willemsen, and J. Allard, “First version Demonstration and test plan,”
HORIZON 2020 project ENSEMBLE, Deliverable D5.1, May 2020, pp. 1–55.
[47]
B. Bloessl and A. O’Driscoll, “A Case for Good Defaults: Pitfalls in VANET
Physical Layer Simulations,” in IFIP Wireless Days (WD 2019), Manchester,
United Kingdom: IEEE, Apr. 2019. DOI:10.1109/WD.2019.8734227.
[48]
M. Segata, B. Bloessl, S. Joerer, C. Sommer, M. Gerla, R. Lo Cigno, and F.
Dressler, “Towards Inter-Vehicle Communication Strategies for Platooning
Support,” in 7th IFIP/IEEE International Workshop on Communication Tech-
nologies for Vehicles (Nets4Cars 2014-Fall), Saint Petersburg, Russia: IEEE,
Oct. 2014, pp. 1–6. DOI:10.1109/Nets4CarsFall.2014.7000903.
[49]
M. Segata, “Safe and Efficient Communication Protocols for Platooning Con-
trol,” PhD Thesis, Institute of Computer Science, Innsbruck, Austria, Feb.
2016.
