Middleware to Support

Sensor Network Applications

Wendi B. Heinzelman, Amy L. Murphy, Hervaldo S. Carvalho, and Mark A. Perillo
University of Rochester

Abstract
Current trends in computing include increases in both distribution and wireless con-
nectivity, leading to highly dynamic, complex environments on top of which appli-
cations must be built. The task of designing and ensuring the correctness of
applications in these environments is similarly becoming more complex. The unified
goal of much of the research in distributed wireless systems is to provide higher-
level abstractions of complex low-level concepts to application programmers, eas-
ing the design and implementation of applications. A new and growing class of
applications for wireless sensor networks require similar complexity encapsulation.
However, sensor networks have some unique characteristics, including dynamic
availability of data sources and application quality of service requirements, that
are not common to other types of applications. These unique features, combined
with the inherent distribution of sensors, and limited energy and bandwidth
resources, dictate the need for network functionality and the individual sensors to
be controlled to best serve the application requirements. In this article we describe
different types of sensor network applications and discuss existing techniques for
managing these types of networks. We also overview a variety of related middle-
ware and argue that no existing approach provides all the management tools
required by sensor network applications. To meet this need, we have developed a
new middleware called MiLAN. MiLAN allows applications to specify a policy for
managing the network and sensors, but the actual implementation of this policy is
effected within MiLAN. We describe MiLAN and show its effectiveness through the
design of a sensor-based personal health monitor.

F or several decades, distributed computing has been

both an enabling and a challenging environment in
which to build applications. Initially, the major diffi-
culty in implementing such systems was simply
exchanging data across distances and among heterogeneous
components. Today these problems are essentially solved, and
research is turning its focus to higher-level concerns such as
network applications require a minimum quality of service
(QoS); this level must be maintained over an extended peri-
od of time. There may be many ways to achieve the QoS
(e.g., different sensors may offer data or services that meet
the applications’ QoS requirements). Furthermore, the
required QoS and the means of meeting it can change over
time, as the state of the application or availability of sensors
improved fault tolerance through replication, optimal data changes.
access via distributed object placement, and methods of • Resource limitations. Both network bandwidth and sensor
enabling high-level communication abstractions such as event energy are constrained. This is especially true when consid-
dispatching and remote invocation. The end result of this ering battery-powered sensors and wireless networks.
research into distributed systems is an expanding set of mid- • Cooperative applications. Sensor network applications share
dleware platforms that reside above the operating system and available resources (e.g., sensor energy, channel bandwidth)
below the application, abstracting lower-level functionality and either cooperate to achieve a single goal or, at the very
such as network connectivity and providing a high-level coor- least, do not compete for these limited resources.
dination interface to the application programmer. One unique feature of sensor network applications with
Often the combination of characteristics from the environ- these properties is that simply responding to the changing
ment and application drive the design of the middleware. For environment is insufficient to achieve the required QoS over
example, consider the new class of applications for sensor net- time. Instead, the applications must be proactive, actively
works with the following features: affecting the network. Most existing middleware systems do
• Inherent distribution. The sensors are distributed throughout not support such a proactive approach with respect to the net-
a physical space and primarily connected wirelessly. work, leaving reactivity as the only choice and sacrificing
• Dynamic availability of data sources. Either mobility through application quality over time. We believe a middleware that
space, addition of new sensors, or loss of existing sensors enables applications to affect the network and the sensors
causes the set of available sensors to change over time. themselves is needed to support this new and growing class of
• Constrained application quality of service demands. Sensor applications for sensor networks.

6 0890-8044/04/$20.00 © 2004 IEEE IEEE Network • January/February 2004

 M Data
