Communication device and communication method compatible with multi-AP synchronous transmission

Abstract

This invention provides a communication device and communication method that support synchronous transmission of multiple access points (APs). [Solution] In a multi-AP system, the communication device 4800 includes a circuit 4814 that generates a frame containing information for subsequent transmissions when in operation, and a wireless transmitter 4802 that transmits this frame to another communication device when in operation.

Description

Technical Field

[0001] This embodiment generally relates to a communication device, and more particularly to a method and apparatus for supporting multi - access point (multi - AP) synchronous transmission.

Background Art

[0002] In the standardization of next - generation wireless local area network (LAN), 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) WLAN, the transmission of multiple frames in a transmission opportunity (TXOP) is supported, and a station (STA) can transmit additional frames in the transmission queue. In 11be extremely high - throughput (EHT) WLAN, for the purpose of improving throughput beyond 11ax HE WLAN, especially for cell - edge STAs, it has been proposed to enable coordinated orthogonal frequency - division multiple access (C - OFDMA) in a multi - AP system.

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the transmission of multiple frames within a TXOP under C - OFDMA operation in multi - AP synchronous transmission has not been discussed so far.

[0005] Therefore, there is a need for communication devices and communication methods that can solve the aforementioned problems. Furthermore, other desirable features and characteristics will become apparent from the accompanying drawings and the subsequent detailed description and the accompanying claims, which are considered in conjunction with the background art section of this disclosure. [Means for solving the problem]

[0006] Non-limiting and exemplary embodiments facilitate the provision of communication devices and communication methods that support multi-AP synchronous transmission.

[0007] According to one aspect of the present disclosure, a communication device is provided, comprising: a circuit that generates a frame containing information for a subsequent transmission when in operation; and a transmitter that transmits this frame to another communication device when in operation.

[0008] Another aspect of the present disclosure provides a communication method comprising the steps of generating a frame containing information for a subsequent transmission, and transmitting the frame to a communication device.

[0009] It should be noted that general or specific embodiments may be implemented as systems, methods, integrated circuits, computer programs, storage media, or any selective combination thereof. Further benefits and advantages of the disclosed embodiments will become apparent from this specification and the drawings. These benefits and / or advantages can be obtained individually by the various embodiments and features of this 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 explanation of the drawing]

[0010] The attached figures, along with the following detailed description, are incorporated herein and form part of it, illustrating various embodiments and illustrating the various principles and advantages of this embodiment. Throughout the individual figures, similar reference figures refer to identical or functionally similar elements. [Figure 1]This shows an example of single-AP-based multi-frame transmission within TXOP in 11ax. [Figure 2] This shows an example of a transmission failure where a block acknowledgment (BA or BlockAck) is not received. [Figure 3] This shows an example of a transmission failure where an invalid BA is received. [Figure 4] This shows an example of the format of a BlockAck request frame in 11ax. [Figure 5] This table shows an example of BlockAck frame variants and their corresponding lengths (octets). [Figure 6] This shows a typical example of C-OFDMA transmission. [Figure 7] This illustrates a scenario where BlockAck frames are not aligned. [Figure 8] This shows scenarios for when data transmission fails. [Figure 9] This shows scenarios where BA transmission fails. [Figure 10] This shows C-OFDMA transmission according to one embodiment. [Figure 11] This shows an example of asynchronous transmission. [Figure 12] This shows an example of synchronous downlink (DL) transmission. [Figure 13] This shows an example of synchronous uplink (UL) transmission. [Figure 14] This shows an example of a MAP Trigger frame. [Figure 15] This table shows an example of MAP trigger types and their corresponding values. [Figure 16] This shows a subfield of the UL TXVECTOR field according to one embodiment. [Figure 17] This shows a subfield of the UL TXVECTOR field according to another embodiment. [Figure 18]An example of a TRS Control subfield according to an embodiment is shown. [Figure 19] An exemplary table of default TXVECTOR parameter lists according to the standard 802.11ax specification is shown. [Figure 20] The new A-Control subfield of the HE variant HT Control field format is shown. [Figure 21] An exemplary table of values of the Control ID subfield and their corresponding descriptions is shown. [Figure 22] An exemplary format of a MU-BAR Trigger frame according to various embodiments is shown. [Figure 23] An exemplary format of a new MAP-BAR Trigger frame according to various embodiments is shown. [Figure 24] An exemplary table of trigger type encoding and the corresponding Trigger frame variants is shown. [Figure 25] An example of the Common Information field of the MAP BAR Trigger frame format according to various embodiments is shown. [Figure 26] An example of the Trigger Dependent User Info subfield of the MAP BAR Trigger frame format according to various embodiments is shown. [Figure 27] An exemplary flowchart including "blank spaces" according to various embodiments is shown. [Figure 28] An exemplary format of a new MAP Trigger frame that requires a MAP response according to various embodiments is shown. [Figure 29] A flowchart of a single round of C-OFDMA transmission with a MAP response according to various embodiments is shown. [Figure 30] This diagram shows a single round of C-OFDMA transmission with a MAP response transmitted in a media access control (MAC) frame, according to one embodiment. [Figure 31] This shows exemplary MAP response frame formats for various embodiments. [Figure 32] This diagram shows a C-OFDMA transmission with a MAP response transmitted via a null data packet (NDP) according to one embodiment. [Figure 33] This shows an exemplary format of a MAP response NDP according to one embodiment. [Figure 34] This table shows an example of the preferred PPDU format, corresponding resource unit (RU) toneset index value, and feedback status for generating EHT-LTF (EHT-Long Training field) in MAP response NDP. [Figure 35] This table shows an example of preferred modulation and coding schemes (MCS), corresponding RU tone set index values, and feedback statuses for EHT-LTF (EHT-Long Training Field) generation in MAP-response NDP. [Figure 36] This diagram illustrates an example of the overlapping network range between the AP and STA. [Figure 37] This shows flowcharts of the operation of the shared AP in various embodiments. [Figure 38] This diagram shows a flow chart of C-OFDMA error recovery using a new C-OFDMA error recovery interval in various embodiments. [Figure 39] This diagram shows a flow chart of C-OFDMA error recovery using Extended Interframe Space (EIFS) in various embodiments. [Figure 40] This diagram shows a flow chart for C-OFDMA error recovery using short PPDU transmission in various embodiments. [Figure 41]This shows flowcharts illustrating the operation of the shared AP during error recovery in various embodiments. [Figure 42] This diagram shows the C-OFDMA error recovery process in various embodiments where a MAP response is requested and an expected ACK / BlockAck frame is received. [Figure 43] This diagram shows a flow chart of C-OFDMA error recovery in various embodiments when a MAP response is requested and the expected ACK / BlockAck frame is not received during the AckTimeout interval. [Figure 44] This shows flowcharts illustrating the operation of the shared AP in C-OFDMA error recovery under various embodiments. [Figure 45] This shows flowcharts illustrating the operation of the shared AP in a C-OFDMA error recovery mechanism, including MAP responses, according to various embodiments. [Figure 46] This shows the configuration of various communication devices, such as communication equipment, or shared access points, according to different embodiments. [Figure 47] This diagram illustrates various methods of multi-AP synchronous transmission according to different embodiments. [Figure 48] The diagram shows a partially framed schematic of an AP or STA that can be implemented to support multi-AP synchronous transmission according to various embodiments.

