## 6 Performance Evaluation
### Network Lifetime  
In this section, we evaluate the impact of our proposed sleep scheduler on the network lifetime. Firstly, we assess the impact of using the residual energy of the node instead of a random number as a rank in the CKN algorithm. We also evaluate our ECKN algorithm, which has different values of \(k\) depending on the node's distance from the sink: \(k=3\) for nodes close to the sink, \(k=2\) for nodes in an intermediate region, and \(k=1\) for nodes further from the sink. We compare our algorithm with the solution that has no sleep scheduler and with CKN having \(k=3\), \(k=2\), and \(k=1\). Figure 15b shows the network lifetime using random numbers and residual energy as rank. As can be seen, using random numbers as ranks shows better performance than using residual energy. This is explained by how the CKN algorithm works. In order to go to sleep, a sensor node has to follow two conditions depicted in step 6 of Algorithm 1. When we use the residual energy, the node with the largest number in a region will never go to sleep due to the first condition. Since the node has the largest rank, all neighbors will be considered. If two neighbors are on extremely opposite sides, there will not be a two-hop connection between them, and this sensor node will not go to sleep. As the node does not sleep, its rank will increase, and the same problem will occur until the node dies. The same problem happens in different regions of the network causing the lifetime (when using residual energy as rank) to be worse than when using random numbers. Figure 16a shows the number of sleep epochs in which the sensor nodes go to sleep. Results only emphasize what we have mentioned earlier, most of the nodes are sleeping only in 0 to 5 epochs when using the energy remaining as rank. When using random numbers as rank, we have more than 60 nodes having more than 15 epochs where they are sleeping, explaining the better lifetime when using this approach as rank. Figure 16b shows the number of alive nodes at the end of the simulations. As expected, the approach using random numbers as rank for the CKN algorithms presents more alive nodes than the  
Figure 15: (a) Network overhead for different node densities. (b) Network lifetime. approach with residual energy. These results are the consequence of the problem depicted above regarding the residual energy. According to our previous results, using random numbers instead of the residual capacity of the nodes showed better performance in the network lifetime; therefore, we are going to use this approach for our next evaluation. We now assess our ECKN algorithm, comparing its performance to CKN and with a solution using no sleep scheduler. Figure 17a shows the network lifetime using the different sleep schedulers. As can be seen, CKN using \(k=1\) presents the best performance, followed by our ECKN algorithm, CKN using \(k=2\), CKN using \(k=3\), and the approach with no sleep scheduler presents the worst performance. The results are explained because CKN using \(k=1\) has the highest number of nodes sleeping per epoch, once each node is required to have only one awake neighbor. ECKN is the next because most of the network nodes have \(k=1\), only those closer to the sink have a larger value for \(k\). The performance of CKN using \(k=2\) and \(k=3\) underperforms because they must have at least two and three awake neighbors in each epoch, respectively. No sleep scheduler presents the worst performance because no node goes to sleep; therefore, the whole network is awake, decreasing the network lifetime. Figure 17b shows the number of alive nodes at the end of the simulations. Following the network lifetime, CKN using \(k=1\) has the best performance, followed by ECKN, CKN using \(k=2\), CKN using \(k=3\), and the approach with no sleep scheduler. Lastly, we evaluate the delivery ratio of the proposed sleep scheduler. As can be seen in Figure 18, the approach with no sleep scheduler presents the best delivery ratio; this is due to the fact that no node is sleeping.