Power-saving techniques for beacon-based wireless control and monitoring networks
The world is currently seeing an exponential growth in the use of wireless networks for control and monitoring in consumer, commercial, industrial and government markets. A number of different techniques and technologies may be used to embed wireless intelligence and networking capabilities into everyday devices. Many solutions are based on the 802.15.4 PHY and MAC layers coupled with a ZigBee stack; alternatively, high-performance, low-power, small-memory-footprint MAC and stack combos such as the Synapse Network Appliance Protocol (SNAP) may be applicable for a wide range of applications.
Depending on the unique requirements of each implementation scenario, a variety of different topologies — such as star, tree and mesh — may be employed. Many applications require their end device units to consume the least possible amount of power, and a wide range of power-saving techniques may be associated with each topology. For the purpose of this article, we shall focus on a simple star configuration as illustrated in Figure 1.
Furthermore, we shall also concentrate on power-saving techniques that can be employed with the beacon-based network implementation. In this case, the coordinator acts as a “beacon” and transmits a periodic signal — let's say every one-tenth of a second for the purpose of these discussions. In addition to its “collision avoidance” benefits, the beacon-based approach allows end devices to enter a low-power (sleep) mode between beacon frames.
The beacon signal, which is used to synchronize the other elements in the network, comprises a packet of information. In turn, this packet may be used to configure one or more end devices (telling them “who they are” and “how they should behave”) and/or instruct them to perform certain actions, such as activating/deactivating selected actuators (relays, switches, etc.).
End devices — each of which includes a wireless module — consume different amounts of power depending on the task they are performing at any particular time. Some example values that span a generic range of devices are as follows:
- transmit = 25 mA to 150 mA
- receive = 25 mA to 50 mA
- idle = 1 mA to 5 mA
- sleep = 5 mA to 50 uA
The reason for the spread of values associated with the transmit and receive modes is that they are highly dependent on their specific silicon implementation; whether or not amplification is employed; and so forth. The idle mode refers to an end device that is powered up, but that is not currently engaged in receiving or transmitting data (although it may be gathering sensor data as discussed below). In the case of the sleep mode, the end device (and its associated wireless module) are powered down until an “alarm clock” timer wakes them up to check for incoming beacon packets and to respond as required.
When an end device is first powered up, its default configuration will typically be to wake up and check each packet from the beacon (coordinator) and also to respond to each beacon signal by transmitting the values on its various sensors, but this may result in unwarranted levels of power consumption. In the case of an end device monitoring ambient temperature, for example, it may be sufficient for it to transmit its data only once every second (on every tenth beacon signal). For other applications, it may be sufficient for an end device to communicate its information once a minute, once an hour, once a day, or over an even longer period.
Even in the case where it is required to record a sensor value relatively often (say once a second), it may not be necessary for the end device to communicate this data immediately. For example, an end device may wake up every second to record its sensor reading; but it may need to enter receive mode only once a minute to check the beacon signal for new configuration data; and it may be required to enter transmit mode only once every 10 minutes (at which time it would transmit all of the bundled up sensor readings gathered since its last transmission).
All of the above techniques are reasonably common, but a number of more advanced tricks may be employed. In the case of SNAP, for example, two representative techniques are as follows:
a) End devices may be instructed to transmit sensor information only when the signal passes outside a specified range (defined by low and high threshold values) or when it is transitioning faster than some “allowed rate-of-change.”
b) With regard to secure environments requiring encryption, the beacon may transmit a “hybrid packet.” In this case, the first (unencrypted) portion of the packet can be used to say “I have new instructions for end devices x, y and z.” This would be followed by an encrypted section containing the instructions themselves. The majority of end devices will wake up, check the first portion of the message, determine that they are not affected, and go back to sleep. Only the end devices that are impacted will have to perform the time-consuming (power-consuming) decryption on the protected portion of the message.
Depending on the application, both of these techniques can result in dramatic reductions in end device power consumption. As an example, consider a beacon-based remote temperature sensor. In order to conserve battery power, the device wakes every five seconds to sample the temperature. A typical duty-cycle and current consumption analysis is shown in Table 1.
This equates to just a little more than six months of battery life using AA alkalines, which means that the batteries have to be replaced too frequently for many remote-sensing applications. By comparison, SNAP's ability to send data based on a predefined condition — such as a significant temperature change — allows it to achieve more than five years of battery life as illustrated in Table 2 (this analysis assumes two relevant events per hour, corresponding to a typical outdoor temperature sensor resolution).
Furthermore, in the case of low-powered microcontrollers performing AES128 encryption/decryption, one may expect 2x the processing time for the “radio Tx/Rx” and related activities due to limitations on both CPU cycles and buffer space. The impact of this workload is greatest in the case of control applications where low command latency is required. In such applications, where power consumption is dominated by communication-related activity, SNAP's “hybrid packet” approach to security can decrease power consumption by up to 50%.
ABOUT THE AUTHOR
David Ewing is director of software development at Synapse, Huntsville, Alabama.
Want to use this article? Click here for options!
© 2013 Penton Media Inc.
Acceptable Use Policy blog comments powered by Disqus
Most Popular Stories
CTIA Wireless IT & Entertainment 2010
Read the latest from the show...