Glenn, Do you plan on participating at the call in 34min? I will add an action point to discuss about it.
My take is that 6P signaling traffic is nothing different from regluar traffic, and I don't believe we have any text anywhere that mandates a particular cell/slotframe to be used for it. Why not just let 6P traffic flow on the same cells at DATA, and let SF0 size the bundle between the neighbor nodes so it offers enough bandwidth for all traffic. About the simyulation, Malisa is spearheading the project. I'll let him update you. Thomas On Wed, Nov 30, 2016 at 7:03 PM, Glenn Daneels <[email protected]> wrote: > Dear all, > > I am wondering if there is any policy on when 6P reservations request and > responses (the “6P transaction”) should be sent (when e.g. doing > neighbor-to-neighbor scheduling). In the 6TiSCH minimal configuration there > is not really a need for this because of the static schedule (the one > active cell). But when using a dynamic scheduler as SF0, the 6P requests > and responses should also be sent. In the "6TiSCH Operation Sublayer > (6top)”, it is suggested that 6P can be used with the minimal configuration > (https://tools.ietf.org/html/draft-wang-6tisch-6top- > sublayer-04#section-2.2); it is recommended that two types of slotframes > are used: one (SFR0) for the Minimal 6TiSCH configuration and one (SFR1) > for 6P to allocate cells from. Should SFR1 then be used for the 6P ADD and > RESPONSE messages or is this slotframe only meant to allocate data > transmissions cells from (and should the actual ADD and RESPONSE messages > be sent somewhere else) or both? What is the current recommended policy for > this (if there is any)? Is it for example also possible that 6P messages > are sent in between normal data transmissions and thus not in a separate, > dedicated slotframe? > > I am also wondering if there is a similar policy on which type of cell > should preferably be used for 6P ADD and RESPONSE messages (or other 6P > commands in general): should one choose for Transmit or Shared cells? For > me, the second option looks the more intuitive one as you could have some > kind of minor management slotframe in which the motes contend to do 6P > transactions (but of course, having such a “shared” management frame could > be a bit much in the context of TSCH). > > I do not any other information on this topic in the different drafts or > mailing list. > > As a third and last question, related to those shared cells, I noticed > that there is some work done in the 6TiSCH simulator on shared cells > by Xavier Vilajosana and Mališa Vučinić. Is the usage of a shared cell > fully working or is this work in progress as I see that the commits are > very recent? > > Kind regards, > Glenn > > -- > Glenn Daneels > IDLab research group > Dept. Mathematics and Computer Science > University of Antwerp - imec > Campus Middelheim, Building G, Office M.G.212 > Email: [email protected] > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
