Hi, 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 ;-)).
Best, Martine [1] https://github.com/t2trg/2017-09-berlin#agenda 2017-09-21 19:11 GMT+02:00 Thomas Eichinger <tho...@riot-os.org>: > 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 >
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
