FIGURES 1 through 21c, 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.
Embodiments of the present disclosure recognize that TWT operation between STAs in a WLAN can help save device power by setting a specific device wakeup Interval
and wakeup Service Period
. Concurrently, the TWT function can also introduce additional latency to the traffic and power consumption to the device. The maximum latency that the TWT function can be allowed introduce is related to two conditions. First, whether the
ratio is large enough to ensure that the TWT-introduced latency can be upper-bounded and therefore the throughput is not affected by TWT operation. Second, whether the TWT-introduced latency
can be smaller than the desired maximum latency.
Accordingly, embodiments of the present disclosure provide apparatuses and methods that enable a STA to find a smallest possible
ratio (
i.e., minimum required duty cycle) with a largest possible
(
i.e., maximum allowed latency) for TWT operation, which can cause the TWT-introduced latency to be upper-bounded by the desired latency while saving the largest amount of power possible. Specifically, embodiments of the present disclosure provide methods for estimation of data transceiving time with or without congestion for TWT parameter design, as well as methods for joint design and optimization of the TWT service period and interval parameters.
Embodiments of the present disclosure describe estimating a target layer (e.g., an open systems interconnection (OSI) model layer) effective data rate and data transceiving time, which can be accomplished by the following sequence of operations. First, using a mapping method to map the PHY layer data rate to the effective data rate of a target layer or layers (e.g., layers in the OSI model other than the PHY layer). Then, this effective data rate can be used to estimate the data transmitting and receiving time (i.e., data transceiving time) at the target layer. Next, using the clear channel assessment (CCA) time and the radio-on time to estimate the congestion level and adjust the estimated data transceiving time for TWT parameter design. Finally, using a TxGoodRate parameter (defined below) to estimate the retransmission rate of the packets due to hidden nodes in the WI-FI network or a malfunctioning AP, and then adjusting the estimated data transceiving time for TWT parameter design.
Embodiments of the present disclosure also describe jointly determining a substantially optimal TWT service period and TWT interval for TWT operation, which can be accomplished by the following sequence of operations. First, using the ratio of the estimated total data transceiving time
during an observation time
to estimate the minimum required TWT duty cycle
Or alternatively, using the target layer throughput and the target layer effective data estimate the
Then, using the estimated
and the maximum allowed TWT-introduced latency
to determine the TWT service period first, and then determine the TWT interval based on the TWT service period (or alternatively, using
and
to determine the TWT interval first, and then determine the TWT service period based on the TWT interval).
FIGURE 1 illustrates an example wireless network 100 according to various embodiments of the present disclosure. The embodiment of the wireless network 100 shown in FIGURE 1 is for illustration only. Other embodiments of the wireless network 100 could be used without departing from the scope of this disclosure.
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.
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 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.
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. Although FIGURE 1 illustrates one example of a wireless network 100, various changes may be made to FIGURE 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.
FIGURE 2a illustrates an example AP 101 according to various embodiments of the present disclosure. The embodiment of the AP 101 illustrated in FIGURE 2a is for illustration only, and the AP 103 of FIGURE 1 could have the same or similar configuration. However, APs come in a wide variety of configurations, and FIGURE 2a does not limit the scope of this disclosure to any particular implementation of an AP.
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.
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.
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 forward channel signals and the transmission of reverse channel signals by the RF transceivers 209a-209n, the RX processing circuitry 219, and the TX processing circuitry 214 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.
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.
As described in more detail below, the AP 101 may include circuitry and/or programming for determining parameters for TWT operations in WLANs. Although FIGURE 2a illustrates one example of AP 101, various changes may be made to FIGURE 2a. For example, the AP 101 could include any number of each component shown in FIGURE 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.
FIGURE 2b illustrates an example STA 111 according to various embodiments of this disclosure. The embodiment of the STA 111 illustrated in FIGURE 2b is for illustration only, and the STAs 111-115 of FIGURE 1 could have the same or similar configuration. However, STAs come in a wide variety of configurations, and FIGURE 2b does not limit the scope of this disclosure to any particular implementation of a STA.
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.
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).
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.
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 forward channel signals and the transmission of reverse 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. In some embodiments, the controller/processor 240 includes at least one microprocessor or microcontroller.
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 jointly determining a TWT service period (SP) and TWT interval (I) to find the specific SP and I parameters 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.
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).
Although FIGURE 2b illustrates one example of STA 111, various changes may be made to FIGURE 2b. For example, various components in FIGURE 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 FIGURE 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.
FIGURE 3 illustrates a diagram 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.
FIGURE 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.
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.
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.
In some embodiments, a TWT parameter set field is used to negotiate the TWT parameters. FIGURE 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.
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 FIGURE 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. FIGURE 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 FIGURE 6.
FIGURE 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 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 end of TWT SP duration to enter doze state 312, as shown in graph 304.
As discussed above, the TWT parameters (e.g., TWT interval, TWT SP period, etc.) are negotiated in response to the STA sending a TWT negotiation request. Current methods of determining TWT parameters do not estimate transceiving time with or without congestion for TWT parameter design. In addition, current methods do not provide for the joint design and optimization of TWT interval and TWT SP.
FIGURE 8 illustrates an example of TWT buffered packets and maximum TWT-introduced latency according to embodiments of the present disclosure. As discussed above, there are two conditions (or constraints) on the maximum TWT-introduced latency that can be allowed. First, the
ratio should be large enough to ensure that the TWT-introduced latency can be upper-bounded and therefore the throughput is not affected by TWT operation. Second, the TWT-introduced latency should be smaller than the desired maximum latency
This can be, for example, the largest amount of TWT-introduced latency that can be tolerated by a network application.
The first condition ensures that TWT-introduced latency is bounded, and thus the data throughput is not affected by TWT operation. As illustrated in FIGURE 8, the buffered packets are defined as the packets that are generated by the AP and STA right after the start of the End-of-SP overhead and before the start of the next End-of-SP overhead. The total time duration of the buffered packets region is the TWT interval. The goal is to ensure that the buffered packets generated during the time period of the TWT interval
can all be transmitted in one TWT service period
Accordingly, the maximum TWT-introduced latency
is bounded by
, where
is the TWT-introduced overhead time including the Start-of-SP and End-of-SP overhead.
From the above, it can be seen that the core problem of the first condition is determining the
ratio. As long as the traffic transmitting speed is higher than the traffic generating speed, a large enough
ratio can always be found which satisfies the first condition to ensure the maximum TWT-introduced latency is bounded. However, the
ratio is also a direct measurement of how much power can be saved by TWT operation. The smaller
is, the more power is saved with TWT operation. Thus, in order to maximize power savings from TWT operation, a method is presented herein to find the minimum
ratio that can satisfy the first condition.
A sub-problem in finding the solution to meet the first condition is the data time estimation problem. To find the minimum
needed for the amount of data packets generated during a period of
, it is necessary to be able to estimate the total amount of time required to transmit those data packets. The traffic statistics that are available to a STA are the number and size of network layer transmitted (TX) and received (RX) packets, and the physical (PHY) layer data rate. For convenience of explanation, the network layer discussed in this disclosure is the IP layer, but it is understood that any suitable network layer could be used. The information available to the STA to indicate the congestion of the environment are the STA clear channel assessment (CCA) time and radio-on time. Thus, a method is presented herein to estimate the total time to transmit the IP layer packets with the information of the PHY layer data rate, CCA and radio-on time.
After finding the minimum
ratio that satisfies the first condition, and knowing that the maximum latency is bounded by
, the second condition is used to check if the upper-bound of the maximum latency
is smaller than the desired maximum latency. It can be seen that, after fixing the
ratio, if the absolute value of
and
are small enough, it can also be ensured that the maximum latency
is smaller than the desired maximum latency. However, a smaller
means more frequent wakeup, which can introduce more TWT related overhead power consumption. Thus, a method is presented herein to find the maximum possible
, for a determined
ratio, to ensure that the TWT-introduced latency is smaller than the desired maximum latency while the TWT-introduced overhead power consumption is also kept to a minimum.
In summary, the present disclosure introduces methods that finds a smallest possible
ratio with a largest possible
for TWT operation, which can cause the TWT-introduced latency to be upper-bounded by the desired maximum latency while saving the largest amount of power possible.
FIGURE 9 illustrates an example of observation of TWT operations according to various embodiments of the present disclosure. The methods of the present disclosure use observed traffic and network statistics with a data time estimation model to estimate the minimum required duty cycle of the TWT operations, and then use a method for jointly determining a TWT service period (SP) and TWT interval (
I) to find the specific SP and
I parameters for TWT operation. As is shown in FIGURE 9,
is the observation period during which the traffic statistics (
e.g. total transmitted and received packet length) and the network conditions (
e.g. the PHY data rate, congestion level, hidden nodes scenario, etc.) are collected by a STA. Due to hardware limitations, the observation frequency often cannot be very high. Thus
is typically larger than the TWT interval
I. In some embodiments,
can be a multiple of TWT interval
.
FIGURE 10 illustrates an overview of an example process for determining TWT parameters according to various embodiments of the present disclosure. For convenience of explanation, it is assumed that the embodiments of the present disclosure are performed by an electronic device, such as a STA 111, but it is understood that any suitable device could perform these embodiments.
During an observation period
, the traffic statistics (
e.g. total length of transmitted and received packets) and the network conditions (PHY data rate, congestion level, hidden nodes scenario, etc.) are collected (block 1002). Then those observed traffic statistics, network conditions during
, and the developed data transceiving time estimation model are used to estimate the require total data transceiving time
during
(block 1004). Then the minimum required duty cycle (the minimum acceptable SP/I ratio) can be found (
i.e., determined or calculated) based on
and
, or based on the throughput and effective data rate (block 1006). Then, with the given maximum latency requirement and the minimum required duty cycle, the developed joint TWT SP and TWT interval update method can be used to find and adjust the TWT SP and interval (block 1008).
As discussed above, the target layer effective data rate and the data transceiving time can be estimated by the following operations. First, using a mapping method to map the PHY layer data rate to the effective data rate of a target layer or layers (e.g., layers in the OSI model other than the PHY layer). Then, this effective data rate can be used to estimate the data transmitting and receiving time (i.e., data transceiving time) at the target layer. Second, using the clear channel assessment (CCA) time and the radio-on time to estimate the congestion level and adjust the estimated data transceiving time for TWT parameter design. Third, using a TxGoodRate parameter (defined below) to estimate the retransmission rate of the packets due to hidden nodes in the WI-FI network or a malfunctioning AP, and then adjusting the estimated data transceiving time for TWT parameter design. These operations comprise the data transceiving time estimation model of block 1004. Each of these operations is described in further detail below.
As discussed above, in order to find the minimum
ratio that can cause the TWT-introduced latency to be bounded, a model to estimate the required time for transmitting and receiving certain amounts of traffic (the data transceiving time) is needed. The main difficulty is that the traffic data observed at the STA can be, but is not limited to, the number and size of packets in the transport layer, the network layer (
e.g., the IP layer in examples below), or the data link layer (
e.g., the MAC layer in examples below). At the same time, the data rate information that is available to the STA is the PHY layer data rate.
FIGURE 11 illustrates an example of transport layer data packet configurations according to various embodiments of the present disclosure. As illustrated in FIGURE 11, to send the transport layer data packets, the PHY and MAC layer can use no-aggregation, Aggregated MAC Service Data Unit (A-MSDU), or Aggregated MAC Protocol Data Unit (A-MPDU). When no-aggregation is used, each MAC Service Data Unit packet can have its own MAC and PHY header. When A-MSDU is used, several IP layer packets are aggregated together to use one shared MAC and PHY header. When A-MPDU is used, several MAC frames are aggregated together to use one shared PHY header.
In order to calculate the data transceiving time, a method is needed to map the PHY data rate to the effective data rate of the layer of the observed packets (e.g., MAC, IP, transport layer effective data rate), referred to as the target layer of the mapping. For ease of explanation, the examples discussed below use the transport layer as the target layer, but it is understood that the disclosed mapping method can be applied analogously to other layers in the OSI model.
FIGURE 12 illustrates an example of components involved in the time required for transmission of a PHY layer data packet according to various embodiments of the present disclosure. When there is no congestion caused by other STAs, excluding the random back-off time, the time to transmit the transport layer packets in one PHY frame can be modeled as:
In equation (1),
is the time to transmit the PHY header, where
is the length of the PHY header and
is the PHY data rate with the lowest modulation and coding scheme (MCS) order.
is the time to transmit the MAC header, where
is the length of the MAC header and
is the PHY data rate with the current MCS order.
is the time to transmit the IP head, where
is the length of the IP header and
is the PHY data rate with the current MCS order.
is the time to transmit the transport layer packets, where
is the length of the transport layer packets and
is the PHY data rate with the current MCS order.
is the Short Inter-Frame Spacing time, which is a constant. SIFS is the amount of time required for a wireless interface to process a received frame and to respond with a response frame. In some instances, it is the difference in time between the first symbol of the response frame in the air and the last symbol of the received frame in the air. A SIFS time includes the delay in receiver RF, Physical Layer Convergence Protocol (
PLCP) delay and the MAC processing delay.
is the time to transmit the acknowledgement frame from the STA to the AP, where
is the length of the acknowledgement frame.
Depending on the level of A-MPDU and A-MSDU, there can be different
,
, and
values, all of which are positive integers.
Other than above terms, there are still some other overhead components -
e.g., MAC layer management frames, from the transport layer perspective, are overhead. All such other overhead is represented as
The effective transport layer data rate
can then be defined as:
In order to estimate the minimum TWT SP required for transport layer packets with a length
needs to be estimated from the observed PHY data rate
In one embodiment, this estimation can be achieved with a segmented linear mapping, where:
and
are the effective transport layer transmitting and receiving data rates, respectively. If the observed packets are in the MAC or IP layer, then
and
are the effective MAC or IP layer transmitting and receiving data rates, respectively.
and
are the PHY layer transmitting and receiving data rates, respectively (which are collectively the PHY data rate
).
The PHY data rate
and
are segmented into several speed regions. Within each region, mapping factors
and
are empirically acquired. This is because the MAC payloads (transport layer packets) are transmitted with the PHY data rate while the PHY/MAC overheads take almost the same time to transmit regardless of the difference of PHY data rate. Thus, with the increase of the PHY data rate, the portion of the time used to transmit the MAC payloads will become smaller compared with the PHY/MAC overheads, and the effective transport layer data rate
will also become smaller.
and
can be acquired by performing an experiment to measure the total length of the transport layer packets
transmitted/received during an observation time interval
with a PHY data rate
and
in a certain region when the throughput is pushed to the maximum. Thus the total time needed for transmitting and receiving
bytes of transport layer packets with a PHY data rate of
and
(the estimated target layer data transceiving time) can be written as:
Some exemplary values of
and
are:
In order to estimate the minimum TWT SP required for transport layer packets with a length
needs to be estimated from the observed PHY data rate
In another embodiment, estimating
from the observed PHY data rate
can be achieved with a continuous mapping function to map the PHY data rate to the effective data rate of the target layer. The mapping model is a function of both the PHY layer data rate and the transport layer average packet size. The estimated target layer data transceiving time without congestion in this embodiment can be modeled as:
As in the segmented mapping model,
and
are the total length of the transport layer packets that are transmitted and received during a period of observation time
. A typical value range of
is 20ms to 3s.
and
are the PHY layer transmitting and receiving data rates, respectively (which are collectively the PHY data rate
). The functions
and
are the continuous mapping functions to map the PHY layer data rate to the transport layer data rate. The mapping functions
and
are functions of both the PHY layer data rate (
and
) and the transport layer average packet size (
and
) of every
.
The mapping function
can be one of the two forms:
where
and
are a function of the average transmitted packet size
and
can be obtained empirically.
The mapping function
can be one of the two forms:
where
and
are a function of the average received packet size
and
can be obtained empirically.
and
can be calculated as
and
, respectively, where
and
are the total transmitted and received, respectively, transport layer packet sizes during
, and
and
are the total number of transmitted and received, respectively, transport layer packets.
In general, the
and
mapping functions can be derived by measuring, at the STA, the throughput for different PHY data rates with different average transport layer packet sizes
and
under a fixed TWT interval and SP duration when there is no congestion, and then using curve fitting to find the best function to describe the relationship between the PHY data rate and the corresponding transport layer throughput.
FIGURES 13a-13b illustrate some examples of measured throughput and fitted throughput for different average transport layer packet sizes
and
according to various embodiments of the present disclosure. In particular, examples are shown for
and
in FIGURE 13a, and for
and for
in FIGURE 13b. At each PHY data rate (TxSpeed corresponding to
, RxSpeed corresponding to
), the maximum achievable transport layer throughput when there is no congestion is recorded (illustrated as the raw data points in FIGURES 13a-13b). The transport layer throughput for a given PHY data rate can vary, as shown by the range of raw data throughputs for each PHY data rate.
For each PHY data rate at each different average transport layer packet size, the 30th percentile of the measured transport layer throughputs are selected as representative throughputs (the representative data points, such as data point 1302), and then a function that is a one-to-one mapping of each PHY data rate to a representative transport layer throughput is built (represented by the measured throughputs, such as 1304). Next, curve fitting is performed to find the best function (represented by the fitted throughputs, such as function 1306) to model the relationship between the PHY data rate and the corresponding transport layer throughput.
After the curve fitting, the uplink mapping function
for different average transmitting packet sizes
can be described, for example, as follows:
Similarly, the downlink mapping function
for different average receiving packet size
can be described as follows:
As the models described above do not account for congestion, they are suitable for the situation where there is little to no congestion in the environment. When there is environmental radio interference, the congestion time needs to be accounted for in the transmission of a data frame. Various methods are provided below to use the clear channel assessment (CCA) time and radio-on time of the STA to determine a congestion factor representing the estimated congestion level of the environment. In the context of these methods, the target layer data transceiving time determined according to one of the above embodiments can be considered an initial estimate of the target layer data transceiving time without congestion, and the congestion factor determined below can be used to adjust this initial estimate to obtain an estimation of the target layer data transceiving time with congestion.
One embodiment of a method to use CCA and radio-on time of the STA to estimate congestion level is an inverse-CCA-over-Radio-on model. The radio-on time represents the time that the STA is awake (
i.e., when the WI-FI radio of the STA is on). It is assumed that during the awake time of the STA, the STA is mainly working on transmitting/receiving data or waiting for another STA to transmit due to congestion. The CCA time mainly represents the time that the STA uses to sense the channel to determine whether the channel is busy. If the channel is busy, the CCA action may be repeated until the channel is found to the idle. Thus, the CCA time is a good indicator of the congestion level of the channel. The radio-on minus CCA time can be proportional to the time that is actually used to transmit and receive data. Thus, the total time used to transmit and receive data packets of length
and time spent on congestion can be represented by:
Which can be rewritten as:
where
RadioOn is the radio-on time of the STA during the observation period
,
is the CCA time during
, and
is the data transceiving time without congestion during
, which can be estimated, for example, with the segmented linear mapping model in Equation (5) or the continuous mapping model in Equation (6).
is the estimated congestion factor of the inverse-CCA-over-Radio-on model, and can be referred to as a data transceiving time amplification factor.
is calculated as
which represents the estimated network congestion level during the observation period
and is obtained at least in part based on a congestion level estimation model.
The
parameter is a tuning parameter that compensates for any modeling errors in the above calculation of the estimate of
and any modeling errors in calculating the estimated congestion factor. The
parameter is empirically derived (
e.g., from curve fitting). For example, empirical measurements are taken of a total amount of time
needed to transmit and receive target layer packets with total length of
when the throughput is pushed to the max. At the same time,
is calculated (
e.g., with the segmented linear mapping model discussed above), and the inverse-CCA-over-Radio-on congestion factor is calculated (
e.g., as in Equation 11.3)).
can be then be determined by comparing the value of the inverse-CCA-over-RadioOn amplification factor with
(the amplification factor of
) for each of the empirically measured
data points. FIGURE 14 illustrates an example of this comparison. A least squares estimate can be used to fit a curve to the data points and obtain the value of the
parameter. As shown in FIGURE 14, an exemplary value of
is 1.9. The 1-
value is designed such that when there is no congestion, the data transceiving time amplification factor for congestion will be equal to 1.
Another embodiment of a method to use CCA and radio-on time of the STA to estimate congestion level is a segmented linear CCA-over-RadioOn model. The congestion time can be positively proportional to the CCA-over-RadioOn value. Thus, the total time used to transmit and receive data packets of length
and time spent on congestion can be represented by:
As in the inverse-CCA-over-RadioOn model,
RadioOn is the radio-on time of the STA during the observation period
,
is the CCA time during
and
is the data transceiving time without congestion during
, which can be estimated, for example, with the segmented linear mapping model in Equation (5) or the continuous mapping model in Equation (6).
here is the estimated congestion factor (or data transceiving time amplification factor) of the segmented linear CCA-over-Radio-on model. The
is a constant which is related to the TWT overhead time per SP. One exemplary value of the
is 0.01. The value of
can have a range of 0 to 0.1. The value of
is segmented for different values of
(the CCA-over-Radio-On ratio), as represented by:
This is due to modeling the increment of the congestion time as saturated when the CCA-over-Radio-On ratio is large. An exemplary set of segmented factor values with respect to the CCA-over-Radio-On ratio is:
In another embodiment for considering the effect of congestion, the total data time
with congestion can be estimated with a regression model. The regression model utilizes various machine-learning-based regression algorithms like Linear Regression, Random Forest Regression, Support Vector Regression, Neural Networks and Multi-Layer Perceptron. As inputs to these models, multiple inputs/features can be considered, such as CCA Time, Radio On Time, Packet Count, Observation Time (the time between which these values are observed), PHY data rate, frequency band, bandwidth, number of retransmissions for transmitted packets from the STA, and retransmission rate of transmitted packets from STA. As an exemplary model, the multivariate linear regression model for
can be formulated as:
where
is the observation time during which the statistics are collected, and
is the count of all the packets communicated within the observation time. In some instances, the observation time
can span multiple TWT intervals. The
value obtained from this regression cannot be negative or greater than
. The regression model is bounded in the negative domain by setting the minimum value to the smallest permissible value in the system. If
is greater than the maximum permissible value in the system, then
is set to the maximum permissible value. As an example in one embodiment, the minimum and maximum permissible values can be set to 0 and
, respectively.
In addition to congestion, hidden nodes or a malfunctioning AP can increase the effective time required to transmit and receive all data packets in one TWT SP (and thus decrease the effective data rate) by requiring retransmission of failed data packets. FIGURE 15 illustrates an example of the hidden node problem according to various embodiments of this disclosure. As illustrated in FIGURE 15, STA1 is used for gaming (
i.e., an application with small transceiving packet size) and is in communication with a
high power AP 1502. STA2 and STA3, which are low power stations, are also communicatively coupled to the
AP 1502. STA2 and STA3 are hidden nodes for STA1, and the hidden node problem can only be captured by the
factor, described further below. It is noted that even though the hidden node problem can sometimes be avoided by the Request-To-Send (RTS) and Clear-To-Send (CTS) control frames, RTS and CTS are usually not used by the AP when the transmitted packet sizes are small. In those scenarios, a hidden node problem can often exist.
In some embodiments, a data time estimation model considering both the congestion level and retransmission due to hidden nodes or a bad AP can be described as follows:
where
is the data time without congestion, which can be calculated, for example, by the segmented linear mapping model in Equation (5) or the continuous mapping model in Equation (6). The
factor can have the same form as the one in Equation (11) or Equation (12).
represents the estimated required retransmission factor, or a data transceiving time amplification factor for retransmission.
is the time duration that the packet statistics are recorded, and
is the current TWT interval.
represents the additional time other than data transceiving that is spent in each TWT service period. The
quantity represents the total TWT overhead during
. A typical value range of
is from 1000 microseconds to 3000 microseconds.
In an exemplary embodiment, the continuous mapping model in Equation (6) is used to estimate the target layer data transceiving time without congestion, and the inverse-CCA-over-Radio-on model of Equation (11) is used to estimate the data transceiving time amplification factor for congestion, resulting in a complete target layer data transceiving time estimation model written as:
models the impact of hidden nodes, and can be calculated as:
where
is the number of successfully transmitted MPDUs (or data packets) during
,
is the number of MPDUs (or data packets) for which transmission was unsuccessfully attempted during
, and
is the number of retransmitted MPDUs (or data packets) during
.
The parameter
is a segmented linear function of
, which can be acquired empirically. An exemplary set of segmented values for
is shown below:
Referring again to FIGURE 10, once
has been found according to the above embodiments,
block 1004 is complete. The next step, in
blocks 1006 and 1008, is to solve the problem of jointly finding the smallest possible
ratio and the largest possible
for TWT operations, which can cause the TWT-introduced latency to be upper-bounded by the desired maximum latency while saving the largest amount of power possible.
The complexity of solving this problem (
e.g., using existing approaches) is demonstrated by the tradeoff between TWT-introduced latency and additional power consumed by TWT overhead after the
ratio is determined. For example, for a given
ratio, reducing the TWT-introduced latency reduces the TWT interval
, which increases the total number of TWT sessions within a fixed amount of time, and therefore increases the power consumed by the TWT overhead. On the other hand, for a given
ratio, reducing total power consumed by the TWT overhead may require increasing the TWT interval
, which in turn increases the TWT-introduced latency. In view of this tradeoff, this disclosure provides several approaches to find the
and
which can satisfy the minimum duty cycle requirement and consume the smallest amount of power possible.
In order to maintain the existing Quality-of-Service (QoS) level after turning on TWT operations, it is necessary to ensure that the traffic throughput and the service latency are not affected. FIGURE 16 illustrates an example of the change in data packet transmission when turning on TWT operations according to various embodiments of the present disclosure. As can be seen in FIGURE 16, to ensure that the throughput is not affected during a period of time equal to the TWT interval, all of the packets that are scheduled to be transmitted and received during the TWT interval need to be transmitted and received during the STA wakeup time/service period of the TWT operation. Thus, the traffic throughput controls the minimum required duty cycle (
i.e., the minimum
ratio) of the TWT.
As the resolution of the traffic statistics observable by the STA is limited by the maximum polling frequency (smallest
) of the traffic statistics, the requirement to maintain the same throughput after turning on TWT operation is satisfied on the time scale of
. This disclosure provides three approaches to find the minimum required TWT duty cycle (
) which can satisfy the requirement to maintain the same throughput after turning on TWT operation at the time scale of
. These approaches can correspond to block 1006 of FIGURE 10.
In the first approach, the minimum required duty cycle is found by calculating the ratio of
to
. FIGURE 17 illustrates an example of the total amount of time needed to transmit and receive all packets generated during the observation period according to various embodiments of the present disclosure. As illustrated in FIGURE 17,
is the total amount of time needed to transmit and receive all packets generated during the observation period
.
can be calculated using one of the methods disclosed above, such as the target layer data transceiving time estimation model. Thus the minimum required duty cycle can be calculated as:
In the second approach, the minimum required duty cycle can be calculated based on the observed target layer transmitting throughput
, target layer receiving throughput
, effective target layer transmitting data rate
and effective target layer receiving data rate
during the observation period
and
can be calculated as
and
, where
and
are the total transmitted and received packet lengths, respectively, during
.
and
comprise the target layer effective data rate, which equals the total amount of the target layer packet length divided by the total amount of time to transmit and receive those packets. Thus
and
can be calculated using the target layer data transceiving time estimation models discussed above. As one example, when only considering congestion,
and
can be calculated as:
In another example,
and
can be calculated as:
where the functions
and
are from Equation (6).
Once
and
are determined, the condition of maintaining the same throughput during
can be represented as:
Then, because the minimum duty cycle is the minimum
ratio, the minimum duty cycle can be represented under this approach as:
In the third approach, the minimum required duty cycle is found by using a combined effective data rate
instead of separate effective transmitting and receiving data rates
and
. To acquire
, observations are made over a time period
and measurements are recorded of the total length of transmitted (and received) packets
(and
) as well as the effective transmitting (and receiving) data rates
(and
). Then the combined effective data rate
can be estimated by:
The total transmitting and receiving throughput
can then be obtained by:
The minimum duty cycle under this approach can then be represented as:
Referring to FIGURE 10, once the minimum required duty cycle has been determined at block 1006 according to one of the above approaches, an updated TWT SP and TWT interval are jointly determined at block 1008. As discussed above, two general approaches to this step are disclosed. The updated TWT SP can be determined first, and then the updated TWT interval can be determined based on the determined SP, or alternatively the updated TWT interval can be determined first, and then the updated TWT SP can be determined based on the determined interval.
FIGURE 18 illustrates a flowchart of an example, according to various embodiments of the present disclosure, of the general approach to jointly updating the TWT SP and interval in which the TWT SP is determined first and then the TWT interval is determined. Two embodiments within this general approach are provided below.
In the first embodiment, as discussed above, in order to maintain the QoS level after turning on TWT operations, it is necessary to ensure that the traffic throughput and the service latency are not affected. That is, two conditions (or constraints) need to be satisfied when determining the TWT SP and TWT interval. First, maintain the same throughput by ensuring that the TWT duty cycle is at least the minimum required TWT duty cycle (
as determined above), and second, ensure that the TWT-introduced latency not exceed the maximum allowed latency (
).
Because the duty cycle is the
ratio, the first condition can be represented as:
Because the TWT-introduced latency is the amount of time that the STA is not awake (
i.e.,
), the second condition can then be represented as:
If Equation (20) (
i.e., the first approach) is used to calculate
, then the following two inequalities can be written based on Equations (29) and (30):
From the first inequality in Equation (31), the following can be derived:
After finding an
satisfying Equation (32) based on the values of
and
(which corresponds to block 1802), then from the second inequality in Equation (31), the TWT interval can be determined based on
(at block 1804) as:
In some embodiments, the final values of
and
are calculated with a guard factor (
) that adds a margin of error to account for variance in traffic between updates to the values of
and
. In this case, the actual updated value of the TWT SP and the TWT interval which would not affect the QoS are calculated by:
with
and
An exemplary value of
can be 1.05. An exemplary value of
can be
. Values for the guard factors are determined based on traffic patterns before calculation of the TWT SP and the TWT interval. Methods for determining the value of the guard factors will be discussed below.
Returning to Equations (29) and (30) above, if Equation (24) (
i.e., the second approach) is used to calculate
then a similar derivation from Equations (29) and (30) results in the following expressions of
and
(including guard factors):
with, similarly,
and
an exemplary value of
can be 1.05, and an exemplary value of
can be
.
If, instead, Equation (28) (
i.e., the third approach) is used to calculate
then a similar derivation from Equations (29) and (30) results in the following expressions of
and
(including guard factors):
with, again,
and
an exemplary value of
can be 1.05, and an exemplary value of
can be
.
For simplicity of explanation, in the remaining embodiments of methods for joint TWT SP and interval updating disclosed below, the value of
will be calculated according to Equation (20) as the ratio of
to
and accordingly the derivation of the expressions for determining the updated TWT SP and interval will be in terms of
to
. However, the derivations remain the same if Equation (24) or (28) is used to calculate
.
Referring now to block 1806, determination of the guard factors will be discussed. As disclosed above, the values of the guard factors are related to the traffic type. As the observed traffic statistics in a current observation period
are used to estimate the best TWT SP and interval for the next observation period
, then enough margin of error needs to be provided when estimating the required data transceiving time
so that a variance in traffic pattern in the next observation period will not cause the TWT operation using the updated TWT SP and interval to fail to send and receive all of the data during the next observation period. Accordingly, if the traffic statistics are varying rapidly, the value of the guard factor needs to accommodate a large error margin.
FIGURE 19 illustrates an example of different traffic types according to various embodiments of the present disclosure. As can be seen in FIGURE 19, if the traffic statistics (
e.g. the total packet length) are varying a lot from one observation interval
to another, this could be a random traffic pattern. If the traffic statistics do not change much from one observation interval
to another, this could be a stable traffic pattern. To quantify the stability of the traffic pattern, the coefficient of variation (
) of the estimated
within a moving window of N observation periods
is calculated as:
where
is the standard deviation of the
estimated
values in a size N moving window of
, and
is the mean value of the N estimated
values in the size N moving window of
. The value of
guard can be calculated as follows depending on whether it needs to be larger than 1 or between 0 and 1:
This approach to finding the value of the guard factors is one exemplary approach. Other approaches can also be used as long as the values of guard1 and guard2 are in the required range.
Returning to
blocks 1802 and 1804, in the second embodiment of a joint TWT SP and interval updating method in which the TWT SP is determined first and then the TWT interval is determined, the same two conditions apply. First, maintain the same throughput by ensuring that the TWT duty cycle is at least the minimum required TWT duty cycle (
as determined above), and second, ensure that the TWT-introduced latency not exceed the maximum allowed latency (
.
In this embodiment, the TWT duty cycle
is first fixed to be the minimum required duty cycle
. Then, the expression of Equation (30) satisfying the latency requirement can be written as:
Then, using the
determined by the
over
ratio of Equation (20), the following can be derived:
After finding the
satisfying Equation (43) using the fixed value of
and the value of
(at block 1802), and because the duty cycle is fixed to the
determined by the
over
ratio, the interval can be determined based on the fixed value of
(at block 1804) as:
Adding in guard factors, the actual updated value of the TWT SP and the TWT interval which would not affect the QoS are calculated by:
with
and
. An exemplary value of
can be 0.99. An exemplary value of
can be
The actual values of the guard factors can be calculated using Equation (41).
After calculating the
and
values based on the above methods, if the ratio of
is too large, it means that the current throughput can be quite high compared with the transmitting and receiving data rate. In such a case, it might not be beneficial to continue using the TWT operation as the power that can be saved could be small and TWT operation can also cause additional TWT related latency and power consumption. That is, at
block 1807, for a threshold value
, if
, then the TWT connection is torn down (
i.e., stopped) at
block 1808.
can be between 0 and 1, and an exemplary value of
is 0.8. If the TWT connection is not torn down, the updated values of the TWT SP and the TWT interval are used to negotiate an adjusted TWT SP and the TWT interval (
e.g., with the AP) at
block 1809.
After the TWT is torn down and not operating, the STA can continue to measure traffic during an observation time
, and record the ratio of
to
(at block 1810). If the ratio of
to
is low, then the time consumed by data exchange between the AP and STA is low, which could mean conditions are good to set up TWT operation again in order to reduce power consumption without risking unacceptable latency increases. That is, at
block 1812, for a threshold value
, if
, then TWT operation is started. In some embodiments, TWT operation is started (at block 1814) with SP and interval values of:
based on the values calculated in the group of
blocks 1816, which can be similar to
blocks 1006 and 1802-1804.
can be between 0 and 1. An exemplary values of
is 0.6. This approach can also be used to determine when to start using TWT initially.
FIGURE 20 illustrates a flowchart of an example, according to various embodiments of the present disclosure, of the general approach to jointly updating the TWT SP and interval in which the TWT interval is determined first and then the TWT SP is determined. Two embodiments within this general approach are provided below. For both embodiments, the same two conditions (or constraints) used for the first general approach apply. Specifically, first, maintain the same throughput by ensuring that the TWT duty cycle is at least the minimum required TWT duty cycle (
as determined above), and second, ensure that the TWT-introduced latency not exceed the maximum allowed latency (
).
In the first embodiment, the TWT interval can be calculated based on the latency requirement and the minimum required duty cycle required to ensure the current throughput is not affected. As discussed above, the minimum required duty cycle can be obtained (at block 1006) according to Equation (20) as:
where, as above,
is the total observation time and
is the total estimated target layer data transceiving time during
. An exemplary
estimation method can be based on the observed total packet length, effective data rate, and the inverse-CCA-over-Radio-On model discussed above.
When a fixed latency
is used, ensuring that the minimum duty cycle requirement is met will require that the actual SP over I ratio be larger than the minimum duty cycle. Based on Equation (29), this can be expressed as:
Therefore, the value of the TWT interval can then be found (at block 2002) based on:
Based on finding an
value satisfying the latency requirement
and the minimum duty cycle requirement (in terms of the ratio of
to
) according to Equation (51), the
value can be calculated (at block 2004) based on
as:
The actual values of the updated TWT SP and TWT interval, including guard factors, which would not affect the QoS can then be calculated by:
with both
and
. As in the above embodiments, there are no constraints on how
is related to
, and any values of
and
are possible as long as both are larger than or equal to 1. An exemplary value of
is
An exemplary value of
is 1.05. The values of the guard factors may be calculated (at block 2006) as discussed above with respect to Equations (40) and (41), but other approaches can also be used as long as the value of
guard1 and
guard2 are in their required range.
In the second embodiment of a joint TWT SP and interval updating method in which the TWT interval is determined first and then the TWT SP is determined, the TWT interval may be determined based on a fixed duty cycle which can be the minimum duty cycle. When the duty cycle is first fixed to be the minimum duty cycle, then an expression ensuring that the latency requirement is met is written as:
The value of the TWT interval can then be found (at block 2002) based on:
Based on finding an
value satisfying the latency requirement
and the fixed minimum duty cycle requirement in terms of the ratio of
to
according to Equation (56), the
value can be calculated (at block 2004) based on
as:
The actual values of the updated TWT SP and TWT interval, including guard factors, which would not affect the QoS can then be calculated by:
with
and
. An exemplary value of
can be 0.99. An exemplary value of
can be
. As discussed above, the actual value of the guard factors can be calculated using Equations (40) and (41), but other approaches can also be used as long as the values of
guard1 and
guard2 are in their required range.
Similar to the first general approach of FIGURE 18, in the general approach of FIGURE 19, the thresholds
and
can be defined, and the updated TWT SP and TWT interval values calculated above can be used to determine when to tear down the TWT operation (at
block 2008, based on determining that
at block 2007) and when to set up the TWT operation (at
block 2012, based on determining that
at block 2010).
An example of the operation of the joint TWT SP and TWT interval updating methods disclosed above, using the first embodiment of FIGURE 20, is provided below. In this example, it is assumed that at
block 1006 the
needed to support current through is determined to be 80%, and it is assumed that the current network service will only allow the TWT-introduced latency to be a maximum (
) of 20ms. Using these values with Equations (53) and (54) gives a Step 1 calculation of:
and a Step 2 calculation of:
It can be seen that if the TWT interval is chosen to be 100ms and the TWT SP is chosen to be 80ms based on the above calculations, then the latency is
, which satisfies the maximum latency requirement of 20ms, and the duty cycle is
, which satisfies the minimum duty cycle requirement of 80%. This combination also provides the largest possible power savings, as desired.
To further illustrate, alternative values of
and
are considered for the Equations (60) and (61). If the TWT interval is chosen to be 90ms in
Step 1, this would result in a TWT SP of 70ms in
Step 2. This would satisfy the latency requirement (with a latency of 90ms - 70 ms = 20ms), but the duty cycle will then be 70/90 = 77.8%, which would not satisfy the minimum duty cycle requirement of 80%.
To illustrate even further, if the Equations (60) and (61) are ignored and a TWT interval of 90ms and a TWT SP of 72ms are chosen through other means, then both the maximum latency requirement and the minimum duty cycle requirement can be met, as the latency will be 90ms - 72ms = 18 ms and the duty cycle will be 72/90 = 80%. However, as the TWT interval is 10ms shorter than the value calculated using Equation (60), more power will be used on TWT overhead using these TWT parameters. For example, in 900ms, if
is 90ms, there will be 10 TWT intervals and 10 TWT sessions worth of overhead, while if
is 100ms, there will only be 9 TWT sessions worth of overhead, consuming less power. Accordingly, values of the TWT parameters other than those determined using Equations (60) and (61) are suboptimal.
FIGURES 21a-21c illustrate an example process for jointly updating a TWT service period and a TWT interval according to various embodiments of the present disclosure. For convenience, the process of FIGURES 21a-21c is discussed as being performed by a communication device that is a WI-FI STA, but it is understood that a communication device that is a WI-FI AP can perform the process, as can any other suitable wireless communication device. For ease of explanation, the process is assumed to be performed by the processor of the wireless communication device unless otherwise stated.
Referring to FIGURE 21a, the process begins with the communication device observing transmitted and received higher layer data packets in a TWT operation during an observation time period (
) (step 2105). For example, a transceiver of the communication device can be configured to transmit and receive the higher layer data packets, and a processor of the communication device can be configured to observe the higher layer data traffic and measure and record traffic statistics of the higher layer data traffic during the observation time period.
These traffic statistics can include, for example, physical (PHY) layer transmission and reception data rates (which together comprise the PHY layer data rate) and throughput. In some cases, throughput can be determined based on requirements of a network application on the communication device that generates the higher layer data traffic during the observation time period.
Next, the device determines, based on the PHY layer transmission and reception data rates during the observation time period, effective higher layer transmission and reception data rates (step 2110).
In one embodiment, as discussed above, transmission and reception mapping factors can be used to perform this step. For example, the device can select, based on the PHY layer transmission data rate, a transmission mapping factor from a set of transmission mapping factors. Similarly, the device selects a reception mapping factor from a set of reception mapping factors based on the PHY layer reception data rate. Then the device determines the effective higher layer transmission data rate as a product of the transmission mapping factor and the PHY layer transmission data rate, and the effective higher layer reception data rate as a product of the reception mapping factor and the PHY layer reception data rate.
In another embodiment, as discussed above, continuous mapping functions can be used to perform this step. For example, the device can determine the effective higher layer transmission data rate based on a first mapping function using the PHY layer transmission data rate and an average length of the transmitted data packets, and determine the effective higher layer reception data rate based on a second mapping function using the PHY layer reception data rate and an average length of the received data packets.
The device then estimates an initial data transceiving time (
) of the higher layer data packets based on the effective higher layer transmission and reception data rates and total lengths of the transmitted and received data packets (step 2115). In some embodiments, this estimation may be performed based on the total length of the transmitted data packets divided by the effective higher layer transmission data rate and the total length of the received data packets divided by the effective higher layer reception data rate.
Next, the device adjusts the initial data transceiving time to obtain a higher layer data transceiving time (
) based on an estimated network congestion level, an estimated required re-transmission rate, and a total amount of TWT overhead during the observation time period (step 2120). In some embodiments, this includes determining a first data transceiving time amplification factor (or data amplification factor) that represents the estimated network congestion level during the observation time period and a second data transceiving time amplification factor (or data amplification factor) that represents the estimated required re-transmission rate during the observation time period, then adjusting the initial data transceiving time using the first and second data transceiving time amplification factors along with the total amount of TWT overhead to obtain the higher layer data transceiving time.
For example, the first data transceiving time amplification factor that represents the estimated network congestion level during the observation time period can be determined as
as discussed above. Here,
is a clear channel assessment (CCA) time of the device during the observation time period,
is a radio-on time of the device during the observation time period, and
is a tuning parameter that is empirically derived.
The second data transceiving time amplification factor that represents the estimated required re-transmission rate during the observation time period can be determined as
. Here,
, where
is a number of the data packets that are successfully transmitted during the observation time period,
is a number of the data packets for which transmission is unsuccessfully attempted during the observation time period,
is a number of the data packets that are re-transmitted during the observation time period, and
is a tuning parameter that is determined as a function of
The device then determines a minimum duty cycle for the TWT operation (
) as a ratio of the higher layer data transceiving time to the observation time period (
) (step 2125). In some embodiments, the minimum duty cycle can be determined by alternative methods, as discussed above.
The device can then determine a new TWT service period (
) and a new TWT interval (
) for the TWT operation (step 2130). In various embodiments,
and
are determined based on the higher layer data transceiving time. For example, based on the minimum duty cycle that is itself determined based on higher layer data transceiving time at
step 2125, the
and
can be jointly determined under joint constraints that a latency introduced by the TWT operation does not exceed a maximum latency amount (
) and that the new TWT interval is as large as possible. The maximum latency amount represents a maximum amount of additional TWT-introduced latency that is acceptable for TWT operation, and may be based on requirements of a network application on the device.
In
step 2130, the new TWT service period (
) and a new TWT interval (
) for the TWT operation may be determined according to one of several embodiments. In some embodiments, the device first determines the new TWT service period based on the minimum duty cycle and the maximum latency amount, and subsequently determines the new TWT interval based on the new TWT service period.
For example, the device may first determine the new TWT service period as
. Based on this
, the device may then determine the new TWT interval as
with
and
, or as
with
and
. Here,
is the minimum duty cycle,
is the maximum latency amount, and
and
are each a value related to a traffic pattern over multiple observation time periods. They are each determined as
when the value needs to be greater than 1, and as
when the value needs to be between 0 and 1, where
is a coefficient of variation of data transceiving times of the data packets over the multiple observation time periods.
In other embodiments, the device first determines the new TWT interval based on the minimum duty cycle and the maximum latency amount, and subsequently determines the new TWT service period based on the new TWT interval. For example, the device may first determine the new TWT interval as
. Based on this
, the device may then determine the new TWT service period as
with
and
, or as
with
and
. Here,
is the minimum duty cycle,
is the maximum latency amount, and
and
are each a value related to a traffic pattern over multiple observation time periods. They are each determined as
when the value needs to be greater than 1, and as
when the value needs to be between 0 and 1, where
is a coefficient of variation of data transceiving times of the data packets over the multiple observation time periods.
After
step 2130, the device may use the new TWT service period and new TWT interval in various ways. Referring now to FIGURE 21b, for example, while TWT operation is turned on for the device, the device may determine whether TWT operation should be continued, or whether the TWT operation should be stopped (
i.e., torn down). To do this, the device first determines whether a ratio of the new TWT service period to the new TWT interval (
) exceeds a predetermined first threshold (
) (step 2135).
Based on the ratio
exceeding the first threshold at
step 2135, the device uses the new TWT service period and the new TWT interval to negotiate an adjusted TWT service period and TWT interval for the TWT operation (step 2140). As discussed above, the new TWT service period and the new TWT interval derived from the method in this case should provide the highest possible power savings without introducing unacceptable additional latency. The method may then return to step 2105 for continued monitoring of traffic statistics and updating of the TWT service period and TWT interval.
Based on the ratio
not exceeding the first threshold at
step 2135, the device stops the TWT operation (step 2145). For example, if the ratio
is below the threshold, this could indicate that the amount of data being transmitted and received is quite high (requiring a large
) compared to the transceiving data rate, and TWT may not provide much in the way of power savings to justify the latency introduced by TWT operation. The method may then proceed to step 2150, discussed below, to determine whether and when to resume TWT operation.
Referring now to FIGURE 21c, in the case that TWT operation is not currently turned on for the device (
e.g., if TWT operation was stopped according to
step 2135, or if the device has not yet turned TWT operation on at all), then the device may determine whether it would be beneficial to turn on TWT operation. To do this, the device observes the transmitted and received higher layer data packets during the observation time period, while the TWT operation is stopped (step 2150). This step can be similar to step 2105,
e.g., the same observation time period
may be used, and the same traffic statistics may be monitored and recorded.
The device then determines whether a ratio of the higher layer data transceiving time to the observation time period is below a predetermined second threshold (
) (step 2155). The higher layer data transceiving time can be determined as in steps 2110-2120 above,
e.g., as
. In embodiments where the higher layer data transceiving time is determined as
, the ratio of the higher layer data transceiving time to the observation time period is
, which is similar to the minimum duty cycle for the TWT operation (
) determined in
step 2125 above.
The second threshold can be set such that if the ratio is below the second threshold, it indicates that the time consumed by data exchange between the device and its counterpart device (e.g., an AP) is low, which could mean conditions are good to set up TWT operation in order to reduce power consumption without risking unacceptable latency increases. Accordingly, based on the ratio falling below the second threshold at step 2155, the device starts (or resumes) TWT operation using the new TWT service period and the new TWT interval for the TWT operation (step 2160). The new TWT service period and the new TWT interval for the TWT operation here can be determined similarly to steps 2125 and 2130 above, based on the measurements taken during the observation time period in step 2150. The method can then proceed to step 2105 to monitor traffic statistics during TWT operation and update of the TWT service period and TWT interval.
Returning to step 2155, if the ratio is above the second threshold, it indicates that conditions remain poor for TWT operation, so the device continues monitoring traffic statistics and checking whether TWT operation should be started (or resumed) at step 2150.
The above flowcharts illustrate example methods that can be implemented in accordance with the principles of the present disclosure and various changes could be made to the method illustrated in the flowchart. For example, while shown as a series of steps, various steps could overlap, occur in parallel, occur in a different order, or occur multiple times. In another example, steps may be omitted or replaced by other steps.
Although the present disclosure has been described with an exemplary embodiment, 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.