Communication device and communication method supporting coordinated service period

Abstract

To provide a communication device and a communication method that support a coordinated service period (SP).SOLUTION: A second access point includes a receiver that receives from a first access point a first frame initiating negotiation of a first service period (SP), and a transmitter that transmits to the first access point a second frame responding to the first frame. The transmitter transmits a third frame notifying information about the first SP, to one or more stations associated with the second access point.SELECTED DRAWING: Figure 9

Description

[Technical Field]

[0001] The present embodiments relate generally to communication devices, and more particularly to methods and devices for supporting coordinated service periods (SP). [Background technology]

[0002] In the standardization of next-generation wireless local area networks (LANs), a new wireless access technology that is backward compatible with IEEE 802.11a / b / g / n / ac / ax technologies is being studied in the IEEE 802.11be task group.

[0003] The 11ax High Efficiency (HE) WLAN supports multiple frame transmissions in a transmission opportunity (TXOP), allowing stations (STAs) to transmit additional frames in their transmission queue. The 11be Extremely High Throughput (EHT) WLAN aims to improve throughput beyond that of the 11ax HE WLAN, especially for cell-edge STAs. It has been proposed to enable cooperative transmissions such as coordinated orthogonal frequency-division multiple access (C-OFDMA), coordinated time-division multiple access (C-TDMA), coordinated beamforming (C-BF), coordinated spatial reuse (C-SR), and coordinated multi-user multiple input multiple output (C-MU-MIMO) in multi-AP systems.

[0004] IEEE 802.11be considers various multi-AP cooperation methods: In time-domain cooperative scheduling, access points (APs) adjust their transmission timing; in cooperative spatial reuse (SR), APs adjust their transmit power; in C-OFDMA, APs adjust resource unit (RU) allocation; in cooperative beamforming (BF), APs adjust BF; and in cooperative multi-user multiple-input multiple-output (MU-MIMO), also known as joint transmission, APs adjust their MU-MIMO transmissions. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Singapore Patent Application No. 10202012139Q Summary of the Invention [Problem to be solved by the invention]

[0006] However, the cooperative service period (SP) has not been discussed so far.

[0007] Therefore, there is a need for a communication apparatus and method that can solve the problems set forth above. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and appended claims, considered in conjunction with the accompanying drawings and the Background section of this disclosure. [Means for solving the problem]

[0008] The non-limiting exemplary embodiments facilitate providing a communications apparatus and method that supports cooperative SPs.

[0009] According to one aspect of the present disclosure, there is provided a first access point (AP) comprising: a circuit that, when operated, generates a request frame indicating a request to set up one or more cooperative service periods (SPs); and a transmitter that, when operated, transmits the request frame to a second AP.

[0010] According to another aspect of the present disclosure, there is provided a non-access point (AP) STA comprising: a receiver that, in operation, receives one of a Beacon frame or an Action frame from an AP associated with the non-AP STA; a circuit that, in operation, extracts information of an SP for cooperative transmission from the frame; and a transmitter that, in operation, transmits a request frame to the AP, the request frame indicating a request to join the SP.

[0011] According to another aspect of the present disclosure, a method is provided that includes generating a request frame indicating a request to set up one or more cooperative SPs, and transmitting the request frame to an AP.

[0012] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually through the various embodiments and features of the specification and drawings, and it is not necessary for all of these features to be present in order to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0013] The accompanying drawings, which together with the following detailed description are incorporated in and form a part of this specification, illustrate various embodiments and serve to explain various principles and advantages according to the present embodiments. Throughout the different drawings, like reference numerals indicate identical or functionally similar elements. [Figure 1]1 shows a flow diagram illustrating communications using extended service periods for priority traffic, according to an example. [Figure 2] 1 illustrates an example of a cooperative service period for multi-AP cooperative transmission. [Figure 3] 1 illustrates overlapping wireless networks, according to an example, where each wireless network can include at least one access point (AP) and at least one communication device. [Figure 4] 1 illustrates overlapping wireless networks, according to an example, where each wireless network can include at least one access point (AP) and at least one communication device. [Figure 5] 1 illustrates an example EHT Action frame. [Figure 6] 1 illustrates an example AP collaborative session Action frame. [Figure 7] 1 illustrates a sequence of cooperative transmission according to an example. [Figure 8] 10 illustrates a sequence of cooperative transmission according to another example. [Figure 9] An example of cooperative SP transmission is shown. [Figure 10] 1 shows an example of a TWT Setup frame for a TWT request / response used to set up a cooperative SP. [Figure 11] 1 shows another example of cooperative SP transmission. [Figure 12] 1 shows an example of an Ethertype 89-0d data frame used for multi-AP buffer status reporting. [Figure 13] An example of an EHT capability element is shown. [Figure 14] 1 illustrates another example of an 802.11 data frame used to set up a cooperative SP. [Figure 15] 1 shows another example of cooperative SP transmission. [Figure 16] 10 shows an example of a collaborative SP request Action frame. [Figure 17] 10 shows an example table of collaborative SP type values. [Figure 18] 10 shows an example of a collaborative SP response Action frame. [Figure 19] 10 shows an example of a TWT Setup frame used to set up a multi-AP cooperative TWT SP. [Figure 20] 1 illustrates an example of TWT elements used to set up a multi-AP cooperative TWT SP for C-TDMA. [Figure 21] 1 shows an exemplary diagram of cooperative SP for C-TDMA. [Figure 22] 1 shows an exemplary diagram of cooperative SP for C-TDMA+C-OFDMA. [Figure 23] 1 shows an example of cooperative SP transmission using extended TWT SP. [Figure 24] 10 shows another example of cooperative SP transmission using extended TWT SP. [Figure 25] 1 illustrates an example of a data frame having an "Ethertype 89-0d" frame body for requesting or sharing information about the AP's service period(s) with other APs. [Figure 26] 10 shows another example table of collaborative SP type values. [Figure 27] 10 shows an example of a TWT SP Information Request / Response Action frame for requesting or sharing information about the AP's service period(s) with other APs. [Figure 28] 1 shows an example of a C-TDMA transmission using broadcast enhanced TWT SP. [Figure 29] 1 illustrates a TWT Setup frame that may be utilized via an individual TWT setup to join an existing TWT SP of another AP. [Figure 30] 1 illustrates a TWT Setup frame that may be utilized to enable an AP to join the scheduled broadcast SP of other interested APs. [Figure 31] 1 shows an exemplary diagram illustrating the use of Sub-SPs to protect sensitive traffic. [Figure 32] 1 illustrates a configuration of a communication device, for example, a communication apparatus, for example, a sharing AP or a shared AP, according to various embodiments. [Figure 33] 1 illustrates a configuration of a communication device, eg, a communication apparatus, eg, a non-AP STA, according to various embodiments. [Figure 34] 1 shows a flow diagram illustrating a method for collaborative SP according to various embodiments. [Figure 35] 1 illustrates a partially boxed schematic diagram of an AP or STA that may be implemented to support cooperative SP, according to various embodiments.

[0014] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. DETAILED DESCRIPTION OF THE INVENTION

[0015] The following detailed description is merely exemplary and is not intended to limit the embodiments or the application and uses of the embodiments. Moreover, there is no intention to be bound by the theories presented in the preceding Background or Detailed Description sections. Moreover, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, taken in conjunction with the accompanying drawings and the background of this disclosure.

[0016] 802.11be allows shared transmission opportunity (TXOP)-based multi-AP cooperation, where APs transmit cooperatively within a shared TXOP. Examples include shared TXOP-based C-OFDMA / C-time domain multiple access (C-TDMA) and shared TXOP-based C-SR.

[0017] Patent document 1 describes a mechanism to protect priority traffic (e.g., low latency traffic or National Security and Emergency Preparedness (NSEP) traffic) within an extended target wake time (TWT) by restricting channel access (from unspecified traffic) within a basic service set (BSS).

[0018] For example, Figure 1 shows a flow diagram 100 illustrating communications using an extended service period for prioritized traffic, according to one example. A contention-based channel access procedure, e.g., an enhanced distributed channel access (EDCA) procedure, is shown by blocks 108, 110, 114, 118, 122, 124, 132, and 134. For simplicity, acknowledgement frames (e.g., ACK frames, BlockAck frames) are not explicitly shown, but it will be understood that they are present if needed. The AP 102 can transmit a Beacon frame 109 to advertise the presence of extended TWT SPs 121, 129, in which only low-latency traffic is allowed. A STA needing access to the channel during the extended TWT SPs 121, 129, such as STA1 104, can then negotiate membership in the extended TWT SPs 121, 129 with the AP 102 through an exchange of TWT request / response frames. In particular, during the TWT negotiation phase 112, STA1 104 sends a TWT request frame to the AP 102 requesting membership in the extended TWT SPs 121, 129, and the AP 102 then sends a TWT response frame to STA1 104 granting membership. During the TWT negotiation phase 112, STA1 104 can request, propose, or solicit a set of TWT parameters for the extended TWT SPs 121, 129, and the AP 102 can accept, reject, or propose an alternate configuration. A first target beacon transmission time (TBTT) 116 may also be negotiated during the negotiation phase 112. STA1 is therefore now allowed to access the channel to exchange low latency traffic during the extended TWT SP 121, 129.The Broadcast TWT ID field of the TWT element included in the TWT request frame or TWT response frame is set to a value other than 0 (for example, 1) to indicate a broadcast TWT.

