## 6 Architecture Measurements  
### Test Bench  
In order to measure our proposal, an application software has been developed, using Java programming, to run and test the designed protocol and the architecture performance. We programmed CH and CM functionalities. The application allows configuring some parameters such as the maximum number of connections, maximum distance, type of node, node position, keepalive time and so on). The application calculates \(\lambda\) and \(\delta\) parameters internally. The MAC protocol used to measure the control messages was CSMA/CA in the frequency of 2.4 GHz. There was one laptop with a high gain antenna configured in a monitor mode that captured all data of the test bench using a sniffer application.  
The test bench is formed by 16 Multisensors [33] in an open air environment. Because we needed a multisensory with high computation capacities, we used the Linksys WRT54 GL router, from Cisco Systems inc., as the core controller. It is an embedded system that that allows us to connect several physical sensors in its serial interfaces. The Linksys WRT54G version 4.0 has a 200 Mhz processor, 4 Mbytes of flash memory, 16 Mbytes of RAM at 100 MHz clock rate and 256 Bytes prefetch cache. The Wireless interface accomplishes IEEE 802.11g at 54 Mbps and IEEE 802.11b at 11 Mbps standards. Its transmitting power is 18 dBm. It allows us to cover large distances.  
The position of the multisensor is shown in Table 2a. X and Y values are in meters. It is one of the most representative test benches performed because it allows showing several operation procedures as they will be seen later. The maximum number of connections has been fixed to a value of four. The maximum distance to establish a connection with a CM of the same type was 100 meters. The keepalive time chosen was 30 seconds (it avoids too much energy consumption because of the number of messages sent and, if larger times are conFigured, nodes will discover the failures too late) and the dead time chosen was 60 seconds (twice the keepalive time). Sixty seconds seems to be enough time to know the node has failed. There are four types of nodes for each group. In order to make the test bench more understandable, CH nodes were CMs of the same type, but it does not affect to the system because they have to establish connections as CH and as CMs (the last ones are only established if the distance is lower than 100 meters, so in this case there will be none for type a). Then, the nodes are started in a  
Figure 15: Bandwidth cost of the messages (backup CH message has two entries).  
sequential order every 10 seconds. This order is shown in Table 2a. Table 2b shows the connections that have been obtained for every node when the network has converged.  
The topology obtained for the test bench and the physical position of the surrogates are shown in Figure 16.  
\begin{table}
\begin{tabular}{c c c c} \hline
**Node number** & **Role** & **Connections with CH** & **Connections with CM** \\ \hline
1 & CH & 3, 7, 9 & 2, 5, 15 \\
2 & CM & 1 & 4 \\
3 & CH & 1, 7, 9 & 4, 6, 11 \\
4 & CM & 3 & 2, 8 \\
5 & CM & 1 & 6 \\
6 & CM & 3 & 5, 10 \\
7 & CH & 1, 3, 9 & 8, 10, 14 \\
8 & CM & 7 & 4, 12 \\
9 & CH & 1, 3, 7 & 12, 13, 16 \\
10 & CM & 7 & 6, 13 \\
11 & CM & 3 & 14, 16 \\
12 & CM & 9 & 8 \\
13 & CM & 9 & 10 \\
14 & CM & 7 & 11, 15 \\
15 & CM & 1 & 14 \\
16 & CM & 9 & 11 \\ \hline \end{tabular}
\end{table}
Table 2a: Nodes’ positions.  
CHs have connections with other CHs (lines formed by black points). CMs have a connection with the CH of its cluster (lines formed by red points) and with the selected CMs of the other clusters (solid lines in different tonalities of grey and in black). We have implemented the positions using only two dimensions, but our application supports three dimensions.