[Tinyos-devel] [Tinyos-help] Collection: Loosing Connection to a Node

Tue Apr 29 03:39:37 PDT 2008

Hi David & Roman,

Thanks for your comments. I would be really interested in trying Roman's
workaround. Roman, would you mind sharing it with us?

Phil & Omprakash,

Considering these comments, what kind of action plan do you have in mind to
make LPL & CTP work together? Will net2 wg own the case? We (a team of 3 EE
& CS at Bosphorus University, Istanbul) are ready to provide support in
testing and any other aspect you see appropriate.

Looking forward to hearing from you.

Thanks,
Bulut

On Tue, Apr 29, 2008 at 12:47 PM, Roman Lim <rlim at ee.ethz.ch> wrote:

> I had similar problems when I tried to run CTP with LPL on a 25 nodes
> network (tmotes). first, routes were quickly set up, but later, the network
> was dieing and nodes were choosing routes that did not lead to the sink.
>
> First I was playing with constants in CtpForwardingEngine.h, increased
> FORWARD_PACKET_TIME and other time constants, but could only measure slight
> overall improvements. I also think that deriving these time constants from
> the LPL interval time would be a good thing.
>
> Finally I got a working CTP/LPL network by adding some timing intelligence
> to the cc2420 LPL stack. The drawback of this solution is, that it bloats
> the existing radio stack with another 5k flash memory usage. Maybe we should
> add this extension to the default CC2420 LPL stack.
>
> Roman
>
>
> David Moss wrote:
>
> > In creating the new CCxx00 radio stack's LPL/Wake-on Radio layer and
> > testing
> > it for CTP, I found lots of issues with low power communications in
> > general
> > that require lots of experimentation with the radio stack and a logic
> > analyzer.  Someone needs to do the same analysis on the CC2420 stack,
> > and I
> > unfortunately don't have time to do it now.
> >
> > Acknowledgments are the biggest problems.  Collisions are another
> > problem,
> > but collisions ultimately feed into the acknowledgment problem.  If we
> > can
> > avoid collisions and prevent each node from transmitting during an
> > acknowledgment period, network reliability will improve.
> >
> > With the CCxx00 stack, I found it necessary to remove hardware address
> > recognition to improve the performance of acknowledgment success rate. I
> > forced each node to take time to receive every packet, and respect the
> > acknowledgment wait period if the packet was not destined for that
> > particular node.
> >
> > I also added progressive backoffs to the CCxx00 stack, where the CSMA
> > backoff duration gets longer and longer as the channel is found to be
> > busy.
> > This works well for long-preamble transmissions, but probably won't work
> > as
> > well for packetized wake-up transmissions as is implemented for the
> > CC2420.
> >
> > The CCxx00 stack was tested for WoR reliability and efficiency by
> > setting up
> > a small network of 4 nodes, each with a unique address (3, 2, 1, and 0).
> > Each node's LEDs were connected to a logic analyzer, allowing me to see
> > when
> > a node was transmitting, receiving, and sending an acknowledgment.
> >  Nodes
> > performed unicast transmissions: #3 transmitted to #2, #2 to #1, #1 to
> > 0,
> > and 0 acted like a base station receiver that didn't transmit.  This
> > setup
> > allowed me to experiment with different radio stack parameters and
> > functionality.  I could see, using the logic analyzer, that nodes
> > transmitted when they weren't supposed to (like during an acknowledgment
> > wait period) or two nodes would try to transmit simultaneously, causing
> > a
> > collision.
> > In CTP, I found it necessary to modify CtpForwardingEngine.h to set the
> > FORWARD_PACKET_TIME equal to some much larger value, like 512 or 1024,
> > to
> > avoid network congestion.  Maybe we should find a way to tie this value
> > to
> > the low power listening interval somehow.
> >
> > CTP works great. But the radio stack underneath has to be reliable under
> > that kind of network congestion.  When the CC2420 LPL implementation was
> > created, most of the tests were point-to-point tests, and very few were
> > network congestion tests.
> > Any modifications done to the CC2420 stack to improve this situation
> > should
> > be contributed back to the TinyOS baseline.
> >
> > -David
> >
> >
> > -----Original Message-----
> > From: Philip Levis [mailto:pal at cs.stanford.edu] Sent: Monday, April 28,
> > 2008 10:40 AM
> > To: Bulut ERSAVAS
> > Cc: Omprakash Gnawali; David Moss; Atakan Bodur; tinyos-help (E-mail);
> > TinyOS Development
> > Subject: Re: [Tinyos-help] Collection: Loosing Connection to a Node
> >
> >
> > On Apr 28, 2008, at 9:25 AM, Bulut ERSAVAS wrote:
> >
> > > Hi Phil & Omprakash,
> > >
> > > It appears that the LPL is to blame for the misbehavior of CTP in  our
> > > case. As Omprakash suggested, I repeated the tests by turning  off the LPL.
> > > Nodes quickly discovered routes and packet losses were  reduced
> > > dramatically.
> > >
> > > We later on retried with LPL but reduced our LPL sleep interval from
> > >  1000 ms to 125 ms. Attached you can find the logs. Node 7 is again  TelosB
> > > with debug logs. The performance is much better, however, is  not as sharp
> > > as it would be with no LPL. I would suspect that the  beacons or the acks
> > > are getting lost when the LPL is activated,  hence the poor route discovery
> > > process and the large amount of data  loss.
> > >
> > > When LPL is used, are the beacons timed for the LPL sleep interval?
> > >  For instance, we use setRxSleepInterval to set the receiving node's  sleep
> > > interval for data transmission. Is something similar done for  CTP beacons?
> > >
> > > Also, when CTP is used, ETX values are quite large. Even for a  single
> > > hop, it is about 265. You will notice ETX values as large as  700 with 3-hop
> > > routes. However, with no LPL it was usually less than  300 even for 6-hop
> > > routes. Can this be due to beacons/acks getting  lost with LPL?
> > >
> > > In summary, attached logs (4BITLE & LPL w/ 125ms interval) are much
> > >  better than the ones I sent last week (LE | 4BITLE & LPL w/ 1000ms
> > >  interval). But still, for an acceptable power consumption level, we  need
> > > to use 1000ms or larger sleep interval. So, in this case, is it  possible to
> > > improve CTP to better work with LPL? How can we assist  you in this process?
> > >
> >
> > It might be useful to move this discussion over to -devel.
> >
> > The first step for doing this was to reduce CTP's control traffic so
> >  that it can function well with LPL (early versions had high control  load).
> > We completed this work a few weeks ago, and Om has just checked  the changes
> > into CVS.
> >
> > Now that CTP has a low control load, the next step is starting testing
> >  with LPL and figuring out what's going wrong and why. From your  traces, it
> > looks like LPL has a low packet delivery success rate. We  should start
> > talking with David Moss (the LPL author) to figure out  what's going on. The
> > most useful thing you can do is take debug traces  of your networks and
> > parse them. Om has a set of tools for plotting  results from traces; he can
> > share them with you. They produce HTML  pages like this:
> >
> > http://enl.usc.edu/~om_p/net2/ctp4bitle/expt-01172008-1/<http://enl.usc.edu/%7Eom_p/net2/ctp4bitle/expt-01172008-1/>
> >
> > Phil
> >
> >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> >
> > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080429/110c5ca1/attachment-0001.htm 