Patent Description:
Wireless local area network (WLAN) technology allows devices to access the internet in the <NUM>, <NUM>, <NUM> or <NUM> frequency bands. WLANs are based on the Institute of Electrical and Electronic Engineers (IEEE) <NUM> standards. The IEEE <NUM> family of standards aim to increase speed and reliability and to extend the operating range of wireless networks.

Multi-Access Point (MAP) coordination is one of the most important features for interference management in WI-FI (wireless fidelity) networks, which was developed by IEEE <NUM>. With MAP, multiple APs can cooperate together to enhance the performance of the network by smartly managing the co-channel interference (CCI) between one Basic Service Set (BSS) and other Overlapping Basic Service Sets (OBSSs). In IEEE <NUM>. 11ax standards, Spatial Reuse (SR), a simple coordination method, is introduced. In SR, APs coordinate their power transmission so that interference is controlled. However, in IEEE <NUM>. 11be standards, many other coordination techniques are under study considering power, frequency, and beamforming coordination. Each coordination technique requires a different level of information sharing between coordinating APs and has different data, resource allocation, and beamforming requirements.

In IEEE <NUM>. 11be standards, multiple terminologies are introduced for MAP coordination operations. A set of APs that can cooperate and coordinate their transmissions are called a coordinating set, and contains at least one coordinating AP and at least one coordinated AP. An AP that obtains a transmission opportunity (TXOP) is called the sharing AP while other APs in the coordinating set that participate in the actual transmission are called shared APs. Not every coordinated AP is a shared AP as some coordinated APs may not participate in the actual transmission. A sharing AP may be the same as the coordinating AP, or a hierarchical network may exist where a coordinating AP is different from a sharing AP and the coordinating AP is in communication with all shared and sharing APs.

MAP coordination would be essential for dense networks where multiple APs are required to provide better performance. The existence of multiple APs in dense networks causes more contention in the channel and less accessibility if coordination is not considered in addition to smart network planning.

Target Wake Time (TWT) is one of the important features of the IEEE <NUM>. 11ax amendment. TWT enables wake time negotiation between an AP and an associated station (STA) for improving power efficiency. With TWT operation, it suffices for a STA to only wake up at a pre-scheduled time negotiated with another STA or AP in the network. In IEEE <NUM>. 11ax standards, two types of TWT operation are possible - individual TWT operation and broadcast TWT operation. Individual TWT agreements can be established between two STAs or between a STA and an AP. On the other hand, with broadcast TWT operation, an AP can set up a shared TWT session for a group of STAs.

The negotiated parameters such as the wake interval, wake duration and initial wake time (offset) highly affect latency, throughput as well as power efficiency, which are directly related to QoS (quality of service) or customer experiences. Services with different traffic characteristics will have different TWT parameter configurations for better QoS. Additionally, the TWT configuration should adapt to network and service status variation.

Restricted TWT (rTWT) operation, which is based on broadcast TWT operation, is a feature introduced with a view to providing better support for latency sensitive applications. Restricted TWT offers a protected service period for its member STAs by sending Quiet elements to other STAs in the BSS which are not members of the restricted TWT schedule, where the Quiet interval corresponding to the Quiet element overlaps with the initial portion of the restricted TWT SP. Hence, it gives more channel access opportunity for the restricted TWT member scheduled STAs, which helps latency-sensitive traffic flow.

Embodiments of the present disclosure provide methods and apparatuses for balancing a tradeoff between channel utilization and fairness during restricted TWT operation in a wireless network (e.g., a WLAN).

In one embodiment, a first AP device is provided, comprising a transceiver, a backhaul interface, and a processor operably coupled to the transceiver and backhaul interface. The transceiver is configured to transmit traffic to a first STA during a TXOP in a first TWT SP based on parameters of a first TWT operation between the first AP and the first STA, and to receive, from the first STA, an interference notification message that includes an indication that the first STA has detected interference with the traffic transmission caused by transmissions between a second STA and a second AP in the MAP coordinating set of APs. The backhaul interface is configured to transmit, to the second AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained the TXOP and (ii) the parameters of the first TWT operation, and to receive, from the second AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination. The processor is configured to determine, based on the MAP coordination response, whether to perform MAP coordination with the second AP during the TXOP, or whether to modify the parameters of the first TWT operation based on the interference notification message.

In another embodiment, a second AP device is provided, comprising a transceiver, a backhaul interface, and a processor operably coupled to the transceiver and backhaul interface. The transceiver is configured to transmit traffic to a second station (STA) in a second target wake time (TWT) service period (SP) based on parameters of a second TWT operation between the second AP and the second STA. The backhaul interface is configured to receive, from a first AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained a TXOP and (ii) parameters of a first TWT operation between the first AP and a first STA, and to transmit, to the first AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination. The processor is configured to determine, based on the MAP coordination announcement, the capabilities of the second AP pertaining to its participation in the MAP coordination.

In another embodiment, a method performed by the first AP is provided, including the step of receiving, from a first STA with which the first AP exchanges traffic in a first TWT SP based on parameters of a first TWT operation between the first AP and the first STA, an interference notification message that includes an indication that the first STA has detected interference with a traffic transmission from the first AP, the interference caused by transmissions between a second STA and a second AP in the MAP coordinating set of APs. The method further includes the steps of transmitting, to the second AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained a transmission opportunity (TXOP) and (ii) the parameters of the first TWT operation, receiving, from the second AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination, and determining, based on the MAP coordination response, whether to perform MAP coordination with the second AP during the TXOP, or whether to modify the parameters of the first TWT operation based on the interference notification message.

In another embodiment, a method performed by the second AP is provided, including the step of transmitting traffic to a second station (STA) in a second target wake time (TWT) service period (SP) based on parameters of a second TWT operation between the second AP and the second STA, receiving, from a first AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained a TXOP and (ii) parameters of a first TWT operation between the first AP and a first STA, and transmitting, to the first AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination, and determining, based on the MAP coordination announcement, the capabilities of the second AP pertaining to its participation in the MAP coordination.

As used herein, such terms as "1st" and "2nd," or "first" and "second" may be used to simply distinguish a corresponding component from another and does not limit the components in other aspect (e.g., importance or order).

The following documents and standards descriptions are hereby incorporated into the present disclosure as if fully set forth herein:.

