1 / 25

Low-Power Wireless Bus (LWB)

Low-Power Wireless Bus (LWB). SenSys 2012 Federico Ferrari, Marco Zimmerling (ETH), Luca Mottola (SICS), Lothar Thiele ( ETH) ("Potential" BEST PAPER/RUNNER UP) NSLab study group 2012/11/05 Presented by: Yu-Ting. Outline. Introduction Protocol Operation Evaluation Discussion.

mason
Download Presentation

Low-Power Wireless Bus (LWB)

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. Low-Power Wireless Bus (LWB) SenSys 2012 Federico Ferrari, Marco Zimmerling(ETH), Luca Mottola(SICS), Lothar Thiele (ETH) ("Potential" BEST PAPER/RUNNER UP) NSLab study group 2012/11/05 Presented by: Yu-Ting

  2. Outline • Introduction • Protocol Operation • Evaluation • Discussion

  3. Comment Part1 • Good writing structure • Clearly explain how this protocol operates • An extended work of Glossy • Take the efficient flooding advantage of Glossy • A brand-new and awesome unified solution for WSN communication

  4. Feature • Bootstraps quickly and efficiently, while distributing energy costs evenly • In many-to-one scenarios, LWB operates reliably and efficiently under a wide range of traffic loads, and promptly adapts when traffic demands change • Supports many-to-many communication without any changes • Topology-independent • Supports mobile nodes acting as sinks, sources, or both without any changes or performance loss • Very good energy consumption!

  5. Comment Part2 • Compare with 7 different protocols • Good to get familiar with important related work • Seems to beats all the other state-of-art protocols • Clearly describe the scenario and parameters in evaluation • Use fair choices of parameter for the other protocols • With brief explanation of how other protocols operate • Multi-Sink is actually not an easy task (few protocols support that)

  6. Outline • Introduction • Protocol Operation • Evaluation • Discussion

  7. Overview

  8. Operation • Sink acts as host here • Inter-packet interval (IPI) = 6s here

  9. Host Failure • Failure of host: complete absence of communication within Thf • Upon detect it, nodes switch to the next channel • Hardcode a circular ordered list <channel, host_id> • After not receiving stream request for Thf, host also switch the the next channel

  10. Scheduler • Determining the round period • Tmin (1s): > total duration of a round Tl • Tmax (30s): < time of synchronization failing due to clock skew • dmax(60 slots): number of data slots that the scheduler can map in a single schedule packet (so, # of pkts/ round) • When Topt <Tmin, the network is saturated • Allocation data slots to streams • where as: number of data slots the scheduler allocates to streams during a round rs = T/IPIs

  11. Outline • Introduction • Protocol Operation • Evaluation • Discussion

  12. Metrics • Metrics • Data yield: • Radio duty cycle • Protocols • Testbeds

  13. Bootstrapping • Fully bootstrapped: when all source nodes delivered at least one packet to the sink • LWB, CTP: < 2min; Dozer: >18min • Fairness in energy consumption: only LWB • Battery depletion may cause a network partition

  14. Many-to-One Scenario:Light/Heavy/Fluctuating Traffic

  15. Many-to-Many Scenario • 8 sinks

  16. Topology Changes - External Interference

  17. Topology Changes - Node Failures

  18. Mobile Sink

  19. Mobile Sources(4) and Mobile Sink(1)

  20. Real-World Trial • Many-to-many • One-to-many • Change traffic demands • Change active nodes • 5 mobile nodes (B,M1~M4) as both sources and sinks • 7 days during working • B: trigger high rate stream of all mobile nodes

  21. Outline • Introduction • Protocol Operation • Evaluation • Discussion

  22. Scalability • The more number of streams, the more consumption of memory and computation time • TelosB can support several hundreds of streams (each stream with 15bytes/pkt and 13bytes to store in memory) • [YT] Memory is used to store a burst of received data within 1 round • The more number of streams, the more saturated the bandwidth is

  23. Network Diameter • Difficult to determine the network diameter in advance, which affect the length of data (Td) and schedule (Ts) • Current prototype is 7 hops ([YT] it's not short…) • When the network spans "several tens" of hops, other approaches may perform better • Longer slots (Ts,Td) leads to fewer available slots per round and thus bandwidth • Default setting: support 300 streams with IPI=5s,so double-length slots support at most IPI=10s

  24. Alternative Scheduling Policies • Trade off between latency and energy consumption • LWB-low-latency: adapts the round period T such that the next round occurs immediately after the generation of new packets • LWB-fixed-period: fixes T = Tmin • LWB is easy to modify this,unlike others!

  25. Q&A

More Related