Wi-Fi Multimedia (WMM) Power Save

To provide power saving while the mobile device is in a call, the Wi-Fi Alliance came up with the second power saving technique, WMM Power Save. This technique, based on the quality-of-service additions in the 802.11e amendment to the standard, acts as a parallel scheme to the legacy one, using similar concepts but in a way that avoids having to wait for beacons and can apply on a per-access-category basis.

If you notice, there is nothing in the standard that prevents clients that are using the legacy power save scheme from ignoring beacons, for the most part, and sending PS Polls whenever they want. If the client were sure that there is going to be a packet for it waiting every so often—say, 20 milliseconds—then it could just send PS Polls every 20 milliseconds, collect its data, and have real-time power save. Of course, this doesn't happen for legacy power save, because the client has no guarantee that it won't get some other frames rather than what it is looking for. However, this is the concept that WMM Power Save builds on.

WMM Power Save is optional, and support for it is signaled by the WMM information elements in the Association messages and the beacons. Unlike with legacy power save, WMM Power Save (capitalized, as it is a formal name) is aware of the WMM access categories and can apply to a subset of them. The two subsets are delivery-enabledaccess categories and trigger-enabled access categories.

First, let's start with the polling protocol. The client no longer checks the beacons to see if there is traffic. Instead, it is responsible for knowing that traffic is waiting for it, and how often. For phones, this is not a problem, as voice is bidirectional and consistent. Instead of sending a PS Poll frame, or using the PSNonPoll mechanism, the phone sends data frames in access categories that it has specified to be trigger-enabled. The access point looks for those data frames, and uses that as a trigger—just as it does in legacy with Power Save Poll frames—sending packets in response from the power save buffer. Those packets, however, can only come from the delivery-enabled access categories. Which categories are delivery- and trigger-enabled are usually specified in the Association Request from the client—there, a bitmask specifies which categories are legacy and which are delivery and trigger enabled together—or in TSPEC messages, which we will come to later.

Here's a common example. The phone associates, and tells the access point that it wants the voice category (AC_VO) to be delivery- and trigger-enabled. That means that the other three categories work on the legacy scheme. If packets come in for those other categories while the client is asleep, the TIM bit on the beacon will be set and the client will use legacy power save mechanisms to get the frames. But when a voice packet is sent to the access point, the access point silently holds onto the packet. The only way the client can get the voice packet is to send a voice packet of its own.

When it does, that causes the access point to respond with one or more voice packets in its buffer. Unlike with legacy power save, the client can ask for more than one packet at a time. Using the concept of a service period, which is set at Association time by the client and specifies the number of frames the client wants to get for every trigger (either two, four, six, or all), the access point will send out the correct number of frames. The last frame, whether because the buffer is empty or the service period has been exceeded, will have a special end of service period (EOSP) bit set in the QoS header. Once the client gets that frame, it can go back to sleep.

As you can see, the legacy and WMM Power Save schemes operate simultaneously and independently. The only overlap is that the client goes into to power save mode for both schemes simultaneously. This means that devices that are actively using WMM Power Save should never use the PSNonPoll method during that time, because the client waking up from power save mode will cause the access point to send all frames, whether they are from the legacy or WMM Power Save access categories.

The capability to support WMM Power Save should be considered nearly mandatory for most voice equipment. Some mobile devices use proprietary mechanisms that may or may not be supported by every access point, but the trend is towards using WMM Power Save. 

Legacy Power Save | Voice Mobility over Wi-Fi

The first mode, known as legacy power saving because it was the original power saving technique for Wi-Fi, is used for saving battery during standby operation.

This power save mode is not designed for quality-of-service applications, but rather for data applications. The way it works is that the mobile device tells the access point when it is going to sleep. After that time, the access point buffers up frames directed to the mobile device, and sets a bit in the beacon to advertise when one or more frames are buffered. The mobile device is expected to wake every so many beacons and look for its bit set in the beacon. When the bit is set, the client then uses one of two mechanisms to get the access point to send the buffered frames.

This sort of system can be thought of as a paging mechanism, as the client is told when the access point has data for it—such as notification of an incoming call. Figure 1 shows the basics of the protocol.

 
Figure 1: Wi-Fi Legacy Power Save

The most important part of the protocol is the paging itself. Each client is assigned an association ID (AID) when it associates. The value is given out by the access point, in a field in the Association Response that it sent out when the client connected to it. The AID is a number from 1 to 2007 (an extremely high number for an access point) that is used by the client to figure out what bit to look at in the beacon. Each beacon carries a Traffic Indication Map (TIM), which is an abbreviated bit field. Each client who has a frame buffered for it has its bit set in the TIM, based on the AID. For example, if a client with AID of 10 has one or more frames buffered for it, the tenth bit (counting from zero) of the TIM would be set.

