Wi-Fi Power Save Simulator
Compare staying awake, legacy power save, U-APSD and TWT for an idle phone, a voice call and an IoT sensor: when the radio wakes, the frames exchanged, the battery life and how long frames wait.
How to use this tool controls and what to look for
Pick a device and its traffic, then compare the four power save methods: when the radio wakes, the frames exchanged, battery life and delay.
Controls to change
- Scenario: choose an idle phone (screen off), a voice call or an IoT sensor.
- Method: compare Always awake, Legacy power save, U-APSD and TWT.
- DTIM period (beacon interval 100 TU): change how often broadcasts are delivered to dozing clients.
- TWT wake interval: set how often a TWT client wakes up, from 0.5 s to 60 s.
- Broadcast and multicast on the network: add broadcast traffic such as ARP.
- Device: choose a Phone Wi-Fi chip or an IoT Wi-Fi module, and set the Battery (Wh).
What to look for
- Listening costs almost as much power as sending, so the time spent dozing decides the battery life.
- Legacy power save fetches one frame per PS-Poll. U-APSD delivers everything in one service period.
- Broadcasts wait for the DTIM beacon, so a longer DTIM period saves battery but delays them.
- TWT lets a client sleep through beacons, but it then misses broadcasts such as ARP unless it also wakes for DTIM beacons.
About this tool
A Wi-Fi radio that listens all the time drains a battery in days; one that dozes between frames can last for months. This simulator compares staying awake, legacy power save with PS-Poll, U-APSD (WMM Power Save) and Target Wake Time (TWT) for an idle phone, a voice call and an IoT sensor. It draws when the radio is awake, shows the frames the AP and client exchange, and works out the average power, battery life and how long frames and broadcasts wait.
What you'll learn
- Why a radio that keeps listening uses more battery than its short bursts of sending and receiving, and why dozing matters most
- How the TIM and DTIM beacons tell a dozing client that the AP is holding frames for it, and why broadcasts wait for the DTIM
- How legacy power save fetches one frame per PS-Poll, while U-APSD delivers everything in one service period after a trigger
- How TWT lets a client agree its wake times and skip beacons, and why it then misses broadcasts such as ARP
Common questions
What is the DTIM period in Wi-Fi?
The number of beacons between DTIM beacons. After each DTIM beacon the AP sends the broadcast and multicast frames it has held. A DTIM period of 3 with the usual 100 TU beacon interval means about every 307 ms: a longer period saves battery but delays ARP, mDNS and multicast for every client.
What is the difference between legacy power save and U-APSD?
In legacy power save a dozing client wakes for DTIM beacons and asks for each held frame with a PS-Poll. With U-APSD any frame the client sends works as a trigger, and the AP returns everything it holds in one service period, which suits voice calls: the downlink audio rides on the client's own packets.
Does TWT save more battery than other power save methods?
Usually, for devices with little and predictable traffic. A client with an individual TWT agreement wakes only at the agreed times and may skip beacons, so an IoT sensor that reports once a minute can sleep for most of that minute. The cost is delay, and broadcasts are missed unless the client also wakes for DTIM beacons or the network answers for it with proxy ARP.
Free for private and educational use. This interactive model is a simplified teaching aid and may contain mistakes. It is provided as is, without warranty. Use it to understand the concepts, not as a substitute for a site survey, vendor documentation or professional design advice.