## 3 Proposed Methodology
### Overall Routing Process
At the end of the functioning of block \"Z0\" (once the updating of the flow table is over), the controller must unicast FlowMod packets related to each flow entry of the flow table to corresponding switches, as shown in block \"B1\" of Figure 13;
* Routing occurs at a routing frequency (f), and, at each routing cycle, including the very first, routing occurs as packet transmissions are scheduled, as is evident from block \"A\" in Figure 13. Packets are forwarded through each node by inspecting the flow table of the node. Because of the implementation of route valid timestamp in the proposed flow table, when a flow table match occurs with source address not equal to destination address, action not explicitly defined to drop, and current timestamp greater than the route valid timestamp, a packet_in message will be generated and sent to the controller, as shown in block \"C1\" in Figure 13, as the current flow entry in the flow table at the switch has expired. Then, in response to the packet_in message, the adaptive flow rule computation, update, and installation algorithm will run as shown in block \"C2\" in Figure 13 to create a FlowMod packet containing flow modification rules, which will be unicasted to the corresponding switch, as shown in block \"C3\" in Figure 13, to update the corresponding flow table entry in the switch with updated flow rules. Note that, if a flow table mismatch occurs due to a packet scheduled to a destination node that does not exist in the vehicular network, a packet_in message will be sent to the controller. Then, the adaptive flow rule computation and update algorithm will inspect the destination, and, as it does not exist in the topology database, a FlowMod packet to drop the packet at the switch will be sent back to the switch. During the entire routing time period (the time period during which routing occurs), each node monitors its transmission queue size at discrete time intervals and computes the parameters' average queue size (\(\overline{\mathcal{R}_{i}}\)) and average pending transmission packet distribution factor (\(\overline{\mathcal{Q}_{i}}\)), as shown in block \"K1\" of Figure 13. Computed \(\overline{\mathcal{R}_{i}}\) and \(\overline{\mathcal{Q}_{i}}\) values are kept with the nodes until they are unicasted to the controller node in the next routing cycle, along with other metadata, as shown in block \"U1\" of Figure 13. The routing in all routing cycles is similar (Functioning blocks \"K1\", \"A\", \"C1\", \"C2\", and \"C3\" operate in each routing cycle, including the initial cycle, similarly);
* Starting from the second cycle (subsequent cycle 1) onwards, agent nodes should collect and unicast status data, a set of node addresses of one-hop neighbors of each node (\(\mathcal{S}_{i}\)), \(\overline{\mathcal{R}_{i}}\), and \(\overline{\mathcal{Q}_{i}}\) computed from the previous routing cycle, as evident from the \"U1\" block in Figure 13. Thus, at the controller node, \(\overline{\mathcal{Q}}\) is computed using the \(\overline{\mathcal{Q}_{i}}\) values received from all the nodes. \(X[N,N,2]\) and \(T[N,N,2]\) are computed at subsequent routing cycles in the same manner specified for the initial cycle. Furthermore, starting from subsequent cycle 1 onwards, normalized homogeneous link entropy with respect to wireless links (\(H_{\text{W}L}\)), normalized homogeneous link entropy with respect to wired links (\(H_{\text{W}I}\)), average collision probability for wireless links (\(\overline{\rho_{\text{W}I}}\)), average collision probability for wired links (\(\overline{\rho_{\text{W}I}}\)), and average contention delay for wired links (\(\overline{\rho_{\text{W}I}}\)) are computed, as shown in block \"K2\" of Figure 13. Using previously computed parameters, normalized network contention (\(\mathcal{C}\)) is computed using Equation (29). Furthermore, the adjacency matrix of link delay (\(D[N,N,2]\)) can be found using Equation (35), with the help of the one-hop per-channel delay prediction DNN.