Evaluating Message Size of the Collective Perception Message in Real

Live Settings

Michael Kl

oppel-Gersdorf

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 beneﬁcial, 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 insufﬁcient 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 proﬁt from such commu-

nications. To this end, ETSI published a ﬁrst 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 beneﬁt 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-

ﬁed using simulations. A recent study (Delooz et al.,

2020) implies that mitigations are not necessary in

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 ﬁrst 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

Figure 1: Collective Perception Message (CPM) message

format as deﬁned 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

ﬁnal 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 deﬁned, with

changes only to be expected for some speciﬁc data

ﬁelds, e.g., ﬁeld 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

signiﬁcant 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 speciﬁc 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 deﬁned distances to the beacon as well as different

number of additional communicating vehicles. Then

PRR(ρ,d) =

recv

(ρ,d)

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):

Conﬁdence based: If the object conﬁdene in the

ego station is lower than the conﬁdence 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

retroﬁtted 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 (ﬁrst 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 classiﬁed 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

classiﬁed 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 ﬁgure) using a local logger. After

ﬁnishing 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 ﬁxing.

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 ﬁrst scenario (denoted complete) that all op-

tional ﬁelds are ﬁlled 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 identiﬁers, leading to a maximum storage require-

ment of 128 Bytes for the sensor identiﬁer list alone.

For every object up to eight different classiﬁcations

plus the corresponding conﬁdences can be given. It is

assumed that all eight classiﬁcations 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

objectConﬁdence 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

classiﬁcation 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 classiﬁed 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 ﬁelds actually

available in the given test vehicle are considered. As

can be seen from Table 1, only some of the optional

ﬁelds can actually be ﬁlled. Also, since the current

sensor setup returns only one single object class, the

classiﬁcation data ﬁeld 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 ﬁelds there is

also overhead for handling, e.g., optional ﬁelds 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

ﬁrst test drive was mainly for bug ﬁxing and evalu-

ation of the sensor performance, the second test was

conducted in real trafﬁc. 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 conﬁned, 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 ﬁrst 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

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 trafﬁc was massively reduced due to

the COVID-19 pandemia. The test drive can roughly

be seperated into ﬁve parts as is visible from Figure 8.

The ﬁrst 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 ﬁt 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 deﬁnitely 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 ﬁtting 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

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

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 speciﬁcation. In particular, giving

only two classiﬁcation 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-

ciﬁc 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 ﬁelds, 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 trafﬁc 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 ﬁnancially supported by the Ger-

man Federal Ministry of Transport and Digital

Infrastructure (BMVI) under grant numbers FKZ

01MM19003D (ErVast) and co-ﬁnanced 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 trafﬁc 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. Conﬁdential.

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.

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