The Sensor Networking with Delay Tolerance project (SeNDT) project

AnLTP implementation

http://down.dsg.cs.tcd.ie/sendt/

Stephen Farrellstephen.farrell@cs.tcd.ie

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:

– http://down.dsg.cs.tcd.ie/schemas/ ● CLI for translation to Binary-kludge

XML schedules

Kludgey binary

perfume_main(daemon)

schedule.xmlfield.xml

LTP segs. LTP segs.

Scheduling Time

Run Time

Edit

perfume_xmlsched(cli)

Schemas, samples at: http://down.dsg.cs.tcd.ie/schemas/

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