Because beacons are set periodically, using specific timing that ensures that it never goes out before its time, each client can plan on the earliest it needs to wake up to hear the beacon. That doesn't guarantee that the client will hear the beacon at exactly that time, however. Beacons can be delayed if the air is occupied at that time. Furthermore, because beacons are sent out as broadcasts, the client might just miss the beacon or the beacon can be collided with. If the client does hear the beacon, it can then go to sleep so long as no traffic is buffered for it.

Clients may also skip beacons. They would do this to save additional battery, at the expense of increasing the amount of time the frames would be buffered. Clients usually let the access points know how many beacons they will skip by sending a listen interval in their Association Request messages. A listen interval of 1 means that the client will wake for every beacon; a listen interval of 10 means that the client will wake only for every tenth beacon. Be careful, however; some clients do not follow the listen interval they state, waiting either for more or less beacons than they advertise.

The client signals that it is going to sleep by using the power management bit in any unicast frame it sends to the access point (except for non-Action management frames). The power management bit is in the Frame Control field for the frame. When the client sends a frame with the power management bit set and when it gets an Acknowledgement in response, it knows that the access point has heard the client's change of state and can now go to sleep. From this moment on, the access point will buffer frames, until the client sends any frame to the access point with the power management bit not set. That signals that the client is now awake, and can be sent packets as usual.

While the client is in power save mode, and it wakes to find that its TIM bit is set to signify that it has frames available for it, the client has two choices on how to gather those frames. The first choice is known as the PSPoll mechanism, and uses the Power Save Poll (PS Poll) frames. After the beacon with the client's TIM bit set, the client would send a PS Poll frame to the access point. This frame, which is usually acknowledged right away, triggers the access point to deliver exactly one of the buffered frames for the client. That buffered frame is put into the transmit queue, using the appropriate access category for WMM. The frame that is sent also has its More Data bit in the Frame Control field set if there are subsequent frames that are buffered. Once the client has the frame, it can chose to send another PS Poll to get another frame. This one-PS-Poll/one-data-frame exchange continues until the access point's buffer is drained or the client wishes to sleep more.

The other option the client has is to use the PSNonPoll mechanism. This mechanism is quite simple: the client simply sends a data frame, usually a Null data frame, stating that it is no longer sleeping, by clearing the power management bit. The access point will proceed to queue all of the buffered frames, each using its own WMM access category. The client can then wait for a certain amount of time, hoping that it got all of the frames it was going to get, after which it can send another Null data frame, signifying it is going back to sleep. Any frames that may have still been in a transmit queue might get buffered again by the access point, for a later PSNonPoll exercise. The advantage of the PSNonPoll mechanism is that it is simple and doesn't require a significant back-and-forth. The disadvantage is that the client has no way of knowing if there are any remaining frames for it, without going to sleep and waiting for the next beacon.

The choice between PSPoll and PSNonPoll modes is often left up to the client's software implementation, and not exposed to you. However, some clients do give a choice up front, or have specific behavior where they will use one method or the other, depending on how aggressive you set its power save settings to (using a slider, say). It should be clear that neither mode is good for quality-of-service traffic, because the client can be forced to wait as much as a beacon interval (times its listen interval) before it finds out traffic is available. If the beacon interval is set to the typical 100 milliseconds, and the listen interval is 10, then that can be up to a second of delay.

Broadcast and multicast frames are also covered in the legacy scheme. However, no polling is necessary for those frames to be delivered. Instead, the access point sets aside a certain number of the beacons for multicast traffic. If any client on the access point is in legacy power save mode, the access point will buffer all multicast traffic. The special beacons known as Delivery Traffic Indication Messages (the poorly named DTIM) are just like regular beacons, except that they come every so many beacons—when the next one is coming is signaled as a part of the TIM in every beacon—and they signal if multicast traffic is buffered. If multicast traffic is buffered, the TIM has the zeroth bit, corresponding to AID 0, set. If clients receive a beacon with that bit set, they know that the next frames coming from the access point will be all of the multicast frames buffered. Each multicast frame, except for the last one, will have the More Data bit set. Thus, clients can stay awake to collect all multicast traffic, and then go back to sleep after the last multicast data frame, with the cleared More Data bit, comes through. (Of course, if that last frame is lost, being multicast, the clients will have to decide on their own when to return to sleep.) The consequence of the all-or-nothing multicast buffering is that multicast traffic on Wi-Fi when any device is in power save is not generally suitable for real-time traffic! Look for architectures that provide solutions for this problem if real-time multicast is a priority for your network.

Finally, I haven't gone into details on how the TIM bits are compressed. It is not easy to read the TIM bits by hand, but a good wireless protocol analyzer will be able to read them for you, and let you know which AIDs are set in any beacon.