This article presents several power saving features with short examples. I was testing 802.11 Power Management using all the laptops and the mobile phones I could get, and there was a lot to learn. Many mechanisms that are described in the IEEE 802.11 standard allow a wireless device to reduce its power consumption, to turn off its radios and to wake up at the correct time to retrieve its traffic. While the APs are generally connected to an external power source, the wireless clients are often running on batteries. The purpose of power saving features is to increase the battery life and to allow longer performance. This battery life extension can be significant for low-powered devices such as smartphones, Voice over IP phones or handheld barcodes scanners.
From the original version in 1997 to now, many features that reduce power consumption have been added to the standard. Some of them have fallen into disuse (PS-Poll), some have been granted certifications (WMM-Power Save) and others relate to specific technologies (MIMO PSPM, 11ac VHT TXOP PS). And there are many other mechanisms related to power-saving that are not discussed in this article (PSMP, TIM Broadcast, Proxy ARP, etc.). Future amendments (802.11ax, 802.11ah) will also introduce new and enhanced power saving techniques.
Power Save (PS) mode
Let's start with the basics. The primary power save mechanism is based on a low-power state in which the radio is not able to transmit or receive.
A radio can be in one of two Power states:
Awake: the radio is constantly powered and able to receive and transmit.
Doze: the radio is not able to receive and transmit and consumes low power.
A wireless client enters Power Save (PS) mode in which the radio power state can transition between awake and doze according to the 802.11 power management rules.
A client can be in one of two Power Management modes:
Active mode: the client is awake all the time. The AP immediately transmits the frames to the client.
Power Save (PS) mode: the client is mostly in doze power state, but can also be awake to transmit and receive now and then. In this mode, the AP buffers the eligible frames destined for the client.
One important element to remember is that a client in PS mode is not always in doze mode. A client in PS mode may transmit a frame to the AP at any time, and the AP can transmit some traffic to a client in PS mode following specific rules.
Let’s see how a client switches between the two Power Management modes. At the beginning, a client is in active mode after (Re)Association. When a client wants to change its Power Management mode, it informs the AP via a successful frame exchange. The new mode is indicated by the Power Management subfield within the Frame Control field of a transmitted frame. A (Null) Data frame is typically used by the client. The AP needs to acknowledge the frame exchange to validate the change successfully. The AP also maintains the Power Management mode state for each associated client.
In this following diagram, the client begins in active mode. The radio is always awake in active mode and ready to receive and transmit any frames. The AP transmit immediately any unicast traffic addressed to the client.
The following frame picture shows the Null Data frame used by the client to go in PS mode: the Power Management bit is set to 1. Then the AP acknowledges the frame to validate the change.
From then, the AP buffers eligible frames, including the Data frames, Disassociation and Deauthentication frames that are addressed to the client, multicast and broadcast frames. Following specific rules, the client wakes up to receive the buffered traffic and then goes back to the doze state for the rest of the time.
The following frame shows the Null Data frame used by this client to go back to active mode: the Power Management bit is set to 0. And the client waits for the Acknowledgement from the AP.
The 802.11 standard also considers that the Power Management subfield in a frame exchange from the AP is ignored.
Although each vendor has its own proprietary set of rules to switch between Active and PS mode, three modes are often configurable on the client:
Constantly Awake Mode (CAM): the radio is active most of the time. This mode consumes the most power and also provides the highest throughput.
Fast Power Save Polling (Fast PSP): the radio switches between active and PS mode, depending on the traffic load. When the traffic is idle or very low, the client stays in PS mode. When the throughput increases, the client goes back to active mode until the traffic ends.
Maximum Power Save Polling (Max PSP): the radio is in PS mode most of the time. This mode saves the most power but also provides the lowest throughput.
Note that a client in CAM mode isn’t always in active mode. Many clients are periodically going into PS mode in order to search and probe the list of neighbouring APs on the channels that are allowed on the client; the method is called Active Scanning.
In the following Wireshark packet capture, a client in CAM mode is scanning for the neighbouring APs every 10 seconds. The client sends a QoS Null Data frame (packet #1) with the Power Management set to 1 to go from Active to PS mode. Then it sends some Probe Request frames (#6, #9) on several channels and wait to receive some Probe Response frames (#7, #10) to update the list of neighbouring APs. In the meanwhile, the AP is responsible to buffer the frames destined to the client. Finally after a total of 147 milliseconds, the client goes back to Active mode with a QoS Null Data frame (#12) with the Power Management set to 0.
The Power Management value can be added in a Wireshark column with the filter: wlan.fc.pwrmgt
Buffered traffic and Traffic Indication Map (TIM) element
The next question is: How does the client retrieve the buffered traffic? To answer that, the client needs first to know that the AP is buffering some frames. The AP indicates that it has some buffered frames using the Traffic Indication Map (TIM) element present in the Beacon frames. The TIM element contains four fields: DTIM Count, DTIM Period, Bitmap Control, and Partial Virtual Bitmap.
The Association Identifier (AID) is a 16-bit value between 1 and 2007 (the 5 MSB bits are reserved) representing the unique identifier of the client in the BSS. The AP assigns the AID value to a client during its association with the AID element contained in the (Re)Association Response frame.
The AP maintains a Traffic Indication Virtual Bitmap that consists of 2008 bits, each of them corresponding to the unique identifier (AID) of the client in the BSS. A bit number N is set to 1 by the AP to indicate that there is buffered traffic for the client whose AID is N. Otherwise the bit in the bitmap is 0.
The Partial Virtual Bitmap that is contained in the TIM element is the relevant part of the bitmap where contiguous series of 0 in the lowest bits and the highest bits of the bitmap have been removed to save some space. The Partial Virtual Bitmap is determined by the Bitmap Offset value and by the Length field with a specific set of rules. The Partial Virtual Bitmap provides the list of AIDs of the clients which the AP has some buffered traffic individually addressed to them. If the Partial Virtual Bitmap is set to 0, there are no buffered frames.
In the following Beacon frame, Wireshark displays the corresponding AIDs that are translated from the Partial Virtual Bitmap. In this example, the AP signals in the TIM element of the Beacon that it has some buffered traffic addressed to the client whose AID is 1. If this client in PS mode wakes up its radios to listen to this Beacon frame, it can poll the AP to receive its buffered traffic and then goes back to sleep.
A client in PS mode gets awake at the times of Beacon frames and checks if there is any buffered traffic. The client may also stay asleep at some Beacon frames in order to save an extra power, running the risk of missing some buffered traffic.
The (Re)Association Request frame includes a Listen Interval subfield within the Capabilities Information field. It is an integer between 0 and 65535 expressed in units of Beacon Interval. It indicates to the AP how often a client in PS mode wakes up to listen to the Beacon frames. In the AP, the Aging Time of the buffered frames bound to the client is implemented differently by each vendor but must not be shorter than the Listen Interval (or the WNM Sleep Interval in a WNM Sleep Mode Request frame). The Listen Interval from the client is also vendor specific.
In the following Association Request frame, the Listen Interval is set to 20 by the client. If the AP has some buffered traffic addressed to the client in PS mode, the AP can age out the buffered traffic after 20 Beacon Intervals and free the buffers if the client is not retrieving them in time. So the client in PS mode must wake up at least once every 20 Beacon Intervals to check if there is some buffered traffic on the AP.
Buffered group traffic and Delivery Traffic Indication Map (DTIM) element
When there is at least one client in PS mode in the BSS, the AP also buffers the broadcast and multicast (group) traffic and transmits it at specific times to ensure that all the associated clients have a chance to receive it. The buffered group traffic is delivered immediately after a Beacon frame containing a Delivery Traffic Indication Map (DTIM) element.
The network administrator can specify the DTIM Period which is the frequency of DTIM Beacons, expressed between 1 and 255 in units of Beacon Interval. It can converted to the DTIM Interval which is the DTIM Period multiplied by the Target Beacon Transmission Time, expressed in Time Unit (TU). Every Beacon contains a DTIM Count that indicates how many Beacon frames will occur until the next DTIM element, like a countdown timer. When the DTIM Count reaches 0 at every DTIM Interval, the Beacon is a DTIM Beacon. After that DTIM Beacon, the DTIM Count is reset to the DTIM Period minus 1.
When the TIM element is a DTIM (DTIM Count of 0) and there are some group traffic buffered at the AP, the bit 0 of the Bitmap Control field (also called AID 0) is set to 1. The AP immediately transmits the buffered group traffic after that DTIM Beacon. The AP also indicates that there are more group buffered frames using the More Data subfield of the Frame Control field.
In this following Beacon frame, the DTIM Count is 0, so the TIM element of this beacon is a DTIM. In addition, the AID 0 is set to 1 in the Bitmap control (“Multicast: True”), meaning that there are some buffered multicast/broadcast frames. Those frames are immediately sent after that Beacon. A client in PS mode may wake up to receive the broadcast and multicast traffic and then goes back to sleep. The Beacon also shows that the DTIM period is 2, therefore the Beacon frames contain a DTIM indication every 2 Beacons (equivalent to a DTIM interval of 200 Time Units).
The choice of the DTIM Period is a trade-off between power-saving and performance. A longer DTIM Period allows the client to wake up at every DTIM interval rather than every DTIM, allowing more power saving. But it can also affect the performance of applications that are sensitive to the delay of the broadcast/multicast traffic.
A short DTIM Period can also impact power-saving for the clients in PS mode that want to receive all the group traffic, waking up to listen to each Beacon. However some clients don’t wake up at every DTIM Beacon. Depending on driver implementation, some clients in extreme low power mode also choose to skip some DTIM beacons and could possibly miss parts of the group traffic. Apple, for instance, recommends a DTIM Period of 3 to ensure that the group traffic is not missed. The DTIM Period should be chosen according to the type of devices and applications.
In the following Wireshark capture, a client sends a QoS Null Data frame (packet #1) to goes from Active mode to PS mode. From then, the client has to check the DTIM Beacon frames to retrieve the group traffic. The Beacon frames include a TIM element with a DTIM Period of 3. When the DTIM Count is equal to 0 and the AID 0 bit (DTIM+Bcast column) is set to 1, the AP sends a DTIM Beacon frame (#13, #23) that indicates some buffered group traffic. The AP immediately sends the broadcast ARP Request Data frames (#14, #24) after those two Beacon frames. A client in PS mode may retrieve those frames if it listens to those DTIM Beacon frames.
The TIM Count value can be added with the filter: wlan.tim.dtim_count
And the DTIM+Bcast value with the filter: wlan.tim.bmapctl.multicast
Buffered unicast traffic delivery and legacy Power Save (PS) mode
When a client in PS mode sees a TIM element indicating some individually-addressed buffered frames for itself, there are several ways to retrieve the buffered frames. The original method is the legacy 802.11 PS mode delivery mechanism.
The legacy PS mode mechanism is based on the PS-Poll frame to retrieve the buffered frames in the AP. The PS-Poll frame is a short Control Frame containing the AID value of the client.
In the legacy PS mode, when the client receives a Beacon with its AID in the TIM element, the client initiates the frame delivery by transmitting a PS-Poll control frame to the AP. The AP responds immediately (or acknowledges the PS-Poll frame and responds) with only a single buffered frame. The client stays awake and retrieve the buffered frame.
The AP also indicates that there are more buffered frames for the client using the More Data subfield. The client continues to retrieve further buffered frames using more PS-Poll frames until there are no more buffered frames and the More Data subfield is set to 0. Then the client goes back into doze state.
The following packet capture has been done with an old PCMCIA 802.11b radio card. In this example, the client enters in PS mode (Null Data #1 and ACK #2) and listens only to some Beacon frames while keeping the radio in doze state the rest of the time.
The TIM AID value can be added in a column with the filter: wlan.tim.aid
When a Beacon frame (#6) announces in the TIM element that there is some buffered traffic for our client whose AID is 1. The client listens to this Beacon frame and transmits a PS-Poll frame (#7) to retrieve the traffic. The PS-Poll frame tells the AID of the client to the AP.
The AP acknowledges the PS-Poll frame and sends the buffered traffic, in this case an ICMP Request (#9). The More Data bit is set to 0 in the Data frame to indicate that there is no more buffered traffic.
The client responds with an ICMP Reply (#11) with the Power Management bit set to 0 which enables the active mode instead of staying in PS mode. The AP validates the change of Power Management mode with the ACK (#12). As the traffic is idle after, the client switches back to PS mode (Null Data #14 and ACK #15).
Rather than the legacy PS mode, there is a de-facto popular method for a client in PS mode to retrieve the buffered traffic: the client simply exits the PS mode and switches back to active mode. Null Data frames or QoS Null Data frames are generally used for this purpose.
In the next Wireshark packet capture, when the client in PS mode sees a Beacon frame (#11) with a TIM element indicating buffered frames associated to its AID, the client sends a Null Data frame (#12) with the Pwr Mgt bit set to 0. Once the client is in active mode, the AP immediately transmits all the buffered frames destined to the client, an ICMP Echo Request (#14). The client also replies to the ping (ICMP Echo Reply #16). After a little while, the client goes back to PS mode by sending a Null Data frame (#18) with the Pwr Mgt bit set to 1.
A ping connectivity test from the wired network to a wireless client in PS mode could defer the transmission of ICMP Echo Request frames for one Beacon interval (or more if there is a higher DTIM Period). It can result in an additional latency of 100 milliseconds or more to Round-trip delay time.
This mechanism using Null Data frames can be more efficient than the PS Polling mechanism if there are multiple buffered frames to retrieve. A single frame exchange with a Null Data frame allows the client to retrieve all the buffered frames compared to one PS-Poll frame exchange per frame in the legacy PS mode. Note that a PS-Poll frame cannot be used to change the Power Management mode because it doesn’t necessarily result in an ACK frame from the AP.
802.11e and Unscheduled Automatic Power-Save Delivery (U-APSD)
The 802.11e amendment has introduced Quality of Service to the 802.11 standard in 2005, and is also the foundation of the Wi-Fi Multimedia (WMM) certification of the Wi-Fi Alliance.
802.11e is backward compatible with the previous Power Management mechanisms. The legacy PS delivery mechanism is still available, and the delivery mechanism for broadcast/multicast traffic follows the same procedures.
Similarly, many QoS clients retrieve the buffered traffic by exiting the PS mode and switching back to Active mode. The difference is that the clients often uses QoS Null Data frames instead of Null Data frames to switch between power management states.
Most importantly 802.11e has prioritized the medium access with Access Categories, Transmit Queues and several parameters (AIFSN, TXOP Limit, CWmin, CWmax). Another difference with 802.11e is that the AP sends the buffered frames in the order of arrival on a per-Traffic Identifier (AC priority), per-client basis.
Additionally 802.11e has added the optional Automatic Power Save Delivery mechanism (APSD) for time-sensitive traffic such as VoIP. APSD defines 2 new delivery mechanisms as following:
Unscheduled Automatic Power-Save Delivery (U-APSD): the buffered frames are delivered during unscheduled Service Periods (SP). The client initiates the unscheduled SP with a trigger frame. Introduced in 2005, the WMM-PowerSave (WMM-PS) certification of the Wi-Fi Alliance is based on the U-APSD implementation. However WMM devices do not advertise the 802.11 QoS formats. They use a different format for the frame elements compared to the elements defined in the 802.11 standard.
Scheduled Automatic Power-Save Delivery (S-APSD): the buffered frames are delivered during scheduled Service Periods (SP). In an EDCA environment, a client sends an ADDTS Request frame with the APSD and Schedule subfields of the TS Info field in the TSPEC element both set to 1. The AP responds with a Schedule element in the ADDTS Response frame.
U-APSD is a mechanism used to retrieve the individual unicast buffered traffic. A client in PS mode starts the unscheduled SP by sending a trigger frame which is a QoS Data frame using a trigger-enabled Access Category (AC).
During the unscheduled SP, the AP sends one or more individually-addressed buffered frames that belong to the delivery-enabled ACs and that are destined to the client. The AP must send no more than the number indicated by the Max SP Length field of the QoS Capability element of the (Re)Association Request frame if this field has a nonzero value. The AP sets the More Data bit to 1 using a delivery-enabled AC or a nondelivery-enabled AC to indicate that there are some buffered traffic for the delivery-enabled ACs or a nondelivery-enabled ACs.
Finally the client remains awake until the AP ends the unscheduled SP by setting the EOSP bit to 1 in the QoS Control field of the last QoS Data frame that is sent to the client.
The client may send an additional trigger frame if the More Data bit is set to 1 in a received frame using a delivery-enabled AC, or a PS-Poll frame if the More Data bit is set to 1 in a received frame using a nondelivery-enabled AC. The client must poll until there are no more buffered traffic for that client.
For any nondelivery-enabled AC, the client sends a PS-Poll frame to retrieve the buffered traffic.
In the 802.11 standard, when a QoS AP supports the APSD capability, it enables the APSD bit in the Capability Information field in Beacon, Probe Response, and (Re)Association Response frames.
Within the WMM-PS certification, a WMM-PS AP advertises the U-APSD capability in the U-APSD subfield (bit 7) in the QoS Info subfield of both the WMM Information element and the WMM Parameter element. The QoS Info element may be found in Beacon frames (either a WMM Information element or a WMM Parameter element), Probe Response frames (WMM Parameter element), and (Re)Association Response frames (WMM Parameter element if the corresponding (Re)Association Request contains a WMM Information element).
The following Beacon is captured from a WMM-PS AP.
In the 802.11 standard, a QoS client advertises the U-APSD capability by designating which ACs are enabled for trigger and which ACs are enabled for delivery. The client has 2 methods to enable U-APSD:
Static U-APSD: the client uses the per-AC U-APSD Flag bits in the QoS Info subfield of the QoS Capability element carried in (Re)Association Request frames. When the U-APSD Flag bit of an AC is set to 1, U-APSD is enabled for both delivery and trigger in the corresponding AC.
ADDTS Request (TSPEC): the client sends an ADDTS Request frame per AC with the APSD subfield set to 1 and the Schedule subfield set to 0 in the TS Info field in the TSPEC element. Trigger ACs and Delivery ACs can be specified differently using TSPEC. APSD settings in an ADDTS Request take precedence over the static U-APSD settings.
Back to the WMM-PS certification, a client signals its U-APSD capability by setting the per-AC U-APSD Flag bits in the QoS Info subfield of the WMM Information element carried in (Re)Association Request frames, or using WMM TSPEC element. The Max SP Length is also specified in the QoS Info subfield.
The following capture shows the procedure when a QoS Data trigger frame from the client in PS mode allows the delivery of buffered unicast frames from the AP.
The application on the client in PS mode sends an RTP G.711 voice packet (#2) with the Power Management bit still set to PS mode. This packet is QoS Data frame tagged with Best Effort which is a Trigger-enabled AC as established in the Association Request, so this packet is a Trigger frame. From this moment, the client is awake to retrieve any buffered traffic. The AP returns any unicast buffered traffic, in this case, an RTP G.711 voice packet (#6) tagged with a Voice Delivery-enabled AC. The traffic from the AP is transmitted within an RTS/CTS mechanism.
Next, the AP sends a QoS Null Data frame (#10) with the EOSP bit set to 1 in order to signal the end of delivery. At this moment, the client switches back to doze state. Then (after 16 milliseconds, defined by the application), the client sends another RTP G.711 voice packet (#12) with the Power Management bit still set to PS mode. This time, the AP has no buffered traffic and sends a QoS Null Data frame (#16) with the EOSP bit set to 1 to indicate the end of delivery. Note that the client stays in PS mode for the whole time.
The EOSP value can be added in a column with the filter: wlan.qos.eosp
U-APSD is a polling method like the legacy PS mechanism; U-APSD is, however, more efficient because an active application can control how often the traffic needs to be retrieved using trigger frames. It will reduce the latency. This is why U-ASPD is well-suited for periodic low latency applications such as Voice over IP. On the contrary, when a client is using the legacy PS mode, the applications are dependent on the listen interval and on the radio driver implementation to retrieve the buffered traffic.
In addition, U-APSD has less overhead than the legacy PS mechanism. For example, the trigger frames may contain application data, whereas the PS-Poll frames are only control frames. U-APSD also allows to retrieve multiple frames instead of polling each individual buffered frames.
802.11v Wireless Network Management (WNM): BSS Max Idle and Sleep Mode
There are 2 features in the 802.11v Wireless Network Management (WNM) amendment that extend the sleeping time for the clients: BSS Max Idle Period Management and WNM-Sleep Mode.
BSS Max Idle Period Management allows an AP to indicate a time period during which the AP will not disassociate a client due to non-receipt of frames from the connected client. It improves the battery life because the client can remain in Doze mode without sending some periodic keep-alive frames for the duration indicated by the AP.
The AP advertises the BSS Max Idle Period Management with the BSS Max Idle Period element in the (Re)Association Response frames.
The Max Idle Period is expressed in unit of 1000 TUs (equivalent to 1.024 seconds). The Idle Options can be used to require that the AP only uses protected frames for keep-alive.
In this following Association Response, the AP informs the client that it can remain idle without transmitting any frame to the AP for a maximum of 3600 TU (3686.4 seconds).
WNM Sleep Mode is an optional 802.11v feature that allows an AP to advertise WNM services to its connected clients. WNM Sleep Mode allows the client to be sleeping for an extended time while it remains associated to the AP. During that extended power save mode, the client may not listen to any DTIM Beacon frames and is not required to perform the GTK/IGTK updates.
A client operating in WNM Sleep mode doesn’t have to listen for the Beacon frames during the Listen interval. The client can specify a longer WNM Sleep Interval during which it wakes up to check for the TIM element. The client can also establish traffic filtering rules with the AP or enable a periodic keep-alive report from the client.
The feature is useful for sensors or IoT devices that are running on batteries for a very long time while the client doesn’t need to listen to the group traffic or when the client only wants to receive a specific type of traffic.
An AP that supports WNM Sleep mode sets the WNM Sleep Mode field of the Extended Capabilities element to 1 in Beacon frames, (Re)Association Response frames and Probe Response frames. A client that supports WNM Sleep mode sets the WNM Sleep Mode field of the Extended Capabilities element to 1 in (Re)Association Request frames and Probe Request frames.
The client sends a WNM Sleep Mode Request frame (WNM Action frame) to the AP when the client enters and exits the WNM Sleep mode. And the AP confirms with a WNM Sleep Mode Response frame as shown in the following diagram.
Those two WNM Action frames include a WNM Sleep Mode element.
The Action Type field identifies the client request (Enter WNM Sleep Mode, Exit WNM Sleep Mode). The WNM Sleep Mode Response Status field provides the status returned by the AP.
The WNM Sleep Interval indicates how often the client wakes up to listen to the Beacon frames to check for the TIM element, in unit of number of DTIM Intervals. A client in WNM-Sleep mode doesn’t need to wake up at every DTIM interval for the group traffic. When the client doesn’t need to listen to the group traffic, a value of 0 indicates that the client doesn’t wake up at any time for the DTIM Beacon frames.
The WNM Sleep Interval can be used by the AP to change the aging time of the buffered traffic for the client. The WNM Sleep Interval must be less than the BSS Max Idle Period as well.
A client may use WNM Sleep mode and PS Mode simultaneously. When a client is in WNM Sleep mode and in PS mode, the AP buffers the unicast frames destined to the client according to the established Traffic Filtering Agreement. When a client is in WNM Sleep mode and in Active mode, the AP buffers the group traffic according to the agreement and to the WNM Sleep Interval.
Note that two of the ten vulnerabilities of the recent WPA2 “KRACK” attack (CVE-2017-13087 and CVE-2017-13088) exploits WNM Sleep Mode Response frames to force a client to reinstall a previously used group key or a previously used integrity group key.
802.11n Spatial Multiplexing (SM) Power Save
The Spatial Multiplexing Power Save (SM Power Save or SMPS) allows an HT client that is capable of multiple spatial streams to operate with only one active receive chain (1x1 SISO) instead of all active receive chains (MIMO) when it is not needed. The feature is also called MIMO Power Save.
There are 2 different methods with SM Power Save:
Dynamic SM Power Save: the client enables its multiple receive chains when the AP starts a frame exchange sequence destined to that client. An RTS/CTS sequence is typically used. The AP sends a single-spatial stream frame to that client and the client switches to the multiple receive chain mode to receive the following frame addressed to it. When the frame exchange sequence ends, the client switches back to a single receive chain.
Static SM Power Save: the client only maintains a single receive chain active.
A client may use the SM Power Save subfield of the HT Capability Information field in the HT Capabilities element of the (Re)Association Request frame to change the SM Power Save mode. This method enables only one single receive chain after (Re)Association.
The 2 bits of the SM Power Save subfield indicate the SM Power Save mode that is in operation immediately after (Re)Association, as well as a capability. It is set to 0 for Static SM Power Save mode, set to 1 for Dynamic SM Power Save mode and set to 3 when SM Power Save is disabled or not supported.
In the following capture, the client supports and operates in Dynamic SM Power Save mode.
The client may also use an SM Power Save Action frame (HT Action frame) to manage the SM Power Save transition. The SM Power Control element communicates any change about the SM Power Save state.
The SM Power Save Enabled subfield is set to 1 when SM power saving is enabled at the client. The SM Mode subfield is set to 1 for Dynamic SM Power Save and set to 0 for Static SM Power Save mode. The change is validated after the frame has been successfully acknowledged.
In this following capture, a client informs the AP that it operates in Static SMPS mode with an SM Power Save Action frame. The client turns off all the active radios except one and operates as a SISO device.
In the next capture, a client sends an SM Power Save Action frame to operate in Dynamic SMPS mode.
When the client uses Dynamic SMPS, the AP can use a quick frame exchange sequence such as an RTS/CTS to signal the client to wake up all its active receive chains and operate using MIMO. After the frame exchange, the client automatically switches back to a single active receive chain.
802.11ac VHT TXOP Power Save
The VHT TXOP Power Save feature allows a VHT client to enter the doze state when when frames are delivered during a transmit opportunity (TXOP) to other clients. A client can operate in VHT TXOP Power Save mode when its Power Management is in active mode. The client may enter the doze state during a TXOP under specific conditions. The AP must not transmit frames to this VHT client during that TXOP.
First of all, both the VHT AP and the VHT client must support VHT TXOP Power Save. An AP advertises the capability by setting the TXOP PS subfield of the VHT Capabilities Information field in the VHT Capabilities element to 1 in Beacon frames, (Re)Association Response frames and Probe Response frames. A client advertises the capability by setting the TXOP PS subfield of the VHT Capabilities Information field in the VHT Capabilities element to 1 in (Re)Association Request frames and Probe Request frames.
Then the AP allows the client to enter the VHT TXOP Power Save mode during a TXOP by transmitting a VHT PPDU with the TXVECTOR parameter TXOP_PS_NOT_ALLOWED set to 0. This value must not be changed during the rest of the TXOP.
Until the end of the current TXOP, the client may enter the doze state under specific conditions, using some information such as the RXVECTOR parameter PARTIAL_AID (a TXOP SU PPDU that is addressed to another client, but not that client) or the RXVECTOR parameter GROUP_ID for MU-MIMO (a VHT MU PPDU that is not intended to that client).
In the following diagram, a MU-MIMO AP sends data to a group of four clients. After checking the preamble at the beginning, a fifth client in TXOP PS mode would turn off its radios during this transmission.
IEEE Standard 802.11-2016:
Wi-Fi Alliance WMM Specification v1.2:
Eldad Perahia and Robert Stacey (2013), Next Generation Wireless LANs: 802.11n and 802.11ac, Cambridge Edition:
Aruba 802.11ac Networks Validated Reference Design Guide:
Aruba Knowledge Base, U-APSD explained and debugged:
Aruba Technology Blog, 802.11 - TIM and DTIM Information Elements:
802.11 Power Management and other related articles, Rasika Nayanajith blog:
802.11v Basic Service Set (BSS) on AireOS WLC, Cisco technical notes: