# EEMIP: Energy-Efficient Communication Using Timing Channels and Prioritization in ZigBee
## 4 Results and Discussion
### Evaluation of Scenario B  
In this scenario, there are two kinds of congestions simulated regarding intensity of congestion. It is simulated by a frequency of dropped packets, i.e., how often some data are lost. We simulate a congestion situation, where each third packet is dropped, and the second congestion situation, where each fifth packet is dropped. A dropped packet is simulated by the coordinator not sending the Acknowledgment message. In such a case, retransmission as explained above occurs. This experiment is intended to point-out benefits of the EEMIP method using prioritization. Table 4 contains the average number of bytes and packets processed by the four end devices during a simulation time of one hour. The results are provided for both congestion situations, where each third or each fifth packet must be retransmitted. Analogous to Table 4, the results for the EEMIP mode are provided in Table 5 (each 3 rd packet must be retransmitted) and Table 6 (each 5 th packet must be retransmitted). These tables provide results for three different low-priority time intervals (similar to the previous experiment). Table 7 contains comparison of results obtained for the two simulation modes for these two congestion situations. It provides a difference in a number of processed bytes and packets when using the EEMIP method in comparison to the standard nonbeacon ZigBee communication. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**End Device** & **2 s Low-Priority Time Interval** & **3 s Low-Priority Time Interval** & **5 s Low-Priority Time Interval** \\
**ID** & **Bytes** & **Packets** & **Bytes** & **Packets** \\ \hline
1 & 56,160 & 4560 & 48,180 & 4020 & 48,540 & 3960 \\
2 & 66,420 & 4380 & 62,100 & 4080 & 59,220 & 3900 \\
3 & 79,560 & 4380 & 72,960 & 4020 & 71,580 & 3900 \\
4 & 92,880 & 4380 & 85,320 & 4020 & 84,600 & 3960 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Number of processed bytes in the EEMIP mode during a congestion with each 5 th packet lost. \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{2}{c}{**Each 3 rd Packet Lost**} & \multicolumn{2}{c}{**Each 5 th Packet Lost**} \\
**End Device ID** & **Bytes** & **Packets** & **Bytes** & **Packets** \\ \hline
1 & 29,400 & 2340 & 37,440 & 2700 \\
2 & 46,920 & 2460 & 53,880 & 2700 \\
3 & 56,040 & 2280 & 69,060 & 2700 \\
4 & 69,720 & 2280 & 87,300 & 2760 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Number of processed bytes in the nonbeacon ZigBee mode during a congestion. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**End Device** & **2 s Low-Priority Time Interval** & **3 s Low-Priority Time Interval** & **5 s Low-Priority Time Interval** \\
**ID** & **Bytes** & **Packets** & **Bytes** & **Packets** \\ \hline
1 & 44,580 & 3900 & 51,060 & 4200 & 47,940 & 3960 \\
2 & 56,220 & 3840 & 63,840 & 4200 & 58,440 & 3840 \\
3 & 68,520 & 3840 & 74,100 & 4080 & 71,160 & 3900 \\
4 & 83,940 & 3840 & 85,680 & 4020 & 80,340 & 3780 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Number of processed bytes in the EEMIP mode during a congestion with each 3 rd packet lost. Based on the reported results for congestion simulation, we can see that the EEMIP method sends more data than the standard nonbeacon ZigBee communication in most of the cases. It might evoke an impression that it is less energy efficient than the standard mode. During a congestion, the coordinator processes the high-priority data first and sends the Acknowledgment message to the end device (which also increases the number of processed bytes). In EEMIP mode, the end devices can transmit data more often without data loss. The data transmission frequency is also increased as a result of no need for delayed waiting for the Acknowledgment message (the mentioned 1.6 s). It means that in the standard ZigBee mode, the end devices more often wait for the Acknowledgment message (upon simulation of data loss) and, thus, effectively transmit less amount of data. To clarify this reasoning, we provide another comparison for the two simulation modes.