Patent Description:
The present disclosure is generally related to wireless communications and, more particularly, to enhanced distributed channel access (EDCA) schemes for triggered transmission opportunity (TXOP) sharing operations in wireless communications.

In wireless networks such as a wireless local area network (WLAN) operating in accordance with the Institute of Electrical and Electronics Engineers (IEEE) <NUM> standard(s), when there are a large number of associated non-access point (non-AP) stations (STAs) in the same basic service set (BSS), a channel access contention mechanism might not be efficient and, as a result, quality of service (QoS) requirement(s) might not be satisfied due to channel contention collision(s) between STAs attempting to access the medium or channel. An access point (AP) should have better control over the medium especially in high-load scenarios. A triggered TXOP sharing (TXS) procedure may allow an AP to allocate a portion of time within a TXOP obtained by the AP to one or more non-AP STAs for transmitting one or more non-trigger-based (non-TB) physical-layer protocol data units (PPDUs) to either the associated AP or other peer non-AP STA(s). However, how to achieve better control over the medium so that the AP can have more chances to share the obtained TXOP and allocate resources to its associated STAs is one issue to be resolved. Moreover, how the AP is to ensure fairness among legacy and extremely-high-throughput (EHT) non-AP STAs when the TXOP sharing can only happen among STAs capable of triggered TXOP sharing is another issue to be resolved. Therefore, there is a need for a solution of EDCA schemes for triggered TXOP sharing operations in wireless communications to address aforementioned issues.

<NPL>" and the IEEE draft P802.11ax/D8. <NUM> disclose that a non-AP STA that receives a Basic Trigger frame that contains a User Info field addressed to the STA may update some state variables to the values contained in the most recently received MU EDCA parameter set element sent by the AP.

IEEE document <NUM>-<NUM>/0268r0 discusses channel access for triggered TXOP sharing.

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.

An objective of the present disclosure is to provide schemes, concepts, designs, techniques, methods and apparatuses pertaining to EDCA schemes for triggered TXOP sharing operations in wireless communications. Under various proposed schemes in accordance with the present disclosure, it is believed that aforementioned issues may be addressed or otherwise alleviated. A method and an apparatus according to the invention are defined in the independent claims. The dependent claims define preferred embodiments thereof. The apparatus according to the invention is in particular arranged to perform the method steps as defined in any one of the method claims according to the invention.

In one aspect, a method may involve a STA associated with an AP receiving, from the AP, an indication of an EDCA parameter set. The method may also involve the STA updating one or more parameters of the EDCA parameter set with respect to a TXS operation.

In another aspect, an apparatus may include a transceiver and a processor coupled to the transceiver. The transceiver may be configured to wirelessly communicate with an AP. The processor may be configured to receive, from the AP, an indication of an EDCA parameter set. The processor may also be configured to update one or more parameters of the EDCA parameter set with respect to a TXS operation.

It is noteworthy that, although description provided herein may be in the context of certain radio access technologies, networks and network topologies such as, Wi-Fi, 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, WiMax, Bluetooth, ZigBee, <NUM>th Generation (<NUM>)/New Radio (NR), Long-Term Evolution (LTE), LTE-Advanced, LTE-Advanced Pro, Internet-of-Things (IoT), Industrial loT (IloT) and narrowband loT (NB-loT). Thus, the scope of the present disclosure is not limited to the examples described herein.

Implementations in accordance with the present disclosure relate to various techniques, methods, schemes and/or solutions pertaining to EDCA schemes for triggered TXOP sharing operations 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.

Referring to <FIG>, network environment <NUM> may involve at least a first STA (or STA <NUM>) and a second STA (or STA <NUM>) communicating wirelessly with each other in a BSS <NUM> in accordance with one or more IEEE <NUM> standards (e.g., IEEE <NUM>. 11be and beyond). Each of STA <NUM> and STA <NUM> may function as either an AP STA or a non-AP STA. Each of STA <NUM> and STA <NUM> may be configured to utilize EDCA schemes for triggered TXOP sharing operations in wireless communications in accordance with various proposed schemes, as described below.

