Zephyr: Efcient Incremental Reprogramming of Sensor Nodes using
Function Call Indirections and Difference Computation
Rajesh Krishna Panta, Saurabh Bagchi, Samuel P. Midkiff
School of Electrical and Computer Engineering, Purdue University

rpanta,sbagchi,smidkiff
@purdue.edu
Abstract
Wireless reprogramming of sensor nodes is an essential
requirement for long-lived networks since the software
functionality changes over time. The amount of infor-
mation that needs to be wirelessly transmitted during
reprogramming should be minimized since reprogram-
ming time and energy depend chiefly on the amount of
radio transmissions. In this paper, we present a multi-
hop incremental reprogramming protocol called Zephyr
that transfers the delta between the old and the new soft-
ware and lets the sensor nodes rebuild the new software
using the received delta and the old software. It reduces
the delta size by using application-level modifications to
mitigate the effects of function shifts. Then it compares
the binary images at the byte-level with a novel method
to create small delta, that is then sent over the wireless
network to all the nodes. For a wide range of software
change cases that we experimented with, we find that
Zephyr transfers 1.83 to 1987 times less traffic through
the network than Deluge, the standard reprogramming
protocol for TinyOS, and 1.14 to 49 times less than an
existing incremental reprogramming protocol by Jeong
and Culler.
1 Introduction
Large scale sensor networks may be deployed for long
periods of time during which the requirements from the
network or the environment in which the nodes are de-
ployed may change. This may necessitate modifying the
executing application or retasking the existing applica-
tion with different sets of parameters, which we will col-
lectively refer to as reprogramming. Once deployed, it
may be very difficult to manually reprogram the sensor
nodes because of the scale (possibly hundreds of nodes)
and the embedded nature of the deployment since the
nodes may be situated in places which are difficult to
reach physically. The most relevant form of reprogram-
ming is remote multi-hop reprogramming using the wire-
less medium which reprograms the nodes as they are em-
bedded in their sensing environment. Since the perfor-
mance of the sensor network is greatly degraded, if not
reduced to zero, during reprogramming, it is essential to
minimize the time required to reprogram the network.
Also, as the sensor nodes have limited battery power, en-
ergy consumption during reprogramming should be min-
imized. Since reprogramming time and energy depend
chiefly on the amount of radio transmissions, the repro-
gramming protocol should minimize the amount of in-
formation that needs to be wirelessly transmitted during
reprogramming.
In practice, software running on a node evolves, with
incremental changes to functionality, or modification of
the parameters that control current functionality. Thus
the difference between the currently executing code and
the new code is often much smaller than the entire code.
This makes incremental reprogramming attractive be-
cause only the changes to the code need to be transmitted
and the entire code can be reassembled at the node from
the existing code and the received changes. The goal of
incremental reprogramming is to transfer a small delta
(difference between the old and the new software) so that
reprogramming time and energy can be minimized.
The design of incremental reprogramming on sensor
nodes poses several challenges. A class of operating sys-
tems, including the widely used TinyOS [1], does not
support dynamic linking of software components on a
node. This rules out a straightforward way of transfer-
ring just the components that have changed and linking
them in at the node. The second class of operating sys-
tems, represented by SOS [6] and Contiki [5], do sup-
port dynamic linking. However, their reprogramming
support also does not handle changes to the kernel mod-
ules. Also, the specifics of the position independent code
strategy employed in SOS limits the kinds of changes to
a module that can be handled. In Contiki, the require-
ment to transfer the symbol and relocation tables to the
node for runtime linking increases the amount of traffic

that needs to be disseminated through the network.
In this paper, we present a fully functional incremen-
tal multi-hop reprogramming protocol called Zephyr. It
transfers the changes to the code, does not need dynamic
linking on the node and does not transfer symbol and
relocation tables. Zephyr uses an optimized version of
the Rsync algorithm [20] to perform byte-level compar-
ison between the old and the new code binaries. How-
ever, even an optimized difference computation at the
low level can generate large deltas because of the change
in the positions of some application components. There-
fore, before performing byte-level comparison, Zephyr
performs application-level modifications, most impor-
tant of which is function call indirections, to mitigate the
effects of the function shifts caused by software modifi-
cation.
We implement Zephyr on TinyOS and demonstrate
it on real multi-hop networks of Mica2 [2] nodes and
through simulations. Zephyr can also be used with SOS
or Contiki to upload incremental changes within a mod-
ule. We evaluate Zephyr for a wide range of software
change cases,—from a small parameter change to almost
complete application rewrite—, using applications from
the TinyOS distribution and various versions of a real
world sensor network application called eStadium [3] de-
ployed at the Ross-Ade football stadium at Purdue Uni-
versity. Our experiments show that Deluge [7], Stream
[16], and the incremental protocol by Jeong and Culler
[8] need to transfer up to 1987, 1324, and 49 times more
number of bytes than Zephyr, respectively. This trans-
lates to a proportional reduction in reprogramming time
and energy for Zephyr. Furthermore, Zephyr enhances
the robustness of the reprogramming process in the pres-
ence of failing nodes and lossy or intermittent radio links
typical in sensor network deployments due to signifi-
cantly smaller amount of data that it needs to transfer
across the network.
Our contributions in this paper are as follows: 1) We
create a small-sized delta for dissemination using opti-
mized byte-level comparisons. 2) We design application-
level modifications to increase the structural similar-
ity between different software versions, also leading to
small delta. 3) We allow modification to any part of the
software (kernel plus user code), without requiring dy-
namic linking on sensor nodes. 4) We present the design,
implementation and demonstration of a fully functional
multi-hop reprogramming system. Most previous work
has concentrated on some of the stages of the incremen-
tal reprogramming system, but not delivered a functional
complete system.
2 Related work
The question of reconfigurability of sensor networks has
been an important theme in the community. Systems
such as Mate [10] and ASVM [11] provide virtual ma-
chines that run on resource-constrained sensor nodes.
They enable efficient code updates, since the virtual ma-
chine code is more compact than the native code. How-
ever, they trade off, to different degrees, less flexibility in
the kinds of tasks that can be accomplished through vir-
tual machine programs and less efficient execution than
native code. Zephyr can be employed to compute incre-
mental changes in the virtual machine byte codes and is
thus complementary to this class.
TinyOS is the primary example of an operating system
that does not support loadable program modules. Sev-
eral protocols provide reprogramming with full binaries,
such as Deluge [7] and Stream [16]. For incremental re-
programming, Jeong and Culler [8] use Rsync to com-
pute the difference between the old and new program
images. However, it can only reprogram a single hop
network and does not use any application-level modifi-
cations to handle function shifts. We compare the delta
size generated by their approach and use it with an exist-
ing multi-hop reprogramming protocol to compare their
reprogramming time and energy with Zephyr. In [19],
the authors modify Unix’s diff program to create an edit
script to generate the delta. They identify that a small
change in code can cause a lot of address changes result-
ing in a large size of the delta. Koshy and Pandey [9] use
slop regions after each function in the application so that
the function can grow. However, the slop regions lead to
fragmentation and inefficient usage of the Flash and the
approach only handles growth of functions up to the slop
region boundary. The authors of Flexcup [13] present
a mechanism for linking components on the sensor node
without support from the underlying OS. This is achieved
by sending the compiled image of only the changed com-
ponent along with the new symbol and relocation tables
to the nodes. This has been demonstrated only in an em-
ulator and makes extensive use of Flash. Also, the sym-
bol and relocation tables can grow very large resulting in
large updates.
Reconfigurability is simplified in OSes like SOS [6]
and Contiki [5]. In these systems, individual modules
can be loaded dynamically on the nodes. Some mod-
ules can be quite large and Zephyr enables the upload of
only the changed portions of a module. Specific chal-
lenges exist in the matter of reconfiguration in individual
systems. SOS uses position independent code and due
to architectural limitations on common embedded plat-
forms, the relative jumps can only be within a certain
offset (such as 4 KB for the Atmel AVR platform). Con-
tiki disseminates the symbol and relocation tables, which
may be quite large (typically these tables make up 45%
to 55% of the object file [9]). Zephyr, while currently
implemented in TinyOS, can also support incremental
reprogramming in these OSes by enabling incremental