Communication device and communication method for multi-AP joint retransmission

Abstract

An access point (AP) includes: a receiver that receives a joint transmission (JT) trigger frame from another AP, the joint transmission (JT) trigger frame indicating a MAC protocol data unit (MPDU) to be jointly transmitted to a communication device; and a local memory storing one or more MPDUs previously transmitted to the communication device.

Description

[0001] This application is a divisional application of the Chinese invention patent application with the application date of February 27, 2020, application number 202080031761.7, invention name “Communication device and communication method for multi-AP joint retransmission”, and the applicant is Panasonic Electric (USA) Intellectual Property Corporation. Technical Field

[0002] The present disclosure relates generally to communication apparatus and methods for electronic devices and systems, and more particularly to joint re-transmission in a multi-AP network. Background Art

[0003] Wireless networks that communicate via multi-AP joint transmissions enable electronic devices to communicate in the network using joint transmissions sent to multiple electronic devices. Such networks have advantages over other wireless networks where wireless communication is limited to a single transmission to one electronic device. Summary of the invention

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

[0005] One example embodiment is an access point (AP) comprising: a receiver that receives a joint transmission (JT) trigger frame from another AP, the joint transmission (JT) trigger frame 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.

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

[0007] Additional benefits and advantages of the disclosed embodiments will become apparent from the description and drawings. Benefits and / or advantages may be obtained individually from various embodiments and features of the description and drawings, and all of these embodiments and features need not be provided in order to obtain one or more such benefits and / or advantages. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the drawings, the same reference numerals refer to the same or functionally similar elements throughout the various views, which, together with the following detailed description, are incorporated into and constitute a part of this specification for explaining various embodiments and explaining various principles and advantages according to the embodiments.

[0009] Figure 1is a wireless network with a multi-AP system according to an example embodiment.

[0010] Figure 2A is a multi-AP system shown as an enterprise network according to an example embodiment.

[0011] Figure 2B is a multi-AP system shown as a home or office network according to an example embodiment.

[0012] Figure 2C A multi-AP system is shown as a master-slave configuration according to an exemplary embodiment.

[0013] Figure 3 is a MAC protocol data unit (MPDU) according to an example embodiment.

[0014] Figure 4 is a message sequence in a joint transmission in a multi-AP system according to an example embodiment.

[0015] Figure 5A and 5B is a data frame for encapsulating JT data according to an example embodiment.

[0016] Figure 6 Shown are a data frame according to an example embodiment, a first table showing protocol names and payload types, and a second table showing AP coordination packet types.

[0017] Figure 7 A joint transmission between a master AP, a slave AP, and a target STA is shown according to an example embodiment.

[0018] Figure 8 is a JT trigger frame according to an example embodiment.

[0019] Fig. 9 It is a message sequence of a joint transmission session between a master AP and a slave AP in a multi-AP system according to an exemplary embodiment.

[0020] Fig.10 AP coordination action frames are shown exchanged over the air to negotiate or break a joint transmission session according to an example embodiment.

[0021] Fig.11 A frame is shown in which an Ethernet frame encapsulates JT data as well as an AP coordination action frame according to an example embodiment.

[0022] Fig.12 A trigger frame for joint transmission to a target STA according to an exemplary embodiment is shown.

[0023] Fig.13 It is shown that the master AP does not participate in the communication exchange of the joint transmission according to an example embodiment.

[0024] Fig.14 An action frame used by an AP to collect information from another AP during an information inquiry phase according to an example embodiment is shown.

[0025] Fig.15 A frame for data sharing from a master AP to a slave AP according to an example embodiment is shown.

[0026] Fig.16 A JT data frame is shown as an aggregate MAC protocol data unit (A-MPDU) according to an example embodiment.

[0027] Fig.17 A frame as an Aggregate MAC Protocol Data Unit (A-MPDU) for sharing data to a slave AP according to an exemplary embodiment is shown.

[0028] Fig.18 A joint transmission trigger frame according to an example embodiment is shown.

[0029] Fig.19 is an example of distributed MU-MIMO joint transmission to two STAs, both of which are associated with a master AP, according to an exemplary embodiment.

[0030] Fig. 20 A JT Data frame, an Acknowledgement (ACK or Ack) frame, and a Block Ack frame are shown according to an example embodiment.

[0031] Fig.21 A joint transmission is shown in which a STA fails to receive a JT data frame and the master AP repeats the joint transmission process according to an exemplary embodiment.

[0032] Fig. 22 A joint transmission according to an example embodiment is shown, where the STA fails to receive the JT data frame and the slave AP also processes the Ack frame, and the master AP repeats the joint transmission without repeating the data distribution.

[0033] Fig.23 A joint transmission according to an example embodiment is shown, where the STA fails to receive the JT data and the slave AP also processes the Block Ack frame and deletes the JT data.

[0034] Fig.24 Joint transmission according to an example embodiment is shown, wherein a STA fails to receive JT data and error recovery in the event that a master AP fails to receive a Block Ack frame.

[0035] Fig.25 An AP coordination information response frame and a table with deletion reasons according to an example embodiment are shown.

[0036] Fig.26A wireless network and wireless transmissions with STAs in backhaul and fronthaul BSSs according to example embodiments are shown.

[0037] Fig. 27 A joint transmission according to an example embodiment is shown, where a STA fails to receive JT data and deletes the JT MPDU from the AP using a JT trigger frame.

[0038] Fig.28 A joint transmission according to an exemplary embodiment is shown, in which a STA fails to receive JT data and relays information about an acknowledgement frame from an AP to a master AP.

[0039] Fig.29 is an AP coordination information response frame according to an example embodiment.

[0040] Fig.30 is a JT trigger frame with an indication to flush the buffer according to an example embodiment.

[0041] Fig.31 A joint transmission according to an exemplary embodiment is shown, wherein the STA fails to receive JT data and supports non-immediate Block Ack for the joint transmission.

[0042] Fig.32 Distributed MU-MIMO joint transmission according to an example embodiment is shown, where the STA fails to receive JT data and non-immediate Block Ack is supported for joint transmission.

[0043] Fig.33 A joint transmission according to an example embodiment is shown, wherein a STA fails to receive JT data and a dedicated frame indicating deletion of the stored JT data from the AP.

[0044] Fig.34 An AP coordination session action field value table and an AP coordination data refresh frame according to example embodiments are shown.

[0045] Fig.35 is an electronic device according to example embodiments.

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

[0047] Electronic devices can be configured to send and receive joint transmission (JT) data in a multi-AP network. These electronic devices have many advantages over traditional electronic devices, which are limited to a single transmission of a single electronic device. However, there are many technical problems in performing joint transmission in a multi-AP network.

[0048] The existing 802.11 BSS (Basic Service Set) operates as an independent unit. The AP of each BSS provides wireless communication services only to the wireless stations (STAs) associated with the corresponding AP. The data rate that the AP can provide for the wireless link to the associated STA depends on the MCS (Modulation and Coding Scheme) used for the link, which in turn depends on the SINR (Signal-to-Noise-Interference Ratio) of each STA. Generally, a higher MCS can be achieved at a higher SINR, while only a lower MCS is possible at a lower SINR level. In an independent BSS, although the AP can control the signal-to-noise ratio by adjusting the transmission power, the interference experience of the STA is more difficult to control. This problem is particularly true for STAs that exist at the edge of the network and are within the wireless range of multiple BSSs, also known as OBS (Overlapping BSS) areas. The useful signal in one BSS is essentially interference to the STA of another BSS.

[0049] Multi-AP coordination (e.g., coordination between APs of neighboring BSSs) can be used as an effective method to improve the SINR of member STAs. The proliferation of APs (such as dense deployment of APs in managed networks (e.g., enterprise networks, stadium settings, etc.) or home networks (e.g., home mesh networks with multiple APs)) makes such schemes possible.

[0050] Various multi-AP coordination schemes can be divided into two categories. The first group includes schemes that attempt to reduce interference to OBSS through transmission 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 synchronous transmission from multiple APs to the same STA. The second group of schemes can be called multi-AP joint processing or multi-AP joint transmission, or distributed MU-MIMO.

[0051] Joint transmission not only improves the signal level, but also reduces interference by converting interfering signals into desired signals. Therefore, the exemplary embodiments solve technical problems associated with STAs in overlapping BSSs or multi-AP systems by reducing interference to STAs and improving SINR to STAs. These problems include how to distribute and synchronize joint transmission data (joint MU-MIMO data) between slave APs and other issues discussed herein.

[0052] An example embodiment is an access point (AP) comprising: a receiver that receives a joint transmission (JT) trigger frame from another AP, the joint transmission (JT) trigger frame 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.

