# Fog-Based Two-Phase Event Monitoring and Data Gathering in Vehicular Sensor Networks
## 4 TPEG Framework
### Event Checking and Node Selection  
Vehicular nodes send their readings to the RSU, so the RSU is able to calculate the weight of the received readings. For a set of readings \(D\), the weight is defined as \(w(D)\):  
\[w(D)=\frac{\sum_{d\in D}w(d)}{|D|} \tag{5}\]  
Given event \(e\), the weight of data \(w(D,e)\) is denoted as \(w(D)\) for simplicity. If the weight for a specific event within the time window is greater than threshold \(\tau_{1}\):  
\[w(D)\geq\tau_{1} \tag{6}\]  
the RSU would broadcast an event-checking procedure to all nodes within its covered area. Here, we adopt a threshold-based event-checking strategy. If a threshold is broken, this means an event is likely to occur on the road, and further checking is required. Threshold \(\tau_{0}\) and \(\tau_{1}\) are two key parameters for our algorithm, and they strike a balance between the number of uploaded readings and the cost of event-checking procedures. In Section 4.5, we will further discuss the setting and adjustment of the parameters.  
When an RSU initiates an event-checking procedure, it periodically broadcasts an \"event-checking command\" within its covered area, where some nodes passing by would transfer to HCS mode. However, working in HCS mode is expensive. It needs more computing and energy resources to sense more accurate data and also costs more in transmissions to upload the data. Therefore, it is crucial for TPEG to selectively pick up a part of the nodes passing-by to work on this mode.  
A node creates a timer when it receives an event-checking command from an RSU for the first time. When the timer is fired, the node transfers to HCS mode. The timer is denoted \(tm(\beta)\), where \(\beta\) is the delayed interval and defined as follows:  
\[\beta=\left\{\begin{array}{ll}BI*\frac{\widetilde{t}}{t-t},&t\leq\widetilde {t}\\ BI*\delta,&t>\widetilde{t}\end{array}\right.\quad BI<\widetilde{t},\ \ \delta\in(0,1) \tag{7}\]  
where \(BI\) denotes the time interval of the broadcasting of event-checking messages at RSU, \(\widetilde{t}\) is the average duration of a node moving through the RSU coverage area, \(t\) is the elapsed time when a node enters the coverage area and \(\delta\) is a random number. The average duration \(\widetilde{t}\) could be derived by the historical duration of nodes passing by a specific RSU. Nodes enter the RSU covered area in sequential order, and the node that newly enter the area would have the smallest delay interval according to Equation (7). It would have its timer \(tm\) fired and then accept the command of working in HCS mode with less delay. Furthermore, the broadcasting interval \(BI\) is set to be smaller than the average pass duration \(\widetilde{t}\), so when a node goes through the RSU coverage area, it would receive at least one broadcasting message. In extreme cases when the elapsed time is greater than \(\widetilde{t}\), e.g., traffic jam, the delay \(\beta\) would be randomly set, and nodes are randomly selected to work in HCS mode. The interval of the timer is set according to \(BI\), and it could be tuned to make the timer smaller to avoid the case that vehicles leave the coverage area of an RSU without vehicles in HCS mode. Moreover, we are assuming a urban scenario where vehicles do no travel so fast.  
If a node accepts the event-checking command, it would transfer to HCS mode and send an accept-HCS message to the RSU, where other nodes overhearing this message would cancel their timers. Therefore, only a small part of the nodes would join the event-checking procedure, and some nodes would still work in LCS mode. For the RSU, it periodically broadcasts the event-checking command if it does not receive an accept-HCS command from passing-by nodes. When it receives the accept-HCS message, it would broadcast an on-checking command, and other nodes that receive this message would cancel their timers for accepting the event-checking command.