1 / 32

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 ] Date Submitted: [4 May, 2009] Source: [J.S Yoon, Gahng S. Ahn, Myung J Lee, Seong-soon Joo] Company [CUNY, ETRI]

todd
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • Summary • Simulation • 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 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 <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 synchronize and 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 • Placing ‘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 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 <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 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 <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 unit range • Back-off period: aUnitBackoffperiod x Back-off unit • The lower the priority the longer the back-off period <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) • = unitCCAperiod x N • Random CCA for alarm • CCA Duration of alarm • = [0, unitCCAperiod 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 <J.S.Yoon>, <CUNY, ETRI>

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

  27. 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 1.844 0.984 Difference: 0.914 <J.S.Yoon>, <CUNY, ETRI>

  28. Comparison: Emergency Alarm delay (From alarm generation to arrival at coordinator) • 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 <J.S.Yoon>, <CUNY, ETRI>

  29. Back-off Delay • Simulation time: 5min • Min. Backoff Exponent=3 • Max. Backoff Exponent=5 • unitBackoffperiod= 320us • Number of node • 1 to 25 / class <J.S.Yoon>, <CUNY, ETRI>

  30. Throughput • Simulation time: 5 min • Channel capacity: 2Mbps • Number of node: 10 • EEG (5), audio, videoBody temp, Heat beat, Coordinator • Data rate • Body temp: 16bps • Hear beat: 128bps • EEG: 3.2kbps • Audio: 30kbps • Video: 1Mbps • Header: 104bit (13byte) <J.S.Yoon>, <CUNY, ETRI>

  31. 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>

  32. Thank you! Welcome any collaboration! <J.S.Yoon>, <CUNY, ETRI>

More Related