Energy-Aware QoS for Application Sessions across Multiple Protocol Domains in Mobile Computing

This article was originally published in a journal published byElsevier, and the attached copy is provided by Elsevier for the

author’s benefit and for the benefit of the author’s institution, fornon-commercial research and educational use including without

limitation use in instruction at your institution, sending it to specificcolleagues that you know, and providing a copy to your institution’s

administrator.

All other uses, reproduction and distribution, including withoutlimitation commercial reprints, selling or licensing copies or access,

or posting on open internet sites, your personal or institution’swebsite or repository, are prohibited. For exceptions, permission

may be sought for such use through Elsevier’s permissions site at:

http://www.elsevier.com/locate/permissionusematerial

http://www.elsevier.com/locate/permissionusematerial

Autho

r's

pers

onal

co

py

Energy-aware QoS for application sessions across multipleprotocol domains in mobile computing

Hanping Lufei, Weisong Shi *

Department of Computer Science, Wayne State University, 5143 Cass Avenue, Detroit, MI 48202, United States

Received 16 November 2006; received in revised form 11 January 2007; accepted 15 January 2007Available online 25 January 2007

Responsible Editor: I.F. Akyildiz

Abstract

The proliferation of heterogeneous devices and diverse networking technologies demands flexible models to guaranteethe quality-of-service (QoS) at the application session level, which is a common behavior of many network-centric appli-cations, e.g., Web browsing and Instant messaging. Several QoS models have been proposed for heterogeneous wired/wire-less environments. However, we envision that the missing part, which is also a big challenge, is taking energy, a scarceresource for mobile and energy-constrained devices, into consideration. In this paper we propose a novel energy-awareQoS model, e-QoS, for application sessions that might across multiple protocol domains, which will be common in thefuture Internet, rather than an exception. The model provides QoS guarantee by dynamically selecting and adapting appli-cation protocols. To the best of our knowledge, our model is the first attempt to address QoS adaptation at the applicationsession level by introducing a new QoS metric called session lifetime. To show the effectiveness of the proposed scheme, wehave implemented two case studies: Web browsing from a Pocket PC to a regular Web server, and an instant messagingapplication between two Pocket PCs. In the former case study, our approach outperforms the conventional approach with-out energy-aware QoS by more than 30% in terms of the session lifetime. In the second case study, we also successfullyextend the session lifetime to the value negotiated by two Pocket PCs with very diverse battery capacities.� 2007 Elsevier B.V. All rights reserved.

Keywords: Energy-aware; Quality of service; Application sessions; Protocol adaptation

1. Introduction

With the development of computer and commu-nication technologies, more and more heteroge-

neous devices, like desktops, laptops, Pocket PCs,and cellular phones are connected to the Internetusing diverse networks, like Ethernet, Wi-Fi, Blue-tooth, 3G/4G wireless technology. As mobile com-puting devices and wireless sensors are deployed inlarge numbers, the Internet will increasingly serveas the interface between people moving aroundand the physical world that surrounds them [1].Thus, we expect to see more and more applications

1389-1286/$ - see front matter � 2007 Elsevier B.V. All rights reserved.

doi:10.1016/j.comnet.2007.01.006

* Corresponding author. Tel.: +1 313 577 3186; fax: +1 313 5776868.

E-mail addresses: [email protected] (H. Lufei), [email protected] (W. Shi).

Computer Networks 51 (2007) 3125–3141

www.elsevier.com/locate/comnet

Autho

r's

pers

onal

co

py

that having multiple protocol domains involvedduring one application session. Each domain hasits own application protocol set from which theend user can select different protocols for specificapplication purpose. Traditional QoS can hardlysatisfy the requirements from the application ses-sion level which may dynamically switch betweenmultiple devices and network connections. Wedefine an application session as a session period tofinish an application level function. For example,in an instant messaging application session, a usermight use a laptop with a cable modem at home,a handheld device with 3G/4G or Bluetooth or evenDSRC [2] (Dedicated Short Range Communica-tions) on the highway to the office through intelli-gent transportation system [3], a desktop withEthernet LAN in the office and a PDA with satelliteradio on the airplane, to talk with another usersequentially. In this scenario, the application sessioncontains several switches between different devicesand networks. Although this is an extreme case, itshows that, on the one hand, diverse network con-nections and heterogeneous devices demand differ-ent application protocols, for instance the Gzipprotocol for low bandwidth network. On the otherhand, both ends of the session could be battery-powered devices. The energy limitation of two endsas well as network and device multi-modalities posenew challenges to traditional QoS models.

To attack the above challenges, we argue that thefuture mobile computing environment could consistof several different application protocol domains.Each domain has its own application protocol setfrom which the end user can select different proto-cols based on its proactive judgements to guaranteethe pre-negotiated QoS metric. Be aware of thenecessity of application-level QoS architecture, wepropose e-QoS, an energy-aware QoS model forapplication sessions. If an application session isacross multiple protocol domains, the peers on bothends need to negotiate a mutually interested QoSmetric through a gateway, which lies betweendomains (see details in Section 4), before the startof the session. Then the gateway evaluates the can-didate protocols for each peer and select one ormore protocols according to the peer side informa-tion, such as network bandwidth, remaining batterycapacity, and so on. Gateway also delivers the pro-tocol modules to the peer so that the protocols canbe deployed on the peer side. During the course ofthe application session, the gateway will monitorthe behavior of both peers and the performance of

the protocols. Later on, the parameters of the cho-sen protocols may be adapted or other new proto-cols could be brought into the session dynamicallyto satisfy the negotiated QoS metric.

We emphasize energy in the design of the e-QoSmodel. A new concept, session lifetime, which is tiedup together with energy, is defined as a new QoSmetric. The protocol selection and adaptation meth-ods for maximizing the session lifetime QoS metricare proposed as well. Specifically our contributionsof this paper include:

1. Proposing a general model for application session

QoS in intelligent transportation systems – Toour knowledge, This paper is the first effort toaddress the application session QoS managementusing application protocol selection and adapta-tion. With the appearance of more and moreapplication level protocols, such as SOAP [4],LDAP [5], and Plugins, their impact on QoS met-rics have to be studied and utilized for applica-tion session QoS. Dynamically selecting andadapting the necessary application protocols inan on-demand manner is applicable for thefuture application sessions QoS model.

2. Defining an energy-aware QoS metric, session life-

time, and proposing the enforcement methods –Energy is managed in terms of a QoS metric, ses-sion lifetime, in our model. In this way, it is notonly manipulated locally on one end butextended to both ends of the application session.Most of the current energy related efforts onlyaddress the client-side management.

3. Dynamically adapting at the application protocol

level – Most of proposed protocol adaptationmethods [6–10] work at or below the networklayer. Such systems can cope with localizedchanges in network conditions but cannot adaptto variations above the network layer. Anyapproach that requires the MAC or networklayer modifications has to face the deploymentchallenge since all involved machines have tochange their protocol stack in order to takeadvantage of the improvement brought theapproach. Although application level adaptationbrings an extra overhead, comparing with thenetwork and MAC layer approach, the evalua-tion results with two case studies show that theeffect of our approach on system performance isin no way to be significant. In terms of powermanagement, most of existing approaches [11–14] need either extra new hardware or major

3126 H. Lufei, W. Shi / Computer Networks 51 (2007) 3125–3141

Autho

r's

pers

onal

co

py

operating system modifications which are abovethat some mobile devices can afford. Our modelperforms entirely in the application level. Fur-thermore, with the gateway handling most ofthe computing workload, e-QoS has very light-weight footprint on the user end.

4. Designing and implementing two energy-aware

application: Pocket PC to Web server browsing

and instant messaging between two Pocket PCs –Several protocols are developed for these twoapplications. Experiment results show that thesession lifetime has been successfully extendedto the value negotiated by two peers even withvery diverse battery capacities.

The rest of the paper is organized as follows.After a brief introduction of terminologies and con-cepts in Section 2, energy-aware QoS metrics arepresented in Section 3. System design is depictedin Section 4. Section 5 evaluates the system usingtwo case studies as the Pocket PC to Web serverbrowsing and an instant messaging applicationbetween two Pocket PCs. Finally, related workand conclusions are listed in Sections 6 and 7respectively.

2. Terminologies and concepts

Before describing the energy-aware QoS metrics,we first introduce some frequently used terminolo-gies and concepts in the following context.

2.1. Session-based application

On the Internet many applications are session-based. An application session is either a lasting con-nection at the session layer or application layerbetween peers, typically a server on one side, anda user on the other side. A session is typically imple-mented as a layer in a network protocol, like Telnetor FTP. In other cases sessions are maintained by ahigher level program using a method defined in thedata being exchanged. For example, an HTTPexchange between a browser and a remote hostmay include an HTTP cookie which identifies state,such as a unique session ID, information about theuser’s preferences or authorization level, and so on.These kinds of sessions are maintained in applica-tion level by application programs. On the contrary,some applications do not have sessions. Forinstance, sending out an email does not maintain a

session in the procedure. In this paper we only con-sider the session-based application.

2.2. Application-level protocol

A protocol is the format to express informationso that others can understand the information. Wedivide the protocol into two groups, the networkprotocol and the application protocol, correspond-ing to the network layer and application layerrespectively. As an example, Gzip is a popularapplication level protocol used in Web contenttransmission as shown in Fig. 1. The Web servercompresses the Web page using Gzip algorithm thensends it to the Web browser, after the browser suc-cessfully receives the zipped Web page, it will usethe Gzip algorithm to unzip it and get the originalWeb page. In this paper, we only address the appli-cation level protocol in our e-QoS model. Com-pared with the QoS models in route or MAClevel, the application level QoS model can handlethe quality metrics above the route level or theMAC level, for example, the image size.

In this paper, a protocol is described as a collec-tion that consists of the implementation algorithm,the delay, quality, and power profiles as follows:

Protocol ¼ fAlgorithm;Delay Profile;

Quality Profile;Power Profileg:

With this definition, when a protocol is evaluated,its influence on the application session qualitiescan be quantified. For instance, how much timehas to be spent on the execution of the protocol,how much power it will consume, and so on.

2.3. Protocol domain

In this paper we introduce an overlay conceptcalled protocol domain, which is inspired by recent

Zip-Unzip Protocol

Web Server Web Browser

Zipped Web Page

Original Web Page

Unzip

Original Web Page

Zip

Zipped Web Page

Fig. 1. An example of application-level protocols.

H. Lufei, W. Shi / Computer Networks 51 (2007) 3125–3141 3127

Autho

r's

pers

onal

co

py

work on delay-tolerant network (DTN) [15] and theproliferation of mobile devices and wireless sensornetworks [16]. DTN defines delay-tolerant networkgateways interconnected regions that runningpotentially dissimilar protocol stacks. Althoughthe protocol domain we defined here is similar toregion in [15], our protocol domain mainly worksat the application level. In each domain, some pro-tocols are available for the application optimiza-tion. Fig. 2 shows an example of one protocoldomain with some peers connected with a protocoldomain gateway. The gateway locates on the edgeof the domain. It holds those available protocols.Each peer negotiates with the gateway to get a suit-able protocol and download it from the gatewayaccording to the application QoS requirement andother situations like the network speed and peerdevice configurations. The protocol domain isintended to operate above the existing networkarchitectures.

The structure and functions of the gateway willbe presented in Section 4.2. A typical sensor net-work is a protocol domain in which all the sensorsconnect with the sink node that acts like a domaingateway. An ad-hoc network built for disaster res-cue is another example of protocol domain. ForInternet applications, the current ISP providercould be a good candidate of the gateway becauseall the service subscribers need to connect to theISP controlled nodes to access the outside Internet.Although right now the ISP only provides the net-work layer connection service, we believe with theemergence of more and more diverse computingdevices on the network and new applications, pro-viding and adapting application-level protocol tomeet application requirements is a must-have func-

tion of the future Internet service provider as envi-sioned in [16].

3. Energy-aware QoS metrics

In e-QoS we extend the QoS to the applicationsession level. It is orthogonal to the network levelQoS which may not be able to view the applicationlevel information, like the power capacity. With theprevalent of handheld and pervasive computingdevices into our daily life, limited battery capacityis a serious impediment to the widespread adoptionof running popular applications, e.g., Web Brows-ing, on this kind of battery powered devices. Byobserving this dilemma, we consider energy as amajor priority in the design of our proposed QoSmodel. First let us have a look at the energy-awareQoS metrics.

3.1. Session delay

Delay time is a very sensitive metric for networkrelated application sessions. Session delay is causedby many reasons, such as traffic congestion, lowmemory, slow hard drive, and so on. Here we onlyconsider the session delay triggered by different algo-rithms, or in other words, different application levelprotocols. Utilization of each protocol will incursome delay. Formula (1) shows the evaluation of ses-sion delay, which consists of the delay incurred byeach involved protocol in the application session.Each individual protocol delay includes severalparts, like computing delay and network delay. In[17] several comprehensive formulas and evaluationmethods are introduced for delay time of each appli-cation protocol

Delay ¼Xn

i¼1

Protocoldelayi : ð1Þ

3.2. Session quality

Content quality is another crucial QoS metricespecially for some application sessions, like multi-media stream or image transmission. In our model,the quality of each protocol is defined in Formula(2). The original fidelity represents the original dataquality, e.g., the original image dimension. The out-put fidelity is the output data quality after applyingthe protocol, e.g., the reduced image dimensionafter the content adaptation protocol. The ratioshould be between 0 and 1. The quality of the ses-

Gateway

ProtocolDomain

Fig. 2. An example structure of a protocol domain.


Autho

r's

pers

onal

co

py

sion is defined as the product of involved protocolsqualities in Formula (3).

1 P Protocolqualityi ¼ adapted fidelity

original fidelityP 0; ð2Þ

Quality ¼Yn

i¼1

Protocolqualityi : ð3Þ

3.3. Session lifetime

Session lifetime is a new concept we introduced inour paper. As we defined, an application session isthe procedure of executing an application function.Then session lifetime is the time period from thestart to the end of the application session as shownin Eq. (4). Note that the session lifetime is decidedby many factors, like the remaining battery capac-ity, power profiles of involved protocols, even userbehaviors, and so on. Some other protocols haveconstant impact on the session lifetime, for instance,the screen brightness, if we consider it as an applica-tion protocol between peer and gateway. Usually, iftwo ends of a session select the session lifetime astheir mutual QoS metric, they will negotiate anexpected lifetime value at the first place. Then ourQoS model tries to satisfy Formula (5). In orderto do this, dynamic selection and adaptation of pro-tocols are necessary. To the best of our knowledge,this is the first energy-aware QoS metric defined forapplication sessions

Lifetimereal ¼ Timeend � Timestart; ð4ÞLifetimereal P Lifetimeexpected: ð5Þ

3.4. Session QoS space

We define a three dimensional session QoS spaceto manifest the relations between these three qualitymetrics. For each point in the space, it correspondsto the selected protocols for the session. In Fig. 3,QoS point PA represents those protocols, fromprotocol 1 to protocol n, that are included in theapplication session. QA, DA and LA are the corre-sponding session quality, delay, and lifetime respec-tively. However different set of selected protocolsmay affect other two QoS metrics. For example,given LA as the expected session lifetime, some pro-tocols will be selected based on their power profile sothat the total session lifetime will be optimized to beclose to LA. Consequently, we can get the QA and DA

related with LA. It is possible that another QoS point

P 0A set of protocols may also achieve the same QoSmetric value LA but with Q0A and D0A different fromQA and DA. In summary, if the user of the sessionspecifies one QoS metric, there exists a mechanismto select appropriate protocols from the candidatesto satisfy the specified QoS metric. In Section 4 wewill explain this mechanism in more details.

4. System design

Now we are in a position to present the design ofthe system. After an overview, we in turn cover thegateway structure, the QoS negotiation procedure,and the protocol adaptation policy.

4.1. System overview

Our system works at the application level. Ageneral scenario is shown in Fig. 4, there are three

SessionQuality

SessionDelay

SessionLifetime

QA

DA

LA

DA'

QA'

PA { Prot 1, Prot 2, Prot 3, ... }

PA' { Prot a, Prot b, Prot c ... }

Fig. 3. The session QoS space.

ProtocolDomain1

Gateway

Gateway

ProtocolDomain3

ProtocolDomain2

Fig. 4. An overview of the system architecture.


Autho

r's

pers

onal

co

py

protocol domains on the overlay network. The pro-tocol gateway bridges different protocol domains. Ifpeer A in domain 1 wants to start an applicationsession with peer B in domain 2, they need to nego-tiate through the protocol gateway which connectsdomain 1 and domain 2. Based on their mutualQoS requirements the gateway then chooses differ-ent protocols according to their diverse conditionslike network speed, remaining energy capacity,and so on. After both peers download and installthe protocol modules, they can start the applicationsession under the surveillance of protocol gateway.Note that it is possible that two peers in not adja-cent domains want to start an application session.For instance the peer in domain 1 wants to talk witha peer in domain 3 in Fig. 4. In this situation, thereis a path along multiple gateways from one peer toanother. One solution could be that the first and lastgateway on the path do the protocol selection andadaptation for his own peer. The gateways in themiddle of the path just receive and forward the ses-sion data. More complex approach can involve allof the gateways on the path to do the adaptation.How to handle the cases that involve multiple gate-ways is our next step. Next, we will introduce thestructure and functions of the gateway.

4.2. Gateway structure

Gateway plays an important role in the system. Itis in charge of negotiating QoS metrics and proto-cols with the peers, delivering protocol modules tothe peers, monitoring the procedure of applicationsessions, and adapting the protocols dynamically.In order to finish these functions, gateway needsto know some peer side information, such asremaining energy, network bandwidth etc. Wedefine them into the format of different metadataas shown in Fig. 5. The device metadata definessome parameters related to the QoS metrics, likeremaining battery percentage, screen brightness,etc. Network metadata is also required in the nego-tiation procedure. Session metadata records the

metadata of included protocols. A general structureof the gateway is shown in Fig. 6, which includes anegotiator, a distributor, a session monitor, and aproxy. Each part is running as a daemon on thegateway. Next we will explain the structure andfunctionality of each module respectively.

The negotiator receives the session and QoSrequests from one peer and forwards to the peeron the other side. After both sides make an agree-ment on the QoS metric, the negotiator will startselecting the proper protocols to satisfy the QoSmetric. In order to show the function of negotiatormore clearly, in the next section we will go throughthe whole QoS negotiation procedure. After thenegotiation is done, it is the distributor’s job to deli-ver the protocol modules to each peer. This is simi-lar to the plugin downloading in Web browser. Forthe secure execution of the downloaded modules onpeer side, several existing security mechanisms canbe applied, like digital signature, sandbox, andvirtual machine monitor. Therefore we will not pro-pose any new security approach for the deploymentof protocols. After the application session starts, theproxy handles protocol translation, content adapta-tion, session data caching, and so forth. Forinstance, one peer uses compression protocol tozip the text data while the peer on the other side justuses plain text. Proxy has to zip the text on one wayand unzip the text on the other way. There is a cache

Fig. 5. Definitions of metadata.

Distributor

Negotiator

Proxy

Monitor

Cache

Fig. 6. The structure of gateway.


Autho

r's

pers

onal

co

py

in the proxy, which is for the temporary storage ofthe session data in case that peers send or receivedata asynchronously. Finally, the monitor beginsto monitor the application procedure from thebeginning of the session by periodically samplingthe peer status. In Section 4.4, the protocol adapta-tion policy used by the monitor will be presented.Next, we will explain the QoS negotiationprocedure.

4.3. QoS negotiation procedure

Generally, the QoS negotiation procedureperforms in two steps. First, two peers discuss andsettle down a mutual QoS metric. Second, accordingto peer’s situation, like device and network meta-data, the gateway selects protocols for each peer.An interactive negotiation protocol (INP) is pro-posed for the interactions between peers and gate-way, as shown in Fig. 7. We assume both the peerside and gateway side understand the protocol defi-nitions. This can be easily implemented by runninga light client stub program on the peer side.

At the beginning of the negotiation, the peer Adecides to start an application session with the peerB. By specifying the application and desired QoSmetric value in the client stub program, peer A firstsends INIT_REQ, which contains applicationrequest and QoS metric value in payload, to thegateway to initialize the protocol negotiation. Eachpacket has an INP header segment, which is used tomaintain the interactive negotiation protocol integ-

rity, and we will omit the details in the INP header.The gateway then sends back the INIT_REP as wellas PEER_META_REQ, having empty DevMeta andNtwkMeta to be filled by the peer A, to acknowl-edge the request and ask some information aboutthe peer. At the same time, gateway will forwardthe INIT_REQ together with PEER_META_REQ topeer B to get his feedback about the QoS metricproposed by peer A and his metadata information.After receiving the reply, the client stub programrunning on each peer will get the content of Dev-

Meta and NtwkMeta by locally probing the systemusing system calls. PEER_META_REP, containingthe collected metadata, is finally sent back to thegateway in step 3. If peer A and B can not makeagreement on the QoS metrics, steps 1–3 will berepeated. Based on the QoS metric value and meta-data, the negotiator in the gateway will computeand select some protocols for peer A and peer Bin step 4. Note that peer A and B may not be pro-vided with the same protocols because of theirdiverse situations. Then it is the distributor’s jobto deliver the protocols to each peer in step 5 ifthe protocol needs the peer side deployment. Forsome protocols it may not require any deploymenton the peer side. For example, gateway only sendsimage with dimension up to 200 · 300 to peer B, ifincoming image from peer A is bigger, proxy willdo the content adaptation before forwarding to peerB. Therefore, peer B may not even know the exis-tence of this protocol happened between himand the gateway. After the security check andprotocol deployment, the peer A sends out theSESSION_REQ to a proxy and monitor demons thatare created by the gateway for this session in step 6.The SESSION_REQ contains the real applicationsession related request. From now on the peer Aand B continue the application session using thedownloaded protocol. The formats of all messagetypes used in INP are listed in the bottom of Fig. 7.

Selecting the protocol in step 4 is the key part ofthe QoS negotiation procedure. Although the mon-itor module can probe the peers periodically in theapplication session and adapt the protocol dynami-cally to fulfil the QoS metric, the accuracy of origi-nal selection of protocols greatly decides theprobability of finally successful QoS provision.From the QoS space’s point of view, given themutual QoS metric of peer A and B, gateway is ableto find a QoS point supported by some protocols toachieve the selected QoS metric and optimize othertwo as much as possible, as we have seen in Fig. 3

Peer AG Gateway Peer B

INIT_REQ

PEER_META_REQ

Selectprotocolsfor each peer

PROTOCOL_DOWNLOAD

Deploy protocols

SESSION_REQ

INIT_REQ

INP header Session Req

PEER_META_REQ

INP header Metadata Req

PEER_META_REP

INP header

SESSION_REQ

Session Data Req

DevMeta NtwkMeta

PROTOCOL_DOWNLOAD

ProtocolModuleINP header ...

INP header

INIT_REQ

PEER_META_RE

Q

PEER_META_REP PEER_META_RE

P

QoS Metric

PROTOCOL_D

OW NLOAD

SESSION_REQ

Deploy protocols

SESSION_REP SESSION_REP

ProtocolModule

SESSION_REP

Session Data RepINP header

Negotiator

Distributor

Proxy &Monitor

INIT_REP

QoS Metric

Fig. 7. The interactive negotiation protocol.


Autho

r's

pers

onal

co

py

for one peer. Since the QoS metric is the mutualinterest of both peers, the gateway needs to combinethe two QoS spaces jointly at the mutual QoS metricaxis as shown in Fig. 8. Two QoS points that map tothe same value on the mutual QoS metric axis willbe found in the joint QoS spaces. In the Fractalframework [17], Lufei and Shi have proposed thenotion of protocol adaptation tree and an adapta-tion path search algorithm to find the set of proto-cols to achieve the minimal delay time. Itorganizes the protocols as a tree structure in whicheach protocol is a node except root. Similarapproach can be used to evaluate the best sessionquality. In two QoS joint space, Fractal’s methodcan still be applied to achieve specific delay timeor quality metric. However, as far as the session life-time is concerned, Fractal’s method does not per-form well because it can not react to theunpredictable user behavior which influence the ses-sion lifetime substantially. We tested several proto-col’s power profiles for some typical batterypowered devices and observe that a priority-basedprotocol selection together with the curve fittingdynamic protocol adaptation is an efficient tech-nique to guarantee the session lifetime QoS metriceven in some unpredictable user behavior situ-ations. In evaluation section, we will give a thor-ough description.

4.4. Protocol adaptation policy

Dynamic protocol adaptation is supposed to beexecuted by the monitor module. One assumption

is that the monitor should be able to probe the‘‘pulse’’ of peers, including device metadata and net-work metadata. The probe frequency is determinedby the monitor according to application sessions.The monitor can pick one sample frequency in thebeginning and dynamically change the frequencyaccording to the adaptation effect. For delay andcontent quality QoS metrics, repeating the selectionprocedure of the protocol will assure the satisfactionof the metrics, thus it is not the focus of this paper.While for the session lifetime metric, only repeatingthe selection procedure is not enough, a new adap-tation approach is necessary.

We observe that most modern Lithium-Ion bat-teries follow the similar pattern on the remainingbattery versus time curve (Fig. 9 in Section 5). Byfitting the curve with the linear or polynomial func-tion, the expected current remaining battery per-centage, which is the indicator of the sessionlifetime, can be estimated at any sampling time inthe session lifetime. With this reference batteryremaining percentage, the monitor module caneither adapt the protocol parameters on the proxyor peer side, or find a new protocol for the remain-ing session lifetime. Obviously, the adapt frequencyand the intensity of the adaptation will greatly affectthe stability of the system and the user experience,which is our future work. In the next section we willanalyze the power profile curve pattern, give out afast but effective segmented curve fitting linearfunction.

5. Performance evaluation

To evaluate the effectiveness and efficiency of ourmodel, we implement two case studies, Pocket PC toWeb Server browsing and instant messagingbetween two Pocket PCs. The session lifetime isset as the QoS metric. For other QoS metrics, like

End ASessionQuality

End ASession

Delay

SessionLifetime

End ASession

QoS Point

End BSessionQuality

End BSession

Delay

End BSession

QoS Point

End BSession

QoSSpace

End A Session QoS Space

Fig. 8. The joint QoS spaces of two peers.

2030405060708090

100

0 10 15 20 25 30 35 40Time (Thousand Seconds)

Perc

enta

ge B

atte

ry R

emai

ning

0% brightness

25% brightness

50%brightness

75%brightness

100%brightness

5

Fig. 9. The power profiles of different screen brightness.


Autho

r's

pers

onal

co

py

session delay, our previous work [17] presentsenough experimental results. Before move on tothe case studies, we examine the power profiles ofsome potential protocols and the segmented curvefitting method.

5.1. Protocol power profiles

We test several protocol sets on a battery pow-ered Pocket PC, HP iPAQ h4150. LCD backgroundlight is one culprit for rapid battery draining in dailyusage. Choosing correct screen brightness scale is aprotocol between a peer and the gateway. Powerprofiles of different brightness are shown as Fig. 9.The x-axis shows the time in thousands of seconds,the y-axis corresponds to the remaining battery per-centage. The 100% brightness lifetime which standsup for 3.8 h is shorter than that of any other bright-ness options. The smaller the brightness is, thelonger the lifetime could be. Finally, 0% brightnesslasts up to 40,000 s, approximately 11 h.

Wireless network interface consumes significantpower on Pocket PC [18,19]. The HP iPAQh4150 has an integrated 802.11g wireless card.We test the continuous sending, receiving, and idlepower profile as shown in Fig. 10. We can see that,first of all, idle state power consumption is small.Its power profile is comparable with that of 0%brightness in Fig. 9. However the send and receivelifetime is only roughly one third of the idle case.Then another question is which one is more energyconsuming between sending and receiving. Fig. 11answers the question. With the same energyconsumed, receiving transfers more than 2000MBytes, about four times of the transfer size ofsending.

Furthermore, for sending and receiving, wetested two different methods as shown in Table 1.Note that Energy is presented as the percentage ofbattery capacity. A lower level parameter, e.g.,power reading, may be more useful, however, wethink our definition is acceptable since we are usingthe same device. The first method is that no persis-tent connection is used. The second one is using per-sistent connection plus the large chunk. Take thesending scenario as an example, if there are 10 appli-cation session data packages each with size of 200bytes. The total size is 2000 bytes. In the firstmethod, the connection between peers is setup andtear down 10 times, each time one 200-byte packageis sent out. For the second method, the connectionis established only once. The large chunk methodcombines the 10 packages into one large chunk as2000 bytes and sends it out. The different energyand time consumptions of these two methods arecompared in the table. Similar differences are shownalso for the receiving scenario. It is easy to see thatthe first method, no persistent connection, incursmuch more energy and time consumption comparedwith the second method, persistent connection pluslarge chunk.

In summary, the screen brightness and wirelessinterface are two major energy consumption parts.Based on this observation, we come out severalprinciples for the protocol adaptation: first, chooseas low screen brightness as possible; second, reducethe connection times; finally, transfer as much dataas possible in one connection. We also evaluateother algorithms power profile for their possible uti-lization in the case study, such as Gzip, which powerconsumption is comparable with that of the 100%brightness screen, so that it is too high to beselected. Therefore in our following case study

20

30

40

50

60

70

80

90

100

0 10 15 20 25 30Time (Thousand Seconds)

Perc

enta

ge B

atte

ry R

emai

ning

Idle Network

Send

Receive

5

Fig. 10. Power profiles of send, receive, and idle network regardstime.

20

30

40

50

60

70

80

90

100

0 500 1000 1500 2000 2500Transfer Size (MBytes)

Perc

enta

ge B

atte

ry R

emai

ning

Send

Receive

Fig. 11. Power profiles of send, and receive regards transfer size.


Autho

r's

pers

onal

co

pygateway basically selects and adapts protocolsrelated to screen brightness, connection persistence,large chunk, and content adaptation which happenson the proxy side with unlimited power supply. Incase study we will give more description aboutinvolved protocols.

5.2. Curve fitting in protocol adaptation

Session lifetime has different nature as sessiondelay. If one peer does not send anything out, thereis no session delay. But energy keeps reducing aslong as the machine is still on. Furthermore, the ses-sion lifetime could be seriously compromised if peerstarts other unrelated energy consuming process.Consequently, energy and protocol must be moni-tored and adapted periodically. Our analysis in theabove subsection implies that they share a similarpattern, which includes a pure flat start stagefollowed by a roughly linear regression as shownin Fig. 12. Let us use t1 to denote the flat stage timeperiod, t3 for the total time, b for the bottom bat-tery percent, in previous figure, b = 20%. t2 is theknot point between t1 and t3. m is an adjustmentamount bigger than 0 so that the fitting curvebetween t1 and t3 is not one line but two segmentedlines which can fit the real power profile curve moreaccurately. c ¼ t1

t3 and m are relatively stable value

set as c = 11% and m = 10. Based on the predictedenergy percentage value generated from this curvefitting method, we can adapt the protocol parameteraccordingly. Let the initial battery percentage be I,the expected session lifetime be t3. For given c, m,b, I, and t3, we can use the following formulas tofind t1, t2, and a, b, which are slopes of the fittinglines of t2t3 and t1t2.

In case that I = 100: t1 = c · t3, t2 ¼ 1þc2� t3,

a ¼ 100�b�2�mð1�cÞ�t3 , b ¼ 100�bþ2�m

ð1�cÞ�t3 .

In case that 50þ b2� m < I < 100: b ¼ I�bþ2�m

t3 ,

t2 ¼ I�b2þm�50

b , a ¼ 50�b2�m

t3�t2 .

In case that 50þ b2� m P I : a ¼ I�b

t3 .We use the curve fitting method to represent the

energy consumption model for portable devices.The approach looks simple, however, it works wellin our two case studies as shown in the followingsections. We are aware of several power consump-tion and management efforts, such as CASTLE[25], EcoSystem [14] and so on. Nevertheless, theyneed either extra new hardware or major operatingsystem modification, which are above that mostmobile devices can afford. On the country, ourmodel performs entirely in the application level,and easy to use. Furthermore, with the gatewayhandling most of the computing workload, themethod has almost unnoticeable lightweight foot-print on the mobile device side.

5.3. Case study 1: pocket PC to web server browsing

session

In first case study, one peer is a Pocket PC with100% battery power. On the other side is a Web ser-ver with unlimited power. The experimental plat-form and hardware configurations are shown inFig. 13. Gateway and Web server are on the samelaptop with unlimited AC power supply. There arestatic Web pages on the Web server. Each pageincludes one 26KB HTML file and five 600 · 600

Table 1Energy and time consumption of different send and receive methods

Methods Size (bytes) Energy (batt percent, 80 · 10�6%of battery capacity)

Time (s)

Send No persistent connection 200 · 10 10,580.47 1041.12Persistent connection + Large chunk send 2000 361.53 37.98

Receive No persistent connection 50,000 · 10 76.15 7.43Persistent connection + Large chunkreceive

500,000 18.59 1.56

gt1 t2 t3

m

Time

Perc

enta

ge B

atte

ry R

emai

ning

b

100

100-b2

100-b2

β

Fig. 12. The segmented linear curve fitting method.


Autho

r's

pers

onal

co

py

52KB images. In the following experiments, the bot-tom battery percentage is set as 20%. In the first test,peer has 100% initial battery percentage, 75% screenbrightness, no connection persistence, and requestsa Web page every 1 minute. As a base case, thereis no QoS, no protocol selection and adaptation.The result is shown as the original curve inFig. 14. The Pocket PC lasts around 11,500 s beforethe battery reaches the bottom capacity.

The second test uses only the protocol selectionfunction but without the protocol adaptation. Theprotocols defined for this case study is shown inTable 2. Besides protocol algorithm or name,power, delay, and quality, the priority and adapt-ability are also listed for each protocol. Since screenbrightness is one of the most energy consumingcomponent, its priority is set to 0, as the highest pri-ority, which means the expected session lifetime willbe estimated according to the power profile of thisprotocol. Based on Table 1, connection persistenceplus large chunk (CPLC) protocol is the defaultselection since it reduces energy consumption with-out the delay and quality deterioration. Contentadaptation, for this case, the image size adaptation,does not consume Pocket PC energy since it is done

on proxy. For delay time, we consider it as negligi-ble for the powerful gateway machine unless it is inextreme heavy load. We will address the capacity ofgateway in Section 5.5. Regards quality, contentadaptation changes the original image dimensioninto 10%, 50%, or keep the original size.

In the beginning of the negotiation procedure,the stub program on Pocket PC will prompt userto input his QoS metric and desired value asFig. 15a shows. Suppose user inputs session lifetimeand specifies 4 h 26 min and 20 s, or 16,000 s as ses-sion lifetime, the negotiator will check the high pri-ority protocol, the screen brightness power profile.Lifetime of 50% brightness is close to the specifiedsession lifetime. Then a message box on peer sideinforms user to change the screen brightness to50%. Connection persistence protocol module isalso downloaded and deployed on the client sidebefore session starts. Now, the 50% screen bright-ness and CPLC protocols are selected without adap-tation. The energy versus the session lifetime isillustrated as the right curve in Fig. 14. It shows thatthe selected protocols successfully extends the life-time to the specified value, just above 16,000 s,which is about 30% more than the original one.

In above scenario, however, we assume that userkeeps the sending frequency as exactly one page perminute as the bottom line shows in Fig. 16 in whichthe x-axis is the time and the y-axis is the userrequest frequency in the number of Web pages perminute. It is unrealistic to require a user to browsethe web page at a constant rate. More practically,if the user changes his behavior by following thedynamically changing rate as the top curve (burst-like) in Fig. 16, it is possible that the previousmethod will fail to satisfy the expected session life-time. In this case, the protocol adaptation is thekey to alleviate the extra energy drop incurred bythe dynamic user behavior and save the session life-time. Therefore, the top curve in Fig. 16 is used asthe user behavior input in the next test. The curvefitting method has c = 11%, m = 10, b = 20 andinput as I = 100, t3 = 16000. Calculated from thecurve fitting equations, t1 = 1760, t2 = 8880,a = 0.004213, and b = 0.007022. The probe fre-quency is one sample per 160 s. The adaptation pol-icy works as follows: if the sample energy is less thanthe predicted value generated from the curve fitting,by 2% (of the battery capacity) or more, we bringthe content adaptation protocol into the systemand begin reducing the dimension of the imagesuntil reach the 10%, then reduce the screen bright-

ProtocolDomain 1

Gateway

ProtocolDomain 2

WebServer

DellLaptopP4 3.2GHz512M RAM

10/100Mbps NICWindows XP

HP iPAQ h4150IntelPXA255 CUP

64M RAM11g WL AN Adapter240X320 TFT

Windows CE 4.20

802.

Peer

Fig. 13. The configuration of experimental platform for casestudy 1.

Time (Thousand Seconds)

Perc

enta

ge B

atte

ry R

emai

ning

Original

50%Brightness + CPLC without adaptation

100

90

80

70

60

50

40

30

200 2 4 6 8 10 12 14 16 18

Fig. 14. Power profiles for constant web page request rate.


Autho

r's

pers

onal

co

py

ness one level down each time. On the contrary, ifthe sample energy is more than the predicted valueon the fitting curve, by 3% or more, the image sizeis increased if it is below 100% before brightness isenhanced. The effect of adaptation is clearly shownon the top curve in Fig. 17. It starts with the sameprotocols, 50% brightness and CPLC as the topcurve in Fig. 14. Each triangle point is the momentof content adaptation. Each circle point marks thescreen brightness adaptation moment. The legenddemonstrates the sequences of these two adapta-tions. Each bar in the legend corresponds to onevertical line in the figure. By four adaptation periods

happened at around 2.5, 8, 12, and 16 thousand sec-onds, the session lifetime is extended to 17,500 sbeyond the expected value, 16,000. For comparison,two approaches used in Fig. 14, original and 50%brightness plus CPLC without adaptation are alsotested under the dynamic user behavior. The bottomtwo curves in Fig. 17 are their performance curves.None of them can really satisfy the specified sessionlifetime, 16,000 s. The adaptation approach outper-forms the original one by more than 7000 s andanother one (CPLC) by more than 3000 s.

5.4. Case study 2: pocket PC to pocket PC instant

messaging

Nowadays more and more communicationsoccur between two handheld devices. In this case,we study the instant messaging session betweentwo Pocket PCs with different battery capacities.The experiment platform and hardware configura-tions are shown in Fig. 18, where two Pocket PCpeers in different protocol domains want to setupan instant messaging application session throughthe gateway. The two protocols used in this casestudy are described in Table 3. Besides the screenbrightness, a message combination protocol is intro-duced. Usually, in instant messaging application,people send and receive text information in a short

Table 2The protocols used in case study 1

Protocol Priority Power Delay Quality Adaptability

Screen brightness 0 battery percent

tested lifetime0 25%, 50%, 75%, 100% Yes

Connection persistence + large chunk (CPLC) 1 Very small 0 1 NoContent adaptation 2 0 Very small 10%, 50%, 100% Yes

10%

50%

100%

Content AdaptationSequence

100%

0%

50%

25%

75%

Screen BrightnessSequence

Perc

enta

ge B

atte

ry R

emai

ning


Original

50% Brightness + CPLC without adaptation

50% Brightness + CPLC with adaptation

100

90

80

70

60

50

40

30

200 2 4 6 8 10 12 14 16 18

Fig. 17. Power profiles for dynamic request rate.

Fig. 15. Screen snapshots of (a) QoS metrics specificationinterface and (b) screen brightness adjustment message box.


Dynamic request rateConstant request rate

Req

uest

Pag

es /

Min

0

5

10

15

20

25

30

0 6 10 12 14 162 4 8

Fig. 16. Dynamic and constant Web page request rates.


Autho

r's

pers

onal

co

py

time period. In order to save energy, the messagecombination protocol prevents the peer from send-ing and receiving messages too frequently. Instead,it caches the sending messages for a while and sendsout multiple messages in one time. The cache inproxy is also used to cache the receiving messagesfor peers. This technique is very useful in delay tol-erant network and peers with intermittent connec-tion. The number of cached messages is called themessage combination length, which is decided bythe protocol adaptation policy. The bigger it is,the more energy could be saved, also the more delaywill be observed and the more bytes have to betransferred in one time.

We assume that peer A has 60% battery and peerB has 40% battery. Their expected session lifetime is7000 s. Based on the screen brightness protocol,negotiator chooses 75% brightness for peer A and25% brightness for peer B. We assume both peerssend and receive one 256 bytes message in each3 s. Without the protocol adaptation function, noneof them can really reach the pre-negotiated sessionlifetime as we can see in Fig. 19. Then the curve fit-ting is used with parameters as c = 11%, m = 10,b = 20 and t3 = 7000, I = 60, t2 = 1166, a =0.005142, b = 0.008571 for peer A, and t3 = 7000,I = 40, a = 0.002857 for peer B.

The protocol adaptation policy works as follows:if the energy is below the predicted value by 1% (ofthe battery capacity), gateway reduces the screenbrightness protocol parameter before increase themessage combination length. Otherwise, in case ofthat the remain energy is beyond the predicted value

by 1% (of the battery capacity), the message combi-nation length is reduced if it is not 1 before thescreen brightness is increased. The performance ofdynamic adaptation for peer A is shown inFig. 20. In the legend, each triangle point is themoment of the screen brightness adaptation. Eachcircle point marks the message combination adapta-tion moment. The legend demonstrates thesequences of these two adaptations. Each bar inthe legend corresponds to one vertical line in the fig-ure. The legend in Fig. 20 shows the adaptationsequences according to the adaptation pointsmarked on the curve. By a series of screen bright-ness and message combination length adaptation,the session lifetime is extended to 7000 s. The max-imum message combination length is 32, whichmeans system combines 32 messages together intoone package. If user sends out one message per3 s, he will feel the delay as 32 · 3 = 96 s, aroundone and half minutes, which is acceptable.

For peer B, Fig. 21 shows that a sequence of mes-sage combination length adaptation contributes tothe extension of the lifetime. In the legend, the peaklength of the combination is 128 message. The cor-responding delay is 128 · 3 = 384 s, approximately6 minutes. Although it is relatively long, we thinkit is acceptable for two reasons. First, the sessionlifetime is greatly extended compared with the origi-nal scenario. A trade-off must be made betweenenergy and delay. Second, most mobile devicesexperience short disconnected time in the real

Table 3The protocols used in case study

Protocol Priority Power (batt percent/time) Delay Quality Adaptability

Screen brightness 0 battery percent

tested lifetime0 25%, 50%, 75%, 100% Yes

Message combination 1 Very small Long 1 Yes

20

30

40

50

60

0 1 2 3 4 5 6Time (Thousand Seconds)

Perc

enta

ge B

atte

ry R

emai

ning

Peer A60% battery75% brightness

Peer B40% battery25% brightness

Fig. 19. Peer A and B power profile for protocol selectionwithout adaptation.

ProtocolDomain 1

Gateway

ProtocolDomain 2

DellLaptopP4 3.2GHz512M RAM

10/100Mbps NICWindows XP


64M RAM802.11g WL AN Adapter

240X320 TFTWindows CE 4.20


64M RAM802.11g WL AN Adap

240X320 TFTWindows CE 4.20

Peer A

PeerB

ter

Fig. 18. The configuration of experimental platform for casestudy.


Autho

r's

pers

onal

co

pychallenged network [15] for many factors, e.g., weaksignal, keeping moving, etc. Hence, a short messagedelay is acceptable for instant messaging applica-tions on mobile devices. At the end of the session,peer A still has about 30% battery capacity, whilepeer B has about 500 s gap to the specified sessionlifetime. This means the adaptation policy is overactive to peer A but a little more passive to peerB. By tuning the adaptation policy algorithm webelieve a more accurate power profile can beachieved.

It is worth noting that we are aware of that multi-media streaming applications are one of the domi-nating applications of future Internet, but we donot adopt a multimedia streaming application inour case study because of the following two reasons.First, we observed that possible adaptation proto-cols for streaming applications include no morethan two levels: user experience adaptation, such asbrightness, window size, frame rate, and so on,and transmission adaptation, such as, content adap-tation, frame compression algorithm and communi-cation optimization protocols. We argue that theadaption of both brightness and the communicationoverhead has been shown to be effective for differentQoS metrics in two case studies. Thus, we believe

that our system will have the similar performancefor streaming applications as that of two case stud-ies. Second, the main contribution of this paper isabout the QoS space design and the adaptationframework, not the specific adaptation protocolfor one specific application. The above two casestudies are comprehensive enough to show the ben-efits. Applying the proposed framework to stream-ing applications is an interesting direction anddeserve future investigation.

5.5. Gateway capacity performance

Now we are in a position to study the general sys-tem capacity of the gateway. Performance of thegateway is greatly determined by the negotiationdelay. We setup the gateway on the PlanetLab [20]and use the configuration of case study to examinethe negotiation time as shown in Fig. 22. It coversthe average negotiation time of up to 300 peers shar-ing one gateway. The x-axis is the number of peers.The y-axis represents the average negotiation time.Although some fluctuations occur, most of thenegotiation times are between 20 ms and 27 ms.We also show the mean and median line of the mea-surement data in the figure. Given the fact that thegateway is on a real overlay network built on top ofInternet, it is quite normal to see this magnitude offluctuation. The overall negotiation time remains ina relatively stable range for two reasons. First is thesimplicity of energy-aware related protocol selectionalgorithm. Second is that each peer only needs onetime negotiation in the protocol selection stage.

5.6. Implications and discussions

Based on the evaluation results of two case stud-ies, we derive several implications for buildingfuture mobile applications. First, for the screenbrightness of the Pocket PC, so far we only use


Perc

enta

ge B

atte

ry R

emai

ning

2481632

64

128

1

64

3216842 2 4 816

32

64

3216

20

30

40

0 4 5 6 71 2 3

Message Combination Length Sequence

Screen BrightnessSequence

0% 0%25%

Fig. 21. Peer B power profile with adaptation.

20 -

25 -

30 -

35 -

10 70 130 190 300250

95% number of clients for the MeanMean Connect Line

- - - - Median Connect Line

Number of clients

Neg

otia

tion

time

(1 A

P) in

ms

Fig. 22. The average negotiation time.


Perc

enta

ge B

atte

ry R

emai

ning

50% 50%75%

100%

25% 25%0%

32

1616

8 844 22 1Screen Brightness

SequenceMessage Combination

Length Sequence

20

30

40

0 4 5 6 71 2 3

Fig. 20. Peer A power profile with adaptation.


Autho

r's

pers

onal

co

py

the setting menu to manually choose different brightlevels. An application programming interface wouldbe very beneficial to the energy-concerned mobileapplications because the screen brightness cangreatly affect the draining time of the battery. Sec-ond, HTTP protocol is widely used in Web applica-tions. HTTP/1.1 in RFC 2616 [21] has a key featureas persistent connections, similar as the CPLC pro-tocol used in case study 1. However many Web serv-ers and clients do not really support persistencyconnection [22]. Our experiments show that persis-tent connection can save the battery energy signifi-cantly. Furthermore, the large chunk approachcan enhance the benefit of persistent connection.We argue that all future mobile applications shouldadopt the persistent connection and large chunkcommunication for energy saving purposes.

6. Related work

Our model shares its goals with several recentefforts that aim at power management and applica-tion adaptation. We categorize them into threegroups as power management, distributed adaptation

and protocol adaptation.

6.1. Power management

Energy is a scarce resource especially for mobiledevices powered by batteries. The speed of batterycapacity increasing is much slower than that ofenergy consumption due to faster processor, largermemory, and bigger screens, and so on. Lots ofresearch has emerged to address how to reduce theenergy consumption and how to do the power man-agement for laptops, PDAs and mobile devices. Interms of working levels, in hardware level, someresearchers design the energy-efficient hardware suchas [23,24]. CASTLE [25] uses a hybrid approach thatcombines a model of the microarchitecture with run-time analysis of processor performance counters toestimate CPU power consumption. In operating sys-tem level, EcoSystem [14] explores operating systembattery management. It manages energy as any otheroperating system resource to enforce fairnessbetween applications. usleep [26] implements anaggressive OS-based power management schemefor exploiting idle periods on an Itsy system. Fromthe whole system level, La Porta et al. [27] optimizethe sensor movement for energy efficiency. Turduc-ken [13], a hierarchical power management architec-ture for mobile system, combines diverse platforms,

like Pocket PC, wireless sensor node, into a singleintegrated laptop to reduce the power cost ofalways-on operation. Zhu and Cao [28] raise apower-conserving service model for streaming appli-cations over wireless networks. The Odyssey system[11] makes the trade-off between energy and applica-tion fidelity. Applications can dynamically modifytheir behavior to conserve energy. Different fromthem, our model manages the energy consumptionusing protocol selection and adaptation from theQoS point of view. Furthermore, it can provide mul-tiple QoS metrics, including not only energy, butalso delay and content quality to both sides of aapplication session.

Some researchers address the power managementthrough network interface. Jung and Vaidya pro-pose a power control MAC protocol for Ad Hoc net-works [29] that allows nodes to vary transmit powerlevel on a per-packet basis. In order to reduce thewireless interface energy consumption, the Wake-on-Wireless (WoW) [12] combines a PDA with awireless sensor. The device and its wireless networkcard are shut down when the device is not being usedto reduce the idle power. Zhong and Jha [30] proposea low-power low-cost cache device, to which the hostcomputer can outsource simple tasks, as an interfacesolution to overcome the bottleneck. In [31], an eco-nomic model is used as a dynamic, decentralizedenergy management system which is integrated intothe Nemesis OS for energy allocation. The Muse sys-tem [32] also employs an economic model to reducehosting center energy needs by managing serverresources. Ref. [33] proposes a dynamic game theo-retic approach for choosing power optimizationstrategies for various components. Those effortseither need the new hardware support or use com-plex algorithms than ours. By naturally using proto-col selection and adaptation our model can achievesimilar or better performance.

6.2. Distributed adaptation

Adaptation can be introduced either at the end-points or distributed on intermediate nodes. Odys-sey [34], Rover [35] and InfoPyramid [36] are exam-ples of systems that support end point adaptation.Conductor [37] and CANS [38] provide an applica-tion transparent adaptation framework that permitsthe introduction of arbitrary adaptors in the datapath between applications and end services. Theseapproaches need some changes to the existing infra-structure for their deployment. Fractal [17] solves


Autho

r's

pers

onal

co

py

the deployment problem by leveraging the existingCDNs technology to distributed protocol adaptors,which are implemented using mobile code. All theseprevious work complements to our work very well.We are the first to take the energy as a QoS metricfor application sessions.

6.3. Protocol adaptation

In terms of protocol adaptation, there are net-work level systems such as [9], in which communi-cating end hosts use untrusted mobile code toremotely upgrade each other with the transport pro-tocols that they use to communicate. Transformertunnels [39] and protocol boosters [40] are doingapplication-transparent adaptation by tuning thenetwork protocol according to the change of net-work situations. Such systems can deal with local-ized changes in network conditions but cannotreact to changing environments outside the networklayer. Our model works at the application layer, itcan maximally adapt application level protocolswhich have no way to be completed in the networklayer. Our work is also different from the Webbrowser plugins, e.g., Realplay, Flash, and so on.Plugin is an application component which com-pletes part of the functionality, incapable of doingprotocol adaptation. Our system is a general modelto provide the QoS by means of protocol adaptationwhich has transparency to the client and other char-acteristics, such as flexibility and extendibility,which plugins do not have.

7. Conclusions

In this paper, e-QoS is proposed to benefit theapplication session across multiple applicationdomains from choosing appropriate protocolsaccording to dynamic end devices and network envi-ronments. To the best of our knowledge, this is thefirst effort on energy-aware QoS on application ses-sions across multiple protocol domains by means ofprotocol selection and adaptation, especially for thecase that both ends are power limited devices. Ses-sion lifetime QoS systems for instant messagingbetween two Pocket PCs have been built in the con-text of this model. Experiment results show thatenergy-aware QoS has lightweight system overhead.The proposed adaptation scheme is very effective onenergy-aware QoS in terms of the session lifetime.Possible future directions include finding morepower saving protocols especially for interactive

application sessions, like instant messaging toreduce the delay time, also integrating this modelwith end to end service differentiation and accesscontrol in the networks.

References

[1] NSF Wireless Mobile Planning Group Workshop, Newarchitecture and disruptive technologies for the futureinternet, September 2005. [Online]. Available from:<http://www.geni.net/wmpg_draft_200508.pdf>.

[2] dsrc, Dedicated short range communications (DSRC) home.[Online]. Available from: <http://grouper.ieee.org/groups/scc32/dsrc/>.

[3] ITS, Intelligent transportation systems. [Online]. Availablefrom: <http://www.its.dot.gov/>.

[4] W3C Consortium, Simple object access protocol (SOAP) 1.1,2000. [Online]. Available from: <http://www.w3.org/TR/SOAP/>.

[5] IETF organization, Ldap (v3) revision, 2004. [Online].Available from: <http://www.ietf.org/ids.by.wg/ldapbis.html>.

[6] B. Baksi, R. Krishna, N. Vaidya, D. Pradhan, Improvingperformance of TCP over wireless networks, in: Proceedingsof the 17th ICDCS, May 1997.

[7] N.C. Hutchinson, L.L. Peterson, The x-Kernel: an architec-ture for implementing network protocols, IEEE Transac-tions on Software Engineering 17 (1) (1991) 64–76.

[8] B.D. Noble et al., Agile application-aware adaptation formobility, in: Proc. of the 16th ACM Symp. on OperatingSystems Principles (SOSP-16), October 1997.

[9] P. Patel, A. Whitaker, D. Wetherall, J. Lepreau, T. Stack,Upgrading transport protocols using untrusted mobile code,in: Proc. of the 19th ACM Symposium on Operating SystemsPrinciples, October 2003, pp. 1–14.

[10] P. Sudame, B. Badrinath, On providing support for protocoladaptation in mobile wireless networks, Mobile Networksand Applications (2001) 43–55.

[11] J. Flinn, M. Satyanarayanan, Managing battery lifetime withenergy-aware adaptation, in: ACM Transactions on Com-puter Systems, May 2004, p. 137–179.

[12] E. Shih, P. Bahl, M.J. Sinclair, Wake on wireless: an eventdriven energy saving strategy for battery operated devices,in: Proceedings of the Eighth ACM Conference on MobileComputing and Networking, September 2002.

[13] J. Sorber, N. Banerjee, M.D. Corner, S. Rollins, Turducken:hierarchical power management for mobile devices, in:Proceedings of the 3rd International Conference on MobileSystems, Applications, and Services, June 2005.

[14] H. Zeng, C.S. Ellis, A.R. Lebeck, A. Vahdat, Ecosystem:managing energy as a first class operating system resource,in: Proceedings of the 10th International Conference onArchitectural Support for Programming Languages andOperating Systems, 2002.

[15] K. Fall, A delay-tolerant network architecture for challengedinternets, in: Proceedings of ACM Sigcomm 03, August 2003.

[16] NSF workshop, Overcoming barriers to disruptive innova-tion in networking, January 2005. [Online]. Available from:<http://geni.net/barriers_200501.pdf>.

[17] H. Lufei, W. Shi, Fractal: A mobile code based frameworkfor dynamic application protocol adaptation in pervasive


Autho

r's

pers

onal

co

py

computing, in: Proceedings of the 19th IEEE InternationalParallel and Distributed Processing Symposium, April2005.

[18] R. Kravets, P. Krishnan, Application driven power man-agement for mobile communication, in: Proceedings of theFourth Annual ACM/IEEE International Conference onMobile Computing and Networking, October 1998.

[19] M. Stemm, R. Katz, Measuring and reducing energyconsumption of network interfaces in handheld devices, in:IEICE Transactions on Communications, August 1997, p.1125–1131.

[20] Planetlab. [Online]. Available from: <http://planet-lab.org/>.

[21] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.Leach, T. Bernes-Lee, RFC 2616: Hypertext transfer proto-col, HTTP/1.1, 1999. [Online]. Available from: <http://www.ietf.org/rfc/rfc2616.txt>.

[22] B. Krishnamurthy, M. Arlitt, PRO-COW:protocol compli-ance on the web – a longitudinal study, in: Proc. of the 3rdUSENIX Symposium on Internet Technologies and Systems(USITS’01), March 2001.

[23] A. Chandrakasan, R. Brodersen, Minimizing power con-sumption in digital CMOS circuits, in: Proceedings of theIEEE, April 1995, 83 (4), p. 498–523.

[24] R. Gonzalez, M. Horowitz, Energy dissipation in generalpurpose microprocessors, in: IEEE Journal of Solid StateCircuits, p. 1277–1284.

[25] R. Joseph, M. Martonosi, Run-time power estimation inhigh-performance microprocessors, in: Proceedings of the2001 Symposium on Low Power Electronics and Design,2001.

[26] L.S. Brakmo, D.A. Wallach, M.A. Viredaz, usleep: atechnique for reducing energy consumption in handhelddevices, in: Proc. Int. Conf. Mobile Systems, Applications,and Services, June 2004.

[27] G. Wang, M. Irwin, P. Berman, H. Fu, T.L. Porta,Optimizing sensor movement planning for energy efficiency,in: Proc. of International Symposium on Low PowerElectronics and Design (IPSLED), August 2005.

[28] H. Zhu, G. Cao, On supporting power-efficient streamingapplications in wireless environments, in: IEEE Transactionson Mobile Computing, August 2005, pp. 391–403.

[29] E. Jung, N. Vaidya, A power control MAC protocol for adhoc networks, in: Wireless Networks, 2005, pp. 55–66.

[30] L. Zhong, N.K. Jha, Energy efficiency of handheld computerinterfaces: limits, characterization and practice, in: Proceed-ings of the 3rd International Conference on Mobile Systems,Applications, and Services, June 2005.

[31] R. Neugebauer, D. Mcauley, Energy is just another resource:energy accounting and energy pricing in the nemesis OS, in:Proceedings of the 8thWorkshop on Hot Topics in Operat-ing Systems, 2001.

[32] J.S. Chase, D.C. Anderson, P.N. Thakar, A.M. Vahdat, R.P.Doyle, Managing energy and server resources in hostingclusters, in: Proceedings of the 18th Symposium on Operat-ing Systems Principles, 2001.

[33] S. Mohapatra, N. Venkatasubramanian, Middleware formobility: a game theoretic approach for power awaremiddleware, in: Proceedings of the 5th ACM/IFIP/USENIXinternational conference on Middleware, October 2004.

[34] B.D. Noble, Mobile Data Access, Ph.D. dissertation, Schoolof Computer Science, Carnegie Mellon University, May

1998. [Online]. Available: <http://mobility.eecs.umich.edu/papers/diss.pdf>.

[35] A.D. Joseph, J.A. Tauber, M.F. Kasshoek, Mobile comput-ing with the Rover toolkit, IEEE Transaction on Computers:Special Issue on Mobile Computing 46 (3) (1997).

[36] R. Mohan, J.R. Simth, C. Li, Adapting multimedia internetcontent for universal access, IEEE Transactions on Multi-media 1 (1) (1999) 104–114.

[37] M. Yarvis, A. Wang, A. Rudenko, P. Reiher, G.J. Popek,Conductor: distributed adaptation for complex networks, in:Proc. of the Seventh Workshop on Hot Topics in OperatingSystems, March 1999. [Online]. Available from: <http://lasr.cs.ucla.edu/reiher/papers/yarvis.ps>.

[38] X. Fu, W. Shi, A. Akkerman, V. Karamcheti, CANS:composable, adaptive network services infrastructure, in:Proc. of the 3rd USENIX Symposium on Internet Technol-ogies and Systems (USITS’01), March 2001, pp. 135–146.

[39] P. Sudame, B. Badrinath, Transformer tunnels: a frameworkfor providing route-specific adaptations, in: Proc. of theUSENIX Technical Conf., June 1998.

[40] A. Mallet, J. Chung, J. Smith, Operating system support forprotocol boosters, in: Proc. of HIPPARCH Workshop, June1997.

Weisong Shi is an Assistant Professor ofComputer Science at Wayne State Uni-versity. He received his B.S. from XidianUniversity in 1995, and Ph.D. degreefrom the Chinese Academy of Sciences in2000, both in Computer Engineering.His current research focuses on mobilecomputing, distributed systems and peer-to-peer systems, and wireless sensornetworks. He has published more than40 peer-reviewed journal and conference

papers in these areas. He is the author of the book ‘‘PerformanceOptimization of Software Distributed Shared Memory Systems’’(High Education Press, 2004). He has also served on technicalprogram committees of several international conferences,including the chair of poster track of WWW 2005. He is a reci-pient of Microsoft Fellowship in 1999, the President outstandingaward of the Chinese Academy of Sciences in 2000, one of 100outstanding Ph.D. dissertations (China) in 2002, ‘‘FacultyResearch Award’’ of Wayne State University in 2004 and 2005,the ‘‘Best Paper Award’’ of ICWE’04 and IPDPS’05. He is amember of ACM, USENIX, and IEEE.

Hanping Lufei is a Ph.D. student ofcomputer science at Wayne State Uni-versity. His current research focuses onQoS, systems security, access control,and trust management in mobile com-puting environment. He is also interestedin computing enhancement for handhelddevice and resource management in dis-tributed systems. He received his Bach-elor degree in 1998 and Masters degreein 2001 from Huazhong University of

Science and Technology (HUST) in China and the University ofToledo in USA, both in Electrical Engineering.


Documents

Energy-Aware QoS for Application Sessions across Multiple Protocol Domains in Mobile Computing