Presentation is loading. Please wait.

Presentation is loading. Please wait.

Remote Programming Dissemination Collection Network Management Gilman Tolle (also speaking for Jonathan Hui)

Similar presentations

Presentation on theme: "Remote Programming Dissemination Collection Network Management Gilman Tolle (also speaking for Jonathan Hui)"— Presentation transcript:

1 Remote Programming Dissemination Collection Network Management Gilman Tolle (also speaking for Jonathan Hui)

2 A Sensor Network Link?

3 A Sensor Network Link!

4 Why Over-The-Air Reprogramming? Embedded nature of sensor networks – they’re small! Network scales reaching thousands of nodes – there’s a lot of them! A necessity in debugging and testing cycle – we can’t stop messing! Learn about the environment after deployment – things change!  sensing data, network characteristics, etc.

5 What is Deluge? A reliable data dissemination protocol for program images over a multihop network. Combined with a bootloader (TOSBoot)  Network Programming Program

6 Deluge Data Representation Program divided into pages, each consisting of N packets. Reduced RAM requirements Allows for spatial multiplexing Program Packets 1234N

7 How Does Deluge Work? Nodes periodically advertise  Suppress similar advertisements Version 2 here. I only have version 1.

8 How Does Deluge Work? Neighboring nodes request data  Suppress similar requests Send me page 1!

9 How Does Deluge Work? Requested data is broadcast Packet 12 of page 1!

10 How Does Deluge Work? Dropped packets are NACKed Repeat packet 4 of page 1! Repeat packet 32 of page 1!

11 How Does Deluge Work? Dropped packets are sent again Packet 4 of page 1!

12 How Does Deluge Work? Advertise for propagation to next hop Version 2 here. I only have version 1.

13 Spatial Multiplexing Propagate in “waves” Exploit limited radio range for concurrent broadcasts. Reduced completion time o(d + S obj ) vs. o(d * S obj ) Page 0Page 1

14 Epidemic Propagation Epidemic propagation from one source

15 Deluge Features Epidemic propagation from one source or many  Continuous propagation effort by all nodes  Turn on/off radios at will  Reach nodes with intermittent connectivity   Will find a path if it exists Aggressive message suppression  Scales with density  Ultra low quiescent traffic

16 Deluge Features Management  Multiple program images  Image metadata  User confirmation on expensive operations Minimize operator error Robustness  Redundant CRCs  Golden Image with write protect  Load Golden Image Watchdog trigger Golden gesture TOSBoot  TOSBoot as isolated code  Verify CRCs  Verify system voltage ProgAProgBProgC Program Name Compile Time UserID Hostname Platform CRASH! CRC

17 Deluge Lessons Advantages  Ease of reprogramming 100’s-1000’s of nodes  Does not erase node IDs  Golden Image is immensely useful  Quickly switch between images  More reliable than uisp or msp430-bsl  Deluge over more efficient that ! Disadvantages  Ease of reprogramming 100’s-1000’s of nodes :)

18 Routing Getting the packets through, across many hops  Every node is a router too Gateway-centric  Get data from the gateway to all the nodes – dissemination  Get data from all the nodes to the gateway – collection  Node-to-node? Message-based  Transferring single packets, datagram-style A layer, with clients above and services below  Attribute Queries and Changes  Event Reporting  RPC Command Layer IP is not the right solution  Any-to-any is not useful enough to justify the state and complexity

19 Drip Dissemination Layer Each sent message reaches all nodes in the network  Good for sending commands and queries A generic single-message communication layer  command send[type](message) on the host  event receive[type](message) on the node Lightweight header – type and sequence number  Higher layer can add destination addressing Uses Trickle epidemic algorithm (Phil Levis)  Dynamic forwarder selection  Periodic retransmissions  Neighborhood suppression Caches latest message on each channel GW Client

20 Drain Collection Layer Every node needs to send data to a gateway A generic single-message communication layer  command send[type](message) on the node  event receive[type](message) on the host Very well-studied problem (Too many authors to list)  Link estimation plus distributed execution of shortest-path algorithm Ours must support multiple gateways  Each gateway builds a tree -- each node selects the cheapest next-hop  Automatic subdivision of the network into pieces GW Client

21 Routing Goals No predefined geographic structure  Routing decisions based only on connectivity and link estimators  Makes it easier to deploy and move nodes  Minimal state – single next hop, update-in-place Robust to lossy networks  Drip periodically retransmits cached data with exponential backoff  Drain uses link-layer ACKs, retransmissions, and long retry window  Experiment with simple duty cycle: 1 second on, 1 second off  Looks just like a lossy network, but the protocols keep working Include rich metadata (source addresse, ttl, sequence numbers)  “How are those bad packets getting into the network?” Impossible to answer without metadata  Enables network management through packet sniffing Even without a specific “management” layer

22 Network Management Sensor networks fail  All networks fail sometimes! Management lets us detect and respond to problems  Just as important for our networks  Harder to do, thanks to highly dynamic networks! Passive Packet Sniffing Active Network-Layer Monitoring Management Queries Monitoring Policies and Statistics

23 The Unbearable Lightness of Sniffing Just sniffing packets reveals a wealth of information  Active nodes from routed Drain messages  Network topology from Drain beacon messages  Dissemination behavior from Drip messages  Reprogramming status from Deluge advertisement messages  Overall traffic rates and histograms by type Doesn’t make any extra demands on the network  “If you’re going to send the packet anyway…”  Passive management information gathering Works when the network isn’t running the management layer  Sometimes, you really need that extra few kB of code space GW

24 The Story About Ping Characterizing the performance of a dynamic network is HARD The first tool of network management: ping  Best with a few nodes that you don’t check very often The second tool of network management: the ping daemon  Can provide historical and current data on many nodes The third tool of network management: the ping visualizer  Scalable way to handle large complex networks  Most networks don’t have a natural spatial realization Our network is firmly embedded in space

25 The 10,000-Foot View

26 Management: The Gathering Sometimes, you need to know more than ping can tell you  How long has the node been running?  Has the node been dropping any packets? … and in our energy-constrained mote-land  What is the node’s power source?  Does the node have enough energy to run? Management can be seen as a database problem TinyOS application exports information  Named attributes, variables in RAM Attribute schema generated at compile time  Replace long names with short integers – save bandwidth  Store schema on mote using Deluge Supplement Nucleus component responds to queries  “Get attributes {2, 3, 6} and RAM variable at {0x1a8c} with length {2}” System & App Components Attribute Dispatcher Query Processor Drip/Drain

27 Nucleus Host Architecture GW Query Translator Monitoring Daemon Web Visualization Command-Line Tools GW Packet Forwarder Other Client Applications XML-RPC Binary Data XML-RPC Binary Data Pixels Characters Other Mgmt Tools

Download ppt "Remote Programming Dissemination Collection Network Management Gilman Tolle (also speaking for Jonathan Hui)"

Similar presentations

Ads by Google