Anda di halaman 1dari 14

1536

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

Leveraging the Tail Time for Saving Energy in


Cellular 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 period
of inactivity timers, known as the tail time, a large proportion of energy in user devices and a considerable amount of radio resources
are wasted. In this paper, we propose TailTheft, a scheme that leverages the tail time for batching and prefetching to reduce energy
consumption. For network requests from a number of applications that can be deferred or prefetched, TailTheft provides a customized
application programming interface to distinguish requests and then schedules delay-tolerant and prefetchable requests in the tail time
to save energy. TailTheft employs a virtual tail time mechanism to determine the amount of tail time that can be used and a dual
queue scheduling algorithm to schedule transmissions. We implement TailTheft in the Network Simulator with a model for calculating
energy 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 radio
resources (up to 56%), compared to the default policy.
Index TermsCellular network, energy saving, inactivity timer, tail time

I NTRODUCTION

ITH almost 6 billion mobile subscribers worldwide [1], mobile phones have become ubiquitous
devices. The increasing popularity of iOS- and Androidbased applications has made mobile phones with richer features an indelible part of modern popular culture. However,
the limited battery life of mobile phones constrains the
emergence of more attractive and complex applications.
In cellular networks, radio resources shared among user
equipments (UEs, e.g., smartphones) are known to be the
major power consumer in mobile phones [16], [32], [34].
However, a large proportion (nearly 60%) of energy consumed by radio resources is derived from the timeout
period of inactivity timers [23]. These timers are used to
control the release of radio resources [7]. The idle interval corresponding to the inactivity timer timeout period
before radio resources are released is referred to as the
tail time, and it is adopted to balance the trade-offs among
radio resources, user experience, energy consumption, and
network overhead [26]. However, the tail time results in
the wastage of radio resources and battery energy in
UEs [23], [25].
We focus on the Universal Mobile Telecommunications
System (UMTS) network, one of the most popular 3G
mobile communication technologies. To use limited radio
resources efficiently [12], the UMTS introduces the Radio

The authors are with the Department of Computer Science and


Technology, Tsinghua University, Beijing, China, 100084.
E-mail: {dizhang.thu, liuhao.buaa}@gmail.com; zyx@moe.edu.cn;
zhouyz@mail.tsinghua.edu.cn.
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:
reprints@ieee.org, and reference the Digital Object Identifier below.
Digital Object Identifier 10.1109/TMC.2013.126

Resource Control (RRC) protocol [7], which maintains a


state machine for each UE [26]. Each state in which the UE
operates corresponds to different radio resource allocation
and energy consumption level. Before data are transmitted,
the state is promoted to a high-power state. However, frequent
state promotions may result in long delays for the UE and
high management overhead for the UMTS network. After
each transmission is completed, the state is not immediately demoted to a low-power state. The state machine waits
for a certain duration (the tail time, reaches up to 15 seconds [25]), which results in the wastage of radio resources
in the UMTS network and battery energy in UEs [23], [25].
A number of studies have been conducted to mitigate
the above described tail time effect, which can be divided
into two categories: traffic aggregation and tail time tuning.
Traffic aggregation approaches, such as TailEnder [23] and
Cool-Tether [17], schedule transmissions based on traffic
patterns. Small transmissions are aggregated into large ones
so that the tails and energy consumption are reduced. For
delay-tolerant applications (e.g., e-mail and RSS feeds) and
prefetchable applications (e.g., news and social networking), data transmissions can be deferred or prefetched to
achieve aggregation. However, low accuracy in predicting
future transmissions may cause an increase in energy consumption during aggregation. For example, when only a
small amount of the prefetched data are needed by applications, aggregation eliminates only a small number of
future tails but imposes high energy consumption for the
prefetching itself [33].
Tail time tuning, the other type of approaches, tunes
the tail time in an effort to balance the energy wasted in
the tail time and the drawbacks incurred by state promotions. When the tail time is aggressively reduced to 0.5
seconds, the state promotion delay is increased by about
300% [25]. Thus, some researchers argue that saving energy

c 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
1536-1233 
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

necessitates the identification of a reasonable tail duration


[18], [21], [20], [31]. However, even if a reasonable tail
duration is found, the tail time still exists and causes considerable 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 dormancy [11] to terminate the tail
dynamically if they predict that no further data needs to be
transmitted. Traffic-aware approach dynamically brings the
radio to a connected or idle state by learning traffic patterns
and predicting the start and end of traffic spurts, and it also
invokes fast dormancy to bring the radio to an idle state.
However, the efficiency of dynamic tuning of these methods depends on the accuracy of the prediction of future
traffic patterns. Low prediction accuracy not only retains
untuned tail time that still wastes energy, but also causes
additional state promotions, thereby wasting more energy.
In addition, both RadioJockey and Traffic-aware approach
are designed only for background traffic and thus cannot
reduce energy wasted in the tail time generated by user
interactive applications.
To better mitigate the tail time effect, we propose
TailTheft [15], a scheme that leverages the tail time for
batching and prefetching to save energy. Our main contributions can be summarized as follows:
First, to the best of our knowledge, our work is the
first to consider using the tail time, rather than eliminating
the inevitable tail time specified by cellular specifications.
TailTheft steals the tail time for two use cases: (1) transferring delay-tolerant requests (e.g., e-mail and RSS feeds)
in batches, and (2) prefetching data that are likely to be
requested in the future (e.g., news and social networking).
By scheduling a number of requests in the tail time, energy
consumption is significantly reduced in TailTheft because
unused tail time is utilized and the total transmission time is
reduced. Although prefetching is also performed in TailTheft,
energy consumption is not increased, even with low prefetch
accuracy, because of the use of unoccupied tail time.
Second, to utilize the tail time with minimized impact
on existing systems, a virtual tail time mechanism and
a dual queue scheduling algorithm are proposed. The virtual tail time mechanism maintains virtual tail timers that
correspond to physical tail timers after a transmission is
completed. These virtual timers determine the time during
which TailTheft can perform batching and prefetching. The
mechanism also terminates tail transmission at the end of
the virtual tail time. The dual queue scheduling algorithm
differentiates between real-time requests and those that can
be batched or prefetched, after which it schedules the latter in the virtual tail time and ensures that the real-time
requests are not affected.
Third, the tail time problem is analyzed in the Network
Simulator (NS-2). Based on the simulative implementation in NS-2 [5], we evaluate TailTheft performance using
real application traces. The experimental results show that
TailTheft can achieve significant savings on battery energy
(up to 65%) and dedicated radio resources (up to 56%).
Our scheme also outperforms recently proposed tail optimization approaches for both traffic aggregation (up to
62%) and tail time tuning (up to 18%) in terms of energy
consumption.

1537

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

The remainder of this paper is organized as follows.


Section 2 describes the background of our study. Section 3
formulates the problem, defines trade-offs, and explains
the applied energy consumption model. Section 4 presents
the design of TailTheft. Section 5 briefly describes the
simulative implementation of TailTheft in NS-2. Section 6
presents the performance evaluation results. Section 7
reviews related studies. Section 8 concludes the paper and
gives directions for future research.

BACKGROUND

The Radio Network Controller (RNC) is an important component of the UMTS network. Most features of the UMTS
Terrestrial Radio Access Network such as radio resource
management, packet scheduling, and some mobility management functions are implemented in the RNC. Radio
resources shared among UEs are potential bottlenecks in
the network. To use the limited resource efficiently, the
RRC 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 allocated to the UE in both downlink and uplink, thus enabling
the UE to use radio resources fully for the high-speed
transmission of user data. Given that communication via
DCH is bidirectional, both the transmitter and receiver of
the UE should be active, thereby resulting in high power
consumption in this state.
CELL_FACH. In the CELL_FACH (Forward Access
Channel, FACH hereafter) state, no dedicated physical
channel is allocated to the UE. Instead, the UE uses the
shared channels FACH (downlink) and Random Access
Channel (uplink) to transmit control messages and a small
amount of user data at very low speeds. Given that
FACH uses shared channels, this state consumes less radio
resources and battery energy.
IDLE1 . In this state, no RRC connection is established,
and no radio resource is allocated. The UE cannot transfer
user data.
Promotion and demotion are the two types of state
transitions. As illustrated in Fig. 1(a) and (b), the UE consumes more (less) radio resources and power after promotion (demotion). Promotion, which includes IDLEDCH,
1. A hibernation state called CELL_PCH is found in some UMTS
networks. It is similar to IDLE, but the state promotion delay is shorter.

1538

FACHDCH, and IDLEFACH2 , is triggered by the


Buffer Occupancy (BO) level (downlink and uplink buffers
are separated) in the Radio Link Control (RLC) layer [19].
When the state machine is in the IDLE state and the BO
level is greater than 0, IDLEDCH promotion occurs.
When in the FACH state and when the BO level of either
direction exceeds the configured threshold, FACHDCH
promotion occurs. In contrast to promotion, demotion
comprises DCHFACH, FACHIDLE, and DCHIDLE.
Demotion is triggered by network throughput and inactivity timers and , which are managed by the RNC [26].
In the DCH state, the timer is reset whenever considerable traffic is generated (because low traffic volume does
not trigger timer being reset). When the throughput is 0 or
less than the configured threshold for the RNC configured
time (T1 ), the timer stops, and the state is demoted to
the 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 IDLE
state.
Ramp energy and tail energy. Promotion time Pt1 pertains to the delays of IDLEDCH (shown in Fig. 1(b),
up to 2 seconds [26]), during which numerous control
messages are exchanged between the UE and RNC for
resource allocation. Promotion time Pt2 refers to the delays
of FACHDCH. A large amount of Pt1 and Pt2 not only
increase the RNC overhead, but also result in long delays to
the end-user and consume a considerable amount of energy
in the UE (nearly 14% of transmission energy [23], where
transmission energy refers to the total energy consumed during data transmission). We refer to this energy as ramp
energy. The tail time denotes the idle interval that corresponds to the interval between the start and reset or start
and expiry of inactivity timers. During the tail time, the
UE has no data to transfer and only waits for the inactivity
timer to stop, although it still uses radio resources. Radio
power consumption remains at a level that corresponds to
that of the transport channel. We refer to this energy as tail
energy, which is nearly 60% of transmission energy [23].
The tail time is necessary for mitigating the delays and
overhead of state promotion in case further transmission
occurs.
Fast Dormancy. The fundamental purpose of employing inactivity timers is that the network has insufficient 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 determine
the end of network usage period because the UE can
use application knowledge to predict network activities. Fast dormancy, which is included in 3GPP releases
7 [9] and 8 [10], is a new feature based on this natural way. Instead of waiting for inactivity timers to
stop, the UE can send a special RRC control message
(Signaling Connection Release Indication [11]) to the RNC
for state demotion to the IDLE (or CELL_PCH) state.
However, the drawbacks of poorly used fast dormancy
include more promotions and potentially long delays to the
end-user [8].
2. IDLEFACH exists in some UMTS networks.

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

P RELIMINARY F ORMULATION

3.1 Differentiating Applications


Common network applications in UEs include instant
messaging, e-mail, news, social networking (e.g., Facebook,
twitter), browsing, media (e.g., videos, radio streaming), maps, RSS feeds and system (e.g., software
updates) [31], [32]. According to data accessing characteristics, these applications can be classified under three
categories: (1) applications that can tolerate delays, (2)
applications that can benefit from prefetching, and (3)
real-time applications, the data of which are neither delaytolerant nor prefetchable. E-mail, RSS feeds and system are
applications that can tolerate a small user- or applicationspecified delay [24]. For example, a user may be willing
to wait for a short time before e-mail is sent or received
if it can save substantial energy. News, social networking,
browsing, media and maps are applications that can benefit
from aggressive prefetching [23].
The data accessing requests of the three aforementioned
categories of applications can be formulated as undivided
requests, where each request i has two attributes: an arrival
time ai and a deadline di . The corresponding three categories of requests are as follows: (1) real-time requests, which
require instantaneous scheduling after arrival and satisfy
ai = di , (2) delay-tolerant requests, which can be scheduled
at a delayed period with di ai after arrival at ai and satisfy ai < di , (3) prefetchable requests, which can benefit from
prefetching and satisfy ai = di . Prefetchable requests can be
handled in accordance with real-time requests, or add one
or more previous attempts before the corresponding prefetchable request arrives [22]. Let PRi = {pr1 , ...} denote these
previous attempts, where the size of PRi is greater than 0.
Suppose prj PRi , the arrival time of prj is aj and satisfy dj = ai (Note that previous attempts would not be
attempted). If the data obtained by previous attempt prj
is exactly the desired data indicated by the prefetchable
request i, this request no longer requires scheduling. If the
attempts fail, request i should be scheduled. Delay-tolerant
requests and previous attempts can be delayed, but the
difference between them is that the latter would be discarded as the deadline approaches because of the risk of
prefetching failure.
3.2 Scheduling Requests to Minimize Energy
The ultimate goal of TailTheft is to schedule data accessing
requests so that the total energy consumption is minimized, while all requests are transmitted within their constraints. The problem can be modeled as follows. Consider a
sequence of n requests, which comprise the four previously
defined categories of requests. Let S = {s1 , . . . , sn } denote a
schedule that transmits request i at time si . The schedule S
is feasible if all requests are transmitted within their constraints, which are defined in Section 3.1. For each request i,
(1) if i is real-time, it should be transmitted instantaneously
after its arrival ai , (2) if i is delay-tolerant, it should be transmitted after its arrival ai and before its deadline di , (3) if
i is prefetchable, it should be transmitted instantaneously
after its arrival for an unsuccessfully prefetched request but
should be discarded for a successfully prefetched request,
and (4) if i is previous attempt, it should be transmitted after

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

its arrival ai and before its deadline di , but should be discarded as its deadline approaches. When i is transmitted at
time si , the RRC state machine generally transits to a highpower state (it may also transit to an intermediate-power
state) and transmits i instantaneously. After transmission
is completed and no additional transmission occurs, the
state machine remains in the high-power state for T1 time
units before transiting to a intermediate-power state. If
no transmission occurs, the state machine remains in the
intermediate-power state for T2 time units before transiting to the lower-power state, where T1 and T2 are
the tail time. Even when multiple requests are simultaneously transmitted, state transition remains the same
with only one request. Let E(S) denote the total energy
consumption of the schedule S. The request scheduling
problem is to compute a feasible request schedule S that
minimizes 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 transitions and longer tail time. If numerous requests need to be
scheduled, substantial energy is consumed by the tail time
and state promotions, and is also drained by sparse transmission. Additionally, given that the request queue is not
known a priori in practice, the schedule has to be computed
online. TailTheft follows the principle that delay-tolerant
requests and previous attempts are delayed and transmitted in the tail time within their deadlines. This action not
only uses the tail time, but also reduces transmission time
and numerous promotions.

3.3 Trade-offs Between Resource and User Latency


An ideal situation is one wherein requests can always be
responded to in real-time. However, limitations in UE battery capacity, radio resources, and the RNC processing
capacity make this ideal state difficult to achieve in practice. The request scheduling problem introduces trade-offs
between resource and user latency. Given a request queue
R and a schedule S, we calculate two categories of metrics to characterize these trade-offs. Some previous studies
focus on only one factor [20], [21]. Although recent studies [26], [25] have provided three types of metrics, these
metrics are not the trade-offs that we consider in the current study and are not sufficiently precise (See Section 3.4).
The two categories of metrics that we define are described
as 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 state
transitions, transmissions, and the tail time. E(S) not
only reflects the resource consumption of the UE, but
also affects radio resource utilization and the RNC
overhead.
Duration in the DCH state, denoted by D(S), quantifies the dedicated radio resources consumed by the
UE on dedicated channels.
Duration in the FACH state is denoted by F(S). F(S)
quantifies the radio resources consumed by the UE
on shared channels, which should be considered.

1539

Fig. 2. Power curve of a transmission process.

The number of promotions of IDLEDCH and


FACHDCH, denoted by P(S), quantifies the overhead incurred by state transitions that increase the
resources used in the RNC. The overhead of state
demotions is disregarded, because it is significantly
smaller than that of state promotions.
User latency can be quantified by one metric.

The average interactive time, denoted by A(S), is


the interval between request submission and return,
which can consequently reflect the speed of responding to user requests. The A(S) of real-time requests
should not be affected by the schedule.
We focus on the relative changes in resource metrics
when the schedule is switched with the same request
queue. Let S denote the default schedule used as a comparison baseline. Let S denote a new request schedule. The
relative changes in E(S), denoted as E(S), are computed
by 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 notation is that for any transmission schedule, an increase in
A(S) causes resource metrics to decrease. In other words,
if the end-user can tolerate a certain delay, numerous
resources are saved. We aim to identify a schedule S that
can significantly decrease resource metrics while slightly
increasing A(S).

3.4 Applied Energy Consumption Model


In this section, we introduce an energy model applied
by TailTheft for calculating energy consumption E(S).
Although some energy models have already been presented, we only consider energy models that are used by
existing tail optimization approaches because the energy
consumption model is not the primary focus of this paper.
The model given by TailEnder [23] does not determine the
energy consumption affected by transmission rate (which
refers to the amount of data transferred per second) in the
FACH state and does not measure FACHDCH promotion energy, which cannot be disregarded. TOP [25], [26]
provides the power consumed during state transitions
but does not determine the energy consumption affected
by transmission rate. To construct an accurate energy
model, we conduct a series of measurements on a Nokia
N81 device using Energy Profiler [2] to obtain a set of
energy consumption data. Based on the data set, we analyze the energy consumption of different states and state
transitions.
Fig. 2 illustrates the power curve of a measured transmission process, where a transmission process refers to the
change in power state from low to high and then back to
low. Let Ei denote the energy consumed by a transmission

1540

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

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 average power and duration of IDLEDCH. Let Wi2d and Pt1
denote the average power and duration of IDLEDCH,
respectively, then E1p = Wi2d Pt1 .
(2) The energy consumed in the DCH state is denoted by
E1s (part (2) in Fig. 2). Power in the DCH state is influenced
by both the transmission rate and duration of the DCH
state [23]. Let function Dw (vt , t) denote the power in the
DCH state, where vt is the transmission rate at time t. Then,
 t2
E1s = 1D Dw (vt , t)dt, where t1D is the start time, and t2D is
tD

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 average power and duration of FACHDCH. Let Wf 2d and Pt2
denote the average power and duration of FACHDCH,
respectively, then E2p = Wf 2d Pt2 .
(4) The energy consumed in the FACH state is denoted
by E2s (part (4) in Fig. 2). Power in the FACH state is influenced by both the transmission rate and duration of the
FACH state. Let function Fw (vt , t) denote the power in the
FACH state, where vt is the transmission rate at time t. Then
 t2
E2s = 1F Fw (vt , t)dt, where t1F is the start time, and t2F is the
tF

end time of the FACH state.


For a certain UE in a specified UMTS network, E1p and E2p
are constants, denoted by C1 and C2 , respectively. Suppose
Np FACHDCH promotions occur (Np 0, not all transmission processes have only one FACHDCH promotion),
then the energy consumed by a transmission process is
computed 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, we


conduct two measurement experiments. In the first experiment, we build a web server with configurable bandwidth,
and energy consumption is measured when the phone
downloads a 5 MB file from the web server under different bandwidth configurations. In another experiment, a
message receiver is started on the phone. We then send
messages to the phone from another device and keep the
state machine in the FACH state while energy consumption is measured. After these two experiments, we obtain
the functions Dw (vt , t) and Fw (vt , t). Linear polynomials are
used to fit the measured energy consumption data, and the
fit results are shown in Fig. 3. The other parameters of the
energy model are obtained through the analysis of a days
energy consumption data.
Table 1 lists the parameters derived from the measurements. Compared with previous measurements
[25], [23], [31], the tail time in our result is shorter by
half because of the differences in the configurations of
various operators. Moreover, the variances among mobile
phones and the applications running on the mobile phones
generate a power difference.

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

TAILT HEFT D ESIGN

4.1 TailTheft Overview


We develop TailTheft, a protocol with the end goal of
scheduling data requests to minimize UE energy consumption. Tail energy and ramp energy are introduced to account
for the majority of energy waste. In addition, a lengthy
and sparse transmission forces the RRC state machine to
remain in a high-power state for a long time, which also
results in large energy consumption. To minimize energy
consumption, TailTheft utilizes the tail time for batching and
prefetching, which not only utilizes the unused tail time but
also reduces the total transmission time, thereby reducing
energy consumption. The challenges that we face are: (1)
how to distinguish different categories of requests, (2) how
to realize aggregating transfers in the tail time and process all requests under the constraints of various kinds of
requests, and (3) how to reduce the impact on existing systems (especially on the cellular network) when transmitting
data in the tail time. TailTheft employs a set of techniques
to address these challenges.
First, TailTheft provides a customized application programming interface (API) for applications. Applications
indicate the type of request, the time that can be delayed
or prefetched by calling the TailTheft API, as well as the
type of action taken as the deadline approaches.
Second, a mechanism called virtual tail time is proposed
to determine the time during which batching and prefetching can be conducted. When the tail time is used for
data transmission, inactivity timers and are reset. To
complete the state transitions originally triggered by timers
and , TailTheft introduces two timers, and , to
replace the functions of and in the UE as well as to
determine the time that can be used for batching and prefetching. In addition, TailTheft uses fast dormancy to trigger
DCHIDLE or FACHIDLE demotion.
Third, to schedule all requests under their constraints, a
dual queue scheduling algorithm is proposed. Two queues are
TABLE 1
Measured Energy Model Parameters

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

maintained for data requests: one for real-time and unsuccessfully prefetched prefetchable requests and another for
delay-tolerant requests and previous attempts. We refer to
delay-tolerant requests and previous attempts as TailTheft
requests. When a request is added to the TailTheft request
queue, TailTheft starts a timer , the timeout value of which
is the latest deadline of all the requests in the queue. Timer
ensures that all delayed requests are processed before the
specified deadline.

4.2 The Interface for Distinguishing Requests


Applications can define the delays for a delay-tolerant
request according to their needs. Applications can also
add previous attempts for a prefetchable request based
on their prefetching strategy and can determine which
request is successfully prefetched and re-submit unsuccessfully prefetched requests. Unlike applications, TailTheft
is unaware of the manner by which applications define
their requests. To distinguish different requests defined by
applications, TailTheft provides a customized API for such
applications. An application informs TailTheft how to process a request via a simple API SubmitRequest(r_delay). If
r_delay is 0, the request may be a real-time or an unsuccessfully prefetched request (successfully prefetched request
would not be submitted) that should be transmitted instantaneously. If r_delay is a positive value, the request is
delay-tolerant and can thus be delayed for r_delay time
units. If r_delay is a negative value, the request is a previous attempt that likewise can be delayed for -r_delay
time units. However, the difference between delay-tolerant
request and previous attempt is that the latter would be
discarded as the deadline approaches. TailTheft schedules
requests as indicated by the parameter r_delay.
4.3 Virtual Tail Time
4.3.1 Determining Whether the Tail Time can be Used
Achieving batching and prefetching in the tail time
requires identification of the time during which these
tasks can be performed. The types of demotion, namely,
DCHFACHIDLE or DCHIDLE, can be accurately
determined [26], [27]. The former demotion type has two
tail times (T1 and T2 ), and the latter has only one tail time
(T1 ). The mechanism of the two tail times can be directly
applied to one tail time. Thus, we consider only the former. We separate the two tail times primarily because the
scheduling rates in these two periods are distinct.
Two mechanisms are employed for online determination
of whether now is the tail time. Power-based state inference
mechanism is used to infer the current RRC state based
on power consumption. Determining the current RRC state
is the foundation of distinguishing between the two kinds
of tail time. However, no API or known work on directly
accessing RRC state information in smartphone systems is
available [27]. Radio resources are the major power consumer in UEs [34], thereby making power consumption a
convenient factor for inferring the RRC state. Moreover, a
power-based state inference mechanism has been proven
effective with high accuracy [27]. Given that it can exhibit
high accuracy (more than 95%), the error estimate of this
mechanism is disregarded. Virtual tail time that is used to

1541

TABLE 2
Parameters Set in TailTheft Implementation

determine whether now is the tail time, which corresponds


to the original inactivity timers maintained by the RNC.
After transmitting data in the tail time, the inactivity timers
are reset, such that the physical tail time is broken. We
refer to the used tail time as the virtual tail time. A timer is
required to determine whether now is the virtual tail time
in the current RRC state. We refer to this timer as the virtual tail timer, which performs operations that are similar
to those performed by the inactivity timer maintained by
the RNC. Two timers correspond to the virtual tail times of
the 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 configured threshold (Table 2). (1) If timer is activated when the
throughput is 0, TailTheft can start transmitting data after
the timer is activated and stop when the timer expires
or is reset. (2) If timer is activated when the throughput 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 transmission of real-time data may be ongoing when the timer
expires, and demotion at this time would trigger additional
state promotions. Thus, having no transmission at the second condition would not reset the inactivity timer , and
the state is demoted to the FACH state after the expiry of
timer . When in the FACH state, the virtual tail timer
would be activated only when the throughput is 0. TailTheft
can start transmitting data after timer is activated and stop
when the timer expires or is reset.

4.3.2 Terminating Tail Transmission


As previously discussed, transmitting data in the tail time
resets the inactivity timer maintained by the RNC, causing
the RNC to forgo demotion at the end of the virtual tail
time. Thus, how to trigger demotion by the expiry of the
virtual tail timer is another important issue. In Section 2,
we introduced fast dormancy, based on which the UE
can actively request for state demotion to the IDLE state.
TailTheft invokes fast dormancy that triggers DCHIDLE
or FACHIDLE demotion when the virtual tail timer
stops. However, direct demotions to IDLE or CELL_PCH
may prevent complete data transmission in the RLC buffer,
causing additional state promotions. Before invoking fast
dormancy, TailTheft delays until the RLC buffer is empty.
To ensure this condition, the delay is set to the longest
consumption time of the RLC buffer (Table 2), which can

1542

be inferred by transmitting two packets with a delay in


between [28].
Another problem is that although now is the virtual
tail time, no data is available for batching and prefetching.
Direct demotions may result in more promotions. TailTheft
uses the concept of short tail time discussed in [31], in
which the burst characteristics of user traffic are exploited.
Let T3 denote the time within which most of the previous
packets (more than 95%) are transmitted. TailTheft triggers
demotion directly after T3 time units since the virtual timer
has been started. We can obtain the value of T3 by analyzing traffic patterns or set a fixed value according to the
statistical data of the end-user. We set a fixed value of T3
in this paper (Table 2).

4.4 Dual Queue Scheduling Algorithm


Scheduling requests feasibly, as defined in Section 3.2,
is another problem to be discussed in this section.
Applications submit network requests by calling the API
defined in Section 4.2. According to the parameter r_delay,
requests can be divided into two categories: requests
that 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 or
negative). Requests that can be delayed, referred to as
TailTheft requests, include delay-tolerant requests and previous attempts. TailTheft employs a dual queue scheduling
algorithm for scheduling these two categories of requests.
TailTheft schedules requests by maintaining two queues:
(1) the real-time queue for requests that must be scheduled
instantaneously, and (2) the TailTheft queue for TailTheft
requests. TailTheft schedules requests in the real-time queue
if requests are present in this queue and schedules those
in the TailTheft queue if the real-time queue is empty or
if the deadline of the first request in the TailTheft queue
approaches.
4.4.1 Handling TailTheft Requests
As shown in the preliminary formulation in Section 3.2,
TailTheft is feasible if and only if it not only transmits
requests in the real-time queue as soon as they are inserted,
but also processes requests in the TailTheft queue before
their deadlines. Specifically, delay-tolerant requests should
be scheduled before their deadlines, and previous attempts
should be scheduled before their deadlines or discarded
as their deadlines approach. To meet the deadlines indicated by requests, the dual queue scheduling algorithm
introduces a new timer . After being delivered by applications, TailTheft requests are added to the queue from small
to large, according to the time between tnow and di , where
tnow is the current time, and di equals to the sum of the
arrival time ai and the absolute value of r_delay of request
i. The first request in the TailTheft queue is assigned with
the latest deadline and is the first to be transmitted. After
each enqueue operation, TailTheft derives the latest deadline, denoted as dl , and restarts the timer , the end time
of which is dl tnow . When now is the virtual tail time, the
first request in the queue is dequeued first. Timer is canceled before the first request is dequeued and reactivated
according to the deadline of the next request in the queue
after dequeuing.

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

Algorithm 1 TailTheft API


1:  dl : the latest deadline of request in Qt
2: procedure S UBMIT R EQUEST(r_delay)
3:
i the submitted request
4:
ai current time tnow
5:
if r_delay = 0 then
6:
Qr .enqueue(i)
7:
else
8:
dl Qt .enqueue(i)
9:
.restart(dl ai )
10:
end if
11: end procedure

However, if the first request in the TailTheft queue


has not been transmitted when the timer stops, the
request should be directly dequeued. TailTheft processes
this request according to the value of r_delay. If r_delay is
positive, the request is delay-tolerant and should be scheduled immediately, regardless of the current RRC state. If
r_delay is negative, the request is a previous attempt and
should be discarded. Similarly, the timer should be reactivated according to the deadline of the next request in the
queue after dequeuing.

4.4.2 Controlling Transmission Rate


In the virtual tail time of the FACH state, excessively high
transmission speed expands the occupancy of the RLC
buffer to a level greater than the threshold set by the RNC.
This expansion results in FACHDCH promotion, thereby
causing additional energy consumption. To prevent triggering promotions when transmitting requests in the FACH
state, TailTheft transmits data according to the size and
consumption time of the RLC buffer (Table 2) [28], and
ensures that the buffer occupancy level does not exceed
the threshold. Let bot denote the buffer occupancy in the
current time and BO denote the buffer occupancy threshold set by the RNC. Request scheduling of TailTheft in
the virtual tail time of the FACH state should satisfy
bot < BO.
The dual queue scheduling algorithm is presented in
Algorithm 2. Let Qr and Qt denote the real-time and
TailTheft queues, respectively. Applications invoke the
TailTheft API shown in Algorithm 1 to submit requests. The
main procedure of Algorithm 2 shows how TailTheft schedules requests queued in the real-time and TailTheft queues.
The procedure TimeOut_Theta shows the timeout operations
of the timer and the procedure TimeOut_GammaAndDelta
shows the timeout operations of the timers and .

S IMULATIVE I MPLEMENTATION

We implement TailTheft via simulation in NS-2 [3] based


on EURANE [4], and the source code can be found in
Github [5]. EURANE is an implementation of the UMTS
network in NS-2, which is extensively used in simulation
studies on the UMTS network [35], [36]. EURANE has
added most of the UMTS protocol stack to NS-2. However,
the implemented protocol stack does not include the IDLE
state and the tail time. Therefore, the following works
should be done: (1) adding the IDLE state, (2) implementing the tail time, and (3) consummating state transitions. We

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

TABLE 3
E-mail Trace

Algorithm 2 Dual Queue Scheduling algorithm


1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:

 dl : the latest deadline of request in Qt


 tnow : the current time
 vc : the throughput of current time
procedure M AIN
loop
s Infer the RRC state with power
if Qr .length() > 0 then
i Qr .dequeue()
Schedule i
else if Qt .length() > 0 then
if or is started then
.cancel()
i, dl Qt .dequeue()
.start(dl tnow )
if s is DCH && vc = 0 then
Schedule i
else if s is FACH then
Schedule i satisfy bot < BO
end if
end if
else
Terminate the virtual tail based on T3
end if
end loop
end procedure

26: procedure T IME O UT _ THETA


27:
i, dl Qt .dequeue()
28:
if r_delay > 0 then
29:
Schedule i
30:
else if r_delay < 0 then
31:
Discard i
32:
end if
33:
.start(dl tnow )
34: end procedure
35: procedure T IME O UT _G AMMA A ND D ELTA
36:
Delay until the RLC buffer is empty
37:
Invoke fast dormancy
38: end procedure

complete these works based on the parameters measured


from actual phones.
Table 2 lists some of the important parameters established to implement TailTheft. For a more comprehensive
comparison with previous studies, the values of T1 and T2
are established in accordance with measurements in [23]
and [25], as well as the size and consumption time of the
RLC buffer (x is packet size in byte) [25], [27]. The rest of
the parameters are from our measurements.
After implementing an unbroken RRC state machine, we
implement TailTheft according to the design in Section 4.
The works include: (1) modifying the channel switching
mechanism to add virtual tail timers in the UE, (2) modifying the multiplexer in the UE to implement the dual queue
scheduling algorithm, (3) implementing transmission in the
tail time, and (4) implementing fast dormancy. When performing these works, the most difficult task is ensuring that
correct transition occurs between different states because of
the increased complexity of state transition. To guarantee
the reliability of the simulation results, the state transition
and transmitted data are verified.

1543

E VALUATION

We evaluate TailTheft performance against that of two existing representative schemes, TailEnder [23] and TOP [25],
where TailEnder is a traffic aggregation scheme and TOP
is a tail time tuning scheme. TailEnder and TOP are also
implemented in NS-2, but for simplicity, TOP is implemented with a prediction accuracy of upcoming non-tail
equal to 100% and a prediction accuracy of upcoming tail
equal to p. These prediction accuracies result in better performance of TOP in this paper compared with that of
previous study [25].
Two kinds of requests, delay-tolerant and prefetchable,
are used to evaluate TailTheft, because a number of requests
can be deferred or prefetched, and these requests are the
key targets of TailTheft. According to the analysis of Falaki
et al. [31], [32], we select requests of two common applications, e-mail and news, for evaluation. E-mail is an
application that can tolerate a moderate delay. News is an
application that can benefit from prefetching. In addition,
delay-tolerant and prefetchable requests are always mixed
with real-time ones. Therefore, the performance with mixed
requests is also evaluated.
We use E(S), D(S), F(S), P(S) and A(S) (defined
in Section 3.3) as evaluation metrics. These metrics are calculated using the energy consumption models proposed in
Section 3.4 and the parameters established in Section 5. The
comparison baseline is the default transmission schedule
with unoptimized tail time.

6.1 Application Trace Collection


To collect e-mail trace, we monitored mailboxes of 10 graduate students for 10 days (from May 20 to 29, 2013) and
recorded the time stamps and size of incoming and outgoing mails. For e-mail attachments is not automatically
received over cellular networks by mobile e-mail clients
(e.g., Gmail), so the recorded size of e-mail does not include
the size of attachments. Table 3 tabulates the statistics of email trace. To collect news trace, we polled Sohu3 news of
9 major topics every 5 seconds for a span of 10 days (from
May 28 to June 7, 2013). We recorded the arrival time and
size of each news story. Table 4 lists the topics and total
number of news of different topics.
Fig. 4 shows the proportion of wasted energy determined using the collected application traces. We can see
that the proportion of total tail energy attributed to e-mail
3. http://m.sohu.com, a famous news site in China.

1544

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

TABLE 4
News Trace

is approximately 72%, whereas that attributed to news is


approximately 62%. Compared with news, requests of email 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 difference
among 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 mixture 2 and 3 are T1 = 2s, T2 = 4.5s and T1 = 6s, T2 = 4s,
respectively. Comparing different mixtures, we can identify
that short tail durations waste less energy, but cause more
promotions.

6.2 Impact on Delay-Tolerant Requests


To evaluate the effectiveness of batching in TailTheft, we
compare TailTheft performance with that of TailEnder and
TOP using the e-mail trace. For a clearer comparison, TOP
is implemented with two prediction accuracy values (p =
0.7 and 0.9). The incoming and outgoing e-mail requests
are set with a varying delay deadline di (from 1 second to
2000 seconds).
Fig. 5 plots the impact on metrics for delay-tolerant
e-mail requests. When the di is short (1 to 50s), the energy
savings of TailTheft increase quickly, because prolonging
the di decreases the number of timeout operations of timer
rapidly, which reduces the DCH time and the number
of state promotions observably. With the increase of di
(greater than 50s), the increase of batched requests gradually decreases, so the energy savings of TailTheft gradually
approach its maximum value. TailTheft achieves its maximum energy savings with the di of 500s, whereas TailEnder
needs more than 2000s (Fig. 5(a)). At the di of 500s, TailTheft
exhibits 48% more energy savings than TailEnder. TOP does
not defer transmission, thus, its performance does not vary
with di but heavily depends on the accuracy of the prediction of future traffic patterns. Fig. 5(a) presents the energy
savings of TOP with different prediction accuracies (0.9 and
0.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 varying 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 performance


level lower than that of TailTheft (40%).
The curves in Fig. 5(b) and (c) show that the energy
decrease is primarily due to the reduction in D(S) and
F(S). Compared with the DCH time, the FACH time
is decreased more significantly by TailTheft. So radio
resources shared among UEs can be more efficiently used
with TailTheft. As shown in Fig. 5(d), promotions in
TailTheft increase due to frequent timeout operation of
timer at short di . When at long di , promotions in TailTheft
significantly decrease. Fig. 5(e) shows how interactive time
changes with varying di . At the di of 500s, the A(S)
of TailTheft increases only 1.9s compared with that of
TailEnder, but is 59s shorter than the indicated di (500s).
Furthermore, the increase of A(S) mainly results from the
delay action, which is specified by the end-user or applications. When the di is greater than 500s, the A(S) of
TailTheft increases linearly, whereas the E(S) of TailTheft
improves only a little. The two main reasons are: (1) the
delay-tolerant requests are scheduled in accordance with
the delay deadlines by TailTheft (Section 4.4.1), and (2) only
the delay-tolerant requests are scheduled in this evaluation
experiment. Because the delay-tolerant requests are submitted by invoking the TailTheft API with a parameter r_delay,
TailTheft does know whether there are enough requests for
batching in the future. To obtain more energy savings, the
delay-tolerant requests are set to be delayed for r_delay
time units, and they are scheduled in the tail time before
their deadlines or scheduled immediately regardless of the
RRC state as their deadlines approach. Fig. 5(f) shows the

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

1545

fast dormancy when no TailTheft request is in the queue


may result in more promotions, and (2) failed prefetchable
requests, which should be immediately transferred as they
arrive, may cause state promotions. As shown in Fig. 6(e),
the interactive time of TailTheft and TailEnder is reduced
gradually with increasing prefetch accuracy mainly because
the 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 realtime, interactive time stems mainly from state promotions
at high prefetch accuracy. Fig. 6(f) shows the improvements in energy consumption using TailTheft for each of
the news topics at a prefetch accuracy of 0.9. The average
improvement across all topics is 65%.

Fig. 6. Impact on resource metrics for prefetchable requests with varying 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 over


default, for different users at the di of 500s. We can obtain
an energy reduction of 80% on average for all 10 users.

6.3 Impact on Prefetchable Requests


We use the news trace to evaluate TailTheft performance
with prefetchable requests. For each prefetchable request,
if the corresponding previous attempts fail, the request
must be retransmitted. If the previous attempts succeed, the
prefetchable request no longer requires transmission. Thus,
we assume that the interactive time of these successfully
prefetched requests is 0.
Fig. 6 plots the impact on metrics for prefetchable
news requests with varying prefetch accuracies (0.05 to 1).
For retransmitting unsuccessfully prefetched requests,
TailEnder generates negative energy savings at low prefetch
accuracy. As shown in Fig. 6(a), TailEnder increases energy
consumption by 31%. Conversely, TailTheft performs batching and prefetching in the tail time. Even at low prefetch
accuracy, TailTheft achieves energy savings of 25%, as
evaluated against the default schedule. At high prefetch
accuracy (0.9), TailTheft generates 56% more energy savings
than 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 transmitting unsuccessfully prefetched requests, the D(S) of
TailTheft is slightly larger than that of TOP at low prefetch
accuracy. When prefetch accuracy is low, the number of promotions (P(S)) is considerably higher in TailTheft than
in TOP (Fig. 6(d)) because (1) the strategy of invoking

6.4 Impact on Mixed Requests


Regardless of whether delay-tolerant and prefetchable
requests are processed, TailTheft can achieve a good balance between resource and user latency. However, delaytolerant and prefetchable requests are always mixed with
real-time ones. Thus, performance with mixed requests is
also evaluated. To the best of our knowledge, no study
has analyzed the proportion of real-time requests. Falaki
et al. [31], [32] provide a rough classification of traffic collected from smartphones but do not indicate delay-tolerant
and prefetchable characteristics. Let rar denote the proportion of real-time requests. According to Falaki et al. and
the characteristics of different applications, we estimate
rar = 0.5.
To generate mixed requests, we select 3 users (User 4, 7,
9) from the e-mail trace in accordance with the number of
mails and three news topics (TOP news, China and World)
from the news trace. By mixing these requests, we obtain
9 groups of mixed requests. In each group, rar proportion
of requests is set as real-time. Thus, we can get 9 groups
of mixed requests consisting of delay-tolerant, prefetchable
and real-time requests.
Fig. 7(a) shows the impact on resource metrics for mixed
requests with estimated ratios (rar = 0.5). TailTheft achieves
considerable energy savings on battery energy (65%) and
dedicated radio resources (56%). Processing overhead in
the RNC is also reduced (12%). Moreover, the E(S) of
TailTheft is reduced by 18% compared with TOP (p = 0.9)
and by 62% compared with TailEnder. Other resource metrics of TailTheft are also less than those of TailEnder and
TOP. 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 of
TailEnder, but greater than that of TOP. This duration stems
primarily from delay-tolerant requests, which is specified
by the end-user or applications. From an end-user perspective, these delays do not affect latency. We can confirm this
point from observing A(S) of real-time requests. The A(S) of
real-time requests of TailEnder, TailTheft and TOP (p = 0.7
and 0.9) are 1.17, 1.197, 1.22, and 1.21, respectively.
To explore the influence of the proportion ratio of realtime requests on energy savings, we conduct two other
experiments, in which the proportion ratios of real-time
requests are rar = 0.2 and rar = 0.8. The results are
depicted in Fig. 7(b) and (c). TailTheft can save much more

1546

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

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 figures


in Fig. 7, we can see that TailTheft achieves similar performance improvement in energy consumption (60% to
62%) compared with TailEnder. Whereas, compared with
TOP, the performance obtained by TailTheft decreases with
increasing rar . The performance gains are 18%, 25%, and
11% (Fig. 7(a), (b), and (c), respectively). The reason is
that the energy saved by TailTheft primarily comes from
batching and prefetching in the tail time. Batching and
prefetching fewer requests reduces the data aggregated
by TailTheft as well as the tail time utilized and energy
saved owing to traffic aggregation. To guarantee TailTheft
performance under these conditions, we set a time T3 in
TailTheft (Section 4.3.2). When now is the tail time, but
no data can be batched and prefetched, TailTheft waits for
T3 time units before triggering demotion. Energy saving
in TailTheft depends on batching and prefetching in the
tail time. Thus, if no data can be batched and prefetched,
TailTheft is unlikely to provide more energy savings than
TOP.
To examine TailTheft performance as affected by T3 , we
test TailTheft performance with varying lengths of T3 (from
0.1s to 5.0s). Fig. 8 plots the impact on energy consumption
and the average interactive time of real-time requests with
varying lengths of T3 . As already observed, TailTheft performance decreases with increasing rar . The energy saved
by TailTheft also decreases with increasing T3 because the
energy wasted in the tail time increases. At minimal T3 ,
TailTheft saves more energy, but the number of promotions increases and thus increases the average interactive
time of real-time requests (Fig. 8). The fixed length of T3
obtained by analyzing user traffic patterns can get relatively

Fig. 8. Impact on energy and the average interactive time of real-time


requests with varying lengths of T3 . (a) E(S). (b) A(S) of real-time
requests.

good performance without affecting user latency, that is,


without increasing the average interactive time of real-time
requests.

6.5 Effect of Tail Durations


Given that the tail durations that we measure differ from
that in [25], UEs from various operators may have different tail durations. To explore the effect of tail durations,
we conduct two experiments with the same request trace
as that used in Section 6.4 (Fig. 7(a)), but with different
configurations of tail durations: (1) the durations that we
measure, where T1 = 2s and T2 = 4.5s; and (2) the durations
from [25], where T1 = 6s and T2 = 4s.
Fig. 9 shows the evaluation results with varying tail
durations. Compared with the results in Fig. 7(a), the performances of all approaches decrease under different tail
durations. One of the primary reasons is that energy wasted
in the tail time decreases with short tail durations (It should
be noted that the tail durations are not as short as possible. As shown in Fig. 4, short tail durations cause more
promotions, thus worsening user experience [27]). Under
different tail configurations, TailTheft obtains much better
performance than TailEnder. Compared with TOP (p = 0.9),
TailTheft achieves similar performance improvement. The
performance gains are 14.5%, 15%, and 18% (Figs. 7(a), 9(a),
and (b), respectively).

R ELATED W ORK

Existing approaches for mitigating the tail time effect in


cellular networks can be classified into two categories.
Traffic aggregation. Traffic in a number of UE applications 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.

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

feature, TailEnder [23] performs batching and prefetching for e-mail and web search, respectively, whereas
Cool-Tether [17] performs aggregation for browsing. The
low accuracy of the prediction of future transmissions
may cause unnecessary energy consumption, which is the
greatest disadvantage of these two approaches. Although
TailTheft is also based on aggregatable applications, it conducts batching and prefetching in the tail time. Even in
a worst-case scenario, TailTheft does not increase energy
consumption.
Tail Time Tuning. A number of previous studies on
optimizing inactivity timers are based on tail time tuning.
It is suggested that a tail time of 10 seconds to 15 seconds is a reasonable range for controlling the probability
of state promotion to below 5% [18]. Researchers [21], [20]
propose analytical models for investigating the effect of different timer values on energy consumption in UEs. It is
shown that setting the tail time to 4.5 seconds significantly
reduces energy consumption [31]. Although these studies
identify a reasonable tail duration for saving energy, the
tail 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 dormancy [11] to terminate the tail time dynamically if they
predict that no data requires further transmission. The
difference between TOP and RadioJockey lies in their prediction methods: TOP provides applications with an API
to actively invoke fast dormancy, whereas RadioJockey uses
program execution traces to predict the end of communication spurts to similarly invoke fast dormancy. Traffic-aware
approach dynamically brings the radio to a connected or
idle state by learning traffic patterns and predicting the
start and end of traffic spurts, and it also invokes fast dormancy to bring the radio to an idle state. However, the
efficiency of dynamic tuning of these methods depends
on the accuracy of the prediction of future traffic patterns. Low prediction accuracy not only retains untuned
tail time that still wastes energy, but also causes additional
state promotions, thereby wasting more energy. In addition,
both Traffic-aware approach and RadioJockey are designed
only for background traffic and thus cannot reduce energy
wasted in the tail time generated by user interactive applications. Furthermore, tail time tuning methods consume
lots of energy in transmitting lengthy and sparse traffic
because the radio resource state machine is forced to remain
in a high-power state for a long time. By batching and
prefetching in the tail time, TailTheft utilizes the unused
tail time of both background and interactive applications.
Moreover, batching and prefetching in the tail time can
reduce the total transmission time, thereby saving more
energy.
In addition to mitigating the tail time effect, saving
radio energy in UEs has also been considered. Given that
cellular radios consume more energy when signals are
weak, researchers [37] develop an energy-aware cellular
data scheduling system. In [38], the authors determine
energy-delay trade-offs in smartphone applications and [34]
discuss user activity patterns for saving energy. Other
mobile energy saving technologies, such as WiFi [39], [40]
and GPS [41], have also been studied.

1547

C ONCLUSION AND F UTURE W ORK

Inactivity timers in cellular networks are used to balance


the trade-offs between resource efficiency for enhanced user
experience and low management overhead. However, considerable radio resources and battery energy are wasted in
the tail time. In this paper, we proposed TailTheft, which
leverages the tail time for batching and prefetching. Our
work is the first to consider using rather than eliminating the tail time for saving energy. To utilize the tail time,
TailTheft uses a virtual tail time mechanism to determine
the amount of tail time that can be used and a dual queue
scheduling algorithm to schedule transmissions. Given that
numerous transmissions are scheduled in the tail time,
energy consumption is significantly decreased. TailTheft
can benefit a number of common applications, including
delay-tolerant applications (e.g., e-mail, RSS feeds, and software updates), and prefetchable applications (e.g., news,
social networking, browsing, media and maps). We have
simulated TailTheft in NS-2 and evaluated its performance
under various conditions. The experimental results show
that TailTheft achieves more significant savings on battery
energy and radio resources than existing methods.
Some of the issues that we would like to explore in the
future are as follows.
Other types of cellular networks. The tail time, promotion delays, and associated trade-offs also exist in other
types of cellular networks (i.e., GPRS/EDGE [6], EvDO [14]
and 4G LTE [13]). The associated trade-offs in these cellular networks are not the same as in the UMTS network but
involve state machines similar to the one used by the UMTS
network. TailTheft is also applicable to the above types of
cellular networks. The additional work necessary is to set
appropriate timers to enable TailTheft to adapt to different state machines and use the tail time for batching and
prefetching.
Incomplete transmission. Transmission in TailTheft may
not be completed by the end of the tail time. In simulations, we can easily inform a server that transmission is
interrupted through a slight modification, but such changes
are infeasible in actual systems. One practical solution is
to transmit short requests, which can be completed within
the tail time. In enhancing TailTheft, the possible directions we are considering include exploring a dynamic timer
scheme to fit transmission duration and breaking down
large transmissions into small ones.
Dynamic timer schemes. Dynamic timer schemes can
be used to enhance TailTheft and can be achieved by
adjusting timers in the UE according to the observed traffic patterns. In this paper, we set a fixed value of T3
(Section 4.3.2). Dynamically changing time T3 can potentially balance the trade-off better. Furthermore, dynamically
changing timers and (corresponding to times T1 and
T2 , respectively), can also better adapt to the tail transfer
to solve the incomplete transmission problem. The challenges of dynamic time schemes include identifying traffic patterns of concurrently running multiple applications
and computing appropriate timer values under different
applications.
Implementing TailTheft. TailTheft is suitable for implementation in mobile operating systems, exposing a simple

1548

API defined in Section 4.2. Applications only need to


provide a parameter (delay or prefetch limit) for each
request. In TailTheft, fast dormancy is an interface leveraged to release radio resources actively in the UE, but to
the best of our knowledge, no smartphone provides a programming interface for invoking fast dormancy in or out of
its operating system (e.g., Android and iOS). Furthermore,
different versions of fast dormancy also increase the difficulty of implementation. For the most recent version of
fast dormancy (Release 8 [10]), TailTheft requires the configuration support of operators to prevent the restriction of
calling fast dormancy. To obtain support, more additional
work and verification are necessary to convince operators.
Bridging the gap between fast dormancy and mobile operating systems as well as implementing TailTheft in the
mobile operating system (e.g., Android) is our ongoing
work.

ACKNOWLEDGMENTS
The authors would like to thank the anonymous reviewers
for their constructive comments which helped improve the
quality of the manuscript significantly. The work is partially
supported by the National Natural Science Foundation of
China (Grant 60903029).

R EFERENCES
[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 meeting #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 Term
Evolution: From Theory to Practice, Chichester, U.K.: Wiley, 2009.
[14] M. Chatterjee and S. K. Das, Optimal MAC state switching for
CDMA2000 networks, in Proc. IEEE INFOCOM, New York, NY,
USA, Nov. 2002, pp. 400406.
[15] H. Liu, Y. Zhang, and Y. Zhou, TailTheft: Leverageing the wasted
time for saving energy in cellular communications, in Proc. ACM
MobiArch, Bethesda, MD, USA, Jun. 2011, pp. 3136.
[16] A. Carroll and G. Heiser, An analysis of power consumption in
a smartphone, in Proc. USENIX ATC, Berkeley, CA, USA, Jun.
2010, pp. 114.
[17] A. Sharma, V. Navda, R. Ramjee, V. N. Padmanabhan, and
E. M. Belding, Cool-tether: Energy efficient on-the-fly WiFi hotspots using mobile phones, in Proc. ACM CoNEXT, Rome, Italy,
Dec. 2009, pp. 109120.

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

[18] M. Chuan, W. Luo, and X. Zhang, Impacts of inactivity timer


values 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 networks, 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 timer
on 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 of
energy-saving techniques in 3GPP and 3GPP2 systems, IEEE
Trans. Veh. Technol., vol. 58, no. 1, pp. 432448, Jan. 2009.
[22] R. Lempel and S. Moran, Optimizing result prefetching in web
search 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 and
implications 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 radio
resource allocation, in Proc. IEEE ICNP, Kyoto, Japan, Oct. 2010,
pp. 285294.
[26] F. Qian et al., Characterizing radio resource allocation for 3G
networks, in Proc. IMC, Melbourne, VIC, Australia, Nov. 2010,
pp. 137150.
[27] F. Qian et al., Profiling resource usage for mobile applications: A
cross-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 execution
to 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 reduce
3G/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 at
traffic 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 optimizations 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, Downlink
scheduling with economic considerations for future wireless networks, IEEE Trans. Veh. Technol., vol. 58, no. 2, pp. 824835,
Feb. 2009.
[36] F. Ren and C. Lin, Modeling and improving TCP performance
over cellular link with variable bandwidth, IEEE Trans. Mobile
Comput., vol. 10, no. 8, pp. 10571070, Aug. 2011.
[37] A. Schulman et al., Bartendr: A practical approach to energyaware 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 applications, 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 listening 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-efficient
positioning for smartphones using Cell-ID sequence matching,
in Proc. Int. Conf. MobiSys, Bethesda, MD, USA, Jun./Jul. 2011,
pp. 293306.

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

Di Zhang received the B.S. degree in software


engineering from Harbin Institute of Technology,
China, in 2010. Currently, he is with the Ph.D.
degree in the Department of Computer Science
and Technology, Tsinghua University, China. His
current research interests include energy-saving
technologies with mobile phones, mobile computing, and cloud computing.

Yaoxue Zhang received the B.S. degree


from Northwest Institute of Telecommunication
Engineering, China, and received the Ph.D.
degree in computer networking from Tohoku
University, Japan, in 1989. Currently, he is a fellow of the Chinese Academy of Engineering and
a professor in computer science and technology at Tsinghua University, China. His current
research interests include computer networking,
operating systems, ubiquitous/pervasive computing, transparent computing, and active services. He has published over 200 technical papers in international
journals and conferences, as well as 9 monographs and textbooks.

1549

Yuezhi Zhou received the Ph.D. degree in computer science and technology from Tsinghua
University, China, in 2004 and is now an
Associate Professor in the same Department. He
was a visiting scientist at the Computer Science
Department in Carnegie Mellon University in
2005. His current research interests include
ubiquitous/pervasive computing, distributed system, mobile device and systems. He has published over 60 technical papers in international
journals or conferences. He received the IEEE
Best Paper Award in the 21st IEEE AINA International Conference in
2007. He is a member of the IEEE and ACM.

Hao Liu received the B.S. degree in software


engineering from Beihang University, China,
in 2009. He is currently a Ph.D. Candidate
at the Department of Computer Science and
Technology, Tsinghua University, China. His current research interests include high-speed transport 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.

Anda mungkin juga menyukai