1 / 5

Flyspec – a network for silicon fly sensors

Flyspec – a network for silicon fly sensors. David L. Mills University of Delaware http://www.eecis.udel.edu/~mills mailto:mills@udel.edu. Assumptions. Designed for ultra-simple ad-hoc sensor nets with short range burst radios

ssimmons
Télécharger la présentation

Flyspec – a network for silicon fly sensors

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. Flyspec – a network for silicon fly sensors David L. Mills University of Delaware http://www.eecis.udel.edu/~mills mailto:mills@udel.edu

  2. Assumptions • Designed for ultra-simple ad-hoc sensor nets with short range burst radios • Simple undisciplined ALOHA medium access without carrier sense or backoff. • Transmissions consist of omnidirectional bursts with limited range. • Entities are of two types • End nodes (sources and sinks) • Intermediate nodes (repeaters) • All nodes must be able to transmit, some sources might not be able to receive. • There is no routing table, no routing algorithm and no congestion control. • Routing principles are based on dynamic reverse-path forwarding.

  3. Routing principles • Basic routing principle is to determine when a burst for a designated sink is received, should it be repeated or not. • Sources and sinks are assigned distinct IDs; repeaters have no IDs. • Every burst sent carries the source ID, sink ID, sequence number, which increments for each burst, and hop count, which is initialized at zero and increments at each repeater. • When a burst is received, buffer it and initialize a counter, which then decrements at a fixed rate. • If the counter value falls below a specified threshold, increment the hop count and repeat the burst. • If a burst is received with the same source ID, sink ID, sequence number and • greater than the hop count, purge the buffer. • equal or less than the hop count, ignore the burst.

  4. Minding the thresholds • The basic idea is to delay an appropriate time to allow some other node closer to the destination to repeat a burst without wasting bandwidth for multiple transmissions. • Each repeater has a list of recently heard burst source and sink IDs, together with hop count and threshold. Initially, the threshold is set depending on the hop count from the source. • The threshold degrades slowly so to allow reconfiguration should a repeater be lost. • If a packet is received with destination ID not on the list, the threshold is set relatively low. • The repeater will hold on to the burst waiting a relatively long time to give other repeaters with knowledge time to transmit first. • A nearby repeater with knowledge will repeat it at greater hop count, which will kill the buffer.

  5. Questions • We must assume bursts flow both ways between source and sink in order to learn the reverse path. So, sinks might run a low-level whisper campaign to the sources. • When the network launches, repeaters don’t know anything, so bursts will random-walk until finding sinks, all the time leaving a trails behind where they have been. • Is this thing stable? Dies it eventually converge to shortest paths? • What are the failure/recovery dynamics? Does it scale?

More Related