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

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

• IEEE INFOCOM 2008
• Gang Zhou
• College of William and Mary
• Jian Lu
• University of Virginia
• Chieh-Yih Wan, Mark D. Yarvis
• Intel Research
• John A. Stankovic
• University of Virginia

2
Outline

• Introduction and overview of BodyQoS
• VMAC Design
• QoS Scheduler Design
• Admission Control Design
• Performance Evaluation
• Conclusion

3
Introduction and overview of BodyQoS

• 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

4
Hurricane Katrina Relief
5
911 Terrorist Attack
6
A Typical Body Sensor Network
Limb motion muscle activity
Heart rate blood oxygen saturation
Two-Lead EKG
7
Quality of Service for Body Sensor Networks

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

• Design Constraints
• Heterogeneous resources
• Heterogeneous radio platforms

Data
Control
8
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

9
BodyQoS Contributios

• Radio-Agnostic QoS
• The Virtual MAC design allows the QoS system to
  be ported from one radio platform to another
• Testbed Implementation
• Implemented in TinyOS and evaluated on the
  MicaZ(XBOW)

10
Asymmetric Architecture

BodyQoS



11
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
12
VMAC Design
Npkt Spkt TPkt TmaxPkt TminSleep
The length of each interval The length of each interval The length of each interval The length of each interval The length of each interval The length of each interval
Tinterval
13
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference The maximum number of packets QoS Scheduler can send/receive within each interval, if there is no interference
Npkt
13
14
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
The effective data payload size in each packet that can carry application data The effective data payload size in each packet that can carry application data The effective data payload size in each packet that can carry application data The effective data payload size in each packet that can carry application data The effective data payload size in each packet that can carry application data The effective data payload size in each packet that can carry application data
Spkt
14
15
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
The minimum time needed to send out a packet, if there is no interference The minimum time needed to send out a packet, if there is no interference The minimum time needed to send out a packet, if there is no interference The minimum time needed to send out a packet, if there is no interference The minimum time needed to send out a packet, if there is no interference The minimum time needed to send out a packet, if there is no interference
Tpkt
15
16
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions The maximum time needed to send out a packet or finally report giving up, if it suffers maximum backoffs/retransmissions
TmaxPkt
16
17
VMAC Design
Tinterval Npkt Spkt TPkt TmaxPkt TminSleep
The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost The minimum time for putting radio to sleep, which includes the sleeping/activation switch time and also considers the energy cost
TminSleep
17
18
VMAC Design
BWeffective
Delivered Bytes / Actual Time
18
19
QoS Scheduler Design

• Three types of traffic
• Reserved aggregator ? mote
• Reserved mote ? aggregator
• Best-effort communication
• Delay sensitivity
• Low sensitivity Avg-Tinterval/2
• High sensitivity Avg-Tinterval/(2KmaxFre)

20
QoS Scheduler Design

• Mote ? aggregator Qos reservation
• The aggregator generates polling packets to poll
  each sensor mote for data within each time
  interval.
• Dynamically configurable parameter PL (set the
  maximum number of packets requested within a
  single polling packet)
• Sleep period Tsleep is piggybacked in each
  polling packet to notify corresponding sensor
  motes.

21
QoS Scheduler Design

• Measuring effective bandwidth
• CODA (Congestion Detection and Avoidance in
  Sensor Networks )
• IEEE 802.11b RTS-CTS-DATA-ACK
• VMAC send/receive Di packets within time Ti X Di,
  where Ti is the time for MAC to send a packet.
• The aggregator waits the mote responds for Ti X
  Di TmaxPkt

22
QoS Scheduler Design

• BWeffective(DiBytes per Packet Polling Packet
  size )/TwaitTime
• BWeffective(Num of Received PacketsBytes per
  Packet Polling Packet size )/(Ti X Di TmaxPkt)
• Polling packet was lost, BWeffective0
• BWeffective BWideal(Num of Delivered Packet/Num
  of Request Packet)

23
QoS Scheduler Design

• BWideal (NpktSpkt8)/Tinterval
• BWmovAvg ( i1) d BWeffective(1-d) BWmovAvg
  ( i )

24
QoS Scheduler Design

• Advanced scheduling algorithms
• RSVP-Light QoS Scheduling An audio / video
  stream reservation consist of a fixed bandwidth
  and time for data communication.
• Adaptive QoS Scheduling Different with TCP, the
  lost packets should receive more opportunities to
  be retransmitted, and it is important to decide
  how much time for lost packets for
  retransmissions.

25
QoS Scheduler Design

• RSVP-Light QoS Scheduling
• Di (bi Tinterval )/(Spkt 8)
• Ti TminPkt
• For VMAC to send out Di packets, BodyQoS should
  reserve a time period of TminPkt Di
• For high delay sensitivity, we modify Di
  max(bi Tinterval )/(Spkt 8), KmaxFre

26
QoS Scheduler Design

• Adaptive QoS Scheduling

Max. MAC Retrans. Time
H
H
Interference
Interference
26
27
Admission Control Design

• For aggregator ? mote Qos reservation, no polling
  packets are needed. DAM S Di, where Di (bi
  Tinterval )/(Spkt 8)
• For mote ? aggregator with low delay sensitivity
  DMAL S Di
• For mote ? aggregator with high delay DMAH S
  max Di, KmaxFre
• P(Polling overhead) KFre(DMALDMAH)/ KFre/PL

28
Admission Control Design

• Admission Decisions
• KH, KL are set within the source range0,1
• New Qos request prioritygt all admitted Qos
  requests priorities and total bandwidth lt KL
  BWmovAvg

29
Admission Control Design

• New Qos request prioritygt all admitted Qos
  requests priorities and total bandwidth gt KL
  BWmovAvg
• Low priority ? High priority, High bandwidth
  requirement? Low bandwidth requirement

30
Admission Control Design

• Bandwidth of all QoS reservations to be removed,
  including current one to be checkedgtbandwidth to
  be reclaimed? the current reservation is ignored
  and go checking next.
• Bandwidth of all QoS reservations to be removed,
  including current one to be checkedltbandwidth to
  be reclaimed? the current reservation is removed
  and go checking next.

31
Admission Control Design

• Bandwidth of all QoS reservations to be removed,
  including current one to be checkedbandwidth to
  be reclaimed? the current reservation is removed
  and stop.

32
Implementation
Easy to Port to Different Radio Platforms
Only need to modify VMAC
VMAC lt100 lines of code
BodyQoS 3700 lines of code
Most Work Done at the Aggregator
33
Implementation
34
Implementation

1. Adaptive QoS always delivers requested BW
2. Delivered BWs for RTP-Like QoS and best-effort
   reduce when interference increase
3. RTP-like QoS has better performance than
   best-effort

Aggregator Side
35
Implementation

1. Adaptive QoS always maintains 4Kbps fetching
   speed
2. Fetching speeds of RTP-Like QoS and best-effort
   reduce when interference is present
3. Fetching speed of RTP-like QoS is higher than
   that of best-effort

Mote Side
35
36
Conclusion

• Asymmetric architecture
• VMAC is developed in BodyQoS to make it
  radio-agnostic.
• Adopts an adaptive scheduling strategy during
  times of channel impairment (RF interference or
  body fading)
• Future work co-existence body sensor network,
  and develop a new transport protocol.