Driving Wi-Fi Based Connectivity for Low-Power IoT Applications
Siddarth Sundar - Senior Product Manager, Wi-Fi Solutions
Over the last two decades, Wi-Fi has transformed connectivity with more than 15 billion installed devices in the world. Such a broad and pervasive installed base, along with its throughput capabilities and native IP capabilities, makes Wi-Fi an attractive protocol for IoT wireless applications. However, a key limitation of most Wi-Fi-based IoT systems is high power consumption. Because Wi-Fi was primarily designed to optimize bandwidth, using traditional Wi-Fi in power constrained battery-powered applications can be a significant challenge. This white paper discusses the factors contributing to Wi- Fi power consumption, different power saving modes, as well as design and hardware considerations for optimizing power consumption and extending battery life in IoT devices.
Wi-Fi Operation from a Power Consumption Perspective
There are multiple flavors of Wi-Fi based on different IEEE standards. These typically operate on the 2.4 and 5 GHz bands, with a multitude of modulation schemes. The maximum data rates range from single digit Mbps to hundreds of Mbps, depending on the antenna configuration and the modulation scheme employed. Before developers can understand best practices for optimizing power consumption and system efficiency, they must first understand the different Wi-Fi technologies and why certain ones have advantages for power-constrained devices.
The following table lists the most common flavors of Wi-Fi:
|Band||Technology||Max Speed (Mbps)||Comments|
|2.4 GHz||802.11 b/g||11-54 Mbps||Historical standards. Superseded by 802.11n|
|2.4 & 5 GHz||802.11 n||72-600 Mbps||Faster speeds, MIMO support|
|5 GHz||802.11 a||54 Mbps||Original 5 GHz standard|
|5 GHz||802.11 ac||Gigabit||Flagship 5 GHz high speed standard|
|2.4 & 5 GHz||802.11 ax||Gigabit||Next-gen Wi-Fi standard|
|Sub-GHz||802.11 ah||< 40 Mbps||New standard designed for Sub-GHz Wi-Fi operation|
These are some of the key aspects to consider while selecting the Wi-Fi standard for IoT applications:
- 5 GHz: Offers high throughput but shorter range, more output power required for the same range vs. 2.4 GHz so it’s not power friendly.
- MIMO: Potentially better range at the cost of more power consumption and cost.
- 802.11 ah/ax: These are new standards and most APs currently on the market do not support these technologies, so IoT devices cannot take advantages of these yet. Widespread deployment typically lags 3-5 years after introduction to public. In particular, 802.11ah is not fully ratified at this point, and it is unclear how much support mainstream access point will have for it.
- 802.11 b/g/n are the most popular Wi-Fi standards used in IoT devices and meet the power, range and throughput requirements for most IoT use cases. They operate on the 2.4 GHz band which is universally available and widely deployed, making them ubiquitous and ideal for IoT applications.
802.11 b/g/n is the most popular Wi-Fi standards used in IoT applications.
Power consumption in Wi-Fi varies dramatically across various modes of operation starting from few hundred mA in transmit mode to few μA in sleep mode. It’s important to understand the various modes of Wi-Fi operation and optimize those modes from a system and application level to reduce the overall power consumption. From a power consumption perspective, you can classify the Wi-Fi operations in to the following modes:
|Mode||Current Consumption*||Memory Retained||Time to Wake Up and Associate*|
|Snooze||500 μA||Yes||1 ms|
|Associated Sleep||30 μA||Yes||~3-5 ms|
|Deep Sleep||2 μA||No||100s of ms|
One strategy to reduce the overall power consumption is to stay in the lowest power mode as much as possible. When data needs to be transmitted or received, do it as quickly as possible then go back to lowest power state possible. As shown in the above table, wake up time increases as you enter deeper sleep states. This means higher latency. Also, certain sleep modes cannot retain memory, which means applications need to re-establish the connection with the AP and cloud and can lead to additional power consumption.
Developers must understand the tradeoff between power consumption, wake-up time, and memory state
of various Wi-Fi modes to optimize applications for maximum battery life.
There are several best practices for optimizing these modes to ensure low power consumption: optimizing Transmit and Receive modes, optimizing various sleep modes, WMM and power save modes, and standby and shutdown modes.
Optimizing Transmit (TX) and Receive (RX) Power
As mentioned previously, Wi-Fi devices typically have significant power consumption in Transmit and Receive modes (Transmit power consumption is typically in the 200-400 mA range, while Receive power consumption is typically in the 50-100 mA range). Therefore, choosing devices with the lowest possible Transmit and Receive power consumption is important to reduce overall power consumption.
For most IoT devices, receive power is more significant as you spend most of your time listening for data. In cases where the device wakes up periodically and transmits a chunk of data (e.g., IP camera triggered on motion), power consumption may be dominated by the TX mode.
Most Wi-Fi devices are optimized for range and throughput, which means they attempt to transmit at close to peak power all the time. A power-optimized Wi-Fi device may have a lower power TX or Receive mode that allows you to trade off power consumption with range for your system.
Figure 1. Downlink/Uplink Power Consumption
Downlink Power Consumption (High Throughput)
Uplink Power Consumption (High Throughput)
Beyond average power consumption, the Transmit (TX) power consumption typically sets the peak current requirement for the whole system, which means the entire power subsystem must be able to deliver that amount of peak power. This can set limits on device size, cost, and battery technologies. Therefore, it is important to look at peak Transmit (Tx) current consumption, even if that is not a dominant factor in overall power consumption. In addition, there may also be thermal considerations in products like lightbulbs and switches, which could be a further limitation on peak current consumption.
Finally, while MIMO architectures and newer standards, such as 802.11ac/ax can offer higher data rates, which often comes at the expense of Transmit (TX) and Receive power consumption. For IoT systems with limited bandwidth requirements, 802.11 b/g/n can offer the right compromise of throughput, power consumption, and cost.
Optimizing Sleep Mode Power
For many IoT applications, most of the time is spent in the idle mode, not transmitting data. The Wi-Fi standards have two mechanisms to reduce power consumption when the device is not sending or receiving data, as follows:
Wi-Fi Multimedia (WMM) Power Save allows the access point (AP) to buffer downlink frames (based on the QoS parameters defined in WMM), allowing the client device to doze between packets to save power. WMM doesn’t need to send specific PS-Poll requests because it can be triggered with any data frame. Also, for integration with 802.11e QoS, different application types can use different queues so services that can tolerate higher latency will let the device stay asleep longer.
Delivery Traffic Indication Message (DTIM) Intervals: Wi-Fi access points send out a beacon every 100 ms. The standard allows the AP to only send broadcast or multicast data every ‘n’ beacons (defined as the DTIM interval), allowing the client to sleep for multiple beacons. This is valuable for power saving because listening to each beacon consumes a lot of Receive current, which typically dominates average current consumption. The longer the DTIM interval, the more the power savings. However, this comes at the cost of higher latency.
By using these two power-saving mechanisms, the device can sleep most of the time it is not sending or receiving data, reducing power consumption dramatically. Keep in mind that the device must retain connection information (SSID, keys, IP addresses, and so on) even when asleep. Therefore, this type of sleep mode (often referred to as “associated sleep”) consumes a bit more power than a true shutoff mode (as memory must be retained). However, this current is far smaller than the Receive or TX current. For example, an average sleep current number may be < 100 μA, compared to 10’s to 100’s of mA in TX and Receive modes. This can enable average power consumption for sleepy applications to drop well below 1 mA in many cases.
Figure 2. Power Save Power Consumption
Association vs. Dissociation
Wi-Fi association and disassociation involves several message exchanges between the device and the access point, which means transmitting and receiving several packets and the power consumption associated with it. To save the maximum amount of power, the station can completely dissociate from the access point and go in shutoff mode (where the device can sometimes consume < 1 μA of current). However, this means that the client has to re-associate with the AP every time it wants to send data, which can take up to a few seconds.
This association process adds significant latency to any information that needs to be communicated and results in significant power consumption during this period. In addition, the device cannot receive any information when it is dissociated, which means remote wakeup via Wi-Fi is not possible.
However, this can be a very useful strategy to save a lot of power. Devices, such as ordering buttons (push button to order a specific item to be delivered) are only used sporadically, perhaps a few times a month. Additionally, latency of a few seconds in such a device is acceptable. Staying dissociated from the Wi-Fi access point and only re-associating on a button push to transmit information allows such devices to have multi-year lifetimes on a small battery.
RF Performance and Power Consumption
Unlike many wireless protocols, Wi-Fi power consumption is significantly impacted by RF performance and network conditions:
- Because Wi-Fi is dynamically modulated, the maximum possible throughput increases as the link budget goes up. For a fixed amount of data, higher throughput means less time spent in high power TX and Receive modes.
- A data packet is only considered to be received when the transmitter receives an acknowledgement from the recipient that it received the data. Unacknowledged packets are typically retransmitted till an ACK is received. As Wi-Fi operates with positive acknowledgement, a busy network can lead to many retries, which consumes more power.
Figure 3. Channel Utilization with Adjacent Channel Interference (5 Mbps Target Throughput)
Goal–Maintain Throughput during Interference
Figure 4. Data Throughput with Adjacent Channel Interference
Goal–Minimize Re-Tries during Interference
The following are ways to optimize power consumption:
- Choose devices with high selectivity/out of band rejection.
- Choose devices with high receive sensitivity.
- If possible, choose uncrowded RF channels to operate your device(s). This may mean using bands or channels not used by chatty connections such as video streaming.
Data Sheet Tricks to Note
Wi-Fi data sheets are complicated and there are several tricks to watch out for:
- TX and Receive power consumption: Be sure to make an apple-to-apples comparison (TX output power, receive sensitivity, modulation rate/throughput) when comparing two numbers from different vendors. Also, make sure to factor in any duty cycle caveats in the data sheet. A power number defined for 50 percent duty cycle means the number should effectively be multiplied by two before comparing it to a vendor that specifies the number for continuous operation.
- Sleep current: Make sure the sleep mode defined retains all the association information to allow the part to stay associated. Otherwise, it will have to associate once it comes out of sleep (which can take seconds). Some vendors compare their “hibernate/deep sleep” currents to other vendors’ “associated sleep” currents to show a lower sleep power number
- Understand the assumptions on “average current”: All average current calculations employ several assumptions that may or may not be valid for your system. Make sure you understand the exact configuration (TX data rate, receive data rate, DTIM Interval, beacon width and beacon skipping, if any). You may have to significantly modify configuration parameters to model power consumption for your own system.
- TX power at pin (vs antenna): Several devices specify output power at the RF pin of the chip/module and not the antenna. This allows them to exclude the loss of the matching network/filter necessary in real life, which can result in 1-2 dB lower link budget. Make sure to account for that when comparing data sheets.
Power consumption is highly dependent on the application and use case. In general, we can classify the applications into three major categories:
- Always On/Connected - These devices are always-on in the sense user can access the device any time remotely via cloud and mobile app. A good example is a battery powered Wi-Fi video camera. Latency is a critical factor in these applications. Power consumption is dominated by the Transmit power as the device will be transmitting video.
- Periodically Connected - These devices connected to a remove server or cloud in a periodic manner to send data or receive commands and updates. A good example is a temperature or humidity sensor that sends the data every few minutes. Latency is not a major concern here and the power consumption is dominated by receive current and sleep currents.
- Event Driven - An order button is a good example of an event-driven use case. It’s almost always inactive/sleep, meaning there is no data transmission. It wakes up when a user presses the order button. Power consumption in these applications is dominated by the lowest sleep current.
These are some of the application level factors that needs to be considered while selecting the Wi-Fi technology:
- Latency requirement - How much latency can your system tolerate? How often do you expect to send or Receive data? Many devices, such as IP cameras, may transmit data infrequently, but have low latency requirements when they do.
- On-to-off time ratio - This drives significant decisions around maintaining IP connectivity permanently versus associating. For example, an ordering button can sleep in the lowest power mode for weeks and reestablish the connection when it wakes up.
- Throughput and range requirements - This drives output power and sensitivity requirements, which are a large contributor even for sleepy Wi-Fi devices.
- Thermal envelope and heat considerations - Some devices, such as lightbulbs have thermal limitations that may drive lower peak power as a constraint.
While Wi-Fi is not optimized from the ground up for low power operations, there are several techniques that can be used to significantly reduce power consumption. These range from features built into the specification, to RF performance, to system level optimizations on connectivity. Developers must understand all the contributing factors to overall energy consumption in IoT devices. They must understand both system level factors and deep application factors to achieve low energy consumption in their applications. The right mix of power-saving Wi-Fi modes and the right hardware are the keys to dramatically reducing power consumption. Leveraging hardware and software designed specifically for IoT devices can reduce long term costs, overcome development challenges, extend battery life, and potentially enhance the life of their products and customer satisfaction.
A highly integrated and purpose-built Wi-Fi solution with application level optimization
is critical for extending the battery life in IoT applications.
Learn more about Silicon Labs low power IoT solutions at www.siliconlabs.com/wi-fi
About the Author:
Siddharth Sundar is a Senior Product Manager at Silicon Labs based out of Austin, TX. He has more than 10 years of experience in the semiconductor industry in engineering and marketing roles. He holds a B.S and a Master of Engineering degree from the Massachusetts Institute of Technology.