## 4 The Up/Down Mechanism of WiFi MAPs
### Algorithm Specification  
In Algorithms 1-4, we show the pseudocode of our proposal for tc and dcr, respectively, which concurrently run in every MAP. As regards tc, once an interference level threshold \(\theta\) is defined (line #1), this algorithm will continuously sense the last interference level \(\kappa\) (line #3) and query for two conditions  
Figure 5: Block diagram for our proposal. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Message Name** & **Arguments** & **Direction** & **Description** \\ \hline _GO\_IFACE\_DOWN_ & \(t_{DOWN}\), id\_MAP & dMAP \(\rightarrow\) neighbours & MAP is downable \\ \hline ACK & \(t_{DOWN}\), id\_MAP & neighbours \(\rightarrow\) dMAP & Neighbour accept dMAP \\  & & & change to _IFACE\_DOWN\_s_ \\ \hline NACK &
\begin{tabular}{c} Motive (reason for \\ refusal) \\ \end{tabular} & neighbours \(\rightarrow\) dMAP & Neighbour refuse dMAP \\  & & & change to _IFACE\_DOWN\_s_ \\ \hline DOWN & & dMAP \(\rightarrow\) neighbours & End of negotiation \\ \hline \hline \end{tabular}
\end{table} 
Table 3: List of messages the MAPs manage to set its wireless interface orderly down. (line #4): if \(\kappa\) exceeds the defined threshold \(\theta\) or the node is unused. According to these conditions, tc sends asynchronously the last MAP previous-downability value Dp to dcr (line #9). It is possible for Dp to change while dcr processes it, but we mainly expect our algorithms to handle properly dMAPs interfered or unused for a long time. ```
1:Define \(\theta\)
2:Repeat
3:Sense (\(\kappa\))
4:if (\(\kappa\) > \(\theta\) or MAP is unused) then
5:Dp = true
6:else
7:Dp = false
8:endif
9:Send (Dp) to dcr
10:Forever
```  
**Algorithm 1**Basic Pseudocode of tc  
Simultaneously, the dcr main process (Algorithm 2) will continuously update the reference starting time \(t_{o}\) (lines #3-#4) and, in the case that MAP was in _MAP_ON_s_ state (lines #5-#6), two timed threads will be launched for \(t_{o}+t_{UP}\) seconds (line #7). Both threads will be stopped after the selected time, and a definitive downability value D will be returned, according to the previous downability Dp (tc line #9). If MAP is definitively downable, its state will be changed to _IFACE_DOWN_s_ and its wireless interface will be deactivated (lines #8-#12). Finally, in the case that MAP was in _IFACE_DOWN_s_ state (line #12), it will wait for \(t_{o}+t_{DOWN}\) seconds (line #13), will activate its wireless interface (line #14), and will change its state to _MAP_ON_s_ state (line #15). ```
1:Define MAP_state = _MAP_ON_s_, \(t_{UP}\), \(t_{DOWN}\)
2:Repeat
3:Read (\(t\))
4:\(t_{o}=t\)
5:Switch (MAP_state)
6:case_MAP_ON_s_:
7:timedThread (\(t_{o}+t_{UP}\), dMAP_proc, neighbour_proc)
8:if (D) then
9:set Wireless Interface DOWN
10:MAP_state = _IFACE_DOWN_s_
11:endif
12:case_IFACE_DOWN_s_:
13:Wait (\(t_{o}+t_{DOWN}\))
14:set Wireless Interface UP
15:MAP_state = _MAP_ON_s_
16:endSwitch
17:Forever
```  
**Algorithm 2**Basic Pseudocode of the dcr Main Process  
Algorithm 3 shows our proposed pseudocode for dcr dMAP_proc process launched from dcr main process line #7. It always initializes MAP downability D to false which will be the default value returned to dcr main process when either the rest of dMAP_proc does not modify this value, or the thread is stopped by the programmed timer in dcr main process line #7. The former condition is tested after receiving the last Dp from tc (lines #2-#3). If this previous-downability is met, the MAP will send a _GO_IFACE_DOWN_ message to its neighbours (line #4) and will wait for receiving their confirmation or a timeout (line #5). Then, if an ACK is received from all neighbours (line #6), will send a DOWNmessage to its neighbours (line #7), will update its \(t_{\text{DOWN}}\) timer as the minimum it received from its neighbours (line #8), and will return a true value for D (line #9).