Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

MiLAN Middleware: Enhancing Sensor Network Applications with Proactive Network Management, Thesis of Computer Science

The unique challenges of sensor network applications and the need for a middleware solution, such as milan, to enable applications to affect the network and sensors, maximize application lifetime, and meet qos requirements. The article also explores various sensor network applications and existing middleware approaches, highlighting the limitations and proposing milan as a promising solution.

Typology: Thesis

2016/2017

Uploaded on 07/04/2017

simpsoncount
simpsoncount 🇺🇸

1 document

1 / 9

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
IEEE Network • January/February 2004
60890-8044/04/$20.00 © 2004 IEEE
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
improved fault tolerance through replication, optimal data
access via distributed object placement, and methods of
enabling high-level communication abstractions such as event
dispatching and remote invocation. The end result of this
research into distributed systems is an expanding set of mid-
dleware platforms that reside above the operating system and
below the application, abstracting lower-level functionality
such as network connectivity and providing a high-level coor-
dination interface to the application programmer.
Often the combination of characteristics from the environ-
ment and application drive the design of the middleware. For
example, consider the new class of applications for sensor net-
works with the following features:
Inherent distribution. The sensors are distributed throughout
a physical space and primarily connected wirelessly.
Dynamic availability of data sources. Either mobility through
space, addition of new sensors, or loss of existing sensors
causes the set of available sensors to change over time.
Constrained application quality of service demands. Sensor
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
changes.
Resource limitations. Both network bandwidth and sensor
energy are constrained. This is especially true when consid-
ering battery-powered sensors and wireless networks.
Cooperative applications. Sensor network applications share
available resources (e.g., sensor energy, channel bandwidth)
and either cooperate to achieve a single goal or, at the very
least, do not compete for these limited resources.
One unique feature of sensor network applications with
these properties is that simply responding to the changing
environment is insufficient to achieve the required QoS over
time. Instead, the applications must be proactive, actively
affecting the network. Most existing middleware systems do
not support such a proactive approach with respect to the net-
work, leaving reactivity as the only choice and sacrificing
application quality over time. We believe a middleware that
enables applications to affect the network and the sensors
themselves is needed to support this new and growing class of
applications for sensor networks.
F
F
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.
Middleware to Support
Sensor Network Applications
pf3
pf4
pf5
pf8
pf9

Partial preview of the text

Download MiLAN Middleware: Enhancing Sensor Network Applications with Proactive Network Management and more Thesis Computer Science in PDF only on Docsity!

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

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 improved fault tolerance through replication, optimal data access via distributed object placement, and methods of enabling high-level communication abstractions such as event dispatching and remote invocation. The end result of this research into distributed systems is an expanding set of mid- dleware platforms that reside above the operating system and below the application, abstracting lower-level functionality such as network connectivity and providing a high-level coor- dination interface to the application programmer. Often the combination of characteristics from the environ- ment and application drive the design of the middleware. For example, consider the new class of applications for sensor net- works with the following features:

  • Inherent distribution. The sensors are distributed throughout a physical space and primarily connected wirelessly.
  • Dynamic availability of data sources. Either mobility through space, addition of new sensors, or loss of existing sensors causes the set of available sensors to change over time.
  • Constrained application quality of service demands. Sensor

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 changes.

  • Resource limitations. Both network bandwidth and sensor energy are constrained. This is especially true when consid- ering battery-powered sensors and wireless networks.
  • Cooperative applications. Sensor network applications share available resources (e.g., sensor energy, channel bandwidth) and either cooperate to achieve a single goal or, at the very least, do not compete for these limited resources. One unique feature of sensor network applications with these properties is that simply responding to the changing environment is insufficient to achieve the required QoS over time. Instead, the applications must be proactive , actively affecting the network. Most existing middleware systems do not support such a proactive approach with respect to the net- work, leaving reactivity as the only choice and sacrificing application quality over time. We believe a middleware that enables applications to affect the network and the sensors themselves is needed to support this new and growing class of applications for sensor networks.

F F

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.

Middleware to Support

Sensor Network Applications

This article presents an overview of 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- dleware abstraction and showing that exist- ing middleware does not meet the specific needs of all sensor network applications. Based on this observation, we propose a new middleware for sensor networks called Middleware Linking Applications and Net- works (MiLAN). MiLAN allows sensor network applications to specify their quali- ty needs and adjusts the network character- istics to increase application lifetime while still meeting those quality needs. Specifi- cally, MiLAN receives information from:

  • The individual applications about their 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- ferent applications
  • The network about available sensors and resources such as sensor energy and channel bandwidth Combining this information, MiLAN continuously adapts the network configuration (e.g., specifying which sensors should send data, which sensors should be routers in multihop net- works, which sensors should play special roles in the network) to meet the applications’ needs while maximizing application lifetime. Figure 1 shows a high-level diagram of a system that employs MiLAN. Next we describe several sensor network applications that could benefit from a middleware like MiLAN that proactively affects different characteristics of the network. Following this, we discuss existing sensor network management and middle- ware approaches. Finally, we describe MiLAN and show how the design of a health monitor sensor application can be sim- plified using MiLAN.

Sensor Network Applications

As stated in the introduction, sensor network applications rep- resent a new class of applications that are:

  • Data-driven, meaning that the applications collect and ana- lyze data from the environment, and, depending on redun- dancy, noise, and properties of the sensors themselves, can assign a quality level to the data
  • State-based, meaning that an application’s needs with respect to sensor data can change over time based on previ- ously received data Typically sensors are battery-operated, meaning they have a limited lifetime during which they provide data to the applica- tion. A challenge of the design of sensor networks is how to maximize network lifetime while meeting application QoS requirements. For these types of applications, the needs of the application should dictate which sensors are active and the role they play in the network topology. To further illustrate this point, we discuss some specific sensor network applica- tions and how they can benefit from this form of interaction.

Environmental Surveillance

Consider an environment where multiple sensors (e.g., acous- tic, seismic, video) are distributed throughout an area such as a battlefield. A surveillance application can be designed on top of this sensor network to provide information to an end user about the environment. The application may require a

minimum percentage of sensor coverage in an area where a phenomenon is expected to occur. The sensor network may consist of sensors with overlapping coverage areas providing redundant information. If the application does not require all this redundant information, it would be desirable to conserve energy in some sensors by allowing them to sleep, thereby lengthening the lifetime of the network. For example, as sen- sors use up their limited energy, the application would like to use different sets of sensors to provide the required QoS (in this case, minimum sensor coverage area). This requires that the application manage the sensors over time. Such manage- ment can be as simple as turning sensors on and off, or as complex as selecting the routes for data to take from each sensor to the collection point in a multihop network. Further- more, the needs of the surveillance application may change as a result of previously received data. For example, if the appli- cation determines that an intrusion has occurred, the applica- 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- cult to incorporate into applications.

Home/Office Security Home/office security systems are becoming increasingly com- plex, monitoring for not only intrusion into the space but also the occurrence of substances such as fire or carbon monoxide gas. To be able to monitor the application variables, the secu- rity system must obtain data from heterogeneous sensors such as acoustic, motion, heat, and vibration sensors scattered throughout the home/office. Making these sensors wireless and battery-powered allows them to easily be placed in exist- ing homes without major household modifications. To make the sensor network last as long as possible, the application may only want a subset of the sensors activated at any time. Once a sensor’s activation has been triggered through some event, the application must analyze the data and decide how to change the configuration of active sensors. This can be modeled as the application changing state based on received data. For different application states, different sets of sensors should be activated to provide the greatest benefit to the security application. Thus, the application needs to be able to control which sensors are activated over time. At the same time, to allow the application to work as long as possible, the set of sensors activated for a given application state should be chosen wisely to reduce energy dissipation and maximize sys- tem lifetime. Furthermore, sensors whose data are very

 Figure 1. A system that employs MiLAN. Each sensor runs a (possibly scaled down) version of MiLAN. MiLAN receives information from applications about their QoS requirements, a system user about the desired interaction among the applications, and the network about available components and resources. MiLAN then decides how best to configure the network to support the applications.

Data

Data

QoS

QoS

System

QoS

App 1

App n

Network MiLAN

M

M M

M

M

M M

energy constraints of sensor networks, and their supporting protocols are heavyweight when compared to protocols tai- lored to sensor networks. Some middleware acknowledge the changing properties of wireless networks and attempt to modify their own behavior to match the conditions detected within the network. For example, both Limbo [17] and FarGo [18] reorder data exchanges or relocate components to respond to changing network conditions such as bandwidth availability or link relia- bility. At a lower level, Mobiware [19] supports various levels of QoS by adapting streams within the network with active fil- ters deployed in the routers. Other middleware systems pro- vide hooks to allow the applications to adapt. For example, applications built on the Odyssey platform [20] can register for notification of changes in the underlying network data rate. Similarly, the Spectra [21] component of Aura [22] moni- tors the network conditions and the accessible computation resources, deciding where computation should be performed based on the network transmission required to complete them as well as the expense of the computation on mobile versus fixed nodes. These advances are applicable to wireless sensor networks; however, they do not integrate any of the specific data aggregation protocols of sensor networks, nor do they consider the details of the low-level wireless protocols. Among existing distributed computing middleware, QoS- Aware Middleware [23] provides the closest example of a middleware that can support sensor network applications. This middleware is responsible for managing local operating system resources based on application requirements specified to the middleware. The application’s QoS information is com- piled into a QoS profile to guide the middleware in making resource use decisions.

Middleware for Sensor Networks

Recently, much work has targeted the development of middle- ware specifically designed to meet the challenges of wireless sensor networks, focusing on the long-lived and resource-con- strained aspects of these systems. Both the Cougar [24] and SINA [25] systems provide a dis- tributed database interface to the information from a sensor network with database-style queries. Power is managed in Cougar by distributing the query among the sensor nodes to minimize the energy consumed to collect the data and calcu- late the query result. To support the database queries, SINA incorporates low-level mechanisms for hierarchical clustering of sensors for efficient data aggregation as well as protocols that limit the retransmission of similar information from geo- graphically proximate sensor nodes. AutoSec [26], Automatic Service Composition, manages resources in a sensor network by providing access control for applications so that QoS requests are maintained. This approach is similar to middleware for standard networks because resource constraints are met on a per-sensor basis, but the techniques for collecting the current resource utiliza- tion are tailored to the sensor network. DSWare [27] provides a similar kind of data service abstrac- tion as AutoSec, but instead of the service being provided by a single sensor, it can be provided by a group of geographical- ly close sensors. Therefore, DSWare can transparently man- age sensor failures as long as enough sensors remain in an area to provide a valid measurement. While these middleware for sensor networks focus on the form of the data presented to the user applications, Impala [28], designed for use in the ZebraNet project, considers the

 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.

Reactive

Static environment

Middleware reactive

Middleware proactive

Proactive

Middleware

Enables reactive applications

Limbo Fargo

Specialized network protocols

DSWare Cougar SINA

Flexible to existing network protocols

MiLAN

Sensor network middleware

AutoSec

QoS aware middleware

Data/resource management

Impala

Code management

Odyssey Spectra

Non-adaptive

Enables proactive applications

Adaptive

LIME Jinl

Dynamic environment

Corba Linda

application itself, exploiting mobile code techniques to change the functionality of the middleware executing at a remote sen- sor. The key to energy efficiency for Impala is for the sensor node applications to be as modular as possible, enabling small updates that require little transmission energy. Although each of these middleware is designed for efficient use of the wireless sensor network, they largely ignore the properties of the network itself. In other words, most of these approaches do not attempt to change the properties of the network in order to manage energy, and they are not flexible enough to support different protocol stacks or different appli- cations’ QoS requirements.

MiLAN Middleware

As the summary of related work in the previous section shows, most sensor network research has focused on designing new network-level protocols (e.g., MAC layer, routing layer, topology control), without considering existing standards or how applications use the protocols. We argue that sensor net- work applications may be built on top of existing protocols, and thus some coordination framework is needed to leverage the flexibility that exists in both standardized and nonstandardized network protocols. However, to make these protocols more use- ful, application designers would benefit from a middleware that encapsulates the protocols, pro- viding a high-level interface. Although the mid- dleware systems discussed provide reasonable APIs, they either invent their own energy man- agement protocols or provide limited mecha- nisms to adapt to the constraints of the wireless network. We argue that additional savings can be achieved if the middleware varies the actual parameters of the network over time while simul- taneously meeting the requirements of the appli- cation, thereby increasing the lifetime of the network. We are developing a new middleware named

Middleware Linking Applications 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- ments to MiLAN through specialized graphs that incorporate state-based changes in application needs. Based on this information, MiLAN makes decisions about how to control the network as well as the sensors themselves to bal- ance application QoS and energy efficiency, lengthening the lifetime of the application. Unlike traditional middleware that sits between the application and the operating system, MiLAN has an architecture that extends into the network protocol stack, as shown in Fig. 4. As MiLAN is intended to sit on top of multiple physical networks, an abstraction layer is provided that allows net- work-specific plugins to convert MiLAN commands to proto- col-specific commands that are passed through the usual network protocol stack. Therefore, MiLAN can continuously adapt to the specific features of whichever network is being used for communication (e.g., determining scatternet forma- tions in Bluetooth networks or coordinator roles in Span [6]) in order to best meet the applications’ needs over time. Figure 5 shows an overview of the interactions among MiLAN, the applications, and the sensors, together with a partial API. This figure makes a distinction between the net- work plugins and the core of MiLAN, emphasizing the sepa- 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 make the description of the MiLAN API and network plugin abstraction more concrete, we use the personal health moni- tor application from earlier as a running example.

Application Performance Many sensor network applications are designed to receive data input from multiple sensors and to adapt as the available sensors change over time, as either new sensors come within

 Figure 4. Milan components (shaded). Milan presents an API through which the application represents its requirements with regard to different sensors that may be available. Milan also presents an abstraction from the network-level functionality through which it issues com- mands to determine available sensors and configure the network.

Application/sensors

MiLAN

MiLAN API

Plugin abstraction

HCI

L2CAP

Bluetooth- specific local network control

Remote network control

Data channels

Bluetooth stack

Bluetooth radio

Bluetooth network

IP/Ad Hoc routing

TCP/UDP

802.11- specific local network control

Remote network control

Data channels

802.11 MAC

802.11 radio

IEEE 802.11 network

Routing

Transport

Network- specific local network control

Remote network control

Data channels

MAC

Physical

Generic network

 Table 1. Feasible sets F (^) A for the personal health monitor application for a patient in medium stress with high heart rate, normal respiratory rate, and low blood pressure.

1 Blood flow, respiratory rate

2 Blood flow, ECG (3 leads)

3 Pulse oxymeter, blood pressure, ECG (1 lead), respiratory rate

4 Pulse oxymeter, blood pressure, ECG (3 leads)

5 Oxygen measurement, blood pressure, ECG (1 lead), respiratory rate

6 Oxygen measurement, blood pressure, ECG (3 leads)

Set # Sensors

application’s minimum acceptable QoS for each variable (e.g., blood pressure or respiratory rate) based on the current state of the patient. For example, the figure shows that when a patient is in a medium stress state and the blood pressure is low, the blood oxygen level must be monitored at a quality level of .7 and the blood pressure at a quality level of .8. For a given application, the QoS for each variable can be satisfied using data from one or more sensors. The application specifies this information to MiLAN through the Sensor QoS graph (Fig. 7a). When multiple sensors are combined to pro- vide a certain quality level to the variable, we refer to this as a single virtual sensor. Figure 7b shows the Sensor QoS graph for the personal health monitor. This graph illustrates the important variables to monitor when determining a patient’s condition and indicates the sensors that can provide at least some quality to the measurement of these variables. Each line between a sensor (or virtual sensor) and a variable is labeled with the quality the sensor (or virtual sensor) can provide to the measurement of that variable. For example, using data from a blood pressure sensor, the heart rate can be deter- mined with a .7 quality level, but combining this with data from a blood flow sensor increases the quality level to 1.0. Given the information from these graphs as well as the cur- rent application state, MiLAN can determine which sets of

sensors satisfy all of the application’s QoS requirements for each variable. These sets of sensors define the application fea- sible set FA, where each element in FA is a set of sensors that provides QoS greater than or equal to the application-speci- fied minimum acceptable QoS for each specified variable. For example, in the personal health monitor, for a patient in medium stress with a high heart rate, normal respiratory rate, and low blood pressure, the application feasible sets in FA that MiLAN should choose to meet the specified application QoS are shown in Table 1. MiLAN must choose which element of FA should be provided to the application. This decision depends on network-level information.

Network The properties of specific network types as well as the current condition of the network can constrain the set of feasible sets to a subset of those in FA. As shown in Fig. 5, it is the network plugin’s job to determine which sets of nodes (sensors) can be supported by the network, as well as other protocol-specific information, such as what role each node must play. MiLAN uses a service discovery protocol (such as SDP [30] or SLP [31]) to find new nodes and learn when nodes are no longer accessible (due to mobility or exhausting their energy resources). The service discovery protocol must return impor-

 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.

User stress state None

High Norm

Blood pressure Low High/ Norm low

High/ low

High Norm (+ECG)

Heart rate

Respiratory rate

Norm

Blood pressure

Blood pressure

Resp rate

Blood O

Heart rate

Blood O

ECG diag.

Blood pressure (b)

Blood O

BP

.

.8 (^) .8. .3.

.3 .8.

.3 .3 1.0 1.

.3 (^). .3.

Norm

HR

.

Low Med

(a)

V (^) i

q 1 q 2 q 3 q 4

q 5

V (^) j V (^) k

A

System state S (^) S=1 S (^) S =2 S (^) S =

System state SV1 =1 (^) S (^) V2=

V 2 state B S (^) V1=2 S (^) V1 = M S (^) V2 = N

C

High

Heart rate

 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.

.9.

Resp sensor ECG*

Resp rate

1.0 (^) .7. .

Blood press

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

ECG** Bloodflow Pulseoxy

Heart rate

.7 (^) 1.0 .8.

Blood press

Blood pulse

Pulse oxy

Blood flow

Blood press

. . .

EMG

Virtual sensor

Accel. Camera EEG

(b)

Body activity

.1 (^) .5.

ECG1 ECG3 ECG5 ECG

ECG diag.

. 1.0 .6.

Blood press

Oxygen sensor

Blood flow

Pulse Oxy

Blood O

qs (^4) v a

qs (^5) v a

qs (^6) v a

qvs

1 v (^) a

(a)

S 1 S 2

Va

VS 1

S 3 S 4 S 5 S (^6) 1.

tant information about the node, such as the type of data that can be provided by that node, the modes in which the node can operate, transmission power levels, and the current resid- ual energy level. Using this information from each currently available node, the network plugin must determine which sets of nodes can be supported by the network. If we assume that all nodes are on a single-hop centralized network, bandwidth constraints place limitations on the total amount of data that can be transmitted to the application. For example, if all nodes are on a Bluetooth piconet or an 802. network operating in infrastructure mode, all nodes transmit data directly to the application (residing at the master in Bluetooth or the access point in 802.11). Therefore, the net- work constraint is the total rate and schedulability of all data transmitted. However, in more complex environments such as Blue- tooth scatternets, 802.11 multihop networks, or hybrid net- works, network topology plays an important role in determining network feasibility and power costs. For exam- ple, in Bluetooth it is necessary to choose a feasible scatter- net topology, where nodes selected in the feasible set allow the network to be fully connected. In addition to ensuring the 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- tooth scatternets, data aggregators in Directed Diffusion [2], coordinators in Span [6]). The power cost of using a node is a combination of the power to run the device, the power to transmit its data, the power to forward the data of other nodes in the set, and the overhead of maintaining its role in the network. These costs can be influenced by MiLAN through techniques such as transmission power control, effi- cient traffic scheduling, and the setting of different sleep states. In multihop networks, routing data from nodes to the application also becomes an important factor. The plugin should know all of the network’s protocol-specific features that can be modified and choose how to set these features to make sets feasible and energy-efficient. The subsets of nodes that can be supported by the network define a network feasible set FN. As only sets in FA provide the required application QoS, we can combine these two con- straints to get an overall set of feasible sets: F = FA ∩ FN. For the personal health monitor, suppose that the sensors and processors communicate using an IEEE 802.11b network. As these networks can support overall throughput of nearly 11 Mb/s, the network is able to support the transmission of all data from each of the sensor sets in FA from Table 1 in real time. However, if other applications (e.g., video gait monitor- ing [32]) are running simultaneously on the network and the personal health monitor application can only utilize 100 kb/s of the throughput, the network would not be able to support the transmission of data from the ECG sensor with either 3, 5, or 12 leads. Thus, the set of network feasible sets FN will only partially overlap with FA. This overlap is the set of feasible sets F and consists of sets 1, 3, and 5 in Table 1. MiLAN must choose a set of sensors from one of the sets in F based on the trade-offs discussed in the next section. If FA is empty, MiLAN should raise an exception to the application, allowing it to decide the appropriate action.

Trade-offs Among the elements in F, MiLAN chooses an element f (^) i that represents the best performance/cost trade-off. How should “best” be defined? This depends on the application; the MiLAN framework supports any method of deciding how to

choose an element of F. In most sensor network applications, we want to allow the application to last as long as possible using the limited energy of each of the sensors. Simple approaches to choosing sensor sets may yield the set f (^) i that consumes the least power or will run for the maximum life- time before the first sensor dies. However, if we want to ensure that the application can run at the required QoS level as long as possible, we should instead optimize the total life- time by intelligently choosing how long to use each feasible sensor set [33]. In some cases there are multiple ways to schedule sensors so that the same total network lifetime is achieved. In these cases we may want to maximize the average quality of the sensor sets over time. For some applications the goal may be to maximize some combination of lifetime and quality. MiLAN is flexible enough to incorporate any of these or other optimization criteria. In Fig. 5 we show this trade-off computation occurring in the core MiLAN component. After the computation is com- plete and the first set of sensors is chosen, the MiLAN core informs the plugin of the selection, and the plugin configures the network accordingly, using information about the role each sensor should play.

Conclusions Current research trends suggest the power of middleware to ease the application development task in complex environ- ments. While conventional middleware operates above the networking layer, for sensor network applications that rely on multiple and varying sensors it is not a viable approach to manage the network completely independent of the needs of the application. We have argued that the needs of the applica- tion should be integrated with the management of the net- work into a single unified middleware system. Through this tight coupling, the middleware can trade application perfor- mance for network cost, while still retaining the separation between the policy specifying how to react to a dynamic envi- ronment (obtained from the application) and the mechanisms to implement the policy (performed in the middleware). We have shown that MiLAN, a sensor network middleware we are developing to meet these goals, can aid the development of sensor network applications. For more details on the MiLAN project, including references to related papers, please visit the project Web page at http://www.futurehealth.rochester.edu/ milan/.

References [1] W. Heinzelman, A. Chandrakasan, and H. Balakrishnan, “Energy-Efficient Communication Protocol for Wireless Microsensor Networks,” IEEE Trans. Wireless Commun. , vol. 1, no. 4, Oct. 2002, pp. 660–70. [2] C. Intanagonwiwat, R. Govindan, and D. Estrin, “Directed Diffusion: A Scal- able and Robust Communication Paradigm for Sensor Networks,” Proc. ACM MobiCom ’00 , Aug. 2000. [3] S. Singh and C. Raghavendra, “PAMAS: Power Aware Multi-Access Protocol with Signalling for Ad Hoc Networks,” ACM Comp. Commun. Rev., vol. 28, no. 3, July 1998, pp. 5–26. [4] Y. Wei, J. Heidemann, and D. Estrin, “An Energy-Efficient MAC Protocol for Wireless Sensor Networks,” Proc. INFOCOM 2002 , June 2002. [5] A. Cerpa and D. Estrin, “ASCENT: Adaptive Self-Configuring Sensor Net- work Topologies,” INFOCOM 2002 , June 2002. [6] B. Chen et al. , “Span: An Energy-Efficient Coordination Algorithm for Topol- ogy Maintenance in Ad Hoc Wireless Networks,” ACM Wireless Networks , vol. 8, no. 5, Sept. 2002. [7] C. Schurgers et al. , “Optimizing Sensor Networks in the Energy-Latency-Density 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 Networks Using Transmit Power Adjustment,” Proc. INFOCOM 2000, Mar. 2000, pp. 404–13. [9] E. Lloyd et al. , “Algorithmic Aspects of Topology Control Problems for Ad Hoc Networks,” Proc. MobiHoc 2002 , June 2002, pp. 123–34. [10] V. Rodoplu and T. Meng, “Minimum Energy Mobile Wireless Networks,” IEEE JSAC , vol. 17, no. 8, Aug. 1999, pp. 1333–44.