This article presents an overview of M
M QoS App 1
related research in the areas of sensor net-
works and middleware, highlighting how
existing approaches to the management of
sensor networks could benefit from a mid- System
M Network MiLAN
dleware abstraction and showing that exist- QoS
ing middleware does not meet the specific
needs of all sensor network applications. QoS
Based on this observation, we propose a App n
new middleware for sensor networks called M Data
M
Middleware Linking Applications and Net-
works (MiLAN). MiLAN allows sensor M
network applications to specify their quali-
ty needs and adjusts the network character-
■ Figure 1. A system that employs MiLAN. Each sensor runs a (possibly scaled down)
istics to increase application lifetime while
version of MiLAN. MiLAN receives information from applications about their QoS
still meeting those quality needs. Specifi-
requirements, a system user about the desired interaction among the applications,
cally, MiLAN receives information from:
and the network about available components and resources. MiLAN then decides
• The individual applications about their
how best to configure the network to support the applications.
QoS requirements over time and how to
meet these QoS requirements using dif-
ferent combinations of sensors
• The overall system about the relative importance of the dif- minimum percentage of sensor coverage in an area where a
ferent applications phenomenon is expected to occur. The sensor network may
• The network about available sensors and resources such as consist of sensors with overlapping coverage areas providing
sensor energy and channel bandwidth redundant information. If the application does not require all
Combining this information, MiLAN continuously adapts the this redundant information, it would be desirable to conserve
network configuration (e.g., specifying which sensors should energy in some sensors by allowing them to sleep, thereby
send data, which sensors should be routers in multihop net- lengthening the lifetime of the network. For example, as sen-
works, which sensors should play special roles in the network) sors use up their limited energy, the application would like to
to meet the applications’ needs while maximizing application use different sets of sensors to provide the required QoS (in
lifetime. Figure 1 shows a high-level diagram of a system that this case, minimum sensor coverage area). This requires that
employs MiLAN. the application manage the sensors over time. Such manage-
Next we describe several sensor network applications that ment can be as simple as turning sensors on and off, or as
could benefit from a middleware like MiLAN that proactively complex as selecting the routes for data to take from each
affects different characteristics of the network. Following this, sensor to the collection point in a multihop network. Further-
we discuss existing sensor network management and middle- more, the needs of the surveillance application may change as
ware approaches. Finally, we describe MiLAN and show how a result of previously received data. For example, if the appli-
the design of a health monitor sensor application can be sim- cation determines that an intrusion has occurred, the applica-
plified using MiLAN. tion may assume a new state and require more sensors to
send data to more accurately classify the intrusion. The imple-
mentation of these tasks can be complex, and they are diffi-
Sensor Network Applications cult to incorporate into applications.
As stated in the introduction, sensor network applications rep-
resent a new class of applications that are: Home/Office Security
• Data-driven, meaning that the applications collect and ana- Home/office security systems are becoming increasingly com-
lyze data from the environment, and, depending on redun- plex, monitoring for not only intrusion into the space but also
dancy, noise, and properties of the sensors themselves, can the occurrence of substances such as fire or carbon monoxide
assign a quality level to the data gas. To be able to monitor the application variables, the secu-
• State-based, meaning that an application’s needs with rity system must obtain data from heterogeneous sensors such
respect to sensor data can change over time based on previ- as acoustic, motion, heat, and vibration sensors scattered
ously received data throughout the home/office. Making these sensors wireless
Typically sensors are battery-operated, meaning they have a and battery-powered allows them to easily be placed in exist-
limited lifetime during which they provide data to the applica- ing homes without major household modifications. To make
tion. A challenge of the design of sensor networks is how to the sensor network last as long as possible, the application
maximize network lifetime while meeting application QoS may only want a subset of the sensors activated at any time.
requirements. For these types of applications, the needs of the Once a sensor’s activation has been triggered through some
application should dictate which sensors are active and the event, the application must analyze the data and decide how
role they play in the network topology. To further illustrate to change the configuration of active sensors. This can be
this point, we discuss some specific sensor network applica- modeled as the application changing state based on received
tions and how they can benefit from this form of interaction. data. For different application states, different sets of sensors
should be activated to provide the greatest benefit to the
Environmental Surveillance security application. Thus, the application needs to be able to
Consider an environment where multiple sensors (e.g., acous- control which sensors are activated over time. At the same
tic, seismic, video) are distributed throughout an area such as time, to allow the application to work as long as possible, the
a battlefield. A surveillance application can be designed on set of sensors activated for a given application state should be
top of this sensor network to provide information to an end chosen wisely to reduce energy dissipation and maximize sys-
user about the environment. The application may require a tem lifetime. Furthermore, sensors whose data are very

IEEE Network • January/February 2004 7

 Routing
Some protocols make use of low-level node collaboration
Directed
Aggregation Diffusion to reduce the energy cost of data transfer by aggregating data
Rumor Routing locally rather than sending all raw data to the application. For
SPIN example, with LEACH [1], nodes form local clusters, and all
data within a cluster are aggregated by the cluster head node
LEACH before being transmitted to the base station. This limited form
of low-level collaboration is also found in the query-based
Topology technique of Directed Diffusion [2], in which nodes collabo-
MAC control
rate to set up routes as interests for particular data are dissem-
STEM inated through the network.
IEEE 802.11 Bluetooth
ASCENT Lint Another approach to reducing energy dissipation is to turn
PAMAS SMAC nodes off whenever possible. As idle power can often be sig-
Span nificant, this approach can greatly extend application lifetime.
MAC-level protocols, such as PAMAS [3] and S-MAC [4] use
■ Figure 2. Relationships between different sensor network proto- this technique to reduce energy dissipation in the MAC proto-
cols and the network services they provide. col, often trading off latency in packet delivery for energy effi-
ciency. Topology control protocols such as ASCENT [5], Span
[6], and STEM [7] use a similar technique of turning on and
important to the application, such as the video sensor, should off sensors to maximize network lifetime while keeping the
not be used as routers or control nodes, so their energy is network fully connected. Other topology control protocols
saved for sensing the environment and transmitting their data such as Lint [8] aim to determine the minimum transmit
to the application. Performing such optimizations, and con- power necessary for a fully connected network, whereas proto-
trolling the sensors and network functionality from within the cols such as those described in [9, 10] determine the optimal
application would place an unreasonable burden on the appli- transmit power to minimize overall energy dissipation.
cation. In addition to the above two techniques, considerable ener-
gy can be saved by tailoring the routing protocol to the char-
Medical Monitoring acteristics of sensor networks, including the energy constraints
As a final example, consider a personal health monitor appli- of the sensors, the data-driven nature of these networks, and
cation running on a PDA that receives and analyzes data from the many-to-one, many-to-some, or many-to-many collection
a number of sensors (e.g., ECG, EMG, blood pressure, blood of the data. Sensor network routing protocols such as Rumor
flow, pulse oxymeter). The monitor reacts to potential health Routing [11], Directed Diffusion [2], and SPIN [12] provide
risks and records health information in a local database. Con- lightweight data-centric solutions tailored to typical sensor
sidering that most sensors used by the personal health moni- network traffic patterns. Although these protocols are effec-
tor will be battery operated and use wireless communication, tive in extending the lifetime of sensor networks, the gap
it is clear that this application can benefit from intelligent sen- between the protocol and the application is often too large to
sor management that provides energy efficiency as well as a allow the protocols to be effectively used by application devel-
way to manage QoS requirements, which may change over opers.
time with changes in the patient’s state. For example, higher
quality might be required for certain health-related variables Middleware
during high stress situations such as a medical emergency, and Middleware has often been useful in traditional systems for
lower quality during low stress situations such as sleep. We bridging the gap between the operating system (a low-level
will return to the details of this application when describing component) and the application, easing the development of
our middleware system, MiLAN. distributed applications. Because wireless sensor networks
share many properties with traditional distributed systems, it
is natural to consider distributed computing middleware for
Sensor Network Management and use in sensor networks. Figure 3 shows a high-level view of
the key relationships among the middleware we discuss here.
Middleware Approaches One of the most common middleware systems, Corba
There has been considerable research on the development of [13], hides the location of remote objects, simplifying the
low-level protocols to support sensor networks as well as high- application’s interactions with these remote objects by
level middleware systems to support the development of dis- allowing all operations to appear local. Although this
tributed computing applications by hiding environmental could be applied to sensor networks to provide access to
complexities. A recent trend includes the combination of the sensor data, by hiding the location of the object (e.g.,
these into middleware designed for sensor networks. In this the sensor), the context information (e.g., the location) of
section we describe these developments and explain why they the sensor is similarly lost. Additionally, by providing indi-
are insufficient for the unique style of many sensor network vidual sensor access through objects, the potential energy
applications. savings by aggregation is lost. Jini’s [14] service discovery
protocol and leasing mechanisms allow client applications
Sensor Networks to discover services and manage client-server connections
One of the distinguishing characteristics of sensor networks is as the set of available services changes. Service discovery is
their reliance on nonrenewable batteries, despite their simul- useful for dynamic sensor networks to know what sensors
taneous need to remain active as long as possible. Therefore, and/or services are available; however, access to services
initial work has been done to create network protocols tai- remains object-based, similar to Corba. The L IME middle-
lored to sensor networks that extend network lifetime consid- ware [15] focuses on a different application programming
ering the energy constraints of the individual sensors. Figure 2 interface (API), namely a shared memory scheme for
highlights the different protocols we discuss here and how mobile ad hoc components through a Linda-like tuple
they relate to different network services. space [16]. Neither Jini nor L IME consider the limited

8 IEEE Network • January/February 2004

 Middleware

Static environment Dynamic environment

Adaptive Non-adaptive
Corba
Linda
LIME
Reactive Proactive Jinl

Enables Enables
Middleware reactive Middleware proactive
reactive applications proactive applications

Data/resource Code
Flexible to management management
Specialized existing
network network
Limbo Odyssey protocols protocols
Fargo Spectra

QoS aware
middleware

DSWare
Cougar MiLAN AutoSec Impala
SINA

Sensor network middleware

■ Figure 3. Relationships among different middleware. In this figure, “middleware reactive” refers to middleware that reacts itself to
changes in network behavior, whereas “middleware proactive” refers to middleware that proactively changes the network functionality.
Similarly, “enables reactive applications” refers to middleware that provides hooks so that applications can react to changes in the envi-
ronment, whereas “enables proactive applications” refers to middleware that accepts information from the application about how to
respond to changes in the network.

energy constraints of sensor networks, and their supporting Middleware for Sensor Networks
protocols are heavyweight when compared to protocols tai-
lored to sensor networks. Recently, much work has targeted the development of middle-
Some middleware acknowledge the changing properties of ware specifically designed to meet the challenges of wireless
wireless networks and attempt to modify their own behavior sensor networks, focusing on the long-lived and resource-con-
to match the conditions detected within the network. For strained aspects of these systems.
example, both Limbo [17] and FarGo [18] reorder data Both the Cougar [24] and SINA [25] systems provide a dis-
exchanges or relocate components to respond to changing tributed database interface to the information from a sensor
network conditions such as bandwidth availability or link relia- network with database-style queries. Power is managed in
bility. At a lower level, Mobiware [19] supports various levels Cougar by distributing the query among the sensor nodes to
of QoS by adapting streams within the network with active fil- minimize the energy consumed to collect the data and calcu-
ters deployed in the routers. Other middleware systems pro- late the query result. To support the database queries, SINA
vide hooks to allow the applications to adapt. For example, incorporates low-level mechanisms for hierarchical clustering
applications built on the Odyssey platform [20] can register of sensors for efficient data aggregation as well as protocols
for notification of changes in the underlying network data that limit the retransmission of similar information from geo-
rate. Similarly, the Spectra [21] component of Aura [22] moni- graphically proximate sensor nodes.
tors the network conditions and the accessible computation AutoSec [26], Automatic Service Composition, manages
resources, deciding where computation should be performed resources in a sensor network by providing access control for
based on the network transmission required to complete them applications so that QoS requests are maintained. This
as well as the expense of the computation on mobile versus approach is similar to middleware for standard networks
fixed nodes. These advances are applicable to wireless sensor because resource constraints are met on a per-sensor basis,
networks; however, they do not integrate any of the specific but the techniques for collecting the current resource utiliza-
data aggregation protocols of sensor networks, nor do they tion are tailored to the sensor network.
consider the details of the low-level wireless protocols. DSWare [27] provides a similar kind of data service abstrac-
Among existing distributed computing middleware, QoS- tion as AutoSec, but instead of the service being provided by
Aware Middleware [23] provides the closest example of a a single sensor, it can be provided by a group of geographical-
middleware that can support sensor network applications. ly close sensors. Therefore, DSWare can transparently man-
This middleware is responsible for managing local operating age sensor failures as long as enough sensors remain in an
system resources based on application requirements specified area to provide a valid measurement.
to the middleware. The application’s QoS information is com- While these middleware for sensor networks focus on the
piled into a QoS profile to guide the middleware in making form of the data presented to the user applications, Impala
resource use decisions. [28], designed for use in the ZebraNet project, considers the

IEEE Network • January/February 2004 9

 Application/sensors
MiLAN API
MiLAN Middleware Linking Applications
Plugin abstraction and Networks (MiLAN) that
receives a description of applica-
tion requirements, monitors net-
work conditions, and optimizes
sensor and network configurations
to maximize application lifetime.
To accomplish these goals, appli-
cations represent their require-
Remote Remote Remote
Data Bluetooth-
network specific Data network
802.11- Data network
Network- ments to MiLAN through
channels control channels control specific channels control specific
local local local specialized graphs that incorporate
network network network state-based changes in application
L2CAP control TCP/UDP control Transport control needs. Based on this information,
MiLAN makes decisions about
HCI IP/Ad Hoc routing Routing how to control the network as well
as the sensors themselves to bal-
Bluetooth stack 802.11 MAC MAC ance application QoS and energy
efficiency, lengthening the lifetime
Bluetooth radio 802.11 radio Physical
of the application.
Unlike traditional middleware
Bluetooth network IEEE 802.11 network Generic network that sits between the application
and the operating system, MiLAN
■ Figure 4. Milan components (shaded). Milan presents an API through which the application has an architecture that extends
represents its requirements with regard to different sensors that may be available. Milan also into the network protocol stack, as
presents an abstraction from the network-level functionality through which it issues com- shown in Fig. 4. As MiLAN is
mands to determine available sensors and configure the network. intended to sit on top of multiple
physical networks, an abstraction
layer is provided that allows net-
application itself, exploiting mobile code techniques to change work-specific plugins to convert MiLAN commands to proto-
the functionality of the middleware executing at a remote sen- col-specific commands that are passed through the usual
sor. The key to energy efficiency for Impala is for the sensor network protocol stack. Therefore, MiLAN can continuously
node applications to be as modular as possible, enabling small adapt to the specific features of whichever network is being
updates that require little transmission energy. used for communication (e.g., determining scatternet forma-
Although each of these middleware is designed for efficient tions in Bluetooth networks or coordinator roles in Span [6])
use of the wireless sensor network, they largely ignore the in order to best meet the applications’ needs over time.
properties of the network itself. In other words, most of these Figure 5 shows an overview of the interactions among
approaches do not attempt to change the properties of the MiLAN, the applications, and the sensors, together with a
network in order to manage energy, and they are not flexible partial API. This figure makes a distinction between the net-
enough to support different protocol stacks or different appli- work plugins and the core of MiLAN, emphasizing the sepa-
cations’ QoS requirements. ration of computation that is specific to the selected network
type vs. the computation that always occurs, but the API spec-
ifies only the application- and sensor-level operations. To
MiLAN Middleware make the description of the MiLAN API and network plugin
As the summary of related work in the previous section abstraction more concrete, we use the personal health moni-
shows, most sensor network research has focused on designing tor application from earlier as a running example.
new network-level protocols (e.g., MAC layer, routing layer,
topology control), without considering existing standards or Application Performance
how applications use the protocols. We argue that sensor net- Many sensor network applications are designed to receive
work applications may be built on top of existing protocols, data input from multiple sensors and to adapt as the available
and thus some coordination framework is needed to leverage sensors change over time, as either new sensors come within
the flexibility that exists in both standardized and
nonstandardized network protocols.
However, to make these protocols more use- Set # Sensors
ful, application designers would benefit from a
middleware that encapsulates the protocols, pro- 1 Blood flow, respiratory rate
viding a high-level interface. Although the mid- 2 Blood flow, ECG (3 leads)
dleware systems discussed provide reasonable
APIs, they either invent their own energy man- 3 Pulse oxymeter, blood pressure, ECG (1 lead), respiratory rate
agement protocols or provide limited mecha-
nisms to adapt to the constraints of the wireless 4 Pulse oxymeter, blood pressure, ECG (3 leads)
network. We argue that additional savings can be 5 Oxygen measurement, blood pressure, ECG (1 lead), respiratory rate
achieved if the middleware varies the actual
parameters of the network over time while simul- 6 Oxygen measurement, blood pressure, ECG (3 leads)
taneously meeting the requirements of the appli-
cation, thereby increasing the lifetime of the ■ Table 1. Feasible sets FA for the personal health monitor application for a
network. patient in medium stress with high heart rate, normal respiratory rate, and low
We are developing a new middleware named blood pressure.

10 IEEE Network • January/February 2004

 MiLAN
network
Sensor(s) plug-in MiLAN Application(s)

oS gra ph
Sensor Q
Determine le
ed variab
network State-bas ents graph
type requirem

State A

Calculate /* application : set Qos */

FA int define_qos_graph (SQoS *sqos);

Node discov B
ery
/* application: set variable requirements */
Calculate int define_variable_graph (SVRG *svrg);
FN

FN
/* sensor: push data */
int send_data (int dest_milan_id, int data_length,
Tradeoff char *data)
among
FA∩FN

fi
/* application : set system state */
int update_state (int state);
Configure f i

Data C /* upcall - MILAN gives data to application */

int recv_data (int *src_milan_id, int *data_length,
unsigned char *data, int *packet_type);

(a) (b)

■ Figure 5. a) A high-level overview of MiLAN operation. Segment A repeats when the application changes its state based on data
received from the sensors. Segment B repeats when sensors arrive in the network. Segment C repeats as data arrives from each sensor,
and represents the normal operation of MiLAN conveying information from the sensors to the application. b) Partial MiLAN API.
Applications represent their Sensor QoS graph to MiLAN using the SQoS structure and the define_qos_graph function, and they repre-
sent their State-based Variable Requirements graph to MiLAN using the SVRG structure and the define_variable_graph function. After
initialization, sensors send data to the application using the send data function and applications receive the data from MiLAN via an
upcall from the recv_data function. Applications specify to MiLAN that they have changed state through the update_state function.

range or sensors go offline when they move away or run out • The required QoS for each variable
of energy. We assume that application performance can be • The level of QoS that data from each sensor or set of sen-
described by the QoS of different variables of interest to the sors can provide for each variable
application, where the QoS of the different variables depends Note that all of these may change based on the application’s
on which sensors provide data to the application. For exam- current state. As shown in Fig. 5, during initialization of the
ple, in the personal health monitor, variables such as blood application, this information is conveyed from the application
pressure, respiratory rate, and heart rate may be determined to MiLAN via “State-based Variable Requirements” and
based on measurements obtained from any of several sensors “Sensor QoS” graphs. Examples of these graphs are shown in
[29]. Each sensor has a certain QoS in characterizing each of Figs. 6 and 7, respectively. Figure 6a, an abstract State-based
the application’s variables. For example, a blood pressure sen- Variable Requirements graph, shows the required QoS for
sor directly measures blood pressure, so it provides a quality each variable of interest based on the current state of the sys-
of 1.0 1 in determining this variable. In addition, the blood tem and the variables of interest to the application, where
pressure sensor can indirectly measure other variables such as these states are based on the application’s analysis of previ-
heart rate, so it provides some quality, although less than 1.0, ously received data. For a particular state (a combination of
in determining these variables. The quality of the heart rate system state, level A, and variable state, level B), the State-
measurement would be improved through high-level fusion of based Variable Requirements graph defines the required QoS
the blood pressure measurements with data from additional for each relevant variable. Because variables (level C) can be
sensors such as a blood flow sensor. named in multiple variable states (level B), MiLAN must
In order to determine how to best serve the application, extract the maximum QoS for each selected variable to satisfy
MiLAN must know: the requirements for all variable states. Figure 6b shows the
• The variables of interest to the application State-based Variable Requirements graph for the personal
health monitor. This application has two states, a system state
that includes the patient’s overall stress level, as well as multi-
1 Quality is mapped to a specific reliability in determining the variable ple states for each variable that can be monitored. The State-
from the sensor’s data, with 1.0 corresponding to 100 percent reliability. based Variable Requirements graph specifies to MiLAN the

IEEE Network • January/February 2004 11

 System state User stress state
A SS=1 SS=2 SS=3 None Low Med High

BP HR
Norm Norm
System state V2 state .3 .3
B Blood Heart
SV1=1 SV1=2 SV1=M SV2=1 SV2=N pressure rate Heart rate
High/ High
Norm low (+ECG)
Blood pressure Respiratory rate
q1 q2 q3 q5 High Norm Low High/
q4 Norm low
.3 .8 .8
.3
C Vi Vj Vk .8 .3 .3
.8 .7 .3 .8 .3 .3 .3 1.0 1.0
Blood Blood Resp Blood Heart Blood ECG Blood
pressure O2 rate O2 rate O2 diag. pressure

(a) (b)

■ Figure 6. The State-based Variable Requirements graph for specifying the variables and required QoS when the application is in vari-
ous states: a) abstract example; b) example for the personal health monitor application. This graph illustrates only a subset of the appli-
cation’s possible states.

application’s minimum acceptable QoS for each variable (e.g., sensors satisfy all of the application’s QoS requirements for
blood pressure or respiratory rate) based on the current state each variable. These sets of sensors define the application fea-
of the patient. For example, the figure shows that when a sible set FA, where each element in FA is a set of sensors that
patient is in a medium stress state and the blood pressure is provides QoS greater than or equal to the application-speci-
low, the blood oxygen level must be monitored at a quality fied minimum acceptable QoS for each specified variable. For
level of .7 and the blood pressure at a quality level of .8. example, in the personal health monitor, for a patient in
For a given application, the QoS for each variable can be medium stress with a high heart rate, normal respiratory rate,
satisfied using data from one or more sensors. The application and low blood pressure, the application feasible sets in FA that
specifies this information to MiLAN through the Sensor QoS MiLAN should choose to meet the specified application QoS
graph (Fig. 7a). When multiple sensors are combined to pro- are shown in Table 1. MiLAN must choose which element of
vide a certain quality level to the variable, we refer to this as a F A should be provided to the application. This decision
single virtual sensor. Figure 7b shows the Sensor QoS graph depends on network-level information.
for the personal health monitor. This graph illustrates the
important variables to monitor when determining a patient’s Network
condition and indicates the sensors that can provide at least The properties of specific network types as well as the current
some quality to the measurement of these variables. Each line condition of the network can constrain the set of feasible sets
between a sensor (or virtual sensor) and a variable is labeled to a subset of those in FA. As shown in Fig. 5, it is the network
with the quality the sensor (or virtual sensor) can provide to plugin’s job to determine which sets of nodes (sensors) can be
the measurement of that variable. For example, using data supported by the network, as well as other protocol-specific
from a blood pressure sensor, the heart rate can be deter- information, such as what role each node must play.
mined with a .7 quality level, but combining this with data MiLAN uses a service discovery protocol (such as SDP [30]
from a blood flow sensor increases the quality level to 1.0. or SLP [31]) to find new nodes and learn when nodes are no
Given the information from these graphs as well as the cur- longer accessible (due to mobility or exhausting their energy
rent application state, MiLAN can determine which sets of resources). The service discovery protocol must return impor-

Resp Blood ECG

rate press diag.
1.0
.9 .8 .7 1.0 .8 .7
.1 .5 .8
Va
Resp Blood Blood Blood Pulse
sensor ECG* pulse press flow oxy ECG1 ECG3 ECG5 ECG12
va
s1
qv
qs4v a

qs
qs5

6v Heart Body Blood

va

VS1 a rate activity O2

1.0 .7
.7 .8 .9 .6 .9
S1 S2 S3 S4 S5 S6 .8 1.0 .6 .7
1.0

Blood Blood Pulse Oxygen Blood Blood Pulse

ECG** press flow oxy Accel. EMG Camera EEG sensor press flow Oxy

*ECG can be used with 3, 5, or 12 leads Virtual

**ECG can be used with 1, 3, 5 or 12 leads sensor
(a) (b)

■ Figure 7. The Sensor QoS graph for specifying which sensors, or sets of sensors, can provide what level of QoS for each variable: a)
abstract example; b) example for the personal health monitor application. This graph illustrates only a subset of the variables that
should be considered by the application.

12 IEEE Network • January/February 2004

tant information about the node, such as the type of data that choose an element of F. In most sensor network applications,
can be provided by that node, the modes in which the node we want to allow the application to last as long as possible
can operate, transmission power levels, and the current resid- using the limited energy of each of the sensors. Simple
ual energy level. Using this information from each currently approaches to choosing sensor sets may yield the set f i that
available node, the network plugin must determine which sets consumes the least power or will run for the maximum life-
of nodes can be supported by the network. time before the first sensor dies. However, if we want to
If we assume that all nodes are on a single-hop centralized ensure that the application can run at the required QoS level
network, bandwidth constraints place limitations on the total as long as possible, we should instead optimize the total life-
amount of data that can be transmitted to the application. For time by intelligently choosing how long to use each feasible
example, if all nodes are on a Bluetooth piconet or an 802.11 sensor set [33]. In some cases there are multiple ways to
network operating in infrastructure mode, all nodes transmit schedule sensors so that the same total network lifetime is
data directly to the application (residing at the master in achieved. In these cases we may want to maximize the average
Bluetooth or the access point in 802.11). Therefore, the net- quality of the sensor sets over time. For some applications the
work constraint is the total rate and schedulability of all data goal may be to maximize some combination of lifetime and
transmitted. quality. MiLAN is flexible enough to incorporate any of these
However, in more complex environments such as Blue- or other optimization criteria.
tooth scatternets, 802.11 multihop networks, or hybrid net- In Fig. 5 we show this trade-off computation occurring in
works, network topology plays an important role in the core MiLAN component. After the computation is com-
determining network feasibility and power costs. For exam- plete and the first set of sensors is chosen, the MiLAN core
ple, in Bluetooth it is necessary to choose a feasible scatter- informs the plugin of the selection, and the plugin configures
net topology, where nodes selected in the feasible set allow the network accordingly, using information about the role
the network to be fully connected. In addition to ensuring the each sensor should play.
feasibility of a network configuration, we must also consider
how the power costs of nodes are affected by their roles in
the network (e.g., piconet masters or bridge nodes in Blue-
Conclusions
tooth scatternets, data aggregators in Directed Diffusion [2], Current research trends suggest the power of middleware to
coordinators in Span [6]). The power cost of using a node is a ease the application development task in complex environ-
combination of the power to run the device, the power to ments. While conventional middleware operates above the
transmit its data, the power to forward the data of other networking layer, for sensor network applications that rely on
nodes in the set, and the overhead of maintaining its role in multiple and varying sensors it is not a viable approach to
the network. These costs can be influenced by MiLAN manage the network completely independent of the needs of
through techniques such as transmission power control, effi- the application. We have argued that the needs of the applica-
cient traffic scheduling, and the setting of different sleep tion should be integrated with the management of the net-
states. In multihop networks, routing data from nodes to the work into a single unified middleware system. Through this
application also becomes an important factor. The plugin tight coupling, the middleware can trade application perfor-
should know all of the network’s protocol-specific features mance for network cost, while still retaining the separation
that can be modified and choose how to set these features to between the policy specifying how to react to a dynamic envi-
make sets feasible and energy-efficient. ronment (obtained from the application) and the mechanisms
The subsets of nodes that can be supported by the network to implement the policy (performed in the middleware). We
define a network feasible set FN . As only sets in FA provide the have shown that MiLAN, a sensor network middleware we are
required application QoS, we can combine these two con- developing to meet these goals, can aid the development of
straints to get an overall set of feasible sets: sensor network applications. For more details on the MiLAN
project, including references to related papers, please visit the
F = FA ∩ FN.
project Web page at http://www.futurehealth.rochester.edu/
For the personal health monitor, suppose that the sensors milan/.
and processors communicate using an IEEE 802.11b network.
As these networks can support overall throughput of nearly 11 References
Mb/s, the network is able to support the transmission of all [1] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “Energy-Efficient
Communication Protocol for Wireless Microsensor Networks,” IEEE Trans.
data from each of the sensor sets in F A from Table 1 in real Wireless Commun., vol. 1, no. 4, Oct. 2002, pp. 660–70.
time. However, if other applications (e.g., video gait monitor- [2] C. Intanagonwiwat, R. Govindan, and D. Estrin, “Directed Diffusion: A Scal-
ing [32]) are running simultaneously on the network and the able and Robust Communication Paradigm for Sensor Networks,” Proc.
personal health monitor application can only utilize 100 kb/s ACM MobiCom ’00, Aug. 2000.
[3] S. Singh and C. Raghavendra, “PAMAS: Power Aware Multi-Access Protocol
of the throughput, the network would not be able to support with Signalling for Ad Hoc Networks,” ACM Comp. Commun. Rev., vol. 28,
the transmission of data from the ECG sensor with either 3, 5, no. 3, July 1998, pp. 5–26.
or 12 leads. Thus, the set of network feasible sets FN will only [4] Y. Wei, J. Heidemann, and D. Estrin, “An Energy-Efficient MAC Protocol for
partially overlap with FA. This overlap is the set of feasible sets Wireless Sensor Networks,” Proc. INFOCOM 2002, June 2002.
[5] A. Cerpa and D. Estrin, “ASCENT: Adaptive Self-Configuring Sensor Net-
F and consists of sets 1, 3, and 5 in Table 1. MiLAN must work Topologies,” INFOCOM 2002, June 2002.
choose a set of sensors from one of the sets in F based on the [6] B. Chen et al., “Span: An Energy-Efficient Coordination Algorithm for Topol-
trade-offs discussed in the next section. If FA is empty, MiLAN ogy Maintenance in Ad Hoc Wireless Networks,” ACM Wireless Networks,
should raise an exception to the application, allowing it to vol. 8, no. 5, Sept. 2002.
[7] C. Schurgers et al., “Optimizing Sensor Networks in the Energy-Latency-Density
decide the appropriate action. Design Space,” IEEE Trans. Mobile Comp., vol. 1, no. 1, Jan. 2002, pp. 70–80.
[8] R. Ramanathan and R. Rosales-Hain, “Topology Control of Multihop Wireless
Trade-offs Networks Using Transmit Power Adjustment,” Proc. INFOCOM 2000, Mar.
Among the elements in F, MiLAN chooses an element fi that 2000, pp. 404–13.
[9] E. Lloyd et al., “Algorithmic Aspects of Topology Control Problems for Ad
represents the best performance/cost trade-off. How should Hoc Networks,” Proc. MobiHoc 2002, June 2002, pp. 123–34.
“best” be defined? This depends on the application; the [10] V. Rodoplu and T. Meng, “Minimum Energy Mobile Wireless Networks,”
MiLAN framework supports any method of deciding how to IEEE JSAC, vol. 17, no. 8, Aug. 1999, pp. 1333–44.

IEEE Network • January/February 2004 13

