## 4 Simulations
### Impact Analysis of Different Scheduling and Retransmission Techniques on EDETA-e Protocol
#### 4.2.1 Performance Evaluation  
In this section, impacts of the scheduling and retransmission techniques introduced in the previous section on EDETA-e are evaluated in order to compare them with the original TDMA approach in terms of delay, packet loss, energy consumption, and number of duplicate packets. EDETA-e with different scheduling and retransmission techniques was tested in three different deployment areas, _i.e._, (i) \(100\times 100\)\(m^{2}\); (ii) \(150\times 150\)\(m^{2}\); and (iii) \(200\times 200\)\(m^{2}\). In all of these deployments, 50, 100, and 200 nodes were randomly distributed, which result in 9 different scenarios to test. Each scenario has been simulated several times in order to achieve a confidence interval of \(\pm 3\%\) with a confidence level of 95%. All simulations were seeded using the number 1310572618 and each repetition was done advancing the run number [5]. The configuration phase of the EDETA-e protocol was set to last for 18,000 s and the nodes were configured to send their data periodically every 250 s. Each node woke up at its defined time interval and sent one byte with its collected data to its CH. After that, each CH had to aggregate these data and sent it to its parent in the tree structure until the data reached the sink. **TnoAck _vs._**DnoAck** In these experiments, the performance of a TDMA schedule and a delay-aware schedule, both of them without acknowledgement, were evaluated. Given the hierarchical nature of the protocol, one notes that the packet delay is heavily influenced by the network topology and since the transmission range used in the simulations is relatively small (100 m), the propagation delay is not the dominant factor of the packet delay in these simulations. As it can be seen from Figure 6(a), there are almost no significant differences in packet delay between the two alternatives. Figure 6: TnoAck and DnoAck comparison. (**a**) Delay; (**b**) Leaf nodes energy consumption; (**c**) CH nodes energy consumption. Also, as depicted in Figure 6(b), energy consumption of the leaf nodes is the same for the two cases since, in both alternatives, the nodes only wake up to send their data and then go back to sleep without waiting for any acknowledgement. On the other hand, Figure 6(c) shows that CHs consume less energy when they use the delay-aware schedule compared with when they use the TDMA schedule. This difference in energy consumption is produced at the initialization phase where, given the different scheduling algorithms, the initialization phase is slightly different in both alternatives. Tack _vs._DackIn these experiments, the performance of a TDMA schedule and a delay-aware schedule, both of them with acknowledgement and a scheduled backup transmission are evaluated. It can be seen from Figure 7(a) that the behavior of duplicate and lost packets are as expected. Since there is always a backup transmission scheduled right after the main transmission and the data packet error rate was set to be 10%, the packet lost rate is 1% in every scenario and the duplicate data packets is around 10%. Focusing on the delays, when acknowledgements and poll messages are introduced, the TDMA slots increase. On the other hand, the delay-aware schedule can optimize the data transmissions and by doing so, as depicted in Figure 7(b), it can reduce the delays. This reduction in the time spent for communication comes with a reduction on the energy consumption of the CHs. Figure 7(d) shows the energy consumption of the CHs during the first 100,000 s of simulation. As it can be seen, the delay-aware schedule consumes less energy than the TDMA schedule. On the other hand, leaf nodes do not get any benefit from the delay-aware scheduling, as they consume the same amount of energy in every scenario as depicted in Figure 7(c). This happens because the leaf nodes have to wait for the acknowledgement packet and in both cases it is immediately sent after the data packet arrives. Figure 7: TAck and DAck comparison.