5.  Wireless for Industrial Applications

5.1.  Use Case Description

   Wireless networks are useful for industrial applications -- for
   example, (1) when portable, fast-moving, or rotating objects are
   involved and (2) for the resource-constrained devices found in the
   Internet of Things (IoT).

   Such network-connected sensors, actuators, control loops, etc.
   typically require that the underlying network support real-time QoS,
   as well as such specific network properties as reliability,
   redundancy, and security.

   These networks may also contain very large numbers of devices -- for
   example, for factories, "big data" acquisition, and the IoT.  Given
   the large numbers of devices installed and the potential
   pervasiveness of the IoT, this is a huge and very cost-sensitive
   market such that small cost reductions can save large amounts of
   money.

5.1.1.  Network Convergence Using 6TiSCH

   Some wireless network technologies support real-time QoS and are thus
   useful for these kinds of networks, but others do not.

   This use case focuses on one specific wireless network technology
   that provides the required deterministic QoS: "IPv6 over the TSCH
   mode of IEEE 802.15.4e" (6TiSCH, where "TSCH" stands for
   "Time-Slotted Channel Hopping"; see [Arch-for-6TiSCH], [IEEE-802154],
   and [RFC7554]).

   There are other deterministic wireless buses and networks available
   today; however, they are incompatible with each other and with IP
   traffic (for example, see [ISA100] and [WirelessHART]).

   Thus, the primary goal of this use case is to apply 6TiSCH as a
   converged IP-based and standards-based wireless network for
   industrial applications, i.e., to replace multiple proprietary and/or
   incompatible wireless networking and wireless network management
   standards.

5.1.2.  Common Protocol Development for 6TiSCH

   Today, there are a number of protocols required by 6TiSCH that are
   still in development.  Another goal of this use case is to highlight
   the ways in which these "missing" protocols share goals in common
   with DetNet.  Thus, it is possible that some of the protocol
   technology developed for DetNet will also be applicable to 6TiSCH.

   These protocol goals are identified here, along with their
   relationship to DetNet.  It is likely that ultimately the resulting
   protocols will not be identical but will share design principles that
   contribute to the efficiency of enabling both DetNet and 6TiSCH.

   One such commonality is that -- although on a different time scale --
   in both TSN [IEEE-8021TSNTG] and TSCH, a packet that crosses the
   network from node to node follows a precise schedule, as does a train
   that leaves intermediate stations at precise times along its path.
   This kind of operation reduces collisions, saves energy, and enables
   engineering of the network for deterministic properties.

   Another commonality is remote monitoring and scheduling management of
   a TSCH network by a Path Computation Element (PCE) and Network
   Management Entity (NME).  The PCE and NME manage timeslots and device
   resources in a manner that minimizes the interaction with, and the
   load placed on, resource-constrained devices.  For example, a tiny
   IoT device may have just enough buffers to store one or a few IPv6
   packets; it will have limited bandwidth between peers such that it
   can maintain only a small amount of peer information, and it will not
   be able to store many packets waiting to be forwarded.  It is
   advantageous, then, for the IoT device to only be required to carry
   out the specific behavior assigned to it by the PCE and NME (as
   opposed to maintaining its own IP stack, for example).

   It is possible that there will be some peer-to-peer communication;
   for example, the PCE may communicate only indirectly with some
   devices in order to enable hierarchical configuration of the system.

   6TiSCH depends on [PCE] and [DetNet-Arch].

   6TiSCH also depends on the fact that DetNet will maintain consistency
   with [IEEE-8021TSNTG].

5.2.  Wireless Industrial Today

   Today, industrial wireless technology ("wireless industrial") is
   accomplished using multiple deterministic wireless networks that are
   incompatible with each other and with IP traffic.

   6TiSCH is not yet fully specified, so it cannot be used in today's
   applications.

5.3.  Wireless Industrial in the Future

