Hi Thomas, > On 09 Dec 2016, at 15:28, Thomas Watteyne <[email protected]> wrote: > > Glenn, > > Do you plan on participating at the call in 34min? I will add an action point > to discuss about it.
Unfortunately, today I’m not able to participate in the call. > > 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. Ok, thanks. I was confused about this because of this section, https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.2 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.2>, where it is mentioned that 6P could be used alongside the minimal configuration slotframe. I thought that the second slotframe (“slotframe 1”) had the specific goal to allow the exchange of 6P messages. It seems that I interpreted that section wrongly. > > About the simyulation, Malisa is spearheading the project. I'll let him > update you. In the meanwhile, he already updated me: the shared slots should work. > > Thomas Thanks, 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] > > On Wed, Nov 30, 2016 at 7:03 PM, Glenn Daneels <[email protected] > <mailto:[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 > <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] <mailto:[email protected]> > > _______________________________________________ > 6tisch mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <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 <http://www.thomaswatteyne.com/> > _______________________________________ > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
