## 5 System Simulation
### Energy Calculations  
In order to evaluate the energy consumption of CENTERA, we simulated an average sized grid topology of 9 \(\times\)9 nodes and extracted the bytes transmitted/received and those used under cryptographic calculations. In both cases we differentiate the initial activity period--where the nodes are not yet informed about their DL neighbors, and the remaining subsequent periods. We show the total bytes in the whole network, the average bytes per node, and the worst case in each activity period (the node that endured the maximum energy consumption). Note that in our simulation, we choose the activity period to be 6--that is the nodes sent their activity reports and the BS update the routing paths every five periods of sending a normal message. Table 5 shows the number of bytes transmitted and received by each block of our model running without any authentication technique. We show the numbers in four passes where activity/neighbor reports are sent, representing the full network, the average bytes per node, and the worst case. From Table 5, it can be seen that the hello messages occurred in passes 2 and 20, which is normal since pass 2 is the initial period where nodes send hello and help reply messages to get acquainted, whereas pass 20 is the third activity period and in our simulations this is the time to send hello keep-alive messages. The network as a whole has communicated 1328 bytes of those messages, averaging to 16.6 bytes per node; and the worst case was node 42, which actually received all of the hello replies from all of its neighbors. Note that, some nodes may not receive the total number of hello replies due to noise or collisions, but CENTERA's hello scheme is resilient to such effect. As for pass 20, the network communicated a  
Figure 8: The isolation of the broadcasting node 23. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Pass** & & **Hello** & **Reports** & **SUB** & **Total OH** & **Normal** & **TOTAL** \\ \hline  & Network & 1328.00 & 130,514.00 & 3510.00 & 135,352.00 & 0.00 & 135,352.00 \\
2 & Av. Per Node & 16.60 & 1631.43 & 43.88 & 1691.90 & 0.00 & 1691.90 \\  & Worst Case (42) & 20.00 & 1823.00 & 186.00 & 2029.00 & 0.00 & 2029.00 \\ \hline  & Network & 0.00 & 6856.00 & 3574.00 & 10,430.00 & 71,680.00 & 82,110.00 \\
8 & Av. Per Node & 0.00 & 85.70 & 44.68 & 130.38 & 896.00 & 1026.38 \\  & Worst Case (32) & 0.00 & 516.00 & 209.00 & 725.00 & 5264.00 & 5989.00 \\ \hline  & Network & 0.00 & 6856.00 & 3479.00 & 10,335.00 & 71,680.00 & 82,015.00 \\
14 & Av. Per Node & 0.00 & 85.70 & 43.49 & 129.19 & 896.00 & 1025.19 \\  & Worst Case (50) & 0.00 & 784.00 & 113.00 & 897.00 & 7952.00 & 8849.00 \\ \hline  & Network & 728.00 & 6856.00 & 3916.00 & 11,500.00 & 53,760.00 & 65,260.00 \\
20 & Av. Per Node & 9.10 & 85.70 & 48.95 & 143.75 & 672.00 & 815.75 \\  & Worst Case (32) & 10.00 & 564.00 & 240.00 & 814.00 & 4284.00 & 5098.00 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Bytes Transmitted and Received without Authentication. less number of 728 bytes due to the fact that hello keep-alive messages don't require a reply. The average was 10 bytes per node, which is logical since every node has to broadcast one keep-alive message and receive as much keep alive messages as the number of its neighbors; and each message contained just two bytes. As for the reports, in the initial phase the reports consist of neighbor reports only. The network communicated 130,514 bytes averaging around 1631 bytes per node; with the worst case being 1823 bytes. This number of bytes may seem a bit high, however this occur only in the initial phase where the nodes still do not have downlinks and, thus, they broadcast their neighbor reports to reach the BS. So, it is considered as a startup overhead that is insignificant in the life time of the network. In subsequent phases, the reports consists of the activity report, larger in size, but smaller communication overhead, since nodes forward them through their DLs to reach the BS.