[Tinyos-devel] CTP and LPL on tmote

[Razvan Musaloiu-E.]

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?

And another quick one: what was the actual duty cycle achieved by the 
network?

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