[11] D. Braginsky and D. Estrin, “Rumor Routing Algorithm for Sensor Net- [30] S. Avancha, A. Joshi, and T. Finin, “Enhanced Service Discovery in Blue-
works,” Proc. 1st ACM Int’l. Wksp. Wireless Sensor Nets. and Apps., 2002. tooth,” IEEE Comp., vol. 35, no. 6, June 2002, pp. 96–99.
[12] W. Heinzelman, J. Kulik, and H. Balakrishnan, “Adaptive Protocols for [31] Service Location Protocol (SLP), http://www.ietf.org/html.charters/svrloc-
Information Dissemination in Wireless Sensor Networks,” Proc. MobiCom charter.html
’99, Aug. 1999, pp. 174–85. [32] S. L. Dockstader and A. M. Tekalp, “Multiple Camera Tracking of Interact-
[13] OMG, “The Common Object Request Broker: Architecture and Specifica- ing and Occluded Human Motion,” Proc. IEEE, vol. 89, no. 10, Oct. 2001,
tion,” Rev. 2.2, 1998. pp. 1441–55.
[14] K. Edwards, Core JINI, Prentice Hall, 1999. [33] Mark Perillo and Wendi Heinzelman, “Simple Approaches for Providing
[15] A. L. Murphy, G. P. Picco, and G.-C. Roman, “Lime: A Middleware for Application QoS Through Intelligent Sensor Management,” Elsevier Ad Hoc
Physical and Logical Mobility,” Proc. 21st Int’l. Conf. Distrib. Comp. Sys., Net. J., vol. 1, no. 2–3, 2003, pp. 235–46.
Apr. 2001, pp. 524–33.
[16] D. Gelernter, “Generative Communication in Linda,” ACM Trans. Program- Biographies
ming Languages and Sys., vol. 7, no. 1, Jan. 1985, pp. 80–112. WENDI B. HEINZELMAN [M] ([email protected]) is an assistant professor
[17] N. Davies et al., “Limbo: A Tuple Space based Platform for Adaptive in the Department of Electrical and Computer Engineering at the University of
Mobile Applications,” Proc. Int’l. Conf. Open Distrib. Processing/Distrib. Rochester. She received a B.S. degree in electrical engineering from Cornell Uni-
Platforms, Toronto, Canada, May 1997. versity in 1995, and M.S. and Ph.D. degrees in electrical engineering and com-
[18] O. Holder, I. Ben-Shaul, and H. Gazit, “System Support for Dynamic Layout of puter science from MIT in 1997 and 2000, respectively. Her current research
Distributed Applications,” Proc. 19th Int’l. Conf. Distrib. Comp., 1999, pp. 403–11. interests lie in the areas of wireless communications and networking, mobile com-
[19] A. T. Campbell, “Mobiware: QoS Aware Middleware for Mobile Multime- puting, and multimedia communication. She is an elected member of the Design
dia Communications,” Proc. 7th IFIP Int’l. Conf. High Perf. Net. (HPN), White and Implementation of Signal Processing Systems (DISPS) Technical Committee of
Plains, NY, Apr. 1997. the Signal Processing Society, and a member of Sigma Xi and the ACM.
[20] B. D. Noble and M. Satyanarayanan, “Experience with Adaptive Mobile Appli-
cations in Odyssey,” Mobile Nets. and Apps., vol. 4, no. 4, 1999, pp. 245–54. AMY L. MURPHY [M] ([email protected]) is currently an assistant professor
[21] J. Flinn, D. Narayanan, and M. Satyanarayanan, “Self-tuned Remote Exe- in the Department of Computer Science at the University of Rochester, New York.
cution for Pervasive Computing,” Proc. Eighth IEEE HotOs Conf., She received a B.S. in computer science from the University of Tulsa in 1995,
Elmau/Oberbayern, Germany, May 2001. and M.S. and D.Sc. degrees from Washington University, St. Louis, Missouri, in
[22] D. Garlan et al., “Project Aura: Toward Distraction-Free Pervasive Comput- 1997 and 2000, respectively. Her research interests include the development of
ing,” IEEE Pervasive Comp., Apr.–June 2002. standard algorithms for mobility and the design, specification, and implementa-
[23] K. Nahrstedt et al., “QoS-Aware Middleware for Ubiquitous and Heteroge- tion of mobile middleware systems. These topics are integrated under the theme
neous Environments,” IEEE Commun. Mag., vol. 39, no. 11, 2001. of enabling the rapid development of dependable applications for both physical-
[24] P. Bonnet, J. Gehrke, and P. Seshadri, “Querying the Physical World,” IEEE ly and logically mobile environments. For more information see http://www.cs.
Pers. Commun., vol. 7, no. 10–15, Oct. 2000. rochester.edu/murphy/
[25] C. Jaikaeo, C. Srisathapornphat, and C.-C. Shen, “Querying and Tasking
in Sensor Networks,” SPIE’s 14th Annual Int’l. Symp. Aerospace/Defense HERVALDO SAMPAIO CARVALHO ([email protected])
Sensing, Simulation, and Control (Digitization of the Battlespace V), Orlan- M.Sc., M.D., is a Ph.D. candidate in the Department of Computer Science at the
do, FL, Apr. 24–28, 2000. University of Minas Gerais in Brazil. He is also a researcher in the Center for
[26] Q. Han and N. Venkatasubramanian, “Autosec: An Integrated Middleware Future Health at the University of Rochester and a professor of medicine/cardiol-
Framework for Dynamic Service Brokering,” IEEE Distrib. Sys. Online, vol. 2, ogy in the School of Medicine at the University of Brasilia in Brazil. His research
no. 7, 2001. interests are in the area of data fusion algorithms and implementation in sensor
[27] S. Li, S. Son, and J. Stankovic, “Event Detection Services Using Data Service networks and the design of a body-worn sensor network for personal long-term
Middleware in Distributed Sensor Networks,” Proc. 2nd Int’l. Wksp. Info. health monitoring.
Processing in Sensor Networks, Apr. 2003.
[28] T. Liu and M. Martonosi, “Impala: A Middleware System for Managing MARK A. PERILLO [StM] ([email protected]) is a graduate student in the
Autonomic, Parallel Sensor Systems,” ACM SIGPLAN Symp. Principles and Department of Electrical and Computer Engineering at the University of
Practice of Parallel Programming, June 2003. Rochester. He received a B.S. degree in electrical engineering in 2000 and an
[29] J. C. D. Conway et al., “Wearable Computer as a Multi-Parametric Monitor M.S. degree in electrical and computer engineering in 2002, both from the Uni-
for Physiological Signals,” Proc. IEEE Int’l. Symp. Bioinformatics and Bioengi- versity of Rochester. His current research interests lie in the area of wireless ad
neering, 2000, pp. 236–42. hoc and sensor networks. He is a member of Tau Beta Pi.

14 IEEE Network • January/February 2004