Dynamic power save schemes in wireless communications

Abstract

Techniques pertaining to dynamic power save schemes in wireless communications are described. An apparatus (e.g., DPS enabled station (STA) ) receives a frame from a DPS assisting STA with an indication of whether to remain in a low capability (LC) mode or to switch to a high capability (HC) mode. The apparatus then performs a frame exchange with the DPS assisting STA: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode. In performing the frame exchange in the LC mode, the apparatus performs the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

Description

DYNAMIC POWER SAVE SCHEMES IN WIRELESS COMMUNICATIONSCROSS REFERENCE TO RELATED PATENT APPLICATION

[0001] The present disclosure is part of a non-provisional patent application claiming the priority benefit of U.S. Provisional Patent Application Nos. 63 / 790,811, 63 / 854,669 and 63 / 868,445, filed 18 April 2025, 31 July 2025 and 22 August 2025, respectively, the contents of which herein is incorporated by reference in their entirety.TECHNICAL FIELD

[0002] The present disclosure is generally related to wireless communications and, more particularly, to dynamic power save schemes in wireless communications.BACKGROUND

[0003] Unless otherwise indicated herein, approaches described in this section are not prior art to the claims listed below and are not admitted as prior art by inclusion in this section.

[0004] In wireless communications such as Wi-Fi (or WiFi) and wireless local area networks (WLANs) under the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, for most typical usage models and over a long-term average, a non-access point (AP) station (STA) is awake and needs to be in a listen mode with its full bandwidth, number of spatial streams (NSS) and modulation and coding scheme (MCS) capabilities to prepare to receive or transmit data. However, when the non-AP STA is not actually receiving or transmitting data, the listen operation tends to contribute to the largest portion of power consumption at the non-AP STA. Furthermore, when in a receive mode and in a triggered transmission mode, the non-AP STA needs to be prepared to receive or transmit data with its full bandwidth, as well as NSS and MCS capabilities.

[0005] Dynamic Power Save (DPS) mode for non-AP STAs provides a mechanism that allows the non-AP STA to stay on a low capability (LC) mode during the listening period to conserve power and, when necessary, transition from LC mode to a high capability (HC) mode during the receive and triggered transmission periods. Some DPS non-AP STAs may operate in a very low capability mode, which only supports receiving a 20MHz bandwidth physical-layer protocol data unit (PPDU) with one spatial stream and in a non-High-Throughput (non-HT) PPDU format. Moreover, some DPS non-AP STAs may operate in a parameterized LC mode, in which the non-AP STA indicates its maximum bandwidth, maximum number of spatial streams, and maximum MCS that are supported during the parameterized LC mode.

[0006] A DPS non-AP STA (herein interchangeably referred to as a “DPS STA” ) may set “ICF-Required” to 0, which requires that a DPS assisting AP to initiate an initial control frame (ICF) and initial control response frame (ICR) exchange (ICF-ICR) to trigger the DPS non-AP STA to transition from the LC mode to the HC mode only prior to frame exchanges that are intended to be transmitted in high-capability transmission parameters. In some cases, the DPS assisting AP may transmit frames other than ICF to the DPS STA within lower capability parameters (e.g., parameterized LC mode) . However, if the AP does not send an ICF, then the non-AP STA would not transition from the LC mode to the HC mode during a receive or triggered transmission period to reduce power consumption.

[0007] Similarly, a DPS mobile AP may set “ICF-Required” to 0 in most cases, which requires that a DPS assisting non-AP STA to initiate ICF / ICR to trigger the DPS mobile AP to transition from the LC mode to the HC mode only prior to the frame exchanges that are intended to be transmitted in high-capability transmission parameters. However, there are many other features that require ICF-ICR frame exchange prior to any frame exchanges, such as dynamic subband operation (DSO) , non-primary channel access (NPCA) , dynamic unavailability operation (DUO) , enhanced multi-link single radio (EMLSR) operation, channel protection (MU-RTS / CTS) , and so on. If a DPS non-AP STA is in the LC mode with “ICF-required” set to 0, when a DPS assisting AP obtains a transmission opportunity (TXOP) and performs DSO, NPCA operation, or channel protection addressed to the STA, or the DPS non-AP STA is a DUO enabled and / or EMLSR enabled device as the TXOP responder, the AP would always start with an ICF, which means that the DPS non-AP STA in the LC mode would always be triggered to transition to the HC mode under the circumstances, regardless of whether the frame exchanges are intended to be transmitted in lower-capability or higher-capability parameters. Such situation would not be beneficial for the DPS STA in terms of reduction in power consumption.

[0008] Therefore, there is a need for a solution for dynamic power save schemes in wireless communications.SUMMARY

[0009] The following summary is illustrative only and is not intended to be limiting in any way. That is, the following summary is provided to introduce concepts, highlights, benefits, and advantages of the novel and non-obvious techniques described herein. Select implementations are further described below in the detailed description. Thus, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0010] An objective of the present disclosure is to provide schemes, concepts, designs, techniques, methods, and apparatuses pertaining to dynamic power save schemes in wireless communications. It is believed that implementation of one or more schemes proposed herein may address or otherwise alleviate the aforementioned issue (s) .

[0011] In one aspect, a method may involve a DPS enabled STA receiving a frame from a DPS assisting STA with an indication of whether to remain in a LC mode or to switch to a HC mode. The method may also involve the DPS enabled STA performing a frame exchange with the DPS assisting STA with the DPS enabled STA being: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode. In performing the frame exchange in the LC mode, the method may involve the DPS enabled STA performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

[0012] In another aspect, a method may involve a DPS assisting STA transmitting a frame to a DPS enabled STA with an indication of whether to remain in a LC mode or to switch to a HC mode. The method may also involve the DPS assisting STA performing a frame exchange with the DPS enabled STA with the DPS enabled STA being: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode. In performing the frame exchange in the LC mode, the method may involve the DPS assisting STA performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

[0013] In another aspect, an apparatus, as a DPS enabled STA, may include a transceiver configured to communicate wirelessly and a processor coupled to the transceiver. The processor may receive a frame from a DPS assisting STA with an indication of whether to remain in a LC mode or to switch to a HC mode. The processor may also perform a frame exchange with the DPS assisting STA with the DPS enabled STA being: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode. In performing the frame exchange in the LC mode, the processor may perform the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

