Hi Phil -
The way LPL works is through continuous retransmissions of
a message for the duration of a receive check period.
These retransmissions are invisible to the application
layer - so from the app layer, it looks like you send a
single message and get a single sendDone back. LPL
doesn't guarantee reliability - that would be up to a
higher layer like you pointed out, like a collection
library or a message transport layer.
If the collection library attempts to send to a LPL
receiver, the LPL layer itself will cause the message to
be rebroadcasted continuously for at least the full
duration of the receiver's receive check, so the duty
cycling receiver can hear it. If the duty cycling
receiver doesn't get the message, the higher layers like
collection would know this by using
PacketAcknowledgements, and be able to choose a different
destination immediately.
-David
On Tue, 12 Dec 2006 10:13:20 -0800
Philip Levis <[EMAIL PROTECTED]> wrote:
On Dec 12, 2006, at 2:53 AM, Miguel Pereira wrote:
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.
I believe pretty strongly that the MAC layer should not
specify a retransmission policy for reliability. That
should be up to the network layer. E.g., if you look at
CTP (the T2 collection protocol), it might choose a new
destination after as little as 1 unacknowledged packet.
Not considering collisions, we've collected pretty good
data suggesting that instantaneous link quality is for
the most part bimodal[1]: losses can be highly
correlated.
Phil
[1] http://sing.stanford.edu/pubs/ip-hotnetsV.pdf
_______________________________________________
Tinyos-help mailing list
Tinyos-help@Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
