Method and apparatus for traffic emergency indication

Abstract

A method and apparatus for supporting traffic urgency indication. A wireless communication method performed by a non-access point (AP) device including a first station (STA) includes forming a link with a first AP; sending information associated with the traffic transmission to the first AP, the information including scheduling parameters configured to assist the first AP in making a scheduling decision; receiving data associated with the scheduling parameters from the first AP; and determining to send traffic transmission to the first AP based on the received data.

Description

Technical Field

[0001] The present disclosure generally relates to transmission efficiency in wireless communication systems including multi-link devices.Embodiments of the present disclosure relate to methods and apparatus for traffic urgency indication. Background Art

[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 family of standards is designed to increase speed, reliability, and extend the operating range of wireless networks.

[0003] Multi-link operation (MLO) is a feature currently being developed by the standards body for the next generation extremely high throughput (EHT) Wi-Fi system in IEEE 802.11be. Wi-Fi devices that support MLO are called multi-link devices (MLDs). With MLO, a non-access point (AP) multi-link device (MLD) can discover, authenticate, associate, and establish multiple links with an AP MLD. Channel access and frame exchange are possible on each link between an AP MLD and a non-AP MLD. Summary of the invention

[0004] Embodiments of the present disclosure provide a method and apparatus for traffic urgency indication.

[0005] In one embodiment, a non-AP MLD is provided, comprising: a first station (STA), comprising: a transceiver, configured to: form a link with a first AP; send information associated with traffic transmission to the first AP, the information including scheduling parameters configured to help the first AP make scheduling decisions; and receive data associated with the scheduling parameters from the first AP. The non-AP MLD includes a processor operably coupled to the first STA, the processor configured to determine to send traffic transmission to the first AP based on the received data.

[0006] In one embodiment, a wireless communication method performed by a non-access point (AP) device including a first station (STA) is provided, the method comprising: forming a link with the first AP; sending information associated with traffic transmission to the first AP, the information including scheduling parameters configured to help the first AP make scheduling decisions; receiving data associated with the scheduling parameters from the first AP; and determining to send traffic transmission to the first AP based on the received data.

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

[0008] Before carrying out the following detailed description, it may be advantageous to set forth the definitions of certain words and phrases used throughout this patent document.The term "coupling" and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are in physical contact with each other.The terms "send", "receive" and "communication" and their derivatives cover both direct communication and indirect communication.The terms "include" and "comprise" and their derivatives mean unlimited inclusion.The term "or" is inclusive, meaning and / or.The phrase "associated with..." and its derivatives mean including, included in, interconnected with, included in, connected to, connected to, coupled to, coupled to, can communicate with, collaborate with, interlace, juxtapose, approach, be bound to, bound to, have, have the property of, have a relationship with, etc.The term "controller" means any device, system or part thereof that controls at least one operation.Such a controller can be implemented with hardware or a combination of hardware and software and / or firmware.The function associated with any particular controller can be centralized or distributed, whether local or remote. The phrase "at least one of..." when used with a list of items means that different combinations of one or more of the listed items may be used, and only one item in 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 "1st" and "2nd" or "first" and "second" may be used to simply distinguish a corresponding component from another component without limiting the component in other aspects (e.g., importance or order). It should be understood that if an element (e.g., a first element) is referred to as "coupled with another element (e.g., a second element)", "coupled with another element (e.g., a second element) to", "connected with another element (e.g., a second element)" or "connected to another element (e.g., a second element)", whether or not the term "operably" or "communicatively" is used, this means that the element may be coupled to another element directly (e.g., wired), wirelessly, or via a third element.

[0009] As used herein, the term "module" may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with other terms (e.g., "logic," "logic block," "component," or "circuit"). A module may be a single integrated component adapted to perform one or more functions, or a minimum unit or component of a single integrated component. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0010] In addition, the various functions described below may be implemented or supported by one or more computer programs, each of which is formed by a 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, sets of instructions, procedures, functions, objects, classes, instances, related data, or parts thereof suitable for implementation with suitable 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 that can be accessed by a computer, such as read-only memory (ROM), random access memory (RAM), hard drive, compact disc (CD), digital video disc (DVD), or any other type of memory. "Non-transitory" computer-readable media do not include wired, wireless, optical, or other communication links that transmit temporary electrical or other signals. Non-transitory computer-readable media include media that can permanently store data and media that can store data and rewrite it later (such as rewritable optical disks or erasable storage devices).

[0011] Definitions for other specific words and phrases are also provided throughout this patent document. Those of ordinary skill in the art should understand that in many, if not most, instances, such definitions apply to prior as well as future uses of such defined words and phrases. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description in conjunction with the accompanying drawings, in which like reference numerals represent like parts:

[0013] Figure 1 An example wireless network according to an embodiment of the present disclosure is shown;

[0014] Figure 2a An example AP according to an embodiment of the present disclosure is shown;

[0015] Figure 2b An example station (STA) according to an embodiment of the present disclosure is shown;

[0016] Figure 3 An example measurement request frame format according to an embodiment of the present disclosure is shown;

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

[0018] Figure 5 An example timeline of measurement request and response framework operation according to an embodiment of the present disclosure is shown;

[0019] Figure 6 An example timeline of triggering TXOP sharing operations according to an embodiment of the present disclosure is shown;

[0020] Figure 7 An example measurement request field format used by an AP in a measurement request frame format according to an embodiment of the present disclosure is shown;

[0021] Figure 8 A flowchart of a method for transmitting a measurement request frame performed by an AP according to an embodiment of the present disclosure is shown;

[0022] Fig. 9 A flowchart of a method performed by an AP to respond to a measurement response frame from a STA according to an embodiment of the present disclosure is shown;

[0023] Fig.10 A flowchart of a method for transmitting a measurement response frame performed by a STA according to an embodiment of the present disclosure is shown;

[0024] Fig.11 An example format of a control information subfield of a buffer status report frame for traffic urgency indication according to an embodiment of the present disclosure is shown; and

[0025] Fig.12 A flowchart of a wireless communication method performed by a non-AP device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0026] Discussed below Figures 1 to 12 The various embodiments used to describe the principles of the present disclosure in this patent document are exemplary only and should not be interpreted in any way as limiting the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can be implemented in any appropriately arranged system or device.

