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] <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>
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
