Multilink protection using NAV control

Abstract

Methods, devices, systems, and computer program products are provided to enable flexible NAV configuration of multilink devices. The method includes a first radio device receiving a first Transmit Request (RTS) frame from a second radio device via a first link requesting the transmission of data to the first radio device via the first link, and a second RTS frame via a second link requesting the transmission of data to the first radio device via the second link. The method also includes the first radio device transmitting a first Transmit Allow (CTS) frame to the second radio device via the first link in response to the first RTS frame, and a second CTS frame via the second link in response to the second RTS frame, and the first radio device transmitting a Conflict-Free Termination (CF Termination) frame via the first link based on the first radio device not receiving data via the first link within a period of time from the transmission of the first CTS frame.

Description

Technical Field

[0001] The present invention relates to wireless networks, and in particular to local area networks, such as local area networks using IEEE802.11 technology, but is not limited thereto.

Background Art

[0002] Modern wireless networks are often deployed at high density, and devices need to adapt to changing situations. In other words, it is desirable to achieve flexibility even with complex devices. Also, additional constraints may arise due to requirements regarding low-latency traffic.

Summary of the Invention

[0003] The inventors have found that when a multi-link device is used and transmission of low-latency traffic is required, a situation may occur where two devices use a multi-link connection, and a third device receives a transmission permission response from one device while not receiving a transmission end notification from the other device. As a result, the third device may refrain from transmitting unnecessarily.

[0004] Accordingly, aspects and embodiments of the present invention are defined in the appended claims.

[0005] In particular, one aspect of the provided method includes a first wireless device receiving a first request to transmit (RTS) frame from a second wireless device via a first link requesting the transmission of data to the first wireless device via the first link, and a second RTS frame via a second link requesting the transmission of data to the first wireless device via the second link; the first wireless device transmitting a first allow to transmit (CTS) frame to the second wireless device via the first link in response to the first RTS frame, and a second CTS frame via the second link in response to the second RTS frame; and the first wireless device transmitting a conflict-free termination (CF termination) frame via the first link based on the fact that the first wireless device has not received data via the first link within a period of time since transmitting the first CTS frame.

[0006] According to one embodiment, in response to a second CTS frame, the first wireless device receives data from the second wireless device via the second link.

[0007] According to one embodiment, the first wireless device transmits an acknowledgment (ACK) frame to the second wireless device via a second link.

[0008] According to one embodiment, the period is longer than the short interframe space (SIFS).

[0009] According to one embodiment, the second RTS frame is superimposed on the first RTS frame.

[0010] According to one embodiment, the first and second RTS frames include a multi-user request to send (MU-RTS) trigger frame.

[0011] According to one embodiment, a first MU-RTS trigger frame or a second MU-RTS trigger frame includes information indicating the transmission of data over a single link, either the first link or the second link.

[0012] According to one embodiment, a first wireless device does not receive data over the first link within a period of time from the transmission of a first CTS frame, and the method further includes the first wireless device transmitting a conflict-free termination (CF termination) frame over the first link.

[0013] In one aspect, a method is provided which includes a first wireless device receiving a first request to transmit (RTS) frame from a second wireless device via a first link requesting the transmission of data to the first wireless device via the first link, and a second RTS frame via a second link requesting the transmission of data to the first wireless device via the second link, the first wireless device transmitting a first allow to transmit (CTS) frame to the second wireless device via the first link in response to the first RTS frame, and a second CTS frame via the second link in response to the second RTS frame, and the first wireless device transmitting a conflict-free termination (CF termination) frame via the first link based on the first wireless device receiving a frame from the second wireless device indicating the transmission of data to the first wireless device via the second link.

[0014] In one aspect, a method is provided which includes a first wireless device transmitting a first request to transmit (RTS) frame to a second wireless device via a first link requesting the transmission of data to the second wireless device via the first link, and a second RTS frame to the second wireless device via a second link requesting the transmission of data to the second wireless device via the second link; the first wireless device receiving a first allow to transmit (CTS) frame from the second wireless device via the first link in response to the first RTS frame, and a second CTS frame via the second link in response to the second RTS frame; and the first wireless device transmitting data to the second wireless device via the second link, on which the first wireless device transmits a frame to the second wireless device indicating the transmission of data to the second wireless device via the second link.

[0015] According to one embodiment, the frame includes a trigger frame.

[0016] According to one embodiment, a trigger frame is transmitted via a first link.

[0017] According to one embodiment, the frame includes a notification instructing a second wireless device to transmit a conflict-free termination (CF termination) frame over a first link.

[0018] According to one embodiment, a notification instructing the transmission of a CF termination frame via a first link is provided in the user information field or common information field of the trigger frame.

[0019] According to one embodiment, the frame includes a data frame containing data.

[0020] According to one embodiment, a data frame is transmitted via a second link.

[0021] According to one embodiment, the frame includes a notification of a first link.

[0022] In accordance with one embodiment, the notification of the first link indicates that data is not transmitted to the second wireless device via the first link.

[0023] In accordance with one embodiment, the notification of the first link is provided within a Universal Signal (U-SIG) field of a physical layer (PHY) header of a frame.

[0024] In accordance with one embodiment, the U-SIG field further includes a link identifier of the first link.

[0025] In accordance with one embodiment, the notification of the first link is provided within an Aggregate Control (A-Control) field of a frame.

[0026] In accordance with one embodiment, the A-Control field is provided within a High Throughput (HT) Control field of a frame.

[0027] In accordance with one embodiment, the frame indicates that data transmission via the first link is not performed.

[0028] In one aspect, a method is provided that includes a first wireless device receiving, from a second wireless device, a first Clear to Send (CTS) frame via a first link and a second CTS frame via a second link; setting a first Network Allocation Vector (NAV) for the first link based on the first CTS frame and setting a second NAV for the second link based on the second CTS frame; and resetting the first NAV for the first link based on receiving a contention-free end from the second wireless device.

[0029] On one side, a method is provided that includes a first wireless device receiving, from a second wireless device, a first request to send (RTS) frame requesting transmission of data to the first wireless device; in response to the first RTS frame, the first wireless device sending a first clear to send (CTS) frame to the second wireless device; and based on the first wireless device not receiving data within a period from the transmission of the first CTS frame, the first wireless device sending a contention free end (CF end) frame.

[0030] On one side, a device is provided that receives, from a second wireless device, a first request to send (RTS) frame requesting transmission of data via a first link, and a second RTS frame requesting transmission of data via a second link; in response to the first RTS frame, sends a first clear to send (CTS) frame to the second wireless device via the first link; in response to the second RTS frame, sends a second CTS frame via the second link; and based on not receiving data via the first link within a period from the transmission of the first CTS frame, sends a contention free end (CF end) frame via the first link.

[0031] In one aspect, a device is provided which the device receives a first request to transmit (RTS) frame from a second wireless device via a first link requesting the transmission of data to the first wireless device via the first link, and receives a second RTS frame via a second link requesting the transmission of data to the first wireless device via the second link, transmits a first allow to transmit (CTS) frame to the second wireless device via the first link in response to the first RTS frame, and transmits a second CTS frame via the second link in response to the second RTS frame, and transmits a conflict-free termination (CF termination) frame via the first link based on the device receiving a frame from the second wireless device indicating the transmission of data to the first wireless device via the second link.

[0032] In one aspect, a device is provided which receives a first request to transmit (RTS) frame from a first radio device requesting the transmission of data to the first radio device, transmits a first allow to transmit (CTS) frame to the first STA in response to the first RTS frame, and the first radio device transmits a conflict-free termination (CF termination) frame based on the fact that it has not received data within a period of time since the transmission of the first CTS frame.

[0033] In one aspect, a device is provided which transmits to a first wireless device a first Transmit Request (RTS) frame via a first link requesting the first wireless device to transmit data via the first link, and a second RTS frame via a second link requesting the first wireless device to transmit data via the second link, and the first wireless device receives a first Transmit Allow (CTS) frame via the first link in response to the first RTS frame, and receives a second CTS frame via the second link in response to the second RTS frame, and transmits to the first wireless device a frame indicating the transmission of data to the first wireless device via the second link.

[0034] In one aspect, a device is provided which the device receives a first transmit permission (CTS) frame from a first radio device via a first link and a second CTS frame via a second link, sets a first network allocation vector (NAV) for the first link based on the first CTS frame, sets a second NAV for the second link based on the second CTS frame, and resets the first NAV for the first link based on receiving a conflict-free termination (CF termination) frame from a second radio device via the first link.

[0035] According to one embodiment, the first and second wireless devices are STAs compliant with the IEEE 802.11 standard.

[0036] In one aspect, a wireless communication system comprising multiple devices described herein is provided.

[0037] In one aspect, a computer program product, which can be stored on a computer-readable medium, is provided, configured to perform the methods described herein when executed on a processor. [Brief explanation of the drawing]

[0038] Some examples of various embodiments of this disclosure will be described with reference to the drawings. [Figure 1] Figure 1 shows several exemplary wireless communication networks in which embodiments of the present disclosure may be implemented. [Figure 2] Figure 2 is a block diagram showing an exemplary implementation of a station (STA) and an access point (AP). [Figure 3] Figure 3 shows an example of a Media Access Control (MAC) frame format. [Figure 4] Figure 4 shows an example of a Quality of Service (QoS) null frame that displays buffer state information. [Figure 5] Figure 5 shows an example of the format for a Physical Layer (PHY) Protocol Data Unit (PPDU). [Figure 6] Figure 6 shows an example including buffer status reporting by the STA, uplink multi-user (MU) transmission scheduling by the AP, and transmission of scheduled uplink transmissions by the STA. [Figure 7] Figure 7 shows an example of a reference model for a multilink device (MLD). [Figure 8] Figure 8 shows an example of AP MLD and its associated non-AP MLD. [Figure 9] Figure 9 shows an example of a multilink setup between AP MLD and non-AP MLD. [Figure 10] Figure 10 shows an example of traffic identifier (TID)-to-link mapping in a multilink communication environment. [Figure 11] Figure 11 shows an example of a Request to Send (RTS) / Authorize to Send (CTS) procedure. [Figure 12] Figure 12 shows an example of an existing procedure that can be used to transmit low-latency data protected by RTS / CTS exchange in a multilink environment. [Figure 13]Figure 13 shows an example of a procedure used to transmit low-latency data protected by multilink RTS / CTS exchange, according to one embodiment. [Figure 14] Figure 14 shows another example of a procedure used to transmit low-latency data protected by multilink RTS / CTS exchange, according to one embodiment. [Figure 15] Figure 15 shows an example of another procedure used to transmit low-latency data protected by multilink RTS / CTS exchange, according to one embodiment. [Figure 16] Figure 16 shows an example of another procedure used to transmit low-latency data protected by multilink RTS / CTS exchange, according to one embodiment. [Figure 17] Figure 17 shows another example of a procedure used to transmit low-latency data protected by multilink RTS / CTS exchange, according to one embodiment. [Figure 18] Figure 18 shows an example of a common information field for a basic multilink element according to one embodiment. [Figure 19] Figure 19 shows an example of a trigger frame that may be used in the embodiment. [Figure 20] Figure 20 shows an example of a universal signal (U-SIG) field that may be used in the embodiment. [Figure 21] Figure 21 shows an example of a process according to one embodiment. [Figure 22] Figure 22 shows another example of the process according to one embodiment. [Figure 23] Figure 23 shows another example of the process according to one embodiment. [Figure 24] Figure 24 shows another example of the process according to one embodiment. [Figure 25] Figure 25 shows another example of the process according to one embodiment. [Modes for carrying out the invention]

[0039] This disclosure presents various embodiments as examples of how to implement the disclosed technology and / or how to implement the disclosed technology in environments and scenarios. Those skilled in the art will understand that various modifications to the form and details are possible without departing from the scope of this disclosure. Those skilled in the art who have read this specification will understand how to implement alternative embodiments. Embodiments are not limited to the exemplary embodiments described herein. Embodiments of this disclosure will be described below with reference to the accompanying drawings. Other embodiments that fall within the scope of this disclosure can be created by combining the limitations, features, and / or elements of the exemplary embodiments disclosed. Drawings focusing on functions and benefits are provided for illustrative purposes only. The disclosed architecture is sufficiently flexible and configurable and can be used in embodiments other than those illustrated. For example, actions enumerated in any flowchart may be reordered or used as options in some embodiments.

[0040] The embodiments may be configured to operate as needed. The disclosed mechanisms may be implemented in, for example, a station, access point, wireless environment, network, or a combination thereof, provided that 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 configuration, packet size, traffic characteristics, and / or a combination thereof. Various exemplary embodiments may be applied if one or more criteria are met. Thus, it may be possible to implement embodiments that selectively implement the disclosed protocols.

[0041] In this disclosure, “a” and “an,” and similar phrases, should be interpreted as “at least one” and “one or more.” Similarly, terms with the suffix “(s)” should be interpreted as “at least one” and “one or more.” In this disclosure, the term “may” should be interpreted as “for example, may.” That is, the word “may” indicates that the following phrase is an example of a number of suitable options that may or may not be adopted in one or more of the various embodiments. In this specification, the terms “comprises” and “consists of” enumerate one or more components of the element being described. The term “comprises” is synonymous with “includes,” and does not exclude the element being described from including components that are not enumerated. In contrast, “consists of” fully enumerates one or more components of the element being described. In this specification, the term “based on” may be interpreted as “at least partially based on” rather than, for example, “based solely on.” In this specification, the term "and / or" represents any possible combination of the enumerated elements. For example, "A, B, and / or C" could mean A, B, C, A and B, A and C, B and C, or A, B and C.

[0042] If A and B are sets, and every element of A is an element of B, then A is called a subset of B. In this specification, only non-empty sets and subsets are considered. For example, possible subsets of B = {STA1, STA2} are {STA1}, {STA2}, and {STA1, STA2}. The phrase "based on" (or similarly "based on at least") indicates that the phrase following "based on" is one example of a number of suitable choices that may or may not be adopted in one or more of the various embodiments. The phrase "in response to" (or similarly "in response to at least") indicates that the phrase following "in response to" is one example of a number of suitable choices that may or may not be adopted in one or more of the various embodiments. The phrase "depending on" (or similarly "depending on at least") indicates that the phrase following "depending on" is one example of a number of suitable choices that may or may not be adopted in one or more of the various embodiments. The phrase “adopt / use” (or similarly “at least adopt / use”) indicates that the phrase following “utilize / use” is one example of a number of suitable options that may or may not be adopted in one or more of the various embodiments.

[0043] The term "configured" can relate to the functionality of a device, regardless of whether the device is operational or not. "Configured" can also refer to specific settings within a device that affect its operational characteristics, regardless of whether the device is operational or not. In other words, hardware, software, firmware, registers, and / or memory values, etc., can be "configured" within a device, giving it specific characteristics, regardless of whether the device is operational or not. Terms such as "a control message that causes ~ in a device" can mean that a control message has parameters that can be used to set specific characteristics or perform specific actions in a device, regardless of whether the device is operational or not.

[0044] In this disclosure, a parameter (also called a field or information element (IE)) may contain one or more information objects. An information object may contain one or more other objects. For example, if 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, if one or more messages / frames contain multiple parameters, this means that some of the multiple parameters are included in at least one of the one or more messages / frames, but not each of the one or more messages / frames.

[0045] Many of the features presented are described as optional elements using "~can be obtained" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly enumerate all possible permutations obtained by selecting from the set of optional elements. This disclosure should be interpreted as explicitly disclosing all such permutations. For example, a system described as having three optional elements can be embodied in seven different forms: having only one of the three elements, having any two of the three elements, or having all three elements.

[0046] Many of the elements described in the disclosed embodiments can be implemented as modules, where a module is defined as an element that performs a predefined function and has predefined interfaces with other elements. Modules described in this disclosure can be implemented in hardware, software combined with hardware, firmware, wetware (e.g., hardware with biological elements), or a combination thereof, and these may be operationally equivalent. For example, a module can be implemented as a software routine written in a computer language (such as C, C++, Fortran, Java, Basic, or Matlab) configured to run on a hardware machine, or as a modeling / simulation program such as Simulink, Stateflow, GNU Octave, or LabVIEW MathScript. Modules can also be implemented using physical hardware, including 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 composite programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed in languages ​​such as assembly, C, or C++. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs) such as VHSIC (VHDL) or Verilog, which connect multiple internal hardware modules with limited functionality on the programmable device. These techniques are often used in combination to achieve the results of the functional modules.

[0047] Figure 1 shows several exemplary wireless communication networks in which embodiments of the present disclosure may be implemented.

[0048] As shown in Figure 1, an exemplary wireless communication network may include an IEEE (Institute of Electrical and Electronic Engineers) 802.11 (WLAN) infrastructure network 102. The WLAN infrastructure network 102 may include one or more basic service sets (BSSs) 110 and 120 and a distribution system (DS) 130.

[0049] BSS110-1 and 110-2 each include a set of access points (APs or AP STAs) and at least one station (STA or non-AP STA). For example, 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 for mutual communication.

[0050] The DS130 may be configured to connect BSS110-1 and BSS110-2. Thus, the DS130 can enable an Extended Service Set (ESS) 150. Within the ESS 150, AP104-1 and 104-2 can be connected via the DS130 and have the same Service Set Identifier (SSID).

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

[0052] The exemplary wireless communication network shown in Figure 1 may further include one or more ad-hoc networks or independent basic service sets (IBSS). An ad-hoc network or IBSS is a network containing multiple STAs that are within each other's communication range. These multiple STAs are configured to communicate with each other using direct peer-to-peer communication (i.e., communication without access points).

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

[0054] An STA as a specified functional medium may include a media access control (MAC) layer compliant with the IEEE 802.11 standard. A physical layer interface for the wireless medium may be used between APs and non-AP stations (STAs). An STA may be referred to using a variety of other terms, such as mobile terminal, wireless device, wireless transceiver unit (WTRU), user equipment (UE), mobile station (MS), mobile subscriber unit, or user. For example, the term "user" may be used to refer to an STA participating in uplink multi-user multiple input multiple output (MU-MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmissions.

[0055] A Physical Layer (PHY) Protocol Data Unit (PPDU) may be a composite structure including a PHY preamble and a payload in the form of a PLCP Service Data Unit (PSDU). For example, a PSDU may include a PHY Convergence Protocol (PLCP) preamble and header, and / or one or more MAC Protocol Data Units (MPDUs). Information provided in the PHY preamble can be used by a receiving device to decode subsequent data within the PSDU. When a PPDU is transmitted over a bonded channel (a channel formed by channel bonding), the preamble fields may be duplicated and transmitted on each of the multiple configuration channels. A PHY preamble may include both a legacy portion (or "legacy preamble") and a non-legacy portion (or "non-legacy preamble"). The legacy preamble may be used for applications such as packet discovery, automatic gain control, and channel estimation. The legacy preamble may also be used to maintain compatibility with legacy devices. The format, encoding, and information of the non-legacy portion of the preamble are based on the specific IEEE 802.11 protocol used for transmitting the payload.

[0056] The frequency band may include one or more subbands or frequency channels. For example, a PPDU compliant with the IEEE 802.11n, 802.11ac, 802.11ax, and / or revised 802.11be standards may be transmitted over the 2.4 GHz, 5 GHz, and / or 6 GHz bands, each band of which may be divided into multiple 20 MHz channels. The PPDU may be transmitted over a physical channel having a minimum bandwidth of 20 MHz. Wider channels may be formed by channel bonding. For example, by combining multiple 20 MHz channels, the PPDU can be transmitted over a physical channel having a bandwidth of 40 MHz, 80 MHz, 160 MHz, or 520 MHz.

[0057] Figure 2 is a block diagram showing exemplary implementations of STA210 and AP260. As shown in Figure 2, STA210 may include at least one processor 220, memory 230, and at least one transceiver 240. AP260 may include at least one processor 270, memory 280, and at least one transceiver 290. The processors 220 / 270 may be operationally connected to the memory 230 / 280 and / or the transceivers 240 / 290.

[0058] Processor 220 / 270 may implement the functions of the PHY layer, MAC layer, and / or Logic Link Control (LLC) layer of the corresponding device (STA210 or AP260). Processor 220 / 270 may include one or more processors and / or one or more controllers. These one or more processors and / or controllers may include, for example, a general-purpose processor, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a logic circuit, or a chipset.

[0059] Memory 230 / 280 may include read-only memory (ROM), random access memory (RAM), flash memory, memory cards, storage media, and / or other storage units. Memory 230 / 280 may include one or more non-temporary computer-readable media. Memory 230 / 280 may also store computer program instructions or code executable by the processor 220 / 270 to perform one or more operations or embodiments described herein. Memory 230 / 280 may be implemented (or located) within the processor 220 / 270 or implemented (or located) outside the processor 220 / 270. Memory 230 / 280 may be operationally connected to the processor 220 / 270 via various means known in the art.

[0060] The transceivers 240 / 290 may be configured to transmit and receive radio signals. In one embodiment, the transceivers 240 / 290 may implement the PHY layer of the corresponding device (STA210 or AP260). In one embodiment, the STA210 and / or AP260 may be multilink devices (MLDs) capable of operating over multiple links as defined in the IEEE 802.11 standard. Thus, the STA210 and / or AP260 can each implement multiple PHY layers. These multiple PHY layers can be implemented using one or more transceivers 240 / 290.

[0061] Figure 3 shows an example of the MAC frame format. During operation, the STA may construct a subset of MAC frames for transmission and, during verification, decode a subset of received MAC frames. The specific subset of frames that the STA may construct and / or decode may be determined by the features that the STA supports. The STA may verify received MAC frames using the frame check sequence (FCS) contained within the frame and interpret specific fields from the MAC header of all frames.

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

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

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

[0065] The size and placement of the protocol version subfield remain constant across all revisions of the IEEE 802.11 standard. The value of the protocol version subfield in MAC frames is 0.

[0066] The type subfield and subtype subfield together identify the function of a MAC frame. There are three frame types: control frames, data frames, and management frames. Each frame type has multiple subtypes defined. The bits in the subtype subfield are used to indicate a specific variation 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. If the QoS subfield is set to 1, it indicates a QoS data frame, which is a data frame that includes a QoS control field in the MAC header. If the second MSB of the subtype field, i.e., bit 6 (B6) of the frame control field, is set to 1 in the data subtype, it indicates a data frame that does not include the frame body field.

[0067] The "To DS" subfield indicates whether the data frame is destined for a distribution system (DS). The "From DS" subfield indicates whether the data frame originated from a DS.

[0068] In all data frames or management frames where another fragment follows a MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) transmitted by a MAC frame, the "More Fragments" subfield is set to 1. In all other frames where the "More Fragments" subfield exists, the "More Fragments" subfield is set to 0.

[0069] For data frames or management frames that are retransmissions of preceding frames, the retransmission subfield is set to 1. For all other frames where a retransmission subfield exists, the retransmission subfield is set to 0. The receiving STA uses this notification to assist in the duplicate frame removal process. These rules do not apply to frames sent by the STA under a block agreement.

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

[0071] The "More Data" subfield indicates to an STA in power saving (PS) mode that bufferable units (BUs) are being buffered by the AP for that STA. 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 buffered BU for that STA.

[0072] If the frame body field contains information processed by the cryptographic encapsulation algorithm, the protected frame subfield is set to 1.

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

[0074] 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 power-saving polling (PS-Poll) subtype control frame, the 14 least significant bits (LSB) of the duration / ID field contain the association identifier (AID) of the STA that sent the frame, 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 how long the STA must delay access to the shared medium.

[0075] The MAC frame format can contain up to four address fields. These address fields are used to identify the Basic Service Set Identifier (BSSID), Source Address (SA), Destination Address (DA), Transmitter Address (TA), and Recipient Address (RA). A particular frame may not contain all address fields. The usage of a particular address field may be determined by its relative position within the MAC header, regardless of the address type it contains. Specifically, Address 1 always identifies the recipient, the destination of the frame, and Address 2 (if present) always identifies the sender of the frame.

[0076] The sequence control field contains two subfields: the sequence number subfield and the fragment number subfield. The sequence number subfield within a data frame indicates the sequence number of the MSDU (if not an Aggregated MSDU (A-MSDU)) or A-MSDU. The sequence number subfield within a management frame indicates the sequence number of that 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 A-MSDUs, or MPDUs containing non-fragmented MSDUs or MMPDUs, the fragment number is set to 0. The fragment number remains constant across all retransmissions of the fragment.

[0077] 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 contain other QoS-related information about the frame, including A-MSDU-related and mesh-related information. This information can 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 within the subtype subfield is set to 1.

[0078] The HT control field is included in the QoS data frame, QoS null frame, and management frame, which are determined by the +HTC subfield of the frame control field.

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

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

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

[0082] The QoS control fields may include a Traffic Identifier (TID) subfield, an ACK Policy Indicator subfield, and a Queue Size subfield (or a Transmit Opportunity (TXOP) Duration Request subfield).

[0083] The TID subfield identifies the TC or TS of the traffic for which a TXOP is being requested, by setting the TXOP duration request subfield or the queue size subfield. The encoding of the TID subfield depends on the access policy (for example, in the Extended Distributed Channel Access (EDCA) access policy, values ​​from 0 to 7 are allowed to identify the user priority of the TC or TS).

[0084] The ACK policy indicator subfield, along with other information, identifies the ACK policy applied when sending the MPDU (e.g., normal ACK, implicit block ACK request, no ACK, block ACK, etc.).

[0085] The queue size subfield is an 8-bit field indicating the amount of traffic for a particular TC or TS buffered by the STA for transmission to the AP, identified by the recipient address of the frame containing the subfield. The queue size subfield is included in QoS null frames sent by the STA when bit 4 of the QoS control field is set to 1. The AP can use the information contained in the queue size subfield to determine the TXOP period to allocate to the STA, or the uplink (UL) resources to allocate to the STA.

[0086] For frames sent by non-high efficiency (non-HE) STAs, or frames sent to non-HE STAs, the following rules may apply to the queue size value.

[0087] The queue size value represents the approximate total size of all MSDUs and A-MSDUs (excluding MSDUs or A-MSDUs included in the current QoS data frame) buffered by the STA in a delivery queue used for MSDUs and A-MSDUs that have the same TID value as indicated in the TID subfield of the QoS control field. It is rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets.

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

[0089] For all sizes exceeding 64,768 octets, a queue size value of 254 is used.

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

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

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

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

[0094] The STA calculates the queue size QS from the scaling factor SF and unscaled value UV included in the received QoS control field using the following formula. QS= 16 × UV (when SF=0) 1024 + 256 × UV (when SF=1) 17408 + 2048 × UV (when SF=2) 148480 + 32768 × UV (if SF = 3 and UV < 62) 2147328 (when SF=3 and UV=62) Not specified or unknown (if SF=3 and UV=63)

[0095] The TXOP Duration Request subfield, which may be included instead of the queue size subfield, indicates the duration in 32 microseconds (μs) that the sending STA deems necessary for the next TXOP for the specified TID. If the TXOP Duration Request subfield is set to 0, it indicates that no TXOP is requested for the specified TID within the current service period (SP). If set to a non-zero value, it indicates the requested TXOP duration in 32 μs increments, within the range of 32 μs to 8160 μs.

[0096] The HT control field may include a BSR control subfield that may contain buffer state information used for UL MU operation. The BSR control subfield may consist of the Access Category Index (ACI) bitmap subfield, Delta TID subfield, ACI High subfield, Scaling Factor subfield, Queue Size High subfield, and Queue Size All subfield of the HT control field.

[0097] The ACI bitmap subfield indicates the access category (AC) for which the buffer state is reported (e.g., B0: Best Effort (AC_BE), B1: Background (AC_BK), B2: Video (AC_VI), B3: Audio (AC_VO), etc.). Each bit in the ACI bitmap subfield is set to 1 if the buffer state for the corresponding AC is included in the queue size all subfield, and to 0 otherwise. However, if the ACI bitmap subfield is 0 and the delta TID subfield is 3, the buffer states for all 8 TIDs are included.

[0098] The Delta TID subfield, along with the value of the ACI bitmap subfield, indicates the number of TIDs for which the STA reports the buffer state.

[0099] The ACI high subfield indicates the ACI of the AC whose BSR is shown in the queue size high subfield. The mapping from ACI values ​​to ACs is defined as follows: ACI value 0 corresponds to AC_BE, ACI value 1 corresponds to AC_BK, ACI value 2 corresponds to AC_VI, and ACI value 3 corresponds to AC_VO.

[0100] The scaling factor subfield shows the octets (SF) of the queue size high subfield and queue size all subfield.

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

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

[0103] The queue size values ​​for the queue size high subfield and queue size all subfield represent the total size of all MSDUs and A-MSDUs (including MSDUs or A-MSDUs included in the same PSDU as the frame containing the BSR control subfield) buffered by the STA in 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, and are rounded up to the nearest multiple of the SF octet.

[0104] A queue size value of 254 in the queue size high subfield and queue size all subfield indicates that the amount of buffered traffic exceeds 254 × SF octets. A queue size value of 255 indicates that the amount of buffered traffic is unspecified or unknown. In QoS dataframes containing fragments, the queue size value may remain constant even if the amount of queue traffic changes between subsequent fragments being sent.

[0105] The MAC service enables peer entities to exchange MSDUs. To support this service, the local MAC uses the underlying PHY layer service to forward MSDUs to the peer MAC entity. This asynchronous MSDU forwarding is performed without a connection.

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

[0107] A PSDU may contain one or more MPDUs, such as a QoS data frame, MMPDU, MAC control frame, or QoS null frame. In the case of an MPDU carrying a QoS data frame, the frame body of that MPDU may contain an MSDU or A-MSDU.

[0108] By default, MSDU forwarding is performed on a best-effort basis; that is, there is no guarantee that the transmitted MSDU will be delivered. However, the QoS feature uses a Traffic Identifier (TID) to specify a service distinct for each MSDU.

[0109] STA can differentiate the delivery of MSDUs according to the designated traffic category (TC) or traffic stream (TS) of each individual MSDU. The MAC sublayer entity determines the user priority (UP) of an MSDU based on the TID value assigned to the MSDU. The QoS function supports eight UP values. The range of UP values ​​is 0 to 7, forming an ordered priority sequence, with 1 being the lowest and 7 being the highest, and 0 being between 2 and 3.

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

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

[0112] The buffer state reported in the QoS control field includes the queue size value for a specific TID. The buffer state reported in the BSR control field includes the ACI bitmap, delta TID, high priority AC, and two queue sizes.

[0113] The STA can report the buffer status to the AP within the QoS control field of the transmitted QoS null frame and QoS data frame, and (if present) within the BSR control subfield of the transmitted QoS null frame, QoS data frame, and management frame as defined below.

[0114] The STA can report the queue size for a specific TID in the queue size subfield of the QoS control field of the transmitted QoS data frame or QoS null frame. The STA can set the queue size subfield to 255 to indicate that the queue size for that TID is unknown / unspecified. The STA can aggregate multiple QoS data frames or QoS null frames within an A-MPDU and report the queue sizes for different TIDs.

[0115] If the AP has indicated that it supports receiving the BSR control subfield, the STA can report the buffer status within the BSR control subfield of the transmit frame.

[0116] High-efficiency (HE) STAs can report the queue size of a preferred AC, indicated in the ACI high subfield, within the queue size high subfield of the BSR control subfield. The STA can set the queue size high subfield to 255 to indicate that the queue size of that AC is unknown / unspecified.

[0117] The HE STA can report the queue size of ACs indicated by the ACI bitmap subfield within the queue size all subfield of the BSR control subfield. The STA can set the queue size all subfield to 255 to indicate that the BSR for those ACs is unknown / unspecified.

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

[0119] As illustrated, an AP can request buffer status from one or more associated STAs (STA1 and STA2) by sending a Buffer Status Reporting Polling (BSRP) trigger frame. Upon receiving a BSRP trigger frame, STA1 and / or STA2 may each generate a Trigger Base (TB) PPDU if the BSRP trigger frame contains the 12 LSBs of the STA's AID in the User Information field.

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

[0121] As mentioned above, the QoS control field may include a queue size subfield for the TID whose queue size the STA should report to the AP. For example, as shown in Figure 6, STA1 can respond to a BSRP trigger frame from the AP by sending an A-MPDU containing multiple QoS null frames. Each QoS null frame indicates the queue size for each TID (e.g., TID0 and TID2) in its respective QoS control field. Similarly, STA2 can respond to a BSRP trigger frame by sending an MPDU containing a QoS null frame indicating the queue size for TID2 in its QoS control field.

[0122] The BSR control subfield may include an ACI bitmap subfield indicating an AC with a queue size that the STA reports to the AP if the AP supports receiving the BSR control subfield, and a queue size all subfield indicating the queue size of the AC. The STA sets the delta TID, scaling factor, ACI high, and queue size high subfields of the BSR control subfield.

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

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

[0125] An MLD is an entity capable of managing communication across multiple links. An MLD is a logical entity and may have multiple affiliated stations (STAs). If its affiliated STA is an AP STA (or AP), the MLD can be an Access Point MLD (AP MLD). If its affiliated STA is a non-AP STA (or STA), the MLD can be a non-Access Point MLD (non-AP MLD).

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

[0127] As shown in Figure 7, an MLD may have a single MAC service access point (MAC-SAP) to the LLC layer, which includes MAC data services. An MLD can support multiple MAC sublayers coordinated by a Sublayer Management Entity (SME). Each AP STA (or non-AP STA) belonging to an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0128] The SME is responsible for coordinating among the MAC sublayer management entities (MLMEs) of STAs belonging to the MLD, thereby maintaining a single robust Security Network Association (RSNA) key management entity and a single IEEE 802.1X authentication device or supplicant for multilink operation (MLO).

[0129] The Multilink Operation (MLO) process allows a pair of MLDs to discover, synchronize, authenticate (deauthenticate), (re)associate, disassociate, and manage resources with each other on a common band or channel supported by both MLDs. The authentication device and MAC-SAP of an AP MLD may be identified by the same AP MLD MAC address. The supplicant and MAC-SAP of a non-AP MLD may be identified by the same non-AP MLD MAC address.

[0130] Figure 8 shows an example of AP MLD and its associated non-AP MLD.

[0131] As shown in the diagram, an AP MLD has two affiliated APs (AP1 and AP2), and a non-AP MLD has two affiliated STAs (STA1 and STA2). AP MLDs and non-AP MLDs may be connected to each other 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.

[0132] Generally, the MAC address of an MLD is different from the MAC address of the STA belonging to that MLD. For example, as shown in Figure 8, an AP MLD may have MAC address M, AP1 may have MAC address w, and AP2 may have MAC address x. Similarly, a non-AP MLD may have MAC address P, STA1 may have MAC address y, and STA2 may have MAC address z.

[0133] As shown in Figure 8, within each MLD, the MAC sublayer may be further divided into an MLD upper MAC sublayer and an MLD lower MAC sublayer. The MLD upper MAC sublayer (MLD) performs functions common to all links. The MLD lower MAC sublayer performs functions specific to each link. Some functions require joint processing by both the MLD upper MAC sublayer and the MLD lower MAC sublayer.

