Thanks to evolving cooperative V2X (Vehicle-to-Anything) communication, soon trafic participants do not have to use only their own perceptions of the environment to make a certain decision in a trafic situation, but also have the opportunity to use external originated data, which information could be hardly perceived or even totally unperceivable from their perspective. Collective Perception Service (CPS) is a Day 2 V2X service which can be used by an ITS-Station (ITS-S) to share information about its environment with other ITS-Ss by providing data about perceived objects (e.g., vehicles, obstacles, pedestrians) and available free space which can be safely allocated by other ITS-Ss (e.g., in an overtaking maneuver). Such extensive exchange of sensor data representations with growing bandwidth demand will aggravate the problem of the increasing load on the radio channels in future C-ITS usecases. Motivated by this, we modeled CPS in an environment with changing vehicular trafic and communication conditions and examined the perceived Channel Busy Ratio (CBR) in multiple scenarios.
In recent times innovation of connectivity in all domains is continuing at an increasing pace. Information is becoming more reliable and is delivered faster than ever before, helping the IT ecosystem to perform at a similarly increasing speed. The transport industry has shown great interest in harvesting such connectivity-based solutions to deliver better C-ITS services. However, connectivity’s significant role in ITS is to increase safety and eficiency radically. V2X (Vehicle-to-Everything) is a term used for low latency (and usually safety-relevant) information exchange between trafic participants. The concept of avoiding nearly all accidents involving all trafic participants by the use of V2X has been introduced in the early 2000s by the Automotive industry, followed by the founding of the Car2Car Communication Consortium and thereafter by initial cross-OEM pilot projects like CVIS [1], DriveC2X [2] and SimTD [3].
After nearly 20 years of research and validation, currently the so-called Day 1 system is being rolled out in Europe by major OEMs introducing (among other services) Cooperative Awareness (CA) where connected vehicles are made aware of each other to avoid accidents including non-line-of-site (NLOS) situations where classic ADAS systems are not able to help.
The Collective Perception Service (CPS) considered as a Day 2 service is
foreseen as the biggest gamechanger when it comes to assisted and automated driving
systems as it enablers connected cars to not only disseminate their presence (via
Cooperative Awareness) but the presence of all nearby (non-connected) entities
whether it is a vehicle, a cyclist or an animal running across the street. CPS will
digitalize trafic at a very early stage (meaning a meager penetration ratio of
enabled cars). Collective Perception Message (CPM) used by CPS could include and
share prosperous sensor data like position, speed, or dimension and even perceived
objects and free space which describe the environment of the station around. ETSI
ITS is currently standardizing the Collective Perception Message (CPM) under the
Technical Specification number TS 103 324 with an initial Technical Report (TR
103 562) already published [
The message can be used to transmit up to 10 times per second the complete environmental perception of a single vehicle, providing sensor properties and capabilities, a database of identified objects, and occupiable free space within the range of its sensors. Consequently, CPS reduces the uncertainty of an ITS-S about the current environment, therefore supporting autonomous driving in the future.
With the growing penetration of V2X applications and V2X-capable devices,
the load on the used channel will also increase. Frequent exchange of sensor data
representations with higher size demand, like in the case of CPS, will further
aggravate this problem. Therefore, simulation-based realistic modeling and examination
of CPS and relating services is essential for further development of such advanced
V2X solutions. This article introduces our initial simulation results gathered from
Artery-based [
The rest of the paper is organized as follows. First, we give a short overview of the background, focusing on the details of Decentralized Congestion Control (DCC) and CA and CP services. Then we introduce the simulation environment and the implemented scenarios and applied parameters we used in our experiments, followed by the gathered measurement results and their analysis. Finally, we conclude the paper and highlight our future work.
In the ETSI ITS–G5 C–ITS architecture DCC [
In our investigations, we used two reactive implementations of DCC, which means their operations are based on two Finite State Machines (FSM). One is called Fully Meshed, and the other one is called Gradual. Table 1 represent the states of these two FSMs. To each state, a value is assigned, which is the minimum time interval between two message transmissions and generations.
These two implementations also operate quite diferently. The Gradual one switches states step by step, and it uses only the latest value of CBR measurement. However, the Fully Meshed implementation can change rules by skipping one or more (for instance, it can shift Active 1 to Active 3 immediately). Still, it uses more (a) States of Gradulal DCC (b) States of Fully Meshed DCC of the recent measurements to determine the proper state. According to C2C-CC BSP, the chosen implementation for deployments is the Gradual FSM.
Cooperative Awareness (Day 1) and Collective Perception (Day 2) services are periodic type ones; they send messages periodically with a rate between 1 and 10 Hz. Furthermore, these services send messages with significant packet size, so they mean relatively high stress to the used channel. CA Service is used to send information about the originating ITS station like position, heading, speed, or recent position points of the traveled path (path history). The latter is responsible for the highest amount of the allocated message size. Using CP Service, the ITS stations can inform each other about the perceived objects and free spaces that can be allocated by other vehicles. Thus, in general, the messages generated by this service are bigger than CA Messages (CAMs). Still, the message size is highly dependable on the number of perceived objects and the used area containers to encode free space information. For example, there are particular kinds of free space area shapes like circle, rectangle, or radial, which can be used to describe areas in simple ways with a low amount of consumed data. Still, there is the opportunity to use polygon type to cover complex areas, presumably with more bytes of data. CA and CP Services use position, heading, and speed change values to determine whether to generate a message or include a perceived object. In our investigations, we used three kinds of CP Message (CPM) content generation techniques: • Objects and free space radials upon sensor detection: every perceived object included and to each one, a free space radial was assigned to cover available free space with a variable number of small shapes. • Objects upon sensor detection with only one free space radial: every perceived object included, and each CPM contains a free space polygon with 16 vertices representing constant, but slightly high data usage. • Every CPM is 1500 bytes large, which is the MTU size determined by 802.11 standards representing a kind of upper bound of penetration by CP Service in our simulations.
Through the investigations both CA and CP services applied the same generation rules, i.e., with the restrictions of DCC (which can raise the applicable minimum generation rate) and the periodicity rules (messages shall be generated with a rate between 1 and 10 Hz), a message shall be created when the originating ITS station’s position changes with 4 m, heading changes with 4∘ and speed changes with 0.5 m/s.
The simulation environment we used is the Artery Framework [
To reach our goals, we performed several extensions, modifications and
configurations in the existing Artery framework. Thanks to the Artery’s well-designed
architecture and the asn1c compiler [
For simulations, we used the built-in car2car-grid scenario of Artery with our modifications. Each scenario was running for 22 simulation seconds, and the number of the vehicles followed a linear growing pattern from 0 to 90 during the simulation time. The deployment of the cars on the grid happened in pseudo-random positions but in a fixed way determined by an XML file so that the diferences between each scenario shall be independent of this factor.
Each vehicle has two radars that detect in forward and backward directions to
perceive other vehicles in the line of sight. Each sensor was configured to detect
in a radius of 150 meters and field–of–view of 180 degrees thus both sensors
together detected the area in 360 degrees Every further measurement presented in
this document was performed on the same vehicle which was deployed in = 0
and present in during the whole simulation in every examined scenario. Since the
standardization of Collective Perception began in the near past (ETSI TR [
Several other parameters were used to define further elaborated simulation scenarios based on the above general details: • Services running on each vehicle: 1) Only CA service (calibration measurement), 2) Only CP service, 3) Both CA and CP services. • DCC–profile of each service: 1) Both CA and CP are on DP2, 2) CA is on
DP2, CP is on DP3. • DCC Finite State Machine: 1) Fully Meshed, 2) Gradual. • Structure of CPM: 1) One free space radial for each perceived object, 2) One free space polygon with 16 vertices in each CPM, 3) Maximum size messages ( 1500 bytes) Sizes of generated CAMs are between 148 and 350 bytes depending on that a packet contains a LowFrequencyContainer with path points or not. The following key performance indicators were taken into consideration in each scenario to analyze simulation results: • Instantaneous CBR: measured on access layer level; to describe the channel load in relation to simulation time. • number of dropped packages in each DCC queue: to describe packet loss caused by DCC restriction. • number of sent packages on the radio: to describe the number of packets that got on the air interface, which is in connection with the channel load caused by the node where the measurements were made. • number of received erroneous packets: measured on access layer level before any packet was transmitted to upper layers; to describe packet loss caused by channel degradation.
Based on the above-introduced simulation environment and scenarios, we performed multiple simulation runs and examinations. We present the gathered results in subsections below grouped by the applied services.
These cases are for calibration measurements. In scenarios applying only CA service, just two cases can be distinct: using Fully Meshed DCC and using Gradual DCC. However, the results showed marginal diferences to each other: the maximal CBR value did not reach 0.2, and no packets were dropped or received as erroneous.
The CBR values resulted from using Fully Meshed or Gradual DCC are depicted in Fig 2 (legend: FM: Fully Meshed, G: Gradual). The diagrams show that bigger packet sizes resulted in non-marginally higher CBR, which is conspicuous in higher trafic. Furthermore, Fully Meshed implementation led to lower CBR in general, mainly when maximum-sized packets were used. Using Gradual DCC, more packets were sent on radio, and fewer packets were dropped in DCC.
Both services were applied corresponding to C2C-CC BSP [
These scenarios are for presenting the situation when messages of two services with similar generation rules are sent out on the radio interface with equal chances. The diagrams of Fig 4 show the increased CBR values resulted from more actuGenerated CAMs Generated CPMs Dropped in DCC–DP2 (CAM) Dropped in DCC–DP3 (CPM) Sent on radio Received erroneous Generated CAMs Generated CPMs Dropped in DCC Sent on radio Received erroneous ally transmitted CPMs – which are more significant than CAMs in general. In Gradual cases, the fluctuation of CBR is higher than in cases with diferent DCC profiles, and the number of erroneous packets is more prominent, too. Based on our experiences, we can say that Gradual DCC implementation with more transmitted packets consequences much higher amounts of received erroneous packets than Fully Meshed implementation because the latter one holds packets back more drastically, thus in case of full DCC queues drops more packets, resulting in lower CBR values.
Our simulation results are focused on the Channel Busy Ratio (CBR) and showed that the quality of the provided CP service degraded significantly when the two services were used simultaneously on the same channel, therefore motivating deployment eforts of the more sophisticated multichannel V2X solutions. Data-intensive applications should use distinct channels, and each channel – if it is feasible – may have its own DCC.
Developing a version of CP service more accurate to its generation rules declared in its published TR and using MCO implementation features of the newest version of Artery could show further exciting and useful information.
Acknowledgements The authors would like to thank the experts from Commsignia Ltd. and the Department of Networked Systems and Services of BME for their valuable comments and guiding discussions. [1] The Cooperative Vehicle-Infrastructure Systems Project http://www.cvisproject.
org/ [2] The Drive-C2X Project http://www.drive-c2x.eu/ [3] The SimTD Project http://www.simtd.de/