Content uploaded by Haoyi Xiong
Author content
All content in this area was uploaded by Haoyi Xiong on Jun 20, 2014
Content may be subject to copyright.
effSense: Energy-Efficient and
Cost-Effective Data Uploading in
Mobile Crowdsensing
Leye Wang
CNRS SAMOVAR
Institut Mines-TELECOM /
TELECOM SudParis
France
leye.wang@telecom-sudparis.eu
Haoyi Xiong
CNRS SAMOVAR
Institut Mines-TELECOM /
TELECOM SudParis
France
haoyi.xiong@telecom-
sudparis.eu
Daqing Zhang
CNRS SAMOVAR
Institut Mines-TELECOM /
TELECOM SudParis
France
daqing.zhang@telecom-
sudparis.eu
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are not
made or distributed for profit or commercial advantage and that copies bear
this notice and the full citation on the first page. Copyrights for components
of this work owned by others than ACM must be honored. Abstracting with
credit is permitted. To copy otherwise, or republish, to post on servers or to
redistribute to lists, requires prior specific permission and/or a fee. Request
permissions from permissions@acm.org.
UbiComp’13 Adjunct, September 8–12, 2013, Zurich, Switzerland.
Copyright c
2013 ACM 978-1-4503-2215-7/13/09...$15.00.
http://dx.doi.org/10.1145/2494091.2499575
Abstract
Energy consumption and mobile data cost are two key
factors affecting users’ willingness to participate in
crowdsensing tasks. While data-plan users are mostly
concerned about the energy consumption, non-data-plan
users are more sensitive to data transmission cost
incurred. Traditional ways of data collection in mobile
crowdsensing often go to two extremes: either uploading
the sensed data online in real-time or fully offline after the
whole sensing task is finished. In this paper, we propose
effSense - a novel energy-efficient and cost-effective data
uploading framework leveraging the delay-tolerant
mechanisms. Specifically, effSense reduces the data cost
of non-data-plan users by maximally offloading the data
to Bluetooth/WiFi gateways or data-plan users
encountered to relay the data to the server; it reduces
energy consumption of data-plan users by uploading data
in parallel with a call or using less-energy demand
networks (e.g. Bluetooth). By leveraging the prediction of
critical events such as user’s future calls or encounters,
effSense selects the optimal uploading scheme for both
types of users. Our evaluation with MIT Reality Mining
and Nodobo datasets show that effSense can save 55% ∼
65% energy and 45% ∼50% data cost for the two types
of users, respectively, compared with the traditional
uploading schemes.
Author Keywords
mobile crowdsensing, energy saving, mobile data usage
ACM Classification Keywords
C.2.1 [Network Architecture and Design]: Wireless
Communications.
Introduction
As sensor equipped smartphones are getting more and
more popular nowadays, mobile crowdsensing is becoming
an effective way to carry out various sensing tasks such as
environmental monitoring [14] and social sensing [13]. To
improve user’s experience in participating mobile
crowdsensing tasks, how to minimize inconvenience
incurred for users is a practical issue. In this regard,
energy consumption and mobile data cost are two critical
concerns. While energy consumption is related to the
phone’s battery life, mobile data cost is often associated
with the fees paid, especially for the users who do not
hold an unlimited data plan. Therefore, reducing energy
consumption and data cost will hopefully encourage more
people to actively participate in crowdsensing tasks.
Recent years have witnessed an increasing interest in
improving user’s experience in mobile crowdsensing,
mainly from the perspective of energy saving. The
proposed solutions include using dynamic sensing duty
cycle [13], making trade-off between local and remote
computation [13,16], reducing data uploading frequency
by predicting missing data at server side [8], splitting the
task smartly among appropriate users [15], etc.. These
works assume that sensed data should be sent to a central
server as soon as they are produced.
In fact, some mobile crowdsensing tasks do not necessarily
require the sensed data to be uploaded in real-time. For
example, in MIT Reality Mining project [5], the
participant’s mobile traces were collected to understand
user’s interests, activity patterns, etc. mainly for further
analysis. Actually, the MIT Reality Mining project
collected users’ data in two ways. (1) 30 participants were
provided with a mobile data plan[4]. These users uploaded
their sensed data every night. (2) The other participants’
data was stored in the SD-cards and was collected after
the mobile phones were returned in the end of the project.
For both types of the participants, certain time of delay
between sensing and uploading is allowed.
Thus, in this paper, for the crowdsensing task that does
not require real-time sensed data uploading (called a
delay-tolerant crowdsensnig task), we attempt to design a
novel data uploading framework (named as effSense)
leveraging heterogeneous networks (e.g. 3G, WiFi and
Bluetooth), in order to enable (1) users without data plan
(called non-data-plan users) to reduce data transmission
cost by relaying data to bluetooth gateway or other
mobile phones encountered (rather than via 3G network),
(2) users with data plan (called data-plan users) to reduce
the energy consumption in data uploading.
effSense is designed based on the following observations:
1. Non-data-plan users can eliminate mobile data cost in
data uploading by using zero-cost network such as
Bluetooth and WiFi. For example, they can upload data
to the server directly via WiFi, or transfer data to another
device via Bluetooth if the other device can relay data to
the server without incurring extra cost.
2. Data-plan users can reduce energy consumption in data
uploading via the energy-efficient methods other than
establishing a new 3G connection. For example, coupling
a 3G data uploading task with a 3G voice call can save
75% ∼90% energy cost [9]. Alternatively, uploading data
via WiFi or Bluethooth consumes less energy than via
normal 3G.
A running example: Figure 1 shows a simple example to
illustrate the basic idea of effSense. Here, u1,u2, and u3
are three data-plan users, while u∗
1,u∗
2, and u∗
3are three
non-data-plan users. In addition, there is a server (S) and
a fixed-location Bluetooth gateway device (D). Instead of
uploading the sensed data directly via a specific 3G link,
effSense might suggest the following data uploading paths
to save data cost and energy consumption:
Server
Bluetooth
Gateway
3g
(parallel with voice call)
WIFI/LAN
u1u2u3
u*1u*2u*3
D
S
{r*2}
{r*1,r2}
ri: sensing data of ui
r*i: sensing data of u*i
{r*1,r2,r1}
{r*1}
{r*2,r3}
{r*3}
non-data-plan user
data-plan user
Figure 1: A running example of
effSense
Path 1 (red):u∗
3→D→S. A non-data-plan user (u∗
3)
uploads data via a Bluetooth gateway.
Path 2 (green):u∗
2→u3→D→S. A non-data-plan
user (u∗
2) relays data to a data-plan user (u3) first and
then u3uploads data via a Bluetooth gateway other than
direct 3G to save both data cost and energy consumption.
Path 3 (purple):u∗
1→u2→u1→S. The primary
difference between this path and the two above is that a
data-plan user (u1) coupled the 3G data uploading with a
voice call in the end, so as to save energy consumption.
As shown in this example, non-data-plan users are guided
to upload their sensed data without mobile data cost,
while data-plan users are recommended to upload data via
energy-efficient methods other than direct 3G. The design
objective of effSense is to ensure both data-plan and
non-data-plan users upload their data to server within a
predefined time line and with minimal energy consumption
and data cost.
The key issues involved in designing effSense include:
1. Identify and predict the critical events. Typical critical
events include making a new call,meeting another user,
encountering a Bluetooth gateway,connecting to a WiFi
AP, etc. Predicting the critical events for each user is the
basis for effSense to select the right data relaying strategy
and accurate prediction would result in better user’s
experience. Such predictions can be made by adopting
existing activity prediction techniques [17,11].
2. Estimate data uploading energy consumption
associated to each critical event. Specifically, for data
uploading, the energy consumption is not always
proportional to the data size. Uploading several small-size
sensed data together may require as much energy as
uploading only one small-size sensed data. For instance,
uploading data smaller than 10KB (whatever the exact
size) via 3G consumes almost the same energy [1].
However, above a certain threshold, the energy for data
uploading is roughly proportional to the data size.
3. Design real-time algorithms to decide whether data
should be offloaded or kept at each individual event. The
algorithms should be lightweight and executed on each
phone locally without incurring much energy or data cost.
In summary, our paper has the following contributions:
1. To the best of our knowledge, this is the first work that
aims to minimize both the energy consumption and
mobile data cost in mobile crowdsensing by leveraging
heterogeneous networks and delay-tolerant mechanisms.
2. We consider two types of users (non-data-plan and
data-plan) with different goals and thus propose two data
uploading schemes for each kind of users: one is pure
greedy, the other is based on the mobility/call predictions.
While the former one is quite effective in handling the
cold-start problem when participants’ historic call or
mobility logs are not available, the latter one can achieve
better performance by leveraging the critical-event
predictions according to the participants’ historic logs.
3. We evaluate effSense with two datasets - MIT Reality
Mining [5] and Nodobo [2]. The results show that
effSense could upload about 45%∼50% of non-data-plan
users’ data without extra data cost, and reduce 55%∼65%
of data-plan users’ data-uploading energy consumption
compared with the traditional method, under the
assumption that data-plan users and non-data-plan users
have the ratio of 3:4∗and maximum delay is 24 hours.
Related Work
The literature related to effSense can be roughly divided
into four categories as follows:
Mobile Crowdsensing Application Framework. To
support various mobile crowdsensnig applications, many
frameworks have been studied, such as task assignment
[15] and data collection [8,16]. Our work also provides a
framework, while the primary target is different from the
existing works as we optimize both non-data-plan and
data-plan users’ experience in terms of data uploading.
Energy Conservation in Mobile Sensing. The energy of
a mobile device in a crowdsensing task is mainly
consumed in three phases: sensing,computing and data
uploading. While effSense does not target at the energy
saving in the first two phases, the existing approaches in
these two phases [7,3] can be incorporated into effSense.
To reduce the energy consumption in data uploading,
while researchers have proposed various approaches such
as adopting low-power communication protocols [12] and
∗3:4 is the ratio when 30 users are selected as data-plan users in
MIT Reality Mining, which is the actual project setting [4].
using relay nodes [6], effSense selects an adaptive set of
these methods to reduce energy consumption.
Mobile Data Cost Conservation in Data Uploading.
To save data cost in data uploading, existing works are
focused on reducing data size by incurring additional
computation on the local mobile device [13,16]. While
these existing approaches can reduce data cost largely
when the size of raw data is big, they cannot eliminate it
completely. As effSense targets to eliminate data cost for
non-data-plan users, it is proposed to use zero-cost
networks (e.g., Bluetooth and WiFi) or relay to data-plan
users to upload data.
Mobility and Phone Call Prediction. Many works have
been studied on the predictions of human mobility [17]
and phone calls [11]. Instead of coming out with new
prediction algorithms, effSense leverages these existing
approaches to design intelligent uploading schemes to
reduce data cost for non-data-plan users and energy
consumption for data-plan users.
Problem Statement
Most real-life crowdsensing applications do not need to
upload the data immediately after it is sensed. Such
applications allow certain delay (a max tolerable delay
dmax) between collecting data from sensors and uploading
data to the server, i.e., the sensed data generated at t0on
a user’s phone can be uploaded during [t0, t0+dmax]. In
this paper, the problem is to design optimal delay-tolerant
data uploading schemes that can not only minimize
mobile-data-cost for non-data-plan users (Undp) but also
maximally decrease energy-consumption for data-plan
users (Udp). We first define two key concepts.
Definition 1 (Critical Events) A critical event (e∈E)
refers to an encounter that can help non-data-plan users
upload data without mobile data cost or/and can help
data-plan users save energy on data uploading. Ehas two
subsets:
•Server-related Critical Events (Eserver ): When one
user encounters the server (or intermediate servers,
e.g. Bluetooth gateway), the data can be uploaded
directly.
•User-related Critical Events (Euser): When usera
encounters userbwho might be able to better serve
data uploading, thus useracan offload data to
userbfor efficacy.
In each crowdsensing period, users encounter a sequence
of critical events (EVENTS ={e1, e2,· · · , en}), where
e1could be non-data-plan useraencountering the
gateway, e2could be non-data-plan userbencountering
data-plan userc. Our effSense framework is designed to
provide users with “optimal” decisions at each event (e),
either upload data to the server (when e∈Eserver ),
offload data to the counterpart (when e∈Euser), or keep
the data till next encounter occurs. Now, we formally
define the concept of “Event Decision”.
Definition 2 (Event Decision) In delay-tolerant data
uploading with maximum delay dmax, when a user uiwith
local sensed data riencounters a critical event eat time
t∗(t∗∈[t0, t0+dmax]), effSense provides a decision
whether data rineeds to be offloaded or kept. We note it
DEC(ui, ri, t∗, e, t0, dmax)→ {true, f alse}.
Based on these two definitions, we formulate our main
problem as follows:
Problem Formulation: In crowdsensing with max
tolerant delay (dmax) for data uploading, data plan users
(Udp) and non-data plan users (Undp ) encounter a critical
event sequence (EVENTS ). We want to obtain an
optimal decision making sequence DECISIONS for
EVENTS (i.e., each d∈DECISIONS corresponds to
the decision (true or false) of an event e∈EVENTS ),
in order to achieve the following two goals dedicated to
Undp and Udp, respectively.
First goal: Maximize the number of non-data-plan users
in Undp whose data is uploaded to the server with zero
data cost.
max |{u|u∈Undp, Ru(t0)∈Rserv er (t0+dmax)}|
where Ru(t0)means the sensed data of user ugenerated
at t0, and Rserver (t+dmax )means the data on the
server at t0+dmax.
Second goal: Minimize the energy consumption for all
data-plan users during the whole data uploading.
min X
u∈Udp
EnergyConsumedu(t0, t0+dmax )
where EnergyConsumedu(t0, t0+dmax )is the energy
consumed in data uploading by the user uduring
[t0, t0+dmax].
It is worth noting that we do not know all events
(EVENTS ) in advance. In real life, the event appears one
after another. When an event is encountered, the data
offloading decision should be made instantly. Although
future events are unknown, they could be predicted to
ensure better decision making for data offloading. This
will be discussed in more details in the next two sections.
Our Proposed Framework
In order to solve the two-goal optimization problem
formulated in the previous section, we design effSense to
provide effective uploading schemes during the whole
mobile crowdsensing period. Our effSense framework is
shown in Figure 2.
Server
Gateway
1
3
2n
Mobility
Prediction
4
3G Call
Prediction
time
location
Crowdsensing
Critical Events
Data Uploading
3G
non-data-plan user
data-plan user
Data Uploading
Schemes
cold-start
prediction-based
Server
Gateway
Figure 2: The effSense
framework
In the top part of Figure 2, we observe two types of
crowdsensing users, i.e., data-plan users (Udp) and
non-data-plan users (Undp). effSense can identify critical
events for each user by using state-of-the-art prediction
methods - including mobility prediction[17] and call
prediction[11]. Hereinafter, we obtain a sequence of
critical events (EVENTS ) in the middle of Figure 2. For
Udp, critical events can be used to reduce the energy
consumption caused by data uploading, e.g., using 3G-call
channel. For Undp, events can be used to eliminate mobile
data cost, e.g., meeting Bluetooth gateways and Udp.
In the crowdsensing period, effSense deploys the data
uploading schemes for analyzing the critical events. When
a user encounters a critical event, effSense applies an
optimal scheme to decide whether the user should offload
or keep data. As shown in the bottom part of Figure 2,
two non-data-plan users send data to a data-plan user and
a gateway via Bluetooth respectively, while a data-plan
user sends data via 3G when he makes a voice call.
There are two kinds of schemes in effSense for both types
of users - cold-start and prediction-based, which will be
explained in the next section.
Note that at the deadline of the data uploading period
(i.e. t0+dmax), effSense checks users whether they have
non-uploaded data: for Undp with data, effSense forces
them to upload to nearby Udp or gateways if applicable;
for Udp with data, effSense forces them to create a new
mobile network connection to upload data to the server.
Optimal Uploading Schemes
In this section, we will describe the uploading schemes in
detail. Before explaining the specific schemes, we first
show some preliminaries.
Preliminaries
Currently, we make the following assumption in effSense:
Assumption - Offload and Dismiss: Once user uoffloads
his local data, no matter the data receiver is the server,
gateway, or another user, uwill not be responsible for
sending the data any more.
This assumption is meant to avoid redundant data
uploading, as one goal of effSense is to reduce energy
consumption.
The focus of effSense is to design data uploading schemes
by detecting, predicting and exploiting critical events,
which are linked to two fundamental definitions, i.e., event
probability and event consumption.
Definition 3 (Event Probability) Given a user u, a
critical event set E∗, a start time t1, and an end time t2,
the event probability is the possibility that uwill
encounter any event e(e∈E∗) from t1to t2. We
represent it as Pevent(u, E ∗, t1, t2). Specifically, for the
data uploading period with max tolerable deley dmax , end
time t2is fixed (t2=t0+dmax), thus we can simplify the
notation as Pevent(u, E∗, t1).
Definition 4 (Event Consumption) Given a user u,
local data r, a critical event e, the event consumption is
the estimation of the energy that uconsumes to upload r
under e, represented as W(u, r, e). Specifically, if
e∈Euser, event consumption sums both the energy for
sending and receiving data. Sppose that another user is
u0,W(u, r, e) = Wsend(u, r, e) + Wrec(u0, r, e).
For the sake of simplification, we do not further discuss
the specific methods for predicting event probability and
estimating event consumption in this section, as they are
not the focus of this paper. The specific methods used in
our experiment will be described in the Evaluation section.
Uploading Scheme Overview
In general, there are two kinds of schemes for each user
type - cold-start and prediction-based.
•Cold-start scheme: It does not require users’ history,
and applies a straightforward greedy algorithm to
recommend users to offload data as soon as he
meets a ‘friendly’ event that can save data cost for
non-data-plan users, or save energy consumption for
data-plan users.
•Prediction-based scheme: It uses users’ history to
predict future mobility traces and calls to optimize
the event decision making.
When a new user joins, effSense can use the cold-start
scheme according to his user type to make the event
decision. After a period of time, when the user
accumulates enough activity logs, effSense can change to
the corresponding prediction-based scheme.
Now we begin to explain our proposed schemes in detail.
In the following section, suppose that a user uiencounters
a critical event eat time t(another user encountered is uj
if e∈Euser).
Non-data-plan Uploading Schemes
SimpleGreedyndp (cold-start)
The intuition behind SimpleGreedyndp is straightforward.
•If a non-data-plan user encounters an event which
can definitely help him upload data to the server
without using 3G, then he offloads data.
This kind of events is represented as End like, which
includes meeting a data-plan user or a gateway via
Bluetooth, connecting to WiFi, etc.
AdvancedGreedyndp (prediction-based)
The intuition behind AdvancedGreedyndp is derived from
SimpleGreedyndp, while adding a new offloading
situation - when non-data-plan uimeets another
non-data-plan ujwho has higher probability to encounter
End like,uiwill offload data to uj. Therefore, uiwill
offload data if any of the two following conditions satisfies.
1. e∈End like
2. e∈ {e0|e0∈Euser, uj∈Undp }and
Pevent(ui, End like, t)< Pev ent(uj, End lik e, t)
Data-plan Uploading Schemes
Greedydp (cold-start)
The intuition behind Greedydp is making a data-plan user
upload data as soon as he meets an event when data
could be uploaded to the server via an energy-saving
method compared with a new 3G connection. This kind of
events is represented as Eeff , which is defined as:
Eeff ={e|e∈Eserver , W (u, r, e)< W3G(u, r)}
where W3G(u, r)is the energy consumption for uto
upload rby establishing a new 3G connection.
ExpectationBaseddp (prediction-based)
The intuition behind ExpectationBaseddp can be
generally described as follows:
1. When uiencounters an event, his expected energy
consumption under two conditions are computed -
(1) offloading data (expEnergyoffload ), (2) keeping
data (expEnergykeep ).
2. If expEnergyoffload < expEnergykeep ,uioffloads
data; otherwise, uikeeps data.
Before the detailed explanation, we first give a definition
for the expected energy consumption stated previously:
The expected energy consumption for a user uat time tis
the energy which uis expected to consume from tto the
data uploading deadline t0+dmax.
Figure 3: Computation for
energyfut
We use the notation energyfut (u, r0, t)to represent the
expected energy consumption when ukeeps data r0locally
at time t. The detailed computation process is shown in
Figure 3. It is worth noting that in step 3 , we not only
consider the local data r0, but also the data that umay
receive from other users during [t, t0+dmax]. Therefore,
even if uhas no local data at t(i.e. r0= 0), it is possible
that energyfut (u, 0, t)>0.
Now we explain the computation processes of
ExpectationBaseddp . The specific processes are
somewhat different between e∈Eserver and e∈Euser .
1. e∈Eserver
1) expEnergyoffload is divided to two parts - (1) energy
for uito upload local data ri, (2) expected energy
consumption when uihas no data at t:
expEnergyoffload =W(ui, ri, e) + energyfut (ui,0, t)
2) expEnergykeep is exactly the expected energy
consumption when uikeeps data riat t:
expEnergykeep =energyfut (ui, ri, t)
2. e∈Euser
When computing expEnergy here, we take both uiand
ujinto account to get the sum of two users’ expected
energy consumption.
1) expEnergyoffload is extended to two conditions - (1)
uioffloads data to uj(expEnergyij
offload), (2) ujoffloads
data to ui(expEnergyji
offload):
expEnergyij
offload =Wsend(ui, ri, e) + Wrec (uj, ri, e) +
energyfut (ui,0, t) + energyfut (uj, ri+rj, t)
expEnergyji
offload =Wsend(uj, rj, e) + Wrec (ui, rj, e) +
energyfut (uj,0, t) + energyfut (ui, ri+rj, t)
2) expEnergykeep means that uiand ujboth keep data:
expEnergykeep =energyfut (ui, ri, t)+energyfut (uj, rj, t)
Through computing energyfut and estimating W(u, r, e),
we get the results of these formulas and make the event
decision by selecting the condition with the smallest value.
Finally, we describe an implementation issue in effSense.
Info Exchange by Device Name Encoding
In effSense, when two users meet, one user needs to know
some info about the other to make the event decision.
These info include user type (non-data-plan or data-plan),
Pevent(u, End like, t)(for non-data-plan users), energyfut
(for data-plan users), etc. effSense make users exchange
the info by encoding them into the device name. One
defect is that the device name needs to change
occasionally as some info change over time. Fortunately,
device name change does not consume much energy.
Evaluation
In this section, we evaluate effSense framework using both
MIT Reality Mining [5] and Nodobo [2] datasets.
Table 1: Energy estimation for
3G and Bluetooth (joule)
Protocol Small Big (xKB)
3G 12 12+0.025x
Bluetoothk1 1+0.003x
Table 2: Energy estimation for
critical events (joule)
Event Small Big (xKB)
e3g call∗3 3+0.006x
ebt device 1 1+0.003x
ebt user†2 2+0.006x
Table 3: Nnd upload on MIT
Scheme Workday Holiday Overall
BTact 26.1 14.8 22.1
SGndp
23.3
(89%)‡
10.6
(71%)
18.8
(85%)
AGndp
24.3
(93%)
11.0
(74%)
19.6
(89%)
5
10
15
20
25
30
35
8 10 12 14 16 18 20
Nnd-upload
Date (2004-11)
Nnd-upload
Simple-Greedy
Advanced-Greedy
BT Activity
Figure 4: Each day’s Nnd upload
during 2-week evaluation on MIT
Experimental Setup on MIT
In the MIT dataset, we choose the time period from
2004.10.4 to 2004.11.21 for evaluation, where 71 active
users participated in the trial in 7 weeks.. We select top
30 mobile-data-usage users as data-plan users according
to the project real setting [4]. We use the first 5 weeks’
logs as history, and evaluate effSense on the last 2 weeks.
We suppose that the start of each data collection is
00:00:00 and deadline is 23:59:59 each day. So there are
14 continuous data collections during the last 2 weeks.
We choose 3 critical event types - (1) e3g call: making a
3G call, (2) ebt device: meeting a Bluetooth gateway ††,
(3) ebt user: meeting another user via Bluetooth.
Based on existing works about the mobile phone energy
consumption [1,10], we construct the energy estimation
formulas for both 3G and Bluetooth, as shown in Table 1,
for both small-size and big-size data‡‡. Further, we use
these results to estimate each event energy consumption,
as shown in Table 2.
kWe do not consider the Bluetooth scan energy consumption,
because MIT Reality Mining project itself asks the participants to do
frequent Bluetooth scan every 5 minute.
∗3G data transmission during voice call save at least 75% energy
consumption [9].
†The energy consumption of ebt user is twice the Bluetooth en-
ergy consumption because of one user sending and one user receiving.
‡The values in the brackets are the proportions to the correspond-
ing Nnd−upload of BTact .
††We choose two devices named localhost.media.mit.edu and stud-
ies.media.mit.edu as gateways.
‡‡Small-size data uploading consumes almost the same energy no
matter what is the specific data size[1].
Prediction Method
Our experiment applied a simple timeslot-based prediction
method. We split one week into 24 ∗7timeslots so that
each timeslot lasts one hour. The calculation process for
Pevent(u, E , t1, t2)is:
1. Map t1,t2to the corresponding timeslots ts1and ts2.
2. Suppose that the history data includes mweeks, and
user uencounters any event e∈Efrom ts1to ts2in n
weeks, then Pevent(u, E , t1, t2) = n/m
Experiment Results on MIT
Corresponding to the two optimization goals of effSense,
we primarily want to answer two questions - (1) How
many non-data-plan (NDP) users can upload data without
data cost? (2) How much energy can data-plan (DP)
users save in data uploading in effSense? The answers for
these two questions are also directly related to the
performances of our proposed NDP and DP uploading
schemes, respectively.
Performance of Data Cost Conservation on MIT
First, we investigate the number of NDP users who
upload data successfully (Nnd upload) for two NDP
schemes (Figure 4and Table 3). In general, effSense can
help 45%∼48% NDP users upload data successfully
without data cost (i.e. help average 18.8∼19.6 in total 41
NDP users in one data collection). In Figure 4, effSense
did not perform well in the holidays (day 11, 13, 14, 20,
and 21 in Nov. 2004), as few users came to school so that
the opportunities for Bluetooth relay dropped. In Table 3,
we introduce an upper bound of Nnd upload , which is the
number of NDP users having Bluetooth activity (BTact),
because only this kind of NDP users might upload data
via Bluetooth relay to cut data cost. Further,
AdvancedGreedyndp outperformed about 4% over
SimpleGreedyndp. As SimpleGreedyndp achieved nearly
0
50
100
150
200
250
300
350
400
working-day holiday total
joule
total-energydata-plan (small-size data, MIT)
SGnd+Gd
SGnd+Ed
AGnd+Gd
AGnd+Ed
Tradition
(a) small
0
100
200
300
400
500
working-day holiday total
joule
total-energydata-plan (100KB data, MIT)
SGnd+Gd
SGnd+Ed
AGnd+Gd
AGnd+Ed
Tradition
(b) 100KB
0
100
200
300
400
500
600
700
working-day holiday total
joule
total-energydata-plan (200KB data, MIT)
SGnd+Gd
SGnd+Ed
AGnd+Gd
AGnd+Ed
Tradition
(c) 200KB
Figure 5: totalEnergydp for small/100KB/200KB data on MIT
90% performance compared with the upper bound BTact
on workdays, this improvement was still meaningful.
0
50
100
150
200
250
300
350
400
SGnd+GdSGnd+EdAGnd+GdAGnd+EdTradition
joule
total-energyall (small-size data, MIT)
non-data-plan user data-plan user
Figure 6: totalEnergyall for
small-size data on MIT
0
5
10
15
20
25
30
35
SGNDP+GDP SGNDP+EDP AGNDP+GDP AGNDP+EDP
joule
Triggerings for each event (small-size data, MIT)
3G-CALL
BT-DEVICE
BT-UN2D
BT-UN2N
BT-UD2D
3G-NEW
Figure 7: Event triggerings in
one data collection on MIT
Performance of Energy Conservation on MIT
Figure 5shows the energy consumption for DP users in
data uploading (totalEnergydp ) of three data sizes
(small, 100KB, and 200KB). effSense saved 55%∼65% of
the energy consumption for DP users compared with the
traditional method‡. Specifically, ExpectationBaseddp
can save 9.8%∼17.5% more energy compared with
Greedydp on workdays (given the same NDP scheme).In
addition, as the data size increases, the performance gap
between ExpectationBaseddp and Greedydp decreases.
The reason is that as the data size increases, the overhead
for one user to help others relay data becomes larger.
Figure 6shows the total energy consumption for both DP
and NDP users (totalEnergyall ). Though effSense incurs
NDP users’ energy consumption which does not exist in
‡The traditional method means that data-plan users upload their
data via a new 3G connection everyday, while non-data-plan users
store their data in the SD-cards instead of uploading to the server.
the traditional method, totalEnergyall is still reduced by
51%∼56%.
Event Triggering Times on MIT
Figure 7shows the actual triggering times to offload data
for each kind of events. Specifically, euser is divided into
three senarios according to the data offloading direction:
(1) Undp →Udp (BT UN2D), (2) Undp →Undp
(BT UN2N), and (3) Udp →Udp (BT UD2D).∗
First, the triggering times of establishing a new 3G
connection decreased significantly in effSense compared
with the traditional method which would incur 30 new 3G
connections in every data collection. As establishing a new
3G connection is energy-demanding, this is the primary
reason why effSense can save energy. In addition, for the
cold-start scheme pair {SimpleGreedyndp,Greedydp},
the data exchanges between users are only carried out as
Undp →Udp. However, AdvancedGreedyndp and
ExpectationBaseddp introduced the data exchanges of
∗Udp →Undp does not exist in effSense because this direction
completely conflicts the goal of saving data cost for Undp
Undp →Undp and Udp →Udp, respectively. Furthermore,
given the same NDP scheme, ExpectationBaseddp
triggers much fewer e3g call and more ebt device than
Greedydp. This is why ExpectationBaseddp can save
more energy than Greedydp, as energy consumption for
ebt device is less than e3g call.
Results on Other Delay Settings
Besides the 24-hour delay assumed, we conduct some
experiments with shorter delays∗(Table 4). With the
delay decreasing, NDP users have fewer chances to upload
data without data cost (Nnd upload decreases) and DP
users consume more energy (totalEnergydp increases),
because few critical events, which effSense can use to
improve users’ experience, exist in a short delay. In
addition, for a short delay, collection start time affects
Nnd upload and totalEnergydp , as the number of critical
events may differ greatly between different time periods.
Table 4: Nnd upload and totalE nergydp for different delays
Delay Nnd upload totalEnergydp
3-hour 10.7 178.9J
6-hour 14.7 167.0J
12-hour 18.0 140.3J
24-hour 19.6 130.4J
0
20
40
60
80
100
120
140
working-day holiday total
joule
total-energydata-plan (small-size data, Nodobo)
SGnd+Gd
SGnd+Ed
AGnd+Gd
AGnd+Ed
Tradition
Figure 8: totalEnergydp for
small-size data on Nodobo
0
1
2
3
4
5
6
7
8
SGnd+GdSGnd+EdAGnd+GdAGnd+Ed
Triggerings for each event (small-size data, Nodobo)
3G-CALL
WiFi
BT-UN2D
BT-UN2N
BT-UD2D
3G-NEW
Figure 9: Event triggerings in
one data collection on Nodobo
Table 5: Nnd upload on Nodobo
Scheme Workday Holiday Overall
BT W act 10.33 7.20 9.21
SGndp
10.00
(97%)
6.20
(86%)
8.64
(94%)
AGndp
10.33
(100%)
6.40
(89%)
8.93
(97%)
Evaluation on Nodobo
We also evaluate effSense on Nodobo, as this dataset
contains users’ WiFi traces, which MIT Reality Mining
lacks. Therefore, we introduce ewif i, which means a user
connecting to a WiFi AP. ewif i can help NDP users
upload data without data cost. The energy consumption
to upload small-size data via WiFi was set to 2J[1]. We
∗Experimental settings: small data size and the prediction-based
schemes {AdvancedGreedyndp ,ExpectationB aseddp }.
exclude ebt device as no gateways exist in Nodobo. The
other experimental settings are small-size data, 24-hour
delay, 11 DP users and 16 NDP users.
The results are shown in Figure 8, Figure 9, and Table 5.
In Table 5, we set the upper bound of Nnd upload as the
number of NDP users who have either Bluetooth or WiFi
activity, called BT Wact. The results are similar to MIT
Reality Mining. Figure 9shows that the new event ewifi
was effective in improving the overall performance of
effSense, as ewif i was triggered most frequently. .
Discussion
Ratio of data-plan and non-data-plan users
The ratio of data-plan and non-data-plan users will affect
the performance of effSense. Currently we choose 30 users
as data-plan users, the same as actual MIT Reality Mining
project setting[4] to simulate the real-life condition.
Though the thorough experiments under various ratios are
not covered in this paper, the proposed mechanisms are
still valuable for real-life mobile crowdsensing tasks.
Data Size
In the experiment, we set three data sizes - small, 100KB,
and 200KB. In fact, some sensing tasks can generate large
data up to several MB (e.g. photos). When considering
such large data, we will face some additional problems.
For instance, we cannot simply make the assumption that
two users can succeed in exchanging several MB data via
Bluetooth when they meet, because the opportunistic
Bluetooth encounter is temporary and unstable. In this
paper, we did not conduct the experiment for large data
up to MB level. effSense should be improved in our future
work to handle large data collection issue.
Energy Consumption vs Battery Life
For current smartphones, uploading small-size data via 3G
once only consumes about 0.1% battery (e.g. Nokia N95
with a 950mAh battery). However, energy-saving schemes
still play a role in effSense, because the battery drain can
increase for two reasons. First, more uploadings (i.e.
shorter delay) and larger data will drain more battery.
Second, the most ‘friendly’ data-plan users will help other
2∼3 non-data-plan users upload data per collection
according to our experiment, which incurs extra battery
drain. E.g., as six 200KB data uploadings in the daytime
(i.e. about 3-hour delay) drain about 1.5% battery, the
most ‘friendly’ data-plan users will drain up to 5% battery
per day in data uploading. By introducing energy-saving
schemes into effSense, the most ‘friendly’ data-plan users
can decrease the battery drain to around 1%.
Additional Critical Events
Due to the dataset limitation, we cannot capture all the
useful critical events in the experiment. For example,
whether a phone is charging or not plays a vital role in
deciding if data should be offloaded or kept. In our future
work, we plan to introduce the phone charging event and
other useful events into effSense.
Other Issues to Improve effSense
We can also improve effSense in many other directions,
such as using a more precise energy estimation mechanism
and an advanced user mobility/call prediction method.
Conclusion
In this paper, we investigate how to reduce both energy
consumption (for data-plan users) and mobile data cost
(for non-data-plan users) caused by data uploading in
mobile crowdsensing, and design the effSense framework
to improve both users’ experience in delay-tolerant mobile
crowdsensing. The experiment results on MIT Reality and
Nodobo datasets verified the effectiveness of effSense.
References
[1] Balasubramanian, N., Balasubramanian, A., and Venkataramani, A.
Energy consumption in mobile phones: a measurement study and
implications for network applications. In IMC (2009), 280–293.
[2] Bell, S., McDiarmid, A., and Irvine, J. Nodobo: Mobile phone as a
software sensor for social network research. In Vehicular Technology
Conference (2011), 1–5.
[3] Chu, D., Lane, N. D., Lai, T. T.-T., Pang, C., Meng, X., Guo, Q., Li, F.,
and Zhao, F. Balancing energy, latency and accuracy for mobile sensor
data classification. In SenSys (2011), 54–67.
[4] Eagle, N. The reality mining data readme:
http://www.media.mit.edu/ventures/EPROM/data/
RealityMining_ReadMe.pdf.
[5] Eagle, N., and (Sandy) Pentland, A. Reality mining: sensing complex
social systems. Personal Ubiquitous Comput. 10 (2006), 255–268.
[6] Hull, B., Bychkovsky, V., Zhang, Y., Chen, K., Goraczko, M., Miu, A.,
Shih, E., Balakrishnan, H., and Madden, S. CarTel: a distributed mobile
sensor computing system. In SenSys (2006), 125138.
[7] Kjrgaard, M. B., Bhattacharya, S., Blunck, H., and Nurmi, P.
Energy-efficient trajectory tracking for mobile devices. In MobiSys
(2011), 307–320.
[8] Musolesi, M., Piraccini, M., Fodor, K., Corradi, A., and Campbell, A. T.
Supporting energy-efficient uploading strategies for continuous sensing
applications on mobile phones. In Pervasive Computing, P. Floren,
A. Krger, and M. Spasojevic, Eds., no. 6030 in LNCS. 2010, 355–372.
[9] Nurminen, J. Parallel connections and their effect on the battery
consumption of a mobile phone. In CCNC (2010), 1–5.
[10] Perrucci, G., Fitzek, F., and Widmer, J. Survey on energy consumption
entities on the smartphone platform (2011). 1–6.
[11] Phithakkitnukoon, S., Dantu, R., Claxton, R., and Eagle, N.
Behavior-based adaptive call predictor. ACM Transactions on
Autonomous and Adaptive Systems (TAAS) 6, 3 (2011), 21.
[12] Ra, M.-R., Paek, J., Sharma, A. B., Govindan, R., Krieger, M. H., and
Neely, M. J. Energy-delay tradeoffs in smartphone applications. In
MobiSys (2010), 255–270.
[13] Rachuri, K. K., Mascolo, C., Musolesi, M., and Rentfrow, P. J.
SociableSense: exploring the trade-offs of adaptive sampling and
computation offloading for social sensing. In MobiCom (2011), 73–84.
[14] Rana, R. K., Chou, C. T., Kanhere, S. S., Bulusu, N., and Hu, W.
Ear-phone: an end-to-end participatory urban noise mapping system. In
IPSN (2010), 105–116.
[15] Sheng, X., Tang, J., and Zhang, W. Energy-efficient collaborative
sensing with mobile phones. In INFOCOM (2012), 1916–1924.
[16] Sherchan, W., Jayaraman, P. P., Krishnaswamy, S., Zaslavsky, A., Loke,
S., and Sinha, A. Using on-the-move mining for mobile crowdsensing. In
MDM (2012), 115–124.
[17] Vu, L., Do, Q., and Nahrstedt, K. Jyotish: A novel framework for
constructing predictive model of people movement from joint
wifi/bluetooth trace. In PerCom (2011), 54–62.