Real-Life Traffic Data Based ITS-G5 Channel Load Simulations of a Major Hungarian C-ITS Deployment Site

Featured Application

The primary objective of introducing the proposed tools and methodology is to enable the accurate and comprehensive simulation of ITS-G5 radio channel load, thereby advancing the field of C-ITS network design and deployment. By leveraging these resources, stakeholders can gain critical insights into the intricate relationship between various C-ITS services, V2X penetration ratios, ITS-G5 radio channels, and network performance. These simulations can then be applied to optimize C-ITS network architecture, identify potential bottlenecks and points of failure, and support strategic decision making. Ultimately, the proposed tools and methodology can serve as a crucial asset for improving the reliability and efficiency of C-ITS networks.

Abstract

Transportation efficiency and safety are crucial development areas nowadays. Cooperative Intelligent Transport Systems (C-ITSs), relying on Vehicle-to-Everything (V2X) communication, are a promising group of technologies and applications aimed at solving several issues related to road safety or efficiency. The C-Roads Platform was brought to life to ensure the cross-border harmonization of C-ITS at a European level, guiding several pilot activities in national deployment projects and providing a harmonized pan-European C-ITS service perspective. Because of the safety relevance of V2X technologies, it is essential to ensure that the crucial parameters of wireless communication are within an acceptable range to serve C-ITS applications appropriately. In this work, we developed a simulation pipeline to evaluate future V2X deployments using the real-world traffic and map data of a C-Roads harmonized major Hungarian C-ITS deployment site. First, we selected three time periods representing different traffic patterns. Then, we reconstructed the flow-based traffic data from the real-world traffic counters for the selected time periods. We developed an approach based on linear equations to perform the conversion. Eventually, we used the real-world data to simulate the effects of various DSRC (ITS-G5-based) C-ITS services and V2X penetration rates on the Channel Busy Ratio (CBR) parameter of the radio access environment.

1. Introduction

Transportation faces various challenges nowadays. There are numerous efforts to enhance traffic safety and efficiency. C-ITS is a key technology in this field that aims to address these challenges. It connects the traffic participants and the infrastructure in a cooperative network. Thanks to the communication, the actors can exchange essential information to realize a wide range of safety improvements, efficiency enhancement, and convenience applications.

The applications are usually categorized into three generations. Day1 applications typically implement cooperative awareness, Day2 broadens the horizon via perception sharing, and Day3 introduces coordinated maneuvering. As of 2023, Day1 use cases are mass-deployed, and Day2 applications are in the final stages of standardization.

Naturally, the C-ITS applications depend on the various network parameters. In the scope of this work, we aim to provide realistic simulation results based on real-world traffic data for different future deployment realizations of Day1 and Day2 applications. We hope this work will support the C-ITS community’s decisions with realistic and accurate data.

The rest of the paper is organized as follows. The background of the article is elaborated in Section 2. Section 3 introduces the applied simulation environment, our proposed extensions, and the used configuration. The details of the traffic modeling follow this in Section 4. The results are collected, introduced, and analyzed in Section 5. Finally, we conclude the paper and highlight our future work.

2. Background

2.1. V2X Use Cases and Literature Review

Multiple surveys focus on the achievable use cases in this domain, as summarized in [1]. In [2], the authors present 5G-V2X use cases and enabling technologies. The authors of [3] collect cooperative automated driving use cases. The authors of [4] introduces an implementation of infrastructure-supported cooperative maneuvers. In [5], the authors survey the scope of V2X testing, while [6,7] analyze the service requirements in this domain.

There are multiple articles covering C-Roads C-ITS deployments in the literature. However, no available documents provide realistic channel utilization simulation results [8,9,10,11]. Currently, the most relevant use cases from the deployment perspective are the so-called Day1 and Day2 use cases. Various aspects of these use cases are examined in the available papers. A list of the most important use cases is provided in

Table 1. C-ITS use cases evolution.

Use Case	Generation	References
Forward collision	Day1, Day2	[12,13,14]
Intersection collision	Day1, Day2	[15,16]
Speed advisory	Day1	[17]
Adverse weather	Day1	[18,19]
Dangerous situation	Day1, Day2	[20,21,22,23]
Special vehicle	Day1	[24,25,26]
Stationary vehicle	Day1	[27]
Green light optimal speed advisory	Day1	[28,29,30]
Red light violation	Day1	[31]
VRU protection	Day2	[32]
Collective perception	Day2	[18,33,34,35,36,37]
Cooperative awareness	Day1	[38,39]
Maneuver Coordination	Day3	[40,41,42]

