Apparatus and method for traffic delay information request and traffic offset alignment

Abstract

Embodiments of the present disclosure provide methods and apparatus for obtaining timing information and performing time offset adjustment for target wake time (TWT) operations in a wireless network. The apparatus includes a first communication device that includes a transceiver and a processor operably coupled to the transceiver. The transceiver is configured to transmit, during a target wake time (TWT) setup phase, a TWT element including a request for information about a traffic delay of a second communication device, and receive the information about the traffic delay. The processor is configured to determine a time offset for adjusting a start time of a next TWT interval based on the information about the traffic delay.

Description

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 127,776, filed December 18, 2020; U.S. Provisional Patent Application No. 63 / 208,298, filed June 8, 2021; U.S. Provisional Patent Application No. 63 / 279,950, filed November 16, 2021; and U.S. Patent Application No. 17 / 643,146, filed December 7, 2021. The contents of the foregoing patent documents are incorporated herein by reference. Technical Field

[0002] This disclosure generally relates to power management in wireless communication systems. Embodiments of this disclosure relate to methods and apparatus for determining traffic offset alignment for a target wake-up time configuration for communication in a wireless local area network communication system. Background Technology

[0003] As the standardization process for the next generation of IEEE 802.11 Wireless Local Area Networks (WLANs), namely the IEEE 802.11ax amendments, enters its final stages, the IEEE 802.11ax amendments are attracting attention from the information technology (IT) industry. It introduces new features to improve peak throughput and efficiency in environments with many 802.11 devices in congested conditions. Example environments include airports and stadiums. The Wi-Fi Alliance (WFA) has launched the Wi-Fi 6 certification program to ensure interoperability between certified products that implement the IEEE 802.11ax amendments. In the market, device manufacturers have begun releasing Wi-Fi 6 certified smart mobile devices.

[0004] Target Wake Time (TWT) is a key feature of the IEEE 802.11ax amendments. TWT enables wake-up time negotiation between an access point (AP) and associated stations (STAs) to improve power efficiency. Using TWT, a STA only needs to wake up at a pre-scheduled time negotiated with another STA or AP in the network. In the IEEE 802.11ax standard, two types of TWT operations are possible—individual TWT operations and broadcast TWT operations. Individual TWT agreements can be established between two STAs or between a STA and an AP. On the other hand, using broadcast TWT operations, an AP can establish a shared TWT session for a group of STAs.

[0005] Negotiated parameters such as wake-up interval, wake-up duration, and initial wake-up time (offset) significantly impact latency, throughput, and power efficiency, which are directly related to QoS (Quality of Service) or customer experience. Services with different traffic characteristics will require different TWT parameter configurations to achieve better QoS. Furthermore, TWT configurations should adapt to changes in network and service conditions.

[0006] TWT allows non-AP STAs to wake up only at a specified time, thereby reducing power consumption. Some applications (e.g., cloud gaming, AR glasses) can have periodic bursts of traffic with very strict latency requirements. When a TWT is established by a non-AP STA, the STA may not have traffic latency information at the AP (i.e., the arrival time of downlink traffic). This results in a large delay between the arrival time of downlink traffic and the start time of the TWT service period (SP). This can severely impact latency-sensitive applications. If a non-AP STA has information about the traffic latency at the AP, it can adjust its TWT parameters accordingly and thus better support TWT traffic.

[0007] Multilink Operation (MLO) is another key feature currently being developed by IEEE 802.11be, the standards body for next-generation Ultra High Throughput (EHT) Wi-Fi systems. Wi-Fi devices that support MLO are called Multilink Devices (MLDs). Using MLO, a non-AP MLD can discover, authenticate, associate, and establish multiple links with an AP MLD. Channel access and frame switching are possible on each link between the AP MLD and non-AP MLDs.

[0008] When a TWT agreement is established on one or more links between an AP MLD and a non-AP MLD, a non-AP STA attached to the non-AP MLD requesting the TWT may not have traffic latency information at its peer STA attached to the AP MLD. Using this traffic latency information, the non-AP STA attached to the non-AP MLD can select appropriate TWT parameters to support low-latency traffic on multiple links. Summary of the Invention

[0009] Various embodiments of this disclosure provide methods and apparatus for obtaining timing information in a wireless network (e.g., WLAN) and performing time offset adjustments for Target Wake-Up Time (TWT) operations.

[0010] In one embodiment, a first communication device is provided, including a transceiver and a processor operatively coupled to the transceiver. The transceiver is configured to transmit a TWT element during a Target Wake-Up Time (TWT) setup phase, the TWT element including a request for information regarding traffic delay of a second communication device, and receiving information regarding the traffic delay. The processor is configured to determine a time offset for adjusting the start time of the next TWT interval based on the information regarding the traffic delay.

[0011] In another embodiment, a method performed by a first communication device is provided, comprising the steps of: sending a TWT element during a Target Wake-Up Time (TWT) setup phase, the TWT element including a request for information about traffic delay of a second communication device, receiving information about the traffic delay, and determining a time offset for adjusting the start time of the next TWT interval based on the information about the traffic delay.

[0012] In another embodiment, a second communication device including a transceiver is provided. The transceiver is configured to receive TWT elements during a Target Wake-up Time (TWT) setup phase, the TWT elements including a request for information about traffic delay of the second communication device, and the transmission of information about traffic delay. A time offset for adjusting the start time of the next TWT interval is determined based on the information about traffic delay.

[0013] Other technical features will be obvious to those skilled in the art based on the following figures, description and claims.

[0014] 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, whether or not 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 to, able to communicate with, cooperate with, interleaved, juxtaposed, 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 may be implemented in hardware or a combination of hardware and software and / or firmware. The functionality associated with any particular controller may be centralized or distributed, local or remote. When used with a list of items, the phrase “at least one of…” means that different combinations of one or more of the listed items can be used, and 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 corresponding components from one other component without otherwise limiting the components (e.g., importance or order). It should be understood that if an element (e.g., a first element) is referred to as “coupled to,” “coupled to,” “connected to,” or “connected to” another element, with or without the terms “operably” or “communically”, it means that the element can be coupled to the other element directly (e.g., wired), wirelessly, or via a third element.

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

[0016] 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 excludes wired, wireless, optical, or other communication links that transmit transient electrical or other signals. Non-transitory computer-readable media includes media capable of permanently storing data and media capable of storing data and later rewriting it, such as rewritable optical discs or erasable memory devices.

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

[0018] 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:

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

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

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

[0022] Figure 3 A diagram illustrating packet exchange between devices according to an embodiment of the present disclosure;

[0023] Figure 4 Example TWT parameter set fields for TWT parameter negotiation according to various embodiments of the present disclosure are shown;

[0024] Figure 5 Offsets in a TWT session according to various embodiments of this disclosure are shown;

[0025] Figure 6Example TWT information frames according to various embodiments of the present disclosure are shown;

[0026] Figure 7 Examples of early termination of TWT according to various embodiments of this disclosure are shown;

[0027] Figure 8 Examples of bursty and generally periodic data traffic from a file download application are shown according to embodiments of this disclosure;

[0028] Figure 9 Examples of TWT delays with and without offset alignment according to various embodiments of the present disclosure are shown;

[0029] Figure 10 Example control field formats for TWT elements according to various embodiments of this disclosure are shown;

[0030] Figure 11A This illustrates another example control field format and an example individual TWT parameter set field format for a TWT element according to various embodiments of the present disclosure;

[0031] Figure 11B Another example control field format of a TWT element according to various embodiments of this disclosure is shown;

[0032] Figure 12 Another example control field format of a TWT element according to various embodiments of this disclosure is shown;

[0033] Figure 13 Another example control field format of a TWT element according to various embodiments of this disclosure is shown;

[0034] Figure 14 Example traffic delay information elements are shown according to embodiments of the present disclosure;

[0035] Figure 15 An example traffic delay information control frame is shown according to an embodiment of the present disclosure;

[0036] Figure 16 Example exchanges of TWT requests and TWT responses according to various embodiments of this disclosure are shown;

[0037] Figure 17 Example control field formats and example individual TWT parameter set fields of TWT elements according to various embodiments of the present disclosure are shown;

[0038] Figure 18 Another example control field format and another example individual TWT parameter set field of a TWT element according to various embodiments of the present disclosure are shown;

[0039] Figure 19Example integrated traffic delay request IE is shown according to various embodiments of this disclosure;

[0040] Figure 20 Example traffic delay response IEs are shown according to various embodiments of this disclosure;

[0041] Figure 21 Examples are shown of SCS request and response frames in the 802.11 standard that include traffic delay information request and response IEs according to various embodiments of the present disclosure;

[0042] Figure 22 The illustration shows data arrival and data transmission at a TWT Responding STA according to various embodiments of the present disclosure, including examples of dedicated frames for sending timing information from the TWT Responding STA to the TWT Requesting STA;

[0043] Figure 23 Example process flows for determining TWT offset adjustments according to various embodiments of this disclosure are shown;

[0044] Figure 24 The TCP timestamp format (i.e., timestamp information in TCP) according to various embodiments of the present disclosure is illustrated.

[0045] Figure 25 Different offset adjustment directions are shown according to various embodiments of this disclosure;

