The Sensor Networking with Delay Tolerance project SeNDT project An LTP implementation

1
The Sensor Networking with Delay Tolerance
project (SeNDT) project AnLTP implementation

• http//down.dsg.cs.tcd.ie/sendt/
• Stephen Farrell
• stephen.farrell_at_cs.tcd.ie
• March 2005 IETF

2
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
• sensorlt-gtsensor
• sensorlt-gtmule

3
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

4
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!

5
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

6
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

7
Lake Nodes and Mules
8
Visibility -gt 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

9
Comms. Schedule -gt 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

10
XML schedules
Schemas, samples at http//down.dsg.cs.tcd.ie/sch
emas/
Edit
Scheduling Time
Kludgey binary
Run Time
perfume_main (daemon)
LTP segs.
LTP segs.
11
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