The Sensor Networking with Delay Tolerance project (SeNDT) project An LTP implementation Stephen Farrell March 2005 IETF

The problem ● Lake water quality monitoring ● Aiming for a bunch of cheap-ish (~€1000) sensors (10's) in a lake – Which can last a winter with little servicing ● Custom I/O board + off-the-shelf components ● Using the data-mule approach – Fishing, tour-boats, passing traffic ● Using LTP for comms – sensor sensor – sensor mule

SeNDT LTP implementation ● Called “perfume” ● Currently implements -01 version of draft without green-part support – Will update to -02 draft real soon now ● Provides a sockets API – Userland not kernel ● Cues via whos_listening() and whos_talking() SPIs – SPI implementation based on SeNDT schedules ● XML for schedule calculation

Mules ● In sensor networking a mule is a special node that wanders through the sensor field and picks up packets for further routing – Idea is that mules allow for much sparser networks ● Mules are very, very like DSN Earthstations – Wandering amongst different clusters of sensor node is very like the Earth turning to make the 70m Goldstone antenna face Mars!

Mules follow Trajectories ● Each consists of a sequence of waypoints ● Each waypoint has the following attributes – Position ● Terrestrial cases are lat/long – no altitude as yet – Arrival time – Pause time – Next move type (hop or slide) ● Whether node's radio is on or off as it transits to the next waypoint

Probabilistic Trajectories ● We associate a probability with each path – Instead of a sequence of waypoints, at each step we have a set of possible next waypoints, each with a certain probability – Overall we get a weighted tree of waypoints with probabilities as weights ● Many nodes are stationary which makes the calculation a bit more efficient – Though we use the same code, i.e. even fixed positions are regarded as probabilistic trajectories ● Mules follow probabilistic trajectories through a field of nodes

Lake Nodes and Mules

Visibility -> Comms. Schedule ● Various algorithms possible – Minimal: Attempt to ensure that each node gets a chance to talk to at least one mule during a given schedule period – Filled: As above but iterate to try to “fill-in” all gaps until no change or configured limit reached (this is the default) – Could envisage others too, e.g. ● Giving configured weights to nodes, or more interestingly basing such weights on actual measured network stats ● Various random schemes

Comms. Schedule -> Schedule ● There are other things to schedule as well: – Sensing events (on, off, report...) – System events and settings ● Used to (re-)configure node ● Configured sleep events ● Two formats for schedules: – Binary-kludge run-time format ● No xml parsing on embedded system ● There's an API and test tool – XML format for scheduling-time tools ● All my schema stuff *.xsd, samples are at: – ● CLI for translation to Binary-kludge

XML schedules Kludgey binary perfume_main (daemon) schedule.xmlfield.xml LTP segs. Scheduling Time Run Time Edit perfume_xmlsched (cli) Schemas, samples at:

Conclusion ● LTP is useful for terrestrial applications – Also looking at other environmental monitoring applications for the sensor nodes ● Noise/Quiet ● Easy enough to implement ● Looking for funding for a real pilot – Have a lake already! ● Planning to make LTP code public – When/if stable and have support resources