[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

Here's a more detailed proposal for system-wide link abstractions,
reflecting an implementation that supports blip and AM simultaneously,
and also works with AM when using TFRAMES.  I've tried to make things
as clean as I can without breaking any backwards compatibility-- ie,
no struct or interface changes.  Please let me know what you all
think-- I'm going to do some more testing in the next day or so and
try to get a patch then.  Phil-- does this need to be vetted by core?

Network stacks: System-wide link abstractions
---------------
 AM Stack: HIL is at ActiveMessageC.  Wires platform-specific code.
           network ID is TINYOS_6LOWPAN_NETWORK_ID (0x3f) if IFRAMEs used.
 802.15.4 Stack: HIL is Ieee802154C.  Wires platform-specific code.
           provides receive parameterized on network ID for convenience.
           [this is what's required for blip operation]
           [this will be replaced in the future by WG stack]

cc2420 implementation
-----------------
 The two system-wide abstractions are provided on top of a new
component, CC2420RadioC, which wires together the lower-layers in one
place.

  CC2420ActiveMessageC continues to provide AM support
    - Requests/releases resource at every send to preserve current semantics

  Ieee802154C       -> provides hardware-agnostic pass-through like
ActiveMessageC -- chip independent
  CC2420Ieee802154C -> required to be radio stack specific because of
packet formats
    - Resource            - get the radio lock to send packets
    - Ieee154Send         - send 802.15.4 packets with 16-bit short
IDs.  basically a renamed AMSend.
    - Receive[networkId]  - receive packets with a specific networkId.
 parameterized to avoid fanout problems
    - Packet
    - Ieee154Packet       - Basically a renamed AMPacket

    Because IEEE802154 doesn't have a dispatch field, these interfaces
    are not parameterized (except for network id).


And here's how it plays for apps.  Although adding additional networks
is possible, below the queuing layer is device-specific.

   ---------------------------------------
   | CTP             |    TCP     |          <- Transport
   ---------------------------------------
   | AMQueue         |    BLIP    |          <- Queuing
   ---------------------------------------
   | ActiveMessage   |  802.15.4  | ...      <- "Resource" arbitrated
sharing, chip specific
   ---------------------------------------
     CC2420RadioC                            <- Shared radio stack wiring
     CC2420TinyosNetworkC
     LplC
     CsmaC


On Sun, Jun 28, 2009 at 6:40 PM, Stephen
Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
>>
>> I think it boils down to a code size vs. RAM size issue. Queueing has a
>> larger RAM cost than locking. I'd like to see what the code size costs are.
>> I'm not sure what would be more, the locking or the queue management. One
>> issue there is that locking scales pretty linearly with clients, while
>> virtualization has only a small incremental cost per client. But I'd expect
>> we're not talking about tons of clients, so this is less of a concern than
>> the constant factors.
>
> I'm also very very concerned about the code size issue, especially in
> the common case where there is only one client (network).  In fact,
> the patch I sent it includes tests for the case where there is only
> one client and uses simplified logic-- this saves about 300 bytes ROM
> over the more general case.  The queuing is about as simple as I can
> make it, and it uses FcfsResourceQueue to actually do the queuing.
>
> Steve
>