[Tinyos-devel] timestamps in seriallisten/sflisten etc.

[Vlado Handziski]

On Thu, Jun 26, 2008 at 19:06, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
wrote:

>
> As far as I understand the SF protocol is like this: first there is a
> handshake phase in which the server and client advertise his version ('U '
> right now).
>
>        SF client --- connect ---> SF
>        SF client <---- 'U ' ----- SF
>        SF client ----- 'U ' ----> SF
>
> If the client version is the same the server will start sending the
> packets he receives from the mote. The format is very simple: one byte
> describes the number of bytes of the active message and then there is the
> active message (destination, source, length, group, type, data):
>
>        +------+-----------------------------------------//--+
>        | size | destination source length group type | data |
>        | (1)  |     (2)       (2)    (1)   (1)   (1) |      |
>        +------+-----------------------------------------//--+
>
> A way to add one timestamp would be to include it in front of the active
> message:
>
>        +------+-----------+-----------------------------------------//--+
>        | size | timestmap | destination source length group type | data |
>        | (1)  |    (4)    |     (2)       (2)    (1)   (1)   (1) |      |
>        +------+-----------+-----------------------------------------//--+
>
>
> > A packet will need to have a timestamp field. Does it have a chain of
> > timestamps from each hop, or a single one? Each packet source would need
> to
> > be able to overwrite(single)/add(chain) a timestamp. If the former,
> probably
> > the best way would be to have an option on packet sources as to whether
> they
> > overwrite the timestamp. I.e., in the case above, SF-a's packet source of
> > serial@ has the overwrite option set.
>
> I think overwriting would throw out very valuable information while
> maintaining a chain could lead to complication like finding who was on the
> path. The most useful (and also simple solution) is to let the serial
> forwarder directly connected to the mote add the timestamp while all the
> others will only forward it.
>

I think we should keep the SF packet format as is and encapsulate the
addition of the time stamp filed inside a new serial frame format called
"timestamped AM" or similar.  We currently have two serial frame formats:
one for AM messages and the other for transparent forwarding of 15.4 frames.
The SF anyhow should be a generic forwarder of serial packets, and not just
of serial AM packets. Existing SF clients will have to add one additional
level of dispatch based on the serial protocol ID and not only skip this
field knowing that the content is always a serial AM.

One way to use the field can be as follows. The original handshake between
the SF and the mote can be extended to enable estimation of the RTT over the
serial line. For each "timestamped AM" packet, the mote then inserts a stamp
based on the local time and sends this over the serial to the SF. On the
receive side, the SF translates this into host time using the RTT estimate.
And from now on, the timestamp is not modified, just forwarded, transparent
for the SF client-server protocols. Upon receiving a "timestamped AM"
packet, the client would know to extract the timestamp from the rest of the
AM packet.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080626/f5d0dbe3/attachment.htm