|Publication number||US8880104 B2|
|Application number||US 11/680,302|
|Publication date||4 Nov 2014|
|Filing date||28 Feb 2007|
|Priority date||3 Mar 2006|
|Also published as||CN102611996A, CN102611996B, CN105007615A, CN105578577A, EP1999888A2, EP1999888B1, EP2346208A1, EP2346208B1, EP2357755A1, EP2357755B1, EP2451115A1, EP2451115B1, EP2509258A1, EP2509258B1, US8611970, US9439146, US20070297438, US20120176949, US20140064173, WO2007103794A2, WO2007103794A3|
|Publication number||11680302, 680302, US 8880104 B2, US 8880104B2, US-B2-8880104, US8880104 B2, US8880104B2|
|Inventors||Arnaud Meylan, Manoj M. Deshpande, Sanjiv Nanda|
|Original Assignee||Qualcomm Incorporated|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (84), Non-Patent Citations (13), Referenced by (4), Classifications (13), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present application claims priority to provisional U.S. Application Ser. No. 60/779,235, entitled “STANDBY TIME IMPROVEMENTS FOR WLAN,” filed Mar. 3, 2006, and provisional U.S. Application Ser. No. 60/779,824, entitled “STANDBY TIME IMPROVEMENTS FOR WLAN,” filed Mar. 7, 2006, both assigned to the assignee hereof and incorporated herein by reference.
The present disclosure relates generally to communication, and more specifically to techniques for improving standby time of a station in a wireless network.
Wireless networks are widely deployed to provide various communication services such as voice, video, packet data, broadcast, messaging, etc. These wireless networks may be capable of supporting communication for multiple users by sharing the available network resources. Examples of such networks include wireless local area networks (WLANs), wireless metropolitan area networks (WMANs), wireless wide area networks (WWANs), and wireless personal area networks (WPANs). The terms “network” and “system” are often used interchangeably.
A wireless network may include any number of access points (APs) and any number of stations (STAs). An access point may act as a coordinator for communication with the stations. A station may actively communicate with an access point, may be idle, or may be powered down at any given moment depending on the data requirements of the station.
Standby time is an important selling point for portable devices that are battery powered. Current WLAN portable devices tend to have poor standby time performance in comparison to cellular phones. For example, the standby time for currently available WLAN Voice-over-IP (VOIP) phones typically ranges between 40 and 80 hours on batteries similar to those used in cellular phones. In comparison, cellular phones may be able to achieve 400 hours of standby time on similar batteries.
IEEE 802.11 is a family of standards developed by The Institute of Electrical and Electronics Engineers (IEEE) for WLANs. IEEE 802.11 defines a method for a station to sleep and thus save power. However, the efficiency of the method is limited for stations desiring very low power consumption because of signaling limitations in the standard as well as limited support by the access points and/or stations.
There is therefore a need in the art for techniques to improve the standby time of a station in a wireless network.
Various techniques to improve the standby time of a station in a wireless network are described herein. In an aspect, an access point conveys a maximum listen interval supported by that access point, e.g., via a beacon or a unicast frame. The maximal listen interval for a given access point indicates the maximal time interval for which a given station may sleep when associated with that access point. The listen interval for a given station indicates how often that station may wake up to receive the beacon and potential traffic. A station may operate in a power-save mode and may wake up periodically to receive the beacon and any potential traffic for the station. The station may receive the maximum listen interval from an access point and may efficiently select a suitable listen interval for that station based on the maximum listen interval supported by the access point, without having to repeatedly negotiate different listen intervals with the access point. The station may also discover the maximum listen interval in other manners, as described below.
In another aspect, an access point conveys its association timeout to stations within its coverage. The association timeout is a duration of time in which the access point will keep an association for a station even when the station shows no activity during this time duration. The station may be dormant for longer than its listen interval in order to extend battery life. The station may obtain the association timeout of the access point and may ensure to be active at least once in every association timeout in order to keep the association with the access point alive.
In yet another aspect, an access point sends broadcast and multicast traffic that might be of interest to stations in the power-save mode (or PS-stations) in a manner such that these stations may achieve improved power saving. Such broadcast and multicast traffic may include traffic associated with managing network connectivity, network monitoring, etc. The access point may send (i) a Delivery Traffic Indication Message (DTIM) to indicate regular broadcast and multicast traffic being sent by the access point and (ii) a slow DTIM to indicate broadcast and multicast traffic of potential interest to the PS-stations. The slow DTIM may be sent at a slower rate than the DTIM. The PS-stations may listen for the slow DTIM and may sleep through the DTIM.
Various aspects and features of the disclosure are described in further detail below.
The power saving techniques described herein may be used for various wireless networks such as WLANs, WMANs, WWANs, WPANs, etc. A WLAN may implement a radio technology such as any defined by IEEE 802.11, Hiperlan, etc. A WWAN may be a cellular network such as a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA) network, a Frequency Division Multiple Access (FDMA) network, an Orthogonal FDMA (OFDMA) network, a Single-Carrier FDMA (SC-FDMA) network, etc. A WMAN may implement a radio technology such as any defined by IEEE 802.16 such as 802.16e, which is commonly referred to as WiMAX, or IEEE 802.20. A WPAN may implement a radio technology such as Bluetooth. For clarity, the techniques are described below for an IEEE 802.11 WLAN.
For a centralized network, a network controller 130 couples to the access points and provides coordination and control for these access points. Network controller 130 may be a single network entity or a collection of network entities. For a distributed network, the access points may communicate with one another as needed without the uses of network controller 130.
Wireless network 100 may implement the IEEE 802.11 family of standards. For example, wireless network 100 may implement IEEE 802.11, 802.11a, 802.11b, 802.11e and/or 802.11g, which are existing IEEE 802.11 standards. Wireless network 100 may also implement IEEE 802.11n and/or 802.11s, which are IEEE 802.11 standards being formed. IEEE 802.11, 802.11a, 802.11b, 802.11g and 802.11n cover different radio technologies and have different capabilities. IEEE 802.11e covers quality of service (QoS) enhancements for a Medium Access Control (MAC) layer. In IEEE 802.11e, a station that supports QoS facility is referred to as QSTA, and an access point that supports QoS facility is referred to as QAP. QoS facility refers to mechanisms used to provide parameterized and prioritized QoS.
A station may communicate with an access point for one or more flows. A flow is a higher layer data stream that is sent via a link. A flow may utilize Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or some other protocol at a transport layer. A flow may also be referred to as a data stream, a traffic stream, etc. A flow may carry any type of data such as voice, video, packet data, etc. A flow may be for a particular traffic class and may have certain requirements on data rate, latency or delay, etc. A flow may be (a) periodic and sent at regular intervals or (b) non-periodic and sent sporadically, e.g., whenever there is data to send. A periodic flow is a flow in which data is sent at regular intervals. For example, a flow for VoIP may send a data frame every 10 or 20 milliseconds (ms). As used herein, a frame is a unit of transmission and may be a data frame, a null frame, a control frame, or some other type of frame. A frame may also be referred to as a packet, a data block, a data unit, a protocol data unit (PDU), a service data unit (SDU), a MAC PDU (MPDU), etc. A call for a station may have one or more flows for one or more traffic types.
Each beacon interval may include any number of service periods for any number of stations. A service period is a contiguous time duration during which an access point may transmit one or more downlink frames to a station and/or may grant one or more transmission opportunities (TXOPs) to the same station. A TXOP is an allocation of time for transmission on a link. A service period may be scheduled or unscheduled. A given station may have any number of service periods within a given beacon interval.
A station typically performs association procedures to associate with an access point when the station is first powered up or moves into a new WLAN coverage area. Association refers to the mapping of a station to an access point, which enables the station to receive distribution service. The association allows the distribution service to know which access point to contact for the station. The station attempts to disassociate whenever it leaves the network. The station performs reassociation procedures to “move” a current association from one access point to another access point. The association, disassociation, and reassociation procedures are described in IEEE 802.11 documents.
A station typically performs negotiation with an access point for various features or attributes such as security, Internet Protocol (IP) address, QoS, flows, power management, etc. The negotiation typically entails exchanging request and response frames between the station and the access point until pertinent parameter values are agreed upon between the station and the access point. Thereafter, the station operates in accordance with the states or context defined by the parameters negotiated with the access point.
IEEE 802.11 defines a power-save (PS) mode for stations desiring to conserve battery power. A station that desires to operate in the power-save mode indicates this intention to an access point by setting a “PS-mode” bit to 1 in a MAC header of a transmission sent to the access point. A station that is in the power-save mode is referred to as a PS-station. In response, the access point recognizes that the station will be sleeping and will wake up only at agreed upon times to receive traffic. The access point then buffers any incoming traffic data for the station and delivers the data to the station when the station is awake.
A station that is in the power-save mode may choose to wake up to receive a Traffic Indication Map (TIM) and/or a Delivery Traffic Indication Message (DTIM). The TIM is a bitmap that is present in every beacon transmitted by an access point. The TIM in a given beacon indicates to the station whether there is pending unicast traffic for that station in the upcoming beacon interval. At the time of association, the station and the access point negotiate a listen interval that indicates how often the station will wake up to listen for beacon and hence receive the TIM. The listen interval is typically multiple times the beacon interval, as shown in
The DTIM is a bitmap that indicates whether broadcast and multicast traffic is being delivered in the upcoming beacon interval. The DTIM is sent at an interval that is selected by the access point. The DTIM interval is typically multiple times the beacon interval and is fixed for a Basic Service Set (BSS), which is a network of stations associated to the access point. A station that is willing to receive broadcast or multicast traffic would decode the DTIM independently of the listen interval for that station.
An access point may select a DTIM interval based on a tradeoff between latency, buffer size requirements, and power saving. Similarly, a station that is in the power-save mode may select a listen interval as well as whether or not to wake for the DTIM based on a tradeoff between latency, buffer size requirements, and power saving.
In general, a longer listen interval provides more power saving for a station in the power-save mode but results in more delay, which may be tolerable for some types of traffic. Hence, the station may request a large listen interval at the time of association with an access point if the station favors power saving. However, a larger listen interval results in larger buffer size requirements for the access point to store potential incoming traffic for all stations supported by that access point. Supporting a large listen interval is thus a constraint for the access point because the buffers used for storing potential incoming traffic should be sized according to the amount of data that might be received during the listen interval for all stations supported by the access point.
IEEE 802.11 does not impose a requirement on the maximum listen interval that an access point needs to support. An access point may support listen intervals within a particular range, e.g., from 1 to 20 times the beacon interval, or possibly more. The supported listen interval range may be dependent on various factors such as the capability of the access point, the number of stations being served by the access point, the number of stations in the power-save mode, etc. Different access points from different vendors may support different ranges of listen intervals. Furthermore, the maximum listen interval supported by a given access point may change over time, e.g., depending on the number of stations that are in the power-save mode with that access point. Conventionally, a station has no easy way of knowing the maximum listen interval supported by an access point.
In an aspect, an access point conveys the maximum listen interval supported by that access point, and a station uses this information to more efficiently select a suitable listen interval. In one design, the access point advertises the maximum listen interval in the beacon. A beacon frame includes various information elements carrying various types of information. An information element may be defined for maximum listen interval and may be included in a beacon frame sent by the access point.
A station may listen for a beacon frame upon power up or moving into a new WLAN coverage area. The station may then determine the maximum listen interval supported by the access point. If the station desires to maximize its power saving, then the station may select the maximum listen interval advertised by the access point. The station may also select a shorter listen interval based on its traffic requirements. In any case, the station is able to select and include a suitable listen interval in the first association request sent to the access point.
In another design, an access point conveys the maximum listen interval that it supports in a unicast frame sent to a station. An information element may be defined for maximum listen interval and may be included in a frame sent by the access point to the station. In one scheme, the maximum listen interval is conveyed during system access. A station may send a probe request to an access point. The access point may include the maximum listen interval supported by that access point in a probe response sent to the station, e.g., if the “PS-mode” bit is set to 1. In another scheme, the maximum listen interval is conveyed during association. A station may select a listen interval desired by the station and include the selected listen interval in the first association request sent to the access point. If the selected service interval is not supported by the access point, then the access point may send an association response that includes the maximum listen interval supported by the access point. The station may then select a suitable listen interval and include it in the next association request.
An access point may also convey the maximum listen interval supported by that access point in other manners. A station may determine the maximum listen interval based on a beacon, a probe response, an association response, or some other transmission. The station may then select a suitable listen interval without or with little guesswork and may save power in the association procedure.
A station may also determine the maximum listen interval supported by an access point in other manners. The station may send one or more requests to determine the maximum listen interval supported by the access point. If a large listen interval is desired, then the station may try one or more listen intervals at association time until the access point accepts one of the listen intervals. The station may request the largest listen interval in the first association request sent to the access point. If the requested listen interval is too large, then the access point may simply respond with an error status code in an association response, e.g., a status code of 51 for “Association denied because the listen interval is too large”. The status code in the response does not convey to the station the largest listen interval supported by the access point. Hence, the station may then request a smaller listen interval in the next association request sent to the access point. The station may request progressively smaller listen intervals until a requested listen interval is within the range supported by the access point.
The station may also send the requests for listen intervals in other orders. For example, the station may send a request for a listen interval of N. If that listen interval is supported, then the station may send a request for a larger listen interval, e.g., N+1. Otherwise, the station may send a request for a smaller listen interval, e.g., N−1. The station may repeat sending requests until the maximum listen interval is discovered and may then use it.
In general, a station may determine the maximum listen interval supported by an access point in a heuristic manner. The station may send multiple requests for multiple listen interval values until the station receives a response accepting one of the requests and another response denying another one of the requests. The station may send one request for one listen interval value at a time. The station may start with a request for a largest listen interval value and conclude with a request for a smallest listen interval value, until the response accepting one of the requests is received. The station may also start with a request for a smallest listen interval value and conclude with a request for a largest listen interval value, until the response denying one of the requests is received. The station may also start with a request for a middle listen interval value, send a request for a larger listen interval value if a response accepting the request is received, and send a request for a smaller listen interval value if a response denying the request is received. The station may also send the requests in other orders. The station may determine a suitable listen interval for use based on the received responses.
A station typically negotiates an appropriate listen interval when it associates with an access point. The station thereafter uses the negotiated listen interval for the entire duration of the association with the access point. The negotiated listen interval may be inadequate or undesirable for various reasons, and the station may desire to select a more suitable listen interval. In this case, the station would disassociate with the access point and then reassociate with the same access point. The station may negotiate a more suitable listen interval during the reassociation with the access point. The current IEEE 802.11 standard does not provide a mechanism for updating the listen interval while a station is associated with an access point.
In another aspect, a station renegotiates the listen interval on the fly without having to disassociate and reassociate with an access point. This capability may provide certain advantages, as described below.
The station thereafter determines that the first listen interval is insufficient for whatever reason. The station then renegotiates with the access point for a second listen interval without disassociating with the access point (block 618). The second listen interval may be shorter or longer than the first listen interval, depending on the requirements of the station. The station may select the second listen interval with or without knowledge of the maximum listen interval supported by the access point. For the renegotiation, the station may send to the access point a control frame with the second listen interval. The access point may grant or deny the request by the station. If the request is granted, then the access point may send a response (e.g., an acknowledgement) indicating that the request is granted. The station receives the response and thereafter receives data based on the second listen interval (block 620). If the access point denies the second listen interval, then the station and the access point may continue negotiation until a suitable listen interval is selected and accepted.
In one design, the states or context (e.g., for security, IP address, QoS, power management, etc.) are retained for the station, and only the listen interval is changed during the renegotiation. In this design, the station thereafter communicates with the access point based on the states/context established earlier during association establishment (block 622). In another design, one or more parameters may also be renegotiated and modified either in the control frame carrying the second listen interval sent by the station or in one or more subsequent frames.
In one design, new frames that are not currently in IEEE 802.11 are defined and used for sending a request for a new listen interval and a response to this request. In another design, new information elements are defined and included in existing frames to request for a new listen interval and to respond to the request.
A station may be dormant for an extended duration that is longer than the maximum listen interval supported by an access point. In this case, entities operating above Layer 2 in the network may buffer traffic for the station and synchronize delivery from a page buffering function (PBF) to the station. The traffic buffering may thus occur upstream of the access point. The PBF may be synchronized with the station and may send traffic for the station such that the traffic reaches the access point shortly before the station wakes up at the start of the next listen interval and decodes the TIM in the beacon. The access point does not need to be aware of the extended dormancy by the station. The access point may operate in a normal manner as if the station is waking up every listen interval to decode the TIM. However, the station may wake up at a multiple of the listen interval, which is synchronized with the PBF. The longer actual listen interval may allow the station to save more power. The PBF may ensure that traffic is sent when the station is awake to receive it.
When a station wakes up at a rate that is less frequent than the listen interval and an access point does not have this knowledge, there is a risk that the access point may disassociate the station if the access point does not detect any activity from the station for an extended period of time. If the access point disassociates the station, then the states/context for the station may be lost. The station may need to perform reassociation procedures in order to re-establish the states/context with the access point. This is undesirable since the reassociation procedures consume time and power.
In yet another aspect, an access point conveys its association timeout to the stations, and a station may use this information to avoid being timed out by the access point. In one design, the access point advertises its association timeout in the beacon. Referring to the design shown in
A station that is dormant for longer than the negotiated listen interval with an access point may obtain the association timeout of the access point. The station may then ensure to be active at least once in every association timeout in order to keep the association with the access point alive. Correspondingly, the access point may ensure to keep the station associated for at least the advertised association timeout duration, even when the station shows no activity.
An access point may advertise the maximum listen interval and/or the association timeout supported by that access point in the beacon, as described above. The maximum listen interval and/or the association timeout may be received by, and applied to, all stations within the coverage of the access point. The access point may also convey the maximum listen interval and/or the association timeout in unicast frames sent to specific stations. The access point may use different maximum listen intervals and/or different association timeouts for different stations, different access categories, etc. For example, a longer listen interval and/or a longer association timeout may be used for a station with higher priority. Conversely, a shorter listen interval and/or a shorter association timeout may be used for a station with lower priority. Individual listen interval and/or association timeout for a specific station may be conveyed in the beacon or unicast frames.
The current IEEE 802.11 standard supports power save for a station and groups traffic into two categories:
A station may desire to receive broadcast or multicast traffic (e.g., audio, streaming video, etc.) from an application layer. The station may then wake up a sufficient amount of time in order to receive these traffic streams. The station is likely not a candidate for deep sleep and significant power-save operation because the DTIM may be sent often, e.g., every beacon.
Conventionally, the broadcast and multicast traffic indicated by the DTIM includes (1) broadcast and multicast traffic from the application layer, which is referred to herein as “application” broadcast and multicast traffic, and (2) broadcast and multicast traffic associated with managing network connectivity, network monitoring, etc., which is referred to herein as “network” broadcast and multicast traffic. Some examples of network broadcast and multicast traffic include Address Resolution Protocol (ARP) traffic, Dynamic Host Configuration Protocol (DHCP) traffic, topology updates, and other such types of traffic. ARP is used to map MAC addresses to IP addresses. DHCP is used for dynamic IP configuration. A station may desire to receive network broadcast and multicast traffic even when the station intends to be idle and operating in deep sleep.
Conventionally, both application and network broadcast and multicast traffic are included together and sent using the DTIM mechanism. An idle station that desires to save power will likely not be interested in receiving the application broadcast and multicast traffic. Otherwise, the station may have its display, keypad, and processor turned on, and therefore may not be saving much power anyway. However, the idle terminal may desire to ensure that its connectivity for Layer 2 and above is operational. For example, the station may desire to respond to ARP requests, possible DHCP messages, etc. These messages are also broadcast traffic and are thus sent using the DTIM.
The DTIM indicates both (a) network broadcast and multicast traffic used to maintain Layer 2 and above connectivity and (b) application broadcast and multicast traffic. Hence, a station that is interested in receiving only network broadcast and multicast traffic would need to wake up for each DTIM in order to receive potential network broadcast and multicast traffic. The DTIM is typically sent in every beacon (or every few beacons) in order to reduce the delay of the application broadcast and multicast traffic. In this case, the station may need to wake up at each beacon for the DTIM, which may severely impact power save performance.
In yet another aspect, an access point sends network broadcast and multicast traffic in a manner to improve power saving for stations in the power-save mode. A new service access point (SAP) may be made available for a new broadcast and multicast traffic class that is associated with stations in the power-save mode. This traffic class may be referred to as Power Save (PS) broadcast and multicast traffic and may include network broadcast and multicast traffic and/or other broadcast and multicast traffic that might be of interest to stations in the power-save mode.
A new DTIM may also be made available and may be referred to as a SlowDTIM or slow DTIM. The PS broadcast and multicast traffic may be sent using the SlowDTIM. The SlowDTIM may be sent at every SlowDTIM interval, which is a predetermined number of beacon intervals. The SlowDTIM interval may be larger than the DTIM interval and may be selected based on a tradeoff between power saving and messaging delay. For example, the SlowDTIM may be sent in every 2, 3, 4, or some other multiple of the DTIM.
Traffic relevant to maintaining Layer 2 and above connectivity and/or other types of PS broadcast and multicast traffic may be sent using the SlowDTIM. The PS broadcast and multicast traffic may also be copied and sent using the DTIM so that stations that do not receive the SlowDTIM can also receive this traffic. Application broadcast and multicast traffic is not sent using the SlowDTIM and is instead sent using the DTIM.
A station in the power-save mode may be able to maintain Layer 2 and above connectivity by listening to the SlowDTIM and receiving network broadcast and multicast traffic used to maintain network connectivity. The station may sleep through the DTIM, which may be sent at a shorter interval or a faster rate. The SlowDTIM may improve power saving for the station.
In one design, the SlowDTIM is sent every N DTIM, where N may be any integer greater than one. In this design, a station in the power-save mode may wake up at each listen interval as well as for each SlowDTIM. In another design, the SlowDTIM is sent in a manner to reduce the number of times that power-save stations need to wake up. For example, the SlowDTIM may be sent in each listen interval for a station or a group of stations having the same listen interval. A station may then receive the SlowDTIM and the TIM from the same beacon in each listen interval.
A station may desire deep sleep and may select a listen interval that is much longer than the SlowDTIM interval. In one design, to avoid requiring the station to wake up at each SlowDTIM interval, the network broadcast and multicast traffic may be sent directly to the station in unicast frames. The station may then receive the network broadcast and multicast traffic when the station wakes up for its listen interval. The station and the access point may configure this mode of traffic delivery, e.g., during configuration setup for the power-save mode. This traffic delivery mode may be selectively applied to stations desiring deep sleep and may be readily supported by the access point when the network broadcast and multicast traffic is segregated from the application broadcast and multicast traffic.
At station 120, an antenna 1252 receives the downlink signal from access point 110 and provides a received signal. A receiver (RCVR) 1254 processes the received signal and provides samples. A receive (RX) data processor 1256 processes (e.g., descrambles, demodulates, deinterleaves, and decodes) the samples, provides decoded data for station 120 to a data sink 1258, and provides control data and scheduling information to a controller/processor 1260.
On the uplink, at station 120, a TX data processor 1272 receives traffic data from a data source 1270 and control data (e.g., listen interval, request frames, etc.) from controller/processor 1260. TX data processor 1272 processes the traffic and control data based on a rate selected for the station and generates data chips. A transmitter 1274 processes the data chips and generates an uplink signal, which is transmitted via antenna 1252 to access point 110.
At access point 110, antenna 1216 receives the uplink signals from the station 120 and other stations. A receiver 1230 processes a received signal from antenna 1216 and provides samples. An RX data processor 1232 processes the samples and provides decoded data for each station to a data sink 1234 and provides control data to controller/processor 1220.
Controllers/processors 1220 and 1260 direct operation at access point 110 and station 120, respectively. Scheduler 1224 may perform scheduling for the stations and may also perform scheduling for broadcast and multicast traffic sent using the DTIM and slow DTIM. Scheduler 1224 may reside at access point 110, as shown in
The power saving techniques described herein may be implemented by various means. For example, these techniques may be implemented in hardware, firmware, software, or a combination thereof. For a hardware implementation, the processing units used to perform the techniques at a station may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, electronic devices, other electronic units designed to perform the functions described herein, or a combination thereof. The processing units used to perform the techniques at an access point may be implemented within one or more ASICs, DSPs, processors, etc.
For a firmware and/or software implementation, the power saving techniques may be implemented with modules (e.g., procedures, functions, etc.) that perform the functions described herein. The firmware and/or software codes may be stored in a memory (e.g., memory 1222 or 1262 in
The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US6067297||28 Jun 1996||23 May 2000||Symbol Technologies, Inc.||Embedded access point supporting communication with mobile unit operating in power-saving mode|
|US6212175||22 Apr 1997||3 Apr 2001||Telxon Corporation||Method to sustain TCP connection|
|US6480476 *||23 Oct 1998||12 Nov 2002||Telefonaktiebolaget Lm Ericsson (Publ)||Variable sleep mode for mobile stations in a mobile communications|
|US6504819||25 Sep 1998||7 Jan 2003||Alcatel Canada Inc.||Classes of service in an MPOA network|
|US6622251||17 Mar 2000||16 Sep 2003||Telefonaktiebolaget Lm Ericsson (Publ)||Method to put a mobile terminal into sleep when a frame control channel containing a location of slow broadcast channel does not include wakeup information|
|US6804542 *||22 Sep 2000||12 Oct 2004||Telefonaktiebolaget Lm Ericsson (Publ)||Sleep modes in peer-to-peer communications|
|US7010300||3 Jun 2002||7 Mar 2006||Sprint Spectrum L.P.||Method and system for intersystem wireless communications session hand-off|
|US7181190 *||30 Apr 2004||20 Feb 2007||Microsoft Corporation||Method for maintaining wireless network response time while saving wireless adapter power|
|US7194288 *||9 Aug 2005||20 Mar 2007||Lg Electronics Inc.||Periodic ranging in a wireless access system for mobile station in sleep mode|
|US7274929||16 Dec 2002||25 Sep 2007||Banginwar Rajesh P||Power management within a wireless communication system|
|US7289804 *||25 Jun 2004||30 Oct 2007||Samsung Electronics Co., Ltd.||Method for controlling sleep interval in broadband wireless access communication system|
|US7295827 *||31 Mar 2004||13 Nov 2007||Intel Corporation||Mobile station dynamic power saving control|
|US7369518 *||25 Nov 2003||6 May 2008||Samsung Electronics Co., Ltd.||Apparatus and method for reducing power consumption in ad-hoc network|
|US7424007 *||12 May 2004||9 Sep 2008||Cisco Technology, Inc.||Power-save method for 802.11 multicast paging applications|
|US7430421 *||5 Aug 2004||30 Sep 2008||Samsung Electronics Co., Ltd.||Method for controlling sleep mode in wireless access communication system|
|US7440781||7 Oct 2005||21 Oct 2008||Symbol Technologies, Inc.||System and method for power conservation in a wireless device|
|US7489648||11 Mar 2004||10 Feb 2009||Cisco Technology, Inc.||Optimizing 802.11 power-save for VLAN|
|US7505795 *||7 Jul 2004||17 Mar 2009||Advanced Micro Devices, Inc.||Power save management with customized range for user configuration and tuning value based upon recent usage|
|US7515569 *||27 Nov 2002||7 Apr 2009||Agere Systems, Inc.||Access control for wireless systems|
|US7593417 *||21 Jan 2005||22 Sep 2009||Research In Motion Limited||Handling broadcast and multicast traffic as unicast traffic in a wireless network|
|US7769414 *||16 Jul 2004||3 Aug 2010||Electronics And Telecommunications Research Institute||System and method for controlling power saving mode in wireless portable network system|
|US7916687||4 Oct 2006||29 Mar 2011||Qualcomm Incorporated||Standby time improvements|
|US8064411||31 Jan 2007||22 Nov 2011||Cisco Technology, Inc.||Speculative power save|
|US20030002465||29 Jun 2001||2 Jan 2003||Duncan Glendining||Reducing power consumption in packet based networks with quality of service (QoS) features|
|US20030093476||26 Oct 2001||15 May 2003||Majid Syed||System and method for providing a push of background data|
|US20030093530||26 Oct 2001||15 May 2003||Majid Syed||Arbitrator system and method for national and local content distribution|
|US20030112815||18 Dec 2002||19 Jun 2003||Lg Electronics Inc.||Method for generating and transmitting a train packet in an ATM switch system|
|US20030137970 *||22 Jan 2003||24 Jul 2003||Odman Knut T.||System and method for improved synchronization in a wireless network|
|US20040029586||3 Mar 2003||12 Feb 2004||Rajiv Laroia||Methods and apparatus for operating mobile nodes in multiple states|
|US20040072559||2 Oct 2003||15 Apr 2004||Nec Corporation||Radio terminal and radio communication system using same|
|US20040100973||27 Nov 2002||27 May 2004||Prasad Anand R.||Access control protocol for wireless systems|
|US20040105401 *||25 Nov 2003||3 Jun 2004||Samsung Electronics Co., Ltd.||Apparatus and method for reducing power consumption in ad-hoc network|
|US20040214571 *||26 Apr 2004||28 Oct 2004||Samsung Electronics Co., Ltd.||System and method for managing the association of device with a piconet|
|US20040235336||22 May 2003||25 Nov 2004||Brekosky Lawrence John||Electrical connector having a cover for registering cables with contacts|
|US20040235536 *||28 Apr 2004||25 Nov 2004||Samsung Electronics Co., Ltd.||Method for setting sleep interval in a broadband wireless access communication system|
|US20050043061||21 May 2004||24 Feb 2005||Takaaki Sato||Radio network controller and broadcast information transmission method|
|US20050049013 *||30 Jun 2004||3 Mar 2005||Samsung Electronics Co., Ltd.||Method and system for controlling sleep mode in broadband wireless access communication system|
|US20050059406||17 Sep 2003||17 Mar 2005||Trapeze Networks, Inc.||Wireless LAN measurement feedback|
|US20050085279||20 Aug 2004||21 Apr 2005||Sharp Kabushiki Kaisha||Communication system, base station, terminal, communication device, communication management method, control program, and computer-readable recording medium containing the same|
|US20050122936 *||8 Nov 2004||9 Jun 2005||Samsung Electronics Co., Ltd.||Method for transmitting a traffic indication message in a broadband wireless access communication system|
|US20050128988||10 Sep 2004||16 Jun 2005||Simpson Floyd D.||Enhanced passive scanning|
|US20050245215 *||30 Apr 2004||3 Nov 2005||Microsoft Corporation||Method for maintaining wireless network response time while saving wireless adapter power|
|US20050254444||12 May 2004||17 Nov 2005||Meier Robert C||Power-save method for 802.11 multicast paging applications|
|US20050288022||6 May 2005||29 Dec 2005||Lg Electronics Inc.||Method for performing handover in broadband wireless access system|
|US20060013256||18 May 2005||19 Jan 2006||Samsung Electronics Co., Ltd.||Wireless communication device and method for aggregating MAC service data units|
|US20060126533||9 Dec 2004||15 Jun 2006||James Wang||Apparatus and methods for two or more delivery traffic indication message (DTIM) periods in wireless networks|
|US20060140186||29 Dec 2004||29 Jun 2006||Logalbo Robert D||Methods for delivery in a wireless communications network|
|US20070021155||22 Nov 2005||25 Jan 2007||Industrial Technology Research Institute||System and method for reducing call establishment delay in a wireless network|
|US20070127478 *||3 Nov 2006||7 Jun 2007||Nokia Corporation||Flexible multicast and/or broadcast listening intervals|
|US20070253399||17 Oct 2006||1 Nov 2007||Deshpande Manoj M||Method and system for selecting a sleep interval to improve battery life|
|US20090279449||7 May 2008||12 Nov 2009||Nokia Corporation||Quality of service and power aware forwarding rules for mesh points in wireless mesh networks|
|US20100189021||27 Feb 2007||29 Jul 2010||Thomson Broadband R & D (Beijing) Col. Ltd.||Method and apparatus for power management in wlan|
|US20120176949||23 Mar 2012||12 Jul 2012||Qualcomm Incorporated||Standby time improvements for stations in a wireless network|
|US20140064173||8 Nov 2013||6 Mar 2014||Qualcomm Incorporated||Standby time improvements for stations in a wireless network|
|CN1592439A||11 Aug 2004||9 Mar 2005||三星电子株式会社||Method and system for controlling sleep mode in broadband wireless access communication system|
|EP1511335B1||11 Aug 2004||12 Oct 2011||Samsung Electronics Co., Ltd.||Method and system for controlling sleep mode in broadband wireless access communication system|
|EP1592272B1||28 Apr 2005||25 Nov 2009||Microsoft Corporation||Method for maintaining wireless network response time while saving wireless adapter power|
|JP2002319886A||Title not available|
|JP2002368802A||Title not available|
|JP2003529954A||Title not available|
|JP2004128949A||Title not available|
|JP2004187002A||Title not available|
|JP2004214865A||Title not available|
|JP2004242187A||Title not available|
|JP2004349971A||Title not available|
|JP2005080287A||Title not available|
|JP2005130436A||Title not available|
|JP2006005577A||Title not available|
|JP2006005630A||Title not available|
|JP2007525128A||Title not available|
|JP2007533276A||Title not available|
|JPH05323683A||Title not available|
|KR20050025039A||Title not available|
|TW200414707A||Title not available|
|WO2000060810A1||17 Mar 2000||12 Oct 2000||Telefonaktiebolaget Lm Ericsson (Publ)||Mobile terminal decode failure procedure in a wireless local area network|
|WO2000072615A1||17 May 2000||30 Nov 2000||Qualcomm Incorporated||Method and apparatus for scheduling wake-up time in a cdma mobile station|
|WO2001063842A1||21 Feb 2001||30 Aug 2001||Nokia Corporation||A method and equipment for supporting mobility in a telecommunication system|
|WO2001069859A1||16 Mar 2001||20 Sep 2001||Telefonaktiebolaget Lm Ericsson (Publ)||Mobile terminal sleep phase assignment and announcement in a wireless local area network|
|WO2002037890A2||5 Nov 2001||10 May 2002||Qualcomm Incorporated||Method and apparatus for adaptive transmission control in a high data rate communication system|
|WO2002078258A8||8 Mar 2002||20 Mar 2003||Myron Ahn||Method for data broadcasting|
|WO2003025597A1||13 Sep 2002||27 Mar 2003||Networks Associates Technology, Inc.||Decoding and detailed analysis of captured frames in an ieee 802.11 wireless lan|
|WO2005002137A1||30 Jun 2003||6 Jan 2005||Nokia Corporation||Adaptive power save mode for short-range wireless terminals|
|WO2005086379A1||4 Mar 2005||15 Sep 2005||Samsung Electronics Co., Ltd.||System and method for controlling an operational mode of a mac layer in a broadband wireless access communication system|
|WO2005125252A1||14 Jun 2005||29 Dec 2005||Matsushita Electric Industrial Co., Ltd.||Scheduling mode dependent data transmissions|
|1||European Search Report-EP11159984-Search Authority-Munich-Jul. 5, 2011.|
|2||European Search Report—EP11159984—Search Authority—Munich—Jul. 5, 2011.|
|3||European Search Report-EP11159986-Search Authority-Munich-May 16, 2011.|
|4||European Search Report—EP11159986—Search Authority—Munich—May 16, 2011.|
|5||European Search Report-EP12152876-Search Authority-Munich-Apr. 2, 2012.|
|6||European Search Report—EP12152876—Search Authority—Munich—Apr. 2, 2012.|
|7||European Search Report-EP12174765-Search Authority-Munich-Aug. 8, 2012.|
|8||European Search Report—EP12174765—Search Authority—Munich—Aug. 8, 2012.|
|9||International Search Report and Written Opinion-PCT/US2007/063190, International Search Authority-European Patent Office-Sep. 7, 2007.|
|10||International Search Report and Written Opinion—PCT/US2007/063190, International Search Authority—European Patent Office—Sep. 7, 2007.|
|11||Jing Al et al: "A adaptive coordinated medium access control for wireless sensor networks" Computers and Communications, 2004. Proceedings. ISCC 2004. Ninth International Symposium on Alexandria, Egypt Jun. 28-Jul. 1, 2004, Piscataway, NJ USA, IEEE, vol. 1, Jun. 28, 2004, pps ISBN: 0-7803-8623-X.|
|12||Taiwan Search Report-TW096107443-TIPO-Apr. 14, 2011.|
|13||Taiwan Search Report—TW096107443—TIPO—Apr. 14, 2011.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US9439146 *||8 Nov 2013||6 Sep 2016||Qualcomm Incorporated||Standby time improvements for stations in a wireless network|
|US9510280 *||25 Sep 2012||29 Nov 2016||Apple Inc.||Transmitting beacon frames over a wireless data link|
|US20140064164 *||25 Sep 2012||6 Mar 2014||Apple Inc.||Transmitting beacon frames over a wireless data link|
|US20140064173 *||8 Nov 2013||6 Mar 2014||Qualcomm Incorporated||Standby time improvements for stations in a wireless network|
|U.S. Classification||455/457, 370/311, 370/445, 455/127.5, 370/431, 455/418|
|International Classification||H04W84/12, H04W24/00, H04W52/02|
|Cooperative Classification||Y02B60/50, H04W84/12, H04W52/0225, H04W52/0216|
|11 Sep 2007||AS||Assignment|
Owner name: QUALCOMM INCORPORATED, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MEYLAN, ARNAUD;DESHPANDE, MANOJ M;NANDA, SANJIV;REEL/FRAME:019811/0757;SIGNING DATES FROM 20070614 TO 20070709
Owner name: QUALCOMM INCORPORATED, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:MEYLAN, ARNAUD;DESHPANDE, MANOJ M;NANDA, SANJIV;SIGNING DATES FROM 20070614 TO 20070709;REEL/FRAME:019811/0757