To see why this is so, consider the standard power-saving protocols available today:

• Legacy power-save mode, the original 802.11 power-save methodology
• Unscheduled Automatic Power Save Delivery (u-APSD), which was defined in 11e as an amendment and enhancement to the base 802.11 standard
• Multiple-input/multiple-output (MIMO) power save, specific to 802.11n
• Power Save Multi-Poll (PSMP), also defined in 802.11n

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.