4.1. Master Gateway

The MGW is the module to be used by the browser as a local proxy server. As with a generic local proxy server, the MGW relays communications between the browser and the HTTP server and caches the server responses. In addition to this basic functionality, it also distinguishes the transactions that are taking place. This is done based on the request URI after stripping it of the query parameters. Each of the transactions is assigned a defined state. The state assigned to a transaction is checked when the browser sends a request. Subsequent behavior of the MGW depends on the state of each of the transactions. The four states and their corresponding actions are as follows:

• Ajax Communication Detection State AJAX_DET:

In the initial state, AJAX_DET, the MGW scans the communications between the browser and the HTTP server and detects those that are done by Ajax applications. This is done by finding JSON objects (packages of data often used with Ajax applications) in the HTTP server’s response messages. The MGW finds JSON objects by checking the Content-Type header in HTTP responses. Once the MGW detects an Ajax communication, the state transitions to UPSTOP_ DET.

• Update Stop Detection State (UPSTOP_DET):

In the UPSTOP_DET, the MGW attempts to detect whether updates at the HTTP server has ceased temporarily. The MGW decides that updates have ceased temporarily when the latest response from the HTTP server is identical to the most recently cached response. Once a temporary cease in communications has been detected, the MGW sends a request message to the SGW (the Surrogate Communication Request Message) that contains both the browser’s request and the server’s response, combined as a multi-part message body. This is the Surrogate Communication Request Message. The state now transitions to RES_WAIT.

• Response Waiting State (RES_WAIT):

In RES_WAIT, the MGW waits for a response from the SGW. Any Ajax requests sent from the browser are responded with cached contents. Completing all communications within the wireless terminal in this way has the effect of practically suspending its communications. Once the SGW responds with a Surrogate Communication Response Message, the cache is overwritten with the newly arrived data. The state now transitions to RESD.

• Surrogate Response Delivery State (RESD):

In RESD, the MGW delivers the Surrogate Communication Response Message to the browser. The message, which is the cache contents that have been overwritten, is delivered in response to requests from the browser. The state transitions back to UPSTOP_DET at this point.

4.2. Slave Gateway

The SGW is the module that receives Surrogate Communication Requests from the MGW and carries out the communications for the wireless terminal; it sends out the request message contained in the Surrogate Communication Request Message periodically to the HTTP server. Consecutive responses from the server are checked to see if they differ from the sample response message contained in the Surrogate Communication Request Message. If in fact the responses do differ, the SGW decides that the remote data has been updated, and pushes the new response (the Surrogate Communication Request Message) to the MGW and terminates communications with the server.

4.3. Method of Content Transmission

For content transmission from the SGW to the MGW, we adopt the long polling method, which is used to achieve pseudo-pushing in pull-based communication systems such as the Web. In long polling, the client initially sends a request to the server. The server, instead of responding instantly, holds the request until a certain event occurs (usually the arrival of newly available data). Once this event occurs, the server sends a response to the client.

In this prototype, the SGW holds the Surrogate Communication Request until it detects data updates at the server.

5. Evaluations

5.1. Evaluation Items

To evaluate the proposed method, we implemented and ran a sample application (described later) in various situations for 10 minutes each and evaluated the following two points.

• The Number of transmissions by the wireless terminal: We compared the number of times the wireless interface was used to send and receive messages.

• Average latency: We compared the average latency of the browser display update since the data update on the server.

5.2. Evaluation Method

We used an application resembling the communication model of an Ajax synchronous application, the chat. This application has the following two front-ends.

1) Sender

The Sender front-end is the one that submits new chat messages. It submits messages at normally distributed random time intervals having an average of μ (msec.) and a standard deviation of 250 (msec.). The requests have two parts to its query parameter. One is a timestamp of the request (the number of milliseconds since January 1st, 1970 at 00:00) that represents the time of submission of the chat message. The other is a sequence of 140 randomly selected Japanese Hiragana characters, encoded in UTF-8, that represents the actual chat message.

2) Receiver

The Receiver front-end is the one that retrieves submitted chat messages. It sends out a request to the HTTP server once every 3 seconds. The request has the timestamp of the request as the query (in the same format as the Sender). The HTTP server responds with chat messages that were submitted later than this timestamp.

5.3. Method of Content Transmission

Table 1 shows the combinations of evaluation conditions,

consisting of μ (the average time intervals between message submissions by the Sender) and T (the time intervals between surrogate communications by the surrogate communication device). T is shown as “n/a” where this method is unnecessary.

5.4. Method of Content Transmission

Specifications of each device used in the evaluation are shown in Tables 2-4. The devices all reside in different networks, and the Sender and Receiver are used on the wireless terminal.

During evaluation, we turned off the wireless device’s HSDPA interface and used its IEEE 802.11 g interface, and limited its throughput to that of HSDPA, which we had measured in advance. This is in consideration of the possibility that the HSDPA interface’s unstable throughput may cause unpredictable effects on evaluation. We used Iperf 1.7.0 [7] with a window size of 32 KB to measure the HSDPA interface’s through put. The limit applied to the IEEE 802.11 g interface is the average of 20 transmissions between the wireless terminal and the HTTP server. The actual values are 80 Kbps upstream and 40 Kbps downstream. We used NEGiES 1.57 [8] to apply the throughput limits.

5.5. Evaluation Procedure

First, the Receiver starts retrieving chat messages. Once the first response from the HTTP server is retrieved, the Sender starts submitting chat messages. Both front-ends are stopped after 10 minutes (counting from the initial message retrieval by the Receiver). The number of transmissions by the wireless terminal and the average latency are then evaluated.

5.6. Evaluation Results

The resulting number of communications and the average latency are shown as follows: cases 1 and 2 in Figures 4 and 5, cases 3 through 5 in Figures 6 and 7, cases 6 through 8 in Figures 8 and 9.

6. Discussion

Let us define the average increase in the wireless terminal’s power consumption, compared to when the terminal’s communications are halted, as

. (1)

Here, W_com is the rate in which power consumption increases or decreases when communicating, compared to when it is not. We set this according to the study by Carroll et al. (cited in Chapter 2) to

(2)

it is the length of time the sample application ran, which is

(3)

t_com is the total length of time (sec) the Receiver used the wireless terminal’s interface to communicate.

Figure 10 shows the values of Equation (1) when applied to the evaluation results for cases 3 through 5. Figure 11 is for cases 6 through 8.

From Figure 11, we can see that the wireless terminal consumed 14% more power when using the sample

application (case 6) and that our proposed method lowered it to 7% (cases 7 and 8). However, in Figure 10, the average power consumption when not using our method is 19% (case 3), which is lower than the 20% when it was used (case 4).

There are two possible reasons for this. One is that the HTTP server’s data update rate (approximately once every 9 seconds) was relatively low for the sync rate (approximately once every 3 seconds). As such, the number of transmissions eliminated was a trivial 14 times. The other is that the size of the Surrogate Communication Request Message (963 bytes) was larger than that of the data update request message in long polling (434 bytes) and the wireless terminal had to communicate for a longer total time.

In summary, the proposed method can reduce power consumption given that data update intervals are sufficiently long compared to the sync interval of the synchronous application. More specifically, we can conclude that our method is effective if the data update intervals are more than 9 times longer than the sync interval.

6.1. Overhead Time

Figure 5 shows that when surrogate communications do not occur (case 2), our method has an increased average overhead time of under 100 ms compared to when our method is not used (case 1), which is acceptable. Figures 7 and 9 show that when surrogate communications do occur (cases 4, 5, 7 and 8), the increased average overhead time can be held down to under 1 second if the intervals of surrogate communications are approximately half of the sync interval.

With the above evaluation results, combined with the fact that synchronous applications do not impose realtime constraints, we conclude that the overhead time introduced by our proposed method does not impair practicality.

6.2. Comparisons with Related Methods

In the method proposed by Ishida et al. [10], the wireless interface on the terminal is set to sleep mode every time a transmission ends. A device called the Wakeup Module is then used in place of the wireless interface to wait for incoming transmission waves and wake up the wireless interface when needed.

In the method proposed by Russel [11], the front-end and the back-end of the Ajax application are modified to adapt long polling (described in Section 4.3) to reduce the communication rate: The HTTP server waits until there is new data available to respond to the browser.

Both of these methods require specific expertise in mobile devices or Web applications if they are to be applied to existing applications. As such, it is difficult if not impossible for the end user to use those methods. In contrast, our method has the advantage of being able to be used by the end user, since it does not require that modifications be made on existing applications.

7. Conclusions

In this study, we proposed a method of off-loading a wireless terminal’s communications to another device in order to tackle the problem of increased power consumption that occurs while using synchronous Ajax applications (applications that synchronize the Web browser’s display with data updates on the server). Our evaluation prototype kept the average increase in power consumption.

We used a networked device as the Surrogate Device in this particular study, but this method could potentially be adapted to wireless base stations and Web servers themselves.

Our method is a valuable contribution in the application software level to the wide social needs [12] of longer battery lives. Because this is a high-level method, we can expect it to be used in conjunction with other low-level technologies in hardware and communications.

8. Acknowledgements

This work was supported by JSPS Grant-in-Aid for Scientific Research KAKENHI (2100084).

REFERENCES