SYSTEM AND METHOD FOR TRAFFIC TYPE DETECTION AND WI-FI TARGET WAKE TIME PARAMETER DESIGN

Abstract

A method includes obtaining statistical information of incoming network traffic. The method also includes using a state machine to classify the incoming network traffic as a traffic pattern based on the statistical information. The method further includes using the traffic pattern to adapt one or more Target Wakeup Time (TWT) parameters to optimize power consumption of a Wi-Fi station. The traffic pattern includes at least one of bursty traffic, random traffic, and stable traffic.

Claims

1. A method comprising: obtaining statistical information of incoming network traffic; using a state machine to classify the incoming network traffic as a traffic pattern based on the statistical information; and using the traffic pattern to adapt one or more Target Wakeup Time (TWT) parameters to optimize power consumption of a Wi-Fi station, wherein the traffic pattern includes at least one of bursty traffic, random traffic, and stable traffic.

2. The method of claim 1, wherein using the state machine to classify the incoming network traffic as the traffic pattern based on the statistical information comprises: obtaining at least one statistical value of the incoming network traffic from the statistical information; determining which of a plurality of state transition conditions is met based on a comparison between the at least one statistical value of the incoming network traffic and one or more predetermined threshold values; inputting the met state transition condition and a previous traffic pattern of the incoming network traffic to the state machine to classify the incoming network traffic as the traffic pattern; and outputting the traffic pattern from the state machine.

3. The method of claim 2, wherein the at least one statistical value comprises one or more of: a throughput of the incoming network traffic, a moving average of the throughput of the incoming network traffic, or a time duration of a current burst of the incoming network traffic.

4. The method of claim 2, wherein the plurality of state transition conditions are grouped as bursty traffic conditions, stable traffic conditions, and random traffic conditions.

5. The method of claim 1, wherein: the one or more TWT parameters comprises at least one of: an overflow threshold, an overflow threshold percentage, an overflow guard, and overflow update, a stable guard, a stable update, a boost multiplier, or a boost offset; and using the traffic pattern to adapt the one or more TWT parameters to optimize power consumption of the Wi-Fi station comprises using a different calculation or value for the one or more TWT parameters depending on whether the traffic pattern is bursty traffic, random traffic, or stable traffic.

6. The method of claim 1, wherein obtaining the statistical information of the incoming network traffic comprises: obtaining first statistical information of the incoming network traffic at a fine time scale; and obtaining second statistical information of the incoming network traffic at a coarse time scale having a longer observation window than the fine time scale.

7. The method of claim 6, wherein obtaining the statistical information of the incoming network traffic further comprises: comparing a first variance of the first statistical information to a second variance of the second statistical information; determining whether a pattern of the incoming network traffic has changed based on the comparison between the first variance and the second variance; in response to determining that the pattern of the incoming network traffic has changed, obtaining third statistical information of the incoming network traffic at the fine time scale; and in response to determining that the pattern of the incoming network traffic has not changed, continuing to obtain the second statistical information of the incoming network traffic at the coarse time scale.

8. A device comprising: a memory configured to store instructions; and a processor operably connected to the memory, the processor configured when executing the instructions to: obtain statistical information of incoming network traffic; use a state machine to classify the incoming network traffic as a traffic pattern based on the statistical information; and use the traffic pattern to adapt one or more Target Wakeup Time (TWT) parameters to optimize power consumption of a Wi-Fi station, wherein the traffic pattern includes at least one of bursty traffic, random traffic, and stable traffic.

9. The device of claim 8, wherein to use the state machine to classify the incoming network traffic as the traffic pattern based on the statistical information, the processor is configured to: obtain at least one statistical value of the incoming network traffic from the statistical information; determine which of a plurality of state transition conditions is met based on a comparison between the at least one statistical value of the incoming network traffic and one or more predetermined threshold values; input the met state transition condition and a previous traffic pattern of the incoming network traffic to the state machine to classify the incoming network traffic as the traffic pattern; and output the traffic pattern from the state machine.

10. The device of claim 9, wherein the at least one statistical value comprises one or more of: a throughput of the incoming network traffic, a moving average of the throughput of the incoming network traffic, or a time duration of a current burst of the incoming network traffic.

11. The device of claim 9, wherein the plurality of state transition conditions are grouped as bursty traffic conditions, stable traffic conditions, and random traffic conditions.

12. The device of claim 8, wherein: the one or more TWT parameters comprises at least one of: an overflow threshold, an overflow threshold percentage, an overflow guard, and overflow update, a stable guard, a stable update, a boost multiplier, or a boost offset; and to use the traffic pattern to adapt the one or more TWT parameters to optimize power consumption of the Wi-Fi station, the processor is configured to use a different calculation or value for the one or more TWT parameters depending on whether the traffic pattern is bursty traffic, random traffic, or stable traffic.

13. The device of claim 8, wherein to obtain the statistical information of the incoming network traffic, the processor is configured to: obtain first statistical information of the incoming network traffic at a fine time scale; and obtain second statistical information of the incoming network traffic at a coarse time scale having a longer observation window than the fine time scale.

14. The device of claim 13, wherein to obtain the statistical information of the incoming network traffic, the processor is further configured to: compare a first variance of the first statistical information to a second variance of the second statistical information; determine whether a pattern of the incoming network traffic has changed based on the comparison between the first variance and the second variance; in response to determining that the pattern of the incoming network traffic has changed, obtain third statistical information of the incoming network traffic at the fine time scale; and in response to determining that the pattern of the incoming network traffic has not changed, continue to obtain the second statistical information of the incoming network traffic at the coarse time scale.

15. A non-transitory computer readable medium comprising a plurality of instructions that, when executed by at least one processor, is configured to cause the at least one processor to: obtain statistical information of incoming network traffic; use a state machine to classify the incoming network traffic as a traffic pattern based on the statistical information; and use the traffic pattern to adapt one or more Target Wakeup Time (TWT) parameters to optimize power consumption of a Wi-Fi station, wherein the traffic pattern includes at least one of bursty traffic, random traffic, and stable traffic.

16. The non-transitory computer readable medium of claim 15, wherein to use the state machine to classify the incoming network traffic as the traffic pattern based on the statistical information, the plurality of instructions is configured to cause the at least one processor to: obtain at least one statistical value of the incoming network traffic from the statistical information; determine which of a plurality of state transition conditions is met based on a comparison between the at least one statistical value of the incoming network traffic and one or more predetermined threshold values; input the met state transition condition and a previous traffic pattern of the incoming network traffic to the state machine to classify the incoming network traffic as the traffic pattern; and output the traffic pattern from the state machine.

17. The non-transitory computer readable medium of claim 16, wherein the at least one statistical value comprises one or more of: a throughput of the incoming network traffic, a moving average of the throughput of the incoming network traffic, or a time duration of a current burst of the incoming network traffic.

18. The non-transitory computer readable medium of claim 15, wherein: the one or more TWT parameters comprises at least one of: an overflow threshold, an overflow threshold percentage, an overflow guard, and overflow update, a stable guard, a stable update, a boost multiplier, or a boost offset; and to use the traffic pattern to adapt the one or more TWT parameters to optimize power consumption of the Wi-Fi station, the plurality of instructions is configured to cause the at least one processor to use a different calculation or value for the one or more TWT parameters depending on whether the traffic pattern is bursty traffic, random traffic, or stable traffic.

19. The non-transitory computer readable medium of claim 15, wherein to obtain the statistical information of the incoming network traffic, the plurality of instructions is configured to cause the at least one processor to: obtain first statistical information of the incoming network traffic at a fine time scale; and obtain second statistical information of the incoming network traffic at a coarse time scale having a longer observation window than the fine time scale.

20. The non-transitory computer readable medium of claim 19, wherein to obtain the statistical information of the incoming network traffic, the plurality of instructions is configured to cause the at least one processor to: compare a first variance of the first statistical information to a second variance of the second statistical information; determine whether a pattern of the incoming network traffic has changed based on the comparison between the first variance and the second variance; in response to determining that the pattern of the incoming network traffic has changed, obtain third statistical information of the incoming network traffic at the fine time scale; and in response to determining that the pattern of the incoming network traffic has not changed, continue to obtain the second statistical information of the incoming network traffic at the coarse time scale.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

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

[0014] FIG. 1 illustrates an example wireless network according to embodiments of the present disclosure;

[0015] FIG. 2A illustrates an example AP according to embodiments of the present disclosure;

[0016] FIG. 2B illustrates an example STA according to embodiments of the present disclosure;

[0017] FIG. 3 illustrates a diagram of packet exchange between devices according to embodiments of the present disclosure;

[0018] FIG. 4 illustrates an example TWT parameter set field used for TWT parameter negotiation according to embodiments of the present disclosure;

[0019] FIG. 5 illustrates an offset in a TWT session according to embodiments of the present disclosure;

[0020] FIG. 6 illustrates an example TWT information frame according to embodiments of the present disclosure;

[0021] FIG. 7 illustrates an example of early termination of TWT according to embodiments of the present disclosure;

[0022] FIG. 8 illustrates a diagram showing example traffic types that can be exhibited by network services according to embodiments of the present disclosure;

[0023] FIG. 9 illustrates details of an example state machine for use in traffic type detection and classification according to embodiments of the present disclosure;

[0024] FIG. 10 illustrates example traffic classes and state transition conditions according to embodiments of the present disclosure;

[0025] FIG. 11 illustrates example results from the traffic type detection technique described in FIGS. 9 and 10 according to embodiments of the present disclosure;

[0026] FIG. 12 illustrates an example of the state machine of FIG. 9 transitioning among three traffic types according to embodiments of the present disclosure;

[0027] FIGS. 13A and 13B illustrate an example of a technique for releasing and resuming TWT according to embodiments of the present disclosure;

[0028] FIG. 14 illustrates a diagram showing an example of fine and coarse time-scale for traffic statistics observation according to embodiments of the present disclosure;

[0029] FIG. 15 illustrates example charts showing the same traffic statistics of packet number observed in fine time scale and coarse time scale, according to embodiments of the present disclosure;

[0030] FIG. 16 illustrates an example process for dynamically updating network statistics variation according to embodiments of the present disclosure;

[0031] FIG. 17 illustrates a chart showing an example of using the process of FIG. 16 according to embodiments of the present disclosure; and

[0032] FIG. 18 illustrates a method for traffic type detection and Wi-Fi parameter design according to embodiments of the present disclosure.

DETAILED DESCRIPTION

[0033] FIGS. 1 through 18, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understand that the principles of the present disclosure may be implemented in any suitably arranged system or device.

[0034] Aspects, features, and advantages of the disclosure are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the disclosure. The disclosure is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive. The disclosure is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

[0035] The present disclosure covers several components which can be used in conjunction or in combination with one another, or can operate as standalone schemes.

[0036] FIG. 1 illustrates an example wireless network 100 according to various embodiments of the present disclosure. The embodiment of the wireless network 100 shown in FIG. 1 is for illustration only. Other embodiments of the wireless network 100 could be used without departing from the scope of this disclosure.

[0037] The wireless network 100 includes access points (APs) 101 and 103. The APs 101 and 103 communicate with at least one network 130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. The AP 101 provides wireless access to the network 130 for a plurality of stations (STAs) 111-114 within a coverage area 120 of the AP 101. The APs 101-103 may communicate with each other and with the STAs 111-114 using Wi-Fi or other WLAN communication techniques.

[0038] Depending on the network type, other well-known terms may be used instead of “access point” or “AP,” such as “router” or “gateway.” For the sake of convenience, the term “AP” is used in this disclosure to refer to network infrastructure components that provide wireless access to remote terminals. In WLAN, given that the AP also contends for the wireless channel, the AP may also be referred to as a STA. Also, 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 device.” For the sake of convenience, the terms “station” and “STA” are used in this disclosure to refer to remote wireless equipment that wirelessly accesses an AP or contends for a wireless channel in a WLAN, whether the STA is a mobile device (such as a mobile telephone or smartphone) or is normally considered a stationary device (such as a desktop computer, AP, media player, stationary sensor, television, etc.).

[0039] Dotted lines show the approximate extents of the coverage areas 120 and 125, which are shown as approximately circular for the purposes of illustration and explanation only. It should be clearly understood that the coverage areas associated with APs, such as the coverage areas 120 and 125, may have other shapes, including irregular shapes, depending upon the configuration of the APs and variations in the radio environment associated with natural and man-made obstructions.

[0040] As described in more detail below, one or more of the APs may include circuitry and/or programming for determining parameters for target wake time (TWT) operations in WLANs (e.g., the TWT interval). Although FIG. 1 illustrates one example of a wireless network 100, various changes may be made to FIG. 1. For example, the wireless network 100 could include any number of APs and any number of STAs in any suitable arrangement. Also, the AP 101 could communicate directly with any number of STAs and provide those STAs with wireless broadband access to the network 130. Similarly, each AP 101-103 could communicate directly with the network 130 and provide STAs with direct wireless broadband access to the network 130. Further, the APs 101 and/or 103 could provide access to other or additional external networks, such as external telephone networks or other types of data networks.

[0041] FIG. 2A illustrates an example AP 101 according to various embodiments of the present disclosure. The embodiment of the AP 101 illustrated in FIG. 2A is for illustration only, and the AP 103 of FIG. 1 could have the same or similar configuration. However, APs come in a wide variety of configurations, and FIG. 2A does not limit the scope of this disclosure to any particular implementation of an AP.

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

[0043] The TX processing circuitry 214 receives analog or digital data (such as voice data, web data, e-mail, or interactive video game data) from the controller/processor 224. The TX processing circuitry 214 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceivers 209a-209n receive the outgoing processed baseband or IF signals from the TX processing circuitry 214 and up-converts the baseband or IF signals to RF signals that are transmitted via the antennas 204a-204n.

[0044] The controller/processor 224 can include one or more processors or other processing devices that control the overall operation of the AP 101. For example, the controller/processor 224 could control the reception of uplink channel signals and the transmission of downlink channel signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 in accordance with well-known principles. The controller/processor 224 could support additional functions as well, such as more advanced wireless communication functions. For instance, the controller/processor 224 could support beam forming or directional routing operations in which outgoing signals from multiple antennas 204a-204n are weighted differently to effectively steer the outgoing signals in a desired direction. The controller/processor 224 could also support OFDMA operations in which outgoing signals are assigned to different subsets of subcarriers for different recipients (e.g., different STAs 111-114). Any of a wide variety of other functions could be supported in the AP 101 by the controller/processor 224 including determining parameters for TWT operations. 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 resident in the memory 229, such as an OS. The controller/processor 224 can move data into or out of the memory 229 as required by an executing process.

