22
Body Sensor Networks: Can we use them? Pedro Brandão and Jean Bacon M-MPAC 2009 Architecture proposal for resource abstraction

Body Sensor Networks: Can we use them? · 11/30/2009  · Body Sensor Networks: Can we use them? Pedro Brandão and Jean Bacon M-MPAC 2009 Architecture proposal for resource ... 30-Nov-2009

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Body Sensor Networks: Can we use them?

Pedro Brandão and Jean Bacon

M-MPAC 2009

Architecture proposal for resource abstraction

Body Sensor Network

Blood pressure

Heart Rate

O2 level

Breathing rate

BS

Glycaemia valueMotion

Blood pressure

T-Cells value

Body Sensor Network

GPS

30-Nov-2009 2Pedro Brandão @ M-MPAC 2009

Body Sensor Network

Internet

Direct Outside

Access

Local Network

Remote client

30-Nov-2009 3Pedro Brandão @ M-MPAC 2009

What is it for? Monitoring Sport

Self-assessment

Team performance

Health At home

More effectively/comfortably at hospitals

Triage

1st responders

Human Computer Itf Impaired persons

Gaming … And there is also Actuating…

30-Nov-2009 4Pedro Brandão @ M-MPAC 2009

Motivation

ApplicationApplicationApplicationApplication

Sensor Heterogeneity

App Heterogeneity

30-Nov-2009 5Pedro Brandão @ M-MPAC 2009

Diff to WSN

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 6

• Existence of a central node (Base Station (BS))

• One Hop Communication

• Sensor heterogeneity

• Data heterogeneity

• Application heterogeneity

• Changing interest on the data

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 7

Holistic information

Resource Abstraction

Data Correlation

Middleware Approach

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 8

ApplicationApplicationApplicationApplication

Middleware

Requests(requirements)

Information +Metadata

Resources

ManagementControl

Data +Metadata

Metrics Data Correlation

Resource Abstraction

Why is it hard for the apps...

• Lack of a common framework– Have to manage each HW sensor;

– No way to specify requirements;

– Optimization/management is apps responsibility

• Ability to correlate data from the sensors– And specify requests/requirements on it;

• Dynamicity of the system:– PnP for added sensors;

– Nodes dying;

30-Nov-2009 9Pedro Brandão @ M-MPAC 2009

Middleware Node

Architecture

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 10

Middleware Node

ApplicationApplicationApplicationApplication

Middleware Central

Node

Middleware Node

Requests(requirements)

ManagementControl

Information +Metadata

Data +Metadata

Deployment/Components

Pedro Brandão @ M-MPAC 2009 11

Base Station Node

Sensor ServiceImpl.

Sensor Service

Sensor Service

Sensor ServiceImpl.

Network ITF implementation

DispatcherDaemon

Service DiscoveryDaemon

Network ITF abstraction

Network ITF implementation

NetPointsDBCommand

Daemon implement.

Command Daemon

Application

Network ITF implementation

DispatcherDaemon

Service DiscoveryDaemon

Network ITF abstraction

Network ITF implementation

NetPointsDBCommand

Daemon implement.

Command Daemon

Application

Management

30-Nov-2009..

Daemons

Pedro Brandão @ M-MPAC 2009 12

DispatcherDaemon

Service DiscoveryDaemon

Command Daemon

Network ITF abstraction

Message

Handles Fragmented Datagrams

Datagram

30-Nov-2009

Service DiscoveryState Machine diagrams

• On BS– It reacts to queries by looking

in internal DB and sending query messages (if needed)

– Receives and stores info on advertisements

• On nodes– Sends advertisements on

start and when queried

– Note: the nodes could also forward queries and send replies pointing to other nodes, but this is disabled in the implementation for BSNs

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 13

Service Discovery Objectives

• Query capability: the query mechanism should be flexible to allow generic matching of capabilities;

• Profile flexibility: it should be relatively easy to introduce a new profile description so to be able to advertise a new capability;

• Overhead: the overhead added should be kept to a minimum;

• Lower Layer Interaction: when possible it should be possible to build on functionality already provided by lower layers (eg.: notification of a new node);

• Energy aware: the SD should be as power efficient as possible so not to increase exceedingly (when compared to not using it) energy consumption.

30-Nov-2009 14Pedro Brandão @ M-MPAC 2009

Command Daemon

Command Daemon

Sensor Service

*

Sensor Profile

11

Thread Collect

Thread Send

Command Daemon implementation

1 1

1

1

Sensor Service implementation

To: • handle the on/off of the Node• build the specific SensorServices

For the reading of the specific sensor

30-Nov-2009 15Pedro Brandão @ M-MPAC 2009

Messages

• Service Discovery

– Ack/Nack

– Advert

– Query

• Commands

– Reading Requests

– Reading Replies

– Rate Change• Collection

• Sending

– Node State change

– Ack/Nack

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 16

Same

Data Structures: Profile Classes

• Classes have a DB version– Has the default instances (SunSpot, Mica2, etc)

– Knows how to code/decode to/from wire format

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 17

Other Implementation Info

• Developed on SunSpots– Temperature, Light, 3D accelerometer– Run Java on Squawk VM– 512KB RAM, ARM920T (180MHz), 4MB Flash,

802.15.4– BS is laptop

• Lib size: 120KB, but...– Generic implementation (the same code on BS and

node);– Specific implementation (network) can also be shared;– Instantiation and usage is however different.

30-Nov-2009 18Pedro Brandão @ M-MPAC 2009

Conclusion

• Framework for:– Resource (HW) abstraction;

– Management/optimization of resources;

– Aggregation/correlation of sensed data using modelling;

– Managing requests/requirements from apps;

• Reg. Resource (HW) abstraction – Protocol and data structures defined

– Service discovery capable;

– Prototype developed;

30-Nov-2009 19Pedro Brandão @ M-MPAC 2009

Res

ou

rce

A

bst

ract

ion

Dat

a C

orr

elat

ion

Future work

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 20

• Add to the sensor heterogeneity:

– Add Equivital platform;

• Management layer:

– Models’ usage;

– Handling requirements;

– Optimization;

• Security:

– Advertising/communicating to/with the intend BS.BSN: We can not use them in a holistic viewBSN: We can not use them in a holistic view, yet...

Ho

listi

c in

form

atio

n

References

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 21

• [CodeBlue] Shnayder, V., Chen, B., Lorincz, K., Fulford-Jones, T. R. F., AND Welsh, M. 2005. Sensor networks for medical care. Tech. rep., Division of Engineering and Applied Sciences Harvard University.

• [LiteMWBAN] Waluyo, A. B., Pek, I., Ying, S., WU, J., Chen, X., and Yeoh, W.-S. 2008. Litemwban: A lightweight middleware for wireless body area network. Medical Devices and Biosensors, 2008. ISSS-MDBS 2008. 5th International Summer School and Symposium on, 141–144.

• [MILAN] Heinzelman, W. B., Murphy, A. L., Carvalho, H. S., and Perillo, M. A. 2004. Middleware to support sensor network applications. Network, IEEE 18, 6–14.

30-Nov-2009 Pedro Brandão @ M-MPAC 2009 22

[email protected]

Thank you for listening.