AppSleep

1
AppSleep

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

2
Outline

• Contributions / Background
• AppSleep / Time Synchronization
• Evaluation
• Adaptive AppSleep / Evaluation
• Summary of Results

3
Contributions

• AppSleep An transport protocol for low
  duty-cycle networks with significant energy
  savings over BMAC/SMAC
• Bulk data transfer energy efficient by only
  keeping active route awake
• Low overhead time synchronization that is robust
  to packet loss
• Adaptive AppSleep An adaptive addition that
  maximizes energy savings while handling time
  varying latency requirements
• Intuition that sleep/wake control does not only
  belong in the MAC for a certain class of
  applications

4
Definition of Terms

• Synchronous Data Pre-scheduled sample delivery
• Frequency 1 / (sampling period)
• Asynchronous Unscheduled data, i.e. detected
  events/ queries
• Latencies
• Synchronous Data Time to return pre-scheduled
  data once it has been obtained
• Asynchronous Data Time to return an event once
  it has been detected, or receive a query

5
Informal Application Taxonomy
6
Sources of Energy Dissipation

• Radio (20mA Tx / 16mA Rx / Idle)
• Idle Listening
• Overhearing
• Control Packet overhead
• Collisions (not addressed by AppSleep)
• Processor (5.5mA active / 1.6mA idle/ lt1uA sleep)

7
SMAC

• Goals
• Energy efficiency, self-organization
• Geared towards
• Medium latency (seconds), frequent,
  non-deterministic traffic
• Link statistics kept up to date
• i.e. Frequent monitoring
• Not suitable for low-traffic, extremely low
  latency apps
• Energy Conservation
• Overhearing Overhearing avoidance, relatively
  short preambles
• Packet Overhead High packet overhead for
  scheduling/SYNC
• Idle Listening Frequent when there is a very
  light traffic load
• Multi-hop not always achieved during one
  wake-period

8
BMAC

• Goals
• Simple operation, Scalability, and Tolerance to
  changing network conds
• Geared towards
• Low latency (msec), non-deterministic traffic
• i.e. Casual/Emergency event detection, target
  tracking
• Not suitable for deterministic / high-traffic
  apps
• Energy Conservation
• Overhearing significant unicast preambles
• Packet Overhead Preamble Length dependent on
  sleep time
• Idle Listening Frequent with minimal traffic
• Collisions Hidden terminal is an issue without
  RTS/CTS addition of BMAC
• While its flexible, optimal parameter setting
  still depends on network characteristics (E.g.
  Network density gt Check period)

9
BMAC Overhead

• Long preambles impact receive and transmit
  energies for BMAC

AppSleep SMAC linear regardless of sleep
duration
10
Energy Efficient Approaches

• Different energy efficient approaches apply to
  different classes of applications
• Nothing directly applies to Infrequent
  Monitoring where applications are willing to do
  nothing for extended periods of time

11
Outline

• Contributions / Background
• AppSleep Protocol / Time Synchronization
• Evaluation
• Adaptive AppSleep / Evaluation
• Summary of Results

12
Application Driven Sleep

• Pros
• Extended sleep periods enables idle mode for
  processor and minimized radio/processor switching
• Minimal application specific knowledge
• Cons of Extended Sleep Periods
• Requires synchronized wake-up so that neighbors
  hear each other
• Dropped packets have higher impact
• Multi-hop during single wakeup is crucial

13
AppSleep

• Cluster wakes/sleeps at the same time
• Cluster head sends periodic SYNCH packet with a
  relative sleep time (Tpkt-sleep) to synchronize
  network
• Control Packet Transfer node waits until cluster
  wakes up
• Bulk Data Transfer node first unicasts a control
  packet along the route it will use
• Extensive wake-up intervals, so receiver on time
  is long

14
Cluster Head broadcasts SYNCH

• Nodes start out awake.
• When a new node joins the network, it remains
  awake until it hears a SYNCH packet

CH
15
Trelative-sleep seconds later

• Nodes goto sleep Trelative-sleep seconds later,
  specified in the SYNCH packet

CH
16
Synchronous wakeup
Sleep
Awake

• Nodes all wakeup together after Tsleep seconds,
  specified in SYNCH packet
• Nodes stay awake long enough to communicate
  across the network diameter

CH
17
Nodes stay awake for Tawake

• Node can transmit a control packet during
  wake-period across network diameter
• For bulk data transfer, control packet commands
  nodes on route to remain awake

CH
18
Remaining nodes go to sleep

• Nodes on active route remain awake until bulk
  data transfer completes

CH
19
Network goes back to sleep

• And then go to sleep again

CH
20
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
21
Global sleep-wake

• Entire cluster sleeps/wakes on the same schedule

