Communication device and communication method corresponding to a coordination service period
The communication device and method negotiate and manage cooperative SPs between APs to synchronize station states and protect priority traffic, addressing the lack of SP discussion in IEEE 802.11be, thereby enhancing network throughput and reducing interference.
Patent Information
- Application Number
- JP2023536107
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-15
- Filing Date
- 2021-03-10
- Publication Date
- 2025-07-01
- Estimated Expiration
- 2041-03-10
AI Technical Summary
The existing wireless local area network (WLAN) standards, such as IEEE 802.11be, do not discuss cooperative service periods (SPs) for multi-AP cooperation, which is necessary for ensuring simultaneous active states of stations across different BSSs and protecting priority traffic from overlapping BSS interference.
A communication device and method that facilitates the negotiation and management of cooperative service periods (SPs) between access points (APs) to ensure synchronized active states of stations and protect priority traffic by coordinating transmission methods like C-OFDMA, C-TDMA, C-SR, and C-MU-MIMO, using request frames and frames like Beacon, Action, and TWT Setup frames to manage SPs.
Ensures simultaneous active states of stations across different BSSs and effectively protects priority traffic from overlapping BSS interference, enhancing network throughput and reducing interference for vulnerable stations.
Smart Images

Figure 0007701450000001 
Figure 0007701450000002 
Figure 0007701450000003
Abstract
Description
Technical Field
[0001] This embodiment generally relates to a communication device, and more particularly, to a method and apparatus for supporting service periods (SP).
Background Art
[0002] In the standardization of next-generation wireless local area networks (LANs), a new wireless access technology with backward compatibility with IEEE 802.11a / b / g / n / ac / ax technologies is being studied in the IEEE 802.11be task group.
[0003] In 11ax high efficiency (HE) WLANs, the transmission of multiple frames during a transmission opportunity (TXOP) is supported, and a station (STA) can transmit additional frames in its transmission queue. In 11be extremely high throughput (EHT) WLANs, for the purpose of improving throughput beyond 11ax HE WLANs, especially for cell-edge STAs, coordinated transmission 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 a multi-AP system has been proposed to be enabled.
[0004] In IEEE 802.11be, various multi-AP cooperation methods are being considered. In time-domain cooperation scheduling, an access point (AP) adjusts its own transmission timing. In cooperative spatial reuse (SR), the AP adjusts its own transmission power. In C-OFDMA, the AP adjusts the allocation of resource units (RUs). In cooperative beamforming (BF), the AP adjusts the BF. In cooperative multi-user multiple-input multiple-output (MU-MIMO) (also called joint transmission), the AP adjusts its own MU-MIMO transmission.
Prior Art Documents
Patent Documents
[0005]
Patent Document 1
Summary of the Invention
Problems 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 device and a communication method that can solve the above-mentioned problems. Furthermore, other desirable features and characteristics will become apparent from the following detailed description and the appended claims, which are to be considered in conjunction with the accompanying drawings and the background section of the present disclosure.
Means for Solving the Problems
[0008] Non-limiting and exemplary embodiments facilitate the provision of a communication device and a communication method corresponding to the cooperative SP.
[0009] According to one aspect of the present disclosure, there is provided a first access point (AP) comprising: a circuit that generates a request frame indicating a request to set up one or more cooperative service periods (SPs) during operation; and a transmitter that transmits the request frame to a second AP during operation.
[0010] According to another aspect of the present disclosure, there is provided a non-access point (AP) STA comprising: a receiver that receives either a Beacon frame or an Action frame from an AP associated with the non-AP STA during operation; a circuit that extracts information on an SP for cooperative transmission from the frame during operation; and a transmitter that transmits a request frame to the AP during operation, the request frame indicating a request to participate in the SP.
[0011] According to another aspect of the present disclosure, there is provided a method comprising: generating a request frame indicating a request to set up one or more cooperative SPs; and transmitting the request frame to an AP.
[0012] Note that a general or specific embodiment may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any optional combination thereof. Further benefits and advantages of the disclosed embodiments will become apparent from the present specification and the drawings. These benefits and / or advantages can be obtained individually by various embodiments and features of the present specification and the drawings, and it is not necessary to provide all of these features in order to obtain one or more of such benefits and / or advantages.
Brief Description of the Drawings
[0013] The accompanying drawings are incorporated herein and form a part of this specification together with the following detailed description, illustrate various embodiments, and serve to explain various principles and advantages according to the present embodiment. Throughout the individual drawings, like reference numerals refer to the same or functionally similar elements.
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
Figure 33
Figure 34
Figure 35
[0014] It will be understood by those skilled in the art that the elements in the figures are illustrated in a concise and clear manner and are not necessarily 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. Further, it is not intended to be bound by the theory presented in the previous background art or detailed description sections of the invention. Moreover, other desirable features and characteristics will become apparent from the following detailed description and the appended claims in conjunction with the accompanying drawings and the background of the present disclosure.
[0016] In 802.11be, shared transmitter opportunity (TXOP)-based multi-AP cooperation is recognized, in which case the APs perform cooperative transmission within the shared TXOP. Examples include shared TXOP-based C-OFDMA / C-time division multiple access (C-TDMA), and shared TXOP-based C-SR.
[0017] Patent Document 1 describes a mechanism for protecting 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, FIG. 1 shows a flow diagram 100 that illustrates communication using an extended service period for prioritized traffic, according to one example. Contention-based channel access procedures, such as enhanced distributed channel access (EDCA) procedures, are shown by blocks 108, 110, 114, 118, 122, 124, 132, 134. For simplicity, acknowledgment frames (e.g., ACK frames, BlockAck frames) are not explicitly shown but will be understood to be present if needed. The AP 102 can transmit a Beacon frame 109 to advertise the presence of extended TWT SPs 121, 129, where only low latency traffic is permitted. STAs such as STA1 104 that need to access the channel during the extended TWT SPs 121, 129 can then negotiate membership in the extended TWT SPs 121, 129 with the AP 102 through the exchange of TWT request / response frames. In particular, during the TWT negotiation phase 112, STA1 104 can transmit a TWT request frame to the AP 102 requesting membership in the extended TWT SPs 121, 129, and the AP 102 can then transmit a TWT response frame granting membership to STA1 104. 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 alternative configuration. The first target beacon transmission time (TBTT) 116 can also be negotiated during the negotiation phase 112. Thus, STA1 is permitted at this point to access the channel during the extended TWT SPs 121, 129 to exchange low latency traffic.The Broadcast TWT ID field of the TWT element included in the TWT request frame or the TWT response frame is set to a value other than 0 (e.g., 1) to indicate a broadcast TWT.
[0019] STA1 can transition to the doze state and, after the first TBTT 116, wake up to receive the Beacon frame 119 from the AP 102. The Beacon frame 119 can include a broadcast TWT element that includes additional 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 by the dashed square of the extended TWT SP 121, 129). The TWT element can further indicate that it is an extended TWT and that only low-latency traffic is permitted to be transmitted during this TWT SP.
[0020] After receiving the Beacon frame 119, STA1 can transition to the sleep state and wake up for the broadcast TWT1 SP 121. Since STA1 is a member of the TWT SP and has low-latency (L.L.) traffic to transmit, the STA that wakes up for the extended TWT SP does not set its own 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 (L.L.DL) signal 123 and a low-latency uplink (L.L.UL) signal 125, respectively.
[0021] After the completion of the first extended TWT SP 121, STA1 104 can transition to the sleep state. According to the TWT wake-up interval 130 specified either in the negotiation phase or in the Beacon frame 119, STA1 104 can wake up for the next broadcast TWT1 SP 129. During this second extended TWT SP 129, AP 102 and STA1 104 each transmit an L.L.DL PPDU 133 and an L.L.UL PPDU 135 respectively.
[0022] On the other hand, a third-party STA such as STA2 106 that has not negotiated membership with AP 102 and thus is not a member of the extended TWT SP is not permitted to access the channel during the extended TWT SPs 121 and 129, as shown by the dashed rectangles 126 and 136. This can be achieved by STA2 checking whether it is a member of the extended TWT SP when it wakes up for the extended TWT SPs 121 and 129 and setting its NAV for the duration of the TWT SP since it is not a member. During the TWT SP, since the transmission of traffic types with traffic identifiers (TIDs) other than those permitted by the TWT SP is restricted, the extended TWP SP is sometimes referred to as a restricted TWT SP. For the purpose of further restricting the transmission by legacy STAs during the extended TWT SP, the AP can further transmit a quiet element / quiet channel element to schedule a quiet interval that overlaps with the extended TWT SP. For non-AP legacy STAs, channel control is lost at the start of the quiet interval, and all non-AP legacy STAs within the BSS set their NAV for the length of the quiet interval established by the quiet element / quiet channel element, thereby restricting non-AP legacy STAs from transmitting during the extended SP.
[0023] However, protection from overlapping BSS (OBSS) traffic where adjacent BSSs operate on the same channel is not considered.
[0024] In a multi-AP cooperative transmission scheme, particularly a shared TXOP-based scheme, it is necessary for the target STAs of different BSSs to be in the active mode or awake state simultaneously. This may not always be possible, especially when the STA operates in the power save mode. Thus, the problem is how to ensure that the STAs of different BSSs participating in the cooperative transmission are in the active mode or awake state simultaneously. Further, another problem to be solved is how to protect the priority traffic (e.g., low latency traffic or NSEP traffic) within the extended TWT by restricting channel access from the OBSS (from the unspecified traffic).
[0025] Referring to FIG. 2, the AP can negotiate a period (cooperative service period) during which it agrees to perform multi-AP cooperative transmission. For example, the negotiation of the cooperative SP between AP1 and AP2 is carried out in the SP negotiation 202. Such a cooperative SP for multi-AP cooperative transmission can include periodically repeated SPs such as the cooperative SP 206 and the cooperative SP 208, and the shared-side AP (the AP that has acquired the shared TXOP) determines the actual multi-AP cooperative scheme used within each cooperative SP. Each AP determines the target STA(s) for transmission between cooperative SPs from the STAs associated with itself based on the actual multi-AP cooperative scheme used within each cooperative SP.
[0026] At 204, the STA negotiates with the associated AP for the scheduled SP (BSS specific), or in some cases, the STA may have already negotiated with the associated AP for the scheduled SP before the 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 STA to the scheduled SPs 210 and 212 so that the scheduled SP of the STA overlaps with the cooperative SP, and ensures that the STA is awake during each cooperative transmission. The AP can further exchange the next TBTT and beacon interval information 214 to ensure that the cooperative SP does not overlap with the AP's TBTT.
[0027] As used herein, the scheduled SP means the SP existing between the STA and the associated AP, and can be any SP for which the STA and the associated AP have negotiated one or more periods for frame exchange in advance. The STA is expected to be in the awake state or active mode during SPs such as S-APSD (Scheduled Automatic Power Save Delivery) SP, scheduled PSMP (Power Save Multi-poll) SP, TWT (Target Wake Time) SP, QTP (Quiet Time Period) SP, etc. The negotiation of the cooperative service period can be performed between two APs at a time. However, if there is a static shared AP / shared AP hierarchy, multiple shared APs can negotiate the cooperative SP with the same shared AP, and multiple shared APs may be assigned to the same cooperative SP (by the shared AP). Otherwise, each cooperative SP can only be between two APs. The shared AP means an AP that shares its transmission opportunity (TXOP) with another AP (shared AP).
[0028] The AP can negotiate the following parameters for the cooperative SP. - Start time of the first SP: The time when the first cooperative SP occurs - SP duration: The duration of each cooperative SP - SP interval: The time interval between two consecutive cooperative SPs - Number of cooperative SPs: If greater than 1, this parameter indicates the total number of cooperative SPs that are periodically repeated. For example, if the cooperative SPs are persistent and occur periodically throughout the duration of the multi-AP cooperation, or if the cooperative SPs are not explicitly terminated, this parameter may not be necessary.
[0029] - Optionally include in the Setup frame the characteristics of the traffic (data rate, burst size, delay bound, etc.) expected to be exchanged between SPs.
[0030] The AP can also request to allocate a specific sub - part of the SP to itself, or alternatively, exchange information regarding their timing synchronization functions (TSF: timing synchronization function), the next TBTT, and the beacon interval (BI) so that the cooperative SPs do not overlap with the beacon transmission time of any AP. When the cooperative SPs are negotiated between APs, within each BSS, the selected STAs (i.e., the vulnerable STAs expected to participate in the cooperative transmission) are assigned to the scheduled SPs (such as S - APSD SP, TWT SP, etc.) that overlap with the cooperative SPs. The STAs do not need to be aware of the cooperative SPs. Advantageously, by not only being aware of the cooperative SPs but also recognizing the identities of the STAs participating in the cooperative transmission, 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 STA benefits the most depends on the multi-AP cooperation method. The STA that can benefit the most from cooperative OFDMA should be identified before cooperative transmission. That is, in the case of C-OFDMA / C-TDMA, it is the STA within the transmission range of multiple APs, and in the case of C-SR / C-BF, it is the STA with a greater distance 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 the most from C-SR / C-BF because these STAs are far apart from each other, and even if they transmit simultaneously, high interference does not occur between them. 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, in order to avoid mutual interference, the transmissions to these two STAs should not overlap in the frequency domain and / or time domain.
[0032] The AP can collect reports (e.g., interference measurement reports) from the associated STAs to identify vulnerable STAs. Generally, STAs operate in power-saving mode to save power, and each STA determines its own awake period (duty cycle). It is desirable to synchronize the awake states of such STAs between OBSSs.
[0033] Not all cell-edge STAs are equally affected by OBSS interference. Rarely, even a cell-center STA may be subject to significant interference from an OBSS. The AP can attempt to protect such an STA from OBSS interference by "reserving" a frequency unit (RU) for the vulnerable STAs within its BSS and informing the OBSS AP of that RU. If all OBSS APs adjust their transmissions so as not to transmit simultaneously on the reserved RUs of adjacent APs, interference to the vulnerable STAs can be significantly avoided. The AP reserves the RU only for STAs that require protection from OBSS, such as vulnerable STAs. A subset of the RUs can be referred to as the "Reserved RU set" or "Protected RU set". The AP can use reports from STAs associated with itself to identify the affected STAs and further determine the RUs for the "Reserved RU set". For example, referring to FIG. 4, AP2 can use the bandwidth query report (BQR) or interference report from the STA to identify STA3 as a "vulnerable STA" and further select a reserved RU set for STA3. For the remaining STAs such as STA1 in FIG. 4, there may be no restrictions on RU selection. The interference report from the STA can also identify the interfering OBSS STA on the interference side, i.e., STA2 can be identified as the interfering STA by STA3. Therefore, both STA2 and STA3 can be identified as vulnerable STAs. The AP advertises the reserved RU set to other APs (either by broadcasting in the beacon or through the AP-to-AP link). Optionally, the AP can also report the interfering OBSS STA on the interference side.
[0034] When selecting its own reserved RU set, the adjusting AP also takes into account the reserved RU sets of adjacent BSSs. The reserved RU set is selected such that the overlap with the reserved RU sets of adjacent BSSs is minimized. The RUs for the STAs reported as interfering STAs on the interference side are also restricted to the reserved RU set.
[0035] For the purpose of requesting interference measurement (by the AP) and reporting interference measurement (by the STA), an EHT Action frame can be defined. Referring to FIG. 5, an EHT Interference Measurement Request frame 502 can be used by the AP to request interference measurement, and an EHT Interference Measurement Report frame 504 can be used by the STA to report interference measurement. 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 UL from a non-AP STA, or can indicate the STA MAC address retrieved from the RA (receiver address) field of the interfering frame if the interference is from DL to a non-AP STA. The Interfering BSSID subfield 508 can indicate the BSSID retrieved from the BSSID field (normally the Address field 3) of the interfering frame.
[0036] Instead of broadcasting, the AP can directly send a consolidated cell-edge RU set or a reserved RU set as an Action frame or encapsulate it in a data frame (e.g., as an Ethertype 89-0d frame) and send it to another AP through the AP-to-AP link. A new AP Coordination Session Action frame 600 as shown in FIG. 6 can be defined to convey the 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 for the AP Coordination Session Action field, and this value 6 indicates that the AP Coordination Session Action frame 600 is a frame for AP coordination reserved RUs. Further, the List of Interfering STAs field 606 can list interfering STAs belonging to the BSS, MAC address, or associated identifier (AID) of the target AP. The information of the reserved RUs is considered valid until the next "AP Coordination Reserved RU" frame is sent. The AP can send the reserved RU set to other APs spontaneously, or the transmission can also be a response to a request from another AP.
[0037] In the example of the coordinated transmission sequence shown in FIG. 7, BSS1 and BSS2 can have different operating channels (having the same bandwidth but different start frequencies and primary channels), provided that the operating channels overlap at CH3 and CH4. The reserved RU set of BSS2 is assigned to CH5 and CH6, and the reserved RU set of BSS1 is assigned to CH1 and CH2. In BSS2, UL MU PPDU transmission is being performed, and the RUs used for DL transmission to the vulnerable STA are in CH5 and CH6. The AP of BSS1 can solicit uplink transmission by transmitting a TF frame that assigns the RUs in CH1 and CH2 to the vulnerable STA. The vulnerable STA of BSS1 can then transmit a UL PPDU on the assigned RUs in CH1 and CH2. The non-overlapping of the reserved RU sets for the vulnerable STA helps to minimize inter-BSS interference while promoting spatial reuse.
[0038] Another example of a coordinated transmission sequence is shown in FIG. 8. In a multi-AP network where transmissions by multiple APs are tightly coordinated by, for example, a multi-AP coordinator (AP2 in FIG. 8), both the transmission timing and the RUs used for transmission to the vulnerable STA can be determined by the multi-AP coordinator. AP2 transmits a multi-AP Trigger frame 802 to another AP (AP1) to initiate coordinated uplink transmission. The multi-AP Trigger frame 802 instructs AP1 to start UL transmission from STA2 and further assigns RU1 used for UL transmission from STA2.
[0039] After the interval of SIFS (Short Interframe Space), both AP2 and AP1 transmit the Basic Trigger frame 804. AP2 allocates RU2 for the UL transmission from STA3, and AP1 allocates RU1 for the UL transmission from STA2. After the interval of SIFS, STA3 and STA2 transmit UL PPDUs 806 on RU2 and RU1 respectively, thereby avoiding mutual interference. After the interval of SIFS, AP2 and AP1 transmit BlockAck frames 808 on RU2 and RU1 respectively. With this transmission sequence, the AP can dynamically adjust the RU allocation to the 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. An individual TWT agreement can be negotiated as a cooperative SP 902 between APs. 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 the shared-side AP. Further, an AP can send an unsolicited TWT setup response 906 to schedule another AP to participate in 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. When the cooperative TWT SP is negotiated, each AP can negotiate a new scheduled SP 904 with the vulnerable STA or renegotiate the existing schedule so that the scheduled SP 904 overlaps with the cooperative SP 902. The scheduled SP 904 of a STA can be any SP in which the STA and the associated AP have previously negotiated one or more periods for frame exchange and in which the STA is expected to be in an awake state or active mode during the SP, for example, an S-APSD (Scheduled Automatic Power Save Delivery) SP, a scheduled PSMP (Power Save Multipole) SP, a TWT (Target Wake Time) SP, a QTP (Quiet Time Period) SP. In FIG. 9, it is shown that the STA negotiates the scheduled SP with each associated AP simultaneously, but in practice, the negotiation may occur at different times, and some STAs may have already negotiated the scheduled SP before the AP sets up the cooperative SP.Within each coordinated SP, the shared AP determines the multi-AP coordination method to be used. For example, in the first coordinated SP 902, the shared AP, AP1, determines to use C-OFDMA, shares the upper half of the operating bandwidth with AP2. Thus, AP1 and AP2 transmit to STA1-1 and STA2-1 on non-overlapping frequency channels (or RUs) among the first coordinated SPs, while AP3 does not participate in the multi-AP coordinated transmission. In the second coordinated SP, the shared AP, AP1, determines to use C-TDMA, and allocates sub-sections of its TXOP to AP2 and AP3. Thus, among the second coordinated SPs, AP1, AP2, and AP3 transmit to their respective associated STAs, STA1-1, STA2-1, and STA3-1, without their transmissions overlapping with each other.
[0041] The TWT Setup frame can be customized for multi-AP coordination. FIG. 10 shows an example of a TWT Setup frame 1000 for TWT requests / responses used to set up a coordinated SP. The Address 1 (or A1) field 1002 can indicate the MAC address of the target AP. The Address 2 (or A2) field 1004 can indicate the MAC address of the requesting-side AP. The Address 3 (or A3) field 1006 can be set to a special value (i.e., the virtual BSSID of the AP candidate set) if it exists, or to the MAC address of the target AP if it does not exist. Since the TWT Setup frame is not a public Action frame, by default, the AP rejects such frames from STAs not associated with the AP. Thus, the A3 field 1006 can be set to a special value (i.e., the virtual BSSID) that is known to all APs within the AP candidate set. A TWT Setup frame with the A3 field set as a special value is accepted by the APs within the AP candidate set. The AP can perform further filtering based on the TA, such as accepting only frames from other APs within the set if an AP candidate set exists, for example. Alternatively, the BSSID can be set to the BSSID of the receiving-side AP, and the receiving-side AP accepts the frame if the TA matches the MAC address of any of the APs within the AP candidate set. The AP candidate set is a set of APs that have agreed to participate in multi-AP coordinated transmission as a shared-side AP (an AP that shares the acquired TXOP with another AP) or a shared-with AP (the recipient of the shared TXOP) by performing basic negotiation and capability exchange. In the present disclosure, it is assumed that all participating APs are members of the AP candidate set. The AP is assumed to have completed the negotiation to form the AP candidate set.
[0042] Since the timing synchronization function (TSF) of the AP is likely to be unsynchronized, for the purpose of assisting the responding AP in correctly calculating the requested target wake time, the TSF Offset / TSF Value field 1008 can indicate either the difference in TSF between the two participating requesting APs and the receiving AP, or the value of the TSF of the requesting AP at the time of transmission. Further, the AP also considers each other's TBTT and BI when determining the actual start time / duration of the cooperative SP. The Member AP List field 1010 of the TWT Setup Response frame can convey a list of the MAC addresses of other APs assigned to the same cooperative TWT SP. Further, the spare bits of the TWT element field 1012 (the Multi-AP Coordinated TWT subfield 1014) can be used to explicitly indicate that the TWT element field 1012 is targeted at the cooperative SP.
[0043] In the exemplary transmission shown in FIG. 11, the scheduled SP for the STA may be a TWT, for example, a trigger-based TWT SP. The scheduled SP for the STA can start a little earlier than the cooperative SP so that the AP can check whether the STA is awake and the status of the STA's buffer. The shared AP can pass this information to the sharing-side AP (e.g., at the start of the shared TXOP), and the sharing-side AP can use this information to determine which shared AP(s) to share the TXOP with. For example, at the start of the scheduled SP, each AP, i.e., AP1, AP2, and AP3, can optionally collect information about the associated STAs within its BSS, which is by sending a Buffer Status Report Poll Trigger frame (BSRP TF) 1102 to each associated STA and having each STA respond by sending the requested information to the associated AP. Next, the sharing-side AP1 can 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 about their respective associated STAs. Thereafter, AP2 and AP3 can each send a MAP BSR frame 1106 to AP1 in the OFDMA mode to report the buffer status (both UL and DL) of their identified or associated STAs. For example, based on the reports, since the traffic buffered in AP3 is much less than the traffic buffered in AP2, AP1 decides to share the TXOP with AP2 and thus sends a MAP TF 1108 to AP2, indicating that AP1 intends to share the TXOP with AP2 and the relevant transmission parameters such as the RUs assigned to AP2, the transmission period, the MCS, and the TX power.After the SIFS following MAP TF 1108, AP1 and AP2 start coordinated transmission, and transmit DL PPDUs to STA1-1 and STA2-1 respectively in the OFDMA mode. Subsequently, each STA sends back a confirmation response frame (e.g., BlockAck frame) to the associated AP. The MAP BSR frame 1106 also serves the purpose of protecting the coordinated transmission by setting the NAV of all STAs within the transmission range of AP1.
[0044] Ethertype 89-0d data frames such as the data frame 1200 in FIG. 12 can be used as MAP-BSR frames (such as the MAP BSR frame 1106) for the purpose of sharing buffer state reports between APs. For example, the UL / DL field 1202 can indicate whether the report is related to the DL buffer or the UL buffer. The Queue Size field 1204 can indicate an estimate of the total buffer size at the AP (in the case of DL) / associated vulnerable STA (in the case of UL) (the same encoding as 11ax can be used).
[0045] Furthermore, as shown in FIG. 13, an AP or STA can use the EHT capability element 1300 to indicate its supported functions. For example, the EHT MAC capabilities field 1302 can include an enhanced TWT (Enhanced TWT) field 1304 that can indicate whether enhanced TWT is supported. The 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 that can be used to indicate whether a multi-AP transmission method is supported. Furthermore, the EHT multi-AP capabilities field 1306 can include a coordinated SP (Coordinated SP) field 1308 that can indicate whether the participating APs support coordinated SP, and an SP information solicitation (SP Information Solicitation) field 1310 that can indicate whether the participating APs support solicitation of information regarding SP.
[0046] (For setting up coordinated SP) The TWT Setup frame can also be transmitted within an Ethertype 89-0d data frame such as the 802.11 data frame 1400 in FIG. 14. For example, the data frame 1400 can include one or more TWT element (TWT Element) fields 1402 that contain information for setting up coordinated SP, and a sub-type field 1404 that indicates that the data frame 1400 is for TWT setup.
[0047] In various embodiments, the cooperative SP can specify a multi-AP cooperation scheme (C-OFDMA / C-TDMA, C-SR / C-BF, joint transmission, etc.) or the traffic types permitted within the SP. For example, referring to FIG. 15, the cooperative SP1 1502 can be a cooperative SP for C-OFDMA / TDMA transmission, and the cooperative SP2 1504 can be a cooperative SP for C-SR / C-BF transmission. In this case, the STA can be assigned to a scheduled SP (unique to the BSS) within the cooperative SP suitable for the STA, and it is guaranteed that the STA is awake during the appropriate cooperative transmission. Advantageously, this enables the STA to obtain more power-saving gains and avoid unnecessary wake-up 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 subchannels for C-OFDMA, and the responding AP can specify the 20 MHz subchannels assigned to the requesting AP for C-OFDMA. Similarly, the requesting AP can further specify its desired sub-time slots within the SP for C-TDMA or for priority traffic, and the responding AP can specify the sub-time slots assigned to the requesting AP. The AP can further protect sensitive traffic (e.g., low-latency traffic / NSEP traffic) from its associated STAs during the sub-time slots by transmitting a quiet element(s) or a quiet channel element(s) in the Beacon / Probe Response frame so that the BSS channel is quiet during the sub-time slots.
[0049] New public Action frames, such as the Coordinated SP Request Action frame 1600 in FIG. 16 and the Coordinated SP Response Action frame 1800 in FIG. 18, can be used to negotiate the coordinated SP. For example, the Coordinated SP Request frame 1600 can include a Schedule Element field 1602 that can indicate the requested SP parameters. The Schedule Element field 1602 can further include a Schedule Info field 1604, which can indicate the value of the coordinated SP type with reference to the table 1700 in 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. Further, the Coordinated SP Response frame 1800 can include a Status field 1802 that can indicate whether the request is accepted or rejected. This frame can further include a Schedule Element field 1804 that can indicate the agreed-upon SP parameters for the coordinated SP.
[0050] In one example, the Baseline Schedule element can be reused (IEEE 802.11-2020's 9.4.2.33 Schedule element) to negotiate the cooperative SP. For example, the Service Start Time field of the Baseline Schedule element indicates the expected time when the service starts in microseconds and represents the lower 4 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 measured time from the start of one SP to the start of the next SP. Further, some reserved bits of the Schedule Info field can be used to indicate the cooperative SP type information, i.e., the multi-AP cooperation method executed within the cooperative SP. The Specification Interval field can be reused for the purpose of conveying the number of cooperative SPs in the case of periodically repeated cooperative SPs.
[0051] Alternatively, the coordinated SP can be negotiated using the TWT Setup frame. Referring to the exemplary TWT Setup frame 1900 of FIG. 19 that can be used for TWT requests and TWT responses to set up the multi-AP coordinated TWT SP, the TWT Setup frame 1900 can include one or more TWT Element fields 1902, and the TWT Element field 1902 includes a Coordinated SP Type field 1904 for specifying the multi-AP coordination mode and / or the permitted traffic type. For example, the Coordinated SP Type field 1904 can indicate the value of the coordinated SP type based on the table 1700 of FIG. 17 for indicating the coordinated SP type. Further, the TWT Setup frame 1900 can include an eTSPEC field 1906 that can indicate the traffic characteristics. For example, if the Coordinated SP Type field 1904 indicates a specific traffic type, further characteristics of the traffic can be indicated in the eTSPEC field 1906.
[0052] To negotiate the TWT within the BSS, the TWT channel field (such as TWT Channel field 1908) and the extended TWT channel field (such as Extended TWT Channel field 1910) of the TWT Element in 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) required for the HE / EHT STA within the primary 160 MHz. The extended TWT channel can be used to convey the secondary channel(s) required for the EHT STA within the secondary 160 MHz. One bit set to 1 indicates a 20 MHz channel for a STA operating at 20 MHz, and the four least significant bits (LSB) or four most significant bits (MSB) all set to 1 indicate the first or second 80 MHz channel within the secondary 160 MHz.
[0053] In the TWT negotiation for the C-OFDMA MAP coordination SP, the TWT channel field and the extended TWT channel field in the TWT Element of the TWT Setup frame are used together to convey the desired / assigned subchannels of the requesting side AP during C-OFDMA MAP transmission. The TWT Channel is used to convey the secondary channel(s) required for the AP within the primary 160 MHz, and each bit represents one 20 MHz subchannel. The Extended TWT Channel is used to convey the secondary channel(s) required for the AP within the secondary 160 MHz, and each bit represents one 20 MHz subchannel.
[0054] The AP can also request a sub-SP (i.e., a specific time slot) within the cooperative SP. A sub-SP can represent a smaller period for which the requesting AP requires guaranteed channel access (e.g., for jitter-sensitive low-latency traffic). Referring to FIG. 20, in the case of TWT negotiation for a C-TDMA MAP cooperative SP, or in the case of TWT negotiation for a cooperative SP for priority traffic, the TWT Setup frame (i.e., the TWT Element 2000 in FIG. 20, etc.) can further convey information related to the desired / assigned sub-SP for the requesting AP during C-OFDMA MAP transmission (within the cooperative SP). - When 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 / assigned sub-SP. - The Sub-SP Intervals field 2008 indicates the time interval between consecutive sub-SPs, if the sub-SPs are also periodic.
[0055] In 11be, when it is determined that coexistence of C-OFDMA transmission and C-TDMA transmission within the same MAP shared TXOP is not permitted, when the cooperative SP type is C-TDMA, or when the cooperative SP type is reserved for priority traffic, it is also possible to reuse the TWT Channel field and the Extended TWT Channel field as the Sub-SP Start Offset field and the Sub-SP Duration field.
[0056] Figure 21 shows an exemplary diagram 2100 of a cooperative SP for C-TDMA. In this example, all STAs have low-latency traffic, and the type of cooperative SP negotiated is low-latency. When negotiating a cooperative SP with AP1, AP2 and AP3 can also indicate subsections of the cooperative SP (such as sub-SP 2104, referred to as sub-SPs), and between these sub-SPs, AP2 and AP3 need to provide quasi-guaranteed channel access to a specific traffic type (e.g., low-latency traffic that is highly affected by jitter). If the sub-SPs of the member APs of the cooperative SP do not overlap, during the shared TXOP, the shared-side AP can adopt C-TDMA transmission and do its best to provide the shared TXOP to each member AP between their respective required sub-SPs. Each AP uses the assigned sub-SP 2104 to communicate with its associated STAs. The shared-side AP, AP1, can reclaim the unused portion of the TXOP for transmission to the STAs associated with itself (e.g., for the transmission of DL-PPDU 2102).
[0057] When the sub-SPs of the member APs of the coordinating SP overlap with each other, during the shared TXOP, the sharing AP may not be able to properly share the TXOP using only C-TDMA. In such a case, the sharing AP can adopt a transmission that mixes C-TDMA and C-OFDMA, doing its best to provide the shared TXOP to each member AP among the respective required sub-SPs, and at the same time ensuring that different sub-channels are allocated to the member APs at least among the sub-SPs. For example, referring to the exemplary diagram 2200 of C-TDMA + C-OFDMA in FIG. 22, the sharing AP, AP1, during the first part of the shared TXOP, uses the entire bandwidth to perform transmissions between the STAs associated with itself via the C-TDMA part 2204, and allocates the second part of the shared TXOP to the other member APs of the coordinating SP. For example, the sharing AP, AP1, can transmit the MAP TF 2202 to the shared APs, AP2 and AP3, to signal the C-TDMA parameters for the C-TDMA part 2204. During the second part of the TXOP, the sharing AP can further adopt C-OFDMA, share the TXOP with the member APs, and allocate non-overlapping sub-channels to each member AP. To achieve this, the sharing AP can transmit the second MAP TF 2206 at the end of its own C-TDMA part 2204 of the TXOP to allocate sub-channels to the member APs during the C-OFDMA part 2208 of the shared TXOP, that is, allocate the secondary 160 MHz channel to AP2 and the primary 160 MHz channel to AP3 (assuming that the operating channel of all APs is 320 MHz). Alternatively, if sub-channels have already been allocated during the negotiation 2210 of the coordinating SP (for example, using the TWT Channel field and the TWT Extended Channel field of the TWT element), since each AP already recognizes its own allocated sub-channel, the second MAP TF 2206 for C-OFDMA can be skipped.Each of the shared APs, i.e., AP2 and AP3, communicates with its associated STAs using its assigned channels within the sub-SP. Further, the shared AP can use the unused portion of the TXOP (either in the time domain or the frequency domain) based on its convenience to transmit to the STAs associated with itself. In this example, all STAs have low-latency traffic and the negotiated cooperative SP type is low-latency.
[0058] In one embodiment, each AP can also advertise the cooperative SP to the STAs within the BSS, i.e., the AP can overlay the broadcast TWT SP on top of the cooperative SP and advertise them via the TWT element of the Beacon frame. For example, referring to the transmission diagram 2300 of FIG. 23, AP1 and AP2 can set up a broadcast TWT SP that overlaps with the cooperative SP using the Beacon frame 2302. For example, a set of extended TWT SPs that overlap with cooperative SP1 (the broadcast TWT SP of ID1) and another set of extended TWT SPs that overlap with cooperative SP 2 (the broadcast TWT SP of ID2) can be set up. In this example, the AP may not need to identify the type of STAs. Instead, the STAs can negotiate in the transmission portion 2304 to participate in the broadcast TWT SP of interest. The STAs do not need to be aware of the existence of the overlapping cooperative SP. Therefore, the AP does not need to identify and micro-manage the STAs because the STAs can sign up for the SP of interest. For example, STAs 1-1 and 2-1 that have low-latency traffic to transmit can negotiate to participate in the extended TWT SP (with the broadcast TWT ID1), and STAs 1-2 and 2-2 that have NSEP traffic to transmit can negotiate to participate in the extended TWT SP (with the broadcast TWT ID2).
[0059] In one embodiment, the AP requests information on the scheduled SP for the associated STAs of the second AP from the second AP, and uses that information to schedule the SP for the STAs associated with itself, thereby reducing mutual contention between priority traffic among OBSSs. Referring to the transmission diagram 2400 in FIG. 24, the APs in the AP candidate set exchange information regarding the (existing and / or to-be-set-up) extended TWT SPs, and adjust their respective extended TWT SPs so that the TWT SPs do not overlap in the time domain / 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 with the extended TWT SPs of AP1 / AP3 in time / frequency.
[0060] The information exchange between APs may be through wireless (in-band) or through a backhaul link (wired / wireless) (out-of-band). The extended TWT can be as defined in Patent Document 1. The adjustment can be performed for any TWT SP, but adjusting the extended TWT can bring more benefits by ensuring that the priority traffic of OBSSs (e.g., low-latency traffic) does not compete for the channel simultaneously. This embodiment may be suitable for deployments where there is no strong relationship between APs (e.g., deployments other than enterprises) and where the APs do not intend to share TXOPs.
[0061] An AP can decode the Beacon frame of another AP, collect information on the broadcast extended SP (when present) of that other AP, and passively adjust its own extended SP to avoid overlap if necessary. However, since the individual TWT SP is not advertised in the Beacon frame, another AP may not recognize the individual TWT SP of an AP. An AP can also request information on the service periods of other APs (AP coordination SP, or the scheduled SPs of the APs' STAs (both broadcast and individual SPs)). For example, an AP can request the coordination SP information from another AP and use this information to request to participate in a coordination SP of interest. Alternatively, an AP can request the extended TWT SP information for prioritized traffic from another AP and adjust its own extended TWT for the prioritized SP as necessary so that the SPs of the two APs do not overlap. In a managed network (e.g., an enterprise deployment), such adjustment of SPs between APs can also be centrally managed, for example, by an AP controller(s). If there is a master / slave hierarchy between APs, the master AP can assist in the adjustment of SPs between APs.
[0062] Using either a data frame having a "Ethertype 89-0d" frame body like the data frame 2500 in FIG. 25, or a new public Action frame like the TWT SP Information Request / Response Action frame 2700 in FIG. 27, information on the service period(s) of an AP can be requested from or shared with other APs. Referring to the data frame 2500, the TWT SP Type field can indicate the value of the TWT SP type based on the table 2600 in FIG. 26. For example, a value of 0 for the TWT SP type indicates that the AP Coordination SP is an SP for C-OFDMA / C-TDMA, a value of 1 indicates that the AP Coordination SP is an SP for C-SR / C-BF, and so on. The data frame 2500 can 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 between the TWT SPs.
[0063] Referring to the TWT SP Information Request / Response frame 2700 in FIG. 27, the following fields are always conveyed in the TWT SP Information Response frame and can be conveyed optionally in the 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 conveys information about one TWT SP of the transmitting AP. Furthermore, the eTSPEC Element field 2706, which conveys information regarding the characteristics of traffic expected / allowed to be exchanged between TW TSPs, can be conveyed as an option in both frames.
[0064] In one embodiment, an AP can also request to participate in an existing scheduled SP of another AP (e.g., either an individual TWP SP or a broadcast TWP SP). Referring to the transmission diagram 2800 of FIG. 28, AP2 has set up a broadcast extended TWT SP (ID 2) 2802 for STAs associated with itself (e.g., for low-latency traffic). AP1 and AP3 passively listen to the Beacon frame of AP2 or exchange SP information request / response frames to collect information about the extended TWT SP for low latency of AP2. AP1 and AP3 request to participate in the broadcast TWT SP (ID 2) 2802 of AP2. During this TWT SP, AP2 recognizes that AP1 and AP3 are also members of the TWT SP and can share its TXOP with AP1 and AP3, for example, for C-TDMA transmission.
[0065] The AP can also indicate a desired subchannel or sub-SP in the TWT setup request. In this case, the first AP that requests to participate in the TWT SP is the TWT request-side STA (or the TWT scheduled STA), and the second AP that accepts the request is the TWT response-side STA (or the TWT scheduling STA). During this TWT SP, the second AP is expected to operate as the sharing-side 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 acquire access to the channel. In this example, there are the following four phases. - Phase 1 (SP Information Collection Phase): AP1 and AP3 collect information on the TWT SP (broadcast / individual TWT SP for associated STAs, or cooperative SP for other APs) provided by AP2. - Phase 2 (AP-AP SP Participation Phase): AP1 and AP3 request to participate in one of the broadcast extended TWT SPs of AP2 (e.g., an SP reserved for low latency traffic). AP1 and AP3 can also request sub-SPs within the TWT SP. - Phase 3 (In-BSS SP Request): If an in-BSS SP does not yet exist, AP1 and AP3 can set up an SP for each of their associated STAs that can benefit from MAP cooperative transmission such that the SP is located within the TWT SP of AP2 in which AP1 and AP3 participate. The in-BSS SP overlaps with the sub-SP if there is one requested by the AP. This can be achieved, for example, when a new TWT SP is set up, by the AP sending an unsolicited TWT setup response frame to the selected STA, 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 starts cooperative transmission (e.g., C-TDMA / C-OFDMA, etc.) between the TWT SPs and allocates time / frequency resources for AP1 and AP3, for example, within a shared TXOP.
[0066] Figure 29 shows a TWT Setup frame 2900 that can be used via an individual TWT setup to participate in an existing TWT SP of another AP. Since the TWT Setup frame is not a public Action frame, a special exception can be defined in the IEEE 802.11be specification so that an AP can accept a TWT Setup frame sent by another AP. Alternatively, a new public Action frame equivalent to the TWT Setup frame for AP-AP TWT setup can be defined. 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 that can indicate using a reserved bit that the TWT element is for AP-AP setup.The TWT Parameter Information field 2908 can include an Extended TWT Channel field 2910 that can convey the secondary channel(s) required within the secondary 160 MHz, a MAP Coordination type field 2912 that can indicate the MAP coordination transmission method that can be used between the TWT SP, a Sub-SP Non-Negotiable field 2914 that can indicate (if set) that the required sub-SP start time cannot be changed, a Sub-SP Start Offset field 2916 that can indicate the time offset from the SP start time to the start of the requested / assigned sub-SP, a Sub-SP Duration field 2918 that can indicate the duration of the requested or assigned sub-SP, and a Sub-SP Intervals field 2920 that can indicate the time interval between consecutive sub-SPs if the sub-SP is also periodic.
[0067] Alternatively, instead of the Action frame, the TWT Setup frame can also be encapsulated within an ethertype 89-0d data frame. In this way, there is no need to define 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. Thus, 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-side AP to indicate to the responding-side AP that the requesting-side AP requires a quasi-guaranteed period during which it should be able to access the channel with a very high probability. Such a request can be made, for example, for low-latency traffic that is highly affected by jitter. If the responding-side AP accepts the TWT request, it shall guarantee that the AP or its associated STA will 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 also indicate the actual (responding-side AP's) TSF at which the first sub-SP is requested to start.
[0069] Furthermore, the Sub-SP Duration field 2918 can indicate the duration of each sub-SP. The Sub-SP Intervals field 2920 can indicate the time interval between consecutive sub-SPs if the sub-SPs are periodic and multiple sub-SPs occur within the requested TWT SP.
[0070] The AP can thus use the TWT Setup frame 2900 to participate in the individual scheduled SPs of other APs of interest. Alternatively, it can also use a broadcast TWT setup to participate in the existing scheduled SPs of the AP. For example, the TWT Setup frame 3000 in FIG. 30 can be utilized in a manner similar to the method described for the TWT Setup frame 2900, enabling the AP to participate in the scheduled broadcast SPs of other APs of interest.
[0071] FIG. 31 shows an exemplary diagram 3100 illustrating the protection of sensitive traffic (e.g., jitter-sensitive low-latency traffic) using a sub-SP. The phases of this example are as follows. - Phase 1: STA2-2 has already negotiated a periodic TWT SP#20 for jitter-sensitive low-latency traffic with AP2. This SP has a short duration but occurs frequently. Since the traffic is highly affected by jitter, AP2 needs to ensure that the traffic of STA2-2 is preferentially handled during the SP. - Phase 2A: AP2 requests to participate in AP1's broadcast TWT#1 at 3102. - Phase 2B: AP2 requests to allocate a non-negotiable sub-SP 3104 within TWT#1. - Phase 3: At the start of TWT#1, since AP2 recognizes AP1's TWT SP#1, AP2 waits for the MAP TF 3106 from AP1. - Phase 4: Within the TWT SP, AP1 shares its TXOP with AP2 (e.g., using C-TDMA), so that AP2 can reliably obtain access to the medium for transmitting jitter-sensitive traffic during AP2's TWT#20 SP. Each AP can further protect the sub-SP by sending a quiet element / quiet channel element to its associated STAs so that the sub-SP overlaps with the quiet period, ensuring that a third-party STA does not transmit during the sub-SP. - Phase 5: AP2 transmits / receives sensitive traffic 3108 with its associated STAs during the TWT#20 SP that overlaps with AP1's TWT#1.
[0072] It can be understood that by adjusting the TWT SP between APs, the APs can effectively adjust their transmissions even within the acquired TXOP and reduce the adverse impact of OBSS transmissions on jitter-sensitive traffic.
[0073] In the exemplary diagram 3100, it is assumed that AP2 collects the information of the TWT SP of AP1 by passively listening to the Beacon frame of AP1 or by spontaneously requesting such information from AP1 using the SP information request / response frame. STA1-1 and STA2-1 are associated with AP1 and AP2 respectively. Since the TWT SP#1 of AP1 and the TWT SP#20 of AP2 can have different periods (determined by the TWT wake interval of each TWT agreement), the start time of the required sub-SP is not constant and may vary in 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 for the purpose of aligning the sub-SP with the TWT SP#20 of AP2. Alternatively, before all new instances of TWT SP#1, AP2 may notify AP1 of the correct start time of the requested sub-SP using, for example, the TWT information frame. AP1 and AP2 can further protect the jitter-sensitive traffic from the associated STAs of each AP by transmitting a quiet element(s) or a quiet channel element(s) in the Beacon / Probe response frame so that the BSS channel is quiet during non-negotiable sub-SPs.
[0074] FIG. 32 shows the configuration of a communication device 3200 according to various embodiments, such as a communication apparatus, such as a shared side AP or a shared AP. The communication device 3200 can include at least one antenna (wireless I / F module) 3202 for transmitting and receiving signals (only one antenna is shown in FIG. 32 for simplicity). This communication device can 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 can further include a MAC sublayer 3206 and a PHY sublayer 3204. The MAC sublayer 3206 includes a service period management module 3208, and the service period management module 3208 manages the service period for the associated STA and holds the records of all such SPs in the coordinated service period record 3210. The wireless I / F module 3212, the CPU 3214, at least one memory 3218, and at least one secondary storage device 3216 can function together as a circuit of the communication device 3200 configured to generate TWT request frames, response frames, Trigger frames, Multi-STA BlockAck frames, DL MU PPDUs, Beacon frames, DL PPDUs, frames including 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 the present disclosure. Then the antenna 3202 can transmit the generated frame(s) or PPDU(s) to other communication devices, such as STA(s).As described in this disclosure, antenna 3202 can receive, from other communication devices, i.e., STA(s), 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 coordinated and prioritized traffic (i.e., low latency traffic). Subsequently, the circuitry of communication device 3200 can be configured to process the received frame(s) or PPDU(s).
[0075] FIG. 33 shows the configuration of a communication device 3300 according to various embodiments, such as a communication apparatus, such as a non-AP STA. The communication device 3300 can include at least one antenna 3302 for transmitting and receiving signals (only one antenna is shown in FIG. 33 for simplicity). This communication device can 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 can further include a MAC sublayer 3306 and a PHY sublayer 3304. The MAC sublayer 3306 includes a service period subscription module 3308, and the service period subscription module 3308 manages the service periods that the communication device 3300 is a member of and holds records of all such SPs in the subscribed service period record 3310. The wireless I / F module 3312, the CPU 3314, at least one memory 3318, and at least one secondary storage device 3316, as circuits of the communication 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 coordinated and prioritized traffic (i.e., low latency traffic) as described in the present disclosure, can function together. The antenna 3302 can then transmit the generated frame(s) or PPDU(s) to other communication devices, such as an AP(s).As described in this disclosure, the antenna 3202 can receive, from other communication devices, i.e., one or more APs, 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. Subsequently, the circuitry of the communication device 3300 can be configured to process the received frame(s) or PPDU(s).
[0076] FIG. 34 shows a flowchart 3400 illustrating a communication method according to various embodiments. At step 3402, a frame indicating a request to set up one or more cooperative SPs is generated. At step 3404, the frame is transmitted to an AP.
[0077] FIG. 35 shows a partially framed schematic view of a communication device 3500 that can be implemented to correspond to a cooperative SP. The communication device 3500 can be implemented as a shared AP, a shared-by AP, or an associated STA according to various embodiments.
[0078] The various functions and operations of the communication device 3500 are arranged in each layer according to a hierarchical model. In this model, lower layers report to upper layers and receive instructions from upper layers according to IEEE specifications. For the sake of brevity of description, the details of the hierarchical model are not described in this disclosure.
[0079] As shown in FIG. 35, the communication device 3500 can include a circuit 3514, at least one wireless transmitter 3502, at least one wireless receiver 3504, and a plurality of antennas 3512 (only one antenna is shown in FIG. 35 for illustrative purposes). The circuit can include at least one controller 3506, and the controller 3506 is used to execute tasks designed to include controlling communication with one or more other multi-link devices in a MIMO wireless network under the assistance of software and hardware. The at least one controller 3506 can control at least one transmission signal generator 3508 to generate frames to be transmitted to one or more other STAs, APs, or AP multi-link devices (MLDs) through at least one wireless transmitter 3502, and further control at least one reception signal processor 3510 to process frames received from one or more other STAs, APs, or AP MLDs through at least one wireless receiver 3504. The at least one transmission signal generator 3508 and the at least one reception signal processor 3510 can be independent modules of the communication device 3500 that communicate with at least one controller 3506 for the functions described above. Alternatively, the at least one transmission signal generator 3508 and the at least one reception signal processor 3510 can be included in the at least one controller 3506. Those skilled in the art will understand that the arrangement of these functional modules is flexible and may vary according to actual needs and / or requirements. The data processing device, storage device, and other related control devices can be provided on a suitable circuit board and / or chipset.
[0080] In various embodiments, during operation, at least one wireless transmitter 3502, at least one wireless receiver 3504, and at least one antenna 3512 can be controlled by at least one controller 3506. Further, although only one wireless transmitter 3502 is shown, it will be understood that there may be two or more such transmitters.
[0081] In various embodiments, during operation, at least one wireless receiver 3504, together with at least one received signal processor 3510, forms the receiver of the communication device 3500. The receiver of the communication device 3500 provides the functions necessary for multi-link communication during operation. Although only one wireless receiver 3504 is shown, it will be understood that there may be two or more such receivers.
[0082] The communication device 3500 provides the functions necessary for cooperative SP during operation. For example, the communication device 3500 can be a first AP. The circuit 3514 can generate a request frame indicating a request to set up one or more cooperative SPs during operation. The wireless transmitter 3502 can transmit the request frame to a second AP during operation.
[0083] During operation, the wireless receiver 3504 can receive a response frame from the second AP, and the response frame indicates acceptance of a request to set up one or more cooperative SPs. The wireless transmitter 3502 can be further configured to transmit a frame for setting up a scheduled SP that overlaps with the cooperative SP to one or more associated STAs. The request frame, the response frame, and this frame may be TWT Setup frames, and the cooperative SP may be a TWT SP. The TWT Setup frame conveys indication information that the cooperative SP is an SP for multi-AP cooperative transmission, and further conveys the TSF value of the AP that transmits the TWT Setup frame. The TWT Setup frame received from the second AP can similarly convey the identity information of one or more other APs that are members of the cooperative SP. The TWT Setup frame can indicate, in the TWT Channel field and the TWT Extended channel field of the TWT element of each TWT Setup frame, the subchannels requested by the first AP or assigned by the second AP to the first AP, and these subchannels are a subset of the operating channels of the second AP. The TWT Setup frame can 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 by the second AP to the first AP, and these sub-SPs are part of the cooperative SP. The first AP may be the only AP permitted by the second AP to transmit on the assigned subchannels or in the assigned sub-SPs during the shared TXOP for multi-AP cooperative transmission initiated by the second AP.
[0084] The first AP can be further configured to participate in a shared TXOP for multi-AP cooperative transmission initiated by a second AP within a cooperative SP. The wireless transmitter 3502 of the first AP can be further configured to transmit frames to STAs associated with itself in a manner that cooperates with the second AP. The wireless transmitter 3502 can be further configured to transmit a frame reporting its own BSS's DL buffer state and UL buffer state to the second AP at the start of the shared TXOP. The multi-AP cooperative transmission can be one of C-OFDMA transmission, C-TDMA transmission, C-SR transmission, C-BF transmission, or cooperative MU-MIMO transmission. The circuit 3514 can be further configured to determine an appropriate type of multi-AP cooperative transmission for the associated STAs. The wireless transmitter 3502 can be further configured to transmit a frame for setting a scheduled SP overlapping with the corresponding cooperative SP to the associated STAs based on the determined type of multi-AP cooperative transmission. The request frame and this frame are TWT Setup frames. The TWT Setup frame can indicate, in the TWT channel field and the TWT Extended channel field of the TWT element of each TWT Setup frame, the subchannels requested by the first AP or assigned by the second AP to the first AP. These subchannels are a subset of the operating channels of the second AP. The TWT Setup frame can 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 by the second AP to the first AP. These sub-SPs are part of the cooperative SP. The first AP can be the only AP permitted by the second AP to transmit on the assigned subchannels or in the assigned sub-SPs during the shared TXOP for multi-AP cooperative transmission initiated by the second AP.
[0085] The wireless receiver 3504 can receive a frame transmitted by the second AP during operation, and this frame is one of a Beacon frame, an Action frame, or a data frame. The circuit 3514 can be further configured to extract information on the 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 to participate in one or more of the SPs associated with the second AP. The wireless transmitter 3502 can be further configured to transmit a frame for setting up a scheduled SP that does not overlap with the SPs associated with the second AP to one or more associated STAs. The TWT Setup frame can indicate, in the TWT channel field and the TWT Extended channel field of the TWT element of each TWT Setup frame, the subchannels requested by the first AP or the subchannels assigned by the second AP to the first AP, and these subchannels are a subset of the operating channels of the second AP. The TWT Setup frame can 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 by the second AP to the first AP, and these sub-SPs are part of the cooperative SPs. The first AP may be the only AP permitted by the second AP to transmit on the assigned subchannels or in the assigned sub-SPs during the shared TXOP for multi-AP cooperative transmission initiated by the second AP.
[0086] The communication device 3500 may be a non-AP STA. During operation, the wireless receiver 3504 can receive one of a Beacon frame or an Action frame from an associated AP. During operation, the circuit 3514 can extract information on the SP for cooperative transmission from the frame. During operation, the wireless transmitter 3502 can transmit a request frame to the AP, and the request frame indicates a request to participate in 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, by hardware, or by software cooperating with hardware. Each functional block used in the description of each of the above-described embodiments can be implemented in part or in whole by an LSI such as an integrated circuit, and 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 individually as a plurality of chips, or can be formed as one chip so as to include part or all of the functional blocks. The LSI can include a data input / output section coupled to itself. Depending on the degree of integration, the LSI is also referred to as an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing the integrated circuit is not limited to the LSI, and can be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. Furthermore, an FPGA (Field Programmable Gate Array) that can be programmed after the manufacture of the LSI, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells arranged inside the LSI can also be used. The present disclosure can be implemented as digital processing or analog processing. As a result of the progress of semiconductor technology or another derivative technology, when future integrated circuit technology replaces the LSI, the functional blocks can be integrated using the future integrated circuit technology. Biotechnology can also be applied.
[0088] The present disclosure can be implemented by any type of device, apparatus, or system having a communication function, referred to as a communication 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, smartwatches, tracking devices), game consoles, e-book readers, telemedicine / telehealth (remote medical / pharmaceutical) devices, vehicles providing a communication function (e.g., automobiles, airplanes, ships), and various combinations thereof.
[0090] The communication device is not limited to being portable or mobile and can include any type of device, apparatus, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other "things" within the network of the "Internet of Things (IoT)".
[0091] Communication can include exchanging data, for example, through cellular systems, wireless LAN systems, satellite systems, and various combinations thereof.
[0092] The communication device can include devices such as a controller or sensor coupled to a communication device that executes the communication function described in the present disclosure. For example, the communication device can include a controller or sensor that generates a control signal or data signal used by a communication device that executes the communication function of the communication device.
[0093] The communication device can further include infrastructure facilities, such as a base station, an access point, and any other device, device, or system that communicates with or controls a device such as the device in the non-limiting example above.
[0094] Non-limiting examples of stations may include stations included in a first plurality of stations belonging to a multi-link station logical entity (i.e., such as an AP MLD), where the stations among the first plurality of stations share a common medium access control (MAC) data service interface to an upper layer, and the common MAC data service interface is associated with a common MAC address or traffic identifier (TID).
[0095] In the present disclosure, the following statements are described.
[0096] (Statement 1) A first access point (AP), a circuit that generates a request frame indicating a request to set up one or more cooperative service periods (SPs) during operation, a transmitter that transmits the request frame to a second AP during operation, A first access point (AP) comprising the above.
[0097] (Statement 2) a receiver that receives a response frame from the second AP during operation, the response frame indicating acceptance of a request to set up one or more cooperative SPs, and the transmitter is further configured to transmit frames for setting up a scheduled SP that overlaps with the cooperative SP to one or more associated stations (STAs). The first AP according to Statement 1.
[0098] (Statement 3) The request frame, response frame, and frame are Target Wake Time (TWT) Setup frames, and the coordinating SP is the TWT SP. The first AP described in Statement 2.
[0099] (Statement 4) The TWT Setup frame conveys indication information that the coordinating SP is the SP for multi-AP coordinated transmission, and further conveys the Timing Synchronization Function (TSF) value of the AP that transmits the TWT Setup frame. The first AP described in Statement 3.
[0100] (Statement 5) The TWT Setup frame received from the second AP further conveys the identity information of one or more other APs that are also members of the coordinating 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 coordinated transmission initiated by the second AP within the coordinating SP, and the transmitter of the first AP is further configured to transmit frames to the STAs associated with itself in a manner that coordinates with the second AP. The first AP described in Statement 1.
[0102] (Statement 7) The transmitter is further configured to transmit a frame reporting the downlink (DL) buffer status and uplink (UL) buffer status of its basic service set (BSS) to the second AP at the start of the shared TXOP. The first AP described 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 described in Statement 6.
[0104] (Statement 9) The circuit 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 a frame to the associated STA for setting up a scheduled SP that overlaps with the corresponding cooperative SP based on the determined multi-AP cooperative transmission type, and the request frame and the frame are TWT Setup frames. The first AP described in Statement 8.
[0105] (Statement 10) A receiver that receives a frame transmitted by a second AP during operation, where the frame is one of a Beacon frame, an Action frame, or a data frame, and the circuit is further configured to extract information on the SP associated with the second AP from the received frame. The first AP described in Statement 1.
[0106] (Statement 11) The SP is a TWT SP. The first AP described in Statement 10.
[0107] (Statement 12) The transmitter is further configured to transmit a TWT setup request frame to the second AP to request to participate in one or more of the SPs associated with the second AP. The first AP described in Statement 11.
[0108] (Statement 13) The transmitter is further configured to transmit to one or more associated STAs a frame for setting up a scheduled SP that does not overlap with the associated SP of the second AP. The first AP described in Statement 10.
[0109] (Statement 14) The TWT Setup frame indicates, in the TWT channel field and the TWT Extended channel field of the TWT element of each TWT Setup frame, a subchannel requested by the first AP or assigned to the first AP by the second AP, and the subchannel is a subset of the operating channel of the second AP. The first AP described in Statement 3, Statement 9, and Statement 12.
[0110] (Statement 15) The TWT Setup frame indicates, 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, and the sub-SP is part of the cooperative SP. The first AP described in Statement 3, Statement 9, and Statement 12.
[0111] (Statement 16) The first AP is the only AP permitted by the second AP to transmit during the shared TXOP for multi-AP cooperative transmission started by the second AP, on the assigned subchannel or the assigned sub-SP. The AP described in Statement 14 and Statement 15.
[0112] (Statement 17) A non-AP STA, During operation, a receiver that receives either a Beacon frame or an Action frame from an AP associated with itself, During operation, a circuit that extracts information of an SP for cooperative transmission from a frame, During operation, a transmitter that transmits a request frame to an AP, where the request frame indicates a request to participate in an SP, A non-AP STA comprising the above.
[0113] (Statement 18) where the SP is a TWT SP and the request frame is a TWT setup request frame, The non-AP STA described in Statement 17.
[0114] (Statement 19) The step of generating a request frame indicating a request to set up one or more cooperative service periods (SPs), The step of transmitting the request frame to an AP, A method comprising the above.
[0115] Thus, it can be understood that embodiments of the present invention provide a communication device and a communication method corresponding to a cooperative SP.
[0116] In the detailed description of the embodiments of the present invention so far, exemplary embodiments have been presented, but it should be understood that there are a vast number of variations. 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 detailed description so far provides a convenient guide for those skilled in the art to implement the exemplary embodiments. It should be understood that various changes can be made to the steps of the operations, the functions and arrangements of the methods, and the modules and structures of the devices described in the exemplary embodiments without departing from the scope of the subject matter described in the appended claims.
Claims
1. A first access point (AP), comprising: a circuit that generates a request frame indicating a request to set up one or more target wake time (TWT) service periods (SP); a transmitter that transmits the request frame to a second AP; a receiver that receives, from the second AP, a response frame indicating acceptance of the request and conveying identity information of one or more other APs that are members of the TWT SP; wherein the transmitter transmits a frame for setting up a Scheduled SP that overlaps with the TWT SP to one or more associated stations (STA). The first access point (AP).
2. The request frame, the response frame, and the frame are TWT Setup frames, the TWT Setup frames convey indication information that the TWT SP is an SP for multi-AP coordinated transmission, and further convey the timing synchronization function (TSF) value of the AP that transmits the TWT Setup frame. The first AP according to Claim 1. The first AP according to claim 1.
3. A first access point (AP), comprising: a circuit that generates a request frame indicating a request to set up one or more coordinated service periods (SP); a transmitter that transmits the request frame to a second AP; wherein the first AP is further configured to participate in a shared TXOP for multi-AP coordinated transmission initiated by the second AP within the coordinated SP; the transmitter is further configured to transmit a frame to a STA associated with the first AP in a manner that coordinates with the second AP, and transmit a frame reporting the downlink (DL) buffer state and uplink (UL) buffer state of the basic service set (BSS) of the first AP to the second AP at the start of the shared TXOP. The first access point (AP).
4. A first access point (AP), comprising: a circuit that generates a request frame indicating a request to set up one or more coordinated service periods (SP); a transmitter that transmits the request frame to a second AP; wherein the first AP is further configured to participate in a shared TXOP for multi-AP coordinated transmission initiated by the second AP within the coordinated SP; The transmitter is further configured to transmit frames to a STA associated with the first AP in a manner that coordinates with the second AP. The multi-AP coordinated transmission is one of coordinated orthogonal frequency division multiple access (OFDMA) transmission, coordinated time division multiple access (TDMA) transmission, coordinated spatial reuse (SR) transmission, coordinated beamforming (BF) transmission, or coordinated multi-user multiple input multiple output (MU-MIMO) transmission. The circuit is further configured to determine an appropriate type of multi-AP coordinated transmission for each associated STA, and the transmitter is further configured to transmit a frame to the associated STA for setting up a Scheduled SP that overlaps with the determined multi-AP coordinated transmission type and the corresponding coordinated SP, and the request frame and the frame are TWT Setup frames. A first access point (AP). **Claim 5** Generating a request frame indicating a request to set up one or more target wake time (TWT) service periods (SPs); Transmitting the request frame to the AP; Receiving, from the AP, a response frame indicating acceptance of the request and conveying identity information of one or more other APs that are members of the TWT SP; Transmitting a frame to one or more associated stations (STAs) for setting up a Scheduled SP that overlaps with the TWT SP; A method comprising.
Citation Information
Patent Citations
Systems and methods for collaborative messaging using high-performance wifi
JP2016524368A
Communication apparatus and communication method for prioritized traffic
SG10202012139Q
Coordinated medium access
US20190082358A1