below.

2.2. The Simulation Context

The first ITS-G5-based C-ITS pilot in Hungary was implemented in 2015 along a 136 km-long stretch of the motorway M1 between Vienna and Budapest. The ITS-G5 technology supports vehicle-to-vehicle, vehicle-to-everything ad hoc communications without prior network set-up used at the dedicated 5.9 GHz frequency bands in Europe (the specified access layer of the communication stack is collectively called ITS-G5). The trial focused on road safety, especially on work zone use cases. Therefore, maintenance vehicles were also equipped with transceivers to act like ad hoc roadside units besides the fixed R-ITS-S stations. They were capable of operating both in connected and in standalone mode. By using an additional switch connected to the installed OBU, the operator can easily generate a DENM message which is broadcasted at the spot directly (standalone mode) or via the central ITS station (connected mode). The C-Roads Platform [43] is considered an adequate instrument for Member States to continue their involvement in the dynamic field of C-ITS and to delve into more detail from a particular road operator perspective. Member States across Europe are installing C-ITS pilot sites needed for the testing and later operation of “Day1” and beyond recommended by the European Commission’s “C-ITS platform”. Therefore, Member States will invest in their infrastructure; OEMs and the industry will use that pilot test infrastructure to test components and services.

As part of C-Roads, Hungarian Public Roads upgraded and extended the 2015 pilot in coverage and functionality. Additional Day1 use cases were introduced with hybrid communication along Motorway M1 (toward Austria) and Motorway M7 (toward Croatia and Slovenia). The provided services/the names of their sub-cases are as follows: IVS-DSLI, IVS-EVFT, IVSDLM, IVS-OSI, HLN-AZ, HLN-TJA, HLN-WCW, HLNTSR, HLN-OR, RWW-LC, RWW-RC, and RWW-RM (as in C-ROADS Harmonized Communication Profiles Rel. 1.6). In addition to core network corridors, special attention was also paid to urban applications: traffic light controllers were improved in the town of Győr to provide Time To Green and Green Light Optimum Speed Advisory (SI-GLOSA/SI-SPTI) information and Intersection Violation Warning (SI-ISVW) at ten neighboring junctions along the main traffic route, where intersection safety services are also available. The pilot sites have been operational since Q1 2021 [44].

Based on the C-Roads Platform results, the parallel CROCODILE project [45] Phase 2 also aimed for new C-ITS investments, mainly focusing on the Budapest Ring Road (expressway M0), implementing a testbed of cooperative ITS functions for the Central Region of Hungary (concerning the plan of the national C-ITS infrastructure). The deployment was started before the C-Roads investments, but the work strongly relied on the outcomes. Therefore, all the installed 26 Road Side Units (RSUs) at 13 locations (see Figure 1 for details) comply with the then-available C-Roads technical specs (”C-ROADS—Harmonized C-ITS Specifications for Europe—Release 1.3”). As a result of the investment, Commsignia ITS-RS4-M transceivers [46] provide ITS-G5 communication links at least every 10 km along the M0 ring road around Budapest (in both directions). The existing roadside stations are to be upgraded according to the newest C-Roads profiles, and RSUs will be available every 5 km of the expressway in the coming development phase.

Despite the tremendous results already collected with the help of the C-Roads Platform, technological innovation still causes plenty of challenges for road operators. It leaves many uncertainties for C-ITS and even more for CCAM (Connected, Cooperative, and Automated Mobility). To tackle the difficulties, Hungarian Public Roads further support connected mobility. The ongoing deployments involving a national C-ITS infrastructure and a planned European C-ITS ecosystem also help this goal by providing more valuable information, best practices, and harmonization guidelines.

