## 3 Testbed Deployment
### Software Description
In this QoS mechanism, the base station sends an acknowledgement back to the origin node after receiving a packet and by default it is only applied to node health packets. The commercial WSN routing protocol was replaced at the end of July 2013 by an open source approach based on the TinyOS 2.1.2 implementation of the Collection Tree Protocol (CTP) [41, 42]. CTP uses the ETX as cost metric and, like XMesh, attempts to build a minimum cost tree within the network, relying on control packets for establishing the network topology. However, since the source code of XMesh is not available, it is not possible to confirm further details about its implementation. Still, a significant difference between these two approaches is that control traffic in XMesh does not adapt to network conditions and thus it always sends routing packets at a fixed rate, while CTP adjusts the transmission of control traffic for a faster response to specific topology changes. The CTP-based application defines two packet types: _data packets_ and _summary packets_. Data packets include all sensor readings and health statistics from each node, such as the total number of generated packets, forwarded packets, retransmissions, and dropped packets. Similar to node health packets in XMesh, the counter of generated packets in CTP reflects unique data packets from the point of view of the WSN application. Summary packets are defined to include further instrumentation information regarding ETX values (link and path ETX) and control traffic. In addition, the application was configured in two different versions for relay and regular nodes, respectively. Relay nodes do not have external sensors and are flexible in their location. They are mainly deployed for improving network connectivity and providing alternative routes; therefore, all components controlling the ADCs on the MDA300 driver were disabled in these nodes for a more energy-efficient operation. Regular nodes do have external sensors attached through the data acquisition board, and thus, all components in the MDA300 driver are enabled. Moreover, the number of active ADCs can be customized for each WSN mote, according to their predefined configuration (e.g., regular nodes with 3, 5, or 6 external sensors). The CTP-based WSN application was configured to periodically sample data packets every 15 min and summary packets every 30 min using TinyOS asynchronous low-power listening (LPL). Based on the experience with XMesh, it was noticed that waiting a complete cycle was ineffective for knowing if a mote boots correctly. Therefore, a faster way was required for receiving initial feedback from motes to help identify common problems (e.g., connection errors, battery problems, forgetting to turn the motes on, or defective hardware). Two mechanisms were included in the WSN application for supporting deployment tasks. First, motes were configured to blink their LEDs after booting. This simple mechanism helps to discover several common problems and allows the user to confirm if the WSN application started running in the mote. Verification can be done on-site before closing mote enclosures. After the LEDs blink to confirm their operation, they are automatically disabled to save battery power. The second mechanism uses a faster sampling rate for the first data packets. The initial experiments with CTP showed that WSN nodes are able join the network in a very short time; therefore, by using a faster sampling rate (e.g., one minute) for the first ten packets, initial feedback (e.g., node parent, battery voltage, and sensor data) can be monitored through the WSN management system's web interface. This helps to solve additional common problems such as using defective batteries or using the wrong version of a WSN application. Table 2 summarizes the parameters configured in the CTP-based WSN application deployed at the ASWP testbed. All other parameters not listed in the table use the default values.