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

[Stephen Dawson-Haggerty]

I replied in a previous email.  Any way we can add Miklos to the net2
list for this discussion?  Maybe he wants to join net2...

Steve

---------- Forwarded message ----------
From: Miklos Maroti <mmaroti at math.u-szeged.hu>
Date: Sun, Jun 28, 2009 at 4:10 PM
Subject: Re: Incremental Radio Interface Update for 2.1.1
To: Stephen Dawson-Haggerty <stevedh at eecs.berkeley.edu>
Cc: net2-wg <net2-wg at millennium.berkeley.edu>, David Moss <dmm at rincon.com>


Dear All,

I think BLIP should use an Ieee154Send interface and not the regular
Send interface (this is unrelated to having a network id). Quite
likely we are going to provide 64 bit addresses in the not so distant
future.

Second, if I see correctly, then both BLIP and regular ActiveMessageC
would use a single network id, so you do not want to dynamically
change the network id.

Third, I think the "interface Resource as RadioResource[uint8_t
client]" would be a very good addition, and it should be moved as low
in the stack as posisble, so it can be shared by all network AND
active messages. Then we can have a generic AMSenderC and
Ieee154SenderC components without the extra files such as AMQueue*.

Miklos

On Mon, Jun 29, 2009 at 12:20 AM, Stephen
Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
> Hi--  We've been discussing the changes necessary to the radio stack
> for blip; let me finally provide a concrete proposal.  Is this
> acceptable to everyone?
>
> Goal: add ability to send/receive from multiple "networks", as
> determined by the "network" dispatch byte in a TinyOS IFRAME.
> Motivation: the network byte may become assigned by IANA in the
> future.  We should be able to support new network protocols expecting
> to receive packets dispatched on this byte.
> Proposed additions: add three parameterized interfaces as system-wide
> networking abstractions:
>
>    interface Resource[uint8_t clientId];
>    interface Send as NetworkSend[uint8_t networkId];
>    interface Receive as NetworkReceive[uint8_t networkId];
>
> Sample patch for the cc2420 is attached.  This is not meant to be
> committed, since it will break if TFRAMES are used and is not
> well-tested.
>
> Just like in the AM layer, we need resource sharing between different
> senders.  However, I am loathe to add another layer of buffering since
> most existing code assumes it "owns" the radio and does its own
> buffering-- both blip and the AM stack do this.  The lightest-weight
> solution seems to be adding a Resource lock around the radio; with
> FCFS it will be reasonably fair.
>
> Changes to AM: the resource request/release calls are added to
> CC2420ActiveMessageP, so the semantics of using AMSend do not change.
> Active Messages become just another "network" but the interface change
> is encapsulated so there shouldn't be any broken code.
>