Bounded target wait time coordination between basic service sets

Abstract

To avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding R-TWT SPs, a wireless protocol enhancement is provided that enables inter-BSS stations / APs to support, negotiate, and participate in temporally overlapping cooperative R-TWT SPs scheduled on different links or different channels. The protocol utilizes new subfield elements to announce, negotiate, and support cooperative R-TWT SPs.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Patent Application Serial No. 18 / 435,638, filed February 7, 2024, which is incorporated herein by reference in its entirety. This application claims priority to and the benefit of U.S. Provisional Patent Application Serial No. 63 / 488,256, filed March 3, 2023, which is incorporated herein by reference in its entirety.

[0002] STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT Not applicable

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

[0004] The techniques of this disclosure relate generally to Restricted Target Wake Time (R-TWT) operation under IEEE 802.11, and specifically to resolving communication blockage issues of overlapping Basic Service Sets (BSSs) during R-TWT Service Periods (SPs). [Background technology]

[0005] Restricted Target Wake Time (R-TWT) was introduced in IEEE 802.11be. Under certain circumstances, interference can occur when R-TWT operations are performed on different overlapping basic service sets (BSSs). Summary of the Invention [Problem to be solved by the invention]

[0006] Therefore, there is a need for improved R-TWT control that solves the blockage / interference problem. The present disclosure fulfills this need while providing additional benefits over existing systems. [Means for solving the problem]

[0007] The disclosed protocol allows inter-basic service set (inter-BSS) devices to negotiate and participate in temporally overlapping cooperative restricted target wake time (R-TWT) service periods (SPs) scheduled on different links or different channels, thereby avoiding inter-BSS interference for prioritized traffic scheduled for transmission during corresponding R-TWT SPs.

[0008] This disclosure describes inter-BSS signaling mechanisms that demonstrate support provided by a protocol for inter-BSS cooperative R-TWTs. Inter-BSS APs obtain information from cooperative BSSs prior to the cooperative R-TWT negotiation process. Inter-BSS APs in this protocol are configured to cooperate with each other while negotiating R-TWT membership at the channel level. Inter-BSS APs are also configured to cooperate with each other to negotiate R-TWT membership at the link level, as long as the TID-to-link mapping is not violated.

[0009] In the disclosed protocol, the size of the Restricted TWT Schedule Information subfield of the Broadcast TWT Information subfield within the TWT element may be increased by, for example, 1 bit (originally 2 bits), with a newly defined field value such as "4" indicating an advertised R-TWT schedule where the R-TWT scheduling AP is likely to cooperate with another R-TWT scheduling AP from the OBSS.

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

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

[0012] [Figure 1] FIG. 1 is a block diagram of communication station (STA) hardware in accordance with at least one embodiment of the present disclosure. [Figure 2] FIG. 1 is a block diagram of multi-link device (MLD) hardware in accordance with at least one embodiment of the present disclosure. [Figure 3] FIG. 1 is a network topology diagram that aids in understanding an example scenario described in accordance with at least one embodiment of the present disclosure. [Figure 4-1] 1 is a communication diagram of Example 1 for negotiating R-TWT membership at the link level, performed in accordance with at least one embodiment of the present disclosure. [Figure 4-2] 1 is a communication diagram of Example 1 for negotiating R-TWT membership at the link level, performed in accordance with at least one embodiment of the present disclosure. [Figure 5-1] FIG. 10 is a communication diagram of Example 2 for negotiating R-TWT membership at the channel level without using trigger-enabled R-TWT SP, performed in accordance with at least one embodiment of the present disclosure. [Figure 5-2] FIG. 10 is a communication diagram of Example 2 for negotiating R-TWT membership at the channel level without using trigger-enabled R-TWT SP, performed in accordance with at least one embodiment of the present disclosure. [Figure 6-1] FIG. 10 is a communication diagram of Example 3 for negotiating R-TWT membership at the channel level using trigger-enabled R-TWT SP, performed in accordance with at least one embodiment of the present disclosure. [Figure 6-2] FIG. 10 is a communication diagram of Example 3 for negotiating R-TWT membership at the channel level using trigger-enabled R-TWT SP, performed in accordance with at least one embodiment of the present disclosure. [Figure 7-1] FIG. 10 is a flow diagram of R-TWT negotiation performed from the AP side, in accordance with at least one embodiment of the present disclosure. [Figure 7-2] FIG. 10 is a flow diagram of R-TWT negotiation performed from the AP side, in accordance with at least one embodiment of the present disclosure. [Figure 7-3]FIG. 10 is a flow diagram of R-TWT negotiation performed from the AP side, in accordance with at least one embodiment of the present disclosure. [Figure 8-1] FIG. 10 is a flow diagram of R-TWT negotiation performed from the non-AP side, in accordance with at least one embodiment of the present disclosure. [Figure 8-2] FIG. 10 is a flow diagram of R-TWT negotiation performed from the non-AP side, in accordance with at least one embodiment of the present disclosure. [Figure 9] FIG. 10 is a data field diagram of a Link ID-to-Channel BSSID mapping element format utilized in accordance with at least one embodiment of the present disclosure. [Figure 10] 10 is a data field diagram of subfields within the Link ID-to-Channel BSSID Mapping Control field shown in FIG. 9, utilized in accordance with at least one embodiment of the present disclosure. [Figure 11] FIG. 10 is a data field diagram of subfields within a Link ID n mapping field, shown in FIG. 9 as Link ID 1 mapping fields through Link ID 15 mapping fields, utilized in accordance with at least one embodiment of the present disclosure. [Figure 12] FIG. 10 is a data field diagram of a broadcast TWT parameter set field format used in channel or link level collaborative R-TWT negotiation, utilized in accordance with at least one embodiment of the present disclosure. [Figure 13] FIG. 13 is a data field diagram of the subfields of the Broadcast TWT Information field shown in FIG. 12, utilized in accordance with at least one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013] 1. Introduction of Limited Target Wake Time (R-TWT) In the following description, we consider the case where the R-TWT scheduling access point (AP), which is an Extra High Throughput (EHT) AP, has the subfield "dot11TWTOptionActivated" equal to true and sets the value of the Limited TWT Support subfield of the transmitted EHT Capabilities element to "1." The R-TWT scheduled station (STA), which is a non-AP EHT STA, sets the Limited TWT Support subfield of the transmitted EHT Capabilities element to a value of "1" and sends and receives broadcast TWT elements carrying one or more R-TWT parameter set fields to and from the R-TWT scheduling AP.

[0014] A non-AP EHT STA establishes membership in one or more R-TWT schedules with its associated EHT AP. An EHT AP with dot11RestrictedTWTOptionImplemented set to true can advertise one or more R-TWT Service Periods (SPs).

[0015] An R-TWT SP is established between an R-TWT scheduling AP and an R-TWT member non-AP STA(s) to provide a specific traffic identifier (TID) or TIDs carrying delay-sensitive traffic in the uplink (UL) and / or downlink (DL) directions of the R-TWT member. Thus, if a TID is not mapped to, or is no longer mapped to, the link on which the R-TWT membership was established, the corresponding R-TWT membership is considered to be torn down.

[0016] The R-TWT scheduling AP announces R-TWT scheduling information by transmitting a management frame containing a Timing Synchronization Function (TSF) element that can indicate a target wake time corresponding to the Timing Synchronization Function (TSF) time at which the scheduled STA requests to wake up for the corresponding R-TWT SP(s). The value of the TSF corresponds to the start time of the first R-TWT SP in the corresponding R-TWT agreement. The R-TWT scheduling AP determines the start time of the next R-TWT SP (after the first R-TWT SP) in the periodic R-TWT schedule based on the start time of the first R-TWT SP and the TWT wake interval. The TSF is used to maintain synchronization of the timers of all STAs within the same BSS. The AP is the timing master of the TSF and periodically transmits a beacon frame containing the AP's TSF timer as a timestamp to synchronize the TSF timers of other STAs within the BSS.

[0017] 2. Problem statement A potential problem may arise from the presence of an OBSS if the OBSS has a scheduled R-TWT SP that overlaps with a scheduled R-TWT SP in the time domain of the BSS under consideration. Scheduled transmissions or receptions between R-TWT member STAs of the overlapping inter-BSS R-TWT SP also utilize the same channel access priority, and therefore may interfere with each other (block) when accessing the channel during the overlapping inter-BSS R-TWT SP.

[0018] 3. Contribution of the present invention To address the blocking issue, we describe a design to provide cooperative R-TWT SP negotiation in the frequency domain when inter-BSS R-TWT SPs overlap in time.

[0019] Cooperation begins before the R-TWT negotiation phase by allowing cooperating BSSs to indicate their inter-BSS cooperation capabilities in overlapping R-TWT SPs. This information allows the cooperating BSSs to understand each other regarding their TSF and Target Beacon Transmission Time (TBTT) offsets or mismatches, the cooperating BSS(s)' channel information and corresponding link IDs, and any other desired information depending on the application.

[0020] During the R-TWT negotiation phase, cooperative APs negotiate overlapping inter-BSS R-TWT SPs by scheduling them on different links or different channels within the same link to avoid interference.

[0021] 4. Hardware Implementation 4.1. Communication Station (STA and MLD) Hardware FIG. 1 illustrates an example embodiment 10 of STA hardware configured to execute the protocol of the present disclosure. An external I / O connection 14 couples to an internal bus 16 of circuitry 12, on which a CPU 18 and memory (e.g., RAM) 20 are preferably connected for executing program(s) implementing the communications protocol. The host machine contains at least one modem 22 supporting communications, coupled to at least one RF module 24, 28, each connected to one or more antennas 29, 26a, 26b, 26c-26n. RF modules with multiple antennas (e.g., antenna arrays) enable beamforming during transmission and reception. In this manner, the STA can transmit signals using multiple sets of beam patterns.

[0022] The bus 14 can connect various devices, such as sensors and actuators, to the CPU. Executing on the processor 18 are instructions from memory 20 for executing programs that implement communication protocols that are executed to enable the STAs to perform the functions of an access point (AP) station or a regular station (non-AP STA). It should also be understood that this programming is configured to operate in different modes (TXOP owner, TXOP sharing participant, source, intermediate, destination, first AP, other AP, station associated with first AP, station associated with other AP, coordinator, coordinatee, AP in OBSS, STA in OBSS, etc.) depending on what role it plays in the current communication situation.

[0023] Thus, the illustrated STA HW comprises at least one modem and associated RF circuitry for providing communications on at least one band. It should be understood that the present disclosure may be configured using multiple modems 22, each coupled to any number of RF circuits. In general, the more RF circuits used, the greater the coverage of the antenna beam directions. It should be understood that the number of RF circuits and antennas utilized is determined by the hardware constraints of a particular device. Some of the RF circuits and antennas may be disabled when a STA determines that it does not need to communicate with neighboring STAs. In at least one embodiment, the RF circuitry includes a frequency converter, an array antenna controller, etc., and is connected to multiple antennas that are controlled to perform beamforming for transmission and reception. In this manner, a STA may transmit signals using a set of multiple beam patterns, with each beam pattern direction considered an antenna sector.

[0024] It should also be understood that multiple instances of station hardware such as that shown in this figure can be combined into a multi-link device (MLD), which typically has a processor and memory for coordinating activity, but that these resources can be shared, so that separate CPUs and memory are not always required for each STA within an MLD.

[0025] FIG. 2 shows an example embodiment 40 of a multi-link device (MLD) hardware configuration. A "soft AP MLD" is an MLD consisting of one or more STAs that operate as an AP. The soft AP MLD should support multiple radio operations, such as 2.4 GHz, 5 GHz, and 6 GHz. A basic link set among the multiple radios is a link pair that satisfies simultaneous transmit / receive (STR) mode, such as a basic link set (2.4 GHz and 5 GHz) or a basic link set (2.4 GHz and 6 GHz).

[0026] A conditional link is a link that forms a non-simultaneous transmission and reception (NSTR) link pair with some fundamental link. For example, these link pairs can include a 6 GHz link as a conditional link corresponding to the 5 GHz link when 5 GHz is the fundamental link, and can include a 5 GHz link as a conditional link corresponding to the 6 GHz link when 6 GHz is the fundamental link. Soft APs are used in different scenarios, including Wi-Fi hotspots and tethering.

[0027] An MLD has multiple STAs attached to it, each operating on a different frequency link. The MLD has external I / O access to applications, which connects to an MLD management entity 48 having a CPU 62 and memory (e.g., RAM) 64 to enable the execution of program(s) that implement the communication protocol at the MLD level. The MLD can distribute tasks to its attached stations, illustrated here as STA1 42, STA2 44 through STA N 46, collect information from them, and share that information among its attached STAs.

[0028] In at least one embodiment, each STA in the MLD has its own CPU 50 and memory (RAM) 52, which are coupled via a bus 58 to at least one modem 54 connected to at least one RF circuit 56 having one or more antennas. In this example, the RF circuit has multiple antennas 60a, 60b, 60c-60n, such as in the form of an antenna array. The modem in combination with the RF circuit and associated antenna(s) transmits / receives data frames to / from nearby STAs. In at least one implementation, the RF module includes a frequency converter, an array antenna controller, and other circuitry for interfacing with the antennas.

[0029] It should be understood that each STA in an MLD does not necessarily require its own processor and memory, as they may share resources with each other and / or with an MLD management entity depending on the particular MLD implementation. It should be understood that the above MLD diagram is provided by way of example and not limitation, and that the present disclosure can work with a wide variety of MLD implementations.

[0030] 5. Network topology example FIG. 3 illustrates an example network topology 70 that is used to help explain the example operation. Note that the present disclosure is not limited in that it is constrained to any particular topology. In the illustrated example, BSS1 96 and BSS2 98 are neighboring BSSs. In BSS1, non-AP STA MLD1 72 has two affiliated non-AP STAs, STA1 80 and STA2 82, which are associated with AP1 84 and AP2 86, respectively, on a 5 GHz link (L1) 100 and a 6 GHz link (L2) 102. AP1 and AP2 belong to AP MLD1. In BSS2, non-AP STA MLD2 88 has two affiliated non-AP STAs, STA3 88 and STA4 90, which are associated with AP3 92 and AP4 94, respectively, on a 5 GHz link (L1) 104 and a 6 GHz link (L2) 106. AP3 and AP4 belong to AP MLD2.

[0031] In this disclosure, a BSS requesting R-TWT cooperation with a neighboring BSS or an AP of the neighboring BSS is referred to as an R-TWT cooperation request BSS or an R-TWT cooperation request AP, respectively. In this disclosure, a corresponding neighboring BSS or an AP of the neighboring BSS is referred to as an R-TWT cooperation response BSS or an R-TWT cooperation response AP, respectively.

[0032] 6. Cooperative R-TWT Negotiation To achieve this R-TWT cooperation, this specification describes a capability flag that indicates cooperative R-TWT enablement. If the cooperative R-TWT capability flag is set to true, an AP should be able to cooperate during R-TWT negotiation with neighboring APs that also set this cooperative R-TWT capability flag to true. The following information is required from the cooperative BSSs before cooperative R-TWT negotiation:

[0033] (a) Implementations are required to compensate for Timing Synchronization Function (TSF) and Target Beacon Transmission Time (TBTT) offsets / mismatches of cooperative BSSs. An AP can obtain neighbor report information for a BSS(s) through measurement reports received from STAs within the BSS, or obtain the information through a management interface or from a distribution system (DS). Neighbor reports contain information including BSSID, primary channel, TSF offset, beacon interval, and other information necessary for the specific situation or application of the reported neighbor BSS.

[0034] (b) Information is needed to understand the channel information of neighboring BSS(s). In at least one embodiment, an AP maintains a list of channel information corresponding to its neighboring APs. The channel information can be obtained from neighbor reports received from neighboring AP(s). In at least one embodiment, the list of channel information can be included in an AP Channel Report element carried in a beacon frame.

[0035] The channel information corresponds to an operational class indicating (i) the frequency corresponding to the channel number, (ii) the available channel center frequencies, (iii) the maximum available channel width, and (iv) any other information required for the particular implementation(s).

[0036] (c) In some cases, an AP can benefit from understanding (acquiring and recognizing) the link IDs of neighboring cooperative BSSs. Because the link ID is a numeric value corresponding to a tuple consisting of the operating class, operating channel, and BSSID of the AP on that link, an AP requesting the link ID of a neighboring BSS needs to understand the explicit link ID value corresponding to the operating class, operating channel, and BSSID tuple of the AP on that link. APs can also benefit from understanding (acquiring and recognizing) the TID-to-Link (T2L) mapping of neighboring cooperative BSSs. Frame exchanges are used to exchange this information between BSSs that have the cooperative R-TWT capability flag set to true before or during cooperative inter-BSS R-TWT negotiation.

[0037] The exchanged frames shall carry the following information: (a) TID-To-Link Mapping element based on the current IEEE 802.11be specification: Draft P802.11be_D5.0, "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications - Amendment 8: Enhancements for extremely high throughput (EHT)," November 2023. (b) A LinkID-To-Channel-BSSID Mapping element, which in this disclosure is designed to indicate the mapping of a Link ID to a tuple of operating class, operating channel, and BSSID of an AP on the link. (c) A cooperative R-TWT capability flag designed in the present disclosure that, when set to true, indicates that the STA that transmitted this frame supports cooperative R-TWT scheduling with the R-TWT cooperative response BSS in the frequency domain when an overlapping R-TWT SP occurs in the time domain.

[0038] 6.1. Cooperative R-TWT Negotiation in the Frequency Domain To achieve frequency division, cooperative TWT negotiation can be performed at the link level or the channel level. Example 1 (below) is used to illustrate this link-level negotiation process.

[0039] 4-1 and 4-2 show a communication diagram 110 for negotiating R-TWT membership at the link level as Example 1. The diagram shows interactions between AP1 84 on L1, STA1 80 on L1, AP3 92 on L1, and AP4 94 on L2.

[0040] STA1 sends an R-TWT request frame 112 to its associated AP1 on Link 1 (L1) requesting or proposing to operate on L1 during the negotiated R-TWT SP(ID:x).

[0041] AP1 receives (114) an R-TWT request frame 114 from STA1 and transmits an R-TWT cooperation request frame 116 to AP3 in the R-TWT cooperation response BSS on link 1 (L1). In the R-TWT cooperation request frame, a TWT element with an R-TWT channel field indicates the currently negotiated R-TWT information with the proposed / requested link (L1) of the corresponding R-TWT SP in the R-TWT cooperation request BSS. The proposed / requested link (L1) is determined according to the proposal / request of the R-TWT requesting STA or the selection of the R-TWT scheduling AP.

[0042] AP3 receives 118 an R-TWT collaboration request frame 116 from AP1 over link 1 (L1) and should check the R-TWT negotiation information of the R-TWT collaboration request BSS to determine whether the negotiated R-TWT SP(ID:x) overlaps with any of the scheduled / negotiated R-TWT SP(s) from its own BSS on L1. AP3 responds to AP1 with an R-TWT collaboration response frame 120 indicating acceptance of allocating link L1 requested in the corresponding R-TWT SP(ID:x) to the R-TWT collaboration request BSS.

[0043] AP1 receives the R-TWT cooperation response frame from AP3 (122) and should respond with an Ack frame 124 indicating successful reception, which is found to be received by AP3 (126). AP1 then transmits an R-TWT response frame 128 to STA1 indicating acceptance of the R-TWT schedule for R-TWT SP(ID:x), which is received by STA1 (130).

[0044] STA3 sends an R-TWT request frame 132 over link 1 (L1) to its associated AP3 requesting / proposing to operate on L1 during the negotiated R-TWT SP(ID:y).

[0045] AP3 receives an R-TWT request frame 132 from STA3 requesting / proposing to operate on L1 during an R-TWT SP(ID:y) that overlaps with an R-TWT SP(ID:x) on L1 scheduled for the R-TWT cooperation request BSS (134). AP3 responds by sending an R-TWT response frame 136 to STA3 indicating that the request / proposal to operate on L1 is not accepted and that a different link (L2) is requested / proposed for the negotiated R-TWT SP(ID:y).

[0046] STA3 receives (138) an R-TWT response frame 136 from AP3 and allows STA4, which belongs to the same non-AP MLD2 as STA3, to send an R-TWT request frame 140 on link 2 (L2) indicating a request / proposition to operate on L2 during the negotiated R-TWT SP(ID:y).

[0047] AP4 receives (142) an R-TWT request frame 140 from STA4 and responds by transmitting an R-TWT response frame 144 indicating acceptance of the R-TWT schedule proposed / requested in the received R-TWT request frame. STA4 receives (146) the R-TWT response frame 144 from AP4.

[0048] AP1 transmits a beacon frame 148 over link 1, and STA1 receives the beacon frame 148 from AP1 over link 1 (150). AP3 transmits a beacon frame over link 1 (152), and STA3 receives the beacon frame 152 from AP3 over link 1 (154). AP4 transmits a beacon frame over link 2 (156), and STA4 receives the beacon frame 156 from AP4 over link 2 (158). It should be understood that, as specified in 802.11 REVme, beacon frames can be used to carry broadcast TWT elements that indicate a broadcast TWT SP schedule, such as a target wake time and a TWT wake interval.

[0049] When R-TWT SP(ID:x) 160 starts, STA1 transmits UL MU PPDU 162, AP1 receives it (164) and transmits Block Ack (BA) 172, which STA1 receives on L1 (174).

[0050] When the R-TWT SP(ID:y) 166 starts, STA4 transmits a UL MU PPDU 168, which AP4 receives (170) and transmits a Block Ack (BA) 176, which STA4 receives on L2.

[0051] 6.2. R-TWT Membership Negotiation at the Channel Level If users from across BSSs map TID(s) to only one link corresponding to the same operating class and operating channel, they cannot negotiate R-TWT membership at the link level. A more granular frequency allocation is needed; that is, R-TWT membership should be negotiated at the channel level. Examples 2 and 3 are used to show how this works for channel-level negotiation.

[0052] 5-1 and 5-2 show a communication diagram 210 of Example 2 illustrating negotiating R-TWT membership at the channel level without using a trigger-enabled R-TWT SP. This diagram shows interactions between AP1 84 on L1, STA1 80 on L1, AP3 92 on L1, and STA3 88 on L1. STA3 is an R-TWT member STA of an R-TWT SP (ID: x) on Link 1 (L1) that is not a trigger-enabled R-TWT SP.

[0053] The initial negotiation process for R-TWT SP(ID:x) is not shown. When R-TWT SP(ID x) 212 begins, STA3 transmits a UL MU PPDU 214, which the associated AP3 receives (216) and transmits a Block Ack (BA) frame 218 on all channels, which is received by STA3 (220).

[0054] STA1 sends an R-TWT request frame 222 on link 1 (L1) to its associated AP1, regardless of whether it indicates the requested / proposed channel information (CH1) to operate during this R-TWT SP if the negotiated R-TWT SP (ID:y) overlaps with any inter-BSS R-TWT SP.

[0055] AP1 receives the R-TWT request frame from STA1 (222) and transmits an R-TWT cooperation request frame 226, which is received by AP3 in the R-TWT cooperation response BSS over link 1 (L1). In the R-TWT cooperation request frame, the TWT element with the R-TWT channel field indicates the current negative R-TWT information with the proposed / requested channel (CH1) of the corresponding R-TWT SP in the R-TWT cooperation request BSS. The proposed / requested channel (CH1) is determined according to the proposal / request of the R-TWT requesting STA or the selection of the R-TWT scheduling AP.

[0056] AP3 receives the R-TWT cooperation request frame 228 from AP1 on link 1 (L1), checks the R-TWT negotiation information of the R-TWT cooperation request BSS, and determines that the negotiated R-TWT SP (ID:y) overlaps with the scheduled R-TWT SP (ID:x) from its own BSS. AP3 should respond with an R-TWT cooperation response frame 230 indicating acceptance of allocating the requested channel CH1 in the corresponding R-TWT SP (ID:y) to the R-TWT cooperation request BSS.

[0057] AP1 receives an R-TWT collaboration response frame 230 from AP3 (232) and should respond with an Ack frame 234 indicating successful receipt, which is seen to be received by AP3 (236). AP1 then transmits an R-TWT response frame 238 to STA1 indicating acceptance of the allocation of channel (CH1) in R-TWT SP(ID:y), which is seen to be received by STA1 (240).

[0058] AP3 should send an unsolicited R-TWT response frame 242 to the R-TWT member STAs of R-TWT SP(ID:x) including STA3, and it is known that STA3 receives this response frame (244). In the R-TWT response frame, AP3 should indicate updated negative R-TWT information with the proposed / requested channel (CH2) of the corresponding R-TWT SP(ID:x).

[0059] In this example, STA3 agrees to an updated channel assignment when it receives an unsolicited R-TWT Response frame from AP3. STA3 transmits a new R-TWT Request frame 246 containing the proposed / requested update channel (CH2) for the corresponding R-TWT SP(ID:x), which is received by AP3. AP3 then optionally transmits an R-TWT Response frame 250 indicating acceptance of the proposed / requested update of channel (CH2), which is seen to be received by STA3 (252).

[0060] AP1 transmits a beacon frame 254 over link 1, and STA1 receives the beacon frame 254 from AP1 over link 1 (256). AP3 transmits a beacon frame 258 over link 1, and STA3 receives the beacon frame 258 from AP3 over link 1 (260).

[0061] The R-TWT SP(ID:y) negotiated between STA1 and AP1 is not a trigger-enabled R-TWT SP. When the R-TWT SP(ID:y) 262 starts, STA1 transmits a UL MU PPDU 266 using the negotiated channel (CH1), which AP1 receives (264) and transmits a Block Ack (BA) frame 274, which is seen to be received by AP3 (276).

[0062] When R-TWT SP(ID:x) 268 starts, STA3 transmits a UL MU PPDU 270 using the negotiated channel (CH2), which AP3 receives (272) and transmits a Block Ack (BA) frame 278, which is received by STA3 (280).

[0063] 6.3. Triggered Channel-Level R-TWT Membership Negotiation 6-1 and 6-2 show a communication diagram 310 of Example 3 illustrating negotiating R-TWT membership at the channel level using trigger-enabled R-TWT SP. The diagram shows interactions between AP1 84 on L1, STA1 80 on L1, AP3 92 on L1, and STA3 88 on L1. The initial negotiation process of R-TWT SP(ID:x) is not shown.

[0064] STA3 is an R-TWT member STA of R-TWT SP(ID:x) running a trigger-enabled R-TWT SP on link 1 (L1). AP3 sends a basic trigger 312, which is received by STA3 (314), so STA3 initiates an R-TWT SP(ID x) 316 on all channels and sends a UL MU PPDU 318, which the associated AP3 receives (320) and sends a Block Ack (BA) frame 322, which is received by STA3.

[0065] STA1 transmits an R-TWT request frame 326, whether or not indicating the requested / proposed channel information (CH1) to operate during this R-TWT SP if the negotiated R-TWT SP (ID:y) overlaps with any inter-BSS R-TWT SP, which is received by its associated AP1 on link 1 (L1) (328).

[0066] In response to receiving this request, AP1 transmits an R-TWT cooperation request frame 330, which is received by AP3 in the R-TWT cooperation response BSS over link 1 (L1) (332). In the R-TWT cooperation request frame, a TWT element with an R-TWT channel field indicates the currently negotiated R-TWT information with the proposed / requested channel (CH1) of the corresponding R-TWT SP in the R-TWT cooperation request BSS. The proposed / requested channel (CH1) is determined based on the proposal / request of the R-TWT requesting STA or according to the selection of the R-TWT scheduling AP.

[0067] Upon receiving the R-TWT cooperation request frame from AP1 on link 1 (L1), AP3 checks the R-TWT negotiation information of the R-TWT cooperation request BSS to determine whether the negotiated R-TWT SP(ID:y) overlaps with a scheduled / negotiated R-TWT SP, such as R-TWT SP(ID:x) from its own BSS. AP3 should respond to AP1 with an R-TWT cooperation response frame 334 indicating acceptance of allocating the requested channel CH1 to the R-TWT cooperation request BSS in the corresponding R-TWT SP(ID:y).

[0068] AP1 receives (336) an R-TWT cooperation response frame 334 from AP3 and responds with an Ack frame 338 indicating successful receipt, and AP3 acknowledges (340) that it has received the Ack. AP1 then transmits an R-TWT response frame 342 to STA1 indicating acceptance of the allocation of a channel (CH1) to STA1 during R-TWT SP(ID:y). STA1 receives (344) a response frame 344 from AP1.

[0069] AP3 sends an unsolicited R-TWT response frame 346 to the R-TWT member STAs of R-TWT SP(ID:x), including STA3. In the R-TWT response frame, AP3 should indicate the updated negotiation R-TWT information with the proposed / requested channel (CH2) of the corresponding R-TWT SP(ID:x).

[0070] STA3 can be seen to receive the unsolicited R-TWT response frame 346 from AP3 and, after agreeing to the updated channel assignment, transmit a new R-TWT request frame 350 with the proposed / requested updated channel (CH2) for the corresponding R-TWT SP(ID:x) to AP3. AP3 receives (352) the request frame 350 and optionally transmits an R-TWT response frame 354 in response indicating acceptance of the proposed / requested channel (CH2) update.

[0071] AP1 transmits a beacon frame 358 over link 1, and STA1 receives the beacon frame 358 from AP1 over link 1 (360). AP3 transmits a beacon frame 362 over link 1, and STA3 receives the beacon frame 362 from AP3 over link 1 (364).

[0072] The R-TWT SP(ID:y) negotiated between STA1 and AP1 is a trigger-enabled R-TWT SP. When the R-TWT SP(ID:y) 366 starts, AP1 sends a BT frame 368 to STA1 using the negotiated channel (CH1) to trigger an UL MU PPDU 376. AP1 receives the UL MU PPDU (378) and responds with a Block Ack (BA) frame 384, which is received (386).

[0073] This figure shows that during the above time frame, R-TWT SP(ID:x) 367 starts, AP3 sends BT frame 370 to STA3 using the updated negotiated channel (CH2), STA3 receives it (374) and initiates UL MU PPDU 380, which is received by AP3 (382). AP3 responds to successful reception with BA 388, which is received by STA3 (390).

[0074] 7. Flow Diagram 7-1 through 7-3 illustrate an example embodiment 450 of R-TWT negotiation performed from the AP side. In FIG. 7-1, the AP indicates support for inter-BSS cooperative R-TWT by setting the cooperative R-TWT capability flag introduced in Section 6 (452). Next, the AP obtains neighbor report information and maintains a list of channel information for cooperative neighbor BSSs (454). The AP then exchanges link ID information and TID-to-link mapping information with the cooperative neighbor BSSs (456).

[0075] Next, in FIG. 7-2, the AP checks 458 whether it has received an R-TWT request indicating channel information. If a request is received, the AP negotiates with a cooperative neighbor BSS to determine whether an overlapping inter-BSS R-TWT SP occurs, in block 460. Next, it determines, in check 462, whether an overlapping R-TWT SP is indicated by the cooperative neighbor BSS. If no overlap exists, execution proceeds to block 464 of FIG. 7-3 to negotiate with the R-TWT requesting STA to use all channels for the R-TWT SP, after which the process ends.

[0076] On the other hand, if an overlap is detected in block 462 of FIG. 7-2, block 466 of FIG. 7-3 is reached, where the AP negotiates with the cooperating neighboring BSSs to determine a different channel allocation for each of the overlapping inter-BSS T-TWT SPs. The AP then negotiates with the R-TWT requesting STA regarding the allocation of a channel(s) for the R-TWT SP (468), with the process then terminating.

[0077] Returning to the description of check 458 of FIG. 7-2, if the AP has not received an R-TWT request frame indicating channel information, block 470 is reached. The AP negotiates 470 with a neighboring cooperative BSS to determine whether there are any overlapping inter-BSS R-TWT SPs on the link. Next, check 472 determines whether an overlap is indicated by the neighboring cooperative BSS. If an overlap is indicated, the AP negotiates with the neighboring cooperative BSS to determine the allocation of a different link for each of the overlapping inter-BSS R-TWT SPs in block 474 of FIG. 7-3. The AP then negotiates with the R-TWT requesting STA with the assigned link for the R-TWT SP, after which the process ends.

[0078] On the other hand, if check 472 in FIG. 7-2 determines that there are no overlapping R-TWT SPs, then the AP negotiates with the R-TWT requesting STA to use the original link for the R-TWT SP in block 478 in FIG. 7-3, and the process ends.

[0079] 8-1-8-2 illustrate an example embodiment 490 of R-TWT negotiation performed from the non-AP side. A non-AP STA sends an R-TWT request frame to its associated AP 492. A check 494 is performed to determine if the non-AP STA has proposed or requested channel information.

[0080] If the non-AP STA proposed or requested channel information, it receives an R-TWT response frame from the associated AP indicating the assigned channel(s) for the R-TWT SP in block 496. It determines whether the assigned channel is different from the proposed or requested channel in check 498. If there is no change, the process ends; otherwise, the non-AP STA transmits an R-TWT request frame to the associated AP in block 500 indicating different channel information, after which the process returns to block 496.

[0081] Returning to consideration of block 494, if there is no information regarding a proposed or requested channel, execution reaches block 502 of FIG. 8-2, where an R-TWT response frame is received from the associated AP indicating an assigned link for the R-TWT SP (502). In check 504, it is determined whether the assigned link is different from the current link. If not, the process ends. If different, in block 506, the non-AP STA allows other STAs belonging to the same non-AP STA MLD to send R-TWT request frames to the associated AP on different links. Next, in block 508, the other STAs belonging to the same non-AP STA MLD receive an R-TWT response frame from the associated AP indicating an assigned link for the R-TWT SP, after which execution returns to check 504.

[0082] 8. Frame Format 8.1. Link ID-to-Channel BSSID Mapping Element FIG. 9 illustrates an example embodiment 510 of a Link ID-to-Channel-BSSID Mapping element format. The Element ID is used to identify the element, and the Length field indicates the number of octets in the element, excluding the Element ID and Length fields. In accordance with the present disclosure, the Link ID-to-Channel-BSSID Mapping Control field is designed to indicate the mapping of a Link ID to a tuple of the operating class, operating channel, and BSSID of the AP on that link. There are also optional Link ID 1 Mappings through Link ID n Mappings, where n is shown as 15 in this specification as an example, but is not limited thereto.

[0083] 10 illustrates an example embodiment 530 of subfields within the Link ID-to-Channel BSSID Mapping Control field shown in FIG. 9. The Link ID Mapping Size subfield indicates the length of the Link ID Mapping n field. The Link ID Mapping Presence Indicator subfield indicates whether a Link ID n mapping field is present within the Link ID-to-Channel BSSID Mapping element. The Cooperative R-TWT Capability flag is set to a first state (e.g., “1”) to indicate that the STA that transmitted this frame supports cooperative R-TWT scheduling with the R-TWT cooperation response BSS in the frequency domain when an overlapping R-TWT SP occurs in the time domain, and is set to a second state (e.g., “0”) otherwise.

[0084] 11 shows an example embodiment 550 of subfields within the Link ID n mapping field shown in FIG. 9 for the Link ID 1 through Link ID 15 mapping fields. The Link ID n mapping field indicates the mapping of Link ID n to the corresponding tuple of operating class, operating channel, and BSSID of the APs on that link. The Link ID subfield indicates the link ID to be mapped. The BSSID subfield indicates the BSSID of the AP that belongs to the AP MLD operating on this link. The Operating Class subfield specifies the operating class for which the Operating Channel field is valid. The Operating Channel indicates the channel operating on this link and may include a channel start frequency, channel spacing, channel set, channel center frequency index, and may include additional subfields depending on the application.

[0085] 8.2. TWT Elements for Channel / Link Level R-TWT Negotiation 12 illustrates an example embodiment 570 of a Broadcast TWT Parameter Set field format used in channel or link level cooperative R-TWT negotiation. The existing fields are Request Type, Target Wake Time, Nominal Minimum TWT Wake Duration, TWT Wake Interval Mantissa, and Broadcast TWT Information. This disclosure adds the following fields to the current Broadcast TWT Parameter Set field of the TWT element:

[0086] Of these added fields, the first field is an optional R-TWT Channel field, and the second field is a Switch Link field.

[0087] The TWT Channel field is present if the transmitting STA supports cooperative R-TWT, sets the Cooperative R-TWT Capability flag to true, and leaves the Link Switching field off (not present). If the transmitting STA does not support cooperative R-TWT, the TWT Channel field is not present.

[0088] The TWT Channels field contains a bitmap indicating the channels negotiated as temporary channels by the STA during an R-TWT SP that overlaps with other R-TWT SPs scheduled in the time domain by the BSS. Each bit in the bitmap corresponds to one minimum-width channel (e.g., 20 MHz) in the band in which the TWT responding STA's associated BSS is currently operating, with the least significant bit corresponding to the lowest-numbered channel among the BSS's operating channels.

[0089] Setting a position in the bitmap of a TWT channel field transmitted by a TWT requester STA to a first state (e.g., "1") indicates that operation using that channel as a temporary channel during the corresponding R-TWT SP is requested. Setting a position in the bitmap of a TWT responder STA to this first state (e.g., "1") indicates that operation using that channel as a temporary channel during the corresponding R-TWT SP is permitted.

[0090] An R-TWT requesting STA from an R-TWT cooperation requesting BSS may propose that its associated R-TWT scheduling AP allocate a channel for the negotiated R-TWT SP by indicating R-TWT channel information in an R-TWT request frame addressed to the associated AP.

[0091] Inter-BSS cooperative APs that support inter-BSS cooperative R-TWT exchange R-TWT cooperation request frames and R-TWT cooperation response frames that carry TWT elements including negotiated R-TWT channel information.

[0092] The R-TWT cooperation requesting AP sends an R-TWT cooperation request frame to the R-TWT cooperation responding AP from its BSS indicating the proposed channel for the R-TWT cooperation requesting STA in addition to other R-TWT negotiation information.

[0093] An R-TWT cooperation response AP from an OBSS that receives an R-TWT cooperation request frame should recognize whether inter-BSS scheduling of overlapping R-TWT SPs is possible in the time domain. If it is determined that overlapping inter-BSS SPs will occur, the R-TWT cooperation response AP should support scheduling of different channels for the overlapping inter-BSS R-TWT SPs. Therefore, if the R-TWT cooperation response AP accepts the proposed or requested channel information received from the R-TWT cooperation request frame, it should respond with an R-TWT cooperation response frame indicating acceptance of the channel assigned to the requesting BSS. If the R-TWT cooperation AP does not accept the proposed channel information, it should respond with an R-TWT cooperation response frame including an indication of rejection of the proposed channel or indicate a different channel for the R-TWT cooperation request BSS in the corresponding R-TWT SP. If overlapping inter-BSS SPs will not occur, in at least one embodiment, the R-TWT cooperation response AP should notify the R-TWT cooperation request AP accordingly. Therefore, the R-TWT cooperation response AP should respond with an R-TWT cooperation response frame carrying a TWT element with an R-TWT channel field indicating that the R-TWT cooperation request AP should schedule different channels as proposed in the R-TWT cooperation request frame and use all channels for the corresponding R-TWT SP.

[0094] An R-TWT cooperation response AP that transmits an R-TWT cooperation response frame indicating a channel allocation for an overlapping inter-BSS R-TWT SP must schedule the R-TWT members of the corresponding R-TWT SP in its own BSS not to use the channel indicated in the R-TWT cooperation response frame. This R-TWT cooperation response AP may transmit unsolicited R-TWT response frames or beacon frames indicating available channel information to the R-TWT member STAs of the corresponding R-TWT SP.

