US20080046547A1

US20080046547A1 - System for Low Power Operation of Wireless LAN Interfaces

Info

Publication number: US20080046547A1
Application number: US11/926,846
Authority: US
Inventors: Claus Olsen; Jeffrey Clark; Chandrasekhar Narayanaswami; Marcel-Catalin Rosu
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2003-04-21
Filing date: 2007-10-29
Publication date: 2008-02-21
Also published as: KR100872254B1; US20040255008A1; KR20060009237A; US20080052366A1; WO2004095193A2; US7752330B2; TW200536305A; CN101069173A; US20080052548A1; EP1616240A4; TWI351195B; EP1616240A2; WO2004095193A3; CN101069173B

Abstract

A wireless client unit for communicating with at least one apparatus for buffering network information destined for the wireless client unit includes: a wireless interface between the apparatus and the wireless client unit; a module for determining whether at least one of the apparatus is available for use by the wireless client unit; and a module for configuring the wireless interface between the apparatus and the wireless client in a manner which promotes energy savings.

Description

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

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

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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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 ⅓ of the maximum achievable throughput may be reached, due to the “TCP slow start” phenomenon mentioned earlier.
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.
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.
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 review 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.
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 capabilities 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.
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.
Therefore, current solutions do not manage to effectively reduce the wasted power consumption while the Client is waiting, or listening, for more data while in the CAM mode. Consequently, there is a need to further reduce consumption of power in mobile stations.

SUMMARY OF THE INVENTION

Briefly, according to an embodiment of the present invention, a wireless client unit for communicating with at least one apparatus for buffering network information destined for the wireless client unit includes: a wireless interface between the apparatus and the wireless client unit, a module for determining whether at least one of the apparatus is available for use by the wireless client unit; and a module for configuring the wireless interface between the apparatus and the wireless client in a manner which promotes energy savings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of a prior art wireless LAN system.
FIG. 2 shows a representation of a wireless LAN environment wherein a system in accordance with the invention can be advantageously used.
FIG. 3 shows a more detailed representation of a portion of the network shown in FIG. 2.
FIG. 4 shows a graphical representation of power consumption using a direct scheme, according to the prior art, and the proxy scheme, according to an embodiment of the invention.
FIG. 5 shows a flowchart of Web page retrieval using a Proxy Server, according to an embodiment of the invention.
FIG. 6 shows a simplified block diagram of an Application Proxy Server, according to an embodiment of the invention.
FIG. 7 shows a block diagram representation of a wireless client, according to an embodiment of the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring to FIG. 2, there is shown a block diagram of a communication system or network 200 using a Proxy Server scheme, according to an embodiment of the invention. The system 200 comprises a plurality of wireless client units such as Wireless Client 202. These can be laptop computers, personal digital assistants or other wireless communication devices, wherein battery life is an important consideration. The Wireless Client 202 is connected to an Intranet 214 via an Access Point (AP) 206 that comprises a wireless transceiver for providing wireless communication with a Client 202. The AP 206 is often connected to the Intranet 214 through a Multiport Ethernet Switch 205 as shown in FIG. 2. According to the invention, an Application Proxy Server 204 is also connected to the Intranet 214 and to the AP 206 through the Multiport Ethernet Switch 205.
The Intranet 214 is connected to the Internet 210 via a Gateway 208. Also connected to the Internet 210 is a Server 212 (called an Origin Server herein). The network 200 uses the TCP/IP protocol to exchange packets.
Referring to FIG. 3, there is shown an illustration of a more detailed block diagram of the network 200, according to an embodiment of the invention. The Intranet 214 is shown as a Wired LAN 306 such as the one discussed with respect to FIG. 1 except that it now includes a plurality of application Proxy Servers 204 each connected to the AP 206 and the rest of the Wired LAN 306 through Multiport Ethernet Switches 205. The Wireless Clients 202 are also different from those shown in FIG. 1 in that they are adapted to use the services of the Proxy Servers 204.
In this embodiment we shall discuss an 11 Mbps IEEE 802.11b wireless LAN, which limits the maximum Client-Server application bandwidth, or throughput, to about 750 kBytes/s. However, those skilled in the art will appreciate that the principles of the invention may be used in other embodiments including other 802.11 systems, and other wireless and wired communication systems. The Proxy Server scheme works by prefetching application data from the Origin Server 212. This causes data to accumulate in the Proxy Server 204 until the wireless Client 202 is able to retrieve the data and until the Proxy Server 204 releases the data. In this fashion, the Client 202 is not required to communicate with the Origin Server 212 in the CAM mode, as now this task is handled by the Proxy Server 204. The Client 202 still has to wait for data packets from the Proxy Server 204 in the CAM mode. But since the Client-Proxy bandwidth (e.g. 750 kBytes/s) is much greater than the Client-Origin Server bandwidth (e.g. 25-150 kBytes/s), the Client 202 may retrieve data packets about 5-30 times faster from the Proxy Server 204, and therefore spend up to 5-30 times less time in the CAM mode, thereby reducing energy consumption.
Furthermore, assuming the Client 202 is aware of the presence of the Proxy Server 204, the Client 202 may adjust its own Ttimeout to be very small since it knows that the response time of the Client-Proxy connection is very high, due to the high Client-Proxy bandwidth. The only factor that may really impact the response time is the wireless network itself, e.g. due to contention or data loss. Communicating via the AP 206 and the Proxy Server 204 will be fast in comparison to communicating directly with the Origin Server 212. In the preferred embodiment it will be assumed that Ttimeout=25 ms. The net effect of all this is that the Client 202 may significantly reduce energy consumption while in the CAM mode. According to an aspect of the invention, the Client 202 is configured to detect the presence of the Proxy Server 204 and to adjust its Ttimeout according to whether the Proxy Server 204 is available to cache messages or not.
The Proxy Server 204 operates at the application level. In a preferred embodiment a web browser application is used. So in this case, the Proxy Server 204 is a web proxy which uses HyperText Transfer Protocol (HTTP) to retrieve web pages and objects from the Origin Server 212. Similarly, the Client 202 uses HTTP to retrieve web pages and objects from the Proxy Server 204.
Referring now to FIG. 4 we see two charts 410 and 420, illustrating the dynamic power consumption (Power) in the Wireless Client's 202 WLAN interface and the number of accumulated DATA packets, N_DATA, in two different systems: 1) when the Client 202 is connected directly to the Origin Server 212, as shown in the Direct scheme 410; and 2) when the Client 202 is making use of the Proxy scheme 420. SYN and FIN represent the initial Client 202 TCP connection request packet and the final Client 202 TCP connection packet, respectively. The remaining “down” arrows (↓) indicate the arrival of DATA packets a) at the Access Point 206 and b) at the Proxy Server 204. Other packets, such as SYN/ACK and ACK packets, are not shown. In both cases Nlisten=5 (the Client 202 will receive every fifth beacon signal).
As may be seen from FIG. 4, in the Proxy Scheme 420, the Proxy Server 204 accumulates packets at whatever speed they may arrive at the Proxy Server 204. In the meantime, the Client 202 is in the Doze state saving energy. Then, when the Client 202 wakes up, it transitions into the CAM mode on detection of the first DATA packet. It then retrieves all buffered packets, depleting the Proxy Server 204 buffer as fast as possible. It then waits for Ttimeout=25 ms in the CAM mode, and if no more DATA packets are transmitted by the AP 206 it returns to the Doze state.
The Web Proxy Server helps reduce the Client 202 power consumption in at least two ways. First, by splitting the TCP connection between client and server into two separate connections, Client-Proxy and Proxy-Server. This split buffers the Client 202 from the negative effects that wide-area network conditions (e.g., limited bandwidth, high latency, packet loss) have on the packet dynamics and its impact on the Ttimeout selection. The benefits of splitting the TCP connections at the Proxy Server 204 apply to any TCP traffic that is mostly unidirectional, towards the Client 202.
The second benefit is specific to Web content and it is illustrated in FIG. 5 which shows a flowchart 500 detailing the process of retrieving and releasing a web page. More specifically, the second benefit stems from the way web pages are constructed, with a main page which may include several other objects embedded in this page. The process begins at step 510 with the receipt of an HTTP request from the Client 202 which wakes up the main thread, ProxyMain(*Object). In case of the initial HTTP request, the Web Proxy Server spawns the GetWebObject(*Object) thread in step 512 which fetches the object from the Origin Server 212. Note that *Object is a pointer to the HTTP request header string. The header includes the Origin Server 212 name, the path name of the object/page, and the cookie, among other things. In case of a subsequent client HTTP request (e.g. the Client 202 requests an embedded image in the main HTML page), it is first determined in step 514 if the object has already been fetched and therefore present in the cache. If the object is absent in the cache then in step 516 the GetWebObject( ) thread is woken up. If the object is present in the cache then in step 518 the ReleaseObject(*Object) thread is spawned, releasing the object to the Client 202. The thread is then put into a wait state in step 520.
Step 530 is the GetWebObject(*Object) thread. This thread fetches the object from the Origin Server 212 in step 532, saves it in cache in step 534 and then spawns the ReleaseObject(*Object) in step 536 to release the object to the Client 202. Next, it is determined if the object is parseable. In case of a non-parseable object, the thread is put into a wait state in step 538. In case of a parseable object, such as an HTML page or Java script, the object is parsed in step 540 and the number of embedded objects is counted. Next, in step 542, the next object is fetched from the Origin Server 212 and then saved in cache in step 544. If the current object is parseable, execution returns to step 540. If the current object is not parseable, the object count is decremented by one in step 546. If there are more objects to prefetch, then execution returns to step 542. When all objects have been prefetched, the thread is put into a wait state in step 538.
Step 560 is the ReleaseObject(*Object) thread which releases the object to the Client 202 in step 562 and then terminates the thread in step 564.
Note that ReleaseObject( ) threads are always spawned and immediately terminated upon complete transfer of an object. This enables the Proxy Server 204 to accept multiple successive Client 202 requests, i.e. pipelined requests, in step 510. The ReleaseObject( ) threads synchronize with each other during servicing of pipelined requests to conform to the HTTP protocol specifications.
Note that step 532 assumes that the object has not already been received in an earlier request. If the object is already in cache, then step 532 may simply fetch the object from cache, skip step 534 and jump to step 536.
Note that the flowchart 500 shown in FIG. 5 accounts for releasing web objects based on the condition of receiving the entire object. In general, web data may be released on other conditions as well. For example, another condition could be to release web data based on exceeding a certain amount of buffer space. Yet another condition could be to release web data based on a timeout. In both cases, the Proxy Server 204 could start releasing web data before it has received an entire object.
The number of embedded objects may vary from a few to more than one hundred and depends on the Web page content and the Web design tool(s) used. When handling pages with embedded objects, the Proxy Server 204 may attempt to emulate some of the client actions with respect to parsing the main page and requesting the embedded objects. For example, it is up to the particular implementation of a web browser in which order embedded objects are requested. The same holds true for objects manifesting themselves as a result of executing other embedded objects. Since, in principle, the Proxy Server 204 may know which web browser a Client 202 is using, the Proxy Server 204 can adjust its prefetching policy accordingly to better match the subsequent sequence of requests from the Client 202.
While the prefetch actions occur, the Client 202 may remain in the Doze state for a longer period and occasionally wake up to determine if there are packets queued up at the Proxy Server 204. Once the main page is retrieved by the Client 202, it is very likely that the Client 202 stays in the Awake state until it has received all currently released objects from the Proxy Server 204 and that this time interval (Tawake) is significantly shorter than in the non-proxy configuration, as the embedded objects are served from the local Proxy Server 204 cache. Furthermore, the Client 202 will return to the Doze state soon after the last object is retrieved, since the Client 202 can be configured with a low Ttimeout value as packet transfers occur across the low-latency Client-Proxy connection.
The Client 202 must be configured (programmed or wired) to detect the presence of the Web Proxy. This is important because the Power Management (PM) mechanism in the Client 202 will depend upon the expectations to the Client-Server latency and server properties as explained earlier. This may be done as follows. In the Client 202 a ProxySniffer( ) daemon is using a UDP port. Occasionally, it will broadcast a sniff packet on an agreed upon UDP port and then wait for a response. The sniff packet may contain information about the browser's capabilities and configuration. On the Web Proxy, an Alert( ) daemon is listening on the agreed upon UDP port. When it detects the sniff packet from the Client 202 it responds with its IP address, TCP port and capabilities. In turn, the Client 202 then configures the Web browser application to use the Proxy Server 204. Secondly, the Client 202 selects a suitable Power Management (PM) scheme for the wireless LAN interface. One such suitable PM scheme is to set Nlisten=5 (i.e. 512 ms) and Ttimeout=25 ms in the MAC network layer. In order to enable the changes in the PM scheme, the Client 202 must be able to share Proxy Server 204 information with the MAC. This is described later. Note that to prevent the sniff packet from propagating to proxies belonging to other APs, each Proxy Server 204 should be on a different IP subnet, since broadcast packets do not propagate across subnets.
The Client 202 should also be able to determine if there are any application network sessions or not. By definition, application session context is only known within each application. However, by sharing the session context with the MAC network layer, a more suitable PM scheme may be selected. One such suitable PM scheme is to set Nlisten=100 as opposed to Nlisten=5 when the Client 202 is not connected with a server, since there is no reason why the Client 202 should wake up to receive the beacon signal every 5 beacons, as there will never be any packets queued up at the AP 206. In fact, the WLAN interface may be completely shut down, and then started up again when the user clicks on a hyperlink. Note that such optimizations are possible only when the Client 202 doesn't run any server-like applications, i.e., applications listening to specific TCP/UDP ports for commands. If the Client 202 runs server-like applications, the above optimizations can still be used if the clients of these applications can tolerate (extremely) large response times.
The following discussion describes how to retrieve the application session context and how to transmit the session and Proxy contexts to the MAC layer and how to reflect the Proxy context in the network settings of the Web browser.
Retrieving the Application Network Session Context.
In the Client 202, a SessionContext( ) module hooks into the TCP protocol layer where it intercepts communication on all the relevant ports, to determine when a connection is opened and closed, by intercepting all communication with the IP network layer. SessionContext( ) also needs to know which application is associated with each port which may be retrieved from known system configuration files or databases. Those skilled in the art of network programming will know how to implement the SessionContext( ) module. Also, tools for retrieving network context are commercially available. For example, the network context can be made available at the user level on a Linux client using shell commands such as ‘netstat-t’, which lists all the TCP connections of the client, their state, and receive and send queue sizes.
Communicating Context to MAC Driver.
Communicating the context from ProxySniffer( ) and SessionContext( ) to the MAC driver is known to anyone skilled in the art of enabling software modules, or software components, to exchange data. See for example J. Richter, “Advanced Windows,” 3rd Edition, Microsoft Press, 1997 and A. Rubini, J. Corbet, “Linux Device Drivers,” 2nd Edition, O'Reilly, 2001.
Reflecting Proxy Context in Web Browser Network Settings.
Reflecting the Proxy context, most importantly the IP address of the Proxy Server 204, in the Web browser is known to anyone skilled in the art of systems programming. For example, under Microsoft Windows™ it is a matter of updating the particular key in the Windows Registry which holds the address of a Proxy Server 204. Also the particular key that instructs the browser to use a Proxy Server 204 in the first place must be enabled, or disabled if the Proxy Server 204 disappears. Finally, the Web Browser's configuration utility must be toggled in order to detect the modifications made to the Windows Registry keys.
In general, web browsers, and other network applications, do not allow other software components to trigger the toggling of their configuration utility. Consequently, the client will continue using the same proxy, which is no longer the optimal proxy, until the user happens to restart the browser. A remedy for this is to use a technique known as Network Address Translation (NAT) at the IP protocol level. By inserting a NAT function into the IP software layer which intercepts all packets, the NAT function can manually insert the proper proxy IP address. In order for this to work the NAT function also needs to know which TCP port the Browser is using so the NAT function can properly isolate browser originated packets. The mapping of TCP port number versus network application is readily accessible in any Operating System's configuration database, such as the Microsoft Windows Registry.
Those skilled in the art will realize that the Web Proxy could also be an Email Proxy or any other network application Proxy.
Those skilled in the art will realize that the Proxy 204 could also be integrated with the Access Point 206, and that the Proxy Server 204 could be located anywhere else on the Intranet 214, or even on the Internet 210. What is important for the sake of reducing power is that there is a high-speed connection between the Wireless Client 202 and the Proxy Server 204. Therefore, the closer to the Access Point 206 the Proxy Server 204 is, the higher is the connection bandwidth between the Client 202 and the Proxy Server 204.
Referring now to FIG. 6, the Proxy Server 204 comprises a Buffer 600 for storing data (or other information) destined for a Client unit 202. The Buffer 600 is a part of the system memory (RAM) of the Proxy Server 204, controlled by a Buffer Control Program 602. A Client Alert Program 608 informs clients of the IP address and other capabilities of the Proxy Server 204. The Buffer Control Program 602 and the Client Alert Program 608 can be implemented as software which executes on a Processor 604. An Input/Output (IO) Interface 606 will enable communication with clients and other information processing systems. The Proxy Server 204 operates at the network application level, or more specifically at the layer 5 and above the Open System Interconnection (OSI) ISO standard. In the preferred embodiment, we shall assume a Web Browser application. So in this case, the Proxy Server 204 is a Web Proxy which uses HyperText Transfer Protocol (HTTP) to retrieve web pages and objects from the Origin Server 212. Similarly, the Client 202 uses HTTP to retrieve Web pages and objects from the Proxy Server 204.
According to another embodiment of the invention the Proxy Server 204 comprises software configured to delay processing at least some of the data buffered for a client for an amount of time greater than zero based on detected operating parameters of the client. The operating parameters comprise the type of device that the client is such as a mobile telephone or a wireless laptop or palmtop or the operating system used. The Proxy Server 204 can detect these operating parameters by analyzing signals received from the Client 202. The parameters can be expressly stated in for example metadata or can be inferred from the type of signal received (e.g., the protocol used). The Proxy Server 204 can be programmed to adjust the processing delay by predetermined amounts of time according to the detected parameters.
FIG. 7 shows how a Wireless Client 202 may be configured according to an embodiment of the invention. A Wireless Client 202 may be configured with components to include a radio-frequency (RF) Transceiver 702, a Processor 704, a Proxy Server Detector Program 706, a Proxy Configuration Program 708, and a Client Configuration Program 710. A Battery 712 will also be part of the configuration.
Therefore, while there has been described what is presently considered to be one or more preferred embodiments, it will be understood by those skilled in the art that other modifications can be made within the spirit of the invention.

