Determining inactivity timeout using distributed coordination function

Methods, systems, and devices are described for power management in wireless devices. Power saving for a device of a wireless network may be improved by appropriately setting an inactivity timeout (ITO), and thus the amount of time, after a last transmission or reception of data traffic, that the device remains in an awake mode listening for more data traffic before the device enters a sleep mode. Distributed coordinated function (DCF) information may be used for determining the ITO. For example, the DCF information may be used to determine a channel congestion metric, which may be used to set the ITO for the device.

BACKGROUND

Field of the Disclosure

The following relates generally to wireless communication, and more particularly to setting an inactivity timeout using distributed coordination function information.

Description of Related Art

Wireless communications systems are widely deployed to provide various types of communication content such as voice, video, packet data, messaging, broadcast, and so on. These systems may be multiple-access systems capable of supporting communication with multiple users by sharing the available system resources (e.g., time, frequency, and power). A wireless network, for example a wireless local area network (WLAN), such as a Wi-Fi network (IEEE 802.11), may include an access point (AP) that may communicate with one or more stations (STAs) or mobile devices. The AP may be coupled to a network, such as the Internet, and enable a mobile device to communicate via the network (and/or communicate with other devices coupled to the access point).

WLAN systems may use channel sense multiple access (CSMA), in which devices or STAs sense channel conditions prior to accessing the channel. In WLAN systems, APs may be communicating with several or many other STAs concurrently, and therefore data transfers may be interrupted by periods where the AP is serving other STAs. A baseline power-saving algorithm may keep the STA awake for a fixed period of time after the last received/transmitted frame. However, a long fixed period will sacrifice power savings for performance, while a short fixed period will save power but sacrifice performance.

One approach is to use a packet arrival rate to adjust the period of time that the device remains in the awake mode after the last received/transmitted frame. The period of time may be referred to as inactivity time interval or inactivity timeout (ITO). The packet arrival rate, determined when the device is in the awake mode, may be used to guide the determination of the ITO. However, this approach suffers from a drawback that the packet arrival rate determination may be in error, for example, due to channel congestion.

A procedure known as the distributed coordination function (DCF) may allow multiple stations (STAs) to compete for access to the same channel while avoiding traffic collisions. The DCF may use CSMA to determine the availability of the medium to be accessed by STAs in a basic service set (BSS). Before any STA may transmit, the STA may wait one inter-frame spacing (IFS) plus a random backoff interval. If the medium is determine to be idle (i.e., available) during the backoff interval (timed with a backoff timer), the STA may access the medium and start transmission. If the medium is determined to be busy, the STA may wait for the medium to become idle, during which the STA may suspend or pause the backoff timer. The backoff interval may be generated as a random number within a range known as a contention window (CW). For each failed transmission attempt, the CW for the STA may be incremented to a next longer CW step until a maximum CW value is reached. When a transmission attempt is successful, the CW may be reset to a default value (e.g., a minimum CW value) for the next transmission.

SUMMARY

The described features generally relate to one or more improved systems, methods, and/or apparatuses for power management in wireless devices. More specifically, the described features generally relate to improving power saving for a device of a wireless network by adjusting the ITO, and thus the amount of time, after a last transmission or reception of data traffic, that the device remains in an awake mode listening for more data traffic before the device enters a sleep mode. The described features may be employed to improve power savings by taking into account distributed coordinated function (DCF) information for determining the ITO. The DCF information may be used to determine a channel congestion metric, which may be used to set the ITO for the device.

A method for wireless communication is described. The method may involve tracking distributed coordination function (DCF) operations of a wireless station to obtain historical DCF information. A channel congestion metric may be determined based at least in part on the historical DCF information. An inactivity timeout (ITO) for the wireless station may be set based at least in part on the channel congestion metric.

The ITO may be inversely proportional to a degree of channel congestion indicated by the channel congestion metric.

The historical DCF information may include historical contention window (CW) data for the wireless station.

Tracking the DCF operations may involve tracking a random backoff interval value for each of a plurality of prior CWs of the wireless station. Tracking the DCF operations also may involve determining a number of times a backoff timer is paused during transmission attempts for each of the plurality of prior CWs of the wireless station.

The method also may involve determining a channel congestion sample for each of the plurality of prior CWs based at least in part on the random backoff interval value and the determined number of times the backoff timer is paused. In such case, the channel congestion metric for the wireless station may be based at least in part on a plurality of the determined channel congestion samples.

The method further may involve associating each channel congestion sample with a timestamp of the corresponding CW. In such case, the ITO for the wireless station may be based at least in part on the plurality of the determined channel congestion samples, the corresponding timestamps of the congestion samples and a current timestamp.

The method may involve identifying a first contention window (CW) value associated with a previous successful transmission by the wireless station. A second CW value for an initial attempt of a subsequent transmission by the wireless station may be set based at least in part on the first CW value.

Setting the second CW value may involve decrementing to a next CW value relative to the first CW value.

An apparatus for wireless communication also is described. The apparatus may include a processor to track distributed coordination function (DCF) operations of a wireless station to obtain historical DCF information. The apparatus also may include a calculator to determine a channel congestion metric based at least in part on the historical DCF information. The apparatus further may include an inactivity timeout (ITO) manager to set an ITO for the wireless station based at least in part on the channel congestion metric. The apparatus may include these and other features to carry out the functions described above and further herein.

Another apparatus for wireless communication is described. The apparatus may include: means for tracking distributed coordination function (DCF) operations of a wireless station to obtain historical DCF information; means for determining a channel congestion metric based at least in part on the historical DCF information; and, means for setting an inactivity timeout (ITO) for the wireless station based at least in part on the channel congestion metric. The apparatus may include these and other features to carry out the functions described above and further herein.

DETAILED DESCRIPTION

The described features generally relate to improved systems, methods, or apparatuses for adaptively setting an inactivity timeout (ITO) for a device, such as a station (STA). Such an approach may avoid drawbacks associated with using a fixed (e.g., preset) ITO. A major contributor to a WLAN STA's power consumption may be time spent in idle-listen mode, which may be determined by a fixed ITO used in all channel conditions. However, when the medium is busy, using a fixed ITO may lead to either unnecessary power consumption by the STA if set too long or decreased performance for the STA if set too short.

As described herein, the ITO may be set adaptively using DCF information. DCF operations may be tracked to generate historical DCF information. The historical DCF information may be used to obtain, derive, calculate, generate or otherwise determine a channel congestion metric. The ITO may be set using the channel congestion metric. For example, the ITO may be set adaptively based at least in part on a number of previous retransmission attempts obtained from DCF historical data and a time value (e.g., a number of time slots) during which a backoff timer was paused or a pause count of the backoff timer.

Adaptively setting the ITO as described herein may conserve power by having the STA enter the sleep mode sooner when the medium is busier, while promoting performance (e.g., throughput/medium utilization) by having the STA stay awake longer when the medium is less busy.

Referring first toFIG. 1, a block diagram illustrates an example of a WLAN100such as, e.g., a network implementing at least one of the IEEE 802.11 family of standards. The WLAN100may include an access point (AP)105and one or more wireless devices or stations (STAs)115, such as mobile stations, personal digital assistants (PDAs), other handheld devices, netbooks, notebook computers, tablet computers, laptops, display devices (e.g., TVs, computer monitors, etc.), printers, etc. While one AP105is illustrated, the WLAN100may have multiple APs105. Each of the wireless STAs115, which may also be referred to as mobile stations (MSs), mobile devices, access terminals (ATs), user equipment (UE), subscriber stations (SSs), or subscriber units, may associate and communicate with the AP105via a communication link120. The AP105has a geographic coverage area110such that wireless STAs115within that area may typically communicate with the AP105. The wireless STAs115may be dispersed throughout the geographic coverage area110. Each wireless STA115may be stationary or mobile.

Although not shown inFIG. 1, a wireless STA115may be covered by more than one AP105and therefore may associate with one or more APs105at different times. A single AP105and an associated set of STAs may be referred to as a basic service set (BSS). An extended service set (ESS) is a set of connected BSSs. A distribution system (DS) (not shown) may be used to connect APs105in an extended service set. The geographic coverage area110for the AP105may be divided into sectors making up a portion of the coverage area (not shown). The WLAN100may include APs105of different types (e.g., metropolitan area, home network, etc.), with varying sizes of coverage areas and overlapping coverage areas for different technologies. Although not shown, other wireless devices may communicate with the AP105.