[0045] The controller/processor 224 is also coupled to the backhaul or network interface 234. The backhaul or network interface 234 allows the AP 101 to communicate with other devices or systems over a backhaul connection or over a network. The interface 234 could support communications over any suitable wired or wireless connection(s). For example, the interface 234 could allow the AP 101 to communicate over a wired or wireless local area network or over a wired or wireless connection to a larger network (such as the Internet). The interface 234 includes any suitable structure supporting communications over a wired or wireless connection, such as an Ethernet or RF transceiver. The memory 229 is coupled to the controller/processor 224. Part of the memory 229 could include a RAM, and another part of the memory 229 could include a Flash memory or other ROM.

[0046] As described in more detail below, the AP 101 may include circuitry and/or programming for determining parameters for TWT operations in WLANs (e.g., the TWT interval). Although FIG. 2A illustrates one example of AP 101, various changes may be made to FIG. 2A. For example, the AP 101 could include any number of each component shown in FIG. 2A. As a particular example, an access point could include a number of interfaces 234, and the controller/processor 224 could support routing functions to route data between different network addresses. As another particular example, while shown as including a single instance of TX processing circuitry 214 and a single instance of RX processing circuitry 219, the AP 101 could include multiple instances of each (such as one per RF transceiver). Alternatively, only one antenna and RF transceiver path may be included, such as in legacy APs. Also, various components in FIG. 2A could be combined, further subdivided, or omitted and additional components could be added according to particular needs.

[0047] FIG. 2B illustrates an example STA 111 according to various embodiments of this disclosure. The embodiment of the STA 111 illustrated in FIG. 2B is for illustration only, and the STAs 112-114 of FIG. 1 could have the same or similar configuration. However, STAs come in a wide variety of configurations, and FIG. 2B does not limit the scope of this disclosure to any particular implementation of a STA.

[0048] The STA 111 includes antenna(s) 205, a radio frequency (RF) transceiver 210, TX processing circuitry 215, a microphone 220, and receive (RX) processing circuitry 225. The 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 a memory 260. The memory 260 includes an operating system (OS) 261 and one or more applications 262.

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

[0050] The TX processing circuitry 215 receives analog or digital voice data from the microphone 220 or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the controller/processor 240. The TX processing circuitry 215 encodes, multiplexes, and/or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver 210 receives the outgoing processed baseband or IF signal from the TX processing circuitry 215 and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna(s) 205.

[0051] The controller/processor 240 can include one or more processors and execute the basic OS program 261 stored in the memory 260 in order to control the overall operation of the STA 111. In one such operation, the main controller/processor 240 controls the reception of downlink channel signals and the transmission of uplink channel signals by the RF transceiver 210, the RX processing circuitry 225, and the TX processing circuitry 215 in accordance with well-known principles. The main controller/processor 240 can also include processing circuitry configured to determine parameters for TWT operations in WLANs (e.g., the TWT interval). In some embodiments, the controller/processor 240 includes at least one microprocessor or microcontroller.

[0052] The controller/processor 240 is also capable of executing other processes and programs resident in the memory 260, such as operations for determining parameters for TWT operations in WLANs. The controller/processor 240 can move data into or out of the memory 260 as required by an executing process. In some embodiments, the controller/processor 240 is configured to execute a plurality of applications 262, such as applications for determining an idle or active state of the Wi-Fi link, and determining TWT parameters such as the TWT interval for TWT operation. The controller/processor 240 can operate the plurality of applications 262 based on the OS program 261 or in response to a signal received from an AP. The main controller/processor 240 is also coupled to the I/O interface 245, which provides 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.

[0053] The controller/processor 240 is also coupled to the touchscreen 250 and the display 255. The operator of the STA 111 can use the touchscreen 250 to enter data into the STA 111. The display 255 may be a liquid crystal display, light emitting diode display, or other display capable of rendering text and/or at least limited graphics, such as from web sites. The memory 260 is coupled to the controller/processor 240. Part of the memory 260 could include a random access memory (RAM), and another part of the memory 260 could include a Flash memory or other read-only memory (ROM).

[0054] Although FIG. 2B illustrates one example of STA 111, various changes may be made to FIG. 2B. For example, various components in FIG. 2B could be combined, further subdivided, or omitted and additional components could be added according to particular needs. In particular examples, the STA 111 may include any number of antenna(s) 205 for MIMO communication with an AP 101. In another example, the STA 111 may not include voice communication or the controller/processor 240 could be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, while FIG. 2B illustrates the STA 111 configured as a mobile telephone or smartphone, STAs could be configured to operate as other types of mobile or stationary devices.

[0055] FIG. 3 illustrates a diagram 300 of packet exchange between devices according to embodiments of the present disclosure. For the purposes of this disclosure, the figures will be discussed from the point of view of a STA, which may be a STA 111, but it is understood that it could be any suitable wireless communication device.

[0056] FIG. 3 illustrates two scenarios of exchange of uplink (UL) communication packets and downlink (DL) communication packets (which may be collectively referred to as traffic) between an AP and an associated client STA. First, without wake time negotiation between the AP and the STA (e.g., as seen in the top graph 302), and second, with wake time negotiation between the AP and the STA (e.g., in an IEEE 802.11ax system and as seen in the bottom graph 304). In the top graph 302, there is a regular stream of non-buffered traffic between the AP and the STA, with UL packets being interspersed with DL packets. In this scenario (i.e., without wake time negotiation) there is no option for the STA to enter a doze state or a power save state.

[0057] By contrast, in the bottom graph 304, wake time negotiation gives rise to consecutive TWT sessions 306. Each TWT session 306 is defined as the time period from the beginning of a TWT interval 308 to the end of the TWT interval 308. Each TWT session 306 includes two states: an active state 311, defined by a TWT service period (SP) duration 310 (during which the STA is awake to communicate with the AP), and a power save state or doze state 312 (during which the STA is not actively awake or communicating with the AP). As a result of wake time negotiation, power efficiency at the STA is improved without adding too much latency or allowing UL or DL packets to be dropped.

[0058] In wake time negotiation, the negotiated TWT parameters include the wake interval (e.g., the TWT interval 308 for each TWT session 306), wake duration (e.g. the TWT SP duration 310 for each TWT session 306), and initial wake time or offset (e.g., indicated by the TWT start time 314). These negotiated parameters highly affect latency, throughput, and power efficiency, which are directly related to the QoS (quality of service) a customer experiences. Services with different traffic characteristics can have different TWT parameter configurations for better QoS. Additionally, the TWT configuration should adapt to network and service status variation.

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

[0060] The target wake time 406 and nominal minimum TWT wake duration 408 subfields specify, respectively, the first wake time for the TWT agreement, and the time for which the STA must wait before going to doze state when there is no transmitted traffic after a wake time, which is the TWT SP duration 310 in FIG. 3.

[0061] Other than the wake interval and wake duration, offset is also an important impact factor on the user experience, as the offset could affect the latency. FIG. 5 illustrates an offset in a TWT session according to embodiments of the present disclosure. Different offsets 502 introduce a different additional TWT related latency. TWT interval 308 and offset 502 together define the additional latency introduced by TWT. After TWT negotiation setup, the offset 502 can be adjusted by the field “Next TWT” 602 in the example TWT information frame 600 illustrated in FIG. 6.

[0062] FIG. 7 illustrates an example of early termination of TWT according to embodiments of the present disclosure. In various embodiments, the actual TWT SP duration 310 is dynamically determined in run time by the aforementioned nominal minimum TWT wake duration, and the STA enters the doze state 312 when a packet is received with EOSP (end of service period) bit set to “1”, or more data bit set to “0”. Depending on whether or not early termination is supported, the time the STA enters the doze state 312 will be slightly different. As shown in the graph 702, if the STA supports early termination then once the STA receives a packet with EOSP bit set to “1” or more data bit “0” the STA can enter doze state 312 (although there could be a slight delay between reception of the packet and entering doze state 312). If the STA does not support early termination, then it will wait until the end of the TWT SP duration 310 to enter doze state 312, as shown in graph 304.

[0063] TWT can help save device power by setting a specific STA wakeup interval and the wakeup SP, which can reduce the time and power consumption that the STA is awake but with no data exchange between the AP and the STA. The adjusted TWT parameters, including the TWT wakeup interval and the wakeup SP, need to meet the requirement that the overall throughput of the traffic is not impacted and little or no additional latency is introduced, while achieving a minimal duty cycle.

[0064] Though the TWT parameters are adjusted to accommodate the incoming traffic, direct information of the incoming traffic's statistics may not be available, and thus the TWT parameters can only be estimated from the previously observed traffic statistics. Fortunately, many network services show some specific traffic patterns which enables a good estimation of the incoming traffic's statistics based on the past observations.

[0065] FIG. 8 illustrates example traffic types 801-803 that can be exhibited by network services according to embodiments of the present disclosure. As shown in FIG. 8, the network services can exhibit any of three types of traffic types or patterns. These types includes bursty traffic 801, stable traffic 802, and random traffic 803.

[0066] The bursty traffic 801 features a periodic “burst” or large throughput, as shown in FIG. 8. When the data in the local buffer is low or empty, the large throughput can be observed to transmit the data to fill the local buffer. After the buffer is filled, relatively low and stable throughput (identified as the “valley” in FIG. 8) can be observed until the local buffer is close to empty for refilling again. The bursty traffic can often be seen in various streaming services such as YOUTUBE LIVE streaming and YOUTUBE video.

[0067] The stable traffic 802 features a relative constant throughput with small variations, which can often be observed in some IM calling or teleconferencing applications, such as WHATSAPP audio calling or ZOOM video conferencing.

[0068] The random traffic 803 often shows random variations of traffic throughput, which is difficult to predict. The random traffic 803 can be observed in web browsing and other applications in which the user interaction with the smart phone or device is hard to predict.

[0069] In order to detect the three traffic types, a real-time traffic type classification method is needed. After determination of the traffic types, the TWT parameter settings can be customized for each traffic type based on their throughput variation pattern. The customized TWT parameter design may prioritize a minimal impact to user experience (e.g., minimal impact on latency or service quality), while saving the most power.

[0070] There are a number of design criteria that can be implemented in detecting traffic type. For example, for bursty traffic, it can be important to have a low false detection rate. A reduced TWT duty cycle method can be applied to bursty traffic to trade off buffer filling speed with more aggressive power saving. A reduced TWT duty cycle method can cause QoS issues for other traffic types. Thus, bursty traffic requires a low false detection rate. Stable traffic typically requires relatively low false detection and high accuracy. Only a small margin in the TWT duty cycle is needed. Random traffic typically requires high accuracy and needs to have a large margin for the TWT duty cycle to accommodate sudden random traffic variation.

[0071] Another practical issue raised from the traffic type-based TWT parameter design is the observation frequency of the traffic statistics limited by the device. While the TWT parameter design should accommodate the variation of traffic statistics at the scale of a TWT interval (e.g., 20 ms to 80 ms), the traffic statistics often can only be observed at a coarse time scale (e.g., 500 ms), which has averaged out the statistics variation at a small time scale of the TWT interval. Thus, a method is needed to estimate the traffic statistics variation at a fine time scale with the observations from a coarse time scale.

[0072] To address these and other issues, this disclosure provides a system and method for traffic type detection and Wi-Fi target wake time parameter design. As described in more detail below, the disclosed embodiments can accurately classify the bursty, stable and random traffic patterns discussed above. The disclosed embodiments can also utilize the information of the traffic pattern to minimize the impact of TWT to user experience while saving the most power. In addition, the disclosed embodiments can estimate fine (small) time-scale traffic statistics based on observations on a coarse (large) time scale.

[0073] While the variation of throughput can be the feature to classify the traffic, it is also possible to use the variation of the required minimum TWT wakeup time/service period to support the current throughput as the criteria to classify different traffic types. In the following description, the throughput is used as an example parameter that is used to classify the traffic, but the same method can also be applied to classifying the traffic based on TWT wakeup time/service period.

[0074] FIG. 9 illustrates details of an example state machine 900 for use in traffic type detection and classification according to embodiments of the present disclosure. The state machine 900 can be used to classify network traffic for a TWT session. For ease of explanation, the state machine 900 will be described as being implemented by a STA, such as one of the STAs 111-114 of FIG. 1. However, the state machine 900 can be implemented by any suitable device. The embodiment of the state machine 900 shown in FIG. 9 is for illustration only. Other embodiments of the state machine 900 could be used without departing from the scope of this disclosure.

[0075] As shown in FIG. 9, the state machine 900 includes five internal states (State 0-State 4) and nine conditions (Condition 1-Condition 9) for the transitions among each state. For State 0 (the initial and default state) and State 1, the output of the state machine 900 (i.e., the classification result) is a random traffic class. For State 2, the output is a stable traffic class. For State 3 and State 4, the output will depend on the value of C.sub.v,b and C.sub.b,v, which represent the number of valley-bursts and burst-valleys, respectively, that have been observed. As shown in FIG. 9, the value of C.sub.v,b will increase by 1 if a valley and then a burst is observed. Similarly, the value of C.sub.b,v will increase by 1 if a burst and then a valley is observed. The values of C.sub.v,b and C.sub.b,v are compared to N.sub.1 and N.sub.2, respectively, which are predetermined threshold values. If the value of C.sub.v,b or C.sub.b,v is larger than N.sub.1 or N.sub.2, then the current traffic is classified as bursty traffic. Otherwise, the output of State 3 and State 4 is a random traffic class. In some embodiments, the value of N.sub.1 or N.sub.2 or both can be increased in order to make the classification criteria of bursty traffic more strict and to make the false detection rate of bursty traffic be further reduced. In the meantime, the detection time required to confirm a bursty traffic can also be increased. A typical value range of N.sub.1 or N.sub.2 is 0 to 3. In some embodiments, a value of 0 is used for a faster detection of bursty traffic.

[0076] For better understanding of the nine conditions for state transition, the conditions can be arranged into three groups based on the traffic type detection results they may lead to. FIG. 10 illustrates the three traffic classes and the state transition conditions that may lead to each traffic class according to embodiments of the present disclosure. As shown in FIG. 10, the state transition conditions can be grouped as follows:

[0077] Bursty Traffic Conditions: Conditions 1, 3, 4.

[0078] Stable Traffic Conditions: Conditions 1, 2, 5.

[0079] Random Traffic Conditions: Conditions 6, 7, 8, 9

[0080] The Bursty traffic conditions are criteria to transition from random or stable traffic to bursty traffic, which will now be discussed.

Condition 1

[0081] Condition 1 finds the initial stable part of the traffic characterized by State 1. This initial stable part can either be the beginning of the stable traffic or the valley of the bursty traffic. In essence, Condition 1 indicates whether there are sudden increases in both the instantaneous throughput and the average throughput. If such sudden increases are absent, then it can be inferred that stable traffic may be present. Condition 1 can be expressed as follows:

|ΔP.sub.i|≤Th.sub.1 (for i=N−k.sub.1+1, N−k.sub.1+2 , . . . , N)

AND

|P.sub.N−MA.sub.i.sup.k.sup.1(P.sub.i)|≤Th.sub.2,

where

[00001]${\mathrm{MA}}_i^{k_1}\left(P_i\right)=\frac{1}{k_1}{.Math.}_{i=N-k_1+1}^N{P}_i$

is the moving average of P.sub.i with a window size of k.sub.1, P.sub.N is the throughput of the most recent observation, Th.sub.1 and Th.sub.2 are predetermined threshold values, i represents an observation time point, and N is the latest observation time point.

[0082] The value of the moving average window size k.sub.1 can be determined empirically offline through observing the typical length of the initial stable valley part of the bursty traffic. A typical value of k.sub.1 used for Condition 1 is 5. Typical values of Th.sub.1 and Th.sub.2 are 0.1 Mbyte/s and 0.12 Mbyte/s. The P.sub.i is the throughput at the ith observation, and ΔP.sub.i=P.sub.i−P.sub.i−1 is the change of throughput between each pair of observations.

[0083] The first equation in Condition 1 can ensure that variation of the throughput is small between each pair of observations, and the second equation ensures that the throughput remains stable and flat instead of continuing to increase or decrease. If Condition 1 is satisfied, then the state machine 900 transitions from State 0 to State 1. Condition 1 is used to find the initial stable part of the traffic characterized by State 1. If the traffic throughput continues to remain stable, then the state machine 900 would transition to State 2 for stable traffic classification. Otherwise, if a burst is observed, the state machine 900 would transition to State 3 and may lead to the classification as bursty traffic.

Condition 3

[0084] Condition 3 is provided to identify the burst part of the bursty traffic. Condition 3 can be expressed as follows:

ΔP.sub.i>Th.sub.b OR Σ.sub.i=N−j.sup.NΔP.sub.i>w.Math.Th.sub.b

where Th.sub.b is a predetermined threshold value, w is an empirically determined weighting value, and j represents a number of observation times.

[0085] Condition 3 can find the time that a sudden increase of the throughput (denoted by ΔP.sub.i) is larger than Th.sub.b. Meanwhile, for bursty traffic, sometimes the throughput might not see a sudden steep jump between two observation times. Thus the condition that the sum of the throughput increases within j observation times being larger than w.Math.Th.sub.b can also be used. In some embodiments, it is determined to set j=2 and w=1.6. A typical value of Th.sub.b is 0.4 Mbyte/s. After entering State 3 (burst after stable state), the next valley of the bursty traffic is determined by testing when Condition 6 will be satisfied. Condition 4 consists of Condition 1 (which ensures a stable traffic pattern) and an additional condition that the moving average of the current valley's throughput must be similar to the moving average of the throughput of the previous valleys of the bursty traffic. This is the based on the fact that the throughput of the valley part of one bursty traffic should remain relatively similar.

Condition 4

[0086] Condition 4 is provided to identify the valley part after a burst in the bursty traffic. Condition 4 can be expressed as follows:

Condition 1 AND |MA.sub.i.sup.k.sup.1(P.sub.i)−MA.sub.j.sup.k.sup.v(P.sub.v,j)|≤Th.sub.v

where P.sub.v,j is the mean throughput of the jth previous valley within the current bursty traffic, k.sub.v is the number of previous valleys used to compute the moving average of the valleys' throughput, and Th.sub.v is a predetermined threshold. A typical value of k.sub.v is 5. A typical value of Th.sub.v is 0.12 Mbyte/s.

[0087] Condition 4 ensures that the mean throughput of the current valley is close to the moving average of the mean throughput of the previous valleys. After entering State 4 with Condition 4, the STA has already identified a stable (valley), burst, stable (valley) pattern of the traffic which indicates that the current traffic is highly likely to satisfy the bursty traffic pattern. In some embodiments, a counter C.sub.V,B can be used to record the number of times that State 4 is continuously reached from State 3, which represents the number of times that the valley-burst-valley traffic pattern is observed. If C.sub.V,B>N, then the traffic can be classified as bursty traffic. In some embodiments, it is determined to set N=0, however N can also be set to a larger number to further reduce the false detection rate of bursty traffic type.

[0088] The Stable Traffic Conditions are criteria to transition from random or bursty traffic to stable traffic, which will now be discussed.

Condition 2

[0089] Condition 2 is provided to confirm that a stable traffic is present after the initial stable part of the traffic is detected in State 1. Condition 2 can be expressed as follows:

|ΔP.sub.i|≤Th.sub.3 (for i=N−k.sub.2+1, N−k.sub.2+2, . . . N)

AND

|P.sub.N−MA.sub.i.sup.k.sup.2(P.sub.i)|≤Th.sub.4,

where Th.sub.3 and Th.sub.4 are predetermined threshold values.

[0090] Condition 2 is similar to Condition 1 with the difference on the throughput variation threshold being set to Th.sub.3 and Th.sub.4, which are usually larger than Th.sub.1 and Th.sub.2. This is due to the fact that the throughput variation of the stable traffic, such as video conferencing, is often larger than the throughput variation of the valley part of bursty traffic. Typical values of Th.sub.3 and Th.sub.4 are 0.2 Mbyte/s and 0.25 Mbyte/s, respectively. The variable k.sub.2 represents the number of additional observations needed to confirm a stable traffic after observing the initial stable part of the traffic with State 1. In some embodiments, the value of k.sub.2 is set to 9.

Condition 5

[0091] Condition 5 is provided to directly confirm the presence of a stable traffic from the random traffic state. Condition 5 shares the same form as Condition 2 with the only difference in the number of consecutive observations (k.sub.3 instead of k.sub.2) needed to directly confirm a stable traffic without detecting the initial stable part of the traffic. A typical value of k.sub.3 is 14 which can be the sum of k.sub.1 and k.sub.2.

[0092] The Random Traffic Conditions are criteria to transition from bursty or stable traffic to random traffic, which includes Conditions 6, 7, 8, and 9, as discussed below.

Condition 6

[0093] Condition 6 can be stated as follows: In State 1, when Condition 1 is NOT satisfied, then transition to State 0. Condition 6 is used to check whether the traffic pattern sees a large variation and is no longer stable, which indicates that the traffic becomes random.

Condition 7

[0094] Condition 7 is provided to identify that the traffic has lost the pattern of a bursty traffic and becomes random in State 3. Condition 7 can be expressed as follows:

T.sub.bur≥MA.sub.i.sup.k.sup.4(T.sub.val,i)

[0095] The value T.sub.bur is the time duration of the current burst in State 3, and MA.sub.i.sup.k.sup.4(T.sub.val, i) is the moving average of the time duration of the valley part of the current bursty traffic. Condition 7 is based on the fact that the time duration of the valley is always statistically longer than the duration of the burst.

Condition 8

[0096] Condition 8 is provided to identify that the traffic has lost the pattern of a bursty traffic and becomes random in State 4. In State 4, when Condition 1 is NOT satisfied for N.sub.1 consecutive observations or N.sub.2 observations within a N.sub.3 long observation window, then the STA transitions to State 0. Typical values of N.sub.1, N.sub.2, and N.sub.3 are 2, 2, and 10, respectively. Condition 8 is very similar to Condition 6 but with added tolerance to allow some anomalies in the valley part of bursty traffic (such as the anomaly shown in the bursty traffic 801 in FIG. 8). The tolerance is added based on the conditional probability that, when State 4 is reached, the traffic is likely to be bursty traffic and some abnormal pattern at the valley part is then tolerable.

[0097] Condition 9 is similar to the criteria in Condition 8. The only difference is that “when Condition 1 is NOT satisfied” is changed to “when Condition 2 is NOT satisfied”.

[0098] FIG. 11 illustrates example results from the traffic type detection technique discussed in FIGS. 9 and 10 according to embodiments of the present disclosure. As shown in FIG. 11, three applications (e.g., YOUTUBE video, WEBEX video conference, and web browsing), which correspond to bursty traffic 801, stable traffic 802, and random traffic 803, respectively, are used. The first row of FIG. 11 depicts the traffic pattern, i.e., the throughput over time, for each application. The second row of FIG. 11 shows how the internal state of the state machine 900 transitions when detecting different traffic patterns. The third row of FIG. 11 shows the final traffic type classification result of the state machine 900 (e.g., 1=random, 2=stable, 3=bursty). As shown in FIG. 11, for the bursty traffic 801, the internal state of the state machine 900 will first transition to State 1 when it detects the first valley of the bursty traffic 801. Then the state machine 900 will transition to State 3 when the burst part of the bursty traffic 801 is observed. Then the state machine 900 will transition to State 4 after observing another valley of the bursty traffic 801. At this stage, the value C.sub.v,b is equal to 1, and the current traffic is classified as bursty traffic.

[0099] It can also be seen in FIG. 11 that there is one anomaly in the valley part of the bursty traffic 801, whose throughput is obviously higher than the valley, but is also significantly lower than the burst. As the transition condition in State 4 allows such an anomaly, the state machine 900 does not immediately transition to State 0 and classify it as random traffic.

[0100] For the stable traffic 802 in FIG. 11, it can be seen that the state machine 900 first finds the initial stable region (State 1), and then transitions to State 2 after the state machine 900 continues to observe that the traffic is stable without burst or anomalies. Then the traffic is classified as stable. For the random traffic 803 of web browsing in FIG. 11, the state machine 900 is not able to find a sufficiently long stable region or identify a pattern of bursty traffic. Thus, the classification result is considered to be random.

[0101] FIG. 12 illustrates an example of the state machine 900 transitioning among the three traffic types according to embodiments of the present disclosure. As shown in FIG. 12, a test is performed by first performing web browsing (random traffic), then playing a YOUTUBE LIVE video (bursty traffic). After that, the test performs PANDORA audio streaming, which can produce stable traffic. As shown in FIG. 12, after finishing the web browsing and before starting the YOUTUBE LIVE video, the state machine 900 observes a period of time that the throughput is stable. The state machine 900 switches to the internal State 2 and classifies the traffic as stable. As the YOUTUBE LIVE video starts, a burst is observed, which breaks the stable traffic condition, and the state machine 900 immediately switches to the random traffic type. Then, after observing the valley-burst pattern, the state machine 900 classifies the traffic as bursty. After the YOUTUBE LIVE video is stopped and the PANDORA audio stream starts, the state machine 900 observes a continuously stable throughput, and classifies the traffic as stable.

[0102] In addition to detecting the three traffic types, the state machine 900 can also find the length of the valley and burst of the bursty traffic, which can be useful for the customized TWT polling cycle design. After detecting the bursty traffic, a moving average window is used to compute the current mean value of the burst and valley length in units of observation time steps.

[0103] The moving average of the burst length T.sub.bur.sup.MA can be expressed as:

T.sub.bur.sup.MA=MA.sub.i.sup.k(T.sub.bur,i)

[0104] The moving average of the valley length T.sub.val.sup.MA can be expressed as:

T.sub.val.sup.MA=MA.sub.i.sup.k(T.sub.val,i)

[0105] In these equations, the value k is the size of the moving average window. The moving average value of T.sub.bur and T.sub.val calculated above can be used to determine the polling cycle T.sub.cc, which will be discussed in detail below.

Traffic Type Based TWT Parameter Design

[0106] In this section, the TWT parameter design based on the detected traffic types is described. In some embodiments, the TWT SP duration 310 is designed to adapt to a stable stream of traffic and accommodate quickly to a burst stream of traffic solely on the means of incoming throughput transformed in to time. The transformation in time is achieved by initially clustering the packets into buffered packets (received/transmitted after a period of time) and non-buffered packets (received/transmitted as soon as arrived/created at node). Then a combination of statistics from all packets (e.g., packet size, inter packet arrival time, number of buffered packets, number of non-buffered packets, and the like) is used to analyze the time required to accommodate future traffic.

[0107] Using these criteria, the TWT SP duration 310 is updated based on a stable condition and an overflow condition. One example of this functionality is described in U.S. patent application Ser. No. 17/444,981, which is hereby incorporated by reference in its entirety.

[0108] In a stable condition, the TWT SP duration 310 is updated based on long-range statistics for stable traffic stream. A stable update happens when the traffic is mostly even and does not deviate substantially from the past trends in the observation window. This can be thought of as a Max envelope tracker of the past traffic. In some embodiments, the TWT SP duration 310 is updated as a sum of the T.sub.max and a stable update guard. A stable update guard is used to accommodate for any errors in the data time estimation or variance in the incoming data. In addition, if there is an increase in the number of packets, the stable update guard provides enough room to accommodate for that.

[0109] In an overflow condition, the TWT SP duration 310 is updated based on instantaneous traffic burst statistics to immediately ramp up the TWT SP duration 310. Overflow protection allows scaling of the TWT SP duration 310 quickly in the case of large incoming data, and prevents the link from saturating below its capability due to TWT. This protection is integral for applications like web browsing, video streaming, and the like, where data comes in the form of periodic and aperiodic bursts and other times there is no traffic present. As the stable update happens at a slower rate, overflow protection can be used to increment the TWT SP duration 310 faster to adapt to the incoming large traffic.

[0110] In this document, using the output from the state machine 900, the update conditions are adapted for random, stable, and burst traffic. A technique for how to release and resume TWT is also provided. FIGS. 13A and 13B illustrate one example of the adapted technique according to embodiments of the present disclosure.

Stable Update Polling Cycle

[0111] The stable update polling cycle T.sub.cc, is the polling interval defined to adapt the duration based on the long-term observed statistics of the traffic flow and network conditions of the STA. The intuition is to keep T.sub.cc, long enough to prevent frequent negotiations in the case of stable traffic and to reduce the time the duration stays large to accommodate for a burst or random traffic input.

[0112] In some embodiments, when the detected traffic is of stable type, T.sub.cc, is set to the time required to capture the effective long-term statistics based on the variance of the traffic flow, amount of traffic within T.sub.cc, etc. In another embodiment, T.sub.cc, can be set to an estimated value defined by data-driven analysis of different stable traffic flows, an exemplary value of which can be six seconds.

[0113] In some embodiments, when the detected traffic is of bursty type, T.sub.cc is set to a short duration, to revert to a lower TWT SP duration 310 when the burst communication has finished by setting T.sub.cc using a function of burst duration T.sub.bur and valley duration T.sub.val as calculated by the state machine 900. In this case, the update of T.sub.cc can be expressed as the following function:

T.sub.cc=f(T.sub.bur,T.sub.val).

[0114] One example of this function can be:

T.sub.cc=T.sub.bur+0.25*T.sub.val.

[0115] In some embodiments, the polling cycle T.sub.cc can be set to an estimated value defined by data-driven analysis of different bursty traffic flows, an exemplary value of which can be two seconds.

[0116] For random traffic, in some embodiments, T.sub.cc can be set to an estimated value defined by data-driven analysis of different random traffic flows, an exemplary value of which can be three seconds.

Data Time Estimation

[0117] To compute the required TWT service period T.sub.Wd, an estimated data time T.sub.dt can be used. The data time T.sub.dt can be calculated based on a combination of the amount of data communicated and the network conditions. For example, the data time T.sub.dt can be estimated according to the following model:

[00002]$\begin{array}{c}{T}_{dt}=\left(\frac{B_{tx}}{S_{tx}}+\frac{B_{\mathrm{rx}}}{S_{\mathrm{rx}}}\right).Math.\left(\frac{\alpha }{1-\frac{T_{\mathrm{cca}}}{T_{on}}}+1-\alpha \right)\\ =T_{data}.Math.\left(\frac{\alpha }{1-\frac{T_{\mathrm{cca}}}{T_{on}}}+1-\alpha \right)\end{array}$

where B.sub.tx, and B.sub.rx are the amounts of data transmitted and received, respectively, T.sub.cca is the channel clearance assessment time, T.sub.on is the radio on time, S.sub.tx and S.sub.rx are the link speed for transmitting and receiving, respectively, and a is a hyper parameter which can be determined empirically. An exemplary value of a is 1.9.

Overflow Update

[0118] A special case of overflow update is the bursty traffic type. In this case, the bursts are short intervals of traffic that arrive pseudo-periodically with long intervals of silence interleaved between the bursts. The overflow update for the bursty traffic type can be customized by reducing the amount by which T.sub.wd is updated. On encountering an overflow trigger during the bursty traffic type, the update formula is as follows:

T.sub.wd,i+1=T.sub.wd,i+δ.sub.OF
where i is the index of the ith TWT SP and δ.sub.OF is an overflow update guard. As can be seen here, instead of updating on the T.sub.dt,max, the STA updates on the previous T.sub.wd. This reduces the amount by which the T.sub.wd scales. As bursty traffic is usually observed in non-real-time traffic with no latency requirement, this customization saves power by scaling smaller than the regular overflow update.

[0119] An overflow threshold ρ.sub.OF is kept as 0.2 in the case of random traffic because the traffic type is non-deterministic and permits faster adaptation. Additional cases which require quick ramping up are network speed testing and file downloading, in which case T.sub.wd needs to be increased as much as possible because the throughput is higher for these requirement applications. In the case of deterministic traffic like stable or burst, ρ.sub.OF is kept as 0.1. This reduces the probability of unnecessary overflows occurring and wasting power.

Stable Update

[0120] As noted here, for stable traffic and the stable guard δ.sub.stable, the standard deviation of the traffic data time in a stable update polling cycle T.sub.dt,std is used instead of 10% of the T.sub.inv. This is because in stable traffic, the STA just accommodates for the variation in traffic which is deterministic.

[0121] Example values of the parameters used for determining the TWT SP duration 310 based on traffic type and exemplary values are summarized in Table 1. Of course, these values represent only one example. Other values are possible and within the scope of this disclosure.

TABLE-US-00001 TABLE 1 Traffic type based TWT parameter design Traffic Type Parameters Random Stable Burst Overflow Threshold 0.2 0.1 0.1 Percentage, ρ.sub.OF Overflow Threshold, max(ρ.sub.OF * T.sub.wd, 1500 ms) T.sub.OF Overflow Update 0.2 * T.sub.inv Guard, δ.sub.OF Overflow Update T.sub.dt, max + δ.sub.OF T.sub.dt, max + δ.sub.OF T.sub.wd + δ.sub.OF Stable Update max(0.1 * max(T.sub.dt, std, ϵ) max(0.1 * Guard, δ.sub.stable T.sub.inv, ϵ) T.sub.inv, ϵ) Stable Update T.sub.dt, max + δ.sub.stable Boost Multiplier, 3.5 2 1 m.sub.boost Boost Offset, c.sub.boost 400    400 1500

TWT Release and Resumption

[0122] The main purpose of TWT is to save power in the STA by scheduling the time the STA stays awake. At higher duty cycles (where the duty cycle is the ratio of SP Duration to Interval, or

[00003]$\frac{T_{wd}}{T_{inv}}),$

the power gain is minimal compared to disabling TWT. In such scenarios, it is more convenient to disable TWT, which is referred to herein as TWT release. After TWT release, traffic flow and network conditions are still monitored to identify if it is convenient to enable TWT, which is referred to herein as TWT resumption.

[0123] For TWT release, there are two criteria to consider:

[00004]$T_{inv}-T_{wd}<T_{overhead}$$\frac{T_{wd}}{T_{inv}}<D_{\max }$

where T.sub.overhead is the overhead time associated with the TWT associated signaling between the STA and AP, and D.sub.max is the maximum duty cycle beyond which power saving capability of TWT is minimal compared to having no TWT set up. D.sub.max is estimated by studying the power consumption of traffic at different duty cycles and without TWT and studying the power consumption by the Wi-Fi chipset. If any of these above conditions is satisfied, the existing TWT setup is torn down between the AP and the STA. After this, the STA disables the overflow and stable polling cycles and then starts the resumption polling cycle.

[0124] At every resumption poll, the traffic flow and the network conditions are observed to evaluate if the conditions are right to resume TWT. The observed conditions are:

[00005]$\frac{T_{dt}}{T_{obs}}<D_{\mathrm{hysteresis}}$

where T.sub.obs is the observation time in which the data time T.sub.dt is calculated and the observation time is set to the resumption poll period, and D.sub.hysteresis is the hysteresis duty cycle which is set to discourage frequent TWT resumption and release in case the traffic fluctuates below D.sub.max.

Estimating Fine-Time Scale Network Statistics from Coarse-Time Scale Observation

[0125] The following section describes an example technique for estimating the fine-time scale network statistics from a coarse-time scale observation. To calculate the proper TWT parameters, it is advantageous to have a good estimation of the network statistics and convert them to the required time or duty cycle to transmit the current traffic between the STA and the AP. However, due to the device hardware limits, it can be difficult to frequently observe the statistics of the traffic. The observation time is usually on a time scale of every S.sub.c time unit, where a typical value of S.sub.c is 500 ms. In contrast, the TWT parameters accommodate the statistical variation of the traffic at a much finer time scale S.sub.f, where a typical value of S.sub.f is 25 ms.

[0126] FIG. 14 illustrates a diagram 1400 showing an example of fine and coarse time-scale for traffic statistics observation according to embodiments of the present disclosure. As is shown in FIG. 14, the network statistics X can be observed on a fine time scale S.sub.f or on a coarse time scale S.sub.c, which can give the observation results as X.sub.f or X.sub.c. The network statistics X can be, e.g., traffic throughput, total amount of transceived data B, total number of transceived packets, link speed, CCA time, radio-on time, estimated minimum data transceiving time T.sub.dt for the TWT operations in order to accommodate the current throughput at the current network condition, and the like.

[0127] FIG. 15 illustrates example charts 1501-1502 showing the same traffic statistics of packet number observed in fine time scale and coarse time scale, according to embodiments of the present disclosure. As shown in FIG. 15, the variation of the packet number in every fine time-scale observation time slot (as shown in the chart 1501) is much larger than the variation of the packet number in every coarse time-scale observation time slot (as shown in the chart 1502).

[0128] FIG. 16 illustrates an example process 1600 for dynamically updating network statistics variation according to embodiments of the present disclosure, as may be performed by a STA (e.g., one of the STAs 111-114 as illustrated in FIG. 1). The embodiment of the process 1600 shown in FIG. 16 is for illustration only. Other embodiments of the process 1600 could be used without departing from the scope of this disclosure.

[0129] In the process 1600, the STA only collects the variance of the network statistics at a fine time scale when it is necessary. The variance of the fine time scale network statistics are dynamically updated only when it is determined, based on the coarse time-scale observations, that the variance of network statistics have a large change.

[0130] To better explain the relationship between χ.sub.f and χ.sub.c, in the process 1600, network statistics of the total amount of transceived data B.sup.25 of every 25 ms can be used as an example. At step 1602, network statistics X.sub.f are collected at the fine time scale S.sub.f. If the fine time scale observation of B is performed every 25 ms, then this can be expressed as:

B.sup.25=χ.sub.f.sup.25.

[0131] At step 1604, the variation of B.sup.25 from the fine time scale observation is computed as:

var(χ.sub.f.sup.25)=σ.sub.f.sup.2.

[0132] At step 1606, network statistics χ.sub.c are collected at the coarse time scale S.sub.c. If the coarse time scale observation of B is performed every 500 ms, then the estimated {circumflex over (B)}.sup.25 can be expressed as:

[00006]${\hat{B}}^{25}={\chi }_c^{25}=\frac{B^{500}}{N_1}=\frac{1}{N_1}\underset{i=1}{\overset{N_1}{.Math.}}{\chi }_f^{25}\left[i\right],$

where N.sub.1=50.

[0133] As can be seen above, the coarse time scale observation result χ.sub.c.sup.25 can be viewed as the statistical mean of the χ.sub.f.sup.25. In the meantime, the variance of the coarse time-scale observation var(χ.sub.c.sup.25)=σ.sub.c.sup.2 can be obtained. If the network statistics remain unchanged, then the following relationship applies:

[00007]$\begin{array}{c}{\sigma }_c^2=\mathrm{var}\left({\chi }_c^{25}\right)\\ =\mathrm{var}\left(\frac{1}{N_1}\underset{i=1}{\overset{N_1}{.Math.}}{\chi }_f^{25}\left[i\right]\right)\\ =\frac{1}{N_1^2}\underset{i=1}{\overset{N_1}{.Math.}}\mathrm{var}\left({\chi }_f^{25}\right)\\ =\frac{1}{N_1^2}{N}_1{\sigma }_f^2\\ =\frac{1}{N_1}{\sigma }_f^2.\end{array}$

[0134] Thus, if the statistical variation at the fine time scale is not changed, then the following relationship applies:

[00008]${\sigma }_c^2=\frac{1}{N_1}{\sigma }_f^2.$

[0135] At step 1608, the difference of σ.sub.c.sup.2 and σ.sub.f.sup.2 is tested to see how much the variation of the statistics have changed. While there is no significant change of the variation of the statistics, the currently observed coarse time scale statistics X.sub.c and the previously acquired fine time scale statistics variation σ.sub.f .sup.2 can be used to estimate the needed TWT parameters.

[0136] At step 1610, the coarse time scale variation σ.sub.c.sup.2 can be acquired by accumulating χ.sub.c in a size M FIFO buffer and calculating its variance. If the coarse time scale observation interval S.sub.c and the fine time scale observation interval S.sub.f has a relationship S.sub.c=K.Math.S.sub.f, then the coarse time scale observed statistics' variation σ.sub.c.sup.2 can have the relationship of:

[00009]${\sigma }_c^2=\frac{1}{K}{\sigma }_f^2.$

[0137] At step 1612, it is tested if

[00010]$.Math.{\sigma }_c^2-\frac{{\sigma }_f^2}{K}.Math.\ge \mathrm{err}$

to determine whether the statistical variation at the small time scale has changed. A typical value of err can be 0.05σ.sub.c.sup.2. If the test result is true, then a fine time scale sampling or observation is needed again to update σ.sub.f.sup.2, and the process 1600 returns to step 1602.

[0138] FIG. 17 illustrates a chart 1700 showing an example of using the process 1600 according to embodiments of the present disclosure. The chart 1700 depicts dynamically updating the observation time scale for the estimation of network statistics. As shown in FIG. 17, the traffic statistics are initially observed at a fine time scale and the variation of the traffic statistics σ.sub.f is recorded. Then the observation is changed to coarse time scale, and the statistics of the traffic that were observed in the fine time scale continue to be used. During the time that the observation is performed in the coarse time scale, it is determined whether the variation of the statistics in the coarse time scale σ.sub.c.sup.2 is larger than

[00011]$\frac{1}{N_1}{\sigma }_f^2+err.$

If that is the case, then it means that the traffic statistics has changed, and the traffic statistics need to be updated at the fine time scale again. After updating the traffic statistics in the fine time scale, the STA reverts to observation at the coarse time scale and monitors if the traffic statistics is changed again by checking the condition

[00012]${\sigma }_c^2\ge \frac{1}{N_1}{\sigma }_f^2+e\mathrm{rr}.$

[0139] In another embodiment, the value of χ.sub.f can be estimated with a linear mapping of χ.sub.c. A mapping between the finely sampled data χ.sub.f and the coarsely sampled data χ.sub.c can be created. The values of χ.sub.c and χ.sub.f can be the throughput in some embodiments. In other embodiments, χ.sub.c and χ.sub.f can be the calculated data time T.sub.dt. In these embodiments, a linear mapping can be observed between the coarsely and finely sampled data, which can be formulated as:

χ.sub.f=m.sub.boost*χ.sub.c+c.sub.boost

where m.sub.boost and c.sub.boost are the linear mapping factors used to map the coarsely calculated χ.sub.c to an estimate of the finely calculated χ.sub.f.

[0140] In some embodiments, the coarse observation time and fine observation time are equal (i.e., S.sub.c=S.sub.f), and thus the observed data are also equal (χ.sub.c=χ.sub.f). In these embodiments, an exemplary time for S.sub.c is T.sub.inv and no estimation of fine-time scale statistics is required. The statistics calculated in these embodiments are used as is for estimation of T.sub.wd.

[0141] FIG. 18 illustrates a method 1800 for traffic type detection and Wi-Fi parameter design according to embodiments of the present disclosure, as may be performed by a STA (e.g., one of the STAs 111-114 as illustrated in FIG. 1). An embodiment of the method 1800 shown in FIG. 18 is for illustration only. One or more of the components illustrated in FIG. 18 can be implemented in specialized circuitry configured to perform the noted functions or one or more of the components can be implemented by one or more processors executing instructions to perform the noted functions.

[0142] As illustrated in FIG. 18, the method 1800 begins at step 1802. At step 1802, a STA obtains statistical information of incoming network traffic. This could include, for example, the STA 111 obtaining statistical information of incoming network traffic from the AP 101, including throughput, average throughput, instantaneous throughput, traffic bursts, traffic valleys, traffic anomalies, TWT wakeup time, TWT service period, and the like. In some embodiments, the statistical information can be obtained at a fine time scale, a coarse time scale, or both.

[0143] At step 1804, a state machine is used to classify the incoming network traffic as a traffic pattern based on the statistical information. This could include, for example, the STA 111 implementing the state machine 900 to classify the incoming network traffic as at least one of bursty traffic, random traffic, and stable traffic.

[0144] At step 1806, the traffic pattern is used to adapt one or more TWT parameters to optimize power consumption of a Wi-Fi station. This could include, for example, the STA 111 using the traffic pattern to adapt at least one of an overflow threshold, an overflow threshold percentage, an overflow guard, and overflow update, a stable guard, a stable update, a boost multiplier, or a boost offset, in order to optimize power consumption of the STA 111.

[0145] Although FIG. 18 illustrates one example of a method 1800 for traffic type detection and Wi-Fi parameter design, various changes may be made to FIG. 18. For example, while shown as a series of steps, various steps in FIG. 18 could overlap, occur in parallel, occur in a different order, or occur any number of times.

[0146] Although the present disclosure has been described with exemplary embodiments, various changes and modifications may be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims. None of the description in this application should be read as implying that any particular element, step, or function is an essential element that must be included in the claims scope. The scope of patented subject matter is defined by the claims.