Under various proposed schemes in accordance with the present disclosure, an AP (e.g., STA <NUM> functioning as an AP STA) may indicate a TXS EDCA (also known as multi-user (MU) EDCA) parameter set which is used to control the use of EDCA for channel contention by non-AP STAs (including STA <NUM> functioning as a non-AP STA) following a particular TXS operation. It is noteworthy that, among a number of access categories (ACs), each AC may be associated with a respective EDCA parameter set corresponding to a respective priority level of different priorities with respect to EDCA. The TXS EDCA parameter set (based on which a non-AP STA performs EDCA to access the medium) may include, for example and without limitation, the following parameter records: (i) TXS AC_BE parameter record (pertaining to the "best effort" access category), (ii) TXS AC_BK parameter record (pertaining to the "background" access category), (iii) TXS AC_VO parameter record (pertaining to the "voice" access category), and (iv) TXS AC_VI parameter record (pertaining to the "video" access category). Each parameter record may include at least the following information: (i) contention window (CW) parameters CWmin (minimum CW) and CWmax (maximum CW), (ii) a TXS EDCA Timer, and (iii) an arbitration interframe spacing number (AIFSN). For a higher-priority AC or traffic, the CW size may be smaller so that the respective STA may have a shorter backoff before attempting to access the medium/channel again. During the duration of the TXS EDCA Timer, a STA (e.g., STA <NUM>) may use, implement or otherwise apply the TXS EDCA parameters for a corresponding access category (AC), except that the value <NUM> is reserved. The AIFSN may denote the number of slots after a short interframe space (SIFS) that the STA defers before either invoking a backoff procedure or starting a transmission, except that the value <NUM> may indicate that EDCA is disabled for the duration specified by the TXS EDCA Timer for the corresponding AC. That is, after a STA has utilized TXOP sharing during a TXS service period (SP), the TXS EDCA Timer may be used to set a duration during which that STA is to use, implement or otherwise apply the updated TXS EDCA parameter set (which has a lower priority than that of a regular MU EDCA parameter set) for fairness. Under various proposed schemes, an AP (e.g., STA <NUM>) may change the TXS EDCA parameters by including a TXS EDCA Parameter Set element with updated TXS EDCA parameters in the Beacon frames and Probe Response frames transmitted by the AP.

<FIG> illustrates an example scenario <NUM> of EDCA parameters for TXS operation under a proposed scheme in accordance with the present disclosure. Under the proposed scheme, a non-AP STA (e.g., STA <NUM>) that receives a multi-user request-to-send (MU-RTS) TXS Trigger frame from its associated AP (e.g., STA <NUM>) and that contains a User Information field that is addressed to it (e.g., STA <NUM>) may update its AC-specific CWmin[AC], CWmax[AC], AIFSN[AC] and TXS EDCA Timer[AC] state variables corresponding to the TXS EDCA parameter set for all the ACs from which at least one QoS Data frame was transmitted successfully within the allocated time in response to a transmitted MU-RTS TXS Trigger frame from the associated AP. Under the proposed scheme, a QoS Data frame may be transmitted successfully by the STA in a non-TB PPDU for an AC in an event that it requires immediate acknowledgement and that the STA receives an immediate acknowledgement for that data frame, or in an event that the QoS Data frame does not require immediate acknowledgement. Referring to <FIG>, the STA updates one or more current EDCA parameter(s) to the TXS EDCA parameter(s) at the end of an immediate acknowledgement (e.g., block acknowledgement (BA)) and use, implement or otherwise apply the updated TXS EDCA parameter(s) in order to access the medium/channel using EDCA channel access scheme to obtain the medium outside the TXS operation. At other times outside the TXS operation, the priority may be lower by using the TXS EDCA parameters for an EHT non-AP STA with a non-zero value TXS EDCA timer so that other legacy non-AP STA or EHT non-AP STA with a zero value TXS EDCA timer may have a chance to access the medium/channel.

