Net2WG/Notes/20071109
Contents
Net2WG/Notes/20071109 Meeting Notes
Agenda
* 6lowpan code * CTP over LPL
Participants
* Mike, JHU * Razvan, JHU * Rodrigo, UCB * Om, USC
Action Items
* Rodrigo - CTP root beacons
Discussion Notes
6lowpan code
Om: Should we put the code in support directory? Maybe not because the code is actually a part of the protocol that you need to run as opposed to accessory files.
Razvan: Why is it different from deluge tools?
Rodrigo: I think we should put it in support. This seems no different from sf.
Om: I think it is different because the host is part of the network.
CTP over LPL
Om: We are experimenting with running tos/lib/net/lqi based collection with LPL. Razvan and Mike are running some experiments running network protocol in dutycycled environment. We can review them.
Razvan: We started using LPL before it was finalized. The problem was 802.11 was waking up the motes and keeping them on for 100ms. We replace the CCA check with a mechanism in which motes send a pkt and wait for an ack if they need to awake. With this mechanism there is no false positive. We call this Low Power Probing (LPP).
Rodrigo: So you guys got rid of symmetric wake-up requirement because of their scenario.
Om: Running collection with LPL is pretty straightforward. One needs to go to each component that generates packet and just because the packet is sent need to set the receiver sleep interval in the metadata. This determines the length of the packet train. In addition, a node during initialization needs to set local sleep interval. With these two changes, we have done some experiments on a 40-node setting and we are able to get packets through. One surprising thing is because the radio stays on for 100ms after each transmission or reception in anticipation of more packets, the dutycycle could be much higher than it could be. In our experiments, each node sending multihop lqi beacons every 30s and data pkts every 10s, with a sleep interval of 500ms, the dutycycle distribution across the network was somewhere between 20 and 50%. This seems exceptionally high. We are planning to experiment with smaller values of wait time to see its impact on dutycycle and latency distribution.
Rodrigo: Can you share those changes? Fred Jiang at Berkeley is interested in doing some experiments.
Rodrigo: Another potential problem in dutycycled environment is the beacon rate, especially the root beacon rate. It seems high and it is constant. Should we revisit this?
Om: Can we use a trickle timer to drive the beacons? We can reset the timer whenever the root receives a pull bit.
Razvan: What do we use trickle for?
Om: We want to send beacons faster during initialization or when network condition has changed so that we can learn about the changes rapidly. But in a quiet network, we don't need to estimate the link qualities or recompute the paths frequently. So the timer starts with an interval of 1s, then it fires in 2s, 4s etc and each time it fires a beacon is sent out. But when a new node is introduced in the system or for some reason if a node wants to get a quick update of the route, it sends a beacon with a PULL bit which resets the timer on the nodes that receive the beacon and they send beacons at a faster rate and increase the interval by 2x again, ...
Rodrigo - I will think about the root beacon timer and send an email. Maybe we just need to test to see if "reset on pull" approach works.