[0019] STA1 can transition to a doze state and after a first TBTT 116, can wake up to receive a Beacon frame 119 from the AP 102. The Beacon frame 119 can include a Broadcast TWT element that contains further TWT information such as a Broadcast TWT (e.g., Broadcast TWT1 120), a TWT wake interval 130, and a minimum TWT wake-up duration (shown as dashed boxes in Extended TWT SPs 121, 129). The TWT element further indicates that it is an Extended TWT and that only low latency traffic is allowed to transmit during this TWT SP.

[0020] STA1 can go to sleep after receiving the Beacon frame 119 and can wake up for a broadcast TWT1 SP 121. Because STA1 is a member of the TWT SP and has low latency (LL) traffic to send, the STA waking up for the extended TWT SP does not set its network allocation vector (NAV). During this first extended TWT SP 121, the AP 102 and STA1 104 exchange low latency traffic, such as a low latency downlink (LLDL) signal 123 and a low latency uplink (LLUL) signal 125, respectively.

[0021] STA1 104 may transition to a sleep state after the end of the first extended TWT SP 121. According to the TWT wake interval 130 specified either in the negotiation phase or in the Beacon frame 119, STA1 104 may wake up for the next broadcast TWT1 SP 129. During this second extended TWT SP 129, the AP 102 and STA1 104 transmit an LLDL PPDU 133 and an LLUL PPDU 135, respectively.

[0022] Meanwhile, third-party STAs, such as STA2 106, that have not negotiated membership with the AP 102 and are therefore not members of the extended TWT SP, are not permitted to access the channel during the extended TWT SPs 121, 129, as indicated by dashed boxes 126, 136. This can be achieved by STA2 waking up for the extended TWT SPs 121, 129, checking whether it is a member of the extended TWT SP and, if not, setting its NAV for the duration of the TWT SP. Because transmission of traffic types with traffic IDs (TIDs) other than those permitted by the TWT SP is restricted during the TWT SP, the extended TWT SP is sometimes referred to as a restricted TWT SP. To further restrict legacy STAs from transmitting during the extended TWT SP, the AP can also transmit a quiet element / quiet channel element to schedule a quiet interval that overlaps with the extended TWT SP. For non-AP legacy STAs, control of the channel is lost at the start of the quiet interval, and all non-AP legacy STAs in the BSS set their NAVs for the length of the quiet interval established by the Quiet Element / Quiet Channel Element, which restricts them from transmitting during the extended SP.

[0023] However, it does not consider protection from overlapping BSS (OBSS) traffic, where neighboring BSSs operate on the same channel.

[0024] Multi-AP cooperative transmission schemes, especially shared TXOP-based schemes, require that target STAs from different BSSs be in active mode or awake state at the same time. This may not always be possible, especially when the STAs operate in power save mode. Therefore, the problem is how to ensure that STAs from different BSSs participating in cooperative transmission are in active mode or awake state at the same time. Furthermore, another problem to be solved is how to protect priority traffic (e.g., low-latency traffic or NSEP traffic) in the extended TWT by restricting channel access from the OBSS (from non-designated traffic).

[0025] Referring to FIG. 2, APs may negotiate a period (cooperative service period) during which they agree to perform multi-AP cooperative transmission. For example, negotiation of a cooperative SP between AP1 and AP2 occurs in SP negotiation 202. Such cooperative SPs for multi-AP cooperative transmission may include periodically recurring SPs such as cooperative SP 206 and cooperative SP 208, and the sharing AP (the AP that wins the shared TXOP) determines the actual multi-AP cooperation scheme to be used in each cooperative SP. Each AP determines target STA(s) for transmitting during the cooperative SP from its associated STAs based on the actual multi-AP cooperation scheme used in each cooperative SP.

[0026] At 204, the STAs negotiate a scheduled SP (BSS-specific) with their associated AP, or in some cases, the STAs may have already negotiated a scheduled SP with their associated AP prior to SP negotiation 202. For example, STA1-1 and STA1-2 negotiate with AP1, and STA2-1 and STA2-2 negotiate with AP2. The AP assigns the STAs to scheduled SPs 210 and 212 such that the STAs' scheduled SPs overlap with the cooperative SPs and ensures that the STAs remain awake during each cooperative transmission. The APs may further exchange next TBTT and beacon interval information 214 to ensure that the cooperative SPs do not overlap with the AP's TBTT.

[0027] As used herein, a scheduled SP refers to an SP that exists between a STA and its associated AP, and may be any SP with which the STA and its associated AP have pre-negotiated one or more periods for exchanging frames. The STA is expected to be awake or in active mode during an SP, such as a Scheduled Automatic Power Save Delivery (S-APSD) SP, a Scheduled Power Save Multi-poll (PSMP) SP, a Target Wake Time (TWT) SP, or a Quiet Time Period (QTP) SP. Negotiation of a cooperative service period can occur between two APs at a time, but if a static sharing AP / shared AP hierarchy exists, many shared APs may negotiate cooperative SPs with the same sharing AP, and multiple shared APs may be assigned (by the sharing AP) to the same cooperative SP. Otherwise, each cooperative SP may be between only two APs. A sharing AP refers to an AP that shares its transmission opportunity (TXOP) with another AP (shared AP).

[0028] The AP can negotiate the following parameters for cooperative SPs: - Start time of first SP: The time when the first collaborative SP occurs. - SP Duration: Duration of each cooperative SP - SP interval: the time interval between two consecutive coordinated SPs - Number of cooperative SPs: If greater than 1, this parameter indicates the total number of periodically repeated cooperative SPs. For example, this parameter may not be present if the cooperative SPs are persistent and occur periodically throughout the lifetime of the multi-AP cooperation, or unless the cooperative SP is explicitly terminated.

[0029] - The characteristics of the traffic expected to be exchanged during the SP (data rate, burst size, delay bounds, etc.) can optionally be included in the Setup frame.

[0030] APs may request that a specific subportion of the SP be assigned to them, or alternatively, they may exchange information about each other's timing synchronization function (TSF), next TBTT, and beacon interval (BI) so that cooperative SPs do not overlap with the beacon transmission times of either AP. Once cooperative SPs are negotiated between APs, within each BSS, selected STAs (i.e., vulnerable STAs expected to participate in cooperative transmissions) are assigned to scheduled SPs (e.g., S-APSD SP, TWT SP, etc.) that overlap with the cooperative SP. STAs do not need to be aware of the cooperative SP. Advantageously, by knowing not only the cooperative SP but also the identities of the STAs participating in cooperative transmissions, the AP can better manage the schedules of those STAs.

[0031] Not all STAs benefit equally from cooperative transmission. Some STAs benefit more than others, and these STAs can be called vulnerable STAs. Which STAs benefit most also depends on the multi-AP cooperative scheme. The STAs that can benefit most from cooperative OFDMA should be identified before cooperative transmission: in the case of C-OFDMA / C-TDMA, those STAs within the transmission range of multiple APs; in the case of C-SR / C-BF, those STAs that are farther away from each other. For example, referring to Figure 3, STA2-1 and STA2-2 are associated with AP2 (BSS2), and STA1-1 and STA1-2 are associated with AP1 (BSS1). STA1-2 and STA2-2 can benefit most from C-SR / C-BF because they are far away from each other and will not cause high interference when transmitting to both simultaneously. On the other hand, STA1-1 and STA2-1 benefit the most from C-OFDMA / TDMA because the two STAs are very close to each other and therefore transmissions to these two STAs must not overlap in the frequency domain and / or time domain to avoid mutual interference.

[0032] An AP can collect reports (e.g., interference measurement reports) from associated STAs to identify vulnerable STAs. Typically, STAs operate in a power-save mode to conserve power, and each STA determines its own awake period (duty cycle). It is desirable to be able to synchronize the awake states of such STAs across OBSSs.

[0033] Not all cell-edge STAs are equally affected by OBSS interference. Even cell-center STAs, in rare cases, may experience significant interference from the OBSS. An AP can attempt to protect vulnerable STAs in its BSS from OBSS interference by reserving frequency units (RUs) for such STAs and informing the OBSS AP of those RUs. If all OBSS APs coordinate their transmissions to avoid simultaneously transmitting on the reserved RUs of neighboring APs, interference to vulnerable STAs can be largely avoided. The AP reserves RUs only for STAs that require protection from the OBSS, such as vulnerable STAs. A subset of RUs can be referred to as the "reserved RU set" or "protected RU set." The AP can use reports from its associated STAs to identify affected STAs and further determine the RUs in the "reserved RU set." For example, referring to Figure 4, AP2 can use bandwidth query reports (BQRs) or interference reports from STAs to identify STA3 as a "vulnerable STA" and further select a reserved RU set for STA3. For the remaining STAs, such as STA1 in Figure 4, there may be no restrictions on the selection of RUs. Interference reports from the STAs can also identify interfering OBSS STAs, i.e., STA2 can be identified as an interfering STA by STA3. STA2 and STA3 can therefore be identified as vulnerable STAs. The AP advertises the reserved RU set to other APs (by broadcasting in a beacon or through an AP-to-AP link). Optionally, the AP can also report interfering OBSS STAs.

[0034] When selecting its own reserved RU set, the coordinating AP also considers the reserved RU sets of neighboring BSSs. The reserved RU set is selected to minimize overlap with the reserved RU sets of neighboring BSSs. RUs for STAs reported as interfering STAs are also restricted to the reserved RU set.

[0035] EHT Action frames can be defined for the purposes of requesting interference measurements (by the AP) and reporting interference measurements (by the STA). Referring to FIG. 5, an EHT Interference Measurement Request frame 502 can be utilized by an AP to request interference measurements, and an EHT Interference Measurement Report frame 504 can be utilized by a STA to report interference measurements. The Interfering STA MAC Address subfield 506 can indicate the STA MAC address retrieved from the TA (Transmitter Address) field of the interfering frame if the interference is from the UL from a non-AP STA, or the STA MAC address retrieved from the RA (Receiver Address) field of the interfering frame if the interference is from the DL to a non-AP STA. The Interfering BSSID subfield 508 can indicate the BSSID retrieved from the BSSID field (usually Address field 3) of the interfering frame.

[0036] Instead of broadcasting, an AP can send the consolidated cell-edge RU set or reserved RU set to another AP over an inter-AP link directly as an Action frame or encapsulated in a data frame (e.g., as an Ethertype 89-0d frame). A new AP Coordination Session Action frame 600 can be defined as shown in FIG. 6, carrying a Reserved RU set element field 602 (same format as the Cell-edge RU Set element, except that the cell-edge RU set field is renamed as the Reserved RU set field). The Category field 604 can have a value of 6 in the AP Coordination Session Action field, indicating that the AP Coordination Session Action frame 600 is for AP cooperative reserved RUs. Additionally, the List of Interfering STAs field 606 may list interfering STAs that belong to the BSS, MAC address, or association identifier (AID) of the target AP. The information in the reserved RU is considered valid until the next "AP Coordination Reserved RU" frame is transmitted. An AP can transmit a reserved RU set to other APs spontaneously, or the transmission may be in response to a request from another AP.

[0037] In the example cooperative transmission sequence shown in Figure 7, BSS1 and BSS2 can have different operating channels (same bandwidth but different starting frequencies and primary channels), but the operating channels overlap on CH3 and CH4. The reserved RU set for BSS2 is assigned to CH5 and CH6, and the reserved RU set for BSS1 is assigned to CH1 and CH2. BSS2 is transmitting an uplink MU PPDU, and the RUs used for DL ​​transmission to vulnerable STAs are on CH5 and CH6. The AP for BSS1 can solicit uplink transmissions by transmitting a TF frame that assigns RUs on CH1 and CH2 to vulnerable STAs. The vulnerable STAs in BSS1 can then transmit their UL PPDUs on the assigned RUs on CH1 and CH2. The non-overlapping reserved RU sets for vulnerable STAs help minimize inter-BSS interference while promoting spatial reuse.

[0038] Another example of a cooperative transmission sequence is shown in Figure 8. In a multi-AP network where transmissions by multiple APs are tightly coordinated, for example, by a multi-AP coordinator (AP2 in Figure 8), both the transmission timing as well as the RUs to be used for transmissions to and from vulnerable STAs can be determined by the multi-AP coordinator. AP2 sends a multi-AP Trigger frame 802 to another AP (AP1) to initiate a cooperative uplink transmission. The multi-AP Trigger frame 802 instructs AP1 to initiate UL transmissions from STA2 and also allocates RU1 to be used for UL transmissions from STA2.

[0039] After a SIFS (Short Interframe Space) interval, both AP2 and AP1 transmit Basic Trigger frames 804, with AP2 allocating RU2 for UL transmission from STA3 and AP1 allocating RU1 for UL transmission from STA2. After a SIFS interval, STA3 and STA2 transmit UL PPDUs 806 on RU2 and RU1, respectively, thereby avoiding mutual interference. After a SIFS interval, AP2 and AP1 transmit BlockAck frames 808 on RU2 and RU1, respectively. This transmission sequence allows the AP to dynamically adjust RU allocations to vulnerable STAs.

[0040] In one embodiment, an individual target wake time (TWT) agreement can be negotiated as a cooperative SP between APs. The requesting AP can function as a TWT requester STA, and the responding AP can function as a TWT responder STA. Referring to FIG. 9, STA1-1 and STA1-2 are associated with AP1, STA2-1 and STA2-2 are associated with AP2, and STA3-1 is associated with AP3. The individual TWT agreement can be negotiated between APs as a cooperative SP 902. The cooperative SP 902 can also be referred to as a cooperative TWT SP. Any of the APs assigned to the cooperative TWT SP (i.e., AP1, AP2, or AP3) can act as a sharing AP. Furthermore, an AP can send an unsolicited TWT setup response 906 to schedule another AP to join the cooperative SP. The AP sending the unsolicited TWT setup response 906 can also include a list of APs already assigned to the same cooperative SP and APs planned to be assigned. Once the cooperative TWT SP is negotiated, each AP can negotiate a new scheduled SP 904 or renegotiate an existing schedule with the vulnerable STA so that the scheduled SP 904 overlaps with the cooperative SP 902. The STA's scheduled SP 904 may be any SP in which the STA and its associated AP pre-negotiate one or more periods for exchanging frames and in which the STA is expected to be awake or in active mode during the SP, such as an S-APSD (Scheduled Automatic Power Save Delivery) SP, a scheduled PSMP (Power Save Multi-Poll) SP, a TWT (Target Wake Time) SP, or a QTP (Quiet Time Period) SP. While FIG. 9 shows the STAs negotiating the scheduled SP with their associated APs simultaneously, in practice the negotiations may occur at different times, and some STAs may already have negotiated scheduled SPs before the AP sets up the cooperative SP.Within each cooperative SP, the sharing AP decides which multi-AP cooperation scheme to use. For example, in the first cooperative SP 902, the sharing AP AP1 decides to use C-OFDMA and shares the upper half of the operating bandwidth with AP2. Therefore, AP1 and AP2 transmit to STA1-1 and STA2-1 on non-overlapping frequency channels (or RUs) during the first cooperative SP, while AP3 does not participate in the multi-AP cooperative transmission. In the second cooperative SP, the sharing AP AP1 decides to use C-TDMA and assigns subsections of its TXOP to AP2 and AP3. Therefore, during the second cooperative SP, AP1, AP2, and AP3 transmit to their associated STAs STA1-1, STA2-1, and STA3-1 without overlapping each other's transmissions.

[0041] The TWT Setup frame can be customized for multi-AP cooperation. FIG. 10 shows an example of a TWT Setup frame 1000 for a TWT request / response used to set up a cooperative SP. The Address 1 field (or A1 field) 1002 can indicate the MAC address of the target AP. The Address 2 field (or A2 field) 1004 can indicate the MAC address of the requesting AP. The Address 3 field (or A3 field) 1006 can be set to a special value (i.e., a virtual BSSID in the AP candidate set) if present, or to the MAC address of the target AP if not present. Because the TWT Setup frame is not a public Action frame, by default, an AP rejects such a frame from a STA that is not associated with the AP. Therefore, the A3 field 1006 can be set to a special value (i.e., a virtual BSSID) that is known to all APs in the AP candidate set. A TWT Setup frame with the A3 field set as the special value is accepted by APs in the AP candidate set. An AP can perform further filtering based on the TA, such as only accepting frames from other APs in an AP candidate set if one exists. Alternatively, the AP sets the BSSID to the BSSID of the receiving AP, and the receiving AP accepts frames if the TA matches the MAC address of any AP in the AP candidate set. The AP candidate set is a set of APs that have conducted basic negotiation and capability exchange and agreed to participate in multi-AP cooperative transmissions as either a sharing AP (an AP that shares an acquired TXOP with another AP) or a shared AP (a recipient of a shared TXOP). This disclosure assumes that all participating APs are members of the AP candidate set. It is assumed that the APs have completed negotiation to form the AP candidate set.

[0042] Because the timing synchronization functions (TSFs) of APs are unlikely to be synchronized, the TSF Offset / TSF Value field 1008 can indicate either the difference between the TSFs of the two participating requesting and receiving APs or the value of the requesting AP's TSF at the time of transmission to help the responding AP correctly calculate the requested target wake time. Furthermore, APs also consider each other's TBTT and BI when determining the actual start time / duration of the cooperative SP. The Member AP List field 1010 in the TWT Setup Response frame can convey a list of MAC addresses of other APs assigned to the same cooperative TWT SP. Furthermore, a reserved bit (Multi-AP Coordinated TWT subfield 1014) in the TWT Element field 1012 can be used to indicate that the TWT Element field 1012 is intended for a cooperative SP.

[0043] In the exemplary transmission shown in FIG. 11 , the scheduled SP for the STA may be a TWT, e.g., a triggered TWT SP. The STA's scheduled SP may start a little earlier than the cooperative SP so that the AP can check whether the STA is awake, the state of the STA's buffer, etc. The shared AP may pass this information to the sharing AP (e.g., at the start of the shared TXOP), which may then use this information to decide with which shared AP(s) to share the TXOP. For example, at the start of the scheduled SP, each AP, i.e., AP1, AP2, and AP3, may optionally collect information of associated STAs in its BSS by sending a Buffer Status Report Poll Trigger frame (BSRP TF) 1102 to each associated STA, to which each STA responds by sending the requested information to its associated AP. Next, the sharing AP1 may send a MAP Buffer Status Report Poll Trigger frame (BSRP TF) 1104 to the shared APs AP2 and AP3, for example, at the start of the cooperative SP1, to request information from their associated STAs. AP2 and AP3 may then each send a MAP BSR frame 1106 to AP1 in an OFDMA manner to report the buffer status (both UL and DL) of their identified or associated STAs. For example, based on the report, AP3's buffered traffic is much less than that of AP2, so AP1 decides to share its TXOP with AP2 and therefore sends a MAP TF 1108 to AP2 to indicate its intention to share the TXOP with AP2 and related transmission parameters, such as the RU, transmit period, MCS, and TX power, allocated to AP2.After the SIFS after the MAP TF 1108, AP1 and AP2 start cooperative transmission, transmitting DL PPDUs to STA1-1 and STA2-1, respectively, in an OFDMA manner, followed by each STA sending an acknowledgement frame (e.g., a BlockAck frame) back to its associated AP. The MAP BSR frame 1106 also serves the purpose of protecting the cooperative transmission by setting the NAV of all STAs within the transmission range of AP1.

[0044] An Ethertype 89-0d data frame, such as data frame 1200 in Figure 12, can be used as a MAP-BSR frame (e.g., MAP BSR frame 1106) for the purpose of sharing buffer status reports between APs. For example, the UL / DL field 1202 can indicate whether the report is for a DL or UL buffer. The Queue Size field 1204 can indicate an estimate of the total buffer size at the AP (for DL) / associated vulnerable STA (for UL) (the same encoding can be used as in 11ax).

[0045] Furthermore, an AP or STA can indicate its supported capabilities using an EHT Capabilities element 1300, as shown in FIG. 13. For example, an EHT MAC Capabilities field 1302 can include an Enhanced TWT field 1304, which can indicate whether enhanced TWT is supported. An EHT Multi-AP Capabilities field 1306 can include a C-OFDMA field, a C-TDMA field, a C-SR field, a C-BF field, and a Joint Transmission field, which can be used to indicate whether a multi-AP transmission scheme is supported. Furthermore, the EHT Multi-AP Capabilities field 1306 can include a Coordinated SP field 1308, which can indicate whether the participating APs support coordinated SP, and an SP Information Solicitation field 1310, which can indicate whether the participating APs support solicitation of information about SPs.

[0046] The TWT Setup frame (for setting up a cooperative SP) may also be carried within an Ethertype 89-0d data frame, such as the 802.11 data frame 1400 of Figure 14. For example, the data frame 1400 may include one or more TWT Element fields 1402 containing information for setting up a cooperative SP, and a sub-type field 1404 indicating that the data frame 1400 is for a TWT setup.

[0047] In various embodiments, a cooperative SP can specify a multi-AP cooperative scheme (e.g., C-OFDMA / C-TDMA, C-SR / C-BF, joint transmission, etc.) or traffic types allowed within the SP. For example, referring to FIG. 15 , cooperative SP1 1502 can be a cooperative SP for C-OFDMA / TDMA transmissions, and cooperative SP2 1504 can be a cooperative SP for C-SR / C-BF transmissions. In this case, a STA can be assigned to a scheduled SP (specific to the BSS) within a cooperative SP suitable for the STA, ensuring that the STA remains awake during suitable cooperative transmissions. Advantageously, this allows the STA to obtain more power-saving gains and avoid waking up unnecessarily during unsuitable cooperative SPs.

[0048] An AP can request another AP to set up a cooperative SP for a specific type of MAP cooperation scheme or a cooperative SP for a specific type of traffic. During the SP negotiation phase, the requesting AP can further specify its desired 20 MHz subchannel for C-OFDMA, and the responding AP can specify the 20 MHz subchannel to be assigned to the requesting AP for C-OFDMA. Similarly, the requesting AP can further specify its desired sub-timeslot within the SP for C-TDMA or for prioritized traffic, and the responding AP can specify the sub-timeslot to be assigned to the requesting AP. The AP can further protect sensitive traffic (e.g., low latency traffic / NSEP traffic) from its associated STAs of each AP during the sub-timeslot by transmitting quiet element(s) or quiet channel element(s) in the Beacon / Probe Response frame so that the BSS channel is quiet during the sub-timeslot.

[0049] A coordinated SP can be negotiated using new public Action frames, such as the Coordinated SP Request Action frame 1600 of FIG. 16 and the Coordinated SP Response Action frame 1800 of FIG. 18. For example, the Coordinated SP Request frame 1600 can include a Schedule Element field 1602 that can indicate requested SP parameters. The Schedule Element field 1602 can further include a Schedule Info field 1604, which can indicate a value of the Coordinated SP Type with reference to table 1700 of FIG. 17. For example, a value of 0 for the Coordinated SP Type indicates that the Coordinated SP is an SP for C-OFDMA, a value of 1 for the Coordinated SP Type indicates that the Coordinated SP is an SP for C-TDMA, and so on. Furthermore, the Coordinated SP Response frame 1800 can include a Status field 1802 that can indicate whether the request is accepted or rejected. The frame may further include a Schedule Element field 1804 that may indicate agreed-upon SP parameters for the cooperative SP.

[0050] In one example, the Baseline Schedule element (IEEE 802.11-2020, 9.4.2.33 Schedule element) can be reused to negotiate cooperative service points (SPs). For example, the Service Start Time field of the Baseline Schedule element indicates the expected time the service will start in microseconds and represents the lower four octets of the TSF timer value at the start of the first SP. The Service Interval field indicates the time between two consecutive SPs in microseconds and represents the time measured from the start of one SP to the start of the next SP. Furthermore, some reserved bits in the Schedule Info field can be used to indicate cooperative SP type information, i.e., the multi-AP cooperation method implemented within the cooperative SP. The Specification Interval field can be reused to convey the number of cooperative SPs in the case of periodically recurring cooperative SPs.

[0051] Alternatively, a TWT Setup frame can be used to negotiate a cooperative SP. Referring to the exemplary TWT Setup frame 1900 of FIG. 19 , which may be utilized for a TWT request and a TWT response to set up a multi-AP cooperative TWT SP, the TWT Setup frame 1900 can include one or more TWT Element fields 1902, which include a Coordinated SP Type field 1904 for specifying a multi-AP cooperative scheme and / or an allowed traffic type. For example, the Coordinated SP Type field 1904 can indicate a value of the cooperative SP type based on table 1700 of FIG. 17 for indicating the cooperative SP type. Furthermore, the TWT Setup frame 1900 can include an eTSPEC field 1906 that can indicate traffic characteristics. For example, if the Coordinated SP Type field 1904 indicates a particular traffic type, further characteristics of the traffic can be indicated in the eTSPEC field 1906.

[0052] To negotiate intra-BSS TWT, the TWT Channel field (e.g., TWT Channel field 1908) and the Extended TWT Channel field (e.g., Extended TWT Channel field 1910) of the TWT Element of the TWT Setup frame are used together for selective transmission of HE / EHT subchannels. The TWT Channel can be used to convey the secondary channel(s) requested for HE / EHT STAs within the primary 160 MHz. The Extended TWT Channel can be used to convey the secondary channel(s) requested for EHT STAs within the secondary 160 MHz. One bit set to 1 indicates a 20 MHz channel for STAs operating at 20 MHz, and four least significant bits (LSBs) or four most significant bits (MSBs) all set to 1 indicate the first or second 80 MHz channel within the secondary 160 MHz.

[0053] In TWT negotiation for C-OFDMA MAP cooperative SP, the TWT Channel and Extended TWT Channel fields in the TWT Element of the TWT Setup frame are used together to convey the desired / assigned subchannels of the requesting AP during C-OFDMA MAP transmission. The TWT Channel is used to convey the secondary channel(s) requested for the AP within the primary 160 MHz, with each bit representing one 20 MHz subchannel. The Extended TWT Channel is used to convey the secondary channel(s) requested for the AP within the secondary 160 MHz, with each bit representing one 20 MHz subchannel.

[0054] An AP can also request a sub-SP (i.e., a specific time slot) within a cooperative SP. A sub-SP may indicate a smaller period during which the requesting AP needs semi-guaranteed channel access (e.g., for jitter-sensitive low-latency traffic). Referring to FIG. 20, in TWT negotiation for a C-TDMA MAP cooperative SP or a cooperative SP for prioritized traffic, the TWT Setup frame (i.e., TWT Element 2000, etc., in FIG. 20) may further convey information related to the desired / assigned sub-SP (within the cooperative SP) for the requesting AP during the C-OFDMA MAP transmission. - If set, the Sub-SP Non-Negotiable field 2002 indicates that the start time of the requested sub-SP cannot be changed. - The Sub-SP Start Offset field 2004 is used to convey the time offset from the SP start time to the start time of the requested / assigned sub-SP. - The Sub-SP Duration field 2006 is used to convey the duration of the requested / allocated sub-SP. - The Sub-SP Intervals field 2008 indicates the time interval between successive sub-SPs if the sub-SPs are also periodic.

[0055] If it is decided in 11be that mixing C-OFDMA and C-TDMA transmissions within the same MAP shared TXOP is not allowed, it is also possible to reuse the TWT Channel and Extended TWT Channel fields as the Sub-SP Start Offset and Sub-SP Duration fields when the cooperative SP type is C-TDMA or is reserved for prioritized traffic.

[0056] FIG. 21 shows an example diagram 2100 of cooperative SP for C-TDMA. In this example, all STAs have low-latency traffic, and the negotiated cooperative SP type is low-latency. When negotiating cooperative SP with AP1, AP2 and AP3 may also indicate subsections of the cooperative SP (e.g., sub-SP 2104, referred to as sub-SPs) during which AP2 and AP3 require quasi-guaranteed channel access for specific traffic types (e.g., low-latency traffic that is highly jitter-sensitive). If the sub-SPs of the member APs of the cooperative SP do not overlap, during a shared TXOP, the sharing AP may employ C-TDMA transmission and make a best effort to provide a shared TXOP to each member AP during each requested sub-SP. Each AP communicates with its associated STAs using its assigned sub-SP 2104. AP1, the sharing AP, may reclaim the unused portion of the TXOP for transmission to its associated STAs (e.g., for transmitting DL-PPDU 2102).

[0057] If the sub-SPs of the member APs of a cooperative SP overlap with each other, the sharing AP may not be able to properly share the TXOP using only C-TDMA during the shared TXOP. In such a case, the sharing AP may employ a mixed C-TDMA and C-OFDMA transmission, making its best effort to provide a shared TXOP to each member AP during each requested sub-SP while ensuring that the member APs are assigned different sub-channels for at least the sub-SP. For example, referring to the C-TDMA+C-OFDMA example diagram 2200 of FIG. 22, the sharing AP AP1 uses the entire bandwidth to transmit to and from its associated STAs via the C-TDMA portion 2204 during the first portion of the shared TXOP and allocates the second portion of the shared TXOP to other member APs of the cooperative SP. For example, the sharing AP AP1 may transmit a MAP TF 2202 to the shared APs AP2 and AP3 to signal C-TDMA parameters for the C-TDMA portion 2204. During the second part of the TXOP, the sharing AP may further employ C-OFDMA, share the TXOP with the member APs, and assign non-overlapping subchannels to each member AP. To achieve this, the sharing AP may transmit a second MAP TF 2206 at the end of its own C-TDMA portion 2204 of the TXOP to assign subchannels to the member APs during the C-OFDMA portion 2208 of the shared TXOP, i.e., assigning a secondary 160 MHz channel to AP2 and a primary 160 MHz channel to AP3 (assuming the operating channel of all APs is 320 MHz). Alternatively, if subchannels have already been assigned during the cooperative SP negotiation 2210 (e.g., using the TWT Channel and TWT Extended Channel fields of the TWT element), the second MAP TF 2206 for C-OFDMA may be skipped since each AP already knows its assigned subchannel.Each of the shared APs, AP2 and AP3, uses its assigned channel in the sub-SP to communicate with its associated STAs. Furthermore, the sharing AP can conveniently use the unused portion of the TXOP (either in the time domain or the frequency domain) to transmit to its associated STAs. In this example, all STAs have low latency traffic, and the negotiated cooperative SP type is low latency.

[0058] In one embodiment, each AP may also advertise cooperative SPs to STAs in the BSS, i.e., the AP may overlay broadcast TWT SPs on top of the cooperative SPs and advertise them via the TWT element of the Beacon frame. For example, referring to transmission diagram 2300 of FIG. 23, AP1 and AP2 may use Beacon frame 2302 to set up broadcast TWT SPs that overlap with the cooperative SPs, e.g., set up a set of extended TWT SPs (broadcast TWT SPs with ID1) that overlap with cooperative SP1 and another set of extended TWT SPs (broadcast TWT SPs with ID2) that overlap with cooperative SP2. In this example, the AP may not need to identify the type of STA; instead, the STA may negotiate in transmission portion 2304 to join the broadcast TWT SPs of interest. The STA does not need to be aware of the existence of the overlapping cooperative SPs. Thus, the AP does not need to identify and micro-manage STAs because STAs can sign up for SPs of interest; for example, STA1-1 and STA2-1, which have low latency traffic to send, can negotiate to join an extended TWT SP (with broadcast TWT ID1), and STA1-2 and STA2-2, which have NSEP traffic to send, can negotiate to join an extended TWT SP (with broadcast TWT ID2).

[0059] In one embodiment, an AP can reduce contention between priority traffic across OBSSs by requesting information about scheduled SPs for the second AP's associated STAs from the second AP and using that information to schedule SPs for its associated STAs. Referring to transmission diagram 2400 in FIG. 24 , APs in the AP candidate set exchange information about their (existing and / or proposed) extended TWT SPs and adjust their respective extended TWT SPs so that the TWT SPs do not overlap in the time / frequency domain. For example, AP2 can request the extended TWT information of AP1 and AP3 by sending an SP information request 2402 to AP1 and an SP information request 2404 to AP3, respectively. Using the extended TWT information of AP1 and AP3, AP2 can ensure that its own extended TWT SP, i.e., extended TWT SP 2406, does not overlap in time / frequency with the extended TWT SPs of AP1 / AP3.

[0060] Information exchange between APs may be over the air (in-band) or over a backhaul link (wired / wireless) (out-of-band). The extended TWT may be as defined in U.S. Patent No. 6,277,999. While adjustments can be made for any TWT SP, the extended TWT adjustment may provide more benefit by ensuring that priority traffic (e.g., low latency traffic) of the OBSS does not simultaneously compete for the channel. This embodiment may be suitable for deployments where there is no strong relationship between APs (e.g., non-enterprise deployments) and where APs do not intend to share TXOPs.

[0061] An AP can decode another AP's Beacon frame, collect information about the other AP's broadcast extended SP (if present), and passively adjust its own extended SP (if necessary) to avoid overlap. However, because individual TWT SPs are not advertised in Beacon frames, another AP may not be aware of the AP's individual TWT SP. An AP can also request information about another AP's service period (AP cooperative SP, or the AP's STA's scheduled SPs (both broadcast and individual SPs)). For example, an AP can request information about its cooperative SPs from another AP and use this information to request to join the cooperative SP of interest. Alternatively, an AP can request information about the extended TWT SPs for prioritized traffic from another AP and adjust its own extended TWT for the prioritized SPs as necessary to prevent overlap between the two APs' SPs. In a managed network (e.g., an enterprise deployment), such coordination of SPs between APs can also be managed centrally, for example, by AP controller(s). If a master / slave hierarchy exists among APs, the master AP can assist in coordinating SPs between APs.

[0062] Either a data frame having an "Ethertype 89-0d" frame body, such as data frame 2500 in Figure 25, or a new public Action frame, such as TWT SP Information Request / Response Action frame 2700 in Figure 27, can be used to request or share information about an AP's service period(s) with other APs. Referring to data frame 2500, the TWT SP Type field can indicate a value of the TWT SP Type based on table 2600 in Figure 26. For example, a value of 0 for TWT SP Type indicates that the AP cooperative SP is an SP for C-OFDMA / C-TDMA, a value of 1 indicates that the AP cooperative SP is an SP for C-SR / C-BF, and so on. The data frame 2500 may include zero or more TWT Element fields 2504 that convey information about the TWT SP and zero or more eTSPEC Element fields 2506 that convey information about the characteristics of the traffic expected / allowed to be exchanged during the TWT SP.

[0063] Referring to the TWT SP Information Request / Response frame 2700 of FIG. 27, the following fields are always carried in a TWT SP Information Response frame and may optionally be carried in a TWT SP Information Request frame: - Current TSF field 2702: conveys the TSF value of the AP at the time of transmission, which helps the receiving AP calculate the target wake time of the TWT SP. - TWT Element field 2704: Each TWT element carries information about one TWT SP of the transmitting AP. Additionally, an eTSPEC Element field 2706, which carries information about the characteristics of the traffic expected / allowed to be exchanged during the TWT SP, may optionally be carried in both frames.

[0064] In one embodiment, an AP can also request to join another AP's existing scheduled SP (e.g., either an individual TWT SP or a broadcast TWT SP). Referring to the transmission diagram 2800 of FIG. 28, AP2 has set up a broadcast extended TWT SP (ID 2) 2802 (e.g., for low-latency traffic) for its associated STAs. AP1 and AP3 collect information about AP2's extended TWT SP for low latency by passively listening to AP2's Beacon frames or by exchanging SP information request / response frames. AP1 and AP3 request to join AP2's broadcast TWT SP (ID 2) 2802. During this TWT SP, AP2 knows that AP1 and AP3 are also members of the TWT SP and can share its TXOP with AP1 and AP3, e.g., for C-TDMA transmission.

[0065] An AP can also indicate a desired subchannel or subSP in the TWT setup request. In this case, the first AP requesting to join the TWT SP is the TWT requester STA (or TWT scheduled STA), and the second AP accepting the request is the TWT responder STA (or TWT scheduler STA). During this TWT SP, the second AP is expected to act as the sharing AP, and the first AP is the shared AP. The first AP should wait for the second AP to start cooperative transmission at the start of the TWT SP and refrain from attempting to gain access to the channel. In this example, there are four phases: - Phase 1 (SP Information Collection Phase): AP1 and AP3 collect information of TWT SPs (broadcast / individual TWT SPs for associated STAs or cooperative SPs for other APs) provided by AP2. Phase 2 (AP-AP SP Join Phase): AP1 and AP3 request to join one of AP2's broadcast-enhanced TWT SPs (e.g., a SP reserved for low-latency traffic). AP1 and AP3 can also request sub-SPs within the TWT SP. Phase 3 (Intra-BSS SP Request): If an intra-BSS SP does not yet exist, AP1 and AP3 can set up an SP for each associated STA that can benefit from MAP coordinated transmission, such that the SP is located within the TWT SP of AP2 to which AP1 and AP3 have joined. The intra-BSS SP overlaps with any sub-SPs requested by the AP. This can be achieved, for example, by the AP sending an unsolicited TWT Setup Response frame to the selected STA if a new TWT SP is being set up, or by sending a TWT Information frame to adjust the start time of an existing TWT SP. Phase 4 (MAP cooperative transmission between TWT SPs): AP2 initiates cooperative transmission (e.g., C-TDMA / C-OFDMA) between TWT SPs, e.g., allocating time / frequency resources for AP1 and AP3 within a shared TXOP.

[0066] FIG. 29 shows a TWT Setup frame 2900 that can be utilized via individual TWT setup to join an existing TWT SP of another AP. Because the TWT Setup frame is not a public Action frame, a special exception can be defined in the IEEE 802.11be specification to allow an AP to accept a TWT Setup frame transmitted by another AP. Alternatively, a new public Action frame equivalent to the TWT Setup frame can be defined for AP-to-AP TWT setup. The TWT Setup frame 2900 can include one or two TWT Element fields 2902, which can include a Control field 2904 and a TWT Parameter Information field 2908. The Control field 2904 can include a Multi-AP Coordinated TWT field 2906, which can indicate using a reserved bit that the TWT element is for an AP-to-AP setup.The TWT Parameter Information field 2908 may include an Extended TWT Channel field 2910, which may convey the requested secondary channel(s) within the secondary 160 MHz; a MAP Coordination type field 2912, which may indicate a MAP coordination transmission scheme that may be used during the TWT SP; a Sub-SP Non-Negotiable field 2914 (if set), which may indicate that the requested sub-SP start time cannot be changed; a Sub-SP Start Offset field 2916, which may indicate the time offset from the SP start time to the start of the requested / assigned sub-SP; a Sub-SP Duration field 2918, which may indicate the duration of the requested or assigned sub-SP; and a Sub-SP Intervals field 2920, which may indicate the time interval between successive sub-SPs if the sub-SPs are also periodic.

[0067] Alternatively, instead of the Action frame, the TWT Setup frame can be encapsulated in an ethertype 89-0d data frame. This method does not require defining a new public Action frame for AP-AP TWT setup. Instead of including its own TSF value / TSF offset in the TWT Setup Request frame, the requesting AP can also calculate the target wake time of the TWT SP based on the TSF of the responding AP, so that the Target Wake Time field of the TWT element indicates the actual start time from the perspective of the responding AP, and no further adjustment is required for it.

[0068] The Sub-SP Non-Negotiable field 2914 can be set by the requesting AP to indicate to the responding AP that it requires a quasi-guaranteed period during which it should have a very high probability of accessing the channel. Such a request can be made, for example, for low-latency traffic that is highly sensitive to jitter. If the responding AP accepts the TWT request, it shall ensure that the AP or its associated STAs do not transmit during the sub-SP. The Sub-SP Start Offset field 2916 can indicate the time offset from the requested SP start time to the start of the requested / assigned sub-SP. Alternatively, this field can indicate the actual (responding AP's) TSF where the first sub-SP is requested to start.

[0069] Additionally, a Sub-SP Duration field 2918 may indicate the duration of each sub-SP. A Sub-SP Intervals field 2920 may indicate the time interval between successive sub-SPs if the sub-SPs are also periodic and multiple sub-SPs occur within the requested TWT SP.

[0070] In this manner, an AP can use the TWT Setup frame 2900 to join individual scheduled SPs of other APs of interest. Alternatively, a broadcast TWT setup can be used to join an AP's existing scheduled SPs. For example, the TWT Setup frame 3000 of FIG. 30 can be utilized in a manner similar to that described for the TWT Setup frame 2900 to enable an AP to join scheduled broadcast SPs of other APs of interest.

[0071] Figure 31 shows an example diagram 3100 illustrating the use of sub-SPs to protect sensitive traffic (e.g., jitter-sensitive low latency traffic). The phases of this example are as follows: - Phase 1: STA2-2 has negotiated periodic TWT SP#20 with AP2 for jitter-sensitive low-latency traffic. This SP is short in duration but occurs frequently. Because the traffic is highly sensitive to jitter, AP2 must ensure that STA2-2's traffic is given priority during the SP. - Phase 2A: AP2 requests to join AP1's broadcast TWT#1 at 3102. - Phase 2B: AP2 requests allocation of a non-negotiable sub-SP 3104 within TWT#1. - Phase 3: At the start of TWT#1, AP2 is aware of TWT SP#1 of AP1, so it waits for MAP TF 3106 from AP1. - Phase 4: Within the TWT SP, AP1 shares its TXOP with AP2 (e.g., using C-TDMA), ensuring that AP2 has access to the medium to transmit jitter-sensitive traffic during AP2's TWT#20 SP. Each AP can further protect the sub-SP by sending quiet elements / quiet channel elements to each associated STA so that the sub-SP overlaps with the quiet period, ensuring that third-party STAs do not transmit during the sub-SP. - Phase 5: AP2 transmits / receives sensitive traffic 3108 to / from associated STAs during TWT#20 SP, which overlaps with AP1's TWT#1.

[0072] It can be seen that by coordinating TWT SPs between APs, APs can effectively adjust their transmissions within the obtained TXOPs, thereby mitigating the adverse effects of OBSS transmissions on jitter-sensitive traffic.

[0073] In the exemplary diagram 3100, it is assumed that AP2 has collected information about AP1's TWT SP by passively listening to AP1's Beacon frames or by proactively requesting such information from AP1 using SP information request / response frames. STA1-1 and STA2-1 are associated with AP1 and AP2, respectively. Because AP1's TWT SP#1 and AP2's TWT SP#20 may have different periods (determined by the TWT wake interval of each TWT agreement), the start time of the requested sub-SP may not be constant but may change at different occurrences of TWT SP#1. AP1 needs to calculate the start time of the sub-SP at the start of each new TWT SP#1 so that the sub-SP aligns with AP2's TWT SP#20. Alternatively, before every new instance of TWT SP#1, AP2 may inform AP1 of the correct start time of the requested sub-SP, for example, using a TWT information frame. AP1 and AP2 can further protect jitter-sensitive traffic from each AP's associated STAs by transmitting quiet element(s) or quiet channel element(s) in the Beacon / Probe response frame so that the BSS channel is quiet during the non-negotiable sub-SP.

[0074] FIG. 32 illustrates a configuration of a communications device 3200, e.g., a communications apparatus, e.g., a sharing AP or a shared AP, according to various embodiments. The communications device 3200 may include at least one antenna (wireless I / F module) 3202 for transmitting and receiving signals (for simplicity, only one antenna is shown in FIG. 32). The communications device may include a wired I / F module 3212, a wireless I / F module 3202, a power supply 3220, at least one memory 3218, a central processing unit (CPU) 3214 including at least one processor, and at least one secondary storage device 3216. The wireless I / F module 3202 may further include a MAC sublayer 3206 and a PHY sublayer 3204. The MAC sublayer 3206 includes a service period management module 3208, which manages service periods for associated STAs and maintains a record of all such SPs in a coordinated service period record 3210. The wireless I / F module 3212, the CPU 3214, the at least one memory 3218, and the at least one secondary storage device 3216 can together function as circuitry of the communications device 3200 configured to generate TWT request frames, response frames, Trigger frames, Multi-STA BlockAck frames, DL MU PPDUs, Beacon frames, DL PPDUs, frames containing TWT elements, RTS / CTS frames, TWT information frames, NSEP response frames, NSEP frames, and TWT Setup frames for coordinated and prioritized traffic (i.e., low latency traffic) as described in this disclosure. The antenna 3202 can then transmit the generated frame(s) or PPDU(s) to other communications devices, e.g., STA(s).The antenna 3202 can receive TWT request frames, response frames, PS-Poll frames, QoS Null frames, BlockAck frames, TB PPDUs (i.e., UL PPDUs), CTS frames, NSEP request frames, NSEP frames, and TWT Setup frames for moderated and prioritized traffic (i.e., low latency traffic) from other communications devices, i.e., STA(s), as described in this disclosure. Circuitry of the communications device 3200 can then be configured to process the received frame(s) or PPDU(s).

[0075] FIG. 33 illustrates a configuration of a communications device 3300, e.g., a communications apparatus, e.g., a non-AP STA, according to various embodiments. The communications device 3300 may include at least one antenna 3302 for transmitting and receiving signals (for simplicity, only one antenna is shown in FIG. 33). The communications device may include a wired I / F module 3312, a wireless I / F module 3302, a power supply 3320, at least one memory 3318, a central processing unit (CPU) 3314 including at least one processor, and at least one secondary storage device 3316. The wireless I / F module 3302 may further include a MAC sublayer 3306 and a PHY sublayer 3304. The MAC sublayer 3306 includes a service period subscription module 3308, which manages the service periods of which the communications device 3300 is a member and maintains a record of all such SPs in a subscribed service period record 3310. The wireless I / F module 3312, the CPU 3314, the at least one memory 3318, and the at least one secondary storage device 3316 can together function as circuitry of the communications device 3300 configured to generate TWT request frames, response frames, PS-Poll frames, QoS Null frames, BlockAck frames, TB PPDUs (i.e., UL PPDUs), CTS frames, NSEP request frames, NSEP frames, and TWT Setup frames for throttled and prioritized traffic (i.e., low latency traffic) as described in this disclosure. The antenna 3302 can then transmit the generated frame(s) or PPDU(s) to other communications devices, such as AP(s).The antenna 3202 can receive TWT response frames, Trigger frames, Multi-STA BlockAck frames, DL MU PPDUs, Beacon frames, DL PPDUs, frames containing TWT elements, RTS / CTS frames, TWT information frames, NSEP response frames, NSEP frames, and TWT Setup frames for coordinated and prioritized traffic (i.e., low latency traffic) from other communications devices, i.e., AP(s), as described in this disclosure. Circuitry of the communications device 3300 can then be configured to process the received frame(s) or PPDU(s).

[0076] 34 shows a flow diagram 3400 illustrating a communication method according to various embodiments. In step 3402, a frame indicating a request to set up one or more cooperative SPs is generated. In step 3404, the frame is transmitted to an AP.

[0077] 35 illustrates a partially boxed schematic diagram of a communications device 3500 that may be implemented to support cooperative SPs. The communications device 3500 may be implemented as a sharing AP, a shared AP, or an associated STA, according to various embodiments.

[0078] The various functions and operations of the communication device 3500 are arranged in layers according to a hierarchical model, where lower layers report to and receive instructions from higher layers according to IEEE specifications. For purposes of brevity, the details of the hierarchical model will not be described in this disclosure.

[0079] As shown in FIG. 35, the communications device 3500 may include circuitry 3514, at least one wireless transmitter 3502, at least one wireless receiver 3504, and multiple antennas 3512 (for simplicity, only one antenna is shown in FIG. 35 for illustrative purposes). The circuitry may include at least one controller 3506, which is used with the assistance of software and hardware to perform the tasks it is designed to perform, including controlling communications with one or more other multi-link devices in a MIMO wireless network. The at least one controller 3506 may control at least one transmit signal generator 3508 to generate frames to be transmitted via the at least one wireless transmitter 3502 to one or more other STAs, APs, or AP multi-link devices (MLDs), and may further control at least one receive signal processor 3510 to process frames received via the at least one wireless receiver 3504 from one or more other STAs, APs, or AP MLDs. The at least one transmit signal generator 3508 and the at least one receive signal processor 3510 may be separate modules of the communication device 3500 that communicate with the at least one controller 3506 for the functions described above. Alternatively, the at least one transmit signal generator 3508 and the at least one receive signal processor 3510 may be included in the at least one controller 3506. It will be understood by those skilled in the art that the arrangement of these functional modules is flexible and may vary according to actual needs and / or requirements. The data processing unit, storage unit, and other related control units may be provided on an appropriate circuit board and / or chipset.

[0080] In various embodiments, in operation, the at least one wireless transmitter 3502, the at least one wireless receiver 3504, and the at least one antenna 3512 may be controlled by at least one controller 3506. Furthermore, while only one wireless transmitter 3502 is shown, it will be understood that there may be more than one such transmitter.

[0081] In various embodiments, in operation, the at least one wireless receiver 3504, together with the at least one receive signal processor 3510, form the receiver of the communications device 3500. In operation, the receiver of the communications device 3500 provides the functionality necessary for multi-link communications. While only one wireless receiver 3504 is shown, it will be understood that there may be more than one such receiver.

[0082] In operation, the communications device 3500 provides functionality necessary for a cooperative SP. For example, the communications device 3500 may be a first AP. In operation, the circuit 3514 may generate a request frame indicating a request to set up one or more cooperative SPs. In operation, the wireless transmitter 3502 may transmit the request frame to a second AP.

[0083] In operation, the wireless receiver 3504 can receive a response frame from the second AP, the response frame indicating acceptance of the request to set up one or more cooperative SPs. The wireless transmitter 3502 can be further configured to transmit a frame to one or more associated STAs to set up scheduled SPs that overlap with the cooperative SPs. The request frame, the response frame, and the frame can be TWT Setup frames, and the cooperative SP can be a TWT SP. The TWT Setup frame carries indication information that the cooperative SP is an SP for multi-AP cooperative transmission and further carries a timing synchronization function (TSF) value of the AP transmitting the TWT Setup frame. The TWT Setup frame received from the second AP can also carry identity information of one or more other APs that are members of the cooperative SPs. The TWT Setup frames may indicate subchannels requested by the first AP or assigned to the first AP by the second AP in the TWT Channel and TWT Extended channel fields of the TWT element of each TWT Setup frame, where these subchannels are a subset of the second AP's operating channel. The TWT Setup frames may indicate the start time offset, duration, and interval of one or more sub-SPs requested by the first AP or assigned to the first AP by the second AP in the TWT element of each TWT Setup frame, where these sub-SPs are part of a cooperative SP. The first AP may be the only AP permitted by the second AP to transmit in its assigned subchannel or in its assigned sub-SP during a shared TXOP for a multi-AP cooperative transmission initiated by the second AP.

[0084] The first AP may be further configured to participate in a shared TXOP for a multi-AP cooperative transmission initiated by the second AP within the cooperative SP, and the radio transmitter 3502 of the first AP may be further configured to transmit a frame to a STA associated with the first AP in a manner coordinated with the second AP. The radio transmitter 3502 may be further configured to transmit a frame reporting DL and UL buffer statuses of the first AP's BSS to the second AP at the start of the shared TXOP. The multi-AP cooperative transmission may be one of a C-OFDMA transmission, a C-TDMA transmission, a C-SR transmission, a C-BF transmission, or a cooperative MU-MIMO transmission. The circuit 3514 may be further configured to determine an appropriate type of multi-AP cooperative transmission for the associated STA, and the radio transmitter 3502 may be further configured to transmit a frame to the associated STA to set up a scheduled SP that overlaps with the corresponding cooperative SP based on the determined type of multi-AP cooperative transmission, the frame being a request frame and a TWT Setup frame. The TWT Setup frames may indicate subchannels requested by the first AP or assigned to the first AP by the second AP in the TWT channel and TWT Extended channel fields of the TWT element of each TWT Setup frame, where these subchannels are a subset of the second AP's operating channel. The TWT Setup frames may indicate the start time offset, duration, and interval of one or more sub-SPs requested by the first AP or assigned to the first AP by the second AP in the TWT element of each TWT Setup frame, where these sub-SPs are part of a cooperative SP. The first AP may be the only AP permitted by the second AP to transmit in its assigned subchannel or in its assigned sub-SP during a shared TXOP for a multi-AP cooperative transmission initiated by the second AP.

[0085] In operation, the wireless receiver 3504 can receive a frame transmitted by the second AP, the frame being one of a Beacon frame, an Action frame, or a Data frame, and the circuit 3514 can be further configured to extract information of an SP associated with the second AP from the received frame. The SP may be a TWT SP. The wireless transmitter 3502 can be further configured to transmit a TWT Setup request frame to the second AP to request joining one or more of the associated SPs of the second AP. The wireless transmitter 3502 can be further configured to transmit a frame to one or more associated STAs to set up scheduled SPs that do not overlap with the associated SPs of the second AP. The TWT Setup frames can indicate subchannels requested by the first AP or assigned to the first AP by the second AP in a TWT channel field and a TWT Extended channel field of a TWT element of each TWT Setup frame, where these subchannels are a subset of the operating channel of the second AP. The TWT Setup frame may indicate, in the TWT element of each TWT Setup frame, the start time offset, duration, and interval of one or more sub-SPs requested by the first AP or assigned to the first AP by the second AP, where these sub-SPs are part of a cooperative SP. The first AP may be the only AP permitted by the second AP to transmit in the assigned sub-channel or in the assigned sub-SP during a shared TXOP for a multi-AP cooperative transmission initiated by the second AP.

[0086] The communication device 3500 may be a non-AP STA. The wireless receiver 3504, in operation, can receive one of a Beacon frame or an Action frame from an associated AP. The circuit 3514, in operation, can extract information of an SP for cooperative transmission from the frame. The wireless transmitter 3502, in operation, can transmit a request frame to the AP, the request frame indicating a request to join the SP. The SP may be a TWT SP, and the request frame may be a TWT Setup request frame.

[0087] The present disclosure can be implemented by software, hardware, or software cooperating with hardware. Each functional block used in the above-described embodiments can be implemented, in part or in whole, by an LSI such as an integrated circuit. Each process described in each embodiment can be controlled, in part or in whole, by the same LSI or a combination of LSIs. The LSI can be formed as multiple individual chips, or a single chip can be formed to include some or all of the functional blocks. The LSI can include a data input / output unit coupled thereto. Depending on the degree of integration, the LSI can also be referred to as an IC, system LSI, super LSI, or ultra LSI. However, the technology for implementing an integrated circuit is not limited to LSI, and can be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (Field Programmable Gate Arrays), which can be programmed after LSI fabrication, and reconfigurable processors, which can reconfigure the connections and settings of circuit cells arranged within the LSI, can also be used. The present disclosure can be implemented using digital or analog processing. If future integrated circuit technologies replace LSI as a result of advances in semiconductor technology or other derivative technologies, the future integrated circuit technologies can be used to integrate functional blocks. Biotechnology can also be applied.

[0088] The present disclosure may be implemented by any type of apparatus, device, or system having communication capabilities, referred to as a communications device.

[0089] Some non-limiting examples of such communication devices include telephones (e.g., mobile phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, e-book readers, telehealth / telemedicine equipment, vehicles providing communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

[0090] Communication devices are not limited to portable or mobile devices, but can also include any type of apparatus, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "thing" in an "Internet of Things" (IoT) network.

[0091] Communications can include exchanging data, for example, through cellular systems, wireless LAN systems, satellite systems, and various combinations thereof.

[0092] A communications device may include a controller or a sensor coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications device may include a controller or a sensor that generates control or data signals used by the communications device to perform the communications functions of the communications device.

[0093] Communications devices may further include infrastructure facilities, such as base stations, access points, and any other apparatus, devices, or systems that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

[0094] A non-limiting example of a station may be a station included in a first plurality of stations belonging to a multi-link station logical entity (i.e., AP MLD, etc.), where the stations of the first plurality of stations, as part of the first plurality of stations belonging to the multi-link station logical entity, share a common Medium Access Control (MAC) data service interface to higher layers, where the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).

[0095] In this disclosure, the following statements are discussed:

[0096] (Statement 1) a first access point (AP), a circuit for generating a request frame that, when operational, indicates a request to set up one or more cooperative service periods (SPs); a transmitter that, in operation, transmits a request frame to a second AP; a first access point (AP) comprising:

[0097] (Statement 2) In operation, the system further comprises a receiver that receives a response frame from the second AP, the response frame indicating acceptance of the request to set up one or more cooperative SPs, and the transmitter is further configured to transmit a frame to one or more associated stations (STAs) to set up scheduled SPs that overlap with the cooperative SPs. The first AP described in statement 1.

[0098] (Statement 3) The request frame, the response frame, and the frame are Target Wake Time (TWT) Setup frames, and the cooperative SP is a TWT SP; The first AP described in statement 2.

[0099] (Statement 4) The TWT Setup frame carries indication information that the cooperative SP is an SP for multi-AP cooperative transmission, and further carries a timing synchronization function (TSF) value of the AP transmitting the TWT Setup frame; The first AP described in statement 3.

[0100] (Statement 5) the TWT Setup frame received from the second AP further carries identity information of one or more other APs that are also members of the cooperative SP; The first AP described in statement 3.

[0101] (Statement 6) The first AP is further configured to participate in a shared TXOP for multi-AP cooperative transmission initiated by a second AP within the cooperative SP, and a transmitter of the first AP is further configured to transmit frames to a STA associated with the first AP in a cooperative manner with the second AP. The first AP described in statement 1.

[0102] (Statement 7) The transmitter is further configured to transmit, at the start of the shared TXOP, a frame reporting a downlink (DL) buffer status and an uplink (UL) buffer status of its own basic service set (BSS) to the second AP. The first AP mentioned in statement 6.

[0103] (Statement 8) The multi-AP cooperative transmission is one of cooperative orthogonal frequency division multiple access (OFDMA) transmission, cooperative time division multiple access (TDMA) transmission, cooperative spatial reuse (SR) transmission, cooperative beamforming (BF) transmission, or cooperative multi-user multiple-input multiple-output (MU-MIMO) transmission; The first AP mentioned in statement 6.

[0104] (Statement 9) the circuitry is further configured to determine an appropriate type of multi-AP cooperative transmission for each associated STA; and the transmitter is further configured to transmit, based on the determined multi-AP cooperative transmission type, a frame to the associated STA for setting up a scheduled SP that overlaps with the corresponding cooperative SP, wherein the request frame and the frame are TWT Setup frames; The first AP mentioned in statement 8.

[0105] (Statement 10) and a receiver configured to receive a frame transmitted by the second AP, the frame being one of a Beacon frame, an Action frame, or a Data frame, in operation, and further configured to extract information of an SP associated with the second AP from the received frame. The first AP described in statement 1.

[0106] (Statement 11) SP is TWT SP, The first AP described in statement 10.

[0107] (Statement 12) the transmitter is further configured to send a TWT setup request frame to the second AP to request joining one or more of the associated SPs of the second AP; The first AP mentioned in statement 11.

[0108] (Statement 13) the transmitter is further configured to transmit a frame to one or more associated STAs to set up a scheduled SP that does not overlap with an associated SP of the second AP; The first AP described in statement 10.

[0109] (Statement 14) The TWT Setup frames indicate subchannels requested by the first AP or assigned to the first AP by the second AP in a TWT channel field and a TWT Extended channel field of a TWT element of each TWT Setup frame, the subchannels being a subset of the operating channel of the second AP; The first AP described in statements 3, 9, and 12.

[0110] (Statement 15) The TWT Setup frame indicates, in a TWT element of each TWT Setup frame, a start time offset, a duration, and an interval of one or more sub-SPs requested by the first AP or assigned to the first AP by the second AP, and the sub-SPs are part of a cooperative SP; The first AP described in statements 3, 9, and 12.

[0111] (Statement 16) The first AP is the only AP permitted by the second AP to transmit on the assigned sub-channel or the assigned sub-SP during a shared TXOP for multi-AP cooperative transmission initiated by the second AP; AP as set out in Statements 14 and 15.

[0112] (Statement 17) A non-AP STA, a receiver that, in operation, receives one of a Beacon frame or an Action frame from an AP associated with the receiver; a circuit for extracting SP information for cooperative transmission from a frame during operation; In operation, a transmitter that transmits a request frame to an AP, the request frame indicating a request to join an SP; A non-AP STA.

[0113] (Statement 18) The SP is a TWT SP and the request frame is a TWT setup request frame. Non-AP STAs as described in Statement 17.

[0114] (Statement 19) generating a request frame indicating a request to set up one or more coordinated service periods (SPs); sending a request frame to the AP; A method comprising:

[0115] Thus, it can be seen that the embodiments of the present invention provide a communication device and a communication method that support cooperative SPs.

[0116] While the foregoing detailed description of embodiments of the present invention has presented exemplary embodiments, it should be understood that numerous variations exist. Furthermore, it should be understood that the exemplary embodiments are examples and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the foregoing detailed description provides those skilled in the art with convenient guidance for implementing the exemplary embodiments. It should be understood that various changes can be made in the function and organization of the steps and methods of operation described in the exemplary embodiments, and in the modules and structure of the devices described in the exemplary embodiments, without departing from the scope of the subject matter set forth in the appended claims.

Claims

1. a second access point, a receiver for receiving a first frame from a first access point that initiates negotiation of a first service period (SP); a transmitter that transmits a second frame to the first access point in response to the first frame; the transmitter transmits a third frame to one or more stations associated with the second access point, the third frame communicating information about the first SP; Second access point.

2. The information includes information of a second SP that overlaps the first SP. The second access point of claim 1 .

3. the second SP is a target wake time (TWT) SP, and the third frame is a beacon frame advertising the TWT SP; The second access point of claim 2 .

4. The beacon frame includes a TWT element, and the TWT element indicates a broadcast TWT, a TWT wake-up interval, and a minimum TWT wake-up duration. The second access point of claim 3 .

5. the first frame includes identity information of the second access point; The second access point of claim 1 .

6. the first frame and the second frame are public action frames; The second access point of claim 1 .

7. the first frame and the second frame are new action frames; The second access point of claim 1 .

8. The first SP is a cooperative TWT SP. The second access point of claim 1 .

9. the first frame includes one or more first fields; the one or more first fields include a target wake time field, a TWT wake interval mantissa field, and a nominal minimum TWT wake duration field for the first SP; The second access point of claim 1 .

10. the one or more stations are unaware of the existence of the first SP; The second access point of claim 1 .

11. the second frame conveys identity information of access points involved in the collaboration of the first SP; The second access point of claim 1 .

12. 1. A communication method for a second access point, comprising: receiving a first frame from a first access point initiating negotiation of a first service period (SP); transmitting a second frame to the first access point in response to the first frame; transmitting a third frame to one or more stations associated with the second access point, the third frame advertising information about the first SP; A communication method, including:

13. an integrated circuit for a second access point, comprising: receiving a first frame from a first access point initiating negotiation of a first service period (SP); transmitting a second frame to the first access point in response to the first frame; transmitting a third frame to one or more stations associated with the second access point, the third frame advertising information about the first SP; An integrated circuit that controls

Images