1 / 55

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. Design a protocol that would Enabling dynamic querying of a network that was mostly asleep and is…

aderes
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  5. Informal Application Taxonomy Event Detection Hazard Detection N/A B-MAC Frequent Monitoring Habitat Monitoring Seconds => Minutes S-MAC Infrequent Monitoring Minutes => 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 => 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 n Asynchronous Data Query Ready 1 Asynchronous Data SYNCH SYNCH ... Tsleep = 2n* x Tsleep = 2 * 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 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

  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 < actual measurements AppSleep’s 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 <= 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

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

  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/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

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

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

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

  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

More Related