5.3.1.  Unified Wireless Networks and Management

   DetNet and 6TiSCH together can enable converged transport of
   deterministic and best-effort traffic flows between real-time
   industrial devices and WANs via IP routing.  A high-level view of
   this type of basic network is shown in Figure 7.

               ---+-------- ............ ------------
                  |      External Network       |
                  |                          +-----+
               +-----+                       | NME |
               |     | LLN Border            |     |
               |     | Router                +-----+
               +-----+
             o    o   o
      o     o   o     o
         o   o LLN   o    o     o
            o   o   o       o
                    o

      LLN: Low-Power and Lossy Network

                      Figure 7: Basic 6TiSCH Network

   Figure 8 shows a backbone router federating multiple synchronized
   6TiSCH subnets into a single subnet connected to the external
   network.

                  ---+-------- ............ ------------
                     |      External Network       |
                     |                          +-----+
                     |             +-----+      | NME |
                  +-----+          |  +-----+   |     |
                  |     | Router   |  | PCE |   +-----+
                  |     |          +--|     |
                  +-----+             +-----+
                     |                   |
                     | Subnet Backbone   |
               +--------------------+------------------+
               |                    |                  |
            +-----+             +-----+             +-----+
            |     | Backbone    |     | Backbone    |     | Backbone
       o    |     | Router      |     | Router      |     | Router
            +-----+             +-----+             +-----+
       o                  o                   o                 o   o
           o    o   o         o   o  o   o         o  o   o    o
      o             o        o  LLN      o      o         o      o
         o   o    o      o      o o     o  o   o    o    o     o

                     Figure 8: Extended 6TiSCH Network

   The backbone router must ensure end-to-end deterministic behavior
   between the LLN and the backbone.  This should be accomplished in
   conformance with the work done in [DetNet-Arch] with respect to
   Layer 3 aspects of deterministic networks that span multiple Layer 2
   domains.

   The PCE must compute a deterministic path end to end across the TSCH
   network and IEEE 802.1 TSN Ethernet backbone, and DetNet protocols
   are expected to enable end-to-end deterministic forwarding.

5.3.1.1.  PCE and 6TiSCH ARQ Retries

   6TiSCH uses the Automatic Repeat reQuest (ARQ) mechanism
   [IEEE-802154] to provide higher reliability of packet delivery.  ARQ
   is related to Packet Replication and Elimination (PRE) because there
   are two independent paths for packets to arrive at the destination.
   If an expected packet does not arrive on one path, then it checks for
   the packet on the second path.

   Although to date this mechanism is only used by wireless networks,
   this technique might be appropriate for DetNet, and aspects of the
   enabling protocol could therefore be co-developed.

   For example, in Figure 9, a track is laid out from a field device in
   a 6TiSCH network to an IoT gateway that is located on an IEEE 802.1
   TSN backbone.

                     +-----+
                     | IoT |
                     | G/W |
                     +-----+
                        ^  <---- Elimination
                       | |
        Track Branch   | |
               +-------+ +--------+ Subnet Backbone
               |                  |
            +--|--+            +--|--+
            |  |  | Backbone   |  |  | Backbone
       o    |  |  | Router     |  |  | Router
            +--/--+            +--|--+
       o     /    o     o---o----/       o
           o    o---o--/   o      o   o  o   o
      o     \  /     o               o   LLN    o
         o   v  <---- Replication
             o

                     Figure 9: 6TiSCH Network with PRE

   In ARQ, the replication function in the field device sends a copy of
   each packet over two different branches, and the PCE schedules each
   hop of both branches so that the two copies arrive in due time at the
   gateway.  In the case of a loss on one branch, one hopes that the
   other copy of the packet will still arrive within the allocated time.
   If two copies make it to the IoT gateway, the elimination function in
   the gateway ignores the extra packet and presents only one copy to
   upper layers.

   At each 6TiSCH hop along the track, the PCE may schedule more than
   one timeslot for a packet, so as to support Layer 2 retries (ARQ).

   At the time of this writing, a deployment's TSCH track does not
   necessarily support PRE but is systematically multipath.  This means
   that a track is scheduled so as to ensure that each hop has at least
   two forwarding solutions.  The forwarding decision will be to try the
   preferred solution and use the other solution in the case of Layer 2
   transmission failure as detected by ARQ.

5.3.2.  Schedule Management by a PCE

   A common feature of 6TiSCH and DetNet is actions taken by a PCE when
   configuring paths through the network.  Specifically, what is needed
   is a protocol and data model that the PCE will use to get/set the
   relevant configuration from/to the devices, as well as perform
   operations on the devices.  Specifically, both DetNet and 6TiSCH need
   to develop a protocol (and associated data model) that the PCE can
   use to (1) get/set the relevant configuration from/to the devices and
   (2) perform operations on the devices.  These could be initially
   developed by DetNet, with consideration for their reuse by 6TiSCH.
   The remainder of this section provides a bit more context from the
   6TiSCH side.

