## 4 Prevention Mechanisms of the Proposed Scheme
### Fog Computing (FC) Storage Preventive Model  
VANET is mainly designed to optimize the communication network between the vehicles. Due to the high movement of the vehicles, Fog Computing and cloud integration (VFC) has gained attention in this area. Fog Computing that denotes VFC can store a lot of data, which can be reused and can be aggregated to prevent time succession searches, as the vehicles have a lot of on-board storage [37]. Broadcasting data for vehicles in the network differ, based upon fog computing status. When the vehicle status is in the state of being elected for communication, in which the vehicles discover the decision of subsequent state on vehicle location information and speed, broadcasting of vehicles data packets (\(d_{p}\)) are considered so that they arrive at CM (Cloud member) within the network. When the CL (Cloud leader) produces data packets, it confirms through the information acquired from vehicles if packets are either received effectively or not. When the vehicles in the cloud have the data packets, then vehicles verify the packet source. When the source is from the parent cloud, they multicast the data packet to the cloud member, otherwise, the packet is taken from the vehicle as the state election mode. Later, vehicles unicast the received packets towards the parent cloud to send the packet until packets arrive at the cloud leader, which discloses the vehicle information. Accordingly, as shown in the below algorithms, if the cloud leader produces a data packet, initially it verifies the packet source. When the data packet approaches from endo-B (an element of the long term evolution (LTE) radio access network), the cloud leader transfers the data packet to each cloud member or the packet is sent from the parent cloud (\(pr_{c}\)) member. In this circumstance, the cloud leader sends the data packet to the cloud member and generates the LTE data packet (\(LTE_{dp}\)), which transfer the packets to endo-B with  
Figure 5: Authentication of data packets using vehicular RSA encryption algorithm. the novel original received packet from the vehicle. In the end, the packets are updated as cloud leader vehicle information (CLvInf). The PSAM utilizes the multicast/broadcast and unicast modelling in order to fulfill the requirement as needed. Obviously, the multicast architecture incurs some latency and as it broadcasts the data, it will consume some time. Algorithms 3, 4, and 5 decrease the issues of the broadcasting storm within the network by lessening the iterated data broadcasting and by keeping less overhead information. They also broadcast the specific data using appropriate vehicles or nodes that also decrease the network load. The reduction of network load action taken is necessary due to consideration of overwhelming messages that may occur as a result of all forms of attacks, including HDSA and DoS JSA in the network. They also lessen the problem of network disconnection by lessening the regular downloading and subscription to the network [38]. Table 1 depicts the notation and descriptions of the algorithms and the models terms. ```
1 On \(d_{p}\) generating or receiving: //on receiving or generating the data packets
2 filter \(Id_{data}\) or \(req_{data}\); //Filter on Packets
3 If (\(Id_{data}\), \(req_{data}\)) \(\epsilon\) CLvInf &
4 If \(d_{p}\) is from \(pr_{c}\)then
5 multicast on \(d_{p}\) to CM; //Multicast situation
6 else
7 unicast \(d_{p}\) to \(pr_{c}\) CL //Unicast situation
8 Update vInf;
9 endif
10 endif
11 end
```  
**Algorithm 3** IEEE 802.11p-LTE CM. ```
1 for on \(d_{p}\) generating or receiving then
2 filter \(Id_{data}\) & \(req_{data}\);
3 If (\(Id_{data}\), \(req_{data}\)) \(\epsilon\) CLvInf &
4 If (On \(d_{p}\) is from eNodeB) then
5 send on \(d_{p}\) to CM;
6 else
7 broadcast \(d_{p}\) to CM
8 develop \(LTE_{dp}\) and send to eNodeB then
9 Update vInf;
10 endif
11 endif
12 endfor
13 end
```  
**Algorithm 4** IEEE 802.11p-LTE Cloud leader (CL).