On each receive check, the receiver samples the channel multiple times.  It
must sample multiple times, simply for the case you brought up: sampling
during the (ack + backoff) period would result in a no-detect if too few
samples were taken.

In the 2.x LPL implementation, when the receiver does wake up in the middle
of the (ack + backoff) period, it will sample enough times to detect the
start of the next packet's transmission.  When it sees the transmission, it
will remain on to receive that same packet in full.  In very few cases, the
receiver starts sampling right at the start of the ack period, and turns off
before the end of the backoff period.  That's why it makes sense for the
transmitter to transmit for twice the receive check period - picking up
these edge cases.

The CCA check is still shorter than leaving the radio on to receive a full
packet no matter which way you cut it.  The (ack + backoff) gap is
significantly shorter than the (backoff + packet transmission + ack) period
(times two, because in order to guarantee reception of a single packet you
have to have your radio on for twice that time).  

Detecting the presence of raw transmitted data will always be shorter than
detecting a single uncorrupted packet, no matter what fancy packet tricks
are performed.

-David



-----Original Message-----
From: Jiakang Lu [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 13, 2007 11:39 AM
To: David Moss
Subject: Re: CC2420_LPL module on Tinyos-1.x?

Hi David,

One more question about CCA check strategy. What if the node is awake 
and does the CCA check between two packets in the packet train? The CCA 
will show there is nothing on the channel and the node will go back to 
sleep immediately. In this case, the node will miss the chance to wake 
up and receive the message. If you let the node to do the CCA check long 
enough to cover the gap between two packets,  I cannot see any 
difference than packet reception check. Is my understanding right?

Thanks.

Best,
Jiakang
> The fact is, a CCA check can wake up, see nothing interesting, and go back
> to sleep faster than waking up and sitting on long enough to receive a
full
> packet.  In the case that there are no packets (which in many cases may be
> the majority of the lifetime of a mote) the CCA check will always save
more
> energy than a full packet reception check.
>
> In the case where there are packets flying around, a CCA check can still
> detect that something interesting is happening faster than a full packet
> reception check like XMAC.  In that case, it decides to stay on longer -
as
> long as a full packet reception check - to receive that packet and decide
if
> the packet is useful or not.  If the packet isn't useful, then it goes
back
> to sleep anyway.
>
> "[CCA] ... is not able to differentiate a transmitter without picking up a
> full packet"  - but keep in mind that the way to do it without CCA is to
> always pick up full packets, even when there are no full packets to
receive,
> which wastes lots of energy idly sitting there with the radio on.  In all
> cases - packet reception checks and CCA checks - you have to receive a
full
> packet to differentiate a transmitter.  Full packet reception is really
the
> strategy that suffers "false positives" 100% of the time, because it
always
> wakes up to receive packets even when nothing's there.
>
> I guess another way of putting it is this: a modulated channel is lower in
> hierarchy than packet transmission.  You can sample the channel to see if
> it's modulated instantaneously.  To see if a full packet is being
> transmitted, you have to remain on for a very long time.  Detecting a
> modulated channel with valid 802.15.4 data is more fundamental than
> detecting a full blown 802.15.4 packet.  Plus, in order to detect that
> packet, there has to be little interference at the time so it gets through
> uncorrupted - something that can't be said about only checking for a
> modulated channel.
>
>   



_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to