The primary components of a V2X system are the On-board Unit (OBU) and the Roadside Unit (RSU). The OBU is a device installed in a vehicle, responsible for communication with other vehicles (V2V, Vehicle-to-Vehicle) and infrastructure elements (V2I, Vehicle-to-Infrastructure). The OBU collects and transmits data necessary for enhancing road safety, informing the driver, and supporting various applications such as navigation and collision warning systems. The RSU is a stationary device installed along roads or on other infrastructure elements. RSUs facilitate communication with OBUs (V2I) and among themselves (I2I, Infrastructure-to-Infrastructure). The primary function of an RSU is to collect, process, and transmit data received from vehicles, as well as provide access to information necessary for the correct operation of transportation applications and the improvement of traffic coordination. Mobile RSUs (mRSUs) are increasingly utilized to organize communication between OBUs and RSUs. Their purpose is to move across the map and address tasks directly near the user, i.e., the OBU.
When simulating a system involving vehicles, roads or lanes are required. For simplification, we assume all roads have one main lane and one opposite lane. The set of road connections can be interpreted as a graph. By mapping the graph onto a graphical interface, we obtain a map of the terrain where the vehicles will move. For model simplification, intersections will not be further burdened with traffic lights or pedestrian crossings. Therefore, it's necessary to create the following components: RSU, OBU (vehicle), and road (lane).
3.1. Mathematical Model
We will now briefly review the mathematical framework employed for implementing the V2X system model and its subsequent simulation.
In the authors' earlier work, a rectangular metric was used for organizing the road network due to its widespread adoption and ease of description. In the present study, the road structure model is represented generally as a graph, where intersections are vertices and roads are edges. This approach is significantly more flexible and allows for an expanded class of optimization problems. Note that the choice of metric, or the method of distance calculation, becomes secondary and depends on the specific tasks and road maps used for the simulation.
We will outline the core principles concerning traffic organization:
Vehicle generation, which will be managed subsequently, is described by Equation (1), defining the speed distribution density for each OBU on a road section within a single RSU's coverage area. The speeds represent a stream of independent, identically distributed random variables with values ranging from a specified minimum to maximum speed, i.e.,
.
OBUs interact with RSUs by exchanging data blocks, for example, information regarding traffic congestion on a route section. Let each OBU and each RSU generate information as a vector M of uncorrelated data elements .
For numerical simulation, we assume that the random variable representing the probability of an element
in the tuple
being requested by an OBU follows a Zipf distribution, calculated using Equation (2):
where A is the distribution asymmetry coefficient and corresponds to the loading degree of the vehicle system.
If an OBU accelerates within a road section serviced by RSU
m/s, and the coverage area of this section spans
meters, then the maximum number of requests that the RSU can process from a specific OBU is calculated using Equation (3):
It's worth noting that in real-world conditions, signal attenuation occurs naturally as the vehicle moves away from the roadside unit within the RSU's coverage area. Our simulation scheme employs the well-known Hata (Okumura-Hata) model [
38] to account for the building coefficient and its influence on attenuation.
Data loss occurs during OBU-RSU interaction, described by Equation (4). Let us enter the loss function when processing RSU OBU requests. Let the OBU at number
form a request
then the interaction loss on the length portion of the
will be:
If some of the requested information needs to be updated, then the total interaction time will be (5):
where
if the data is outdated, and
, if the data does not require updating, for each pair of vehicles RSU.
Describing the mathematical framework for mRSU operation requires a more detailed explanation of pathfinding algorithms in graphs since we assume that in all scenarios, mRSUs move along dedicated lanes without encountering traffic jams.
It is convenient to utilize Estimated Time of Arrival (ETA) [
39] as a cost function: the resulting route will be the shortest among all possible routes. In the simplest case, travel time comprises two factors: time spent traversing graph edges and additional time for maneuvering when transitioning between graph vertices.
where the first summation represents the travel time along graph edges and the second represents penalties for maneuvers. If the mRSU moves along a dedicated lane on the previously described route, the average travel time remains constant. If mRSU movement to a specific map point is considered, then at each stage, the element of our dynamic system closest in terms of arrival time must be selected.
The problem with the chosen cost function, ETA, lies in the need to consider route parameters beyond just travel time. The identified route may be highly inconvenient for several reasons: poor road quality (e.g., poor surface, numerous potholes, lack of markings) or complex turns or intersections that should be avoided. Iterating through all possible route options would consume significant computational resources, impacting the overall system. Therefore, our study employs statistical analysis to determine preferred edges for traversal, formalized by Equation (6):
where
– is a normalized weight function approximating the attractiveness of each edge on the route,
– the portion of penalties accumulated at traversed intersections. Experimental results indicate that a linear function
yields the best results.
Systemic errors in speed determination can occur on certain roads (e.g., due to insufficient data), resulting in a suboptimal calculated route. However, the proposed approach significantly reduces the average error magnitude.
3.2. Simulation System
Selecting an environment or tools for developing a V2X system simulation requires careful consideration of both road traffic and data transmission modeling implementations.
OMNeT++ is a flexible and powerful discrete event simulator widely employed for network simulation. Its modular design supports seamless integration of various components such as VEINS and INET. Its advantages include high customizability, robust community support, and powerful visualization tools. However, effective utilization of OMNeT++ requires a substantial learning curve, posing a significant constraint for this project.
VEINS (Vehicles in Network Simulation) is a framework that bridges road traffic simulation with network interaction simulation. Operating in conjunction with OMNeT++ and SUMO, VEINS provides high-fidelity modeling of both vehicular movement and data transmission. Its strength lies in integrating network models with vehicle models. However, utilizing VEINS necessitates familiarity with both OMNeT++ and SUMO, thereby increasing development complexity.
SUMO (Simulation of Urban Mobility) is a widely adopted open-source road traffic simulator, enabling vehicle movement modeling in urban and suburban environments. SUMO offers a high degree of detail and supports complex traffic scenario simulations. Its advantages encompass integration capabilities with other tools like OMNeT++ and VEINS, alongside a comprehensive feature set for scenario customization. A primary drawback of SUMO is its complex configuration and the prerequisite for preparing road network data.
INET is a library for OMNeT++ providing models of network protocols and devices. INET supports various network technologies, including Wi-Fi, Ethernet, and TCP/IP, making it well-suited for modeling data transmission networks in V2X systems. Its advantage lies in its extensive functionality and the ability to model network interactions in detail. However, similar to OMNeT++, INET requires considerable knowledge and experience for effective use.
AnyLogic is a comprehensive simulation platform offering built-in modules for road traffic and infrastructure modeling. AnyLogic's distinguishing feature is its combination of various modeling paradigms, including discrete event, system dynamics, and agent-based modeling. Its integrated traffic and road simulation module enables the creation and customization of traffic scenarios without requiring external simulator integration. AnyLogic's intuitive interface and capacity for rapid development of complex models are advantageous. A potential drawback is the high cost of licensing, although AnyLogic provides a free educational license with limited features compared to the OMNeT++, VEINS, and SUMO combination for specialized V2X system simulation.
Analysis of the presented tools revealed that each environment possesses both advantages and disadvantages. However, considering the complexity of comprehensive integration and utilization of these tools collectively, the need arose for an alternative approach. Furthermore, extending the functionality of certain closed systems presented challenges. Given these circumstances, we opted to explore an alternative approach for creating the simulation system using Python.
Python is well-known for its simplicity and powerful libraries for scientific computing and simulation, such as NumPy, SciPy, and SimPy. However, Python's interpreted nature, leading to slower execution speeds compared to compiled languages, can be problematic when simulating complex real-time systems. To address these limitations, we selected GDScript, the scripting language integrated within the Godot Engine (
https://godotengine.org/). GDScript's syntax resembles Python, facilitating a smooth transition for developers familiar with Python. Crucially, unlike Python, GDScript is compiled, providing a significant performance advantage. This makes it suitable for simulation tasks where high performance is essential.
Godot is a modern, open-source game engine offering a robust environment for creating both 2D and 3D applications. While primarily designed for game development, Godot's flexibility and extensibility allow for diverse applications, including simulating network systems like V2X. The compiled nature of GDScript and Godot's optimizations enable real-time simulation with minimal latency. Furthermore, Godot facilitates the visualization of vehicle movement and network interactions, enhancing the clarity of simulation results. Godot's modular architecture and open-source nature allow the system to be easily extended and customized to specific project requirements. Thus, the choice of Godot and GDScript effectively addresses the key challenges encountered, ensuring high quality and performance within the simulated system. Importantly, working with Godot offers the possibility of future development in 3D, incorporating the effects of network interference from surrounding buildings.
As described earlier, roads are fundamental elements within the V2X system. While manual road rendering is possible, developing a dedicated editor is resource-intensive. Therefore, we opted to utilize readily available cartographic data, significantly streamlining the development process. OpenStreetMap (OSM) was chosen for this purpose.
OpenStreetMap (OSM) is an open and freely available geographic database, providing detailed information on roads, buildings, and other infrastructure elements globally. OSM's community-driven nature ensures data relevance and accuracy. To integrate cartographic data into our simulation system, we employed an approach where the map is automatically generated from OSM data. This allows for rapid retrieval of current data for any location, readily applicable in the simulation. Python, with its powerful geospatial analysis libraries, was chosen for processing OSM data.
Initial location data extraction is performed with Python code utilizing the osmnx library, simplifying the download and processing of OpenStreetMap data. The following Python code snippet demonstrates this data extraction process:
The extracted files contain the following columns:
nodes.csv: osmid, y, x, highway, street_count, ref, geometry
edges.csv: u, v, key, osmid, name, highway, maxspeed, oneway, reversed, length, geometry, lanes, ref, access, bridge, tunnel, width, junction
Godot provides the Path2D element, suitable for this task. It connects points (nodes) to form roads. Subsequently, PathFollow2D can be used to move vehicles along these Path2D elements, which will be detailed below. This process resulted in the map depicted in
Figure 3, with a scale of 1 meter to 1 pixel. Camera adjustments within the scene enable map zooming.
The chosen approach offers flexibility by enabling users to create custom maps and utilize them within the traffic flow simulation environment.
We utilize PathFollow2D in Godot to represent vehicles, treating the path (Path2D) as a continuous straight line, even with multiple points and curves. For clarity, such "paths" will be referred to as sections, and the combination of sections will be a route. By obtaining the length in pixels, we move the object along the "straight line" at a set speed. We assume an average speed of 30 km/h, which translates to approximately 8.5 m/s. With a 1:1 ratio, vehicles move at 8 and 12 pixels per second.
A vehicle's route from one point to another consists of a set of sections (Path2D) determined using the A* algorithm [
40]. Thus, a vehicle initially has the shortest route to its destination.
Vehicle movement alone is insufficient for simulation. We must also account for these vehicles generating traffic. For simplicity, vehicles cannot overtake each other and may experience congestion if the leading vehicle stops.
Upon entering a new section (Path2D), the following algorithm is executed: For every vehicle within the current section, we determine its location as the distance traveled from the section's start. If the distance allows for a transition, the vehicle moves to the next section and continues at its set speed, maintaining a distance of 20 pixels from the preceding vehicle. If the distance is insufficient, the transition does not occur.
Vehicles spawn at their route's starting point. Upon reaching their destination, they randomly select a new destination and continue moving.
Figure 4.
Traffic algorithm scheme.
Figure 4.
Traffic algorithm scheme.
RSUs are crucial system components. Their implementation in the software must consider not only their physical properties, adhering to the IEEE 802.11bd standard [
41], but also their placement on the map.
The RSU operation and OBU interaction algorithm is as follows: Using an Area2D element, a monitored zone is established. When an OBU enters this Area2D, it is considered within the coverage area and capable of data transmission. Accurate simulation also requires incorporating distance-based attenuation and accounting for data loss. Information transmitted by the RSU can be classified as either useful or overhead. Useful information consists of commands for the OBU, while overhead information constitutes a specific volume of bits. If messages need to be sent, the RSU allocates transmission speed equally among connected OBUs. Message transmission is simulated with packet-based modeling, meaning a single message may comprise several packets. A primary channel is assumed for multimedia traffic, while a secondary channel is used for transmitting critical information like instructions.
The primary interface provides information about the selected element. Currently, only RSUs are supported, though minor modifications could incorporate additional placeable objects. Upon clicking "Select Folder," the user is prompted to open a folder containing simulation configurations. Upon successful selection and loading, a second window containing the map opens.
A dedicated block within the interface displays information about the selected map element. However, it currently remains empty, as the specific information display requirements have yet to be defined at this development stage. Defining these requirements would delay prototype creation beyond the scope of this practical implementation.
A system accepting an event list as input has been designed for creating simulation scenarios. Events can be specified for each simulated object within the system.
3.3. Description of the Simulation Environment and Experimental Scenarios
The simulation was conducted using a Windows 11 operating system with the following software specifications: RTX 4060 graphics card with 8 GB of video memory, AMD Ryzen 7 7735HS processor with 8 cores and 16 threads at 3.2 GHz, 16 GB of DDR5 RAM at 4800 MHz.
Key system parameters for the model were derived from the IEEE 802.11bd standard documentation [
41], some of which are presented in
Table 1.
Initially, we will describe the simulated system. The average speed of vehicles (OBUs and mRSUs) is 30 km/h. RSUs have access to MEC, and if they cannot provide up-to-date information upon request, they query the MEC for updates. If the RSU belongs to a cluster, it queries the cluster for information before sending a request to the MEC.
Even if two or more RSUs are located on a section, we assume OBU-RSU interaction occurs with only one station, thereby avoiding redundant requests from the OBU. In other words, in cases of multiple connection possibilities, the OBU autonomously selects a single RSU for connection. If an OBU isn't connected to any RSU, it connects to the first one encountered along its route. If multiple connection options exist, it retrieves information about the current number of OBUs connected to each RSU. If this number is less than 20% of the current RSU's active connections, the OBU switches to the less loaded RSU. OBUs perceive mRSUs as RSUs, while RSUs perceive mRSUs as OBUs. The primary difference between mRSUs and OBUs is the ability to process requests and store data, while mRSUs are not connected to the MEC and consequently redirect requests to a connected RSU according to the logic described above. The primary distinction between mRSUs and RSUs is their mobility along OBU movement paths.
Within the simulation framework, a vehicle (OBU) may encounter an emergency situation, triggering a message to the nearest RSU, which then propagates this information. Initially, all vehicles connected to this RSU are notified about the incident, followed by the remaining infrastructure, including mRSUs.
Modulated event-case. After a period of continuous movement, every tenth vehicle experiences an "accident," resulting in a complete stop and blocking the road. After waiting for 10 to 60 seconds, the vehicle resumes movement. In the event of an accident, the system is designed to send a critical message. Subsequently, vehicles within RSU coverage are expected to update their routes, while other vehicles continue on their initial paths. Once the accident is cleared, a message is transmitted to the RSU, enabling subsequent vehicles to proceed to utilize unblocked route. Vehicles spawn at random locations across the map, simulating a more realistic and heavily loaded traffic system.
Our model considers unique content requests. The size of the response to each request ranges from to bits.
It's important to note that the simulation was conducted on a map representing the infrastructure of Manhattan, NYC, USA (
Figure 3), which facilitated subsequent comparison of results and evaluation of the developed simulation system's effectiveness.
The program's output includes three scenarios. Each scenario employs two RSU placement schemes:
Scheme 1: RSUs are placed as densely as possible, with a data collection and transmission device at each road section or block. Data transmission to the higher level is carried out independently by each RSU over a dedicated communication channel (possibly fiber optic). The coverage areas of different RSUs may overlap. OBUs can sequentially query the least loaded RSU within their coverage area for data exchange. The main drawback of this arrangement is the high cost of network organization and its "noise" due to numerous cross-requests.
Scheme 2: RSUs are sparsely placed on the map, with the sole condition that the entire map is covered by RSU coverage areas. For centralized interaction with the MEC, roadside units are grouped into clusters with a shared cache. A primary element is selected within each cluster to interact with the MEC. While significantly reducing system management costs, this scheme may increase data loss within the system and potentially lead to complete system blockage.
1. The interaction model includes only four system elements: OBU-RSU-MEC-CLOUD.
2. As previously mentioned, using mRSUs significantly improves system efficiency. Mobile RSU movement routes are chosen according to designated public transport routes. mRSUs move on a schedule, enabling prediction of their location and anticipated appearance at specific points. The main disadvantage of this scheme is the presence of idle mobile RSUs not involved in system operation during periods of low network load. However, this is expected to be mitigated by high traffic flow or long mRSU travel routes. Within this model, all mRSUs are assumed to be en route according to the schedule.
3. This scenario proposes a new mRSU management scheme where each system element is responsible for serving a specific map area. Alternatively, it can be stationed in a depot until notified of increased load within its designated area. In this case, the mRSU travels to the call point via the shortest route, the mathematical description of which is provided in
Section 3.1.