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

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

  • Uploaded on

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…

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'A Stream-Oriented Power Management Protocol for Low Duty Cycle Sensor Network Applications' - aderes

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 Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

Event Detection

Hazard Detection



Frequent Monitoring

Habitat Monitoring

Seconds => Minutes


Infrequent Monitoring

Minutes => Day



AppSleep Cycle Sensor Network Applications

  • 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

3 State Protocol Cycle Sensor Network Applications

Cluster Awake

Ctrl packets tx/rx

across network


timer fires

Node initiates

bulk transfer


timer fires

Node terminates

bulk transfer

Cluster Sleep

Proc idle/sleeps

Bulk Data Transfer

Note: Sleep period determined by latency needs of application

AppSleep Cycle Sensor Network Applications

  • 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


Bulk data transfer
Bulk Data Transfer Cycle Sensor Network Applications

  • 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


Synch packets
SYNCH Packets Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

  • 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? Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

  • Network diameter to calculate Tawake

    • Potentially obtain from routing layer

  • Data characteristics to specify Tsleep

    • Obtain from Application

Optimal synch period
Optimal SYNCH Period Cycle Sensor Network Applications

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 Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

  • Within each state, AppSleep protocol is running

  • SYNCH packets from the cluster head moves the network between states by changing Tsleep


Data Return


Tsleep = x

Query Ready n

Asynchronous Data

Query Ready 1

Asynchronous Data




Tsleep = 2n* x

Tsleep = 2 * x

Evaluation Cycle Sensor Network Applications

  • 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 Cycle Sensor Network Applications

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

SMAC operating



operating range

BMAC operating range

Energy to maintain network no traffic
Energy to Maintain Network (No traffic) Cycle Sensor Network Applications

BMAC has the lowest overhead when no traffic is sent

Total lifetime
Total Lifetime Cycle Sensor Network Applications

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

AppSleep avg


atency =

375 sec

3x difference bet

BMAC/SMAC & AppSleep

for 22min



AppSleep avg


latency =

46 sec

Impact of neighborhood size for 22 minute sampling
Impact of Neighborhood Size for 22-minute sampling Cycle Sensor Network Applications

  • 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


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


Actual Average Energy Consumption Scalability

  • 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 ScalabilityAppSleep

  • Much less energy consumed by adaptive protocol

  • Enables varying latency restrictions while maximizing energy savings

Future work
Future Work Scalability

  • Deploy AppSleep

  • Run AppSleep on top of an energy efficient MAC and quantify advantages

    • Especially when nodes miss SYNCH packets and “fail on”

Conclusion Scalability

  • 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

Back up Slides Scalability

T guard band 2 c drift ms hour t last synch hours 1
T Scalabilityguard_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



After Tguard_band all nodes along the path are guaranteed to be awake



Node x

wakes up

Node y

wakes up

Time Nodes Stay Awake ScalabilityTawake = 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




Thop_dly = Nhops * HopDly (50ms)

Node 1

starts sending

Node n

wakes up

Node 1

wakes up

Node n


Packet delay ScalabilityTPkt_Delay = TSend-delay + TReceive_Delay

Packet Transmission

Send Delay



P r e a m b l e

D a t a



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


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 Scalability

  • 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 Scalability

  • 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 Scalability

  • 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 Scalability

  • 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 Scalability

  • BMAC is awake 4x longer than AppSleep

Time synchronization timeline
Time Synchronization timeline Scalability

  • 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


wakes up

Neighboring nodes hear


send updated SYNCH messages

Node broadcasts

SYNCH-REQ message

Time synchronization time t ts
Time Synchronization ScalabilityTime = Tts

  • Cluster Head floods SYNCH packets

  • Nodes update the SYNCH packet and forward the first one

  • Some nodes do not hear them




Time t ts 200msec
Time = T Scalabilityts + 200msec

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





Forwarding synch req responses
Forwarding SYNCH-REQ responses Scalability

  • Nodes that receive updated SYNCH packets will forward those on


Time t ts 200msec 400msec
Time = T Scalabilityts + 200msec + 400msec…

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



Robustness Scalability

  • 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 Scalability

  • Control Packets should be reliably unicast

  • Incorporate a cluster head selection algorithm

  • Routing considerations

Future features
Future features Scalability

  • 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 Scalability

> 3x lifetime

increase for all

sampling periods

AppSleep avg latency =

.75 sec

Average latency1
Average Latency Scalability

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

Energy to Maintain Network Including Processing Scalability

AppSleep performs 3x better

with processor in idle mode

AppSleep avg

latency = 1.5 sec

Appsleep parameters
AppSleep Parameters Scalability

Performance characterization
Performance Characterization Scalability

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 Scalability

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 Scalability

  • 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 Scalability

Parameter Computation

Difference between bmac paper
Difference between BMAC paper Scalability

  • 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 Scalability

Time = 0




N-hop Delay

NN receives Pkt

NN wakes


N0 wakes


N0 sends




Receiver; located

across the network




N-hop Delay


Theoretical clk drift


Initial packet delay


wakes up

N0 wakes


N0 sends


NN receives Pkt

Routing Scalability

  • 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

Time = 0 Scalability



2 * C

N-hop Delay

NN wakes


N0 wakes


N0 sends


NN receives Pkt