[0046] Figures 26-27 Example procedures for performing TWT offset adjustment based on round-trip time obtained from TCP timestamp information, according to various embodiments of this disclosure, are shown.

[0047] Figure 28 Examples of TWT offset alignment in the context of flow density-based offset alignment are shown according to various embodiments of the present disclosure;

[0048] Figures 29-30 A state machine representing an example process for TWT offset adjustment based on flow density, according to various embodiments of the present disclosure, is shown.

[0049] Figure 31 Example procedures for obtaining timing information and adjusting offsets for the execution time of a TWT operation, according to various embodiments of the present disclosure, are shown.

[0050] Figure 32 Example delay information element formats according to various embodiments of this disclosure are shown;

[0051] Figure 33 Examples of multi-link delay information element formats according to various embodiments of this disclosure are shown;

[0052] Figure 34 Example low-latency QoS control field formats are shown according to various embodiments of the present disclosure; and

[0053] Figure 35 Examples of multi-link low-latency delay information element formats are shown according to various embodiments of the present disclosure. Detailed Implementation

[0054] The following discussion Figures 1 to 31 The various embodiments described in this patent document to illustrate the principles of this disclosure 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.

[0055] The embodiments of this disclosure recognize that TWT operations between STAs in a WLAN can introduce latency if packets are ready to be transmitted before the start time of the next TWT interval. However, in order for the receiving STA to negotiate the start time of the next TWT interval that is correctly aligned with the time when packets are ready to be transmitted from the sending STA, the receiving STA needs to know timing information related to when packets arrive at the sending STA.

[0056] Accordingly, embodiments of this disclosure provide apparatus and methods that enable the receiving STA to request timing information from the transmitting STA and to generate timing offset adjustments for TWT operations based on the timing information at the transmitting STA, thereby reducing the latency caused by the TWT operations.

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

[0058] 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 (STAs) 111-114 within its coverage area 120. APs 101-103 can communicate with each other and with STAs 111-114 using Wi-Fi or other WLAN communication technologies.

[0059] 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 remote terminals. In a WLAN, assuming that the AP also competes for the wireless channel, the AP may also be referred to as a STA. Furthermore, 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 the wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile phone or smartphone) or a generally considered static device (such as a desktop computer, AP, media player, static sensor, television, etc.).

[0060] The dashed lines indicate the approximate extent of coverage areas 120 and 125, which 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, may 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.

[0061] As described in more detail below, one or more of the APs may include circuitry and / or programming for obtaining timing information in the WLAN and performing time offset adjustments for Target Wake Time (TWT) operation. Although Figure 1 An example of a wireless network 100 is shown, but more details can be found on other wireless networks. 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.

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

[0063] AP 101 includes multiple antennas 204a-204n, multiple RF transceivers 209a-209n, transmit (TX) processing circuitry 214, and receive (RX) processing circuitry 219. AP 101 also includes a controller / processor 224, a memory 229, and a backhaul or network interface 234. RF transceivers 209a-209n receive incoming RF signals from antennas 204a-204n, such as signals transmitted by STAs in network 100. RF transceivers 209a-209n down-convert the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to RX processing circuitry 219, which generates a processed baseband signal by filtering, decoding, and / or digitizing the baseband or IF signals. RX processing circuitry 219 sends the processed baseband signal to controller / processor 224 for further processing.

[0064] TX processing circuit 214 receives analog or digital data (such as voice data, web data, email, or interactive video game data) from controller / processor 224. TX processing circuit 214 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from TX processing circuit 214 and up-convert the baseband or IF signals into RF signals transmitted via antennas 204a-204n.

[0065] 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 reception of forward channel signals and the transmission of reverse channel signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 according to 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 the outgoing signals in a desired direction. The controller / processor 224 may also support OFDMA operations, wherein outgoing signals are allocated 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 obtaining timing information and performing time offset adjustments for TWT operations based on the obtained timing information. 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.

[0066] 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 via a wired or wireless local area network or via a wired or wireless connection to a larger network, such as the Internet. Interface 234 includes any suitable architecture supporting communication via wired or wireless connections, 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.

[0067] As described in more detail below, AP 101 may include circuitry and / or programming for obtaining timing information in the WLAN and performing time offset adjustments for TWT operations. Although Figure 2A An example of AP 101 is shown, but it is possible to compare it with other versions. Figure 2A Various modifications can be made. For example, AP 101 can include any number of... Figure 2AEach component 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. As another specific example, although shown as a single instance including TX processing circuitry 214 and a single instance including RX processing circuitry 219, AP 101 can include multiple instances of each (such as one per RF transceiver). Alternatively, it can include only one antenna and RF transceiver path, as in legacy APs. Moreover, Figure 2A The various components can be combined, further subdivided, or omitted, and additional components can be added as needed.

[0068] 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 come in a wide variety of configurations, and Figure 2B This disclosure is not intended to limit the scope to any particular implementation of STA.

[0069] STA 111 includes an antenna 205, a radio frequency (RF) transceiver 210, a TX processing circuit 215, a microphone 220, and a receive (RX) processing circuit 225. STA 111 also includes a speaker 230, a controller / processor 240, an input / output (I / O) interface (IF) 245, a touchscreen 250, a display 255, and memory 260. Memory 260 includes an operating system (OS) 261 and one or more applications 262.

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

[0071] TX processing circuitry 215 receives analog or digital voice data from microphone 220, or other outgoing baseband data (such as web data, email, or interactive video game data) from controller / processor 240. TX processing circuitry 215 encodes, multiplexes, and / or digitizes the outgoing baseband data to generate processed baseband or IF signals. RF transceiver 210 receives the outgoing processed baseband or IF signals from TX processing circuitry 215 and up-converts the baseband or IF signals into RF signals transmitted via antenna 205.

[0072] The controller / 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, the main controller / processor 240 controls the reception of forward channel signals and the transmission of reverse channel signals by the RF transceiver 210, RX processing circuitry 225, and TX processing circuitry 215 according to known principles. The main controller / processor 240 may also include processing circuitry configured to provide timing information in the WLAN and perform time offset adjustments for TWT operations. In some embodiments, the controller / processor 240 includes at least one microprocessor or microcontroller.

[0073] The controller / processor 240 is also capable of executing other processes and programs residing in the memory 260, such as operations for obtaining timing information in the WLAN and performing time offset adjustments for TWT operations. The controller / processor 240 is capable of moving data into or out of the memory 260 as needed for the execution process. In some embodiments, the controller / processor 240 is configured to execute multiple applications 262, such as an application for generating TWT elements that include a request for timing information from another STA, determining a time offset for adjusting the start time of the next TWT interval based on the timing information. The controller / processor 240 is capable of operating the 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 an I / O interface 245, which provides the STA 111 with the ability to connect to other devices such as laptop computers and handheld computers. The I / O interface 245 is the communication path between these accessories and the main controller 240.

[0074] The controller / processor 240 is also coupled to the touchscreen 250 and the display 255. The operator of STA 111 can use the touchscreen 250 to input data into STA 111. The display 255 may be a liquid crystal display, a light-emitting diode display, or other display capable of rendering text and / or at least limited graphics from a website. Memory 260 is coupled to the controller / processor 240. A portion of memory 260 may include random access memory (RAM), and another portion of memory 260 may include flash memory or other read-only memory (ROM).

[0075] although Figure 2B An example of STA 111 is shown, but it is possible to compare it with other models. 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 may include any number of antennas 205 for MIMO communication with AP 101. In another example, STA 111 may not include voice communication, 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). Furthermore, although... Figure 2B The STA 111 is shown to be configured as a mobile phone or smartphone, but the STA can be configured to operate as other types of mobile or fixed devices.

[0076] Figure 3 A diagram illustrating packet switching between devices according to an embodiment of the present disclosure is shown. For the purposes of this disclosure, the drawings will be discussed from the perspective of the STA, which may be STA 111, but it should be understood that it may be any suitable wireless communication device.

[0077] Figure 3 Two scenarios are illustrated where uplink (UL) and downlink (DL) communication packets (collectively referred to as traffic) are exchanged between an AP and an associated client STA. The first scenario involves no wake-up time negotiation between the AP and STA (e.g., as seen in top Figure 302); the second scenario involves wake-up time negotiation between the AP and STA (e.g., in an IEEE 802.11ax system and as seen in bottom Figure 304). In top Figure 302, there is a regular flow of unbuffered traffic between the AP and STA, where UL packets are scattered among DL packets. In this scenario (i.e., without wake-up time negotiation), there is no option for the STA to enter a doze or power-saving state.

[0078] Conversely, in the bottom figure 304, wake-up time negotiation results in a coherent TWT session 306. Each TWT session 306 is defined as a time period from the beginning to the end of TWT interval 308. Each TWT session 306 includes two states: an active state 311 defined by the TWT service period (SP) duration 310 (during which the STA wakes up to communicate with the AP), and a power-saving state or dozing state 312 (during which the STA does not actively wake up or communicate with the AP). As a result of wake-up time negotiation, power efficiency at the STA is improved without adding too much latency or allowing the dropping of UL or DL ​​packets.

