[Tinyos-devel] net2 goals/timeline for 2.1.1

Stephen Dawson-Haggerty stevedh at eecs.berkeley.edu
Fri Jun 12 12:49:48 PDT 2009


I think that Phil's suggestion works; we would need the corresponding
send-side interface as well.

Steve

On Fri, Jun 12, 2009 at 12:47 PM, Philip Levis<pal at cs.stanford.edu> wrote:
>
> On Jun 12, 2009, at 12:08 PM, Stephen Dawson-Haggerty wrote:
>
>> The major issue for core is the frame format.  The 6lowpan standard
>> when used over 802.15.4 requires the 6lowpan payload to start
>> immediately following the 802.15.4 frame header; the first byte is an
>> IANA assigned dispatch value.
>>
>> This dispatch value is the same as the "network" field when I-frames
>> are enabled, and so it is possible to have a radio stack which
>> supports both Active Messages and other network protocols.  This is
>> pretty much the same as the dispatching of packets base on the
>> ethernet header in other systems-- IP and non-IP protocols can
>> coexist.
>>
>> Conceptually, the layering would be (for AM)
>> --------------------------
>> | 802.15.4 | network (6LOWPAN_NALP) | AM  | ...
>> --------------------------
>>
>> What is needed is an interface to intercept the non-NALP network
>> values and feed them into blip, and an interface to allow blip to send
>> packets with its own (arbitrary) network ids.
>
> Well, as I said, it's important to remain radio-chip independent. We want to
> think about blip working on all kinds of link layers, not just 802.15.4. So
> while we definitely have to handle that case, the solution should not be
> constrained to that case.
>
> Would it make sense for <RadioChip>ActiveMessageP to have
>
> provides interface Receive as NotAMReceive;
>
> then have a MessageC which exports this?
>
> My one major concern is detecting at compile-time whether you're expecting
> non-AM packets but the link layer doesn't support them. I suppose this could
> be handled by whether the above interface exists.
>
> Phil
>



More information about the Tinyos-devel mailing list