[Tinyos-devel] packet level time synchronization TEP

Tue Nov 18 18:43:10 PST 2008

Hi Janos, Miklos:

First, thank you very much for putting the time into getting FTSP into the
T2 tree.  I've made great use of FTSP in every platform that I've worked on
and am really excited to see it finally make its way into the distribution
tree.  Great work.

Second, the TEP looks fine.  The comments below are specific to the CC2420
implementation.  Anyone who isn't deeply interested in the CC2420 stack
implementation should feel free to let their eyes glaze over at this
point...

I did some hacking recently in order to try and get FTSP to work in the
presence of LPL.  My work was done for the TMote, so I was mucking around in
the CC2420 stack, and I did have a few issues with the implementation I
found there.  I realize that it's not the reference implementation, but the
higher-order bit is that I'm not convinced that embedding this (all of this)
functionality into the radio stack itself is the right approach.

According to the TEP implementation requires hooks notifying you when a)
when the packet is injected into the stack (i.e., when Send.send() is
called), b) when the packet is about to be transmitted (in either the
mutable or immutable case) and c) a way to associate an event timestamp with
the message.  Currently, in the CC2420 stack implementation:

(a and c) are provided through a separate send target,
CC2420TimeSyncMessage[C,P], which differs only slightly from the original
CC2420ActiveMessage[C,P] (by a few lines).

(b) is embedded in the low-level transmit logic.

Obviously embedding these things in each stack has the disadvantage that you
have to maintain several different implementations, one per stack.  And at
least the (a and c) changes above aren't really necessary.  You could
achieve the same effect in a slightly prettier way without duplicating
CC2420ActiveMessage[C,P].

Instead, provide a common (across all stacks) packet-level timestamping Send
interface which accepts a timestamp as parameter, writes it into the right
spot in the packet, modifies the length and then sends it on its way through
the already standardized Send.send() interface which could point to any
radio stack.

The second question is how to get the metadata set up right so that the
transmit event handler knows to rewrite the timestamp. This is also a bit
tricky, since what you have right now is fairly unintuitive:

<code CC2420TimeSyncMessageP.nc:96>
        err = call SubSend.send[id](addr, msg, len +
sizeof(timesync_radio_t));
        call PacketTimeSyncOffset.set(msg);
</code>

Besides just being a bit hard to wrap your head around at first glance ;-),
this also fails in the presence of LPL.  This took me a while to figure out,
but the assumption that this makes is that the SubSend.send() call makes its
way all the way through to CC2420CsmaC.send(), which initializes the
metadata (setting metadata->timesync = FALSE and metadata->timestamp =
INVALID_TIMESTAMP). Then the call below it to PacketTimeSyncOffset.set()
rewrites these fields and all is good...

...except if you are using LPL, because DefaultLPLP.nc (which sits above
CsmaP.nc) does not pass the SubSend.send() call through synchronously!  It
posts a task, meaning that the metadata values you set in the call to
PacketTimeSyncOffset.set() get overwritten by CsmaP.nc and the offset never
gets subtracted in the transmit handler.  Doh.

My suggestion here to move the metadata initialization in CsmaP.nc higher in
the stack, above SendNotifier.nc, and then handle setting this property in a
SendNotifier listener in the generic packet level timestamping code.  David
or Phil can correct me if I'm wrong, but I think that the metadata values
could really be initalized higher in the SubSend chain and this might be
useful in a variety of different contexts.

Finally, to get really LPL specific, the computation you do in the Transmit
handler where you subtract off the current time fails in the presence of LPL
since the message is broadcast and will probably be transmitted multiple
times (to ensure the receiver hears it once), meaning that after one
transmission eventtime - currenttime becomes eventtime - currenttime_1 -
currenttime_2 ... which is pretty much useless.  My suggestion is rather
than do this computation in place you either a) put the event time in the
metadata and then load metadata->eventtime - currenttime into the extra
field or b) pad the packet with another copy of the event time that doesn't
get overwritten every time the packet gets sent.

Anyway, to try and climb up to slightly higher-order bits, I was able to
implement all of the current packet level timestamping logic with LPL and
alongside the original CC2420 radio stack by performing the following
modifications:

a) moving metadata initailization higher so that SendNotifier can mark the
message for timestamping (and change the size)
b) providing a aboutToTransmit() interface which provides an event in the
SFD.captured() handler. This isn't all that beautiful though and I think
that *that* portion of the functionality might be best left inside the
stack.

OK, phew, I hope that this helps out the implementers. In general I think
that this is good case study in terms of trying to implement a service
necessitating fairly close interaction with the radio stack. I would
probably lean towards trying to modify the radio stack in order to provide
the needed hooks since they might be useful to other services with similar
requirements.  I have no idea, however, how possible these hooks are on
non-CC2420 radios.

Best,

-gwa-

geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner

On Wed, Nov 12, 2008 at 5:48 PM, Janos Sallai <sallai at isis.vanderbilt.edu>wrote:

> TEP 133 on packet level time synchronization has been out for a while, and
> this functionality has been implemented for most platforms by now. Before
> submitting this TEP for community review, I would like to solicit comments
> from users and platform owners about the interfaces the TEP describes.
>
> Just to recap, the TEP describes two interfaces, parameterized by timestamp
> precision and width:
> - TimeSyncAMSend, a variant of AMSend that allows for attaching a timestamp
> (in the local clock of the sender) to the message
> - TimeSyncPacket, which allows for reading the timestamp by the receiver of
> the message (in the local clock of the receiver)
>
> The conversion of the timestap from the transmitter's local clock to the
> receiver's local clock is done within the radio stack, and is hidden from
> the users.
>
> The TEP is available at
>
> http://tinyos.cvs.sourceforge.net/viewvc/*checkout*/tinyos/tinyos-2.x/doc/txt/tep133.txt?revision=1.1
>
> Thanks,
> Janos
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081118/58bb51ce/attachment.htm 