COMMUNICATION DEVICE AND METHOD FOR MULTILINK BLOCK ACKNOWLEDGMENT - Patent application

Abstract

A communications device and method for multilink block acknowledgment is provided, comprising: a first multilink device, circuitry having a link established between each station of a first plurality of stations and a corresponding station of a second plurality of stations; a transmitter, the first plurality of stations configured to share a common transmit buffer for storing frames of a TID to be transmitted to the second multilink device and a common transmit buffer control for managing transmission of the frames on one or more links, and each of the first plurality of stations configured to maintain a per-link transmit buffer control for managing transmission of the frames on a corresponding one of the one or more links.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate generally to communication devices, and more particularly to methods and devices for multilink block acknowledgment involving multilink traffic streams. [Background technology]

[0002] Today, communication devices are expected to perform the same functions as wired computing devices, but wirelessly. For example, users expect to be able to seamlessly watch high-definition movies streamed to their wireless communication devices. This creates challenges for the communication devices and the access points to which they connect wirelessly.

[0003] The Institute of Electrical and Electronics Engineers (IEEE) 802.11 Group recently formed the Extreme High Throughput (EHT) Study Group to address these challenges. Multi-link operation in the 2.4 GHz, 5 GHz, and 6 GHz frequency bands has been identified as an important candidate technology for such communications. Multi-channel aggregation across multiple links is a natural way to increase communication data throughput several times. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] IEEE 802.11 REVmd_D3.0, 10.25.6.3 -Scoreboard context control during full-state operation Summary of the Invention [Problem to be solved by the invention]

[0005] In current IEEE 802.11 devices, when admission control is mandated for an Access Category (AC) by an Access Point (AP) (e.g., via the Admission Control Mandatory (ACM) subfield in the Enhanced Distributed Channel Access (EDCA) parameter set element), a communication device (STA) must set up a traffic stream (TS) for that AC with the AP (via an Add Traffic Stream (ADDTS) request / response exchange) and also perform a Block Acknowledgment agreement (via an Add Block Ack (ADDBA) request / response exchange) targeting the corresponding TID. [Means for solving the problem]

[0006] One non-limiting, exemplary embodiment facilitates providing a first multilink device configured to operate with a first plurality of associated stations, the first multilink device comprising: circuitry for, in operation, initiating setup of a block acknowledgment agreement with a second multilink device configured to operate with a second plurality of associated stations, wherein a link is established between each station of the first plurality of stations and a corresponding station of the second plurality of stations; and a transmitter for, in operation, transmitting frames of a Traffic Identifier (TID) over one or more links to the second multilink device based on the block acknowledgment agreement, the first plurality of stations being configured to share a common transmit buffer that stores frames of the TID to be transmitted to the second multilink device and a common transmit buffer control that manages transmission of frames over the one or more links, and each of the first plurality of stations being configured to maintain a per-link transmit buffer control that manages transmission of frames on a corresponding one of the one or more links.

[0007] Another non-limiting, exemplary embodiment facilitates providing a method of multi-link communication, the method including: initiating, at a first multi-link device, setup of a block acknowledgement agreement with a second multi-link device configured to operate with a second plurality of stations, the first multi-link device being configured to operate with the first plurality of stations, wherein a link is established between each station of the first plurality of stations and a corresponding station of the second plurality of stations; and transmitting frames of a traffic identifier (TID) to the second multi-link device over one or more links based on the block acknowledgement agreement, the first plurality of stations being configured to share a common transmit buffer that stores frames of the TID to be transmitted to the second multi-link device and a common transmit buffer control that manages transmission of the frames over the one or more links, wherein each of the first plurality of stations is configured to maintain a per-link transmit buffer control that manages transmission of the frames on a corresponding one of the one or more links.

[0008] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any selective combination thereof. Additional benefits and advantages of the disclosed embodiments will be apparent from the specification and drawings. Benefits and / or advantages may be obtained individually from various embodiments and features of the specification and drawings, and not all need be provided to obtain one or more of such benefits and / or advantages. [Brief explanation of the drawings]

[0009] The accompanying drawings, which together with the following detailed description are incorporated in and constitute a part of this specification, illustrate various embodiments and serve to explain various principles and advantages according to the present embodiments. Throughout the different drawings, like reference numerals indicate identical or functionally similar elements. [Figure 1] 1 shows an illustration of an overview of an 802.11 wireless network basic service set (BSS) in accordance with various embodiments. [Figure 2] 1 shows an illustration of communication from an originator Multilink Device (MLD) to a recipient MLD according to various embodiments. [Figure 3] 1 illustrates an illustration of setting up a traffic stream (TS) and block ACK (BA) agreement for a traffic identifier (TID), according to various embodiments. [Figure 4] 1 illustrates a communication flow between an AP MLD 102 and a non-AP MLD 104 that communicate after setting up TS and BA over multiple bands / links according to current multi-link communication. [Figure 5] 1 illustrates a communication flow between an AP MLD 102 and a non-AP MLD 104 communicating after setting up a multilink TS and a multilink BA, according to various embodiments. [Figure 6] 1 illustrates an illustration of multi-link enhanced distributed channel access (EDCA) parameter set elements in accordance with various embodiments. [Figure 7] 1 illustrates an illustration of a Multilink ADDTS request frame and a Multilink ADDTS response frame according to various embodiments. [Figure 8] 1 illustrates an illustration of a multilink ADDBA request frame and a multilink ADDBA response frame according to various embodiments. [Figure 9] 9 shows an illustration of the multi-band elements of FIGS. 7 and 8, according to various embodiments. [Figure 10] 1 illustrates an illustration of a multi-band capability element according to various embodiments. [Figure 11]1 shows an illustration of a multilink BlockAckReq frame and a multilink BlockAck frame according to various embodiments. [Figure 12A] 1 illustrates an architectural diagram of a traffic stream and Block Ack in accordance with various embodiments. [Figure 12B] 1 illustrates an illustration of a traffic stream and Block Ack architecture defined to handle Multilink Transmission and Multilink Block Ack, according to various embodiments. [Figure 13] 1 illustrates an exemplary multi-link transmission diagram in accordance with various embodiments. [Figure 14] 1 illustrates an illustration of an exemplary reference model for a Multilink Block Ack implementation according to various embodiments. [Figure 15A] 10 illustrates an illustration of a situation in which an unsuccessful multilink transmission can result in an out-of-bounds scoreboard context and receive reordering buffer overflow, according to various embodiments. [Figure 15B] 10 illustrates an illustration of a situation in which an unsuccessful multilink transmission can result in an out-of-bounds scoreboard context and receive reordering buffer overflow, according to various embodiments. [Figure 15C] 10 illustrates an illustration of a situation in which an unsuccessful multilink transmission can result in an out-of-bounds scoreboard context and receive reordering buffer overflow, according to various embodiments. [Figure 15D] 10 illustrates an illustration of a situation in which an unsuccessful multilink transmission can result in an out-of-bounds scoreboard context and receive reordering buffer overflow, according to various embodiments. [Figure 16] 16 shows an illustration of a Multilink Block Ack architecture 1600 according to a present embodiment. [Figure 17A] 17 shows an illustration of a multilink Block Ack parameter set 1700 and a multiband element 1710 for use in the Block Ack architecture 1600, according to the present embodiment. [Figure 17B] 17 shows an illustration of a multilink Block Ack parameter set 1700 and a multiband element 1710 for use in the Block Ack architecture 1600, according to the present embodiment. [Figure 18] 18 illustrates the format of an extended BlockAck Request (eBAR) frame 1800 for use in the multilink Block Ack architecture 1600, according to a present embodiment. [Figure 19] FIG. 15A shows an illustration of how the eBAR frame 1800 can be used to solve a problem outside of the scoreboard context described above. [Figure 20] 16 shows an illustration of how the common transmit buffer controller of the Multilink Block Ack architecture 1600 prevents the receive reordering buffer overflow problem shown in FIGS. 15C and 15D. [Figure 21] 21 shows an illustration of a Multilink Block Ack architecture 2100 with a common Multilink Scoreboard Context Controller according to a variation of the present embodiment. [Figure 22A] 2 shows an illustration of a multilink Block Ack parameter set 2200 and a multiband element 2210 for use in the Block Ack architecture 2100, according to a present embodiment. [Figure 22B] 2 shows an illustration of a multilink Block Ack parameter set 2200 and a multiband element 2210 for use in the Block Ack architecture 2100, according to a present embodiment. [Figure 23A] 23 shows an illustration of an ADDBA request frame 2304, an ADDBA response frame 2306, a Block Ack parameter set 2300, and a multilink element 2310 according to another variation of this embodiment. [Figure 23B]23 shows an illustration of an ADDBA request frame 2304, an ADDBA response frame 2306, a Block Ack parameter set 2300, and a multilink element 2310 according to another variation of this embodiment. [Figure 23C] 23 shows an illustration of an ADDBA request frame 2304, an ADDBA response frame 2306, a Block Ack parameter set 2300, and a multilink element 2310 according to another variation of this embodiment. [Figure 24] 2 shows a schematic diagram of an originator MLD 2400 according to various embodiments. [Figure 25] 2 shows a schematic diagram of a receiver MLD 2500 according to various embodiments. [Figure 26] 2 shows a flowchart 2600 illustrating a method for multi-link communication according to various embodiments. [Figure 27] 27 shows a schematic partial cross-sectional view of a multi-link device 2700 that can be implemented for multi-link communication according to the various embodiments shown in FIGS. 1-26. [Figure 28] 2 shows a detailed block diagram of a multi-link device according to the present embodiment;

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

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

[0012] Referring to FIG. 1, this figure shows an overview of an 802.11 wireless network 100, also known as a basic service set (BSS), which includes an access point (AP) 102 and multiple communication devices (STAs) 104 connected to the AP 102. The AP 102 provides the STAs with access to a distribution system (DS), such as the Internet. Current IEEE 802.11 BSSs operate in a single frequency band, with APs capable of operating simultaneously in multiple frequency bands operating as independent (single-link) APs in each frequency band. While most current 802.11 STAs are single-band devices and can only participate in one BSS (in a particular frequency band) at a time, future 802.11 communication devices (e.g., EHT (very high throughput) communication devices) are expected to operate simultaneously in multiple frequency bands. Multi-link capable STAs are sometimes referred to as non-AP MLDs. Such a non-AP MLD can simultaneously participate in multiple BSSs and establish multiple communication links with APs in multiple frequency bands or on multiple frequency-separated channels in the same frequency band. An AP that can simultaneously communicate with a non-AP MLD through multiple links is sometimes referred to as an AP MLD. In FIG. 1, AP 102 represents the AP MLD, and STA 104 represents the non-AP MLD. Both the AP MLD and the non-AP MLD can simultaneously communicate in the 2.4 GHz, 5 GHz, and 6 GHz frequency bands. Such a future AP 102 could set up separate BSSs for the 2.4 GHz, 5 GHz, and 6 GHz frequency bands, similar to existing 802.11 systems. In this case, legacy STAs could join the BSSs in the three frequency bands using legacy authentication and association procedures. Alternatively, an AP may operate a unified / virtual BSS, such as that shown in BSS 100, that operates in multiple frequency bands (ie, 2.4 GHz frequency band 106, 5 GHz frequency band 108, and 6 GHz frequency band 110).In either case, the STA 104 is assumed to have joined the unified / virtual BSS 100 for all three frequency bands through separate authentication and association requests / responses for each frequency band, or through multi-link setup negotiations (e.g., authentication and association requests / responses) for either frequency band.

[0013] FIG. 2 shows a diagram 200 of communicating a video file 202 from an AP MLD 201 to a non-AP MLD 203. To fully realize the throughput gains of multilink aggregation, a traffic stream (TS) and block acknowledgment (BA) mechanism operating on multiple links is desirable. Such multilink TS and BA can help achieve a multi-fold improvement in device throughput by enabling aggregation of traffic on multiple links (e.g., 2.4 GHz 204, 5 GHz 206, and 6 GHz 208). Setting up a multilink TS is optional if there are no restrictions on traffic for a traffic identifier (TID) on any link, i.e., if admission control for an access category (AC) is not mandated on any link. Streaming high-definition video 206 (e.g., high-definition (HD) or 4K or 8K video) may require such multilink transmission. At the Internet Protocol (IP) layer 210 of the AP MLD 201, the video file 206 is segmented into small IP packets. The 802.11 Media Access Control (MAC) layer 212 of the AP MLD 201 converts the IP packets into 802.11 MAC layer protocol data units (MPDUs) and provides them to the MAC TX queue 214, which provides the MPDUs to transceivers 216, 218, and 220 in the lower MAC layer 212 and physical layer (PHY) 222 for simultaneous transmission in the 2.4 GHz, 5 GHz, and 6 GHz frequency bands, respectively. In this manner, MPDU 224 is transmitted to the non-AP MLD 203 in the 2.4 GHz frequency band, MPDU 226 in the 5 GHz frequency band, and MPDU 228 in the 6 GHz frequency band.

[0014] In non-AP MLD 203, MPDUs 224, 226, 228 are received by transceivers 230, 232, 234 at PHY layer 236 and lower MAC layer 238. The MPDUs 224, 226, 228 are collected by MAC layer 238, reordered if necessary, and then passed to MAC RX queue 240 and provided to IP layer 242, where the IP packets are combined to re-form the original video file 206.

[0015] In current 802.11 communication devices, admission control is typically mandated to maintain QoS (Quality of Service) levels for high-priority traffic such as video (AC_VO) and voice (AC_VI). When admission control is requested for an Access Category (AC) by an AP MLD (e.g., via the Admission Control Mandatory (ACM) subfield of the Enhanced Distributed Channel Access (EDCA) Parameter Set element), a non-AP MLD may be requested to set up a TS for that Access Category (AC) with the AP MLD via an Add Traffic Stream (ADDTS) request / response exchange. The Traffic Specification (TSPEC) element in the ADDTS request and ADDTS response frames specifies various parameters for the TS, such as the Traffic Stream Identifier (TSID), direction, MAC Service Data Unit (MSDU) size, minimum and maximum interval range, and minimum, average, and peak data rates. If there are no restrictions on any link for traffic of an Access Category (AC), i.e., no admission control is mandatory for the AC on any link, then setting up a multilink TS is optional.

[0016] Additionally, Block Acknowledgment agreements covering corresponding TIDs must be performed via Add Block Ack (ADDBA) Request / Response exchanges. Traffic streams and Block Acknowledgment agreements can also be configured for different frequency bands by including multi-band elements in the ADDTS Request / Response and ADDBA Request / Response exchanges, respectively, or via On-Channel Tunneling (OCT).

[0017] Because the uncontrolled addition of new high-priority traffic to a wireless network can adversely affect the QoS of existing traffic, AP MLD typically mandates admission control for such traffic. If the volume of existing traffic is high, AP MLD may reject non-AP MLD requests to set up traffic streams for that Access Category (AC).

[0018] To implement multilink transmission according to this embodiment, TS and BA operations need to be modified because current TS and BA setups are set up between the MAC layer on a specific link. Referring to Figure 3, a diagram 300 shows a Traffic Stream (TS) and Block Ack (BA) agreement for a Traffic Identifier (TID) set up between a multilink sender 302 and a multilink receiver 304 according to this embodiment. The TS and BA agreements are typically set up as a pair, with the BA agreement set up in the opposite direction to the TS direction. TSs 306, 308, and 310 are set up between the transmitting MAC layer 318, 320, and 322 of each link and the corresponding receiving MAC layer 324, 326, and 328 of each link for data transmission from the multilink originator 302 to the multilink receiver 304, while BA agreements 312, 314, and 316 are set up in the opposite direction between the receiving MAC layer 324, 326, and 328 and the transmitting MAC layer 318, 320, and 322, respectively, for transmitting BAs from the multilink receiver 304 to the multilink originator 302 for the purpose of acknowledging the data transmission corresponding to TSs 306, 308, and 310.

[0019] At the multilink sender side, the upper layer 330 and logical link control (LLC) layer 332 decide which link to use for transmission for a particular TID. MPDUs for each TS 306, 308, and 310 are generated by the MAC layer (MAC layer 318, 320, and 322) on the transmitting side of each link and sent to the MAC layer (MAC layer 324, 326, and 328) on the receiving side of the same link. At the receiving side, MAC service data units (MSDUs) received over different links are reordered by the receiving LLC layer 334 and passed to the receiving upper layer 336. Block ACKs (BAs) corresponding to the MPDUs for each TS 306, 308, and 310 are generated by the MAC layer (MAC layer 324, 326, and 328) on the receiving side of the same link and sent to the MAC layer (MAC layer 318, 320, and 322) on the transmitting side of each link. If a BA is not received or if an MPDU is not acknowledged in the BA bitmap (the bit corresponding to the MPDU is set to 0), the unacknowledged MPDU is considered a failed transmission. Retransmission of the unacknowledged MPDU by the MAC layer occurs in the same frequency band (2.4 GHz, 5 GHz, or 6 GHz) as the failed transmission, as shown in Figure 4. Also, instead of setting up traffic streams (TSs) to restrict traffic of specific TIDs to specific links, some kind of TID mapping can be negotiated between the AP MLD and non-AP MLD to map specific TIDs to specific links, e.g., to map video traffic exclusively to the 6 GHz link, audio traffic exclusively to the 5 GHz link, and the remaining traffic to the 2.4 GHz link. In the absence of a TS setup or TID mapping, the default is to assume that traffic of any TID can be transmitted on any link.

[0020] 4 illustrates a communication flow 400 between a multilink originator 302 (in this example, an AP MLD) and a multilink receiver 304 (in this example, a non-AP MLD) for the setup of TSs and BAs and subsequent communication under current multilink communication. If the ACM (Admission Control Required) bit in the EDCA parameter set element received in a beacon frame on any link is set for any access category (AC), the non-AP MLD (e.g., the multilink receiver 304) must set up a traffic stream (TS) for the corresponding TID with the multilink originator 302 before transmitting data frames belonging to that TID / AC on that link. The setup of a TS targeted to a specific TID is performed separately for each link, e.g., for downlink data transmission (i.e., from the AP MLD to the non-AP MLD), by exchanging ADDTS request / response frames on each link. The ADDTS request is always initiated by the non-AP MLD, regardless of the actual direction of data transmission. Similarly, setting up a BA 404 for a particular TID is performed separately for each link by exchanging ADDBA request / response frames on each link. The ADDBA request is initiated by the multilink originator of the corresponding TS. Once the TS and BA are set up on each link, data transmission and corresponding BA transmission can occur on each link, e.g., link 430 in the 6 GHz band, link 440 in the 5 GHz band, and link 450 in the 2.4 GHz band. BlockAck frames for data transmission on each link 430, 440, and 450 are requested via BlockAckReq frames, and the requested BlockAck frames are transmitted on the same link. Because the transmissions on links 430, 440, and 450 are different, these transmissions may occur simultaneously or overlap, thereby achieving multilink transmission.

[0021] If the transmission of a data frame is determined to be unsuccessful (eg, as indicated by a BlockAck frame in data transmission 452), the data frame is retransmitted on the same link (eg, retransmission 454).

[0022] While multilink transmission can be achieved in this manner, the responsibilities for scheduling, band selection, retransmission, and other processing are left to higher layers 330, 336 (FIG. 3), which may not have the necessary information about the physical (PHY) layers 317, 319, 321, 323, 325, 327 to make such decisions. It would be better for the multilink transmission decision to be made in the MAC layer 318, 320, 322, 324, 326, 328, since the MAC layer has better information / control of the PHY layer.

[0023] FIG. 5 illustrates the communication flow between the multilink originator 302 and the multilink receiver 304 during TS and BA setup and subsequent communication according to this embodiment. The multilink originator 302 can choose to listen to beacon frames transmitted on a single link to conserve power. The beacon frame 502 of the primary link (e.g., the 5 GHz band) can carry multi-band EDCA parameter set elements to indicate EDCA parameters for links other than the link on which the beacon frame 502 is transmitted, separate from legacy EDCA parameter set elements. If the ACM bit of the beacon frame 502 is set to “1” for any AC on any link, the multilink receiver 304 is required to set up a traffic stream (TS) targeting the TID corresponding to that AC on the indicated link before transmitting data frames belonging to that TID / AC on that link. Alternatively, the multilink receiver 304 can receive beacon frames with legacy EDCA parameter set elements carrying the ACM bit set to “1” separately on each link.

[0024] If both the sender and receiver support Multilink TS and Multilink BA and indicate the capability in the Multilink TS and Block Ack fields of the Multilink Capability element (the Multilink Capability element including the Multilink TS and Block Ack fields is described in further detail in FIG. 10 ), Multilink TS setup 510 (e.g., for downlink traffic) targeting a specific TID applicable to multiple links (e.g., three bands: 2.4 GHz, 5 GHz, and 6 GHz) can be performed using a single frame exchange (e.g., on the channel of the primary link) in accordance with this embodiment. Similarly, Multilink BA setup 520 targeting a TID applicable to multiple links (e.g., three bands: 2.4 GHz, 5 GHz, and 6 GHz) can be performed using a single frame exchange (e.g., on the channel of the primary link) in accordance with this embodiment. Multilink ADDTS request frame 512 and Multilink ADDTS response frame 514 are used to negotiate TS setup 516 targeting a TID across multiple links. Similarly, a Multilink ADDBA request 522 and a Multilink ADDBA response 524 are used to negotiate a BA setup 526 covering a TID across multiple links. In this downlink traffic example, the Multilink ADDBA request 522 is sent by the AP 102 to the Multilink Receiver 304 (which can be any one of the non-AP MLDs 104). If the Multiband TS setup 510 is for uplink traffic, the Multiband ADDBA request is sent in the opposite direction, i.e., by the Multilink Receiver 304 to the Multilink Originator 302.

[0025] Once the multilink TS and multilink BA are set up on multiple links, the multilink originator 302 can initiate multilink transmission 530 to the multilink receiver 304. The multilink transmission 530 includes simultaneously transmitting frames belonging to the same TS (TID / AC) over the three links to the multilink receiver 304 in QoS Data A-MPDUs 536a, 536b, and 536c, respectively.

