[Tinyos-devel] PacketLink interface, CC2420 impl, problems with Broadcast packets TinyOS 2.0.2.2

[Avinash Sridharan]

Since in TinyOS 2.0.2.2 the default are software ACKS, and there is an
address checking in the receive code before initiating an ACK, thus
broadcast packets are never ACKed.

But if you look at the PacketLinkP.nc implementation of the PacketLink
interface in the link module of CC2420, it simply makes a call the
PacketAcknowledge interface was checking if a packet was Acked or not. The
PacketAcknowledge interface implemented in CC2420PacketC.nc simply returns
the ACK field of the meta data which would be false for Broadcast packet.
But then this would make the PacketLinkP.nc to resend these packets (since
PacketLinkP, does not have a destination check) for the maximum number of
retries. Thus the anomaly.

If the PacketAcknowledge interface returns TRUE for broadcast packets, the
PacketLinkP.nc would never retransmit broadcast packets.

regards,
Avinash

On 9/6/07, Razvan Musaloiu-E. <razvanm at cs.jhu.edu> wrote:
>
> Hi!
>
> On Thu, 6 Sep 2007, J. Ryan Stinnett wrote:
>
> > Avinash -
> >
> > Broadcast packets are not ACKed at all.
>
> If a broadcast packet has the 'Acknowledge request' set then it will be
> acked by the CC2420 chip.
>
> --
> Razvan ME
>
> > If I understand correctly, you are checking in the sendDone event
> > whether or not the packet was ACKed, and retrying if it was not,
> > correct?  This check should not be performed on broadcast packets since
> > ACKs are never sent for them.
> >
> > - Ryan
> >
> > Avinash Sridharan wrote:
> >> Hi All,
> >>  I am not sure if this is the right forum to send this mail, or should
> I be
> >> sending it to the TinyOS-help mailing list.
> >>
> >> I was using the the PacketLink interface on the Tmote Sky's with the
> CC2420
> >> stack. In my code I have broadcast beacons that are send out at
> periodic
> >> intervals. When I started using the PacketLink interface I started
> seeing a
> >> considerable drop in my throughput (this is observed using logs from
> the
> >> mote).
> >>
> >> I added some code to see the number of retransmission attempts for each
> >> packet being sent out. In my test case I had a fully connected network
> >> (with all links having a PRR of ~ 1). Ideally I should be seeing all
> >> packets being ACKED and the number the sent attempts on packets being
> 1.
> >> This was the case for the packets that were being unicasted however for
> the
> >> broadcast packets the transmission attempts were always the maximum
> number
> >> of retries and they were never ACKED (this was true for all broadcast
> >> packets).
> >>
> >> On digging a bit deeper I realised that the CC2420PacketC (which
> provides
> >> the PacketAcknowledgement interface) does not check for the destination
> >> address and simply returns the ACK field in the metadata. Once I added
> a
> >> condition for the checking the broadcast address (and always returning
> true
> >> for BROADCAST), performance returned to normal.
> >>
> >> Is this a valid bug ? Is the fix correct, or should this condition be
> >> handled at some other point ?
> >>
> >> regards,
> >> Avinash
> >>
> >>
> >> --
> >> Phd Dept. of Electrical Engineering
> >> University of Southern California
> >> http://www-scf.usc.edu/~asridhar
> >>
> >>
> >
>



-- 
Phd Dept. of Electrical Engineering
University of Southern California
http://www-scf.usc.edu/~asridhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20070906/13a3b75f/attachment.htm