<FIG> illustrates an example scenario <NUM> of EDCA parameters for TXS operation under a proposed scheme in accordance with the present disclosure. Under the proposed scheme, usage, implementation or application (by a STA) of the updated TXS EDCA Timer[AC] may start at the end of the immediate acknowledgement/response in case that the transmitted non-TB PPDU contains at least one QoS Data frame for that AC that requires immediate acknowledgement. Alternatively, usage, implementation or application (by the STA) of the updated TXS EDCA Timer[AC] may start at the end of the non-TB PPDU in case that the transmitted non-TB PPDU does not contain any QoS Data frame for that AC that requires immediate acknowledgement. Still alternatively, usage, implementation or application (by the STA) of the updated TXS EDCA Timer[AC] may start at the end of a negotiated allocated time.

<FIG> illustrates an example scenario <NUM> of EDCA parameters for TXS operation under a proposed scheme in accordance with the present disclosure. Referring to part (A) of <FIG>, under the proposed scheme, implementation or application (by a STA) of the updated TXS EDCA Timer[AC] may start at the end of the allocated time. Referring to part (B) of <FIG>, alternatively, implementation or application (by the STA) of the updated TXS EDCA Timer[AC] may start at the termination of the TXOP sharing. The non-AP STA may terminate the sharing earlier than the end of the allocated time.

Under a proposed scheme in accordance with the present disclosure, the allocated time in the Triggered TXOP sharing may be indicated or negotiated between the non-AP STA and its associated AP. The AP may signal the allocated time in a MU-RTS TXS trigger frame. The STA addressed by the MU-RTS TXS trigger frame may indicate its acceptance, rejection or negotiation of the allocated time. In a first option (Option-<NUM>), the duration field of the clear-to-send (CTS) frame in response to the MU-RTS TXS trigger frame may contain the value indicating the allocation time required by the STA. For instance, a value of <NUM> or a predefined non-zero value may indicate rejection of the allocated time by the STA. Alternatively, or additionally, a value greater than <NUM> and less than or equal to the allocated time carried in the MU-RTS TXS trigger frame may indicate the required allocation time (as required by the STA and being negotiated with the AP). In a second option (Option-<NUM>), a non-TB single-user (SU) PPDU transmitted by the STA may carry the required allocation time. For instance, the required allocation time may be carried in the TXOP duration field of a signal A (SIG-A) field of the non-TB PPDU. Alternatively, the required allocation time may be carried in the duration field of a medium access control (MAC) header of the non-TB PPDU. The value of the required allocation time indicates a time no later than an ending time of the PPDU carrying the MU-RTS TXS trigger frame plus the required allocation time in soliciting the MU-RTS TXS trigger frame.

Under a proposed scheme in accordance with the present disclosure, with respect to non-AP STA behavior in a TXS operation, after receiving an MU-RTS TXS Trigger frame from its associated AP addressed to a non-AP STA, the non-AP STA may perform certain operations. For instance, the non-AP STA may transmit one or more non-TB PPDUs within the time allocation indicated or negotiated with the associated AP. The first PPDU of the exchange may be a CTS frame transmitted per rule(s) in response to the MU-RTS, except that: (i) the STA may not respond with the CTS in case that it rejects the allocated time, or (ii) the STA may set the duration field of the CTS to <NUM> or a predefined non-zero value to reject the allocated time. If the STA rejected the TXOP sharing by setting the duration field of the CTS to <NUM> or a predefined non-zero value, the associated AP may continue to share the TXOP to other STAs or perform frame exchanges within the obtained TXOP. Under the proposed scheme, the time allocation may start when the PHY-RXEND. indication primitive of the PPDU that contains the MU-RTS TXS Trigger frame has occurred in an event that the non-AP STA accepted the TXOP sharing.

<FIG> illustrates an example system <NUM> having at least an example apparatus <NUM> and an example apparatus <NUM> in accordance with an implementation of the present disclosure. Each of apparatus <NUM> and apparatus <NUM> may perform various functions to implement schemes, techniques, processes and methods described herein pertaining to EDCA schemes for triggered TXOP sharing operations 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 <NUM> may be implemented in STA <NUM> and apparatus <NUM> may be implemented in STA <NUM>, or vice versa.