[0026] After completing the multilink transmission 530, the multilink originator 302 can send a multilink BlockAckReq 532 to the multilink receiver 304 on any link (e.g., the primary link) to request a multilink Block Ack that acknowledges the frames 536a, 536b, and 536c received on the three links. Upon receiving the multilink BlockAckReq 532 from the multilink originator 302, the multilink receiver 304 sends a multilink Block Ack 534 on the same link on which it received the multilink BlockAckReq 532 to indicate that the multilink receiver 304 successfully received the QoS data A-MPDUs 536a and 536b, but was unable to receive the QoS data A-MPDU 536c transmitted in the 2.4 GHz band. In accordance with this embodiment, the multilink originator 302 may choose to retransmit the QoS data A-MPDU 538 in the 6 GHz band instead of the 2.4 GHz band used for the original transmission in order to use frequency diversity to improve the success rate of the retransmission.

[0027] The Multilink Originator 302 then sends a Multilink BlockAckReq 542 to the Multilink Receiver 304 on a different link (e.g., on the primary 5 GHz link) to request a Multilink Block ACK 544 carrying an aggregated BA bitmap acknowledging the frames received on the 6 GHz band. Thus, according to this embodiment, a single Multilink ADDTS frame exchange (request frame 512, response frame 514) on any one link is used to set up traffic streams across multiple links. Block ACKs are also set up across multiple links using a single Multilink ADDBA frame exchange (request frame 522, response frame 524) on any one link. Furthermore, according to this embodiment, the aggregated Multilink BlockAck frame 534 acknowledges the Multilink aggregated transmission, and the Multilink BlockAck frame 544 can be used to acknowledge transmissions on other links, allowing failed frames 536c to be retransmitted on other links.

[0028] Thus, according to this embodiment, the MLD (e.g., AP 102) includes a plurality of transceivers 216, 218, and 220 that, in operation, transmit signal frames 536c, 536a, and 536b, respectively, over different ones of the plurality of frequency bands 204, 206, and 208. The MLD further includes a medium access control (MAC) layer 212 coupled to the plurality of transceivers 216, 218, and 220, which, in operation, generates a multilink block acknowledgement request frame 532 to request a multilink block acknowledgement frame 534 and transmits the MAC multilink block acknowledgement request frame 532 over one of the plurality of frequency bands 206. The medium access control (MAC) layer 212 subsequently receives a multilink block acknowledgement frame 534 over one of the plurality of frequency bands 206 that acknowledges the signal frames 536a, 536b, and 536c transmitted over the plurality of frequency bands.

[0029] Further, according to this embodiment, the MLD (e.g., the non-AP 104) includes a plurality of transceivers 230, 232, 234 coupled to a MAC layer 238. In operation, the plurality of transceivers 230, 232, 234 receive signal frames 536a, 536b, 536c, respectively, in different frequency bands of the plurality of frequency bands 204, 206, 208. In operation, upon receiving a multilink block acknowledgment request frame 532 on one frequency band 206 of the plurality of frequency bands, the MAC layer 238 generates and transmits a multilink block acknowledgment frame 534 on one frequency band 206 of the plurality of frequency bands that acknowledges the signal frames 536a, 536b, 536c received on the plurality of frequency bands 204, 206, 208.

[0030] FIG. 6 shows a diagram 600 of a multilink EDCA parameter set element 610 in a beacon frame 402 (FIG. 4) according to this embodiment. The multilink EDCA parameter set element 610 indicates EDCA parameters for links other than the link on which the beacon frame 402 is transmitted. The applicable link is indicated by a Band ID field 612. The format of each Parameter Record field 620 targeting a specific AC is shown. If the ACM bit 622 is set to "1" for any AC on any link, the non-AP MLD must set up a traffic stream (TS) targeting the TID corresponding to that AC on the indicated link before transmitting data frames belonging to that TID / AC on that link. Alternatively, instead of the Band ID field 612, a Multi-link field indicating the applicable link may be present in the EDCA parameter set element 610. Alternatively, the non-AP MLD may receive beacon frames with legacy EDCA parameter set elements carrying the ACM bit 622 set to "1" separately on each link.

[0031] Figure 7 shows an illustration 700 of a multilink ADDTS request frame 710 and a multilink ADDTS response frame 720 according to this embodiment, and Figure 8 shows an illustration 800 of a multilink ADDTS request frame 810 and a multilink ADDTS response frame 820 according to this embodiment. The multilink ADDTS request frame 710 and the multilink ADDTS response frame 720 are used to negotiate the setup of a TS covering a TID across multiple links in response to information in one or more multiband elements 750 in the multilink ADDTS request frame 710 and the multilink ADDTS response frame 720, respectively. Similarly, the multilink ADDBA request frame 810 and the multilink ADDBA response frame 820 are used to negotiate the setup of a BA covering a TID across multiple links in response to information in one or more multiband elements 750 in the multilink ADDTS request frame 810 and the multilink ADDTS response frame 820, respectively.

[0032] 9, a diagram 900 illustrates a multi-band element 750 according to this embodiment. The multi-band element 750 indicates the additional band (separate from the link being transmitted) to which the TS or BA agreement applies. The multi-band element 750 may also include the MAC address used on the link.

[0033] The multiband element 750 includes, among other things, a multiband control field 910, which contains several fields, including an inter-band field 920. The inter-band field 920 is used to distinguish the multi-band element for use in multilink TS and BA setup. When the inter-band field 920 is set to '1', it indicates that the corresponding setup applies to the link indicated by the Band ID field 930 in addition to the link on which the frame conveying this element is transmitted. The inter-band field 920 thus serves to distinguish the inclusion of the multi-band element 750 in multilink ADDTS and multilink ADDBA setup according to the present embodiment from legacy usage in ADDTS and ADDBA setup on different links.

[0034] 7 and 8, each of the multilink ADDTS request frame 710, multilink ADDTS response frame 720, multilink ADDBA request frame 810, and multilink ADDBA response frame 820 includes two multiband elements 750, with the first multiband element 750 having its Inter-band field 920 set to "1" and its Band ID field 930 set to 2.4 GHz, and the second multiband element 750 having its Band ID field 930 set to 6 GHz. Because the frames are transmitted in the 5 GHz band, this indicates a multilink setup with three links.

[0035] In this example, the multilink ADDBA request frame 810 is sent from the multilink originator 302 to the multilink receiver 304, but if the multilink TS setup 510 is for uplink traffic, the multilink ADDBA request is sent by the multilink receiver 304 to the multilink originator 302. Once the TS and BA are set up in the multilink, the AP 102 can initiate a multilink transmission 530 to the STA 104, which includes simultaneously transmitting frames belonging to the same TS (TID / AC) on three links to the multilink receiver 304.

[0036] 10 shows a diagram 1000 of a multi-band capability element 1010 according to various embodiments. If both the originator and receiver support multilink TS and multilink BA and indicate the capability in the Multi-band TS and Block Ack field 1020 of the multi-band capability element 1010, multi-band TS setup 510 (downlink traffic) and multi-band BA setup 520 for a specific TID applicable to multilink can be performed using a single frame exchange on a channel, for example, in the primary link. The Multi-band TS and Block Ack field 1020 also indicates whether the AP 102 and the STA 104 support the multilink TS and multilink BA functions, and the Supported Bands field 1030 indicates the frequency bands supported by the AP 102 and the STA 104. It is also possible to signal the multilink TS and multilink BA capabilities separately in different fields.

[0037] 11 shows an illustration of a Multilink BlockAckReq frame 1100 and a Multilink BlockAck frame 1150 according to various embodiments. After completing a Multilink transmission 530, the Multilink originator 302 can send a Multiband BlockAckReq frame 1100 to the Multilink receiver 304 on either link (e.g., on the primary link) to request a Multilink BlockAck frame 1150. The Multilink BlockAck frame 1150 includes a consolidated BA bitmap in a BA information field 1152 that acknowledges frames received on the three links. A Multi-Band field 1110 and a Multi-Band field 1160 distinguish the Multilink BlockAckReq frame 1100 and the Multilink BlockAck frame 1150 from prior art single-link BlockAckReq frames and prior art single-link BlockAck frames, respectively.

[0038] The integrated BA bitmap in the Multilink BlockAck frame 1150 indicates that the receiver failed to receive the QoS Data A-MPDU 536c, which was transmitted in the 2.4 GHz band. To improve the success rate of retransmissions by using frequency diversity, the Multilink originator 302 can choose to retransmit the QoS Data A-MPDU 538 in the 6 GHz band instead of the 2.4 GHz band used for the original transmission.

[0039] The Multilink Originator 302 then sends a Multilink BlockAckReq frame 1100 to the Multilink Receiver 304 on another link (e.g., on the primary link) to request a Multilink BlockAck frame 1150 carrying an aggregate BA bitmap acknowledging frames received in the 6 GHz band.

[0040] The Receiver Address (RA) and Transmitter Address (TA) fields are set to the MAC address of the wireless radio interface of each link. However, regardless of the contents of the RA and TA fields, if the Multi-band field 1110 is set to "1," the BlockAckReq frame 1100 is interpreted as requesting a multilink BlockAck frame that acknowledges frames belonging to the TID indicated in the TID_INFO field 1112, regardless of the link on which the frames are received. Similarly, regardless of the contents of the RA and TA fields, if the Multi-band field 1160 is set to "1," the Multilink BlockAck frame 1150 conveys in the BA Information field 1152 an integrated BA bitmap that acknowledges frames belonging to the TID indicated in the TID_INFO field 1162, regardless of the link on which the frames are received.

[0041] In this manner, according to this embodiment, traffic belonging to the same TID can be divided into multiple bands. Furthermore, Block Acks from multiple bands can be aggregated and transmitted in another band. This functionality is provided according to this embodiment for existing Block Ack request types, such as Compressed, Multi-TID, Multi-STA, and GCR (GroupCast with Retries) Block Ack request types.

[0042] FIG. 12A shows a diagram 1200 of a traffic stream and block ACK architecture according to various embodiments. The MAC layers 318, 320, 322, 324, 326, and 328 are divided into band-agnostic unified upper MAC (UMAC) layers 1202 and 1204 and band-specific lower MAC (LMAC) layers 1206, 1208, 1210, 1212, 1214, and 1216. In this architecture, the LMAC / PHY layers of different links are tightly coupled to the UMAC, which coordinates the operation of each link's specific LMAC / PHY layer. Such an architecture may be appropriate when MLD is implemented as a single piece of silicon hardware. Multilink traffic stream agreements 1220, 1222, and 1224 for TID and multilink block ACK agreements 1230, 1232, and 1234 are set up between the respective MAC layers of each link.

