# A Deep-Learning-Based Secure Routing Protocol to Avoid Blackhole Attacks in VANETs +
## 3 System Model
### The Proposed DLSR Protocol
#### 3.3.1 Route Request Process  
In this sub-subsection, we explain in detail the RREQ process of the proposed DLSR protocol as follows:  
* **Step 1: Initialization** If the route between a source node \(S\) and a destination node \(D\) does not exist, the source node \(S\) starts the route establishment process.
* **Step 2: Source Generates and Sends RREQ Packet**  
Figure 4: The Basic Concept of the DLSR protocol.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Packet Name** & **Stand for** & **Field Information** \\ \hline INFO & Information Packet & \(\text{Type},\text{S}_{\text{ID}},\text{D}_{\text{ID}},\text{E}\) \\ CHI & Cluster Head Info Packet & \(\text{Type},\text{S}_{\text{ID}},\text{D}_{\text{ID}},\text{Pos},\text{S}, \text{Dir}\) \\ JC & Join Cluster Packet & \(\text{Type},\text{S}_{\text{ID}},\text{D}_{\text{ID}},\text{Stat}\) \\ AC & Accept Cluster Packet & \(\text{Type},\text{S}_{\text{ID}},\text{D}_{\text{ID}}\) \\ \hline \hline \end{tabular}
\end{table}
Table 3: Packet list for the DLC protocol.  
The source node \(S\) (a CM) wants to send a message to a destination node \(D\) located in another cluster. In this case, \(S\) generates the RREQ packet with a unique ID and a sequence number and then sends it to the CHi in the cluster if \(S\) does not have the routing information to the destination. The RREQ packet contains the following fields:  
\[\langle\texttt{Type},\texttt{S}_{\texttt{ID}},\texttt{D}_{\texttt{ID}}, \texttt{S}_{\texttt{seq}},\texttt{D}_{\texttt{seq}},\texttt{B}_{\texttt{ID}}, \texttt{H}\rangle\]  
where Type represents the packet type, \(\texttt{S}_{\texttt{ID}}\) represents the source node ID, \(\texttt{D}_{\texttt{ID}}\) represents the destination node ID, \(\texttt{S}_{\texttt{seq}}\) represents the source sequence, and \(\texttt{D}_{\texttt{seq}}\) represents the destination sequence, which is the number of attempts to confirm control messages. \(\texttt{B}_{\texttt{ID}}\) represents the broadcast ID, which is the number of generating RREQs in the same session at the source, and \(\texttt{H}\) is a hop count, respectively. Then, go to **Step 3**.  
* **Step 3: Intermediate Nodes Operation at CH for RREQ** When CHi receives the RREQ packet, it checks the freshness of the received RREQ packet and then checks its routing table for a valid route towards \(D\). The operation to check the freshness of the packet can be summarized as follows:  
Figure 5: The Flowchart of the Proposed DLSR Protocol.  
* **Step 3.1:** If \(S_{\tt seq}\) at the received RREQ is larger than \(S_{\tt seq}\) at the routing table, then go to **Step 3.3**. Otherwise, go to **Step 3.2**.
* **Step 3.2:** If \(S_{\tt seq}\) at the received RREQ is equal to \(S_{\tt seq}\) at the routing table, then check again whether the \(B_{\tt ID}\) at the received RREQ is equal to \(B_{\tt ID}\) at the routing table or if \(B_{\tt ID}\) at the received RREQ is larger than \(B_{\tt ID}\) at the routing table and H at the received RREQ plus one is less than H at the routing table or not, then go to **Step 3.3**. Otherwise, the packet will be dropped.
* **Step 3.3:** If the node ID in the CH\({}_{\rm i}\) table is the same as the destination ID in the RREQ packet, then go to **Step 3.4**. Otherwise, go to **Step 3.5**.
* **Step 3.4:** CH\({}_{\rm i}\) records the sender's ID, updates the routing table, and sends the RREQ packet to the destination using unicast, then goes to **Step 5**.
* **Step 3.5:** CH\({}_{\rm i}\) records the sender's ID, updates the routing table, and broadcasts RREQ to NN, then goes to **Step 4**.
* **Step 4: Intermediate Nodes Operation at GW for RREQ** When GW\({}_{\rm i}\) receives the RREQ packet from CH\({}_{\rm i}\), it records the sender's ID, updates the routing table, and broadcasts RREQ to NN\({}_{\rm i}\) by increasing the number of hop counts. **Steps 1-4** are repeated until the RREQ packet reaches the destination node's CH and goes to the **Route Reply Process**.