Hi David,

Thanks for your help and report.
In my opinion to improve the reliability you should concentrate on resend
messages. The major problem, i think, is because you are not resending the
messages with CCA. I think you should use resend with CCA by default and
only use resend without CCA if the message was not ack but the CCA check was
passed true. If you put the resend with CCA, even better if with "advanced
CCA", I think you will notice large improvements on Average Packets Dropped
but a significant reduce too on Average Packets Received. Maybe that will be
the price for increasing reliability.

Thanks for your elucidation.

Miguel Pereira


On 12/11/06, David Moss <[EMAIL PROTECTED]> wrote:

*> Suppose that I have 2 motes sending messages. Mote one send one message
with preamble, and the second mote start sending message on top of mote 1.
The result is that the 2 messages are corrupted. I was looking in the code
and it seems that on file CC2420LowPowerListeningP.nc you send one message
(task send) with CCA and then resend (task resend) with no CCA. The problem
is that call SubSend.send(currentSendMsg, currentSendLen) (line 447)
return SUCESS even if call CC2420Transmit.sendCCA( m_msg ) (file
CC2420CsmaP.nc) return FALSE. The consequence is that the resend doesn't
use CCA.
*
Hi Miguel -

I have done some testing with multiple transmitters to a single receiver.
The test setup involved 1 Rx mote with a 1000 ms sleep interval, and 3 Tx
motes transmitting full 28 byte payloads to the Rx mote. After each sendDone
event, the Tx motes would wait 500 ms before attempting the next send.

With the CC2420 stack as it is right now, it samples the channel at least
one time before sending a packet.  This is bad, as you've pointed out:  the
Tx mote could be sampling in a quiet acknowledgement gap of another
transmitter, and get a clear-to-send without the channel really being
clear.  Two+ motes will transmit simultaneously and most likely cause
collisions.  We'll call this method the "default CCA" method.

I made some modifications to the clear channel assessment in
CC2420TransmitP that allows the mote to sample the channel many times before
determining that the channel is clear.  If at any point during the
assessment it finds the channel is not clear, it sets the backoff timer and
tries the whole advanced CCA check from the beginning after the backoff
timer fires.  This way, there's less probability that two motes will be
transmitting at the same time.  We'll call this method the "advanced CCA"
method.

Here are my results for two 3-minute runs using telosb's:

Default method
  Average Packets Received:  104.3
  Average Packets Dropped: 17

Advanced CCA method
  Average Packets Received:  101.3
  Average Packets Dropped: 19.6


Now, it could be that three minutes is not long enough to give a good
sample - but the results here show that the default method is actually more
reliable than the advanced CCA method.  Kind of counter-intuitive - motes
sending messages on the same channel simultaneously actually produces better
results than longer CCA checks.  The advanced CCA check method actually
seemed to make some motes hog the channel as well. It also seems to decrease
throughput.   Looking at the packets dropped, it could be that some motes
are still transmitting simultaneously (but visually looking at the Led's
shows this is not true most of the time)

We're still seeing a little less than 20% packet loss with multiple
transmitters, which is bad.  I'd like to continue by testing the impact of
adding in CCA checks on each send, instead of resending without CCA.  Maybe
this will make the receive check period too long, which would also be bad.
Maybe it will increase reliability.  The only way to tell is to implement it
and try it out.

If anybody wants to test out other methods, I'd love to hear your results.

Thanks,
-David



_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to