[0027] The following documents and standard descriptions are incorporated by reference into the present disclosure as if fully set forth herein: IEEE P802.11be / D1.6, 2022 (referred to herein as REF [1]); IEEE P802.11-REVme / D1.1, 2022 (referred to herein as REF [2]).

[0028] Embodiments of the present disclosure provide a mechanism for traffic urgency indication.

[0029] Figure 1 An example wireless network 100 is shown according to one embodiment of the present disclosure. Figure 1 The embodiment of the wireless network 100 shown is for illustration only. Other embodiments of the wireless network 100 may be used without departing from the scope of the present disclosure.

[0030] The wireless network 100 includes APs 101 and 103. The 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. The AP 101 provides wireless access to the network 130 for a plurality of STAs 111-114 within a coverage area 120 of the AP 101. The APs 101-103 may communicate with each other and with the STAs 111-114 using Wi-Fi or other WLAN communication technologies.

[0031] Depending on the network type, other well-known terms may 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 a remote terminal. In a WLAN, a given AP also competes for a wireless channel, and the AP may also be referred to as a STA (e.g., AP STA). In addition, depending on the network type, other well-known terms may be used instead of "station" or "STA", such as "mobile station", "subscriber station", "remote terminal", "user equipment", "wireless terminal" or "user equipment". 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 competes for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smart phone) or a generally considered fixed device (such as a desktop computer, AP, media player, fixed sensor, TV, etc.). This type of STA may also be referred to as a non-AP STA.

[0032] In one embodiment of the present disclosure, each of the APs 101 and 103 and each of the STAs 111-114 may be an MLD. In such an embodiment, the APs 101 and 103 may be AP MLDs, and the STAs 111-114 may be non-AP MLDs. Each MLD is attached to more than one STA. For ease of explanation, an AP MLD is described herein as being attached to more than one AP (e.g., more than one AP STA), and a non-AP MLD is described herein as being attached to more than one STA (e.g., more than one non-AP STA).

[0033] The dashed lines illustrate the approximate extents of coverage areas 120 and 125, which are shown as generally circular for purposes of illustration and explanation only. It should be clearly understood that coverage areas associated with APs, such as coverage areas 120 and 125, may have other shapes, including irregular shapes, depending on the configuration of the AP and variations in the radio environment associated with natural and man-made obstacles.

[0034] As described in more detail below, one or more APs may include circuitry and / or programming for traffic urgency indication. Figure 1 One example of a wireless network 100 is shown, but may be Figure 1 Various changes may be made. For example, the wireless network 100 may include any number of APs and any number of STAs in any suitable arrangement. In addition, the AP 101 may communicate directly with any number of STAs and provide these STAs with wireless broadband access to the network 130. Similarly, each AP 101-103 may communicate directly with the network 130 and provide the STAs with direct wireless broadband access to the network 130. In addition, the APs 101 and / or 103 may provide access to other or additional external networks (such as external telephone networks or other types of data networks).

[0035] Figure 2a An example AP 101 is shown according to one embodiment of the present disclosure. Figure 2a The illustrated embodiment of AP 101 is for illustration only, and Figure 1 The APs 103 may have the same or similar configurations. In the embodiments discussed below, the AP 101 is an AP MLD. However, the APs may have a variety of configurations, and Figure 2a The scope of the present disclosure is not limited to any particular implementation of the AP.

[0036] The AP MLD 101 is attached to a plurality of APs 202a-202n (which may be referred to as, for example, AP1-APn). Each of the attached APs 202a-202n includes a plurality of antennas 204a-204n, a plurality of RF transceivers 209a-209n, a transmit (TX) processing circuit 214, and a receive (RX) processing circuit 219. The AP MLD 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface (IF) 234.

[0037] The illustrated components of each subordinate AP 202a-202n may represent the physical (PHY) layer and the lower media access control (LMAC) layer in the open systems interconnection (OSI) networking model. In such an embodiment, the illustrated components of the AP MLD 101 represent a single upper MAC (UMAC) layer and other higher layers in the OSI model shared by all subordinate APs 202a-202n.

[0038] For each satellite AP 202a-202n, an RF transceiver 209a-209n receives an incoming RF signal from an antenna 204a-204n, such as a signal transmitted by a STA in the network 100. In some embodiments, each satellite AP 202a-202n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), and accordingly, the incoming RF signals received by each satellite AP may be at a different RF frequency. The RF transceiver 209a-209n down-converts the incoming RF signal to generate an IF or baseband signal. The IF or baseband signal is sent to the RX processing circuit 219, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signal. The RX processing circuit 219 sends the processed baseband signal to the controller / processor 224 for further processing.

[0039] For each of the attached APs 202a-202n, the TX processing circuitry 214 receives analog or digital data (such as voice data, network data, email, or interactive electronic game data) from the controller / processor 224. The TX processing circuitry 214 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from the TX processing circuitry 214 and up-convert the baseband or IF signals to RF signals that are transmitted via the antennas 204a-204n. In embodiments where each of the attached APs 202a-202n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), the outgoing RF signals transmitted by each of the attached APs may be at different RF frequencies.

[0040] The controller / processor 224 may include one or more processors or other processing devices that control the overall operation of the AP MLD 101. For example, the controller / processor 224 may control the reception of the forward channel signal and the transmission of the reverse channel signal by the RF transceiver 209a-209n, the RX processing circuit 219, and the TX processing circuit 214 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, in which the signals transmitted from the multiple antennas 204a-204n are weighted differently to effectively direct the outgoing signals to the desired direction. The controller / processor 224 may also support OFDMA operations, in which the outgoing signals are assigned to different subcarrier subsets of different recipients (e.g., different STAs 111-114). The controller / processor 224 may support any of a variety of other functions in the AP MLD 101, including traffic urgency indication. In some embodiments, the controller / processor 224 includes at least one microprocessor or microcontroller. Controller / processor 224 is also capable of executing programs and other processes, such as an OS, that reside in memory 229. Controller / processor 224 may move data into or out of memory 229 as required by the executing process.

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

[0042] As described in more detail below, AP MLD 101 may include circuitry and / or programming for traffic urgency indication. Figure 2a An example of AP MLD 101 is shown, but the same may be applied to Figure 2a For example, AP MLD 101 may include Figure 2a Any number of each component shown. As a specific example, the AP MLD 101 may include multiple interfaces 234, and the controller / processor 224 may support routing functions to route data between different network addresses. As another specific example, although each satellite AP 202a-202n is shown as including a single instance of the TX processing circuit 214 and a single instance of the RX processing circuit 219, the AP MLD 101 may include multiple instances of each satellite AP in one or more satellite APs 202a-202n (such as one satellite AP for each RF transceiver). Alternatively, only one antenna and RF transceiver path may be included in one or more satellite APs 202a-202n (such as in a traditional AP). In addition, Figure 2a The various components in may be combined, further subdivided, or omitted, and additional components may be added according to specific needs.

[0043] Figure 2b An example STA 111 is shown according to one embodiment of the present disclosure. Figure 2b The embodiment of STA 111 shown is for illustration only, and Figure 1 STAs 111-115 may have the same or similar configurations. In the embodiments discussed below, STA 111 is a non-AP MLD. However, STAs may have a variety of configurations, and Figure 2b The scope of the present disclosure is not limited to any particular implementation of a STA.

[0044] The non-AP MLD 111 is attached to a plurality of STAs 203A-203N (which may be referred to as, for example, STA1-STAN). Each of the attached STAs 203a-203n includes an antenna 205, a radio frequency (RF) transceiver 210, a TX processing circuit 215, and a receive (RX) processing circuit 225. The non-AP MLD 111 also includes a microphone 220, a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touch screen 250, a display 255, and a memory 260. The memory 260 includes an operating system (OS) 261 and one or more applications 262.

[0045] The illustrated components of each dependent STA 203a-203n may represent the PHY layer and the LMAC layer in the OSI networking model. In such an embodiment, the illustrated components of the non-AP MLD 111 represent a single UMAC layer and other higher layers in the OSI model shared by all dependent STAs 203a-203n.

[0046] For each affiliated STA 203a-203n, the RF transceiver 210 receives an incoming RF signal sent by the AP of the network 100 from the antenna 205. In some embodiments, each affiliated STA 203a-203n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), and accordingly the incoming RF signal received by each affiliated STA can be at a different RF frequency. The RF transceiver 210 down-converts the incoming RF signal to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is sent to the RX processing circuit 225, which generates a processed baseband signal by filtering, decoding and / or digitizing the baseband or IF signal. The RX processing circuit 225 sends the processed baseband signal to the speaker 230 (such as for voice data) or the controller / processor 240 for further processing (such as for web browsing data).

[0047] For each affiliated STA 203a-203n, the TX processing circuit 215 receives analog or digital voice data from the microphone 220, or receives other outgoing baseband data (such as network data, email, or interactive electronic game data) from the controller / processor 240. The TX processing circuit 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 210 receives the outgoing processed baseband or IF signal from the TX processing circuit 215 and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna 205. In an embodiment where each affiliated STA 203a-203n operates at a different bandwidth (e.g., 2.4 GHz, 5 GHz, or 6 GHz), the outgoing RF signal transmitted by each affiliated STA can be at a different RF frequency.

[0048] The controller / processor 240 may include one or more processors and execute a basic OS program 261 stored in the memory 260 to control the overall operation of the non-AP MLD 111. In one such operation, the main controller / processor 240 controls the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 210, the RX processing circuit 225, and the TX processing circuit 215 according to well-known principles. The main controller / processor 240 may also include processing circuits configured to support traffic urgency indication. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0049] The controller / processor 240 is also capable of executing other processes and programs resident in the memory 260, such as operations for supporting traffic urgency indications. The controller / processor 240 can move data into or out of the memory 260 as needed to execute the process. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as applications for supporting traffic urgency indications. The controller / processor 240 can operate multiple applications 262 based on the OS program 261 or in response to signals received from the AP. The main controller / processor 240 is also coupled to the I / O interface 245, which provides the non-APMLD 111 with the ability to connect to other devices, such as laptops and handheld computers. The I / O interface 245 is the communication path between these accessories and the main controller 240.

[0050] The controller / processor 240 is also coupled to a touch screen 250 and a display 255. An operator of the non-AP MLD 111 may use the touch screen 250 to input data into the non-AP MLD 111. The display 255 may be a liquid crystal display, a light emitting diode display, or other display capable of presenting text and / or at least limited graphics (such as from a website). A memory 260 is coupled to the controller / processor 240. A portion of the memory 260 may include random access memory (RAM), and another portion of the memory 260 may include flash memory or other read-only memory (ROM).

[0051] although Figure 2b An example of a non-AP MLD 111 is shown, but the Figure 2b Make various changes. For example, Figure 2b The various components in the embodiment may be combined, further subdivided, or omitted, and additional components may be added as required. In a specific example, any number of antennas 205 may be included in one or more of the affiliated STAs 203a-203n for MIMO communication with the AP 101. In another example, the non-AP MLD 111 may not include voice communications, or the controller / processor 240 may be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). In addition, although Figure 2b The non-AP MLD 111 is shown configured as a mobile phone or smart phone, but the non-AP MLD may be configured to operate as other types of mobile or fixed devices.

[0052] One embodiment of the present disclosure recognizes that the measurement request and response element framework specified in REF [2] provides an AP with a framework for requesting a STA to take specified measurement actions and send measurement reports to the AP. Many request and response elements have been defined in REF [2] to convey various information, such as clear channel assessment (CCA), receive power indication (RPI), etc. In addition, the AP can also use this framework to request the destination STA to activate autonomous reporting mode. This mode allows a STA to send measurement results for which no explicit measurement request has been made. The format of the measurement request frame is as follows: Figure 3 shown.

[0053] Figure 3 An example measurement request frame format 300 is shown according to an embodiment of the disclosure. Figure 3The illustrated embodiment of the example measurement request frame format 300 is for illustration only. Other embodiments of the example measurement request frame format 300 may be used without departing from the scope of the present disclosure.

[0054] like Figure 3 As shown, the measurement request frame contains a measurement token 302, which is a non-zero number that uniquely identifies a measurement request. In addition, the measurement request frame contains a measurement request mode, which contains a three-bit encoding to specify the nature of the response expected from the STA (for example, the STA may send an autonomous measurement report to the AP). The measurement type 304 is a unique number that identifies the measurement requested by the AP from the STA. Currently, 18 measurement request types have been defined, and the remaining values ​​are reserved for future request definitions. Finally, the measurement request field 306 ( Figure 3 The last field in the frame shown in FIG. 10A ) carries a measurement request element that specifies the measurement details that the AP requests from the STA.

[0055] Figure 4 An example measurement response frame format 400 is shown according to an embodiment of the disclosure. Figure 4 The illustrated embodiment of the example measurement response frame format 400 is for illustration only. Other embodiments of the example measurement response frame format 400 may be used without departing from the scope of the present disclosure.

[0056] like Figure 4 As shown, the measurement response frame is similar to the measurement request frame. The key difference is that the measurement response frame contains a measurement report field 402 ( Figure 4 4. The measurement report field 402 is the last field in the frame shown in FIG. 4A ), and the measurement report field 402 contains the report information (rather than the measurement request field in the measurement request frame).

[0057] Figure 5 An example timeline of measurement request and response framework operations 500 is shown in accordance with an embodiment of the disclosure. Figure 5 The illustrated embodiment of the example timeline of the measurement request and response framework operations 500 is for illustration only. Other embodiments of the example timeline of the measurement request and response framework operations 500 may be used without departing from the scope of the present disclosure.

[0058] like Figure 5 As shown, the AP requests the STA to perform a measurement operation and send a measurement report to the AP. The measurement request specifies measurement parameters and report constraints, such as report frequency. The STA performs the measurement and sends a measurement response containing the measurement value according to the measurement request.

[0059] One embodiment of the present disclosure recognizes that triggered sharing is one of the newly introduced procedures in the IEEE 802.11be REF [1]. According to the 802.11be specification, the procedure allows an AP to allocate a portion of the acquired TXOP duration to one of its associated non-AP Extremely High Throughput (EHT) STAs. The associated non-AP EHT STA can then use the allocated duration for the transmission of one or more non-TB PPDUs.

[0060] Figure 6 An example timeline 600 of triggered TXOP sharing operations according to an embodiment of the disclosure is shown. Figure 6 The illustrated embodiment of the example timeline 600 for triggering TXOP sharing operations is for illustration only. Other embodiments of the example timeline 600 for triggering TXOP sharing operations may be used without departing from the scope of the present disclosure.

[0061] According to the 802.11be specification, the EHT AP may allocate a portion of its acquired TXOP duration to the non-AP EHT STA by sending a multi-user ready-to-send (MU-RTS) TXOP Sharing (TXS) trigger frame 602 addressed to the associated non-AP EHT STA and containing a user information field. When the non-AP EHT STA receives the MU-RTS TXS trigger frame from its associated AP addressed to it, the non-AP EHT STA may send one or more non-TB PPDUs within the allocated time.

[0062] An example of triggering TXOP shared mode operation is Figure 6 As shown. When the AP obtains the TXOP after winning the channel contention, the AP sends a CTS to itself (CTS-to-self) 604. This is followed by a MU-RTS TXS trigger frame, which is sent to the target STA with which the AP wants to share the TXOP duration. The portion of the TXOP shared with the target non-AP STA (non-AP STA1 in the above example) is specified in the MU-RTS TXS trigger frame itself. The target STA then uses this duration to send its own frame on the uplink to the AP (mode 1) or its peer STA (mode 2).

[0063] One embodiment of the present disclosure recognizes that an AP may have many STAs associated with it. Furthermore, depending on the applications that the user runs on the STA, uplink traffic may vary from STA to STA. Furthermore, when the AP obtains a TXOP, it may have its own data to send. As a result, the amount of time remaining within the obtained TXOP may not be sufficient to detect every STA associated with the AP.

[0064] Depending on the nature of the traffic, a non-AP MLD may have an urgent need to send traffic on one of its links. An example scenario is as follows. One of the STAs attached to the non-AP MLD may have packets corresponding to real-time / cloud gaming traffic in its queue, and if that STA is not served within a certain amount of time, the latency requirement may be exceeded. It may be beneficial if such a STA can be identified and served with higher priority.

[0065] Knowing which STA has such urgent traffic transmission requirements can enable the AP to prioritize such STA during TXOP sharing. Unfortunately, in the current specification, the AP does not have such information available.

[0066] Accordingly, one embodiment of the present disclosure provides a procedure for enabling a STA to indicate the urgency of traffic transmission to its AP. The traffic urgency indication procedure discussed in the present disclosure can be used for a range of features / applications, including but not limited to triggered TXOP sharing, R-TWT, AP-side scheduling, etc. In the present disclosure, the embodiments are discussed in the context of triggered TXOP sharing. However, the procedure for traffic urgency indication can be used for any of the above features / applications.

[0067] According to one embodiment, the STA may indicate the urgency of traffic transmission according to the duration that the corresponding packet will be kept in the STA queue (e.g., the packet expiration time, which may be the duration from the current time until the time when the delay limit of the packet is exceeded or the time when the delay limit of the packet will be exceeded). In one embodiment, this may also be indicated according to the packet enqueue time. The packet enqueue time may be the time when the packet arrives at the MAC queue of the STA (e.g., it is generated by an application running on the STA and then pushed into the MAC queue). In addition, this information may also be indicated for the head-of-line (HOL) packet and may be referred to as HOL packet delay feedback. The HOL packet delay information may be the enqueue time of the packet at the head of the queue. In the HOL packet delay information, instead of indicating the enqueue time / packet expiration time for each packet, it may be indicated only for the first packet in the queue. The first packet is sent before each packet, so the urgency of the packet is the highest because it has been in the queue for the longest time. Alternatively, it may be the duration (e.g., packet expiration time) that the packet can be kept in the STA queue. In addition, the delay may be indicated at the MLD level or at the link level. According to one embodiment, a traffic identifier (e.g., TID) may be used to provide an indication of traffic urgency. According to this embodiment, a TID corresponding to latency-sensitive traffic (e.g., traffic with a lower delay bound) may be used to infer the urgency of the transmission. According to one embodiment, a traffic type (e.g., traffic corresponding to an emergency preparedness communication service (EPCS)) may be used for traffic urgency indication.

[0068] Figure 7 An example measurement request field format 700 for use by an AP in a measurement request frame format according to an embodiment of the present disclosure is shown. Figure 7 The illustrated embodiment of the example measurement request field format 700 used by an AP in a measurement request frame format is for illustration only. Other embodiments of the example measurement request field format 700 used by an AP in a measurement request frame format may be used without departing from the scope of the present disclosure.

[0069] According to one embodiment, new request and response elements may be defined to operate within the measurement request and response framework. In addition, according to this embodiment, the measurement request frame (e.g., Figure 3 As shown in FIG. 1 , the AP may send a measurement request frame to the STA, where the measurement request mode is set to allow the STA to send autonomous measurement reports to the AP. This may authorize the STA to send autonomous measurement reports when necessary to convey the urgency of its traffic transmission to the AP whenever necessary, without requiring the AP to send any additional request / probe frames to the STA.

[0070] As described herein, the measurement request field ( Figure 3 The last field in the frame shown in FIG. 10 carries a measurement request element that specifies the measurement details requested by the AP from the STA. Therefore, according to one embodiment, the measurement request field may contain one or more per-link measurement request sub-elements 702, each of which may define a measurement request for a given link. An example is shown in FIG. Figure 7 shown.

[0071] Each per-link measurement request sub-element may contain one or more information items shown in Table 1:

[0072] Table 1 Information content of the measurement request field carried in the measurement request frame

[0073] [Table 1]

[0074] Information item name Size (octets) describe Link ID 1 The link ID corresponding to the link for which the measurement request has been defined. The first four bits of this field may be used to indicate the link ID, while the remaining bits are reserved. TID Bitmap 2 The TID bitmap contains TIDs corresponding to the AP authorizing the STA to send a measurement response indicating traffic urgency to the AP. Measurement start time 8 A start time indicating the time from when the request can be considered active. In one embodiment, the start time may be a multiple of a fixed pre-negotiated or pre-known value (e.g., TBTT, TU). According to one embodiment, the start time may be set to the TSF timer in the case where the requested measurement is indicated with a value of 0 that it can start immediately. Request activity duration 2 A request can be considered as the duration of an activity, expressed in units of fixed pre-negotiated or pre-known values ​​(e.g., TBTT, TU).

[0075] In response to receiving a measurement request frame from the AP, the STA may send a measurement response frame including an indication of the urgency of its traffic transmission. According to one embodiment, the STA may indicate the urgency of the traffic transmission based on the duration that the corresponding packet will be held in the STA queue. In one embodiment, this may also be indicated based on the packet enqueue time. In addition, this information may also be referred to as packet delay feedback and may be indicated for the header of the link packet.

[0076] In one embodiment, this may be indicated according to a pre-negotiated or pre-known value (e.g., TBTT representing the target beacon transmission time, TU representing the time unit). In one embodiment, the duration may be indicated according to a TSF (Timing Synchronization Function) timer value when the delay tolerance of the indicated TID packet will be exceeded. In addition, according to this embodiment, the measurement report field in the measurement response frame may contain one or more information elements as shown in Table 2.

[0077] Table 2 Information content of the measurement report field carried in the measurement response frame

[0078] (A frame may carry one or more of the information indicated in this table)

[0079] [Table 2]

[0080] Information item name Size (bits) describe Link ID 4 The link ID for which information is indicated. TID 4 The TID for which this information is indicated. The AP can also understand the priority of buffered traffic based on its TID. Group Identifier 8 Packet identifier (e.g., sequence number). When the AP receives a packet whose packet identifier matches this value, the AP can assume that the STA has already sent the corresponding traffic and does not have any urgency unless another measurement response frame is received from the STA. Note that the STA may not need to send only one packet, but may want to send multiple packets. In this case, the packet identifier will correspond to the final packet that the STA must send. Duration 64 Until the duration that the packet will be retained in the STA queue / until the duration of the packet delay tolerance is not exceeded. In one embodiment, this can be indicated according to a pre-negotiated or pre-known value (e.g., TBTT, TU). In one embodiment, the duration can be indicated according to the TSF timer value when the delay tolerance of the indicated TID packet will be exceeded. According to one embodiment, the delay tolerance can be a value indicated in the QoS characteristic element. In one embodiment, the indicated TSF time can be indicated with reference to the TSF time of the sending link. Alternatively, this can also be any indicator previously mentioned for indicating the urgency of traffic transmission.

[0081] Figure 8 A flowchart of a method 800 for transmitting a measurement request frame performed by an AP according to an embodiment of the present disclosure is shown. Figure 8The illustrated embodiment of the method 800 performed by an AP for transmitting a measurement request frame is for illustration only. Other embodiments of the method 800 performed by an AP for transmitting a measurement request frame may be used without departing from the scope of the present disclosure.

[0082] like Figure 8 As shown, in one embodiment, the AP MLD can authorize the non-AP MLD to indicate traffic transmission urgency for any of its affiliated STAs. Method 800 begins at step 802, where it is determined whether the AP wants to authorize the STA to send traffic urgency indications. If not, then at step 804, no action is required. If yes, then at step 806, the AP sends a measurement request frame on any link that the corresponding non-AP MLD has formed with the AP MLD. At step 808, when the request frame is received from the AP MLD, the STA on the indicated link can be considered to be authorized to send such information, and the AP waits for a response from the STA.

[0083] Fig. 9 A flowchart of a method 900 for transmitting a measurement response frame from a STA performed by an AP according to an embodiment of the present disclosure is shown. Fig. 9 The illustrated embodiment of the method 900 performed by an AP for transmitting a measurement response frame from a STA is for illustration only. Other embodiments of the method 900 performed by an AP for transmitting a measurement response frame from a STA may be used without departing from the scope of the present disclosure.

[0084] like Fig. 9 As shown, in one embodiment, when the AP receives a measurement response frame from the STA, the AP may share the duration within the TXOP that it has obtained before the duration value indicated in the response frame. The link on which the TXOP sharing is performed may be a link identified by a link ID in the measurement response frame. Method 900 begins at step 902, where it is determined whether the AP receives a traffic urgency indication from its associated STA. If not, then at step 904, no action is required. If yes, then at step 906, it is determined whether the AP obtains a TXOP on the link indicated by the STA within the duration indicated by the STA. If no, then at step 908, no action is required. If yes, then at step 910, the AP schedules the STA to transmit within the TXOP.

[0085] Fig.10 A flowchart of a method 1000 for transmitting a measurement response frame performed by a STA according to an embodiment of the present disclosure is shown. Fig.10The illustrated embodiment of the method 1000 for transmitting a measurement response frame performed by a STA is for illustration only. Other embodiments of the method 1000 for transmitting a measurement response frame performed by a STA may be used without departing from the scope of the present disclosure.

[0086] like Fig.10 As shown, in one embodiment, after providing the indication, when the AP shares a portion of its acquired TXOP with the STA, the STA may send a packet corresponding to the information indicated in the measurement response frame. The method 1000 begins at step 1002, where it is determined whether the non-AP MLD is authorized by the AP MLD to provide a traffic urgency indication. If not, then at step 1004, no action is required. If yes, then at step 1006, it is determined whether the affiliated STA has an urgent traffic transmission requirement. If no, then at step 1008, no action is required. If yes, then at step 1010, the non-AP MLD generates a measurement response frame and sends it to the AP on any link.

[0087] In one embodiment, the STA may send an emergency traffic indication to the AP in a frame (e.g., any existing frame or a newly defined frame sent separately). The frame may contain the information mentioned in Table 3. In one embodiment, one or more information fields indicated in the following table may be carried in a control subfield, and the subfield may be referred to as a delay status report (DSR) control subfield.

[0088] Table 3 Independent emergency traffic indication frame sent by STA to AP

[0089] Information contained in

[0090] [Table 3]

[0091] Subfield Name Size (bits) describe Element ID 8 Element ID length 8 Frame length Element ID Extensions 8 Element ID Extensions Link ID 4 In one embodiment, the AP / APMLD may perform resource sharing / medium time allocation in TXOP sharing mode on the link indicated by the link ID. TID 4 The TID for which this information is indicated. The AP can also understand the priority of buffered traffic based on its TID. Group Identifier 8 Packet identifier (e.g., sequence number). When the AP receives a packet whose packet identifier matches this value, the AP can assume that the STA has sent the corresponding traffic and does not have any urgency unless another Measurement Response frame is received from the STA. Duration 64 Until the duration that the packet will be retained in the STA queue / until the duration of the packet delay tolerance is not exceeded. In one embodiment, this can be indicated according to a pre-negotiated or pre-known value (e.g., TBTT, TU). In one embodiment, the duration can be indicated according to the TSF timer value when the delay tolerance of the indicated TID packet will be exceeded. According to one embodiment, the delay tolerance can be a value indicated in the QoS characteristic element. In one embodiment, the indicated TSF time can be indicated with reference to the TSF time of the sending link. Alternatively, this can also be any of the metrics mentioned previously for indicating the urgency of traffic transmission.

[0092] In some embodiments, the duration subfield (shown in Table 3) may contain information for a HOL packet and may be referred to as HOL packet delay feedback. In addition, the same field may be used to indicate the HOL packet enqueue time using a flag to indicate which value the field carries.

[0093] In addition, according to this embodiment, the STA can send the above-mentioned independent emergency traffic indication frame to the AP on any link it has established with the AP when necessary without any authorization from the AP. When receiving the above-mentioned frame from the STA, if the AP obtains a TXOP within the duration indicated by the STA, it can share a part of its TXOP with the STA.

[0094] In one embodiment, the traffic urgency indication may also be provided by the STA to the AP in a modified A-Control subfield containing the information mentioned in Table 2.

[0095] Fig.11 An example format 1100 of a control information subfield of a buffer status report frame for traffic urgency indication according to an embodiment of the present disclosure is shown. Fig.11 The illustrated embodiment of the example format 1100 of the control information subfield of the buffer status report frame for traffic urgency indication is for illustration only. Other embodiments of the example format 1100 of the control information subfield of the buffer status report frame for traffic urgency indication may be used without departing from the scope of the present disclosure.

[0096] In one embodiment, the traffic urgency indication may also be provided in a modified buffer status report frame. The control information subfield of such a buffer status report frame may contain additional information compared to the buffer status report frame in the standard. The information added to the control information subfield of the buffer status report may be as shown in Table 3, or may include one or more information fields indicated in Table 3. An example format of the control information subfield of such a modified buffer status report may be as shown in Table 3. Fig.11 As shown. One or more of these information fields may be present / absent. In addition, one or more of these information fields may be sent in any other type of frame exchanged between the AP and the STA.

[0097] When triggered by the AP or by itself, the STA may send the modified buffer status report to the AP. When the AP receives such a modified buffer status report from its associated STA, the AP may then follow the same procedures as described herein. Fig. 9 A similar procedure as shown.

[0098] Furthermore, the traffic urgency indication may be sent by a STA or a STA attached to a non-AP MLD to an AP or an AP attached to an AP MLD in a separate frame or as a part of any existing frame in the standard.

[0099] Furthermore, in one embodiment, for resource request / medium time allocation for TXOP sharing to send frames to its peer in P2P operation mode, a STA or a STA affiliated with a non-AP MLD may send one or more information fields indicated in Table 3 to an AP or an AP affiliated with an AP MLD. The TID information may indicate to the AP / AP MLD the priority of the packet enqueued at the STA.

[0100] When receiving the frame, the AP / AP MLD can allocate medium time to the STA from the TXOP duration it obtains to send frames to its P2P peer STA. In addition, according to this embodiment, the AP can also understand which link the medium time is allocated on from the information provided by the STA. The AP can understand the link in two ways.

[0101] According to one embodiment, any STA attached to a non-AP MLD may send a frame with a Link ID field in it and provide explicit notification to the AP MLD / AP. The AP MLD / AP may then allocate medium time from the TXOP duration it obtains on the link whose Link ID is mentioned in the frame sent by the STA attached to the non-AP MLD. Note that in this case, the frame may be sent on any link that the non-AP MLD has established with the AP MLD.

[0102] According to one embodiment, the non-AP MLD sends the frame on the same link on which it wishes to allocate media time as a portion of the acquired TXOP duration. Based on this implicit notification, the AP MLD may then allocate media time on the same link on which the frame was received. Note that in this case, explicit link ID indication may not be necessary. This implicit notification may be useful in P2P scenarios where frames may be sent on the same link used for P2P operations.

[0103] According to one embodiment, the AP may infer that the STA is facing traffic urgency based on historical data. Based on this information, the STA may provide timing information (e.g., such as described herein) to the AP for one or more frames sent by the STA to the AP. In addition, according to this embodiment, the STA may provide this information to the AP as part of the frame sent to the AP, or provide this information to the AP in a separate frame (e.g., a measurement request and response frame or any existing frame in the specification). The AP may use this information to calculate the delay faced by the STA when attempting to send a frame. The AP may also calculate the delay on a per-TID / AC basis. Based on this statistical data, the AP may infer that the STA may face delays for its future transmissions, and the AP may take necessary actions to reduce the delays for future transmissions (e.g., giving priority to STAs with longer delays for triggering uplinks). After taking action, the AP may calculate the delay again based on the information provided by the STA to evaluate whether the situation of the STA has improved. An example of this procedure is as follows. Assume that AP1 is receiving packets from STA1. In each packet sent by STA1, STA1 provides timing information (e.g., an enqueue timestamp or any indicator described herein). The AP uses the enqueue timestamp and the receive timestamp to calculate the net delay faced by STA1. To reduce this delay or ensure that future packets do not face such a long delay, the AP may prioritize STA1 for triggering uplink transmission. The AP may infer the existence of a backlog at the STA based on any procedure described in this disclosure or based on any procedure present in the specification (e.g., buffer status reporting).

[0104] In one embodiment, the AP / AP MLD may give higher priority to EPCS (Emergency Preparedness Communication Service) enabled devices than non-EPCS devices in scheduling decisions. In addition, according to this embodiment, when making any kind of scheduling decisions in TXOP sharing mode, the AP / AP MLD may give higher priority to the buffered traffic / frames of STAs attached to non-AP MLDs that have enabled EPCS authorization. For example, if the AP / AP MLD has the option to allocate medium time / resources to two STAs (STA1 and STA2) in TXOP sharing mode, and STA1 is attached to EPCS authorized / enabled non-AP MLD, and STA2 is attached to EPCS unauthorized / enabled non-AP MLD, then when allocating medium time / resources in TXOP sharing mode, the AP / AP MLD may give STA 1 higher priority than STA2. In addition, as part of other scheduling related features in the standard (e.g., triggered-based transmission), for downlink and / or uplink traffic scheduling, the AP / AP MLD may give such higher preference to EPCS authorized devices, and is not limited to TXOP sharing mode.

[0105] Any of the above frames can be sent by a STA or a STA attached to a non-AP MLD to an AP or an AP attached to an AP MLD. If the frame is sent by a STA attached to a non-AP MLD to an AP attached to an AP MLD, the frame can be sent on any link established between the non-AP MLD and the APMLD.

[0106] In one embodiment, upon receiving any of the above frames, the AP may allocate a portion of its TXOP on the link that the STA has indicated via the link ID. In one embodiment, the AP may select the link on which to allocate a portion of the TXOP based on its own knowledge of the TID to link mapping.

[0107] In one embodiment, the STA may also send the above frame on any link that has been established between itself and the AP associated with it.

[0108] Furthermore, the information fields discussed in this disclosure may be sent as part of any existing frame in the standard.One or more information fields may be present / absent.

[0109] The embodiments presented in this disclosure are not limited to TXOP sharing and may be used for any other purpose (eg, scheduling uplink RUs by an AP).

[0110] For example, the embodiments described herein may be applied for restricted TWT (R-TWT) purposes. According to one embodiment, based on the traffic urgency indication, the AP may prioritize STAs with higher urgency packets (eg, earlier packet expiration times) for transmission.

[0111] In addition, according to this embodiment, after the packet is queued on the STA side, the STA can provide a traffic urgency indication to the AP. The STA can use any of the above procedures for traffic urgency. When scheduling STAs for uplink transmission in the R-TWT service period, the AP can schedule those STAs whose traffic has a higher urgency. As an example, if three STAs provide traffic urgency indications to the AP - STA1's packet expires within 10 ms, STA2's packet expires within 1 ms, and STA3's packet expires within 40 ms, the AP can schedule STA2, then STA1, and then STA4 for transmission.

[0112] According to one embodiment, when making any scheduling decision (e.g., for triggering uplink transmission), the AP may give higher priority to STAs with higher urgency packets. Similar to the example provided above, if three STAs provide traffic urgency indications, the AP may first trigger STA2 for uplink transmission, followed by STA1, and then STA4.

[0113] Fig.12 A flowchart of a wireless communication method 1200 performed by a non-AP device including a first STA according to an embodiment of the present disclosure is shown. Fig.12 The embodiment of the wireless communication method 1200 performed by a non-AP device including a first STA shown in FIG. 1 is for illustration only. Other embodiments of the wireless communication method 1200 performed by a non-AP device including a first STA may be used without departing from the scope of the present disclosure.

[0114] like Fig.12 As shown, method 1200 begins at step 1210, where a non-AP device forms a link with a first AP. At step 1220, the non-AP device sends information associated with traffic transmission to the first AP, the information including scheduling parameters configured to help the first AP make scheduling decisions. At step 1230, the non-AP device receives data associated with the scheduling parameters from the first AP. At step 1240, based on the received data, the non-AP device determines to send traffic transmission to the first AP.

[0115] In one embodiment, the scheduling parameters include timing parameters associated with the timing information.

[0116] In one embodiment, the timing parameters include: the duration that the packets transmitted by the traffic will be kept in the STA queue, or the time until the delay bound of the packets transmitted by the traffic is not exceeded; or the packet enqueue time associated with the time when the packets transmitted by the traffic are enqueued at the STA.

[0117] In one embodiment, the non-AP device determines whether the scheduling parameter is associated with an existing measurement request and response frame; and sends the scheduling parameter based on the scheduling parameter being associated with the existing measurement request and response frame.

[0118] In one embodiment, the non-AP device determines whether the scheduling parameter is associated with the independent frame; and transmits the scheduling parameter based on the scheduling parameter being associated with the independent frame.

[0119] In one embodiment, the non-AP device determines whether the scheduling parameter is associated with a subfield in the independent frame; and transmits the scheduling parameter based on the scheduling parameter being associated with the subfield in the independent frame.

[0120] In one embodiment, the non-AP device determines whether the scheduling parameter is associated with the buffer status report; and sends the scheduling parameter based on the scheduling parameter being associated with the buffer status report.

[0121] In one embodiment, the non-AP device determines whether the scheduling parameter is associated with a control subfield variant of the A-Control subfield; and sends the scheduling parameter based on the scheduling parameter being associated with the control subfield variant of the A-Control subfield.

[0122] In one embodiment, the non-AP device is a non-AP multi-link device (MLD), the first STA is one of multiple STAs in the non-AP MLD, and the AP is one of multiple APs in the AP MLD, wherein the non-AP device forms a link with a corresponding AP of the AP MLD, sends information associated with traffic transmission to the corresponding AP, the information including scheduling parameters configured to help the corresponding AP make scheduling decisions, receives data associated with the scheduling parameters from the AP MLD, and determines to send traffic transmission to the AP MLD through a link between the non-AP MLD and the AP MLD based on the received data.

[0123] In one embodiment, the information includes an explicit link identification indication, where the explicit link identification indication is used to indicate which link between the non-AP MLD and the AP MLD the information corresponds to.

[0124] The above flow charts illustrate example methods that can be implemented according to the principles of the present disclosure, and various changes can be made to the methods or processes shown in the flow charts. For example, although shown as a series of steps, the individual steps can overlap, occur in parallel, occur in different orders, or occur multiple times. In another example, a step can be omitted or replaced by another step.

[0125] Although the present disclosure has been described with exemplary embodiments, various changes and modifications may be conceived by those skilled in the art. The present disclosure is intended to cover these changes and modifications that fall within the scope of the appended claims. Any description in this application should not be understood to mean that any particular element, step or function is an essential element that must be included in the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A non-access point (AP) device, comprising: The first station (STA) includes: The transceiver is configured as: Forming a link with the first AP, sending information associated with traffic transmission to the first AP, the information comprising scheduling parameters configured to assist the first AP in making scheduling decisions, and receiving data associated with the scheduling parameters from the first AP; and A processor is operably coupled to the first STA, the processor being configured to determine to send the traffic transmission to a first AP based on the received data.

2. The non-AP device according to claim 1, wherein: The scheduling parameters include timing parameters associated with timing information.

3. The non-AP device according to claim 1 or 2, wherein: The timing parameters include: The duration for which packets of the flow transmission will be held in the STA queue, or until a delay bound for the packets of the flow transmission is not exceeded; or A packet enqueue time associated with a time at which a packet of the flow transmission is enqueued at the STA.

4. A non-AP device according to any one of the preceding claims, wherein: The processor is configured to determine whether the scheduling parameters are associated with an existing measurement request and response frame, and The transceiver is configured to send the scheduling parameter based on associating the scheduling parameter with the existing measurement request and response frame.

5. A non-AP device according to any one of the preceding claims, wherein: The processor is configured to determine whether the scheduling parameter is associated with an independent frame, and The transceiver is configured to transmit the scheduling parameter based on associating the scheduling parameter with the independent frame.

6. A non-AP device according to any one of the preceding claims, wherein: The processor is configured to determine whether the scheduling parameter is associated with a subfield in an independent frame, and The transceiver is configured to transmit the scheduling parameter based on associating the scheduling parameter with a subfield in the independent frame.

7. A non-AP device according to any one of the preceding claims, wherein: The processor is configured to determine whether the scheduling parameter is associated with a buffer status report, and The transceiver is configured to send the scheduling parameter based on associating the scheduling parameter with the buffer status report.

8. A non-AP device according to any one of the preceding claims, wherein: The processor is configured to determine whether the scheduling parameter is associated with a control subfield variant of an A-Control subfield, and The transceiver is configured to transmit the scheduling parameter based on associating the scheduling parameter with the control subfield variant of an A-Control subfield.

9. A non-AP device according to any one of the preceding claims, wherein: The non-AP device is a non-AP multi-link device (MLD), The first STA is one of the multiple STAs in the non-AP MLD, The AP is one of the multiple APs in the AP MLD, Each of the plurality of STAs comprises a transceiver, wherein the transceiver is configured to: Form a link with the corresponding AP of AP MLD, sending information associated with traffic transmission to the corresponding AP, the information including scheduling parameters configured to help the corresponding AP make scheduling decisions, and receiving data associated with the scheduling parameters from the AP MLD; as well as A processor is operably coupled to the plurality of STAs, the processor being configured to determine, based on the received data, to send the traffic transmission to the AP MLD via a link between the non-AP MLD and the AP MLD.

10. A non-AP device according to any one of the preceding claims, wherein: The information includes an explicit link identification indication, where the explicit link identification indication is used to indicate which link between the non-AP MLD and the AP MLD the information corresponds to.

11. A wireless communication method performed by a non-access point (AP) device including a first station (STA), the method comprising: forming a link with a first AP; sending information associated with traffic transmission to the first AP, the information comprising scheduling parameters configured to help the first AP make a scheduling decision; receiving data associated with the scheduling parameters from the first AP; as well as Based on the received data, determine to send the traffic transmission to the first AP.

12. The method according to claim 11, wherein: The scheduling parameters include timing parameters associated with timing information.

13. The method according to claim 11 or 12, further comprising: determining whether the scheduling parameter is associated with an independent frame; as well as The scheduling parameter is sent based on associating the scheduling parameter with the independent frame.

14. The method according to any one of claims 11 to 13, further comprising: determining whether the scheduling parameter is associated with a buffer status report; as well as The scheduling parameter is sent based on associating the scheduling parameter with the buffer status report.

15. The method according to any one of claims 11 to 14, further comprising: determining whether the scheduling parameter is associated with a control subfield variant of the A-Control subfield; as well as The scheduling parameters are sent based on associating the scheduling parameters with the control subfield variant of the A-Control subfield.

Images