[Tinyos-devel] CTP and LPL on tmote

[Andreas Köpke]

Razvan Musaloiu-E. wrote:
> Hi!
>
> On Mon, 22 Dec 2008, Andreas Kopke wrote:
> > Just a short update on our experiments:
> >
> > Setup:
> > 34 nodes,
> > 3-5m apart, 3D grid
> > sink always on
> > duty cycle 5%
>
> Quick question: is the 5% equivalent to setting the local sleep interval
> to about 210ms?
Roughly, yes.

> And another quick one: what was the actual duty cycle achieved by the
> network?
See below.

> --
> Razvan ME
>
> > real network diameter: 3-4 hops
> > sink in "corner"
> > each node transmits about one packet in 5min (random uniform distribution
> > in interval)
> >
> > Changes to LPL to get nearly 100% delivery ratio for two nodes, 3m apart:
> >
> > - extended expected sleep interval at receiver
> >  call LowPowerListening.setRxSleepInterval(msg, lpl + 20);
> >  for some reason, the real sleep interval of a telosb node is 5-6ms
> > longer than computed.
> >
> > - use energy detect for CCA
> >  The standard threshold of -77dBm is too high to detect packets/WLAN.
> >  Solution: floating estimation of RSSI noisefloor and fixed threshold.
> >  In our testbed, the RSSI noisefloor is node dependent, probably due to
> > USB. Channel busy, if RSSI >= noisefloor + 8 dB, or if valid bits are
> > detected
> >
> > - Carrier Sense the channel before packet transmission longer than the
> > 11ms gap between two packets. Prevents mixing packets from two or more
> > packet trains.
> >
> > - send packet repetitions without CCA
> >  Otherwise, the gaps between packets become too large.
> >
> > - fix bug in sleep time computation (integer overflow)
> >
> > - two busy CCA samples are enough to declare the channel busy. Does not
> > seem to have much influence.
> >
> > - DELAY_AFTER_RECEIVE=20 to reduce energy consumption. Smaller values
> >  impact the delivery ratio.
> >
> > Changes in CTP:
> > - minimum beacon interval 2min (some also with 5min)
> > - maximum beacon interval 12min (some with 30min)
> > - round in ETX estimator (instead of floor)
> > - max retries: 10
> >
> > Results:
> > - ETX to parent converges to 10
> > - THL converges to diameter (3-4hops)
> > - Transient: 2-3 hours (then the above mentioned values are
> >  somewhat reasonable and network starts to deliver messages)
> >
> > Strange observations (not in all experiments):
> > - the sink node does not start to send beacons for 4 hours. Then
> >  starts and everything works fine.
> > - the ETX values stay at 265 for more than 10 hours
> > - after running for more than two days, a couple of nodes disappear in
> >  permanent routing loops. We had to restart the experiments to get rid of
> >  them.
> > - ETX is 10, although the number of transmission attempts in the link is
> >  between 1.2 and 2. (or in delivery ratios: 50% to 80%)
> >
> > Comparison with MultihopLQI:
> > - comparable overall delivery ratio
> > - MultihopLQI results in permanent loops after running for more than 2
> > days
> >
> > Changes to MultihopLQI to get rid of permanent loops:
> > - distinguish between good links (LQI>=100) and bad links (all others),
> > only To do so, set LQI = 100 for  good links, LQI = 50 for all others. -
> > evict parent if more than 2 beacons are missing (instead of 8) - detect
> > broken links (exceeded MAX_RETRIES), evict parent, send update beacon -
> > beacon interval 12min, (5min for faster repair of broken links)
> >
> > Conclusion:
> > It runs now , somehow. It seems possible to find a way to reduce the
> > transient and the sometimes strange startup behavior. The discrepancy
> > between ETX and the retries is of academic interest. It is interesting to
> > note that the uplink breaks for short time periods, resulting in a sharp
> > increase of ETX with no parent change (saw-tooth behavior of ETX).
> >
> > The permanent loops are a real pain. The comparison with MultihopLQI
> > suggests that there might be an interaction with the toplogy in our
> > testbed, the bug seems to go unnoticed in other testbeds. Or the
> > published results are from experiments shorter than three days.
> >
> > Merry christmas,
> >
> > Andreas
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel