[Tinyos-devel] [Tinyos-help] Collection: Loosing Connection to a Node
Roman Lim
rlim at ee.ethz.ch
Tue Apr 29 03:48:09 PDT 2008
Bulut, you can actually find this radio stack in the t2 contrib directory:
tinyos-2.x-contrib/ethz/snpk/tos/chips/cc2420/
Roman
Bulut ERSAVAS wrote:
> 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
> <mailto: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
> <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
> <mailto:Tinyos-devel at millennium.berkeley.edu>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
>
>
More information about the Tinyos-devel
mailing list