Link recommendation meeting QoS requirements

Abstract

Methods and apparatus for link recommendations that meet Quality of Service (QoS) requirements. A method of wireless communication performed by an AP associated with an AP MLD, the method comprising: receiving an indication of a QoS requirement from a non-AP MLD; determining whether an existing target wakeup time (TWT) or an existing link is sufficient to meet QoS requirements; if the existing TWT or the existing link is insufficient to meet the QoS requirements, sending a message to the non-AP MLD indicating that an additional TWT service period (SP) needs to be negotiated or an additional enabling link is converted to an active mode or an additional link with the AP MLD is enabled; and if the existing TWT or the existing link is sufficient to meet the QoS requirements, scheduling uplink or downlink resources to meet the QoS requirements.

Description

Technical Field

[0001] This disclosure generally relates to wireless communication systems, and more specifically to methods and apparatus for link recommendation to meet Quality of Service (QoS) requirements. Background Technology

[0002] Wireless Local Area Network (WLAN) technology allows devices to access the Internet in the 2.4 GHz, 5 GHz, 6 GHz, or 60 GHz frequency bands. WLAN is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard. The IEEE 802.11 standard family is designed to improve speed and reliability and extend the operational range of wireless networks. Summary of the Invention

[0003] Technical solution

[0004] Embodiments of this disclosure provide methods and apparatus for recommending links to meet QoS requirements.

[0005] In one embodiment, a method of wireless communication performed by an AP associated with an Access Point (AP) Multilink Device (MLD) includes: receiving an indication of a Quality of Service (QoS) requirement from a non-AP MLD; determining whether an existing Target Wake-Up Time (TWT) or existing link is sufficient to meet the QoS requirement; if the existing TWT or existing link is insufficient to meet the QoS requirement, sending a message to the non-AP MLD indicating that an additional TWT Service Period (SP) needs to be negotiated or that an additional enabled link is switched to active mode or that an additional link with the AP MLD is enabled; and if the existing TWT or existing link is sufficient to meet the QoS requirement, scheduling uplink or downlink resources to meet the QoS requirement.

[0006] In another embodiment, the AP includes a transceiver and a processor operatively coupled to the transceiver. The processor is configured to: receive an indication of QoS requirements from a non-AP MLD; determine whether the existing TWT or existing link is sufficient to meet the QoS requirements; if the existing TWT or existing link is insufficient to meet the QoS requirements, send a message to the non-AP MLD indicating that an additional TWT SP needs to be negotiated or that an additional enabled link should be switched to active mode or that an additional link with the AP MLD should be enabled; and if the existing TWT or existing link is sufficient to meet the QoS requirements, schedule uplink or downlink resources to meet the QoS requirements.

[0007] Other technical features will be apparent to those skilled in the art from the following figures, description and claims.

[0008] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used throughout this patent document. The term “coupled” and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are physically in contact with each other. The terms “transmit,” “receive,” and “communicate,” and their derivatives include both direct and indirect communication. The terms “comprising” and “including,” and their derivatives, mean including but not limited to. The term “or” is inclusive, meaning and / or. The phrase “associated with,” and its derivatives, mean including, being included in, interconnected with, containing, being contained within, connected to or connected to, coupled to or coupled with, capable of communicating with, cooperating with, interleaving, juxtaposing, proximate, bound to or bound to, having, possessing the properties of, having a relationship to or with, etc. The term “controller” means any device, system, or part thereof that controls at least one operation. Such a controller can be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller can be centralized or distributed, whether local or remote. When used with a list of items, the phrase "at least one" means that different combinations of one or more of the listed items can be used, and that only one item from the list may be required. For example, "at least one of A, B, and C" includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C. As used herein, terms such as "first" and "second" or "first" and "second" can be used to simply distinguish one component from another without otherwise limiting the components (e.g., in terms of importance or order). It will be understood that, whether the terms “operably” or “communically” are used or not, if an element (e.g., a first element) is referred to as “combined with another element (e.g., a second element),” “combined to another element (e.g., a second element),” “connected to another element (e.g., a second element),” or “connected to another element (e.g., a second element)”, it means that the element can be directly (e.g., wiredly) connected to the other element, wirelessly connected to the other element, or connected to the other element via a third element.

[0009] As used herein, the term "module" can include units implemented in hardware, software, or firmware, and is used interchangeably with other terms such as "logic," "logic block," "part," or "circuit." A module can be a single integrated component suitable for performing one or more functions, or its smallest unit or part. For example, according to an embodiment, a module can be implemented as an application-specific integrated circuit (ASIC).

[0010] Furthermore, the various functions described below can be implemented or supported by one or more computer programs, each computer program being formed by computer-readable program code and embodied in a computer-readable medium. The terms "application" and "program" refer to one or more computer programs, software components, instruction sets, procedures, functions, objects, classes, instances, associated data, or portions thereof suitable for implementation in appropriate computer-readable program code. The phrase "computer-readable program code" includes any type of computer code, including source code, object code, and executable code. The phrase "computer-readable medium" includes any type of medium accessible by a computer, such as read-only memory (ROM), random access memory (RAM), hard disk drive, optical disc (CD), digital video disc (DVD), or any other type of storage. "Non-transitory" computer-readable media does not include wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media in which data can be permanently stored and media in which data can be stored and later rewritten, such as rewritable optical discs or erasable memory devices.

[0011] Definitions of certain other words and phrases are provided throughout this patent document. Those skilled in the art will understand that, in many cases (if not most), such definitions apply to the prior and future use of the words and phrases defined in this way. Attached Figure Description

[0012] To gain a more complete understanding of this disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein like reference numerals denote like parts:

[0013] Figure 1 Example wireless networks according to various embodiments of this disclosure are shown;

[0014] Figure 2A Example APs according to various embodiments of this disclosure are shown;

[0015] Figure 2B Example STAs are shown according to various embodiments of this disclosure;

[0016] Figure 3 An example frame exchange sequence for Stream Classification Service (SCS) negotiation between a non-AP STA and an AP, according to an embodiment of this disclosure, is shown;

[0017] Figure 4 An example SCS request frame format according to an embodiment of the present disclosure is shown;

[0018] Figure 5 An example SCS response frame format according to an embodiment of the present disclosure is shown;

[0019] Figure 6 An example format of a QoS feature element according to an embodiment of this disclosure is shown;

[0020] Figure 7 An example of multi-link service indication element operation according to an embodiment of this disclosure is shown;

[0021] Figure 8 Examples of enhanced multilink single radio (EMLSR) operation for dual-link non-AP MLDs are shown according to various embodiments of the present disclosure;

[0022] Figure 9 Examples of enhanced multi-link multi-radio (EMLMR) operation for dual-link non-AP MLDs are shown according to various embodiments of the present disclosure;

[0023] Figure 10 Examples of SCS response frames depicting state subfields according to various embodiments of the present disclosure are shown;

[0024] Figure 11 Examples of status code values ​​to be used in an SCS response frame according to various embodiments of the present disclosure are shown;

[0025] Figure 12 Example formats of the link recommendation frame action field according to various embodiments of this disclosure are shown;

[0026] Figure 13 Examples of reason code values ​​corresponding to the purpose of link recommendation according to various embodiments of this disclosure are shown;

[0027] Figure 14 Example formats of action frames for individual addressing for link recommendation according to various embodiments of this disclosure are shown;

[0028] Figure 15 Examples of novel elements for indicating link recommendations for individual addressing are shown according to various embodiments of the present disclosure;

[0029] Figure 16 Another example of an SCS response frame depicting a state subfield according to various embodiments of the present disclosure is shown;

[0030] Figure 17 Another example of a status code value to be used in an SCS response frame according to various embodiments of the present disclosure is shown;

[0031] Figure 18 Another example format of the link recommendation frame action field according to various embodiments of this disclosure is shown;

[0032] Figure 19Another example of a reason code value corresponding to the purpose of link recommendation according to various embodiments of the present disclosure is shown;

[0033] Figure 20 Another example format of an action frame for separate addressing for link recommendation according to various embodiments of this disclosure is shown;

[0034] Figure 21 Another example of a novel element for indicating link recommendations for individual addressing, according to various embodiments of the present disclosure, is shown;

[0035] Figure 22 Exemplary flowcharts according to various embodiments of the present disclosure are shown, illustrating a sequence of steps performed by an AP to recommend that a non-AP MLD use more links or more target wake-up times (TWTs) to meet QoS requirements;

[0036] Figure 23 Example flowcharts illustrating a sequence of steps performed by a STA to meet the QoS requirements of its services, according to various embodiments of this disclosure, are shown.

[0037] Figure 24 This illustrates yet another example format of the link recommendation frame action field according to various embodiments of the present disclosure;

[0038] Figure 25 Another example of a reason code value corresponding to the purpose of link recommendation according to various embodiments of the present disclosure is shown;

[0039] Figure 26 An exemplary format of the action field of a multi-link recommendation request frame according to various embodiments of the present disclosure is shown;

[0040] Figure 27 Examples of EML capability subfields indicating EMLSR support, EMLSR capability, EMLMR support, and EMLMR capability subfields according to various embodiments of this disclosure are shown; and

[0041] Figure 28 A flowchart illustrating an example of a method for wireless communication performed by an access point device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0042] The following discussion Figures 1 to 28 The various embodiments used to describe the principles of this disclosure in this patent document are for illustrative purposes only and should not be construed as limiting the scope of this disclosure in any way. Those skilled in the art will understand that the principles of this disclosure can be implemented in any suitably arranged system or device.

[0043] The following documents and standards are incorporated herein by reference, as if fully set forth herein: [1] IEEE 802.11-2020, “Specifications for Wireless LAN Media Access Control (MAC) and Physical Layer (PHY)”; [2] IEEE P802.11ax / D8.0; [3] IEEE P802.11be / D3.0.

[0044] Figure 1 An example wireless network 100 according to various embodiments of the present disclosure is shown. Figure 1 The embodiment of wireless network 100 shown is for illustrative purposes only. Other embodiments of wireless network 100 can be used without departing from the scope of this disclosure.