[0014] It is noteworthy that, although the description provided herein may be in the context of certain radio access technologies, networks and network topologies such as Wi-Fi / WiFi, the proposed concepts, schemes and any variation (s)  / derivative (s) thereof may be implemented in, for and by other types of radio access technologies, networks and network topologies such as, for example and without limitation, Bluetooth, ZigBee, 5th Generation (5G)  / New Radio (NR) , Long-Term Evolution (LTE) , LTE-Advanced, LTE-Advanced Pro, Internet-of-Things (IoT) , Industrial IoT (IIoT) and narrowband IoT (NB-IoT) . Thus, the scope of the present disclosure is not limited to the examples described herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of the present disclosure. The drawings illustrate implementations of the disclosure and, together with the description, serve to explain the principles of the disclosure. It is appreciable that the drawings are not necessarily in scale as some components may be shown to be out of proportion than the size in actual implementation to clearly illustrate the concept of the present disclosure.

[0016] FIG. 1 is a diagram of an example network environment in which various solutions and schemes in accordance with the present disclosure may be implemented.

[0017] FIG. 2 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0018] FIG. 3 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0019] FIG. 4 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0020] FIG. 5 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0021] FIG. 6 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0022] FIG. 7 is a diagram of an example design under a proposed scheme in accordance with the present disclosure.

[0023] FIG. 8 is a block diagram of an example communication system under a proposed scheme in accordance with the present disclosure.

[0024] FIG. 9 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.

[0025] FIG. 10 is a flowchart of an example process under a proposed scheme in accordance with the present disclosure.DETAILED DESCRIPTION

[0026] Detailed embodiments and implementations of the claimed subject matters are disclosed herein. However, it shall be understood that the disclosed embodiments and implementations are merely illustrative of the claimed subject matters which may be embodied in various forms. The present disclosure may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that the description of the present disclosure is thorough and complete and will fully convey the scope of the present disclosure to those skilled in the art. In the description below, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations. Overview

[0027] Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and / or solutions pertaining to dynamic power save schemes in wireless communications. According to the present disclosure, a number of possible solutions may be implemented separately or jointly. That is, although these possible solutions may be described below separately, two or more of these possible solutions may be implemented in one combination or another. The various solutions and schemes implement the proposed schemes between APs and non-AP STAs. Accordingly, the various solutions and schemes proposed herein may address or otherwise alleviate the issues described above.

[0028] FIG. 1 illustrates an example network environment 100 in which various solutions and schemes in accordance with the present disclosure may be implemented. FIG. 2 -FIG. 10 illustrate examples of implementation of various proposed schemes in network environment 100 in accordance with the present disclosure. The following description of various proposed schemes is provided with reference to FIG. 1 -FIG. 10.

[0029] Referring to FIG. 1, network environment 100 may include at least a first STA, or STA 110, and a second STA, or STA 120. One of STA 110 and STA 120 may be an AP STA (herein interchangeably referred to as “AP” ) and the other of STA 110 and STA 120 may be a non-AP STA (herein interchangeably referred to as “STA” ) associated with the AP STA. STA 110 and STA 120 may be part of a basic service set (BSS) . While there may be additional STAs involved in network environment 100 under one or more schemes proposed herein, for simplicity only two STAs (STA 110 and STA 120) are shown in FIG. 1 with the understanding that additional STAs may be involved. Each of STA 110 and STA 120 may be configured to implement various proposed schemes in accordance with the present disclosure as described below. It is noteworthy that, while the various proposed schemes may be individually or separately described below, in actual implementations some or all of the proposed schemes may be utilized or otherwise implemented jointly. Of course, each of the proposed schemes may be utilized or otherwise implemented individually or separately.

[0030] In the present disclosure regarding DPS modes and parameters, a STA that indicates “DPS assisting Support” in the Capabilities element in Management frames that it transmits is referred to as a DPS assisting STA, which may be a DPS assisting non-AP STA or a DPS assisting AP. Additionally, a STA that indicates “DPS Support” and has enabled its DPS mode is referred to as a DPS STA, which may be a DPS non-AP STA or a DPS mobile AP. Moreover, a DPS STA may indicate, during a DPS enablement procedure or a DPS parameter update procedure, an “ICF Required” field with the value of the “ICF Required” field set to either 0 or 1. In case that the “ICF Required” field set to 0, a DPS assisting STA may initiate frame exchanges with a DPS STA by sending an ICF if it intends to transmit to the DPS STA in the HC mode. For instance, the DPS assisting STA may exchange frames with the DPS STA without being required to send an ICF as long as the frames use parameters consistent with the LC mode of both STAs. In case that the “ICF Required” field set to 1, the DPS assisting STA may initiate any frame exchange with the DPS STA by sending an ICF. For instance, the DPS assisting STA may not exchange any frames with the DPS STA unless they are preceded with an ICF. Furthermore, a DPS STA may enable one of the following lower-capability modes: (1) default mode, and (2) parameterized mode. The default mode may involve a bandwidth (BW) of 20MHz, one spatial stream (1SS) , and a non-HT PPDU format with a limited data rate of 6, 12 or 24 mega-bits per second (Mbps) . The parameterized mode may involve PPDU formats up to Ultra High Reliability (UHR, also known as Wi-Fi 8) PPDUs where the parameters are the maximum BW, maximum NSS, and / or maximum MCS announced by the DPS STA when enabling the DPS mode. Accordingly, a STA that intends to use the parametrized mode may set the “ICF Required” field / bit to 0 with some exceptions.

[0031] Under a proposed scheme in accordance with the present disclosure regarding explicit DPS (HC mode) switch indication in an ICF, if a DPS non-AP STA is operating on an EMLSR link, it shall always set the “ICF Required” field to 1 when it enables DPS mode, which means that a DPS non-AP STA shall not enable DPS mode with the “ICF Required” field set to 0 if the DPS non-AP STA is operating on an EMLSR link. For instance, if the DPS non-AP STA operating on an EMLSR link enables default LC mode or parameterized LC mode, once the DPS STA switches to the EMLSR link after receiving the ICF (e.g., multi-user request-to-send (MU-RTS) , buffer status report poll (BSRP) , BSRP non-trigger based (NTB) ) addressed to it, the DPS STA may stay in the LC mode if the ICF indicates ‘no DPS HC mode switching (i.e. Remain in LC mode) ’ by including an explicit DPS HC mode switching indication bit (e.g., by setting the bit to 0) . Otherwise, the DPS STA may switch to the HC mode.

[0032] Under a proposed scheme in accordance with the present disclosure regarding explicit DPS (HC mode) switch indication in an ICF, if a DPS non-AP STA enabled DUO operation, it shall always set the “ICF Required” field to 1 when it enables DPS mode, which means that a DPS non-AP STA shall not enable DPS mode with the “ICF Required” field set to 0 if the DPS non-AP STA enabled DUO operation. For instance, if the DPS non-AP STA enabling DUO operation enables default LC mode or parameterized LC mode, once the DPS STA receives the ICF (e.g., buffer status report poll (BSRP) , BSRP non-trigger based (NTB) ) addressed to it, the DPS STA may stay in the LC mode if the ICF indicates ‘no DPS HC mode switching (i.e. Remain in LC mode) ’ by including an explicit DPS HC mode switching indication bit (e.g., by setting the bit to 0) . Otherwise, the DPS STA may switch to the HC mode.

[0033] Under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in an ICF, if a DPS non-AP STA is operating on an EMLSR link, it may set the “ICF Required” field to 1 due to the requirement of EMLSR operation, unless the STA enabled DUO mode or control frame protection (CFP) mode (in which case it may set the “ICF Required” field set to 0) . For instance, if the DPS non-AP STA operating on an EMLSR link enables default LC mode or parameterized LC mode, once the DPS STA switches to the EMLSR link after receiving the ICF (e.g., multi-user request-to-send (MU-RTS) , buffer status report poll (BSRP) , BSRP non-trigger based (NTB) ) addressed to it, the DPS STA may stay in the LC mode if the ICF indicates ‘no DPS HC mode switching / remain in LC mode’ by including an explicit DPS HC mode switching / remain in LC mode indication bit / subfield (e.g., by setting the bit to 0) . Otherwise, the DPS STA may switch to the HC mode if the ICF sets the bit to 1.

[0034] Under the proposed scheme, if a DPS non-AP STA enables a DUO operation, it may set the “ICF Required” field to 0 or 1. For instance, if the DPS non-AP STA enabling DUO operation enables default LC mode or parameterized LC mode, once the DPS STA receives an ICF (e.g., BSRP GI3, also known as BSRP NTB) addressed to it, the DPS STA may stay in the LC mode if the ICF indicates ‘no DPS switching’ by including an explicit DPS switch indication bit / subfield (e.g., by setting the bit to 0) . Otherwise, the DPS STA may switch to HC mode if the ICF sets the bit to 1.

[0035] Under the proposed scheme, if a DPS non-AP STA is neither operating on an EMLSR link nor enables DUO operation, it may set the “ICF Required” field to 0 or 1 in the default LC mode and may set the “ICF Required” field to 0 in the parameterized LC mode. For instance, when the DPS non-AP STA sets the “ICF Required” field to 0, if it is an intended responder of a TXOP, once it receives an ICF (e.g., BSRP, BSRP GI3, MU-RTS) addressed to it, the DPS non-AP STA may stay in the LC mode if the ICF indicates ‘no DPS HC mode switching / remain in LC mode’ by including an explicit DPS switch indication bit / subfield (e.g., with the bit set to 0) . Otherwise, the DPS non-AP STA may switch to the HC mode if the ICF sets the bit to 1.

[0036] FIG. 2 illustrates an example design 200 under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in an ICF. Under the proposed scheme, a DPS assisting AP may include an explicit DPS HC Mode switch / Remain in LC mode indication in the User Info field of an ICF (e.g., MU-RTS, BSRP, BSRP GI3 / BSRP NTB) that it sends, if at least one of the intended recipients is a DPS STA with ‘explicit DPS switch / Remain in LC mode’ enabled. For instance, a “DPS HC Mode switch / Remain in LC mode” subfield / bit may be included in the UHR variant User info field of the ICF (e.g., with the bit set to 0 meaning that the DPS STA may stay in the LC mode or switch to the HC mode; or with the bit set to 1 meaning that the DPS STA needs to switch to the HC mode) . Alternatively, or additionally, the “SS Allocation” subfield of a UHR variant User Info field associated with the ICF may include the “DPS HC Mode switch / Remain in LC mode” subfield / bit (e.g., a 1-bit subfield) , while the “Number of Spatial Streams” subfield may have one or two bits. The DPS Switch subfield may indicate that the DPS STA may stay in the LC mode (e.g., if set to 0) or may need to switch to the HC mode (e.g., if set to 1) , if “ICF Required” subfield is most recently set by the DPS STA to 0. Otherwise, the DPS Switch subfield may be set to 1. Moreover, the Number Of Spatial Streams subfield may indicate the number of spatial streams and may be set to the number of spatial streams minus 1 with a maximum value of 1. Referring to FIG. 2, which shows an example Spatial Stream (SS) Allocation subfield format under the proposed scheme, the SS Allocation subfield of a UHR variant of User Info field associated with a BSRP ICF may include a DPS Switch subfield (e.g., bit B0) , a Reserved subfield (e.g., bits B1 ～ B3) , and a Number of Spatial Streams subfield (e.g., bit B4) . Under the proposed scheme, the common Info field or Special User Info field (e.g., AID12 is 2007) of the BSRP ICF may include “DPS HC Mode switch / Remain in LC mode Present” subfield / bit to indicate that it is an ICF frame with DPS HC Mode switch / Remain in LC mode indication in a User Info field.

