Multi-link protection for low latency communications

Abstract

A multi-link capable wireless device (multi-link device or 'MLD') may attempt to transmit low latency data on one link. The receiving device may discover that the link is occupied for it by another transmission. Methods, devices, and systems are provided. An exemplary method includes transmitting, by a first wireless device, a first request frame to a second wireless device via a first link, the first request frame requesting transmission of first data to the second wireless device via the first link, and based on the fact that the first wireless device does not receive a first response frame from the second wireless device within a time period from the transmission of the first request frame and the first data comprises low-latency traffic, a second request frame requesting transmission of the first data to the second wireless device via the second link is transmitted by the first wireless device to the second wireless device via the second link.

Description

Technical Field

[0001] This invention relates to wireless networks, particularly but not limited to local area wireless networks using technologies such as the IEEE 802.11 standard. Background Technology

[0002] Modern wireless networks are typically deployed densely. Devices face significant media access contention. This problem becomes even more severe when there is a need to allocate time for transmitting data ('urgent data' or so-called 'low-latency data'). Summary of the Invention

[0003] The inventors have recognized that several problems arise when using Multi-Link Operation (MLO). A wireless device with multi-link capability (a multi-link device or 'MLD') may attempt to transmit low-latency data on a single link. It begins by asking the intended receiving device (a second device) if it is possible. The second device may find that the link is occupied for it by another transmission (e.g., from another overlapping network, referred to as an Overlapping Basic Service Set or OBSS in the case of 802.11). In this case, the second device does not acknowledge the request from the first device, forcing the first device to wait and then retransmit its request, resulting in time loss. Alternatively, a device may transmit data (which may not be low-latency data) on multiple links, thus blocking another device (such as one in an OBSS) from transmitting data that might be low-latency data.

[0004] In attempts to improve wireless network functionality, methods, apparatus, systems, and computer program products as defined in the appended claims are provided.

[0005] In one aspect, a method is provided, comprising: a first request frame sent by a first wireless device to a second wireless device via a first link requesting the transmission of first data to the second wireless device via the first link; and a second request frame sent by the first wireless device to the second wireless device via a second link requesting the transmission of the first data to the second wireless device based on the first wireless device not receiving a first response frame from the second wireless device within a time period from the transmission of the first request frame and the first data comprising low-latency services.

[0006] In one aspect, a method is provided, comprising: a first request frame sent by a first wireless device to a second wireless device via a first link requesting the transmission of first data to the second wireless device via the first link; and a second request frame sent by the first wireless device to the second wireless device via a second link requesting the transmission of the first data to the second wireless device based on the first wireless device not receiving a first response frame from the second wireless device within a time period from the transmission of the first request frame and the first data comprising low-latency services.

[0007] In one embodiment, the method includes: receiving a second response frame from a second wireless device via a second link in response to a second request frame; and sending first data from the first wireless device to the second wireless device via the second link.

[0008] In one embodiment, the method includes: in response to a second request frame, receiving a second response frame from a second wireless device via a second link by a first wireless device.

[0009] In one embodiment, the method includes a first wireless device sending a third request frame to a second wireless device via a first link, requesting the transmission of first data to the second wireless device via the first link.

[0010] In one embodiment, the second request frame and the third request frame include MU-RTS trigger frames.

[0011] In one aspect, a method is provided, comprising: receiving, by a first wireless device, data for transmission to a second wireless device based on data including low-latency services; sending, by the first wireless device, a first multi-user request transmission (MU-RTS) trigger frame to the second wireless device via a first link, the first MU-RTS trigger frame requesting data transmission to the second wireless device via the first link; and sending, by the first wireless device, a second MU-RTS trigger frame to the second wireless device via a second link, the second MU-RTS trigger frame requesting data transmission to the second wireless device via the second link.

[0012] In one aspect, a method is provided, comprising: receiving a first multi-user request transmission (MU-RTS) trigger frame from a second wireless device via a first link, the first MU-RTS trigger frame requesting data to be transmitted to the first wireless device via the first link; receiving a second MU-RTS trigger frame from the second wireless device via a second link, the second MU-RTS trigger frame requesting data to be transmitted to the first wireless device via the second link; discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame including an indication of the first link; and sending a first response frame from the first wireless device to the second wireless device via the second link in response to the second MU-RTS trigger frame.

[0013] In one embodiment, the request frame is a Request to Send (RTS) frame, and the response frame is a Clear to Send (CTS) frame.

[0014] In one aspect, there is provided an apparatus arranged to perform operations when acting as a first wireless device (wireless device), the operations including: sending a first request frame via a first link to a second wireless device requesting the transmission of first data to the second wireless device via the first link; and sending a second request frame via a second link to the second wireless device requesting the transmission of the first data to the second wireless device based on the fact that no first response frame has been received from the second wireless device within a time period from the transmission of the first request frame and the first data includes low-latency services.

[0015] In one aspect, there is provided an apparatus configured to perform operations when acting as a first wireless device, the operations including: sending a first request frame via a first link to a second wireless device requesting the transmission of first data to the second wireless device via the first link; and sending a second request frame via a second link to the second wireless device requesting the transmission of the first data to the second wireless device based on the fact that no first response frame has been received from the second wireless device within a time period from the transmission of the first request frame and the first data includes low-latency services.

[0016] In one aspect, there is provided an apparatus that, when acting as a first wireless device, is arranged to perform operations including receiving data for transmission to a second wireless device; Based on the data including low-latency services, a first multi-user request transmission (MU-RTS) trigger frame is sent to the second wireless device via a first link. The first MU-RTS trigger frame requests the transmission of the data to the second wireless device via the first link. A second MU-RTS trigger frame is also sent to the second wireless device via a second link. The second MU-RTS trigger frame requests the transmission of the data to the second wireless device via the second link.

[0017] In one aspect, there is provided an apparatus arranged to perform the following operations when acting as a first wireless device: receiving a first multi-user request transmission (MU-RTS) trigger frame from a second wireless device via a first link, the first MU-RTS trigger frame requesting data transmission to the device via the first link; requesting to receive a second MU-RTS trigger frame from the second wireless device via a second link, the second MU-RTS trigger frame requesting data transmission to the device via the second link; discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame including an indication of the first link; and transmitting a first response frame to the second wireless device via the second link in response to the second MU-RTS trigger frame.

[0018] In one embodiment, the wireless device is a Station (STA) according to IEEE 802.11.

[0019] In one aspect, a wireless network is provided that includes multiple devices as described herein.

[0020] In one aspect, a computer program product is provided that is stored on a computer-readable medium and configured, when a computing device is operated, to perform the methods described herein. Unless otherwise stated, the term "station" as used herein should be understood to apply to any wireless device and is not limited to stations according to 802.11. Attached Figure Description

[0021] This document describes examples of several embodiments of various embodiments of the present disclosure with reference to the accompanying drawings.

[0022] Figure 1 An example wireless communication network in which embodiments of the present disclosure can be implemented is shown.

[0023] Figure 2 This is a block diagram showing an example implementation of a station (STA) and an access point (AP).

[0024] Figure 3 An example of the Media Access Control (MAC) frame format is shown.

[0025] Figure 4 An example of a Quality of Service (QoS) empty frame indicating buffer status information is shown.

[0026] Figure 5 An example format of the Physical Layer (PHY) Protocol Data Unit (PPDU) is shown.

[0027] Figure 6 Examples are shown, including buffer status reporting by the STA, uplink multi-user (MU) transmissions scheduled by the AP, and uplink transmissions scheduled by the STA.

[0028] Figure 7 An example reference model of a multi-link device (MLD) is shown.

[0029] Figure 8 Examples of AP MLDs and associated non-AP MLDs are shown.

[0030] Figure 9 An example of establishing a multi-link between an AP MLD and a non-AP MLD is shown.

[0031] Figure 10 An example of a service identifier (TID) to link mapping is shown in a multi-link communication environment.

[0032] Figure 11 An example of the Request to Send (RTS) / Clear to Send (CTS) process is shown.

[0033] Figure 12 An example of an existing process that can be used to send low-latency data protected by RTS / CTS switching is shown.

[0034] Figure 13 Another example of an existing process that can be used to send low-latency data protected by RTS / CTS switching is shown.

[0035] Figure 14 Another example of an existing process that can be used to send low-latency data protected by RTS / CTS switching is shown.

[0036] Figure 15 An example process according to one embodiment is shown.

[0037] Figure 16 An example of a proposed process, according to one embodiment, can be used to transmit low-latency data protected by RTS / CTS switching.

[0038] Figure 17 An example of a proposed process, according to an embodiment, can be used to transmit low-latency data protected by RTS / CTS switching.

[0039] Figure 18 An example of a proposed process, according to one embodiment, can be used to transmit low-latency data protected by RTS / CTS switching.

[0040] Figure 19 An example of a proposed process, according to one embodiment, can be used to transmit low-latency data protected by RTS / CTS switching.

[0041] Figure 20 An example of a proposed process, according to one embodiment, can be used to transmit low-latency data protected by RTS / CTS switching.

[0042] Figure 21 An example of a public information field for a basic multilink element according to one embodiment is shown.

[0043] Figure 22 An example multi-user request transmission (MU-RTS) trigger frame according to one embodiment is shown.

[0044] Figure 23 An example process according to one embodiment is shown.

[0045] Figure 24 Another example process according to one embodiment is shown.

[0046] Figure 25 Another example process according to one embodiment is shown. Detailed Implementation

[0047] In this disclosure and the accompanying drawings, the same reference numerals denote the same elements.

[0048] In this disclosure, various embodiments are presented as examples of how the disclosed techniques and / or how the disclosed techniques can be practiced in environments and scenarios. It will be apparent to those skilled in the art that various changes in form and detail can be made without departing from the scope. How alternative embodiments can be implemented will be apparent to those skilled in the art after reading the description. This embodiment is not limited to any of the exemplary embodiments described. Embodiments of this disclosure will be described with reference to the accompanying drawings. Limitations, features, and / or elements from the disclosed example embodiments can be combined to create further embodiments within the scope of this disclosure. Any drawings emphasizing features and advantages are presented for illustrative purposes only. The disclosed architecture is flexible and configurable enough that it can be utilized in ways other than those shown. For example, actions listed in any flowchart can be reordered or used only optionally in some embodiments.

[0049] The embodiments can be configured to operate as needed. The disclosed mechanisms can be executed when certain criteria are met, for example, in a station, access point, radio environment, network, or a combination thereof. Example standards may be based at least in part on, for example, wireless device or network node configuration, traffic load, initial system setup, packet size, service characteristics, or a combination thereof. Various example embodiments can be applied when one or more criteria are met. Therefore, example embodiments that selectively implement the disclosed protocols can be implemented.

[0050] In this disclosure, “a” and “an” and similar phrases should be interpreted as “at least one” and “one or more”. Similarly, any term ending with the suffix “(s)” should be interpreted as “at least one” and “one or more”. In this disclosure, the term “may” should be interpreted as “may, for example.” In other words, the term “may” indicates that the phrase following the term “may” is an example of one of a plurality of suitable possibilities that may or may not be employed by one or more of the various embodiments. As used herein, the terms “comprising” and “consisting of” enumerate one or more components of the described element. The term “comprising” is interchangeable with “including” and does not exclude the inclusion of unenumerated components in the described element. In contrast, “consisting of” provides a complete enumeration of one or more components of the described element. The term “based on” as used herein can be interpreted as “at least partially based on” rather than, for example, “based on only.” The term “and / or” as used herein indicates any possible combination of the enumerated elements. For example, “A, B and / or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C.

[0051] If A and B are sets and every element of A is an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1, STA2} are: {STA1}, {STA2}, and {STA1, STA2}. The phrase “based on” (or equivalently “at least based on”) indicates that the phrase following the term “based on” is an example of one of a plurality of suitable possibilities that may or may not be used in one or more of the various embodiments. The phrase “in response to” (or equivalently “at least in response to”) indicates that the phrase following the phrase “in response to” is an example of one of a plurality of suitable possibilities that may or may not be used in one or more of the various embodiments. The phrase “depends on” (or equivalently “at least depends on”) indicates that the phrase following the phrase “depends on” is an example of one of a plurality of suitable possibilities that may or may not be used in one or more of the various embodiments. The phrase “adopt / use” (or equivalently “at least adopt / use”) indicates that the phrase following the phrase “adopt / use” is an example of one of a plurality of suitable possibilities that may or may not be used in one or more of the various embodiments.

[0052] The term "configuration" can refer to the ability of a device to be in an operational or non-operational state. Configuration can refer to specific settings within a device that affect its operational characteristics, regardless of whether the device is in an operational or non-operational state. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within the device, whether it is in an operational or non-operational state, to provide specific characteristics to the device. Terms such as "control messages induced in the device" can mean that control messages have parameters that can be used to configure specific characteristics, or can be used to implement certain actions within the device, regardless of whether the device is in an operational or non-operational state.

[0053] In this disclosure, a parameter (or equivalently referred to as a field or information element: IE) may include one or more information objects, and an information object may include one or more other objects. For example, if parameter (IE)N includes parameter (IE)M, and parameter (IE)M includes parameter (IE)K, and parameter (IE)K includes parameter (information element)J, then, for example, N includes K, and N includes J. In the example embodiment, when one or more messages / frames include multiple parameters, this means that a parameter among the multiple parameters is in at least one of the one or more messages / frames, but not necessarily in every one of the one or more messages / frames.

[0054] Many of the features presented are described as optional using the word "may" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly describe each and every permutation that can be obtained by selecting from the set of optional features. This disclosure should be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional features can be embodied in seven ways: having only one of the three possible features, having any two of the three possible features, or having three of the three possible features.

[0055] Many of the elements described in the disclosed embodiments can be implemented as modules. A module is defined herein as an element that performs a defined function and has an interface to a definition of other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wet hardware (e.g., hardware with biological elements), or combinations thereof, and may be behaviorally equivalent. For example, a module can be implemented as a software routine written in a computer language configured to be executed by a hardware machine (such as C, C++, Fortran, Java, Basic, Matlab, etc.) or a modeling / simulation program (such as Simulink, Stateflow, GNU Octave, or LabVEWMathScript). Modules can be implemented using physical hardware that includes discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include: computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs); field-programmable gate arrays (FPGAs); and complex programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are typically programmed using hardware description languages ​​(HDLs) such as VHSIC Hardware Description Language (VHDL) or Verilog, which configure the connections between a limited number of internal hardware modules on the programmable device. The techniques mentioned are often used in combination to achieve the result of functional modules.

[0056] Figure 1 An example wireless communication network in which embodiments of the present disclosure can be implemented is shown.

[0057] like Figure 1 As shown, an example wireless communication network may include an IEEE 802.11 (WLAN) infrastructure network 102. WLAN infrastructure network 102 may include one or more Basic Service Sets (BSS) 110 and 120 and a Distribution System (DS) 130.

[0058] BSS 110-1 and 110-2 each include a set of access points (APs or AP STAs) and at least one station (STA or non-AP STA). For example, BSS 110-1 includes AP 104-1 and STA 106-1, and BSS 110-2 includes AP 104-2 and STAs 106-2 and 106-3. The APs and at least one STA in the BSS perform an association process to communicate with each other. The DS 130 can be configured to connect BSS 110-1 and BSS 110-2. Therefore, the DS 130 can enable Extended Service Set (ESS) 150. Within the ESS 150, APs 104-1 and 104-2 are connected via the DS 130 and can have the same Service Set Identifier (SSID).

[0059] The WLAN infrastructure network 102 can be coupled to one or more external networks. For example, such as Figure 1 As shown, WLAN infrastructure network 102 can be connected to another network 108 (e.g., 802.X) via portal 140. Port 140 can be used as a bridge to connect DS 130 of WLAN infrastructure network 102 to another network 108.

[0060] Figure 1 The example wireless communication network shown may further include one or more self-organizing networks or independent BSSs (IBSSs). A self-organizing network or IBSS is a network of multiple STAs included within each other's communication range. The multiple STAs are configured such that they can communicate with each other using direct peer-to-peer communication (i.e., not via an AP).

[0061] For example, in Figure 1 In this configuration, STAs 106-4, 106-5, and 106-6 can be configured to form a first IBSS 112-1. Similarly, STAs 106-7 and 106-8 can be configured to form a second IBSS 112-2. Since an IBSS does not include an AP, it does not include a centralized management entity. Instead, STAs within the IBSS are managed in a distributed manner. STAs forming an IBSS can be fixed or mobile.

[0062] A STA, serving as a predefined functional medium, may include a Media Access Control (MAC) layer conforming to the IEEE 802.11 standard. A physical layer interface for the radio medium can be used between APs and non-AP stations (STAs). STAs may also be referred to using various other terms, including mobile terminal, radio device, radio transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" may be used to refer to a STA participating in uplink multi-user multiple-input multiple-output (MU MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmissions.

[0063] A Physical Layer (PHY) Protocol Data Unit (PPDU) can be a composite structure including a PHY preamble and a PLCP Service Data Unit (PSDU) payload. For example, a PSDU may include a PHY Convergence Protocol (PLCP) preamble and header and / or one or more MAC Protocol Data Units (MPDUs). The information provided in the PHY preamble can be used by the receiving device to decode subsequent data in the PSDU. When transmitting a PPDU via a bonded channel (a channel formed by channel bonding), the preamble field can be copied and transmitted in each of the multiple component channels. The PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble can be used for packet detection, automatic gain control, and channel estimation, among other purposes. The legacy preamble is also typically used to maintain compatibility with legacy equipment. The format, encoding, and information provided in the non-legacy portion of the preamble are based on the specific IEEE 802.11 protocol to be used for transmitting the payload.

[0064] A frequency band can include one or more sub-bands or frequency channels. For example, PPDUs conforming to revisions of the IEEE 802.11n, 802.11ac, 802.11ax, and / or 802.11be standards can be transmitted in the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which can be divided into multiple 20 MHz channels. PPDUs can be transmitted on physical channels with a minimum bandwidth of 20 MHz. Larger channels can be formed through channel bonding. For example, PPDUs can be transmitted on physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding multiple 20 MHz channels together.

[0065] Figure 2 This is a block diagram illustrating example implementations of the STA 210 and AP 260. (As shown...) Figure 2 As shown, STA 210 may include at least one processor 220, memory 230, and at least one transceiver 240. AP 260 may include at least one processor 270, memory 280, and at least one transceiver 290. Processors 220 / 270 may be operatively connected to memory 230 / 280 and / or transceiver 240 / 290.

[0066] Processors 220 / 270 can implement the functions of the PHY layer, MAC layer, and / or logical link control (LLC) layer of the corresponding device (STA 210 or AP 260). Processors 220 / 270 may include one or more processors and / or one or more controllers. For example, one or more processors and / or one or more controllers may include, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), logic circuits, or a chipset.

[0067] Memory 230 / 280 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage units. Memory 230 / 280 may include one or more non-transitory computer-readable media. Memory 230 / 280 may store computer program instructions or code that can be executed by processor 220 / 270 to perform one or more operations / embodiments discussed in this application. Memory 230 / 280 may be implemented (or located) within or outside of processor 220 / 270. Memory 230 / 280 may be operatively connected to processor 220 / 270 via various means known in the art.

[0068] Transceiver 240 / 290 can be configured to transmit / receive radio signals. In one embodiment, transceiver 240 / 290 can implement the PHY layer of a corresponding device (STA 210 or AP 260). In one embodiment, STA 210 and / or AP 260 can be multi-link devices (MLDs), which are devices capable of operating on multiple links defined by the IEEE 802.11 standard. Thus, STA 210 and / or AP 260 can each implement multiple PHY layers. Multiple PHY layers can be implemented using one or more of transceivers 240 / 290.

[0069] Figure 3 An example format of a MAC frame is shown. In operation, the STA can construct a subset of MAC frames for transmission and can decode a subset of received MAC frames during verification. The specific subset of frames that the STA can construct and / or decode can be determined by the functions supported by the STA. The STA can use the Frame Check Sequence (FCS) contained in the frame to verify the received MAC frames and can interpret certain fields from the MAC header of all frames.

[0070] like Figure 3 As shown, a MAC frame includes a MAC header, a variable-length frame body, and a frame check sequence (FCS).

[0071] The MAC header includes a frame control field, an optional duration / ID field, an address field, an optional sequence control field, an optional QoS control field, and an optional HT control field.

[0072] The frame control field includes the following subfields: protocol version, type, subtype, "to DS", "from DS", "more fragments", retry, power management, "more data", protected frames, and +HTC.

[0073] The protocol version subfield remains unchanged in size and placement across all revisions of the IEEE 802.11 standard. For MAC frames, the value of the protocol version subfield is 0.

[0074] The type and subtype subfields together identify the function of a MAC frame. There are three frame types: control, data, and management. Each frame type has several defined subtypes. Bits within the subtype subfield are used to indicate specific modifications to the underlying data frame (subtype 0). For example, in a data frame, the most significant bit (MSB) of the subtype subfield (bit 7 (B7) of the frame control field) is defined as the QoS subfield. When the QoS subfield is set to 1, it indicates a QoS data frame, which is a data frame that includes a QoS control field in its MAC header. The second MSB of the subtype field (bit 6 (B6) of the frame control field when set to 1 in the data subtype) indicates a data frame that does not include a frame body field.

[0075] The “To DS” subfield indicates whether the data frame is destined for the distribution system (DS). The “From DS” subfield indicates whether the data frame originated from the DS.

[0076] The "More Fragments" subfield is set to 1 in all data or management frames that have another fragment, in accordance with the MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) carried by the MAC frame. The "More Fragments" subfield is set to 0 in all other frames where the "More Fragments" subfield is present.

[0077] In any data or management frame that is a retransmission of an earlier frame, the retry subfield is set to 1. It is set to 0 in all other frames where the retry subfield exists. The receiving STA uses this indication to aid in the process of eliminating duplicate frames. These rules do not apply to frames transmitted by the STA under the block protocol.

[0078] The power management subfield is used to indicate the power management mode of the STA.

[0079] The “More Data” subfield instructs a STA in Power Saving (PS) mode to buffer a bufferable unit (BU) at the AP. The “More Data” subfield is valid in separately addressed data or management frames sent by the AP to the STA in PS mode. The “More Data” subfield is set to 1 to indicate that the STA has at least one additional buffered BU.

[0080] If the frame body field contains information that has already been processed by the cryptographic encapsulation algorithm, then the protected frame subfield is set to 1.

[0081] The +HTC subfield indicates that the MAC frame contains the HT control field.

[0082] The Duration / ID field in the MAC header indicates various information depending on the frame type and subtype, as well as the QoS capabilities of the sending STA. For example, in a control frame of the Power Saving Polling (PS-Poll) subtype, the Duration / ID field carries the Association Identifier (AID) of the STA sending the frame in 14 least significant bits (LSBs), with the two most significant bits (MSBs) set to 1. In other frames sent by the STA, the Duration / ID field contains a duration value (in microseconds) used by the receiver to update the Network Allocation Vector (NAV). The NAV is a counter indicating to the STA the amount of time it must postpone access to the shared medium.

[0083] A MAC frame format can contain up to four address fields. These address fields indicate the Basic Service Set Identifier (BSSID), source address (SA), destination address (DA), sending address (TA), and receiving address (RA). Some frames may not contain certain address fields. The use of certain address fields can be specified by the relative positions of address fields (1-4) within the MAC header, regardless of the type of address present in that field. Specifically, address 1 always identifies the intended receiver of the frame, and address 2, if present, always identifies the transmitter of the frame.

[0084] The sequence control field includes two subfields: a sequence number subfield and a fragment number subfield. In a data frame, the sequence number subfield indicates the sequence number of the MSDU (if not in an aggregated MSDU (A-MSDU)) or the A-MSDU. In a management frame, the sequence number subfield indicates the sequence number of the frame. The fragment number is set to 0 in the first or only fragment of an MSDU or MMPDU, and increments by 1 for each subsequent fragment of that MSDU or MMPDU. In a MAC Protocol Data Unit (MPDU) containing an A-MSDU, or in an MPDU containing an unsegmented MSDU or MMPDU, the fragment number is set to 0. The fragment number remains constant throughout all retransmissions of the fragment.

[0085] The QoS control field identifies the service category (TC) or service flow (TS) to which the MAC frame belongs. The QoS control field can also indicate various other QoS-related, A-MSDU-related, and mesh-related information about the frame. This information can vary depending on the frame type, frame subtype, and the type of STA transmitting the frame. The QoS control field exists in all data frames where the QoS subfield of the subtype subfield is equal to 1.

[0086] The HT control field exists in QoS data, QoS empty frames, and management frames, which are determined by the +HTC subfield of the frame control field.

[0087] The frame body field is a variable-length field that contains information specific to the individual frame type and subtype. The frame body may include one or more MSDUs or MMPDUs. The minimum length of the frame body is 0 octets.

[0088] The FCS field contains a 32-bit Cyclic Redundancy Check (CRC) code. The FCS field value is calculated over all fields in the MAC header and frame body.

[0089] Figure 4 An example of a QoS empty frame indicating buffer status information is shown. A QoS empty frame is a QoS data frame with an empty frame body. A QoS empty frame includes a QoS control field and an optional HT control field, which may contain a Buffer Status Report (BSR) control subfield. QoS empty frames indicating buffer status information can be sent from the STA to the AP.

[0090] QoS control fields may include a service identifier (TID) subfield, an ack policy indicator subfield, and a queue size subfield (or a transmission opportunity (TXOP) duration request subfield).

[0091] The TID subfield identifies the TC or TS requesting a TXOP by setting the requested TXOP duration or queue size subfield. The encoding of the TID subfield depends on the access policy (e.g., allowed values ​​of 0 to 7 for Enhanced Distributed Channel Access (EDCA) access policies to identify the user priority of the TC or TS).

[0092] The ack policy indicator subfield, along with other information, identifies the acknowledgment policy, followed by the delivery of the MPDU (e.g., normal ack, implicit block ack request, no ack, block ack, etc.). The queue size subfield is an 8-bit field that indicates the amount of buffered traffic at the STA for a given TC or TS to be transmitted to the AP identified by the receiver address of the frame containing the subfield. The queue size subfield is present in QoS empty frames transmitted by the STA when bit 4 of the QoS control field is set to 1. The AP can use the information contained in the queue size subfield to determine the duration of the t TXOP allocated to the STA or to determine the uplink (UL) resources allocated to the STA.

[0093] In frames transmitted by or sent to a non-HE STA, the following rules may be applied to queue size values: The queue size value is the approximate total size of all MSDUs and A-MSDUs buffered at the STA in the delivery queue for MSDUs and A-MSDUs (excluding MSDUs or A-MSDUs contained in the current QoS data frame), rounded to the nearest multiple of 256 octets and expressed in units of 256 octets. The TID value is equal to the value indicated in the TID subfield of the QoS control field.

[0094] A queue size value of 0 is only used to indicate that there are no buffered transactions in the queue used for the specified TID.

[0095] The queue size value of 254 is used for all sizes greater than 64,768 octets.

[0096] The queue size value of 255 is used to indicate an unspecified or unknown size.

[0097] In frames sent from HE STA to HE AP, the following rules can be applied to queue size values.

[0098] The queue size value QS is the approximate total size in octet of all MSDUs and A-MSDUs buffered at the STA in the delivery queue for MSDUs and A-MSDUs (including MSDUs or A-MSDUs contained in the same PSDU as the frame containing the queue size subfield), where the TID value is equal to the value indicated in the TID subfield of the QoS control field.

[0099] The queue size subfield includes the scaling factor subfield in bits B14-B15 of the QoS control field and the unscaled value UV in bits B8-B13 of the QoS control field. The scaling factor subfield provides the scaling factor SF.

[0100] The STA obtains the queue size QS from the received QoS control field, which contains the scaling factor SF and the unscaled value UV, as shown below: QS= 16×UV, if SF equals 0; 1024 + 256 × UV, if SF equals 1; 17 408 + 2048 × UV, if SF equals 2; 148 480+32 768×UV, if SF equals 3 and UV is less than 62; >2 147 328, if SF equals 3 and UV equals 62; Unspecified or unknown if SF equals 3 and UV equals 63.

[0101] The TXOP Duration Request subfield, which can be included instead of the Queue Size subfield, indicates to the sending STA that it needs the duration (in 32 microseconds (µs) for its next TXOP for the specified TID. The TXOP Duration Request subfield is set to 0 to indicate that no TXOP is requested for the specified TID in the current Service Hour (SP). The TXOP Duration Request subfield is set to a non-zero value to indicate the requested TXOP duration in 32-µs increments within the range of 32µs to 8160µs.

[0102] The HT control field may include a BSR control subfield, which may contain buffer status information for UL MU operation. The BSR control subfield may be formed by the Access Class Index (ACI) bitmap subfield, incremental TID subfield, ACI high subfield, scaling factor subfield, queue size high subfield, and queue size full subfield of the HT control field.

[0103] The ACI bitmap subfield indicates the access category (AC) for reporting buffer states (e.g., B0: Best Effort (AC_BE), B1: Background (AC_BK), B2: Video (AC_VI), B3: Voice (AC_VO), etc.). Each bit of the ACI bitmap subfield is set to 1 to indicate that the buffer state corresponding to the AC is included in the queue size of all subfields; otherwise, it is set to 0, unless the ACI bitmap subfield is 0 and the incremental TID subfield is 3, in which case the buffer states of all 8 TIDs are included. The incremental TID subfield, together with the value of the ACI bitmap subfield, indicates the number of TIDs that the STA is reporting the buffer state for.

[0104] The ACI high subfield indicates the ACI of the AC of the BSR in the queue size high subfield. The ACI to AC mapping is defined as ACI value 0 mapped to AC_BE, ACI value 1 mapped to AC_BK, ACI value 2 mapped to AC_VI, and ACI value 3 mapped to AC_VO.

[0105] The scaling factor subfield indicates the unit SF (in octets) for both the queue size high subfield and the queue size full subfield.

[0106] The queue size high subfield indicates the amount of buffered traffic in SF octets for the AC identified by the ACI high subfield, which is intended for the STA identified by the receiver address of the frame containing the BSR control subfield.

[0107] The queue size full subfield indicates the amount of buffered traffic in SF octets for all ACs identified by the ACI bitmap subfield, which is intended for STAs identified by the receiver address of the frame containing the BSR control subfield.

[0108] The queue size values ​​in the queue size high subfield and queue size full subfield are the total size of all MSDUs and A-MSDUs buffered at the STA (including MSDUs or A-MSDUs contained in the same PSDU as the frame containing the BSR control subfield) in the delivery queues used for the MSDUs and A-MSDUs associated with the ACs specified in the ACI high and ACI bitmap subfields, respectively, rounded to the nearest multiple of the SF octet.

[0109] A queue size value of 254 in both the queue size high subfield and the queue size full subfield indicates that the buffered traffic volume is greater than 254 × SF octets. A queue size value of 255 in both the queue size high subfield and the queue size full subfield indicates that the buffered traffic volume is unspecified or unknown. Even if the amount of queued traffic changes with the transmission of consecutive segments, the queue size value of the QoS data frame containing the segments can remain unchanged.

[0110] The MAC service provides the ability to exchange MSDUs with peer entities. To support this service, the local MAC uses an underlying PHY-level service to transfer MSDUs to the peer MAC entity. This asynchronous MSDU transfer is performed on a connectionless basis.

[0111] Figure 5 An exemplary format of a PPDU is shown. As illustrated, a PPDU may include a PHY preamble, a PHY header, a PSDU, and a tail and padding bits.

[0112] A PSDU may include one or more MPDUs, such as a QoS data frame, an M MPDU, a MAC control frame, or a QoS empty frame. When an MPDU carries a QoS data frame, the frame body of the MPDU may include an MSDU or an A-MSDU.

[0113] By default, MSDU transmission is best-effort. That is, there is no guarantee that the sent MSDU will be successfully delivered. However, QoS facilities use Service Identifiers (TIDs) to specify differentiated services based on each MSDU.

[0114] The STA can differentiate MSDU delivery based on the specified service category (TC) or service flow (TS) of an individual MSDU. The MAC sublayer entity determines the user priority (UP) of the MSDU based on the TID value provided with the MSDU. The QoS facility supports eight UP values. The UP values ​​range from 0 to 7 and form an ordered sequence of priorities, where 1 is the lowest value, 7 is the highest value, and 0 falls between 2 and 3.

[0115] MSDUs with a specific UP are referred to as belonging to the service category with that UP. Each MSDU can be provided to the UP directly in the UP parameters at the Media Access Control Service Access Point (MAC SAP). A-MPDUs can include MPDUs with different TID values.

[0116] The STA can deliver Buffer Status Reports (BSRs) to assist the AP in allocating UL MU resources. The STA can implicitly deliver the BSR in the QoS control field or BSR control subfield of any frame sent to the AP (unrequested BSR), or explicitly deliver the BSR in a frame sent to the AP in response to a BSRP trigger frame (requested BSR).

[0117] The buffer status reported in the QoS control field includes the queue size value for a given TID. The buffer status reported in the BSR control field includes the ACI bitmap, incremental TID, high-priority AC, and two queue sizes.

[0118] The STA can report the buffer status of the QoS empty frames and QoS data frames sent to the AP in the QoS control field, and report the buffer status of the QoS empty frames, QoS data frames and management frames sent in the BSR control subfield (if present), as described below.

[0119] The STA can report the queue size for a given TID in the queue size subfield of the QoS control field of the transmitted QoS data frame or QoS empty frame; the STA can set the queue size subfield to 255 to indicate an unknown / unspecified queue size for that TID. The STA can aggregate multiple QoS data frames or QoS empty frames in the A-MPDU to report the queue size for different TIDs.

[0120] If the AP has indicated its support for the receive BSR control subfield, the STA can report the buffer status in the BSR control subfield of the transmitted frame.

[0121] The High Efficiency (HE) STA can report the queue size of the preferred AC, indicated by the ACI high subfield, in the queue size high subfield of the BSR control subfield. The STA can set the queue size high subfield to 255 to indicate an unknown / unspecified queue size for that AC.

[0122] The HE STA can report the queue size of an AC, indicated by the ACI bitmap subfield in the queue size full subfield of the BSR control subfield. The STA can set the queue size full subfield to 255 to indicate an unknown / unspecified BSR for those ACs.

[0123] Figure 6 Examples are shown, including buffer status reporting by the STA, uplink multi-user (MU) transmissions scheduled by the AP, and uplink transmissions scheduled by the STA.

[0124] As shown in the figure, the AP can request buffer status from one or more associated STAs (STA 1 and STA 2) by sending a Buffer Status Report Polling (BSRP) trigger frame. Upon receiving a BSRP trigger frame, if the BSRP trigger frame contains 12 LSBs of the STA's AID in the User Information field, then STA 1 and / or STA 2 can each generate a trigger-based (TB) PPDU.

[0125] STA 1 and / or STA 2 may each include one or more QoS empty frames in the TB PPDU. The one or more QoS empty frames may contain one or more QoS control fields or one or more BSR control subfields.

[0126] As mentioned earlier, the QoS control field may include a queue size subfield for a TID, for which the STA has the queue size to report to the AP. For example, as Figure 6 As shown, STA 1 can respond to a BSRP trigger frame from the AP by sending an A-MPDU that includes multiple QoS empty frames. Each QoS empty frame indicates the queue size for the corresponding TID (e.g., TID 0 and TID 2) in its respective QoS control field. Similarly, STA 2 can respond to a BSRP trigger frame by sending an MPDU that includes a QoS empty frame indicating the queue size for TID 2 in its QoS control field.

[0127] The BSR control subfield may include the queue size full subfield, which indicates the queue size of the AC as indicated by the ACI bitmap subfield. If the AP has indicated its support for receiving the BSR control subfield, the STA has the queue size to report to the AP. The STA sets the incremental TID, scaling factor, ACI high, and queue size high subfields of the BSR control subfield.

[0128] Upon receiving a BSR from STA 1 and STA 2, the AP can send a basic trigger frame to allocate UL MU resources to STA 1 and STA 2. In response, STA 1 can send a TB PPDU containing QoS data frames with TID 0 and TID 2, and STA 2 can send a TB PPDU containing one or more QoS data frames with TID 0. The AP can acknowledge the TB PPDUs sent from STA 1 and STA 2 by sending a multi-STA block ack frame.

[0129] Figure 7 An example reference model of a multi-link device (MLD) is shown.

[0130] An MLD is an entity capable of managing communication across multiple links. An MLD can be a logical entity and can have more than one affiliated station (STA). An MLD can be an Access Point MLD (AP MLD), where the STAs affiliated with the MLD are AP STAs (or APs). An MLD can also be a Non-Access Point MLD (Non-AP MLD), where the STAs affiliated with the MLD are non-AP STAs (or STAs).

[0131] Depending on the ability to transmit both AP MLD and non-AP MLD, communication across different frequency bands / channels may or may not occur simultaneously.

[0132] like Figure 7 As shown, an MLD can have a single MAC service access point (MAC-SAP) to the LLC layer, which includes MAC data services. An MLD can support multiple MAC sub-layers coordinated by a Sub-Layer Management Entity (SME). Each AP STA (or non-AP MLD) attached to an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0133] The SME is responsible for coordinating the MAC sublayer management entity (MLME) of the MLD under the STA to maintain a single Robust Secure Network Association (RSNA) key management entity and a single IEEE 802.1X authenticator or applicant for Multi-Link Operation (MLO).

[0134] The Multi-Link Operation (MLO) process allows a pair of MLDs to discover, synchronize, (de-)authenticate, (re)associate, disassociate, and manage resources on any common frequency band or channel supported by both MLDs. The authenticator and MAC-SAP of an AP MLD can be identified using the same AP MLD MAC address. The requester and MAC-SAP of a non-AP MLD can be identified using the same non-AP MLD MAC address.

[0135] Figure 8 Examples of AP MLDs and associated non-AP MLDs are shown.

[0136] As shown in the figure, the AP MLD has two affiliated APs (AP1 and AP2), and the non-AP MLD has two affiliated STAs (STA1 and STA2). The AP MLD and the non-AP MLD can be communicatively coupled through two links (link 1 and link 2), with link 1 established between AP1 and STA1, and link 2 established between AP2 and STA2.

[0137] Typically, the MAC addresses of the MLD and its associated STAs are different from each other. For example, such as Figure 8 As shown, AP MLD can have MAC address M, AP 1 can have MAC address w, and AP2 can have MAC address x. Similarly, non-AP MLD can have MAC address P, STA 1 can have MAC address y, and STA2 can have MAC address z.

[0138] like Figure 8 As shown, for each MLD, the MAC sublayer can be further divided into the upper MLD MAC sublayer and the lower MLD MAC sublayer. The upper MLD MAC sublayer performs functions common across all links. The lower MLD MAC sublayer performs functions local to each link. Some functions require joint processing from both the upper and lower MLD MAC sublayers.

[0139] The upper MAC sublayer of the MLD may include the following functions: Authentication, association, and re-association (between AP MLD and non-AP MLD); Security associations (e.g., Paired Master Key Security Association (PMKSA), Paired Transient Key Security Association (PTKSA)) and distribution of group ephemeral keys (GTK) / integrity GTK (IGTK) / beacon IGTK (BIGTK); Assignment of sequence number (SN) / block number (PN) for frames to be encrypted by the pairwise transient key (PTK) used for unicast frames; Use PTK for unicast frame encryption / decryption; Select the lower MAC sublayer of MLD for transmission (TID to link mapping). Reordering of groups ensures ordered delivery of each block of the Ack session; A block Ack scoreboard for individually addressed frames (in cooperation with the lower MLD MAC sublayer); optionally, the upper MLD MAC sublayer delivers block Ack records to the lower MLD MAC sublayer on other links on one link; and MLD-level management information exchange / instruction via the lower MAC sublayer of MLD The lower MAC sublayer functionality of the MLD may include: Maintain link-specific GTK / IGTK / B IGTK (between APs attached to AP MLDs and STAs attached to non-AP MLDs). Link-specific encryption / decryption / integrity protection and PN allocation using GTK / IGTK / BIGTK (between APs attached to APMLDs and STAs attached to non-AP MLDs). Link-specific management information exchange / instructions (e.g., beacons); Link-specific control information exchange / instruction (e.g., RTS / CTS, acknowledgments, etc.); Power saving status and mode; MAC address filtering for frame reception; and A block Ack scoreboard for individually addressed frames (in cooperation with the upper MAC sublayer of MLD); optionally, the lower MAC sublayer of MLD receives block Ack records on other links from the upper MAC sublayer of MLD.

[0140] Multilink (re)establishment between a non-AP MLD and an AP MLD may include the exchange of (re)association request / response frames. The exchange of (re)association request / response frames for multilink establishment may include two frames carrying basic multilink elements.

[0141] In the (re)association request frame, the non-AP MLD indicates the link requested for (re)re-establishment, along with the capabilities and operating parameters of the requested link. A non-AP MLD can request (re)re-establishment of links with a subset of APs attached to an AP MLD. The link requested for (re)re-establishment, along with the capabilities and operating parameters of the requested link, is independent of existing established links with the associated AP MLD, and the capabilities and operating parameters of those established links.

[0142] In the (re)association response frame, the AP MLD can indicate the accepted and rejected requested links for (re)establishment, as well as the capabilities and operating parameters of the requested links. The AP MLD can accept a subset of the links requested for (re)establishment. The (re)association response frame is sent to the non-AP STA attached to the non-AP MLD that sent the (re)association request frame.

[0143] The MLD requesting or accepting multi-link (re)establishment of any two links ensures that each link is located on a different non-overlapping channel. After a successful multi-link (re)establishment between a non-AP MLD and an AP MLD, the non-AP MLD and AP MLD establish a link for multi-link operation, and the non-AP MLD is (re)associated with the AP MLD. For each established link, the corresponding non-AP STA attached to the non-AP MLD is in the same association state as the non-AP MLD and is associated with the corresponding AP attached to the AP MLD. For each established link, functionality between the non-AP STA and its associated AP is enabled unless the functionality has been extended to the MLD level or otherwise specified.

[0144] Figure 9 An example of multi-link establishment between an AP MLD and a non-AP MLD is shown. As illustrated, the AP MLD has three affiliated APs: AP 1 operating in the 2.4 GHz band, AP 2 operating in the 5 GHz band, and AP 3 operating in the 6 GHz band. The non-AP MLD has three affiliated STAs: non-AP STA 1 operating in the 2.4 GHz band, non-AP STA 2 operating in the 5 GHz band, and non-AP STA 3 operating in the 6 GHz band.

[0145] A non-AP MLD can initiate multi-link establishment by sending an association request frame from non-AP STA 1 to AP 1, which is attached to the AP MLD. In the association request frame, the transmitter address (TA) field is set to the MAC address of non-AP STA 1, and the receiver address (RA) field is set to the MAC address of AP 1. The association request frame includes basic multi-link elements indicating the MLD MAC address of the non-AP MLD and complete information about non-AP STA 1, non-AP STA 2, and non-AP STA 3. The association request frame can request the establishment of three links between the non-AP MLD and the AP MLD (a link between AP 1 and non-AP STA 1, a link between AP 2 and non-AP STA 2, and a link between AP 3 and non-AP STA 3).

[0146] AP MLD can respond to a requested multilink setup by sending an association response frame to a non-AP STA 1 attached to a non-AP MLD. In the association response frame, the TA field is set to the MAC address of AP 1, and the RA field is set to the MAC address of non-AP STA 1. The association response frame includes basic multilink elements indicating the MLD's MLD MAC address and complete information about AP 1, AP 2, and AP 3. The association response frame signals successful multilink establishment by establishing three links between the non-AP MLD and AP MLD: link 1 between AP1 and non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP STA 3.

[0147] By default, all TIDs at non-AP MLDs are mapped to all established links on both the uplink and downlink. The TID-to-link mapping mechanism allows AP MLDs and non-AP MLDs performing or in the process of multi-link establishment to specify how UL and DL QoS services corresponding to different TIDs (e.g., between 0 and 7) can be allocated to the established links. In negotiated TID-to-link mapping, TIDs can be mapped to a set of links, which is a subset of all established links from a single established link.

[0148] If at least one TID is mapped to the link in either the DL or UL, the link establishment is defined as enabled for non-APMLDs, and if no TID is mapped to the link in either the DL or UL, the link establishment is defined as disabled. At any given time, a TID is always mapped to at least one established link in either the DL or UL, meaning that a TID-to-link mapping change is only valid and successful if it does not generate a set of TIDs with a mapping consisting of zero established links.

[0149] By default, all configured links are enabled. If a link is enabled for a non-AP MLD, it can be used for switching individually addressed frames, subject to the power state of the non-AP STA operating on that link. Only MSDUs or A-MSDUs with a TID mapped to the link can be transmitted on that link in the direction corresponding to the TID-to-link mapping (DL / UL). Individually addressed management and control frames can be transmitted on any enabled link between the non-AP MLD's affiliated STA in the DL and UL and the corresponding AP of the AP MLD.

[0150] If a link is disabled for a non-AP MLD, the link may not be used for exchanging individually addressed frames between the non-AP MLD's affiliated STA and the corresponding AP of the AP MLD.

[0151] If a TID is mapped in the UL to an enabled link set for a non-AP MLD, the non-AP MLD can use any link within that enabled link set to send a separately addressed MSDU or A-MSDU corresponding to that TID.

[0152] If a TID is mapped in the DL to an enabled set of links for a non-AP MLD, the non-AP MLD can retrieve the separately addressed BU buffered at the AP MLD as the MSDU or A-MSDU corresponding to the TID on any link in the enabled set. Conversely, the AP MLD can use any link within the enabled set to transmit the separately addressed MSDU or A-MSDU corresponding to the TID, depending on the power state of each non-AP STA on the used link.

[0153] If the default mode is used, non-AP MLDs can retrieve BUs buffered by AP MLDs on any established link, although AP MLDs can recommend links.

[0154] Non-AP MLDs can retrieve buffered BUs on any enabled link; these BUs are MMPDUs buffered at the AP MLD. AP MLDs can use any enabled link to transmit buffered management frames that are not separately addressed to measure MMPDUs, depending on the power state of the non-AP STAs on the link being used.

[0155] If a STA attached to a non-AP MLD is in active mode on a link with a set of TIDs mapped for DL ​​transmission, its associated AP attached to the AP MLD may send to the STA: MSDU / A-MSDU for the mapped TID set for the non-AP MLD; and MMPDU for measurement MMPDU that is not for the non-AP MLD or its attached STA, unless these frames are sent to another STA attached to the same non-AP MLD and in active mode.

[0156] As described above, in the default mapping mode, all TIDs are mapped to all established links of DL and UL, and all established links are enabled. If TID-to-link mapping negotiation for different mappings does not occur, fails, or is torn down, the non-AP MLD and AP MLD performing multi-link establishment will operate in this mode.

[0157] During the (re)establishment of multiple links, if the AP MLD has indicated support for TID-to-link mapping negotiation, the non-AP MLD can initiate TID-to-link mapping negotiation by including a TID-to-link mapping element in the (re)association request frame.

[0158] Upon receiving a (re)association request frame containing a TID-to-link mapping element, the AP MLD can respond to the (re)association request frame according to the following rules: The AP MLD may accept the requested TID-to-link mapping indicated in the TID-to-link mapping element in the received (re)association request frame only if the AP MLD accepts multi-link (re)establishment of all links requesting mapping at least one TID. In this case, the non-AP MLD includes the TID-to-link mapping element in the (re)association response frame. Otherwise, the non-AP MLD indicates rejection of the proposed TID-to-link mapping by including a TID-to-link mapping element suggesting preferred TID-to-link mapping in the (re)association response frame.

[0159] After a successful multilink (re)establishment, in order to negotiate a new TID-to-link mapping, the initiating MLD can send a separately addressed TID-to-link mapping request frame to the responding MLD that has indicated support for TID-to-link mapping negotiation.

[0160] Upon receiving a separately addressed TID-to-link mapping request frame, the responding MLD sends a separately addressed TID-to-link mapping response frame to the initiating MLD according to the following rules: The responding MLD can accept the requested TID-to-link mapping indicated in the TID-to-link mapping element of the received TID-to-link mapping request frame by sending a TID-to-link mapping response frame. Otherwise, the responding MLD can indicate rejection of the proposed TID-to-link mapping in the TID-to-link mapping response frame. The responding MLD can suggest a preferred TID-to-link mapping in the TID-to-link mapping response frame by including a TID-to-link mapping element in the TID-to-link mapping response frame.

[0161] MLDs can suggest preferred TID-to-link mappings to peer MLDs by sending an unsolicited TID-to-link mapping response frame that includes TID-to-link mapping elements.

[0162] When a peer MLD indicates a preferred TID-to-link mapping, the MLD can consider the preferred TID-to-link mapping when the MLD initiates a new TID-to-link mapping. Furthermore, the AP MLD can consider service flows attached to non-AP MLDs, as well as the capabilities and constraints of non-AP MLDs (if any).

[0163] When two MLDs have negotiated a TID-to-link mapping, the MLD can tear down the negotiated TID-to-link mapping by sending a separately addressed TID-to-link mapping teardown frame. After teardown, the MLD operates in the default mapping mode.

[0164] When MLD and peer MLD successfully negotiate TID-to-link mapping, both MLD and peer MLD update the uplink and / or downlink TID-to-link mapping information according to the negotiated TID-to-link mapping.

[0165] When an MLD has successfully negotiated uplink and / or downlink TID-to-link mappings with its peer MLD, bit position i of the link mapping field n in the TID-to-link mapping element is set to 0, and TID n should not be mapped to the link associated with link ID i in the uplink and / or downlink. When an MLD has successfully negotiated uplink and / or downlink TID-to-link mappings with its peer MLD, bit position i of the link mapping field n in the TID-to-link mapping element is set to 1, and TID n is mapped to the link associated with link ID i in the uplink and / or downlink.

[0166] Figure 10 An example of TID-to-link mapping in a multi-link communication environment is shown. As illustrated, the multi-link communication environment includes an AP MLD with three affiliated APs and a non-AP MLD with three affiliated STAs.

[0167] During or after multi-link establishment, non-AP MLDs and AP MLDs can negotiate TID-to-link mapping. TID-to-link mapping maps the TID at the non-AP MLD to the UL and DL to establish a link between the AP MLD and the non-AP MLD. For example, as... Figure 10 As shown, TID-to-link mapping maps TIDs 0-6 from both UL and DL to link 1, and TID 7 from both UL and DL to link 2. Therefore, links 1 and 2 are enabled, and link 3 is disabled. TID-to-link mapping negotiation can be performed by exchanging association request / response frames or TID-to-link mapping request / response frames between non-AP MLDs and AP MLDs.

[0168] Figure 11 Example 1100 of a Request to Send (RTS) / Clear to Send (CTS) procedure is shown. Example RTS / CTS procedure 1100 may be an example of an RTS / CTS procedure as defined in Section 10.3.2.9 of the IEEE 802.11 draft standard “IEEE P802.11-REVme™ / D2.1, January 2023”. Figure 11 As shown, example RTS / CTS procedure 1100 may include STA 1102 and STA 1104. Other STAs of the same BSS may also be within the communication range of STA 1102 and 1104.

[0169] In one example, STA 1102 may send RTS frame 1106 to STA 1104. STA 1102 may send RTS frame 1106 to protect the transmission of data frame 1110 that STA 1102 intends to send from the influence of (multiple) hidden STAs. RTS frame 1106 may include a duration / ID field. The duration / ID field may be set to the time in microseconds required to send data frame 1110 plus one CTS frame plus one ACK frame (if needed) plus three SIFS (Short Interframe Spacing) periods.

[0170] In one example, STA 1104 can respond to RTS frame 1106 by sending CTS frame 1108 to STA 1102. CTS frame 1108 can be sent within one SIFS period after RTS frame 1106. STA 1104 can respond to RTS frame 1106 when it is addressed and after considering NAV, unless NAV is set by a frame originating from STA 1102. STA 1104 can respond to RTS frame 1106 when it is addressed and if NAV indicates idle. For non-S1G STAs, NAV indicates idle when the NAV count is 0 or when the NAV count is non-zero but the non-bandwidth signaling TA obtained from the TA field of RTS frame 1106 matches the stored TXOP holder address. For S1G STA, NAV indicates idle when both NAV and RID (Response Indication Delay) counters are 0, or when either NAV or RID counters are non-zero but the TA field of RTS frame 1106 matches the stored TXOP holder address.

[0171] STA 1104 can set the RA field of CTS frame 1108 to the non-bandwidth signaling TA obtained from the TA field of RTS frame 1106. STA 1104 can set the duration field of CTS frame 1108 based on the duration / ID field of RTS frame 1106, that is, equal to the value of the duration / ID field of RTS frame 1106, adjusted by subtracting the time required to send CTS frame 1108 and one SIFS period.

[0172] Upon receiving CTS frame 1108, STA 1102 may wait for one SIFS period before sending data frame 1110. STA 1104 may send ACK frame 1112 in response to data frame 1110. STA 1104 may send ACK frame 1112 one SIFS after receiving data frame 1110.

[0173] As shown in Example 1100, other STAs within the communication range of STAs 1102 and 1104 and belonging to the same BSS can set their NAV based on RTS frame 1106 and / or CTS frame 1108. For example, a STA receiving RTS frame 1106 can set its NAV based on the duration / ID field of RTS frame 1106. Another STA receiving CTS frame 1008 can set its NAV based on the duration field of CTS frame 1108. In this way, other STAs can access the channel without using EDCA until the transmission of ACK frame 1112 ends. Similarly, if STAs belonging to an Overlapping BSS (OBSS) are within the communication range of the transmitting STA, they can set their NAV based on either RTS or CTS frames.

[0174] The future IEEE 802.11 standard is expected to provide various mechanisms to support the Quality of Service (QoS) requirements of low-latency (LL) (or latency-sensitive) services. Such services can originate from a variety of real-time applications with stringent latency requirements (e.g., very low average latency, worst-case latency of a few milliseconds to tens of milliseconds, and / or small jitter). In operation, LL services can be associated with one or more service identifiers (TIDs) linked to one or more pre-defined ACs or service flows (hereinafter, the TID associated with an LL service is referred to as the LL TID). For example, one or more pre-defined ACs may include access classes for video (AC_VI) and voice (AC_VO).

[0175] In addition to supporting the QoS requirements of low-latency services, future IEEE 802.11 radios (e.g., Ultra-High Reliability (UHR) 802.11 radios) are also expected to support reliable communication for low-latency services. Reliability can be achieved by using an RTS / CTS procedure before transmitting low-latency data to protect the transmission of low-latency data from interference. However, while meeting reliability requirements, low-latency data may be delayed when the receiving STA is unavailable to respond to an RTS frame. The following describes... Figure 12 Example 1200 illustrates an existing process that can be used to send low-latency data protected by RTS / CTS switching.

[0176] like Figure 12As shown, Example 1200 includes STAs 1210 and 1211 and OBSS STA 1212. OBSS STA 1212 may belong to a different BSS than STAs 1210 and 1211. STAs 1210 and 1211 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1212 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1212 may be within the communication range of STA 1211, but may not be within the communication range of STA 1210.

[0177] In Example 1200, STA 1210 may have a low-latency data frame 1225 to send to STA 1211 within a transmission completion time. The low-latency data frame may be a data frame including one or more MPDUs with an LLTID. In one implementation, STA 1210 may associate a counter with the transmission completion time. The transmission completion time counter may begin when STA 1210 sends low-latency data in the low-latency data frame 1225. In another implementation, the transmission completion time counter may begin when STA 1210 initiates an RTS / CTS procedure. In yet another implementation, the transmission completion time counter may begin when STA 1210 transmits the low-latency data frame 1225. In one implementation, successful transmission of the low-latency data frame may require the destination STA to acknowledge receipt of the low-latency data frame before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the amount of time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may be different for different low-latency data frames.

