System Architectures for Unified Power Management in Power - - PDF document

▶
system architectures for unified power management in
SMART_READER_LITE
LIVE PREVIEW

System Architectures for Unified Power Management in Power - - PDF document

Jul 16, 2023 28 likes •100 views

Challenges System Architectures for Unified Power Management in Power management is critical for wireless sensor networks Limited energy source Wireless Sensor Networks Lifetime from months to years Gap between algorithms

slide-1
SLIDE 1

1 System Architectures for Unified Power Management in Wireless Sensor Networks

Chenyang Lu

Department of Computer Science and Engineering

6

Challenges

  • Power management is critical for wireless sensor networks
  • Limited energy source
  • Lifetime from months to years
  • Gap between algorithms and systems
  • Significant advance in power management algorithms & protocols
  • Significant challenges to integrate them in real systems
  • Minimum support for power management in OS
  • Need unified system architectures for flexible power

management!

7

Outline

  • MLA: Media Access Control Layer Architecture
  • Unified radio power management architecture
  • ICEM: Integrated Concurrency and Energy Management
  • Integrated and automatic power management for all I/O devices

8

Outline

  • MLA: Media Access Control Layer Architecture
  • Component architecture for MAC protocols
  • ICEM: TinyOS device driver architecture
  • Integrated power management for all I/O devices

9

Problem

  • Conflicting application requirements
  • Energy
  • Latency
  • Throughput
  • Radio is a major consumer of energy
  • Need different MAC protocols to meet different requirements

Habitat Monitoring Tracking Structural Health Health Care

10

Current Solution

  • Design a new MAC protocol as a monolithic stack
  • S-MAC
  • BMAC
  • ZMAC
  • XMAC
  • WiseMAC
  • T-MAC
  • SCP
  • Funnel-MAC
  • Crankshaft
  • 802.15.4
  • DRAND
  • ……………

Send/Receive Logic Send/Receive Interfaces Backoff Control Interfaces Sleep Scheduling Protocol Clear Channel Assessment Backoff Controller Radio State Machine Sleep Scheduling Interfaces

slide-2
SLIDE 2

2

11

Problem with Current Solution

Send/Receive Logic Send/Receive Interfaces Sleep Scheduling Interfaces Backoff Control Interfaces Sleep Scheduling Protocol Clear Channel Assessment Backoff Controller Radio State Machine

No separation between power management & core radio functionality

12

Problem with Current Solution

Send/Receive Logic Send/Receive Interfaces Backoff Control Interfaces Duty Cycling Protocol Clear Channel Assessment Radio State Machine

All features jumbled into one big monolithic implementation

Backoff Controller Sleep Scheduling Interfaces

13

Problem: Monolithic Radio Stack

  • Hard to develop new MAC protocols
  • No clear separation of concerns
  • Need intimate knowledge of entire stack
  • Hard to maintain multiple MAC stacks as OS evolves
  • Protocols not reusable across radio platforms

14

MLA: MAC Layer Architecture

  • Separation of sleep sleeping from radio core [IPSN‘07]
  • Components for sleep scheduling protocols [SenSys’07]
  • Reusable ease development and maintenance of new protocols
  • Platform independent Reduces porting effort

Radio Core Timers Sleep Scheduling

15

MLA: MAC Layer Architecture

  • Components implement common features of MAC protocols
  • Hardware-independent: portable across platforms
  • Hardware-dependent: portable interfaces, platform specific

implementations

  • Simplifies porting to a new platform
  • Re-implement hardware-dependent components (once per platform)
  • Hardware independent components stay the same
  • Support diverse MAC protocols
  • CSMA (contention-based), TDMA (scheduling-based), Hybrid
  • Comparable efficiency to monolithic implementations

16

B-MAC: An Example Protocol

Preamble Sender: Receiver: Check the Channel Sleep Check the Channel and receive Check the Channel Sleep Data Data

slide-3
SLIDE 3

3

17

B-MAC

Preamble Sender: Receiver: Check the Channel Sleep Check the Channel and receive Check the Channel Sleep Data Data

Receiver performs periodic CCA check

18

B-MAC

Preamble Sender: Receiver: Check the Channel Sleep Check the Channel and receive Check the Channel Sleep Data Data

Sender sends preambles equal to CCA check period Receiver performs periodic CCA check

19

B-MAC

Preamble Sender: Receiver: Check the Channel Sleep Check the Channel and receive Check the Channel Data Data Sleep

Sender sends preambles equal to CCA check period Receiver performs periodic CCA check Receiver receives data if channel busy when performing check

20

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

Check the Channel Sleep Check the Channel and receive Check the Channel Data Sleep

21

Breakdown of B-MAC

  • What does it need?
  • Method of turning the radio on and off
  • Method of checking the channel for radio activity (CCA)

Radio Core

22

Breakdown of 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

Timers Radio Core Channel Poller

slide-4
SLIDE 4

4

23

Breakdown of 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 preambles and data

Timers Radio Core Channel Poller Bmac Sender Preamble Sender

24

Breakdown of 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 preambles and data
  • A way of receiving data and filtering out preambles

Timers Radio Core Channel Poller Bmac Sender Preamble Sender LPL Listener Bmac Preamble Filter

25

Component Library

Asynchronous I/O Adapter

Low Level Dispatcher Time Synchronization Slot Handlers (TDMA/CSMA)

Alarm Channel Poller

Local Time

LPL Listener Radio Core Preamble Sender

