One document matched: draft-wang-6tisch-track-use-cases-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="std" docName="draft-wang-6tisch-track-use-cases-00" ipr="trust200902">
<front>
<title abbrev="6tisch-track-use-cases">Use Cases and Requirements for using Track in 6TiSCH Networks</title>
<author initials="Z." surname="Chen" fullname="Zhuo Chen">
<organization>InterDigital Communications, LLC</organization>
<address>
<postal>
<street>781 Third Ave</street>
<city>King of Prussia</city>
<region>PA</region>
<code>19406</code>
<country>USA</country>
</postal>
<phone>+1 610 878 5730</phone>
<email>Zhuo.Chen@InterDigital.com</email>
</address>
</author>
<author initials="C." surname="Wang" fullname="Chonggang Wang">
<organization>InterDigital Communications, LLC</organization>
<address>
<postal>
<street>781 Third Ave</street>
<city>King of Prussia</city>
<region>PA</region>
<code>19406</code>
<country>USA</country>
</postal>
<phone>+1 610 878 5831</phone>
<email>Chonggang.Wang@InterDigital.com</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<keyword>6TiSCH</keyword>
<keyword>Track use cases</keyword>
<abstract>
<t>
This document further analyzes the 6TiSCH requirements related to Track
through the use of examples and use cases. The goal of this document is
to trigger discussions in 6TiSCH working group so that all relevant
considerations are take into account when design Track reservation schemes in 6TiSCH.
</t>
</abstract>
<note title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
IEEE802.15.4e <xref target="IEEE802154e"/> was published in 2012 as an amendment to
the Medium Access Control (MAC) protocol defined by the IEEE802.15.4-2011 <xref target="IEEE802154"/>
standard. IEEE802.15.4e will be rolled into the next revision of IEEE802.15.4, scheduled
to be published in 2015. The Timeslotted Channel Hopping (TSCH) mode of IEEE802.15.4e is
the object of this document. The 6TiSCH working group is chartered to enable IPv6 over
the TSCH mode of the IEEE802.15.4e standard.
</t>
<t>
The requirements for 6TiSCH are well documented <xref target="I-D.ietf-6tisch-tsch"/>. Initially, the WG will limit its scope to distributed routing over a static schedule. In this draft, we focus and expand discussions pertaining to Track. We propose requirements and use cases for different type of Track reservation schemes.
</t>
</section>
<section title="Terms used in this document">
<t>
The draft uses terminologies defined in <xref target="I-D.ietf-6tisch-terminology"/>. The following are definition of terminologies used in this draft.
</t>
<t>
Centralized Track reservation: The reservation of a track done by the central controller of the network, e.g. PCE.
</t>
<t>
Distributed Track reservation: A reservation of a track done by one or more in-network entities (typically a connection endpoint).
</t>
<t>
Track: A determined sequence of cells along a multi-hop path. It is typically the result of a reservation. The node that initializes the process for establishing a Track is the owner of the track. The latter assigns a unique identifier to the Track, called TrackID
</t>
</section>
<section title="Use Cases: Industrial Networks">
<t>
An industry network is a good use case for a 6TiSCH network. In an industry network as shown in <xref target='figUsecases'/>, many devices are LLN devices, e.g. sensors and actuators. There are many types of applications in an industry network, such as industry process control and automation applications, e.g. an automation assembly line, and industry monitor applications, e.g. a safety monitoring application.
</t>
<section title="Industry process control and automation applications">
<t>
In an industry process control and automation application as shown in <xref target='figUsecases'/>, LLN Devices are actuator and sensors in an automation assemble line. An LLN Device, for example LLN Device 1, MAY periodically send signalling packets to another actuator, e.g. LLN Device 2. For example, LLN Device 1 locate at the step 1 of the automation assemble line, whenever it finishes a task, it will send singling packets to LLN Device 2 located at the step 2 of the automation assemble line to trigger the next action in the automation assembly line. The delay of these packets are extremely important for the performance of the automation assembly line. Also the reliability of these signalling packets are extremely important since a packet loss may result products with defects. Reserving a Track between LLN device 1 and LLN device 2 can not only guarantee the delay of these signalling packets but also improve the reliability of these packet due to less interference. Moreover, by reserving a Track, battery powered LLN Devices are able to wake up and sleep based on its TSCH schedule to save energy. In these cases, the Tracks reserved are deterministic, unless the topology of the network changes.
</t>
</section>
<section title="Industrial monitoring applications">
<t>
In an industrial monitoring application, sensors such as LLN 1 and 2, monitor the status of each machine or plant and send data to the Control Controller as shown in <xref target='figUsecases'/>. An LLN Device, for example LLN Device 1, MAY detect a critical event, and sends a signalling emergency message to the Central Controller in the network. After that the LLN Device may send monitoring data to the Central Controller. The singling packets that contains an emergency message SHOULD arrive at the Central Controller with minimum delay and highest reliability. Therefore, multiple Tacks may be reserved between these sensors and the Central Controller. Moreover, a bursty traffic that contains monitoring data MAY follow the critical message. These data packets also require low latency and high reliability, thus a high bandwidth Track SHOULD be quickly set-up between these LLN Devices and the Central Controller. Therefore, the Track reservation scheme has to react faster in a more dynamic way.
</t>
<t>
<figure anchor='figUsecases' suppress-title='false' title="Use Case of an Industry Network">
<artwork><![CDATA[
---+-------- ............ ------------
| External Network |
| +-----+
| +-----+ | NME |
+-----+ | +-----+ | |
| | Central | | PCE | +-----+
| | Controller +--| |
+-----+ +-----+
| |
| 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 Device 1 o o LLN Device 2 o
o o o o o o o o o o o o
]]></artwork>
</figure>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
<t>
</t>
</section>
</section>
<section title="Handling Tracks in 6TiSCH Networks">
<section title="General Behavior of Tracks">
<t>
In this section, we discuss the behavior and the benefits of Tracks. As discussed in <xref target="I-D.ietf-6tisch-architecture"/>, Track is first a multi-hop paths from the source LLN Device to the destination LLN Device. Second, some resources of LLN Devices on the path are reserved by configuring their TSCH schedule. Therefore, an LLN Device on the Track not only knows what cells it should use to receive packets from its previous hop, but also knows what cells it should use to send packets to its next hop. There are several benefits for using Track to forward a packet from the source LLN Device to the destination LLN Device.
</t>
<t>
First, Track forwarding as described in Section 10.1 in <xref target="I-D.ietf-6tisch-architecture"/> is a layer-2 forwarding scheme, which introduces less process delay and overhead than layer-3 forwarding scheme. Therefore, LLN Devices can save more energy and resource, which is critical for resource constrained devices.
</t>
<t>
Second, since channel resources, i.e. cells, have been reserved for communications between LLN devices of each hop on the Track, the packets traverse along the Track as a train passes each stations along the rail track. Therefore, the throughput and delay of the traffic on a Track is guaranteed and the jitter of the traffic is small. These are extremely important features for time-sensitive applications, which require packets arrives on time.
</t>
<t>
Third, by knowing the scheduled time slots of incoming cell and outgoing cell, LLN devices on a Track could save more energy by staying in sleep state during in-active slots. This is extreme important for LLN Devices that are battery powered.
</t>
<t>
Fourth, by allocating scheduled channel frequency, both inter-Track and intra-Track interference can be reduced. This will enhance the reliability of transmissions on a Track and reduce energy consumption of LLN Devices by decreasing the number of retransmissions.
</t>
</section>
<section title="Track Reservation">
<t>
Cells along a Track have to be reserved before any packet transmissions. How to efficiently allocate resources along a Track becomes a challenging problem. Generally, there are both remote Track management and hop-by-hop Track management described in <xref target="I-D.ietf-6tisch-architecture"/> to solve the Track reservation issue.
</t>
<section title="Remote Track Management">
<t>
In the remote Track management scheme in section 9.3 in <xref target="I-D.ietf-6tisch-architecture"/>, a central controller of the network, e.g. Path Computation Element (PCE) in <xref target='figUsecases'/>, can allocate hard cells of LLN Devices on a Track remotely. The network may be globally optimized by the central controller of the network.
</t>
</section>
<section title="Hop-by-hop Track Management">
<t>
In the hop-by-hop Track management scheme in section 9.4 in <xref target="I-D.ietf-6tisch-architecture"/>, LLN Devices can negotiate and reserve Soft Cells in their TSCH Schedule by communicating with each other. By configuring the TSCH Schedule of LLN Devices on a route, a Track can be reserved to enhance the multi-hop communications between the source and the destination. The hop-by-hop Track management schemes may be more scalable and robust than the remote Track management scheme since it does not rely on the central controller of the network.
</t>
</section>
</section>
</section>
<section title="Requirement for Track reservation schemes">
<t>
The track reservation schemes are required to support both deterministic traffics such as periodical transmissions for industry process control and automation applications and dynamic traffics such as bursty transmissions for industrial monitoring applications.
</t>
<section title="Centralized Track reservation">
<t>
Need a protocol for LLN devices to report their topology and TSCH schedule information to the central controller as shown in Figure 1. The central controller need the topology information to obtain a path from the source to the destination and the network can be better optimized if the central controller is aware of the TSCH schedule of all or part of LLN Devices in the network.
</t>
<t>
Need a lightweight protocol for the central controller to configure hard cells of LLN Devices using 6top interface defined in <xref target="I-D.ietf-6tisch-6top-interface"/>. The central controller has to configure hard cells of LLN Devices on the track remotely and LLN Devices are usually constrained devices which may not support heavyweight protocol such as <xref target="RFC5440">RFC 5440</xref>
</t>
</section>
<section title="Distributed Track reservation">
<t>
Need a fast reaction protocol to reserve a Track. LLN Devices have limited information about the topology of the network and the TSCH schedule of other LLN Devices on the path. The protocol should quickly detect a Track reservation failure. Need an efficient negotiation protocol between LLN Devices multi-hop away from each other. LLN Devices on the path have to negotiate in order to reserve a Track, which may bring extra overhead to constrained devices.
</t>
</section>
</section>
<section title="Conclusions">
<t>
A Track can provide low latency, guaranteed throughput and high reliable for end-to-end communications. There are many use cases that can show the benefit of using a Track, such as industry networks, home networks, structure networks, health networks and vehicular networks. Moreover, different Track reservation schemes, such as centralized and distributed schemes, need to be proposed to handle a large variety of requirements.
</t>
</section>
<section title="Security Considerations">
<t>
This draft discussed the design considerations and operations of using Track in 6TiSCH networks. It does not introduce new security threats.
</t>
</section>
<section title="IANA Considerations">
<t>
This specification does not require IANA action.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- 6TiSCH -->
<!-- others -->
<?rfc include="reference.RFC.2119"?> <!-- Key words for use in RFCs to Indicate Requirement Levels -->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5440"?> <!-- Path Computation Element (PCE) Communication Protocol (PCEP) -->
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<?rfc include='reference.I-D.ietf-6tisch-tsch'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-6top-interface'?>
</references>
<references title="External Informative References">
<reference anchor="IEEE802154e">
<front>
<title>IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="IEEE802154">
<front>
<title>IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="June" year="2011"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:26:04 |