150 likes | 213 Views
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ MAC Design Issues and Wake-up Radio for Wireless BANs ] Date Submitted: [May, 2008] Source: [ Feng Shu and Guido Dolmans] Company : [ Holst Centre / IMEC-NL]
E N D
Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [MAC Design Issues and Wake-up Radio for Wireless BANs] Date Submitted: [May, 2008] Source: [Feng Shu and Guido Dolmans] Company: [Holst Centre / IMEC-NL] Address [High Tech Campus 31, Eindhoven, the Netherlands] Voice:[+31 40 2774382], FAX: [+44 40 2746400], E-Mail:[{feng.shu, guido.dolmans}@imec-nl.nl] Abstract: [Presentation for MAC design issues and wake-up radio.] Purpose: [To discuss MAC design considerations and a wake-up radio for BAN] 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.
MAC Design Issues and Wake-up Radio for Wireless BANs Feng Shu and Guido Dolmans IMEC-NL May, 2008, Jacksonville
Outline • MAC layer design issues • Design challenge: Quality of Service (QoS) assurance for heterogeneous applications • Considerations on some design issues such as packet size and reliability • Integrating wake-up radio into BAN sensor nodes
accelerometer video glass Heterogeneous Traffic MAC design challenge • Single MAC for co-existent heterogeneous applications • Meeting very different QoS • Minimizing energy consumption • Main traffic types • Real-time low rate • Real-time high rate • Command & control • Other small & bulky data
QoS for BAN Applications: Examples ECG monitoring Video streaming real-time critical • Periodical data signals • Ultra low latency. eg, 50 ms • High reliability, eg, BER 10-10 • Very low data rate, eg, 7.2kbps(3-lead, 200 Hz, 12 bits ADC) real-time non-critical • Continuous data flow • Moderate latency, eg, ≈500ms • Moderate reliability, eg, BER 10-4 • Relatively higher data rate, eg, 2.8 Mbps (640x480) Energy consumption needs to be minimized!
IEEE 802.15.4 MAC: Pros and Cons Some energy saving features are attractive for BANs: Duty cycling:good trade-off between delay & energy Simplified CSMA-CA:contention-based channel access Reserved medium access:constant bandwidth applications But there are many negatives too … No QoS differentiation for multiple types of applications Not adaptive to channel quality variation Not optimized for coexistence of heterogeneous devices No guarantee for life-critical signal transmission Designed without considering human tissue protection Innovative features need to be invented to address MAC requirements for BANs!
Packet Size • Data are assembled into packets for transmission • It is not trivial to decide optimal packet sizes Short packets deliver small portion of information Long packets decrease efficiency when errored header payload packet • Consider additional issues for packet size in BANs • Sampling rate is low for many medical monitoring signals (eg, ECG, 200 Hz, respiration 10 Hz) • Delay requirements are usually strict for medical applications
Medical Monitoring: Examples 10 samples, 12-bit ADC 5 ms packetization delay MAC access, propagation, processing, etc. end-to-end delay
Make Packet size Variable • Short packet sizes are needed for medical monitoring signals to meet stringent delay requirements • It is not efficient to have short packet sizes for other traffic types such as video streaming, elastic computer data • Make packet size variable in BANs Short packets for delay-sensitive data (eg, medical) Long packets for delay-tolerant data meet delay requirements & improve system efficiency
high Efficiency app4 app1 app2 app3 app5 low Reliability Requirement low high Reliability • BAN applications have diversified reliability requirements • Medical data usually need higher reliability than non-medical • Life-critical medical signals require highest reliability • Trade-off between reliability and efficiency, eg, error control coding
Differentiating Reliability Don’t have to use same strategies for all types of data! high Efficiency app4 app1 app2 app3 app5 low low Reliability Requirement high Differentiation mechanisms are necessary to address different reliability requirements!
The Intrinsic Trade-offs Energy Throughput BANs Packet size Trans. strategies Delay Reliability
Patient - Wim • EEG • ECG • Respiration • SpO2 Wake-up Radio: A Hospital Scenario • Perhaps only some sensors are necessary to transmit at a time! • Other sensors are put to sleep, wake up immediately if necessary.
Wake-up radio circuitry Sensor node Wake-up Radio Low power listening might be desirablein BANs • Proposed solution: wake-up radio Stand-by component to watch environment, activate main radio when detecting incoming signals (eg, PicoRadio) • Extremely low power (e.g., 50 uW) • Reduce cost to a minimum Working toward a low power, low cost wake-up radio with simple signal processing capabilities
Conclusions • Identified QoS assurance as one of the greatest challenges for MAC design in BANs • Discussed two MAC layer issues: Variable packet sizes Differentiate reliability requirements • Proposed wake-up radio as low-power stand-by mode to prolong life-time of BANs