Link priority-based multi-access point coordination

Abstract

Methods, devices, and systems are provided to improve the operation of multilink devices. In one example, a device is proposed that acts as a first access point (AP) and is configured to receive a first frame from a second AP indicating the priority of the first link among multiple links for communicating first category traffic over the first link by the second AP, and to transmit a second frame containing second category traffic over a second link among multiple links, the second link being selected based on the priority of the first link. This device can be configured to select the second link for transmitting second category traffic.

Description

Technical Field

[0001] The present invention relates to wireless networks, particularly those using local area technologies such as IEEE 802.11, but is not limited thereto.

Background Art

[0002] Latest wireless networks are often deployed at high density, and devices need to be able to adapt to changing situations. In other words, even complex devices are desired to achieve flexibility. Also, due to requirements for low-latency traffic, additional constraints may arise.

Summary of the Invention

Problems to be Solved by the Invention

[0003] The inventors have recognized that when a multi-link device (MLD) is used and transmission of low-latency traffic is required, a situation may occur where two devices are using a multi-link connection. In particular, the inventors have recognized that the problem may occur when an MLD non-AP STA receives a frame transmitted in an inter-AP frame in one of the multi-links. The STA may defer transmission of urgent (e.g., low-latency) traffic. In the case of IEEE 802.11, this may involve the STA setting its NAV. Or, the MLD STA may fail to receive an inter-AP frame and continue a transmission that interferes with the inter-AP frame.

Means for Solving the Problems

[0004] [[ID=?]] Embodiments and aspects of the present invention are defined in the appended claims.

[0005] In one embodiment, a method is provided comprising the steps of: a first access point (AP) receiving a first frame from a second AP indicating the priority of a first link among a plurality of links for communication of a first category of traffic by the second AP over a first link; the first AP selecting a second link among a plurality of links based on the priority of the first link in order to transmit a second category of traffic to the second AP; and the first AP transmitting a second frame containing a second category of traffic to the second AP over the second link.

[0006] In one embodiment, a method is provided for selecting the second link based on the priority of the first link, comprising the steps of: first access point (AP) receiving a first frame from second AP indicating the priority of the first link among a plurality of links for second category traffic to be communicated by second AP over the first link; and first AP transmitting a second frame containing second category traffic over the second link among a plurality of links.

[0007] According to one embodiment, the step of transmitting a second frame includes transmitting the second frame to a second AP or a first STA.

[0008] According to one embodiment, the step of receiving a first frame includes receiving the first frame via a first link or a second link.

[0009] According to the embodiment, the priority of the first link indicates that the second AP communicates only Category 1 traffic through the first link.

[0010] According to the embodiment, the priority of the first link indicates that the second AP does not communicate Category 1 traffic through the first link.

[0011] According to the embodiment, traffic streams of the first category are mapped to the first link in the second AP.

[0012] According to the embodiment, the first category of traffic includes low-latency traffic.

[0013] According to the embodiment, the first category of traffic includes traffic between the second AP and the second STA associated with the second AP.

[0014] According to the embodiment, the second category of traffic includes traffic between the first AP and the second AP.

[0015] According to the embodiment, the first frame further indicates the priority of the second link for the second AP to communicate Category 1 traffic over the second link.

[0016] According to one embodiment, the first frame further includes a period for the second AP to communicate the first category of traffic over the first link.

[0017] According to one embodiment, the first frame includes a management frame.

[0018] According to one embodiment, the management frame includes a beacon frame that includes an element indicating the priority of the first link.

[0019] According to one embodiment, the management frame includes an action frame that includes an action field indicating the priority of the first link.

[0020] According to this embodiment, the first AP sends a third frame to the second AP requesting the first frame.

[0021] According to this embodiment, the first AP transmits a fourth frame to the second AP in response to the first frame.

[0022] According to this embodiment, the first AP and the second AP form a multi-AP group. According to an embodiment, the first AP or the second AP includes a multi-link device (MLD).

[0023] According to one aspect, an apparatus is provided that is configured to function as a first access point (AP), receive a first frame from a second AP indicating the priority of a first link among a plurality of links for communication of traffic of a first category via the first link by the second AP, and transmit a second frame including traffic of a second category via a second link among the plurality of links, wherein the second link is selected based on the priority of the first link.

[0024] According to an embodiment, the apparatus is configured to select a second link for transmission of a second category.

[0025] According to one aspect, a system is provided that includes an apparatus as described above and a second AP.

[0026] According to one aspect, a computer program product is provided that is stored on a computer-readable medium and configured to execute the methods described herein when executed on a processor.

Brief Description of the Drawings

[0027] Examples of some of the various embodiments of the present disclosure are described herein with reference to the drawings. [Figure 1] A diagram showing an example of a wireless communication network in which embodiments of the present disclosure are implemented. [Figure 2] A block diagram showing an implementation example of a station (STA) and an access point (AP). [Figure 3] A diagram showing an example of a Medium Access Control (MAC) frame format. [Figure 4] A diagram showing an example of a management frame that can be used as an action frame. [Figure 5] A diagram showing an example of a control frame that can be used as a trigger frame. [Figure 6] A diagram showing an example of a data frame that can be used as a Quality of Service (QoS) null frame. [Figure 7] A diagram showing an example format for a Physical Layer (PHY) Protocol Data Unit (PPDU). [Figure 8] A diagram showing an example of a reference model for a multilink device (MLD). [Figure 9] A diagram showing examples of AP MLD and related non-AP MLD. [Figure 10] A diagram illustrating an example of a multilink setup between AP MLD and non-AP MLD. [Figure 11] A diagram illustrating an example of traffic identifier (TID) and link mapping in a multilink communication environment. [Figure 12] A diagram illustrating an example of a multi-AP network. [Figure 13] A diagram illustrating an example of a network including a coordinated set of APs. [Figure 14] A diagram illustrating an example of the operation procedure for a multi-AP. [Figure 15] A diagram illustrating an example of a multi-AP sounding phase. [Figure 16] A diagram illustrating an example of the data transmission phase of a multi-AP downlink. [Figure 17] A diagram illustrating an example of the data transmission phase of a multi-AP uplink. [Figure 18] A diagram illustrating an example of the multi-AP information exchange phase. [Figure 19] A diagram showing an example of the target wake time (TWT). [Figure 20] A diagram illustrating an example of a multi-AP network that supports multi-link operation (MLO). [Figure 21] A diagram illustrating an example of the procedure for multiple access points (APs) in a multilink environment. [Figure 22] A diagram illustrating an example of a multi-AP coordination procedure in a multilink environment according to the embodiment. [Figure 23]A diagram illustrating another example of a multi-AP coordination procedure in a multilink environment according to the embodiment. [Figure 24] A diagram illustrating another example of a multi-AP coordination procedure in a multilink environment according to the embodiment. [Figure 25] A diagram illustrating another example of a multi-AP coordination procedure in a multilink environment according to the embodiment. [Figure 26] A diagram showing an example of a beacon frame used according to the embodiment. [Figure 27] A diagram showing an example of an action frame used by the embodiment. [Figure 28] A diagram showing an example of processing according to the embodiments of this disclosure. [Figure 29] A diagram showing an example of processing according to the embodiments of this disclosure. [Modes for carrying out the invention]

[0028] This disclosure presents various embodiments as examples of how the disclosed technology may be implemented and / or how it may be carried out in environments and scenarios. It will be apparent to those skilled in the art that various modifications can be made to its form and details without departing from the scope. After reading the description, it will be apparent to those skilled in the art that alternative embodiments may be implemented. These embodiments are not limited to any of the exemplary embodiments described. Embodiments of this disclosure will be described with reference to the accompanying drawings. Further embodiments can be created within the scope of the disclosure by combining limitations, features and / or elements from the examples of the disclosed embodiments. Figures highlighting functions and benefits are presented for illustrative purposes only. The disclosed architecture is sufficiently flexible and configurable to be used in ways other than those illustrated. For example, the actions listed in any flowchart can be rearranged or used only optionally in some embodiments.

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

[0030] In this disclosure, “a” and “an” and similar phrases are interpreted as “at least one” and “one or more.” Similarly, terms ending in the suffix “(s)” are interpreted as “at least one” and “one or more.” In this disclosure, the term “may” is interpreted as “may, for example.” In other words, the term “may” indicates that the phrase following the term “may” is one example of a number of suitable possibilities that may or may not be adopted by one or more of the various embodiments. As used herein, the terms “have” and “consist of” enumerate one or more components of the element being described. The term “have” is interchangeable with “include” and does not exclude components not enumerated from being included in the element being described. In contrast, “consist of” provides a complete enumeration of one or more components of the element being described. As used herein, the term “based on” may be interpreted as “at least partially based” rather than, for example, “based only on.” As used herein, the term “and / or” represents any possible combination of the enumerated elements. For example, "A, B and / or C" can represent A, B, C, A and B, A and C, B and C, or A, B and C.

[0031] 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 term “based on” (or equally “at least based on”) indicates that the phrase following the term “based on” is one example of a number of suitable possibilities that may or may not be adopted in one or more of the various embodiments. The term “in response” (or similarly “at least in response”) indicates that the phrase following “in response” is one example of a number of suitable possibilities that may or may not be adopted in one or more of the various embodiments. The phrase “depending on” (or equally “at least depending on”) indicates that the phrase following the phrase “depending on” is one example of a number of suitable possibilities 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 “adopt / use” is one example of a number of suitable possibilities that may or may not be adopted in one or more of the various embodiments.

[0032] The term "configured" relates to the capabilities of a device, regardless of whether it is operational or non-operational. "Configured" can also refer to specific settings within a device that affect its operational characteristics, regardless of whether it is operational or non-operational. In other words, hardware, software, firmware, registers, memory values, and / or similar elements can be "configured" within a device, regardless of whether it is operational or non-operational.

[0033] Terms such as "control messages generated by a device" mean that control messages have parameters that can be used to set specific characteristics or implement specific actions within a device, regardless of whether the device is operational or non-operational.

[0034] In this disclosure, a parameter (also called a field or information element: IE) includes one or more information objects, and an information object may include one or more other objects. For example, if parameter (IE) N includes parameter (IE) M, parameter (IE) M includes parameter (IE) K, and parameter (IE) K includes parameter (information element) J, then for example, N includes K and N includes J. In the examples of embodiments, if one or more messages / frames include multiple parameters, it means that some of the multiple parameters are present in at least one of the one or more messages / frames, but not in each of the one or more messages / frames.

[0035] Many of the features presented are indicated as optional by the use of "may" or parentheses. For the sake of brevity and readability, this disclosure does not explicitly describe all possible variations that may be obtained by selecting from a set of optional features. This disclosure should be construed as explicitly disclosing all such variations. For example, a system described as having three optional features can be embodied in seven aspects, i.e., having only one of the three possible features, any two of the three possible features, or three of the three possible features.

[0036] Many of the elements described in the disclosed embodiments can be implemented as modules. Here, a module is defined as an element that performs a defined function and has a defined interface to other elements. Modules described in this disclosure can be implemented as hardware, software combined with hardware, firmware, wetware (e.g., hardware with biological elements), or a combination thereof, and these are 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 may be implemented using physical hardware that incorporates discrete or programmable analog, digital, and / or quantum hardware. Examples of programmable hardware include computers, microcontrollers, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and complex-programmable logic devices (CPLDs). Computers, microcontrollers, and microprocessors are programmed using languages ​​such as assembly, C, and C++. FPGAs, ASICs, and CPLDs are often programmed using hardware description languages ​​(HDLs) such as VHSIC (VHDL) or Verilog, which configure connections between less functional internal hardware modules on a programmable device. The aforementioned technologies are used in combination to achieve the results of functional modules.

[0037] Figure 1 shows an example of a wireless communication network 100 in which an embodiment of the present disclosure is implemented.

[0038] As shown in Figure 1, an example of a wireless communication network 100 may include an IEEE 802.11 (WLAN) infrastructure network 102. The WLAN infrastructure network 102 may include one or more basic service sets (BSS) 110 and 120 and a distribution system (DS) 130.

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

[0040] DS 130 can be configured to connect BSS 110-1 and BSS 110-2. In this way, DS130 can enable Extended Service Set (ESS) 150. Within ESS 150, AP 104-1 and AP 104-2 can be connected via DS 130 and have the same Service Set ID (SSID).

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

[0042] The example wireless communication network shown in Figure 1 may further include one or more ad-hoc networks or independent BSS (IBSS). An ad-hoc network or IBSS is a network containing multiple STAs that are within each other's communication range. The multiple STAs are configured to communicate with each other directly using peer-to-peer communication (i.e., without going through APs).

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

[0044] An STA as a designated functional medium may include a Media Access Control (MAC) layer compliant with the IEEE 802.11 standard. The physical layer interface of the wireless medium can be used between an AP and a non-AP station (STA). An STA may also be referred to using a variety of other terms, 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 indicate an STA participating in uplink multi-user multiple input multiple output (MU MIMO) and / or uplink orthogonal frequency division multiple access (OFDMA) transmissions.

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

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

[0047] Figure 2 is a block diagram 200 showing implementation examples of STA210 and AP260. As shown in Figure 2, STA210 can include at least one processor 220, memory 230, and at least one transceiver 240. AP260 can include at least one processor 270, memory 280, and at least one transceiver 290. Processors 220 / 270 can be operationally connected to transceivers 240 / 290.

[0048] The transceivers 240 / 290 can be configured to transmit and receive radio signals. In an embodiment, the transceivers 240 / 290 can implement the PHY layer of the corresponding device (STA210 or AP260).

[0049] In embodiments, the STA210 and / or AP260 may be multilink devices (MLDs), i.e., devices capable of operating on multiple links as defined by the IEEE 802.11be revision. Therefore, the STA210 and / or AP260 may each have multiple PHY layers. These multiple PHY layers may be implemented using one or more transceivers 240 / 290.

[0050] The 220 / 270 processor can implement the functions of the PHY layer, MAC layer, and / or Logical Link Control (LLC) layer of the corresponding device (STA210 or AP260).

[0051] The processors 220 / 270 and / or transceivers 240 / 290 may include application-specific integrated circuits (ASICs), other chipsets, logic circuits, and / or data processors. The memory 230 / 280 may include read-only memory (ROM), random-access memory (RAM), flash memory, memory cards, storage media, and / or other storage units.

[0052] When the embodiments are implemented by software, the techniques (or methods) described herein can be implemented in a module (e.g., a process, a function, etc.) that performs the functions described herein. The module can be stored in memory 230 / 280 and executed on processor 220 / 270. Memory 230 / 280 can be implemented (or located) within or outside of processor 220 / 270. Memory 230 / 280 can be operationally connected to processor 220 / 270 by various means known in the art.

[0053] Figure 3 shows an example of the MAC frame 300 format. During operation, the STA can construct a subset of MAC frames for transmission and decode a subset of received MAC frames during verification. The specific subset of frames that the STA can construct and / or decode is determined by the features supported by the STA. The STA can 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.

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

[0055] The MAC header includes a frame control field, an optional duration / ID field (not present in PS-Poll frames), an address field, an optional sequence control field, an optional QoS control field (only present in QoS data frames), and an optional high-throughput (HT) control field (only present in +HTC frames).

[0056] The frame control field includes the following subfields: protocol version, type, subtype, destination DS, source DS, additional fragments, retry, power management, additional data, protected frame, and high-throughput control (+HTC).

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

[0058] The Type subfield and Subtype subfield identify the function of a MAC frame. There are three frame types: Control, Data, and Management. Each frame type has several predefined subtypes. Bits within the Subtype subfield can be used to indicate specific modifications to the base data frame (subtype 0). For example, in a data frame, the most significant bit (MSB) of the Subtype subfield, bit 7 (B7) of the Frame Control field, is defined as the QoS subfield. When the QoS subfield is set to 1, it indicates a QoS subtype data frame (a data frame that includes a QoS control field in its MAC header). The second MSB of the Subtype field, bit 6 (B6) of the Frame Control field, when set to 1 in a Data subtype, indicates a data frame that does not include the Frame Body field.

[0059] The destination DS subfield indicates whether the data frame is addressed to that DS. The source DS subfield indicates whether the data frame originates from that DS.

[0060] In all data frames or management frames that have another fragment following the MAC Service Data Unit (MSDU) or MAC Management Protocol Data Unit (MMPDU) carried by the MAC frame, the Additional Fragment subfield is set to 1. This is set to 0 in all other frames where the Additional Fragment subfield exists.

[0061] The retry subfield is set to 1 in data frames or management frames that are retransmissions of previous frames. It is set to 0 in all other frames where the retry subfield exists. The receiving STA uses this metric to assist in the process of removing duplicate frames. These rules do not apply to frames sent by the STA based on a block agreement.

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

[0063] The additional data subfield indicates to an STA in power saving (PS) mode that a bufferable unit (BU) is being buffered at the AP for that STA. The additional data subfield is valid for individually addressed data or management frames sent by the AP to an STA in PS mode. The additional data subfield is set to 1 to indicate that at least one additional buffered BU exists for the STA.

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

[0065] The +HTC subfield indicates that MAC frame 300 contains an HT control field. Frames containing an HT control field are called +HTC frames. Control wrapper frames are +HTC frames.

[0066] The Duration / ID field in the MAC header contains various values ​​depending on the frame type and subtype, as well as the QoS capabilities of the transmitting STA. For example, in a control frame of the Power-Saving Polling (PS-Poll) subtype, the Duration / ID field carries the Association Identifier (AID) of the STA that sent the frame in 14 least significant bits (LSBs), and both most significant bits (MSBs) are set to 1. In other frames sent by an STA, the Duration / ID field contains a Duration value (in microseconds) used by the receiver to update the Network Allocation Vector (NAV). The NAV is a counter that tells the STA how long access to the shared media should be delayed.

[0067] In the MAC frame 300 format, there can be up to four address fields. These fields are used to identify the Basic Service Set Identifier (BSSID), Source Address (SA), Destination Address (DA), Sender Address (TA), and Receiver Address (RA). Certain frames may omit some address fields. The usage of a particular address field can be specified by its relative position (1 through 4) in the MAC header, regardless of the type of address present in that field. Specifically, address field 1 always identifies the destination recipient of the frame, and address field 2, if present, always identifies the sender of the frame.

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

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

[0070] The HT control field is present in QoS data, QoS nulls, and management frames, determined by the +HTC subfield of the frame control field. The control frame subtype in which the HT control field exists is the control wrapper frame. A control frame described as +HTC (e.g., request to send (RTS) +HTC, clear to send (CTS) +HTC, block acknowledgment (BlockAck) +HTC, or block acknowledgment request (BlockAckReq) +HTC frame) means that a control wrapper frame is used to transmit that control frame.

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

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

[0073] Figure 4 shows an example of a management frame 400 that can be used as an action frame. For example, a management frame 400 includes a MAC header, a variable-length frame body, and a frame check sequence (FCS). The MAC header includes a frame control field, a duration field, an address 1 field, an address 2 field, an address 3 field, a sequence control field, and an optional HT control field. The presence of the HT control field is determined by the setting of the +HTC subfield of the frame control field.

[0074] As shown in Figure 4, when used as an action frame, the frame body of the management frame includes an action field, vendor-specific elements, a management message integrity code element (MME), a message integrity code (MIC), and an authenticated mesh peering exchange element.

[0075] The action field includes a category field and an action details field. The action field provides a mechanism for specifying extended management actions. The category field indicates the category of the action frame. The action details field contains details of the action requested by the action frame. For example, the action frame can be a public action frame. As shown in Figure 4, in the public action frame format, the action details field contains the public action field in the octet immediately following the category field, followed by a variable-length public action details field.

[0076] One or more vendor-specific elements are optionally present. These elements are not present if the category subfield of the action field is vendor-specific.

[0077] MME is a robust action frame where management frame protection is negotiated and the frame is group-addressed, and it exists when the action frame category (MBSS only) does not support group-addressed privacy indicated by the category value, and does not exist otherwise.

[0078] The MIC element is present in the self-protection action frame if a shared pairwise master key (PMK) exists between the sender and receiver of this frame; otherwise, it is not present.

[0079] Authenticated mesh peering exchange elements are present in the self-protection action frame if a shared PMK exists between the sender and receiver of this frame, and not otherwise.

[0080] Figure 5 shows an example of the format of trigger frame 500. Trigger frame 500 can be used by an AP to allocate resources to one or more STAs and to request one or more TB PPDU transmissions from one or more STAs. Trigger frame 500 can also carry other information required by the responding STA to send TB PPDUs to the AP.

[0081] As shown in Figure 5, the trigger frame 500 includes a frame control field, a duration field, a receiver address (RA) field, a transmitter address (TA) field, a common information field, a user information list field, a padding field, and an FCS field.

[0082] The frame control field includes subfields for protocol version, type, subtype, destination DS, source DS, additional fragments, retry, power management, additional data, protected frame, and +HTC.

[0083] The duration field contains various values ​​depending on the frame type and subtype, and the QoS capabilities of the transmitting STA. For example, in a control frame of the power-saving polling (PS-Poll) subtype, the duration field carries the association identifier (AID) of the STA that transmitted the frame in 14 least significant bits (LSBs), and both most significant bits (MSBs) are set to 1. In other frames transmitted by the STA, the duration field contains a duration value (in microseconds) used by the receiver to update the network allocation vector (NAV).

[0084] The RA field is the address of the STA intended to receive incoming transmissions from the transmitting station. The TA field is the address of the STA sending trigger frame 500 if trigger frame 500 is addressed to an STA belonging to a single BSS. The TA field is the BSSID being sent if trigger frame 500 is addressed to an STA from at least two different BSSs of a set of multiple BSSIDs.

[0085] The Common Information field specifies the trigger frame type of trigger frame 500, the transmit power (dBm) of trigger frame 500, and several key parameters of the TB PPDU transmitted by the STA in response to trigger frame 500. The trigger frame type of the trigger frame used by the AP to receive QoS data using UL MU operation is called the base trigger frame. Non-EHT non-AP HE STAs interpret the Common Information field as an HE variant. Non-AP EHT STAs interpret the Common Information field as an HE variant if B54 and B55 of the Common Information field are equal to 1, and as an EHT variant otherwise. The Common Information field for HE variants and the Common Information field for EHT variants use the same encoding scheme for the rigger type, UL length, additional TF, requested CS, LDPC additional symbol segment, AP TX power, FEC pre-padding coefficient, PE disambiguation (PE Disambiguation), and trigger-dependent Common Information subfields.

[0086] The User Information List field contains zero or more User Information fields. User Information fields have three variants: Special User Information fields, EHT variant User Information fields, and HE variant User Information fields.

[0087] The Special User Information field is a user information field that does not contain user-specific information but carries extended common information not provided in the Common Information field. If the Special User Information field is included in the trigger frame, the Special User Information field flag subfield of the EHT variant common information field is set to 0; otherwise, it is set to 1. The Special User Information field is identified by the AID12 value of 2007 and is optionally present in trigger frames generated by the EHT AP. If present, the Special User Information field is immediately following the common information field in the trigger frame and carries information for the U-SIG field of the requested EHT TB PPDU. The PHY Version Identifier subfield indicates the PHY version of the requested TB PPDU that is not an EHT TB PPDU. The PHY Version Identifier subfield is set to 0 for EHT. Other values ​​from 1 to 7 are reserved. The UL Bandwidth Extension subfield, along with the UL BW subfield in the Common Information field, indicates the bandwidth of the requested TB PPDU from the addressed EHT STA (i.e., the bandwidth of the U-SIG field of the EHT TB PPDU). The EHT Space Reuse n subfield carries the value that should be contained in the corresponding Space Reuse n subfield in the U-SIG field of the EHT TB PPDU. The U-SIG Disregard and Validate subfield carries the value that should be contained in the Disregard and Validate subfield of the U-SIG field of the requested EHT TB PPDU. The presence and length of the Trigger Dependent User Information subfield in the Special User Information field vary depending on the trigger frame variant.

[0088] The EHT variant user information field includes a user information field per STA addressed in the trigger frame 500. The user information field per STA includes, among other things, the AID12 subfield, the RU allocation subfield, the UL FEC coding type subfield, the UL EHT-MCS subfield, the reservation subfield, the spatial stream (SS) allocation / RA-RU information subfield, the UL target received power subfield, the power saving (PS)160 subfield used by the STA in the TB PPDU transmitted in response to the trigger frame 500, and the trigger-dependent user information subfield. The RU allocation subfield of the EHT variant user information field for trigger frames that are not MU-RTS trigger frames, together with the UL BW subfield in the common information field, the UL BW extension subfield in the special user information field, and the PS160 subfield in the user information field of the EHT variant, specifies the size and location of the RU or MRU. The value of the PS160 subfield and B0 of the RU assignment subfield indicate an 80 MHz frequency subblock, where RUs or MRUs are assigned to 26-tone RUs, 52-tone RUs, 106-tone RUs, 242-tone RUs, 484-tone RUs, 996-tone RUs, 52+26-tone RUs, and 106+26-tone RUs. The value of the PS160 subfield indicates a 160 MHz segment where RUs or MRUs are assigned to 2 996-tone RUs, 996+484-tone MRUs, and 996+484+242-tone MRUs. The [UL FEC Encoding Type subfield] in the User Information field indicates the coding type of the requested EHT TB PPDU. The UL FEC Encoding Type subfield is set to 0 to indicate BCC and to 1 to indicate LDPC. The UL EHT-MCS subfield in the user information field indicates the EHT-MCS of the requested EHT TB PPDU. The SS allocation subfield in the user information field for the EHT variant indicates the spatial stream of the requested EHT TB PPDU.The UL Target Received Power subfield indicates the expected received signal power, measured at the AP's antenna connector and averaged across the antennas, for the EHT portion of the EHT TB PPDU transmitted by the assigned RU. The Trigger-Dependent User Information subfield can be used by the AP to specify the Preferred Access Category (AC) per STA. The Preferred AC sets the lowest priority AC traffic that participating STAs can transmit. The AP determines the list of participating STAs along with BW, MCS, RU assignment, SS assignment, Tx power, Preferred AC, and the maximum duration of the TB PPDU per participating STA. The RA-RU Information subfield is reserved in the EHT Variant User Information field.

[0089] A padding field is optionally present in trigger frame 400 to extend the frame length, giving the receiving STA sufficient time to prepare a transmit response 1 SIFS after the frame is received. If present, the padding field is at least 2 octets long and all are set to 1.

[0090] The FCS field is used by the STA to validate the received frame and interpret specific fields from the frame's MAC header.

[0091] Figure 6 shows an example of a data frame 600 that can be used as a QoS null frame. A QoS null frame refers to a QoS data frame with an empty frame body. A QoS null frame includes a QoS control field and an optional HT control field that includes a Buffer Status Report (BSR) control subfield. A QoS null frame showing buffer status information can be sent by the STA to the AP.

[0092] QoS control fields may include a Traffic Identifier (TID) subfield, an Acknowledgment (Ack) policy indicator subfield, and a queue size subfield (or a Transmit Opportunity (TXOP) duration request subfield).

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

[0094] The Acknowledgment Policy Indicator subfield, along with other information, identifies the Ack policy followed when the MPDU is delivered (e.g., normal Ack, implicit block Ack request, no Ack, block Ack, etc.).

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

[0096] For frames sent by or to a non-high efficiency (non-HE) STA, the following rules may apply to the queue size value:

[0097] The queue size value is the approximate total size of all MSDUs and A-MSDUs buffered by the STA in the delivery queue used for MSDUs and A-MSDUs, rounded up to the nearest multiple of 256 octets and expressed in units of 256 octets, with the TID value being equal to the value shown in the TID subfield of the QoS control field.

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

[0099] The queue size value 254 is used for all sizes exceeding 64,768 octets.

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

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

[0102] The queue size value (QS) is 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 in a delivery queue for MSDUs and A-MSDUs that have a TID value equal to the value indicated in the TID subfield of the QoS control field.

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

[0104] The STA obtains the queue size QS from the received QoS control field, which includes the scaling factor SF and the unscaled value UV, as follows: QS = If SF is equal to 0, then 16 × UV; If SF is equal to 1, then 1024 + 256 × UV; If SF is equal to 2, then 17 408 + 2048 × UV; If SF is equal to 3 and UV is less than 62, then 148 480 + 32 768 × UV; If SF is equal to 3 and UV is equal to 62, then > 2 147 328; If SF is equal to 3 and UV is equal to 63, it is unspecified or unknown.

[0105] The TXOP Duration Request subfield can be included in place of the queue size subfield and indicates the duration in 32 microseconds (us) that the sending STA determines is necessary for the next TXOP for a given TID. The TXOP Duration Request subfield is set to 0 to indicate that no TXOP is requested for a given TID during the current service period (SP). The TXOP Duration Request subfield is set to a non-zero value to indicate a requested TXOP duration ranging from 32 us to 8160 us in 32 us units.

[0106] An HT control field can contain an aggregate control (A-Control) subfield. An A-Control subfield can contain a control list subfield that contains one or more control subfields.

[0107] The control subfield may be a BSR control subfield containing buffer status information used for UL MU operation. The BSR control subfield may be formed from the Access Category Index (ACI) bitmap subfield, the Delta TID subfield, the ACI High subfield, the Scaling Factor subfield, the Queue Size High subfield, and the Queue Size Full subfield of the HT control field.

[0108] The ACI bitmap subfield indicates the access category for which buffer status 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 to indicate that the buffer status for the corresponding AC is included in all subfields of the queue size; otherwise, it is set to 0. However, if the ACI bitmap subfield is 0 and the Delta TID subfield is 3, then the buffer status for all eight TIDs is included.

[0109] The Delta TID subfield, along with the value of the ACI bitmap subfield, indicates the number of TIDs for which the STA is reporting buffer status.

[0110] The ACI high subfield indicates the ACI of an AC for which a BSR is shown in the queue size high subfield. The mapping from ACI to AC is defined as the mapping from ACI value 0 to AC_BE, from ACI value 1 to AC_BK, from ACI value 2 to AC_VI, and from ACI value 3 to AC_VO.

[0111] The scaling factor subfield shows the units SF of the queue size high and queue size all subfields in octets.

[0112] The queue size high subfield indicates the amount of buffered traffic for ACs identified in the ACI high subfield, in SF octets, for STAs identified by the receiving address of the frame containing the BSR control subfield.

[0113] The queue size all subfield indicates the amount of buffered traffic in SF octets for all ACs identified in the ACI Bitmap subfield, targeting STAs identified by the receiving address of the frame including the BSR control subfield.

[0114] The queue size values ​​for the queue size high and queue size all subfields are the sum 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 and ACI bitmap subfields, respectively, rounded up to the nearest multiple of the SF octet.

[0115] A queue size value of 254 in the queue size high and queue size all subfields indicates that the amount of buffered traffic exceeds 254 × SF octets. A queue size value of 255 in the queue size high and queue size all subfields indicates that the amount of buffered traffic is of an unspecified or unknown size. The queue size value for QoS dataframes containing fragments may remain constant even if the amount of traffic queued changes as consecutive fragments are sent.

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

[0117] Figure 7 shows an example of a PPDU format. As illustrated, a PPDU can include a PHY preamble, PHY header, PSDU, and tail and padding bits.

[0118] A PSDU can contain one or more MPDUs, such as QoS data frames, MMPDUs, MAC control frames, and QoS null frames. In the case of an MPDU that carries a QoS data frame, the frame body of the MPDU can contain an MSDU or A-MSDU.

[0119] By default, MSDU transmission is best-effort based; that is, there is no guarantee that a transmitted MSDU will be successfully delivered. However, the QoS facility uses a Traffic Identifier (TID) to specify a service distinct for each MSDU.

[0120] STA can differentiate MSDU deliveries according to the designated traffic category (TC) or traffic stream (TS) of individual MSDUs. MAC sublayer entities determine the user priority (UP) of an MSDU based on the TID value provided by the MSDU. The QoS facility supports eight UP values. The UP values ​​range from 0 to 7, with 1 being the minimum value, 7 being the maximum value, and 0 representing an ordered priority between 2 and 3.

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

[0122] The STA can deliver Buffer Status Reports (BSRs) to help the AP allocate UL MU resources. The STA can implicitly deliver BSRs in the QoS control field or BSR control subfield of frames sent to the AP (unsolicited BSRs), or explicitly deliver BSRs in frames sent to the AP in response to BSRP trigger frames (solicited BSRs).

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

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

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

[0126] If the AP indicates support for receiving the BSR control subfield, the STA can report the buffer status in the BSR control subfield of the transmitted frame.

[0127] High Efficiency (HE) STAs can report the queue size of the preferred AC indicated by the ACI High subfield in the Queue Size High subfield of the BSR control subfield. The STA can set the Queue Size High subfield to 255 to indicate the unknown / unspecified queue size of that AC.

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

[0129] Figure 8 shows an example of a reference model for a multilink device (MLD). An MLD is an entity that can manage communication across multiple links. An MLD is a logical entity and may have multiple associated stations (STAs). An MLD can be an access point MLD (AP MLD) whose affiliated STAs are AP STAs (or APs). An MLD can be a non-access point MLD (non-AP MLD) whose affiliated STAs are non-AP STAs (or STAs).

[0130] Communication between different frequency bands / channels may or may not occur simultaneously, depending on the capabilities of both the communicating AP MLD and non-AP MLD.

[0131] As shown in Figure 8, an MLD can have a single MAC service access point (MAC-SAP) to the LLC layer containing MAC data services. An MLD can support multiple MAC sublayers coordinated by sublayer management entities (SMEs). Each AP STA (or non-AP STA) associated with an AP MLD (or non-AP MLD) has a different MAC address within the MLD.

[0132] The SME is responsible for coordinating the MAC sublayer management entities (MLMEs) of the MLD's associated STAs to maintain a single robust security network association (RSNA) key management entity and a single IEEE 802.1X authenticator or supplicant for multilink operation (MLO).

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

[0134] Figure 9 shows examples of AP MLD and related non-AP MLD.

[0135] As shown, an AP MLD has two associated APs (AP1 and AP2), and a non-AP MLD has two associated STAs (STA1 and STA2). AP MLDs and non-AP MLDs can be communicatively coupled 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.

[0136] Generally, the MAC addresses of MLDs and their associated STAs are different from each other. For example, as shown in Figure 9, AP MLD has MAC address M, AP1 has MAC address w, and AP2 has MAC address x. Similarly, non-AP MLDs have MAC address P, STA1 has MAC address y, and STA2 has MAC address z.

[0137] As shown in Figure 9, for each MLD, the MAC sublayer can 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 local to each link. Some functions require joint processing by both the MLD upper and MLD lower MAC sublayers.

[0138] The MLD upper MAC sublayer features 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); Assignment of sequence number (SN) / packet number (PN) for frames to be encrypted by a pairwise transient key (PTK) for unicast frames; Encryption / decryption of unicast frames using PTK; Selection of the MLD lower MAC sublayer for transmission (mapping from TID to link); Packet reordering to ensure sequential delivery for each Block Ack session; Block Ack scoreboard for individually addressed frames (in conjunction with the MLD lower MAC sublayer); optionally, the MLD upper MAC sublayer distributes Block Ack records on one link across the MLD lower MAC sublayers of other links; MLD-level management information exchange / display via the MLD lower MAC sublayer.

[0139] The MLD lower MAC sublayer functions include the following: Link-specific GTK / IGTK / BIGTK maintenance (between APs belonging to AP MLD 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 MLD and STAs belonging to non-AP MLDs); Link-specific management information exchange / indicators (such as beacons); Link-specific control information exchange / indicators (RTS / CTS, acknowledgments, etc.); Power save states and modes; MAC address filtering for frame reception; and Block Ack scoreboard for individually addressed frames (in conjunction with the MLD upper MAC sublayer); optionally, the MLD lower MAC sublayer receives Block Ack records from the MLD upper MAC sublayer on other links.

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

[0141] In a (re)association request frame, a non-AP MLD indicates the link for which (re)setup is requested, and the functional and operational parameters of the requested link. A non-AP MLD can 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 functional and operational parameters of the requested link, are independent of the existing set-up link with the associated AP MLD, and the functional and operational parameters of the set-up link.

[0142] In the (re)association response frame, the AP MLD may indicate the requested links that were approved, the requested links that were rejected in the (re)setup, and the functionality and operational parameters of the requested links. The AP MLD may approve a subset of the links that were requested for (re)setup. 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.

[0143] An MLD requesting or approving a multilink (re)setup of any two links ensures that each link is placed on a different, non-overlapping channel. Upon successful multilink (re)setup between a non-AP MLD and an AP MLD, the non-AP MLD and AP MLD establish 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, functionality between the non-AP STA and its associated AP is enabled unless the functionality has been extended to the MLD level or otherwise specified.

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

[0145] A non-AP MLD can initiate multilink setup by having a non-AP STA 1 send an association request frame to AP 1, 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 STA 1, and the receiver address (RA) field is set to the MAC address of AP 1. The association request frame includes the MLD MAC address of the non-AP MLD and basic multilink elements that show complete information about non-AP STA 1, non-AP STA 2, and non-AP STA 3. The association request frame can request the setup of three links between the non-AP MLD and the AP MLD (the link between AP 1 and non-AP STA 1, the link between AP 2 and non-AP STA 2, and the link between AP 3 and non-AP STA 3).

[0146] An AP MLD can respond to a requested multilink setup by having the AP send an association response frame to the non-AP MLD. In the association response frame, the TA field is set to the MAC address of AP 1, and the RA field is set to the MAC address of non-AP STA 1. The association response frame may include the MLD MAC address of the AP MLD and basic multilink elements showing complete information for AP 1, AP 2, and AP 3. The association response frame indicates that the multilink setup was successful with the setup of three links between the non-AP MLD and the AP MLD (link 1 between AP 1 and non-AP STA 1, link 2 between AP 2 and non-AP STA 2, and link 3 between AP 3 and non-AP STA 3).

[0147] By default, all TIDs for non-AP MLDs are mapped to all setup links, 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 UL and DL QoS traffic corresponding to different TIDs (e.g., between 0 and 7) should be allocated to the setup links. In negotiated TID-to-link mappings, TIDs can be mapped to link sets, which are subsets of setup links, ranging from a single setup link to all setup links.

[0148] A setup link is defined as valid for non-AP MLDs if at least one TID is mapped to that link in either the DL or UL, and as invalid if no TID is mapped to that link in either the DL or UL. At any given time, a TID is always mapped to at least one setup link in either the DL or UL, meaning that a change in the mapping from a TID to a link is only valid and successful if it does not result in a TID having a set of mapped links that results in zero setup links.

[0149] By default, all setup links are enabled. When a link is enabled for a non-AP MLD, it can be used for exchanging individually addressed frames, depending on the power status of the non-AP STA operating on that link. Only MSDUs or A-MSDUs with a TID mapped to the link can be transmitted on that link in the direction corresponding to the TID-to-link mapping (DL / UL). Individually addressed management and control frames can be transmitted in both DL and UL on enabled links between the associated STA of the non-AP MLD and the corresponding AP of the AP MLD.

[0150] If a non-AP MLD link is disabled, that link cannot be used for the exchange of individually addressed frames between the associated STA of the non-AP MLD and the corresponding AP of the AP MLD.

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

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

[0153] When the default mode is used, a non-AP MLD can obtain BUs buffered by AP MLD on any setup link, but AP MLD may recommend a link.

[0154] A non-AP MLD can obtain a buffered BU, which is an MMPDU buffered by an AP MLD on an enabled link. An AP MLD can use any enabled link to send an individually addressed bufferable management frame, which is not a measured MMPDU, depending on the power status of the non-AP STA on the link being used.

[0155] 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 the AP MLD may transmit the following to that STA: an MSDU / A-MSDU for the mapped TID set for the non-AP MLD, and an MMPDU other than the measured MMPDU for the non-AP MLD or its affiliated STA, except for frames transmitted to another STA belonging to the same non-AP MLD and in active mode.

[0156] As mentioned 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 must operate in this mode if negotiation of TID-to-link mapping for another mapping has not occurred, failed, or been discarded.

[0157] In the multilink (re)setup procedure, if the AP MLD indicates support for negotiating TID-to-link mappings, the non-AP MLD can initiate TID-to-link mapping negotiations by including a "TID-to-link mAPping" element in the (re)association request frame.

[0158] After receiving a (re)association request frame containing the "TID to Link Mapping" element, the AP MLD may respond to the (re)association request frame according to the following rules: The AP MLD may accept the requested TID-to-link mapping, as indicated in the "TID to Link Mapping" element of the received (re)association request frame, only if it accepts a multilink (re)setup for all links for which a mapping of at least one TID is requested. In this case, the non-AP MLD will include the "TID to Link Mapping" element in the (re)association response frame. Otherwise, the non-AP MLD will indicate rejection of the proposed TID-to-link mapping by including a "TID to Link Mapping" element in the (re)association response frame that proposes a preferred TID-to-link mapping.

[0159] After a successful multilink (re)setup, the initiating MLD can send a individually addressed "TID to link mapping" request frame to the responding MLD, which has indicated support for negotiating a new TID to link mapping.

[0160] Upon receiving an individually addressed "TID to Link Mapping" request frame, the responding MLD 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 of the received "TID to Link Mapping" request frame by sending a "TID to Link Mapping" response frame. Otherwise, the responding MLD may indicate a rejection of the TID to link mapping proposed in the "TID to Link Mapping" response frame. The responding MLD may propose a recommended TID to link mapping in the "TID to Link Mapping" response frame by including a "TID to Link Mapping" element in the "TID to Link Mapping" response frame.

[0161] An MLD can suggest a preferred TID-to-link mapping to a peer MLD by sending an unsolicited "TID-to-link mapping" response frame that includes the "TID-to-link mapping" element.

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

[0163] If two MLDs negotiate a TID-to-link mapping, either MLD can discard the negotiated TID-to-link mapping by sending an individually addressed "TID-to-link mapping" discard frame. After discarding, the MLD operates in its default mapping mode.

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

[0165] If the MLD successfully negotiates the TID-link mapping between the peer MLD and the uplink and / or downlink, and bit position i of the link mapping field n in the TID-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 the MLD successfully negotiates the TID-link mapping between the peer MLD and the uplink and / or downlink, and bit position i of the link mapping field n in the TID-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.

[0166] Figure 11 shows an example of TID-to-link mapping in a multilink communication environment. As shown in the figure, the multilink communication environment includes AP MLDs with three associated APs and non-AP MLDs with three associated STAs.

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

[0168] AP MLD can advertise the required TID-to-Link mapping by including a TID-to-Link Mapping element in the Beacon and Probe Response frames transmitted by APs belonging to AP MLD.

[0169] APs belonging to an AP MLD can schedule the transmission of link recommendation frames to provide link recommendations to sets of non-AP MLDs.

[0170] AP MLD uses TID-to-link mapping procedures advertised in beacon and probe response frames to disable or enable links to all related non-AP MLDs.

[0171] A Non-Simultaneous Transmit / Receive (NSTR) mobile AP MLD is a mobile AP MLD that has at least one NSTR link pair. An NSTR link pair is a pair of links corresponding to STAs belonging to an MLD where, when an STA belonging to the MLD is transmitting on the other link, the receiving requirements are not met on one link. Each link in such a pair is a member of the NSTR link pair. For example, if an MLD supports simultaneous transmission on link 1 and reception on link 2, but cannot simultaneously support transmission on link 2 and reception on link 1, then link 1 and link 2 are the NSTR link pair for that MLD.

[0172] A simultaneous transmit and receive (STR) link pair is a pair of links that is not an NSTR link pair. If the pair of links on which the MLD operates is an STR link pair, an STA belonging to the MLD and operating on the first link of the STR link pair will, unless otherwise specified, access the radio media on the first link according to EDCA rules, regardless of any activity occurring on the second link of the STR link pair.

[0173] For AP MLDs that operate with multiple links (unlike NSTR Mobile AP MLDs), all pairs of links are STR link pairs. If an AP MLD that is not an NSTR Mobile AP MLD operates with only one link, the STR requirements and functionality corresponding to the link pair no longer apply.

[0174] An AP belonging to an AP MLD that has obtained the right to initiate transmission of an AC frame on a link through EDCA rules may choose not to transmit the frame corresponding to that AC due to expected interference caused by transmissions on other links in the NSTR link pair to which the link in the target receiving non-AP MLD belongs, and due to the lack of availability of alternative frames in the queue that do not introduce an opportunity for such interference.

[0175] A non-AP STA belonging to a non-AP MLD operating on a link of an NSTR link pair, which has obtained the authority to initiate transmission of an AC frame on the link via an EDCA backoff rule, or has been enabled by the AP, the TXOP owner, to use a portion of a TXOP obtained via a triggered TXOP sharing rule, may choose not to transmit a frame corresponding to its AC due to the interference expected to be caused by transmissions by non-AP STAs operating on other links of the NSTR link pair within the non-AP MLD, and because no alternative frame that does not introduce an opportunity for such interference is available in the queue.

[0176] Figure 12 shows an example of a multi-AP network 1200. The example multi-AP network 1200 can be a multi-AP network that conforms to the Wi-Fi Alliance standard specification for multi-AP networks. As shown in Figure 12, the multi-AP network 1200 may include a multi-AP controller 1202 and multiple multi-AP groups (or multi-AP sets, or AP candidate sets), including multi-AP group 1204, multi-AP group 1206, and multi-AP group 1208.

[0177] The multi-AP controller 1202 can be a logical entity that implements the logic for controlling APs in the multi-AP network 1200. The multi-AP controller 1202 can receive functional information and measurements from APs and trigger AP control commands and actions on the APs. The multi-AP controller 1202 can also provide onboarding functionality for onboarding and configuring APs in the multi-AP network 1200.

[0178] Multi-AP groups 1204, 1206, and 1208 can each contain multiple APs. APs within a multi-AP group are within each other's communication range. However, APs within a multi-AP group do not need to have the same primary channel. As used herein, the primary channel of an AP refers to the default channel that the AP uses to monitor management frames and / or transmit beacon frames. For an STA associated with an AP, the primary channel refers to the AP's primary channel, which is advertised via the AP's beacon frames.

[0179] One approach is to designate one of the APs in a multi-AP group as the master AP. The designation of the master AP can be done by the multi-AP controller 1202 or by an AP in the multi-AP group. The master AP of a multi-AP group may be fixed or it may change over time among the APs in the multi-AP group. APs that are not the master AP of a multi-AP group are called slave APs.

[0180] One approach is that a multi-AP group or AP candidate set is a set of APs that can initiate or join multi-AP coordination. APs in a multi-AP group can participate as slave APs in multi-AP coordination initiated by a master AP in the same multi-AP group. At least one AP in a multi-AP group must be able to become the master AP.

[0181] One approach is that APs within a multi-AP group can coordinate with each other, including coordinating transmissions within the multi-AP group. One aspect of coordination involves coordinating to perform multi-AP transmissions within the multi-AP group. As used herein, a multi-AP transmission is a transmission event in which multiple APs (of a multi-AP group or multi-AP network) transmit simultaneously over a period of time. The period of simultaneous AP transmission can be a continuous period.

[0182] Multi-AP group coordination can be enabled by a multi-AP controller or the master AP of a multi-AP group. One approach is for the multi-AP controller and / or master AP to control time and / or frequency sharing within a TXOP. For example, if one of the APs in a multi-AP group (e.g., the master AP) acquires a TXOP, the multi-AP controller and / or master AP can control how the time / frequency resources of that TXOP are shared with the other APs in the multi-AP group. In one implementation example, the AP in the multi-AP group that acquires the TXOP becomes the master AP of the multi-AP group. The master AP can share a portion (or the entirety) of its acquired TXOP with one or more other APs in the multi-AP group.

[0183] Multi-AP operation can be enabled by at least two APs that support multi-AP coordination within one or more multi-AP groups. APs can support multi-AP transmission in a multi-AP network. A master AP can cooperate with slave APs to enable multi-AP coordination and support multi-AP transmission. Slave APs can participate in multi-AP transmission. A master AP can select a slave AP suitable for multi-AP transmission. A slave AP may be a candidate for multi-AP transmission before being designated by the master AP.

[0184] The multi-AP transmission scheme may include transmission methods such as cooperative OFDMA, cooperative time-division multiplexing (TDMA), cooperative space reuse, cooperative beamforming, joint transmit or receive (JT / JR), or a combination of two or more of the aforementioned methods.

[0185] Coordinated OFDMA and coordinated TDMA are classified as coordinated TXOPs, and can use the frequency or time resources of a TXOP to tune interference. Coordinated spatial reuse (CSR) can provide spatial domain reuse of adjacent BSSs by adjusting the transmit power of coordinated APs. Coordinated beamforming (CBF) can use multiple antennas to suppress interference and provide dedicated null steering through spatial radiation based on channel state information (CSI) feedback from coordinated APs. JT / JR can use distributed MIMO precoding or detection via shared CSI for data streams between multiple APs.

[0186] Figure 13 shows an example of network 1300 with a coordinated AP set. As shown in Figure 13, the coordinated AP set can include AP1302-1 and AP1302-2. The coordinated AP set can be a subset of an established multi-AP group. At least one STA can be associated with each of AP 1302-1 and 1302-2. For example, STA1304-1 can be associated with AP1302-1, and STA1304-2 can be associated with AP1302-2.

[0187] APs 1302-1 and 1302-2 can belong to the same ESS as described above in Figure 1. In such cases, APs 1302-1 and 1302-2 can be connected via DS to support ESS functionality. Furthermore, as part of a coordinated AP set, APs 1302-1 and 1302-2 can be connected via backhaul. Backhaul is used to quickly share information between APs to support coordinated transmission. The information shared is channel status information or data sent to the associated STA. Backhaul can be wired or wireless. Wired backhaul is recommended for high-capacity data transfer without burdening the AP's main radio. However, wired backhaul can have high deployment costs and impose significant constraints on AP placement. Wireless backhaul is recommended due to its lower deployment costs and greater flexibility in AP placement. However, because wireless backhaul relies on the AP's main radio for information transfer, APs cannot send or receive data while using wireless backhaul.

[0188] Typically, one of APs 1302-1 and 1302-2 functions as the master AP, and the other as the slave AP. The master AP is the AP that owns the TXOP. The master AP shares frequency resources with the slave APs during the TXOP. If there are more than two APs in the coordinated set, the master AP can only share its TXOP with a subset of the coordinated AP set. The role of the master AP can change over time. For example, the role of the master AP can be assigned to a specific AP for a certain period. Similarly, the role of the slave APs can be dynamically selected by the master AP or pre-assigned for a certain period.

[0189] Depending on the capabilities of the APs within a coordinated AP set, an AP can perform only a specific type of coordinated transmission. For example, in Figure 13, if AP1302-1 supports JT and CSR, while AP1302-2 supports CSR and CBF, both APs can only perform CSR as the coordinated transmission method. Furthermore, an AP may prioritize performing single-AP transmission for a certain period if the advantages of coordinated transmission do not outweigh some of its disadvantages, such as reduced flexibility or increased computing power requirements.

[0190] CSR is a type of multi-AP coordination that can be supported by AP1301-1 and AP1302-2, as shown in Figure 13. Spatial reuse using CSR is more stable than non-AP coordinated spatial reuse schemes such as Overlap Basic Service Set (OBSS), Packet Detection (PD) based SR, and PSR based SR. For example, in the example of network 1300, AP1302-1 and 1302-2 can perform a joint sounding operation to measure the path loss (PL) on the path in network 1300. For example, this joint sounding operation may yield measurements of PL1308 for the path between AP1302-1 and 1302-2, path loss 1310 for the path between AP1302-1 and STA1304-2, and path loss 1312 for the path between AP1302-2 and STA1304-1. The measured path loss information is shared between AP1302-1 and 1302-2 (e.g., using backhaul) to enable simultaneous transmission by AP1302-1 and 1302-2 to their respective STA1304-1 and 1304-2. Specifically, one of AP1302-1 and 1302-2 acquires the TXOP and becomes the master AP. The master AP can send a CSR announcement frame to the other APs. In an embodiment, the master AP may perform a polling operation to poll the slave APs regarding the availability of packets for transmission before sending the CSR announcement frame. If at least one slave AP responds indicating packet availability, the master AP can proceed to send the CSR announcement frame. In the CSR announcement, the master AP may limit the transmission power of the slave APs to protect its own transmission to its target STA. A slave AP can similarly protect its own transmission to the target STA by selecting a modulation scheme that allows for a sufficiently high signal-to-interference ratio (SIR) margin to support interference from the master AP's transmission to its target STA.

[0191] Figure 14 shows example 1400 of the multi-AP operation procedure. In example 1400, the multi-AP operation procedure is shown for a multi-AP network including APs 1402 and 1404 and STAs 1406 and 1408. In the example, APs 1402 and 1404 can form a multi-AP group. AP 1402 can be the master AP of the multi-AP group, and AP 1404 can be a slave AP. For example, AP 1402 can acquire a TXOP and become the master AP of the multi-AP group. Alternatively, AP 1402 can be designated as the master AP by the multi-AP controller.

[0192] As shown in Figure 14, the multi-AP operation procedure may include a series of time phases, each phase of which may include multiple frame exchanges within the multi-AP network. Specifically, the multi-AP operation procedure may include a multi-AP selection phase 1410, a multi-AP data sharing phase 1412, a multi-AP sounding phase 1414, and a multi-AP data transmission phase 1416.

[0193] A multi-AP network can perform multi-AP operations based on a specific multi-AP transmission scheme. The multi-AP transmission scheme can be selected by the master AP based on the capabilities of the slave APs within the multi-AP group. Before multi-AP operation, a slave AP can notify the master AP of functional information related to the slave AP, such as the ability to support one or more multi-AP transmission schemes. A slave AP can also notify the master AP of BSS information for the slave AP and link quality information for the STA associated with the slave AP. The master AP can receive information related to all available slave APs. This information may include functional information, BSS information, and link quality information. Based on the information provided by the available slave APs, the master AP can determine, during the multi-AP selection phase, which slave APs will be designated for multi-AP transmission and which specific multi-AP transmission scheme will be used during multi-AP transmission.

[0194] The multi-AP selection phase 1410 may include procedures for the master AP to request, select, or designate slave APs for a multi-AP group. As shown in Figure 14, the multi-AP selection phase may include the transmission of frame 618 from AP1402 and frame 1420 from AP1404. AP1402 may send frame 1418 to request information about AP1404's buffer status. In response, AP1404 may send frame 1420 to notify AP1402 of its and its associated STA's buffer status and / or whether it intends to participate in the multi-AP operation. The multi-AP selection phase 1410 may also be used to exchange information related to the multi-AP operation, such as AP BSS information and link quality information between each AP and its associated STA. AP BSS information may include the AP's BSS ID, the identifier and / or function of the STA belonging to the BSS, information about the STA's sounding function, and information about the AP's MIMO function. Link quality information may include the Received Signal Strength Indicator (RSSI), signal-to-noise ratio (SNR), signal-to-interference noise ratio (SINR), channel status information (CSI), and channel quality indicator (CQI).

[0195] The multi-AP data sharing phase 1412 may include a procedure for sharing data frames to be sent to the STA associated with the AP between the master AP and selected slave APs via a direct connection between APs. Phase 1412 may be optional in some multi-AP data transmission schemes. For example, JT / JR may require phase 1412 because data frames may be exchanged between APs before or after the multi-AP data transmission phase 1416.

[0196] The multi-AP data sharing phase 1412 can be performed using a wired backhaul, an in-channel radio backhaul, or an out-of-channel radio backhaul. In some cases, the multi-AP data sharing phase 1412 can be performed via an in-channel backhaul, for example, using the same radio channel used to send and receive data to and from the STA. For example, as shown in Figure 14, in phase 1412, AP 1402 may transmit frame 1422, which can be received by AP 1404. Frame 1422 may contain an MPDU that AP 1402 wishes to send to the relevant STA using the multi-AP operation. Similarly, AP 1404 may transmit frame 1424, which can be received by AP 1402. Frame 1424 may contain an MPDU that AP 1404 wishes to send to the relevant STA using the multi-AP operation.

[0197] The multi-AP sounding phase 1414 may include procedures for multi-AP channel sounding, including channel estimation and feedback of channel estimation between the master AP, candidate slave APs, and associated STAs. Phase 1414 may be optional in some multi-AP transmission schemes such as COFDMA, CDTMA, and CSR. For example, phase 1414 can be performed by the master AP to assist in the allocation of resource units when coordinating COFDMA transmissions.

[0198] The multi-AP data transmission phase 1416 may include the exchange of data frames between the master AP, slave APs, and their associated STAs, based on the multi-AP transmission scheme determined by the master AP. Depending on the multi-AP transmission scheme used, phase 1416 may include optional synchronization between APs in a multi-AP group before the exchange of data frames between APs and STAs within the multi-AP group.

[0199] The order of phases 1410, 1412, 1414, and 1416 may differ from that shown in Figure 14. For example, in COFDMA, phase 1416 can be performed immediately after phase 1410, while in JT / JR, phase 1412 can be performed after phase 1410. Furthermore, as mentioned above, some phases are optional and may or may not be present. For example, phase 1414 is not required for COFDMA but may be required for JT / JR.

[0200] Figure 15 shows an example 1500 of a multi-AP sounding phase. Multi-AP sounding phase 1500 can be an example of multi-AP sounding phase 1414. As shown in Figure 15, example 1500 may include a master AP 1502 and a slave AP 1504 in the multi-AP group. Example 1500 may further include STA 1506 associated with AP 702 and STA 1508 associated with AP 1504.

[0201] As shown in Figure 15, the multi-AP sounding phase 1500 may include frame exchange to enable AP 1502 (master AP) to acquire channel status information (CSI) for channels within the multi-AP group. In an implementation, phase 1500 may include a first subphase 1510 and a second subphase 1512. During the first subphase 1510, the APs initiate channel sounding, and the STAs can estimate the CSI. For example, AP1502 can trigger multi-AP sounding by sending frame 1514 to AP1504 (slave AP). Frame 1514 may contain a multi-AP trigger frame. Subsequently, AP1502 and 1504 can announce the transmission of sounding frames by sending announcement frames 1516-1 and 1516-2 to their respective associated STAs 1506 and 1508, respectively. Frames 1516-1 and 1516-2 may contain Multi-AP Null Data Packet Announcement (NDPA) frames. Frames 1516-1 and 1516-2 can be sent simultaneously. Next, AP1502 and 1504 can send frames 1518-1 and 1518-2 to STAs 1506 and 1508, respectively. Frames 1518-1 and 1518-2 may contain Multi-AP Null Data Packet (NDP) frames. STA1506 and 1508 receive frames 1518-1 and 1518-2, respectively, and perform channel estimation for the channels from AP1502 to STA1506 and from AP1504 to STA1508, respectively.

[0202] During the second subphase 1512, the AP can initiate a procedure for the STA to feed back channel estimates to the AP. For example, AP 1502 sends frame 1520 to trigger STA 1506 and 1508 to send their respective channel estimates to AP 1502 and 1504. Frame 1520 may contain a multi-AP trigger frame. In response, STA 1506 and 1508 may send frames 1522 and 1524, respectively, to AP 1502 and 1504, containing feedback of the channel estimates. Frames 1522 and 1524 may contain NDP feedback frames. The feedback of channel estimates may include NDP feedback, CSI-related information, beamforming reports (BFRs), or channel quality index (CQI) reports.

[0203] Figure 16 shows an example 1600 of the multi-AP downlink data transmission phase. The multi-AP downlink data transmission phase 1600 is an example of the multi-AP data transmission phase 1516. As shown in Figure 16, Example 1600 may include a master AP 1602 and a slave AP 1604 in the multi-AP group. Example 1600 may further include STA 1606 associated with AP 1602 and STA 1608 associated with AP 1604.

[0204] As shown in Figure 16, the multi-AP downlink data transmission phase 1600 may include frame exchange, enabling the master AP 1602 to coordinate with the slave AP 1604 to perform a specific multi-AP transmission scheme with their respective associated STA 1606 and 1608. The multi-AP transmission scheme may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0205] As shown in Figure 16, the master AP1602 can initiate phase 1600 by sending frame 1610 to AP1604. Frame 1610 may include information related to AP1604 (e.g., AP1604 identifier), synchronization information, information related to the specific multi-AP transmission scheme to be used, and / or information related to resource units (RUs) that AP1604 will use to acknowledge frame 1610. Frame 1610 may also include a control frame. For example, frame 1610 may include a multi-AP trigger frame.

[0206] Slave AP1604 receives frame 1610 and can synchronize with master AP1602 using the synchronization information. AP1602 and 1604 can then perform data transmission to their respective associated STA1606 and 1608. Specifically, AP1602 can send data frame 1612 to its associated STA1606, and AP1604 can send data frame 1614 to its associated STA1608. Depending on the multi-AP transmission scheme used, AP1602 and 1604 can send frames 1612 and 1614 to STAs in different BSSs, respectively. For example, if the multi-AP transmission scheme is JT / JR, AP1602 can send frame 1612 to the STA1608 associated with slave AP1604, and AP1604 can send frame 1614 to the STA1608 associated with AP1604. The resources required to send and receive frames 1612 and 1614 may depend on the specific multi-AP transmission scheme employed.

[0207] STA1606 and 1608 can acknowledge frames 1612 and 1614, respectively. For example, STA1606 can send frame 1616 to AP1602, and STA1608 can send frame 1618 to AP1604. Frames 1616 and 1618 can contain block acknowledgment (BA) frames. STA1606 and 1608 can also send frames 1616 and 1618 to APs in different BSSs if required by the multi-AP transmission scheme used. For example, if the multi-AP transmission scheme is JT / JR, STA1606 can send frame 1616 to AP1604, and STA1608 can send frame 1618 to AP1602. The resources required to send and receive frames 1616 and 1618 may depend on the specific multi-AP transmission scheme adopted.

[0208] Figure 17 shows an example 1700 of a multi-AP uplink data transmission phase. Multi-AP uplink data transmission phase 1700 is an example of multi-AP data transmission phase 1516. As shown in Figure 17, Example 1700 may include a master AP 1702 and a slave AP 1704 in a multi-AP group. Example 1700 may further include STA 1706 and 1708 associated with AP 1702, and STA 1710 associated with AP 1704.

[0209] As shown in Figure 17, the multi-AP uplink data transmission phase 1700 may include frame exchange, enabling the master AP 1702 to coordinate with the slave AP 1704 to perform a specific multi-AP transmission scheme with STA 1706, 1708, and 1710. The multi-AP transmission scheme may include COFDMA, CTDMA, CSR, CBF, JT / JR, or a combination of two or more of the aforementioned schemes.

[0210] As shown in Figure 17, the master AP1702 can initiate phase 1700 by sending frame 1712 to AP1704. Frame 1712 may include information related to AP1704 (e.g., AP1704 identifier), synchronization information, information related to the specific multi-AP transmission scheme used, and / or information related to the RU that AP1704 uses to acknowledge frame 1712. Frame 1712 may include a control frame. For example, frame 1712 may include a multi-AP trigger frame.

[0211] Slave AP1704 receives frame 1712 and can synchronize with master AP1702 using the synchronization information. AP1702 and 1704 can then use trigger frames to request uplink data transmission from associated STA1706, 1708, and 1710. Specifically, AP1702 can send trigger frame 1714 to its associated STA1706 and 1708, and AP1704 can send trigger frame 1716 to its associated STA1710. Depending on the multi-AP transmission scheme used, AP1702 and 1704 can also send frames 1714 and 1716 to STAs in different BSSs, respectively. For example, if the multi-AP transmission scheme is JT / JR, AP1702 can send frame 1714 to STA1710 associated with slave AP1704, and AP1704 can send frame 1716 to STA1706 and 1708 associated with AP1702. The resources required to send and receive frames 1714 and 1716 may depend on the specific multi-AP transmission scheme employed.

[0212] STA1706 and 1708 can respond to frame 1714, and STA1710 can respond to frame 1716. For example, STA1706 and 1708 can send frames 1718 and 1720 to AP1702, respectively, while STA1710 can send frame 1722 to AP1704. Frames 1718, 1720, and / or 1722 can be sent simultaneously. Frames 1718, 1720, and 1722 can contain data frames or null data frames. STA 1706, 1708, and 1710 can also send frames 1718, 1720, and 1722 to APs in different BSSs, respectively, if required by the multi-AP transmission scheme used. For example, if the multi-AP transmission scheme is JT / JR, STA1706 and 1708 can also transmit frames 1718 and 1720 respectively to AP1704, and STA1710 can also transmit frame 1722 to AP1702. The resources required to send and receive frames 1718, 1720, and 1722 may depend on the specific multi-AP transmission scheme adopted.

[0213] Figure 18 shows an example 1800 of the multi-AP information exchange phase. The multi-AP information exchange phase 1800 can be an example of the multi-AP information exchange phase 946. As shown in Figure 18, example 1800 can include a master AP 1802 and a slave AP 1812 in a multi-AP group. In one example, AP 1802 and AP 1812 exchange beacon frames in a previous phase (e.g., the multi-AP setup phase 940). AP 1812 can be a candidate slave AP if phase 1800 occurs during the multi-AP setup phase or before AP 1812 is selected or designated as a slave AP in a subsequent multi-AP selection phase (e.g., the multi-AP selection phase 950). In contrast, AP 1812 can be a designated slave AP if phase 1800 occurs (or is repeated) after AP 1812 has been selected or designated as a slave AP in the multi-AP selection phase.

[0214] As shown in Figure 18, Phase 1800 may include subphases 1840 and 1850. In one example, during subphase 1840, AP1802 may send frame 1842 to AP1812 to request BSS information from AP2. Frame 1842 may be a BSS information request frame. In response, AP1812 may send frame 1844 to AP1802 containing AP1812's BSS information. Frame 1844 may be a BSS information response frame.

[0215] In one example, during subphase 1850, AP1802 may send a further frame 1852 to AP1812 to request link quality information from AP1812. In response, AP1812 may send a frame 1854 containing the requested link quality information to AP1802. Frame 1852 may be a link quality information response frame.

[0216] Target Wake Time (TWT), a feature introduced in the IEEE 802.11ah standard, allows STAs to manage activity within the BSS by scheduling STAs to operate at different times to reduce contention. TWT allows STAs to reduce the time required for STAs utilizing power management modes to recover. TWT can be individual TWT or broadcast TWT. Individual TWTs are subject to a TWT agreement negotiated between STAs. Broadcast TWTs are based on a schedule set and are provided to STAs by APs.

[0217] A TWT session can be negotiated between an AP and a STA. A TWT session can define a TWT Service Period (SP) for downlink (DL) and UL traffic between the AP and the STA. Expected traffic may be limited within the negotiated SP. A TWT SP may start at a specific time. A TWT SP can run for the duration of the SP. A TWT SP can be repeated at each SP interval.

[0218] Figure 19 shows an example of TWT operation 1900. TWT operation 1900 includes AP 1902, STA 1904, and STA 1906. AP 1902 and STA 1904 can establish TWT SP 1920. AP 1902 and STA 1906 can establish TWT SP 1922. TWT SP1920 and TWT SP1922 may be repeated as shown in Figure 10, such that TWT SP1920 includes the first TWT SP 1920-1 and the second TWT SP 1920-2, and TWT SP1922 includes the first TWT SP 1922-1 and the second TWT SP 1922-2.

[0219] AP 1902 and STA 1904 can swap frames during the first TWT SP 1920-1. STA 1904 can enter a dozed state at the end of TWT SP 1920-1 and remain dozed until the second TWT SP 1920-2 begins. The start of the second TWT SP 1920-2 can be indicated by a TWT wake interval 1930 associated with TWT SP 1920. AP 1902 and STA 1904 can swap frames again during the second TWT SP 1920-2.

[0220] Similarly, AP 1902 and STA 1906 can swap frames during the first TWT SP 1922-1. STA 1906 can enter a dozed state at the end of the first TWT SP 1922-1 and remain dozed until the start of the second TWT SP 1922-2. The start of the second TWT SP 1922-2 can be indicated by the TWT wake interval 1932 associated with TWT SP 1922. AP 1902 and STA 1906 can again swap frames during the second TWT SP 1922-2.

[0221] In the wake state, the STA can be fully powered. The STA can send and receive frames with the AP or another STA. In the dash state, the STA cannot send or receive frames with the AP or another STA.

[0222] Restricted TWT (R-TWT) operation allows STAs within BSS to use enhanced media access protection and resource reservation mechanisms to deliver latency-sensitive traffic.

[0223] R-TWT membership is established using the same procedure as for setting up broadcast TWT membership, except that the broadcast TWT element transmitted in the TWT setup frame contains one or more Restricted TWT parameter set fields.

[0224] APs scheduling R-TWTs and STAs scheduled for R-TWTs must configure the Restricted TWT traffic information field to identify TIDs that carry delay-sensitive traffic in DL and UL for the R-TWT membership being configured.

[0225] In the Restricted TWT traffic information field, TIDs indicated as delay-sensitive traffic in DL and UL must be within the set of TIDs mapped to links with R-TWT membership configured in DL and UL, respectively. TIDs specified in the Restricted TWT traffic information field of the TWT element in a TWT response indicating acceptance of a TWT are called R-TWT DL TIDs or R-TWT UL TIDs, and are collectively referred to as R-TWT TIDs.

[0226] If an update to the TID-link mapping results in an R-TWT membership where the R-TWT TID is no longer mapped to a link where the R-TWT membership is configured, the corresponding R-TWT membership is considered discarded.

[0227] An STA scheduled for R-TWT can, in accordance with the procedure, notify the AP scheduling the R-TWT of the QoS characteristic elements of the traffic flow intended to be delivered during the R-TWT SP of the R-TWT schedule in the SCS request frame (Stream Classification Service).

[0228] If an AP scheduling an R-TWT receives a QoS characteristic element from a scheduled STA where the R-TWT's TID field and Direction field match in the R-TWT membership configuration, the AP scheduling the R-TWT can use these parameters in the QoS characteristic element as guidance for the R-TWT membership configuration.

[0229] The Stream Classification Service (SCS) is a service provided by APs to STAs that support SCS. In SCS, APs classify incoming, individually addressed MSDUs based on parameters provided by non-AP STAs.

[0230] The SCS procedure requires the AP MLD to classify incoming individually addressed MSDUs based on parameters provided by the non-AP MLD and / or to describe the characteristics of their traffic to the AP MLD.

[0231] The EHT STA establishes an SCS stream with the EHT AP, as defined in the SCS procedure.

[0232] A non-AP EHT STA may send an SCS request frame containing an SCS descriptor element that includes a QoS characteristic element if the frame's request type field is set to "Add" or "Modify". The QoS characteristic element describes the traffic characteristics of the requested SCS stream. A non-AP EHT STA will not send an SCS request frame containing an SCS descriptor element that includes a QoS characteristic element to an AP that has not received an EHT feature element from it where the SCS traffic description support field is equal to 1.

[0233] The MLD maintains SCSIDs at the MLD level. This means that the SCSID used by a non-AP STA belonging to a non-AP MLD in an SCS request frame sent to an AP belonging to an AP MLD is unique among all STAs belonging to the non-AP MLD.

[0234] All STAs belonging to an MLD must set the SCS field of the extension elements they send to the same value. The SCSID is used by non-AP MLDs to request the creation, modification, or deletion of an SCS stream. The SCSID is used by AP MLDs to identify an SCS stream in an SCS response.

[0235] An SCS request frame sent from a non-AP STA belonging to a non-AP MLD to an AP of an AP MLD, which contains a QoS characteristic element with its direction subfield set to uplink or downlink, or an SCS request frame that does not contain a QoS characteristic element, is interpreted as a request to create an SCS stream, which is applied at the MLD level.

[0236] The QoS characteristic element is the basis for scheduling the EHT AP. If the direction subfield of the QoS characteristic element indicates downlink, the EHT AP must schedule the transmission of downlink frames so that the requested delay limits and minimum data rates for downlink data frames are met. The EHT AP must enable the transmission of uplink frames from the EHT STA at intervals between the requested minimum and maximum service intervals, and if the direction subfield of the QoS characteristic element indicates uplink, the AP must meet the requested minimum data rate. The EHT AP must enable the transmission of direct link frames from one EHT STA to another STA on the link specified by the LinkID subfield of the control information field at intervals between the requested minimum and maximum service intervals.

[0237] If an EHT STA is an STA that has scheduled a TWT or an STA that requests a TWT, and there is a TWT SP that has been negotiated for the TID specified in the QoS characteristic element of the EHT AP, the EHT AP must ensure that the service interval matches the negotiated TWT wake interval.

[0238] If an EHT STA is an STA that has scheduled an R-TWT, and there is an R-TWT SP negotiated for the TID specified in the QoS characteristic element, the EHT AP must use these R-TWT SPs to process traffic corresponding to the TID and specified direction in the QoS characteristic element. If the negotiated R-TWT SP for the TID specified in the QoS characteristic element is a trigger-enabled R-TWT, the EHT AP must ensure that the trigger frame is scheduled at the start of the R-TWT SP.

[0239] Figure 20 shows an example of a multi-AP network 2000 supporting MLO. As shown in Figure 20, the example multi-AP network 2000 includes AP2002, AP2004, STA2006, and STA2008. AP2002 and 2004 can form a coordinated AP set. A coordinated AP set can be a subset of an established multi-AP group. AP2002 and AP2004 may include AP MLDs. For example, AP2002 includes coordinated APSTA2002-1 and coordinated APSTA2002-2. For example, AP2004 includes coordinated APSTA2004-1 and coordinated APSTA2004-2.

[0240] At least one STA can be associated with AP 2002 and AP 2004, respectively. For example, STA 2006 can be associated with AP 2002, and STA 2008 can be associated with AP 2004. STA 2006 and STA 2008 can each contain non-AP MLDs. For example, STA 2006 may contain affiliated non-AP STA 2006-1 and affiliated non-AP STA 2006-2. For example, STA 2008 may contain affiliated non-AP STA 2008-1 and affiliated non-AP STA 2008-2.

[0241] For example, an AP MLD or a non-AP MLD can communicate over multiple links (e.g., a first link and a second link). In the 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 distinct from the first link.

[0242] For example, AP STA 2002-1, AP STA 2004-1, non-AP STA 2006-1, and non-AP STA 2008-1 operate on the first link (link 1). For example, non-AP STA 2006-1 is associated with AP STA 2002-1. For example, non-AP STA 2008-1 is associated with AP STA 2004-1. For example, AP STA 2002-2, AP STA 2004-2, non-AP STA 2006-2, and non-AP STA 2008-2 operate on the second link (link 2). For example, non-AP STA 2006-2 is associated with AP STA 2002-2. For example, non-AP STA 2008-2 is associated with AP STA 2008-2.

[0243] In one example, AP2002 and 2004 may belong to the same ESS as described in Figure 1 above. In such a case, AP 2002 and 2004 can be connected via DS to support ESS functionality. Furthermore, AP 2002 and 2004 can be connected via backhaul as part of a coordinated AP set. As shown in Figure 20, the multi-AP network 2000 of the embodiment can connect AP2002 and AP2004 via link 1 and link 2 using wireless backhaul. For example, AP STA 2002-1 and 2004-1 belong to different Basic Service Sets (BSS). In another example, AP STA 2002-2 and 2004-2 belong to different BSSs.

[0244] 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 may originate from a variety of real-time applications with stringent latency requirements (e.g., very low average latency, worst-case latency on the order of milliseconds to tens of milliseconds, and / or small jitter). In operation, LL traffic may be associated with one or more given ACs or one or more traffic identifiers (TIDs) associated with the traffic stream (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.

[0245] Figure 21 shows an example of a multi-AP procedure 2100 in a multilink environment. As shown in Figure 21, the multi-AP procedure 2100 of the embodiment includes AP2102, AP2104, and STA2106. AP 2102 and 2104 can form a coordinated AP set. A coordinated AP set can be a subset of an established multi-AP group. AP 2102 and AP 2104 can constitute an AP MLD. For example, AP 2102 includes associated AP STA 2102-1 and associated AP STA 2102-2. For example, AP 2104 includes associated AP STA 2104-1 and associated AP STA 2104-2. As shown in Figure 21, STA2106 can be associated with AP2102. STA 2106 can constitute a non-AP MLD. For example, STA 2106 includes affiliated non-AP STA 2106-1 and affiliated non-AP STA 2106-2. For example, AP STA 2102-1, AP STA 2104-1, and non-AP STA 2106-1 operate on the first link (link 1). For example, non-AP STA 2106-1 is associated with AP STA 2102-1. For example, AP STA 2102-2, AP STA 2104-2, and non-AP STA 2106-2 operate on the second link (link 2). For example, non-AP STA 2106-2 is associated with AP STA 2102-2.

[0246] In one example, APs 2102 and 2104 may belong to the same ESS as described in Figure 1 above. In such a case, APs 2102 and 2104 can be connected via DS to support ESS functionality. Furthermore, as part of a coordinated AP set, APs 2102 and 2104 can be connected via backhaul. As shown in Figure 21, an example of the multi-AP procedure 2100 can connect APs 2102 and 2104 via link 1 and link 2 using wireless backhaul. For example, AP STA 2102-1 and 2104-1 belong to different BSSs. In another example, AP STA 2102-2 and 2104-2 belong to different BSSs.

[0247] Example 2100 assumes that AP 2102 and STA 2106 have completed multilink configuration. During multilink configuration, AP 2102 can categorize traffic between AP 2102 and STA 2106 into one or more categories based on traffic latency requirements. For example, AP 2102 can categorize traffic between AP 2102 and STA 2106 into Category 1 and Category 2. For example, Category 1 may include low-latency traffic. For example, Category 2 may include non-low-latency traffic. For example, AP 2102 can negotiate a TID-to-link mapping with STA 2106 to assign traffic streams to available links. For example, AP 2102 can prioritize each link based on the traffic category. For example, AP 2102 may prioritize Link 2 over Link 1 for Category 1 traffic. For example, Category 1 traffic streams between AP 2102 and STA 2106 can be mapped to Link 2.

[0248] In one example, as shown in Figure 21, AP2104 can send frame 2112 to AP2102 via link 2 at time T1. Frame 2112 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2104 and AP2102. In another example, STA2106 can receive frame 2112 and set its NAV based on frame 2112. Therefore, when its NAV indicates idle, STA2106 can postpone the transmission of frame 2122, which contains Category 1 traffic, from time T2 to time T3. If Category 1 consists of low-latency traffic, that low-latency traffic may be delayed. In another example, STA2106 does not receive frame 2112 and therefore can send frame 2122 to AP2102 at time T2. Therefore, frame 2122 may collide with or interfere with frame 2112 in AP2102, potentially resulting in the failure to receive one or more frames.

[0249] Embodiments of the present disclosure address the above-mentioned problems of existing multi-AP procedures, as will be further described below. In an embodiment, the first AP can receive a first frame from the second AP indicating the priority of the first link among multiple links for the second AP to communicate first category traffic over the first link. In an embodiment, the first AP can transmit a second frame containing second category traffic over the second link among multiple links, the second link being selected based on the priority. This reduces interference and delay of first category traffic.

[0250] Figure 22 shows an example 2200 of a multi-AP coordination procedure in a multilink environment according to the embodiment. Example 2200 is provided for illustrative purposes only and is not limiting. As shown in Figure 22, Example 2200 includes AP2202, 2204, and STA2206. AP 2202 and / or AP 2204 constitute an AP MLD. STA 2206 may constitute a non-AP MLD. For example, AP 2202 includes associated AP STA 2202-1 and associated AP STA 2202-2. For example, AP 2204 includes associated AP STA 2204-1 and associated AP STA 2204-2. For example, STA 2206 includes associated non-AP STA 2206-1 and associated non-AP STA 2206-2. For example, AP STA 2202-1, AP STA 2204-1, and non-AP STA 2206-1 operate on the first link (link 1). In this example, the first link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. For example, non-AP STA 2206-1 is associated with AP STA 2202-1. For example, AP STA 2202-2, AP STA 2204-2, and non-AP STA 2206-2 operate on the second link (link 2). The second link may include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is distinct from the first link.

[0251] In some embodiments, APs 2202 and 2204 may belong to the same ESS. In such cases, APs 2202 and 2204 can be connected by a DS to support ESS functionality. Furthermore, as part of a coordinated AP set, APs 2202 and 2204 can be connected by backhaul. For example, as shown in Figure 22, APs 2202 and 2204 can be connected by a wireless backhaul including links 1 and 2. In some embodiments, non-AP STA 2206-2 is associated with AP STA 2202-2. In some embodiments, AP STAs 2202-1 and 2204-1 belong to different BSSs. In another example, AP STAs 2202-2 and 2204-2 belong to different BSSs.

[0252] In one embodiment, AP2202 and AP2204 form a multi-AP group. In another embodiment, AP STA 2202-1 and AP STA 2204-1 form a multi-AP group. In yet another embodiment, AP STA 2202-2 and AP STA 2204-2 form a multi-AP group.

[0253] Example 2200 assumes that AP 2202 and STA 2206 have completed multilink configuration. During multilink configuration, AP 2202 can categorize traffic between AP 2202 and STA 2206 into one or more categories based on traffic latency requirements. For example, AP 2202 can categorize traffic between AP 2202 and STA 2206 into Category 1 and Category 2. For example, Category 1 may include low-latency traffic. For example, Category 2 may include non-low-latency traffic. In this embodiment, AP 2202 negotiates a TID-to-link mapping with STA 2206 to assign traffic streams to available links. For example, AP 2202 can prioritize each link based on traffic category. For example, AP 2202 can prioritize Link 2 over Link 1 for Category 1 traffic.

[0254] As shown in Figure 22, Embodiment 2200 can begin with AP2202 transmitting a first frame 2212 to AP2204 at time T0. In this embodiment, the first frame 2212 indicates the priority of link 2 for AP2202 to communicate a first category of traffic over link 2. That is, the priority of link 2 represents the priority of link 2 used by AP2202 to communicate a first category of traffic over link 2. In this embodiment, the first frame 2212 is transmitted over link 1 or link 2. In Embodiment 2200, the first frame 2212 is transmitted over link 1. The first frame 2212 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2202 and AP2204.

[0255] In one embodiment, the priority of link 2 may indicate that AP2202 communicates only Category 1 traffic over link 2. In another embodiment, the priority of link 2 may indicate that AP2202 does not communicate Category 1 traffic over link 2.

[0256] In this embodiment, a first category of traffic stream between AP 2202 and STA 2206 can be mapped to link 2. In this embodiment, the first category includes low-latency traffic.

[0257] In an embodiment, the first frame 2212 may further indicate the priority of link 1 for AP 2202 to communicate Category 1 traffic over link 1. For example, the priority of link 1 may be lower than the priority of link 2. That is, AP 2202 will prioritize using link 2 over using link 1 for AP 2202 to communicate Category 1 traffic.

[0258] In one embodiment, the first frame 2212 may be a management frame. In another embodiment, the management frame may be a beacon frame. In yet another embodiment, the management frame may be an action frame.

[0259] In one embodiment, AP2204 may transmit frame 2214 via link 1 in response to the first frame 2212. In another embodiment, if the first frame 2212 is a beacon frame, AP2204 does not transmit a frame in response to the first frame 2212.

[0260] In this embodiment, AP2204 may have a second category of traffic to transmit to AP2202. The second category may include non-low latency traffic. For example, the second category of traffic may include inter-AP traffic used for coordination between AP2202 and AP2204.

[0261] In one embodiment, AP2204 can select either link 1 or link 2 for transmitting second category traffic. In another embodiment, AP2202 can select either link 1 or link 2 for transmitting second category traffic based on the priority of link 1 and / or link 2 indicated in the first frame 2212. In one embodiment, AP2204 selects link 1 based on the priority of link 2. For example, the priority of link 2 may indicate that link 2 is used by AP 2202 only for first category traffic. In yet another embodiment, AP2204 selects link 1 based on the priority of link 2 and the priority of link 1. In one example, AP 2204 compares the priority of link 2 with the priority of link 1. For example, the priority of link 2 may be higher than the priority of link 1. In this way, AP 2202 can select Link 1 instead of Link 2 to transmit traffic that does not belong to Category 1, such as Category 2 traffic.

[0262] In Example 2200, AP2204 transmits a second frame 2216 containing second category traffic to AP2202 via link 1. As shown in Figure 22, the second frame 2216 may be received by AP2202 at time T1. The second frame 2216 may be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2202 and AP2204. In one example, AP2202 transmits frame 2218 via link 1 in response to the second frame 2216.

[0263] In Example 2200, Category 1 traffic can arrive at STA2206 for transmission to AP2202 around time T1. In this example, if AP2204 selects link 1 to transmit the second frame 2216, STA2206 is enabled to transmit frame 2222, containing Category 1 traffic, to AP2202 via link 2. In this example, STA2206 can transmit frame 2222 to AP2202 via link 2 at time T2, while AP2202 receives frame 2216 from AP2204 via link 1. As a result, Category 1 traffic can be successfully delivered to AP2202 in a more timely manner.

[0264] Figure 23 shows another example 2300 of a multi-AP coordination procedure in a multilink environment according to the embodiment. Example 2300 is provided for illustrative purposes only and is not limiting. As shown in Figure 23, Example 2300 includes AP2302, 2304, and STA2306. AP2302 and / or AP2304 can constitute an AP MLD. STA 2306 can constitute a non-AP MLD. For example, AP 2302 includes associated AP STA 2302-1 and associated AP STA 2302-2. For example, AP 2304 includes associated AP STA 2304-1 and associated AP STA 2304-2. For example, STA 2306 includes associated non-AP STA 2306-1 and associated non-AP STA 2306-2. For example, AP STA 2302-1, AP STA 2304-1, and non-AP STA 2306-1 operate on the first link (Link 1). The first link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. For example, non-AP STA 2306-1 is associated with AP STA 2302-1. For example, AP STA 2302-2, AP STA 2304-2, and non-AP STA 2306-2 operate on the second link (Link 2). The second link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is distinct from the first link.

[0265] For example, APs 2302 and 2304 can belong to the same ESS. In such cases, APs 2302 and 2304 can be connected by a DS to support ESS functionality. Furthermore, as part of a coordinated AP set, APs 2302 and 2304 can be connected by backhaul. For example, as shown in Figure 23, APs 2302 and 2304 can be connected by a wireless backhaul consisting of Link 1 and Link 2. For example, non-AP STA 2306-2 is associated with AP STA 2302-2. For example, AP STA 2302-1 and 2304-1 belong to different BSSs. In another example, AP STA 2302-2 and 2304-2 belong to different BSSs.

[0266] In this embodiment, AP2302 and AP2304 form a multi-AP group. For example, AP STA 2302-1 and AP STA 2304-1 form a multi-AP group. In another example, AP STA 2302-2 and AP STA 2304-2 form a multi-AP group.

[0267] In Example 2300, it is assumed that the AP 2302 and the STA 2306 have completed the multi-link setup. During the multi-link setup, the AP 2302 can classify the traffic between the AP 2302 and the STA 2306 into one or more categories based on the traffic delay requirements. For example, the AP 2302 can classify the traffic between the AP 2302 and the STA 2306 into a first category and a second category. For example, the first category can include low-delay traffic. For example, the second category can include non-low-delay traffic. For example, the AP 2302 negotiates TID-link mapping with the STA 2306 to allocate traffic streams to available links. For example, the AP 2302 can assign priorities to each link based on the category of the traffic. For example, the AP 2302 can prioritize Link 2 over Link 1 for the communication of the traffic in the first category.

[0268] As shown in FIG. 23, Example 2300 can start with the AP 2304 sending the frame 2310 to the AP 2302 via Link 2 and requesting the first frame 2312 from the AP 2302. In one embodiment, the AP 2302 transmits the first frame 2312 to the AP 2304 at time T0 in response to the frame 2310. In the embodiment, the first frame 2312 indicates the priority of Link 2 for communicating the traffic in the first category by the AP 2302 via Link 2. That is, the priority of Link 2 represents the priority of Link 2 used by the AP 2302 for communicating the traffic in the first category via Link 2. In the embodiment, the first frame 2312 is transmitted via Link 1 or Link 2. In Example 2300, the first frame 2312 is transmitted via Link 1. The first frame 2312 can be an inter-AP frame. For example, the inter-AP frame can be used for multi-AP cooperation between the AP 2302 and the AP 2304.

[0269] In an embodiment, the priority of Link 2 can indicate that AP 2302 communicates only traffic of the first category via Link 2. In another embodiment, the priority of Link 2 can indicate that AP 2302 does not communicate traffic of the first category via Link 2.

[0270] For example, a traffic stream of the first category between AP 2302 and STA 2306 can be mapped to Link 2. In an embodiment, the first category includes low-latency traffic.

[0271] In an embodiment, the first frame 2312 can further indicate the priority of Link 1 for AP 2302 to communicate traffic of the first category via Link 1. As an example, the priority of Link 1 may be lower than the priority of Link 2. That is, AP 2302 prefers to use Link 2 over Link 1 for communicating traffic of the first category by AP 2302.

[0272] In an embodiment, the first frame 2312 can be a management frame. In an embodiment, the management frame can be a beacon frame. In another embodiment, the management frame can be an action frame.

[0273] In an embodiment, AP 2304 can transmit a frame 2314 via Link 1 in response to the first frame 2312. In an embodiment, when the first frame 2312 is a beacon frame, AP 2304 does not transmit a frame in response to the first frame 2312.

[0274] In an embodiment, AP2304 may have a second category of traffic to transmit to AP2302. The second category may include non-low latency traffic. For example, the second category of traffic may include inter-AP traffic used for coordination between AP2302 and AP2304.

[0275] In one embodiment, AP2304 can select either Link 1 or Link 2 for transmitting Category 2 traffic. In another embodiment, AP2302 can select either Link 1 or Link 2 for transmitting Category 2 traffic based on the priority of Link 1 and / or Link 2 as indicated in the first frame 2312. In one embodiment, AP2304 selects Link 1 based on the priority of Link 2. For example, the priority of Link 2 may indicate that Link 2 is used by AP 2302 only for Category 1 traffic. In yet another embodiment, AP2304 selects Link 1 based on the priority of Link 2 and the priority of Link 1. For example, AP 2304 compares the priority of Link 2 with the priority of Link 1. For example, the priority of Link 2 may be higher than the priority of Link 1. Thus, AP 2302 can select Link 1 instead of Link 2 to transmit Category 2 traffic and other non-Category 1 traffic.

[0276] In Example 2300, AP2304 transmits a second frame 2316 containing second category traffic to AP2302 via link 1. As shown in Figure 23, the second frame 2316 can be received by AP2302 at time T1. The second frame 2316 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP 2302 and AP 2304. In one example, AP2302 transmits a frame 2318 via link 1 in response to the second frame 2316.

[0277] In Example 2300, Category 1 traffic can arrive at STA2306 for transmission to AP2302 around time T1. In one example, if AP2304 selects link 1 to transmit the second frame 2316, STA2306 can be configured to transmit frame 2322 containing Category 1 traffic to AP2302 via link 2. In one example, STA2306 can transmit frame 2322 to AP2302 via link 2 at time T2, while AP2302 receives frame 2316 from AP2304 via link 1. As a result, Category 1 traffic can be successfully delivered to AP2302 in a more timely manner.

[0278] Figure 24 shows another example 2400 of a multi-AP coordination procedure in a multilink environment according to the embodiment. Example 2400 is provided for illustrative purposes only and is not limiting. As shown in Figure 24, Example 2400 includes AP2402, AP2404, and STA2406. AP2402 and / or AP2404 may include AP MLDs. STA2406 may include non-AP MLDs. For example, AP2402 includes associated AP STA2402-1 and associated AP STA2402-2. For example, AP2404 includes associated AP STA2404-1 and associated AP STA2404-2. For example, STA2406 includes associated non-AP STA2406-1 and associated non-AP STA2406-2. For example, AP STA 2402-1, AP STA 2404-1, and non-AP STA 2406-1 operate on the first link (Link 1). The first link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. For example, non-AP STA 2406-1 is associated with AP STA 2402-1. For example, AP STA 2402-2, AP STA 2404-2, and non-AP STA 2406-2 operate on the second link (Link 2). The second link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is distinct from the first link.

[0279] For example, APs 2402 and 2404 can belong to the same ESS. In such cases, APs 2402 and 2404 can be connected by a DS to support ESS functionality. Furthermore, as part of a coordinated AP set, APs 2402 and 2404 can be connected by backhaul. For example, as shown in Figure 24, APs 2402 and 2404 can be connected by a wireless backhaul consisting of link 1 and link 2. In one example, a non-AP STA 2406-2 is associated with AP STA 2402-2. For example, APs STA 2402-1 and 2404-1 belong to different BSSs. In another example, APs STA 2402-2 and 2404-2 belong to different BSSs.

[0280] In this embodiment, AP2402 and AP2404 form a multi-AP group. For example, AP STA 2402-1 and AP STA 2404-1 form a multi-AP group. In another example, AP STA 2402-2 and AP STA 2404-2 form a multi-AP group.

[0281] Example 2400 assumes that AP 2402 and STA 2406 have completed multilink configuration. During multilink configuration, AP 2402 can categorize traffic between AP 2402 and STA 2406 into one or more categories based on traffic latency requirements. For example, AP 2402 can categorize traffic between AP 2402 and STA 2406 into Category 1 and Category 2. For example, Category 1 may include low-latency traffic. For example, Category 2 may include non-low-latency traffic. For example, AP 2402 can negotiate a TID-to-link mapping with STA 2406 to assign traffic streams to available links. For example, AP 2402 can prioritize each link based on traffic category. For example, AP 2402 can prioritize Link 2 over Link 1 for Category 1 traffic.

[0282] For example, AP 2402 can schedule an R-TWT session with STA 2406 to allow STA 2406 to deliver Category 1 traffic. For example, before the start of Example 2400, AP 2402 and STA 2406 can exchange TWT setup request / response frames to configure R-TWT SP 2442 for TIDs associated with Category 1 traffic.

[0283] As an example, as shown in Figure 24, Embodiment 2400 can be initiated with a Stream Classification Service (SCS) procedure between STA2406 and AP2402. The SCS procedure allows STA2406 to notify AP2402 of QoS characteristic elements for traffic streams to be delivered during the R-TWT SP of the R-TWT schedule. Specifically, STA2406 can send a request frame 2422 to AP2402 via link 2 to notify AP2402 of the first category of traffic streams in STA2406. In one example, frame 2422 may be an SCS request frame. For example, frame 2422 may include QoS characteristic elements indicating R-TWT SP 2442 and a TID for the first category of traffic. In response to frame 2422, AP2402 may send a response frame 2424 accepting the SCS request contained in frame 2422. For example, frame 2424 could be an SCS response frame.

[0284] Next, as shown in Figure 24, AP2402 transmits the first frame 2412 to AP2404 at time T0. In this embodiment, the first frame 2412 indicates the priority of link 2 for AP2402 to communicate category 1 traffic over link 2. That is, the priority of link 2 represents the priority of link 2 used by AP2402 to communicate category 1 traffic over link 2. In this embodiment, the first frame 2412 is transmitted over link 1 or link 2. In embodiment 2400, the first frame 2412 is transmitted over link 1. The first frame 2412 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2402 and AP2404.

[0285] In one embodiment, the priority of link 2 indicates that AP2402 communicates only Category 1 traffic over link 2. In another embodiment, the priority of link 2 indicates that AP2402 does not communicate Category 1 traffic over link 2.

[0286] In one example, a first category of traffic stream between AP 2402 and STA 2406 can be mapped to link 2. In this embodiment, the first category includes low-latency traffic.

[0287] In an embodiment, the first frame 2412 may further indicate the priority of link 1 for AP 2402 to communicate Category 1 traffic over link 1. In one example, the priority of link 1 may be lower than the priority of link 2. That is, AP 2402 will prioritize the use of link 2 over the use of link 1 for AP 2402 to communicate Category 1 traffic.

[0288] In an embodiment, the first frame 2412 further includes a period 2440 for AP2402 to communicate Category 1 traffic over Link 2. As shown in Figure 24, period 2440 can start earlier than R-TWT SP 2442 and end later than R-TWT SP 2442. In one example, period 2440 can be the same as R-TWT SP 2442. For example, period 2440 can be used to protect the transmission of Category 1 traffic over Link 2 between AP2402 and STA2406. For example, by including period 2440 in the first frame 2412, AP2402 can avoid AP2404 using Link 2 to communicate traffic that does not belong to Category 1 during period 2440.

[0289] In an embodiment, the first frame 2412 can be a management frame. In an embodiment, the management frame can be a beacon frame. In another embodiment, the management frame can be an action frame.

[0290] In an embodiment, when the first frame 2412 is a beacon frame, the AP 2404 does not transmit the frame 2414 in response to the first frame 2412.

[0291] In an embodiment, the AP 2404 can have a second category of traffic for transmission to the AP 2402. The second category can include non-low-latency traffic. For example, the traffic of the second category can include inter-AP traffic used for cooperation between the AP 2402 and the AP 2404.

[0292] In an embodiment, AP2404 can select either Link 1 or Link 2 for transmitting Category 2 traffic. In an embodiment, AP2402 can select either Link 1 or Link 2 for transmitting Category 2 traffic based on the priority of Link 1, the priority of Link 2, and / or the period 2440 indicated in the first frame 2412. In an embodiment, AP2404 can select Link 1 based on the priority of Link 2 and the period 2440. For example, the priority of Link 2 and the period 2440 may indicate that the period 2440 on Link 2 is used by AP 2402 only for Category 1 traffic. In another embodiment, AP2404 can select Link 1 based on the priority of Link 2, the priority of Link 1, and the period 2440. In one example, AP2404 can compare the priority of Link 2 with the priority of Link 1 within the period 2440. For example, the priority of Link 2 may be higher than the priority of Link 1 within the period 2440. At that time, AP2402 can choose Link 1 instead of Link 2 within period 2440 to transmit traffic that does not belong to Category 1, such as Category 2 traffic.

[0293] In Example 2400, AP2404 can transmit a second frame 2416 containing second category traffic over link 1 within period 2440. As shown in Figure 24, the second frame 2416 can be received by AP2402 at time T1. The second frame 2416 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP 2402 and AP 2404. In one example, AP2402 can transmit a frame 2418 over link 1 in response to frame 2416.

[0294] In Example 2400, Category 1 traffic can arrive at STA2406 for transmission to AP2402 around time T1. In one example, if AP2404 selects link 1 to transmit a second frame 2416, STA2406 can be configured to transmit frame 2426 containing Category 1 traffic to AP2402 via link 2. In one example, while AP2402 receives frame 2416 from AP2404 via link 1, STA2406 can initiate transmission of frame 2426 to AP2402 via link 2 at time T2. As a result, Category 1 traffic can be delivered to AP2402 successfully and more timely.

[0295] Figure 25 shows another example 2500 of a multi-AP coordination procedure according to the embodiment. Example 2500 is provided for illustrative purposes only and is not limiting. As shown in Figure 25, Example 2500 includes AP2502, AP2504, and STA2506. AP2502 and / or AP2504 may include AP MLDs. STA 2506 may include non-AP MLDs. For example, AP 2502 includes associated AP STA 2502-1 and associated AP STA 2502-2. For example, AP 2504 includes associated AP STA 2504-1 and associated AP STA 2504-2. For example, STA 2506 includes associated non-AP STA 2506-1 and associated non-AP STA 2506-2. For example, AP STA 2502-1, AP STA 2504-1, and non-AP STA 2506-1 operate on the first link (Link 1). The first link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands. For example, non-AP STA 2506-1 is associated with AP STA 2502-1. For example, AP STA 2502-2, AP STA 2504-2, and non-AP STA 2506-2 operate on the second link (Link 2). The second link can include any of the 2.4GHz, 5GHz, 6GHz, or future-defined bands, and the second link is distinct from the first link.

[0296] For example, APs 2502 and 2504 can belong to the same ESS. In such cases, APs 2502 and 2504 can be connected by DS and support ESS functionality. Furthermore, as part of a coordinated AP set, APs 2502 and 2504 can be connected by backhaul. For example, as shown in Figure 25, APs 2502 and 2504 can be connected by a wireless backhaul consisting of link 1 and link 2. For example, non-AP STA 2506-2 is associated with AP STA 2502-2. For example, AP STA 2502-1 and 2504-1 belong to different BSSs. In another example, AP STA 2502-2 and 2504-2 belong to different BSSs.

[0297] In this embodiment, AP2502 and AP2504 form a multi-AP group. For example, AP STA 2502-1 and AP STA 2504-1 form a multi-AP group. In another example, AP STA 2502-2 and AP STA 2504-2 form a multi-AP group.

[0298] In Example 2500, we assume that AP 2502 and STA 2506 have completed multilink configuration. During multilink configuration, AP 2502 can categorize traffic between AP 2502 and STA 2506 into one or more categories based on traffic latency requirements. For example, AP 2502 can categorize traffic between AP 2502 and STA 2506 into Category 1 and Category 2. For example, Category 1 may include low-latency traffic. For example, Category 2 may include non-low-latency traffic. For example, AP 2502 negotiates a TID-to-link mapping with STA 2506 to assign traffic streams to available links. For example, AP 2502 can prioritize each link based on traffic category. For example, AP 2502 may prioritize Link 2 over Link 1 for Category 1 traffic.

[0299] For example, AP 2502 can schedule an R-TWT session with STA 2506 so that STA 2406 can deliver Category 1 traffic. For example, before the start of Example 2500, AP 2502 and STA 2506 can exchange TWT setup request / response frames to configure R-TWT SP 2542 for TIDs associated with Category 1 traffic.

[0300] In one example, as shown in Figure 25, Embodiment 2500 can be initiated with an SCS procedure between STA2506 and AP2502. The SCS procedure allows STA 2506 to notify the QoS characteristic elements of the traffic stream to be delivered during the R-TWT SP of the R-TWT schedule.

[0301] Specifically, STA2506 can send a request frame 2522 to AP2502 via link 2 to notify AP2502 of a Category 1 traffic stream in STA2506. For example, frame 2522 may be an SCS request frame. For example, frame 2522 may include a QoS characteristic element indicating R-TWT SP 2542 and the TID of Category 1 traffic. In response to frame 2522, AP2502 can send a response frame 2524 accepting the SCS request contained in frame 2522. For example, frame 2524 may be an SCS response frame.

[0302] Next, as shown in Figure 25, AP2502 transmits the first frame 2512 to AP2504 at time T0. In this embodiment, the first frame 2512 indicates the priority of link 2 for AP2502 to communicate category 1 traffic over link 2. That is, the priority of link 2 represents the priority of link 2 used by AP2502 to communicate category 1 traffic over link 2. In this embodiment, the first frame 2512 is transmitted over link 1 or link 2. In Example 2500, the first frame 2512 is transmitted over link 1. The first frame 2512 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2502 and AP2504.

[0303] In one embodiment, the priority of link 2 indicates that AP2502 communicates only Category 1 traffic over link 2. In another embodiment, the priority of link 2 indicates that AP2502 does not communicate Category 1 traffic over link 2.

[0304] For example, a first category of traffic stream between AP 2502 and STA 2506 can be mapped to link 2. In this embodiment, the first category includes low-latency traffic.

[0305] In an embodiment, the first frame 2512 may further indicate the priority of link 1 for AP 2502 to communicate Category 1 traffic over link 1. For example, the priority of link 1 may be lower than the priority of link 2. That is, AP 2502 will prioritize the use of link 2 over the use of link 1 for AP 2502 to communicate Category 1 traffic.

[0306] In one embodiment, the first frame 2512 further includes a period 2540 for AP 2502 to communicate Category 1 traffic over Link 2. As shown in Figure 25, period 2540 can start earlier than R-TWT SP 2542 and end later than period R-TWT SP 2542. In one example, period 2540 can be the same as R-TWT SP 2542. For example, period 2540 can be used to protect the transmission of Category 1 traffic over Link 2 between AP 2502 and STA 2506. For example, by including period 2540 in the first frame 2512, AP 2502 can prevent AT 2504 from using Link 2 to communicate traffic that does not belong to Category 1 during period 2540.

[0307] In one embodiment, the first frame 2512 may be a management frame. In another embodiment, the management frame may be a beacon frame. In yet another embodiment, the management frame may be an action frame.

[0308] In this embodiment, if the first frame 2512 is a beacon frame, AP2504 does not transmit frame 2514 in response to the first frame 2512.

[0309] In an embodiment, AP2504 may have a second category of traffic to transmit to AP2502. The second category may include non-low latency traffic. For example, the second category of traffic may include inter-AP traffic used for coordination between AP2502 and AP2504.

[0310] As shown in Figure 25, AP2504 may be busy on link 1 for a period of 2540. In an embodiment, AP2504 can select either link 1 or link 2 for transmitting second category traffic. In an embodiment, AP2502 can select either link 1 or link 2 for transmitting second category traffic based on the priority of link 1, the priority of link 2, and / or the period 2540 shown in the first frame 2512. In an embodiment, AP2504 can select link 2 based on the priority of link 2 and the period 2540. For example, the priority of link 2 and the period 2540 may indicate that the period 2540 on link 2 is used by AP2502 only for first category traffic. In another embodiment, AP2504 can select link 2 based on the priority of link 2, the priority of link 1, and the period 2540. For example, AP2504 can compare the priority of Link 2 to the priority of Link 1 during period 2540. For instance, Link 2's priority may be higher than Link 1's priority during period 2540. For example, AP2504 may be busy on Link 1 during period 2540. Therefore, after period 2540, AP2502 can choose Link 2 instead of Link 1 to send traffic that does not belong to Category 1, such as Category 2 traffic.

[0311] In Example 2500, AP2504 can transmit a second frame 2516 containing second category traffic via link 2 within period 2540. As shown in Figure 25, the second frame 2516 can be received by AP2502 at time T3 after the end of period 2540. Frame 2516 can be an inter-AP frame. For example, an inter-AP frame can be used for multi-AP coordination between AP2502 and AP2504. In one example, AP2502 can transmit frame 2518 via link 2 in response to frame 2516. In another example, AP2502 can transmit frame 2518 via link 1 in response to frame 2516.

[0312] In Example 2500, Category 1 traffic can arrive at STA2506 for transmission to AP2502 around time T1. In one example, if AP2504 selects link 2 to transmit the second frame 2516, STA2506 can be configured to transmit frame 2526 containing Category 1 traffic to AP2502 via link 2. In one example, STA2506 can transmit frame 2526 via link 2 to AP2502 at time T2 before AP2502 receives frame 2516 via link 2 at T3. As a result, Category 1 traffic can be successfully delivered to AP2502 in a more timely manner.

[0313] In one embodiment, the first frame 2212 shown in Figure 22, the first frame 2312 shown in Figure 23, the first frame 2412 shown in Figure 24, and the first frame 2512 shown in Figure 25 can be management frames such as beacon frames.

[0314] Figure 26 shows an example of a beacon frame 2600 that can be used according to an embodiment. For example, the beacon frame 2600 may be an embodiment of frames 2212, 2312, 2412, and 2512. In an embodiment, the beacon frame 2600 may indicate the priority of a first link among multiple links for the AP to communicate a first category of traffic over the first link. The first link may include any of the 2.4GHz band, 5GHz band, 6GHz band, or a future-defined band. In an embodiment, the beacon frame 2600 may further indicate the priority of a second link among multiple links for the AP to communicate a first category of traffic over the second link. 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. In an embodiment, the beacon frame 2600 may further include the period for the AP to communicate a first category of traffic over the first link.

[0315] As shown in Figure 26, the beacon frame 2600 may include a frame control field, a duration field, one or more address fields, a sequence control field, an HT control field, a frame body, and an FCS field. In one embodiment, the frame body may include an element 2602 indicating the priority of the first link. In one example, the element 2602 may include an element identifier (ID) field 2604, a length field 2606, an element ID extension field 2608, and an information field 2610. In another embodiment, the frame body may include further elements, such as element 2602, to indicate the priority of the second link.

[0316] In one example, the information field 2610 may include a link priority subfield 2612 and an optional link duration subfield 2614.

[0317] In one embodiment, the link priority subfield 2612 may include the priority of a first link. In another embodiment, the link priority subfield 2612 may further include the priority of a second link. In one implementation example, the link priority subfield 2612 may include at least one value from a list of priority values. In one implementation example, a high (or low) priority value indicates that the link has a higher priority for communicating Category 1 traffic by the AP. In another implementation example, the link priority subfield 2612 may take a value of 0 or 1, where a value of 1 indicates that the first link is dedicated to communicating Category 1 traffic by the AP.

[0318] In one embodiment, the link duration subfield 2614 may include the period for which the AP communicates Category 1 traffic over the first link. In one implementation example, the link duration subfield 2614 may include the start time and duration of the period. In another implementation, the link duration subfield 2614 may include the start time and end time of the period.

[0319] In one embodiment, the first frame 2212 shown in Figure 22, the first frame 2312 shown in Figure 23, the first frame 2412 shown in Figure 24, and the first frame 2512 shown in Figure 25 can be management frames such as action frames.

[0320] Figure 27 shows an example of an action frame 2700 that can be used in an embodiment. For example, an action frame 2700 can be an embodiment of frames 2212, 2312, 2412, and 2512. In one example, an action frame 2700 can be a public action frame. In an embodiment, an action frame 2700 may include the priority of a first link among a plurality of links for the AP to communicate a first category of traffic over the first link. The first link can include any of the 2.4 GHz band, 5 GHz band, 6 GHz band, or a future-defined band. In an embodiment, an action frame 2700 may further indicate the priority of a second link among a plurality of links for the AP to communicate a first category of traffic over the second link. The second link can include any of the 2.4 GHz band, 5 GHz band, 6 GHz band, or a future-defined band, and the second link is different from the first link. In an embodiment, an action frame 2700 may further include the period for the AP to communicate a first category of traffic over the first link.

[0321] As shown in Figure 27, the action frame 2700 may include an action field 2702. In one embodiment, the action field 2702 may include a category subfield 2704 for indicating the priority of the link. In one example, the action field 2702 may include an action detail field 2706. In one example, the action detail field 2706 may include a link priority subfield 2708 and an optional link duration subfield 2710.

[0322] In one embodiment, the link priority subfield 2708 may include the priority of a first link. In another embodiment, the link priority subfield 2708 may further include the priority of a second link. In one implementation example, the link priority subfield 2708 may include at least one value from a list of priority values. In one implementation example, a high (or low) priority value indicates that the link has a higher priority for AP to communicate Category 1 traffic. In another implementation example, the link priority subfield 2708 may take a value of 0 or 1, where a value of 1 indicates that the first link is dedicated to AP communicating Category 1 traffic.

[0323] In one embodiment, the link duration subfield 2710 may include a period of time during which the AP communicates a first category of traffic over the first link. In another embodiment, the link duration subfield 2710 may include a start time and a duration.

[0324] As those skilled in the art will understand based on the teachings herein, the embodiments described by the above examples can be readily extended to include more than two links.

[0325] As will be understood by those skilled in the art based on the teachings herein, the embodiments described by the above examples can be readily extended to include more than two APs.

[0326] Figure 28 shows an example of process 2800 according to an embodiment. The illustrative process 2800 is provided for illustrative purposes only and is not limited to the embodiment. Process 2800 can be performed by the first AP.

[0327] As shown in Figure 28, process 2800 begins in step 2802, which includes the first AP receiving a first frame from the second AP indicating the priority of the first link among multiple links for the second AP to communicate Category 1 traffic over the first link.

[0328] In an embodiment, receiving a first frame includes receiving the first frame via a first or second link. In an embodiment, the priority of the first link indicates that the second AP communicates only Category 1 traffic via the first link. In an embodiment, the priority of the first link indicates that the second AP does not communicate Category 1 traffic via the first link. In the 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.

[0329] In the embodiment, the first category of traffic streams is mapped to the first link at the second AP. In the embodiment, the first category of traffic includes low-latency traffic. In the embodiment, the first category of traffic includes traffic between the second AP and the first STA associated with the second AP.

[0330] In this embodiment, the first frame further indicates the priority of the second link for the second AP to communicate Category 1 traffic over the second link.

[0331] In this embodiment, the first frame further includes a period for the second AP to communicate the first category of traffic over the first link.

[0332] In the embodiment, the first frame includes a management frame. In the embodiment, the management frame includes a beacon frame that includes an element indicating the priority of the first link. In the embodiment, the management frame includes an action frame that includes an action field indicating the priority of the first link.

[0333] In one embodiment, the first AP further includes sending a third frame requesting a first frame to the second AP.

[0334] In one embodiment, the first AP further includes transmitting a fourth frame to the second AP in response to the first frame.

[0335] In step 2804, process 2800 includes sending a second frame containing Category 2 traffic from the first AP to the second AP via the second link of multiple links, the second link being selected based on the priority of the first link.

[0336] In the embodiment, the transmission of the second frame includes sending the second frame to the second AP or the second STA. In the embodiment, the second category of traffic includes traffic between the first AP and the second AP.

[0337] In this embodiment, the first AP and the second AP form a multi-AP group.

[0338] In the embodiment, the first AP or the second AP includes a multilink device (MLD).

[0339] Figure 29 shows an example of process 2900 according to an embodiment. The example process 2900 is provided for illustrative purposes only and is not intended to limit the embodiments. Process 2900 can be performed by the first AP.

[0340] As shown in Figure 29, process 2900 is initiated in step 2902, which includes sending a first frame from the first AP to the second AP indicating the priority of the first link among multiple links, in order for the first AP to communicate first category traffic over the first link.

[0341] In an embodiment, the transmission of a first frame includes transmitting the first frame over a first link or a second link. In an embodiment, the priority of the first link indicates that the first AP communicates only Category 1 traffic over the first link. In an embodiment, the priority of the first link indicates that the first AP does not communicate Category 1 traffic over the first link. In the example, the first link may include any of the 2.4 GHz band, 5 GHz band, 6 GHz band or a future-defined band. Similarly, the second link may include any of the 2.4 GHz band, 5 GHz band, 6 GHz band or a future-defined band, and the second link is different from the first link.

[0342] In the embodiment, the first category of traffic streams is mapped to the first link in the first AP. In the embodiment, the first category of traffic includes low-latency traffic.

[0343] In this embodiment, the first frame further indicates the priority of the second link for the first AP to communicate Category 1 traffic over the second link.

[0344] In this embodiment, the first frame further includes a period for the first AP to communicate a first category of traffic over the first link.

[0345] In the embodiment, the first frame includes a management frame. In the embodiment, the management frame includes a beacon frame that includes an element indicating the priority of the first link. In the embodiment, the management frame includes an action frame that includes an action field indicating the priority of the first link.

[0346] In one embodiment, the first AP further includes receiving a third frame from the second AP requesting a first frame.

[0347] In one embodiment, the first AP further includes receiving a fourth frame from the second AP in response to a first frame.

[0348] In step 2904, process 2900 includes the first AP receiving a second frame containing second category traffic from the second AP via the second link of multiple links, the second link being selected based on the priority of the first link.

[0349] In the embodiment, receiving a second frame includes receiving a second frame from a first AP. In the embodiment, traffic of the second category includes traffic between the first AP and the second AP.

[0350] In this embodiment, the first AP and the second AP form a multi-AP group.

[0351] In the embodiment, the first AP or the second AP includes a multilink device (MLD).

Claims

1. The first access point (AP) receives a first frame from a second AP, the second AP receiving a first frame indicating the priority of the first link among multiple links for communicating first category traffic via the first link; The first AP selects a second link from among the plurality of links to transmit traffic of the second category to the second AP, based on the priority of the first link. A method comprising the steps of transmitting a second frame containing traffic of a second category from the first AP to the second AP via the second link.

2. The first access point (AP) receives a first frame from a second AP, the second AP receiving a first frame indicating the priority of the first link among multiple links for communicating first category traffic via the first link; A method comprising the steps of: transmitting a second frame containing traffic of a second category via a second link among the plurality of links using the first AP, wherein the second link is selected based on the priority of the first link.

3. The method according to claim 1 or 2, wherein the step of transmitting the second frame includes transmitting the second frame to the second AP or the first STA.

4. The method according to claim 1 or 2, wherein the step of receiving the first frame includes receiving the first frame via the first link or the second link.

5. The method according to claim 1 or 2, wherein the priority of the first link indicates that the second AP communicates only traffic of the first category through the first link.

6. The method according to claim 1 or 2, wherein the priority of the first link indicates that the second AP does not communicate the first category of traffic through the first link.

7. The method according to claim 1 or 2, wherein the traffic stream of the first category is mapped to the first link in the second AP.

8. The method according to claim 1 or 2, wherein the first category of traffic includes low-latency traffic.

9. The method according to claim 1 or 2, wherein the traffic of the first category includes traffic between the second AP and the second STA associated with the second AP.

10. The method according to claim 1 or 2, wherein the traffic of the second category includes traffic between the first AP and the second AP.

11. The method according to claim 1 or 2, wherein the first frame further indicates the priority of the second link for the second AP to communicate the first category of traffic over the second link.

12. The method according to claim 1 or 2, wherein the first frame further includes a period for the second AP to communicate the first category of traffic over the first link.

13. The method according to claim 1 or 2, wherein the first frame includes a management frame.

14. The method according to claim 13, wherein the management frame has a beacon frame that includes an element indicating the priority of the first link.

15. The method according to claim 13, wherein the management frame has an action frame that includes an action field indicating the priority of the first link.

16. The method according to claim 1 or 2, further comprising the step of the first AP transmitting a third frame requesting the first frame to the second AP.

17. The method according to claim 1 or 2, further comprising the step of transmitting a fourth frame from the first AP to the second AP in response to the first frame.

18. The first access point (AP) transmits a first frame to the second AP indicating the priority of the first link among a plurality of links for communicating first category traffic via the first link. A method comprising the steps of: the first AP receiving a second frame containing traffic of a second category from the second AP via a second link among the plurality of links, wherein the second link is selected based on the priority of the first link.

19. The method according to claim 18, wherein the step of receiving the second frame includes receiving the second frame from the first AP.

20. The method according to claim 18 or 19, wherein the step of transmitting the first frame includes transmitting the first frame via the first link or the second link.

21. The method according to claim 18 or 19, wherein the priority of the first link indicates that the first AP communicates only traffic of the first category through the first link.

22. The method according to claim 18 or 19, wherein the priority of the first link indicates that the first AP does not communicate the first category of traffic through the first link.

23. The method according to claim 18 or 19, wherein the traffic stream of the first category is mapped to the first link in the first AP.

24. The method according to claim 18 or 19, wherein the first category of traffic includes low-latency traffic.

25. The method according to claim 18 or 19, wherein the traffic of the first category includes traffic between the first AP and the STA associated with the first AP.

26. The method according to claim 18 or 19, wherein the traffic of the second category includes traffic between the first AP and the second AP.

27. The method according to claim 18 or 19, wherein the first frame further indicates the priority of the second link for the first AP to communicate the first category of traffic over the second link.

28. The method according to claim 18 or 19, wherein the first frame further includes a period for the first AP to communicate the first category of traffic over the first link.

29. The method according to claims 18 to 19, wherein the first frame includes a management frame.

30. The method according to claim 29, wherein the management frame has a beacon frame that includes an element indicating the priority of the first link.

31. The method according to claim 29, wherein the management frame has an action frame that includes an action field indicating the priority of the first link.

32. The method according to claim 18 or 19, further comprising the step of the first AP receiving a third frame requesting the first frame from the second AP.

33. The method according to claim 18 or 19, further comprising the step of the first AP receiving a fourth frame from the second AP in response to the first frame.

34. The method according to any one of claims 1, 2, 18, or 19, wherein the first AP and the second AP form a multi-AP group.

35. The method according to any one of claims 1, 2, 18, or 19, wherein the first AP or the second AP includes a multilink device (MLD).

36. It functions as the primary access point (AP), The second AP receives from the second AP a first frame indicating the priority of the first link among multiple links for communicating Category 1 traffic via the first link, and To transmit a second frame containing traffic of the second category via the second link among the aforementioned multiple links, A device configured to perform an operation including the following, wherein the second link is selected based on the priority of the first link.

37. The device according to claim 36, configured to select the second link for transmission of the second category.

38. The device according to claim 36 or 37, wherein the traffic of the second category is transmitted in a second frame.

39. A system comprising the device and second AP according to claim 36 or 37.

40. A computer program that is executed by a computer and causes the computer to perform the method described in claim 1 or 2.

Images