## 7 Testing  
In order to validate the proposed framework and determine if physical features are fit for the purpose of modelling the response of a network a number of experiments were undertaken. The purpose of the experiments was to provide data to build a network response model for a number of different communication solutions. The goal was to present an easy form for comparison between the communication solutions. The response of the network is measured in terms of four evaluation metrics: reliability, latency, efficiency and stability. Reliability is the measure of how many sent packets get received at the root as a percentage. This is calculated as the ratio of the total number of packets received (removing duplicates) at the root node over the total number of packets generated (not including forwarded packets) across the network during the experiment. Latency is an average over each node in the network. The nodes latency is the average time a packet, originating from that node, takes to reach the root. Efficiency is measured as the total number packets sent through the network during the experiment. This includes all application packets forwarded through the networks as  
Figure 9: Single binary and multiple binary program solutions. (**a**) Program binary containing multiple communication solutions; (**b**) Multiple program binaries containing a single communication solution each. well as packet retransmissions. The number of packets sent is used as a proxy for energy use within the network as the energy consumed by transmitting and receiving packets far exceeds other energy considerations [39]. An energy efficient routing protocol will route a packet to the intended destination with the fewest number of packets. Stability is measured as the number of route changes occurring in the network. This metric is often described as route churn. The metric is calculated as the total number of route changes made in the network over the duration of the experiment. Experiments were conducted on the TinyOS SIMulator (TOSSIM) simulator [5] with TinyOS [40] used as the sensor platform for each. The simulations use an array of micaz nodes. TOSSIM uses noise modelling with Closest-fit Pattern Matching (CPM) [41] to model the packet reception rates at receiving nodes. The links can be varied by introducing increasing levels of noise on the channel. A noise trace derived from empirical testing can be introduced to simulate dynamic link conditions. Each experiment was run in simulation for a network time of one hour with each node in the network sends a packet to the root each minute. This replicates a simple BEMS scenario for building environment monitoring. This provides the basis of many BEMS applications. Each experiment is conducted on a distinct topology generated for use within the TOSSIM simulator. Nodes in the simulated network are randomly distributed within a unit square with each node having at least one usable link to another node. This is only the case, however, in perfect channel conditions. Introducing noise to the network may leave nodes with longer links unconnected to the network due to an inability to send packets to it's closest neighbour. The basestation where the data packets are collected is situated on a corner within the unit square. The area of the unit square and number of nodes in the network are varied to assess a range of network densities, sizes and scale. While the network is composed of homogeneous nodes the network conditions for each experiment will vary due to the noise profile in the network. The RPL routing protocol was used as the routing protocol for all experiments. RPL is a protocol that is currently under standardisation review. It is important to integrate any proposed standardised evaluation procedure within current standardisation efforts. RPL is claimed to have significant use cases within the BEMS application scenario and is well placed within the community to make a significant contribution to BEMS.