VHT TXOP Power Save

Battery power is a precious resource and various mechanisms have been introduced in the 802.11 standard to protect the same. The VHT TXOP power save feature is one such feature.

TXOP stands for – Transmit Opportunity. All 802.11 stations (Access Point as well as non-Access Point stations) contend for the medium as per EDCA rules and on winning the medium – obtain right of transmission for a particular amount of time. This Time is termed as TXOP.

When a particular 802.11 Station wins medium contention and obtains the right of transmission – the other 802.11 stations in the network need to wait for TXOP duration before they can again contend for the medium for their own right of transmission. In such a scenario – TXOP Power save feature allows the other 802.11 Stations to power down till the current TXOP is completed and hence save up on battery power.

An 802.11 station when in active mode will operate in TXOP-Power Save mode during a TXOP operation if it supports TXOP Power save. that is, (dot11VHTTXOPPowerSaveOptionImplemented is set to true)

The 802.11 stations indicate their support for TXOP power save mode by setting the TXOP Power Save field in the VHT capabilities field to ‘1’. If this parameter is set to ‘0’ – TXOP power save is not supported by the station.

Fig Courtesy: 802.11-2016 Standard

The Access Point needs to support the 802.11 stations to go into TXOP power save mode. The Access point achieves this by setting the TXVECTOR parameter – TXOP_PS_NOT_ALLOWED to Zero. If the above TXVECTOR parameter is set to Zero in a received frame by a non-AP station – the 802.11 station can sleep for the duration of the current TXOP. If the TXVECTOR parameter is set to 1, then the 802.11 stations cannot enter doze state

The below figure depicts the TXOP power save operation



Rules for an 802.11 Station to enter into TXOP Power Save mode

The 802.11ac standard mandates the following set of rules for an 802.11 non-AP station to enter into Doze state. The non-AP station can enter doze state if any one of the below conditions is satisfied.

  • On receipt of a VHT MU PPDU, the STA determines that it is not a member of the group indicated by the RXVECTOR parameter GROUP_ID.
  • On receipt of an SU PPDU, the STA determines that the RXVECTOR parameter PARTIAL_AID is not equal to 0 nor does it match the STA’s partial AID.
  • The STA finds that the PARTIAL_AID in the RXVECTOR matches its partial AID but the RA in the MAC header of the corresponding frame that is received correctly does not match the MAC address of the STA.
  • The STA receives a frame with an RXVECTOR parameter NUM_STS equal to 0 if it is a member of group indicated by RXVECTOR GROUP_ID.
  • In a received VHT NDP Announcement frame, the STA finds that the RXVECTOR parameter PARTIAL_AID is 0 and the AID in the STA Info field is not its AID.
  • The STA receives a frame intended for it with the More Data field equal to 0 and the Ack Policy subfield in the QoS Control field is equal to No Ack or sends an acknowledgment if Ack Policy subfield is not equal to No Ack.


Leave a Reply

Your email address will not be published. Required fields are marked *