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:* tinyos-help@millennium.berkeley.edu > *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; tinyos-help@millennium.berkeley.edu > *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 Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help