BodyQoS: Adaptive and Radio-Agnostic QoS for Body Sensor Networks

BodyQoS: Adaptive and Radio-Agnostic QoS for Body Sensor Networks

Gang ZhouCollege of William and MaryJian LuUniversity of VirginiaChieh-Yih Wan, Mark D. YarvisIntel ResearchJohn A. StankovicUniversity of VirginiaIEEE INFOCOM 2008

College of William and Mary

Hurricane Katrina Relief

2


911 Terrorist Attack

3

College of William and Mary4

Health Monitoring During Emergency

Manual tracking of patient status, based on papers and phones, is the past;Real-time & continuous monitoring, through body sensor networks, is the future;


A Typical Body Sensor Network

Heart rate & blood oxygen saturation

Two-Lead EKG

Limb motion & muscle activity

Sweat

Temp.


BodyQoS GoalsBodyQoS Goals Priority-based admission control Wireless resource scheduling Providing effective bandwidth

Design ConstraintsDesign Constraints Heterogeneous resources Heterogeneous radio platforms

EKG

Light

Sweat

DataControl

Quality of Service for Body Sensor Networks

http://images.google.com/imgres?imgurl=http://www.schmiemann.de/PublishedFiles/stamps/038.gif&imgrefurl=http://www.schmiemann.de/index.php%3Fcat%3DWG4%26product%3DRP%2520109&h=33&w=34&sz=1&tbnid=Cpck8QnseL5cNM:&tbnh=33&tbnw=34&hl=en&start=12&prev=/images%3Fq%3Dekg%2Bsensor%26imgsz%3Dicon%26svnum%3D10%26hl%3Den%26lr%3D%26sa%3DN


BodyQoS Contributios

The first Running QoS System for Body Sensor Networks

Asymmetric Architecture• Most work for the aggregator• Little work for sensor nodes

Virtual MAC• Separate QoS scheduling from underlying real MAC• Easy to port to different radio platforms

Effective BW Allocation• Adaptive resource scheduling, so that statistically the delivered

BW meets QoS requirements, even during interference


Asymmetric Architecture

TransportTransport

Admission Control

Slave QoS Schduler

V-MACV-MAC

Sensor Motes Aggregator

QoS Scheduler

Slave Admission

Control

AppApp

Real MACReal MAC

Poll

Data

BodyQoS

(1) Schedule wireless resources(2) Calculate effective bandwidth(3) Put radio to sleep

(1) Abstract wireless resource for QoS scheduling

(2) Implemented by calling real MAC’s functions

① Asymmetric Architecture② Virtual MAC③ Effective BW Allocation

(1) Decide which streams to serve and which not to serve


Wireless Resource Abstraction

…...packet packet packet packet packet packet

…... …... …...…...

packet packet

…... …... …...

Tinterval Npkt Spkt TPkt TmaxPkt TminSleep





…... …... …...…...

packet packet

…... …... …...

Tinterval

Npkt Spkt TPkt TmaxPkt TminSleep

The length of each interval

Tinterval





…... …... …...…...

packet packet

…... …... …...

Npkt


The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference

Npkt





…... …... …...…...

packet packet

…... …... …...

Spkt


The effective data payload size in each packet that can carry application data

Spkt





…... …... …...…...

packet packet

…... …... …...


The minimum time needed to send out a packet, if there is no interference

Tpkt





…... …... …...…...

packet packet

…... …... …...


The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions

TmaxPkt





…... …... …...…...

packet packet

…... …... …...


The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost;

TminSleep



Virtual MAC Operation

Assigned resource to send D packets within time T

D ≥ 1 andtime left ≥ TmaxPkt?

End

Call real MAC to send the next packet

N

Update time leftD=D-1Y

Wait for real MAC returns: sendDone/failure

Delivered Bytes / Actual TimeBWeffective



If application requests BW bi, BodyQoS allocates BW bi

pkt

intervalii S

T*bD


Minimum per packet transmission time

Packet size

Interval length

The ideal case: no Interference

That is, in each interval Tinterval, QoS scheduler requests VMAC to send/receive Di packets within time Ti=Di*Tpkt

The general case: when interference is present

Effective BW Allocation


18

Interference

Max. MAC Retrans. Time

HInterference

H



Per Packet Trans. Time: *pktTpktT # Requested Packets: *

iDiD

*pktT *

iD

}T,BWBWmin{TT maxPkt

effective

idealpkt

*pkt

pkt*pkt

effectiveideali

*i TT

BWBWDD



EKGLocation

Aggregator

Adaptive QoS

Best effort

Explicit Noise

Data Collection

Temperature

RTP-Like QoS

Performance Evaluation Setup

Implemented at Intel with Imote2

Ported to MicaZ at UVA


Performance

① Adaptive QoS always delivers requested BW

② Delivered BWs for RTP-Like QoS and best-effort reduce when interference increase

③ RTP-like QoS has better performance than best-effort

135s0s 225s 315s 400s

Noise Node Off

Noise Node On 30ms per packet




ConclusionsWe designed, implemented, and evaluated the first Running QoS System for Body Sensor Networks Asymmetric Architecture

• Most work for the aggregator• Little work for sensor nodes

Virtual MAC• Separate QoS scheduling from underlying real MAC• Easy to port to different radio platforms

Effective BW Allocation• Adaptive resource scheduling, so that statistically the delivered

BW meets QoS requirements, even during interference

For more information, visit: www.cs.wm.edu/~gzhou


The End

22


Interference

Max. MAC Retrans. Time

HInterference

H



Per Packet Trans. Time: *pktTpktT # Requested Packets: *

iDiD

*pktT *

iD

effective

idealpkti

*pkt

*i BW

BW)T(DTD effective

idealpkt

*pkt BW

BWTT

}T,BWBWmin{TT maxPkt

effective

idealpkt

*pkt

pkt*pkt

effectiveideali

*i TT

BWBWDD



Implementation

01234567

ROM (kBytes)

AdmissionControl

QoSScheduler

VMAC

Mote Aggregator

Implemented at Intel with Imote2

Ported to MicaZ at UVA

1:17Most Work Done at the Aggregator

1:4 The sameVMAC <100 lines of codeBodyQoS ~3700 lines of code

Only need to modify VMACEasy to Port to Different Radio Platforms

Ported to Telos at W&M


Evaluation -- Bandwidth Delivery Ratio

① Adaptive QoS always delivers requested BW

② Delivered BWs for RTP-Like QoS and best-effort reduce when interference increase

③ RTP-like QoS has better performance than best-effort

Aggregator Side

135s0s 225s 315s 400s

Noise Node Off





Evaluation -- Data Buffer Fetching Speed

① Adaptive QoS always maintains 4Kbps fetching speed

② Fetching speeds of RTP-Like QoS and best-effort reduce when interference is present

③ Fetching speed of RTP-like QoS is higher than that of best-effort

Mote Side

135s0s 225s 315s 400s

Noise Node Off




Documents

BodyQoS: Adaptive and Radio-Agnostic QoS for Body Sensor Networks