MiLAN: Middleware to Support Sensor Network Applications Wendi B. Heinzelman, Amy L. Murphy, Hervaldo S. Carvalho, Mark A. Perillo University of Rochester.

MiLAN: Middleware to Support Sensor Network Applications

Wendi B. Heinzelman, Amy L. Murphy,Hervaldo S. Carvalho, Mark A. Perillo

University of Rochester

Presented by Kyungmin ChoNetwork Computing Lab., KAIST

2005/05/31

Network Computing Lab., KAIST

2

Contents

• One Line Comment

• Motivation

• MiLAN

• Conclusion

• Critique

Network Computing Lab., KAIST

3

One Line Comment

• MiLAN is a middleware which goal is 1)maximizing application lifetime while 2)providing application QoS by controlling and optimizing network as well as sensors

Network Computing Lab., KAIST

4

Motivation

High respiratory rate

Normal Heart Rate

Low blood pressureRespiratory

Rate

Blood O2

BloodPressure

Blood O2

HeartRate

0.8

0.7

High Heart Rate

ECGDiagram

BloodPressure

BloodO2

HeartRate

0.3

0.8

0.3

0.8

0.3

1.0

0.3

• Personal Health Monitor Application– The QoS of the different variables of interest at each different states of patient– The state-based Variable Requirement graph

Network Computing Lab., KAIST

5

Motivation• Personal Health Monitor Application

– The QoS of the different variables depends on which sensors provide data to the application

– The Sensor QoS Graph

Bloodpressure

Heartrate

Bloodpulse

Bloodpress

Bloodflow

Pulseoxy

ECGBloodpress

Bloodflow

Pulseoxy

0.7 1.0 0.8 0.7 1.0 0.70.7 0.8

1.0

Virtual sensor

Network Computing Lab., KAIST

6

Motivation

• The characteristics of sensor network

2. Dynamic Availability

Either mobility through space, addition of new sensors, or loss of existing sensors causes the set of available sensors to change over time

3. Resource Limitation

Both network bandwidth and sensor energy are constrained. This is especially true when considering battery-powered sensors and wireless networks

1. Inherent Distribution

The sensors are distributed throughout a physical space and primarily connected wirelessly

Network Computing Lab., KAIST

7

Goal of MiLAN

ProvideApplication

QoS

Maximize Application

Lifetime

Control the network as well as the sensors

• Goal– To satisfy the given application QoS specification and

provide data to application as long as possible, MiLAN control sensor network as well as the sensors

ApplicationQoS

Requirement

NetworkMonitoring

State Of Monitored

Objects

Network Computing Lab., KAIST

8

MiLAN Components

Network Computing Lab., KAIST

9

MiLAN Network Plugin

• Functionality– Providing available sensor sets– Getting bandwidth information– Discovery sensors

• Using service discovery protocol• Ex. SDP, SLP

– Configure sensors• Data transmission rate• Sensor power on&off• Setting of different sleep states• Specifying the role of each sensors in multihop networks

Network Computing Lab., KAIST

10

MiLAN Overview

App.Feasible

Set

NetworkFeasible

Set

Sensor Network Configuration

Sensor Network

ApplicationQoS Requirement

Sensed ObjectStates

NetworkInformation

OverallSet

Application Logic

Sensor Reading

Doctor

Application Middleware - MiLAN

Trade-off computation

Network Computing Lab., KAIST

11

A High-level overview of MiLAN operation and Partial MiLAN API

Network Computing Lab., KAIST

12

Application Feasible Set FA

Set # Sensors

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)

• Multiple set of sensors, which can provide application QoS at a given state, can be derived from the state-based variable requirement graph and the sensor QoS graph

• A patient state– medium stress– high heart rate, normal respiratory rate, and low blood pressure

Network Computing Lab., KAIST

13

Network Feasible Set FN

• Network Feasible Set– Network plugin’s job– The subsets of nodes that can be supported by

the network• Suppose that the sensors and processors communicate

using an IEEE 802.11a network• It can support overall throughput of nearly 11Mb/s• However, if multiple applications are running

simultaneously on the network and the personal health monitor application can only utilize 100kb/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

Network Computing Lab., KAIST

14

Overall Set F

• F = FA ∩ FN

• Example of Overall set F– Suppose network can’t support ECG 3, 5 12 leads, since other applications are running

simultaneously

Set # Sensors

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

1 Blood flow, Respiratory rate

3 Pulse oxymeter, Blood pressure,

ECG(1 lead), Respiratory rate

5 Oxygen Measurement, Blood pressure, ECG(1 lead), Respiratory rate

Application Feasible Set FA

Overall Set F

FA ∩ FN

Network Computing Lab., KAIST

15

Trade-off Computation

• Goal– Among the elements in overall set F, MiLAN choose an element f

that represents the best performance/cost trade-off

• For getting more information about trade-off computation, refer to the paper named “Providing Application QoS through Intelligent Sensor Management” published in Elsevier Ad Hoc Network Journal, vol. 1, no. 2-3, 2003– Mathematically formulate the problem– Interpret the problem as a Generalized Maximum Flow Problem– None of the algorithms that are commonly used to solve

generalized maximum flow problem in polynomial time can be used for the sensor scheduling problem

– They use simple linear programming approach

Network Computing Lab., KAIST

16

Conclusion

• Proposed a middleware for sensor network applications– Ease the application development task– Enable applications to affect the network and

sensors themselves• Tight coupling between the needs of the application and

the management of the network

– Separate the policy (obtained from the application) and the mechanism (performed in the middleware)

Network Computing Lab., KAIST

17

Critique

• Strong Points– Application QoS requirement is actively reflected in the network

and sensors• Middleware control sensor network directly

– Application QoS is specified at each different states of monitored objects

• Weak Points– MiLAN approach is not appropriate when there are a lot of sensors

• MiLAN should know a lot of information about each sensors• Available energy, role of each sensor, network connectivity, etc.

– They didn’t present enough explanation about mechanism in detail• How to choose an element among overall set F

Network Computing Lab., KAIST

18

The END

Thank you

Network Computing Lab., KAIST

19

Supplementary Slides

Network Computing Lab., KAIST

20

State-based Variable Requirement graph

Network Computing Lab., KAIST

21

The Sensor QoS Graph

Network Computing Lab., KAIST

22

Motivation

Sensor Network Application

Sensor Network

DynamicAvailability

EnergyConstrained

Distributed

State-basedQuality of Information

LimitedBandwidth

Middleware - MiLAN

Network Computing Lab., KAIST

23

MiLAN Architecture

Network Computing Lab., KAIST

24

Middleware for Sensor Network Applications (SNA)

Sensor Network Application

Sensor Network

DynamicAvailability

EnergyConstrained

DistributedLimited

Bandwidth

State-basedQuality of Information

Middleware for Sensor Network Applications

Sensor NetworkManagement Mechanism

Network Computing Lab., KAIST

25

MiLAN

Sensor Network

MiLAN

Network InformationData Reading

Sensor power on&offData routing pathSensor data transmission rate

Application QoS

Application