Content uploaded by Hieu Khac Le
Author content
All content in this area was uploaded by Hieu Khac Le
Content may be subject to copyright.
SolarStore: Enhancing Data Reliability in Solar-powered
Storage-centric Sensor Networks
Yong Yang∗, Lili Wang$, Dong Kun Noh∗, Hieu Khac Le∗and Tarek F. Abdelzaher∗
∗Department of Computer Science, University of Illinois at Urbana-Champaign, Urbana, IL 61801, USA
$School of Computer Science and Engineering, Beihang University, Beijing 100191, China
{yang25, liliwang, dnoh, hieule2, zaher}@illinois.edu
ABSTRACT
In this paper, we present a reliable storage service, called
SolarStore, that adaptively trades-off storage reliability ver-
sus energy consumption in solar-powered sensor networks.
SolarStore adopts a predominantly disconnected network
model, where long-running data-collection experiments are
conducted in the absence of a continuous connection to the
outside world. SolarStore (i) replicates data in the network
until the next upload opportunity, and (ii) adapts the degree
of data replication dynamically depending on solar energy
and storage availability. The goal is to maximize the amount
of data that can eventually be retrieved from the network
subject to energy and storage constraints. Maximization of
retrievable data implies minimizing sensing blackouts due to
energy depletion as well as minimizing loss due to node dam-
age in harsh environmental conditions. We have deployed an
outdoor solar-powered sensor network, on which SolarStore
is implemented and tested. An indoor testbed is also set up
for performance evaluation under environmental conditions
not attained locally. Experiments show that SolarStore is
successful in dynamically responding to variations in the en-
vironment in a manner that increases retrievable data under
different node failure scenarios.
Categories and Subject Descriptors
C.2.4 [Computer Systems Organization]: COMPUTER-
COMMUNICATION NETWORKS—Distributed Systems; E.5
[Data]: FILES—Backup/recovery
General Terms
Algorithms, Design, Experimentation
Keywords
Energy, Sensor networks, Reliable file systems, Solar-powered
systems
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. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
MobiSys’09, June 22–25, 2009, Kraków, Poland.
Copyright 2009 ACM 978-1-60558-566-6/09/06 ...$5.00.
1. INTRODUCTION
Driven by advances in wireless networking and embedded
processing technologies, there has been an increasing interest
in the use of sensor networks for habitat and environment
monitoring [11, 14, 19, 30, 32]. In many scenarios where
sensor nodes are deployed in remote locales, there is limited
connectivity to the outside world, and thus sensory data
have to be stored in the network until the next upload op-
portunity (e.g., a mobile basestation) appears. Meanwhile,
habitat and environmental monitoring usually requires long-
running (or even perpetual) operation, which makes solar
energy an attractive power source.
In this paper, we develop a storage service, called Solar-
Store, for solar-powered storage-centric sensor networks as
described above. The service is novel in its mechanisms for
improving the amount of data retrieved from the network
(when it gets upload opportunities) in the face of energy con-
straints and node failures. Maximizing retrievable data in
the face of node failures requires implementing reliable stor-
age, where reliability is achieved using redundancy. Since
achieving redundancy takes energy, the energy constraints
imply that the level of redundancy should be adapted dy-
namically depending on the energy available. Hence, a main
contribution of SolarStore lies in its energy-adaptive storage-
reliability mechanism used to maximize retrievable data.
Maximizing retrievable data in solar-powered networks
motivates a new design for reliable storage, which is differ-
ent from those proposed for conventional battery-powered
networks [12, 17, 21, 22]. Namely, in conventional battery-
powered sensor networks, the total amount of work that
can be accomplished is approximately fixed as given by the
initial energy in the batteries. On the contrary, in solar-
powered nodes, a full battery could not harvest more energy
even if it was noon and more solar energy was available.
Hence there is an incentive to spend energy to make room
for more energy. Yet, because of the dynamic nature of so-
lar energy, spending should not be overdone in order not to
deplete the battery prematurely and cause sensor blackouts.
A challenge of SolarStore is thus to achieve the right balance
between spending and saving to maximize the total amount
of energy harvested while avoiding blackouts.
SolarStore utilizes fountain coding [20] for data replica-
tion. It partitions each data block into pieces and then
encodes them into a larger number of chunks. The origi-
nal data can be retrieved as long as some subset of encoded
chunks survive. A distributed strategy is used to scatter
the encoded data chunks in the network. More chunks are
created and scattered when more energy is available. We for-
333
mulate the above adaptive policy as an optimization prob-
lem, with the objective of maximizing the amount of data
that can eventually be retrieved from the sensor network
when it gets connected. Ideally, solving this optimization
requires knowledge of both the node failure probability dis-
tribution (to predict replication needs) and weather patterns
(to predict energy input). Since this information is hard to
quantify, we develop a very simple and effective solution
instead, that is independent of models of node failure and
weather patterns. The key insight of our solution is that
the energy status of a node is reset every time the battery
is fully charged. At that time, prior energy use becomes ir-
relevant. Instead, based on the average energy charge and
discharge rates, we can determine how much energy should
be reserved in order to sustain the node until the next time
it is fully charged. The energy surplus (if any) can then be
allocated to improve storage reliability.
Besides energy constraints, data replication is also lim-
ited by available storage. Since storage is renewed every
time when an upload opportunities appears, we apply an
approach similar to the energy allocation to determine the
storage surplus that can be used for storing data replicas.
We set up a solar-powered sensor network testbed in a
farm on the south campus of the University of Illinois at
Urbana-Champaign, on which SolarStore has been imple-
mented and tested. Currently, 9 nodes have been deployed
and each node comprises an energy subsystem and a comput-
ing subsystem. The energy subsystem contains a recharge-
able battery as the power source for the computing system,
plus a set of two solar panels to recharge the battery. The
computing subsystem has a low-power PC to provide the
computing capability, a wireless router to support commu-
nication between nodes, as well as sensing devices, such as
microphones or cameras, to serve different applications. In
addition, we built an indoor testbed with the purpose of
performance evaluation under a wide range of emulated en-
vironmental conditions. This indoor tested also has 9 nodes
with the exactly same computing subsystem as nodes out-
doors, while the energy subsystem is emulated to enable ex-
perimentation with environmental conditions not attained
locally. Results show that SolarStore dynamically responds
to variations in the environment and leads to more retriev-
able data under different node failure scenarios, compared
to three other schemes.
The remainder of the paper is organized as follows. In Sec-
tion 2, we summarize the related work. In Section 3, we for-
mulate the retrievable data maximization problem and pro-
pose a simple and effective solution. In Section 4, we explain
how data are encoded and disseminated among nodes in the
network. Following that, Section 5 illustrates the setup of
the outdoor testbed, describes the software architecture of
SolarStore and addresses issues in its implementation. We
introduce the indoor testbed and evaluate SolarStore in Sec-
tion 6. Finally, Section 7 concludes the paper and discusses
future work.
2. RELATED WORK
Solar energy is one of the most attractive power sources
due to its high power density and periodical charging cy-
cle. A number of works have prototyped the use of solar
energy to power wireless sensor networks (WSNs) [26, 16,
33, 10, 31, 15, 19, 27, 29]. However, most of them have fo-
cused on node-level design such as hardware architecture or
power control, rather than network-wide or application-level
performance optimization such as throughput or reliability.
For example, Vijay et al. [26] describe the key issues and
tradeoffs which arise in the design of a solar energy har-
vesting system and present a prototype called Heliomote.
Alippi and Galperti [10] propose a low-energy MPPT (Max-
imum Power Point Tracker) circuit specifically designed for
wireless sensor nodes to optimally convey solar energy into
rechargeable batteries. Jay et al. [31] describe a systematic
approach to build micro-solar power subsystems for wire-
less sensor nodes. Eon [29] is an energy-aware programming
language that allows programmers to annotate paths in the
program with different energy states, while the energy man-
ager adapts these states to current and predicted energy
levels.
Recently, there arise a few research efforts dealing with
these network-wide metrics in solar-powered wireless sensor
networks [34, 24, 25]. For example, Noh et al. [25] con-
sider the end-to-end delay as a metric of network-wide QoS
in solar-powered WSNs. They suggest a low-latency data
delivery scheme, which considers the information of the har-
vested energy, deployed location and duty-cycle information
about the neighbors. However the scope of these works is
limited to data delivery schemes for delivery-centric WSNs.
On the contrary, our scheme is designed for enhancing stor-
age reliability in storage-centric WSNs where sensory data
have to be stored in the network for a long time until upload
opportunities appear.
On the other hand, much work has been done on dis-
tributed storage systems in storage-centric (or called dis-
connection -tolerant) networks. DALi [28] is a data ab-
straction layer towards mobile and frequently disconnected
sensor networks. It aims at providing a virtual file system
among distributed sensor nodes, thus focusing on data orga-
nization, search and naming schemes. EnviroStore [22] and
EnviroMic [21] are distributed storage systems designed for
disconnected operation in sensor networks, targeted at max-
imizing the network storage capacity. However, they do not
consider reliability issues. Bhatnagar et al. [12] suggest a
reliable file system for sensor networks. It assumes a flat,
distributed network organization devoid of a basestation,
encrypts data stored on local storage of sensor nodes and
backs it up regularly onto neighbor nodes. Even though it
guarantees reliability through regular backup, it does not
address adaptive energy allocation for reliability. Capsule
[23] aims at saving energy in storage-centric networks by
providing a rich file system abstraction that can fully ben-
efits the NAND flash storage. Additionally, most of works
mentioned above assume traditional battery-based systems.
Thus, they focus on reducing the consumed energy as much
as possible, which is different from our approach that trades
off the energy surplus (if any) for data reliability so as to
maximize the overall retrievable data.
3. RETRIEVABLE DATA MAXIMIZATION
In this section, we formulate retrievable data maximiza-
tion as an optimization problem where we enhance data re-
liability such that the total amount of data eventually re-
trievable from the network is maximized. Ideally, solving
this optimization problem requires knowledge of both the
node failure rates and weather patterns. However, both of
these are extremely hard to quantify precisely. Instead, we
propose a simple and effective solution that is independent
334
of these two physical models. Both energy constraints and
storage constraints can be accommodated similarly. We first
focus on the energy allocation problem.
3.1 Problem Formulation
In storage-centric sensor networks, there are two types
of possible reasons for data loss. One is loss due to node
failures (e.g., caused by natural events in the harsh envi-
ronment). The data on failed nodes cannot be retrieved.
Redundancy can be used to improve storage reliability and
thus mitigate data loss caused by node failure. Achieving re-
dundancy takes additional energy and storage resources to
replicate/encode data and scatter them in the network. Let
Eresidual be the current residual energy in the battery, and
∆E(0 ≤∆E≤Eresidual) be the energy allocated for en-
hancing data reliability. Given a replication method, the sta-
tus of the current buffered data and the node failure model,
we can determine how much more data can survive if ∆Eis
spent, and denote this gain in data reliability by Gain(∆E).
On the other hand, it is possible that the added energy
consumption will lead to suspension sensing due to energy
depletion and hence result in data loss. Denote Loss(∆E)
as the additional amount of such data loss if ∆Eamount of
energy is taken away for data reliability. Our goal is
max Gain(∆E)−Loss(∆E) (1)
s.t. 0≤∆E≤Eresidual.
Intuitively, the larger the ∆E, the higher the Gain(∆E)
in data reliability but potentially the more the Loss(∆E).
Hence ∆Eshould be carefully chosen such that Gain(∆E)
and Loss(∆E) are balanced.
Loss(∆E) can be further quantified using the insight that
the energy in the system is renewed every time the bat-
tery is fully charged. It implies that it does not matter
how the energy was spent before, once the battery is fully
charged again. Therefore, given the current residual en-
ergy Eresidual, we define B(Eresidual ) as the expected dura-
tion of blackout time (i.e., when the battery is empty and
data sensing is suspended), from now until the next time
when the battery is fully charged. Since no sensory data
can be created during a blackout, the resulting data loss is
R·B(Eresidual), where Ris the expected data sensing rate.
Thus, if ∆Eis allocated from Eresidual for storage reliability,
we have the additional data loss
Loss(∆E) = R·£B(Eresidual −∆E)−B(Eresidual )¤(2)
The explicit formula for B(Eresidual) and Gain(∆E) de-
pends on physical models used for node failure and weather
patterns. Both cannot be accurately modeled and highly
depend on the deployment environment. The question be-
comes whether we can identify some properties of Gain(∆E)
and B(Eresidual) that are independent of those physical mod-
els and can help in solving the problem. In the next section,
we describe a solution to this problem.
3.2 A Simple and Effective Solution
We propose a simple and effective solution based on the
following properties of Gain(∆E) and B(Eresidual).
Property 1: Given any node failure model, Gain(∆E)is
a non-decreasing function of ∆E.This can be ensured by
any correct reliable storage scheme, which increases or at
least maintains the current reliability level if more energy is
spent.
Property 2: Given any weather pattern, B(Eresidual)is
a non-increasing function of Eunder the same power con-
sumption profile. It is obvious that the higher the energy
available initially, the lower the blackout time, under the
same weather conditions and the same power consumption
profile.
Let Psolar be the average power charging rate of the solar
panels, and Psys be the average power consumption rate of
the system. Given the current residual energy Eresidual , the
expected number of days to the next time when the battery
is full can be calculated by
Tfull (Eresidual ) = C−Eresidual
Psolar −Psys
.(3)
where Cis the battery capacity.
Note that when the battery is partially empty, to charge
it, it must be that Psolar ≥Psys, which means that the av-
erage energy consumption rate of the system must be made
less than or equal to the average solar energy charging rate.
Otherwise, the system will shut down.
Even though solar energy varies from daytime to night-
time and from day to day, it remains true that the expected
blackout time is zero between now and the next time the bat-
tery is full, if we currently have at least Psys ·Tf ull(Eresidual )
energy in the battery. This is true even in the worst case,
where all solar energy charging occurs at the very last in-
stant at Tfull . By solving Eresidual =Psys ·Tf ull(Er esidual),
we have Eresidual =Psys
Psolar C. Based on the monotonicity of
B(Eresidual) as in Property 2, we obtain the last but most
important property.
Property 3:B(Er esidual)=0if Eresidual ≥Psys
Psolar C.
It implies that by maintaining the residual energy above a
fraction Psys
Psolar of the battery capacity C, the expected data
loss due to blackout is always zero.
Based on Property 3, when the energy allocation ∆Efor
storage reliability satisfies Eresidual −∆E≥Psys
Psolar C, we
have
Loss(∆E) = R·B(Eresidual −∆E)−R·B(Eresidual )
= 0 −0 = 0.(4)
Furthermore, according to Property 1 that the reliabil-
ity gain Gain(∆E) is a non-decreasing function of ∆E, we
thereby allocate
∆E=Eresidual −Psys
Psolar
C(5)
for SolarStore to maximize the reliability gain Gain(∆E), at
the same time, with no additional data loss in data sensing
(i.e., Loss(∆E) = 0).
Following this allocation method, when the residual en-
ergy Eresidual is less than the threshold Psys
Psolar C, all energy
will be reserved for data sensing. Only when the residual
energy is above the threshold, the energy surplus (∆E=
Eresidual −Psys
Psolar C) can be used for enhancing data relia-
bility, at no expected additional cost in data sensing.
This allocation method requires the knowledge of Psys
and Psolar, which can be estimated online by using moving
335
averages. Let Pnew
sys and Pnew
solar be the latest samples for the
system power consumption rate and solar panel charging
rate respectively. The moving averages can be computed
by:
Psys = (1 −θsys )Psys +θsys Pnew
sys ,(6)
Psolar = (1 −θsolar )Psolar +θsolarPnew
solar,(7)
where the forgetting factor θsys (0 < θsys <1) and θsolar
(0 < θsys <1) controls how fast the historical samples
should be neglected. How to choose θsys and θsolar will be
addressed in Section 5.3, together with other implementa-
tion issues for SolarStore. Moreover, if a duty cycle schedul-
ing mechanism [13, 18] is employed to further save energy in
data sensing, its affect will be captured by the calculation
of Psys and then reflected during the energy allocation.
We emphasize that this solution is simple and general,
independent of physical models on node failure and weather
patterns. Although this solution may not be optimal, it can
guarantee that the system performance is never degraded
(i.e., Gain(∆E)−Loss(∆E) is always non-negative).
3.3 Storage Allocation
Similarly, the storage resource is renewed every time when
data are uploaded from the network. Thus, storage alloca-
tion can be performed in a similar way as the energy allo-
cation. Denote Mas the expected time from now to the
next upload opportunity. Then, a storage space of R·M
is needed to store the future sensory data, where Ris the
expected data sensing rate. Let Sresidual be the current
residual storage space left. When Sresidual is above R·M,
the storage surplus
∆S=Sresidual −R·M(8)
can be allocated for storing data replicas.
4. DATA ENCODING AND DISSEMINATION
Instead of using simple replication of data blocks, we use
fountain coding [20] for data replication. Generally, fountain
coding partitions a data block into kchunks and generates k0
(k0≥k) encoded chunks. The original data block is recover-
able if having a reasonable number of encoded chunks, usu-
ally (1+ε)kfor some small ε > 0. By working on data chunks
with finer granularity than data blocks, fountain coding can
achieve higher reliability than simple replication with the
same energy and storage requirements. For example, if k= 8
and k0= 12, the original data can be recovered with a very
high probability when receiving any 9 (i.e., k+ 1) out of
12 chunks. Then three nodes can fail without impacting
data recovered if data chunks are evenly distributed in the
network. Achieving the same level of reliability with sim-
ple replication requires making three replicas, or increasing
storage requirements by 300% (as opposed to only 50% in
the above scenario). Moreover, by partitioning each block
into smaller pieces, it also contributes amazingly to the load
balancing of the system.
LT codes (Luby Transform codes) [20] are a class of prac-
tical fountain codes that have been widely used. The dis-
tinguishing characteristic of LT codes is that they employ a
particularly simple algorithm based on the exclusive opera-
tion (⊕) to encode and decode the data, and hence are very
computationally efficient. Interested readers are referred to
[20] for the details of LT codes.
Three questions arise in this context. The first one is
where to scatter the encoded data chunks. The ideal sce-
nario is to distribute them evenly among all nodes in the
network. However, this requires that each node have a global
view of the network. Maintaining such a view is quite expen-
sive because the network is dynamic as nodes could die or
come alive later. Instead, we adopt a very simple heuristic
in which nodes only scatter data chunks to their neighboring
nodes. As will be explained later, those data chunks could
be further forwarded away by the neighbors if their energy
permits.
The second question is how many chunks should be scat-
tered out to each neighbor. Suppose a node has gneighbors
and g+ 1 ≤k0, chunks are scattered evenly so that there are
k0/(g+ 1) chunks on every neighbor and the node itself. If
g+ 1 > k0,k0−1 nodes are randomly picked from gneigh-
bors, and one data chunk is scattered to each of the k0−1
selected nodes and the last chunk is kept on the current node
itself. However, the neighborhood of a node is dynamic as
data dissemination on some of neighboring nodes might be
suspended or some neighboring nodes could fail completely.
Therefore, we introduce a mechanism to allow data chunks
to be redistributed again.
Hence, there comes the last question of when to redis-
tribute those encoded data chunks that were generated and
kept on a node in the first place or received from other nodes.
On each node, for each data block, let hbe the number of
data chunks stored on the node that were generated from
this data block. We define the reliability level for a data
block on a node as α=k0/h, which is the total number of
data chunks generated for this data block over the number
of data chunks stored on this node for this data block. Given
a constant k0used by LT codes, the lower the his, the fewer
chunks are stored on this node, and thus the more reliable
is this data block with regard to the possible failure of this
node. Note that, data blocks that have not been encoded
by LT codes yet have the lowest reliability level α= 1 since
k0=k= 1 for them. Based on the reliability level αof each
data block on a node, the averaged reliability ¯αfor all data
stored on this node can be calculated.
We sort the data blocks according to their reliability levels,
and select the data block with the lowest reliability level
to process first. If the data block has not been encoded
yet, then we encode it and scatter the encoded data chunks
evenly to neighbors as described before. If the data block has
been encoded before, then we randomly pick k0(1/α −1/¯α)
chunks from its hstored chunks, and scatter them evenly to
neighbors. Hence, the reliability level of this data block is
increased to the average reliability level ¯α. In order to avoid
sending a chunk back to the nodes where it has been stored
before, a list of nodes where this chuck has been stored is
maintained in each chunk, and nodes on the list are excluded
when scattering this chunk further.
If there is energy surplus ∆Eand storage surplus ∆S, a
node starts to listen on a specified port for incoming data
chunks from other nodes. When a data chunk is received, we
first retrieve the ID of its corresponding data block from the
meta information in its header, and then store it together
with other chunks generated from the same data block.
5. IMPLEMENTATION OF SOLARSTORE
While SolarStore is applicable to a wide array of solar-
powered sensing systems, we implemented and evaluated it
336
62
5
41
3
25m
9
7
8
Figure 1: Map of 9 deployed nodes.
Solar
Panels
Node
Enclosure
Antenna
Figure 2: Outside look of one node.
on a solar-powered sensor network testbed that we deployed
for intensive data acquisition experiments (e.g. recording
bird vocalizations in CD-quality). Currently, we have de-
ployed 9 nodes in a farm on the south campus of the Uni-
versity of Illinois at Urbana-Champaign. Figure 1 displays
the map of the current deployment. Figure 2 provides an
outside look at a node. Every component, except the solar
panels and the antenna, is packed in a waterproof enclosure.
The components inside of the enclosure are shown in Figure
3.
In this section, we first present the hardware components
of each node and how they provide information and control
required by SolarStore. We then describe the software ar-
chitecture of SolarStore, and finally address issues in its im-
plementation on the testbed. Interested readers are referred
to our project website [8] for more detailed information.
5.1 Hardware
In Figure 4, we sketch the basic components of each node,
which can be grouped into two subsystems: energy subsys-
tem and computing subsystem. We next describe them in
detail respectively.
5.1.1 Energy Subsystem
Each node is powered by one 12 Volt deep cycle battery
(DEKA 8G31) with a capacity of 98 AH. Although they look
like normal car batteries, deep cycle batteries are especially
designed for prolonged discharges at lower current, while car
batteries are designed for high initial cranking current for a
short time.
A set of two solar panels [7] are used on each node to
charge the battery, and the output of each panel is rated
Waterproof enclosure
EEE PC
WRT54GL
router
Router power
switch
Voltage¤t
sensors
Battery
Load controller Charge controller
Figure 3: Components inside of a node enclosure.
as 120 Watts. Note that, this wattage specification of so-
lar panels is rated under an ideal environment, where the
sun is directly overhead at local noon and the atmosphere
is clear and dry. The real output of the panels depends on
the season, the weather, the mounting angle, and the lati-
tude where they are going to be deployed. The location of
our deployment is at (40.10N, 88.20W). After a period of
calibration, we decided to use two panels to support each
node. Both panels are set facing south and have a 40oangle
with the ground. So they are approximately perpendicu-
lar to the sunlight during both spring and fall, which yields
higher yearly energy collection.
In order to avoid overcharging the battery and causing po-
tential electrical damage to the devices, a charge controller
(Xantrex C35 [9] in charge control mode) is used to regulate
the output voltage and current of the panels down to what
the battery needs at the time.
The whole computing subsystem draws power from the
battery, with a load controller (Xantrex C35 in load control
mode) sitting in between, which disconnects the circuit when
the battery is nearly empty to protect the battery from over
discharging.
5.1.2 Computing Subsystem
Since the testbed aims at supporting a wide spectrum of
applications, including very high-performance sensing and
processing (e.g., record CD-quality acoustic data at a rate of
705.6Kbps), we investigated several PCs, looking for power-
ful computing capabilities and reasonably large local storage
as well as high power efficiency. We eventually chose Asus
EEE PCs [1]. An EEE PC is equipped with an Intel 900
MHz CPU, 1GB DDR2, 20GB solid static disk and 3 USB
ports. It can run Linux or Windows. The PC consumes
only about 10 Watts under moderate load and 15 Watts
when heavily loaded (namely, 0.8 Ampere and 1.2 Ampere
respectively drained from the 12 Volt battery).
An EEE PC has a built-in wireless interface, which draws
about 2.4 Watts but has a very limited transmission range,
especially when sealed inside the waterproof enclosure. Hence,
we decided to use a stand-alone wireless device to provide
communication between nodes. The Linksys WRT54GL
337
Charge
Controller
Battery
Load
Controller
Current
Sensor
Voltage
Sensor
Phidget
Interface
EEE PC
WRT54GL
Antenna
Power Switch
...
Sensors
Data/Signal Power
Solar
Panels
Computing Subsystem Energy Subsystem
Figure 4: Basic components of each node.
router [2] was selected because of its low power consump-
tion (6 Watts) and support for third-party firmware, which
allows us to program the device. Moreover, its antenna is
detachable. By extending the antenna outside of the water-
proof enclosure, we achieved at least a 3 Mbps transmission
rate at a distance of 50 meters outdoors. For each Linksys
WRT54GL router, we update its firmware as openwrt [3],
a Linux distribution for embedded devices. Openwrt not
only provides more device customization choices, but also
supports running programs compiled for the MIPS archi-
tecture of WRT54GL. By using openwrt, we configure the
wireless interface of each router to work in an ad-hoc mode
with a static and unique virtual IP. We also assign a static
virtual IP (but in a different subnet from the ad-hoc wire-
less network) to the Ethernet interface of each EEE PC, and
connect it to the router’s Ethernet interface. On each EEE
PC, a permanent route is set for packets going to the ad-
hoc subnet using the router’s Ethernet interface as the next
hop. The router then checks its routing table and forwards
the packets accordingly for the EEE PC. A routing daemon
runs on each router to monitor active neighboring routers
and update its routing table. Besides, port forwarding is
setup on each router so that packets can be forwarded from
the ad-hoc subnet to EEE PCs.
Additional hardware is also employed to provide Solar-
Store the information required for energy management, such
as the remaining energy in the battery and the charging rate
from solar panels. The remaining energy of a battery can
be approximately indicated by its voltage. A Phidget preci-
sion voltage sensor [6] is wired in parallel with the battery
to measure its voltage. Details on how to infer the resid-
ual energy from the voltage are discussed in Section 5.3. In
the meantime, the charging current from the solar panels is
measured by a Phidget current sensor [4] in series between
the Charge Controller and the battery. Both the voltage
sensor and the current sensor are connected to a Phidget
InterfaceKit [5], which converts analog readings of the sen-
sors to digital and then feeds them to the EEE PC through
a USB port.
Applications
API
OS
Repository
Replicator
Receiver
Network Stack
Resource
Allocator
Data
Control/info
Battery Solar
Panel
SolarStore
Figure 5: Architecture of SolarStore.
Like other wireless devices, WRT54GL routers in idle mode
consume non-trivial power. Thus, SolarStore is allowed to
completely turn the router off when it is necessary to save en-
ergy. We note that turning on or off a WRT54GL router can
only be done through switching on or off its power supply.
Thus, we use a dual-coil latching relay, controlled through
the Phidget InterfaceKit, to connect or disconnect the power
supply of the router. The advantage of dual-coil latching re-
lays over normal relays is that they need only a short current
pulse instead of a continuous current in order to keep the cir-
cuit open or close, which leads to further energy savings.
It is not straightforward to reboot an EEE PC back on
after it shuts down when the battery is depleted. An auto
reboot timer on its motherboard can be used to wake up
an EEE PC. Therefore, we have a daemon running on each
EEE PC to refresh the auto reboot timer every 10 minutes,
while the the timer is set to 20 minutes. Hence, normally,
the timer will be reset before it goes off. If an EEE PC is
down because the battery is depleted, the timer will continue
counting down, freeze at zero, and immediately go off when
the power is back on. This way, the whole system can work
quite autonomously without need of maintenance.
5.2 Software Architecture of SolarStore
On the software side, SolarStore provides an adaptive re-
liable storage service to applications based on the status of
energy and storage resources. Blocks of data are passed by
applications to SolarStore through the defined APIs, and
then stored into a Repository, which is a piece of storage
space on the solid state disk managed by the operating sys-
tem.
AReplicator reads data blocks from Repository and en-
codes them into data chunks by using LT codes, and then
scatters the encoded data chunks as described in Section
4. A Receiver receives the encoded data chunks from other
nodes and stores them into Repository, organizing chunks
generated from the same data block together in one direc-
tory.
338
AResource Allocator (as summarized by the pseudo code
in Algorithm 1) monitors the status of energy and storage
resources and determines the energy and storage surpluses,
based on the solution proposed in Section 3. Replicator is
stared when there is energy surplus because it demands en-
ergy to encode the data blocks into data chunks and scatter
them to other nodes, while Receiver is only started when
both energy and storage surpluses are positive as it requires
both energy to receive and storage to store data chunks from
other nodes. The scattering of data chunks by Replicator on
a node also relies on Receiver on other nodes. One may sug-
gest that Replicator could go sleep for a while if it found no
live Receiver on other nodes. However, during its sleeping,
it may miss the working period of Receiver of others. As
a matter of fact, this idea deviates from the design prin-
ciple of solar-powered systems and the definition of energy
surplus, where nodes should be encouraged to spend their
energy surplus because of the renewable feature of solar en-
ergy. Therefore, Replicator and Receiver keep running until
energy surplus or storage surplus is used up. Furthermore,
as will be seen in Section 6, the behavior of SolarStore on
nodes even with different initial states will tend to become
cooperative, which then leads to more overlapped working
periods of Replicator and Receiver on different nodes.
Next, we will address some issues in the implementation
of SolarStore on our testbed.
Algorithm 1 Resource Allocator
1: while true do
2: Sample the status of Eresidual,Pnew
sys ,Pnew
solar and
Sresidual.
3: Update Psys = (1 −θsys )Psys +θsys Pnew
sys , and Psolar =
(1 −θsolar)Psolar +θsolar Pnew
solar.
4: Compute energy surplus ∆E=Eresidual −
Psys
Psolar
C, and
∆S=Sresidual −R·M.
5: if ∆E > 0then
6: Start Replicator
7: else
8: Stop Replicator
9: end if
10: if ∆E > 0 and ∆S > 0then
11: Start Receiver
12: else
13: Stop Receiver
14: end if
15: end while
5.3 Implementation Issues
The operation of SolarStore relies mainly on the status
of the two resources. The storage resource can be easily
measured, while obtaining the status of the residual energy
demands extra effort. As mentioned above, the remaining
energy of a battery can be approximately indicated by its
voltage. However, it is also affected by the charge controller.
Figure 6 shows the voltage variations over one day. We see
that the voltage decreased from 12.8 Volt at 12AM to 12.4
Volt at 6AM as the computing subsystem was drawing power
from the battery and there was no charging available from
solar panels in the night. After sunrise at 6AM, solar panels
started to charge the battery and the voltage continuously
increased to 14.0 Volt around 2PM. Thereafter, the battery
was fully charged and the voltage was sustained at 13.5 Volt
until the sunset at 7PM. After that, the charging stopped
and the voltage started to decrease again.
Figure 6: Voltage variations over 24 hours on Aug
9th 2008.
According to the specification of the charge controller
[9], the charge processing first enters a bulk charging phase
where voltage will increase until reaches 14.0 Volt when the
battery is nearly fully charged. Moreover, the load controller
disconnects the power when the voltage falls below 11.0 Volt.
Hence we use a linear approximation to estimate the current
residual energy, regarding 14.0 Volt as 100% and 11.0 Volt
as 0%. Second, after reaching 14.0 Volt, it enters a float
charging phase, where the battery stays at 13.5 Volt until
the charging ends. Therefore, after the bulk charging phase,
we regard 13.5 Volt instead of 14.0 Volt as the voltage for a
full battery and then use a linear approximation to estimate
the residual energy.
We use a Phidget precision voltage sensor with a reso-
lution of 0.06Vto accurately measure the residual energy.
In addition, the charging rate from the solar panels is sam-
pled by a Phidget current sensor, while the discharge rate is
inferred from changes in the residual energy of the battery
and the charging rate. The sampling period of the sensors is
set to be small (3 seconds in the current implementation) in
order to gain high accuracy. Even though the variations in
the charging current are smoothed by the moving average,
it is still possible to witness churns of energy surplus be-
tween positive and negative, especially when it is very close
to zero. Thereby, we use a large (30 minutes in the current
implementation) working period for the Resource Allocator
in order to avoid frequent churns between powering on and
off the router when energy surplus is close to zero. This
way, the system status is sampled frequently for the sake of
accuracy, while decisions are made at a lower frequency for
the sake of stability.
Another issue in the implementation is to choose the for-
getting factors θsolar and θsys to calculate the moving aver-
ages of the charging rate Psolar and discharging rate Psys.
Since SolarStore aims at perpetual systems that operate for
a really long time, the forgetting factors should be small so
that the historical samples influence the averages for a long
period. Suppose we like the sample at Htime ago to have a
weight of ψin the moving average, then the forgetting fac-
tor θshould satisfies (1 −θ)Hλ =ψ, namely θ= 1 −ψ1/H λ,
where λis the sampling rate. Considering that solar energy
339
EEE PC
X10
Controller
X10 Modules
PC-controlled
switch
WRT54GL Router
Current Sensors
Figure 7: Each node in the indoor testbed has the
same computing subsystem as nodes outdoors, while
the energy subsystem is emulated by using current
sensors, X10 modules and controller, and real solar
energy traces collected outdoor.
varies a lot from daytime to night, Hshould be at least
one day. Furthermore, impact of weather changes in a short
period of time should also be smoothed out. On the other
side, Hcould not be too large in order to respond to slight
changes in the climate and seasons. To this end, we use
H= 5 days and ψ= 0.1 in the current implementation.
Choosing parameters kand k0for Replicator could also be
tactical. Replicator divides a data block into kpieces and
then encodes them into k0chunks. The smaller k, the finer
granularity of the replication, and thus the more reliability
levels available for Replicator. On the other hand, shifting
data chunks to other nodes is in units of data chunks, which
could lead to higher transmission overhead if data chunks
are too small because of a large k. Therefore kshould be
carefully selected to trade off between replication granularity
and transmission overhead. Meanwhile, the higher the k0is,
the higher the reliability level that can be achieved. This is
also limited by the total available storage space Smax . Note
that, upload opportunities appear with an expected period
of Mand the expect data sensing rate is R, thus k0should
satisfy k0≤Smax
RM kin order to mitigate data loss in data
sensing.
6. PERFORMANCE EVALUATION
Experimental results on the testbed greatly depend on the
outdoor environment, especially weather conditions during
the experiments. Because SolarStore is designed for solar-
powered systems with a long time of operation, it is difficult,
if not impossible, to have repeated weather conditions so as
to compare SolarStore with other schemes. Moreover, given
the fixed location of our testbed, some environmental con-
ditions may never be attained locally. Therefore, an indoor
solar system testbed has been set up to conduct a fair per-
formance evaluation under a wide range of environmental
conditions. This section shows results from both testbeds.
6.1 Indoors Testbed
Figure 7 is a snapshot of 9 nodes in our indoor testbed.
The computing subsystem of each node is a clone of the one
in the outdoor testbed, including an EEE PC, a Linksys
WRT54GL wireless router and a PC-controlled power switch.
As for the energy subsystem, a solar panel emulator is
used to emulate the charging current from solar panels based
on real solar energy traces collected on the outdoor testbed.
Taking the charging current as one of its inputs, and leverag-
ing Phidget current sensors to obtain the power consump-
tion rate of the computing subsystem, a battery emulator
maintains the residual energy level of the battery for each
node. Even though nodes are now powered by normal in-
door AC supplies, the battery emulator will disconnect the
AC power for a node if the residual energy in its emulated
battery reaches zero, and connect the power back on when
the residual energy becomes positive again.
The automatic control of the AC power supply for each
node is realized through X10 modules, which are typically
used to control appliances in smart houses. The AC/DC
power adapter of each node connects to an X10 module first
before being plugged into an AC outlet. Each X10 mod-
ule listens for incoming X10 commands from the power line,
and then switches the circuit on/off if X10 on/off commands
addressed to this module are received. In addition, an X10
controller is used by the battery emulator to issue X10 com-
mands onto the power line.
With regard to communication, since the data chunk ex-
change between nodes in SolarStore is implemented over
TCP, we focus on emulating the TCP bandwidth of the out-
door links in the indoor testbed. Our goal is not to induce
outdoor interference characteristics and loss distributions in
an indoor setting, as that would be impossible and unneces-
sary for our experiments, but merely to construct a topology
with bandwidths representative of the outdoors. The nodes
in the indoor testbed are all within one hop of each other, so
we leverage MAC address filters on the WRT54GL routers
to form exactly the same network topology as measured in
the outdoor testbed (Figure 1). Furthermore, we decrease
the routers’ transmit power to induce enough packet losses
to bring TCP throughput to 3.0Mbps to 4.5Mbps, the same
range as in our outdoor links.
6.2 Experimental Setup
In our performance evaluation, we consider a sensing ap-
plication that collects bird vocalizations at 220500Hz and
16 bits per sample for environmental studies of bird popu-
lations and social behavior. This, in fact, is the real appli-
cation that motivated the outdoor deployment. The data
are being used by colleagues in the department of natural
history at the University of Illinois at Urbana-Champaign.
We run each experiment for a period of 15 days. As shown
in Figure 8, real traces collected from the outdoor testbed
during Oct 21st – Nov 4th are used to emulate the solar en-
ergy input for the nodes indoors. Note that the solar energy
harvesting traces on different nodes are very similar because
the testbed is deployed in a farm-wide area where all nodes
share almost the same weather conditions. The figure also
shows the total amount of solar energy collected daily in
units of Ampere Hour (AH), which equals the current flow
in amperes multiplied by the time of flow in hours, and is
frequently used in measurements of electrical systems that
output a relatively stable voltage compared to the current.
During the experiments, the application on a node always
runs to record acoustic data unless the node is shut down
when its battery is empty. The emulated battery of each
node has a capacity of 98AH; the same as the DEKA 8G31
battery used outdoors. Each node has a 18GB space on its
solid state disk to buffer the sensory data. A data mule ar-
rives every 3 days to collect all the recorded acoustic data
340
Figure 8: Charging current from solar panels during Oct 21st – Nov 4th 2008. Total energy collected daily
in units of Ampere Hour is also shown.
(a) Node 2 with Eresidual = 19.6AH initially (b) Node 9 with Eresidual = 88.2AH initially
Figure 9: Residual energy Er esidual and the threshold Psys
Psolar Cduring the 15 days’ experiment.
(a) Node 2 with Eresidual = 19.6AH initially (b) Node 9 with Eresidual = 88.2AH initially
Figure 10: Changes of the residual storage space Sr esidual and storage surplus ∆Sduring the 15 days’ experi-
ment.
341
from every node. Considering the large amount of data gen-
erated by the application, the data mule uses USB cables,
instead of wireless communication, to connect to the nodes
to copy the data. Thus, the time and energy used to upload
the data from each node to the data mule are negligible.
As discussed in Section 5.3, in order to avoid frequent
churns between switching the router on and off, the working
period of SolarStore is set to 30 minutes, while the system
status sampling period is 3 seconds. We use H= 5 days and
ψ= 0.1 to determine the forgetting factor θsys and θsolar
for the moving averages, and choose k= 8 and k0= 12 for
LT codes.
Next, using the solar energy traces collected locally, we
study the behavior of SolarStore under different energy con-
ditions. Then, we show that SolarStore can also adapt to
other (more extreme) environmental conditions. Finally, we
compare SolarStore to three other schemes under different
node failure scenarios.
6.3 Experimental Results
6.3.1 Behavior study under different energy states
In order to study SolarStore under different energy condi-
tions, we start each experiment with nodes having different
initial energy in their batteries, evenly distributed between
10% to 90% of the battery capacity.
Figure 9 demonstrates how the residual energy Eresidual
and the threshold Psys
Psolar Cvary under SolarStore for 2 nodes
with very different initial amount of energy. For your refer-
ence, the charging current from solar panels is also shown in
the figure. For the sake of presentation, energy surplus ∆Eis
not plotted but can be inferred by ∆E=Eresidual −Psys
Psolar C.
In the experiments, node 2 starts with a very low energy in
its battery. For the first 9 days, its residual energy Eresidual
is always below the threshold Psys
Psolar C, and thus SolarStore
allocates no energy for enhancing data reliability but re-
serves all energy for data sensing. When Eresidual eventually
reaches above Psys
Psolar Con the 10th day, Replicator and Re-
ceiver (having storage surplus as well) begin to work. Then
the energy is consumed in a faster rate, and Replicator and
Receiver stop working after a few hours when Eresidual falls
below Psys
Psolar Cagain. In each of the following days, there are
always a few hours when Eresidual ≥Psys
Psolar C, and thus en-
ergy is allocated for improving data reliability during these
periods of time. SolarStore on node 9 has similar behav-
ior, except that there is energy surplus in the first two days
because node 9 starts with an almost fully charged battery.
Comparing SolarStore on node 2 and node 9, even though
they behave differently in the beginning because of the dif-
ferent initial states, the residual energy and the threshold
trend to converge to some extent after a few days. There-
fore, from the perspective of a perpetual system, the behav-
ior of SolarStore in a long run does not depend on the initial
state.
Next, Figure 10 illustrates the changes in the residual stor-
age space Sresidual and storage surplus ∆Sof node 2 and
node 9 over the 15 days. A data mule comes every 3 days to
collect all the data. Thus, the storage is renewed once every
3 days. As in Figure 10 (b), during the first two days, nodes
9 has a storage surplus, and also has an energy surplus for
most time as shown in Figure 9 (b). Thus its Replicator
and Receiver start working, and then the storage surplus is
Figure 11: Average reliability level ¯αof the data on
node 9.
gradually consumed by data replicas. In the next 3 days,
the storage surplus remains relatively constant since Repli-
cator and Receiver are sleeping during this period due to the
shortage of energy as shown in Figure 9 (b). Starting from
the 8th day, Replicator and Receiver wake up to work for a
few hours everyday. As shown in Figure 9 (a), the situation
on node 2 is similar to node 9, except that the time when
Replicator and Receiver start working is later since the ini-
tial Eresidual of node 2 is lower. Note that an increase of
∆Scould happen when data chunks sent out by Replicator
are more than those received by Receiver. And how to coor-
dinate energy sharing between Replicator and Receiver will
be addressed in our subsequent work.
Figure 11 shows the average reliability level ¯αof the data
on node 9 over the 15 days. Recall that the reliability level
for raw data is 1. Several observations are in order. First,
in the beginning of the experiment, node 9 starts Replicator
and Receiver, and then ¯αsoars from 1 to over 11. The
reason of this steep increase is that only little data has been
collected and stored locally so far. As we can see, this also
happens every time after the data are retrieved by the data
mule. Second, from day 3 to day 8, ¯αremains one since
Replicator and Receiver are turned off due to negative ∆E.
Third, after day 9, ¯αis roughly controlled between 2 and 4,
and trends to converge as the time goes on.
The average reliability levels ¯αof all 9 nodes after 15 days
are shown in Table 1. Even though nodes start with very
different energy states, the achieved reliability levels on the
9 nodes are comparable, falling between 2.9 and 4.2. On
average, the data reliability is about 3.56, which means that
there are averaged k0/3.51 = 3.37 encoded chunks for each
data block stored on a node. Thus k0−3.42 = 8.63 chunks
will still be retrievable even if one node is completely dead.
According to fountain coding, the original data blocks are
still recoverable as 8.63 > k.
6.3.2 Adaptation to other environments
In order to study how SolarStore adapts to other environ-
ments, especially under some extreme environmental condi-
342
Node 1 2 3 4 5 6 7 8 9
¯α3.3 4.1 3.2 3.4 2.9 3.6 4.2 3.9 3.4
Table 1: Node Average Reliability Level
Figure 12: Residual energy Er esidual and the thresh-
old Psys
Psolar Cof node 9 under a highly skewed solar
energy input.
tions, we emulate an extreme solar energy input based on
the one used in the previous experiment. We enlarge the
charging current by 3 times for one day every three days.
And for the other two days in each cycle, we multiply it by
a factor of 0.2. This way, solar energy input for SolarStore is
highly skewed. We start the experiment with a fully charged
battery for every node.
In Figure 12, we see that SolarStore adjusts the threshold
Psys
Psolar Caccording to the solar input, increasing it slowly
during the days of poor weather and decreasing it quickly to
a reasonable level when a large amount of energy is charged
into the battery. Figure 13 shows how the residual storage
and the storage surplus vary during the experiment. The
storage surplus remains roughly the same during days of
bad weather, and is used up quickly during those extremely
“sunny”days because during that time nodes are encouraged
to spend energy on enhancing data reliability.
6.3.3 Comparison to three other schemes
Next, we evaluate the performance of SolarStore in en-
hancing data reliability, comparing to three other schemes:
(1) 0-Reliable has no data replication at all and uses all
energy and storage space for data sensing; (2) 1-Reliable al-
ways replicates data to maximize data reliability; and (3)
full-Reliable only starts data replication when the battery
is nearly full (99%) because the energy charged from solar
panels will be wasted if not used. We conduct the experi-
ments under three node failure scenarios, in each of which
1, 2, or 3 nodes are randomly chosen to be dead right at
the end of each experiment. Recall that there are two types
of data loss. One is in data sensing during energy black-
out, while the other one is the data that are on failed nodes
and cannot be recovered as no enough chunks are found on
Figure 13: Changes of the residual storage space
Sresidual and storage surplus ∆Sof node 9 under a
highly skewed solar energy input.
other working nodes. All experiments are conducted under
the same solar energy conditions as shown earlier in Figure
8.
Figure 14 shows the total data loss of the four different
storage schemes under the 3 different node failure scenarios.
In the figure, results are first grouped based on the number of
failed nodes. Then in each group, 4 bars represent the total
data loss for the 4 schemes as labeled. The data loss in each
case further breaks down into the two types. As we can see,
SolarStore has the lowest total data loss in all cases. Even
though 1-Reliable achieves the best in recovering data from
node failures, its overall performance is lower because of the
severe data loss during energy blackouts. On the contrary,
0-Reliable has no replication and recovery mechanism, and
thus has the worst data loss caused by node failures. Even
though full-Reliable improves the data reliability to some
extent, it still suffers at least 58% more data loss comparing
to SolarStore, since it is too conservative in energy allocation
for data reliability. This experiment justifies our design and
illustrates the efficacy of mechanisms described in this paper.
7. CONCLUSION AND FUTURE WORK
In this paper, we developed a storage service, called So-
larStore, for solar-powered storage-centric sensor networks.
Taking into account the renewable and dynamic nature of
solar energy, SolarStore adaptively balances between data
reliability and data sensing, in order to improve the total
amount of data that can be eventually retrieved from the
network.
We formulate the retrievable data maximization as an op-
timization problem, and propose a simple and effective solu-
tion, which is independent of physical models of node failure
and weather patterns. In spite of the fact that this solution
might not be optimal, it guarantees good system perfor-
mance. Deployment results show that SolarStore dynami-
cally responds to variations in the environment, and has at
least 58% less data loss compared to three baseline schemes
in different node failure scenarios.
SolarStore has many avenues for extension. First, models
343
Figure 14: The total data loss, caused by blackout
and node failure, in the case that 1, 2 or 3 nodes
failed.
of node failure and weather patterns can be utilized to im-
prove the performance of the resource allocation. Second,
algorithms to coordinate energy sharing can be refined. As
a future work, we will continue to test SolarStore on the
outdoor testbed. In the near future, we plan to deploy 20
more nodes outdoors, and extend the testbed into a power-
ful, convenient and open facility for the research community.
8. REFERENCES
[1] Asus EEE PC 900. http://eeepc.asus.com/global/.
[2] Linksys WRT54GL, Linux Compatible.
http://www.linksys.com.
[3] Openwrt. http://openwrt.org/.
[4] Phidget Current Sensor. http://www.phidgets.com/
products.php?product id=1119.
[5] Phidget InterfaceKit. http://www.phidgets.com/
products.php?product id=1018.
[6] Phidget Precision Voltage Sensor.
http://www.phidgets.com/products.php?product id=1123.
[7] Solar Panel.
http://www.mrsolar.com/page/MSOS/PROD/pallet/
XC110HalfPallet.
[8] SouthFarm project website.
http://cyphy4.cs.uiuc.edu/web/.
[9] Xantrex C35. http://www.xantrex.com/web/id/71/p
/1/pt/25/product.asp.
[10] Cesare Alippi and Cristian Galperti. An adaptive
system for optimal solar energy harvesting in wireless
sensor network nodes. In IEEE Transactions on
Circuits and Systems, 2008.
[11] A. Arora, R. Ramnath, E. Ertin, P. Sinha, S. Bapat,
V. Naik, V. Kulathumani, H. Zhang, H. Cao,
M. Sridharan, S. Kumar, N. Seddon, C. Anderson,
E. Herman, N. Trivedi, C. Zhang, M. Nesterenko,
R. Shah, S. Kulkarni, M. Aramugam, L. Wang,
M. Gouda, Y. Choi, D. Culler, P. Dutta, C. Sharp,
G. Tolle, M. Grimmer, B. Ferriera, and K. Parker.
Exscal: Elements of an extreme scale wireless sensor
network. In RTCSA ’05, pages 102–108, Washington,
DC, USA, 2005.
[12] Neerja Bhatnagar and Ethan L. Miller. Designing a
secure reliable file system for sensor networks. In
StorageSS07, 2007.
[13] Qing Cao, Tarek Abdelzaher, Tian He, and John
Stankovic. Towards optimal sleep scheduling in sensor
networks for rare-event detection. In IPSN ’05,
Piscataway, NJ, USA, 2005.
[14] Tian He, Sudha Krishnamurthy, Liqian Luo, Ting
Yan, Lin Gu, Radu Stoleru, Gang Zhou, Qing Cao,
Pascal Vicaire, John A. Stankovic, Tarek F.
Abdelzaher, Jonathan Hui, and Bruce Krogh.
Vigilnet: An integrated sensor network system for
energy-efficient surveillance. ACM Trans. Sen. Netw.,
2(1):1–38, 2006.
[15] Xiaofan Jiang, Joseph Polastre, and David Culler.
Perpetual environmentally powered sensor networks.
In IPSN ’05, page 65, Piscataway, NJ, USA, 2005.
[16] A. Kansal, J. Hsu, , M. Srivastava, and
V. Raghunathan. Harvesting aware power
management for sensor networks. In DAC, 2006.
[17] Song Lin, Benjamin Arai, and Dimitrios Gunopulos.
Reliable hierarchical data storage in sensor networks.
In SSDBM ’07, page 26, Washington, DC, USA, 2007.
[18] Hai Liu, P. Wan, C.-W. Yi, Xiaohua Jia, S. Makki,
and N. Pissinou. Maximal lifetime scheduling in sensor
surveillance networks. In INFOCOM ’05, 2005.
[19] Ting Liu, Christopher M. Sadler, Pei Zhang, and
Margaret Martonosi. Implementing software on
resource-constrained mobile sensors: experiences with
impala and zebranet. In MobiSys ’04, pages 256–269,
New York, NY, USA, 2004.
[20] M. Luby. LT codes. In In IEEE Symposium on the
Foundations of Computer Science (FOCS), 2002.
[21] Liqian Luo, Qing Cao, Chengdu Huang, Tarek
Abdelzaher, John A. Stankovic, and MichaelWard.
Enviromic: towards cooperative storage and retrieval
in audio sensor networks. In ICDCS, 2007.
[22] Liqian Luo, Chengdu Huang, Tarek Abdelzaher, and
John A. Stankovic. Envirostore: A cooperative storage
system for disconnected operation in sensor networks.
In INFOCOM ’07, pages 1802–1810, Achorage, AK,
USA, 2007.
[23] Gaurav Mathur, Peter Desnoyers, Deepak Ganesan,
and Prashant Shenoy. Capsule: an energy-optimized
object storage system for memory-constrained sensor
devices. In SenSys ’06, pages 195–208, New York, NY,
USA, 2006.
[24] Donggeon Noh, Dongeun Lee, and Henonshik Shin.
Qos-aware geographic routing for solar-powered
wireless sensor networks. IEICE Transactions on
Communications, 2007.
[25] Donggeon Noh, Ikjoon Yoon, and Henonshik Shin.
Low-latency geographic routing for asynchronous
energy-harvesting wsns. International Journal of
Networks, 2008.
[26] Vijay Raghunathan, Aman Kansal, Jason Hsu,
Jonathan Friedman, and Mani Srivastava. Design
considerations for solar energy harvesting wireless
embedded systems. In IPSN/SPOTS, 2005.
[27] S. Roundry, B. Otis, Y. H. Chee, J. Rabaey, and
P. Wright. A 1.9GHz RF transmit beacon using
environmentally scanenged energy. In ISLPED, 2003.
344
[28] Christopher M. Sadler and Margaret Martonosi. Dali:
A communication-centric data abstraction layer for
energy-constrained devices in mobile sensor networks.
In Mobisys, 2007.
[29] Jacob Sorber, Alexander Kostadinov, Matthew
Garber, Matthew Brennan, Mark D. Corner, and
Emery D. Berger. Eon: a language and runtime
system for perpetual systems. In SenSys ’07, pages
161–174, New York, NY, USA, 2007.
[30] Robert Szewczyk, Alan Mainwaring, Joseph Polastre,
John Anderson, and David Culler. An analysis of a
large scale habitat monitoring application. In SenSys
’04, pages 214–226, New York, NY, USA, 2004.
[31] Jay Taneja, Jaein Jeong, and David Culler. Design,
modeling, and capacity planning for micro-solar power
sensor networks. In IPSN, 2008.
[32] Gilman Tolle, Joseph Polastre, Robert Szewczyk,
David Culler, Neil Turner, Kevin Tu, Stephen
Burgess, Todd Dawson, Phil Buonadonna, David Gay,
and Wei Hong. A macroscope in the redwoods. In
SenSys ’05, pages 51–63, New York, NY, USA, 2005.
[33] C. M. Vigorito, D. Ganesan, and A. G. Barto.
Adpative control of duty cycling in energy-harvesting
wireless sensor networks. In SECON, 2007.
[34] Thiemo Voigt, Hartmut Ritter, and Jochen Schiller.
Utilizing solar power in wireless sensor networks. In
LCN, 2003.
345
