A StreamOriented Power Management Protocol for Low Duty Cycle Sensor Network Applications

1
A Stream-Oriented Power Management Protocol for
Low Duty Cycle Sensor Network Applications

• Nithya Ramanathan
• Mark Yarvis
• Lakshman Krishnamurthy
• Deborah Estrin

2
Problem Definition

• Design a protocol that would
• Enabling dynamic querying of a network that was
  mostly asleep and is
• Low duty-cycle Sample period on the order of
  minutes
• Stream oriented Applications with multi-fragment
  transmissions between two nodes
• Latency tolerant functionality does not require
  low response latency (e.g. several minutes)
• E.g. FabApp

3
Contributions

• Intuition that sleep/wake control does not only
  belong in the MAC for a certain class of
  applications
• A more energy efficient protocol can leverage
  data characteristics
• Information on scheduled data transmissions
• Latency restrictions on delivery of un/scheduled
  transmissions
• Proposed an adaptive addition that handles time
  varying latency requirements

4
MAC power management protocols

• Challenge ensure nodes are awake to hear
  neighboring transmissions
• Packet-based protocols
• Ensure reception of every asynchronous packet gt
  idle listening
• Often Neighbors overhear multi-fragment
  transmissions
• SMAC
• Synchronized sleep/wake protocol using frequent
  SYNC transmission
• Nodes sleep on the order of seconds
• BMAC
• Nodes send long preamble to ensure neighbors are
  awake
• e.g. for 100ms sleep, and 19.2kbps radio,
  preamble240B
• Sleep periods on the order of milliseconds
• E.g. sleep 100 ms, radio will switch 600 times
  in 1 minutes

5
Informal Application Taxonomy
Event Detection
Hazard Detection
N/A
B-MAC
Frequent Monitoring
Habitat Monitoring
Seconds gt Minutes
S-MAC
Infrequent Monitoring
Minutes gt Day
FabApp
?
6
AppSleep

• Cluster-based protocol synchronized cluster
  sleep / wake cycles
• Prioritizes energy efficiency above latency
• Enables scheduling across packets to minimize
  neighbor overhearing
• Leverages minimal application characteristics to
  enable extended sleep periods
• Enables idle mode for processor, minimized radio
  switching, and idle listening
• Cons of Extended Sleep Periods
• Requires synchronized wake-up so that neighbors
  hear each other
• Dropped packets have higher impact
• Multi-hop during a single wake period is crucial
  to avoid high latencies

7
3 State Protocol
Cluster Awake Ctrl packets tx/rx across network
Wakeup timer fires
Node initiates bulk transfer
Sleep timer fires
Node terminates bulk transfer
Cluster Sleep Proc idle/sleeps
Bulk Data Transfer
Note Sleep period determined by latency needs of
application
8
AppSleep

• Cluster Cluster-head and nodes
• Nodes start out awake
• Every SYNCH period, cluster head floods SYNCH
  packet, which specifies
• Trel-sleep Time cluster waits before going to
  sleep (synchronization mechanism)
• Tsleep Time cluster sleeps
• Between SYNCH periods, cluster continues sleep
  for Tsleep and wake for Tawake
• When a new node joins the network, it remains
  awake until it hears a SYNCH packet

CH
9
Bulk Data Transfer

• Tawake is calculated to keep the cluster awake
  long enough to communicate 1 packet the network
  diameter
• For bulk data transfer, control packet commands
  nodes on route to remain awake
• Nodes on active route remain awake until bulk
  data transfer completes

CH
10
SYNCH Packets

• Used to synchronize cluster sleep/wake
• Trades-off accuracy for minimal overhead
• Lower overhead than other protocols (RBS1, DTMS2,
  LTS3)
• Pair-wise time synchronization not needed
  reduces overhead gt O(1).
• Tight synchronization not required due to
  extensive sleep periods
• Protocol addresses SYNCH packet loss
• 1 J. Elson, L. Girod, D. Estrin, Fine-Grained
  Network Time Synchronizatino using Reference
  Broadcasts. OSDI, 2002.
• 2 S. Ping, Delay Measurement Time
  Synchronization for WSN. Intel-Research,
  Berkeley.
• 3 J. Greunen, J. Rabaey, Lightweight Time
  Synchronization for Sensor Networks

11
Impacts on Cluster Synchronization

• SYNCH transmission/node-processing delay
• Nodes compensate by adjusting their Trel-sleep
  ,the time in which they go to sleep
• Trel-sleep Tpkt-rel-sleep (Tpkt_dly)
• Clock drift (theoretical for mica2 is 20 ppm or
  72 msec/hour)
• Initial node delays packet transmission by a
  guard-band to ensure neighbors are awake
  Tguard_band
• The wake period (Tawake ) is calculated to ensure
  that nodes farthest from the cluster-head will
  hear transmissions

12
What if a SYNCH packet is dropped?

• Each SYNCH packet informs the cluster when to
  expect the next SYNCH packet
• If a node does not get a SYNCH packet when
  expected, it broadcasts a SYNCH-REQ message to
  request an updated sleep time

13
Parameters

• Network diameter to calculate Tawake
• Potentially obtain from routing layer
• Data characteristics to specify Tsleep
• Obtain from Application

14
Optimal SYNCH Period
Decreased SYNCH packet overhead is offset by
increased time nodes stay awake during each
wake-up
Optimal SYNCH period increases with the sleep
period
15
Varying Latency Usage Model
Low latency response required immediately after
scheduled data to verify emergency event detection
As time progresses, minimum required response
latency varies inversely with probability and
importance of request
16
Adaptive AppSleep State Diagram

• Within each state, AppSleep protocol is running
• SYNCH packets from the cluster head moves the
  network between states by changing Tsleep

Scheduled Data Return
SYNCH
Tsleep x
Query Ready 1 Asynchronous Data
Query Ready n Asynchronous Data
SYNCH
SYNCH
...
Tsleep 2 x
Tsleep 2n x
17
Evaluation

• Theoretical Results using energy model
• Based on measurements and model presented by
  Polastre et. al Sensys04
• Radio (20mA Tx / 16mA Rx / Idle), Processor
  (5.5mA active / 1.6mA idle)
• Actual Measurements
• All are 7-hop networks

18
Average Latency

• B-MAC provides the best response latency because
  it enables the shortest sleep periods

SMAC operating range
AppSleep operating range
BMAC operating range
19
Energy to Maintain Network (No traffic)
BMAC has the lowest overhead when no traffic is
sent
20
Total Lifetime

• SMAC outperforms AppSleep for equivalent sleep
  periods because AppSleep communicates across the
  network during a wake period to enable long sleep
  periods.

AppSleep avg asynchronous atency 375 sec
3x difference bet BMAC/SMAC AppSleep for
22min sampling period
AppSleep avg Asynchronous latency 46 sec
21
Impact of Neighborhood Size for 22-minute sampling

• Demonstrates 2nd key result despite increased
  transmission overhead, SMAC exceeds BMAC for
  dense neighborhoods due to BMACs preamble
  over-hearing
• SMAC AppSleep not impacted by neighbor density

AppSleep performs 9x better than BMAC for 20
neighbors
AppSleep avg latency 46 sec
22
AppSleep Lifetime as Impacted by Network
Diameter Scalability
Loses 5 of life-time as for each increase of
5 hops in network diameter
23
Actual Average Energy Consumption

• Measured
• Time radio on
• Time tx/rx
• Number of times radio switches
• Test
• 2 Runs of 22 hours each
• Sample 1/10 minutes
• SYNCH packet 1 / (2 hours) for AppSleep

BMAC estimate lt actual measurements
AppSleeps model closely matches measurement
24
Compare Adaptive and Basic AppSleep

• Much less energy consumed by adaptive protocol
• Enables varying latency restrictions while
  maximizing energy savings

25
Future Work

• Deploy AppSleep
• Run AppSleep on top of an energy efficient MAC
  and quantify advantages
• Especially when nodes miss SYNCH packets and
  fail on

26
Conclusion

• Significant energy savings possible by moving
  sleep control up the stack
• Extended sleep periods realized with minimal
  overhead
• Adaptive AppSleep maximizes energy savings while
  handling time varying response latency
  requirements

27
Back up Slides
28
Tguard_band (2 Cdrift ms/hour)
(Tlast_SYNCH hours 1)
For example If it has been lt 4 hours since the
SYNCH packet, nodes could wakeup anytime from
Cdrift (Tlast_SYNCH 1) msec before/after they
should
Node ys clock
Node xs clock
Cdrift
0
After Tguard_band all nodes along the path are
guaranteed to be awake
Tguard_band
0
Node x wakes up
Node y wakes up
29
Time Nodes Stay AwakeTawake Thop_dly 2
Tguard_band
Worst-case Node n (n-hops away from Node 1) must
stay awake for Tawake to ensure that it receives
Node 1s transmission
0
Tguard_band
Tguard_band
Thop_dly Nhops HopDly (50ms)
Node 1 starts sending
Node n wakes up
Node 1 wakes up
Node n receives
30
Packet delayTPkt_Delay TSend-delay
TReceive_Delay
Packet Transmission
Send Delay
Receive Delay
P r e a m b l e
D a t a
Preamble
Data
Sender application stamps packet
Receiver MAC stamps same byte in packet
Receiver application receives packet,
forwards the packet and sets its sleep timers
Sender MAC stamps packet
Send-delay Includes channel access, and
processing
Transmission Delay Included in Send and Receive
Delay
Propagation Delay Assume it is 0
Receive-delay Time elapsed while processing a
received packet 1 1 Ping, Su Delay Measurement
Time Synchronization for Wireless Sensor
Networks. IRB-TR-03-013. June, 2003.
31
Energy Model Assumptions

• General
• Nodes have 7 neighbors
• Routing traffic overhead included commensurate
  with sample traffic (2 packets)
• Radio only has three modes Erx, Etx, OFF
• SMAC
• Node sends SYNCH packet every 1 / (SYNC_PERIOD
  NUM_NEIGHBORS) seconds
• Does not include adaptive listening
• BMAC
• Uses application control
• Based on code (tinyos-1.x/contrib/ucb/tos/CC1000Pu
  lse) as of 9/20/2004
• Used energy model in Sensys Paper
• AppSleep
• Minimum Power Network sleeps for 12 minutes
• Time Synchronization 1 / 2 Hours

32
Choosing an energy efficient approach

• Minimize latency of synchronous sampling
• AppSleep (frequency gt 1 minute) Monitoring
• SMAC (frequency gt 1 second lt 1 minute)
  Monitoring
• Minimize latency of asynchronous events
• BMAC (latency milliseconds) Casual/Emergency
  Event Detection
• SMAC (latency seconds) Casual Event Detection
• Minimize energy consumption for
• Infrequent Monitoring AppSleep
• Frequent Monitoring SMAC

33
Unsolved Questions

• What are risks/impacts if two nodes want to
  transmit control packets during the same wake
  period and collide?
• Bootstrapping how do we ensure the first SYNCH
  packet reaches nodes
• How do nodes decide which cluster to associate
  with

34
Current Limitations to AppSleep

• Maximum network diameter needed to calculate
  Tawake if new nodes exceed this network
  diameter then packets crossing the diameter will
  take two wake periods
• For Inter-cluster communication, cluster heads
  must have 802.11. However there is no theoretical
  limitation on cluster size.
• Cluster Head is single point of failure
• Nodes fail on when they do not hear SYNCH packet,
  so if cluster head fails, cluster will fail on
  until cluster head is rebooted.

35
Actual Average Time Radio is Awake

• BMAC is awake 4x longer than AppSleep

36
Time Synchronization timeline

• Nodes send up to 4 SYNCH-REQ messages,
  exponentially decay timeout
• If they still do not hear a SYNCH packet remain
  on

Twait Tawake Tbuffer
Ttimeout 200msec
Ttimeout 400msec

Node wakes up
Neighboring nodes hear SYNCH-REQ send updated
SYNCH messages
Node broadcasts SYNCH-REQ message
37
Time Synchronization Time Tts

• Cluster Head floods SYNCH packets
• Nodes update the SYNCH packet and forward the
  first one
• Some nodes do not hear them

CH
X
X
38
Time Tts 200msec

• Nodes that did not receive a SYNCH packet send
  SYNCH-REQ packets after Twait secs

CH
X
X
X
39
Forwarding SYNCH-REQ responses

• Nodes that receive updated SYNCH packets will
  forward those on

CH
40
Time Tts 200msec 400msec

• Nodes that again did not receive SYNCH packets
  will send up to 3 more SYNCH-REQ messages - after
  decaying wait periods

CH
X
41
Robustness

• When new nodes are added, they remain on until
  they hear a SYNCH packet or if they hear other
  traffic, they can send a SYNCH-REQ

42
AppSleep Usage

• Control Packets should be reliably unicast
• Incorporate a cluster head selection algorithm
• Routing considerations

43
Future features

• Buffering packets that cannot be sent because
  neighboring nodes are asleep (only a problem if
  wake period is not long enough due to network
  diameter exceeding expectations)

44
Total Lifetime Including Processing
gt 3x lifetime increase for all sampling periods
AppSleep avg latency .75 sec
45
Average Latency

• B-MAC is the best
• B-MAC/S-MAC latency scales with number of hops,
  AppSleep is constant
• AppSleep Tsleep/2 Tlisten
• S-MAC
• (Tsleepk/2 Twake)
• (Nhops 1) (Tsleep Twake)
• B-MAC
• (1.5 Tsleep Twake)
• (Nhops 1) (Tsleep Twake)

46
Energy to Maintain Network Including Processing
AppSleep performs 3x better with processor in
idle mode
AppSleep avg latency 1.5 sec
47
AppSleep Parameters
48
Performance Characterization
Assume number of hops 5 Time Average latency
to return an asynchronous event
1 day
44 min
22 min
11 min

• AppSleep
• 375 secs
• 2. BMAC
• .55 secs
• SMAC
• 54 secs

• AppSleep
• 46 secs
• 2. BMAC
• .55 secs
• SMAC
• 54 secs

• AppSleep
• 23 secs
• 2. SMAC
• 54 secs
• 2. BMAC
• .55 secs

• AppSleep
• 46 secs
• 2. SMAC
• 54 secs
• BMAC
• .28 secs

49
Performance Characterization
5.6 min
2.8 min
1.4 min

• AppSleep
• 46 seconds
• 2. BMAC
• .11
• SMAC
• 54 secs

• AppSleep
• 46 secs
• 1. SMAC
• 54 secs
• BMAC
• .11

• SMAC
• 54 secs
• 2. AppSleep
• 46 secs
• BMAC
• .11 secs

50
Min Tsleep to switch to deep sleep

• Minimum time to amortize switching to deep sleep
• Compare energy to keep processor active during
  sleep to energy consumed by switching and sleeping

51
Parameter Computation

• Time Awake

52
Difference between BMAC paper

• Assumed node had 7 neighbors
• Assumed node had to forward traffic from 3
  children
• Assumed periodic routing traffic overhead
  correlated with sampling rate

53
Worst Case Clock Drift Scenarios
Time 0
C
C
Dinit
N-hop Delay
NN receives Pkt
NN wakes up
N0 wakes up
N0 sends Pkt
N0
Sender
Receiver located across the network
NN
C
C
N-hop Delay
C
Theoretical clk drift
Dinit
Initial packet delay
NN wakes up
N0 wakes up
N0 sends Pkt
NN receives Pkt
54
Routing

• Due to long periods of sleeping and minimal
  control packet overhead, routes could potentially
  stale. Options are to
• Maintain routes by waking up more frequently and
  sending packets, better for high-traffic/low
  latency networks
• Reactive routing, flood a stay awake packet and
  re-calculate routing tables, better for
  low-traffic/high latency networks

55
Time 0
C
C
2 C
N-hop Delay
NN wakes up
N0 wakes up
N0 sends Pkt
NN receives Pkt