# Simulation-Based Evaluation of V2X System with Variable Computational Infrastructure
## 3 Materials and Methods
### 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  
Figure 5: Traffic algorithm scheme. Ryzen 7 7735 HS processor with eight 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.11 bd standard documentation [51], 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 EC, and if they cannot provide up-to-date information upon request, they query the EC for updates. If the RSU belongs to a cluster, it queries the cluster for information before sending a request to the EC. 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 is not 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 EC 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. In our chosen scheme, OBUs follow a one-way traffic pattern on roads, while mRSUs, when moving towards an offloading point, utilize a dedicated lane, thus not creating additional load on the system. 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. In simulation, 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 s, 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 with the unblocked route. Vehicles spawn at random locations across the map, simulating a more realistic and heavily loaded traffic system. Our model considers \(10^{6}\) unique content requests. The size of the response to each request ranges from \(4,194,304\) to \(8,388,608\) bits. \begin{table}
\begin{tabular}{c c c} \hline \hline \multirow{2}{*}{**Parameter**} & **OBU/mRSU** & **RSU** \\  & **(Onboard Unit/Mobile Onboard Unit)** & **(Roadside Unit)** \\ \hline Frequency & 5.9 GHz & 5.9 GHz \\ \hline Bandwidth & 10 MHz & 10 MHz \\ \hline Noise Figure & 9 dB & 9 dB \\ \hline Transmitter Power & 20 dBm & 25 dBm \\ \hline Antenna & 1 m & 3 m \\ \hline Range radius & 500 m & 250 m \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Model system characteristics. It is important to note that the simulation was conducted on a map representing the infrastructure of Manhattan, NYC, USA (Figure 4), which facilitated subsequent comparison of results and evaluation of the developed simulation system's effectiveness. The program's output includes three scenarios.