[Tinyos-devel] CTP and LPL on tmote

[Andreas Köpke]

Just a short update on our experiments:

Setup: 
34 nodes, 
3-5m apart, 3D grid
sink always on 
duty cycle 5%
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