Embodiments of the present disclosure recognize that, with respect to MAP coordination as introduced in <NUM>. 11be, whereby multiple APs cooperate together to enhance performance, although though power coordination through coordinated spatial reuse, beamforming coordination through nulling and joint transmission, and frequency coordination through coordinated orthogonal frequency division multiple access (OFDMA) are agreed as release-<NUM> features, each comes with some cost associated with it.

For example, in coordinated spatial reuse, power backoff is applied which causes performance degradation. Even though the performance degradation is more balanced with coordinated spatial reuse in <NUM>. 11be (compared to legacy spatial reuse in <NUM>. 11ax) because power backoff is applied in a balanced way between coordinating APs, the power backoff will still make the performance worse than the case without power backoff (if systems are able to mitigate the interference). In coordinated beamforming, nulling comes with the cost of cross-channel CSI measurements and also nulling causes beam misalignment for the served STA. In joint transmission, the overhead of data sharing along with tight time and phase synchronization requirements makes the implementation very challenging.

On the other hand, coordinated OFDMA mitigates the interference by allocating interfering links in different frequency resources. However, when operating on large frequency bandwidths, it becomes challenging to allocate orthogonal frequency resources and hence it may sometimes be necessary to operate in a smaller bandwidth to be able to utilize coordinated OFDMA.

Accordingly, embodiments of the present disclosure provide apparatuses and methods that maintain the performance while mitigating the interference with limited requirements on information sharing and limited synchronization requirements. For example, one approach is to coordinate between multiple APs in a time division multiple access (TDMA) manner. This can utilize many features existing in standards such as power saving modes and TWT features. However, the current standards do not provide enough tools to utilize TDMA cooperation between multiple APs. Information sharing between coordinating APs needs to be addressed in order to unleash the potential of such a level of coordination.

Some embodiments of the present disclosure provide a MAC-level coordination mechanism for MAP coordination utilizing TWT features of high efficiency (HE) and extremely high throughput (EHT) STAs that addresses the issue of interfering links in two or more different BSSs (e.g., a sharing AP's BSS and a shared AP's overlapping BSS) through time-duplexing TWT's service periods (SP) to be non-overlapping. These solutions are also extended to both legacy and non-legacy links and links that do not support power saving modes.

Some embodiments of the present disclosure provide a procedure for MAC-level negotiation and information sharing between APs in MAP coordination utilizing TWT features of HE and EHT STAs that addresses the issue of interfering links in two or more different BSSs (e.g., a sharing AP's BSS and a shared AP's overlapping BSS) through sharing TWT information among cooperating APs and facilitating the negotiation between those APs.

Embodiments of the present disclosure further recognize that in a dense deployment scenario where neighboring BSSs corresponding to two or more APs overlap each other, if one AP has an rTWT schedule for which the corresponding scheduled STAs fall in a geographic area that has overlap with a neighbor BSS, then the rTWT scheduled STAs would possibly face interference from the neighboring BSS's operation.

Since the objective of restricted TWT is to provide better protection for latency-sensitive traffic for its member STAs, embodiments of the present disclosure provide apparatuses and methods that handle interference from neighboring BSS activities during a restricted TWT service period by managing the Quiet interval in the neighboring BSS.

<FIG> illustrates an example wireless network <NUM> according to various embodiments of the present disclosure. The embodiment of the wireless network <NUM> shown in <FIG> is for illustration only.

The wireless network <NUM> includes access points (APs) <NUM> and <NUM>. The APs <NUM> and <NUM> communicate with at least one network <NUM>, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. The AP <NUM> provides wireless access to the network <NUM> for a plurality of stations (STAs) <NUM>-<NUM> within a coverage area <NUM> of the AP <NUM>. The APs <NUM>-<NUM> may communicate with each other and with the STAs <NUM>-<NUM> using WI-FI or other WLAN communication techniques.

Depending on the network type, other well-known terms may be used instead of "access point" or "AP," such as "router" or "gateway. " For the sake of convenience, the term "AP" is used in this disclosure to refer to network infrastructure components that provide wireless access to remote terminals. In WLAN, given that the AP also contends for the wireless channel, the AP may also be referred to as a STA. Also, depending on the network type, other well-known terms may be used instead of "station" or "STA," such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device. " For the sake of convenience, the terms "station" and "STA" are used in this disclosure to refer to remote wireless equipment that wirelessly accesses an AP or contends for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile telephone or smartphone) or is normally considered a stationary device (such as a desktop computer, AP, media player, stationary sensor, television, etc.).

It should be clearly understood that the coverage areas associated with APs, such as the coverage areas <NUM> and <NUM>, may have other shapes, including irregular shapes, depending upon the configuration of the APs and variations in the radio environment associated with natural and man-made obstructions.

As described in more detail below, one or more of the APs may include circuitry and/or programming for sharing TWT information between APs to facilitate negotiations for MAP coordination in a WLAN. Although <FIG> illustrates one example of a wireless network <NUM>, various changes may be made to <FIG>. For example, the wireless network <NUM> could include any number of APs and any number of STAs in any suitable arrangement. Also, the AP <NUM> could communicate directly with any number of STAs and provide those STAs with wireless broadband access to the network <NUM>. Similarly, each AP <NUM>-<NUM> could communicate directly with the network <NUM> and provide STAs with direct wireless broadband access to the network <NUM>. Further, the APs <NUM> and/or <NUM> could provide access to other or additional external networks, such as external telephone networks or other types of data networks.

<FIG> illustrates an example AP <NUM> according to various embodiments of the present disclosure. The embodiment of the AP <NUM> illustrated in <FIG> is for illustration only, and the AP <NUM> of <FIG> could have the same or similar configuration. However, APs come in a wide variety of configurations, and <FIG> does not limit the scope of this disclosure to any particular implementation of an AP.

The AP <NUM> includes multiple antennas 204a-204n, multiple RF transceivers 209a-209n, transmit (TX) processing circuitry <NUM>, and receive (RX) processing circuitry <NUM>. The AP <NUM> also includes a controller/processor <NUM>, a memory <NUM>, and a backhaul or network interface <NUM>. The RF transceivers 209a-209n receive, from the antennas 204a-204n, incoming RF signals, such as signals transmitted by STAs in the network <NUM>. The RF transceivers 209a-209n down-convert the incoming RF signals to generate IF or baseband signals.

The RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from the TX processing circuitry <NUM> and up-converts the baseband or IF signals to RF signals that are transmitted via the antennas 204a-204n.

The controller/processor <NUM> can include one or more processors or other processing devices that control the overall operation of the AP <NUM>. For example, the controller/ processor <NUM> could control the reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 209a-209n, the RX processing circuitry <NUM>, and the TX processing circuitry <NUM> in accordance with well-known principles. The controller/processor <NUM> could support additional functions as well, such as more advanced wireless communication functions. For instance, the controller/processor <NUM> could support beam forming or directional routing operations in which outgoing signals from multiple antennas 204a-204n are weighted differently to effectively steer the outgoing signals in a desired direction. The controller/processor <NUM> could also support OFDMA operations in which outgoing signals are assigned to different subsets of subcarriers for different recipients (e.g., different STAs <NUM>-<NUM>). Any of a wide variety of other functions could be supported in the AP <NUM> by the controller/processor <NUM> including sharing TWT information between APs to facilitate negotiations for MAP coordination. In some embodiments, the controller/processor <NUM> includes at least one microprocessor or microcontroller.

The backhaul or network interface <NUM> allows the AP <NUM> to communicate with other devices or systems over a backhaul connection or over a network. For example, the interface <NUM> could allow the AP <NUM> to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet).

As described in more detail below, the AP <NUM> may include circuitry and/or programming for sharing TWT information between APs to facilitate negotiations for MAP coordination. Although <FIG> illustrates one example of AP <NUM>, various changes may be made to <FIG>. For example, the AP <NUM> could include any number of each component shown in <FIG>. As another particular example, while shown as including a single instance of TX processing circuitry <NUM> and a single instance of RX processing circuitry <NUM>, the AP <NUM> could include multiple instances of each (such as one per RF transceiver). Alternatively, only one antenna and RF transceiver path may be included, such as in legacy APs.

<FIG> illustrates an example STA <NUM> according to various embodiments of this disclosure. The embodiment of the STA <NUM> illustrated in <FIG> is for illustration only, and the STAs <NUM>-<NUM> of <FIG> could have the same or similar configuration. However, STAs come in a wide variety of configurations, and <FIG> does not limit the scope of this disclosure to any particular implementation of a STA.

The STA <NUM> includes antenna(s) <NUM>, a radio frequency (RF) transceiver <NUM>, TX processing circuitry <NUM>, a microphone <NUM>, and receive (RX) processing circuitry <NUM>. The STA <NUM> also includes a speaker <NUM>, a controller/processor <NUM>, an input/output (I/O) interface (IF) <NUM>, a touchscreen <NUM>, a display <NUM>, and a memory <NUM>.

The RF transceiver <NUM> receives, from the antenna(s) <NUM>, an incoming RF signal transmitted by an AP of the network <NUM>. The RX processing circuitry <NUM> transmits the processed baseband signal to the speaker <NUM> (such as for voice data) or to the controller/processor <NUM> for further processing (such as for web browsing data).

The TX processing circuitry <NUM> receives analog or digital voice data from the microphone <NUM> or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the controller/processor <NUM>. The RF transceiver <NUM> receives the outgoing processed baseband or IF signal from the TX processing circuitry <NUM> and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna(s) <NUM>.

The controller/processor <NUM> can include one or more processors and execute the basic OS program <NUM> stored in the memory <NUM> in order to control the overall operation of the STA <NUM>. In one such operation, the main controller/processor <NUM> controls the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver <NUM>, the RX processing circuitry <NUM>, and the TX processing circuitry <NUM> in accordance with well-known principles. The main controller/processor <NUM> can also include processing circuitry configured to detect interference from a neighboring BSS and inform the associated AP of the interference. In some embodiments, the controller/processor <NUM> includes at least one microprocessor or microcontroller.

The controller/processor <NUM> is also capable of executing other processes and programs resident in the memory <NUM>, such as operations for detecting interference from a neighboring BSS and inform the associated AP of the interference. In some embodiments, the controller/processor <NUM> is configured to execute a plurality of applications <NUM>, such as applications for detect interference from a neighboring BSS and inform the associated AP of the interference. The controller/processor <NUM> can operate the plurality of applications <NUM> based on the OS program <NUM> or in response to a signal received from an AP. The main controller/ processor <NUM> is also coupled to the I/O interface <NUM>, which provides STA <NUM> with the ability to connect to other devices such as laptop computers and handheld computers. The I/O interface <NUM> is the communication path between these accessories and the main controller <NUM>.

The controller/processor <NUM> is also coupled to the touchscreen <NUM> and the display <NUM>. The operator of the STA <NUM> can use the touchscreen <NUM> to enter data into the STA <NUM>. Part of the memory <NUM> could include a random-access memory (RAM), and another part of the memory <NUM> could include a Flash memory or other read-only memory (ROM).

Although <FIG> illustrates one example of STA <NUM>, various changes may be made to <FIG>. In particular examples, the STA <NUM> may include any number of antenna(s) <NUM> for MIMO communication with an AP <NUM>. In another example, the STA <NUM> may not include voice communication or the controller/ processor <NUM> could be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while <FIG> illustrates the STA <NUM> configured as a mobile telephone or smartphone, STAs could be configured to operate as other types of mobile or stationary devices.

When considering interfering links in at least two neighboring BSSs corresponding to the APs in a coordinating set (i.e., main/target BSS and OBSSs), a MAP coordination mechanism would mitigate the interference between the two links while trying to maintain the performance in each link without degradation. If a victim link uses a power saving mechanism such as TWT, then when the victim link sees large interference from a neighboring OBSS it will be awake only for part of the time while dozing for large periods of time and, similarly, interfering links will often times follow a power saving profile such as TWT. Sharing TWT information with coordinated APs would allow the coordinated APs to mitigate interference to the victim link through MAP coordination. Accordingly, mechanisms for utilizing the victim link's TWT configuration between coordinated APs to facilitate MAP coordination are provided below.

A simple example can be illustrated using <FIG> as a dense deployment scenario wherein BSSs corresponding to AP <NUM> and AP <NUM> overlap with each other, and assuming that for an HE or EHT STA (e.g., STAs <NUM> and <NUM>), an individual TWT agreement (or broadcast TWT schedule) is agreed upon between an AP and its associated STA (or group of STAs). Although the embodiments below are discussed with respect to a TWT agreement, it is understood that they could be performed with a broadcast TWT schedule instead. For the purposes of this disclosure "a TWT operation" may be used to refer to an individual TWT agreement or to a broadcast TWT schedule. In this example, AP <NUM> may obtain a TXOP to serve STA <NUM>. The link between AP <NUM> and STA <NUM> is denoted as Link-<NUM>. At the same time, AP <NUM> may be serving STA <NUM> on a link denoted as Link-<NUM> (the link between AP <NUM> and STA <NUM>). Additionally, AP <NUM> and AP <NUM> operate on the same frequency band. In this simple example, Link-<NUM> may be considered to be in the OBSS to the BSS that contains Link-<NUM>. In the downlink (DL) direction, Link-<NUM> and Link-<NUM> will cause interference to each other, leading to performance degradation.

