[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

First, about multiple components using multiple networks
simultaneously-- you know, I'm not sure.  On one hand, it could be
nice, but on the other hand I think it may be overkill for 2.1.1 since
I haven't heard anybody ask for it, and other then 6lowpan and AM
there aren't any other standards I'm aware of who would want this.
Also, it would be simple enough to add a dispatching layer on top of
Ieee154C if someone felt it was necessary.  Since 6lowpan uses a lot
of network ids, it's going to increase complexity in the stack, for no
great reason that I can see.

Okay, let me play back what we have.  Thanks, Miklos, I think this has
been very helpful.

At a high level, our goal is to support "dual stack" motes-- motes
running both AM-based protocols and 6lowpan/IP protocols.  This means
dispatching packets differently based on a "network" byte, which
immediately follows the 802.15.4 header.  The wire formats are already
there, since IFRAMES contain the 6lowpan "network" byte; however, we
need a consistent interface to send and receive non-AM packets.
Furthermore, this support is to be considered only a waypoint present
in 2.1.1; once a full 802.15.4 stack is available, it can be
eliminated.

We introduce a new hardware independent component Ieee154C analogous
to ActiveMessageC, providing:
 Ieee154Send;
 Receive as Ieee154Receive
 Resource as SendResource;
 Ieee154Packet;
 Packet;
 PacketLink;
 PacketAcknowledgements;
 LowPowerListening; (?)
 PacketLinkMetadata; (?)

Also we introduce a new frame type, IEEE154FRAMES, which, when enabled
(#define IEEE154FRAMES_ENABLED), disables support for AM frames.

The payload of these interfaces is to refer to the first byte after
the 802.15.4 header-- the "network" byte in an IFRAME.

Addressing remains 16-bit short id only.

In order to correctly dispatch AM packets, radio stacks with IFRAMES
enabled must snoop on the payload-- if the first byte is
"TINYOS_6LOWPAN_NETWORK_ID", the packet must be dispatched to the AM
stack.  Otherwise, it is dispatched through the above interfaces.  The
AM interface semantics and offsets do not change, and when IFRAMES or
TFRAMES are enabled, the AM payload is aligned on (message_t).data.
(This means the Ieee154 payload _isn't_ aligned there).

In order to arbitrate access between the two stacks, Ieee154 senders
must acquire SendResource before sending a packet.  Internally, the AM
stack must also acquire this resource before sending, but it is not
exposed to upper layers to preserve existing conventions.  [ SDH: not
exposing the resource is also fine with me.  as is exposing it to both
AM and Ieee154].


On Thu, Jul 2, 2009 at 8:56 AM, Philip Levis<pal at cs.stanford.edu> wrote:
>
> On Jul 2, 2009, at 12:56 AM, Miklos Maroti wrote:
>
>> Hi Stephen,
>>
>>> Miklos, the more I think about it the more I like your first option
>>> where there is only a single Send/Receive interface and we pick out AM
>>> packets by peeking.
>>
>> That is fine for me. You are the one who know what to do inside the
>> 6lowpan implementation and I can well imagine that it is better to
>> keep the packet with the network id. By the way, this is why I have
>> asked if you anticipated other clients than AM and your 6lowpan.
>> Eventually you might want to share more clients by the network id, so
>> at that point you need to further dispatch by the network id. Either
>> way, I see that this option (simply removing the AM layer from the
>> picture by peeking the network id) makes everyone happy in the short
>> term.
>
> Just to reiterate core's requirement: AM layers must have their data payload
> at a uniform offset within a message_t. In this case, "payload" means the
> pointer returned by Packet.getPayload() at the AM layer. Exactly how
> pointers are exposed below this, within the stack, isn't that big a deal.
>
> That being said, since this discussion is pretty strongly in core territory,
> what I'd recommend is coming up a concrete proposal (sounds like you've
> almost reached consensus), then I can forward it to core. A clear statement
> of the problem you're trying to solve (not everyone in core might know it)
> and a good articulation why you reached the particular solution you did will
> make it go a lot faster/easier.
>
> Phil
>