Post on 01-Jan-2016
description
transcript
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
Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation
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
Flexible Power Scheduling
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
Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation
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
Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation
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
Flexible Power Scheduling
Tim
eSyn
c
Sen
dQ
ueu
es
Bu
ffer
Man
agem
ent
Po
wer
Man
agem
ent
Outline
Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation
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
Introduction Radio Scheduling FPS Overview Implementation Micro Benchmarks Application Evaluation
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
Flexible Power Scheduling
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 Hohlthohltb@cs.berkeley.edu
END