CN117395813A - Dynamic link selection for reliable retransmission in wireless communications - Google Patents

Dynamic link selection for reliable retransmission in wireless communications Download PDF

Info

Publication number
CN117395813A
CN117395813A CN202310846466.2A CN202310846466A CN117395813A CN 117395813 A CN117395813 A CN 117395813A CN 202310846466 A CN202310846466 A CN 202310846466A CN 117395813 A CN117395813 A CN 117395813A
Authority
CN
China
Prior art keywords
mld
link
block acknowledgement
links
recommended
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310846466.2A
Other languages
Chinese (zh)
Inventor
方永刚
易志熹
徐建芳
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MediaTek Inc
Original Assignee
MediaTek Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US18/211,758 external-priority patent/US20240014982A1/en
Application filed by MediaTek Inc filed Critical MediaTek Inc
Publication of CN117395813A publication Critical patent/CN117395813A/en
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/15—Setup of multiple wireless link connections
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/08—Access point devices
    • H04W88/10—Access point devices adapted for operation in multiple networks, e.g. multi-mode access points

Abstract

Dynamic link selection for reliable retransmission in wireless communications. Techniques relating to dynamic link selection for reliable retransmission in wireless communications are described. A multi-link device (MLD) establishes a Block acknowledgement (Block Ack) protocol or a protected Block acknowledgement protocol with one other MLD over one or more enabled links for dynamic link selection. The MLD communicates with other MLDs on at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.

Description

Dynamic link selection for reliable retransmission in wireless communications
Cross-reference to related patent applications
The present invention is part of a non-provisional patent application claiming the benefit of priority from U.S. provisional patent application No.63/368,088, filed 7/11 at 2022, and claiming the benefit of priority from U.S. patent application No.18/211,758, filed 6/20 at 2023, the contents of which are incorporated herein by reference in their entirety.
Technical Field
The present invention relates generally to wireless communications, and more particularly to dynamic link selection for reliable retransmission in wireless communications.
Background
Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims listed and are not admitted to be prior art by inclusion in this section.
In wireless communications based on one or more institute of electrical and electronics engineers (Institute of Electrical and Electronics Engineers, IEEE) 802.11 standards, such as Wi-Fi (or WiFi) and wireless local area networks (wireless local area network, WLAN), wireless links may be unreliable (especially when operating on unlicensed spectrum) due to weak received signal strength indicators (received signal strength indicator, RSSI) and/or weak signal-to-interference and noise ratios (SINR) or interference from other transmitters in the coverage area. This may occur in the DL or UL or both directions due to different radio conditions on the initiator side or the receiver side, e.g. unbalanced Downlink (DL) and Uplink (UL) on the transmission and reception. In the IEEE 802.11 standard, improving transmission reliability is becoming a potential range for the next generation Wi-Fi project. For many applications such as industrial internet of things (industry internet of things, IIoT), artificial intelligence (artificial intelligence, AI), gaming, etc., ultra-high reliability for delay-sensitive transmissions is desirable, especially in non-line-of-sight (NLOS) conditions of indoor/outdoor environments.
Existing Wi-Fi techniques rely on retransmissions to improve transmission success (i.e., reliability) over the link. However, if interference on the link continues and increases the delay in user data payload reception, multiple retransmissions on a given link or decreasing the modulation and coding scheme (modulation and coding scheme, MCS) rate of the retransmission may not be successful. This can cause problems for delay sensitive applications that tend to have strict delay bound requirements. In order to support low latency applications in WLANs interworking with time-sensitive networks (time-sensitive networking, TSNs), deterministic scheduling and synchronization of TSN entities is required. Thus, the transmitting station (transmitting station, STA) needs to deterministic schedule low latency traffic and complete transmission and retransmission within the scheduled time interval with expected reliability. This also requires improvement in retransmission reliability. Thus, there is a need for a solution for dynamic link selection for reliable retransmissions in wireless communications.
Disclosure of Invention
The following summary is illustrative only and is not intended to be in any way limiting. That is, the following summary is provided to introduce a selection of concepts, benefits, and advantages of the novel and non-obvious techniques described herein. The implementation of the selection is further described in the detailed description below. Accordingly, the following summary is not intended to identify essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.
It is an object of the present invention to provide schemes, concepts, designs, techniques, methods and apparatuses related to dynamic link selection for reliable retransmissions in wireless communications. Various schemes presented herein may involve improving the transmission reliability of delay-sensitive transmissions via selection of a more reliable link for Block acknowledgement (interchangeably referred to herein as "BlockAck", and "BA") transmission and/or user data retransmission. The proposed scheme may be used for multi-link or multi-access point (multi-AP) operation of next generation Wi-Fi. It is believed that the above problems may be solved or otherwise alleviated under various proposed solutions according to the present invention.
In one aspect, a method may include a processor of a multi-link device (MLD) establishing a Block acknowledgement (Block Ack) protocol or a protected Block acknowledgement protocol with one other MLD over one or more enabled links for dynamic link selection. The method may further include the MLD communicating with the other MLD on at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
In another aspect, an apparatus capable of being implemented in an MLD may include a transceiver and a processor coupled to the transceiver. The transceiver may be configured for wireless communication. The processor may be configured to establish a block acknowledgement protocol or a protected block acknowledgement protocol with one other MLD over one or more enabled links for dynamic link selection. The processor may be further configured to communicate with the other MLD on at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
Notably, while the description provided herein may be in the context of certain radio access technologies, networks, and network topologies (such as Wi-Fi), the proposed concepts, schemes, and any variations/derivatives thereof may be implemented in, for, and by other types of radio access technologies, networks, and network topologies such as (for example and without limitation): wiMax, bluetooth, zigBee, fifth generation (5th Generation,5G)/New Radio (NR), long-Term Evolution (LTE), LTE-Advanced Pro, internet of Things (IoT), industrial IoT (IIoT), and narrowband IoT (NB-IoT). Accordingly, the scope of the disclosure is not limited to the examples described herein.
Drawings
The accompanying drawings are included to provide a further understanding of the invention, and are incorporated in and constitute a part of this specification. The accompanying drawings illustrate an implementation of the invention and, together with the description, serve to explain the principles of the invention. It will be appreciated that the drawings are not necessarily to scale, since some components may be shown out of scale from actual implementation to clearly illustrate the inventive concept.
FIG. 1 is a schematic diagram of an example architecture in which various proposed schemes according to the present invention may be implemented.
Fig. 2 is a schematic diagram of an example scenario under the proposed solution according to the invention.
Fig. 3 is a schematic diagram of an example scenario under the proposed solution according to the invention.
Fig. 4 is a schematic diagram of an example scenario under the proposed solution according to the invention.
Fig. 5 is a schematic diagram of an example scenario under the proposed solution according to the invention.
Fig. 6 is a schematic diagram of an example scenario under the proposed solution according to the invention.
Fig. 7 is a schematic diagram of an example scenario under the proposed solution according to the present invention.
Fig. 8 is a schematic diagram of an example scenario under the proposed solution according to the present invention.
Fig. 9 is a schematic diagram of an example scenario under the proposed solution according to the present invention.
Fig. 10 is a schematic diagram of an example scenario under the proposed solution according to the present invention.
Fig. 11 is a schematic illustration of an example design under the proposed solution according to the invention.
Fig. 12 is a schematic diagram of an example design under the proposed solution according to the invention.
Fig. 13 is a block diagram of an example communication system in accordance with an embodiment of the present invention.
Fig. 14 is a flowchart of an example process according to an embodiment of the invention.
Detailed Description
Detailed embodiments and implementations of the claimed subject matter are disclosed herein. It is to be understood, however, that the disclosed embodiments and implementations are merely exemplary of the claimed subject matter, which may be embodied in various forms. This invention may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments and implementations set forth herein. Rather, these exemplary embodiments and implementations are provided so that this description will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. In the following description, details of known features and/or techniques may be omitted to avoid unnecessarily obscuring the presented embodiments and implementations.
SUMMARY
Implementations consistent with the invention relate to various techniques, methods, schemes and/or solutions related to dynamic link selection for reliable retransmission in wireless communications. According to the invention, many possible solutions may be implemented individually or in combination. That is, although these possible solutions may be described separately below, two or more of these possible solutions may be implemented in one combination or another.
Fig. 1-14 illustrate examples of implementations of various proposed schemes in a network environment 100 according to the present invention. A description of the various proposed schemes is provided below with reference to fig. 1-14.
An Access Point (AP) multilink device (MLD) and STA MLD in a multilink operation (MLO) may be configured for simultaneous transmission and reception (simultaneous transmission and reception, STR) on multiple links (although simultaneous reception is not required). In quality of service (quality of service, qoS) control, a Block acknowledgement (Block Ack) policy may be set to Block acknowledgements with default traffic identifier (traffic identifier, TID) to link (T2L) mapping (or with TID mapping to two or more links). Notably, an AP affiliated with the AP MLD corresponding to the link may or may not be collocated (collocated) with the AP MLD. Currently, there are certain problems associated with multi-link retransmissions. One problem involves one or more links being unreliable and thus resulting in lost block acknowledgements. That is, an STA affiliated with the initiator MLD may transmit an aggregated media access control (medium access control, MAC) protocol data unit (aggregate MAC protocol data unit, a-MPDU) to an STA affiliated with the receiver MLD over the enabled link. In addition, STAs affiliated with the receiving party MLD may update the status of the received MPDUs in the link-level scoreboard. In addition, the STA affiliated with the initiator MLD may transmit a block acknowledgement request (Block Ack request, BAR) to the STA affiliated with the receiver MLD through the communication link to request a reception status of the transmitted MAC protocol data unit (MAC protocol data unit, MPDU) or a-MPDU. In addition, the STA attached to the receiving party MLD may transmit a BA having a status of the received MPDU. However, if one or more enabled links are unreliable, such as having a lower received signal strength indicator (received signal strength indicator, RSSI) or strong interference at the initiator side, the initiator MLD may not be able to successfully receive the BA. This may result in retransmission of MPDUs on the corresponding link, which increases delay and reduces efficiency if lower RSSI or strong interference persists on the corresponding link.
Another problem relates to one or more links being unreliable and thus resulting in lost MPDUs or a-MPDUs. That is, one or more STAs affiliated with the initiator MLD transmit MPDUs or a-MPDUs over corresponding enabled links. Then, the STA attached to the receiving party MLD updates the status of the received MPDU in the link-level scoreboard. In addition, an STA attached to the initiator MLD may transmit a BAR to the receiver MLD through a communication link to request a reception state of the transmitted MPDU or a-MPDU. In addition, the STA attached to the receiving party MLD transmits a BA having a state of the received MPDU. In addition, STAs affiliated with the initiator MLD retransmit the lost MPDU to STAs of the receiver MLD on the same link indicating the lost MPDU. However, if one of the enabled links is unreliable (such as having a lower SINR), it will result in multiple retransmissions of lost MPDUs and delay of delay-sensitive traffic when retransmissions continue on the unreliable link.
FIG. 1 illustrates an example architecture 100 in which various proposed schemes according to the present invention may be implemented. Architecture 100 may support dynamic link selection for reliable retransmission under the proposed scheme. Architecture 100 may be implemented in an initiator/transmitter MLD and a receiver MLD in various proposed schemes described below with respect to fig. 2-12. When implemented in a sender MLD, an upper MAC sublayer of the MLD may include an ordering buffer that stores aggregated MAC Service Data Units (MSDUs) received from a Logical Link Control (LLC) sublayer. When implemented in a receiver MLD, the upper MAC sublayer of the MLD may include a reorder buffer that stores received MSDUs from the MLD lower MAC of the MLD. The upper MAC sublayer of the MLD may also include a BA scoreboard that maintains the integrity of received MPDUs that are consolidated according to a link-level BA scoreboard. In addition, the lower MAC sublayer of the MLD may also include a BA scoreboard that maintains a partial state of MPDUs received over the link (e.g., a link-level scoreboard).
Fig. 2 shows an example scenario 200 under the proposed solution according to the invention. Scenario 200 may involve block acknowledgement protocol setup and block acknowledgement protocol termination. Referring to fig. 2, regarding Block acknowledgement protocol establishment, an initiator MLD (MLD 1) may send an Add Block acknowledgement (ADDBA) request to a receiver MLD (MLD 2) over any of one or more enabled links (e.g., link 1 as shown in fig. 2) to establish a Block acknowledgement protocol between MLD1 and MLD 2. Alternatively, if both MLD1 and MLD 2 support protected block acknowledgement capability, the initiator MLD1 may request establishment of the protected block acknowledgement protocol by an addrba request message with a starting sequence number and robustness. The recipient MLD 2 may send an ADDBA response to the initiator MLD1 to accept the block acknowledgement protocol on the same link (e.g., link 1) that received the ADDBA request. In the case of receiving a valid and robust ADDBA request frame, the recipient MLD 2 may update its WinStart based on the starting sequence number in the robust ADDBA request frame R Value and WinStart B Values. Alternatively, the initiator MLD and the recipient MLD may establish a link in the block acknowledgement protocol dedicated to BA transmissions between MLDs and/or deferring retransmissions. After establishing the protected block acknowledgement protocol, MLD1 may update WinStart without using the block acknowledgement starting sequence control subfield value in the block acknowledgement request frame R And WinStart B Is a value of (2). Regarding block acknowledgement protocol termination, the initiator MLD1 or the receiver MLD 2 may initiate a block acknowledgement protocol terminationStopping. In establishing the block acknowledgement protocol or the protected block acknowledgement protocol, MLD1 and MLD 2 may exchange data packets BAR and BA over at least one link (e.g., link 2 as shown in fig. 2) among the one or more enabled links. The initiator MLD1 may signal its end of use of the Block acknowledgement mechanism by sending a delete Block Ack (DELBA) frame to the recipient MLD 2 to terminate the Block acknowledgement protocol when no protocol is needed for a specified period of time or no frame exchange between MLD1 and MLD 2.
Fig. 3 shows an example scenario 300 under the proposed solution according to the invention. Scenario 300 may involve selecting a link for transmitting (Tx) a BA with a combined reception status. Referring to fig. 3, an initiator MLD (MLD 1) may begin transmitting MAC packets (e.g., MPDUs or a-MPDUs) to a receiver MLD (MLD 2) over a T2L mapped link (e.g., an enabled link). The STA of the receiving party MLD 2 may update the status of the received MAC packet in the link-level scoreboard. In addition, the STA of the initiator MLD1 may send a block acknowledgement request (Block Ack request, BAR) and/or a multi-link BAR (ML-BAR) to request the status of the sent MAC packets received on the corresponding link and/or other links. The recipient MLD 2 may send the BA with the status of the received MAC packet on the corresponding link and/or other links to the initiator MLD1 on the same link. In case of successful reception of the BA, the STA of the initiator MLD1 may retransmit the lost MPDU to the STA of the receiver MLD 2 on the same link according to the status of the received MPDU in the received BA. In the event that a BA responding to the BAR is not successfully received, the STA affiliated with the initiator MLD1 may transmit another BAR with a recommended link Identifier (ID) to the receiver MLD 2 to request that the reception status of the transmitted MAC packet on the link be included in the BA on the recommended link. In addition, the STA of the receiving party MLD 2 receiving the BAR merges the reception status of the received MAC packet in the link-level scoreboard into the MLD-level scoreboard. The recipient MLD 2 may then send the BA with the reception status of the combined MAC packet to the initiator MLD1 over the recommended link. In addition, the STA of the initiator MLD1 may retransmit the lost MAC packet (if any) to the STA of the receiver MLD 2 on the same link. Otherwise, the STA of the initiator MLD1 may continue to transmit new MAC packets to the receiver MLD 2 on the same link. In addition, the initiator MLD1 may include in the BAR to the recipient MLD 2 a recommended link for transmitting the BA from the recipient MLD 2 in order to avoid transmitting (retransmitting) the BA on an unreliable link. The initiator MLD1 may continue to send new MAC packets on other enabled links to help improve channel usage efficiency. If the initiator MLD1 is aware that it is transmitting a BA on an unreliable link, the initiator MLD1 may transmit a BAR with a recommended link ID to the recipient MLD 2 to request that a BA with the reception status of the combined transmitted MAC packet be transmitted on the recommended link to avoid transmitting and/or retransmitting the BA on the unreliable link.
Fig. 4 shows an example scenario 400 under the proposed solution according to the invention. Scenario 400 may involve selecting a link for transmitting BAs with combined reception status without a transmission opportunity (TXOP). Referring to fig. 4, an initiator MLD (MLD 1) may begin transmitting MAC packets (e.g., MPDUs or a-MPDUs) to a receiver MLD (MLD 2) over T2L mapped links (e.g., a subset of enabled links). The STA of the receiving party MLD 2 may update the status of the received MAC packet in the link-level scoreboard. The STA of the initiator MLD1 may transmit a BAR/ML-BAR to request the reception status of the transmitted MAC packet on the corresponding link and/or other links. In response, the recipient MLD 2 may send the BA with the status of the received MAC packet on the corresponding link and/or other links to the initiator MLD1 on the same link. In case of successful reception of the BA, the STA of the initiator MLD1 may retransmit the lost MPDU to the STA of the receiver MLD 2 on the same link according to the status of the received MPDU in the received BA. In the event that a BA that responds to the BAR is not successfully received, the STA affiliated with the initiator MLD1 may send another BAR with a recommended link ID (e.g., in an idle state) to the recipient MLD 2 to request a BA that includes the received state of the transmitted MAC packet on the link to be sent on the recommended link. The STA of the receiving party MLD 2 receiving the BAR may incorporate the reception status of the received MAC packet in the link-level scoreboard into the MLD-level scoreboard. In the case that the recommended link for the TXOP is not established, the recipient MLD 2 may then send a BA with the status of the combined received MAC packets to the initiator MLD1 over the recommended link after performing the enhanced distributed channel access (enhanced distributed channel access, EDCA) and after establishing the TXOP. The STA of the initiator MLD1 may retransmit the lost MAC packet to the STA of the receiver MLD 2 on the same link. If a STA affiliated with the initiator MLD1 receives a BA over the recommended link, the STA may continue to send new MAC packets or respond with an Acknowledgement (ACK) if no lost MAC packets are reported in the BA; otherwise, the STA may retransmit the lost MAC packet according to the status of the received MPDU in the received BA. The initiator MLD1 may continue to send new MAC packets on other links, which may help to improve channel usage efficiency.
Fig. 5 shows an example scenario 500 under the proposed solution according to the invention. Scenario 500 may involve selecting a link for transmitting BAs with a merge state in response to repeated transmissions. Referring to fig. 5, an upper MAC sublayer of an initiator MLD (MLD 1) may copy MSDUs and may distribute MPDUs or a-MPDUs to dependent STAs for transmission reliability improvement. The dependent STA may then transmit the duplicate MAC packet (e.g., MPDU or a-MPUD) to a STA dependent on the receiving party MLD (MLD 2) on the corresponding enabled link. STAs affiliated with the receiving party MLD2 may update the status of the received MAC packets on the corresponding link in its link-level scoreboard. The initiator MLD 1 may send a BAR (or ML-BAR) with a deferred retransmission indication (deferred retransmission indication, DRTI) to the receiver MLD2 to indicate deferred retransmission and request to merge the reception status of the sent MAC packet on the corresponding link. The STA of the receiving party MLD2 receiving the BAR/ML-BAR with DTRI may incorporate the status of the received MAC packet at the link-level scoreboard into the MLD-level scoreboard. The STA may then send a BA with acknowledgement of the DRTI to the initiator MLD 1 on the same link, with the full state of the received MAC packet combined at the upper MAC or the partial state of the received MAC packet on its link. In the event that a deferred retransmission is established on a link (e.g., link 1 or link 2), the initiator MLD 1 may continue to send new MAC packets on the same link, if desired. In the event that a deferred retransmission is not established on a link (e.g., link 3) and at least one lost MAC packet is indicated in the BA, the initiator MLD 1 may instruct the dependent STA to retransmit the lost MAC packet to the recipient MLD2 on the same link. After the packet is successfully delivered to the receiving party MLD2 or exceeds the set-up delivery time, the originating party MLD 1 may release the transmitted MAC packet from the ordering buffer, and the receiving party MLD2 may forward the received MAC packet to an upper layer and clear the state of the received MAC packet.
Fig. 6 shows an example scenario 600 under the proposed solution according to the invention. Scenario 600 may involve selecting a link for transmitting BAs with a merge state without a TXOP in response to repeated transmissions. Referring to fig. 6, an upper MAC sublayer of an initiator MLD (MLD 1) may copy MSDUs and may distribute MPDUs or a-MPDUs to dependent STAs for transmission reliability improvement. The dependent STA may then transmit the duplicate MAC packet (e.g., MPDU or a-MPUD) to a STA dependent on the receiving party MLD (MLD 2) on the corresponding enabled link. After receiving the MAC packet, the STA affiliated with the receiving party MLD2 may update the status of the received MAC packet on the corresponding link in its link-level scoreboard. The initiator MLD 1 may send a BAR (or ML-BAR) with DRTI to the receiver MLD2 to indicate deferred retransmission and request to merge the reception status of the sent MAC packet on the corresponding link. STAs of the recipient MLD2 that receive the BAR with DTRI may incorporate the status of the received MAC packets at the link-level scoreboard into the MLD-level scoreboard. The STA may then send a BA with acknowledgement of the DRTI to the initiator MLD 1 on the same link, with the full state of the received MAC packet combined at the upper MAC or the partial state of the received MAC packet on its link. In the event that a deferred retransmission is established on a link (e.g., link 1), the initiator MLD 1 may continue to send new MAC packets on the same link, if desired. In the event that a deferred retransmission is not established on a link (e.g., link 2) and at least one lost MAC packet is indicated in the BA, if a recommended link (e.g., link 3) is included in the BA, the initiator MLD 1 may instruct the corresponding dependent STA to retransmit the lost MAC packet to the recipient MLD2 on the recommended link. In the event that a TXOP has not been established on the proposed link between the initiator MLD 1 and the receiver MLD2, the dependent STA with the initiator MLD 1 may retransmit the lost MAC packet after EDCA is performed and after the TXOP is established. After the packet is successfully delivered to the receiving party MLD2 or exceeds the set-up delivery time, the originating party MLD 1 may release the transmitted MAC packet from the ordering buffer, and the receiving party MLD2 may forward the received MAC packet to an upper layer and clear the state of the received MAC packet.
Fig. 7 shows an example scenario 700 under the proposed solution according to the present invention. The scenario 700 may involve a link recommended by the recipient for retransmission of lost MPDUs. Referring to fig. 7, an initiator MLD (MLD 1) may start transmitting a MAC packet (e.g., MPDU or a-MPDU) to a receiver MLD (MLD 2) through an enabled link mapped by a Traffic Identifier (TID) to link mapping (T2 LM). The STA of the receiving party MLD 2 may update the status of the received MAC packet in the corresponding link-level scoreboard. The STA of the initiator MLD 1 may transmit a BAR/ML-BAR to request the reception status of the transmitted MAC packet on the corresponding link and/or other links. In the event that a BAR/ML-BAR is successfully received, STAs affiliated with the receiving party MLD 2 may send a BA with the status of the received MAC packet on the corresponding link and/or other links to the originating party MLD 1 on the same link. Alternatively, if it is determined that the link currently used to receive the MAC packet is unreliable (e.g., the number of lost MAC packets or the number of BAs for retransmitting the lost MAC packet on the same link exceeds a given threshold), the STA of the receiving party MLD 2 may send the BA with the status of the received MAC packet and the recommended link ID to the originating party MLD 1 to request retransmission of the lost MAC packet on the recommended link and/or RSSI information. In the case where the receiving party MLD 2 requests the originating party MLD 1 to retransmit the lost MAC packet on the recommended link, the receiving party MLD 2 may reset the receiving state of the scoreboard on the recommended link with the receiving state of the MLD-level scoreboard. Receiver MLD 2 may utilize WinStart of receive reorder buffer control B WinStart to update scoreboard context control over recommended links R . This can avoid pushing that is being discardedThe MAC packet is retransmitted on the referral link. The initiator MLD 1 receiving the BA may instruct the dependent STA to retransmit the lost MAC packet to the receiver MLD 2 on the recommended link. Alternatively, the initiator MLD 1 may continue to send one or more new MAC packets to the receiver MLD 2 over the recommended link.
Fig. 8 shows an example scenario 800 under the proposed solution according to the invention. Scenario 800 may involve a link recommended by a recipient to replicate a retransmission of a lost MPDU. Referring to fig. 8, an initiator MLD (MLD 1) may start transmitting a MAC packet (e.g., MPDU or a-MPDU) to a receiver MLD (MLD 2) through an enabled link mapped by a T2 LM. The STA of the receiving party MLD 2 may update the status of the received MAC packet at the corresponding link-level scoreboard. The STA of the initiator MLD 1 may send a BAR/ML-BAR to request the reception status of the sent MAC packets on the corresponding link and/or other enabled links mapped by the T2 LM. The STA of the receiving party MLD 2 receiving the BAR/ML-BAR may incorporate the status of the received MAC packets on its link-level scoreboard into the MLD-level scoreboard and may then send the BA with the status of the received MAC packets on the corresponding link and/or other links to the initiator MLD 1 on the same link. Alternatively, if it is determined that the link currently used to receive the MAC packet is unreliable, the STA of the receiving party MLD 2 may transmit a BA including the status of the received MAC packet and recommended link ID and/or RSSI information to the originating party MLD 1 on the corresponding link to request retransmission of the lost MAC packet on the recommended link. Receiver MLD 2 may utilize WinStart of receive reorder buffer control B WinStart to update scoreboard context control over recommended links R . This may avoid retransmitting MAC packets on the discarded recommended link. The initiator MLD 1 receiving the BA may copy the lost MAC packets and may instruct the corresponding dependent STA to retransmit these lost MAC packets to the receiver MLD 2 over the recommended link. The receiving party MLD 2 may receive the retransmitted lost MAC packet on the recommended link and may merge the state of the receiving party link. The recipient MLD 2 may also respond to the BAR with a merge state in the BA. Alternatively, the initiator MLD 1 may continue to send one or more new MAC packets to the receiver MLD 2 over the recommended link.
Fig. 9 shows an example scenario 900 under the proposed solution according to the invention. Scenario 900 may involve recommending, by a recipient, a link for retransmitting a hybrid MPDU without a TXOP. Referring to fig. 9, an initiator MLD (MLD 1) may start transmitting MAC packets (e.g., MPDUs or a-MPDUs) to a receiver MLD (MLD 2) on a subset of enabled links (e.g., link 1 and link 2 when link 3 is busy). STAs affiliated with the receiving party MLD 2 may update the status of the received MAC packet in the corresponding link-level scoreboard. The STA affiliated with the initiator MLD 1 may transmit a BAR/ML-BAR to request the reception status of the transmitted MAC packets on the corresponding link and/or other links. In the event that a BAR/ML-BAR is successfully received, STAs affiliated with the receiving party MLD 2 may send a BA with the status of the received MAC packet on the corresponding link and/or other links to the originating party MLD 1 on the same link. Alternatively, if it is determined that the link currently used to receive the MAC packet is unreliable (e.g., the number of lost MAC packets or the number of BAs for retransmitting the lost MAC packet on the same link exceeds a given threshold), the STA affiliated with the recipient MLD 2 may send a BA with the status of the received MAC packet and with recommended link ID and/or RSSI information to the initiator MLD 1 on the same link to request retransmission of the lost MAC packet on the recommended link (e.g., in an idle state). In the case where the receiving party MLD 2 recommends that the originating party MLD 1 retransmit the lost MAC packet on the recommended link, the receiving party MLD 2 may reset the receiving state of the scoreboard on the recommended link with the receiving state of the MLD-level scoreboard. Receiver MLD 2 may utilize WinStart of receive reorder buffer control B WinStart to update scoreboard context control over recommended links R . This may avoid retransmitting MAC packets on the discarded recommended link. In the case where an STA affiliated with the initiator MLD 1 receives a BA with the recommended link without establishing a TXOP, the STA may retransmit the lost MAC packet to the recipient MLD 2 on the recommended link after EDCA is performed and after the TXOP is established.
Fig. 10 shows an example scenario 1000 under the proposed solution according to the invention. Scenario 1000 may involve selection by the initiatorAnd on the link where the lost MPDU is retransmitted. Referring to fig. 10, an initiator MLD (MLD 1) may start transmitting a MAC packet to a receiver MLD 2 through an enabled link mapped by the T2 LM. The STA of the receiving party MLD 2 may update the status of the received MAC packet in the corresponding link-level scoreboard. The STA of the initiator MLD 1 may transmit a BAR/ML-BAR to request the reception status of the transmitted MAC packet on the corresponding link and/or other links. In the event that a BAR/ML-BAR is successfully received, STAs affiliated with the receiving party MLD 2 may send a BA with the status of the received MAC packet on the corresponding link and/or other links to the originating party MLD 1 on the same link. The initiator MLD 1 may determine the retransmission reliability of the link based on the number of BAs used to retransmit the lost MAC packet on the link and may determine a different link to use to retransmit the lost MAC packet. The STA attached to the initiator MLD 1 may transmit a BAR/ML-BAR with a recommended link ID to the receiver MLD 2 to request that the reception status of the transmitted MAC packet on the link be included in the BA transmitted on the recommended link. STAs affiliated with the recipient MLD 2 that receive the BAR may respond with the BA on the same link to agree to retransmissions on other links, and may then merge the receive status of the transmitted MAC packet in the link-level scoreboard into the MLD-level scoreboard. Receiver MLD 2 may utilize WinStart controlled by the receive reorder buffer B WinStart to update scoreboard context control over a recommended link R This may avoid retransmitting MAC packets on the discarded recommended link. The recipient MLD 2 may then send the BA with the status of the combined received MAC packet to the initiator MLD 1 over the recommended link. The initiator MLD 1 may retransmit the lost MAC packet on the recommended link according to the status of the received MPDU in the received BA.
Fig. 11 shows an example design 1100 under the proposed solution according to the invention. Design 1100 may involve a block acknowledgement request (BlockAckReq) or a multilink block acknowledgement request (ML-BlockAckReq). Referring to fig. 11, a block acknowledgement request (or a multi-link block acknowledgement request) under the proposed scheme may contain a plurality of fields including, for example, a Receiver Address (RA) field, a transmitter address (transmitter address, TA) field, a BAR control field, and a BAR/link ID information field. The RA field may be set to the address of the receiving STA. The TA field may be set to the address of the transmitting STA. The BAR control field may indicate the number of DRTI subfields and link ID subfields, among other subfields. The DRTI subfield may be set to 1 to indicate a deferred retransmission; otherwise, the DRTI subfield may be set to 0. The number of the link ID subfield may be set to the number of link IDs (0 to 2) to be included in the block acknowledgement request. The link ID may indicate a link of a set of enabled links through which the recipient MLD is to send a block acknowledgement in response to the BAR. In the event that the number of the link ID subfield is set to a non-zero value, the receiving party MLD may incorporate the status of the received MPDUs in the link-level scoreboard into the MLD level. Further, the value of this subfield may be set to 3 to indicate deferred retransmission. The BAR/link ID information field may include a link ID. That is, if the number of link ID subfields is not equal to "0", the BAR/link ID information field may include one or more link ID subfields, the number of which is specified by the number of link ID subfields. Otherwise, the link ID subfield may not be included.
Fig. 12 shows an example design 1200 under the proposed solution according to the invention. Design 1200 may involve block acknowledgement (BlockAck) or multi-link block acknowledgement (ML-BlockAck). Referring to fig. 12, a block acknowledgement (or multi-link block acknowledgement) under the proposed scheme may contain a plurality of fields including, for example, an RA field, a TA field, a BA control field, and a BA/link ID information field. The RA field may be set to the address of the receiving STA. The TA field may be set to the address of the transmitting STA. The BA control field may indicate, among other subfields, the digits of the DRTA/SINR Inc subfield and the link ID subfield. The DTRA/SINR Inc subfield may relate to acknowledgement of deferred retransmissions and may be set to 1 to indicate acknowledgement of deferred retransmissions or to indicate that SINR subfields are included in block acknowledgements. Otherwise, the subfield may be set to 0. The number of the link ID subfield may be set to the number (0 to 2) of link ID subfields included in the BA/link ID information field. The link ID indicates the link of a set of enabled links over which the initiator MLD is to send retransmissions in response to the BA. The value of this subfield may be set to 3 to indicate acknowledgement of deferred retransmission. The BA/link ID information field may include a compressed BA, a multi-TID BA, or other variant subfields. Further, the BA/link ID information field may include a link ID subfield and a SINR subfield. In the case where the number of the link ID subfield is not equal to "0", the link ID subfield may include one or more link IDs, the number of which is specified by the number of the link ID subfields. Otherwise, this subfield may not be included. In the case where the number of the link ID subfield is equal to "0" and the DRTA/SINR Inc subfield is set to "1", the SINR subfield may include a signal-to-interference-and-noise ratio (SINR) corresponding to the current reception link. In the case where the number of the link ID subfield is not equal to "0" and the DRTA/SINR Inc subfield is set to "1", the SINR subfield may include one or more SINRs for the corresponding link, the number of which is specified by the number of the link ID subfield. Otherwise, this subfield may not be included.
Thus, under various proposed schemes for improving reliability of transmission and retransmission according to the present invention, an MLD may transmit an ADDBA request to another MLD to establish a block acknowledgement protocol or a protected block acknowledgement protocol between the two MLDs for dynamic link selection. In addition, under various proposed schemes for improving reliability of transmission and retransmission according to the present invention, the initiator MLD may transmit data packets, followed by BARs, on one or more enabled links. In addition, under various proposed schemes for improving reliability of transmission and retransmission according to the present invention, the receiving party MLD may select and transmit a block acknowledgement with a combined reception state to the originating party MLD on a link in response to the BAR from the originating party MLD. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the selected link for sending the block acknowledgement may be among those ongoing communication links protected by the current TXOP. In this case, the current TXOP may protect the ongoing communication link for a period of time reserved for transmission between the initiator MLD and the recipient MLD on the selected link. Alternatively or additionally, the recipient MLD may select and send a block acknowledgement with a combined reception state to the initiator MLD over the link in response to the BAR from the initiator MLD. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection and the selected link for sending the block acknowledgement may not be among the ongoing communication links protected by the current TXOP. Still alternatively or additionally, the recipient MLD may select and send a block acknowledgement with a combined reception state to the initiator MLD over the link in response to the data packet received from the initiator MLD. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the selected link for sending the block acknowledgement may be among the ongoing communication links protected by the current TXOP.
Under various proposed schemes according to the present invention regarding improving reliability of transmission and retransmission, the receiving party MLD may transmit a block acknowledgement with a combined reception state to the originating party MLD over the link in response to the BAR with a deferred retransmission indication. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection and may send a block acknowledgement on the ongoing communication link protected by the current TXOP. Alternatively or additionally, the recipient MLD may send a block acknowledgement with a combined reception state to the initiator MLD over the link in response to the BAR with a deferred retransmission indication. In this case, the initiator MLD and the receiver MLD may have established a block acknowledgement protocol for dynamic link selection and may send a block acknowledgement on a link that is not protected by the current TXOP.
Under various proposed schemes according to the present invention regarding improving reliability of transmission and retransmission, the receiving party MLD may transmit a block acknowledgement with a combined reception state to the originating party MLD over a link in response to the BAR. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection and the block acknowledgement sent on the link protected by the current TXOP may indicate a recommended link for retransmission of any lost data packets. The recommended link may be an ongoing communication link protected by the current TXOP. In response to receiving a block acknowledgement with a recommended link for retransmission, the initiator MLD may retransmit the lost data packet to the recipient MLD over the recommended link. Alternatively or additionally, the recipient MLD may send a block acknowledgement with a combined reception state to the initiator MLD over the link in response to the BAR. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection and the block acknowledgement sent on the link protected by the current TXOP may indicate a recommended link for retransmission of any lost data packets. The recommended link may be an ongoing communication link protected by the current TXOP. In response to receiving a block acknowledgement with the recommended link for retransmission, the initiator MLD may retransmit the lost data packet to the recipient MLD on the recommended link after successfully gaining or gaining access to the medium on the recommended link.
Under various proposed schemes according to the present invention regarding improving reliability of transmission and retransmission, the receiving party MLD may transmit a block acknowledgement with a combined reception state to the originating party MLD over a link in response to the BAR. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the block acknowledgement sent on the link protected by the current TXOP may indicate one or more recommended links for replicating retransmission of any lost data packets. The recommended link may be among the ongoing communication links protected by the current TXOP. In response to receiving a block acknowledgement with a recommended link for duplicate retransmissions, the initiator MLD may duplicate retransmissions of the lost data packet to the recipient MLD on the recommended link. Alternatively or additionally, the recipient MLD may send a block acknowledgement with a combined reception state to the initiator MLD over the link in response to the BAR. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the block acknowledgement sent on the link protected by the current TXOP may indicate one or more recommended links for replicating retransmission of any lost data packets. In response to receiving a block acknowledgement with a recommended link for duplicate retransmissions, the initiator MLD may duplicate retransmissions of the lost data packet to the recipient MLD after successfully gaining or gaining access to the medium on the recommended link.
Under various proposed schemes according to the present invention regarding improving reliability of transmission and retransmission, the initiator MLD may transmit the BAR to the receiver MLD over the link. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the BAR sent on the link protected by the current TXOP may indicate one or more recommended links for retransmission of any lost data packets. The recommended link may be among the ongoing communication links protected by the current TXOP. In response to receiving the BAR with the recommended link for retransmission, the recipient MLD may respond with a block acknowledgement with an acknowledgement of the recommended link for retransmission of the lost data packet. Alternatively or additionally, the initiator MLD may send the BAR to the recipient MLD over the link. In this case, the initiator MLD and the recipient MLD may have established a block acknowledgement protocol for dynamic link selection, and the BAR sent on the link protected by the current TXOP may indicate one or more recommended links for retransmitting any lost data packets. The recommended link may be among the ongoing communication links protected by the current TXOP. In response to receiving the BAR with the recommended link for retransmission, the recipient MLD may respond with a block acknowledgement with an acknowledgement of the recommended link for retransmission of the lost data packet.
In view of the above, many benefits of dynamic link selection for reliable retransmission under various proposed schemes according to the present invention can be summarized below. First, the proposed scheme exploits the advantages of MLO to improve retransmission reliability (especially for delay sensitive traffic) based on the real-time status of received MPDUs on enabled links at the receiving MLD and/or recommendations of links for retransmission. Second, the initiator MLD may request that the BA include the status of the received MPDUs in the link level or MLD level. Third, the initiator MLD may request the receiver MLD to transmit the BA on a different link than the link receiving the BAR in order to improve the reliability of receiving the BA. Fourth, the initiator MLD may retransmit the lost MPDU on the link recommended by the receiver MLD in the BA, and the initiator MLD may continue to transmit new MAC packets on the same recommended link. Fifth, the recipient MLD may respond to the BAR with a status BA including the received MPDU on the same link and/or other links via a merge of the received status in the MLD-level scoreboard. In addition, the recipient MLD may respond to the BAR with a BA including one or more recommended link IDs to designate retransmission of lost MPDUs on the recommended link, thereby improving retransmission reliability. Furthermore, dynamic link selection for reliable retransmission may be used in the protected block acknowledgement protocol. Further, similar mechanisms may be used in other control frames for recommending links and/or providing SINR information.
Exemplary implementation
Fig. 13 illustrates an example system 1300 having at least example apparatus 1310 and example apparatus 1320 in accordance with an implementation of the invention. One or each of the devices 1310 and 1320 may perform various functions to implement the schemes, techniques, processes, and methods described herein in connection with dynamic link selection for reliable retransmission in wireless communications, including the various proposed designs, concepts, schemes, systems, and methods described above, as well as the processes described below. For example, in accordance with various proposed aspects of the present disclosure, apparatus 1310 may be implemented in a sender MLD, while apparatus 1320 may be implemented in a receiver MLD, or vice versa.
Each of the devices 1310 and 1320 may be part of an electronic device, which may be a non-AP MLD or an AP MLD, such as a portable or mobile device, a wearable device, a wireless communication device, or a computing device. When implemented in a non-AP MLD, each of the apparatus 1310 and 1320 may be implemented in a smart phone, a smart watch, a personal digital assistant, a digital camera, or a computing device such as a tablet computer, a laptop computer, or a notebook computer. Each of the devices 1310 and 1320 may be part of a machine-type device, which may be an IoT device such as a stationary or fixed device, a home device, a wired communication device, or a computing device. For example, each of the devices 1310 and 1320 may be implemented in a smart thermostat, a smart refrigerator, a smart door lock, a wireless speaker, or a home control center. When implemented in or as a network device, the apparatus 1310 and/or 1320 may be implemented in a network node, such as an AP MLD in a WLAN. In any case, in various implementations, one of the devices 1310 and 1320 may be implemented in or as a non-AP MLD, while the other of the devices 1310 and 1320 may be implemented in or as an AP MLD.
In some implementations, each of the devices 1310 and 1320 may be implemented in the form of one or more integrated-circuit (IC) chips, such as, for example and without limitation, one or more single-core processors, one or more multi-core processors, one or more reduced-instruction-set-instruction set computing (RISC) processors, or one or more complex instruction-set-computing (CISC) processors. In the various aspects described above, each of the apparatus 1310 and 1320 may be implemented in or as a non-AP MLD or AP MLD. For example, each of the devices 1310 and 1320 may include at least some of those components shown in fig. 13, such as processor 1312 and processor 1322, respectively. Each of the apparatus 1310 and 1320 may also include one or more other components (e.g., an internal power source, a display device, and/or a user interface device) that are not relevant to the proposed solution of the present invention, and thus, such components of the apparatus 1310 and 1320 are neither shown in fig. 13 nor described below for simplicity and brevity.
In one aspect, each of processors 1312 and 1322 may be implemented in the form of one or more single-core processors, one or more multi-core processors, one or more RISC processors, or one or more CISC processors. That is, even though the singular terms "processor" are used herein to refer to processor 1312 and processor 1322, each of processor 1312 and processor 1322 in accordance with the present invention may include multiple processors in some implementations, and a single processor in other implementations. In another aspect, each of processor 1312 and processor 1322 may be implemented in hardware (and optionally firmware) having electronic components including, for example and without limitation, one or more transistors, one or more diodes, one or more capacitors, one or more registers, one or more inductors, one or more memristors, and/or one or more varactors configured and arranged to achieve the particular objects in accordance with the invention. In other words, in at least some implementations, each of processor 1312 and processor 1322 is a special purpose machine specifically designed, arranged, and configured to perform specific tasks, including those tasks related to dynamic link selection for reliable retransmission in wireless communications in accordance with various implementations of the invention.
In some implementations, the apparatus 1310 may also include one or more transceivers 1316 coupled to the processor 1312. Each of the one or more transceivers 1316 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data. In some implementations, the apparatus 1320 may also include one or more transceivers 1326 coupled to the processor 1322. Each of the one or more transceivers 1326 may include a transmitter capable of wirelessly transmitting and a receiver capable of wirelessly receiving data.
In some implementations, the apparatus 1310 may also include a memory 1314 coupled to the processor 1312 and capable of being accessed by the processor 1312 and storing data therein. In some implementations, the apparatus 1320 may also include a memory 1324 coupled to the processor 1322 and capable of being accessed by the processor 1322 and storing data therein. Each of the memory 1314 and the memory 1324 may include a random-access memory (RAM) type such as Dynamic RAM (DRAM), static RAM (SRAM), thyristor RAM (T-RAM), and/or zero-capacitor RAM (Z-RAM). Alternatively or additionally, each of memory 1314 and memory 1324 may include read-only memory (ROM) types, such as mask ROM, programmable ROM (PROM), erasable programmable ROM (erasable programmable ROM, EPROM), and/or electrically erasable programmable ROM (electrically erasable programmable ROM, EEPROM). Alternatively or additionally, each of memory 1314 and memory 1324 may include non-volatile random-access memory (NVRAM) types, such as flash memory, solid-state memory, ferroelectric RAM (FeRAM), magnetoresistive RAM (MRAM), and/or phase-change memory.
Each of the devices 1310 and 1320 may be communication entities capable of communicating with each other using various proposed schemes according to the present invention. For illustrative purposes, and not limitation, a description of the capabilities of the apparatus 1310 (e.g., sender MLD or receiver MLD) and the apparatus 1320 (e.g., receiver MLD or sender MLD) is provided below. It is noted that although the example implementations described below are provided in the context of a WLAN, they may also be implemented in other types of networks. It is also noted that although the examples described below are provided in the context of apparatus 1310, these examples may also apply to apparatus 1320 or otherwise be implemented by apparatus 1320.
Under various proposed schemes for dynamic link selection for reliable retransmission in wireless communications in accordance with the present invention, processor 1312 may establish a block acknowledgement protocol or a protected block acknowledgement protocol with one other MLD (e.g., device 1320) over one or more enabled links via transceiver 1316 for dynamic link selection. In addition, the processor 1312 may communicate with other MLDs over at least one of the one or more enabled links via the transceiver 1316 prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
In some implementations, in terms of communications, the processor 1312 may perform certain operations (as the recipient MLD). For example, processor 1312 may select a link from one or more enabled links. Further, processor 1312 may send a block acknowledgement with a combined reception status to the other MLD (as the initiator MLD) on the selected link in response to receiving the BAR from the other MLD. In some implementations, the selected link may be among one or more ongoing communication links protected by a current TXOP that includes a period reserved for transmissions between the MLD and other MLDs. Alternatively, the selected link may not be among the one or more ongoing communication links protected by the current TXOP.
In some implementations, in terms of communications, the processor 1312 may perform certain operations (as the recipient MLD). For example, processor 1312 may select a link from one or more enabled links. In addition, processor 1312 may send a block acknowledgement with a combined reception status to the other MLD (as the initiator MLD) on the selected link in response to receiving one or more data packets from the other MLD. In this case, the selected link may be among the one or more ongoing communication links protected by the current TXOP.
In some implementations, in terms of communications, processor 1312 may send a block acknowledgement with a combined receipt status (as the initiator MLD) to other MLDs (as the recipient MLD) in response to receiving a BAR with a deferred retransmission indication from the other MLDs. In some implementations, the block acknowledgement may be sent over an ongoing communication link protected by the current TXOP. Alternatively, the block acknowledgement may be sent on a link that is not protected by the current TXOP.
In some implementations, in terms of communications, the processor 1312 may send a block acknowledgement with a combined reception status (as the recipient MLD) to other MLDs (as the initiator MLD) in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate a recommended link for retransmission of the lost data packet, where the recommended link is an ongoing communication link protected by the current TXOP. Further, process 1400 may include: processor 1312 receives retransmission of lost data packets from other MLDs over the recommended link.
In some implementations, in terms of communications, process 1400 may include: processor 1312 sends or receives block acknowledgements including SINR information on one or more corresponding links.
In some implementations, in terms of communications, the processor 1312 may send a block acknowledgement with a combined reception status (as the recipient MLD) to other MLDs (as the initiator MLD) in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate a recommended link for retransmission of the lost data packet, where the recommended link is not an ongoing communication link protected by the current TXOP. Further, after the other MLD successfully gains access to the medium on the recommended link, the processor 1312 may receive a retransmission of the lost data packet from the other MLD on the recommended link.
In some implementations, in terms of communications, the processor 1312 may send a block acknowledgement with a combined reception status (as the recipient MLD) to other MLDs (as the initiator MLD) in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate one or more recommended links for replicating retransmission of the lost data packet, wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP. In addition, processor 1312 may receive retransmissions of the replicated lost data packets from other MLDs over one or more recommended links.
In some implementations, in terms of communications, the processor 1312 may send a block acknowledgement with a combined reception status (as the recipient MLD) to other MLDs (as the initiator MLD) in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP and the block acknowledgement may indicate one or more recommended links for copying retransmissions of lost data packets, wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP. In addition, after the other MLD successfully gains access to the medium on the one or more recommended links, the processor 1312 may receive a retransmission of the replicated lost data packet from the other MLD on the one or more recommended links.
In some implementations, in terms of communications, processor 1312 may send BAR (as an initiator MLD) to device 1320 (as a receiver MLD). In some implementations, the BAR may be sent on a link protected by the current TXOP and the BAR may indicate one or more recommended links for retransmission of the lost data packet, wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP. Further, the processor 1312 may receive a block acknowledgement from the other MLD with acknowledgements for one or more recommended links for retransmission of one or more lost data packets.
In some implementations, in terms of communications, processor 1312 may send BAR (as an initiator MLD) to device 1320 (as a receiver MLD). In some implementations, the BAR may be sent on a link protected by the current TXOP and the BAR may indicate one or more recommended links for retransmission of lost data packets, wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP. Further, the processor 1312 may receive a block acknowledgement from the other MLD with acknowledgements for one or more recommended links for retransmission of one or more lost data packets.
Exemplary Process
FIG. 14 illustrates an example process 1400 in accordance with implementations of the invention. Process 1400 may represent aspects of implementing the various proposed designs, concepts, schemes, systems, and methods described above. More particularly, process 1400 may represent aspects of the concepts and aspects presented in connection with dynamic link selection for reliable retransmission in wireless communications in accordance with the subject invention. Process 1400 may include one or more operations, actions, or functions as illustrated by one or more of blocks 1410 and 1420. While illustrated as separate blocks, the various blocks of process 1400 may be divided into additional blocks, combined into fewer blocks, or eliminated, depending on the desired implementation. Further, the blocks/sub-blocks of process 1400 may be performed in the order shown in fig. 14, or alternatively, in a different order. Moreover, one or more of the blocks/sub-blocks of process 1400 may be performed repeatedly or iteratively. Process 1400 may be implemented by apparatus 1310 and apparatus 1320, and any variations thereof, or may be implemented in apparatus 1310 and apparatus 1320, and any variations thereof. For illustrative purposes only and without limiting the scope, process 1400 is described below in the context of an apparatus 1310 (implemented in MLD1 or as MLD 1) and an apparatus 1320 (implemented in MLD2 or as MLD 2) of a wireless network (such as the WLAN shown in fig. 2-10) according to one or more of the IEEE 802.11 standards. It is noted that although the examples described below are provided in the context of an apparatus 1310 implementing a first MLD (e.g., MLD 1) and an apparatus 1320 implementing a second MLD (e.g., MLD 2). Process 1400 may begin at block 1410.
At 1410, process 1400 may include: processor 1312 establishes a block acknowledgement protocol or protected block acknowledgement protocol with one other MLD (e.g., device 1320) over one or more enabled links via transceiver 1316 for dynamic link selection. Process 1400 may proceed from 1410 to 1420.
At 1420, process 1400 may include: processor 1312 communicates with the other MLD via transceiver 1316 on at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
In some implementations, in terms of communications, process 1400 may include: processor 1312 performs certain operations. For example, process 1400 may include: processor 1312 selects a link from one or more enabled links. Further, process 1400 may include: processor 1312 sends block acknowledgements with combined reception status to other MLDs on the selected link in response to receiving the BAR from the other MLDs. In some implementations, the selected link may be among one or more ongoing communication links protected by a current TXOP that includes a period reserved for transmissions between the MLD and other MLDs. Alternatively, the selected link may not be among the one or more ongoing communication links protected by the current TXOP.
In some implementations, in terms of communications, process 1400 may include: processor 1312 performs certain operations. For example, process 1400 may include: processor 1312 selects a link from one or more enabled links. Additionally, process 1400 may include: processor 1312 sends block acknowledgements with combined reception status to other MLDs on the selected link in response to receiving one or more data packets from the other MLDs. In this case, the selected link may be among the one or more ongoing communication links protected by the current TXOP.
In some implementations, in terms of communications, process 1400 may include: processor 1312 sends block acknowledgements with combined receipt status to other MLDs in response to receiving a BAR with deferred retransmission indication from the other MLDs. In some implementations, the block acknowledgement may be sent over an ongoing communication link protected by the current TXOP. Alternatively, the block acknowledgement may be sent on a link that is not protected by the current TXOP.
In some implementations, in terms of communications, process 1400 may include: the processor 1312 sends block acknowledgements with combined reception status to other MLDs in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate a recommended link for retransmission of the lost data packet, where the recommended link is an ongoing communication link protected by the current TXOP. Further, process 1400 may include: processor 1312 receives retransmission of lost data packets from other MLDs over the recommended link.
In some implementations, in communication, process 1400 may include: processor 1312 sends or receives block acknowledgements including SINR information on one or more corresponding links.
In some implementations, in terms of communications, process 1400 may include: the processor 1312 sends block acknowledgements with combined reception status to other MLDs in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate a recommended link for retransmission of the lost data packet, where the recommended link is not an ongoing communication link protected by the current TXOP. Further, process 1400 may include: the processor 1312 receives retransmission of lost data packets from other MLDs on the recommendation link after the other MLDs successfully gain access to the medium on the recommendation link.
In some implementations, in terms of communications, process 1400 may include: the processor 1312 sends block acknowledgements with combined reception status to other MLDs in response to receiving the BAR from the other MLDs. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP, and the block acknowledgement may indicate one or more recommended links for replicating retransmission of the lost data packet, wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP. Additionally, process 1400 may include: processor 1312 receives retransmissions of the replicated missing data packets from other MLDs over one or more recommended links.
In some implementations, in terms of communications, process 1400 may include: the processor 1312 transmits a block acknowledgement with a combined reception status to the other MLD in response to receiving the BAR from the other MLD. In some implementations, the block acknowledgement may be sent on a link protected by the current TXOP and the block acknowledgement may indicate one or more recommended links for copying retransmissions of lost data packets, wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP. Additionally, process 1400 may include: the processor 1312 receives retransmissions of replicated lost data packets from other MLDs on one or more recommended links after the other MLDs successfully acquired access to the medium on the one or more recommended links.
In some implementations, in communication, process 1400 may include: processor 1312 (as the initiator MLD) sends BAR to device 1320 (as the receiver MLD). In some implementations, the BAR may be sent on a link protected by the current TXOP and the BAR may indicate one or more recommended links for retransmission of the lost data packet, wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP. Further, process 1400 may include: processor 1312 receives block acknowledgements from the other MLDs with acknowledgements for one or more recommended links for retransmission of one or more lost data packets.
In some implementations, in communication, process 1400 may include: processor 1312 (as the initiator MLD) sends BAR to device 1320 (as the receiver MLD). In some implementations, the BAR may be sent on a link protected by the current TXOP and the BAR may indicate one or more recommended links for retransmission of lost data packets, wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP. Further, process 1400 may include: processor 1312 receives block acknowledgements from the other MLDs with acknowledgements for one or more recommended links for retransmission of one or more lost data packets.
Additional notes
The subject matter described herein sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely exemplary, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Thus, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermedial components. Likewise, any two components so associated can also be viewed as being "operably connected," or "operably coupled," to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable," to each other to achieve the desired functionality. Specific examples of operably couplable include, but are not limited to, components capable of physically mating and/or physically interacting and/or components capable of wirelessly interacting and/or components capable of logically interacting and/or logically interacting.
Furthermore, those of skill in the art may translate from the plural to the singular and/or from the singular to the plural as is appropriate to the context and/or application. For clarity, various singular/plural permutations may be explicitly set forth herein.
Furthermore, it will be understood by those within the art that, in general, terms such as used herein, and in particular, terms such as used in the appended claims (e.g., bodies of the appended claims) are generally intended as "open" terms (e.g., the term "comprising" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "comprising" should be interpreted as "including but not limited to," etc.). Those skilled in the art will also understand that if a specific number of a introduced claim is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such intent is present. For example, as an aid to understanding, the following appended claims may contain usage of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed to imply that the introduction of a claim recitation by the indefinite articles "a" or "an" limits any particular claim containing such introduced claim recitation to implementations containing only one such recitation, even when the same claim includes the introductory phrases "one or more" or "at least one" and indefinite articles such as "a" or "an" (e.g., "a" or "an" should be interpreted to mean "at least one" or "one or more"); the same holds true for the use of definite articles used to refer to the claims. In addition, even if a specific number of a introduced claim recitation is explicitly recited, those skilled in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation of "two recitations," without other modifiers, means at least two recitations, or two or more recitations). Moreover, in those instances where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand that such a convention would work (e.g., "a system having at least one of A, B and C" would include but not be limited to systems having a alone, B alone, C, A and B together alone, a and C together, B and C together, and/or A, B and C together, etc.). In those instances where a convention analogous to "at least one of A, B or C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand that such a convention is in the sense (e.g., "a system having at least one of A, B or C" would include but not be limited to systems having a alone a, B alone, C, A and B together, a and C together, B and C together, and/or A, B and C together, etc.). It will be further understood by those within the art that, in fact, any inflections and/or phrases presenting two or more alternative terms (whether in the specification, claims, or drawings) should be understood to contemplate the possibilities of including one of the terms, either of the terms, or both terms. For example, the phrase "a or B" should be understood to include the possibility of "a" or "B" or "a and B".
From the foregoing, it will be appreciated that various implementations of the invention have been described for purposes of illustration, and that various modifications may be made without deviating from the scope and spirit of the invention. Accordingly, the implementations described herein are not intended to be limiting, and the true scope and spirit is indicated by the following claims.

Claims (20)

1. A method, the method comprising:
establishing, by a processor of the multi-link device MLD, a Block acknowledgement (Block Ack) protocol or a protected Block acknowledgement (blocked Ack) protocol with one other MLD over one or more enabled links for dynamic link selection; and
communicating, by the processor, with the other MLD on at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
2. The method of claim 1, wherein the communicating comprises:
selecting a link from the one or more enabled links; and
transmitting a block acknowledgement with a combined reception status to the other MLD on the selected link in response to receiving a block acknowledgement request BAR from the other MLD,
wherein the selected link is among one or more ongoing communication links protected by a current transmission opportunity, TXOP, the current TXOP comprising a period reserved for transmissions between the MLD and the other MLD.
3. The method of claim 1, wherein the communicating comprises:
selecting a link from the one or more enabled links; and
transmitting a block acknowledgement with a combined reception status to the other MLD on the selected link in response to receiving a block acknowledgement request BAR from the other MLD,
wherein the selected link is not among the one or more ongoing communication links protected by the current transmission opportunity TXOP.
4. The method of claim 1, wherein the communicating comprises:
selecting a link from the one or more enabled links; and
transmitting a block acknowledgement with a combined reception status to the other MLD on the selected link in response to receiving one or more data packets from the other MLD,
wherein the selected link is among one or more ongoing communication links protected by the current transmission opportunity TXOP.
5. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR with a deferred retransmission indication from the other MLD,
Wherein the block acknowledgement is sent on an ongoing communication link protected by a current transmission opportunity TXOP.
6. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR with a deferred retransmission indication from the other MLD,
wherein the block acknowledgement is sent on a link not protected by the current transmission opportunity TXOP.
7. The method of claim 1, wherein the communicating comprises: a block acknowledgement including signal to interference and noise ratio, SINR, information is transmitted or received over one or more corresponding links.
8. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR from the other MLD,
wherein the block acknowledgement is sent on a link protected by the current transmission opportunity TXOP,
wherein the block acknowledgement indicates a recommended link for retransmission of lost data packets, an
Wherein the recommended link comprises an ongoing communication link protected by a current TXOP.
9. The method of claim 8, wherein the communicating further comprises:
retransmission of the lost data packet is received from the other MLD over the recommended link.
10. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR from the other MLD,
wherein the block acknowledgement is sent on a link protected by the current transmission opportunity TXOP,
wherein the block acknowledgement indicates a recommended link for retransmission of lost data packets, an
Wherein the recommended link is not an ongoing communication link protected by the current TXOP.
11. The method of claim 10, wherein the communicating further comprises:
after the other MLD successfully gains access to the medium on the recommended link, a retransmission of the lost data packet is received from the other MLD on the recommended link.
12. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR from the other MLD,
Wherein the block acknowledgement is sent on a link protected by the current transmission opportunity TXOP,
wherein the block acknowledgements indicate one or more recommended links for replicating retransmission of lost data packets, an
Wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP.
13. The method of claim 12, wherein the communicating further comprises:
retransmission of the replicated lost data packet is received from the other MLD over the one or more recommended links.
14. The method of claim 1, wherein the communicating comprises:
transmitting a block acknowledgement with a combined reception state to the other MLD in response to receiving a block acknowledgement request BAR from the other MLD,
wherein the block acknowledgement is sent on a link protected by the current transmission opportunity TXOP,
wherein the block acknowledgements indicate one or more recommended links for replicating retransmission of lost data packets, an
Wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP.
15. The method of claim 14, wherein the communicating further comprises:
After the other MLD successfully gains access to the medium on the one or more recommended links, a retransmission of the replicated lost data packet is received from the other MLD on the one or more recommended links.
16. The method of claim 1, wherein the communicating comprises:
a block acknowledgement request BAR is sent to the other MLD,
wherein the BAR is transmitted over a link protected by a current transmission opportunity TXOP,
wherein the BAR indicates one or more recommended links for retransmission of lost data packets, an
Wherein the one or more recommended links are among the ongoing communication links protected by the current TXOP.
17. The method of claim 16, wherein the communicating further comprises:
a block acknowledgement is received from the other MLD, the block acknowledgement having an acknowledgement of one or more recommended links for retransmission of one or more lost data packets.
18. The method of claim 1, wherein the communicating comprises:
a block acknowledgement request BAR is sent to the other MLD,
wherein the BAR is transmitted over a link protected by a current transmission opportunity TXOP,
Wherein the BAR indicates one or more recommended links for retransmission of lost data packets, an
Wherein the one or more recommended links are not among the ongoing communication links protected by the current TXOP.
19. The method of claim 18, wherein the communicating further comprises:
a block acknowledgement is received from the other MLD, the block acknowledgement having an acknowledgement of one or more recommended links for retransmission of one or more lost data packets.
20. An apparatus implementable in a multi-link device, MLD, the apparatus comprising:
a transceiver configured for wireless communication; and
a processor coupled to the transceiver and configured to perform operations via the transceiver, the operations comprising:
establishing, via the transceiver, a Block acknowledgement, ack, protocol or a protected Block acknowledgement protocol with one other MLD over one or more enabled links for dynamic link selection; and
communicate with the other MLD via the transceiver over at least one of the one or more enabled links prior to terminating the block acknowledgement protocol or the protected block acknowledgement protocol.
CN202310846466.2A 2022-07-11 2023-07-11 Dynamic link selection for reliable retransmission in wireless communications Pending CN117395813A (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US63/368,088 2022-07-11
US18/211,758 US20240014982A1 (en) 2022-07-11 2023-06-20 Dynamic Link Selection For Reliable Retransmission In Wireless Communications
US18/211,758 2023-06-20

Publications (1)

Publication Number Publication Date
CN117395813A true CN117395813A (en) 2024-01-12

Family

ID=89461942

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310846466.2A Pending CN117395813A (en) 2022-07-11 2023-07-11 Dynamic link selection for reliable retransmission in wireless communications

Country Status (1)

Country Link
CN (1) CN117395813A (en)

Similar Documents

Publication Publication Date Title
US20190014597A1 (en) Methods and systems for receiver initiated protection of a wireless communication exchange
US20160080115A1 (en) Methods for efficient acknowledgement in wireless systems
KR20220106739A (en) Data retransmission method and apparatus, data reception response method and apparatus, and storage medium
JP2009515401A (en) Multicast and / or broadcast acknowledgment mechanism
JP2014502453A (en) Method and apparatus for performing channel aggregation and medium access control retransmission
JP7383161B2 (en) Method and communication device for determining reception status of data frames
US10673574B2 (en) Methods and apparatuses for group transmissions
JP7176050B2 (en) Wireless communication method using TXOP and wireless communication terminal using the same
US20230139754A1 (en) Coding method and apparatus
CN113573359B (en) Multilink communication method and related device
WO2022006914A1 (en) Method for feeding back hybrid automatic repeat request acknowledgement (harq-ack) and terminal device
EP3790213B1 (en) Mac-based hybrid automatic repeat request (harq)
US11329698B2 (en) Electronic apparatus
CN116367359A (en) Method and device for determining physical direct-connection feedback channel resources
EP4307590A1 (en) Dynamic link selection for reliable retransmission in wireless communications
CN117395813A (en) Dynamic link selection for reliable retransmission in wireless communications
TW202131740A (en) Device and method for handling physical uplink control channel collision
US20240072924A1 (en) Frame forwarding for range extension in a wireless network
US11362771B2 (en) Base station and automatic retransmission scheduling method thereof
US11677507B2 (en) Faster retransmission in multi-link communication
CN110958682B (en) Method and device for point-to-point physical layer communication in ad hoc network, sending UE (user equipment) and receiving UE
US20240098786A1 (en) End-to-end acknowledgement in a wireless network
JP2022105211A (en) Transmission device, reception device, wireless communication system, and communication method
WO2020034133A1 (en) Communication method and apparatus
JP6048048B2 (en) Wireless communication apparatus, bandwidth request method, wireless communication system, and control method of wireless communication system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination