250 likes | 720 Views
An Energy-Efficient MAC Protocol for Wireless Sensor Networks. Wei Ye, John Heidemann, Deborah Estrin -- Adapted the authors’ Infocom 2002 talk. Introduction. Wireless sensor network Special ad hoc wireless network Large number of nodes w/ sensors & actuators
E N D
An Energy-Efficient MAC Protocol for Wireless Sensor Networks Wei Ye, John Heidemann, Deborah Estrin -- Adapted the authors’ Infocom 2002 talk
Introduction • Wireless sensor network • Special ad hoc wireless network • Large number of nodes w/ sensors & actuators • Battery-powered nodes energy efficiency • Unplanned deployment self-organization • Node density & topology change robustness • Sensor-net applications • Nodes cooperate for a common task • In-network data processing
Primary Secondary Medium Access Control in Sensor Nets • Important attributes of MAC protocols • Collision avoidance • Energy efficiency • Scalability in node density • Latency • Fairness • Throughput • Bandwidth utilization
0.018 0.016 Flooding 0.014 0.012 0.01 (Joules/Node/Received Event) Average Dissipated Energy 0.008 Omniscient Multicast 0.006 Diffusion 0.004 0.14 Diffusion 0.002 0.12 Flooding Omniscient Multicast 0 0.1 50 100 150 200 250 300 0 0.08 Network Size Average Dissipated Energy (Joules/Node/Received Event) 0.06 Over energy-aware MAC Over always-listening MAC 0.04 0.02 0 0 50 100 150 200 250 300 Network Size Energy Efficiency in MAC • Major sources of energy waste • Idle listening • Energy consumption of typical 802.11 WLAN cards idle:receive:send — 1:1.05:1.4, 1:2:2.5 (Stemm 1997) • Example: directed diffusion (Intanagonwiwat 2000)
Reminder: IEEE 802.11 MAC • Very popular wireless MAC protocol • Two modes: DCF (distributed coordination function) & PCF (point coordination function) • DCF is based on CSMA/CA ≈ CSMA + MACA • RTS-CTS-DATA-ACK • Physical carrier sensing + NAV (network allocation vector) containing time value that indicates the duration up to which the medium is expected to be busy due to transmissions by other nodes • Every packet contains the duration info for the remainder of the message • Every node overhearing a packet continuously updates its own NAV for virtual carrier sensing • IFS (inter frame spacing) • Short IFS (SIFS), PCF IFS (PIFS), DCF IFS (DIFS), Extended IFS (EIFS)
Big problem with existing wireless MACs • Idle listening • Does anybody send me a RTS? • Does anyone send CTS to my neighbor which I want to communicate with? • Huge energy consumption! • PAMAS (Power Aware Medium Access with Signaling) • Separate radio channel for RTS/CTS • Sleep for the duration of the transmission indicated in the control packets S-MAC aims to achieve this without requiring a separate channel for RTS & CTS
Idle listening in 802.11 • RTS & CTS only reserves the medium for the first data fragment & the first ACK • The 1st fragment & ACk reserves the medium for the 2nd fragment and so on • After overhearing a fragment or an ACK, a neighboring node knows that there is one more fragment to be sent • It has to keep listening until all the fragments are sent • Promote fairness; If the sender fails to get ACK after sending a fragment, it must give up the transmission and recondtend for the medium • For in-network processing, an entire message is needed in sensor networks 802.11 may cause a largee delay
Dominant in sensornets Common to all wireless networks Energy Efficiency in MAC • Major sources of energy waste (cont.) • Idle listening • Long idle time when no sensing event happens • Collisions • Control overhead • Overhearing • Reduce energy consumption from all above sources • Combine benefits of TDMA + contention protocols
Latency Fairness Energy Sensor-MAC (S-MAC) Design • Tradeoffs • Major components in S-MAC • Periodic listen and sleep • Collision avoidance • Overhearing avoidance • Massage passing
sleep listen listen sleep Energy Latency Periodic Listen and Sleep • Problem: Idle listening consumes significant energy • Solution: Periodic listen and sleep • Turn off radio when sleeping • Reduce duty cycle to ~ 10% (200ms on/2s off)
Node 1 sleep sleep listen listen Node 2 sleep sleep listen listen Schedule 1 Schedule 2 Periodic Listen and Sleep • Schedules can differ • Prefer neighboring nodes have same schedule • — easy broadcast & low control overhead Border nodes: two schedules broadcast twice
Periodic Listen and Sleep - Choosing and Maintaining Schedules • Each nodes has a schedule table - Stores the schedules of all its known neighbors • Listens for a certain amount of time - If it doesn’t hear a schedule, it becomes a synchronizer - It randomly chooses a schedule and broadcast it in SYNC message - SYNC message indicates that it will go to sleep after t seconds
Periodic Listen and Sleep - Choosing and Maintaining Schedules • 2. If the node receives a schedule before choosing its own schedule, it follows that schedule - follower - waits for a random delay td and re-broardcasts this schedule, indicating that it will sleep in t – td • 3. If a node receives a different schedule after it selects and broadcast (border node) - adopts both schedules - less time to sleep - consume more energy
Periodic Listen and Sleep - Schedule Synchronization • Remember neighbors’ schedules — to know when to send to them • Each node broadcasts its schedule for multiple periods of sleeping and listening • Update period can be long, e.g., tens of seconds • Re-sync when receiving a schedule update • Sync packets also serve as beacons for new nodes to join a neighborhood
Periodic Listen and Sleep Listen Receiver For RTS Sleep For SYNC SYNC Sender 1 Sleep CS RTS Sender 2 CS Send data if CTS received RTS SYNC Sender 3 CS CS Send data if CTS received Figure 2. Timing relationship between a receiver and different senders
Collision Avoidance • Problem: Multiple senders want to talk • Options: Contention vs. TDMA • Solution: 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
Overhearing Avoidance • Problem: Receive packets destined to others • In 802.11, each node keeps listening to all transmissions from its neighbors for virtual carrier sensing • Each node should overhear a lot of packets not destined to itself • Solution: Sleep when neighbors talk • Basic idea from PAMAS (Singh, Raghavendra 1998) • But S-MAC only uses in-channel signaling • Who should sleep? • All immediate neighbors of sender and receiver • S-MAC lets interfering nodes go to sleep after they hear an RTS or CTS • DATA packets are normally much longer than control packets • How long to sleep? • The duration field in each packet informs other nodes the sleep interval • After hearing the RTS/CTS packet destined to a node, all the other immediate neighbors of both the sender and receiver should sleep until the NAV becomes zero
Energy Msg-level latency Fairness 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 if no ACK is received • Other nodes sleep for whole message time • Fragmentation in IEEE 802.11 • No indication of entire time — other nodes keep listening • If ACK is not received, give up Tx & recontend for medium — fairness
Energy Savings vs. Increased Latency • General delay factors • Carrier sensor delay • Backoff delay • Transmission delay • Propagation delay • Processing delay • Queuing delay • Sleep delay: S-MAC specific • A sender has to wait until the receiver wakes up
Sleep delay and Relative energy savings • Average sleep delay on the sender is 0.5Tframe = 0.5(Tlisten + Tsleep) • Relative energy saving • Es = Tsleep/Tframe = 1 – Tlisten/Tframe Duty Cycle
Platform Motes (UC Berkeley) 8-bit CPU at 4MHz, 8KB flash, 512B RAM 916MHz radio TinyOS Implementation on Testbed Nodes • Compared MAC modules • IEEE 802.11-like protocol w/o sleeping • Message passing with overhearing avoidance • S-MAC (2 + periodic listen/sleep)
Source 1 Sink 1 Sink 2 Source 2 Experiments • Topology and measured energy consumption on source nodes • Each source node sends 10 messages • — Each message has 400B in 10 fragments • Measure total energy over time to send all messages
Conclusions • S-MAC offers significant energy efficiency over always-listening MAC protocols • Sleep delay can be accumulated in intermediate hops Potential problem for real-time sensing in multiple environments • Future Plans • Measurement of throughput and latency • Throughput reduces due to latency, contention, control overhead and channel noise • Experiments on large testbeds • ~100 Motes, ~30 embedded PCs w/ MoteNIC • URL: http://www.isi.edu/scadds/