Request trigger frame and TXOP sharing launched by non-AP sta

Abstract

To provide a request trigger frame and TXOP sharing launched by a non-AP STA.SOLUTION: In a wireless communication apparatus, system or method for operating on a network utilizing CSMA / CA, non-AP stations can share their TXOP. After obtaining a TXOP, a non-AP station informs the AP to share the TXOP within its BSS. The AP collects buffer status and the QoS requirements of the buffer from the stations and arranges transmissions during the shared TXOP to satisfy the QoS requirement of the buffer reported by the STAs. The non-AP station can also share its TXOP through the AP using trigger frames or other mechanisms. The AP station may be part of a multi-link device and the AP can arrange transmissions on multiple links of an MLD.SELECTED DRAWING: Figure 21

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 066,354, filed August 17, 2020, which is incorporated by reference in its entirety.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT N / A

[0003] [Incorporation by reference of Computer Program Appendix] N / A

[0004] Notification of copyrighted material Portions of the material in this patent document may be subject to copyright protection under the copyright laws of the United States and other countries. The copyright owner has no objection to the copying by any third party of the patent document or the patent disclosure as it appears in the U.S. Patent and Trademark Office public files or records, but otherwise reserves all copyright rights. The copyright owner does not hereby waive any of its rights to have this patent document maintained in secrecy, including, but not limited to, the right pursuant to 37 CFR §1.14.

[0005] The technology of the present disclosure relates generally to wireless communication systems (WLANs), and more specifically to a WLAN using CSMA / CA in which non-access point (non-AP) stations obtain and share transmission opportunities (TXOPs) and the AP arranges for transmission through a buffer during the TXOP. [Background technology]

[0006] Current wireless technologies using Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) are focused on achieving high throughput performance in the network, but lack the ability to address the needs of some packets for low latency delivery, such as those required by real-time applications (RTA).

[0007] RTA requires low latency communication and uses best effort communication. Data resulting from RTA and packetized as RTA packets at a source station (STA) is referred to herein as RTA traffic. Data resulting from non-time sensitive applications and packetized as non-RTA packets at a source station STA is referred to herein as non-RTA traffic.

[0008] RTA packets require low latency due to high timeliness requirements for packet delivery. RTA packets are effective if they are delivered within a certain time. One solution in CSMA / CA wireless technology is to allow STAs to obtain channel access rights more quickly with less channel contention time.

[0009] The random channel access scenario of CSMA / CA requires STAs to sense the channel and contend for access before transmitting each packet. Although a short channel contention time speeds up channel access, it is still long compared to the latency requirements of RTA packets and therefore may prevent delivery within the required time interval. Summary of the Invention [Problem to be solved by the invention]

[0010] Thus, a need exists for a mechanism to support low latency RTA packet transmission. The present disclosure fulfills this need and provides further advantages over previous techniques. [Means for solving the problem]

[0011] In a WLAN protocol using CSMA / CA, a non-AP STA acquires a TXOP and notifies an AP to share the TXOP within its BSS. The AP of the BSS collects the buffer status and the QoS requirement of the buffer from the STA. The AP then arranges transmission in the shared TXOP to satisfy the Quality of Service (QoS) requirement of the buffer reported by the STA.

[0012] In one variation of the above, a non-AP STA sends a trigger request frame (RTF) to its associated AP and embeds recommended parameter settings for the trigger frame (TF) in the RTF. The AP receives the RTF and transmits the TF as requested by the STA.

[0013] In a further variation, we describe how to employ this method with multi-link operation. In one variation, an AP multi-link device (MLD) transmits a Buffer Status Report (BSRP) frame on one link to collect buffer status and buffer QoS requirements from associated non-AP MLDs. The AP MLD shares the buffer status and buffer QoS requirements of the associated non-AP MLDs with all affiliated APs in multiple links. Each affiliated AP uses the buffer status and buffer QoS requirements from the associated non-AP MLDs to schedule transmissions.

[0014] In another variation, a non-AP STA accesses the channel on one link and shares its TXOP with the associated AP. The AP MLD of the associated AP contends for the channel on the other link and wins channel access during the TXOP sharing period on link 1. The AP MLD coordinates transmission on both links.

[0015] This disclosure includes numerous variations and embodiments.

[0016] Further aspects of the technology described herein will become apparent in the following portions of this specification, and this detailed description is intended to fully disclose preferred embodiments of the technology without limiting them.

[0017] The techniques described herein will be better understood with reference to the following drawings, which are for illustrative purposes only. [Brief description of the drawings]

[0018] [Figure 1] 1 is a flow diagram of a retransmission scheme in CSMA / CA based on IEEE 802.11. [Figure 2A] 1 is a data field diagram of a data frame and an ACK frame format in a typical WLAN system. [Figure 2B] 1 is a data field diagram of a data frame and an ACK frame format in a typical WLAN system. [Diagram 3] FIG. 1 is a data field diagram of an HE-SU PPDU frame format in IEEE 802.11ax. [Figure 4] FIG. 11 is a communication sequence diagram of a double contention window when performing retransmission in CSMA / CA. [Diagram 5] FIG. 11 is a communication sequence diagram showing that a packet is discarded due to the retry count limit being reached in CSMA / CA. [Figure 6] FIG. 1 is a data field diagram of a HE-MU PPDU frame format in IEEE 802.11ax. [Figure 7] This is a data field diagram of the HE-TB PPDU frame format in IEEE 802.11ax. [Figure 8] FIG. 1 is a data field diagram of a trigger frame format in IEEE 802.11ax. [Figure 9] FIG. 9 is a data field diagram of a common information field in the trigger frame shown in FIG. 8. [Figure 10] FIG. 9 is a data field diagram of a user information field in the trigger frame shown in FIG. 8. [Figure 11] FIG. 11 is a data field diagram of the trigger-dependent user information field in the trigger frame shown in FIG. 10 for MU-BAR. [Figure 12] FIG. 1 is a data field diagram of a Block Ack (BA) frame format in a typical WLAN system. [Figure 13] FIG. 1 is a data field diagram of the BSR frame format. [Figure 14] FIG. 1 is a communication sequence diagram of a CSMA / CA retransmission scheme in the downlink of an OFDMA system. [Figure 15] FIG. 1 is a communication sequence diagram of a CSMA / CA retransmission scheme in the uplink of an OFDMA system. [Figure 16] FIG. 1 is a queue structure diagram of the EDCA queue system. [Figure 17] FIG. 1 is a communication format diagram of EDCA channel access. [Figure 18] FIG. 2 is a data field diagram of a typical IEEE 802.11be preamble. [Figure 19] FIG. 2 is a hardware block diagram of a station configuration, such as that included in multilink device hardware, in accordance with at least one embodiment of the present disclosure. [Figure 20] 1 is an embodiment of a station topology contemplated in accordance with at least one embodiment of the present disclosure. [Figure 21] 1 is a flow diagram for a non-AP STA to share a TXOP within an associated BSS, performed in accordance with at least one embodiment of the present disclosure. [Figure 22] 1 is a flow diagram of an AP receiving a frame to initiate TXOP sharing from a non-AP STA, performed in accordance with at least one embodiment of the present disclosure. [Figure 23] 1 is a flow diagram for a non-AP STA to send an RTF in accordance with at least one embodiment of the present disclosure. [Figure 24]FIG. 13 is a flow diagram for an AP to receive an RTF in accordance with at least one embodiment of the present disclosure. [Diagram 25] FIG. 1 is a flow diagram for an AP to collect buffer status of STAs in its BSS in accordance with at least one embodiment of the present disclosure. [Figure 26] 4 is a flow diagram for a non-AP STA to report its buffer status to an associated AP, in accordance with at least one embodiment of the present disclosure. [Figure 27] 1 is a communication sequence diagram including an example in which a non-AP STA requests a P2P trigger frame from an AP, in accordance with at least one embodiment of the present disclosure. [Figure 28] FIG. 11 is a communication sequence diagram including an example in which a non-AP STA requests a P2P trigger frame from an AP and the AP transmits multiple P2P-TFs, in accordance with at least one embodiment of the present disclosure. [Figure 29] FIG. 11 is a communication sequence diagram including an example in which a non-AP STA requests a P2P trigger frame from an AP and the AP transmits one P2P-TF for multiple P2P transmissions, in accordance with at least one embodiment of the present disclosure. [Diagram 30] 1 is a communication sequence diagram including an example in which a non-AP STA requests a basic trigger frame from an AP, in accordance with at least one embodiment of the present disclosure. [Diagram 31] A communication sequence diagram including an example in which a non-AP STA requests a basic trigger frame from an AP for use of all RUs, performed in accordance with at least one embodiment of the present disclosure. [Diagram 32] FIG. 13 is a communication sequence diagram including an example in which a non-AP STA requests a basic trigger frame from an AP and the AP transmits one TF for multiple uplink transmissions, in accordance with at least one embodiment of the present disclosure. [Diagram 33] FIG. 11 is a communication sequence diagram including an example in which a non-AP STA requests a basic trigger frame from an AP and the AP transmits multiple TFs, in accordance with at least one embodiment of the present disclosure. [Diagram 34]1 is a communication sequence diagram including an example of a non-AP STA sharing a TXOP by sending an RTF frame to an AP, in accordance with at least one embodiment of the present disclosure. [Diagram 35] 1 is a communication sequence diagram including an example of a non-AP STA sharing a TXOP by sending an RTS frame to an AP, in accordance with at least one embodiment of the present disclosure. [Diagram 36] FIG. 11 is a communication sequence diagram including an example of a non-AP STA sharing a TXOP by transmitting a MU-BSR frame to an AP when two STAs in MU-BSR use different RUs to carry buffer status reports, performed in accordance with at least one embodiment of the present disclosure. [Figure 37] FIG. 11 is a communication sequence diagram including an example of a non-AP STA sharing a TXOP by transmitting a MU-BSR frame to an AP when two STAs in MU-BSR use the same RU to carry a buffer status report, performed in accordance with at least one embodiment of the present disclosure. [Figure 38] 1 is a communication sequence diagram illustrating an example in which a non-AP STA shares a TXOP by sending a CTS frame to an AP, in accordance with at least one embodiment of the present disclosure. [Figure 39] FIG. 1 is a communication sequence diagram including an example in which a non-AP STA shares a TXOP by transmitting a BSR frame to an AP, in accordance with at least one embodiment of the present disclosure. [Diagram 40] 1 is a communication sequence diagram including an example in which a non-AP STA initiates a P2P transmission by sending an RTF frame to an AP without sharing a TXOP, in accordance with at least one embodiment of the present disclosure. [Diagram 41] 1 is a communication sequence diagram including an example in which a non-AP STA initiates a P2P transmission by sending an RTF frame to an AP using TXOP sharing, in accordance with at least one embodiment of the present disclosure. [Diagram 42]1 is a communication sequence diagram including an example of enabling P2P transmission when a non-AP STA shares a TXOP by sending a P2P-BSR frame to an AP, in accordance with at least one embodiment of the present disclosure. [Diagram 43] FIG. 11 is a communication sequence diagram including an example of enabling P2P transmission when a non-AP STA shares its TXOP by sending a MU-BSR frame to an AP when two STAs in MU-BSR use different RUs to carry BSR, in accordance with at least one embodiment of the present disclosure. [Diagram 44] FIG. 11 is a communication sequence diagram including an example of enabling P2P transmission when a non-AP STA shares its TXOP by sending a MU-BSR frame to an AP when two STAs in MU-BSR use the same RU to carry a BSR, in accordance with at least one embodiment of the present disclosure. [Diagram 45] 1 is a communication sequence diagram illustrating an example of enabling P2P transmission when a non-AP STA shares a TXOP by sending a CTS frame to an AP, in accordance with at least one embodiment of the present disclosure. [Figure 46A] FIG. 2 is a communication sequence diagram including an example of enabling P2P transmission when a non-AP STA shares its TXOP, in accordance with at least one embodiment of the present disclosure. [Figure 46B] FIG. 2 is a communication sequence diagram including an example of enabling P2P transmission when a non-AP STA shares its TXOP, in accordance with at least one embodiment of the present disclosure. [Figure 47A] A communication sequence diagram including an example of an AP arranging for transmission in a TXOP in accordance with at least one embodiment of the present disclosure. [Figure 47B] A communication sequence diagram including an example of an AP arranging for transmission in a TXOP in accordance with at least one embodiment of the present disclosure. [Figure 47C] A communication sequence diagram including an example of an AP arranging for transmission in a TXOP in accordance with at least one embodiment of the present disclosure. [Figure 48A]A communication sequence diagram including an example in which a non-AP MLD shares its own TXOP in a multi-link scenario when the non-AP MLD does not have STR capability, performed in accordance with at least one embodiment of the present disclosure. [Figure 48B] A communication sequence diagram including an example in which a non-AP MLD shares its own TXOP in a multi-link scenario when the non-AP MLD does not have STR capability, performed in accordance with at least one embodiment of the present disclosure. [Figure 49] FIG. 2 is a data field diagram of either type of BSR frame format in accordance with at least one embodiment of the present disclosure. [Figure 50] FIG. 2 is a data field diagram of a BA+BSR frame format in accordance with at least one embodiment of the present disclosure. [Figure 51] FIG. 2 is a data field diagram of a Data+BSR frame format in accordance with at least one embodiment of the present disclosure. [Figure 52] FIG. 1 is a data field diagram of an HT control field format for a BSR control subfield variant in accordance with at least one embodiment of the present disclosure. [Diagram 53] FIG. 1 is a data field diagram of an RTA-BSR control subfield as an A control subfield in accordance with at least one embodiment of the present disclosure. [Figure 54] FIG. 1 is a data field diagram of a P2P-BSR control subfield as an A control subfield in accordance with at least one embodiment of the present disclosure. [Figure 55] FIG. 2 is a data field diagram of an RTF frame format in accordance with at least one embodiment of the present disclosure. [Figure 56] FIG. 13 is a data field diagram of a CTS frame format for TXOP sharing in accordance with at least one embodiment of the present disclosure. [Figure 57] A data field diagram of a P2P trigger frame format and its subordinate user information fields in accordance with at least one embodiment of the present disclosure. [Figure 58]A data field diagram of a preamble format when indicating TXOP sharing in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] 1. WLAN systems based on IEEE802.11 1.1.CSMA / CA System IEEE 802.11 in WLAN systems uses CSMA / CA to allow stations (STAs) to gain access to a channel for packet transmission and retransmission.

[0020] Figure 1 is a flow diagram of this process. In a CSMA / CA system, a STA needs to sense the channel condition before each transmission and retransmission and set a backoff time to contend for channel access. The backoff time is determined by a uniform random variable between zero and the contention window size. After a STA waits for the backoff time and senses that the channel is idle, it can transmit a packet.

[0021] If an acknowledgement (ACK) for the transmission is received, the transmission is successful. Otherwise, the STA needs to retransmit this packet because it did not receive an ACK for the packet transmission before a timeout occurred. If a retransmission is necessary, the STA checks the number of retransmissions performed for the packet. If the number of retransmission attempts exceeds the retry limit, the packet is discarded and not scheduled for retransmission. Otherwise, a retransmission is scheduled.

[0022] If a retransmission is scheduled, another backoff period is required to contend for retransmission channel access. If the contention window size has not yet reached its upper limit, the STA increases the size of the contention window.

