Challenges Power management is critical for wireless sensor - PowerPoint PPT Presentation

MLA: ¡MAC ¡Layer ¡Architecture ¡ Chenyang ¡Lu ¡ Cyber-­‑Physical ¡Systems ¡Laboratory ¡ Department ¡of ¡Computer ¡Science ¡and ¡Engineering ¡

Challenges ¡ Ø Power management is critical for wireless sensor networks q Limited energy source q Lifetime from months to years Ø Gap between protocols and systems q Significant advance in power management protocols q Significant challenges to integrate them in real systems q Minimum support for power management in OS Ø Need unified architecture for flexible power management! 2

Diversity ¡of ¡MAC ¡Protocols ¡ Ø Conflicting application requirements q Energy q Latency q Throughput Ø Radio is a major consumer of energy Ø Need different MACs to meet different requirements Habitat Monitoring Tracking Structural Health Health Care 3

Current ¡Solu:on ¡ Ø Design a new MAC protocol as a monolithic stack q S-MAC q B-MAC q Z-MAC q X-MAC Backoff Control Send/Receive Interfaces Sleep Scheduling Interfaces Interfaces q RI-MAC q A-MAC Sleep Scheduling q T -MAC Send/ Receive Clear q SCP Channel Logic Radio Assessment State q Funnel-MAC Machine Backoff Controller q 802.15.4 q DRAND q …………… 4

Problem ¡with ¡Current ¡Solu:on ¡ Backoff Control Send/Receive Interfaces Sleep Scheduling Interfaces Interfaces Sleep Scheduling Send/ Receive Clear Channel Logic Radio Assessment State Machine Backoff Controller No separation between power management & core radio functionality 5

Problem ¡with ¡Current ¡Solu:on ¡ Backoff Control Send/Receive Interfaces Sleep Scheduling Interfaces Interfaces Duty Cycling Backoff Controller Radio Send/ Clear State Channel Receive Machine Assessment Logic All features jumbled into one big monolithic implementation 6

Problem: ¡Monolithic ¡Radio ¡Stack ¡ Ø Hard ¡to ¡develop ¡new ¡MAC ¡protocols ¡ q No ¡clear ¡separa9on ¡of ¡concerns ¡ q Need ¡in9mate ¡knowledge ¡of ¡en9re ¡stack ¡ Ø Hard ¡to ¡maintain ¡mul9ple ¡MAC ¡stacks ¡as ¡OS ¡evolves ¡ Ø Protocols ¡not ¡reusable ¡across ¡radio/processor ¡plaCorms ¡ ¡ 7

MLA: ¡MAC ¡Layer ¡Architecture ¡ Ø Separation of sleep sleeping from radio core [IPSN’07] Ø Components for sleep scheduling protocols [SenSys’07] q Reusable à ease development & maintenance of protocols q Platform independent à reduce porting effort Sleep Scheduling Timers Radio Core 8

MLA: ¡MAC ¡Layer ¡Architecture ¡ Ø Components implement common features of MAC protocols q Hardware-independent: portable across platforms q Hardware-dependent: portable interfaces, platform specific implementations Ø Simplifies porting to a new platform q Re-implement hardware-dependent components - once per platform q Hardware independent components stay the same Ø Support diverse MAC protocols q CSMA (contention-based), TDMA (scheduling-based), Hybrid Ø Comparable efficiency to monolithic implementations 9

B-­‑MAC: ¡An ¡Example ¡Protocol ¡ Sender: Data Preamble Sleep Receiver: Data Sleep Check the Check the Check the Channel Channel Channel and receive 10

B-­‑MAC ¡ ¡ Sender: Receiver performs Data Preamble periodic CCA check Sleep Receiver: Data Sleep Check the Check the Check the Channel Channel Channel and receive 11

B-­‑MAC ¡ ¡ Sender sends preambles equal to CCA check period Sender: Receiver performs Data Preamble periodic CCA check Sleep Receiver: Data Sleep Check the Check the Check the Channel Channel Channel and receive 12

B-­‑MAC ¡ ¡ Sender sends preambles equal to CCA check period Sender: Receiver receives Receiver performs Data Preamble data if channel periodic CCA check busy when performing Sleep Receiver: check Data Sleep Check the Check the Check the Channel Channel Channel and receive 13

B-­‑MAC: ¡ What ¡Does ¡It ¡Need? ¡ Ø Method of turning the radio on and off Ø Method of checking the channel for radio activity (CCA) Ø Periodic Timer to listen for radio activity Ø A way of sending / receiving preambles Ø A way of sending / receiving data Sleep Data Sleep Check the Check the Check the Channel Channel and receive Channel 14

Breakdown ¡of ¡B-­‑MAC ¡ Ø What does it need? q Method of turning the radio on and off q Method of checking the channel for radio activity (CCA) Radio Core 15

Breakdown ¡of ¡B-­‑MAC ¡ Ø What does it need? q Method of turning the radio on and off q Method of checking the channel for radio activity (CCA) q Periodic Timer to listen for radio activity Channel Poller Timers Radio Core 16

Breakdown ¡of ¡B-­‑MAC ¡ Ø What does it need? q Method of turning the radio on and off q Method of checking the channel for radio activity (CCA) q Periodic Timer to listen for radio activity q A way of sending preambles and data Bmac Sender Preamble Sender Channel Poller Timers Radio Core 17

Breakdown ¡of ¡B-­‑MAC ¡ Ø What does it need? q Method of turning the radio on and off q Method of checking the channel for radio activity (CCA) q Periodic Timer to listen for radio activity q A way of sending preambles and data q A way of receiving data and filtering out preambles Bmac Sender Bmac Preamble Filter Preamble Sender Channel Poller LPL Listener Timers Radio Core 18

Component ¡Library ¡ CSMA Protocols Hardware Independent Hardware Dependent Preamb mble Se Sender Ra Radio o Cor ore LPL Li LPL Liste stene ner Local Time Channe Channel Pol oller Alarm Alarm Slot Handlers (TDMA/CSMA) Time Synchronization Low Level Dispatcher Asynchron onou ous I/O Adapter 19

Component ¡Library ¡ TDMA Protocols Hardware Independent Hardware Dependent Preamble Sender Radio Core LPL Listener Loc ocal Time me Channel Poller Alarm Alarm Slot Sl ot Handlers (TDMA/CSM SMA) Time me Sy Synchron onization on Low ow Level Dispatcher Asynchronous I/O Adapter 20

Component ¡Library ¡ Hybrid Protocols Hardware Independent Hardware Dependent Preamb mble Se Sender Ra Radio o Cor ore LPL Li LPL Liste stene ner Loc ocal Time me Channel Pol Channe oller Al Alarm arm Sl Slot ot Handlers (TDMA/CSM SMA) Time me Sy Synchron onization on Low ow Level Dispatcher Asynchron onou ous I/O Adapter 21

Evalua:on ¡ Ø All evaluations performed on TelosB motes in TinyOS 2.0.1 Ø Implemented 5 MAC protocols q B-MAC, X-MAC, SCP-WUSTL, Pure TDMA, SS-TDMA Ø Measure q Reusability of components among protocols q Memory footprint compared to monolithic implementations q Throughput q Latency q Energy Consumption 22

Code ¡Reuse ¡ 1600 Lines of code 1200 Protocol-Specific 800 Reused 400 0 B-MAC X-MAC SCP- Pure SS- Wustl TDMA TDMA MAC Protocol 23

Reusability ¡of ¡Components ¡ B-MAC X-MAC SCP-Wustl Pure-TDMA SS-TDMA Channel Poller LPL Listener Preamble Sender Time Synchronization TDMA Slot Handler CSMA Slot Handler Low Level Dispatcher Async I/O Adapter Alarm Local Time Radio Core Other Comp ompon onents 3 3 4 2 2 Re Reused Comp ompon onents 6 6 8 7 8 24

Memory ¡Footprint ¡(TelosB) ¡ ROM Overhead RAM Overhead 20000 1000 15000 750 Monolithic Monolithic 10000 500 MLA MLA 5000 250 0 0 B-MAC X-MAC B-MAC X-MAC 25

Throughput ¡ 100 Throughput (kbits/s) X-MAC (MLA) X-MAC (Monolithic) 10 B-MAC (MLA) B-MAC (Monolithic) 1 1 2 3 4 5 6 7 8 9 10 Number of sending nodes 26

MLA: ¡Summary ¡ Ø Component-based, low-power MAC architecture q Increases flexibility q Simplifies development q Reduces porting effort Ø Provides evidence contrary to the existing philosophy that radio stacks must be monolithic to be efficient Ø Bridge the gap between algorithms/protocols and systems. Ø Code: tinyos-2.x-contrib/wustl/upma 27

Solve ¡the ¡Real ¡Problems ¡ Ø Hard to develop new MAC protocols? ü RI-MAC (SenSys’08) built on MLA ü More built on MLA Ø Hard to maintain multiple MAC stacks as OS evolves? ü Upgrading MLA for TinyOS 2.0.1 à 2.0.2 à 2.1 took several hours ü Multiple MAC protocols survived upgrade without any change! Ø Protocols not reusable across radio/processor platforms? ü Supports both Telos and MicaZ Ø TinyOS 2.1 version available from TinyOS “contrib” CVS 28

References ¡ Ø K. Klues, G. Hackmann, O. Chipara and C. Lu, A Component-Based Architecture for Power-Efficient Media Access Control in Wireless Sensor Networks, SenSys'07. Ø K. Klues, G. Xing and C. Lu, Link Layer Driver Architecture for Unified Radio Power Management in Wireless Sensor Networks, ACM Transactions on Embedded Computing Systems, 9(4), Article 41, March 2010. 29