And what would be your recommendation for 6TiSCH, Pat? Pascal
Le 18 déc. 2015 à 18:43, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> a écrit : 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]<mailto:[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]] 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]] 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]] 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 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 _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> 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 _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