An essential part of these C-ITS-related investments in Hungary is connected to the Automated Proving Ground and ZalaZone [47], which is dedicated to genuine public road testing in the town of Zalaegerszeg. The test track is unique because it integrates all the standard driving and driving stability features, a complex research/development framework, and advanced communication infrastructures to create a multi-level system for validating automotive solutions for the CCAM era. Therefore, the proving ground provides dynamics tests for conventional vehicles, but it also allows validation tests for autonomous and electric vehicles. The demand was raised by setting up the test track to enable open road tests (with safety always the first concern). In addition to the testing area of ZalaZone, the planned expressway M76 (between M7 and Zalaegerszeg) will be a part of the testing facility, too. This is the first road section in Hungary that will be constructed by taking the requirements of automotive Tier 1 s and OEMs into account already from the planning phase and aiming at CCAM test opportunities in real traffic conditions. The ongoing C-Roads 2 Hungary project is focusing on this region, too, using synergies with the test facility. The planned Hungarian work program devotes particular attention to creating an urban test environment for autonomous and connected vehicles in the town of Zalaegerszeg, linked to the Automotive Proving Ground Zala (APZ), and building on the experiences of the pilot project in Győr. The deployment will focus on Day1 and Day1.5 C-ITS services with special attention on Vulnerable Road User (VRU) use cases. “ZalaZone” is the greater area that includes the town and the test track that will be ready for autonomous vehicle testing, but there are even more ambitious plans. As part of trilateral multi-level cooperation, Austria, Slovenia, and Hungary plan to implement cross-border test routes [48]. C-Roads 2 Hungary will enhance this effort by implementing C-ITS services in the greater city area and TEN-T corridors (with domestic and cross-border sections).

Supported by the C-Roads Platform results/available deployment details and driven by the above-introduced intertwined C-ITS/CCAM plans of the Hungarian road operator, it became essential to start analyzing the possible limitations of existing infrastructure components and to evaluate potential barriers and challenges to the further growth and advancement of C-ITS solutions available. This work can be considered as the first step of this general effort. We took expressway M0 and its RSU deployment as the C-ITS infrastructure under evaluation: we modeled the traffic of this road segment based on real-life traffic and map data, we modeled the RSU deployment and the V2X network and performed extensive simulations to highlight how the penetration rate of the C-Roads-compatible V2X technology will affect the service scalability in means of the radio channel load from now to the future.

3. The Simulation Environment

3.1. The Simulation Pipeline

In order to perform the necessary simulation steps, we developed a simulation pipeline containing eight main stages. The pipeline is depicted in Figure 2. Some of the stages with non-trivial contributions are elaborated on in the sections below.

• In the traffic data collection stage, we received traffic count data in an hourly resolution from the Hungarian Roads. The data originated from loop detectors which are able to count the passing vehicles. Typically, one loop detector is deployed between each driveway.
• In the traffic data selection stage, we selected traffic scenarios that were considered to represent typical traffic patterns, including, e.g., summer-time low-intensity traffic and school start high-intensity traffic. The selection is elaborated on in Section 4.
• In the traffic data aggregation stage, we calculated the average of the data of the selected road sections in the selected hours. We have also performed some cleaning on the data in this stage.
• In the traffic demand generation stage, we generated the number of entering, leaving, and passing vehicles for each driveway. The method is described in Section 4.
• In the traffic flow generation stage, we generated traffic flows from the previously generated traffic demand values using Algorithm 1.
• In the scenario selection and configuration generation stage, we selected the relevant services and simulation parameters. The configuration is elaborated on in Section 2.
• We used the Artery/OMNeT++ simulator in the supervised simulation stage to model the network and analyze the channel utilization values. The details are described in Section 3.
• We developed data processing scripts to visualize the results in the evaluation stage.

Algorithm 1 The proposed algorithm for flow generation

Require: Demand values to each driveway (D) Ensure: Proper flows (F)           F ← {}           for all d ← D do                    l ← d.next {Node satisfy demand}                   while d.entry ≠ 0 do                              p ← min{d.entry, l.leaving} {Processable demand}                              d.entry ← d.entry—p                              l.leaving ← l.leaving—p                              F ← F ∪ {d, l, p} {Add flow}                              l ← l.next                    end while           end for

3.2. OMNeT++ and Artery-Based Simulation Framework

The Artery/OMNeT++ framework is a state-of-the-art simulation solution supporting V2X communication with real protocol implementation and advanced traffic modeling capabilities. The Artery framework binds and integrates the following main components.

• The OMNeT++ framework: The OMNeT++ [49] is an event-based discrete-time network simulation framework that serves as a basis for the Artery framework. It is responsible for the simulation core of the network simulator. It also helps with many utility commands, like its own configuration file format, the XML parsing utilities, or the capability of defining multiple configurations with variable parameters.
• SUMO: The SUMO [50]—Simulation of Urban Mobility—is a discrete-time microscopic traffic simulation framework. The SUMO framework supports network files imported from real-world maps using OpenStreetMaps. It is easily configurable with various parameters like the dynamics of the vehicles or the number of cars in a flow. The most important configuration options are the used network files and the route files defining the vehicles or vehicle flows in the simulation.
• INET: The INET framework [51] is practically an open-source simulation model library built on top of the OMNeT++ environment. It implements protocols, agents, and other models for researchers and students working with communication networks. It models and implements various Internet-related protocols like IP, UDP, TCP, Wi-Fi, and many others. The Artery framework uses this library for multiple purposes, like the physical layer implementation.
• Veins: Veins [52] is an open-source framework for executing vehicular network simulations. It integrates INET/OMNeT++ (the event-based network simulator with well-detailed protocol models) and SUMO (the road traffic simulator component). Veins also extends these main components to offer a comprehensive suite of models for inter-vehicle communication.
• Vanetza: Vanetza [53] is an ETSI protocol stack library comprising compiled ASN.1 descriptors. It includes various protocols from the ITS transport, network, security, management, and facilities layers. This package was originally designed to operate on the ETSI-standardized ITS-G5 channels in V2X networks using IEEE 802.11p [54], but it can also be combined with other communication technologies.
• Artery: The Artery framework [55] is considered the state-of-the-art V2X simulation solution to evaluate complete C-ITS service infrastructures based on ETSI ITS-G5 protocols like GeoNetworking and Basic Transport Protocol (BTP). Simulated vehicles can be equipped with multiple V2X interfaces to access various possible ITS-G5 services through Artery’s middleware component that also implements common facilities for the C-ITS services. Furthermore, the framework provides a sensor architecture with local and global environment models and a scripting toolset for dynamically evolving scenarios.

3.3. Proposed Extensions to the Artery Framework

• The CPM support: The Collective Perception Message (CPM) models and the related mechanisms were implemented in our previous work [56]. We further extended and updated this model to a newer version based on the available ETSI CPM standardization documents [57,58]. Apart from that, the dynamic behavior of the protocol—CP service—also had to be implemented in the Artery framework since it is not implemented in Vanetza.
• The modeled V-ITS-S nodes: The Vehicle ITS station (VITS-S) nodes included an ITS-G5 interface to send the status information generated by the vehicles. We have modified the model, enabling the used V2X messages to now be either a Cooperative Awareness Message (CAM) [59], CPM, or CAMs and CPMs in the simulation scenarios.
• In order to enhance the interpretability of the measured data, a data-processing pipeline was developed. In the simulation framework, the proper measurement data were logged. After the simulation, the data were converted to CSV format, which was eventually processed by a Python-based process script based on pandas and matplotlib responsible for the visualization.
• Resource management: The simulation was performed with many simulation setups. The simulation was also time and resource-consuming—both RAM and CPU utilization had to be monitored to achieve optimal speed. To manage this kind of issue, a virtualized docker-based simulation environment was developed. Our ultimate goal is to create a Kubernetes-based simulation system with automatic simulation orchestration and intelligent resource estimation heuristics.

3.4. The Simulation Configuration

The simulation had three unbounded variables. One of them was the used service on the ITS-G5 channel. It could be CAM, CPM, or combined CAM and CPM facilities. The V2X protocol stack was implemented in accordance with the standards. The protocol layers included the MAC header, the GeoNet header, and the UPER-encoded facility layer protocol headers as well. The second variable represented the amount of traffic in the simulation. During the traffic data selection, we chose nine different traffic patterns. The selection is elaborated on in detail in Section 4. The last unbounded variable was penetration, which means the share of V2X-equipped vehicles in the overall traffic. These three variables resulted in 297 different simulation configurations. The simulated time was 20 s long, and the simulation covered the expressway M0 C-ITS deployment site of Hungarian Public Roads.

4. Traffic Data

