Request trigger frame initiated by NON-AP STA and TXOP sharing

Abstract

A wireless communication apparatus, system, or method is provided for operating on a network utilizing CSMA / CA, in which non-AP stations can share their TXOPs. After obtaining a TXOP, the non-AP station notifies the AP within its BSS of the shared TXOP. The AP collects buffered QoS requirements and buffer status from the stations and schedules transmissions during the shared TXOP to meet the buffered QoS requirements reported by the STAs. Non-AP stations can also share their TXOPs with the AP using trigger frames or other mechanisms. The AP station can be part of a multi-link device, and the AP can schedule transmissions on multiple links of the MLD.

Description

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS)

[0002] This application claims priority to and the benefit of U.S. patent application serial No. 17 / 228,214, filed on April 12, 2021, which is hereby incorporated by reference in its entirety, and claims priority to and the benefit of U.S. provisional patent application serial No. 63 / 066,354, filed on August 17, 2020, which is hereby incorporated by reference in its entirety.

[0003] (Statement Regarding Federally Sponsored Research or Development)

[0004] not applicable.

[0005] (Computer Program Appendix Incorporated by Reference)

[0006] not applicable.

[0007] (Notice of Copyrighted Material)

[0008] Portions of the material in this patent document may be copyrighted under the copyright laws of the United States and other countries. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office publicly available file or records, but otherwise reserves all copyright rights whatsoever. The copyright owner does not waive any of its rights to maintain confidentiality with respect to this patent document, including but not limited to its rights under 37 CFR §1.14. Technical Field

[0009] The technology of the present disclosure generally pertains to wireless communication systems (WLANs), and more specifically to WLANs using CSMA / CA, in which non-access point (non-AP) stations obtain and share transmit opportunities (TXOPs), with the AP transmitting during the TXOP through a buffered arrangement. Background Art

[0010] Current wireless technologies using Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) focus on achieving high throughput performance of networks, but they lack the ability to meet some packet requirements for low-latency delivery, such as required by real-time applications (RTA).

[0011] RTA requires low-latency communication and uses best-effort communication. Data generated from RTA is referred to herein as RTA traffic and will be packaged as RTA packets at the transmitter station (STA). In addition, data generated from non-time-sensitive applications will be referred to herein as non-RTA traffic and will be packaged as non-RTA packets at the transmitter STA.

[0012] RTA packets require low latency due to their high timeliness requirements. RTA packets are valid only when they are delivered within a certain time period. One solution in CSMA / CA wireless technology is to enable STAs to gain channel access faster with less channel contention time.

[0013] Due to the random channel access scenario of CSMA / CA, STAs need to sense and contend for channel access before transmitting each packet. Although short channel contention time speeds up channel access, the contention time may still be significant compared to the delay requirement of RTA packets, thus hindering delivery within the required time interval.

[0014] Therefore, there is a need for a mechanism to support low-latency RTA packet delivery. Compared with the prior art, the present disclosure meets this need and provides additional benefits. Summary of the Invention

[0015] This paper describes a WLAN protocol using CSMA / CA, in which a non-AP STA obtains a TXOP and notifies the AP within its BSS of the shared TXOP. The BSS's AP collects buffered QoS requirements and buffer status from the STA. The AP then schedules transmissions during the shared TXOP to meet the buffered Quality of Service (QoS) requirements reported by the STA.

[0016] In one variation of the above, a non-AP STA sends a Request Trigger Frame (RTF) to its associated AP and embeds recommended parameter settings for a Trigger Frame (TF) in the RTF. The AP receives the RTF and sends the TF according to the STA's request.

[0017] Additional variations describe how this can be used for multi-link operation. In one variation, an AP Multi-Link Device (MLD) sends a Buffer Status Report (BSRP) frame on a link to collect buffered QoS requirements and buffer status from its associated non-AP MLD. The AP MLD shares the buffered QoS requirements and buffer status with all of its subordinate APs across multiple links using its associated non-AP MLD. Each subordinate AP then uses the buffered QoS requirements and buffer status from its associated non-AP MLD to schedule transmissions.

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

[0019] This disclosure includes many variations and examples.

[0020] Other aspects of the technology described herein will be presented in the following portions of the specification, wherein the purpose of the detailed description is to fully disclose preferred embodiments of the technology without placing limitations thereon. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The technology described herein may be more fully understood by reference to the following drawings, which are included for illustration purposes only:

[0022] FIG1 is a flow chart of a retransmission scheme in CSMA / CA under IEEE 802.11.

[0023] 2A and 2B are diagrams showing data fields of a data frame and an ACK frame format in a conventional WLAN system.

[0024] Figure 3 shows the data field of the HE-SU PPDU frame format in IEEE 802.11ax.

[0025] FIG4 is a communication sequence diagram of a double-sized contention window when performing retransmission in CSMA / CA.

[0026] FIG5 is a communication sequence diagram showing packets discarded due to reaching the retry limit under CSMA / CA.

[0027] FIG6 is a diagram of the data field of the HE-MU PPDU frame format in IEEE 802.11ax.

[0028] FIG7 is a diagram of the data field of the HE-TB PPDU frame format in IEEE 802.11ax.

[0029] FIG8 is a diagram of the data field of the trigger frame format in IEEE 802.11ax.

[0030] FIG. 9 is a diagram showing data fields of the common information field in the trigger frame shown in FIG. 8 .

[0031] FIG. 10 is a diagram showing data fields of a user information field in the trigger frame shown in FIG. 8 .

[0032] FIG. 11 is a diagram showing data fields of the trigger-dependent user information field in the trigger frame shown in FIG. 10 for MU-BAR.

[0033] FIG. 12 is a diagram showing a data field of a block ACK (BA) frame format in a conventional WLAN system.

[0034] FIG13 is a diagram showing the data fields of the BSR frame format.

[0035] FIG14 is a communication sequence diagram of a CSMA / CA retransmission scheme in a downlink of an OFDMA system.

[0036] FIG15 is a communication sequence diagram of a CSMA / CA retransmission scheme in the uplink of an OFDMA system.

[0037] FIG16 is a queue structure diagram of the EDCA queue system.

[0038] FIG17 is a diagram showing the communication format of EDCA channel access.

[0039] FIG18 is a diagram showing the data field of a conventional IEEE 802.11be preamble.

[0040] FIG. 19 is a hardware block diagram of a station configuration such as included in multi-link device hardware, in accordance with at least one embodiment of the present disclosure.

[0041] Figure 20 is a station topology embodiment considered according to at least one embodiment of the present disclosure.

[0042] Figure 21 FIG1 is a flowchart of a non-AP STA sharing a TXOP within its associated BSS, performed according to at least one embodiment of the present disclosure.

[0043] Figure 22 The present invention is a flowchart of an AP receiving a frame for initiating TXOP sharing from a non-AP STA, performed according to at least one embodiment of the present disclosure.

[0044] Figure 23 FIG. 4 is a flowchart of a non-AP STA sending an RTF according to at least one embodiment of the present disclosure.

[0045] Figure 24 FIG. 4 is a flowchart of an AP receiving RTF according to at least one embodiment of the present disclosure.

[0046] Figure 25 FIG. 1 is a flowchart of an AP collecting buffer status of STAs within its BSS according to at least one embodiment of the present disclosure.

[0047] Figure 26 is a flowchart of a non-AP STA reporting its buffer status to its associated AP according to at least one embodiment of the present disclosure.

[0048] Figure 27 is a communication sequence diagram illustrating an example of a non-AP STA requesting a P2P trigger frame from an AP according to at least one embodiment of the present disclosure.

[0049] Figure 28 is a communication sequence diagram illustrating an example in which a non-AP STA requests a P2P trigger frame from an AP and the AP sends multiple P2P-TFs, according to at least one embodiment of the present disclosure.

[0050] Figure 29 is a communication sequence diagram illustrating an example in which a non-AP STA requests a P2P trigger frame from an AP and the AP sends one P2P-TF for multiple P2P transmissions, according to at least one embodiment of the present disclosure.

[0051] Figure 30 is a communication sequence diagram illustrating an example of a non-AP STA requesting a basic trigger frame from an AP according to at least one embodiment of the present disclosure.

[0052] Figure 31 is a communication sequence diagram illustrating an example in which a non-AP STA requests a basic trigger frame from an AP to use all RUs, according to at least one embodiment of the present disclosure.

[0053] Figure 32 is a communication sequence diagram illustrating an example in which a non-AP STA requests a basic trigger frame from an AP and the AP sends one TF for multiple uplink transmissions, according to at least one embodiment of the present disclosure.

[0054] Figure 33 is a communication sequence diagram illustrating an example in which a non-AP STA requests a basic trigger frame from an AP and the AP sends multiple TFs, according to at least one embodiment of the present disclosure.

[0055] Figure 34 FIG. 4 is a communication sequence diagram illustrating an example in which a non-AP STA shares a TXOP by sending an RTF frame to an AP, according to at least one embodiment of the present disclosure.

[0056] Figure 35 FIG. 4 is a communication sequence diagram illustrating an example in which a non-AP STA shares a TXOP by sending an RTS frame to an AP, according to at least one embodiment of the present disclosure.

[0057] Figure 36 A communication sequence diagram illustrating an example in which non-AP STAs share a TXOP by sending MU-BSR frames to an AP when two STAs use different RUs to carry a buffer status report in an MU-BSR, according to at least one embodiment of the present disclosure.

[0058] Figure 37 A communication sequence diagram illustrating an example in which non-AP STAs share a TXOP by sending MU-BSR frames to an AP when two STAs use the same RU to carry a buffer status report in an MU-BSR, according to at least one embodiment of the present disclosure.

[0059] Figure 38 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, according to at least one embodiment of the present disclosure.

[0060] Figure 39 FIG. 4 is a communication sequence diagram illustrating an example in which a non-AP STA shares a TXOP by sending a BSR frame to an AP according to at least one embodiment of the present disclosure.

[0061] Figure 40 is a communication sequence diagram illustrating an example in which a non-AP STA initiates P2P transmission by sending an RTF frame to an AP without sharing a TXOP, according to at least one embodiment of the present disclosure.

[0062] Figure 41 is a communication sequence diagram illustrating an example in which a non-AP STA initiates P2P transmission by sending an RTF frame to an AP in a shared TXOP, according to at least one embodiment of the present disclosure.

[0063] Figure 42 is a communication sequence diagram for an example of enabling P2P transmission when a non-AP STA shares a TXOP by sending a P2P-BSR frame to an AP, according to at least one embodiment of the present disclosure.

[0064] Figure 43 is a communication sequence diagram for an example of enabling P2P transmission when a non-AP STA shares its TXOP by sending an MU-BSR frame to an AP when the two STAs use different RUs to carry a BSR in a MU-BSR, according to at least one embodiment of the present disclosure.

[0065] Figure 44 is a communication sequence diagram for an example of enabling P2P transmission when a non-AP STA shares its TXOP by sending an MU-BSR frame to an AP when both STAs use the same RU to carry a BSR in an MU-BSR, according to at least one embodiment of the present disclosure.

[0066] Figure 45 is a communication sequence diagram for an example of enabling P2P transmission when a non-AP STA shares its TXOP by sending a CTS frame to an AP, according to at least one embodiment of the present disclosure.

[0067] Figure 46A and Figure 46B is a communication sequence diagram for an example of enabling P2P transmission when non-AP STAs share their TXOPs, according to at least one embodiment of the present disclosure.

[0068] Figures 47A to 47C is a communication sequence diagram illustrating an example of an AP arranging transmissions in a TXOP, according to at least one embodiment of the present disclosure.

[0069] Figure 48Aand Figure 48B is a communication sequence diagram illustrating an example of a non-AP MLD sharing its TXOP in a multi-link scenario when the non-AP MLD is unable to perform STR, according to at least one embodiment of the present disclosure.

[0070] Figure 49 is a diagram of data fields of any type of BSR frame format according to at least one embodiment of the present disclosure.

[0071] Figure 50 is a diagram of data fields of a BA+BSR frame format according to at least one embodiment of the present disclosure.

[0072] Figure 51 1 is a diagram of a data field of a data+BSR frame format according to at least one embodiment of the present disclosure.

[0073] Figure 52 FIG. 4 is a data field diagram of an HT control field format for a BSR control subfield modification example according to at least one embodiment of the present disclosure.

[0074] Figure 53 is a data field diagram of the RTA-BSR control subfield as the A-control subfield according to at least one embodiment of the present disclosure.

[0075] Figure 54 is a data field diagram of a P2P-BSR control subfield as an A-control subfield according to at least one embodiment of the present disclosure.

[0076] Figure 55 is a data field diagram of an RTF frame format according to at least one embodiment of the present disclosure.

[0077] Figure 56 is a diagram of data fields of a CTS frame format for TXOP sharing according to at least one embodiment of the present disclosure.

[0078] Figure 57 FIG. 4 is a diagram of data fields of a P2P trigger frame format and its subordinate user information field according to at least one embodiment of the present disclosure.

[0079] Figure 58 is a data field diagram indicating the format of a preamble when TXOP sharing according to at least one embodiment of the present disclosure. DETAILED DESCRIPTION

[0080] 1. WLAN system under IEEE 802.11

[0081] 1.1.CSMA / CA System

[0082] In a WLAN system, IEEE 802.11 uses CSMA / CA to allow a station (STA) to gain access to a channel for packet transmission and retransmission.

[0083] Figure 1 depicts a flowchart of this process. In a CSMA / CA system, before each transmission and retransmission, the STA must sense the channel state and set a backoff time for contention channel access. The backoff time is determined by a uniform random variable between 0 and the contention window size. After the STA waits for the backoff time and detects that the channel is idle, it can send a packet.

