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] < [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]> 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]> 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 >> [email protected] >> >> On Dec 11, 2015, at 5:06 PM, Qin Wang <[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]" >> <[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]> 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]>: >> >> 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] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> _______________________________________________ >> 6tisch mailing list >> [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 (510) 489-3799 FAX [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 and delete the original transmission and its attachments without reading or saving in any manner. Thank you.
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
