## 4 Results
### Configuration of the Simulation Environment
#### 4.2.1 Configuration for Routing
In particular, we scheduled broadcasting of status data (timestamp, node addresses, position, velocity, and acceleration) at 1 kHz frequency, where the received node stored the received status in the specific position of a 100,000 size data structure corresponding to 100,000 samples for 100 s. Note that wireless link lifetime of each sample in the data structure was the time elapsed from the timestamp at which the sample was received up to the timestamp at which reception of status from the given node address stopped (as the link has ceased to exist), or timestamp at the passage of 100 s in the case where the link continued to exist. Thus, when reception of status data from a given node stops or at the passage of 100 s, we stored (appended) the destination and source node's position, velocity, and acceleration along with the wireless link lifetimes for all samples stored in the data structure in a CSV file. Thus, we collected a combined data set having 3,368,564 samples for wireless link lifetime prediction training and testing. Collecting a data set for one-hop channel delay prediction--\(\overline{R_{i}}\), \(\overline{Q_{i}}\), and \(S_{i}\) of each node were collected and updated in the control node of the SDVN architecture, where data were collected at a 1 Hz frequency. Specifically, for generating a well-distributed data set in terms of input variables for one-hop channel delay prediction, we generated different data sets by varying the packet sizes in the set [10, 100, 1000] bytes, the DSRC data rate in the set [6, 12, 27] Mbps, the Ethernet data rate in the set [10, 100, 1000] Mbps, \(T_{slot}\) in the set [20, 40, 60], and E from 1 to 6 by varying \(CW_{min}\), \(CW_{max}\) in the range 15 to 1031. Input data (1 \(\times\) 30) required for one-hop channel delay prediction and the corresponding one-hop channel delay were saved in a CSV file to be read by a Python script for training. Note that the one-hop total delay for each hop in the network for each of the communication channels was computed by monitoring each packet's sending and receiving timestamp values in each of the communication channels. Specifically, for a given hop (\(i\)) in a given communication channel, the timestamp difference refers to the difference between the receiving timestamp of the last packet at the destination sent from node \(i\) through the given communication channel and the sending timestamp of the first packet from the given hop (\(i\)) in the given communication channel. The one-hop wired channel delay in CSMA-CD (\(\mathcal{D}_{iW1}\)) directly precedes the timestamp difference, whereas, for CSMA-CA, the total one-hop wireless channel delay (\(\mathcal{D}_{iW1}\)) can be obtained by adding \(t_{prop,i}+t_{pro,i}+t_{ack}\) to the preceding timestamp difference. We collected two sets of one-hop delay data sets consisting of 3,500,000 samples each for low-contention (\(\mathcal{C}<0.5\)) and high-contention scenarios (\(\mathcal{C}\geq 0.5\)). Pre-processing of the data sets--The wireless link lifetime data set collected cannot be directly fed into the DNN. The wireless link lifetime data set needs to be pre-processed before feeding into the DNN. As the first pre-processing step, from the collected data set, higher-order (order 2-8) values of differential displacements, differential velocities, differential accelerations, maximum displacement, etc. were computed. Both wireless link lifetime prediction and one-hop delay prediction data sets were normalized to be mapped in the range \([-1,1]\). Specifically, wireless link lifetimes, which spanned the range 0-10,000 us, and one-hop channel delays, which spanned the range 0-100,000 us, were normalized in the range \([-1,1]\). Finally, the data sets were split into train and test sets in the ratio of 4:1, which were subsequently used for model fitting and evaluation. Note that the test wireless link lifetime data consist of link lifetimes generated entirely from the status data collected from vehicular networks.