A stream oriented power management protocol for low duty cycle sensor network applications
This presentation is the property of its rightful owner.
Sponsored Links
1 / 55

A Stream-Oriented Power Management Protocol for Low Duty Cycle Sensor Network Applications PowerPoint PPT Presentation


  • 95 Views
  • Uploaded on
  • Presentation posted in: General

A Stream-Oriented Power Management Protocol for Low Duty Cycle Sensor Network Applications. Nithya Ramanathan Mark Yarvis Lakshman Krishnamurthy Deborah Estrin. Problem Definition. Design a protocol that would Enabling dynamic querying of a network that was mostly asleep and is…

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


A stream oriented power management protocol for low duty cycle sensor network applications

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

Nithya Ramanathan

Mark Yarvis

Lakshman Krishnamurthy

Deborah Estrin


Problem definition

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


Contributions

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


Mac power management protocols

MAC power management protocols

  • Challenge – ensure nodes are awake to hear neighboring transmissions

  • Packet-based protocols

    • Ensure reception of every asynchronous packet => 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, preamble=240B

    • Sleep periods on the order of milliseconds

      • E.g. sleep= 100 ms, radio will switch 600 times in 1 minutes


Informal application taxonomy

Informal Application Taxonomy

Event Detection

Hazard Detection

N/A

B-MAC

Frequent Monitoring

Habitat Monitoring

Seconds => Minutes

S-MAC

Infrequent Monitoring

Minutes => Day

FabApp

?


Appsleep

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


A stream oriented power management protocol for low duty cycle sensor network applications

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


Appsleep1

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


Bulk data transfer

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


Synch packets

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 => 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”


Impacts on cluster synchronization

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


What if a synch packet is dropped

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


Parameters

Parameters

  • Network diameter to calculate Tawake

    • Potentially obtain from routing layer

  • Data characteristics to specify Tsleep

    • Obtain from Application


Optimal synch period

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


Varying latency usage model

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


Adaptive appsleep state diagram

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 n

Asynchronous Data

Query Ready 1

Asynchronous Data

SYNCH

SYNCH

...

Tsleep = 2n* x

Tsleep = 2 * x


Evaluation

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


Average latency

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


Energy to maintain network no traffic

Energy to Maintain Network (No traffic)

BMAC has the lowest overhead when no traffic is sent


Total lifetime

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


Impact of neighborhood size for 22 minute sampling

Impact of Neighborhood Size for 22-minute sampling

  • Demonstrates 2nd key result: despite increased transmission overhead, SMAC exceeds BMAC for dense neighborhoods due to BMAC’s preamble over-hearing

  • SMAC & AppSleep not impacted by neighbor density

AppSleep performs

9x better than

BMAC for 20

neighbors

AppSleep avg

latency = 46 sec


Appsleep lifetime as impacted by network diameter scalability

AppSleep Lifetime as Impacted by Network Diameter: Scalability

Loses 5% of life-time as

for each increase of 5

hops in network

diameter


A stream oriented power management protocol for low duty cycle sensor network applications

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 <

actual measurements

AppSleep’s model

closely matches measurement


Compare adaptive and basic appsleep

Compare Adaptive and Basic AppSleep

  • Much less energy consumed by adaptive protocol

  • Enables varying latency restrictions while maximizing energy savings


Future work

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”


Conclusion

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


A stream oriented power management protocol for low duty cycle sensor network applications

Back up Slides


T guard band 2 c drift ms hour t last synch hours 1

Tguard_band = (2 * Cdrift [ms/hour]) * (Tlast_SYNCH [hours] + 1)

For example: If it has been <= 4 hours since the SYNCH packet, nodes could

wakeup anytime from Cdrift * (Tlast_SYNCH + 1) msec before/after they should

Node y’s clock

Node x’s 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


A stream oriented power management protocol for low duty cycle sensor network applications

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 1’s 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


A stream oriented power management protocol for low duty cycle sensor network applications

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.


Energy model assumptions

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/CC1000Pulse) as of 9/20/2004

    • Used energy model in Sensys Paper

  • AppSleep

    • Minimum Power: Network sleeps for 12 minutes

    • Time Synchronization: 1 / 2 Hours


Choosing an energy efficient approach

Choosing an energy efficient approach

  • Minimize latency of synchronous sampling:

    • AppSleep (frequency >= 1 minute): Monitoring

    • SMAC (frequency >= 1 second && <= 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


Unsolved questions

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


Current limitations to appsleep

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.


Actual average time radio is awake

Actual Average Time Radio is Awake

  • BMAC is awake 4x longer than AppSleep


Time synchronization timeline

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


Time synchronization time t ts

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


Time t ts 200msec

Time = Tts + 200msec

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

CH

X

X

X


Forwarding synch req responses

Forwarding SYNCH-REQ responses

  • Nodes that receive updated SYNCH packets will forward those on

CH


Time t ts 200msec 400msec

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


Robustness

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


Appsleep usage

AppSleep Usage

  • Control Packets should be reliably unicast

  • Incorporate a cluster head selection algorithm

  • Routing considerations


Future features

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)


Total lifetime including processing

Total Lifetime Including Processing

> 3x lifetime

increase for all

sampling periods

AppSleep avg latency =

.75 sec


Average latency1

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)


A stream oriented power management protocol for low duty cycle sensor network applications

Energy to Maintain Network Including Processing

AppSleep performs 3x better

with processor in idle mode

AppSleep avg

latency = 1.5 sec


Appsleep parameters

AppSleep Parameters


Performance characterization

Performance Characterization

Assume number of hops = 5

Time = Average latency to return an asynchronous event

1 day

11 min

22 min

44 min

  • AppSleep

  • 375 secs

  • 2. BMAC

  • .55 secs

  • SMAC

  • 54 secs

  • AppSleep

  • 46 secs

  • 2. SMAC

  • 54 secs

  • BMAC

  • .28 secs

  • AppSleep

  • 23 secs

  • 2. SMAC

  • 54 secs

  • ~2. BMAC

  • .55 secs

  • AppSleep

  • 46 secs

  • 2. BMAC

  • .55 secs

  • SMAC

  • 54 secs


Performance characterization1

Performance Characterization

5.6 min

1.4 min

2.8 min

  • AppSleep

  • 46 seconds

  • 2. BMAC

  • .11

  • SMAC

  • 54 secs

  • SMAC

  • 54 secs

  • 2. AppSleep

  • 46 secs

  • BMAC

  • .11 secs

  • AppSleep

  • 46 secs

  • 1. SMAC

  • 54 secs

  • BMAC

  • .11


Min tsleep to switch to deep sleep

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


Parameter computation

Time Awake

Parameter Computation


Difference between bmac paper

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


Worst case clock drift scenarios

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


Routing

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


A stream oriented power management protocol for low duty cycle sensor network applications

Time = 0

C

C

2 * C

N-hop Delay

NN wakes

up

N0 wakes

up

N0 sends

Pkt

NN receives Pkt


  • Login