[0134] The functions of the MLD upper MAC sublayer may include the following: Authentication, association, and reassociation (between AP MLD and non-AP MLD); Security associations (e.g., Pairwise Master Key Security Association (PMKSA), Pairwise Transient Key Security Association (PTKSA)), and distribution of Group Temporary Keys (GTK) / Integrity GTK (IGTK) / Beacon IGTK (BIGTK); Assigning sequence numbers (SN) / packet numbers (PN) to frames encrypted with a pairwise transient key (PTK) for unicast frames; Encryption / decryption using PTK for unicast frames; Selection of the MLD lower MAC sublayer for transmission (TID-to-Link mapping); Packet reordering to ensure sequential delivery within each block ACK session; Block ACK scoreboarding for individually addressed frames (in coordination with the MLD lower MAC sublayer); optionally, the MLD upper MAC sublayer distributes block ACK records for one link to the MLD lower MAC sublayers of other links; and MLD-level management information exchange / notification via the MLD lower MAC sublayer.

[0135] The functions of the MLD lower MAC sublayer may include the following: Maintaining link-specific GTK / IGTK / BIGTK (between APs belonging to AP MLDs and STAs belonging to non-AP MLDs); Link-specific encryption / decryption / integrity protection and PN assignment using GTK / IGTK / BIGTK (between APs belonging to AP MLDs and STAs belonging to non-AP MLDs); Link-specific administrative information exchange / notification (e.g., beacons); Link-specific control information exchange / notification (e.g., RTS / CTS, acknowledgments, etc.); Power saving states and modes; MAC address filtering for frame reception; and Block ACK scoreboarding for individually addressed frames (in coordination with the MLD upper MAC sublayer); optionally, the MLD lower MAC sublayer receives block ACK records for other links from the MLD upper MAC sublayer.

[0136] Multilink (re)setup between a non-AP MLD and an AP MLD may involve the exchange of (re)association request / response frames. The exchange of (re)association request / response frames for multilink setup may involve both frames carrying the basic multilink elements.

[0137] In a (re)association request frame, a non-AP MLD indicates the link for which (re)setup is requested, and the function and operating parameters of that link. A non-AP MLD may request (re)setup of links with a subset of APs belonging to an AP MLD. The link for which (re)setup is requested, and the function and operating parameters of that link, are independent of the existing setup link with the associated AP MLD and its function and operating parameters.

[0138] In the (re)association response frame, the AP MLD may indicate which of the requested links will be (re)set up and which will be rejected, as well as their functional and operational parameters. The AP MLD may accept (re)set up only a subset of the requested links. The (re)association response frame is sent to the non-AP STA belonging to the non-AP MLD that sent the (re)association request frame.

[0139] An MLD requesting or accepting a multilink (re)setup for any two links ensures that each link is located on a different non-overlapping channel. Upon successful completion of the 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 belonging to the non-AP MLD is in the same association state as the non-AP MLD and is associated with the corresponding AP belonging to the AP MLD. For each setup link, the functionality between the non-AP STA and its associated AP is enabled unless those functions are extended to the MLD level or otherwise specified.

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

[0141] A non-AP MLD can initiate a multilink setup by having a non-AP STA1 send an association request frame to AP1, which belongs to 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 a basic multilink element that shows complete information about non-AP STA1, non-AP STA2, and non-AP STA3. The association request frame may request 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).

[0142] An AP MLD may respond to a requested multilink setup by having the AP send an association response frame to a non-AP STA1 belonging to a 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 includes the MLD MAC address of the AP MLD and basic multilink elements showing complete information about AP1, AP2, and AP3. The association response frame indicates that the multilink setup was 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).

[0143] By default, all TIDs of a non-AP MLD are mapped to all setup links for both uplinks and downlinks. 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 QoS traffic for ULs and DLs corresponding to different TIDs (e.g., 0-7) should be allocated to the setup links. In negotiated TID-to-Link mappings, TIDs may be mapped to link sets (a subset of setup links ranging from one setup link to all setup links).

[0144] A setup link is defined as valid for a non-AP MLD if at least one TID is mapped to that link in either the DL or UL, and invalid if no TID is mapped in either the DL or UL. Each TID is always mapped to at least one setup link in either the DL or UL. Therefore, a change in TID-to-Link mapping is valid and successful only if it does not result in the link set corresponding to the TID containing zero setup links.

[0145] By default, all setup links are enabled. If 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 in both DL and UL on enabled links between the relevant STA belonging to the non-AP MLD and the corresponding AP belonging to the AP MLD.

[0146] If a link is invalid for a non-AP MLD, that link cannot be used to exchange individually addressed frames between the associated STA belonging to the non-AP MLD and the corresponding AP belonging to the AP MLD.

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

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

[0149] When default mode is used, a non-AP MLD can obtain BUs buffered by AP MLD on any setup link, even if AP MLD recommends a specific link.

[0150] A non-AP MLD can obtain a BU, which is a buffered MMPDU, to the AP MLD on any valid link. The AP MLD can use any valid link to send individually addressable bufferable management frames, which are not measured MMPDUs, depending on the power status of the non-AP STA on the link used.

[0151] If an STA belonging to a non-AP MLD is in active mode on a link with a TID set mapped for DL ​​transmission, the associated AP belonging to an AP MLD may transmit to that STA: an MSDU / A-MSDU for the mapped TID set for the non-AP MLD, and an MMPDU that is not a measured MMPDU for the non-AP MLD (except for frames destined for another STA belonging to the same non-AP MLD and in active mode).

[0152] 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 multilink setups operate in this mode if TID-to-Link mapping negotiation for a different mapping was not performed, failed, or was discarded.

[0153] In the multilink (re)setup procedure, if the AP MLD indicates support for TID-to-Link mapping negotiation, the non-AP MLD can initiate TID-to-Link mapping negotiation by including a TID-to-Link mapping element in the (re)association request frame.

[0154] After receiving a (re)association request frame containing a TID-to-Link mapping element, the AP MLD responds to the 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 the multilink (re)setup of all links to which at least one TID is requested to be mapped. 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 includes a TID-to-Link mapping element proposing a preferred TID-to-Link mapping in the (re)association response frame to indicate that it rejects the proposed TID-to-Link mapping.

[0155] After a successful multilink (re)setup, the initiating MLD can send an individually addressed TID-to-Link mapping request frame to the responding MLD that has indicated support for TID-to-Link mapping negotiation, in order to negotiate a new TID-to-Link mapping.

[0156] When a responding MLD receives an individually addressed TID-to-Link mapping request frame, it sends an individually addressed TID-to-Link mapping response frame to the initiating MLD according to the following rules: The responding MLD may accept 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 responding MLD indicates a rejection of the proposed TID-to-Link mapping in the TID-to-Link mapping response frame. Furthermore, the responding MLD may propose a preferred TID-to-Link mapping by including a TID-to-Link mapping element in the TID-to-Link mapping response frame.

[0157] An MLD can propose a preferred TID-to-Link mapping to a peer MLD by sending a non-requested TID-to-Link mapping response frame that includes a TID-to-Link mapping element.

[0158] If a peer MLD indicates a preferred TID-to-Link mapping, the MLD can take that preferred TID-to-Link mapping into consideration when initiating a new TID-to-Link mapping. Furthermore, the AP MLD can consider the traffic flow associated with the non-AP MLD, as well as the non-AP MLD's capabilities and limitations (if any).

[0159] If 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 teardown frames. After teardown, the MLDs operate in their default mapping mode.

[0160] If an MLD successfully negotiates a TID-to-Link mapping with a peer MLD, both the MLD and the peer MLD update the uplink and / or downlink TID-to-Link mapping information according to the negotiated TID-to-Link mapping.

[0161] If an MLD successfully negotiates an uplink and / or downlink TID-to-Link mapping with a peer MLD, and bit position i of the link mapping field n within that TID-to-Link mapping element is set to 0, then TID n will not be mapped to the link associated with link ID i in the uplink and / or downlink. If an MLD successfully negotiates an uplink and / or downlink TID-to-link mapping with a peer MLD, and bit position i of the link mapping field n within that TID-to-Link mapping element is set to 1, then TID n will be mapped to the link associated with link ID i in the uplink and / or downlink.

[0162] Figure 10 shows an example of TID-to-Link mapping in a multilink communication environment. As illustrated, the multilink communication environment includes an AP MLD with three affiliated APs and a non-AP MLD with three affiliated STAs.

[0163] During or after multilink setup, the non-AP MLD and AP MLD may negotiate a TID-to-link mapping. TID-to-link mapping maps the TIDs in the UL and DL of the non-AP MLD to the setup links between the AP MLD and the non-AP MLD. For example, as shown in Figure 10, TID-to-link mapping may map TID0-6 to link 1 and TID7 to link 2 in both the UL and DL. Thus, links 1 and 2 become active, and link 3 becomes inactive. Negotiation of TID-to-link mapping may be performed by exchanging association request / response frames or TID-to-link mapping request / response frames between the non-AP MLD and the AP MLD.

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

[0165] For example, STA1102 may send RTS frame 1106 to STA1104. STA1102 may also send RTS frame 1106 to protect the transmission of data frame 1110 that STA1102 is about to send from hidden STAs. RTS frame 1106 may include a Duration / ID field. The Duration / ID field may be set to the time required (in microseconds) to transmit data frame 1110 plus one CTS frame, one ACK frame (if necessary), and three short interframe space (SIFS) periods.

[0166] As an example, STA1104 may send CTS frame 1108 to STA1102 in response to RTS frame 1106. CTS frame 1108 may be sent after one SIFS period has elapsed following RTS frame 1106. STA1104 may respond to RTS frame 1106 after considering the NAV if the RTS frame 1106 is destined for STA1104 (unless the NAV was set by a frame sent from STA1102). STA1104 may respond to RTS frame 1106 if the RTS frame 1106 is destined for STA1104 and the NAV indicates an idle state. For non-S1G STAs, the NAV indicates an idle state when the NAV count is 0, or when the NAV count is non-zero but the non-bandwidth signaling TA obtained from the TA field of RTS frame 1106 matches a stored TXOP holder address. In the case of 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 not 0, but the TA field of RTS frame 1106 matches the TXOP holder address where it is stored.

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

[0168] After receiving CTS frame 1108, STA1102 may wait for one SIFS period before sending data frame 1110. STA1104 may send ACK frame 1112 in response to data frame 1110. STA1104 may send ACK frame 1112 one SIFS period after receiving data frame 1110.

[0169] As shown in RTS / CTS procedure 1100, other STAs belonging to the same BSS and within the communication range of STA1102 and STA1104 may set their NAV based on RTS frame 1106 and / or CTS frame 1108. For example, an STA that receives RTS frame 1106 may set its NAV based on the Duration / ID field of RTS frame 1106. Another STA that receives CTS frame 1108 may set its NAV based on the Duration field of CTS frame 1108. Thus, other STAs may not access the channel using EDCA until the transmission of ACK frame 1112 is complete. Similarly, STAs belonging to an overlapping BSS (OBSS) may also set their NAV based on an RTS or CTS frame if they are within the communication range of the transmitting STA.

[0170] Future IEEE 802.11 standards are expected to provide various mechanisms to support quality of service (QoS) requirements for low-latency (LL) (or latency-sensitive) traffic. Such traffic can originate from a variety of real-time applications with stringent latency requirements (e.g., very low average latency, at worst a few milliseconds to tens of milliseconds, and / or low jitter). In operation, LL traffic may be associated with one or more traffic identifiers (TIDs) associated with one or more given ACs or traffic streams (hereinafter, TIDs associated with LL traffic will be referred to as LL TIDs). One or more given ACs may include, for example, video (AC_VI) and voice (AC_VO) access categories.

[0171] 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 may be achieved by using RTS / CTS procedures before transmitting low-latency data to protect that transmission from interference. When STAs perform RTS / CTS exchange, other STAs within the communication range of those STAs may receive RTS frames and / or CTS frames and set their own NAVs based on the Duration field of those frames. In scenarios where multiple links are available, multilink RTS / CTS exchange may be used. STAs within the communication range of the transmitting STA and / or receiving STA (e.g., an OBSS STA, or other STAs belonging to the same BSS as the transmitting and receiving STAs) may set NAVs for all links on which the STAs receive RTS frames from the transmitting STA and CTS frames from the receiving STA. However, since the transmitting STA transmits data frames over only one link, the STA may unnecessarily refrain from communicating over other unused links. Figure 12, described below, shows an example of an existing procedure that may be used to transmit low-latency data protected by RTS / CTS exchange in a multilink environment.

[0172] As shown in Figure 12, Example 1200 includes STA1210, STA1211, and STA1212. Each of STA1210, STA1211, and STA1212 may include an AP MLD or a non-AP MLD that can communicate over multiple links (e.g., a first link and a second link). For example, the first link may include any of the 2.4GHz band, 5GHz band, 6GHz band, or a future-defined band. Similarly, the second link may include any of the 2.4GHz band, 5GHz band, 6GHz band, or a future-defined band, and the second link is different from the first link. For example, STA1212 may be within the communication range of STA1210 and STA1211.

[0173] In Example 1200, STA1210 may have a low-latency data frame 1224 to be sent to STA1211 within the transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs having an LL TID. In one implementation, STA1210 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1224 arrives at STA1210. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1210. In yet another implementation, the transmission completion time counter may start when STA1210 transmits the low-latency data frame 1224. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be sent to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0174] According to existing procedures, in order to transmit the low-latency data frame 1224, STA1210 may transmit RTS frame 1220 to STA1211 via a second link (e.g., Link-2) and RTS frame 1221 to STA1211 via a first link (e.g., Link-1). STA1210 may start transmitting RTS frames 1220 and 1221 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1220 and 1221 may or may not coincide in time. As an example, STA1210 may start a transmission completion time counter associated with the low-latency data frame 1224 when transmitting RTS frame 1220. When STA1212 receives RTS frame 1220 via the second link and RTS frame 1221 via the first link, it may configure NAVs for the first and second links, respectively, based on RTS frames 1221 and 1220 (based on the Duration / ID fields of RTS frames 1221 and 1220).

[0175] For example, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1220 via the second link and send CTS frame 1222 to STA1210. Alternatively, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1221 via the first link and send CTS frame 1223 to STA1210. When STA1212 receives CTS frame 1222 via the second link and CTS frame 1223 via the first link, it may update the NAVs for the first and second links, respectively, based on CTS frames 1223 and 1222 (based on the Duration fields of CTS frames 1223 and 1222). Typically, the Duration / ID field of the RTS frame and the Duration field of the response CTS frame are set to the same value. Therefore, an STA that receives a response CTS frame after receiving an RTS frame does not change its NAV value, which was set when the RTS frame was received.

[0176] After receiving CTS frame 1222 via the second link (for example, if STA1210 receives CTS frame 1222 via the second link before receiving CTS frame 1223 via the first link), STA1210 may send low-latency data frame 1224 to STA1211 via the second link. After receiving low-latency data frame 1224, STA1211 may send ACK frame 1225 to STA1210 via the second link. After sending CTS frame 1223 via the first link, STA1211 may take no action based on the fact that it has not received any data from STA1210 via the first link within a certain period of time since sending CTS frame 1223. Note that if RTS frame 1221 is not addressed to STA1211, STA1211 will not set its NAV based on RTS frame 1221.

[0177] While data is being exchanged between STA1210 and STA1211, STA1212 may be unable to communicate via the first or second link. Specifically, even though the first link is not being used for any frame transmission, STA1212 may be unable to reset the NAV for the first link and therefore unable to communicate via the first link. Consequently, while existing procedures may allow sending low-latency data before the transmission completion time, many STAs may become unable to communicate on the first link even though the first link is not being used.

[0178] As detailed below, embodiments of the present disclosure address the aforementioned problems of existing procedures. In one aspect, embodiments enable a transmitting / receiving STA (AP STA or non-AP STA) in a multilink RTS / CTS exchange to notify neighboring STAs of links on which it will not send or receive data after the multilink RTS / CTS exchange. In one embodiment, the transmitting / receiving STA may send a CF termination frame over a link on which it will not send or receive data after the multilink RTS / CTS exchange. The CF termination frame enables neighboring STAs to reset their respective NAVs for that link. As a result, neighboring STAs are free to communicate over a link while the transmitting / receiving STA is sending or receiving data over another link.

[0179] Figure 13 is Example 1300, which illustrates a procedure used to transmit low-latency data protected by a multilink RTS / CTS exchange according to one embodiment. As shown in Figure 13, Example 1300 includes STA1210, STA1211, and STA1212 as described above with respect to Figure 12.

[0180] In Example 1300, STA1210 may have a low-latency data frame 1324 to be sent to STA1211 within the transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs having an LL TID. In one implementation, STA1210 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1324 arrives at STA1210. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1210. In yet another implementation, the transmission completion time counter may start when STA1210 transmits the low-latency data frame 1324. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be sent to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0181] In one embodiment, to transmit a low-latency data frame 1324, STA1210 may transmit an RTS frame 1320 to STA1211 via a second link and an RTS frame 1321 to STA1211 via a first link. STA1210 may start transmitting RTS frames 1320 and 1321 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1320 and 1321 may or may not coincide in time. As an example, STA1210 may start a transmission completion time counter associated with the low-latency data frame 1324 when transmitting RTS frame 1320. When STA1212 receives RTS frame 1320 via the second link and RTS frame 1321 via the first link, it may configure the NAVs for the first and second links based on RTS frames 1321 and 1320 (based on the Duration / ID fields of RTS frames 1321 and 1320).

[0182] For example, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1320 via the second link and send CTS frame 1322 to STA1210. Alternatively, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1321 via the first link and send CTS frame 1323 to STA1210. When STA1212 receives CTS frame 1322 via the second link and CTS frame 1323 via the first link, it may update the NAVs on the first and second links, respectively, based on CTS frames 1323 and 1322 (based on the Duration fields of CTS frames 1323 and 1322). Typically, the Duration / ID field of the RTS frame and the Duration field of the response CTS frame are set to the same value. Therefore, an STA that receives a response CTS frame after receiving an RTS frame does not change its NAV value, which was set when the RTS frame was received.

[0183] After receiving the CTS frame 1322 via the second link (for example, if STA1210 receives the CTS frame 1322 via the second link before receiving the CTS frame 1323 via the first link), STA1210 may send a low-latency data frame 1324 to STA1211 via the second link. After receiving the data frame 1324, STA1211 may send an ACK frame 1326 to STA1210 via the second link.

[0184] In addition to transmitting data frame 1324 over the second link, STA1210 may also transmit a conflict-free termination (CF termination) frame 1325 over the first link. STA1210 may transmit the CF termination frame 1325 before, simultaneously with, or after transmitting data frame 1324. STA1210 may be permitted to transmit the CF termination frame 1325 as a TXOP initiator on the first link. The CF termination frame 1325 allows an STA within STA1210's communication range to reset its NAV for the first link, thereby enabling communication over the first link. For example, upon receiving the CF termination frame 1325 over the first link, STA1212 may reset its NAV for the first link (set based on RTS frame 1321 and updated based on CTS frame 1323) and become able to communicate over the first link. Therefore, the procedure in Figure 13 makes it possible to deliver low-latency data before the transmission completion time, and allows other STAs within the communication range of STA1210 to communicate via the first link while data exchange between STA1210 and STA1211 is taking place via the second link. However, as will be discussed later in relation to Figure 14, STAs that are outside the communication range of STA1210 but within the communication range of STA1211 may still have their communication via the first link restricted.

[0185] Figure 14 is another example 1400 illustrating the procedure in Figure 13. As shown in Figure 14, example 1400 includes STA1412 in addition to STA1210 and STA1211 described above. STA1412 may belong to a different BSS than STA1210 and STA1211. STA1412 may include an AP MLD or a non-AP MLD that can communicate over multiple links (e.g., a first link and a second link). For example, the first link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. Similarly, the second link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is different from the first link. In example 1400, STA1412 may be within the communication range of STA1211 but outside the communication range of STA1210.

[0186] In Example 1400, STA1210 may have a low-latency data frame 1424 to be sent to STA1211 within the transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs having an LL TID. In one implementation, STA1210 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1424 arrives at STA1210. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1210. In yet another implementation, the transmission completion time counter may start when STA1210 transmits the low-latency data frame 1424. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0187] In one embodiment, to transmit a low-latency data frame 1424, STA1210 may transmit an RTS frame 1420 to STA1211 via a second link and an RTS frame 1421 to STA1211 via a first link. STA1210 may start transmitting RTS frames 1420 and 1421 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1420 and 1421 may or may not coincide in time. For example, when STA1210 transmits RTS frame 1420, it may start a transmission completion time counter associated with the low-latency data frame 1424. Because STA1412 is outside the communication range of STA1210, it may not receive RTS frame 1420 via the second link and RTS frame 1421 via the first link, and as a result may not set up NAVs for the first and second links.

[0188] For example, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1420 via the second link and send CTS frame 1422 to STA1210. Alternatively, if the NAV indicates an idle state, STA1211 may respond to RTS frame 1421 via the first link and send CTS frame 1423 to STA1210. When STA1412 receives CTS frame 1422 via the second link and CTS frame 1423 via the first link, it may configure the NAVs on the first and second links, respectively, based on CTS frames 1423 and 1422 (based on the Duration fields of CTS frames 1423 and 1422).

[0189] After receiving the CTS frame 1422 via the second link (for example, if STA1210 receives the CTS frame 1422 via the second link before receiving the CTS frame 1423 via the first link), STA1210 may send the data frame 1424 to STA1211 via the second link. After receiving the data frame 1424, STA1211 may send the ACK frame 1426 to STA1210 via the second link.

[0190] In addition to transmitting data frame 1424 over the second link, STA1210 may also transmit CF termination frame 1425 over the first link. STA1210 may transmit CF termination frame 1425 before, simultaneously with, or after transmitting data frame 1424. STA1210 may be permitted to transmit CF termination frame 1425 as a TXOP initiator on the first link. CF termination frame 1425 allows STAs within STA1210's communication range to reset their NAV for the first link. However, in example 1400, STA1412 is outside STA1210's communication range and therefore does not receive CF termination frame 1425 over the first link, and thus may maintain its NAV for the first link as set based on CTS frame 1423. Therefore, even though the first link is not being used for data frame transmission between STA1210 and STA1211, STA1412 may be unable to use the first link for communication while data exchange between STA1210 and STA1211 is taking place via the second link.

[0191] Figure 15 shows another example 1500 of a procedure used to transmit low-latency data protected by multilink RTS / CTS switching according to one embodiment. As shown in Figure 15, example 1500 includes STA1510, STA1511, and STA1512. STA1512 may belong to a different BSS than STA1510 and STA1511. STA1510, STA1511, and STA1512 may each include an AP MLD or non-AP MLD that can communicate over multiple links (e.g., a first link and a second link). For example, the first link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. Similarly, the second link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is different from the first link. In Example 1500, STA1512 may be within the communication range of STA1511 but outside the communication range of STA1510.

[0192] In Example 1500, STA1510 may have a low-latency data frame 1524 to be sent to STA1511 within the transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1510 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1524 arrives at STA1510. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1510. In yet another implementation, the transmission completion time counter may start when STA1510 transmits the low-latency data frame 1524. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0193] In one embodiment, to transmit a low-latency data frame 1524, STA1510 may transmit an RTS frame 1520 to STA1511 via a second link and an RTS frame 1521 to STA1511 via a first link. STA1510 may start transmitting RTS frames 1520 and 1521 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1520 and 1521 may or may not coincide in time. In one example, RTS frame 1521 may overlap with RTS frame 1520. As an example, when STA1510 transmits RTS frame 1520, it may start a transmission completion time counter associated with the low-latency data frame 1524. Because STA1512 is outside the communication range of STA1510, it does not receive RTS frame 1520 via the second link and RTS frame 1521 via the first link, respectively, and as a result may not set up NAV for the first and second links. In one embodiment, RTS frames 1520 and 1521 may include multi-user transmission request (MU-RTS) trigger frames. For example, the first or second MU-RTS trigger frame may include information indicating the transmission of data over a single link, either the first or the second link.

[0194] For example, if the NAV indicates an idle state, STA1511 may respond to the RTS frame 1520 via the second link and send the CTS frame 1522 to STA1510. Alternatively, if the NAV indicates an idle state, STA1511 may respond to the RTS frame 1521 via the first link and send the CTS frame 1523 to STA1510. When STA1512 receives the CTS frame 1522 via the second link and the CTS frame 1523 via the first link, it may configure the NAVs on the first and second links, respectively, based on the CTS frames 1523 and 1522 (based on the Duration fields of the CTS frames 1523 and 1522).

[0195] After receiving CTS frame 1522 via the second link (for example, if STA1510 receives CTS frame 1522 via the second link before receiving CTS frame 1523 via the first link), STA1510 may send data frame 1524 to STA1511 via the second link. After STA1511 receives data frame 1524 on the second link, STA1511 may send ACK frame 1526 to STA1510 via the second link.

[0196] In one embodiment, STA1511 may transmit a CF termination frame 1525 on the first link based on the fact that it has not received any data over the first link within a specific period of time since the transmission of the CTS frame 1523. STA1512, which is within the communication range of STA1511, may reset the NAV for the first link upon receiving the CF termination frame 1525 (thus enabling communication over the first link). In one embodiment, the specific period may be longer than the SIFS. In one embodiment, STA1512 may transmit a frame over the first link to another STA (not shown in Figure 15) within the period indicated in the CTS frame 1523. In another embodiment, STA1512 may receive a frame over the first link from another STA (not shown in Figure 15) within the period indicated in the CTS frame 1523.

[0197] Therefore, by using the procedure in Figure 15, an STA that is within the communication range of the receiving STA but outside the communication range of the transmitting STA may be released to communicate via a link not used for data exchange after multilink RTS / CTS exchange. An STA that is within the communication range of the transmitting STA but outside the communication range of the receiving STA may also be permitted to communicate via an unused link. Such an STA resets the NAV for the unused link (which was set based on receiving an RTS frame on the unused link) if it does not receive a corresponding CTS frame on the unused link. One advantage of the procedure shown in Figure 15 is the low overall overhead, as the receiving STA (TXOP responder) can determine to transmit a CF end frame without receiving a trigger frame or transmit flag (TX flag) from the transmitting STA (TXOP holder).

[0198] Figure 16 shows another example 1600 of a procedure used to transmit low-latency data protected by multilink RTS / CTS switching according to one embodiment. As shown in Figure 16, example 1600 includes STA1610, STA1611, and STA1612. STA1612 may belong to a different BSS than STA1610 and STA1611. STA1610, STA1611, and STA1612 may each include an AP MLD or non-AP MLD that can communicate over multiple links (e.g., a first link and a second link). For example, the first link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. Similarly, the second link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is different from the first link. In Example 1600, STA1612 may be within the communication range of STA1611 but outside the communication range of STA1610.

[0199] In Example 1600, STA1610 may have a low-latency data frame 1624 to be sent to STA1611 within the 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 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1624 arrives at STA1610. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1610. In yet another implementation, the transmission completion time counter may start when STA1610 transmits the low-latency data frame 1624. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0200] In one embodiment, to transmit a low-latency data frame 1624, STA1610 may transmit an RTS frame 1620 to STA1611 via a second link and an RTS frame 1621 to STA1611 via a first link. STA1610 may start transmitting RTS frames 1620 and 1621 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1620 and 1621 may or may not coincide in time. In one example, RTS frame 1621 may overlap with RTS frame 1620. In one example, when STA1610 transmits RTS frame 1620, it may start a transmission completion time counter associated with the low-latency data frame 1624. Because STA1612 is outside the communication range of STA1610, it does not receive RTS frame 1620 via the second link and RTS frame 1621 via the first link, respectively, and as a result, it may not configure NAV for the first and second links.

[0201] For example, if the NAV indicates an idle state, STA1611 may respond to RTS frame 1620 via the second link and send CTS frame 1622 to STA1610. Alternatively, if the NAV indicates an idle state, STA1611 may respond to RTS frame 1621 via the first link and send CTS frame 1623 to STA1610. If other STA1612 receives CTS frame 1622 via the second link and CTS frame 1623 via the first link, it may configure the NAVs on the first and second links, respectively, based on CTS frames 1623 and 1622 (based on the Duration fields of CTS frames 1623 and 1622).

[0202] After receiving CTS frame 1622 via the second link (for example, if STA1610 receives CTS frame 1622 via the second link before receiving CTS frame 1623 via the first link), STA1610 may transmit STA1611 data frame 1624 via the second link. After receiving data frame 1624 on the second link, STA1611 may transmit ACK frame 1627 to STA1610 via the second link.

[0203] In one embodiment, based on STA1610 transmitting data frame 1624 to STA1611 via a second link, STA1610 may transmit frame 1625 to STA1611 via the first link, indicating the transmission of data to STA1611 via the second link. In one embodiment, frame 1625 may be a trigger frame. In one embodiment, the trigger frame may indicate to STA1611 that no data transmission will occur via the first link. In one embodiment, the trigger frame may include information instructing STA1611 to transmit a CF end frame via the first link. In one embodiment, the notification instructing STA1611 to transmit a CF end frame via the first link may be included in the user information field or common information field of the trigger frame.

[0204] Based on receiving frame 1625 from STA1610 indicating the transmission of data to STA1611 via the second link, STA1611 may transmit a CF termination frame 1626 via the first link. Upon receiving the CF termination frame 1626, STA1612, which is within the communication range of STA1611, may reset its NAV for the first link (making it possible to communicate via the first link). In one embodiment, STA1612 may transmit a frame to another STA (not shown in Figure 16) via the first link within the period indicated in the CTS frame 1623. In another embodiment, STA1612 may receive a frame from another STA (not shown in Figure 16) via the first link within the period indicated in the CTS frame 1623.

[0205] Therefore, by using the procedure in Figure 16, an STA that is within the communication range of the receiving STA but outside the communication range of the transmitting STA may be released to communicate via a link that is not used for data exchange after multilink RTS / CTS exchange. An STA that is within the communication range of the transmitting STA but outside the communication range of the receiving STA may also be permitted to communicate via an unused link. Such an STA resets the NAV for the unused link (which was set based on receiving an RTS frame on the unused link) if it does not receive a corresponding CTS frame on the unused link. Compared to Figure 15, one advantage of the procedure shown in Figure 16 is that the receiving STA (TXOP responder) only sends a CF termination frame when triggered by the transmitting STA (TXOP holder). Therefore, reliability may be improved as the transmitting STA notifies the receiving STA of the unused link.

[0206] Figure 17 shows another example 1700 of a procedure used to transmit low-latency data protected by multilink RTS / CTS switching according to one embodiment. As shown in Figure 17, example 1700 includes STA1710, STA1711, and STA1712. STA1712 may belong to a different BSS than STA1710 and STA1711. STA1710, STA1711, and STA1712 may each include an AP MLD or non-AP MLD that can communicate over multiple links (e.g., a first link and a second link). For example, the first link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. Similarly, the second link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is different from the first link. In Example 1700, STA1712 may be within the communication range of STA1711 but outside the communication range of STA1710.

[0207] In Example 1700, STA1710 may have a low-latency data frame 1724 to be sent to STA1711 within the transmission completion time. The low-latency data frame may be a data frame containing one or more MPDUs with LL TIDs. In one implementation, STA1710 may associate a counter with the transmission completion time. The transmission completion time counter may start when the low-latency data to be sent in the low-latency data frame 1724 arrives at STA1710. In another implementation, the transmission completion time counter may start with the initiation of the RTS / CTS procedure by STA1710. In yet another implementation, the transmission completion time counter may start when STA1710 transmits the low-latency data frame 1724. In one implementation, for the transmission of the low-latency data frame to be successful, an ACK of the low-latency data frame by the destination STA may be required before the transmission completion time counter expires. In one implementation, the transmission completion time may refer to the time required for the low-latency data frame to be delivered to the destination STA. The transmission completion time may differ for each low-latency data frame.

[0208] In one embodiment, to transmit a low-latency data frame 1724, STA1710 may transmit an RTS frame 1720 to STA1711 via a second link and an RTS frame 1721 to STA1711 via a first link. STA1710 may start transmitting RTS frames 1720 and 1721 simultaneously. Due to random backoffs on the first and second links, the transmissions of RTS frames 1720 and 1721 may or may not coincide in time. In one example, RTS frame 1721 may overlap with RTS frame 1720. In one example, when STA1710 transmits RTS frame 1720, it may start a transmission completion time counter associated with the low-latency data frame 1724. Because STA1712 is outside the communication range of STA1710, it does not receive RTS frame 1720 via the second link and RTS frame 1721 via the first link, respectively, and as a result, it may not configure NAV for the first and second links.

[0209] For example, if the NAV indicates an idle state, STA1711 may respond to RTS frame 1720 via the second link and send CTS frame 1722 to STA1710. Alternatively, if the NAV indicates an idle state, STA1711 may respond to RTS frame 1721 via the first link and send CTS frame 1723 to STA1710. If other STA1712 receives CTS frame 1722 via the second link and CTS frame 1723 via the first link, it may configure the NAVs on the first and second links based on CTS frames 1723 and 1722 (based on the Duration fields of CTS frames 1723 and 1722).

[0210] After receiving CTS frame 1722 via the second link (for example, if STA1710 receives CTS frame 1722 via the second link before receiving CTS frame 1723 via the first link), STA1710 may send data frame 1724 to STA1711 via the second link. After STA1711 receives data frame 1724 on the second link, STA1711 may send ACK frame 1726 to STA1710 via the second link.

[0211] In one embodiment, based on STA1710 transmitting data frame 1724 to STA1711 via a second link, STA1710 may transmit a frame to STA1711 indicating the transmission of data to STA1711 via the second link. In another embodiment, the frame may indicate that no data is transmitted via the first link. In one embodiment, the frame may include a data frame containing data. For example, as shown in Figure 17, the frame may be data frame 1724. In another embodiment, the frame may be separate from data frame 1724. In one embodiment, the frame may include information about the first link, and the information about the first link may indicate that no data is transmitted to STA1711 via the first link. In one embodiment, the information may be a transmit flag. In one embodiment, the information about the first link may be provided in the Universal Signal (U-SIG) field of the frame's PHY header, and the U-SIG field may further include a link identifier for the first link. In another embodiment, information regarding the first link may be provided in an aggregated control (A control) field located within the frame's high-throughput (HT) control field.

[0212] Based on receiving frame 1724 from STA1710 indicating the transmission of data to STA1711 via the second link, STA1711 may transmit a CF termination frame 1725 via the first link. Upon receiving the CF termination frame 1725, STA1712, which is within the communication range of STA1711, may reset its NAV for the first link (and become available for further communication). In one embodiment, STA1712 may transmit a frame to another STA (not shown in Figure 17) via the first link within the period indicated in the CTS frame 1723. In another embodiment, STA1712 may receive a frame from another STA (not shown in Figure 17) via the first link within the period indicated in the CTS frame 1723.

[0213] Therefore, by using the procedure in Figure 17, an STA that is within the communication range of the receiving STA but outside the communication range of the transmitting STA may be freed to communicate via a link not used for data exchange after multilink RTS / CTS exchange. An STA that is within the communication range of the transmitting STA but outside the communication range of the receiving STA may also be permitted to communicate via an unused link. Such an STA will reset the NAV for the unused link (which was set based on receiving an RTS frame on the unused link) if it does not receive a corresponding CTS frame on the unused link. Another advantage of the procedure shown in Figure 17 is that it does not require signaling with a separate frame to trigger the receiving STA to transmit a CF termination frame. Signaling is integrated with the data frame, thus reducing signaling overhead.

[0214] Figure 18 shows an example of a common information field 1800 of a basic multilink element according to one embodiment. A basic multilink element may be transmitted by one STA to notify other STAs of its functions. As shown in Figure 18, the common information field 1800 may include 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.

[0215] In one embodiment, the reserved bits of the MLD function and operation subfield may be used to indicate a transmission operation mode for data containing low-latency traffic that is protected by multilink RTS / CTS exchange and transmitted over a single link (see Figures 15-17). In one embodiment, by setting the reserved bits to 1, STA may notify another STA that it can transmit data containing low-latency traffic by using multilink RTS / CTS exchange and then transmit the data to that other STA over a single link. Conversely, by setting the reserved bits to 1, STA may notify another STA that it can receive data containing low-latency traffic over a single link after multilink RTS / CTS and that it can transmit CF termination frames over an unused link as in the embodiments shown in Figures 15, 16, and 17.

[0216] Figure 19 shows an example of a trigger frame 1900 that may be used in the embodiment. As shown in Figure 19, the trigger frame 1900 may include a frame control subfield, a duration subfield, a recipient address (RA) subfield, a sender address (TA) subfield, a common information subfield, a user information list subfield, a padding subfield, and an FCS subfield.

[0217] As an example, the trigger type field subfield of the common information subfield may indicate that trigger frame 1900 is a variation of a MU-RTS trigger frame. In one embodiment, as a variation of a MU-RTS trigger frame, trigger frame 1900 may be an embodiment of the frames 1520 and / or 1521, if those frames are MU-RTS frames. In one embodiment, trigger frame 1900 may include information indicating that data is transmitted over a single link, either the first link or the second link. As an example, notification of data transmission over a single link may be transmitted in one or more reserved bits in the common information subfield of trigger frame 1900. As another example, notification of data transmission over a single link may be transmitted in one or more reserved bits in the user information subfield of trigger frame 1900. In one embodiment, if the transmitting STA sets the bit indicating data transmission over a single link to 1, the receiving STA may expect to receive low-latency data over a single link despite the multi-link RTS / CTS exchange. In one embodiment, based on the notification being set to 1, the receiving STA may send a CF termination frame on a link where no data has been received after a certain period of time has elapsed since a CTS frame was transmitted on that link (see Figure 15).

[0218] As another example, trigger frame 1900 may be an embodiment of trigger frame 1625. In one embodiment, trigger frame 1900 may include information (CF termination notice) informing the receiving STA to transmit a CF termination frame over the first link. In one embodiment, by setting the CF termination notice bit to 1, the transmitting STA may notify the receiving STA that it should broadcast a CF termination frame on the link on which it received trigger frame 1900 from the transmitting STA (see Figure 16). Alternatively, by setting the CF termination notice bit to 0, the transmitting STA may notify the receiving STA that it should perform legacy operation. In one embodiment, the CF termination notice may be provided in the user information field or common information field of the trigger frame. In one embodiment, the CF termination notice may be transmitted in one of the reserved bits (e.g., bits 20-38) in the user information field. In another embodiment, the CF termination notice may be transmitted in one of the reserved bits (e.g., bits 22, 26, 53, or 63) in the common information field. In another embodiment, the user information list subfield may indicate the link to which the CF termination frame is sent.

[0219] Figure 20 shows an example of a universal signal (U-SIG) field 2000 that may be used in the embodiment. As shown in Figure 20, the U-SIG field 2000 includes both version-independent and version-dependent subfields. The version-independent subfields are located in bits B0 to B19, and the version-dependent subfields are located in bits B20 to B51.

[0220] Version-independent subfields are subfields whose location and interpretation are consistent across various IEEE 802.11 PHY layers. The purpose of version-independent subfields is to enable better coexistence between IEEE 802.11 PHYs defined for the 2.4 GHz, 5 GHz, and 6 GHz spectra since the EHT (Extremely High Throughput) PHY specification. The value of this subfield is used to identify the exact PHY version of the EHT PPDU. Other version-independent subfields include the Bandwidth (BW) subfield indicating the bandwidth of the PPDU, the Uplink / Downlink (UL / DL) subfield indicating whether the PPDU is an uplink or downlink PPDU, the BSS Color subfield indicating the BSS color of the PPDU, and the TXOP subfield indicating the duration of the TXOP during which the PPDU is transmitted.

[0221] In one embodiment, a U-SIG field, such as U-SIG field 2000, may be provided in the PHY header of the frame to provide information indicating a link that is not used for data transmission. For example, as described above with respect to Figure 17, in one embodiment, frame 1724 may include information about a first link, which may indicate to STA1711 that no data is transmitted to STA1711 via the first link. In one embodiment, the information about the first link may include a transmit flag. In one embodiment, frame 1724 may include a U-SIG field, such as U-SIG field 2000, in its PHY header. In one embodiment, the information about the first link may be provided in one of the version-dependent subfields of U-SIG field 2000. In one embodiment, U-SIG field 2000 may further include a link identifier for the first link in the version-dependent subfield.

[0222] In another embodiment, as described above in Figure 4, information regarding the first link may be provided in an aggregated control (A control) field located within the frame's high-throughput (HT) control field. In one embodiment, the A control field may further include a link identifier for the first link.

[0223] Figure 21 shows an example of process 2100 according to one embodiment. The exemplary process 2100 is for illustrative purposes only and is not intended to limit. The exemplary process 2100 may be performed by a first STA, such as STA1511. The first STA may have multilink capabilities (e.g., it may include a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a receiving STA that receives data transmissions from a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link.

[0224] As shown in Figure 21, process 2100 may include, in step 2110, the first STA receiving a first RTS frame via the first link from the second STA requesting data transmission to the first STA via the first link, and the second RTS frame via the second link requesting data transmission to the first STA via the second link. In one embodiment, the first STA and the second STA may each include an AP MLD or a non-AP MLD capable of communicating over multiple links. In one embodiment, the data may include low-latency traffic. In one embodiment, the second RTS frame may overlap with the first RTS frame. In another embodiment, the first RTS frame and the second RTS frame may include MU-RTS trigger frames, and the first or second MU-RTS trigger frame may include information indicating data transmission over a single link, either the first or the second link.

[0225] In step 2120, process 2100 may include the first STA sending a first CTS frame to the second STA via the first link in response to a first RTS frame, and a second CTS frame via the second link in response to a second RTS frame.

[0226] In step 2130, process 2100 may include sending a CF termination frame over the first link based on the fact that the first STA has not received data over the first link within a specific period of time since sending the first CTS frame. In one embodiment, this specific period may be longer than SIFS.

[0227] In one embodiment, process 2100 may further include the first STA receiving data from the second STA via the second link in response to a second CTS frame. Accordingly, process 2100 may further include the first STA sending an acknowledgment (ACK) frame to the second STA via the second link.

[0228] In one embodiment, process 2100 may further include the first STA transmitting a CF termination frame over the first link if the first STA has not received data over the first link within a certain period of time since transmitting the first CTS frame.

[0229] Figure 22 shows another example of process 2200 according to one embodiment. The exemplary process 2200 is for illustrative purposes only and is not intended to limit. The exemplary process 2200 may be performed by a first STA, such as STA1511. The first STA may have multilink capabilities (i.e., may include a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a receiving STA that receives data transmissions from a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link.

[0230] As shown in Figure 22, process 2200 may include, in step 2210, the first STA receiving a first RTS frame via the first link from the second STA requesting data transmission to the first STA via the first link, and the second RTS frame via the second link requesting data transmission to the first STA via the second link. In one embodiment, the first STA and the second STA may each include AP MLDs or non-AP MLDs that can communicate over multiple links. In one embodiment, the data may include low-latency traffic. In one embodiment, the second RTS frame may overlap with the first RTS frame.

[0231] In step 2220, process 2200 may include the first STA sending a first CTS frame to the second STA via the first link in response to a first RTS frame, and a second CTS frame via the second link in response to a second RTS frame.

[0232] Step 2230 may include the first STA transmitting a CF termination frame over the first link, based on the first STA receiving a frame from the second STA indicating that data is being transmitted to the first STA over the second link. In another embodiment, the frame may indicate that no data is being transmitted over the first link.

[0233] In one embodiment, the frame may include a trigger frame. In one embodiment, process 2200 may further include receiving the trigger frame via a first link. In one embodiment, the frame may include a notification instructing the transmission of a CF end frame via the first link, and the notification instructing the transmission of a CF end frame via the first link may be included in the user information field or common information field of the trigger frame.

[0234] In another embodiment, the frame may include a data frame containing data. In one embodiment, process 2200 may further include receiving a data frame via a second link. In one embodiment, the frame may include information about a first link, which may indicate that no data is transmitted to the first STA via the first link. In one example, the information about the first link may be provided in the U-SIG field of the frame's PHY header, and the U-SIG field may further include a link identifier for the first link. In another example, the information about the first link may be provided in the A control field of the frame, and the A control field may be provided in the HT control field of the frame.

[0235] Figure 23 shows another example of process 2300 according to one embodiment. The exemplary process 2300 is for illustrative purposes only and is not intended to limit. The exemplary process 2300 may be performed by a first STA, such as STA1510. The first STA may have multilink capabilities (i.e., may include a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a transmitting STA having data transmissions to send to a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link.

[0236] As shown in Figure 23, process 2300 may include, in step 2310, the first STA sending a first RTS frame over the first link to the second STA requesting data transmission to the second STA over the first link, and the second STA receiving a second RTS frame over the second link requesting data transmission to the second STA over the second link. In one embodiment, the first STA and the second STA may each include AP MLDs or non-AP MLDs that can communicate over multiple links. In one embodiment, the data may include low-latency traffic. In one embodiment, the second RTS frame may overlap with the first RTS frame.

[0237] In step 2320, process 2300 may include the first STA receiving a first CTS frame from the second STA via the first link in response to a first RTS frame, and the second CTS frame via the second link in response to a second RTS frame.

[0238] In step 2330, process 2300 may include the first STA transmitting data to the second STA via the second link, and the first STA transmitting the data to the second STA via the second link, by transmitting a frame to the second STA indicating that the data is being transmitted to the second STA via the second link. In one embodiment, the frame may indicate that no data is being transmitted via the first link.

[0239] In one embodiment, the frame may include a trigger frame. In one embodiment, process 2300 may further include transmitting the trigger frame over a first link. In one embodiment, the frame may include a notification instructing the transmission of a CF end frame over the first link, and the notification instructing the transmission of a CF end frame over the first link may be included in the user information field or common information field of the trigger frame.

[0240] In another embodiment, the frame may include a data frame containing data. In one embodiment, process 2300 may further include transmitting the data frame over a second link. In one embodiment, the frame may include information about a first link, which may indicate that no data is transmitted to a first STA over the first link. In one example, the information about the first link may be provided in the U-SIG field of the frame's PHY header, and the U-SIG field may further include a link identifier for the first link. In another example, the information about the first link may be provided in the A control field of the frame, and the A control field may be provided in the HT control field of the frame.

[0241] Figure 24 shows another example of process 2400 according to one embodiment. The exemplary process 2400 is for illustrative purposes only and is not intended to limit. The exemplary process 2400 may be performed by a first STA, such as STA1512. The first STA may have multilink capabilities (i.e., may include a multilink device (MLD)). The first STA may be an AP STA or a non-AP STA. The first STA may be a receiving STA that receives data transmissions from a second STA. The second STA may also include an MLD. The first STA and the second STA may communicate via at least a first link and a second link. The first STA may also be a transmitting STA with data to send to a third STA, or a receiving STA that receives data transmissions from a third STA. The third STA may also include an MLD. The first STA and the third STA may communicate via at least a first link and a second link.

[0242] As shown in Figure 24, process 2400 may include, in step 2410, the first STA receiving a first CTS frame from the second STA via a first link and a second CTS frame via a second link. In one embodiment, the first STA and the second STA may each include an AP MLD or a non-AP MLD that can communicate over multiple links. In one embodiment, the second CTS frame may overlap with the first CTS frame.

[0243] In step 2420, process 2400 may include setting a first NAV for the first link based on a first CTS frame and setting a second NAV for the second link based on a second CTS frame. In step 2430, process 2400 may include resetting the first NAV for the first link based on receiving a CF termination frame from the second STA over the first link.

[0244] In one embodiment, process 2400 may further include the first STA transmitting a frame to the third STA via the first link during the period indicated in the first CTS frame. In another embodiment, process 2400 may further include the first STA receiving a frame from the third STA via the first link during the period indicated in the first CTS frame.

[0245] While exemplary embodiments relating to operation in a multilink environment have been described, as will be apparent to those skilled in the art, the embodiments can be easily extended to a single-link framework, as shown in Figure 25, based on the teachings provided herein.

[0246] Figure 25 shows another example of process 2500 according to one embodiment. The exemplary process 2500 is for illustrative purposes only and is not intended to limit. The exemplary process 2500 may be performed by a first STA. The first STA may be an AP STA or a non-AP STA. The first STA may be a receiving STA capable of receiving data transmissions from a second STA. The first STA and the second STA may communicate over a single link.

[0247] As shown in Figure 25, process 2500 may include in step 2510 receiving a first RTS frame from a second STA requesting data transmission to the first STA. In one embodiment, the data may include low-latency traffic. In one embodiment, the first RTS frame may include an MU-RTS trigger frame.

[0248] In step 2520, process 2500 may include the first STA sending a first CTS frame to the second STA in response to a first RTS frame.

[0249] In step 2530, process 2500 may include sending a CF termination frame based on the fact that the first STA has not received data within a specific period of time since sending the first CTS frame. In one embodiment, this specific period may be longer than SIFS.

[0250] In one embodiment, process 2500 further obtains that if the first STA does not receive data within a certain period of time from the transmission of the first CTS frame, the first STA transmits a CF end frame.

Claims

1. The first wireless device receives from the second wireless device, The first link receives a first request to transmit (RTS) frame requesting the transmission of data over the first link to the first wireless device, and Receiving a second RTS frame via the second link requesting the transmission of data via the second link to the first wireless device, The first wireless device communicates with the second wireless device, In response to the first RTS frame, a first transmit permission (CTS) frame is transmitted over the first link, and In response to the second RTS frame, a second CTS frame is transmitted via the second link, A method comprising the first wireless device transmitting a conflict-free termination (CF termination) frame over the first link based on the first wireless device not receiving the data over the first link within a period of time from the transmission of the first CTS frame.

2. The method according to claim 1, further comprising the first wireless device receiving data from the second wireless device via the second link in response to the second CTS frame.

3. The method according to claim 2, further comprising the first wireless device transmitting an acknowledgment (ACK) frame to the second wireless device via the second link.

4. The method according to any one of claims 1 to 3, wherein the period is longer than the short interframe space (SIFS).

5. The method according to any one of claims 1 to 4, wherein the second RTS frame is superimposed on the first RTS frame.

6. The method according to any one of claims 1 to 5, wherein the first RTS frame and the second RTS frame include a multi-user transmission request (MU-RTS) trigger frame.

7. The method according to claim 6, wherein the first MU-RTS trigger frame or the second MU-RTS trigger frame includes information indicating the transmission of data through a single link, either the first link or the second link.

8. The method according to claim 7, further comprising the first wireless device not receiving the data over the first link within the period from the transmission of the first CTS frame, and the first wireless device transmitting a competition-free termination (CF termination) frame over the first link.

9. The first wireless device receives from the second wireless device, The first link receives a first request to transmit (RTS) frame requesting the transmission of data over the first link to the first wireless device, and Receiving a second RTS frame via the second link requesting the transmission of data via the second link to the first wireless device, The first wireless device communicates with the second wireless device, In response to the first RTS frame, a first transmit permission (CTS) frame is transmitted over the first link, and In response to the second RTS frame, a second CTS frame is transmitted via the second link, A method comprising the first wireless device transmitting a conflict-free termination (CF termination) frame over the first link based on the first wireless device receiving a frame from the second wireless device indicating the transmission of the data to the first wireless device over the second link.

10. The method according to claim 9, wherein the frame includes a trigger frame.

11. The method according to claim 10, further comprising receiving the trigger frame via the first link.

12. The method according to claim 10 or 11, wherein the frame includes a notification instructing the transmission of the CF termination frame over the first link.

13. The method according to claim 12, wherein the notification instructing to transmit the CF termination frame via the first link is provided in the user information field or common information field of the trigger frame.

14. The method according to claim 9, wherein the frame includes a data frame containing the data.

15. The method according to claim 14, further comprising receiving the data frame via the second link.

16. The method according to claim 14 or 15, wherein the frame includes notification of the first link.

17. The method according to claim 16, wherein the notification of the first link indicates that the data is not transmitted to the first wireless device via the first link.

18. The method according to claim 16 or 17, wherein the notification of the first link is provided in the universal signal (U-SIG) field of the physical layer (PHY) header of the frame.

19. The method according to claim 18, wherein the U-SIG field further includes a link identifier for the first link.

20. The method according to claim 16 or 17, wherein the notification of the first link is provided within the aggregate control (A control) field of the frame.

21. The method according to claim 20, wherein the A control field is provided within the high-throughput (HT) control field of the frame.

22. The method according to any one of claims 10 to 21, wherein the frame indicates that the data is not transmitted via the first link.

23. The first wireless device communicates to the second wireless device. A first Transmit Request (RTS) frame is transmitted via the first link, requesting the transmission of data via the first link to the second wireless device, and Transmitting a second RTS frame via the second link requesting the transmission of data via the second link to the second wireless device, The first wireless device receives a signal from the second wireless device, In response to the first RTS frame, a first transmit permission (CTS) frame is received via the first link, and In response to the second RTS frame, a second CTS frame is received via the second link, A method comprising the first wireless device transmitting the data to the second wireless device via the second link, and the first wireless device transmitting a frame to the second wireless device indicating the transmission of the data to the second wireless device via the second link.

24. The method according to claim 23, wherein the frame includes a trigger frame.

25. The method according to claim 24, further comprising transmitting the trigger frame via the first link.

26. The method according to claim 24 or 25, wherein the frame includes a notification instructing the second wireless device to transmit a conflict-free termination (CF termination) frame over the first link.

27. The method according to claim 26, wherein the notification instructing to transmit the CF termination frame via the first link is provided in the user information field or common information field of the trigger frame.

28. The method according to claim 23, wherein the frame includes a data frame containing the data.

29. The method according to claim 28, further comprising transmitting the data frame via the second link.

30. The method according to claim 28 or 29, wherein the frame includes notification of the first link.

31. The method according to claim 30, wherein the notification of the first link indicates that the data will not be transmitted to the second wireless device via the first link.

32. The method according to claim 30 or 31, wherein the notification of the first link is provided in the universal signal (U-SIG) field of the physical layer (PHY) header of the frame.

33. The method according to claim 11, wherein the U-SIG field further includes a link identifier for the first link.

34. The method according to claim 30 or 31, wherein the notification of the first link is provided within the aggregate control (A control) field of the frame.

35. The method according to claim 34, wherein the A control field is provided within the high-throughput (HT) control field of the frame.

36. The method according to any one of claims 27 to 35, wherein the frame indicates that the data is not transmitted via the first link.

37. The first wireless device receives from the second wireless device, The first link receives the first transmit permission (CTS) frame, and Receiving a second CTS frame via the second link, Setting a first network assignment vector (NAV) for the first link based on the first CTS frame, and setting a second NAV for the second link based on the second CTS frame, A method comprising resetting the first NAV for the first link based on receiving a conflict-free termination (CF termination) frame from the second wireless device via the first link.

38. The method according to claim 37, further comprising the first wireless device transmitting a frame to a third STA via the first link during the period indicated in the first CTS frame.

39. The method according to claim 37, further comprising the first wireless device receiving a frame from the third STA via the first link during the period indicated in the first CTS frame.

40. The method according to any one of claims 37 to 39, wherein the second CTS frame is superimposed on the first CTS frame.

41. The first wireless device receives a first transmit request (RTS) frame from the second wireless device requesting the transmission of data to the first wireless device, In response to the first RTS frame, the first wireless device transmits a first transmit permission (CTS) frame to the second wireless device, A method comprising the first wireless device transmitting a race-free termination (CF termination) frame based on the first wireless device not receiving the data within a certain period of time from the transmission of the first CTS frame.

42. The method according to claim 41, wherein the period is longer than the short interframe space (SIFS).

43. The method according to claim 41 or 42, wherein the first RTS frame includes a multi-user transmission request (MU-RTS) trigger frame.

44. The method according to any one of claims 41 to 43, wherein the first wireless device does not receive the data within the period from the transmission of the first CTS frame, and the method further comprises the first wireless device transmitting a competition-free termination (CF termination) frame.

45. A device, wherein the device is From the second wireless device, The first link receives a first request to transmit (RTS) frame requesting the transmission of data over the first link, and The second link receives a second RTS frame requesting the transmission of data via the second link. In response to the first RTS frame, a first transmit-permit (CTS) frame is transmitted to the second wireless device via the first link, and in response to the second RTS frame, a second CTS frame is transmitted via the second link. A device that transmits a conflict-free termination (CF termination) frame over the first link based on the fact that the device does not receive the data over the first link within a certain period of time from the transmission of the first CTS frame.

46. A device, wherein the device is From the second wireless device, The first link receives a first request to transmit (RTS) frame requesting the transmission of data to the device via the first link, and The second link receives a second RTS frame requesting the transmission of data to the device via the second link. The second wireless device, In response to the first RTS frame, a first transmit permission (CTS) frame is transmitted over the first link, and In response to the second RTS frame, a second CTS frame is transmitted via the second link. A device that transmits a conflict-free termination (CF termination) frame over the first link based on the device receiving a frame from the second wireless device indicating the transmission of the data to the device over the second link.

47. The method according to any one of claims 1 to 44, wherein the first wireless device and the second wireless device are STAs compliant with the IEEE 802.11 standard.

48. A device, wherein the device is The first wireless device receives a first transmit request (RTS) frame requesting the transmission of data to the first wireless device. In response to the first RTS frame, a first transmit permission (CTS) frame is sent to the first STA. A device in which the first wireless device transmits a race-free termination (CF termination) frame based on the fact that it does not receive the data within a certain period of time from the transmission of the first CTS frame.

49. A device, wherein the device is The first wireless device, Send a first Transmit Request (RTS) frame via the first link requesting the transmission of data via the first link to the first wireless device, and A second RTS frame is transmitted via the second link, requesting the transmission of data via the second link to the first wireless device. From the first wireless device, In response to the first RTS frame, a first transmit permission (CTS) frame is received via the first link, and The second link receives a second CTS frame in response to the second RTS frame. A device that transmits to the first wireless device a frame indicating the transmission of the data to the first wireless device via the second link, based on the transmission of the data to the first wireless device via the second link.

50. A device, wherein the device is From the first wireless device, The first link receives the first transmit permission (CTS) frame, and The second CTS frame is received via the second link. Based on the first CTS frame, a first network assignment vector (NAV) is set for the first link, and based on the second CTS frame, a second NAV is set for the second link. A device that resets the first NAV for the first link based on receiving a conflict-free termination (CF termination) frame from the device via the first link.

51. A wireless communication system comprising a plurality of devices according to any one of claims 48 to 50.

52. A computer program, which can be stored in a computer-readable medium, that, when executed on a processor, performs the method according to any one of claims 1 to 47.

Images