Adaptive adjustment of target wake time duration configuration

Abstract

A wireless communication device includes a processor configured to obtain first information about network conditions and second information about packets transmitted to another communication device during a current target wake time (TWT) session, and to update a TWT service period (SP) duration of a future TWT session based on the first information and the second information.

Description

Technical Field

[0001] This disclosure generally relates to power management in wireless communication systems. Embodiments of this disclosure relate to methods and apparatus for determining the target wake-up time duration of communication in a wireless local area network (WLAN) communication system. Background Technology

[0002] With the standardization process of the next-generation IEEE 802.11 Wireless Local Area Network (WLAN), namely the IEEE 802.11ax revision, entering its final stage, the IEEE 802.11ax revision is 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 environments. Example environments include airports and stadiums. The Wi-Fi Alliance (WFA) has launched a Wi-Fi 6 certification program to ensure interoperability between certified products implementing the IEEE 802.11ax revision. In the market, device manufacturers have begun releasing Wi-Fi 6 certified smart mobile devices.

[0003] Target Wake-up Time (TWT) is one of the key features of the IEEE 802.11ax modifications. TWT enables wake-up time negotiation between an access point (AP) and an associated station (STA) or client. Wake-up time negotiation results in a TWT session (e.g., a continuous TWT session), in which the STA wakes up at a pre-negotiated time and communicates with the AP for a specified duration (e.g., via UL and / or DL ​​communication). The IEEE 802.11ax modifications allow for periodic, non-periodic, and arbitrary wake-up by the STA. Summary of the Invention

[0004] Technical issues

[0005] Traditional power-saving mechanisms in Wi-Fi systems do not consider the communication patterns between the Access Point (AP) and the STA. Typically, when a STA has an active communication link with the AP, it remains active, and power-saving mechanisms are only activated when the STA's screen is off. Power-saving mechanisms in Wi-Fi systems can include beacon-triggered solutions or Unscheduled Automatic Power Saving Transmission (U-APSD) solutions. In beacon-triggered solutions, the trigger is a beacon interval of 100 milliseconds or more. Therefore, beacon-triggered solutions increase latency because communication between the AP and STA requires waiting for the next communication trigger. In U-APSD solutions, if the STA (or AP) has data, it wakes up to send it and checks if the AP (or STA) has any buffered data; however, in this case, the STA (or AP) has no information about the communication patterns between the STA and AP.

[0006] The current method for determining TWT parameters does not consider the current traffic between the AP and STA, and does not dynamically adapt the TWT parameters in response to the type of traffic exchanged between the AP and STA. A better method for determining TWT parameters may be needed.

[0007] Technical solution

[0008] Embodiments of this disclosure provide a method and apparatus for determining the duration of a target wake-up time in a wireless local area network communication system.

[0009] In one embodiment, a communication apparatus is provided, comprising a processor configured to obtain first information about network conditions during a current Target Wake-up Time (TWT) session and second information about packets transmitted to another communication apparatus, and to update the TWT Service Period (SP) duration for future TWT sessions based on the first and second information. The processor may also be configured to identify a set of buffered packets from the transmitted packets based on the second information about the transmitted packets, estimate the data time of the current TWT session as the total time required to send all transmitted packets based on characteristics of the buffered packet set, and determine a new TWT SP duration in part based on the data time.

[0010] In another embodiment, a method for wireless communication is provided, comprising the steps of: obtaining first information about network conditions during a current Target Wake-up Time (TWT) session and second information about packets transmitted to another communication device; and updating the TWT Service Period (SP) duration for future TWT sessions based on the first and second information. The method may further include: identifying a set of buffered packets from the transmitted packets based on the second information about the transmitted packets; estimating the data time of the current TWT session as the total amount of time required to transmit all transmitted packets based on characteristics of the set of buffered packets; and determining a new TWT SP duration in part based on the data time.

[0011] In another embodiment, a non-transitory computer-readable medium is provided, wherein the non-transitory computer-readable medium is configured to store instructions that, when executed by a processor, cause the processor to obtain first information about network conditions during the current Target Wake-up Time (TWT) session and second information about packets transmitted to another communication device, and to update the TWT Service Period (SP) duration for future TWT sessions based on the first and second information. The non-transitory computer-readable medium may be further configured to store instructions that, when executed by a processor, cause the processor to identify a set of buffered packets from the transmitted packets based on the second information about the transmitted packets, to estimate the data time of the current TWT session as the total amount of time required to send all transmitted packets based on characteristics of the set of buffered packets, and to determine a new TWT SP duration in part based on the data time.

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

[0013] Beneficial effects

[0014] Embodiments of this disclosure provide apparatus and methods that utilize the standard of incorporating Target Wake-up Time (TWT) into IEEE 802.11ax to enable STAs to wake up at periodic intervals and for specific durations based on service and communication patterns between the AP and the STA.

[0015] Embodiments of this disclosure consider the service and communication patterns between the AP and STA during a TWT session to determine the TWT SP duration (i.e., the amount of time the STA is active within a TWT interval) for at least the next TWT session. The apparatus and methods of this disclosure can save power in the STA by allowing it to doze off when it has already transmitted data (e.g., in UL and / or DL) and wake up (e.g., in UL and / or DL) to transmit the next batch of data when it becomes available. Furthermore, embodiments of this disclosure consider whether the service between the AP and STA is stable or bursty, and adaptively update the TWT SP duration for the next TWT session based on these considerations.

[0016] Given knowledge of the deterministic communication and network environment, embodiments of this disclosure can determine the TWT SP duration for a given TWT interval, which can have the beneficial effect of saving additional power at the STA without degrading the user experience. Specifically, for a given TWT interval, embodiments of this disclosure identify the optimal TWT SP duration for the service and communication patterns between the AP and STA. Attached Figure Description

[0017] The patent or application documents contain at least one color drawing. Upon request and upon payment of the necessary fees, the Patent Office will provide a color drawing copy of the patent or patent application publication.

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

[0019] Figure 1 Example electronic devices in a network environment 100 according to various embodiments of the present disclosure are shown;

[0020] Figure 2 A packet exchange diagram between devices according to embodiments of the present disclosure is shown;

[0021] Figure 3 An example TWT parameter set field for TWT parameter negotiation according to an embodiment of the present disclosure is shown;

[0022] Figure 4 An offset in a TWT session according to an embodiment of this disclosure is shown;

[0023] Figure 5 An example TWT information frame according to an embodiment of the present disclosure is shown;

[0024] Figure 6 An example of early termination of TWT according to an embodiment of this disclosure is shown;

[0025] Figure 7 An example of a time-sensitive service according to an embodiment of this disclosure is shown;

[0026] Figure 8 An example of a high-throughput service according to an embodiment of this disclosure is shown;

[0027] Figure 9 Examples of buffered and unbuffered packets in a TWT session according to various embodiments of the present disclosure are shown;

[0028] Figure 10 An example of a three-stage process for adaptively updating the TWT SP duration according to an embodiment of the present disclosure is shown;

[0029] Figure 11 Examples of inter-group offsets and inter-group times according to various embodiments of the present disclosure are shown;

[0030] Figure 12 An example process 1200 for grouping cluster determination according to an embodiment of the present disclosure is shown;

[0031] Figure 13An example of a TWT session for a data time calculation process according to an embodiment of the present disclosure is shown;

[0032] Figure 14 An example of a TWT session is shown, according to an embodiment of the present disclosure, for a data time calculation process when the start time of the TWT session is unknown;

[0033] Figure 15 An example of a three-stage process for adaptively updating the TWT SP duration according to embodiments of the present disclosure is shown, along with additional details of an example process for the business adaptation stage;

[0034] Figure 16 Example scenarios of stable updates and overflow updates according to embodiments of this disclosure are shown; and

[0035] Figures 17a-17c Example processes for adaptively adjusting the duration of TWT SP according to various embodiments of this disclosure are shown. Detailed Implementation