Using a realistic microscopic traffic simulator implies that the expected traffic data format of the traffic simulator is flow-based. Contrary to this, measuring the actual traffic conditions on public roads is implemented in practice typically via traffic counters due to technical and legal reasons. The following section describes how we calculated the flows from the real-world traffic counter measurements, i.e., how we generated the appropriate SUMO models for our simulations.

4.1. Traffic Data Preprocessing

• Traffic data format: The traffic information provided by road operators is usually the number of vehicles crossing the highway at some measurement points. Contrary to this, the traffic simulators expect the traffic given by routes of cars or vehicle flows. Both of these models expect the start and end positions to be provided. This means that we need to transform the measurement data into some form of a flow model.
• Traffic data: In the phase of traffic data collection, we processed the real-life measured data gathered by Hungarian Public Roads. The data included traffic counter information from various sections of the modeled M0 highway with a one-hour resolution. The data covered three weeks from 2019; one represented winter, one represented spring, and one represented autumn. We split the measurement data into different periods in the day to better showcase the relevant traffic patterns. We took the measurements’ average to calculate the traffic’s magnitude in the specific time period. This means that the measured values of the different intervals are scaled to one hour. After that, we selected periods representing the minimum, the maximum, and the average traffic within that specific day. This method also preserved the typical traffic patterns of that period. The traffic patterns among the measurement points are visible in Figure 3. The S and N letters indicate the direction of the lanes—south or north. The numbers on the X-axis identify the measurement points. The number of vehicles passing the measurement point is represented on the Y-axis.

4.2. Traffic Model

In this measurement, we considered a highway scenario where the vehicles were driving on the M0 motorway. SUMO implements a microscopic traffic simulation, meaning that each vehicle’s movement is simulated individually. To model the vehicles’ movements, it was sufficient to specify where the vehicles entered and left the highway. After that, SUMO handled the exact modeling of the movement. Our road model consisted of one highway and highway driveways where the vehicles could enter, leave or pass on the highway (one road for each direction). First, we calculated the entry, exit, and passing traffic at each driveway (we named it traffic demand; see Figure 4). After that, we calculated the flows (practically each vehicle’s start and end points). Eventually, we transformed these data into a format accepted by the traffic simulator. The entry and exit points were mapped with the map topology of the traffic simulator—SUMO—to interpret these points as the starting and ending points of a particular traffic flow. Using this model and the related calculations, we were able to replicate the traffic counter data in the simulation.

4.3. Transform Data into a Traffic Model

The measurement data were first transformed into our traffic model. To do so, first, we collected the driveway points and ordered them based on their position. After that, we calculated the traffic on the different road segments. This means we took the average of the two subsequent road segments if no measurement points were within the examined road segment. We took their average if there were multiple measurement points on a road segment. We kept the result intact if there was precisely one measurement point between two driveways. Using this method, we calculated the amount of traffic on each road segment.

4.4. Obtaining Demand Information

Based on the traffic on each road segment, we had to calculate the entering, leaving, and passing—e, l, and p in the second indices, respectively—traffic on each driveway. We modeled the traffic situation with m driveways, which is one more than the number of measurement points. There are driveways between each measurement point and an entering and a leaving driveway at the end and beginning of the road segment. Thus, we have m + 1 driveways and m measurement points. We formulated the problem using linear equations. The problem was solved for x with an optimizer tool.

The x values represent the number of entering, passing, and leaving vehicles In each intersection, as denoted by its indices, respectively.

The t values on the equation’s right hand represent the number of passing vehicles on the measurement points. This was known based on real-world measurements.

The A matrix on the left-hand side of Equation (1) has three main sections (Figure 5).

The first section represents that the number of entering and passing vehicles after a driveway equals the number of vehicles in the next measurement point. Due to the long sampling period (1 h), the effect of vehicles that are among the measurement points at the end or beginning of the sample period on the simulation result is negligible. The right-hand side of the matrix represents the measured traffic values after the ith driveway. Naturally, on the last measurement point, there are no entering and passing vehicles; thus, the related number on the right hand is 0. The second section represents that the number of leaving and passing vehicles on a driveway equals the number of vehicles on the preceding measurement point. Naturally, on the first measurement point, there are no leaving and passing vehicles; thus, the corresponding number on the right hand is 0.

The third section (last four rows) represents that the first driveway is modeled in a way that it has only leaving vehicles; thus, the number of passing and entering vehicles is 0. The last driveway only has leaving vehicles, so the number of passing and entering vehicles is 0.

$$\left[\begin{array}{ccccc}110& \dots & 000& \dots & 000\\ ⋮& & \ddots & & ⋮\\ 000& \dots & 110& \dots & 000\\ ⋮& & \ddots & & ⋮\\ 000& \dots & 000& \dots & 110\\ 011& \dots & 000& \dots & 000\\ ⋮& & \ddots & & ⋮\\ 000& \dots & 011& \dots & 000\\ ⋮& & \ddots & & ⋮\\ 000& \dots & 000& \dots & 011\\ 010& \dots & 000& \dots & 000\\ 001& \dots & 000& \dots & 000\\ 000& \dots & 000& \dots & 100\\ 000& \dots & 000& \dots & 010\end{array}\right]\times \left[\begin{array}{c}{x}_{1,e}\\ x_{1,p}\\ x_{1,l}\\ ⋮\\ x_{i,e}\\ x_{i,p}\\ x_{i,l}\\ ⋮\\ x_{m\pm 1,e}\\ x_{m+1,p}\\ x_{m+1,l}\end{array}\right]=\left[\begin{array}{c}{t}_0\\ ⋮\\ t_i\\ ⋮\\ t_m\\ 0\\ 0\\ t_0\\ ⋮\\ t_i\\ ⋮\\ t_m\\ 0\\ 0\\ 0\\ 0\end{array}\right]$$

(1)

Here, the following constraints apply:

$$\underset{\_}{\underset{\_}{\mathrm{A}}} \times \underset{\_}{\mathrm{x}} = \underset{\_}{\mathrm{t}}$$

(2)

$$x_i\ge 0 \forall i$$

(3)

$$So that min\{\sum _i{\left(\underset{\_}{\underset{\_}{A_i}}\times \underset{\_}{x_i}-\underset{\_}{t_i}\right)}^2\}$$

(4)

Naturally, constraint (2) was applied. Constraint (3) defines that each x must be larger or equal to 0, meaning that the number of vehicles cannot be smaller than 0.

If the number of measurement points was higher than 4, the number of columns exceeded the number of rows. This means that the system is underdetermined, which means that there are either zero or an infinite number of solutions. In order to provide a solution with relatively small x values, we optimized for Equation (4). This problem will provide us with the number of vehicles leaving, entering, and passing on each driveway. The algorithm also ensures correctness in converting the generated data into flows. On the first and last road segments, there are only entering and leaving vehicles, respectively. This method had to be applied in both driving directions.

4.5. The Proposed Algorithm to Calculate the Flows

We designed an algorithm (Algorithm 1) to convert the demand values into vehicle flows. The algorithm walked through the driveways starting from the nearest and tried to assign as much of its entry demand as possible to the existing values in the other driveways. The algorithm generated the necessary flows, which were converted to the SUMO format. The algorithm had to be applied in both directions.

4.6. Generalization of the Solution

The current solution can only be applied to traffic models with only one highway. This algorithm can be easily extended to more complex networks with multiple highways. In such traffic networks, only the connections have to be handled, and after that, the proposed algorithm can be applied without any changes. Taking such connections is quite an easy problem to solve, but it is not in the scope of the current document.

5. Measurement Details and Results

In V2X networks, the most crucial channel load parameter is the CBR—Channel Busy Ratio. The relevant ETSI standard defines the measurement of this parameter. The V2X protocols also use this value for congestion control [60]. This work focused on this CBR parameter affecting the V2X channel scalability and measured CBR values on eight R-ITS-S nodes and all the V-ITS-S nodes within the selected highway section. With the evaluation of this CBR parameter, we wanted to highlight two different perspectives. On the one hand, we wanted to depict the CBR values on some well-defined measurement points in the network with the first approach. This approach gives us an overview of the average CBR values in the whole network and represents the R-ITS-S perspectives. We took the average of the CBR values measured on the R-ITS-S devices to measure this parameter. On the other hand, we tried to highlight the perspective of the vehicles. We wanted to show what CBR values an average vehicle will see when it participates in the traffic with this value. We calculated the average CBR value on each V-ITS-S node to measure this parameter and took the average of the calculated average CBR parameters.

5.1. CA Service