[0011] Those skilled in the art will understand that the elements in the diagram are illustrated in a concise and clear manner, and are not necessarily drawn to the correct scale. [Modes for carrying out the invention]

[0012] The following detailed description is illustrative only and is not intended to limit the embodiments or the application and use of the embodiments. Furthermore, it is not intended to be constrained by the prior background art or theories presented in the sections on embodiments for carrying out the invention. In addition, 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 this disclosure.

[0013] A TXOP is a limited period during which a station can transmit data. Upon receiving a TXOP, a station can transmit data frames, control frames, and management frames, and receive response frames, as long as the duration of the frame sequence does not exceed the TXOP limit. Figure 1 shows an example of single-AP-based multi-frame transmission within a TXOP in 11ax.

[0014] Transmission of multiple frames within a TXOP occurs after the completion of the frame exchange sequence, when the Enhanced Distributed Channel Access Function (EDCAF) retains the right to access the medium. If a TXOP holder has additional frames in the transmit queue, and the transmission of those frames and the expected duration of acknowledgments for those frames are likely to end within the TXOP, the TXOP holder may, subject to the constraints of the TXOP limit, begin transmitting those frames in the Short Interframe Space (SIFS) after the completion of the preceding frame exchange sequence. If transmission by the TXOP holder fails, the AP can initiate priority interframe space (PIFS) recovery.

[0015] There are two cases in which a transmission is determined to have failed. In the first case, a block acknowledgment (BA or BlockAck) is not received. An example of this is shown in Figure 2. In TXOP, the AP sends an HE Physical Layer Protocol Data Unit (PPDU) 202 containing a frame that requires an immediate acknowledgment. The expected reception of the acknowledgment does not begin during the first slot time following the SIFS, i.e., the AP does not receive a BA 204. Subsequently, the AP may send another PPDU 206 containing a Block Acknowledgment Request (BlockAckReq) frame in the PIFS after the previous frame.

[0016] In the first case, an invalid BA is received. An example of this is shown in Figure 3. In the TXOP, the AP sends HE PPDU 302 containing a frame requiring immediate acknowledgment. The expected acknowledgment is received, i.e., BA 304 is received by the AP, but BA 304 is recognized as an invalid frame. Subsequently, the AP may send another PPDU 306 containing a BlockAckReq frame in the PIFS following the received BA frame.

[0017] The length of the PPDU that transmits the BlockAck frame depends on the BlockAck frame variant invited by the BlockAckReq frame and the receiving device. The BlockAck frame variant to be used is indicated in the BlockAckReq frame sent by the STA, which invites an immediate response. The type of PPDU used to transmit the BlockAck frame is determined by the invited STA and can be a non-HT PPDU or an HE single-user (SU) PPDU. The primary modulation and coding scheme (MCS) and primary rate are selected for the PPDU by the invited STA. An example of the BlockAckReq frame format in 11ax is shown in Figure 4, and an exemplary table of BlockAck frame variants and their corresponding lengths (octets) is shown in Figure 5.

[0018] However, there is no information regarding the parameters of the uplink (UL) PPDU shown in the BlockAckReq frame. The length of the PPDU that carries the BlockAck frame is determined by the STA when solicited in the BlockAckReq frame. The AP can estimate the length of the PPDU, but cannot determine it.

[0019] In C-OFDMA transmission, the sharing AP shares frequency resources with (one or more) shared APs for the duration of the acquired TXOP. A typical example of C-OFDMA transmission is shown in Figure 6. The sharing AP shares its frequency resources with (one or more) shared APs in units of multiples of 20 MHz channels. C-OFDMA transmission can include two phases. Phase 1 (negotiation and preparation) allows for the exchange of information necessary for C-OFDMA transmission. Phase 2 is when the sharing AP initiates cooperative transmission between participating APs. If the cooperative transmission is synchronized, the information necessary for synchronization can be provided before the cooperative transmission begins.

[0020] Numerous problems can arise in achieving multi-frame transmission within a TXOP in C-OFDMA operation. For example, one or more unaligned BlockAck frames can cause ACI (Adjacent Channel Interference) and collisions. Another example is the error recovery problem, where unaligned BlockAck frames and the 11ax error recovery mechanism can lead to collisions.

[0021] Figure 7 illustrates a scenario involving unaligned BlockAck frames. STA1 is associated with the sharing AP, and STA2 is associated with the shared AP. A Multi-AP (MAP) Trigger frame 702 targets the shared AP, and STA2 cannot hear the sharing AP. The BlockAck frame 704 transmitted by STA1 and the BlockAck frame 706 transmitted by STA2 may be unaligned, and therefore collisions and ACI (Adjacent Channel Interference) can occur.

[0022] Figure 8 illustrates a scenario of a failed data transmission. STA1 is associated with the sharing AP, and STA2 is associated with the shared AP. MAP Trigger frame 802 is targeted to the shared AP, and the sharing AP cannot hear STA2. If the BlockAck frame 804 sent by STA1 is not received by the sharing AP, the sharing AP performs PIFS recovery. In this case, the MAP Trigger frame 808 sent by the sharing AP to the shared AP following PIFS will collide with the BlockAck frame 806 sent by STA2.

[0023] Figure 9 illustrates a scenario of a failed BA transmission. STA1 is associated with the sharing AP, and STA2 is associated with the shared AP. MAP Trigger frame 902 targets the shared AP, and the sharing AP cannot hear STA2. If BA frame 904 transmitted by STA1 fails, the sharing AP transmits a subsequent frame in the PIFS after BA frame 904. The transmission of the subsequent frame may collide with BlockAck frame 906 transmitted by STA2. However, if BlockAck frames 904 and 906 transmitted by STA1 and STA2 are aligned, this problem does not occur.

[0024] In operations where multiple APs transmit together, one AP can send information about subsequent transmissions to one or more other APs. Possible operations include using multi-AP coordination or multi-link transmission (when multi-link APs are involved) to ensure that information about subsequent transmissions, such as transmission type (asynchronous / synchronous), PPDU parameters conveying the expected BlockAck frame, and other similar information, is shared among the APs.

[0025] Figure 10 shows a C-OFDMA transmission according to one embodiment. The C-OFDMA transmission includes the following phases. Negotiation and preparation phase 1002 may include the necessary negotiation and preparation for the next cooperative transmission. For example, this may include the exchange of request to send (RTS) frames and clear to send (CTS) frames, the exchange of requests and intentions to participate in the next cooperative transmission, the switching of the primary channel, the reporting of the buffer status of (one or more) candidate shared APs, and the selection of (one or more) shared APs. Subsequently, cooperative transmission phase 1004 may include one or more rounds of C-OFDMA transmission 1008. The sharing AP sends a MAP Trigger frame 1006 to (one or more) shared APs to initiate one round of C-OFDMA transmission. The MAP Trigger frame 1006 may be transmitted in a non-HT duplicate PPDU. Furthermore, the intended type of C-OFDMA transmission is indicated before the C-OFDMA transmission. In one option, the intended transmission type is indicated in the negotiation and preparation phase 1002 so that the next cooperative transmission phase 1004 includes only one type of C-OFDMA transmission. In another option, the intended transmission type is indicated in the MAP Trigger frame 1006 for the round in which the C-OFDMA transmission is initiated.

[0026] The intended type of C-OFDMA transmission can be asynchronous or synchronous. The intended transmission type can be determined based on the interference level, and ACI between APs can be reduced by spectral masking in asynchronous transmissions and further reduced by aligned symbols in synchronous transmissions. Alternatively, the intended transmission type may be determined based on the buffer state of (one or more) shared APs, and asynchronous transmission is a better choice in scenarios where (one or more) shared APs have large buffers. The intended transmission type may also be determined based on the duration of subsequent transmissions from the sharing AP. For example, if the duration of subsequent transmissions is long (i.e., until the end of the acquired TXOP), asynchronous transmission can be selected.

[0027] Figure 11 shows an example of asynchronous transmission. When asynchronous transmission is shown, the sharing AP no longer controls the (one or more) subchannels assigned to the (one or more) shared APs after sending the MAP Trigger frame 1102. Instead, the shared APs gain complete control of the (one or more) subchannels that are assigned to them. The sharing AP and the (one or more) shared APs transmit independently on their own frequency resources. Therefore, in asynchronous transmission, the sharing AP does not need to align transmissions, but loses control over the (one or more) shared APs and their assigned subchannels.

[0028] In asynchronous transmission, the sharing AP may still listen on the subchannel assigned to the shared AP, if conditions permit, for example by using an available antenna or by performing a clear channel assessment (CCA) on the subchannel during an SIFS between PPDUs. If the assigned subchannel is detected to have been idle for an extended period (e.g., idle for two consecutive periods of PIFS or SIFS), the sharing AP may attempt to terminate the cooperative transmission by sending a frame (e.g., a Contention Free-End (CF-End) frame or a MAP Trigger frame) to one or more shared APs, or to reclaim the assigned subchannel for its own use.

[0029] When synchronous transmission is indicated, the shared AP controls all frequency resources until the end of the acquired TXOP. Figure 12 shows an example of synchronous downlink (DL) transmission, and Figure 13 shows an example of synchronous uplink (UL) transmission. In the case of synchronous DL transmission shown in Figure 12, the UL BlockAck frame in the subsequent C-OFDMA transmission can be solicited by the Trigger frame 1202 or the triggered response scheduling (TRS) control field. The parameters required for the subsequent C-OFDMA transmission are indicated in the MAP Trigger frame 1202 and include, for example, the frequency resources allocated for each shared AP, the TXVECTORS required to align the C-OFDMA transmission, the maximum transmit power, the parameters of the PPDU that conveys the BlockAck frame (e.g., PPDU format), and other similar parameters.

[0030] After SIFS, the sharing AP and (one or more) shared APs simultaneously transmit data (including parameters for the PPDU that conveys the BlockAck frame) on their own frequency resources according to the parameters indicated in the MAP Trigger frame 1202 (i.e., the sharing AP sends EHT PPDU 1204 to STA1 and the shared AP sends EHT PPDU 1206 to STA2). After SIFS, the STAs simultaneously transmit BlockAck frames to their corresponding associated APs according to the parameters conveyed in the received DL PPDUs (i.e., STA1 sends BA frame 1208 to the sharing AP and STA2 sends BA frame 1210 to the shared AP). If a valid BlockAck frame is received, at least after SIFS, the sharing AP may, if the TXOP duration allows, send a new MAP Trigger frame 1212 to initiate another round of C-OFDMA transmission. If the sharing AP does not receive the expected BlockAck frame, the C-OFDMA recovery mechanism is executed. If the TXOP duration allows, the shared AP can send a new MAP Trigger frame according to the C-OFDMA recovery mechanism and initiate another round of C-OFDMA transmission.

[0031] In synchronous transmission, the shared AP will not initiate transmission unless triggered or indicated by the sharing AP. Furthermore, the shared AP transmits according to the parameters indicated in the MAP Trigger frame. Advantageously, the BlockAck frames transmitted by the STA are aligned, avoiding collisions caused by misalignment of BlockAck frames or failure to transmit BlockAck frames.

[0032] Figure 14 shows an example of a MAP Trigger frame 1400, and Figure 15 shows an exemplary table of MAP trigger types and their corresponding values. For example, when the MAP trigger type field 1402 shows a value of "0", the corresponding MAP type is Joint Transmission, and when the MAP trigger type field 1402 shows a value of "1", the corresponding MAP type is C-OFDMA Transmission.

[0033] When the UL / DL Flag field 1404 indicates "UL transmission," the information contained in the DL TXVECTOR field 1406 is used to indicate the parameters of the DL PPDU containing the Trigger frame and the parameters of the DL PPDU conveying the BlockAck frame. Furthermore, the information contained in the UL TXVECTOR field 1408 is used to indicate the parameters of the trigger-based UL PPDU to be transmitted by (one or more) STAs in the next C-OFDMA transmission. Figure 16 shows the subfields of the UL TXVECTOR field 1408 when the UL / DL Flag field 1404 indicates "UL transmission," and the PPDU Format subfield 1602 can indicate HE TB PPDU / EHT TB PPDU.

[0034] When the UL / DL Flag field 1404 indicates "DL transmission," the DL PPDU Length for BA subfield 1410 of the DL TXVECTOR field 1406 becomes spare, and the information contained in the UL TXVECTOR field 1408 indicates the parameters of the PPDU that will transmit the BlockAck frame in the next C-OFDMA transmission by (one or more) STAs. Figure 17 shows the subfields of the UL TXVECTOR field 1408 when the UL / DL Flag field 1404 indicates "DL transmission," and the PPDU Format subfield 1704 can indicate a non-HT / HE / EHT PPDU. For example, the PPDU format can be implicitly indicated, i.e., the STA uses the same PPDU format as the soliciting DL PPDU to transmit the BlockAck frame. The BA Soliciting Manner subfield 1702 can indicate only a TRS Control field or a Trigger frame. If the PPDU Format subfield 1704 is indicated as "Non-HT PPDU" or the BA Soliciting Manner subfield 1702 is indicated as "TRS Control field or Trigger frame", then the subfields from the PPDU Format subfield 1704 onward are reserved. The length of a PPDU conveying a BlockAck frame is generally shorter than a normal data PPDU. The most significant bit (MSB) of the UL TXVECTOR field 1700 can be reused to indicate the BA soliciting manner, in which case the number of UL data symbols can be indicated using fewer bits compared to indicating the length of the UL PPDU.

[0035] In one embodiment, in each round of C-OFDMA transmission, the parameters of the PPDU conveying the BlockAck frame, as shown in the MAP Trigger frame sent by the sharing AP, are determined without explicit feedback from (one or more) shared APs. In one option, the parameters are determined by the sharing AP based on its own requirements. In another option, the parameters are determined by the sharing AP based on the maximum bitmap length of the BlockAck frame. The maximum bitmap length is 1024 octets, or the maximum possible bitmap length among all participating APs, which can be exchanged during the negotiation and preparation phases.

[0036] One or more shared APs prepare and send DL transmissions according to the parameters indicated in both the DL TXVECTOR and UL TXVECTOR fields. DL transmissions contain information about the parameters of the PPDU that carries the BlockAck frame. If a PPDU using the indicated parameters cannot carry the BlockAck requested by a MAC protocol data unit (MPDU) or aggregated MPDU (A-MPDU) in the transmit queue, the shared AP may abandon the MPDU or shorten the A-MPDU. For example, a sharing AP decides to invite a PPDU of length L1 to carry the BlockAck frame and presents it to the shared AP. The shared AP has an A-MPDU with 180 MPDUs in its transmit queue. The expected bitmap length in the BlockAck frame should be 32 octets. The shared AP calculates the predicted length (L2) of the PPDU that conveys the expected BlockAck frame, based on parameters (BlockAck frame length, maximum available MCS, PPDU format, etc.), such that L2 > L1. The shared AP can then shorten the A-MPDU to 64 inner MPDUs and invite a BlockAck frame with an 8-octet bitmap. This is advantageous in that it reduces complexity, but may increase the overhead of the shared AP or decrease throughput.

[0037] In one embodiment, when the BA Soliciting Manner subfield of a MAP Trigger frame is indicated as "TRS Control field or Trigger frame," the sharing AP and (one or more) shared APs can indicate the parameters of the PPDU conveying the BlockAck frame to the associated STA by reusing the TRS Control subfield of the HE variant HT Control field. The HT Control field is always present in the Control Wrapper frame and in the Quality of Service (QoS) Data and Management frame when the +HTC subfield of the Frame Control field is set to 1. The TRS Control subfield indicates some of the parameters of the PPDU conveying the BlockAck frame. Other necessary parameters can be set as a default TXVECTOR parameter list. The PPDU shall convey a BlockAck request frame that has a frame conveying a TRS Control subfield indicating the parameters of the BlockAck frame.

[0038] Figure 18 shows an example of the TRS Control subfield 1800. The RU Allocation subfield 1802 can use a spare entry to indicate the PPDU format when used to solicit the PPDU that will carry the BA frame. The PPDU format can be non-HT PPDU or EHT PPDU. The spare subfield 1804 can be used to indicate that the TRS Control subfield 1800 will be reused to indicate the parameters of the PPDU that will carry the BA frame. For example, if "0" is indicated in the TRS Control subfield 1800, the PPDU format that will carry the BA frame is HE TB PPDU. For further reference, Figure 19 shows an exemplary table of the default TXVECTOR parameter list according to the standard 802.11ax specification.

[0039] When the BA Soliciting Manner subfield in a MAP Trigger frame is indicated as a "TRS control field or Trigger frame," the sharing AP and (one or more) shared APs can use the new Control subfield of the HE variant HT Control field to indicate the parameters of the PPDU that transmits the BlockAck frame to the associated STA. Figure 20 shows the new A-Control subfield 2002 in the HE variant HT Control field format, and Figure 21 shows an exemplary Table 2100 of Control ID subfield values ​​and their corresponding descriptions. For example, a Control ID subfield 2004 with a value of 7 indicates that the A-Control subfield 2002 is used for MAP BlockAck scheduling control (MBS).

[0040] The A-Control subfield 2002 can be 30 bits long. The PPDU (i.e., sent from the sharing AP and (one or more) shared APs to their respective associated STAs) shall convey a BlockAck request frame having a frame that conveys the A-Control subfield 2002 for indicating the parameters of the BlockAck frame. The parameters of the BlockAck frame may be indicated in the Control Information subfield 2006 of the A-Control subfield 2002. This new control field can also be used when the BA frame is conveyed in an SU PPDU.

[0041] In one embodiment, a sharing AP and (one or more) shared APs can specify the parameters of the PPDU that conveys the BlockAck frame by reusing a Multi-User Block Acknowledgment Request (MU-BAR) Trigger frame to the associated STA. Figure 22 shows an exemplary format of a MU-BAR Trigger frame 2200, which includes at least a Common Information field 2202 and a User Info List field 2210. The Common Information field 2202 may include a More TF subfield 2204 and a CS Required subfield 2206. The More TF subfield 2204 can be used together with the CS Required subfield 2206 to specify the PPDU format of the PPDU that conveys the BlockAck frame. For example, the PPDU format may be specified as a Non-HT PPDU, HE TB PPDU, or EHT TB PPDU. The User Info List field 2210 may contain a User Info field that includes at least a Trigger Dependent User Info subfield 2212. The BA End Sequence Control subfield 2214 of the Trigger Dependent User Info subfield 2212 can be used to indicate the size of the BA. The Reserve field 2208 can be used to indicate that the MU-BAR Trigger frame 2200 is reused to indicate the parameters of the PPDU that transmits the BA frame in C-OFDMA.

[0042] In one embodiment, the sharing AP and (one or more) shared APs can indicate the parameters of the PPDU that transmits the BlockAck frame in the Trigger frame variant transmitted in the DL PPDU to the associated STA. Figure 23 shows an exemplary format of a new MAP-BAR Trigger frame 2300 that includes at least a Common Information field 2302. The Common Information field 2302 may include at least a Trigger Type subfield 2304, a More TF field, a CS Required field, a MU-MIMO LTF Mode field, a UL STBC field, an LDPC Extra Symbol Segment field, a Doppler field, a UL-HE-SIGA2 Reserved field, and a Trigger Dependent Common Info field 2306. The Trigger Type subfield 2304 identifies the Trigger frame variant. Examples of its encoding are defined in Table 2400 in Figure 24. For example, a value of 8 in the Trigger Type subfield indicates that the trigger frame variant is in MAP BAR format.

[0043] Figure 25 shows an example of the Common Information field 2500 in the MAP BAR Trigger frame format, where the More TF field, CS Required field, MU-MIMO LTF Mode field, UL STBC field, LDPC Extra Symbol Segment field, Doppler field, and UL-HE-SIGA2 Reserved field are reserved. The Trigger Dependent User Info subfield 2600 of the MAP BAR Trigger frame 2300 is defined as shown in Figure 26 (i.e., similar to the same subfield 2212 of the MU-BAR trigger frame 2200), and the BAR Control subfield 2602 and BAR Information field 2604 are defined similarly to those of the BlockAck Request frame. Compared to the new A-Control subfield, the MAP BAR Trigger frame can show more information, but this may result in significant transmission overhead.

