Reference Manual

Redpine Signals, Inc. Proprietary and Confidential Page 83
RS9116 n-Link Linux and Android
Technical Reference Manual
Version 2.0
15 Power save Modes, Profiles and Parameters
The Power save modes and parameters are valid only for the Client mode. By default, the module's power save is disabled.
15.1 Power save Modes
The module broadly supports two types of power save modes. They are outlined below:
• Low Power (LP) Mode: The PHY (RF and Baseband) and LMAC sections are powered off but the UMAC and Host
Interface sections of the module are powered on and fed a low frequency clock. The module responds to
commands/requests from the Host processor immediately in this mode.
• Ultra-low Power (ULP) Mode: A majority of the module is powered off except for a small section which has a timer
and interrupts logic for waking up the module. The module cannot respond to the Host processor's
commands/requests unless and until it gets wake up because of timeout or because of an interrupt asserted by Host
processor. The sleep entry/exit procedures in this mode are indicated to the Host processor either through a packet
based or signal based handshake. This mode is supported only for SDIO host interface.
15.2 Power save Profiles
For each of the above power save modes, the module supports multiple power save profiles. They are outlined below:
• Deep Sleep: The module is in deep sleep mode when it is not connected to an Access Point. The duration of the Deep
Sleep is defined by the <sleep_duration> parameter of the set_ps_params command. For LP mode, a value of 0 for
the <sleep_duration> parameter programs the module to be in Deep Sleep mode indefinitely till it is woken up by the
Host processor via the host interface. The value of 0 is invalid for ULP mode and should not be used.
• Connected Power Save: In the connected state, the module can operate in Traffic Based Power Save Profile (PSP) or
Fast PSP. These profiles are used by the module to decide when to enter and exit from power save modes on the fly.
They have to be selected based on the performance and power consumption requirements of the end product.
• Traffic Based PSP: This profile is dependent on the <tx_threshold> and <rx_threshold> parameters, which indicate
transmit and receive throughput thresholds beyond which the module exits power save mode and below which the
module enters power save mode. The <tx_hysteresis> and <rx_hysteresis> parameters are also used in this profile.
This profile is enabled when non-zero values are assigned to the <tx_threshold> and <rx_threshold> parameters along
with the <monitor_interval> parameter.
• Fast PSP: This profile is a variant of the Traffic Based PSP which exits power save mode even for a single packet and
enters the power save mode if no packet is transferred for the <monitor_interval> amount of duration. This profile is
enabled independently for the Transmit and Receive directions if the <tx_threshold> and <rx_threshold> parameters
are assigned zero, respectively, while assigning a non-zero value to the <monitor_interval> parameter.
15.3 Wakeup Procedures and Data Retrieval
When in power save mode, the module wakes up at periodic intervals or due to certain events (like pending transmit
packets from the Host). At every wake up, the module has to poll the Access Point and check whether there are any
pending Rx packets destined for the module. The module uses different protocols to retrieve data from the Access Point
based on the protocol supported by the Access Point. These data retrieval methods (protocol-based) are used to further
classify the power save profiles described in the previous section into Max PSP, Periodic UAPSD and Transmit based
UAPSD.
The MAX PSP and UAPSD modes are explained below:
• Max PSP: In this mode, the module wakes up at the end of sleep period (Listen or DTIM interval) and retrieves
pending Rx packets from the Access Point by sending a PS-POLL packet. It also transmits any packets received
from the Host processor and then goes back to sleep. The parameters listed below are used by the module to
decide the period of sleep during power save, in the same order of priority:
a. <listen_interval_duration>
b. <dtim_interval_duration>
c. <num_beacons_per_listen_interval>