1 Types of Power-Saving MACs The Sensor MAC (S-MAC) Three - PDF document

What Is Media Access Control? � Media Access Control (MAC) determines who gets access to the shared medium, and when Media Access Control � In wired settings, usually just tries to avoid Greg Hackmann contention � In wireless settings, can also significantly reduce CSE520S Fall 2007 energy consumption 2 Carrier Sense Multiple Access, Collision Avoidance (CSMA/CA) Hidden Terminal Problem CS CS 3 4 Virtual Carrier Sense: RTS/CTS Power-Saving MAC � Many applications’ expected lifetime: months or years RTS Payload � Actual lifetime: AA batteries: 2000 mAh (if you’re lucky) � CC2420 radio: 19.7 mA when idle but awake (RX mode) � 2000 mAh / 19.7 mA = 101.5 h � 6 days � CTS � This is a problem! � Solution: keep the radio asleep most of the time NAV Duty cycles on the order of 0.1% – 1% � 5 6 1

Types of Power-Saving MACs The Sensor MAC (S-MAC) � Three distinct classes of power-saving MAC protocols: � S-MAC is the first MAC protocol designed Scheduled contention: nodes periodically wake up in unison, � specifically for sensor networks contend for access to channel, then go back to sleep • S-MAC [Ye 2002], T-MAC [van Dam 2003] Channel polling: nodes independently wake up to sample radio � � Guiding assumptions: channel Many small, self-configuring nodes arranged in a multi- • B-MAC [Polastre 2004], X-MAC [Buettner 2006] � Time division multiple access (TDMA): nodes maintain hop mesh � schedule of when to wake and when they’re allowed to Node-to-base station traffic rare � transmit Maximize application-wide performance over node-level • 802.15.4 [IEEE 2003], DRAND [Rhee 2006] � Different trade-offs for latency, power consumption, fairness � runtime overhead, etc. Reduce traffic through in-network processing � Motivation for hybrid protocols: SCP [Ye 2006], Z-MAC [Rhee � Sacrifice some latency for longer lifetime � 2005], Funneling MAC [Ahn 2006] 7 8 S-MAC: Synchronized Sleeping S-MAC: Boot Phase � Nodes stay asleep most of the time Waking up in 3 s Waking up � Periodically wake for short in 5 s intervals (0.5 s) to see if Waking up anyone’s sending in 4.5 s 3 s � Very low energy consumption when traffic is low 4.5 s 5 s 3 s 4.5 s 5 s 9 10 S-MAC: Sending a Packet S-MAC: Sending a Packet � Time awake divided RTS section used for � into two parts: SYNC SYNC RTS transmitting data SYNC RTS and RTS � CSMA/CA again, followed by RTS/CTS Receiver Receiver � Node periodically CS CS send SYNC packet to Wants to SYNC Wants to SYNC keep clocks in sync CS � CSMA/CA used to contend for access Wants to send data Wants to send data to wireless channel CS CS CS Wants to SYNC & send data Wants to SYNC & send data 11 12 2

S-MAC: Sending a Packet S-MAC: Evaluation � CTS for someone else RTS -> go to sleep CTS ACK ACK Overhearing avoidance � Receiver � Sender does one RTS/CTS then sends Sleep data for rest of frame � All data packets are RTS DATA DATA ACKed RTS Winner Packet fragmentation = � higher reliability Sleep 13 14 A Look at S-MAC Berkeley MAC (B-MAC) � Power savings over standard 802.11 MAC � Long listening period is expensive Everyone stays awake unless somebody transmits � � Time synchronization overhead even when t � t network is idle � RTS/CTS and ACK overhead when sending data � Complex to implement 15 16 B-MAC: Throughput B-MAC: Power Consumption 17 18 3

A Look at B-MAC X-MAC: Room for Improvement � Low overhead when network is idle Header � Simple to implement � Better power savings, latency, and throughput than S-MAC Payload Sender Lower duty cycle -> longer preambles: � Higher average latency � Higher cost to send � Recipient Higher cost to overhear � More contention � Neighbor 19 20 X-MAC: Overhearing Avoidance X-MAC: Preamble ACKing Destination Header Destination Header Payload Payload Sender Sender ACK Recipient Recipient Neighbor Neighbor 21 22 X-MAC: Current Draw X-MAC: Latency 23 24 4

A Look at X-MAC TDMA � Better latency, throughput, and power consumption than Frame B-MAC for unicast traffic Little energy consumed by overhearing � Still simple to implement � � No improvements over B-MAC for broadcast traffic On average, cuts preamble by half -> sending packets is � still expensive Time A B C Sleep Sleep Sync Transmits Transmits Transmits Slot 25 26 SCP: Scheduled Contention + Channel A Look at TDMA Polling � Predictable latency, throughput, and duty cycle � Low packet loss due to contention � Schedules must be recreated when nodes leave/enter neighborhood t t � Time synchronization overhead � Slots wasted when scheduled node has nothing to send � Often complex to implement 27 28 SCP: Reducing Contention SCP: Adaptive Channel Polling Receiver Receiver CS CS Sender Sender Two-phase contention: CS before preamble and between Add N sub-intervals whenever packet received � � preamble & payload Reduces latency of bursty data � Lower probability of contention vs. one longer CS window � � Continue adding sub-intervals as long as they’re needed, and as long as there’s room 29 30 5

SCP: Multi-Hop Pipelining SCP: Energy Consumption Hop 2 Hop 1 Sender Sender “gives up” first regular check after sending multi- � hop traffic Whole network quickly moves into adaptive polling mode � 31 32 SCP: Multi-Hop Latency A Look at SCP � Channel polling: low overhead when idle � Scheduled contention: low cost to send � Low latency for multi-hop traffic � Complex to implement � Experimental radio data required � Overhead due to time synchronization Reduced by piggybacking on data packets � 33 34 Zebra MAC (Z-MAC): TDMA + Channel Polling A Look at Z-MAC � Reduces waste from unused slots Time A B C Sleep Sleep Sync Transmits Transmits Transmits Higher throughput and lower latency � � Throughput, latency, and duty cycle no worse than pure TDMA A � Nodes still stay awake if no one transmits � Still overhead from time sync B � Complex to implement C 35 36 6

So Why Are They Rarely Used? A Better Approach: MLA � Unified Power Management Architecture (UPMA) � MAC protocols have additional radio-dependent to the rescue! requirements beyond normal application code � Most recent addition to UPMA: MAC Layer Turn radio on and off, low latency I/O, carrier sense, � Architecture (MLA) [Klues 07] etc. Low-level abstractions of radio functionality � Typically implemented by forking radio stacks � High-level implementations of common MAC logic � Hard to implement � Must be maintained as original radio stack changes � � Implemented on TinyOS 2.0.1 � Used to create 5 platform-independent MAC � MAC layers supported by TinyOS today: layers CC1000: “experimental” B-MAC � B-MAC, X-MAC, SCP, TDMA, variant of Z-MAC � CC2420: X-MAC � 37 38 7