[0043] The upper layers 330, 336 and LLC layers 332, 334 only need to deal with the unified UMAC layers 1202, 1204, respectively. At the multilink sender 302, the unified UMAC layer 1202 performs multilink aggregation of TS data across the three TS data paths 1240, 1242, 1244 (i.e., frames belonging to a particular traffic stream (TS) can be aggregated across multiple different links) and makes the decision on which link to use for transmission and retransmission. The actual link used for transmission may be transparent to the upper layers. The unified UMAC 1204 at the multilink receiver 304 is responsible for multilink deaggregation (i.e., reordering frames belonging to a particular traffic stream (TS) received from different links) and recording receipts in the unified block ACK scoreboard.

[0044] Additionally, the unified UMAC 1204 of the Multilink Receiver 304 is responsible for generating a Multilink Block Ack and transmitting the Multilink Block Ack (BA) along the Multilink BA path 1250 on the selected link (2.4 GHz in this example). The Multilink Originator 302 can request a Multilink BA on any link by sending a Multilink Block Ack Request. The Multilink Receiver 304 generates and transmits a Multilink Block Ack in response to receiving a Multilink Block Ack Request frame or in response to an implicit request to generate a Multilink Block Ack frame. Multilink Block Ack frames are transmitted on the same link on which the respective request was received.

[0045] FIG. 12B shows a diagram 1260 of a traffic stream and block ACK architecture defined to handle multilink transmission and multilink block ACK according to this embodiment. In this architecture, an MLD can be viewed as a collection of one or more associated STAs, with each STA operating on one link at a time. All associated STAs can share a common MAC Service Access Point (SAP) to higher layers and can be assigned a unique MAC address to represent the MLD. Each associated STA has its own MAC / PHY layer, and each MAC layer can have its own unique MAC address assigned to it. The MAC address of the MLD may be the same as or different from one of the MAC addresses of the associated STAs. The MLD coordinates the operation of each associated STA specific to a link. For example, the originator MLD 302 has three associated STAs 1280, 1282, and 1284 operating on a 2.4 GHz link, a 5 GHz link, and a 6 GHz link, respectively. Similarly, receiver MLD 304 has three associated STAs 1286, 1288, and 1290 operating on the 2.4 GHz, 5 GHz, and 6 GHz links, respectively. STA 1280 has its MAC layer 1266 and PHY layer 317 with MAC address TA-2, STA 1282 has its MAC layer 1268 and PHY layer 319 with MAC address TA-5, STA 1284 has its MAC layer 1270 and PHY layer 321 with MAC address TA-6, STA 1286 has its MAC layer 1272 and PHY layer 323 with MAC address RA-2, STA 1288 has its MAC layer 1274 and PHY layer 325 with MAC address RA-5, and STA 1290 has its MAC layer 1276 and PHY layer 327 with MAC address RA-6. The MAC address of the sender MLD 302 may be the same as the MAC address of the STA 1280 (i.e., TA-2), while the MAC address of the receiver MLD 304 may be the same as the MAC address of the STA 1286 (i.e., RA-2).This architecture may be appropriate when each associated STA is implemented as independent silicon, and these multiple associated STAs are housed together in a module to form an MLD, with the MLD being considered a logical collection of STAs. Of course, advances in silicon technology may allow the entire MLD to be implemented as a single piece of silicon hardware. It will be appreciated that various architectures of the MLD are possible. In this example, the Multilink Traffic Stream Agreement 1224 and Multilink Block ACK Agreement 1230 covering the TID are set up between the respective originator MLD 302 and receiver MLD 304, are link-independent, and are therefore much simpler to manage. The Multilink Traffic Stream Agreement 1224 and Multilink Block ACK Agreement 1230 can be identified by the MAC addresses of the TID and MLD, rather than by link-specific MAC addresses.

[0046] In the sender MLD 302, the MLD receives TS data from higher layers through a common MAC SAP, performs multi-link aggregation of the TS data across the three TS data paths 1240, 1242, and 1244, determines which links to use for transmission and retransmission, and passes the TS data to each STA for transmission on the link. Similarly, the receiver MLD 304 is responsible for multi-link de-aggregation of the TS data received from each of the associated STAs (and reordering of frames belonging to TSs received on the three TS data paths 1240, 1242, and 1244), and then passes the TSs to higher layers through a shared MAC SAP.

[0047] 13 shows an illustration of an exemplary multi-link transmission 1300 according to various embodiments, showing transmissions on a first link 1302 in a first frequency band (e.g., 2.4 GHz), a second link 1304 in a second frequency band (e.g., 5 GHz), and a third link 1306 in a third frequency band (e.g., 6 GHz), assuming that TS and BA setup for TIDs has been completed on the involved links. The bandwidth of the channel for each link 1302, 1304, 1306 may vary depending on channel conditions and availability (e.g., 20 MHz for the 2.4 GHz band 1302, 80 MHz for the 5 GHz band 1304, and 160 MHz for the 6 GHz band 1306). In some deployments, the first link 1302 (e.g., the 2.4 GHz band) may be used primarily to exchange management and control frames such as multilink Block Ack request frames 1308 and multilink Block Ack frames 1310 and may be recognized as a primary link, while the second link 1304 (e.g., the 5 GHz band) and the third link 1306 (e.g., the 6 GHz band) may be used primarily to exchange data frames 1312 (e.g., downlink (DL) PPDUs) and may be recognized as secondary or supplemental links. However, in other deployments, there may be no restrictions on the types of frames that can be transmitted over the links, and such a primary / secondary link distinction may not exist.

[0048] After gaining access to the channel of each link, the AP 102 initiates a multilink transmission 1300 consisting of a downlink PPDU 1312a on the third link 1306, a downlink PPDU 1312b on the second link 1304, and a downlink PPDU 1312c on the first link 1302. Each PPDU may carry an aggregated MPDU (A-MPDU), each having multiple frames.

[0049] The AP 102 sets the ACK policy in the QoS control field of each frame to Block ACK, indicating that immediate ACKs are not returned on each link, and assigns Block ACK Request (BAR) and Block ACK (BA) transmissions to the low-rate link (e.g., 2.4 GHz band 1302) while freeing the high-rate links (e.g., second link 1304 and third link 1306) for data transmission. Furthermore, to ensure that the sequence numbers (SNs) of transmitted frames are not repeated across links, the same sequence number counter is used for each TID pair for non-AP MLD across multiple links. In this example, frames with SNs 1, 2, and 3 are transmitted in PPDU 1312c on the first link 1302, frames with SNs 4, 5, and 6 are transmitted in PPDU 1312b on the second link 1304, and frames with SNs 7, 8, and 9 are transmitted in PPDU 1312a on the third link 1306. The STA 104 (i.e., receiver) maintains separate BlockAck bitmaps for each link in its network interface (NIC), but upon receiving a multilink BlockAckReq frame, it aggregates them into a single BlockAck bitmap 1314. The multilink BA frame 1310 carries an aggregate bitmap 1314 that acknowledges frames received on the three links, with a bit set to "1" indicating successful reception of the frame for the SN corresponding to that bit and a "0" indicating unsuccessful reception of the frame for the SN corresponding to that bit.

[0050] In the exemplary multilink transmission 1300, the multilink aggregated DL PPDU frame transmission includes frame 1312a transmitted on the third link 1306, frame 1312b transmitted on the second link 1304, and frame 1312c transmitted on the first link 1302, with the frames for SN2 on the first link 1302 and SNs 5 and 6 on the second link 1304 failing to transmit. Upon completion of the multilink transmission, the AP 102 transmits a multilink BlockAckReq frame 1308a to request a multilink BA acknowledging the frames transmitted on the three links 1302, 1304, and 1306. The multilink BA 1310a aggregates the BlockAck bitmaps from the three links into an aggregated BlockAck bitmap 1314a. In the consolidated BlockAck bitmap 1314a, bits 2, 5, and 6 corresponding to SNs 2, 5, and 6 are set to "0," indicating unsuccessful reception of the frames for SNs 2, 5, and 6, and the remaining bits are set to "1," indicating successful reception. Because there were unsuccessful transmissions on the second link 1304 and the first link 1302, but no unsuccessful transmissions on the third link 1306, the AP 102 may determine that the channel conditions on link 3 are good and may elect to consolidate the failed frames and retransmit them on the third link 1306 in PPDU 1312d. A multilink BlockAckReq frame 1308b is then transmitted on the first link 1302 to request a multilink BA 1310b conveying an acknowledgment for the frames conveyed in PPDU 1312d transmitted on the third link 1306. This time, all three retransmitted frames are received successfully, and STA 104 transmits multilink BA 1310b with the corresponding bit in the BA bitmap set to one.