Hardware Dependent Hardware Independent

CSMA Protocols

26

Component Library

Asynchronous I/O Adapter

Low Level Dispatcher Time Synchronization Slot Handlers (TDMA/CSMA) Alarm

Channel Poller

Local Time

LPL Listener Radio Core Preamble Sender

Hardware Dependent Hardware Independent

TDMA Protocols

27

Component Library

Asynchronous I/O Adapter Low Level Dispatcher Time Synchronization Slot Handlers (TDMA/CSMA) Alarm Channel Poller Local Time LPL Listener Radio Core Preamble Sender

Hardware Dependent Hardware Independent

Hybrid Protocols

28

Evaluation

  • All evaluations performed on TelosB motes in TinyOS 2.0.1
  • Implemented 5 MAC protocols
  • B-MAC, X-MAC, SCP-Wustl, Pure TDMA, SS-TDMA
  • Measure
  • Reusability of components among protocols
  • Memory footprint compared to monolithic implementations
  • Throughput
  • Latency
  • Energy Consumption
slide-5
SLIDE 5

5

29

Code Reuse

400 800 1200 1600 B-MAC X-MAC SCP- Wustl Pure TDMA SS- TDMA

MAC Protocol Lines of code

Protocol-Specific Reused

30

Reusability of Components

2 2 4 3 3 Other Components 8 7 8 6 6 Reused Components

Radio Core Local Time Alarm Async I/O Adapter Low Level Dispatcher CSMA Slot Handler TDMA Slot Handler Time Synchronization Preamble Sender LPL Listener Channel Poller SS-TDMA Pure-TDMA SCP-Wustl X-MAC B-MAC

31

Memory Footprint (TelosB)

50 0 0 10 0 0 0 150 0 0 20 0 0 0 B-MAC X-MAC Monolithic MLA 250 50 0 750 10 0 0 B-MAC X-MAC Monolithic MLA

ROM Overhead RAM Overhead

32

Throughput

1 10 100 1 2 3 4 5 6 7 8 9 10

Num ber of sending node

X-MAC (MLA) X-MAC (Monolithic B-MAC (MLA) B-MAC (Monolithic

33

MLA: Summary

MLA: Component-based, Low-Power MAC architecture for wireless sensor networks

  • Increases Flexibility
  • Simplifies development
  • Reduces porting effort

Provides evidence contrary to the existing philosophy that radio stacks must be monolithic to be efficient

34

Outline

  • MLA: Media Access Control Layer Architecture
  • Unified radio power management architecture
  • ICEM: Integrated Concurrency and Energy Management
  • Integrated power management for all I/O devices
  • Decentralized Architecture for Structural Health Monitoring
  • Wireless Clinical Monitoring
slide-6
SLIDE 6

6

35

ICEM: Integrated Concurrency and Energy Management

First generation sensornet OSes (TinyOS, Contiki, Mantis, ...)

Push all energy management to the application Optimal energy savings at cost of application complexity

ICEM: Unified device driver architecture [SOSP’07]

Integrating transparent energy management with concurrency

control for asynchronous I/O

Implemented in TinyOS 2.0 -- all drivers follow it Provides a component library for building drivers

36

Power Lock

Power Control HW-Specific Configuration Arbiter Arbiter Configure Default Owner Configurator Power Manager Lock

Lock interface for concurrency control of asynchrous I/O ArbiterConfigure interface for automatic hardware configuration DefaultOwner interface for automatic power management

  • 37

Shared Driver Example

Msp430 USART (Serial Controller)

Three modes of operation – SPI, I2C, UART Uart Configurator Arbiter Immediate Power Manager SPI User Msp430 USART SPI Configurator Uart User I2C User I2C Configurator Power Control Functional Configuration Lock Uart Configurator Arbiter Immediate Power Manager SPI User Msp430 USART SPI Configurator Uart User I2C User I2C Configurator Power Control Functional Configuration Lock

38

Expected Node Lifetimes

39

ICEM: Summary

Device driver architecture for low power devices At least 98.4% as energy efficient as hand-tuned implementation of representative application Simplifies application and driver development Questions the assumption that applications must be responsible for all energy management

40

Conclusion

  • Power management is critical for wireless sensor networks
  • Unified system architectures for flexible power management
  • MLA: component-based architecture for MAC protocols
  • ICEM: Integrated power management for all I/O devices.
  • Bridge the gap between algorithms/protocols and systems.
  • Available in TinyOS 2.x.
slide-7
SLIDE 7

7

41

Code

  • SourceForge TinyOS CVS repository:
  • http://sourceforge.net/cvs/?group_id=28656
  • ICEM: Library components and interfaces
  • tinyos-2.x/tos/interfaces
  • tinyos-2.x/tos/lib/power
  • tinyos-2.x/tos/system
  • Example Drivers
  • Atmega128 ADC: tos/chips/atm128/adc
  • MTS300 Photo: tos/sensorboards/mts300
  • MSP430 USART0: tos/chips/msp430/usart
  • Storage: tos/chips/stm25p
  • CC2420: tos/chips/cc2420
  • MLA: tinyos-2.x-contrib/wustl/upma

42

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 Support for Unified Radio

Power Management in Wireless Sensor Networks, IPSN'07.

  • K. Klues, V. Handziski, C. Lu, A. Wolisz, D. Culler, D. Gay and P.

Levis, Integrating Concurrency Control and Energy Management in Device Drivers, SOSP'07.