[0023] The STA sets another backoff time according to the size of the new contention window. The STA waits for the backoff time, checks the channel condition, performs retransmission, and proceeds accordingly.

[0024] Figure 2A shows a data frame format in a typical WLAN system with the following fields: The Frame Control field indicates the type of frame. The Duration field contains NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The Sequence control field contains the fragment number and sequence number of the packet. The Data field contains the data payload of the frame. Also shown here and in other data structures described herein is the Frame Check Sequence (FCS). The FCS is an error detection code added to frames in communication protocols when communicating data from a source to a destination.

[0025] Figure 2B shows an ACK frame format in a typical WLAN system, with the following fields: Frame Control field indicates the type of frame; Duration field contains NAV information used for CSMA / CA channel access; RA field contains the address of the receiver of the frame.

[0026] FIG. 3 shows a high efficiency (HE) single user (SU) physical layer protocol data unit (PPDU) format used for single user (SU) transmission in IEEE 802.11ax, which includes the following fields:

[0027] The L-STF field is a non-HT short training field. The L-LTF field is a non-HT long training field. The L-SIG field is a non-HT SIGNAL field. The RL-SIG field is a repeated non-HT SIGNAL field. The HE-SIG-A field is a HE SIGNAL A field. The HE-STF field is a HE short training field. The HE-LTF field is a HE long training field. The Data field is a field that carries data as a PSDU. The PE field is a packet extension field.

[0028] FIG. 4 shows one retransmission example where the backoff time increases due to retransmission in CSMA / CA. Data frames and ACK frames use the formats shown in FIG. 2A-2B, respectively. The frames are packetized using the packet format shown in FIG. 3. In this example, the sender does not receive an ACK after the first packet transmission until the timeout. Therefore, the sender sets another backoff time for the first retransmission where the contention window size is n slots. The sending STA only retransmits the packet after waiting the backoff time. However, this retransmission also fails. The sending STA needs to retransmit the packet and sets the backoff time again to contend for channel access again. This time, the contention window size is doubled to 2 slots because it is a retransmission. * n slots. This contention window size also doubles the expected backoff time. The second retransmission is successful because an ACK is received before the timeout.

[0029] Figure 5 shows an example of a packet being discarded after the number of retransmissions exceeds the retry limit. Let the retry limit be R. Data and ACK frames use the formats shown in Figures 2A and 2B, respectively. The frames are packetized using the packet format shown in Figure 3. As shown in Figure 5, the sending STA retransmits the packet multiple times after the first packet transmission fails. However, none of the retransmissions are successful. After R retransmissions, the number of retransmissions exceeds the retry limit, which causes the sending STA to stop retransmitting the packet and the packet is discarded.

[0030] 1.2. Multi-user transmission Multi-user transmission is available in wireless networks such as IEEE 802.11. From IEEE 802.11ax onwards, the network supports multi-user transmission in both uplink and downlink directions. Multi-user transmission in IEEE 802.11ax includes multiple-input multiple-output (MIMO) mode and orthogonal frequency division multiple access (OFDMA) mode, which can be used alone or simultaneously.

[0031] IEEE 802.11ax uses a multi-user (MU) transmission packet format as shown in Figures 2A and 2B to transmit data in multi-user mode. When multiple users transmit or receive a multi-user transmission packet, all users share the same Physical Layer Convergence Procedure (PLCP) header of the multi-user transmission packet. Then, each user transmits or receives the data carried by the multi-user transmission packet using a different resource block, including resource unit (RU) allocation and modulation coding scheme (MCS), etc.

[0032] IEEE 802.11ax defines several PPDU formats for transmitting packets in different multi-user transmission scenarios, which are listed as follows:

[0033] The HE Multi-User (MU) PPDU format used for downlink (DL) multi-user transmission is shown in Figure 6. Compared to the single-user PPDU format as shown in Figure 3, this format adds an HE-SIG-B field that provides dedicated resource block allocation information for each user.

[0034] The HE trigger-based (TB) PPDU format used for uplink (UL) multi-user transmission is shown in Figure 7. The fields of the HE TB PPDU format are identical to those of the HE single-user PPDU format, except that the HE-STF field length is 8 μs.

[0035] Figure 8 shows the contents of the trigger frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The Common Info field contains information of all assigned STAs as shown in Figure 9. The User Info field contains information for each STA as shown in Figure 10. The Common Info and User Info fields provide individual resource block allocation information for each user.

[0036] A trigger frame such as that shown in Figure 8 can be sent as a Multi-User Block Ack Request (MU-BAR) by setting the trigger type in the common information field to "2". Figure 11 shows the contents of the trigger dependent user information field (as shown in Figure 10) in the trigger frame when the trigger frame is a MU-BAR.

[0037] Figure 12 shows the contents of a Block Ack frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The Block Acknowledge (BA) Control field indicates the Block Ack policy. The BA Information field contains feedback on the transmission.

[0038] Figure 13 shows the contents of a Buffer Status Report (BSR) frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The HT Control field indicates the BSR control subfield variant. The Format Indication is a field used to indicate the format of the HT control field. Bits B0 and B1 in this field, when set to 1, indicate that the HT control field uses the HE format. This field is followed by the A-Control field. The A-Control field is the field that carries the Buffer Status Report. The Control ID field indicates that the BSR is carried in the Control Information field. The Control Information field carries the BSR control subfield variant. The ACI Bitmap field indicates the access category for which the buffer status is reported. The Delta TID field indicates the number of TIDs for which buffer status is being reported. The ACI High field indicates the access category reported in the Queue Size High field. The Scaling Factor field indicates the units used by the Queue Size High and Queue Size All fields. The Queue Size High field indicates the queue size in units of the Access Category (AC) indicated in the ACI High. The Queue Size All field indicates the queue size in units of the AC indicated in the ACI Bitmap.

[0039] Figure 14 shows an example of downlink (DL) multi-user (MU) transmission using Orthogonal Frequency Division Multiple Access (OFDMA). The transmitting AP transmits data to receivers 1, 2, 3 and 4 using HE MU PPDU format. The AP sends a Multi-User Block Ack Request (MU-BAR) to all receivers after the first transmission is finished. The receivers send back Block Ack (BA) to the AP. The AP decides to retransmit packets to receivers 1, 3 and 4 according to the content of the BA. The AP contends for the channel after waiting for a backoff time. The first retransmission occurs after the AP has acquired channel access rights.

[0040] Figure 15 shows an example of an uplink (UL) multi-user (MU) transmission using OFDMA. The AP first transmits a Buffer Status Report Request (BSRP) trigger frame to all senders 1, 2, 3, and 4. The senders receive the BSRP trigger frame and send a Buffer Status Report (BSR) back to the AP. The AP then transmits a trigger frame to all senders 1, 2, 3, and 4. The channel resources allocated in the trigger frame are based on the BSR received from the STA. The senders receive the trigger frame and start their initial transmission using the resource blocks allocated in the trigger frame. The multi-user transmission packet uses the HE-TB PPDU format. The AP receives the packet from the sender and transmits a BA frame to report that the transmission was received correctly.

[0041] 3.3.EDCA System A reference model of the Enhanced DCF Channel Access (EDCA) queue system in IEEE 802.11 is shown in Figure 16. The system includes six transmission queues associated with four different Access Categories (ACs). Each AC competes for channel access rights using the EDCA Functions (EDCAF) to transmit packets in its corresponding transmission queue.

[0042] The six transmit queues are Voice (VO), Alternate Voice (A_VO), Alternate Video (A_VI), Video (VI), Best Effort (BE), and Background (BK). Each transmit queue determines the order in which packets in the queue are transmitted.

[0043] The four ACs are Voice (VO), Video (VI), Best Effort (BE) and Background (BK). Each AC has an EDCA Function (EDCAF) that provides channel contention capabilities. When multiple EDCAFs attempt to access the channel simultaneously, an internal collision avoidance mechanism is used. In case of an internal collision, the EDCAF with the higher priority gets the channel access right.

[0044] Table 1 lists the user priority (UP) mapping to the access categories (AC) used in IEEE 802.11 EDCA queues. The second and third columns represent the user priority of the traffic and its corresponding IEEE 802.1D designation. In each row, traffic is added to the corresponding transmission queue and access category according to the user priority. The priority increases from the top row to the bottom row. Higher priority traffic has a higher probability of being transmitted sooner.

[0045] Figure 17 shows the channel access procedure for EDCA. As shown, this figure also compares EDCA channel access when only Distributed Coordination Function (DCF) is used. When only DCF is used, the STA can immediately access the channel if the medium is free for more than DCF Interframe Space (DIFS) time. Otherwise, the STA contends for the channel using CSMA / CA. After the STA senses that the channel is idle for a DIFS time, it starts counting down the backoff as long as the medium is idle. The number of backoff slots is randomly selected between 0 and the contention window. The contention window is updated as shown in Figure 1. The STA pauses the backoff countdown when a CCA busy occurs, such as when the STA senses that the channel is busy. When the backoff counts down to zero, the STA starts transmitting packets.

[0046] In EDCA, each EDCAF as shown in FIG. 16 can immediately access the channel, and the medium is unused for longer than the Arbitration Interframe Spacing (AIFS) of the AC that is going to gain channel access. It should be understood that the AIFS[i] in the figure represents the AIFS time of ACi. Otherwise, each EDCAF uses CSMA / CA to contend for the channel of each AC that is going to gain channel access. After each EDCAF senses that the channel is idle for the AIFS time, it starts counting down the backoff as long as the medium is idle. The number of backoff slots is randomly selected between 0 and the contention window size. The contention window size is updated as shown in FIG. 1. The STA pauses the backoff countdown when a CCA busy occurs, such as when it senses that the channel is busy. When the backoff counts down to zero, the STA starts transmitting packets for that AC.

[0047] It should be understood that multiple EDCAFs can contend for the channel at the same time. For example, as shown in Figure 17, an EDCAF for ACi and an EDCAF for ACj can contend for the channel at the same time. When an internal collision occurs, the EDCAF with higher priority wins the channel access right and the EDCAF with lower priority can double the contention window. If the ACs are VO or VI, they can reserve a period of contention free time for packet transmission, i.e., TXOP. The maximum duration of a TXOP is shown as TXOP limit.

[0048] Table 2 lists the default parameter settings for EDCA channel access. Each AC has its own minimum and maximum contention window. AIFSN represents the AIFS duration in terms of the number of backoff slots. TXOP limit represents the maximum TXOP duration each AC can reserve each time.

[0049] 1.4.Normal IEEE802.11be PLCP Preamble FIG. 18 is a typical IEEE 802.11be preamble format with the following fields: L-STF field indicates a non-HT short term training field; L-LTF field indicates a non-HT long term training field; L-SIG field indicates a non-HT signal field; RL-SIG field indicates a repeating non-HT signal; U-SIG field indicates an EHT universal field; EHT-SIG field indicates an EHT signal field; EHT-STF field indicates an EHT short term training field, but could be replaced by some other type of signal training field; EHT-STF field indicates an EHT short term training field; EHT-LTF field indicates an EHT long term training field.

[0050] 2. Problem Statement The disclosed technology describes a WLAN protocol that supports TXOP sharing within one BSS: A non-AP STA acquires a TXOP and shares the TXOP within the BSS.

[0051] In current wireless communication systems using CSMA / CA, non-AP STAs cannot share their TXOP with other STAs in the BSS. In traditional wireless protocols, each non-AP STA must contend for the channel alone to obtain a TXOP.

[0052] In order to reduce the delay caused by contention time, a TXOP sharing mechanism is utilized to reduce the contention time among multiple STAs. Any STA accessing the channel can share its TXOP within the BSS. When a TXOP is shared, multiple STAs can transmit during a shared TXOP, so each channel does not need to contend alone for channel access rights.

[0053] In the current wireless communication system using CSMA / CA, an AP can arrange transmissions such as multi-user transmissions in its TXOP. The AP can collect buffer status from STAs and initiate uplink transmission. When the AP collects buffer status from associated STAs, it only gets the amount of buffered traffic for uplink transmission. However, it may be recognized that the current BSR frame does not reflect the QoS requirements of RTA traffic, even though RTA traffic has high timeliness requirements. Therefore, it is difficult for the AP to arrange transmissions in its TXOP to meet the QoS requirements of RTA traffic.

[0054] In current wireless communication systems using CSMA / CA, APs cannot arrange peer-to-peer (P2P) transmission in their TXOPs. For some devices such as AR / VR, it may be of great demand to transmit large amounts of data directly from one non-AP STA to another non-AP STA.

[0055] The task of designing a TXOP sharing mechanism in a CSMA / CA system becomes even more challenging when considering the following scenarios: RTA and non-RTA packets coexist, and RTA packets have a timeliness requirement that they must be transmitted before their expiration time is reached. Peer-to-Peer (P2P) transmissions are possible, and the challenge is to initiate a P2P transmission during a shared TXOP. A TXOP sharing mechanism must be designed with the objective of minimizing the delay of RTA packets while considering the timeliness of RTA traffic in wireless networks where RTA and non-RTA traffic coexist.

[0056] 3. Contribution of this Disclosure The disclosed technology solves the TXOP sharing problem when a non-AP STA acquires a TXOP and shares it within a BSS. The disclosed technology allows a non-AP STA that acquires a TXOP to send a frame to its AP indicating the start of TXOP sharing. The AP can then collect buffer status from the STAs and arrange (order / schedule) their transmissions during the shared TXOP.

[0057] The disclosed technology solves the problem that the AP can only obtain the buffer size of the STA when scheduling uplink transmission. The disclosed technology defines a different type of Buffer Status Report (BSR) that can carry QoS requirement information about the reported buffer. The AP can arrange the transmission in the TXOP to meet the QoS requirement of the reported buffer.

[0058] The disclosed technique solves the problem of the AP arranging P2P transmissions during a TXOP, since the STAs can report P2P buffer status and the AP is informed of the scheduling of P2P transmissions in the TXOP.

[0059] The disclosed technology can also enable sharing of buffer status reports among APs belonging to the same AP Multi-Link Device (MLD). Once the buffer status of a non-AP MLD is collected on one link, this information can be shared with other belonging APs. The AP MLD can then arrange for transmission over multiple links according to the buffer status reports from the non-AP MLD.

[0060] 4. Embodiment 4.1.STA Hardware Configuration An example station hardware embodiment 10, illustrated herein in the form of a Multi-Link Device (MLD) hardware configuration, is shown in Figure 19. The MLD serves multiple STAs with up to "n" stations 12a, 12b...12n, each operating on a different frequency link.

[0061] Each station (STA) hardware has external I / O access 14 to applications and an internal bus 16 connecting to at least one processor (CPU, MCU, SoC, or other control circuitry) 18 and memory (e.g., RAM, or similar program and / or data store) 20, the combination of which is configured to execute programs that implement this wireless communication protocol.

[0062] Each STA contains at least one modem 22 supporting communications coupled to at least one RF module 24 connected to one or more antennas 26a, 26b, 26c-26n that implement communications in one or more bands, such as sub-6 GHz (e.g., 2.4, 5, 6 GHz) and / or millimeter wave (mmW) bands. In at least one embodiment, RF module 24 includes a frequency converter, an array antenna controller, and other associated circuitry.

[0063] In some embodiments, the RF can be configured for omni-directional antenna operation and / or can be directional to increase gain. As an example, the illustrated RF module 24 has multiple antennas to support beamforming for transmission and reception on the band. In this manner, the STAs can transmit signals using one or more sets of beam patterns. It should be understood that any desired band can be supported by the teachings of this disclosure. The example shows multiple STAs grouped (clustered) within the multi-link device.

