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

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Versatile MAC for Body Area Network ] 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:[jsyoon@ee.ccny.cuny.edu, gahn@ccny.cuny.edu, lee@ccny.cuny.edu , ssjoo@etri.re.kr] 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. <J.S.Yoon>, <CUNY, ETRI>

2. Versatile MAC for Body Area Networks June S Yoon, Gahng S Ahn, Myung J Lee, Seong S. Joo CUNY, ETRI <J.S.Yoon>, <CUNY, ETRI>

3. Outline • Motivation • Challenges • Versatile MAC Overview • Functionalities of Each Period • AD, CAP, Beacon, DTP, Options • Energy saving • Prioritization • Performance • Conclusion <J.S.Yoon>, <CUNY, ETRI>

4. Motivation To design a simple MAC protocol to support various QoS for Body Area Networks <J.S.Yoon>, <CUNY, ETRI>

5. 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 <J.S.Yoon>, <CUNY, ETRI>

6. Versatile MAC Overviews <J.S.Yoon>, <CUNY, ETRI>

7. 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 <J.S.Yoon>, <CUNY, ETRI>

8. 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 <J.S.Yoon>, <CUNY, ETRI>

9. Flexible BSF • BSF flexibly adjusts its length in accordance with requirements of sensor nodes <J.S.Yoon>, <CUNY, ETRI>

10. Functionalities of Each Period <J.S.Yoon>, <CUNY, ETRI>

11. 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 <J.S.Yoon>, <CUNY, ETRI>

12. CAP • Contention access period • Backoff and CCA to avoid collision • Prioritized back-off and CCA 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 first available slot based on the priority order to prevent DTS shortage • Lower priority slots may be preempted by higher priority data <J.S.Yoon>, <CUNY, ETRI>

13. 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 check reservation status changes • Sequential ‘Ad-CAP-Beacon’ enables straightway slot reservation and prompt accommodation to changes <J.S.Yoon>, <CUNY, ETRI>

14. 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 • Place Ad  CAP  Beacon in a row enables urgent transmission <J.S.Yoon>, <CUNY, ETRI>

15. 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 <J.S.Yoon>, <CUNY, ETRI>

16. 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 a 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 <J.S.Yoon>, <CUNY, ETRI>

17. 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 <J.S.Yoon>, <CUNY, ETRI>

18. Prioritization <J.S.Yoon>, <CUNY, ETRI>

19. BAN Data Prioritization • Prioritization based on QoS (latency) requirement • Priority 0: Emergency reaction alarm (CAP, ETS) • 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 <J.S.Yoon>, <CUNY, ETRI>

20. 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 • Priority based allocation (2) • Higher priority data can preempt lower priority if no DTS is available • This change immediately becomes effective through straightway reservation <J.S.Yoon>, <CUNY, ETRI>

21. 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 interval • The lower the priority the longer the back-off duration <J.S.Yoon>, <CUNY, ETRI>

22. 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 • CCA Duration of slot owner (fixed) • = unitCCAduration x N • Random CCA for alarm • CCA Duration of alarm • = [0, unitCCAdurtion x (N-1)] <J.S.Yoon>, <CUNY, ETRI>

23. 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 <J.S.Yoon>, <CUNY, ETRI>

24. Summary of Versatile MAC Functionalities <J.S.Yoon>, <CUNY, ETRI>

25. Simulation <author>, <company>

26. Simulation Scenario • Simulation time: 5 min. • Star topology • 1 BAN Coordinator and child nodes • Superframe size • Slot size: 7.68ms • AI: 128 slot • CAP: 8 slot • Ad & Beacon: 1 slot each • Data rate: 250Kbps • Channel model: CM3, 2.405Ghz • IEEE802.15.4: BO=6, SO=3 <J.S.Yoon>, <CUNY, ETRI>

27. Comparison: Reservation delay (From data generation to slot assign confirm by beacon) Difference: 119 slots <J.S.Yoon>, <CUNY, ETRI>

28. Comparison: Emergency Alarm delay (From alarm generation to arrival at coordinator) • Simulation time: 5 min • Poisson pkt arrival rate: • - 1pkt/10sec • Frame size: 144 bit • Number of node: • -1,2,3,4,5,7,10 • Number of ETS:1,3,7 • 15.4: BO=6, SO=3 <J.S.Yoon>, <CUNY, ETRI>

29. Throughput • Simulation time: 5 min • No. of ETS: 3 • No. of node: 25 nodes • -15 Periodic data node: • 1pkt/sec (3.2Kbit) • - 5 Alarm: (Poisson) 1 pkt/min • (16bit) • - 5 Non-perodic data node: • (Poisson) 1pkt/5sec (32bit) <J.S.Yoon>, <CUNY, ETRI>

30. 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 <J.S.Yoon>, <CUNY, ETRI>