Power Management Techniques for Mobile Communication

Robin I{mvets P. I{rishnan

College of Computing Bell Labs, Lucent TechnologiesGeorgia Institute of Technology 101 Crawfords Corner Rd.

801 Atlantic Drive Holmdel, NJ 07733-3030Atlanta, GA 30309 pk~research bell-labs. com

robirtk@cc. gatech. edu

Abstract

In mobile computing, power is a hmited r=ouce. Likeother devices, communication devices need to be properly managed to conserve energy. In this paper, weprment the design and implementation of an innovativetrartspori level protocol capable of significantly reduc-ing the power usage of the communication device. Theprotocol achieves power savings by selectively choosingshort periods of time to suspend communications andshut down the communication device. It manages theimportant task of queuing data for future dehvery duringperiods of communication suspension, and decides whento restart communication. We *O address the tradeoffbetween reducing power consumption and reducing delayfor incoming data.

We present resdts from experiments using our imple-mentation of the protocol. Th=e experiments measurethe energy consumption for three simrdated communica-tion patterns and compare the effects of different suspen-sion strategies. Our r-tits show up to an 83~0 savingsin the energy consumed by the communication. This cantranslate to a 6-9% savings in the energy consumed byan entire high end laptop or a savings of up to 40% forcurrent hand-held PCs. The resdting delay introducedis sm~ (0.4-3.1 seconds depending on the power man-agement level).

1 Introduction

In today’s world of mobile commtications, one of themost precious commodities is power. The mobile hostcan ody operate as long as its battery maintains power.New machines are being made to use less power dewingfor smder batteries with smfler capacities. The trendin mobile computing is towards more communication-dependent activities, with mobile users switching fromtraditiortd wired Ethernet communication to wireless com------

Permissionto makedistal orhardcopiesof allorpartof thisworkforperjonalorclassroomuseis granted\t+thoutfeepro!idedtha~copiesarenotmadeordistributedforprofitor commercialadvamageandthatcopiesbearthisnoticeandthefull citationon tl~cfirstpage.To copyothen!ise.torepublish,topostonsen,e=or toredistributeto lists,requirespriorspecificpermissionand~ora fee.N40BICOM 98 Dallas Texas USACopyrightAChl 19981-58113-035-ti98/10...S00OO 157

munication (using wirel-s Ethernet cards, for example).When inserted, many wireless communication devicesconsume energy continuously. Although dependent onthe specific machine ad wireless device, this energy con-sumption can represent over 5070 of total system powerfor current hand-held computers and up to 10% for high-end laptops. These trends make it imperative that wedesign power-efficient communication subsystems.

Various techniques, both hardware and software, havebeen proposed to reduce a mobile host’s power consumption during operation. Most softwar-level techniqueshave concentrated on non-communication components ofthe mobile host, such as displays, disks and CPUS. Inparticdar, researched have looked at methods to turnoff the display after some period of inactivity (as oftenimplemented in BIOS or screen savers), to spin down thehard dsk of the mobile host [7, 9, 16], and to slow downor stop the CPU depending on work load [8, 17, 24]. Theprinciple underlying the tetilques for controfing thesecomponents is to estimate (or guess) when the device wi~not be used and suspend it for those interv~. Stemm et.d [23] have identified the problem of excess energy con-sumption by network interfaces in had held devices, andhave provided trac~driven simrdation restits for simplesoftwar~level timeout strategies. The new IEEE 802.11standard that is being adopted by some vendors adoptslower level solutions (at the MAC and PHY layer) tosupport id~time power management. Hardwarelevelsolutions for managing the communication device focuson moddating the power used by the mobile transmitterduring active communication [21, 22, 19].

Our r=earch presented in this paper focuses on softwarelevel techniques for managing the mobile host’s commu-nication device through suspension of the device duringide periods in the communication. We present a noveltransport level protocol for managing the suspend/resumecycle of the mobile host’s communication device in aneffort to reduce power consumption. The managementof communication devices creates a new and inter= t-ing ~~enge not present when managing other devices’power consumption. Similar to hard disks and CPUS,the communication devices continuously draw power U-Iess they can be suspended. A suspended hard disk orCPU can be restarted by any user requiring that device.However, when a communication device is suspended,the mobile host is effectively cut off from the rest of the

——.— -—. —.-.. . .—-—

network. A mobtie host with a suspended communica-tion device can ordy guess about when other hosts mayhave data destined for it. If the suspension of the mobilehost’s communication does not match prevaihng commu-nication patterns, the isolation can cause btiers to over-flow both in the mobile host and in other hosts tryingto communicate with it. Additiondly, other hosts maywaste precious resources trying to commticate with themobile host if they have no knowledge about whether ornot the mobde host’s communication is suspended.

Our god is to provide mechanisms for managing andreducing the power consumption of the commticationdevice. We present a simple model for mobile communi-cation that provides adaptable functiontity at the tr~port layer for suspending and resuming communication.By exposing this function~ty to the apphcation, we en-able apphcation-driven solutions to power management.Power savings are attained by suspending communica-tions and the communication device for short periodsof time. During these suspensions, data transmissionsare queued up in both the mobile host and any otherhost trying to communicate with the mobile host. Thekey to balancing power savings and data delay hes inidentifying when to suspend and restart communications.By abstracting power management to a higher level, wecan exploit application-specific information about howto balance power savings and data delay.

Intuitively, power conservation is achieved by accumu-lating the power savings from many sm~ ide periods.We, however, need to be careti to monitor any addi-tiond energy consumption caused w~e executing thesuspend/resume strategies. Addition~y, we need to con-sider the effect on other hosts who are trying to commu-nicate with the suspended mobde host. A base stationusing our protocol has enough knowledge about the stateof the mobde host to know when it is suspended andcan use this information to help employ schedfing tech-niques. We implemented our protocol and experimen-tdy determined its effect on power consumption andthe qufity of communication. Using three simdatedusers designed to capture typical moblIe, commticationpattern, we obtained 48-83% savings in the power con-sumed by the communication subsystem, while introduc-ing a smd additiond response delay (0.4-3.l secondsdepending on the power management level) that is ac-ceptable for many applications, Eke web browsing.

In Section 2, we present our basic mobile communicationmodel, and the important issues in power managementfor communication. In Section 3 we present our powermanagement protocol and discuss the effect of timingissues on the effectiveness of our protocol. Section 4 describes our experimental setup and the communicationpatterns used in ow experiments. We then present mea-surements horn the implementation of our protocol anddiscuss the resdt.s in the context of several red systems.In Section 5, we discuss adaptive control strategies.

problems. These problems include different loss char-act eristics and Merent bandwidth capabihties on thewired and the wireless Erie, synchronization of discon-nected operations, and issues involving packet forward-ing. These problems pose significant ch~enges for end-t~end communication protocok. Two types of modekhave been studied [2]. The fit model exploits the natu-ral hop existing in the communication route to a mobdehost. Standard communication protocok are used bywired hosts to a base station and specified protocokare used for the fi~ hop from the base station to themobile hosts [1]. The second model utitizes and tunesexisting end-t ~end protocok, providing help and hintsalong the way [3].

We target our approach at the transport layer, where weprovide a set of mechanisms that flow communication tobe suspended and resumed. We assume a modd wherethe mobde host is communicating with the rest of thenetwork through a base station. This base station maybe a proxy, or it may be the connection point for end-t~end communication with other hosts. Often, defingwith moblhty does not fit into the standard seven layermodel. By exposing power management techniques tothe apphcation, we provide a system-level solution aimedat end-t~end communication. For our experiments inthis paper, we concentrate on the communication be-tween the mobile host and the base station, and for clar-ity assume that fl commtication to and from the m~bfle host is directed through one spefic base station.This work can be extended to include changing base sta-tions through techniques sidar to those used in [1, 3].

Current wireless communication devices typicdy oper-ate in two modes: transmit mode and receive mode.The transmit mode is used during data transmission.The receive mode is the defatit mode for both receiv-ing data and hstening for incoming data. Much of thetime, the wireless communication device sits ide in re-ceive mode, and, wtie the power required for reception isless than the power required for transmission, this powerconsumption is not neghgible. The IEEE 802.11 stan-dard provides for some power management at the lower(MAC or PHY) layers. Comptiant cards can exchangeinformation about outstanding data to decide on whento wake up suspended cards. There are ongoing effortsto provide IEEE 802.11 comphant support for powermanagement by introducing new features into the nextgeneration wireless communication cards [11]. An appreach that reties solely on techniques provided by thedevice (e.g., the s02.11 standard) cannot take applica-tion specific information into consideration when deter-mining power management strategies. Researchers have&o considered hardware-level solutions to provide lowpower communication capabihties [21, 22, 19]. Such SGIutions reduce the power cost of operating in either oneof the modes, and are orthogonal to our approach whichaddrmses the amount of time the device spends in eachmode.

Logical areas to look for softwarelevel power conserva-2 Communication Model and Power Management tion in communication are tw~fold. Since data transmi~

sion is expensive, we can reduce the time spent in trans-

The introduction of wireless finks into communication mission. This can be achieved by data reduction tech-

systems based on wired finks has posed a number of niques and inte~gent data transfer protocols. The obvious technique of data compression reduces the amount

158

.—— .. -.. .— ------ —. --—-

———----- .-. —-—. —..——

of transmission time, but requires additiond CPU cy-cles for performing compression. The connection between compression and communication rates is studiedin [5]. Through simple experiments, we observed that,com~idenng the current power requirements of CPUS ver-sus wireless communication devic=, the benefit in termsof power savings from reduced communication time of-ten outweighs the increased energy consumption costsfor compression. Intetigent data transfer protocok canbe used to reduce the effect of noisy connections thatcause power-expensive retransmission of lost messages.Our continuing research addresses the assessment of theeffects of different techniques for data reduction, includ-ing reduced rehabihty requirements, and their effect onboth power reduction and communication qutity.

The second area, and the emphasis of this paper, is thecost of leaving the communication device sitting ide dur-ing periods of no communication activity. During suchide periods, the communication device &aws power fis-tening for incoming data. Our god in this work is toreduce the amount of time the device sits ide drawingpower by judiciowly suspending it. Suspending a wire1=s communication device is sifiar to slowing a CPUin that there are some smfl power costs associated withsuspension and resumption. As mentioned in Section 1,the diffidt part here is to ded with when to suspendand resume the communication device, how to ded withthe mobile host being unreachable at times, and howto address the issue of not losing en-route data. Ourprotocol and its implementation presented here addressthese problems. Since the protocol itse~ generates ad-ditiond communication during these ide periods, thereneeds to be a balance between when it is beneficial to usethe power management techniques, and when we shoddleave the device on continuously.

In contrast to the solutions proposed by the IEEE 802.11standard, we beheve that power management shodd becontro~ed by the mobile host, potentidy even the apph-cat ion. By providing power control at the transport layer(or above), we can provide power management interfacesto the application, flowing the apphcation to better con-trol the communication, enabhng adaptive power man-agement driven by the needs of the apphcation. Specif-ic~y, communications using the IEEE 802.11 standardwi~ always pay the overhead of delays imposed by usingpower management, while our techniques Wow the appli-cation to determine when such delays are too high, and soadapt power management Ievek. Stemm et. d [23] havedso investigated methods for reducing power consumption of network interfaces, specificity targeting their research at hand-held devices. Their research suggestsapplication-specific solutions to such problems. In con-trast, our research provides a general solution capable ofhosting various strategies, both static and adaptive. Ourmeasurements are with a red implementation of a powermanagement protocol in an experimental setup. We are,therefore, able to observe the effects of the queuing ofdata and the red effect of extra energy consumption bysuch a protocol. We measure the power consumption inthe context of the entire system, considering such costsas message processing and disk accesses, for various sim-tiated worMoads that we expect mobile users to perform.

3 Communication-Based Power Management

Currently, a typical mobile host leaves its wirelms Eth-ernet card in receive mode during the time it is not be-ing used, tiess the user exphcitly remov= the card.The technique described in this section provides mecha-nisms to extend battery hfetime by suspending the wire-less Ethernet card during ide periods in communication.At the heart of the technique ties a protocol where themobile host acts as a master and teh the base stationwhen data transmission can occur. When the mobilehost wakes up, it sends a query to the base station to seeif the base station has any data to send. This permitscommunication device suspension at the mobile host, andenables the implement ation of communication schedd-ing techniques at the base station. The suspend/resumecycle resdts in bursts of communication that may befo~owed by periods of inactivity. Mthough producingsuch bursty communication may incur addition~ delay,bursty communication patterns lend themselves we~ toefficient schedting techniques.

With the suspension of a communication device, a mobilehost wi~ experience an additiond delay in data transmi~sion since data on both the sending and receiving sidesmay be held up during suspension. The mobile host canmonitor its own outgoing communication pat terns to in-sure that, despite these suspension times, communicationcontinues smootMy without btier ovetiow. The basestation, on the other hand, has no means to restart com-munication if it notices that it is running out of btierspace. It is up to the mobile host to understand the basestation’s expected communication patterns so that thebtiers at the base station do not ovetiow. In order to ef-ficiently use our power management techniques, our com-munication layer must monitor the communication pat-terns of the mobde host and match the suspend/resumecycle to these patterns.

The protocol we describe in this section dews a mobilehost to suspend a wireless communication device. Pen-odic~y, or by request from the apphcation, the protocolwakes up and reinitiates communication with the basestation. In the rest of this section, we wi~ describe ourpower management protocol in detail and discuss the sig-nificance of some of the timing parameters. Appendix Adescribes in detail the commands used by the protocoland the possible states and state transitions for both themaster and slave.

3.1 Power Management Control Protocol

In this protocol, the mobile host is the master and thebase station acts fike a slave. The slave is ody allowedto send data to the master during specific phases of theprotocol. During non-transmit phases, the slave queuesup data and waits for commands from the master. Ideperiods for both the master and the slave can be detectedthrough the use of idle timers or indicated to the protocolfrom the apphcation. In the protocol state diagrams forthe master and the slave (Figure 1 and Figure 2), IN:

indicates an input event that can be either an incomingmessage or a timeout, Q: indicates the state of the queue,and OUT: indicates an outgoing response message.

159

———-. . - FV -- .-. ..= -.. ._—. -.

As shown in Figure 1, the slave is initifized to be inthe SLEEPINGmode. It can ody leave that mode upon aHAKE-Wmessage from the m=ter. If the slave has datato send, it wi~ enter the SENDAECVmode. The slave winstay in this mode until it has detected that it has no moredata to transmit, whereupon, it wiU send a DDNEmessageto the master, enter the RECEIVINGmode, and continuereceiving until it receives a SLEEPmessage. If during thistime the slave detects that there is new data to transmit,it wi~ send a NEUDATAmessage to the master and enterthe RECEIVINGYAITmode. The slave can ody start totransmit when it receives a HAKE~ message. If a SLEEPmessage is received first, the waiting data stays bufferedand is not transmitted until the next resume cycle.

Although the state diagram for the master (Figure 2) ismuch more complex, we can see that the states may bepartitioned into three sets. The tit set (SLEEPING)con-cerns the m=ter when it is sleeping. When the masteris in the SLEEPINGmode, it can be woken up by one oftwo triggers: a wakeup timer or new data to transmit.If the wakeup timer expires, the master sends a WAKE-Wmessage along with any new data to the slave. If thereis new data to transmit to the slave before the wakeuptimer expires, the master has the option to wakeup andtransmit this new data, or continue sleeping and queueup the data until the timeout expires.

The second set of states (SENDINGXAIT,WAITING,andHAIT~OR~K) concerns the master when it is waiting fora response from the slave about whether or not the slavehas data to send. In the SENDINGJAITmode, the masteris transmitting data and in the WAITINGmode it has nodata to transmit. When the master receives a responsefrom the slave in the form of a DATAor a NODATAmessage,the m=ter enters the appropriate state in the third set.AdditionMy, if while in the SENDINGXAITmode an idetimer expires indicating that, the master has no moredata to send, the master enters the WAITINGmode andcontinues waiting for a response from the slave. In theWAITYOR~K mode, the master has told the slave that itshodd sleep and is waiting for a SLEEP~Kmessage.

When the mxter is in one of the finrd set of states(SENDING,sEND/REcv,and RECEIVING),itis actively send-ing and/or receiving data. In the SENDINGmode, them=t er may receive a NEWDATAmessage from the slave.The master responds with a WAKE~ message and entersthe SENDINGflAITmode. When neither the master northe slave have ay more data to send, the master sendsa SLEEPmessage and enters the WAITXOR~K mode.

Wireless connections are very susceptible to interferencefrom both external devices and other wireless devices us-ing the same settings or t~ng to the same base station.By ~~ing this protocol, we provide the base station with~<em information about the communication patt ems ofthe mobile host. Wthough not required by the prot~CO1,the master can inform the slave of its sleep time,or the slave can suggest appropriate sleep times to them=ter. If the protocol is used such that ody prespeci-fied timeouts trigger restarting communication, the slavecan design a communication schedting algorithm basedaround the known sleep time of the master. Addition-dy, if the sleep times for the master are sufficiently long,the slave can save any data destined for the master to

160

disk. This win free the b~er space being used by thedata destined for the master so it can be used for otheractive communications.

3.2 Wining Considerations

Timing is a key issue for both the performance of themobile host as we~ as the amount of power that canbe saved. If the wireless Ethernet card is suspended toooften, the user wi~ see lags in data transfer performance.On the other hand, if it is not suspended long enough,the gain in battery fife time may be undetectable.

In order to determine when the card shotid be suspended,the protocol needs to determine the communication pat-terns for both sender and receiver. There are two waysby which ide periods in the communication can be de-tected. The first, and simplest, is when the apphcationcan actudy inform the protocol that it doesn’t have anydata to send. This requires a more complex apphcationthat has information about its communication patterns.The second method is to use a timer set with a timeoutperiod. If the timer expires and no communication hasoccurred since the last expiration, the protocol concludesthat there is an ide period in the communication. Theappropriate timeout period depends on the requirementsof the apphcation. Timeout periods that are too shortmay cause the protocol to go to sleep prematurely, r~salting in poor response time for apphcations dependenton communication. On the other hand, timeout periodsthat are too long may cause the protocol and the com-munication device to remain active for unnecessdy longperiods of time, wasting precious energy.

The other timing parameter js the sleep duration whichdefines how long the master shotid keep the communi-cation suspended. The appropriate sleep duration &odepends on the requirements of the apphcation. Longersleep periods win cause longer lags in any interactive appficatjons. Shorter sleep periods wi~ not extend batteryhfetime appreciatively. The application needs to deter-mine the appropriate tradeoff for battery fifetime versusdelay. In many instances, the expected time and datasize for the response to a request initiated by the mobilehost can be estimated. This includes, for example, app~cations me mail, web browsing, md fle transfer. Inthis context, hints provided by the apphcation codd bevery helpfti. In our experiments reported in Section 4,we examine the effects of fixed timeouts that require noapphcation support and can be implemented within thetransport layer. Adaptively varying the timeouts or wing learning techniques are discussed in Section 5.

A mobile host that is running mtitjple applications can-not base jts power strategy on the expected communica-tion patterns of a single application. In this situation,the power management protocol must take hints aboutsleep/wake up durations for ~ executing applications.By exposing power management to the apphcation, andhence to the user, our power management protocol canbe guided in the appropriate ~ocation of resources.

A find consideration is the time required to wakeup andshut down the specific wireless network card. Our pr~tocol is designed to be independent of the specific card

——— .— .— .-,- .,. ... . . . . . . —-,.

//’

IN WAKE.UP

4

(INSEEP IM IDLE nMEOUT

am

IN IDE nMEOUT

OW MA out MA

Fl~e 1. Slave (Base StatIon ] Protocol State Diagram

OK

\ O.-a1

:.<*:::-...-”,.

\

WAIT.... .... . .

FOROK R-w; .+~w:

INDONE .. . >0 MAOW SLEEP 1% DATA

0: MA0~ NA

161

being used. Since our techniques address issues regard-ing the end-t ~end transmission of data, we assume thatthis wakeup time is minimal in comparison to the totaltransfer time. Although this may not be true for all de-vices currently, the interface standards proposed ]n [10]suggest that future devices will provide relatively inex-pensive transitions between waking and sleeping states.

4 Experiments

The god of our experiments is to show that, by usingour power management techniques, we can save a sig-nificant amount of the power consumed by the wirelessEthernet card. The tradeoff is an increased transmissiondelay observed by the receiver. First we will present ourexperimental setup and the user communication patternsused in our experiments. We win then show the impactof the power management techniques in the context ofthese user communication patterns. Fln~y, we will dis-cuss our results in the context of several red systems.

4.1 Experimental Setup

In order to determine the impact of our power management techniques, we measure the power consumption ofa wireless Ethernet card under varying conditions. Inour experiments, we use a 915MHz Lucent WaveLANPCMCIA wireless Ethernet card that can transmit dataup to 150KBps. It provides three power modes: tran~mit, receive and suspend, and does not perform powermanagement at the MAC layer. The system is cofig-ured as shown in Figure 3, with a wireless Ethernet in aNEC Versa 6320 laptop (the mobile host) communicatingwith a Gateway Solo 22OO(the base station) using a sec-ond WaveLAN PCMCIA card, both machines runningLinux. We plugged the laptop into a universal powersupply (UPS) to filter out voltage fluctuations. Our mti-timeter samples the current 11-12 times a second. Fromthese samples and the output voltage of the UPS, we canmonitor the power being used by the computer.

Figure 3: Experimental Setup

To determine the power consumption of the entire com-puter, we monitor the current being drawn from thetransformer by the computer. This trace of current read-ings (11-12 readings a second), when integrated overtime, provides us with the tot d energy and average powerconsumed during that time period. From basetine infor-mation we coHected about the necessary energy to runan ide computer, we can compute the cost of communi-cation. This cost of communication includes the energy

162

consumed by the communication device and any energyconsumed by the CPLTand hard disk due to the commu-nication. Each experiment was performed over a periodof 30 minutes to provide sufficiently long samples. To en-sure stablfity in our reported numbers, we repeated ourexperiments several times for each scenario. The resdtspresented in this section were taken from specific sam-ple runs. Each individud run was chosen from a set. ofqualitatively similar runs of a particdar experiment

According to specifications from the manufacturer [18],the power requirements of the WaveLAN card are thoseshown in Table 1, Column 2. Column 3 in Table 1shows the power requirements measured during our ex-periments without any power management. The mea-surements for receive mode were taken while the com-puter was ide, which imphed no extra disk or CPU ac-tivity. As mentioned earfier, the power consumption fortransmission includes any incidentd CPU and hard diskpower consumed to effect communication. It is interest-ing to note that the transmitter is rarely at fti power forlong periods of time. We observe that our measurementsof the power required while the device is in either modeare very dose to the documented specification.

State Documented MeasuredWaveLAN - suspended Ow OwWaveLAN - receive 1.48W 1.52WWaveLAN - transmit 3.00W 3.1OW

Table 1: Power Requirements of the Lucent WaveLANPCMCIA Wireless Ethernet card.

We chose Linux as a research platform becaw~e of theavailable source code for both the PCMCIA driver andthe WaveLAN driver. In order to suspend the WaveLANcard in Linux, a system cfl to the kernel is used to senda suspend command to the WaveLAN driver. Suspensionstops the receive unit, turns off the card, and updates thestatus of the PCMCIA device, removing its entry fromany routing tables. This update generates an unwanteddisk access. We modified the WaveLAN driver to updatethe status, but to leave the routing tables untouched,and called this the “sleep mode”. Switching from activemode to sleep mode is now a matter of ody the systemcd to the kernel and does not access the disk. Similarly,to wake up the WaveLAN card, a system cd to the ker-nel is used to restart the receive unit on the WaveLANcard. The next generation of WaveLAN cards wi~ havea DOZE mode [11] that wi~ provide a quicker transitionfrom active to DOZE than the transition from active tosuspended in the current model. Our power managementprotocol was implemented in the context of an adaptivecommunication framework that provides dynamic protocol configuration support to the apphcation [14, 13].Through the use of the framework interface, the apphca-tion can set and change specific protocol parameters.

4.2 Communication Patterns

The communication patterns used in our e~erimentsare designed to simdate different types of users. The

.- , . ...,. - —. .

amounts of data transmitted and received and the idepatterns of the users are varied randomly over time. Thecommunication patterns are chosen to model three “typicdm users. Table 2 presents the minimum, maximumand average amount of data in a transmission for each ofth=e users. For the simtiated web users, a transmissionfrom the mobile host triggers mtitiple responses from thebase station to simdate the mtitiple ties needed for aweb page. The average number of responses is shown inthe count column of Table 2. Table 3 shows the timingpatte- for the same users. Each user is d=cribed bya transmission cycle. During this cycle, the mobde hosttransmits and receives the amounts of data= describedin Table 2. When considered with the ide times shownin Table 3, we can see the total amount of time per cyclethat the mobde host spends transmitting, receiving andsitting ide. Our god is to suspend the communicationdevice during as much of th-e ide times as possible.

The fit pattern (WEB) simtiates a user browsing theweb. The amount of data transmitted is relatively in-significant in comparison to the amount of data received.The sleep time represents the amount of time the userwodd spend reading a page before going on to the nextone. Ea& request transmitted by the mobile host tri-ggersa number of responses. The delay between theseresponses is varied from O to 15 seconds to simtiate r~sponses from a busy web server. The second pattern(JW) simdates a user working on a joint project overthe wireless LAN. This user occasion~y transmits andreceives large pieces of their work. There is no connectionbetween transmissions from the mobile and transmis-sions from the base station. The third pattern (EMAIL)simdates a user that mostly transmits and receives &md messages. This user is ide most of the time between transmissions, and the size of the transmissionsare relatively smfl.

energy consumption. During ide periods in the commu-nication, the overhead is due to the cost of waking up theWaveLAN card, transmitting a query to the base stationand putting the card to sleep immediately since thereis no data to receive. Our resdts show that, even withrelatively short sleep times, this overhead is stti signifi-cantly less than the energy consumed by the WaveLANcard had it been left in receive mode.

Our experiments produce a trace of the power measurements from the mdtimeter. Plotting these traces giv=us a good, intuitive underst ading of the effect of ~ow-ing the wireless Ethernet card to sleep for short periodsof time. In each graph in Figure 4, we compare twotrac~ of the power consumed by the ide communica-tion subsystem ~.e., when there is no actual transmi-sion or reception). In Figure 4a, the sleep duration is1 second, ad in Figure 4b, the sleep duration is 2 sec-onds. The first trace, the flat Ene at 1.5W marked bythe diamonds, shows “the power consumed by the com-munication when no power management is performed.The second trace, the tine at OW with occasional spikesmarked by the plus signs, shows the power consumptionwith our power m~agement protocol turned on.

We can see from the two traces that the power consum~tion is approximately 1.5W 1=s when the WaveLAN cardis suspended. For the fit trace, the power consumptionstays at 1.5W since the communication device is alwayspowered on. For the second trace, the power consurnption is near zero most of the time, but spikes up at re~arinterv~. Three spikes are caused by the protocol wak-ing up and sending a query to the base station to see ifthere is any data waiting to be sent. By comparing thetwo graphs, we can see that the overhead for transmit-ting the queries is going to increase as the sleep durationgets shorter. Fi~e 5(a) shows the percent savings ofusing our protocol during ide periods when compared

Typical mobile users tend to perform each of the above to no power management.activities to some degree. From that point of view, thepatterns prmented above categorize users according to

Figure 5(b) shows a trace during the transmission of a

their main activity. The god of the adaptive techniques message to the base station. As we can see, the power

discussed in Section 5 are to dynamic~y find appropri- consumption for both traces is the same during the trans-

ate timeouts for user performing such activities. mission. The difference ties in the fact that after thetransmission is complete, the trace using power manag-ment shows the effect of suspending the wireless Ethernet

4.3 Results on the power consumption.

In this section, we consider the resdts from our exper- 4.3.2 Power Savings for Communication Patternsiments in the context of the effects of our power man-agement protocol on the energy consumed by the com-munication. This energy consumption is affected by theuse of the CPU and the hard disk during communica-tion. The savings we see come predominantly from thereduced consumption by the wireless Ethernet card. InSection 4.4, we discuss our resdts in the context of threered systems. The effects of the power management ona red system ~ depend on the power requirements ofthe system itseE.

4.3.1 Protocol Power Consumption

In order to determine the longer term effects of powermanagement, we measure power consumption during com-munication generated in the patterns discussed in Sec-tion 4.2. In our experiments, we do not queue data atthe mmter; i.e., we always wake up the communicationdevice at the master if there is data to send. Figure 6shows the resdts from our experiments in terms of thepercent of the total energy consumed by the communi-cation that was saved by using our power managementprotocol. For WEB, we see a 4&57% savings in the en-ergy consumed by the communication. For JW, we see a54-78% savings in the energy consumed by the commu-

When running the experiments with our management nication. In tie case of EM-AIL, we comp~e the resdts

techniques turned on, we incur some overhead in terms of of no power management with those of power management with sleep durations of 1 and 5 minutes. (Due to

163I

I

.— -.-— .-

Data Tmnsmitted Data ReceivedAvg Avg

~n Max Avg Total Min Max Avg TotalPattern (KB) (KB) (KB) Count (KB) (KB) (KB) (KB) Count (KB)WEB 5 30 17.5 1 17.5 300 1200 750 10 7500JW 5 500 227.5 1 227.5 5 500 227.5 1 227.5EMAW 5 300 152.5 1 152.5 5 300 152.5 1 152.5

Table 2: Commtication Patterns for Tkee Simtiated Users

User Sleep Time Average Time AverageMln M= Avg Transmitting Receiving Sleeping Percent

Pattern sec see) sec sec sec sec SleepingWEB 10 300 155 0.116 50 104.9 67.7%JW 10 300 155 1.52 1.52 151.96 98%EMA~ 10 600 305 1.02 1.02 302.96 99%

Table 3 Timing Patterns for Thee Simdated Users

6, t 6, INO Power Managent — NO Power Managent —

5Sleep Duration = 1 Semnd — Sleep Duration = 2 Semnd —

2 - ~

z1 z 1

0226 234

&%Ation T%3~On se~~%s)226

=%cttion ~%%~n se~;%s)234

(a) (b)

Fi~e 4: Power Consumption Dting a Sample Ide Period

100

90

60

70

60

50

40

30

20 -

10

0-0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Sleep Duration On aemnda)

(a)

’260 262 264 266 266 270tiecution 7ime on semnda)

(b)

Fi~e 5: Power Savings During Ide Periods and a Sample ~anamission

164

.,L”r ., . . . . . . . . . . -A..— . ..’ —-

the different time scale, th-e measurements are not in-cluded in Figure 6.) These sleep durations resdt in asavings of 81~0 and 83% of the power consumed by thecommunication.

.~o 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Sleep Duration On semnds)

Figure 6: Savings for Communication Power ConsumPtion

4.3.3 Delay

Power savings never come for free. In the context of com-munication, this cost can be measured in delay. A sleepduration of any length wi~ impose, on average, a delay ofhti the duration. This cost must be taken into consid-eration when deciding how much power management touse. In the context of a user that solely uses communica-tion for email, a sleep duration of 1 minute is acceptable.In re~ty, many email programs check md on the orderof every 5 minutes, and hence, such a sleep duration ismore representative of the common emd user. In con-trast, a user who is working jointly across the network orwho is accessing web pages may not be wtig to acceptsuch delays. In these c=es, the sleep durations shotidreflect the tolerance of the users to delays in receivingdata.

In the context of these experiments, we measure thecommunication delay in terms of additiond transmissiontime per user data block at the base station. (We neverqueued data at the mobile machine.) We cdtiate thisdelay by determiningg the amount of time that the fitmessage in the data block was delayed. Once the firstmessage is sent, the rest wi~ fo~ow, and the delay tothose messages win depend purely on how quicMy thedata can be transmitted. It is easy to show that themaximum additiond delay imposed by our protocol onany data can never exceed the delay for the fit packet,and hence, the numbers we pr-ent are a conservative es-timate. We measure this delay by determining the timethe transmission request was sent to the communicationsubsystem and the time when the data is fi~y sent.Since mdtiple transmission requests may queue up atthe base station during large bursts of traffic, delays maybe incurred even when no power management is used.Figure 7 shows the average added delay for a given sleepduration for the WEB pattern. When no power management is used, the average added delay is approximateely1 second. This increases, as we wotid expect, with in-creased sleep duration.

165

3.5

3

2.5 -

2

1.5

1

0.5

o~O 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Sleep Dumtion on -rends)

Figure 7 Added Delay b=ed on Sleep Duration

4.4 Impact on System Costs

Now we consider the power savings in the context ofthree red machines (see Table 4). The experiments thatwe have described were performed on the NEC Versa6320. We *O measured the ide power consumption forthe Toshiba Libretto 60 with and without the WaveLANcard and the ide power consumption for the HP PalmtopPC 320LX. We then used the restits from Section 4.3,running the experiments on the NEC, to estimate theeffect of the commtication patterns on the other twomachines. The Toshiba Libretto 60 is a smd laptopthat can run either Windows 95 or Linux. We woddexpect similar power costs for the hard disk and CPUforthis machine - we did for the NEC. The HP PahntopPC 320LX, on the other hand, runs Windows CE andhas no intern~ hard disk. This win probably change theeffect of power management on this type of machine. Itmay be argued that a wireless card with the power profleof WaveLAN is dkely to be used with an HP PahntopWe machine. We simply use this as an example of thetrend towards h~hter, more power efficient machines thathave smd batt~ry capacity:

Power RequirementsIde w/o I Ide w/

Table 4: Measured Power Requirements for Three Ma-chines

The fit machine, the NEC Versa 6320, is a high endmachine that consum- 14W while sitting ide. In thiscontext, the 1.5W consumed by the WaveLAN card odyrepresents approximately 10~0 of the power consumedby the computer when it is ide. In comparison, a ma-chine Eke the Toshiba Libretto consumes ody 7W whenide. The 1.5W of the WaveLAN card now representsapproximately 18% of the power consumed by the com-puter when it is ide. If we take this one step tither,we can see that for a machine fike the HP Palmtop PC,this percentage increases to over 50%. To compemate

for this problem, some manufactmere have introducedwirdess Ethernet cards that have an internal battery, d-althoughthey sti~ draw some amount of power from themain battery. In this case, the power consumed from themain battery by the ide device repr=ents approximately10% of the entire system power of the HP. Mthough thisreduces the effect on the hfetime of the main battery,we sti~ need to consider the effects on the battery forthe card itse~. Our techniques win work to extend theMetimes of both batteries.

Considered in the context of the NEC, the resdts dis-cussed in Section 4.3 show a 6.2-8.9~o savings for theJW pattern and a 8.G9.5% savings for the WEB pattern.If we now project these restits onto the other two ma-chines, we see even better savings of the power consumedby the entire system. Figure 8 compares the resdts forthe percent saved of the total system power for thesethree machines over varied sleep durations. The crossingof the plots for the WEB and JW patterns for the HP isdue to the fact that the power consumption of the com-munication device is more than the power consumptionof the HP. Therefore, the better communication powersavings for the JW pattern dominates the resdts. Thisis simply an artifact of the fact that the two pat temswi~ eventufly cross for fl c~es, as can be seen by theplots for the Toshiba. Most importantly, we can see thatthe trend toward machines We the Toshiba and the HPmake it imperative that we properly manage communica-tion devices, since the power consumed by these devicesrepresents more and more of the total system power.

40

35

30

25

20

15

10

5

.-.....-...+.....s-_._--.-=..---.”.--.’.----Jw.Kc —--- -JW;-Tosmba._e-.;,

,P..~- ~- -_. -_ . . .. —------ ~w; Hp ... ....

~&.- WEB. NEC — .WEB TosMba —

WEB HP ----:i/

or I0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Sleep Duration fin semnds)

Fi~e 8 Savings for Three Types of Machines

5 Adaptive Motile Power Management

We have shown that power management for communi-cation devices can extend battery Me. We *O see thatthere is not one scheme that win fit d users or W appticatione. This leads us to investigate mechanisms foradapting power management Ievek during communica-tion. The god of this paper is not to address the issue ofprediction, but provide the mechanism by which predic-tive algorithms can be used to adjust power managementparameters; in partitiar, the timeout and sleep durationparametem in our implementation.

The ided power management technique wotid sleep when-ever there is no data to receive born the base station andwake up for any incoming receptions as we~ ES te~ the

166

base station exactly when to expect transmissions fromthe mobile host. The god of adaptive power manage-ment techniques is to be able to estimate when thereis data to transmit from either side. Poor predictioncan cause unsuccessfd power management and waste re-sources such as btier space and bandwidth.

With our protocol, the sleep duration can be adaptedto fit the communication patterns of the apphcation. Asthe sleep durations increase, we can see that the curve forthe amount of energy saved @ level off. This happensas the savings reach the theoretical maximum savingsfor the partidar communication pattern. The theoret-ical hmit is reached when the communication device isordy active when there is actual data transfers occur-ring. For sm~er sleep durations that are much sm~erthan the expected time between transmissions, the com-munication device is sti~ active during some of the ideperiod. As the sleep duration increases, the probabilitythat there is data waiting at the base station increases.As an example, consider Figure 9 which shows the per-cent of the total time spent sleeping for both the JWand the WEB patt ems. As the sleep duration increases,the percent of the total time spent sleeping approachesthe theoretical hmit (98% for JW and 67% for WEB; seeTable 3). From the fact that the sleep time for the WEBpattern comes closer than the JW pattern to the optimalsleep time, we can see that the power management tech-niques that we used were more successfti for the WEBpattern.

100JW —

95 WEB ----- I

65 -------- ---... ---.. —..- ... ... ... . . . . . ..... . ............

80 I ‘..<.” Io 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

Sleep Duration on seconds)

Figure 9: Percent of Total Time spent Sleeping

By providing an apphcation-level interface to our powermanagement protocol, app~catione can control the poE-cies used for determiningg sleep duratiom. In this way,apphcation-specific information can be used to determineoptimal adaptation strategies.

In the context of our experiments, we implemented asimple adaptive algorithm similar to [6] for the web user.The ~gorithm responds to communication activity byreducing the sleep duration to 250 mi~seconds and reacts to ide periods by doub~g the sleep dwation up to5 minutes. We can use this simple algorithm because thecommunication patterns of the web user are somewhatpredictable. A request from the mobde host expects md-tiple responses from the b=e station. As the mobile hostnotices that no more responses are avdable, it can de-duce that either there are no more responses or that theserver is busy and the responses maybe delayed. For thiscommunication pattern, such m adaptive algorithm pr~

-- . ..—

tides a 58~0 savings in the power consumed by the com-munication device. This savings is an improvement overthe 5 sec static sleep duration. We for the 5 secondsleep duration, we saw a 3.12 second additiond delay, forthe adaptive algorithm, we ody saw a 2.77 second delay.This suggests that adaptive and predictive techniqueshave merit in mobde communication power managementfor communication applications. It *O demonstratesthat applying power management at the transport orapplication layer has benefits. These techniques can beused in conjunction with adaptive techniques used at theMAC layer [4, 19].

An important aspect to keep in mind is that efficient pr~diction or estimation is not always simple or usefi. Tak-ing the communication patterns of mtitiple applicationswotid &o make adaptation more ch~enging. Learning-theory based =timation techniques [15, 12] can providebetter adaptive algorithms for deciding when to poweroff and when to turn back on the communication device. Many such tetiques inherently try to estimatethe distribution generating the communication packets,and hence app~cation provided hints help such estima-tion techniques.

6 Conclusions

In this paper, we have studied the important issue ofpower management in mobile wireless commtication.We have presented a novel transport-level protocol bywhich a mobfle host can judiciously suspend and restartits communication device, and by informing the basest a-tion appropriately, not lose en-route data. We have pr~sented experimental resdts from an implementation ofttis protocol, and shown power savings of up to 83% forcommunication. This translates to a savings of &9Yo interms of total system power for high end laptops, and canrepresent up to 40% savings for current hand-held PCs.When we consider the subset of our restits for emd andweb browsing applications in the context of hand-heldPDAs, our implementation resdts agree in large mea-sure with the simtiation resdts in [23]. It is importantto note that if other components of the mobile machineare managed bet ter, the relative improvement numbersdue to efficient power management of the communicationdevice wiu be more prominent. For most apphcations theresdting sm~ additiond delay (e.g., 0.4-3.1 seconds forsome web browsing responses) shodd be acceptable.

Open problems include the development of inte~genttechniques (e.g., learning-based methods) to -timate whenthere is queued data at the base station, so that reception delays can be reduced. Such techniques might *Oadapt the timeout choice for users with varied communi-cation patterns. It wi~ be interesting to explore the cor-rect APIs to provide to applications so that they can givehints to the protocol about their communication patternfin the spirit of transparent informed prefetching [20]).

Acknowledgements

Research by Robin Kravets was sponsored in part by anAT&T/Lucent Technologies Ph.D. Fe~owship. The au-

thors wotid hke to thank Rob Kooper and Don Msonfor their assistance in the setup, configuration and btid-ing of our power measurement equipment.

References

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

A. Bakre and B.R. Badrinath. I-TCP: Indirect TCPfor mobile hosts. In IEEE International Confer-ence on Distributed Computing Systems (ICDCS)’95, 1995.

H. Bdakrishnm, V. Padmanabhan, S. Seshan, andR. Katz. A comparison of mechanisms for improvingTCP performance over wireless tinks. In Proceedingsof the SIGCOMM ’96 Symposium, 1996.

H. Bdakrishnan, S. Seshan, E. Amir, and R. Katz.Improving TCP/IP performance over wireless net-works. In First ACM International Conference onMobile Computing and Networking (MOBICOM),November 1995.

I. CMamtac, C. Petrioti, and J. Redi. Energy conser-vation in access protocok for mobile computing andcommunication. Microprocessors and MicrosystemsJournal, 1998.

F. Dougtis. On the role of compression in distributedsystems. ACM Operating Sy9tems Review, 27(2):8*93, April 1993.

F. Doughs, P. Krishnan, and B. Bershad. Adaptive disk spindown potici= for mobde computers. InProceedings of the Second USENIX Symposium onMobile and Location Independent Computing, April1995.

F. Doughs, P. Krishnan, and B. Marsh. Thwartingthe power hungry &sk. In Proceedings of the 1991Winter USENIX Conference, January 1994.

K. Govil, E. Chan, and H. Wasserman. Comparingalgorithms for dynamic speed-setting of a low-powercpu. In First ACM International Conference onMobile Computing and Networking (MOBICOM),1995.

D. Helmbold, D. D. E. Long, and B. Sherrod. A dy-namic disk spin-down technique for mobile comput-ing. In Second ACM International Conference onMobile Computing and Networking (MOBICOM),1996.

Intel Corporation, Microsoft Corporation andToshiba Corporation. Advanced Configuration andPower Interface Specification, revision l.Oa edition,Jtiy 1998.

A. Kamerman and L. Monteban. WaveLAN-II: Ahigh performance wireless LAN for the ticensedband. Bell Labs Technical Journal, Summer 1997.

S. Keshav, C. Lund, S. J. PhiMps, N. Reingold, andH. Saran. An empirical evaluation of virtual circuitholding time poticies in ipover-atm networks. InProceedings of IEEE INFOCOM 95, 1995.

167

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

R. Kravets, K. Cdvert, P. Knshnan, and K. Schwan.Adaptive variation of rehabihty. In the SeventhIFIP Conference on High Performance Networking(HPN’97), April 1997.

R. Kravets, K. Cdvert, and K. Schwan. Payoff adaptation of communication for distributed interactiveapplications. Journal on High Speed Networking:Special Issue on Multimedia Communications, 1998.

P. Krishnan, P. Long, and J. S. Vitter. Adaptivedisk spindown via optimal rent-t~buy in proba-bfistic environments. In Proceedings of the Twe~thInternational Machine Learning Conference, Jtiy1995.

K. Li, R. Kumpf, P. Horton, and T. Anderson. Aquantitative analysis of disk drive power management in portable computers. In Proceedings of the1994 Winter USENIX, 1994.

J. R. Lorch and A. J. Smith. Reducing proces-sor power consumption by improving processor timemanagement in a singl~user operating system. InSecond ACM International Conference on MobileComputing and Networking (MOBICOM), 1996.

Lucent Technologies. WaveLAN/PCMCIA CardUser’s Guide, October 1996.

B. Narendran, J. Sienicki, S. Yajnik, andP. Agrawd. Evaluation of and adaptive power anderror control algorithm for wireless systems. InIEEE International Conference on Communications(ICC’97), 1997.

R. H. Patterson, G. A. Gibson, and M. Satya-narayanan. A status report on research in transpar-ent informed prefetching. ACM Operating SystemsReview, (27):21-34, April 1993.

J.M. Ruhd& and N. Bambos. Mobile power man-agement for m~mum battery hfe in wireless com-munication networks. In Proceedings of IEEE IN-FOCOM 96, 1996.

A. Sampath, P.S. Kumar, and J. Holtzman. Powercontrol and resource management for a mdtimediacdma wireless system. In-The Sizth InternationalSymposium on Personal, Indoor and Mobile RadioCommunications (PIMRC’95), 1995.

[23] M. Stemm and R. Katz. Reducing power consumption of network interfaces in hand-held devices. InThird International Workshop on Mobile Multime-dia Communications (MoMuc-3), December 1996.

[24] M. Weiser, B. Welch, A. Demers, and S. Shenker.Sched&ng for reduced cpu energy. In Proceedingsof the First Symposium on Operating System Designand Implementation (OSDI) ’94, November 1994.

A Power Control Protocol

Protocol Commands: During the course of commu-nication both the master and the slave use commandsto inform the receiving side of state changes. Protocolcomman& are as fo~ows:

168

PHC-CMD-UAKEXP:Used by the master to inform the slavethat it can wake up and transmit data if it h= any m-sages queued up.PMC-CMDHODATA:Used by the slave to inform the mxterthat upon wake up, the slave had no data to send.PMC-CMDDATA:Used for any messages that simply con-tains data.PMC-CHDHEWDATA:Used by the slave to indicate to themaster that it now has data to transmit.PMC-CMDDONE:Used by the slave to indicate the end ofdata transmission.PMC-CMDSLEEP:Used by the master to inform the slavethat it shodd go to sleep.PMC-CMDSLEEP~K:Used by the slave to indicate that itcompleted the sleep command.

Master Protocol: The mobile host has the responsi-bi~ty of determining when communication takes place.At any point in time, the master can be in one of thefo~owing states:

PMCSTATESLEEPING:The protocol is sleeping and nodata can be transmitted or new data requests wti betiowed and a PMC-CHD-WAKE~is sent. Addition~y, nodata shodd be received when the protocol is sleeping.PHC3TATESENDING:Ody the master is sending data.Subsequent data requests are queued for transmission.PHCSTATESENDINGHAIT:Ordy the master is sending data.The slave has been queried for new data to send. Subs~quent data requests are queued for transmission.PMCSTATERECEIVING:Ody the slave is sending data.New data requests wi~ be queued for transmission andthe master wi~ enter the PMCATATESENDRECVstate.PMC~TATESENDAECV:Both the m=ter and the slave aresending data. Subsequent data requests are queued fortransmission.PMCSTATEXAITING:The m=ter woke up and has noth-ing to send. It has sent a query to the slave to see if ithas any new data to send.PMCSTATEJAITIOR~K: The master has determined thatcommunication shotid be suspended and is waiting for aresponse from the slave.

Slave Protocol: The base station fo~ows the com-mands of the master. At any point in time, the slavecan be in one of the fo~owing states:

PMCSTATEfiLEEPING:The protocol is sleeping and nodata can be transmitted. Upon receiving a message, theslave wakes up and enters either the PMCSTATERECEIVINGstate or the PMCSTATESEND~CV state, determined bywhether or not the slave has data to send.PMCSTATE&ECEIVING:Ody the master is sending data.New transmissions wi~ not be dewed. If new transmi~sions are requested, the slave sends a PMC-CMDXEWDATAmessage and enters the PMC~TATERECEIVING4AITstate.PMC~TATERECEIVINGIAIT: Ody the master is sendingdata. New transmissions wi~ not be flowed. Uponreceipt of a PMC-CHD-WAKE-Wmessage, the slave startstransmitting and enters the PHC~TATESENDRECVstate.PMC~TATE~ENDRECV:Both the master and the slave aresending data, Subsequent data requests are queued fortransmission.

—7. .-. .7— — —..-. ,., ..—