Can we get some text quoted from the appropriate IEEE spec(s) to support the positions in this discussion?
- Ralph > On Dec 12, 2015, at 5:29 PM 12/12/15, 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 > > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
