| System for low power operation of wireless lan interfaces -> Monitor Keywords |
|
|
  System for low power operation of wireless lan interfacesUSPTO Application #: 20080052548Title: System for low power operation of wireless lan interfaces Abstract: In a network including a proxy server located between a wireless access point and an origin server; and a client module detecting the availability of the proxy server; a method for conserving power in the client module includes: configuring a wireless interface to promote energy savings when using a proxy server; buffering data destined for the wireless client unit at the proxy server; and releasing the data to the client module responsive to the occurrence of at least one specified condition that promotes energy savings. (end of abstract)
Agent: Michael Buchenhorner, P.A. - Miami, FL, US Inventors: Claus Michael Olsen, Jeffrey W. Clark, Chandrasekhar Narayanaswami, Marcel-Catalin Rosu USPTO Applicaton #: 20080052548 - Class: 713310000 (USPTO) Related Patent Categories: Electrical Computers And Digital Processing Systems: Support, Computer Power Control, By External Command The Patent Description & Claims data below is from USPTO Patent Application 20080052548. Brief Patent Description - Full Patent Description - Patent Application Claims
[0001] This application is a division of co-pending, commonly-owned U.S. application Ser. No. 10/419,656, filed on Apr. 21, 2003, which is incorporated by referenced herein. FIELD OF THE INVENTION [0002] The invention disclosed broadly relates to the field of wireless communications, and more particularly relates to the field of power management in wireless local area networks (LANs). BACKGROUND OF THE INVENTION [0003] Referring to FIG. 1 there is shown an example of a known wireless LAN system 100 comprising a wired LAN 120 which comprises a LAN server 124 and a wired Client 122, both coupled to the LAN by a wireline bus 128. The system further comprises a plurality of access points (APs) 126 which are similar to base stations in a cellular system. Wireless Client Units 132 typically communicate with the access points 126 over the air in an unlicensed frequency such as the 2.4 GHz ISM (Industrial, Scientific and Medical) band. APs 126 are connected to an Ethernet hub or LAN server and transmit radio frequency signals over an area of up to a thousand feet which can penetrate walls and other non-metal barriers. Roaming users (e.g., Wireless Client Units 132) can be handed off from one access point 126 to another as in a cellular mobile phone system. Laptops use wireless modems that plug into an existing Ethernet interface or that are self-contained on PC cards, while stand-alone desktops and servers use plug-in cards. [0004] Power consumption by mobile stations (wireless units) is a significant problem because these units are generally battery-powered, and to support wireless communication requires a level of power consumption that significantly reduces battery life, See for example E. Shih et al, "Wake on Wireless: An Event Driven Energy Saving Strategy for Battery Operated Devices, " MobiCom 2002. [0005] Before discussing an embodiment of the invention, we shall first present a summary of the IEEE 802.11 Wireless Local Area Network (WLAN) protocol, the two Power modes within this protocol and the dynamics of the WLAN system. Note that unless otherwise specified, whenever we mention the term power we are referring to the power consumption in the wireless interface, including host system power consumption directly related to running the wireless protocol. The power associated with other components in the client are excluded such as display power, power supply loss, and processor/memory power associated with executing other computing tasks. [0006] The following background discussion addresses WLAN Clients (or STAs in 802.11 parlance) operating in the so-called "Infrastructure" mode in which an access point (AP) 126 connects the Wireless Client Units 132 to another network medium, typically a wired Ethernet medium. The role of the APs 126 is to synchronize the Wireless Client Units 132 on a common time base and to buffer packets on behalf of the Wireless Clients 132 as well as coordinate delivery of the packets to the Clients 132. Synchronization is maintained by a beacon signal which is launched by the AP 126 typically every 102.4 ms. Further, the AP 126 provides support for the Clients 132 operating in one of two power modes, namely the Constant Awake Mode (CAM) and the Power Save (PS) mode. In the CAM mode, Clients 132 are registered with the AP 126 as constantly being in the "Awake" state which means they must always be monitoring the wireless medium. Accordingly, the AP 126 may send packets to the Client 132 at any given time. Since the receiver of Client unit 132 is always on in the Constant Awake Mode, this mode also consumes the most power. [0007] In the Power Save mode, Clients 132 are registered with the AP 126 as being in the "Doze" state between beacon signals and as "waking up" temporarily to receive selected beacon signals. The AP 126 must buffer packets destined for Clients 132 that are registered as being in the PS mode. The AP 126 informs Clients in PS mode if there are packets queued up at the AP 126 by including a Traffic Indication Map in the beacon signals that the Client 132 is expected to receive. In turn, the Client 132 in PS mode will poll the AP 126 to retrieve the queued-up packets. [0008] Clients 132 operating in the PS mode may have significantly lower power consumption. Clients 132 can further reduce their power consumption by skipping beacon signals. Clients 132 may do so after first informing the AP 126 of their intention by passing a parameter known as the ListenInterval to the AP 126. This ListenInterval indicator is the interval between beacon signals in which the Client 132 intends to wake up and receive the beacon signal. For example, a ListenInterval of Nlisten=1, means that the Client intends to wake up to receive every single beacon signal. A ListenInterval of Nlisten=3 means that the Client 132 intends to wake up to receive every third beacon signal. The power consumption, Pdoze, in the wireless interface when the Client 132 is in the Doze state, is much less than power consumption when the Client 132 is in the Awake state, or Pawake. In the case where the time spent in the Doze state, or Tdoze, is much greater than the time spent in the Awake state, Tawake (when the beacon signal can be received), the average power consumption, P, follows this formula: <P>=Pdoze+Pawake*Tawake/Tdoze [0009] State-of-the-art power numbers are Pdoze=5 mW and Pawake=500 mW, and typically it takes Tawake=10 ms to receive a beacon signal. By extending the ListenInterval beyond 10, which increases Tdoze beyond 1 second, the power consumption of the Client 132 may be reduced by almost two orders of magnitude below the CAM mode. [0010] One drawback of being in the Power Save mode is a significantly reduced network throughput since the Client 132 is not able to receive incoming packets as they arrive. Instead, the Client 132 must wait until it wakes up to receive the beacon signal, and then poll the AP 126 to receive the queued packets. At first sight this seems to impact only latency, which does not necessarily translate into a throughput reduction. The fact is, however, that throughput is severely impacted, as discussed in R. Krashinsky, H. Balakrishnan, "Minimizing Energy for Wireless Web Access with Bounded Slowdown," MobiCom 2002. The reason for this is rooted in the manner in which network application data are sent across a network from an origin server to a client. See, P. Barford, M. Crovella, "Critical path analysis of TCP transactions", IEEE/ACM Transactions on Networking, Vol. 9, No. 3, 2001, for a discussion on this issue. [0011] Today, the predominant network protocol is the Transfer Control Protocol/Internet Protocol (TCP/IP) stack. See D. E. Corner, "Internetworking with TCP/IP: Volume I," Prentice Hall, 2nd Edition, 1991. In this stack, TCP ensures reliable data packet delivery between two TCP endpoints. An endpoint is defined as an IP address and TCP port number pair. An association of two distinct endpoints is called a TCP connection and the TCP protocol defines the mechanisms for establishing connections, for reliable data delivery, and for terminating connections. The TCP is a symmetric protocol (i.e., the same connection guarantees reliable data delivery in both directions; either one of the two endpoints can initiate the establishment or termination of a connection; and the protocol provides for simultaneous open and close). However, to simplify the discussion, we shall call the endpoints `client` and `server,` respectively, and refer to the data flow from the server to the client only. [0012] Reliable data packet delivery is accomplished via two means. First, the client must acknowledge each DATA packet it receives from the server, typically one ACK packet (used to acknowledge the error-free receipt of transmitted data) for every two DATA packets. Secondly, the server will only send a limited number of DATA packets while allowing for the ACK packet(s) to be received later. The maximum number of outstanding, i.e. non-ACKed, data packets, expands according to a congestion window size (CWND) algorithm, as explained below. This algorithm, however, restarts for every new network connection that is established at the TCP level. To give an example of how all this works, assume that a File Transfer Protocol (FTP) session is established with an FTP server. Within the FTP application, the client may issue the command "get <file_name>" on the command connection, the first connection established between the FTP client and server. On execution of this command, a second TCP connection, called the data connection, is established between the client and the FTP server, and upon receipt of the entire file, the data TCP connection is torn down. [0013] Assuming that the FTP service is configured to use passive-mode, (as most anonymous FTP servers and clients, such as Netscape, are configured today), the following describes the dynamics of the packet transfer between the client and the server as well as the CWND algorithm during the lifetime of the connection. To open the data connection, the client sends the first packet, called a SYN (synchronization) packet, to the server, to a port number that was previously provided by the server on the command connection. The server must respond immediately with a SYN packet, which must also acknowledge (ACK) the receipt of the client SYN packet. This server packet is called a SYN/ACK packet, because of its dual role. [0014] At the same time, as part of the CWND algorithm, the server initializes its CWND variable to a value of one. The client acknowledges the SYN/ACK packet immediately, by sending an ACK packet. In TCP, all ACK packets are cumulative. Upon receipt of the ACK, the server increases its CWND by one, as specified by the CWND algorithm. In addition, the server will send two data packets (if the requested file is large enough). As long as no DATA or ACK packets are lost or reordered, the server increases its CWND by one for every ACK it receives, up to a very large limit, and it sends the maximum number of packets allowed by the current CWND, the last ACK, and the file size; the client sends an ACK packet for every two data packets it receives, or after a system-dependent timeout expires (typically 100 ms), if there is any unacknowledged data received. The CWND algorithm is substantially more complex, due to its handling of extraordinary events, such as packet loss and reorder or idle timeout expirations, when CWND is reduced, such as halved or reset to one, and its upper limit reset to a lower limit, such as its value before the event. In the interest of brevity, the descriptions of how TCP handles extraordinary events and of TCP connection termination are not included here, however those skilled in the art are familiar with these subjects. [0015] As may be recognized from the above discussion, if the Client 132 is slow to receive the SYN/ACK packet, its transmission of the first ACK packet will be delayed. And then if the Client 132 is slow to receive the first two DATA packets it will also be slow to acknowledge them. As the CWND grows larger, and the instantaneous throughput increases, the AP 126 is queuing up an increasing number of DATA packets (up to the CWND number of packets). This is occurring while the Client 132 is in the Doze state. The Client 132 may then fetch packets very rapidly after the next beacon signal it receives (when it is in the Awake state). However, the total average throughput will suffer to an increasing extent with smaller file sizes due to the so-called "TCP slow start" phenomenon that is experienced in the very beginning of a new network connection, i.e. two DATA, then one ACK, then four DATA, then two ACKs, and so forth. It may also be seen that the smaller the ListenInterval is, the better the throughput is. But even for Nlisten=1 (i. e., the Client will receive every beacon signal), a DATA packet which is typically 1500 bytes takes only 1.1 msec to transfer across an 11 Mbps wireless interface. Thus, considering a typical beacon period of 102.4 msec and taking into consideration TCP, IP and medium-access control (MAC) protocol inefficiency, almost 50 DATA packets have to queue up at the AP 126 before the Client 132 in PS mode is no longer limiting the throughput, assuming the Client-Server connection bandwidth is limited by the speed of the wireless interface, i.e. 11 Mbps. Several other factors may further limit the maximum possible throughput. It should be noted that the maximum throughput of 50 maximum sized DATA frames per 102.4 ms beacon is based on measurements performed with an 802.11b wireless LAN client operating in the CAM mode and corresponds to a maximum throughput of 700 kilobytes per second (kByte/s), or about half the speed of the wireless interface itself. The inefficiency is mainly due to 802.11b protocol overhead. TCP/IP frame overhead also contributes. [0016] There are two actions that may be undertaken to minimize the adverse effect on the throughput for a Client 132 in PS mode. First, whenever a DATA packet is detected, the Nlisten state is immediately reduced to minimal size in anticipation of more DATA packets to queue up at the AP 126. Second, the Client 132 in PS mode temporarily transitions into the CAM mode where it may remain for typically 100 ms, but could remain as long as 1 second. This temporary visit to the CAM mode will be referred to as the CAM timeout time, or Ttimeout. Typically, Ttimeout is reset to its original value, say 100 ms, after a DATA packet has been either transmitted or received. [0017] By reducing Nlisten to 1, some improvement may be achieved in throughput. However, considering that the cumulative size of a typical web page is around 150 KB, only 1/3 of the maximum achievable throughput may be reached, due to the "TCP slow start" phenomenon mentioned earlier. [0018] With respect to temporarily exploiting the CAM mode, this is an extremely effective method which, in some cases, may regain 100% throughput efficiency, even without a reduction in Nlisten. The reason is that as long as the Client-Server round trip time, Tround, is comfortably smaller than Ttimeout, the Client 132 will remain in the CAM mode due to resetting of Ttimeout on every DATA packet. That is, until no DATA packet has been either sent or received for a period of Ttimeout. [0019] The problem with utilizing the CAM mode, even for brief moments such as 100 ms, is an increased power consumption if the Client-server bandwidth is smaller than the wireless bandwidth. As long as there are DATA packets being received, or sent, the Client 132 will remain in the CAM mode for another 100 ms. Therefore, if the overall throughput is slow, the Client 132 will spend excess time in the CAM mode waiting for DATA packets to arrive at the AP 126. As the Client-Server bandwidth decreases, the power efficiency decreases too. Typical Client-Server throughput on the world-wide web (WWW) is in the range of 25-150 kBytes/second depending on the particular server and its load and on the Client's browser. This throughput may be measured by a web sniffer (software and/or hardware that analyzes traffic and detects bottlenecks and problems in a network) such as IBM's PageDetailer. [0020] It should be noted that there do exist solutions which attempt to increase the download throughput at the Client 132. One such solution is to combine web caching with web prefetching, where the server prefetches web data that a Client 132 is expected to request on the basis of the Client's request history. This methodology is denoted speculative prefetching. See X. Chen, X. Zhang, "A popularity-based prediction model for web prefetching", IEEE Computer, March 2003, for a discussion of prefetching. The efficiency of speculative prefetching, however, is not reliable, or predictable, on a per client basis. Speculative prefetching works best in proxy servers which host thousands of clients, and which see very high throughputs. Prefetching proxies also constantly have to revew pages as they time out, and therefore generate a significant amount of network traffic. It is therefore also beneficial for overall network performance if there are not too many of such proxies. [0021] It should be further noted that the benefits of proxy servers to enhance and support the capabilities of clients is well known. See D. Gourley, B. Totty, "HTTP: The definitive guide", O'Reilly, 2002, for a good survey of proxy servers and how they function. Proxy servers have been developed for many purposes. Probably, the most well known types of proxy servers are the web cache proxy server and the security firewall proxy server. Other interesting types include proxies for transcoding content to better suit the capabilties of a certain device (such as a PDA), and filtering proxies for blocking access to inappropriate web sites. There are, however, no proxy servers that optimize for power consumption in the clients. [0022] Finally, note that quite a bit of work has been done in the transport network layer, and below, to reduce power consumption. See, C. E. Jones, K. M. Sivalingam, P. Agrawal, J. C. Chen, "A survey of energy efficient network protocols for wireless networks", Wireless Networks, No. 7, 2001. These network level methods, however, do not replace or reduce the importance and benefits of a proxy server. Continue reading... Full patent description for System for low power operation of wireless lan interfaces Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this System for low power operation of wireless lan interfaces patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like System for low power operation of wireless lan interfaces or other areas of interest. ### Previous Patent Application: System and method to optimize multi-core microprocessor performance using voltage offsets Next Patent Application: Semiconductor data processing device and data processing system Industry Class: Electrical computers and digital processing systems: support ### FreshPatents.com Support Thank you for viewing the System for low power operation of wireless lan interfaces patent info. IP-related news and info Results in 0.80933 seconds Other interesting Feshpatents.com categories: Daimler Chrysler , DirecTV , Exxonmobil Chemical Company , Goodyear , Intel , Kyocera Wireless , |
||
