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

[Roman Lim]

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/
> 
> Phil
> 
> 
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel