vilajosana196TiSCH

Goal

The goal of this work is designing a protocol to bridge the performance of industrial solutions with IP-compliant networks. This protocol is 6TiSCH, a set of specifications that define the IPv6 control plane to manage and orchestrate a TSCH network.

Paper organization

1. 6TiSCH standardization process and related activities

2. Background on the TSCH mode of the IEEE 802.15.4 standard

3. 6TiSCH bootstrap process

4. 6TiSCH wireless medium management through scheduling

5. Lightweight security approach developed to minimize communication and implementation overhead

6. How 6TiSCH is built with extensibility in mind

7. Key performance indicators of the reference implementation

8. Overview of the ecosystem of tools developed by the 6TiSCH community and standardization contributors

Introduction

• Using wireless in an industrial context is challenging due to the harsh environmental conditions, where interference and fading cause any wireless connection to be inherently unreliable. Deploying devices whose batteries would need to be replaced often is inconvenient from the practical aspect, as well. To address these challenges, a set of industrial communication products and standards was developed, all relying on the concept of time-slotted channel hopping (TSCH).

• TSCH was adopted by the IEEE as a medium access control (MAC) technique in the IEEE 802.15.4 standard.

• TSCH-based networks have proven to yield over 99.999% end-to-end reliability, supporting flow isolation and QoS management while ensuring over a decade of battery lifetime.

• Standards such as WirelessHART and ISA100.11a relied on TSCH but did not consider IP compliance or standardized network management and resource orchestration as a must.

• Open

  

  6TiSCH WG has produced a set of IP-compliant
  specifications that manage the underlying IEEE 802.15.4 TSCH MAC layer and enable the integration with other IETF solutions targeting IoT applications.

Highlights

• 6TiSCH builds on IPv6 by design: industrial networks using 6TiSCH seamlessly integrate into the Internet architecture, without the need to bridge or handle protocol translation at the application layer.

• 6TiSCH fully enables the vision of a “cloudified” industry, where sensor and actuator devices connect to cloud-based SCADA systems.

• Time-Slotted Channel Hoping:

  • TSCH is essentially a combination of time-division and frequency-division multiple access (TDMA/FDMA).

  • TSCH splits time into timeslots, multiple timeslots are grouped into a slotframe structure that repeats over time. The schedule defines to a node how each timeslot within a slotframe is used.

  • The IEEE 802.15.4 specification defines how the schedule is executed but it does not define how it is
    built or signaled between network entities. WirelessHART and ISA100.11a build the schedule in a centralized manner. However, 6TiSCH specifications build the schedule in a fully distributed manner, integrating the signaling into the management plane.

  • The component in the 6TiSCH architecture that is in charge of dynamically adapting the schedule is called a scheduling function (SF). The schedule can be represented as an m × n matrix, where m is the length of the slotframe in timeslots, and n is the number of available channels to hop. An element in the schedule matrix is called a cell, which is uniquely identified by the (timeslot offset, channel offset) pair.

• The IEEE 802.15.4 standard includes a large set of configuration options. To facilitate interoperable network formation, a “minimal profile” standardized in the Request for Comments (RFC)8180 defines a common schedule used for bootstrap and the control plane traffic. This minimal schedule consists of a single shared cell, used both for transmissions and receptions in a slotted Aloha manner.

• To maintain the synchronization, the IEEE 802.15.4 standard defines that each node has its “time-source neighbor” that acts as its time reference. A routing parent of a node is also its time source neighbor, with one node in the network acting as the root.

• Scheduling functionality in 6TiSCH is handled by two components: the 6TiSCH Operation Sublayer (6top) Protocol (6P) and the SF:

  • 6top Protocol

    • 6P is a pairwise negotiation protocol that enables two radio neighbor nodes to allocate cells in their schedules for communication.

    • Transactions occur in a two-step exchange or a three-step message exchange between nodes.

    • 6P detects possible inconsistencies based on the sequence numbers and a set of timeouts.

    • 6P messages are carried directly over IEEE 802.15.4 frames. They are encapsulated in a generic structure called information element (IE).

  • Minimal Scheduling Function (MSF)

    • The 6TiSCH vision is to support different types of traffic and application needs by making the cell allocation policy a separate module in the communication stack. This module is called an SF and it is in charge of driving 6P according to the application needs. There are numerous SF proposals.

    • 6TiSCH WG standardizes the minimal SF (MSF). MSF defines two types of cells to be installed: autonomous cells (not requiring 6P transactions) and managed cells (using 6P).

  • The interaction of MSF and 6P is handled through a programmatic interface not defined by the IETF as it depends on the particular stack implementation.

