## 3 System Model
### Join the Network
In this simulation, server delay is the delay between maximum end-to-end delay between local TA and other TAs. Local TAs call all other TAs (REST API) parallelly, so we measured the average maximum delay as server delay. The V2X delay is the communication (network) delay between joining the vehicle and the local TA. Figure 9 compares the joining time breakdown for 5G and Wi-Fi vehicles. It shows that the additional joining delay in the Wi-Fi vehicle is due to the V2X network delay, where the Wi-Fi vehicle connects to RSU via ad hoc Wi-Fi and then uses 5G. This shows the delay could be 100 ms. Figure 10 shows the CDF of the V2X network delay for both vehicles. Therefore, more focus should be on network designers to add more RSUs near the edge of the V2X network and potentially use RSUs with high transmission power to increase range. Figure 11 shows the cloud network delay between TA communication and its average of less than 5 ms. Selecting a dedicated cloud network could potentially reduce this delay; however, it is small compared with the V2X delay. Therefore, more focus should be on improving V2X delay. Figure 8: Time taken to compute a public key. Figure 9: The joining time breakdown for 5G and Wi-Fi vehicles. As shown in Figure 12, encryption and decryption time is not huge compared to network delays. For example, a 1024-byte message can be encrypted or decrypted within 1 ms. However, as shown in Figure 8, the public key calculation is expansive. Therefore, based on network requirements, we need to select the correct security parameters. Figure 11: The cloud network delay between TA communication. Figure 10: The CDF of the V2X network delay. ## 5 Discussion

The previous section evaluated the proposed system in two ways. First, we evaluated the time taken for network initialization in Section 4.2, which is influenced by the size of the private key, the threshold value T, and the computational power of the machine executing the process. Second, we evaluated the performance of a vehicle joining a V2X network in Section 4.3. We used a stationary 5G-connected vehicle simulated in NS-3 in our V2X network to evaluate this and tried to join the network using two verification methods: client-verify and server-verify. In this section, we will discuss the key findings from the performance evaluations of the proposed system. The use of larger private key sizes in V2X communication systems has been an ongoing discussion due to the potential benefits it could offer in terms of security. However, concerns regarding the potential overhead that may arise from the use of larger key sizes have been raised. Our simulation that was discussed in Section 4.2 demonstrates that the initialization time increases linearly with the increase of the private key size. Nevertheless, our research results in Figure 5 have suggested using private key sizes can be larger than 512 bits without incurring considerable overhead, with an average processing time of 2-3 milliseconds. Another parameter that has been considered in the context of V2X network initialization is the threshold value T. Research has indicated that increasing the value of T does not have a significant impact on the network initialization process, allowing for larger T values to be used (greater than 12) without adverse effects. Therefore, network designers should try to use large private key sizes as well as large T values. One approach we considered to reduce the overall time required for vehicles to join the V2X network is server verification, as shown in Figure 4:0 Performance analysis has shown that server verification can reduce verification time by 15% compared to local verification. Moreover, this time can be further reduced by increasing the computational power available in cloud-based systems. The time taken to compute a public key is another factor that can impact V2X network performance. As shown in Figure 8, as the number of TAs and threshold values increase, the time required to compute a public key also increases.