# Centralized Energy Prediction in Wireless Sensor Networks
## 5 Experiments and Results
### Prediction Mechanisms Performance Evaluation
#### 5.2.1 Results Analysis
Moreover, we observed that the Markov-PC reduces the control overhead in around 3% and 9% for 49, 64, and 81 nodes. On the other hand, the Markov-Node scheme increases the control overhead between 4.9% and 5.4% for topologies with 64 and 81 nodes. This increase is related to the control packets delivery rate, which is analyzed further below. Figure 5: Energy consumption of No-Prediction and Markov chain schemes: values in milijoules. Figure 6: Packets overhead of Markov chain and No-Prediction schemes: (**a**) shows the number of control packets and (**b**) shows the number of energy packets. On the other hand, using the Markov-Node scheme the delivery rate is below the No-Prediction scheme results in most cases. This is interesting since the Markov-Node scheme obtained the lowest energy packets overhead, with up to 40% less than the Markov-PC scheme. To understand this, we have to remember that in WSNs all packets share the same band and channel in some cases. Despite the Markov-Node obtained the lowest energy packets overhead, it also obtained the highest control packets overhead, which can affect the energy packets delivery rate. Furthermore, in the Markov-Node scheme all energy packets go upward (i.e., from sensor nodes to the controller) while in the Markov-PC scheme half of them go upward and the other half go downward (i.e., from the controller to sensor nodes). This helps to alleviate the congestion of the routes hence the delivery rate. The control packets delivery rate results also helped us to understand the increase in the control overhead using the Markov-Node scheme for 64 and 81 nodes noticed before (Figure 6a). In Figure 7a, we observed that for topologies from 16 to 49 nodes, the decrease is less than 1.25%, while for 64 and 81 nodes, the decrease is around 3% and 4%, which is a match to the increase in the control packets overhead. These metrics are related since the overhead is caused by the retransmissions for the lost packets. A lower delivery rate is a sign that more retransmissions were required. Figure 8a-c depicts the average delay for control, data, and energy packets, respectively. The first we observed is that the Markov-Node scheme obtained the highest delay in all the packet types, with a significant difference in the energy packet. In this case, the delay is from 65% to 122% higher than the delay in the No-Prediction scheme. Unlike the Markov-Node scheme, the Markov-PC scheme was able to maintain the control and data packets delay with respect to the No-Prediction scheme, but also it was able to reduce the delay up to 18% in the case of the energy packets. Figure 7: Total Delivery rate of Markov chain and No-Prediction schemes: (**a**) shows the delivery rate of control packets, (**b**) shows the delivery rate of the data packets, and (**c**) shows the delivery rate of energy packets. The increase in the delay using the Markov-Node scheme is caused by its processing overhead. As shown in Figure 9, the Markov-Node scheme doubles the processing overhead of the Markov-PC and No-Prediction schemes. This processing overhead delays energy packets forwarding. Furthermore, as energy and data updates have the same period, it also delays data packets forwarding. The Markov-PC and No-Prediction schemes have similar processing overheads. Thus, recalling the overhead and delivery rate results, despite the fact that the Markov-Node scheme reduces the number of energy packets in the network, the high delay caused by processing overhead could be affecting both energy packets and data packets delivery rate. Summarizing, the Markov-PC scheme overcomes the Markov-Node scheme in all the metrics evaluated, except for the energy packets overhead. This means, executing the prediction in the SDN controller we obtain better accurate prediction and delivery rate, and less energy consumption, control packets overhead, delay and sensor nodes' processing overhead.