[net2-wg] Incremental Radio Interface Update for 2.1.1

[Stephen Dawson-Haggerty]

On Tue, Jun 30, 2009 at 10:55 AM, Miklos Maroti<mmaroti at math.u-szeged.hu> wrote:
>>> - 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
>
> I do not understand the next sentence
>
>> 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.
>
> I think the AM payload should be after the stuff after and not
> including the "type" byte. The Ieee 802154 payload should be the stuff
> after and not including the "network" byte. The network byte should
> not be written directly, no?

Sorry I was unclear.

This really gets to a bit of 802.15.4's brokenness-- there's no
upper-layer dispatch field in the header.  Therefore it makes sense to
me to expose the network byte as part of the payload.  Some more on
this below.

As far as the AM interface, I agree-- from my point of view it's set
in stone and can't change in this release.

>
>>> - 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.
>
> What I am saying that by defining TFRAMES then we would still have the
> fanout interfaces but only the TINYOS_6LOWPAN_NETWORK_ID network would
> be used and the packet would not contain the network byte. On the
> other hand if you define IEEE154FRAMES, then once again a single
> network id would be used for the span out and the packet again would
> not contain the network byte.
>
> Maybe I completely misunderstand the use of the network byte, maybe
> you do not want to use a single network (like for TFRAMES) for TCP.

This actually gets at a secret motivation of mine :)  The current
6lowpan draft I implement (draft-hui-6lowpan-hc-01) uses two network
ids, one for link-local and one for global scope communication.  More
recent drafts have used a larger number of network ids as they try to
find some extra bits.  Now, we can certainly argue about whether or
not this is okay, but looking forward it's would be nice if we didn't
have to change a bunch of stuff to make this work cleanly, and just
leaving the network byte as part of the payload does this.

In any case, the code that does dispatching based on network id should
be platform-independent, and not in the radio stack.

>
> From your other letter, I think it is immaterial how the
> cc2420_header_t is defined, every packet would be manipulated via
> standard interfaces and not directly (certainly the RF230 will not
> provide this struct).

Of course.

>
> Miklos
>
>
>
> Miklos
>