integrated circuits

Abstract

To facilitate providing joint transmission and re-transmission communication in multi AP networks.SOLUTION: An integrated circuit mounted on an AP controls the processes for: generating a data frame including multi AP transmission data, and a multi AP transmission packet ID allocated to the multi AP transmission data; transmitting the data frame to slave Aps, and distributing a first multi AP transmission trigger frame including the allocated multi AP transmission packet ID for starting multi AP transmission; and transmitting a second multi AP trigger frame including the allocated multi AP transmission packet ID to the slave APs without re-distributing a failed MPDU to the slave APs when a communication device determines that it fails to receive one or more MPDUs of the data frame undergoing joint transmission to the communication device in the multi AP transmission by the AP and the slave APs.SELECTED DRAWING: Figure 31

Description

[Technical Field]

[0001] The present disclosure relates generally to integrated circuits on communication devices for electronic devices and systems, and more particularly to joint re-transmission in multi-AP networks. [Background technology]

[0002] Wireless networks that communicate via multi-AP joint transmission allow electronic devices to communicate in the network with joint transmissions sent to multiple electronic devices. Such networks have advantages over other wireless networks in which wireless communication is limited to a single transmission to one electronic device. Summary of the Invention

[0003] One non-limiting, exemplary embodiment facilitates providing joint transmission and retransmission communications in a multi-AP network, for example, communications including joint retransmissions between two or more access points (APs) and one or more wireless stations (STAs).

[0004] One exemplary embodiment is an AP that includes, during operation, a receiver that receives a joint transmit (JT) trigger frame from another access point (AP) indicating a MAC protocol data unit (MPDU) to be jointly transmitted to a communication device, and a local memory that stores one or more MPDUs previously transmitted to the communication device.

[0005] It should be noted that the general or specific embodiments may be realized as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.

[0006] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. These benefits and / or advantages may be obtained individually by various embodiments and features of the specification and drawings. However, not all of these features need to be present to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0007] In the accompanying drawings, like reference numerals indicate identical or functionally similar elements throughout the different views. The accompanying drawings, together with the following detailed description, are incorporated into and form a part of this specification. The accompanying drawings illustrate various embodiments and serve to explain various principles and advantages according to the present embodiments. Those skilled in the art will appreciate that elements in the drawings are illustrated for simplicity and clarity and have not necessarily been drawn to scale. [Figure 1] FIG. 1 illustrates a wireless network including a multi-AP system according to an exemplary embodiment. [Figure 2A] FIG. 1 illustrates a multi-AP system shown as an enterprise network, according to an exemplary embodiment. [Figure 2B] FIG. 1 illustrates a multi-AP system, shown as a home or office network, according to an exemplary embodiment. [Figure 2C] FIG. 1 illustrates a multi-AP system shown as a master-slave configuration, according to an exemplary embodiment. [Figure 3] 1 illustrates a MAC Protocol Data Unit (MPDU) according to an exemplary embodiment. [Figure 4] FIG. 1 illustrates a message sequence for joint transmission in a multi-AP system, according to an example embodiment. [Figure 5A] FIG. 1 illustrates a data frame used to encapsulate JT data, according to an exemplary embodiment. [Figure 5B] FIG. 1 illustrates a data frame used to encapsulate JT data, according to an exemplary embodiment. [Figure 6] 1 illustrates a first table showing data frames, protocol names and payload types, and a second table showing AP cooperation packet types, according to an example embodiment. [Figure 7] FIG. 1 illustrates a joint transmission between a master AP, a slave AP, and a target STA according to an example embodiment. [Figure 8] FIG. 1 illustrates a JT trigger frame according to an exemplary embodiment. [Figure 9] FIG. 1 illustrates a message sequence for a joint transmission session between a master AP and a slave AP in a multi-AP system, according to an exemplary embodiment. [Figure 10] FIG. 1 illustrates AP Coordination Action frames exchanged over the air to negotiate or tear down a joint transmission session, according to an example embodiment. [Figure 11] FIG. 1 illustrates an Ethernet frame encapsulating JT data and AP coordinated action frames, according to an exemplary embodiment. [Figure 12] FIG. 1 illustrates a trigger frame for joint transmission to a target STA according to an exemplary embodiment. [Figure 13] FIG. 1 illustrates a communication exchange in which the master AP does not participate in joint transmissions, according to an exemplary embodiment. [Figure 14] FIG. 1 illustrates an action frame used by an AP in an information inquiry phase to gather information from another AP, according to an exemplary embodiment. [Figure 15] FIG. 1 illustrates a frame for data sharing from a master AP to a slave AP according to an exemplary embodiment. [Figure 16] FIG. 1 illustrates a JT data frame as an aggregated MAC protocol data unit (A-MPDU) according to an exemplary embodiment. [Figure 17] FIG. 1 illustrates a frame as an Aggregated MAC Protocol Data Unit (A-MPDU) used for data sharing to a slave AP according to an example embodiment. [Figure 18] 1 illustrates a joint transmission trigger frame according to an exemplary embodiment. [Figure 19] FIG. 1 illustrates an example of distributed MU-MIMO joint transmission to two STAs, both associated with a master AP, according to an example embodiment. [Figure 20] FIG. 1 illustrates a JT data frame, an acknowledgement (ACK or Ack) frame, and a BlockAck frame according to an exemplary embodiment. [Figure 21] FIG. 1 illustrates a joint transmission in which a STA fails to receive a JT data frame and the master AP repeats the joint transmission procedure, according to an exemplary embodiment. [Figure 22] FIG. 1 illustrates a joint transmission in which a STA fails to receive a JT data frame, the slave AP processes the Ack frame, and the master AP repeats the joint transmission without repeating the data distribution, according to an exemplary embodiment. [Figure 23] FIG. 1 illustrates a joint transmission in which a STA fails to receive JT data and a slave AP processes a BlockAck frame and deletes the JT data, according to an exemplary embodiment. [Figure 24] FIG. 1 illustrates joint transmission and error recovery when a STA fails to receive JT data when a master AP fails to receive a BlockAck frame, according to an exemplary embodiment. [Figure 25] 1 illustrates an AP cooperation information response frame and a table containing deletion reasons according to an example embodiment. [Figure 26] FIG. 1 illustrates wireless transmissions between a wireless network and STAs in a backhaul BSS and a fronthaul BSS according to an example embodiment. [Figure 27] FIG. 1 illustrates a joint transmission in which a STA fails to receive JT data and a slave AP uses a JT trigger frame to delete a JT MPDU, according to an exemplary embodiment. [Figure 28]FIG. 1 illustrates a joint transmission in which a STA fails to receive JT data and a slave AP relays information about an acknowledgement frame to a master AP according to an exemplary embodiment. [Figure 29] FIG. 1 illustrates an AP cooperation information response frame according to an example embodiment. [Figure 30] FIG. 1 illustrates a JT trigger frame containing instructions to flush buffers, according to an exemplary embodiment. [Figure 31] FIG. 1 illustrates a joint transmission where a STA fails to receive JT data and non-immediate BlockAck is supported for the joint transmission, according to an exemplary embodiment. [Figure 32] FIG. 1 illustrates distributed MU-MIMO joint transmission where a STA fails to receive JT data and non-immediate BlockAck is supported for joint transmission, according to an example embodiment. [Figure 33] FIG. 1 illustrates a joint transmission in which a STA fails to receive JT data and a special-purpose frame instructing a slave AP to delete the stored JT data, according to an exemplary embodiment. [Figure 34] FIG. 1 illustrates a table of AP collaborative session action field values ​​and an AP collaborative data flash frame according to an example embodiment. [Figure 35] 1 illustrates an electronic device according to an exemplary embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0008] Electronic devices can be configured to transmit and receive joint transmission (JT) data in a multi-AP network. These electronic devices have many advantages over conventional electronic devices that are limited to a single transmission to a single electronic device. However, performing joint transmission in a multi-AP network presents many technical challenges.

[0009] Existing 802.11 basic service sets (BSSs) operate as standalone units. Each BSS AP provides wireless communication services only to its associated wireless stations (STAs). The data rate an AP can provide over a wireless link to associated STAs depends on the modulation and coding scheme (MCS) used for that link, which in turn depends on the STAs' signal-to-interference-and-noise ratio (SINR). Typically, a higher MCS can be achieved with a higher SINR, whereas only a lower MCS may be possible at low SINR levels. While the signal ratio can be controlled by the AP in a standalone BSS by adjusting its transmit power, the interference experienced by STAs is much more difficult to control. This problem is particularly true for STAs that reside at the edge of the network and are within the wireless range of multiple BSSs (also known as overlapping BSS (OBSS) zones). A useful signal in one BSS is essentially interference to STAs in another BSS.

[0010] Multi-AP coordination (e.g., cooperation between APs in neighboring BSSs) can be used as an effective method to improve the SINR of member STAs. Such a scheme is made possible by the proliferation of APs, such as in managed networks (e.g., enterprise networks, stadium settings, etc.) or high-density AP deployments in residential networks (e.g., with multi-AP home mesh networks).

[0011] The various multi-AP cooperation schemes can be divided into two general groups. The first group includes schemes that attempt to reduce interference to the OBSS through transmit power control, coordinated beamforming, coordinated null forming, coordinated scheduling, etc. The second group includes schemes that attempt to increase the signal level at the STA through synchronized transmission by multiple APs to the same STA. Schemes in the second group may be known as multi-AP joint processing or multi-AP joint transmission or distributed MU-MIMO.

[0012] Joint transmission not only improves signal level but also reduces interference by converting an interfering signal into a desired signal. Thus, exemplary embodiments solve technical problems associated with STAs in overlapping BSSs or multi-AP systems by reducing interference to the STAs and improving the SINR for the STAs. These problems include how to distribute and synchronize jointly transmitted data (joint MU-MIMO data) between slave APs, as well as other problems described herein.

[0013] One exemplary embodiment is an AP that includes, in operation, a receiver that receives a joint transmit (JT) trigger frame from another access point (AP) indicating a MAC protocol data unit (MPDU) to be jointly transmitted to a communication device, and a local memory that stores one or more MPDUs previously transmitted to the communication device.

[0014] Another exemplary embodiment is an access point (AP) that includes circuitry that, during operation, determines that a communication device fails to receive one or more MAC protocol data units (MPDUs) jointly transmitted to the communication device by the AP and another AP, and a transmitter that, during operation, transmits a joint transmission (JT) trigger frame to the other AP without re-distributing the failed MPDUs to the other AP.

[0015] 1 illustrates a wireless network including a multi-AP system 100 according to an exemplary embodiment. For example, system 100 includes three BSSs (shown as BSS1, BSS2, and BSS3). Each BSS has at least one AP (shown as AP1, AP2, and AP3). Multiple STAs (shown as STA1 through STA5) are distributed throughout the system. STA1 resides in a single BSS (BSS1), STA2 resides in three overlapping BSSs (BSS1 through BSS3), STA3 resides in two overlapping BSSs (BSS1 and BSS3), STA4 resides in two overlapping BSSs (BSS2 and BSS3), and STA5 resides in a single BSS (BSS2).

[0016] In Figure 1, STA2 is associated with AP3, but three APs (AP1, AP2, and AP3) can coordinate their transmissions to simultaneously transmit to STA2. This simultaneous transmission increases the SINR level at STA2 and facilitates the use of a higher MCS, which translates into higher throughput for STA2.

[0017] While multi-AP cooperation schemes typically utilize some type of time synchronization among participating APs, the level of synchronization utilized is highest for joint transmission, particularly in the case of distributed MU-MIMO. Thus, one or more exemplary embodiments implement joint transmission where one AP (called the master AP) provides a synchronization signal and other participating APs (called slave APs) are within range of the master AP. In FIG. 1 , AP3 is the master AP, while AP1 and AP2 are slave APs. The master AP may be known by alternative names such as a coordinating AP, a joint transmission (JT) AP, or a multi-AP controller, while the slave AP may be known as a multi-AP device, a coordinated AP, or the like.

[0018] In an exemplary embodiment, as described in more detail below, joint transmission involves all participating APs transmitting the same signal to the STA, which includes MAC layer specific fields being identical for all participating APs.

[0019] 2A illustrates a multi-AP system 200, shown as an enterprise network, according to an exemplary embodiment. For example, the system includes multiple APs (shown as AP1 through AP8) broadcasting with overlapping transmissions. Each AP operates on a respective channel (Ch). For example, AP1 operates on Ch36, AP2 operates on Ch52, AP3 operates on Ch149, AP4 operates on Ch44, AP5 operates on Ch56, AP6 operates on Ch161, AP7 operates on Ch48, and AP8 operates on Ch60.

[0020] In enterprise networks, AP locations and frequency allocations are carefully planned during deployment to maximize capacity. As shown in Figure 2A, adjacent APs use non-overlapping channels to minimize inter-BSS interference. APs can use high-gain directional antennas with narrow beamwidths. Adjacent APs may not be within wireless range of each other. Multiple or all APs can use the same service set identifier (SSID). Furthermore, APs may be connected using Ethernet and configured and / or controlled by a central AP controller. Most edge STAs are within the coverage of at least two APs. AP-to-AP communication can use, for example, Ethernet or out-of-band mesh wireless direct links. Even though adjacent APs are assigned non-overlapping primary channels, inter-BSS interference inevitably exists in the OBSS zone when wideband channels are used. Because most enterprise networks are centrally managed and coordination between APs is easier, enterprise networks are prime candidates for joint transmission systems.

[0021] 2B illustrates a multi-AP system 230, shown as a home or office network, according to an exemplary embodiment. For example, the system includes multiple APs (shown as AP1-AP3) broadcasting with overlapping transmissions. Each AP operates on a respective channel. For example, AP1 operates on Ch36, AP2 operates on Ch149, and AP3 operates on Ch52.

[0022] A multi-AP system (e.g., Wi-Fi EasyMesh) is an exemplary configuration for providing Wi-Fi coverage throughout an area, such as a home or office. AP locations and frequency assignments are planned to maximize coverage. For example, one AP may act as a multi-AP controller, while the remaining APs may act as multi-AP agents. APs may be expected to be within the wireless coverage of at least one other AP. A backhaul BSS is set up for inter-AP signaling. The backhaul BSS may use an SSID different from the fronthaul SSID. Most edge STAs are within the coverage of at least two APs. Furthermore, inter-AP communication can use direct wireless links or a mix of wireless and wired links. Such multi-AP home or small office networks are also good candidates for joint transmission systems.

[0023] 2C illustrates a multi-AP system 260 shown in a master-slave configuration according to an exemplary embodiment. For example, the system includes a master AP 270, two slave APs 280 and 282, and a STA 284. Inter-AP communication occurs over link 290, and AP-to-STA communication occurs over link 292.

[0024] For joint transmission, the AP owns the transmit data (upper layer data) to be jointly transmitted to the STAs prior to the actual joint transmission. However, in one or more exemplary embodiments, owning the transmit data may not be sufficient to realize the SINR gain of joint transmission. The actual data symbols transmitted over the air need to be synchronized among participating APs, such as multiple APs or all APs. This means that the PHY layer and MAC layer processing of the transmit data is the same among participating APs. Exemplary embodiments include systems, devices, and methods for distributing and synchronizing data for multi-AP joint transmission.

[0025] In one or more exemplary embodiments, the joint transmission occurs in two phases: distribution of JT data to the slave AP and joint transmission to the target STA.

[0026] In the first phase (distribution of jointly transmitted data to the slave APs), the data to be jointly transmitted is distributed to the participating slave APs via AP-to-AP links, such as link 290 in FIG. 2C, before the actual joint transmission. The distribution may be performed via a wireless backhaul link between the APs or via a wired backhaul link (e.g., Ethernet) between the APs. If wireless backhaul is used, the slave AP may be associated with the master AP in a separate BSS set up by the master AP for communication between the APs before starting the joint transmission. The wireless channel used for the backhaul link between the APs may be different from the fronthaul link between the APs and the target STA.

[0027] In the second phase (joint transmission to the target STA), the actual joint transmission by two or more participating APs to the target STA occurs over a link, such as wireless link 292 in FIG. 2C. The joint transmission may be preceded by a synchronization signal from the master AP over link 290, sometimes referred to as a slave trigger frame or joint transmission (JT) trigger frame. In some scenarios, the master AP may participate in the joint transmission, while in some scenarios, the master AP may not participate in the joint transmission and only the slave APs may participate in the joint transmission. Different sets of APs may be involved in the joint transmission to different target STAs.

[0028] 3 illustrates a jointly transmitted MAC Protocol Data Unit (MPDU) 300 according to an exemplary embodiment. The MPDU includes a MAC Header and a Frame Body. The MAC Header includes Frame Control, Duration, Address 1 (Receiver Address (RA)), Address 2 (Transmitter Address (TA)), Address 3 (BSSID), Sequence Control, QoS Control, and HT Control. The Frame Body includes a Data Payload, MIC, and FCS. The Address 3 field carries the BSSID if the data frame carries an A-MSDU. Otherwise, the Address 3 field carries the Source Address (SA), i.e., the MAC address of the device that is the source of the data payload.

[0029] To achieve the SINR gain of joint transmission, the actual data symbols transmitted over the air are synchronized between participating APs. Furthermore, the PHY layer and MAC layer processing of the transmission are the same between participating APs. Typically, for normal transmissions (e.g., non-joint transmissions), an upper layer (e.g., IP layer) passes the data payload to be transmitted (e.g., IP packet) to the MAC layer, which performs MAC layer processing such as prepending a MAC header, adding an FCS, and MAC padding as needed, to generate a MAC Protocol Data Unit (MPDU) 300. If protection is enabled, the data payload may further undergo an encryption procedure, which results in the addition of a CCMP Header field and an MIC field to the MAC frame body. The MPDU is then passed to the PHY layer for PHY layer processing, such as prepending a PHY preamble, applying PHY coding, adding PHY padding, etc., to generate a PHY Protocol Data Unit (PPDU), which is finally sent over the air.

[0030] For joint transmission, participating APs must know the MAC and PHY parameters that apply to the data payload. Additionally, some fields are locally generated at the MAC layer. Some fields, such as Frame Control, Address 2 (TA), Address 3 (BSSID), QoS Control, and HT Control, may be overwritten by the MAC layer of the slave AP to match those generated by the master AP, while some fields, such as Sequence Control and CCMP Header, vary for each MPDU and are typically generated locally at each AP. Therefore, these fields are more difficult to synchronize between APs. Furthermore, at the MAC layer, two or more MPDUs may be aggregated to form an A-MPDU (Aggregated MPDU), and one MPDU may constitute an S-MPDU (Single MPDU). To synchronize the data to be jointly transmitted between the MAC layers of all participating APs, the master AP can generate the actual MAC layer A-MPDU or S-MPDU and distribute it to all participating slave APs. The sequence control field in the MPDU is generated by the master AP, and the same number space is used for the sequence number subfield of the sequence control field for both direct transmission from the master AP to the target STA (i.e., single AP transmission) and joint transmission. If encryption is enabled, the master AP also encrypts the data payload and appends a MIC field. In this case, joint transmission (JT) data refers to the MAC layer data that is jointly transmitted.

[0031] In some cases, the master AP may not be involved in the actual joint transmission phase (e.g., only the slave APs may participate in the joint transmission). This can occur when the master AP is implemented as a central controller and is remote from the target STAs. In this case, the target STAs are associated with one of the slave APs and not with the master AP.

[0032] In such a case where the target STA is associated with a slave AP, during the data distribution phase, the master AP sets the MAC header fields of the MPDU 300 so that the MPDU appears to have been generated by the slave AP with which the target STA is associated. For example, the Address 2 (TA) field and Address 3 (BSSID) field are set to the MAC address of the slave AP. The master AP also queries the slave AP for the next sequence control to be used and, optionally, the CCMP packet number (PN) and encryption key ID to be used for transmission to the target STA, and sets these fields in the MPDU 300 accordingly. The sequence control field in the MPDU in this case is generated by the slave AP, and the same number space is used for the sequence number subfield of the sequence control field for both direct transmissions (i.e., single AP transmissions) and joint transmissions from the slave AP to the target STA.

[0033] FIG. 4 is a message sequence 400 for joint transmission in a multi-AP system, according to an example embodiment.

[0034] In distributed wireless networks such as 802.11 WLANs, access to the wireless channel is controlled by CSMA / CA, making it difficult to predict the exact transmission time. Similarly, failed transmissions and retransmissions make it difficult to maintain the order of transmissions. For this reason, in joint transmissions, it may be advantageous to separate the data distribution phase from the joint transmission phase.

[0035] As shown in Figure 4, joint transmission is performed in two phases: distribution of joint transmission data to the slave AP and joint transmission to one or more target STAs. In the first phase, one or more joint transmission data are distributed to the slave AP (e.g., via wireless backhaul). Each joint transmission data is assigned a unique ID. In the second phase, the master AP initiates the joint transmission by transmitting a JT trigger frame. This frame carries a unique ID that identifies the joint transmission data jointly transmitted by all participating APs.

[0036] 4 shows an example message sequence for joint transmission in which the data distribution phase 410 is separated from the joint transmission phase 420. During the data distribution phase 410, the master AP distributes one or more joint transmission (JT) data to the slave APs. The JT data in this case may be actual S-MPDUs or A-MPDUs to be jointly transmitted, encapsulated within another data frame addressed to the slave AP. To reduce the overhead of distributing the JT data, the encapsulated data frame may be transmitted to the slave AP as a groupcast transmission instead of a unicast transmission. The master AP can also distribute different JT data to different slave APs simultaneously using a multi-user (MU) PPDU format.

[0037] To uniquely identify each JT data, the master AP assigns a unique ID, sometimes called a JT Packet ID, to each JT data. When each slave AP receives the encapsulated JT data, it de-encapsulates the JT data indexed by the JT Packet ID and stores it in its local memory. To ensure that the slave AP stores the JT data rather than immediately forwarding it to the target STA, data frames encapsulating the JT data can be addressed to the slave AP by setting RA to the MAC address of the slave AP. If a four-address MAC header is used for data frames to the slave AP, both RA (Address 1) and DA (Address 3) can be set to the MAC address of the slave AP. Due to strict time synchronization requirements for joint transmission and faster retrieval, JT data frames may be stored in a separate memory (e.g., different from the local EDCA queue).

[0038] In the joint transmission phase 420, the master AP initiates joint transmission by sending a JT trigger frame to the slave AP. The JT trigger frame provides time synchronization to the slave AP. In addition, the JT trigger frame also carries the JT packet ID of the JT data to be jointly transmitted. Upon receiving the JT trigger frame, each slave AP retrieves (fetches) the JT data corresponding to the JT packet ID from its local memory and transmits a JT PPDU constructed from the JT data.

[0039] 5A and 5B are data frames used to encapsulate JT data according to an example embodiment.

[0040] 5A shows a data frame 500 transmitted by a master AP, encapsulating JT data, in this case an S-MPDU, within the frame body of the data frame 500. The S-MPDU consists of an MPDU delimiter, the actual MPDU, and padding, if necessary. Each joint transmission is assigned a unique ID (JT packet ID). In this case, the JT packet ID uniquely identifies the S-MPDU.

[0041] 5B shows a data frame 550 transmitted by a master AP, encapsulating JT data, in this case an A-MPDU, within the frame body of the data frame 550. An A-MPDU consists of two or more A-MPDU subframes and, optionally, end-of-frame (EOF) padding. Each A-MPDU subframe shares the same format as an S-MPDU. In this case, a JT packet ID uniquely identifies the A-MPDU.

[0042] If encryption is enabled, each of the MPDUs in the JT data is also encrypted by the master AP before encapsulation within the data frame 500 or 550 .

[0043] Upon receiving the encapsulated JT data, each slave AP de-encapsulates the JT data indexed by the JT packet ID and stores it in its local memory. Due to the strict time synchronization requirements for joint transmission, the JT data frames may be stored in a separate memory (e.g., different from the local EDCA queue) for faster retrieval.

[0044] The slave AP does not immediately forward the received JT data to one or more target STAs. To ensure this, if a 4-address MAC header is used for data frames to the slave AP, both RA (address 1) and DA (address 3) are set to the MAC address of the slave AP.

[0045] FIG. 6 illustrates a data frame 600, a first table 610 illustrating the encoding of the payload type field, and a second table 620 illustrating the encoding of the AP cooperation packet type field, according to an example embodiment.

[0046] Data frame 600 encapsulates JT data during the data distribution phase (e.g., as described in 410 in FIG. 4). In this example, the frame body of data frame 600 carries an Ethertype 89-0d frame with the Payload Type field set to 5, “AP Coordination,” to distinguish it from other encapsulation types. Ethertype 89-0d is an Ethertype originally assigned for encapsulating IEEE 802.11 frames within Ethernet frames. The payload of an Ethertype 89-0d frame with the Payload Type set to “AP Coordination” can carry JT data in the Packet Content field if the AP Coordination Packet Type field is set to 0, 1, or 2, as shown in table 620. The Destination MAC Address carries the MAC address of the target STA (e.g., the target of the joint transmission). The JT Packet ID is a unique ID assigned to the JT data, while the Packet Length field indicates the size of the JT data carried in the Packet Content field. If 802.11 data frames are used exclusively to encapsulate JT data, the Sequence Number subfield 630 in the Sequence Control field 632 of the host 802.11 data frame may be used as an implicit JT Packet ID, and the JT Packet ID field may be omitted in the Ethertype 89-0d frame body.

[0047] To ensure that the slave AP stores the JT data rather than immediately forwarding it to the target STA, the data frame 600 encapsulating the JT data is addressed to the slave AP by setting the RA field of the MAC header to the MAC address of the slave AP. If a four-address MAC header is used, both RA (Address 1) and DA (Address 3) are set to the MAC address of the slave AP.

[0048] FIG. 7 illustrates a joint transmission 700 between a master AP, a slave AP, and a target STA according to an example embodiment.

[0049] In the joint transmission phase (e.g., as described in 420 in FIG. 4), the master AP initiates the joint transmission by sending a JT trigger frame 710 to the slave AP. In addition to PHY and MAC parameters used for synchronization, the JT trigger frame also carries the JT packet ID of the JT data to be jointly transmitted. When the MAC layer of each slave AP receives the JT trigger frame identifying that slave AP as an AP participating in the joint transmission, it retrieves the JT data corresponding to the JT packet ID from local memory and passes it to the PHY layer. The PHY layer constructs a JT PPDU from the JT data and then transmits the JT PPDU SIFS (Short Interframe Space) after the end of the JT trigger frame. The master AP also constructs a JT PPDU from the JT data corresponding to the JT packet ID and transmits the JT PPDU SIFS after the end of the JT trigger frame. Since channel conditions may differ for different APs, each slave AP may need to take channel conditions into account and transmit a JT PPDU only if the channel is considered idle during the SIFS after the end of the JT trigger frame, except that the NAV (Network Allocation Vector) set due to the master AP or target STA's transmission may be ignored. As for the target STA, upon receiving the JT data, it may not even realize that multiple APs were involved in the transmission. As far as the target STA is concerned, this is just another transmission from the master AP or the AP with the MAC address that appears in the TA Address (Address 2) field of the frame. If the reception is successful, the target STA sends an acknowledgement frame (ACK or Block Ack) to the AP with the MAC address that appears in the TA Address (Address 2) field.

[0050] 8 is a JT trigger frame 800 according to an example embodiment. Each User Info field carries information of a slave AP and a set of target STAs.

[0051] The MAC Address of Slave APs field identifies the slave APs participating in the joint transmission for a particular set of STAs. If only a single slave AP is involved in the joint transmission, it may be omitted, and the slave AP is identified by the RA field in the MAC header. The AID12 field in each user information field may be set to a special value (e.g., 2047) to distinguish JT trigger frames from other trigger frames used to request uplink OFDMA transmissions.

[0052] The JT Packet ID field identifies the MPDU carried (stored / stored) in the JT PPDU. In the case of an S-MPDU, this may be the value of the Sequence Control field of the S-MPDU. If identical data is jointly transmitted (transmit diversity), the field value may be the same for different slave APs. Alternatively, if different data is jointly transmitted (D-MIMO), the field value may be different for different slave APs.

[0053] In addition, the Joint Transmission PHY Layer Info field specifies additional PHY parameters used to encode the JT PPDU. For example, for transmit diversity joint transmission (also known as non-coherent joint transmission), it is desirable to use different cyclic shift diversity (CSD) values ​​for the transmit antennas (transmit chains) of different APs participating in joint transmission to the target STA using the same spatial stream to prevent unintended beamforming. In such a case, the Joint Transmission PHY Layer Info field may specify the CSD value to be used for the transmit chain by the slave AP. The master AP may select the CSD value to be used for each transmit chain of each slave AP and notify the slave AP of the exact CSD value. Alternatively, instead of signaling the exact CSD value, the master AP assigns an index # to the transmit chain involved in the joint transmission and notifies the slave AP of the index # in the Joint Transmission PHY Layer Info field. The slave AP selects the CSI value according to the index # by referencing a stored / stored table of CSD values. If the slave AP transmits using more than one antenna, the index # may be the starting index with the subsequent antenna using the CSD value corresponding to the next index # in the table. Target STA Information carries information related to joint transmission by the slave AP to one or more target STAs. Joint Transmission Information identifies the stored / stored data to be transmitted and the spatial streams for the target STAs.

[0054] Furthermore, the Spatial Stream Allocation field indicates the spatial streams allocated to each target STA and is present only in the case of MIMO joint transmission. The Starting Spatial Stream field indicates the first spatial stream allocated to the STA, and the Number of Spatial Streams field indicates the total number of consecutive spatial streams, including the first spatial stream, allocated to the STA.

[0055] FIG. 9 is a message sequence 900 for a joint transmission session between a master AP and a slave AP in a multi-AP system, according to an example embodiment.

[0056] When joint transmissions are expected to occur for more than one frame, an exemplary embodiment sets up a joint transmission session between the master AP and participating slave APs before the actual joint transmission. During the joint transmission session negotiation, the master AP and slave AP exchange information about the target STAs involved in the joint transmission. The master AP and slave AP also specify the joint transmission parameters expected to be used throughout the session (e.g., the channel to be used, the PPDU format (e.g., HT, VHT, or HE), the precoding scheme for MU-MIMO, etc.). Each joint transmission session is identified by a unique Session ID. The master AP initiates the joint transmission session setup by sending an AP Coordination Session Request frame to the slave AP. If the slave AP accepts this request, the slave AP sends an AP Coordination Session Response frame with the Status Code field set to Accept back to the master AP. The master AP repeats this process for each slave AP participating in the joint transmission. To terminate the session, the master AP sends an AP Coordination Session Teardown frame to the slave AP.

[0057] 10 illustrates AP collaboration action frames exchanged between APs to negotiate or tear down a joint transmission session according to an example embodiment. The figure shows an AP collaboration session request 1000, an AP collaboration session response 1002, an AP collaboration session teardown 1004, a table 1010 with AP collaboration session action field values, and a table 1020 with AP collaboration type field values.

[0058] A new category of action action frames is defined for multi-AP cooperation and is indicated in the Category field. Five new action frames are defined for AP-to-AP communication related to multi-AP cooperation, three of which are used for session setup / teardown (indicated by the value of the "AP Cooperation Session Action" field listed in table 1010). Sessions may be set up for various types of multi-AP cooperation schemes, as indicated by the value of the "AP Coordination Type" field of the AP cooperation session request frame listed in table 1020. For example, for a joint transmission session, this is set to 2. The "Target STA Information" field in the AP cooperation session request frame 1000 lists the MAC addresses of one or more target STAs expected to participate in the joint transmission.

[0059] The "Type Specific Parameters" field in the AP collaboration session request frame 1000 carries additional session parameters specific to the AP collaboration type. For example, in the case of joint transmission, this field can specify channel information for the joint transmission. The channel information may be present when the master AP and the slave AP are operating on different fronthaul channels. The "Type Specific Parameters" field may indicate the start time at which the joint transmission is expected to begin. In high-density networks, it is common for neighboring APs to operate on different channels to mitigate BSS interference. If the channel specified in the channel information is different from the operating channel of the slave AP, and if the slave AP accepts the AP collaboration session request, the slave AP is expected to switch channels to the specified joint transmission channel before the indicated joint transmission start time.

[0060] As another example, in the case of a joint transmission, if encryption is enabled for the joint transmission and encryption is performed locally at each AP, the "Type Specific Parameters" field may include a Security Key (e.g., a PTK) used for encryption.

[0061] As yet another example, in the case of a joint transmission, the "Type Specific Parameters" field may include the amount of buffer space requested by the master AP to be allocated by the slave AP to store the JT data frames.

[0062] FIG. 11 illustrates a frame 1100 in which an Ethernet frame encapsulates JT data and AP coordinated action frames according to an example embodiment.

[0063] The master AP encapsulates the joint transmit data frame (the entire S-MPDU or A-MPDU carrying the joint transmit data payload) in an 802.3 (Ethernet) frame and transmits it over the Ethernet link to the slave AP. If encryption is used, the encrypted frame is encapsulated.

[0064] When Ethernet frames are used to exchange AP coordination information between APs, Ethertype 89-0d frames may be used to encapsulate AP coordination action frames, for example, to set up or tear down AP coordination sessions. In this case, the Payload Type field is set to "AP Coordination," and the Ethertype 89-0d frame payload carries the AP coordination action frame. In this case, the "AP Coordination Packet Type" field is set to AP coordination action frame (set to 3 in table 620 in FIG. 6), and the Packet Content field carries the AP coordination action frame, while other fields in the payload are omitted.

[0065] The Destination Address in the MAC header ensures that the slave AP does not immediately forward the received JT data frame to the target STA, e.g., its subfield is set to the MAC address of the slave AP rather than the MAC address of the target STA.

[0066] Transmissions to different slave APs may not be time-synchronized in a wired backhaul scenario or a mixed backhaul scenario and may occur at the same time or at different times. The JT packet ID is used to synchronize the content of the joint transmission.

[0067] FIG. 12 illustrates a trigger frame 1200 for joint transmission to a target STA, according to an example embodiment.

[0068] The joint transmission trigger frame 1200 includes an AP Coordination Session ID 1210. This session ID is included in the JT trigger frame to indicate which joint transmission session is being triggered. Based on this session ID, the slave AP receiving the JT trigger frame obtains the common parameters negotiated during session setup. Such pre-negotiated parameters are omitted in the JT trigger frame unless the master AP explicitly overrides any of the parameters. This reduces the overhead of joint transmission control signaling over the wireless medium.

[0069] Furthermore, if all slave APs corresponding to the session ID are involved in the joint transmission, the MAC address field of the slave AP may be omitted. If the target STA is clear from the session ID, the destination MAC address field may be omitted.

[0070] FIG. 13 illustrates a communication exchange 1300 in which the master AP does not participate in joint transmissions, according to an example embodiment.

[0071] As mentioned above, in some cases, the master AP may not be involved in the actual joint transmission phase, and only the slave AP may be involved in the joint transmission. This can occur when the master AP is implemented as a central controller and is remote from the target STA, or when the master AP is not even an actual AP but a multi-AP controller device in the core network. In this case, the target STA associates with one of the slave APs rather than the master AP. Communication between the slave AP and the master AP, including the JT trigger frame, can be performed over a wired backhaul (e.g., Ethernet). If there is no wireless link between the master AP and the slave AP, even the JT trigger frame is encapsulated within an Ethernet frame. Due to the strict time synchronization requirements for joint transmission and the fact that the JT trigger frame is used for time synchronization between slave APs, the use of a wired backhaul for transmitting the JT trigger frame is only possible if it can be guaranteed that all participating slave APs receive the JT trigger frame simultaneously. In this case, the payload type field is set to "AP cooperation," and an Ethertype 89-0d frame payload carries the JT trigger frame. In this case, the "AP Cooperation Packet Type" field is set to a JT trigger frame (set to 4 in table 620 in FIG. 6), and the packet content field carries the JT trigger frame, while other fields in the payload are omitted. This type of deployment removes the constraint that slave APs must be within wireless range of the master AP, enabling much larger-scale joint transmissions, and a master AP in a central location can remotely manage joint transmissions at multiple physical locations. However, if it cannot be guaranteed that all participating slave APs will receive the JT trigger frame simultaneously, the JT trigger frame is transmitted over the wireless medium.

[0072] In such cases where the target STA is not associated with the master AP, the master AP may not know the value to be used for the sequence control field or the CCMP packet number (PN) generated locally by the slave AP. For example, if the target STA is associated with the slave AP1, before the data distribution phase 1320, the master AP initiates an information query phase 1310 to query the slave AP1 for the next sequence control to be used and, optionally, the CCMP packet number (PN) and encryption key ID to be used for transmission to the target STA. If the entire MPDU is to be distributed to the slave AP, the master AP uses the queried information to set the respective fields of the encapsulated JT data, or if the MPDU for joint transmission is generated locally by the slave AP, the information is distributed to the slave AP.

[0073] At some point prior to the data distribution phase 1320, the master AP also configures the upper layer data to be routed through the master AP itself instead of through the slave AP 1. This may be done by temporarily updating the routing tables of network router devices that forward data payloads to the AP so that the master AP is recorded as the serving AP for the target STA.

[0074] During the data distribution phase 1320, the master AP sets the MAC header field of the encapsulated JT data so that the data appears to be generated by the slave AP1 with which the target STA is associated. For example, the Address 2 (TA) field of the jointly transmitted MPDU is set to the MAC address of the slave AP1. Also, the sequence number subfield in the sequence control field of the MPDU (of the JT data) is used as an implicit JT identifier; as a result, no explicit JT packet ID is assigned to the JT data. During the joint transmission phase 1330, the master AP still initiates the joint transmission by transmitting a JT trigger frame, but only the slave AP participates in the actual joint transmission. To the target STA, the transmission appears to be initiated by the slave AP1.

[0075] FIG. 14 illustrates an action frame 1400 used by an AP in an information inquiry phase to gather information from another AP, according to an example embodiment.

[0076] The AP Coordination Info Request frame contains a Requested Information bitmap that indicates information about the slave AP's parameters for the target STA requested by the master AP. The slave AP uses the AP Coordination Info Response frame to report the requested information to the master AP. The included information is indicated by the Reported Information bitmap.

[0077] The master AP can initiate the request, but a slave AP can also initiate the request. The AP cooperation information request frame 1410 includes a requested information bitmap that indicates information about the receiving AP's parameters for the target STA requested by the transmitting AP. The receiving AP reports the requested information to the requesting AP using the AP cooperation information response frame 1420. The included information fields are indicated by the reported information bitmap. If a bit is set to 1 in the reported information bitmap, the corresponding field is included in the AP cooperation information response frame 1420; otherwise, the corresponding field is not present.

[0078] FIG. 15 illustrates a frame 1500 for data sharing from a master AP to a slave AP according to an example embodiment.

[0079] Instead of encapsulating the entire MAC layer frame (MPDU or A-MPDU), the master AP encapsulates only the upper layer data payload (also known as MSDU (MAC Service Data Unit)) and other relevant fields of the MAC header within the payload field of the Ethertype 89-0d frame body. When multiple data payloads are included, the sequence control field and the CCMP header (if included) carry the starting sequence number (SN) and packet number (PN), respectively. Based on this, each slave AP generates the MPDU or A-MPDU to be jointly transmitted. If necessary, data encryption is performed by each slave AP.

[0080] Copies of the Frame Control, Duration / ID, QoS Control, and HT Control fields are used by the slave AP to generate MAC headers for locally generated MPDUs. Alternatively, some or all of these fields may be distributed during JT session setup, provided that these fields remain the same throughout the JT session.

[0081] If the "Protected Frame" bit in the frame control field 1520 is set, then the CCMP header field 1510 is present. The CCMP header field 1510 carries a packet number (PN) used to encrypt the first MPDU with subsequent MPDUs that use sequentially increasing PNs.

[0082] The sequence control field 1520 carries the sequence number (SN) used for the locally generated A-MPDUs. It is used as the starting SN for the first MPDU and increases sequentially for subsequent MPDUs in the A-MPDU.

[0083] The packet content field 1530 carries only the upper layer payload (also known as the MSDU). Each of the slave APs appends a locally generated MAC header to the upper layer payload to generate an MPDU for joint transmission.

[0084] FIG. 16 illustrates a JT data frame 1600 as an aggregated MAC protocol data unit (A-MPDU) according to an exemplary embodiment.

[0085] Each slave AP locally generates a joint transmission data frame 1600 and stores it in memory. For example, each slave AP generates a jointly transmitted MPDU or A-MPDU based on information 1602 received from the master AP. The arrows in FIG. 16 indicate that fields are simply copied to the locally generated MPDU, except for some fields that require addition. The first generated MPDU directly uses the sequence control field received from the master AP, while each subsequent MPDU increments the sequence number subfield in the sequence control field 1620 by one. The MPDU or A-MPDU may be generated and stored in memory upon receiving encapsulated data from the master AP. If encryption is required (indicated by the "Protected Frame" bit in the frame control field 1610), each slave AP also encrypts the data payload and generates and appends a MIC to the payload. The first encrypted MPDU directly uses the CCMP header field received from the master AP, while each subsequent MPDU increments the PN subfield in the CCMP header field by one. The encrypted MPDUs are stored in memory, indexed by the JT packet ID 1630.

[0086] Alternatively, if the slave AP has a sufficiently fast processor, the received MAC parameters and payload may be stored in memory during the data distribution phase, and MPDU generation (and encryption, if necessary) may occur only after the JT trigger frame is received.

[0087] 16, the Address 2 (TA) field 1622 in the MPDU of the locally generated JT data frame 1600 is also copied from the corresponding Address 2 (TA) field 1630 in the information received from the master AP 1602. The Address 2 (TA) field 1630 is set to either the MAC address of the master AP or one of the MAC addresses of the slave AP, depending on the AP to which the target STA is associated. The remaining fields of each A-MPDU subframe (MPDU delimiter, padding, FCS, etc.) and EOF padding are locally generated. Furthermore, for CCMP encrypted frames, if the "protected frame" bit in the frame control field 1610 is set, CCMP encryption is performed by the slave AP.

[0088] One advantage of frame 1600 is that it reduces the overhead of data transfer over the backhaul.

[0089] FIG. 17 illustrates a frame 1700 as an aggregated MAC protocol data unit (A-MPDU) used for data sharing to a slave AP according to an example embodiment.

[0090] The Master AP distributes JT data to the Slave APs using 802.11 data frames 1700 in 4-address MAC header format (without Ethertype 89-0d encapsulation). This distribution method may be used, for example, in a Wi-Fi EasyMesh deployment when the Slave APs are associated with the Master AP.

[0091] When the slave AP receives the joint transmission data from the master AP, it generates an MPDU to be jointly transmitted. The sequence number in the sequence control field 1734 in the MAC header of the generated MPDU 1730 is used as an implicit JT identifier.

[0092] Consider an example deployment in which the target STA is associated with the master AP, and the master AP also participates in the actual joint transmission. The master AP sends an A-MPDU 1700 to the slave AP to distribute the JT data. Each data frame in the MPDU of the A-MPDU uses a 4-address MAC header format, and the frame body of the MPDU 1710 carries the actual data payload 1720 (encrypted as needed and including a CCMP header field and a MIC field) to be jointly transmitted. In this case, the JT data refers to the data payload 1720 (encrypted as needed and including a CCMP header field and a MIC field). Because the final destination of the data payload 1720 is not the slave AP, the "To DS" and "From DS" bits in the frame control field 1712 are both set to 1 to distinguish between AP-to-STA and STA-to-AP transmissions. Additionally, the HE control field 1714 is extended for EHT use, and a new Control ID is defined for AP cooperation. The control field may be used to carry control signals for various multi-AP cooperation schemes, and the AP Cooperation Type 1716 indicating the cooperation scheme may be set to one of the values ​​in table 1020 in FIG. 10, e.g., 2 for joint transmission if the field following the HE Control field is used to carry JT Sequence Control 1718. The JT Sequence Control field 1718 carries the Sequence Control field 1734 of the actual MPDU that is jointly transmitted.

[0093] Upon receiving an A-MPDU 1710 carrying an HE control field 1714 for AP cooperation from the master AP, the addressed slave AP (indicated by address 1 (RA)) generates a jointly transmitted MPDU or A-MPDU based on the information received from the master AP, instead of forwarding the A-MPDU to the target STA (indicated by address 3 (DA)). The generated MPDU 1730 is an 802.11 data frame using a three-address MAC header format.

[0094] In Figure 17, the arrows indicate that fields are copied from the received MPDU to the generated MPDU, except that in the generated MPDU, the "To DS" bit in the frame control field 1732 is set to 0, while the "From DS" bit is set to 1. The sequence control field 1734 of the generated MPDU is copied from the JT sequence control 1718 received from the master AP. The duration field, address 2 (TA) field, and QoS control field are copied without modification, while the address 3 (DA) field is copied to the address 1 (RA) field, and the address 4 (SA) field is copied to the address 3 (SA) field in the generated MPDU. The HE control field, which carries the JT sequence control field, is omitted in the generated MPDU. The frame body of the generated MPDU is copied directly from the MPDU 1710 received from the master AP (i.e., no further processing is performed). However, the FCS field 1738 is generated locally by the slave AP. An important aspect to note here when the data payload 1720 is encrypted is that CCMP encryption is performed for the target STA's consumption, and therefore the MAC header parameters used for encryption are based not on the MAC header fields of the MPDU 1710, but on the MAC header fields included in the actual MPDU 1730 that is jointly transmitted. Specifically, during the CCMP encapsulation procedure, the master AP uses the frame control field 1732, address 1 (RA) field 1740, address 2 (TA) field 1742, address 3 (SA) field 1744, sequence control field 1746, and QoS control field 1748, as generated by the slave AP, to construct additional authentication data (AAD) used for CCMP encryption. The address 4 field is not included in the AAD. The CCMP header fields, encrypted data payload 1720, and generated MIC are included in the frame body of the MPDU 1710 and are directly copied by the slave AP into the frame body of the MPDU 1730 without further processing.This significantly reduces the processing overhead associated with encryption on the slave AP.

[0095] An MPDU or A-MPDU may be generated by the slave AP immediately upon receiving data from the master AP and stored in memory. The MPDU is indexed by the sequence number subfield of the sequence control field 1734 and stored in memory. Alternatively, if the slave AP has a fast enough processor, during the data distribution phase, the received MPDU / A-MPDU may be stored in memory without modification, and MPDU generation (for joint transmission) may occur only after the JT trigger frame is received.

[0096] FIG. 18 illustrates a joint transmit trigger frame 1800 according to an example embodiment.

[0097] The JT trigger frame contains a list of sequence numbers of MPDUs to be jointly transmitted. The slave AP constructs A-MPDUs from the stored MPDUs, if necessary.

[0098] The sequence number subfield (e.g., 1620 in Figure 16 or 1732 in Figure 17) in the sequence control field of the MPDU (JT data) is used as an implicit JT identifier, which allows the master AP more flexibility in selecting the content of the JT data during the actual joint transmission (by indicating a specific sequence number in the sequence number information field 1810 in the JT trigger frame 1800).

[0099] This flexibility can be achieved, for example, during joint retransmissions, where only failed MPDUs are retransmitted. The Sequence Number Information field 1810 identifies the jointly transmitted MPDUs. Bits set to 1 in the Sequence Number Bitmap subfield indicate the sequence numbers of the contained MPDUs, with the first bit in the bitmap (n=1) corresponding to the Starting Sequence Number (SSN) subfield and the nth bit corresponding to (SSN+n-1).

[0100] FIG. 19 is an example of a distributed MU-MIMO (D-MU-MIMO) joint transmission 1900 to two STAs, both associated with a master AP, according to an example embodiment.

[0101] Reference numerals 1910 and 1912 indicate data distribution to the slave AP. The JT data is distributed to the slave AP addressed to STA1 and STA2, respectively. For example, the JT data 1910 and 1912 may be the A-MPDU 1700 in FIG. 17. Upon receiving the JT data 1910 and 1920, the slave AP can generate an MPDU 1730 for joint transmission by copying necessary fields from the received JT data. The slave AP can further aggregate the locally generated MPDUs into one A-MPDU and store the A-MPDU in a designated local buffer. Although not shown in FIG. 19, for D-MU-MIMO joint transmission, before the actual joint transmission, the AP needs to collect channel state information (CSI) of the channel between the AP and the target STA, for example, by performing an explicit sounding procedure. The master AP can instruct each slave AP to collect CSI of the channel between the intended AP and the target STA according to the conventional 802.11 sounding procedure. The slave AP reports the CSI to the master AP. Once the master AP collects the CSI from all slave APs, it calculates the steering matrix to be used for joint transmission. The master AP then distributes the relevant section of the steering matrix to each slave AP. This may occur before or after the data distribution phase. Reference numeral 1914 denotes a joint transmission trigger frame used to initiate a joint transmission to a target STA. The JT trigger frame 1914 initiates a MU joint transmission using two spatial streams using the steering matrix received from the master AP. Reference numeral 1920 denotes a joint transmission to STA1 using spatial stream 1 (SNs 1-5 to STA1). Reference numeral 1922 denotes a joint transmission to STA2 using spatial stream 2 (SNs 11-15 to STA2). 1920 and 1922 occur simultaneously but use different spatial streams.

[0102] Another problem is that it is unclear how long a slave AP should store JT data (e.g., data previously distributed by the master AP). Because buffer space is a limited resource for an AP, from the slave AP's perspective, it is beneficial to delete JT data that has already been transmitted as soon as possible to make room for newer JT data. However, deleting JT data too early creates an ambiguity problem in joint retransmissions, because the master AP does not know whether the slave AP still owns the JT data to be retransmitted or whether the master AP needs to redistribute the JT data.

[0103] Redistribution and retransmission also have other problems: for example, there is significant protocol overhead due to wireless backhaul, and if backhaul transmission and joint transmission are strongly coupled, this overhead further increases in the presence of transmission failures.

[0104] The exemplary embodiments address these issues and provide an acknowledgement procedure for a multi-AP joint transmission and retransmission scheme, and also reduce retransmission overhead.

[0105] FIG. 20 illustrates a JT data frame 2000, an acknowledgement (ACK or Ack) frame 2010, and a BlockAck frame 2020 according to an example embodiment.

[0106] Although multiple APs may participate in a joint transmission, from the perspective of the target STA, it may appear as a single AP transmission. The STA may not even be aware of the joint transmission. The RA field of the Ack or BlockAck frame is simply copied from the TA field of the JT data frame. This is typically set as the MAC address of the AP with which the target STA is associated. Furthermore, by default, APs will not parse Ack or BlockAck frames with an RA field that does not match their own MAC address. As a result, these APs will not know whether the joint transmission was successful or not.

[0107] 20, Address 2 (TA) 2030 of JT data frame 2000 is set to the MAC address of the associated AP (e.g., the master AP or one of the slave APs). Upon successful reception of JT data frame 2000, the addressed STA acknowledges the JT data frame by sending an ACK frame 2010 or a BlockAck frame 2020. The STA copies the TA field 2030 of the JT data frame into the RA field 2040 of the Ack frame 2010 or the RA field 2050 of the BlockAck frame 2020.

[0108] FIG. 21 illustrates a joint transmission 2100 in which a STA fails to receive a JT data frame and the master AP repeats the joint transmission procedure, according to an example embodiment.

[0109] As mentioned above, the STA may not even be able to recognize the joint transmission. Therefore, the ACK is addressed to the TA of the JT data (i.e., the master AP in this example of Figure 21). In this case, the procedure is simple for the slave AP because there is no standardization on how the slave AP processes the JT data. However, the transmission overhead is high due to the redistribution of data to the slave AP. Here, the master AP assumes that the slave AP deletes the JT data immediately after each joint transmission. The master AP initiates a retransmission if the Ack frame is not received within a certain timeout value. In case of a retransmission, the master AP simply repeats the entire joint transmission procedure, including the data distribution phase.

[0110] Alternatively, the slave AP may keep only one JT data in memory at a time, rather than deleting it from memory after each joint transmission. When new JT data is received from the master AP, the slave AP replaces existing JT data, if any. In either case, in the event of a transmission failure, retransmission overhead can prove high due to the redistribution of data to the slave APs.

[0111] FIG. 22 illustrates a joint transmission 2200 in which a STA fails to receive a JT data frame, the slave AP processes the Ack frame, and the master AP repeats the joint transmission without repeating the data distribution, according to an exemplary embodiment.

[0112] As shown in Figure 22, the slave AP actively participates in the acknowledgement procedure for the joint transmission. As explained more fully below, the JT data is held by the slave AP (i.e., the slave AP follows the retransmission procedure normally followed by the transmitter) until it is successfully acknowledged or a retry limit is reached.

[0113] After a joint transmission, the slave AP also processes the Ack frame from the target STA (addressed to the master AP or another slave AP) as if the ACK frame was addressed to the slave AP. If an ACK frame is received, the jointly transmitted data is deleted. If an ACK frame is not received, the jointly transmitted data is retained for possible retransmission. The slave AP maintains retry counters (short retry counter, or SRC, and long retry counter, or LRC) for each jointly transmitted MSDU and increments these counters with each joint retransmission. If either retry limit is reached, the corresponding jointly transmitted MSDU is discarded. The retry limits are synchronized between all participating APs, i.e., they must be the same value.

[0114] In case of a transmission failure, the master AP repeats only the joint transmission; data distribution is not repeated. During retransmission, data distribution over the backhaul is omitted. Furthermore, the JT trigger frame that initiates the joint retransmission may specify a more robust transmission mode (such as a lower MCS) or may specify a different PHY coding (e.g., if HARQ retransmissions are used).

[0115] FIG. 23 illustrates a joint transmission 2300 in which a STA fails to receive the JT data and the slave AP processes the BlockAck frame and deletes the JT data, according to an example embodiment.

[0116] This figure shows an example of aggregate transmission using block acknowledgement. During joint transmission, an A-MPDU carrying an aggregate of multiple MPDUs is jointly transmitted by the AP, and the target STA responds by transmitting a BlockAck frame addressed to the master AP, acknowledging the successfully received MPDU. In this example, the slave AP also processes a BlockAck (BA) frame from the target STA (addressed to the master AP) as if the BlockAck frame were addressed to the slave AP. If the BlockAck frame indicates that the MPDU was received, the MPDU is deleted from the local buffer. If the BlockAck frame indicates that the MPDU was not received, the MPDU is retained for possible retransmission. In Figure 23, MPDUs with SNs 1 through 10 were jointly transmitted during the original joint transmission, but the target STA failed to receive MPDUs with SNs 5 and 6, and the BlockAck frame reports the MPDUs with SNs 5 and 6 as not being received. After processing the BlockAck, Slave AP1 and Slave AP2 delete the transmitted MPDUs except for the MPDUs with SNs 5 and 6. The Master AP then transmits a JT trigger frame instructing the retransmission of the MPDUs with SNs 5 and 6 and the transmission of the MPDUs with SNs 11 to 20. Because the Slave APs retain the MPDUs, the Master AP does not need to redistribute the MPDUs with SNs 5 and 6 to the Slave APs. Although the processing load on the Slave APs increases due to the need to decode ACK / BA and maintain retry counters, the data distribution overhead is eliminated for retransmissions.

[0117] The slave AP may delete the stored JT data based on a lifetime timer or when the AP collaboration session is torn down (if the session is set up). Additionally, MSDUs successfully received by the target STA are deleted based on the BA bitmap.

[0118] FIG. 24 illustrates joint transmission 2400 and error recovery where a STA fails to receive JT data and the master AP fails to receive a BlockAck frame from a target STA, according to an example embodiment.

[0119] This figure shows an example of error recovery when, for some reason, the master AP fails to receive the Ack / BA frame while the slave AP receives the Ack / BA frame, which can occur, for example, when the master AP is farther away from the target STA compared to the slave AP, or simply due to hidden node interference, etc.

[0120] As explained more fully below, the slave AP may have already deleted the JT data referenced in the JT trigger frame (e.g., when the slave AP receives a BA for a joint transmission but the master AP fails to receive the BA). The slave AP sends a special frame to inform the master AP of the deleted JT data and the reason for the deletion. The master AP may retransmit only the failed MPDU.

[0121] The slave AP may receive BA frames acknowledging the successfully received MPDUs with SNs 1-4, 7-10 and may delete these MPDUs from memory. However, the master AP may fail to receive a Block Ack (BA) frame and assume that the original joint transmission failed, and may initiate a joint retransmission of all MPDUs by sending a JT trigger frame referencing the MPDUs with SNs 1-10.

[0122] SIFS after the JT trigger frame, the master AP transmits a JT PPDU. Because the slave AP no longer owns some of the MPDUs referenced in the JT trigger frame, the slave AP does not participate in the joint transmission. Because this is a single AP transmission, the target STA fails to receive the entire JT PPDU. Based on the contents of the JT trigger frame, the slave AP can infer that the master AP failed to receive the BA frame. To prevent the master AP from continuing to repeatedly attempt such retransmissions, the slave AP can send an AP cooperation information response frame to the master AP to report that some of the MPDUs referenced in the JT trigger frame have already been deleted, and also indicate the reason for the deletion (e.g., successfully acknowledged). The master AP can then proceed to selectively retransmit only the failed MPDUs (i.e., MPDUs with SNs 5 and 6).

[0123] FIG. 25 illustrates an AP cooperation information response frame 2500 and a table 2510 containing deletion reasons, according to an example embodiment.

[0124] The AP cooperation information response frame 2500 includes Deleted JT Data 2520 reported to the master AP. The Deleted JT Data 2520 includes the deletion reason (shown in table 2510) and a starting sequence number and a sequence number bitmap that together indicate the sequence numbers of the MPDUs deleted by the slave AP.

[0125] Table 2510 includes deletion reason field values ​​(eg, 0-3) and meanings associated with the corresponding field values.

[0126] The slave AP notifies the master AP of the currently stored JT data using an AP collaboration information response frame 2500. The AP collaboration information response frame is sent when a JT trigger frame is received that references JT data that has been deleted from the slave AP's memory.

[0127] When the master AP receives the AP cooperation information response frame 2500 from the slave AP, it decides the next action based on the deletion reason. Consider an example where the reason is Exceeded Lifetime. In this case, the joint transmission may not have even been attempted. The master AP can redistribute the JT data to the slave APs and attempt a joint transmission.

[0128] Consider another example where the reason is Reached Retry Limit: In this case, the transmission failed regardless of the number of joint transmissions, so the master AP can give up on the transmission if the retry limit is reached.

[0129] Consider another example where the reason is "Successfully acknowledged." In this case, the master AP recognizes the JT data (MPDUs) whose transmission failed, so it can retransmit only the failed JT data that has not been deleted. The successfully acknowledged JT data is omitted from the joint retransmission.

[0130] FIG. 26 illustrates wireless transmissions with a wireless network 2600 and STAs in a backhaul BSS and a fronthaul BSS in accordance with an example embodiment.

[0131] Wireless network 2600 includes a backhaul BSS 2610, a fronthaul BSS 2620, multiple APs (shown as AP1-AP3), and multiple STAs (shown as STA1-STA3). The backhaul BSS is used by APs to communicate between APs, while the fronthaul BSS is used for communication between APs and STAs. Diagram 2630 shows communication links between APs in the backhaul BSS and the fronthaul BSS. Thick dotted lines represent transmission links between APs in the backhaul BSS, while thin dotted lines represent transmission links between APs and STAs in the fronthaul BSS. In this network configuration, a master AP may include logical backhaul APs and logical fronthaul APs, while a slave AP may include logical backhaul STAs that associate with the backhaul APs and logical fronthaul APs. STAs are associated with the fronthaul APs of either the master AP or the slave AP. The MAC addresses of the fronthaul entities and backhaul entities in each AP may be different.

[0132] To make it easier for the slave AP to identify the Ack / BA frame for the joint transmission, the master AP may also assign a unique MAC address to be used as the TA (Transmitter Address) in the MAC header of the jointly transmitted frame (see, for example, the frame in Figure 20). Such a MAC address may be called the Joint Transmission Transmit Address (JT TA) or the joint transmit MAC address.

[0133] One such example is given here: The MAC address of the backhaul AP may be used as the TA for joint transmission, which may be the BSSID of the backhaul BSS. Here, the slave AP processes only Ack / BA frames with the RA field set to JT TA. In this case, the target STA also needs to be aware of the JT TA. Before the joint transmission, the associated AP notifies the target STA of the JT TA, and the target STA stores the JT TA in its memory. The presence of the JT TA also makes the STA aware of the joint transmission.

[0134] The master AP can dynamically switch between single AP transmission and joint transmission based on channel conditions, making the assignment of sequence numbers to MPDUs problematic. For example, the AP may initially attempt single AP transmission and switch to multi-AP joint transmission if the single AP transmission repeatedly fails, even after using the most robust MCS, etc. To simplify the sequence number plan, for transmissions to a specific target STA, the master AP can use consecutive sequence numbers from the same sequence number space for both normal transmissions (single AP transmissions using the master AP's MAC address as the TA) and joint transmissions (using the JT TA as the TA). In this case, MPDU reordering for the target STA is straightforward because MPDUs can be reordered based on sequence numbers regardless of the TA (either the JT TA or the master AP's MAC address). Conversely, the Block Ack scoreboarding procedure at the slave AP may be slightly more complex because only a portion of the scoreboard bitmap may be used during joint transmission acknowledgments.

[0135] 27-32 show two further exemplary embodiments (FIGS. 27-29 show one embodiment, and FIG. 30-32 show another). In these embodiments, the slave AP does not actively participate in the acknowledgement procedure for joint transmission. Only the master AP or the AP with the MAC address appearing in the TA field of the jointly transmitted frame needs to process the Ack / BA frame. This reduces the frame processing load on the slave AP.

[0136] In Figures 27-29, we assume that each joint transmission is immediately acknowledged by the target STA and that non-immediate BA is not used. Here, non-immediate BlockAck refers to a transmission in which the Ack policy of the transmitted frame is set to Block Ack. In this case, the addressed receiver takes no action upon receiving the frame except to record the state. The receiver can expect a BlockAckReq frame or an implicit Block Ack request in the future.

[0137] The JT trigger frame serves two purposes: first, it serves the original (explicit) purpose of initiating a joint transmission and referencing the JT data to be jointly transmitted; second, it serves a new (implicit) purpose of indicating the transmission status of a previous joint transmission.

[0138] FIG. 27 illustrates a joint transmission 2700 in which a STA fails to receive JT data and a slave AP uses a JT trigger frame to delete a JT MPDU, according to an example embodiment.

[0139] In this diagram, the slave AP uses the contents of the JT trigger frame to delete JT MPDUs that it presumes have been successfully transmitted. MPDUs that have already been jointly transmitted are deleted if they are not listed for retransmission. The master AP may also use the JT trigger frame solely to signal the slave AP to flush their JT MPDUs.

[0140] Based on the list of jointly transmitted MPDUs, the slave AP infers which MPDUs were successfully transmitted and are eligible to be discarded. Furthermore, JT trigger frames listing newer (unsaved) MPDUs trigger the deletion of older MPDUs. In Figure 27, during the original joint transmission, MPDUs with SNs 1-10 were jointly transmitted, but the target STA failed to receive the MPDUs with SNs 5 and 6, and the BlockAck frame reports the MPDUs with SNs 5 and 6 as not received. After processing the BlockAck, the master AP transmits a JT trigger frame instructing the retransmission of the MPDUs with SNs 5 and 6 and the transmission of MPDUs with SNs 11-20. Based on the contents of this JT trigger frame, the slave AP infers that the MPDUs with SNs 1-4 and SNs 7-10 were successfully received by the STAs and can proceed to delete them. All APs also proceed to jointly transmit the MPDUs with SNs 5 and 6 and the MPDUs with SNs 11-20. Upon successful reception of all MPDUs, the target STA responds with a BlockAck frame indicating the same. Since the master AP has no further MPDUs to jointly transmit, it sends a special-purpose JT trigger frame listing MPDUs with SN21 that have not been previously transmitted. The sole purpose of this JT trigger frame is to trigger a buffer flush in the slave AP. Upon receiving a JT trigger frame listing MPDUs with new (unstored) SN21, the slave AP proceeds to delete any older MPDUs stored in its buffer.

[0141] FIG. 28 illustrates a joint transmission 2800 in which a STA fails to receive JT data and the slave AP relays information about the acknowledgement frame to the master AP, according to an example embodiment.

[0142] This diagram shows a deployment where the target STA is associated with a slave AP and the master AP does not participate in the actual joint transmission. Only the slave AP participates in the actual joint transmission. The RA field of the Ack / BA frame is set as the MAC address of one of the slave APs. The master AP cannot receive / process the Ack / BA frame for the joint transmission and must have the slave AP relay such information to the master AP to make a decision regarding retransmission.

[0143] In this example, the target STA is associated with Slave AP1, and therefore the BlockAck is addressed to Slave AP1. Since Slave AP1 receives the BlockAck frame, it can discard the MPDU based on the content of the BlockAck frame and does not need to wait for a subsequent JT trigger frame for the discard decision. Furthermore, Slave AP1 forwards the content of the Block Ack to the Master AP. The other Slave AP (i.e., Slave AP2 in this example) does not need to explicitly participate in the acknowledgement procedure for the joint transmission, but as previously mentioned, it can use the subsequent JT trigger frame to decide whether to discard the transmitted MPDU. Only associated APs are involved in the processing of the Ack / BA frame.

[0144] FIG. 29 is an AP cooperation information response frame 2900 that may be used by a slave AP to forward the contents of a received Ack / Block Ack frame to a master AP, according to an example embodiment.

[0145] If the target STA is associated with the slave AP, the slave AP forwards the contents of the Ack or BlockAck frame received from the target STA to the master AP using the AP cooperation information response frame 2900. The AP cooperation information response frame is not sent by the slave AP if no Ack / BA frame is received from the target STA.

[0146] The frame body includes Ack Info 2910, which carries the contents of the Ack frame or Block Ack frame received from the target STA. The Ack Info 2910 includes a BA Control field and a BA Information field. When transmitting information of an Ack frame, the BA Control field includes the sequence control field of the Ack frame, and the BA Information field is omitted. When transmitting information of a BlockAck frame, the BA Control field and BA Information field of the received BlockAck frame are copied into the respective fields of the Ack Information field.

[0147] Additionally, if an Ack information field is included in the frame body and the Ack / BA field indicates whether the Ack information field 2910 carries the contents of an Ack frame or a BlockAck frame (e.g., a value of 0 signaling an Ack frame and a value of 1 signaling a BlockAck frame), then Ack information 2920 is set to 1.

[0148] The frame implementation of FIG. 29 reduces data distribution overhead while keeping the operation simple for the slave AP.

[0149] FIG. 30 is a JT trigger frame 3000 that includes an explicit instruction to flush the buffer, according to an example embodiment.

[0150] The JT trigger frame 3000 includes a Flush Buffer field 3010 that contains an indication of whether to flush the buffer, i.e., whether to delete JT data that no longer needs to be stored. For example, if the Flush Buffer bit is set to 1, previously transmitted JT data with JT identification information (SN or JT packet ID) not listed in the JT trigger frame is deleted from the slave AP's memory. If the Flush Buffer bit is set to 0, the stored JT data is retained.

[0151] Frame 3000 also includes a sequence number information field 3020. When used as a special purpose JT trigger frame to flush the buffers of a slave AP, the bitmap may be omitted or set to all zeros.

[0152] FIG. 31 illustrates a joint transmission 3100 in which a STA fails to receive JT data and non-immediate Block Ack is supported for the joint transmission in accordance with an example embodiment.

[0153] This figure shows an example for the case of transmit diversity or SU-MIMO when non-immediate BlockAck is supported for joint transmission. Non-immediate BlockAck refers to a transmission where the Ack policy is set to Block Ack. In this case, the addressed receiver takes no action upon receiving the frame except to record the state. The receiver can expect a BlockAckReq frame or an implicit Block Ack request in the future.

[0154] During a joint transmission, if the Ack policy of a jointly transmitted frame is set as "Block Ack," the target STA does not respond immediately but waits for a BlockAckReq frame to return a Block Ack frame. In such a case, two or more JT trigger frames and sets of JT PPDUs can be transmitted one after the other before an acknowledgment for the previous joint transmission is received. To prevent a subsequent JT trigger frame from triggering the deletion of previously transmitted JT data in this transmission burst, the "flush buffers" indication is set to disabled (0) during the original joint transmission, even before any confirmation of the reception status is received from the target STA. The master AP can set the "flush buffers" indication to enabled (1) in the JT trigger frame that initiates a joint retransmission to signal to the slave AP that it is now safe to delete previously transmitted JT data not referenced in this JT trigger frame.

[0155] This JT trigger frame can therefore carry an explicit indication (e.g., by setting a bit to 1 or 0) of whether to flush the slave AP's buffer. The JT Trigger frame [JT Packet ID = 5, FB = 1] signals to the slave AP that JT packets with IDs less than 5 can be safely deleted from memory, while JT packets with ID 5 will be jointly retransmitted. Furthermore, a JT Trigger frame [JT Packet ID = 6, FB = 1] listing new (unsaved) JT data and FB = 1 triggers the deletion of all older JT data.

[0156] FIG. 32 illustrates a distributed MU-MIMO joint transmission 3200 where a STA fails to receive JT data and non-immediate BlockAck is supported for joint transmission in accordance with an example embodiment.

[0157] This figure shows an example of the distributed MU-MIMO case for simultaneous joint transmission to two target STAs. The use of flush buffer indication is the same, except for some differences in the signaling of JT data in the JT trigger frame. One difference is that different data is transmitted to different STAs via different spatial streams during joint transmission, and the JT data for different target STAs may be different within the same joint transmission. Another difference is that BlockAck frames from target STAs are requested using MU-BAR frames (Multi-User BlockAckReq frames).

[0158] FIG. 33 illustrates a joint transmission 3300 in which a STA fails to receive JT data and a special purpose frame instructing a slave AP to delete the stored JT data, according to an exemplary embodiment.

[0159] A special purpose frame is defined to be used by the master AP to instruct the slave AP to delete stored JT data. The slave AP will retain the stored JT data until this frame is received. The JT trigger frame is used only to initiate joint transmission (i.e., it is not used to determine when to flush the buffer).

[0160] This diagram shows an example embodiment in which the master AP is entirely responsible for how long the slave APs retain the JT data. A separate frame (AP Coordination Data Flush) is used by the master AP to instruct the slave APs to flush their buffers. The slave APs retain all JT data until an AP Coordination Data Flush is received indicating the JT data that can be deleted.

[0161] FIG. 34 illustrates a table 3400 of AP collaboration session action field values ​​and an AP collaboration data flash frame 3410 according to an example embodiment.

[0162] The master AP instructs the slave AP to delete the stored JT data using an AP Coordination Data Flush action frame 3410. The AP Coordination Data Flush frame may be an AP Coordination Action frame with the AP Coordination Session Action field set to 5 (AP Coordination Data Flush). The AP Coordination Data Flush frame may be sent after each Ack / BA received by the master AP or upon completion of the entire joint transmission (including retransmissions).

[0163] This frame includes a Data Flush field 3420 with a Starting Sequence Number field and a Sequence Number Bitmap field that together indicate the SNs of MPDUs that may be deleted from the slave AP's buffer. When used at the end of a joint transmission burst, the value of the Starting Sequence Number field may be set to a value greater than the highest SN of the stored JT data, in which case the slave AP will flush all stored JT data (regardless of their previous transmission status). In such a case, the Sequence Number Bitmap may be set to all zeros to distinguish this special use.

[0164] FIG. 35 is an example of an electronic device 3500 according to an exemplary embodiment.

[0165] The electronic device 3500 includes a power supply 3510, a memory 3520, a central processing unit (CPU) 3530, a secondary storage device 3540, and a wireless I / F 3550 (including a transmitter and / or receiver). The wireless I / F 3550 includes a MAC 3552 and a PHY 3560 that communicate with an antenna 3570. The MAC 3552 further includes a JT identification information generator 3554, a JT data buffer 3556, a JT data encapsulation / deencapsulation 3558, and a JT buffer management 3562.

[0166] Consider an exemplary embodiment in which the electronic device 3500 is an AP, such as a master AP or a slave AP (note that the JT identity generator 3554 is only present in the master AP).

[0167] The electronic device 3500 includes circuitry that operates to receive (e.g., in a wireless receiver) a joint transmit (JT) trigger frame from another AP that indicates a MAC protocol data unit (MPDU) to be jointly transmitted to the communication device. The JT data buffer 3556 (which may be a logical portion of the memory 3520) stores one or more MPDUs previously transmitted to the communication device and MPDUs allocated by another AP for joint transmission.

[0168] In an exemplary embodiment, JT buffer management 3562 determines how long JT data should be held in JT data buffer 3556. JT buffer management 3562 is also responsible for processing Ack / BA frames, JT trigger frames, or AP cooperative data flash frames to arrive at such a determination.

[0169] The electronic device 3500 includes a circuit that operates to generate a frame including JT data and a JT identification that uniquely identifies the JT data. For example, the JT identification generator block 3554 is responsible for generating a JT identification corresponding to the JT data distributed to the slave AP. The JT data encapsulation / deencapsulation block 3558 is used by the master AP to encapsulate JT data within 802.11 data frames or 802.3 Ethernet frames during the data distribution phase. This block is used by the slave AP to deencapsulate JT data received from the master AP. The JT data buffer 3556 stores the JT data used for joint transmission. In the master AP, the JT data buffer 3556 may not be a separate buffer but may be a shared buffer that stores all transmitted data frames. In the slave AP, the JT data buffer 3556 may be a separate buffer used exclusively for storing data frames used for joint transmission. The electronic device 3500 further includes circuitry, such as a wireless transmitter and / or antenna 3570, that enables the AP to transmit data frames to one or more communication devices, such as one or more STAs in a wireless network.

[0170] The present disclosure can be realized by software, hardware, or software cooperating with hardware. Each functional block used in the above-described embodiments can be realized, in part or in whole, by an LSI such as an integrated circuit. Each process described in each embodiment can be controlled, in part or in whole, by the same LSI or a combination of LSIs. The LSI can be formed as an individual chip, or a single chip can be formed to include some or all of the functional blocks. The LSI can include a data input / output unit coupled thereto. Herein, LSIs are sometimes referred to as ICs, system LSIs, super LSIs, or ultra LSIs depending on their level of integration. However, integrated circuits are not limited to LSIs and can be realized using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (field programmable gate arrays), which can be programmed after LSI fabrication, and reconfigurable processors, which can reconfigure the connections and settings of circuit cells arranged within LSIs, can also be used. The present disclosure can be realized using digital or analog processing. When LSI is replaced by future integrated circuit technology as a result of advances in semiconductor technology or other derivative technologies, the future integrated circuit technology can be used to integrate functional blocks. Biotechnology can also be applied.

[0171] The present disclosure may be implemented by any type of apparatus, device, or system with communication capabilities (collectively referred to as communication apparatus).

[0172] The communication device may include a transceiver and processing / control circuitry. The transceiver may include and / or function as a receiver and a transmitter. As a transmitter and a receiver, the transceiver may include an RF (Radio Frequency) module including an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

[0173] Non-limiting examples of communication devices include telephones (e.g., cell phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, netbooks), cameras (e.g., digital still / video cameras), digital players (e.g., digital audio / video players), wearable devices (e.g., wearable cameras, smartwatches, tracking devices), game consoles, digital book readers, telehealth / telemedicine devices, communication-enabled vehicles (e.g., cars, airplanes, ships), and combinations of the above devices.

[0174] Communications equipment is not limited to portable or mobile equipment, but also includes non-portable or fixed equipment, devices, or systems of any kind, such as smart home devices (appliances, lighting, smart meters, control panels, etc.), vending machines, and any other "things" that may exist on an Internet of Things (IoT) network.

[0175] Communications include data communications via cellular systems, wireless LAN systems, communications satellite systems, etc., as well as data communications via combinations of these.

[0176] A communications apparatus also includes devices such as controllers and sensors connected or coupled to a communications device that performs the communications functions described in this disclosure. For example, a communications apparatus may include a controller or sensor that generates control or data signals used by the communications device to perform the communications functions of the communications apparatus.

[0177] The communication apparatus also includes infrastructure facilities, such as base stations, access points, and any other apparatus, device, or system that communicates with or controls the various apparatuses listed above, but are not limited to these.

[0178] Other exemplary embodiments include, but are not limited to, the following examples:

[0179] One exemplary embodiment is an AP that includes a receiver that, during operation, receives a joint transmission (JT) trigger frame from another access point (AP) indicating a MAC protocol data unit (MPDU) to be jointly transmitted to a communication device, and a local memory that stores one or more MPDUs previously transmitted to the communication device.

[0180] The JT trigger frame includes an explicit indication of whether one or more MPDUs previously transmitted to the communication device are to be deleted from the local memory.

[0181] The local memory stores one or more MPDUs previously transmitted to the communication device until the JT trigger frame is received.

[0182] The JT trigger frame includes sequence number values ​​of MPDUs to be jointly transmitted to the communication device, and the AP deletes from the local memory any previously transmitted MPDUs having sequence number values ​​not indicated in the JT trigger frame.

[0183] The AP further comprises a transmitter that, during operation, when the AP does not hold an MPDU that is indicated in the JT trigger frame to be jointly transmitted, transmits a frame to the other AP including a sequence number value of an MPDU that has been deleted from the local memory and a reason for deleting the MPDU from the local memory.

[0184] The receiver further operates to receive from the communication device an acknowledgement (ACK) frame or a Block Ack (BA) frame that acknowledges a successfully received MPDU jointly transmitted by one or more other APs and the AP, the ACK frame or the BA frame being addressed to the AP, and the AP further comprises a transmitter that, in operation, transmits a frame carrying the contents of the ACK frame or the BA frame to the other AP.

[0185] Another exemplary embodiment is an access point (AP) comprising: circuitry that, during operation, determines that a communication device fails to receive one or more MAC protocol data units (MPDUs) jointly transmitted to the communication device by the AP and another AP; and a transmitter that, during operation, transmits a joint transmission (JT) trigger frame to the other AP without redistributing the failed MPDUs to the other AP.

[0186] The JT trigger frame indicates an MPDU to be jointly transmitted again to the communication devices.

[0187] Another exemplary embodiment is a method that includes receiving, at an access point (AP), a joint transmission (JT) trigger frame from another AP indicating MAC protocol data units (MPDUs) to be jointly transmitted to a communication device, and storing one or more MPDUs previously transmitted to the communication device in a local memory of the AP.

[0188] Another exemplary embodiment is a method that includes, at an access point (AP), determining that a communication device fails to receive one or more MAC protocol data units (MPDUs) jointly transmitted to the communication device by the AP and another AP, and transmitting, by the AP, a joint transmission (JT) trigger frame to the other AP without redistributing the failed MPDUs to the other AP.

[0189] Another exemplary embodiment is an access point (AP) comprising: a transmitter that, in operation, jointly transmits MAC protocol data units (MPDUs) with another AP to a communication device; and a receiver that, in operation, receives an acknowledgement (ACK) frame or a Block Ack (BA) frame from the communication device that acknowledges a successfully received MPDU, wherein a receiver address in the ACK frame or the BA frame is different from a MAC address of the transmitter; and the AP deletes from a local memory MPDUs having a sequence control value that was acknowledged by the ACK frame or the BA frame as being successfully received by the communication device.

[0190] The AP also stores in its local memory any MPDUs having sequence control values ​​that have not been acknowledged as successfully received by the communication device.

[0191] The receiver address in the ACK frame or the BA frame is the MAC address of the other AP.

[0192] The receiver address in the ACK frame or the BA frame is a MAC address assigned by the other AP for joint transmission of the MPDU to the communication device.

[0193] Another exemplary embodiment is a communications device comprising: a receiver that, during operation, receives an assigned JT MAC address for joint transmission from an associated AP; and a local memory that stores the JT MAC address, the receiver further receiving an MPDU with a transmitter address (TA) field set to the JT MAC address.

[0194] The communication device further comprises a transmitter that, in operation, transmits an ACK or BA frame, with a receiver address (RA) field set to the JT MAC address, acknowledging the received MPDU.

[0195] While exemplary embodiments have been presented in the foregoing detailed description of the present embodiments, it should be understood that numerous variations exist. It should be further understood that the exemplary embodiments are examples only and are not intended to limit the scope, applicability, operation, or configuration of the present disclosure in any way. Rather, the foregoing detailed description provides those skilled in the art with a convenient road map for implementing exemplary embodiments of the present disclosure, and it should be understood that various changes can be made in the function and configuration of the steps and operational methods described in the exemplary embodiments without departing from the scope of the present disclosure as set forth in the claims.

Claims

1. An integrated circuit mounted on an access point (AP), a process of encapsulating multi-AP transmission data and generating a data frame including the encapsulated multi-AP transmission data and a multi-AP transmission packet ID assigned to the encapsulated multi-AP transmission data; Distributing a first multi-AP transmission trigger frame including the assigned multi-AP transmission packet ID for transmitting the data frame to a slave AP and initiating multi-AP transmission; When the communication device determines that it has failed to receive one or more MAC Protocol Data Units (MPDUs) of the data frame jointly transmitted to the communication device by the AP and the slave AP in the multi-AP transmission, transmitting a second multi-AP transmission trigger frame including the assigned multi-AP transmission packet ID to the slave AP without redistributing the failed MPDU to the slave AP; Integrated circuit.

2. the second multi-AP transmission trigger frame indicates the MPDU to be jointly transmitted again to the communication device; 10. The integrated circuit of claim 1.

Images