[0045] Wireless network 100 includes access points (APs) 101 and 103. APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. AP 101 provides wireless access to network 130 to multiple stations 111-114 within its coverage area 120. APs 101-103 are capable of communicating with each other and with STAs 111-114 using Wi-Fi or other WLAN communication technologies. STAs 111-114 can communicate with each other using peer-to-peer protocols such as Tunneled Direct Link Setup (TDLS).

[0046] Depending on the network type, other well-known terms can be used instead of "access point" or "AP," such as "router" or "gateway." For convenience, the term "AP" is used in this disclosure to refer to a network infrastructure component that provides wireless access to remote terminals. In a WLAN, assuming that the AP also contends for the wireless channel, the AP can also be referred to as a STA. Furthermore, depending on the network type, other well-known terms can be used instead of "station" or "STA," such as "mobile station," "subscriber station," "remote terminal," "user equipment," "wireless terminal," or "user device." For convenience, the terms "station" and "STA" are used in this disclosure to refer to a remote wireless device that wirelessly accesses an AP or contends for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or is generally considered a fixed device (such as a desktop computer, AP, media player, fixed sensor, television, etc.).

[0047] The dashed lines indicate the approximate extent of coverage areas 120 and 125, and are shown as approximately circular for illustrative and explanatory purposes only. It should be clearly understood that coverage areas associated with an AP (such as coverage areas 120 and 125) can have other shapes, including irregular shapes, depending on the AP's configuration and variations in the radio environment associated with natural and man-made obstacles.

[0048] As described in more detail below, one or more of the APs can include circuitry and / or programming to facilitate link recommendations that meet QoS requirements. Although Figure 1 An example of a wireless network 100 is shown, but it is possible to... Figure 1 Various modifications can be made. For example, wireless network 100 can include any number of APs and any number of STAs in any suitable arrangement. Furthermore, AP 101 can communicate directly with any number of STAs and provide them with wireless broadband access to network 130. Similarly, each AP 101-103 can communicate directly with network 130 and provide STAs with direct wireless broadband access to network 130. Additionally, AP 101 and / or 103 can provide access to other or additional external networks, such as external telephone networks or other types of data networks.

[0049] Figure 2A Example AP 101 is shown according to various embodiments of the present disclosure. Figure 2A The embodiment of AP 101 shown is for illustrative purposes only, and Figure 1 AP 103 can have the same or similar configuration. However, APs have a wide variety of configurations, and Figure 2A This disclosure is not intended to limit the scope to any particular implementation of AP.

[0050] AP 101 includes multiple antennas 204a-204n and multiple transceivers 209a-209n. AP 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface 234. Transceivers 209a-209n receive incoming radio frequency (RF) signals from antennas 204a-204n, such as signals transmitted by STAs 111-114 in network 100. Transceivers 209a-209n down-convert the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are processed by receive (RX) processing circuitry in transceivers 209a-209n and / or controller / processor 224, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. Controller / processor 224 is capable of further processing the baseband signals.

[0051] The transmit (TX) processing circuitry in transceivers 209a-209n and / or controller / processor 224 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from controller / processor 224. The TX processing circuitry encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. Transceivers 209a-209n up-convert the baseband or IF signal into an RF signal transmitted via antennas 204a-204n.

[0052] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller / processor 224 may control the transceivers 209a-209n to receive forward channel signals and transmit reverse channel signals according to well-known principles. The controller / processor 224 may also support additional functions, such as more advanced wireless communication functions. For example, the controller / processor 224 may support beamforming or directional routing operations, wherein outgoing signals from multiple antennas 204a-204n are weighted differently to effectively guide outgoing signals to a desired direction. The controller / processor 224 may also support OFDMA operations, wherein outgoing signals are assigned to different subsets of subcarriers for different receivers (e.g., different STAs 111-114). The controller / processor 224 may support any of a wide variety of other functions in the AP 101, including facilitating link recommendation for meeting QoS requirements. In some embodiments, the controller / processor 224 includes at least one microprocessor or microcontroller. The controller / processor 224 is also capable of executing programs and other processes, such as an operating system, residing in the memory 229. The controller / processor 224 is capable of moving data into or out of the memory 229 as needed for the execution process.

[0053] The controller / processor 224 is also coupled to a backhaul or network interface 234. The backhaul or network interface 234 allows the AP 101 to communicate with other devices or systems via a backhaul connection or over a network. Interface 234 is capable of supporting communication via any suitable wired or wireless connection. For example, interface 234 allows the AP 101 to communicate with a larger network (such as the Internet) via a wired or wireless local area network or via a wired or wireless connection. Interface 234 includes any suitable architecture supporting communication via a wired or wireless connection, such as Ethernet or an RF transceiver. Memory 229 is coupled to the controller / processor 224. A portion of memory 229 can include RAM, and another portion of memory 229 can include flash memory or other ROM.

[0054] As described in more detail below, AP 101 can include circuitry and / or programming to facilitate link recommendations for meeting QoS requirements. Although Figure 2A An example of AP 101 is shown, but it is possible to... Figure 2A Various modifications can be made. For example, AP 101 can include any number of... Figure 2A Each component is shown. As a specific example, an access point can include multiple interfaces 234, and the controller / processor 224 can support routing functions to route data between different network addresses. Alternatively, it can include only one antenna and transceiver path, as in a conventional AP. Moreover, Figure 2A The various components can be combined, further subdivided, or omitted, and additional components can be added as needed.

[0055] Figure 2B Example STA 111 is shown according to various embodiments of the present disclosure. Figure 2B The embodiment of STA 111 shown is for illustrative purposes only, and Figure 1 STA 111-115 can have the same or similar configurations. However, STAs appear in a wide variety of configurations, and Figure 2B This disclosure is not intended to limit the scope of any particular implementation of STA.

[0056] STA 111 includes an antenna 205, a transceiver 210, a microphone 220, a speaker 230, a processor 240, an input / output (I / O) interface (IF) 245, an input 250, a display 255, and a memory 260. The memory 260 includes an operating system (OS) 261 and one or more applications 262.

[0057] Transceiver 210 receives incoming RF signals from antenna 205 (e.g., transmitted by AP 101 of network 100). Transceiver 210 down-converts the incoming RF signals to generate intermediate frequency (IF) or baseband signals. The IF or baseband signals are processed by RX processing circuitry in transceiver 210 and / or processor 240, which generates processed baseband signals by filtering, decoding, and / or digitizing the baseband or IF signals. The RX processing circuitry sends the processed baseband signals to speaker 230 (e.g., for voice data) or to processor 240 (e.g., for web browsing data).

[0058] The TX processing circuitry in transceiver 210 and / or processor 240 receives analog or digital voice data from microphone 220 or other outgoing baseband data (such as network data, email, or interactive video game data) from processor 240. The TX processing circuitry encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. Transceiver 210 up-converts the baseband or IF signal into an RF signal transmitted via antenna 205.

[0059] Processor 240 may include one or more processors and execute a basic OS program 261 stored in memory 260 to control the overall operation of STA 111. In one such operation, processor 240 controls transceiver 210 to receive forward channel signals and transmit reverse channel signals according to known principles. Processor 240 may also include processing circuitry configured to facilitate link recommendations for meeting QoS requirements. In some embodiments, processor 240 includes at least one microprocessor or microcontroller.

[0060] Processor 240 is also capable of executing other processes and programs residing in memory 260, such as operations for facilitating link recommendations that meet QoS requirements. Processor 240 is capable of moving data into or out of memory 260 as needed during the execution of the process. In some embodiments, processor 240 is configured to execute multiple applications 262, such as applications for facilitating link recommendations that meet QoS requirements. Processor 240 is capable of operating multiple applications 262 based on OS program 261 or in response to signals received from AP. Processor 240 is also coupled to I / O interface 245, which provides STA 111 with the ability to connect to other devices such as laptops and handheld computers. I / O interface 245 is the communication path between these accessories and processor 240.

[0061] Processor 240 is also coupled to input 250 and display 255, including, for example, a touchscreen, keypad, etc. The operator of STA 111 can use input 250 to input data into STA 111. Display 255 can be a liquid crystal display, a light-emitting diode display, or other display capable of displaying text and / or at least limited graphics (such as from a website). Memory 260 is coupled to processor 240. A portion of memory 260 can include random access memory (RAM), and another portion of memory 260 can include flash memory or other read-only memory (ROM).

[0062] although Figure 2B An example of STA 111 is shown, but it is possible to... Figure 2B Make various changes. For example, Figure 2B The various components can be combined, further subdivided, or omitted, and additional components can be added as needed. In a specific example, STA 111 can include any number of antennas 205 for MIMO communication with AP 101. In another example, STA 111 can exclude voice communication, or processor 240 can be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Furthermore, although Figure 2BThe STA 111 is shown configured as a mobile phone or smartphone, but the STA can be configured to operate as other types of mobile or fixed devices.

[0063] Various embodiments of this disclosure recognize that, upon receiving a QoS request from one or more traffic flows from a non-AP MLD, the AP MLD is able to attempt to satisfy the QoS request requested by the non-AP MLD. In this process, the AP MLD may determine that currently available link resources or negotiated TWT resources are insufficient to satisfy the requested QoS requirement. However, the AP may also determine that the use of additional links or more TWT memberships by the non-AP MLD could help satisfy the QoS requirement.

[0064] Various embodiments of this disclosure recognize that the current IEEE 802.11 specification is unclear on how to address the following issues in EMLSR and EMLMR operating modes: (i) how to individually indicate whether an MLD can perform frame exchange with another MLD operating in EMLSR mode, and whether the MLD itself can operate in EMLSR mode; (ii) how to individually indicate whether an MLD can perform frame exchange with another MLD operating in EMLMR mode, and whether the MLD itself can operate in EMLMR mode; (iii) when an EMLMR STA is performing uplink transmission on one link, another EMLMR STA can simultaneously perform uplink transmission; and (iv) how this affects the EMLMR operation process when an EMLMR STA uses an operating mode notification frame to perform an operating mode change to update bandwidth or NSS.

[0065] Therefore, various embodiments of this disclosure propose a mechanism for an AP MLD to indicate to a non-AP MLD that the currently used link or the negotiated TWT may be insufficient to meet the QoS requirements requested by the non-AP MLD. Mechanisms are also provided to indicate recommended additional or alternative links for meeting the QoS requirements. Furthermore, various embodiments of this disclosure propose a mechanism for an AP attached to an AP MLD to recommend that an STA attached to a non-AP MLD wake up STAs operating on other links to retrieve the BU when the traffic buffer at the AP MLD is large.

[0066] An access point (AP) can have many different types of associated non-AP stations (STAs), each with its own service patterns and service requirements. To meet the different requirements of different service flows of non-AP STAs, the specification [1] also provides a Flow Classification Service (SCS). SCS allows the definition of a rule classifier based on parameters in the protocol header (Layer 2 and / or Layer 3). This classification allows for the selection of UP, discarding of eligible, and Enhanced Distributed Channel Access (EDCA) transmission queues for all Media Access Control Service Data Units that match the classification. Non-AP STAs can request the AP to apply specific QoS processing to downlink IP data flows using the classifier. The AP can use this to classify incoming individually addressed MSDUs. This rule-based classification of different service flows allows packets of one service flow to be prioritized over other flows by enhancing their channel access or allocated resources.

[0067] Figure 3 An example frame exchange sequence for SCS negotiation between a non-AP STA and an AP 300, according to an embodiment of this disclosure, is shown. Figure 3 The example frame exchange sequence shown for SCS negotiation between a non-AP STA and AP 300 is for illustrative purposes only. Other embodiments of the example frame exchange sequence for SCS negotiation between a non-AP STA and AP 300 can be used without departing from the scope of this disclosure.

[0068] The SCS negotiation process includes first, a non-AP STA sending an SCS request frame, and then the corresponding AP sending an SCS response frame. Figure 3 The example illustrates the frame switching process.

[0069] Figure 4 An example SCS request frame format 400 according to an embodiment of the present disclosure is shown. Figure 4 The example SCS request frame format 400 shown is for illustrative purposes only. Other embodiments of the example SCS request frame format 400 can be used without departing from the scope of this disclosure.

[0070] The Access Class Priority element provides information about the relative priority of flows within an AC. The Traffic Classification (TCLAS) element contains a set of parameters necessary to identify the various Protocol Data Units (PDUs) or incoming MSDUs (from higher layers across all STAs or from DSs in the AP) belonging to a specific TS. The TCLAS Processing element, together with the TCLAS element, specifies how the classifier should process the PDUs or MSDUs. The QoS Characteristics element contains a set of parameters defining the characteristics of the traffic flow and QoS expectations.

[0071] Figure 5An example SCS response frame format 500 according to an embodiment of the present disclosure is shown. Figure 5 The example SCS response frame format 500 shown is for illustrative purposes only. Other embodiments of the example SCS response frame format 500 can be used without departing from the scope of this disclosure.

[0072] IEEE 802.11be[3] supports multiple operating frequency bands, in which access points (APs) and non-AP devices can communicate with each other, called links. Therefore, both APs and non-AP devices can communicate on different frequency bands / links, which is called multi-link operation (MLO). Devices capable of performing this MLO are called multi-link devices (MLDs). When associated with an AP MLD on a set of links (called setup links), each such non-AP device is assigned a unique association identifier (AID).

[0073] MLDs can also serve several different types of service categories with varying requirements for throughput, latency, etc. To differentiate services, a Service Identifier (TID) can be assigned to each service category. To prioritize channel access for different TIDs on different links and to limit contention, AP MLDs and non-AP MLDs can negotiate this MLO's TID-to-link mapping. This TID-to-link mapping identifies which TIDs are eligible for transmission / reception on each link. Note that the default TID-to-link mapping allows any TID to be transmitted on any link.

[0074] In order to manage services corresponding to different TIDs within the Basic Service Set (BSS), the 802.11be[3] specification also defines a link recommendation frame. This frame can be sent by an AP attached to an AP MLD to a STA attached to a non-AP MLD to recommend one or more links for the non-AP MLD to use for uplink and downlink data transmission.

[0075] Figure 6 An example format of a QoS feature element 600 according to an embodiment of the present disclosure is shown. Figure 6 The example format of QoS feature element 600 shown is for illustrative purposes only. Other embodiments of the example format of QoS feature element 600 can be used without departing from the scope of this disclosure.

[0076] In order for non-AP MLDs to meet their QoS requirements without relying on the channel contention mechanism of non-APs, the specification [3] also proposes QoS feature elements. By sending QoS feature elements in the SCS request frame, non-AP MLDs can indicate different requirements for their services, such as the periodicity of channel access, minimum service interval, delay limit, average data rate, maximum MSDU size, etc. Figure 5 The document provides a diagram illustrating the format of QoS feature elements. Ultra-High Throughput (EHT) APs attempt to ensure compliance with these QoS features by scheduling downlink transmissions to non-AP MLDs and allocating triggered uplink resources to non-AP MLDs or STAs in active mode during the TWT service cycle (SP). If the direction subfield of a QoS feature element indicates downlink, the EHT AP should schedule downlink frame transmissions to satisfy downlink data frame delay limits and the requested minimum data rate. The EHT AP should enable uplink frame transmission from EHT STAs at intervals falling between the requested minimum and maximum service intervals, and if the direction subfield of a QoS feature element indicates uplink, the AP should satisfy the requested minimum data rate.

[0077] A WiFi station (STA) can be in one of two states:

[0078] 1. Wake-up state - when it continuously monitors the channel and is able to send or receive packets.

[0079] 2. Sleep mode – when it is not monitoring the channel, for example, for power saving purposes.

[0080] Non-AP STAs can be in one of two power management modes:

[0081] 1. Active mode: The STA receives and sends frames at any time. The STA remains in an active state.

[0082] 2. Power Saving (PS) Mode: The STA enters wake-up mode to receive or send frames. Otherwise, the STA remains in sleep mode.

[0083] To allow non-AP devices to conserve power, the specifications [1-3] also support several power-saving methods that determine how a STA behaves when in power-saving (PS) mode and how it transitions between power-saving and active modes. These include Normal Power Saving (PS), Automatic Power Saving Delivery (APSD), Wireless Network Management (WNM) Power Saving, Power Saving Multi-Polling Mode, Spatial Multiplexing PS, Independent BSS (IBSS) Power Saving, Very High Throughput (VHT) Transmit Opportunity (TXOP) Power Saving, Target Wake-Up Time (TWT), etc. During this period, the corresponding AP buffer of the AP MLD addresses the “bufferable packets” of STAs in the non-AP MLD, called Buffer Units (BUs). To indicate such pending BUs to all relevant non-AP devices via broadcast or multicast signaling, each AP in the AP MLD periodically includes a Traffic Information Map (TIM) element in its transmitted beacon frames, and optionally, also as a separate periodic broadcast TIM frame. If there are pending buffer services for non-AP MLDs at an AP MLD, each AP attached to an AP MLD should indicate the pending buffer service for that non-AP MLD by setting the bit corresponding to the AID of the non-AP MLD to 1 in a partial virtual bitmap of the TIM element.

[0084] Because of the use of non-default TID-to-link mapping, none of the BUs can acquire it on any configured link. Therefore, specification [2] also specifies the transmission of a new multi-link service indication element to indicate the links on which the BU can acquire it. If at least one of the associated non-APMLDs has successfully negotiated a TID-to-link mapping, the AP attached to the AP MLD will include the multi-link service indication element in its transmitted beacon frames. The multi-link service indication element includes a per-link service indication bitmap subfield, which corresponds to the AID of the non-AP MLD or STA, starting from bit number k of the service indication virtual bitmap. The order of the per-link service indication bitmap subfield follows the order of the AID bits set to 1 in the partial virtual bitmap subfield of the TIM element. For each such AID set to 1, I bits are reserved in the per-link service indication bitmap, where I is the number of associated links of the APMLD. If a non-AP MLD has a non-default TID-to-link mapping with an AP MLD, then bit position i of the bitmap subfield corresponding to the AID of the non-AP MLD should be set to 1. If the AP MLD has a buffered BU, its TID is mapped to that link or the MMPDU of the non-AP MLD; otherwise, this bit should be set to 0. In the case where a non-AP has a default TID-to-link mapping, if the AP MLD has a buffered BU, then bit position i of the bitmap subfield for each link service indication should be set to 1, and the non-AP MLD should use link i to retrieve the BU, which is recommended.

[0085] exist Figure 7 The baseline indication of link recommendation in the multi-link service indication element is described in the text. Figure 7 An example multi-link service indication element operation 700 according to an embodiment of the present disclosure is shown. Figure 7 The example of multi-link service indication element operation 700 shown is for illustrative purposes only. Other embodiments of the example multi-link service indication element operation 700 can be used without departing from the scope of this disclosure.

[0086] To ensure that the non-AP MLD acquires this BU in a timely manner, the non-AP MLD also negotiates a listening interval with the corresponding AP MLD. If all STAs attached to the non-AP MLD are in power-saving mode, the listening interval field is used to instruct the AP MLD that at least one STA attached to the non-AP MLD should wake up to listen for beacon frames at a specific frequency. By listening to the TIM and Multilink Service Indicator elements in these beacon frames, the non-AP MLD can determine the pending services buffered at the AP MLD. Upon noticing that the bit corresponding to its AID is set to 1 in the TIM element, the non-AP MLD can decode the Multilink Service Indicator element to interpret which link(s) the buffered BU is recommended to acquire. Accordingly, one or more STAs of the non-AP MLD can switch to active mode and send PS polling, Unscheduled Automatic Power Saving Delivery (U-APSD) trigger frames, etc., to acquire the buffered downlink services from the attached AP. When an AP attached to an AP MLD receives a PS-Poll frame or a U-APSD trigger frame from a STA attached to a related non-AP MLD in power-saving mode, it should send the buffered BU to the STA if it is available and has not been dropped for implementation-related reasons; otherwise, it may send a QoS empty frame. After initiating a frame exchange sequence with a STA in power-saving mode to send the BU, the attached AP uses the More Data subfield in the frame control field of the transmitted data frame to indicate to the non-AP STA whether more individually addressed BUs have been buffered for that non-AP MLD. The indicated buffered BUs (excluding the currently transmitting BU) are buffered at the AP MLD of the non-AP MLD and correspond to data frames with a TID mapped to this link or management frames that are not TPC request frames or link measurement request frames. If no such frames are pending, i.e., if the More Data subfield is set to 0, the STA of the non-AP MLD can return to sleep mode after the frame exchange sequence ends.

[0087] For each of its links, the non-AP MLD indicates a set of maximum supported spatial streams (NSS) and modulation and coding schemes (MCS) in the “Supported EHT MCS and NSS Sets” subfield of the EHT Capability element. The supported EHT-MCS and NSS set does more than just determine the number of spatial streams that the MLD can transmit or receive. The 802.11 2020 draft [1] also defines a power-saving mechanism called “operating mode change” for any STA. By using operating mode change, the STA is able to change its operating bandwidth and / or the maximum NSS it can support. Thus, it is able to save power by reducing the bandwidth or the number of spatial streams when needed.

[0088] Figure 8 Examples of EMLSR operation for a dual-link non-AP MLD 800 according to various embodiments of this disclosure are shown. Figure 8 The example embodiment of EMLSR operation for a dual-link non-AP MLD 800 shown is for illustrative purposes only. Other embodiments of the example of EMLSR operation for a dual-link non-AP MLD 800 can be used without departing from the scope of this disclosure.

[0089] In order to improve channel access capability or spectrum efficiency with limited hardware cost and power consumption, IEEE 802.11be also supports an operating mode for non-AP MLD devices called Enhanced Multi-Link Single Radio (EMLSR) mode. In EMLSR mode, the non-AP device behaves like a single radio device, capable of performing channel sensing and basic packet reception on multiple frequency bands / links simultaneously, but only performing reliable data communication on one link at a time. Therefore, by opportunistically selecting the link that wins the channel contention for data communication, EMLSR can improve the system spectrum efficiency. The operation procedure of the EMLSR link is defined in the current 802.11be standard draft [2] and in Figure 8As shown in the diagram. According to this process, the non-AP MLD and AP MLD can declare their ability to support EMLSR operation and corresponding operating parameters in the Enhanced Multilink (EML) Capability subfield of the Basic Variant Multilink Element, which is shared with each other during the association process. If both the AP MLD and non-AP MLD support EMLSR, then to initiate EMLSR operation, the non-AP MLD first sends an EML Operation Mode Notification Frame (EOMNF) to any AP attached to the AP MLD, where the EML Control field of the frame is set to 1. The EOMNF can contain several parameters for EMLSR operation, including the identifier of the link to be considered for EMLSR mode. Within a fixed delay of sending the EOMNF (indicated in the Conversion Timeout subfield of the EML Capability subfield of the Basic Variant Multilink Element), the non-AP MLD should convert to EMLSR mode by converting all STAs associated with the EMLSR to active and listening modes. In this listening mode, the EMLSR non-AP MLD is able to perform channel sensing and basic packet reception. Once an AP MLD wins a transmission opportunity (TXOP) on any link associated with a non-AP MLD EMLSR mode, it can initiate frame exchange with the non-AP MLD by transmitting an initial control frame on that link. Figure 8 In this context, the control frame is a Multi-User Request to Transmit (MU-RTS) frame sent on Link 1. After receiving the initial control frame from the AP MLD on a link, and following a short delay, the non-AP MLD should be able to send and receive data on that link for the duration of the frame exchange sequence. All other EMLSR-enabled links of the non-AP MLD should remain inactive for the duration of the frame exchange sequence (e.g., ...). Figure 8 (Link 2 in the image). At the end of the frame exchange sequence, all EMLSR-enabled STAs outside the AP MLD will switch back to listen mode to win a TXOP for uplink transmission or to seek another initial control frame from the AP MLD. To exit EMLSR operation mode, the non-AP MLD should send an EOMNF with the EML control field set to 0 to the AP MLD. After such an EOMNF is transmitted from the link, the other links outside the non-AP MLD will switch to power-saving mode.

[0090] Figure 9 Examples of EMLMR operation for a dual-link non-AP MLD 900 according to various embodiments of the present disclosure are shown. Figure 9 The example embodiment of EMLMR operation for a dual-link non-AP MLD 900 shown is for illustrative purposes only. Other embodiments of the example of EMLMR operation for a dual-link non-AP MLD 900 can be used without departing from the scope of this disclosure.

[0091] In order to improve the supported MCS and NSS in a timely manner and thus improve spectrum efficiency, IEEE 802.11be also supports an operating mode for non-AP MLD devices called Enhanced Multi-Link Multi-Radio (EMLMR) mode. When a frame exchange sequence with an AP begins on the first link, a non-AP MLD in EMLMR mode is able to move a radio from its other links to the first link to improve the supported MCS and NSS on that link. The set of links that have this ability to move radios to / from the EMLMR non-AP MLD is called an EMLMR link. The operating procedure for a non-AP MLD in EMLMR mode is defined in the current 802.11be standard draft [2] and is Figure 9 As shown in the diagram. According to this process, non-AP MLDs and AP MLDs can declare their ability to support EMLMR operation and the corresponding operating parameters in the Enhanced Multilink (EML) Capability subfield of the Basic Variant Multilink Element, which is shared with each other during the association process. If both the AP MLD and non-AP MLD support EMLMR operation, then to initiate EMLMR operation, the STA of the non-AP MLD first sends an EML Operation Mode Notification Frame (EOMNF) to the corresponding AP attached to the AP MLD, wherein the “EMLMR Mode” bit is set to 1 in the EML Control field of the frame. The EOMNF can contain several parameters for EMLMR operation via the EMLMR Link Bitmap field, including the identifier of the link that can be considered for EMLMR mode. In the EML Control field of the EML Operation Mode Notification Frame (EOMNF), the non-AP MLD also includes a “Set of MCS and NSS Supported by EMLMR” subfield, which (via MCS mapping) indicates the maximum supported combination of MCS and NSS in EMLMR mode for each channel BW, which applies to all EMLMR links. These values ​​are referred to herein as “Enhanced MCS and NSS”. Within a fixed delay for transmitting EOMNF (indicated in the transition timeout subfield of the EML capability subfield of the basic variant multilink element), a non-AP MLD can transition to EMLMR mode by converting all its STAs associated with EMLMR to active and listen modes. In this listen mode, the EMLMR non-AP MLD is able to perform channel sensing and transmit and receive packets on the EMLMR link with basic MCS and NSS. When a Transmit Opportunity (TXOP) is won on any of the EMLMR links associated with the non-AP MLD in EMLMR mode, the AP MLD can initiate frame exchange with the non-AP MLD by transmitting an Initial Frame (IF) with sufficient padding on that link. Figure 9In this context, the IF is a Multi-User Request Transmit (MU-RTS) frame sent on Link 1. After receiving the IF from an AP MLD on a link, a non-AP MLD may be able to transmit and receive data on that link for the duration of the frame exchange sequence under the enhanced MCS and NSS declared in the EOMNF. This is achieved through reception at the enhanced MCS and NSS of other links via the EMLMR non-AP MLD access radio. The padding in the IF is to provide sufficient time for this handover, and this time is disclosed in the EMLMR Delay subfield of the EML Capability field of the Basic Variant Multi-Link Element. At the end of the frame exchange sequence, all EMLMR-enabled STAs of the non-AP MLD can switch back to listening mode to win a TXOP for uplink transmission or to seek another initial control frame from the AP MLD. To exit EMLMR operating mode, the non-AP MLD can send an EOMNF with the EMLMR mode bit set to 0 to the AP MLD.

[0092] Figure 10 Examples of SCS response frames depicting the state subfield 1000 according to various embodiments of the present disclosure are shown. Figure 10 The example embodiment of the SCS response frame depicting the state subfield 1000 shown is for illustrative purposes only. Other embodiments of the example SCS response frame 1000 depicting the state subfield can be used without departing from the scope of this disclosure.

[0093] Figure 11 Examples of status code values ​​to be used in SCS response frame 1100 according to various embodiments of the present disclosure are shown. Figure 11 The example of the status code values ​​shown for use in the SCS response frame 1100 is for illustrative purposes only. Other embodiments of the example 1100 of the status code values ​​to be used in the SCS response frame can be used without departing from the scope of this disclosure.

[0094] It can be assumed that a non-AP MLD can have one or more traffic flows with strict Quality of Service (QoS) requirements. The non-AP MLD can indicate these QoS requirements to the AP MLD, allowing the AP MLD to allocate resources accordingly. These QoS requirements can be indicated by the non-AP MLD using, for example, QoS feature elements or TSPEC elements carried in Flow Classification Service (SCS) request frames.

[0095] In one embodiment, in an SCS request frame sent from a non-AP STA attached to a non-AP MLD to an AP MLD, the non-AP STA can indicate a list of links it is willing to use to satisfy the QoS parameters indicated in the QoS feature element included in the SCS request. This information can be carried in the Link ID bitmap subfield or in the QoS feature element of the SCS request frame.

[0096] In one embodiment, when a QoS request received from a non-AP MLD corresponds to a flow for which the non-AP MLD has negotiated a TWT on one or more links, the AP MLD can use the negotiated TWT SPs to determine whether it can satisfy the requested QoS requirement. If these SPs are insufficient, the AP MLD can indicate one or more of the following:

[0097] - The TWT SP negotiated by the non-AP MLD is insufficient to meet the QoS requirements, therefore the non-AP MLD should consider using more TWT SPs, or the same or other links.

[0098] - A non-AP MLD should set up a set of links with TWT membership on it.

[0099] -AP can also indicate the parameters to be used for the TWT to be set. This can be indicated, for example, by including the TWT element along with the above notification.

[0100] - When a non-AP MLD receives such an indication, it can set additional TWT membership on the recommended links to meet QoS requirements. In a variant, the AP can indicate 0 for some links on which TWTs have already been negotiated to indicate that they may not be required to meet the QoS requirements of the non-AP MLD. In another variant, the AP may also include a TWT element to indicate modifications to existing TWT negotiations required to meet QoS requirements.

[0101] In one example, the AP's indication can be carried in the status subfield of the SCS status list in the SCS response frame, such as... Figure 10 As shown. It is possible to add new status codes to this indication, such as INSUFACIENT_SP_RESOURCES_FOR_QoS, as... Figure 11As shown. Upon receiving this indication in the SCS response frame, a non-AP MLD can also negotiate TWT membership on other links. In a variant of this example, the SCS response frame can have an optional Link ID bitmap subfield to indicate the set of links recommended by the AP to perform additional TWT membership negotiation. This can be carried, for example, within the SCS descriptor element carrying the SCS ID corresponding to the QoS requirements. In a variant of this example, the SCS response frame can have an optional TWT element subfield to indicate the recommended TWT parameters for TWT membership. This can be carried, for example, within the SCS descriptor element carrying the SCS ID corresponding to the SCS.

[0102] Figure 12 An example format of the link recommendation frame action field 1200 according to various embodiments of the present disclosure is shown. Figure 12 The example format of the link recommendation frame action field 1200 shown is for illustrative purposes only. Other embodiments of the example format of the link recommendation frame action field 1200 can be used without departing from the scope of this disclosure.

[0103] Figure 13 Examples of reason code values ​​corresponding to the purpose of link recommendation 1300 according to various embodiments of this disclosure are shown. Figure 13 The example of the reason code value corresponding to the purpose of link recommendation 1300 shown is for illustrative purposes only. Other embodiments of the example of the reason code value corresponding to the purpose of link recommendation 1300 can be used without departing from the scope of this disclosure.

[0104] In another example, the AP indication can be carried in the link recommendation frame sent to a non-AP MLD. In one variation, the indication of the purpose of the recommendation can be carried in the reason code field of the link recommendation frame. In another variation, a separate field called a subtype field can exist to indicate the purpose of the recommendation. For example, the format of the link recommendation frame can be as follows: Figure 12 As shown, and the reason code can be as follows Figure 13 As shown, N is the last allocation reason code value defined in the baseline specification. New reason codes can be defined, such as TWT_NEGOTIATION_FOR_QOS, to indicate that the recommendation is to set new TWT membership for the link to meet QoS requirements. In one variant, the link recommendation frame can also have a session token to identify the SCS request frame corresponding to the recommendation being provided. In another variant, the link recommendation frame can also have a service identifier (TID) or flow ID field to identify the TID or flow corresponding to the recommendation being provided.

[0105] Figure 14Example formats of action frames for separate addressing of Link Recommendation 1400 according to various embodiments of this disclosure are shown. Figure 14 The example format of the action frame for individually addressed link recommendation 1400 shown is for illustrative purposes only. Other embodiments of the example format of the action frame for individually addressed link recommendation 1400 can be used without departing from the scope of this disclosure.

[0106] Figure 15 Examples of new elements for indicating a link recommendation 1500 for individual addressing are shown according to various embodiments of the present disclosure. Figure 15 The example shown for indicating a new element of individually addressed link recommendation 1500 is for illustrative purposes only. Other embodiments of the example for indicating a new element of individually addressed link recommendation 1500 can be used without departing from the scope of this disclosure.

[0107] In another example, it is possible to have a new action frame recommended for a single addressing link. The format could be as follows: Figure 14 As depicted in [the text]. Here, TID or Flow ID can be used to identify the flow or TID for which a negotiated TWT is recommended. Alternatively, an identifier corresponding to the recommended QoS feature element can be provided. The encoding and use of the Reason Code field can be similar to [the text]. Figure 13 In the variant, this can be a vendor-specific action frame.

[0108] In another example, the new element can be used to indicate the individual addressing of a set of recommended links. This element can again have a reason code or subtype subfield to indicate the reason for the recommendation, as explained in the example above. Here, the flow ID can be used to identify the flow for which the recommendation negotiates its TWT. Alternatively, an identifier corresponding to the QoS characteristic element of the recommendation can be provided. The format of this element can be, for example, as shown below. Figure 15 As shown. In one variation, this element can be a variant of the MLO link information element. In another variation, this can be a vendor-specific element.

[0109] Figure 16 Another example of an SCS response frame depicting the state subfield 1600 according to various embodiments of the present disclosure is shown. Figure 16 The example embodiment of the SCS response frame depicting the state subfield 1600 shown is for illustrative purposes only. Other embodiments of the example SCS response frame depicting the state subfield 1600 can be used without departing from the scope of this disclosure.

[0110] Figure 17 Another example of a status code value to be used in SCS response frame 1700 according to various embodiments of this disclosure is shown. Figure 17The example embodiments of the status code values ​​used in the SCS response frame 1700 are for illustrative purposes only. Other embodiments of the example status code values ​​to be used in the SCS response frame 1700 can be used without departing from the scope of this disclosure.

[0111] In one embodiment, if a QoS requirement indicated by a non-AP MLD does not correspond to a TID or traffic flow for which a TWT has already been negotiated by the non-AP MLD, the AP MLD can determine whether it can meet the requested QoS requirement using only the links where the STA is in active mode. If these links are insufficient, the AP MLD can indicate one or more of the following:

[0112] - The non-AP MLD currently has insufficient links in active mode to meet QoS requirements, therefore the non-AP MLD should consider using more links.

[0113] - A group of links on which a non-AP MLD is in power-saving mode should be switched to active mode to meet QoS requirements.

[0114] - A set of disabled links that should be enabled to meet QoS requirements in the non-AP MLD.

[0115] Upon receiving such an indication, a non-AP MLD can either switch the additional STA to active mode or renegotiate the TID-to-link mapping to enable the additional link. In one variant, the AP can indicate 0 for some links that the non-AP MLD is already in active mode, to indicate that they may not need to be in active mode to meet the QoS requirements of the non-AP MLD.

[0116] In one example, the AP's indication can be carried in the status subfield of the SCS status list in the SCS response frame, such as... Figure 16 As shown. It is possible to add new status codes to this indication, such as INSUFACIENT_LINK_RESOURCES_FOR_QoS, as... Figure 17 As shown. Upon receiving this indication in an SCS response frame, a non-AP MLD can either convert the additional link to active mode or enable the additional link. In a variant of this example, the SCS response frame can have an optional link ID bitmap subfield to indicate the set of links the AP recommends converting to active mode. This can be carried, for example, within the SCS descriptor element carrying the SCS ID corresponding to the QoS requirements.

[0117] Figure 18 Another example format of the link recommendation frame action field 1800 according to various embodiments of the present disclosure is shown. Figure 18The example format of the link recommendation frame action field 1800 shown is for illustrative purposes only. Other embodiments of the example format of the link recommendation frame action field 1800 can be used without departing from the scope of this disclosure.

[0118] Figure 19 Another example of a reason code value corresponding to the purpose of Link Recommendation 1900 according to various embodiments of this disclosure is shown. Figure 19 The embodiments shown here, corresponding to the example of the reason code value for the purpose of link recommendation 1900, are for illustrative purposes only. Other embodiments of the example of the reason code value corresponding to the purpose of link recommendation 1900 can be used without departing from the scope of this disclosure.

[0119] In another example, the AP indication can be carried in the link recommendation frame sent to a non-AP MLD. In one variation, the indication of the purpose of the recommendation can be carried in the reason code field of the link recommendation frame. In another variation, a separate field called a subtype field can exist to indicate the purpose of the recommendation. For example, the format of the link recommendation frame can be as follows: Figure 18 As shown, and the reason code can be as follows Figure 19 As shown, N is the last allocated reason code value defined in the baseline specification. New reason codes can be defined, such as WAKE_UP_REQUEST_FOR_QOS, to indicate that the link should be switched to active mode to meet QoS requirements. In one variant, the link recommendation frame can also have a session token to identify the SCS request frame corresponding to the recommendation being provided. In another variant, the link recommendation frame can also have a service identifier (TID) or flow ID field to identify the TID or flow corresponding to the recommendation being provided.

[0120] Figure 20 Another example format of an action frame for separate addressing of Link Recommendation 2000 according to various embodiments of this disclosure is shown. Figure 20 The example format of the action frame for individually addressed Link Recommendation 2000 shown is for illustrative purposes only. Other embodiments of the example format of the action frame for individually addressed Link Recommendation 2000 can be used without departing from the scope of this disclosure.

[0121] In yet another example, a new action frame can be provided for link recommendation used for individual addressing. The format could be as follows: Figure 20 As described in [the document]. The encoding and use of the reason code field can be similar to [the description in the document]. Figure 19 In the variant, this can be a user-specific action frame.

[0122] Figure 21 Another example of a new element for indicating a link recommendation 2100 for individual addressing, according to various embodiments of the present disclosure, is shown. Figure 21 The example shown for indicating a new element of link recommendation 2100 for individual addressing is for illustrative purposes only. Other embodiments of the example for indicating a new element of link recommendation 2100 for individual addressing can be used without departing from the scope of this disclosure.

[0123] In another example, the new element can be used to indicate the individual addressing of a set of recommended links. This element can again have a reason code or subtype subfield to indicate the reason for the recommendation, as explained in the example above. The format of this element can be, for example, as shown below. Figure 21 As shown. In one variation, this element can be a variant of the MLO link information element. In another variation, this can be a vendor-specific element.

[0124] In one embodiment, the indication provided by the AP can be independent of whether a TWT has been negotiated for the traffic flow. The AP MLD can use the negotiated TWT or the links on which the STA is active to determine whether it can meet the requested QoS requirements. If these links are insufficient, the AP MLD can indicate one or more of the following:

[0125] - If a non-AP MLD is currently in active mode, or if a non-AP MLD is an indication that its members' TWT is insufficient to meet QoS requirements, then the non-AP MLD should also consider using more links or TWT.

[0126] - A group of links that are not in power-saving mode by the AP MLD should switch to active mode or negotiate TWT membership to meet QoS requirements.

[0127] - A set of disabled links that should be enabled to meet QoS requirements in the non-AP MLD.

[0128] -AP can also indicate the parameters to be used for the TWT to be set. This can be indicated, for example, by including the TWT element along with the above notification.

[0129] Upon receiving such an indication, a non-AP MLD may switch the additional STA to active mode, renegotiate the TID-to-link mapping to enable the additional link, or set additional TWT membership on the indicated link. In one variant, the AP can indicate certain links where the non-AP MLD is already in active mode or where the TWT negotiation is 0, to indicate that they may not need to meet the non-AP MLD's QoS requirements. In another variant, the AP may also include a TWT element to indicate modifications to the existing TWT negotiation required to meet the QoS requirements.

[0130] In one example, the AP's indication can be carried in the status subfield of the SCS status list in the SCS response frame. New status codes, such as INSUFACIENT_RESOURCES_FOR_QoS, can be added to this indication. Upon receiving this indication in the SCS response frame, the non-AP MLD can either transition the additional link to active mode, make the additional link an enabled link, or negotiate additional TWT membership. In a variant of this example, the SCS response frame can have an optional link ID bitmap subfield to indicate the set of links recommended by the AP for transitioning to active mode or setting additional TWTs. This can be carried, for example, within the SCS descriptor element carrying the SCS ID corresponding to the QoS requirements. In a variant of this example, the SCS response frame may have an optional TWT element subfield to indicate the TWT parameters recommended for TWT membership. This can be carried, for example, within the SCS descriptor element carrying the SCS ID corresponding to the QoS requirements.

[0131] In another example, the AP's indication can be carried in the link recommendation frame transmitted to a non-AP MLD. In one variation, the indication of the purpose of the recommendation can be carried in the reason code field of the link recommendation frame. In another variation, a separate field called a subtype field can exist to indicate the purpose of the recommendation. For example, a new reason code, such as LINK_RECOMMENDATION_FOR_QOS, can be defined to indicate whether the recommendation is to switch the link to active mode or for TWT negotiation to meet QoS requirements. In one variation, the link recommendation frame can also have a session token to identify the SCS request frame corresponding to the recommendation being provided. In another variation, the link recommendation frame can also have a service identifier (TID) or flow ID field to identify the TID or flow corresponding to the recommendation being provided. Similarly, one or more of the other instances described herein can also be applied to this embodiment.

[0132] In one embodiment, when QoS requirements no longer exist, the AP MLD can provide an indication to the non-AP MLD that it is no longer necessary to keep some STAs in active mode or retain membership in a specific TWT. In a variant, this indication can be carried in an explicit frame sent by an AP attached to the AP MLD to STAs attached to the non-AP MLD. In another example, the indication can be implicit and can occur when SCS negotiation is terminated by either the AP MLD or the non-AP MLD. Upon receiving this indication, the non-AP MLD can disable some STAs, put some of its STAs into a dormant state, or terminate the membership of some TWTs.

[0133] Figure 22An exemplary flowchart 2200 is shown, illustrating a sequence of steps performed by an AP according to various embodiments of this disclosure to recommend that a non-AP MLD use more links or more TWTs to meet QoS requirements. Figure 22 The exemplary flowchart 2200 shown, illustrating a sequence of steps performed by an AP to recommend that a non-AP MLD use more links or more TWTs to meet QoS requirements, is for illustrative purposes only. Other embodiments of the example flowchart 2200, which illustrates a sequence of steps performed by an AP to recommend that a non-AP MLD use more links or more TWTs to meet QoS requirements, can be used without departing from the scope of this disclosure.

[0134] like Figure 22 As shown, the method begins at step 2202, where the AP receives an indication of a QoS requirement from a non-AP MLD. At step 2204, the AP determines whether the existing TWT or existing links are sufficient to meet the QoS requirement. If the existing TWT or existing links are sufficient to meet the QoS requirement, then at step 2206, the AP schedules DL / UL resources to meet the indicated QoS requirement. Subsequently, at step 2208, when the QoS requirement ends, the AP provides an AP-recommended termination (if applicable). If, at step 2206, the existing TWT or existing links are insufficient to meet the QoS requirement, then at step 2210, the AP sends a response to the non-AP STA indicating the need to negotiate more TWT SPs or to convert more links to active mode. The method then proceeds to steps 2206 and 2208 as described above.

[0135] Figure 23 Example flowchart 2300 is shown, illustrating a sequence of steps performed by a STA to meet the QoS requirements of its services according to various embodiments of this disclosure. Figure 23 The example flowchart 2300 shown, illustrating a sequence of steps performed by an STA to meet the QoS requirements of its services, is for illustrative purposes only. Other embodiments of the example flowchart 2300, which illustrates a sequence of steps performed by an STA to meet the QoS requirements of its services, can be used without departing from the scope of this disclosure.

[0136] like Figure 23 As shown, the method begins at step 2302, where the STA sends a QoS request to the AP to meet traffic flow requirements. At step 2304, upon receiving a response from the AP indicating insufficient current SPs or links, the STA acts accordingly (e.g., negotiating more TWT SPs or converting more links to active mode). At step 2306, the STA provides an indication to end the QoS request. At step 2308, upon receiving an indication from the AP recommending termination, the STA (if applicable) takes appropriate action, such as transitioning to a dormant state or being able to terminate some TWT memberships.

[0137] Figure 24 Another example format of the link recommendation frame action field 2400 according to various embodiments of the present disclosure is shown. Figure 24 The example format of the link recommendation frame action field 2400 shown is for illustrative purposes only. Other embodiments of the example format of the link recommendation frame action field 2400 can be used without departing from the scope of this disclosure.

[0138] Figure 25 This illustrates yet another example of a cause code value corresponding to the purpose of link recommendation 2500, according to various embodiments of this disclosure. Figure 25 The example embodiment of the reason code value corresponding to the purpose of link recommendation 2500 shown is for illustrative purposes only. Other embodiments of the example reason code value corresponding to the purpose of link recommendation 2500 can be used without departing from the scope of this disclosure.

[0139] Status codes for link recommendation frames:

[0140] In one embodiment, an AP attached to an AP MLD can send link recommendation frames to one or more associated non-AP MLDs to recommend:

[0141] - A set of links used for uplink and downlink transmission for load balancing purposes.

[0142] - A set of links to be used for retrieving buffered traffic at AP MLD.

[0143] - A set of links to be used for group-addressed frame reception.

[0144] - A set of links to be used for target wake-up time negotiation.

[0145] - A set of links, etc., to be used for EMLSR / EMLMR operations.

[0146] In one embodiment, the indication of the purpose of the recommendation can be carried in the reason code field of the link recommendation frame. In another embodiment, a separate field called a subtype field can exist to indicate the purpose of the recommendation. For example, the format of the link recommendation frame can be as follows: Figure 24 As shown, and the status code can be as follows Figure 25 As shown, N is the last assigned reason code value defined in the baseline specification.

[0147] In one embodiment, a non-AP MLD can behave differently based on the indicated recommendation reason code. For example, in one embodiment, upon receiving the status code LOAD_BALANCING_UL_DL, any STA associated with a non-AP MLD operating on one of the recommended links can be used to send frames to or receive frames from the AP MLD. This avoids performing frame switching on links not indicated in the recommended link set. In another example, upon receiving the status code TRAFFIC_BUFFER_RETRIEVAL, all STAs attached to a recommended non-AP MLD can transition to a wake-up state by sending a PS polling or U-APSD trigger frame to the corresponding AP of the AP MLD.

[0148] Multi-link service indication elements:

[0149] In one embodiment, if (i) a non-AP MLD in default mapping mode or (ii) a non-default mapping with all TIDs mapped to the same link set detects that the bit corresponding to its AID is equal to 1 in the TIM element, and the Multi-Link Traffic Indicator (MLTI) element is present in the beacon frame, and the MLTI element includes a per-link traffic indicator bitmap n subfield corresponding to the non-AP MLD, then the non-AP MLD can operate as follows:

[0150] - If all bits of the per-link traffic indicator bitmap n subfield are set to 0, all non-AP STAs attached to the non-AP MLD operating on the enabled link are able to issue PS polling frames, or if the STA is using U-APSD and all ACs are delivery enabled, issue U-APSD trigger frames to retrieve the buffered BU from the AP MLD.

[0151] - If not all bits of the per-link traffic indication bitmap n subfield are set to 0, any non-AP STA attached to the non-AP MLD operating on the link indicated as 1 in the per-link traffic indication bitmap n subfield can issue a PS polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, issue a U-APSD trigger frame to retrieve the buffered BU from the AP MLD.

[0152] In another embodiment, if a non-AP MLD in the default mapping mode detects that the bit corresponding to its AID is equal to 1 in the TIM element, and a multi-link service indication element exists in the beacon frame, and the multi-link service indication element includes a per-link service indication bitmap n subfield corresponding to the non-AP MLD, then the non-AP MLD can operate as follows:

[0153] - If all bits of the per-link traffic indicator bitmap n subfield are set to 1, then all non-AP STAs attached to the non-AP MLD operating on the enabled link are able to issue PS polling frames, or if the STA is using U-APSD and all ACs are delivery enabled, issue U-APSD trigger frames to retrieve the buffered BU from the AP MLD.

[0154] - If all bits of the per-link traffic indicator bitmap n subfield are set to 0, any non-AP STA attached to a non-AP MLD and operating on an enabled link is able to issue a PS polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, issue a U-APSD trigger frame to retrieve the buffered BU from the AP MLD.

[0155] - If not all bits of the per-link traffic indication bitmap n subfield are set to 0, and not all bits of the per-link traffic indication bitmap n subfield are set to 1, then any non-AP STA attached to the non-AP MLD operating on the link indicated as 1 in the per-link traffic indication bitmap n subfield can issue a PS polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, issue a U-APSD trigger frame to retrieve the buffered BU from the AP MLD.

[0156] In a variant of this embodiment, if not all bits of the per-link traffic indication bitmap n subfield are set to 0, and not all bits of the per-link traffic indication bitmap n subfield are set to 1, then a non-AP STA attached to a non-AP MLD operating on a link indicated as 1 in the per-link traffic indication bitmap n subfield can issue a PS polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, then a U-APSD trigger frame is issued to retrieve the buffered BU from the AP MLD.

[0157] In one embodiment, if a non-AP MLD with a non-default mapping mode (where not all TIDs are mapped to the same set of links) detects that the bit corresponding to its AID is equal to 1 in the TIM element, and a multi-link traffic indication element exists in the beacon frame, and the multi-link traffic indication element includes a per-link traffic indication bitmap n subfield corresponding to the non-AP MLD, then the non-AP MLD can operate as follows:

[0158] - If all bits of the per-link traffic indicator bitmap n subfield are set to 0, any non-AP STA associated with a non-AP MLD operating on an enabled link can issue a PS polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, issue a U-APSD trigger frame to retrieve the buffered BU from the AP MLD.

[0159] - If not all bits of the per-link traffic indication bitmap n subfield are set to 0, a non-AP STA attached to a non-AP MLD operating on a link that is indicated as 1 in the per-link traffic indication bitmap n subfield can issue a PSn polling frame, or if the STA is using U-APSD and all ACs are delivery enabled, issue a U-APSD trigger frame to retrieve the buffered BU from the AP MLD.

[0160] In one embodiment, the AP MLD can take the above rules into account when creating a multi-link service indication element.

[0161] Figure 26 An exemplary format of the multilink recommendation request frame action field 2600 according to various embodiments of the present disclosure is shown. Figure 26 The example format of the multi-link recommendation request frame action field 2600 shown is for illustrative purposes only. Other embodiments of the exemplary format of the multi-link recommendation request frame action field 2600 may be used without departing from the scope of this disclosure.

[0162] In one embodiment, a non-AP MLD can send a frame to the AP MLD instructing rules to determine if the number of BUs at the AP MLD is too large, thus requiring multiple STAs at the non-AP MLD to retrieve BIs. The AP MLD can then apply these rules when constructing link recommendations in the MLTI elements. This frame can be, for example, a new EHT action frame called a Multi-Link Recommendation Request Frame. The frame can contain one or more of the following:

[0163] - Indicators for non-AP MLDs regarding whether they want to use multi-link wake-up requests for BU retrieval.

[0164] - An indication of a threshold for buffer size; if this threshold is exceeded, it should be recommended that all links transition to a wake-up state.

[0165] - An indication of a threshold for Head-of-Line Delay (HoLD), exceeding which multiple links should be recommended to transition to a wake-up state.

[0166] - An indication of the TID or access category corresponding to the indicated buffer size and / or retention threshold.

[0167] - Buffer status report control field, which indicates the buffer size threshold based on each TID or each access category.

[0168] - The Business Classification (TCLAS) element indicates that the stream should be considered as a multi-link retrieval recommendation.

[0169] - Frame classifier elements, indicating which flows should be considered for multi-link wake-up recommendations, etc.

[0170] - An indication of parameters used to combine the buffer size and holding area corresponding to the different access categories indicated.

[0171] - A bitmap of link IDs indicating candidate links to be considered when making recommendations.

[0172] exist Figure 26 The example illustration depicts this EHT action frame.

[0173] Figure 27 Examples of EML capability subfields that respectively indicate EMLSR support, EMLSR capability, EMLMR support, and EMLMR capability subfields 2700 according to various embodiments of the present disclosure are shown. Figure 27 The examples of EML capability subfields indicating EML support, EML capability, EMLMR support, and EMLMR capability subfields 2700 are provided for illustrative purposes only. Other embodiments of the examples indicating EML capability subfields 2700 are possible without departing from the scope of this disclosure.

[0174] Indications for EMLSR support, EMLSR capability, EMLMR support, and EMLMR capability:

[0175] In one embodiment, the EML capability subfield transmitted in the common information field of the basic multi-link element sent by the STA can contain two subfields: EMLSR support and EMLSR capability, each subfield being one bit. The format of the EML capability subfield can be, for example, as follows: Figure 27 As described herein. These instructions can have the following meanings:

[0176] - An STA attached to an MLD can set the EML Capability field's EML Support subfield to 1 to indicate that it can perform frame exchange with an STA attached to another MLD operating in EMLSR mode. Otherwise, the STA can set the EML Support subfield to 0.

[0177] - A STA attached to an MLD can set the EML capability field's EML capability subfield to 1 to indicate that the MLD can operate in EML mode. Otherwise, the STA can set the EML capability subfield to 0.

[0178] In a variant of this embodiment, the EML function subfield in the EML function field of the STA transmission attached to the MLD can be set to 1 only if the MLD is capable of operating in EMLSR mode and the transmitting STA is operating on one of the EMLSR links.

[0179] In one embodiment, the EML capability subfield transmitted in the common information field of the basic multi-link element sent by the STA can contain two subfields: EMLMR support and EMLMR capability, each subfield being one bit. The format of the EML capability subfield can be, for example, as follows: Figure 27 As described herein. These instructions can have the following meanings:

[0180] - A STA attached to an MLD can set the EMLMR Support subfield of the EML Capability field to 1 to indicate that it can perform frame exchange with a STA attached to another MLD operating in EMLMR mode. Otherwise, the STA can set the EMLMR Support subfield to 0.

[0181] - A STA attached to an MLD can set the EMLMR capability subfield of the EML capability field to 1 to indicate that the MLD can operate in EMLMR mode. Otherwise, the STA can set the EMLMR capability subfield to 0.

[0182] In a variant of this embodiment, the EMLMR function subfield in the EML function field sent by the STA attached to the MLD can be set to 1 only if the MLD is capable of operating in EMLMR mode and the transmitting STA is operating on one of the EMLMR links.

[0183] Uplink transmissions from two EMLMR STAs:

[0184] In one embodiment, if a first EMLMR STA attached to an MLD operating in EMLMR mode initiates a frame exchange sequence with another STA attached to another device as the owner of a TXOP, then other EMLMR STAs in the MLD should not initiate frame exchanges during the duration of that TXOP. In another embodiment, other EMLMR STAs should not initiate frame exchanges if the first EMLMR STA's transmissions in the TXOP satisfy one or more of the following conditions:

[0185] - A transmission request is made to receive a frame from a STA on another device within the same TXOP. Examples of such transmissions include: PS polling frames, QoS empty frames, and U-APSD trigger frames.

[0186] - A transmission request is received from the STA of another device that can send a frame in high MCS or NSS, as indicated in the EMLMR MCS and NSS mapping of the EML operation mode notification frame sent to switch to EMLMR mode.

[0187] - Transfers and TXOPs are shorter than a certain threshold.

[0188] In one embodiment, if it is determined during a TXOP initiated by a first EMLMR STA operating in EMLMR mode that another EMLMR STA is permitted to initiate a frame exchange, then the frame exchange initiated by the other EMLMR STA can satisfy one or more of the following rules:

[0189] - The initiated frame exchange can be performed without requesting the reception of uplink frames. Examples of such restricted frames include PS polling frames, QoS empty frames, U-APSD frames, etc.

[0190] - The frame exchange of another EMLMR STA can end before the end of the TXOP on the first EMLMR link, or it can be aligned with the end time of the TXOP initiated by the first EMLMR STA.

[0191] In one embodiment, if an EMLMR STA attached to a first MLD operating in EMLMR mode sends a frame to a STA attached to another MLD that is a TXOP holder, then that other MLD is able to refrain from sending frames to the first MLD on any other EMLMR link for the duration of the TXOP.

[0192] The impact of operating mode notifications and operating mode indications on EMLMR operations:

[0193] In one embodiment, an EMLMR STA attached to an MLD operating in EMLMR mode can change its Spatial Stream Quantity (NSS) without sending an Operation Mode Notification Frame or Operation Mode Control Field. In another embodiment, if an STA attached to an MLD operating in EMLMR mode sends an Operation Mode Notification Frame or Operation Mode Control Field to update its NSS, the updated Rx NSS and Tx NSTS values ​​are applicable to any frame exchanged between the serving AP or any peer STA and the STA. In yet another embodiment, if an STA attached to an MLD operating in EMLMR mode sends an Operation Mode Notification Frame or Operation Mode Control Field to update its NSS, the updated Rx NSS and Tx NSTS values ​​are applicable only to the initial frame exchanged with / by the STA, but may not apply to subsequent frames exchanged. They are also applicable to frames exchanged after the MLD exits EMLMR mode.

[0194] In one embodiment, an EMLMR STA attached to an MLD operating in EMLMR mode can change its channel width without sending an operation mode notification frame or operation mode control field. In another embodiment, if an STA attached to an MLD operating in EMLMR mode sends an operation mode notification frame or operation mode control field to update the channel width, the updated channel width is applicable to any frame exchanged between the serving AP or any peer STA and the STA. In yet another embodiment, if an STA attached to an MLD operating in EMLMR mode sends an operation mode notification frame or operation mode control field to update the channel width, the updated channel width value is applicable only to the initial frame exchanged with / by the STA, but may not apply to subsequent frames exchanged. They are also applicable to frames exchanged after the MLD exits EMLMR mode.

[0195] Figure 28 A flowchart of a method 2800 for wireless communication performed by an AP device according to an embodiment of the present disclosure is shown. Figure 28 The example method 2800 shown is for illustrative purposes only. Other embodiments of example method 2800 can be used without departing from the scope of this disclosure.

[0196] like Figure 28As shown, method 2800 begins at step 2802, where the AP device receives an indication of QoS requirements from a non-AP MLD. In step 2804, the AP device determines whether the existing TWT or existing link is sufficient to meet the QoS requirements. In step 2806, when the existing TWT or existing link is insufficient to meet the QoS requirements, the AP device sends a message to the non-AP MLD indicating that an additional TWT SP needs to be negotiated, or that an additional enabled link needs to be switched to active mode, or that an additional link with the AP MLD needs to be enabled. In step 2808, if the existing TWT or existing link is sufficient to meet the QoS requirements, the AP device schedules uplink or downlink resources to meet the QoS requirements.

[0197] In one embodiment, the AP device receives information from a non-AP MLD indicating that the non-AP MLD can be used for a link that meets QoS requirements.

[0198] In one embodiment, when a QoS requirement corresponds to a flow for which a non-AP MLD has negotiated a TWT on one or more links, the AP device: determines whether the negotiated TWT SP can be used to satisfy the QoS requirement; when the negotiated TWT SP cannot satisfy the QoS requirement: the AP device indicates to the non-AP MLD that the negotiated TWT SP is insufficient to satisfy the QoS requirement and considers using an additional TWT SP or other links to satisfy the QoS requirement; or indicates to the non-AP MLD that the non-AP MLD should set up a link with TWT membership on it; and when the negotiated TWT SP can satisfy the QoS requirement, the AP device schedules uplink or downlink resources to satisfy the QoS requirement.

[0199] In one embodiment, the AP device indicates the parameters to be used to set an additional TWT SP or modify an existing TWT SP.

[0200] In one embodiment, the AP device sends an indication in a frame sent to a non-AP MLD that indicates one or more of the following: the negotiated TWT SP is insufficient to meet QoS requirements, or the non-AP MLD should set up a TWT membership link on it, or the non-AP MLD's active link on it is insufficient to meet QoS requirements, or the non-AP MLD's power-saving link on it should be switched to active mode to meet QoS requirements, or the non-AP MLD's disabled link should be enabled to meet QoS requirements, or the non-AP MLD's TWT link on it is insufficient to meet QoS requirements.

[0201] In one embodiment, when the QoS requirement corresponds to a flow for which a non-AP MLD has not yet negotiated a TWT on one or more links, the AP device: determines whether the QoS requirement can be met using only the links on which the non-AP MLD is in active mode; when the QoS requirement cannot be met using only the links on which the non-AP MLD is in active mode: indicates to the non-AP MLD that the links on which the non-AP MLD is in active mode are insufficient to meet the QoS requirement and considers using additional links to meet the QoS requirement; or indicates to the non-AP MLD that the links on which the non-AP MLD is in power-saving mode should be switched to active mode to meet the QoS requirement; or indicates to the non-AP MLD that the disabled links on which the non-AP MLD should be enabled to meet the QoS requirement; and when the QoS requirement can be met using only the links on which the non-AP MLD is in active mode, schedules uplink or downlink resources to meet the QoS requirement.

[0202] In one embodiment, the AP device: determines whether the QoS requirements can be met using a negotiated TWT SP or only using links where a non-AP MLD is active; when the QoS requirements cannot be met using a negotiated TWT SP or only using links where a non-AP MLD is active: indicates to the non-AP MLD that the links where the non-AP MLD is active or the TWTs on which the non-AP MLD is a member are insufficient to meet the QoS requirements, and considers using additional links or additional TWTs; indicates to the non-AP MLD that the links on which the non-AP MLD is in power-saving mode should be switched to active mode or negotiate TWT membership to meet the QoS requirements; or indicates to the non-AP MLD that the disabled links of the non-AP MLD should be enabled to meet the QoS requirements; and when the QoS requirements can be met using a negotiated TWT SP or only using links where a non-AP MLD is active, schedules uplink or downlink resources to meet the QoS requirements.

[0203] In one embodiment, when the AP device determines that the existing TWT negotiation is insufficient, it indicates the parameters to be used to set up an additional TWTSP or modify the existing TWTSP.

[0204] In one embodiment, when the QoS requirement no longer exists, the AP device provides an indication to the non-AP MLD that it is no longer necessary to keep one or more stations (STAs) associated with the non-AP MLD in active mode or retain membership in a specific TWT.

[0205] In one embodiment, the AP device sends frames to a non-AP MLD to recommend: a link for load balancing uplink and downlink transmission; a link for retrieving buffered traffic at the AP MLD; a link for group-addressed frame reception; a link for TWT negotiation; or a link for Enhanced Multi-Link Single Radio / Enhanced Multi-Link Multiple Radio (EMLSR / EMLMR) operation.

[0206] The flowchart above illustrates an example method that can be implemented according to the principles of this disclosure, and various modifications can be made to the method shown in the flowchart. For example, although shown as a series of steps, the steps can overlap, occur in parallel, occur in different orders, or occur multiple times. In another example, steps can be omitted or replaced with other steps.

[0207] Although this disclosure has been described using exemplary embodiments, various changes and modifications are likely to be recommended to those skilled in the art. This disclosure is intended to cover such changes and modifications that fall within the scope of the appended claims. Nothing described in this application should be construed as implying that any particular element, step, or function is an essential element that must be included within the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A method for wireless communication performed by an access point (AP) associated with an access point (AP) multilink device (MLD), the method comprising: Receive instructions on Quality of Service (QoS) requirements from non-AP MLDs; Determine whether the existing target wake-up time (TWT) or existing links are sufficient to meet QoS requirements; If the existing TWT or existing link is insufficient to meet the QoS requirements, a message is sent to the non-AP MLD indicating that an additional TWT service period (SP) needs to be negotiated, or that the additional enabled link is switched to active mode, or that the additional link with the AP MLD is enabled. and If the existing TWT or existing links are sufficient to meet the QoS requirements, then schedule uplink or downlink resources to meet the QoS requirements.

2. The method of claim 1 further includes receiving information from a non-AP MLD indicating that the non-AP MLD can be used for a link that meets QoS requirements.

3. The method according to claim 1, wherein, Based on the QoS requirements corresponding to flows for which a TWT has already been negotiated by a non-AP MLD on one or more links, the method further includes: Determine whether using the negotiated TWT SP can meet the QoS requirements; If using the negotiated TWT SP cannot meet the QoS requirements: Indicate to the non-AP MLD that the negotiated TWT SP is insufficient to meet the QoS requirements, and consider using an additional TWT SP or other links to meet the QoS requirements; or Instruct the non-AP MLD to set up a TWT-membered link on it; and If the QoS requirements can be met using the negotiated TWT SP, then uplink or downlink resources will be scheduled to meet the QoS requirements.

4. The method of claim 3 further includes indicating the modification of parameters to be used for the additional TWT SP or an existing TWT SP.

5. The method of claim 1, further comprising sending an indication in a frame sent to a non-AP MLD indicating one or more of the following: the negotiated TWT SP is insufficient to meet QoS requirements, or a non-AP MLD should set up a TWT membership link on it, or a non-AP MLD is in an active mode link on it that is insufficient to meet QoS requirements, or a non-AP MLD is in a power-saving mode link on it that should be switched to an active mode to meet QoS requirements, or a disabled link of a non-AP MLD that should be enabled to meet QoS requirements, or a TWT on which a non-AP MLD is a member has insufficient QoS requirements.

6. An access point (AP) associated with an access point (AP) multilink device (MLD), the AP comprising: transceiver; and A processor, operatively coupled to the transceiver, is configured to: Receive instructions on Quality of Service (QoS) requirements from non-AP MLDs; Determine whether the existing target wake-up time (TWT) or existing links are sufficient to meet QoS requirements; If the existing TWT or existing link is insufficient to meet the QoS requirements, a message is sent to the non-AP MLD indicating that an additional TWT service period (SP) needs to be negotiated, or that the additional enabled link is switched to active mode, or that the additional link with the AP MLD is enabled. and If the existing TWT or existing links are sufficient to meet the QoS requirements, then schedule uplink or downlink resources to meet the QoS requirements.

7. The AP according to claim 6, wherein, The processor is also configured to receive information from a non-AP MLD indicating that the non-AP MLD can be used for a link that meets QoS requirements.

8. The AP according to claim 6, wherein, Based on the QoS requirements corresponding to flows for which a TWT has already been negotiated by a non-AP MLD on one or more links, the processor is further configured to: Determine whether using the negotiated TWT SP can meet the QoS requirements; If using the negotiated TWT SP cannot meet the QoS requirements: Indicate to the non-AP MLD that the negotiated TWT SP is insufficient to meet the QoS requirements, and consider using an additional TWT SP or other links to meet the QoS requirements; or Instruct the non-AP MLD to set up a TWT-membered link on it; and If the QoS requirements can be met using the negotiated TWT SP, then uplink or downlink resources will be scheduled to meet the QoS requirements.

9. The AP according to claim 8, wherein, The processor is also configured to indicate parameters to be used for settings of an additional TWT SP or modifications of an existing TWT SP.

10. The AP according to claim 6, wherein, The processor is also configured to send an indication in a frame sent to a non-AP MLD indicating one or more of the following: the negotiated TWT SP is insufficient to meet QoS requirements, or a non-AP MLD should set up a TWT membership link on it, or a non-AP MLD's link in active mode is insufficient to meet QoS requirements, or a non-AP MLD's link in power-saving mode should be switched to active mode to meet QoS requirements, or a disabled link of a non-AP MLD that should be enabled to meet QoS requirements, or a TWT on which a non-AP MLD is a member is insufficient to meet QoS requirements.

11. The AP according to claim 6, wherein, Based on the QoS requirements corresponding to flows for which the non-AP MLD has not yet negotiated a TWT on one or more links, the processor is further configured to: Determine whether the QoS requirements can be met by using only the links on which the non-AP MLD is active. If using only non-AP MLDs in active mode on the links cannot meet QoS requirements: Indicate to the non-AP MLD that the links on which the non-AP MLD is active are insufficient to meet the QoS requirements, and consider using additional links to meet the QoS requirements; or Instruct the non-AP MLD on the links on which the non-AP MLD is in power-saving mode, and the power-saving mode should be switched to active mode to meet QoS requirements; or Indicate to non-AP MLDs that the disabled links of non-AP MLDs should be enabled to meet QoS requirements; and If QoS requirements can be met using only the links on which the non-AP MLD is active, then schedule uplink or downlink resources to meet the QoS requirements.

12. The AP according to claim 6, wherein, To determine whether the existing TWT or existing link is sufficient to meet QoS requirements, the processor is configured to: Determine whether the QoS requirements can be met by using the negotiated TWT SP or by using only a non-AP MLD with an active link on it. If using a negotiated TWT SP or only using a non-AP MLD on which the link is active cannot meet the QoS requirements: Indicate to the non-AP MLD that the link on which the non-AP MLD is active or the TWT of the non-AP MLD as a member is insufficient to meet the QoS requirements, and consider using an additional link or additional TWT. Instruct the non-AP MLD to use the links on which the non-AP MLD is in power-saving mode, which should be switched to active mode or negotiate TWT membership to meet QoS requirements; or Indicate to non-AP MLDs that the disabled links of non-AP MLDs should be enabled to meet QoS requirements; and If the QoS requirements can be met by using a negotiated TWT SP or by using only a non-AP MLD with an active link on it, then schedule uplink or downlink resources to meet the QoS requirements.

13. The AP according to claim 12, wherein, The processor is also configured to, when it is determined that the existing TWT negotiation is insufficient, indicate the parameters to be used for the settings of the additional TWT SP or the modification of the existing TWT SP.

14. The AP according to claim 6, wherein, The processor is also configured to provide the non-AP MLD with an indication that it is no longer necessary to keep one or more stations (STAs) associated with the non-AP MLD in active mode or retain membership in a specific TWT if the QoS requirement no longer exists.

15. The AP according to claim 6, wherein, The processor is also configured to send frames to non-AP MLDs for recommendation: Links to be used for load balancing of uplink and downlink transmissions; The link to be used for retrieving buffered traffic at AP MLD; The link to be used for receiving group-addressed frames; The link to be used for TWT negotiation; or Links to be used for Enhanced Multilink Single Radio / Enhanced Multilink Multiradio (EMLSR / EMLMR) operation.

Images