## 3 Testbed Deployment
### Software Description  
The initial WSN deployment operated using XMesh, Crossbow's mesh routing protocol. XMesh provides a self-healing and self-organizing networking service [39]. The application code for XMesh is compiled specifically for a more architecture (e.g., MicaZ) and sensor board (e.g., MDA300). Arguments for programming the transmission frequency and node/group identifiers are also available. XMesh offers three power modes, which are assigned during the program compilation, including high power (HP), low power (LP), and extended low power (ELP). The ASWP testbed deployment uses the LP mode, where motes power off non-essential electronics when idle. Motes in LP mode can still forward messages from neighboring motes unlike motes programmed in ELP. For MicaZ and IRIS motes, XMesh does not support time synchronization of messages. Therefore, all message transmissions are made asynchronously. XMesh generates three basic types of application packets, which are transmitted along the network and stored at the WSN gateway:  
* _Sensor data_: correspond to the actual sensor readings of the motes and depends on the data acquisition board (MDA300, in this case). This packet type was configured with a sampling interval of 15 min. * _Node health data_: contain node-level statistics that include the following accumulated counters: node health data packets generated at the node, total number of packets generated at the node (including all three packet types), number of packets forwarded from other nodes, number of retransmissions, number of packets dropped at the node, path cost to the base station (e.g., node cost), and information about the link connecting to the parent node. Counters for node health data packets and node generated packets reflect unique packet identifiers from the point of view of the WSN application; therefore, they do not include packet retransmissions. * _Neighbor health data_: report the information of up to five neighbor nodes including their link information and path cost values. Neighbor health packets and node health packets are sent alternatively, one type after the other, and they are defined with a single interval named Health Update Interval (HUI). The HUI is set by default to 10 min, thus the effective transmission for each health data type is twice the initial HUI: 20 min. XMesh's multi-hop routing is based on the Minimum Transmission (MT) cost metric aiming to minimize the total energy consumed to transmit a packet to the base station [39]. In order to send a packet, each node always selects the neighbor with the minimum cost (denoted as parent node). There are two costs defined in XMesh: one associated to a link and one associated to a node. A node computes the link cost to each of its neighbors and also broadcasts its own node cost. As part of an iterative process, started by the base station with node cost equal to zero, each node receives its neighbors' node cost and adds to it the corresponding link cost. Based on these values, the node selects a parent node and updates its own node cost to broadcast it again to its neighbors. From this perspective, it can be seen that XMesh works in a similar way as other mechanisms based on the EstimatedTransmission Number (ETX) given that the node cost, or path cost as referred to in the node health data, is proportional to this value [40]. Node costs and all routing information are exchanged periodically using Route Update (RU) messages and the frequency of the message exchange is defined by a fixed Route Update Interval (RUI). For this deployment, the RUI was initially set to 36 s during the period of the Sluggo gateway and after July 2011 (_i.e._, the change to the Linux gateway, see Figure 4), it was increased to 128 s for reducing the routing traffic in the network. In terms of quality of service (QoS), XMesh specifies an end-to-end acknowledgement in addition to the data link layer acknowledgement [39].