[0084] If an acknowledgment (ACK) is received for the transmission, the transmission is successful. Otherwise, a retransmission of that packet is required because the STA did not receive an ACK for the packet transmission before a timeout occurred. When a retransmission is required, 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 no retransmission is scheduled. Otherwise, a retransmission is scheduled.

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

[0086] The STA sets another backoff time according to the new size of the contention window. The STA waits for the backoff time period for checking the channel status and performing its retransmission, and proceeds accordingly.

[0087] Figure 2A illustrates a data frame format in a conventional WLAN system with the following fields. The Frame Control field indicates the type of frame. The Duration field contains NAV information 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 transmitting 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. A Frame Check Sequence (FCS) is also shown here and in other data structures described herein. The FCS is an error detection code added to the frame in the communication protocol when transmitting data from a source to a destination.

[0088] Figure 2B shows the format of an acknowledgment (ACK) frame in a conventional WLAN system having the following fields: The Frame Control field indicates the type of frame. The Duration field contains the NAV information for CSMA / CA channel access. The RA field contains the address of the receiver of the frame.

[0089] Figure 3 depicts the High Efficiency (HE) Single User (SU) Physical Layer Protocol Data Unit (PPDU) format for SU transmission in IEEE 802.11ax; the format contains the following fields.

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

[0091] Figure 4 illustrates an example of retransmissions in CSMA / CA where the backoff time increases due to retransmissions. The data frame and ACK frame use the formats shown in Figures 2A and 2B, respectively. The frames are packetized using the packet format shown in Figure 3. In this example, after the transmitter initially transmits the packet, it does not receive an ACK before a timeout. Therefore, it sets another backoff time for the first retransmission, resulting in a contention window size of n slots. After waiting for the backoff time, the transmitter STA retransmits the packet for the first time. However, this retransmission also fails. The transmitter STA needs to retransmit the packet and sets a backoff time again to contend for channel access again. This time, due to the retransmission, the contention window size doubles to 2*n slots. The expected backoff time also doubles due to the contention window size. Since it receives an ACK before the timeout, the second retransmission succeeds.

[0092] Figure 5 shows an example of packet discarding after the number of retransmissions exceeds the retry limit. Let's denote the retry limit as R. Data frames 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, after the initial transmission of a packet fails, the transmitter STA retransmits that packet multiple times. However, none of the retransmissions succeed. After retransmitting R times, the number of retransmissions exceeds the retry limit, causing the transmitter STA to stop retransmitting the packet, and the packet is discarded.

[0093] 1.2. Multi-user transmission

[0094] Multi-user transmission is available in wireless networks such as IEEE 802.11. Since IEEE 802.11ax, networks support multi-user transmission in both uplink and downlink directions. Multi-user transmission in IEEE 802.11ax includes multiple-input multiple-output (MIMO) and orthogonal frequency division multiple access (OFDMA) modes, which can be used individually or together.

[0095] IEEE 802.11ax uses a multi-user (MU) transport packet format, such as that shown in Figures 2A and 2B, to transmit data in multi-user mode. When multiple users transmit or receive a "MU transport packet," all users share the same physical layer convergence procedure (PLCP) header for the MU transport packet. Each user then transmits or receives the data carried by the MU transport packet using a separate resource block, including resource unit (RU) allocations and modulation and coding schemes (MCS).

[0096] IEEE 802.11ax defines multiple PPDU formats to transmit packets in different multi-user transmission scenarios. They are listed below.

[0097] Figure 6 illustrates the HE multi-user (MU) PPDU format for downlink (DL) multi-user transmission. Compared to the single-user PPDU format shown in Figure 3, it adds the HE-SIG-B field to its format, which provides separate resource block allocation information for each user.

[0098] Figure 7 shows the HE-triggered (TB) PPDU format for uplink (UL) multi-user transmission. The fields in the HE-TB PPDU format are the same as those in the HE single-user PPDU format, except that the HE-STF field is 8 μs long.

[0099] Figure 8 depicts the contents of a trigger frame having the following fields. The Frame Control field indicates the frame type. The Duration field contains NAV information 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 transmitting the frame. The Common Information field includes information for all assigned STAs, as shown in Figure 9. The User Information field includes information for each STA, as shown in Figure 10. The Common Information field and the User Information field provide individual resource block allocation information for each user.

[0100] By setting the trigger type in the common information field to "2," the trigger frame shown in FIG8 can be transmitted as a multi-user block ACK request (MU-BAR). When the trigger frame is a MU-BAR, the contents of the Trigger Dependent User Information field (shown in FIG10) in the trigger frame are shown in FIG11.

[0101] Figure 12 shows the contents of a Block ACK frame with the following fields. The Frame Control field indicates the frame type. 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 transmitting the frame. The Block Acknowledgement (BA) Control field indicates the Block ACK policy. The BA Information field contains the transmitted feedback.

[0102] Figure 13 depicts the contents of a Buffer Status Report (BSR) frame with the following fields. The Frame Control field indicates the frame type. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the frame's receiver. The TA field contains the address of the STA transmitting the frame. The HT Control field represents a modified version of the BSR Control subfield. The Format Indicator field indicates the format of the HT Control field. When bits B0 and B1 are set to 1, this indicates that the HT Control field uses the HE format. This field is followed by the A Control field. The A Control field 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 a modified version of the BSR Control subfield. 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 the buffer status is reported. The ACI High field indicates the access category reported in the Queue Size High field. The Scale Factor field indicates the units used for the Queue Size High and Queue Size All fields. The Queue Size High field indicates the queue size of the access category (AC) indicated in the ACI High field in units of scale factor. The Queue Size All field indicates the queue size of the AC indicated in the ACI bitmap in units of scale factor.

[0103] Figure 14 illustrates an example of a downlink (DL) multi-user (MU) transmission using orthogonal frequency division multiple access (OFDMA). The transmitter AP transmits data to its receivers 1, 2, 3, and 4 using the HE MU PPDU format. After completing the initial transmission, the AP sends a multi-user block ACK request (MU-BAR) to all receivers. The receivers then send a block ACK (BA) back to the AP. Based on the contents of the BA, the AP decides to retransmit the packet to receivers 1, 3, and 4. It contends for the channel and waits for the backoff period. The first retransmission occurs after the AP gains channel access.

[0104] Figure 15 depicts an example of an uplink (UL) multi-user (MU) transmission using OFDMA. The AP first sends a buffer status report request (BSRP) trigger frame to all transmitters 1, 2, 3, and 4. The transmitter then receives the BSRP trigger frame and sends its buffer status report (BSR) back to the AP. The AP then sends a trigger frame to all transmitters 1, 2, 3, and 4. The channel resources allocated in the trigger frame are based on the BSR received from the STA. The transmitter receives the trigger frame and starts the initial transmission by using the resource blocks allocated by the trigger frame. The multi-user transmission packet uses the HE-TB PPDU format. The AP receives the packet from the transmitter and sends a BA frame to report that the transmission was properly received.

[0105] 3.3.EDCA System

[0106] Figure 16 shows the reference model of the Enhanced DCF Channel Access (EDCA) queue system in IEEE 802.11. The system contains six transmit queues associated with four different access categories (ACs). Each AC uses the EDCA function (EDCAF) to contend for channel access for transmitting packets in its corresponding transmit queue.

[0107] 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.

[0108] The four ACs are Voice (VO), Video (VI), Best Effort (BE), and Background (BK). Each AC has an EDCA function (EDCAF) to mitigate channel contention. When multiple EDCAFs attempt to access a channel simultaneously, an internal collision avoidance mechanism is used. In the event of an internal collision, the EDCAF with the higher priority is granted channel access.

[0109] Table 1 lists the mapping of user priority (UP) to access category (AC) used in IEEE 802.11 EDCA queues. The second and third columns indicate the user priority of traffic and its corresponding designation in IEEE 802.1D. In each row, traffic is queued in the corresponding transmit queue and access category based on user priority. Priority increases from top to bottom. Traffic with higher priority is more likely to be transmitted early.

[0110] Figure 17 shows the channel access process of EDCA. As shown in the figure, it also compares the EDCA channel access when only the distributed coordination function (DCF) is used. When only DCF is used, the STA can access the channel immediately when the medium idle time exceeds the DCF inter-frame space (DIFS) time. Otherwise, it uses CSMA / CA to contend for the channel. After sensing that the channel is idle within the 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 its contention window. As shown in Figure 1, the contention window is updated. When CCA is busy, such as when the STA senses that the channel is busy, the STA pauses counting down the backoff. When the backoff countdown reaches zero, the STA starts transmitting packets.

[0111] In EDCA, each EDCAF as shown in Figure 16 can access the channel immediately, and the idle time of the medium exceeds the arbitration inter-frame space (AIFS) time of the AC to obtain channel access. It should be understood that AIFS[i] as shown in the figure represents the AIFS time of AC i. Otherwise, each EDCAF uses CSMA / CA to contend for the channel for each AC to obtain channel access. After sensing that the channel is idle within the AIFS time, it starts counting down backoff as long as the medium is idle. The number of backoff slots is randomly selected between 0 and its contention window size. As shown in Figure 1, the contention window size is updated. When CCA is busy, such as when a STA senses that the channel is busy, the STA suspends the countdown backoff. When the backoff countdown reaches zero, the STA starts transmitting packets for that AC.

[0112] It should be understood that multiple EDCAFs can contend for the channel in parallel. For example, as shown in Figure 17, EDCAFs for AC i and AC j can contend for the channel simultaneously. When an internal conflict occurs, the EDCAF with the higher priority will gain channel access, while the EDCAF with the lower priority will have its contention window doubled. When ACs are VO or VI, they can reserve a period of contention-free time (i.e., TXOP) for transmitting packets. The maximum duration of a TXOP is denoted as the TXOP limit.

[0113] Table 2 lists the default parameter settings for EDCA channel access. Each AC has its own minimum contention window and maximum contention window. AIFSN represents the AIFS duration relative to the number of backoff slots. TXOP limit represents the maximum duration of a TXOP that each AC can maintain at any one time.

[0114] 1.4. Conventional IEEE 802.11be PLCP Preamble

[0115] Figure 18 shows a conventional IEEE 802.11be preamble format with the following fields. The L-STF field represents the non-HT short training field. The L-LTF field represents the non-HT long training field. The L-SIG field represents the non-HT signal field. The RL-SIG field represents the repeated non-HT signal field. The U-SIG field represents the EHT universal field. The EHT-SIG field represents the EHT signal field. The EHT-STF field represents the EHT short training field; although it can be replaced by some other type of signal training field. The EHT-STF field represents the EHT short training field. The EHT-LTF field represents the EHT long training field.

[0116] 2. Problem Statement

[0117] The disclosed technology describes a WLAN protocol that supports TXOP sharing within a BSS. Non-AP STAs obtain TXOPs and share the TXOPs within the BSS.

[0118] Current wireless communication systems using CSMA / CA do not allow non-AP STAs to share their TXOPs with other STAs in a BSS. In previous wireless protocols, each non-AP STA had to contend for a channel individually to obtain a TXOP.

[0119] To reduce delays caused by contention time, a TXOP sharing mechanism is used to reduce contention time between multiple STAs. Any STA accessing a channel can share its TXOP within the BSS. When a TXOP is shared, multiple STAs can transmit during the shared TXOP, so each channel does not have to contend for channel access individually.

[0120] Current wireless communication systems using CSMA / CA allow the AP to schedule transmissions, such as multi-user transmissions, within its TXOP. The AP can collect buffer status from STAs and initiate uplink transmissions. When the AP collects buffer status from its associated STAs, it only obtains the amount of buffered traffic for uplink transmissions. However, it is recognized that RTA traffic has high timeliness requirements, but the current BSR framework does not reflect the QoS requirements of RTA traffic. Consequently, it is difficult for the AP to schedule transmissions within its TXOP that meet the QoS requirements of RTA traffic.

[0121] Current wireless communication systems using CSMA / CA do not allow an AP to arrange peer-to-peer (P2P) transmissions in its TXOPs. For some devices, such as AR / VR, it may be necessary to transmit large amounts of data directly from one non-AP STA to another.

[0122] The task of designing a TXOP sharing mechanism in a CSMA / CA system becomes even more challenging when considering the following scenario. RTA packets coexist, but RTA packets have timeliness requirements, where they must be delivered before their expiration time. Peer-to-peer (P2P) transmissions are allowed, and the challenge is to initiate P2P transmissions during the shared TXOP period. The design of the TXOP sharing mechanism must consider the time validity of RTA traffic and minimize RTA packet delays in wireless networks where RTA and non-RTA traffic coexist.

[0123] 3. Contributions of the Present Disclosure

[0124] The disclosed technology addresses the TXOP sharing issue when a non-AP STA obtains a TXOP and shares it within a BSS. The disclosed technology allows the non-AP STA that obtains a TXOP to send a frame to its AP indicating the start of TXOP sharing. The AP can then collect buffer status from the STA and schedule (subscribe / schedule) transmissions during the shared TXOP.

[0125] The disclosed technology addresses the problem of an AP only being able to obtain a STA's buffer size when scheduling an uplink transmission. The disclosed technology defines different types of buffer status reports (BSRs) that can carry information about reported buffered QoS requirements. The AP can schedule transmissions during a TXOP to meet the reported buffered QoS requirements.

[0126] The disclosed technology solves the problem of the AP scheduling P2P transmissions during a TXOP; since STAs are allowed to report P2P buffer status, and the AP knows to schedule P2P transmissions in the TXOP.

[0127] The disclosed technology also allows for sharing buffer status reports between APs affiliated with the same AP Multi-Link Device (MLD). When a non-AP MLD collects buffer status on a link, that information can be shared with other affiliated APs. The AP MLD can then schedule transmissions on multiple links based on the buffer status reports from the non-AP MLD.

[0128] 4. Examples

[0129] 4.1.STA Hardware Composition

