draft-ietf-6tisch-tsch-04.txt   draft-ietf-6tisch-tsch-05.txt 
6TiSCH T. Watteyne, Ed. 6TiSCH T. Watteyne, Ed.
Internet-Draft Linear Technology Internet-Draft Linear Technology
Intended status: Informational MR. Palattella Intended status: Informational MR. Palattella
Expires: June 22, 2015 University of Luxembourg Expires: July 12, 2015 University of Luxembourg
LA. Grieco LA. Grieco
Politecnico di Bari Politecnico di Bari
December 19, 2014 January 8, 2015
Using IEEE802.15.4e TSCH in an IoT context: Using IEEE802.15.4e TSCH in an IoT context:
Overview, Problem Statement and Goals Overview, Problem Statement and Goals
draft-ietf-6tisch-tsch-04 draft-ietf-6tisch-tsch-05
Abstract Abstract
This document describes the environment, problem statement, and goals This document describes the environment, problem statement, and goals
for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs. for using the IEEE802.15.4e TSCH MAC protocol in the context of LLNs.
The set of goals enumerated in this document form an initial set The set of goals enumerated in this document form an initial set
only. only.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 22, 2015. This Internet-Draft will expire on July 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8 4.6. Dataflow Control . . . . . . . . . . . . . . . . . . . . 8
4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8 4.7. Deterministic Behavior . . . . . . . . . . . . . . . . . 8
4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9 4.8. Scheduling Mechanisms . . . . . . . . . . . . . . . . . . 9
4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9 4.9. Secure Communication . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
8.3. External Informative References . . . . . . . . . . . . . 13 8.3. External Informative References . . . . . . . . . . . . . 12
Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 15 Appendix A. TSCH Protocol Highlights . . . . . . . . . . . . . . 13
A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 15 A.1. Timeslots . . . . . . . . . . . . . . . . . . . . . . . . 13
A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 16 A.2. Slotframes . . . . . . . . . . . . . . . . . . . . . . . 14
A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 16 A.3. Node TSCH Schedule . . . . . . . . . . . . . . . . . . . 14
A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 16 A.4. Cells and Bundles . . . . . . . . . . . . . . . . . . . . 14
A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 17 A.5. Dedicated vs. Shared Cells . . . . . . . . . . . . . . . 15
A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 17 A.6. Absolute Slot Number . . . . . . . . . . . . . . . . . . 15
A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 18 A.7. Channel Hopping . . . . . . . . . . . . . . . . . . . . . 16
A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 18 A.8. Time Synchronization . . . . . . . . . . . . . . . . . . 16
A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 19 A.9. Power Consumption . . . . . . . . . . . . . . . . . . . . 17
A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 19 A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . . 17
A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 20 A.11. Join Process . . . . . . . . . . . . . . . . . . . . . . 18
A.12. Information Elements . . . . . . . . . . . . . . . . . . 20 A.12. Information Elements . . . . . . . . . . . . . . . . . . 18
A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 20 A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . . 18
Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 21 Appendix B. TSCH Gotchas . . . . . . . . . . . . . . . . . . . . 19
B.1. Collision Free Communication . . . . . . . . . . . . . . 21 B.1. Collision Free Communication . . . . . . . . . . . . . . 19
B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 21 B.2. Multi-Channel vs. Channel Hopping . . . . . . . . . . . . 19
B.3. Cost of (continuous) Synchronization . . . . . . . . . . 21 B.3. Cost of (continuous) Synchronization . . . . . . . . . . 19
B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 22 B.4. Topology Stability . . . . . . . . . . . . . . . . . . . 20
B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 22 B.5. Multiple Concurrent Slotframes . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to
the Medium Access Control (MAC) protocol defined by the the Medium Access Control (MAC) protocol defined by the
IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be
rolled into the next revision of IEEE802.15.4, scheduled to be rolled into the next revision of IEEE802.15.4, scheduled to be
published in 2015. The Timeslotted Channel Hopping (TSCH) mode of published in 2015. The Timeslotted Channel Hopping (TSCH) mode of
IEEE802.15.4e is the object of this document. IEEE802.15.4e is the object of this document.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
2. Provide a mechanism for such deterministic flows to coexist with 2. Provide a mechanism for such deterministic flows to coexist with
bursty or infrequent traffic flows of different priorities. bursty or infrequent traffic flows of different priorities.
4.8. Scheduling Mechanisms 4.8. Scheduling Mechanisms
Several scheduling mechanisms can be envisioned, and possibly coexist Several scheduling mechanisms can be envisioned, and possibly coexist
in the same network. For example, in the same network. For example,
[I-D.phinney-roll-rpl-industrial-applicability] describes how the [I-D.phinney-roll-rpl-industrial-applicability] describes how the
allocation of bandwidth can be optimized by an external Path allocation of bandwidth can be optimized by an external Path
Computation Element (PCE). Alternatively, two neighbor nodes can Computation Element (PCE). Another centralized (PCE-based) traffic-
adapt the number of cells autonomously by monitoring the amount of aware scheduling algorithm is defined in [TASA-PIMRC].
traffic, and negotiating the allocation to extra cell when needed. Alternatively, two neighbor nodes can adapt the number of cells
This mechanism can be used to establish multi-hop paths in a fashion autonomously by monitoring the amount of traffic, and negotiating the
similar to RSVP. The LLC needs to: allocation to extra cell when needed. An example of decentralized
algorithm is provided in [tinka10decentralized]. This mechanism can
be used to establish multi-hop paths in a fashion similar to RSVP.
The LLC needs to:
1. Provide a mechanism for two 6TiSCH devices to negotiate the 1. Provide a mechanism for two 6TiSCH devices to negotiate the
allocation and deallocation of cells between them. allocation and deallocation of cells between them.
2. Provide a mechanism for device to monitor and manage the 6TiSCH 2. Provide a mechanism for device to monitor and manage the 6TiSCH
capabilities of a node several hops away. capabilities of a node several hops away.
3. Define an mechanism for these different scheduling mechanisms to 3. Define an mechanism for these different scheduling mechanisms to
coexist in the same network. coexist in the same network.
skipping to change at page 10, line 7 skipping to change at page 10, line 11
This memo is an informational overview of existing standards, and This memo is an informational overview of existing standards, and
does define any new mechanisms or protocols. does define any new mechanisms or protocols.
It does describe the need for the 6TiSCH WG to define a secure It does describe the need for the 6TiSCH WG to define a secure
solution. In particular, Section 4.1 describes security in the join solution. In particular, Section 4.1 describes security in the join
process. Section 4.9 discusses data frame protection. process. Section 4.9 discusses data frame protection.
7. Acknowledgments 7. Acknowledgments
Special thanks to Jonathan Simon for his review and valuable Special thanks to Dominique Barthel, Patricia Brett, Guillaume
comments. Thanks to Guillaume Gaillard and Dominique Barthel for Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon,
their in-depth review. Thanks to the IoT6 European Project (STREP) Rene Struik, Xavi Vilajosana for reviewing the document and providing
of the 7th Framework Program (Grant 288445). valuable feedback. Thanks to the IoT6 European Project (STREP) of
the 7th Framework Program (Grant 288445).
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
skipping to change at page 10, line 35 skipping to change at page 10, line 40
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228, May 2014.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 2014. Lossy Networks", RFC 7102, January 2014.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", RFC Wireless Personal Area Network (6LoWPAN) Routing", RFC
6606, May 2012. 6606, May 2012.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. September 2011.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
skipping to change at page 11, line 37 skipping to change at page 11, line 37
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[I-D.ietf-6tisch-6top-interface]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top) Interface", draft-ietf-6tisch-
6top-interface-02 (work in progress), October 2014.
[I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An
Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-04 (work in
progress), October 2014.
[I-D.ietf-6tisch-coap]
Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
Interaction using CoAP", draft-ietf-6tisch-coap-02 (work
in progress), December 2014.
[I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-04 (work in
progress), November 2014.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-02 (work in 802.15.4e", draft-ietf-6tisch-terminology-02 (work in
progress), July 2014. progress), July 2014.
[I-D.wang-6tisch-6top-sublayer] [I-D.wang-6tisch-6top-sublayer]
Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
Operation Sublayer (6top)", draft-wang-6tisch-6top- Operation Sublayer (6top)", draft-wang-6tisch-6top-
sublayer-01 (work in progress), July 2014. sublayer-01 (work in progress), July 2014.
[I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-02 (work in
progress), September 2013.
[I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in
progress), March 2010.
[I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress),
December 2011.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terms used in Routing for Low power And
Lossy Networks", draft-ietf-roll-terminology-13 (work in
progress), October 2013.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17
(work in progress), March 2013.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-11 (work in progress), November 2014.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-03 (work in progress), February
2013.
[I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Cragie, "Security Bootstrapping Solution for Resource-
Constrained Devices", draft-sarikaya-core-
sbootstrapping-04 (work in progress), April 2012.
[I-D.gilger-smart-object-security-workshop]
Gilger, J. and H. Tschofenig, "Report from the 'Smart
Object Security Workshop', 23rd March 2012, Paris,
France", draft-gilger-smart-object-security-workshop-00
(work in progress), October 2012.
[I-D.phinney-roll-rpl-industrial-applicability] [I-D.phinney-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-phinney-roll- applicability in industrial networks", draft-phinney-roll-
rpl-industrial-applicability-02 (work in progress), rpl-industrial-applicability-02 (work in progress),
February 2013. February 2013.
8.3. External Informative References 8.3. External Informative References
[IEEE802154e] [IEEE802154e]
IEEE standard for Information Technology, "IEEE std. IEEE standard for Information Technology, "IEEE std.
skipping to change at page 14, line 36 skipping to change at page 13, line 13
publications/2008/TSMP%20DSN08.pdf>. publications/2008/TSMP%20DSN08.pdf>.
[watteyne09reliability] [watteyne09reliability]
Watteyne, T., Mehta, A., and K. Pister, "Reliability Watteyne, T., Mehta, A., and K. Pister, "Reliability
Through Frequency Diversity: Why Channel Hopping Makes Through Frequency Diversity: Why Channel Hopping Makes
Sense", International Conference on Performance Evaluation Sense", International Conference on Performance Evaluation
of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE- of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-
WASUN) 2009, Oct. 2009, <http://www.ietf.org/mail- WASUN) 2009, Oct. 2009, <http://www.ietf.org/mail-
archive/web/roll/current/pdfa_EzmuDIv3.pdf>. archive/web/roll/current/pdfa_EzmuDIv3.pdf>.
[kerkez09feasibility]
Kerkez, B., Watteyne, T., and M. Magliocco, "Feasibility
analysis of controller design for adaptive channel
hopping", International Workshop on Performance
Methodologies and Tools for Wireless Sensor Networks
(WSNPERF) 2009, Oct. 2009, <http://www-
bsac.eecs.berkeley.edu/publications/search/
send_publication_pdf2client.php?pubID=1249681245>.
[TASA-PIMRC] [TASA-PIMRC]
Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
and G. Boggia, "Traffic Aware Scheduling Algorithm for and G. Boggia, "Traffic Aware Scheduling Algorithm for
Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept. Multi-Hop IEEE 802.15.4e Networks", IEEE PIMRC 2012, Sept.
2012, < http://www.cttc.es/resources/ 2012, < http://www.cttc.es/resources/
doc/120531-submitted-tasa-25511.pdf>. doc/120531-submitted-tasa-25511.pdf>.
[TASA-SENSORS]
Palattella, MR., Accettura, N., Dohler, M., Grieco, LA.,
and G. Boggia, "Traffic-Aware Time-Critical Scheduling In
Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT",
IEEE SENSORS 2012, Oct. 2012, <
http://www.cttc.es/resources/
doc/120821-sensors2012-4396981770946977737.pdf>.
[TASA-WCNC]
Accettura, N., Palattella, MR., Dohler, M., Grieco, LA.,
and G. Boggia, "Standardized Power-Efficient and Internet-
Enabled Communication Stack for Capillary M2M Networks",
IEEE WCNC 2012, Apr. 2012, < http://www.cttc.es/resources/
doc/120109-1569521283-submitted-58230.pdf>.
[palattella12standardized] [palattella12standardized]
Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, Palattella, MR., Accettura, N., Vilajosana, X., Watteyne,
T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized
Protocol Stack For The Internet Of (Important) Things", Protocol Stack For The Internet Of (Important) Things",
IEEE Communications Surveys and Tutorials 2012, Dec. 2012, IEEE Communications Surveys and Tutorials 2012, Dec. 2012,
< http://www.cttc.es/resources/doc/121025- < http://www.cttc.es/resources/doc/121025-
completestackforiot-clean-4818610916636121981.pdf>. completestackforiot-clean-4818610916636121981.pdf>.
[PANA] Kanda, M., Ohba, Y., Das, S., and S. Chasko, "PANA
applicability in constrained environments", Febr. 2012, <h
ttp://www.lix.polytechnique.fr/hipercom/SmartObjectSecurit
y/papers/MitsuruKanda.pdf>.
Appendix A. TSCH Protocol Highlights Appendix A. TSCH Protocol Highlights
This appendix gives an overview of the key features of the This appendix gives an overview of the key features of the
IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes IEEE802.15.4e Timeslotted Channel Hopping (TSCH) amendment. It makes
no attempt at repeating the standard, but rather focuses on the no attempt at repeating the standard, but rather focuses on the
following: following:
o Concepts which are sufficiently different from traditional o Concepts which are sufficiently different from traditional
IEEE802.15.4 networking that they may need to be defined and IEEE802.15.4 networking that they may need to be defined and
presented precisely. presented precisely.
skipping to change at page 18, line 31 skipping to change at page 16, line 31
schedule for that scheduled cell, and the same ASN counter, they schedule for that scheduled cell, and the same ASN counter, they
compute the same frequency. At the next iteration (cycle) of the compute the same frequency. At the next iteration (cycle) of the
slotframe, however, while the channelOffset is the same, the ASN has slotframe, however, while the channelOffset is the same, the ASN has
changed, resulting in the computation of a different frequency. changed, resulting in the computation of a different frequency.
This results in "channel hopping": even with a static schedule, pairs This results in "channel hopping": even with a static schedule, pairs
of neighbors "hop" between the different frequencies when of neighbors "hop" between the different frequencies when
communicating. A way of ensuring communication happens on all communicating. A way of ensuring communication happens on all
available frequencies is to set the number of timeslots in a available frequencies is to set the number of timeslots in a
slotframe to a prime number. Channel hopping is a technique known to slotframe to a prime number. Channel hopping is a technique known to
efficiently combat multi-path fading and external interference. efficiently combat multi-path fading and external interference
[watteyne09reliability].
A.8. Time Synchronization A.8. Time Synchronization
Because of the slotted nature of communication in a TSCH network, Because of the slotted nature of communication in a TSCH network,
nodes have to maintain tight synchronization. All nodes are assumed nodes have to maintain tight synchronization. All nodes are assumed
to be equipped with clocks to keep track of time. Yet, because to be equipped with clocks to keep track of time. Yet, because
clocks in different nodes drift with respect to one another, neighbor clocks in different nodes drift with respect to one another, neighbor
nodes need to periodically re-synchronize. nodes need to periodically re-synchronize.
Each node needs to periodically synchronize its network clock to Each node needs to periodically synchronize its network clock to
 End of changes. 15 change blocks. 
140 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/