Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Thomas Eichinger]

Hi Joakim,

Thanks for sharing your point of view.

Personally I think it complicates MAC protocol implementations when they
somehow have to accommodate 802.15.4 functionality and deal with e.g.
starting and maintaining the PAN and I'd expect we will have to use more
#ifdefs.

In my opinion runtime functionality as described in 6.3 and following of
the standard also doesn't need to run with the same priority as the 
actual

MAC protocol.

Your approach would however benefit upper layers I think as the 
interface

wouldn't have to change.

In the end I'm fine with whatever works and covers our requirements.

Best, Thomas

On 20 Sep 2017, at 1:11 PDT(-0700), Joakim Nohlgård wrote:


Hi,
I have recently been digging around the gnrc_netdev code as well. I
think that adding support for other frame types and logic for sending
these frames will definitely become a mess if the 802.15.4 code is not
decoupled from the netdev code. Especially if someone would like to
add advanced features like 802.15.4e TSCH, which requires version 2
framing and a number of special MAC header fields. I don't think the
802.15.4 layer needs to be in its own thread though, it should be
enough to separate the framing functionality from the send/recv code
and let the MAC layer handle it internally, and keep the 802.15.4
layer in the same thread as the netdev driver, like gnrc_netdev does
today.

/Joakim

On Wed, Sep 20, 2017 at 12:16 AM, Thomas Eichinger 
 wrote:

Hi Oleg!

On 19 Sep 2017, at 13:24 PDT(-0700), Oleg Hahm wrote:


On Sun, Sep 17, 2017 at 02:37:39PM -0700, Thomas Eichinger wrote:

A while ago I worked on adding support for MAC commands and 
procedures

the
standard describes like channel scanning and automatic association 
of a

device with a coordinator.
Personally I think those are nifty features to provide, the reality 
check

the last two days showed though that it'd need some non-trivial
refactoring
of the existing 15.4 code to not end up in #ifdef hell.




Can you elaborate a little bit on this part? I would assume that 
being

compatible with other 802.15.4 implementations requires run-time
flexibility,
i.e., react properly to optional features implemented by other 
802.15.4
devices. Or were you proposing to have a minimal 
non-standard-compliant
version _and_ standard-compliant version intermingled, sharing 
commmon

code
through preprocessor directives?



Admittedly the "#ifdef hell" was a bit polemic and I didn't intend to
propose
offering a non-standard-compliant version. ;)

Right now RIOT is very much streamlined to send and receive 802.15.4 
data

and
ACK frames. The nontrivial refactoring I referred to would have to 
break

this.

On the receiving side I see the possibility to introduce an other 
nettype

like
GNRC_NETTYPE_802154 set by the corresponding frame type and the 
actual

runtime
logic would basically be in parallel of sixlowpan threads, 
hierarchically.
(changing channels and hardware addresses, actively/passively 
scanning for

coordinators...)
That'd be at least my approach.

On the sending side, however, the 15.4 header currently gets crafted 
in the
netdev code and set to data frames. We'd have to take that out and 
let the
upper layers  define the frame type, or at least overwrite it. There 
will be

more flags or header fields that will have to get configurable.

Do others see a better approach?

So, instead of having a minimal non-standard-compliant version I'd 
rather

progress to a minimal standard-compliant version with the inevitable
increase
in code size. From there we can take it how far we want and make it
configurable
i.e. supporting IEs and use 802.15.9 to support key management etc. 
The sky

is
the limit.
(Or as a German'd say "With sauce and spicy!")

Does this somehow answer your question? Let me know if I missed it.

Best, Thomas

p.s.: Writing this it seems easier to do actually. Good we talked 
about it.

:)

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] gnrc: MAC layer selection

[Martine Lenders]

Hi Joakim, Hi Shuguo,

First of all: We know of this problem and I try to come up with a solution
for this for a long time, so thanks for picking this up. A step into that
direction (but not the final solution) was the refactoring of GNRC's
interface layer (aka gnrc_netif2, see [1], should also simplify
implementing new MAC-layers a lot ;-)).

2017-09-20 10:38 GMT+02:00 Shuguo Zhuo :

> Hi, Joakim,
>
> This is a very good topic which also confuses me (with also my GoMacH MAC
> implementation queued up in pipe).
>
> > One possible solution is to add a function pointer member to the
> > `at86rf2xx_params_t` (and similar parameter structs for the other
> > netdev drivers) for initializing the MAC layer, and let the user
> > select the MAC layer there.
>
> This sounds like a good solution to me.
> Waiting for responses from more experienced RIOT developers. ;-)
>

I see some problems with this for several reasons:

a) This seems too device-specific for me. Can we maybe find a looser
coupling. First thing coming to mind is a (void *,
MAC_init_function)-tuple, where `void *` is an arbitrary params struct
(this solution isn't perfect either because it requires some searching).
b) Device configuration. That's a problem with our config in general. Say
you have several devices the same type on a board (e.g. two at86rf233). If
you want to change the config (i.e. switch MAC layer) for one device of
that type you need to reconfigure *all* devices of that type, since they
are in a static array. That sucks.
c) We need to ensure that this solution isn't GNRC-specific. lwIP has a
similar mechanism (different init functions for different MAC layers), but
there abstraction only starts at the interface layer, so a user (or in our
case our auto-init system) needs to know which device they want to use for
which MAC layer (sounds familiar?)
d) Function pointers. While I personally have no problem with function
pointers and quite happily use them to achieve better modularity (see [1]
;-)), I know there are community members that don't think using too many
function pointers is a good idea and make the code more complicated.

Best Regards,
Martine

[1] https://github.com/RIOT-OS/RIOT/pull/7370

>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Joakim Nohlgård]

On Wed, Sep 20, 2017 at 11:32 AM, Kaspar Schleiser  wrote:
> Hi Joakim,
>
> On 09/20/2017 10:11 AM, Joakim Nohlgård wrote:
>> I have recently been digging around the gnrc_netdev code as well. I
>> think that adding support for other frame types and logic for sending
>> these frames will definitely become a mess if the 802.15.4 code is not
>> decoupled from the netdev code.
>
> Could you elaborate why? We should aim to get as much as possible
> gnrc-independent code.

I don't have an opinion on whether to depend on gnrc or not, but the
current send and recv implementation in gnrc_netdev_ieee802154 acts as
a wrapper for the real device driver send/recv functions, so the MAC
layer calls the wrapper function which generates the frame header
before passing on to the device driver. What I meant was that this
header generation/parsing should be its own separate function that the
MAC layer explicitly calls, instead of implicitly as a middle layer
between the MAC and the network device driver. All of the header
generation code is inside gnrc_netdev_ieee802154.c right now. That
code is going to be a mess if more frame types are added, or different
frame versions and header options should be supported.

https://github.com/RIOT-OS/RIOT/blob/master/sys/net/gnrc/link_layer/netdev/gnrc_netdev_ieee802154.c#L154

/Joakim
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] On the State of RIOT's IEEE 802.15.4 Support

[Kaspar Schleiser]

Hi Joakim,

On 09/20/2017 10:11 AM, Joakim Nohlgård wrote:
> I have recently been digging around the gnrc_netdev code as well. I
> think that adding support for other frame types and logic for sending
> these frames will definitely become a mess if the 802.15.4 code is not
> decoupled from the netdev code.

Could you elaborate why? We should aim to get as much as possible
gnrc-independent code.

Kaspar
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] gnrc: MAC layer selection

[Shuguo Zhuo]

Hi, Joakim,

This is a very good topic which also confuses me (with also my GoMacH MAC 
implementation queued up in pipe). 

