leveraging the tail time for saving energy in

1536 IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 13, NO. 7, JULY 2014

Leveraging the Tail Time for Saving Energy inCellular Networks

Di Zhang, Yaoxue Zhang, Yuezhi Zhou, Member, IEEE, and Hao Liu

AbstractIn cellular networks, inactivity timers are used to control the release of radio resources. However, during the timeout periodof inactivity timers, known as the tail time, a large proportion of energy in user devices and a considerable amount of radio resourcesare wasted. In this paper, we propose TailTheft, a scheme that leverages the tail time for batching and prefetching to reduce energyconsumption. For network requests from a number of applications that can be deferred or prefetched, TailTheft provides a customizedapplication programming interface to distinguish requests and then schedules delay-tolerant and prefetchable requests in the tail timeto save energy. TailTheft employs a virtual tail time mechanism to determine the amount of tail time that can be used and a dualqueue scheduling algorithm to schedule transmissions. We implement TailTheft in the Network Simulator with a model for calculatingenergy consumption that is based on parameters measured from mobile phones. We evaluate TailTheft using real application traces,and the experimental results show that TailTheft can achieve significant savings on battery energy (up to 65%) and dedicated radioresources (up to 56%), compared to the default policy.

Index TermsCellular network, energy saving, inactivity timer, tail time

1 INTRODUCTION

WITH almost 6 billion mobile subscribers world-wide [1], mobile phones have become ubiquitousdevices. The increasing popularity of iOS- and Android-based applications has made mobile phones with richer fea-tures an indelible part of modern popular culture. However,the limited battery life of mobile phones constrains theemergence of more attractive and complex applications.

In cellular networks, radio resources shared among userequipments (UEs, e.g., smartphones) are known to be themajor power consumer in mobile phones [16], [32], [34].However, a large proportion (nearly 60%) of energy con-sumed by radio resources is derived from the timeoutperiod of inactivity timers [23]. These timers are used tocontrol the release of radio resources [7]. The idle inter-val corresponding to the inactivity timer timeout periodbefore radio resources are released is referred to as thetail time, and it is adopted to balance the trade-offs amongradio resources, user experience, energy consumption, andnetwork overhead [26]. However, the tail time results inthe wastage of radio resources and battery energy inUEs [23], [25].

We focus on the Universal Mobile TelecommunicationsSystem (UMTS) network, one of the most popular 3Gmobile communication technologies. To use limited radioresources efficiently [12], the UMTS introduces the Radio

The authors are with the Department of Computer Science andTechnology, Tsinghua University, Beijing, China, 100084.E-mail: {dizhang.thu, liuhao.buaa}@gmail.com; [email protected];[email protected].

Manuscript received 10 June 2012; revised 21 Sep. 2013; accepted 27 Sep.2013. Date of publication 2 Oct. 2013; date of current version 2 July 2014.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference the Digital Object Identifier below.Digital Object Identifier 10.1109/TMC.2013.126

Resource Control (RRC) protocol [7], which maintains astate machine for each UE [26]. Each state in which the UEoperates corresponds to different radio resource allocationand energy consumption level. Before data are transmitted,the state is promoted to a high-power state. However, frequentstate promotions may result in long delays for the UE andhigh management overhead for the UMTS network. Aftereach transmission is completed, the state is not immedi-ately demoted to a low-power state. The state machine waitsfor a certain duration (the tail time, reaches up to 15 sec-onds [25]), which results in the wastage of radio resourcesin the UMTS network and battery energy in UEs [23], [25].

A number of studies have been conducted to mitigatethe above described tail time effect, which can be dividedinto two categories: traffic aggregation and tail time tuning.Traffic aggregation approaches, such as TailEnder [23] andCool-Tether [17], schedule transmissions based on trafficpatterns. Small transmissions are aggregated into large onesso that the tails and energy consumption are reduced. Fordelay-tolerant applications (e.g., e-mail and RSS feeds) andprefetchable applications (e.g., news and social network-ing), data transmissions can be deferred or prefetched toachieve aggregation. However, low accuracy in predictingfuture transmissions may cause an increase in energy con-sumption during aggregation. For example, when only asmall amount of the prefetched data are needed by appli-cations, aggregation eliminates only a small number offuture tails but imposes high energy consumption for theprefetching itself [33].

Tail time tuning, the other type of approaches, tunesthe tail time in an effort to balance the energy wasted inthe tail time and the drawbacks incurred by state promo-tions. When the tail time is aggressively reduced to 0.5seconds, the state promotion delay is increased by about300% [25]. Thus, some researchers argue that saving energy

1536-1233 c 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

ZHANG ET AL.: LEVERAGING THE TAIL TIME FOR SAVING ENERGY IN CELLULAR NETWORKS 1537

necessitates the identification of a reasonable tail duration[18], [21], [20], [31]. However, even if a reasonable tailduration is found, the tail time still exists and causes con-siderable energy wastage. TOP [25], RadioJockey [29] andTraffic-aware approach [30] are three recently proposedmethods to tune the tail time. TOP and RadioJockey uti-lize a feature called fast dormancy [11] to terminate the taildynamically if they predict that no further data needs to betransmitted. Traffic-aware approach dynamically brings theradio to a connected or idle state by learning traffic patternsand predicting the start and end of traffic spurts, and it alsoinvokes fast dormancy to bring the radio to an idle state.However, the efficiency of dynamic tuning of these meth-ods depends on the accuracy of the prediction of futuretraffic patterns. Low prediction accuracy not only retainsuntuned tail time that still wastes energy, but also causesadditional state promotions, thereby wasting more energy.In addition, both RadioJockey and Traffic-aware approachare designed only for background traffic and thus cannotreduce energy wasted in the tail time generated by userinteractive applications.

To better mitigate the tail time effect, we proposeTailTheft [15], a scheme that leverages the tail time forbatching and prefetching to save energy. Our main con-tributions can be summarized as follows:

First, to the best of our knowledge, our work is thefirst to consider using the tail time, rather than eliminatingthe inevitable tail time specified by cellular specifications.TailTheft steals the tail time for two use cases: (1) trans-ferring delay-tolerant requests (e.g., e-mail and RSS feeds)in batches, and (2) prefetching data that are likely to berequested in the future (e.g., news and social networking).By scheduling a number of requests in the tail time, energyconsumption is significantly reduced in TailTheft becauseunused tail time is utilized and the total transmission time isreduced. Although prefetching is also performed in TailTheft,energy consumption is not increased, even with low prefetchaccuracy, because of the use of unoccupied tail time.

Second, to utilize the tail time with minimized impacton existing systems, a virtual tail time mechanism anda dual queue scheduling algorithm are proposed. The vir-tual tail time mechanism maintains virtual tail timers thatcorrespond to physical tail timers after a transmission iscompleted. These virtual timers determine the time duringwhich TailTheft can perform batching and prefetching. Themechanism also terminates tail transmission at the end ofthe virtual tail time. The dual queue scheduling algorithmdifferentiates between real-time requests and those that canbe batched or prefetched, after which it schedules the lat-ter in the virtual tail time and ensures that the real-timerequests are not affected.

Third, the tail time problem is analyzed in the NetworkSimulator (NS-2). Based on the simulative implementa-tion in NS-2 [5], we evaluate TailTheft performance usingreal application traces. The experimental results show thatTailTheft can achieve significant savings on battery energy(up to 65%) and dedicated radio resources (up to 56%).Our scheme also outperforms recently proposed tail opti-mization approaches for both traffic aggregation (up to62%) and tail time tuning (up to 18%) in terms of energyconsumption.

Fig. 1. (a) Overview of the RRC state machine. (b) Power curve of anexample transfer over the UMTS network.

The remainder of this paper is organized as follows.Section 2 describes the background of our study. Section 3formulates the problem, defines trade-offs, and explainsthe applied energy consumption model. Section 4 presentsthe design of TailTheft. Section 5 briefly describes thesimulative implementation of TailTheft in NS-2. Section 6presents the performance evaluation results. Section 7reviews related studies. Section 8 concludes the paper andgives directions for future research.

2 BACKGROUNDThe Radio Network Controller (RNC) is an important com-ponent of the UMTS network. Most features of the UMTSTerrestrial Radio Access Network such as radio resourcemanagement, packet scheduling, and some mobility man-agement functions are implemented in the RNC. Radioresources shared among UEs are potential bottlenecks inthe network. To use the limited resource efficiently, theRRC protocol described in [7] maintains a state machine(Fig. 1(a)) for both the UE and RNC.

Typical RRC states are described as follows.CELL_DCH. In the CELL_DCH (Dedicated Channel,

DCH hereafter) state, a dedicated physical channel is allo-cated to the UE in both downlink and uplink, thus enablingthe UE to use radio resources fully for the high-speedtransmission of user data. Given that communication viaDCH is bidirectional, both the transmitter and receiver ofthe UE should be active, thereby resulting in high powerconsumption in this state.

CELL_FACH. In the CELL_FACH (Forward AccessChannel, FACH hereafter) state, no dedicated physicalchannel is allocated to the UE. Instead, the UE uses theshared channels FACH (downlink) and Random AccessChannel (uplink) to transmit control messages and a smallamount of user data at very low speeds. Given thatFACH uses shared channels, this state consumes less radioresources and battery energy.

IDLE1. In this state, no RRC connection is established,and no radio resource is allocated. The UE cannot transferuser data.

Promotion and demotion are the two types of statetransitions. As illustrated in Fig. 1(a) and (b), the UE con-sumes more (less) radio resources and power after promo-tion (demotion). Promotion, which includes IDLEDCH,

1. A hibernation state called CELL_PCH is found in some UMTSnetworks. It is similar to IDLE, but the state promotion delay is shorter.


FACHDCH, and IDLEFACH2, is triggered by theBuffer Occupancy (BO) level (downlink and uplink buffersare separated) in the Radio Link Control (RLC) layer [19].When the state machine is in the IDLE state and the BOlevel is greater than 0, IDLEDCH promotion occurs.When in the FACH state and when the BO level of eitherdirection exceeds the configured threshold, FACHDCHpromotion occurs. In contrast to promotion, demotioncomprises DCHFACH, FACHIDLE, and DCHIDLE.Demotion is triggered by network throughput and inactiv-ity timers and , which are managed by the RNC [26].In the DCH state, the timer is reset whenever consider-able traffic is generated (because low traffic volume doesnot trigger timer being reset). When the throughput is 0 orless than the configured threshold for the RNC configuredtime (T1), the timer stops, and the state is demoted tothe FACH state. Similar to the timer, in the FACH state,the RNC resets the timer whenever it observes traffic.However, when the throughput is 0 for the configured time(T2), the timer stops, and the state is demoted to the IDLEstate.

Ramp energy and tail energy. Promotion time Pt1 per-tains to the delays of IDLEDCH (shown in Fig. 1(b),up to 2 seconds [26]), during which numerous controlmessages are exchanged between the UE and RNC forresource allocation. Promotion time Pt2 refers to the delaysof FACHDCH. A large amount of Pt1 and Pt2 not onlyincrease the RNC overhead, but also result in long delays tothe end-user and consume a considerable amount of energyin the UE (nearly 14% of transmission energy [23], wheretransmission energy refers to the total energy consumed dur-ing data transmission). We refer to this energy as rampenergy. The tail time denotes the idle interval that corre-sponds to the interval between the start and reset or startand expiry of inactivity timers. During the tail time, theUE has no data to transfer and only waits for the inactivitytimer to stop, although it still uses radio resources. Radiopower consumption remains at a level that corresponds tothat of the transport channel. We refer to this energy as tailenergy, which is nearly 60% of transmission energy [23].The tail time is necessary for mitigating the delays andoverhead of state promotion in case further transmissionoccurs.

Fast Dormancy. The fundamental purpose of employ-ing inactivity timers is that the network has insuffi-cient information to determine, at certain points in time,whether applications plan to transmit any further data.A natural approach is to enable the UE to determinethe end of network usage period because the UE canuse application knowledge to predict network activi-ties. Fast dormancy, which is included in 3GPP releases7 [9] and 8 [10], is a new feature based on this nat-ural way. Instead of waiting for inactivity timers tostop, the UE can send a special RRC control message(Signaling Connection Release Indication [11]) to the RNCfor state demotion to the IDLE (or CELL_PCH) state.However, the drawbacks of poorly used fast dormancyinclude more promotions and potentially long delays to theend-user [8].

2. IDLEFACH exists in some UMTS networks.

3 PRELIMINARY FORMULATION3.1 Differentiating ApplicationsCommon network applications in UEs include instantmessaging, e-mail, news, social networking (e.g., Facebook,twitter), browsing, media (e.g., videos, radio stream-ing), maps, RSS feeds and system (e.g., softwareupdates) [31], [32]. According to data accessing charac-teristics, these applications can be classified under threecategories: (1) applications that can tolerate delays, (2)applications that can benefit from prefetching, and (3)real-time applications, the data of which are neither delay-tolerant nor prefetchable. E-mail, RSS feeds and system areapplications that can tolerate a small user- or application-specified delay [24]. For example, a user may be willingto wait for a short time before e-mail is sent or receivedif it can save substantial energy. News, social networking,browsing, media and maps are applications that can benefitfrom aggressive prefetching [23].

The data accessing requests of the three aforementionedcategories of applications can be formulated as undividedrequests, where each request i has two attributes: an arrivaltime ai and a deadline di. The corresponding three cate-gories of requests are as follows: (1) real-time requests, whichrequire instantaneous scheduling after arrival and satisfyai = di, (2) delay-tolerant requests, which can be scheduledat a delayed period with di ai after arrival at ai and sat-isfy ai < di, (3) prefetchable requests, which can benefit fromprefetching and satisfy ai = di. Prefetchable requests can behandled in accordance with real-time requests, or add oneor more previous attempts before the corresponding prefetch-able request arrives [22]. Let PRi = {pr1, ...} denote theseprevious attempts, where the size of PRi is greater than 0.Suppose prj PRi, the arrival time of prj is aj and sat-isfy dj = ai (Note that previous attempts would not beattempted). If the data obtained by previous attempt prjis exactly the desired data indicated by the prefetchablerequest i, this request no longer requires scheduling. If theattempts fail, request i should be scheduled. Delay-tolerantrequests and previous attempts can be delayed, but thedifference between them is that the latter would be dis-carded as the deadline approaches because of the risk ofprefetching failure.

3.2 Scheduling Requests to Minimize EnergyThe ultimate goal of TailTheft is to schedule data accessingrequests so that the total energy consumption is mini-mized, while all requests are transmitted within their con-straints. The problem can be modeled as follows. Consider asequence of n requests, which comprise the four previouslydefined categories of requests. Let S = {s1, . . . , sn} denote aschedule that transmits request i at time si. The schedule Sis feasible if all requests are transmitted within their con-straints, which are defined in Section 3.1. For each request i,(1) if i is real-time, it should be transmitted instantaneouslyafter its arrival ai, (2) if i is delay-tolerant, it should be trans-mitted after its arrival ai and before its deadline di, (3) ifi is prefetchable, it should be transmitted instantaneouslyafter its arrival for an unsuccessfully prefetched request butshould be discarded for a successfully prefetched request,and (4) if i is previous attempt, it should be transmitted after


its arrival ai and before its deadline di, but should be dis-carded as its deadline approaches. When i is transmitted attime si, the RRC state machine generally transits to a high-power state (it may also transit to an intermediate-powerstate) and transmits i instantaneously. After transmissionis completed and no additional transmission occurs, thestate machine remains in the high-power state for T1 timeunits before transiting to a intermediate-power state. Ifno transmission occurs, the state machine remains in theintermediate-power state for T2 time units before tran-siting to the lower-power state, where T1 and T2 arethe tail time. Even when multiple requests are simul-taneously transmitted, state transition remains the samewith only one request. Let E(S) denote the total energyconsumption of the schedule S. The request schedulingproblem is to compute a feasible request schedule S thatminimizes E(S).

A simplistic schedule treats all requests as real-time,without considering delay and prefetch characteristics.However, this schedule may result in more state transi-tions and longer tail time. If numerous requests need to bescheduled, substantial energy is consumed by the tail timeand state promotions, and is also drained by sparse trans-mission. Additionally, given that the request queue is notknown a priori in practice, the schedule has to be computedonline. TailTheft follows the principle that delay-tolerantrequests and previous attempts are delayed and transmit-ted in the tail time within their deadlines. This action notonly uses the tail time, but also reduces transmission timeand numerous promotions.

3.3 Trade-offs Between Resource and User LatencyAn ideal situation is one wherein requests can always beresponded to in real-time. However, limitations in UE bat-tery capacity, radio resources, and the RNC processingcapacity make this ideal state difficult to achieve in prac-tice. The request scheduling problem introduces trade-offsbetween resource and user latency. Given a request queueR and a schedule S, we calculate two categories of met-rics to characterize these trade-offs. Some previous studiesfocus on only one factor [20], [21]. Although recent stud-ies [26], [25] have provided three types of metrics, thesemetrics are not the trade-offs that we consider in the cur-rent study and are not sufficiently precise (See Section 3.4).The two categories of metrics that we define are describedas follows.

The resource factor can be quantified by four metrics.

The energy consumption of the UE, denoted by E(S),is the total energy consumed during the schedule.E(S) comprises the energy consumed during statetransitions, transmissions, and the tail time. E(S) notonly reflects the resource consumption of the UE, butalso affects radio resource utilization and the RNCoverhead.

Duration in the DCH state, denoted by D(S), quan-tifies the dedicated radio resources consumed by theUE on dedicated channels.

Duration in the FACH state is denoted by F(S). F(S)quantifies the radio resources consumed by the UEon shared channels, which should be considered.

Fig. 2. Power curve of a transmission process.

The number of promotions of IDLEDCH andFACHDCH, denoted by P(S), quantifies the over-head incurred by state transitions that increase theresources used in the RNC. The overhead of statedemotions is disregarded, because it is significantlysmaller than that of state promotions.

User latency can be quantified by one metric.

The average interactive time, denoted by A(S), isthe interval between request submission and return,which can consequently reflect the speed of respond-ing to user requests. The A(S) of real-time requestsshould not be affected by the schedule.

We focus on the relative changes in resource metricswhen the schedule is switched with the same requestqueue. Let S denote the default schedule used as a com-parison baseline. Let S denote a new request schedule. Therelative changes in E(S), denoted as E(S), are computedby E(S) = (E(S) E(S))/E(S). D(S), F(S), and P(S)can be similarly defined. The key trade-off in our nota-tion is that for any transmission schedule, an increase inA(S) causes resource metrics to decrease. In other words,if the end-user can tolerate a certain delay, numerousresources are saved. We aim to identify a schedule S thatcan significantly decrease resource metrics while slightlyincreasing A(S).

3.4 Applied Energy Consumption ModelIn this section, we introduce an energy model appliedby TailTheft for calculating energy consumption E(S).Although some energy models have already been pre-sented, we only consider energy models that are used byexisting tail optimization approaches because the energyconsumption model is not the primary focus of this paper.The model given by TailEnder [23] does not determine theenergy consumption affected by transmission rate (whichrefers to the amount of data transferred per second) in theFACH state and does not measure FACHDCH promo-tion energy, which cannot be disregarded. TOP [25], [26]provides the power consumed during state transitionsbut does not determine the energy consumption affectedby transmission rate. To construct an accurate energymodel, we conduct a series of measurements on a NokiaN81 device using Energy Profiler [2] to obtain a set ofenergy consumption data. Based on the data set, we ana-lyze the energy consumption of different states and statetransitions.

Fig. 2 illustrates the power curve of a measured trans-mission process, where a transmission process refers to thechange in power state from low to high and then back tolow. Let Ei denote the energy consumed by a transmission


process, then E(S) = Ei. We divide Ei into four parts,which are shown below.

(1) The energy consumed by IDLEDCH promotion(part (1) in Fig. 2), denoted by E1p, is affected by the aver-age power and duration of IDLEDCH. Let Wi2d and Pt1denote the average power and duration of IDLEDCH,respectively, then E1p = Wi2d Pt1.

(2) The energy consumed in the DCH state is denoted byE1s (part (2) in Fig. 2). Power in the DCH state is influencedby both the transmission rate and duration of the DCHstate [23]. Let function Dw(vt, t) denote the power in theDCH state, where vt is the transmission rate at time t. Then,E1s =

t2Dt1D

Dw(vt, t)dt, where t1D is the start time, and t2D is

the end time of the DCH state.(3) The energy consumed by FACHDCH promotion

(part (3) in Fig. 2), denoted by E2p, is affected by the aver-age power and duration of FACHDCH. Let Wf 2d and Pt2denote the average power and duration of FACHDCH,respectively, then E2p = Wf 2d Pt2.

(4) The energy consumed in the FACH state is denotedby E2s (part (4) in Fig. 2). Power in the FACH state is influ-enced by both the transmission rate and duration of theFACH state. Let function Fw(vt, t) denote the power in theFACH state, where vt is the transmission rate at time t. ThenE2s =

t2Ft1F

Fw(vt, t)dt, where t1F is the start time, and t2F is the

end time of the FACH state.For a certain UE in a specified UMTS network, E1p and E

2p

are constants, denoted by C1 and C2, respectively. SupposeNp FACHDCH promotions occur (Np 0, not all trans-mission processes have only one FACHDCH promotion),then the energy consumed by a transmission process iscomputed as:

Ei = t2D

t1D

Dw(vt, t)dt + t2F

t1F

Fw(vt, t)dt + C1 + Np C2. (1)

To identify the parameters of our energy model, weconduct two measurement experiments. In the first experi-ment, we build a web server with configurable bandwidth,and energy consumption is measured when the phonedownloads a 5 MB file from the web server under dif-ferent bandwidth configurations. In another experiment, amessage receiver is started on the phone. We then sendmessages to the phone from another device and keep thestate machine in the FACH state while energy consump-tion is measured. After these two experiments, we obtainthe functions Dw(vt, t) and Fw(vt, t). Linear polynomials areused to fit the measured energy consumption data, and thefit results are shown in Fig. 3. The other parameters of theenergy model are obtained through the analysis of a daysenergy consumption data.

Table 1 lists the parameters derived from the mea-surements. Compared with previous measurements[25], [23], [31], the tail time in our result is shorter byhalf because of the differences in the configurations ofvarious operators. Moreover, the variances among mobilephones and the applications running on the mobile phonesgenerate a power difference.

Fig. 3. Fit results of energy consumption. (a) DCH. (b) FACH.

4 TAILTHEFT DESIGN4.1 TailTheft OverviewWe develop TailTheft, a protocol with the end goal ofscheduling data requests to minimize UE energy consump-tion. Tail energy and ramp energy are introduced to accountfor the majority of energy waste. In addition, a lengthyand sparse transmission forces the RRC state machine toremain in a high-power state for a long time, which alsoresults in large energy consumption. To minimize energyconsumption, TailTheft utilizes the tail time for batching andprefetching, which not only utilizes the unused tail time butalso reduces the total transmission time, thereby reducingenergy consumption. The challenges that we face are: (1)how to distinguish different categories of requests, (2) howto realize aggregating transfers in the tail time and pro-cess all requests under the constraints of various kinds ofrequests, and (3) how to reduce the impact on existing sys-tems (especially on the cellular network) when transmittingdata in the tail time. TailTheft employs a set of techniquesto address these challenges.

First, TailTheft provides a customized application pro-gramming interface (API) for applications. Applicationsindicate the type of request, the time that can be delayedor prefetched by calling the TailTheft API, as well as thetype of action taken as the deadline approaches.

Second, a mechanism called virtual tail time is proposedto determine the time during which batching and prefe-tching can be conducted. When the tail time is used fordata transmission, inactivity timers and are reset. Tocomplete the state transitions originally triggered by timers and , TailTheft introduces two timers, and , toreplace the functions of and in the UE as well as todetermine the time that can be used for batching and prefe-tching. In addition, TailTheft uses fast dormancy to triggerDCHIDLE or FACHIDLE demotion.

Third, to schedule all requests under their constraints, adual queue scheduling algorithm is proposed. Two queues are

TABLE 1Measured Energy Model Parameters


maintained for data requests: one for real-time and unsuc-cessfully prefetched prefetchable requests and another fordelay-tolerant requests and previous attempts. We refer todelay-tolerant requests and previous attempts as TailTheftrequests. When a request is added to the TailTheft requestqueue, TailTheft starts a timer , the timeout value of whichis the latest deadline of all the requests in the queue. Timer ensures that all delayed requests are processed before thespecified deadline.

4.2 The Interface for Distinguishing RequestsApplications can define the delays for a delay-tolerantrequest according to their needs. Applications can alsoadd previous attempts for a prefetchable request basedon their prefetching strategy and can determine whichrequest is successfully prefetched and re-submit unsuc-cessfully prefetched requests. Unlike applications, TailTheftis unaware of the manner by which applications definetheir requests. To distinguish different requests defined byapplications, TailTheft provides a customized API for suchapplications. An application informs TailTheft how to pro-cess a request via a simple API SubmitRequest(r_delay). Ifr_delay is 0, the request may be a real-time or an unsuccess-fully prefetched request (successfully prefetched requestwould not be submitted) that should be transmitted instan-taneously. If r_delay is a positive value, the request isdelay-tolerant and can thus be delayed for r_delay timeunits. If r_delay is a negative value, the request is a pre-vious attempt that likewise can be delayed for -r_delaytime units. However, the difference between delay-tolerantrequest and previous attempt is that the latter would bediscarded as the deadline approaches. TailTheft schedulesrequests as indicated by the parameter r_delay.

4.3 Virtual Tail Time4.3.1 Determining Whether the Tail Time can be UsedAchieving batching and prefetching in the tail timerequires identification of the time during which thesetasks can be performed. The types of demotion, namely,DCHFACHIDLE or DCHIDLE, can be accuratelydetermined [26], [27]. The former demotion type has twotail times (T1 and T2), and the latter has only one tail time(T1). The mechanism of the two tail times can be directlyapplied to one tail time. Thus, we consider only the for-mer. We separate the two tail times primarily because thescheduling rates in these two periods are distinct.

Two mechanisms are employed for online determinationof whether now is the tail time. Power-based state inferencemechanism is used to infer the current RRC state basedon power consumption. Determining the current RRC stateis the foundation of distinguishing between the two kindsof tail time. However, no API or known work on directlyaccessing RRC state information in smartphone systems isavailable [27]. Radio resources are the major power con-sumer in UEs [34], thereby making power consumption aconvenient factor for inferring the RRC state. Moreover, apower-based state inference mechanism has been proveneffective with high accuracy [27]. Given that it can exhibithigh accuracy (more than 95%), the error estimate of thismechanism is disregarded. Virtual tail time that is used to

TABLE 2Parameters Set in TailTheft Implementation

determine whether now is the tail time, which correspondsto the original inactivity timers maintained by the RNC.After transmitting data in the tail time, the inactivity timersare reset, such that the physical tail time is broken. Werefer to the used tail time as the virtual tail time. A timer isrequired to determine whether now is the virtual tail timein the current RRC state. We refer to this timer as the vir-tual tail timer, which performs operations that are similarto those performed by the inactivity timer maintained bythe RNC. Two timers correspond to the virtual tail times ofthe DCH and FACH states, which are denoted as and ,respectively.

Similar to the inactivity timer , the virtual tail timer is activated when the throughput is 0 or under the config-ured threshold (Table 2). (1) If timer is activated when thethroughput is 0, TailTheft can start transmitting data afterthe timer is activated and stop when the timer expiresor is reset. (2) If timer is activated when the through-put is under the configured threshold but greater than 0,TailTheft cannot transmit data after the timer is activated.If TailTheft transmits data under this condition, the trans-mission of real-time data may be ongoing when the timer expires, and demotion at this time would trigger additionalstate promotions. Thus, having no transmission at the sec-ond condition would not reset the inactivity timer , andthe state is demoted to the FACH state after the expiry oftimer . When in the FACH state, the virtual tail timer would be activated only when the throughput is 0. TailTheftcan start transmitting data after timer is activated and stopwhen the timer expires or is reset.

4.3.2 Terminating Tail TransmissionAs previously discussed, transmitting data in the tail timeresets the inactivity timer maintained by the RNC, causingthe RNC to forgo demotion at the end of the virtual tailtime. Thus, how to trigger demotion by the expiry of thevirtual tail timer is another important issue. In Section 2,we introduced fast dormancy, based on which the UEcan actively request for state demotion to the IDLE state.TailTheft invokes fast dormancy that triggers DCHIDLEor FACHIDLE demotion when the virtual tail timerstops. However, direct demotions to IDLE or CELL_PCHmay prevent complete data transmission in the RLC buffer,causing additional state promotions. Before invoking fastdormancy, TailTheft delays until the RLC buffer is empty.To ensure this condition, the delay is set to the longestconsumption time of the RLC buffer (Table 2), which can


be inferred by transmitting two packets with a delay inbetween [28].

Another problem is that although now is the virtualtail time, no data is available for batching and prefetching.Direct demotions may result in more promotions. TailTheftuses the concept of short tail time discussed in [31], inwhich the burst characteristics of user traffic are exploited.Let T3 denote the time within which most of the previouspackets (more than 95%) are transmitted. TailTheft triggersdemotion directly after T3 time units since the virtual timerhas been started. We can obtain the value of T3 by analyz-ing traffic patterns or set a fixed value according to thestatistical data of the end-user. We set a fixed value of T3in this paper (Table 2).

4.4 Dual Queue Scheduling AlgorithmScheduling requests feasibly, as defined in Section 3.2,is another problem to be discussed in this section.Applications submit network requests by calling the APIdefined in Section 4.2. According to the parameter r_delay,requests can be divided into two categories: requeststhat must be scheduled instantaneously (r_delay is zero,including real-time and unsuccessfully prefetched requests)and requests that can be delayed (r_delay is positive ornegative). Requests that can be delayed, referred to asTailTheft requests, include delay-tolerant requests and pre-vious attempts. TailTheft employs a dual queue schedulingalgorithm for scheduling these two categories of requests.TailTheft schedules requests by maintaining two queues:(1) the real-time queue for requests that must be scheduledinstantaneously, and (2) the TailTheft queue for TailTheftrequests. TailTheft schedules requests in the real-time queueif requests are present in this queue and schedules thosein the TailTheft queue if the real-time queue is empty orif the deadline of the first request in the TailTheft queueapproaches.

4.4.1 Handling TailTheft RequestsAs shown in the preliminary formulation in Section 3.2,TailTheft is feasible if and only if it not only transmitsrequests in the real-time queue as soon as they are inserted,but also processes requests in the TailTheft queue beforetheir deadlines. Specifically, delay-tolerant requests shouldbe scheduled before their deadlines, and previous attemptsshould be scheduled before their deadlines or discardedas their deadlines approach. To meet the deadlines indi-cated by requests, the dual queue scheduling algorithmintroduces a new timer . After being delivered by applica-tions, TailTheft requests are added to the queue from smallto large, according to the time between tnow and di, wheretnow is the current time, and di equals to the sum of thearrival time ai and the absolute value of r_delay of requesti. The first request in the TailTheft queue is assigned withthe latest deadline and is the first to be transmitted. Aftereach enqueue operation, TailTheft derives the latest dead-line, denoted as dl, and restarts the timer , the end timeof which is dl tnow. When now is the virtual tail time, thefirst request in the queue is dequeued first. Timer is can-celed before the first request is dequeued and reactivatedaccording to the deadline of the next request in the queueafter dequeuing.

Algorithm 1 TailTheft API1: dl: the latest deadline of request in Qt2: procedure SUBMITREQUEST(r_delay)3: i the submitted request4: ai current time tnow5: if r_delay = 0 then6: Qr.enqueue(i)7: else8: dl Qt.enqueue(i)9: .restart(dl ai)

10: end if11: end procedure

However, if the first request in the TailTheft queuehas not been transmitted when the timer stops, therequest should be directly dequeued. TailTheft processesthis request according to the value of r_delay. If r_delay ispositive, the request is delay-tolerant and should be sched-uled immediately, regardless of the current RRC state. Ifr_delay is negative, the request is a previous attempt andshould be discarded. Similarly, the timer should be reac-tivated according to the deadline of the next request in thequeue after dequeuing.

4.4.2 Controlling Transmission RateIn the virtual tail time of the FACH state, excessively hightransmission speed expands the occupancy of the RLCbuffer to a level greater than the threshold set by the RNC.This expansion results in FACHDCH promotion, therebycausing additional energy consumption. To prevent trigger-ing promotions when transmitting requests in the FACHstate, TailTheft transmits data according to the size andconsumption time of the RLC buffer (Table 2) [28], andensures that the buffer occupancy level does not exceedthe threshold. Let bot denote the buffer occupancy in thecurrent time and BO denote the buffer occupancy thresh-old set by the RNC. Request scheduling of TailTheft inthe virtual tail time of the FACH state should satisfybot < BO.

The dual queue scheduling algorithm is presented inAlgorithm 2. Let Qr and Qt denote the real-time andTailTheft queues, respectively. Applications invoke theTailTheft API shown in Algorithm 1 to submit requests. Themain procedure of Algorithm 2 shows how TailTheft sched-ules requests queued in the real-time and TailTheft queues.The procedure TimeOut_Theta shows the timeout operationsof the timer and the procedure TimeOut_GammaAndDeltashows the timeout operations of the timers and .

5 SIMULATIVE IMPLEMENTATIONWe implement TailTheft via simulation in NS-2 [3] basedon EURANE [4], and the source code can be found inGithub [5]. EURANE is an implementation of the UMTSnetwork in NS-2, which is extensively used in simulationstudies on the UMTS network [35], [36]. EURANE hasadded most of the UMTS protocol stack to NS-2. However,the implemented protocol stack does not include the IDLEstate and the tail time. Therefore, the following worksshould be done: (1) adding the IDLE state, (2) implement-ing the tail time, and (3) consummating state transitions. We


Algorithm 2 Dual Queue Scheduling algorithm1: dl: the latest deadline of request in Qt2: tnow: the current time3: vc: the throughput of current time4: procedure MAIN5: loop6: s Infer the RRC state with power7: if Qr.length() > 0 then8: i Qr.dequeue()9: Schedule i

10: else if Qt.length() > 0 then11: if or is started then12: .cancel()13: i, dl Qt.dequeue()14: .start(dl tnow)15: if s is DCH && vc = 0 then16: Schedule i17: else if s is FACH then18: Schedule i satisfy bot < BO19: end if20: end if21: else22: Terminate the virtual tail based on T323: end if24: end loop25: end procedure

26: procedure TIMEOUT_THETA27: i, dl Qt.dequeue()28: if r_delay > 0 then29: Schedule i30: else if r_delay < 0 then31: Discard i32: end if33: .start(dl tnow)34: end procedure

35: procedure TIMEOUT_GAMMAANDDELTA36: Delay until the RLC buffer is empty37: Invoke fast dormancy38: end procedure

complete these works based on the parameters measuredfrom actual phones.

Table 2 lists some of the important parameters estab-lished to implement TailTheft. For a more comprehensivecomparison with previous studies, the values of T1 and T2are established in accordance with measurements in [23]and [25], as well as the size and consumption time of theRLC buffer (x is packet size in byte) [25], [27]. The rest ofthe parameters are from our measurements.

After implementing an unbroken RRC state machine, weimplement TailTheft according to the design in Section 4.The works include: (1) modifying the channel switchingmechanism to add virtual tail timers in the UE, (2) modify-ing the multiplexer in the UE to implement the dual queuescheduling algorithm, (3) implementing transmission in thetail time, and (4) implementing fast dormancy. When per-forming these works, the most difficult task is ensuring thatcorrect transition occurs between different states because ofthe increased complexity of state transition. To guaranteethe reliability of the simulation results, the state transitionand transmitted data are verified.

TABLE 3E-mail Trace

6 EVALUATIONWe evaluate TailTheft performance against that of two exist-ing representative schemes, TailEnder [23] and TOP [25],where TailEnder is a traffic aggregation scheme and TOPis a tail time tuning scheme. TailEnder and TOP are alsoimplemented in NS-2, but for simplicity, TOP is imple-mented with a prediction accuracy of upcoming non-tailequal to 100% and a prediction accuracy of upcoming tailequal to p. These prediction accuracies result in better per-formance of TOP in this paper compared with that ofprevious study [25].

Two kinds of requests, delay-tolerant and prefetchable,are used to evaluate TailTheft, because a number of requestscan be deferred or prefetched, and these requests are thekey targets of TailTheft. According to the analysis of Falakiet al. [31], [32], we select requests of two common appli-cations, e-mail and news, for evaluation. E-mail is anapplication that can tolerate a moderate delay. News is anapplication that can benefit from prefetching. In addition,delay-tolerant and prefetchable requests are always mixedwith real-time ones. Therefore, the performance with mixedrequests is also evaluated.

We use E(S), D(S), F(S), P(S) and A(S) (definedin Section 3.3) as evaluation metrics. These metrics are cal-culated using the energy consumption models proposed inSection 3.4 and the parameters established in Section 5. Thecomparison baseline is the default transmission schedulewith unoptimized tail time.

6.1 Application Trace CollectionTo collect e-mail trace, we monitored mailboxes of 10 grad-uate students for 10 days (from May 20 to 29, 2013) andrecorded the time stamps and size of incoming and out-going mails. For e-mail attachments is not automaticallyreceived over cellular networks by mobile e-mail clients(e.g., Gmail), so the recorded size of e-mail does not includethe size of attachments. Table 3 tabulates the statistics of e-mail trace. To collect news trace, we polled Sohu3 news of9 major topics every 5 seconds for a span of 10 days (fromMay 28 to June 7, 2013). We recorded the arrival time andsize of each news story. Table 4 lists the topics and totalnumber of news of different topics.

Fig. 4 shows the proportion of wasted energy deter-mined using the collected application traces. We can seethat the proportion of total tail energy attributed to e-mail

3. http://m.sohu.com, a famous news site in China.


TABLE 4News Trace

is approximately 72%, whereas that attributed to news isapproximately 62%. Compared with news, requests of e-mail are sparser, causing more energy waste. In Fig. 4,mixture indicates the mixture of e-mail and news traces(which is further described in Section 6.4). The differenceamong these mixtures is the configuration of tail durations.Mixture 1 is configured with the default tail durations,where T1 = 5s and T2 = 12s. The tail durations of mix-ture 2 and 3 are T1 = 2s, T2 = 4.5s and T1 = 6s, T2 = 4s,respectively. Comparing different mixtures, we can identifythat short tail durations waste less energy, but cause morepromotions.

6.2 Impact on Delay-Tolerant RequestsTo evaluate the effectiveness of batching in TailTheft, wecompare TailTheft performance with that of TailEnder andTOP using the e-mail trace. For a clearer comparison, TOPis implemented with two prediction accuracy values (p =0.7 and 0.9). The incoming and outgoing e-mail requestsare set with a varying delay deadline di (from 1 second to2000 seconds).

Fig. 5 plots the impact on metrics for delay-tolerante-mail requests. When the di is short (1 to 50s), the energysavings of TailTheft increase quickly, because prolongingthe di decreases the number of timeout operations of timer rapidly, which reduces the DCH time and the numberof state promotions observably. With the increase of di(greater than 50s), the increase of batched requests gradu-ally decreases, so the energy savings of TailTheft graduallyapproach its maximum value. TailTheft achieves its maxi-mum energy savings with the di of 500s, whereas TailEnderneeds more than 2000s (Fig. 5(a)). At the di of 500s, TailTheftexhibits 48% more energy savings than TailEnder. TOP doesnot defer transmission, thus, its performance does not varywith di but heavily depends on the accuracy of the predic-tion of future traffic patterns. Fig. 5(a) presents the energysavings of TOP with different prediction accuracies (0.9 and0.7), and with a 8% difference in energy savings. Even with

Fig. 4. Fraction of wasted energy with application traces.

Fig. 5. Impact on resource metrics for delay-tolerant requests with vary-ing delay deadlines. (a) E(S). (b) D(S). (c) F (S). (d) P(S).(e) A(S). (f) E(S) of different users.

high prediction accuracy (0.9), TOP exhibits a performancelevel lower than that of TailTheft (40%).

The curves in Fig. 5(b) and (c) show that the energydecrease is primarily due to the reduction in D(S) andF(S). Compared with the DCH time, the FACH timeis decreased more significantly by TailTheft. So radioresources shared among UEs can be more efficiently usedwith TailTheft. As shown in Fig. 5(d), promotions inTailTheft increase due to frequent timeout operation oftimer at short di. When at long di, promotions in TailTheftsignificantly decrease. Fig. 5(e) shows how interactive timechanges with varying di. At the di of 500s, the A(S)of TailTheft increases only 1.9s compared with that ofTailEnder, but is 59s shorter than the indicated di (500s).Furthermore, the increase of A(S) mainly results from thedelay action, which is specified by the end-user or appli-cations. When the di is greater than 500s, the A(S) ofTailTheft increases linearly, whereas the E(S) of TailTheftimproves only a little. The two main reasons are: (1) thedelay-tolerant requests are scheduled in accordance withthe delay deadlines by TailTheft (Section 4.4.1), and (2) onlythe delay-tolerant requests are scheduled in this evaluationexperiment. Because the delay-tolerant requests are submit-ted by invoking the TailTheft API with a parameter r_delay,TailTheft does know whether there are enough requests forbatching in the future. To obtain more energy savings, thedelay-tolerant requests are set to be delayed for r_delaytime units, and they are scheduled in the tail time beforetheir deadlines or scheduled immediately regardless of theRRC state as their deadlines approach. Fig. 5(f) shows the


Fig. 6. Impact on resource metrics for prefetchable requests with vary-ing prefetch accuracies. (a) E(S). (b) D(S). (c) F (S). (d) P(S).(e) A(S). (f) E(S) of different topics.

average per day energy improvement using TailTheft overdefault, for different users at the di of 500s. We can obtainan energy reduction of 80% on average for all 10 users.

6.3 Impact on Prefetchable RequestsWe use the news trace to evaluate TailTheft performancewith prefetchable requests. For each prefetchable request,if the corresponding previous attempts fail, the requestmust be retransmitted. If the previous attempts succeed, theprefetchable request no longer requires transmission. Thus,we assume that the interactive time of these successfullyprefetched requests is 0.

Fig. 6 plots the impact on metrics for prefetchablenews requests with varying prefetch accuracies (0.05 to 1).For retransmitting unsuccessfully prefetched requests,TailEnder generates negative energy savings at low prefetchaccuracy. As shown in Fig. 6(a), TailEnder increases energyconsumption by 31%. Conversely, TailTheft performs batch-ing and prefetching in the tail time. Even at low prefetchaccuracy, TailTheft achieves energy savings of 25%, asevaluated against the default schedule. At high prefetchaccuracy (0.9), TailTheft generates 56% more energy savingsthan TailEnder and 34% more than TOP (p = 0.9).

Fig. 6(b) and (c) show the impact on D(S) and F(S),the latter of which exhibits significant reduction. For trans-mitting unsuccessfully prefetched requests, the D(S) ofTailTheft is slightly larger than that of TOP at low prefetchaccuracy. When prefetch accuracy is low, the number of pro-motions (P(S)) is considerably higher in TailTheft thanin TOP (Fig. 6(d)) because (1) the strategy of invoking

fast dormancy when no TailTheft request is in the queuemay result in more promotions, and (2) failed prefetchablerequests, which should be immediately transferred as theyarrive, may cause state promotions. As shown in Fig. 6(e),the interactive time of TailTheft and TailEnder is reducedgradually with increasing prefetch accuracy mainly becausethe interactive time of successfully prefetched requests is 0.The result also indicates that traffic aggregation methods(i.e., TailTheft and TailEnder) can benefit from prefetching.Given that failed prefetchable requests are treated as real-time, interactive time stems mainly from state promotionsat high prefetch accuracy. Fig. 6(f) shows the improve-ments in energy consumption using TailTheft for each ofthe news topics at a prefetch accuracy of 0.9. The averageimprovement across all topics is 65%.

6.4 Impact on Mixed RequestsRegardless of whether delay-tolerant and prefetchablerequests are processed, TailTheft can achieve a good bal-ance between resource and user latency. However, delay-tolerant and prefetchable requests are always mixed withreal-time ones. Thus, performance with mixed requests isalso evaluated. To the best of our knowledge, no studyhas analyzed the proportion of real-time requests. Falakiet al. [31], [32] provide a rough classification of traffic col-lected from smartphones but do not indicate delay-tolerantand prefetchable characteristics. Let rar denote the propor-tion of real-time requests. According to Falaki et al. andthe characteristics of different applications, we estimaterar = 0.5.

To generate mixed requests, we select 3 users (User 4, 7,9) from the e-mail trace in accordance with the number ofmails and three news topics (TOP news, China and World)from the news trace. By mixing these requests, we obtain9 groups of mixed requests. In each group, rar proportionof requests is set as real-time. Thus, we can get 9 groupsof mixed requests consisting of delay-tolerant, prefetchableand real-time requests.

Fig. 7(a) shows the impact on resource metrics for mixedrequests with estimated ratios (rar = 0.5). TailTheft achievesconsiderable energy savings on battery energy (65%) anddedicated radio resources (56%). Processing overhead inthe RNC is also reduced (12%). Moreover, the E(S) ofTailTheft is reduced by 18% compared with TOP (p = 0.9)and by 62% compared with TailEnder. Other resource met-rics of TailTheft are also less than those of TailEnder andTOP. The average interactive times of TailEnder, TailTheft,and TOP (p = 0.7 and 0.9) are 40.8, 32.1, 1.20, and 1.20,respectively. The A(S) of TailTheft is smaller than that ofTailEnder, but greater than that of TOP. This duration stemsprimarily from delay-tolerant requests, which is specifiedby the end-user or applications. From an end-user perspec-tive, these delays do not affect latency. We can confirm thispoint from observing A(S) of real-time requests. The A(S) ofreal-time requests of TailEnder, TailTheft and TOP (p = 0.7and 0.9) are 1.17, 1.197, 1.22, and 1.21, respectively.

To explore the influence of the proportion ratio of real-time requests on energy savings, we conduct two otherexperiments, in which the proportion ratios of real-timerequests are rar = 0.2 and rar = 0.8. The results aredepicted in Fig. 7(b) and (c). TailTheft can save much more


Fig. 7. Impact on resource metrics for mixed requests with different ratios of real-time requests. (a) rar = 0.5. (b) rar = 0.2. (c) rar = 0.8.

energy than TailEnder and TOP. From the three figuresin Fig. 7, we can see that TailTheft achieves similar per-formance improvement in energy consumption (60% to62%) compared with TailEnder. Whereas, compared withTOP, the performance obtained by TailTheft decreases withincreasing rar. The performance gains are 18%, 25%, and11% (Fig. 7(a), (b), and (c), respectively). The reason isthat the energy saved by TailTheft primarily comes frombatching and prefetching in the tail time. Batching andprefetching fewer requests reduces the data aggregatedby TailTheft as well as the tail time utilized and energysaved owing to traffic aggregation. To guarantee TailTheftperformance under these conditions, we set a time T3 inTailTheft (Section 4.3.2). When now is the tail time, butno data can be batched and prefetched, TailTheft waits forT3 time units before triggering demotion. Energy savingin TailTheft depends on batching and prefetching in thetail time. Thus, if no data can be batched and prefetched,TailTheft is unlikely to provide more energy savings thanTOP.

To examine TailTheft performance as affected by T3, wetest TailTheft performance with varying lengths of T3 (from0.1s to 5.0s). Fig. 8 plots the impact on energy consumptionand the average interactive time of real-time requests withvarying lengths of T3. As already observed, TailTheft per-formance decreases with increasing rar. The energy savedby TailTheft also decreases with increasing T3 because theenergy wasted in the tail time increases. At minimal T3,TailTheft saves more energy, but the number of promo-tions increases and thus increases the average interactivetime of real-time requests (Fig. 8). The fixed length of T3obtained by analyzing user traffic patterns can get relatively

Fig. 8. Impact on energy and the average interactive time of real-timerequests with varying lengths of T3. (a) E(S). (b) A(S) of real-timerequests.

good performance without affecting user latency, that is,without increasing the average interactive time of real-timerequests.

6.5 Effect of Tail DurationsGiven that the tail durations that we measure differ fromthat in [25], UEs from various operators may have differ-ent tail durations. To explore the effect of tail durations,we conduct two experiments with the same request traceas that used in Section 6.4 (Fig. 7(a)), but with differentconfigurations of tail durations: (1) the durations that wemeasure, where T1 = 2s and T2 = 4.5s; and (2) the durationsfrom [25], where T1 = 6s and T2 = 4s.

Fig. 9 shows the evaluation results with varying taildurations. Compared with the results in Fig. 7(a), the per-formances of all approaches decrease under different taildurations. One of the primary reasons is that energy wastedin the tail time decreases with short tail durations (It shouldbe noted that the tail durations are not as short as possi-ble. As shown in Fig. 4, short tail durations cause morepromotions, thus worsening user experience [27]). Underdifferent tail configurations, TailTheft obtains much betterperformance than TailEnder. Compared with TOP (p = 0.9),TailTheft achieves similar performance improvement. Theperformance gains are 14.5%, 15%, and 18% (Figs. 7(a), 9(a),and (b), respectively).

7 RELATED WORKExisting approaches for mitigating the tail time effect incellular networks can be classified into two categories.

Traffic aggregation. Traffic in a number of UE appli-cations can be deferred or prefetched. Based on this

Fig. 9. Impact on resource metrics with different tail durations. (a) T1 =2s and T2 = 4.5s. (b) T1 = 6s and T2 = 4s.


feature, TailEnder [23] performs batching and prefetch-ing for e-mail and web search, respectively, whereasCool-Tether [17] performs aggregation for browsing. Thelow accuracy of the prediction of future transmissionsmay cause unnecessary energy consumption, which is thegreatest disadvantage of these two approaches. AlthoughTailTheft is also based on aggregatable applications, it con-ducts batching and prefetching in the tail time. Even ina worst-case scenario, TailTheft does not increase energyconsumption.

Tail Time Tuning. A number of previous studies onoptimizing inactivity timers are based on tail time tuning.It is suggested that a tail time of 10 seconds to 15 sec-onds is a reasonable range for controlling the probabilityof state promotion to below 5% [18]. Researchers [21], [20]propose analytical models for investigating the effect of dif-ferent timer values on energy consumption in UEs. It isshown that setting the tail time to 4.5 seconds significantlyreduces energy consumption [31]. Although these studiesidentify a reasonable tail duration for saving energy, thetail time still exists and causes substantial energy wastage.TOP [25], RadioJockey [29] and Traffic-aware approach [30]are three recently proposed methods to tune the tail time.TOP and RadioJockey utilize a feature called fast dor-mancy [11] to terminate the tail time dynamically if theypredict that no data requires further transmission. Thedifference between TOP and RadioJockey lies in their pre-diction methods: TOP provides applications with an APIto actively invoke fast dormancy, whereas RadioJockey usesprogram execution traces to predict the end of communica-tion spurts to similarly invoke fast dormancy. Traffic-awareapproach dynamically brings the radio to a connected oridle state by learning traffic patterns and predicting thestart and end of traffic spurts, and it also invokes fast dor-mancy to bring the radio to an idle state. However, theefficiency of dynamic tuning of these methods dependson the accuracy of the prediction of future traffic pat-terns. Low prediction accuracy not only retains untunedtail time that still wastes energy, but also causes additionalstate promotions, thereby wasting more energy. In addition,both Traffic-aware approach and RadioJockey are designedonly for background traffic and thus cannot reduce energywasted in the tail time generated by user interactive appli-cations. Furthermore, tail time tuning methods consumelots of energy in transmitting lengthy and sparse trafficbecause the radio resource state machine is forced to remainin a high-power state for a long time. By batching andprefetching in the tail time, TailTheft utilizes the unusedtail time of both background and interactive applications.Moreover, batching and prefetching in the tail time canreduce the total transmission time, thereby saving moreenergy.

In addition to mitigating the tail time effect, savingradio energy in UEs has also been considered. Given thatcellular radios consume more energy when signals areweak, researchers [37] develop an energy-aware cellulardata scheduling system. In [38], the authors determineenergy-delay trade-offs in smartphone applications and [34]discuss user activity patterns for saving energy. Othermobile energy saving technologies, such as WiFi [39], [40]and GPS [41], have also been studied.

8 CONCLUSION AND FUTURE WORKInactivity timers in cellular networks are used to balancethe trade-offs between resource efficiency for enhanced userexperience and low management overhead. However, con-siderable radio resources and battery energy are wasted inthe tail time. In this paper, we proposed TailTheft, whichleverages the tail time for batching and prefetching. Ourwork is the first to consider using rather than eliminat-ing the tail time for saving energy. To utilize the tail time,TailTheft uses a virtual tail time mechanism to determinethe amount of tail time that can be used and a dual queuescheduling algorithm to schedule transmissions. Given thatnumerous transmissions are scheduled in the tail time,energy consumption is significantly decreased. TailTheftcan benefit a number of common applications, includingdelay-tolerant applications (e.g., e-mail, RSS feeds, and soft-ware updates), and prefetchable applications (e.g., news,social networking, browsing, media and maps). We havesimulated TailTheft in NS-2 and evaluated its performanceunder various conditions. The experimental results showthat TailTheft achieves more significant savings on batteryenergy and radio resources than existing methods.

Some of the issues that we would like to explore in thefuture are as follows.

Other types of cellular networks. The tail time, pro-motion delays, and associated trade-offs also exist in othertypes of cellular networks (i.e., GPRS/EDGE [6], EvDO [14]and 4G LTE [13]). The associated trade-offs in these cellu-lar networks are not the same as in the UMTS network butinvolve state machines similar to the one used by the UMTSnetwork. TailTheft is also applicable to the above types ofcellular networks. The additional work necessary is to setappropriate timers to enable TailTheft to adapt to differ-ent state machines and use the tail time for batching andprefetching.

Incomplete transmission. Transmission in TailTheft maynot be completed by the end of the tail time. In simula-tions, we can easily inform a server that transmission isinterrupted through a slight modification, but such changesare infeasible in actual systems. One practical solution isto transmit short requests, which can be completed withinthe tail time. In enhancing TailTheft, the possible direc-tions we are considering include exploring a dynamic timerscheme to fit transmission duration and breaking downlarge transmissions into small ones.

Dynamic timer schemes. Dynamic timer schemes canbe used to enhance TailTheft and can be achieved byadjusting timers in the UE according to the observed traf-fic patterns. In this paper, we set a fixed value of T3(Section 4.3.2). Dynamically changing time T3 can poten-tially balance the trade-off better. Furthermore, dynamicallychanging timers and (corresponding to times T1 andT2, respectively), can also better adapt to the tail transferto solve the incomplete transmission problem. The chal-lenges of dynamic time schemes include identifying traf-fic patterns of concurrently running multiple applicationsand computing appropriate timer values under differentapplications.

Implementing TailTheft. TailTheft is suitable for imple-mentation in mobile operating systems, exposing a simple


API defined in Section 4.2. Applications only need toprovide a parameter (delay or prefetch limit) for eachrequest. In TailTheft, fast dormancy is an interface lever-aged to release radio resources actively in the UE, but tothe best of our knowledge, no smartphone provides a pro-gramming interface for invoking fast dormancy in or out ofits operating system (e.g., Android and iOS). Furthermore,different versions of fast dormancy also increase the dif-ficulty of implementation. For the most recent version offast dormancy (Release 8 [10]), TailTheft requires the con-figuration support of operators to prevent the restriction ofcalling fast dormancy. To obtain support, more additionalwork and verification are necessary to convince operators.Bridging the gap between fast dormancy and mobile oper-ating systems as well as implementing TailTheft in themobile operating system (e.g., Android) is our ongoingwork.

ACKNOWLEDGMENTSThe authors would like to thank the anonymous reviewersfor their constructive comments which helped improve thequality of the manuscript significantly. The work is partiallysupported by the National Natural Science Foundation ofChina (Grant 60903029).

REFERENCES[1] The World in 2011: ICT Facts and Figures [Online]. Available:

http://www.itu.int/ITU-D/ict/facts/2011/index.html[2] Nokia Energy Profiler [Online]. Available: http://store.ovi.com.cn/

content/73969[3] The Network Simulator [Online]. Available: http://www.isi.edu/

nsnam/ns[4] Enhanced UMTS Radio Access Network Extensions for NS-2 [Online].

Available: http://eurane.ti-wmc.nl/eurane[5] TailTheft [Online]. Available: https://github.com/dizhang/

tailtheft[6] GERAN RRC State-Machine, 3GPP TSG GERAN Adhoc #2 GAHW-

(00)0027, 2000.[7] Radio Resource Control (RRC); Protocol Specification (Release 8), 3GPP

TS 25.331 V8.0.0, 2007.[8] System Impact of Poor Proprietary Fast Dormancy, TSG-RAN meet-

ing #45 RP-090941, 2009.[9] Technical Specifications and Technical Reports for a UTRAN-based

3GPP system (Release 7), 3GPP TS 21.101 V7.0.0, 2007.[10] Technical Specifications and Technical Reports for a UTRAN-Based

3GPP System (Release 8), 3GPP TS 21.101 V8.0.0, 2009.[11] Interlayer Procedures in Connected Mode (Release 8), 3GPP TS 25.303

V8.0.0, 2007.[12] H. Holma and A. Toskala, HSDPA/HSUPA for UMTS: High

Speed Radio Access for Mobile Communications, Chichester, U.K.:Wiley, 2000.

[13] S. Sesia, I. Toufik, and M. Baker, LTE, The UMTS Long TermEvolution: From Theory to Practice, Chichester, U.K.: Wiley, 2009.

[14] M. Chatterjee and S. K. Das, Optimal MAC state switching forCDMA2000 networks, in Proc. IEEE INFOCOM, New York, NY,USA, Nov. 2002, pp. 400406.

[15] H. Liu, Y. Zhang, and Y. Zhou, TailTheft: Leverageing the wastedtime for saving energy in cellular communications, in Proc. ACMMobiArch, Bethesda, MD, USA, Jun. 2011, pp. 3136.

[16] A. Carroll and G. Heiser, An analysis of power consumption ina smartphone, in Proc. USENIX ATC, Berkeley, CA, USA, Jun.2010, pp. 114.

[17] A. Sharma, V. Navda, R. Ramjee, V. N. Padmanabhan, andE. M. Belding, Cool-tether: Energy efficient on-the-fly WiFi hot-spots using mobile phones, in Proc. ACM CoNEXT, Rome, Italy,Dec. 2009, pp. 109120.

[18] M. Chuan, W. Luo, and X. Zhang, Impacts of inactivity timervalues on UMTS system capacity, in Proc. IEEE WCNC, Orlando,FL, USA, Apr. 2002, pp. 897903.

[19] P. H. J. Perala, A. Barbuzzi, G. Boggia, and K. Pentikousis,Theory and practice of RRC state transitions in UMTS net-works, in Proc. IEEE GlobeCom Workshops, Honolulu, HI, USA,Nov. 2009, pp. 16.

[20] C.-C. Lee, J.-H. Yeh, and J.-C. Chen, Impact of inactivity timeron energy consumption in WCDMA and CDMA2000, in Proc.Wireless Telecommunications Symp., Pomona, CA, USA, May 2004,pp. 1521.

[21] J.-H. Yeh, J.-H. Chen, and C.-C. Lee, Comparative analysis ofenergy-saving techniques in 3GPP and 3GPP2 systems, IEEETrans. Veh. Technol., vol. 58, no. 1, pp. 432448, Jan. 2009.

[22] R. Lempel and S. Moran, Optimizing result prefetching in websearch engines with segmented indices, in Proc. Int. Conf. VLDB,Hong Kong, China, Aug. 2002, pp. 370381.

[23] N. Balasubramanian, A. Balasubramanian, and A. Venkataramani,Energy consmption in mobile phones: A measurement study andimplications for network applications, in Proc. IMC, Chicago, IL,USA, Nov. 2009, pp. 280293.

[24] A. Balasubramanian, R. Mahajan, and A. Venkataramani,Augmenting mobile 3G using WiFi, in Proc. Int. Conf. MobiSys,San Francisco, CA, USA, Jun. 2010, pp. 209222.

[25] F. Qian et al., TOP: Tail optimization protocol for cellular radioresource allocation, in Proc. IEEE ICNP, Kyoto, Japan, Oct. 2010,pp. 285294.

[26] F. Qian et al., Characterizing radio resource allocation for 3Gnetworks, in Proc. IMC, Melbourne, VIC, Australia, Nov. 2010,pp. 137150.

[27] F. Qian et al., Profiling resource usage for mobile applications: Across-layer approach, in Proc. Int. Conf. MobiSys, Bethesda, MD,USA, Jun./Jul. 2011, pp. 321334.

[28] A. Gerber et al., Intelligent mobility application profiling tool,U.S. Patent Application 2012/0151041, June 14, 2012.

[29] P. K. Athivarapu et al., RadioJockey: Mining program executionto optimize cellular radio usage, in Proc. Int. Conf. MobiCom,Istanbul, Turkey, Aug. 2012, pp. 101112.

[30] S. Deng and H. Balakrishnan, Traffic-aware techniques to reduce3G/LTE wireless energy consumption, in Proc. ACM CoNEXT,Nice, France, Dec. 2012, pp. 181192.

[31] H. Falaki, D. Lymberopoulos, and R. Mahajan, A first look attraffic on smartphones, in Proc. IMC, Melbourne, VIC, Australia,Nov. 2010, pp. 281287.

[32] H. Falaki et al., Diversity in smartphone usage, in Proc. Int. Conf.MobiSys, San Francisco, CA, USA, Jun. 2011, pp. 179194.

[33] B. D. Higgins et al., Informed mobile prefetching, in Proc. Int.Conf. MobiSys, Low Wood Bay, U.K., Jun. 2012, pp. 155168.

[34] A. Shye, B. Scholbrock, and G. Memik, Into the wild:Studying real user activity patterns to guide power optimiza-tions for mobile architectures, in Proc. IEEE/ACM Int. Symp.Microarchitecture, New York, NY, USA, Dec. 2009, pp. 168178.

[35] B. Al-Manthari, N. Nasser, and H. Hassanein, Downlinkscheduling with economic considerations for future wireless net-works, IEEE Trans. Veh. Technol., vol. 58, no. 2, pp. 824835,Feb. 2009.

[36] F. Ren and C. Lin, Modeling and improving TCP performanceover cellular link with variable bandwidth, IEEE Trans. MobileComput., vol. 10, no. 8, pp. 10571070, Aug. 2011.

[37] A. Schulman et al., Bartendr: A practical approach to energy-aware cellular data scheduling, in Proc. Int. Conf. MobiCom,Chicago, IL, USA, Sept. 2010, pp. 8596.

[38] M.-R. Ra et al., Energy-delay tradeoffs in smartphone applica-tions, in Proc. Int. Conf. MobiSys, San Francisco, CA, USA, Jun.2010, pp. 255269.

[39] J. Manweiler and R. R. Choudhury, Avoiding the rush hours:WiFi energy management via traffic isolation, in Proc. Int. Conf.MobiSys, Bethesda, MD, USA, Jun./Jul. 2011, pp. 253266.

[40] X. Zhang and K. G. Shin, E-MiLi: Energy-minimizing idle listen-ing in wireless networks, in Proc. Intl Conf. MobiCom, Las Vegas,NV, USA, Sept. 2011, pp. 205216.

[41] J. Paek, K.-H. Kim, J. P. Singh, and R. Govindan, Energy-efficientpositioning for smartphones using Cell-ID sequence matching,in Proc. Int. Conf. MobiSys, Bethesda, MD, USA, Jun./Jul. 2011,pp. 293306.


Di Zhang received the B.S. degree in softwareengineering from Harbin Institute of Technology,China, in 2010. Currently, he is with the Ph.D.degree in the Department of Computer Scienceand Technology, Tsinghua University, China. Hiscurrent research interests include energy-savingtechnologies with mobile phones, mobile com-puting, and cloud computing.

Yaoxue Zhang received the B.S. degreefrom Northwest Institute of TelecommunicationEngineering, China, and received the Ph.D.degree in computer networking from TohokuUniversity, Japan, in 1989. Currently, he is a fel-low of the Chinese Academy of Engineering anda professor in computer science and technol-ogy at Tsinghua University, China. His currentresearch interests include computer networking,operating systems, ubiquitous/pervasive com-puting, transparent computing, and active ser-

vices. He has published over 200 technical papers in internationaljournals and conferences, as well as 9 monographs and textbooks.

Yuezhi Zhou received the Ph.D. degree in com-puter science and technology from TsinghuaUniversity, China, in 2004 and is now anAssociate Professor in the same Department. Hewas a visiting scientist at the Computer ScienceDepartment in Carnegie Mellon University in2005. His current research interests includeubiquitous/pervasive computing, distributed sys-tem, mobile device and systems. He has pub-lished over 60 technical papers in internationaljournals or conferences. He received the IEEE

Best Paper Award in the 21st IEEE AINA International Conference in2007. He is a member of the IEEE and ACM.

Hao Liu received the B.S. degree in softwareengineering from Beihang University, China,in 2009. He is currently a Ph.D. Candidateat the Department of Computer Science andTechnology, Tsinghua University, China. His cur-rent research interests include high-speed trans-port protocols, energy saving in smartphones,and data mining in location-based services.

For more information on this or any other computing topic,please visit our Digital Library at www.computer.org/publications/dlib.

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 200 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages false /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 400 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description >>> setdistillerparams> setpagedevice

leveraging the tail time for saving energy in

Documents

release of radio resources

wastage of radio resources

mobile computing

tail timeto

radio resourcesare

virtual tail time mechanism

battery energy inues

large proportion of