# An Optimization Framework for Data Collection in Software Defined Vehicular Networks
## 3 Materials and Methods
### Formulating Factors Affecting Data Collection  
Several factors governing the data collection process can be identified. 1. **Update/Data collection frequency (_f_)--As vehicle status and sensor measurements are highly dynamic in a vehicular network, data have to be collected periodically at a sufficient frequency such that collected information depicts the current dynamics of the vehicle. If the frequency is too low, the knowledge generated regarding the vehicular network will be less valuable, as it has been generated for an older version of the vehicular environment. However, this frequency cannot be so high since it can cause an extra communication burden in terms of bandwidth and cost, and can result in congesting the communication channels. However, in such a case, the validity (accuracy) of the generated knowledge is higher. Therefore, this tradeoff has to be properly managed and optimized. Data content (\(\mathcal{L}\))--The control plane must choose from the vehicle status and sensor measurement, and collect data which are only essential for knowledge generation. For \(j^{th}\) node, we represent node's status data payload size using \(\mathcal{L}_{st,j}\) and its sensor data payload size using \(\mathcal{L}_{sc,j}\). Here, \(p_{j}\) represents whether node \(j\) collects status data or not as given in Equation (1). \[p_{j}=\left\{ \begin{array}{ll}1;&if\;\;node\;j\;\text{collects\;status\;data} \\ 0;&\;\text{otherwise}\end{array} \right. \tag{1}\]  
Similarly, we use \(q_{j}\) to represent the state of a collection of sensor data from the \(j^{th}\) node as given in Equation (2). \[q_{j}=\left\{ \begin{array}{ll}1;&if\;\;node\;j\;\text{collects\;sensor\;data} \\ 0;&\;\text{otherwise}\end{array} \right. \tag{2}\]  
The collection of unwanted data can cost a waste of communication bandwidth and can exhaust the system. The decision to use whether the mined data from an OBU is directly sent to the control plane or not will depend on the SDVN architecture. 3. **The number of participating nodes as agents (\(k\))--** One trivial way is to involve all the vehicular nodes in the data collection process where redundant information may be collected by the centralized control plane. So, such a scenario is not the optimum way to collect data as such a system will increase the vehicular network's communication cost and overall latency of the system. In other words, all vehicles in the vehicular network may not be required to send or receive data. Consider a system that only collects vehicle status. In such a case, when there is a group of vehicles (a vehicle and its one-hop neighbors), the data can be collected from one agent of the vehicle group. This will reduce the communication overhead as the agent collects information broadcast from its one-hop neighbors and transmit it to the centralized controller along with its own data encapsulated in a single header. Furthermore, the number of participating agents is also SDVN architecture dependent. For a group of vehicles of the hybrid architecture, one agent needs to collect and send data to the centralized control plane. However, for the distributed architecture, there are no agents for data transmission, whereas, for the centralized architecture, all nodes act as agents. 4. **The delay (\(\mathcal{D}\))--** Some vehicular network applications such as safety (required latency < 100 ms) are delay sensitive [40]. The information should be collected such that the total delay does not exceed the required standards. In a multi-hop scenario, the total delay is the addition of delay at each hop. The total delay (\(\mathcal{D}\)) in a single hop can be calculated as in Equation (3) [41]. \[\mathcal{D}=t_{trans}+t_{q}+t_{cont}+t_{proc}+t_{prop} \tag{3}\]  
In Equation (3), \(t_{trans}\) is the transmission delay, \(t_{q}\) is the queuing delay, \(t_{cont}\) is the contention delay, \(t_{proc}\) is the processing delay, and \(t_{prop}\) is the propagation delay. We calculate the delay corresponding to each term as in work [41].