## 4 Cross Layer Adaptation of Check Intervals
### Tree-Based Topologies  
Tree-based topologies are widely used in many WSN applications. In a tree topology each forwarding node has a number of children which is not necessarily the same for all of the nodes. The intermediate nodes forward all the incoming packets from their children to the single parent to reach the destination node. In many WSN applications which use a collection tree, nodes typically use filters to select the sensed data that needs to be transmitted to the sink. For example, in Directed Diffusion, all nodes sample the environment at the same given rate in order to detect a specific event. When a node detects the event, it starts transmitting any relevant data to the sink at a rate that corresponds to the sampling period. This means that in general not all the nodes produce data, but rather a subset of them, which we call sources. The sources emit data that travels along a path in the tree up to the sink (which in these cases is the root of the tree). From the point of view of the individual source, the data traveling along the path to the sink behaves as in the case of linear topologies. However, packets from different sources generally meet at some intermediate nodes in the tree and from that point on they follow the same path. Consider the case in which a relay node \(i_{k}\) receives data produced by different sources that can be either \(i_{k}\)'s direct children or nodes in the subtree rooted at \(i_{k}\). All sources emit packets according to the same duty cycle, and therefore, the same period. If the packets emitted by the sources arrive at \(i_{k}\) at different times, for instance if the sources are at different depths in the tree, the network behaves similar to a linear topology. If the packets from two or more sources arrive at \(i_{k}\) at instances close in time they may experience additional delays due to channel contention. In these cases, the delay defined at \(i_{k}\) should be configured to have \(i_{k}\) ready for the fastest packet. The delay of the node will therefore be defined by the same formula as in the case of linear topologies: \(\gamma(i_{k})=p\times\tau_{check}/100\). It is important to remember that, after a packet is received by \(i_{k}\) there may be others that are delayed due to channel contention. For this reason \(i_{k}\) must keep its radio on for a period after receiving a packet, a behavior already present in BoX-MAC. Algorithm 1 shows the pseudo-code for CLAC. ```
1:\(\gamma(i_{k})=p\times\tau_{check}/100\)
2:for\(i_{k}\) in \(i_{k}\)do
3:\(i_{k}\) = \(p\times\tau_{check}/100\)
4:for\(i_{k}\) in \(i_{k}\)do
5:\(i_{k}\) = \(p\times\tau_{check}/100\)
6:for\(i_{k}\) in \(i_{k}\)do
7:\(i


```
\(p\) # MAC layer info \(DC\) # MAC layer info  Compute \(t\_check\)=DUTY_ON_TIME \(\times\) (100-\(DC\)) / \(DC\)  Obtain all \(routes\) crossing node \(i\) # Routing layer info D(i)=\(\infty\) for all (\(r\in routes\)) do  Compute \(order(i)\) in \(r(j,k)\), \(j\)=source,\(k\)=sink  Compute delay \(D_{r}(i)\)=\(order(i)\times p\times t\_check/100\)  Compute \(D(i)\) = \(min(D_{r}(i),D(i))\) loop  Compute \(t\_new\_check\)= \(t\_check\) + \(D(i)\)
```

**Algorithm 1** CLAC algorithm

## 5 Evaluation

We implemented CLAC on top of TinyOS [4] and we used available implementations of CTP and BoX-MAC-2 as the routing and MAC protocols. We also implemented an application where each node generates a 40-byte length data packet at constant intervals of 10 seconds and forwards incoming packets from children to the sink. This application is implemented on top of CLAC and uses the routing and MAC information to adapt the check intervals as discussed in this paper. We developed CLAC specifically for the MicaZ [36] platform and we tested it on linear and tree-based topologies, for which we evaluated networks of different sizes and densities. To represent meaningful variations in the node activity we configured the application with different duty cycles.