While the wireless STAs115may communicate with each other through the AP105using communication links120, each wireless STA115may also communicate directly with one or more other wireless STAs115via a direct wireless link125. Two or more wireless STAs115may communicate via the direct wireless link125when both wireless STAs115are in the AP geographic coverage area110or when one or neither wireless STA115is within the AP geographic coverage area110(not shown). Examples of the direct wireless link125may include Wi-Fi Direct connections, connections established by using a Wi-Fi Tunneled Direct Link Setup (TDLS) link, and other P2P group connections. The wireless STAs115in these examples may communicate according to the WLAN radio and baseband protocol including physical and MAC layers from IEEE 802.11, and its various versions including, but not limited to, 802.11b, 802.11g, 802.11a, 802.11n, 802.11ac, 802.11 ad, 802.11 ah, etc. In other implementations, other peer-to-peer connections and/or ad hoc networks may be implemented within WLAN100.

As discussed above, each of the STAs115, such as STA115-amay employ an ITO for power savings. Thus, the STA115-amay include an ITO manager130to set the ITO. As described herein, the ITO manager130may set the ITO using DCF information. For example, the DCF information may be used to calculate, generate or otherwise determine a channel congestion metric, which may be used by the ITO manager130to set the ITO for the STA115-a.

FIG. 2shows a timing diagram200illustrating an implementation of power saving for a device, such as the STA115-adescribed with reference toFIG. 1, using an ITO. The device may initially be in an awake mode for an awake interval205-ain which the device transmits and/or receives communications (e.g., packets of information). An inactivity time interval or ITO begins after a last transmission or reception (tx/rx). In this example, the ITO may be for a relatively long period of time (e.g., as a percentage of the beacon interval, etc.). The ITO is reset upon reception (rx)210-aof any further communications within the ITO. Once the ITO has elapsed, the device enters a sleep mode for a sleep interval215-a, which may last until the device has data to transmit or receives a beacon from the AP, such as the AP105described with reference toFIG. 1, indicating that the AP has data for the device. The beacon interval is the time (e.g., ms) between beacons which contain information about the network and synchronize the wireless network.

After receiving the beacon, the device may exit the sleep mode and enter the awake mode for another awake interval205-b, for example, when the device has information to transmit or the AP has information to transmit to the device. Again, the ITO begins after a last transmission or reception (tx/rx). Again, the ITO is reset upon reception(s)210-bof any further communications. Once the ITO has elapsed, the device enters a sleep mode for another sleep interval215-buntil receiving another beacon from the AP, after which the device may enter the awake mode for another awake interval205-c(assuming further communications are to occur for the device, which may be indicated with a traffic indication map (TIM) bit in the beacon).

As illustrated in the timing diagram200, a longer time period for the ITO may improve system performance (e.g., throughput) by increasing the chances that the device will still be in the awake mode when further communications (e.g.,210-a,210-b) occur. On the other hand, a longer time period for the ITO may forfeit power saving opportunities by delaying entry of the device into the sleep mode. As described herein, the ITO for the device may be determined (e.g., set) in a manner that takes into account traffic conditions, for example, using DCF information of the device.

FIG. 3shows a block diagram300illustrating an example of a process flow for setting an ITO for a STA115-b, in accordance with various aspects of the present disclosure. The STA115-bmay be an example of one of the STAs115described with reference toFIG. 1, such as the STA115-aincluding the ITO manager130. In this example, the STA115-bis shown communicating with an AP105-a, which may be an example of the AP105described with reference toFIG. 1. It should be understood, however, that the STA115-bmay communicate with multiple devices (e.g., STAs, APs, etc.) and that the single AP105is shown for the sake of simplicity.

At305, the STA115-bmay make a plurality of transmission attempts, for example, to send information (e.g., data) to the AP105-a. Some of the transmission attempts may be unsuccessful and some may be successful.

At310, the STA115-bmay track DCF operations regarding the plurality of transmission attempts to obtain historical DCF information. While this aspect of the process is illustrated as occurring later in time, it should be understood that the tracking may be concurrent (or nearly concurrent) with the transmission attempts at305.

The historical DCF information may include historical contention window (CW) data for the STA115-b. As such, tracking the DCF operations may involve tracking a random backoff interval value for each of a plurality of prior CWs employed by the STA115-b. Tracking the DCF operations also may involve determining a number of times a backoff timer is paused during transmission attempts for each of the plurality of prior CWs.

The random backoff interval value may be defined according to the equations:
RandBO(k)=[1 . . . CW(k)]
CW(k)=2k−1

where RandBO(k) is the random backoff interval value (e.g., random number) generated for the kth contention window, CW(k).

Table I shows an example of historical DCF information including random backoff interval values (RandBO) and total pause counts for each CW. The values of the CWs and the number of CWs may be implementation specific, or may be set in accordance with an industry standard. The random backoff interval values (RandBO) are determined randomly in accordance with the value of the respective CW, and will vary in actual practice of DCF operations. The pause count also will vary in actual practice of DCF operations in accordance with how busy the medium is during transmission attempts by the STA115-b.

At315, the STA115-bmay determine a channel congestion metric using the historical DCF information. The STA115-bmay, for example, determine a channel congestion sample for each of the plurality of prior CWs based at least in part on the random backoff interval value and the determined number of times the backoff timer is paused. In such case, the channel congestion metric may be determined using a plurality of the determined channel congestion samples. A desired number of most recent channel congestion samples may be used for the plurality. The desired number may be predetermined or may be adaptive, for example, to take into account samples that are sufficiently relevant (e.g., having occurred within a certain time frame of determining the channel congestion metric or determining the ITO, as discussed below). Further, the STA115-bmay associate each channel congestion sample with a timestamp of the corresponding CW.

Each channel congestion sample may be determined according to the equation:
Sample(k)=Σi=0nlog2(RandBO(i))*Coeff(k)+flimit(Pt(i))

where Sample(k) is the channel congestion sample for the kth contention window, Coeff(k) is a coefficient associated with the kth contention window, and Pt(i) is the total pause time. The total pause time may be determined according to the equation:
Pt(k)=Σi=0nslot_time*slot(i)

where Pt(k) is the total pause time for the contention window k, slot_time is the amount of time of each slot, and slot(i) is the number of paused slots.

At320, the STA115-bmay determine an ITO for the STA115-b. The ITO may be determined using the channel congestion metric. As noted above, the ITO may be determined using a plurality of the determined channel congestion samples. In such case, the corresponding timestamps of the congestion samples and a current timestamp may also be used by the STA115-bin determining the ITO. The new ITO may be calculated according to the equation:
ITO=Σi=0nSample(i)/(TScurrent−TSi)

where n is the number of sample metrics, TSi is the timestamp associated with the individual samples Sample(i), and TScurrent is the timestamp when the ITO is generated.

Thus, as described above and further herein, the ITO may be set adaptively using historical DCF information. As illustrated inFIG. 3, the process of setting the ITO may be performed again using DCF information from transmission attempts325. Repetition of the process may after a certain number of transmission attempts are made, periodically, or as often as appropriate or desired for a particular implementation.

FIG. 4shows a diagram illustrating an example of DCF contention windows (CWs), in accordance with various aspects of the present disclosure. As noted above, the values of the CWs and the number of CWs may be implementation specific, or may be set in accordance with an industry standard. Further, when a transmission attempt (e.g., for sending data) fails, the CW employed for a next transmission attempt (e.g., for sending the data) is stepped to the next higher CW. As such, in accordance with the CWs shown, a first transmission attempt may be made using the CW with a value of 15. If the first transmission attempt fails, a second transmission attempt may be made using the CW with a value of 31. If the second transmission attempt fails, a third transmission attempt may be made using the CW with a value of 63, and so on, until a CW with a highest or maximum value (e.g., 1023 as shown) is employed. Conventionally, once a transmission attempt is successful, the CW for a next transmission attempt (e.g., for sending additional data) is determined by resetting the CW to the CW having the lowest value (e.g., 15 as shown).

In addition to using DCF information to determine/set the ITO for a wireless device, an approach for modifying the CW resetting procedure is contemplated. Instead of resetting the CW to the CW having the lowest value, the CW may be reset to one of the CW values in accordance with the CW value used for a previous successful transmission. For example, the CW may be reset in accordance with the CW used for the most recent successful transmission. This may involve, for example, decrementing to a next CW value relative to the CW used for the most recent successful transmission. For example, with reference toFIG. 4, if a transmission attempt employing the CW with a value of 255 is successful, the CW may be reset to the CW with a value of 127 for the next transmission attempt.

Alternatively, the CW may be reset in accordance with the CWs used for a plurality of previous successful transmissions (e.g., a history of CWs used for successful transmissions). A suitable number of previous successful transmissions may be taken into account for resetting the CW for the next transmission attempt. The suitable number may be based on a consistency of the CWs employed for successful transmissions. For example, when the CWs employed for successful transmissions varies significantly, just a few previous successful transmissions may be taken into account. On the other hand, when a history of the CWs employed for successful transmissions exhibits a trend, a number of successful transmissions representative of the trend may be considered.

Taking into account a plurality of previous successful transmissions may involve calculating an average of the associated CW values. Resetting the CW for the next transmission attempt in accordance with the four previous successful transmission attempts may be based on the calculated average. For example, with reference toFIG. 4, if four previous successful transmission attempts are considered that have associated CW values of 127, 255, 511 and 1023 (e.g., in no particular order), the average CW value may be 481.5. The CW for the next transmission attempt may be reset to the CW with a value of 255, for example, as the next CW value relative to the calculated average CW value of 481.5.

FIG. 5shows a block diagram500of an example of a STA115-cfor use in wireless communication, in accordance with various aspects of the present disclosure. The STA115-cmay be an example of aspects of one or more of the STAs115described with reference toFIGS. 1 and 3, and may implement various aspects described with reference toFIGS. 2 and 4. The STA115-cmay also be or include a processor (not shown). The STA115-cmay include may include a receiver505, a transmitter510, and/or a communications manager515. Each of these components may be in communication with each other.

The STA115-c, through the receiver505, the transmitter510, and/or the communications manager515, may perform functions described herein. For example, the STA115-ctrack DCF operations or otherwise obtain historical DCF information, determine a channel congestion metric using the historical DCF information, set an ITO using the channel congestion metric, and/or set a CW value for an initial attempt of a subsequent transmission, such as described herein.

The components of the STA115-c(as well as those of other related devices/apparatus described herein) may, individually or collectively, be implemented using ASICs adapted to perform some or all of the applicable functions in hardware. Alternatively, the functions may be performed by other processing units (or cores), on integrated circuits. In other examples, other types of integrated circuits may be used (e.g., Structured/Platform ASICs, FPGAs, and other Semi-Custom ICs), which may be programmed in any manner known in the art. The functions of each component may also be implemented, in whole or in part, with instructions embodied in a memory, formatted to be executed by general or application-specific processors.

The receiver505may receive information such as packets, user data, and/or control information associated with various information channels (e.g., control channels, data channels, etc.). The receiver505also may receive acknowledgements (ACKs) in response to successful transmissions by the STA115-c. Information may be passed on to the communications manager515, and to other components of the STA115-c.

The transmitter510may transmit signals received from other components of the STA115-c. The transmitter510may transmit various communications (e.g., data, etc.) under control by the communications manager515, for example. In some examples, the transmitter510may be collocated with the receiver505in a transceiver. The transmitter510may include a single antenna, or it may include a plurality of antennas. The transmitter510also may share the antenna(s) with the receiver505.

The communications manager515may be used to manage wireless communication for the STA115-c. For example, the communications manager520may be used to manage the transmitter510and/or the receiver505. According to aspects of this disclosure, the communications manager515may manage or otherwise control setting an ITO for the STA115-c. Further, the communications manager515may manage or otherwise control aspects of a DCF procedure, such as resetting a CW after a successful transmission attempt.

FIG. 6shows a block diagram600of another STA115-dfor use in wireless communication, in accordance with various aspects of the present disclosure. The STA115-dmay be an example of aspects of one or more of the STAs115described with reference toFIGS. 1 and 3, may implement various aspects described with reference toFIGS. 2 and 4, and may be an example of the STA115-cdescribed with reference toFIG. 5. The STA115-dmay also be or include a processor (not shown). The STA115-dmay include may include a receiver505-a, a transmitter510-a, and/or a communications manager515-a. Each of these components may be in communication with each other.

The STA115-dmay perform various functions described herein. The receiver505-a, the transmitter510-a, and the communications manager520-amay operate as described above with respect toFIG. 5, for example. The communications manager520-amay include a DCF operations tracker605, a channel congestion metric calculator610and an ITO manager615.

The DCF operations tracker605may track details of DCF operations, such as described herein, using information from the transmitter510-a, the receiver505-aand/or the communications manager515-a. The DCF operations tracker605may process the details in a suitable manner to generate a history (e.g., historical DCF information), and may assemble the history/information is a manner that is accessible/usable for channel congestion metric determination as discussed herein (e.g., in one or more tables of data).

The channel congestion metric calculator610may receive the history/information from the DCF operations tracker605, or may access DCF operations tracker605from storage (e.g., in memory of the STA115-d(not shown)). The channel congestion metric calculator610may perform various manipulations, determinations and/or calculations using the history/information obtained/generated by the DCF operations tracker605to calculate or otherwise determine a channel congestion metric and or samples, such as described herein.

The ITO manager615may manage the ITO for the STA115-d. Such management may include, but is not limited to, setting the ITO using the congestion metric and/or samples determined by the channel congestion metric calculator610.

Further, the communications manager515-amay include various subcomponents for managing otherwise controlling aspects of a DCF procedure, such as resetting a CW after a successful transmission attempt as described herein. For example, the communications manager515-amay include a DCF manager or controller (e.g., controlling the DCF process, selecting/setting the CWs used for transmission attempts, etc.), a CW history generator (e.g., tracking the CWs used for successful transmission attempts), and a CW database (e.g., storing the available/defined CW values, a CW history, etc.). For the sake of simplicity and brevity, such subcomponents are not shown inFIG. 6. Further, such subcomponents may be implemented by adapting conventional DCF hardware components to provide various functionality described herein. For example, the mechanism for resetting the CW may be accomplished by a modification of software controlling existing components and/or a modification of existing hardware used in WLAN media access control (MAC).

Turning toFIG. 7A, a block diagram700-ais shown that illustrates a STA115-efor use in wireless communication, in accordance with various aspects of the present disclosure. The STA115-emay be an example of aspects of one or more of the STAs115described with reference toFIGS. 1 and 3, may implement various aspects described with reference toFIGS. 2 and 4, and may be an example of one or both of the STAs115described with reference toFIGS. 1, 3, 5, and 6. The STA115-emay have various other configurations and may be included or be part of a personal computer (e.g., laptop computer, netbook computer, tablet computer, etc.), a cellular telephone, a PDA, a digital video recorder (DVR), an internet appliance, a gaming console, an e-readers, etc. The STA115-emay have an internal power supply (not shown), such as a small battery, to facilitate mobile operation.

The STA115-emay include a processor705, a memory710, at least one transceiver720and at least one antenna725. Each of these components may be in communication with each other, directly or indirectly, over at least one bus730.

The memory710may include random access memory (RAM) and read-only memory (ROM). The memory710may store computer-readable, computer-executable software (SW) code715containing instructions that, when executed, cause the processor705to perform various functions described herein, for example, for setting an ITO and/or resetting a CW. Alternatively, the software code715may not be directly executable by the processor705but may cause the STA115-eor components thereof (e.g., when compiled and executed) to perform functions described herein.

The processor705may include an intelligent hardware device, e.g., a CPU, a microcontroller, an ASIC, etc. The processor705may process information received through the transceiver(s)720and/or to be sent to the transceiver(s)720for transmission through the antenna(s)725. The processor705may handle, alone or in connection with other components, various aspects for communicating using DCF procedures, for power saving using an ITO, etc.

The transceiver(s)720may communicate bi-directionally with APs, STAs or other devices, such as described above with reference toFIGS. 1, 2 and 3. The transceiver(s)720may be implemented as at least one transmitter module and at least one separate receiver module. The transceiver(s)720may include a modem to modulate the packets and provide the modulated packets to the antenna(s)725for transmission, and to demodulate packets received from the antenna(s)725. While the STA115-emay include a single antenna, there may be aspects in which the STA115-emay include multiple antennas725.

According to the architecture ofFIG. 7, the STA115-efurther may include a communications manager515-b. The communications manager515-bmay manage communications with various APs and/or STAs, for example. The communications manager515-bmay be an example of aspects of the communications managers515and515-adescribed with reference toFIGS. 5 and 6, respectively. The communications manager515-bmay be a component of the STA115-ein communication with some or all of the other components of the STA115-eover the bus730. Alternatively, functionality of the communications manager515-bmay be implemented as a component of the transceiver(s)720, as a computer program product, and/or as at least one controller element of the processor705.

The STA115-ealso may include an ITO manager615-a. The ITO manager615-amay be an example of aspects of the ITO manager615described with reference toFIG. 6. The ITO manager615-amay be a component of the STA115-ein communication with some or all of the other components of the STA115-eover the bus730. Alternatively, functionality of the ITO manager615-amay be implemented as a component of the transceiver(s)720, as a computer program product, and/or as at least one controller element of the processor705.

The components of the STA115-emay implement aspects discussed above with respect toFIGS. 5 and 6, and those aspects may not be repeated here for the sake of brevity. Moreover, the components of the STA115-emay implement aspects discussed below with respect toFIGS. 8, 9 and 10, and those aspects may not be repeated here also for the sake of brevity.

Turning toFIG. 7B, a block diagram700-bis shown that illustrates a STA115-ffor use in wireless communication, in accordance with various aspects of the present disclosure. The STA115-fmay be an example of aspects of one or more of the STAs115described with reference toFIGS. 1, 3, 5, and 6, and 7A, and may implement various aspects described with reference toFIGS. 2 and 4. The STA115-fmay include a processor705-a, a memory710-a, at least one transceiver720-a, and at least one antenna725-a. Each of these components may be in communication, directly or indirectly, with one another (e.g., over a bus730-a). Each of these components may perform the functions described above with reference toFIG. 7A.

In this example, the memory710-amay include software that performs the functionality of a communications manager515-cand an ITO manager615-b. For example, memory710-amay include software that, when compiled and executed, causes the processor705-a(or other components of the STA115-f) to perform the functionality described above and further below. A subset of the functionality of the communications manager515-cand the ITO manager615-bmay be included in memory710-a; alternatively, all such functionality may be implemented as software executed by the processor705-ato cause the STA115-fto perform such functions. Other combinations of hardware/software may be used to perform the functions of the communications manager515-cand the ITO manager615-b.

FIG. 8shows a flow chart illustrating an example of a method800for wireless communication, in accordance with various aspects of the present disclosure. For clarity, the method800is described below with reference to aspects of one or more of the STAs115described with reference toFIGS. 1 and 3, one or both of the STAs115described with reference toFIGS. 5 and 6, or one or both of the STA115described with reference to FIGS.7A and7B. The operations of method800may be implemented by such a STA or components thereof, such as described above. For example, the operations of method800may be performed by the communications manager515described with reference toFIGS. 5 and 6, or a combination of the communications manager515and the ITO manager615described with reference toFIGS. 7A and 7B. The STA may execute a set of codes to control the functional elements thereof to perform the functions described below. Additionally or alternatively, the STA may perform aspects the functions described below using special-purpose hardware.

At block805, a STA may track DCF operations to obtain historical DCF information. For example, the operation(s) at block805may be performed by the DCF operations tracker605of the communications manager515-aas described above with reference toFIG. 6.

At block810, the STA may determine a channel congestion metric using the historical DCF information. For example, the operation(s) at block810may be performed by the channel congestion metric calculator610of the communications manager515-aas described above with reference toFIG. 6.

Then, at block815, the STA may set an ITO using the channel congestion metric. For example, the operation(s) at block815may be performed by the ITO manager615of the communications manager515-aas described above with reference toFIG. 6.

FIG. 9shows a flow chart illustrating another example of a method900for wireless communication, in accordance with various aspects of the present disclosure. For clarity, the method900is described below with reference to aspects of one or more of the STAs115described with reference toFIGS. 1, 3, 5, 6, 7A, 7B. The operations of method900may be implemented by such a STA or components thereof, such as described above. For example, the operations of method900may be performed by the communications manager515described with reference toFIGS. 5-7B. The STA may execute a set of codes to control the functional elements thereof to perform the functions described below. Additionally or alternatively, the STA may perform aspects the functions described below using special-purpose hardware.

At block905, a STA may identify a first contention window (CW) value associated with a previous successful transmission by the wireless station. Such identification may be performed as part of a DCF procedure such as described herein.

Then, at block910, the STA may set a second CW value for an initial attempt of a subsequent transmission by the wireless station based at least in part on the first CW value. Again, such setting (e.g., resetting) of the CW to be employed after a successful transmission attempt may be performed as part of a DCF procedure such as described herein.

FIG. 10shows a flow chart illustrating yet another example of a method1000for wireless communication, in accordance with various aspects of the present disclosure. For clarity, the method1000is described below with reference to aspects of one or more of the STAs115described with reference toFIGS. 1, 3, 5, 6, 7A, 7B. The operations of method1000may be implemented by such a STA or components thereof, such as described above. For example, the operations of method1000may be performed by the communications manager515described with reference toFIGS. 5 and 6, or a combination of the communications manager515and the ITO manager615described with reference toFIGS. 7A and 7B. The STA may execute a set of codes to control the functional elements thereof to perform the functions described below. Additionally or alternatively, the STA may perform aspects the functions described below using special-purpose hardware.

The method1000may provide a modified DCF based procedure in which an ITO is set adaptively and a CW to be employed after a successful transmission attempt is set in accordance with the CW(s) associated with previous successful transmission attempt(s). The method1000may begin at block1005when the STA has a transmission (e.g., of data, etc.) to another device (e.g., a STA, an AP, etc.) or devices.

At block1005, the STA may determine a random back off interval and start an associated timer (e.g., a back off timer) to implement the determined back off interval. The STA may then wait for the determined back off interval to elapse (e.g., the back off timer to expire) or pause at block1010. Although not illustrated as a separate block inFIG. 10, the STA may use CSMA to determine whether the channel is idle during the determined back off interval.

At block1015, the STA may determine if the back off timer is expired. If not, the method1000may proceed to block1020, where the STA may determine if the back off time has been paused. If so, the method1000may proceed to block1025, where the STA may increment a pause count, for example, updating a table of DCF information with pause timer information (e.g., pause count) for a CW currently being employed as part of the DCF procedure. After incrementing/updating at block1025, the method1000may return to block1010. Also, if the back off timer has not been paused, the method1000may return directly to block1010from block1020.

Once the back off timer has expired, the method1000may jump from block1015to block1030. At block1030, the STA may attempt to perform the transmission and wait to receive an acknowledgement (ACK). An ACK timer may be set when the transmission has been sent form the STA. While waiting for the ACK timer to expire, the STA may, at block1035determine if an ACK is received in response to the sent transmission. If the ACK is not received before expiration of the ACK timer, the method may proceed to block1040, where the STA may record DCF information associated with the current CW, for example, by updating a table. The STA may then increase the CW size (e.g., increment to the next available/defined CW) and the method may return to block1005to continue attempting to transmit the data using the increased/incremented CW.

If the STA receives an ACK for the sent transmission prior to expiration of the ACK timer, the method may jump from block1035to block1045. At block1045, the STA may record DCF information for the successful transmission attempt, for example, by updating a table for the CW used for the successful transmission. Then, at block1050, the STA may determine whether more transmissions are to be performed (e.g., there is additional data at the STA to transmit). If so, the method1000may return to block1005to continue the DCF procedure for transmitting the additional data. Although not as a separate block inFIG. 10, the STA may reset the CW for an initial attempt at a subsequent transmission. As described herein, the CW may be reset, for example, in accordance with the current CW that was used for the most recent successful transmission. For example, the CW may be decremented from the current CW to a next CW available or defined.

If no more transmissions are to be performed (e.g., no additional data for transmission is pending at the STA), the method1000may continue from block1050to block1055. At block1055, the STA may calculate or otherwise determine an ITO to employ. As described herein, such calculation/determination may be performed using historical DCF information collected during previous transmission attempts.

Once the ITO is calculated/determined, the method1000may proceed to block1060, where ITO may be set (e.g., applied) and an ITO timer may be started to implement the ITO. The STA may employ the ITO such as described with reference toFIG. 2, for example. The method1000may continue from block1060to block1065, where the STA may determine if the ITO has elapsed (e.g., the ITO timer has expired). If not, the STA may continue to wait in an awake state until the ITO has elapsed.

Once the ITO has elapsed, the method may proceed from block1065to block1070, where the STA may transition to a sleep or low-power mode, for example, to conserve power. As noted above, the STA may remain in the sleep mode until the STA wakes up to receive a beacon from an AP, for example.

The methods800,900and1000may provide for wireless communications at a STA or similar device. It should be noted that these methods are just example implementations and that the operations of thereof may be rearranged or otherwise modified such that other implementations are possible. For example, aspects from two or more of the methods800,900and1000may be combined.