Abstract:
A wireless device and method may be used to receive messages. The wireless device may include, among other things, a receiver, a processor, and a memory. The processor may be configured to determine whether a received message includes a mobile device identification. The processor may perform the determination periodically, for example, during a transmit time interval (TTI). If at least one of the received messages includes a mobile device identification and information indicating that data is to be sent to the wireless device, the wireless device may initiate receiving data in accordance with the information. If a received message does not include any mobile device identification, the wireless device may initiate discontinuous reception. The discontinuous reception may be performed until the next TTI.

Description:
CROSS REFERENCE TO RELATED APPLICATION(S) 
       [0001]    This application is a divisional of U.S. patent application Ser. No. 10/546,952, filed on Aug. 25, 2005, which is a National Stage Entry of PCT Application No. PCT/IB04/00477 filed on Feb. 23, 2004, which claims the benefit of U.S. Provisional Application No. 60/451,032 filed on Feb. 27, 2003 and U.S. Provisional Application No. 60/477,208 filed on Jun. 10, 2003, which are incorporated by reference as if fully set forth. 
     
    
     SUMMARY 
       [0002]    A wireless device may be used to receive messages. The wireless device may include, among other things, a receiver, a processor, and a memory. The processor may be configured to determine whether a received message includes a mobile device identification. The processor may perform the determination periodically, for example, during a transmit time interval (TTI). If at least one of the received messages includes a mobile device identification and information indicating that data is to be sent to the wireless device, the wireless device may initiate receiving data in accordance with the information. If a received message does not include any mobile device identification, the wireless device may initiate discontinuous reception. The discontinuous reception may be performed until the next TTI. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0003]      FIG. 1   a  illustrates an infrastructure BSS WLAN. 
           [0004]      FIG. 1   b  illustrates an independent BSS or IBSS WLAN. 
           [0005]      FIG. 2  illustrates a simplified block diagram of each STA within a particular IBSS according to an embodiment of the present invention. 
           [0006]      FIG. 3  illustrates power management operation in IBSS according to an embodiment of the present invention. 
           [0007]      FIG. 4  illustrates an empty Destination List at the start of a Data_Alert window. 
           [0008]      FIG. 5  illustrates the Destination List of  FIG. 4  after the Source STA has sent one Data_Alert frame to STA, and overheard a successful booking conversation between STA 2  and STA 5 . 
           [0009]      FIG. 6  illustrates the Destination List of  FIG. 5  after the Source STA has sent a Data_Alert frame to STA 3 . 
           [0010]      FIG. 7  illustrates the Destination List of  FIG. 6  after the Source STA has sent STA 2  a data frame with “More Data” indicator set to 1. 
           [0011]      FIG. 8  illustrates the Destination List of  FIG. 7  after the Source STA has overheard a data frame sent to/from STA 4 . 
           [0012]      FIG. 9  illustrates an empty Source List at the start of a Data_Alert window. 
           [0013]      FIG. 10  illustrates the Source List of  FIG. 9  after the Source STA receives a Data_Alert message from STA 10  and STA 14 . 
           [0014]      FIG. 11  illustrates the Source List of  FIG. 10  after the Source STA receives a data frame from STA. 11  and STA 13 , each with “More Data” indicator set to 1. 
           [0015]      FIG. 12  illustrates the Source List of  FIG. 11  after the Source STA receives a data frame from STA 10  with “more Data” indicator set to 0. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0016]    The present invention relates to power management in an Independent Basic Service Set Wireless Local Area Network (WLAN). More particularly, the present invention relates to power management in an Institute of Electrical and Electronics Engineers (IEEE) 802.11 IBSS WLAN. Most particularly, the present invention relates to providing higher throughput thereby optimizing power use in an IBSS WLAN for a given Ad-hoc Traffic Indication Message (ATIM) window size. 
         [0017]    The wireless local area network (WLAN) is becoming the dominant network technology. This growth in popularity is due to the explosive growth in demand for portable wireless devices and communications networks to service these devices. 
         [0018]    The WLAN supports two types of networks: the Infrastructure BSS and Independent BSS (IBSS). The basic service set (BSS) is the basic building block of a WLAN. Each BSS consists of at least two stations (STAs). 
         [0019]    Referring to  FIG. 1   a , an Infrastructure BSS is illustrated in which STAs  100  communicate via a central access point (AP)  130  that receives traffic  20  from the source STA  100  and relays it  120  to the destination STA  100 . Referring to  FIG. 1   b , an Independent BSS or IBSS is illustrated (also known as an Ad-hoc network) in which each STA  100  communicates  110  with other STAs  100  directly, without the assistance of an AP. That is, each STA  100  in an Ad-hoc network can communicate with another STA  100  if they are within radio range of one another since all traffic is peer-to-peer in an IBSS. 
         [0020]    Many applications of a WLAN are for mobile devices which are battery-powered. Therefore power consumption of a WLAN card is a critical factor in overall IBSS WLAN power management. For example, an IEEE 802.11 standard WLAN utilizes carrier sense multiple access with collision avoidance (CSMA/CA) as the access method, requiring stations to continuously monitor the medium during idle time. As a result, the power consumed in the idle mode is not much less than the power consumed in the transmit or receive mode. 
         [0021]    Power saving in a WLAN is achieved by allowing STAs, whenever appropriate, to enter a lower power consumption mode, i.e., sleep mode, during which the WLAN card does not monitor the medium. Note that entering sleeping mode is different from turning the WLAN card off, as it will take much longer to turn on the WLAN card from the off state than to awaken a WLAN card from sleep mode. 
         [0022]    With regard to power consumption, a typical WLAN card consumes 1.5 w in transmit mode, 1.25 w in receive mode, about 1.12 w in idle mode, and just 0.045 w in sleep mode. Sleep mode provides substantial power savings. However, although power is saved in sleep mode, the STAs in sleeping mode are totally isolated from the rest of the network. In sleep mode STAs can neither transmit nor receive any packets. This raises a problem: when a STA has packets to transmit and the destination STA is in sleep mode, namely, “How to wakeup the destination STA so that it can receive the packets?” That is, the challenge is to have the destination station wake up at the right time when the source station decides to transmit packets. 
         [0023]    To solve this problem, an IBSS WLAN uses a Data_Alert message and a Data_Window to perform power management for the IBSS.  FIG. 3  illustrates the operation of an IBSS WLAN. At a predetermined interval, known as Target Beacon Transmission Time (TBTT)  330 , all STAs of the IBSS wake up and compete to send their Beacon  310  out because Beacon generation in an IBSS WLAN is distributed. Each STA in the IBSS has a Beacon  310  ready to transmit at the TBTT  330  and competes with all other STAs in the IBSS to access the medium using a random delay. The STA that wins the contention cancels all the other pending Beacon transmissions. Therefore, except for the case of Beacon failure, one Beacon  310  is transmitted per Beacon Interval  300 . 
         [0024]    A window of a predetermined length and that occurs right after the Beacon is reserved as a Data_Alert window  340 , in which only Data_Alert frames  350  and acknowledgements  360  can be transmitted. Data_Alert frames  350  are traffic announcements, used by source STAs to inform destination STAs that there are data frames buffered at the source waiting to be transmitted to the destination. The Data_Alert frames  350  (and their acknowledgements  380 ) resolve contention by following the same distributed coordination function (DCF) rules as normal data frames. Data_Alert frames  350  that cannot be transmitted before the Data_Alert window  340  ends are transmitted during the next Beacon Interval which follows the next TBTT  330 . 
         [0025]    After the Data_Alert window  340  is over, if a STA doesn&#39;t successfully send or receive any Data_Alert frames  350 ,  375 , it can assume that there will be no traffic for it during the current Beacon Interval  340  and, thus, it can go back to sleep (low power mode) until the next TBTT  330 . Otherwise, a STA can start transmission of data frames  365  and receipt of acknowledgements  370  or stay in the receiving mode throughout the Beacon Interval  340  to receive a data frame  385  and transmit an acknowledgement  390 . Note that only the data that is announced during the Data_Alert window  340  can be transmitted after the Data_Alert window  340 . Current approaches to power management require the Data_Alert window  340  size to be a fixed size throughout the lifespan of an IBSS. 
         [0026]    The power management scheme of prior art IBSS WLANs can be summarized as follows. A STA periodically wakes up for a small period of time during which everyone else is also known to be awake. Within this period, STAs try to “book” their destination STAs for the packets they have buffered. At the end of this period, a STA by default goes back to sleep unless it has booked any destination STA or has been booked as a destination STA during the period. 
         [0027]    This prior art power management scheme has the following two drawbacks: 
         [0028]    1) Only the STAs that have explicitly booked their destination STAs can transmit data frames during the remainder  345  of the Beacon Interval  300 ; and 
         [0029]    2) A STA must stay awake for the entire Beacon Interval as long as either it has booked any destination STA or it has been booked as a destination STA. 
         [0030]    Accordingly, there is a need to: 
         [0031]    1) Allow overheard information (knowledge) overheard by a STA to be used, and 
         [0032]    2) Allow STAs to go back to sleep as long as they finish the announced traffic.
       Since STAs monitor the medium constantly when they are awake, STAs overhear conversations in which source STAs “book” destination STAs. This overheard information can be used as a basis on which a STA stays awake to transmit buffered data frames to a destination STA some other STA has booked since in the prior art STAs that have been booked remain awake for the entire Beacon Interval  300 . However, to minimize power use a STA should be able to go to sleep when all announced traffic has been either received or sent by the STA.       
 
         [0034]    Thus, the essence of IBSS WLAN power management in the system and method of the present invention concerns “knowledge”—knowledge about whether the destination STA will be awake. The key used by the system and method of the present invention to optimize 1BSS WLAN power management is the maximum use of this knowledge. That is, in the system and method of the present invention, STAs utilize this knowledge regardless of how the knowledge is obtained (i.e., explicit or implicit). Therefore, in a preferred embodiment, if a STA is confident that its destination STA is awake, it transfers data frames to-the destination STA even though it did not explicitly book the destination STA. 
         [0035]    According to the prior art power management scheme for an IBSS WLAN, each booked STA knows exactly which STAs are going to send packets to it during a Beacon Interval  300 . After all the STAs from which STA B is expecting data frames have finished sending their data frames to STA B, it is a waste of power to have STA B stay awake any further in the Beacon Interval  300 . 
         [0036]    The system and method of the present invention mitigates the two drawbacks of prior art IBSS WLAN power management schemes stated above by: 
         [0037]    1) allowing STAs to use overheard information (knowledge); and 
         [0038]    2) allowing STAs to go back to sleep (low power mode) as long as they finish their announced traffic. 
         [0039]    In the prior art IEEE 802.11 standard, Data_Alert window  340  is an Ad-hoc traffic indication message (ATIM) window and Data_Alert frames  350  are ATIM frames. Further, a “More Data” bit in the frame control field of the MAC header is only used in the Infrastructure BSS. To address the problem of a STA going to sleep after all announced traffic, a preferred embodiment of the system and method of the present invention uses the “More Data” bit in 1BSS for power management purposes. 
         [0040]    Accordingly, the apparatus and method of the present invention provides a “More Data” bit that allows STAs of an 1BSS WLAN to take advantage of information overheard by a STA concerning STAs that have been “booked” as destination STAs. A value of 1 for the “More Data” bit indicates there is at least one more frame at the source STA for the same destination STA whereas a value of 0 indicates that there are no more frames for this destination STA from this source STA. Thus, if at least one data frame from a non-booking STA gets through, the destination STA stays awake if the More Data bit is set to 1. 
         [0041]    The foregoing and other features and advantages of the present invention will be apparent from the following, more detailed description of preferred embodiments as illustrated in the accompanying drawings. 
         [0042]    In the following description, by way of example and not limitation, specific details are set forth such as the particular architecture, power management techniques, etc., in order to provide a thorough understanding of the present invention. However, to one skilled in the art it will apparent that the present invention may be practiced in other embodiments that depart from the specific details set forth. 
         [0043]    In the prior art 802.11 standard, defined in International Standard ISO/IED 8802-11, “Information Technology—Telecommunications and information exchange area networks”, 1999 Edition, which is hereby incorporated by reference in its entirety, the “More Data” bit in the frame control field of the MAC header is only used in the Infrastructure BSS. In a preferred embodiment, the system and method of the present invention uses the “More Data” bit in IBSS for power management. 
         [0044]    In a preferred embodiment, the present invention provides a power save mode in which the “More Data” bit is valid in directed data or management type frames transmitted by STAs of an IBSS WLAN. A value of 1 indicates that at least one additional buffered data or management frame is present at the source STA for the same destination STA. A value of 0 indicates that no more data or management frame is present at the source STA for the same destination STA. 
         [0045]      FIG. 1   b  illustrates a representative network whereto embodiments of the present invention are to be applied. As illustrated in  FIG. 1 , a plurality of STAs  100  communicates through a wireless link with each other via a plurality of wireless channels  110  such that all traffic is peer-to-peer. A key principle of the present invention is to provide a mechanism to optimize power use by each wireless STA  100  such that within each Beacon Interval  300  the maximum number of data frames  365  are transmitted between the STAs  100  while at the same time a STA  100  either stays awake for the entire Beacon Interval or, alternatively, only if it has frames to transmit and/or receive and goes into a sleep or low power mode otherwise to conserve power. It should be noted that if the remaining time  350  in a Beacon Interval  300  is small, a STA  100  may not enter sleep mode since the power consumed to awake at the next TBTT  330  may exceed the power saved by going into sleep mode for so short a time. Further, it should be noted that the IBSS network shown in  FIG. 1   b  is small for purposes of illustration. In practice most networks include a much larger number of mobile STAs  100 . 
         [0046]    Referring to  FIGS. 1   b  and  2 , each STA  100  of an IBSS within the WLAN of  FIG. 1   b  may include a system with an architecture that is illustrated in the block diagram of  FIG. 2 . Each STA  100  may include a receiver  200 , a demodulator  210 , a memory  220 , a power management circuit  230 , a control processor  240 , a timer  250 , a modulator,  260 , and a transmitter  270 . The exemplary system  280  of  FIG. 2  is for descriptive purposes only. Although the description may refer to terms commonly used in describing particular mobile STAs, the description and concepts equally apply to other processing systems, including systems having architectures dissimilar to that shown in  FIG. 2 . 
         [0047]    In operation, the receiver  200  and the transmitter  270  are coupled to an antenna (not shown) to convert received signals and desired transmit data via the demodulator  210  and the modulator  260 , respectively. The power management circuit  230  operates under the control of the processor  240  to determine whether the STA  100  should remain awake throughout the remainder  345  of a given Beacon Interval  300  or go to sleep (low power mode) by determining if there are data frames to be sent/received (1) explicitly “booked”, (2) overheard and implicitly booked, and (3) as indicated by a “More Data” bit in a received message. Further, once the STA has made a decision to go to sleep (low power mode) if the remaining time  340  for the given Beacon Interval  300  must be greater that a predetermined threshold or the STA remains awake for the duration of the Beacon Interval  300 . The computed remaining time in the Beacon Interval  300  is determined by subtracting the current time from the time of the next TBTT, the latter value being stored in the memory  230 . The timer  250  is used to wake up a sleeping STA at predetermined TBTTs  330  and to schedule the control processor  240  to send a Beacon since at the TBTT all STAs compete to send their Beacons. 
         [0048]    In a preferred embodiment, each STA  100  keeps a list of source STA identifiers from which it expects to receive packets during a given Beacon Interval  300 . At the end of the Data_Alert window  340 , the list consists of identifiers of STAs that have explicitly booked this STA during the Data_Alert window  340 . After the Data_Alert window  340 , the STA  100  adds to the list, if it is not already in the list, a STA from which it receives a data or management frame with the “More Data” bit set to 1. On the other hand, the STA  100  deletes from the list, if it is already in the list, a STA from which it receives a data or management frame with the “More Data” bit set to 0. When the list is empty, the STA  100  assumes no obligation to other STAs to stay awake. If the STA  100  itself does not have any packets to send to other STAs, it can then go to sleep and wake up at the next TBTT  330 , provided the remaining time  345  of the Beacon Interval  300  is greater than a predetermined threshold since the extra power consumption associated with the mode switching may not save power if the sleep is too short. Therefore, a STA eligible to go to sleep does so only if the expected sleeping time is greater than the predetermined threshold. 
         [0049]    Since a wireless medium is a broadcast medium, every STA  100  can overhear the traffic over the medium within a certain range. Therefore, it is possible that STA A 1  overhears that STA A 2  booked STA A 3  during a Data_Alert window  340 . Such information is used in a preferred embodiment to improve the performance of the overall IBSS. Depending on the STAs&#39; behavior after the Data_Alert window  340 , either of the two following embodiments of the present invention utilizes this overheard information to improve power management and overall IBSS performance. 
         [0050]    1) STAs that stay awake after the Data_Alert window  340 , stay awake throughout the entire Beacon Interval  300 , as defined in the current standard. In a preferred embodiment, as long as STA A 1  overhears that STA A 2  booked STA A 3  in the ATIM window, STA A 1  knows that both STA A 2  and STA A 3  will stay awake for the entire Beacon Interval  300 . Therefore, STA A 1  can, after the Data_Alert window  340  during the remainder of the Beacon Interval  345 , send frames to either STA A 2  or STA A 3  without explicitly booking either of them in the Data_Alert window  340  and assured that the destination STA is available just as if it had been explicitly booked. 
         [0051]    Therefore, whenever a STA overhears a successful Data_Alert conversation (a Data_Alert frame  350  followed by the corresponding acknowledgement  360 ), the STA should cancel, if any, its pending Data_Alert frames  350  directed to either party of the overheard Data_Alert conversation. Thus, the result is less Data_Alert frame  350  traffic, which conserves power. 
         [0052]    If a STA overhears just the Data_Alert acknowledgement  380 , the STA should cancel, if any, its pending Data_Alert frame  350  directed to the sender of the Data_Alert acknowledgement  380 . 
         [0053]    If a STA  100  just overhears a Data_Alert frame  350 , the STA  100  should make no assumption about the availability of either the overheard source or its intended destination being awake during the remainder of the Beacon Interval  345 . 
         [0054]    In the ideal case, each destination STA  100  should be booked just once per Beacon Interval  300  regardless of the number of source STAs. Doing so will reduce the Data_Alert  350  traffic within the Data_Alert window  340 , thus reducing the Data_Alert window  340  size needed. Since transmitting Data_Alert frames  350  also consumes power, reducing Data_Alert frame  350  traffic means less overhead power consumption. One the other hand, a smaller Data_Alert window  340  leaves more time for data transmission, and thus may improve throughput. 
         [0055]    2) STAs, that stay awake after the ATIM window, can go back to sleep upon finishing all the announced traffic. In an alternative preferred embodiment, when STA A 1  overhears that STA A 2  booked STA A 3 , STA A 1  knows that both STA A 2  and STA A 3  will stay awake after the Data_Alert window  340 , but STA A 1  does not know how long STA A 2  and STA A 3  will stay awake. Without explicitly booking STA A 2  or STA A 3  itself, STA A 1  cannot guarantee that STA A 2  or STA A 3  are awake when it sends frames to them. 
         [0056]    Despite the uncertainty, the overheard information in this embodiment still has value. Although STA A 1  would still like to book all the destination STAs it has traffic to, it gives priority to the destination STAs that it knows nothing about, i.e., has not overheard a conversation involving them, by booking them first. Should the Data_Alert window  340  not be long enough, STA A 1  leaves out STA A 3 , which someone else already booked, rather than STA A 4 , that no one else ever booked. After all, STA A 1  gets another chance to “book” STA A 3  after the Data_Alert window  340  is over by sending STA A 3  a frame with the “More Data” bit set to 1 early enough before STA A 2  finishes sending all its frames directed to STA A 3 . 
         [0057]    The basic idea of this embodiment is to book as many distinct destination STAs as possible within a limited Data_Alert window  340 . 
         [0058]    After the Data_Alert window  340 , each STA first tries to send, if any, one frame to each of the STAs booked by others but not by itself. With the “More Data” bit set to 1, these frames provide another chance to book the destinations that the STA could not book during the Data_Alert window  340 . The least a STA should worry about is the STAs it already booked during the Data_Alert window  340 , as these STAs have given their commitment and will remain awake to receive frames anyway. From another perspective, holding back traffic to the booked STAs in fact gives a greater window of opportunity for other STAs to “book” after the Data_Alert window  340  by using the “More Data” bit. 
         [0059]    Still, sending frames to an un-booked destination STA is taking a chance. A STA should take a failed (or a certain number of failed transmissions) transmission as an indication that the destination STA is no longer awake and move on to its next destination STA. 
         [0060]    Implementation Using Lists of Source and Destination STAs 
         [0061]    A preferred embodiment of an implementation of the present invention uses two lists: a Source STA list and a Destination STA list. 
         [0062]    1. Destination List of STAs Maintained by a Given STA 
         [0063]    At the beginning of a Data_Alert window  340 , a given STA determines a list of those Destination STAs it is buffering frames to be sent during the current Beacon Interval. Suppose the five STAs shown in  FIG. 4  form the initial Destination List of STAs maintained by a given STA. The given STA would like to book each of the STAs in the Destination List, if possible. Note that, at this moment (at the beginning of the Data_Alert window  340 ), nothing has happened, i.e., every entry corresponding to the STAs in the Destination List is empty, as illustrated in  FIG. 4 . After that, whenever the given STA successfully sends a Data_Alert frame to a STA in the Destination List, it marks the Destination STA in the Destination List as “Booked”. 
         [0064]    Meanwhile, whenever the given STA overhears a Data_Alert conversation between two other STAs, the given STA marks the corresponding STAs in the Destination list as “Booked by others”. Within the Data_Alert window  340 , the given STA always chooses from the Destination list an unmarked Destination STA to send a Data_Alert to, as long as there is such a Destination STA in the Destination list. Only after all the Destination STAs in the Destination list are marked as either “Booked” or “Booked by others”, can the STA choose to send a Data_Alert frame to Destination STAs marked as “Booked by others”. 
         [0065]    Suppose the given STA sends a Data_Alert frame to Destination STA 1  in order to “book” STA, as a Destination STA for at least one frame buffered by the given STA, and overhears a conversation between STA 2  and STA 5 . The resulting Destination list is illustrated in  FIG. 5 . Then given STA sends a Data_Alert frame to STA 3  to “book” STA 3  as a Destination STA and marks STA 3  in the Destination list as “booked”, as illustrated in  FIG. 6 . 
         [0066]    Now, assume that the Data_Alert window  340  ends when the Destination List looks as shown in  FIG. 6 . This Destination List is now used by the given STA to decide which Destination STAs to send data frames to and in what order. The given STA first sends data frames to the Destination STAs in the Destination List marked as “booked by others”. If there is more than one frame buffered for a Destination STA, the “More Data” bit of the data frame is set to 1, see  FIG. 7 . Once the data frame is successfully sent, the given STA changes the entry in the Destination List from “Booked by others” to “Booked” because the Destination STA looked at the “More Data” bit that was set to 1 and stays awake to receive more data frames from the given STA. The given STA continues in this manner for all the “Booked by others” Destination STAs in the Destination List before sending any data frame to the “Booked” STAs in the Destination List. This ordering of sending data frames is intended to provide the given STA with another chance to “book” destination STAs and to improve the probability of success. 
         [0067]    Meanwhile, if the given STA overhears data frames to/from an unmarked STA, i.e., STA 4  in the Destination List, the given STA should mark STA 4  as “Booked by others”, see  FIG. 8 . Otherwise, the given STA should not try to send DATA frame to unmarked STAs in the Destination List because the unmarked STAs most likely are in sleep mode because the unmarked STAs likely did not receive any Data_Alert frames. 
         [0068]    Once all the STAs in its Destination List are “Booked”, the given STA can send data frames in whatever order. 
         [0069]    2. Source List of STAs Maintained by a Given STA 
         [0070]    This Source List contains STAs from which the given STA has received notice, i.e., “the booking order”. In the following example, STA 10 -STA 15  are used to simplify the exposition, however, the two lists are definitely not, mutually exclusive. 
         [0071]    Unlike the Destination List, the Source List is empty to start with at the beginning of a Data_Alert window  340 , see  FIG. 9 , and there is no mark needed for the Source List. Within the Data_Alert window  340 , the given STA adds a Source STA to the Source List a source STA if it receives a Data_Alert frame from the Source STA, see  FIG. 10 . 
         [0072]    After the Data_Alert window  340  ends, the given STA adds to the Source List a Source STA if it receives a data frame with a “More Data” bit set to 1 from the Source STA and the source STA is not already in the Source List, see  FIG. 11 . The given STA deletes from its Source List a Source STA if the given STA receives from the Source STA a data frame with the “More Data” bit set to 0, see  FIG. 12 . 
         [0073]    Once the Source List is empty, the given STA can assume that no other STA is going to send frames to the given STA during the current Beacon Interval  300 . After that, if the given STA has no more data frames to send to any other STAs, the given STA can go back to sleep if the remaining time  350  in the Beacon Interval is greater than a pre-determined threshold. 
         [0074]    Referring now to  FIG. 3 , in general, the ATIM of the IEEE 802.11 IBSS WLAN is a Data_Alert window  340  of a known and fixed length so that during the Data_Alert/ATIM window  340  each STA  100  can alert another STA  100  of the IBSS that it has data for it, by sending that STA a Data_Alert/ATIM frame  350 . The system and method of the present invention applies to IEEE802.11 IBSS WLANs for purposes of power management and increased throughput. 
         [0075]    As is apparent from the foregoing, by taking advantage of overheard information according to the system and method of the present invention, STAs of an IBSS WLAN can achieve near-optimal use of power with accompanying increased throughput for a given fixed size of the Data_Alert window and is applicable to IEEE 802.11 IBSS WLANs. 
         [0076]    While the present invention has been described in connection with what is presently considered to be the best mode for managing power in an IBSS WLAN by using information overheard in conversations between other STAs, namely, this overheard information is used to send data frames from a source STA to destination STAs during the current Beacon Interval without explicitly booking the destination STAs so as to reduce use of bandwidth by not having to send Data_Alerts and their acknowledgements, it is to be understood that the invention is not limited to the disclosed embodiments. On the contrary, it is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.