According to various embodiments of the present disclosure, STA <NUM> may detect high DL interference from the OBSS, making STA <NUM> a victim STA of interference from AP <NUM>, and making Link-<NUM> a victim link (or suffering link) of Link-<NUM>, which is the interfering link. In such cases, STA <NUM> may inform its AP <NUM> that it is detecting high interference from the OBSS. In some embodiments, the STA <NUM> can send AP <NUM> information on the link (Link-<NUM>) or the AP (AP <NUM>) that is causing the interference while informing AP <NUM> of the interference.

When AP <NUM> has obtained a TXOP (and is thus a sharing AP) for transmitting to STA <NUM>, it may announce its MAP coordination capability to neighboring coordinated APs, including AP <NUM>, and indicate to them that it has obtained the TXOP. When AP <NUM> announces its MAP coordination capability, it includes the TWT agreement for Link-<NUM> - the victim link - to facilitate a negotiation procedure with the coordinated APs to avoid interference with the victim link. For example, AP <NUM> can share the TWT Parameter Set field of the victim link's TWT agreement (including Link-<NUM>'s TWT SP) with the coordinated APs. Sharing the TWT Parameter Set field information of the victim link with the coordinated APs allows them to determine the time slots where interference management needs to be handled. In the announcement frame, interfering link information (including the TWT agreement and TX-RX information of the interfering link, e.g., Link-<NUM>) may also be shared. Coordinated APs, such as AP <NUM>, can then act upon the shared TWT agreement information.

Coordinated APs (e.g., AP <NUM>) can respond to the MAP coordination announcement frame from the sharing AP <NUM> as part of the negotiation process. Backhaul communication between the coordinating APs (e.g., AP <NUM> and AP <NUM>) may be used for the negotiation process. When coordinated AP <NUM> receives the MAP coordination announcement frame carrying the TWT agreement of the victim link Link-<NUM>, it may send a response frame to sharing AP <NUM> that notifies AP <NUM> as to whether AP <NUM> is able to participate in MAP coordination during the TXOP.

In one embodiment, when AP <NUM> receives the MAP coordination announcement frame from AP <NUM>, it renegotiates the TWT agreement on Link-<NUM> with STA <NUM> based on the TWT parameters of Link-<NUM> so that the TWT SP for Link-<NUM> is not overlapping with the TWT SP for Link-<NUM>. When AP <NUM> responds to the MAP coordination announcement frame with its capability for joining MAP coordination with AP <NUM>, AP <NUM> may include the renegotiated TWT agreement for Link-<NUM> in the response frame ( e.g., AP <NUM> may share the TWT Parameter Set field of Link-<NUM> with AP <NUM>).

In other embodiments, when AP <NUM> responds with its capability for joining MAP coordination with AP <NUM>, it can suggest adjustment or modification of Link-<NUM>'s TWT agreement so that the TWT SP of Link-<NUM> does not overlap the TWT SP of Link-<NUM>. This can happen in a response frame from AP <NUM> to AP <NUM> informing AP <NUM> of a suggested TWT setup (e.g., suggested TWT parameters) for Link-<NUM> and indicating that AP <NUM> can join AP <NUM> in MAP coordination if the suggested TWT setup is adopted for Link-<NUM>. In other embodiments, the response frame from AP <NUM> to AP <NUM> informing AP <NUM> can inform AP <NUM> that adjustment or modification of Link-<NUM>'s TWT agreement is needed in order for AP <NUM> to participate in MAP coordination with AP <NUM> and can include Link-<NUM>'s TWT agreement (e.g., the TWT Parameter Set field of Link-<NUM>). AP <NUM> may then determine whether to adjust Link-<NUM>'s TWT agreement so that the TWT SP for Link-<NUM> is not overlapping with the TWT SP for Link-<NUM>.

In other embodiments, AP <NUM> may respond by declining to participate in MAP coordination with AP <NUM>.

In all cases in this example, the final decision of the sharing AP on which coordinated APs to include in the shared AP set that are going to participate in MAP operation is announced after receiving the response from all coordinated APs. The information sharing between coordinating APs relies on including enough information of the TWT agreement (whether it is individual TWT or part of a broadcast TWT) of the victim's link so that coordinated APs can respond accordingly.

<FIG> illustrates an example of a negotiation procedure between APs for MAP coordination according to various embodiments of the present disclosure. The example of <FIG> corresponds to the above embodiments, and is illustrated from the viewpoint of the victim STA and its serving AP. The victim STA may be STA <NUM> and its serving AP may be AP <NUM>, while the interfering STA may be STA <NUM> and its associated AP in the OBSS may be AP <NUM>. However, it is understood that the STAs could be any other STA device, and the APs could be any AP device.

In some embodiments, the MAP coordination negotiation between APs can facilitate a TDMA-like coordination. Extending the example discussed above, the coordinated AP <NUM> may respond to a MAP coordination announcement frame from the coordinated AP <NUM> by sending a response frame that includes one of the below MAP coordination responses. <FIG> illustrates an example of a negotiation procedure between APs for TDMA-like MAP coordination according to various such embodiments of the present disclosure.

When coordinated AP <NUM> declines to participate in MAP coordination with sharing AP <NUM>, the response from AP <NUM> to the MAP coordination announcement frame may be a TWT agreement modification rejection message. This may occur if the coordinated AP is not able to accommodate the TWT agreement of the victim link due to some requirement for the interfering link in the OBSS. In this case, the sharing AP will not include coordinated AP <NUM> as a shared AP for MAP operation. As a result, interference will still impact the victim link. To handle this, the victim link can continue to work with a modulation and coding scheme (MCS) that is adequate to the interference level, the coordinating APs may negotiate a different coordination mechanism, or the victim link can move to a different channel (e.g., a different frequency).

