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:[EMAIL PROTECTED] 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-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
