This two-part series of articles provides an overview of today's power-saving methods, ranging from power-reduction protocols and system optimization to low-power circuit design and process technology. Since protocol and system solutions have the greatest influence on power, the articles focus on how these methods can minimize power consumption while ensuring high performance of the wireless system.
Considering just the 802.11 wireless portion of a VoIP handset, the battery would last for more than 100 hours in continual VoIP mode on a standard 3.7V, 800mAh phone battery (as demonstrated by Atheros next week at COMPUTEX TAIPEI 2008).
Similarly, considering just the power consumption of the Wi-Fi system, a portable media player can download over 200 gigabytes of data on the same battery charge. This level of power efficiency is possible without requiring users to switch the Wi-Fi functionality on and off, because the techniques described in these articles automatically manage the wireless power modes.
Part One
This first article in the series begins with a brief look at protocol modes and then provides an overview of standard power-reduction protocols for wireless systems. While WLAN and Bluetooth standards define a number of power-reduction protocols, many of these protocols are optional. Even among chips that implement the protocols, the way the protocols are implemented can make a big difference in power consumption from one chip to another. An understanding of these modes is thus vital for system developers who want to minimize the power consumption of WLAN and Bluetooth products.
Protocol modes
As wireless devices operate, their physical layers (PHYs) can be considered to be in one of five states:
(ul>
These wireless physical states are used in combination to create wireless protocol modes:
To illustrate the contrast between one protocol mode and another, Figure 1 shows the amount of time spent in various states when searching for a network, while Figure 2 shows the states for media traffic flow. When searching for a network, the device spends almost all its time in sleep mode.
Surprisingly, the device still spends most of its time in sleep mode when sending and receiving media traffic. The required data rate is lower than the radio capacity, and the device can be in this state continuously for hours.
Click here for Figure 1.
Figure 1: Wireless power mode: Searching for a network.
Click here for Figure 2.
Figure 2: Wireless power mode: Media traffic.
In the max-throughput state, a wireless device is trying to move a large amount of data as quickly as possible (e.g., a file transfer). Devices are usually in this mode for a short burst. The higher the data rate, the sooner the device can go back to idle.
To see why this is so, consider the standard power-saving protocols available today:
Figure 3 shows how the legacy power-save mode works. The device tells the access point (AP) that it is going to sleep. While the device is in sleep mode, the AP holds the data coming to that device.
Periodically, the device wakes up to listen for a beacon. In the beacon, the AP indicates whether there is data traffic and therefore whether the device should wake up and receive the data.
The AP uses a special kind of beacon called a Delivery Traffic Indication Message (DTIM) that indicates whether there is uni-cast traffic specific to that device.
Click here for Figure 3.
Figure 3: Legacy power-save modes.
Broadcast and multi-cast traffic is also preserved for devices that are in power save. The AP holds these messages and transmits them immediately following the DTIM beacon.
Devices that wake up to listen for the beacon stay awake to receive the broadcast and multi-task traffic. The devices go back to sleep as soon as the broadcast and multi-cast traffic is completed if the AP has no uni-cast traffic specifically for them.
If the beacon indicates that the AP has uni-cast traffic for a specific device, that device has two options for getting its traffic. It may send back a power-save poll message to indicate that the AP should release a particular number of packets. If a single power-save poll does not drain the reserved packets, the device can issue additional power-save polls to get additional packets.
Once the AP has released all the data it has stored for a particular device, the AP indicates in the final packet that all the data for that device has been sent, and the device can go back to sleep.
The other method is for the device to indicate to the AP that it is coming out of the power-save state and will be continuously awake until further notice and can receive its packets at any time.
This can be more efficient if there are a number of packets since multiple power-save polls do not need to be sent. The wake/sleep indication can be sent with a data packet or a power-save poll.
The key to making this method work is knowing when a device should go in and out of the power-save state. As described earlier, a device being in sleep or standby reduces power consumption dramatically. However, being in the power-save state also increases latency.
In fact, if a packet is coming to a device, the time it takes to receive that packet may be the latency of waiting for an entire beacon cycle, after which time the device wakes up, polls the AP to get that packet, and then eventually receives that packet. That latency can be on the order of 300 ms if the DTIM beacons are coming every 300 ms, which is traditional in WLAN networks.
In addition to increasing latency, the power-save state reduces throughput. Spending time moving in and out of sleep, or sending power-save polls, causes a decrease in aggregate throughput.
To help improve this situation, good algorithms predict when there will and will not be traffic. Based on these algorithms, devices go into power-save states when it looks like there is going to be a sustained period without traffic.
The devices come out of the state and stay in fully awake listen/receive/transmit states when the algorithms predict that there will be traffic.
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 VoIP—about 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.
Click here for Figure 6.
Figure 6: VoIP being carried by PSMP.
PSMP emulates a TDMA system within the larger 802.11 system. The PSMP beacon essentially carves out time for a TDMA mode of operation. The beacon gets all other devices to be silent after they hear it, and it carries a schedule for when the AP is going to send downlink packets to the PSMP-capable devices—different VoIP phones, for example. The AP also uses the beacon to schedule these devices' uplinks.
Contrasting PSMP with APSD is interesting. In the latter mode, the device is only spending its time sending uplink traffic and getting the ACKs, or receiving downlink traffic and sending the ACKs. It is very efficient.
In the case of PSMP, a device has to wake up and receive the PSMP beacon, which is pure overhead. Depending on how many other wireless devices are in the network, and the timing of the activities, the device may not have time to transition into the sleep mode, wake back up, and get a packet.
It may be that the gap in time is short enough that the device must stay awake while other devices receive their VoIP packets. If so, that time is also wasted overhead. The same kind of situation can happen with the transmit period of PSMP operation.
Yet another PSMP inefficiency occurs because the wireless channel can vary rapidly. As devices move around, the supportable data rate increases and decreases. As a result, PSMP devices need to be conservative and use a lower data rate because failed packets are a burden on the system.
If a packet fails in a TDMA system, on the other hand, the system has to make up for that failure at a much later time. The system has to allocate a new time slot to retransmit the packet, because the whole idea behind TDMA is to pack transmissions right next to each other. There is no time allowed for retransmitting failed packets.
In contrast, with APSD, a packet might fail, but it can be retransmitted immediately, without centralized coordination. This makes the penalty for a failed packet much lower, and allows APSD devices to use higher data rates more aggressively, reducing power consumption (Figure 7).
Click here for Figure 7.
Figure 7: VoIP being carried by APSD.
All of these factors cause PSMP to have a significant amount of overhead, so this mode only pays off if the number of VoIP nodes associated with an AP exceeds approximately 15. Under APSD, the devices wake up according to their own timing and are not coordinated. With that many devices contending for the airwaves, they start colliding or waiting for each other to finish their transmissions.
As a rule of thumb, with a modest number of VoIP devices, APSD is the best approach. A network with a large number of VoIP calls (>15) going simultaneously to the same access point might benefit from PSMP.
Sniff Subrating
One of these methods is to use the capabilities of sniff subrating, which was standardized in the Bluetooth 2.1 specification. Sniff subrating allows the period between listen and transmit periods to be adjusted dynamically. Similar to the beacons and sleep periods in WLANs, Bluetooth devices have standby periods. After these periods, a device wakes up and sniffs, and the sniff timing can be negotiated.
Sniff subrating is particularly beneficial for bursty traffic from devices such as mice and keyboards. When a mouse is moving, it needs to be quite reactive, but when the mouse is just sitting still, it should go into a very low-power mode. Using sniff subrating, a Bluetooth device can constantly renegotiate how long it goes to sleep and how often it wakes up and transmits data.
Simultaneous Sniff and HV3 Operation
A Bluetooth device operating in headset mode (HV3) is active about one-third of the time. It is possible for such a device to transfer data in two-thirds the time that the headset voice data is not consuming. Originally these devices had to listen at the start of each time slot to see if such data were present.
However, starting with the Bluetooth 2.0 specification, the device can use the sniff mode while HV3 is running to remain ready for data transmissions while dissipating much less power. In this way, the device operating in HV3 mode can sleep for most of the time that it is not transmitting or receiving voice data, waking only occasionally to see if there is additional data that needs to be received in other slots. Unfortunately, some manufacturers have not implemented this feature.
Transmit Power Control
Bluetooth technology includes a sophisticated transmit power control mechanism. When two Bluetooth devices are close to each other, they can successfully communicate with lower transmit power. Reducing the transmit power reduces the draw on the battery from the RF power amplifier.
The Bluetooth power control system is a closed-loop power control system. The receiver notifies the transmitter if the power level can safely be reduced. The same procedure can operate simultaneously in the other direction. The mechanism is quite reliable because the receiver is able to specify the exact power level it needs to receive adequately.
Getting results from power-reduction protocols
Wireless communication standards offer many ways to reduce the power consumption of wireless chips. The operating modes combine with the power-reduction protocols described in this article to provide many choices for managing power consumption.
Many of these choices are optional, and results depend greatly on the way the protocols are implemented by chip designers. The next article in this series will show how implementation details—such as the speed of transitioning from one power mode to another—can have a profound affect on overall power consumption.
Part 2 of this article is available at Power-reduction details determine a chip's overall power consumption (Part 2 of 2).
About the author
Bill McFarland is Chief Technology Officer for Atheros Communications, a semiconductor company specializing in the development of high-performance wireless systems solutions.
