## 4 Network Performance
### XMesh  
An analysis of the network behavior is presented, which aims to address the key points previously mentioned regarding the quality of the collected data. For the analysis of the application based on \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Data sampling interval & 15 min \\ Initial data sampling interval & 1 min for the first 10 packets \\ Summary packet interval & 30 min \\ Radio channel & 26 \\ Transmission power & Maximum \\ Low-power-listening (LPL) sleep interval & 1 s \\ Maximum CTP retransmissions & 7 attempts \\ Maximum Trickle timer interval & 1 h \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Summary of non-default parameters configured in the CTP-based WSN application deployed at the ASWP testbed. XMesh, the selected dataset starts on August 2011, after the Linux gateway was deployed, and continues until August 2012, covering one year of operation (see Figure 4). During this year the testbed was exposed to different seasons and weather allowing a comprehensive network evaluation. The dataset contains more than 900,000 packets including sensor data, node health data and neighbor health data, divided into two periods to examine the effect of deploying the two additional IRIS motes in the testbed. Table 3 lists the evaluation periods: period 1 (P1) and period 2 (P2), before and after the additional IRIS motes, respectively. Likewise, shorter time periods of one month of operation were selected for each larger period to account for short-term performance, in which the effect of the network maintenance is reduced. Selected sub-periods correspond to the month with the best performance and highest number of connected nodes. Table 3 also presents the maximum, average, and minimum daily connected nodes in the network for each time period and sub-period. XMesh defines the node health packet counter, which works as an application-layer sequence number for this packet type. This 16-bit counter initially starts at one and increments after every new generated node health packet, allowing for up to 65,535 packets to be identified. In this case, the effective collection rate for each type of health packet (_i.e._, node health and neighbor health) is 20 min; then, the sequence number would be enough to consider all consecutive packets within a period larger than 900 days, far exceeding the battery life of motes operating without energy-harvesting mechanisms. Using the node health packet counter, it was found that around 3% to 4% of the received packets corresponded to duplicate packets. These results show the need to include an initial pre-processing stage for identifying and removing these packets from datasets. However, since node health is the only packet type in XMesh that includes a counter field to uniquely identify each packet, it was necessary to devise an algorithm that identifies and removes duplicates for the sensor and neighbor health data. The main idea behind our devised duplication deletion algorithm is that by comparing the content of two received packets from the same node, it can be identified if one of them was duplicated with high accuracy, given that for each node it is unlikely to obtain all sensor readings with exactly the same values. With this idea, any two packets from the same origin node can be compared and duplicates can be identified. Additional assumptions were introduced in this context. First, it is assumed that the sampling period, represented as \(T\), is large enough so that each packet is either delivered or dropped before the next packet