## 3 System Model
### Join the Network
### Performance Evaluation of Vhelical Joining a V2X Network

Once the vehicle receives shares and witnesses, it must be verified as described in Equation (12). Share verification is a critical security condition in a distributed threshold-based secret-sharing scheme and is computationally intensive. However, our proposed system model defined a vehicle as having a pre-existing trust relationship with their Home TA. Therefore, we defined two verification types, client-verify, where verification is done in the vehicle, and server-verify, where the Home TA inside the cloud server does verification. Vehicle joining time will include the V2X network delay, combined share calculation time of all TAs, and network delay between the Home TA and other TAs. 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. First, we ran a simulator with a different number of TAs from 2 to 12 and a threshold value of 3 to 12. We also varied private key sizes from 64-bit to 512-bit with 64-bit increments. Other parameters are kept the same as stated in Table 3. Each configuration was run 100 times. The share calculation time, verification time, V2X network delay, and cloud network delay were measured. Figure 6 shows the breakdown of joining time for both verification types. Here, we exclude V2X network delay and cloud network delay in the figure. The impact of communication delay is evaluated in the next section. This concludes that using server verification reduces verification time by 15%. This was performed using the least powerful AWS server. Increasing computational power in cloud computers is easy; therefore, server verification time can be further reduced by using powerful computers available in the cloud. Hence, it reduces the overall time that the vehicle required to join the V2X network. Figure 7a shows the impact of the number of TAs on the total join time calculation for both verification types, while Figure 7b shows the impact based on the threshold value. In both cases, with an increase of TAs and threshold value, verification time is increasing. However, if it shows using server verification, we can reduce the overall verification time. Figure 5: Network initialization time by the size of the private key and threshold number. Another critical parameter to evaluate is the time an entity takes to calculate another entity's public key using Equation (13). For example, Figure 8 shows the time taken to compute a public key increase with the number of TAs and threshold values. Therefore, we need to select different parameters based on network performance and security requirements. ### Communication Overhead of Joining V2X Network

As mentioned earlier, communication overhead occurs in two different locations: in V2X, where 5G-enabled vehicles connect to the Home TA via 5G network; or Wi-Fi-only vehicles which connect to the Home TA via RSU. In this case, vehicle to RSU communication will be via Wi-Fi, and RSU to Home TA is via 5G. Other network overhead occurs when the Home TA tries to communicate with the local TA and other third-party TAs. To evaluate this, we used 5G-enabled vehicles and Wi-Fi-only vehicles in the V2X network, where vehicles were randomly placed in a grid of 1000 m by 1000 m area and moving with a constant speed of 20 m/s using the NS-3 random walking module. We ran a simulator with 5 TAs, a threshold value of 8, and private key sizes of 256-bit. In addition, the size of P and Q were kept as 64-bit and the ID size was kept as 32-bit for the entire simulation. The simulation ran for 1000 s. With each second, RSU broadcasts network information,

Figure 6: Breakdown of joining time. Figure 7: Total join time calculation for both verification types; (**a**) impact of the number of Tas; (**b**) impact based on the threshold value. and the vehicle tried to join the network upon receiving the broadcast. We recorded V2X network delay as well as cloud network delay.