Embed Size (px)
Citation preview
1
Energy-Aware Web Browsing in 3G Based Smartphones
Bo Zhao, Qiang Zheng and Guohong CaoDepartment of Computer Science & Engineering
The Pennsylvania State UniversityE-mail: {bzhao, quz103, gcao}@cse.psu.edu
ABSTRACTSmartphone based web browsing wastes a lot of power whendownloading webpages due to the special characteristics ofthe 3G radio interface. In this paper, we identify these spe-cial characteristics, and address the power consumption is-sues in smartphone web browsing through two novel tech-niques. First, we reorganize the computation sequence ofthe web browser when loading a webpage, so that the webbrowser can first run the computations that will generatenew data transmissions and retrieve these data from the webserver. Then, the web browser can put the 3G radio interfaceinto low power state, release the radio resource, and thenrun the remaining computations. Second, we introduce apractical data mining based method to predict the user read-ing time of webpages, based on which the smartphone canswitch to low power state when the reading time is longerthan a threshold. To demonstrate the effectiveness of ourenergy-aware approaches, we develop a testbed with An-droid phones on T-Mobile UMTS network. Experimental re-sults show that our approach can reduce the power consump-tion of the smartphone by more than 30% during web brows-ing. Moreover, our solution can further reduce the webpageloading time and increase the network capacity.
1. INTRODUCTIONWeb browsing is one of the most important and commonly
used service provided by smartphones. However, the currentsmartphone web browser wastes a lot of power when down-loading webpages. There have been lots of research on opti-mizing the power usage of smartphones [1–4], but they onlyfocus on reducing the power consumption of one componentof the smartphone such as display. Although some of themalso consider the power consumption of the wireless inter-face [5], most of them focus on the WiFi interface whichhas different characteristics from the 3G wireless interfacewhich consumes much more power.
In UMTS 3G networks, multiple timers are used to controlthe radio resource, and the timeout value for releasing the re-source can be more than 15 seconds [6]. Thus, it is possiblethat the wireless radio interface continues to consume a largeamount of power before the timer times out, even when thereis no network traffic. One advantage of this approach is thatit can reduce the latency of next possible data transmissionthat arrives before the timer expires, because the connection
between the smartphone and the backbone network is stillavailable. Otherwise, the backbone network has to allocatethe radio resource again, which will consume more time andpower. As a result, simply adjusting the timer may not be agood solution for saving power.
Due to the limited computation capability, when opening awebpage, current smartphone web browser takes a long timefor downloading and processing all objects (e.g., javascripts)of the webpage. As a result, the data transmissions are dis-tributed along the whole webpage downloading duration, andthen the data rate at any instant time is quite low. The timeinterval between data transmissions is large although it isstill smaller than the time out value. The data transmissionsreset the timers again and again before they expire. Con-sequently, the radio interface is always on and the radio re-source cannot be released, which consumes lots of powerand decreases the network capacity.
In this paper, we address the power consumption issue insmartphone based web browsing through two novel tech-niques. First, we reorganize the computation sequence ofthe web browser when loading a webpage. There are vari-ous computations when loading a webpage such as HTMLparsing, JavaScript code execution, image decoding, styleformatting, page layout, etc. These computations generallybelong to two categories based on whether they will gener-ate new data transmissions from the web server. We wantto separate these two types of computations so that the webbrowser can first run the computations that will generate newdata transmissions and retrieve these data. Then, the webbrowser can put the 3G radio interface into low power state,release the radio resource, and then run the remaining com-putations which may take 40–70% of the processing time forloading webpages [7]. Thus, a significant amount of powerand radio resource can be saved.
The aforementioned technique can be applied to webpageswhich require a long processing time. For webpages thathave short processing time, we propose another novel tech-nique. The idea is to predict the user reading time on thewebpage after it is downloaded. If this time is longer thana threshold, the radio interface can be put into low powerstate. Since smartphones have limited computation capabil-ity, we propose a low overhead prediction algorithm basedon Gradient Boosted Regression Trees (GBRT) [8].
To demonstrate the effectiveness of our energy-aware ap-
2
proaches, we implement a prototype based on Android phoneson T-Mobile UMTS network. We collect real data traces toevaluate our energy-aware approaches. Experimental resultsshow that our approach can reduce the power consumptionof the smartphone by more than 30% during web browsing.Moreover, our solution can reduce the webpage loading timeby 17%, and increase the network capacity by 19.6%. Morespecifically, the contributions of this paper are as follows.
• To the best of our knowledge, we are the first to achievepower saving for web browsing on smartphones by re-organizing the computation sequence of web browser.Moreover, this approach can increase the network ca-pacity without any extra equipment and it does notmodify the communication protocol between the smart-phone and the backbone network.
• The proposed light-weight GBRT prediction methodhas high accuracy and can be used to further save powerduring user reading time.
• We implement the prototype and collect real traces whichare used to validate the effectiveness of the proposedenergy-efficient approaches.
The rest of this paper is organized as follows. Section 2and Section 3 introduce the background and motivation ofour work, respectively. Section 4 presents the two energysaving techniques. Section 5 presents our test-bed and ex-perimental results. Section 6 discusses related work, andSection 7 concludes the paper.
2. BACKGROUNDIn this section, we introduce the background knowledge
related to power consumption of the 3G radio interface andthe design of smartphone web browser.
2.1 Power Consumption of the 3G Radio In-terface
To efficiently utilize the limited radio resource of the back-bone network [9], the 3G Radio Resource Control protocoldefines the following three states for smartphones to controltheir radio interface.
• IDLE state: the smartphone does not have any signal-ing connection with the backbone network, and henceit cannot transmit user data. The radio interface of thesmartphone in IDLE state consumes very little poweras shown in Fig. 1.
• DCH state: the backbone network allocates dedicatedtransmission channels (uplink and downlink) to the smart-phone, so that the smartphone can transmit user dataand signaling information at high speed. This requireshigh level of power as shown in Fig. 1.
• FACH state: smartphone in this state has no dedicatedtransmission channel. Hence, it can only transmit user
0 20 40 60 80 100 120 140 1600
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
Time (x 0.25 second)
Pow
er (
W)
Power PointMean Power
IDLEIDLE
FACH
DCH
Figure 1: The power level of the 3G radio interface onsmartphones at different states.
data and signaling information through common sharedtransmission channels at low speed (up to a few hun-dred bytes/second). As shown in Fig. 1, data transmis-sion in the FACH state requires about half of the powerin the DCH state.
When a smartphone in IDLE wants to transmit user data,it has to switch to DCH by first establishing a signaling con-nection with the backbone network, and then obtaining ded-icated transmission channels. This process requires ten ofcontrol message exchanges between the smartphone and thebackbone network, which takes more than one second.
The backbone network uses a timer to determine whento release the dedicated transmission channels allocated tothe smartphone. The timer (T1) is usually set to 4 seconds.The backbone network triggers T1 when each data transmis-sion is complete and resets it whenever a new data transmis-sion happens before it expires. When T1 expires, the dedi-cated transmission channels allocated to the smartphone arereleased, and the smartphone switches to FACH [10].
After the smartphone switches to FACH, the backbonenetwork triggers another timer T2 to determine when to re-lease the signaling connection, which is usually set to 15seconds [6]. Before T2 expires, the signaling connectionbetween the smartphone and the backbone network still ex-ists. If the backbone network or the smartphone needs totransmit user data, the backbone network allocates dedicatedtransmission channels to the smartphone and the smartphoneswitches to DCH. Since the signaling connection still ex-ists, the latency of switching the smartphone from FACH toDCH is smaller than that of switching it from IDLE to DCH.When T2 expires, the signaling connection is released andthe smartphone enters IDLE [11].
2.2 Web Browser DesignToday’s web browser is more complex since it has to process
various script code such as JavaScript embedded in HTMLdocuments. Further, it has to process Cascading Style Sheets(CSS), which is used to describe the presentation semanticsand the style rules of a webpage such as layout, color andfonts. Document Object Model (DOM) is an interface thatallows programs and scripts to update the content, structure
3
and style of HTML documents. After the HTML code hasbeen parsed, the nodes in the DOM tree store the HTMLdata. After the CSS code has been parsed, the style and lay-out properties are assigned to these nodes in the DOM tree.Then the web browser can display them on the screen.
Style
Formatting
Layout
CalculationRenderingDisplay
Javascript
execution
Parsing data
Reqeust html,
images, css, scripts
scripts
Add
html
body
…
… …...Web server
Figure 2: The workflow of webpage processing in smart-phone based web browser.
After the web browser gets the main HTML page, thedata transmission mainly comes from three kinds of sources:HTML, JavaScript, and CSS. In HTML and CSS, contentobjects such as HTML files, JavaScript files, images, andflashes, are referenced by URLs. Hence, the web browserneeds to fetch and add them to the DOM tree. For JavaScriptcode, it is either transformed to HTML code and then fetchescontent objects, or it can directly get content objects from theweb server.
Fig. 2 shows a simplified workflow of webpage processingin smartphone web browsers. Loading HTML page triggersa set of events. First, the HTML code is parsed. If there isJavaScript code, it is delivered to the interpreter engine toprocess. If it includes URLs for objects like images, htmlfiles, and flashes, these objects are requested. Each objectis added to the DOM tree as a node. Next, to provide bet-ter user experience, the web browser processes the layoutinformation such as image decoding, style formatting, pagelayout calculation, and page rendering. Then it can drawa partially rendered display on the screen before finishingloading the whole webpage [7].
As shown in Fig. 2, in current smartphone web browser,there are two types of computations associated with each in-coming object. The first type is the computation that gen-erates new data transmissions such as HTML and CSS fileparsing and JavaScript code execution, which is referred toas the data transmission computation. The second type is thecomputation that does not cause data transmission. This typeof computation is used to lay out the webpage such as imagedecoding, style formatting, page layout calculation and pagerendering, which is referred to as the layout computation.
3. MOTIVATIONIn this section, we introduce how to save power for smart-
phones in the DCH state and FACH state, respectively.
1 2 3 4 5 6 7 8 9 10 11 12 14 16 18 20 22 24−4
−2
0
2
4
6
8
10
12
14
16
18
20
Transmission Interval (seconds)
Pow
er C
onsu
mpt
ion
(J)
OriginalIntuitivePower Saving = Original − Intuitive
Figure 3: The power consumption with different trans-mission intervals.
10 20 30 40 50 60 70 80 900
10
20
30
40
50
60
70
Time (0.5 second)
Dat
a T
raffi
c (K
B)
Open espn.go.com/sportsDownload 760 KB
Figure 4: The traffic load of web browsing and datadownloading
3.1 Power Saving in the DCH StateSince smartphone in the DCH state consumes much more
power than in IDLE, an intuitive approach for saving poweris to switch the smartphone from DCH to IDLE immedi-ately after each data transmission. However, this approachdoes not work if the next data transmission happens quickly.First, reestablishing the signaling connection and switchingthe smartphone from IDLE to DCH needs to consume power.The power consumed in these two steps may be more thanthe power saved by switching to IDLE, if the time inter-val between the two data transmissions is short. Second,reestablishing the signaling connection increases the delayof data transmission, and then it affects the user experienceof web browsing.
We measure the delay and power consumption of this in-tuitive approach through a simple experiment. We send 1 KBdata from an Android smartphone to a remote server. Afterreceiving 1 KB data through 3G network, the smartphoneimmediately switches to IDLE until another data transmis-sion. This approach causes about 1.75 seconds extra delaycompared with the original approach. We also measure thepower saving of this intuitive approach with different datatransmission intervals, which is shown in Fig. 3. This intu-itive approach can save power only when the data transmis-sion interval is larger than 9 seconds. Otherwise, it con-sumes more power than the original approach. For mostwebpages, the data transmission interval during webpage
4
loading is smaller than 4 seconds. As a result, this intuitiveapproach consumes more power.
Although the web browser takes a long time to get theobjects of a webpage, the data transmissions are distributedalong the whole webpage loading time and the traffic rate isquite low. Fig. 4 shows the traffic load of opening webpageespn.go.com/sports/, where the smartphone web browsertakes 47 seconds to download all 760 KB data. The datais downloaded through several data transmissions which arespread along the whole webpage loading time. We open asocket client to download the same amount of data (760 KB),and it only takes 8 seconds as shown in the figure.
If we can group all data transmissions together, the objectsof a webpage can be downloaded in a shorter time. Then, wecan switch the smartphone from DCH to FACH (and then toIDLE), because there will be no data transmission for thecurrent webpage. Hence, power can be saved via reducingthe time in the DCH state. Since the smartphone switchesto FACH earlier, the backbone network can allocate the re-leased dedicated transmission channels to other smartphonesand thus increase the network capacity.
The major challenge is to separate data transmission com-putation and layout computation in the web browser, anddownload the objects as early as possible. We will addressthese issues in Section 4.1.
3.2 Power Saving in the FACH StateAs introduced in Section 2.1, timer T2 controls how long
the smartphone stays in the FACH state, which is usually 15seconds. Since most users spend more than 20 seconds onreading downloaded webpages without any data transmis-sion for 80% webpages [12], keeping smartphone in FACHonly wastes power. Thus, we should switch the smartphonefrom FACH to IDLE to save power.
Our approach for power saving in the FACH state is basedon predicting the webpage reading time. If the reading timeis larger than a threshold, the smartphone will switch fromFACH to IDLE. Since smartphone has limited computationcapability, we cannot use complex prediction algorithms, andwe will introduce our prediction algorithm in Section 4.3.
4. SYSTEM DESIGNIn this section, we first introduce how to reorganize the
computation sequence to get all data from the web serveras fast as possible. Then, we introduce a low-overhead ap-proach to display the partly downloaded data to improve userexperience. Finally, we introduce a practical data miningbased method to predict the user reading time of webpageson smartphones, based on which the smartphone can switchto IDLE to save power when the reading time is longer thana threshold.
4.1 Reorganizing the Computation SequenceWe reorganize the computation sequence of the web browser
to retrieve all data in the webpage as fast as possible. In the
Data transmission
computation
Layout computation
:
:
Time slot 1 Time slot 2 Time slot 3
… …
… …
Original web
browser
Our approach
:
:
Figure 5: The computation sequence for opening web-page and building the DOM tree
original web browser design, the data transmission compu-tation and the layout computation are mixed, as shown inFig. 2. In this subsection, we explain how to separate themto save power.
Fig. 5 compares the computation sequence of our energy-aware approach with that of the original web browser foropening a webpage. At time slot 1, the original web browserspends its computation resource on both data transmissionand layout computation. It processes one object and adds itto the DOM tree. In our approach, the browser focuses ondata transmission and ignores layout. Thus, our approachcan process more objects and add them to the DOM tree attime slot 1. At time slot 2, our approach processes all theobjects and builds the complete DOM tree. At time slot 3,no data transmission will happen, and our approach focuseson computing the page layout. Although the original webbrowser can display partial webpage content on the screenat each time slot, it keeps generating data transmission untiltime slot 3. Finally, both approaches have the same com-plete DOM tree and display the same webpage although ourapproach may be a little bit faster in practice.
Next, we describe how to separate different type of ob-jects in detail. For the computation to process HTML files,we scan them to fetch the objects (images, JavaScript files,flashes, and CSS files) referred by URLs. If the JavaScriptand HTML files do not request any object, the data transmis-sion is finished immediately after downloading them. Next,the HTML files are parsed to build the DOM tree for gram-mar correction, because the JavaScript code may use theHTML element in the DOM tree when being processed bythe interpreter engine.
For the computation to process CSS code and files, weonly scan them to fetch the objects (images and CSS files)referred by URLs, but do not parse them. Thus, the webbrowser does not spend any computation on parsing themand generating the style rules. Image files and other mul-timedia objects can be saved in memory instead of beingdelivered to the web browser. Hence, the web browser doesnot spend any computation time on decoding the multimediaobjects.
Separating the computation for JavaScript files or the Java-Script code in HTML file is the most difficult task. Gener-ally, JavaScript codes are distributed in several JavaScriptfiles and HTML files. Since they are executed in global con-
5
text, we have to run them in sequence to check if they willgenerate data transmission or not. Besides, JavaScript codesare much more complex than HTML or CSS codes, and thereis no simple approach to find out if they will generate newdata transmission without executing them.
After all the HTML and JavaScript are processed, and allthe CSS files are scanned, all data transmission computa-tions are done. Next, we process the layout computation(e.g., image decoding, CSS files processing, style format-ting, layout calculation, and rendering) which does not causedata transmission.
4.2 Intermediate DisplayTo improve user experience, original web browsers al-
ways draw intermediate display and update it frequently whenloading webpages. However, this approach has two disad-vantages. First, although the web browser already has theweb content, it has to wait before displaying the intermedi-ate results. This is because the browser needs to associateDOM nodes and CSS style rules to lay out these data. How-ever, since the CSS file is large and complex, it takes a lot ofprocessing time to extract the rules [7]. Another disadvan-tage is that the browser wastes a lot of computation resourceto frequently redraw and reflow the intermediate display be-fore the final display [13].
A redraw occurs when updates to DOM nodes will changevisibility, but will not affect its layout. Examples includechanging the background color, or the visibility style. Re-draw is expensive, since it requires the browser to searchthrough all nodes in the DOM tree to determine what shouldbe displayed. A reflow occurs whenever the DOM tree ischanged. Reflow of a node causes the subsequent reflow ofits child and parent nodes in the DOM tree, and the new lay-out of these nodes will be recalculated. Finally, everythingis redrawn. Therefore, a reflow costs more computation re-sources because it involves changes that affect the layout ofthe whole page.
By reorganizing the computation sequence, our approachdraws the final display at the end of webpage loading, andthus it saves the computation on redrawing or reflowing in-termediate display. To improve user experience, we presenta low-overhead approach to draw intermediate display withlittle layout computation during the data transmission time.When the browser begins to open a webpage, it first down-loads the webpage which has a lot of text content and thebasic html format information. After parsing 1/3 webpagecontent, we can draw a simplified intermediate display. Be-cause this display does not need CSS rules, style format orimages, it only costs little layout computation. In addition,since it does not need to wait for any information from theCSS files, it can be displayed much earlier than the originalweb browser. Moreover, because the interval between thefirst intermediate display and the final display is only around10 ∼ 20 seconds, we do not update the intermediate displayduring the loading time to avoid unnecessary computation on
redraw and reflow. For webpages with mobile version, sincethe interval is very short (1 ∼ 2 seconds) between interme-diate display and final display, our approach only draws thefinal display.
4.3 Predicting the Reading TimeIn this subsection, we present a machine learning based
approach to predict the user reading time, based on whichwe can decide if the smartphone should switch to IDLE.
4.3.1 Gradient Boosted Regression TreesGradient Boosted Regression Tree (GBRT) [8] is a tech-
nique of predictive data mining, which is used for construct-ing statistical decision tree models from historical data. De-cision tree is a decision support tool that uses a tree-likegraph or model of decisions and their possible consequences.These models are used to predict the value of future data. Inthe “predictive learning” problem, one has a system consist-ing of a “output” variable y and a set of “input” variablesx = {x1, · · · , xn}. Using a “training” sample {yi,xi}N
1
of known (y,x) values, the goal is to obtain an estimate orapproximation F (x) of the function F ∗(x) mapping x to y,which minimizes the expected value of some specified lossfunction L(y, F (x)) over the joint distribution of all (y,x)values.
F ∗(x) = arg minF
Ey,xL(y, F (x)) (1)
= arg minF
Ex[Ey(L(y, F (x)))|x] (2)
The GBRT method assumes a real-valued y and seeks anapproximation F (x) in the form of a weighted sum of func-tions hi(x) from some class H called based learners:
F (x) =M∑
i=1
βihi(x) (3)
Gradient Boosting: In accordance with the empirical riskminimization principle, the method tries to find an approx-imation F (x) that minimizes the average value of the lossfunction on the training set. This is achieved by starting witha model consisting of a constant function F0(x) and then in-crementally expanding it in a greedy fashion as follows.
F0(x) = arg minβ
n∑
i=1
L(yi, β) (4)
Fm(x) = Fm−1(x) + βmhm(x) (5)
βm = arg minβ
n∑
i=1
L(yi, Fm−1(xi) + βhm(xi)) (6)
Where F is restricted to be a function from the class H ofbase learner functions. Eq.(4) and Eq.(5) are called “gradientboosting”.
Gradient Tree Boosting:Here we consider the special case where each base learner
is a J-terminal node decision tree. Each decision tree model
6
Table 1: Feature DetailsFeature DescriptionReading Time The duration from the webpage is
completely opened to the time when theuser clicks to open another webpage.
Transmission Time Data transmission timeWebpage Size The data size of the webpage
without considering the figures (KB)Download Objects The number of total downloaded objectsDownload JavaScript files The number of downloaded
JavaScript filesDownload Figures The number of downloaded figuresFigure Size Size of the total downloaded figures
(KB)JavaScript Running Time The time for processing
all the JavaScript codeSecond URL The number of secondary URLsPage Height The height of the webpagePage Width The width of the webpage
itself has the additive form:
h(x; {bj , Rj}J1 ) =
J∑
j=1
bj1(x ∈ Rj) (7)
Here {Rj}J1 represents disjoint regions that collectively
cover the space of all joint values of the predictor variablesx. These regions are represented by the terminal nodes ofthe corresponding decision tree. The indicator function 1(.)has value one if its argument is true, and zero otherwise. The“parameters” of this base learner Eq.( 7) are the coefficients{bj}J
1 , and the quantities that define the boundaries of theregions {Rj}J
1 . These are the splitting variables, and thevalues of those variables, that represent the splits at the non-terminal nodes of the decision tree. Because the regions aredisjoint, Eq.(7) is equivalent to the prediction rule: if x ∈ Rj
then h(x) = bj . Then for a decision tree:
Fm(x) = Fm−1(x) + βm
J∑
j=1
bjm1(x ∈ Rjm) (8)
Here {Rjm}J1 are the regions defined by the terminal nodes
of the decision tree at the mth iteration. They are constructedto predict {yi}N
1 by least squares. {bjm} presents the corre-sponding least-square coefficient. m is the number of deci-sion trees. J is the number of terminal nodes in each deci-sion tree.
4.3.2 Setup the Trace Collection ProgramWe modify the Android web browser to collect 10 features
of the webpage when opening it, which are listed in Table 1.We use feature “Reading Time” to verify the accuracy ofoutput y from GBRT and use the remaining features as inputpredictors x = {x1, · · · , x10} to the GBRT.
4.3.3 Training the ModelTo train the model, we use square error as the employed
loss functions L(y, F ) = (y−F )2. This leads to the follow-ing generic Algorithm 1.
Due to the high computation overhead, the model is trainedeither offline on a PC or on the smartphone when it is con-
Algorithm 1 : Regression Tree BoostGet the input training set (xi, yi)
ni=1
Number of iteration M .Initialize the model with a constant value:F0(x) = median{yi}N
1
for m = 1 to M doyi = −
[∂L(yi,Fm−1(xi))
∂Fm−1(xi)
]F (x)=Fm−1(x)
, i = 1, . . . , N
{Rjm}J1 = J − terminalnodetree({yi,xi}N
1 )γjm = arg minγ
∑xi∈Rjm
L(yi, Fm−1(xi) + γ)
Fm(x) = Fm−1(x) +∑J
j=1 γjm1(x ∈ Rjm)end for
nected to a power source. Then, we deploy the tree modelto the prediction program which is embedded in the webbrowser program. When the web browser finishes parsing awebpage, this program will put feature data x = {x1, · · · , x10}to the tree model to predict the reading time. Since the modelis composed of decision trees, the prediction workload isvery low and it can be run on mobile devices. In addition,we do not need to frequently update the tree model, becausethe user behavior of web browsing generally does not changetoo much.
4.3.4 Interest ThresholdBased on our collected traces (details in Section 5.1.3),
the reading time of a webpage is related to both webpagefeatures and user interests in the webpage. For example, sup-pose that two news webpages have similar features listed inTable 1. One is about games and the other is about finance.A user may spend more time on the webpage about games ifhe has more interests in game than finance.
To match the user interest, we need to parse the content ofa webpage when opening it to collect the word frequencyand classify the content based on keywords like “game”,“finance”, and “weather”. Parsing the content and classify-ing webpages will consume too much power on computationlimited smartphones.
Instead of parsing the webpage content, we use a prede-fined interest threshold for prediction. If the reading timeof a webpage is larger than the interest threshold, it meansthat the user is interested in this webpage. To improve theprediction accuracy, we only predict the reading time of thewebpages that the user is interested in. After a webpage isopened, we will wait until the reading time is larger than theinterest threshold. Then we can predict and decide if thesmartphone should switch to IDLE. In Section 5, we willdescribe how to set the interest threshold in detail.
4.3.5 Our Energy-Aware ApproachIn this subsection, we present our energy-aware approach
as shown in Algorithm 2. The algorithm has two differentmodes: the delay driven mode which optimizes delay, andthe power driven mode which optimizes power. Recall thatimproperly moving to the IDLE state may increase the power
7
Table 2: Parameter Description
Parameters DescriptionTr Predicted reading time (sec)α Interest threshold (sec)Td Time duration threshold (T1 + T2) for delay driven modeTp Time duration threshold for power driven modeMode Power driven or delay driven
consumption and the data transmission delay as explainedin Section 3. In delay driven mode, if the predicted read-ing time (Tr) is shorter than Td, new data transmission maycome during the FACH state, and hence the smartphone willnot go to IDLE to avoid increasing the data transmission de-lay. Here we set Td to 20 seconds which is T1 +T2. In powerdriven mode, as long as the predicted reading time is longerthan Tp, the smartphone will go to IDLE to save power al-though it may increase the transmission delay in some cases.As shown in Figure 3, Tp = 9 seconds. Table 2 lists the pa-rameters used in Algorithm 2.
Algorithm 2 : Energy-Aware ApproachBegin to open a webpageData transmission computation is done.Layout computation is finishedCollect features x = {x1, · · · , x10}Webpage is openedWait for α seconds.Get Tr from the prediction model with xif (Tr > Td) OR (Tr > Tp AND mode == power) then
switch to IDLE stateend if
4.4 State SwitchThe state switch component is used to switch the state of
the smartphone from FACH to IDLE. This can be easily im-plemented if the source code of the radio firmware interfaceis available to the developers. However, in Android smart-phone the source code of the radio firmware is not available,although the source codes of the applications, framework,and OS are open. Android only provides some interfacesto access the radio firmware through the 3G wireless radiointerface called Radio Interface Layer (RIL).
We implement state switch functions at the applicationlayer through RIL. To access radio firmware, the applicationsends a message which is an abstract description of an oper-ation to be performed, to the RIL.java file in the applicationframework. Based on the received message, RIL.java sendsanother message to RIL through a Unix socket connection.Then RIL operates on radio firmware to release the signalingconnection and switch the smartphone to IDLE.
5. PERFORMANCE EVALUATIONIn this section, we first describe our experiment setup,
and then evaluate the delay and power consumption of webbrowsing.
5.1 The Experimental Setup
Figure 6: The experimental setup to measure the powerconsumption of the smartphone
5.1.1 The Experimental EquipmentWe use Android Dev Phone 2 with Android OS version
1.6 connecting with the T-Mobile 3G UMTS network as thetestbed. Fig. 6 shows the experimental setup. To accu-rately measure the power consumption of the smartphone,we use Agilent E3631A Power Supply to provide the currentwith constant voltage (3.706 V) to the smartphone insteadof using the battery. The Agilent E3631A connects to ourlaptop through the “NI GPIB-USB-HS” cable. We installLabVIEW on the laptop, and use it to program the AgilentE3631A to capture the current of the smartphone every 0.25second. Then, we can easily calculate the power consump-tion of the smartphone. We modify the Android browserto reorganize the data transmission computation and layoutcomputation. In addition, we collect the 10 features listed inTable 1 when a webpage is opened.
5.1.2 Benchmark WebpagesWe use the most popular webpages from Alexa website
[14] as the benchmark. Most webpages of these popularwebsites have mobile version for smartphones, while theirsubpages (lower level webpages) are full versions to showvarious content. Thus, we separate the benchmark into twoparts: the mobile version benchmark and the full versionbenchmark. The mobile version benchmark consists of themobile version of the top popular webpages. Some mobileversion webpages have the corresponding full versions thatcan be displayed on smartphone, such as www.amazon.com.We add them to the full version benchmark. If a mobile ver-sion webpage does not have its full version, one of its sub-page with full version is added to the full version benchmark.If none of its subpage has full version, some other top popu-lar webpage which has full version is added. Table 3 lists allthe webpages in the benchmark.
5.1.3 Experimental DataWe collect data traces with our prototype and use them
to evaluate the accuracy of our prediction approach. Thedata trace describes the reading time and key features of web
8
Table 3: Benchmark WebpagesMobile version Full versioncnn edition.cnn.com/WORLD/ebay www.motors.ebay.comespn.go.com espn.go.com/sportsamazon amazon full versionmsn home.autos.msn.commyspace www.myspace.com/musicbbc.co.uk bbc.com/travelaol www.popeater.com/celebrities/nytime www.apple.comyoutube hotjobs.yahoo.com
0 2 4 6 8 10 12 14 16 18 200
10
20
30
40
50
60
70
Reading Time (sec)
Cum
ulat
ive
Dis
trib
utio
n (%
)
Figure 7: The cumulative distribution of the reading timeof all the user data.
browsing on 3G based smartphone. We distribute smart-phones to 40 students and collect their web access history.Each data trace has at least 2 hours of web browsing activ-ities. It is organized into sessions, each of which lists thefeatures of webpages. We calculate the reading time of eachwebpage based on the visiting time of consecutive webpageswithin a session. Webpages with reading time larger than 10minutes are discarded, because we are not sure if the user isstill reading the webpage after such a long time period.
The distribution of the reading time affects if our approachcan be applied to a large range of webpages. Fig. 7 showsthe cumulative distribution of the reading time of all userdata. The reading time of 53% webpages is smaller than Tp
(9 seconds), which means that we can save power by puttingthe smartphone into IDLE for 47% webpages but with somedelay penalty. The reading time of 68% webpages is smallerthan Td (20 seconds), which means that we can save powerby putting the smartphone into IDLE for 32% webpageswithout any delay penalty.
The reading time of 30% webpages is less than 2 seconds,so we set the interest threshold (α) to 2 seconds, which maybe different for other data sets. By using interest threshold,we do not need to predict the reading time of these 30%webpages since the user will ask for other webpages withinthe interest threshold (α). Therefore, we exclude them fromthe data set used for training the prediction model.
We calculate the Pearson’s correlation coefficient betweenreading time and 10 features of the webpages, and show theresults in Table 4. As can be seen, there is no notable correla-tion between the reading time and the 10 webpage features,which indicates why we cannot use simple linear models forprediction.
Original Energy−Aware Original Energy−Aware 0
5
10
15
20
25
30
35
40
Mobile version benchmark Full version benchmark
Tim
e (s
econ
ds)
Data transmission timeLayout computation time
Save2.5%
Save17%
Save15%
Save27%
(a) Average
Original Energy−Aware Original Energy−Aware0
5
10
15
20
25
30
m.cnn.com www.motors.ebay.com
Tim
e (s
econ
ds)
Data transmission timeLayout computation time
Save2.2%
Save20%
Save15%
Save31%
(b) Two popular webpages
Figure 8: The data transmission time
5.2 Data Transmission TimeDuring data transmission, the radio interface cannot be
put into IDLE. Thus, the data transmission time is related topower consumption. In the original web browsing approach,data transmission computation and layout computation aremixed, and hence the data transmission time is the webpageloading time. In our energy-aware approach, these two com-putations are separated and then the webpage loading timeincludes the data transmission time and the layout computa-tion time.
Fig. 8(a) shows the data transmission time based on themobile version benchmark and the full version benchmark.On the full version benchmark, our approach reduces thedata transmission time by 27%. Even after adding the lay-out computation time, the total loading time of our approachis still 17% less than the original approach. This is becausethe original web browser redraws and reflows intermediatedisplay frequently when loading webpages. Our approachonly draws a simple intermediate display, and lays out thefinal display. Since our approach does not have the compu-tation extensive redraws and reflows, our approach can loadthe webpages faster.
For the mobile version benchmark, our approach reducesthe data transmission time by 15%. Since most mobile ver-sion webpages are quite simple, the layout computation timeis also very small. Since the original web browser draws theintermediate display of mobile version webpages close tothe end of loading time, it does not spend too much computa-tion on redraw and reflow. Therefore, after adding the layoutcomputation time, the total loading time of our approach isonly 2.5% less than the original approach for mobile versionbenchmark.
We select two popular webpages from the benchmark tofurther investigate the data transmission time and the web-page loading time. m.cnn.com is selected to represent themobile version and www.motors.ebay.com is selected torepresent the full version webpage. As shown in Fig. 8(b),the general trend is similar to Fig. 8(a). Our approach canreduce the data transmission time by about 30% for www.motors.ebay.com and 15% for m.cnn.com.
5.3 Power ConsumptionTable 5 lists the power consumption of the smartphone
at different states. The power is measured at the smart-
9
Table 4: Pearson’s correlation coefficient between reading time and 10 featuresTransmission time Page Size Objects Javascript Num Figures Num Figure Size Javascript Time Second URL Height Width0.0009 0.059 0.023 0.042 0.013 0.015 0.021 0.038 0.067 0.016
0 25 50 75 100 125 150 175 200 225 2500
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
1.8
2
Time (x 0.25 second)
Pow
er (
W)
Power to open espn.go.com/sports by OriginalPower to open espn.go.com/sports by Energy−Aware
Figure 9: The power consumption for loading the ESPNsports webpage
Table 5: The power consumption of the smartphone atdifferent states (which includes display and system main-taining power)
Power (W)IDLE state 0.15FACH state 0.63DCH state without transmission 1.15DCH state with transmission 1.25Fully running CPU (IDLE state) 0.6
phone, which includes the display and system maintainingpower. As can be seen, data transmission consumes thelargest amount of power. When the smartphone stays inFACH, it consumes the same amount of power as fully run-ning CPU at IDLE state. When the smartphone is in IDLE,the power is mainly used for screen displaying and systemmaintaining. Since our energy-aware approach reduces thetime at FACH and DCH states, it can save much power forweb browsing.
Fig. 9 compares the power consumption of the originalapproach and our energy-aware approach when loading awebpage espn.go.com/sports. As can be seen, the orig-inal approach and our approach finish data transmission attime 130 and 100, respectively. Our approach switches thesmartphone from FACH state to IDLE at time 110 and thenthe smartphone consumes very little power. On the otherhand, the original web browser keeps consuming about 0.6W power in FACH for 20 seconds (time 150 ∼ 230).
Suppose the reading time is larger than 20 seconds, in the
Original Energy−Aware Original Energy−Aware0
10
20
30
40
50
60
Mobile version benchmark Full version benchmark
Pow
er C
ost (
J)
Opening the webpage20 seconds reading time
Save35.7%
Save30.8%
(a) Average
Original Energy−Aware Original Energy−Aware0
10
20
30
40
50
60
m.cnn.com espn.go.com/sports
Pow
er C
ost (
J)
Opening the webpage20 seconds reading time
Save35.5%
Save43.6%
(b) Two popular webpages
Figure 10: The power consumption
300 350 400 450 500 550 600 650 7000
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
Number of users
Ses
sion
dro
ppin
g pr
obab
ility
(%
)
OriginalEnergy−Aware
(a) Mobile version benchmark
200 220 240 260 280 300 320 340 3600
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
Number of users
Ses
sion
dro
ppin
g pr
obab
ility
(%
)
OriginalEnergy−Aware
(b) Full version benchmark
Figure 11: The capacity increaseoriginal approach, the smartphone will stay in FACH for 20seconds. As shown in Fig. 10(a), with mobile version bench-mark, our approach can reduce the power consumption by35.7%. Most of this power saving comes from putting thesmartphone into IDLE during the reading time. With fullversion benchmark, our approach can reduce the power con-sumption by 30.9%. Different from the mobile version, mostof this power saving comes from reducing the data transmis-sion, which is achieved by separating the data transmissioncomputation and layout computation.
We also evaluate the power saving with two web sites:the mobile version of m.cnn.com and the full version ofespn.go.com/sports. As shown in Fig. 10(b), the generaltrend is similar to Fig. 10(a). Our approach reduces thepower consumption by 35.5% for m.cnn.com, and reducesthe power consumption by 43.6% for espn.go.com/sports.
5.4 Network CapacityWhen a user sets up a data session, the backbone net-
work allocates a pair of dedicated transmission channels tothe smartphone for downlink and uplink data transmission,and then the smartphone enters the DCH state. Normally,the allocated transmission channels will be released after thesmartphone leaves DCH. Due to the limited number of trans-mission channels, the backbone network may not alwayshave dedicated transmission channels for a user’s data ses-sion. If such case occurs, the data session has to be dropped.
Suppose there are N pairs of dedicated transmission chan-nels. The problem can be modeled as a M/G/N multi-serverqueue, with the service queue size of 0. We develop a pro-gram to simulate the M/G/N multi-server queue, and illus-trate how our energy-aware approach can improve the net-work capacity. We simplify the model to focus on web brows-ing. The service time for a session is equal to the data trans-mission time for opening a webpage. The backbone networkhas 200 pairs of dedicated transmission channels (N = 200).The capacity is the number of users that the network can sup-port with certain quality of service (session dropping proba-bility) during some time (4 hours in this experiment), assum-ing that all users are browsing Web and each user generatesdata transmission sessions with Poisson distribution intervalλ = 25 seconds.
On the mobile version benchmark, Fig. 11(a) shows that
10
(a) Original takes 17.6 seconds (b) Energy-Aware takes 7 sec-onds
Figure 12: The intermediate display of espn.go.com/sports
(a) Original takes 34.5 seconds (b) Energy-Aware takes 28.6seconds
Figure 13: The final display of espn.go.com/sports
to achieve the same session dropping probability, our ap-proach can support 14.3% more users, because our approachcan reduce the data transmission time by 15% as shown inFig. 8(a). For the full version benchmark, Fig. 11(b) showsthat our approach can support 19.6% more users, since ourapproach can save 27% data transmission time.
5.5 User experienceTo evaluate the user experience, we take a snapshot of the
smartphone web browser when opening a web page espn.go.com/sports. As shown in Fig. 12, our intermediate dis-play has as much content as the original, but the display inour approach is about 10.6 seconds earlier than the originalapproach. Although the screen layout of our approach is notas good as the original approach, we can still read the con-tent, and more importantly our approach is much faster. Thefinal screen layout of both approaches will be the same, withour approach 5.9 seconds faster as shown in Fig. 13.
Fig. 14 shows the screen layout time for both approaches.For full version webpages, our approach reduces the inter-mediate screen layout time by 45.5%, and reduces the finalscreen layout time by 16.8%. As explained before, this is be-
cause our approach does not have the frequent redraws andreflows. For mobile version, our approach does not draw in-termediate display, but the final layout is drawn almost at thesame time when the original approach draws its intermediatedisplay.
5.6 Predicting the reading timeIn this section, we evaluate the performance of our predic-
tion approach based on the collected data trace presented inSection 5.1.3. We first measure the prediction accuracy, andthen measure the effects of prediction on power saving anddelay. Finally, we measure the computation cost of predic-tion.
5.6.1 Prediction AccuracyIf the predicted reading time and the real reading time are
both larger or smaller than a given value (Td or Tp), the pre-diction is correct. Otherwise, it is wrong. The predictionaccuracy is defined as the percentage of correct cases overall cases. In this section, we show how the interest thresholdcan improve the prediction accuracy.
We evaluate the accuracy with two threshold values, Tp =9 seconds and Td = 20 seconds. As explained in Section 3,our approach saves power only when the reading time islarger than Tp, and does not cause any delay penalty whenthe reading time is larger than Td.
To get the prediction accuracy without considering the in-terest threshold, we train the prediction model with the orig-inal trace. To get the prediction accuracy considering the in-terest threshold, we train the prediction model with the dataset excluding the 2 second trace data. Fig. 15 shows thatusing interest threshold can increase the prediction accuracyby at least 10%.
5.6.2 The effects of prediction on power saving anddelay
In this subsection, we study the effects of prediction onpower saving and delay. We consider 6 cases shown in Ta-ble 6. To achieve 100% prediction accuracy, we directly usethe reading time from the trace (in Accurate-9 and Accurate-20) which shows the performance upper bound that the pre-diction algorithm can achieve. Since our energy-efficient ap-proach can be power driven or delay driven, there are twothresholds: Td = 9 seconds for power driven approach andTd = 20 seconds for delay driven approach. We also com-pare different prediction approaches to the Always-off ap-proach. In the Original Always-off approach, the smart-phone switches to IDLE after the webpage is opened. In theEnergy-Aware Always-off approach, our approach is usedwhere the computation sequence is reorganized in the webbrowser.
Fig. 16 compares the original web browsing approach withthese 6 approaches. As can be seen, the Original Always-offapproach increases the delay (1.47%) instead of saving thedelay, since it increases the delay penalty for all webpageswhose reading time is less than 20 seconds. Although the
11
Original Energy−Aware Original Energy−Aware0
5
10
15
20
25
30
35
Mobile version benchmark Full version benchmark
Tim
e (s
econ
ds)
First display timeFinal display time
Save16.8%
Save 45.5%
Figure 14: The average screen dis-play time
0
10
20
30
40
50
60
70
80
90
100
Tp = 9 T
d = 20
Pre
dict
ion
Acc
urac
y (%
)
Without interest thresholdWith interest threshold
Figure 15: The prediction accuracywith and without interest threshold
Accurate−9 Predict−9 Accurate−20 Predict−20−3
0
3
6
9
12
15
18
21
24
27
30
Per
cent
age
(%)
Power savingDelay saving
OriginalAlways Off
Energy−AwareAlways Off
Figure 16: The power and delay savingof six cases
Table 6: The condition for switching to IDLECase DescriptionOriginal After the webpage is opened by the originalAlways-off web browserEnergy-aware After the webpage is opened in our approachAlways-off where the computation sequence is reorganizedAccurate-9 The reading time in the user trace is longer than
Tp = 9 seconds in our approachPredict-9 The predicted reading time is longer than
Tp = 9 seconds in our approachAccurate-20 The reading time in the user trace is longer than
Td = 20 seconds in our approachPredict-20 The predicted reading time is longer than
Td = 20 seconds in our approach
Energy-Aware Always-off approach also increases the delaypenalty, it saves more delay during webpage loading timewith our approach. Overall, it saves the least amount of de-lay (9.2%) among all our approaches. The Original Always-off approach saves the least amount of power, since it onlysaves power during the reading time. Other approaches arebased on our approach, which also save power during thewebpage loading time.
From the figure, we can also see that Accurate-20 savesthe most amount of delay (13.6%). Accurate-9 saves themost amount of power (26.1%), since it only switches stateswhen it can save power. Basically, there is a tradeoff be-tween power and delay, and Accurate-20 optimizes delaywhile Accurate-9 optimizes power. Since our prediction can-not achieve 100% accuracy, the performance of Predict-20is a little bit less than Accurate-20, and the performance ofPredict-9 is a little bit less than Accurate-9.
5.6.3 Computational CostWe also study the computational cost of the prediction al-
gorithm. We measure the power consumption and the execu-tion time of different decision tree sizes used for prediction.Table 7 shows that the prediction algorithm only takes 0.295second and consumes 0.177 J power on average for goingthrough 10000 decision trees each of which has 8 nodes. Inaddition, unlike the malware detection [15], we do not needto frequently train and upload the decision trees to the smart-phone. If we train the decision trees too frequently with re-cent data, it may lead to overfitting and degrade the model’sgeneralization capability.
6. RELATED WORK
Table 7: Power consumption and execution time of pre-diction
Number of Decision Trees 1000 10000 20000Power Consumption (J) 0.016 0.177 0.326Execution Time (second) 0.027 0.295 0.543
Recently, research on reducing the power consumption ofsmartphones has received much attention. At the user inter-face level, because the display consumes the most amountof battery power, Iyer et al. [1] proposed to save energyby matching the display energy consumption to the func-tionality required by the workload/user. Zhong et al. [2]studied the impact of human factors and user interfaces onenergy efficiency and proposed a cache solution to reducethe power consumed by the user interface. At the applica-tion level, Flinn et al. proposed power management solu-tions [3] through adaptation where applications can dynam-ically modify their behavior to conserve energy and let theOS manage battery resources using feedback and applicationhistory to extend the battery lifetime. Turduken [4] proposedan approach that would integrate a series of components op-erating at various power levels to extend the battery life.Constandache et al. [16] proposed an energy-efficient lo-calization technique which can choose WiFi, GSM, or GPSbased on a given energy budget.
How to reduce the power used by the WiFi interface onmobile devices has been well studied. Wake-on-wireless[17] turns WLAN card off and uses a secondary out-of-bandmechanism to wake up mobile devices. uPM [5] modifiesthe MAC layer to put the 802.11 interface into power sav-ing for idle intervals to reduce the power consumption. Cat-nap [18] reduces the energy consumption of mobile devicesby allowing them to sleep during data transmission. In ad-dition, NAPman [19] uses an energy-aware fair schedulingalgorithm to minimize the client energy consumption andunnecessary retransmissions. To avoid the high power con-sumption of 3G connection, CoolSpots [20] and Agarwalet al. [21] enable wireless mobile devices to automaticallyswitch to low energy WiFi or Bluetooth connections. Raet al. [22] proposes to delay the data transmissions until alower-energy WiFi connection becomes available.
As the number of 3G smartphones exponentially increases,it has become an important problem to save the power ofthe 3G wireless interface. Bartner [23] establishes the re-
12
lationship between signal strength and power consumption,and schedules communication based on the signal strength tosave power. The power consumption of mobile devices withdifferent timer values has been measured by analytical mod-els [24] [25]. Instead of finding optimal values, some previ-ous studies focus on changing timer values to save power inthe FACH state. Liers et al. [26] rely on the characteristicsof packet traffic pattern and the current system utilization todecide when to release the radio resource. TOP [10] dynam-ically changes the timer value with input from the applica-tions. Differently from these works, our approach updatesthe timer based on the predicted reading time. Although thereading time has been predicted and used for various infor-mation retrieval tasks [12, 27], none of them has applied topower saving in smartphones.
Web browsing is a computation intensive application insmartphones. To address the computation constraint, a com-mon approach is to shift the computation to the remote proxy[28] [29] [30]. Opera Mini [31] first processes webpages ona proxy and then deliver the data to smartphones. Althoughthese approaches can reduce the webpage loading time, theyneed additional remote devices.
Recently, how to reduce the webpage layout computationhas received much attention, because it takes 40–70% of theprocessing time for loading webpages [7]. Meyerovich etal. [7] provides a fast layout engine to speed up the layoutcomputation for new webpages. For webpages that havealready been opened, Zhang et al. [32] propose a layoutcaching approach. It caches the layout results to eliminateredundant computations and achieves more efficient localwebpage processing. Different from them, our approach fo-cuses on reorganizing the computation sequence to reducethe total data transmission time to save power.
7. CONCLUSIONIn this paper, we proposed an energy-aware approach for
web browsing on 3G based smartphones. First, we reorga-nize the computation sequence for loading webpage so thatthe web browser can first run the computations that will gen-erate new data transmissions and retrieve these data. Then,the web browser can put the 3G radio interface into IDLE,release the radio resource, and then run the remaining layoutcomputation. This not only saves power, but also reducesthe webpage loading time by removing the computation in-tensive redraws and reflows. Second, we predict the userreading time on the webpage after it is downloaded. If thistime is longer than a threshold, the radio interface can be putinto IDLE to save power. Since smartphones have limitedcomputation capability, we propose a low overhead predic-tion algorithm based on Gradient Boosted Regression Trees(GBRT). Experimental results show that our approach canreduce the power consumption of the smartphone by morethan 30% during web browsing. Moreover, our solution canreduce the webpage loading time by 17%, and increase thenetwork capacity by 19.6%.
8. REFERENCES[1] S. Iyer, L. Luo, R. Mayo, and P. Ranganathan, “Energy-adaptive
display system designs for future mobile environments,” in Proc.ACM MobiSys, 2003.
[2] L. Zhong and N. K. Jha, “Energy efficiency of handheld computerinterfaces: limits, characterization and practice,” in Proc. ACMMobiSys, 2005.
[3] J. Flinn and M. Satyanarayanan, “Managing battery lifetime withenergy-aware adaptation,” ACM Transactions on Computer Systems(TOCS), May 2004.
[4] J. Sorber, N. Banerjee, M. D. Corner, and S. Rollins, “Turducken:hierarchical power management for mobile devices,” in Proc. ACMMobiSys, 2005.
[5] J. Liu and L. Zhong, “Micro power management of active 802.11interfaces,” in Proc. ACM MobiSys, 2008.
[6] 3GPP Specification TS 24.008: Mobile radio interface Layer 3specification; Core network protocols; Stage 3
[7] L. A. Meyerovich and R. Bodik, “Fast and parallel webpage layout,”in Proc. International World-Wide Web Conference (WWW), 2010.
[8] J. H. Friedman, “Greedy function approximation: A gradientboosting machine cite,” in Annals of Statistics, 1999, pp. 579–588.
[9] J. P. Romero, O. Sallent, R. Agusti, and M. A. Diaz-Guerra, Radioresource management strategies in UMTS. John Wiley and Sons, Inc,2005.
[10] F. Qian, Z. Wang, A. Gerber, Z. M. Mao, S. Sen, and O. Spatscheck,“TOP: Tail optimization protocol for cellular radio resourceallocation,” in Proc. IEEE ICNP, 2010.
[11] 3GPP Specification TS 25.331: Radio Resource Control (RRC);Protocol specification.
[12] C. Liu, R. W. White, and S. Dumais, “Understanding web browsingbehaviors through weibull analysis of dwell time,” in Proc. ACMSIGIR, 2010.
[13] “Efficient javascript”http://dev.opera.com/articles/view/efficient-javascript/, 2011
[14] Alexa Internet, Inc, “The top 500 sites on the web,”http://www.alexa.com/topsites, December 2009.
[15] A. Bose, X. Hu, K. G. Shin, and T. Park, “Behavioral detection ofmalware on mobile handsets,” in Proc. ACM MobiSys, 2008.
[16] I. Constandache, S. Gaonkar, M. Sayler, R. R. Choudhury, andL. Cox, “Energy-efficient localization via personal mobilityprofiling,” in Proc. IEEE Infocom mini-conference, 2009.
[17] E. Shih, P. Bahl, and M. J. Sinclair, “Wake on wireless: an eventdriven energy saving strategy for battery operated devices,” in Proc.ACM MobiCom, 2002.
[18] F. R. Dogar, P. Steenkiste, and K. Papagiannaki, “Catnap: exploitinghigh bandwidth wireless interfaces to save energy for mobiledevices,” in Proc. ACM MobiSys, 2010.
[19] E. Rozner, V. Navda, R. Ramjee, and S. Rayanchu, “Napman:network-assisted power management for wifi devices,” in Proc. ACMMobiSys, 2010.
[20] T. Pering, Y. Agarwal, R. Gupta, and R. Want, “Coolspots: reducingthe power consumption of wireless mobile devices with multipleradio interfaces,” in Proc. ACM MobiSys, 2006.
[21] Y. Agarwal, R. Chandra, A. Wolman, P. Bahl, K. Chin, and R. Gupta,“Wireless wakeups revisited: energy management for voip over wi-fismartphones,” in Proc. ACM MobiSys, 2007.
[22] M.-R. Ra, J. Paek, A. B. Sharma, R. Govindan, M. H. Krieger, andM. J. Neely, “Energy-delay tradeoffs in smartphone applications,” inProc. ACM MobiSys, 2007.
[23] A. Schulman, V. Navda, R. Ramjee, N. Spring, P. Deshpande,C. Grunewald, K. Jain, and V. N. Padmanabhan, “Bartendr: apractical approach to energy-aware cellular data scheduling,” in Proc.ACM MobiSys, 2010.
[24] C.-C. Lee, J.-H. Yeh, and J.-C. Chen, “Impact of inactivity timer onenergy consumption in WCDMA and CDMA2000,” in WirelessTelecommunications Symposium, 2004.
[25] J.-H. Yeh, J.-C. Chen, and C.-C. Lee, “Comparative analysis ofenergy saving techniques in 3GPP and 3GPP2 systems,” in IEEEtransactions on vehicular technology, 2009.
[26] F. Liers and A. Mitschele-Thiel, “UMTS data capacity improvementsemploying dynamic RRC timeouts,” in Proc. PIMRC, 2005.
[27] J. Attenberg, S. Pandey, and T. Suel, “Modeling and predicting user
13
behavior in sponsored search,” in Proc. ACM SIGKDD, 2009.[28] B.-G. Chun and P. Maniatis, “Augmented smart phone applications
through clone cloud execution,” in Proc. HotOS XII, 2009.[29] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The case
for VM-based cloudlets in mobile computing,” IEEE PervasiveComputing, 2009.
[30] E. Cuervoy, A. Balasubramanianz, D.-k. Cho, A. Wolmanx,S. Saroiux, R. Chandrax, and P. Bahl, “Maui: Making smartphoneslast longer with code offload,” in Proc. ACM MobiSys, 2010.
[31] “Opera mini” http://www.opera.com/mobile/features/, 2010.[32] K. Zhang, L. Wang, A. Pan, and B. B. Zhu, “Smart caching for web
browsers,” in Proc. International World-Wide Web Conference(WWW), 2010.
