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?
ThanksQin
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
