The Road to WiFi 6E Part 5: Enhanced Low Power

Published on July 7, 2022

The Road to WiFi 6E Part 5: Enhanced Low Power

This blog post is the fifth in a series of articles we’ll be presenting over the course of 2022 about WiFi 6 (and 6E) – the current and future top-of-the-line WiFi standards championed by the WiFi Alliance. We’ll be discussing the history of the evolving standard of WiFi, new features introduced in WiFi 6 and 6E, applications beyond the commonly known consumer use cases, and much more. Additionally, we’ll be releasing a companion series of video interviews with Ezurio (formerly Laird Connectivity) experts, which you can find here.

Slow And Steady: How Enhanced Low Power Wins the Race

For the previous portions of this series, we focused in many ways on higher throughput, and how WiFi 6 and 6E decrease latency across more and more devices. WiFi 6 is built to serve the entire next generation of WiFi, delivering Quality of Service to more devices in a more efficient way. And just as important as the high-throughput devices are the low-throughput ones: devices that are lightweight, battery-powered, sensor and control driven, and otherwise have completely different needs than the data hogs on the network.

WiFi 6 is about serving ALL devices better. And when it comes to battery-operated devices, smart power management is a huge driver of the success of the applications itself and is a big determiner of user experience. Anecdotally, it’s not hard to remember a short while ago, before the advent of the lithium-ion battery, when seemingly every battery-powered device had a very limited operational charge life and spent as much time charging or replacing batteries as it did in use. Today’s batteries are higher-capacity and their power usage is increasingly optimized by power schemas, smaller semiconductor manufacturing processes, and more. And WiFi 6 has something important to offer in terms of Enhanced Low Power support which directly targets these kinds of devices.

In this post, we’ll look at Enhanced Low Power support and its related technology, Target Wake Time (TWT). The basic concept is: what if APs and clients could negotiate between them the ideal time to fall asleep and then wake only when necessary to send or receive data? A key feature of many low-power WAN technologies, configurable sleep times give clients and access points the flexibility to save as much power as possible, especially helpful to devices that only transmit infrequently such as sensors and automation controls in many industries such as industrial, medical, infrastructure, utilities, and much more. Although power save techniques like this have been around for a while TWT brings a more flexible and application driven approach to tailoring the power usage.

Still Supported: PS-Poll and WMM

First, let’s look at previous power save modes supported in WiFi, which are still supported in WiFi 6 and 6E: PS-Poll (DTIM) and WMM (APSD). These methods save power, but do not allow clients to rest in quite the same way that is enabled in WiFi 6.

For example, PS-Poll allows the AP to queue up packets for a client, which has to check in every cycle for a PS-Poll packet to see if those packets are incoming. When the AP decides to send the queued packets, it does so one at a time until the queue is cleared. While this generally saves the client from receiving packets every single time, the client still has to check in every cycle to look for the PS-Poll frame and must clear the queue when flagged. It’s better, but imperfect. There is no true sleep interval. PS-Poll has limited range in terms of how long the stations and AP’s do not talk, usually a multiple of the beacon clock period, there is also no accounting for accounting for extended disconnect periods and the association state of the client if this times out.

 WMM (APSD) was designed to make this process more efficient by doing away with the regular check in for a PS-Poll frame and instead creating “trigger frames” which could be any data frame. This means the client could generally be asleep for longer periods of time, and when the AP has data to send, it issues the trigger frame and seizes the opportunity to send the queued packets to the client. This does enable sleep, but it’s not a complete two-sided negotiation. The client’s sleep is independent of the AP’s scheduling, and it can only wait for the client to awaken to send packets.  APSD also included packet aggregation to make the delivery of stored packets more efficient.

What is missing from both of these is a mutually-aware sleep negotiation between the AP and the client. As we’ll explore, TWT enables much longer sleep times for clients, greater periods of inactivity while still remaining connected to the network. For devices that CAN sleep for long periods of time, TWT is a game-changer that dramatically improves power scheduling and battery life, as well as keeps a network less congested overall.


TWT Origins: You Had Me at HaLow™

The WiFi 6 / 6E specification borrows this critical TWT feature from another WiFi spec, not coincidentally one that is expressly concerned with power savings on WiFi devices. The 802.11ah specification carries the branding WiFi HaLow™, which is its own separate WiFi implementation that operates in sub-gigahertz frequencies, unlike WiFi 6 and 6E. Operating between 750-928 MHz, it occupies a frequency range associated with technologies like LoRaWAN. And as with most LPWAN technologies, its goals are to provide long range connectivity and low power usage, often on coin cell batteries where power is truly at a premium.

Target Wake Time makes perfect sense for devices of this type. Being able to negotiate sleep times between the AP and the client has big implications for how long a device can operate in the field. Let’s use an example: In an auto manufacturing plant, let’s say a barcode scanner is installed which checks each incoming chassis as it passes into the work area. That scanner is connected via WiFi, which in older implementations of WiFi might require that scanner to be constantly connected, even when it isn’t scanning. But we know that the vehicles rolling down the line move at a maximum rate, say one per minute. With this information, we know the scanner can sleep for a minute at a time before it needs to send data. That’s a huge power savings if implemented correctly.


Multiple Configurations: Who’s the Boss?

There are three configurations of TWT available to administrators, which are mostly concerned with which devices set the sleep times on the network and how. Each has its advantages, but the difference is largely who defines the wake times, and how it is negotiated:

  1. Individual TWT. In the barcode scanner example from earlier, we have enough information from the client side to know very well how often the device should sleep, and when it should wake. Clients can dictate to the AP their wake/sleep schedule, which prioritizes the client’s needs and creates an ideal schedule that only uses power when it’s needed.
  2. Broadcast TWT. In this configuration, the AP sends a sleep/wake schedule to all clients that support Broadcast TWT. The clients can accept or reject this schedule, based on need. They can join the existing broadcast service period, or negotiate a new one with the AP.
  3. Solicited and Unsolicited TWT.   In this configuration, the client will either start a TWT session with the AP (on the AP’s terms, unlike individual TWT) or the AP will initiate a TWT session with the client, which the client may accept and join. These both differ from individual TWT in that the AP dictates the terms and the times as are advantageous for the AP.

Helping the Whole Network with TWT

As we’ve established, TWT has a big impact on WiFi devices that need to conserve power. But it also helps every other device connected to the network, in terms of keeping the RF space clean, and in particular between access points.

In our last post, we looked at BSS coloring, a new feature that allows APs with overlapping channel sets to distinguish their clients and traffic from each other. Two APs with overlapping RF coverage, which have clients communicating on the same channels, can opt not to back off if the interfering traffic is not intended for them. APs are assigned a “color” as are their clients, and they use this to improve efficiency by working simultaneously.

This issue of overlapping basic service sets, as they’re known, is further helped by using Target Wake Time. If the APs are experiencing too much difficulty and interference caused by devices on the same channel, Broadcast TWT can be used to create a temporal buffer for their traffic. Broadcast TWT can schedule clients into sleeping for the right amount of time so that their traffic doesn’t interfere with the listen/broadcast schedule of the neighboring clients.

To Repeat: It’s All About Efficiency

As with many other improvements in WiFi 6, enhanced low power support with TWT has multiple applications that all drive at the same goal: a more efficient network. Different devices have different needs, and the flexibility offered by a highly configurable sleep/wake schedule ends up being a tide that raises all boats on the network.

To review, some applications that are well-served by TWT include:

  • Sensors – In many ways, TWT enables sensor-type devices to catch up, in terms of power efficiency, to other protocols like Bluetooth LE and LoRaWAN. It goes without saying that every microsecond awake is power consumption, so it’s critical to sleep when possible to help power-constrained devices reach maximum efficiency. In a deployment, temp sensors may be read once every 5 minutes, light sensors or motion sensors every 5 seconds, humidity sensors every 15 minutes, access control every 30 seconds. When they use individual or broadcast TWT to schedule sleep as often as possible and only communicate as needed, the RF environment is cleaner and the entire building performs better.
  • Handheld Terminals – In many working environments, handheld devices are a tool required every day for regular operations. Handheld scanners in warehouses and retail help facilitate measuring stock levels and stock picking. Handheld terminals provide order entry in hospitality and restaurants. Patient data is entered and read in handheld devices in healthcare facilities. All of these devices are in use all day, every day, even if their WiFi radio doesn’t need to be (making them a great candidate for establishing individual TWT). Keeping devices off the charger and in the hands of workers is critical to getting these jobs done.
  • Remote Monitoring – Anywhere remote sensing is needed, power-supply is likely to be hard to find. In remote utility monitoring, the meters or infrastructure being measured are likely to be hard to reach with cabled power. WiFi can reach hundreds of feet outdoors with line of sight, but power is likely to be much harder to find, and the needed interval for data transmission is likely to be very, very low. By sleeping nearly all the time, and only communicating infrequently without competition from other clients, a monitoring installation can be highly power efficient, free of collisions, and much more effective than previous WiFi standards would allow.
  • Connected Hospital Room – The number and variety of devices in a connected hospital room are many, and their individual needs for connectivity all vary as well. For example, a monitor for patient vitals might need to be awake relatively frequently to send up-to-date information to a nurse’s station, where a medication dispenser performs fairly regularly and its data requirements may be primarily for logging, where delays are acceptable. A handheld tablet, used to review patient charts and more, may benefit from sleeping over long intervals, only waking to Wi-Fi when it’s currently in use, which has the benefit of driving up its battery life. All of these devices’ unique needs form a strategy around their ideal wake time, whether assigned by the AP or negotiated individually by the device. Hospital administrators can benefit from assigning broad-reaching rules that apply to devices by their type and class, cleaning up the RF environment for the most urgent devices. 


Having established many features in this series which improve efficiency for the entire WiFi network, it’s clear WiFi 6 is about better network intelligence between clients and access points, smarter use of spectrum, better organization of clients and QoS sufficient to their needs. We have alluded to, but not yet focused on, the whale under the surface of WiFi. That whale is the new availability of the 6 GHz spectrum, the cornerstone of WiFi 6E, and that’s what we’ll discuss in our next post.

Governments around the world are rapidly lining up to make up to 1.2 GHz of license free frequency available to WiFi devices, a massive expansion that over doubles what was available in previous versions of WiFi. It’s a huge expansion, but comes with its own challenges. It will require the regulatory efforts to become fully available, coming with limitations in terms of how it can be used and the power limitations that will keep it compliant. And it will also be critical in highly-demanding applications that require absolute RF clarity or an extreme amount of bandwidth to function properly.

Subscribe to our blog series to get updates on our next post and many more as we continue our 2022 series on WiFi 6 and 6E.

Learn more on these topics: