1 / 41

Andreas Savvides andreas.savvides@yale Office: AKW 212 Tel 432-1275 Course Website

Medium Access Control Protocols Lecture 7 (Lecture material contributed by K. Langendoen(TUDelft) and W. Ye(USC/ISI)) September 23, 2004 EENG 460a / CPSC 436 / ENAS 960 Networked Embedded Systems & Sensor Networks. Andreas Savvides andreas.savvides@yale.edu Office: AKW 212 Tel 432-1275

dysis
Download Presentation

Andreas Savvides andreas.savvides@yale Office: AKW 212 Tel 432-1275 Course Website

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. Medium Access Control ProtocolsLecture 7 (Lecture material contributed by K. Langendoen(TUDelft) and W. Ye(USC/ISI))September 23, 2004EENG 460a / CPSC 436 / ENAS 960 Networked Embedded Systems &Sensor Networks Andreas Savvides andreas.savvides@yale.edu Office: AKW 212 Tel 432-1275 Course Website http://www.eng.yale.edu/enalab/courses/eeng460a

  2. Protocol stack MAC Protocol OSI Data link layer: • mapping network packets  radio frames • transmission and reception of frames over the air • error control • security (encryption) Network Layer 3 Data Link Layer 2 Physical Layer 1

  3. Medium Access Control Control access to the shared medium (radio channel) • avoid interference between transmissions • mitigate effects of collisions (retransmit) Approaches • contention-based: no coordination • schedule-based: central authority (access point)

  4. Collision-based MAC protocols ALOHA : • packet radio networks • send when ready • 18-35% channel utilization CSMA (Carrier Sense Multiple Access): • “listen before talk” • 50-80% channel utilization

  5. Hidden terminal problem A B C DATA DATA cs Time cs Carrier sense at sender may not prevent collision at receiver

  6. CSMA/CA: Collision Avoidance A B C DATA Blocked RTS CTS ACK MACA: • Request To Send • Clear To Send • DATA MACAW (Wireless) • additional ACK cs Time

  7. Exposed terminal problem A B C D DATA Blocked RTS CTS ACK cs Time Parallel CSMA transfers are synchronized by CSMA/CA Collision avoidance can be too restrictive!

  8. IEEE 802.11 Operation • infrastructure mode (access point) • ad-hoc mode Power save mechanism; not for multi-hop networks Protocol • carrier sense • collision avoidance (optional)

  9. IEEE 802.11 DIFS SIFS RTS DATA Sender SIFS SIFS DIFS CTS ACK Receiver NAV(CTS) NAV(RTS) Contention Window Others Network Allocation Vector (NAV) • collision avoidance • overhearing avoidance: other nodes may sleep

  10. Schedule-based MAC protocols Communication is scheduled in advance • no contention • no overhearing • support for delay-bound traffic (voice) Time-Division Multiple Access • time is divided into slotted frames • access point broadcasts schedule • coordination between cells required

  11. TDMA Frame n Frame n+1 Frame n+2 TC downlink uplink CP Typical WLAN setup • no direct communication between nodes • access point broadcast Traffic Control (TC) map • (new) nodes signal needs in Contention Period (CP)

  12. Requirements for Sensor Networks Handle scarce resources • CPU: 1 – 10 MHz • memory: 2 – 4 KB RAM • radio: ~100 Kbps • energy: small batteries Unattended operation • plug & play, robustness • long lifetime

  13. Sensor Node Energy Roadmap (DARPA) -Rehosting to Low Power COTS (10x) -Simple Power Management -Algorithm Optimization (10x) -System-On-Chip -Adv Power Management -Algorithms (50x) 10,000 1,000 100 10 1 • Deployed (5W) • PAC/C Baseline (.5W) Average Power (mW) • (50 mW) • (1mW) software does it! 2000 2002 2004 [Srivastava:2002]

  14. Transceiver Processor LED Sensors Energy consumption (mW) 25 20 15 10 5 0 LED Light 5 MHz 1 MHz Sleep Standby Receive Transmit Compass Accelerometer [Hoesel:2004]

  15. Energy-Efficient MAC Design • Power save (PS) mode in IEEE 802.11 DCF • Assumption: all nodes are synchronized and can hear each other (single hop) • Nodes in PS mode periodically listen for beacons & ATIMs (ad hoc traffic indication messages) • Beacon: timing and physical layer parameters • All nodes participate in periodic beacon generation • ATIM: tell nodes in PS mode to stay awake for Rx • ATIM follows a beacon sent/received • Unicast ATIM needs acknowledgement • Broadcast ATIM wakes up all nodes — no ACK

  16. Energy-Efficient MAC Design • Unicast example of PS mode in 802.11 DCF

  17. Communication patterns local gossip convergecast WSN applications: • local collaboration when detecting a physical phenomenon • periodic reporting to sink Characteristics • low data rates • small messages • fluctuations (in time and space) <1000 bps ~25 bytes [Kulkarni:2004]

  18. Design guidelines • switch radio off when possible (duty cycle) • AND, minimize number of switches • low complexity (memory footprint) • trade off performance for energy • optimize for traffic patterns

  19. Energy-efficient medium access control Performance/Cost trade-off • latency • throughput • fairness • energy consumption Organizational/Flexibility trade-off • contention-based • schedule-based

  20. Sources of overhead • idle listening (to handle potentially incoming messages) • collisions (wasted resources at sender and receivers) • overhearing (communication between neighbors) • protocol overhead (headers and signaling) • traffic fluctuations (overprovisioning and/or collapse) • scalability/mobility (additional provisions)

  21. Contention-based vs. Schedule-based

  22. Energy-efficient MAC protocols WSN-specific protocols • starting from 2000 (1 paper) • exponential growth (2004, 16+ papers) Classification (up to May 2004, 20 papers) • the number of channels used • the degree of organization between nodes • the way in which a node is notified of an incoming msg

  23. Protocol classification

  24. Protocol classification

  25. Case Study: S-MAC Latency Fairness Energy • S-MAC — by Ye, Heidemann and Estrin • Tradeoffs • Major components in S-MAC • Periodic listen and sleep • Collision avoidance • Overhearing avoidance • Massage passing

  26. Coordinated Sleeping sleep listen listen sleep Energy Latency • Problem: Idle listening consumes significant energy • Solution: Periodic listen and sleep • Turn off radio when sleeping • Reduce duty cycle to ~ 10% (120ms on/1.2s off)

  27. Coordinated Sleeping Node 1 sleep sleep listen listen Node 2 sleep sleep listen listen Schedule 1 Schedule 2 • Schedules can differ • Prefer neighboring nodes have same schedule • — easy broadcast & low control overhead Border nodes: two schedules or broadcast twice

  28. Coordinated Sleeping • Schedule Synchronization • New node tries to follow an existing schedule • Remember neighbors’ schedules — to know when to send to them • Each node broadcasts its schedule every few periods of sleeping and listening • Re-sync when receiving a schedule update • Periodic neighbor discovery • Keep awake in a full sync interval over long periods

  29. Coordinated Sleeping RTS CTS CTS listen listen t1 t2 • Adaptive listening • Reduce multi-hop latency due to periodic sleep • Wake up for a short period of time at end of each transmission 2 4 1 3 listen • Reduce latency by at least half

  30. Collision Avoidance • S-MAC is based on contention • Similar to IEEE 802.11 ad hoc mode (DCF) • Physical and virtual carrier sense • Randomized backoff time • RTS/CTS for hidden terminal problem • RTS/CTS/DATA/ACK sequence

  31. Overhearing Avoidance • Problem: Receive packets destined to others • Solution: Sleep when neighbors talk • Basic idea from PAMAS (Singh, Raghavendra 1998) • But we only use in-channel signaling • Who should sleep? • All immediate neighbors of sender and receiver • How long to sleep? • The duration field in each packet informs other nodes the sleep interval

  32. Message Passing Energy Msg-level latency Fairness • Problem: Sensor net in-network processing requires entire message • Solution: Don’t interleave different messages • Long message is fragmented & sent in burst • RTS/CTS reserve medium for entire message • Fragment-level error recovery — ACK — extend Tx time and re-transmit immediately • Other nodes sleep for whole message time

  33. Implementation on Testbed Nodes • Platform • Mica Motes (UC Berkeley) • 8-bit CPU at 4MHz, • 128KB flash, 4KB RAM • 20Kbps radio at 433MHz • TinyOS: event-driven • Configurable S-MAC options • Low duty cycle with adaptive listen • Low duty cycle without adaptive listen • Fully active mode (no periodic sleeping)

  34. Experiments: two-hop network Average energy consumption in the source nodes 1800 Source 1 Sink 1 1600 1400 802.11-like protocol without sleep 1200 Sink 2 Source 2 1000 Energy consumption (mJ) Overhearing avoidance 800 600 400 S-MAC w/o adaptive listen 200 0 2 4 6 8 10 Message inter-arrival period (second) • Topology and measured energy consumption on source nodes • S-MAC consumes much less energy than 802.11-like protocol w/o sleeping • At heavy load, overhearing avoidance is the major factor in energy savings • At light load, periodic sleeping plays the key role

  35. Energy Consumption over Multi-Hops Energy consumption at different traffic load 30 25 No sleep cycles 20 Energy consumption (J) 15 10 10% duty cycle without adaptive listen 5 10% duty cycle with adaptive listen 0 0 2 4 6 8 10 Message inter-arrival period (S) • 3 configurations of S-MAC • Ten-hop linear network at different traffic load • At light traffic load, periodic sleeping has significant energy savings over fully active mode • Adaptive listen saves more at heavy load by reducing latency

  36. Latency as Hops Increase 12 12 10 10 8 8 6 6 4 4 2 2 0 0 0 2 4 6 8 10 0 2 4 6 8 10 • Adaptive listen significantly reduces latency causes by periodic sleeping Latency under highest traffic load Latency under lowest traffic load 10% duty cycle without adaptive listen 10% duty cycle without adaptive listen Average message latency (S) Average message latency (S) 10% duty cycle with adaptive listen 10% duty cycle with adaptive listen No sleep cycles No sleep cycles Number of hops Number of hops

  37. Throughput as Hops Increase 220 200 180 160 140 120 100 80 60 40 20 0 0 2 4 6 8 10 • Adaptive listen significantly increases throughput Effective data throughput under highest traffic load • Using less time to pass the same amount of data No sleep cycles Effective data throughput (Byte/S) 10% duty cycle with adaptive listen 10% duty cycle without adaptive listen Number of hops

  38. Combined Energy and Throughput 3 2.5 2 1.5 1 0.5 0 0 2 4 6 8 10 Energy-time cost on passing 1-byte data from source to sink • Periodic sleeping provides excellent performance at light traffic load • With adaptive listening, S-MAC achieves about the same performance as no-sleep mode at heavy load No sleep cycles Energy-time product per byte (J*S/byte) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen Message inter-arrival period (S)

  39. IEEE 802.15.4 MAC Protocol • Based on an IEEE standard for WPAN • Goal: Ultra-low cost, low power radios • Support multiple configurations (e.g point-to-point, groups, ad-hoc etc) • CSMA-CA based protocol • Each packet can be individually acknowledged • Key features • Three types of node functionalities • PAN Coordinator, Coordinator and Device • Two device types • FFD – Full Function Device • RFD – Reduced Function Device

  40. Frequencies and Data Rates BANDCOVERAGE DATA RATE# OF CHANNEL(S) 2.4 GHz ISM Worldwide 250 kbps 16 868 MHz Europe 20 kbps 1 915 MHz ISM Americas 40 kbps 10 See class website for more information about Zigbee More abut MAC protocols on the next lecture

  41. Paper Reading • [Elson02] Fine-Grained Network Time Synchronization using Reference Broadcasts, Jeremy Elson, Lewis Girod and Deborah EstrinIn Proceedings of the Fifth Symposium on Operating Systems Design and Implementation (OSDI 2002), Boston, MA. December 2002. UCLA Technical Report 020008.  • You should all read this paper closely before lecture 9!

More Related