[Tinyos Core WG] CC1000 Header

[Philip Levis]

On Jan 17, 2007, at 11:19 AM, David Moss wrote:

> David -
>
> In the meeting this morning I brought up a concern about the CC1000  
> header not containing a DSN byte like the 802.15.4 CC2420 packets.   
> I'd like to get your input on this to see if this is something we  
> can include in the CC1000 stack.
>
> The argument for having a DSN byte in the CC1000 packet header is  
> we can more easily detect and reject duplicate packets.  This is  
> especially important for the version of low power listening that  
> sends shorter packets redundantly from within the radio stack.  As  
> you know, the transmitter in this low power listening  
> implementation is able to quit early by detecting an ack from a  
> receiver; however, the receive needs some kind of filter to reject  
> duplicate packets coming from the transmitter.  Another instance  
> where the DSN byte is useful is when a message transport layer  
> retransmits a single packet from within the radio stack for some  
> duration of time, attempting a reliable delivery.  Set the DSN byte  
> on transmit at the top of the stack, check it on receive at the  
> bottom.
>
> One of the questions that arises as part of adding a DSN byte to  
> the packet header is how should the AMPacket interface be modified  
> to access this byte?  And, should the equivalent functionality that  
> a DSN byte provides be a requirement for all radios in TinyOS?
>
> It's possible that this update should happen as part of a  
> cc1000_lpl asynchronous/synchronous lpl stack release like I have  
> access to locally, but it's good to start thinking about it now for  
> compatibility.

My thought is that AM shouldn't include the byte. I can imagine data  
link protocols where having a sequence number is of zero use, and so  
it would just be wasted space.

Note that having a sequence number will not completely remove the  
possibility of duplicate packets, unless you have unbounded state.  
That being said, reducing its frequency is good.

Phil