[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

On Tue, Jun 30, 2009 at 10:03 AM, Miklos Maroti<mmaroti at math.u-szeged.hu> wrote:
> Hi Stephen,
>
> This sounds great for the RF2xx codebase, and a good starting point to
> migrate away when we introduce 64-bit addresses. A few comments and
> questions:
>
> - From my experiences with supporting BLIP on the RF2xx, PacketLink is
> automatically enabled for the Ieee802154C, but it is off by default
> for the ActiveMessageC. How are we going to merge these two since they
> are compile time switches.

Actually Ieee802154C is agnostic to whether PacketLink is on or off;
BLIP will turn it on but the stack will work either way.

>
> - I assume that CC2420RadioC will do the fanout, so it will provide
> parametrized Send and Receive interfaces, right? However, what if we
> want to enable TFRAMES, then this fanout will disappear and only
> Receive[TINYOS_6LOWPAN_NETWORK_ID ] will be called?

CC2420RadioC does fanout based on networkId on receives, and on a
clientId for sends (the clients are AM and 802154).  When TFRAMES are
enabled, we don't support the 802.15.4 interface; I put in an #error
about this.  When using Ieee802154C, I've decided to make the network
byte the first byte of the payload and so people wishing to ignore it
can wire the whole interface.  This will cause fanout warnings if used
with AM, but that is the correct behavior.

>
> - Will it be possible to use Ieee802154C without the 6lowpan network
> id, so is there going the be an IEEE802154FRAMES switch similar to
> TFRAMES?

I suppose this would remove the network and type bytes from the header
structure, which could be more elegant in some case.  This would then
not provide a parameterized interface, since there would be nothing to
do dispatching on.  I'm not necessarily opposed, but not sure I see
the need either.

>
> - Can we name all components with 154 instead of 802154? It is getting
> rather long. The current code base has both usage, at least we should
> converge them to the same.

Fine with me.

>
> Miklos
>
> On Tue, Jun 30, 2009 at 6:53 AM, Stephen
> Dawson-Haggerty<stevedh at eecs.berkeley.edu> wrote:
>> 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
>>>
>>
>