# Fog-Based Two-Phase Event Monitoring and Data Gathering in Vehicular Sensor Networks
## 4 TPEG Framework
### Adaptive Data Upload  
Nodes that accept the event-checking command would transfer to deep sensing for a period of time, and a relatively larger size of data would be generated in HCS mode. The data are uploaded to the RSUs and then routed to the ITS system for event analysis as RSUs are inter-connected through wired networks or the Internet.  
A node would schedule its data for upload when it is within the coverage of an RSU. When it moves out of the RSU coverage, it would delay the data upload until the next opportunity of entering an RSU, or forward the data to an encountered vehicular node. For the ease of data upload and transmission, a piece of HCS data would be split into small segments. For a data segment, e.g., _ds_, there are three cases for it to be uploaded to the ITS system:  
1. When the node is within the coverage area of RSU, _ds_ is directly scheduled for uploading, which is denoted as: \[method(ds)=Upload,\ \ \text{if}\ \ rsu(s)=true;\] (8) where \(s\) is the node that holds _ds_ and \(rsu(s)\) returns _true_ if node \(s\) is within the coverage of an RSU.
2. When there is no RSU coverage or node-to-node connections, _ds_ is stored locally, and the upload is suppressed, which is denoted as: \[method(ds)=Delay,\ \ \text{if}\ \ rsu(s)=false;\ \&\ \ neighbor(s)=\phi\] (9) where \(neighbor(s)\) denotes the set of neighbors of node \(s\).
3. When a node moves out of the RSU coverage and encounters a neighboring node, it would decide its forwarding strategy based on the current node \(s\) and the encountered node _s'_. _ds_ might be forwarded to _s'_ or be stored at \(s\) and waits for other transmission opportunities. This is denoted as: \[method(ds)=\left\{\begin{array}{ll}Forward,&\text{if}\ \ fw(s,s^{\prime})=true\ \&\ rsu(s)=false\\ Suppress,&\text{if}\ \ fw(s,s^{\prime})=false\ \&\ rsu(s)=false\end{array}\right.\] (10) where \(fw(s,s^{\prime})\) denotes the feasibility of forwarding data from node \(s\) to _s'_. \(fw(s,s^{\prime})\) returns _true_ if the data are forwarded to _s'_, and node _s'_ would go into an RSU coverage area and upload the data before a predefined deadline. In more detail, \(fw(s,s^{\prime})\) is _true_ if it satisfies the following condition: \[et(s^{\prime})+ut(ds)\leq TC<et(s),\ \ \ ut(ds)<cd(s,s^{\prime})\] (11) Here, \(TC\) is the time constraint of data to be uploaded to the ITS system, \(et(s^{\prime})\) is the expected time interval for node _s'_ to enter an RSU coverage area and \(ut(ds)\) is the time duration of data uploading.  
which could be easily calculated by dividing the data size by the bandwidth: \(ut(ds)=\frac{|ds|}{bw}\). \(cd(s,s^{\prime})\) is the expected contact duration of node \(s\) and \(s^{\prime}\).  
Here, we borrow the idea of \"store-carry-forward\" in delay-tolerant networks [36] for the data uploading and forwarding. When a node, e.g., \(s^{\prime}\) receives data from another node, \(s^{\prime}\) is responsible for the data uploading. \(s^{\prime}\) might upload the data when it is within an RSU's coverage, or forward it to another node based on Equation (11). The calculation is mainly based on the expected time interval to reenter an RSU coverage area, as well as the expected contact duration between two encountered nodes, which are learned from the network meta-data and historical data. Each node would predict its time left to the next RSU (\(et(s)\)) based on their routes or historical trajectories, as well as contact histories with RSUs. The expected contact duration (\(cd(s,s^{\prime})\)) between two encountered nodes could also be estimated based on their direction, speed and trajectory records. These metadata and parameters are common input for the routing protocols for VANETs. Readers could refer to [2] for further discussions.