[0053] Another example embodiment is an access point (AP) comprising: circuitry that determines that a communication device has failed 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 sends a joint transmission (JT) trigger frame to the other AP without redistributing the failed MPDUs to the other AP.

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

[0055] exist Figure 1 In Figure 1, although STA2 is associated with AP3, the three APs (AP1, AP2, and AP3) can coordinate their transmissions to transmit to STA2 simultaneously. This synchronized transmission increases the SINR level of STA2 and facilitates the use of a higher MCS, thereby improving the throughput of STA2.

[0056] Although multi-AP coordination schemes typically utilize some kind of time synchronization between participating APs, for joint transmissions, especially for distributed MU-MIMO, the highest level of synchronization is utilized. Therefore, one or more example embodiments implement joint transmissions where one AP (referred to as the master AP) provides the synchronization signal while the other participating APs (referred to as slave APs) are within range of the master AP. Figure 1 , AP3 will be the master AP, while AP1 and AP2 are slave APs. The master AP may also be referred to as an alternative name such as a coordinated AP, a joint transmission (JT) AP, or a multi-AP controller, and the slave AP may also be referred to as a multi-AP device or a coordinated AP, etc.

[0057] In an example embodiment and as discussed in more detail below, the joint transmission includes all participating APs to transmit the same signal to the STA. This includes MAC layer specific fields that are equivalent to all participating APs.

[0058] Figure 2AIt is a multi-AP system 200 shown as an enterprise network according to an example embodiment. For example, the system includes multiple APs (shown as AP1-AP8) broadcasting with overlapping transmissions. Each AP operates its own channel (Ch), such as AP1 at Ch 36, AP2 at Ch 52, AP3 at Ch 149, AP4 at Ch 44, AP5 at Ch 56, AP6 at Ch 161, AP7 at Ch 48, and AP8 at Ch 60.

[0059] In enterprise networks, AP locations and frequency allocations are carefully planned during deployment to maximize capacity. Figure 2A As shown, 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 each other's wireless range. Multiple APs or all APs can use the same service set identifier (SSID). In addition, the APs are connected using Ethernet and can be configured and / or controlled by a central AP controller. Most edge STAs will be within the coverage of at least two APs. For example, AP-to-AP communication can use Ethernet or out-of-band mesh wireless direct links, etc. Even if adjacent APs are assigned non-overlapping primary channels, inter-BSS interference is inevitable in the OBSS area when broadband channels are used. Since most enterprise networks are centrally managed and coordination between APs is easier, enterprise networks are prime candidates for joint transmission systems.

[0060] Figure 2B It is 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 its own channel, such as AP1 at Ch 36, AP2 at Ch 149, and AP3 at Ch 52.

[0061] A multi-AP system (such as Wi-Fi EasyMesh) is an example configuration to provide Wi-Fi coverage throughout an area, such as a house or office. Plan AP locations and frequency allocations to maximize coverage. For example, one AP can act as a multi-AP controller, while the remaining APs can act as multi-AP agents. The AP can be expected to be in the wireless coverage of at least one other AP. Set up a backhaul BSS for AP-to-AP signaling. The backhaul BSS can use an SSID different from the fronthaul SSID. Most edge STAs will be within the coverage of at least two APs. In addition, AP-to-AP communications can use a wireless direct link or a mix of wireless and wired links. This multi-AP home or small office network is also a good candidate for a joint transmission system.

[0062] Figure 2C2 is a multi-AP system 260 shown as 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. AP to AP communication occurs on link 290, and communication between AP and STA occurs on link 292.

[0063] For joint transmission, the AP has the transmission data (upper layer data) to be jointly transmitted to the STA before the actual joint transmission. However, in one or more example embodiments, having the transmission data may not be sufficient to achieve SINR gain for joint transmission. The actual data symbols transmitted in the air need to be synchronized between participating APs (such as multiple APs or all APs). This means that in the participating APs, the PHY layer and MAC layer processing of the transmission data are the same. Example embodiments include systems, devices, and methods for distributing and synchronizing data for multi-AP joint transmission.

[0064] In one or more example embodiments, joint transmission occurs in two phases: distribution of JT data to slave APs and joint transmission to target STAs.

[0065] In the first phase (distributing the joint transmission data to the slave APs), the AP-to-AP link (such as Figure 2C Prior to the actual joint transmission (link 290 in Figure 2), the data to be jointly transmitted is distributed to the participating slave APs. The distribution can occur over a wireless backhaul link between the APs, or it can also occur over a wired backhaul link between the APs, such as Ethernet. When a wireless backhaul is used, before initiating the joint transmission, the slave APs may have been associated with the master AP on a separate BSS established by the master AP for communication between APs. The wireless channel used for the backhaul link between the APs may be different from the fronthaul link between the AP and the target STA.

[0066] In the second phase (joint transmission to the target STA), the actual joint transmission to the target STA by two or more participating APs takes place in e.g. Figure 2C The joint transmission may be preceded by a synchronization signal from the master AP via link 290, which may be referred to as a slave trigger frame or a joint transmission (JT) trigger frame. In some scenarios, the master AP may also participate in the joint transmission, while in some scenarios, the master AP may not participate in the joint transmission but only the slave APs may participate. Different AP sets may be involved in the joint transmission of different target STAs.

[0067] Figure 3is a MAC protocol data unit (MPDU) 300 to be jointly transmitted according to an example embodiment. The MPDU includes a MAC header and a frame body. The MAC header includes frame control, duration, address 1 (receiver address), address 2 (transmitter address), address 3 (BSSID), sequence control, QoS control, and HT control. The frame body includes data payload, MIC, and FCS. If the data frame carries an A-MSDU, the address 3 field carries the BSSID, otherwise the address 3 field carries the source address (SA), that is, the MAC address of the device that is the source of the data payload.

[0068] In order to achieve the SINR gain of the joint transmission, the actual data symbols transmitted over the air are synchronized between the participating APs. In addition, the PHY layer and MAC layer processing for the transmission between the participating APs is the same. Typically, for normal transmission (e.g., non-joint transmission), the 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 pre-suspending the MAC header, adding FCS, MAC padding (if necessary), etc., to create the MPDU (MAC Protocol Data Unit) 300. If protection is enabled, the data payload may further undergo an encryption process that results in the addition of the CCMP header field and the MIC field to the MAC frame body. The MPDU is then passed down to the PHY layer for PHY layer processing, such as pre-suspending the PHY preamble, applying PHY coding, adding PHY padding, etc., to create the PPDU (PHY Protocol Data Unit) and finally transmit the PPDU over the air.

[0069] For joint transmission, participating APs need to know the MAC and PHY parameters to be applied to the data payload. In addition, at the MAC layer, there are several fields that are generated locally. While some fields such as frame control, address 2 (TA), address 3 (BSSID), QoS control, and HT control can be rewritten by the MAC layer of the slave AP to match the fields generated by the master AP, some fields such as sequence control and CCMP header are different for each MPDU and are usually generated locally at each AP; therefore, these fields are more difficult to synchronize between APs. In addition, multiple MPDUs can also be aggregated at the MAC layer to form an A-MPDU (aggregate MPDU), or one MPDU can constitute an S-MPDU (single MPDU). In order 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 also generated by the master AP, and the same digital space is used for the sequence number subfield of the sequence control field for direct transmission from the master AP to the target STA (i.e., sing AP transmission) and for joint transmission. If encryption is enabled, the master AP also encrypts the data payload and appends the MIC field. In this case, joint transmission (JT) data refers to the MAC layer data to be jointly transmitted.

[0070] In some cases, the master AP may not participate in the actual joint transmission phase (e.g., only slave APs may participate in joint transmission). This may happen when the master AP is implemented as a central controller and is far away from the target STA. In this case, the target STA will associate with one of the slave APs instead of the master AP.

[0071] In this 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 be generated by the slave AP associated with the target STA, for example, the Address 2 (TA) field and the Address 3 (BSSID) 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 the fields of the MPDU 300 respectively. In this case, the sequence control field in the MPDU is generated by the slave AP, and the sequence number subfield of the sequence control field uses the same numeric space for both direct transmission from the AP to the target STA (i.e., sing AP transmission) and joint transmission.

[0072] Figure 4 is a message sequence 400 in a joint transmission in a multi-AP system according to an example embodiment.

[0073] In distributed wireless networks (such as 802.11 WLANs), access to the wireless channel is controlled by CSMA / CA, and it is difficult to predict the exact transmission time. Also, transmission failures and retransmissions make it difficult to maintain the transmission order. Therefore, for joint transmission, it may be beneficial to decouple the data distribution phase and the joint transmission phase.

[0074] like Figure 4 As shown, joint transmission is divided into two phases: distributing joint transmission data to slave APs and joint transmission to one or more target STAs. In the first phase, one or more joint transmission data are distributed to slave APs (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. The frame carries a unique ID that identifies the joint transmission data to be jointly transmitted by all participating APs.

[0075] Figure 4 An example message sequence involved in a joint transmission is shown, wherein the data distribution phase 410 is decoupled 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 AP. In this case, the JT data may be an actual S-MPDU or A-MPDU to be jointly transmitted and is encapsulated in another data frame addressed to the slave AP. In order to reduce the overhead of distributing the JT data, the encapsulated data frame may be transmitted to the slave AP as a multicast transmission rather than a unicast transmission. The master AP may also use a multi-user (MU) PPDU format to simultaneously distribute different JT data to different slave APs.

[0076] In order to uniquely identify each JT data, the master AP also assigns a unique ID, which may be referred to as a JT packet ID, to each JT data. Each slave AP, upon receiving the encapsulated JT data, decapsulates the JT data and saves it in a local memory indexed by the JT packet ID. In order to ensure that the slave AP saves the JT data instead of immediately forwarding it to the target STA, the data frame encapsulating the JT data may be addressed to the slave AP by setting the RA to the MAC address of the slave AP. If a four-address MAC header is used for a data frame to a slave AP, both the RA (address 1) and the DA (address 3) may be set to the MAC address of the slave AP. Due to the strict time synchronization requirements and faster retrieval of joint transmissions, JT data frames may be stored in a separate memory (e.g., different from the local EDCA queue).

[0077] In the joint transmission phase 420, the master AP initiates the joint transmission by transmitting a JT trigger frame to the slave APs. The JT trigger frame provides time synchronization to the slave APs. 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 the JT data from the local memory corresponding to the JT packet ID and sends a JT PPDU constructed by the JT data.

[0078] Figure 5A and 5B is a data frame for encapsulating JT data according to an example embodiment.

[0079] Figure 5A A data frame 500 transmitted by a master AP is shown, which encapsulates 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, an actual MPDU, and padding (if necessary). A unique ID (JT packet ID) is assigned to each joint transmission data. In this case, the JT packet ID uniquely identifies the S-MPDU.

[0080] Figure 5B A data frame 550 transmitted by a master AP is shown, which encapsulates 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 EOF (end of frame) padding (if required). Each A-MPDU subframe shares the same format as an S-MPDU. In this case, the JT packet ID uniquely identifies the A-MPDU.

[0081] If encryption is enabled, each MPDU in the JT data is also encrypted by the primary AP before being encapsulated into data frame 500 or 550.

[0082] Each slave AP, upon receiving encapsulated JT data, decapsulates the JT data and stores it in a local memory indexed by the JT packet ID. Due to the strict time synchronization requirements of joint transmission, the JT data frame can be stored in a separate memory (e.g., different from the local EDCA queue) for faster retrieval.

[0083] The slave AP does not immediately forward the received JT data to the target STA. To ensure this, if a four-address MAC header is used for the slave AP's data frame, both RA (address 1) and DA (address 3) are set to the slave AP's MAC address.

[0084] Figure 6 Shown is a data frame 600 according to an example embodiment, a first table 610 showing payload type field encoding, and a second table 620 showing AP coordination packet type field encoding.

[0085] Data frame 600 encapsulates JT data during the data distribution phase (e.g., in Figure 4 410 of ). In this example, the frame body of the 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 IEEE802.11 frames within Ethernet frames. When the payload type is set to "AP coordination", the payload of the Ethertype 89-0d frame can carry JT data within the packet content field when 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, and the packet length field indicates the size of the JT data carried in the packet content field. When an 802.11 data frame is dedicated to encapsulating JT data, the sequence number subfield 630 in the sequence control field 632 of the host 802.11 data frame can be used as an implicit JT packet ID, and the JT packet ID field can be omitted in the Ethertype 89-0d frame body.

[0086] To ensure that the JT data is saved by the slave AP instead of being immediately forwarded 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.

[0087] Figure 7 A joint transmission 700 between a master AP, a slave AP, and a target STA is shown according to an example embodiment.

[0088] During the joint transmission phase (e.g. Figure 4420 in the discussion), the master AP initiates the joint transmission by transmitting a JT trigger frame 710 to the slave APs. In addition to the PHY and MAC parameters for synchronization, the JT trigger frame also carries the JT packet ID of the JT data to be jointly transmitted. The MAC layer of each slave AP, upon receiving the JT trigger frame that identifies the slave AP as a participating AP in the joint transmission, retrieves the JT data corresponding to the JT packet ID from the local memory and passes it down to the physical layer, which constructs a JT PPDU from the JT data before sending its SIF (Short Inter-Frame 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 (Short Inter-Frame Space) after the end of the JT trigger frame. Since the channel status may be different at different APs, each slave AP may need to consider the channel conditions and transmit the JT PPDU only when the channel is considered idle during the SIF after the end of the JT trigger frame, except that the NAV (Network Allocation Vector) set due to the transmission of the master AP or the target STA may be ignored. As for the target STA, upon receiving the JT data, it may not even be aware that multiple APs are involved in the transmission. As far as the target STA is concerned, this is just another transmission from the primary AP or the AP whose MAC address appears in the TA Address (Address 2) field of the frame to the target STA. If the reception is successful, the target STA proceeds to transmit an acknowledgment frame (ACK or Block Ack) to the AP whose MAC address appears in the TA Address (Address 2) field.

[0089] Figure 8 800 is a JT trigger frame according to an example embodiment. Each user information field carries a set of information from the AP and the target STA.

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

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

[0092] In addition, the joint transmission PHY layer information field specifies additional PHY parameters for the encoding of the JT PPDU. For example, for transmit diversity joint transmission (also known as non-coherent joint transmission), in order to prevent unintentional beamforming, it is desirable to use different cyclic shift diversity (CSD) values ​​for the transmit antennas (transmit chains) of different APs participating in the joint transmission to the target STA using the same spatial stream. In this case, the joint transmission PHY layer information field can specify the (CSD) value used by the slave AP for its transmit chain. The master AP can select a CSD value for each transmit chain for each slave AP and notify the slave AP of the exact CSD value. Alternatively, the master AP assigns the index # to the transmit chain involved in the joint transmission and notifies the slave AP of the index # in the joint transmission PHY layer information field instead of signaling the exact CSD value. The slave AP selects a CSI value according to the index # by referring to a stored CSD value table. If the slave AP transmits using multiple antennas, the index # can be the starting index, and the subsequent antennas use the CSD value corresponding to the next index # in the table. The target STA information carries information related to the joint transmission from the AP to one or more target STAs. The joint transmission information identifies the stored data to be transmitted and the spatial stream of the target STA.

[0093] In addition, the spatial stream allocation field indicates the spatial stream allocated to each target STA and exists 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.

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

[0095] If the joint transmission is expected to occur for more than one or two frames, the example embodiment establishes a joint transmission session between the master AP and the participating slave APs before the actual joint transmission. During the joint transmission session negotiation, the master AP and the slave AP exchange information about the target STAs participating in the joint transmission. The master AP and the slave AP also specify the joint transmission parameters expected to be used throughout the session, such as the channel to be used, the PPDU format (HT, VHT or HE, etc.), the precoding scheme for MU-MIMO, etc. Each joint transmission session is identified by a unique session ID. The master AP initiates the establishment of a joint transmission session by sending an AP coordination session request frame to the slave AP. If the slave AP accepts the request, an AP coordination session response frame with the status code field set to accepted is sent 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 release frame to the slave AP.

[0096] Fig.10The AP coordination action frames exchanged between APs to negotiate or release a joint transport session according to an example embodiment are shown. The figure shows an AP coordination session request 1000, an AP coordination session response 1002, an AP coordination session release 1004, a table 1010 with AP coordination session action field values, and a table 1020 with AP coordination type field values.

[0097] A new action frame category is defined for multi-AP coordination and is indicated in the category field. To implement AP-to-AP communication associated with multi-AP coordination, five new action frames are defined, three of which are used for session establishment / release (indicated by the value of the "AP coordination session action" field listed in Table 1010). Sessions can be established for various types of multi-AP coordination schemes, and the session is indicated by the value of the "AP coordination type" field in the AP coordination session request frame, as shown in Table 1020. For example, for a joint transmission session, it is set to 2. The "target STA information" field in the AP coordination session request frame 1000 lists the MAC addresses of one or more target STAs expected to participate in the joint transmission.

[0098] The "Type Specific Parameters" field in the AP coordination session request frame 1000 carries additional session parameters specific to the AP coordination type. For example, for a joint transmission, this field may specify channel information for the joint transmission. The channel information may be present when the master AP and the slave AP operate on different fronthaul channels. The "Type Specific Parameters" field may also indicate the start time when the joint transmission is expected to start. In dense networks, neighboring APs typically operate on different channels to mitigate interference between BSSs. 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 coordination session request, the slave AP is expected to switch the channel to the specified joint transmission channel before the indicated joint transmission start time.

[0099] As another example, for a joint transmission, if encryption is enabled for the joint transmission and encryption is to be performed locally at each AP, the "Type Specific Parameters" field may also include a security key (eg, PTK) used for encryption.

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

[0101] Fig.11 Frame 1100 is shown in accordance with an example embodiment, where an Ethernet frame encapsulates JT data as well as an AP coordination action frame.

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

[0103] When Ethernet frames are used to exchange AP coordination information between APs, Ethertype 89-0d frames can also be used to encapsulate AP coordination action frames, such as for establishing or dismantling an AP coordination session. In this case, the Payload Type field is set to "AP Coordination" and the Ethertype 89-0d frame payload carries AP coordination action frames. In this case, the "AP Coordination Packet Type" field is set to the AP Coordination Action frame (such as Figure 6 As shown in Table 620 in FIG. 6 , the packet content field carries the AP coordination action frame, while other fields in the payload are omitted.

[0104] The destination address in the MAC header ensures that the slave AP does not immediately forward the received JT data frame to the destination STA. For example, the subfield is set to the MAC address of the slave AP instead of the MAC address of the destination STA.

[0105] In a wired or hybrid backhaul scenario, transmissions to different slave APs may not be synchronized in time and may occur at the same time or at different times. The JT packet ID is used to synchronize the joint transmission content.

[0106] Fig.12 A trigger frame 1200 for a joint transmission to a target STA is shown according to an example embodiment.

[0107] The joint transmission trigger frame 1200 includes an AP coordinated session ID 1210. The session ID is included in the JT trigger frame to indicate which joint transmission session is being triggered. Based on the session ID, the slave AP receiving the JT trigger frame retrieves the common parameters negotiated during session establishment. Unless the master AP explicitly overrides any parameters, such pre-negotiated parameters are omitted in the JT trigger frame. The overhead of joint transmission control signaling over the wireless medium is reduced.

[0108] In addition, if all slave APs corresponding to the session ID are involved in the joint transmission, the field MAC address of the slave AP can be skipped. If the target STA can be clearly seen from the session ID, the target MAC address field can also be skipped.

[0109] Fig.13 A communication exchange 1300 is shown in which a master AP does not participate in a joint transmission according to an example embodiment.

[0110] As mentioned earlier, in some cases, the master AP may not participate in the actual joint transmission phase, and only the slave AP can participate in the joint transmission. This may happen when the master AP is implemented as a central controller and is far away from the target STA, or the master AP may not even be an actual AP and may be a multi-AP controller device in the core network. In this case, the target STA is associated with one of the slave APs, not the master AP. Communication between the slave AP and the master AP (including the JT trigger frame) may occur over a wired backhaul (such as Ethernet). When there is no wireless link between the master AP and the slave AP, even the JT trigger frame is encapsulated in an Ethernet frame. Since the joint transmission has strict time synchronization requirements and the JT trigger frame is used for time synchronization in the slave AP, the wired backhaul transmission JT trigger frame can only be used when it is guaranteed that all participating slave APs receive the JT trigger frame at the same time. In this case, the payload type field is set to "AP coordination" and the Ethertype 89-0d frame payload carries the JT trigger frame. In this case, the "AP coordination packet type" field is set to the JT trigger frame (such as Figure 6 As shown in Table 620 in FIG. 4 , the packet content field carries the JT trigger frame, while the other fields in the payload are omitted. This deployment eliminates the constraint that the slave APs are within the wireless range of the master AP and enables larger-scale joint transmissions, where a master AP in a centralized location can remotely manage joint transmissions in multiple physical locations. However, if it cannot be guaranteed that all participating slave APs receive the JT trigger frame at the same time, the JT trigger frame is transmitted over the wireless medium.

[0111] In the case 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 from the AP. For example, if the target STA is associated with slave AP1, before the data distribution phase 1320, the master AP initiates the information query phase 1310 and queries 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 distributed to the slave AP, the master AP uses the queried information to set the various 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.

[0112] At some point before the data distribution phase 1320, the master AP also arranges for the upper layer data to be routed through itself rather than through slave AP 1. This can be achieved by temporarily updating the routing table of the network router device that forwards data payloads to the AP so that the master AP is recorded as the serving AP for the target STA.

[0113] During the data distribution phase 1320, the master AP sets the MAC header fields of the encapsulated JT data so that the data appears to be generated by slave AP1 associated with the target STA, for example, the Address 2 (TA) field of the MPDU of the joint transmission is set to the MAC address of slave AP1. In addition, the sequence number subfield in the sequence control field of the MPDU (of the JT data) is used as an implicit JT identifier, so an explicit JT packet ID is not 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, however only the slave AP participates in the actual joint transmission. To the target STA, the transmission appears to be initiated by slave AP1.

[0114] Fig.14 An action frame 1400 is shown for an AP to collect information from another AP during an information inquiry phase according to an example embodiment.

[0115] The AP coordination information request frame includes a requested information bitmap, which indicates information about the slave AP parameters of the target STA requested by the master AP. The slave AP uses the AP coordination information response frame to report the requested information to the master AP, including information indicated by the reported information bitmap.

[0116] Although the master AP can initiate the request, the slave AP can also initiate the request. The AP coordination information request frame 1410 includes a requested information bitmap, which indicates information about the parameters of the receiving AP of the target STA that sent the AP request. The receiving AP uses the AP coordination information response frame 1420 to report the requested information to the requesting AP, and the information fields included are indicated by the reported information bitmap. If the bit in the report information bitmap is set to 1, the corresponding field is included in the AP coordination information response frame 1420, otherwise the field does not exist.

[0117] Fig.15 A frame 1500 for data sharing from a master AP to a slave AP is shown according to an example embodiment.

[0118] 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 the MSDU (MAC Service Data Unit), and other relevant fields of the MAC header within the payload field of the Ethertype 89-0d frame body. If multiple data payloads are included, the sequence control field and the CCMP header (if included) carry the starting sequence number (SN) and the packet number (PN), respectively. Based on this, each slave AP generates the MPDU or A-MPDU to be jointly transmitted. Data encryption is performed by each slave AP if necessary.

[0119] The slave AP creates a MAC header for the locally generated MPDU using a copy of the Frame Control, Duration / ID, QoS Control, and HT Control fields. Alternatively, if these fields remain unchanged throughout the JT session, some or all of these fields may also be distributed during the JT session establishment.

[0120] The CCMP Header field 1510 is present if the "Protected Frame" bit in the Frame Control field 1520 is set. The CCMP Header field 1510 carries a Packet Number (PN) that is used to encrypt the first and subsequent MPDUs using sequentially increasing PNs.

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

[0122] The packet content field 1530 carries only the higher layer payload (also called MSDU). Each slave AP appends a locally generated MAC header to the higher layer payload to generate an MPDU for joint transmission.

[0123] Fig.16 A JT data frame 1600 is shown as an aggregated MAC protocol data unit (A-MPDU) according to an example embodiment.

[0124] Each slave AP locally generates a joint transmission data frame 1600 and stores it in a memory. For example, each slave AP generates an MPDU or A-MPDU to be jointly transmitted based on information 1602 received from the master AP. Fig.16 The arrows in indicate that only fields need to be copied to the locally generated MPDU, except for some fields that need to be added. The first MPDU generated directly uses the sequence control field received from the master AP, while each subsequent MPDU increases the sequence number subfield within the sequence control field 1620 by 1. The MPDU or A-MPDU can be generated and saved in memory immediately when the encapsulated data is received 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 a MIC and attaches it to the payload. The first encrypted MPDU directly uses the CCMP header field received from the master AP, while each subsequent MPDU increases the PN subfield within the CCMP header field by 1. The encrypted MPDU is saved in memory, indexed by the JT packet ID 1630.

[0125] Alternatively, if the slave AP has a fast enough processor, the received MAC parameters and payload are kept in memory during the data distribution phase, and MPDU generation (and encryption, if required) can be done only after receiving the JT trigger frame.

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

[0127] One advantage of frame 1600 is that data transmission overhead on the backhaul is reduced.

[0128] Fig.17 A frame 1700 is shown according to an example embodiment as an Aggregate MAC Protocol Data Unit (A-MPDU) for sharing data to a slave AP.

[0129] The master AP distributes JT data to the slave APs using 802.11 data frame 1700 with a 4-address MAC header format (without Ethertype 89-0d encapsulation). This distribution scheme can be used when the slave AP is associated with the master AP, such as in a Wi-Fi EasyMesh deployment.

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

[0131] Consider a deployment example where the target STA is associated with a master AP, which also participates in the actual joint transmission. The master AP transmits an A-MDPU 1700 to the slave AP to distribute the JT data. Each data frame within the MPDU of the A-MPDU uses a four-address MAC header format, and the frame body of the MPDU 1710 carries the actual data payload 1720 to be jointly transmitted (encrypted if necessary, and includes the CCMP header field and the MIC field). In this case, the JT data refers to the data payload 1720 (encrypted if necessary, and includes the CCMP header field and the MIC field). Since 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 or STA to AP transmissions. The HE control field 1714 is also enhanced for EHT use, and a new control ID is defined for AP coordination. The control field can be used to carry control signals for various multi-AP coordination schemes. The AP coordination type 1716 indicates the coordination scheme and can be set to Fig.10 The HE control field is one of the values ​​in Table 1020, for example, set to 2 for joint transmission, in which case the subsequent field of the HE control field is used to carry the JT sequence control 1718. The JT sequence control field 1718 carries the sequence control field 1734 of the actual MPDU to be jointly transmitted.

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

[0133] exist Fig.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 and 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 any 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 carrying the JT Sequence Control field is omitted from the generated MPDU. The frame body of the generated MPDU is copied directly from the MPDU 1710 when received from the master AP (i.e., without any further processing). However, the FCS field 1738 is generated locally by the slave AP. An important aspect to note here is that if the data payload 1720 is encrypted, CCMP encryption is performed for use by the target STA, so the MAC header parameters used for encryption are based on the MAC header fields included in the actual MPDU 1730 of the joint transmission, rather than based on the MAC header fields of the MPDU 1710. Specifically, during the CCMP encapsulation process, the master AP uses the frame control field 1732, the address 1 (RA) field 1740, the address 2 (TA) field 1742, the address 3 (SA) field 1744, the sequence control field 1746, and the QoS control field 1748, as generated by the slave AP, to construct additional authentication data (AAD) for CCMP encryption. The address 4 field is not included in the AAD. The CCMP header fields, the encrypted data payload 1720, and the generated MIC are included in the frame body of the MPDU 1710 and are copied directly to the frame body of the MPDU 1730 by the slave AP without further processing. This significantly reduces the processing overhead associated with encryption from the slave AP.

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

[0135] Fig.18 A joint transmission trigger frame 1800 is shown according to an example embodiment.

[0136] The JT trigger frame includes a list of sequence numbers of the MPDUs to be jointly transmitted. If necessary, an A-MPDU is constructed from the saved MPDUs from the AP.

[0137] The sequence number subfield in the sequence control field of the MPDU (JT data), e.g. Fig.16 1620 or Fig.17 1732 in the JT trigger frame 1800 is used as an implicit JT identifier. This allows the primary AP to more flexibly select 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).

[0138] This flexibility can be implemented, for example, during joint retransmissions of only the MPDUs that failed to be retransmitted. The sequence number information field 1810 identifies the MPDUs to be jointly transmitted. The bits set to 1 in the sequence number bitmap subfield indicate the sequence number of the MPDU to be included, with the first bit (n=1) in the bitmap corresponding to the starting sequence number (SSN) subfield and the nth bit corresponding to (SSN+n–1).

[0139] 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.

[0140] Numbers 1910 and 1912 show data distribution to slave APs. JT data is distributed to slave APs with STA1 and STA2 as destinations, respectively. For example, JT data 1910 and 1912 may be Fig.17 The slave AP may further aggregate the locally generated MPDUs into a single A-MPDU and save the A-MPDU in a designated local buffer. Fig.19Not shown, but 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 process. The master AP can instruct each slave AP to collect CSI of the channel between the AP and the target STA of interest according to the traditional 802.11 sounding process. The slave AP will report the CSI to the master AP. Once the master AP collects CSI from all slave APs, the master AP will calculate the steering matrix for joint transmission. The master AP then distributes the relevant part of the steering matrix to each slave AP. This may occur before or after the data distribution phase. Number 1914 shows a joint transmission trigger frame for initiating a joint transmission to the target STA. The JT trigger frame 1914 uses the steering matrix received from the master AP to initiate a MU joint transmission using two spatial streams. Number 1920 shows a joint transmission to STA1 using spatial stream 1: sequence numbers 1–5 to STA1. Number 1922 shows a joint transmission to STA2 using spatial stream 2: sequence numbers 11-15 to STA2. 1920 and 1922 occur at the same time, but use different spatial streams.

[0141] Another problem is that it is unclear how long a slave AP should keep JT data (e.g., data previously distributed by a master AP). Since buffer space is a limited resource for an AP, it is beneficial from the slave AP's perspective to delete transmitted JT data as soon as possible to make room for newer JT data. However, deleting JT data too early creates an ambiguity problem for joint retransmissions, so the master AP is not sure whether the slave AP still has the JT data to retransmit, or whether it needs to redistribute the JT data?

[0142] There are other issues with redistribution and retransmission as well. For example, there is significant protocol overhead due to the wireless backhaul. This overhead is further increased when the backhaul transmission and the joint transmission are strongly coupled and when there are transmission failures.

[0143] The exemplary embodiments solve these problems and provide a confirmation process for a multi-AP joint transmission and retransmission scheme. The exemplary embodiments also reduce the retransmission overhead.

[0144] Fig. 20 A JT data frame 2000 , an acknowledgement (ACK or Ack) frame 2010 , and a Block Ack frame 2020 are shown according to an example embodiment.

[0145] Although multiple APs can participate in a joint transmission, from the perspective of the target STA, it can be shown as a single AP transmission. The STA may not even be aware of the joint transmission. The RA field of the Ack frame or Block Ack frame is simply copied from the TA field of the JT data frame, which is usually set to the MAC address of the AP associated with the target STA. In addition, by default, the AP will not parse the Ack or Block Ack frame whose RA field does not match its own MAC address. As a result, these APs do not know whether the joint transmission is successful.

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

[0147] Fig.21 A joint transmission 2100 is shown according to an example embodiment, wherein the STA fails to receive a JT data frame and the master AP repeats the joint transmission process.

[0148] As mentioned above, the STA may not even be aware of the joint transmission. Therefore, the ACK is addressed to the TA of the JT data (i.e., in Fig.21 The master AP in this example). In this case, the way the slave AP handles JT data is not standardized, so the process is very simple for the slave AP. However, the transmission overhead is high due to the redistribution of data to the slave APs. Here, the master AP assumes that the slave AP will delete the JT data immediately after each joint transmission. If an Ack frame is not received within a certain timeout value, the master AP initiates a retransmission. In the case of a retransmission, the master AP simply repeats the entire joint transmission process, including the data distribution phase.

[0149] Alternatively, after each joint transmission, the slave AP does not delete the JT data from the memory, but can only keep one JT data in the memory at any time. If new JT data is received from the master AP, the slave AP will replace the existing JT data (if any). In both cases, it can be seen that in the case of transmission failure, the retransmission overhead is high due to the redistribution of data to the slave APs.

[0150] Fig. 22 A joint transmission 2200 is shown according to an example embodiment, where the STA fails to receive the JT data frame, and the slave AP also processes the Ack frame, and the master AP repeats the joint transmission without repeating the data distribution.

[0151] like Fig. 22 As shown, the slave AP actively participates in the acknowledgment process for joint transmission. As described below, the JT data is retained by the slave AP until successfully acknowledged or the retry limit is reached (i.e., the slave AP also follows the retransmission process normally followed by the sender).

[0152] 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 joint transmission data is deleted. If an ACK frame is not received, the joint transmission 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 joint transmission MSDU and increments the counters for each joint retransmission. When either retry limit is reached, the corresponding joint transmission MSDU is discarded. The retry limits are synchronized between all participating APs, i.e., they should be the same value.

[0153] In case of transmission failure, the primary AP only repeats the joint transmission. Data distribution is not repeated. During retransmission, data distribution on the backhaul is skipped. In addition, the JT trigger frame that initiates the joint retransmission may specify a more robust transmission mode (lower MCS, etc.) or may specify different PHY coding (for example, if HARQ retransmission is used).

[0154] Fig.23 A joint transmission 2300 is shown according to an example embodiment, wherein the STA fails to receive the JT data, and the slave AP also processes the Block Ack frame and deletes the JT data.

[0155] This figure shows an example of an aggregate transmission using block acknowledgment. During a joint transmission, the AP jointly transmits an A-MPDU carrying an aggregate of multiple MPDUs, and the target STA responds by sending a Block Ack frame addressed to the master AP to acknowledge those MPDUs that were successfully received. In this example, the slave AP also processes the Block Ack (BA) frame from the target STA (addressed to the master AP) as if the Block Ack frame was addressed to the slave AP. If the Block Ack frame indicates that the MPDU was received, the MPDU is deleted from the local buffer. If the Block Ack frame indicates that the MPDU was not received, the MPDU is retained for possible retransmission. Fig.23In the example, during the initial joint transmission, MPDUs with sequence numbers 1 to 10 are jointly transmitted, however, the target STA fails to receive the MPDUs with sequence numbers 5 and 6, and the Block Ack frame reports that the MPDUs with sequence numbers 5 and 6 are not received. After processing the Block Acks from AP1 and AP2, the transmitted MPDUs are deleted except for the MPDUs with sequence numbers 5 and 6. Subsequently, the master AP sends a JT trigger frame indicating the retransmission of the MPDUs with sequence numbers 5 and 6, as well as the retransmission of the MPDUs with sequence numbers 11 to 20. Since the slave APs retain the MPDUs, the master AP does not need to redistribute the MPDUs with sequence numbers 5 and 6 to the slave APs. The processing burden of the slave APs is increased due to the need to decode ACK / BA and maintain the retry counter, but the data distribution overhead of the retransmission is eliminated.

[0156] The slave AP may also delete the saved JT data based on a lifetime timer or when the AP coordination session is terminated (if the session is established). In addition, based on the BA bitmap, the MSDU that has been successfully received by the target STA is deleted.

[0157] Fig.24 A joint transmission 2400 is shown according to an example embodiment, wherein the STA fails to receive JT data and the master AP fails to receive a Block Ack frame and error recovery from the target STA.

[0158] This figure shows an example of error recovery when the slave AP receives the Ack / BA frame but the master AP fails to receive the Ack / BA frame for some reason. This may happen, for example, if the master AP is farther away from the target STA than the slave AP, or simply due to hidden node interference, etc.

[0159] As discussed more fully below, the slave AP may have 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 notify the master AP about the deleted JT data and the reason for the deletion. The master AP retransmits only the failed MPDU.

[0160] Since the slave APs receive BA frames acknowledging that the MPDUs (sequence numbers 1-4, 7-10) have been successfully received, they can delete these MPDUs from memory. However, since the master AP fails to receive the Block Ack (BA) frame, it can assume that the initial joint transmission has failed and initiate a joint retransmission of all MPDUs by sending a JT Trigger frame referencing the MPDUs with sequence numbers 1–10.

[0161] SIFS after the JT trigger frame, the master AP sends a JT PPDU. Since 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. Since this is a single AP transmission, the target STA cannot receive the entire JTP PDU. Based on the content of the JT trigger frame, the slave AP can infer that the master AP did not receive the BA frame. To prevent the master AP from continuing to repeat such retransmission attempts, the slave AP can send an AP coordination information response frame to the master AP to report that some of the MPDUs referenced in the JT trigger frame have been deleted, and also indicate the reason for the deletion (e.g., success confirmation). The master AP can then continue to selectively retransmit only the failed MPDUs (i.e., MPDUs with sequence numbers 5, 6).

[0162] Fig.25 An AP coordination information response frame 2500 and a table 2510 with deletion reasons are shown according to an example embodiment.

[0163] The AP coordination information response frame 2500 includes deleted JT data 2520 reported to the master AP. The deleted JT data 2520 includes a deletion reason (as shown in table 2510), a starting sequence number, and a sequence number bitmap, which together indicate the sequence number of the MPDU deleted from the AP.

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

[0165] The slave AP informs the master AP of the currently saved JT data using the AP coordination information response frame 2500. If a JT trigger frame referencing JT data that has been deleted from the slave APs memory is received, an AP coordination information response frame is sent.

[0166] Upon receiving the AP coordination information response frame 2500 from the slave AP, the master AP decides the next action based on the deletion reason. Consider an example of exceeding the lifetime. In this case, joint transmission may not even be attempted. The master AP can redistribute the JT data to the slave AP and attempt joint transmission.

[0167] Consider another example where the reason is reaching the retry limit. In this case, despite the high number of joint transmissions, the transmission failed, so the master AP may give up the transmission if the retry limit is reached.

[0168] Consider another example where the reason is a successful confirmation. In this case, the master AP knows the JT data (MPDU) whose transmission failed, so the master AP can retransmit only the failed JT data that was not deleted. The JT data that has been successfully confirmed will be omitted from the joint retransmission.

[0169] Fig.26A wireless network 2600 is shown according to an example embodiment and wireless transmissions with STAs in backhaul and fronthaul BSSs.

[0170] The 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 for communication between APs, while the fronthaul BSS is used for communication between APs and STAs. Figure 2630 shows the transmission links between APs in the backhaul and fronthaul BSSs. The thick dotted lines represent the transmission links between APs in the backhaul BSS, while the thin dotted lines represent the transmission links between APs and STAs in the fronthaul BSS. In this network structure, the master AP may include a logical backhaul AP and a logical fronthaul AP, and the slave AP may include a logical backhaul STA associated with the backhaul AP and the logical fronthaul AP. The STA is associated with the fronthaul AP of the master AP or the slave AP. The MAC addresses of the fronthaul and backhaul entities in each AP may be different.

[0171] To make it easier for the slave AP to identify the Ack / BA frames for joint transmissions, the master AP may also assign a unique MAC address to be used as the TA (transmitter address) in the MAC header of the joint transmission frame (see, for example, Fig. 20 This type of MAC address may be called a Joint Transport Address (JT TA) or a Joint Transport MAC address.

[0172] Here is an example: the MAC address of the backhaul AP can be used as the TA for the joint transmission. This could also be the BSSID of the backhaul BSS. Here, only the Ack / BA frames whose RA field is set to JT TA are processed from the AP. In this case, the target STA also needs to know the JT TA. Before the joint transmission, the associated AP notifies the target STA of the JT TA, and the target STA saves the JT TA in memory. Due to the existence of the JT TA, the STA also knows the joint transmission.

[0173] The master AP may dynamically switch between single AP transmission to joint transmission based on channel conditions, and the assignment of sequence numbers to MPDUs may become an issue. For example, initially, even after using the most robust MCS, the AP may attempt single AP transmission and switch to multi-AP joint transmission upon repeated failures of single AP transmission, etc. To simplify sequence number planning, for transmissions to a specific target STA, the master AP may use a running sequence number 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 sorting for the target STA is easy because the MPDUs can be sorted based on sequence numbers regardless of the TA (JT TA or the master AP's MAC address). In contrast, the block Ack scoreboard process at the slave AP may be slightly more complicated because only a portion of the scoreboard bitmap can be used during joint transmission confirmation.

[0174] Figure 27-32 Two further example embodiments are shown ( Figure 27-29 An embodiment is shown. Figure 30-32 ). In these embodiments, the slave AP does not actively participate in the acknowledgment process for joint transmission. Only the master AP or the AP whose MAC address appears in the TA field of the frame of the joint transmission needs to process the Ack / BA frame. This reduces the frame processing burden on the slave AP.

[0175] exist Figure 27-29 In , it is assumed that the target STA immediately acknowledges each joint transmission without using non-immediate BA. Non-immediate Block Ack here refers to a transmission that sets the Ack policy of the transmitted frame to Block Ack. In this case, the addressed receiver does not take any action upon receiving the frame and only records the status. The receiver can expect a Block Ack Request frame or an implicit Block Ack request in the future.

[0176] The JT Trigger frame has two purposes. First, the JT Trigger frame is used for the initial (explicit) purpose of initiating a joint transmission and referencing the JT data to be jointly transmitted. Second, the JT Trigger frame has a new purpose (implicit) to indicate the transmission status of an early joint transmission.

[0177] Fig. 27 A joint transmission 2700 is shown according to an example embodiment, where a STA fails to receive JT data and a JT trigger frame is used from an AP to delete the JT MPDU.

[0178] In this figure, the slave AP uses the contents of the JT Trigger frame to delete the JT MPDUs that were inferred to be successfully transmitted. If no MPDUs are listed for retransmission, the MPDUs that were jointly transmitted will be deleted. The master AP can also use the JT Trigger frame alone to signal the slave AP to flush its JT MPDUs.

[0179] Based on the list of MPDUs to be jointly transmitted, the AP infers the MPDUs that have been successfully transmitted and meet the discard criteria. In addition, the JT trigger frame that lists the new (unsaved) MPDU triggers the deletion of the old MPDU. Fig. 27 In FIG. 5 , during the initial joint transmission, MPDUs with sequence numbers 1 to 10 are jointly transmitted, however, the target STA fails to receive the MPDUs with sequence numbers 5 and 6, and a Block Ack frame reports that the MPDUs with sequence numbers 5 and 6 have not been received. After processing the Block Ack, the master AP sends a JT Trigger frame indicating the retransmission of the MPDUs with sequence numbers 5 and 6, as well as the retransmission of the MPDUs with sequence numbers 11 to 20. Based on the content of the JT Trigger frame, the slave AP infers that the STA has successfully received the MPDUs with sequence numbers 1 to 4 and sequence numbers 7 to 10, and can proceed to delete them. All APs will also continue to jointly transmit the MPDUs with sequence numbers 5 and 6 and sequence numbers 11 to 20. Upon successful reception of all MPDUs, the target STA responds with a Block Ack frame indicating the same. Since the master AP has no more MPDUs to be jointly transmitted, it sends a special purpose JT Trigger frame that lists the previously unsent MPDU with sequence number 21. The only purpose of the JT Trigger frame is to trigger a buffer flush at the slave AP. Upon receiving a JT trigger frame listing a new (unsaved) MPDU with sequence number 21, the slave AP proceeds to delete old MPDUs saved in its buffer.

[0180] Fig.28 A joint transmission 2800 is shown according to an example embodiment, wherein a STA fails to receive JT data and relays information about an acknowledgment frame from an AP to a master AP.

[0181] The figure shows a deployment scenario where the target STA is associated with a slave AP, while the master AP does not participate in the actual joint transmission. Only the slave APs participate in the actual joint transmission. The RA field of the Ack / BA frame is set to the MAC address of one of the slave APs. The master AP may not receive / process the Ack / BA frame for the joint transmission and needs the slave AP to relay such information to it so that it can make decisions about retransmissions.

[0182] In this example, the target STA is associated with slave AP1, so the Block Ack is addressed to slave AP1. Since slave AP1 receives the Block Ack frame, it can delete the MPDU based on the content of the Block Ack frame and does not need to wait for the subsequent JT trigger frame to make a deletion decision. In addition, slave AP 1 also forwards the content of the Block Ack to the master AP. Other slave APs, namely slave AP2 in this example, do not need to explicitly participate in the confirmation process for joint transmission, but can use subsequent JT trigger frames to decide whether to delete the sent MPDU, as described above. Only associated APs participate in processing Ack / BA frames.

[0183] Fig.29 is an AP coordination information response frame 2900 according to an example embodiment, which may be used by a slave AP to forward the contents of a received Ack / Block Ack frame to a master AP.

[0184] If the target STA is associated with a slave AP, the slave AP forwards the contents of the Ack frame or Block Ack frame received from the target STA to the master AP using the AP coordination information response frame 2900. If no Ack / BA frame is received from the target STA, the slave AP does not send an AP coordination information response frame.

[0185] The frame body includes Ack information 2910, which carries the content of the Ack frame or Block Ack frame received from the target STA. Ack information 2910 includes a BA control field and a BA information field. If the information of the Ack frame is forwarded, the BA control field contains the sequence control field of the Ack frame and the BA information field is omitted. If the information of the Block Ack frame is forwarded, the BA control field and BA information field of the received Block Ack frame are copied to the corresponding fields of the Ack information field.

[0186] In addition, if the Ack information field is included in the frame body and the Ack / BA field indicates whether the Ack information field 2910 carries the content of an Ack frame or a Block Ack frame, for example, a value of 0 signaling an Ack frame and a value of 1 signaling a Block Ack frame, the Ack information 2920 is set to 1.

[0187] Fig.29 The implementation of frames reduces the data distribution overhead while keeping the operation from the AP simple.

[0188] Fig.30 is a JT trigger frame 3000 according to an example embodiment, which has an explicit indication to flush the buffer.

[0189] The JT trigger frame 3000 includes a flush buffer field 3010 with an indication of whether to flush the buffer (i.e., 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 a JT identifier (sequence number or JT packet ID) not listed in the JT trigger frame is deleted from the AP memory. If the flush buffer bit is set to 0, the stored JT data is retained.

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

[0191] Fig.31 A joint transmission 3100 is shown according to an example embodiment, where the STA fails to receive JT data and supports non-immediate Block Ack for the joint transmission.

[0192] This figure shows an example of a transmit diversity or SU-MIMO case when non-immediate Block Ack is supported for a joint transmission. Non-immediate Block Ack refers to a transmission where the Ack policy is set to Block Ack. In this case, the addressed receiver takes no action upon receipt of the frame and only records the status. The receiver can expect a Block Ack Request frame or an implicit Block Ack Request in the future.

[0193] During a joint transmission, if the Ack policy of the jointly transmitted frame is set to "Block Ack", the target STA does not respond immediately, but waits for a Block Ack Request frame to send back a Block Ack frame. In this case, it is possible that two or more sets of JT trigger frames and JT PPDUs are sent one after another before receiving an acknowledgment of the previous joint transmission. To prevent subsequent JT trigger frames from triggering the deletion of JT data sent earlier in this transmission burst, the "Flush Buffers" indication is set to disabled (0) during the initial joint transmission even before any acknowledgment is received from the target STA about the reception status. The master AP can set the "Flush Buffers" indication in the JT trigger frame to enabled (1), indicating that a joint retransmission is initiated, to signal to the slave AP that the previously transmitted JT data that is not referenced in this JT trigger frame can now be safely deleted.

[0194] Therefore, the JT trigger frame can carry explicit instructions (e.g., via setting a bit to 1 or 0) to decide whether to flush the slave AP 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 the JT packet with ID 5 will be jointly retransmitted. In addition, the JT trigger frame [JT packet ID = 6, FB = 1] that lists new (unsaved) JT data and FB = 1 triggers the deletion of all old JT data.

[0195] Fig.32 A distributed MU-MIMO joint transmission 3200 is shown according to an example embodiment, where the STA fails to receive JT data and supports non-immediate Block Ack for joint transmission.

[0196] This figure is an example of a distributed MU-MIMO case for a joint transmission to two target STAs at the same time. The use of the Flush Buffer Indication is the same as some differences in the signaling of the JT data in the JT Trigger frame. As a difference, different data is transmitted to different STAs through different spatial streams during the joint transmission, and the JT data of different target STAs may be different in the same joint transmission. As another difference, the MU-BAR frame (Multi-User Block Ack Request frame) is used to request the Block Ack frame from the target STA.

[0197] Fig.33 A joint transmission 3300 is shown according to an example embodiment, wherein a STA fails to receive JT data and a dedicated frame indicating deletion of the stored JT data from the AP.

[0198] A dedicated frame is defined that is used by the master AP to instruct the slave AP to delete the saved JT data. The slave AP retains the saved JT data until the frame is received. The JT Trigger frame is only used to initiate a joint transmission (i.e., not used to decide when to flush the buffer).

[0199] This figure shows an example embodiment where the master AP is fully responsible for how long the slave APs retain JT data. The master AP uses a different frame (AP coordinated data refresh) to instruct the slave APs to flush their buffers. The slave APs retain all JT data until an AP coordinated data refresh is received indicating that the JT data can be deleted.

[0200] Fig.34 A table 3400 of AP coordination session action field values ​​and an AP coordination data refresh frame 3410 are shown according to an example embodiment.

[0201] The master AP indicates deletion of the saved JT data from the AP using an AP coordination data refresh action frame 3410. The AP coordination data refresh frame may be an AP coordination action frame (AP coordination data refresh) with the AP coordination session action field set to 5. The AP coordination data refresh frame may be sent after each Ack / BA received by the master AP, or may be sent upon completion of the entire joint transmission (including retransmissions).

[0202] The frame includes a data flush field 3420 having a starting sequence number field and a sequence number bitmap field, which together indicate the sequence number of the MPDU that can be deleted from the buffer of the slave AP. When used at the end of a joint transmission burst, the value of the starting sequence number field can be set to a value greater than the largest sequence number in the saved JT data, in which case all saved JT data is flushed from the AP (regardless of the previous transmission status). In this case, the sequence number bitmap can be set to all zeros to distinguish this special use.

[0203] Fig.35 is an example of an electronic device 3500 according to an example embodiment.

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

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

[0206] The electronic device 3500 includes circuitry for receiving (e.g., at a wireless receiver) a joint transmission (JT) trigger frame from another AP indicating 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 distributed by another AP for joint transmission.

[0207] In an example embodiment, JT buffer management 3562 decides how long JT data should be retained in JT data buffer 3556. JT buffer management 3562 is also responsible for processing Ack / BA frames, JT trigger frames, or AP coordinated data refresh frames to reach such a decision.

[0208] The electronic device 3500 includes a circuit for generating a frame including JT data and a JT identifier that uniquely identifies the JT data. For example, the JT identifier generator block 3554 is responsible for generating a JT identifier corresponding to the JT data distributed to the slave AP. The JT data encapsulation / decapsulation block 3558 is used by the master AP to encapsulate the JT data in an 802.11 data frame or an 802.3 Ethernet frame during the data distribution phase. The slave AP uses this block to decapsulate the JT data received from the master AP. The JT data buffer 3556 stores JT data for joint transmission. In the master AP, this may not be a separate buffer, but a shared buffer that stores all outgoing data frames. In the slave AP, this can be a separate buffer dedicated to storing data frames for joint transmission. The electronic device 3500 also includes circuits, such as a wireless transmitter and / or antenna 3570, which enables the AP to send data frames to one or more communication devices, such as one or more STAs in a wireless network.

[0209] The present invention can be implemented by software, hardware, or software and hardware. Each functional block used in the description of each of the above embodiments can be partially or entirely implemented by an LSI such as an integrated circuit, and each process described in each embodiment can be partially or entirely controlled by the same LSI or a combination of LSIs. The LSI can be formed as a chip alone, or a chip can be formed to include some or all of the functional blocks. The LSI may include data inputs and outputs coupled thereto. Depending on the degree of integration, the LSI here may be referred to as an IC, a system LSI, a super LSI, or an ultra LSI. However, the technology for implementing an integrated circuit is not limited to LSI, and can be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. In addition, an FPGA (field programmable gate array) or a reconfigurable processor that can be programmed after manufacturing the LSI can be used, wherein the connection and setting of the circuit unit arranged inside the LSI can be reconfigured. The present invention can be implemented as digital processing or analog processing. If future integrated circuit technology replaces LSI due to the advancement of semiconductor technology or other derivative technologies, the functional blocks can be integrated using future integrated circuit technology. Biotechnology can also be applied.

[0210] The present invention can be implemented by any type of device, apparatus or system having a communication function, which is referred to as a communication device.

[0211] The communication device may include a transceiver and processing / control circuits. The transceiver may include and / or function as a receiver and a transmitter. The transceiver as a transmitter and a receiver may include an RF (radio frequency) module including an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

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

[0213] The communication devices are not limited to portable or movable, and may also include any type of device, equipment, or system that is non-portable or fixed, such as smart home devices (e.g., appliances, lighting, smart meters, control panels), vending machines, and any other "things" in an "Internet of Things (IoT)" network.

[0214] Communications may include exchanging data via, for example, cellular systems, wireless LAN systems, satellite systems, etc., and various combinations thereof.

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

[0216] The communication devices may also include infrastructure such as base stations, access points, and any other devices, equipment, or systems that communicate with or control devices such as the above non-limiting examples.

[0217] Other example embodiments include, but are not limited to, the following examples.

[0218] One example embodiment is an access point (AP) comprising: a receiver that receives a joint transmission (JT) trigger frame from another AP, the joint transmission (JT) trigger frame 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.

[0219] 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 local memory.

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

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

[0222] The AP further includes a transmitter that, when not possessing the MPDU indicated in the JT trigger frame to be jointly transmitted, transmits a frame including a sequence number value of the MPDU deleted from the local memory and a reason for deleting the MPDU from the local memory to another AP.

[0223] The receiver also receives an acknowledgment (ACK) frame or a block Ack (BA) frame from the communication device confirming successful reception of an MPDU jointly transmitted by one or more other APs and the AP, and the ACK frame or the BA frame is addressed to the AP; and the AP also includes: a transmitter that sends a frame carrying the content of the ACK frame or the BA frame to another AP.

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

[0225] The JT trigger frame indicates that the MPDUs are to be jointly transmitted again to the communication device.

[0226] Another example embodiment is a method comprising: receiving, at an access point (AP), a joint transmission (JT) trigger frame from another AP, the joint transmission (JT) trigger frame indicating a MAC protocol data unit (MPDU) to be jointly transmitted to a communication device; and storing, in a local memory of the AP, one or more MPDUs previously transmitted to the communication device.

[0227] Another example embodiment is a method comprising: determining at an access point (AP) that a communication device has failed to receive one or more MAC protocol data units (MPDUs) transmitted jointly 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.

[0228] Another example embodiment is an access point (AP) including: a transmitter that transmits a MAC protocol data unit (MPDU) to a communication device in conjunction with another AP; and a receiver that 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, the MPDU having a sequence control value acknowledged by the ACK frame or the BA frame that is successfully received by the communication device.

[0229] The AP also saves the MPDUs having sequence control values ​​that were not acknowledged as successfully received by the communication device in a local memory of the AP.

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

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

[0232] Another example embodiment is a communication device including: a receiver that receives a JT MAC address assigned for joint transmission from an associated AP; and a local memory that stores the JT MAC address; and the receiver further receives an MPDU having a transmitter address (TA) field set to the JT MAC address.

[0233] The communication device also includes a transmitter that transmits an ACK frame or a BA frame in which a receiver address (RA) field is set to the JTMAC address and acknowledges the received MPDU.

[0234] Although exemplary embodiments have been presented in the foregoing detailed description of the present embodiment, it should be understood that there are a large number of variations. It should also be understood that the exemplary embodiments are only examples and are not intended to limit the scope, applicability, operation or configuration of the present invention in any way. On the contrary, the foregoing detailed description will provide a convenient roadmap for implementing exemplary embodiments of the present invention for those skilled in the art, and it should be understood that various changes can be made to the functions and arrangements of the steps and operating methods described in the exemplary embodiments without departing from the scope of the present invention as described in the protection scope of the attached application.

Claims

1. An access point AP, comprising: circuit, encapsulates multi-AP transmission data, and generates a data frame including the encapsulated multi-AP transmission data and a multi-AP transmission group ID assigned to the encapsulated multi-AP transmission data, The transmitter sends the data frame to the slave AP and sends a first multi-AP transmission trigger frame including the assigned multi-AP transmission group ID for starting multi-AP transmission, The circuit determines that the following situation is a failure: the communication device receives more than one MAC protocol data unit MPDU of the data frame jointly transmitted to the communication device by the AP and the slave AP in the multi-AP transmission, The transmitter transmits a second multi-AP transmission trigger frame including the assigned multi-AP transmission group ID to the slave AP without redistributing the failed MPDU to the slave AP.

2. The AP according to claim 1, wherein: The second multi-AP transmission trigger frame indicates the MPDU to be jointly transmitted to the communication device.

3. A method comprising: Encapsulate multi-AP transmission data at the access point AP; generating, at the AP, a data frame including the encapsulated multi-AP transmission data and a multi-AP transmission group ID assigned to the encapsulated multi-AP transmission data; Sending the data frame to a slave AP through the AP; Sending, by the AP, a first multi-AP transmission trigger frame for starting multi-AP transmission, including the assigned multi-AP transmission group ID; At the AP, determining that the following situation is a failure: the communication device receives more than one MAC protocol data unit (MPDU) of the data frame jointly transmitted to the communication device by the AP and the slave AP in the multi-AP transmission; A second multi-AP transmission trigger frame including the assigned multi-AP transmission group ID is transmitted to the slave AP by the AP without redistributing the failed MPDU to the slave AP.

4. An integrated circuit that controls the following processes: Processing of encapsulating multi-AP transmission data at access point AP; generating, at the AP, 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; sending the data frame to a slave AP through the AP; Sending, by the AP, a process of sending a first multi-AP transmission trigger frame for starting multi-AP transmission, including the assigned multi-AP transmission group ID; At the AP, determining that the following situation is a failure: a process in which the communication device receives more than one MAC protocol data unit (MPDU) of the data frame jointly transmitted to the communication device by the AP and the slave AP in the multi-AP transmission; A second multi-AP transmission trigger frame including the assigned multi-AP transmission group ID is transmitted to the slave AP by the AP without redistributing the failed MPDU to the slave AP.

Images