Doc.: IEEE 802.15-09-0336-03-0006 Submission, Slide 1 Project: IEEE P802.15 Working Group for...

doc.: IEEE 802.15-09-0336-03-0006

Submission

<July 2009>

<J.S.Yoon>, <CUNY, ETRI>Slide 1

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Submission Title: [Versatile MAC for Body Area Network Update for UWB PHY]Date Submitted: [4 May, 2009]Source: [J.S Yoon, Gahng S. Ahn, Myung J Lee, Seong-soon Joo] Company [CUNY, ETRI]Address [140th St. and Convent Ave, New York, NY, USA ]Voice:[+1-212-650-7180], FAX: [], E-Mail:[[email protected], [email protected], [email protected] , [email protected]]

Re: [Versatile MAC for BAN proposal responding to TG6 Call for Proposals (15-08-0811-03-0006-tg6- call-proposals) ]

Abstract: [This document describes a Versatile MAC that is being proposed to the TG6 group ]

Purpose: [Discussion in 802.15.6 Task Group ]

Notice: This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

doc.: IEEE 802.15-09-0336-03-0006

Submission

Versatile MAC for Body Area Networks

June S Yoon, Gahng S Ahn, Myung J Lee, Seong S. Joo

CUNY, ETRI

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Outline• Motivation • Challenges• Versatile MAC Overview• Functionalities of Each Period

– AD, CAP, Beacon, DTP, Options– Energy saving– Prioritization– Summary

• Simulation• Conclusion

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Motivation

To design a simple MAC protocol

to support various QoS for

Body Area Networks

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

MAC Design Challenges • QoS Assurance

– High reliability and guaranteed latency requirement for real time data, especially vital signs

Need deterministic structure

Special care for emergency reaction alarm

• Flexibility– Support various types (periodic, non-periodic, medical,

entertainment…) of traffic, data rate and PHYs

Instantly adaptable to application’s requirements

• Energy efficiency– Less energy consumption especially for implanted device

Need efficient active/inactive scheduling

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Versatile MAC Overviews

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Versatile MAC Features

• Versatile– Best breed of Contention based and TDMA– Supports various (burst, periodic, continuous) types of traffic

• Straightway reservation– Fast reservation and prompt adaption– Latency reduction for delay sensitive real time data

• Emergency data transmit slot– Highly adaptable to abrupt emergency data– Support high QoS and reliability

• Priority supported • Simple, easy to implement

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

BSF (BAN Superframe)

• Ad (Advertisement)– Synch, interval, address

• CAP– Reservation, Non-periodic data

• Beacon– Synch, length of slot, reservation status announcement

• DTP (Data Transmit Period)– DTS (Data Transmit Slot)

• Continuous, Periodic data

– ETS (Emergency Data Transmit Slot)• Emergency data & Periodic data

<July 2009>


TDMA Data Transmit Period

Advertisement

CAP

DTS ETS ( CAP )Beacon

Inactive PeriodOr

CAP Extension ( Optional )

Batch Ack ( Optional )

doc.: IEEE 802.15-09-0336-03-0006

Submission

Flexible BSF

• BSF flexibly adjusts its length in accordance with requirements of sensor nodes

<July 2009>


Ad

CAP

Beacon

ETS

DTS

Inactive No data slot reuest

If requested,allocate data slot

Optional CAP Extension

Full load

CAP

CAP

CAP

Inactive Inactive

Inactive Inactive

DTS DTS

DTS DTS DTS

Ad

Advertisement Interval

DTS CAP

doc.: IEEE 802.15-09-0336-03-0006

Submission

Functionalities of Each Period

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Advertisement

• The beginning of BSF (BAN Superframe) followed by contention access period

• Ban Coordinator (BC) broadcasts it at the beginning of BSF and it contains basic information such as– Synchronization– BC ID– Ad Interval, length of periods

• A newly joined node adjusts its clock, gets information on BC and BSF

<July 2009>


AI (Advertisement Interval)


Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr

CAP Extension (Optional)

Batch Ack (Optional)

doc.: IEEE 802.15-09-0336-03-0006

Submission

CAP

• Contention access period– Backoff and CCA to avoid collision

– Prioritized back-off to serve higher priority first

• Data Transmission– Command frames exchange for DTS reservation

– Non-periodic data including alarm and periodic data failed to reserve DTS can be sent

• BC collects all the DTS requests and sort them according to their priorities and slot availability– Allocate from the first available slot based on the priority order to

prevent DTS shortage

– Lower priority slots may be preempted by higher priority data

<July 2009>




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



doc.: IEEE 802.15-09-0336-03-0006

Submission

Beacon

• BC Broadcasts beacon before DTP– Notifies sync, interval, length, DTS reservation status

• All the nodes that reserved DTS should listen beacon every AI to synchronize and to check reservation status changes

• Sequential ‘Ad-CAP-Beacon’ enables straightway slot reservation and prompt accommodation to changes




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



doc.: IEEE 802.15-09-0336-03-0006

Submission

Straightway Reservation & TransmissionWhy ? How?

• In a life critical situation, e.g. patient in ER, wounded soldier in battle field, urgent reporting after initial placement of sensors is as important as emergency alarm

• Placing ‘Ad CAP Beacon’ in a row enables urgent transmission

<July 2009>


Versatile MAC

IEEE802.15.4

Reservation

Reservation Anounce

Anounce

Transmit

Transmit

doc.: IEEE 802.15-09-0336-03-0006

Submission

Data Transmit Period

• TDMA Period for the latency-critical continuous and periodic data

• BC allocates DTS first and then ETS if no more DTS is available

• Since ETS is dedicated slot for Emergency data, the node assigned to ETS performs CCA before its transmission so as to avoid collision with Emergency data

<July 2009>




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



doc.: IEEE 802.15-09-0336-03-0006

Submission

ETS for Emergency Alarm

• ETS (Emergency Data Transmit slot)

– Contention access period– Number of slot is configurable and evenly distributed

throughout DTP period– If any, emergency data is transmitted at ETS while the

node assigned to this slot performs CCA• Emergency alarm can be sent in CAP, ETS, and

CAP Extension whichever available first

– Enables urgent transmission for abrupt Emergency alarm

<July 2009>




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



doc.: IEEE 802.15-09-0336-03-0006

Submission

Options

• ECAP (CAP Extension)– The duration between the ends of DTP and next advertisement– If power is not a concern for BC, it can stay awake and extend

CAP – All kinds of data can be transmitted including retransmission

• Batch ACK– Ack at the last active slot for all data transmission in DTP

• Delayed ACK– Ack for multiple-slot transmission from a same source

<July 2009>




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



doc.: IEEE 802.15-09-0336-03-0006

Submission

Prioritization

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

BAN Data Prioritization• Prioritization based on QoS (latency) requirement

– Priority 0: Emergency alarm (CAP, ETS, CAP Extension)• Emergency vital signs, Battery depletion, ...

– Priority 1: Medical Continuous data (DTS)• Latency critical data

– E.g. EEG/ECG/EMG

– Priority 2: Medical Routine data (DTS)• Reliability critical but lesser latency requirement

– E.g. Temperature, Blood pressure

– Priority 3 : Non-medical Continuous data (DTS)• Video, audio

– Priority 4 : Non-medical, non-time sensitive (CAP)

• Priority classes are dictated by the applications

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Prioritized DTS Allocation

• For Priority classes 1, 2, and 3• Priority based allocation (1)

– Higher priority data served first in case of contention among different priority traffics

<July 2009>


• Priority based allocation (2)– Higher priority data can preempt

lower priority if no DTS is available

– This change immediately becomes effective through straightway reservation

P3P2

P1Reservation

P1 P2 P3

Priority based allocation

P2 Reservation

P1 P3

Priority based Re-allocation

P1

P1 P2P1

doc.: IEEE 802.15-09-0336-03-0006

Submission

Access Policy in CAP• Perform random back-off first then CCA before

access channel• Back-off classes

– Class 0: Priority 0 (Emergency alarm)– Class 1: Priority 1 and 2 (Medical)– Class 2: Priority greater than 2 (Non-Medical)

• Back-off unit range• Back-off period: aUnitBackoffperiod x Back-off unit

– The lower the priority the longer the back-off period

<July 2009>


[0, 2 ( 1) 1]BE Class

doc.: IEEE 802.15-09-0336-03-0006

Submission

Access Policy in ETS• Alarm may share ETS with Priority 1~3 data• Priority 1~3 data perform CCA first to avoid collision• Alarm also performs CCA for the case of contending

among multiple alarms

<July 2009>


• CCA Duration of slot owner (fixed)

= unitCCAperiod x N

• Random CCA for alarm

• CCA Duration of alarm

= [0, unitCCAperiod x (N-1)]

Data Ack

CCA of slot owner

CCA of alarm

ETS

doc.: IEEE 802.15-09-0336-03-0006

Submission

Energy Saving• Inherent advantage of TDMA architecture for power

saving over non-TDMA structure. • Coordinator

– Goes into inactive If no activity is scheduled after CAP or DTP

• Sensor (continuous data)– Once DTS reservation is done, the node stays inactive period except for

beacon and its reserved transmit time

• Sensor (routine data)– Wakeup only for report and transmit during CAP or CAP Extension

whichever available first

• Sensor (Alarm)– Wakeup only for report and transmit during CAP, CAP Extension or ETS

whichever available first

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Summary of Versatile MAC Functionalities<July 2009>




Advertisement

CAP

DTS ETS (CAP)Beacon

Inactive PeriodOr



Delayed Ack (Optional)

Dev A

Dev D

Dev C

Dev B

Dev E

Higher priority than Dev AServed first regardless of

reservation order

Alarm

BNC

Low priority DTS reservation

High priority DTS reservation

Transmission failure

Re-transmission if CAP Extension

is available

Immediate Ack

X

doc.: IEEE 802.15-09-0336-03-0006

Submission

Simulation

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Simulation Scenario• Simulation time: 5 min.• Star topology

– 1 BAN Coordinator and variable number of child nodes

• Superframe size (BO=6, SO=3)– Slot size: 7.68ms

– AI: 128 slot

– CAP: 8 slot

– Ad & Beacon: 1 slot each

• Channel capacity – 250Kbps for comparison with IEEE802.15.4

– 2Mbps for A/V application

• Channel model: CM3, 2.4Ghz– Body surface to body surface

• IEEE802.15.4: BO=6, SO=3

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Comparison: Reservation delay (From data generation to slot assignment confirm by beacon)

• Concatenate ‘Ad-CAP-Beacon’ enables reservation fast

• All nodes contend for reservation– Data generation time is uniformly distributed

• If remaining CAP time is not enough because of contention, wait & retry at the next CAP

– Longer delay than one node case

<July 2009>


0.0

0.3

0.6

0.9

1.2

1.5

1.8

2.1

0 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 128

Del

ay (

s)

Slot position when data generated

One Node Trace

IEEE802.15.4

Versatile MAC

CAP DTS DTS DTS

1.844

0.984

0.0

0.4

0.8

1.2

1.6

2.0

MaxMin

Avg

1.860

0.869

1.363

1.007

0.009

0.501

Delay

(sec

)

Seven Node ContentionIEEE802.15.4

Veratile MAC

Difference: 0.914

doc.: IEEE 802.15-09-0336-03-0006

Submission

Comparison: Emergency Alarm delay

(From alarm generation to arrival at coordinator)

<July 2009>


• Simulation time: 5 min• Packet size: 18byte• Number of node - Periodic data node: 15 - Alarm node: 1,2,3,4,5,7,10• Alarm arrival rate -1pkt/10sec (Poisson)• Number of ETS:1,3,7

0.00

0.05

0.10

0.15

0.20

0.25

0.30

0.35

0.40

0.45

1 2 3 4 5 7 10

Del

ay (

sec)

Avg. Emergency Alarm delay

15.4

1 ETS

3 ETS

7 ETS

Number of Alarm source

doc.: IEEE 802.15-09-0336-03-0006

Submission

Back-off Delay

• Simulation time: 5min• Min. Backoff Exponent=3• Max. Backoff Exponent=5• unitBackoffperiod

