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 Cho Network 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 pressure Respiratory Rate Blood O2 Blood Pressure Blood O2 Heart Rate High Heart Rate ECG Diagram Blood Pressure Blood O2 Heart Rate 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 Blood pressure Heart rate Blood pulse Blood press Blood flow Pulse oxy ECG Blood press Blood flow Pulse oxy 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 Provide Application 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 Application QoS Requirement Network Monitoring 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 Network Feasible Set Sensor Network Configuration Sensor Network Application QoS Requirement Sensed Object States Network Information Overall Set Application Logic Sensor Reading Doctor ApplicationMiddleware - 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 F A Set #Sensors 1Blood flow, Respiratory rate 2Blood flow, ECG (3 leads) 3Pulse oxymeter, Blood pressure, ECG(1 lead), Respiratory rate 4Pulse oxymeter, Blood pressure, ECG(3 leads) 5Oxygen Measurement, Blood pressure, ECG(1 lead), Respiratory rate 6Oxygen 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 F N 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 a 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 = F A ∩ F N Example of Overall set F –Suppose network can’t support ECG 3, 5 12 leads, since other applications are running simultaneously Set #Sensors 1Blood flow, Respiratory rate 2Blood flow, ECG (3 leads) 3Pulse oxymeter, Blood pressure, ECG(1 lead), Respiratory rate 4Pulse oxymeter, Blood pressure, ECG(3 leads) 5Oxygen Measurement, Blood pressure, ECG(1 lead), Respiratory rate 6Oxygen measurement, Blood pressure, ECG(3 leads) Set #Sensors 1Blood flow, Respiratory rate 3Pulse oxymeter, Blood pressure, ECG(1 lead), Respiratory rate 5Oxygen Measurement, Blood pressure, ECG(1 lead), Respiratory rate Application Feasible Set F A Overall Set F F A ∩ F N

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 Dynamic Availability Energy Constrained Distributed State-based Quality of Information Limited Bandwidth 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 Dynamic Availability Energy Constrained Distributed Limited Bandwidth State-based Quality of Information Middleware for Sensor Network Applications Sensor Network Management Mechanism

Network Computing Lab., KAIST 25 MiLAN Sensor Network MiLAN Network Information Data Reading Sensor power on&off Data routing path Sensor data transmission rate Application QoS Application