# EEMIP: Energy-Efficient Communication Using Timing Channels and Prioritization in ZigBee
## 4 Results and Discussion  
To verify the energy efficiency of the proposed method for ZigBee communication, we have implemented a network simulator. The simulator has two operating modes which it can simulate:  
1. Nonbeacon ZigBee communication,
2. Communication using the proposed energy-efficient method (EEMIP).  
The nonbeacon ZigBee mode has been selected because it is more efficient (regarding data transmission itself) than the beacon mode (the end devices have to process beacon frames, which consumes power). The simulator was implemented as a console application using.Net framework and Windows operating system. The architecture of the implemented simulator is illustrated using a block diagram in Figure 5. Dark grey color represents the used external libraries. The Newtonsoft.Json library [29] has been used for loading the configuration files. For communication between the coordinator and end devices, sockets operations using the ZeroMQ library [30] have been utilized.  
As part of the simulation, we assume that the network initialization has already taken place, i.e., the ZigBee network is created by the coordinator and all end devices are connected to the network and ready to send data. We are not simulating creation of a connection or exchanging initialization messages, since this is not important from our point of view. Our method aims at energy-efficient communication in the data transfer stage.  
Simulation runs in both available modes. For each mode, we send the same data and the simulation runs for the same time period (e.g., 1 h). The data to transfer for each end device can be specified in the configuration file. The separated configuration file is available for all end devices and the network coordinator in JSON format. The configuration file for the coordinator includes a number of nodes in the network, a number of different priorities, and time intervals for individual priorities. There is also a single global configuration file, which contains these configurable parameters:  
* _Test mode_--determines whether the simulation is run until stopped or just the predefined time period (e.g., 1 h).
* _Simulation mode_--determines whether standard nonbeacon ZigBee mode is used or EEMIP.
* _Congestion simulation_--determines whether a congestion is simulated.
* _Data autogeneration_--determines whether the data for transmission will be pseudorandomly generated or data defined in the configuration file are used.
* _Congestion packet ordinal number_--determines which packet will be lost in case of congestion simulation (e.g., each 5 th packet).
* _Low priority time interval_--defines a time interval value in milliseconds for low-priority data.
* _High priority time interval_--defines a time interval value in milliseconds for high-priority data.  
Using various parameter values in the global configuration file, we can run simulations in various modes with various functions.  
The EEMIP mode retransmits lost messages (i.e., Acknowledgment was not received) differently than the nonbeacon ZigBee mode. The nonbeacon ZigBee mode resends the message three times at maximum (according to Zigbee specification [25]). An end device waits for the Acknowledgment message from the coordinator for a time period \(T_{ACK}\), given by the equation:  
\[T_{ACK}=0.05*(2*nwkcMaxDepth)+(security{}_{}_{}_{}_{}_{}{\blacksquare} \tag{3}\]  
where \((security{}_{}_{}{\blacksquare}\)  
\({}_{}{\blacksquare}\)  
\({}_{  
is the same as the high-priority time interval for the EEMIP mode. We have scaled the time interval for low-priority data and we have obtained results for 2 s, 3 s, and 5 s. For all the reported results, we have conducted ten measurements (each taking one hour) and used the average values in the tables. The size of the Acknowledgement frame is constant; 10B according to the specification [25].