# EEMIP: Energy-Efficient Communication Using Timing Channels and Prioritization in ZigBee
## 2 Background  
ZigBee [25] is a wireless personal area network (WPAN) technology targeting low data rate applications requiring low power operation. It supports multiple network topologies, specifically star, mesh, and cluster tree. It is especially useful for low-power IoT applications, since it requires relatively small amount of energy for data transmission, which enables the connected devices to run several year on batteries (for comparison of energy efficiency of several technologies, see [26]). There are three types of logical devices in ZigBee [27]: coordinator, router, and end device. A coordinator creates and manages the network, it must be aware of all the connected devices. A router is an intermediary device, which forwards traffic between the coordinator and other devices that are not directly connected. An end device is a reduced function device (usually battery operated), which interacts with the environment using sensors/actuators, it cannot forward traffic between other devices. In the star topology, the coordinator is usually a central node, which must be a full function device.  
ZigBee supports three data-transfer types [28]: from a device to the coordinator, from the coordinator to a device, and between two devices. The exchange of messages depends on whether a beacon frame is used for synchronization or not (there are beacon and nonbeacon modes available). A beacon mode is usually considered more power-efficient [26], since it allows the end devices to switch to a sleep mode for some period between individual beacon frames. However, it also requires the devices to wait and listen for such a beacon frame and afterwards wait for their time slot to communicate (uses the slotted CSMA/CA for a channel access), and thus waste power. In other words, a device must be awake (i.e., not in a power-saving state) for a time \(T\), which is given by the following simplified equation:  
\[T=Process+Wait\_beacon+Wait\_slot+Transmit+Wait\_ack, \tag{1}\]  
where _Process_ represents processing time (generating data to be sent), _Wait\(\_\)beacon_ is a variable time period, for which the device must wait for the beacon frame after the data are prepared, _Wait\(\_\)slot_ represents the period the device is waiting for its time slot (which might be guaranteed or the device must compete for nonguaranteed time slot that might include back-off time in case of multiple devices trying to communicate simultaneously), _Transmit_ is time required to send the data, and _Wait\(\_\)ack_ is time required to wait for the Acknowledge message in case of a reliable delivery. It must be noted that the retransmission can be required if the Acknowledgement message is not received, which prolongs the device's active time. If there are multiple kinds of devices with various sensors in the network, some of which require sending data more frequently than the others, the beacon mode makes them to unnecessarily (i.e., no data to send) process the beacon frame, or even wake up to receive it, which wastes more power.  
Nevertheless, the duty-cycle approach itself has undeniable potential in energy savings. There is, however, need to use different duty cycles for different devices in the same ZigBee network, and thus, minimize their waiting period, during which the devices must be awake. A synchronization method that is different from the beacon mode must be used to exchange data between the coordinator and multiple end nodes. Ideally, the device would be active only for processing time, transmission time, and waiting for acknowledgement that is always received (no retransmission required). The optimal active time _To_ would then be expressed by the following equation:  
\[\textit{To}=\textit{Process}+\textit{Transmit}+Wait\_ack. \tag{2}\]  
This is achievable if the end device periodically generates the same amount of data (this is the case of most sensory devices), since the processing and transmitting time is predictable. The device can then wake-up just before its time slot; enough to prepare data for transmission.