Each of apparatus <NUM> and apparatus <NUM> may be a part of an electronic apparatus, which may be a non-AP MLD or an AP MLD, such as a portable or mobile apparatus, a wearable apparatus, a wireless communication apparatus or a computing apparatus. When implemented in a non-AP MLD, each of apparatus <NUM> and apparatus <NUM> 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 <NUM> and apparatus <NUM> may also be a part of a machine type apparatus, which may be an loT 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 <NUM> and apparatus <NUM> 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 <NUM> and/or apparatus <NUM> may be implemented in a network node, such as an AP MLD in a WLAN.

In some implementations, each of apparatus <NUM> and apparatus <NUM> 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 <NUM> and apparatus <NUM> may be implemented in or as a non-AP MLD or an AP MLD. Each of apparatus <NUM> and apparatus <NUM> may include at least some of those components shown in <FIG> such as a processor <NUM> and a processor <NUM>, respectively, for example. Each of apparatus <NUM> and apparatus <NUM> 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 <NUM> and apparatus <NUM> are neither shown in <FIG> nor described below in the interest of simplicity and brevity.

In one aspect, processor <NUM> and processor <NUM> 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 <NUM> and processor <NUM>, processor <NUM> and processor <NUM> may include multiple processors in some implementations and a single processor in other implementations in accordance with the present disclosure. In another aspect, processor <NUM> and processor <NUM> 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, processor <NUM> and processor <NUM> is a special-purpose machine specifically designed, arranged and configured to perform specific tasks including those pertaining to EDCA schemes for triggered TXOP sharing operations in wireless communications in accordance with various implementations of the present disclosure.

In some implementations, apparatus <NUM> may also include a transceiver <NUM> coupled to processor <NUM>. Transceiver <NUM> may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. In some implementations, apparatus <NUM> may also include a transceiver <NUM> coupled to processor <NUM>. Transceiver <NUM> may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data.

Each of apparatus <NUM> and apparatus <NUM> 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 <NUM>, as MLD <NUM> (e.g., a non-AP MLD operating on a NSTR link pair), and apparatus <NUM>, as MLD <NUM> (e.g., an AP MLD), is provided below. It is 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. It is also noteworthy that, although examples described below are provide in the context of apparatus <NUM>, the examples may also be applicable to apparatus <NUM> or otherwise implemented by apparatus <NUM>.

Under a proposed scheme pertaining to EDCA schemes for triggered TXOP sharing operations in wireless communications in accordance with the present disclosure, with apparatus <NUM> implemented in a non-AP STA (e.g., STA <NUM>) and apparatus <NUM> implemented in an AP STA (e.g., STA <NUM>), processor <NUM> may receive, via transceiver <NUM>, an indication of an EDCA parameter set from apparatus <NUM>. Additionally, processor <NUM> may update one or more parameters of the EDCA parameter set with respect to a TXS operation.

In some implementations, the EDCA parameter set may include a plurality of AC-related parameter records including: (i) a TXS AC_BE parameter record pertaining to a best-effort AC; (ii) a TXS AC_BK parameter record pertaining to a background AC; (iii) a TXS AC_VO parameter record pertaining to a voice AC; and (iv) a TXS AC_VI parameter record pertaining to a video AC.

In some implementations, each of the plurality of AC-related parameter records may include a plurality of parameters including: (a) a minimum CW parameter; (b) a maximum CW parameter; (c) a TXS EDCA timer; and (d) an AIFSN. In some implementations, processor <NUM> may apply the plurality of parameters for a corresponding AC when the TXS EDCA timer is non-zero. Moreover, the AIFSN may denote a number of slots after a SIFS that the STA defers before invoking a backoff procedure or starting a transmission.

In some implementations, in updating the one or more parameters of the EDCA parameter set, processor <NUM> may start the TXS EDCA timer at an end of an immediate acknowledgement in response to transmission of a frame by apparatus <NUM> or at an end of the transmission of the frame which does not require the immediate acknowledgement by apparatus <NUM> within an allocated time.

In some implementations, in receiving the indication, processor <NUM> may receive the indication in a beacon frame or a probe response frame.

In some implementations, processor <NUM> may also perform other operations. For instance, processor <NUM> may perform, during a TXS SP, a TXS operation. The TXS operation may involve: (i) receiving, via transceiver <NUM>, from apparatus <NUM> an MU-RTS TXS trigger frame indicating an allocated time for performing the TXS operation; and (ii) transmitting, via transceiver <NUM>, a PPDU (e.g., non-TB PPDU) after sending a CTS frame responsive to receiving the MU-RTS TXS trigger frame.

In some implementations, responsive to the MU-RTS TXS trigger frame containing a user information field that is addressed to the STA, in updating the one or more parameters of the EDCA parameter set, processor <NUM> may update the one or more parameters corresponding to one or more ACs from which at least one QoS data frame was transmitted successfully by apparatus <NUM> within an allocated time in response to the MU-RTS TXS trigger frame.

In some implementations, in updating the one or more parameters of the EDCA parameter set, processor <NUM> may apply the updated one or more parameters and starting an updated TXS EDCA timer at an end of the acknowledgement. Alternatively, in updating the one or more parameters of the EDCA parameter set, processor <NUM> may apply the updated one or more parameters and starting an updated TXS EDCA timer at an end of the transmitting of the PPDU when the PPDU does not require an immediate response. Still alternatively, in updating the one or more parameters of the EDCA parameter set, processor <NUM> may apply the updated one or more parameters and starting an updated TXS EDCA timer at an end of a negotiated allocated time.

In some implementations, processor <NUM> may also indicate, via transceiver <NUM>, a required allocation time responsive to receiving the MU-RTS TXS trigger frame.

In some implementations, responsive to the MU-RTS TXS trigger frame containing a value indicating the allocated time, in indicating, processor <NUM> may transmit a CTS frame containing a duration field that indicates the required allocation time. In some implementations, a value of <NUM> or a predefined value in the duration field may indicate the required allocation time. Moreover, a value greater than <NUM> and less than or equal to the allocated time in the duration field may indicate the negotiation of a required allocation time different than the allocated time.

In some implementations, in indicating, processor <NUM> may indicate, in the PPDU, a required allocation time. In such cases, a value of the required allocation time may indicate a time no later than an ending time of the PPDU carrying the MU-RTS TXS trigger frame plus the required allocation time in soliciting the MU-RTS TXS trigger frame. In some implementations, a value of the required allocation time may be carried in a TXOP duration field of a SIG-A field of the PPDU or in a duration field of a MAC header of the PPDU.

<FIG> illustrates an example process <NUM> in accordance with an implementation of the present disclosure. Process <NUM> may represent an aspect of implementing various proposed designs, concepts, schemes, systems and methods described above. More specifically, process <NUM> may represent an aspect of the proposed concepts and schemes pertaining to EDCA schemes for triggered TXOP sharing operations in wireless communications in accordance with the present disclosure. Process <NUM> may include one or more operations, actions, or functions as illustrated by one or more of blocks <NUM> and <NUM>. Although illustrated as discrete blocks, various blocks of process <NUM> may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Moreover, the blocks/sub-blocks of process <NUM> may be executed in the order shown in <FIG> or, alternatively in a different order. Furthermore, one or more of the blocks/sub-blocks of process <NUM> may be executed repeatedly or iteratively. Process <NUM> may be implemented by or in apparatus <NUM> and apparatus <NUM> as well as any variations thereof. Solely for illustrative purposes and without limiting the scope, process <NUM> is described below in the context of apparatus <NUM> implemented in or as MLD <NUM> and apparatus <NUM> implemented in or as MLD <NUM> of a wireless network such as a WLAN in network environment <NUM> in accordance with one or more of IEEE <NUM> standards. It is noteworthy that, although examples described below are provide in the context of apparatus <NUM> implemented in a non-AP STA (e.g., STA <NUM>) and apparatus <NUM> implemented in an AP STA (e.g., STA <NUM>). Process <NUM> may begin at block <NUM>.

At <NUM>, process <NUM> may involve processor <NUM> receiving, via transceiver <NUM>, an indication of an EDCA parameter set from apparatus <NUM>. Process <NUM> may proceed from <NUM> to <NUM>.

