Now that we understand how message retrieval happens in a Wi-Fi network, we can start exploring the different power save modes and how devices in different power save modes retrieve their unicast data from an AP. This difference in data-retrieval behavior impacts their performance and battery lifetime, and, in turn, the effectiveness of the power save mode.
Legacy Power Save mode
Legacy Power Save mode (PS mode), as its name implies, is the power save mode used in legacy IEEE 802.11 standards. Despite not being a cutting-edge PS mode, it is still widely used in various applications for its simplicity.
Legacy PS mode utilizes the PS-Poll frame technique to retrieve buffered unicast data from the AP. In Legacy PS mode, the STA knows it has pending unicast data when it receives a DTIM beacon containing its own AID in the Partial Virtual Bitmap of the TIM element. Consequently, the device sends a special uplink control frame called the PS-Poll frame, containing its AID. This control frame informs the AP that the STA with this AID is ready to receive its unicast message. The AP responds with an acknowledgment message (ACK) followed by the STA’s unicast data.
The downlink frame received by the STA will contain the requested unicast data along with a More Data subfield. This field is set to value 1 when the AP wishes to inform the STA that there is still more data to be sent. To which the STA responds by sending another PS-Poll frame and the cycle described above is repeated. Once the STA has received all its data, the AP will toggle the More Data subfield in the downlink frame to value 0. This will signal to the STA that data exchange is to be concluded and the device is to go back to sleep.
This means that the STA must send a PS-Poll frame for every downlink frame, which is sub-optimal with regards to efficiency and reducing overhead control signaling.
Wireless Multimedia Power Save mode
Wireless Multimedia Power Save mode (WMM PS mode) is an alternative to Legacy power save mode. It still relies on DTIM beacons and TIM elements, but with some changes in its data-retrieval mechanisms, which enhances its performance for certain applications.
The WMM PS mode utilizes a technique called Unscheduled Automatic Power Save Delivery (UAPSD) to retrieve buffered unicast data from the AP. As mentioned above, an STA receives a DTIM beacon containing its own AID in the TIM element, indicating that the AP has buffered unicast messages for it. However, STAs in WMM PS mode can also wake up upon triggers from their application layer to check the beacons for their AIDs.
If an STA learns that the AP has buffered messages for it, it will respond by initiating the Service Period (SP) by sending the AP an uplink trigger frame in the form of a QoS Data frame or a QoS Null frame. The device also sets the MAX SP period, which indicates how many buffered frames the AP can send the STA during the time of one Service Period.
The AP responds by sending the device the buffered unicast messages. Downlink messages are sent one by one, with each message containing an End of Service Period bit (EOSP) with a value of 0. Once the AP sends the last downlink message to the device, it sets the EOSP bit to 1, indicating to the device that data exchange in this SP is now concluded. But if the More Data field is set to 1, this indicates to the device that there are still more buffered frames, so the device sends a new trigger frame to initiate a new SP. Once the EOSP and More Data fields are both set to 0, the device goes back to sleep.
Extended Power Save mode
Contrary to previously discussed power save modes, STAs in extended power save mode can extend their sleep period by not waking up every DTIM beacon. Instead, during the association procedure, the STA and AP will exchange a listen interval, which indicates the number of TIM beacon intervals the STA will skip before waking up to listen for beacon frames.
Listen Interval: Indicates the number of beacons the STA will skip before waking up to listen for beacon frames.
The device wake-up interval is adjusted to the nearest multiple of the DTIM period. For example, if the listen interval is set to 10, and the DTIM period is set to 3, the device wakes up every 9th beacon.
In extended power save mode, an STA can use a higher listen interval to allow for longer sleep periods, thereby conserving more power. This makes the extended power save mode particularly useful for devices that don’t need to be continuously connected to the network and can tolerate some amount of latency in data reception. The STA can plan its own sleep times in accordance with its own power requirements and network conditions, allowing for a more efficient use of power.
However, it is worth noting that while increasing the listen interval allows the STA to save more power, it also increases the latency of data reception and could lead to buffer overflow at the AP if the buffered data isn’t retrieved often enough. Therefore, choosing an appropriate listen interval involves balancing the trade-off between power conservation and data delivery efficiency.
API for power save modes
Power saving is a part of Zephyr’s Networking APIs. There are three main APIs relevant for power saving, the Network Management API, the Wi-Fi Management API, and the Network Interface API.
The Network Management API is used to send network requests or receive notifications on network events. An example of a network request is the Wi-Fi connection request which we recognize from previous lessons where we called net_mgmt() with NET_REQUEST_WIFI_CONNECT. Similarly, we used the network event NET_EVENT_WIFI_CONNECT_RESULT to be notified when the device had connected to the network. When it comes to power saving, the Network Management API is used to send network requests to enable or disable poser saving and to configure the power saving, such as setting different power save wakeup modes.
The Wi-Fi Management API is also familiar from previous lessons. For power saving, we will use it to manage the power save parameters.
When sending the network requests we provide a network interface to tie the request to the specific interface. This is where the Network Interface API comes in, which we use to retrieve and reference the Wi-Fi network interface.