[0051] 14 shows an example reference model diagram 1400 for implementing Multilink Block Ack in accordance with various embodiments. In a wireless communication device, the air interface (I / F), PHY layer, and time-critical MAC functions for each link can be implemented as separate modules and considered part of a separate associated STA (e.g., 1410, 1420, 1430 for the 2.4 GHz, 5 GHz, and 6 GHz bands, respectively, such as transceivers 230, 232, and 234 (FIG. 2)). All of the modules / STAs 1410, 1420, and 1430 are connected to a host system 1405 (which can be a CPU). The physical layer (PHY) modules (e.g., 323, 325, 327 (FIGS. 12A, 12B)) and time-critical MAC functions in the lower MAC layer 1402 (e.g., 1212, 1214, 1216 (FIG. 12A) and 1272, 1274, 1276 (FIG. 12B)) may be implemented on the radio I / Fs 216, 218, 220, each of which may be part of an independent associated STA (e.g., 1286, 1288, 1290 in FIG. 12B), while the remaining MAC functions (i.e., upper MAC layer 1404 (e.g., 1202 (FIG. 12A)) may be implemented in the host system 1405. The entire system (diagram 1400) may comprise an MLD.

[0052] Because of the low latency required to generate a BA in response to a BAR (within a short interframe space (SIFS) from the end of the BAR), a band-specific Block ACK scoreboard is implemented in each radio interface using fast but expensive on-chip memory. However, maintaining a BA scoreboard that persists throughout the duration of all active Block ACK sessions (known as a full-state Block ACK) places a significant burden on the memory requirements of the receiver implementation. Therefore, most implementations reuse the on-chip memory across multiple Block ACK sessions, and the memory acts as a cache to store the state of the most recent active Block ACK session (also known as a partial-state Block ACK). In-band BA scoreboards 1412, 1422, and 1432 are examples of on-chip memory used as BA scoreboards, recording the reception status of frames received in the 2.4 GHz, 5 GHz, and 6 GHz bands, respectively. The in-band BA scoreboard is also known as a per-link BA scoreboard, or simply a per-link scoreboard. Partial State Block Ack saves memory, but requires special handling to prevent data loss due to the increased risk that the Block Ack scoreboard will be overwritten by another Block Ack session at the next Transmission Opportunity (TXOP).

[0053] To implement Multilink Block ACK operation, Multilink BA Scoreboard 1406 is maintained in Host System 1405. Because memory in Host System 1405 is generally inexpensive, Multilink BA Scoreboard 1406 may be implemented as a full-state Block ACK scoreboard, i.e., the scoreboard persists for the entire duration of a Multilink Block ACK session.

[0054] According to this embodiment, as shown in diagram 1400, frames received on each link are parsed by Rx parsers 1414, 1424, 1434 and processed according to frame type. Data frames 1415, 1425, 1435 that are correctly received and addressed to a recipient are recorded in in-band BA scoreboards 1412, 1422, 1432 according to their sequence numbers (SN) and then passed to receive buffer 1408. The contents of receive buffer 1408 can be sorted according to the SN of the data frames at regular intervals.

[0055] In traditional single-link Block Ack operation, upon completion of a TXOP (in the case of implicit Block Ack) or upon receipt of a legacy Block Ack Request (BAR) frame (in the case of explicit Block Ack), the subordinate MAC copies the BA bitmap from the in-band BA scoreboard and generates a Block Ack frame for immediate transmission. However, in the case of multilink Block Ack operation, explicit Block Ack can be used, and upon completion of a TXOP on each band, the multilink BA scoreboard 1406 can be updated with the contents of the in-band scoreboards 1412, 1422, and 1432 from the respective radio interfaces. By the time the multilink transmit opportunity (TXOP) ends, the multilink BA scoreboard 1406 has merged the BA bitmaps from all in-band BA scoreboards 1412, 1422, and 1432.

[0056] Finally, upon receiving a Multilink BAR frame 1416 on either link, the upper MAC 1404 copies the BA bitmap from the Multilink BA Scoreboard 1406 and generates a Multilink BlockAck frame for transmission (1407). At the same time, the reception of the Multilink BAR frame 1416 triggers the upper MAC to reassemble complete MSDUs from the frames in the receive buffer 1408 (all complete MSDUs with a Starting Sequence Number (SSN) lower than the SSN conveyed in the Multilink BAR frame 1416) and forward them sequentially to the upper layer. Note that while the diagram 1400 shows the reception of the Multilink BAR frame 1416 and the transmission of the Multilink BA frame 1820 in the 2.4 GHz band, it will be understood that this process is similar for other frequency bands.

[0057] According to Figures 1-14, a single Block ACK agreement can be negotiated between two MLDs for a TID transmitted over one or more links. The Block ACK agreement can be represented by the tuple {sender MLD MAC address, receiver MLD MAC address, TID}. Furthermore, a multi-link Block ACK agreement can be negotiated by exchanging a single pair of ADDBA request / response frames over any one of the active links between the two MLDs. Furthermore, sequence numbers for MSDUs for a TID transmitted over one or more links to the other MLD can be assigned from a common sequence number space shared across the MLD's multiple links.

[0058] However, when frames with the same TID are transmitted simultaneously over multiple different links, potential problems can arise, such as when one or more of the per-link scoreboard contexts in the receiver MLD go out of range during a multi-link transmission. Referring to Figure 15A, the sender MLD can transmit MPDUs for SNs 1-15 to the receiver MLD on Link 1 (as shown in Link 1 transmit window 1502) and MPDUs for SNs 16-30 on Link 2 (as shown in Link 2 transmit window 1504). The SNs in the Link 1 transmit window are WS_O=1 (WS_O is the beginning of the transmit window, WinStart O The Link 2 transmit window is controlled by the Link 1 transmit control unit, starting at WS_R=16 and ending at WE_R=30 (assuming a transmit window size of 15 was negotiated during Multi-Link BA agreement for both links), and the SN of the Link 2 transmit window starts at WS_R=16 and ends at WE_R=30. For example, due to poor quality of Link 1 transmission, the receiver MLD fails to receive MPDUs for SN3 and SN5-15. This can be seen in Link 1 scoreboard 1512, where SN3 and SN5-15 have a value of 0. Meanwhile, Link 2 scoreboard 1514 shows that all MPDUs for SN16-30 were successfully received by the receiver MLD. At this point, the Link 2 scoreboard has shifted to the right (from its initial value of WS_R=0) and now starts at WS_R=16 and ends at WE_R=30 (i.e., WS_R and WS_E are the leading SNs of the scoreboard context, respectively). R and End SN WinEnd R These MPDUs are consolidated in the reordering buffer 1516, and the MPDU with the smallest consecutive SN (i.e., SN1 and SN2) is forwarded to the next MAC process. However, the MPDUs from SN4 onwards that were successfully received by the receiver MLD cannot be forwarded to the next MAC process because the MPDU with SN3 was not received correctly and forwarding must be in order. As a result, the SN of the frames in the reordering buffer 1516 now starts from 3 (i.e., WS_B=3, and WS_B is the WinStartB ), there are gaps at SN=3 and 5-15 because these MPDUs have not been received by the receiver MLD.

[0059] Referring to Figure 15B, the sender MLD can receive a per-link BlockAck frame on each link, or a multi-link BlockAck frame on one of the links, to know the transmission status of the MPDUs. As a next step, it can take advantage of the better link by retransmitting the failed MPDU on link 1 to the receiver MLD on link 2. However, since the scoreboard context for link 2 has already shifted to the right and is outside the range of these retransmitted lower SNs, the retransmitted MPDUs with lower SNs on link 2 will be discarded even if they were all received in order. This is according to Non-Patent Document 1, i.e. WinStart R +2 11 ≦SN <WinStart R In the formula, SN refers to the SN of the received frame, and WinStart R refers to the leading SN of the scoreboard context. The above is just one example to illustrate the problem where the scoreboard contexts of different links go out of range of each other, risking the failure of a retransmitted MPDU on the other link. As can be seen, this problem becomes even worse when the bandwidths of different links are different and, as a result, the size of the scoreboard context is different. The scoreboard context of a link with a higher bandwidth is expected to be shifted to the right more quickly compared to a link with a lower bandwidth, which may increase the risk of the scoreboard contexts of different links going out of range of each other.

[0060] Alternatively, a receive reordering buffer overflow problem may occur. Referring to FIG. 15C, the MPDUs for SN3 and SN5-15 that previously failed to be transmitted on link 1 can be retransmitted to the receiver MLD on link 1. Furthermore, after the successful transmission of the MPDUs for SN16-30 as shown in FIG. 15A, new MPDUs for SN31-45 can be transmitted to the receiver MLD on link 2. However, the MPDUs for SN3 and SN5-15 again fail to be received on link 1, and the MPDU for SN31 fails to be received on link 2. As a result, the reordering buffer contains MPDUs starting from SN16 to SN45, with a gap at SN31. Here, the size of the receive reordering buffer, WinSize, is B = 30 (the sum of the buffer sizes of Link 1 and Link 2). According to the rules of the receive reordering buffer operation, when an MPDU with a SN greater than the end of the receive buffer is received, the end of the receive reordering buffer is shifted to accommodate the new MPDU (i.e., WS_R = 16 and WE_B = 45, and WE_B is the end of the receive reordering buffer). B (which indicates the new beginning of the buffer), buffer contents with a smaller SN than WS_R (e.g., MPDUs with SN4) are passed to the next MAC process if there is a gap in the SN of the MPDU. Additionally, MPDUs with SNs 16-30 previously received on link 2 are forwarded to the next MAC process, but MPDUs with SNs 31 and above cannot be forwarded due to the gap caused by the failed transmission of the MPDU with SN 31 (i.e., WS_R=31, WE_B=60).

[0061] Referring to Figure 15D, the failed MPDUs with SN3 and SN5-15 on Link 1 are retransmitted again to the receiver MLD on Link 1. This time, all of these MPDUs are successfully received and their reception is recorded in the scoreboard of Link 1. However, even though the retransmitted MPDUs are successfully received on Link 1, they cannot be recorded in the receive reordering buffer 1516 because it has already been shifted right, and are therefore discarded by the receiver MLD. This problem is more prevalent when there is a large difference in bandwidth / throughput between the links, i.e., when the faster link dominates the receive reordering buffer. The higher the SN (current WinEnd B When an MPDU with an SN greater than the value of WinStart is received on a faster link, the receive reordering buffer is shifted to the right (i.e., WinStart B and WinEnd B ), thereby increasing the risk of overflowing the receive reordering buffer.

[0062] To solve the above problems, we propose a two-tiered block ACK architecture for multi-link transmission as shown in Figure 16. Essentially, the originator MLD creates a WinStart ACK for a common transmit buffer 1602a shared among all links (or all associated STAs, assuming one associated STA per link if we follow the MLD architecture of Figure 12B). T The leading SN and size WinSize are equal to T The receiver MLD has a transmit buffer controller 1604 for each MLD-RA / TID with a common transmit buffer 1602a, which allows flexible retransmission across links and prevents overrun of the receive reordering buffer in the receiver MLD. On the other hand, the receiver MLD has a WinStart T The leading SN and size WinSize are equal to Twhere MLD-RA and MLD-TA refer to the MAC addresses of the receiver MLD and originator MLD, respectively. In other words, the originator MLD maintains a transmit buffer and transmit buffer control for each TID of the Multilink Block Ack agreement. The originator MLD also maintains a start SN WinStart O and size WinSize O a transmit buffer controller 1606a per L1-RA / TID with a transmit buffer 1602b, a Block ACK status per L1-RA / TID with a Block ACK status 1608a per L1-RA / TID, an aggregation controller L1 1610a for link 1, and a start SN WinStart O and size WinSize OThe MLD comprises a per-L2-RA / TID transmit buffer controller 1606b having a transmit buffer 1602c, a per-L2-RA / TID Block ACK state 1608b, and a link 2 aggregation controller L2 1610b. Here, L1-RA and L2-RA refer to the MAC addresses of the associated STAs of the receiver MLD operating on link 1 and link 2, respectively. In other words, each associated STA of the originator MLD maintains a per-link transmit buffer controller for each TID of the Multilink Block ACK agreement (if that link is part of the Multilink Block ACK agreement). Furthermore, each associated STA of the originator MLD may maintain a per-link transmit buffer for each TID of the Multilink Block ACK agreement (if that link is part of the Multilink Block ACK agreement). The per-link transmit buffer controllers 1606a and 1606b advantageously prevent overflow of the block acknowledgment record (scoreboard context) maintained by each STA or station belonging to the receiver MLD due to the transmission of frames over one or more links, as shown in Figures 15A-15D. A common transmit buffer shared among all links advantageously enables flexible retransmission across links and prevents overrun of the receive reordering buffer at the receiver. However, storing the same MPDU in two different transmit buffers requires additional rules to ensure synchronization of the two transmit buffers. For example, an MPDU already transmitted on one link should not be transmitted on another link before receiving transmission status on the original link. An MPDU should be retransmitted on another link only upon receiving feedback of transmission failure on one link, and the MPDU should be deleted from the per-link transmit buffer of the link of the original transmission. An MPDU should also be deleted from both the per-link transmit buffer and the common transmit buffer upon receiving feedback of successful transmission over either link, or upon the expiration of the MSDU lifetime of the MSDU carried in the MPDU.The size of the Block Acknowledgment record for each STA or station is negotiated independently during Multilink Block Ack negotiation, as described below. It should be understood that STAs belonging to an originator MLD or receiver MLD are also referred to as stations. The Block Ack state is used by the originator MLD to track the status of transmitted MPDUs and is updated upon receiving a Block Ack frame from the receiver MLD. The role of the Aggregation Controller is to construct an A-MPDU for transmission by aggregating two or more MPDUs.

[0063] Meanwhile, the receiver MLD is sending the starting SN WinStart R and size WinSize R a scoreboard context controller L1 1616a having a deaggregation controller L1 1618a, and a start SN WinStart R and size WinSize RThe receiver MLD further comprises a scoreboard context controller L2 1616b having a block acknowledgement record (BACK) and a deaggregation controller L1 1618b. The scoreboard context controller L2, also known as a block acknowledgement record, maintains a record of the reception status of MPDUs. The deaggregation controller's role is to deconstruct a received A-MPDU into two or more MPDUs. The receiver MLD also maintains a common receive reordering buffer (receive buffer for short) for each TID of the Multilink Block Acknowledgment agreement. The primary role of the receive reordering buffer is to ensure that MPDUs are forwarded to the next MAC process in the correct SN order. Having a common receiver reordering buffer shared among associated STAs (links) ensures that MPDUs received over different links are passed to the next MAC process in the correct order. It will be understood that the number of sets of transmit buffer controllers per RA / TID, block ACK status per RA / TID, aggregation controller, scoreboard context controller, and deaggregation controller can be extended to more than two links. In this architecture, the originator MLD maintains a two-tiered transmit buffer control structure: a common transmit buffer control unit shared among multiple links, and an individual transmit buffer control unit for each link.

[0064] The extension of the HT-Immediate Block ACK mechanism to multilink is known as Multilink Block ACK and is negotiated separately for each direction between two MLDs for a particular TID. The MLD to which the associated STAs send data using the Multilink Block ACK agreement is called the originator MLD, and the MLD for which the associated STAs are recipients of the data is called the receiver MLD. A Multilink Block ACK agreement is uniquely identified by the tuple {originator MLD MAC address, receiver MLD MAC address, TID}.

[0065] In the architecture shown in FIG. 16, the originator MLD includes a common transmit buffer controller per {receiver MLD MAC address, TID} shared among associated STAs or stations using the Multilink Block Acknowledgment Agreement, and the WinStart T and WinSize T It supplies and transmits MPDUs using WinStart and releases the transmit buffer upon receiving a BlockAck frame. T is the starting sequence number of the common transmission window across all links in the Multilink Block ACK agreement, and WinSize T WinSize is the size of the total send window, equal to the receive reordering buffer maintained by the receiver MLD. T is equal to the size of the receive reordering buffer negotiated during Block ACK agreement. The size of the receive reordering buffer may be negotiated independently or calculated based on the size of the per-link scoreboard context. The common transmit buffer is used to store MSDUs or A-MSDUs until they are reported as successfully received or their lifetime (e.g., MSDU lifetime) is exceeded.

[0066] Each associated STA of the originating MLD includes a per-link transmit buffer control unit and a per-link block ACK state unit per {MAC address, TID of the peer associated STA}, and an aggregation control unit. Additionally, each associated STA maintains a per-link transmit buffer that is valid for a short period (e.g., a single transmit opportunity (TXOP)) and can be used for per-link retransmissions, i.e., retransmissions within the same TXOP.

[0067] The receiver MLD contains a common receive reordering buffer controller per {originator MLD MAC address, TID} and is responsible for recording and reordering the MSDUs / A-MSDUs arriving from each associated STA, as well as identifying and discarding duplicate frames.

[0068] Furthermore, each associated STA of the receiver MLD includes a per-link scoreboard context control unit per {MAC address, TID of the peer associated STA} and a deaggregation control unit. Each per-link scoreboard context control unit includes an acknowledgement bitmap control unit containing the current reception status of MSDUs or A-MSDUs received on the associated link, and can use either full-state or partial-state operation.

[0069] In operation, the originating MLD may store transmitted frames in the common transmit buffer until they are acknowledged by the receiving MLD as having been successfully received or until they are discarded at the end of the MAC Service Data Unit (MSDU) lifetime. On the other hand, stations belonging to the originating MLD may store frames in the per-link transmit buffers only during a transmission opportunity (TXOP). In other words, frames are stored for a longer period in the common transmit buffer compared to the per-link transmit buffer.

[0070] 17A shows a Block Ack parameter set (i.e., fields of the ADDBA request frame 810 shown in FIG. 8) according to the Block Ack architecture 1600 shown in FIG. 16, and FIG. 17B shows a multiband element (i.e., fields of the ADDBA response frame 820 shown in FIG. 8). The Block Ack parameter set 1700 specifies the size of the scoreboard context control unit (i.e., WinSize R The Multiband element 1710 currently includes a Buffer Size field 1702 indicating the size of the scoreboard context control (WinSize) for the link it represents in the ADDBA response frame. R 16, the size of the receive reordering buffer is WinSize. B =WinSize T= WinSize across all links in the Multi-Link Block ACK agreement R Alternatively, the Buffer Size field 1702 of the ADDBA response frame can be set to the sum of WinSize B Represents the WinSize of the link on which the ADDBA response frame was sent. R =WinSize B It can also be the value of the Buffer Size field 1712 of the multiband element (i.e., the WinSize of the link on which the ADDBA response frame was sent). R is indirectly signaled).

[0071] Figure 18 shows the format of an extended BlockAck Request (eBAR) frame according to the architecture shown in Figure 16. According to the existing HT-Immediate Block Ack rules, a BAR frame is used to send a WinStart R The value of WinStart can be shifted forward. R BARs with smaller starting sequence number (SSN) values ​​are discarded, so WinStart R It is not possible to shift the value of WinStart backwards. Therefore, the extended BAR (eBAR) frame 1800 can explicitly allow this. For example, shifting WinStart R (Shift WinStart R ) If the bit in field 1802 is set, the receiver MLD shall check the WinStart R If this bit is not set, the value of the WinStart R <SSN≦WinStart R +2 11 Only if WinStart R will be updated. In addition, Shift WinStart B (Shift WinStartB ) If the bit in field 1804 is set, the receiver MLD B The receiver shall replace the value of the Starting Sequence Number subfield of the BAR information field with the value of the Starting Sequence Number subfield of the BAR information field. If the bit is not set, the receiver shall not update based on the SSN value in the BAR frame. Furthermore, the transmission of the eBAR frame 1800 on the link shall not cause the WinStart O is also replaced with the SSN value.

[0072] Alternatively, if a protected Block Ack agreement has been successfully negotiated, a robust ADDBA request frame can be used to achieve the same effect as eBAR frame 1800. Thus, the BlockAck request frame can be configured to indicate whether the start of the block acknowledgement record maintained by the station should be replaced with the value of the starting sequence number (SSN) carried in the BlockAck request frame.

[0073] Figure 19 shows how eBAR solves the out of bounds scoreboard context problem as described above in Figure 15A. After the first transmission, the WinStart R Since the value of WS_R is 16, when the originator MLD retransmits the failed MPDUs (originally sent on link 1) on link 2, they will be discarded by the receiver MLD because the SN is less than 16. To avoid this, the originator MLD sends an eBAR 1800 with SSN=3, the smallest SN to be retransmitted. R " bit is set, so the receiver MLD will receive the WinStart R, with the value of the Starting Sequence Number (SSN) subfield of the BAR information field. The MPDU that failed on link 1 can then be retransmitted on link 2 as shown in 1900 without the scoreboard context control going out of scope. eBAR advantageously solves the scoreboard context control going out of scope problem and facilitates retransmission across links.

[0074] Alternatively, if the originator MLD decides to disable link 1 due to repeated transmission failures, it can send a signal to the receiver MLD to disable link 1. Upon receiving the signal to disable link 1, the receiver MLD starts the scoreboard context control unit (WinStart R = the smallest SN that has not been successfully received).

[0075] As shown in the BlockAck architecture of Figure 16, having a common transmit buffer controller across all links of a multi-link Block Ack agreement advantageously prevents the problem of receive reordering buffer overflow at the receiver (i.e., the problem shown previously in Figures 15A, 15C, and 15D). (WinStart T +WinSize T ) acts as an upper bound on the SN of MPDUs transmitted on each link, and the highest SN transmitted on any link ≤ WinStart T +WinSize T This becomes:

[0076] Figure 20 shows how the receive reordering buffer overflow problem shown in Figures 15A, 15C, and 15D is prevented by the common transmit buffer controller. Tdenotes the beginning of the transmission window (i.e., WS_T) and is equal to the smallest SN that has not yet been acknowledged by the receiver MLD as being successfully received. As seen by the common transmit buffer control unit 2000, MPDUs that previously failed to be transmitted on link 1 (i.e., MPDUs with SN3 and SN5-15) are retransmitted on link 1. The highest SN that can be safely transmitted across all links is determined by the common transmit window size (WinSize T ) and the highest SN is WinStart T +WinSize T -1=32.

[0077] WinSize T is set to the buffer size value of the receive reordering buffer control unit 2004, and therefore, by having the above rule, it is guaranteed that the MPDUs sent by the originator MLD will not overflow the receive reordering buffer at the receiver MLD. Now, if MPDUs that failed on link 1 are retransmitted on link 1 as shown in Figure 15D, they can be safely received at the receiver side. If the originator MLD gives up on sending an MPDU (for example, due to repeated transmission failures or the MPDU lifetime expiring), the originator MLD can shift its transmission window to the right by sending a BlockAck request frame with the SSN set to the value of the next MPDU to be sent. This allows the originator MLD to T and WinStart O is set to SSN, and in the recipient MLD, WinStart R (i.e. WS_R) and WinStart B By setting (i.e., WS_B) to the SSN, both the scoreboard and the receive window are shifted to the right. After that, transmission of MPDUs with higher SNs can resume. This is advantageous as it allows retransmissions across links without overflowing the receive buffer.

[0078] According to another embodiment, if the receiver MLD supports unified Block Ack across multiple links, a common multi-link scoreboard context control can be used to combine the scoreboard context controls of the individual links. Figure 21 shows a Block Ack architecture 2100 according to this embodiment, which is a variation of the Block Ack architecture 1600 shown in Figure 16. The two architectures are nearly identical, with the main difference being that the receiver MLD in architecture 2100 uses a block acknowledgment of size (ML_WinStart R ,ML_WinSize R ) multilink scoreboard context control unit 2120. R is the minimum WinStart across all links in the Multilink Block ACK agreement negotiated by the originator MLD and receiver MLD. R and ML_WinSize R ≥ WinSize across all links in Multi-Link Block Ack agreement R Another difference is that the originator MLD in architecture 2100 maintains only one common send buffer 2102 that is shared among all links.

[0079] Architecture 2100 is based on the premise that two-level transmit buffer control is possible without individual transmit buffers for each link, such as transmit buffers 1602b and 1602c for link 1 and link 2 in Block Ack architecture 1600. For example, the only buffer in architecture 2100 is common transmit buffer 2102, and the two-level transmit buffer control is implemented by address / pointer management.

[0080] The multilink scoreboard context control unit 2120 may operate according to the following rules regarding reception of data frames. - ML_WinStart R <=SN<=ML_WinEnd RIf so, set the bit at position SN in the bitmap to 1. - ML_WinEnd R <SN<ML_WinEnd R +2 11 If 1) ML_WinEnd R Set the bits of the SN value from +1 to SN-1 to 0. 2) ML_WinEnd R =SN 3) ML_WinStart R =SN-ML_WinSize R 4) Set the bit at position SN in the bitmap to 1. - ML_WinEnd R +2 11 <=SN<=ML_WinEnd R If , no change.

[0081] Additionally, the multilink scoreboard context control 2120 may operate according to the following rules regarding the reception of a multilink BlockAckReq (ML_BAR) frame. - ML_WinStart R <=SSN<=ML_WinEnd R in the case of, 1) ML_WinStart R =SSN 2) ML_WinEnd R +1 to ML_WinSize R Set the bits of the SN value up to -1 to 0. 3) ML_WinEnd R =ML_WinStart R +ML_WinSize R -1 - ML_WinEnd R <SSN<ML_WinEnd R +2 11 in the case of, 1) ML_WinStart R =SSN 2) ML_WinEnd R=ML_WinStart R +ML_WinSize R -1 3) ML_WinStart R From ML_WinEnd R Set the bits of the SN value up to 0. - ML_WinEnd R +2 11 <=SSN<=ML_WinEnd R If , no change The rules for updating the receive reordering buffer control upon receipt of a Multilink BAR (ML_BAR) frame are the same as for receipt of a BAR frame. Furthermore, receipt of a per-link BAR does not affect the ML_Scoreboard, and receipt of an ML_BAR does not affect the per-link scoreboard.

[0082] In both the architecture shown in FIG. 16 and the architecture shown in FIG. 21, it is advantageous to implement a separate transmit buffer control unit 1604 or 2104, but such a record (WinStart T ,WinSize T Instead of maintaining a WinStart count, the sender MLD can also control transmissions across multiple links by consulting the records in each per-link transmit buffer control before each transmission to prevent overflow of the receive reordering buffer at the receiver. The sender MLD then selects the smallest WinStart count across all links. T and across all links (WinStart T +WinSize T ) and the maximum value of WinSize B In summary, the purpose of having a common transmit buffer controller is to ensure that transmission of MPDUs across different links does not cause problems in the receiver MLD, e.g., overflow of the receive reordering buffer.

[0083] Figure 22A illustrates a Block Ack parameter set (i.e., fields in the ADDBA request frame 810 shown in Figure 8) and Figure 22B illustrates a multiband element (i.e., fields in the ADDBA response frame 820 shown in Figure 8) according to the Block Ack architecture 2100 shown in Figure 21. The Block Ack parameter set 2200 includes the receive reordering buffer size (i.e., WinSize B The ADDBA request / response frame carries one multiband element for each link in the multilink block ACK agreement (including the link on which the frame is transmitted). The multiband element 2210 specifies in the ADDBA response frame the size of the scoreboard context control (WinSize R ) Each Multi-Band element 2210 identifies one link of a Multi-Link Block Ack agreement.

[0084] According to the architecture 2100 shown in FIG. T =WinSize B ≥ WinSize across all links in the Multilink Block ACK agreement negotiated by the sender MLD and receiver MLD RThe sum of the receive buffer sizes is the sum of the receive buffers across all links. To account for differences in link throughput, a receive reordering buffer size larger than the sum of the receive buffers across all links can be negotiated. Furthermore, the receive reordering buffer size can be negotiated independently of the per-link scoreboard size. Such an implementation can help reduce the likelihood of receive reordering buffer overflow due to differences in link bandwidth, etc., as described above, by being able to receive MPDUs from slower links while accommodating more MPDUs received over faster links without overflowing. However, it should be understood that while increasing the receive reordering buffer size may mitigate receive reordering buffer overflow, it alone does not completely eliminate the risk of receive reordering buffer overflow, and some central control of transmission across multiple different links is required at the originating side, regardless of the receive reordering buffer size negotiated during Multilink Block ACK agreement.

[0085] According to yet another embodiment, ADDBA request and ADDBA response frames may carry Multilink elements that specify parameters related to all links in a Multilink Block Ack agreement negotiated between the originator MLD and the recipient MLD. Referring to Figures 23A, 23B, and 23C, ADDBA request frame 2304 and ADDBA response frame 2306 may include a Block Ack Parameter Set field 2300 that includes a Buffer Size field 2302. Buffer Size field 2302 may specify the size of the receive reordering buffer (WinSize B) in the Multi-link element 2310 of the ADDBA Response frame 2306. Additionally, the ADDBA Request frame 2304 and the ADDBA Response frame 2306 may include a Multi-link element 2310 that includes one or more Link Parameters fields 2312. Each of the one or more Link Parameters fields may include a Link ID field 2314, a Scoreboard Size field 2316, and an optional MAC Address field 2318. The Link ID field 2314 identifies the associated link, where the Link ID may be assigned during Multi-link setup / association or during a separate link setup procedure after association. The Scoreboard Size field 2316 of the Multi-link element 2310 of the ADDBA Response frame 2306 indicates the size of the scoreboard context control (WinSize) for the link represented by the associated Link ID identified in the Link ID field 2314. R In this embodiment, WinSize T =WinSize B ≥ WinSize across all links in Multi-Link Block Ack agreement R The sum of

[0086] 24 shows a schematic diagram of an originator MLD 2400 according to various embodiments. The originator MLD includes a common transmit buffer controller 2406 having a common transmit buffer 2404 (i.e., common transmit buffer controller 1604 having common transmit buffer 1602a in the originator MLD of architecture 1600, and common transmit buffer controller 2104 having common transmit buffer 2102 in the originator MLD of architecture 2100), and a MAC-SAP 2402 for performing distribution services (DS). The originator MLD 2400 includes two associated STAs or stations, STA1 2408a and STA2 2408b. At the MAC layer, STA1 2408a includes a per-link transmit buffer control unit 2414a, a block ACK state 2416a, and an aggregation control unit 2418a (i.e., similar to the transmit buffer control unit 1606a, block ACK state 1608a, and aggregation control unit 1610a in architecture 1600, and the transmit buffer control unit 2106a, block ACK state 2108a, and aggregation control unit 2110a in architecture 2100). Similarly, STA2 2408b includes a per-link transmit buffer control 2414b, a Block ACK state 2416b, and an aggregation control 2418b at the MAC layer (i.e., similar to transmit buffer control 1606b, Block ACK state 1608b, and aggregation control 1610b in architecture 1600, and transmit buffer control 2106b, Block ACK state 2108b, and aggregation control 2110b in architecture 2100). Both STAs include a PHY layer where transmissions occur over link 1 (STA1 2408a) and link 2 (STA2 2408b). It will be understood that the number of links and associated STAs or stations can be further expanded.

[0087] 25 shows a schematic diagram of a receiver MLD 2500 according to various embodiments. The receiver MLD includes a receive reordering buffer control unit 2506 having a receive reordering buffer 2504 (i.e., receive reordering buffer control unit 1614 having a receive reordering buffer 1612 in the receiver MLD of architecture 1600, and receive reordering buffer control unit 2114 having a receive reordering buffer 2112 in the receiver MLD of architecture 2100), and a MAC-SAP 2502 for performing distribution services (DS). The receiver MLD 2500 includes two associated STAs or stations, STA1 2508a and STA2 2508b. STA1 2508a includes a scoreboard context control unit 2516a and a deaggregation control unit 2518a at the MAC layer (i.e., similar to scoreboard context control unit 1616a and deaggregation control unit 1618a in architecture 1600 and scoreboard context control unit 2116a and deaggregation control unit 2118a in architecture 2100). Similarly, STA2 2508b includes a scoreboard context control unit 2516b and a deaggregation control unit 2518b at the MAC layer (i.e., similar to scoreboard context control unit 1616b and deaggregation control unit 1618b in architecture 1600 and scoreboard context control unit 2116b and deaggregation control unit 2118b in architecture 2100). Both STAs have a PHY layer that transmits over link 1 (i.e., between STA1 2508a and STA1 2408a in the originator MLD 2400) and link 2 (i.e., between STA2 2508b and STA2 2408b in the originator MLD 2400). It will be appreciated that the number of links and associated STAs or stations can be further expanded.

[0088] FIG. 26 shows a flowchart 2600 illustrating a method of multilink communication according to various embodiments. In step 2602, a first multilink device initiates setup of a block acknowledgement agreement with a second multilink device configured to operate with a second plurality of stations. The first multilink device is configured to operate with the first plurality of stations, and a link is established between each station of the first plurality of stations and a corresponding station of the second plurality of stations. In step 2604, frames of a traffic identifier (TID) are transmitted to the second multilink device over one or more links based on the block acknowledgement agreement. The first plurality of stations are configured to share a common transmit buffer for storing frames of the TID transmitted to the second multilink device and a common transmit buffer control for managing transmission of the frames over the one or more links, and each of the first plurality of stations is configured to maintain a per-link transmit buffer control for managing transmission of frames over a corresponding link of the one or more links.

[0089] Figure 27 shows a schematic partial cross-sectional view of a multi-link device 2700 that can be implemented for multi-link communications according to various embodiments shown in Figures 1-26. The multi-link device 2700 can be implemented as an AP MLD or a non-AP MLD, and includes one or more associated stations or STAs according to various embodiments.

[0090] The various functions and operations of the multilink device 2700 are arranged in layers according to a hierarchical model, in which lower layers report to and receive instructions from higher layers, in accordance with the IEEE specification. For the sake of brevity, the details of the hierarchical model will not be described in this disclosure.

[0091] As shown in Figure 27, the multilink device 2700 may include circuitry 2714, at least one wireless transmitter 2702, at least one wireless receiver 2704, and multiple antennas 2712 (for simplicity, only one antenna is depicted in Figure 27 for illustrative purposes). The circuitry may include at least one controller 2706, which is used to perform, with the assistance of software and hardware, the tasks it is designed to perform, including controlling communications with one or more other multilink devices in a MIMO wireless network. The at least one controller 2706 may control at least one transmit signal generator 2708 to generate ADDBA action frames, such as ADDBA request frames and / or ADDBA response frames, transmitted via the at least one wireless transmitter 2702 to one or more other multilink devices, and at least one receive signal processor 2710 to process ADDBA action frames, such as ADDBA request frames and / or ADDBA response frames, received via the at least one wireless receiver 2704 from one or more other multilink devices. The at least one transmit signal generator 2708 and the at least one receive signal processor 2710 may be standalone modules of the multilink device 2700 that communicate with the at least one controller 2706 for the functions described above. Alternatively, the at least one transmit signal generator 2708 and the at least one receive signal processor 2710 may be included in the at least one controller 2706. Those skilled in the art will appreciate that the arrangement of these functional modules is flexible and may vary depending on actual needs and / or requirements. Data processing, storage, and other related control devices may be provided on an appropriate circuit board and / or chipset. In various embodiments, the at least one wireless transmitter 2702, the at least one wireless receiver 2704, and the at least one antenna 2712 may be controlled by the at least one controller 2706 during operation.Furthermore, although only one wireless transmitter 2702 is shown, it will be understood that there may be multiple such transmitters (i.e., one transmitter for each associated station or STA of the multilink device 2700).

[0092] 27, at least one radio receiver 2704, together with at least one receive signal processor 2710, form the receiver of the multilink device 2700. In operation, the receiver of the multilink device 2700 provides the functionality necessary for multilink communications. While only one radio receiver 2704 is shown, it will be understood that there may be multiple such receivers (i.e., one receiver for each associated station or STA of the multilink device 2700).

[0093] In operation, the multilink device 2700 provides functionality necessary for multilink communications. For example, the multilink device 2700 can be a first multilink device configured to operate with a first plurality of associated stations. In operation, the circuit 2714 can initiate the setup of a block acknowledgement agreement with a second multilink device configured to operate with a second plurality of associated stations, where a link is established between each station of the first plurality of stations and a corresponding station of the second plurality of stations. In operation, the transmitter 2702 can transmit frames of a traffic identifier (TID) over one or more links to the second multilink device based on the block acknowledgement agreement, the first plurality of stations being configured to share a common transmit buffer for storing frames of the TID to be transmitted to the second multilink device and a common transmit buffer control for managing the transmission of frames over the one or more links, and each of the first plurality of stations being configured to maintain a per-link transmit buffer control for managing the transmission of frames over a corresponding link of the one or more links.

[0094] Each of the first plurality of stations can be configured to maintain a separate per-link transmit buffer for storing frames to be transmitted on a corresponding one of the one or more links. The circuit 2714 can be configured to store the frames in the common transmit buffer until the frames are acknowledged by the second multilink device as successfully received or until the frames are discarded at the end of a MAC service data unit (MSDU) lifetime, and the first plurality of stations stores the frames in the per-link transmit buffer only for the duration of a transmit opportunity (TXOP).

[0095] The common transmit buffer controller can be used to prevent overflow of a receive reordering buffer maintained by the second multilink device due to transmitting frames over one or more links. The per-link transmit buffer controller can be used to prevent overflow of a block acknowledgment record maintained by each of the second plurality of stations due to transmitting frames over one of the one or more links. Furthermore, the sizes of the receive reordering buffers managed by the second multilink device can be independently negotiated.

[0096] The circuit 2714 can be configured to negotiate a block acknowledgement agreement with a second multilink device by exchanging ADDBA action frames over one of the one or more links, wherein a size of the block acknowledgement record maintained by each station of the second plurality of stations is independently negotiated.

[0097] Further, the circuitry can be configured to transmit a BlockAckReq frame to a second multilink device on one of the one or more links to request a BlockAck frame, the BlockAckReq frame configured to indicate whether a starting point of a block acknowledgement record maintained by one of the second plurality of stations should be replaced with a starting sequence number (SSN) value conveyed in the BlockAckReq frame.

[0098] 28 shows a detailed block diagram 2800 of a multi-link device according to this embodiment. Each of multiple wireless I / Fs 2850, 2860, and 2870 implements a respective one of physical layer (PHY) processing modules 2856, 2866, and 2876, a respective one of lower MAC function modules 2854, 2864, and 2874, and a respective one of antennas 2852, 2862, and 2872. The functionality of the wireless I / Fs 2850, 2860, and 2870 can be the same as that of the associated STAs 1280, 1282, 1284, 1286, 1288, and 1290 in FIG. 12B if such an architecture is implemented. The upper MAC functionality may be implemented as software within a central processing unit (CPU) 2830, which in operation may be coupled to a memory 2820 that may be used to store the multi-band BA scoreboard, a secondary storage device 2840, and a wired communication I / F 2880 for communicating with an external network, another AP 102, or another MLD. A power supply 2810 provides power to the AP 2802. When an architecture such as that shown in FIG. 12B is implemented, the upper MAC functionality is realized by the MLD.

[0099] The present disclosure can be realized by software, hardware, or software cooperating with hardware. Each functional block used in the above-described embodiments can be realized, in part or in whole, by an LSI such as an integrated circuit. Each process described in each embodiment can be controlled, in part or in whole, by the same LSI or a combination of LSIs. The LSI may be formed as an individual chip, or a single chip may be formed to include some or all of the functional blocks. The LSI may include a data input / output unit coupled to it. The LSI referred to here may be referred to as an IC, system LSI, super LSI, or ultra LSI depending on the level of integration. However, the technology for implementing an integrated circuit is not limited to LSI, and may be realized using dedicated circuits, general-purpose processors, or special-purpose processors. Furthermore, a field programmable gate array (FPGA), which can be programmed after the LSI is manufactured, or a reconfigurable processor, which allows the connections and settings of circuit cells arranged within the LSI to be changed, may also be used. The present disclosure can be realized as digital processing or analog processing. If future integrated circuit technology replaces LSI due to advances in semiconductor technology and other derivative technologies, it may be possible to integrate functional blocks using that future integrated circuit technology. Biotechnology can also be applied.

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

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

[0102] Some non-limiting examples of such communication devices include phones (e.g., cellular phones, smartphones), 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), gaming consoles, e-readers, telemedicine / telehealth equipment, vehicles (e.g., automobiles, airplanes, ships) that provide communication capabilities, and various combinations thereof.

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

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

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

[0106] The communications device may further include infrastructure facilities, such as base stations, access points, and any other apparatus, device, or system that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

[0107] As a non-limiting example of an architecture (e.g., the architectures shown in Figures 12A, 12B, 16, 21, and 28), the MLD of the present disclosure may be logically realized by multiple separated communication devices that share a common MAC data service interface to upper layers.

[0108] A non-limiting example of a station may be a station included in a first plurality of stations belonging to a multi-link station logical entity (i.e., MLD, etc.), where as part of the first plurality of stations belonging to the multi-link station logical entity, the stations of the first plurality of stations share a common Medium Access Control (MAC) data service interface to upper layers, and the common MAC data service interface is associated with a common MAC address or traffic identifier (TID). The station may include: circuitry that, in operation, initiates setup of a block acknowledgement agreement with a second multilink device configured to operate with a second plurality of associated stations, wherein a link is established between each station of the first plurality of stations and a corresponding station of the second plurality of stations; and a transmitter that, in operation, transmits frames of a TID over one or more links to the second multilink device based on the block acknowledgement agreement, wherein the first plurality of stations are configured to share a common transmit buffer that stores frames of the TID to be transmitted to the second multilink device and a common transmit buffer control that manages transmission of the frames on the one or more links, and wherein each of the first plurality of stations is configured to maintain a per-link transmit buffer control that manages transmission of the frames on a corresponding link of the one or more links.

[0109] It will therefore be appreciated that the present embodiments provide a communications device and method that operates over multiple links to fully realize the throughput gains of multi-link communications.

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

Claims

1. a circuit for setting up a multilink block acknowledgment agreement for the plurality of links on a first link with a recipient multilink device; a transmitter configured to transmit a plurality of MAC layer protocol data units (MPDUs) having a common traffic identifier (TID) to the recipient multi-link device over one or more of the plurality of links; a receiving unit that receives, from the receiver multilink device, a multilink block acknowledgment on the first link, indicating a reception status of a plurality of MPDUs transmitted on the one or more links, and receives, on each link, a per-link block acknowledgment on each link, indicating a reception status of one or more MPDUs transmitted on each link among the plurality of MPDUs; Equipped with the circuitry includes one common transmit buffer controller per TID that provides a plurality of MPDUs for transmission on the one or more links; Caller Multilink device.

2. The multilink block acknowledgment agreement is set up per TID by sending an Add Block Ack Request (ADDBA) and receiving an ADDBA response. The caller multilink device of claim 1 .

3. The one common transmit buffer control unit uses WinStart, which indicates the start sequence number of a transmit window common to the multiple links, and WinSize, which indicates the size of a receive reordering buffer managed by the receiver multilink device, in each block acknowledgement agreement. The caller multilink device of claim 1 .

4. the circuit, after receiving the one or more Per-Link Block Acks including reception statuses of the successfully received MPDUs at the receiver multilink device, empties a common transmit buffer corresponding to the successfully received MPDUs.

4. The caller multilink device of claim 3.

5. the received one or more Per-Link Block Acks are aggregated into a multi-link Block Ack scoreboard, which is used to determine which MPDUs among the plurality of MPDUs require retransmission; The caller multilink device of claim 1 .

6. the Multilink Block Ack Scoreboard includes a bitmap of a plurality of bits, each bit of the plurality of bits indicating whether a corresponding MPDU was successfully received at the recipient Multilink device; 6. The caller multilink device of claim 5.

7. 1. A Multilink communication method for an originator Multilink device, comprising: setting up a Multilink block acknowledgment agreement for the plurality of links on a first link with a recipient Multilink device; transmitting a plurality of MAC layer protocol data units (MPDUs) having a common traffic identifier (TID) to the recipient multi-link device over one or more of the plurality of links; receiving, from the receiver multilink device, a multilink Block Ack on the first link indicating a reception status of a plurality of MPDUs transmitted on the one or more links, and receiving, on each link, a per-link Block Ack indicating a reception status of one or more MPDUs transmitted on each link among the plurality of MPDUs; the originator multilink device includes one common transmit buffer controller per TID that provides a plurality of MPDUs for transmission on the one or more links; providing a plurality of MPDUs for transmission on the one or more links after setting up the multilink block acknowledgment agreement; Multi-link communication method.

8. The multilink block acknowledgment agreement is set up per TID by sending an Add Block Ack Request (ADDBA) and receiving an ADDBA response.

8. The multi-link communication method according to claim 7.

9. The one common transmit buffer control unit uses WinStart, which indicates the start sequence number of a transmit window common to the multiple links, and WinSize, which indicates the size of a receive reordering buffer managed by the receiver multilink device, in each block acknowledgement agreement.

8. The multi-link communication method according to claim 7.

10. and after receiving the one or more per-link Block Acks including reception statuses of the successfully received MPDUs at the receiver multi-link device, emptying a common transmit buffer corresponding to the successfully received MPDUs.

10. The multi-link communication method of claim 9.

11. the received one or more Per-Link Block Acks are aggregated into a multi-link Block Ack scoreboard, which is used to determine which MPDUs among the plurality of MPDUs require retransmission; 8. The multi-link communication method according to claim 7.

12. the Multilink Block Ack Scoreboard includes a bitmap of a plurality of bits, each bit of the plurality of bits indicating whether a corresponding MPDU was successfully received at the recipient Multilink device; 12. The multi-link communication method of claim 11.

13. 1. An integrated circuit for a caller multilink device, comprising: setting up a Multilink block acknowledgement agreement for the plurality of links on a first link with a recipient Multilink device; transmitting a plurality of MAC layer protocol data units (MPDUs) having a common traffic identifier (TID) to the recipient multilink device over one or more of the plurality of links; receiving, from the receiver multilink device, a multilink Block Ack on the first link indicating a reception status of a plurality of MPDUs transmitted on the one or more links, and receiving per-link Block Acks on each link indicating a reception status of one or more MPDUs transmitted on each link among the plurality of MPDUs; the originator multilink device includes one common transmit buffer controller per TID that provides a plurality of MPDUs for transmission on the one or more links; providing a plurality of MPDUs for transmission on the one or more links after setting up the multilink block acknowledgment agreement; An integrated circuit that controls

Images