[0044] In one embodiment, the sharing AP may optionally solicit MAP responses from (one or more) shared APs. The solicited MAP response may convey estimated parameters of the expected BlockAck frame for the next round of C-OFDMA transmission and any other negotiation information (i.e., empty buffer report) that the sharing AP may require during the coordinating phase. The MAP response may be solicited by a MAP Trigger frame and may be sent at the end of one round of C-OFDMA transmission. The sharing AP will solicit a MAP response only if the following conditions are met: it is possible in the remaining TXOP and the next round of C-OFDMA transmission is a synchronous transmission.

[0045] In a single round of C-OFDMA transmission, the sharing AP indicates the parameters of the PPDU that will transmit the BlockAck frame, based on the parameters in the MAP response and its own requirements in the MAP Trigger frame. The (one or more) shared APs prepare and transmit the DL transmission according to the parameters indicated in both the DL TXVECTOR field and the UL TXVECTOR field. The sharing AP and the (one or more) shared APs indicate the parameters of the PPDU that will transmit the BlockAck frame to the associated STA using the TRS Control subfield of the HE variant HT Control field included in the DL transmission or the MU-BAR Trigger frame. Advantageously, this ensures the successful data transmission of the (one or more) shared APs. The C-OFDMA transmission procedure has the overhead of the MAP response added. Furthermore, a "blank space" is created for the STA associated with the sharing AP. Figure 27 shows an exemplary flowchart 2700 of the "blank space". In flow chart 2700, STA1 cannot hear the shared AP. For the duration of MAP response 2702 and the subsequent SIFS 2704, STA1 perceives the channel as idle. This duration is a "blank space" 2706 for STA1. If STA1 attempts to send something during this period, a collision may occur.

[0046] The sharing AP can use the MAP Response Required subfield 2802 to indicate whether a MAP response from the shared AP is required in the MAP Trigger frame 2800 shown in Figure 28. When a MAP response is required, the procedure for one round of C-OFDMA transmission is as shown in the illustrative flowchart 2900 in Figure 29. The shared AP sends a MAP response 2902 to the sharing AP in the SIFS following the received BlockAck frame.

[0047] As shown in the MAP response 3002 in the exemplary flow diagram 3000 of Figure 30, the MAP response may be transmitted in a MAC frame. For example, the MAP response 3002 may be an EHT PPDU that transmits the MAP response frame.

[0048] Figure 31 shows an exemplary MAP response frame format 3100. The parameters of the PPDU that convey the MAP response frame (e.g., PPDU length, number of EHT-LTF symbols, etc.) can be set as a predefined default parameter list, or the necessary parameters can be indicated in the MAP Trigger frame.

[0049] Information for a MAP response can be conveyed in a null data packet (NDP). As shown in the exemplary flow diagram 3200 in Figure 32, a MAP response 3204 can be a MAP response NDP. Some information necessary to solicit a MAP response NDP (i.e., the target RSSI) is shown in the Per AP Info subfield of the AP Info List field in the MAP Trigger frame 3202. An exemplary format of a MAP response NDP 3300 is shown in Figure 33. Advantageously, lower overhead is achieved compared to conveying the MAP response in a MAC frame. However, the STA associated with the shared AP may not be aware of the purpose of the MAP response NDP.

[0050] A scheduled shared AP can use different tone sets to indicate preferred parameters using the EHT-LTF field of the MAP response NDP. The tone set can be determined from FEEDBACK_STATUS (two types of status) and RU_TONE_SET_INDEX (18 types of tone sets for each status), so there are a total of 36 entries for each 20MHz channel. Preferred parameters such as preferred PPDU format, preferred MCS, and preferred BA type must be indicated. Referring to the exemplary table 3400 in Figure 34, the preferred PPDU format can have three entries when the feedback status is "0", such as non-HT PPDU (RU tone set index 1), HE PPDU (RU tone set index 2), and EHT PPDU (RU tone set index 3). Referring to the exemplary table 3500 in Figure 35 when the feedback status is "1", there can be 0 to 13 entries for preferred MCS with RU tone set indices 1 to 14. The AP can distinguish MAP response NDP from EHT TB feedback NDP (where only a single RU tone set is used) by detecting whether multiple tone sets are used in the EHT-LTF. Furthermore, there may be five entries for preferred BA types such as Extended Compression / Compression / Multi-Traffic Identifier (Multi-TID) / Group Cast with Retry (GCR) / General Link GCR (GLK-GCR).

[0051] The available entries in the MAP response NDP can be used to indicate the buffer state of the shared AP. For example, if a shared AP indicates an empty buffer, the sharing AP can terminate cooperation with (one or more) shared APs and reallocate the corresponding (one or more) subchannels to itself or other (one or more) shared APs. To improve reliability, multiple entries can be aggregated to indicate a single preferred parameter. For example, RU_TONE_SET_INDEX 1+2+3 can be used when FEEDBACK_STATUS is 0 to indicate "non-HT PPDU preferred".

[0052] The sharing AP can assign subchannels to (one or more) shared APs for sending MAP responses in order to reduce the "blank space" of the associated STA. For example, a shared AP can send MAP responses not only on its own assigned subchannel but also on any extra subchannels that are assigned. The sharing AP can assign extra subchannels to (one or more) shared APs based on information about the associated STA (e.g., location, operating bandwidth), and these extra subchannels are assigned solely for sending MAP responses.

[0053] Referring to diagram 3600 in Figure 36, the AP set includes one shared AP (AP1) and two shared APs (AP2, AP3). AP1 acquires a TXOP on the 80MHz channel and assigns the third and fourth 20MHz subchannels to AP2 and AP3, respectively. AP1 is associated with three STAs: STA1 and STA3 operating at 40MHz, and STA2 operating at 20MHz. As shown in overlapping regions 3602 and 3604, STA1 is within reach of AP2, and STA2 is within reach of AP3. AP1 assigns a primary 20MHz to AP3 for transmitting MAP responses and another 20MHz to AP2. In this case, the "blank space" between STA1 and STA2 is avoided.

[0054] Figure 37 shows a flowchart 3700 of the operation of a shared AP. The process starts in step 3702. In step 3704, a MAP Trigger frame is received. In step 3706, it is determined whether the MAP Trigger frame indicates that the next transmission is a synchronous transmission. If it is determined to be "yes", the process proceeds to step 3708, where information is obtained from the common information field and AP information list field of the MAP Trigger frame. In step 3710, the transmission is derived according to the obtained parameters. In step 3712, a DL PPDU is sent, and then the process ends in step 3714. On the other hand, if it is determined in step 3706 that the next transmission is not a synchronous transmission, i.e., an asynchronous transmission, the process proceeds to step 3716, where information about the assigned subchannel and the granted duration (i.e., remaining TXOP) is obtained. In step 3718, transmissions are made independently on the assigned subchannel for the granted duration. Then the process ends in step 3714.

[0055] In the case of C-OFDMA error recovery using Extended Interframe Space (EIFS), after sending an MPDU or A-MPDU that requires an Ack frame or BlockAck frame as a response, the sharing AP shall wait for an AckTimeout interval with the value aSIFSTime + aSlotTime + aRxPHYStartDelay, starting from the PHY-TXEND acknowledgment primitive. If the PHY-RXSTART indicator primitive does not occur during the AckTimeout interval (i.e., no ACK / BlockAck frame is received), the sharing AP shall initiate transmission to (one or more) shared APs in the EIFS since the last transmission. The sharing AP shall perform ED (Energy Detection) sensing during the EIFS and shall initiate transmission only if the detection result is idle. Referring to the flowchart 3800 in Figure 38, the EIFS 3802 can have a duration equal to the sum of aSIFSTime 3804 + EstimatedAckTxTime + AIFS (arbitration interframe space) 3806, where EstimatedAckTxTime is the predicted duration of the PPDU 3808 that transmits the BlockAck frame.

[0056] In the case of C-OFDMA error recovery using a new C-OFDMA error recovery interval, after sending an MPDU or A-MPDU that requires an Ack frame or BlockAck frame as a response, the sharing AP shall wait for an AckTimeout interval with the value aSIFSTime + aSlotTime + aRxPHYStartDelay, starting from the PHY-TXEND acknowledgment primitive. If the PHY-RXSTART indicator primitive does not occur during the AckTimeout interval (i.e., no ACK / BlockAck frame is received), the sharing AP shall initiate another transmission to (one or more) shared APs in the C-OFDMA error recovery interval since the previous transmission. The sharing AP shall perform ED (Energy Detection) sensing during C-OFDMA error recovery and shall initiate transmission only if the detection result is idle. Referring to the flow diagram 3900 in Figure 39, the C-OFDMA error recovery interval 3902 can have a duration of the sum of aSIFSTime 3904 + EstimatedAckTxTime + aSIFSTime 3906, where EstimatedAckTxTime is the estimated duration of the PPDU 3908 that transmits the BlockAck frame. If an erroneous BlockAck frame is received, the shared AP performs error recovery according to the PIFS recovery mechanism. When the transmission of BlockAck frames is aligned, the PIFS recovery mechanism will not cause collisions.

[0057] In the case of C-OFDMA error recovery using the transmission of short PPDUs, after sending an MPDU or A-MPDU that requires an Ack frame or BlockAck frame as a response, the sharing AP shall wait for an AckTimeout interval with the value aSIFSTime+aSlotTime+aRxPHYStartDelay, starting from the PHY-TXEND acknowledgment primitive. Referring to flow diagram 4000 in Figure 40, if the PHY-RXSTART. indicator primitive does not occur during the AckTimeout interval (i.e., no ACK / BlockAck frame such as BA 4002 is received), the sharing AP shall send one or more short PPDUs 4004 (e.g., RTS frames, CTS-to-self frames) to the associated STA or itself in the PIFS since the last transmission. The sharing AP, in the SIFS following a short PPDU (e.g., an RTS and CTS exchange, multiple CTS-to-self frames), initiates another transmission to (one or more) shared APs (i.e., starting with a MAP Trigger frame 4006), ensuring that the duration of the short PPDU 4004 exceeds the expected duration of the BlockAck frame 4002.

[0058] Figure 41 shows a flowchart 4100 of the operation of the shared AP in error recovery. The process starts in step 4102. In step 4104, a PPDU containing a frame requiring immediate feedback is sent. In step 4106, it is determined whether the expected ACK / BlockAck frame is received during the AckTimeout interval. If it is determined to be "yes", the process proceeds to step 4108 to determine whether the received frame is correctly decoded and demodulated. If it is determined to be "yes", the process proceeds to step 4110 to start another transmission in SIFS after the received ACK / BlockAck frame, and then the process terminates in step 4112. Otherwise, the process instead proceeds to step 4114 to start another transmission according to the PIFS recovery mechanism, and then the process terminates in step 4112. On the other hand, if in step 4106 it is determined that the expected ACK / BlockAck frame was not received during the AckTimeout interval, the process proceeds instead to step 4116 and initiates another transmission according to the C-OFDMA error recovery mechanism (i.e., as shown in the examples in Figures 38, 39, and 40), and the process terminates in step 4112.

[0059] Referring to the flow chart 4200 in Figure 42, in C-OFDMA error recovery when a MAP response is requested and an expected ACK / BlockAck frame is received, the shared AP may send a MAP response 4204 in the SIFS after the completion of the received ACK / BlockAck frame 4202. If an expected ACK / BlockAck frame 4202 is not received, the shared AP sends a MAP response 4204 in the SIFS after the completion of the expected ACK / BlockAck frame 4202. If the received ACK / BlockAck frame 4202 is recognized as invalid, the shared AP does not send a subsequent MAP response 4204. If an expected ACK / BlockAck frame 4202 is received during the AckTimeout interval, the sharing AP shall wait for the AckTimeout interval starting from the PHY-RXEND acknowledgment primitive, regardless of whether the ACK / BlockAck frame 4202 is successfully decoded or not. If no PHY-RXSTART indicator primitive occurs during the AckTimeout interval (i.e., no MAP response 4204 is received), the sharing AP will begin transmitting to (one or more) shared APs in the PIFS after the end of BlockAck frame 4202, starting with MAP Trigger frame 4206.

[0060] Referring to flow diagram 4300 in Figure 43, in C-OFDMA error recovery when a MAP response is requested and the expected ACK / BlockAck frame 4302 is not received during the AckTimeout interval, the sharing AP shall wait for the AckTimeout interval after the estimated end of the ACK / BlockAck frame 4302. If no PHY-RXSTART indicator primitive occurs during the AckTimeout interval (i.e., no MAP response 4304 is received), the sharing AP may initiate transmission to (one or more) shared APs (i.e., begin with MAP Trigger frame 4306) at the EIFS after the previous transmission (such that the shortest EIFS = aSIFSTime + EstimatedAckTxTime + PIFS), or at the PIFS after the estimated end of the ACK / BlockAck frame. To reduce complexity, a corrupted MAP response does not trigger any error recovery procedure.

[0061] Figure 44 shows a flowchart 4400 of the operation of the shared AP in C-OFDMA error recovery. The process starts in step 4402. In step 4404, a MAP Trigger frame is sent. In step 4406, it is determined whether the MAP Trigger frame indicates that a MAP response is required. If it is determined to be "yes", the process then proceeds to step 4408 and sends a PPDU indicating that an immediate feedback frame is required. In step 4410, the C-OFDMA error recovery mechanism, including the MAP response, is advanced. The process then terminates in step 4412. On the other hand, if it is determined in step 4406 that the MAP Trigger frame does not indicate that a MAP response is required, the process instead proceeds to step 4114 and the normal C-OFDMA error recovery mechanism is advanced, and the process terminates in step 4412.

[0062] Figure 45 shows flowchart 4500 of the operation of the shared AP in the C-OFDMA error recovery mechanism including MAP response. The process starts in step 4502. In step 4504, it is determined whether the expected ACK / BlockAck frame will be received during the AckTimeout interval. If it is determined to be "yes", the process then proceeds to step 4506 to determine whether the expected MAP response will be received during the AckTimeout interval after the expected end of the ACK / BlockAck frame. If it is determined to be "yes", the process then proceeds to step 4508 to start another transmission after SIFS, and the process ends in step 4510. Otherwise, the process proceeds from step 4506 to step 4512 instead to start another transmission at PIFS after the end of the ACK / BlockAck frame, and ends in step 4510. On the other hand, if in step 4504 it is determined that the expected ACK / BlockAck frame was not received during the AckTimeout interval, the process proceeds instead to step 4514 to determine whether the expected MAP response was received during the AckTimeout interval after the expected end of the ACK / BlockAck frame. If the answer is "yes", the process proceeds to step 4508 to start another transmission after the SIFS, and then the process terminates in step 4510. Otherwise, the process proceeds from step 4514 to step 4516 instead to start another transmission at a specific duration after the previous transmission, and then the process terminates in step 4510.

[0063] Figure 46 shows the configuration of a communication device 4600, e.g., a communication device, e.g., a shared AP, in various embodiments. The communication device 4600 in the schematic example of Figure 46 has at least one antenna 4602, at least one radio transmitter 4604, at least one radio receiver 4606, and circuit 4608. The circuit 4608 may include at least one controller or CPU 4610, which is used to perform tasks designed to be performed by the CPU 4610, including controlling communication with other communication devices such as associated STAs, or other APs such as shared APs, with the assistance of software and hardware.

[0064] Circuit 4608 may further include a transmit manager 4612 responsible for the transmission process of the communication device 4600. The transmit manager 4612 may include a MAP response scheduler 4614 for scheduling MAP responses, a BA parameter determination module 4616 for determining BA parameters, and a transmit type determination module 4618 for determining the transmission type.

[0065] The PPDU transmitted by the AP to the STA may contain only a limited set of necessary parameters. These necessary parameters include the PPDU format, PPDU length, AP transmit power, target RSSI, and other similar parameters. Other parameters of the PPDU conveying the BlockAck frame, such as MCS, data rate, and other similar parameters, can be determined by the STA itself according to the specified parameters. To ensure alignment, some parameters, such as the number of LTF symbols, can be determined by a unified predefined list.

[0066] The PPDU sent by the AP to the STA may contain only some of the necessary parameters, and other parameters of the BlockAck frame can be determined by the STA itself according to the indicated parameters. For example, some necessary parameters include the BlockAck type, the maximum bitmap size, and other similar parameters. Parameters that can be determined by the STA include the bitmap size and other similar parameters.

[0067] Furthermore, an STA receiving a PPDU or a new A-control field / new trigger frame that invites BlockAck, or a new MAC function that has partial parameters of the BlockAck frame, can determine the PPDU or other parameters of the BlockAck frame according to the indicated parameters.

[0068] Figure 47 shows a flowchart 4700 illustrating communication methods according to various embodiments. In step 4702, a frame containing information for subsequent transmission is generated. In step 4704, this frame is transmitted to the communication device.

[0069] Figure 48 shows a partially framed schematic diagram of a communication device 4800 that can be implemented to support multi-AP synchronous transmission. The communication device 4800 can be implemented as a shared AP, a shared AP, or an associated STA according to various embodiments.

[0070] The various functions and operations of the communication device 4800 are arranged in layers according to a hierarchical model. In this model, lower layers report to higher layers and receive instructions from higher layers, in accordance with IEEE specifications. For the sake of brevity, the details of the hierarchical model are not described in this disclosure.

[0071] As shown in Figure 48, the communication device 4800 may include a circuit 4814, at least one radio transmitter 4802, at least one radio receiver 4804, and multiple antennas 4812 (for simplification, only one antenna is depicted in Figure 48 for illustrative purposes). The circuit may include at least one controller 4806, which is used to perform tasks designed to be performed, including controlling communication with one or more other multilink devices in a MIMO radio network, with the assistance of software and hardware. At least one controller 4806 may control at least one transmit signal generator 4808 to generate frames to be transmitted to one or more other STAs, APs, or multilink devices (MLDs) through at least one radio transmitter 4802, and may further control at least one receive signal processor 4810 to process frames received from one or more other STAs, APs, or MLDs through at least one radio receiver 4804. At least one transmit signal generator 4808 and at least one receive signal processor 4810 can be separate modules of the communication device 4800, communicating with at least one controller 4806 for the functions described above. Alternatively, at least one transmit signal generator 4808 and at least one receive signal processor 4810 can be included in at least one controller 4806. 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. Data processing devices, storage devices, and other related control devices can be provided on a suitable circuit board and / or chipset.

[0072] In various embodiments, at least one radio transmitter 4802, at least one radio receiver 4804, and at least one antenna 4812 can be controlled by at least one controller 4806 during operation. Furthermore, although only one radio transmitter 4802 is shown, it will be understood that there may be two or more such transmitters.

[0073] In various embodiments, during operation, at least one radio receiver 4804, together with at least one receive signal processor 4810, forms a receiver for the communication device 4800. The receiver for the communication device 4800 provides the functions necessary for multilink communication during operation. Although only one radio receiver 4804 is shown, it will be understood that two or more such receivers may exist.

[0074] The communication device 4800 provides the functions necessary for multi-AP synchronous transmission when in operation. For example, the communication device 4800 can be a shared AP. The circuit 4814 can generate a frame containing information for subsequent transmissions when in operation. The transmitter 4802 can transmit that frame to another communication device when in operation.

[0075] Communication device 4800 and other communication devices can be APs. Information can indicate whether subsequent transmissions are asynchronous or synchronous. Information can indicate the parameters of the PPDU that convey the BlockAck frame for subsequent transmissions. Circuit 4814 can be further configured to determine parameters based on the maximum length of the bitmap in the BlockAck frame.

[0076] The information may further indicate that the subsequent transmission is a downlink (DL) transmission, and the transmitter 4802 may be configured to send data to an associated STA based on the information, and the receiver 4804 may, when operating, receive a PPDU from the associated STA based on the parameters after sending the data, conveying a BlockAck frame.

[0077] The information can further indicate that the subsequent transmission is a UL transmission, and the receiver 4804 can, in operation, receive data from the associated STA based on the information, and the transmitter 4802 can be configured to send a PPDU conveying a BlockAck frame to the associated STA based on the parameters after receiving the data.

[0078] The frame can be a MAP Trigger frame, and when the BA Soliciting Manner subfield of the MAP Trigger frame is indicated as "TRS Control field or Trigger frame", the transmitter can be configured to transmit a frame to the associated STA that has a TRS Control subfield or an MBS Control subfield indicating the parameters of the BlockAck frame.

[0079] The transmitter 4802 can be configured to send a MU-BAR trigger frame or a MAP-BAR trigger frame to the associated STA, indicating the parameters of the PPDU that transmits the BlockAck frame.

[0080] The frame can be a MAP trigger frame, which contains a request for a MAP response from another communication device, and the receiver 4804 can receive a MAP response from the other communication device when in operation, which contains estimated parameters for the expected BlockAck frame for a subsequent transmission. The transmitter 4802 can be configured to send another MAP trigger frame to the other communication device, which contains parameters for the PPDU that carries the BlockAck frame, such that the parameters are determined based on the estimated parameters in the MAP response, and the transmitter 4802 can be further configured to send data to the associated STA such that the data contains parameters for the PPDU that carries the BlockAck frame. When an expected Ack frame or BlockAck frame is received within an AckTimeout interval after a previous transmission, and no MAP response is received within another AckTimeout interval starting from a PHY-RXEND acknowledgment primitive, the transmitter 4802 can be configured to initiate another transmission to the other communication device in a PIFS after the end of the received Ack frame or BlockAck frame. If an expected Ack frame or BlockAck frame is not received within the AckTimeout interval after the previous transmission, and a MAP response is not received within another AckTimeout interval after the estimated end of the expected Ack frame or BlockAck frame, the transmitter 4802 may be configured to initiate another transmission to another communication device in the PIFS after the end of the received Ack frame or BlockAck frame, or in the EIFS after the previous transmission.

[0081] The transmitter 4802 can be configured to transmit an MPDU or A-MPDU that requires an Ack frame or BlockAck frame as a response, and the transmitter 4802 can be further configured to initiate another transmission to another communication device for a time duration after the transmission of the MPDU or A-MPDU if an Ack frame or BlockAck frame is not received within the AckTimeout interval after the transmission of the MPDU or A-MPDU. The time duration can be Extended Interframe Space (EIFS) = SIFS time + EstimatedAckTxTime + AIFS, or C-OFDMA Error Recovery Interval = aSIFSTime + EstimatedAckTxTime + aSIFSTime, where EstimatedAckTxTime is the expected duration of the PPDU that carries the BlockAck frame. The transmitter 4802 can be further configured to transmit one or more short PPDUs to the associated STA or return them to the communication device in the PIFS after the transmission of an MPDU or A-MPDU, and another transmission may be initiated in the SIFS after the transmission of one or more short PPDUs.

[0082] This disclosure can be implemented by software, by hardware, or by software working in conjunction with hardware. Each functional block used in the description of each embodiment above 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 combination of LSIs. An LSI can be formed individually as multiple chips, or as a single chip containing some or all of the functional blocks. An LSI can include data input / output units coupled to itself. Depending on the degree of integration, LSIs are also called ICs, system LSIs, super LSIs, or ultra LSIs. However, the technology for implementing integrated circuits is not limited to LSIs and can be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, a Field Programmable Gate Array (FPGA), which can be programmed after the manufacture of the LSI, or a reconfigurable processor, which can reconfigure the connections and settings of circuit cells located inside the LSI, can also be used. This disclosure can be implemented as digital or analog processing. If future integrated circuit technology replaces LSIs as a result of advancements in semiconductor technology or other derivative technologies, then functional blocks can be integrated using that future integrated circuit technology. Biotechnology can also be applied.

[0083] This disclosure can be implemented by any type of device, apparatus, or system having communication capabilities, referred to as a communication device.

[0084] Some non-exclusive 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-readers, telemedicine devices, vehicles providing communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

[0085] Communication devices are not limited to portable or mobile devices, but may include any type of non-portable or fixed device, device, or system, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other "things" in the "Internet of Things (IoT)" network.

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

[0087] A communication device may include devices such as controllers or sensors coupled to a communication device that performs the communication functions described in this disclosure. For example, a communication device may include a controller or sensor that generates control signals or data signals used by the communication device that performs the communication functions of the communication device.

[0088] Communication devices may further include base stations, access points, and any other devices, devices, or systems that communicate with or control infrastructure equipment, such as the devices in the non-limiting examples above.

[0089] A non-exclusive example of a station may be a station included in a first group of stations belonging to a multilink station logical entity (i.e., an MLD), where a station among the first group of stations shares a common medium access control (MAC) data services interface to a higher layer as part of the first group of stations belonging to the multilink station logical entity, and the common MAC data services interface is associated with a common MAC address or traffic identifier (TID).

[0090] Thus, it can be understood that this embodiment provides a communication device and communication method that supports multi-AP synchronous transmission.

[0091] While the detailed description of embodiments of the present invention presented exemplary embodiments, it should be understood that a vast number of variations exist. Furthermore, it should be understood that the exemplary embodiments are examples and are not intended to limit in any way the scope, applicability, operation, or configuration of the present disclosure. Rather, the detailed description so far provides a useful guide for carrying out the exemplary embodiments for those skilled in the art. It should be understood that the function and organization of the steps and methods of operation described in the exemplary embodiments, and the modules and structures of the devices described in the exemplary embodiments, can be modified in various ways without departing from the scope of the subject matter set forth in the appended claims.

Claims

1. A communication device that performs coordinated transmission with another communication device, A receiver that receives from the other communication device a frame containing information indicating whether the type of subsequent transmission, which is the transmission of data between the other communication device and the STA associated with the other communication device, is asynchronous or synchronous, If the type of subsequent transmission is synchronous, a circuit that causes the other communication device to control all frequency resources, A communication device equipped with the following features.

2. The communication device according to claim 1, wherein the circuit controls the frequency resources used by the communication device for the subsequent transmission when the type of subsequent transmission is asynchronous.

3. The aforementioned communication device performs Cooperative Orthogonal Frequency Division Multiple Access (C-OFDMA). The communication device according to claim 1.

4. The aforementioned communication device and the aforementioned other communication device are access points (APs). The communication device according to claim 1.

5. The information indicates the parameters of the physical layer protocol data unit (PPDU) that transmits the block acknowledgment (BlockAck) frame for the subsequent transmission. The communication device according to claim 1.

6. The aforementioned parameters are determined based on the maximum length of the bitmap in the BlockAck frame. The communication device according to claim 5.

7. The information indicates that the subsequent transmission is a downlink (DL) transmission. The communication device according to claim 1.

8. The information indicates that the subsequent transmission is an uplink (UL) transmission. The communication device according to claim 1.

9. The frame is a MAP Trigger frame, the MAP Trigger frame includes a request for a MAP response from the communication device, and the MAP response includes estimated parameters for the expected BlockAck frame for the subsequent transmission. The communication device according to claim 1.

10. A communication method using a communication device that performs coordinated transmission with another communication device, The steps include receiving a frame indicating whether the type of information in a subsequent transmission, which is the transmission of data between the other communication device and the STA associated with the other communication device, is asynchronous or synchronous, The steps include transmitting the frame to the other communication device, If the type of subsequent transmission is synchronous, the step is to have the other communication device control all frequency resources. A communication method that includes this.

Images