# Improving Route Selections in ZigBee Wireless Sensor Networks
## 4 Simulation Tool to Evaluate Link Cost Estimation Procedures
### Parameters Common to All Simulations  
In the upcoming sections, we describe simulations used to evaluate the performance of the LS-based, the LQI-based, and our proposed procedure in various scenarios. All of such simulations will use the configurations described on this section. Regarding the application layer, a node \(z_{i}\) that connects to a sensor (e.g., nodes 3, 4, and 5 in Figure 1) generates application messages periodically, with an interarrival time uniformly distributed between 0 and a maximum interarrival time, which we vary to generate different averages of packets generated per second. Each application message (sensor data) contains 12 bytes, which are encapsulated by an 8-byte APS header, and subsequently an 8-byte network header, before being sent to the MAC layer (total of 28 bytes). Application messages are sent using the APS reliable data transfer service; i.e., when receiving the application message, node 0's APS layer generates an 8-byte acknowledgment (APS-ACK) frame towards the sending node. Nodes always wait for the APS-ACK message to arrive before sending a new message. If the APS-ACK message does not arrive after a timeout period of 800 ms, the APS layer retransmits the message up to three times. If the APS-ACK message has not arrived and a new message arrives, the new message is buffered. If the buffer is already full, the message is discarded. Regarding the network layer, we considered that all ZigBee nodes were full-functioning devices able to participate in routing procedures. All ZigBee nodes generate LS messages every one second with an added random jitter uniformly distributed between 10 and 40 ms, and in all examples, we considered that node 0 was the concentrator node and nodes used the M2O routing algorithm to reach the concentrator. The concentrator was configured to send RREQ messages every 10 s; and the concentrator radius was configured such that the RREQ message was rebroadcast by at most one hop in all but the two-hop scenario of Section 7.1.3, in which the radius was configured for two hops. All the link cost estimation procedures used an averaging window of \(T_{avg}=81\) s.  
Regarding the IEEE 802.15.4 MAC and physical layers, all simulations used the default parameters of the ns3 model [52]. Among the MAC parameters, we highlight that the CSMA procedure was configured to retransmit packets up to three times before dropping the packet. Among the physical parameters, we highlight that transceivers required 192 microseconds to switch between receive and transmit modes, and vice-versa. All ZigBee devices were configured to transmit with 0 dBm power and operate at channel 11, centered at 2.405 GHz. Regarding simulations with WiFi IEEE 802.11 stations, the WiFi access point was configured to have a server that transmitted an application packet of 972 bytes to each of two WiFi stations every \(T_{WiFi}=972*8/R_{WiFi}\) s, where \(R_{WiFi}\) s the application data throughput that we varied to generate different traffic loads. The WiFi application data was sent over UDP/IPv4. The IEEE 802.11 MAC layer exchanged RTS/CTS messages before sending the data, and we considered WiFi devices using IEEE 802.11n in Greenfield (HT) mode, with a modulation and coding scheme (MCS) level 0 with 800 ns guard spacing and occupying a 20 MHz bandwidth channel, which results in 6.5 Mbps PHY transmission rate. Considering the transmission to the two stations and the time to transmit the RTS/CTS and the MAC ACK, WiFi stations occupy the channel for at least 2.94 ms every \(T_{WiFi}\) seconds, which means that the fraction of time in which WiFi transmissions occupy the channel is at least \(0.00294/T_{WiFi}\). The WiFi devices transmit at 0 dBm and the 20 MHz channel is centered at 2.412 GHz, which overlaps with ZigBee transmissions centered at 2.405 GHz. Simulations are performed for 400 s and results are collected from the last 300 s of the simulation in ZigBee-only scenarios.