= 320us• Number of node

– 1 to 25 / class

<July 2009>


0

2

4

6

8

10

12

1 3 5 10 15 20 25

Del

ay (

ms)

No. of node in each class

Avg. Backoff Delay

Class 0 Class 1 Class 2

doc.: IEEE 802.15-09-0336-03-0006

Submission

Throughput

• Simulation time: 5 min• Channel capacity: 2Mbps• Number of node: 10

– EEG (5), audio, videoBody temp, Heart beat,

and Coordinator

• Data rate– Body temp: 16bps– Hear beat: 128bps– EEG: 3.2kbps– Audio: 30kbps– Video: 1Mbps

• Header: 104bit (13byte)

<July 2009>


0.0

20.0

40.0

60.0

80.0

100.0

120.0

140.0

Body Temp Heart Beat EEG Audio Video TotalThroughput(byte) 0.02 0.03 2.07 3.76 125.02 130.89

Kby

te /

sec

Throughput

doc.: IEEE 802.15-09-0336-03-0006

Submission

Conclusion• Versatile MAC

– CAP: Contention period– DTP: TDMA period, Enables high QoS

• Straightway reservation – Fast reservation, adaptation– Latency reduction

• Emergency data transmit slot– Highly adaptable to abrupt emergency data– Support high QoS and reliability

• Priority supported• Simple, easy to implement

– A little modification to IEEE802.15.4

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Channel Access Policy with UWB PHY

<month year>

<author>, <company>Slide 32

doc.: IEEE 802.15-09-0336-03-0006

Submission

Challenges

With ISM band, we could use

1)CCA after prioritized back-off in CAP

2)Random CCA in ETS

<July 2009>


But CCA is not feasible with UWB

doc.: IEEE 802.15-09-0336-03-0006

Submission

Access Policy in CAP

• CCA or Carrier sense is not feasible with UWB PHY• Aloha type of access is the only possible solution

(e.g.IEEE802.15.4a)– Aloha (Non-Beacon mode)– Slotted Aloha (Beacon mode)

• Slotted Aloha is better than Aloha but still high probability of collision

• We propose “Slotted Aloha with Prioritized Back-off”

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

• Simulation: 60 sec

• Inter-arrival time: 1pkt/sec (Poisson)

• Packet size: 16byte

<July 2009>


• BO=6, SO=3

• CAP size = 8 slot

• 1 to 5 node per each class

0

10

20

30

40

50

60

70

1 2 3 4 5

Rate

(%)

Number of Node per Class

Avg. Acknowledged Packet

Prioritized Backoff with Slotted Aloha

Slotted Aloha

doc.: IEEE 802.15-09-0336-03-0006

Submission

Channel Access in ETS (1)• Problem:

– CCA in ETS is not feasible.

– Buffered alarms try to access channel at the same time as soon as ETS begins.

– Slotted Aloha with Prioritized Backoff is not enough because random backoff may too long to deal with contentions in a short data slot.

• Solution:– ETS Preoccupancy using two way handshaking

• Nodes transmit ETS allocation request with back-off

• BNC replies a node whose request arrived first

• Only the replied node transmit emergency alarm

• Others retry at next ETS or CAP

<July 2009>


doc.: IEEE 802.15-09-0336-03-0006

Submission

Channel Access in ETS (2)• ETS is divided into N mini backoff slots,

an ETS reply slot, and an Emergency alarm slot– Each node select random backoff unit

between [0, N).

– At the selected mini slot, the node sends ETS request frame.

• Mini slot > ETS request

– After the end of backoff slots, BNC send ETS reply to the winning node whose request arrived first.

• Mini slot > ETS reply

– After receiving the ETS reply, the winning node sends an emergency alarm.

• Mini slot < Emergency Alarm

<July 2009>


Random BackoffETS request

Mini Slot

ETS reply

Backoff Window

Emergency Alarm

ETS

Date post:	14-Dec-2015
Category:	Documents
Upload:	leo-garrison
View:	216 times
Download:	1 times

Doc.: IEEE 802.15-09-0336-03-0006 Submission, Slide 1 Project: IEEE P802.15 Working Group for...

Documents