[0095] When the R-TWT cooperation request AP receives an R-TWT cooperation response frame indicating that the proposed or requested channel has been accepted by the R-TWT cooperation response BSS, it should schedule the R-TWT member STAs in its own BSS to use that channel during the corresponding R-TWT SP by indicating corresponding information in an R-TWT response frame or beacon frame. When the R-TWT cooperation request AP receives an R-TWT cooperation response frame indicating that the proposed or requested channel has been rejected by the cooperating BSS or a different channel has been proposed or requested, it should reflect the corresponding information to the R-TWT member STAs in an R-TWT response frame or beacon frame. When the R-TWT cooperation request AP receives an R-TWT cooperation response frame indicating that the negotiated R-TWT SP does not overlap with other R-TWT SPs from the R-TWT cooperation response BSS, it should schedule the R-TWT member STAs in its own BSS to use the entire channel (all channels) during the corresponding R-TWT SP by indicating corresponding information in an R-TWT response frame.

[0096] The Link Switch field is present if the transmitting STA supports cooperative R-TWT and sets the Cooperative R-TWT Capability flag to true, and the R-TWT Channel subfield is not used (present). If the transmitting STA does not support cooperative R-TWT, the Link Switch field is not included in the Broadcast TWT Parameter Set field.

[0097] The Link Switch field indicates the link ID negotiated by the STA as the temporary link to switch to during an R-TWT SP that overlaps in the time domain with another inter-BSS R-TWT SP.

[0098] If the TWT requester STA sets a link ID in the link switching field, it indicates that the link is requested to be used as a temporary link in the corresponding R-TWT SP. If the TWT responder STA sets a link ID in the link switching field, it indicates that the link is allowed to be used as a temporary link in the corresponding R-TWT SP.

[0099] The R-TWT scheduling AP shall propose or request a temporary link to be switched over during an R-TWT SP only if the proposed or requested link supports the TID(s) negotiated on the original link based on the TID-to-link mapping.

[0100] 8.3. Restricted TWT Schedule Information Subfield Figure 13 illustrates an example embodiment 590 of subfields within the Broadcast TWT Information field shown in Figure 12. The Restricted TWT Traffic Information present field is shown and is utilized as before. The Restricted TWT Schedule Information subfield of the present disclosure increases in size by at least one additional bit (e.g., originally 2 bits) with a new field value (e.g., "4") indicating an advertised R-TWT schedule where the R-TWT scheduling AP is likely to cooperate with another R-TWT scheduling AP from the OBSS. The Broadcast TWT ID and Broadcast TWT Persistence fields are also present and may be utilized as in previous 802.11be releases.

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

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

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

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

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

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

