[Tinyos Core WG] TKN15.4

[Jan Hauer]

Ideally the platform glue code is only a header file that defines some
guard times and a configuration that wires the MAC to Alarms/Timers
and the radio stack. This configuration is similar to ActiveMessageC,
its name is fixed and it does not itself use any interfaces, so
platform-independent code/apps can sit on top of it. However, this
assumes that the chips that are part of the platform already provide
Alarms/Timers with symbol precision (62.500 Hz for the RF230) and that
the radio stack provides the radio interfaces that are required by the
MAC. The main effort will be to extend/modify the respective chip
abstractions to provide these interfaces (I've done it for the msp430
and CC2420 stack); the Alarm/Timer interfaces are standard T2
interfaces with 62.5Khz precision and the radio interfaces are aync
Tx/Rx/Off interfaces that separate between a preparation state (to
load the packet into the radio) and the scheduled transmission of the
frame.

The code is not yet available (the implementation is not 100%
complete, I need to comment the code/interfaces/test apps, etc), but
if we agree to the proposed directory structure I can upload it next
week, or probably the week after. The directory structure we came up
with in the conference call was:

+ the platform-independet MAC implementation/interfaces go into
tos/lib/mac/tkn154/
+ the platform-specific glue code goes into tos/platforms/<platform>/mac/tkn154/
+ test apps go into apps/tests/tkn154
+ the modified CC2420 radio driver would go into tos/chips/cc2420/tkn154

Jan


> How much glue code is necessary? I would like to take a look if the
> RF230 could be supported, and actually try to do it. That would be the
> real test whether it is platform independent. Where can I take a look?
> Is the "glue" documented?
>
> Miklos
>
> On Wed, May 21, 2008 at 4:56 PM, Jan Hauer <jan.hauer at gmail.com> wrote:
>> As discussed in the last conference call, here is an update on our
>> 802.15.4 implementation, on how the code is structured and how it
>> could be integrated into the T2 core.
>>
>> The main part is a platform-independent 802.15.4-2006 MAC
>> implementation, structured into a set of about 20 components (a total
>> of 5k lines of code), providing the standard 15.4 interfaces slightly
>> adapted to the T2 design philosophy (e.g. using message_t and buffer
>> swapping). The implementation currently includes the beacon-enabled
>> mode (I'm working on the non-beacon-enabled mode) and almost all of
>> the functionality described in the standard, except GTS and security.
>> I have developed it on telosb and plan to port it to tossim soon.
>>
>> The MAC has some requirements (uses a set of interfaces) that I found
>> "problematic" to implement with the current T2 codebase, at least on
>> the telosb platform which I used for development: it requires
>> Alarm/Timer interfaces with a precision of a 15.4 symbol (62.500Hz in
>> the 2.4 GHz band) and it requires radio interfaces that allow to
>> precisely control when a packet is transmitted. These requirements are
>> caused by the fact that the 15.4 standard expresses backoffs in symbol
>> times and in the slotted CSMA-CA (beacon-enabled mode) packets must be
>> sent exactly on backoff boundaries defined through the previous
>> beacon. For telosb we have developed a small 62.5Khz timer-board that
>> can be attached to the telosb expansion header, but I have not yet
>> checked whether other T2 platforms might be able to generate 62.5Khz
>> Alarms (+-40ppm accuracy) without additional hardware. As for the
>> radio interfaces: basically these are async interfaces for Tx/Rx/Off,
>> where the Tx interface allows to specify the absolute time (t0+dt)
>> when the packet is to be transmitted.
>>
>> Ideally a radio driver providing these Tx/Rx/Off interfaces to the
>> 15.4 MAC should just be a wrapper that sits on top of an existing T2
>> radio stack. For the CC2420, however, I had to slightly modify the
>> current CC2420 radio stack/interfaces to achieve the necessary timing
>> - maybe a future radio TEP could define interfaces (or guidelines) for
>> structuring radio stacks, so that implementation of
>> platform-independent MACs can be made easier and we can avoid code
>> duplication.
>>
>> Finally, in order to use the MAC there needs to be some
>> platform-specific glue code (a configuration) to wire the MAC
>> implementation to the particular radio driver and to the Alarm/Timer
>> interfaces (and also to define some constants like guard times, etc.).
>>
>> I have successfully done some basic interoperability tests of our 15.4
>> implementation (we call it "TKN15.4") running on a telosb with TIMAC
>> running on a CC2430DB (TIMAC is a commercial 15.4 implementation by
>> Texas Instruments). It will probably take me another 2 weeks to finish
>> the implementation/tossim port and perform some more evaluation;
>> meanwhile I plan to write a TEP on TKN15.4.
>>
>> However, I think we have not yet established rules on how a
>> platform-independent MAC would be put into T2 core. I would suggest
>> the following:
>>
>> + the platform-independet MAC implementation/interfaces go into
>> tos/lib/mac/tkn154/
>> + the platform-specific glue code goes into tos/platforms/<platform>/tkn154/
>> + test apps go into apps/tests/tkn154
>> + I'm not sure, however, where the modified CC2420 radio driver would go...
>>
>> Jan
>> _______________________________________________
>> Tinyos-2.0wg mailing list
>> Tinyos-2.0wg at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>>
>