Sleep
Awake
Cluster Awake
Bulk Data Transfer
Cluster Sleeps
22
Time Synchronization

• Trades-off accuracy for minimal overhead
• Tight / pair-wise synchronization not needed
  reduces overhead by ½ gt O(1).
• Lower overhead than other protocols (RBS1, DTMS2,
  LTS3)
• 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

23
Impacts on Time Synchronization

• Packet Delay / Loss
• Clock drift
• Theoretical clock drift for mica2 is 20 ppm
• Cdrift /- 72 msec/hour
• Dependent on time elapsed since the last SYNCH
  packet (Tlast_ts)

24
Accounting for packet delaysTPkt_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, and adjusts
relative sleep time
Receiver MAC stamps same byte in packet
Receiver application receives packet, sets
its sleep timers, and forwards the packet
Sender MAC stamps packet
Send-delay Includes channel access, and
processing Transmission Delay Included in Send
and Receive Delay Propogation 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.
25
AppSleeps Time Synchronization

• Compensating for Packet Delay
• Receiving nodes calculate their relative sleep
  time (Tsleep)
• TPkt_Delay TSend-delay TReceive_Delay
• Ttime-sleep Tpkt-sleep - TPkt_Delay (1)
• Compensating for Clock Drift
• Initial node delays packet transmission by
  Tinit_dly
• Tclk_drift (2 Cdrift ) (Tlast_ts 1)
• Tinit_dly Tclk_drift (2)
• Nodes should stay awake for Tawake (recaluclated
  1 / hour)
• Thop_dly (Nhops 50ms)
• Tawake Tinit_dly Tclk_drift Thop_dly
  (3)

26
Initial GuardbandTinit_dly (2 Tclk_drift )
(Tlast_ts 1)
If it has been lt 1 hour since the SYNCH packet,
nodes could wakeup anytime from 72 msec before
to 72 msec after they are supposed to
72 msec
- 72 msec
0
After Tinit_dly all nodes along the path are
guaranteed to be awake
Tinit_dly 144msec
Node 2 receives preamble
Node 1 starts sending
Node 1 wakes up
Node 2 wakes up
27
AppSleeps Time Synchronization

• Compensating for Packet Delay
• Receiving nodes calculate their relative sleep
  time (Tsleep)
• TPkt_Delay TSend-delay TReceive_Delay
• Tsleep Tpkt-sleep - TPkt_Delay (1)
• Compensating for Clock Drift
• Initial node delays packet transmission by
  Tinit_dly
• Tclk_drift (2 Cdrift ) (Tlast_ts 1)
• Tinit_dly Tclk_drift (2)
• Nodes should stay awake for Tawake (recaluclated
  1 / hour)
• Thop_dly (Nhops 50ms)
• Tawake Tinit_dly Tclk_drift Thop_dly
  (3)

28
Time Nodes Stay AwakeTawake Thop_dly
Tclk_drift Tinit_dly
Assuming SYNCH packet has been sent in the last
hour, and the network diameter is n hops
Tclk_drift Tinit_dly (2 72ms) (0 1)
144ms Tawake 144 144 n 50ms A
worst-case scenario
0
Tclk_drift 144ms
Thop_dly Nhops 50ms
Tinit_dly 144msec
Node 1 starts sending
Node n wakes up
Node 1 wakes up
Node n receives
29
AppSleeps Time Synchronization

• Compensating for Packet Delay
• Receiving nodes calculate their relative sleep
  time (Tsleep)
• TPkt_Delay TSend-delay TReceive_Delay
• Tsleep Tpkt-sleep - TPkt_Delay (1)
• Compensating for Clock Drift
• Initial node delays packet transmission by
  Tinit_dly
• Tclk_drift (2 Cdrift ) (Tlast_ts 1)
• Tinit_dly Tclk_drift (2)
• Nodes should stay awake for Tawake (recaluclated
  1 / hour)
• Thop_dly (Nhops 50ms)
• NOTE N Maximum network diameter
• Tawake Tinit_dly Tclk_drift Thop_dly (3)

30
Application Specific Knowledge

• Network diameter
• To calculate Tawake
• Potentially obtain from routing layer
• Minimum latency requirements
• To calculate Tsleep
• Obtain from Application

31
Optimal Time Synchronization Period

• Increased SYNCH packet overhead is offset by
  decreased time nodes stay awake during each
  wake-up
• Optimal SYNCH period decreases with the sleep
  period

32
What if a SYNCH packet is dropped?

• Each SYNCH packet informs nodes 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

33
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
34
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
35
Time Tts 200msec

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

CH
X
X
X
36
Forwarding SYNCH-REQ responses

• Nodes that receive updated SYNCH packets will
  forward those on

