Multilink protection for low-latency communication

Abstract

A wireless device with multilink capabilities (a multilink device or "MLD") may attempt to transmit low-latency data on a given link. A receiving device may find that the link is occupied by another transmission. Methods, devices, and systems are provided. An exemplary method includes the steps of: first wireless device transmitting a first request frame to second wireless device via a first link, requesting that first data be transmitted to second wireless device via a first link; and first wireless device transmitting a second request frame to second wireless device via a second link, requesting that first wireless device transmit the first data to second wireless device via a second link, based on the first wireless device not receiving a response frame from second wireless device within a period of time since transmitting the first request frame and the first data consisting of low-latency traffic.

Description

Technical Field

[0001] The present invention relates to a wireless network, and more particularly to a local area wireless network using technologies such as the IEEE 802.11 standard, but is not limited thereto.

Background Art

[0002] Modern wireless networks are often deployed densely. Devices face many competitions for medium access. When there are requirements for the time taken to transmit data ("urgent data" or so-called "low-latency data"), the problem of competition for medium access becomes more serious.

Summary of the Invention

Problems to be Solved by the Invention

[0003] The inventors have noticed that many problems occur when multi-link operation (MLO) is used. A wireless device with a multi-link function (a multi-link device or "MLD") may attempt to transmit low-latency data over a certain link. It starts by asking the intended recipient device (the second device) whether it is possible. The second device may find that the link is occupied by another transmission (for example, in the case of 802.11, from another overlapping network known as an overlapping basic service set, i.e., OBSS). In this case, the second device does not send a positive acknowledgment to the request from the first device, and the first device is forced to wait for the request and then retransmit, resulting in wasted time. Alternatively, a device may transmit data (not necessarily low-latency data) over multiple links, which may also prevent another device (such as a device within an OBSS) from transmitting something like low-latency data.

[0004] As an attempt to improve the functionality of wireless networks, methods, devices, systems, and computer program products as defined in the attached claims are provided. [Means for solving the problem]

[0005] In one embodiment, a method is provided, which includes the steps of: first wireless device transmitting a first request frame to second wireless device via a first link, requesting that first data be transmitted to second wireless device via a first link; and first wireless device transmitting a second request frame to second wireless device via a second link, requesting that first wireless device transmit first data to second wireless device via a second link, based on the first wireless device not receiving a response frame from second wireless device within a certain period of time from the transmission of the first request frame and the first data consisting of low-latency traffic.

[0006] In one embodiment, a method is provided, which includes the steps of: first wireless device transmitting a first request frame to second wireless device via a first link, requesting that first data be transmitted to second wireless device via a first link; and first wireless device transmitting a second request frame to second wireless device via a second link, requesting that first wireless device transmit first data to second wireless device via a second link, based on the first wireless device not receiving a response frame from second wireless device within a certain period of time from the transmission of the first request frame and the first data consisting of low-latency traffic.

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

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

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

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

[0011] In one embodiment, a method is provided which includes the steps of: a first wireless device receiving data to transmit to a second wireless device; the first wireless device transmitting a first Multi-User Transmit Request (MU-RTS) trigger frame to the second wireless device via the first link, on the basis that the data consists of low-latency traffic; and the first wireless device transmitting a second MU-RTS trigger frame to the second wireless device via the second link, on the basis that the data consists of low-latency traffic.

[0012] In one embodiment, a method is provided. This method includes the steps of: first, receiving from a second wireless device via the first link a first multi-user transmission request (MU-RTS) trigger frame requesting data to be transmitted to a first wireless device via a first link; first, receiving from a second wireless device via the second link a 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 on the basis that the second MU-RTS trigger frame includes instructions for the first link; and first, transmitting a first response frame 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 permission to send (CTS) frame.

[0014] In one embodiment, a device is provided which, when functioning as a first wireless device (wireless device), performs operations including sending a first request frame to the second wireless device via a first link, requesting that the second wireless device send first data via a first link; and, based on the fact that the second wireless device has not received a first response frame from the second wireless device within a certain period of time since the transmission of the first request frame and that the first data consists of low-latency traffic, sending a second request frame to the second wireless device via a second link, requesting that the second wireless device send first data via a second link.

[0015] In one embodiment, a device is provided which, when functioning as a first wireless device, performs an operation that includes sending a first request frame to the second wireless device via a first link, requesting that the second wireless device transmit first data via a first link, and, based on the fact that the second wireless device has not received a first response frame from the second wireless device within a certain period of time since the transmission of the first request frame and that the first data consists of low-latency traffic, sending a second request frame to the second wireless device via a second link, requesting that the second wireless device transmit first data via a second link.

[0016] In one embodiment, a device is provided, which, when functioning as a first wireless device, receives data to be transmitted to a second wireless device. Based on the fact that the data consists of low-latency traffic, the system performs an operation that includes sending a first Multi-User Transmit Request (MU-RTS) trigger frame to the second wireless device via the first link, requesting the data to be transmitted to the second wireless device via the first link, and sending a second MU-RTS trigger frame to the second wireless device via the second link, requesting the data to be transmitted to the second wireless device via the second link.

[0017] In one embodiment, a device is provided which, when functioning as a first wireless device, performs an operation that includes: sending a first Multi-User Transmit Request (MU-RTS) trigger frame from a second wireless device over a first link requesting data to be sent to the device over a first link; sending a second MU-RTS trigger frame from a second wireless device over a second link requesting data to be sent to the device over a second link; discarding the first MU-RTS trigger frame based on the second MU-RTS trigger frame containing instructions for the first link; and sending a first response frame over the second link to the second wireless device in response to the second MU-RTS trigger frame.

[0018] In one embodiment, the wireless device is an IEEE 802.11 compliant station (STA).

[0019] In one embodiment, a wireless network comprising multiple devices described herein is provided.

[0020] In one embodiment, a computer program product is provided which is stored on a computer-readable medium and performs the method described herein when a computing device is running.

[0021] When used herein, the term "station" should be understood to apply to any wireless device unless otherwise specified, and not to a station compliant with 802.11. [Brief explanation of the drawing]

[0022] Several examples of various embodiments of this disclosure are described herein with reference to the drawings.

[0023] [Figure 1] Figure 1 shows an example of a wireless communication network that can implement the embodiments of this disclosure. [Figure 2] FIG. 2 is a block diagram showing an example of an implementation form of a station (STA) and an access point (AP). [Figure 3] FIG. 3 shows an example of a media access control (MAC) frame format. [Figure 4] FIG. 4 shows an example of a quality of service (QoS) null frame indicating buffer status information. [Figure 5] FIG. 5 shows an example of a format of a physical layer (PHY) protocol data unit (PPDU). [Figure 6] FIG. 6 shows an example including buffer status reporting by a STA, scheduling of uplink multi-user (MU) transmission by an AP, and transmission of scheduled uplink transmission by a STA. [Figure 7] FIG. 7 shows an example of a reference model of a multi-link device (MLD). [Figure 8] FIG. 8 shows an example of an AP MLD and a non-AP MLD associated therewith. [Figure 9] FIG. 9 shows an example of multi-link setup between an AP MLD and a non-AP MLD. [Figure 10] FIG. 10 shows an example of traffic identifier (TID)-to-link mapping in a multi-link communication environment. [Figure 11] FIG. 11 shows an example of a request-to-send (RTS) / clear-to-send (CTS) procedure. [Figure 12] FIG. 12 shows an example of an existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange. [Figure 13] FIG. 13 shows another example of an existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange. [Figure 14] FIG. 14 shows another example of an existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange. [Figure 15] Figure 15 shows an example of a process according to an embodiment. [Figure 16] Figure 16 shows an example of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. [Figure 17] Figure 17 shows an example of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. [Figure 18] Figure 18 shows an example of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. [Figure 19] Figure 19 shows an example of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. [Figure 20] Figure 20 shows an example of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. [Figure 21] Figure 21 shows an example of a common information field for a basic multilink element according to an embodiment. [Figure 22] Figure 22 shows an example of a multi-user request-to-send (MU-RTS) trigger frame according to the embodiment. [Figure 23] Figure 23 shows an example of a process according to an embodiment. [Figure 24] Figure 24 shows another process example according to an embodiment. [Figure 25] Figure 25 shows another process example according to an embodiment. [Modes for carrying out the invention]

[0024] In this disclosure and in the figures, the same reference numerals indicate the same elements.

[0025] This disclosure presents various embodiments as examples of how the disclosed technology may be implemented and / or how it may be practiced in environments and scenarios. It will be apparent to those skilled in the art that various modifications can be made to the form and details without departing from the scope. After reading the description, it will be apparent to those skilled in the art how to implement alternative embodiments. These embodiments are not limited by any of the exemplary embodiments described. Exemplary embodiments of this disclosure are described with reference to the accompanying drawings. Limitations, features, and / or elements of the disclosed embodiments may be combined to create further embodiments within the scope of the disclosure. Figures highlighting features and benefits are presented for illustrative purposes only. The disclosed architecture is sufficiently flexible and configurable to be used in ways other than those shown. For example, actions listed in any flowchart may be reordered or used only at will in some embodiments.

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

[0027] In this disclosure, “a,” “an,” and similar phrases should be interpreted as “at least one” and “one or more.” Similarly, terms ending in 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 one example of a number of appropriate possibilities, which may or may not be adopted by one or more of the various embodiments. The terms “comprises” and “consists of,” as used herein, enumerate one or more components of the element being described. The term “comprises” is interchangeable with “includes” and does not preclude the inclusion of components not enumerated in the element being described. In contrast, “consists of” provides a complete enumeration of one or more components of the element being described. As used herein, the term "based on" can be interpreted as "based at least partially" rather than, for example, "based solely on." As used herein, the term "and / or" represents 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.

[0028] If A and C 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 similarly, "based at least on") indicates that the phrase following the term "based on" is one example of many appropriate possibilities, which may or may not be adopted by one or more of the various embodiments. The phrase "in response to" (or similarly, "in response at least to") indicates that the phrase following "in response to" is one example of many appropriate possibilities, which may or may not be adopted in one or more of the various embodiments. The phrase "depending on" (or similarly, "depending at least to") indicates that the phrase following "depending on" is one example of many appropriate possibilities, which may or may not be adopted in one or more of the various embodiments. The phrase "to adopt / use" (or similarly, "to adopt / use") indicates that the phrase following "to adopt / use" is one example of many appropriate possibilities, which may or may not be adopted in one or more of the various embodiments.

[0029] The term "configured" can relate to the capabilities of a device, regardless of whether the device is operational or inoperable. "Configured" can refer to specific settings within a device that affect its operational characteristics, regardless of whether the device is operational or inoperable. In other words, hardware, software, firmware, registers, memory values, etc., can be "configured" within a device to provide it with specific characteristics, regardless of whether the device is operational or inoperable. Terms such as "a control message that causes a device to..." mean that a control message contains parameters that can be used to configure specific characteristics or to perform specific actions on the device, regardless of whether the device is operational or inoperable.

[0030] In this disclosure, a parameter (or similarly referred to as a “field” or information element: IE) may contain one or more information objects, and an information object may contain one or more other objects. For example, suppose parameter (IE)N contains parameter (IE)M, parameter (IE)M contains parameter (IE)K, and parameter (IE)K contains parameter (information element)J. Then, for example, N contains K, and N contains J. In one embodiment, when one or more messages / frames contain multiple parameters, it means that some of the multiple parameters are present in at least one of the one or more messages / frames, but not in each of the one or more messages / frames.

[0031] Many of the features presented are described as optional using "may" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly list each and every substitution that can be obtained by choosing from the set of optional features. This disclosure should be interpreted as explicitly disclosing all such substitutions. For example, a system described as having three optional features can be materialized in seven ways: namely, with just one of the three possible features, with any two of the three possible features, or with three of the three possible features.

[0032] 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 defined interfaces with other elements. Modules described in this disclosure can be implemented in behaviorally equivalent hardware, software combined with hardware, firmware, wetware (e.g., hardware with biological elements), or combinations thereof. For example, a module can be implemented as a software routine written in a computer language configured to run on a hardware machine (e.g., C, C++, Fortran, Java®, Basic, Matlab), or as a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. Modules can also be implemented using physical hardware incorporating 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 assembly, C, C++, etc. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs) such as VHSIC (VHDL) or Verilog, which configure connections between internal hardware modules with fewer functions on the programmable device. These techniques are often used in combination to achieve the results of functional modules.

[0033] Figure 1 shows an example of a wireless communication network that can implement the embodiments of this disclosure.

[0034] As shown in Figure 1, an example of a wireless communication network includes an IEEE 802.11 (WLAN) infrastructure network 102. The WLAN infrastructure network 102 includes one or more basic service sets (BSSs) 110, 120 and a distributed system (DS) 130.

[0035] BSS110-1 and 110-2 each include a set of access points (AP or AP STA) and at least one station (STA or non-AP STA). For example, BSS110-1 includes AP104-1 and STA106-1, and BSS110-2 includes AP104-2 and STA106-2 and 106-3. The APs and at least one STA within the BSS perform association procedures to communicate with each other.

[0036] The DS130 connects BSS110-1 and BSS110-2. Therefore, the DS130 enables Extended Service Set (ESS) 150. In ESS150, AP104-1 and AP104-2 are connected via the DS130 and have the same Service Set Identifier (SSID).

[0037] The WLAN infrastructure network 102 can be connected to one or more external networks. For example, as shown in Figure 1, the WLAN infrastructure network 102 can be connected to another network 108 (e.g., 802.X) via a portal 140. The portal 140 acts as a bridge connecting the DS130 of the WLAN infrastructure network 102 to the other network 108.

[0038] The example wireless communication network shown in Figure 1 further includes one or more ad-hoc networks or independent BSSs (IBSSs). An ad-hoc network or IBSS is a network containing multiple STAs that are within each other's communication range. Multiple STAs can communicate with each other using direct peer-to-peer communication (i.e., not via APs).

[0039] For example, in Figure 1, STA106-4, 106-5, and 106-6 form the first IBSS112-1. Similarly, STA106-7 and 106-8 form the second IBSS112-2. Since IBSS does not include APs, it does not include centralized management entities. Rather, STAs within IBSS are managed in a decentralized manner. The STAs that make up IBSS may be fixed or mobile.

[0040] An STA as a designated functional medium includes a media access control (MAC) layer compliant with the IEEE 802.11 standard. A physical layer interface for wireless media can be used between an AP and a non-AP station (STA). An STA may also be referred to using a variety of other terms, including mobile terminal, wireless device, wireless transmit / receive unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" is used to describe an STA participating in uplink multi-user multi-input, multi-output (MU MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmissions.

[0041] A Physical Layer (PHY) Protocol Data Unit (PPDU) is a composite structure that includes a PHY preamble and a payload in the form of a PLCP Service Data Unit (PSDU). For example, a PSDU includes a PHY Convergence Protocol (PLCP) preamble and a header and / or one or more MAC Protocol Data Units (MPDUs). The information provided in the PHY preamble is used by the receiving device to decode the subsequent data in the PSDU. When a PPDU is transmitted over bonded channels (channels formed by channel bonding), the preamble fields are duplicated and transmitted to each of the multiple component channels. A PHY preamble can contain both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble is used, among several uses, particularly for packet detection, automatic gain control, and channel estimation. The legacy preamble is also commonly used to maintain compatibility with legacy devices. The format, coding, and information provided in the non-legacy portion of the preamble are based on the specific IEEE 802.11 protocol used for transmitting the payload.

[0042] A frequency band includes one or more subbands or frequency channels. For example, a PPDU compliant with IEEE 802.11n, 802.11ac, 802.11ax, and / or 802.11be modification standards is transmitted in the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each of which is divided into multiple 20 MHz channels. A PPDU can be transmitted over physical channels with a minimum bandwidth of 20 MHz. Larger channels can be formed by channel bonding. For example, a PPDU can be transmitted over physical channels with bandwidths of 40 MHz, 80 MHz, 160 MHz, or 520 MHz by bonding multiple 20 MHz bands.

[0043] Figure 2 is a block diagram showing example implementation configurations of STA210 and AP260. As shown in Figure 2, STA210 includes at least one processor 220, memory 230, and at least one transceiver 240. AP260 includes at least one processor 270, memory 280, and at least one transceiver 290. The processors 220 / 270 are operably connected to the memory 230 / 280 and / or the transceivers 240 / 290.

[0044] The processor 220 / 270 implements the functions of the PHY layer, MAC layer, and / or Logic Link Control (LLC) layer of the corresponding device (STA210 or AP260). The processor 220 / 270 includes one or more processors and / or one or more controllers. The one or more processors and / or one or more controllers 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), a logic circuit, or a chipset.

[0045] Memory 230 / 280 includes read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage devices. Memory 230 / 280 may include non-temporary computer-readable media. Memory 230 / 280 stores computer program instructions or code that can be executed by the processor 220 / 270 to perform one or more of the operations / embodiments described herein. Memory 230 / 280 may be implemented (or located) within the processor 220 / 270 or outside the processor 220 / 270. Memory 230 / 280 can be operably connected to the processor 220 / 270 by various means known in the art.

[0046] Transceivers 240 / 290 transmit and receive radio signals. In one embodiment, transceivers 240 / 290 implement the PHY layer of the corresponding device (STA210 or AP260). In one embodiment, STA210 and / or AP260 are multilink devices (MLDs), which are devices capable of operating on multiple links as defined in the IEEE 802.11 standard. Therefore, STA210 and / or AP260 each implement multiple PHY layers. Multiple PHY layers can be implemented using one or more transceivers 240 / 290.

[0047] Figure 3 shows an example of MAC frame format. During operation, the STA constructs a subset of MAC frames for transmission and decodes a subset of received MAC frames during verification. The specific subset of frames that the STA constructs and / or decodes is determined by the capabilities supported by the STA. The STA uses the frame check sequence (FCS) contained within the frame to verify the received MAC frames and interprets specific fields from the MAC header of all frames.

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

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

[0050] The frame control field includes subfields for protocol version, type, subtype, "To DS", "From DS", "More Fragments", retry, power management, "More Data", protected frame, and +THC.

[0051] The protocol version subfield remains constant in size and placement across all revisions of the IEEE 802.11 standard. For MAC frames, the protocol version subfield has a value of 0.

[0052] The type subfield and subtype subfield both identify the function of a MAC frame. There are three types of frames: control, data, and management. Each frame type has several defined subtypes. The bits within the subtype subfield are used to indicate a specific modification of the basic data frame (subtype 0). For example, in a data frame, the most significant bit (MSB) of the subtype subfield, i.e., 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. This is a data frame that includes a QoS control field in the MAC header. The second MSB of the subtype field, i.e., 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.

[0053] The "To DS" subfield indicates whether the data frame is destined for a distributed system (DS). The "From DS" subfield indicates whether the data frame originates from a DS.

[0054] The "More Fragments" subfield is set to 1 for all data frames or management frames that have another fragment following a MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) transmitted by the MAC frame. The "More Fragments" subfield is set to 0 for all other frames in which the "More Fragments" subfield exists.

[0055] The retry subfield is set to 1 for any data frame or administration frame that is a retransmission of a previous frame. The retry subfield is set to 0 for all other frames in which the retry subfield exists. The receiving STA uses this instruction to assist in the process of filtering out duplicate frames. These rules do not apply to frames sent from the STA under a block agreement.

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

[0057] The "More Data" subfield indicates to an STA in Power Save (PS) mode that bufferable units (BUs) are buffered for that STA at the AP. The "More Data" subfield is valid in individually addressed data frames or management frames sent from the AP to an STA in PS mode. The "More Data" subfield is set to 1 to indicate that there is at least one additional BU buffered for that STA.

[0058] The protected frame subfield is set to 1 if the frame body field contains information processed by the cryptographic encapsulation algorithm.

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

[0060] The Duration / ID field in the MAC header contains various values ​​depending on the frame type and subtype, as well as the QoS capabilities of the transmitting STA. For example, in a control frame of the Power Save Polling (PS-Poll) subtype, the Duration / ID field carries the Association Identifier (AID) of the STA that transmitted the frame in its 14th least significant bit (LSB), and the two most significant bits (MSB) are set to 1. In other frames transmitted by the STA, the Duration / ID field contains a Duration value (in microseconds) that the receiver uses to update the Network Allocation Vector (NAV). The NAV is a counter that indicates to the STA how long it must withhold access to the shared medium.

[0061] The MAC frame format has up to four address fields. These address fields are used to identify the Basic Service Set Identifier (BSSID), Source Address (SA), Destination Address (DA), Sending Address (TA), and Receiving Address (RA). Some frames may not contain all of these address fields. The usage of a particular address field is determined by its relative position within the MAC header, regardless of the type of address present in that field. Specifically, the field in address 1 always identifies the frame's intended recipient, and the field in address 2, if present, always identifies the frame's sender.

[0062] The sequence control field contains two subfields: the sequence number subfield and the fragment number subfield. The sequence number subfield for a data frame indicates the sequence number of the MSDU (if not present in an aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield for a management frame indicates the sequence number of the frame. The fragment number subfield indicates the number of each fragment in the MSDU or MMPDU. The fragment number is set to 0 for the first or only fragment of an MSDU or MMPDU and increments by 1 for each subsequent fragment of that MSDU or MMPDU. For MAC protocol data units (MPDUs) containing an A-MSDU, or MPDUs containing an unfragmented MSDU or MMPDU, the fragment number is set to 0. The fragment number remains constant for all retransmissions of the fragment.

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

[0064] The HT control field is present in QoS data frames, QoS null frames, and management frames, determined by the +HTC subfield of the frame control field.

[0065] The frame body field is a variable-length field containing information specific to each frame type and subtype. A frame body contains one or more MSDUs or MMPDUs. The minimum length of a frame body is 0 octets.

[0066] The FCS field contains a 32-bit cyclic redundancy check (CRC) code. The FCS field value is calculated across all fields in the MAC header field and the frame body fields.

[0067] Figure 4 shows an example of a QoS null frame indicating buffer status information. A QoS null frame refers to a QoS data frame with an empty frame body. A QoS null frame includes a QoS control field and an optional HT control field which may include a Buffer Status Report (BSR) control subfield. The QoS null frame indicating buffer status information is sent from the STA to the AP.

[0068] The QoS control fields include the Traffic Identifier (TID) subfield, the ACK Policy Indicator subfield, and the Queue Size subfield (or the Requested Transmit Opportunity (TXOP) duration subfield).

[0069] The TID subfield identifies the TC or TS of the traffic for which TXOP is being requested, based on the settings in the Requested TXOP Duration subfield or Queue Size subfield. The encoding of the TID subfield is determined by the access policy (for example, an acceptable value of 0-7 for an Extended Distributed Channel Access (EDCA) access policy to identify the user priority of either TC or TS).

[0070] The ACK policy indicator subfield, along with other information, identifies the acknowledgment policy that follows the delivery of the MPDU (e.g., normal ACK, implicit block ACK request, no ACK, block ACK, etc.).

[0071] The queue size subfield is an 8-bit field that indicates the amount of traffic buffered by the STA for a given TC or TS for transmission to the AP, identified by the recipient address of the frame containing the subfield. The queue size subfield is present in QoS null frames transmitted by the STA when bit 4 of the QoS control field is set to 1. The AP uses the information contained in the queue size subfield to determine the TXOP period allocated to the STA and the uplink (UL) resources allocated to the STA.

[0072] For frames sent by or to a non-HE STA, the following rules apply to the queue size value:

[0073] The queue size value is the approximate total size, expressed in units of 256 octets, of all MSDUs and A-MSDUs buffered in the STA (excluding MSDUs or A-MSDUs included in the current QoS data frame) within the distribution queue used for MSDUs and A-MSDUs that have a TID value equal to the value shown in the TID subfield of the QoS control field, rounded up to the nearest multiple of 256 octets.

[0074] A queue size value of 0 is used solely to indicate that there is no buffered traffic in the queue used for the specified TID.

[0075] For all sizes exceeding 64768 octets, a queue size value of 254 is used.

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

[0077] For frames sent from HE STA to HE AP, the following rules apply to the queue size value:

[0078] The queue size value QS is the approximate total size in octets of all MSDUs and A-MSDUs buffered in the STA (including MSDUs or A-MSDUs contained in the same PSDU as the frame containing the queue size subfield) within the delivery queue used for MSDUs and A-MSDUs that have a TID value equal to the value specified in the TID subfield of the QoS control field.

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

[0080] The STA obtains the queue size QS from the received QoS control field, which includes the scaling factor SF and the unscaled value UV, as follows: QS= If SF is 0, then 16 × UV, If SF is 1, then 1024 + 256 × UV, If SF is 2, then 17408 + 2048 × UV, If SF is 3 and UV is less than 62, then 148480 + 32768 × UV, If SF is 3 and UV is 62, then >2147328, If SF is 3 and UV is 63, it is either unspecified or unknown.

[0081] The Requested TXOP Duration subfield can be included instead of the Queue Size subfield and indicates the period in 32 microseconds (us) that the sending STA deems necessary for the next TXOP for the specified TID. The Requested TXOP Duration subfield is set to 0 to indicate that no TXOP is requested for the specified TID in the current Service Period (SP). The Requested TXOP Duration subfield is set to a non-zero value to indicate a Requested TXOP Duration in 32us increments, ranging from 32us to 8160us.

[0082] The HT control field includes a BSR control subfield containing buffer status information used for UL MU operations. The BSR control subfield is formed from the HT control field's Access Category Index (ACI) bitmap subfield, Delta TID subfield, ACI high subfield, scaling factor subfield, queue size high subfield, and queue size all subfield.

[0083] The ACI bitmap subfield indicates the access category (AC) for which the buffer status is reported (e.g., B0: Best Effort (AC_BE), B1: Background (AC_BK), B2: Video (AV_VI), B3: Audio (AC_VO), etc.). Each bit in the ACI bitmap subfield is set to 1 to indicate that the buffer status for the corresponding AC is included in the queue size all subfield; otherwise, it is set to 0, however, if the ACI bitmap subfield is 0 and the Delta TID subfield is 3, then the buffer status for all eight TIDs is included. The Delta TID subfield, along with the value of the ACI bitmap subfield, indicates the number of TIDs for which the STA is reporting the buffer status.

[0084] The ACI high subfield indicates the ACI of the AC, where the BSR is shown in the queue size high subfield. The mapping from ACI to AC is defined as the ACI value 0 mapping to AC_BE, the ACI value 1 mapping to AC_BK, the ACI value 2 mapping to AC_VI, and the ACI value 3 mapping to AC_VO. The scaling factor subfield indicates the unit SF of the queue size high subfield and queue size all subfield in octets.

[0085] The queue size high subfield indicates the amount of buffered traffic for AC, identified by the ACI high subfield, directed to the STA identified by the recipient address of the frame including the BSR control subfield, in SF octets.

[0086] The queue size all subfield indicates the amount of buffered traffic, in SF octets, for all ACs identified by the ACI bitmap subfield, directed to the STA identified by the recipient address of the frame, including the BSR control subfield.

[0087] The queue size values ​​for queue size high subfield and queue size all subfield are the sum of all MSDUs and A-MSDUs buffered in the STA (including MSDUs or A-MSDUs included in the same PSDU as the frame containing the BSR control subfield) within the delivery queue used for the MSDUs and A-MSDUs associated with the AC specified in the ACI high subfield and ACI bitmap subfield, respectively, rounded up to the nearest multiple of the SF octet.

[0088] A queue size value of 254 in the queue size high subfield and queue size all subfield indicates that the amount of buffered traffic is greater than 254 × SF octets. A queue size value of 255 in the queue size high subfield and queue size all subfield indicates that the amount of buffered traffic is unspecified or of unknown size. The queue size value of a QoS data frame containing fragments remains constant even if the amount of queued traffic changes as consecutive fragments are sent.

[0089] The MAC service provides peer entities with the ability to exchange MSDUs. To support this service, the local MAC forwards MSDUs to the peer MAC entity using an underlying PHY-level service. Such asynchronous MSDU forwarding is performed on a connectionless basis.

[0090] Figure 5 shows an example of the PPDU format. As shown in the figure, the PPDU includes the PHY preamble, PHY header, PSDU, tail bits, and padding bits.

[0091] A PSDU may contain one or more MPDUs, such as a QoS data frame, MMPDU, MAC control frame, or QoS null frame. When an MPDU carries a QoS data frame, the MPDU's frame body contains an MSDU or A-MSDU.

[0092] By default, MSDU forwarding is best-effort based; that is, there is no guarantee that the sent MSDU will be successfully delivered. However, the QoS facility uses a Traffic Identifier (TID) to specify differentiated services on a per-MSDU basis.

[0093] STA can differentiate MSDU delivery according to the designated traffic category (TC) or traffic stream (TS) of individual MSDUs. MAC sub-tier entities determine the user priority (UP) of an MSDU based on the TID value provided by the MSDU. The QoS facility supports eight UP values. The range of UP values ​​is 0 to 7, forming an ordered priority sequence where 1 is the lowest value, 7 is the highest value, and 0 is between 2 and 3.

[0094] MSDUs with a specific UP are considered to belong to the traffic category that has that UP. UPs are provided directly to each MSDU as UP parameters at the Media Access Control Service Access Point (MAC SAP). A-MPDU may contain MPDUs with different TID values.

[0095] The STA delivers Buffer Status Reports (BSRs) to assist the AP in allocating UL MU resources. The STA implicitly delivers BSRs in the QoS control field or BSR control subfield of any frame sent to the AP (unsolicited BSRs), or explicitly delivers BSRs in frames sent to the AP in response to a BSRP trigger frame (solicited BSRs).

[0096] 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, delta TID, high priority AC, and two queue sizes.

[0097] The STA reports to the AP, as defined below, the buffer status of transmitted QoS null frames and QoS data frames in the QoS control field, and the buffer status of transmitted QoS null frames, QoS data frames, and management frames in the BSR control subfield (if present).

[0098] The STA reports 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 null frame. The STA also sets the queue size subfield to 255 to indicate an unknown / unspecified queue size for that TID. The STA aggregates multiple QoS data frames or QoS null frames into an A-MPDU to report the queue sizes for different TIDs.

[0099] If the AP indicates that it supports receiving the BSR control subfield, the STA may report the buffer status in the BSR control subfield of the transmitted frame.

[0100] The High Efficiency (HE) STA reports 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 sets the queue size high subfield to 255 to indicate the unknown / unspecified queue size of that AC.

[0101] The HE STA reports the queue size of the AC, indicated by the ACI bitmap subfield in the queue size all subfield of the BSR control subfield. The STA sets the queue size all subfield to 255 to indicate the unknown / unspecified BSR of these ACs.

[0102] Figure 6 shows an example including STA reporting of buffer status, AP scheduling of uplink multi-user (MU) transmissions, and STA sending of scheduled uplink transmissions.

[0103] As shown in the diagram, the AP requests the buffer status from one or more relevant STAs (STA1 and STA2) by sending a Buffer Status Report Polling (BSRP) trigger frame. Upon receiving the BSRP trigger frame, STA1 and / or STA2 each generate a Trigger Base (TB) PPDU if the BSRP trigger frame contains the 12LSB of the STA's AID in the User Information field.

[0104] STA1 and / or STA2 each contain one or more QoS null frames in the TB PPDU. One or more QoS null frames may contain one or more QoS control fields or one or more BSR control subfields.

[0105] As mentioned above, the QoS control field includes a queue size subfield for the TID whose queue size the STA reports to the AP. For example, as shown in Figure 6, STA1 responds to a BSRP trigger frame from the AP by sending an A-MPDU containing multiple QoS null frames. Each QoS null frame has its respective QoS control field showing the queue size for its respective TID (e.g., TID0 and TID2). Similarly, STA2 responds to a BSRP trigger frame by sending an MPDU with a QoS null frame in its QoS control field showing the queue size for TID2.

[0106] The BSR control subfield includes a queue size all subfield, which indicates the queue size of the AC, as shown in the ACI bitmap subfield, and has the queue size that the STA reports to the AP if the AP indicates that it supports receiving the BSR control subfield. The STA sets the delta TID subfield, scaling factor subfield, ACI high subfield, and queue size high subfield of the BSR control subfield.

[0107] Upon receiving BSRs from STA1 and STA2, the AP sends a basic trigger frame to allocate UL MU resources to STA1 and STA2. In response, STA1 sends a TB PPDU containing QoS data frames with TID0 and TID2, and STA2 sends a TB PPDU containing one or more QoS data frames with TIDs. The AP acknowledges the TB PPDUs sent from STA1 and STA2 by sending a multi-STA block ACK frame.

[0108] Figure 7 shows an example of a reference model of a multilink device (MLD).

[0109] An MLD is an entity that can manage communications across multiple links. An MLD is a logical entity and has multiple liaison stations (STAs). An MLD may be an access point MLD (AP MLD), and the STAs associated with the MLD are AP STAs (or APs). An MLD may also be a non-access point MLD (non-AP MLD), and the STAs associated with the MLD are non-AP STAs (or STAs).

[0110] Depending on the functionality of both the communicating AP MLD and non-AP MLD, communication between different frequency bands / channels may or may not occur simultaneously.

[0111] As shown in Figure 7, the MLD has a single MAC service access point (MAC-SAP) to the LLC layer, which includes MAC data services. The MLD supports multiple MAC sublayers, coordinated by sublayer management entities (SMEs). Each AP STA (or non-AP STA) interacting with an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0112] The SME is responsible for coordinating the MAC sub-layer management entity (MLME) of the MLD's linked STA to maintain a single robust Security Network Association (RSNA) key management entity and a single IEEE 802.1X authenticator or supplicant for multilink operations.

[0113] The Multilink Operations (MLO) procedure allows a pair of MLDs to discover, synchronize, authenticate (deauthenticate), (re)associate, disassociate, and manage resources with each other over any common bandwidth or channel supported by both MLDs. The authenticator and MAC-SAP of an AP MLD can be identified by the same AP MLD MAC address. The supplicant and MAC-SAP of a non-AP MLD can be identified by the same non-AP MLD MAC address.

[0114] Figure 8 shows examples of AP MLDs and their associated non-AP MLDs.

[0115] As shown in the diagram, the AP MLD has two cooperative APs (AP1 and AP2), and the non-AP MLD has two cooperative STAs (STA1 and STA2). The AP MLD and the non-AP MLD are connected communicatively by two links (Link 1 and Link 2). Link 1 is established between AP1 and STA1, and Link 2 is established between AP2 and STA2.

[0116] Generally, the MAC addresses of an MLD and its associated STA are different from each other. For example, as shown in Figure 8, AP MLD has MAC address M, AP1 has MAC address w, and AP2 has MAC address x. Similarly, non-AP MLD has MAC address P, STA1 has MAC address y, and STA2 has MAC address z.

[0117] As shown in Figure 8, in each MLD, the MAC sublayer can be further divided into the MLD Upper MAC sublayer and the MLD Lower MAC sublayer. The MLD Upper MAC sublayer (MLD) performs functions common to all links. The MLD Lower MAC sublayer performs functions local to each link. Some functions require joint processing by both the MLD Upper MAC sublayer and the MLD Lower MAC sublayer.

[0118] The MLD upper MAC sublayer functions include the following: Authentication, association, and re-association (between AP MLDs and non-AP MLDs) Security associations (such as Pairwise Master Key Security Association (PMKSA) and Pairwise Transient Key Security Association (PTKSA)), and distribution of Group Temporal Keys (GTK) / Integrity GTK (IGTK) / Beacon IGTK (BIGTK), Assignment of sequence number (SN) / packet number (PN) for frames encrypted by a pairwise transient key (PTK) of unicast frames. Encryption / decryption of unicast frames using PTK, Selection of the MLD lower MAC sublayer for transmission (TID-to-link mapping), Packet reordering to ensure correct delivery for each block ACK session, Scoreboarding of block ACKs for individually addressed frames (in cooperation with the MLD lower MAC sublayer). Optionally, the MLD upper MAC sublayer distributes block ACK records on one link to the MLD lower MAC sublayers on other links, and MLD-level management information exchange / instruction via the MLD lower MAC sublayer.

[0119] The MLD lower MAC sublayer functions include the following: Link-specific GTK / IGTK / BIGTK maintenance (between APs connected to AP MLDs and STAs connected to non-AP MLDs), Link-specific encryption / decryption / integrity protection and PN assignment using GTK / IGTK / BIGTK (between APs working with AP MLD and STAs working with non-AP MLDs), Exchange / instruction of link-specific management information (such as beacons), Link-specific control information exchange / instructions (RTS / CTS, confirmation, etc.), Power saving status and mode, MAC address filtering for frame reception, and Scoreboarding of block ACKs for individually addressed frames (in cooperation with the MLD upper MAC sublayer). Optionally, the MLD lower MAC sublayer receives block ACK records on other links from the MLD upper MAC sublayer.

[0120] Multilink (re)setup between a non-AP MLD and an AP MLD involves the exchange of (re)association request / response frames. The (re)association request / response frame exchange for multilink setup includes both frames that transmit the basic multilink elements.

[0121] In a (re)association request frame, a non-AP MLD indicates the link for which (re)setup is requested, as well as the functional and operational parameters of the requested link. A non-AP MLD may request (re)setup of a subset of APs and links that are working with an AP MLD. The link for (re)setup, as well as the functional and operational parameters of the requested link, are independent of the existing setup link with the associated AP MLD, as well as the functional and operational parameters of the setup link.

[0122] In the (re)association response frame, the AP MLD indicates which requested links were accepted and rejected for (re)setup, as well as the functional and operational parameters of the requested links. The AP MLD may accept a subset of the requested links for (re)setup. The (re)association response frame is sent to the non-AP STA working with the non-AP MLD that sent the (re)association request frame.

[0123] An MLD requesting or accepting a multilink (re)setup for any two links ensures that each link is on a different non-overlapping channel. Upon successful multilink (re)setup between a non-AP MLD and an AP MLD, the non-AP MLD and AP MLD set up the links for multilink operation, and the non-AP MLD is (re)associated with the AP MLD. For each setup link, the corresponding non-AP STA working with the non-AP MLD is in the same associated state as the non-AP MLD and is associated with the corresponding AP working with the AP MLD. For each setup link, functionality between the non-AP STA and its associated AP is enabled unless the functionality is extended to the MLD level or otherwise specified.

[0124] Figure 9 shows an example of a multilink setup between an AP MLD and a non-AP MLD. As shown in the figure, the AP MLD has three cooperative APs: AP1 operating in the 2.4GHz band, AP2 operating in the 5GHz band, and AP3 operating in the 6GHz band. The non-AP MLD has three cooperative STAs: non-AP STA1 operating in the 2.4GHz band, non-AP STA2 operating in the 5GHz band, and non-AP STA3 operating in the 6GHz band.

[0125] A non-AP MLD initiates multilink setup by sending an association request frame to AP1, with which the non-AP STA1 is working with the AP MLD. In the association request frame, the sender address (TA) field is set to the MAC address of the non-AP STA1, and the receiver address (RA) field is set to the MAC address of AP1. The association request frame includes the MLD MAC address of the non-AP MLD and basic multilink elements showing the complete information of non-AP STA1, non-AP STA2, and non-AP STA3. The association request frame requests the setup of three links between the non-AP MLD and the AP MLD: the link between AP1 and non-AP STA1, the link between AP2 and non-AP STA2, and the link between AP3 and non-AP STA3.

[0126] The AP MLD responds to the requested multilink setup by sending an association response frame to the non-AP STA1 that is working with the non-AP MLD. In the association response frame, the TA field is set to the MAC address of AP1 and the RA field is set to the MAC address of the non-AP STA1. The association response frame contains the MLD MAC address of the AP MLD and basic multilink elements showing the complete information of AP1, AP2, and AP3. The association response frame signals that the multilink setup has been successful by setting up three links between the non-AP MLD and the AP MLD (link 1 between AP1 and non-AP STA1, link 2 between AP2 and non-AP STA2, and link 3 between AP3 and non-AP STA3).

[0127] By default, all TIDs in a non-AP MLD are mapped to all setup links, both uplink and downlink. The TID-to-link mapping mechanism allows AP MLDs and non-AP MLDs that have performed or are performing a multilink setup to specify how UL and DL QoS traffic corresponding to different TIDs (e.g., 0-7) should be allocated to the setup links. Negotiated TID-to-link mappings allow TIDs to be mapped to link sets (subsets of setup links), ranging from a single setup link to all setup links.

[0128] A setup link is defined as enabled for a non-AP MLD if at least one TID is mapped to that link in either the DL or UL, and disabled if there are no TIDs mapped to that link in both the DL and UL. At any given time, a TID is always mapped to at least one setup link in both the DL and UL. In other words, a TID-to-link mapping change can only be effective and successful if it does not result in a TID having a set of mapped links without a setup link.

[0129] By default, all setup links are enabled. When a link is enabled for a non-AP MLD, it can be used for exchanging individually addressed frames, depending on the power status of the non-AP STA operating on that link. Only MSDUs or A-MSDUs with a TID mapped to the link can transmit 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 a non-AP MLD cooperative STA and its corresponding AP in an AP MLD, in both DL and UL.

[0130] If the link is disabled for a non-AP MLD, the link cannot be used to exchange individually addressed frames between the non-AP MLD's linked STA and the corresponding AP of the AP MLD.

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

[0132] If the TID is mapped in DL to a set of enabled links for a non-AP MLD, the non-AP MLD can obtain an individually addressed BU buffered by the AP MLD, which is the MSDU or A-MSDU corresponding to the TID, on any link in the set of enabled links. Conversely, the AP MLD will transmit the individually addressed MSDU or A-MSDU corresponding to the TID using any link in the set of enabled links, depending on the power state of the non-AP STA on each link being used.

[0133] When the default mode is used, a non-AP MLD will acquire the BU buffered by the AP MLD on any setup link, even if the AP MLD recommends a link.

[0134] A non-AP MLD obtains a buffered BU, which is an MMPDU buffered by an AP MLD on any enabled link. The AP MLD, depending on the power status of the non-AP STA on the link being used, sends an individually addressed bufferable management frame, which is not a measured MMPDU, using any enabled link.

[0135] If an STA working with a non-AP MLD is in active mode on a link that has a set of TIDs mapped for DL ​​transmission, its associated AP working with the AP MLD will send the STA the MSDU / A-MSDU of the non-AP MLD's mapped TID set and an MMPDU that is not the measured MMPDU of the non-AP MLD or its working STA (unless the frame is sent to another STA working with the same non-AP MLD and in active mode).

[0136] As described above, in the default mapping mode, all TIDs are mapped to all setup links in DL and UL, and all setup links are enabled. Non-AP MLDs and AP MLDs performing a multilink setup operate in this mode if TID-to-link mapping negotiation for different mappings has not occurred, failed, or been torn down.

[0137] In the multilink (re)setup procedure, if the AP MLD indicates that it supports TID-to-link mapping negotiation, the non-AP MLD initiates TID-to-link mapping negotiation by including the TID-to-link mapping element in the (re)association request frame.

[0138] After receiving a (re)association request frame containing a TID-to-link mapping element, the AP MLD responds 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 within the received (re)association request frame only if it accepts a multilink (re)setup for all links for which mapping of at least one TID is requested. 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 rejects the proposed TID-to-link mapping by including the TID-to-link mapping element proposing a preferred TID-to-link mapping in the (re)association response frame.

[0139] After a successful multilink (re)setup, the initiating MLD sends a individually addressed TID-to-link mapping request frame to the response MLD, indicating that it supports TID-to-link mapping negotiation, in order to negotiate a new TID-to-link mapping.

[0140] Upon receiving an individually addressed TID-to-link mapping request frame, the response MLD sends an individually addressed TID-to-link mapping response frame to the initiating MLD according to the following rules: The response MLD accepts the requested TID-to-link mapping indicated in the TID-to-link mapping element in the received TID-to-link mapping request frame by sending a TID-to-link mapping response frame. Otherwise, the response MLD rejects the proposed TID-to-link mapping in the TID-to-link mapping response frame. The response MLD proposes a preferred TID-to-link mapping in the TID-to-link mapping response frame by including the TID-to-link mapping element in the TID-to-link mapping response frame.

[0141] An MLD can propose a preferred TID-to-link mapping to a peer MLD by sending an unsolicited TID-to-link mapping response frame that includes a TID-to-link mapping element.

[0142] When a peer MLD indicates a preferred TID-to-link mapping, the MLD takes that preferred TID-to-link mapping into consideration when initiating a new TID-to-link mapping. Furthermore, the AP MLD takes into account the traffic flow interacting with the non-AP MLD, as well as the capabilities and limitations of the non-AP MLD (if any).

[0143] When two MLDs negotiate a TID-to-link mapping, the MLDs can tear down the negotiated TID-to-link mapping by sending individually addressed TID-to-link mapping teardown frames. After teardown, the MLDs operate in their default mapping mode.

[0144] When an MLD successfully negotiates a TID-to-link mapping with a peer MLD, both the MLD and the peer MLD update their uplink and / or downlink TID-to-link mapping information according to the negotiated TID-to-link mapping.

[0145] When an MLD successfully negotiates an uplink and / or downlink TID-to-link mapping with a peer MLD, where bit position i of the link mapping field n in the TID-to-link mapping element is set to 0, TID n is not mapped to the link associated with link ID i in the uplink and / or downlink. When an MLD successfully negotiates an uplink and / or downlink TID-to-link mapping with a peer MLD, where bit position i of the link mapping field n in the TID-to-link mapping element is set to 1, TID n is mapped to the link associated with link ID i in the uplink and / or downlink.

[0146] Figure 10 shows an example of TID-to-link mapping in a multilink communication environment. As shown in the figure, the multilink communication environment has an AP MLD with three cooperative APs and a non-AP MLD with three cooperative STAs.

[0147] During or after multilink setup, the non-AP MLD and AP MLD negotiate a TID-to-link mapping. The TID-to-link mapping maps the TIDs of the UL and DL in the non-AP MLD to the setup link between the AP MLD and the non-AP MLD. For example, as shown in Figure 10, the TID-to-link mapping maps TIDs 0-6 of both the UL and DL to link 1, and TID 7 of both the UL and DL to link 2. Therefore, links 1 and 2 are enabled, and link 3 is disabled. TID-to-link mapping negotiation is performed by exchanging association request / response frames or TID-to-link mapping request / response frames between the non-AP MLD and the AP MLD.

[0148] Figure 11 shows example 1100 of the Request to Transmit (RTS) / Authorize to Transmit (CTS) procedure. Example 1100 of the RTS / CTS procedure is based on the IEEE 802.11 draft standard "IEEEP802.11-REVme TM This is an example of the RTS / CTS procedure defined in section 10.3.2.9 of " / D2.1 (January 2023)". As shown in Figure 11, RTS / CTS procedure example 1100 includes STA1102 and 1104. Other STAs of the same BSS may also be within the communication range of STA1102 and 1104.

[0149] In one example, STA1102 sends RTS frame 1106 to STA1104. STA1102 sends RTS frame 1106 to protect the transmission of data frame 1110 that STA1102 is about to send from a hidden STA. RTS frame 1106 contains a period / ID field. The period / ID field sets the time in microseconds required to send data frame 11105, which consists of one CTS frame, one ACK frame (if necessary), and three SIFS (short inter-frame interval) periods.

[0150] In one example, STA1104 responds to RTS frame 1106 by sending CTS frame 1108 to STA1102. CTS frame 1108 is sent 1 SIFS period after RTS frame 1106. STA1104 responds to RTS frame 1106 after it has been addressed to STA1104 and after considering the NAV (unless the frame originating from STA1102 has a NAV set). STA1104 responds to RTS frame 1106 if it has been addressed to STA1104 and the NAV indicates an idle state. In a non-S1G STA, the NAV indicates an idle state when the NAV count is 0, or when the NAV count is not 0 but the non-bandwidth signaling TA obtained from the TA field of RTS frame 1106 matches the stored TXOP holder address. In S1G STA, the NAV indicates an idle state when both the NAV counter and the RID (response indication deferral) counter are 0, or when either the NAV counter or the RID counter is non-zero but the TA field of RTS frame 1106 matches the stored TXOP holder address.

[0151] STA1104 sets the RA field of CTS frame 1108 to a non-bandwidth signaling TA obtained from the TA field of RTS frame 1106. STA1104 sets the period field of CTS frame 1108 based on the period / ID field of RTS frame 1106. That is, it sets it to be equal to the value of the period / ID field of RTS frame 1106, adjusted by subtracting the time required to transmit CTS frame 1108 and one SIFS period.

[0152] When STA1102 receives CTS frame 1108, it waits for 1 SIFS period before sending data frame 1110. STA1104 sends ACK frame 1112 in response to data frame 1110. STA1104 sends ACK frame 1112 1 SIFS after receiving data frame 1110.

[0153] As shown in Example 1100, other STAs belonging to the same BSS and within the communication range of STAs 1102 and 1104 set their NAVs according to the RTS frame 1106 and / or CTS frame 1108. For example, an STA that receives an RTS frame 1106 sets its NAV based on the duration / ID field of the RTS frame 1106. Another STA that receives a CTS frame 1008 sets its NAV based on the duration field of the CTS frame 1108. Therefore, other STAs do not access the channel using EDCA until the transmission of ACK frame 1112 is complete. Similarly, STAs belonging to overlapping BSSs (OBSSs) set their NAVs according to the RTS or CTS frame if they are within the communication range of the transmitting STA.

[0154] Future IEEE 802.11 standards are expected to provide various mechanisms to support the quality of service (QoS) requirements of low-latency (LL) (or latency-sensitive) traffic. Such traffic originates from various 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 traffic is associated with one or more predetermined ACs or one or more traffic identifiers (TIDs) associated with traffic streams (hereinafter, TIDs associated with LL traffic are referred to as LL TIDs). For example, one or more predetermined ACs include access categories for video (AC_VI) and access categories for voice (AC_VO).

[0155] In addition to supporting QoS requirements for low-latency traffic, future IEEE 802.11 radios (e.g., Ultra-High-Reliability (UHR) 802.11 radios) are also expected to support reliable communication of low-latency traffic. Reliability is achieved by using RTS / CTS procedures before transmitting low-latency data to protect the transmission of low-latency data from interference. However, even if reliability is met, low-latency data may be delayed if the receiving STA is unable to respond to the RTS frame. Figure 12 below shows an example 1200 of an existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange.

[0156] As shown in Figure 12, Example 1200 includes STA1210, 1211, and OBSS STA1212. OBSS STA1212 may belong to a different BSS than STA1210 and 1211. STA1210 and 1211 each include AP MLDs or non-AP MLDs that can communicate over multiple links. Similarly, OBSS STA1212 includes AP MLDs or non-AP MLDs that can communicate over multiple links. In one example, OBSS STA1212 is within the communication range of STA1211 but not within the communication range of STA1210.

[0157] In Example 1200, STA1210 has a low-latency data frame 1225 to send to STA1211 within a transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1210 can associate a counter with the transmission completion time. The transmission completion time counter starts from the arrival of the low-latency data at STA1210 in the low-latency data frame 1225. In another implementation, the transmission completion time counter starts from the initiation of the RTS / CTS procedure by STA1210. In yet another implementation, the transmission completion time counter starts from the transmission of the low-latency data frame 1225 by STA1210. In one implementation, successful transmission of the low-latency data frame requires an acknowledgment of the low-latency data frame by the destination STA before the transmission completion time counter expires. In one implementation, the transmission completion time refers to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may vary depending on the low-latency data frame.

[0158] According to existing procedures, in order to transmit the low-latency data frame 1225, STA1210 first transmits RTS frame 1221 to STA1211 via a first link (e.g., link-1). In one example, when STA1210 transmits RTS frame 1221, it starts the transmit completion time counter associated with the low-latency data frame 1225. In another example, STA1211 does not transmit a CTS frame to STA1210 in response to RTS frame 1221 via the first link because it is in the process of receiving data frame 1222 from OBSS STA1212 when it receives RTS frame 1221 from STA1210. In yet another example, OBSS STA1212 transmits data frame 1222 to another STA (not shown in Figure 12) via the first link, and STA1211 sets its NAV based on data frame 1222 because it is within the communication range of OBSS STA1212.

[0159] In one example, the RTS / CTS timer expires on STA1210 before STA1211 sends a CTS frame to STA1210 over the first link. In another example, the RTS / CTS timer is initialized with a value for the CTS timeout interval. The CTS timeout interval may represent the time interval starting from when the STA sends an RTS frame. If the CTS timeout interval elapses without receiving a CTS frame in response to an RTS frame, the STA determines that the RTS / CTS procedure has failed. The CTS timeout interval is defined in the IEEE 802.11 standard ("IEEE P802.11-REVme"). TM As described in section 10.3.2.9 of / D2.1 (January 2023), the period may be aSIFSTime + aSlotTime + aRxPHYStartDelay, where aSIFSTime is the nominal time (microseconds) required from the time the MAC and PHY layers receive the end of a first PPDU[+SigExt] on the wireless medium until the MAC and PHY layers process the frames therein and respond with the start of a second PPDU on the wireless medium containing the earliest possible response frame; aSlotTime is the slot time (microseconds) that the MAC uses to define the interframe space; and aRxPHYStartDelay is the delay (microseconds) from the start of the PPDU on the receiver's antenna until the issuance of the PHY-RXSTART.indication primitive.

[0160] According to existing procedures, STA1210 sends a further RTS frame 1223 to STA1211 via the first link. In one example, STA1211 responds to RTS frame 1223 by sending a CTS frame 1224 to STA1210 via the first link if its NAV indicates an idle state. By listening to the CTS frame, OBSS STA1212 sets its NAV to the first link. Meanwhile, STA1210 sends a low-latency data frame 1225 to STA1211 via the first link. After receiving the low-latency data frame 1225, STA1211 sends an ACK frame 1226 to STA1210 via the first link.

[0161] As shown in Figure 12, delays can occur due to the RTS / CTS protection procedure on busy links, so the elapsed time from the transmission of RTS frame 1221 by STA1210 to the reception of ACK frame 1226 by STA1210 may be longer than the transmission completion time of low-latency data frame 1225. In the case of low-latency data frames, delayed transmission may be useless because the frame may no longer be useful to the receiving STA. One approach is for an STA with multilink capabilities to request the transmission of low-latency data from available links (if any) by transmitting RTS frames over multiple links. Figure 13 below shows an example 1300 illustrating another existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange.

[0162] As shown in Figure 13, Example 1300 includes STA1310, 1311, and OBSS STA1312. OBSS STA1312 may belong to a different BSS than STA1310 and 1311. STA1310 and 1311 each include AP MLDs or non-AP MLDs that can communicate over multiple links. Similarly, OBSS STA1312 includes AP MLDs or non-AP MLDs that can communicate over multiple links. In one example, OBSS STA1312 is within the communication range of STA1311 but not within the communication range of STA1310.

[0163] In Example 1300, STA1310 has a low-latency data frame 1325 to send to STA1311 within a transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1310 can associate a counter with the transmission completion time. The transmission completion time counter starts from the arrival of the low-latency data at STA1310, which is sent in the low-latency data frame 1325. In another implementation, the transmission completion time counter starts from the initiation of the RTS / CTS procedure by STA1310. In yet another implementation, the transmission completion time counter starts from the transmission of the low-latency data frame 1325 by STA1310. In one implementation, successful transmission of the low-latency data frame requires an acknowledgment of the low-latency data frame by the destination STA before the transmission completion time counter expires. In one implementation, the transmission completion time refers to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may vary depending on the low-latency data frame.

[0164] According to existing procedures, to transmit low-latency data frame 1325, STA1310 transmits RTS frame 1321 to STA1311 via the first link and another RTS frame 1322 to STA1311 via the second link (e.g., link-2). STA1310 starts transmitting RTS frame 1321 and RTS frame 1322 simultaneously. Due to random backoffs occurring on the first and second links, the transmissions of RTS frame 1321 and RTS frame 1322 may not be time-synchronized. In one example, STA1310 starts a transmission completion time counter associated with low-latency data frame 1325 when transmitting RTS frame 1321.

[0165] In one example, STA1311 does not send a CTS frame to STA1310 in response to RTS frame 1321 because it is in the process of receiving data frame 1323 from OBSS STA1312 when it receives RTS frame 1321 from STA1310. In another example, OBSS STA1312 sends data frame 1323 to another STA (not shown in Figure 13) over the first link, and STA1311 sets its NAV based on data frame 1323 because it is within OBSS STA1312's communication range. However, STA1311 responds to RTS frame 1322 by sending CTS frame 1324 to STA1310 over the second link if its NAV indicates an idle state. By hearing CTS frame 1324, OBSS STA1312 sets its NAV on the second link. After receiving CTS frame 1324, STA1310 sends low-latency data frame 1325 to STA1311 via the second link. After receiving data frame 1325, STA1311 sends ACK frame 1326 to STA1310 via the second link. Meanwhile, after RTS frame 1321 is sent via the first link, STA1310 observes the expiration of the CTS timeout interval if it does not receive a CTS frame via the first link. Since data frame 1325 is sent via the second link, STA1310 does not send any further RTS frames via the first link.

[0166] As shown in Figure 13, by sending multiple RTS frames over multiple links (to request the transmission of low-latency data) and receiving a CTS frame from any of the links, the elapsed time from the transmission of RTS frame 1321 by STA1310 to the reception of ACK frame 1326 by STA1310 becomes shorter than the transmission completion time. As shown in Figure 13, if one or more links are busy / unavailable and only one link is available, sending multiple RTS frames over multiple links can provide an efficient solution for transmitting low-latency data. However, in scenarios where multiple links are available, sending multiple RTS frames may cause STAs within the receiving STA's communication range (OBSS STA and / or other STAs in the same BSS) to set NAV for all links that hear CTS frames from the receiving STA. However, since the transmitting STA only transmits data frames over one link, STAs within the receiving STA's communication range may unnecessarily refrain from communicating over other links. Figure 14 below is an example 1400 illustrating another existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange.

[0167] As shown in Figure 14, Example 1400 includes STA1410, 1411, and OBSS STA1412. OBSS STA1412 may belong to a different BSS than STA1410 and 1411. STA1410 and 1411 each include AP MLDs or non-AP MLDs that can communicate over multiple links. Similarly, OBSS STA1412 includes AP MLDs or non-AP MLDs that can communicate over multiple links. In one example, OBSS STA1412 is within the communication range of STA1411 but not within the communication range of STA1410.

[0168] In Example 1400, STA1410 has a low-latency data frame 1425 to send to STA1411 within a transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1410 can associate a counter with the transmission completion time. The transmission completion time counter starts from the arrival of the low-latency data at STA1410 in the low-latency data frame 1425. In another implementation, the transmission completion time counter starts from the initiation of the RTS / CTS procedure by STA1410. In yet another implementation, the transmission completion time counter starts from the transmission of the low-latency data frame 1425 by STA1410. In one implementation, successful transmission of the low-latency data frame requires an acknowledgment of the low-latency data frame by the destination STA before the transmission completion time counter expires. In one implementation, the transmission completion time refers to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may vary depending on the low-latency data frame.

[0169] According to existing procedures, to transmit low-latency data frame 1425, STA1410 transmits RTS frame 1421 to STA1411 via the second link and another RTS frame 1422 to STA1411 via the first link. STA1410 starts transmitting RTS frame 1421 and RTS frame 1422 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frame 1421 and RTS frame 1422 may not be time-synchronized. In one example, STA1410 starts a transmission completion time counter associated with low-latency data frame 1425 when transmitting RTS frame 1421.

[0170] In one example, if STA1411 indicates that its NAV is idle, it sends a CTS frame 1423 to STA1410 in response to an RTS frame 1421 via the second link. STA1411 may also respond to an RTS frame 1422 by sending a CTS frame 1424 to STA1410 via the first link if its NAV is idle. By listening to CTS frame 1423 via the second link and CTS frame 1424 via the first link, OBSS STA1412 sets its NAV on the first and second links based on CTS frames 1423 and 1424, respectively. After receiving CTS frame 1423 via the second link (for example, STA1410 receives CTS frame 1423 via the second link before CTS frame 1424 via the first link), STA1410 sends data frame 1425 to STA1411 via the second link. After receiving data frame 1425, STA1411 sends ACK frame 1426 to STA1410 via the second link. On the other hand, if STA1411 does not receive a data frame via the first link within a period of (2 × aSIFSTime) + CTS_Time + aRxPHYStartDelay + (2 × aSlotTime) after sending CTS frame 1424 via the first link, STA1411 resets its NAV to the first link. CTS_Time represents the transmission time of CTS frame 1424. On the other hand, OBSS STAs (such as OBSS STA1412) and other STAs within the same BSS as STA1411 cannot reconfigure their NAVs to the first link, and therefore cannot communicate via the first link even though the first link is not being used for frame transmission. As a result, low-latency data can be transmitted before the transmission completion time, but many STAs become unusable via the first link even though the first link is not being used.

[0171] The embodiments of the present disclosure, further described below, address the above-mentioned problems of existing procedures. In one embodiment, the embodiment enables a multilink-capable STA (AP STA or non-AP STA) to utilize the availability of a second link for transmitting low-latency data when proper protection of transmission over the first link is not available. In another embodiment, 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 a further embodiment, the embodiment enables a receiving STA to respond to multiple RTS frames received over multiple links via only one link. Thus, other STAs within the communication range of the receiving STA are not unnecessarily blocked from communication over other links.

[0172] Figure 15 shows an example process 1500 according to an embodiment. Example process 1500 is provided for illustrative purposes only and is not intended to limit the embodiments. Example process 1500 is performed by a first STA having multilink capabilities (i.e., comprising a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA is a transmitting STA having data to transmit to a second STA (receiving STA). The second STA may also comprise an MLD. The first and second STAs communicate via at least a first link and a second link. In one example, the first link consists of one of the 2.4GHz band, 5GHz band, 6GHz band, or a future-defined band. Similarly, the second link consists of one of the 2.4GHz band, 5GHz band, 6GHz band, or a future-defined band, and the second link is different from the first link.

[0173] As shown in Figure 15, process 1500 begins at step 1505. In this step, it is determined whether the data to be sent to the second STA is low-latency traffic. As used herein, low-latency traffic refers to traffic associated with one or more predetermined traffic categories or traffic streams (e.g., voice / video). Low-latency traffic consists of data frames with LL TID. If the answer in step 1505 is "no", process 1500 proceeds to step 1510, where the STA processes the data according to existing IEEE 802.11 standard procedures. For example, before the STA sends the data, it uses existing RTS / CTS procedures defined in the existing standard.

[0174] If the answer in step 1505 is "yes", process 1500 proceeds to step 1520 according to the first option (hereinafter referred to as Option-1), or to step 1545 according to the second option (hereinafter referred to as Option-2).

[0175] In step 1520, process 1500 sends a first RTS frame to the second STA via the first link, requesting that it send data consisting of low-latency traffic. Process 1500 then proceeds to step 1525, checking whether it has received a CTS frame from the second STA via the first link. If the answer to step 1525 is "yes", process 1500 proceeds to step 1530, sending data consisting of low-latency traffic to the second STA via the first link.

[0176] If the answer to step 1525 is "no", process 1500 proceeds to step 1535 to determine whether period T has elapsed. In one embodiment, period T can be used as an early check to see if a transmission request over a link has been accepted. The early check ensures that even if a transmission request has not yet been accepted, data consisting of low-latency traffic can be transmitted over another link within the transmission completion time. In one embodiment, period T is set according to the formula T <= transmission completion time - data transmission time - ACK transmission time - RTS / CTS exchange time - 4 × SIFS time - maximum backoff time (Formula 1).

[0177] If the answer to step 1535 is "no", then process 1500 returns to step 1525 above.

[0178] If the answer to step 1535 is "yes", process 1500 proceeds to step 1540. In the first embodiment, step 1540 sends a second RTS frame to the second STA over the second link. In one embodiment, the period T is shorter than the CTS timeout interval in this first embodiment. The second RTS frame requests the second STA to send data consisting of low-latency traffic over the second link. In response, the first STA receives a CTS frame from the second STA over the second link in response to the second RTS frame. The first STA sends data consisting of low-latency traffic over the second link to the second STA.

[0179] In a second embodiment, step 1540 transmits a third RTS frame to the second STA via the first link, in addition to transmitting a second RTS frame to the second STA via the second link. In one embodiment, the period T is longer than or equal to the CTS timeout interval in this second embodiment. The third RTS frame requests the second STA to transmit data consisting of low-latency traffic via the first link. Thus, the third RTS frame may overlap with the second RTS frame. In one embodiment, the second and third RTS frames are Multi-User Send Request (MU-RTS) trigger frames. In one embodiment, the first STA receives a CTS frame from the second STA via the second link in response to the second RTS frame and transmits data consisting of low-latency traffic to the second STA via the second link. In another embodiment, the first STA receives a CTS frame from the second STA via the first link in response to the third RTS frame.

[0180] Switching to option-2, step 1545 sends a first MU-RTS trigger frame to the second STA requesting it to transmit data via the first link, and also sends a second MU-RTS trigger frame to the second STA requesting it to transmit data via the second link.

[0181] In one embodiment, the first MU-RTS trigger frame includes a second link instruction. In one embodiment, the second link instruction in the first MU-RTS trigger frame indicates that the second STA requests that the second MU-RTS trigger frame transmitted over the second link transmit the same data as the first MU-RTS trigger frame transmitted over the first link. In another embodiment, the second MU-RTS trigger frame includes a first link instruction. In one embodiment, the first link instruction in the second MU-RTS trigger frame indicates that the second STA requests that the first MU-RTS trigger frame transmitted over the first link transmit the same data as the second MU-RTS trigger frame transmitted over the second link. Such instructions in the first or second MU-RTS trigger frame allow the second STA to link the first MU-RTS trigger frame and the second MU-RTS trigger frame as relating to the same data.

[0182] In one embodiment, the first MU-RTS trigger frame and / or the second MU-RTS trigger frame include instructions for a CTS response option to be used by the second STA. In one embodiment, the CTS response option includes the second STA responding to either the first MU-RTS trigger frame or the second MU-RTS trigger frame. Alternatively, the CTS response option includes the second STA responding to both the first and second MU-RTS trigger frames.

[0183] Subsequently, process 1500 proceeds to step 1550, where it determines whether the CTS frame was received on the first or second link within the CTS timeout interval. If the answer to step 1550 is "no", process 1500 returns to step 1545 above. If the answer to step 1550 is "yes", i.e., if STA receives the CTS frame from the second STA via either the first or second link (for example, via the second link in response to the second MU-RTS trigger frame), STA sends a data frame consisting of data to the second STA via the corresponding link (for example, the second link in response to the CTS frame).

[0184] Figure 16 shows Example 1600 of a proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to an embodiment. As shown in Figure 16, Example 1600 includes STA1610, 1611 and OBSS STA1612. OBSS STA1612 may belong to a different BSS than STA1610, 1611. STA1610, 1611 each include an AP MLD or non-AP MLD that can communicate over multiple links. Similarly, OBSS STA1612 includes an AP MLD or non-AP MLD that can communicate over multiple links. In one example, OBSS STA1612 is within the communication range of STA1611 but not within the communication range of STA1610.

[0185] In Example 1600, STA1610 has a low-latency data frame 1625 to send to STA1611 within a transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1610 can associate a counter with the transmission completion time. The transmission completion time counter starts from the arrival of the low-latency data at STA1610, which is sent in the low-latency data frame 1625. In another implementation, the transmission completion time counter starts from the initiation of the RTS / CTS procedure by STA1610. In yet another implementation, the transmission completion time counter starts from the transmission of the low-latency data frame 1625 by STA1610. In one implementation, successful transmission of the low-latency data frame requires an acknowledgment of the low-latency data frame by the destination STA before the transmission completion time counter expires. In one implementation, the transmission completion time refers to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may vary depending on the low-latency data frame.

[0186] To transmit a low-latency data frame 1625, STA1610 sends an RTS frame 1621 to STA1611 over the first link, requesting STA1611 to transmit data consisting of low-latency traffic over the first link. In one example, when STA1610 transmits the RTS frame 1621, it starts the transmit completion time counter associated with the low-latency data frame 1625. In another example, STA1611 does not send a CTS frame to STA1610 in response to the RTS frame 1621 over the first link because it is in the process of receiving data frame 1622 from OBSS STA1612 when it receives the RTS frame 1621 from STA1610. In yet another example, OBSS STA1612 is transmitting data frame 1622 over the first link to another STA (not shown in Figure 16), and STA1611 sets its NAV because it is within the communication range of OBSS STA1612.

[0187] In one embodiment, based on the fact that STA1610 has not received a CTS frame from STA1611 within a period T after sending an RTS frame 1621 and a data frame 1625 consisting of low-latency traffic, STA1610 sends an RTS frame 1623 to STA1611 via a second link, requesting STA1611 to send the data frame 1625 via the second link. In one embodiment, the period T is set to a value smaller than the CTS timeout interval (and also according to equation (1) above). In one example, the period T is set to half the CTS timeout interval. In another example, the period T is set to one-third the CTS timeout interval. Thus, the period T is used to perform an early check of whether the RTS / CTS exchange was successful on the first link. The early check provides a hint as to whether the RTS / CTS exchange on the first link was successful. Based on the early check, STA1611 can immediately initiate the RTS / CTS exchange on the second link to increase the likelihood of sending low-latency traffic.

[0188] In one embodiment, STA1610 may not transmit another RTS frame over the first link after a CTS timeout interval. In one embodiment, if the NAV indicates that the second link is idle for STA1611, STA1610 receives a CTS frame 1624 from STA1611 over the second link in response to an RTS frame 1623. Upon hearing the CTS frame 1624, OBSS STA1612 sets its NAV over the second link based on the CTS frame 1624. STA1610 then transmits a data frame 1625 to STA1611 over the second link. After receiving the data frame 1625, STA1611 transmits an ACK frame 1626 to STA1610 over the second link.

[0189] As shown in Figure 16, using the proposed procedure, STA1611 receives data consisting of low-latency traffic within the transmission completion time. This is made possible by STA1611 switching to a second link to perform RTS / CTS exchange after a period T has elapsed. A period T shorter than the CTS timeout interval ensures that STA1611 initiates RTS / CTS exchange on the second link based on an early check of whether the RTS / CTS exchange on the first link was successful. This early initiation of RTS / CTS exchange on the second link allows STA1611 to postpone using a brute-force approach of sending multiple RTS frames across multiple links.

[0190] Figure 17 shows another example 1700 of the proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. As shown in Figure 17, example 1600 includes STA1610, 1611 and OBSS STA1612. OBSS STA1612 may belong to a different BSS than STA1610, 1611. STA1610, 1611 each include an AP MLD or non-AP MLD that can communicate over multiple links. Similarly, OBSS STA1612 includes an AP MLD or non-AP MLD that can communicate over multiple links. In one example, OBSS STA1612 is within the communication range of STA1611 but not within the communication range of STA1610.

[0191] To transmit a low-latency data frame 1726, STA1610 sends an RTS frame 1721 to STA1611 via the first link, requesting STA1611 to transmit data consisting of low-latency traffic via the first link. In one example, when STA1610 transmits the RTS frame 1721, it starts the transmit completion time counter associated with the low-latency data frame 1726. In another example, STA1611 does not send a CTS frame to STA1610 in response to the RTS frame 1721 via the first link because it is in the process of receiving data frame 1722 from OBSS STA1612 when it receives the RTS frame 1721 from STA1610. In yet another example, OBSS STA1612 is transmitting data frame 1722 to another STA (not shown in Figure 17) via the first link, and STA1611 sets its NAV because it is within the communication range of OBSS STA1612.

[0192] In one embodiment, based on the fact that STA1610 has not received a CTS frame from STA1611 within a period T after transmitting an RTS frame 1721 and a data frame 1726 consisting of low-latency traffic, STA1610 transmits an RTS frame 1723 to STA1611 via a second link, requesting STA1611 to transmit the data frame 1726 via the second link. In one embodiment, the period T is longer than or equal to the CTS timeout interval (also according to equation (1) above). In one embodiment, when the period T is longer than or equal to the CTS timeout interval, STA1610 transmits an RTS frame 1724 to STA1611 via a first link, requesting STA1611 to transmit the data frame 1726 via the first link. In one embodiment, the RTS frame 1724 may overlap with the RTS frame 1723.

[0193] In one embodiment, STA1610 receives a CTS frame 1725 in response to an RTS frame 1723 from STA1611 via a second link. By listening to the CTS frame 1725, OBSS STA1612 sets its NAV to the second link based on the CTS frame 1725. STA1610 then sends a data frame 1726 to STA1611 via the second link. In another embodiment, STA1610 receives a CTS frame 1727 in response to an RTS frame 1724 from STA1611 via a first link. By listening to the CTS frame 1727, OBSS STA1612 sets its NAV to the first link based on the CTS frame 1727. In one embodiment, STA1610 receives the CTS frame 1727 after receiving the CTS frame 1725. Therefore, STA1610 may not respond to the CTS frame 1727 over the first link because it may have already begun transmitting the data frame 1726 over the second link. In one embodiment, if STA1611 transmits the CTS frame over a link and does not receive a data frame over that link, STA1611 resets its NAV to that link. Thus, in example 1700, STA1611 resets its NAV to the first link based on having received a data frame in response to the CTS frame 1727. Upon receiving the data frame 1726, STA1611 sends an ACK frame 1728 over the second link to STA1610.

[0194] As shown in Figure 17, using the proposed procedure, the second STA receives data consisting of low-latency traffic within the transmission completion time. This is made possible by the first STA sending multiple RTS frames over multiple links after a period T has elapsed. A period T longer than or equal to the CTS timeout interval ensures that if the first RTS / CTS exchange over the first link fails, the first STA will have to rely solely on multiple RTS transmissions over multiple links. In other words, when the remaining time window for low-latency data transmission narrows, the STA resorts to a brute-force approach of multiple RTS transmissions over multiple links.

[0195] However, data consisting of low-latency traffic is transmitted only over the second link, and the first link is not used, yet OBSS STA1612 cannot reconfigure its NAV to the first link by listening to CTS frame 1727 over the first link. This is also true for any STA within the communication range of STA1611, and such STAs cannot communicate over the first link even though the first link is not being used for frame transmission. Figure 18 below shows an example solution to this problem.

[0196] Figure 18 shows another example 1800 of the proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. As shown in Figure 18, example 1800 includes STA1610, 1611 and OBSS STA1612. OBSS STA1612 may belong to a different BSS than STA1610, 1611. STA1610, 1611 each include an AP MLD or non-AP MLD that can communicate over multiple links. Similarly, OBSS STA1612 includes an AP MLD or non-AP MLD that can communicate over multiple links. In one example, OBSS STA1612 is within the communication range of STA1611 but not within the communication range of STA1610.

[0197] To transmit a low-latency data frame 1826, STA1610 sends an RTS frame 1821 to STA1611 via the first link, requesting STA1611 to transmit data consisting of low-latency traffic via the first link. In one example, when STA1610 transmits the RTS frame 1821, it starts the transmit completion time counter associated with the low-latency data frame 1826. In another example, STA1611 does not send a CTS frame to STA1610 in response to the RTS frame 1821 via the first link because it is in the process of receiving data frame 1822 from OBSS STA1612 when it receives the RTS frame 1821 from STA1610. In yet another example, OBSS STA1612 is transmitting data frame 1822 to another STA (not shown in Figure 18) via the first link, and STA1611 sets its NAV because it is within the communication range of OBSS STA1612.

[0198] In one embodiment, based on the fact that STA1610 has not received a CTS frame from STA1611 within a period T after transmitting an RTS frame 1821 and a data frame 1826 consisting of low-latency traffic, STA1610 transmits a MU-RTS trigger frame 1823 to STA1611 via a second link, requesting STA1611 to transmit the data frame 1826 via the second link. In one embodiment, the period T is longer than or equal to the CTS timeout interval (also according to equation (1) above). In one embodiment, when the period T is longer than or equal to the CTS timeout interval, STA1610 transmits a MU-RTS trigger frame 1824 to STA1611 via a first link, requesting STA1611 to transmit the data frame 1826 via the first link. In one embodiment, the MU-RTS trigger frame 1824 may overlap with the MU-RTS trigger frame 1823. In one embodiment, the MU-RTS trigger frame 1823 and / or the MU-RTS trigger frame 1824 have a format such as the trigger frame 2200 described later with respect to Figure 22.

[0199] In one embodiment, STA1611 receives MU-RTS trigger frame 1823 via a second link before receiving MU-RTS trigger frame 1824 via a first link. In another embodiment, STA1611 responds to MU-RTS trigger frame 1823 by transmitting CTS frame 1825 via a second link if its NAV indicates an idle state. In yet another embodiment, STA1611 receives MU-RTS trigger frame 1823 via a second link simultaneously with or after MU-RTS trigger frame 1824 via a first link. In one embodiment, STA1611 selects an appropriate link (e.g., a second link) for CTS transmission (e.g., depending on traffic parameters) and transmits only one CTS frame via the selected link (e.g., a second link). The selection of only one appropriate link for CTS transmission is triggered by MU-RTS frames 1823 and 1824 having a special format defined in Figure 22. In one embodiment, MU-RTS trigger frame 1823 or MU-RTS trigger frame 1824 includes an instruction for a CTS response option for use with STA1611. In one embodiment, the CTS response option includes STA1611 responding to either MU-RTS trigger frame 1823 or MU-RTS trigger frame 1824. In another embodiment, the CTS response option includes STA1611 responding to both MU-RTS trigger frame 1823 and MU-RTS trigger frame 1824.

[0200] In one embodiment, STA1610 receives a CTS frame 1825 from STA1611 via a second link in response to a MU-RTS trigger frame 1823. Upon hearing the CTS frame 1825, OBSS STA1612 sets its NAV to the second link. STA1610 then sends a data frame 1826 to STA1611 via the second link. Upon receiving the data frame 1826, STA1611 sends an ACK frame 1827 to STA1610 via the second link.

[0201] As shown in Figure 18, when using MU-RTS trigger frames (instead of RTS frames) in the proposed procedure, the STA1611 transmits a single CTS frame over the second link in response to multiple MU-RTS trigger frames. Therefore, the OBSS STA1612 does not unnecessarily configure its NAV on the first link, allowing other transmissions (including the OBSS STA1612) to be made on the first link.

[0202] Figure 19 shows another example 1900 of the proposed procedure that can be used to transmit low-latency data protected by RTS / CTS exchange according to the embodiment. As shown in Figure 19, example 1900 includes STA1610, 1611 and OBSS STA1612. OBSS STA1612 may belong to a different BSS than STA1610, 1611. STA1610, 1611 each include an AP MLD or non-AP MLD that can communicate over multiple links. Similarly, OBSS STA1612 includes an AP MLD or non-AP MLD that can communicate over multiple links. In one example, OBSS STA1612 is within the communication range of STA1611 but not within the communication range of STA1610.

[0203] In one embodiment, STA1610 receives data to be transmitted to STA1611. Based on the fact that the data consists of low-latency traffic, STA1610 transmits a MU-RTS trigger frame 1921 to STA1611 via the first link, requesting that the data be transmitted via the first link, and a MU-RTS trigger frame 1922 to STA1611 via the second link, requesting that the data be transmitted via the second link. In one embodiment, the MU-RTS trigger frame 1921 and / or the MU-RTS trigger frame 1922 have a format such as the trigger frame 2200 described later with respect to Figure 22. In one embodiment, the MU-RTS trigger frame 1921 includes a second link instruction. In one embodiment, the second link instruction in the MU-RTS trigger frame 1921 indicates to STA1611 that the MU-RTS trigger frame 1922 transmitted via the second link transmits the same data as the MU-RTS trigger frame 1921 transmitted via the first link. In another embodiment, the MU-RTS trigger frame 1922 includes a first link instruction. In one embodiment, the first link instruction in the MU-RTS trigger frame 1922 indicates to the STA 1611 that the MU-RTS trigger frame 1921 transmitted over the first link transmits the same data as the MU-RTS trigger frame 1922 transmitted over the second link. Such an instruction in the MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922 allows the STA 1611 to link the MU-RTS trigger frame 1921 and the MU-RTS trigger frame 1922 as relating to the same data.

[0204] In another embodiment, MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922 includes an instruction for a CTS response option for use with STA1611. In one embodiment, the CTS response option includes STA1611 responding to either MU-RTS trigger frame 1921 or MU-RTS trigger frame 1922. In another embodiment, the CTS response option includes STA1611 responding to both MU-RTS trigger frame 1921 and MU-RTS trigger frame 1922.

[0205] In one embodiment, STA1611 does not send a CTS frame to STA1610 in response to the MU-RTS frame 1921 over the first link because STA1611 is in the process of receiving a data frame 1923 from OBSS STA1612 when it receives a MU-RTS frame 1921 from STA1610. In another example, OBSS STA1612 sends a data frame 1923 over the first link to another STA (not shown in Figure 19), and STA1611 sets its NAV based on the data frame 1923 because it is within the communication range of OBSS STA1612. In one embodiment, STA1611 sends a CTS frame 1924 to STA1610 in response to the MU-RTS frame 1922 over the second link if its NAV indicates an idle state. By listening to the CTS frame 1924, OBSS STA1612 sets its NAV over the second link based on the CTS frame 1924. Next, STA1610 sends a data frame 1925, consisting of data, to STA1611 via the second link. Upon receiving the data frame 1925, STA1611 sends an ACK frame 1926 to STA1610 via the second link.

[0206] Figure 20 shows another example 2000 of the procedure described in Figure 19, according to an embodiment. As shown in Figure 20, example 2000 includes STA1610, 1611 and OBSS STA1612. OBSS STA1612 may belong to a different BSS than STA1610, 1611. STA1610, 1611 each include an AP MLD or non-AP MLD that can communicate over multiple links. Similarly, OBSS STA1612 includes an AP MLD or non-AP MLD that can communicate over multiple links. In one example, OBSS STA1612 is within the communication range of STA1611 but not within the communication range of STA1610.

[0207] In one embodiment, STA1610 receives data to be transmitted to STA1611. Based on the fact that the data consists of low-latency traffic, STA1610 transmits a MU-RTS trigger frame 2021 to STA1611 via the first link, requesting that the data be transmitted via the first link, and a MU-RTS trigger frame 2022 to STA1611 via the second link, requesting that the data be transmitted via the second link. In one embodiment, MU-RTS trigger frames 1921 and / or 1922 have a format such as the trigger frame 2200 described later with respect to Figure 22. In one embodiment, MU-RTS trigger frame 2021 includes a second link instruction. In one embodiment, the second link instruction in MU-RTS trigger frame 2021 indicates to STA1611 that the MU-RTS trigger frame 2022 transmitted via the second link transmits the same data as the MU-RTS trigger frame 2021 transmitted via the first link.

[0208] In another embodiment, the MU-RTS trigger frame 2022 includes a first link instruction. In one embodiment, the first link instruction in the MU-RTS trigger frame 2022 indicates to the STA 1611 that it requests the MU-RTS trigger frame 2021 transmitted over the first link to transmit the same data as the MU-RTS trigger frame 2022 transmitted over the second link. Such an instruction in the MU-RTS trigger frame 1921 or 1922 allows the STA 1611 to link the MU-RTS trigger frame 1921 and the MU-RTS trigger frame 1922 as relating to the same data.

[0209] In another embodiment, MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022 includes instructions for a CTS response option for use with STA1611. In one embodiment, the CTS response option includes STA1611 responding to either MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022. In another embodiment, the CTS response option includes STA1611 responding to both MU-RTS trigger frame 2021 and MU-RTS trigger frame 2022.

[0210] In one embodiment, STA1611 receives MU-RTS trigger frame 2022 via a second link before receiving MU-RTS trigger frame 2021 via a first link. In another embodiment, STA1611 responds to MU-RTS trigger frame 2022 by transmitting CTS frame 2023 via the second link if its NAV indicates an idle state. In yet another embodiment, STA1611 receives MU-RTS trigger frame 2022 via the second link simultaneously with or after MU-RTS trigger frame 2021 via the first link. In one embodiment, STA1611 selects an appropriate link (e.g., a second link) for CTS transmission (e.g., depending on traffic parameters) and transmits only one CTS frame via the selected link (e.g., a second link). The selection of only one appropriate link for CTS transmission is triggered by MU-RTS frames 2021 and 2022 having a special format defined in Figure 22. In one embodiment, MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022 includes instructions for a CTS response option for use with STA1611. In one embodiment, the CTS response option includes STA1611 responding to either MU-RTS trigger frame 2021 or MU-RTS trigger frame 2022. In another embodiment, the CTS response option includes STA1611 responding to both MU-RTS trigger frame 2021 and MU-RTS trigger frame 2022.

[0211] In one embodiment, STA1610 receives CTS frame 2023 from STA1611 via a second link in response to MU-RTS trigger frame 2022. Upon hearing CTS frame 2023, OBSS STA1612 sets its NAV to the second link. STA1610 then sends data frame 2024 to STA1611 via the second link. Upon receiving data frame 2024, STA1611 sends ACK frame 2025 to STA1610 via the second link.

[0212] In one embodiment, STA1611 transmits a single CTS frame 2023 over the second link by selecting a CTS response option that responds to only one of MU-RTS frames 2021 and 2022. STAs within STA1611's communication range (including OBSS STA1612) do not set their NAVs to the first link and can communicate over the first link while transmitting data frame 2024 and ACK frame 2025.

[0213] Figure 21 shows an example of a common information field 2100 for a basic multilink element according to an embodiment. The basic multilink element is transmitted from one STA to another STA to inform the STA of its function. As shown in Figure 21, the common information field 2100 includes a common 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 function subfield, an MLD function and operation subfield, an AP MLD ID subfield, and an extended MLD function and operation subfield.

[0214] In one implementation, the MLD function and reserved bits of the operation subfield are used to signal the operation mode for transmitting data consisting of low-latency traffic protected by RTS / CTS exchange (e.g., option-1 or option-2 as described in Figure 15 above).

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

[0216] As shown in Figure 22, the MU-RTS trigger frame example 2200 includes a frame control subfield, a duration subfield, a recipient address (RA) subfield, a sender address (TA) subfield, a common information subfield, a padding subfield, an FCS subfield, and a user information list subfield.

[0217] In one embodiment, the user information list subfield indicates one or more links other than the link on which the MU-RTS trigger frame 2200 is 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 over one or more other links are requesting that they transmit the same data as the MU-RTS trigger frame 2200. In one example, the indication of one or more other links (e.g., 2.4GHz band, 5GHz band, 6GHz band, etc.) is transmitted in one or more reserved bits of the user information list subfield.

[0218] In some examples, the user information list subfield further includes instructions for the CTS response options to be used by the receiving STA. Therefore, the CTS response options may include the receiving STA responding to only one of several received MU-RTS trigger frames, or the second STA responding to each of several received MU-RTS trigger frames. In some examples, the CTS response options are transmitted using reserved bits in the user information list subfield.

[0219] Figure 23 shows an example process 2300 according to an embodiment. Example process 2300 is provided for illustrative purposes only and is not limiting. Example process 2300 is performed by a first STA, such as STA1610. The first STA has multilink capabilities (i.e., it includes a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA is a transmitting STA that has data to transmit to a second STA. The second STA may also include an MLD. The first and second STAs communicate via at least a first link and a second link.

[0220] As shown in Figure 23, in step 2310, process 2300 sends a first RTS frame to the second STA requesting that the first STA transmit first data to the second STA via the first link. In one embodiment, the first STA and the second STA each include an AP MLD or a non-AP MLD that can communicate over multiple links. In one embodiment, the first data consists of low-latency traffic.

[0221] In step 2320, process 2300 includes the first STA sending a second RTS to the second STA, requesting the second STA to send the first data via the second link, based on the first STA not receiving a first CTS frame from the second STA within a certain period of time since sending the first RTS frame and the first data consisting of low-latency traffic.

[0222] In one embodiment, the period is shorter than the CTS timeout interval (and according to formula (1) above). In another embodiment, the period is longer than or equal to the CTS timeout interval (and according to formula (1) above).

[0223] In one embodiment, process 2300 further includes the first STA receiving a second CTS frame from the second STA via a second link in response to a second RTS frame. In one embodiment, process 2300 further includes the first STA transmitting first data to the second STA via a second link.

[0224] In one embodiment, process 2300 further includes the first STA sending a third RTS frame to the second STA requesting the second STA to transmit first data over the first link. In one embodiment, the first STA sends a third RTS frame when it has not received a first CTS frame from the second STA within a certain period of time since sending the first RTS frame, and the first data consists of low-latency traffic. In one embodiment, the third RTS frame may overlap with the second RTS frame.

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

[0226] In another embodiment, the second and third RTS frames consist of MU-RTS trigger frames. In one embodiment, process 2300 further includes the first STA receiving a second CTS frame from the second STA via a second link in response to the second MU-RTS trigger frame. In one embodiment, process 2300 further includes the first STA transmitting the first data to the second STA via the second link.

[0227] Figure 24 shows an example process 2400 according to an embodiment. Example process 2400 is provided for illustrative purposes only and is not limiting. Example process 2400 is performed by a first STA, such as STA1610. The first STA has multilink capabilities (i.e., it includes a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA is a transmitting STA that has data to transmit to a second STA. The second STA may also include an MLD. The first and second STAs communicate via at least a first link and a second link.

[0228] As shown in Figure 24, process 2400 includes, in step 2410, receiving data from the first STA to be transmitted to the second STA.

[0229] In step 2420, process 2400 includes sending a first MU-RTS trigger frame to the second STA requesting the second STA to transmit data via the first link, and a second MU-RTS trigger frame requesting the second STA to transmit data via the second link, based on the fact that the data consists of low-latency traffic. In one embodiment, the first MU-RTS trigger frame includes a second link instruction. In one embodiment, the second link instruction in the first MU-RTS trigger frame indicates to the second STA that the second MU-RTS trigger frame transmitted via the second link transmits the same data as the first MU-RTS trigger frame transmitted via the first link.

[0230] Similarly, in one embodiment, the second MU-RTS trigger frame includes an instruction for the first link. In one embodiment, the instruction for the first link in the second MU-RTS trigger frame indicates that the second STA is requesting that the first MU-RTS trigger frame transmitted over the first link transmit the same data as the second MU-RTS trigger frame transmitted over the second link.

[0231] In another embodiment, the first MU-RTS trigger frame or the second MU-RTS trigger frame includes an instruction for a CTS response option to be used by the second STA. In one embodiment, the CTS response option includes the second STA responding to either the first MU-RTS trigger frame or the second MU-RTS trigger frame. In another embodiment, the CTS response option includes the second STA responding to both the first and second MU-RTS trigger frames.

[0232] In one embodiment, process 2400 further includes the first STA receiving a first CTS frame from the second STA via the second link in response to a second MU-RTS trigger frame. In one embodiment, process 2400 further includes the first STA transmitting a data frame consisting of data to the second STA via the second link.

[0233] Figure 25 shows an example process 2500 according to an embodiment. Example process 2500 is provided for illustrative purposes only and is not limiting. Example process 2500 is performed by a first STA, such as STA1611. Example process 2500 is performed by a first STA having multilink capabilities (i.e., comprising a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA is a receiving STA that receives data transmissions from a second STA. The second STA may also comprise an MLD. The first and second STAs communicate via at least a first link and a second link.

[0234] As shown in Figure 25, process 2500 includes, in step 2510, receiving from the second STA a first MU-RTS trigger frame via the first link requesting the first STA to transmit data via the first link, and a second MU-RTS trigger frame via the second link requesting the first STA to transmit data via the second link. In one embodiment, the first MU-RTS trigger frame includes an instruction for the second link. In one embodiment, the instruction for the second link in the first MU-RTS trigger frame indicates that the second STA is requesting the second MU-RTS trigger frame transmitted via the second link to transmit the same data as the first MU-RTS trigger frame transmitted via the first link.

[0235] Similarly, in one embodiment, the second MU-RTS trigger frame includes an instruction for the first link. In one embodiment, the instruction for the first link in the second MU-RTS trigger frame indicates that the second STA is requesting that the first MU-RTS trigger frame transmitted over the first link transmit the same data as the second MU-RTS trigger frame transmitted over the second link.

[0236] In another embodiment, the first MU-RTS trigger frame or the second MU-RTS trigger frame includes an instruction for a CTS response option to be used by the second STA. In one embodiment, the CTS response option includes the second STA responding to either the first MU-RTS trigger frame or the second MU-RTS trigger frame. In another embodiment, the CTS response option includes the second STA responding to both the first and second MU-RTS trigger frames.

[0237] In step 2520, process 2500 includes discarding the first MU-RTS trigger frame based on the fact that the second MU-RTS trigger frame contains instructions for the first link. In one embodiment, discarding the first MU-RTS trigger frame includes not sending the second CTS frame over the first link in response to the first MU-RTS trigger frame.

[0238] In step 2530, process 2500 includes the first STA transmitting a first CTS frame to the second STA via the second link in response to a second MU-RTS trigger frame. In one embodiment, process 2500 further includes the first STA receiving a data frame consisting of data from the second STA via the second link.

[0239] 1. The first wireless device transmits a first request frame to the second wireless device via the first link, requesting that the second wireless device transmit first data via the first link. One method includes the step of the first wireless device sending a second request frame to the second wireless device via the second link, based on the first wireless device not receiving a first response frame from the second wireless device within a certain period of time since sending the first request frame and the first data consisting of low-latency traffic.

[0240] One method includes the steps of: the first wireless device transmitting a first request frame to the second wireless device via the first link, requesting that the second wireless device transmit first data via the first link; and the first wireless device transmitting a second request frame to the second wireless device via the second link, based on the fact that the first wireless device has not received a first response frame from the second wireless device within a certain period of time since transmitting the first request frame and that the first data consists of low-latency traffic.

[0241] This method includes the steps of: the first wireless device receiving 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 transmitting the first data to the second wireless device via the second link.

[0242] This method includes the steps of: the first wireless device receiving 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 transmitting the first data to the first wireless device via the second link.

[0243] In this method, the above period is shorter than the response timeout interval.

[0244] This method includes the step of the first wireless device sending a third request frame to the second wireless device via the first link, requesting that the first data be sent to the second wireless device via the first link.

[0245] In this method, the third request frame described above overlaps with the second request frame described above.

[0246] In this method, the above period is longer than or equal to the response timeout interval.

[0247] In this method, the second and third request frames described above consist of MU-RTS trigger frames.

[0248] This method includes the step of the first wireless device receiving a second response frame from the second wireless device via the second link in response to the second request frame.

[0249] This method includes the step in which the first wireless device receives a third response frame from the second wireless device via the first link in response to the third request frame.

[0250] The method includes the steps of: a first wireless device receiving data to transmit to a second wireless device; the first wireless device transmitting a first Multi-User Transmit Request (MU-RTS) trigger frame to the second wireless device via the first link, based on the data consisting of low-latency traffic, requesting the second wireless device to transmit the data via the first link; and the first wireless device transmitting a second MU-RTS trigger frame to the second wireless device via the second link, requesting the second wireless device to transmit the data via the second link.

[0251] This method includes the step of the first wireless device receiving a first response frame from the second wireless device via the second link in response to the second MU-RTS trigger frame.

[0252] The method includes the steps of: the first wireless device (wireless device) receiving a first multi-user transmission request (MU-RTS) trigger frame from a second wireless device via the first link, requesting that data be transmitted to a first wireless device via the first link; the first wireless device receiving a second MU-RTS trigger frame from the second wireless device via the second link, requesting that the data be transmitted to the first wireless device via the second link; discarding the first MU-RTS trigger frame based on the fact that the second MU-RTS trigger frame includes instructions for 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.

[0253] In this method, the step of discarding the first MU-RTS trigger frame includes the step of not sending a second response frame over the first link in response to the first MU-RTS trigger frame.

[0254] This method includes the step of the first wireless device transmitting a data frame composed of the above data to the second wireless device via the second link.

[0255] In this method, the first MU-RTS trigger frame includes instructions for the second link.

[0256] In this method, the instruction for the second link in the first MU-RTS trigger frame indicates that the second wireless device is requesting that the second MU-RTS trigger frame transmitted via the second link transmit the same data as the first MU-RTS trigger frame transmitted via the first link.

[0257] In this method, the second MU-RTS trigger frame includes the instructions for the first link.

[0258] In this method, the instruction for the first link in the second MU-RTS trigger frame indicates a request to the second wireless device to transmit the same data as the first MU-RTS trigger frame transmitted via the first link and the second MU-RTS trigger frame transmitted via the second link.

[0259] In this method, the first MU-RTS trigger frame or the second MU-RTS trigger frame includes an instruction for the CTS response option used by the second wireless device.

[0260] In this method, 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.

[0261] In this method, the CTS response option includes the second wireless device responding to the first MU-RTS trigger frame and the second MU-RTS trigger frame.

[0262] In this method, the request frame is a Send Request (RTS) frame, and the response frame is a Send Allow (CTS) frame.

[0263] When the device functions as a first wireless device (wireless device), some devices perform an operation that includes sending a first request frame to the second wireless device via a first link, requesting that the second wireless device transmit first data via a first link, and, based on the fact that the first wireless device has not received a first response frame from the second wireless device within a certain period of time since the transmission of the first request frame and that the first data consists of low-latency traffic, sending a second request frame to the second wireless device via a second link, requesting that the second wireless device transmit the first data via a second link.

[0264] When the device functions as a first wireless device, some devices perform an operation that includes sending a first request frame to the second wireless device via the first link, requesting that the second wireless device transmit first data via the first link, and, based on the fact that the first response frame is not received from the second wireless device within a certain period of time from the transmission of the first request frame and that the first data consists of low-latency traffic, sending a second request frame to the second wireless device via the second link, requesting that the second wireless device transmit the first data via the second link.

[0265] When a device functions as a first wireless device, it performs an operation that includes receiving data to be transmitted to a second wireless device, and, based on the fact that the data consists of low-latency traffic, transmitting to the second wireless device a first Multi-User Transmit Request (MU-RTS) trigger frame via the first link requesting the second wireless device to transmit the data via the first link, and a second MU-RTS trigger frame via the second link requesting the second wireless device to transmit the data via the second link.

[0266] When the device functions as a first wireless device, there is a device that performs an operation that includes sending a first Multi-User Transmit Request (MU-RTS) trigger frame from the second wireless device over the first link requesting that data be sent to the device over the first link, sending a second MU-RTS trigger frame from the second wireless device over the second link requesting that the data be sent to the device over the second link, discarding the first MU-RTS trigger frame based on the fact that the second MU-RTS trigger frame contains instructions for the first link, and sending a first response frame over the second link to the second wireless device in response to the second MU-RTS trigger frame.

[0267] The above wireless device is a station (STA) compliant with IEEE 802.11.

[0268] In this device, the above request frame is a Send Request (RTS) frame, and the above response frame is a Send Allow (CTS) frame.

[0269] There is a wireless network that has multiple devices of the above type.

[0270] There are computer program products that are stored on computer-readable media and perform the above-described method when running on a computing device.

Claims

1. The first wireless device transmits a first request frame to the second wireless device via the first link, requesting that the second wireless device transmit first data via the first link. The first wireless device transmits a second request frame to the second wireless device via the second link, based on the first wireless device not receiving a first response frame from the second wireless device within a certain period of time since transmitting the first request frame and the first data consisting of low-latency traffic. Methods that include...

2. The method according to claim 1, comprising the steps of: the first wireless device receiving 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 transmitting the first data to the second wireless device via the second link.

3. The method according to claim 1 or 2, further comprising the step of the first wireless device receiving a second response frame from the second wireless device via the second link in response to the second request frame.

4. The method according to any one of claims 1 to 3, further comprising the step of the second wireless device transmitting the first data to the first wireless device via the second link.

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

6. The method according to any one of claims 1 to 5, further comprising the step of the first wireless device transmitting a third request frame to the second wireless device via the first link, requesting the second wireless device to transmit the first data 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 claim 6 or 7, wherein the period is longer than or equal to the response timeout interval.

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

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

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

12. The first wireless device receives data to transmit to the second wireless device, Based on the fact that the aforementioned data consists of low-latency traffic, The first wireless device transmits a first multi-user transmission request (MU-RTS) trigger frame to the second wireless device via the first link, requesting that the aforementioned data be transmitted to the second wireless device via the first link. The first wireless device transmits a second MU-RTS trigger frame to the second wireless device via the second link, requesting that the aforementioned data be transmitted to the second wireless device via the second link. Methods that include...

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

14. The first wireless device (wireless device) receives a first multi-user transmission request (MU-RTS) trigger frame from the second wireless device via the first link, requesting that data be transmitted to the first wireless device via the first link. The first wireless device (wireless device) receives from the second wireless device via the second link a second MU-RTS trigger frame requesting the first wireless device to transmit the aforementioned data via the second link, The steps include discarding the first MU-RTS trigger frame based on the fact that the second MU-RTS trigger frame includes instructions for the first link, The steps include: in response to the second MU-RTS trigger frame, the first wireless device transmits a first response frame to the second wireless device via the second link; Methods that include...

15. The method according to claim 14, wherein the step of discarding the first MU-RTS trigger frame includes the step of not transmitting a second response frame over the first link in response to the first MU-RTS trigger frame.

16. The method according to claim 14 or 15, further comprising the step of the first wireless device transmitting a data frame comprising the data to the second wireless device via the second link.

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

18. The method according to claim 17, wherein the instruction for the second link in the first MU-RTS trigger frame indicates a request to the second wireless device to transmit the same data as the first MU-RTS trigger frame transmitted over the second link.

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

20. The method according to claim 19, wherein the instruction of the first link in the second MU-RTS trigger frame indicates a request to the second wireless device to transmit the same data as the first MU-RTS trigger frame transmitted over the first link and the second MU-RTS trigger frame transmitted over the second link.

21. The method according to any one of claims 14 to 20, wherein the first MU-RTS trigger frame or the second MU-RTS trigger frame includes an instruction for a CTS response option to be used 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 claim 21 or 22, wherein the CTS response option includes 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 one of claims 1 to 23, wherein the request frame is a request to transmit (RTS) frame and the response frame is a transmit permission (CTS) frame.

25. When the device functions as the first wireless device, Sending a first request frame to the second wireless device via the first link, which requests that the first data be sent to the second wireless device via the first link, Based on the fact that the first response frame is not received from the second wireless device within a certain period of time from the transmission of the first request frame and that the first data consists of low-latency traffic, a second request frame is transmitted to the second wireless device via the second link requesting that the first data be transmitted to the second wireless device via the second link. A device that performs operations including those mentioned above.

26. When the device functions as the first wireless device, Sending a first request frame to the second wireless device via the first link, which requests that the first data be sent to the second wireless device via the first link, Based on the fact that the first response frame is not received from the second wireless device within a certain period of time from the transmission of the first request frame and that the first data consists of low-latency traffic, a second request frame is transmitted to the second wireless device via the second link, requesting that the first data be transmitted to the second wireless device via the second link. A device that performs operations including those mentioned above.

27. When the device functions as the first wireless device, Receiving data to transmit to a second wireless device, Based on the fact that the aforementioned data consists of low-latency traffic, A first multi-user transmission request (MU-RTS) trigger frame requesting the transmission of the aforementioned data to the second wireless device via the first link is transmitted to the second wireless device via the first link. A second MU-RTS trigger frame requesting the transmission of the aforementioned data to the second wireless device via the second link is transmitted to the second wireless device via the second link, A device that performs operations including those mentioned above.

28. When the device functions as the first wireless device, A first Multi-User Transmission Request (MU-RTS) trigger frame requesting the transmission of data to the device via the first link is received from the second wireless device via the first link. Receiving a second MU-RTS trigger frame from a second wireless device via the second link, which requests that the data be transmitted to the device via the second link, Based on the fact that the second MU-RTS trigger frame includes the instruction for the first link, the first MU-RTS trigger frame is discarded, In response to the second MU-RTS trigger frame, a first response frame is transmitted to the second wireless device via the second link. A device that performs operations including those mentioned above.

29. The wireless device is a station (STA) compliant with IEEE 802.11, according to any one of claims 25 to 28.

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

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

32. A computer program stored in a computer-readable medium that causes a computing device to perform the method according to any one of claims 1 to 24 when the device is running.

Images