## 3 Data Routing Approaches in WSNs
### Delay-Aware Approaches
#### 3.2.1 Hard Delay-Aware Approaches  
The protocols in [14] and [64] are suitable for time-critical applications. In Threshold-Sensitive Energy Efficient Sensor Network Protocol (TEEN), the nodes sense the medium repeatedly, but data dissemination is done less frequently. A cluster head transmits a hard and a soft threshold to its cluster's members. A hard threshold enables the nodes to transmit their data only when it is in the required range of interest. Thus, this threshold can reduce a number of redundant and unnecessary messages in the network. On the other hand, soft threshold presents the changes in the sensed values. It  
Figure 5: Example of virtual grid in GAF. allows the nodes to sleep in their idle times and wake up when the changes are greater than soft threshold. Therefore, sensor nodes can conserve considerable energy in their idle times. But the main problem of this approach is dependability of the algorithm on these thresholds. When there is no threshold, there is no communication between the nodes either. Furthermore, Adaptive Periodic TEEN (APTEEN) improved TEEN by using a TDMA like scheduling in which when a node does not sense data for a specific period of time; it will be obliged to sense and transmit data. In this approach, only the nodes which their sensed data are equal or greater than hard threshold can send their data. Moreover, such data is transmitted only when the value of that attribute differs by an amount at or beyond soft threshold. Furthermore, APTEEN considers a threshold for transmission, too. If the nodes do not transmit their data up to this threshold, they are forced to sense and retransmit the data. However, the main drawback of this approach is the complexity which is added to the basic function of the TEEN approach. Emergency-Adaptive Routing (EAR) which is proposed by authors in [48] is a real-time routing protocol in WSN for building fire emergencies and other similar applications. EAR computes the delay in its routing mechanism for selecting the next hop. Moreover, end-to-end delay from nodes to sink is calculated according to the delay of each hop. In this approach, each node can be in four specific states: _Safe_ which means there is no fire, _Infire_ when the nodes discover fire, _Lowsafe_ states that the node is one hop away from the _Infire_ node and finally _Unsafe_ which illustrates the malfunctioning or failure of the node. Furthermore, there is a _State_ which is used by the nodes to notify their current situation. When a node detects fire, it broadcasts the state of _Infire_ to notify the occurrence of fire. The nodes which receive this message, mark themselves _Lowsafe_ and propagate their status. Also, when a node finds that its residual energy is going to be finished, it broadcasts a message with the state of _Unsafe_ to inform other nodes that it may be failed in the near future. Figure 6 presents the state transition diagram of each node in EAR. In the initialization phase of EAR, it is assumed that sinks are not prone to failure. After deployment, an initialization message is broadcasted to the nodes containing the _height_ parameter which demonstrates the hop count of the nodes to the sink. Each node upon receiving the packet, increments the _height_ and forwards it to the next hop. In this process, the end-to-end delay which is considered the summation of the delays of each hop is calculated for path selection. _delay (sink, i)_ as the delay of transmission from a node to sink is approximated as below:  
\[\textit{delay (sink, i)}=\sum_{n=1}^{h}Avg\textit{delay}=\sum_{n=1}^{h} \left(T_{c}+T_{t}+T_{q}\right)*R\]  
In the formula, \(n\) is the hop count from the sink to node \(i\), _Tc_ is the time taken in each hop to obtain the wireless channel with carrier sense delay and back-off delay. _It_ is the time to transmit a packet which determined by channel bandwidth, packet length and the adopted coding scheme. _Tq_ is the queuing delay which depends on the traffic load, and \(R\) is the retransmission count.