According to 802.15.4, shared time slots may use CCA but are not required to use CCA.
Pat On 18, Dec2015, at 11:19, Ralph Droms <[email protected]> wrote: On Dec 18, 2015, at 11:55 AM, Pascal Thubert (pthubert) <[email protected] <mailto:[email protected]>> wrote: > Hello Xavi: > Point is, we are doing statistical multiplexing in the minimal time slots. If > a node starts talking, the others should yield. > The draft says that CCA is optional; this is not a very strong language. > Shouldn’t we encourage it a bit more loudly? What do the IEEE 802.15.4 specs require for the use of slots marked as shared? > > Cheers, > > Pascal > > From: [email protected] <mailto:[email protected]> > [mailto:[email protected] <mailto:[email protected]>] On Behalf Of > Xavier Vilajosana > Sent: vendredi 18 décembre 2015 17:47 > To: [email protected] > <mailto:[email protected]> > Cc: Pascal Thubert (pthubert) <[email protected] > <mailto:[email protected]>>; Tero Kivinen <[email protected] > <mailto:[email protected]>>; Ralph Droms (rdroms) <[email protected] > <mailto:[email protected]>>; Kris Pister <[email protected] > <mailto:[email protected]>>; 6tisch <[email protected] > <mailto:[email protected]>>; Simon Jonathan <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > As Jonathan said in a previous thread. CCA is optional and does not bring a > big advantage as nodes are synchronized and communication occurs at the same > time and hence CCA does not bring a lot. Maybe to get some benefit in duty > cycle regulation due to LBT and maybe to avoid some external interference. > But at the end the behaviour in shared slots is slotted aloha if this CCA > option is not used. > > regards, > Xavi > > > 2015-12-18 17:00 GMT+01:00 [email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>>: > You’re correct, they are very similar so no need to change. > > Pat > > On 18, Dec2015, at 8:57, Pascal Thubert (pthubert) <[email protected] > <mailto:[email protected]>> wrote: > > Hello Pat: > > Actually, I provisionally wrote the following in last call text for the > abstract: > > > This document describes a minimal mode of operation for a 6TiSCH > > Network, to provide IPv6 connectivity over a Non-Broadcast > > Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Time slotted > > Channel Hopping (TSCH) links. > > This minimal mode uses a collection of protocols including the 6LoWPAN > > framework and RPL to enable shared access operations over a static > > TSCH schedule. > > > Note that Ralph had an issue with the beginning of the sentence which now > mentions a “collection of protocols”. > > Otherwise, the last call text seems to be very similar to your proposal. > Would you suggest to change the above abstract or is it OK as is? > > Pascal > > From: [email protected] > <mailto:[email protected]> > [mailto:[email protected] > <mailto:[email protected]>] > Sent: vendredi 18 décembre 2015 15:41 > To: Pascal Thubert (pthubert) <[email protected] <mailto:[email protected]>> > Cc: Simon Jonathan <[email protected] <mailto:[email protected]>>; Qin Wang > <[email protected] <mailto:[email protected]>>; Xavier Vilajosana > <[email protected] <mailto:[email protected]>>; Tero > Kivinen <[email protected] <mailto:[email protected]>>; Ralph Droms (rdroms) > <[email protected] <mailto:[email protected]>>; Kris Pister <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; 6tisch <[email protected] > <mailto:[email protected]>> > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > We could change the sentence to : This minimal mode leverages 6LoWPAN and RPL > to enable communication links over a static TSCH schedule via shared > time-slots. > > Pat > > > On 18, Dec2015, at 8:25, Pascal Thubert (pthubert) <[email protected] > <mailto:[email protected]>> wrote: > > We need to reach consensus on this; > > With minimal, we are using a time slotted medium with shared access. And we > want to do cca to avoid collisions, don’t we? If that’s so, then even if the > MAC has that optional, minimal needs it. > Should we call this TDMA? For some people (including Wikipedia and yours > truly), TDMA is about exclusive access to time slots. Which will be the case > of the slots that are assigned by the 6P protocol between parent and child, > but is not the case of the minimal draft. I agree that because we do cca, we > are not aloha stricto sensu either. > > What we are doing extends slotted-aloha to make it “polite”. In a way that > makes minimal compliant with ETSI, since politeness is what the regulation is > all about. > > Will we agree if we replace “slotted-aloha” by “polite slotted-aloha” or “a > polite form of slotted-aloha”? > > Cheers, > > Pascal > > From: Jonathan Simon [mailto:[email protected] <mailto:[email protected]>] > Sent: mardi 15 décembre 2015 01:28 > To: [email protected] > <mailto:[email protected]> > Cc: Qin Wang <[email protected] <mailto:[email protected]>>; Pascal > Thubert (pthubert) <[email protected] <mailto:[email protected]>>; Xavier > Vilajosana <[email protected] > <mailto:[email protected]>>; Tero Kivinen <[email protected] > <mailto:[email protected]>>; Ralph Droms (rdroms) <[email protected] > <mailto:[email protected]>>; Kris Pister <[email protected] > <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; 6tisch <[email protected] > <mailto:[email protected]>> > Subject: Re: [6tisch] #40 (minimal): Ralph's INT AREA review on minimal > > Pat - Carrier sense (via CCA) is an option in TSCH, so it can be used where > appropriate (e.g. for coexistence), but isn't required in general as part of > the media access scheme, again because it may not be useable in a tightly > synchronized network. > > Jonathan > > On Mon, Dec 14, 2015 at 4:18 PM, [email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>> wrote: > I made an error in my earlier email, although shared slots do not require > carrier sense, it is really recommended. In most 15.4 modes (but not TSCH) > when a device wishes to use a shared medium, the devices use CSMA to avoid > collisions. Also, devices compliant to ETSI 300-328 must use carrier sense > for LBT (802.15.4’s CSMA is cited in that regulation) > > Pat > > On 12, Dec2015, at 16:29, Jonathan Simon <[email protected] > <mailto:[email protected]>> wrote: > > Pat - unless something was changed in 802.15.4-2015, that was not how the > original TSCH shared slots worked. Devices don't do carrier sense, since > transmissions are synchronized and talk at the same time (within sync > tolerances) - they do however back off using a similar backoff mechanism, but > counted in shared slots as opposed to time, to avoid persistent collision. > I think that's what "slotted Aloha" is supposed to mean here - a slotted > shared medium without carrier sense. > > Jonathan > > On Sat, Dec 12, 2015 at 4:57 AM, Pat Kinney > <[email protected] > <mailto:[email protected]>> wrote: > Hi Qin; > A shared slot is open for all devices. To transmit on this timeslot a device > shall sense the medium for activity, if active it shall wait for the next > available time slot. Hence a shared slot is a contention access period for > CSMA-CA. This isn't slotted aloha, since it senses the medium first. > Pat > > Patrick Kinney > Kinney Consulting > +1.847.960.3715 <tel:%2B1.847.960.3715> > [email protected] <mailto:[email protected]> > > On Dec 11, 2015, at 5:06 PM, Qin Wang <[email protected] > <mailto:[email protected]>> wrote: > > Hi Pat, > > According to my understanding, in the TSCH mode of 802.15.4, if the attribute > of a slot is Shared, slotted- aloha access should be allowed in the slot. > Right? > > Thanks > Qin > > > > On Friday, December 11, 2015 2:29 PM, "[email protected] > <mailto:[email protected]>" > <[email protected] > <mailto:[email protected]>> wrote: > > > Xavi; > > As I understand slotted-aloha, TSCH is really Time Division Multiple Access > (TDMA), not slotted-aloha. Slotted-aloha access to the medium is used in the > 802.15.4 CSMA algorithms for some modes but not TSCH. > > Pat > > On 11, Dec2015, at 11:24, Xavier Vilajosana <[email protected] > <mailto:[email protected]>> wrote: > > Dear all, > > I wrapped up the proposed changes and integrated them to the version in > bitbucket. > https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a > > <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/commits/28cb63fde078a0aec8307d416e82cdf482c0608a> > > For simplicity, see here a summary of the changes. > > > Abstract: > > [OLD] > > This document describes the minimal set of rules to operate an IEEE > 802.15.4 Timeslotted Channel Hopping (TSCH) network. This minimal > mode of operation can be used during network bootstrap, as a fall- > back mode of operation when no dynamic scheduling solution is > available or functioning, or during early interoperability testing > and development. > > [NEW] > > This document describes a minimal mode of operation for a 6TiSCH > Network, to provide IPv6 connectivity over a Non-Broadcast Multi- > Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted > Channel Hopping (TSCH) links. This minimal mode leverages 6LoWPAN > and RPL to enable slotted-aloha operations over a static TSCH > schedule. > > > Introduction: > > [OLD] > > The nodes in a IEEE 802.15.4 TSCH network follow a communication > schedule. The entity (centralized or decentralized) responsible for > building and maintaining that schedule has precise control over the > trade-off between the network's latency, bandwidth, reliability and > power consumption. During early interoperability testing and > development, however, simplicity is more important than efficiency. > One goal of this document is to define the simplest set of rules for > building a TSCH-compliant network, at the necessary price of lesser > efficiency. Yet, this minimal mode of operation MAY also be used > during network bootstrap before any schedule is installed into the > network so nodes can self-organize and the management and > configuration information be distributed. In addition, the minimal > configuration MAY be used as a fall-back mode of operation, ensuring > connectivity of nodes in case that dynamic scheduling mechanisms fail > or are not available. The IEEE 802.15.4 specification provides a > mechanism whereby the details of slotframe length, timeslot timing, > and channel hopping pattern are communicated when a node time > synchronizes to the network [IEEE802154]. This document describes > specific settings for these parameters. > > [NEW] > > A 6TiSCH Network provides IPv6 connectivity over a Non-Broadcast > Multi-Access (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted > Channel Hopping (TSCH) links. > > The 6TiSCH [I-D.ietf-6tisch-architecture] architecture requires the > use of both RPL and the 6LoWPAN adaptation layer framework > ([RFC4944], [RFC6282]) as defined over IEEE 802.14.5. 6LoWPAN > Neighbor Discovery [RFC6775] (ND) is also required to exchange > Compression Contexts, form IPv6 addresses and register them for the > purpose of Duplicate Address Detection, Address Resolution and > Neighbor Unreachability detection over one TSCH link. In order to > reduce the header overhead of the RPL artifacts in data packets, the > Routing header [RFC6554], the RPL Option [RFC6553] and the related IP > in IP encapsulation MUST be encoded as prescribed in > [I-D.ietf-6lo-routing-dispatch] > > Nodes in a IEEE 802.15.4 TSCH network follow a communication > schedule. A network using the simple mode of operation uses a static > schedule. > > This specification defines a Minimal Configuration to build a 6TiSCH > Network, using the Routing Protocol for LLNs (RPL) and a static TSCH > Schedule. The 802.15.4 TSCH mode, RPL [RFC6550], and its Objective > Function 0 (OF0) [RFC6552], are used unmodified, but parameters and > particular operations are specified to guarantee interoperability > between nodes in a 6TiSCH Network. > > More advanced work is expected in the future to complement the > Minimal Configuration with dynamic operations that can adapt the > Schedule to the needs of the traffic in run time. > > > Section 11.2 > > [OLD] > > In addition to the Objective Function (OF), nodes in a multihop > network using RPL MUST indicate the preferred mode of operation using > the MOP field in DIO. Nodes not being able to operate in the > specified mode of operation MUST only join as leaf nodes. RPL > information and hop-by-hop extension headers MUST follow [RFC6553] > and [RFC6554] specification. In the case that the packets formed at > the LLN need to cross through intermediate routers, these MUST follow > the IP in IP encapsulation requirement specified by the [RFC6282] and > [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST > be compressed according to [RFC6282]. > > [NEW] > > In addition to the Objective Function (OF), nodes in a multihop > network using RPL MUST indicate the preferred mode of operation using > the MOP field in DIO. Nodes not being able to operate in the > specified mode of operation MUST only join as leaf nodes. RPL > information and hop-by-hop extension headers MUST follow [RFC6553] > and [RFC6554] specification. In the case that the packets formed at > the LLN need to cross through intermediate routers, these MUST follow > the IP in IP encapsulation requirement specified by the [RFC6282] and > [RFC2460]. RPI and RH3 extension headers and inner IP headers MUST > be compressed according to [RFC6282] and [I-D.ietf-6lo-routing-dispatch]. > > > have a nice weekend, > Xavi > > 2015-12-11 17:49 GMT+01:00 Kris Pister <[email protected] > <mailto:[email protected]>>: > Ralph - to my knowledge no one has deployed the specific time-parent > selection scheme described in 802.15.4-*. The basic scheme will likely work, > but the devil will be in the real-world details. > > We've had about 8 years of successful deployments of industrial tsch mesh > networks using a time-parent selection scheme similar to what is proposed > in minimal. > > 6TiSCH present a rich design space at many levels. The goal of minimal was > to do something simple, based as closely as possible on things that are > known to work in deployed networks. The hope and belief is that new and > better ideas will emerge, but it is certain that many of the proposed "good > ideas" will fail. By defining minimal we provide a reliable interoperable > platform on which papers like "Comparing time-parent selection in 15.4-* > and foo" can be written. > > ksjp > > On 12/10/2015 5:43 AM, Ralph Droms (rdroms) wrote: > Is there an analysis published somewhere that demonstrates how time > synchronization in 802.15.4-* is inadequate for 6TiSCH? > > _______________________________________________ > 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > > _______________________________________________ > 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > _______________________________________________ > 6tisch mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > > > > > > > -- > Jonathan Simon > Linear Technology, Dust Networks product group > 32990 Alvarado-Niles Road, Suite 910 > Union City, CA 94587 > (510) 400-2936 <tel:%28510%29%20400-2936> > (510) 489-3799 <tel:%28510%29%20489-3799> FAX > [email protected] <mailto:[email protected]> > > ******************LINEAR TECHNOLOGY CORPORATION CONFIDENTIAL****************** > This e-mail transmission, and any documents, files or previous e-mail > messages attached to it may contain confidential information that is legally > privileged. If you are not the intended recipient, or person responsible for > delivering it to the intended recipient, you are hereby notified that any > disclosure, copying, distribution or use of any of the information contained > in or attached to this transmission is STRICTLY PROHIBITED. If you have > received this transmission in error, please immediately notify me by reply > email or by telephone at 510-400-2936 <tel:510-400-2936> and delete the > original transmission and its attachments without reading or saving in any > manner. Thank you. > > _______________________________________________ > 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] <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
