[net2-wg] Fwd: Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

---------- Forwarded message ----------
From: Miklos Maroti <mmaroti at math.u-szeged.hu>
Date: Thu, Jul 2, 2009 at 12:40 PM
Subject: Re: [net2-wg] Incremental Radio Interface Update for 2.1.1
To: Stephen Dawson-Haggerty <stevedh at eecs.berkeley.edu>
Cc: Philip Levis <pal at cs.stanford.edu>, net2-wg
<net2-wg at millennium.berkeley.edu>, David Moss <dmm at rincon.com>


Guys,

I completely agree with what Stephen wrote. A few comments:

- The sendDone() event is dispatched similarly to the receive() event,
so only the one who called send() will get it.

- The SendResource will be shared by all clients of ActiveMessageC and
Ieee154C. AMSenderC will be updated to use that. Any other client of
ActiveMessageC that does not use AMSenderC (e.g. FTSP or
TimeSyncMessageC clients) will have to call it directly. This is a
great bonus as it does not require all radio clients to pass through
AMSenderC.

- Maybe we should name Ieee154C as Ieee154MessageC (that is the way I
have named the RF230 IEEE 802154 component and this is what Lars
Schor's BLIP port to the RF2xx chip relies on). However if you wish, I
can just rename that.

Miklos

On Thu, Jul 2, 2009 at 9:09 PM, Stephen
Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
> Okay, here's a patch for this paragraph.  If some particular needs to
> be clarified, let me know...
>
> Incoming packets must be dispatched either to the AM stack or the
> Ieee154 stack, depending on the value of the "network" byte.  After a
> packet is received, the radio stack must inspect the value of the
> network byte.  If the value is TINYOS_6LOWPAN_NETWORK_ID (= 3f), the
> packet is treated as an AM packet and dispatched through the AMReceive
> interface based on the next byte, "type".  The payload pointer is
> updated to point to the byte after the type byte: this will be the
> address of the msg->data field.
>
> Otherwise, the packet is not an AM packet, and dispatched through the
> Ieee154Receive interface.  The payload pointer continues to point at
> the "network" byte, and further dispatching is left to higher layers.
>
> On Thu, Jul 2, 2009 at 12:00 PM, Philip Levis<pal at cs.stanford.edu> wrote:
>>
>> On Jul 2, 2009, at 11:29 AM, Stephen Dawson-Haggerty wrote:
>>
>>> 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).
>>
>> Can you talk a little bit about how this dispatch will work?
>>
>> The rest of the proposal looks good to me.
>>
>> Phil
>>
>