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.
No comments:
Post a Comment