If coordinated AP <NUM> is able to accommodate the TWT agreement of the victim link, then the response from AP <NUM> to the MAP coordination announcement frame may be a TWT agreement modification acceptance message. This can happen, for example, if the coordinated AP is able to negotiate a new TWT agreement for the interfering link that will reduce or resolve the interference caused on the victim link. Another option is that the coordinated AP can limit the scheduler from scheduling the interfering link's STA during the victim link's SP duration, thereby avoiding the victim link's SP without modifying any TWT agreements. This can be useful in many cases such as the case where interfering links don't support power saving modes.

When coordinated AP <NUM> suggests an adjustment to Link-<NUM>'s TWT agreement, the response from AP <NUM> to the MAP coordination announcement frame may be a TWT agreement modification suggestion message. This may occur if the coordinated AP is not able to accommodate the TWT agreement of the victim link as is but would be able to work together with the sharing AP if the sharing AP were to update the victim link's TWT agreement to the suggested one. In this case, it is up to the sharing AP whether to update the TWT agreement of the victim link and include the coordinated AP as a shared AP for MAP transmission or not to update the victim link's TWT agreement and exclude the coordinated AP from the shared AP set. The suggestion is made only once, and it is either accommodated or rejected by the sharing AP to avoid back and forth negotiation.

In some cases, either the sharing or shared AP or both may require changing their TWT agreement based on certain changes in the links requirements in either the sharing AP's BSS or the shared AP's BSS (the OBSS). In such a case, the AP that wants to update its TWT agreement announces its intention to the sharing AP and a new round of negotiation may start. In other cases, the sharing AP may announce that MAP coordination is no longer needed or is needed with a new set of requirements. This requires infrequent periodic/aperiodic handshaking between sharing and shared APs.

In other embodiments, a hierarchical network topology is adopted where AP <NUM> and AP <NUM> are both connected to a coordinating AP that receives TWT agreements for both Link-<NUM> and Link-<NUM> and then informs AP <NUM> and AP <NUM> with suggested TWT agreement updates. A coordinating set of APs can be predetermined when the network is deployed based on the network topology.

Furthermore, although the above examples focus on the case in which both links support TWT, they can be extended to other cases in which the interfering link does not support TWT, but the shared AP can avoid scheduling the interfering link in the TWT SP duration of the victim link. Additionally, the case in which more than one interfering link exists can be included. In such a case, non-legacy interfering links can be part of a broadcast TWT schedule having a non-overlapping SP. For other links (including legacy or non-legacy links), more STAs can be included in the scheduling avoidance sessions to protect the victim link.

When one of the BSS's links and one of the OBSS's links interfere, then both links have overlapping TWT SPs. <FIG> illustrates an example of interfering TWT SPs of a BSS link and an OBSS link according to various embodiments of the present disclosure. In the example of <FIG>, the BSS link is Link-<NUM> and the OBSS link is Link-<NUM>, as in the above examples. Link-<NUM> is the link between the coordinating AP of the BSS and the victim STA, and Link-<NUM> is the link between a coordinated AP of the OBSS and the interfering STA.

When the coordinating AP announces its capability for TWT MAP coordination through an announcement frame, it shares the TWT agreement of Link-<NUM> (e.g., the TWT Parameter Set field of Link-<NUM>) with the coordinated APs. A coordinated AP updates the TWT SP of Link-<NUM> by adding fixed offset to the start of the SP so that the SPs for Link-<NUM> and Link-<NUM> are not overlapped.

However, coordinating links generally have different quality of service (QoS) requirements. Hence, TWT coordination for non-overlapping SPs should consider that. In the example of <FIG>, due to different QoS requirement on both links, the SP of each link may be of different length, and although adding a fixed offset may guarantee non-overlapping SPs for the first TWT round, drifting would occur, and the SPs will overlap in later wake-up times. Therefore, a further update to the TWT agreements may be required in addition to adding an SP offset.

<FIG> and <FIG> illustrate examples of further updates to TWT agreements of interfering links to account for different QoS requirements according to various embodiments of the present disclosure. In the example of <FIG>, the longer TWT cycles are accommodated by increasing the sleep duration for Link-<NUM>. In the example of <FIG>, the original TWT agreement of Link-<NUM> is maintained, and the sleep duration of Link-<NUM> is shortened. This may include changing the power saving profile of the STA on Link-<NUM>. Other combinations may also be done depending on the traffic requirements and the QoS requirements of both links.

Another option to account for different QoS requirements is to calculate the duration where SPs will not overlap and perform a one-time calculation of how often wake-up and sleep-time are adjusted accordingly in coming rounds of TWT. For this level of coordination between APs to be possible, enough information should be shared between both APs to facilitate a TWT negotiation process, which should take place to be able to achieve frame-level synchronization between the TWT agreements of the APs.

The above examples are discussed in terms of DL interference and DL MAP coordination; however, a similar approach may be used for uplink (UL) interference. In some such embodiments, when an AP senses high interference coming from a neighboring OBSS's UL transmission, the AP starts announcement of MAP coordination if it is capable of MAP coordination and a similar approach to DL coordination may be followed.

In dense deployment scenarios, if one AP has a restricted TWT schedule, for which the corresponding scheduled STA falls in a geographic area that has overlap with a neighbor BSS (OBSS), then the rTWT scheduled STA would possibly face interference from operations of the neighboring BSS. This interference during the restricted TWT SP corresponding to the rTWT schedule can be managed by MAP coordination through quiet interval management.

According to some embodiments, neighboring APs can share their restricted TWT schedule information with each other and one rTWT scheduling AP can request its neighboring APs to quiet their transmissions for their STAs during the rTWT scheduling AP's restricted TWT service periods. If a neighboring AP in the coordinating set accepts the quieting request, that AP can send a Quiet element to its associated STAs so that the corresponding Quiet interval protects the restricted TWT service period for which the requesting AP sent the quieting request.

<FIG> illustrates an example scenario using MAP coordination between APs to protect a restricted TWT SP through quiet interval management according to various embodiments of the present disclosure. The example scenario of <FIG> may be a modification of the example scenario of <FIG>. For example, AP2 may correspond to sharing AP <NUM>, AP1 may correspond to coordinated AP <NUM>, STA4 may correspond to victim STA <NUM>, and STA3 may correspond to interfering STA <NUM>. The link between STA4 and AP2 may correspond to Link-<NUM>, and the link between STA3 and AP1 may correspond to Link-<NUM> in this case.

AP2 announces one restricted TWT schedule, namely, rTWT schedule A. STA4 is a device that has latency sensitive traffic, and hence STA4, after negotiation with AP2, becomes a member of the rTWT schedule A. However, STA4 is situated towards the BSS boundary and would face interference from AP1 if transmission occurs in BSS1 during the TWT service period corresponding to rTWT schedule A in BSS2. This interference can cause higher contention for STA4 even though STA4 is a member of an rTWT schedule created by AP2. Hence, STA4's latency-sensitive applications can suffer from this interference.

In order to minimize the interference towards restricted TWT scheduled STAs (e.g., STA4), AP2 shares its restricted TWT schedule information with AP1. That is, AP2 shares TWT information corresponding to rTWT schedule A with AP1. Additionally, AP2 sends a quieting request to AP1 to quiet transmissions for AP1's STAs to protect rTWT schedule A. This may be done through backhaul communications between AP1 and AP2.

If AP1 accepts AP2's channel quieting request, it establishes a quiet interval corresponding to the rTWT service period of rTWT schedule A. In order to establish the quiet interval, AP1 sends Quiet element A to its member STAs (including STA4), which corresponds to the wake-up time for rTWT schedule A.

<FIG> illustrates an example process for sending a quieting request in MAP coordination according to various embodiments of the present disclosure. The process begins at step <NUM>, when the Target BSS has one or more restricted TWT schedules. Here, the Target BSS is the BSS for which the corresponding AP (referred to as the Target AP) intends to provide better protection for its rTWT schedules by reducing interference from its neighbor BSSs through MAP coordination. In this example, the Target AP may be AP2 (or AP <NUM>).

In step <NUM>, the Target AP sends quieting requests along with its restricted TWT schedule information to other neighboring APs in its coordinating set.

In step <NUM>, if a neighboring AP in the coordinating set accepts the quieting request from the Target AP for a particular restricted TWT schedule, then it sends out a Quiet element to protect the requested rTWT service period (step <NUM>). Otherwise, no more action is expected from the neighbor AP in regards of protecting the rTWT service period requested by the Target AP (step <NUM>).

According to another embodiment, upon accepting the quieting request from the Target AP, the neighbor AP in the coordinating set may send a variant of Quiet element to the STAs in its BSS. The variant Quiet element can be a Deprioritized variant Quiet element. According to one embodiment, upon receiving a Deprioritized variant Quiet element, the STAs in the neighbor BSS may have the option of whether or not to abide by the Quiet interval (i.e., the option to keep silent/not transmit). In some such embodiments, upon receiving the Deprioritized variant Quiet element, the STAs in the neighbor BSS follow the Quiet interval if some rules or conditions set by their BSS are satisfied.

<FIG> illustrates an example scenario using MAP coordination between APs to protect a restricted TWT SP through quiet interval management using a Deprioritized variant Quiet element according to various embodiments of the present disclosure. The example of <FIG> is a modification of that of <FIG> in which STA3, which is associated with AP1, also has latency sensitive traffic.

Accordingly, AP1 establishes restricted TWT schedule B with STA3 in order to protect the latency sensitive traffic for STA3. Therefore, other STAs (STA1 and STA2) in BSS1 abide by the Quiet interval corresponding to the Quiet element B, which corresponds to the restricted TWT service period B.

AP1 then receives the quieting request from AP2. The quieting request is made to protect STA4's restricted TWT service period A. Since AP1 has its own restricted TWT schedules in its BSS, AP1 decides to send a Deprioritized variant Quiet element A to its STAs. Upon receiving the Deprioritized variant Quiet element A, response to the Deprioritized variant Quiet element reception can be different for different STAs in BSS1. Some example rules for Deprioritized variant Quiet element adherence can be the following (other rules can also be set by the AP):.

If a STA in a BSS already has its own restricted TWT schedule to protect its latency sensitive traffic, then if the STA receives a Deprioritized variant Quiet element, it can ignore the Deprioritized variant Quiet element. In <FIG>, STA3 has its own restricted TWT schedule (rTWT schedule B). Therefore, STA3 can ignore the Deprioritized variant Quiet element A corresponding to rTWT schedule A.

STAs in a BSS which are not members of a restricted TWT schedule follow the quiet interval corresponding to a Deprioritized variant Quiet element if the number of Quiet intervals corresponding to the Quiet element that the STAs need to follow (due to the presence of existing restricted TWT schedule in their own BSS) is less than a threshold. For such a STA, there can be a second threshold value for the number of Quiet intervals that the STA follows corresponding to Deprioritized variant Quiet elements that the STA receives corresponding to the quieting requests from one or more neighboring APs. In <FIG>, STA1 and STA2 follow two Quiet intervals - the first one corresponds to the Quiet element B for protection of STA3's rTWT schedule B, and the second one corresponds to Deprioritized variant Quiet element A for protection of STA4's rTWT schedule A.

<FIG> illustrates an example of usage of a Quiet element by a neighbor AP in the coordinating set according to various embodiments of the present disclosure. In <FIG>, STA1 is associated with AP1 and STA2 is associated with AP2. AP1 and AP2 form a multi-AP coordinating set.

STA1 receives a Beacon frame from AP1 that contains a Restricted TWT Parameter Set corresponding to restricted TWT SP A. Through the negotiation with AP1, STA1 becomes a member of the restricted TWT schedule corresponding to the Restricted TWT Parameter Set A. For better protection for the restricted TWT SP A, AP1 sends a quieting request to AP2, and AP2 accepts the request. Accordingly, STA2 receives a Quiet element from AP2. The Quiet interval corresponding to the Quiet element sent by AP2 overlaps with the beginning portion of the restricted TWT SP A. According to one embodiment, the duration of this Quiet interval is <NUM> TU. According to another embodiment, duration of the Quiet interval can be more than <NUM> TU and less than or equal to the duration of the restricted TWT SP A.

<FIG> illustrates an example of usage of a Deprioritized variant Quiet element according to various embodiments of the present disclosure. In <FIG>, STA1 is associated with AP1 and STA2 is associated with AP2. AP1 and AP2 form a multi-AP coordinating set.

STA1 becomes a member of a restricted TWT schedule, Restricted TWT schedule A, announced by AP1. Moreover, STA2 becomes a member of a restricted TWT schedule, Restricted TWT schedule B, announced by AP2. AP1 sends a quieting request to AP2 to better protect its rTWT schedule corresponding to Restricted TWT SP A. Similarly, AP2 sends a quieting request to AP1 to better protect its rTWT schedule corresponding to Restricted TWT SP B. Both APs accept each other's quieting requests.

However, since each AP has its own restricted TWT schedule for protecting the latency sensitive traffic in its respective BSS, each AP decides to send a Deprioritized variant Quiet element (instead of a Quiet element) to the STAs in its respective BSS. Accordingly, the quiet interval corresponding to the Deprioritized variant Quiet element sent by AP2 to STA2 overlaps with the starting portion of restricted TWT SP A to protect latency sensitive traffic of STA1. Also, the quiet interval corresponding to the Deprioritized variant Quiet element sent by AP1 to STA1 overlaps with the starting portion of restricted TWT SP B to protect latency sensitive traffic of STA2.

According to some embodiments, APs in a coordinating set can directly share each other's restricted TWT schedule information. According to some other embodiments, an AP can act as a coordinating AP for the coordinating set. The coordinating AP has restricted TWT information of all APs in the coordinating set and distributes the rTWT schedule information to the different APs. <FIG> illustrates an example of a scenario in which a coordinating AP distributes rTWT schedule information to the coordinating set according to various embodiments of the present disclosure. In <FIG>, AP2 receives rTWT information of AP1 and AP1 receives rTWT information of AP2.

According to some embodiments, APs in the coordinating set can share restricted TWT information over the backhaul. According to some other embodiments, an AP can send individually addressed management frames to other APs that contain the restricted TWT information. In order to indicate the quieting request, an AP can send a broadcast TWT element to the neighboring AP in the coordination set. The broadcast TWT element may contain one or more Restricted TWT Parameter Sets. The Target AP (the AP which request for quieting from other APs) can indicate which restricted TWT schedule corresponding to the Restricted TWT Parameter Set the quieting request applies to.

<FIG> illustrates an example format of a Control field of a TWT element that includes a MAP Quieting Request subfield. In some embodiments, the MAP Quieting Request subfield in the Control field of the TWT element can be used to indicate a quieting request. If the bit corresponding to the MAP Quieting Request subfield is set to <NUM>, it indicates that the TWT element includes a quieting request to the respective AP in the multi-AP coordinating set and the quieting request applies to all rTWT schedules contained in the TWT element. If the bit corresponding to MAP Quieting Request subfield is set to <NUM>, it indicates that the quieting request, if indicated through other signaling, may not apply to all rTWT schedules carried in the TWT element. The MAP Quieting Request can also be indicated by bit <NUM> (B7).

<FIG> illustrates an example format of a Request Type field of a Restricted TWT Parameter Set field that includes a Multi-AP Quieting Request subfield. In some embodiments, the Multi-AP Quieting Request subfield in the Request Type field in the Broadcast TWT Parameter Set field may indicate whether or not a quieting request applies to a particular rTWT schedule. If the Multi-AP Quieting Request subfield is set to <NUM>, it indicates that a quieting request is placed to the recipient (AP in the coordinating set) of the TWT element and the quieting request applies to the restricted TWT schedule corresponding to the Restricted TWT Parameter Set. If the Multi-AP Quieting Request subfield is set to <NUM>, it indicates that no quieting request has been made that applies to the restricted TWT schedule corresponding to the Restricted TWT Parameter Set.

<FIG> illustrates an example format of a Broadcast TWT info subfield of a Restricted TWT Parameter Set field that includes a Quieting Request subfield. In some embodiments, whether a quieting request applies to a particular rTWT schedule can be indicated by a Quieting Request subfield of the Broadcast TWT Info subfield in a Restricted TWT Parameter Set field. If the Quieting Request subfield is set to <NUM>, it indicates that a quieting request is placed to the recipient (AP in the coordinating set) of the TWT element and the quieting request applies to the restricted TWT schedule corresponding to the Restricted TWT Parameter Set. If the Quieting Request subfield is set to <NUM>, it indicates that no quieting request has been made that applies to the restricted TWT schedule corresponding to the Restricted TWT Parameter Set. The Quieting Request subfield can also be indicated by bit <NUM> (B0) or bit <NUM> (B2) of the Broadcast TWT Info subfield.

According to yet another embodiment, whether or not a quieting request applies to a particular rTWT schedule can be indicated by the Broadcast TWT Recommendation field value in the Request Type field in a Broadcast TWT Parameter Set field corresponding to the restricted TWT schedule. Table <NUM> illustrates values of the Broadcast TWT Recommendation field according to such an embodiment. According to some embodiments, if the Broadcast TWT Recommendation field value is set to <NUM>, it indicates that the corresponding broadcast TWT schedule is a restricted TWT schedule, and a quieting request has made for the corresponding restricted TWT schedule. According to some other embodiments, this indication can also be made by other values (value <NUM> and value <NUM>) in the Broadcast TWT Recommendation field in Request Type field in Broadcast TWT Parameter Set corresponding to the restricted TWT schedule.

<FIG> illustrates an example format of a Broadcast TWT info subfield of a Restricted TWT Parameter Set field that includes Quieting Request subfields with priority levels. According to some embodiments, when the Target AP sends a quieting request to the neighboring AP in the coordination set, it can indicate whether the quieting request is with high priority or with low priority. A high priority quieting request means that it is critical for the Target AP to protect the rTWT SP corresponding to the rTWT schedule for which the quieting request has been made.

Based on the priority level of the quieting request, the neighbor AP in the coordinating set which receives the TWT element may take different actions in response to the quieting request. According to some embodiments, the Quieting Request with Low Priority subfield set to <NUM> indicates that a quieting request has been made for the corresponding rTWT schedule and the request is with low priority. The Quieting Request with High Priority subfield set to <NUM> indicates that a quieting request has been made for the corresponding rTWT schedule and the request is with high priority. Both of the Quieting Request with Low Priority and Quieting Request with High Priority subfields cannot be set to <NUM> in the same Broadcast TWT Info subfield. Both of the Quieting Request with Low Priority and Quieting Request with High Priority subfields set to <NUM> indicates that no quieting request has been made for the corresponding rTWT schedule.

According to some other embodiments, the priority level of the quieting request can be indicated by the Broadcast TWT Recommendation field value in the Request Type field in a Broadcast TWT Parameter Set field corresponding to the restricted TWT schedule. Table <NUM> illustrates values of the Broadcast TWT Recommendation field according to such embodiments. Value <NUM> indicates low priority and value <NUM> indicates high priority in Table <NUM>.

<FIG> illustrates an example format of a Deprioritized variant Quiet element according to various embodiments of the present disclosure. The Priority Level field in Deprioritized variant Quiet element indicates the priority levels for the Deprioritized variant Quiet element.

<FIG> illustrates an example process for sharing TWT parameters between coordinating APs to perform MAP coordination according to various embodiments of the present disclosure. The process of <FIG> is discussed as being performed by a sharing AP (a first AP) in a MAP coordinating set of APs, but it is understood that a coordinated AP (a second AP) in the MAP coordinating set could perform a corresponding process. Additionally, for convenience, the process of <FIG> is discussed as being performed by a WI-FI AP, but it is understood that any suitable wireless communication device could perform the process.

Beginning at step <NUM>, the first AP receives, from a first STA with which the first AP exchanges traffic in a first TWT SP based on parameters of a first TWT operation between the first AP and the first STA, an interference notification message that includes an indication that the first STA has detected interference with a traffic transmission from the first AP. The interference is caused by transmissions between a second STA and a second AP in the MAP coordinating set of APs. As used herein, the term TWT operation may be either an individual TWT agreement or a broadcast TWT schedule.

The first AP next transmits, to the second AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained a TXOP and (ii) the parameters of the first TWT operation (step <NUM>). This may be done using a backhaul interface between the first and second APs.

The first AP then receives, from the second AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination (step <NUM>).

The first AP next determines, based on the MAP coordination response, whether to perform MAP coordination with the second AP during the TXOP, or whether to modify the parameters of the first TWT operation based on the interference notification message (step <NUM>). The MAP coordination response may have various forms, and the first AP's determination will vary accordingly.

In one embodiment, if the MAP coordination response includes an indication that the second AP declines to participate in MAP coordination, then the first AP may determine not to perform MAP coordination with the second AP at step <NUM>.

In another embodiment, the MAP coordination response includes an indication that the second AP is capable of participating in MAP coordination and parameters of a second TWT operation between the second STA and the second AP. In this case, the parameters of the second TWT operation have been modified based on the parameters of the first TWT operation based on the extent of overlap between a second SP of the second TWT operation and the first SP of the first TWT operation. Information on the first SP is included in the parameters of the first TWT operation and information on the second SP is included in the parameters of the second TWT operation. Based on this MAP coordination response the first AP may determine to perform MAP coordination with the second AP, and may determine, based on the parameters of the second TWT operation, whether to modify the parameters of the first TWT operation based on the overlap between the second SP and the first SP.

In another embodiment, the MAP coordination response includes a first indication that the second AP is capable of participating in MAP coordination, parameters of a second TWT operation between the second STA and the second AP, and a second indication that the parameters of the first TWT operation need to be modified based on overlap between the first SP of the first TWT operation and a second SP of the second TWT operation. Information on the first SP is included in the parameters of the first TWT operation and information on the second SP is included in the parameters of the second TWT operation. Based on the first indication in this MAP coordination response the first AP may determine whether to perform MAP coordination with the second AP, and based on the second indication the first AP may determine whether to modify the parameters of the first TWT operation based on the parameters of the second TWT operation and based on the overlap between the first SP and the second SP.

In another embodiment, the MAP coordination response includes a TWT agreement modification rejection message that indicates that the second AP is not able to modify parameters of a second TWT operation based on overlap of a second SP of the second TWT operation with the first SP of the first TWT operation. Based on the TWT agreement modification rejection message, the first AP may determine not to perform MAP coordination with the second AP.

In another embodiment, the MAP coordination response includes a TWT agreement modification acceptance message that indicates that the second AP is able to modify the parameters of the second TWT operation based on the parameters of the first TWT operation and based on the overlap of the second SP with the first SP. Based on the TWT agreement modification acceptance message, the first AP may determine to perform MAP coordination with the second AP.

In another embodiment, the MAP coordination response includes a TWT agreement modification suggestion message that includes a suggested modification to the parameters of the first TWT operation based on the overlap of the second SP with the first SP. Based on the TWT agreement modification suggestion message, the first AP may determine whether (i) to modify the parameters of the first TWT agreement based on the suggested modification and perform MAP coordination with the second AP or (ii) not to modify the parameters of the first TWT agreement and not to perform MAP coordination with the second AP.

In cases in which the first TWT operation corresponds to a restricted TWT schedule based on which the first STA and first AP exchange latency-sensitive traffic during restricted TWT operation in a restricted TWT SP, the first AP may also transmit, to the second AP, parameters corresponding to the restricted TWT schedule and a request for the second AP to establish a quiet interval in the second AP's BSS for the second STA during restricted TWT SPs corresponding to the restricted TWT schedule. The first AP may then receive, from the second AP, a response indicating whether or not the second AP will establish the quiet interval during the restricted SPs, during which transmissions will not be allowed for the second STA.

The above flowchart illustrates example methods that can be implemented in accordance with the principles of the present disclosure and various changes could be made to the methods illustrated in the flowchart. For example, while shown as a series of steps, various steps could overlap, occur in parallel, occur in a different order, or occur multiple times. In another example, steps may be omitted or replaced by other steps.

Claim 1:
A first wireless access point, AP, device (<NUM>) for a multi-AP, MAP, coordinating set of APs, the first AP comprising:
a transceiver (<NUM>~209n),
wherein the transceiver (209a~209n) is configured to:
transmit traffic to a first station, STA, during a transmission opportunity, TXOP, in a first target wake time, TWT, service period, SP, based on parameters of a first TWT operation between the first AP and the first STA,
receive (<NUM>), from the first STA, an interference notification message that includes an indication that the first STA has detected interference with the traffic transmission caused by transmissions between a second STA and a second AP in the MAP coordinating set of APs;
a backhaul interface (<NUM>)
wherein the backhaul interface (<NUM>) is configured to:
transmit (<NUM>), to the second AP, a MAP coordination announcement that includes (i) an indication that the first AP has obtained the TXOP and (ii) the parameters of the first TWT operation, and
receive (<NUM>), from the second AP, a MAP coordination response that indicates capabilities of the second AP pertaining to its participation in the MAP coordination; and
a processor (<NUM>) operably coupled to the transceiver and the backhaul interface, the processor configured to determine (<NUM>), based on the MAP coordination response:
whether to perform MAP coordination with the second AP during the TXOP, or
whether to modify the parameters of the first TWT operation based on the interference notification message.