An Energy-Bandwidth Aware Web

2169-3536 (c) 2013 IEEE. Translations and content mining are permitted for academic research only. Personal use is also permitted, but republication/redistribution requires IEEEpermission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI10.1109/ACCESS.2014.2365091, IEEE Access

1

SMoW: An Energy-Bandwidth Aware WebBrowsing Technique for Smartphones

Abdurhman Albasir and Kshirasagar Naik

AbstractWith the rapid advancement of mobile devices, people have become more attached to them than ever. This rapid growthcombined with millions of applications (apps) make smartphones a favourite means of communication among users. In general, theavailable contents on smartphones, apps and the web, come in two versions: (i) free contents that are monetized via advertisements(ads), and (ii) paid contents that are monetized by user subscription fees. However, the resources, namely, energy, bandwidth, andprocessing power, on-board are limited, and the existence of ads in websites and free apps can significantly increase the usage ofthese resources. These issues necessitate a good understanding of the mobile advertising eco-system and how such limited resourcescan be efficiently used. In this paper, we present the results of a novel web browsing technique that adapts the webpages delivered tosmartphone, based on the smartphones current battery level and the network type. Webpages are adapted by controlling the amountof ads to be displayed. Validation tests confirm that the system can extend smartphone battery life by up to 30% and save wirelessbandwidth up to 44%.

Index TermsSmarphones; energy efficiency; efficient web browsing; web adaptation.

F

1 INTRODUCTION

THE past decade has witnessed a huge growth insmartphones popularity. People all over the worldnow tend to have smartphones, and the number ofmobile phones in the market has been estimated to bealmost equal to the number of people worldwide in 2013[1]. A significant percentage of these mobile subscribersalready have a smartphone. A report published by Com-Score in September 2012 stated that over 115 millionpeople in the United States owned smartphones out of234 million total subscribers [2]. This statistics shows apenetration of close to 50%. Such growth and popularityare driven by the vast variety of applications (apps) nowavailable. The rapid growth of smartphones combinedwith millions of apps makes them a favourite meansof communication among users, but their functionalitiesare constrained by a number of challenges concerningbattery life, bandwidth, and security.

The volume of wireless traffic continues to grow ex-ponentially. Web browsing and network related appli-cations (NRAs) rely entirely on the Internet for theiroperation. They are considered the main contributors tothe ever-growing wireless traffic. Since the traffic gener-ated by smartphones forms a new addition to wirelessnetworks, there is increased interest in the investigationof the nature of smartphone traffic [3] [4]. These researchstudies focus on interesting questions: (i) how much traf-fic a device generates per day; (ii) which app contributesthe most to the total smartphone-generated traffic; and(iii) which app utilises the most network resources. The

A. Albasir and K. Naik are with the Department of Electrical andComputer Engineering, University of Waterloo, Waterloo, ON, Canada,N2L3G1.E-mail: {aalbasir, snaik}@uwaterloo.ca

results can be used by mobile operators to improve theirwireless quality of services (QoS) [5] [6] [7]. Some studieshave broken down the traffic generated by smartphonesto the app level, to explore how much traffic is generatedby each app. However, more questions remain unan-swered. For example, in mobile web browsing, whatis the bandwidth cost of delivering certain informationto an end user? More specifically, how many bytes arerequired for downloading information that is not of userinterest? Thus, more investigation is needed, and moresolutions that utilize this scarce resource efficiently areof great importance.

Smartphones use Lithium-ion batteries due to theirhigh energy densities. However, there is no tangibleevidence that, in the near future, more energy can bepacked into the small space available on todays hand-held devices [8]. In addition, more powerful processors,high resolution displays, huge numbers of applications,and advanced wireless technologies (LTE, WiMAX) areemployed in todays smartphones and tablets. Such tech-nologies and components drain energy at high rates,and are considered as battery hungry. For instance,the authors of [9] found that smartphone components,namely, CPU, Wi-Fi, LCD, GPS, and 3G links, consumeup to 28.6, 24.6, 85.9, 33.6, and 36.5 Joules, respectively.

The subject of this research was motivated by twoobservations: (i) the high growing popularity of mobile webbrowsing; and (ii) the increasing complexity of webpages.Recent statistics show that users prefer to use webbrowsers for digital news delivery. According to a surveyconducted in the United States in 2012, 61% of smart-phone users and 60% of tablet users use mainly browsersfor reading news [10]. Thus, browsers are consideredto be among the most popular apps. Regarding theincreasing complexity of webpages, a study reported



in [11] shows that over half of the webpages are notoptimized for mobile browsers. Although many websiteshave mobile versions of their webpages, people tend toview the full (that is, desktop) versions to experience therichness of the contents. Despite the fact that some wellknown website companies have already created mobileversions of their websites, their sub-pages are actuallydesktop versions (full versions). These webpages are get-ting more complex [12], [13], that is, more computationintensive; and the existence of ads in webpages furtherincreases the complexity. This complexity in smartphoneenvironment, where resources (e.g., battery and band-width) are limited, is reflected in longer loading times,more energy consumed, and more bytes transferred.

Therefore, with those observations in mind, we werefirst motivated to study the energy and bandwidthimpacts of ads in webpages. Then, after studying theimpact of web ads on smartphone battery life and band-width, we were motivated by the measurements andthe findings obtained in Section 3.2 to design a systemthat is energy and bandwidth efficient. In Section 3.2we show that: (i) for some webpages, the energy costof ads is about 18% of the energy cost of browsing thesame pages without ads; and (ii) bandwidth overheaddue to downloading ads is almost 50% of the total re-quired bandwidth to download those pages without ads.Therefore, we propose a novel web browsing technique, called Smart Mobile Web (SMoW) browsing that takesinto account two parameters: (i) the state of charge ofthe battery; (ii) the current network type (i.e., Wi-Fi or3G)

SMoW mainly targets: (i) extending smartphone bat-tery life; and (ii) preserving the bandwidth needed todownload webpages. As mentioned previously, havingads displayed in webpages is essential to having freeweb contents; therefore, our approach aims to balancethe satisfaction of end users and the interest of thewebpage owners (publishers) to push ads.

With the aforementioned backdrop, this paper makesthe following contributions:

quantify the ad traffic generated during mobile webbrowsing;

quantify the energy consumed to download and dis-play ads on webpages while mobile web browsing;

investigate the impact of using different networks,say 3G and Wi-Fi, on the energy consumed todownload and display ads on webpages;

propose a smart mobile browsing technique thataims to extend smartphone battery life and savewireless bandwidth by controlling the amount ofads to be displayed. This solution attempts to retainthe ads, and, at the same time, alleviates its impacton the smartphones limited resources.

The rest of the paper are organized as follows. Therelated work and background are presented in Section2. Section 3 describes the testing methodology usedand the experiments carried out to achieve the firsttwo contributions of this research; it also presents and

discusses the measurements of energy and bandwidthexpanded on ads. Section 4 describes the proposed smartmobile web browsing framework and the validation ofresults. Finally, Section 5 lists some conclusions of thispaper and recommendations for future work.

2 BACKGROUND AND RELATED WORKIn this section we provide the background informationrelated to web browsing, the impact of web advertisingon smartphone resources, and the existing related work.

2.1 The Structure of Webpages

Webpages basically are HTML files that are deliveredto the end users browser, which in turn, renders thecomponents that the HTML file contains and displaysthem on the users screen in a readable way. Tagsare used in HTML files to reference these components,distinguish them from each other, and let the browserunderstand what to do with each and every component.Zooming in into the HTML files to see what kind ofcomponents it contains, we find: (i) textual information;(ii) images; (iii) Cascading Style Sheets (CSS); and (iv)JavaScript code. From an end users view, what she seesare some information that she is interested in, and someother unwanted information (ads), as shown in Fig. 1.The big arrows in the figure highlight those unwantedinformation (ads.) From an end users prospective, wecall the ads unwanted forced information becauseusers mostly see them as a source of annoyance. Besides,ads are downloaded and displayed whether or not a userwants to see them.

Fig. 1: Example of webpage contents.

2



Fig. 2: A high level view of how web browsing works.

A simplified view of how things work while webbrowsing is depicted in Fig. 2. The figure shows onlythe main players. It starts with an end user fetch-ing content from a certain website (publisher, e.g.www.mydictionary.com). The browser makes the neces-sary DNS (Domain Name System) look up to get theIP (Internet Protocol) address of the website, establishesa TCP connection with the server, and then sends anHTTP GET request to that server (website). The pub-lishers server sends back an HTML file that contains thepage contents and other components, namely, CSS files,images, and JavaScript code. The browser at the end userside starts rendering the HTML file, and it finds tagsfor other components that need to be fetched. It sendsmore HTTP GET requests to retrieve these elements.Ads come into the picture in the form of HTML orJavaScript code. Once such code is triggered, while thebrowser renders the HTML file, another TCP connec-tion is established with a specific ad network server(Ad network, e.g. AdSense) followed by an HTTP GETrequest to download ad contents. The ad sever figuresout what sort of ads should be sent to the user based ona matching technique that is done with the publisherswebpage content (Contextual targeting.) If a user findsan interesting ad and clicks on it, she will be redirected tothe advertisers webpage. Behind the scenes, advertisersmake agreements with the ad network that specify thepricing method and provide the ad network with theads of products they want to promote. Publishers aswell make other agreements with the ad networks thatspecify the financial conditions and some regulationson what kind of ads are allowed to be published ontheir pages. Ad networks, in turn, provide the publisher(website) with a piece of JavaScript code or HTML tagsthat the publisher embeds in its webpages.

2.2 The Impact of Web Advertising on SmartphonesAppearance of ads on webpages and mobile apps isessential and necessary for having free web contentsand free apps. The features that smartphones offermake them a suitable advertising platform. In addi-tion, the ever increasing popularity of smartphonesis an indication that there is a huge opportunitythat advertisers can reach the audience almost ef-fortlessly. Advertisers have the capability to instantlytarget the consumers individually by leveraging theGPS (Global Positioning System) location and the searchhistory of web-browsers and map apps.

Ads come in different formats in the webpages: somecan be just simple textual ads and others can be verycomplex dynamic ads. An example of complex dynamicads is having an ad banner that shows ads that auser can interact with; such ads are rich in animationand computation intensive. As mentioned in Subsection2.1, ads are embedded in the main HTML files in theform of JavaScript code or an HTML tag code. Suchcodes are computationally intensive, and, consequently,consume much of energy and require high bandwidthto download (e.g. JavaScript components, on average,may occupy 200 Kbytes [14]). The more ads a web-page contains and the more the ads get complex, themore resources are wasted. Therefore, the involvement ofthird-party advertisements, as a monetization technique,in webpages as well as in mobile apps increases theseriousness of the energy and bandwidth issues on theavailable limited resources of smartphones.

2.3 Related WorkRecently, there have been several studies that focused onbetter mobile web browsing experience. Some proposalsare content adaptation-based solutions [14], [15], andothers manipulate the way browsers download the webcontents and the resulting latency [11], [16].

Chava et al. [14] have addressed the adaptation ofwebpages based on the users data plan and usagelevels. Their solution aims to reduce the cost of webbrowsing by monitoring the users web usage and theusers data plan quota to ensure that the user doesnot exceed the specified data limit (data quota.) Theirsystem requires a network middle-box (proxy) to: (i)manage the required adaptation each time a web requestis made; and (ii) track the user data usage to ensurethat the data limit is not exceeded. Dubey et al. [15]proposed a framework based on pre-defining the loadingorder of the webpage components. Their content creatorapproach works in a way that lets the user be part ofthe web content adaptation process. Therefore, based onusers preferences, the content creator can prioritize theimportance of webpage items. The loading of these itemsis done according to the highest priority to the lowest.By doing so, users experience can be enhanced.

Zhao et al. [16] proposed an energy-aware web brows-ing solution for smartphones while connecting to 3G

3



networks. They leverage two main properties of webbrowsing on 3G networks: (i) the computation sequenceof loading web contents by the browsers; and (ii) thedifferent power states that a smartphone has while con-necting to a 3G network. The idea is to download all thecontents in one attempt instead of downloading them inmultiple attempts. In that case, the 3G radio interface isin a high power state till all the web components arefetched. Once all the components are downloaded, theradio interface goes into a low power state. The browser,in turn, runs the computations needed to render thedownloaded web contents for the user. As a result, therequired power is lowered and the latency (time neededto load webpages,) as well. In reference [11], Wang etal. critically analyse the slowness of web browsers onsmartphones. They found that the main reason for theslow web browsing is the process of fetching differentweb contents.

Some other solutions related to energy efficiency insmartphones were proposed in [17] and [18]. Huang etal. [17] aim to reduce the number of HTTP requestsand responses made by mobile mesh applications, and,consequently, lower the energy consumption as well asspeed up the web resource retrieval process.

3 MOTIVATIONAL STUDYThis section contains the main study motivating thedesign of Smart Mobile Web Browsing (SMoW) system.This section describes a number of experiments car-ried out to achieve the first two contributions of thispaper (see Section1.) Subsection 3.1 details our testingmethodology and test benches; finally, the results andmeasurements of energy and bandwidth are presentedand analysed in Section 3.2.

3.1 Testing MethodologyTo perform testing, the first challenge was to separate theweb contents. In other words, we wanted a way to sep-arate the ad contents from the original webpage, so thatwe can test the smartphone once with the existing of adsand a second time without ads. As a result, we can mea-sure exactly the energy and bandwidth cost of ads by cal-culating the difference between the two cases. A methodwas sought to block or insulate the ads from the web-pages. The available blocking techniques are as follows.

3.1.1 The Available Ad-blocking Techniques Ad-blocking Applications: A number of apps avail-

able online can block ads, namely, Ad-Vanish Lite,NoRoot Ad-Remover Lite, and AdFree. These appswork by turning off the Internet connection com-pletely. They are designed to block ads from Androidgames and they work as follows: the user is re-quested to prepare an Ad-block list, so if she wantsto stop displaying ads on a game all she needs todo is to put this game on the Ad-block list. Theseapps in turn make sure that the games will have no

access to the Internet any more, and hence the adsare blocked. These Ad-blocking applications workfine for the apps that do not require an Internet con-nection. In the case of web browsing, establishing anInternet connection is essential. Therefore, this Adblocking option does not satisfy our testing needs.

Browser Plug-in Ad-blockers: Mobile web browserssuch as Mozilla Firefox and Android can use plug-in ad-blockers to block ads. Some plug-in apps areavailable online (Adblock Plus) and they filter outthe ad URLs. These plug-ins maintain a black listthat contains advertising companies URLs; thus,whenever an ad request made by the browser isfound on the black-list, that request is aborted.Our comments on these ad-blocking methods are asfollows: (i) installing these plug-ins will change theway browsers work, and hence the measurementswill be distorted. In other words, having such plug-ins working in the background requires extra ac-tivities and computational power. As a result, extraenergy is consumed. For our case, where we arelooking to measure the actual energy and band-width required to download and display ads, usingthis option will give us distorted measurements.(ii) In addition, not all of the ads will be blockedsince the operation of these plug-ins relies entirelyon the specified list, which may not contain all theadvertising companies (Ad networks.) As a result,some ads will still be displayed while adopting thisoption. (iii) The ad links (ad tags) in a webpage arealready delivered to the smartphone and parsed bythe browser; as a result, some bandwidth and en-ergy would have been consumed. For these reasons,we eliminated this option as well.

Proxies: Proxies, namely, Privoxy [19], can be in-stalled at a middle point (e.g., a Wi-Fi access point ora network router) to block ads. The mechanism usedto block ads is similar to the one explained in Ad-blocking Applications. Therefore, this option has alsobeen eliminated.

The last two options suffer from the same problems;moreover, they require human effort and time to keeptheir ad-blocking lists up-to-date. Therefore, another ap-proach was needed to achieve the goal of blocking adswithout engaging the smartphone in this process.

3.1.2 Our Ad-blocking StrategyThe approach used to tackle the ad-blocking problemand take full control of the web content crystallizes inhaving our own web hosting server. By doing so, we caneither enable the ads or remove them completely fromthe webpages before they are even requested by the enduser. The process works as follows: (1) choose certainweb-sites; (2) download them and make two copies ofevery one; (3) modify and remove ad codes found in onecopy and keep the other one as is; and (4) upload onecopy to the server at a time to perform testing. We mod-ify the the webpages manually by removing all the ad-

4



1) choose a number of website

(e.g., www.therecord.com,

www.nytimes.com)

Full versionAd free

version

3) Modify this

version so that all

the ad components

are removed

2) Download them and create

two versions of each one

Ads

Ads

Ads

Fig. 3: Ad blocking strategy

Smartphone

Internet

News Server

Mac Laptop

Cellular Tower

WiFi Access Point

Streaming Server

Lab PC

Power supply

Fig. 4: Measurement Set-up.

related contents from the requested HTML documents.Figure 3 illustrates the sequence of the ad-blocking pro-cess and the final view that is displayed on the end userscreen after the ad-blocking technique is applied.

3.1.3 Test Set-upThe test bench used to measure the energy consumptionin smartphones is described in this section. Our exper-imental setup is shown in Fig. 4. We use a Monsoonpower monitor [20] to power the smartphone and accu-rately measure the current drawn by the smartphone inreal-time. The power monitor is connected to a personalcomputer (PC) where the measurements are receivedand stored for off-line analysis. We performed our exper-iments on a Galaxy Nexus smartphone running AndroidV4.2.1. The phone settings during the testing were keptconstant to provide consistent measurements.

To conduct the experiments, we chose the built-in An-droid Browser on Galaxy Nexus smartphone and anotherbrowsing application caslled semi web browser that

we developed. The energy cost experiments were doneover a 3G cellular link and a Wi-Fi private access point(AP) installed in our lab. The AP is a Cisco Linksys,and it supports the IEEE802.11g interface. For the 3Gcellular connection, an HSPA+ Bell prepaid SIM card wasused. This connection provides a typical speed of 7 - 14Mbit/s [21]. For the phone configurations, we followedthe methodology proposed in reference [22], in order tohave consistent measurements.

To ensure that the measured energy is the real costof requesting webpages, we make sure that no datais cached and all the web elements will be requestedentirely fresh from the web server in each web request.Therefore, we clear the browsers cache before everyexperiment and also disable all the other network-relatedapplications (e.g., Android update libraries.)

3.1.4 Bandwidth and Network Test Set-upThe test bench used to monitor the traffic going fromand to the smartphone is shown in Fig. 4. We installedWireshark on a Mac-book laptop to leverage the MonitorMode feature available on Mac-book laptops. This featureallows the packet sniffing task to be performed passively;that is, we can capture all the traffic exchanged betweenthe AP and the smartphone without involving any activ-ities on the phone. Wireshark is a powerful monitoringand analysis tool, and enables us to monitor packetinformation from the radio level up to the applicationlevel packet information. The collected packet tracesare analysed to classify how much bandwidth web adsconsume and how much bandwidth the non-ad relatedweb contents consume.

3.2 Measurements of Costs of Web Advertisementson Smartphones3.2.1 Test Cases for Energy MeasurementsUsing the described testing infrastructure for measuringthe energy consumption we were able to measure theinstantaneous current drawn from the battery when auser is accessing the web. We started our energy exper-iments by testing how much energy is consumed whenbrowsing a number of websites. The terms drainedcurrent and consumed energy are used interchange-ably throughout this paper due to the direct relationshipthat connects both of them, as shown by the equationE = I V t, where E is the energy, I is the current, Vis the constant voltage, and t is the time duration.

We chose a number of websites: (i) the most-accessedlocal news websites; (ii) a highly ranked internationalnews website; and (iii) three samples of highly rankedCanadian magazine websites, according to Alexa [23].We surfed the full version of each website, using Androidweb browser over Wi-Fi and 3G connections. Figure.5 (the solid line) illustrates the energy behaviour of anumber of news websites.

First of all, we noticed a common energy-consumptionfootprint for mobile web browsing. As can be seen in

5



0 10 20 30 40 50 60 70300

400

500

600

700

800

900

1000

Time (Sec)

Current (mAmp)

Webpage without adsWebpage with ads

(a) www.macleans.com

0 5 10 15 20 25 30 35 40 45200

300

400

500

600

700

800

900

1000

Time (Sec)

Current (mAmp)


(b) www.nytimes.com

0 5 10 15 20 25 30 35 40 45300

400

500

600

700

800

900

1000

Time (Sec)

Current (mAmp)


(c) www.thestar.com

0 5 10 15 20 25 30 35 40 45300

400

500

600

700

800

900

1000

Time (Sec)

Current (mAmp)


(d) www.canoe.com

Fig. 5: The power footprint of four websites over a Wi-Fi connection with and without ads

TABLE 1: Summary the traffic statistics while web browsing with and without ads

Websites # of serverswith Ads

# of serverswithout Ads

Time to downloadthe page with ads(Sec.)

Time to downloadthe page withoutads (Sec.)

Energy dif-ference (J)

www.therecord.com 17 9 10.5 8 15www.nytimes.com 23 19 10 6 6.2www.macleans.com 35 22 7 11 6.1www.thestar.com 29 17 7.5 5 10.6www.canoe.com 19 16 15.5 15 4.5

Fig. 5 (the solid line), the energy behaviour starts withthe phones idling energy, which is the state before auser launches the web browser. This state is marked onthe figures and found to be approximately 300 mA (milliAmpere), and is followed by high-energy activities thatlast for some of time. The high-energy-activity periodrepresents the energy needed to: (i) launch the browserapp; (ii) download the web content (the network/radiointerface energy cost); (iii) render the received HTML file(the computational energy cost), and (iv) display what isbeing rendered and is ready to be displayed on the userscreen. The next energy state represents the energy costonly of displaying the entire webpage content. In gen-eral, we found that browsing a full version of the websiteover Wi-Fi for 30 seconds consumes 60 to 73.9 Joules.

To correlate the energy activities with the displayedweb contents, we started from an end-user point of viewand closely examined Fig. 5. We noticed, for instance,that periodic energy spikes occur approximately every 5seconds in Fig. 5(b). To investigate the real cause of suchan energy activity, we looked into the contents displayedon the phones screen and found that these spikes aredue to displaying an ad content. This ad content isbasically a dynamic ad that displays different ads every5 seconds. We then went further to the application layerand investigated the HTML document that contains this

ad content. We found out that this ad corresponds to ablock of JavaScript code, and it requires high computa-tional power to render and display.

3.2.1.1 Energy-Bandwidth Mapping in Webpages:In an attempt to understand the energy behaviour of webbrowsing, we correlated the energy consumption foot-print to the network activities needed to download webcontents. Doing so, we can identify how long fetchinga web component takes, and consequently, how muchenergy doing so consumes. Using the test bench, we con-ducted an offline analysis of the traffic being transferredfrom and to the smartphone while a user is accessingthe web. We, then, mapped the network activities (thatis, the loading time for each TCP connection) onto theconsumed energy. As was expected, we notice that thereare multiple TCP connections established in parallel.Multiple parallel TCP connections are typically neededto speed up the retrieval of web contents. The first con-tent that the browser downloads is typically the indexHTML document. Once this document is downloaded,the browser starts to parse and script its contents. Bydoing so, the browser finds other web resources (images,CSS, JavaScript files, and ads) to be fetched. Conse-quently, more TCP connections are established. Now,since the core web content and the ad content come from

6



different servers, in some cases 3 to 13 TCP connectionswere found to be dedicated to ad servers and to analyticservers that gather statistics and other information aboutusers. Table. 1 lists the number of TCP connections (# ofservers) needed for advertising purposes.

As explained briefly in Section 1, for the browser todisplay webpages, all web contents referenced/taggedin the index HTML document, certain processes arerequired. The browser has to: (i) obtain the IP (InternetProtocol) address corresponding to the URL referencingan web object; (ii) handle the HTTP request that is to bemade; (iii) establish the TCP connection with the servercontaining that web object; and (iv) render that objectbased on the rules specified in the CSS. These time-consuming processes were found to be under the timeperiod of a high energy state, which is not very sur-prising considering the high computations required bythe browser to accomplish the task of displaying the re-quested webpages. We noticed also that the overall timeneeded to download all the webpage contents is around10 seconds, in some cases. Approximately 2 seconds be-yond those 10 seconds show high energy activity; we be-lieve that is due to the computation needed to render theremaining fetched objects (objects that are downloadedwith no network activities are involved). We found itvery difficult to separate the energy consumed by therendering process and the radio/network interface ac-tivity. Moreover, it is important to mention here that theobjective of this paper is to quantify the web advertise-ment energy and bandwidth impacts and not to focuson analysing the energy consumption of web browsers.

To identify the relationship between the number ofTCP connections and the corresponding energy con-sumption, we modified some webpages using our Ad-blocking strategy. Applying this strategy allowed usto change the number of TCP connections that areopened. Then, we compared the energy consumptionin both cases for each website, and found, as ex-pected, that the more TCP connections we have, themore energy is consumed, as shown in Table 1. More-over, as the number of TCP connections increases, thefetching loading time increases as well, and so doesthe energy consumption. Downloading the ad con-tent prolongs the active period of the radio interface,and hence increases the energy consumption.

3.2.1.2 Energy Impact of Ads over Wi-Fi:To study the impact of web advertising on energy,

we started by browsing the full version of a numberof websites over a Wi-Fi network, using the phonesbuilt-in Android Browser. Then, we applied our Ad-blocking strategy, described in section 3.1.2, and repeatedthe same experiments that were conducted for the fullversions of the websites. Next, we compared the energyneeded to download webpages with and without ads.Figure 5 shows the energy consumption for a numberof websites. The dashed line refers to the webpagesthat are ads-free and the solid line refers to the full

0 20 40 60 80 100 120 140 160 180 200300

400

500

600

700

800

900

1000

Time (Sec)

Current (mAmp)

Without AdsWith Ads

Fig. 6: Energy measurement of our browser

version of webpages (webpages with ads.) It is worthmentioning here that during our energy measurementswe performed passive network sniffing over the Wi-Ficonnection as well. Our offline analysis of the gatherednetwork traces confirmed our previous argument thatthe more TCP connections there are, the longer theloading time is, and consequently, the more energy isconsumed. As shown in Table 1, the energy overheaddue to ads ranges from 4.5 to 15 Joules.

Reliability of Measurements

To ensure the reliability of our measurements, we devel-oped a semi-web browser on Android. To ensure morereliable measurements, the experiments were repeatedmultiple times. We wanted to keep the same settingsthroughout the experiments, and, most importantly, min-imise end-user interactions with the smartphone. There-fore, we developed our own web browser. Doing so: (i)enabled us to repeat the same experiments a number(7 times) of times at consistent time intervals of 30seconds; (ii) meant that no information was allowed tobe cached; and (iii) minimized end-user interactions withthe phone; that is, a single tap on the apps icon wasenough to start the browsing.

Figure 6 shows the power footprint while using ourbrowser app. Moreover, we conducted a number of testsjust to ensure that our app energy consumption did notdiffer a lot from the built-in Android Browser. We foundin many cases that both measurements were very close,and in some cases a 100% match was noticed.

Table 2 summarizes the energy consumed by a num-ber of websites, with and without ads. The differencein energy consumption ranges from 6 - 17.5%. Again,these figures are due what we call ad-overhead, thatis, the net energy cost of the processes of downloading,rendering, and displaying web ads over a Wi-Fi network.These numbers are average values. We noticed that thead contents vary each time a request is made, andobserved that webpages with ads take longer to load.As it can be seen in Fig. 5, around 4 to 10 secondsof extra time is needed to download and display ads.These times are reflected in the form of extra energy,

7



TABLE 2: The cost of ads over a Wi-Fi/3G interfaces

Website Browsing Energy (J)WiFi/3G

EnergyOverhead due to

Ads WiFi/3G

Difference in theEstimated

Battery Life(min) WiFi/3G

browsing with ads 68.5/87.7 16%/14% 27/22www.therecord.com browsing without ads 59/76.7

browsing with ads 60/72.8 9%/7% 23/15www.nytimes.com browsing without ads 55/68.2

browsing with ads 65/80.5 12%/8.2% 17/14www.macleans.com browsing without ads 58/74.4

browsing with ads 67/82.6 17.5%/17.5% 35/28www.thestar.com browsing without ads 57/70.2

browsing with ads 61.5/73 6%/6% 8/5www.canoe.com browsing without ads 58/69

TABLE 3: Traffic breakdown per webpage

Web site Total page traffic(with ads) in BytesTotal page traffic

(without ads)in BytesTotal ads traffic in

Bytes

www.therecord.com 3,025,082 1,449,882 1,575,200 (52%)

www.nytimes.com 975,646 634,018 341,628 (35%)

www.thestar.com 714,961 351,732 363,229 (50%)

www.macleans.com 987,682 617,857 369,825 (37%)

www.canoe.com 6,005,729 5,861,272 144,457 (2.5%)

as the measurements in Table 2 show. We compared theextra times introduced by the existence of ads just fordownloading (Table 1) and the overall time added due todownloading and rendering ads (Fig. 5.) In some cases,most ads energy consumptions were due to the processof rendering. As the test case of browsing www.canoe.comshows, downloading the ads requires only half a sec-ond extra time, while the power footprint in Fig. 5-(d) shows an extra 10 seconds of high activity energystate. Moreover, Table 2 shows an estimation of batterylife, i.e., how long the battery would last if we wereto browse each version of the websites repeatedly untilthe battery died. These numbers illustrate how muchenergy is wasted by ads in webpages.

3.2.1.3 Energy Impact of Ads over 3G:

We repeated the experiments of Section 3.2.1.2 overa 3G connection. Table. 2 summarizes the energy con-sumed by browsing five websites, with and withoutads. We noticed that browsing over a 3G connectionconsumes more energy than Wi-Fi in general. The en-ergy overhead due to web ads ranges from 6 to 17.5%.However, the energy difference due to ads is less thanthe difference noticed over Wi-Fi. Moreover, we observedthat browsing a full version of a website, with ads,over Wi-Fi, is less expensive than browsing an ads-free version of the same website over 3G connection, asshown in Fig. 7. With 3G usage, batteries die faster thanwith Wi-Fi, which was certainly expected taking intoconsideration the observations mentioned in the begin-

ning of this paragraph. The higher energy consumptionover the 3G network is due to the energy tails and thecapacity dissimilarity, according to [24]. Energy tailrefers to the high energy state that the 3G radio interfacestays in after the network activity is terminated, whilethe capacity dissimilarity refers to the 3G bandwidthcapacity limit. Compared to Wi-Fi, 3G is slower, andconsequently, downloading webpages over 3G will takelonger, resulting in higher energy consumption. Whenwe considered browsing over the two network inter-faces, 3G and Wi-Fi, we found a difference in batterylife of, in some cases, one hour of operation. In otherwords, we could browse the web for an hour longerwhen using a Wi-Fi connection instead of 3G. Based onthis observation, we came up with the idea of SmartMobile Web Browsing that we explain in Section. 4.

www.canoe.com www.thestar.com www.therecord www.macleans.com50

60

70

80

90

Energy (J)

Website without Ads (WiFi)Website with Ads (WiFi)Website without Ads (3G)Website with Ads (3G)

Fig. 7: Energy cost of browsing five different websitesover 3G and Wi-Fi networks

8



3.2.2 Test Cases for Bandwidth Measurement

Using the previously described testing infrastructure formonitoring network activities while mobile web brows-ing, we were able to capture the network traces. Webrowsed five news websites and conducted an offlineanalysis to measure how much bandwidth ads down-loading require.

3.2.2.1 Bandwidth Cost of Ads:Using Wireshark traces, we investigated the traffic

needed to download ads components in webpages, andfound that in one case, surprisingly enough, ads trafficcomprised almost 50% of the traffic needed to downloadsome news webpages. More detailed traffic statisticsare shown in Fig. 8, where we see that when ads areenabled, 8 extra servers are contacted. We also observethat the number of HTTP requests made by the client(smartphone) is almost three times more when ads areenabled, and the total number of packets exchangedbetween the client and the access point is doubled. Table3 shows the overhead bytes needed to download ads.These numbers are average values since the ad contentsvary each time a request is made.

(Total # of pkts*20) (# of HTTP reqs) (# of HTTp pkts exchanged) (# of servers)0

50

100

150

200

250

300

350

#

Website without AdsWebsite with Ads

Fig. 8: Traffic statistics while web browsing with andwithout ads.

In summary, we found that ads consume a consider-able amount of energy and bandwidth. To have a bettersense of the effective cost of ads, we, next, give an em-pirical estimation of (i) how much energy a smartphonewould consume to download and display ads, and (ii)how much bandwidth it would cost a user to downloadthese ads for a certain period of time. We assume that auser spends around one hour on web browsing a day, notnecessarily continuously. In this hour, she would spend2 minutes per website; therefore, on average, she wouldaccess at least 30 websites. Based on Tables 2 and 3, weget the following:

the energy that a smartphone would consume, todownload and display ads in one hour of browsingis 360 Jules/day; and

the amount of bandwidth needed to downloadads would be equal to 2.6 Mbyte/day, that is 78Mbyte/month. Based on some US metered data

plans (usage-based pricing plans) [25], $ 12.48would be spent just on downloading ads.

4 PROPOSED SOLUTIONOur Smart Mobile Web (SMoW) browsing technique ismotivated by the measurements and findings of Section3.2. In the SMoW browsing technique, the page deliverymechanism is a function of the smartphones energy andnetwork-type resources and the amount of ads allowedto be displayed on the webpages. In other words, thesolution strategy we take crystallizes in making theserver smart enough to sense the smartphones currentoperational resources and provide it with a customizedwebpage. In this system, unlike other web adaptionsolutions [14], no end user involvement is required;rather, the client application (browser) sends the currentavailable resources, Battery Level and Network Typeto the server, along with the HTTP request. Based onthose information, the server sends back adapted webcontents to the client. Adaptations of the web contentsare effected in the form of how much ads are allowedto be displayed on the webpage. In [26], we have shownthe framework of SMoW from a high-level view, andin this study we describe the proposed technique inmore details with the support of implementation andthe validation of results.

4.1 Design requirements and objectives of SMoW

This section presents the key design decisions of ourSMoW browser as follows:

Minimize the number of ads when needed. As shownin Section 3.2, ads can be expensive in terms ofenergy and bandwidth. Therefore, the amount ofads to be delivered to the end user should be basedon a devices available resources, so that publishersdo not exhaust the smartphones resources. SMoWadapts the webpages that are sent to the smartphonebased on the devices current battery level andnetwork type. A adaptation of web contents comesin the form of how many ads are allowed to bedisplayed on the webpage.

Minimum adjustment to the existing browsing systems.The modifications required to be made to the ex-isting browsers and web servers are not complex-and the SMoW technique satisfies the requirement.On the server side, the necessary changes can bepackaged in the form of some plug-in modules thatcan be installed on the existing servers. And for theclient side (browsers), the needed components cansimply be added to existing browsers in the formof software updates. In Section 4.1.1, we explainthe details of the required modifications neededto accommodate the features of SMoW. The mainchallenge was to decide the protocol layer where weembed the required information on the client side.We decided to choose the application layer due to

9



Fig. 9: System Architecture

the simplicity of adding optional fields in the headerof the HTTP protocol. This approach facilitates theneed to make minimum changes to existing webbrowsers.

To achieve the two design goals, our solution strategyrequires the server to sense the smartphones operationalenvironment and provide the device with customizedwebpages. Having done that, SMoW can extend a smart-phones battery life while users still enjoy browsing thefull versions of their favourite websites (full pages).This system also takes into account the type of networkthat the mobile client is connected to and accordinglyprovides it with full pages that require less bandwidthto download. In this system, unlike other web adaptationsolutions, e.g. [14], no user involvement is required, andthe client application (browser) sends the current avail-able resources (Battery Level and Network Type) to theserver in the HTTP requests. Based on that information,the server sends web content back to the client.

4.1.1 System ArchitectureIn this subsection, we introduce the overall system ar-chitecture and the decision policy that the server appliesto prepare the response. Our approach is a client-serverbased system, as depicted in Fig. 9, similar to otherconventional web-browsing techniques. The details ofthe system are as follows:

Smart Browser: As shown in Fig. 9, the client ap-plication browser consists of six components, namely,User Interface, WebView engine, HTTP Header Han-dler, Network Interface Handler, Battery Level Lis-tener, and Connection Type Listener. The first fourcomponents exist in all browsers; we present themseparately to show exactly the internal basic compo-nents of conventional browsers, and how our systemcan be implemented in general. The function of eachcomponent is described in Table 4.

Smart Server: The server in our system can be anyHTTP server. We added a HTTP Header Parser to

extract the information that the browser includes inthe HTTP requests. Then, the information is passedon to the Decision and Response Preparation unit,where the policies are applied and decisions aremade based on the current available resources onthe smartphone. Next, a customized webpage isprepared and sent back to the client. The functionof each component is described in Table 5.

TABLE 4: Functions of the clients components

Component Description and FunctionUser Interface This displays what the user sees and inter-

acts with when running the browser.WebView engine This is an Android Java class that provides

browser-like functionalities.HTTP HeaderHandler

This handles the proposed modifications tothe HTTP requests header.

Network Inter-face Handler

This handles the HTTP requests that aremade by the browser.

Battery LevelListener

This obtains smartphone battery level everytime a user makes a web request, and passesit to HTTP Header Handler.

ConnectionType Listener

This gets the type of network that the smart-phone is connected to and passes it to HTTPHeader Handler.

Note that when a user wants to access a certainwebsite, the browser gets the Battery Level and Con-nection Type, modifies the HTTP header, and sends aHTTP GET request. On the server side, The serverreceives the request, extracts the information needed tomake the decision, applies certain policies, adopts thewebpage, and then sends the webpage to the smart-phone. Table 6 explains the policies that server appliesto make the adaptation decision. For instance, if a usermakes a page request when the phone Battery Levelis 75% and the Connection Type is cellular, the serversends an webpage with only textual ads. On the otherhand, if the phone Battery Level is 85% and the Con-nection Type is Wi-Fi, the server sends back the full

10



Fig. 10: HTTP header: (a) standard header; (b) modified header.

TABLE 5: Functions of the servers components

Component Description and FunctionNetwork Inter-face

This handles the received HTTP requests,and passes them to HTTP Header Parser.

HTTP HeaderParser

This component extracts the embedded in-formation from the received HTTP headerand then passes it to Decision and ResponsePreparation Unit.

Decision andResponsePreparationUnit

This unit applies certain policies and makesa decision about the type of web contentsto be sent to the client.

Web ContentRepository

This is a repository of the websitess re-sources (different versions of webpages).

version of the website, (including the ads), and so on.That is how the server basically works.

4.1.2 System ImplementationWe implemented a prototype system in which the clientside was implemented on the Android operating systemand the server side was implemented in Java.

4.1.3 Client Side ConfigurationThe adaptations that need to be made to the clientsbrowser are described next:

Battery Level Listener: This listeners function is toobtain the smartphones battery level every time auser makes a web request. The battery level is thenpassed on to the HTTP Header Handler. Modernoperating systems of smartphones gather this in-formation from the battery of the device via thecommunication pin, as we explained in Section 3.1.3.

Connection Type Listener: This listeners function isto identify the type of network that the smart-phone is connected to and pass it on to theHTTP Header Handler. This information is gath-ered by the operating system from the devicesprotocol stack that is being used.

HTTP Header Handler: This handler modifies theHTTP requests header. It inserts the battery leveland the type of network to the optional fields ofthe HTTP protocol header. Figure 10(b) shows howthe header looks after the new fields are addedto the standard HTTP header (Fig. 10(a).) Thesesnapshots are for our system, taken from Wiresharkto illustrate the modifications that the system makesto the HTTP packets.

TABLE 6: The servers applied policies

Battery Level(B)

Wi-Fi Cellular

(B) 70% Full version of web-pages

Webpages with onlytextual ads

40% (b)

An Energy-Bandwidth Aware Web

Documents

Transcript of An Energy-Bandwidth Aware Web