5.3.2.1.  PCE Commands and 6TiSCH CoAP Requests

   The 6TiSCH device does not expect to place the request for bandwidth
   between itself and another device in the network.  Rather, an
   operation control system invoked through a human interface specifies
   the traffic requirements and the end nodes (in terms of latency and
   reliability).  Based on this information, the PCE must compute a path
   between the end nodes and provision the network with per-flow state
   that describes the per-hop operation for a given packet, the
   corresponding timeslots, the flow identification that enables
   recognizing that a certain packet belongs to a certain path, etc.

   For a static configuration that serves a certain purpose for a long
   period of time, it is expected that a node will be provisioned in one
   shot with a full schedule, i.e., a schedule that defines the behavior

   of the node with respect to all data flows through that node. 6TiSCH
   expects that the programming of the schedule will be done over the
   Constrained Application Protocol (CoAP) as discussed in
   [CoAP-6TiSCH].

   6TiSCH expects that the PCE commands will be mapped back and forth
   into CoAP by a gateway function at the edge of the 6TiSCH network.
   For instance, it is possible that a mapping entity on the backbone
   transforms a non-CoAP protocol such as the Path Computation Element
   Communication Protocol (PCEP) into the RESTful interfaces that the
   6TiSCH devices support.  This architecture will be refined to comply
   with DetNet [DetNet-Arch] when the work is formalized.  Related
   information about 6TiSCH can be found in [Interface-6TiSCH-6top] and
   [RFC6550] ("RPL: IPv6 Routing Protocol for Low-Power and Lossy
   Networks").

   A protocol may be used to update the state in the devices during
   runtime -- for example, if it appears that a path through the network
   has ceased to perform as expected, but in 6TiSCH that flow was not
   designed and no protocol was selected.  DetNet should define the
   appropriate end-to-end protocols to be used in that case.  The
   implication is that these state updates take place once the system is
   configured and running, i.e., they are not limited to the initial
   communication of the configuration of the system.

   A "slotFrame" is the base object that a PCE would manipulate to
   program a schedule into an LLN node [Arch-for-6TiSCH].

   The PCE should read energy data from devices and compute paths that
   will implement policies on how energy in devices is consumed -- for
   instance, to ensure that the spent energy does not exceed the
   available energy over a period of time.  Note that this statement
   implies that an extensible protocol for communicating device
   information to the PCE and enabling the PCE to act on it will be part
   of the DetNet architecture; however, for subnets with specific
   protocols (e.g., CoAP), a gateway may be required.

   6TiSCH devices can discover their neighbors over the radio using a
   mechanism such as beacons, but even though the neighbor information
   is available in the 6TiSCH interface data model, 6TiSCH does not
   describe a protocol to proactively push the neighbor information to a
   PCE.  DetNet should define such a protocol; one possible design
   alternative is that it could operate over CoAP.  Alternatively, it
   could be converted to/from CoAP by a gateway.  Such a protocol could
   carry multiple metrics -- for example, metrics similar to those used
   for RPL operations [RFC6551].

5.3.2.2.  6TiSCH IP Interface

   Protocol translation between the TSCH MAC layer and IP is
   accomplished via the "6top" sublayer [Sublayer-6TiSCH-6top].  The
   6top data model and management interfaces are further discussed in
   [Interface-6TiSCH-6top] and [CoAP-6TiSCH].

   An IP packet that is sent along a 6TiSCH path uses a differentiated
   services Per-Hop Behavior Group (PHB) called "deterministic
   forwarding", as described in [Det-Fwd-PHB].

5.3.3.  6TiSCH Security Considerations

   In addition to the classical requirements for protection of control
   signaling, it must be noted that 6TiSCH networks operate on limited
   resources that can be depleted rapidly in a DoS attack on the system
   -- for instance, by placing a rogue device in the network or by
   obtaining management control and setting up unexpected additional
   paths.

5.4.  Wireless Industrial Requests to the IETF

   6TiSCH depends on DetNet to define:

   o  Configuration (state) and operations for deterministic paths

   o  End-to-end protocols for deterministic forwarding (tagging, IP)

   o  A protocol for PRE