The standalone use of CA service is typical today in the so-called Day1 scenarios or deployments. In some cases, Day1 use cases also include DENM and IVIM messages in highway scenarios; however, these message types were not in the scope of this work, since they would only change the results marginally.

Figure 6 shows that the CBR values will remain low if we only use the CA service. This means that the maximum value of the CBR remains around 6% even with the assumption of 100% penetration—this is approximately half of the value measured with both CP and CA services. We can also see in Figure 6 and Figure 7 that the data are growing nearly linearly.

Figure 7 shows that the average CBR values reported by V-ITS-S nodes are slightly higher than those reported by R-ITS-S nodes. The clusterization is more or less similar to the CAM and CPM scenarios.

5.2. CP Service

The CPM—Collective Perception Message—is a message type that can drive so-called Day2—or perception sharing—use cases. The CPMs and CAMs are both sent by V-ITSS nodes and are also sent quite regularly, in many cases with 10 Hz—unlike, for example, the DENM. This means that CAM+CPM messages are responsible for the majority of channel usage. We can assume that if an ITSS supports CPM, it also supports CAM. The measurement of the standalone CP service still makes sense, because ITSG5 supports multiple channels, and it is not certain whether CA and CP services will be deployed on the same channel in the future. We have to emphasize that in our CPM model—thanks to the Artery framework’s sensor and environment architecture—the generation of the perception messages perfectly complies with the characteristics of the realistic, traffic-given environment. This means that the size of every CPM message is in line with the actually sensed number of objects (other vehicles in the ego sensor range) for every V-ITS-S during the simulation.

The simulation results show that the CP service is responsible for a similar CBR value compared to the CA service considering the applied vehicle traffic parameters. This is visible in Figure 8. The maximum CBR value was around 6% in each scenario.

We can see in the Figure 9 diagram that the measured values are slightly higher than the ones measured on the R-ITS-S nodes.

We can observe in Figure 8 and Figure 9 that if we add the values measured in the CAM and CPM scenarios, the result will be about the same as in the combined CAM + CPM scenario alone. This is due to the relatively low channel usage. We can also see that the traffic measurement intervals with low traffic have only minor channel usage.

5.3. CA and CP Combined Services

In the combined usage of CA and CP services, we can see in Figure 10 and Figure 11 that the CBR value increases almost linearly with the V2X penetration. In the case of the highway scenario, the CBR value was at most 12%, which means that the channel is capable of handling a lot more additional services than just the CAM and CP services—or, in other words, it is capable of providing the CAM and CP services on a high service level. We can also see from Figure 10 that the CBR values are growing almost linearly with the penetration. We can also see that lower traffic generates higher average CBR values. These symptoms are valid, since the simulation has a stochastic nature, and the selection of traffic densities does not consider the traffic patterns.

In Figure 10 and Figure 11, we can observe that the two different approaches provide similar results. The R-ITS-S nodes experience slightly lower CBR values than the regular V-ITS-S nodes.

We can also see that the CBR values are characterized mainly by three different clusters, one representing the minimum values, one representing the average values of January and March, and one representing the maximal intervals and the average of September. From the diagram, we can see that September is quite a busy month from a traffic perspective.

6. Conclusions

In this work, we successfully modeled the C-ITS infrastructure of the Budapest Ring Road (expressway M0) and simulated V2X messaging of Day1 and Day2 cooperative services using real-world traffic data measurements in our implementation. The traffic data were processed and fed to the simulation engine, which used a detailed implementation of the overall V2X communication chain from the access and networking layers through the facilities and toward the applications/services.

We could see from the results that the V2X channel load remained in the acceptable range in every case. In the case of 20% penetration—which could represent the V2X penetration in the foreseeable future—the CBR value was about 0.02 in the combined CAM and CPM case and only about 0.01 in the case of single CA or CP services (both from the infrastructure’s and the vehicle’s point of view).

However, as the V2X penetration grows and the number/bandwidth requirements of C-ITS services increases, the ITS-G5 channel will definitely see more considerable challenges: it might quickly be saturated in Day2 and beyond scenarios. Multi-Channel Operation (MCO) techniques can be applied to mitigate this problem.

Our future work is to implement a complete list of ITS services with all the possible Day1/2/3 applications in the created C-ITS environment and analyze the precise conditions of channel saturation during the modeled realistic traffic situations.