[0037] FIG. 3 illustrates an example design 300 under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in BSRP NTB. Under the proposed scheme, a DPS assisting STA may include an explicit DPS HC mode switch indication (herein interchangeably referred to as a “remain in LC mode indication” ) in the User Info field where the Association Identifier 12 (AID12) field, which is a 12-bit subfield containing the 12 least significant bits of a STA’s full AID, may be set to the STA identification (ID) of a DPS enabled STA which supports the explicit DPS HC mode Switch / Remain in LC mode indication individually addressed by a BSRP NTB frame that it sends. Referring to FIG. 3, which shows an example UHR variant User Info field addressed to a DPS enabled STA in a BSRP NTB ICF, the UHR variant User Info field associated with a BSRP NTB ICF may include an AID12 subfield, a Reserved subfield, and a “HC mode switch / remain in LC mode” subfield. The DPS assisting STA may be a DPS assisting non-AP STA (uplink) or a DPS assisting AP (downlink) , and the DPS enabled STA may be a DPS mobile AP (uplink) or a DPS non-AP STA (downlink) . When the DPS assisting STA intends to keep the intended DPS enabled recipient that supports the indication in LC mode after receiving the BSRP NTB, a “DPS HC mode Switch / Remain in LC mode” subfield / bit may be included in the UHR variant User info field of the BSRP NTB (e.g., with the bit “DPS HC mode Switch” set to 0 to mean that the DPS STA may stay in the LC mode or switch to the HC mode; or with the bit “DPS HC mode Switch” set to 1 to mean that the DPS STA may need to switch to the HC mode) . In case that the intended DPS enabled recipient does not support the indication, the subfield / bit may be reserved in the User Info field of BSRP NTB. The DPS assisting STA may include an intermediate frame check sequence (I-FCS) and padding bits if the intended DPS enabled recipient requires non-zero padding regardless of whether the recipient may remain in the LC mode or switch to the HC mode. The DPS enabled recipient STA that supports the indication may remain in the LC mode after correctly receiving the BSRP NTB indicating “remain in LC mode” . The DPS enabled recipient STA that supports the indication may switch to the HC mode after decoding the I-FCS if required and included in the received BSRP NTB indicating “remain in LC mode” . Furthermore, under the proposed scheme, a DPS enabled STA may indicate support and / or enablement of the explicit DPS HC mode Switch / remain in the LC mode indication if it sets “ICF Required” subfield / bit to 0 in the most recently transmitted DPS parameters by the DPS STA. Otherwise, it may indicate no support of the indication.

[0038] FIG. 4 illustrates an example design 400 under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in MU-RTS. Under the proposed scheme, a DPS assisting AP may include an explicit DPS HC mode switch / remain in LC mode indication in the User Info field where the AID12 field is set to the STA ID of a DPS enabled non-AP STA which supports the explicit DPS HC mode switch / remain in LC mode indication addressed by a MU-RTS frame that it sends. Referring to FIG. 4, which shows an example Extremely High Throughput (EHT, also known as Wi-Fi 7) or UHR variant User Info field addressed to a DPS enabled STA in a MU-RTS ICF, the EHT or UHR variant User Info field associated with a MU-RTS ICF may include an AID12 subfield, a Resource Unit (RU) Allocation subfield, a “HC mode switch / remain in LC mode” subfield, a Reserved subfield, and a Primary / Secondary 160 (PS160) subfield. For instance, when the DPS assisting AP intends to keep the intended DPS enabled recipient that supports the indication on LC mode after receiving the MU-RTS frame, a “DPS HC mode switch / remain in LC mode” subfield / bit may be included in the EHT / UHR variant User info field of the MU-RTS (e.g., with the subfield / bit set to 0 to mean that the DPS non-AP STA may stay in the LC mode or switch to the HC mode; or with the subfield / bit set to 1 to mean that the DPS non-AP STA needs to switch to HC mode) . In case that the intended DPS enabled recipient does not support the indication or the intended recipient is a legacy STA (e.g., non-UHR STA) , the subfield / bit may be reserved in the User Info field of MU-RTS. Moreover, the DPS assisting AP may include I-FCS and padding bits if the intended DPS enabled recipient requires non-zero padding regardless of whether the recipient may remain in the LC mode or switch to the HC mode. Additionally, the DPS enabled recipient STA that supports the indication may remain in the LC mode after correctly receiving the MU-RTS indicating “remain in LC mode” . Moreover, the DPS enabled recipient STA that supports the indication may switch to the HC mode after decoding the I-FCS if required and included in the received MU-RTS indicating “remain in LC mode” . Furthermore, a DPS enabled STA may indicate support and / or enablement of the explicit DPS HC mode switch / remain in LC mode indication if it sets the “ICF Required” subfield / bit to 0 in the most recently transmitted DPS parameters by the DPS STA. Otherwise, it may indicate no support of the indication.

[0039] FIG. 5 illustrates an example design 500 under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in BSRP under a first option (Option 1) . Under the proposed scheme, a DPS assisting AP may include an explicit DPS HC mode switch / remain in the LC mode indication in the User Info field where the AID12 field is set to the STA ID of a DPS enabled non-AP STA which supports the explicit DPS HC mode switch / remain in LC mode indication addressed by a BSRP frame that it sends. For instance, when the DPS assisting AP intends to allow the intended DPS enabled recipient that supports the indication to remain on LC mode after receiving the BSRP frame, a “DPS HC mode Switch / Remain in LC mode” subfield / bit may be included in a UHR variant User info field of the BSRP (e.g., with the subfield / bit set to 0 to mean that the DPS non-AP STA may stay in the LC mode or switch to the HC mode; or with the subfield / bit set to 1 to mean that the DPS non-AP STA shall switch to HC mode) . The UHR variant User Info field of the BSRP frame may carry a subfield / bit indication “Remain in LC Mode” for DPS enabled non-AP STA which supports the explicit DPS HC mode switch / remain in LC mode indication. The subfield / bit may be reserved for DPS disabled non-AP STA or DPS enabled non-AP STA which does not support the explicit DPS HC mode switch / remain in LC mode indication. Referring to FIG. 5, which shows an example UHR variant User Info field addressed to a DPS enabled STA in a BSRP ICF, the UHR variant User Info field associated with a BSRP ICF may include an AID12 subfield, a RU Allocation subfield, an Uplink (UL) Forward Error Correction (FEC) Coding type subfield, a UL UHR-MCS subfield, a two times low density-parity check (2xLDPC) subfield, a “Regular Resource Unit (RRU) SS Allocation  / Distributed-Tone Resource Unit (DRU) SS Allocation and Data Bandwidth (DBW)  / Remain in LC Mode and SS Allocation” subfield, a UL Target Receive Power subfield, and a Reserved subfield. The “RRU SS Allocation  / DRU SS Allocation and DBW  / Remain in LC Mode and SS Allocation” subfield may include certain subfields such as, for example: a Reserved  / DRU Distribution Bandwidth (BW) subfield, a Reserved  / Remain in LC Mode subfield, a Reserved subfield, and a Number of Spatial Streams subfield. When the BSRP frame indicates DRU (the bit in the DRU / RRU Indication subfield in the Common Info field is set to 0) , UHR variant User info field with “Remain in LC Mode” indication may also include DRU Distribution BW.

[0040] FIG. 6 illustrates an example design 600 under a proposed scheme in accordance with the present disclosure regarding explicit DPS HC mode switch indication in BSRP under a second option (Option 2) . FIG. 7 illustrates an example design 700 under the proposed scheme. Under the proposed scheme, a DPS assisting AP may include an explicit DPS HC mode switch / remain in LC mode indication in the User Info field where the AID12 field may be set to the STA ID of a DPS enabled non-AP STA which supports the explicit DPS HC mode switch  / remain in LC mode indication addressed by a BSRP frame that it sends. For instance, when the DPS assisting AP intends to allow the intended DPS enabled recipient that supports the indication to remain on LC mode after receiving the BSRP frame, a “DPS HC mode Switch / Remain in LC mode” subfield / bit may be included in an EHT / High Efficiency (HE, also known as Wi-Fi 6) variant User info field of the BSRP (e.g., with the subfield / bit set to 0 to mean that the DPS non-AP STA may stay in the LC mode or switch to the HC mode; or with the subfield / bit set to 1 to mean that the DPS non-AP STA may need to switch to the HC mode) . The EHT / HE variant User Info field of the BSRP frame may carry a subfield / bit indication “Remain in LC Mode” for DPS enabled non-AP STA which supports the explicit DPS HC mode switch / remain in LC mode indication; the subfield / bit may be reserved for DPS disabled non-AP STA or DPS enabled non-AP STA which does not support the explicit DPS HC mode switch / remain in LC mode indication. Referring to part (A) of FIG. 6, which shows an example HE variant User Info field format addressed to a DPS enabled STA in a BSRP ICF, the HE variant User Info field format may include an AID12 subfield, a RU Allocation subfield, an UL FEC Coding type subfield, an UL HE-MCS subfield, an UL Dual Carrier Modulation (DCM) subfield, an SS Allocation / RA-RU Information subfield, an UL Target Receive Power subfield, and a Reserved  / Remain in LC Mode subfield (e.g., bit B39) . Referring to part (B) of FIG. 6, which shows an example EHT variant User Info field format addressed to a DPS enabled STA in a BSRP ICF, the EHT variant User Info field format may include an AID12 subfield, a RU Allocation subfield, an UL FEC Coding type subfield, an UL HE-MCS subfield, a Reserved  / Remain in LC Mode subfield (e.g., bit B25) , an SS Allocation subfield, an UL Target Receive Power subfield, and a PS160 subfield.

[0041] Under the proposed scheme, in case that the intended DPS enabled recipient does not support the indication or the intended recipient is a legacy STA (e.g., non-UHR STA) , the subfield may be SS Allocation field defined in the User Info field of BSRP. The DPS assisting AP may include a Feedback User Info field indicating a feedback subtype as “DPS Remain in LC mode feedback” to remain in the LC mode or switch to the HC mode. The DPS assisting AP may include I-FCS and padding bits if the intended DPS enabled recipient requires non-zero padding regardless the recipient may remain in the LC mode or switch to the HC mode. The DPS enabled recipient STA that supports the indication may remain in the LC mode after correctly receiving the BSRP indicating “remain in LC mode” . The DPS enabled recipient STA that supports the indication may switch to HC mode after decoding the I-FCS if required and included in the received BSRP indicating “remain in LC mode” . Furthermore, a DPS enabled STA may indicate support and / or enablement of the explicit DPS HC mode switch / remain in LC mode indication if it sets ICF-required to 0 in the most recently transmitted DPS parameters by the DPS STA. Otherwise, it may indicate no support of the indication. Illustrative Implementations

[0042] FIG. 8 illustrates an example system 800 having at least an example apparatus 810 and an example apparatus 820 in accordance with an implementation of the present disclosure. Each of apparatus 810 and apparatus 820 may perform various functions to implement schemes, techniques, processes, and methods described herein pertaining to dynamic power save schemes in wireless communications, including the various schemes described above with respect to various proposed designs, concepts, schemes, systems and methods described above as well as processes described below. For instance, apparatus 810 may be implemented in an AP STA (e.g., STA 110) and apparatus 820 may be implemented in a non-AP STA (e.g., STA 120) , or vice versa.

[0043] Each of apparatus 810 and apparatus 820 may be a part of an electronic apparatus, such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. When implemented in a STA, each of apparatus 810 and apparatus 820 may be implemented in a smartphone, a smart watch, a personal digital assistant, a digital camera, or a computing equipment such as a tablet computer, a laptop computer or a notebook computer. Each of apparatus 810 and apparatus 820 may also be a part of a machine type apparatus, which may be an IoT apparatus such as an immobile or a stationary apparatus, a home apparatus, a wire communication apparatus or a computing apparatus. For instance, each of apparatus 810 and apparatus 820 may be implemented in a smart thermostat, a smart fridge, a smart door lock, a wireless speaker, or a home control center. When implemented in or as a network apparatus, apparatus 810 and / or apparatus 820 may be implemented in a network node, such as an AP in a WLAN or a mesh device.

[0044] In some implementations, each of apparatus 810 and apparatus 820 may be implemented in the form of one or more integrated-circuit (IC) chips such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction set computing (RISC) processors, or one or more complex-instruction-set-computing (CISC) processors. In the various schemes described above, each of apparatus 810 and apparatus 820 may be implemented in or as a STA or an AP. Each of apparatus 810 and apparatus 820 may include at least some of those components shown in FIG. 8 such as a processor 812 and a processor 822, respectively, for example. Each of apparatus 810 and apparatus 820 may further include one or more other components not pertinent to the proposed scheme of the present disclosure (e.g., internal power supply, display device and / or user interface device) , and, thus, such component (s) of apparatus 810 and apparatus 820 are neither shown in FIG. 8 nor described below in the interest of simplicity and brevity.

[0045] In one aspect, each of processor 812 and processor 822 may be implemented in the form of one or more single-core processors, one or more multi-core processors, one or more RISC processors or one or more CISC processors. That is, even though a singular term “a processor” is used herein to refer to processor 812 and processor 822, each of processor 812 and processor 822 may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, each of processor 812 and processor 822 may be implemented in the form of hardware (and, optionally, firmware) with electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more resistors, one or more inductors, one or more memristors and / or one or more varactors that are configured and arranged to achieve specific purposes in accordance with the present disclosure. In other words, in at least some implementations, each of processor 812 and processor 822 is a special-purpose machine specifically designed, arranged and configured to perform specific tasks including those pertaining to dynamic power save schemes in wireless communications in accordance with various implementations of the present disclosure.

[0046] In some implementations, apparatus 810 may also include a transceiver 816 coupled to processor 812. Transceiver 816 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. In some implementations, apparatus 820 may also include a transceiver 826 coupled to processor 822. Transceiver 826 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. It is noteworthy that, although transceiver 816 and transceiver 826 are illustrated as being external to and separate from processor 812 and processor 822, respectively, in some implementations, transceiver 816 may be an integral part of processor 812 as a system on chip (SoC) and / or transceiver 826 may be an integral part of processor 822 as a SoC.

[0047] In some implementations, apparatus 810 may further include a memory 814 coupled to processor 812 and capable of being accessed by processor 812 and storing data therein. In some implementations, apparatus 820 may further include a memory 824 coupled to processor 822 and capable of being accessed by processor 822 and storing data therein. Each of memory 814 and memory 824 may include a type of random-access memory (RAM) such as dynamic RAM (DRAM) , static RAM (SRAM) , thyristor RAM (T-RAM) and / or zero-capacitor RAM (Z-RAM) . Alternatively, or additionally, each of memory 814 and memory 824 may include a type of read-only memory (ROM) such as mask ROM, programmable ROM (PROM) , erasable programmable ROM (EPROM) and / or electrically erasable programmable ROM (EEPROM) . Alternatively, or additionally, each of memory 814 and memory 824 may include a type of non-volatile random-access memory (NVRAM) such as flash memory, solid-state memory, ferroelectric RAM (FeRAM) , magnetoresistive RAM (MRAM) and / or phase-change memory.

[0048] Each of apparatus 810 and apparatus 820 may be a communication entity capable of communicating with each other using various proposed schemes in accordance with the present disclosure. For illustrative purposes and without limitation, a description of capabilities of apparatus 810 or apparatus 820, as an STA (e.g., STA 120) or an AP (e.g., STA 110) , respectively, is provided below in the context of example processes 900 and 1000. It is noteworthy that, although a detailed description of capabilities, functionalities and / or technical features of either of apparatus 810 and apparatus 820 is provided below, the same may be applied to the other of apparatus 810 and apparatus 820 although a detailed description thereof is not provided solely in the interest of brevity. It is also noteworthy that, although the example implementations described below are provided in the context of WLAN, the same may be implemented in other types of networks. Illustrative Processes

[0049] FIG. 9 illustrates an example process 900 in accordance with an implementation of the present disclosure. Process 900 may represent an aspect of implementing various proposed designs, concepts, schemes, systems, and methods described above. More specifically, process 900 may represent an aspect of the proposed concepts and schemes pertaining to dynamic power save schemes in wireless communications. Process 900 may include one or more operations, actions, or functions as illustrated by one or more of blocks. Although illustrated as discrete blocks, various blocks of process 900 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 900 may be executed in the order shown in FIG. 9 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 900 may be executed repeatedly or iteratively. Process 900 may be implemented by or in apparatus 810 and apparatus 820 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 900 is described below in the context of apparatus 810 implemented in or as a first STA (e.g., STA 110 as a DPS enabled STA) and apparatus 820 implemented in or as a second STA (e.g., STA 120 as a DPS assisting STA) of a wireless network such as a WLAN in network environment 100 in accordance with one or more of IEEE 802.11 standards. Process 900 may begin at block 910.

[0050] At 910, process 900 may involve processor 812 of apparatus 810, as a DPS enabled STA, receiving, via transceiver 816, a frame from a DPS assisting STA (e.g., apparatus 820) with an indication of whether to remain in a LC mode or to switch to a HC mode. Process 900 may proceed from 910 to 920.

[0051] At 920, process 900 may involve processor 812 performing, via transceiver 816, a frame exchange with the DPS assisting STA: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode.

[0052] In some implementations, in performing the frame exchange in the LC mode, process 900 may involve processor 812 performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

[0053] In some implementations, the indication may include one bit of a “remain in LC mode” subfield in an EHT or UHR variant User Info field corresponding to the DPS enabled STA in the frame. For instance, responsive to the “remain in LC mode” subfield having a first value indicating to the DPS enabled STA to remain in the LC mode, the DPS enabled STA may either remain in the LC mode or switch to the HC mode. Moreover, responsive to the “remain in LC mode” subfield having a second value indicating to the DPS enabled STA to switch to the HC mode, the DPS enabled STA may switch to the HC mode.

[0054] In some implementations, in receiving the frame with the indication, process 900 may involve processor 812 receiving the frame with the indication as a result of an “ICF required” most recently set by the DPS enabled STA being set to a value which requires the DPS assisting STA to initiate an ICF-ICR exchange to trigger the DPS enabled STA to transition from the LC mode to the HC mode.

[0055] In some implementations, the frame may include an I-FCS and padding bits that are utilized by the DPS enabled STA in switching to the HC mode.

[0056] In some implementations, in receiving the frame, process 900 may involve processor 812 receiving a MU-RTS that includes the indication.

[0057] In some implementations, in receiving the frame, process 900 may involve processor 812 receiving an ICF that includes the indication.

[0058] In some implementations, in receiving the frame, process 900 may involve processor 812 receiving a BSRP or BSRP NTB frame that includes the indication.

[0059] FIG. 10 illustrates an example process 1000 in accordance with an implementation of the present disclosure. Process 1000 may represent an aspect of implementing various proposed designs, concepts, schemes, systems, and methods described above. More specifically, process 1000 may represent an aspect of the proposed concepts and schemes pertaining to dynamic power save schemes in wireless communications. Process 1000 may include one or more operations, actions, or functions as illustrated by one or more of blocks. Although illustrated as discrete blocks, various blocks of process 1000 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks / sub-blocks of process 1000 may be executed in the order shown in FIG. 10 or, alternatively, in a different order. Furthermore, one or more of the blocks / sub-blocks of process 1000 may be executed repeatedly or iteratively. Process 1000 may be implemented by or in apparatus 810 and apparatus 820 as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process 1000 is described below in the context of apparatus 810 implemented in or as a first STA (e.g., STA 110 as a DPS enabled STA) and apparatus 820 implemented in or as a second STA (e.g., STA 120 as a DPS assisting STA) of a wireless network such as a WLAN in network environment 100 in accordance with one or more of IEEE 802.11 standards. Process 1000 may begin at block 1010.

[0060] At 1010, process 1000 may involve processor 822 of apparatus 820, as a DPS assisting STA, transmitting, via transceiver 826, a frame to a DPS enabled STA (e.g., apparatus 810) with an indication of whether to remain in a LC mode or to switch to a HC mode. Process 1000 may proceed from 1010 to 1020.

[0061] At 1020, process 1000 may involve processor 822 performing, via transceiver 826, a frame exchange with the DPS enabled STA with the DPS enabled STA performing the frame exchange: (a) in the LC mode responsive to the indication indicating to remain in the LC mode; or (b) in the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode.

[0062] In some implementations, in performing the frame exchange in the LC mode, process 1000 may involve processor 822 performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.

[0063] In some implementations, the indication may include one bit of a “remain in LC mode” subfield in an EHT or UHR variant User Info field corresponding to the DPS enabled STA in the frame. For instance, responsive to the “remain in LC mode” subfield having a first value indicating to the DPS enabled STA to remain in the LC mode, the DPS enabled STA may either remain in the LC mode or switch to the HC mode. Moreover, responsive to the “remain in LC mode” subfield having a second value indicating to the DPS enabled STA to switch to the HC mode, the DPS enabled STA may switch to the HC mode.

[0064] In some implementations, responsive to the “remain in LC mode” subfield indicating to the DPS enabled STA to remain in the LC mode, the DPS assisting STA may perform the frame exchange with one or more frames transmitted within low capability parameters of the DPS enabled STA. Otherwise, responsive to the “remain in LC mode” subfield indicating to the DPS enabled STA to switch to the HC mode, the DPS assisting STA may perform the frame exchange with the one or more frames transmitted within the low capability parameters or high capability parameters of the DPS enabled STA.

[0065] In some implementations, in transmitting the frame with the indication, process 1000 may involve processor 822 transmitting the frame with the indication as a result of an “ICF required” most recently set by the DPS enabled STA being set to a value which requires the DPS assisting STA to initiate an ICF-ICR exchange to trigger the DPS enabled STA to transition from the LC mode to the HC mode.

[0066] In some implementations, the frame may include an I-FCS and padding bits that are utilized by the DPS enabled STA in switching to the HC mode.

[0067] In some implementations, in transmitting the frame, process 1000 may involve processor 822 transmitting a MU-RTS that includes the indication.

[0068] In some implementations, in transmitting the frame, process 1000 may involve processor 822 transmitting an ICF that includes the indication.

[0069] In some implementations, in transmitting the frame, process 1000 may involve processor 822 transmitting a BSRP or BSRP NTB frame that includes the indication. Additional Notes

[0070] The herein-described subject matter sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected" , or "operably coupled" , to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" , to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.

[0071] Further, with respect to the use of substantially any plural and / or singular terms herein, those having skill in the art can translate from the plural to the singular and / or from the singular to the plural as is appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for sake of clarity.

[0072] Moreover, it will be understood by those skilled in the art that, in general, terms used herein, and especially in the appended claims, e.g., bodies of the appended claims, are generally intended as “open” terms, e.g., the term “including” should be interpreted as “including but not limited to, ” the term “having” should be interpreted as “having at least, ” the term “includes” should be interpreted as “includes but is not limited to, ” etc. It will be further understood by those within the art that if a specific number of an introduced claim recitation is intended, such an intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an, " e.g., “a” and / or “an” should be interpreted to mean “at least one” or “one or more; ” the same holds true for the use of definite articles used to introduce claim recitations. In addition, even if a specific number of an introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number, e.g., the bare recitation of "two recitations, " without other modifiers, means at least two recitations, or two or more recitations. Furthermore, in those instances where a convention analogous to “at least one of A, B, and C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, and C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those instances where a convention analogous to “at least one of A, B, or C, etc. ” is used, in general such a construction is intended in the sense one having skill in the art would understand the convention, e.g., “a system having at least one of A, B, or C” would include but not be limited to systems that have A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. It will be further understood by those within the art that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase “A or B” will be understood to include the possibilities of “A” or “B” or “A and B. ”

[0073] From the foregoing, it will be appreciated that various implementations of the present disclosure have been described herein for purposes of illustration, and that various modifications may be made without departing from the scope and spirit of the present disclosure. Accordingly, the various implementations disclosed herein are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

Claims

1.A method, comprising:receiving, by a processor of a dynamic power save (DPS) enabled station (STA) , a frame from a DPS assisting STA with an indication of whether to remain in a low capability (LC) mode or to switch to a high capability (HC) mode; andperforming, by the processor, a frame exchange with the DPS assisting STA:in the LC mode responsive to the indication indicating to remain in the LC mode; orin the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode,wherein the performing of the frame exchange in the LC mode comprises performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.2.The method of Claim 1, wherein the indication comprises one bit of a “remain in LC mode” subfield in an Extremely High Throughput (EHT) or Ultra High Reliability (UHR) variant User Info field corresponding to the DPS enabled STA in the frame, wherein, responsive to the “remain in LC mode” subfield having a first value indicating to the DPS enabled STA to remain in the LC mode, the DPS enabled STA either remains in the LC mode or switches to the HC mode, and wherein, responsive to the “remain in LC mode” subfield having a second value indicating to the DPS enabled STA to switch to the HC mode, the DPS enabled STA switches to the HC mode.3.The method of Claim 1, wherein the receiving of the frame with the indication comprises receiving the frame with the indication as a result of an “initial control frame (ICF) required” most recently set by the DPS enabled STA being set to a value which requires the DPS assisting STA to initiate an ICF-initial control response frame (ICR) exchange to trigger the DPS enabled STA to transition from the LC mode to the HC mode.4.The method of Claim 1, wherein the frame includes an intermediate frame check sequence (I-FCS) and padding bits utilized by the DPS enabled STA in switching to the HC mode.5.The method of Claim 1, wherein the receiving of the frame comprises receiving a multi-user request-to-send frame (MU-RTS) that includes the indication.6.The method of Claim 1, wherein the receiving of the frame comprises receiving an initial control frame (ICF) that includes the indication.7.The method of Claim 1, wherein the receiving of the frame comprises receiving a buffer status report poll (BSRP) or BSRP non-trigger based (NTB) frame that includes the indication.8.A method, comprising:transmitting, by a processor of a dynamic power save (DPS) assisting station (STA) , a frame to a DPS enabled STA with an indication of whether to remain in a low capability (LC) mode or to switch to a high capability (HC) mode; andperforming, by the processor, a frame exchange with the DPS enabled STA:in the LC mode responsive to the indication indicating to remain in the LC mode; orin the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode,wherein the performing of the frame exchange in the LC mode comprises performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.9.The method of Claim 8, wherein the indication comprises one bit of a “remain in LC mode” subfield in an Extremely High Throughput (EHT) or Ultra High Reliability (UHR) variant User Info field corresponding to the DPS enabled STA in the frame, wherein, responsive to the “remain in LC mode” subfield having a first value indicating to the DPS enabled STA to remain in the LC mode, the DPS enabled STA either remains in the LC mode or switches to the HC mode, and wherein, responsive to the “remain in LC mode” subfield having a second value indicating to the DPS enabled STA to switch to the HC mode, the DPS enabled STA switches to the HC mode.10.The method of Claim 9, wherein, responsive to the “remain in LC mode” subfield indicating to the DPS enabled STA to remain in the LC mode, the DPS assisting STA performs the frame exchange with one or more frames transmitted within low capability parameters of the DPS enabled STA, and wherein, responsive to the “remain in LC mode” subfield indicating to the DPS enabled STA to switch to the HC mode, the DPS assisting STA performs the frame exchange with the one or more frames transmitted within the low capability parameters or high capability parameters of the DPS enabled STA.11.The method of Claim 8, wherein the transmitting of the frame with the indication comprises transmitting the frame with the indication as a result of an “initial control frame (ICF) required” most recently set by the DPS enabled STA being set to a value which requires the DPS assisting STA to initiate an ICF-initial control response frame (ICR) exchange to trigger the DPS enabled STA to transition from the LC mode to the HC mode.12.The method of Claim 8, wherein the frame includes an intermediate frame check sequence (I-FCS) and padding bits utilized by the DPS enabled STA in switching to the HC mode.13.The method of Claim 8, wherein the transmitting of the frame comprises transmitting a multi-user request-to-send frame (MU-RTS) that includes the indication.14.The method of Claim 8, wherein the transmitting of the frame comprises transmitting an initial control frame (ICF) that includes the indication.15.The method of Claim 8, wherein the transmitting of the frame comprises transmitting a buffer status report poll (BSRP) or BSRP non-trigger based (NTB) frame that includes the indication.16.An apparatus, comprising:a transceiver configured to communicate wirelessly; anda processor coupled to the transceiver and configured to perform operations, as a dynamic power save (DPS) enabled station (STA) , comprising:receiving, via the transceiver, a frame from a DPS assisting STA with an indication of whether to remain in a low capability (LC) mode or to switch to a high capability (HC) mode; andperforming, via the transceiver, a frame exchange with the DPS assisting STA:in the LC mode responsive to the indication indicating to remain in the LC mode; orin the HC mode responsive to the indication indicating to remain in the LC mode or to switch to the HC mode,wherein the performing of the frame exchange in the LC mode comprises performing the frame exchange with transmission of frames within low capability parameters of the DPS enabled STA.17.The apparatus of Claim 16, wherein the indication comprises one bit of a “remain in LC mode” subfield in an Extremely High Throughput (EHT) or Ultra High Reliability (UHR) variant User Info field corresponding to the DPS enabled STA in the frame, wherein, responsive to the “remain in LC mode” subfield having a first value indicating to the DPS enabled STA to remain in the LC mode, the DPS enabled STA either remains in the LC mode or switches to the HC mode, wherein, responsive to the “remain in LC mode” subfield having a second value indicating to the DPS enabled STA to switch to the HC mode, the DPS enabled STA switches to the HC mode.18.The apparatus of Claim 16, wherein the frame includes an intermediate frame check sequence (I-FCS) and padding bits utilized by the DPS enabled STA in switching to the HC mode.19.The apparatus of Claim 16, wherein the receiving of the frame with the indication comprises receiving the frame with the indication as a result of an “initial control frame (ICF) required” most recently set by the DPS enabled STA being set to a value which requires the DPS assisting STA to initiate an ICF-initial control response frame (ICR) exchange to trigger the DPS enabled STA to transition from the LC mode to the HC mode.20.The apparatus of Claim 16, wherein the receiving of the frame comprises receiving a multi-user request-to-send frame (MU-RTS) , an initial control frame (ICF) , or a buffer status report poll (BSRP) or BSRP non-trigger based (NTB) frame that includes the indication.

Images