Claims

1. A wireless client unit for communicating with at least one apparatus for buffering network information destined for the wireless client unit, the wireless client unit comprising:

a wireless interface between the apparatus and the wireless client unit;

a module for determining whether at least one of the apparatus is available for use by the wireless client unit;

a module for configuring the wireless client unit to use the apparatus; and

a module for configuring the wireless interface between the apparatus and the wireless client unit in a manner which promotes energy savings.

2. The wireless client unit of claim 1 further comprising a module for programming the apparatus to release said data on at least one occurrence of a specified condition that promotes energy savings.

3. The wireless client unit of claim 2 wherein the specified condition comprises exceeding a buffer threshold.

4. The wireless client unit of claim 2 wherein the specified condition comprises ending of an application data stream.

5. The wireless client unit of claim 2 wherein the specified condition comprises receipt of at least one object.

6. The wireless client unit of claim 2 wherein the specified condition comprises expiration of a specified period of time.

7. The wireless client unit of claim 1 further comprising software configured to infer information about a session context; and wherein said software is further configured to use said session context for the purpose of configuring the wireless interface to promote energy savings.

8. The wireless client unit of claim 7 further comprising software configured to extend a beacon listen interval upon failure to detect active sessions.

9. The wireless client unit of claim 1 further comprising software configured to exploit advanced power management settings of the wireless interface upon failure to detect active sessions.

10. The wireless client unit of claim 1 further comprising software configured to disable the wireless interface upon failure to detect an active session.

11. The wireless client unit of claim 7 further comprising software configured to use said session context for reducing a beacon listen interval upon detection of an active session.

12. The wireless client unit of claim 7 further comprising software to use said session context to enable the wireless interface.

13. The wireless client of claim 1 further comprising a module for configuring the apparatus such that said client does not use said apparatus for buffering network information.