> One possible solution is to add a function pointer member to the
> `at86rf2xx_params_t` (and similar parameter structs for the other
> netdev drivers) for initializing the MAC layer, and let the user
> select the MAC layer there.

This sounds like a good solution to me. 
Waiting for responses from more experienced RIOT developers. ;-)

Bests,
Shuguo

- 原始邮件 -
> 发件人: "Joakim Nohlgård" 
> 收件人: "RIOT OS kernel developers" 
> 发送时间: 星期三, 2017年 9 月 20日 上午 9:56:19
> 主题: [riot-devel] gnrc: MAC layer selection
> 
> Dear developers,
> Currently there are two different MAC layers for gnrc in the master
> branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a
> no-op MAC layer, only passes packets between the netdev driver and the
> upper layers, while LWMAC is a duty cycling MAC implementation which
> manages a schedule for the radio, including sleep.
> 
> Which layer is used is selected by which init function is called
> during boot, if gnrc_lwmac_init is called, then the device will run
> LWMAC, or if gnrc_netdev_init is called, then the device will use
> gnrc_netdev. auto_init has an `#ifdef` block checking for
> `MODULE_GNRC_LWMAC` and uses that to select which init function is
> called, but this is only implemented for the at86rf2xx driver, any
> other drivers will need to have similar changes to their auto_init
> functions as well.
> 
> This current model is not going to scale well when new devices are
> added and new MAC layers are implemented. All MAC layer
> implementations will need to touch all netif auto_init
> implementations.
> 
> I am asking for ideas on how to make this more modular and less #ifdeffy.
> 
> One possible solution is to add a function pointer member to the
> `at86rf2xx_params_t` (and similar parameter structs for the other
> netdev drivers) for initializing the MAC layer, and let the user
> select the MAC layer there.
> By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose
> the default MAC layer depending on the module selection. This would
> behave like it is today for LWMAC, but the #ifdef hell would be kept
> in a common header file, like gnrc_mac_default.h or something.
> 
> What are your thoughts on this?
> 
> I have a ContikiMAC MAC layer implementation queued up in the pipe for
> inclusion in master and it will only make this situation worse if we
> don't alter the current model.
> 
> Best regards,
> Joakim Nohlgård
> Eistec AB
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] gnrc: MAC layer selection

[Joakim Nohlgård]

Dear developers,
Currently there are two different MAC layers for gnrc in the master
branch: basic gnrc_netdev, and gnrc_lwmac. gnrc_netdev is basically a
no-op MAC layer, only passes packets between the netdev driver and the
upper layers, while LWMAC is a duty cycling MAC implementation which
manages a schedule for the radio, including sleep.

Which layer is used is selected by which init function is called
during boot, if gnrc_lwmac_init is called, then the device will run
LWMAC, or if gnrc_netdev_init is called, then the device will use
gnrc_netdev. auto_init has an `#ifdef` block checking for
`MODULE_GNRC_LWMAC` and uses that to select which init function is
called, but this is only implemented for the at86rf2xx driver, any
other drivers will need to have similar changes to their auto_init
functions as well.

This current model is not going to scale well when new devices are
added and new MAC layers are implemented. All MAC layer
implementations will need to touch all netif auto_init
implementations.

I am asking for ideas on how to make this more modular and less #ifdeffy.

One possible solution is to add a function pointer member to the
`at86rf2xx_params_t` (and similar parameter structs for the other
netdev drivers) for initializing the MAC layer, and let the user
select the MAC layer there.
By default, we can use a macro GNRC_DEFAULT_INIT or similar to choose
the default MAC layer depending on the module selection. This would
behave like it is today for LWMAC, but the #ifdef hell would be kept
in a common header file, like gnrc_mac_default.h or something.

What are your thoughts on this?

I have a ContikiMAC MAC layer implementation queued up in the pipe for
inclusion in master and it will only make this situation worse if we
don't alter the current model.

Best regards,
Joakim Nohlgård
Eistec AB
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel