2. 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 Course Website http://www.eng.yale.edu/enalab/courses/eeng460a

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

4. Medium Access Control Control access to the shared medium (radio channel)  avoid interference between transmissions  mitigate effects of collisions (retransmit) History ALOHA CSMA MACA MACAW 802.11 S-MAC 19701980199020002010

5. 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)

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

7. Hidden terminal problem Time ABC cs DATA cs DATA Carrier sense at sender may not prevent collision at receiver

8. CSMA/CA: Collision Avoidance MACA:  Request To Send  Clear To Send  DATA MACAW (Wireless)  additional ACK Time ABC cs DATA RTS CTS Blocked ACK

9. Exposed terminal problem ABCD Time cs DATA RTS CTS Parallel CSMA transfers are synchronized by CSMA/CA Collision avoidance can be too restrictive! Blocked ACK

10. 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)

11. IEEE 802.11 Network Allocation Vector (NAV)  collision avoidance  overhearing avoidance: other nodes may sleep RTSDATA Contention Window Sender Receiver Others NAV(RTS) NAV(CTS) SIFS DIFS CTSACK

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

13. TDMA Typical WLAN setup  no direct communication between nodes  access point broadcast Traffic Control (TC) map  (new) nodes signal needs in Contention Period (CP) TCCP Frame nFrame n+2Frame n+1 downlinkuplink

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

15. ~2 kcal (per battery) <<< ~280 kcal (without cheese !) The battery crisis Limited capacity Slow increase of capacity  ~8% yearly increase (Wh/cm 3 )  doubles every 9 years

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

17. TransceiverProcessorSensorsLED 0 5 10 15 20 25 Energy consumption (mW) Transmit Receive Sleep 5 MHz1 MHz Standby LED Compass Accelerometer Light [Hoesel:2004]

18. 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 oAll nodes participate in periodic beacon generation ATIM: tell nodes in PS mode to stay awake for Rx oATIM follows a beacon sent/received oUnicast ATIM needs acknowledgement oBroadcast ATIM wakes up all nodes — no ACK

19. Energy-Efficient MAC Design  Unicast example of PS mode in 802.11 DCF

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

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

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

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

24. 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)

25. Contention-based vs. Schedule-based source of overhead performance (latency, throughput, fairness) cost (energy-efficiency) idle listeningC collisionsCC overhearingC protocol overheadC,S traffic fluctuationsC,S scalability/mobilitySS

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

27. Protocol classification Protocol ChannelsOrganizationNotification 2000 SMACS [34] FDMAframesschedule 2001 PACT [28] singleframesschedule PicoRadio [10] CDMA+tonerandomwakeup 2002 STEM [33] data+ctrlrandomwakeup Preamble sampling [6] singlerandomlistening Arisha [2] singleframesschedule S-MAC [36] singleslotslistening PCM [18] singlerandomlistening Low Power Listening [13] singlerandomlistening

28. Protocol classification 2003 Sift [17] singlerandomlistening EMACs [15] singleframesschedule T-MAC [5] singleslotslistening TRAMA [30] singleframesschedule WiseMAC [7] singlerandomlistening 2004 BMA [24] singleframesschedule Miller [27] data+tonerandomwakeup+list DMAC [26] singleslotslistening SS-TDMA [23] singleframesschedule LMAC [14]singleframeslistening B-MAC [29]singlerandomlistening

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

30. Coordinated Sleeping  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) sleep listen sleep Latency Energy

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

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

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

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

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

36. Message Passing  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 Fairness Energy Msg-level latency

37. Implementation on Testbed Nodes  Platform Mica Motes (UC Berkeley) o8-bit CPU at 4MHz, o128KB flash, 4KB RAM o20Kbps 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)

38. Experiments: two-hop network  Topology and measured energy consumption on source nodes Source 1 Source 2 Sink 1 Sink 2 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

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

40. Latency as Hops Increase  Adaptive listen significantly reduces latency causes by periodic sleeping Latency under highest traffic load Number of hops Average message latency (S) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen No sleep cycles Latency under lowest traffic load Number of hops Average message latency (S) 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen No sleep cycles

41. Throughput as Hops Increase  Adaptive listen significantly increases throughput Effective data throughput under highest traffic load Number of hops Effective data throughput (Byte/S) No sleep cycles 10% duty cycle with adaptive listen 10% duty cycle without adaptive listen Using less time to pass the same amount of data

42. Combined Energy and Throughput  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 Message inter-arrival period (S) Energy-time product per byte (J*S/byte) Energy-time cost on passing 1-byte data from source to sink No sleep cycles 10% duty cycle without adaptive listen 10% duty cycle with adaptive listen

43. 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 oEach packet can be individually acknowledged  Key features Three types of node functionalities oPAN Coordinator, Coordinator and Device Two device types oFFD – Full Function Device oRFD – Reduced Function Device

44. Frequencies and Data Rates BAND COVERAGE DATA RATE # OF CHANNEL(S) 2.4 GHz ISM Worldwide 250 kbps 16 868 MHzEurope 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

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