MiLAN: Middleware to Support Sensor Network Applications Jonghak Kim, Da Huo, Hyungik Oh
2 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
3 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
4 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
5 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
6 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
7 MiLAN Components
8 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
9 A High-level overview of MiLAN operation and Partial MiLAN API
10 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
11 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
12 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
13 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
14 The END Thank you