On Dec 18, 2015, at 9:40 AM 12/18/15, [email protected] wrote:
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]> 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]
Cc: Qin Wang <[email protected]>; Pascal Thubert (pthubert)
<[email protected]>; Xavier Vilajosana
<[email protected]>; Tero Kivinen <[email protected]>; Ralph
Droms (rdroms) <[email protected]>; Kris Pister <[email protected]>;
[email protected]; 6tisch <[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]
<[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/28cb63f
de078a0aec8307d416e82cdf482c0608a
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