• Existing industrial automation solutions such as WirelessHART and ISA100.11a build on top of the MAC-layer security features provided by the IEEE 802.15.4 standard. The assumption behind the design of the IEEE 802.15.4 security module is that cryptographic keys are already in place for all the nodes in the network. To communicate securely, TLS is typically used as an umbrella solution for authenticated key agreement and to provide confidentiality, authenticity, and replay protection of the secure channel.

• WirelessHART and ISA100.11a defined custom security protocols and data formats to provide more efficient solutions and to enable secure end-to-end communications. While admittedly very efficient, these industrial solutions do not integrate with the existing Internet infrastructure.

• 6TiSCH adopts object security as a basic primitive to design a secure and efficient communication stack. The use of a single primitive to carry all security-related components of the communication stack enables major savings in terms of the code footprint.

• In order to efficiently solve the problems of network access authentication and key distribution, the 6TiSCH WG produced the “minimal security framework for 6TiSCH” specification. The specification defines the Constrained Join Protocol (CoJP) that is used by the pledge to request admission into the network and, if the request is granted, for the join registrar/coordinator (JRC), who plays the role of the AAA server, to configure the pledge with the network parameters. Pledge uses one of its radio neighbors that are already part of the network, called a join proxy (JP), to reach the JRC.

• The pledge joins the network using CoJP in a single round-trip exchange with no fragmentation required. In comparison, it takes EAP-TLS 16 messages to complete the network access exchange.

• CoJP can be used in two deployments options that differ in the provisioning and the type of the security credentials used for network access authentication: One-Touch and Zero-Touch Credential Provisioning. With both options, CoJP exchanges are secured by a mechanism called object security for constrained RESTful environments (OSCORE).

• OSCORE encapsulates the application message and certain fields of the protocol header in a secure object, providing confidentiality, authenticity, and replay protection. Based on a secret shared between the communicating endpoints, OSCORE derives a security context, a set of parameters needed to keep the secure channel alive.

• Since OSCORE is already a mandatory component of CoJP, the application developers can reuse the same implementation for communication security, resulting in lower effort and code footprint savings.

• The network time protocol (NTP) and IEEE 1588 have not been designed to be transported in small frames, making them unsuitable for IEEE 802.15.4. 6TiSCH takes advantage of the synchronized nature of the underlying TSCH and enables nodes to share a common base of time. Through a simple protocol extension, a 6TiSCH network can be augmented with the global time information at a relatively small cost.

• Mainly due to the IPv6 nature of the 6TiSCH architecture, bridging or application layer packet handling is not needed at the routers, while flow isolation is natively supported by the IP infrastructure through the DSCP IPv6 header field.

• The OpenTestbed is an open-source testbed solution developed by the Open-WSN community, building upon the previous Rover project.

• 6TiSCH open data action (SODA) project develops the tools that automate the performance benchmarking of 6TiSCH implementations on testbeds and facilitate reproducible and repeatable research. SODA also aims at providing reference performance data sets of 6TiSCH in industry relevant test scenarios.

New terms

• TSCH (Time-Slotted Channel Hoping)

• SCADA (Supervisory Control And Data Acquisition) is a control system architecture comprising computers, networked data communications and graphical user interfaces for high-level supervision of machines and processes

• WirelessHART (wireless highway addressable remote transducer)

• PDR (packet delivery ratio)

• OSCORE (object security for constrained RESTful environments)

Review

Open

Important topics to read about

1. a more detailed version explaining the 6TiSCH https://datatracker.ietf.org/doc/rfc9030/

2. Constrained join protocol (CoJP) https://datatracker.ietf.org/doc/rfc9031/

3. the concept of object security https://www.sciencedirect.com/science/article/pii/S1570870514003126

4. Object security for constrained RESTful environments (OSCORE) https://datatracker.ietf.org/doc/rfc8613/

5. Extensible Authentication Protocol (EAP) https://datatracker.ietf.org/doc/rfc3748/