[0064] The bus 14 can connect various devices such as sensors and actuators to the CPU. On the processor 18, instructions are executed from the memory 20 to execute a program implementing a communication protocol that is executed so that the STA can function as an access point (AP) station or a non-AP (normal) station (STA). It is also understood that this programming is configured to operate in different modes (source, transmitter, intermediate, destination, receiver, first AP, other AP, non-AP station associated with the first AP, non-AP TXOP owner station, non-AP TXOP participant station, non-AP TXOP non-participant station, station associated with another AP, coordinator, coordinate, etc.) depending on what role it plays in the current communication situation. The protocol is also configured to operate with one or more other stations in a multilink device (MLD) configured for simultaneous transmit and receive (STR MLD) or in a multilink device without such capability (non-STR MLD).

[0065] It should be understood that STAs of the present disclosure, such as those in this MLD, can be configured to have multiple modems 22, each coupled to any number of RF circuits. In general, the more RF circuits used, the greater the coverage in the antenna beam direction. It should be understood that the number of RF circuits and antennas utilized is determined by the hardware constraints of a particular device. Some RF circuits and antennas can be disabled when a STA determines that it does not need to communicate with neighboring STAs.

[0066] The illustrated MLD has an internal bus 34 for communication between its processor 36 and associated memory 38 and each of the STAs 12a, 12b-12n. The MLD also has an external I / O 32 for executing the MLD's applications, programs that access the MLD management entity's CPU and RAM to implement communications protocols at the MLD level. The MLD can allocate tasks to each of its associated STAs, collect information from each of its associated STAs, and share information among itself.

[0067] It should also be understood that each STA in an MLD need not have its own processor and memory. In at least one embodiment, one or more stations in an MLD can share processors and memory with each other, or can share the processor and memory of the MLD circuitry. Thus, this disclosure contemplates many possible arrangements for communication over multiple links in an MLD.

[0068] 4.2. STA Topologies Considered An example embodiment 50 of a wireless topology between MLDs is shown in Fig. 20. In this figure, a network scenario is presented to better explain the objectives of the proposed technology. It should be understood that this topology is shown only for the purpose of illustrating the case described herein, since the present disclosure provides protocols that can operate in any desired topology.

[0069] A Multi-Link Device (MLD) is a device that has multiple associated STAs and one Media Access Control (MAC) Service Access Point (SAP) to a Logical Link Control (LLC) that includes one MAC data service. In this example, assume that there are 10 STAs spread across five MLDs 56, 58, 60, 62, and 64 installed in some local area or structure (e.g., conference room) 52, illustrated as having one or more windows / doors 54. STA1 and STA1' belong to AP MLD1, and STA x and x' belong to non-AP MLDx, where x=2, 3, 4, or 5. STA2, 3, 4, 5 are associated with STA1 via link 1, and STA2', 3', 4', 5' are associated with STA1' via link 2.

[0070] If an MLD can transmit on one link and receive on the other link, such an MLD is called a simultaneous transmit-receive MLD (STR-MLD), whereas if an MLD cannot simultaneously transmit on one link and receive on the other link due to in-device operational constraints, the MLD is referred to herein as a non-STR MLD. A non-STR MLD can only transmit on one or both links simultaneously, or receive on one or both links simultaneously. In this example network topology, MLD1 is a STR MLD, and the other MLDs in this example can be either STR or non-STR.

[0071] All STAs use CSMA / CA for random channel access. It is also possible for MLD to be enabled on only one STA, allowing them to behave as a single-link device.

[0072] 4.3. TXOP Sharing Initiated by Non-AP STA This technical proposal proposes a method for a non-AP STA to share its TXOP with other STAs in the associated BSS. When a non-AP STA obtains channel access right, it notifies its associated AP to share its TXOP with other STAs in the BSS. When the STA starts TXOP sharing, it enables the AP to meet the requirements of the STA and trigger additional transmission during the TXOP sharing time. Then, the AP schedules the transmission during the TXOP according to the buffer status of the STA in the BSS.

[0073] FIG. 21 illustrates an example embodiment 70 of the steps a non-AP STA follows to share 72 its TXOP within an associated BSS.

[0074] The non-AP STA first performs a clear channel assessment (CCA) 74 to acquire channel access rights. Then, the non-AP STA transmits a frame including TXOP sharing information to the associated AP to indicate TXOP sharing (76). This frame can include any of different types of frames configured to also include sharing information, such as a request to send (RTS) frame or a clear to send (CTS) frame or a buffer status report (BSR) frame, while a newly defined frame can be used, such as a trigger request frame (RTF) frame as shown in FIG. 55, and a new type of BSR frame is shown in FIG. 49. It is also possible that the RTS frame is a MU-RTS frame. When these frames are transmitted, the recipient address of the frame can be an address negotiated between the AP and the STA to indicate that the frame is to initiate TXOP sharing. Alternatively, the AP and the non-AP STA can schedule the period during which these frames are transmitted to initiate TXOP sharing by default. That is, when the AP receives these frames from a non-AP STA during the scheduled period, it knows (recognizes) that these frames are to initiate TXOP sharing.

[0075] At check 78, it is determined whether the non-AP STA received feedback from its associated AP before the timeout. If feedback is received, the TXOP sharing initiated by the non-AP STA is successful (80). For example, the feedback from the AP may include a CTS or trigger frame if an RTS was sent by the non-AP STA, or a trigger frame if another frame indicating TXOP sharing was sent by the non-AP STA. Next, at block 82, the non-AP STA transmits during the TXOP according to the schedule determined by the AP.

[0076] On the other hand, if block 78 determines that the non-AP STA did not receive feedback from its associated AP before the timeout, then the TXOP sharing initiated by the non-AP STA fails (84).

[0077] FIG. 22 illustrates an example embodiment 90 of a method by which an AP initiates TXOP sharing 92 within an associated BSS when one of the associated STAs owns the TXOP.

[0078] The AP receives a frame from a non-AP STA to initiate TXOP sharing within the BSS (94). The AP can optionally send a BSRP trigger frame to collect the buffer status of associated STAs (96). For example, the AP can send a BSRP when it receives a CTS frame or an RTF with trigger type information set to BSRP. The procedure by which the AP collects the buffer status including the QoS requirements of associated STAs is described in FIG. 25. The AP schedules transmission during the TXOP according to the buffer status of associated STAs (98). The purpose of this scheduling is to perform best effort to meet the QoS requirements such as delay time, jitter and packet loss for all packets of associated STAs.

[0079] 4.4. Trigger Request Frame Initiated by Non-AP STA The techniques of this disclosure allow a non-AP STA to request an associated AP to transmit a trigger frame.

[0080] FIG. 23 illustrates an example embodiment 110 of a method for a non-AP STA to request a TF from an associated AP. When a non-AP STA requests a TF from an AP (112), it first performs a clear channel assessment (CCA) 114 in preparation for gaining channel access rights. The non-AP STA then sends an RTF to the AP (116). The RTF indicates the type of TF requested and includes recommended parameter settings for the TF. The RTF may carry Buffer Status Report (BSR) information in a high throughput (HT) control field. The RTF indicates whether TXOP sharing is allowed.

[0081] In check 118, it is determined whether TXOP sharing is allowed. If sharing is allowed, the non-AP STA follows 120 the triggered transmission scheduled by the AP. On the other hand, if sharing is not allowed, in block 122, the non-AP STA arranges to transmit independently after completing the RTF transmission and its solicited transmissions during the TXOP.

[0082] It should be understood that the TXOP sharing indication field and the TXOP sharing duration field in the RTF can be optional: if these two fields are not included in the RTF, or if there are no other fields in the RTF that indicate TXOP sharing, then TXOP sharing is not allowed by default.

[0083] The TXOP sharing indication field in the RTF can be replaced by setting the Receiver Address (RA) field to a special address negotiated with the AP to indicate that TXOP sharing is allowed.

[0084] The TXOP Shared Time field in the RTF can be replaced by setting the frame duration of the RTF.

[0085] FIG. 24 illustrates an example embodiment 130 of an AP's reaction when the AP receives 132 an RTF from an associated non-AP STA.

[0086] When an AP STA receives an RTF from an associated STA (132), it generates a TF of the type indicated in the RTF (134). The AP sets the parameters in the TF as recommended by the RTF to allocate channel resources for transmissions after the TF. The AP may add and adjust parameters in the TF. If the RTF carries BSR information, the AP should allocate channel resources to satisfy the BSR information carried by the RTF 134.

[0087] A check is performed (136) to determine whether the RTF allows TXOP sharing, i.e., whether the TXOP sharing indication field of the RTF is set to "1", after which TXOP sharing is allowed. If the condition is met after the AP has finished the TF and the solicited transmission and sharing is allowed, the AP continues to arrange transmission for the TXOP sharing time indicated in the RTF (138). On the other hand, if sharing is not allowed, the AP only transmits the TF (140).

[0088] It should be understood that the TXOP sharing indication field and the TXOP sharing duration field in the RTF can be optional: if these two fields are not included in the RTF, or if there are no other fields in the RTF that indicate TXOP sharing, then TXOP sharing is not allowed by default.

[0089] In at least one embodiment, the TXOP sharing indication field in the RTF can be replaced by setting the RA field to a special address negotiated with the AP to indicate that TXOP sharing is allowed. In at least one embodiment, the TXOP sharing time field of the RTF can be replaced by setting the frame duration of the RTF.

[0090] 4.5. Collecting Buffer Status This section describes how the AP collects the buffer status of associated STAs. As described in the previous section, it is important for the AP to collect the buffer status including the QoS requirements of associated STAs during the TXOP sharing time. According to the buffer status of associated STAs, the AP can schedule the transmission during the TXOP sharing time to meet the QoS requirements of all packets of the STAs.

[0091] It is assumed that every packet has an expiration time and that packets should be transmitted by their expiration time. RTA packets can have a short expiration time, whereas non-RTA packets usually have a long expiration time. Each STA knows the expiration time of each packet in its buffer. It should be understood that this buffer status collection procedure can be utilized for transmission scheduling during the TXOP time owned by the AP.

[0092] 25 illustrates an example embodiment 150 of a method for an AP to collect buffer status of associated STAs. When the AP collects 152 the buffer status of associated STAs, it sends 154 a BSRP frame to these STAs. The AP can then receive different types of buffer status reports from these STAs. In block 156, a check is made as to the type of buffer status report.

[0093] It should be understood that the disclosed technology also defines two other types of BSR frames, namely, P2P-BSR frame and RTA-BSR frame, in addition to the BSR frame defined in IEEE 802.11ax. The P2P-BSR frame is used to report a buffer for peer-to-peer transmission. The RTA-BSR frame is used to report the buffer status of RTA packets with low latency requirements. The RTA-BSR frame includes a buffer expiration time, i.e., packets in the reported buffer must be transmitted before the respective expiration time to meet the latency requirement. Details of the P2P-BSR frame and the RTA-BSR frame will be described later in Section 4.7. Due to the use of different types of BSR, the AP can receive P2P-BSR frames from some STAs (158), receive RTA-BSR frames from some STAs (160), and receive BSR frames defined in IEEE 802.11ax from other STAs (162).

[0094] FIG. 26 illustrates an example embodiment 170 of a method for a STA to report its buffer status to an AP. When a non-AP STA receives a BSRP from an associated AP, it must report its buffer status (172). The STA may first determine the type of BSR to report to the AP (174). The STA may decide to transmit a P2P-BSR frame (176) indicating that a buffer exists for a P2P transmission. The STA may decide to transmit an RTA-BSR frame (178) indicating that a buffer exists for an RTA packet that needs to be transmitted before the expiration time. The STA may decide to transmit a BSR frame (180) indicating the STA's coarse buffer status as defined in IEEE 802.11ax.

[0095] 4.6.Example 4.6.1. Trigger Request Frame by Non-AP STA In this section, we provide several examples that illustrate how a non-AP STA can request a trigger frame from its associated AP. The network topology for these examples is shown in Figure 20, where we only consider transmissions on link 1. In this section, we assume that the RTF does not have the TXOP sharing indication and TXOP sharing time fields.

[0096] 27 illustrates an example embodiment 190 in which a non-AP STA requests a P2P trigger frame by sending an RTF frame to the AP. As shown, all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel using backoffs 202, 204, 206, 208, and 210, and STA4 obtains channel access (212). It should be understood that this example is merely an example to illustrate the operation, and that any number of stations may contend for the channel in this and the following examples.

[0097] Next, STA4 transmits an RTF frame 214 to the AP to request a P2P trigger frame to initiate a P2P transmission from STA4 to STA5. This procedure is described in FIG. 23 at 116. The format of the RTF frame is described in FIG. 55. In response, the AP transmits a P2P trigger frame 216 to the associated STA4 to initiate the P2P transmission from STA4 to STA5 requested by the RTF. Since the RTF indicates that all channels are to be used for the P2P transmission, the AP allocates all channels to this P2P transmission. It can be seen that STA4 transmits data 218, after which STA5 responds with a block acknowledgement (BA) 220.

[0098] FIG. 28 illustrates an example embodiment 230 in which a non-AP STA requests a P2P trigger frame from an AP, after which the AP transmits multiple P2P-TFs.

[0099] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel using backoffs 202, 204, 206, 208 and 210, STA4 acquires channel access (212), reserves a TXOP (213), sends an RTF 214, receives a P2P-TF 216 from the AP, sends data 218 to STA5 and receives an acknowledgment via a block acknowledgment (BA) 220.

[0100] If the AP sends a further P2P-TF 232 upon completion of the data PPDU after the trigger frame, the STA can continue to send further PPDUs 234, to which STA5 can respond with a BA 236. The AP can trigger any number of data PPDUs up until the period for which the TXOP is reserved (STA4 reserved the TXOP in this case). Thus, in this figure, after the AP sends the first P2P-TF and STA4 finishes its P2P transmission, the AP can send another P2P-TF during the TXOP period 213 reserved by STA4 to start another P2P transmission for STA4, and so on.

[0101] FIG. 29 illustrates an example embodiment 250 in which the P2P-TF allocates resources (all or a portion of the available BW) given to P2P data transmission over a particular period of time.

[0102] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel together using backoffs 202, 204, 206, 208 and 210, and STA4 acquires channel access (212), reserves a TXOP (213), sends an RTF 214, receives a P2P-TF 216 from the AP, sends data 218 to STA5, and then receives a BA 220.

[0103] In this example, STA4 can use these RUs for the time indicated in the P2P-TF. STA4 can transmit multiple P2P packets to STA5 during its TXOP using the resources allocated by the P2P-TF after the AP has sent the P2P-TF, which also shows the transmission of data 252 and the reception of BA 254.

[0104] FIG. 30 illustrates an example embodiment 270 in which a non-AP STA requests a (basic) trigger frame by sending an RTF frame to the AP.

[0105] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend together for the channel using backoffs 202, 204, 206, 208 and 210, and STA4 wins channel access (212).

[0106] Next, in this example, STA4 transmits an RTF frame 272 to the AP to request a trigger frame to initiate a triggered UL transmission. The RTF may also carry BSR information from STA4. This procedure is described in block 116 of FIG. 23. The format of the RTF frame is described below in connection with FIG. 55. Next, the AP transmits a trigger frame 274 to the associated STA4 to initiate UL transmission of data reported by STA4's BSR. STA4 indicates in the RTF that it only requests RU3 for UL transmission and the remaining RUs, such as RU1, RU2, and RU4, are available for UL transmission by other STAs. In the illustrated example, it can be seen that STA4 transmits data on RU3 286 after a preamble 284 in a transmission to STA1. It can be seen that the other stations use their assigned RUs, with STA2 transmitting data 278 on RU1 after a preamble 276, STA3 transmitting data 282 on RU2 after a preamble 280, and STA5 transmitting data 290 on RU4 after a preamble 288. These transmissions are followed by a multi-user (MU) block acknowledgement (BA) 292 being sent from the AP to each participating station.

[0107] 31 shows an example embodiment 310 in which a non-AP STA requests a basic trigger frame from the AP to use all RUs. Thus, in this case, instead of the previous example of sharing TXOPs, STA4 decides to request to use all channels in its trigger frame, and in response, the AP sends a trigger frame 274 allocating all RUs to STA4 (e.g., in the case of SU-MIMO).

[0108] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel together using backoffs 202, 204, 206, 208 and 210, and STA4 wins channel access (212) and sends an RTF 272 along with the BSRP.

[0109] This figure illustrates the case where the AP responds to a request by a STA by sending a TF 274 and assigning all RUs to this STA. In this case, STA4 requests a (basic) trigger frame by sending an RTF frame 272 to the AP, and the AP responds by sending a TF 274 to assign all RUs to STA4 for uplink transmission. It can be seen that STA4 transmits a preamble 312 and data 314 over all RUs assigned to it, after which the AP generates a MU-BA (e.g., this frame can also be an ACK or BA frame) 316.

[0110] FIG. 32 illustrates an example embodiment 330 in which a non-AP STA requests a basic trigger frame from an AP, and the AP responds by sending one TF for multiple uplink transmissions.

[0111] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel together using backoffs 202, 204, 206, 208 and 210, and STA4 acquires channel access rights (212), reserves a TXOP (213), sends an RTF 272 for use of all RUs, receives a P2P-TF 274 from the AP, transmits a preamble 312 and data 314 using all RUs, and then receives an MU-BA 316.

[0112] In this example, if the AP sends another TF upon completion of the data PPDU after the trigger frame, the STA can continue to transmit further PPDUs. The AP can trigger any number of data PPDUs within the TXOP period reserved by the STA (STA4 in this case). In this example, the AP sends another TF 332 to assign RUs to different STAs, and each STA transmits preambles 334, 338, 342 and 346, followed by data 336, 340, 344 and 348 in the assigned RUs, after which the AP responds with MU-BA 349.

[0113] Figure 33 shows an example embodiment 350 in which a non-AP STA requests a basic trigger frame from an AP, and the AP transmits one TF for multiple UL transmissions, and the TF sets the RU allocation for all UL transmissions. The TF may also be such that it allocates a given resource (all or a part of the available BW) for STA4's UL data transmission for a certain period of time. STA4 may use these RUs for the time indicated in the TF. This figure is shown by way of example and not by way of limitation.

[0114] As shown in the previous figure, assume that all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel together using backoffs 202, 204, 206, and 208, 210, and that STA4 obtains channel access (212), reserves a TXOP (213), transmits an RTF 272 for use of all RUs, receives a TF 274 from the AP, transmits a preamble 312 and data 314 using all RUs, and then receives an MU-BA 352. It can then be seen that STA4 receives an MU-BA 358 after transmitting a preamble 354, illustrated as spanning all RUs, and additional data, illustrated as data 356.

[0115] 4.6.2. TXOP Sharing Initiated by Non-AP STA This section provides several examples that illustrate how non-AP STAs can gain channel access and share their TXOPs within their BSS. The network topology for this example is shown in Figure 20, but in this case only transmissions on link 1 are considered.

[0116] FIG. 34 illustrates an example embodiment 370 in which a non-AP STA shares its TXOP within an associated BSS by sending an RTF frame to the AP.

[0117] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) are illustrated as contending for the channel using backoffs 202, 204, 206, 208 and 210, with STA4 winning channel access (212) and reserving a TXOP 213.

[0118] STA4 sends an RTF frame 371 to the AP to start TXOP sharing. This procedure is described in block 76 of FIG. 21. The format of the RTF frame will be described later in connection with FIG. 55. The AP can then perform an optional information gathering step 372, as described in blocks 94 and 96 of FIG. 22, to send BSRP trigger frames 374 to the relevant STAs, such as STA2-STA5, to gather their buffer statuses 376, 378, 380 and 382. The AP schedules transmissions in the TXOP according to the buffer statuses of the STAs, as described in 98 of FIG. 21. In this example, the AP sends a trigger frame (TF) 384 to start multi-user uplink transmission. STA2-STA5 transmit packets after receiving the TF from the AP. This procedure is described in 82 of FIG. 21. The figure shows the transmission of data 388, 392, 396 and 400 after preambles 386, 390, 394 and 398 in the respective RUs. The AP responds at the end of these transmissions with a MU-BA 402. It should be understood that the AP does not need to send a BSRP to collect the STA's buffer status if it already has the STA's recent buffer status.

[0119] FIG. 35 illustrates an example embodiment 390 in which a non-AP STA first sends an RTS / CTS to reserve a TXOP, and then shares its TXOP within the associated BSS.

[0120] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) are illustrated as competing together for the channel using backoffs 202, 204, 206, 208 and 210.

[0121] STA4 acquires channel access rights (392) and obtains a TXOP 393. Next, STA4 transmits an RTS frame 394 to the AP, and in response receives a CTS frame 396 from the AP to reserve a TXOP period 393. After reserving the TXOP, STA4 can share its TXOP in the BSS by transmitting a frame such as RTF 398 as shown. Next, the AP arranges for transmission during the shared TXOP as described in FIG. 34. Note that if the AP already has the buffer status of the STA, it does not need to transmit a BSRP to collect the buffer status of the STA.

[0122] The remainder of the figure shows the same collection of buffer status and initiation of multi-user uplink transmission as shown in the previous figure.

[0123] FIG. 36 illustrates an example embodiment 410 in which a non-AP STA shares its TXOP within an associated BSS by sending a MU-BSR frame to the AP.

[0124] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0125] STA2 and STA4 simultaneously acquire channel access rights (412) to share TXOP (414). STA2 and STA4 send MU-BSR packets to the AP in preambles 416 and 420, respectively, to initiate TXOP sharing. This procedure is described in block 76 of Figure 21, and the MU-BSR preamble is described in Figure 58. Within the preamble is a TXOP sharing indication, such as a 1-bit sharing field, that indicates that this MU-BSR is to initiate TXOP sharing.

[0126] Negotiation between the AP and the STAs can also prefix the RU allocation in the MU-BSR for carrying the BSR frame. Therefore, there is no need to indicate the RU allocation of the BSR frame in the preamble. For example, the MU-BSR for TXOP sharing initiation transmitted over the 20 MHz band can use a random 26-tone resource unit (RU) to carry the BSR frame. As shown in this example, STA2 uses RUy 418 and STA4 uses RUx 422 to carry their respective BSR frames to the AP STA1.

[0127] The advantage of using MU-BSR is that when multiple STAs, such as STA2 and STA4 shown in the figure, gain channel access at the same time, the AP can receive these MU-BSR packets without error because the preamble contents of these STAs are prefixed with the same (overlapping) information. Also, the BSR frames are transmitted by different RUs, so the AP can decode all possible RUs, such as RUx and RUy, to receive the BSR frames. The BSR frames can be carried in the same PPDU format, with the same packet length, the same bit rate (e.g., 6 Mb / s rate), and with the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value.

[0128] As described in blocks 78 and 80 of FIG. 21, if the non-AP STA receives a trigger frame (TF) from the AP before the timeout, the TXOP sharing is successful. In this example, the AP sends a trigger frame (TF) 424 to start multi-user uplink transmission according to the buffer status of STA2 and STA4. After receiving the TF from the AP, STA2 and STA4 send their preambles 426 and 430, and packets 428 and 432. This procedure is described in block 82 of FIG. 21. After the packet transmission, the AP sends a MU-BA 434 to acknowledge the packet reception.

[0129] Note that FIG. 36 merely illustrates an example in which multiple STAs simultaneously acquire channel access rights, and it is also possible for only one STA to acquire channel access rights and transmit a MU-BSR frame.

[0130] FIG. 37 illustrates an example embodiment 450 in which a non-AP STA shares its TXOP within an associated BSS by sending a MU-BSR packet to the AP.

[0131] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0132] In this example, STA2 and STA4 also simultaneously acquire channel access rights for TXOP sharing 454 and transmit preambles 456 and 460 to AP STA1. However, in this example, these two STAs use the same RU to convey BSR frames 458 and 462 in MU-BSR packets to the AP to initiate TXOP sharing. This procedure is described in Figure 21 at 76, and the MU-BSR preamble is described in Figure 58. In the preamble, there is a 1-bit TXOP sharing indication that indicates this MU-BSR is for initiating TXOP sharing.

[0133] Negotiation between the AP and the STAs can also prefix the RU allocation in the MU-BSR for carrying the BSR frame. Therefore, there is no need to indicate the resource unit (RU) allocation for the BSR frame in the preamble. For example, the MU-BSR for TXOP sharing initiation transmitted over the 20 MHz band can carry the BSR frame using a random 26-tone RU as defined in IEEE 802.11ax. As shown in this example, both STAs use RUx to carry the BSR frame. The BSR frame can be carried in the same PPDU format with the same packet length, the same bit rate (e.g., 6 Mb / s rate), and with the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value as that set in the negotiation.

[0134] The advantage of using MU-BSR is that when multiple STAs, such as STA3 and STA4 shown in the figure, gain channel access rights at the same time, the AP can receive the preambles of these MU-BSR packets without error. This is because the contents of the preambles of these STAs are prefixed with an overlapping set of information. Thus, although the BSR frames of STA2 and STA4 collide because they are carried by the same RU (i.e., RUx), the AP can still successfully decode the preamble and decide to start TXOP sharing. Next, in this figure, the AP sends a BSRP 464 to collect BSRs 466, 468, 470, and 472 from the STAs by sending a BSRP trigger frame to arrange for transmission during the TXOP.

[0135] In this example, the AP sends TF 474 to initiate multi-user UL transmission after collecting BSRs and buffer status information from the STAs. It can be seen that the STAs send preambles 476, 480, 484 and 486, then send data 478, 482, 486, 488 to the AP STA1 via different RUs, after which the AP responds with MU-BA 490.

[0136] Therefore, although FIG. 37 mainly shows multiple STAs acquiring channel access rights simultaneously, it is also possible for only one STA to acquire channel access rights and transmit a MU-BSR.

[0137] FIG. 38 illustrates an example embodiment 510 in which a non-AP STA shares its TXOP within an associated BSS by sending a CTS frame to the AP.

[0138] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0139] STA3 and STA4 simultaneously gain channel access 512 for a TXOP 514 and both send CTS frames 516 and 518 to the AP to start sharing the TXOP (514). This procedure is described above in block 76 of FIG. 21. When the STAs send the CTS frames, they can set the RA field of the CTS frames to the same specific address prefixed with overlapping information and negotiated with the AP to indicate the start of TXOP sharing. These CTS frames can also be carried in the same PPDU format (e.g., non-HT or non-HT overlapping PPDU) with a fixed rate (e.g., 6 Mb / s rate) and with the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value.

[0140] The advantage of using a CTS frame is that when multiple STAs, such as STA3 and STA4 shown in the figure, simultaneously gain channel access, the CTS frame contents are identical so that the AP can receive the CTS frame without error, since their preamble contents are prefixed to include the overlapping information contained in the CTS frame.

[0141] When the AP receives the CTS indicating the start of TXOP sharing, it can determine that one STA will acquire the TXOP and share the TXOP in the BSS. The AP is illustrated as optionally collecting the buffer status 520 by sending a BSRP trigger frame 522, and collecting BSRs 524, 526, 528 and 530 to arrange the transmission during the TXOP. In this example, the AP sends TF 532 to start the multi-user UL transmission after collecting the buffer information, and the STAs send preambles 534, 538, 542 and 546 on different RUs before sending data 536, 540, 544 and 548 to the AP STA1, which receives the data and sends MU-BA 549 to acknowledge these transmissions.

[0142] Although FIG. 38 shows only an example in which multiple STAs simultaneously obtain channel access rights, it is also possible for only one STA to obtain channel access rights and transmit a CTS frame.

[0143] FIG. 39 illustrates an example embodiment 550 in which a non-AP STA shares its TXOP within an associated BSS by sending a BSR frame to the AP.

[0144] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0145] STA4 acquires channel access rights (552) and transmits a BSR frame 556 to the AP to start sharing the TXOP 554. This procedure is described above in block 76 of FIG. 21. When the STA transmits the BSR frame, it can set the RA field of the BSR frame to a specific address that is prefixed and negotiated with the AP to indicate the start of TXOP sharing. When the AP receives this BSR frame from STA4 indicating the start of TXOP sharing, it can determine which STAs will get the TXOP to share in the BSS.

[0146] Here, it can be seen that the AP optionally collects buffer status information 558 from other STAs. The AP transmits a BSRP trigger frame 560 to STA2, STA3, and STA5, which respond with BSRs 562, 564, and 566. The AP can then optionally collect BSRs from other STAs by transmitting a BSRP trigger frame and arrange for transmission during the TXOP.

[0147] After collecting the BSRs from the STAs, the AP sends a TF 568 to initiate a multi-user UL transmission, which transmits data 572, 576, 580, and 584 to the AP STA1 after preambles 570, 574, 578, and 582, and acknowledges the transmission with the MU-BA 586 upon receipt of the data. The STAs then transmit their packets through the RUs assigned by the P2P TF. As shown, the UL OFDMA transmissions of STA2 572 and STA3 576 are transmitted through RU1 and RU2, respectively, and the P2P transmission of STA4 is transmitted to STA1 through RU3 (578).

[0148] Enabling P2P Sending This section provides several examples that illustrate how a non-AP STA can share its TXOP in a BSS and initiate a peer-to-peer (P2P) transmission during the shared TXOP. The network topology for these examples is shown in Figure 20, although in this example only transmissions on link 1 are considered.

[0149] FIG. 40 illustrates an example embodiment 590 in which a non-AP STA initiates a P2P transmission by sending an RTF frame.

[0150] As illustrated in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel together using backoffs 202, 204, 206, 208, and 210, and STA4 obtains channel access for TXOP 594 (592).

[0151] Once STA4 has acquired channel access rights, it requests a P2P trigger frame from the AP by transmitting an RTF frame 596. The AP then transmits a P2P trigger frame 598 to initiate a P2P transmission 600 from STA4 to STA5.

[0152] In this example, the TXOP sharing indication included in the RTF 596 is set to a first state (e.g., "0") indicating that STA4 does not want to share the TXOP within the BSS. After the P2P transmission is finished and STA5 acknowledges the transmission with BA 602, STA4 arranges to transmit on its own, sending another data frame 604, which in this example is sent to the AP, which the AP acknowledges with BA 606.

[0153] FIG. 41 illustrates an example embodiment 610 in which a non-AP STA initiates a P2P transmission by sending an RTF frame.

[0154] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel using backoffs 202, 204, 206, 208 and 210, and STA4 wins channel access (612).

[0155] When STA4 obtains channel access rights for TXOP 614 (612), it sends an RTF frame 616 to request a P2P trigger frame from the AP. In response to the RTF, the AP sends a P2P trigger frame 618 to initiate a P2P transmission 620 from STA4 to STA5, which STA5 acknowledges with a BA 622. In this example, the TXOP sharing indication in the RTF is set to a second state (e.g., "1") indicating that STA4 is sharing the TXOP in the BSS.

[0156] After the P2P transmission is finished, the AP continues to arrange the transmission in the TXOP and transmits TF 624 to initiate multi-user uplink transmissions by other stations, and data 628, 632, 636 and 640 are transmitted to STA1 on different RUs after preambles 626, 630, 634 and 638, and the AP issues an acknowledgement in BA 642 after receiving these transmissions.

[0157] FIG. 42 illustrates an example embodiment 650 in which a non-AP STA shares its TXOP in an associated BSS and requests P2P transmission by sending a P2P-BSR frame in the shared TXOP.

[0158] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0159] STA4 acquires channel access rights (652) and transmits a P2P-BSR frame 656 to the AP to initiate sharing of the TXOP 654. The format of the P2P-BSR frame is described below in Figure 49, and the P2P-BSR procedure is described in block 76 of Figure 21. When the STA transmits the P2P-BSR frame, it may set the RA field of the frame to a specific address negotiated with the AP, prefixed to indicate the start of TXOP sharing.

[0160] When the AP receives a P2P-BSR frame indicating the start of TXOP sharing, it determines TXOP sharing from this frame. In this example, the STA requests to share its TXOP in the BSS and requests P2P transmission during the sharing TXOP. Then, in this example, the AP collects buffer status information 658 from other STAs by optionally sending a BSRP trigger frame 660 to collect BSRs 662, 664, and 666, and arranges (orders / schedules) transmission during the TXOP at this point. As shown in this example, after collecting BSRs from the STAs, the AP sends a P2P TF 668 to start multi-user UL transmissions 670, 672, 674, 676 for STA2 and STA3, and P2P transmissions 678, 680 between STA4 and STA5.

[0161] The STAs transmit packets through RUs assigned by the P2P TF. As shown, UL OFDMA transmissions of STA2 and STA3 are transmitted through RU1 and RU2, respectively. P2P transmissions of STA4 are transmitted to STA5 through RU3. It can then be seen that the AP transmits preamble 682, and BAs 684 and 686, and STA5 transmits preambles 688 and BAs 689.

[0162] FIG. 43 illustrates an example embodiment 690 in which a non-AP STA shares its TXOP in an associated BSS and requests a P2P transmission by sending a MU-BSR packet in the shared TXOP.

[0163] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) compete together for the channel using backoffs 202, 204, 206, 208 and 210.

[0164] In this example, STA2 and STA4 simultaneously acquire channel access rights (692). Then, both STA2 and STA4 start using TXOP (694) by sending preambles 696 and 700 and MU-BSR packets 698 and 702 to the AP to initiate TXOP sharing. This procedure is described in FIG. 21 at 76. The MU-BSR preamble is described in FIG. 58. Within the preamble, there is a TXOP sharing indication (e.g., 1 bit) that indicates that this MU-BSR is for initiating TXOP sharing.

[0165] The RU allocation in the MU-BSR carrying the BSR frame can be prefixed by negotiation between the AP and the STA. Therefore, there is no need to indicate the RU allocation of the BSR in the preamble. For example, the MU-BSR to initiate TXOP sharing transmitted over the 20 MHz band can transmit the BSR frame using a random 26-tone resource unit (RU). As shown in this example, STA2 carries the BSR frame to the AP using RUy, and STA4 carries the P2P-BSR frame to the peer station at STA5 using RUx.

[0166] The advantage of using MU-BSR is that when multiple STAs, such as STA2 and STA4 shown in the figure, simultaneously gain channel access, the AP can receive these MU-BSR packets without error because the preamble contents are prefixed to contain the same shared information, and the BSR frames are carried on different RUs.

[0167] The type of BSR frame carried by the RU can be determined by the STA. As shown, STA2 transmits a BSR frame defined in IEEE 802.11ax through RUy, and STA4 transmits a P2P BSR frame through RUx. The AP can decode different types of BSR frames through RUs with different prefixes.

[0168] As described in 78 and 80 of FIG. 21, if the non-AP STA receives the trigger frame from the AP before the timeout, the TXOP sharing is successful. In this example, the AP sends a P2P TF 704 to initiate uplink OFDMA transmission 706, 708 via RU1 according to the buffer status of STA2, and initiates P2P transmission 710, 712 between STA4 and STA5 via RU3 according to the buffer status of STA4. STA2 and STA4 transmit their packets after receiving the P2P-TF from the AP. This procedure is described in block 82 of FIG. 21. After that, it can be seen that the AP sends a BA transmission 716 including a preamble 714 to STA2 via RU1, and STA5 sends a BA transmission 720 including a preamble 718 to STA4.

[0169] FIG. 44 illustrates an example embodiment 730 in which a non-AP STA shares its TXOP in an associated BSS and requests a P2P transmission by sending a MU-BSR packet in the shared TXOP.

[0170] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) are illustrated as competing together for the channel using backoffs 202, 204, 206, 208 and 210.

[0171] In this example, STA3 and STA4 simultaneously acquire channel access rights (732). Next, STA3 and STA4 send MU-BSR packets 738 and 742, including preambles 736 and 740, to the AP to initiate sharing of TXOP 734. This procedure is described in FIG. 21 at 76. Preambles such as those used in MU-BSR 736 and 740 are described in FIG. 58. Within the preamble, there is a 1-bit TXOP sharing indication, which indicates that this MU-BSR is to initiate TXOP sharing.

[0172] The RU allocation in the MU-BSR carrying the BSR frame can be prefixed by negotiation between the AP and the STA. Therefore, there is no need to indicate the resource unit (RU) allocation of the BSR in the preamble. For example, the MU-BSR to initiate TXOP sharing transmitted over the 20 MHz band can transmit the BSR frame using the random 26-tone RU defined in IEEE 802.11ax. As shown in this example, STA3 and STA4 use RUx738 and 742 to carry the BSR frame.

[0173] The advantage of using MU-BSR is that when multiple STAs, such as STA3 and STA4 shown in the figure, simultaneously gain channel access rights, the AP can receive the preambles 736 and 740 of their MU-BSR packets without error because the contents of their preambles provide prefixes with the same information. Although the BSR frames of STA2 and STA4 collide because they are carried by the same RU, i.e., RUx, the AP can still successfully decode the preambles and thus notice the start of TXOP sharing.

[0174] Next, in this example, the AP collects the BSR from the STA by sending a BSRP trigger frame 744 to arrange for transmission during the TXOP. As described in Figure 26, the STA can determine what type of BSR frame to send back. In the illustrated example, STA2 and STA5 send BSR frames 746 and 752 defined in IEEE 802.11ax, STA3 sends an RTA-BSR frame 748, and STA4 sends a P2P BSR frame 750. The formats of the RTA-BSR frame and the P2P-BSR frame are shown in Figure 49.

[0175] As described in Fig. 25, the AP collects buffer status from the STAs even if the type of BSR frame is different. The AP transmits a P2P TF frame 754 to initiate multi-user transmissions including UL transmissions 756, 758, 760, 762 for STA2 and STA3, and P2P transmissions 764, 766, 774, 776 between STA4 and STA5 according to the BSR. The allocation of RUs is indicated by the P2P TF. The UL transmissions are transmitted using RU1 and RU2, and the P2P transmissions are transmitted using RU3. It can also be seen that the AP transmits block acknowledgements (BAs) 770 and 772 including the preamble 768 to STA2 and STA3, respectively, and STA5 transmits a BA 776 including the preamble 774 to STA4.

[0176] FIG. 45 illustrates an example embodiment 790 in which a non-AP STA shares its TXOP in an associated BSS and requests a P2P transmission by sending a CTS frame in the shared TXOP.

[0177] As shown in the previous figure, the STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel using backoffs 202, 204, 206, 208, and 210.

[0178] STA3 and STA4 simultaneously acquire channel access rights (792). Then, STA3 and STA4 send CTS frames 796 and 798 to the AP to start sharing the TXOP (794). This procedure is described in block 76 of Figure 21. Because the contents of the CTS frames are the same, the AP can still successfully decode the CTS.

[0179] Next, the AP can collect BSR from the STA by transmitting a BSRP trigger frame 800, and arrange transmission for TXOP after collecting BSR 802, 804, 806, and 808. As described in FIG. 26, the STA can determine which type of BSR frame should be returned. In this example, STA2 and STA5 transmit BSR frames 802 and 808 defined in IEEE 802.11ax. STA3 transmits an RTA-BSR frame 804, and STA4 transmits a P2P-BSR frame 806. The formats of the RTA-BSR frame and the P2P-BSR frame are shown in FIG. 49.

[0180] As described in Fig. 25, although the type of BSR frame is different, the AP collects buffer status from the STAs. The AP arranges transmission in the shared TXOP according to the BSR. The AP transmits a P2P TF frame 810 to start a multi-user transmission, including UL transmissions 814, 818 with preambles 812, 816 for STA2 and STA3, and a P2P transmission 822 with preamble 820 from STA4 to STA5. The allocation of RUs is indicated by the P2P TF. The UL transmission is transmitted using RU1 and RU2, and the P2P transmission is transmitted through RU3. Then, a block acknowledgement 826, 828 is transmitted from the AP to STA2 and STA3, respectively, after the preamble 824, and a BA 832 is transmitted from STA5 to STA4 after the preamble 830.

[0181] 46A-B show an example embodiment 850 in which a non-AP STA shares its TXOP in an associated BSS and requests a P2P transmission by sending a CTS frame in the shared TXOP. This example describes how an AP arranges for transmission in the shared TXOP.

[0182] As shown in the previous figure, the STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) are contending for the channel using backoffs 202, 204, 206, 208, and 210.

[0183] In Figure 46A, it can be seen that STA4 acquires channel access rights (852) and sends an RTF frame 856 to the AP to request a P2P trigger frame and initiate a shared TXOP 854. This procedure is described in Figure 23, block 116.

[0184] As described in block 134 of FIG. 24, the AP transmits a P2P TF frame 858 to initiate a P2P transmission 860 from STA4 to STA5, to which STA5 responds with a BA 862.

[0185] Since the TXOP is shared by STA4, the AP starts downlink multi-user transmissions 866, 868 and 870 after the preamble 864 for STA2, STA3 and STA5 after the end of the P2P transmission, as described in block 138 of Figure 24. This can happen for different reasons, such as the expiration time of the downlink transmissions is shorter than the UL transmission of the RTA packets requested by the STAs.

[0186] Figure 46B illustrates at least one embodiment where the buffer status is embedded in the BA frame. It can be seen that STA2 and STA3 transmit BA frames 874, 878 to the AP after preambles 872, 876. The figure illustrates an example where P2P-BSR is embedded in a BA frame 882 after a preamble 880. The format of the BA+P2P-BSR frame is described in Figure 50. In at least one embodiment, the P2P-BSR in the BA+P2P-BSR frame is replaced with any type of BSR frame, such as RTA-BSR and BSR as defined in IEEE 802.11ax.

[0187] Since the P2P transmission expiration is the shortest, the AP schedules another P2P transmission between STA4 and STA5 according to the latest buffer status update from STA5. After the P2P transmissions of STA5 and STA4 are finished, the AP sends a TF frame 884 to start uplink multi-user transmission 886 of the buffers reported by the RTA-BSR frames of STA2, STA3 and STA5. Then, STA4 responds with BA 888. The AP sends a TF 890 before the end of the TXOP, and it can be seen that STA2, STA3 and STA5 are uploading data 894, 898 and 902 after the preambles 892, 896 and 900. Then, the AP responds with MU-BA 904. The AP can send a CF-End frame 906 as defined in IEEE 802.11 to end the current TXOP.

[0188] 6.6.4. AP Sharing TXOP Example In this section, we provide examples showing that APs can also collect buffer status information as described in Figure 25 in order to arrange transmissions in their own TXOPs. The network topology for these examples is shown in Figure 20, however, in this example we only consider transmissions on link 1.

[0189] 47A-47C show an example embodiment 910 in which an AP arranges transmissions in TXOPs it owns according to buffer status collected from STAs.

[0190] As shown in the previous figure, the STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend together for the channel using backoffs 202, 204, 206, 208, and 210.

[0191] As shown, the AP acquires channel access rights for a TXOP 914 (912) and transmits a BSRP 916 to collect BSRs from the STAs. As described in Figure 26, the STAs can determine what type of BSR frame they should send back. In this example, STA2, STA3, and STA5 transmit BSR frames 918, 920, and 924, and STA4 transmits a P2P BSR frame 922.

[0192] As explained in Fig. 25, the AP collects buffer status from the STAs even if the type of BSR frame is different. The AP arranges to transmit TXOP according to the BSR. In the execution of P2P transmission 927, the AP first transmits a P2P TF frame 926 to initiate a P2P transmission 928 from STA4 to STA5, to which STA5 responds with a BA 930. Since the P2P transmission has the shortest expiration time according to the BSR from the STA, it is preferable that the P2P transmission is performed first. Next, the AP initiates an MU DL 933, and transmissions 934, 936 and 938 for STA2, STA3 and STA5 are performed after the preamble 932. This is because the expiration time of the downlink transmission is shorter than the expiration time of the UL transmission of the RTA packet requested by the STA. Then, these stations respond with BA 942, 946 and 950 after the relevant preambles 940, 944 and 948.

[0193] Referring to FIG. 47B, the AP transmits a TF frame 952 to initiate uplink multi-user transmission 951 of the buffers reported by the BSR frames of STA2, STA3, and STA5 after the multi-user downlink transmission is finished. In at least one embodiment, the buffer status is embedded in the data frame. Data uploads 956, 960, and 964 from STA2, STA3, and STA5 to the AP, as well as preceding preambles 954, 958, and 962, are seen. Also shown in this figure is an example of a P2P-BSR 964 embedded in the data frame of STA5 and transmitted through RU3. The format of the data+P2P-BSR frame is described in FIG. 51. In at least one embodiment, the P2P-BSR in the BA+P2P-BSR frame is replaced with any type of BSR frame, such as RTA-BSR and BSR as defined in IEEE 802.11ax. The AP responds to their reception by transmitting a MU BA 966.

[0194] Since the P2P transmission 980 with preamble 978 from STA5 to STA4 has the shortest expiration time, the AP schedules a multi-user transmission (uplink+P2P) 967 including this P2P transmission according to the latest buffer status update from STA5. In this case, the AP sends a P2P TF 968 to arrange a multi-use transmission for both uplink and P2P transmissions. It can be seen that the uplink transmissions 972 and 976 of STA2 and STA3 use RU1 and RU2 and are accompanied by preambles 970 and 974. The P2P transmission 980 from STA5 to STA4 uses RU3 and is preceded by a preamble 978. The AP sends BA 984 and 986 after preamble 982 in response to STA2 and STA3. It can also be seen that STA4 sends BA 990 to STA5 after preamble 988.

[0195] Proceeding to FIG. 47C, it can be seen that the AP transmits another P2P TF 992 to arrange for another multi-user transmission 991 for both downlink and P2P transmissions.

[0196] It can be seen that STA5 is transmitting a preamble 1000 and data 1002 to STA4 via RU3.

[0197] It can be seen that the AP is transmitting preamble 994 and data over RU1 and RU2 for downlink transmissions 996 and 998 from the AP to STA2 and STA3, respectively. RU3 is used for P2P transmission. It should be understood that the AP can have an AID that points to itself. Using this AID, the AP can set the AID12 field to indicate that the channel resources indicated in the corresponding user information field of the P2P trigger frame will be used for downlink transmission. The P2P receiver ID in this user information field indicates the receiver of the downlink transmission. In the case where multi-user downlink transmissions and P2P transmissions coexist, each STA can only play one of the following roles: (a) sender of P2P transmissions, (b) receiver of P2P transmissions, (c) receiver of downlink transmissions, or (c) the AP can send a CF-End frame as defined in IEEE 802.11 to end the current TXOP. The diagram concludes with block acknowledgements (BA) 1004, 1006, 1008 and 1010 being sent from STA2 and STA3 to the AP, and 1012 and 1014 being sent from STA4 to STA5.

[0198] It should be understood that the transmission arrangement shown in this example can also be used during a TXOP shared by non-AP STAs. The number and order of different transmissions (e.g., P2P transmissions only, multi-user downlink transmissions, multi-user uplink transmissions, multi-user transmissions (uplink+P2P), multi-user transmissions (downlink+P2P)) can be determined by the AP.

[0199] 4.6.5. Example of non-AP MLD sharing TXOP in multi-link scenario This section provides examples showing (a) how a non-AP MLD shares a TXOP within a BSS on one link, and (b) how an AP MLD collects buffer status on one link and arranges transmission on multiple links as described in Figure 25. The network topologies for these examples are shown in Figure 20. The TXOP sharing on link 1 and the packet transmission arranged by STA1 (AP) during the shared TXOP on link 1 can be similar to those shown in Figures 46A and 46B.

[0200] Figures 48A-48B show an example embodiment 1030 in which an AP MLD capable of simultaneous transmission and reception (STR) communicates with a non-AP MLD that can be non-STR. Note that the communication shown in the markings of Figure 48B occurs simultaneously (not sequentially) with the communication shown in the markings of Figure 48A. The markings are the parts associated with the illustrated connection structure "DD".

[0201] As shown in the previous figures, region 1032 of Figure 48A shows all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contending for the channel together using backoffs 202, 204, 206, 208, and 210. Region 1076 of Figure 48B shows corresponding communication lines 192', 194', 196', 198', and 200' for STAs STA1' through STA5'.

[0202] STA4 acquires channel access right 1033 and transmits CTS 1036 to the AP for TXOP 1034 .

[0203] STA1 collects buffer status on link 1 by sending a BSRP 1038, and receives various BSR responses 1040, 1042, 1044, and 1046. This buffer status information can also be used to arrange transmissions on link 2, which will be described later.

[0204] The AP transmits a P2P TF 1048, and a P2P transmission 1050 from STA4 to STA5 with a corresponding BA 1052 is performed.

[0205] Now, referring to the parallel portions of Figures 48A and 48B, when STA1 receives RTA-BSRs 1040, 1042, 1046 and P2P-BSR 1044 after sending a BSRP trigger frame on link 1, it can also notify STA1' (see topology in Figure 20) on link 2 to update the buffer status of the associated STAs.

[0206] Because non-AP MLD is non-STR, STAs such as STA2'-STA5' cannot sense channels on link 2 and contend for those channels during the TXOP on link 1, as shown in Figure 48B. Therefore, STA1' initiates a backoff 1078, which is seen to be interrupted by a CCA busy.

[0207] However, STA1' then acquires channel access rights on link 2 (1081). Once STA1' acquires channel access rights on link 2, it can transmit a CTS frame 1080 to obtain and reserve a TXOP 1079 on link 2. Within the CTS frame, a padding field 1082 can be added to align PPDU transmissions (e.g., TF, multi-user UL transmissions, MU-BA, P2P TF and P2P transmissions) on link 1 and link 2. That is, the PPDU transmissions on both links are either downlink transmissions, uplink transmissions or P2P transmissions.

[0208] As shown, after STA1' reserves a TXOP on link 2 using a CTS+padding frame, both STA1 and STA1' transmit TF frames 1054, 1084 on both links to initiate multi-user uplink transmissions 1056, 1058, 1060, 1062, 1064, 1066, 1086, 1088, 1090, 1092, 1094 and 1096.

[0209] In at least one embodiment, the multi-user uplink data packet may include a BSR. For example, as shown, STA5 embeds a P2P-BSR 1066 in its multi-user uplink data packet. STA5's new buffer status is reported to STA1, which shares this information with STA1'. STA1 and STA1' then acknowledge the transmission with MU BAs 1068 and 1098. After this, both STA1 and STA1' schedule P2P transmissions simultaneously on both links by sending P2P TFs 1070 and 1100, and know that associated transmissions from STA5 to STA4 and STA5' to STA4', as well as associated BAs 1074 and 1104, are to occur.

[0210] It should be understood that PPDU alignment is optional. In particular, PPDU alignment is not required when the non-AP MLD is in STR.

[0211] Frame Format FIG. 49 illustrates an example embodiment 1150 of a BSR frame defined in IEEE 802.11ax, any type of BSR frame including P2P-BSR and RTA-BSR.

[0212] The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. If the BSR frame is used to indicate the start of TXOP sharing, the non-AP STA (sender) can set the RA to a specific address that is prefixed and negotiated with the AP. The AP (receiver) can recognize this special address as this frame is for TXOP sharing. The TA field contains the address of the STA that sent the frame.

[0213] The HT control field indicates a BSR control subfield variant. The format of the BSR control subfield variant is described in Figure 52. The non-AP STA (sender) sets this field to indicate the type of BSR and the corresponding buffer status of the non-AP STA. Thus, the AP receiving this frame can determine the current buffer status of the non-AP STA and the QoS requirements of the buffer. The AP can schedule transmissions to meet the QoS requirements of the buffer. Here and in some other data formats, we see a Frame Check Sequence (FCS) as an error detection code added to frames in communication protocols.

[0214] 50 illustrates an example embodiment 1170 of a BA+BSR frame format. The BSR can be of any type, including the BSR frame defined in IEEE 802.11ax, P2P-BSR, and RTA-BSR.

[0215] The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. If the BSR frame is used to indicate the start of TXOP sharing, the non-AP STA (sender) can set the RA to a specific address that is prefixed and negotiated with the AP. The AP (receiver) can recognize this special address as this frame is for TXOP sharing. The TA field contains the address of the STA that sent the frame.

[0216] The HT control field indicates the BSR control subfield variant. The format of the BSR control subfield variant is described in Figure 52. The non-AP STA (sender) sets this field to indicate the type of BSR and the corresponding buffer status of the non-AP STA. Thus, the AP receiving this frame can obtain information about the current buffer status and the QoS requirements of the buffer of the non-AP STA. The AP can schedule transmission to meet the QoS requirements of the buffer. The BA Control field indicates the Block ACK policy. The BA Control field contains feedback for the transmission.

[0217] 51 illustrates an example embodiment 1190 of a Data+BSR frame format. The BSR can be of any type, including the BSR frame defined in IEEE 802.11ax, P2P-BSR, and RTA-BSR.

[0218] The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. If the BSR frame is used to indicate the start of TXOP sharing, the non-AP STA (sender) can set the RA to a specific address that is prefixed and negotiated with the AP. The AP (receiver) can recognize this special address as this frame is for TXOP sharing. The TA field contains the address of the STA that sent the frame. The Sequence control field contains the fragment number and sequence number of the packet.

[0219] The HT control field indicates the BSR control subfield variant. The format of the BSR control subfield variant is described in Figure 52. The non-AP STA (sender) sets this field to indicate the type of BSR and the corresponding buffer status of the non-AP STA. Thus, the AP receiving this frame can obtain information about the current buffer status of the non-AP STA and the QoS requirements of the buffer. The AP can schedule transmissions to meet the QoS requirements of the buffer.

[0220] The Data field carries the payload of the data frame.

[0221] Figure 52 shows an example embodiment 1210 of the format of the BSR control subfield variant. The Format indication field is used to indicate the format of the HT control field. When bits B0 and B1 are set to a first state (e.g., 1), it indicates that the HT control field uses the HE / EHT format. This field is followed by the A-Control field, which is used to carry different types of buffer status reports.

[0222] The Control ID is a field indicating the type of BSR carried in the control information field. The Control Information field carries the BSR control subfield variants, such as the BSR control subfield defined in IEEE 802.11ax, the RTA-BSR shown in Figure 53, and the P2P-BSR shown in Figure 54. The sender sets this field to report the buffer status and the QoS requirements of the buffer to the receiver. The receiver can schedule transmission according to the BSR to meet its QoS requirements.

[0223] Figure 53 shows an example embodiment 1230 of the format of the RTA-BSR control subfield in the A control subfield. The RTA ID field indicates the identity of the RTA buffer reported in this BSR. The receiver can use the TA ID to identify the RTA traffic so that the QoS requirements of the RTA traffic are known. As an example and not a limitation, assume that both the AP and the STA have a list of traffic specifications (such as AC, TID, priority and traffic rate) and QoS requirements (such as delay, jitter and packet loss) for the RTA traffic. Each QoS requirement of the RTA traffic under the same traffic specification is linked to an RTA ID.

[0224] The Scaling Factor field indicates the units of the Expiration Queue Size and the RTA Queue Size. The encoding of this field can be the same as that of IEEE 802.11ax. The Expiration Queue Size field indicates the amount of buffered RTA traffic that expires at the expiration time in units of the Scaling Factor. The Expiration Time field indicates the expiration time of the buffered RTA traffic indicated in the Expiration Queue Size. The RTA Queue Size field indicates the total amount of buffered RTA traffic in units of the Scaling Factor.

[0225] When the AP receives this control subfield, it should terminate the transmission of the buffered RTA traffic indicated in the expiry queue size before the expiry date in order to meet the QoS requirements of the buffered traffic indicated in the control subfield. The AP can also process the buffered RTA traffic indicated in the RTA queue size.

[0226] It should be understood that the number of bits below each field as shown in Figure 53 represents an example length of each field, and in at least one embodiment, the length of each field differs from that shown.

[0227] FIG. 54 illustrates an example embodiment 1250 of the format of the P2P-BSR control subfield in the A-control subfield. The ACI P2P field indicates the access category of the P2P buffer reported in this BSR. The Scaling Factor field indicates the units of the queue size P2P, and the encoding of this field can be the same as that of IEEE 802.11ax. The Queue Size P2P field indicates the amount of buffered P2P traffic that expires at the expiration time in units of the Scaling Factor. The Expiration Time field indicates the expiration time of the buffered P2P traffic indicated in the Queue Size P2P. The P2P receiver ID field indicates the receiver of the P2P traffic indicated in the Queue Size P2P. Upon receiving this field, the AP can recognize the receiver of the P2P traffic. When an AP schedules a multi-user transmission such as the example in Section 4.6.3, the receiver of the P2P traffic must not simultaneously be the sender of a UL transmission or the receiver of a DL transmission. Upon receiving this control subfield, the AP SHOULD schedule the transmission of the buffered P2P traffic indicated in Queue Size P2P before the expiration time in order to meet the QoS requirements of the buffered traffic indicated in the control subfield.

[0228] It should be understood that while the example number of bits shown below each field in FIG. 54 represents an example length of each field, in at least one embodiment the length of one or more of these fields may differ from that shown.

[0229] Figure 55 shows an example embodiment 1270 of the format of an RTF frame. The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. If the BSR frame is used to indicate the start of TXOP sharing, the non-AP STA (sender) can set the RA to a specific address that is prefixed and negotiated with the AP. The AP (receiver) can recognize this special address as this frame is for TXOP sharing. The TA field contains the address of the STA that sent the frame.

[0230] The HT control field indicates the BSR control subfield variant. The format of the BSR control subfield variant is described in Figure 52. The non-AP STA (sender) sets this field to indicate the type of BSR and the corresponding buffer status of the non-AP STA. Thus, the AP receiving this frame can know the current buffer status of the non-AP STA and the QoS requirements of the buffer. The AP can schedule transmissions to meet the QoS requirements of the buffer. In at least one embodiment, the HT control field carries other subfield variants defined in IEEE 802.11 that the receiver can use.

[0231] The TXOP sharing indication field indicates whether the RTF frame is used to initiate TXOP sharing. This field may be implemented as a one-bit indication. If the sender sets this bit to a first state (e.g., "1"), the RTF frame indicates the start of TXOP sharing. The receiver transmits the trigger frame requested in the trigger type field to initiate TXOP sharing. The receiver can arrange for subsequent transmissions in the shared TXOP. If the sender sets it to a second state (e.g., "0"), this frame is for a trigger frame request only. The receiver only needs to transmit the trigger frame requested by the sender.

[0232] The TXOP sharing period indicates the time of TXOP sharing. If the TXOP sharing indication is set to a first state (e.g., "1"), the receiver can arrange to transmit during the TXOP sharing period. If the TXOP sharing indication is set to a second state (e.g., "0"), this field is reserved.

[0233] The Trigger Type field indicates the type of trigger frame that the sender requests the receiver to send. The receiver sends a trigger frame of the type indicated in the Trigger Type field. For example, if this field is set to indicate a P2P trigger frame, the receiver sends a P2P trigger frame.

[0234] The Common Info field indicates the recommended parameter settings in the requested trigger frame. The format of the Common Info field is shown in Figure 9. The receiver may use the recommended parameters in this field to set the Common Info field of the corresponding TF. It should be understood that the receiver may not use the same parameter settings in the Common Info field.

[0235] The User info field indicates the recommended parameter settings in the requested trigger frame. The format of the User info field is shown in FIG. 10. The receiver may use the recommended parameters in this field to set any one of the user information fields of the corresponding TF. In at least one embodiment, a rule may be set that the receiver must use the recommended parameters in this field to set one of the user information fields of the corresponding TF. In at least one embodiment, a rule may be set that the receiver does not have to use the same parameter settings in the usage information field of the corresponding TF.

[0236] The Requested time field indicates the time that the STA requests to access the channel when it receives the TF from the AP. The STA calculates this time to meet the data transmission to the AP. Upon receiving this field, the AP transmits the TF to allocate resources for this STA for the requested time. If this field is available (not reserved), it is assumed that the user will use the frequency resources defined in the user field, or the requested frequency resources field if available (not reserved).

[0237] The Requested frequency resources field (if not reserved) indicates the amount of frequency resources (RUs or channels) that the STA requests to use after receiving the TF. The STA calculates the amount of resources to satisfy the data transmission to the AP. Upon receiving this field, the AP sends a TF to allocate the requested frequency resources to this STA. This field takes precedence over the information in the User field if available. This field is optional and is enabled by the Requested Frequency Resources field.

[0238] The requested frequency resources indication is preferably 1 bit indicating whether to use the user field or the requested frequency resources field to define the requested frequency resources. The STA sets this field to a first state (e.g., "1") if it is requesting resources through the configuration of the requested frequency resources field, and sets this field to 0 if it is requesting resources through the user field. When the AP receives this field, it reads the requested resources from the STA from either the requested frequency resources field or the user field. The AP should allocate resources to the STA in the TF according to the requested frequency resources.

[0239] Figure 56 shows an example embodiment 1290 of the format of a CTS frame for TXOP sharing. The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. If a BSR frame is used to indicate the start of TXOP sharing, the non-AP STA (sender) can set the RA to a specific address that is prefixed and negotiated with the AP. The AP (receiver) can recognize this special address as this frame is for TXOP sharing.

[0240] Figure 57 illustrates an example embodiment 1310 of the contents of a P2P trigger frame with the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the receiver of the frame. The TA field contains the address of the STA that sent the frame. The Common Info field contains information of all assigned STAs as shown in Figure 9.

[0241] The User Info field contains the information of each STA as shown in Figure 10. In particular, the Trigger dependent Common Info field in the User Info field carries the P2P receiver ID. The sender of the P2P-TF sets this field to indicate the receiver of the P2P transmission triggered by the P2P trigger frame.

[0242] If the recipient in the user information field is a non-AP and the P2P receiver ID indicates a non-AP, then the recipient in the user information field sends the packet to the recipient indicated by the P2P receiver ID.

[0243] If the recipient in the user information field is an AP and the P2P recipient ID represents a non-AP, the AP sends a downlink packet to the recipient indicated by the P2P recipient ID.

[0244] If the recipient of the user information field is a non-AP and the P2P recipient ID represents an AP, the recipient of the user information field sends an uplink packet to the AP.

[0245] The TF Validation field is set to indicate the time during which the TF can trigger multiple PPDUs using the channel resources allocated in the TF. The receiver receiving this field is triggered to transmit multiple PPDUs using the channel resources allocated in the TF. That is, one TF triggers multiple transmissions during the TF validation time. In at least one embodiment, this field is set to indicate the number of PPDUs this TF can trigger. The receiver receiving this field is triggered to transmit multiple PPDUs with the number indicated in the field. These PPDUs follow the channel resources allocated in the TF. It should be understood that this field can be used by any type of TF, examples of which are shown in Figures 29 and 57.

[0246] The common information field and the user information field provide individual resource block allocation information for each user.

[0247] It should be understood that the TF validation field can be a subfield within the common information field.

[0248] FIG. 58 illustrates an example embodiment 1330 of a typical IEEE 802.11be preamble format that may be used in accordance with the present disclosure for MU-BSR to indicate TXOP sharing, with the following fields: L-STF field indicates a non-HT short training field; L-LTF field indicates a non-HT long training field; L-SIG field indicates a non-HT SIGNAL field; RL-SIG field indicates a repeated non-HT SIGNAL field; U-SIG field indicates an EHT universal field; EHT-SIG field indicates an EHT SIGNAL field.

[0249] In the EHT-SIG field, a TXOP sharing indication field may be present. The TXOP sharing indication field indicates whether a preamble is used to initiate TXOP sharing. This field may contain a one-bit indication. For example, if the sender sets this bit to a first state (e.g., "1"), the preamble indicates the start of TXOP sharing and the receiver starts TXOP sharing. The receiver can arrange to transmit in a shared TXOP. If the sender sets this bit to a second state (e.g., "0"), this preamble is not for TXOP sharing.

[0250] The EHT-STF field indicates an EHT short-term training field. The EHT-LTF field indicates an EHT long-term training field.

[0251] 5. General scope of embodiments The described enhancements of the presented techniques may be readily implemented within various wireless network communication stations, and it should be appreciated that the wireless network communication stations are preferably implemented to include one or more computer processor devices (e.g., CPUs, microprocessors, microcontrollers, computer-enabled ASICs, etc.) and associated memory (e.g., RAM, DRAM, NVRAM, FLASH, computer readable media, etc.) for storing instructions, such that programs (instructions) stored in the memory are executed on the processor to perform the various process steps described herein.

[0252] Additionally, the computer readable media (memory that stores instructions) in these computer systems will be understood to be "non-transitory" and include any and all forms of computer readable media, with the only exception being a transitory propagating signal. Thus, the disclosed technology can include any form of computer readable media, including those that are randomly accessed (e.g., RAM), require periodic refreshing (e.g., DRAM), degrade over time (e.g., EEPROM, disk media), or store data only for a short period of time and / or only in the presence of power; the only restriction is that the term "computer readable media" does not apply to transitory electronic signals.

[0253] Embodiments of the present technology may be described herein with reference to flowcharts of methods and systems according to embodiments of the present technology, and / or procedures, algorithms, steps, operations, formulas, or other computational expressions, which may also be implemented as computer program products. In this regard, each block or step of the flowchart, and combinations of blocks (and / or steps) of the flowchart, and any procedures, algorithms, steps, operations, formulas, or computational expressions, may be implemented by various means, such as hardware, firmware, and / or software that includes one or more computer program instructions embodied in a computer readable program code. As will be appreciated, any such computer program instructions may be executed by one or more computer processors, including, but not limited to, a general purpose computer or a special purpose computer, or any other programmable processing device to produce a machine, such that the computer program instructions executing on the computer processor or other programmable processing device produce means for performing the specified function(s).

[0254] Thus, the blocks of the flowcharts and procedures, algorithms, steps, operations, formulas, or computational expressions described herein support combinations of means for performing a particular function(s), combinations of steps for performing a particular function(s), and computer program instructions for performing a particular function(s) as embodied in computer readable program code logic means. It will also be understood that each block of the flowcharts described herein and any procedures, algorithms, steps, operations, formulas, or computational expressions, and combinations thereof, can also be implemented by a dedicated hardware-based computer system that performs the particular function(s) or step(s), or a combination of dedicated hardware and computer readable program code.

[0255] Moreover, these computer program instructions, embodied in computer readable program code or the like, may be stored in one or more computer readable memories or memory devices capable of directing a computer processor or other programmable processing device to function in a particular manner, such that the instructions stored in these computer readable memories or memory devices produce an article of manufacture including instruction means for performing the functions specified in the flowchart(s). The computer program instructions may be executed by the computer processor or other programmable processing device to generate a computer-implemented process by causing a series of operational steps to be performed on the computer processor or other programmable processing device, such that the instructions executing on the computer processor or other programmable processing device provide steps for performing the function specified in the flowchart(s) block(s), procedure(s), algorithm(s), step(s), operation(s), mathematical formula(s), or computational expression(s).

[0256] Additionally, the terms "program" or "program executable" as used herein will be understood to mean one or more instructions executable by one or more computer processors to perform one or more functions described herein. The instructions may be embodied in software, firmware, or a combination of software and firmware. The instructions may be stored locally on a non-transitory medium of the device or remotely, such as on a server, or all or a portion of the instructions may be stored locally or remotely. Remotely stored instructions may be downloaded (pushed) to the device upon user initiation or automatically based on one or more factors.

[0257] Furthermore, as used herein, the terms processor, hardware processor, computer processor, central processing unit (CPU), and computer are used synonymously to indicate a device capable of executing instructions and communicating with input / output interfaces and / or peripheral devices, and it will be understood that the terms processor, hardware processor, computer processor, CPU, and computer are intended to include single or multiple devices, single-core devices and multi-core devices, and variations thereof.

[0258] From the description herein, it will be understood that the present disclosure includes multiple implementations, including but not limited to the following.

[0259] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station to wirelessly communicate with at least one other station on the network using carrier sense multiple access with collision avoidance (CSMA / CA); (b) a processor coupled to the station; and (c) a non-transitory memory storing instructions executable by the processor, the instructions, when executed by the processor, for (d) (i) receiving, at a station operating as an access point (AP), messaging from a non-access point (non-AP) station that has acquired a transmission opportunity (TXOP) informing an access point (AP) station about sharing the TXOP within a basic service set (BSS). (d)(ii) a station operating as an AP obtaining a buffer status and quality of service (QoS) requirements for the buffer associated with the at least one other station; and (d)(iii) the station operating as an AP, during a shared TXOP, acting as a TXOP owner on behalf of the non-AP station that obtained the TXOP, to satisfy the QoS requirements for the buffer reported by the at least one other station, wherein a TXOP obtained by a non-AP station is shared with other stations through use of an access point (AP) station of a BSS.

[0260] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on the network using carrier sense multiple access with collision avoidance (CSMA / CA); (b) a processor coupled to the station; and (c) a non-transitory memory storing instructions executable by the processor, which, when executed by the processor, cause the station to: (d)(i) a station operating as a non-access point (non-AP) station (STA) to embed recommended parameter settings for a trigger frame (TF) indicating its quality of service (QoS) requirements in a trigger request frame (RTF) and transmit the RTF to an associated AP; (d)(i) a station operating as an access point (AP) receiving the RTF and transmitting the TF as requested by the non-AP STA to trigger transmissions of the non-AP STA and other non-AP STAs; and (d)(iii) a non-AP STA to transmit the TF to an associated AP. An apparatus for executing a communication protocol for a station and other stations operating as either an AP station or a non-AP station on a network by performing operations including: a STA initiating transmission as triggered by the AP in response to receiving a TF from the AP, and a transmission opportunity (TXOP) obtained by a non-AP station is shared with other stations through use of an AP station in a basic service set (BSS).

[0261] An apparatus for wireless communication in a network, comprising: (a) a wireless communication circuit configured as a station for wirelessly communicating with at least one other station on a network using carrier sense multiple access with collision avoidance (CSMA / CA) and for which a multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-transitory memory storing instructions executable by the processor, the instructions, when executed by the processor, causing: (d)(i) a station that is part of the multi-link device (MLD) and operates as a first access point (AP) to transmit a BSRP frame on one link to collect buffer status and quality of service (QoS) requirements from an associated non-access point (non-AP) MLD; (d)(ii) a station that is part of the multi-link device (MLD) and operates as a first AP to share the buffer status and QoS requirements of the associated non-AP MLD with all serving APs in a plurality of links; and (d)(iii) a station that operates as an serving AP of the first AP to send a BSRP frame on one link to collect buffer status and quality of service (QoS) requirements from an associated non-AP MLD with all serving APs in a plurality of links. and scheduling transmissions using the buffer status from the MLD and the QoS requirements of the buffer, thereby executing a communications protocol for the station and other stations operating as either an AP station or a non-AP station on a network, wherein a transmission opportunity (TXOP) obtained by a non-AP station is shared with other stations through use of an AP station in a basic service set (BSS).

[0262] An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on the network using carrier sense multiple access with collision avoidance (CSMA / CA) and for which multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-transitory memory storing instructions executable by the processor, the instructions, when executed by the processor, for (d)(i) a station operating as a non-access point (non-AP) station accessing a channel on a first link and transmitting its TXOP to an access point (AP) associated with the first link. (d)(ii) a station operating as an AP associated with the first link contends for a channel on a second link and obtains channel access rights within a TXOP sharing period on the first link; and (d)(iii) an AP associated with the first link arranges for transmission on both the first link and the second link, thereby executing a communications protocol for the station and other stations operating as either an AP station or a non-AP station on a network, wherein a transmission opportunity (TXOP) obtained by a non-AP station is shared with other stations through use of an AP station in a basic service set (BSS).

[0263] A wireless communication system / apparatus for performing packet transmission, in which CSMA / CA is applied within the system / apparatus, a non-AP STA obtains a TXOP and notifies an AP to share the TXOP within its own BSS, an AP of the BSS collects buffer status and QoS requirements of the buffer from the STA, and the AP arranges transmission in the shared TXOP to satisfy the QoS requirements of the buffer reported from the STA.

[0264] A wireless communication system / apparatus for performing packet transmission, in which CSMA / CA is applied within the system / apparatus, including a non-AP STA sending a trigger request frame (RTF) to an associated AP, the non-AP STA embedding recommended parameter settings of a TF in the RTF, and the AP receiving the RTF and transmitting the TF as requested by the STA.

[0265] A wireless communication system / apparatus for performing packet transmission, in which CSMA / CA and multi-link operation are applied, in which an AP MLD transmits a BSRP frame on one link to collect buffer status and buffer QoS requirements from associated non-AP MLDs, the AP MLD shares the buffer status and buffer QoS requirements of the associated non-AP MLD with all serving APs in multiple links, and each serving AP schedules transmission using the buffer status and buffer QoS requirements from the associated non-AP MLD.

[0266] A wireless communication system / apparatus for performing packet transmission, in which CSMA / CA and multi-link operation are applied, a non-AP STA accesses a channel on one link (shown as link 1) and shares its TXOP with an associated AP, the AP MLD of the associated AP contends for a channel on another link (shown as link 2) and acquires channel access rights within the TXOP sharing period on link 1, and the AP MLD arranges transmission on both link 1 and link 2.

[0267] The apparatus of any preceding implementation, wherein the messaging received at the station acting as an AP from a station acting as a non-AP regarding the sharing of its TXOP is prefixed with content having duplicate information regarding TXOP sharing in a direction that eliminates communication errors when the station acting as an AP processes information regarding the TXOP sharing.

[0268] A device of any preceding implementation, in which a station operating as a non-AP STA sharing its own TXOP transmits a frame to a station operating as an AP with the same information prefixed in the preamble to indicate the TXOP sharing and payload carrying buffer status transmitted by the random RU.

[0269] A device of any preceding implementation, in which a station acting as a non-AP STA sharing its TXOP transmits a frame negotiated with the station acting as an AP with a receiver address prefixed to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner, to the station acting as an AP.

[0270] An apparatus of any preceding implementation, in which a station acting as a non-AP STA sharing its TXOP transmits a Clear to Send (CTS) frame to a station acting as an AP to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner.

[0271] An apparatus according to any preceding implementation, wherein a station acting as a non-AP STA sharing its TXOP transmits a Buffer Status Report (BSR) frame to a station acting as an AP to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner.

[0272] The apparatus of any preceding implementation, wherein a station acting as an AP station that collects buffer status from at least one other station transmits a Buffer Status Report Poll (BSRP) trigger frame to the at least one other station requesting the buffer status and QoS requirements of the buffer.

[0273] The apparatus of any preceding implementation, wherein a station acting as a non-AP station reporting buffer status to an AP station may transmit different types of Buffer Status Report (BSR) frames reporting the buffer status and QoS requirements of the buffer.

[0274] A station acting as a non-AP STA that reports buffer status to an AP station reports expiration times for buffered traffic, as in any preceding implementation.

[0275] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA that reports buffer status to an AP station reports buffered traffic for peer-to-peer transmission.

[0276] The apparatus of any preceding implementation, wherein a station operating as an AP station is configured to arrange transmissions in a shared TXOP and performs arranging the peer-to-peer transmissions by allocating a portion of channel time for the peer-to-peer transmissions.

[0277] The apparatus of any preceding implementation, wherein a station operating as an AP station is configured to arrange transmissions by taking over a TXOP during a shared TXOP and acting as a TXOP owner, and arranges multi-user transmissions, including downlink transmissions and any peer-to-peer transmissions.

[0278] The apparatus of any preceding implementation, wherein a station operating as an AP station is configured to arrange transmissions by taking over a TXOP during a shared TXOP and acting as a TXOP owner, and arranges multi-user transmissions, including uplink transmissions and any peer-to-peer transmissions.

[0279] A station operating as a non-AP STA sending a request-to-trigger frame (RTF) may embed a buffer status report in the RTF, in accordance with any preceding implementation of the device.

[0280] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA sending a trigger request frame (RTF) can provide an indication to allow TXOP sharing.

[0281] The apparatus of any preceding implementation, wherein non-AP stations sharing said QoS requirements of a buffer also include information regarding an expiration time of the buffer.

[0282] The apparatus of any preceding implementation, wherein non-AP stations that share buffer status also share buffer status for P2P transmissions.

[0283] The AP that wins channel access on the second link sends a clear-to-send (CTS-to-self) frame to reserve a TXOP.

[0284] An apparatus of any preceding implementation, wherein an AP that has gained channel access on the second link transmits a clear to send (CTS-to-self) frame incorporating padding to align physical layer protocol data unit (PPDU) end times on both the first and second links.

[0285] The apparatus of any preceding implementation, wherein an AP arranging for transmission on both the first and second links transmits a Buffer Status Report (BSRP) frame to collect buffer status and buffer Quality of Service (QoS) requirements from non-AP STAs.

[0286] Any non-AP STA that shares its TXOP can send frames with the same prefixed content to the AP, according to any prior implementation.

[0287] The device of any preceding implementation, in which any non-AP STA sharing its TXOP can transmit a frame to the AP with the same prefixed preamble and the payload transmitted by the random RU.

[0288] Any non-AP STA that shares its TXOP may send a frame to the AP with the receiver address prefixed and negotiated with the AP to indicate that the frame is for TXOP sharing, any prior implementation of the device.

[0289] Any non-AP STA that shares its TXOP may send a CTS frame to the AP to indicate TXOP sharing, in accordance with any prior implementation of the device.

[0290] Any non-AP STA that shares its TXOP may send a BSR frame to the AP to indicate TXOP sharing, in any prior implementation of the device.

[0291] In any prior implementation, an AP that collects buffer status from a STA may send a BSRP trigger frame to request the STA for the buffer status and QoS requirements of the buffer.

[0292] In any prior implementation, a non-AP STA reporting buffer status to the AP may send different types of BSR frames to report the buffer status and the QoS requirements of the buffer.

[0293] A non-AP STA that reports buffer status to the AP may report expiration times for buffered traffic, as in any prior implementation.

[0294] The apparatus of any preceding implementation, wherein a non-AP STA that reports buffer status to an AP can report buffered traffic for peer-to-peer transmission.

[0295] An AP that arranges transmission during a shared TXOP may arrange peer-to-peer transmission, as in any preceding implementation.

[0296] The apparatus of any preceding implementation, wherein an AP arranging transmissions during a shared TXOP can arrange multi-user transmissions, including downlink transmissions and peer-to-peer transmissions.

[0297] The apparatus of any preceding implementation, wherein an AP arranging transmissions during a shared TXOP can arrange multi-user transmissions, including uplink transmissions and peer-to-peer transmissions.

[0298] A non-AP STA sending a request-to-trigger frame (RTF) may embed a buffer status report in the RTF, as in any prior implementation.

[0299] A non-AP STA sending a trigger request frame (RTF) may indicate that it is willing to allow TXOP sharing, in any prior implementation of the device.

[0300] The term "implementation" as used herein is intended to include, without limitation, embodiments, examples, or other forms for practicing the techniques described herein.

[0301] As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly indicates otherwise. Reference to an object in the singular does not mean "the only one" unless expressly stated otherwise, but rather means "one or more."

[0302] In this disclosure, constructs such as "A, B, and / or C" indicate that either A, B, or C, or any combination of items A, B, and C, may be present. Constructs such as "at least one of" followed by a group of listed elements indicate that at least one of the group of elements is present, including possible combinations of any of the listed elements, where applicable.

[0303] References in this disclosure to "an embodiment," "at least one embodiment," or similar embodiment language indicate that a particular feature, structure, or characteristic described in connection with the described embodiment is included in at least one embodiment of the disclosure. Thus, these references to various embodiments do not necessarily refer to all the same embodiment, or to a specific embodiment that is different from all other embodiments described. References to embodiments should be interpreted to mean that the particular features, structures, or characteristics of a given embodiment can be combined in any suitable manner in one or more embodiments of the disclosed devices, systems, or methods.

[0304] As used herein, the term "set" refers to a collection of one or more objects. Thus, for example, a set of objects can include a single object or multiple objects.

[0305] Relative terms such as first and second, top and bottom, etc. in this document are used merely to distinguish one entity or action from another entity or action, and do not necessarily require or imply any such actual relationship or ordering between such entities or actions.

[0306] The terms "comprises, comprising, has, having, includes, including, contains, containing," or any other variations of these terms, are intended to cover non-exclusive inclusions, such that a process, method, article, or apparatus that comprises, has, or includes a list of elements does not include only those elements, but may also include other elements not expressly listed or that are inherent to such process, method, article, or apparatus. An element following "comprises ... a, has ... a, includes ... a, contains ... a" does not exclude, without further constraints, the presence of additional identical elements in the process, method, article, or apparatus that comprises, has, or includes that element.

[0307] As used herein, the terms "approximately", "approximate", "substantially", "essentially" and "about", or any variation thereof, are used to describe and explain slight variations. When used in relation to events or circumstances, these terms can mean that the events or circumstances will definitely occur and that the events or circumstances are highly likely to occur. When used in relation to a numerical value, these terms can mean a variation range of ±10% or less, such as ±5% or less, ±4% or less, ±3% or less, ±2% or less, ±1% or less, ±0.5% or less, ±0.1% or less, or ±0.05% or less of the numerical value. For example, being "substantially" aligned can mean an angle variation range of ±10° or less, such as ±5° or less, ±4° or less, ±3° or less, ±2° or less, ±1° or less, ±0.5° or less, ±0.1° or less, or ±0.05° or less.

[0308] In addition, amounts, ratios, and other numerical values ​​may be expressed in range format in this specification. Such range formats are used for convenience and simplification, and include numerical values ​​explicitly specified as the limits of the range, but should be understood to include all individual numerical values ​​or subranges within the range as if each of these numerical values ​​and subranges were explicitly stated. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also include individual ratios such as about 2, about 3, about 4, and subranges such as about 10 to about 50, about 20 to about 100, etc.

[0309] The term "coupled," as used herein, is defined as connected, but not necessarily in a direct mechanical connection. A device or structure that is "configured" in a particular way is configured in at least that way, but may also be configured in other ways not listed.

[0310] Benefits, advantages, solutions to problems, and any element(s) that cause or make any advantage, advantage, or solution more pronounced are not to be construed as critical, necessary, or essential features or elements of the technology described herein, or of any or all of the claims.

[0311] Also, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Inventive subject matter may be embodied in less than all features of a single disclosed embodiment.

[0312] The Abstract of the Disclosure is presented to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims.

[0313] It is understood that some jurisdictions have a practice of requiring the deletion of one or more portions of the present disclosure after filing. Thus, the reader should refer to the application as of its filing date for the original content of the present disclosure. The deletion of any of the disclosed content should not be construed as an abandonment, forfeiture, or dedication to the public of any subject matter of the application as originally filed.

[0314] The following claims are hereby incorporated into this disclosure, with each claim standing on its own as a separate inventive subject matter.

[0315] Although the description herein contains many details, these should not be construed as limiting the scope of the disclosure, but merely as exemplifying some of the presently preferred embodiments, and therefore the scope of the disclosure will be understood to fully embrace other embodiments that may become apparent to those skilled in the art.

[0316] Structural and functional equivalents of elements of the embodiments of the present disclosure known to those skilled in the art are also expressly incorporated herein by reference and are intended to be included in the scope of the claims. Moreover, no element, component, or method step of the present disclosure is intended to be publicly disclosed, regardless of whether they are explicitly recited in the claims. No claim element herein should be construed as a "means-plus-function" element unless the element is explicitly recited using the phrase "means for". No claim element herein should be construed as a "step-plus-function" element unless the element is explicitly recited using the phrase "step for". [Explanation of symbols]

[0317] 70 Embodiments 72 non-AP STAs share TXOP within a BSS 76 A non-AP STA sends a frame (e.g., RTS, CTS, RTF, BSR, RTA-BSR, P2P-BSR) to its associated AP to indicate TXOP sharing. 78 Did a non-AP STA receive feedback from its associated AP before the timeout? 80 TXOP sharing initiated by non-AP STA was successful 82 Non-AP STAs follow the schedule scheduled by the AP 84 TXOP sharing initiated by non-AP STA failed Table 1 User Priority to Access Category (UP to AC) Mapping TIFF2025019064000002.tif74158 Table 2 Default parameter settings for EDCA channel access TIFF2025019064000003.tif34153

Claims

1. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on a network using carrier sense multiple access with collision avoidance (CSMA / CA); (b) a processor coupled to the station; and (c) a non-transitory memory that stores instructions executable by the processor; and Equipped with (d) the instructions, when executed by the processor, (i) receiving, in a station operating as an access point (AP), messaging from a non-access point (non-AP) station that has acquired a transmission opportunity (TXOP) notifying the access point (AP) station about sharing the TXOP within a basic service set (BSS); (ii) the station acting as an AP obtaining a buffer status and buffer Quality of Service (QoS) requirements associated with the at least one other station; (iii) the station acting as an AP functions during a shared TXOP as a TXOP owner on behalf of the non-AP station that obtained the TXOP to satisfy the QoS requirements of the buffer reported by the at least one other station; and executing a communications protocol for said station and other stations operating as either an AP station or a non-AP station on the network by performing operations including: An apparatus comprising:

2. In order to eliminate communication errors when a station acting as an AP processes information related to TXOP sharing, the messaging related to sharing the TXOP of a non-AP station, which is received in the station acting as an AP from a station acting as a non-AP station, is prefixed with content carrying duplicate information related to sharing the TXOP; 2. The apparatus of claim 1.

3. A station acting as a non-AP STA sharing its own TXOP transmits a frame to a station acting as an AP, the frame having the same information to indicate the TXOP sharing and payload carrying buffer status transmitted by the random RU prefixed in the preamble; 2. The apparatus of claim 1.

4. A station acting as a non-AP STA sharing its own TXOP transmits a frame, which is negotiated with the station acting as an AP and has a receiver address prefixed thereto, to the station acting as an AP to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner; 2. The apparatus of claim 1.

5. A station acting as a non-AP STA sharing its TXOP transmits a clear to send (CTS) frame to the station acting as an AP to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner; 2. The apparatus of claim 1.

6. A station acting as a non-AP STA sharing its TXOP transmits a Buffer Status Report (BSR) frame to the station acting as an AP to indicate TXOP sharing and permission for the station acting as an AP to become the TXOP owner; 2. The apparatus of claim 1.

7. a station acting as an AP station collecting buffer status from at least one other station, transmitting a Buffer Status Report Poll (BSRP) trigger frame to the at least one other station requesting a buffer status and a QoS requirement of the buffer; 2. The apparatus of claim 1.

8. A station acting as a non-AP station reporting buffer status to an AP station may transmit different types of Buffer Status Report (BSR) frames to report the buffer status and the QoS requirements of the buffer; 2. The apparatus of claim 1.

9. A station acting as a non-AP STA that reports buffer status to an AP station reports the expiration time of buffered traffic; 2. The apparatus of claim 1.

10. A station acting as a non-AP STA that reports buffer status to an AP station reports buffered traffic for peer-to-peer transmission; 2. The apparatus of claim 1.

11. a station operating as an AP station is configured to arrange for transmission during the shared TXOP, and performs arranging the peer-to-peer transmission by allocating a portion of the channel time for the peer-to-peer transmission; 2. The apparatus of claim 1.

12. A station operating as an AP station is configured to arrange transmissions by taking over the TXOP during the shared TXOP and acting as the TXOP owner, and arranges multi-user transmissions, including downlink transmissions and any peer-to-peer transmissions; 2. The apparatus of claim 1.

13. A station operating as an AP station is configured to arrange transmissions by taking over the TXOP during the shared TXOP and acting as the TXOP owner, and arranges multi-user transmissions, including uplink transmissions and any peer-to-peer transmissions; 2. The apparatus of claim 1.

14. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on a network using carrier sense multiple access with collision avoidance (CSMA / CA); (b) a processor coupled to the station; and (c) a non-transitory memory that stores instructions executable by the processor; and Equipped with (d) the instructions, when executed by the processor, (i) a station operating as a non-access point (non-AP) station (STA) embeds recommended parameter settings of a trigger frame (TF) indicating its quality of service (QoS) requirements in a trigger request frame (RTF) and transmits the RTF to an associated AP; (i) a station acting as an access point (AP) receiving the RTF and transmitting a TF as requested by the non-AP STA to trigger transmission of the non-AP STA and other non-AP STAs; (iii) the non-AP STA initiating transmission as triggered by the AP in response to receiving a TF from the AP; Executing a communications protocol for the station and other stations operating as either an AP station or a non-AP station on the network by performing operations including: An apparatus comprising:

15. A station operating as a non-AP STA that transmits a request-to-trigger frame (RTF) embeds a buffer status report in the RTF; 15. The apparatus of claim 14.

16. A station acting as a non-AP STA sending a trigger request frame (RTF) can provide an indication to grant TXOP sharing.

15. The apparatus of claim 14.

17. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on a network using carrier sense multiple access with collision avoidance (CSMA / CA) and for which multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-transitory memory that stores instructions executable by the processor; and Equipped with (d) the instructions, when executed by the processor, (i) a station that is part of a multi-link device (MLD) and acts as a first access point (AP) sending a BSRP frame on one link to collect buffer status and buffer quality of service (QoS) requirements from associated non-access point (non-AP) MLDs; (ii) the station, which is part of a multi-link device (MLD) and acts as a first AP, shares the buffer status and buffer QoS requirements of associated non-AP MLDs with all serving APs in multiple links; (iii) a station acting as a serving AP of the first AP schedules transmissions using the buffer status and the QoS requirements of the buffer from an associated non-AP MLD; Executing a communications protocol for the station and other stations operating as either an AP station or a non-AP station on the network by performing operations including: An apparatus comprising:

18. Non-AP stations sharing the QoS requirements of a buffer also include information regarding the expiration time of the buffer.

20. The apparatus of claim 17.

19. Non-AP stations that share the buffer status also share buffer status for P2P transmissions.

20. The apparatus of claim 17.

20. An apparatus for wireless communication in a network, comprising: (a) wireless communication circuitry configured as a station for wirelessly communicating with at least one other station on a network using carrier sense multiple access with collision avoidance (CSMA / CA) and for which multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-transitory memory that stores instructions executable by the processor; and Equipped with (d) the instructions, when executed by the processor, (i) a station operating as a non-access point (non-AP) station accesses a channel on a first link and shares its TXOP with an associated AP, which is a station operating as an access point (AP) associated with the first link; (ii) a station acting as an AP associated with the first link contending for a channel on a second link and acquiring channel access rights within a TXOP sharing period on the first link; (iii) an AP associated with the first link arranging for transmission on both the first link and the second link; Executing a communications protocol for the station and other stations operating as either an AP station or a non-AP station on the network by performing operations including: An apparatus comprising:

21. The AP that has won channel access on the second link sends a clear-to-send (CTS-to-self) frame to reserve a TXOP; 21. The apparatus of claim 20.

22. The AP that has gained channel access on the second link transmits a clear-to-send (CTS-to-self) frame that incorporates padding to align physical layer protocol data unit (PPDU) end times on both the first and second links; 21. The apparatus of claim 20.

23. An AP arranging for transmission on both the first and second links transmits a Buffer Status Report (BSRP) frame to collect buffer status and buffer Quality of Service (QoS) requirements from non-AP STAs; 21. The apparatus of claim 20.

Images