CH
37
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
38
Outline

• Contributions / Background
• AppSleep / Time Synchronization
• Evaluation
• Adaptive AppSleep / Evaluation
• Summary of Results

39
Evaluation

• Theoretical Results using energy model
• Actual Measurements
• BMAC snapshot as of 9/20 (tinyos-1.x/contrib/ucb/t
  os/CC1000Pulse)
• AppSleep snapshot as of 9/20 (tinyos-1.x/tos/platf
  orm/mica2/CC1000)
• All are 7-hop networks

40
Energy Model Assumptions

• General
• 7-hop network diameter
• Nodes receive/forward data from average of 3
  children
• Nodes have 7 neighbors
• Routing traffic overhead included commensurate
  with sample traffic (2 packets)
• Radio Erx Eidle to conservatively estimate
  overhearing
• SMAC
• Node sends SYNCH packet every 1 / (SYNC_PERIOD
  NUM_NEIGHBORS) seconds Because if a node hears a
  SYNC packet, it doesnt need to send one out
• Maximum sleep 12 seconds
• BMAC
• Uses application control
• Based on code (tinyos-1.x/contrib/ucb/tos/CC1000Pu
  lse) as of 9/20/2004
• Maximum sleep 1.6 seconds
• Radio Awake Time Awake (1.5
  num-radio-switches)

41
Average Latency

• B-MAC is the best
• SMAC does not include adaptive listening
• B-MAC/S-MAC latency scales with number of hops,
  AppSleep is constant
• AppSleep
• Tcheck/2 Tlisten
• S-MAC
• (Tcheck/2 Tlisten)
• (Nhops 1) (Tcheck Tlisten)
• B-MAC
• (1.5 Tcheck Tlisten)
• (Nhops 1) (Tcheck Tlisten)

42
Energy to Maintain Network (No traffic)

• BMAC has the lowest overhead when no traffic is
  sent

43
Total Lifetime

• AppSleep attempts communication across network
  diameter, so for equivalent sleeping duration,
  SMAC outperforms it

AppSleep avg latency 375 sec
3x difference bet BMAC AppSleep for 22min
sampling period
AppSleep avg latency 46 sec
44
Impact of Neighborhood Size for 22-minute sampling

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

AppSleep shows 9X longer lifetime over BMAC for
20 neighbors
AppSleep avg latency 46 sec
AppSleep avg latency 5.9 sec
45
AppSleep Lifetime as Impacted by Network
Diameter Scalability
46
Actual Average Energy Consumption

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

BMAC estimate lt actual measurements
AppSleeps model closely matches measurement
47
Actual Average Time Radio is Awake

• BMAC is awake 4x longer than AppSleep

48
Packet Loss

• Test
• 4 runs each
• 6-20 hours
• 7-hops
• BMAC 3-6
• AppSleep gt 1-3

49
Varying Latency Usage Model

• Samples are sent in a pre-scheduled fashion
• Dynamic querying ability required, however
• Low latency query response required for a period
  of time after a sample has been returned (1
  minute response time)
• After that, the query response latency bounds
  increase substantially (10 minute response time)

50
Adaptive AppSleep State Diagram

• Within each state, AppSleep protocol is running
• Control packets from the cluster head moves the
  network between states
• Difference between states is length of sleep

Synchronous Data Return
Minimum Power Asynchronous Data
Query Ready 1 Asynchronous Data
Query Ready n Asynchronous Data
...
51
Theoretical Results

• AppSleep
• Minimum Power Network sleeps for 12 minutes
• Query Ready Sleep varies along x-axis
• Time Synchronization 1 / 2 Hours

52
Compare Adaptive and Non-adaptive

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

53
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

54
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

55
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

56
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.

57
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

58
Conclusion

• AppSleep
• More than 3x energy savings over BMAC/SMAC using
• Extended sleep periods gt 100 seconds
• Placing the processor into idle mode
• Good for very low duty cycle applications
• Low overhead time synchronization
• Not impacted by neighbor density
• Adaptive AppSleep maximizes energy savings while
  handling time varying latency requirements

59
Back up Slides
60
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

61
AppSleep Usage

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

62
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)

63
Total Lifetime Including Processing
gt 3x lifetime increase for all sampling periods
AppSleep avg latency .75 sec
64
Energy to Maintain Network Including Processing
AppSleep performs 3x better with processor in
idle mode
AppSleep avg latency 1.5 sec
65
AppSleep Parameters
66
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

67
Parameter Computation

• Time Awake

68
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

69
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
70
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

71
PICTURES FOR PAPER
72
Time 0
C
C
2 C
N-hop Delay
NN wakes up
N0 wakes up
N0 sends Pkt
NN receives Pkt