Network Power Scheduling for wireless sensor networks

Network Power Scheduling for wireless sensor networks

Barbara Hohlt

Intel Communications Technology LabHillsboro, OR

August 9, 2005

Outline

Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation

Wireless Sensor Networks

Networks of small, low-cost, low-power devices

Sensing/actuation, processing, wireless communication

Dispersed near phenomena of interest Self-organize, wireless multi-hop networks Unattended for long periods of time

Berkeley Motes

Mica Mica2Dot Mica2

Example Applications

Indoor Building Monitoring

Environmental Monitoring

Inventory TrackingSecurity

15

13

14

6

5`

15

118

Mote Layout 1

29

Home AutomationPursuer-Evader

Power Consumption

Power consumption limits the utility of sensor networks Must survive on own energy stores for months

or years 2 AA batteries or 1 Lithium coin cell

Replacing batteries is a laborious task and not possible in some environments

Conserving energy is critical for prolonging the lifetime of these networks

Where the power goes

Main energy draws Central processing unit Sensors/actuators Radio

Radio dominates the cost of power consumption

Radio Power Consumption

Primary cost is idle listening Time spent listening waiting to receive packets Nodes sleep most of the time to conserve

energy Secondary cost is overhearing

Nodes overhear their neighbors communication Broadcast medium Dense networks

Must turn radio off need a schedule

Flexible Power Scheduling Flexible Power Scheduling

Reduces radio power consumption Supports fluctuating demand (multiple queries, aggregates) Adaptive and decentralized schedules

Improves power savings over approaches used in existing deployments 4.3X over TinyDB duty cycling 2–4.6X over GDI low-power listening

High end-to-end packet reception Reduces contention Increases end-to-end fairness and yield

Optimized per hop latency

Network Power Schedule

CSMA MAC

FPS Two-Level Architecture

Coarse-grain scheduling At the network layer Planned radio on-off times

Fine-grain CSMA MAC underneath Reduces contention and increases end-to-end fairness

Distributes traffic Decouples events from correlated traffic Reserve bandwidth from source to sink

Does not require perfect schedules or precise time synchronization

Outline


Scheduling Approaches

Low-power Listening (preamble sampling)

PHY

S-MAC Scheduled Listen/Sleep

MAC

Flexible Power Scheduling

Network

TinyDB

Duty Cycling

Application

Approach Protocol Layer

Low-power Listening

Radio periodically samples channel for incoming packets

Radio remains in low-power mode during idle listening

Fixed channel sample period per deployment Supports general communication

PHY Layer

idle listening (low-power mode)

S-MAC Scheduled Listening

Virtual Clustering, all nodes maintain and synchronize on schedules of their neighborhoods

Data transmitted during “sleep” period, otherwise radios turned off Fixed duty-cycle per deployment Supports general communication

listen period

MAC Layer

SYN RTS CTS

“sleep” period

sleep or send data

frame

TinyDB Duty Cycling

All nodes sleep and wake at same time every epoch

All transmissions during waking period Fixed duty-cycle per deployment Supports a tree topology

Application Layer

waking period

epoch


Each node has own local schedule During idle time slots the radio is turned off Schedules adapt continuously over time Duty-cycles are adaptive Supports tree topology

cycles

Network Layer

Outline


Assumptions

Sense-to-gateway applications Multihop network Majority of traffic is periodic Nodes are sleeping most of the time Available bandwidth >> traffic demand Routing component

The power schedule

Time is divided into cycles

Each cycle is divided into slots

Each node maintains a local power schedule of what operations it performs over a cycle

T RI TI I

cycleslot

time

T – TransmitR – ReceiveI - Idle

Scheduling flows

Schedule entire flows (not packets) Make reservations based on traffic demand Bandwidth is reserved from source to sink

(and partial flows from source to destination) Reservations remain in effect indefinitely

and can adapt over time

Adaptive Scheduling

Demand represents how many messages a node seeks to forward each cycle

Supply is reserved bandwidth The network keeps some preallocated

bandwidth in reserve Changes in reservations percolate up the

network tree

T RI TI I supply demand

local stateLocal data structure

1 0 1

2 1 1

3 1 2

Supply and Demand

1. If supply < demand 1. Request reservation

2. If Conf -> Increment supply

2. If supply >= demand1. Offer reservation

2. If Req ->Increment demand

supply demandcycle

For the purposes of this example, we will say one unit of demand counts as one message per cycle.

0 1

1 1

1 2

Using only local information, the next Receive slot is always within w of the next Transmit slot putting an upper bound on the per hop latency of the network.

Reduced Latency

supply demandcycle

T

R T

1

2

3

0 1 2 3 4 5slot

window size = w

Sliding Reservation Window

Receiver Initiated Scheduling

Periodically nodes advertise available bandwidth

A node joining the network listens for advertisements and sends a request

Thereafter it can increase/decrease its demand during scheduled time slots

Receiver

Joiner

REQ

CONF

ADV

Broadcast Rx

Tx Rx

Tx

Joining Protocol

Listen

Receiver Initiated Scheduling

Periodically advertise available bandwidth

Nodes increase/decrease their demand during scheduled time slots

No idle listening

Receiver

Sender

REQ

CONF

ADV

Broadcast Rx

Tx Rx

Tx

Reservation Protocol

Properties of supply/demand

All network changes cast as demand Joining Failure Lossy link Multiple queries Mobility

3 classes of node Router and application Router only Application only

Load balancing

Outline


Implementation

HW Mica Mica2Dot Mica2

SW Slackers TinyDB/FPS (Twinkle) GDI/FPS (Twinkle)

Architecture

Radio power scheduling Manages send queues Provides buffer management

MAC/PHY

Active Messages

Application

Multihop Routing

Ran

do

mM

LC

G


Tim

eSyn

c

Sen

dQ

ueu

es

Bu

ffer

Man

agem

ent

Po

wer

Man

agem

ent

Outline


Micro Benchmarks Mica

Power Consumption Fairness and Yield Contention

Power consumption

4 TinyOS Mica motes 3-hop network Node 3 sends one 36-byte packet per cycle Measure the current at node 2

0123source gateway

Time in seconds

Cur

rent

in

mA

1.4

Slackers. Early experiment on Mica.5X savings

Avg

Mica Experiments

10 MICA motes plus base station

6 motes send 100 messages across 3 hops

One message per cycle (3200ms)

Begin with injected start message

Repeat 11 times

1 2 3 4 5 6

Two Topologies Single Area

one 8’ x 3’4” area Multiple Area

five areas, motes are 9’-22’ apart

Scheduled (FPS) vs Unscheduled (Naïve)

End-to-end Fairness and Yield

0

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6

Mote ID

Percent

FPS

Naive

AVG STDDEV Max/Min

FPS 96.4 1.13 1.03

Naïve 24.7 6.19 2.48

Contention is Reduced

CDF of Single Area Tests

30.00%

40.00%

50.00%

60.00%

70.00%

80.00%

90.00%

100.00%

0 5 10 15 20 25 30 35

Number of Backoffs

CDF

Naive

FPS

Outline


Application Evaluation

TinyDB/fps vs TinyDB/duty cycling 4.3X power savings Multiple queries Partial flows

Query dissemination Aggregation

GDI/fps vs GDI/lpl 2-4.6X power savings Up to 23 % increase in yield

Evaluation with TinyDB

Two implementations TinyDB Duty Cycling TinyDB FPS

Current Consumption Analysis Berkeley Botanical Gardens Model

Acknowledgment: Sam Madden

TinyDB Redwood Deployment

17

18

BTS

1 2

3

0

• 2 trees• 35 nodes

• 1/3 two hops• 2/3 one hop

3 Step Methodology

Estimate radio-on time for TinyDB/DC and TinyDB/FPS No power management 3600 sec/hour

For FPS, validate the estimate at one mote with an experiment

Use Mica current measurements to estimate current consumption

TinyDB Duty Cycling

4 seconds

2.5 minutes

All nodes wake up together for 4 seconds every 2.5 minutes. During the waking period nodes exchange messages and take sensor readings.

Outside the waking period the processor, radio, and sensors are powered down.

24 samples/hour * 4 sec/sample = 96 sec/hour


0.767 sec/cyc (per node) = 18 slots * 128 ms = 2.3 sec/cycle per 3 nodes

24 samples/hour * 0.767 sec/cycle = 18.4 sec/hour

Node 1: 2 T, 3 ANode 2: 3 T, 2 R, 3 ANode 3: 2 T, 3 A

18 slots = 5 (node 1) + 8 (node 2) + 5 (node 3)

0

2

3

1

Traffic

Communication Broadcast

FPS Validation

Metric Slots Idle PercentPredicted Idle Slots 56/64 89.1%Measured Idle Slots 56/64 89.1%Measured Radio Idle Time 56/64 91%

Current Consumption

Current Consumption mA-seconds per hour =(On time) * (On draw) + (Off time) * (Off Draw)

803 mA-s/hr = 96 s/hr (8mA) + 3504 s/hr (.01mA) Mica1

183 mA-s/hr = 18.4 s/hr (8mA) + 3582 s/hr (.01mA) Mica1

4.39 XTinyDB/ Duty Cycling

TinyDB/FPS

Evaluation with GDI

Two implementations GDI Low-Power Listening GDI FPS

Experiments Yield Power Measurements

Power Consumption Acknowledgement: Rob Szewczyk

GDI Low-Power Listening

MAC Layer

Each node wakes up periodically to sample the channel for traffic and goes right back to sleep if

there is nothing to be received.

12 Experiments Mica2Dot

30 mica2dot inlab testbed 3 sets

GDI/lpl100 GDI/lpl485 GDI/Twinkle

4 sample rates 30 seconds 1 minute 5 minute 20 minute

Yield and Fairness

Power Scheme

Sample Period

Yield

%

Max/Min

ratio

Twinkle 0.5 0.80 2.11

Twinkle 1 0.90 1.74

Twinkle 5 0.84 1.92

Twinkle 20 0.83 2.4

Lpl-485 0.5 0.40 15.6

Lpl-485 1 0.68 94.0

Lpl-485 5 0.72 11.8

Lpl-485 20 0.69 12.0

Lpl-100 0.5 0.85 3.45

Lpl-100 1 0.83 2.23

Lpl-100 5 0.78 2.76

Lpl-100 20 0.77 4.00

Sample Period: 20 minuteSample Period: 5 minutes

Measured Power Consumption

0

1

2

3

4

5

6

Inner Leaf

Power (mW)

Twinkle Lpl-485 Lpl-100

0

1

2

3

4

5

6

Inner Leaf

Power (mW)

Twinkle Lpl-485 Lpl-100

Power Scheme

Sample

Period

Yield %

Inner (mW)

Leaf (mw)

#

GDI-485 (singlehop)

5 0.70* n/a 0.71** 21

GDI-485 (multihop)

20 0.70* 1.60** n/a 36

Lpl-485 5 0.72 4.09 3.99 30

Lpl-485 20 0.69 1.77 1.74 30

Twinkle 5 0.84 0.52 0.36 30

Twinkle 20 0.83 0.38 0.34 30

Comparison of Lab and GDI Deployment

* Yield from first day of GDI deployment

** Estimate

Summary

Flexible Power Scheduling Two-level architecture Schedules flows (not packets) Adaptive and decentralized schedules

High Yield Reduced contention Increased end-to-end fairness and throughput

Reduced end-to-end latency Supports multiple queries (fluctuating demand) Improved power savings

4.3X over TinyDB duty cycling 2-4.6X over GDI low-power listening

Thank You

Barbara [email protected]

Network Power Scheduling for wireless sensor networks

Documents

Transcript of Network Power Scheduling for wireless sensor networks