[0130] Figure 19 An exemplary embodiment of station hardware exemplified herein in a multi-link device (MLD) hardware configuration is shown 10. Multiple STAs are attached to the MLD, with up to "n" stations 12a, 12b-12n, each operating on a link at a different frequency.

[0131] The hardware of each station (STA) has external input / output access 14 to applications, and an internal bus 16 connected to at least one processor (CPU, MCU, SoC or other control circuitry) 18 and memory (e.g., RAM or similar program and / or data storage) 20, the combination of which is configured to execute programming that implements the wireless communication protocol.

[0132] Each STA houses at least one modem 22 to support communications coupled to at least one RF module 24, which is connected to one or more antennas 26a, 26b, 26c-26n for communicating in one or more frequency bands, such as sub-6 GHz bands (e.g., 2.4, 5, 6 GHz) and / or at millimeter wavelengths (mmW). In at least one embodiment, the RF module 24 includes a frequency converter, an array antenna controller, and other related circuitry.

[0133] In some cases, the RF can be configured for omnidirectional antenna operation and / or can be directional to increase gain. As an example, the RF module 24 is shown as having multiple antennas to support beamforming for transmission and reception on this frequency band. In this way, STAs can transmit signals by using one or more groups of beam patterns. It should be understood that the teachings of the present disclosure can support any desired frequency band. This example shows multiple STAs grouped (clustered) in this multi-link device.

[0134] Bus 14 allows various devices, such as sensors and actuators, to be connected to the CPU. Instructions from memory 20 are executed on processor 18 to execute a program that implements the communication protocol. This program is executed to allow a STA to function as an access point (AP) station or a non-AP (regular) station (STA). It should also be understood that the 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 holder station, non-AP TXOP participant station, non-AP TXOP non-participant station, station associated with another AP, coordinator, coordinator, etc.), depending on the role it plays in the current communication environment. In addition, the protocol is configured to operate with individual stations or stations within a multi-link device (MLD) that are configured for simultaneous transmission and reception (STR MLD) or do not have this capability (non-STR MLD).

[0135] It should be understood that STAs of the present disclosure, such as those in this MLD, can be configured with multiple modems 22, each coupled to any number of RF circuits. Generally, using more RF circuits results in wider coverage of antenna beam directions. It should be understood that the number of RF circuits and antennas utilized is determined by the hardware constraints of a specific device. When a STA determines that it does not need to communicate with neighboring STAs, some of the RF circuits and antennas may be disabled.

[0136] The MLD is shown as having an internal bus 34 for communication between its processor 36 and associated memory 38, and each of the STAs 12a, 12b-12n. Additionally, the MLD has external I / O 32 to provide access to applications for the MLD, the CPU, and the RAM of the MLD management entity, which runs programs that implement the communication protocol at the MLD level. It can assign tasks to and collect information from each attached STA, and share information between attached STAs.

[0137] It should also be understood that each STA of an MLD need not have its own processor and memory. In at least one embodiment, one or more of the stations within an MLD may share a processor and memory among themselves, or share the processor and memory of the MLD circuitry. Thus, the present disclosure contemplates many possible arrangements for communicating over multiple links within an MLD.

[0138] 4.2. STA topology considered

[0139] Figure 20 An exemplary embodiment 50 of a wireless topology between MLDs is shown. To better explain the objectives of the proposed technology, the diagram sets a network scenario. It should be understood that this topology is shown only to illustrate the exemplary scenarios described herein; since the present disclosure provides a protocol that can operate in any desired topology.

[0140] A multi-link device (MLD) is a device with more than one attached STA and a media access control (MAC) service access point (SAP) to a logical link control (LLC), including a MAC data service. This example assumes the presence of ten STAs distributed across five MLDs 56, 58, 60, 62, and 64 installed in some local area or structure (e.g., a conference room) 52, exemplified by one or more windows / doors 54. STAs 1 and 1′ are attached to AP MLD1, and STAs x and x′ are attached to non-AP MLDx, where x = 2, 3, 4, or 5. STAs 2, 3, 4, and 5 are associated with STA 1 on link 1, and STAs 2′, 3′, 4′, and 5′ are associated with STA 1′ on link 2.

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

[0142] All STAs use CSMA / CA for random channel access. MLD may only enable one STA and behave as a single-link device.

[0143] 4.3. TXOP Sharing Initiated by Non-AP STA

[0144] This proposed technique allows a non-AP STA to share its TXOP with other STAs in its associated BSS. When a non-AP STA gains channel access, it notifies its associated AP to share its TXOP with other STAs in the BSS. When the STA initiates TXOP sharing, it allows the AP to accommodate the STA's request and trigger additional transmissions within the TXOP sharing time. The AP then schedules transmissions within the BSS based on the STA's buffer status during the TXOP.

[0145] Figure 21 An exemplary embodiment 70 illustrates the steps taken when a non-AP STA shares 72 its TXOP within its associated BSS.

[0146] The non-AP STA first performs 74 a clear channel assessment (CCA) to gain channel access. It then sends 76 a frame containing TXOP sharing information to its associated AP to indicate TXOP sharing. The frame may include any different types of frames configured to also contain sharing information, such as, for example, a request to send (RTS) or clear to send (CTS) or a buffer status report (BSR) frame; newly defined frames may also be used, such as Figure 55 The request trigger frame (RTF) frame shown in Figure 49A new type of BSR frame is shown in FIG. It should be noted that the RTS frame may be a MU-RTS frame. When these frames are transmitted, the receiver address of the frame may be an address negotiated between the AP and STA to indicate that the frame is used to initiate TXOP sharing. Alternatively, the AP and non-AP STAs can schedule a time period during which these frames are transmitted by default to initiate TXOP sharing. That is, during the scheduled time period, when the AP receives these frames from a non-AP STA, it knows (recognizes) that they are used to initiate TXOP sharing.

[0147] A check 78 determines whether the non-AP STA receives feedback from its associated AP before a timeout. If feedback is received, the TXOP sharing initiated by the non-AP STA is successful 80. If the RTS is sent by the non-AP STA, the feedback from the AP may include, for example, a CTS or trigger frame, or, if other frames are sent by the non-AP STA to indicate TXOP sharing, the feedback from the AP may include a trigger frame. Then, in block 82, the non-AP STA follows the schedule determined by the AP to transmit during the TXOP.

[0148] Otherwise, if it is found at block 78 that the non-AP STA does not receive feedback from its associated AP before timing out, then the TXOP sharing initiated by the non-AP STA fails 84 .

[0149] Figure 22 An exemplary embodiment 90 illustrates how an AP initiates TXOP sharing 92 within its associated BSS when the TXOP is owned by one of its associated STAs.

[0150] The AP receives a frame 94 from a non-AP STA to start TXOP sharing within the BSS. The AP may optionally send 96 a BSRP trigger frame to collect the buffer status of its associated STAs. For example, if it receives a CTS frame or RTF with the trigger type information set to BSRP, it may send BSRP. Figure 25 The process by which an AP collects buffer status including the QoS requirements of its associated STAs is explained in

[15] . Based on the buffer status of the associated STAs, the AP schedules transmissions during the TXOP 98. The purpose of scheduling is to make a best effort to meet the QoS requirements of all packets of the associated STAs, such as delay, jitter, and packet loss.

[0151] 4.4. Request trigger frame initiated by non-AP STA

[0152] The disclosed technology can allow a non-AP STA to request its associated AP to send a trigger frame.

[0153] Figure 23An exemplary embodiment 110 illustrates how a non-AP STA requests a TF from its associated AP. When a non-AP STA requests a TF from an AP 112, it first performs a Clear Channel Assessment (CCA) 114 to prepare for channel access. The non-AP STA then sends 116 an RTF to the AP. The RTF indicates the type of TF requested and contains recommended parameter settings for the TF. The RTF may carry buffer status report (BSR) information in the High Throughput (HT) Control field. The RTF indicates whether TXOP sharing is allowed.

[0154] A check 118 determines whether TXOP sharing is allowed. If sharing is allowed, then at block 120, the non-AP STA follows the trigger-based transmission scheduled by the AP 120. Otherwise, if sharing is not allowed, then at block 122, the non-AP STA arranges its own transmission during its TXOP after completing the RTF transmission and its requested transmission.

[0155] It should be understood that the TXOP sharing indication field and the TXOP sharing duration field in the RTF may be optional. If these two fields are not included in the RTF or there is no other field in the RTF to indicate TXOP sharing, TXOP sharing is not allowed by default.

[0156] The TXOP Sharing Indication field in the RTF may be replaced by setting the Receiver Address (RA) field to a specific address negotiated with the AP indicating that TXOP sharing is allowed.

[0157] The TXOP sharing time field in the RTF can be replaced by setting the frame duration of the RTF.

[0158] Figure 24 An exemplary embodiment 130 is shown of an AP's reaction upon receiving 132 an RTF from its associated non-AP STA.

[0159] When an AP STA receives an RTF 132 from its associated STA, it generates 134 a TF of the type indicated in the RTF. The AP sets parameters in the TF according to the recommendations of the RTF to allocate channel resources for transmissions following the TF. The AP may add and adjust parameters in the TF. If the RTF carries BSR information, channel resources should be allocated to meet the BSR information carried by the RTF 134.

[0160] 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," and then TXOP sharing is allowed. After the AP completes transmitting the TF and the requested transmission, if the conditions for allowing sharing are met, the transmission is continued during the TXOP sharing time indicated in the RTF 138. Otherwise, if sharing is not allowed, the AP only sends the TF 140.

[0161] It should be understood that the TXOP sharing indication field and the TXOP sharing duration field in the RTF may be optional. If these two fields are not included in the RTF, or there is no other field in the RTF indicating TXOP sharing, TXOP sharing is not allowed by default.

[0162] In at least one embodiment, the TXOP Sharing Indication field in the RTF may be replaced by setting the RA field to a specific address negotiated with the AP indicating that TXOP sharing is permitted. In at least one embodiment, the TXOP Sharing Time field in the RTF may be replaced by setting the frame duration of the RTF.

[0163] 4.5. Buffer Status Collection

[0164] This section explains how the AP collects buffer status for its associated STAs. As mentioned in the previous section, it is important for the AP to collect buffer status, including the QoS requirements of its associated STAs, during the TXOP sharing time. Based on the buffer status of its associated STAs, the AP can schedule transmissions during the TXOP sharing time to meet the QoS requirements of all packets of the STAs.

[0165] It is assumed that all packets have an expiration time and that packets should be transmitted before their respective expiration times. RTA packets may have a short expiration time, while non-RTA packets generally have a longer expiration time. Each STA knows the expiration time of each packet in its buffer. It should be understood that this buffer status collection process can be used to schedule transmissions during the AP's TXOP time.

[0166] Figure 25 An exemplary embodiment 150 illustrates how an AP collects the buffer status of its associated STAs. When the AP collects the buffer status of its associated STAs 152, it sends 154 BSRP frames to these STAs. It may then receive different types of buffer status reports from these STAs. At block 156, the type of buffer status report is checked.

[0167] It should be understood that in addition to the BSR frame defined in IEEE 802.11ax, the disclosed technology also defines two other types of BSR frames: P2P-BSR frames and RTA-BSR frames. P2P-BSR frames are used to report buffering for point-to-point transmissions. RTA-BSR frames are used to report the buffering status of RTA packets with low latency requirements. RTA-BSR frames include buffer expiration times, meaning that reported buffered packets must be transmitted before their respective expiration times to meet latency requirements. Details of P2P-BSR and RTA-BSR frames will be explained later in Section 4.7. Due to the use of different types of BSR, an AP may receive P2P-BSR frames 158 from some STAs, RTA-BSR frames 160 from some STAs, and BSR frames 162 defined in IEEE 802.11ax from other STAs.

[0168] Figure 26 An exemplary embodiment 170 illustrates how a STA reports its buffer status to an AP. When a non-AP STA receives a BSRP from its associated AP, it needs to report its buffer status 172. The STA can first decide 174 which type of BSR to report to the AP. The STA can decide to send a P2P-BSR frame 176, which indicates that a buffer exists for P2P transmissions. The STA can decide to send an RTA-BSR frame 178, which indicates that a buffer exists for RTA packets that need to be transmitted before their expiration time. The STA can decide to send a BSR frame 180 defined in IEEE 802.11ax, which indicates the STA's general buffer status.

[0169] 4.6. Examples

[0170] 4.6.1. Triggering frames via non-AP STA requests

[0171] This section provides several examples to explain how a non-AP STA can request a trigger frame from its associated AP. The network topology of these examples is as follows: Figure 20 As shown, however, in this example, only transmission on link 1 is considered. This section assumes that RTF does not have the TXOP sharing indication field and the TXOP sharing time field.

[0172] Figure 27An exemplary embodiment 190 of a non-AP STA requesting a P2P trigger frame by sending an RTF frame to an AP is shown. As shown, all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel together with backoffs 202, 204, 206, 208, and 210, and STA4 gains channel access 212. It should be understood that this is merely an example for illustrating operation, and it will be understood that in this and subsequent examples, any number of stations may contend for the channel.

[0173] STA4 then sends an RTF frame 214 to the AP to request a P2P trigger frame to initiate a P2P transmission from STA4 to STA5. Figure 23 The process is explained in 116 of . Figure 55 The format of the RTF frame is explained in [2]. In response, the AP sends a P2P trigger frame 216 to its associated STA4, initiating a P2P transfer from STA4 to STA5 as requested by the RTF. Since the RTF indicates the use of the entire channel for P2P transfer, the AP allocates the entire channel for this P2P transfer. STA4 transmits data 218, and STA5 responds with a block acknowledgment (BA) 220.

[0174] Figure 28 An exemplary embodiment 230 is shown in which a non-AP STA requests a P2P trigger frame from an AP and the AP then sends multiple P2P TFs.

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

[0176] When completing a data PPDU after a trigger frame, if the AP sends additional P2P-TFs 232, the STA can continue to transmit more PPDUs 234, to which STA5 responds with a BA 236. The AP can trigger as many data PPDUs as possible until the duration of the reserved TXOP (in this case, STA4 reserves the TXOP). Therefore, in the figure, after the AP sends the first P2P-TF and STA4 completes the P2P transmission, the AP can send another P2P-TF during the TXOP duration 213 reserved by STA4 to initiate another P2P transmission for STA4, etc.

[0177] Figure 29 An exemplary embodiment 250 is shown in which a P2P-TF allocates resources (all or part of the available BW) given to P2P data transmission for a specific time period.

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

[0179] In this example, STA 4 can use these RUs for the time indicated in the P2P-TF. After the AP sends the P2P-TF, STA 4 can use the resources allocated by the P2P-TF to transmit multiple P2P packets to STA 5 during its TXOP, and the transmission of data 252 and the reception of BA 254 are also shown here.

[0180] Figure 30 An exemplary embodiment 270 illustrates a non-AP STA requesting a (basic) trigger frame by sending an RTF frame to an AP.

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

[0182] Then, in this example, STA4 sends an RTF frame 272 to the AP to request a trigger frame to initiate a trigger-based UL transmission. The RTF may also carry BSR information from STA4. Figure 23 This process is explained in block 116 of FIG. Figure 55The format of the RTF frame is described. The AP then sends a trigger frame 274 to its associated STA4 to initiate an UL transmission for the data reported by STA4's BSR. STA4 indicates in the RTF that it is only requesting RU3 for UL transmission, and that the remaining RUs (such as RU1, RU2, and RU4) are available for UL transmission by other STAs. In the example shown, STA4 is seen transmitting a preamble 284, followed by data on RU3 286 being transmitted to STA1. The other stations are seen using their allocated RUs, with STA2 sending a preamble 276 followed by data 278 on RU1, STA3 sending a preamble 280 followed by data 282 on RU2, and STA5 sending a preamble 288 followed by data 290 on RU4. Following these transmissions, a multi-user (MU) block acknowledgement (BA) 292 is shown being sent from the AP to each of the participating stations.

[0183] Figure 31 An exemplary embodiment 310 shows a non-AP STA requesting a basic trigger frame from the AP to use all RUs. Thus, unlike the previous shared TXOP example, in this case, STA4 decides to request use of all channels in its trigger frame; in response, the AP sends a trigger frame 274 allocating all RUs to STA4 (e.g., in the case of SU-MIMO).

[0184] As shown in the previous figure, all STAs (STA1 192, STA2 194, STA3 196, STA4 198 and STA5 200) contend for the channel together by using backoff 202, 204, 206, 208 and 210, and STA4 obtains channel access 212, sending RTF 272 with BSRP.

[0185] In the illustrated example, in response to a STA's request, the AP sends a TF 274 to allocate all RUs to the 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 and allocating all RUs to STA4 for uplink transmission. STA4 can be seen transmitting a preamble 312 and data 314 across all its allocated RUs, and the AP then generates an MU-BA (e.g., this frame could also be an ACK or BA frame) 316.

[0186] Figure 32 An exemplary embodiment 330 is shown where a non-AP STA requests a Basic Trigger Frame from an AP and the AP responds by sending one TF for multiple uplink transmissions.

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

[0188] In this example, when the data PPDU is completed after the trigger frame, if the AP sends additional TFs, the STA can continue to transmit more PPDUs. The AP can trigger as many data PPDUs as possible within the TXOP duration reserved by the STA (in this case, STA4). In this specific example, the AP sends another TF 332 and allocates RUs to different STAs. Each STA sends preambles 334, 338, 342, and 346 in the allocated RUs, followed by data 336, 340, 344, and 348. The AP then responds with MU-BA 349.

[0189] Figure 33 An exemplary embodiment 350 illustrates a non-AP STA requesting a Basic Trigger frame from an AP, the AP sending a single TF for multiple UL transmissions, and the TF setting RU allocations for all UL transmissions. The TF may also allocate resources (all or part of the available bandwidth) for UL data transmission to STA4 for a specific period. STA4 may use these RUs for the times indicated in the TF. This diagram is presented by way of example and not limitation.

[0190] As shown in the previous figure, it is assumed that all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contend for the channel together by using backoffs 202, 204, 206, 208, and 210, and STA4 obtains channel access 212, reserves a TXOP 213, sends an RTF 272 for using all RUs, receives a TF 274 from the AP, and transmits a preamble 312 and data 314 using all RUs, followed by receiving a MU-BA 352. STA4 is then seen sending additional data, illustrated as a preamble 354, and data 356, illustrated as spanning all RUs, and then receiving a MU-BA 358.

[0191] 4.6.2. TXOP Sharing Initiated by Non-AP STA

[0192] This section provides several examples to explain how non-AP STAs can gain channel access and share their TXOPs within their BSS. The example network topology is as follows: Figure 20 As shown, although in this case only transmissions on link 1 are considered.

[0193] Figure 34 An exemplary embodiment 370 is shown in which a non-AP STA shares its TXOP within its associated BSS by sending an RTF frame to the AP.

[0194] 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 by using backoffs 202, 204, 206, 208 and 210, and STA4 gains channel access 212 and reserves TXOP 213.

[0195] STA4 sends an RTF frame 371 to the AP to initiate TXOP sharing. Figure 21 This process is explained in block 76 of FIG. Figure 55 Describes the format of the RTF frame. Then, as in Figure 22 As explained in blocks 94 and 96 of FIG, the AP may perform an optional information collection step 372 in which it sends a BSRP trigger frame 374 to its associated STAs (e.g., STA2-STA5) to collect their buffer status 376, 378, 380, and 382. Figure 21 As explained in 98 of , based on the buffer status of the STA, the AP schedules transmissions during the TXOP. In this example, the AP sends a trigger frame (TF) 384 to initiate a multi-user uplink transmission. STA2-STA5 transmit their packets after they receive the TF from the AP. Figure 21 This process is explained in FIG82. The figure depicts the transmission of preambles 386, 390, 394, and 398 in their respective RUs, followed by the transmission of data 388, 392, 396, and 400. The AP responds with MU-BA 402 at the end of these transmissions. It should be understood that if the AP has already obtained the most recent buffer status of the STA, it does not need to transmit a BSRP to collect the buffer status of the STA.

[0196] Figure 35 An exemplary embodiment 390 is shown in which a non-AP STA sends an RTS / CTS to first reserve a TXOP and then share its TXOP within its associated BSS.

[0197] 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 together by using backoffs 202, 204, 206, 208, and 210.

[0198] STA4 obtains channel access 392 and obtains TXOP 393. STA4 then sends an RTS frame 394 to the AP and in response receives a CTS frame 396 from the AP to reserve the TXOP duration 393. After reserving the TXOP, STA4 may send a frame, such as RTF 398 as shown, to share its TXOP within the BSS. Then, as in Figure 34 As explained in

[0014] , the AP arranges transmissions during a shared TXOP. It should be noted that if the AP already has the buffer status of the STA, it does not have to send a BSRP to collect the buffer status of the STA.

[0199] The remainder of the figure depicts the same set of buffer states and initiating multi-user uplink transmissions as shown in the previous figure.

[0200] Figure 36 An exemplary embodiment 410 is shown in which a non-AP STA shares its TXOP within its associated BSS by sending a MU-BSR frame to the AP.

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

[0202] STA2 and STA4 simultaneously obtain channel access 412 for a shared TXOP 414. STA2 and STA4 each send a MU-BSR packet within a preamble 416 and 420 to the AP to initiate TXOP sharing. Figure 21 This process is explained in block 76 of Figure 58 The preamble of the MU-BSR is explained in . There is a TXOP sharing indication in the preamble, such as a one-bit sharing field, to indicate that the MU-BSR is used to initiate TXOP sharing.

[0203] The RU allocation used to carry the BSR frame in the MU-BSR can be prefixed through negotiation between the AP and STAs. Therefore, it is not necessary to indicate the RU allocation of the BSR frame in the preamble. For example, a MU-BSR transmitted on the 20 MHz band to initiate TXOP sharing can use random 26-tone resource units (RUs) to carry the BSR frame. As shown in the example, STA2 uses RUy 418 and STA4 uses RUx 422 to carry their respective BSR frames to AP STA1.

[0204] The benefit 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, their MU-BSR packets can be received by the AP without error. This is because the content of their preamble is prefixed with the same (repeated) information. In addition, the BSR frame is carried by different RUs, where the AP can therefore decode all possible RUs, such as RUx and RUy, to receive the BSR frame. The BSR frame should probably be carried with the same PPDU format, the same packet length, the same bit rate (for example, 6Mb / s rate), and the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value.

[0205] like Figure 21 As explained in blocks 78 and 80 of FIG, if the non-AP STA receives a trigger frame (TF) from the AP before the timeout, TXOP sharing is successful. In this example, the AP sends a trigger frame (TF) 424 to initiate multi-user uplink transmission based on the buffer status of STA2 and STA4. STA2 and STA4 transmit their preambles 426 and 430 and packets 428 and 432 after they receive the TF from the AP. Figure 21 This process is explained in block 82 of . After packet transmission, the AP sends a MU-BA 434 to acknowledge packet reception.

[0206] It should be noted that Figure 36 This is just an example of multiple STAs gaining channel access simultaneously; although only one STA may gain channel access and send an MU-BSR frame.

[0207] Figure 37 An exemplary embodiment 450 is shown in which a non-AP STA shares its TXOP within its associated BSS by sending a MU-BSR packet to the AP.

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

[0209] Likewise, in this example, STA2 and STA4 simultaneously obtain channel access 452 for a shared TXOP 454 and send their preambles 456 and 460 to the AP STA1. However, in this example, both STAs use the same RU to carry BSR frames 458 and 462 in MU-BSR packets to the AP to initiate TXOP sharing. Figure 21 The process is explained in 76 of Figure 58 The preamble of the MU-BSR is explained in

[15] . There is a one-bit TXOP sharing indication in the preamble to indicate that the MU-BSR is used to initiate TXOP sharing.

[0210] The RU allocation for carrying BSR frames in MU-BSR can be prefixed by negotiation between the AP and STA. Therefore, it is not necessary to indicate the resource unit (RU) allocation of the BSR frame in the preamble. For example, the MU-BSR for initiating TXOP sharing transmitted on the 20MHz band can use the random 26-tone RU defined in IEEE 802.11ax to carry the BSR frame. As shown in the example, both STAs use RUx to carry their BSR frames. The BSR frame should probably be carried with the same PPDU format, the same packet length, the same bit rate (e.g., 6Mb / s rate), and the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value as their setting in the negotiation.

[0211] The benefit of using MU-BSR is that when multiple STAs (such as STA3 and STA4 shown in the figure) gain channel access at the same time, the AP can receive the preamble of their MU-BSR packets without error. This is because the content of their preambles provides a set of repeated information as a prefix. Therefore, 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 determine the start of TXOP sharing. Then, the AP is shown to send BSRP 464 by sending a BSRP trigger frame and arranging transmissions during the TXOP to collect BSRs 466, 468, 470, and 472 from the STAs.

[0212] In this example, after collecting the buffer status information, the AP sends a TF 474 to initiate a multi-user UL transmission after collecting the BSR from the STA. The STA is seen transmitting its preamble 476, 480, 484, and 486 to the AP STA1 via different RUs, followed by data 478, 482, 486, and 488, after which the AP responds with a MU-BA 490.

[0213] From this we can see that Figure 37First, it indicates that multiple STAs obtain channel access at the same time; however, it is possible that only one STA obtains channel access and sends an MU-BSR.

[0214] Figure 38 An exemplary embodiment 510 is shown in which a non-AP STA shares its TXOP within its associated BSS by sending a CTS frame to an AP.

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

[0216] STA3 and STA4 simultaneously obtain channel access 512 for TXOP 514 and both send CTS frames 516 and 518 to the AP to initiate sharing of TXOP 514. Figure 21 This process is described in block 76 of FIG. When STAs transmit CTS frames, they may set the RA field of the CTS frames to the same specific address (prefixed with repetition information and negotiated with the AP) to indicate the start of TXOP sharing. These CTS frames may also be carried in the same PPDU format (e.g., non-HT or non-HT repeated PPDU), at a fixed rate (e.g., 6 Mbps), and with the TXVECTOR parameter SCRAMBLER_INITIAL_VALUE set to the same value.

[0217] The benefit of using CTS frames is that when multiple STAs (such as STA3 and STA4 in the figure) gain channel access simultaneously, the AP can receive them correctly because the CTS frames have the same content. This is because their preambles contain information that overlaps with that in the CTS frames.

[0218] When the AP receives a CTS indicating the start of TXOP sharing, it can determine that one STA has obtained the TXOP and is sharing the TXOP within the BSS. The AP is illustrated as sending a BSRP trigger frame 522 and collecting BSRs 524, 526, 528, and 530, optionally collecting buffer status 520, and the AP arranges transmissions during the TXOP. Here, in this example, after collecting buffer information, the AP sends TF 532 to initiate the multi-user UL transmission seen, and the STA sends preambles 534, 538, 542, and 546, and then sends data 536, 540, 544, and 548 on different RUs to the AP STA1, which receives the data and transmits MU-BA 549 to confirm these transmissions.

[0219] It should be noted that Figure 38 Only an example is depicted in which multiple STAs simultaneously obtain channel access; however, only one STA may obtain channel access and transmit a CTS frame.

[0220] Figure 39 An exemplary embodiment 550 is shown in which a non-AP STA shares its TXOP within its associated BSS by sending a BSR frame to the AP.

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

[0222] STA4 obtains channel access 552 and sends a BSR frame 556 to the AP to initiate sharing of TXOP 554. Figure 21 This process is explained in block 76 of FIG. When a STA transmits a BSR frame, it may set the RA field of the BSR frame to the specific address that was prefixed and negotiated with the AP to indicate the start of TXOP sharing. When the AP receives the BSR frame from STA4 indicating the start of TXOP sharing, the AP may determine which STA to obtain and share the TXOP within the BSS.

[0223] Here we see that the AP optionally collects buffer status information from other STAs 558. The AP sends a BSRP trigger frame 560 to STA2, STA3, and STA5, and these STAs respond with BSRs 562, 564, and 566. The AP can then optionally collect BSRs from other STAs by sending BSRP trigger frames and arrange transmissions during the TXOP.

[0224] After collecting BSRs from the STAs, the AP sends a TF 568, initiating a multi-user UL transmission, represented by preambles 570, 574, 578, and 582. Data 572, 576, 580, and 584 are then sent to the AP STA 1. Upon receiving the data, the AP STA 1 confirms the transmission using MU-BA 586. Consequently, the STAs transmit their packets over the RUs allocated by the P2P TF. As shown in the figure, UL OFDMA transmissions from STA2 572 and STA3 576 are transmitted on RU1 and RU2, respectively, while STA4's P2P transmission is transmitted 578 to STA1 on RU3.

[0225] 4.6.3. Enable P2P transfer

[0226] This section provides several examples to explain how a non-AP STA can share its TXOP within its BSS and initiate peer-to-peer (P2P) transmissions during the shared TXOP. The network topologies of these examples are as follows: Figure 20 As shown, although only transmissions on link 1 are considered in this example.

[0227] Figure 40 An exemplary embodiment 590 is shown in which a non-AP STA initiates a P2P transmission by sending an RTF frame.

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

[0229] When STA4 obtains channel access, it sends an RTF frame 596 to request a P2P trigger frame from the AP. The AP then sends a P2P trigger frame 598 to initiate a P2P transmission 600 from STA4 to STA5.

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

[0231] Figure 41 An exemplary embodiment 610 is shown in which a non-AP STA initiates a P2P transmission by sending an RTF frame.

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

[0233] When STA4 obtains channel access 612 for TXOP 614, 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 is acknowledged by STA5 with a BA 622. In this example, the TXOP sharing indication in the RTF is set to the second state (e.g., "1") indicating that STA4 shares the TXOP within the BSS.

[0234] After the P2P transmission ends, the AP continues to arrange transmissions during the TXOP, as shown below: the AP sends a TF 624 to initiate a multi-user uplink transmission through other stations, represented as preambles 626, 630, 634 and 638 and subsequent data 628, 632, 636 and 640 on different RUs to STA1, and the AP sends an acknowledgement with a BA 642 after STA1 receives the transmission.

[0235] Figure 42 An exemplary embodiment 650 is shown in which a non-AP STA shares its TXOP within its associated BSS and requests P2P transmission during the shared TXOP by sending a P2P-BSR frame.

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

[0237] STA4 obtains channel access 652 and sends a P2P-BSR frame 656 to the AP to initiate sharing of TXOP 654. Figure 49 Describes the format of the P2P-BSR frame and addresses Figure 21 The P2P-BSR process is explained in block 76. When a STA transmits a P2P-BSR frame, it may set the RA field of the frame to the specific address that was prefixed and negotiated with the AP to indicate the start of TXOP sharing.

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

[0239] STAs transmit their packets over the RUs allocated by the P2P TF. As shown in the figure, STA2 and STA3's UL OFDMA transmissions are transmitted on RU1 and RU2, respectively. STA4's P2P transmission is transmitted to STA5 via RU3. The AP is then seen sending preamble 682 with BAs 684 and 686, while STA5 is seen sending preamble 688 and BA 689.

[0240] Figure 43 An exemplary embodiment 690 is shown in which a non-AP STA shares its TXOP within its associated BSS and requests P2P transmission during the shared TXOP by sending a MU-BSR packet.

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

[0242] In this example, STA2 and STA4 simultaneously obtain channel access 692. STA2 and STA4 then start using TXOP 694 by sending preambles 696 and 700 with MU-BSR packets 698 and 702 to the AP to initiate TXOP sharing. Figure 21 The process is explained in 76 of Figure 58 The preamble of the MU-BSR is explained in . There is a TXOP sharing indication (eg, one bit) in the preamble to indicate that the MU-BSR is used to initiate TXOP sharing.

[0243] The RU allocation used to carry the BSR frame in the MU-BSR can be prefixed by negotiation between the AP and STA. Therefore, it is not necessary to indicate the RU allocation of the BSR in the preamble. For example, the MU-BSR transmitted on the 20MHz band to initiate TXOP sharing can use random 26-tone resource units (RUs) to carry the BSR frame. As shown in the example, STA2 uses RUy to carry its BSR frame to the AP, while STA4 uses RUx to carry its P2P-BSR frame to STA5's peer station.

[0244] The benefit of using MU-BSR is that when multiple STAs (for example, STA2 and STA4 in the figure) gain channel access simultaneously, the AP can receive their MU-BSR packets without error. This is because their preambles carry prefixes and contain the same shared information. Similarly, BSR frames are carried on different RUs.

[0245] The STA can determine the type of BSR frame carried by the RU. As shown in the figure, STA2 transmits the BSR frame defined in IEEE802.11ax via RUy, and STA4 transmits the P2P BSR frame via RUx. The AP can decode different types of BSR frames on different RUs with prefixes.

[0246] If the non-AP STA receives a trigger frame from the AP before the timeout, Figure 21 78 and 80, TXOP sharing is successful. In this example, the AP sends a P2P TF 704 to initiate uplink OFDMA transmissions 706 and 708 on RU1 based on the buffer status of STA2, and sends P2P transmissions 710, 712 on RU3 between STA4 and STA5 based on the buffer status of STA4. STA2 and STA4 transmit their packets after they receive the P2P-TF from the AP. Figure 21 This process is explained in block 82 of . The AP is then seen sending a BA transmission 716 with a preamble 714 to STA2 on RU1, and STA5 is seen sending a BA transmission 720 with a preamble 718 to STA4.

[0247] Figure 44 An exemplary embodiment 730 is shown in which a non-AP STA shares its TXOP within its associated BSS and requests P2P transmission during the shared TXOP by sending a MU-BSR packet.

[0248] 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 together by using backoffs 202, 204, 206, 208, and 210.

[0249] In this example, STA3 and STA4 simultaneously obtain channel access 732. STA3 and STA4 then send MU-BSR packets 738 and 742 with preambles 736 and 740 to the AP to initiate sharing of TXOP 734. Figure 21 The process is explained in 76 of Figure 58 The preamble used in 736 and 740 of the MU-BSR is explained in

[0066] . A one-bit TXOP sharing indication is present in the preamble to indicate that the MU-BSR is used to initiate TXOP sharing.

[0250] The RU allocation used to carry the BSR frame in the MU-BSR can be prefixed through negotiation between the AP and STAs. Therefore, it is not necessary to indicate the resource unit (RU) allocation for the BSR in the preamble. For example, the MU-BSR transmitted on the 20 MHz band to initiate TXOP sharing can use the random 26-tone RU defined in IEEE 802.11ax to carry the BSR frame. As shown in the example, STA3 and STA4 use RUx 738 and 742 to carry the BSR frame.

[0251] The benefit of using MU-BSR is that when multiple STAs (such as STA3 and STA4 shown in the figure) gain channel access simultaneously, the preambles 736 and 740 of their MU-BSR packets can be received by the AP without error. This is because the content of their preambles provides 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 know the start of TXOP sharing.

[0252] Then, in this example, the AP is shown collecting BSRs from the STAs by sending a BSRP trigger frame 744 and arranging transmissions during the TXOP. Figure 26 As explained in

[15] , the STA can decide which type of BSR frame to send back. In the example shown, 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 as follows: Figure 49 shown.

[0253] As in Figure 25 As explained in

[15] , although the type of BSR frame may be different, the AP collects buffer status from the STAs. Based on the BSR, the AP sends a P2P TF frame 754 to initiate a multi-user transmission, which includes UL transmissions 756, 758, 760, and 762 of STA2 and STA3, and P2P transmissions 764, 766, 774, and 776 between STA4 and STA5. RU allocation is indicated by the P2P TF. UL transmissions are transmitted using RU1 and RU2, and P2P transmissions are transmitted using RU3. It is also seen that the AP sends block acknowledgments (BAs) 770 and 772 with preamble 768 to STA2 and STA3, respectively; and STA5 sends a BA 776 with preamble 774 to STA4.

[0254] Figure 45An exemplary embodiment 790 is shown in which a non-AP STA shares its TXOP within its associated BSS and requests P2P transmission during the shared TXOP by sending a CTS frame.

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

[0256] STA3 and STA4 simultaneously obtain channel access 792. Then, STA3 and STA4 send CTS frames 796 and 798 to the AP to initiate sharing of TXOP 794. Figure 21 This process is explained in block 76 of Since the content of the CTS frame is the same, the AP can still successfully decode the CTS.

[0257] The AP may then collect BSRs from the STAs by sending a BSRP trigger frame 800 and collect BSRs 802, 804, 806, and 808 and then arrange transmissions for the TXOP. Figure 26 As explained in

[15] , the STA can decide which type of BSR frame to send back. Here, as shown in the example, STA2 and STA5 send BSR frames 802 and 808 defined in IEEE 802.11ax. STA3 sends an RTA-BSR frame 804, and STA4 sends a P2P BSR frame 806. The formats of the RTA-BSR frame and the P2P-BSR frame are as follows: Figure 49 shown.

[0258] As in Figure 25 As explained in

[15] , although the BSR frame type is different, the AP collects buffer status from the STAs. Based on the BSR, the AP arranges transmissions in a shared TXOP. The AP sends a P2P TF frame 810 to initiate a multi-user transmission, which includes UL transmissions 814 and 818 with preambles 812 and 816 for STA2 and STA3, and a P2P transmission 822 with preamble 820 from STA4 to STA5. RU allocation is indicated by the P2P TF. UL transmissions are transmitted using RU1 and RU2, and P2P transmissions are transmitted using RU3. Block ACKs 826 and 828 are then sent from the AP to STA2 and STA3, respectively, following preamble 824, while STA5 sends a BA 832 to STA4 following its preamble 830.

[0259] Figures 46A and 46BAn exemplary embodiment 850 is shown in which a non-AP STA shares its TXOP within its associated BSS and requests P2P transmissions during the shared TXOP by sending a CTS frame. This example explains how an AP can arrange transmissions during a shared TXOP.

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

[0261] exist Figure 46A In FIG, STA4 is seen to obtain channel access 852 and send an RTF frame 856 to the AP to request a P2P trigger frame and initiate a shared TXOP 854. Figure 23 This process is explained in block 116 of FIG.

[0262] The AP sends a P2P TF frame 858 to initiate a P2P transmission 860 from STA4 to STA5. STA5 Figure 24 Respond to it with BA 862 as explained in block 134 of FIG.

[0263] Because as in Figure 24 As explained in block 138 of FIGURE 1, the TXOP is shared by STA4, so after the P2P transmission ends, the AP initiates downlink multi-user transmissions 866, 868, and 870 following the preamble 864 for STA2, STA3, and STA5. This may be due to different reasons, such as because the downlink transmission has a shorter expiration time than the UL transmission of the RTA packet requested by the STA.

[0264] exist Figure 46B At least one embodiment of embedding the buffer status in the BA frame is depicted in FIG. STA2 and STA3 are seen sending BA frames 874 and 878 to the AP after the preambles 872 and 876. The figure shows an example of a P2P-BSR embedded in a BA frame 882 after the preamble 880. The format of the BA+P2P-BSR frame is as follows: 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 defined in IEEE 802.11ax.

[0265] Based on the latest buffer status update from STA5, the AP schedules another P2P transmission between STA4 and STA5, as the P2P transmission has the shortest expiration time. After the P2P transmission between STA5 and STA4 completes, the AP sends a TF frame 884 to initiate an uplink multi-user transmission 886 for the buffer reported by the RTA-BSR frames from STA2, STA3, and STA5. STA4 then responds with a BA 888. Before the TXOP ends, the AP sends a TF 890 and observes that STA2, STA3, and STA5 upload data 894, 898, and 902 following preambles 892, 896, and 900. The AP then responds with a MU-BA 904. The AP can also send a CF-End frame 906, defined in IEEE 802.11, to end the current TXOP.

[0266] 6.6.4. Example of AP Sharing TXOP

[0267] This section provides information about how the AP can also Figure 25 Although only transmissions on Link 1 are considered in this example, Figure 20 The network topology for these examples is represented in .

[0268] Figures 47A to 47C An exemplary embodiment 910 is shown where an AP schedules transmissions during its owned TXOP based on buffer status collected from STAs.

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

[0270] As shown, the AP obtains channel access 912 for TXOP 914 and sends BSRP 916 to collect BSRs from STAs. Figure 26 As explained in

[0066] , the STA can decide which type of BSR frame to send back. Here, as shown in the example, STA2, STA3, and STA5 send BSR frames 918, 920, and 924, and STA4 sends a P2P BSR frame 922.

[0271] As in Figure 25As explained in

[15] , despite the different types of BSR frames, the AP collects buffer status from the STAs. Based on the BSR, the AP arranges transmissions in the TXOP. A P2P transmission 927 is performed, wherein the AP sends a P2P TF frame 926 to first initiate a P2P transmission 928 from STA4 to STA5, to which STA5 responds with a BA 930. Preferably, P2P transmissions are performed first because they have the shortest expiration time according to the BSR from the STAs. The AP then initiates MU DL 933 with transmissions 934, 936, and 938 for STA2, STA3, and STA5 following preamble 932. This may be due to the downlink transmission having a shorter expiration time than the UL transmission of the RTA packet requested by the STA. These stations then respond with BAs 942, 946, and 950 following the associated preambles 940, 944, and 948.

[0272] Return to Figure 47B , after the multi-user downlink transmission is completed, the AP sends a TF frame 952 to initiate an uplink multi-user transmission 951 for the buffer reported by the BSR frames of STA2, STA3, and STA5. In at least one embodiment, the buffer status is embedded in the data frame. Data is uploaded 956, 960, and 964, and the preceding preambles 954, 958, and 962 are seen from STA2, STA3, and STA5 to the AP. The figure also shows an example of embedding a P2P-BSR 964 in the data frame of STA5 and transmitting it through RU3. Figure 51 The format of the data+P2P-BSR frame is explained in

[15] . 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 defined in IEEE 802.11ax. The AP responds to these receptions by transmitting MUBA 966.

[0273] Based on the latest buffer status update from STA5, the AP schedules multi-user transmission (uplink + P2P) 967. Since this P2P transmission has the shortest expiration time, multi-user transmission (uplink + P2P) 967 includes a P2P transmission 980 with a preamble 978 from STA5 to STA4. In this case, the AP sends a P2P TF 968 to arrange a multi-purpose transmission for both uplink and P2P transmissions. Uplink transmissions 972 and 976 from STA2 and STA3 use RU1 and RU2 and are seen with preambles 970 and 974. P2P transmission 980 from STA5 to STA4 uses RU3 and is preambled with preamble 978. In response to STA2 and STA3, the AP sends BAs 984 and 986 following preamble 982. STA4 is also seen sending a BA 990 to STA5 following preamble 988.

[0274] continue Figure 47C , the AP is seen sending another P2P TF 992 to arrange another multi-user transmission 991 for both downlink and P2P transmission.

[0275] It is seen that STA5 transmits the preamble 1000 and data 1002 to STA4 through RU3.

[0276] The AP is seen transmitting preamble 994 and data from the AP to STA2 and STA3 on RU1 and RU2 for downlink transmissions 996 and 998, respectively. RU3 is used for P2P transmission. It should be understood that the AP can have an AID pointing to itself. The AP can then use this AID to set the AID12 field to indicate that the AP will use the channel resources indicated in the corresponding user information field of the P2P trigger frame for downlink transmission. The P2P receiver ID in the user information field indicates the receiver of the downlink transmission. When multi-user downlink transmission and P2P transmission coexist, each STA can only assume one of the following roles: (a) transmitter of P2P transmission; (b) receiver of P2P transmission; (c) receiver of downlink transmission; or (c) the AP can send a CF-End frame defined in IEEE802.11 to end the current TXOP. The diagram ends with block acknowledgements (BAs) 1004, 1006, 1008, and 1010 being sent from STA2 and STA3 to the AP, and 1012 and 1014 from STA4 to STA5.

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

[0278] 4.6.5. Example of non-AP MLD shared TXOP in a multi-link scenario

[0279] This section provides information on how (a) non-AP MLD shares TXOPs within a BSS on a link and (b) AP MLD shares TXOPs within a BSS on a link. Figure 25 Examples of collecting buffer states to arrange transmissions on multiple links as explained in

[15] . The network topology for these examples is as follows Figure 20 TXOP sharing on link 1 and packet transmission arranged by STA1 (AP) during the shared TXOP on link 1 may be similar to Figure 46A and Figure 46B shown.

[0280] Figures 48A and 48B An exemplary embodiment 1030 of an AP MLD capable of both transmitting and receiving (STR) thereby communicating with a non-AP MLD which may be non-STR is shown. Figure 48B The communication indicated in the marked part is Figure 48A Those communications shown in the labeled portions occur in parallel (rather than sequentially). The labeled portions are those associated with the connection structure "DD" depicted in the figure.

[0281] As shown in the previous figure, Figure 48A Region 1032 depicts all STAs (STA1 192, STA2 194, STA3 196, STA4 198, and STA5 200) contending for the channel together by using backoffs 202, 204, 206, 208, and 210. Figure 48B In the 1076 area, corresponding communication lines 192', 194', 196', 198' and 200' for STAs STA1' to STA5' are seen.

[0282] STA4 obtains channel access 1033 and sends a CTS 1036 to the AP for TXOP 1034 .

[0283] STA1 collects the buffer status on link 1 by sending BSRP 1038 and receiving various BSR responses 1040, 1042, 1044, and 1046. This buffer status information can also be used to arrange transmissions on link 2, as will be described below.

[0284] The AP sends a P2P TF 1048 , and performs a P2P transmission 1050 from STA4 to STA5 using a corresponding BA 1052 .

[0285] Now refer to Figure 48A and Figure 48B In the parallel part, when STA1 receives RTA BSR 1040, 1042, 1046 and P2P-BSR 1044 after sending the BSRP trigger frame on link 1, it can also notify STA1′ on link 2 (refer to Figure 20 topology in) to update the buffer status of the associated STA.

[0286] Since non-AP MLD is non-STR, Figure 48B Their STAs (such as STA2′ to STA5′) seen in FIG1 may not be able to sense and contend for the channel on link 2 during the TXOP duration on link 1. Therefore, STA1′ is seen to start backoff 1078, which is interrupted by CCA busy.

[0287] However, STA1′ then obtains channel access 1081 on link 2. When STA1′ obtains channel access on link 2, it can send a CTS frame 1080 to obtain and reserve a TXOP 1079 on link 2. A padding field 1082 can be added to the CTS frame to align PPDU transmissions (e.g., TF, multi-user UL transmission, MU-BA, P2P TF, and P2P transmission) on link 1 and link 2. That is, the PPDU transmissions on both links are downlink, uplink, or P2P transmissions.

[0288] As shown, after STA1′ reserves the TXOP on link 2 by using a CTS+fill frame, both STA1 and STA1′ send 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.

[0289] In at least one embodiment, a multi-user uplink packet can include a BSR. For example, as shown, STA5 embeds a P2P-BSR 1066 in its multi-user uplink packet. STA5's new buffer status is reported to STA1, and STA1 shares this information with STA1'. STA1 and STA1' then confirm the transmission with MU BAs 1068 and 1098. Following this, both STA1 and STA1' are seen scheduling P2P transmissions on both links simultaneously by sending P2P TFs 1070 and 1100 with an associated transmission from STA5 to STA4 and with associated BAs 1074 and 1104 from STA5' to STA4'.

[0290] It should be understood that PPDU alignment is optional. In particular, it should be noted that when the non-AP MLD is STR, PPDU alignment is not necessary.

[0291] 4.7. Frame Format

[0292] Figure 49 An exemplary embodiment 1150 is shown of any type of BSR frame, including BSR frames defined in IEEE 802.11ax, P2P-BSR, and RTA-BSR.

[0293] The Frame Control field indicates the frame type. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the frame's receiver. When a BSR frame is used to indicate the start of TXOP sharing, a non-AP STA (transmitter) can set the RA to the specific address prepended and negotiated with the AP. The AP (receiver) can identify the specific address used for TXOP sharing in this frame. The TA field contains the address of the STA transmitting the frame.

[0294] The HT Control field shows the BSR Control subfield changes. Figure 52 This section explains the format of the BSR Control subfield modification example. A non-AP STA (transmitter) 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 non-AP STA's current buffer status and buffered QoS requirements. The AP can then schedule transmissions to meet the buffered QoS requirements. Here, and in some other data formats, the Frame Check Sequence (FCS) is considered an error detection code added to frames in communication protocols.

[0295] Figure 50 An exemplary embodiment of the format of a BA+BSR frame is shown 1170. The BSR may be of any type, including BSR frames defined in IEEE 802.11ax, P2P-BSR, and RTA-BSR.

[0296] The Frame Control field indicates the frame type. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the frame's receiver. When a BSR frame is used to indicate the start of TXOP sharing, a non-AP STA (transmitter) can set the RA to the specific address prepended and negotiated with the AP. The AP (receiver) can identify the specific address used in this frame for TXOP sharing. The TA field contains the address of the STA transmitting the frame.

[0297] The HT Control field indicates a variant of the BSR Control subfield. Figure 52 The format of the BSR Control subfield variant is explained in [1]. The non-AP STA (transmitter) sets this field to indicate the BSR type and the corresponding buffer status of the non-AP STA. Thus, the AP receiving this frame obtains information about the non-AP STA's current buffer status and buffered QoS requirements. The AP can then schedule a transmission that meets the buffered QoS requirements. The BA Control field indicates the Block ACK policy. The BA Information field contains feedback for the transmission.

[0298] Figure 51An exemplary embodiment of the format of a data+BSR frame is shown 1190. The BSR may be of any type, including BSR frames defined in IEEE 802.11ax, P2P-BSR, and RTA-BSR.

[0299] The Frame Control field indicates the frame type. The Duration field contains the NAV information used for CSMA / CA channel access. The RA field contains the address of the frame's receiver. When a BSR frame is used to indicate the start of TXOP sharing, a non-AP STA (transmitter) can set the RA to the specific address prepended and negotiated with the AP. The AP (receiver) can identify the specific address used for TXOP sharing in this frame. The TA field contains the address of the STA transmitting the frame. The Sequence Control field contains the packet's fragment number and sequence number.

[0300] The HT Control field indicates a variant of the BSR Control subfield. Figure 52 The format of the BSR Control subfield variant is explained in [1]. The non-AP STA (transmitter) 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 has information about the non-AP STA's current buffer status and buffered QoS requirements. The AP can then schedule transmissions that meet the buffered QoS requirements.

[0301] The data field carries the payload of the data frame.

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

[0303] The Control ID is a field that indicates the type of BSR carried in the Control Information field. The Control Information field carries a BSR Control subfield variant, such as the BSR Control subfield defined in IEEE 802.11ax, Figure 53 The RTA-BSR and Figure 54 The transmitter sets this field to report the buffered QoS requirements and buffer status to the receiver. The receiver can schedule transmissions according to the BSR and meet their QoS requirements.

[0304] Figure 53An exemplary embodiment 1230 illustrates the format of the RTA-BSR control subfield in the A-Control subfield. The RTA ID field identifies the RTA buffer reported in this BSR. The receiver can use the RTA ID to identify RTA traffic, enabling it to understand the QoS requirements of the RTA traffic. As an example and not a limitation, let's assume that both the AP and the STA have a list of traffic specifications (e.g., AC, TID, priority, and traffic rate) and the QoS requirements of the RTA traffic (e.g., delay, jitter, and packet loss). Each QoS requirement for RTA traffic under the same traffic specification is linked to the RTA ID.

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

[0306] When the AP receives this control subfield, in order to meet the QoS requirements of the buffered traffic indicated in the control subfield, it should complete the delivery of the buffered RTA traffic indicated in the expiration queue size before the expiration time. The AP can also process the buffered RTA traffic indicated in the RTA queue size.

[0307] It should be understood that Figure 53 The number of bits below each field shown represents an example of the length of each field. In at least one embodiment, the length of each field is different from the length shown in the figure.

[0308] Figure 54Example embodiment 1250 illustrates the format of the P2P-BSR Control subfield in the A-Control subfield. The ACIP2P field indicates the access category of the P2P buffer reported in this BSR. The Scale Factor field indicates the units of the Queue Size P2P and can be encoded similarly to IEEE 802.11ax. The Queue Size P2P field indicates the amount of buffered P2P traffic that will expire at the Expiration Time in units of the Scale 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. When the AP receives this field, it identifies the receiver of the P2P traffic. When scheduling multi-user transmissions as shown in the example in Section 4.6.3, the receiver of the P2P traffic should not be simultaneously a transmitter of an UL transmission or a receiver of a DL transmission. When the AP receives this control subfield, in order to meet the QoS requirements of the buffered traffic indicated in the control subfield, it should schedule transmission for the buffered P2P traffic indicated in the queue size P2P before the expiration time.

[0309] It should be understood that Figure 54 The number of bits illustrated below each field as shown represents an example of the length of each field; however, in at least one embodiment, the length of one or more of these fields may differ from that shown in the figure.

[0310] Figure 55 An exemplary embodiment 1270 of the RTF frame format is shown. The Frame Control field indicates the frame type. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the address of the frame's receiver. When a BSR frame is used to indicate the start of TXOP sharing, a non-AP STA (transmitter) can set the RA to a specific address prepended and negotiated with the AP. The AP (receiver) can recognize the specific address used for TXOP sharing. The TA field contains the address of the STA transmitting the frame.

[0311] The HT Control field shows a modified example of the BSR Control subfield. Figure 52 This section explains the format of a modified BSR Control subfield. A non-AP STA (transmitter) sets this field to indicate the type of BSR and the corresponding buffer status of the non-AP STA. This allows the AP receiving the frame to know the non-AP STA's current buffer status and buffered QoS requirements. The AP can then schedule transmissions to meet the buffered QoS requirements. In at least one embodiment, the HT Control field carries other subfield variations defined in IEEE 802.11 that can be used by receivers.

[0312] The TXOP Sharing Indication field indicates whether the RTF frame is used to initiate TXOP sharing. This field can be implemented as a one-bit indication. When the transmitter sets this bit to the first state (e.g., "1"), the RTF frame indicates the start of TXOP sharing. The receiver will transmit the trigger frame requested in the Trigger Type field to initiate TXOP sharing. The receiver can arrange the following transmissions in a shared TXOP. If the transmitter is set to the second state (e.g., "0"), the frame is only used for trigger frame requests. The receiver only needs to send the trigger frame requested by the transmitter.

[0313] The TXOP sharing duration indicates the duration of TXOP sharing. When the TXOP sharing indication is set to a first state (e.g., "1"), the receiver can schedule transmissions during the TXOP sharing duration. When the TXOP sharing indication is set to a second state (e.g., "0"), this field is reserved.

[0314] The Trigger Type field indicates the type of trigger frame the transmitter requests the receiver to send. The receiver will send 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 will send a P2P trigger frame.

[0315] The Common Information field indicates the recommended parameter settings in the Request Trigger Frame. The format of the Common Information field is shown in Figure 9. Receivers can use the recommended parameters in this field to set the Common Information field of the corresponding TF. It should be understood that receivers may not use the same parameter settings in the Common Information field.

[0316] The User Information field indicates the recommended parameter settings in the Request Trigger Frame. The format of the User Information field is shown in Figure 10. The receiver can 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 can be established 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 can be established that the receiver may not use the same parameter settings in the Usage Information field of the corresponding TF.

[0317] The Requested Time field indicates the time requested by the STA to access the channel when receiving a Frequency Resource from the AP. The STA calculates this time to accommodate its data transmission to the AP. Upon receiving this field, the AP sends a Frequency Resource and allocates resources to the STA for the requested time. If this field is available (unreserved), the user is assumed to use the frequency resources defined in the User field or the Requested Frequency Resource field (if used (unreserved)).

[0318] The Requested Frequency Resources field (if not reserved) indicates the amount of frequency resources (RUs or channels) requested by the STA for use after receiving a TF. The STA calculates the amount of resources required to transmit data to the AP. Upon receiving this field, the AP sends a TF and allocates the requested frequency resources to the STA. If this field is available, it overrides the information in the User field. This field is optional and is enabled by the Requested Frequency Resources field.

[0319] The requested frequency resource indication is preferably a single bit indicating whether the user field is used to define the requested frequency resource or the requested frequency resource field. If the STA requests resources by setting the requested frequency resource field, it sets this field to the first state (e.g., "1"). If the STA requests resources via the user field, it sets this field to zero. After receiving this field, the AP optionally reads the requested resources from the STA from the requested frequency resource field or the user field. The AP should allocate resources to the STAs in the TF based on the requested frequency resources.

[0320] Figure 56 An exemplary embodiment 1290 of the CTS frame format for TXOP sharing is shown. The Frame Control field indicates the frame type. The Duration field contains NAV information for CSMA / CA channel access. The RA field contains the address of the frame's receiver. When a BSR frame is used to indicate the start of TXOP sharing, a non-AP STA (transmitter) can set the RA to a specific address prepended and negotiated with the AP. The AP (receiver) can then recognize that the frame is for a specific address in TXOP sharing.

[0321] Figure 57 An exemplary embodiment 1310 of the content in a P2P trigger frame is shown with the following fields. The Frame Control field indicates the type of frame. The Duration field contains NAV information 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 transmitting the frame. As shown in FIG9 , the Common Information field includes information for all assigned STAs.

[0322] As shown in Figure 10, the User Information field includes information about each STA. In particular, the Trigger Dependent Common Information field in the User Information field carries the P2P Receiver ID. The transmitter of the P2P-TF sets this field to indicate the receiver of the P2P transmission that will be triggered by the P2P Trigger Frame.

[0323] If the receiver of the user information field is a non-AP and the P2P receiver ID indicates a non-AP, the receiver of the user information field transmits a packet to the receiver indicated by the P2P receiver ID.

[0324] If the receiver of the user information field is an AP and the P2P receiver ID indicates a non-AP, the AP transmits a downlink packet to the receiver indicated by the P2P receiver ID.

[0325] If the receiver of the user information field is a non-AP and the P2P receiver ID represents an AP, the receiver of the user information field transmits an uplink packet to the AP.

[0326] The TF verification field is set to indicate a time when the TF can trigger multiple PPDUs by using the channel resources allocated in the TF. A receiver that receives this field is triggered to send multiple PPDUs by using the channel resources allocated in the TF. That is, one TF triggers multiple transmissions during the TF verification time. In at least one embodiment, this field is set to indicate the number of PPDUs that can be triggered by the TF. A receiver that receives this field is triggered to send multiple PPDUs whose numbers are 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 Figure 29 and Figure 57 shown.

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

[0328] It should be understood that the TF verification field can be a subfield in the public information field.

[0329] Figure 58 An exemplary embodiment 1330 of a conventional IEEE 802.11be preamble format is shown. This format, which can be used for MU-BSR to indicate TXOP sharing according to the present disclosure, has the following fields: The L-STF field represents the non-HT short training field. The L-LTF field represents the non-HT long training field. The L-SIG field represents the non-HT signal field. The RL-SIG field represents the repeated non-HT signal field. The U-SIG field represents the EHT common field. The EHT-SIG field represents the EHT signal field.

[0330] The EHT-SIG field may include a TXOP Sharing Indication field. The TXOP Sharing Indication field indicates whether the preamble is used to initiate TXOP sharing. This field may include a one-bit indication. For example, when the transmitter sets this bit to the first state (e.g., "1"), the preamble indicates the start of TXOP sharing, where the receiver will start TXOP sharing. The receiver can arrange for transmission in a shared TXOP. If the transmitter is set to the second state (e.g., "0"), the preamble is not used for TXOP sharing.

[0331] The EHT-STF field indicates the EHT short training field, and the EHT-LTF field indicates the EHT long training field.

[0332] 5. General Scope of the Embodiments

[0333] The enhancements described in this technology can be easily implemented in various wireless network communication stations. It should also be understood that the wireless network communication station is preferably implemented to include one or more computer processor devices (e.g., CPU, microprocessor, microcontroller, computer-enabled ASIC, etc.) and associated memory storage instructions (e.g., RAM, DRAM, NVRAM, FLASH, computer-readable media, etc.), whereby the programming (instructions) stored in the memory is executed on the processor to perform the steps of the various processing methods described herein.

[0334] It should also be understood that the computer-readable media (memory storing instructions) in these computing systems are "non-transitory," including any and all forms of computer-readable media, with the sole exception of transient propagating signals. Thus, the disclosed technology can include any form of computer-readable media, including those that are random access (e.g., RAM), require periodic refresh (e.g., DRAM), degrade over time (e.g., EEPROM, magnetic disk media), or store data only for a short period of time and / or only while powered, with the only limitation that the term "computer-readable medium" does not apply to transient electronic signals.

[0335] Embodiments of the present technology may be described with reference to flowchart illustrations and / or processes, algorithms, steps, operations, formulas, or other computational depictions of methods and systems according to embodiments of the present technology, which may also be implemented as computer program products. In this regard, each box or step of the flowchart, a combination of boxes (and / or steps) in the flowchart, and any process, algorithm, step, operation, formula, or computational depiction may be implemented by various means such as hardware, firmware, and / or software comprising one or more computer program instructions embodied in a computer-readable program code. It will be understood that any such computer program instructions may be executed by one or more computer processors or other programmable processing devices, including but not limited to general-purpose computers or special-purpose computers, to produce a machine such that the computer program instructions executed on the computer processor or other programmable processing device create a means for implementing a specified function.

[0336] Therefore, the blocks of the flowcharts described herein and the processes, algorithms, steps, operations, formulas or calculations depictions support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and computer program instructions such as those embodied in computer-readable program code logic means for performing the specified functions. It should also be understood that the blocks of the flowcharts described herein and any processes, algorithms, steps, operations, formulas or calculations depictions and combinations thereof can be implemented by a hardware-based special-purpose computer system that performs the specified functions or steps or a combination of special-purpose hardware and computer-readable program code.

[0337] Furthermore, these computer program instructions, such as those embodied in computer-readable program code, may also be stored in one or more computer-readable memories or storage devices, which may instruct a computer processor or other programmable processing apparatus to operate in a specific manner, such that the instructions stored in the computer-readable memory or storage device produce an article of manufacture comprising instruction means for implementing the functions specified in the flowchart blocks. The computer program instructions may also be executed by a computer processor or other programmable processing apparatus to cause a series of operational steps to be performed on the computer processor or other programmable processing apparatus to produce a computer-implemented process, such that the instructions executed on the computer processor or other programmable processing apparatus provide steps for implementing the functions specified in the flowchart blocks, process algorithms, steps, operations, formulas, or calculation depictions.

[0338] It should also be understood that the terms "programming" or "executable program" as used herein refer to one or more instructions that can be executed 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 the device in a non-transitory medium, or may be stored remotely, such as on a server, or all or part of the instructions may be stored locally and remotely. Remotely stored instructions may be automatically downloaded (pushed) to the device by user initiation or based on one or more factors.

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

[0340] It can be understood from the description herein that the present disclosure includes various implementations including but not limited to the following aspects:

[0341] 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-volatile memory storing instructions executable by the processor; (d) wherein the instructions, when executed by the processor, perform a communication protocol for the station and other stations operating as access point (AP) stations or non-AP stations on the network, and wherein, by performing the following steps, the access point (AP) station using a basic service set (BSS) is used to share with other stations a communication protocol provided by a non-AP station. A method for obtaining a transmission opportunity (TXOP) obtained by a (non-AP) station, the steps comprising: (d)(i) receiving a message at a station operating as an access point (AP) from a non-AP station that has obtained a TXOP, wherein the message notifies the AP station of a shared TXOP within a BSS; (d)(ii) obtaining, by the station operating as the AP, buffered quality of service (QoS) requirements and a buffer status associated with the at least one other station; and (d)(iii) wherein the station operating as the AP behaves as a TXOP holder rather than the non-AP station that obtained the TXOP during the shared TXOP to meet the buffered QoS requirements reported by the at least one other station.

[0342] 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-volatile memory storing instructions executable by the processor; (d) wherein the instructions, when executed by the processor, perform a communication protocol for the station and other stations operating as access point (AP) stations or non-AP stations on the network, and wherein a transmit opportunity (TXOP) obtained by a non-access point (non-AP) station is shared with other stations by virtue of the access point (AP) station using a basic service set (BSS), the steps comprising: (d)(i) by the station operating as a non-AP STA, embedding a proposed parameter setting of a trigger frame (TF) in a request trigger frame (RTF) to indicate its quality of service (QoS) requirement, and sending the RTF to its associated AP; (d)(i) by the station operating as the AP, receiving the RTF and, based on the non-AP The STA sends a TF at its request to trigger transmissions by the non-AP STA and other non-AP STAs; and (d)(iii) wherein, in response to receiving the TF from the AP, the non-AP STAs start their transmissions triggered by the AP.

[0343] 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 in which multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-volatile memory storing instructions executable by the processor; (d) wherein the instructions, when executed by the processor, perform a communication protocol for the station and other stations operating as access point (AP) stations or non-AP stations on the network, and wherein a transmit opportunity (TXOP) obtained by a non-access point (non-AP) station is shared with other stations by virtue of the access point (AP) station using a basic service set (BSS), the steps comprising: (d) (i) sending, by a station that is part of a multi-link device (MLD) and operating as a first AP, a BSRP frame on one link to receive a TXOP from its associated non-AP station. The MLD collects buffered quality of service (QoS) requirements and buffer status; (d)(ii) sharing, by a station operating as part of a multi-link device (MLD) and as a first AP, the buffered QoS requirements and buffer status of its associated non-AP MLD with all subordinate APs in a plurality of links; and (d)(iii) wherein the station operating as a subordinate AP of the first AP uses the buffered QoS requirements and buffer status from its associated non-AP MLD to schedule transmissions.

[0344] 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 by using carrier sense multiple access with collision avoidance (CSMA / CA), and in which multi-link operation for a multi-link device (MLD) is applied; (b) a processor coupled to the station; and (c) a non-volatile memory storing instructions executable by the processor; (d) wherein the instructions, when executed by the processor, perform a communication protocol for the station and other stations operating as access point (AP) stations or non-AP stations on the network, and wherein, by performing the following steps, an access point (AP) station using a basic service set (BSS) is connected to the station. , sharing a transmit opportunity (TXOP) obtained by a non-access point (non-AP) station with other stations, the steps comprising: (d)(i) accessing a channel on a first link by a station operating as a non-AP station and sharing its TXOP with its associated access point (AP), wherein its associated access point (AP) is a station operating as an AP associated with the first link; (d)(ii) contending for a channel on a second link by a station operating as an AP associated with the first link and obtaining channel access on the first link within a TXOP sharing duration; and (d)(iii) arranging transmissions on both the first link and the second link by the AP associated with the first link.

[0345] A wireless communication system / device for performing packet transmission, wherein CSMA / CA is applied in the system / device, including: a non-AP STA obtains a TXOP and notifies an AP within its BSS of a shared TXOP; the AP of the BSS collects buffered QoS requirements and buffer status from the STA; and the AP arranges transmission during the shared TXOP to meet the buffered QoS requirements reported by the STA.

[0346] A wireless communication system / device for performing packet transmission, wherein CSMA / CA is applied in the system / device, including: a non-AP STA sends a request trigger frame (RTF) to its associated AP; the non-AP STA embeds a recommended parameter setting of the TF in the RTF; the AP receives the RTF and sends the TF according to the STA's request.

[0347] A wireless communication system / apparatus for performing packet transmission in which CSMA / CA and multi-link operation are applied, comprising: an AP MLD sending BSRP frames on one link to collect buffered QoS requirements and buffer status from its associated non-AP MLD; the AP MLD sharing the buffered QoS requirements and buffer status of its associated non-AP MLD with all of its subordinate APs in multiple links; and each subordinate AP using the buffered QoS requirements and buffer status from its associated non-AP MLD to schedule transmission.

[0348] A wireless communication system / device performing packet transmission in which CSMA / CA and multi-link operation are applied includes: a non-AP STA accessing a channel on one link (represented by link 1) and sharing its TXOP with its associated AP; an AP MLD of the associated AP contending for a channel on another link (represented by link 2) and obtaining channel access during the TXOP sharing duration on link 1; and the AP MLD scheduling transmissions on both link 1 and link 2.

[0349] The apparatus according to any preceding implementation, wherein, when a station operating as an AP processes information about TXOP sharing, the message received at the station operating as an AP from a station operating as a non-AP station about sharing its TXOP is prefixed with content carrying duplicate information about the shared TXOP to eliminate communication errors.

[0350] An apparatus according to any preceding implementation, wherein a station operating as a non-AP STA sharing its TXOP sends a frame to a station operating as an AP, wherein a preamble of the frame is prefixed with the same information indicating TXOP sharing and a payload carrying buffer status transmitted by a random RU.

[0351] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA sharing its TXOP sends a frame to a station operating as an AP to indicate TXOP sharing and to allow the station operating as the AP to become the TXOP holder, the receiver address of the station operating as the AP being prepended and negotiated with the station operating as the AP.

[0352] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA sharing its TXOP sends a clear to send (CTS) frame to a station operating as an AP to indicate TXOP sharing and to allow the station operating as an AP to become the TXOP holder.

[0353] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA sharing its TXOP sends a buffer status report (BSR) frame to a station operating as an AP to indicate TXOP sharing and to allow the station operating as an AP to become a TXOP holder.

[0354] The apparatus according to any preceding implementation, wherein the station operating as an AP station collecting buffer status from at least one other station sends a buffer status report poll (BSRP) trigger frame to request buffered QoS requirements and buffer status from the at least one other station.

[0355] The apparatus as in any preceding implementation, wherein a station operating as a non-AP station reporting a buffer status to an AP station may send different types of buffer status report (BSR) frames to report buffered QoS requirements and buffer status.

[0356] The apparatus as in any preceding implementation, wherein the station operating as a non-AP STA reporting a buffer status to the AP station reports an expiration time of the buffered traffic.

[0357] The apparatus as in any preceding implementation, wherein the station operating as a non-AP STA reporting a buffer status to the AP station reports buffered flow for point-to-point transmission.

[0358] The apparatus of any preceding implementation, wherein the station operating as an AP station is configured to schedule transmissions during a shared TXOP period, the scheduling of the point-to-point transmissions being performed by allocating a portion of a channel time for the point-to-point transmissions.

[0359] The apparatus of any preceding implementation, wherein the station operating as an AP station is configured to arrange transmissions by taking over a TXOP and acting as a TXOP holder during a shared TXOP, and then arrange multi-user transmissions including downlink transmissions and any point-to-point transmissions.

[0360] The apparatus of any preceding implementation, wherein the station operating as an AP station is configured to arrange transmissions by taking over a TXOP and acting as a TXOP holder during a shared TXOP, and then arrange multi-user transmissions including uplink transmissions and any point-to-point transmissions.

[0361] The apparatus as in any preceding implementation, wherein a station operating as a non-AP STA sending a request trigger frame (RTF) may embed a buffer status report in the RTF.

[0362] The apparatus of any preceding implementation, wherein a station operating as a non-AP STA sending a request trigger frame (RTF) may provide an indication that TXOP sharing is allowed.

[0363] The apparatus as in any preceding implementation, wherein the non-AP stations sharing the buffered QoS requirements further include information regarding a buffered expiration time.

[0364] The apparatus as in any preceding implementation, wherein non-AP stations that share a buffer status also share a buffer status for P2P transmissions.

[0365] The apparatus as in any preceding implementation, wherein the AP gaining channel access on the second link sends a clear to send to self (CTS-to-self) frame to reserve the TXOP.

[0366] An apparatus according to any preceding implementation, wherein an AP gaining channel access on a second link sends a clear to send to itself (CTS-to-self) frame, the clear to send to itself (CTS-to-self) frame including padding to align physical layer protocol data unit (PPDU) end times on both the first link and the second link.

[0367] The apparatus according to any preceding implementation, wherein the transmitting AP sends a buffer status report (BSRP) frame on both the first link and the second link to collect buffered quality of service (QoS) requirements and buffer status from non-AP STAs.

[0368] The apparatus of any preceding implementation, wherein any non-AP STA sharing its TXOP may send frames to the AP with the same prefixed content.

[0369] The apparatus of any preceding implementation, wherein any non-AP STA sharing its TXOP may send a frame with its preamble prefixed to the same AP, and the payload is transmitted by a random RU.

[0370] The apparatus of any preceding implementation, wherein any non-AP STA sharing its TXOP may send a frame to the AP with its receiver address prefixed and negotiated with the AP to indicate that the frame is for TXOP sharing.

[0371] The apparatus of any preceding implementation, wherein any non-AP STA sharing its TXOP may send a CTS frame to the AP to indicate TXOP sharing.

[0372] The apparatus of any preceding implementation, wherein any non-AP STA sharing its TXOP may send a BSR frame to the AP to indicate TXOP sharing.

[0373] The apparatus according to any preceding implementation, wherein the AP collecting the buffer status from the STA may send a BSRP trigger frame to request the buffered QoS requirement and the buffer status from the STA.

[0374] The apparatus according to any preceding implementation, wherein a non-AP STA that reports a buffer status to an AP may send different types of BSR frames to report buffered QoS requirements and buffer status.

[0375] The apparatus as in any preceding implementation, wherein a non-AP STA that reports a buffer status to the AP may report an expiration time of the buffered traffic.

[0376] The apparatus as in any preceding implementation, wherein a non-AP STA reporting a buffer status to an AP may report a buffered flow for point-to-point transmission.

[0377] The apparatus of any preceding implementation, wherein the AP arranging transmissions during a shared TXOP may arrange point-to-point transmissions.

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

[0379] The apparatus of any preceding implementation, wherein the AP arranging transmissions during a shared TXOP may arrange multi-user transmissions including uplink transmissions and point-to-point transmissions.

[0380] The apparatus as in any preceding implementation, wherein a non-AP STA sending a request trigger frame (RTF) may embed a buffer status report in the RTF.

[0381] The apparatus as in any preceding implementation, wherein a non-AP STA sending a request trigger frame (RTF) may indicate that TXOP sharing is allowed.

[0382] As used herein, the term "implementation" is intended to include, but not be limited to, embodiments, examples, or other forms of implementing the techniques described herein.

[0383] As used herein, the singular terms "a," "an," and "the" may include plural referents unless the context clearly dictates otherwise. Unless explicitly stated, singular forms of the invention do not mean "one and only one" but "one or more."

[0384] Phrase structures in the present disclosure, such as "A, B and / or C," describe that any of A, B, or C may be present, or any combination of items A, B, and C. Expressive phrase structures, such as "at least one of" followed by a list of elements, indicate that at least one of the listed elements is present, including any possible combination of the listed elements, as applicable.

[0385] 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 embodiment is included in at least one embodiment of the disclosure. Thus, these different embodiment phrases are not necessarily all referring to the same embodiment, or to a particular embodiment that is different from all other embodiments described. The embodiment language should be interpreted as meaning 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 apparatus, system, or method.

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

[0387] Relational terms, such as first and second, top and bottom, and the like, may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual relationship or order between such entities or actions.

[0388] The terms "comprises," "comprising," "having," "includes," "including," "contains," "containing," or any other variations thereof are intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus that comprises, has, includes, or contains a list of elements includes not only those elements but may also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without more constraints, an element preceded by "comprises," "having," "including," or "contains" does not preclude the presence of additional identical elements in a process, method, article, or apparatus that comprises, has, includes, or contains that element.

[0389] As used herein, the terms "approximately," "about," "substantially," and "approximately," or any other versions thereof, are used to describe and explain small variations. When used with an event or circumstance, these terms can refer to instances where the event or circumstance occurred exactly as well as instances where the event or circumstance came close to occurring. When used with a numerical value, these terms can refer to a range of variation less than or equal to ±10% of that numerical value, such as less than or equal to ±5%, less than or equal to ±4%, less than or equal to ±3%, less than or equal to ±2%, less than or equal to ±1%, less than or equal to ±0.5%, less than or equal to ±0.1%, or less than or equal to ±0.05%. For example, "approximately" alignment can refer to an angular variation less than or equal to ±10°, such as less than or equal to ±5°, less than or equal to ±4°, less than or equal to ±3°, less than or equal to ±2°, less than or equal to ±1°, less than or equal to ±0.5°, less than or equal to ±0.1°, or less than or equal to ±0.05°.

[0390] In addition, amounts, ratios, and other numerical values may sometimes be presented herein in a range format. It should be understood that this range format is provided for convenience and brevity and should be flexibly interpreted to include the values explicitly specified as the limits of the range, but also to include all individual values or subranges contained within that range, as if each value and subrange were explicitly specified. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly stated limits of about 1 and about 200, but also to include individual ratios such as about 2, about 3, and about 4, as well as subranges such as about 10 to about 50 and about 20 to about 100.

[0391] As used herein, the term "coupled" is defined as connected, although not necessarily directly, and not necessarily mechanically. A device or structure that is "configured" in a certain way is configured in at least that way, but may also be configured in ways that are not listed.

[0392] Benefits, advantages, solutions to problems, and any elements that may cause any benefit, advantage, or solution to occur or become apparent are not to be construed as critical, required, or essential features or elements of the technology described herein or in any or all the claims.

[0393] Additionally, in the foregoing disclosure, various features may be grouped together in various embodiments for the purpose of streamlining the disclosure. This method of disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. The subject matter of the invention may lie in fewer than all features of a single disclosed embodiment.

[0394] The Abstract of the Disclosure is provided 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.

[0395] It should be understood that the practice of some jurisdictions may require that one or more portions of the disclosure be deleted after the application is filed. Therefore, readers should consult the application as filed to obtain the original disclosure. Any deletion of disclosure should not be construed as a waiver, forfeiture, or donation to the public of any subject matter of the application as originally filed.

[0396] The following claims are hereby incorporated into this disclosure with each claim standing on its own as a separately claimed subject matter.

[0397] Although the description herein contains many details, it should not be interpreted as limiting the scope of the present disclosure, but rather as merely providing illustrations of some of the presently preferred embodiments. Therefore, it should be understood that the scope of the present disclosure fully encompasses other embodiments that may become apparent to those skilled in the art.

[0398] All structural and functional equivalents to the elements of the disclosed embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be included in the claims herein. Furthermore, no element, component, or method step in this disclosure is intended to be dedicated to the public, regardless of whether the element, component, or method step is expressly recited in the claims. No claim element herein shall be construed as a “means plus function” element unless the element is expressly recited using the phrase “means for…” No claim element herein shall be construed as a “step plus function” element unless the element is expressly recited using the phrase “step for…”

[0399] Table 1 User priority mapping to access category (UP to AC)

[0400]

[0401]

[0402] Table 2 Default parameter settings for EDCA channel access

[0403] AC CWmin CWmax AIFSN TXOP limit (mS) BK 15 1023 7 0 BE 15 1023 3 0 VI 7 15 2 or 1(AP) 3 VO 3 7 2 or 1(AP) 1.5

Claims

1. A device for wireless communication in a network, the device being an access point (AP), 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 (CSMA / CA) with contention avoidance; (b) a processor coupled to the station; and (c) a non-transitory memory storing instructions executable by the processor; (d) wherein the instructions, when executed by the processor, execute a communication protocol for the station, and wherein the transmit opportunity (TXOP) obtained by the non-AP station is shared with other stations by the AP station using a basic service set (BSS) by performing the following steps, the steps comprising: (i) receiving, at the station, a message from a non-AP station that has obtained a TXOP, wherein the message notifies the station of sharing the TXOP within the BSS; (ii) obtaining a buffered quality of service (QoS) requirement and a buffer status associated with the at least one other station; and (iii) A non-AP station that behaves as a TXOP holder rather than obtaining a TXOP during a shared TXOP to satisfy the buffered QoS requirements reported by at least one other station.

2. The device according to claim 1, wherein When the station processes information on TXOP sharing, the message received at the station from the non-AP station on sharing its TXOP is prefixed with content carrying duplicate information on the shared TXOP to eliminate communication errors.

3. The device according to claim 1, wherein The steps also include: A frame is received from the non-AP station sharing its TXOP, wherein a preamble of the frame is prefixed with the same information indicating TXOP sharing and a payload carrying a buffer status transmitted by a random RU.

4. The device according to claim 1, wherein The steps also include: A frame is received from the non-AP station sharing its TXOP to indicate TXOP sharing and to allow the station to become a TXOP holder, the receiver address of the frame being prefixed and negotiated with the station.

5. The device according to claim 1, wherein The steps also include: A clear to send CTS frame is received from the non-AP station sharing its TXOP to indicate TXOP sharing and allow the station to become the TXOP holder.

6. The device according to claim 1, wherein The steps also include: A buffer status report (BSR) frame is received from the non-AP station sharing its TXOP to indicate TXOP sharing and to allow the station to become a TXOP holder.

7. The device according to claim 1, wherein The steps also include: The buffer status is collected from at least one other station by sending a Buffer Status Report Polling BSRP trigger frame requesting a QoS requirement and a buffer status of a buffer from the at least one other station.

8. The device according to claim 1, wherein The steps also include: Different types of buffer status report (BSR) frames reporting buffered QoS requirements and buffer status are received from the non-AP station.

9. The device according to claim 1, wherein The steps also include: A report of the expiration time of the buffered traffic is received from the non-AP station as part of reporting the buffer status to the AP station.

10. The device according to claim 1, wherein The steps also include: A report of buffered traffic for point-to-point transmission is received from the non-AP station as part of reporting a buffer status to the AP station.

11. The device according to claim 1, wherein The steps also include: Transmissions are arranged during a shared TXOP, which includes performing arrangement of point-to-point transmissions by allocating a portion of a channel time for point-to-point transmissions.

12. The device according to claim 1, wherein The steps also include: It arranges transmissions by taking over a TXOP and acting as a TXOP holder during a shared TXOP, and then arranges multi-user transmissions including downlink transmissions and any point-to-point transmissions.

13. The device according to claim 1, wherein The steps also include: It arranges transmissions by taking over the TXOP and acting as the TXOP holder during the shared TXOP, and then arranges multi-user transmissions including uplink transmissions and any point-to-point transmissions.

Images