## 4 The Up/Down Mechanism of WiFi MAPs
### Algorithm Specification
Those readings were made during several sessions of 300 s leaving a 1 s interval between every pair of readings. Data were obtained without varying any configuration or traffic aspect. Vertical axis represents the following node (after node6) in the route; so \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Destination** & **Gateway** & **Genmask** & **Flags** & **Metric** & **Ref** & **Use IFace** \\ \hline
169.254.0 & 0.0.0.0 & 255.255.0.0 & U & 303 & 0 & 0 wlan0 \\
192.168.200.0 & 0.0.0.0 & 255.255.255.0 & U & 0 & 0 wlan0 \\
192.168.200.1 & 192.168.200.7 & 255.255.255.255 & UGH & 2 & 0 & 0 wlan0 \\
192.168.200.4 & 192.168.200.4 & 255.255.255.255 & UGH & 2 & 0 & 0 wlan0 \\
192.168.200.7 & 192.168.200.7 & 255.255.255.255 & UGH & 2 & 0 & 0 wlan0 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Most habitual kernel IP routing table for node6. Figure 14: Deployed static topology. that possible values were node7, node4 and directly node1. In view of Figure 15 we must highlight that the direct route from node6 to node1 was seldom chosen. We can detect that node6 uses as intermediate node mainly both the node7 and node4 to reach node1. Though both are valid, distance and other environmental conditions (radio channel instability and especially typical variation [50] of WiFi signal) cause OLSR to change dynamically the chosen route. As OLSR chose a single route among all the possibilities in order to establish connectivity between every pair of nodes, we considered that every node not participating in any route was susceptible for deactivating its wireless interface, so that it could contribute to power saving and avoid possible interferences. In order to check our test platform behaviour under interferences and the validity of this proposal, we have used several applications which generate some data traffic on the route node6-node1. We specifically used traffic which emulates the following two patterns:

* Connection-less Low Frequency Traffic (LFT) with Internet Control Message Protocol (ICMP). * Connection-oriented High volume and Frequency previously stored Traffic (HFT) with Secure Copy (scp). #### 6.1.1 Effect of WiFi Interface Deactivation

Figure 16 illustrates the result of one of the multiple tests performed in order to check what happens in node6 routing table when node7 (one of the intermediate nodes) interface was deactivated for 2 s in a 60 s session. Specifically, initial chosen route was node6-node7-node1. At instant \(t=10\) we deactivated node7 WiFi interface for 2 s and, after this time was elapsed, we reactivated node7 WiFi interface again until \(t=60\). We repeated this experiment changing the interface deactivation interval. Similarly we checked our proposal of implementing a state \"duty cycle\", i.e., cyclically repeated changes on the state of node from _MAP_ON_s_ to _IFACE_DOWN_s_. The obtained results prompt us to state that, for this cyclical process, small t\({}_{\text{DOWN}}\) values were not optimal, especially for medium or high data-rate traffic. This was due to OLSR definitively deletes that route from the table, because of its high variability. With an adequate selection of t\({}_{\text{DOWN}}\), the right rerouting (through node4) later undone (and recovered through node7) is evidenced in Figure 4. Obviously, our mechanism could be applied on any unused node that, as node4, was not participating in any route (or is being interfered); because OLSR could find a right substitute and even could reuse the inactive node whenever possible. Figure 15: Chosen intermediate node for route from node6 to node1. We can deduct from Figure 16 that node7 was initially in the chosen entry, as intermediate node (\"gateway\"), in node6 routing table for reaching node1. At \(t=10\), node7 changed to _IFACE_DOWN_s_ state. The cited routing table was not immediately modified, but it waited for an updating time related to OLSR configuration.