How to use optional wireless power-save protocols to dramatically reduce power consumption
Wireless standards offer many ways to reduce the power consumption but many are optional and results depend on the way the protocols are implemented by chip designers.
Unscheduled automatic power save delivery
Unscheduled Automatic Power Save Delivery (u-APSD) works in a similar way. This power-save protocol is based on devices polling the AP to get data, similar to what was described previously, but in this case, the sleep/wake periods are much more finely grained. Thus, u-APSD is much more appropriate for media streams such as VoIP.
Figure 4 shows how u-APSD works. Traditionally, a WLAN device carrying voice traffic would have to be in the listen state all of the time, because it could never know when the downlink packets were going to come. The device would go into transmit when it had something to send.
It could not afford to go into the sleep state and wake up for the next beacon, because that period of time is ≈ 100 ms, and VoIP packets might come once every 10 or 20 ms. So the device would generate far too much latency for voice traffic if it tried to use traditional power save methods.
Click here for Figure 4.
Figure 4: Unscheduled automatic power save delivery (u-APSD).
With u-APSD, the device tells the AP that it is operating according to this protocol, and the AP will save downlink packets for the device. In this case, however, as soon as the AP sees an uplink packet for the device, the AP automatically releases any downlink packets it has for the device.
This allows the device to sleep until it needs to send a VoIP packet on the uplink, and that packet on the uplink automatically releases any downlink packets destined for the device. There is a slight delay while in listen mode, while the AP gathers up and sends the packets down, at which time the device goes into receive mode.
Once it has received all the downlink packets (as before there is an indication in the last packet), the device returns immediately to the low-power sleep state.
One interesting aspect of this operation is that increasing the data rate improves power efficiency, because the device spends less time in active Tx and Rx, and a greater percentage of the time in sleep. Overall, this technique can result in very significant reductions in power consumption for VoIPabout one-sixth the power consumption without u-APSD.
MIMO power save
The next protocol method for saving power is MIMO power save, which has the potential to be more efficient overall because using multiple transmit-and-receive chains multiplies the data rate. These multiple transmit-and-receive chains increase power consumption, but also increase the achievable data rate by a larger amount.
As just explained, the higher data rate, achieved with only fractionally increased power can yield a net improvement in battery life. However, it is not useful to have multiple receive chains in the listen state just waiting for a packet to come.
Additionally, there is no reason to be running two full receive chains that are able to receive a high data rate when the device is waiting only for a low data rate beacon. Beacons are usually transmitted at a low data rate to ensure that all devices on the network can receive them successfully. Thus, beacons are not usually sent with MIMO encoding, so the device has no reason to be receiving with two receive chains.
To save power, the device could dynamically change the number of transmit and receive chains that are active for various conditions (Figure 5). This feature is called MIMO power save. For example, the device can dynamically switch between a 2x2 and a 1x1 configuration depending on whether it is in a battery-powered state or plugged in.
Click here for Figure 5.
Figure 5:2x2 MIMO downshifts to 1x1.
If the device is plugged in, it might as well be ready to go for a full data rate all the time. If the device is running on a battery, it should have the ability to downshift into the 1x1 mode more of the time. The ability to dynamically change the MIMO configuration, depending on the traffic load, can cut power consumption by about 30 percent when the traffic is low.
The client device can change its mode autonomously and indicate that choice to the AP. That setup keeps the AP from sending MIMO-encoded packets to a device that is only receiving with one chain. The AP can activate MIMO-mode operation dynamically by sending a short wake-up packet (a request to send, or RTS packet) to indicate that the AP is about to send a MIMO packet. The device can then wake up all of its receivers.
Dynamic MIMO Power Save is standardized in 802.11n, but it is an optional mode. Atheros is one of the few vendors that have actually implemented this mode.