tl;dr: Do we see the need to be IEEE 802.15.4 compliant?
RIOT so far does not support anything other than beacon, data, and ack frames while the standard says that also reduced-function devices have to support certain command frames [IEEE802.15.4-2015 7.5.1]. Basically, "RIOT does not support IEEE 802.15.4".
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.
(I see work on netif2 but I am not in the position to evaluate if above mentioned will benefit from it.)
On the other side, scanning through Zephyr's 1.9.0 release notes I noticed their support for IEEE 802.15.4 MAC commands, at least the most basic ones. So we'd have an other project to actually test against. (They also claim support for basic 802.15.4 security.)
Thus my questions,
do people consider adding support for MAC commands worth the effort?
Does anybody know about cases these are actually used?
Can we add those when approaching 802.15.4 security?
Agreed. I realise it’s difficult, but I think having 15.4 support as a primary goal is very important for compatibility reasons with other software and hardware platforms.
I agree with Kaspar: thanks for bringing this up and yes, we should aim for
compliance.
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?
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.
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.
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.
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.
Hi again,
Perhaps it would make sense to split it in two? One low level part
which manages the duty cycling and wake scheduling, while the PAN
management part (I think it is called MAC services in the 802.15.4
standard) would run as a higher layer on top of it.
this will be discussed tomorrow at the T2TRG meeting preceeding the RIOT summit [1]. Will anyone of you who discussed this be there? The premise is that 6LoWPAN was designed to run on even on a minimized, non-compliant IEEE 802.15.4, so the question is: other than PAN bootstrapping and MAC: is this really required for a minimal network set-up? (Answer in the session, rather than in this thread are preferred, but I’ll try to carry any posts here into the f2f discussion ;-)).