[0178] According to the existing process, in order to send low-latency data frame 1225, STA 1210 may first send RTS frame 1221 to STA 1211 via a first link (e.g., link-1). In one example, STA 1210 may start a transmission completion time counter associated with low-latency data frame 1225 when sending RTS frame 1221. In one example, since STA 1211 is receiving data frame 1222 from OBSS STA 1212 while receiving RTS frame 1221 from STA 1210, STA 1211 may send CTS frame to STA 1210 via the first link without responding to RTS frame 1221. In another example, OBSS STA 1212 may send a CTS frame to another STA ( Figure 12 (Not shown in the image) Data frame 1222 is sent, and STA 1211 may have already set its NAV based on data frame 1222 because it is within the communication range of OBSSSTA 1212.

[0179] In one example, the RTS / CTS timer may expire at STA 1210 before STA 1211 sends a CTS frame to STA 1210 via the first link. In this example, the RTS / CTS timer can be initialized with the value of the CTS timeout interval. The CTS timeout interval can represent the time interval from the start of the STA's transmission of the RTS frame. When the CTS timeout interval expires without receiving a CTS frame in response to the RTS frame, the STA can determine that the RTS / CTS process has failed. The CTS timeout interval can be equal to the duration of aSIFSTime + aSlotTime + aRxPHYStartDelay as described in Section 10.3.2.9 of the IEEE 802.11 standard (“IEEE P802.11-REV me™ / D 2.1, January 2023”). Here, aSIFSTime represents the nominal time (in microseconds) required from the end of the first PPDU[+SigExt] received on the radio medium to the MAC and PHY layers processing any frames therein and responding on the radio medium at the start of the second PPDU containing the earliest possible response frame; aSlotTime represents the slot time (in microseconds) used by the MAC to define the inter-frame interval; aRxPHY_StartDelay represents the delay (in microseconds) from the start of the PPDU at the receiver's antenna to the transmission of the PHY-RXSTART.indication primitive.

[0180] According to the existing procedure, STA 1210 can send another RTS frame 1223 to STA 1211 via the first link. In one example, if STA 1211's NAV indicates idle, STA 1211 can respond to RTS frame 1223 by sending a CTS frame 1224 to STA 1210 via the first link. By hearing the CTS frame, OBSS STA 1212 can set its NAV for the first link. Simultaneously, STA 1210 can send a low-latency data frame 1225 to STA 1211 via the first link. STA 1211 can send an ACK frame 1226 to STA 1210 via the first link after receiving the low-latency data frame 1225.

[0181] like Figure 12As shown, due to potential delays in the RTS / CTS protection process on busy links, the time elapsed from the transmission of RTS frame 1221 to the reception of ACK frame 1226 by STA 1210 may be longer than the transmission completion time of low-latency data frame 1225. For low-latency data frames, delayed transmission may be useless because the frame may no longer be useful to the receiving STA. In one approach, a STA with multi-link capability can request the transmission of low-latency data from available links (if any) by sending RTS frames on multiple links. The following describes... Figure 13 Example 1300 illustrates another existing process that can be used to send low-latency data protected by RTS / CTS switching.

[0182] like Figure 13 As shown, Example 1300 includes STAs 1310 and 1311 and OBSS STA 1312. OBSS STA 1312 may belong to a different BSS than STAs 1310 and 1311. STAs 1310 and 1311 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1312 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1312 may be within the communication range of STA 1311, but may not be within the communication range of STA 1310.

[0183] In Example 1300, STA 1310 may have a low-latency data frame 1325 to send to STA 1311 within a transmission completion time. The low-latency data frame may be a data frame including one or more MPDUs with an LLTID. In one implementation, STA 1310 may associate a counter with the transmission completion time. The transmission completion time counter may begin when STA 1310 sends low-latency data in the low-latency data frame 1325. In another implementation, the transmission completion time counter may begin when STA 1310 initiates an RTS / CTS procedure. In yet another implementation, the transmission completion time counter may begin when STA 1310 transmits the low-latency data frame 1325. In one implementation, successful transmission of the low-latency data frame may require the destination STA to acknowledge receipt of the low-latency data frame before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the amount of time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may be different for different low-latency data frames.

[0184] According to the existing process, in order to send low-latency data frame 1325, STA 1310 can send RTS frame 1321 to STA 1311 via a first link, and another RTS frame 1322 to STA 1311 via a second link (e.g., link 2). STA 1310 can initiate the transmission of RTS frames 1321 and 1322 simultaneously. Due to random backoff on the first and second links, the transmission of RTS frames 1321 and 1322 can be time-aligned or unaligned. In one example, STA 1310 can start a transmission completion time counter associated with low-latency data frame 1325 when sending RTS frame 1321.

[0185] In one example, since STA 1311 is receiving data frame 1323 from OBSS STA 1312 while receiving RTS frame 1321 from STA 1310, STA 1311 may send a CTS frame to STA 1310 via the first link without responding to RTS frame 1321. In another example, OBSS STA 1312 may send a CTS frame to another STA (…) via the first link. Figure 13 (Not shown) Data frame 1323 is transmitted, and STA 1311 may have already set its NAV based on data frame 1323 because it is within communication range of OBSS STA 1312. However, if STA 1311's NAV indicates idle, STA 1311 can respond to RTS frame 1322 by sending CTS frame 1324 to STA 1310 via the second link. By listening to CTS frame 1324, OBSS STA 1312 can set its NAV for the second link. After receiving CTS frame 1324, STA 1310 can send low-latency data frame 1325 to STA 1311 via the second link. STA 1311 can send ACK frame 1326 to STA 1310 via the second link after receiving data frame 1325. Meanwhile, after transmitting RTS frame 1321 via the first link, if no CTS frame is received via the first link, STA 1310 can observe the expiration of the CTS timeout interval. When transmitting data frame 1325 via the second link, STA 1310 does not transmit additional RTS frames via the first link.

[0186] like Figure 13 As shown, by sending multiple RTS frames (to request the transmission of low-latency data) via multiple links and receiving CTS frames from one of the links, the time elapsed for STA 1310 from the transmission of RTS frame 1321 to the reception of ACK frame 1326 can be less than the transmission completion time. In scenarios where one or more links are busy / unavailable and only one link is available, such as... Figure 13As shown, transmitting multiple RTS frames via multiple links can provide an efficient solution for low-latency data transmission. However, when multiple links are available, the transmission of multiple RTS frames may cause STAs within the communication range of the receiving STA (OBSS STA and / or other STAs in the same BSS) to set their NAV for all links from which they hear the CTS frame. However, when the transmitting STA transmits data frames via only one link, STAs within the communication range of the receiving STA can avoid unnecessary communication via other links. The following description... Figure 14 Example 1400 illustrates another existing process that can be used to send low-latency data protected by RTS / CTS switching.

[0187] like Figure 14 As shown, Example 1400 includes STAs 1410 and 1411 and OBSS STA 1412. OBSS STA 1412 may belong to a different BSS than STAs 1410 and 1411. STAs 1410 and 1411 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1412 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1412 may be within the communication range of STA 1411, but may not be within the communication range of STA 1410.

[0188] In Example 1400, STA 1410 may have a low-latency data frame 1425 to send to STA 1411 within a transmission completion time. The low-latency data frame may be a data frame including one or more MPDUs with an LLTID. In one implementation, STA 1410 may associate a counter with the transmission completion time. The transmission completion time counter may begin when STA 1410 sends low-latency data in low-latency data frame 1425. In another implementation, the transmission completion time counter may begin when STA 1410 initiates an RTS / CTS procedure. In yet another implementation, the transmission completion time counter may begin when STA 1410 transmits low-latency data frame 1425. In one implementation, successful transmission of the low-latency data frame may require the destination STA to acknowledge receipt of the low-latency data frame before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the amount of time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may be different for different low-latency data frames.

[0189] According to the existing process, in order to send low-latency data frame 1425, STA 1410 can send RTS frame 1421 to STA 1411 via the second link and another RTS frame 1422 to STA 1411 via the first link. STA 1410 can initiate the transmission of RTS frames 1421 and 1422 simultaneously. Due to random backoff on the first and second links, the transmission of RTS frames 1421 and 1422 can be time-aligned or unaligned. In one example, STA 1410 can start a transmission completion time counter associated with low-latency data frame 1425 when sending RTS frame 1421.

[0190] In one example, if STA 1411's NAV indicates idle, STA 1411 may respond to RTS frame 1421 by sending CTS frame 1423 to STA 1410 via the second link. If STA 1411's NAV indicates idle, STA 1411 may also respond to RTS frame 1422 by sending CTS frame 1424 to STA 1410 via the first link. While listening for CTS frame 1423 via the second link and CTS frame 1424 via the first link, OBSS STA 1412 may set its NAV for the first and second links based on CTS frames 1423 and 1424, respectively. After receiving CTS frame 1423 via the second link (e.g., STA 1410 receives CTS frame 1423 via the second link earlier than it receives CTS frame 1424 via the first link), STA 1410 may send data frame 1425 to STA 1411 via the second link. STA 1411 can send an ACK frame 1426 to STA 1410 via the second link after receiving data frame 1425. Simultaneously, after transmitting CTS frame 1424 via the first link, if STA 1411 does not receive a data frame via the first link within a duration of (2×aSIFSTime) + CTS_Time + aRxPHYStartDelay + (2×aSlotTime), STA 1411 can reset its own NAV for the first link. CTS_Time represents the transmission time of CTS frame 1424. On the other hand, OBSS STAs in the same BSS as STA 1411 (e.g., OBSS STA 1412) and other STAs cannot reset their NAVs for the first link and therefore cannot communicate via the first link, even though the first link is not used for any frame transmission. Thus, although low-latency data can be sent before the transmission completion time, many STAs may become unavailable on the first link even though it is not used.

[0191] As further described below, embodiments of this disclosure address the aforementioned problems of existing processes. In one aspect, embodiments enable a multi-link-capable STA (AP STA or non-AP STA) to utilize the availability of a second link to transmit low-latency data when successful protection of transmission via the first link becomes impossible. In another aspect, the STA can utilize the availability of the second link, in addition to the first link, based on the remaining time for transmitting low-latency data within the transmission completion time. In yet another aspect, embodiments enable a receiving STA to respond to multiple RTS frames received via multiple links via only one link. This prevents other STAs within the communication range of the receiving STA from being unnecessarily prevented from communicating via other links.

[0192] Figure 15 An example process 1500 according to an embodiment is illustrated. The example process 1500 is provided for illustrative purposes only and is not intended to limit the embodiments. Example process 1500 can be performed by a first STA (i.e., including a multi-link device (MLD)). The first STA can be an AP STA or a non-AP STA. The first STA can be a transmitting STA with data for transmission to a second STA (receiving STA). The second STA may also include an MLD. The first STA and the second STA can communicate via at least a first link and a second link. In the example, the first link may include one of the 2.4 GHz band, the 5 GHz band, the 6 GHz band, or a band to be defined in the future. Similarly, the second link may include one of the 2.4 GHz band, the 5 GHz band, the 6 GHz band, or a band to be defined in the future, wherein the second link is different from the first link.

[0193] like Figure 15 As shown, process 1500 may begin in step 1505, which includes determining whether the data to be sent to the second STA includes low-latency services. As used herein, low-latency services may refer to services associated with one or more predefined service categories or service flows (e.g., voice / video). Low-latency services may include data frames with LL TIDs. If the answer is no in step 1505, process 1500 proceeds to step 1510, where the STA processes the data according to existing IEEE 802.11 standard procedures. For example, the STA may use existing RTS / CTS procedures defined in existing standards before sending the data.

[0194] Otherwise, if the answer is yes in step 1505, process 1500 can transition to step 1520 based on the first option (hereinafter referred to as option-1) or to step 1545 based on the second option (hereinafter referred to as option-2).

[0195] Step 1520 includes sending a first RTS frame requesting the transmission of data including low-latency services to the second STA via the first link. Subsequently, process 1500 proceeds to step 1525, which includes checking whether a CTS frame has been received from the second STA via the first link. If the answer in step 1525 is yes, process 1500 can transition to step 1530, which includes sending data including low-latency services to the second STA via the first link.

[0196] Otherwise, if the answer is no in step 1525, process 1500 can proceed to step 1535, which includes determining whether time period T has elapsed. In an embodiment, time period T can be used as an early check to determine whether a transmission request on the link has been accepted. The early check ensures that if a transmission request has not yet been accepted, data including low-latency services can still be sent via another link within the transmission completion time. In an embodiment, time period T is set according to the equation T <= Transmission completion duration - Data transmission duration - ACK transmission duration - RTS / CTS exchange duration - 4xSIFS duration - Maximum backoff duration (Equation 1).

[0197] If the answer is no in step 1535, then process 1500 can be converted back to step 1525 above.

[0198] Otherwise, if the answer is yes in step 1535, process 1500 can proceed to step 1540. In a first embodiment, step 1540 includes sending a second RTS frame to a second STA via a second link. In this embodiment, according to the first embodiment, the time period T may be less than the CTS timeout interval. The second RTS frame requests the transmission of data including low-latency services to the second STA via the second link. In response, the first STA may receive a CTS frame from the second STA via the second link in response to the second RTS frame. The first STA may then send data including low-latency services to the second STA via the second link.

[0199] In a second embodiment, step 1540 includes sending a second RTS frame to the second STA via the second link, and also sending a third RTS frame to the second STA via the first link. In this embodiment, according to the second embodiment, the time period T can be greater than or equal to the CTS timeout interval. The third RTS frame requests the transmission of data including low-latency services to the second STA via the first link. Therefore, the third RTS frame can overlap with the second RTS frame in time. In one embodiment, the second and third RTS frames may include a Multiple User Request Transmission (MU-RTS) trigger frame. In one embodiment, the first STA may receive a CTS frame from the second STA via the second link in response to the second RTS frame, and may send data including low-latency services to the second STA via the second link. In another embodiment, the first STA may receive a CTS frame from the second STA via the first link in response to the third RTS frame.

[0200] Now switch to option-2, step 1545 includes: sending a first MU-RTS trigger frame to the second STA via the first link, the first MU-RTS trigger frame requesting data to be sent to the second STA via the first link; and sending a second MU-RTS trigger frame to the second STA via the second link, the second MU-RTS trigger frame requesting data to be sent to the second STA via the second link.

[0201] In one embodiment, the first MU-RTS trigger frame may include an indication of a second link. In one embodiment, the indication of the second link in the first MU-RTS trigger frame instructs the second STA that a second MU-RTS trigger frame transmitted via the second link requests the transmission of the same data as the first MU-RTS trigger frame transmitted via the first link. In another embodiment, the second MU-RTS trigger frame may include an indication of the first link. In one embodiment, the indication of the first link in the second MU-RTS trigger frame instructs the second STA that a first MU-RTS trigger frame transmitted via the first link requests the transmission of the same data as the second MU-RTS trigger frame transmitted via the second link. Such indications in the first or second MU-RTS trigger frame allow the second STA to link the first and second MU-RTS trigger frames for the same data.

[0202] In one embodiment, the first MU-RTS trigger frame and / or the second MU-RTS trigger frame may include an indication of a CTS response option for use by the second STA. In one embodiment, the CTS response option may include the second STA responding to either the first MU-RTS trigger frame or the second MU-RTS trigger frame. Alternatively, the CTS response option may include the second STA responding to both the first and second MU-RTS trigger frames.

[0203] Subsequently, process 1500 proceeds to step 1550, which includes determining whether the CTS frame was received via the first link or the second link within the CTS timeout interval. If the answer in step 1550 is no, process 1500 returns to step 1545 described above. Otherwise, if the answer in step 1550 is yes, i.e., the STA receives the CTS frame from the second STA via one of the first and second links (e.g., via the second link in response to the second MU-RTS trigger frame), then the STA can send a data frame containing data to the second STA via the corresponding link (e.g., via the second link in response to the CTS frame).

[0204] Figure 16 Example 1600 of a proposed process, according to one embodiment, for transmitting low-latency data protected by RTS / CTS switching is shown. Figure 16 As shown, Example 1600 includes STA 1610 and STA 1611, and OBSS STA 1612. OBSS STA 1612 may belong to a different BSS than STA 1610 and STA 1611. STA 1610 and STA 1611 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1612 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1612 may be within the communication range of STA 1611, but may not be within the communication range of STA 1610.

[0205] In Example 1600, STA 1610 may have a low-latency data frame 1625 to send to STA 1611 within a transmission completion time. The low-latency data frame may be a data frame including one or more MPDUs with an LLTID. In one implementation, STA 1610 may associate a counter with the transmission completion time. The transmission completion time counter may begin from the arrival of the low-latency data transmitted in the low-latency data frame 1625 at STA 1610. In another implementation, the transmission completion time counter may begin from the transmission of the low-latency data frame 1625 by STA 1610. In yet another implementation, the transmission completion time counter may begin from the transmission of the low-latency data frame 1625 by STA 1610. In one implementation, successful transmission of the low-latency data frame may require the destination STA to acknowledge receipt of the low-latency data frame before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the amount of time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may be different for different low-latency data frames.

[0206] To send a low-latency data frame 1625, STA 1610 may send a request to STA 1611 via the first link to send an RTS frame 1621 containing data for low-latency services. In one example, STA 1610 may start a transmission completion time counter associated with the low-latency data frame 1625 when sending the RTS frame 1621. In one example, since STA 1611 is receiving data frame 1622 from OBSS STA 1612 while receiving the RTS frame 1621 from STA 1610, STA 1611 may send a CTS frame to STA 1610 via the first link without responding to the RTS frame 1621. In another example, OBSS STA 1612 may send a request to another STA ( Figure 16 (Not shown in the image) Sends data frame 1622, and STA1611 may set its NAV due to being within the communication range of OBSS STA 1612.

[0207] In one embodiment, based on the fact that STA 1610 has not received a CTS frame from STA 1611 within a time period T from the transmission of RTS frame 1621 and that data frame 1625 includes low-latency services, STA 1610 may send a request to STA 1611 via the second link to send RTS frame 1623 of data frame 1625 to STA 1611 via the second link. In this embodiment, the time period T is set to a value lower than the CTS timeout interval (and according to equation (1) above). In an example, the time period T may be set to 1 / 2 of the CTS timeout interval value. In another example, the time period T may be set to 1 / 3 of the CTS timeout interval value. Therefore, the time period T can be used to perform an early check on whether the RTS / CTS exchange is successful on the first link. The early check can provide an indication of whether the RTS / CTS exchange on the first link will be successful. Based on the early check, STA 1611 can immediately initiate an RTS / CTS exchange via the second link to increase the transmission opportunity of low-latency services.

[0208] In one embodiment, STA 1610 may not send another RTS frame via the first link after a CTS timeout interval. In one embodiment, if the NAV indicates that the second link for STA 1611 is idle, STA 1610 may receive CTS frame 1624 from STA 1611 via the second link in response to RTS frame 1623. While listening for CTS frame 1624, OBSS STA 1612 may set its NAV for the second link based on CTS frame 1624. STA 1610 may then send data frame 1625 to STA 1611 via the second link. STA 1611 may send ACK frame 1626 to STA 1610 via the second link after receiving data frame 1625.

[0209] like Figure 16 As shown, using the proposed procedure, STA 1611 receives data including low-latency services within the transmission completion time. This is achieved by STA 1611 switching to a second link to perform RTS / CTS switching after time period T has elapsed. Time period T being less than the CTS timeout interval ensures that STA 1611 initiates RTS / CTS switching on the second link based on an early check of whether the RTS / CTS switching was successful on the first link. Initiating RTS / CTS switching early via the second link allows STA 1611 to postpone the transmission of multiple RTS frames via multiple links in a robust manner.

[0210] Figure 17 Another example 1700 of the proposed process, according to an embodiment, can be used to transmit low-latency data protected by RTS / CTS switching. (As...) Figure 17 As shown, Example 1600 includes STA 1610 and STA 1611, and OBSS STA 1612. OBSS STA 1612 may belong to a different BSS than STA 1610 and STA 1611. STA 1610 and STA 1611 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1612 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1612 may be within the communication range of STA 1611, but may not be within the communication range of STA 1610.

[0211] To send a low-latency data frame 1726, STA 1610 may send a request to STA 1611 via the first link to send an RTS frame 1721 containing data for low-latency services. In one example, STA 1610 may start a transmission completion time counter associated with the low-latency data frame 1726 when sending the RTS frame 1721. In one example, since STA 1611 is receiving data frame 1722 from OBSS STA 1612 at the time it receives the RTS frame 1721 from STA 1610, STA 1611 may send a CTS frame to STA 1610 via the first link without responding to the RTS frame 1721. In another example, OBSS STA 1612 may send a request to another STA ( Figure 17 (Not shown in the image) Sends data frame 1722, and STA1611 may set its NAV due to being within the communication range of OBSS STA 1612.

[0212] In one embodiment, based on the fact that STA 1610 has not received a CTS frame from STA 1611 within a time period T from the transmission of RTS frame 1721 and that data frame 1726 includes low-latency services, STA 1610 may send a request to STA 1611 via a second link to send an RTS frame 1723 of data frame 1726 to STA 1611 via the second link. In this embodiment, the time period T may be greater than or equal to the CTS timeout interval (and according to equation (1) above). In one embodiment, when the time period T is greater than or equal to the CTS timeout interval, STA 1610 may further send a request to STA 1611 via a first link to send an RTS frame 1724 of data frame 1726 to STA 1611 via the first link. In this embodiment, RTS frame 1724 may overlap with RTS frame 1723 in time.

[0213] In one embodiment, STA 1610 may receive CTS frame 1725 from STA 1611 via a second link in response to RTS frame 1723. By listening to CTS frame 1725, OBSS STA 1612 may set its NAV for the second link based on CTS frame 1725. STA 1610 may then send data frame 1726 to STA 1611 via the second link. In another embodiment, STA 1610 may receive CTS frame 1727 from STA 1611 via a first link in response to RTS frame 1724. By listening to CTS frame 1727, OBSS STA 1612 may set its NAV for the first link based on CTS frame 1727. In one embodiment, STA 1610 may receive CTS frame 1727 after receiving CTS frame 1725. Therefore, since STA 1610 may have already started transmitting data frame 1726 via the second link, STA 1610 may not respond to CTS frame 1727 via the first link. In an embodiment, if STA 1611 does not receive a data frame via the link after STA 1611 has transmitted a CTS frame via the link, STA 1611 may reset its NAV for the link. Thus, in Example 1700, STA 1611 may reset its NAV for the first link based on receiving a data frame responding to CTS frame 1727. Upon receiving data frame 1726, STA 1611 may send ACK frame 1728 to STA 1610 via the second link.

[0214] like Figure 17 As shown, using the proposed procedure, the second STA receives data including low-latency services within the transmission completion time. This is achieved by the first STA transmitting multiple RTS frames via multiple links after the time period T has elapsed. The time period T being greater than or equal to the CTS timeout interval ensures that if the first RTS / CTS exchange via the first link fails, the first STA resorts to multiple RTS transmissions via multiple links. In other words, it is a powerful method for the STA to resort to multiple RTS transmissions via multiple links when the remaining time window for performing low-latency data transmission becomes narrower.

[0215] However, even though data including low-latency services is transmitted only via the second link and the first link is not used, OBSS STA 1612 cannot reset its NAV for the first link because it is listening for CTS frame 1727 on the first link. This can also be the case for any STA within the communication range of STA 1611, and such STAs cannot communicate via the first link even though it is not used for any frame transmissions. The following describes... Figure 18 An example solution to this problem is provided.

[0216] Figure 18 Another example 1800 of the proposed process, according to one embodiment, for transmitting low-latency data protected by RTS / CTS switching is shown. For example... Figure 18 As shown, Example 1800 includes STA 1610 and STA 1611, and OBSS STA 1612. OBSS STA 1612 may belong to a different BSS than STA 1610 and STA 1611. STA 1610 and STA 1611 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1612 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1612 may be within the communication range of STA 1611, but may not be within the communication range of STA 1610.

[0217] To send a low-latency data frame 1826, STA 1610 may send a request to STA 1611 via the first link to send an RTS frame 1821 containing data including low-latency services. In one example, STA 1610 may start a transmission completion time counter associated with the low-latency data frame 1826 when sending the RTS frame 1821. In one example, since STA 1611 is receiving data frame 1822 from OBSS STA 1612 at the time it receives the RTS frame 1821 from STA 1610, STA 1611 may send a CTS frame to STA 1610 via the first link without responding to the RTS frame 1821. In another example, OBSS STA 1612 may send a request to another STA ( Figure 18 (Not shown) Sends data frame 1822, and STA1611 may set its NAV due to being within the communication range of OBSS STA 1612.

[0218] In one embodiment, based on the fact that STA 1610 has not received a CTS frame from STA 1611 within a time period T from the transmission of RTS frame 1821 and that data frame 1826 includes low-latency services, STA 1610 may send a MU-RTS trigger frame 1823 requesting STA 1611 to send data frame 1826 via the second link. In this embodiment, the time period T may be greater than or equal to the CTS timeout interval (and according to equation (1) above). In one embodiment, when the time period T is greater than or equal to the CTS timeout interval, STA 1610 may further send a MU-RTS trigger frame 1824 requesting STA 1611 to send data frame 1826 via the first link. In this embodiment, MU-RTS trigger frame 1824 may overlap with MU-RTS trigger frame 1823 in time. In one embodiment, MU-RTS trigger frame 1823 and / or MU-RTS trigger frame 1824 may have similar characteristics to the following: Figure 22 The format of trigger frame 2200 is described further.

[0219] In one embodiment, STA 1611 may receive MU-RTS trigger frame 1823 via a second link before receiving MU-RTS trigger frame 1824 via a first link. In one embodiment, if NAV indicates idle, STA 1611 may respond to MU-RTS trigger frame 1823 by sending CTS frame 1825 via the second link. In another embodiment, STA 1611 may receive MU-RTS trigger frame 1823 via the second link simultaneously with or later than receiving MU-RTS trigger frame 1824 via the first link. In this embodiment, STA 1611 may select an appropriate link (e.g., the second link) for CTS transmission (e.g., depending on service parameters) and may send only one CTS frame via the selected link (e.g., the second link). The selection of only one appropriate link for CTS transmission may be determined by factors such as... Figure 22 MU-RTS frames 1823 and 1824, defined in a specific format, are triggered. In one embodiment, MU-RTS trigger frame 1823 or MU-RTS trigger frame 1824 may include an indication of a CTS response option for use by STA 1611. In one embodiment, the CTS response option may include STA 1611 responding to MU-RTS trigger frame 1823 or MU-RTS trigger frame 1824. In another embodiment, the CTS response option may include STA 1611 responding to both MU-RTS trigger frames 1823 and MU-RTS trigger frame 1824.

[0220] In one embodiment, STA 1610 may receive CTS frame 1825 from STA 1611 via a second link in response to MU-RTS trigger frame 1823. While listening for CTS frame 1825, OBSS STA 1612 may set its NAV for the second link. STA 1610 may then send data frame 1826 to STA 1611 via the second link. Upon receiving data frame 1826, STA 1611 may send ACK frame 1827 to STA 1610 via the second link.

[0221] like Figure 18 As shown, in the proposed process, MU-RTS trigger frames (instead of RTS frames) are used, and STA 1611 transmits a single CTS frame via the second link in response to multiple MU-RTS trigger frames. Therefore, OBSS STA 1612 does not unnecessarily set its NAV for the first link, thereby allowing other transmissions on the first link (e.g., involving OBSS STA 1612).

[0222] Figure 19 Another example 1900 of the proposed process, according to an embodiment, can be used to transmit low-latency data protected by RTS / CTS switching. (As...) Figure 19 As shown, Example 1900 includes STA 1610 and STA 1611, and OBSS STA 1612. OBSS STA 1612 may belong to a different BSS than STA 1610 and STA 1611. STA 1610 and STA 1611 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1612 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1612 may be within the communication range of STA 1611, but may not be within the communication range of STA 1610.

[0223] In an embodiment, STA 1610 can receive data for transmission to STA 1611. Based on the data including low-latency services, STA 1610 can send a MU-RTS trigger frame 1921 requesting data transmission to STA 1611 via a first link, and a MU-RTS trigger frame 1922 requesting data transmission via a second link to STA 1611. In one embodiment, MU-RTS trigger frame 1921 and / or MU-RTS trigger frame 1922 may have similar characteristics to the following: Figure 22The format of trigger frame 2200 is further described. In one embodiment, MU-RTS trigger frame 1921 may include an indication of a second link. In one embodiment, the indication of the second link in MU-RTS trigger frame 1921 may instruct STA 1611 that MU-RTS trigger frame 1922 transmitted via the second link requests the transmission of the same data as MU-RTS trigger frame 1921 transmitted via the first link. In another embodiment, MU-RTS trigger frame 1922 may include an indication of a first link. In one embodiment, the indication of the first link in MU-RTS trigger frame 1922 may instruct STA 1611 that MU-RTS trigger frame 1921 transmitted via the first link requests the transmission of the same data as MU-RTS trigger frame 1922 transmitted via the second link. Such indications in MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922 allow STA 1611 to link MU-RTS trigger frame 1921 and MU-RTS trigger frame 1922 for the same data.

[0224] In another embodiment, MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922 may include an indication of a CTS response option for use by STA 1611. In one embodiment, the CTS response option may include STA 1611 responding to MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922. In another embodiment, the CTS response option may include STA 1611 responding to both MU-RTS trigger frames 1921 and MU-RTS trigger frame 1922.

[0225] In one embodiment, since STA 1611 is receiving data frame 1923 from OBSS STA 1612 while receiving MU-RTS frame 1921 from STA 1610, STA 1611 may send a CTS frame to STA 1610 via the first link without responding to MU-RTS frame 1921. In another example, since OBSS STA 1612 is within communication range of OBSS STA 1612, OBSS STA 1612 may send a CTS frame to another STA ( ) via the first link. Figure 19(Not shown in the image) Data frame 1923 is transmitted, and STA 1611 can set its NAV based on data frame 1923. In one embodiment, if STA 1611's NAV indicates idle, STA 1611 can send CTS frame 1924 to STA 1610 via the second link in response to MU-RTS frame 1922. By listening to CTS frame 1924, OBSS STA 1612 can set its NAV for the second link based on CTS frame 1924. Then, STA 1610 can send data frame 1925, including data, to STA 1611 via the second link. Upon receiving data frame 1925, STA 1611 can send ACK frame 1926 to STA 1610 via the second link.

[0226] Figure 20 An example is shown. Figure 19 Another example of the process described in 2000. (e.g.) Figure 20 As shown, Example 2000 includes STA 1610 and STA 1611, and OBSS STA 1612. OBSS STA 1612 may belong to a different BSS than STA 1610 and STA 1611. STA 1610 and STA 1611 may each include an AP MLD or a non-AP MLD capable of communicating via multiple links. Similarly, OBSS STA 1612 may include an AP MLD or a non-AP MLD capable of communicating via multiple links. In this example, OBSS STA 1612 may be within the communication range of STA 1611, but may not be within the communication range of STA 1610.

[0227] In an embodiment, STA 1610 can receive data for transmission to STA 1611. Based on the data including low-latency services, STA 1610 can send a MU-RTS trigger frame 2021 requesting data transmission to STA 1611 via a first link, and a MU-RTS trigger frame 2022 requesting data transmission to STA 1611 via a second link. In one embodiment, MU-RTS trigger frame 1921 and / or MU-RTS trigger frame 1922 may have similar characteristics to the following... Figure 22 The format of trigger frame 2200 is further described. In one embodiment, MU-RTS trigger frame 2021 may include an indication of a second link. In one embodiment, the indication of the second link in MU-RTS trigger frame 2021 may instruct STA 1611 that MU-RTS trigger frame 2022 transmitted via the second link requests the transmission of the same data as MU-RTS trigger frame 2021 transmitted via the first link.

[0228] In another embodiment, MU-RTS trigger frame 2022 may include an indication of a first link. In one embodiment, the indication of the first link in MU-RTS trigger frame 2022 may instruct STA 1611 that MU-RTS trigger frame 2021 transmitted via the first link requests the transmission of the same data as MU-RTS trigger frame 2022 transmitted via a second link. Such an indication in MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922 allows STA 1611 to link MU-RTS trigger frames 1921 and 1922 for the same data.

[0229] In another embodiment, MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022 may include an indication of a CTS response option for use by STA 1611. In one embodiment, the CTS response option may include STA 1611 responding to MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022. In another embodiment, the CTS response option may include STA 1611 responding to both MU-RTS trigger frame 2021 and MU-RTS trigger frame 2022.

[0230] In one embodiment, STA 1611 may receive MU-RTS trigger frame 2022 via a second link before receiving MU-RTS trigger frame 2021 via a first link. In one embodiment, if NAV indicates idle, STA 1611 may respond to MU-RTS trigger frame 2022 by sending CTS frame 2023 via the second link. In another embodiment, STA 1611 may receive MU-RTS trigger frame 2022 via the second link simultaneously with or later than receiving MU-RTS trigger frame 2021 via the first link. In this embodiment, STA 1611 may select an appropriate link (e.g., the second link) for CTS transmission (e.g., depending on service parameters) and may send only one CTS frame via the selected link (e.g., the second link). The selection of only one appropriate link for CTS transmission may be determined by factors such as... Figure 22 The MU-RTS frame 2021 and MU-RTS frame 2022, defined in a specific format, are triggered. In one embodiment, MU-RTS trigger frame 2021 may include an indication of a CTS response option for use by STA 1611. In one embodiment, the CTS response option may include STA 1611 responding to MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022. In another embodiment, the CTS response option may include STA 1611 responding to both MU-RTS trigger frames 2021 and MU-RTS trigger frame 2022.

[0231] In one embodiment, STA 1610 may receive CTS frame 2023 from STA 1611 via a second link in response to MU-RTS trigger frame 2022. While listening for CTS frame 2023, OBSS STA 1612 may set its NAV for the second link. STA 1610 may then send data frame 2024 to STA 1611 via the second link. Upon receiving data frame 2024, STA 1611 may send ACK frame 2025 to STA 1610 via the second link.

[0232] In one embodiment, by selecting the CTS reply option in which STA 1611 responds only to one of MU-RTS frames 2021 and 2022, STA 1611 transmits a single CTS frame 2023 via the second link. STAs within the communication range of STA 1611 (including OBSS STA 1612) do not set their NAVs for the first link and can communicate via the first link during the transmission of data frame 2024 and ACK frame 2025.

[0233] Figure 21 An example public information field 2100 of a basic multilink element according to an embodiment is shown. A basic multilink element can be sent by one STA to another STA to notify that STA of its capabilities. For example... Figure 21 As shown, the public information field 2100 may include a public information length subfield, an MLD MAC address subfield, a link ID information subfield, a BSS parameter change count subfield, a media synchronization delay information subfield, an EML capability subfield, an MLD capability and operation subfield, an AP MLD ID subfield, and an extended MLD capability and operation subfield.

[0234] In one embodiment, reserved bits in the MLD capability and operation subfield can be used to signal the operation mode for data transmission, which includes the operation mode exchanged by RTS / CTS (e.g., above). Figure 15 The low-latency service is protected by option-1 or option-2 as described in the document.

[0235] Figure 22 An example MU-RTS trigger frame 2200 according to an embodiment is shown. The MU-RTS trigger frame 2200 may be an embodiment of the MU-RTS trigger frames 1823, 1824, 1921, 1922, 2021 and / or 2022 described above.

[0236] like Figure 22As shown, the example MU-RTS trigger frame 2200 may include a frame control subfield, a duration subfield, a receiver address (RA) subfield, a transmitter address (TA) subfield, a common information subfield, a padding subfield, an FCS subfield, and a user information list subfield.

[0237] In an embodiment, the user information list subfield may indicate one or more other links compared to the link on which the MU-RTS trigger frame 2200 was transmitted. The indication of one or more other links in the MU-RTS trigger frame 2200 indicates to the receiving STA that other MU-RTS trigger frames transmitted via those one or more other links request the transmission of the same data as MU-RTS trigger frame 2200. In one example, the indication of one or more other links (e.g., the 2.4 GHz band, the 5 GHz band, the 6 GHz band, etc.) may be transmitted in one or more reserved bits of the user information list subfield.

[0238] In one example, the user information list subfield may also include an indication of a CTS response option used by the receiving STA. Therefore, the CTS response option may include the receiving STA responding to only one of a plurality of received MU-RTS trigger frames. Alternatively, the CTS response option may also include a second STA responding to each of the plurality of received MU-RTS trigger frames. In one example, the CTS response option may be sent in reserved bits of the user information list subfield.

[0239] Figure 23 An example process 2300 according to an embodiment is illustrated. The example process 2300 is provided for illustrative purposes only and is not intended to be limiting. For example, the example process 2300 may be performed by a first STA (such as STA 1610). The first STA may have multi-link capability (i.e., include a multi-link device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a transmitting STA with data for transmission to a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link.

[0240] like Figure 23 As shown, process 2300 may include: in step 2310, a first STA sends a first RTS frame requesting the transmission of first data to the second STA via the first link. In an embodiment, the first STA and the second STA may each include an AP MLD or a non-AP MLD capable of communicating through multiple links. In an embodiment, the first data may include low-latency services.

[0241] In step 2320, process 2300 may include: the first STA sending a second RTS frame to the second STA via the second link, the second RTS frame requesting the transmission of first data to the second STA via the second link based on the fact that the first STA has not received the first CTS frame from the second STA within the time period from the transmission of the first RTS frame and based on the fact that the first data includes low-latency services.

[0242] In one embodiment, the time period may be less than the CTS timeout interval (and according to equation (1) described above). In another embodiment, the time period may be greater than or equal to the CTS timeout interval (and according to equation (1) described above).

[0243] In one embodiment, process 2300 may further include the first STA receiving a second CTS frame from the second STA via the second link in response to the second RTS frame. In one embodiment, process 2300 may further include the first STA sending first data to the second STA via the second link.

[0244] In one embodiment, process 2300 may further include a first STA sending a third RTS frame requesting the second STA to transmit first data via the first link. In one embodiment, the first STA sends the third RTS frame when it has not received the first CTS frame from the second STA within a time period from the transmission of the first RTS frame and when the first data includes low-latency services. In this embodiment, the third RTS frame may overlap with the second RTS frame.

[0245] In one embodiment, process 2300 may further include receiving a third CTS frame from a second STA via a first link in response to a third RTS frame.

[0246] In another embodiment, the second RTS frame and the third RTS frame may include MU-RTS trigger frames. In one embodiment, process 2300 may further include the first STA receiving a second CTS frame from the second STA via the second link in response to the second MU-RTS trigger frame. In one embodiment, process 2300 may further include the first STA sending first data to the second STA via the second link.

[0247] Figure 24Another example process 2400 according to an embodiment is shown. The example process 2400 is provided for illustrative purposes only and is not intended to be limiting. For example, the example process 2400 may be performed by a first STA (such as STA 1610). The first STA may have multi-link capability (i.e., include a multi-link device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a transmitting STA with data for transmission to a second STA. The second STA may also include an MLD. The first STA and the second STA can communicate via at least a first link and a second link.

[0248] like Figure 24 As shown, process 2400 may include: in step 2410, the first STA receives data for transmission to the second STA.

[0249] In step 2420, process 2400 may include: sending a first MU-RTS trigger frame from a first STA to a second STA via a first link, based on data including low-latency services, the first MU-RTS trigger frame requesting data transmission to the second STA via the first link; and sending a second MU-RTS trigger frame from the first STA to the second STA via a second link, the second MU-RTS trigger frame requesting data transmission to the second STA via the second link. In one embodiment, the first MU-RTS trigger frame may include an indication of the second link. In one embodiment, the indication of the second link in the first MU-RTS trigger frame may instruct the second STA that the second MU-RTS trigger frame sent via the second link requests the transmission of the same data as the first MU-RTS trigger frame sent via the first link.

[0250] Similarly, in this embodiment, the second MU-RTS trigger frame may include an indication of the first link. In one embodiment, the indication of the first link in the second MU-RTS trigger frame may instruct the second STA to request the transmission of the same data as the second MU-RTS trigger frame transmitted via the first link.

[0251] In another embodiment, the first MU-RTS trigger frame or the second MU-RTS trigger frame may include an indication of a CTS response option for use by the second STA. In one embodiment, the CTS response option may include the second STA responding to one of the first MU-RTS trigger frame or the second MU-RTS trigger frame. In another embodiment, the CTS response option may include the second STA responding to both the first and second MU-RTS trigger frames.

[0252] In one embodiment, process 2400 may further include the first STA receiving a first CTS frame from a second STA via a second link in response to a second MU-RTS trigger frame. In another embodiment, process 2400 may further include the first STA sending a data frame including the data to the second STA via the second link.

[0253] Figure 25 Another example process 2500 according to an embodiment is shown. Example process 2500 is provided for illustrative purposes only and is not intended to be limiting. For example, example process 2500 may be performed by a first STA (such as STA 1611). Example process 2500 may be performed by a first STA having multi-link capability (i.e., including a multi-link device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a receiving STA receiving data transmission from a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link.

[0254] like Figure 25 As shown, process 2500 may include: in step 2510, a first STA receives a first MU-RTS trigger frame requesting data transmission from a second STA via a first link to the first STA via the first link, and a second MU-RTS trigger frame requesting data transmission from the second STA via the second link to the first STA via the second link. In one embodiment, the first MU-RTS trigger frame may include an indication of the second link. In one embodiment, the indication of the second link in the first MU-RTS trigger frame may instruct the second STA that the second MU-RTS trigger frame sent via the second link requests the transmission of the same data as the first MU-RTS trigger frame sent via the first link.

[0255] Similarly, in this embodiment, the second MU-RTS trigger frame may include an indication of the first link. In one embodiment, the indication of the first link in the second MU-RTS trigger frame may instruct the second STA to request the transmission of the same data as the second MU-RTS trigger frame transmitted via the first link.

[0256] In another embodiment, the first MU-RTS trigger frame or the second MU-RTS trigger frame may include an indication of a CTS response option for use by the second STA. In one embodiment, the CTS response option may include the second STA responding to one of the first MU-RTS trigger frame or the second MU-RTS trigger frame. In another embodiment, the CTS response option may include the second STA responding to both the first and second MU-RTS trigger frames.

[0257] In step 2520, process 2500 may include: discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame including an indication of the first link. In one embodiment, discarding the first MU-RTS trigger frame may include responding to the first MU-RTS trigger frame without transmitting the second CTS frame via the first link.

[0258] In step 2530, process 2500 may include: in response to a second MU-RTS trigger frame, a first STA sending a first CTS frame to a second STA via a second link. In one embodiment, process 2500 may further include the first STA receiving a data frame including the data from the second STA via the second link. 1. A method comprising: A first request frame is sent by a first wireless device to a second wireless device via a first link, requesting the transmission of first data to the second wireless device via the first link; and Based on the fact that the first wireless device has not received the first response frame from the second wireless device within the time period from the transmission of the first request frame and the first data includes low-latency services, the first wireless device sends a second request frame to the second wireless device via the second link, requesting the second wireless device to send the first data via the second link.

[0259] One method includes: a first request frame sent by a first wireless device to a second wireless device via a first link, requesting the transmission of first data to the second wireless device via the first link; and a second request frame sent by the first wireless device to the second wireless device via a second link, based on the first wireless device not receiving a first response frame from the second wireless device within a time period from the transmission of the first request frame and the first data comprising low-latency services. In this method, the first wireless device may receive a second response frame from the second wireless device via the second link in response to the second request frame; and the first wireless device may send the first data to the second wireless device via the second link.

[0260] In this method, the first wireless device may receive a second response frame from the second wireless device via the second link in response to the second request frame, and the second wireless device may send the first data to the first wireless device via the second link.

[0261] In this method, the time period can be shorter than the response timeout interval.

[0262] The method may include a third request frame from the first wireless device to the second wireless device via the first link, requesting the first data to be sent via the first link to the second wireless device.

[0263] In this method, the third request frame may overlap with the second request frame.

[0264] In this method, the time period can be greater than or equal to the response timeout interval.

[0265] In this method, the second request frame and the third request frame may include MU-RTS trigger frames.

[0266] In this method, the first wireless device may receive a second response frame from the second wireless device via the second link in response to a second request frame.

[0267] In this method, the first wireless device may receive a third response frame from the second wireless device via a first link in response to a third request frame.

[0268] The method may include: a first wireless device receiving data for transmission to a second wireless device based on data including low-latency services; the first wireless device sending a first multi-user request to transmit (MU-RTS) trigger frame to the second wireless device via a first link, the first MU-RTS trigger frame requesting data transmission to the second wireless device via the first link; and the first wireless device sending a second MU-RTS trigger frame to the second wireless device via a second link, the second MU-RTS trigger frame requesting data transmission to the second wireless device via the second link.

[0269] In this method, in response to a second MU-RTS trigger frame, the first wireless device can receive a first response frame from the second wireless device via the second link.

[0270] The method may include: receiving a first multi-user request transmission (MU-RTS) trigger frame from a second wireless device via a first link, requesting the first wireless device to transmit data via the first link; and a second MU-RTS trigger frame requesting the first wireless device to transmit data via the second link; discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame including an indication of the first link; and the first wireless device transmitting a first response frame to the second wireless device via the second link in response to the second MU-RTS trigger frame.

[0271] In this method, discarding the first MU-RTS trigger frame may include responding to the first MU-RTS trigger frame without sending a second response frame via the first link.

[0272] In this method, the first wireless device can send a data frame containing data to the second wireless device via the second link.

[0273] In this method, the first MU-RTS trigger frame may include an indication of the second link.

[0274] In this method, the indication of the second link in the first MU-RTS trigger frame can indicate to the second wireless device that the second MU-RTS trigger frame sent via the second link requests the transmission of the same data as the first MU-RTS trigger frame sent via the first link.

[0275] In this method, the second MU-RTS trigger frame may include an indication of the first link.

[0276] In this method, the indication of the first link in the second MU-RTS trigger frame can indicate to the second wireless device that the first MU-RTS trigger frame sent via the first link requests the transmission of the same data as the second MU-RTS trigger frame sent via the second link.

[0277] In this method, the first MU-RTS trigger frame or the second MU-RTS trigger frame may include an indication of a CTS response option for use by a second wireless device.

[0278] In this method, the CTS response option may include a second wireless device responding to either a first MU-RTS trigger frame or a second MU-RTS trigger frame.

[0279] In this method, the CTS response option may include a second wireless device responding to a first MU-RTS trigger frame and a second MU-RTS trigger frame.

[0280] In this method, the request frame can be a Request to Send (RTS) frame, and the response frame can be a Clear to Send (CTS) frame.

[0281] When acting as a first wireless device (wireless device), there is a device configured to perform operations including: sending a first request frame to a second wireless device via a first link requesting the transmission of first data to the second wireless device via the first link; and sending a second request frame to the second wireless device via the second link requesting the transmission of the first data to the second wireless device based on the fact that no first response frame has been received from the second wireless device within a time period from the transmission of the first request frame and the first data includes low-latency services.

[0282] When acting as a first wireless device, there exists a device configured to perform the following operations: sending a first request frame via a first link to a second wireless device requesting the transmission of first data to the second wireless device via the first link; and sending a second request frame via a second link to the second wireless device requesting the transmission of the first data to the second wireless device based on the fact that a first response frame has not been received from the second wireless device within a time period from the transmission of the first request frame and the first data includes low-latency services.

[0283] When acting as a first wireless device, there is a device configured to perform the following operations: receiving data for transmission to a second wireless device based on data including low-latency services; sending a first multi-user request transmission (MU-RTS) trigger frame to the second wireless device via a first link; requesting data transmission from the second wireless device via the first link; and requesting data transmission from the second wireless device via the second link.

[0284] When acting as a first wireless device, there exists a device configured to perform the following operations: receiving a first Multi-User Request Transmission (MU-RTS) trigger frame from a second wireless device via a first link, the first MU-RTS trigger frame requesting data transmission to the device via the first link; receiving a second MU-RTS trigger frame from the second wireless device via a second link, the second MU-RTS trigger frame requesting data transmission to the device via the second link; discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame including an indication of the first link; and transmitting a first response frame to the second wireless device via the second link in response to the second MU-RTS trigger frame.

[0285] The wireless device may be a station (STA) according to IEEE 802.11.

[0286] In the device, the request frame may be a Request to Send (RTS) frame, and the response frame may be a Clear to Send (CTS) frame.

[0287] There exists a wireless network that includes multiple devices as described above.

[0288] There exists a computer program product stored on a computer-readable medium and configured to perform the aforementioned methods when a computing device is running.

Claims

1. A method comprising: A first request frame is sent from a first wireless device to a second wireless device via a first link, the first request frame requesting the transmission of first data to the second wireless device via the first link; as well as Based on the fact that the first wireless device has not received the first response frame from the second wireless device within the time period from the transmission of the first request frame and the first data includes low-latency services, the first wireless device sends a second request frame to the second wireless device via the second link. The second request frame requests the transmission of the first data to the second wireless device via the second link.

2. The method according to claim 1, comprising: In response to the second request frame, the first wireless device receives a second response frame from the second wireless device via the second link; And the first data is sent from the first wireless device to the second wireless device via the second link.

3. The method according to any one of claims 1-2, further comprising: In response to the second request frame, the first wireless device receives a second response frame from the second wireless device via the second link.

4. The method according to any one of claims 1-3, further comprising: The first data is transmitted from the second wireless device to the first wireless device via the second link.

5. The method according to any one of claims 1-4, wherein, The time period is shorter than the response timeout interval.

6. The method according to any one of claims 1-5, further comprising: The first wireless device sends a third request frame to the second wireless device via the first link, the third request frame requesting the transmission of the first data to the second wireless device via the first link.

7. The method according to claim 6, wherein, The third request frame overlaps with the second request frame.

8. The method according to any one of claims 6-7, wherein, The time period is greater than or equal to the response timeout interval.

9. The method according to any one of claims 6-8, wherein, The second request frame and the third request frame include MU-RTS trigger frames.

10. The method according to any one of claims 6-9, further comprising: The first wireless device receives a second response frame from the second wireless device in response to the second request frame via the second link.

11. The method of claim 10, further comprising: The first wireless device receives a third response frame in response to the third request frame from the second wireless device via the first link.

12. A method comprising: The first wireless device receives data intended for transmission to the second wireless device; Based on the fact that the data includes low-latency services, the first wireless device sends the following items to the second wireless device: A first multi-user request transmission (MU-RTS) trigger frame is sent via the first link, the first MU-RTS trigger frame requesting the transmission of the data to the second wireless device via the first link; as well as A second MU-RTS trigger frame is sent via the second link, and the second MU-RTS trigger frame requests the transmission of the data to the second wireless device via the second link.

13. The method of claim 12, further comprising: The first wireless device receives a first response frame from the second wireless device via the second link in response to the second MU-RTS trigger frame.

14. A method comprising: The first wireless device (wireless device) receives the following from the second wireless device: A first multi-user request transmission (MU-RTS) trigger frame is received via a first link, the first MU-RTS trigger frame requesting data to be transmitted to the first wireless device via the first link; as well as A second MU-RTS trigger frame is received via a second link, the second MU-RTS trigger frame requesting the transmission of the data to the first wireless device via the second link; and The first MU-RTS trigger frame is discarded because it includes an indication of the first link. as well as In response to the second MU-RTS trigger frame, the first wireless device sends a first response frame to the second wireless device via the second link.

15. The method according to claim 14, wherein, Discarding the first MU-RTS trigger frame includes: responding to the first MU-RTS trigger frame without sending a second response frame via the first link.

16. The method according to any one of claims 14 or 15, further comprising: The first wireless device sends a data frame containing the data to the second wireless device via the second link.

17. The method according to any one of claims 14-16, wherein, The first MU-RTS trigger frame includes an indication of the second link.

18. The method according to claim 17, wherein, The indication of the second link in the first MU-RTS trigger frame indicates to the second wireless device that the second MU-RTS trigger frame sent via the second link requests the transmission of the same data as the first MU-RTS trigger frame sent via the first link.

19. The method according to any one of claims 14-18, wherein, The second MU-RTS trigger frame includes an indication of the first link.

20. The method according to claim 19, wherein, The indication to the first link in the second MU-RTS trigger frame indicates to the second wireless device that the first MU-RTS trigger frame sent via the first link requests the transmission of the same data as the second MU-RTS trigger frame sent via the second link.

21. The method according to any one of claims 14-20, wherein, The first MU-RTS trigger frame or the second MU-RTS trigger frame includes an indication of a CTS response option for use by the second wireless device.

22. The method according to claim 21, wherein, The CTS response option includes the second wireless device responding to either the first MU-RTS trigger frame or the second MU-RTS trigger frame.

23. The method according to any one of claims 21 or 22, wherein, The CTS response options include the second wireless device responding to the first MU-RTS trigger frame and the second MU-RTS trigger frame.

24. The method according to any of the preceding claims, wherein, The request frame is a Request to Send (RTS) frame, and the response frame is a Clear to Send (CTS) frame.

25. A device, when acting as a first wireless device (wireless device), is configured to perform operations including: Sending a first request frame via the first link to the second wireless device requesting the transmission of first data via the first link; and Based on the fact that no first response frame has been received from the second wireless device within the time period from the transmission of the first request frame and the first data includes low-latency services, a second request frame is sent to the second wireless device via the second link requesting the transmission of the first data to the second wireless device via the second link.

26. A device, when acting as a first wireless device, is configured to perform operations including: Sending a first request frame via the first link to the second wireless device requesting the transmission of first data via the first link; and Based on the fact that no first response frame has been received from the second wireless device within the time period from the transmission of the first request frame and the first data includes low-latency services, a second request frame is sent to the second wireless device via the second link requesting the transmission of the first data to the second wireless device via the second link.

27. A device, when acting as a first wireless device, is configured to perform operations including: Receive data for transmission to a second wireless device; Based on the data including low-latency services, the following items are sent to the second wireless device: A first Multi-User Request Transmission (MU-RTS) trigger frame is sent via the first link, the first MU-RTS trigger frame requesting the transmission of the data to the second wireless device via the first link; and A second MU-RTS trigger frame is sent via the second link, and the second MU-RTS trigger frame requests the transmission of the data to the second wireless device via the second link.

28. A device, when acting as a first wireless device, is configured to perform operations including: Receive the following from the second wireless device: A first multi-user request transmission (MU-RTS) trigger frame is received via a first link, the first MU-RTS trigger frame requesting data to be transmitted to the device via the first link; as well as A second MU-RTS trigger frame is received via a second link, the second MU-RTS trigger frame requesting the transmission of the data to the device via the second link; and The first MU-RTS trigger frame is discarded because it includes an indication of the first link. as well as In response to the second MU-RTS trigger frame, a first response frame is sent to the second wireless device via the second link.

29. The device according to any one of claims 25-28, wherein, The wireless device is a Station (STA) based on IEEE 802.

11.

30. The device according to any one of claims 25-29, wherein, The request frame is a Request to Send (RTS) frame, and the response frame is a Clear to Send (CTS) frame.

31. A wireless network comprising a plurality of devices according to any one of claims 25-30.

32. A computer program product stored on a computer-readable medium and configured, when a computing device is operated, to perform the method of any one of claims 1-24.

Images