A Network Application Programming Interface
for Data Processing in Sensor Networks
Rice University Technical Report TREE0705
Raymond Wagner, J. Ryan Stinnett, David B. Johnson,
Marco Duarte, Richard Baraniuk T. S. Eugene Ng
Dept. of Electrical and Computer Engineering Dept. of Computer Science
Rice University Rice University
ABSTRACT tached to the Internet), features a unique energy economics
Since the inception of sensor networks, a wide variety of algo- which encourages the development of applications with dis-
rithms for in-network data processing have emerged. To en- tributed components. That is, application designers often
able practical implementation of a broad class of these pro- prefer localized collaboration among nodes and in-network
posed algorithms, suﬃcient application programming sup- processing of data to long-haul transport of data to a central
port for network communications is critical. While standard location for conventional processing. And while an abun-
(but relatively low-level) network application programming dance of creative distributed algorithms have been proposed,
interfaces (APIs) such as those implemented in TinyOS can a great deal still occupy the realm of theory. The in-network
provide a basis for ﬂexible application-speciﬁc customiza- collaborations require by these algorithms induce a variety
tion, experience in the past several years has shown that of network communication patterns, many of which are not
data processing algorithms in fact share similar higher level supported by standard sensor network programming tools
communication needs that can be better supported. such as TinyOS . And since many algorithm designers do
In this paper, we ﬁrst identify common communication not have the backgrounds necessary to develop the network
patterns through an extensive survey of data processing communication protocols they need using TinyOS building
algorithms proposed over the past four years in the pro- blocks, many of their designs go untested in real sensor net-
ceedings of the Information Processing in Sensor Networks work environments. Thus, many algorithm developers are
(IPSN) conference. We then present the design of a higher unable to ascertain the true practicality of their designs and
level network API for sensor networks that is powerful, con- identify and correct possible ﬂaws exposed by the complex
venient to use, and compact. Many familiar issues in tra- operating environments of real-world deployments.
ditional networking such as addressing and reliability have What these researchers lack is a network programming ab-
vastly diﬀerent solutions in the sensor network environment, straction to allow them to implement their designs without
and we carefully develop the rationales behind the design concerning themselves with the underlying network services
of the resulting network API, providing an in-depth dis- to support the communications they require.
cussion on the fundamental design decisions. We believe We believe the time is right to design a network applica-
that the proposed network API serves as a starting point for tion programming interface (API) that provides access to a
the implementation of a more comprehensive sensor network suitable set of abstract network services for data processing
communication middleware than what is found in currently in sensor networks. An API is not a speciﬁc implementa-
available systems, enabling algorithm developers to quickly tion of these abstract services. Rather, an API provides a
and easily implement their designs without having to handle portal through which an application accesses the abstract
low-level networking details themselves. services. Deﬁning the API is a crucial intellectual exercise,
since the API is the part of the system that is the most dif-
ﬁcult to change over time; any change to the API requires
1. INTRODUCTION application programs to be re-written. In contrast, the im-
Sensor networks pose an incredible variety of research plementation of an abstract service is relatively changeable.
challenges to the community that is working to make such For example, the implementation of a multi-hop datagram
systems a reality. During the relatively few years in which service can change from using link state routing to distance
sensors networks have been actively studied, a great deal of vector routing transparently.
progress has been made toward designing sensor node hard- Designing a suitable network API requires solid knowledge
ware, creating data processing applications to run on nodes, of the applications’ communication needs. Fortunately, the
and developing the programming and networking interfaces plethora of sensor network applications and algorithms pro-
to unite applications with hardware. There is, however, a posed to date provide strong guidance. Moreover, ad hoc
growing disconnect between the latter two endeavors that wireless network algorithms and protocols have matured in
must be addressed to sustain the growth of sensor networks recent years, so the basic technologies necessary for imple-
into a mature technology. menting the abstract services are available. Starting with
It is widely recognized that the sensor network model, these observations, this paper addresses the problem of de-
which consists of a wireless ad-hoc network of sensor nodes signing a suitable network API for sensor networking. Our
connected to one or more sink nodes (that are perhaps at- primary goals are to expose the technical trade-oﬀs between
diﬀerent API design choices and to propose a speciﬁc API Broadcast of a message is common, either to all of a node’s
that is suﬃciently powerful, convenient to use, compact, and immediate neighbors within wireless transmission range [2–
realizable with existing technologies. We intentionally leave 5, 10, 16, 18, 19, 29, 31, 34, 36, 38] or to all neighbors within
out implementation issues such as software architecture or a larger number of radio hops [2, 14, 29]. This notion is
system performance evaluation. We expect future work to extended in several applications to sending a message to all
explore and evaluate diﬀerent implementation choices for nodes within a geographic radius of the sender [1, 4, 14, 34].
realizing the proposed API. Finally, a number of applications wish to send a message
Our contributions in this paper are two-fold. First, we to nodes within an arbitrary region of space not centered
conduct a survey of the distributed data processing algo- around the sender [13, 14, 23, 27, 37].
rithms proposed in the proceedings of Information Process- Communication based on hierarchies of more- and less-
ing in Sensor Networks (IPSN) to extract a family of key powerful devices is also common. In its simplest form, this
communication patterns that recur across the algorithms. consists of sending to one or more central data sinks in an
In Section 2 we present the results of this survey. Second, otherwise homogeneous network of nodes [4,14,18,19,26,30,
we design a network API to cover the classes of communica- 31, 34, 37]. For networks with multiple device classes below
tion. We begin by carefully discussing the design of the API the level of the sink, this notion is extended to sending to a
in Section 3, and we present the API calls and a brief discus- more powerful parent device and less powerful child devices
sion of possible implementation directions for each in Section [8, 11, 15, 35].
4. We provide a detailed treatment of four of the surveyed We note that most applications at least implicitly require
algorithms in Section 5, indicating the API calls necessary some form of multi-hop communication, with only a handful
to implement the communications required by each. Finally, speciﬁcally relying solely on single-hop transmissions [5, 10,
we conclude the paper in Section 6. 25, 28, 38]. Similarly, most applications imply at least some
level of reliability in packet delivery, with a very few claiming
complete robustness to unreliable links [5, 10, 25, 38].
2. SURVEY OF APPLICATION Finally, while most applications concern themselves with
REQUIREMENTS reception of packets only at the intended destination, a few
leverage the ability of nodes to eavesdrop on packets passing
To understand the communication requirements of typi-
through their vicinity on the way to a diﬀerent destination
cal sensor network applications, we conducted an extensive
[14, 25, 35].
review of the papers proposing data processing algorithms
in the proceedings of IPSN to date. We surveyed over 100
papers in all, but due to space limitations, we present the 3. DESIGN DECISIONS
survey results for a set of 30 of them here, chosen to best The survey results provide a starting point for specifying
represent the diversity of application classes and communi- an API to cover common communication patterns; a num-
cation patterns. For the complete survey results, we refer ber of issues, however, inﬂuence the shape of the ﬁnal API.
the reader to . In categorizing each paper, we carefully We motivate and detail key design decisions in this section,
looked to the authors’ description of the assumed network- beginning with a brief overview of the state of the art in
ing environment, making as few assumptions as possible on sensor network programming APIs.
our own part in order to accurately capture the authors’
original intent. 3.1 Preliminaries
The proposed applications span a wide variety of top- Over the past several years, a variety of programming
ics. Algorithms for data analysis include standard signal models and support frameworks have been developed for
processing applications such as measurement compression sensor networks to overcome the unique challenges faced
[26, 34, 37], target tracking [3, 8, 23, 27, 35], and parameter when trying to implement data processing applications of
estimation [25, 28, 38], as well as those more speciﬁc to sen- varying complexities on highly constrained hardware plat-
sor networks, such as query servicing [9, 13, 14, 19, 36] and forms. Of the available architectures, TinyOS has garnered
aggregation [5, 10]. Network maintenance algorithms form the most research and attention. Its event-driven model is
another common application class, with protocols to enable attractive because it allows for a direct translation of hard-
node self-localization [16, 29], guide node placement, , ware interrupts from physical devices into handlers that run
schedule node sleep cycles while maintaining sensing cover- in response to these interrupts.
age [1, 4, 39], detect network faults , and provide navi- TinyOS also allows developers to program in nesC, an
gation assistance for mobile agents traversing a sensor net- event-based extension of C created speciﬁcally for TinyOS,
work . Finally, a number of papers extend their algorithm rather than forcing users to adapt to an entirely new lan-
proposals to real-world implementations, that monitor envi- guage. TinyOS 2.0 contains a large selection of components
ronmental and structural phenomena [6, 11, 15, 31]. to simplify typical tasks an application might want to per-
Despite great diversity in the kinds of applications, we form, such as collecting sensor readings, managing overall
ﬁnd signiﬁcant commonality in their node communication device power, and communicating with other nearby de-
requirements. Some notion of address-based sending, either vices .
to a single destination or a set of destinations, is found in While TinyOS has greatly reduced the work required of
a majority of the proposed algorithms [2, 3, 5, 6, 8–10, 13, 14, the application developer, its networking components are fo-
16, 19, 23, 25, 26, 28, 30, 31, 34, 36, 37, 39]. These addresses cused on supporting two basic communication types: single-
typically take the form of unique node identiﬁers, though hop unicast to a single node and single-hop broadcast to all
a subset of applications address multicast groups to which nodes within radio range of the sender . This provides
nodes may subscribe [14, 23]. a basis upon which more complicated transmission schemes
Region-based sending also emerges as a common feature. can be built. For example, TinyOS 2.0 extends the single-
hop support to include a tree collection protocol . The vicinity, while the second allows a node to intervene and
communication classes directly supported by TinyOS, how- modify passing message. Support for these two modes is
ever, do not cover the bulk of the patterns enumerated in qualiﬁed as follows:
Moreover, while TinyOS’s basic send and receive system Support an eavesdropping receive mode. A node is al-
is well designed for simple networking systems, it lacks sev- lowed to passively listen to all overheard messages for which
eral features useful to applications developers. For example, the node is not the ultimate destination. This includes mes-
to expend extra eﬀort sending a certain packet in order to sages sent by neighbors for which the node is not the next-
increase its chances of reaching the receiver, a developer hop destination as well as those for which it is the next-hop
may take a number of platform-dependent actions, such as destination. This is the multi-hop analogue to TinyOS’s
enabling automatic radio acknowledgements (ACKs) or in- radio-channel eavesdropping.
creasing the radio’s transmission power. There is, however, Support an intervening receive mode. A node is noti-
currently no transparent way for an application to specify ﬁed of messages it is forwarding to another multi-hop des-
increased reliability. Developers must directly access these tination and allowed to modify those messages before per-
low level controls, which can diﬀer from one platform to an- forming the forward (including optionally canceling the for-
other. As another example, to send data larger than the ward). This new capability can allow for novel implemen-
packet structure’s ﬁxed payload length, an application de- tations of distributed algorithms. Consider, for example,
signer must custom-build a fragmentation and reassembly the algorithms proposed in [19, 26], both of which perform
scheme. Implementing such a system can itself become quite cluster-based aggregation of data where the node serving as
complex and distracting for designers wishing to focus their the cluster head can change with time. Both algorithms ex-
eﬀorts on novel applications. pend eﬀort to build and maintain a routing tree rooted at
the head node, and child data is aggregated by parents in
3.2 Supporting Multiple Addressing Modes the tree as it ﬂows to the root. Instead, each node in the
In addition to the most basic form of unicast addressing cluster could address the cluster head directly, with all nodes
for identifying the recipient of a message, the proposed API utilizing the intervening-receive mode. Nodes would wait an
must also support a multicast group addressing mode as well amount of time inversely proportional to their hop-count to
as addressing modes based on physical regions, either cen- the head before aggregating all intercepted data with their
tered around the sending node or around an arbitrary point own reading and addressing the result to the cluster head.
in space. Eﬃciently supporting these families of send func- Such a solution avoids re-building the routing tree when the
tions in the proposed API requires the following decisions: cluster head membership changes or detecting and repairing
Provide a dedicated API call for each addressing links in the tree that have been broken due to changes in the
mode. Instead of having a generic send () API call and us- wireless communication environment.
ing a parameter to specify the intended addressing mode, we
dedicate a separate API call to each addressing mode. This
3.4 Giving the Application the Ability to Control
design allows the underlying execution environment, such
as TinyOS, to selectively load only the code corresponding Transmission eﬀort is an important issue to consider in
to the addressing mode(s) required by the application onto designing a network API for sensor networks as it impacts
the possibly resource-constrained nodes. This design also both the reliability of packet delivery and the amount of
removes the need to unnaturally force very diﬀerent address- energy consumed in delivering a packet.
ing modes such as unicast and region-based addressing to ﬁt Among existing network APIs that provide enhanced
into a single API call mold. transmission eﬀort, the TCP socket API is the best-known.
It provides an end-to-end reliable in-order byte-stream de-
Use a separate address space for multicast address- livery service to the application, and data is retransmitted
ing. In today’s IP network, unicast and multicast addresses until an end-to-end acknowledgement is received. And while
co-exist within a 32-bit address space, where multicast ad- the TCP socket API serves the common case in the commu-
dresses are identiﬁed by the preﬁx bit sequence 1110. While nication and content oriented Internet, it does not serve the
a similar strategy may be used for a sensor network API, common case in data-processing oriented sensor networks,
sensor node addresses are typically drawn from a 16-bit ad- where data tend to be much more time-sensitive — consider,
dress space . To statically reserve a signiﬁcant portion of for example, the sensor measurements that drive the target
those 216 addresses for multicast addressing may be waste- tracking applications proposed in [3, 8, 23, 27, 35]. A TCP
ful. Instead, the proposed API uses a separate 16 bit address socket-like API may retransmit a packet that the applica-
space for multicast addressing. An address is evaluated as tion no longer considers useful, wasting energy. Moreover,
either unicast or multicast depending on the API call nam- the in-order nature of the service causes the application to
ing it as a destination. lose control over the timing of packet transmissions. When
a packet is retransmitted past its deadline, the subsequent
3.3 Supporting Multiple Receive Modes packet may be delayed suﬃciently to miss its deadline as
To enable an application running on a node to eavesdrop well.
on passing messages for which the node is not the intended Providing no transmission eﬀort enhancement, however,
recipient, the proposed API supports overhearing receive does not suﬃciently serve sensor networks — the chance of a
modes in addition to the basic mode where the receiving packet being delivered successfully over a multi-hop wireless
node is the intended destination. The multi-hop nature of sensor network can, in some cases, become too small to be
network traﬃc enables two very diﬀerent kinds of overhear- practical. These considerations led us to the following design
ing receivers. The ﬁrst merely observes traﬃc in the node’s decisions:
Give control to applications. The proposed API is de- all sensors in a region whose measurements fall in a given
signed to give applications control over the level of trans- range — a set whose size can be arbitrarily large and re-
mission eﬀort required. Wireless sensor networks’ reliability quire the payload of multiple packets. Consider also the
characteristics will depend on the physical environments in distributed wavelet compression algorithm of , where
which they are deployed. Moreover, sensor network applica- transform data describing a node’s roles at each scale of
tions can have widely diﬀerent tolerance to packet loss and a multiscale transform must be sent by the sink before the
sensitivity to timeliness of data delivery. Thus, only appli- transform can begin. The number of transform scales, and
cations themselves can decide the level of transmission eﬀort hence the size of the transform data, depends on the number
suﬃcient to achieve the desired performance. of nodes in the network and cannot be guaranteed to ﬁt in
a single packet.
Allow per-packet control. The proposed API allows the
Our proposed API, therefore, provides a message frag-
transmission eﬀort to be controlled on a per packet basis.
mentation and reassembly service to reduce the burden on
The API provides a datagram style service rather than a
application programmers. Note, however, that applications
byte-stream style service like TCP. This allows applications
should avoid packet fragmentation as much as possible.
to maintain ﬁner control over the timing of packet trans-
The message fragmentation support of our API reﬂects
missions. Packets of diﬀerent importance to an application
the following design decisions:
can be transmitted at diﬀerent eﬀort levels to realize diﬀer-
ent levels of reliability. The application can also adapt the Require hop-by-hop fragment reassembly. As men-
transmission eﬀort level at run-time to ﬁnd the operational tioned in Section 2, some applications leverage packet eaves-
sweet-spot. dropping [14, 25, 35], and others will likely beneﬁt from in-
tervening and modifying in-transit packets. To support such
Provide an energy-based abstraction. The proposed
applications, fragment reassembly must be performed at
API expresses transmission eﬀort abstractly in terms of an
each intermediate hop.
energy factor relative to the amount of energy required for
regular transmission. Thus, an energy factor of 1 implies Require in-order fragment delivery at each hop. The
no extra eﬀort is needed, while a factor of 2 allows for up primary implementation complexity for fragmentation lies
to twice as much energy to be used for transmission of the in the reassembly of packet fragments when they may ar-
packet. Compared to an alternative where the transmission rive out of order. The lower layer software should there-
eﬀort is expressed in terms of lower level notions, such as fore provide an in-order fragment delivery service. A simple
allowed number of re-transmissions, the energy-based ab- stop-and-wait protocol  is ideal for hop-by-hop in-order
straction has a number of advantages. First of all, applica- fragment transmissions. Although in many cases, a stop-
tions on resource-constrained nodes can relate to energy con- and-wait protocol would sacriﬁce performance when com-
sumption most meaningfully — with the energy-based ab- pared to a sliding-window protocol (e.g., as used in TCP),
straction, the application can pick a desired balance between this is not the case as used here, since there is no oppor-
reliability and energy consumption. Secondly, using energy tunity for pipelining of packets over the single wireless link
as an abstraction allows a variety of techniques such as in- before fragment reassembly at each hop.
creased transmission power, decreased transmission rate, or
acknowledgements and retransmissions, to be used transpar- 3.6 Providing Flexible Memory Allocation and
ently by the lower layer software and hardware depending Management for Variable Sized Data
on the situation. Both the application and the implementation of our sensor
network API will in general need to deal with data objects
Allow applications to manage congestion. Increasing
for which the total size is not known in advance. For ex-
transmission eﬀort may potentially exacerbate congestion
ample, the message fragmentation and reassembly service
in the network; the proposed API explicitly leaves the man-
described in Section 3.5 requires a node to collect the data
agement of network congestion to the applications. Sensor
from a variable number of packets (fragments) to reassemble
network applications should be designed correctly to avoid
the original application-level message; only once completely
overloading the network. When necessary, an application
reassembled can the API pass the message to the applica-
can use a variety of available techniques such as rate-based
tion for processing. As another example, in a sensor network
and credit-based ﬂow control  to help avoid transient
with nodes organized into hierarchical levels (Section 3.7),
the application on some node may need a list of its imme-
3.5 Providing Packet Fragmentation and diate children nodes that are one level below it in the hier-
Reassembly Service archy; the number of such children included in the list may
be a dynamic function of the network topology for which it
Operational experience from the IP Internet suggests that
may be diﬃcult in advance to know the expected list size.
packet fragmentation is a liability on network performance
Our proposed API, therefore, provides a ﬂexible mem-
and software complexity that should be avoided when pos-
ory allocation and management mechanism for such variable
sible. However, sensor network radios in general allow only
sized data. This mechanism entails the following design de-
very small data payloads in packets. For instance, Chip-
con’s CC2420 radio currently supports a raw data size of
128 bytes , and TinyOS 2.0 uses a message structure with Deﬁne a buﬀer chain data structure. Variable sized
a default payload data size of just 28 bytes . It is easy data are stored in a buﬀer chain data structure. A buﬀer
to ﬁnd applications that send data units larger than such a chain is a linked list of memory chunks. Each memory chunk
small size. contains application data as well as meta data that facili-
Consider, for example, the Fractional Cascading query tate the manipulation of the buﬀer chain. Multiple buﬀer
servicing algorithm , which returns the identiﬁers of chains containing diﬀerent application messages can also be
linked together to form a message queue. The idea is sim- 4. API DESCRIPTION
ilar to the FreeBSD mbuf chain data structure . The We present in this section the deﬁnition of our API for
primary advantage of this design is that memory manage- data processing algorithms in sensor networks, from the
ment is greatly simpliﬁed, since a pool of ﬁx sized buﬀers point of view of application developers who may use this
can be pre-allocated by the system and used dynamically to API, and we also provide suggestions on how the underly-
store variable sized application data without heavy weight ing network protocols to support this API can be imple-
memory allocation and de-allocation operations. mented eﬃciently in a real system. Our presentation here is
Provide a buﬀer allocation service. The application divided between the API calls for sending messages and for
can request ﬁx sized buﬀers from the pool of buﬀers main- receiving messages, and for send calls, it is divided between
tained by the system to create a buﬀer chain for storing its the calls for our three diﬀerent addressing modes: address-
variable sized data. When a buﬀer is no longer needed by based sending, geographic region-based sending, and send-
the application, it is returned to the pool for future use. ing relative to a device hierarchy. For each proposed API
call, we also provide citations to representative example data
3.7 Supporting Self-Organized Device processing algorithms that can directly use the call, based
Hierarchies on our survey of application requirements presented in Sec-
The proposed API is designed to enable self-organization tion 2.
of the sensor network nodes into network hierarchies. Pro-
viding such network hierarchies is an important service since 4.1 Address-Based Sending
many applications rely on more powerful devices managing There are three principle destination types for address-
the data from less powerful devices — see, for example the based sending. The ﬁrst sends a message to a single node
target tracking applications of [8, 35] and the environmental address. The second sends a message to a single address
monitoring applications of [11, 15]. that is a multicast address to which several nodes may be
Nodes in the network can be heterogeneous in many di- subscribed. The third sends a message to each of a list of
mensions. Physically, nodes can have batteries with varying node addresses. The calls for each of these send types are
capacities or they may even be connected to a power grid. speciﬁed as follows:
They can have varying computation capabilities, data stor-
sendSingle(data, address, eﬀort, hopLimit). The pa-
age resources, and communication bandwidth. In addition,
rameter data is a pointer to the buﬀer chain containing the
nodes can also have diﬀerent logical roles in a sensor net-
message data. address is the single-address destination for
work. For example, a sink node has the special logical role
the message, drawn from the physical node address space.
of a gateway between the sensor network and the outside
eﬀort is an integer specifying the transmission eﬀort level
world and is usually placed at the root of a network hier-
to use at each hop (1 to MAXLEVEL). hopLimit is an in-
archy. The proposed API is based on the following design
teger specifying the maximum number of hops over which
the message may be forwarded on its way to the destination
Do not assign static roles to device classes. We address (1 to MAXHOPS ). [2, 3, 5, 6, 8–10, 13, 14, 16, 19, 23,
have explicitly decided against statically mapping diﬀerent 25, 26, 28, 31, 34, 36, 37, 39]
classes of devices (e.g. Stargates and Micas) to diﬀerent
ﬁxed roles in a hierarchy, since the application should dic- sendMulti(data, address, eﬀort, hopLimit). The pa-
tate how these resources are used. Suppose, for example, rameters here are as in sendSingle() above, except that
that some Mica nodes are connected to an external power address is drawn from the multicast-group addressing space.
source. With the proposed API, the application will have [14, 23]
the ﬂexibility of giving them a special role in the hierarchy sendList(data, addList, eﬀort, hopLimit). The param-
to take advantage of their additional resources. eters here are as in sendSingle() above, except that addList
Support hierarchy level-based abstraction. The pro- is a pointer to a buﬀer chain containing the list of des-
posed API provides applications with the means to assign a tination addresses drawn from the physical node address
node a hierarchy level number at run time. For example, the space; the number of addresses in the list can be determined
application can choose speciﬁc nodes to be the sinks and set from the length of the data (in bytes) in the addrList buﬀer
them at level 1, set less powerful Stargate devices at level 2, chain. [6, 9, 25, 30, 34, 36, 37, 39]
and ﬁnally set least powerful Mica devices at level 3. The Routing for sendSingle() can be done using any exist-
lower layer software then organizes the nodes to form eﬃ- ing multihop wireless unicast routing protocol; this prob-
cient logical network hierarchies rooted at the level 1 nodes. lem has been well studied in the literature. Likewise, for
Each node at level K is associated with a parent node at sendMulti (), routing may be done using any existing multi-
level K −1 whenever possible. Each node is also associated hop wireless multicast routing protocol; although this prob-
with one of the nodes at level 1 to enable it to send messages lem has received less attention in sensor networks, it has
directly to the data sink. This approach allows applications been well studied in the multihop wireless ad hoc network-
to make very ﬂexible decisions based on both the physical ing community.
characteristics and the logical roles of network nodes. Routing for sendList() can be done by leveraging the uni-
Maintain self-organized logical overlays. It is impor- cast routing protocol used for sendSingle(). For example,
tant to note that the hierarchies constructed are logical over- the sending node can determine the ﬁrst hop toward each of
lays, so that a parent and its children need not be within the destinations listed in addrList. For all destinations with
physical radio range. This gives the lower layer software the a common ﬁrst hop, the sending node can forward a single
ﬂexibility to optimize the overlay structures to achieve good copy of the packet to that ﬁrst-hop node; this process is re-
performance. peated for each distinct ﬁrst-hop node needed for the routes
to all destinations listed in addrList. In the header of the col); as a special case, if hopLimit = 1 , sendHopRad () can
packet sent to each unique ﬁrst-hop node in this way, the be implemented as a single link-layer broadcast transmission
sending node includes a list of all destinations from addrList of the packet. The sendGeoRad () API call is similar, except
reachable through that speciﬁc ﬁrst-hop node. Each of these that nodes forward the ﬂood if they are still inside the spec-
nodes, upon receiving the packet, then repeats this process iﬁed geoRad radius around the originating node, or if they
with the remaining address list. are within outHops beyond the ﬁrst node encountered out-
Multi-hop transmissions are only allowed to propagate a side this radius. The use of outHops increases the chance
limited number of hops (hopLimit) to allow applications to of reaching all nodes inside the radius (at the expense of in-
control the scope of their packets and as a safeguard against creased overhead, as controlled by the application), despite
routing loops in the underlying routing protocols. the presence of voids inside the circle.
For the sendCircle() call, routing can be done by adapting
4.2 Region-Based Sending any existing geographic routing protocol; the problem of ge-
Applications may often want to address all nodes within ographic routing has been well studied in the literature. The
certain geographic constraints. This may include all nodes sending node routes the packet to geographic coordinates
within a certain number of hops of a given node, all nodes that are the center of the circle (centerX , centerY ). How-
within a certain radius of a given node, or all nodes within ever, once the packet is received by (or overheard by) the
an arbitrary region of space. The API calls to support this ﬁrst node that is inside this circle (the node need not be at
are speciﬁed as follows: the center coordinates), geographic forwarding of the packet
terminates, and this node instead initiates a form of the
sendHopRad(data, hopRad , eﬀort, hopLimit). The
protocol used for sendGeoRad (), giving centerX , centerY ,
parameters here are as in sendSingle() above, except that
radius, and outHops to deﬁne the ﬂood of the packet. Most
hopRad is an integer specifying a hop-count from the send-
ﬂooding protocols use a unique identiﬁer for multiple pack-
ing node within which all neighboring nodes are intended
ets that are part of the same ﬂood, to ensure that the ﬂood
to receive the message. hopRad can take a value rang-
expands eﬃciently in a well controlled manner; by assigning
ing from 1, corresponding to immediate radio neighbors,
the unique identiﬁer at the original sending node (the node
to MAXHOPS , corresponding to a network-wide ﬂood.
initiating the sendCircle() call), the resulting ﬂood will be
[2–5, 10, 14, 16, 18, 19, 29, 31, 34, 36, 38]
well controlled, even if the packet under geographic forward-
sendGeoRad(data, geoRad , outHops, eﬀort, ing is overheard by multiple nodes that all initiate copies of
hopLimit). The parameters here are as in sendSingle() the ﬂood — the diﬀerent copies of the ﬂood will in eﬀect
above, except that geoRad is a ﬂoating point number merge into a single ﬂood.
specifying a geographic distance (in standardized units) For the sendPolygon() API call, we proceed similarly to
from the sending node within which all neighboring nodes the sendCircle() call, with the region boundary evaluated
are intended to receive the message, and outHops speciﬁes for ﬂooding purposes as the convex hull of the vertex list.
the maximum number of hops that packets are allowed to
propagate outside the speciﬁed region in order to route 4.3 Device Hierarchy Sending
around voids inside the region, attempting to reach all In any sensor network, there will typically be a hierarchy
intended nodes. [1, 4, 14, 34] induced by a central data sink and the nodes of the network.
In a sensor network with multiple classes of non-sink devices
sendCircle(data, centerX , centerY , radius, single,
(e.g., low power sensor nodes and higher power intermediate
outHops, eﬀort, hopLimit). The parameters here are
nodes), we support extending this device hierarchy to reﬂect
as in sendSingle() above, except that centerX and centerY
these additional device classes. The API calls for sending in
are ﬂoating point numbers that deﬁne the coordinates of the
the device hierarchy are speciﬁed as follows:
center of a circle, and radius is a ﬂoating point number spec-
ifying the radius from that point within which all nodes are setLevel(level ). The parameter level is an integer specify-
intended to receive the message (all in standardized units). ing the level for this node in the hierarchy. We assume that
single is a boolean ﬂag indicating how many sensors in the each node, in an application-speciﬁc manner, has access to
area must be reached: single = 1 speciﬁes that only one sen- the level of the hierarchy it should occupy.
sor in the area must receive the message , whereas sin- sendSink(data, eﬀort, hopLimit). The parameters here
gle = 0 speciﬁes that all sensors in the area are intended to are as in sendSingle() above. The message is sent to the
receive the message. [14, 23, 27] “best” available sink node in the network, where the choice
sendPolygon(data, vertCount, vertices, single, of sink node is determined for the application by the API.
outHops, eﬀort, hopLimit). The parameters here are as [4, 11, 14, 15, 18, 19, 26, 30, 31, 34, 35, 37]
in sendSingle() above, except that vertCount is an integer sendParent(data, eﬀort, hopLimit). The parameters
specifying a number of polygon vertices (1 to some number here are as in sendSingle() above. The message is sent to
MAXVERTS ), and vertices is a pointer to an array of ﬂoat- the node’s parent in the device hierarchy. [8, 11, 15, 35]
ing point numbers representing the spatial coordinate pairs
of the vertices (in standardized units). single = 1 speciﬁes sendChildren(data, eﬀort, hopLimit). The parameters
that only one sensor within the convex hull formed by the here are as in sendSingle() above. The message is sent to
vertex list must receive the message [13, 23], whereas sin- each of the node’s children in the device hierarchy. [11,15,35]
gle = 0 speciﬁes that all sensors in this area are intended to parent = getParent() returns the address of the node’s
receive the message. [13, 14, 23, 37] current parent in the device hierarchy.
The sendHopRad () API call can be implemented by any childList = getChildren() returns a pointer to a buﬀer
form of a ﬂooding protocol (or using a spanning tree proto- chain containing a list of the addresses of the node’s current
children in the device hierarchy; the number of children in the node’s radio receiver. The API calls for receiving mes-
the list can be determined from the length of the data (in sages are speciﬁed as follows:
bytes) in the childList buﬀer chain. This API call supports,
for example, a node sending to a subset of its children by receiveTarget(data, metadata). This API call is invoked
calling sendList() using a subset of the return child list. by the API implementation as an event into the application
when a message has been received. The parameter data is
newParent(parent). This API call is invoked by the API a pointer to a buﬀer chain holding the message data, and
implementation as an event into the application when the metadata is a pointer to a buﬀer chain holding the header
node’s parent in the device hierarchy has changed. The pa- information appropriate for the message packet type.
rameter parent gives the address of the node’s new parent.
receiveForward(data, metadata). The parameters are
newChildren(childList). This API call is invoked by the the same as in receiveTarget(). This API call is invoked
API implementation as an event into the application when by the API implementation as an event into the applica-
one or more of the node’s children in the device hierarchy has tion when a message has been received. If the application
changed. The parameter childList is a pointer to a buﬀer returns a zero result value in response to this call (the func-
chain containing a list of the node’s current children; the tion return value), then the message will not be forwarded
number of children in the list can be determined from the (forwarding stops at this node). If instead the application
length of the data (in bytes) in the childList buﬀer chain. returns a nonzero result value, the message (possibly modi-
ﬁed by the application) will be forwarded along to the next
In order to form the device hierarchy, the API implemen- hop to the destination(s).
tation can cause each level-n node (at all but the nodes with
the largest level number) to broadcast a message announc- receiveOverhear(data, metadata). The parameters are
ing itself as a level-n device. Any level-(n−1) node hear- the same as in receiveTarget(). This API call is invoked
ing this message may consider itself as a potential parent by the API implementation as an event into the application
and contacts the level-n node with this information. The when a message has been received. Any message overheard
level-n node then chooses its parent from the responding by this node’s radio will be received, regardless of the ad-
level-(n−1) nodes and informs that parent of its status as dressing of the message. [14, 25, 35]
a level-n child. The lowest level of nodes (typically the low- Within any of these receive events within the application,
est power sensor nodes) never advertise themselves and only the application handler for that event can then parse the
look for messages from potential parents. The highest level metadata for any packet-speciﬁc ﬁelds it cares to extract.
(sink) node(s) never look for potential parents. All packet types will support the following two calls:
The API implementation maintaining this process can pe-
riodically update parent assignment to cope with changing type = getPacketType(metadata)
network conditions. When a node’s parent changes, the API sender = getSender(metadata)
implementation invokes the newParent() event in the appli-
where type is an integer corresponding with one of the packet
cation if the application had earlier requested knowledge
classes, and sender speciﬁes the address of the sender in the
of its parent through a getParent() call. Likewise, when a
physical address space. With this type information in hand,
node’s list of children changes (a new node becomes a child,
the application layer can then use similar calls to extract
or an old child is no longer associated with this node), the
packet ﬁelds such as the destination address for sendSingle()
API implementation invokes the newChildren() event in the
or the (remaining) list of destinations for sendList(), the
application if the application had earlier requested knowl-
hop radius for sendHopRad () or the geographic radius for
edge of its children through a getChildren() call.
sendGeoRad (), or the center and radius for sendCircle() or
We considered providing a sendLevel () call in our pro-
the vertices for sendPolygon().
posed API, as a more general form of the sendParent() and
sendChildren() calls. Such a sendLevel () call, given a level
number in the device hierarchy, would send to the respec- 5. APPLICATION EXAMPLES
tive node(s) at that level. For example, for a node at level n We now present detailed treatments of a selection of the
(n > 1), a sendLevel () to level n − 1 would be equivalent surveyed papers [13, 14, 23, 34], chosen for the range of com-
to a sendParent() call, and to level n+1 would be equiva- munication patterns they exhibit. We brieﬂy describe the
lent to a sendChildren() call; a sendLevel () call need not be objective of each proposed algorithm and show how it can
limited, however, to only sending to levels n−1 and n+1, be implemented using the API calls outlined in the previous
creating an easy way to send to “grandchildren” (level n+2) section.
and “great grandparents” (level n−3), for example. We did
not include such a call in the API, though, since we did not 5.1 TinyDB
ﬁnd the need for this generality in our survey of application In , the authors describe the TinyDB query engine for
requirements, as presented in Section 2. sensor networks. Basic aggregate queries — such as min-
ima, maxima, averages, counts, and sums — are posed at
4.4 Receiving the network’s data sink. The sink broadcasts the query to
The three main receive functions correspond to the three the network with an incrementing hop counter that allows
receiving modes. A node can (1) receive a message for which nodes to form an application-speciﬁc hierarchy to service the
it is the target destination, (2) intercept and potentially query. Each node receiving the query picks a parent one-hop
modify a message for which the node is a forwarder on the closer to the sink than itself and re-broadcasts the query to
path to a diﬀerent target destination, or (3) passively eaves- potential children in its 1-hop neighborhood. This query dis-
drop (without modiﬁcation) on all messages overheard by semination is handled as a network-wide ﬂood at the sink
using the sendHopRad () call with hoplimit = MAXHOPS. calls, and each measurement returns to the track leader via
As the query forwards, each node can extract its minimum a sendSingle() call. As the target moves, the track leader
distance to the sink from the decrementing hoplimit ﬁeld. duty is passed to a new node in the target’s path using
Once the query has reached the entire network, each leaf sendCircle() or sendPolygon() with the single-node-only op-
node (a node that has no children) evaluates the query using tion. When two targets come within a threshold range of
its data and forwards the result to its parent. Each parent each other, the two GCGs are merged and serviced by a sin-
aggregates messages from its children with its own datum gle track leader. As the two targets subsequently diverge,
and forwards the result to its parent until the ﬁnal aggregate two new GCGs, each with its own track leader, are created.
is computed at the sink. Each child-to-parent message is To disambiguate target identities, nodes serving as track
sent using the sendSingle() API call. leaders must maintain a dialogue for a time, so they form
TinyDB extends basic sink query servicing to support an “acquaintance group” (AG). Since tracking agents move
more advanced event-driven queries issued from nodes in from node to node to follow their targets, we represent the
the network. On detection of an event (say, a bird enter- AG as a multicast group to which each leader subscribes.
ing a nest monitored by a node), the node can query all Messages passed between leaders to sort out target identi-
neighbors within a speciﬁed radius for data (such as light ties are then sent using the sendMulti () call.
and temperature) using the sendGeoRad () call. Data from
the neighboring nodes returns to the querying node using 5.3 Fractional Cascading
sendSingle() calls, and a report is sent to the sink using
In , the authors present a framework called Fractional
sendSink () addressing. Alternatively, the report can be sent
Cascading for answering range queries injected from any-
to a storage point within the network which is addressable
where in the network. Each node in the network has a
by all nodes but does not occupy a ﬁxed location. In this
global view of the measurement ﬁeld that decays in reso-
case, the querying node sends its report to a multicast group
lution proportional to distance from the node — that is, a
of storage nodes using the sendMulti () call.
node knows much more about measurements from nearby
As an example of the utility of TinyDB, the authors con-
nodes than from those far away. This allows queries posed
sider the problem of tracking a vehicle using magnetometer
at arbitrary locations, counting or enumerating all sensors
readings at each sensor. Nodes in the network initially start
in a rectangular area whose measurements lie in some range,
out in a low power mode, and those in the vicinity of the tar-
to be eﬃciently routed to regions with relevant information.
get power up when it ﬁrst enters the sensor network using
The structure that enables eﬃcient query processing is
dedicated wake-up circuitry. Each active node then mon-
a virtual quadtree partition of the bounding box contain-
itors the running average of its magnetometer and when a
ing the sensor ﬁeld. This square box is partitioned into four
threshold is exceeded inserts its measurement and node iden-
sub-squares, and each of these is recursively partitioned into
tiﬁer into a storage point (again using the sendMulti () call).
four smaller sub-squares, and so on, until a minimum square
The storage point estimates the target’s location using the
size is reached. At each scale, the larger square giving rise to
location of the node with the strongest reading. Nodes can
the four smaller squares is declared a parent and the smaller
also eavesdrop on their neighbors’ messages to the storage
squares its children. To guide query routing, the maximum
point using the receiveOverhear () call and suppress their
measurement value of any sensor node in a given quadtree
own transmissions when neighbors have a stronger reading.
square is stored in the nodes in all children of that square’s
Note that use of the receiveForward () receiver would also
parent — i.e., its sibling squares. This structure is built in
allow nodes with stronger readings to suppress forwarding
a bottom-up fashion. One node in a square (which by in-
messages from nodes with weaker readings. Finally, when a
duction has access to the maximum value in each of that
sensing node detects that the target is moving out of range,
square’s children) computes the square’s maximum value
it can wake up nodes in the next area to be traversed by
and sends the value to all nodes in the square’s siblings,
the target using a region-based send such as sendCircle() or
implemented using a sendPolygon() call.
The answer to each range query is compiled in three steps.
First, the query is directed toward a sensor in the region
5.2 Distributed Multi-Target Tracking of interest, which requires a sendPolygon() API call with
The authors of  tackle the problem of tracking multiple the single-node-only option. Once in the region, the query
maneuvering targets in a decentralized fashion. Maintain- sequentially visits each sub-region designated as a “canon-
ing a complete record of the joint state space of targets in ical piece” — that is, a quadtree square which is com-
any one component of the sensor network is impractical; it pletely contained inside the query region but whose parent
is far more eﬃcient to keep state information for each tar- square extends outside the region. This again necessitates a
get in tracking agents occupying nearby nodes. When tar- sendPolygon() API (single-node-only) call. Once the query
gets’ paths cross, however, their locations must be estimated has arrived at any sensor in the canonical region, it can ex-
jointly, and target identity upon track divergence becomes ploit the distributed information structure to eﬃciently tra-
uncertain. Agents separately tracking each target following verse the sub-tree for that region, recursively visiting each
the split must maintain a dialogue to determine which of child square in a fashion appropriate to the query, again
the targets they are actually tracking. using a sendPolygon() API (single-node-only) call. For ex-
Before a merge, each target is tracked by an agent oc- ample, if the query wishes to compile a list of sensors with
cupying a node designated as the track leader. To localize measurements above a threshold value, the query need not
its target, the node collects measurements from other nodes recur on any children or siblings of a square with a max-
in the vicinity of the target — a so-called “geographically imum temperature below the threshold. Since any sensor
constrained group” (GCG) deﬁned as a circle or polygon. in each square records the maximum value in that square
This process involves sendCircle() or sendPolygon() API and its sibling squares, the query can eﬃciently traverse the
squares of each canonical region’s subtree. characteristics of sensor network hardware and software, we
Finally, the aggregated query data return to the querying have carefully made a set of design decisions that covers a
node using a sendSingle() API call. wide range of issues including addressing modes, receiving
modes, transmission reliability enhancement, message frag-
5.4 Distributed Wavelet Compression mentation, system memory management, and device hierar-
In , the authors propose a distributed wavelet com- chy formation.
pression algorithm. This entails ﬁrst computing a dis- By presenting a concrete API, we hope to stimulate fur-
tributed wavelet transform of data within the network and ther discussions in the research community on API design
then selectively streaming wavelet coeﬃcients from nodes issues for sensor networks. In addition, we believe the API
to the sink. First, however, the sink must learn of each also opens new research directions. Speciﬁcally, the pre-
node’s self-localized position, sent using a sendSink () call sented API frames two new challenges for future research to
by each node. Using this information, the sink computes a address: (1) how to optimally enhance transmission reliabil-
set transform data for each node and sends it to the node ity given an energy budget and the current environmental
using a sendSingle() call. conditions, and (2) how to optimally self-organize nodes dy-
Given this transform data, the multi-scale wavelet trans- namically into device hierarchies.
form, based on the theory of wavelet lifting, proceeds in the
network as follows. A subset of nodes at each scale are des-
ignated to compute wavelet transform values. Each node in
this set computes its value — called a wavelet coeﬃcient —  Z. Abrams, A. Goel, and S. Plotkin. Set K-cover algorithms
using values from neighbors not generating wavelet coeﬃ- for energy eﬃcient monitoring in wireless sensor networks.
cients. Each such neighbor knows which nodes will require In Proc. of IPSN, pages 424–432, 2004.
its value — called a scaling coeﬃcient – and transmits this  M. A. Batalin and G. S. Sukhatme. Coverage, exploration,
value to those nodes, using an instance of the sendList() and deployment by a mobile robot and communication
network. In Proc. of IPSN, pages 376–391, 2003.
call. Each node which computes a wavelet coeﬃcient col-
 P. W. Boettcher and G. A. Shaw. Energy-constrained
lects these neighboring values, computes its coeﬃcient, and collaborative processing for target detection, tracking, and
sends the coeﬃcient value back to the neighbors, again using geolocation. In Proc. of IPSN, pages 254–268, 2003.
an instance of the sendList() call. Each neighbor collects the  Q. Cao, T. Abdelzaher, T. He, and J. Stankovic. Towards
list of wavelet coeﬃcients sent to it and uses the information optimal sleep scheduling in sensor networks for rare-event
to compute a new coarser-scale scaling coeﬃcient for itself. detection. In Proc. of IPSN, pages 20–27, 2005.
The process then repeats at the next scale on the remaining  J. Y. Chen, G. Pandurangan, and D. Xu. Robust
scaling coeﬃcient nodes, with a subset giving rise to wavelet computation of aggregates in wireless sensor networks:
Distributed randomized algorithms and analysis. In Proc.
coeﬃcients at the new scale and the remainder participating
of IPSN, pages 348–355, 2005.
as scaling coeﬃcients in further scales of the transform.  K. Chintalapudi, J. Paek, O. Gnawali, T. S. Fu, K. Dantu,
Once the transform has iterated to a ﬁnal, coarsest scale, J. Caﬀey, and R. Govindan. Structural damage detection
each node has a transform coeﬃcient replacing its original and localization using NETSHM. In Proc. of IPSN, pages
measurement. This set of coeﬃcients is much more sparse 475–482, 2006.
than the original measurement set — in other words, the  Chipcon. CC2420 Data Sheet. http:
energy of the measured signal is concentrated at far fewer //www.chipcon.com/files/CC2420 Data Sheet 1 4.pdf.
nodes. To harvest a lossily compressed version of the mea-  M. Coates. Distributed particle ﬁlters for sensor networks.
In Proc. of IPSN, pages 99–107, 2004.
surement ﬁeld, the sink broadcasts a threshold to all sensors
 A. G. Dimakis, V. Prabhakaran, and K. Ramchandran.
using the sendHopRad () call with hoplimit = MAXHOPS. Ubiquitous access to distributed data in large-scale sensor
Upon receiving this threshold query, each node with a co- networks through decentralized erasure codes. In Proc. of
eﬃcient whose magnitude is above the threshold sends its IPSN, pages 111–117, 2005.
coeﬃcient to the sink using the sendSink () call. The process  A. G. Dimakis, A. D. Sarwate, and M. J. Wainwright.
may repeat with subsequent threshold broadcasts from the Geographic gossip: Eﬃcient aggregation for sensor
sink and node replies until it has harvested enough coeﬃ- networks. In Proc. of IPSN, pages 69–76, 2006.
cients to reconstruct the ﬁeld to some desired ﬁdelity.  P. Dutta, J. Hui, J. Jeong, S. Kim, C. Sharp, J. Taneja,
G. Tolle, K. Whitehouse, and D. Culler. Trio: Enabling
To provide robustness to occasional node and routing
sustainable and scalable outdoor wireless sensor network
failures,  also proposes a mechanism for nodes to re- deployments. In Proc. of IPSN, pages 407–415, 2006.
pair transform data in a distributed fashion. If a wavelet  R. Fonseca, O. Gnawali, K. Jamieson, and P. Levis.
coeﬃcient-generating node cannot hear from a required Collection. http:
neighbor, it can begin to search for new neighbors outward //www.tinyos.net/tinyos-2.x/doc/html/tep119.html.
in an expanding radial neighborhood. Such a request is im-  J. Gao, L. J. Guibas, J. Hershberger, and L. Zhang.
plemented using the sendGeoRad () call, and replies from Fractionally cascaded information in a sensor network. In
potential neighbors return using the sendSingle() call. New Proc. of IPSN, pages 311–319, 2004.
 J. M. Hellerstein, W. Hong, S. Madden, and K. Stanek.
and remaining neighbors must be informed of this change
Beyond average: Toward sophisticated sensing with queries.
using further sendList() and sendSingle() calls. In Proc. of IPSN, pages 63–79, 2003.
 W. Hu, V. N. Tran, N. Bulusu, C. T. Chou, S. Jha, and
6. CONCLUSIONS A. Taylor. The design and evaluation of a hybrid sensor
network for cane-toad monitoring. In Proc. of IPSN, pages
We have presented a network API for sensor networks. 503–508, 2005.
The selection of the abstract services that the API pro-  A. T. Ihler, J. W. F. III, and R. L. Moses. Nonparametric
vides has been informed by an extensive survey of over belief propagation for self-calibration in sensor networks. In
100 data processing algorithms. Moreover, guided by the Proc. of IPSN, pages 225–233, 2004.
 S. Keshav. An Engineering Approach to Computer
Networking: ATM Networks, the Internet, and the
Telephone Netowrk. Addison Wesley. 1997.
 A. Krause, C. Guestrin, A. Gupta, and J. Kleinberg.
Near-optimal sensor placements: Maximizing information
while minimizing communication cost. In Proc. of IPSN,
pages 2–10, 2006.
 B. Krishnamachari and S. S. Iyengar. Eﬃcient and
fault-tolerant feature extraction in wireless sensor networks.
In Proc. of IPSN, pages 488–501, 2003.
 P. Levis. message t. http:
 P. Levis. Packet Protocols. http:
 P. Levis. TinyOS Programming. http:
 J. Liu, M. Chu, J. Liu, J. Reich, and F. Zhao. Distributed
state representation for tracking problems in sensor
networks. In Proc. of IPSN, pages 234–242, 2004.
 M. K. McKusick and G. V. Neville-Neil. The Design and
Implementation of the FreeBSD Operating System.
Addison Wesley. 2005.
 M. Paskin, C. Guestrin, and J. McFadden. A robust
architecture for distributed inference in sensor networks. In
Proc. of IPSN, pages 55–62, 2005.
 S. Pattem, B. Krishnamachari, and R. Govindan. The
impact of spatial correlation on routing with compression
in wireless sensor networks. In Proc. of IPSN, pages 28–35,
 S. Pattem, S. Poduri, and B. Krishnamachari.
Energy-quality tradeoﬀs for target tracking in wireless
sensor networks. In Proc. of IPSN, pages 32–46, 2003.
 M. Rabbat and R. Nowak. Distributed optimization in
sensor networks. In Proc. of IPSN, pages 20–27, 2004.
 A. Savvides, W. Garber, S. Adlakha, R. Moses, and M. B.
Srivastava. On the error characteristics of multihop node
localization in ad-hoc sensor networks. In Proc. of IPSN,
pages 317–332, 2003.
 N. Shrivastava, S. Suri, and C. T´th. Detecting cuts in
sensor networks. In Proc. of IPSN, pages 210–217, 2005.
 A. Terzis, A. Anandarajah, K. Moore, and I. Wang. Slip
surface localization in wireless sensor networks for landslide
predection. In Proc. of IPSN, pages 109–116, 2006.
 TinyOS Community Forum. http://www.tinyos.net/.
 R. Wagner, M. Duarte, J. R. Stinnett, T. S. E. Ng, D. B.
Johnson, and R. Baraniuk. A network API-driven survey of
communication requirements of distributed data processing
algorithms for sensor networks. Technical report, Rice
University, 2006. http:
 R. S. Wagner, R. G. Baraniuk, S. Du, D. B. Johnson, and
A. Cohen. An architecture for distributed wavelet analysis
and processing in sensor networks. In Proc. of IPSN, pages
 Q. Wang, W. Chen, R. Zheng, K. Lee, and L. Sha. Acoustic
target tracking using tiny wireless sensor devices. In Proc.
of IPSN, pages 642–657, 2003.
 W. Wang and K. Ramchandran. Random distributed
multiresolution representations with signiﬁcance querying.
In Proc. of IPSN, pages 102–108, 2006.
 R. Willett, A. Martin, and R. Nowak. Backcasting:
Adaptive sampling for sensor networks. In Proc. of IPSN,
pages 124–133, 2004.
 L. Xiao, S. Boyd, and S. Lall. A scheme for robust
distributed sensor fusion based on average consensus. In
Proc. of IPSN, pages 63–70, 2005.
 G. Xing, C. Lu, R. Pless, and J. A. O’Sullivan. Co-grid: an
eﬃcient coverage maintenance protocol for distributed
sensor networks. In Proc. of IPSN, pages 414–423, 2004.