Evaluating Message Size of the Collective Perception Message in Real
Live Settings
Michael Kl
¨
oppel-Gersdorf
a
and Thomas Otto
Fraunhofer IVI, Fraunhofer Institute for Transportation and Infrastructure Systems, Dresden, Germany
Keywords:
V2X, IEEE 802.11p, ETSI ITS-G5, Collective Perception Message, Mitigation Strategies, CPM.
Abstract:
The introduction of the Collective Perception Message (CPM) by ETSI offers new possibilities for connected
and automated driving by enabling the exchange of object information between several participants. While
this is surely beneficial, it also leads to higher load on the communication channel, which poses a problem,
especially when considering IEEE 802.11p V2X communication. To overcome this problem, several mitiga-
tion strategies were formulated by ETSI. In the literature, several simulation studies regarding the effect on
the communication can be found. Goal of this paper is to enrich the discussion with measurements from a real
vehicle, showing how many objects might be available for CPM inclusion in the near to mid future.
1 INTRODUCTION
Modern vehicles are equipped with various sensors
(e.g., LIDAR, RADAR, cameras), which are used to
provide safety (e.g., lane keeping assistant) and com-
fort (e.g., Adaptive Cruise Control (ACC)) functions.
Nonetheless, some objects might be invisible to the
existing sensors due to occlusion or insufficient sen-
sor range. Communication offers one possibility to
retrieve the missing information, which can be used to
improve the situational awareness of a given vehicle.
In addition, even older vehicles with unsophisticated
or non-existing sensors can profit from such commu-
nications. To this end, ETSI published a first draft of
the Collective Perception Message (CPM) (ETSI TR
103 562 V2.1.1 (2019-12), 2019), which is used to ex-
change information about detected objects. These ob-
jects are either dynamic (e.g., other vehicles or pedes-
trians) or static. In the latter case, only objects on the
road are of interest.
While the benefit of the CPM is unquestionable,
it also has a drawback in form of increased channel
load. To minimize the impact, ETSI TR 103 562
V2.1.1 (2019-12) (ETSI TR 103 562 V2.1.1 (2019-
12), 2019) proposes an algorithm for the dynamic
generation of CPMs as well as several mitigations for
decreasing the communication load, which are veri-
fied using simulations. A recent study (Delooz et al.,
2020) implies that mitigations are not necessary in
a
https://orcid.org/0000-0001-9382-3062
current scenarios with only a few vehicles equipped,
while the authors of the CPM draft show their effec-
tiveness in a very large scale scenario. In addition,
Thandavarayan et al. (Thandavarayan et al., 2020)
propose a reorganization of contents and the trans-
mission to improve the overall Collective Perception
Service (CPS). All of the aforementioned studies con-
centrate on the communication side of the CPM and
consider perfect, possibly even 360°, sensors and do
not take into account issues, e.g., of occlusion. On the
other hand, Schiegg et al. (Schiegg et al., 2020) con-
sider a sophisticated sensor model in the CPM gener-
ation.
While it is true that the upcoming CPS should be
able to cope with (near to) 100% equipment rate and
future superior sensor setups, we want to enrich the
discussion with a short to mid term perspective. In
order to do so, test drives in different environments
with an experimental vehicle (having a sensor setup
superior to most of todays series vehicles) where con-
ducted and the number of objects to be included in
the CPM are evaluated following different strategies
for inclusion. The test drives were controlled by the
testing framework introduced in the ErVast project,
which is concerned with how advanced driving tech-
nologies, like connected or automated driving, can be
tested during the general inspection and how such test
scenarios can be derived in the first place.
This paper is organized as follows: The next sec-
tion gives a short introduction in the Collective Per-
ception Service (CPS) as outlined in (ETSI TR 103
554
Klöppel-Gersdorf, M. and Otto, T.
Evaluating Message Size of the Collective Perception Message in Real Live Settings.
DOI: 10.5220/0010459005540561
In Proceedings of the 7th International Conference on Vehicle Technology and Intelligent Transpor t Systems (VEHITS 2021), pages 554-561
ISBN: 978-989-758-513-5
Copyright
c
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
Figure 1: Collective Perception Message (CPM) message
format as defined by ETSI (ETSI TR 103 562 V2.1.1 (2019-
12), 2019).
562 V2.1.1 (2019-12), 2019) as well as the proposed
mitigation strategies. Section 3 describes the exper-
imental setup used in this study, whereas Section 4
presents the results. The paper is concluded in the
final section.
2 COLLECTIVE PERCEPTION
MESSAGE (CPM)
The CPM as introduced in (ETSI TR 103 562 V2.1.1
(2019-12), 2019) is still in a draft version. Nonethe-
less, the basic functionality is already defined, with
changes only to be expected for some specific data
fields, e.g., field sizes or encoding. Figure 1 shows a
basic overview over the different containers included
in the CPM. It is notable that vehicles as well as in-
frastructure elements can act as a source. The most
significant difference between these two is the way
the sensors can be described. In addition, only in-
frastructure is allowed to collect Cooperative Aware-
ness Message (CAM) of surrounding vehicles and re-
peat them via CPM. In the following, we will only
consider CPMs generated in the experimental vehicle.
Please note that the stationDataContainer is manda-
tory in this case.
Like the CAM, CPMs are to be generated with a
frequency between 1 10 Hz, where the rules of in-
cluding a sensed object are similar to the CAM up-
date rules, e.g., including an object if it moved more
than 4 meters since it was last included in a CPM.
The maximum number of objects, which could be in-
cluded into one message, are 128, which is the same
as for the maximum number of sensors. The proposed
message format supports segmentation using a more
versatile approach, i.e, having a specific data element
for segmentation, than the simple approach used in
the Map Extended Message (MAPEM) (ETSI TS 103
301 V1.3.1 (2020-02), 2020).
2.1 CPM and ETSI ITS-G5
Communication
As already mentioned above, the introduction of the
CPM will lead to a higher load on the communication
system, especially when considering ETSI ITS-G5.
While a complete simulation is out of the scope of this
paper, we want to give a rough estimate of the impact
of the CPM. For this, we rely on the work of Jacob et
al. (Jacob et al., 2020), who simulated the Packet Re-
ception Ratio (PRR) vs. communication distance of
300 Byte packets (about the size of a CAM sent from
a vehicle) using a highway scenario, IEEE 802.11p
and various load conditions. Their setup consists of
a sending beacon and several probe vehicles located
at defined distances to the beacon as well as different
number of additional communicating vehicles. Then
PRR(ρ,d) =
N
recv
(ρ,d)
N
total
,
where ρ is the density of additional communicating
vehicles, d is the distance of the probe vehicle to the
beacon, N
recv
(ρ,d) is the number of message actu-
ally received from the beacon at distance d, and N
total
is the total number of messages sent by the beacon.
Typically, N
recv
(ρ,d) is smaller than N
total
due to fad-
ing effects and multi-user interference. Take, for ex-
ample, a load of ρ = 20 vehicles/km/lane. Then
the PRR at 100m and 250m for Line of Sight (LoS)
communication, given by (Jacob et al., 2020), is 68%
and 47%, respectively. If one assumes that CPMs are
sent as well (with the same frequency of 10Hz), the
number of messages doubles, which is comparable
to the simulations using ρ = 40 vehicles/km/lane.
This reduces the PRR to 25% and 14%, respectively,
which can be considered as much worse communica-
tion conditions. This simple calculation does not even
Evaluating Message Size of the Collective Perception Message in Real Live Settings
555
take into account that CPMs are usually larger than
the 300 Bytes used in the study, leading to more multi-
user interference and even lower PRR values. Con-
sidering this, the segmentation of messages, which
can happen easily in ETSI ITS-G5 with its Maximum
Transfer Unit (MTU) of just 1,500 Byte, can be seen
as problematic as this would lead to even more pack-
ets being sent. This gives rise to the mitigation tech-
niques described below, which aim at reducing the
amount of CPMs being sent.
2.2 Mitigation Techniques
Although mitigation techniques are not considered in
this work, they are introduced here to show how they
might impact the amount of objects included in the
messages. All mitigation rules rely on the reception
of CPMs from other participants, therefore, only little
impact is to be expected in short to mid term since
equipment rates are expected to be rather low in the
foreseeable future. All in all, six different mitigations
are proposed in (ETSI TR 103 562 V2.1.1 (2019-12),
2019):
Confidence based: If the object confidene in the
ego station is lower than the confidence in one of
the received CPMs then the object is excluded.
Distance based: If the object is already included in
a CPM by another participant, which is near to the
own station, the object is not included again.
Dynamics based: If the dynamic state of the object
has not changed by a certain amount since it was
last received in a CPM (similar to CAM genera-
tion rules) it is not included.
Entropy based: Checks for every communication
partner if the inclusion of the object would im-
prove the respective local tracking. If there is im-
provement for at least one partner, the object is
included, otherwise excluded.
Frequency based: Object is excluded if it appeared
in more than a given threshold of received CPMs.
Self Announcement: Every participant who sends a
CAM is not included as object.
Please note that applying these mitigation rules neces-
sitates to uniquely identify the objects over the several
participating stations. This is not a given since one
station might, for example, detect the front of a truck
whereas the other detects the rear.
1085
865
3630
3310
Rear axle
845
160
64°
62°
790
Figure 2: Positioning of the Ibeo Scala sensors on the ex-
perimental vehicle.
3 EXPERIMENTAL SETUP
Here, we will introduce our experimental vehicle and
describe the test setup used.
3.1 Experimental Vehicle
The test vehicle used in this study is a VW Passat
retrofitted with additional sensors. Its series sensors
consist of radar sensors in the front and rear, ultra
sonic sensors around the whole vehicle, a front facing
camera and additional area view cameras in the side
mirrors. The newly installed sensors consists of six
Ibeo Scala sensors (first generation, see Figure 2 for
their location on the vehicle) and two roof mounted
Velodyne 16 sensors. This vehicle is a twin to the ve-
hicle introduced in (Auerswald et al., 2019).
3.2 Test Setup
As the goal of the study is to get an impression about
the current state, no new sensor fusion algorithms
were implemented. Rather, data and algorithms al-
ready existing in the automotive domain were used.
This excludes using the Velodyne sensors as they
only deliver point cloud data and additional process-
ing would be required. Besides, the authors do not
see roof mounted sensors in mainstream automotive
design, at least for the near future. In contrast, the
Ibeo Scala sensors deliver already classified objects.
In addition, these sensors are already utilized in se-
ries vehicles, e.g., some Audis employ a pair of those.
Objects detected by the Scala sensors are queried us-
ing the Scala Udp Based Transport Protocol (Henning
and Kleiser, 2016), whereas objects from the series
sensors are provided via a proprietary CAN connec-
tion supplied by the manufacturer of the experimental
vehicle. The current position is available via CAN as
well. As the generation of the CPM is rather involved
(e.g., for static objects it has to be determined whether
they are on the road), we opted to count the objects
detected by the sensors, with one caveat mentioned
VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems
556
below, and do not carry out any steps of fusion or
the inclusion algorithm presented by ETSI in Figure
D.2 of (ETSI TR 103 562 V2.1.1 (2019-12), 2019).
This is done in order to prevent a benchmark of our
own implementation instead of the capabilities of the
test vehicle. As such, the numbers presented here can
be seen as an upper limit to the objects actually in-
cluded in the CPM. The Scala sensors, in particular,
detect a lot of static objects, like curbs or bushes (see
also Figure 4). As such items do not belong into the
CPM, they have to be detected from the sensor data.
This could, in theory, be done using HD maps to de-
termine the objects’ absolute positions, but since this
would again mean implementing an own algorithm, it
was instead chosen to only include objects explicitly
classified as road users. For example, out of all the
47 objects shown in Figure 4 only one would be re-
ported (the one detecting a parking vehicle). While
this seems very conversative, the authors feel that this
is the better approach instead of littering the channel
with possibly useless data.
SUMO CARLA ...
OpenScenario/
Opendrive
Interpreter
File
Logger
Database
Logger
Local Logger
Virtual
V2X modem
Software-in-the-
Loop
Scenario Execution
Local Logger
V2X modem
Hardware-in-the-
Loop
Scenario Execution
Local Logger
V2X modem
Virtual V2X
modem
802.11p
LTE/5G
C-V2X
Scenario
Control
Monitoring
Scenario
Logger
Figure 3: Testing framework developed in the ErVast
project. The parts utilized in this study are marked with
a red dashed line. Figure adapted from (Kl
¨
oppel-Gersdorf
and Otto, 2020).
The test drives were planned using the ErVast
testing framework shown in Figure 3. While the
framework also allows to test Vehicle-to-Everything
(V2X) communication, here only the scenario plan-
ning and especially logging solutions were employed.
Nonetheless, the full framework can be employed
once the CPM generation is completely set up. The
udp data streams from the sensors as well as CAN
data were logged in the vehicle (called Scenario En-
tity (real) in the figure) using a local logger. After
finishing the scenario, all data was transmitted to the
Central Logging instance for further postprocessing.
This approach allows to replay a certain test drive and
evaluate additional measures as the full sensor log is
available. The postprocessing step mainly consists
of evaluating the performance indicators, i.e., in the
given case the number of detected objects, but also
generates a visual representation of the test drive us-
ing streetscape.gl (Uber ATG and VIS.GL, 2020) as
seen in Figure 4, which allows an easy monitoring
and also facilitates an effective bug fixing.
3.3 Message Size Evaluation
In this part, the storage size requirements of a sin-
gle object inside a CPM are examined. Two differ-
ent scenarios are considered (see Table 1 for a de-
tailed statistic): To get an upper bound it is assumed
in the first scenario (denoted complete) that all op-
tional fields are filled with data. Furthermore, it is
assumed that a maximum of four sensors contribute
to the detection of one object. This is essential, since
the standard allows to specify up to 128 different sen-
sor identifiers, leading to a maximum storage require-
ment of 128 Bytes for the sensor identifier list alone.
For every object up to eight different classifications
plus the corresponding confidences can be given. It is
assumed that all eight classifications are used in this
scenario. In total this leads to a storage requirement
of 61.25 Byte or 490 Bits per object. In the second
Table 1: Size of the PerceivedObjectContainer.
Optional?
Complete
Available
objectId 8 bit x
sensorIdList x 32 bit x
timeOfMeasurement 12 bit x
objectAge x 11 bit x
objectConfidence 7 bit x
xDistance 25 bit x
yDistance 25 bit x
zDistance x 25 bit -
xSpeed 23 bit x
ySpeed 23 bit x
zSpeed x 23 bit -
xAcceleration x 16 bit -
yAcceleration x 16 bit -
zAcceleration x 16 bit -
yawAngle x 19 bit x
planarObjectDimension1 x 17 bit x
planarObjectDimension2 x 17 bit x
verticalObjectDimension x 17 bit -
objectRefPoint 5 bit x
dynamicStatus x 2 bit x
classification x 120 bit 15 bit
matchedPosition x 31 bit -
Total 490 bit 241 bit
Evaluating Message Size of the Collective Perception Message in Real Live Settings
557
Figure 4: Screenshot of the streetscape.gl (Uber ATG and
VIS.GL, 2020) visualization of the parking lot test case.
Orange markers denotes object classified as unknown large
objects, whereas yellow markers denote unknown small ob-
jects. The single cyan marker directly above the vehicle
denotes a correctly detected parking vehicle. Most of the
unknown objects either belong to building walls, bushes,
trees, or the curb.
scenario (denoted available), only the fields actually
available in the given test vehicle are considered. As
can be seen from Table 1, only some of the optional
fields can actually be filled. Also, since the current
sensor setup returns only one single object class, the
classification data field is smaller than in the complete
case. This results in a storage requirement of 30.125
Byte or 241 bit, less than half the requirement of the
complete case. Please note, that Unaligned Packed
Encoding Rules (UPER) are used, i.e., in addition to
the storage requirements for the single fields there is
also overhead for handling, e.g., optional fields and
sequences. Since this overhead changes depending
on the concrete message contents, it was not included
in the above numbers.
4 RESULTS
A total of two test drives were conducted. Where the
first test drive was mainly for bug fixing and evalu-
ation of the sensor performance, the second test was
conducted in real traffic. Figure 5 shows the maxi-
mum distance of the detected objects from the vehicle
for both test scenarios. Whereas the parking lot sce-
nario is rather confined, with typical distances about
20–30m, the more open layout of the public road net-
work can be seen with typical detection ranges of up
to 100m and maximum detection range of over 300m.
4.1 Parking Lot Scenario
The first test drive took place on the 13th of November
2020, 4:30 p.m. in Dresden, Germany, at the parking
lot of our institute. As this was the end of the week,
0 5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0
0 . 0
0 . 1
0 . 2
0 . 3
0 . 4
R e l a t i v e f r e q u e n c y
M a x i m u m d i s t a n c e o f o b j e c t t o t h e v e h i c l e [ m ]
P a r k i n g l o t
U r b a n a r t e r i a l r o a d a n d r e s i d e n t i a l a r e a
Figure 5: A histogram of the maximum distance between
the detected objects and the test vehicles in the two test
scenarios, respectively. It is clearly visible that detection
ranges are higher in the urban arterial road and residential
area case.
0 2 0 4 0 6 0 8 0 1 0 0 1 2 0 1 4 0 1 6 0
0
1
2
3
N u m b e r o f d e t e c t e d o b j e c t s
T e s t d r i v e t i m e [ s ]
Figure 6: Number of suitable objects detected by the test
vehicle during the test drive on the parking lot. Total test
duration is 160s, measures were taken for every 0.1s inter-
val.
the occupancy of the parking lot was rather low and
there was no dynamic activity by other pedestrians or
vehicles. Figure 6 shows the number of objects de-
tected during the 160 seconds of the test drive. As
both the series as well as the additional sensors have
problems classifying parking vehicles as such, only
very few objects were actually detected. With a max-
imum of only three objects detected a mere 184 Byte
would be required in the CPM with a complete con-
tainer and only 91 Byte when considering available
information, much lower than the MTU of 1500 Bytes
in ETSI ITS-G5 communication even when consider-
ing the other necessary containers.
VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems
558
Figure 7: Route of the test drive through residential and urban arterial roads. Total trip length was 7.8 km with a total trip
duration of 18 min.
4.2 Urban Arterial Road and
Residential Area
The second test drive took place on the 18th of De-
cember 2020, 4:30 p.m, also in Dresden, Germany.
While under normal conditions this would be a time
of rush hour, the traffic was massively reduced due to
the COVID-19 pandemia. The test drive can roughly
be seperated into five parts as is visible from Figure 8.
The first 150 seconds are used to get through residen-
tal area to the urban arterial roads. The next segment
contains a drive along Bergstraße, Zellescher Weg,
and Teplitzer Straße (all three of them major urban
arterial roads, all with two lanes per direction) till the
500 seconds mark. This is also visible in the number
of detected objects, which goes up to 29 maximum
during this period. Afterwards, till the mark of 920
seconds, a drive through residential area followed,
which in turn was followed by a drive on Bergstraße
(same as above) for about 80 seconds. The last seg-
ment was the return to the origin, again through resi-
dential area. The complete route is shown in Fig. 7.
There is a clear difference between the number
of objects detected on the urban arterial roads (max-
imum of 29 objects detected) in contrast to the more
quiet residential areas (maximum of 14 detected ob-
jects). Considering the complete perceivedObject-
Containter case, 14 objects, with a total storage re-
quirement of about 858 Bytes, still fit into one CPM,
which is not the case for the 29 detected objects seen
on the urban arterial roads. With a storage require-
ment of about 1777 Bytes, a segmentation of the
CPM is definitely necessary. When only consider-
ing the available object information, storage require-
ments are 422 Bytes (residential area) or 874 Bytes
(urban arterial road), both still fitting into a single
CPM.
4.3 Discussion
The results show that the test vehicle can detect up
to 29 objects at a single time interval. This means
that even for a contemporary vehicle message seg-
mentation might be necessary in the CPM when con-
sidering complete object information and if no other
measures, like mitigation strategies, are taken. What
make things worse is that a need for segmentation ap-
pears in a scenario with a lot of potential communica-
Evaluating Message Size of the Collective Perception Message in Real Live Settings
559
0 2 0 0 4 0 0 6 0 0 8 0 0 1 0 0 0
0
5
1 0
1 5
2 0
2 5
3 0
N u m b e r o f d e t e c t e d o b j e c t s
T e s t d r i v e t i m e [ s ]
r e s i d e n t i a l
r e s i d e n t i a l
r e s i d e n t i a l
u r b a n a r t e r i a l
u r b a n a r t e r i a l
Figure 8: Number of suitable objects detected by the
test vehicle during the test drive on urban arterial roads
(Bergstraße, Zellescher Weg, Teplitzer Straße in Dresden,
Germany) and residential areas. Total test duration is 1150s,
measures were taken for every 0.1s interval.
tion partners, which might themselves detect a similar
amount of objects. This gives rise to the idea to adapt
the CPM generation rules to the current driving en-
vironment, e.g., sending information with 10 Hz on
residential roads and using mitigation techniques on
the larger urban arterial roads as well as on highways.
While this proposal is backed by the initial data, much
more test drives would be required to determine its
actual feasibility. One could also consider if it is use-
ful to use the perceivedObjectContainer to its full ex-
tent allowed by the specification. In particular, giving
only two classification results instead of the allowed
eight would reduce storage requirements in the 29 ob-
jects case by 326 Byte alone, although this is still not
enough to avoid message segmentation. On the other
hand, when only considering information currently
available, all 29 objects can be transmitted in a sin-
gle CPM. On a more general note, inclusion of spe-
cific optional information in the CPM could be made
dependent on the amount of objects sensed by the ve-
hicle. For instance, even when giving complete infor-
mation, about 20 objects (depending on the size of the
other containers) can be included in the CPM without
the need for segmentation. This number increases to
40 objects when considering the information available
at the experimental vehicle. Finally, when sending
only the required data fields, up to 75 objects can be
included.
5 CONCLUSIONS
In this paper, test drives with a real experimental ve-
hicle were conducted to assess the number of objects,
which can be detected by a modern car. Sensors were
chosen such that the equipment of future vehicles (at
least in the near future) could be mimicked. The re-
sults show that even under today’s conditions a seg-
mentation of the CPM might be required.
Future work includes measurements under differ-
ent traffic conditions, e.g., different day times and
street conditions, and on different streets as well as
measurements on highways. Large scale data acqui-
sition, taking into account other probe vehicles with
different sensor setups, is necessary to determine if
the proposed scheme of making the generation rules
dependent on the driving environment is actually fea-
sible. In addition, the derived results can be fed back
into communications network simulations to assess
the necessity of employing CPM mitigation strategies
under the current conditions. This is especially of in-
terest as current research (ETSI TR 103 562 V2.1.1
(2019-12), 2019; Yu, 2020) has shown that the miti-
gation strategies, while reducing channel load, might
also decrease service availability. Finally, the object
fusion algorithm as well as the object choosing al-
gorithm provided by ETSI, which were omitted here,
can be implemented, allowing to generate and directly
evaluate the resulting CPM message size under vari-
ous conditions.
ACKNOWLEDGEMENTS
This research is financially supported by the Ger-
man Federal Ministry of Transport and Digital
Infrastructure (BMVI) under grant numbers FKZ
01MM19003D (ErVast) and co-financed by the Con-
necting Europe, Facility of the European Union (C-
ROADS Urban Nodes). We would like to thank Ina
Partzsch for her valuable suggestions and comments.
REFERENCES
Auerswald, R., Busse, R., Dod, M., Fritzsche, R., Jung-
mann, A., Kl
¨
oppel-Gersdorf, M., Krems, J. F., Lorenz,
S., Schmalfuß, F., Springer, S., and Strobl, S. (2019).
Cooperative driving in mixed traffic with heteroge-
neous communications and cloud infrastructure. In
Proceedings of the 5th International Conference on
Vehicle Technology and Intelligent Transport Sys-
tems - Volume 1: VEHITS,, pages 95–105. INSTICC,
SciTePress.
VEHITS 2021 - 7th International Conference on Vehicle Technology and Intelligent Transport Systems
560
Delooz, Q., Festag, A., and Vinel, A. (2020). Revisiting
message generation strategies for collective percep-
tion in connected and automated driving. In Proceed-
ings of the VEHICULAR 2020 : The Ninth Interna-
tional Conference on Advances in Vehicular Systems,
Technologies and Applications.
ETSI TR 103 562 V2.1.1 (2019-12) (2019). ETSI TR 103
562 V2.1.1 (2019-12) Intelligent Transport Systems
(ITS); Vehicular Communications; Basic Set of Ap-
plications; Analysis of the Collective Perception Ser-
vice (CPS); Release 2. Standard, ETSI.
ETSI TS 103 301 V1.3.1 (2020-02) (2020). ETSI TS 103
301 V1.3.1 (2020-02) Intelligent Transport Systems
(ITS); Vehicular Communications; Basic Set of Ap-
plications; Facilities layer protocols and communica-
tion requirements for infrastructure services . Stan-
dard, ETSI.
Henning, J. and Kleiser, M. (2016). SCALA UDP based
transport protocol SUTP. Confidential.
Jacob, R., Anwar, W., Schwarzenberg, N., Franchi, N., and
Fettweis, G. (2020). System-level performance com-
parison of ieee 802.11p and 802.11bd draft in highway
scenarios. In 2020 27th International Conference on
Telecommunications (ICT), pages 1–6.
Kl
¨
oppel-Gersdorf, M. and Otto, T. (submitted 2020). A
hybrid real and virtual testing framework for v2x ap-
plications. In Donnellan, B., Klein, C., Helfert, M.,
and Gusikhin, O., editors, Smart Cities, Green Tech-
nologies and Intelligent Transport Systems 9th Inter-
national Conference, SMARTGREENS, and 6th Inter-
national Conference, VEHITS 2020, Prague, Czech
Republic, May 2–4, 2020, Revised Selected Papers,
Communications in Computer and Information Sci-
ence. Springer International Publishing.
Schiegg, F. A., Bischoff, D., Krost, J. R., and Llatser, I.
(2020). Analytical performance evaluation of the col-
lective perception service in ieee 802.11p networks. In
2020 IEEE Wireless Communications and Networking
Conference (WCNC), pages 1–6.
Thandavarayan, G., Sepulcre, M., and Gozalvez, J. (2020).
Generation of cooperative perception messages for
connected and automated vehicles. IEEE Transactions
on Vehicular Technology, pages 1–1.
Uber ATG and VIS.GL (2020). AVS project page.
https://avs.auto. Accessed: 2020-12-15.
Yu, C. (2020). Experimental study on redundancy mitiga-
tion techniques for the dissemination of collective per-
ception messages. diploma thesis.
Evaluating Message Size of the Collective Perception Message in Real Live Settings
561