[0107] A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each connected to one or more antennas; (b) the station (STA) operates as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless communication protocol, the STA being configured as an independent STA or an STA within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory that stores instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN), the instructions, when executed by the processor, causing (e)(i) the STA to communicate with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless communication protocol, the STA being configured as either an access point (AP) STA or a non-AP STA. and (e)(ii) the STA is an inter-basic service set (BSS) AP capable of performing inter-BSS communication with overlapping BSSs (OBSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and participating in such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding restricted target wake time (R-TWT) service periods (SPs); and (e)(iii) the inter-BSS AP, as well as other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag transmitted to the cooperative BSS.

[0108] A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each connected to one or more antennas; (b) the station (STA) operates as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism in a wireless communication protocol, the STA being configured as an independent STA or an STA within a multi-link device (MLD); (c) a processor in the STA; and (d) an IEEE 802.11 standard.and (e) a non-transitory memory storing instructions executable by a processor to wirelessly communicate with other STAs on a wireless local area network (WLAN), wherein (e) the instructions, when executed by the processor, cause (e)(i) the STA to operate as either an access point (AP) STA or a non-AP STA in a wireless communication protocol, communicating physical layer protocol data units (PPDUs) to other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; and (e)(ii) the STA to perform inter-BSS communications with overlapping basic service sets (BSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and transmitting such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding restricted target wake time (R-TWT) service periods (SPs). An apparatus that is an inter-basic service set (BSS) AP capable of joining an SP, and that performs steps of a wireless communication protocol including: (e)(iii) the inter-BSS AP exchanging information from the cooperating BSSs before performing cooperative R-TWT negotiation; (e)(iv) the inter-BSS AP obtaining neighbor report information from one or more BSSs through measurement reports received from STAs in each BSS, obtaining the information from a management interface, or obtaining the information from a distribution system (DS); and (e)(v) the inter-BSS AP, and other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag that is sent to the cooperating BSS.

[0109] 1. A method for performing communications in a wireless network, comprising: (a) each wireless station (STA) operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism, the STA being configured as an independent STA or an STA within a multi-link device (MLD); (b) the STA operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that conveys physical layer protocol data units (PPDUs) to other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; and (c) the STA performs inter-BSS communications with overlapping basic service sets (BSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and transmitting such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding restricted target wake time (R-TWT) service periods (SPs). (d) the inter-BSS AP, and other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag that is transmitted to the cooperative BSS.

[0110] An apparatus or method that enables an inter-BSS device to support, negotiate, and participate in temporally overlapping cooperative R-TWT SPs scheduled on different links or different channels to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding R-TWT SPs.

[0111] An apparatus or method that allows an inter-BSS device to indicate support for inter-BSS cooperative R-TWT by setting a flag that allows transmission to a cooperative BSS.

[0112] An apparatus or method in which an inter-BSS AP should be aware of BSS information from a cooperative BSS prior to cooperative R-TWT negotiation.

[0113] An apparatus or method by which inter-BSS APs can cooperate with each other to negotiate R-TWT membership at the channel level.

[0114] An apparatus or method in which an AP obtains neighbor report information for a BSS(s) through measurement reports received from STAs within the BSS, or obtains the information through a management interface, or can obtain the information from a DSL, and the neighbor report includes information including BSSID, primary channel, TSF offset, beacon interval, and any other information of the reported neighbor BSS.

[0115] An apparatus or method in which an AP maintains a list of channel information corresponding to its neighboring APs, the channel information can be obtained from the AP's neighbor report, and the list of channel information is included in an AP Channel Report element carried in a beacon frame.

[0116] An apparatus or method in which an AP exchanges link ID information with a cooperating AP, indicating a link ID corresponding to a tuple consisting of an operating class, an operating channel, and a BSSID of the AP on that link.

[0117] The apparatus or method of any preceding implementation, wherein the AP exchanges TID-to-link mapping information with cooperative APs.

[0118] The apparatus or method of any preceding implementation, wherein the inter-BSS APs exchange information from cooperative BSSs before performing cooperative R-TWT negotiation.

[0119] An apparatus or method as described in any preceding implementation, wherein the inter-BSS AP obtains neighbor report information from one or more BSSs through measurement reports received from STAs within each BSS, or obtains the information from a management interface, or obtains the information from a distribution system (DS).

[0120] The apparatus or method of any preceding implementation, wherein the neighbor report includes information regarding the BSSID, primary channel, timing synchronization function (TSF) offset, and beacon interval of the reported neighbor BSS.

[0121] An apparatus or method as described in any preceding implementation, wherein the inter-BSS AP maintains a list of channel information for neighboring APs, and the channel information is obtained from reports from the neighboring APs, or the list of channels and associated information is included in an AP Channel Report element carried in a beacon frame.

[0122] An apparatus or method as described in any preceding implementation, wherein an inter-BSS AP exchanges link ID information with a cooperative AP of another BSS by indicating a link ID corresponding to a tuple consisting of an operating class, operating channel, and BSSID of the AP on the link.

[0123] The apparatus or method of any preceding implementation, wherein an inter-BSS AP exchanges TID-to-link mapping information with cooperative APs.

[0124] The apparatus or method of any preceding implementation, wherein an inter-BSS AP coordinates with inter-BSS APs of other BSSs to negotiate R-TWT membership at the channel level.

[0125] The apparatus or method of any preceding implementation, wherein a TWT Channel subfield is added within the Broadcast TWT Parameter Set field to negotiate with an inter-BSS AP of another BSS, and the TWT Channel subfield is present if the transmitting STA supports cooperative R-TWT and the Link Switching field is not present, and otherwise the TWT Channel field is not present.

[0126] An apparatus or method as described in any preceding implementation, wherein an inter-BSS AP performing R-TWT scheduling and an R-TWT requesting STA negotiate for an R-TWT SP to operate on a particular channel indicated in the TWT channel field through an exchange of R-TWT request frames and R-TWT response frames.

[0127] The apparatus or method of any preceding implementation, wherein a STA acting as an inter-BSS AP that transmitted either an R-TWT request frame or an R-TWT response frame negotiates with an inter-BSS AP from a cooperative BSS to determine whether the R-TWT SPs overlap in the time domain, in which case a different channel is assigned for each of the overlapping inter-BSS R-TWT SPs.

[0128] An apparatus or method as described in any preceding implementation, wherein a STA acting as an inter-BSS AP that transmitted either an R-TWT request frame or an R-TWT response frame negotiates with an inter-BSS AP from a cooperative BSS to determine whether the R-TWT SPs overlap in the time domain, and if no overlap exists, the inter-BSS AP transmitting the R-TWT request frame requests all channels to be assigned to R-TWT member STAs of the corresponding negotiated R-TWT SP.

[0129] An apparatus or method as described in any preceding implementation, wherein a STA acting as an inter-BSS AP cooperates with an inter-BSS AP of another BSS to negotiate R-TWT membership at the link level that does not violate TID-to-link mapping.

[0130] An apparatus or method as described in any preceding implementation, wherein a subfield within the Broadcast TWT Parameter Set field of the TWT information element includes information regarding a Link Switching field that is present when the transmitting STA supports cooperative R-TWT and the R-TWT Channel subfield is not present.

[0131] An apparatus or method described in any preceding implementation, in which a STA, when acting as an R-TWT requesting STA, sends an R-TWT request frame to an AP acting as an associated R-TWT scheduling AP on a link in which an R-TWT channel subfield is not presented in the TWT element, indicating that the STA can negotiate with the R-TWT SP to utilize the duration of the entire link.

[0132] The apparatus or method of any preceding implementation, wherein a STA acting as an R-TWT cooperation request AP negotiates with another STA in a cooperative BSS acting as an R-TWT cooperation response AP, the negotiation determining whether R-TWT SPs overlap in the time domain on the same link, and a different link is assigned for each of the overlapping inter-BSS R-TWT SPs.

[0133] An apparatus or method as described in any preceding implementation, wherein a STA acting as an R-TWT cooperation request AP negotiates with another STA acting as an R-TWT cooperation response AP from a cooperative BSS to determine whether R-TWT SPs overlap in the time domain on the same link, and if no overlap exists, the R-TWT cooperation request AP assigns the entire link to the R-TWT member STA of the corresponding negotiated R-TWT SP.

[0134] An apparatus or method as described in any preceding implementation, wherein a STA acting as an R-TWT scheduling AP sends a proposed or requested link for use by an R-TWT requesting STA when an overlapping inter-BSS R-TWT SP is predicted on the original link.

[0135] An apparatus or method as described in any preceding implementation, wherein a STA acting as an R-TWT scheduling AP sends an indication to an R-TWT requesting STA indicating that the original link should be used if no overlapping inter-BSS R-TWT SPs are predicted on the original link.

[0136] An apparatus or method as described in any preceding implementation, wherein a STA acting as an R-TWT requesting STA notifies another STA belonging to the same non-AP MLD to negotiate an R-TWT SP on a different link as proposed or requested as indicated in a received R-TWT response frame.

[0137] An apparatus or method as described in any preceding implementation, wherein a STA acting as an R-TWT scheduling AP proposes or requests the use of a different link to switch to during an R-TWT SP if the proposed or requested link supports the TID(s) negotiated on the original link based on a TID-to-link mapping.

[0138] An apparatus or method as described in any preceding implementation, wherein a restricted TWT schedule information subfield of a broadcast TWT information subfield in a TWT element is configured to indicate the advertised scheduling.

[0139] An apparatus or method as described in any preceding implementation, wherein a Broadcast TWT Information subfield in the TWT element is set to a unique value indicating an advertised R-TWT schedule in which a STA operating in the R-TWT scheduling AP is expected to cooperate with another R-TWT scheduling AP from the OBSS.

[0140] An apparatus or method as recited in any preceding implementation, wherein inter-BSS APs can cooperate with each other to negotiate R-TWT membership at the channel level.

[0141] An apparatus or method as described in any preceding implementation, wherein inter-BSS APs can cooperate with each other to negotiate R-TWT membership at the link level that does not violate TID-to-link mapping.

[0142] An apparatus or method as described in any preceding implementation, wherein one subfield is added within the Current Broadcast TWT Parameter Set field of the TWT element, which is a TWT Channel field, and the TWT Channel field is present if the transmitter STA supports cooperative R-TWT and the Link Switching field is not present, and otherwise the TWT Channel field is not present.

[0143] An apparatus or method as described in any preceding implementation, wherein the R-TWT scheduling AP and the R-TWT requesting STA negotiate the R-TWT SP to operate on a particular channel indicated in the TWT channel field through an exchange of R-TWT request frames and R-TWT response frames.

[0144] The apparatus or method of any preceding implementation, wherein an R-TWT cooperation request AP and an R-TWT cooperation response AP from a cooperative BSS negotiate to determine whether the R-TWT SPs overlap in the time domain and assign a different channel for each of the overlapping inter-BSS R-TWT SPs.

[0145] An apparatus or method as described in any preceding implementation, wherein an R-TWT cooperation request AP and an R-TWT cooperation response AP from a cooperative BSS negotiate to determine whether the R-TWT SPs do not overlap in the time domain and notify the R-TWT cooperation request AP to allocate all channels to the R-TWT member STAs of the corresponding negotiated R-TWT SPs.

[0146] The apparatus or method of any preceding implementation further includes adding one subfield within the filed current broadcast TWT parameter set of the TWT element that is a TWT channel field. The TWT channel field is present if the transmitter STA supports cooperative R-TWT and the link switching field is not present. Otherwise, the TWT channel field is not present.

[0147] An apparatus or method as described in any preceding implementation, wherein the R-TWT scheduling AP and the R-TWT requesting STA negotiate the R-TWT SP to operate on a particular channel indicated in the TWT channel field through an exchange of R-TWT request frames and R-TWT response frames.

[0148] The apparatus or method of any preceding implementation, wherein the R-TWT cooperation request AP and the R-TWT cooperation response AP from the cooperating BSSs negotiate to determine whether the R-TWT SPs overlap in the time domain and allocate a different channel for each of the overlapping inter-BSS R-TWT SPs.

[0149] The apparatus or method of any preceding implementation, wherein the R-TWT cooperation request AP and the R-TWT cooperation response AP from the cooperative BSS negotiate to determine whether the R-TWT SPs do not overlap in the time domain and notify the R-TWT cooperation request AP to allocate all channels to the R-TWT member STAs of the corresponding negotiated R-TWT SPs.

[0150] The term "implementation," as used herein, is intended to include, without limitation, any embodiment, example, or other form for practicing the techniques described herein.

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

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

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

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

[0155] Use of relative terms such as first and second, top and bottom, etc. in this document is used merely to distinguish one entity or action from another and does not necessarily require or imply any such actual relationship or ordering between such entities or actions.

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

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

[0158] Additionally, amounts, ratios, and other numerical values ​​may be presented in range format herein. Such range formats are used for convenience and simplicity, and should be understood to include numerical values ​​explicitly specified as the limits of the range, but also to include all individual numerical values ​​or subranges within the range, as if each such numerical value and subrange were expressly set forth. For example, a ratio within the range of about 1 to about 200 should be understood to include the explicitly recited limits of about 1 and about 200, but also 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.

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

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

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

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

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

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

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

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

[0167] 510 Link ID-to-Channel BSSID Mapping Element Format Embodiments

Claims

1. A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each modem coupled to one or more antennas; (b) the station (STA) operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism, and the STA is configured as an independent STA or an STA within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN); and Furthermore, (e) the instructions, when executed by the processor: (i) the STA operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates physical layer protocol data units (PPDUs) to other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; (ii) the STA is an Inter-BSS AP capable of performing inter-BSS communications with overlapping BSSs (OBSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and participating in such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding Restricted Target Wake Time (R-TWT) Service Periods (SPs); (iii) the inter-BSS AP, and other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag that is transmitted to the cooperative BSS; performing steps of a wireless communication protocol including: An apparatus characterized in that

2. Inter-BSS APs exchange information from cooperative BSSs before performing cooperative R-TWT negotiation; 10. The apparatus of claim 1.

3. The inter-BSS AP obtains neighbor report information from one or more OBSSs through measurement reports received from STAs in each BSS, or obtains information from a management interface, or obtains information from a distribution system (DS); 10. The apparatus of claim 1.

4. The neighbor report includes information about the BSSID, primary channel, timing synchronization function (TSF) offset, and beacon interval of the reported neighbor BSS.

4. The apparatus of claim 3.

5. The inter-BSS AP maintains a list of channel information for neighboring APs, the channel information being obtained from reports from the neighboring APs, or the list of channels and associated information being included in an AP Channel Report element carried in a beacon frame.

4. The apparatus of claim 3.

6. the inter-BSS AP exchanging link ID information with a cooperating AP of another BSS by indicating a link ID corresponding to a tuple consisting of an operating class, an operating channel, and a BSSID of the AP on the link; 4. The apparatus of claim 3.

7. The inter-BSS AP exchanges TID-to-link mapping information with the cooperative AP; 4. The apparatus of claim 3.

8. The Inter-BSS AP negotiates R-TWT membership at the channel level in cooperation with Inter-BSS APs of other BSSs; 10. The apparatus of claim 1.

9. To negotiate with an inter-BSS AP of another BSS, a TWT channel subfield is added in the broadcast TWT parameter set field, and the TWT channel subfield is present if the transmitting STA supports cooperative R-TWT and the link switching field is not present, otherwise the TWT channel field is not present; 9. The apparatus of claim 8.

10. The inter-BSS AP performing R-TWT scheduling and the R-TWT requesting STA negotiate for the R-TWT SP to operate on a specific channel indicated in the TWT channel field through the exchange of R-TWT request frames and R-TWT response frames; 9. The apparatus of claim 8.

11. The STA acting as an inter-BSS AP that transmitted either an R-TWT request frame or an R-TWT response frame negotiates with the inter-BSS AP from the cooperating BSS to determine whether the R-TWT SPs overlap in the time domain, in which case a different channel is assigned for each of the overlapping inter-BSS R-TWT SPs; 11. The apparatus of claim 10.

12. A STA acting as an inter-BSS AP that transmitted either an R-TWT request frame or an R-TWT response frame negotiates with an inter-BSS AP from a cooperative BSS to determine whether the R-TWT SPs overlap in the time domain, and if no overlap exists, the inter-BSS AP transmitting the R-TWT request frame requests all channels to be assigned to the R-TWT member STAs of the corresponding negotiated R-TWT SPs; 11. The apparatus of claim 10.

13. A STA acting as an inter-BSS AP cooperates with inter-BSS APs of other BSSs to negotiate R-TWT membership at the link level that does not violate TID-to-link mapping; 10. The apparatus of claim 1.

14. A subfield in the Broadcast TWT Parameter Set field of the TWT information element contains information about the link switching field that is present if the transmitting STA supports cooperative R-TWT and the R-TWT Channel subfield is not present; 14. The apparatus of claim 13.

15. When the STA acts as an R-TWT requesting STA, it sends an R-TWT request frame to an AP acting as an associated R-TWT scheduling AP on a link in which an R-TWT channel subfield is not presented in the TWT element, indicating that the STA can negotiate with the R-TWT SP to utilize the duration of the entire link; 14. The apparatus of claim 13.

16. A STA acting as an R-TWT cooperation request AP negotiates with another STA in the cooperative BSS acting as an R-TWT cooperation response AP, the negotiation determining whether the R-TWT SPs overlap in the time domain on the same link, and a different link is assigned for each of the overlapping inter-BSS R-TWT SPs; 14. The apparatus of claim 13.

17. A STA acting as an R-TWT cooperation request AP negotiates with another STA acting as an R-TWT cooperation response AP from a cooperative BSS to determine whether the R-TWT SPs overlap in the time domain on the same link, and if no overlap exists, the R-TWT cooperation request AP allocates the entire link to the R-TWT member STA of the corresponding negotiated R-TWT SP; 14. The apparatus of claim 13.

18. The STA acting as the R-TWT scheduling AP transmits a proposed or requested link for the R-TWT requesting STA to use when an overlapping inter-BSS R-TWT SP is predicted on the original link; 14. The apparatus of claim 13.

19. The STA acting as the R-TWT scheduling AP sends an indication to the R-TWT requesting STA indicating that the original link should be used if no overlapping inter-BSS R-TWT SP is expected on the original link; 20. The apparatus of claim 18.

20. A STA acting as an R-TWT requesting STA notifies another STA belonging to the same non-AP MLD to negotiate an R-TWT SP on a different link as proposed or requested as indicated in the received R-TWT response frame; 14. The apparatus of claim 13.

21. The STA acting as the R-TWT scheduling AP proposes or requests the use of a different link to be switched to during the R-TWT SP if the proposed or requested link supports the TID(s) negotiated on the original link based on the TID-to-link mapping; 14. The apparatus of claim 13.

22. The Restricted TWT Schedule Information subfield of the Broadcast TWT Information subfield within the TWT element is configured to indicate the advertised scheduling; 10. The apparatus of claim 1.

23. The Broadcast TWT Information subfield within the TWT element is set to a unique value indicating the advertised R-TWT schedule in which a STA operating at the R-TWT scheduling AP is expected to cooperate with another R-TWT scheduling AP from the OBSS; 23. The apparatus of claim 22.

24. A station device for communication in a wireless network, comprising: (a) at least one modem coupled to at least one radio frequency (RF) circuit, each modem coupled to one or more antennas; (b) the station (STA) operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism, and the STA is configured as an independent STA or an STA within a multi-link device (MLD); (c) a processor of the STA; and (d) a non-transitory memory storing instructions executable by the processor to wirelessly communicate with other STAs on an IEEE 802.11 wireless local area network (WLAN); and Furthermore, (e) the instructions, when executed by the processor: (i) the STA operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates physical layer protocol data units (PPDUs) to other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; (ii) the STA is an Inter-BSS AP capable of performing inter-BSS communications with overlapping BSSs (OBSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and participating in such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding Restricted Target Wake Time (R-TWT) Service Periods (SPs); (iii) the inter-BSS APs exchanging information from cooperative BSSs before performing cooperative R-TWT negotiation; (iv) the Inter-BSS AP obtaining neighbor report information from one or more OBSSs through measurement reports received from STAs in each BSS, or obtaining information from a management interface, or obtaining information from a distribution system (DS); (v) the inter-BSS AP, and other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag that is transmitted to the cooperative BSS; performing steps of a wireless communication protocol including: An apparatus characterized in that

25. 1. A method of performing communications in a wireless network, comprising: (a) each wireless station (STA) operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates with other STAs using a carrier sense multiple access / collision avoidance (CSMA / CA) mechanism, and the STA is configured as an independent STA or an STA within a multi-link device (MLD); (b) the STA operates in a wireless communication protocol as either an access point (AP) STA or a non-AP STA that communicates physical layer protocol data units (PPDUs) to other STAs using a carrier sense multiple access with collision avoidance (CSMA / CA) mechanism; (c) the STA is an inter-BSS AP capable of performing inter-BSS communications with overlapping BSSs (OBSSs), negotiating time-overlapping cooperative R-TWT SPs scheduled on different links or different channels, and participating in such cooperative R-TWT SPs to avoid inter-BSS interference of prioritized traffic scheduled to be transmitted during corresponding Restricted Target Wake Time (R-TWT) Service Periods (SPs); (d) the inter-BSS AP, and other inter-BSS APs and STAs on other BSSs, indicating support for inter-BSS cooperative R-TWT by setting a flag that is transmitted to the cooperative BSS; A method comprising:

Images