Hi Joakim,
That was what I pretty much meant before I'm sorry for not expressing
this clear enough.
Seems we reached common ground here.
Best,
Thomas
On 20 Sep 2017, at 13:51 PDT(-0700), Joakim Nohlgård wrote:
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.
/Joakim
On Wed, Sep 20, 2017 at 10:37 PM, Thomas Eichinger
<tho...@riot-os.org> wrote:
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
<tho...@riot-os.org>
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
_______________________________________________
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