[0079] In wake-up time negotiation, the negotiated TWT parameters include the wake-up interval (e.g., TWT interval 308 for each TWT session 306), the wake-up duration (e.g., TWT SP duration 310 for each TWT session 306), and the initial wake-up time or offset (e.g., indicated by the TWT start time 314). These negotiated parameters have a significant impact on latency, throughput, and power efficiency, which are directly related to the QoS (Quality of Service) of the customer experience. Services with different traffic characteristics can have different TWT parameter configurations to achieve better QoS. Furthermore, the TWT configuration should adapt to changes in network and service state.

[0080] In some embodiments, the TWT parameter set field is used to negotiate TWT parameters. Figure 4 An example TWT parameter set field 400 for TWT parameter negotiation according to an embodiment of the present disclosure is shown. The TWT agreement is initiated by the STA sending a TWT negotiation request to the AP. Once a TWT agreement is made between the AP and the STA, the STA periodically wakes up to communicate with the AP, wherein the interval between successive wake-up times is jointly specified by the TWT wake-up interval mantissa 402 and the TWT wake-up interval index 404 subfields in the TWT parameter set field 400.

[0081] The target wake-up time 406 and nominal minimum TWT wake-up duration 408 subfields specify the first wake-up time of the TWT agreement, and the time the STA must wait before entering a dormant state if it has not sent any traffic after the wake-up time. Figure 3 The duration of TWT SP is 310.

[0082] Besides the wake-up interval and wake-up duration, offset is also an important factor affecting user experience because offset can affect latency. Figure 5The diagram illustrates an offset in a TWT session according to an embodiment of this disclosure. Different offsets 502 introduce different additional TWT-related delays. The TWT interval 308 and offset 502 together define the additional delay introduced by the TWT. After the TWT negotiation is established, offset 502 can be... Figure 6 The field “Next TWT” 602 in the example TWT information frame 600 shown in the figure is adjusted.

[0083] Figure 7 An example of early termination of a TWT according to an embodiment of this disclosure is shown. In various embodiments, the actual TWT SP duration 310 is dynamically determined during runtime by the aforementioned nominal minimum TWT wake-up duration, and the STA enters a dozing state 312 when a packet is received with the ESP (End of Service) bit set to "1" or more data bits set to "0". The time at which the STA enters the dozing state 312 will vary slightly depending on whether early termination is supported. As shown in FIG702, if the STA supports early termination, the STA can enter the dozing state 312 as soon as it receives a packet with the ESP bit set to "1" or more data bits set to "0" (although there may be a slight delay between receiving the packet and entering the dozing state 312). If the STA does not support early termination, it will wait until the TWT SP duration ends to enter the dozing state 312, as shown in FIG304.

[0084] In many applications, data traffic between the STA and AP is bursty and roughly periodic. Figure 8 An example of this type of data traffic from a file download application is shown. For Figure 8 The data types shown will introduce relatively large latency if the TWT solution only establishes the TWT interval and the TWT SP duration. For example, Figure 9 Examples of TWT delays with and without offset alignment according to various embodiments of this disclosure are shown. Delay 904 (about Figure 9 (As shown in the middle figure 902) is an example of this relatively large latency. On the other hand, if the TWT solution is also aligned with the offset, the additional latency introduced by the TWT (i.e., as shown in the middle figure 902) is an example of this relatively large latency. Figure 9 The offset 502 shown can be relatively small. For example, Figure 9 Figure 906 illustrates reducing or eliminating offset alignment at offset 502. Timing information of the traffic flow is required to align the offset. Such timing information can include information about traffic delay 908.

[0085] Traffic delay can be defined as the time (TSF) between when a packet arrives at the AP / non-AP STA (e.g., when a packet arrives at the MAC layer from a higher layer) and the time (TSF) when the packet is successfully transmitted by the AP / non-AP STA. This delay is determined based on queuing delays at the AP / non-AP STA, contention time, delays to other STAs, and the number of retransmissions (e.g., due to collisions on the radio channel). Alternatively, traffic delay can be defined as the delay between the time (TSF) when a packet arrives from a higher layer and the time (TSF) when the packet is accepted by the MAC layer. Other definitions of traffic delay are also possible.

[0086] This information can be useful for STAs in many applications, including TWT timing offset alignment, enabling TWT operation to support latency-sensitive applications. Furthermore, understanding traffic latency and its components can be useful when making multiple decisions such as channel selection and AP selection. Specifically, traffic latency information can be used to develop metrics to understand the extent to which downlink traffic is blocked for non-AP STAs. If downlink traffic is heavily blocked, non-AP STAs can initiate changes in operating modes (e.g., by switching to an alternative channel / band, switching to a different AP, etc.) to reduce performance degradation.

[0087] Embodiments of this disclosure provide methods that enable either an AP STA or a non-AP STA to request traffic delay information. Hereinafter, the STA sending the traffic delay information request is referred to as the TWT requesting STA, and the STA requesting the traffic delay information is referred to as the TWT responding STA.

[0088] TWT operations allow adjustment of the TWT SP start time alignment using TWT constraint parameter elements or TWT information frames. In 802.11, the Start Target Wake-up Time Alignment field within the TWT constraint parameter element contains a positive integer n, indicating the recommended start time for the first TWT SP used in the TWT agreement. Therefore, the target wake-up time is recommended to be an integer multiple of (n+1). However, without knowing the traffic delay information on the TWT response STA side, the TWT request STA cannot properly set (recommended) TWT parameters.

[0089] For example, if the TWT requesting STA does not have any information about the latency faced by the traffic at the TWT response STA, the TWT requesting STA may not be able to select an appropriate target wake-up time in the TWT elements sent from the TWT requesting STA to the TWT response STA while establishing the TWT agreement. This results in a large delay between the time the traffic arrives at the TWT response STA and the time the TWT SP begins. Without a proper timing offset (between the traffic arrival time and the TWT SP start time), the latency introduced by TWT operation can be relatively large and may not meet the application's stringent latency requirements. With proper timing offset alignment using the traffic arrival information on the TWT requesting STA side, TWT operation can achieve low power consumption while meeting the low latency requirements of periodic traffic. This makes it possible to apply TWT operation to applications with very stringent latency requirements. Therefore, it can bring significant benefits to battery-powered devices such as augmented reality / virtual reality (AR / VR) glasses.

[0090] exist Figure 9 In the example, the TWT requesting STA wants to establish a TWT agreement with the TWT responding STA. Assume a scenario with latency-sensitive traffic where traffic arrival at the TWT responding STA is bursty and periodic. As shown in the top figure 910, traffic arrives at the TWT responding STA (at the MAC layer or MAC Service Access Point (SAP)) at time t0 (for packet 1) and time t3 (for packet 2). At the TWT responding STA, packets face a traffic (or packet) processing delay 908 (e.g., frame formatting, fragmentation / aggregation, queuing delay, scheduling delay, etc.). Packets 1 and 2 are ready to depart from the TWT responding STA at time t1 and time t4, respectively. The departure point can be at the PHY SAP. If the PHY layer processing delay can be estimated with sufficient accuracy, the departure point can also be after PHY processing and before over-the-air transmission. Therefore, the traffic delays 908 for the two packets are Δ1 = (t1 - t0) and Δ2 = (t4 - t3), respectively.

[0091] Without information about the traffic delay at the TWT response STA, the TWT request STA cannot select the appropriate target wake-up time field in the TWT element, and as a result, it establishes TWT agreements with TWT SP start times at t2 and t5 respectively. Accordingly, due to the misaligned TWT SP start times, this TWT agreement introduces additional delays of Δ3 = (t2-t1) and Δ4 = (t5-t4) respectively (i.e., offsets of 502). On the other hand, if the TWT request STA has information about how much traffic delay the packets incur on the TWT response STA side, the TWT request STA can appropriately set the target wake-up time field so that the TWT SP now starts for these two packets at times t1 and t4 respectively. This will meet the application's latency requirements while reducing the power consumption of the TWT operation.

[0092] For ease of explanation, in the following embodiments, both non-AP STAs and AP STAs will be simply referred to as STAs. However, it should be understood that both the TWT request STA and the TWT response STA can be either non-AP STAs or AP STAs. Furthermore, in the following embodiments, STAs are capable of indicating their ability to request or provide traffic delay information. A TWT request STA can request traffic delay information from a TWT response STA during the TWT setup process.

[0093] In some embodiments, if the TWT request STA aims to request traffic delay information from the TWT response STA for all traffic identifiers (TIDs), this traffic delay information request can be indicated by including an indication bit in the TWT element sent from the TWT request STA to the TWT response STA. This is in Figure 10 The example shown illustrates an example control field format 1000 for a TWT element according to an embodiment of this disclosure.

[0094] exist Figure 10 In this context, traffic delay information requests for all TIDs are indicated by the TWT request STA by including a "Traffic Delay Information Request" subfield 1002 in the control field of the TWT element. If the bit corresponding to the Traffic Delay Information Request subfield 1002 is set to zero, it indicates that the TWT request STA has not requested traffic delay information from the TWT response STA. Conversely, if the bit corresponding to the Traffic Delay Information Request subfield 1002 is set to 1, it indicates that the TWT request STA is seeking traffic delay information from the TWT response STA. Figure 10 In the example, bit 6 (B6) is used to indicate a traffic delay information request. In another embodiment, bit 7 (B7) can also be used to indicate a traffic delay information request.

[0095] In some embodiments, the TWT requesting STA may request traffic delay information from the TWT response STA only for a selection of TIDs. A TID bitmap can be used by the TWT requesting STA to indicate the TIDs for which traffic delay information is requested. This is in Figure 11A The example shown illustrates another example control field format 1100 and an example individual TWT parameter set field format 1101 for a TWT element.

[0096] exist Figure 11A In the TWT element, the "Traffic Delay Information Request TID Bitmap Existence" subfield 1102 in the control field can indicate the existence of such a TID bitmap for the TWT requesting the STA to request traffic delay information. If the "Traffic Delay Information Request TID Bitmap Existence" subfield 1102 in the control field of the TWT element is set to 1, it indicates that a TID bitmap exists in the TWT element to indicate the TID for which traffic delay information is requested, and in this case, the "Traffic Delay Information Request TID Bitmap" subfield 1104 in the individual TWT parameter set field 1101 contains the corresponding TID bitmap. If the bit corresponding to the k-th position in the "Traffic Delay Information Request TID Bitmap" subfield 1104 is set to 1, it indicates that traffic delay information is requested for the k-th TID. If the bit is set to 0, it indicates that traffic delay information is not requested for the k-th TID. In some embodiments, the traffic delay information request subfield 1002 is ignored when both the traffic delay information request subfield 1002 and the traffic delay information request TID bitmap existence subfield 1102 exist in the control field of the TWT element (e.g., in example control field format 1100).

[0097] exist Figure 11A In the example, the Traffic Delay Information Request (TID) bitmap presence subfield 1102 is indicated by bit 7 (B7) of the control field of the TWT element. In this case, the Traffic Delay Information Request subfield 1002 will be indicated by bit 6 (B6) of the control field of the TWT element. In other embodiments, the Traffic Delay Information Request (TID) bitmap presence subfield 1102 may be indicated by bit 6 (B6) of the control field of the TWT element. In this case, the Traffic Delay Information Request subfield 1002 will be indicated by bit 7 (B7) of the control field of the TWT element.

[0098] In some embodiments, even if the Traffic Delay Information Request (TID) bitmap presence subfield is not present in the control field of the TWT element, the TID bitmap presence subfield can still exist in the control field of the TWT element (indicated by bit 6 or bit 7 of the control field), and will accordingly indicate that the TID bitmap presence subfield exists in the individual TWT parameter set field. This is in Figure 11B The example control field format 1103 is shown, in which there is a traffic delay information request TID bitmap with subfield 1102 but no traffic delay information request subfield 1002.

[0099] In some embodiments, upon receiving a traffic delay information request from the TWT request STA (e.g., when the traffic delay information request in the received TWT element is 1), the TWT response STA will provide the requested traffic delay information to the TWT request STA. That is, the TWT response STA will provide traffic delay information for all TIDs to the TWT request STA.

[0100] In other embodiments, upon receiving a traffic delay information request from the TWT request STA (e.g., when the traffic delay information request in the received TWT element is 1), the TWT response STA may decide whether to accept the traffic delay information request received from the TWT request STA.

[0101] In some such embodiments, the TWT response STA can use the same control field format of the TWT element as the TWT request STA, via indicator bits corresponding to the traffic delay information request subfield, to indicate acceptance or rejection of the TWT traffic delay information request. For example, using Figure 10 The control field format is 1000. A traffic delay information request of 0 in the TWT element sent from the TWT response STA indicates that traffic delay information requests from the TWT request STA for all requested TIDs will be rejected. Conversely, a traffic delay information request of 1 in the TWT element sent from the TWT response STA indicates that traffic delay information requests from the TWT request STA for all requested TIDs will be accepted.

[0102] In other embodiments, the TWT Response STA can indicate acceptance or rejection of a TWT traffic delay information request by including a "Accept Traffic Delay Information Request" subfield in the control field of the TWT element sent from the TWT Response STA. This is in Figure 12Example control field format 1200 is shown, which includes an accept traffic delay information request subfield 1202. For example, accept traffic delay information request = 0 in a TWT element sent from a TWT response STA will indicate that traffic delay information requests from the TWT request STA for all requested TIDs are rejected. Accept traffic delay information request = 1 in a TWT element sent from a TWT response STA will indicate that traffic delay information requests from the TWT request STA for all requested TIDs are accepted.

[0103] exist Figure 12 In the example, the Traffic Delay Information Request subfield 1002 is indicated by bit 6 (B6) of the control field of the TWT element, and the Accept Traffic Delay Information Request subfield 1202 is indicated by bit 7 (B7) of the control field of the TWT element. In other embodiments, the Traffic Delay Information Request subfield can be indicated by bit 7 (B7) of the control field of the TWT element, while the Accept Traffic Delay Information Request subfield can be indicated by bit 6 (B6) of the control field of the TWT element. In these embodiments (i.e., when the Accept Traffic Delay Information Request subfield is present), if the TWT element is sent by the TWT Request STA, the Accept Traffic Delay Information Request subfield 1202 is ignored. If the TWT element is sent by the TWT Response STA, the Traffic Delay Information Request subfield 1002 is ignored.

[0104] In some embodiments where the TWT response STA can decide whether to accept a traffic delay information request received from the TWT request STA, the TWT response STA can accept a traffic delay information request only for a subset of the requested TIDs. The accepted TIDs can be indicated by the TID bitmap included in the TWT element sent from the TWT response STA. This is illustrated in another example control field format 1300 of the TWT element. Figure 13 As shown in the image.

[0105] exist Figure 13In the TWT element, the "Accept Traffic Delay Information Request TID Bitmap Existence" subfield 1302 in the control field indicates the existence of a TID bitmap for which a traffic delay information request has been accepted by the TWT response STA. If the "Accept Traffic Delay Information Request TID Bitmap Existence" subfield 1302 is set to 1 in the TWT element's control field, it indicates that the "Accept Traffic Delay Information Request TID Bitmap Existence" subfield is included in the individual TWT parameter set field of the TWT element to indicate the TID for which a traffic delay information request has been accepted. If the bit corresponding to the k-th position in the "Accept Traffic Delay Information Request TID Bitmap Existence" subfield is set to 1, it indicates that a traffic delay information request is accepted for the k-th TID. If the bit is set to 0, it indicates that a traffic delay information request is not accepted for the k-th TID.

[0106] The presence of the Accept Traffic Delay Information Request (TID) bitmap subfield can be indicated by bit 6 (B6) or bit 7 (B7) of the control field of the TWT element. In some embodiments, both the Accept Traffic Delay Information Request (TID) bitmap presence subfield 1302 and the Accept Traffic Delay Information Request subfield 1202 exist in the control field of the TWT element. In some such embodiments, the Accept Traffic Delay Information Request subfield 1202 is ignored.

[0107] In some embodiments, if the TWT Response STA accepts a traffic delay information request from the TWT Request STA according to one of the above embodiments, the TWT Response STA can provide traffic delay information to the TWT Request STA by sending a "traffic delay information" element in the TWT Setup frame or any other frame sent to the TWT Request STA. The traffic delay information element will contain the necessary traffic delay information, allowing the TWT Request STA to adjust TWT parameters at runtime to minimize latency.

[0108] Figure 14 An example traffic delay information element 1400 according to these embodiments is shown. Figure 14In the example, the "Traffic Delay Information Subfield Size" subfield 1402 determines the size of the traffic delay information subfield. The "Traffic Delay Information TID Bitmap" subfield 1404 contains a bitmap for the TIDs whose traffic delay information is included in the traffic delay information element. If the bit corresponding to the k-th position in the Traffic Delay Information TID Bitmap subfield 1404 is set to 1, it indicates that the traffic delay information for the k-th TID is included in the traffic delay information element 1400. If the bit is set to 0, it indicates that no traffic delay information is included for the k-th TID. The "Traffic Delay Information" subfield 1406 contains traffic delay information for different TIDs. For each TID, there can be two (or any other number) octets for the traffic delay information. In the traffic delay information subfield 1406, the octets for the traffic delay information for different TIDs are concatenated.

[0109] The TID for which traffic delay information is included in the traffic delay information subfield 1406 is indicated by the TID bitmap in the traffic delay information TID bitmap subfield 1404. For example, if the TID bitmap in the traffic delay information TID bitmap subfield 1404 is [011001000000000], it indicates that the traffic delay information subfield 1406 will contain traffic delay information for 3 TIDs (corresponding to 3 1s in the TID bitmap). In this example, if two octets are used to represent the traffic delay information for each TID, then the length of the traffic delay information subfield 1406 is 6 octets. The first two octets in the traffic delay information subfield 1406 will contain the traffic delay information corresponding to TID 2, the last two octets in the traffic delay information subfield 1406 will contain the traffic delay information corresponding to TID 3, and the last two octets in the traffic delay information subfield 1406 will contain the traffic delay information corresponding to TID 6.

[0110] In another embodiment, the traffic delay information subfield size subfield 1402 may not exist in the traffic delay information element 1400. In this case, the size of the traffic delay information subfield 1406 can be determined based on the number of 1s in the traffic delay information TID bitmap and the number of octets used to encapsulate the traffic delay information for each TID. For example, if the TID bitmap in the traffic delay information TID bitmap subfield 1404 is [0110011000000000] and two octets are used to represent the traffic delay information for each TID, then the size of the traffic delay information subfield 1406 is eight octets.

[0111] In some other embodiments where the TWT Response STA accepts a traffic delay information request from the TWT Request STA, the TWT Response STA may send a traffic delay information control frame to provide traffic delay information to the TWT Request STA. This traffic delay information control frame will contain the necessary traffic delay-related information from the TWT Request STA.

[0112] Figure 15 An example traffic delay information control frame 1500 according to these embodiments is shown. Figure 15 In the example, the traffic delay information subfield size subfield 1402, the traffic delay information TID bitmap subfield 1404, and the traffic delay information subfield 1406 in the traffic delay information control frame 1500 can be compared with the above-mentioned... Figure 14 The same as the traffic delay information element 1400.

[0113] Figure 16 Example exchanges of TWT requests and TWT responses according to various embodiments of this disclosure are shown. Figure 16 In this process, TWT Request STA 1602 sends TWT Request 1606 to TWT Response STA 1604. In the control field of the TWT element sent by TWT Request STA 1602, the Traffic Delay Information Request subfield is set to 1, indicating that TWT Request STA 1602 is seeking traffic delay information for all TIDs on the TWT Response STA side. In response to TWT Request 1606, TWT Response STA 1604 sends TWT Response 1608 and sets Accept Traffic Delay Information Request = 1 in the control field of the TWT element. A successful TWT agreement is established. At the beginning of each TWT SP 310, TWT Response STA 1604 provides Traffic Delay Information 1610 to TWT Request STA 1602 before DL data 1612 is sent.

[0114] In some embodiments involving MLO systems, traffic delay information requests can be made between AP MLDs and non-AP MLDs. A TWT request STA attached to a non-AP MLD can request traffic delay information from a TWT response STA attached to an AP MLD, and vice versa. Traffic delay information for multiple established links between AP MLDs and non-AP MLDs can be requested on a single established link (i.e., a link already established for multi-link operation) between an AP MLD and a non-AP MLD.

[0115] A link established on which a traffic delay request is made can be called a "negotiation link". In such embodiments, a TWT request STA attached to an MLD can request traffic delay information from a TWT response STA associated with the corresponding MLD on the negotiation link during the TWT establishment process. Accordingly, similar to the non-MLO embodiments described above, as part of the TWT establishment process, the TWT request STA attached to an MLD sends a TWT element to a TWT response STA associated with the corresponding MLD on the negotiation link.

[0116] In some embodiments, when a TWT request STA attached to an MLD includes a traffic delay information request = 1 in the TWT element sent on the negotiated link between the AP MLD and the non-AP MLD, it means that the TWT request STA is requesting traffic delay information for all established links between the AP MLD and the non-AP MLD.

[0117] In other embodiments, the TWT request STA attached to the MLD can indicate a subset of links being established between the AP MLD requesting traffic delay information and non-AP MLDs. The TWT request STA can include a link ID bitmap in the TWT element to indicate the subset of links for which it requests traffic delay information. This is in Figure 17 The example shown illustrates the example control field format 1700 of the TWT element and the example individual TWT parameter set field 1701 of the TWT element.

[0118] exist Figure 17 In the example, the "Traffic Delay Information Request Link ID Bitmap Existence" subfield 1702 in the control field of the TWT element can indicate the existence of such a link ID bitmap in the TWT element. If the "Traffic Delay Information Request Link ID Bitmap Existence" subfield is set to 1, it indicates that the link ID bitmap used for the traffic delay information request exists in the TWT element; otherwise, such a link ID bitmap does not exist in the TWT element. In one embodiment, if the "Traffic Delay Information Request Link ID Bitmap Existence" subfield 1702 is set to 1 in a TWT element sent by a TWT request STA attached to the MLD, then the link ID bitmap exists in the individual TWT parameter set field 1701 of the TWT element. The "Traffic Delay Information Request Link ID Bitmap" field 1704 in the individual TWT parameter set field 1701 maintains the link ID bitmap to indicate that the attached TWT request STA is requesting a subset of links between the AP MLD and non-AP MLD for which it requests traffic delay information. If a bit in the link ID bitmap corresponding to a link is set to 1, it indicates that traffic delay information is requested for that link; otherwise, traffic delay information is not requested for that link.

[0119] In some embodiments, when a traffic delay information request is received from a TWT request STA associated with an MLD for a subset of established links between AP MLDs and non-AP MLDs, the TWT response STA associated with the corresponding MLD sends traffic delay information on each requested established link (via TWT Traffic Delay Information IE or TWT Traffic Delay Information Control Field, as described above, or via any other appropriate message).

[0120] In other embodiments, when a traffic delay information request is received from a TWT request STA attached to an MLD for a subset of links established between AP MLDs and non-AP MLDs, the TWT response STA attached to the corresponding MLD may indicate acceptance or rejection of traffic delay information requests for some or all links in a TWT element sent from the TWT response STA via the negotiated link. The link ID bitmap can indicate the subset of links for which the request for traffic delay information was accepted. This is in... Figure 18 The example shown illustrates the example control field format 1800 and the example individual TWT parameter set field 1801 for a TWT element.

[0121] exist Figure 18 In the example, the “Accept Traffic Delay Information Request Link ID Bitmap Exists” subfield 1802 in the control field of the TWT element indicates whether a link ID bitmap exists to indicate a subset of links for which a traffic delay information request is accepted. If the “Accept Traffic Delay Information Request Link ID Bitmap Exists” subfield 1802 is set to 1, it indicates that a link ID bitmap exists in the TWT element; otherwise, a link ID bitmap does not exist in the TWT element. In one embodiment, if the “Accept Traffic Delay Information Request Link ID Bitmap Exists” subfield 1802 is set to 1 in a TWT element sent by a TWT response STA attached to an MLD, then the “Accept Traffic Delay Information Request Link ID Bitmap” field 1804 exists in the individual TWT parameter set field 1801, and the link ID bitmap is maintained to indicate a subset of links between APMLDs and non-AP MLDs for which a traffic delay information request is accepted. If a bit in the link ID bitmap corresponding to a link is set to 1, it indicates that a traffic delay information request is accepted for that link; otherwise, a traffic delay information request is not accepted for that link.

[0122] As an extension of the above embodiments, integrated traffic delay information can be requested by a non-AP STA or a STA attached to a non-AP MLD. The integrated traffic delay information can carry information about queuing delay, contention delay, delay, and receiver / transmitter (Rx / Tx) delay. The integrated traffic delay information can be requested by sending a request information element (IE) to the corresponding AP STA or a STA attached to the AP MLD. Figure 19 An example of a comprehensive traffic latency request IE1900 according to such an embodiment is shown. Figure 19 In the example, non-AP STAs can request aggregated traffic delay information for certain TIDs by indicating only certain TIDs in the TID bitmap subfield 1902.

[0123] In some embodiments, such as Figure 20 As shown in the example, the AP STA can send the requested aggregated traffic latency information to a non-AP STA in the traffic latency response IE within the response frame. Figure 20 In the example, the AP STA can include a TID bitmap subfield 2002 to maintain a TID bitmap that indicates which TIDs the information in each TID information field 2004 corresponds to. For each TID indicated in the TID bitmap, the corresponding aggregated traffic delay information can be included in each TID information field 2004 using format 2006. The aggregated traffic delay information for each TID in each TID information field 2004 can be included in the same order as the TIDs are marked in the TID bitmap.

[0124] In the various embodiments discussed above, request frames and response frames can also be used directly to request uplink traffic latency information. In some embodiments, request IEs and response IEs can be sent as separate frames. In other embodiments, request IEs and response IEs can be included as subfields in any request and response frame in the 802.11 standard. Figure 21 Examples of including a Traffic Delay Information Request IE and a Response IE in an 802.11 standard SCS request frame and response frame according to various embodiments of this disclosure are shown. As shown, a Traffic Delay Information Request IE 2102 can be included in the SCS descriptor element of the SCS request frame. The Traffic Delay Information Request IE can be generated by a TWT response AP or a non-AP STA (if the request corresponds to information about uplink traffic) and included in the SCS descriptor element of the SCS response frame in a similar manner.

[0125] In the various embodiments discussed above, traffic delay information can be sent by the TWT response STA in a dedicated frame. Figure 22Data arrival and data transmission at a TWT response STA according to various embodiments of the present disclosure are illustrated, including examples of dedicated frames for sending timing information from the TWT response STA to the TWT request STA. Figure 22 In the example, timing information frame 2202 is a dedicated frame for sending timing information (e.g., traffic delay information).

[0126] Depending on the layer processing the timing information, the timing information frame can be a MAC frame or an IP frame. If the frame is processed at the MAC layer, it can include a PHY layer header 2204, a MAC layer header 2206, a frame identifier 2208, and a timing information field 2210. If the frame is processed at the IP layer, it will add an IP header 2212 after the MAC header 2206. Here, the frame identifier 2208 is used to identify the timing information frame 2202. Additionally, the timing information field 2210 includes timing information. One format of the timing information can be the timing difference between the arrival time 2214 (downlink data arrives at the AP) and the transmission time 2216 (downlink data is sent from the AP to the STA) of the first data packet in the SP. Figure 22 Shown as L t This timing information format corresponds to the timing delay information discussed above.

[0127] Note that in the case of TWT request STA adjusting offset, only the packets from TWT response STA to TWT request STA are counted, because TWT request STA already knows the timing information from TWT request STA to TWT response STA. The second timing information format can be the average value L over the last N SPs. t In other embodiments, the timing information frame 2202 can be transmitted as the first packet of each SP, the last packet of each SP, or an intermediate packet of each SP.

[0128] After obtaining the timing information, TWT requests STA to use L t Determine TWT offset adjustment A t (Time offset used to adjust the start time of the next TWT interval). Figure 23 Example process flows for determining TWT offset adjustments according to various embodiments of this disclosure are shown. The first step 2302 will be based on L... t Estimate current delay L e，t In step 2304, if the estimated delay L... e，t > α, where α is a configurable variable indicating the fault tolerance level (e.g., α = 2ms), then STA calculates the offset adjustment A in step 2306. t and through Figure 6 The TWT information field shown is used to transfer A tApplied to the TWT function. If L e，t If the value is ≤α, it means the offset is already very small. Therefore, no offset adjustment is needed in step 2306.

[0129] For the current delay L e，t One option, I estimate, is to use the last N. e The average value L among SPs t Defined as:

[0130] L ave，t =avg(L t (1)

[0131] Another option is to use a weighted average. For values ​​L that are closer to the current time... t Assign a larger weight (ω) i >ω i-1 ),as follows:

[0132]

[0133] Another option is to use the exponential moving average, which can be defined as follows:

[0134] L ave，t =L ave，t-1 +θ(L t -L ave，t-1 (3)

[0135] Where θ is the attenuation rate of the exponential filter.

[0136] If condition L is satisfied ave，t If > a, then the offset adjustment can be calculated as follows:

[0137] A t =L ave，t +T oh (4)

[0138] Among them, T oh It is a constant used to account for the overhead of control frames and some other overhead.

[0139] The above embodiments detail feedback-based offset alignment, wherein an AP or STA (e.g., a TWT request STA) can obtain traffic arrival information through feedback of timing information from the corresponding STA or AP, and align the offset accordingly. In other embodiments, offset alignment can be performed based on different information.

[0140] In some such embodiments, offset alignment based on Transmission Control Protocol (TCP) timestamps can be performed by estimating round-trip times using timestamp information in TCP packets. Based on the estimated round-trip times, TWT offsets can be aligned. In other embodiments, offset alignment based on traffic density can be performed based on the knowledge that data packets have relatively large inter-packet arrival times when the offset is well aligned. Based on this characteristic, traffic density-based algorithms can be used to align TWT offsets.

[0141] Figure 24-27 An example related to offset alignment based on TCP timestamps is shown. The TCP protocol supports timestamp echoing, which can be used to estimate latency. Figure 24 This illustrates the TCP timestamp format (i.e., timestamp information in TCP). The first two fields are constants used to identify the timestamp information in the TCP frame. Timestamp 2402 is carried in two four-byte timestamp fields. The TSval field contains the current value of the TCP sender's timestamp clock. The TSecr field is valid if the ACK bit is set in the TCP header. If the ACK bit is not set in the outgoing TCP header, the sender of that segment should set the TSecr field to zero. When the ACK bit is set in the outgoing segment, the sender must echo back the most recently received TSval sent by the remote TCP in the TSval field.

[0142] Using the TCP timestamp format, an STA acting as a TCP server or client can estimate the round-trip time from the STA to the corresponding TCP client or server. If the AP is acting as a TCP server or client, it can also estimate the round-trip time between the STA and the AP.

[0143] For example, in the case of wireless VR / AR glasses communicating with a mobile phone, the phone acts as the access point (AP) and the VR / AR glasses act as the standby device (STA). The TCP traffic between the phone and the VR / AR glasses can be used by both parties to estimate the round-trip time (RTT). Because traffic may be unbalanced between the two devices, TSecr may not always be updated. For example, if DL traffic is much greater than UL traffic, many DL TCP packets will use the same TSecr. Therefore, when a new TSecr value (T...) is received... ecr，n Calculate the time delay. Estimate the round-trip time delay T. r，n It was identified as:

[0144] T r，n =T clock -T ecr，n (5)

[0145] Among them, Tclock It is the current value of the timestamp clock on the TCP receiver side.

[0146] Figure 25 Different offset adjustment directions are shown. If the TWT SP start time 2502 is shifted to an earlier time (e.g., time 2504), it is a negative offset adjustment. A positive offset adjustment corresponds to shifting the TWT SP start time to a later time (e.g., time 2506).

[0147] Figure 26-27 Example procedures for performing TWT offset adjustment based on round-trip time obtained from TCP timestamp information, according to various embodiments of this disclosure, are shown. Figure 26 During the process, in step 2602, within the time window T w Internal estimated round-trip time T r，n Take the average to obtain T ar，t , where t is the TWT SP index. When t = 0, an offset adjustment (e.g., a negative offset adjustment) is applied in the default adjustment direction with a predefined step size T0 (e.g., T0 = 5ms).

[0148] When t > 0, the process moves to decision box 2604, where T ar，t With T ar，t-1 Compare them. If the average latency has not changed significantly since the last adjustment (-K2≤T), then... ar，t -T ar，t-1 If the offset is ≤K1, where K1 and K2 are predefined positive numbers (e.g., K1 = K2 = 2ms), then no additional offset adjustment is required (step 2606). Alternatively, when the offset adjustment at t-1 is not adjusted (as in step 2606), the offset adjustment is applied in the default adjustment direction with a step size T0.

[0149] If in decision box 2604, the average latency has become significantly larger since the last adjustment (T) ar，t -T ar，t-1 If the average delay has become significantly smaller since the last adjustment (T > K1), then apply the offset adjustment in the opposite direction to the previous offset adjustment with a step size T0 (step 2608). ar，t -T ar，t-1 If <-K2), then apply the offset adjustment in the same direction as the previous offset adjustment with a step size T0 (step 2610).

[0150] exist Figure 27 In the substitution process, in step 2702, the application and Figure 26 The same process in step 2602 is performed within the time window T. w Internal estimated round-trip time Tr，n Take an average to obtain T ar，t Similarly, when t=0, an adjustment is applied in the default adjustment direction (e.g., applying negative offset adjustment) with a predefined step size T0 (e.g., T0=5ms). Figure 26 The same default offset adjustment applies.

[0151] When t > 0, the process moves to decision box 2704, where T ar，t With T ar，t-1 Compare (similar to decision box 2604). If the average latency has not changed significantly since the last adjustment (-K2≤T), then... ar，t -T ar，t-1 If K1 ≤ K2, where K1 and K2 are predefined positive numbers (e.g., K1 = K2 = 2ms), then no additional offset adjustment is needed (step 2706), similar to step 2606.

[0152] If in decision box 2704, the average latency has become significantly larger since the last adjustment (T) ar，t -T ar，t-1 If the average delay has become significantly smaller since the last adjustment (T > K1), then apply an offset adjustment in the positive direction with a step size T0 (step 2708). ar，t -T ar，t-1 If <-K2), then apply offset adjustment in the negative direction with step size T0 (step 2710).

[0153] Furthermore, in the above embodiments, the TWT interval can be adapted to the average round-trip time. If the maximum latency requirement of the application is L... rq Then the TWT interval can be set as:

[0154] I twt，t =max (L rq -T ar，t +T g I min (6)

[0155] Among them, T g It is a protection time constant, designed to prevent errors in the estimation of round-trip time delay, and I min It is the minimum TWT interval.

[0156] Figures 28-30 An example related to traffic density-based offset alignment is shown. In feedback-based offset alignment and TCP timestamp-based offset alignment, some explicit timing information is required. In traffic density-based offset alignment, no explicit timing information is needed. This solution can be applied to situations where the STA does not immediately enter a nap mode after sending buffered data.

[0157] Figure 28 Examples of TWT offset alignment in the context of flow density-based offset alignment are shown according to various embodiments of the present disclosure. Figure 28 As shown, given the same TWT interval 308 and TWT SP duration 310, the dense region 2802 corresponding to the buffered data is relatively small when the offset is better aligned. Therefore, the flow density can be used to estimate / calculate the TWT offset alignment.

[0158] The first step in traffic density-based offset alignment is to classify data into buffered and unbuffered data. Buffered data refers to data arriving at the AP or STA and awaiting processing before transmission. Unbuffered data refers to data arriving at the AP or STA and being processed immediately by the MAC layer for transmission. Inter-packet arrival time can be used to classify data into buffered or unbuffered data. The start time of the TWT SP is defined as T... a，0，t Where t is the TWT SP index, and the arrival time of the nth packet (counting both UL and DL packets) is defined as T. a，n，t Therefore, the inter-group arrival time between the nth group and the (n-1)th group is expressed as:

[0159] T a，(n-1，n)，t =T a，n，t -T a，n-1，t , n = 1, 2, 3... (7)

[0160] To detect buffered data, the inter-packet arrival time in the t-th TWT SP is compared with the constant value T. B (For example, T) B =2.1ms) to compare and evaluate condition T a，(n-1，n)，t >T B When the nth group (denoted as n) in the t-th TWT SP that satisfies this condition is found... b，t When n is reached, the boundary between buffered and unbuffered data is detected. Note that if n... b，t If = 1, then all data in the t-th TWT SP are unbuffered data. Other clustering algorithms, such as density-based spatial clustering (DBSCAN) for noisy applications, can also be used to estimate buffered data periods, in which case the first cluster can be considered as buffered data.

[0161] The duration of the buffered data in the t-th TWT SP (D b，t ) and the duration of unbuffered data (D n，t It was then calculated as:

[0162]

[0163]

[0164] Where, N t It is the total number of groups in the t-th TWT SP, and It is the arrival time of the last packet in the t-th TWT SP.

[0165] Figure 29 A state machine 2900 representing an example process for TWT offset adjustment based on flow density, according to various embodiments of this disclosure, is shown. The initial state of state machine 2900 is state 0. In state 0, if the duration of the buffered data does not show a significant increment over the last M TWT SPs (i.e., the duration decreases or remains at a similar level), D b，t -D b，m If the increment is less than or equal to D0, then state machine 2900 applies a negative offset adjustment with a step size T0 (e.g., T0 = 5ms) and remains in state 0. The significant increment is defined as D. b，t -D b，m >D0, where D b，m It is the minimum value D of the last M SPs. b，t (For example, M=3), and D0 is a predefined small constant value (for example, 0.5ms).

[0166] In state 0, if the duration of the buffered data shows a significant increment over the last M TWT SPs (i.e., D... b，t -D b，m If the offset is greater than D0, then state machine 2900 rolls back the last offset adjustment and transitions to state 1. When rolling back the last offset adjustment, the step size can be changed to D. b =T 1s，t -T sp，t , among which, T 1s，t It is the transmission time of the first packet in the t-th TWT SP, and T sp，t It is the start time of the t-th TWT SP.

[0167] In state 1, if the duration of the buffered data remains at a low level (D b，t If the offset is less than or equal to D1, then state machine 2900 remains in state 1 without offset adjustment. D1 is defined as the duration of the buffered data when state machine 2900 transitions from state 0 to state 1, plus D0.

[0168] If the duration of the buffered data becomes greater than D1 (i.e., D... b，t If >D1), then state machine 2900 will transition from state 1 to state 0, and apply a negative offset adjustment with a step size T0.

[0169] Figure 30A state machine 3000 is shown, representing an alternative example process for TWT offset adjustment based on flow density, according to various embodiments of the present disclosure. State machine 3000 is similar to state machine 2900, except that a ratio is used under state transition conditions. To replace ratio D b，t R b，m It is the minimum value R among the last M TWT SPs. b，t R0 is a predefined constant value that can be tuned (or can also be adaptive), while R1 is the value of R when the state machine transitions from state 3000 to state 1. b，t Add R0.

[0170] Figure 31 Example procedures for obtaining timing information and adjusting offsets for TWT operation execution time are shown according to various embodiments of the present disclosure. Figure 31 The process is discussed as being performed by a first communication device acting as the requesting STA (e.g., a TWT request STA or a TWT request STA attached to the MLD), but it should be understood that a second communication device acting as the corresponding responding STA (e.g., a TWT response STA or a TWT response STA attached to the MLD) performs the corresponding process. Additionally, for convenience, Figure 31 The process is discussed as being performed by a Wi-Fi STA, but it should be understood that any suitable wireless communication device can perform these processes.

[0171] Reference Figure 31 The process begins with the first communication device generating a TWT element that includes a request for information regarding the traffic delay of the second communication device (step 3105). This request can be for information regarding the traffic delay of all Traffic Identifiers (TIDs) or a subset of TIDs. The TWT element is generated to include a first binary subfield in a first control field, which indicates the request for information regarding the traffic delay of the second communication device. If the request is for a subset of TIDs, the TWT element is generated to include a second binary subfield, which indicates a bitmap corresponding to the TID for which it requests information regarding the traffic delay. The first binary subfield of the first control field of the TWT element is represented by one of the sixth or seventh bits of the first control field, and the second binary subfield is appended to the TWT parameter set field within the TWT element.

[0172] If the first communication device is one of a first plurality of STAs attached to the first MLD, and the second communication device is one of a second plurality of STAs attached to the second MLD (i.e., operating in the MLO), then in step 3105, the first communication device generates a TWT element to include a request for information regarding the traffic delay of the second plurality of STAs.

[0173] Next, the first communication device sends a TWT element to the second communication device during the TWT setup phase (step 3110). In some embodiments of step 3110, the first communication device sends a comprehensive traffic delay request element, which includes a request for information about traffic delay and information about each of the second communication device's queuing delay, contention delay, postponement delay, and receiver / transmitter delay.

[0174] If the first communication device is operating in an MLO, then multiple links are established between the STAs attached to the first MLD and the STAs attached to the second MLD. In this case, in step 3110, the first communication device sends a TWT element to the second communication device through one of these links (i.e., the negotiation link).

[0175] Subsequently, the first communication device receives a second TWT element from the second communication device (step 3115). The second TWT element includes a third binary subfield in the first control field of the second TWT element, which indicates a response to a request for information regarding the traffic delay of the second communication device, indicating whether the request is accepted or rejected. The third binary subfield of the first control field of the second TWT element is represented by one of the sixth or seventh bits of the first control field. If the response indicates that the request is accepted for a subset of the requested TIDs, a fourth binary subfield in the second control field of the second TWT element indicates the presence of a bitmap indicating the subset of requested TIDs accepted to provide information regarding traffic delay.

[0176] Then, the first communication device receives information about traffic delay from the second communication device (step 3120). The information about traffic delay can be received in a traffic delay information element in a frame, or in a traffic delay information control frame. The traffic delay information element or the traffic delay information control frame includes a first subfield and a second subfield. The first subfield includes a bitmap indicating a subset of TIDs for which traffic delay information exists, and the second subfield includes information about the traffic delay for each of the TID subsets. If, in step 3110, the first communication device sends a comprehensive traffic delay request element, then in step 3120, the first communication device receives a traffic delay response element including the requested information.

[0177] If the first communication device is operating in MLO, then in step 3120, the first communication device receives information about the traffic delay of the second plurality of communication devices from the second communication device through a link (i.e., the negotiation link).

[0178] Finally, the first communication device determines a time offset for adjusting the start time of the next TWT interval based on information about traffic latency (step 3125). In some embodiments, the time offset is determined based on information about the traffic latency of the second communication device as the average traffic latency of the second communication device over one or more TWT intervals. In some embodiments, the time offset is determined based on an estimate of the round-trip time to the second communication device, which is based on information about TCP timestamps received from the second communication device. In other embodiments, the time offset is determined based on information about the density of buffered data packets received from the second communication device in at least one previous TWT interval of the first communication device.

[0179] 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 various 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.

[0180] Returning to the discussion of traffic delay information above, in some embodiments, a STA (e.g., a sending STA) can send unsolicited traffic delay information to another STA. In such embodiments, the sending STA can send traffic delay information to another STA without receiving a request for such information from the other STA. The STA can send information for any or all TIDs. This information can also be sent for any or all TIDs and for any or all enabled links between AP MLDs and non-AP MLDs. In some embodiments, other delay information (e.g., delay limits, etc.) can also be considered as traffic delay information in this disclosure. Such delay information can be indicated as being for a specific TID. In some embodiments, delay information can be requested or sent outside the context of TWT operation.

[0181] In an embodiment, the transmitting STA can include a delay information element in any frame sent to another STA so that the delay information can be conveyed at the transmitting STA end. Figure 32 An example delay information element format 3200 according to various embodiments of the present disclosure is illustrated. In the delay information element format 3200, a delay information subfield size field 3202 determines the size of the delay information subfield 3204. A TID bitmap subfield 3206 contains a bitmap for the TIDs whose delay information is included in the delay information element. If the bit corresponding to the k-th position in the TID bitmap subfield is set to 1, it indicates that the delay of the k-th TID is included in the delay information element. If the bit is set to 0, it indicates that delay information is not included for the k-th TID.

[0182] The delay information subfield 3204 contains delay information for different TIDs. For each TID, two octets can be used for delay information, but any number of octets can be used. In the delay information subfield 3204, the octets used for delay information for different TIDs are concatenated. The TID whose delay information is included in the delay information subfield 3204 is indicated by the TID bitmap in the TID bitmap subfield 3206. For example, if the TID bitmap in the TID bitmap subfield 3206 is [011001000000000], it will indicate that the delay information subfield 3204 will contain delay information for 3 TIDs (corresponding to 3 ones in the TID bitmap subfield). In this example, if two octets are used to represent the traffic delay information for each TID, then the delay information subfield 3204 will be 6 octets long. The first two octets in the delay information subfield 3204 will contain delay information corresponding to TID 2, the second two octets in the delay information subfield 3204 will contain delay information corresponding to TID 3, and the last two octets in the delay information subfield 3204 will contain delay information corresponding to TID 6.

[0183] In another embodiment, the delay information subfield size subfield 3202 may not exist in the delay information element. In this case, the size of the delay information subfield 3204 can be determined based on the number of 1s in the delay information TID bitmap and the number of octets used to encapsulate the delay information for each TID. For example, if the TID bitmap in the TID bitmap subfield 3206 is [0110011000000000] and two octets are used to represent the traffic delay information for each TID, then the size of the delay information subfield 3204 is eight octets.

[0184] In some embodiments, an MLD (e.g., a transmitting MLD) is able to include a multi-link delay information element in any frame transmitted to another MLD via any established link, so as to transmit delay information at the end of the transmitting MLD corresponding to one or more established links between the two MLDs. Figure 33An example multi-link delay information element format 3300 according to various embodiments of the present disclosure is illustrated. The link ID bitmap subfield 3302 in the multi-link delay information element format 3300 indicates a bitmap (i.e., a link ID bitmap) for the link for which delay information is provided. In the delay information subfield 3304, delay information for all indicated TIDs is provided for a first indicated link ID, then for all indicated TIDs for a second link ID, and so on. For each link ID indicated as 1 in the link ID bitmap, two octets will exist in the TID Bitmap Set per Link ID subfield 3306.

[0185] In some embodiments, latency information can be provided in conjunction with the queue size corresponding to the TID. For example, a latency information element or a multi-link latency information element can be provided together with a buffer status report included in the same frame. In some embodiments, existing QoS control fields can be modified. The low-latency QoS control field can include both queue size and latency information. Figure 34 An example low-latency QoS control field format 3400 according to various embodiments of the present disclosure is shown.

[0186] In other embodiments, it is possible to use multi-link low-latency delay information elements to provide queue size and delay information in a single element for multiple TIDs and for multiple links between two MLDs. Figure 35 An example multi-link low-latency delay information element format 3500 according to various embodiments of the present disclosure is shown. The information order in the queue size subfield 3502 of the multi-link low-latency delay information element format 3500 is the same as the information order in the delay information subfield 3504. In other embodiments, the queue size and delay information can be per access class (AC) rather than per TID. In this case, the TID bitmap subfield 3506 can be replaced by the AC bitmap subfield. This can be considered a modification to the buffer status report (BSR) control subfield in the buffer status report (BSR).

[0187] According to other embodiments, variations in the format 3500 of the multi-link low-latency delay information element are possible. For example, delay limits for a TID and traffic delay information can be placed in the same information element, wherein the delay limit for the corresponding TID is defined as the maximum amount of time the STA expects to elapse in order to complete the transmission of a specified number of packets. This is a duration t4-t3, where t3 is the time when the STA / AP sends the BSR, and t4 is the time when the AP / STA requests the STA / AP to begin transmitting the packets specified in this variant of the multi-link low-latency delay information element.

[0188] According to some embodiments, an AP or non-AP STA can request a multi-link low-latency delay information element or a variant thereof carrying TID information, corresponding queue size information, delay limit information, and traffic delay information. According to some other embodiments, the multi-link low-latency delay information element or a variant thereof carrying TID information, corresponding queue size information, delay limit information, and traffic delay information can be sent by an AP or non-AP STA. According to other embodiments, a delay unit subfield can be included in a variant of the multi-link low-latency delay information element format 3500, wherein the delay unit subfield indicates a delay unit suitable for delay boundary information or traffic delay information included in the variant of the multi-link low-latency delay information element. According to another embodiment, traffic delay information or delay limit information can be included in a variant of the BSR control subfield or a variant of the QoS control field in QoS data / empty frames.

[0189] Although this disclosure has been described using exemplary embodiments, various changes and modifications may be suggested 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. None of the descriptions 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 first communication device, comprising: transceiver; and A processor, operatively coupled to a transceiver, enables the first communication device to: During the Target Wake-up Time (TWT) setup phase, TWT elements are sent to the second communication device; Receive information about the traffic delay of the second communication device sent in response to the TWT element; and The time offset for adjusting the start time of the next TWT interval is determined based on information about traffic delay. The TWT element includes a request for information about the traffic delay of the second communication device.

2. The first communication device as claimed in claim 1, wherein: The request is for information regarding traffic latency for all Traffic Identifiers (TIDs) or a subset of TIDs. The processor causes the first communication device to generate TWT elements to include: The first binary subfield in the first control field of the TWT element indicates a request for information regarding the traffic delay of the second communication device; and Based on the fact that the request is for a subset of the TID, the second binary subfield in the TWT element indicates the bitmap corresponding to the TID for which information about traffic latency is requested, and The second binary subfield is appended to the TWT parameter set field within the TWT element.

3. The first communication device as described in claim 1, wherein, The processor also enables the first communication device to: Receive a second TWT element, which includes a third binary subfield in the first control field of the second TWT element, the third binary subfield indicating a response to a request for information about the traffic delay of the second communication device, the response indicating whether the request is accepted or rejected.

4. The first communication device as described in claim 3, wherein, The processor also enables the first communication device to: Based on the response indicating that the request is accepted for a subset of the requested TID, a second TWT element is received, which includes a fourth binary subfield in the control field of the second TWT element, the fourth binary subfield indicating the presence of a bitmap indicating a subset of the requested TIDs accepted to provide information about traffic latency.

5. The first communication device as described in claim 1, wherein, The processor also enables the first communication device to: Information about traffic delay is received in the traffic delay information element of the frame or in the traffic delay information control frame; The traffic delay information element or traffic delay information control frame includes a first subfield and a second subfield. The first subfield includes a bitmap indicating a subset of traffic identifiers (TIDs) for which traffic delay information exists. The second subfield includes information about the traffic delay for each TID in the subset of TIDs.

6. The first communication device as claimed in claim 1, wherein: The first communication device is a first multi-link device (MLD) having more than one auxiliary station, and the second communication device is a second MLD having more than one auxiliary station. Establish multiple links between the first MLD and the second MLD, and The processor also enables the first communication device to: A TWT element is sent on one of the links, the TWT element including a request for information on traffic delays of one or more stations of the second MLD; as well as The information regarding the traffic delay of one or more stations of the second MLD is received on one of the links.

7. The first communication device as claimed in claim 1, wherein, The processor also enables the first communication device to: Send a comprehensive traffic delay request element, the comprehensive traffic delay request element including a request for information about traffic delay and information about each of the queuing delay, contention delay, delay delay and receiver / transmitter delay of the second communication device; as well as Receive a traffic delay response element that includes the requested information.

8. The first communication device as claimed in claim 1, wherein, The processor also enables the first communication device to: Based on information about the traffic delay of the second communication device, the time offset is determined as the average traffic delay of the second communication device over one or more TWT intervals; or The time offset is determined based on an estimate of the round-trip delay to the second communication device, the estimate being based on information about the Transmission Control Protocol (TCP) timestamps received from the second communication device; or The time offset is determined based on information about the density of buffered data packets received from the second communication device in at least one previous TWT interval of the first communication device.

9. A method performed by a first communication device, comprising: TWT elements are sent during the Target Wake-up Time (TWT) setup phase; Receive information about the traffic delay of the second communication device sent in response to the TWT element; and The time offset for adjusting the start time of the next TWT interval is determined based on information about traffic delay. The TWT element includes a request for information about the traffic delay of the second communication device.

10. The method of claim 9, wherein: The request is for information regarding traffic latency for all Traffic Identifiers (TIDs) or a subset of TIDs. The method further includes generating TWT elements to include: The first binary subfield in the first control field of the TWT element indicates a request for information regarding the traffic delay of the second communication device; and Based on the fact that the request is for a subset of the TID, the second binary subfield in the TWT element indicates the bitmap corresponding to the TID for which information about traffic latency is requested, and The first binary subfield of the first control field of the TWT element is represented by one of the sixth or seventh bits of the first control field, and the second binary subfield is appended to the TWT parameter set field within the TWT element.

11. A second communication device, comprising: transceiver; and: A processor, operatively coupled to a transceiver, enables a second communication device to: During the Target Wake-up Time (TWT) setup phase, a TWT element is received, which includes a request for information about the traffic delay of the second communication device; as well as In response to the TWT element, information about the traffic delay of the second communication device is sent to the first communication device; as well as The time offset used to adjust the start time of the next TWT interval is determined based on information about the flow delay.

12. The second communication device as claimed in claim 11, wherein: The request is for information regarding traffic latency for all Traffic Identifiers (TIDs) or a subset of TIDs. TWT elements include: The first binary subfield in the control field of the TWT element indicates a request for information regarding the traffic delay of the second communication device; and Based on the fact that the request is for a subset of the TID, the second binary subfield in the TWT element indicates the bitmap corresponding to the TID for which information about traffic latency is requested, and The second binary subfield is appended to the TWT parameter set field within the TWT element.

13. The second communication device as claimed in claim 11, wherein, The processor also enables a second communication device: Send a second TWT element, the second TWT element including a third binary subfield in the first control field of the second TWT element, the third binary subfield indicating a response to a request for information about the traffic delay of the second communication device, the response indicating whether the request is accepted or rejected.

14. The second communication device as claimed in claim 13, wherein, The processor also enables a second communication device: Based on the response indicating that the request is accepted for a subset of the requested TIDs, a second TWT element is received, the second TWT element including a fourth binary subfield in the control field of the second TWT element, the fourth binary subfield indicating the presence of a bitmap indicating a subset of the requested TIDs accepted to provide information about traffic latency.

15. The second communication device as claimed in claim 11, wherein, The processor also enables a second communication device: Information about traffic delay is sent in the traffic delay information element of the frame or in the traffic delay information control frame. The traffic delay information element or traffic delay information control frame includes a first subfield and a second subfield. The first subfield includes a bitmap indicating a subset of traffic identifiers (TIDs) for which traffic delay information exists. The second subfield includes information about the traffic delay for each TID in the subset of TIDs.

Images