[0036] Before proceeding with the detailed description below, it may be advantageous to define certain words and phrases used in this patent document. The term “coupled” and its derivatives refer to any direct or indirect communication between two or more elements, regardless of whether these elements are physically in contact with each other. The terms “transmit,” “receive,” and “communicate,” and their derivatives include both direct and indirect communication. The terms “include” and “comprising,” and their derivatives mean unrestricted inclusion. The term “or” is inclusive, meaning and / or. The phrase “associated,” and its derivatives refer to including, being included, interconnected, containing, being contained within, connected to or connected with, coupled to or coupled with, able to communicate with, cooperate with, interleave, juxtapose, be close to, be combined with or combined with, have, have attributes, be related to, or be associated with, etc. The term “controller” refers to 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. Whether local or remote, the functionality associated with any particular controller may be centralized or distributed. When used with a list of items, the phrase “at least one” means that different combinations of one or more of the listed items may be used, and that only one item from the list may be required. For example, “at least one of A, B, and C” includes any of the following combinations: A, B, C, A and B, A and C, B and C, and A and B and C. As used herein, terms such as “first” and “second” or “first” and “second” can be used to simply distinguish the corresponding component from another component without limiting other aspects of 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 another element (e.g., a second element),” “coupled to another element (e.g., a second element),” “connected to another element (e.g., a second element),” or “connected to another element (e.g., a second element)”, regardless of whether the terms “operably” or “communically” are used, it means that the element can be coupled to another element directly (e.g., wired), wirelessly, or via a third element.

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

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

[0039] Definitions of other specific words and phrases are also provided in 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.

[0040] The following discussion Figures 1 to 17c The various embodiments described in this patent document to illustrate the principles of this disclosure are merely exemplary 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 apparatus.

[0041] Embodiments of this disclosure recognize that conventional power-saving mechanisms in Wi-Fi systems do not take into account the communication patterns between the AP and STA. Typically, when a STA has an active communication link with the AP, the STA remains active, and power-saving mechanisms are only activated when the STA's screen is off. Power-saving mechanisms in Wi-Fi systems may include beacon-triggered solutions or Unscheduled Automatic Power Saving Transmission (U-APSD) solutions. In beacon-triggered solutions, the trigger is a beacon interval of 100 milliseconds or greater. Therefore, beacon-triggered solutions increase latency because communication between the AP and STA requires waiting for the next communication trigger. In U-APSD solutions, if the STA (or AP) has data, it wakes up to send it and checks if the AP (or STA) has any buffered data; however, in this case, the STA (or AP) has no information about the service patterns between the STA and AP.

[0042] Embodiments of this disclosure provide devices and methods for enabling STAs to wake up at periodic intervals and for specific durations based on the target wake-up time (TWT) introduced in the IEEE 802.11ax standard. Current methods for determining TWT parameters do not take into account the current traffic between the AP and STA, and do not dynamically adapt the TWT parameters in response to the type of traffic exchanged between the AP and STA. Better methods for determining TWT parameters may be needed.

[0043] Embodiments of this disclosure consider the service and communication patterns between the AP and STA during a TWT session to determine the TWT SP duration (i.e., the amount of time the STA is active within a TWT interval) for at least the next TWT session. The apparatus and methods of this disclosure can save power in the STA by causing it to doze off when it has already transmitted data (e.g., in UL and / or DL) and wake up to transmit the next batch of data (e.g., in UL and / or DL) when it becomes available. Furthermore, embodiments of this disclosure consider whether the service between the AP and STA is stable or bursty, and adaptively update the TWT SP duration for the next TWT session based on these considerations.

[0044] Given knowledge of the deterministic communication and network environment, embodiments of this disclosure can determine the TWT SP duration for a given TWT interval, which can have the beneficial effect of saving additional power at the STA without degrading the user experience. Specifically, for a given TWT interval, embodiments of this disclosure identify the optimal TWTSP duration for the service and communication patterns between the AP and STA.

[0045] Figure 1 Example electronic device 101 in a network environment 100 according to various embodiments of the present disclosure is shown. In this embodiment, electronic device 101 in network environment 100 can communicate with electronic device 102 via a first network 198 (e.g., a short-range wireless communication network), or with electronic device 104 or server 108 via a second network 199 (e.g., a long-range wireless communication network). Electronic device 101 can communicate with electronic device 104 via server 108.

[0046] Electronic device 101 may include a processor 120, a memory 130, an input device 150, a sound output device 155, a display device 160, an audio module 170, a sensor module 176, an interface 177, a haptic module 179, a camera module 180, a power management module 188, a battery 189, a communication module 190, a subscriber identification module (SIM) 196, or an antenna module 197. In some embodiments, at least one component (e.g., display device 160 or camera module 180) may be omitted from electronic device 101, or one or more other components may be added to electronic device 101. In some embodiments, some components may be implemented as a single integrated circuit. For example, sensor module 176 (e.g., a fingerprint sensor, an iris sensor, or an illumination sensor) may be implemented as embedded in display device 160 (e.g., a display).

[0047] Processor 120 can execute, for example, software (e.g., program 140) to control at least one other component (e.g., hardware or software component) of electronic device 101 coupled to processor 120, and can perform various data processing or calculations. According to one embodiment, as at least part of data processing or calculation, processor 120 can load commands or data received from another component (e.g., sensor module 176 or communication module 190) into volatile memory 132, process the commands or data stored in volatile memory 132, and store the resulting data in non-volatile memory 134. According to embodiments, processor 120 may include a main processor 121 (e.g., a central processing unit (CPU) or application processor (AP)) and an auxiliary processor 123 (e.g., a graphics processing unit (GPU), image signal processor (ISP), sensor hub processor, or communication processor (CP)), the auxiliary processor 123 operating independently of or in conjunction with the main processor 121. Additionally or alternatively, the auxiliary processor 123 may be adapted to consume less power than the main processor 121, or dedicated to a specific function. The auxiliary processor 123 may be implemented independently of the main processor 121 or as part of the main processor 121.

[0048] When the main processor 121 is inactive (e.g., in sleep mode), the auxiliary processor 123 may control at least some functions or states associated with at least one component of the electronic device 101 (e.g., display device 160, sensor module 176, or communication module 190) in place of the main processor 121, or when the main processor 121 is active (e.g., executing an application), the auxiliary processor 123 may control the device together with the main processor 121. According to embodiments, the auxiliary processor 123 (e.g., an image signal processor or a communication processor) may be implemented as part of another component (e.g., camera module 180 or communication module 190) functionally associated with the auxiliary processor 123.

[0049] Memory 130 may store various data used by at least one component of electronic device 101 (e.g., processor 120 or sensor module 176). The various data may include, for example, input or output data of software (e.g., program 140) and associated commands. Memory 130 may include volatile memory 132 or non-volatile memory 134.

[0050] Program 140 may be stored as software in memory 130 and may include, for example, an operating system (OS) 142, middleware 144, or application 146.

[0051] Input device 150 can receive commands or data from outside electronic device 101 (e.g., from a user) for use by another component of electronic device 101 (e.g., processor 120). Input device 150 may include, for example, a microphone, mouse, keyboard, or digital pen (e.g., stylus).

[0052] The sound output device 155 can output sound signals to the outside of the electronic device 101. The sound output device 155 may include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as playing multimedia or playing recordings, while the receiver can be used for incoming calls. According to an embodiment, the receiver may be implemented separately from the speaker or as part of the speaker.

[0053] Display device 160 can visually provide information to the outside of electronic device 101 (e.g., to a user). Display device 160 may include, for example, a display, a holographic device, or a projector, and control circuitry that controls a corresponding one of the display, holographic device, and projector. According to an embodiment, display device 160 may include touch circuitry adapted to detect touch, or sensor circuitry (e.g., a pressure sensor) adapted to measure the intensity of the force caused by touch.

[0054] The audio module 170 can convert sound into electrical signals and vice versa. According to an embodiment, the audio module 170 can obtain sound via the input device 150, or output sound via the sound output device 155 of an external electronic device (e.g., electronic device 102) or headphones that are directly (e.g., wired) or wirelessly coupled to the electronic device 101.

[0055] Sensor module 176 can detect the operating state of electronic device 101 (e.g., power or temperature) or the environmental state outside electronic device 101 (e.g., user state), and then generate an electrical signal or data value corresponding to the detected state. According to embodiments, sensor module 176 may include, for example, a gesture sensor, gyroscope sensor, atmospheric pressure sensor, magnetic sensor, accelerometer, grip sensor, proximity sensor, color sensor, infrared (IR) sensor, biosensor, temperature sensor, humidity sensor, brightness sensor, obstruction sensor, or folding state sensor.

[0056] Interface 177 may support one or more specified protocols for coupling electronic device 101 directly (e.g., wired) or wirelessly to external electronic devices (e.g., electronic device 102). According to embodiments, interface 177 may include, for example, a High Definition Multimedia Interface (HDMI), a Universal Serial Bus (USB) interface, a Secure Digital Card (SD) interface, or an audio interface.

[0057] Connection end 178 may include a connector through which electronic device 101 can be physically connected to an external electronic device (e.g., electronic device 102). According to embodiments, connection end 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0058] The tactile module 179 can convert electrical signals into mechanical stimulation (e.g., vibration or motion) or electrical stimulation, which a user can identify via touch or kinesthesia. According to embodiments, the tactile module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulator.

[0059] Camera module 180 can capture still or moving images. According to an embodiment, camera module 180 may include one or more lenses, an image sensor, an image signal processor, or a flash.

[0060] The power management module 188 can manage the power supplied to the electronic device 101. According to one embodiment, the power management module 188 can be implemented as at least part of, for example, a power management integrated circuit (PMIC).

[0061] Battery 189 can power at least one component of electronic device 101. According to embodiments, battery 189 may include, for example, a non-rechargeable main battery, a rechargeable secondary battery, or a fuel cell.

[0062] Communication module 190 can support the establishment of a direct (e.g., wired) or wireless communication channel between electronic device 101 and external electronic devices (e.g., electronic device 102, electronic device 104, or server 108), and perform communication via the established communication channel. Communication module 190 may include one or more communication processors (e.g., application processors (APs)) that operate independently of processor 120, and supports direct (e.g., wired) or wireless communication.

[0063] According to an embodiment, communication module 190 may include wireless communication module 192 (e.g., cellular communication module, short-range wireless communication module, or Global Navigation Satellite System (GNSS) communication module) or wired communication module 194 (e.g., local area network (LAN) communication module or power line communication (PLC) module). One of these communication modules may communicate with an external electronic device via a first network 198 (e.g., a short-range communication network such as Bluetooth, Wi-Fi Direct, Ultra-Wideband (UWB), or Infrared Data Association (IrDA)) or a second network 199 (e.g., a long-range communication network such as a cellular network, the Internet, or a computer network (e.g., a LAN or Wide Area Network (WAN)). These different types of communication modules may be implemented as a single component (e.g., a single chip) or as multiple components (e.g., multiple chips) that are separate from each other. Wireless communication module 192 may use subscriber information (e.g., International Mobile Subscriber Identity (IMSI)) stored in subscriber identification module 196 to identify and authenticate electronic device 101 in communication networks such as the first network 198 or the second network 199.

[0064] Antenna module 197 can transmit or receive signals or power to or from the outside of electronic device 101 (e.g., to or from external electronic devices). According to an embodiment, antenna module 197 may include an antenna comprising a radiating element made of conductive material or conductive patterns formed in or on a substrate (e.g., a PCB). According to an embodiment, antenna module 197 may include multiple antennas. In this case, for example, communication module 190 (e.g., wireless communication module 192) may select at least one antenna suitable for a communication scheme used in a communication network such as a first network 198 or a second network 199 from among the multiple antennas. Signals or power can then be transmitted or received between communication module 190 and external electronic devices via the selected at least one antenna. According to an embodiment, another component besides the radiating element (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as part of antenna module 197. According to an embodiment, electronic device 101 may include multiple antenna modules 197. Each antenna module 197 may have multiple antennas, referred to as antenna elements, configured such that antenna module 197 is capable of beamforming using multiple antenna elements.

[0065] At least some of the aforementioned components can be coupled to each other and transmit signals (e.g., commands or data) therebetween via peripheral communication schemes (e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industrial processor interface (MIPI)).

[0066] According to an embodiment, commands or data can be sent or received between electronic device 101 and external electronic device 104 via server 108 coupled to a second network 199. Each of electronic devices 102 and 104 can be a device of the same or different type as electronic device 101. According to an embodiment, all or some operations to be performed at electronic device 101 can be performed at one or more external electronic devices 102, 104, or 108. For example, if electronic device 101 is to automatically or in response to a request from a user or another device to perform a function or service, electronic device 101 may request one or more external electronic devices to perform at least a portion of the function or service in addition to performing the function or service. The one or more external electronic devices receiving the request may perform at least a portion of the requested function or service, or additional functions or services associated with the request, and transmit the result of the execution to electronic device 101. Electronic device 101 may provide a result, with or without further processing of the result, as at least part of a response to the request. For this purpose, cloud computing, distributed computing, or client-server computing technologies may be used, for example.

[0067] Electronic device 101, according to various embodiments, can be one of a variety of types of electronic devices. Electronic devices may include, for example, communication devices, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. In various embodiments, electronic device 101 may be IEEE 802.11STA or IEEE 802.11AP. It should be understood that the electronic device is not limited to those described above.

[0068] The various embodiments described herein can be implemented as software (e.g., program 140) comprising one or more instructions stored in a machine-readable storage medium (e.g., internal memory 136 or external memory 138). For example, a processor (e.g., processor 120) of the machine (e.g., electronic device 101) can invoke at least one of one or more instructions stored in the storage medium, and execute the instructions with or without one or more other components under the control of the processor. This allows the machine to be operated to perform at least one function according to the invoked at least one instruction. One or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. The term "non-transitory" simply means that the storage medium is a tangible device and does not include signals (e.g., electromagnetic waves), but this term does not distinguish between locations where data is semi-permanently stored in the storage medium and locations where data is temporarily stored in the storage medium.

[0069] According to embodiments, methods according to various embodiments of this disclosure may be included in and provided therein in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., an optical disc read-only memory (CD-ROM)), or distributed online (e.g., downloaded or uploaded) via an app store (e.g., the Google Play Store), or directly between two user devices (e.g., smartphones). If distributed online, at least a portion of the computer program product may be temporarily generated or at least temporarily stored in a machine-readable storage medium, such as the memory of a manufacturer's server, an app store's server, or a relay server.

[0070] According to various embodiments, each of the above-described components (e.g., a module or program) may include a single entity or multiple entities. According to various embodiments, one or more of the above-described components may be omitted, or one or more other components may be added. Alternatively or additionally, multiple components (e.g., modules or programs) may be integrated into a single component. In this case, according to various embodiments, the integrated component may still perform one or more functions of each of the multiple components in the same or similar manner as performed by a corresponding component of the multiple components prior to integration. According to various embodiments, operations performed by a module, program, or other component may be performed sequentially, in parallel, repeatedly, or heuristically, or one or more operations may be performed in a different order or omitted, or one or more other operations may be added.

[0071] Figure 2 A packet switching diagram 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 electronic device 101, but it should be understood that it may be any suitable wireless communication device.

[0072] Figure 2 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 STA. First, there is no wake-up time negotiation between the AP and STA (e.g., as shown in Figure 202 above), and second, there is wake-up time negotiation between the AP and STA (e.g., in an IEEE 802.11ax system, as shown in Figure 204 below). In Figure 202 above, there is a regular, unbuffered traffic flow between the AP and STA, where UL packets are interspersed with DL packets. In this case (i.e., no wake-up time negotiation), the STA has no option to enter a dozing or power-saving state.

[0073] In contrast, in Figure 204 below, wake-up time negotiation results in consecutive TWT sessions 206. Each TWT session 206 is defined as a time period from the beginning to the end of TWT interval 208. Each TWT session 206 includes two states: an active state 211 defined by the TWT service cycle (SP) duration 210 (during which the STA wakes up to communicate with the AP), and a power-saving or dozing state 212 (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 increasing latency too much or preventing UL or DL ​​packets from being dropped.

[0074] In wake-up time negotiation, the negotiated TWT parameters include the wake-up interval (e.g., TWT interval 208 per TWT session 206), the wake-up duration (e.g., TWT SP duration 210 per TWT session 206), and the initial wake-up time or offset (e.g., indicated by the TWT start time 214). These negotiated parameters significantly impact latency, throughput, and power efficiency, all of which are directly related to the QoS (Quality of Service) of the customer experience. Services with different service characteristics can have different TWT parameter configurations to achieve better QoS. Furthermore, the TWT configuration should adapt to changes in network and service conditions.

[0075] In some embodiments, the TWT parameter set field is used to negotiate TWT parameters. Figure 3 An example TWT parameter set field 300 for TWT parameter negotiation according to an embodiment of the present disclosure is shown. The TWT protocol is initiated by the STA sending a TWT negotiation request to the AP. Once a TWT protocol is reached between the AP and the STA, the STA periodically wakes up to communicate with the AP, wherein the interval between consecutive wake-up times is jointly specified by the TWT wake-up interval mantissa 302 and the TWT wake-up interval index 304 subfields in the TWT parameter set field 300.

[0076] The target wake-up time 306 and nominal minimum TWT wake-up duration 308 subfields specify the first wake-up time of the TWT protocol, and the time the STA must wait before entering a dormant state if no service is sent after the wake-up time. Figure 2 The duration of TWT SP is 210.

[0077] Besides wake-up interval and wake-up duration, offset is also an important factor affecting user experience, as offset can affect latency. Figure 4 An offset in a TWT session according to an embodiment of this disclosure is shown. Different offsets 402 introduce different additional TWT-related latency. The TWT interval 208, together with the offset, defines the additional latency introduced by the TWT. After the TWT negotiation is established, it can be... Figure 5 The field “Next TWT” 502 in the example TWT information frame 500 shown is used to adjust the offset 402.

[0078] Figure 6An example of early termination of TWT according to an embodiment of this disclosure is shown. In various embodiments, the actual TWTSP duration 210 is dynamically determined during runtime by the aforementioned nominal minimum TWT wake-up duration, and the STA enters a dozing state 212 when a packet is received with the ESP (End of Service Period) bit set to "1" or more data bits set to "0". The timing of the STA entering dozing state 212 will vary slightly depending on whether early termination is supported. As shown in Figure 602, if the STA supports early termination, it can enter dozing state 212 once it receives a packet with the ESP bit set to "1" or more data bits set to "0" (although there may be a small waiting time between packet reception and entering dozing state 212). If the STA does not support early termination, it will wait until the TWTSP duration ends to enter dozing state 212, as shown in Figure 204.

[0079] In some embodiments, the type of service between the STA and AP affects the optimal TWT parameters, particularly the optimal TWT interval and the TWT SP duration. For network-based applications, internet services can be broadly categorized into two types: time-sensitive services and high-throughput services. Time-sensitive services require data packets to be transmitted immediately upon arrival (e.g., for applications such as VoIP, video conferencing, online gaming, or screen mirroring). Time-sensitive services generate at a stable rate but are sensitive to latency. High-throughput services are not sensitive to packet latency but may require bursts of data transmission.

[0080] Figure 7 Examples of time-sensitive services according to embodiments of the present disclosure are illustrated. Time-sensitive services require immediate processing or communication upon receipt and can be associated with stable service applications such as online games, video and voice calls, which create data at periodic intervals, where the intervals are very short. Typically, these time periods are associated with the tick rate of a game or the frames per second (FPS) of a video call. Each of Figures 702, 704, and 706 is a graph of packets generated per second (on the y-axis) versus time in seconds (on the x-axis). Figure 702 illustrates an example of a stable service generated by an online game (e.g., a smartphone game). Figure 704 illustrates an example of a stable service generated by a video calling application. Figure 706 illustrates an example of a stable service generated by an audio calling application.

[0081] Figure 8Examples of high-throughput services according to embodiments of the present disclosure are illustrated. In these examples, large amounts of data are communicated in the form of periodic bursts or random bursts. For example, periodic bursts occur in video sharing or over-streaming applications using a quasi-periodic update read-ahead buffer. Random bursts may occur, for example, in web browsing, background updates, and other applications. These occur at random intervals within short bursts. Each of Figures 802, 804, and 806 is a graph of packets generated per second (on the y-axis) versus time in seconds (on the x-axis). Figure 802 illustrates an example of periodic bursts generated by a video sharing application. Figure 804 illustrates an example of random bursts generated by a web browsing application. Figure 806 illustrates an example of periodic bursts generated by an over-streaming service.

[0082] In embodiments of this disclosure, the selection of the TWT interval depends on the latency requirements of the application generating the service. The TWT SP duration is a function of the number of packets to be transmitted within the selected TWT interval and the time required to buffer and serve these packets. Figure 9 As shown, during the dozing state 212 within a given TWT session 206, packets arriving at the AP or needing to be sent from the STA to the AP are buffered until the next TWT session 206 begins at the AP and STA, respectively. Furthermore, while other packets are being served in the active state 211 of the TWT session 206, packets arriving at the AP or needing to be sent from the STA are also buffered at the AP and STA, respectively. Therefore, there are buffered packets 902 (e.g., packets delayed at the AP or STA due to queuing of previous packets) and unbuffered packets 904 (e.g., packets that are sent immediately upon arrival at the AP or created at the STA). Embodiments of this disclosure focus on packets at the data link layer, but other embodiments may also focus on packets at the network layer and above.

[0083] As described above, TWT session configuration includes the TWT interval and the TWT SP duration. The TWT interval can range from approximately 15 milliseconds to approximately 50 milliseconds, and there are several ways to obtain the TWT interval. For example, the TWT interval can be calculated as the minimum time required for an application between two packets in the UL or DL ​​direction. In another example, when data is unbalanced in the UL and DL directions, the TWT interval can be the minimum time required between two packets in the UL or DL ​​direction. In a third example, any type of TWT interval estimation procedure can be used to calculate the TWT interval. This example of a TWT interval estimation procedure can be based on application latency requirements, network traffic, or network conditions. In a fourth example, the TWT interval can be provided by an application running on the device (e.g., on a STA). In a fifth example, if the traffic is bursty and periodic (e.g., in some videos, the data period is consistent with the frame rate), the TWT interval can be set to the traffic period.

[0084] Once the TWT interval is determined, the process of adaptively updating the TWT SP duration can be divided into three stages. Figure 10 An example of a three-stage process for adaptively updating the TWT SP duration according to an embodiment of this disclosure is shown. First, buffered packet detection is performed, and packets are clustered into buffered packets and non-buffered packets (step 1002). Second, data time calculation is performed to find the data time required to transmit the packets based on major network conditions, such as congestion, link speed, number of retries when sending packets, etc. (step 1004). Third, the TWT SP duration is adjusted for subsequent TWT sessions based on the calculated data time and the type of arriving traffic (e.g., stable or bursty), which may be referred to as traffic adaptation (steps 1006, 1008, and 1010). More specifically, if the arriving traffic is stable, the TWT SP duration can be updated periodically (step 1008), but if the arriving traffic is bursty (as determined in step 1006), the TWT SP duration may need to be updated rapidly to accommodate the incoming traffic (step 1010).

[0085] Regarding the buffered packet detection in step 1002, embodiments of this disclosure use packet clustering determination to divide packets in a TWT session into buffered and unbuffered packets. For example... Figure 11As shown, packets are clustered based on inter-packet offset 1102, which is defined as the time between the end timestamp 1104 of one packet and the start timestamp 1106 of another consecutive packet. Inter-packet offset 1102 does not include the propagation time required to send a packet. However, inter-packet offset 1102 includes the time spent on contention between consecutive packets, overhead, and actual waiting time. If arriving packets are buffered, inter-packet offset 1102 should only include the time spent on contention (i.e., the opportunity for the device to wait to send or receive a packet) and overhead time (i.e., the time used for controlling and managing frames). Unbuffered packets will have a larger inter-packet offset 1102 due to the additional inclusion of the actual waiting time between packets (i.e., the time until the next consecutive packet arrives).

[0086] An exemplary process or method for clustering is designed to distinguish between buffered and unbuffered packets in a TWT session based on inter-packet offsets (e.g., inter-packet offset 1102). In normal operation of a Wi-Fi system, the inter-packet offset within a TWT session is a monotonically increasing function (e.g., unbuffered packets will have a larger inter-packet offset due to latency). That is, the inter-packet offset monotonically increases within a TWT session. The exemplary clustering process uses this characteristic of the Wi-Fi system to distinguish between buffered and unbuffered packets. When the inter-packet offset exceeds a clustering threshold ε, the boundary between buffered and unbuffered packets is found.

[0087] Figure 12 An example process 1200 for determining group clustering according to an embodiment of the present disclosure is shown. Process 1200 can be performed by any suitable electronic device 101 (such as a STA). In process 1200, N is the total number of packets in the TWT session, Nc is the number of clusters, k is a packet counter / iterator variable, t(k) is the relative timestamp of packet k to the start of the TWT session, τ is the inter-packet offset, s(k) is the size of packet k, DataRate is the physical layer (PHY) data rate of the current radio link, ε is the clustering threshold, and Ct is the timestamp of the last packet in cluster Nc.

[0088] When the TWT session ends (step 1202), process 1200 receives information about the number of packets N in the TWT session, the timestamp of the start of the TWT session, and the timestamp of each packet k. A preliminary check is performed to determine if there is more than one packet in the TWT session (step 1204). If not, the process moves to the next TWT session (step 1206). If there is more than one packet in the TWT session, the process continues to step 1208, in which the number of clusters Nc is initialized to 1, and the group counter variable k is initialized to 0.

[0089] Next, if the packet counter k is less than the total number of packets N in the TWT session, the process reads the timestamp information t(k) of packet k and increments k by 1 (step 1210), then moves to step 1212. However, if the packet counter k is equal to the total number of packets N in the TWT session, this indicates that all packets in the TWT session have been considered, and the process moves to the next TWT session (step 1206).

[0090] In step 1212, the inter-packet offset τ is calculated as follows. If k = 1 (i.e., if this is the first data packet in the TWT session):

[0091]

[0092] Otherwise, if k > 1:

[0093]

[0094] The process then checks whether the calculated τ > ε (step 1214). If not, the process returns to step 1210 and calculates τ for the next group. If τ > ε, the process increments the cluster number Nc by 1 and appends the cluster separation time to Ct, such as Ct[Nc-1] = t(k-1) (step 1216). The process then returns to step 1210 and calculates τ for the next group. This iteration is repeated until all groups in the TWT session have been considered.

[0095] As described above, when the inter-packet offset τ is greater than the clustering threshold ε, the boundary between buffered and unbuffered packets is found. The clustering threshold ε can be equivalent to the average contention time per packet and is a measure of network conditions resulting from active communication from other Wi-Fi devices on the same channel. Essentially, ε is a factor representing the influence of other devices on the Wi-Fi channel on the operation of the device of interest (e.g., a STA performing an embodiment of this disclosure).

[0096] In various embodiments, one or more of the following metrics can be used to estimate the clustering threshold ε. First, the ratio of idle channel access (CCA) time to the total CCA time within a given period. The ratio of busy CCA time to radio-on time can be used as an approximation. This helps to understand the channel utilization by other devices communicating on the same channel. Generally, ε increases with increasing ratio.

[0097] Second, the number of times transmitted packets are retransmitted due to the lack of acknowledgments from the receiver (e.g., the AP). This helps in understanding the impact of interference sources on the Wi-Fi channel. Generally, ε increases with the number of retransmission attempts.

[0098] Third, the retransmission rate of data packets sent per unit time. Generally, ε increases with the increase of the retransmission rate of packets sent per unit time.

[0099] Fourth, the ratio of retransmitted packets to successfully transmitted packets. Typically, ε increases with the retransmission rate (e.g., because the average contention time per packet increases with the retransmission rate).

[0100] Fifth, the frequency band or bandwidth of the Wi-Fi channel on which the AP and STA are communicating. Typically, ε decreases as the frequency band or bandwidth increases (e.g., because the average contention time per packet decreases as the frequency band or bandwidth increases).

[0101] Sixth, the number of APs on the channel. This can be determined by the STA sending probe requests to other APs or passively listening to the beacons of other APs. Typically, ε increases with the number of APs (e.g., because the average contention time per packet increases with the number of APs).

[0102] Seventh, the number of STAs associated with the current AP. This can be determined by the network discovery performed by the STAs on the local network provided by the AP. Typically, ε increases with the number of STAs (e.g., because the average contention time per packet increases with the number of STAs).

[0103] Eighth, the estimated average of the difference between the inter-packet time and the airtime of buffered or unbuffered packets. Typically, ε increases with the average of this difference (e.g., because the average competition time per packet increases with the average of this difference).

[0104] In some embodiments, a lookup table is used to determine the ε value based on one or a combination of the metrics specified above. For example, the parameters of the lookup table can be defined based on the ratio of CCA busy time to radio on time (the first metric in the list above). In this case, ε is chosen as 1 millisecond if the ratio is less than 0.25, ε is chosen as 1.5 milliseconds if the ratio is between 0.25 and 0.5, ε is chosen as 1.8 milliseconds if the ratio is between 0.5 and 0.75, and ε is chosen as 2.1 milliseconds if the ratio is greater than 0.75. The ε values ​​given above are merely examples. In other implementations, these values ​​can vary based on the metrics used, the capabilities of the Wi-Fi chipset, and the network interface used. If inter-packet time is used instead of inter-packet offset as the clustering feature, these values ​​will be different (ideally higher) and will depend on the PHY rate, as they will include the propagation time of the packets themselves.

[0105] In other embodiments, the model can be formulated to calculate ε based on one or a combination of the metrics specified above. A simple example of a formula could be:

[0106] ε=max(min(ε min +averageBuffTime, ε max ), ε min (3)

[0107] In equation (3), averageBuffTime is the estimated average of the difference between the inter-packet time and the packet propagation time in the buffer packet (the eighth metric in the list above), ε min and ε max These are the lower and upper bounds of ε, respectively. In one embodiment, ε min Set to 1ms, ε max It is set to 2.1ms. If an alternative value is used, if ε min If the time is less than 1ms, more clusters can be generated and connected together.

[0108] Once the clustering in process 1200 has been performed, the number of clusters and the separation time between clusters can be used to determine how many clusters provide information about the buffered packets. Since packets have monotonically increasing arrival / departure times, the end timestamp of the last packet in each cluster symbolizes the amount of time spent transmitting all packets appearing in that cluster and the clusters preceding it. One or more clusters can be identified as containing the buffered data. In one embodiment, a first cluster is identified as containing the buffered data, and the arrival / departure of the last packet in that cluster is designated as the buffered packet communication time. In an alternative embodiment, more clusters are used in a similar manner to symbolize the buffered data.

[0109] Refer again Figure 10 Regarding the data time calculation step 1004, embodiments of this disclosure use information about the identified buffered packets of the TWT session determined in step 1002 (e.g., using process 1200) to determine the data time of the TWT session. The data time of the TWT session is the time required to send all packets (buffered and unbuffered) in a buffered manner during the TWT session. That is, the data time is the time required to send all packets in the TWT session as if they were buffered. If all packets can be sent as if they were buffered, the time that the STA can be in a slumber or power-saving mode during the TWT session is maximized.

[0110] Figure 13An example of a TWT session for a data time calculation process according to an embodiment of the present disclosure is shown. In a simplified embodiment, buffered grouping clustering N relative to the start timestamp of the TWT session can be used. buff The end timestamp of the last group in the middle, TWT session N buff The number of buffered packets and TWT session N session The total number of groups is used to perform data time calculation. The data time T in a TWT session is... d It can be represented as:

[0111]

[0112] In another embodiment, the data time calculation also considers the overhead associated with communication between the initiating AP and STA when the TWT session begins, as well as the overhead and contention time associated with packet communication. In this case, the formula for data time is:

[0113]

[0114] in:

[0115]

[0116] In equations 5 and 6, T wakeupOH This refers to the wake-up overhead time of the TWT service, dataRate is the PHY data rate used to send data packets, and PktSize is... buff It is a vector containing the size of the buffer blocks. PktSize is the average of the communication overhead and contention time for all buffered packets in a TWT session. session It is a vector containing the group sizes in the session.

[0117] exist Figure 13 In one embodiment, the start time of the TWT session is known, but TWTs can also operate in an unannounced and untriggered manner. In this case, it may be unknown when the TWT session begins. Therefore, in another embodiment where the start time of the TWT session is unknown, such as... Figure 14 As shown, T buff The time is calculated as the time between the timestamp of the end of the first packet in the session and the timestamp of the end of the last buffered packet. In this case, the data time is still expressed by the formula shown in Formula 5, but the average of the communication overhead time and contention time of all buffered packets in the TWT session is expressed by the formula:

[0118]

[0119] In the special case where there are 2 or fewer packets in a TWT session, the calculation is based on the previous TWT session. It can be reused.

[0120] In the above embodiments, packet communication overhead is ideally attributed to the request-to-send (RTS), clear-to-send (CTS), and block-acknowledgment (BACK) operations per packet in the Wi-Fi MAC layer. (See reference...) Figure 13 For example, if packet communication overhead is considered constant, then the average congestion time... It can be calculated as:

[0121]

[0122] Furthermore, the data time can be formulated as follows:

[0123]

[0124] In equations 8 and 9, The scaling factor is the average contention time calculated based on buffered packets during a TWT session, and a scaling factor is applied to represent constant packet overhead. The scaling factor also symbolizes a difference between the actual throughput and the PHY data rate. Specifically, the scaling factor depends on the efficiency of the layer in which the algorithm operates. If the algorithm runs at the MAC layer, the scaling factor can be related to the MAC efficiency of the protocol used, for example, 65% to 85%, and therefore, the scaling factor could be 0.65–0.85. If the algorithm is implemented at Layer 3 or the IP layer, the scaling factor can range from 0.5 to 0.85. The scaling factor can also be derived empirically from data collected from the device, making it more device-specific.

[0125] Another example embodiment of data time calculation can be used for network layer and higher-layer packets. Since network layer data packets are created independently of the Wi-Fi chipset, patterns for determining buffered and unbuffered data packets cannot be observed in the device's uplink data packets. These patterns are only observed in downlink packets because their transmission depends on the TWT session parameters. In this example, the above embodiment of data time calculation can be used only for downlink network layer and higher-layer packets. This embodiment and all other embodiments discussed regarding data time calculation step 1004 can be combined to improve the accuracy of data time calculation.

[0126] Refer again Figure 10Regarding the business adaptation phase of the process for adaptively updating the TWT SP duration, including steps 1006, 1008, and 1010, embodiments of this disclosure use the data time information determined in step 1004 to estimate the new TWT SP duration. In one embodiment, a continuous observation window of size N TWT sessions is evaluated, and the average data time T over the observation window is determined. avg and maximum data time T max Based on these values, overflow conditions are defined, and based on overflow conditions, it can be determined whether the TWT SP duration will be updated in periodic (or stable) updates, or whether an overflow protection update is required, in which case the TWT SP duration is updated more frequently.

[0127] Figure 15 Examples of embodiments according to this disclosure are shown. Figure 10 An example of a three-phase process for adaptively updating the TWT SP duration, with additional details of an example process for the business adaptation phase. Figure 15 In the process, the business adaptation phase is divided into two polling operations: algorithm polling 1502 (representing the stable TWT SP duration update, or...) Figure 10 Stable business adaptive step 1008) and overflow polling 1504 (indicating overflow protection TWT SP duration update, or Figure 10 Overflow protection update 1010).

[0128] Overflow polling 1504 occurs at a relatively fast rate, such as per TWT session or an integer multiple of TWT sessions. Algorithmic polling 1502 or stable updates occur at a slower rate, such as every N overflow polls, where N is the observation window size. Decision block 1506 represents a check after each overflow polling 1504 to determine whether to perform a stable update. In some embodiments, N can be set to 50 (although this can be generalized to any number, such as 40 to 60).

[0129] Figure 16 An example is shown where overflow polling occurs every 40ms, and the algorithmic polling (or stable polling) has an overflow polling window of N=3. Figure 16In the example, no overflow polling is triggered in the initial algorithm polling 1602 (or stable polling, e.g., between 1ms and 120ms), and a stable update 1604 occurs (e.g., between 120ms and 160ms). In the second stable polling 1606 (e.g., between 120ms and 240ms), an overflow condition is detected in the overflow polling 1608, and an overflow protection update 1610 (overflow update, e.g., between 200ms and 240ms) is triggered, followed by a second stable update 1612 (e.g., between 240ms and 280ms).

[0130] Back Figure 15 A stable update occurs when the arriving traffic is substantially uniform and does not deviate significantly from the past trend within the observation window. A stable update is analogous to a maximum envelope tracker of past traffic. In one embodiment, the stable update tracks T... max And whenever a new T is found in the observation window max At this time, a stable update occurs. Additionally or alternatively, the stable update may be performed at a slower rate after every N TWT sessions or after a multiple of N TWT sessions. During stable update 1502, in step 1508, T is re-evaluated for the past V TWT sessions (or overflow polling). max and T avg And in step 1510, the TWT parameters are renegotiated with the AP, based on T max and T avg One or two of the TWT SP durations for the update are determined, and a stable update protection time is added. Stable update protection is needed to accommodate any errors in the data time estimation or any changes in the input data. Furthermore, the protection provides sufficient time to adapt to an increase in the number of arriving data packets.

[0131] The stable update protection time α is formulated as a function of the TWT session parameters and the contention level in the channel (considering network conditions). The average contention time factor ε is used to represent the contention level. In one embodiment, the stable update protection time is expressed as a percentage of the TWT interval. This percentage is based on the value of ε. This percentage can be expressed as a function of ε or determined from a lookup table based on the value of ε. In one embodiment, the stable update protection time is formulated as:

[0132] α=p(ε)*interval (10)

[0133] Where interval is the TWT interval, and p is a function or lookup table based on the percentage of ε. Empirically, when ε is less than 1.8ms, p(ε) is 5%, and when ε is greater than 1.8ms, p(ε) is 10%.

[0134] In an alternative embodiment, a combination of the TWT interval and the TWT SP duration can be used to calculate the stable update protection time α. When α < ε, the stable update protection time is specified as α = ε. Combinations of these embodiments can also be used to perform stable updates.

[0135] Once the stable protection time is determined, the final TWT SP duration value of the TWT session is calculated as follows:

[0136] duration = T max +α (11)

[0137] In an alternative embodiment, the average data time over the observation window is used instead of the maximum data time, and the final TWT SP duration value for the TWT session is calculated as follows:

[0138] duration = T avg +α (12)

[0139] In another alternative embodiment, the average data time and maximum data time over the observation window are used, and the final TWT SP duration value of the TWT session is calculated as follows:

[0140] duration=x*Tmax+(1-x)*T avg +α, x∈[0,1] (13)

[0141] Where x is a contribution metric that can be adjusted to decrease or increase T. max and T avg Impact on TWT SP duration. The contribution metric is determined by the ability of the served application to accept lower effective throughput and more lenient latency requirements. If the application's latency or effective throughput requirements are high, then x will be equal to or close to 1 to maximize TWT. max The impact of this. If the application can tolerate lower effective throughput, or has more relaxed latency requirements, x can be closer to 0.5, T max and T avg The impacts are equal or roughly equal. For example, for stable business applications, T max and T avg The ratio of stable business applications is smaller than that of bursty business applications, which can be quite large. However, compared to bursty business applications, stable business applications have strict latency requirements, therefore x can be expressed as x = 1 / (T) max / T avg ).

[0142] In another alternative embodiment, when a TWT session negotiation is initiated between the AP and STA after no prior TWT session negotiation, the TWT SP duration can be calculated as follows:

[0143]

[0144] Where T obs It is the data calculation time T d The observation time. When the TWT interval value is updated, T obs It is the old TWT interval value, and T d Scaled by the ratio of the new TWT interval to the old TWT interval.

[0145] As an alternative to the above embodiment used to calculate the new TWT SP duration in a steady update, a Poisson process can be used to calculate the new TWT SP duration. For latency-sensitive applications, there may be a constant packet flow between the STA and AP. Data packets arrive according to a stochastic process, which can be modeled as a Poisson process. This model requires knowledge of λ, which is the rate at which packets arrive per second. Given the interval I and the average inter-packet arrival rate θ, the arrival rate can be calculated as:

[0146]

[0147] Then, in order to create a protection similar to a stable update, to adjust for any additional grouping by increasing the standard deviation by a factor of 2, the new TWT SP duration can be formulated as:

[0148]

[0149] Among them PktSizs avg T is the average packet size in the packet flow, ε is the average contention time per packet, and T is the average contention time per packet. wakeupOH This is the wake-up overhead associated with TWT operations, and DataRate is the PHY data rate used to send packets.

[0150] Overflow protection is crucial for bursty data arrivals. When bursts of data arrive, the TWTSP duration needs to be adjusted rapidly. Overflow protection allows for quick scaling of the TWTSP duration in the event of large influxes of data, preventing the link from saturating below its capacity due to TWT. This protection is indispensable for applications such as web browsing and video streaming, where data arrives in periodic and aperiodic bursts, while there is no traffic at other times. Because steady updates occur at a slower rate, overflow protection can be used to adjust the TWTSP duration more quickly to accommodate large influxes of traffic. This is critical; for example, if the link cannot adapt quickly, TCP congestion control might resort to a lower transmission rate.

[0151] As described above, overflow protection is triggered by overflow conditions evaluated at a rate different from the stable update rate. In one embodiment, overflow polling 1504 checks the overflow protection criterion at the end of each TWT session (step 1006). In another embodiment, overflow polling 1504 checks the overflow protection criterion after two or more TWT sessions. In a third embodiment, the rate at which overflow protection is evaluated may depend on the values ​​of the TWT interval and the TWT SP duration; for example, for shorter TWT intervals, overflow conditions are evaluated every other TWT session. In an alternative embodiment, overflow protection may be performed by evaluating consecutive overflow triggers.

[0152] The data time Td of the latest TWT session determined in step 1004 is used to evaluate the overflow situation in step 1006. The overflow situation used can be a combination of one or more of the following criteria. First, T... d -T max Whether it exceeds a certain predetermined threshold. Under this standard, an overflow update is triggered when the latest data time is greater than the maximum data time of the previous N TWT sessions by a certain threshold.

[0153] Second, T d -T avg Whether it exceeds a certain predetermined threshold. Under this standard, an overflow update is triggered when the latest data time is greater than the average data time of the previous N TWT sessions by a certain threshold.

[0154] Third, duration T d Is it less than a very small threshold (e.g., δ)? Under this criterion, an overflow update is triggered when the latest data time is very close to the currently negotiated TWT SP duration.

[0155] In embodiments using the third standard, the threshold δ is determined to be a portion of the currently negotiated TWT SP duration, the current TWT interval, or a combination of both. For small TWT SP durations and TWT intervals, the threshold is instead set to δ = ε, i.e., the average contention time, because the percentage of the TWT SP duration used as the threshold may be insufficient to send / receive any packets, resulting in trigger failure. For other cases, δ is empirically derived as 10% of the TWT SP duration.

[0156] In one embodiment, during overflow protection update 1010, the duration of the updated TWT SP is determined to be T. max The overflow update protection β is an integer multiple of the constant value. The overflow update protection β can be expressed using a formula similar to the stable update protection α, but can be any fraction higher than the stable protection update, depending on how quickly the TWT SP duration needs to adapt to the input traffic. For example, the overflow update protection β can be expressed as:

[0157] β=P overflow (ε)*interval (17)

[0158] Where P overflow It is a lookup table or function, or a function that determines the value based on the ε value. The new TWT SP duration can be calculated as follows:

[0159] duration=L*T max +β (18)

[0160] Where L is an integer multiple, chosen based on how quickly the TWT SP duration adapts to business changes. In one embodiment, L = 1, P overflow =20%. These values ​​were obtained through simulation results. These factors control the response speed of overflow protection to incoming bursts of traffic. Since the number of incoming traffic is unknown, these values ​​were chosen because they will not easily tear down the TWT, but they will also adapt to the traffic so as not to saturate active TCP connections. Higher L values ​​will allow the TWT to break down faster, and different P values ​​will be applied when an overflow is detected. overflow This will allow for finer or coarser adjustments to the TWT SP duration. For faster decomposition and conservative operations, L=2 and P can be used. overflow =40%.

[0161] Figures 17a-17c Example procedures for adaptively adjusting the TWT SP duration according to various embodiments of this disclosure are shown. For convenience, Figures 17a-17c 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.

[0162] refer to Figure 17a The process begins with the STA obtaining first information about the network status during the current TWT session and second information about packets transmitted to another communication device (e.g., an AP) (step 1705). The first information may include, for example, information discussed above regarding the calculation of the clustering threshold. The second information may include, for example, the start and end timestamps of each packet sent in the current TWT session.

[0163] Next, the process updates the TWT SP duration for future TWT sessions based on the first and second information (step 1710). Figure 17b and Figure 17c This step was discussed in more detail.

[0164] refer to Figure 17b Following step 1705, the process identifies a set of buffered packets from the transmitted packets based on second information about the transmitted packets (step 1715). This may include estimating a clustering threshold based on first information about network conditions, and identifying the set of buffered packets based on a comparison of inter-packet offsets between adjacent transmitted packets (which may have a clustering threshold such that each subsequent packet is added to the set of buffered packets starting from the start timestamp of the current TWT session until a packet with an inter-packet offset greater than the clustering threshold is found).

[0165] Next, the process estimates the data time of the current TWT session as the total amount of time required to send all the packets, based on the characteristics of the buffered group of packets (step 1720). This may include determining the characteristics of the buffered group of packets, including the number of buffered packets and the duration from the start timestamp of the current TWT session to the end timestamp of the last buffered packet in the buffered group, determining the total number of packets to be sent, and based on the total number of packets to be sent, the number of buffered packets, and the duration from the start timestamp of the current TWT session to the end timestamp of the last buffered packet in the buffered group.

[0166] The process then determines the maximum data time from the data times of multiple previous TWT sessions, as well as the average data time of the data times of multiple previous TWT sessions (step 1725).

[0167] Next, in the first embodiment, the process determines the stable update protection time based on the contention level included in the first information about network conditions (step 1730). The process then determines the new TWT SP duration based on the stable update protection time and one or more of the maximum data time and average data time of multiple previous TWT sessions (step 1735).

[0168] Finally, in a first embodiment of the process, another communication device is used to periodically update the TWT SP duration of future TWT sessions to the new TWT SP duration (step 1740). This may include, for example, negotiating the TWT SP duration with another device.

[0169] Now for reference Figure 17c Following step 1725, in the second embodiment, the process periodically assesses traffic overflow based on a comparison of the data time of the current TWT session with one of the maximum data time of a plurality of previous TWT sessions or the duration of the current TWT SP (step 1745). In some embodiments, traffic overflow can be assessed after each TWT session. Traffic overflow is satisfied when the data time of the current TWT session is greater than the maximum data time of a plurality of previous TWT sessions by a first predetermined threshold amount, or when the data time of the current TWT session is within a second predetermined threshold amount of the duration of the current TWT SP, wherein the second predetermined threshold amount is based on first information about network conditions.

[0170] When a service overflow condition is met, the process determines the overflow protection time based on the contention level included in the first information about the network condition (step 1750). Then, the process can determine a new TWT SP duration based on the overflow protection time and the maximum data time of multiple previous TWT sessions (step 1755). Finally, in a second embodiment of the process, another communication device is used to update the TWT SP duration of future TWT sessions to the new TWT SP duration (step 1760).

[0171] 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 herein. For example, although shown as a series of steps, the individual steps in each diagram can overlap, occur in parallel, occur in different orders, or occur multiple times. In another example, steps can be omitted or replaced by other steps.

[0172] Although this disclosure has been described with reference to exemplary embodiments, various changes and modifications will be apparent to those skilled in the art. This disclosure is intended to include such changes and modifications that fall within the scope of the appended claims. Nothing described herein should be construed as implying that any particular element, step, or function is essential and must be included within the scope of the claims. The scope of the patent subject matter is defined by the claims.

Claims

1. A communication apparatus comprising: a processor configured to: obtain first information about network conditions and second information about transmitted packets to another communication apparatus during a current target wake time (TWT) session; identify a set of buffered packets from among the transmitted packets based on the second information about the transmitted packets; estimate a data time of the current TWT session as a total amount of time required to send all the transmitted packets based on characteristics of the set of buffered packets; and update a TWT service period (SP) duration of a future TWT session based on the first information and the data time. the processor is further configured to:

2. The communication apparatus according to claim 1, wherein estimate a clustering threshold based on the first information about network conditions; and identify the set of buffered packets based on a comparison of an inter-packet offset between adjacent transmitted packets and the clustering threshold, such that each subsequent packet is added to the set of buffered packets from a start timestamp of the current TWT session until a packet is found whose inter-packet offset from a previous adjacent packet is greater than the clustering threshold. the processor is further configured to:

3. The communication apparatus according to claim 1, wherein determine characteristics of the set of buffered packets, including a number of buffered packets and a duration from a start timestamp of the current TWT session to an end timestamp of a last buffered packet in the set of buffered packets; determine a total number of the transmitted packets; and estimate the data time of the current TWT session based on the total number of the transmitted packets, the number of buffered packets, and the duration from the start timestamp of the current TWT session to the end timestamp of the last buffered packet in the set of buffered packets. the processor is further configured to: determine a maximum data time from among data times of a plurality of previous TWT sessions, and an average data time of the data times of the plurality of previous TWT sessions; 4. The communication apparatus according to claim 3, wherein determine a stable update guard time based on a contention level included in the first information about network conditions; determine a new TWT SP duration based on the stable update guard time and one or more of the maximum data time and the average data time of the plurality of previous TWT sessions; and periodically update the TWT SP duration of a future TWT session to the new TWT SP duration with another communication apparatus. the processor is further configured to: determine a maximum data time from among data times of a plurality of previous TWT sessions; periodically evaluate a traffic overflow condition based on a comparison of the data time of the current TWT session and one of the maximum data time of the plurality of previous TWT sessions or a current TWT SP duration; 5. The communication apparatus according to claim 3, wherein determine an overflow guard time based on a contention level included in the first information about network conditions based on the traffic overflow condition being satisfied; determine a new TWT SP duration based on a multiple of the overflow guard time and the maximum data time of the plurality of previous TWT sessions based on the traffic overflow condition being satisfied; and ​ ​ ​ ​ updating, with another communication device, a TWT SP duration for a future TWT session to a new TWT SP duration based on satisfying the traffic spill condition.

6. The communication device of claim 5, wherein: the processor is further configured to evaluate the traffic spill condition after each TWT session, and the traffic spill condition is satisfied when: a data time of a current TWT session is greater than a maximum data time of the plurality of previous TWT sessions by a first predetermined threshold amount, or a data time of a current TWT session is within a second predetermined threshold amount of a current TWT SP duration, wherein the second predetermined threshold amount is based on the first information regarding network conditions.

7. A method for wireless communication, comprising: obtaining first information regarding network conditions and second information regarding transmitted packets to another communication device during a current target wake time (TWT) session; identifying, based on the second information regarding the transmitted packets, a set of buffered packets from among the transmitted packets; estimating, based on characteristics of the set of buffered packets, a data time of a current TWT session as a total amount of time required to send all of the transmitted packets; and updating, with another communication device, a TWT service period (SP) duration for a future TWT session to a new TWT SP duration based on the first information and the data time.

8. The method of claim 7, further comprising: estimating, based on the first information regarding network conditions, a clustering threshold; and identifying the set of buffered packets based on a comparison of inter-packet offsets between adjacent transmitted packets to the clustering threshold, such that each subsequent packet is added to the set of buffered packets from a start timestamp of the current TWT session until a packet is found whose inter-packet offset to a previous adjacent packet is greater than the clustering threshold.

9. The method of claim 7, further comprising: determining characteristics of the set of buffered packets, including a number of buffered packets and a duration from a start timestamp of the current TWT session to an end timestamp of a last buffered packet in the set of buffered packets; determining a total number of the transmitted packets; and estimating the data time of the current TWT session based on the total number of the transmitted packets, the number of buffered packets, and the duration from the start timestamp of the current TWT session to the end timestamp of the last buffered packet in the set of buffered packets.

10. The method of claim 9, further comprising: determining, from among data times of a plurality of previous TWT sessions, a maximum data time and an average data time of the data times of the plurality of previous TWT sessions; determining a stable update guard time based on a contention level included in the first information regarding network conditions; determining a new TWT SP duration based on the stable update guard time and one or more of the maximum data time and the average data time of the plurality of previous TWT sessions; and periodically updating, with another communication device, the TWT SP duration for a future TWT session to the new TWT SP duration.

11. The method of claim 9, further comprising: determining a maximum data time from among data times of a plurality of previous TWT sessions; periodically evaluating a traffic overflow condition based on a comparison of a data time of a current TWT session to one of the maximum data time of the plurality of previous TWT sessions or a current TWT SP duration; based on the traffic overflow condition being satisfied, determining an overflow protection time based on a contention level included in the first information regarding network conditions; based on the traffic overflow condition being satisfied, determining a new TWT SP duration based on a multiple of the overflow protection time and the maximum data time of the plurality of previous TWT sessions; and based on the traffic overflow condition being satisfied, updating, with another communication device, a TWT SP duration of a future TWT session to the new TWT SP duration.

12. The method of claim 11, wherein: the method further comprises evaluating the traffic overflow condition after each TWT session, and the traffic overflow condition is satisfied when: the data time of the current TWT session is greater than the maximum data time of the previous TWT session by a first predetermined threshold amount, or the data time of the current TWT session is within a second predetermined threshold amount of the current TWT SP duration, wherein the second predetermined threshold amount is based on the first information regarding network conditions.

13. A non-transitory computer-readable medium configured to store instructions that, when executed by a processor, cause the processor to: obtain first information regarding network conditions and second information regarding transmitted packets to another communication device during a current target wake time (TWT) session; identify, based on the second information regarding the transmitted packets, a set of buffered packets from among the transmitted packets; estimate, based on characteristics of the set of buffered packets, a data time of the current TWT session as a total amount of time required to send all of the transmitted packets; and update, based on the first information and the data time, a TWT service period (SP) duration of a future TWT session. ​

Images