Patent ID: 12219492

DETAILED DESCRIPTION

FIGS.1through18, 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.

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.

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

FIG.1illustrates an example wireless network100according to various embodiments of the present disclosure. The embodiment of the wireless network100shown inFIG.1is for illustration only. Other embodiments of the wireless network100could be used without departing from the scope of this disclosure.

The wireless network100includes access points (APs)101and103. The APs101and103communicate with at least one network130, such as the Internet, a proprietary Internet Protocol (IP) network, or other data network. The AP101provides wireless access to the network130for a plurality of stations (STAs)111-114within a coverage area120of the AP101. The APs101-103may communicate with each other and with the STAs111-114using Wi-Fi or other WLAN communication techniques.

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.).

Dotted lines show the approximate extents of the coverage areas120and125, 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 areas120and125, 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.

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). AlthoughFIG.1illustrates one example of a wireless network100, various changes may be made toFIG.1. For example, the wireless network100could include any number of APs and any number of STAs in any suitable arrangement. Also, the AP101could communicate directly with any number of STAs and provide those STAs with wireless broadband access to the network130. Similarly, each AP101-103could communicate directly with the network130and provide STAs with direct wireless broadband access to the network130. Further, the APs101and/or103could provide access to other or additional external networks, such as external telephone networks or other types of data networks.

FIG.2Aillustrates an example AP101according to various embodiments of the present disclosure. The embodiment of the AP101illustrated inFIG.2Ais for illustration only, and the AP103ofFIG.1could have the same or similar configuration. However, APs come in a wide variety of configurations, andFIG.2Adoes not limit the scope of this disclosure to any particular implementation of an AP.

The AP101includes multiple antennas204a-204n, multiple RF transceivers209a-209n, transmit (TX) processing circuitry214, and receive (RX) processing circuitry219. The AP101also includes a controller/processor224, a memory229, and a backhaul or network interface234. The RF transceivers209a-209nreceive, from the antennas204a-204n, incoming RF signals, such as signals transmitted by STAs in the network100. The RF transceivers209a-209ndown-convert the incoming RF signals to generate IF or baseband signals. The IF or baseband signals are sent to the RX processing circuitry219, which generates processed baseband signals by filtering, decoding, and/or digitizing the baseband or IF signals. The RX processing circuitry219transmits the processed baseband signals to the controller/processor224for further processing.

The TX processing circuitry214receives analog or digital data (such as voice data, web data, e-mail, or interactive video game data) from the controller/processor224. The TX processing circuitry214encodes, multiplexes, and/or digitizes the outgoing baseband data to generate processed baseband or IF signals. The RF transceivers209a-209nreceive the outgoing processed baseband or IF signals from the TX processing circuitry214and up-converts the baseband or IF signals to RF signals that are transmitted via the antennas204a-204n.

The controller/processor224can include one or more processors or other processing devices that control the overall operation of the AP101. For example, the controller/processor224could control the reception of uplink channel signals and the transmission of downlink channel signals by the RF transceivers209a-209n, the RX processing circuitry219, and the TX processing circuitry214in accordance with well-known principles. The controller/processor224could support additional functions as well, such as more advanced wireless communication functions. For instance, the controller/processor224could support beam forming or directional routing operations in which outgoing signals from multiple antennas204a-204nare weighted differently to effectively steer the outgoing signals in a desired direction. The controller/processor224could also support OFDMA operations in which outgoing signals are assigned to different subsets of subcarriers for different recipients (e.g., different STAs111-114). Any of a wide variety of other functions could be supported in the AP101by the controller/processor224including determining parameters for TWT operations. In some embodiments, the controller/processor224includes at least one microprocessor or microcontroller. The controller/processor224is also capable of executing programs and other processes resident in the memory229, such as an OS. The controller/processor224can move data into or out of the memory229as required by an executing process.

The controller/processor224is also coupled to the backhaul or network interface234. The backhaul or network interface234allows the AP101to communicate with other devices or systems over a backhaul connection or over a network. The interface234could support communications over any suitable wired or wireless connection(s). For example, the interface234could allow the AP101to 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 interface234includes any suitable structure supporting communications over a wired or wireless connection, such as an Ethernet or RF transceiver. The memory229is coupled to the controller/processor224. Part of the memory229could include a RAM, and another part of the memory229could include a Flash memory or other ROM.

As described in more detail below, the AP101may include circuitry and/or programming for determining parameters for TWT operations in WLANs (e.g., the TWT interval). AlthoughFIG.2Aillustrates one example of AP101, various changes may be made toFIG.2A. For example, the AP101could include any number of each component shown inFIG.2A. As a particular example, an access point could include a number of interfaces234, and the controller/processor224could support routing functions to route data between different network addresses. As another particular example, while shown as including a single instance of TX processing circuitry214and a single instance of RX processing circuitry219, the AP101could 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 inFIG.2Acould be combined, further subdivided, or omitted and additional components could be added according to particular needs.

FIG.2Billustrates an example STA111according to various embodiments of this disclosure. The embodiment of the STA111illustrated inFIG.2Bis for illustration only, and the STAs112-114ofFIG.1could have the same or similar configuration. However, STAs come in a wide variety of configurations, andFIG.2Bdoes not limit the scope of this disclosure to any particular implementation of a STA.

The STA111includes antenna(s)205, a radio frequency (RF) transceiver210, TX processing circuitry215, a microphone220, and receive (RX) processing circuitry225. The STA111also includes a speaker230, a controller/processor240, an input/output (I/O) interface (IF)245, a touchscreen250, a display255, and a memory260. The memory260includes an operating system (OS)261and one or more applications262.

The RF transceiver210receives, from the antenna(s)205, an incoming RF signal transmitted by an AP of the network100. The RF transceiver210down-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 circuitry225, which generates a processed baseband signal by filtering, decoding, and/or digitizing the baseband or IF signal. The RX processing circuitry225transmits the processed baseband signal to the speaker230(such as for voice data) or to the controller/processor240for further processing (such as for web browsing data).

The TX processing circuitry215receives analog or digital voice data from the microphone220or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the controller/processor240. The TX processing circuitry215encodes, multiplexes, and/or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The RF transceiver210receives the outgoing processed baseband or IF signal from the TX processing circuitry215and up-converts the baseband or IF signal to an RF signal that is transmitted via the antenna(s)205.

The controller/processor240can include one or more processors and execute the basic OS program261stored in the memory260in order to control the overall operation of the STA111. In one such operation, the main controller/processor240controls the reception of downlink channel signals and the transmission of uplink channel signals by the RF transceiver210, the RX processing circuitry225, and the TX processing circuitry215in accordance with well-known principles. The main controller/processor240can also include processing circuitry configured to determine parameters for TWT operations in WLANs (e.g., the TWT interval). In some embodiments, the controller/processor240includes at least one microprocessor or microcontroller.

The controller/processor240is also capable of executing other processes and programs resident in the memory260, such as operations for determining parameters for TWT operations in WLANs. The controller/processor240can move data into or out of the memory260as required by an executing process. In some embodiments, the controller/processor240is configured to execute a plurality of applications262, 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/processor240can operate the plurality of applications262based on the OS program261or in response to a signal received from an AP. The main controller/processor240is also coupled to the I/O interface245, which provides STA111with the ability to connect to other devices such as laptop computers and handheld computers. The I/O interface245is the communication path between these accessories and the main controller240.

The controller/processor240is also coupled to the touchscreen250and the display255. The operator of the STA111can use the touchscreen250to enter data into the STA111. The display255may 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 memory260is coupled to the controller/processor240. Part of the memory260could include a random access memory (RAM), and another part of the memory260could include a Flash memory or other read-only memory (ROM).

AlthoughFIG.2Billustrates one example of STA111, various changes may be made toFIG.2B. For example, various components inFIG.2Bcould be combined, further subdivided, or omitted and additional components could be added according to particular needs. In particular examples, the STA111may include any number of antenna(s)205for MIMO communication with an AP101. In another example, the STA111may not include voice communication or the controller/processor240could be divided into multiple processors, such as one or more central processing units (CPUs) and one or more graphics processing units (GPUs). Also, whileFIG.2Billustrates the STA111configured as a mobile telephone or smartphone, STAs could be configured to operate as other types of mobile or stationary devices.

FIG.3illustrates a diagram300of 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 STA111, but it is understood that it could be any suitable wireless communication device.

FIG.3illustrates 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 graph302), 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 graph304). In the top graph302, 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.

By contrast, in the bottom graph304, wake time negotiation gives rise to consecutive TWT sessions306. Each TWT session306is defined as the time period from the beginning of a TWT interval308to the end of the TWT interval308. Each TWT session306includes two states: an active state311, defined by a TWT service period (SP) duration310(during which the STA is awake to communicate with the AP), and a power save state or doze state312(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.

In wake time negotiation, the negotiated TWT parameters include the wake interval (e.g., the TWT interval308for each TWT session306), wake duration (e.g. the TWT SP duration310for each TWT session306), and initial wake time or offset (e.g., indicated by the TWT start time314). 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.

In some embodiments, a TWT parameter set field is used to negotiate the TWT parameters.FIG.4illustrates an example TWT parameter set field400used 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 mantissa402and TWT wake interval exponent404subfields in the TWT parameter set field400.

The target wake time406and nominal minimum TWT wake duration408subfields 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 duration310inFIG.3.

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.5illustrates an offset in a TWT session according to embodiments of the present disclosure. Different offsets502introduce a different additional TWT related latency. TWT interval308and offset502together define the additional latency introduced by TWT. After TWT negotiation setup, the offset502can be adjusted by the field “Next TWT”602in the example TWT information frame600illustrated inFIG.6.

FIG.7illustrates an example of early termination of TWT according to embodiments of the present disclosure. In various embodiments, the actual TWT SP duration310is dynamically determined in run time by the aforementioned nominal minimum TWT wake duration, and the STA enters the doze state312when 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 state312will be slightly different. As shown in the graph702, 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 state312(although there could be a slight delay between reception of the packet and entering doze state312). If the STA does not support early termination, then it will wait until the end of the TWT SP duration310to enter doze state312, as shown in graph304.

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.

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.

FIG.8illustrates example traffic types801-803that can be exhibited by network services according to embodiments of the present disclosure. As shown inFIG.8, the network services can exhibit any of three types of traffic types or patterns. These types includes bursty traffic801, stable traffic802, and random traffic803.

The bursty traffic801features a periodic “burst” or large throughput, as shown inFIG.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” inFIG.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.

The stable traffic802features 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.

The random traffic803often shows random variations of traffic throughput, which is difficult to predict. The random traffic803can be observed in web browsing and other applications in which the user interaction with the smart phone or device is hard to predict.

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.

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.

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.

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.

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.

FIG.9illustrates details of an example state machine900for use in traffic type detection and classification according to embodiments of the present disclosure. The state machine900can be used to classify network traffic for a TWT session. For ease of explanation, the state machine900will be described as being implemented by a STA, such as one of the STAs111-114ofFIG.1. However, the state machine900can be implemented by any suitable device. The embodiment of the state machine900shown inFIG.9is for illustration only. Other embodiments of the state machine900could be used without departing from the scope of this disclosure.

As shown inFIG.9, the state machine900includes 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 machine900(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 Cv,band Cb,v, which represent the number of valley-bursts and burst-valleys, respectively, that have been observed. As shown inFIG.9, the value of Cv,bwill increase by 1 if a valley and then a burst is observed. Similarly, the value of Cb,vwill increase by 1 if a burst and then a valley is observed. The values of Cv,band Cb,vare compared to N1and N2, respectively, which are predetermined threshold values. If the value of Cv,bor Cb,vis larger than N1or N2, 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 N1or N2or 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 N1or N2is 0 to 3. In some embodiments, a value of 0 is used for a faster detection of bursty traffic.

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.10illustrates 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 inFIG.10, the state transition conditions can be grouped as follows:

Bursty Traffic Conditions: Conditions 1, 3, 4.

Stable Traffic Conditions: Conditions 1, 2, 5.

Random Traffic Conditions: Conditions 6, 7, 8, 9

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

Condition 1

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:
|ΔPi|≤Th1(fori=N−k1+1, N−k1+2, . . . , N)
AND
|PN−MAik1(Pi)|≤Th2,
where

MAik1(Pi)=1k1⁢∑i=N-k1+1NPi
is the moving average of Piwith a window size of k1, PNis the throughput of the most recent observation, Th1and Th2are predetermined threshold values, i represents an observation time point, and N is the latest observation time point.

The value of the moving average window size k1can be determined empirically offline through observing the typical length of the initial stable valley part of the bursty traffic. A typical value of k1used for Condition 1 is 5. Typical values of Th1and Th2are 0.1 Mbyte/s and 0.12 Mbyte/s. The Piis the throughput at the ith observation, and ΔPi=Pi−Pi−1is the change of throughput between each pair of observations.

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 machine900transitions 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 machine900would transition to State 2 for stable traffic classification. Otherwise, if a burst is observed, the state machine900would transition to State 3 and may lead to the classification as bursty traffic.

Condition 3

Condition 3 is provided to identify the burst part of the bursty traffic. Condition 3 can be expressed as follows:
ΔPi>ThbOR Σi=N−jNΔPi>w·Thb
where Thbis a predetermined threshold value, w is an empirically determined weighting value, and j represents a number of observation times.

Condition 3 can find the time that a sudden increase of the throughput (denoted by ΔPi) is larger than Thb. 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·Thbcan also be used. In some embodiments, it is determined to set j=2 and w=1.6. A typical value of Thbis 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

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 |MAik1(Pi)−MAjkv(Pv,j)|≤Thv
where Pv,jis the mean throughput of the jth previous valley within the current bursty traffic, kvis the number of previous valleys used to compute the moving average of the valleys' throughput, and Thvis a predetermined threshold. A typical value of kvis 5. A typical value of Thvis 0.12 Mbyte/s.

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 CV,Bcan 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 CV,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.

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

Condition 2

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:
|ΔPi|≤Th3(fori=N−k2+1,N−k2+2, . . . N)
AND
|PN−MAik2(Pi)|≤Th4,
where Th3and Th4are predetermined threshold values.

Condition 2 is similar to Condition 1 with the difference on the throughput variation threshold being set to Th3and Th4, which are usually larger than Th1and Th2. 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 Th3and Th4are 0.2 Mbyte/s and 0.25 Mbyte/s, respectively. The variable k2represents 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 k2is set to 9.

Condition 5

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 (k3instead of k2) needed to directly confirm a stable traffic without detecting the initial stable part of the traffic. A typical value of k3is 14 which can be the sum of k1and k2.

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

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

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:
Tbur≥MAik4(Tval,i)

The value Tburis the time duration of the current burst in State 3, and MAik4(Tval, 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

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 N1consecutive observations or N2observations within a N3long observation window, then the STA transitions to State 0. Typical values of N1, N2, and N3are 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 traffic801inFIG.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.

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”.

FIG.11illustrates example results from the traffic type detection technique discussed inFIGS.9and10according to embodiments of the present disclosure. As shown inFIG.11, three applications (e.g., YOUTUBE video, WEBEX video conference, and web browsing), which correspond to bursty traffic801, stable traffic802, and random traffic803, respectively, are used. The first row ofFIG.11depicts the traffic pattern, i.e., the throughput over time, for each application. The second row ofFIG.11shows how the internal state of the state machine900transitions when detecting different traffic patterns. The third row ofFIG.11shows the final traffic type classification result of the state machine900(e.g., 1=random, 2=stable, 3=bursty). As shown inFIG.11, for the bursty traffic801, the internal state of the state machine900will first transition to State 1 when it detects the first valley of the bursty traffic801. Then the state machine900will transition to State 3 when the burst part of the bursty traffic801is observed. Then the state machine900will transition to State 4 after observing another valley of the bursty traffic801. At this stage, the value Cv,bis equal to 1, and the current traffic is classified as bursty traffic.

It can also be seen inFIG.11that there is one anomaly in the valley part of the bursty traffic801, 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 machine900does not immediately transition to State 0 and classify it as random traffic.

For the stable traffic802inFIG.11, it can be seen that the state machine900first finds the initial stable region (State 1), and then transitions to State 2 after the state machine900continues to observe that the traffic is stable without burst or anomalies. Then the traffic is classified as stable. For the random traffic803of web browsing inFIG.11, the state machine900is 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.

FIG.12illustrates an example of the state machine900transitioning among the three traffic types according to embodiments of the present disclosure. As shown inFIG.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 inFIG.12, after finishing the web browsing and before starting the YOUTUBE LIVE video, the state machine900observes a period of time that the throughput is stable. The state machine900switches 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 machine900immediately switches to the random traffic type. Then, after observing the valley-burst pattern, the state machine900classifies the traffic as bursty. After the YOUTUBE LIVE video is stopped and the PANDORA audio stream starts, the state machine900observes a continuously stable throughput, and classifies the traffic as stable.

In addition to detecting the three traffic types, the state machine900can 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.

The moving average of the burst length TburMAcan be expressed as:
TburMA=MAik(Tbur,i)

The moving average of the valley length TvalMAcan be expressed as:
TvalMA=MAik(Tval,i)

In these equations, the value k is the size of the moving average window. The moving average value of Tburand Tvalcalculated above can be used to determine the polling cycle Tcc, which will be discussed in detail below.

Traffic Type Based TWT Parameter Design

In this section, the TWT parameter design based on the detected traffic types is described. In some embodiments, the TWT SP duration310is 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.

Using these criteria, the TWT SP duration310is 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.

In a stable condition, the TWT SP duration310is 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 duration310is updated as a sum of the Tmaxand 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.

In an overflow condition, the TWT SP duration310is updated based on instantaneous traffic burst statistics to immediately ramp up the TWT SP duration310. Overflow protection allows scaling of the TWT SP duration310quickly 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 duration310faster to adapt to the incoming large traffic.

In this document, using the output from the state machine900, 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 and13Billustrate one example of the adapted technique according to embodiments of the present disclosure.

Stable Update Polling Cycle

The stable update polling cycle Tcc, 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 Tcc, 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.

In some embodiments, when the detected traffic is of stable type, Tcc, 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 Tcc, etc. In another embodiment, Tcc, 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.

In some embodiments, when the detected traffic is of bursty type, Tccis set to a short duration, to revert to a lower TWT SP duration310when the burst communication has finished by setting Tccusing a function of burst duration Tburand valley duration Tvalas calculated by the state machine900. In this case, the update of Tcccan be expressed as the following function:
Tcc=f(Tbur,Tval).

One example of this function can be:
Tcc=Tbur+0.25*Tval.

In some embodiments, the polling cycle Tcccan 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.

For random traffic, in some embodiments, Tcccan 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

To compute the required TWT service period TWd, an estimated data time Tdtcan be used. The data time Tdtcan be calculated based on a combination of the amount of data communicated and the network conditions. For example, the data time Tdtcan be estimated according to the following model:

Td⁢t=(Bt⁢xSt⁢x+BrxSrx)·(α1-TccaTo⁢n+1-α)=Td⁢a⁢t⁢a·(α1-TccaTo⁢n+1-α)
where Btx, and Brxare the amounts of data transmitted and received, respectively, Tccais the channel clearance assessment time, Tonis the radio on time, Stxand Srxare 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

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 Twdis updated. On encountering an overflow trigger during the bursty traffic type, the update formula is as follows:
Twd,i+1=Twd,i+δOF
where i is the index of the ith TWT SP and δOFis an overflow update guard. As can be seen here, instead of updating on the Tdt,max, the STA updates on the previous Twd. This reduces the amount by which the Twdscales. 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.

An overflow threshold ρOFis 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 Twdneeds 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, ρOFis kept as 0.1. This reduces the probability of unnecessary overflows occurring and wasting power.

Stable Update

As noted here, for stable traffic and the stable guard δstable,the standard deviation of the traffic data time in a stable update polling cycle Tdt,stdis used instead of 10% of the Tinv. This is because in stable traffic, the STA just accommodates for the variation in traffic which is deterministic.

Example values of the parameters used for determining the TWT SP duration310based 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 1Traffic type based TWT parameter designTraffic TypeParametersRandomStableBurstOverflow Threshold0.20.10.1Percentage, ρOFOverflow Threshold,max(ρOF* Twd, 1500 ms)TOFOverflow Update0.2 * TinvGuard, δOFOverflow UpdateTdt, max+ δOFTdt, max+ δOFTwd+ δOFStable Updatemax(0.1 *max(Tdt, std, ϵ)max(0.1 *Guard, δstableTinv, ϵ)Tinv, ϵ)Stable UpdateTdt, max+ δstableBoost Multiplier,3.521mboostBoost Offset, cboost4004001500

TWT Release and Resumption

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 Twdto TWT Interval Tinv, or

Tw⁢dTi⁢n⁢v),
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.

For TWT release, there are two criteria to consider:

Ti⁢n⁢v-Tw⁢d<To⁢v⁢e⁢r⁢h⁢e⁢a⁢dTw⁢dTi⁢n⁢v<Dmax
where Toverheadis the overhead time associated with the TWT associated signaling between the STA and AP, and Dmaxis the maximum duty cycle beyond which power saving capability of TWT is minimal compared to having no TWT set up. Dmaxis 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.

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:

Td⁢tTo⁢b⁢s<⁢Dhysteresis
where Tobsis the observation time in which the data time Tdtis calculated and the observation time is set to the resumption poll period, and Dhysteresisis the hysteresis duty cycle which is set to discourage frequent TWT resumption and release in case the traffic fluctuates below Dmax.

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

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 Sctime unit, where a typical value of Scis 500 ms. In contrast, the TWT parameters accommodate the statistical variation of the traffic at a much finer time scale Sf, where a typical value of Sfis 25 ms.

FIG.14illustrates a diagram1400showing an example of fine and coarse time-scale for traffic statistics observation according to embodiments of the present disclosure. As is shown inFIG.14, the network statistics X can be observed on a fine time scale Sfor on a coarse time scale Sc, which can give the observation results as Xfor Xc. 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 Tdtfor the TWT operations in order to accommodate the current throughput at the current network condition, and the like.

FIG.15illustrates example charts1501-1502showing 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 inFIG.15, the variation of the packet number in every fine time-scale observation time slot (as shown in the chart1501) is much larger than the variation of the packet number in every coarse time-scale observation time slot (as shown in the chart1502).

FIG.16illustrates an example process1600for dynamically updating network statistics variation according to embodiments of the present disclosure, as may be performed by a STA (e.g., one of the STAs111-114as illustrated inFIG.1). The embodiment of the process1600shown inFIG.16is for illustration only. Other embodiments of the process1600could be used without departing from the scope of this disclosure.

In the process1600, 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.

To better explain the relationship between χfand χc, in the process1600, network statistics of the total amount of transceived data B25of every 25 ms can be used as an example. At step1602, network statistics Xfare collected at the fine time scale Sf. If the fine time scale observation of B is performed every 25 ms, then this can be expressed as:
B25=χf25.

At step1604, the variation of B25from the fine time scale observation is computed as:
var(χf25)=σf2.

At step1606, network statistics χcare collected at the coarse time scale Sc. If the coarse time scale observation of B is performed every 500 ms, then the estimated {circumflex over (B)}25can be expressed as:

Bˆ2⁢5=χc2⁢5=B5⁢0⁢0N1=1N1⁢∑i=1N1χf2⁢5[i],
where N1=50.

As can be seen above, the coarse time scale observation result χc25can be viewed as the statistical mean of the χf25. In the meantime, the variance of the coarse time-scale observation var(χc25)=σc2can be obtained. If the network statistics remain unchanged, then the following relationship applies:

σc2=var⁢(χc2⁢5)=var⁢(1N1⁢∑i=1N1χf2⁢5[i])=1N12⁢∑i=1N1var⁢(χf2⁢5)=1N12⁢N1⁢σf2=1N1⁢σf2.

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

σc2=1N1⁢σf2.

At step1608, the difference of σc2and σf2is 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 Xcand the previously acquired fine time scale statistics variation σf2can be used to estimate the needed TWT parameters.

At step1610, the coarse time scale variation σc2can be acquired by accumulating χcin a size M FIFO buffer and calculating its variance. If the coarse time scale observation interval Scand the fine time scale observation interval Sfhas a relationship Sc=K·Sf, then the coarse time scale observed statistics' variation σc2can have the relationship of:

σc2=1K⁢σf2.

At step1612, it is tested if

σc2-σf2K≥err
to determine whether the statistical variation at the small time scale has changed. A typical value of err can be 0.05σc2. If the test result is true, then a fine time scale sampling or observation is needed again to update σf2, and the process1600returns to step1602.

FIG.17illustrates a chart1700showing an example of using the process1600according to embodiments of the present disclosure. The chart1700depicts dynamically updating the observation time scale for the estimation of network statistics. As shown inFIG.17, the traffic statistics are initially observed at a fine time scale and the variation of the traffic statistics σfis 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 σc2is larger than

1N1⁢σf2+e⁢r⁢r.
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

σc2≥1N1⁢σf2+e⁢rr.

In another embodiment, the value of χfcan be estimated with a linear mapping of χc. A mapping between the finely sampled data χfand the coarsely sampled data χccan be created. The values of χcand χfcan be the throughput in some embodiments. In other embodiments, χcand χfcan be the calculated data time Tdt. In these embodiments, a linear mapping can be observed between the coarsely and finely sampled data, which can be formulated as:
χf=mboost*χc+cboost
where mboostand cboostare the linear mapping factors used to map the coarsely calculated χcto an estimate of the finely calculated χf.

In some embodiments, the coarse observation time and fine observation time are equal (i.e., Sc=Sf), and thus the observed data are also equal (χc=χf). In these embodiments, an exemplary time for Scis Tinvand no estimation of fine-time scale statistics is required. The statistics calculated in these embodiments are used as is for estimation of Twd.

FIG.18illustrates a method1800for 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 STAs111-114as illustrated inFIG.1). An embodiment of the method1800shown inFIG.18is for illustration only. One or more of the components illustrated inFIG.18can 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.

As illustrated inFIG.18, the method1800begins at step1802. At step1802, a STA obtains statistical information of incoming network traffic. This could include, for example, the STA111obtaining statistical information of incoming network traffic from the AP101, 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.

At step1804, 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 STA111implementing the state machine900to classify the incoming network traffic as at least one of bursty traffic, random traffic, and stable traffic.

At step1806, 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 STA111using 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 STA111.

AlthoughFIG.18illustrates one example of a method1800for traffic type detection and Wi-Fi parameter design, various changes may be made toFIG.18. For example, while shown as a series of steps, various steps inFIG.18could overlap, occur in parallel, occur in a different order, or occur any number of times.

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.