Hi Jongkeun -
Good observation. Sending an RTS / CTS to stop transmissions from other nodes is a good idea. I have two initial concerns about this approach, but maybe it should be studied a little more to confirm or deny these: 1) I'm concerned about the dependency on the link-layer to prevent phy-layer collisions, especially when we're dealing with such low power and somewhat long transmission distances that cause packets to be easily corrupted. 2) I'm concerned about the excess transmissions taking place to get a single packet through, and the impact on reliability and energy savings. 802.11's virtual sensing approach, from what I understand, works well especially because the transmission rates are high and the transmitters have access to mains power. In this case, getting a single packet through with an RTS / CTS requires at least 3 packets to be exchanged: RTS / CTS / Data. Transmissions are typically the largest energy consumer of any operation on the node. If one of those packets gets dropped, it will have to be retransmitted. Other nodes will also have to back off somehow to prevent collision if they miss the CTS packet, which brings us back down to PHY-layer collision avoidance. If you don't want to rely on the radio hardware to prevent collisions (and save energy by leaving the radio off), I think you'd be talking more about a TDMA solution. This is totally possible, but requires accurate clock management and synchronization between nodes. The RF230 implementation is pioneering some really nice synchronization protocols that would make something like that more possible, at least across homogeneous platforms. -David _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Monday, June 02, 2008 9:29 PM To: David Moss Cc: [email protected] Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening It sounds like a sort of virtual carrier sensing. How about introducing a thing like NAV of 802.11 for a packetized wake-up transmission as a general approach? do you think it is worth to introduce such a virutal carrier sensing mechansim for LPL based sensor networks? if so, is it possible to implement it without an aid of radio H/W? Thanks, Jongkeun On Fri, May 30, 2008 at 9:17 AM, David Moss <[EMAIL PROTECTED]> wrote: Yes, in fact, this is what I'm implementing on the CC1100 and CC2500 radio stacks. The trick is getting the transmit branch of the radio stack to hold off for awhile if a packet was recently received. This allows one node to completely dominate the channel while it sends back-to-back packets with acknowledgment gaps in between. Packet delivery and acknowledgment success rate goes up, collisions go down, and energy efficiency goes way up. So far, this seems to work very reliable on my desk. I have yet to test it outside or in a real network, where any number of issues may come into play. -David _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Thursday, May 29, 2008 7:24 PM To: David Moss Cc: [email protected] Subject: Re: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening Thank you David for your detailed explanation. I fully agree with you regarding safety and robustness for applications. One more question, looking at the initial backoff (0x4) and congestion backoff (0x3) applied in the packetized wake-up transmission, I'm wondering there is any theory in choosing those backoff constants. What's the backoff strategy? intentionally to allow multiple wake-up transmissions mixed at the same time. What if we allows only one wake-up transmission at a time in medium by treating separately the first packet and the following resended packets in the packet train, i.e. the standard backoff is applied for the first packet and almost 0 backoff is used for the resended packets. Do you have any history or experience? Thanks, Jongkeun On Thu, May 29, 2008 at 8:54 AM, David Moss <[EMAIL PROTECTED]> wrote: Hi Jongkeun, The DELAY_AFTER_RECEIVE is not the length of a CCA receive check. The receive check is currently implemented through polling the CCA pin a number of times in PowerCycleP. This polling method will be transformed into an alarm/interrupt receive check for greater accuracy and efficiency, as soon as someone has time to do it. The goal of the receive check is to be as short as possible, and is the length of the time between packets in a packetized wake up transmission strategy. I've had these receive check perform reliably at 5 ms or less, but the current implementation makes the receive check last ~11 ms for reliability across everyone's systems and platforms. Only after activity is detected - either by transmitting a packet or receiving a packet - does the radio remain on for the time defined by DELAY_AFTER_RECEIVE, which is currently 100 ms. You'll notice the DELAY_AFTER_RECEIVE is #ifdef'd, so you can override it. I agree, 50 ms - or even 20 ms - is a better value for leaving the radio on after activity. The 100 ms value was chosen because highly congested networks need further optimization with the packetized wake up transmission in the default low power communication implementation. In fact, we need to connect a bunch of nodes to a logic analyzer to 1) improve acknowledgment success rate, 2) decrease packet collisions, and 3) optimize these timing values before it will make sense to decrease that value for the entire community. Right now the emphasis is on safety and robustness on everyone's applications. Once the items above are solved, we should be able to safely improve energy consumption while maintaining this level of robustness. -David _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jongkeun Na Sent: Wednesday, May 28, 2008 4:02 PM To: David Moss; [email protected] Subject: DELAY_AFTER_RECEIVE in CC2420 Low Power Listening Hi David, I have a question about a parameter used in CC2420 LPL module. * DELAY_AFTER_RECEIVE=100ms defined in DefaultLpl.h This value is used to stretch the radio's ON time after receiving or sending a packet, and also detecting some CCAs at check time. I think that the cca detection related delay time should be seperated with the first two cases (after sending/receiving). If CCA detection is a false positive meaning that no packet is being transmitted to node, keeping radio ON during 100ms is too wasteful when we use a short check interval such as 100ms. Even though we use a shorter delay time such as 50ms, according to my experiment, there is no problem because radio is supposed to receive a packet after detecting CCAs, otherwise the radio should be OFF right after waiting an expected time for packet reception. I do not feel 100ms should be sticked for this case, a shorter delay would be fine if it is enough to guarrantee the packet reception at valid CCA detection. Am I missing something? Thanks, -- Jongkeun -- Jongkeun -- Jongkeun
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
