2010 - Energy-Efficient VoIP Over Wireless LANs (1)

8/4/2019 2010 - Energy-Efficient VoIP Over Wireless LANs (1)

1/16

Energy-Efficient VoIP over Wireless LANsVinod Namboodiri, Member, IEEE, and Lixin Gao, Senior Member, IEEE

AbstractEmerging dual-mode phones incorporate a Wireless LAN (WLAN) interface along with the traditional cellular interface. The

additional benefits of the WLAN interface are, however, likely to be outweighed by its greater rate of energy consumption. This isespecially of concern when real-time applications, that result in continuous traffic, are involved. WLAN radios typically conserve energy

by staying in sleep mode. With real-time applications like Voice over Internet Protocol (VoIP), this can be challenging since packets

delayed above a threshold are lost. Moreover, the continuous nature of traffic makes it difficult for the radio to stay in the lower power

sleep mode enough to reduce energy consumption significantly. In this work, we propose the GreenCall algorithm to derive sleep/

wake-up schedules for the WLAN radio to save energy during VoIP calls while ensuring that application quality is preserved within

acceptable levels of users. We evaluate GreenCall on commodity hardware and study its performance over diverse network paths and

describe our experiences in the process. We further extensively investigate the effect of different application parameters on possible

energy savings through trace-based simulations. We show that, in spite of the interactive, real-time nature of voice, energy

consumption during calls can be reduced by close to 80 percent in most instances.

Index TermsVoice over IP (VoIP), wireless LANs, energy consumption, portable communication devices, Internet.

1 INTRODUCTION

DUAL-MODE phones like the Apple iPhone and RIMBlackberry are an emerging trend with both a cellularand a Wireless LAN (WLAN) interface [1]. Apart from dataaccess, the WLAN interface can also be leveraged formaking Voice over Internet Protocol (VoIP) calls. This offerstwo advantages over traditional calling over the cellularinterface: 1) calls over the Internet through WLANs aremore cost effective and 2) these calls are not affected by lackof coverage of the cellular network in some indoor areas likethe office or home,1 or in certain outdoor areas.

The caveat, however, with using the WLAN interface is

that now energy consumption is of greater concern. Anactive or even idle wireless network interface (WNIC) is asignificant drain on the relatively limited capacity batteriesfound in smart phones. For example, the specifications ofApples iPhone [3] lists a talk time of 14 hours with thecellular interface, but no more than 6 hours of operatinglifetime with the WLAN interface for very light web browsing and e-mail access. The D-Link V-Click dual-mode-smart phone lists a talk time of 5 hours with thecellular interface, and only 2 hours of operating lifetimewith the WLAN interface [4]. Subjecting these devices toreal-time applications like VoIP would further significantlyreduce the talktime due to the much heavier workload.

Previous studies suggest that for high end devices like

laptops, at least 15-20 percent of the total energy capacity isconsumed by an active WLAN interface [5], while for low-end devices like a PDA, this number increases to about65 percent of the total energy consumption [6]. Reducing theenergy consumed by the WLAN interface for VoIP calls isthus a critical step toward extending the operating lifetimeof these mobile devices when utilized for such applications.

For applications with long periods of inactivity likeNetwork File Systems (NFS), or those with large tolerablelatencies of the order of seconds like web browsing, energycan be saved by letting the WLAN radio stay in the low

power sleep mode frequently and for long periods of time[7], [8]. Adopting this approach with real-time applications,however, is more challenging. VoIP has tolerable latenciesof the order of only hundreds of milliseconds, and anygreater delay induced by periodic transitions to the sleepmode would degrade the quality of the call beyond theusers tolerable limits. Packet generation intervals of theorder of tens of milliseconds exacerbate the situation bymaking it difficult for the radio to spend any significantamount of time in the sleep mode.

In this paper, we address the issue of reducing energyconsumption of the WLAN interface during a VoIP callwhile preserving the quality within acceptable levels. Our

approach is based on using an algorithm that can beimplemented as a software solution to saving energy. Thissolution would work with legacy interfaces whose radiosmay not be as power efficient as those of emerginginterfaces. Further, when improved hardware solutionsemerge that are more power efficient, our approach wouldcomplement such advances. Our contributions can besummarized as the following:

1. We propose the GreenCall algorithm that conservesenergy during VoIP calls over WLANs. Our algorithmsaves energy by computing sleep/wake-up sche-dules that allow the radio to stay in the low power

sleep mode for significant periods of time during a

566 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 9, NO. 4, APRIL 2010

. V. Namboodiri is with the Department of Electrical Engineering andComputer Science, Wichita State University, 1845 Fairmount, Wichita,KS 67260-0083. E-mail: [email protected].

. L. Gao is with the Department of Electrical and Computer Engineering,University of Massachusetts, 151 Holdsworth Way, Amherst, MA 01003.E-mail: [email protected].

Manuscript received 17 July 2008; revised 22 Mar. 2009; accepted 4 Aug.2009; published online 12 Aug. 2009.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TMC-2008-07-0277.

Digital Object Identifier no. 10.1109/TMC.2009.150.

1. Users typically spend greater than 30 percent of their time at theirhomes or offices [2].

1536-1233/10/$26.00 2010 IEEE Published by the IEEE CS, CASS, ComSoc, IES, & SPS

Authorized licensed use limited to: TAGORE ENGINEERING COLLEGE. Downloaded on July 21,2010 at 08:50:54 UTC from IEEE Xplore. Restrictions apply.


2/16

call. These schedules are computed keeping in mindthe maximum delay users can tolerate in theirconversations. This enables our algorithm to max-imize energy consumption while targeting a speci-fied level of application quality. Moreover, thealgorithm requires a software upgrade only on themobile device that desires to save energy. A

corresponding software upgrade at the peer deviceon the other end of a VoIP call is beneficial, but notrequired. No modifications are necessary at anypoint of the WLAN infrastructure or the Internet.

2. We present extensive evaluations of our algorithmthrough trace-driven simulations as well as experimentson commodity hardware/software. We evaluate ouralgorithm on commodity hardware and quantifythe energy saved between widespread geographicpoints of the Internet and describe our experiencesof the process. Through trace-based simulations, wefurther evaluate the effectiveness of our algorithmfor various configurable parameters of VoIP applica-

tions. We demonstrate that, with our algorithm,close to 80 percent energy savings can be achievedon most paths during a call. More importantly, froma fundamental perspective, our evaluations showthat significant reduction of the energy consumeddue to the WLAN interface can be achieved even forreal-time interactive applications like VoIP.

The organization of this paper is as follows: In Section 2,we provide some background on saving energy that iswasted in the idle mode of the WLAN interface and describerelated work. Section 3 considers the end-to-end perspectiveof a VoIP call in saving energy consumed due to the WLANinterface and formulates the problem we address in thispaper. In Sections 4 and 5, we develop the solution to ourproblem and describe how our algorithm computes energy-efficient sleep/wake-up schedules. Details of our GreenCallalgorithmand its pseudocode arethen presented in Section 6.In Section 7, we describe our experiences of evaluations ofGreenCall on commodity hardware/software. Section 8presents the evaluation results of trace-driven simulationsthat analyze the performance of GreenCall over diversenetwork paths in detail for various VoIP applicationconfigurations. Section 9 discusses some practical aspectsof the integration of GreenCall with existing VoIP clients andthe expected utility of GreenCall for a typical user. Conclud-ing remarks are made in Section 10.

2 BACKGROUND AND RELATED WORK

We begin this section by providing some background onhow energy wastage by time spent in the idle mode of theWLAN interface can be minimized. Subsequently, we willlook at related work that saves energy in the idle modeclassified based on the type of traffic under consideration:Non-VoIP traffic or VoIP traffic.

2.1 Saving Energy Consumed by WLAN Interface

The key idea of saving energy of the wireless interface is toallow it to sleep as much as possible by reducing the timespent in idle mode. There is typically about one order of

magnitude difference between the power consumption in

the idle and sleep states [9]. This is a difficult problem sincethe radio may not know when exactly it has to wake up toreceive incoming packets and will lose them if it stays in thesleep state. Other researchers have thus proposed schemesthat use multiradio solutions. The data and control channelsare separated, with the control channel generally using alower power, always active radio to wake up the higher

powered Wireless LAN radio (e.g., [9], [10], [11]).A standardized solution to this issue is the Power Save

Mode (PSM) which was introduced in the IEEE 802.11standard for infrastructure WLANs [12]. PSM allows a nodeto transition to the lower power sleep state when it is notactively sending or receiving packets by notifying the AP.Subsequently, theAP buffers any packets it receives destinedfor this node. Periodically, a beacon is sent out from the APthat informs all associated nodes if they have any packetsbuffered through a traffic indication map (TIM). This beaconis sent every beacon interval (BI) and is a preconfigured valueat the AP. Each node on receiving notification of bufferedpacket(s) within a beacon, can leave sleep mode and request

buffered packets from the AP. Within these retrievedpackets, the AP sets a more data bit as long as there arepending packets. The client goes to sleep immediately after itfinds no more packets buffered to it. When the client does notwant to use PSM anymore, it notifies the AP and the latterdoes not buffer packets destined to the client anymore. Theclients network card consumes much less power whilesleeping by shutting off power to all components except for atiming circuit. Because PSM has been part of the standard formany years now, all current deployments support PSM.Using PSM obviates the need for any supplementary devicesto reduce the energy consumption of the WNIC. Asexplained next, there have been important additions to

PSM in recent years; thus, throughout this paper, we refer tothe scheme outlined above as legacy PSM.

An important change in PSM with the ratification ofthe IEEE 802.11e standard has been the introduction of theUnscheduled Power Saved Delivery (UPSD) mode. In theUPSD mode, an uplink packet from a node to its APtriggers the downlink of any buffered packets at AP to thenode. This mode takes advantage of the fact that a nodesradio wakes up from sleep to send its packets, and thuscan receive packets as well at those times without havingto wait for notification in the next beacon sent from theAP. Thus, the UPSD mode works in the same fashion aslegacy PSM explained above except for the triggeredpacket delivery from AP. This allows a node to receive

any buffered packets at the AP directly without having tofirst wait for notification in a beacon. Due to only minordifferences in the legacy PSM and UPSD schemes, anyreference to PSM in this paper implies the basic mechan-ism of going to sleep mode and waking up every BI tocheck for buffered packets at the AP which is common for both schemes. We will make the reference explicit whennecessary during our discussion of implementation oncommodity hardware in Section 7.

On a related note, power management is well supportedin other technologies like GSM through time divisionschemes, and IEEE 802.16e (WiMax) through similar powersaving modes. The support provided in legacy IEEE 802.11

wasnot fine-grained enough, butthis situation has improved

NAMBOODIRI AND GAO: ENERGY-EFFICIENT VOIP OVER WIRELESS LANS 567



3/16

with the more recent version of the standard with theintroduction of the UPSD mode and related modifications.

2.2 Related Work

We bifurcate related work based on the type of traffic underconsiderationthose that have dealt with saving energy inthe idle mode with non-VoIP traffic, and those that have

specifically worked with VoIP traffic. We also brieflydiscuss related work done to gather Wide-Area Network(WAN) latencies between different points. Network latencycharacterization is a critical aspect of our algorithm as it isdesigned to work over a large number of hops between thetwo ends of a VoIP session over the Internet.

We begin by providing an overview of work done withnon-VoIP traffic. Krashinsky and Balakrishnan [8] presentedthe Bounded Slowdown Protocol (BSD) which bounds thedelay to a user specified level, while maximizing energysavings. It is aimed at situations where there are longperiods of user inactivity as in Web-based traffic. A similarapproach of saving energy during periods of inactivity of acell phone was presented in [13], [9]. In their work, a lower

power radio is used to wake-up a higher power radio whencalls arrive, while the higher power radio stays in sleepmode between calls. Thus, the focus of saving energy is between calls and not during calls like our work. Anandet al. [7] have advocated enabling knowledge of theapplication at the OS level, i.e., to save energy by tuningthe parameters based on the intent and access patterns ofapplications. They specifically consider noninteractive ap-plications like NFS, audio streaming, and remote displaywhich are more delay-tolerant than VoIP. Some otherresearchers propose approaches that rely on additionalhardware to allow the client radio to save energy [14], [9],[10]. The work by [15] considers traffic based on audio/video streaming where the received throughput is impor-tant. Their client-side approach focuses on how the trafficcan be forced to be sent in bursts from the server to allowmaximum savings with PSM by adjusting the advertisedTCP receive window in ACK packets. Another approach tosend streaming multimedia packets in bursts from theserver is presented in [16], where packets are buffered at theserver and sent periodically. These approaches are suited fordelay-tolerant multimedia traffic, and will not be suitable forVoIP traffic which is generated at a fixed rate and has aninteractive nature. Further, with server-side bufferingapproaches, packets are already delayed when they arriveat the client, giving it very little leverage over amount ofenergy savings. The work by [17] is a scheme designed toallow the radio interface to transition to lower power sleepmodes for idle periods much smaller than those supportedby the legacy PSM standard (Section 2.1), and is designed towork with any data traffic. This work relies on somemodifications to the IEEE 802.11 standard and runs oncustom-built hardware, and does not incorporate the recentchanges to the standard like the UPSD mode. Our work onthe other hand is targeted specifically to VoIP and itscharacteristics, works with commodity interfaces, includingthe most recent ones and compares and contrasts ourcontribution with the UPSD mode designed for real-timetraffic like VoIP.

Now, we describe more general work done previouslyfor saving energy due to WLAN interface specifically with

VoIP traffic. The work in [18] presents an implementation of

an energy saving algorithm for VoIP over wireless ad hocnetworks. They rely on turning the radio off and back onbetween VoIP packets to save energy. They observe that thetransition time to and from the off mode is too large for allpractical purposes and use simulations with small transi-tion times for their results. In our work, we rely on usingPSM of the IEEE 802.11 standard to switch the radio

between the low power sleep state and high power idle (on)state, without actually having to turn the radio off at anytime. Moreover, our focus is specifically on infrastructureWLANs, with the peer of a VoIP session possibly anynumber of hops away on the Internet. A measurement-based study on power consumption of a WiFi-based phonewas presented in [19]. The authors measure powerconsumption incurred for tasks like scanning, roaming,receiving beacons, and draw inferences for VoIP applica-tions. This work looks at energy from a microlevelperspective focusing only on the one hop network withthe AP; similar microlevel work on the topic has been doneby Gleeson et al. [20] and Tsao et al. [21]. Our work, on theother hand, looks at energy from a macrolevel perspective

focusing on end-to-end (multiple hops over the Internet)characteristics of a VoIP session. Microlevel studies wouldbe complementary to our work. The work by Chen et al. [22]presents the UPSD mode where a node can collect anypackets buffered at the AP when it wakes up and can goback to sleep without having to explicitly announce (frameexchange) to the AP its intentions to sleep. The UPSD modehas been incorporated in the WMM-PS [23] scheme that wasadded to legacy PSM in recent standards like 802.11e asexplained before. While this approach reduces the latencyto receive packets by waking up more frequently than whenusing GreenCall, the energy savings with this scheme is stillsignificantly smaller than that of our algorithm. Wecompare this approach with our proposed GreenCall

algorithm later in this paper.Latency characteristics between different locations on the

Internet play an important role on VoIP call quality. Therehave been many studies on capturing latency character-istics, with some directly focusing on the impact on VoIP,and thus proposing algorithms to enhance the VoIPexperience. A recent work by Markopoulou et al. [24]provides an in-depth measurement study of delays on theInternet backbones and how expected behavior can bemodeled. The work in [25] provides classical techniques forestimating network delay when used with VoIP applica-tions. The work in [26], [27] focus specifically on the impactof delay characteristics of the Internet on VoIP traffic.

Corresponding adjustments required during audio playoutare discussed in [28].

3 PROBLEM DEFINITION

Based on the background provided in the earlier section, westate the problem that needs to be solved in this section. We begin by studying the latency components of a VoIP callfrom an end-to-end perspective and then provide a moreformal problem statement.

3.1 Using PSM to Save Energy During a VoIP Call

The two ends of a VoIP call are peers of each other. To

simplify our description, we term the device on which




4/16

energy savings is sought and runs our energy savingalgorithm as the client. Our descriptions will be based on theperspective of the client. The device on the other end of theclient will be referred to as the peer. If both ends are runningan energy saving algorithm, they are symmetric for thepurposes of our descriptions and either of these can bereferred to as the client and other as the peer.

Looking at Fig. 1, if the client uses PSM to go to sleep,any packets arriving from the peer will be buffered at theAP. If the arriving packets were delay-tolerant, the clientcould sleep for long durations (order of seconds) beforecollecting packets from the AP. VoIP traffic, however, hassmall tolerable latencies and each packet must reach theclient by its playout deadline. Thus, the client sleepschedules must be precise enough to ensure no packetsare lost due to missed playout deadlines.

To calculate such a strict sleep/wake-up schedule, weneed to consider the latency (mouth-to-ear delay) of apacket from the peer to the client. It can be broken intodifferent components as illustrated in Fig. 1. The latency

from the peer to clients AP is mainly the network delay forthe packet once it is sent out from the application layer ofthe peer station. The peer incurs an encoding andpacketization delay before it hands the packet to thenetwork layer. Once a packet reaches the AP, it is bufferedthere until the client comes out of PSM and is ready toreceive the packet. Finally, once the packet reaches theclient, it is kept in a playout buffer to reduce jitter onplayback. The minimum latency induced by the playout buffer is only the time to decode and playout the packet.When the mouth-to-ear delay exceeds a specific tolerablevalue (thus, termed tolerable delay), the packet is dropped.

3.2 Problem Statement

We will now define the problem we consider in more detail.Fig. 2 illustrates the possible packet arrival patterns for twocases at the clientwhen it does not go to sleep at all, andwhen it periodically goes to sleep. For simplicity, thisillustration and associated description assumes that only theclient is trying to save energy (we look at the case when bothends try to save energy in Section 4.2). The packet receivetimes when client is not using PSM is not a straight line because the network latencies from peer to client arevariable. On the other hand, the line for playout deadlinesis straight because it is the sum of a constant tolerable latencyover packets generated at fixed intervals. The differencebetween the line representing receive times without PSM

and line for playout deadlines is the time that the client has

to play with to save energy. For the case when clientperiodically transitions to sleep, packets arrive at the clientin bursts. The first packet delivered to the client after a sleepperiod is likely to be closest to its playout deadline comparedto the other packets sent by the AP for the same sleep period.

The lines showing receive times at client on wake-up alsohave a slight slope (over a horizontal line) incorporating thelatency between the AP and client, and the transition timefor the client to notify the AP about its transitions to andfrom the sleep state.

The client needs to calculate2 a sleep/wake-up schedulethat allows it to sleep as much as possible, while ensuring itreceives all packets before their playout deadline. Largersleep periods are preferable to smaller sleep periods as theyminimize the total overhead incurred in transitioning to andfrom the sleep state by notifying the AP each time. In thecontext of Fig. 2, it implies that sleep periods chosen mustensure the line representing packet receive times at client

always stays below the line for playout deadlines. Anotherissue posed to the client during a VoIP call is that apart fromreceiving packets from the peer, it is also sending packets tothe peer at fixed intervals. Thus, assuming that it buffers anygenerated packets when it is in sleep state, it also needs toensure that its sleep/wake-up schedule is such that thesepackets reach the peer by their playout deadlines.

If the client knew the network latency for each packetthroughout the call (i.e., it had knowledge of the linerepresenting packet receive times without PSM) theproblem can be easily solved. Unfortunately, networklatencies3 of packets arriving in the future are unknown tothe client when it has to calculate its schedule. If the

estimate of network latency used by the client is larger thanthe underlying network latency, it is missing out onopportunities to save energy by sleeping more. On theother hand, packet loss is likely if the underlying networklatency increases above any estimate used by the client. Toachieve energy savings under the circumstances, we tradeoff the possibility of some packet loss due to transitions tosleep mode by introducing a parameter LR that specifiesthe tolerable loss rate of the application.


Fig. 1. Illustration of end-to-end latency components of a VoIP callbetween a peer on a wired/wireless network and the client on a wirelessnetwork.

Fig. 2. Timing of packet arrival at the client with and without using PSMwith respect to playout deadlines.

2. For now assume that the client has control of when and how long itcan sleep and is not restricted to the AP beacon interval schedule as inlegacy PSM. The client notifies the AP before sleeping and on wake-up. Wewill address the practical implications in Section 7.

3. By each packets network latency we mean the latency the packet will

suffer in traversing the network path from one end to the other.



5/16

Let f1 . . . ng be the set of sleep periods used bythe client during the call, with n being the number oftimes it transitions to sleep mode during the call. Theenergy consumed for this sleep/wake-up schedule can bemodeled as

E PtxTtx PrxTrx PidleTidle PsleepTsleep; 1

where Ps are the known power consumption values and Tsare the total time spent during the entire call in transmit,receive, idle, and sleep states, respectively. We have Tsleep Pn

i1 i and Tidle Tcall duration Ttx Trx Tsleep. The va-

lues ofTtx and Trx canbe treated as constantsbasedon knowntime to send or receive each packet and known number ofpackets communicated during the call. Thus, E is comple-tely characterized by the sleep schedule . The energysavings achieved for some sleep/wake-up schedule is thedifference between energy consumptionwhenthe clientdoesnot sleep at all, and energy consumption using .

For the whole call, we seek that maximizes energysavings while targeting a loss rate no greater than LR at both

ends of the session. The specified loss rate LR is the sum ofpacket losses due to missed playout deadlines induced byrunning an energy saving algorithm, Les, and underlyingnetwork losses (including delayed packets missing playoutdeadlines), Lnw; i.e., LR Lnw Les. Even though Lnwcannot be controlled by the energy saving algorithm, Lesshould be controlled in an attempt to maintain the total lossrate below LR at the end of the call. The degree of energysavings should degrade gracefully with increase in loss ratein contrast to an abrupt all or nothing policy. Larger sleepdurations are desirable, if possible, to minimize the over-heads involved (more specifically, the AP notifications) ineach transition to the sleep mode.

The challenge involved in the design of GreenCall can be

better understood by looking at some typical numbers ofthe parameters involved. Network latency between sitesvary from 0 to 1,000 ms based on geographic distance and/or characteristic of the path. Tolerable latency for VoIP iswidely used as 100-300 ms. Latency to communicatebetween the client and its AP varies from 0 to 20 ms basedon contention on the medium. These numbers vary due to anumber of factors which will be discussed at various placesthroughout the rest of the paper.

4 DERIVATION OF SLEEP/WAKE-UP SCHEDULES

In this section, we will describe ourapproach to derive sleep/wake-up schedules and present our GreenCall algorithm tosolve theproblemas defined in Section 3.2. Notificationsusedin the derivation are listed in Table 1. We will bifurcate ourpresentation of deriving sleep schedules into two cases: onewhere only the client is trying to save energy through PSMand the peer radio always stays in active mode, and anotherwhere both the client and peer desire to save energy. The firstcase happens in scenarios where the peer user does not careabout energy. For example, such a peer device could bepowered through a wall socket.

4.1 Derivation of Schedules When PSM Used Onlyby Client

Assume that our energy saving algorithm is running at the

client. To calculate sleep periods, the client needs to

perform the following three steps: 1) determine playoutdeadlines of each arriving packet, 2) estimate times at whichpackets would have been received at the client if it neverused PSM, and 3) calculate sleep period for future packets based on difference between the playout deadline andtheoretical receive time at client without PSM of previouslyreceived packets. We begin by describing the calculation of

playout deadlines.

4.1.1 Playout Deadlines

Let tis be the time at which a packet i is sent from the peer toclient. Since voice needs to be encoded and packetized before it is sent, the time at which the voice content ofpacket i was generated is tis Tpktz, where Tpktz is theconstant encoding and packetization delay. Let tia be thetime at which packet i arrives at the client and tip be the time by which it has to be played out (also called playoutdeadline). Let lpc be the estimated network latency frompeer to the client of the first generated packet, and let lac bethe estimate of network latency of first generated packetfrom clients AP to client. We will describe our estimationmethodology for these latencies later in this section whenwe present our algorithm. The playout deadline for a packeti can be calculated as the sum of tolerable latency from thetime the packets voice content was generated, or

tip tis Tpktz TL; 2

where TL is the constant tolerable latency of all packets.Based on the arrival time of first packet at client and thenetwork latency estimate, it can calculate tis for allsubsequent packets simply as

tis t1

a lpc m 1TI; 3

where TI is the constant packet generation interval betweensuccessive sequence numbered packets, and m is thesequence number4 of a packet.

4.1.2 Network Latency

Now that the client can calculate the playout deadline ofeach packet, it requires an estimate of packet networklatencies to calculate the receive times for each packet if itwere never using PSM. For this, we use the concept of sparetime of a packet which is the difference between its playouttime and arrival time at client. The spare time of anyreceived packet i can be directly calculated by the client based on the difference between its arrival time and itsplayout deadline as

tispare ti

p Tpb tia; 4

where Tpb is the time required to decode and play out apacket and each packet must reach the client in time toallow this operation.5

Once the client has begun transitions to sleep, however,network latencies of subsequent packets it observes includethe delays incurred at the APs buffer. Thus, tispare can be


4. i represents the order in which packets are received, while mrepresents the order in which packets are generated. Due to packet loss, theclient may not receive all generated packets and, thus, we need to make thisdistinction explicit.

5. For simplicity, we had ignored this constant time in our descriptions in

Section 3.2.



6/16

termed as the pseudospare time of packet i. The actual sparetimes (difference between playout deadline and packetreceive time without PSM) of packets previously received,on which it can base its future sleep period calculations, isunknown. Our approach to solve this relies on the knowl-edge of arrival times of packets at the client and its last used

sleep period. By adding the possible buffering delayincurred by a packet at AP to its observed spare time atclient, we hope to reconstruct the actual spare time thatwould have been observed for the packet if it were neverbuffered at the AP.

A critical observation required at this point is that thefirst packet buffered during a sleep period possibly incursthe maximum delay among all packets in the AP buffer.Because a packet is generated by the peer every TI ms, thefirst packet in buffer will likely come in no later than TI afterAP starts buffering for the client for that sleep period. Dueto notification delay between client and AP, the AP startsbuffering lac before client goes to sleep and stops bufferingonly lac after client wakes up. Thus, the arriving packet will

have a minimum buffering delay ofk 2lac TI, where k

is the last used sleep period, k 2 1; . . . ; n. If the first packetcomes earlier, our reconstructed spare time will be anunderestimate (i.e., a conservative estimate) by up to TI. Ifthe first packet comes in later, but within the same sleepperiod, it will be buffered for lesser time at the AP, but willstill be received at the client at the same time as it wouldhave done if it was not late. Thus, the buffering at AP during aclients sleep period is able to absorb some additional latency oflate-arriving packets.

We can then use the following equation to get anestimate of the actual spare time for the first packet receivedat client after a sleep period (also referred to as a significant

packet henceforth).

tkspare tfkspare max0;

k 2lac TI; 5

where fk is a mapping from the first packet received afterkth sleep period k to received packet number i. The aboveequation gives an upper bound on the actual spare time ofthe first packet in the AP buffer. Thus, to summarize, wecalculate the spare times of only selected significant packetsthrough a call and will use these for the calculation of sleepperiods. Knowing the playout deadline and spare times ofpackets, we can calculate the network latency (afteraccounting for encoding and packetization delay at thesender and decoding and playout delay at the receiver) of

each significant packet as

lk tfk

p tkspare Tpktz Tpb: 6

4.1.3 Sleep Periods

Finally, we will use the playout deadlines and spare timescalculated for the significant packets to derive sleep periodsat various decision points through the call. A decision point

can be defined as the time when the client has to calculatethe next sleep period to use after receiving packets from theAP buffered during previous sleep period. If the client knewthe network latency lk1 of the next arriving packet ik1, itcan calculate the next (k 1th) sleep period to use as

k1 tk1spare 2lac tfk1

p lk1 Tpktz Tpb 2lac: 7

However, network latency of arriving packets is un-knownthus, we need to predict a bound for the value lk1from above for the packet arriving after the decision pointusing the estimated network latencies of previouslyreceived packets calculated by (6). We will describe ourapproach to predict a bound on network latency in

Section 5. Another point of note is that the above calculatedsleep periods are based on packets received at the clientfrom peer. To ensure that these sleep periods also allowpackets sent by client to reach peer before their playoutdeadlines, periodic feedback is used between the two endsof the session. More details about the feedback mechanismare described in the next section.

4.2 Derivation of Schedules when PSM is Used byBoth Client and Peer

If the peer also desires to save energy and calculates sleepperiods to usewith PSM, both theclient andpeer must ensurethat their calculations take into account the fact that each

packetmightbe delayed at both ends. If thenetworklatenciessuffered by packets are symmetric in both directions, thesleep periods calculated at both ends should be the same.Under the circumstances, both ends using half the calculatedsleep period is a fair way to share the possible sleep times between both ends and ensure packet meet their playoutdeadlines. In other words, if one end calculates its sleepperiod as and knows the other end to be running an energysaving algorithm, it uses a sleep period of Cshare , whereCshare is a constant forwhich thevalue0.5 provides fairness inenergy savings at both ends. As the call progresses, the clientcalculates sleep periods as in Section 4.1 and uses a sleepperiod equal to half the calculated value. To account for

asymmetric network latencies between the two ends, the


TABLE 1Notation Used in Calculation of Sleep Periods



7/16

client relies on a combination of feedback to the peer andadjustments of its own sleep durations. Further implementa-tion details are explained with the presentation of ourGreenCall algorithm in Section 6. The implications of ourchoice in terms of results and subsequent discussion arepresented in Section 8.3.

5 BOUNDING NETWORK LATENCY AND ADAPTATIONWITH LOSS RATE

In the previous section, we showed how sleep periods can

be computed through the call if we have a bound on futurenetwork latencies. In this section, we look at how we canbound future network latencies through a systematic studyof actual network latency characteristics. We will alsopresent an adaptive approach to deal with cases where thisbound does not hold and ensure that ensuing packet lossesare controlled. We begin by giving details of the collectionand description of the data sets we use to study how we canpredict bounds on network latencies.

5.1 Network Latency Data Sets

We collected multiple WAN latencies and WLAN latenciesto an AP. The sum of these gave us traces of end-to-end

latency between any two end points. The WAN traces werecollected from the University of Massachusetts (UMASS),Amherst, MA (termed site S0) to different node locationswithin and outside US with both end points having ethernetaccess to the Internet. The chosen end points werePlanetLab nodes to represent possible network latencies todifferent geographic points [29]. The names of these sitesalong with measured network characteristics from S0 arelisted in Fig. 3. We collected actual one way traces in bothdirections between site S0 and sites S1, S2, and S3. Due toinadequate Network Time Protocol (NTP) clock synchroni-zation on S4 and S5, we used the approximation of half theround trip time (RTT), or RTT/2 to these sites. WLANlatency traces were taken from a public AP at UMASS

during the daytime. The number of users on the networkvaried from 10-15 users at the times the traces werecollected with mainly HTTP traffic, and a few TCP/IPcontrol messages.6 We term the collected data sets asUMASS5. The latency traces were collected at intervals of 30and 60 ms as these are typical packet generation interval forVoIP calls and will reflect how network latencies evolveduring a call. In this section, we mainly study the latenciesgathered for the 30 ms interval. VoIP calls last for about12 minutes which translate to greater than 20,000 packetsfor a 30 ms packet generation interval [30]. Thus, for ourstudies in this section we look at traces of 20,000 packets.

5.2 Network Latency Characteristics

As the call proceeds, estimates of previous network

latencies are available for making predictions about boundson future network latencies. Thus, the first step is to studyhow accurately previous latencies reflect future networklatencies. We studied how often the next network latencyexceeds the Pth percentile of previous network latencies.Thus, for a given P, we have statistical information on howmany times the next latency will exceed the Pth percentilevalue (also called error rate or loss rate because packetsexceeding this bound will be dropped as sleep periods arecalculated based on the bound). Instead of considering allpreviously seen latencies while calculating the Pth percen-tile, we consider only the last H network latencies ofpackets. This sliding window of H latencies allowsincorporation of recent events affecting latencies while

discounting other prior events. This sliding windowapproach is storage and computation efficient as well.

We study network latencies of all traces in our UMASS5data sets with the results shown in Fig. 4. Each subplot isshown for a different value of H and considers the effect ofvalue of P on loss rate for 20,000 packets of each trace. Asexpected, increasing values of P decrease the loss rate.When P 100, i.e., the maximum latency of last H packetsis used as the latency bound for next packet, the loss rate issmallest. For all five traces, the variation in loss rate with Pis very similar. Increasing value of H results in smaller lossrates as more historical information is used in calculation of bounds. However, looking at the evolution of loss rates

with increasing H across subplots, it can be seen that benefits of larger H decreases fast, and a value of H 500provides barely any reduction in loss rate for the tracescompared to H 375. Thus, we can fix the value of H 500for calculation of network bounds. A look at Fig. 5 showingnetwork latencies from an 84-minute trace between nodes atUMASS Amherst and UC Berkeley provides the answer asto why this value ofH suffices to reduce loss rates to a smallvalue. The latencies are fairly constant around a base valuewith small variations, with spikes every 100-200 packets.This can be more clearly observed from the correspondingzoomed snapshot in Fig. 6. Thus, values of H greater than200 packets incorporate enough important events to

reduce loss rates.


Fig. 3. UMASS5 Data sets: Different sites and network latencycharacteristics between S0 and each site.

Fig. 4. Loss rate variation for different values of P and H for all traces inUMASS5 data sets.

6. We study the impact of a heavier traffic load on the WLAN side later

during our evaluations.



8/16

It would be natural to think that using P 100 would bethe best strategy to bound network latency values with smallloss rate. However, P 100 also results in conservativelatency bounds which reduces the size of sleep periodscalculated based on these bounds, and hence reduced energysavings. Latency bounds for P 98 or P 99 offer less

conservative latency bounds at the expense of additional lossrate (Fig. 4). The comparison of values of error frompredicted bounds for values of P 98, 99, and 100 areshown in Fig. 7 for H 500. After a latency spike thatexceeds the bound for P 100 (shown as a negative spikerepresenting underestimation), the value of the error spikesimmediately for the next H packets as it uses the maximumlatency seen as the bound. The bounds for P 98 are theleast conservative as it can discount some of these spikeswhen they fall above the 98th percentile. Thus, given a targetloss rate LR by the user, the value of P chosen should be thesmallest that has a loss rate less than LR. Or put more formally,

Pchosen min 8 P j LP LR;

where Pchosen is the selected value of P and LP is theassociated loss rate for the value. Considering the UMASS5data sets as an example (with only integral values ofP), withLR 2 percent, we require P ! 99 to satisfy this loss rate forall traces. As P 99 is less conservative, that should be thechoice for providing latency bounds compared to P 100.In general, we expect most network latencies between anytwo sites to have similar variation in loss rate with latencybounds as those shown here. This observation is supportedby other studies of Internet delay characteristics (e.g., [24]).For cases where the loss rate variation differs significantly,we introduce an adaptive property to the calculation of

latency bounds as explained next.

5.3 Adaptation of Latency Bound with Respect toLoss Rate

Note that the sleep period calculation in Section 4 reliesheavily on estimates of many parameters; when theseestimates are incorrect, there are either missed opportunitiesto save energy, or packets are lost. Further, the bounds onlatency for a certain value of P may have a larger thanexpected loss rate for some trace, and it is important toadjust to such scenarios. We, thus, rely on adding orsubtracting a shift value Sfrom the current latency bound tocontrol how conservative or aggressive the predicted boundis during the call. If the current loss rate is greater than theuser specified loss rate LR, the value ofS can be increased.Conversely, when the current loss rate is smaller than userspecified loss rate, Scan be decreased. This adaptation helpsbalance the trade-off between energy savings and loss rate.

For adaptation of S, we considered two alternatives toadjust its valueadditive increase additive decrease

(AIAD) and multiplicative increase additive decrease(MIAD) so that we increase S fast to bring down loss raterapidly, and then increase slowly to ensure we are not beingtoo conservative. We compared various values for thesefactors in terms of two criteria for all traces in UMASS5 datasets: 1) loss rate must be below specified LR at end of call,and 2) average value of latency bound through a call shouldbe small. The set of factors which had the smallest value forthe second criteria while satisfying the first criteria waschosen; this was found to be the AIAD adaptive schemewith an increment factor Cincf 5 and decrement factorCdecf 1. Through a call, the current loss rate is monitoredat intervals of 500 packets with constant Cinterval 500. This

provides a balance between adapting too frequently toobserve the effect on loss rate versus adapting too rarely tonot have enough control on loss rate. We also consideredscaling the latency bounds by a constant value instead ofadding a constant value as above but found that it did notperform as well in terms of the two criteria mentionedearlier to judge the effectiveness of the adaptive scheme. Weexplain some more details of the adaptation in the nextsection where we introduce the GreenCall algorithm.

6 GREENCALL ALGORITHM

Having described our approach to calculate sleep periods,

in this section, we present the complete GreenCall


Fig. 5. Network latencies over an 84-minute trace. The latencies arestable most of the time with only slight variations, and only a few spikeswhich are well separated.

Fig. 6. Close-up view of a few network latencies shown in Fig. 5.

Fig. 7. Values of error for the trace to S1 showing reactions to loss forP 98; 99; and 100. It can be seen that the bounds for P 100 are themost conservative (hence, has highest error value) followed by boundsfor P 99 and then P 98.



9/16

algorithm to derive sleep schedules during the call. Green-Call handles unknown network latencies by keeping trackof latencies suffered by previous packets received at clientand predicts latency bounds for future network latencies, based on which subsequent sleep periods are calculated.The magnitude of shift value S used for network latency bounddepends on the current loss rate. Consequently, at higher loss

rates, more conservative sleep periods are used. Thisenables a smooth trade-off between loss rate and energysavings and is the main feature of the algorithm. We willconclude the section by presenting a variant of GreenCallwhich does not require feedback between the client andpeer, thus enabling independent operation.

The GreenCall pseudocode is presented as an algorithmin Fig. 8. The algorithm can be divided into three phases:an initialization phase followed by two phases as eachpacket arrives.

The initialization phase, Phase 0, deals with the collectionof parameters defined by the application as well as tunableparameters of the algorithm. The final step of this phase is toestimate the one way first packet network latencies lpc and lcpbetween the client and the peer and vice versa, and the oneway latency between client and AP, lac. This is done bysending special control packets (ICMP echo packets) fromthe client to each of these points to get the RTT. This RTT isthen divided by two to be used as a one way latency estimate.To account for variability, these estimations are collectedover a series of 10 packets with the second to largest of thesechosen in an attempt to avoid an underestimate of networkdelays. Since, at this point theclient has not begun transitionsto sleep mode, these measurements give the true picture oflatencies between these points without introducing anydelays due to buffering at AP.

Phase 1 begins with the calculation of spare time for

packets as the algorithm loops for each packet received

until the call continues. Note that this calculation is doneonly for the first packet after a sleep period as this signifiesa decision point of the algorithm from where the next sleepperiod is derived. At this decision point, only the estimatedspare time (as described in Section 4) of this packet isutilized along with values of known application constants.Subsequently, once the AP has no more packets buffered for

it, the client goes to sleep for duration k, the duration ofkth sleep period. This duration k considers whether thepeer is running GreenCall as well through the use of aconstant Cshare as described in Section 4. When the sleepperiod is not greater than zero, the client just stays in theconstantly awake mode (CAM). To ensure that the clientdoes not interrupt its sleep period to send packets, the clientbuffers any generated packets until it wakes up. On wake-up, the client contends for the medium with downlinkpackets from AP to send all its packets.

Phase 2 deals with the adaptation ofS. Large values ofSwill result in more conservative sleep periods (minimizingpacket losses). On the other hand, if more network losses

are tolerable or if the network latency is estimated to varyonly slightly over time, we can save more energy by beingmore aggressive in selecting a sleep period with smallervalues ofS. To stay within a target loss rate LR, and achievemaximum possible energy savings, the algorithm con-stantly monitors the current loss rate and adapts the valueofS as explained in Section 5. The monitoring begins after aminimum number of packets, Cmin have been received, andis done every Cinterval packets thereafter. 1 and 2 arethresholds used to control loss rate below LR and avoidhysteresis. If the peer is running an energy savingalgorithm, the client tries to control its loss rate throughadaptation of S. Once the maximum S has been reached, it

sends a feedback to the peer for it to increase its estimate oflcp so that future sleep periods take that into account. Anincreased lcp would decrease sleep times at peer and thusimprove loss rate situation at client. Once loss rate is backbelow LR 2, the client sends feedback again to let peerdecrease its lcp to original levels. The adaptation of Sis donethrough two constant factors: Cincf to increase it and Cdecf todecrease it whose values we discussed in Section 5 alongwith the value ofCinterval. The values for other constants weused in the evaluations that follow are Cmin 100, Cfb 5,Smax 100, 1 0:05, and 2 0:1.

GreenCall operation without feedback. In some scenar-ios, it is desirable that the client runs independently from

the peer without any mutual feedback. For example, thepeer might be running on a device on which adding newsoftware (to run GreenCall) is not feasible or desirable. Forsuch scenarios, we consider a separate variant of GreenCallwhere only one of the two ends is sending packets at a time by using silence suppression7 and the client tries to saveenergy only when it is not sending packets. Thus, when it isthe turn for the clients user to talk, all packets generated aresent with no attempts made to transition to the sleep modeuntil it is the turn of the peer user to talk. The sleep period


Fig. 8. GreenCall algorithm.

7. During a call, for intelligible conversation, only one party is speakingat a time. Thus, only the packetization and transmission of the voice of thisparty is necessary. The packetization and transmission of silence of the

other party is unnecessary and can be suppressed.



10/16

calculations are done similarly as listed in GreenCallalgorithm shown in Fig. 8. Because the client attempts totransition to sleep only at time when the peer user is talking(as opposed to the typical case where it attempts to sleep atall times through the call), this approach will reduce theamount of energy saved, but will allow operation withoutany feedback. With only one end sleeping at a time (because

only one side is talking at a time) each end uses Cshare 1.We compare the possible energy savings with this variant ofGreenCall in our evaluations in Section 8.3.

7 EVALUATION THROUGH EMULATION

In this section, we discuss our experiences of evaluatingGreenCall with commodity hardware/software throughemulations.8 We study the specific case of no silencesuppression with a packet generation interval of 30 ms.We discuss how sleep periods in GreenCall can be set by theclient. Specifically, we will describe why legacy PSM is notsuited for this purpose and how the 802.11e standards

UPSD mode can be utilized. We also motivate whyGreenCall is a better alternative to save energy duringVoIP traffic than the UPSD mode. We will do a moredetailed study of how much energy can be saved with otherpacket generation intervals and scenarios in the followingsection through trace-based simulations.

7.1 Experimental Setup

We begin by describing our VoIP emulation setup and thechallenges faced in implementing flexible sleep periodswith GreenCall in commodity hardware, and how weovercome it. Next, we will describe our power measure-ment setup that is used to quantify energy savings ofGreenCall. This will be followed by describing the user

quality specifications for a call.

7.1.1 VoIP Emulation

The client was a Linux-based laptop with a Belkin IEEE802.11n wireless card operated through the RT2860 linuxdriver from Ralink Tech. Almost all 802.11n based driversallow both the legacy PSM mode as well as 802.11e UPSDmode. We chose this card for its ease of configurability inLinux. For the following experiments, a 12-minute con-versation is used which is the typical average length of aVoIP session [30]. In our experiments, we chose to emulatetraffic with parameters derived from typical VoIP callsrather than use real VoIP sessions to provide moreflexibility and ensure repeatability across tests. Packet levelemulation also allows us to focus more on the networkingissues and bypass application level operations involved thatdo not affect the results of this work. In our emulated VoIPsession, UDP packets of 160 bytes were continuouslyexchanged between the mobile client and a peer for theduration of the call. The traffic generating interval TI wasset to 30 or 60 ms which are typical voice framepacketization rates.9 When the radio was in sleep mode,

the generated packets were buffered and sent after the sleepperiod elapsed. The packetization delay Tpktz, and decodingand playout delay Tpb were both set to 20 ms. The client waskept at UMass Amherst while the peers were Planetlabnodes that were used to collect our UMASS5 data setsshown in Fig. 3. These pairs of nodes were expected toprovide good insights on how much energy savings can be

expected over diverse paths on the Internet owing todifferences in proximity and geographic locations.

7.1.2 Legacy PSM Limitation and Leveraging 802.11e

The sleep periods calculated by the GreenCall algorithm canvary over a wide range. However, legacy PSM dictates thatsleep periods specified by nodes be multiples of the AP BI,which is typically 100 ms. This also means that GreenCallcannot setsleep periods less than BI which arequite commonfor paths between sites separated by large geographicdistances like those between US and India or China whichhave large network latencies as seen in theUMASS5 data setsin Fig. 3. Thus, unless the 802.11 standards are modified to

allow clients to set flexible sleep periods, the completebenefits of GreenCall cannot be realized.

We overcome this limitation for our evaluation byleveraging the Unscheduled Power Save Delivery (UPSD)mode in the 802.11e standard to allow for clients toindirectly control their sleep periods. As briefly explainedin Section 2, in the UPSD mode, every uplink packet fromclient to AP triggers downlink packets buffered at the AP tobe delivered to the client. Thus, the client can control whenit receives packets from the AP by adjusting how long itbuffers uplink packets. Note that this requires packets to beexchanged in both the uplink and downlink directionsthis implementation of GreenCall will not work when

silence suppression is used. The same limitation is alsopointed out in [23]. We will rely on our evaluations throughtrace-based simulations to study how GreenCall works withsilence suppression.

7.1.3 Power Measurement Setup

The power measurement setup (Fig. 9) used was similar tothat in [31], where a PCMCIA Extender (Sycard PCCExtend140A) was used to expose the pins of the wireless card.Voltage drop across a 1-ohm resistor in series was used todetermine the current drawn, and hence the powerconsumption. A Tektronix TDS2002B oscilloscope was usedto measure the average voltage consumption and project

energy consumption for the call.


Fig. 9. Energy measurement setup of wireless card.

8. Only the VoIP traffic is emulated. We have implemented the rest of thesystem on commodity hardware. The reason for emulating VoIP traffic isexplained in Section 7.1.1. Practical aspects of integrating with VoIP clientsare discussed in Section 9.

9. We confirmed the ease of setting parameters like codecs on the open

source VoIP application Ekiga. More details are provided later in Section 9.



11/16

7.1.4 User Quality Specifications

The tolerable latency TL for our experiments was set at250 msbased on studies described in recommendations G.109 andG.114 of ITU-T [32], [33] which suggest 300 ms as a goodlatency to aim for in terms of user satisfaction. Our 250 ms

tolerablelatency is thus a conservative estimate.We specifiedthe tolerable packet loss LR as 2 percent for all experiments.Total packetlossratesof up to5 percent are known toprovidea fair to good call experience based on previous studies [34],[18]. From the perspective of Mean Opinion Score (MOS), theabove parameters translate10 to an MOS score 3.82 for theG.711 codec, where the impairment due to codec is 0.59,while the impairment due to delay, loss, and jitter amount to0.63. The MOS score has a scale of 1-5 with 1 the worst qualityand 5 the best quality. An MOS of 4 is considered good, whilean MOS of 3 is considered only fair. The parameters specifiedfor our experiments are closer to cellular quality as opposedto PSTN quality which typically has latency no more than150 ms and loss rate no more than 1 percent. We consider ourspecification reasonable for the user to allow for energysavings on the mobile device. We discuss the implications onenergy savings of using more stringent specifications whenwe present our evaluation results in the following section.

7.2 Energy Savings

Fig. 10 shows the corresponding energy savings for all fivedestinations from UMass Amherst in our UMASS5 data setsfor 30 ms packet generation interval with no silencesuppression. We took these measurements at five differenttimes of the day and present the mean and standarddeviation in the figure.

The energy savings to the first four sites are within the

standard deviation of each other, giving theinteresting resultthat smaller sized sleep periods do not necessarily result inlesser energysavings. On thecontrary, we found that smallersleep periods, like those used between S0 and S4 of $75 ms,can be just as effective. This is because the greater latency between sites only alters the duration of calculated sleepperiods and thus number of transitions to sleep, and resultsin differences only due to the overhead of transitions alongwith any additional overhead due to prevailing network and

wireless channel conditions. The total amount of time spentin sleep state is very similar for the first four traces. As thesleep periods reduce further, like those between S0 and S5,the penalty due to greater number of wake-ups startsreducing energy savings. Interestingly, we observe that theloss rate to S5 is close to 5 percent. The reason for this is thatGreenCall was implemented using the 802.11e UPSD mode

which keeps the client radio in sleep mode for at least thepacket generation interval (30 ms in this case) each time before transmitting buffered packets. For a UPSD-basedimplementation, sleep periods less than packet generationinterval cannot be executed. On average, GreenCall calcu-lates sleep periods less than this for the trace to S5 whichshould result in much smaller energy savings (as will be seenin our simulations in the next section). The forcible use oflarger sleep periods for the trace to S5 resulted in higherenergy savings, but the loss rate was much higher than thespecified loss rate. Once calculated sleep periods drop belowthe packet generation interval, it would be better to come outof PSM altogether to reduce the loss rate. With the wireless

card we performed the experiments with, this was difficultto do without restarting the driver. This is however possibleon many other cards (e.g., Intel PRO3945 ABG card).

From our measurements, we found that the UPSD modeby itself saved about 40 percent energy as shown by thedotted line in Fig. 10. The energy consumption for thismode stays almost constant for calls between any twopoints as the communication and sleep pattern remains thesame, with differences only due to network and channelconditions (the small variations are not shown in plot forsimplicity). As the AP sends all buffered packets to theclient when the latter transmits every packet generationinterval, the AP buffer delay is bounded by this interval.Thus, there are obvious advantages to the UPSD mode interms of latency (as explained in more detail in [23]).However, by waking up every packet generation interval,the overhead of wake-ups is much higher with UPSD thanGreenCall. In GreenCall, the client buffers all generatedpackets for a sleep period and bursts them out at the end ofthe period. As the sleep periods used decrease, thedifference in power consumption between GreenCall andUPSD will decrease. The difference in power consumptionwill become zero as the size of the calculated sleep periodsdecrease below the packet generation interval, which is theminimum sleep interval of the radio in UPSD mode.

Discussion. The key result from the above experimentsis that higher network latencies do not necessarily imply

significantly lower energy savings. Energy can be saved aslong as the underlying network latency is not high enoughto induce losses by missing playout deadlines. Thus, energycan be saved for calls over a wide variety of paths on theInternet, not restricted to points in geographical proximityof each other. This also means that more stringentspecifications of tolerable delay would also save significantamount of energy. The only downside of a more stringentspecification of tolerable delay is that no energy savingswould be possible between end points that have latencieslarge enough to leave no time to sleep for the radio. Forexample, specifying TL 150 ms would result in no energysavings for calls between UMASS Amherst and China as the

network latency of 127 ms along with encoding and


Fig. 10. Measured energy savings for experiments with all five sites. Theplot shows the mean energy savings and standard deviation associatedfor each site.

10. These can be calculated from ITU G.107 and G.113 Appendix I whichdefine the E-Model, an algorithm for calculating MOS from measuredfactors. A simple calculator based on these documents can be found athttp://davidwall.com/MOSCalc.htm at the time of this writing. We also

specified a jitter value of 10 ms for these calculations.



12/16

decoding delays (40 ms) exceeds TL. More insight of this

key result will be provided in the following section.

8 EVALUATIONS THROUGH TRACE-DRIVENSIMULATIONS

Our experiments on commodity hardware had limitationsdue to the use of IEEE 802.11e UPSD mode for implementingGreenCall. Utilizing the UPSD mode did not allow evalua-tions for the case of using silence suppression as uplinkpackets had to be sent to collect downlink packets from theAP. Also, the use of sleep periods smaller than the packetgeneration interval could not be implemented as the radiospends at least this much time in sleep mode for each

transition when using UPSD. Thus, in this section, we ranourGreenCall algorithm over multiple actual traces of networklatencies using a custom-built simulator. The aim was to seehowour algorithmadapts as network latenciesfluctuateovera period of time, and how the duration of sleep periodscorresponds to energy savings over different paths. Toquantify the energy savings through the simulator we nowrely on an energy model as opposed to actual measurementsas in theprevious section. We begin by describing our energymodel followed by the results of our evaluations. TheUMASS5 data sets traces were used for these experimentswith the same user quality specifications as before.

8.1 Energy Model

We allowed the client to specify an exact sleep period in thesimulator. At the end of the call, with being the set of sleepperiods used during the call, the energy consumption wasfound based on theenergy model describedin (1)in Section 3.

E PtxTtx PrxTrx PidleTidle PsleepTsleep:

As mentioned before, in Section 3, the total duration of allsleep periods in uniquely determines the energy con-sumption of a call. This requires knowledge of powerconsumption in various modes as well as the time to transmitand receive a packet. We obtain these values by measuringthese values on our Belkin wireless card conforming to the802.11n draft specifications using the setup described in

Section 7. The specific measured values are provided forreference in Table 2 where Ttx

PUi1 ttx and Trx

PVi1 trx,

where ttx and trx are the time to transmit and receive eachpacket, with U packets transmitted in total by the client andVpackets received in total by the client. For a VoIP call,givenits duration, it is easy to compute U and V due to knownpacket generation intervals. The model does not take intoaccount retransmissions of packets which varies dependingon channel conditions and traffic load of neighboringstations. Those effects can be more effectively understoodfrom our implementation results in the previous sectionwhere energy consumed due to retransmissions are alsoaccounted for. We will discuss the effects of retransmissions

later in this section when we present our results.

8.2 Traffic Model

For our simulations, the traffic is based on constant packetsgenerated with intervals of 30 or 60 ms. The networklatency of these packets is based on gathered delay traces inthe UMASS5 data sets in Fig. 3. When no silencesuppression is used, packets are exchanged between theclient and peer constantly until the end of the call. Whensilence suppression11 is used, we generated a trace ofconversation between two people as per the recommenda-tions of ITU-T [36] for generating artificial conversations.This generated trace had periods of single talk, double talk,and mutual silence. The trace used had the client and peereach actively speaking for only about 40-50 percent of thetime. During the on-time of a node, packets are generatedevery fixed interval as mentioned above.

8.3 Results

In this section, we present the results obtained by runningGreenCall under different settings based on the experi-mental setup described in the previous section. In thissection, we also examine the effect of asymmetric networkpaths on the playout deadline estimation accuracy ofGreenCall. We conclude this section by studying theperformance of GreenCall with varying levels of contentionin the wireless link between the client and its AP.

8.3.1 Basic Experiments and Results

Here we look at energy savings obtained under differentsettings. This provides insight on the expected energysavings with GreenCall for different scenarios. We willinitially look at results for the scenario which we term astypical where silence suppression was not used, packet

generation interval was set to 30 ms, and peer was notrunning GreenCall.12 Subsequently, we will look at resultsfor scenarios that used silence suppression, or used a packetgeneration interval of 60 ms, or had the peer also runningGreenCall. The results are shown in Fig. 11.

The result for the typical scenario shows that greaterthan two-thirds of the energy consumed by the WLANinterface can be generally saved to different geographicpoints while keeping the packet loss rates down to tolerable


TABLE 2Measured Values Used in Energy Model

11. Silence suppression is sometimes used with VoIP traffic to reduce theload on the network by suppressing packets during silent periods. This isarbitrarily employed by different application developers. For example, VoIPapplication from Skype does not use it while the one from MSN does [35].

12. These typical settings are used for all experiments in later sections as

well, with any changes specifically mentioned.

Fig. 11. Energy savings with GreenCall under the typical scenario, withsilence suppression, with a 60 ms packet generation interval, and peeralso running GreenCall. Loss rates greater than target loss rate of2 percent are shown explicitly.



13/16

levels as specified. It can be seen that the energy savings arecomparable to that found through our implementation,with a slight increase that can be attributed to notaccounting for retransmissions on the channel. The onlyexception was S5 to which the network latency was too high(introducing losses by missing playout deadline even

without GreenCall) to have useful energy savings. Interest-ingly, it can be observed that the energy savings to S5resulted in much higher savings in our implementations inthe previous section than through the results of trace-drivensimulations here. The reason for this difference is thatGreenCall was implemented using the 802.11e UPSD modewhich sleeps for at least the packet generation interval(30 ms in this case) even though the actual calculated sleepperiods may be smaller. For all experiments, we alsoobserved a good balance between the important statistics ofloss rate and energy savings at the client and peer.Consequently, in Fig. 11, we have shown only the smallerof the savings at both ends, and larger of the loss rate at both ends. The energy savings across the first four traces

decrease very slowly in spite of large increases in averagenetwork latencies as seen in the results of the previoussection as well. For the final trace, the higher latency(resulting in smaller sleep periods) coupled with greaterinherent network losses (those not due to GreenCall) resultsin very conservative sleep periods by GreenCall. This wasverified by looking up the value of S at the end of theexperiment. Large values of S mean that the algorithm hadbecome increasingly conservative through the call.

To gain further insight, we plotted the possible resultsfor various possible network latency bounds used byGreenCall making use of our analysis of impact of radiotransition overhead in [37, Section 4] in Fig. 12. Theseanalytical results give the energy savings possible if a

specific network latency value is estimated by GreenCallthrough a call when compared to the case when no energysaving scheme is used. The values of constants used werethe same for other results in this section. This plot showswhy, for network latencies less than 150-160 ms, the energysavings changes very slightly with change in latency. Whennetwork latencies are greater, the number of transitionsincreases exponentially, thus, decreasing energy savingsrapidly. The implication of this behavior is that the impactof transition overhead becomes significant only when thenetwork latencies become large enough to result in a smallsleep duration to transition overhead ratio.

When silence suppression is used, with only one of the

two ends sending packets or periods of mutual silence

where no packets are exchanged, we surprisingly foundthat energy savings actually decreased slightly. We attributethis small difference to fewer packets being communicatedoverall. Note that the size of sleep periods does not changemuch with silence suppression because at least one end istalking most of the time and thus necessitates both ends toeither send or receive. When network latency is very high,for example, similar to that to S5, the transition overhead is

reduced when silence suppression is used. This results ingreater energy savings as compared to the case of no silencesuppression for such sites.

The performance of GreenCall with a large packetgeneration interval typically results in smaller energysavings. This happens because a greater value of TIdecreases the spare time calculated in (5) due to greateruncertainty about the arrival time of a packet in the APsbuffer. Fortunately, for VoIP calls, TI is typically no greaterthan 60 ms. Due to the reasons explained above, sleepperiods of half the size in this case, however, do not resultin halving the energy savings.

When the peer also ran GreenCall, the sleep periodswere calculated with Cshare 0:5 instead of Cshare 1,

which resulted in sleep periods of half the size. The greaternumber of transitions to sleep mode increased the overheadincurred due to notifications required between client andAP for each transition to sleep.

8.3.2 Performance of No Feedback Variant

In Section 6, we had presented a variant of GreenCall whensilence suppression is used that does not rely on feedback between the client and peer. Here, we show the energysavings we can expect with this variant. The aim is to judgeif any reasonable energy savings can be expected with theclient and peer functioning independent of each other. Theresults in Fig. 13 show that the no feedback version saves

only about one-third of the energy of the WLAN radio. Thisis primarily because the client sleeps only during talk spurtsof the peer, and each side talks for less than half the time forthe conversation trace used (described in Section 8). Thesesavings are impressive considering absolutely no coordina-tion is required between the two end points, whichincreases the applicability of GreenCall. From a practicalperspective, if silence suppression is not used, devicescompliant with 802.11e standard can provide similarsavings at each end without any coordination required.

8.3.3 Effect of Asymmetric Latencies

The network traces we used for experiments so far had more

or less symmetric latencies from client to peer and vice versa.


Fig. 12. Impact of network latency bounds on energy savings withGreenCall.

Fig. 13. Performance of no feedback version of GreenCall with silencesuppression. Loss rates greater than target loss rate of 2 percent areshown explicitly.



14/16

To test the effectiveness of initial GreenCall latency estimate based on RTTs for calculating playout deadlines, wedoctored the network trace from S0 to S1 to be asymmetricto various levels by adding a constant time to all packets ofthe trace in one direction. This preserves the underlyingvariability of latencies in the trace while introducingasymmetry. Due to asymmetric latencies, playout deadlinescalculated by GreenCall are expected to be incorrect as it usesRTT/2 as its network latency estimate in (3), and has no wayof knowing the degree of asymmetry (without time synchro-nized clocks, of course, which we do notassume).We show in

Fig. 14 the percent of packets that miss the actual playoutdeadline of packets based on their tolerable latencies (orpercent error), the average error, and the maximum erroramong all received packetsat theclient(whichis theside thatunderestimates actual latency). The notation S0 S1 cdenotes that a constant time c is added to original trace fromS0 to S1. GreenCall is unaffected in terms of energy savingsby the asymmetry because both ends are unaware of thiserror in estimation of latency. As expected, there is anincrease in error percent and is a limitation withoutsynchronized clocks. Interestingly, the error magnitudesare smaller than expected, and probably tolerable (up to10 ms asymmetry), mainly because the AP buffer is able to

absorb much of the asymmetry. We also ran these sameexperiments with a known maximum time synchronizationoffset of 5 ms. As a result, the client can upper bound theactual first packet network latency allowing it to calculateplayout deadlines correctly (with zero errors) in spite of theasymmetry in network latencies (which affects the RTT/2method of estimation). This ensures that there are no errors.The downside is that the energy savings at the clientdecreases as it incorporates the greater asymmetric latencyinto its calculation of sleep periods.

8.3.4 Effect of WLAN Contention

We have mainly focused on the effect of WAN latencies in

the above experiments. Here, we demonstrate the signifi-cant impact WLAN contention can have on GreenCall, andVoIP calls in general. Heavy WLAN contention increasesboth the average network latency as well as the variabilityof the links used in our experiments.

We collected traces to the same AP we used in theUMASS5 data sets mentioned in Section 5 with varyinglevels and types of surrounding traffic over the underlyingtraffic of 10-15 users with mainly HTTP traffic.13 The firsttype, termed voip-1, was a continuous VoIP call generatedfrom an adjacent node to study effect of such traffic on the

call in progress at the client. A heavier form of contentionwas produced by adjacent nodes through single FTPsessions for the duration of the call. A 1-GB file wasrepeatedly transferred in each FTP session. Depending onhow many adjacent nodes (one or two) generated such FTPtraffic, the scenarios were termed ftp-1 and ftp-2.Hybrid traffic with a VoIP call from one adjacent nodeand an FTP session from another adjacent node was termedvoip-ftp. Traffic without these other traffic types is alsoshown for reference, termed typical. Again, note that allfour types of surrounding traffic levels considered are inaddition to the underlying typical traffic. The level of trafficwas monitored at all times through another node to ensurecomparability across different scenarios. The WAN tracesbetween S0 and S1 were used for these experiments.

The results are shown in Fig. 15 with loss rates with andwithout GreenCall shown. The performance of GreenCallwas not affected much with surrounding traffic typesvoip-1 and ftp-1 due to only a small increase in averagenetwork latencies (1-10 ms). For voip-ftp and ftp-2 the

average latency increased to 16 and 64 ms, respectively,with many packets to the AP encountering latencies in therange 100-1,000 ms. This naturally led to those packets being dropped by GreenCall. Such high contention andresulting latencies would pose a problem for any VoIPapplication (looking at the high loss rates even withoutGreenCall). QoS guarantees at the MAC layer for VoIPtraffic as provisioned in IEEE 802.11e standard is thus anapproach in the right direction to handle the problem ofcontention for VoIP over WLAN. Additional latencies onthe WLAN link, for example, due to periodic handoffscannot be solved with just QoS guarantees. However, suchlatencies are incurred very infrequently (order of seconds tominutes at least) compared to the communication of packets

(order of milliseconds) and would not have as much of animpact as contention with heavy bandwidth users.

9 DISCUSSION

In this section, we discuss some practical aspects of Green-Call implementation and its utility for an average user.

Integration of GreenCall with VoIP Clients. Here, webriefly discuss how the GreenCall algorithm can work withVoIP application softwareour evaluations had only usedemulated VoIP sessions without looking at the integrationaspect. For the computation of sleep periods, GreenCallneeds to get the packet generation interval, packetization

interval, and time to encode and decode packets. These


Fig. 14. Percent energy savings and percent errors due to asymmetricnetwork latencies.

Fig. 15. Performance of GreenCall under various background trafficscenarios. The number within parenthesis shows the loss rate withoutGreenCall running.

13. We repeated the same experiments in a Coffee Shop scenario as wellwith 15-20 active users with similar traffic profiles and achieved similar

results.



15/16

values can be obtained by knowledge of the audio codecused through its publicly available specifications. To testhow easy it is to find information about the audio codecused for a call, we studied the open source VoIP clientsoftware Ekiga (formerly known as GnomeMeeting). As

shown in Fig. 16, Ekiga can be configured by the user to useany specific audio codec or multiple possible codecs. Whenthe two ends of the call negotiate and decide on a codec, thisinformation can be written into a log file which can be read by the GreenCall algorithm. By mapping the codec to itsspecified packet generation interval, packetization interval,and encoding and decoding delays, GreenCall can computesleep periods for the call.

Another aspect of this integration is the ability to bufferpackets that are generated and sent at the end of sleepperiods. In our Linux-based implementation, we used libipqwhich provides an API for userspace packet queuing. Thisallowed packets to be buffered and released at specified

intervals as the algorithm runs during the call. Similarly,libipq can be used to hand receive packets over to theapplication before their playout deadline.

Energy saving projections over a typical day. The mainfocus of our work was to save energy during VoIP calls. Theamount of energy consumed for a dual-mode or smartphone would depend on the time spent on calls and timespent in standby/idle mode in between calls. Here wepresent simple back-of-the-envelope calculations as to howmuch energy can be saved due to the wireless interface byrunning GreenCall with a typical cell phone talktimeprofile. We use the profile calculated in [9] where the userspends an average of 80 minutes per day talking on the

phone. Table 3 summarizes our calculations based onmeasured values from our card and shows the possibleenergy savings by using GreenCall. The first row shows theenergy savings when legacy PSM (card waking up every BI)is used when the phone is on standby and GreenCall is usedduring calls. The second row shows the energy savingswhen legacy PSM is used on the phones standby modewith no power saving algorithm used during the call. It canbe seen that about 20 percent of energy savings due to theWireless LAN radio can be achieved during a typical dayusing GreenCall. Considering that the WLAN interface isresponsible for greater than 50 percent of the total energyconsumption of such devices (e.g., see [38]), GreenCall can

be expected to save about 10 percent of the overall energy of

a low-end device like a smart or dual-mode phone, or aPDA. We believe this is a significant gain considering thatsaving power of the wireless radio in the idle mode has been a well researched problem over the years, andadditional savings can only be obtained by saving powerduring active communication as during VoIP calls.

10 CONCLUSIONS

We have addressed the important problem of saving energyfor mobile clients due to the wireless interface during VoIPcalls. We presented the GreenCall algorithm that leverages

the IEEE 802.11 PSM mode to save energy consumed by thewireless radio while at the same time ensuring thatapplication quality is preserved. Through extensive evalua-tions, both through experiments and trace-based simulationsover diverse Internet paths, we showed the utility ofGreenCall and underscored the great potential of savingenergyeven with real-time applications like VoIP. This pavestheway for saving energyduringactivecommunication withmore delay-tolerant traffic like audio and video as well.

ACKNOWLEDGMENTS

A preliminary version of this paper appeared in theProceedings of the ACM International Symposium on MobileAd Hoc Networking and Computing (ACM MobiHoc 2008),Hong Kong, May 2008.

REFERENCES[1] Wi-Fi Phones Make a Splash, CNET News, http://news.com/

Wi-Fi+phones+make+a+splash/2100-7351_3-5296745.html, 2009.[2] New T-Mobile Plan Cuts Costs by Using Internet, San Francisco

Chronicle, http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/06/27/BUGG6QM5DR1.DTL, 2009.

[3] Apple Iphone Technical Specifications, http://www.apple.com/iphone/specs.html, 2009.

[4] D-Link V-CLICK Makes It Easy to Switch from GSM and Wi-FiModes with a Single Click, http://www.slashphone.com/115/5464.html, 2009.

[5] A. Mahesri and V. Vardhan, Power Consumption Breakdown ona Modern Laptop, Proc. Power-Aware Computer Systems (PACS),2004.

[6] V. Raghunathan, T. Pering, R. Want, A. Nguyen, and P. Je

Documents

2010 - Energy-Efficient VoIP Over Wireless LANs (1)