Hi Pascal, That was the other alternative on the call I was referring to, if a node (application) requires spanning a slot for TX, then an application/context-based cell scheduling algorithm would just schedule adjacent cells ( on the same channel )— but this is just one alternative, there are probably other considerations…I’m still studying scheduling documents.
R. > On Dec 13, 2016, at 10:18 AM, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Seems that large EBs at low rates ended up being a problem in subgig cases > after all, Dale. > > The discussion at the interim was either to make very large slots => > impractical, or preconfigure sometimes, 2 or more consecutive time slots are > paired; the second is never scheduled, and is free to accept the remainder of > the frame sent in the first… The pairing will be interesting to make work, > ince the channel computation is based on ASN so the consecutive time slots to > not have the same channel offset…. > > Cheers > > Pascal > > > > From: 6tisch [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of Thomas Watteyne > Sent: vendredi 9 décembre 2016 15:39 > To: Dale R. Worley <[email protected] <mailto:[email protected]>> > Cc: Randy Turner <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > Subject: Re: [6tisch] slot schedluing > > Dale, > > +1 on your answer. > > Thomas > > On Thu, Dec 8, 2016 at 9:38 PM, Dale R. Worley <[email protected] > <mailto:[email protected]>> wrote: > Randy Turner <[email protected] <mailto:[email protected]>> > writes: > > Just re-confirming an assumption -- from a TSCH perspective, slot > > scheduling assumes any single transmission "cannot" exceed a slot > > boundary -- if transmissions require a certain amount of time, then the > > slot width is increased to deal with this ( or possibly increase the > > TX bit rate if possible ) > > > > Is this correct ? > > As others have noted, extending the slot width can only be done when the > network is initialized. In practice, packets that do not fit within a > slot time are fragmented. My understanding is that all such packets are > IP packets, and are fragmented using using the layer 2 fragmentation > defined in RFC 6282 (not the one defined in RFC 4944). Thus, the > minimum (layer 3) IPv6 MTU of 1280 bytes is supported. > > As far as I know, there is no fragmentation mechanism for the EB > (extended beacon) layer-2 packets. But that does not seem to be a > problem in practice. > > Dale > > _______________________________________________ > 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