At <NUM>, process <NUM> may involve processor <NUM> updating one or more parameters of the EDCA parameter set with respect to a TXS operation.

In some implementations, in updating the one or more parameters of the EDCA parameter set, process <NUM> may involve processor <NUM> starting the TXS EDCA timer at an end of an immediate acknowledgement in response to transmission of a frame by apparatus <NUM> or at an end of the transmission of the frame which does not require the immediate acknowledgement by apparatus <NUM> within an allocated time.

In some implementations, in receiving the indication, process <NUM> may involve processor <NUM> receiving the indication in a beacon frame or a probe response frame.

In some implementations, process <NUM> may further involve processor <NUM> performing other operations. For instance, process <NUM> may involve processor <NUM> performing, during a TXS SP, a TXS operation. The TXS operation may involve: (i) receiving, via transceiver <NUM>, from apparatus <NUM> an MU-RTS TXS trigger frame indicating an allocated time for performing the TXS operation; and (ii) transmitting, via transceiver <NUM>, a PPDU (e.g., non-TB PPDU) after sending a CTS frame responsive to receiving the MU-RTS TXS trigger frame.

In some implementations, responsive to the MU-RTS TXS trigger frame containing a user information field that is addressed to the STA, in updating the one or more parameters of the EDCA parameter set, process <NUM> may involve processor <NUM> updating the one or more parameters corresponding to one or more ACs from which at least one QoS data frame was transmitted successfully by apparatus <NUM> within an allocated time in response to the MU-RTS TXS trigger frame.

In some implementations, in updating the one or more parameters of the EDCA parameter set, process <NUM> may also involve processor <NUM> applying the updated one or more parameters and starting an updated TXS EDCA timer at an end of the acknowledgement. Alternatively, in updating the one or more parameters of the EDCA parameter set, process <NUM> may also involve processor <NUM> applying the updated one or more parameters and starting an updated TXS EDCA timer at an end of the transmitting of the PPDU when the PPDU does not require an immediate response. Still alternatively, in updating the one or more parameters of the EDCA parameter set, process <NUM> may also involve processor <NUM> applying the updated one or more parameters and starting an updated TXS EDCA timer at an end of a negotiated allocated time.

In some implementations, process <NUM> may further involve processor <NUM> indicating, via transceiver <NUM>, a required allocation time responsive to receiving the MU-RTS TXS trigger frame.

In some implementations, responsive to the MU-RTS TXS trigger frame containing a value indicating the allocated time, in indicating, process <NUM> may involve processor <NUM> transmitting a CTS frame containing a duration field that indicates the required allocation time. In some implementations, a value of <NUM> or a predefined value in the duration field may indicate the required allocation time. Moreover, a value greater than <NUM> and less than or equal to the allocated time in the duration field may indicate the negotiation of a required allocation time different than the allocated time.

In some implementations, in indicating, process <NUM> may involve processor <NUM> indicating, in the PPDU, a required allocation time. In such cases, a value of the required allocation time may indicate a time no later than an ending time of the PPDU carrying the MU-RTS TXS trigger frame plus the required allocation time in soliciting the MU-RTS TXS trigger frame. In some implementations, a value of the required allocation time may be carried in a TXOP duration field of a SIG-A field of the PPDU or in a duration field of a MAC header of the PPDU.

Claim 1:
A method, comprising:
receiving, from an access point, in the following also referred to as AP, by a station, in the following also referred to as STA, associated with the AP, an indication of an enhanced distributed channel access, in the following also referred to as EDCA, parameter set (<NUM>); and
updating, by the STA, one or more parameters of the EDCA parameter set with respect to a triggered transmission opportunity, in the following also referred to as TXOP, sharing, in the following also referred to as TXS, operation, wherein the EDCA parameter set is used to control the use of EDCA for channel contention by associated STAs following the triggered TXS operation and the associated STAs include the STA (<NUM>),
characterized in that
the updating the one or more parameters of the EDCA parameter set is performed at an end of an immediate acknowledgement received by the STA from the AP in response to transmission of a frame by the STA.