RFC 7554 - Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7554
タイトル : RFC 7554 - モノのインターネット（IoT）でのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用：問題の説明
翻訳編集 : 自動生成

[要約] 要約： RFC 7554は、IoTにおけるIEEE 802.15.4e Time-Slotted Channel Hopping（TSCH）の問題を明確にし、解決策を提案しています。目的：このRFCの目的は、IoTデバイス間の信頼性と効率を向上させるために、TSCHの問題を特定し、解決策を提供することです。

Internet Engineering Task Force (IETF)                  T. Watteyne, Ed.
Request for Comments: 7554                             Linear Technology
Category: Informational                                    M. Palattella
ISSN: 2070-1721                                 University of Luxembourg
                                                               L. Grieco
                                                     Politecnico di Bari
                                                                May 2015

Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement

モノのインターネット（IoT）でのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用：問題の説明

Abstract

概要

This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs). The set of goals enumerated in this document form an initial set only.

このドキュメントでは、IEEE 802.14.4eのタイムスロットチャネルホッピング（TSCH）メディアアクセス制御（MAC）プロトコルを低電力および損失の多いネットワーク（LLN）のコンテキストで使用するための環境、問題ステートメント、および目標について説明します。このドキュメントに列挙されている目標のセットは、初期のセットのみを形成しています。

Status of This Memo

本文書の状態

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7554.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7554で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  TSCH in the LLN Context . . . . . . . . . . . . . . . . . . .   5
   3.  Problems and Goals  . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Network Formation . . . . . . . . . . . . . . . . . . . .   8
     3.2.  Network Maintenance . . . . . . . . . . . . . . . . . . .   8
     3.3.  Multi-Hop Topology  . . . . . . . . . . . . . . . . . . .   8
     3.4.  Routing and Timing Parents  . . . . . . . . . . . . . . .   8
     3.5.  Resource Management . . . . . . . . . . . . . . . . . . .   9
     3.6.  Dataflow Control  . . . . . . . . . . . . . . . . . . . .   9
     3.7.  Deterministic Behavior  . . . . . . . . . . . . . . . . .   9
     3.8.  Scheduling Mechanisms . . . . . . . . . . . . . . . . . .  10
     3.9.  Secure Communication  . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     5.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  TSCH Protocol Highlights . . . . . . . . . . . . . .  15
     A.1.  Time Slots  . . . . . . . . . . . . . . . . . . . . . . .  15
     A.2.  Slotframes  . . . . . . . . . . . . . . . . . . . . . . .  15
     A.3.  Node TSCH Schedule  . . . . . . . . . . . . . . . . . . .  15
     A.4.  Cells and Bundles . . . . . . . . . . . . . . . . . . . .  16
     A.5.  Dedicated vs. Shared Cells  . . . . . . . . . . . . . . .  17
     A.6.  Absolute Slot Number  . . . . . . . . . . . . . . . . . .  17
     A.7.  Channel Hopping . . . . . . . . . . . . . . . . . . . . .  17
     A.8.  Time Synchronization  . . . . . . . . . . . . . . . . . .  18
     A.9.  Power Consumption . . . . . . . . . . . . . . . . . . . .  19
     A.10. Network TSCH Schedule . . . . . . . . . . . . . . . . . .  19
     A.11. Join Process  . . . . . . . . . . . . . . . . . . . . . .  19
     A.12. Information Elements  . . . . . . . . . . . . . . . . . .  20
     A.13. Extensibility . . . . . . . . . . . . . . . . . . . . . .  20
   Appendix B.  TSCH Features  . . . . . . . . . . . . . . . . . . .  21
     B.1.  Collision-Free Communication  . . . . . . . . . . . . . .  21
     B.2.  Multi-Channel vs. Channel Hopping . . . . . . . . . . . .  21
     B.3.  Cost of (Continuous) Synchronization  . . . . . . . . . .  21
     B.4.  Topology Stability  . . . . . . . . . . . . . . . . . . .  21
     B.5.  Multiple Concurrent Slotframes  . . . . . . . . . . . . .  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1. Introduction

1. はじめに

IEEE 802.15.4e [IEEE.802.15.4e] was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE 802.15.4 standard (of 2011) [IEEE.802.15.4]. IEEE 802.15.4e will be rolled into the next revision of IEEE 802.15.4, scheduled to be published in 2015. The Time-Slotted Channel Hopping (TSCH) mode of IEEE 802.15.4e is the object of this document. The term "TSCH" refers to TSCH as used in [IEEE.802.15.4e].

IEEE 802.15.4e [IEEE.802.15.4e]は、IEEE 802.15.4標準（2011年）[IEEE.802.15.4]で定義されたメディアアクセスコントロール（MAC）プロトコルの修正版として2012年に公開されました。 IEEE 802.15.4eは、2015年に公開される予定のIEEE 802.15.4の次のリビジョンに組み込まれます。IEEE802.15.4eのタイムスロットチャネルホッピング（TSCH）モードは、このドキュメントの目的です。「TSCH」という用語は、[IEEE.802.15.4e]で使用されるTSCHを指します。

This document describes the main issues arising from the adoption of the TSCH in the LLN context, following the terminology defined in [TERMS-6TISCH]. Appendix A further gives an overview of the key features of the TSCH amendment to IEEE 802.15.4e. Appendix B details features of TSCH, which might be interesting for the work of the 6TiSCH WG.

このドキュメントでは、[TERMS-6TISCH]で定義されている用語に従い、LLNコンテキストでのTSCHの採用から生じる主な問題について説明します。付録Aはさらに、IEEE 802.15.4eに対するTSCH修正の主要な機能の概要を示しています。付録Bは、6TiSCH WGの作業にとって興味深いかもしれないTSCHの機能を詳しく説明しています。

TSCH was designed to allow IEEE 802.15.4 devices to support a wide range of applications including, but not limited to, industrial ones [IEEE.802.15.4e]. At its core is a medium access technique that uses time synchronization to achieve low-power operation and channel hopping to enable high reliability. Synchronization accuracy impacts power consumption and can vary from microseconds to milliseconds depending on the solution. This is very different from the "legacy" IEEE 802.15.4 MAC protocol and is therefore better described as a "redesign". TSCH does not amend the physical layer, i.e., it can operate on any hardware that is compliant with IEEE 802.15.4.

TSCHは、IEEE 802.15.4デバイスが産業用アプリケーションを含むがこれに限定されない幅広いアプリケーションをサポートできるように設計されました[IEEE.802.15.4e]。中核となるのは、時間同期を使用して低電力動作を実現し、チャネルホッピングを使用して高い信頼性を実現するメディアアクセス技術です。同期の精度は消費電力に影響し、ソリューションに応じてマイクロ秒からミリ秒まで変動する可能性があります。これは、「レガシー」IEEE 802.15.4 MACプロトコルとは非常に異なるため、「再設計」としてよりよく説明されています。 TSCHは物理層を修正しません。つまり、IEEE 802.15.4に準拠する任意のハードウェアで動作します。

IEEE 802.15.4e is the latest generation of ultra-lower power and reliable networking solutions for LLNs. [RFC5673] discusses industrial applications and highlights the harsh operating conditions as well as the stringent reliability, availability, and security requirements for an LLN to operate in an industrial environment. In these environments, vast deployment environments with large (metallic) equipment cause multi-path fading and interference to thwart any attempt of a single-channel solution to be reliable; the channel agility of TSCH is the key to its ultra-high reliability. Commercial networking solutions are available today in which nodes consume 10's of microamps on average [CurrentCalculator] with end-to-end packet delivery ratios over 99.999% [Doherty07channel].

IEEE 802.15.4eは、LLN向けの超低消費電力で信頼性の高いネットワーキングソリューションの最新世代です。 [RFC5673]は産業用アプリケーションについて説明しており、LLNが産業環境で動作するための厳しい動作条件と厳しい信頼性、可用性、およびセキュリティ要件を強調しています。これらの環境では、大規模な（金属）機器を備えた広大な展開環境により、マルチパスフェージングと干渉が発生し、信頼性を高めるための単一チャネルソリューションの試みが阻止されます。 TSCHのチャネルの俊敏性は、その超高信頼性の鍵です。現在、商用ネットワーキングソリューションが利用可能であり、ノードはエンドツーエンドのパケット配信率が99.999％[Doherty07channel]で、平均で数十マイクロアンペア[CurrentCalculator]を消費します。

IEEE 802.15.4e has been designed for low-power constrained devices, often called "motes". Several terms are used in the IETF to refer to those devices, including "LLN nodes" [RFC7102] and "constrained nodes" [RFC7228]. In this document, we use the generic (and shorter) term "node", used as a synonym for "LLN node", "constrained node", or "mote".

IEEE 802.15.4eは、しばしば「モート」と呼ばれる、低電力の制約のあるデバイス用に設計されています。 IELLでは、「LLNノード」[RFC7102]や「制約付きノード」[RFC7228]など、これらのデバイスを指すためにいくつかの用語が使用されています。このドキュメントでは、「LLNノード」、「制約付きノード」、または「モート」の同義語として使用される総称（およびより短い）用語「ノード」を使用します。

Enabling the LLN protocol stack to operate in industrial environments opens up new application domains for these networks. Sensors deployed in smart cities [RFC5548] will be able to be installed for years without needing battery replacement. "Umbrella" networks will interconnect smart elements from different entities in smart buildings [RFC5867]. Peel-and-stick switches will obsolete the need for costly conduits for lighting solutions in smart homes [RFC5826].

LLNプロトコルスタックを産業環境で動作できるようにすると、これらのネットワークに新しいアプリケーションドメインが開かれます。スマートシティに配置されたセンサー[RFC5548]は、バッテリーの交換を必要とせずに何年もインストールできます。「傘」ネットワークは、スマートビルディングのさまざまなエンティティからのスマートエレメントを相互接続します[RFC5867]。ピールアンドスティックスイッチは、スマートホームの照明ソリューション用の高価な導管の必要性を廃止します[RFC5826]。

TSCH focuses on the MAC layer only. This clean layering allows for TSCH to fit under an IPv6-enabled protocol stack for LLNs, running an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC6282], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. What is missing is a functional entity that is in charge of scheduling TSCH time slots for frames to be sent on. In this document, we refer to this entity as the "Logical Link Control" (LLC), bearing in mind that realizations of this entity can be of different types, including a distributed protocol or a centralized server in charge of scheduling.

TSCHはMAC層のみに焦点を当てています。このクリーンなレイヤリングにより、TSHはLLNのIPv6対応プロトコルスタックに適合し、低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）[RFC6282]を介してIPv6を実行し、低電力および損失の多いネットワーク（RPL）のIPv6ルーティングプロトコル[RFC6550]、および制約付きアプリケーションプロトコル（CoAP）[RFC7252]。欠けているのは、送信されるフレームのTSCHタイムスロットのスケジューリングを担当する機能エンティティです。このドキュメントでは、このエンティティを "Logical Link Control"（LLC）と呼んでいます。このエンティティの実現には、分散プロトコルやスケジューリングを担当する集中型サーバーなど、さまざまなタイプがあることに留意してください。

While [IEEE.802.15.4e] defines the mechanisms for a TSCH node to communicate, it does not define the policies to build and maintain the communication schedule, match that schedule to the multi-hop paths maintained by RPL, adapt the resources allocated between neighbor nodes to the data traffic flows, enforce a differentiated treatment for data generated at the application layer and signaling messages needed by 6LoWPAN and RPL to discover neighbors, react to topology changes, self-configure IP addresses, or manage keying material.

[IEEE.802.15.4e]はTSCHノードが通信するメカニズムを定義しますが、通信スケジュールを構築および維持するポリシーを定義せず、RPLが維持するマルチホップパスにそのスケジュールを一致させ、間に割り当てられたリソースを適合させますデータトラフィックフローへのネイバーノードは、アプリケーションレイヤーで生成されたデータに差別化された処理を適用し、6LoWPANとRPLがネイバーを検出し、トポロジの変更に対応し、IPアドレスを自己構成し、またはキー情報を管理するために必要なシグナリングメッセージを適用します。

In other words, TSCH is designed to allow optimizations and strong customizations, simplifying the merging of TSCH with a protocol stack based on IPv6, 6LoWPAN, and RPL.

つまり、TSCHは最適化と強力なカスタマイズを可能にするように設計されており、IPv6、6LoWPAN、およびRPLに基づくプロトコルスタックとTSCHのマージを簡素化します。

2. TSCH in the LLN Context

2. LLNコンテキストのTSCH

To map the services required by the IP layer to the services provided by the link layer, an adaptation layer is used [Palattella12standardized]. In 2007, the 6LoWPAN WG started working on specifications for transmitting IPv6 packets over IEEE 802.15.4 networks [RFC4919]. A low-power Wireless Personal Area Network (WPAN) is typically composed of a large number of battery-powered devices that are deployed at locations that are unknown a priori. Nodes form a star or a mesh topology and communicate with one another at a low datarate and using short frames. The wireless nature of the links means that they are unreliable in nature. Nodes turn off their radio interface most of the time to conserve energy. Given these features, it is clear that the adoption of IPv6 on top of a low-power WPAN is not straightforward but poses strong requirements for the optimization of this adaptation layer.

IPレイヤーで必要なサービスをリンクレイヤーで提供されるサービスにマッピングするには、アダプテーションレイヤーを使用します[Palattella12standardized]。 2007年に、6LoWPAN WGは、IEEE 802.15.4ネットワーク[RFC4919]を介してIPv6パケットを送信するための仕様に取り組み始めました。低電力のワイヤレスパーソナルエリアネットワーク（WPAN）は、通常、アプリオリに知られていない場所に展開されている多数のバッテリー駆動のデバイスで構成されています。ノードはスタートポロジまたはメッシュトポロジを形成し、短いデータレートで短いフレームを使用して相互に通信します。リンクのワイヤレスの性質は、リンクが本質的に信頼できないことを意味します。ノードは、エネルギーを節約するために、ほとんどの場合、無線インターフェースをオフにします。これらの機能を考えると、低電力WPANに加えてIPv6を採用することは簡単ではありませんが、このアダプテーションレイヤーの最適化には強い要件があります。

For instance, due to the IPv6 default minimum MTU size (1280 bytes), an unfragmented IPv6 packet is too large to fit in an IEEE 802.15.4 frame. Moreover, the overhead due to the 40-byte-long IPv6 header wastes the scarce bandwidth available at the PHY layer [RFC4944]. For these reasons, the 6LoWPAN WG has defined an effective adaptation layer [RFC6282]. Further issues encompass the autoconfiguration of IPv6 addresses [RFC2460] [RFC4862], the compliance with the recommendation on supporting link-layer subnet broadcast in shared networks [RFC3819], the reduction of routing and management overhead [RFC6606], the adoption of lightweight application protocols (or novel data encoding techniques), and the support for security mechanisms (confidentiality and integrity protection, device bootstrapping, key establishment, and management).

たとえば、IPv6のデフォルトの最小MTUサイズ（1280バイト）により、断片化されていないIPv6パケットは大きすぎてIEEE 802.15.4フレームに収まりません。さらに、40バイト長のIPv6ヘッダーによるオーバーヘッドは、PHYレイヤーで利用可能な乏しい帯域幅を浪費します[RFC4944]。これらの理由により、6LoWPAN WGは効果的なアダプテーション層[RFC6282]を定義しています。 IPv6アドレスの自動構成[RFC2460] [RFC4862]、共有ネットワークでのリンク層サブネットブロードキャストのサポートに関する推奨への準拠[RFC3819]、ルーティングと管理のオーバーヘッドの削減[RFC6606]、軽量アプリケーションの採用など、さらなる問題が含まれますプロトコル（または新しいデータエンコーディング手法）、およびセキュリティメカニズムのサポート（機密性と整合性の保護、デバイスのブートストラップ、キーの確立、および管理）。

These features can run on top of TSCH. There are, however, important issues to solve, as highlighted in Section 3.

これらの機能はTSCHの上で実行できます。ただし、セクション3で強調されているように、解決すべき重要な問題があります。

Routing issues are challenging for 6LoWPAN, given the low-power and lossy radio links, the battery-powered nodes, the multi-hop mesh topologies, and the frequent topology changes due to mobility. Successful solutions take into account the specific application requirements, along with IPv6 behavior and 6LoWPAN mechanisms [Palattella12standardized]. The ROLL WG has defined RPL in [RFC6550]. RPL can support a wide variety of link layers, including ones that are constrained, potentially lossy, or typically utilized in conjunction with host or router devices with very limited resources, as in building/home automation [RFC5867] [RFC5826], industrial environments [RFC5673], and urban applications [RFC5548]. RPL is able to quickly build up network routes, distribute routing knowledge among nodes, and adapt to a changing topology. In a typical setting, nodes are connected through multi-hop paths to a small set of root devices, which are usually responsible for data collection and coordination. For each of them, a Destination-Oriented Directed Acyclic Graph (DODAG) is created by accounting for link costs, node attributes/status information, and an Objective Function, which maps the optimization requirements of the target scenario.

6LoWPANのルーティングの問題は、低電力で損失の多い無線リンク、バッテリー駆動のノード、マルチホップメッシュトポロジ、およびモビリティによる頻繁なトポロジ変更を考えると、困難です。成功するソリューションでは、IPv6の動作と6LoWPANメカニズム[Palattella12standardized]とともに、特定のアプリケーション要件が考慮されます。 ROLL WGは[RFC6550]でRPLを定義しています。 RPLは、さまざまなリンクレイヤーをサポートできます。これには、制約のある、損失の可能性のある、または通常、ビルディング/ホームオートメーション[RFC5867] [RFC5826]のような産業環境[ RFC5673]、およびアーバンアプリケーション[RFC5548]。 RPLは、ネットワークルートをすばやく構築し、ルーティング知識をノード間で分散し、変化するトポロジに適応できます。典型的な設定では、ノードはマルチホップパスを介してルートデバイスの小さなセットに接続されます。ルートデバイスは通常、データの収集と調整を担当します。それらのそれぞれについて、リンク先コスト、ノード属性/ステータス情報、および目的のシナリオの最適化要件をマップする目的関数を考慮して、宛先指向の有向非循環グラフ（DODAG）が作成されます。

The topology is set up based on a Rank metric, which encodes the distance of each node with respect to its reference root, as specified by the Objective Function. Regardless of the way it is computed, the Rank monotonically decreases along the DODAG towards the root, building a gradient. RPL encompass different kinds of traffic and signaling information. Multipoint-to-Point (MP2P) is the dominant traffic in LLN applications. Data is routed towards nodes with some application relevance, such as the LLN gateway to the larger Internet or to the core of private IP networks. In general, these destinations are the DODAG roots and act as data collection points for distributed monitoring applications. Point-to-Multipoint (P2MP) data streams are used for actuation purposes, where messages are sent from DODAG roots to destination nodes. Point-to-Point (P2P) traffic allows communication between two devices belonging to the same LLN, such as a sensor and an actuator. A packet flows from the source to the common ancestor of those two communicating devices, then downward towards the destination. Therefore, RPL has to discover both upward routes (i.e., from nodes to DODAG roots) in order to enable MP2P and P2P flows and downward routes (i.e., from DODAG roots to nodes) to support P2MP and P2P traffic.

トポロジーは、目的関数で指定されているように、参照ルートに対する各ノードの距離をエンコードするランクメトリックに基づいて設定されます。計算方法に関係なく、ランクはDODAGに沿ってルートに向かって単調に減少し、勾配を構築します。 RPLには、さまざまな種類のトラフィックおよびシグナリング情報が含まれます。マルチポイントツーポイント（MP2P）は、LLNアプリケーションの主要なトラフィックです。データは、より大きなインターネットやプライベートIPネットワークのコアへのLLNゲートウェイなど、アプリケーションに関連するノードにルーティングされます。一般に、これらの宛先はDODAGルートであり、分散監視アプリケーションのデータ収集ポイントとして機能します。ポイントツーマルチポイント（P2MP）データストリームは、DODAGルートから宛先ノードにメッセージが送信される作動目的で使用されます。ポイントツーポイント（P2P）トラフィックにより、センサーやアクチュエーターなど、同じLLNに属する2つのデバイス間の通信が可能になります。パケットは、送信元からこれら2つの通信デバイスの共通の祖先に流れ、次に宛先に向かって流れます。したがって、RPLは、MP2PおよびP2Pフローを有効にするために上向きのルート（ノードからDODAGルートへ）と、P2MPおよびP2Pトラフィックをサポートするために下向きのルート（DODAGルートからノードへ）の両方を検出する必要があります。

Section 3 highlights the challenges that need to be addressed to use RPL on top of TSCH.

セクション3では、TSHの上でRPLを使用するために対処する必要のある課題に焦点を当てています。

Open-source initiatives have emerged around TSCH, with the OpenWSN project [OpenWSN] [OpenWSNETT] being the first open-source implementation of a standards-based protocol stack. This implementation was used as the foundation for an IP for the Smart Objects Alliance (IPSO) [IPSO] interoperability event in 2011. In the absence of a standardized scheduling mechanism for TSCH, a "slotted Aloha" schedule was used.

オープンソースイニシアチブはTSCHを中心に登場し、OpenWSNプロジェクト[OpenWSN] [OpenWSNETT]は、標準ベースのプロトコルスタックの最初のオープンソース実装です。この実装は、2011年のスマートオブジェクトアライアンス（IPSO）[IPSO]相互運用イベントのIPの基盤として使用されました。TSCHの標準化されたスケジューリングメカニズムがない場合、「スロットアロハ」スケジュールが使用されました。

3. Problems and Goals

3. 問題と目標

As highlighted in Appendix A, TSCH differs from other low-power MAC protocols because of its scheduled nature. TSCH defines the mechanisms to execute a communication schedule; yet, it is the entity that sets up the schedule that controls the topology of the network. This scheduling entity also controls the resources allocated to each link in that topology.

付録Aで強調されているように、TSCHはそのスケジュールされた性質のため、他の低電力MACプロトコルとは異なります。 TSCHは、通信スケジュールを実行するメカニズムを定義します。それでも、ネットワークのトポロジを制御するのは、スケジュールを設定するエンティティです。このスケジューリングエンティティは、そのトポロジの各リンクに割り当てられるリソースも制御します。

How this entity should operate is out of scope of TSCH. The remainder of this section highlights the problems this entity needs to address. For simplicity, we refer to this entity by the generic name "LLC". Note that the 6top sublayer, currently being defined in [SUBLAYER-6top], can be seen as an embodiment of this generic "LLC".

このエンティティの動作方法はTSCHの範囲外です。このセクションの残りの部分では、このエンティティが対処する必要がある問題について説明します。簡単にするために、このエンティティを総称名「LLC」で参照します。現在[SUBLAYER-6top]で定義されている6topサブレイヤーは、この一般的な「LLC」の実施形態と見なすことができます。

Some of the issues the LLC needs to target might overlap with the scope of other protocols (e.g., 6LoWPAN, RPL, and RSVP). In this case, the LLC will profit from the services provided by other protocols to pursue these objectives.

LLCが対象とする必要のある問題の一部は、他のプロトコルのスコープと重複する場合があります（6LoWPAN、RPL、RSVPなど）。この場合、LLCはこれらの目的を追求するために他のプロトコルによって提供されるサービスから利益を得るでしょう。

3.1. Network Formation

3.1. ネットワーク形成

The LLC needs to control the way the network is formed, including how new nodes join and how already joined nodes advertise the presence of the network. The LLC needs to:

LLCは、新しいノードがどのように参加するか、すでに参加しているノードがネットワークの存在を通知する方法など、ネットワークの形成方法を制御する必要があります。 LLCは次のことを行う必要があります。

1. Define the Information Elements included in the Enhanced Beacons (EBs) [IEEE.802.15.4e] advertising the presence of the network.

1. ネットワークの存在を通知する拡張ビーコン（EB）[IEEE.802.15.4e]に含まれる情報要素を定義します。

2. (For a new node), define rules to process and filter received EBs.

2. （新しいノードの場合）、受信したEBを処理およびフィルタリングするルールを定義します。

3. Define the joining procedure. This might include a mechanism to assign a unique 16-bit address to a node and the management of initial keying material.

3. 結合手順を定義します。これには、一意の16ビットアドレスをノードに割り当てるメカニズムと、初期キー情報の管理が含まれる場合があります。

4. Define a mechanism to secure the joining process and the subsequent optional process of scheduling more communication cells.

4. 参加プロセスと、より多くの通信セルをスケジュールする後続のオプションプロセスを保護するメカニズムを定義します。

3.2. Network Maintenance

3.2. ネットワークメンテナンス

Once a network is formed, the LLC needs to maintain the network's health, allowing for nodes to stay synchronized. The LLC needs to:

ネットワークが形成されると、LLCはネットワークの正常性を維持し、ノードの同期を維持できるようにする必要があります。 LLCは次のことを行う必要があります。

1. Manage each node's time source neighbor.

1. 各ノードのタイムソースネイバーを管理します。

2. Define a mechanism for a node to update the join priority it announces in its EB.

2. ノードがEBでアナウンスする結合優先度を更新するメカニズムを定義します。

3. Schedule transmissions of EBs to advertise the presence of the network.

3. EBの送信をスケジュールして、ネットワークの存在を通知します。

3.3. Multi-Hop Topology

3.3. マルチホップトポロジ

RPL, given a weighted connectivity graph, determines multi-hop routes. The LLC needs to:

加重接続グラフが与えられたRPLは、マルチホップルートを決定します。 LLCは次のことを行う必要があります。

1. Define a mechanism to gather topological information, node and link state, which it can then feed to RPL.

1. トポロジー情報、ノード、リンクの状態を収集するメカニズムを定義し、RPLに提供できます。

2. Ensure that the TSCH schedule contains cells along the multi-hop routes identified by RPL (a cell in a TSCH schedule is an atomic "unit" of resource, see Section 3.5).

2. TSCHスケジュールにRPLで識別されるマルチホップルートに沿ったセルが含まれていることを確認します（TSCHスケジュールのセルはリソースのアトミックな「単位」です。セクション3.5を参照してください）。

3. Where applicable, maintain independent sets of cells to transport independent flows of data.

3. 該当する場合は、独立したセルのセットを維持して、独立したデータフローを転送します。

3.4. Routing and Timing Parents

3.4. ルーティングとタイミングの親

At all times, a TSCH node needs to have a time-source neighbor to which it can synchronize. Therefore, LLC needs to assign a time-source neighbor to allow for correct operation of the TSCH network. A time-source neighbor could, or not, be taken from the RPL routing parent set.

TSCHノードには常に、同期可能なタイムソースネイバーが必要です。したがって、LLCはTSCHネットワークが正しく動作するように、タイムソースネイバーを割り当てる必要があります。タイムソースのネイバーは、RPLルーティングの親セットから取得される場合とされない場合があります。

3.5. Resource Management

3.5. 資源管理

A cell in a TSCH schedule is an atomic "unit" of resource. The number of cells to assign between neighbor nodes needs to be appropriate for the size of the traffic flow. The LLC needs to:

TSCHスケジュールのセルは、リソースのアトミックな「ユニット」です。隣接ノード間に割り当てるセルの数は、トラフィックフローのサイズに適切である必要があります。 LLCは次のことを行う必要があります。

1. Define a mechanism for neighbor nodes to exchange information about their schedule and, if applicable, negotiate the addition/ deletion of cells.

1. 隣接ノードがスケジュールに関する情報を交換し、該当する場合はセルの追加/削除をネゴシエートするためのメカニズムを定義します。

2. Allow for an entity (e.g., a set of devices, a distributed protocol, a Path Computation Element (PCE), etc.) to take control of the schedule.

2. エンティティ（デバイスのセット、分散プロトコル、パス計算エレメント（PCE）など）がスケジュールを制御できるようにします。

3.6. Dataflow Control

3.6. データフロー制御

TSCH defines mechanisms for a node to signal when it cannot accept an incoming packet. It does not, however, define the policy that determines when to stop accepting packets. The LLC needs to:

TSCHは、ノードが着信パケットを受け入れられないときに信号を送るメカニズムを定義します。ただし、パケットの受け入れを停止するタイミングを決定するポリシーは定義されていません。 LLCは次のことを行う必要があります。

1. Allow for the implementation and configuration of policy to queue incoming and outgoing packets.

1. 着信パケットと発信パケットをキューに入れるためのポリシーの実装と構成を可能にします。

2. Manage the buffer space, and indicate to TSCH when to stop accepting incoming packets.

2. バッファースペースを管理し、着信パケットの受け入れを停止するタイミングをTSCHに指示します。

3. Handle transmissions that have failed. A transmission is declared failed when TSCH has retransmitted the packet multiple times, without receiving an acknowledgment. This covers both dedicated and shared cells.

3. 失敗した送信を処理します。 TSCHが確認応答を受信せずにパケットを複数回再送信した場合、送信は失敗したと宣言されます。これは、専用セルと共有セルの両方をカバーしています。

3.7. Deterministic Behavior

3.7. 確定的行動

As highlighted in [RFC5673], in some applications, data is generated periodically and has a well-understood data bandwidth requirement, which is deterministic and predictable. The LLC needs to:

[RFC5673]で強調表示されているように、一部のアプリケーションでは、データは定期的に生成され、確定的で予測可能な十分に理解されたデータ帯域幅要件があります。 LLCは次のことを行う必要があります。

1. Ensure that the data is delivered to its final destination before a deadline possibly determined by the application.

1. アプリケーションによって決定される可能性のある期限の前に、データが最終宛先に配信されることを確認してください。

2. Provide a mechanism for such deterministic flows to coexist with bursty or infrequent traffic flows of different priorities.

2. そのような決定論的なフローが、異なる優先度のバースト性またはまれなトラフィックフローと共存するためのメカニズムを提供します。

3.8. Scheduling Mechanisms

3.8. スケジューリングのメカニズム

Several scheduling mechanisms can be envisioned and could possibly coexist in the same network. For example, [RPL] describes how the allocation of bandwidth can be optimized by an external PCE [RFC4655]. Another centralized (PCE-based) traffic-aware scheduling algorithm is defined in [TASA-PIMRC]. Alternatively, two neighbor nodes can adapt the number of cells autonomously by monitoring the amount of traffic and negotiating the allocation to extra cell when needed. An example of a decentralized algorithm (i.e., no PCE is needed) is provided in [Tinka10decentralized]. This mechanism can be used to establish multi-hop paths in a fashion similar to RSVP [RFC2205]. The LLC needs to:

いくつかのスケジューリングメカニズムが想定され、同じネットワーク内で共存できる可能性があります。たとえば、[RPL]は、帯域幅の割り当てを外部PCE [RFC4655]によって最適化する方法を説明しています。別の集中型（PCEベースの）トラフィック対応スケジューリングアルゴリズムは、[TASA-PIMRC]で定義されています。または、2つの隣接ノードが、トラフィック量を監視し、必要に応じて追加のセルへの割り当てをネゴシエートすることにより、セルの数を自律的に調整できます。 [Tinka10decentralized]には、分散アルゴリズムの例（つまり、PCEは必要ありません）が提供されています。このメカニズムは、RSVP [RFC2205]と同様の方法でマルチホップパスを確立するために使用できます。 LLCは次のことを行う必要があります。

1. Provide a mechanism for two devices to negotiate the allocation and deallocation of cells between them.

1. 2つのデバイス間でのセルの割り当てと割り当て解除をネゴシエートするためのメカニズムを提供します。

2. Provide a mechanism for the device to monitor and manage the capabilities of a node several hops away.

2. デバイスが数ホップ離れたノードの機能を監視および管理するためのメカニズムを提供します。

3. Define a mechanism for these different scheduling mechanisms to coexist in the same network.

3. これらの異なるスケジューリングメカニズムが同じネットワーク内で共存するためのメカニズムを定義します。

3.9. Secure Communication

3.9. 安全な通信

Given some keying material, TSCH defines mechanisms to encrypt and authenticate MAC frames. It does not define how this keying material is generated. The LLC needs to:

いくつかのキーイング情報が与えられた場合、TSCHはMACフレームを暗号化および認証するメカニズムを定義します。このキー情報の生成方法は定義されていません。 LLCは次のことを行う必要があります。

1. Define the keying material and authentication mechanism needed by a new node to join an existing network.

1. 新しいノードが既存のネットワークに参加するために必要なキー情報と認証メカニズムを定義します。

2. Define a mechanism to allow for the secure transfer of application data between neighbor nodes.

2. 隣接ノード間でのアプリケーションデータの安全な転送を可能にするメカニズムを定義します。

3. Define a mechanism to allow for the secure transfer of signaling data between nodes and the LLC.

3. ノードとLLC間のシグナリングデータの安全な転送を可能にするメカニズムを定義します。

4. Security Considerations

4. セキュリティに関する考慮事項

This memo is an informational overview of existing standards and does not define any new mechanisms or protocols.

このメモは、既存の標準に関する情報の概要であり、新しいメカニズムやプロトコルを定義するものではありません。

It does describe the need for the 6TiSCH WG to define a secure solution. In particular, Section 3.1 describes security in the join process. Section 3.9 discusses data-frame protection.

安全なソリューションを定義するための6TiSCH WGの必要性については説明しています。特に、セクション3.1では、結合プロセスのセキュリティについて説明します。セクション3.9では、データフレーム保護について説明します。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[IEEE.802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks -- Part. 15.4: Low-Rate Wireless Personal Area Networks", IEEE Std. 802.15.4-2011, September 2011.

[IEEE.802.15.4] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Part。15.4：Low-Rate Wireless Personal Area Networks」、IEEE Std。 802.15.4-2011、2011年9月。

[IEEE.802.15.4e] IEEE, "IEEE Standard for Local and metropolitan area networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE Std. 802.15.4e-2012, April 2012.

[IEEE.802.15.4e] IEEE、「IEEE Standard for Local and Metropolitan Area Network-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）Amendment 1：MAC sublayer」、IEEE Std。 802.15.4e-2012、2012年4月。

5.2. Informative References

5.2. 参考引用

[CurrentCalculator] Linear Technology, "Application Note: Using the Current Calculator to Estimate Mote Power", August 2012, <http://www.linear.com/docs/43189>.

[Current Calculator] Linear Technology、「Application Note：Using the Current Calculator to Estimate More Power」、2012年8月、<http://www.linear.com/docs/43189>。

[Doherty07channel] Doherty, L., Lindsay, W., and J. Simon, "Channel-Specific Wireless Sensor Network Path Data", IEEE International Conference on Computer Communications and Networks (ICCCN), pp. 89-94, 2007.

[Doherty07channel] Doherty、L.、Lindsay、W。、およびJ. Simon、「チャネル固有のワイヤレスセンサーネットワークパスデータ」、IEEE International Conference on Computer Communications and Networks（ICCCN）、pp。89-94、2007。

[IPSO] IPSO Alliance, "IP for Smart Objects Alliance Homepage", <http://www.ipso-alliance.org/>.

[IPSO] IPSO Alliance、「IP for Smart Objects Alliance Homepage」、<http://www.ipso-alliance.org/>。

[OpenWSN] "Berkeley's OpenWSN Project Homepage", <http://www.openwsn.org/>.

[OpenWSN]「バークレーのOpenWSNプロジェクトホームページ」、<http://www.openwsn.org/>。

[OpenWSNETT] Watteyne, T., Vilajosana, X., Kerkez, B., Chraim, F., Weekly, K., Wang, Q., Glaser, S., and K. Pister, "OpenWSN: A Standards-Based Low-Power Wireless Development Environment", Transactions on Emerging Telecommunications Technologies, Volume 23: Issue 5, August 2012.

[OpenWSNETT] Watteyne、T.、Vilajosana、X.、Kerkez、B.、Chraim、F.、Weekly、K.、Wang、Q.、Glaser、S。、およびK. Pister、「OpenWSN：A Standards-Based低電力ワイヤレス開発環境」、新興の通信技術に関するトランザクション、第23巻：第5号、2012年8月。

[Palattella12standardized] Palattella, MR., Accettura, N., Vilajosana, X., Watteyne, T., Grieco, LA., Boggia, G., and M. Dohler, "Standardized Protocol Stack For The Internet Of (Important) Things", IEEE Communications Surveys and Tutorials, Volume: 15, Issue 3, December 2012.

[Palattella12standardized] Palattella、MR。、Accettura、N.、Vilajosana、X.、Watteyne、T.、Grieco、LA。、Boggia、G.、and M. Dohler、 "Standardized Protocol Stack for the Internet Of（Important）Things "、IEEE Communications Surveys and Tutorials、Volume：15、Issue 3、2012年12月。

[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <http://www.rfc-editor.org/info/rfc2205>.

[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<http://www.rfc-editor.org/info/rfc2205>。

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。

[RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, DOI 10.17487/RFC3819, July 2004, <http://www.rfc-editor.org/info/rfc3819>.

[RFC3819]カーン、P。、編、ボーマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J.、L。ウッド、「インターネットサブネットワークデザイナーのためのアドバイス」、BCP 89、RFC 3819、DOI 10.17487 / RFC3819、2004年7月、<http://www.rfc-editor.org/info/rfc3819>。

[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.

[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<http：//www.rfc -editor.org/info/rfc4655>。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.

[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>.

[RFC4919] Kushalnagar、N.、Montenegro、G。、およびC. Schumacher、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、RFC 4919、DOI 10.17487 / RFC4919 、2007年8月、<http://www.rfc-editor.org/info/rfc4919>。

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.

[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。

[RFC5548] Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and D. Barthel, Ed., "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May 2009, <http://www.rfc-editor.org/info/rfc5548>.

[RFC5548] Dohler、M。、編、Watteyne、T。、編、Winter、T。、編、およびD. Barthel、編、「都市の低電力および損失の多いネットワークのルーティング要件」、RFC 5548 、DOI 10.17487 / RFC5548、2009年5月、<http://www.rfc-editor.org/info/rfc5548>。

[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October 2009, <http://www.rfc-editor.org/info/rfc5673>.

[RFC5673] Pister、K.、Ed。、Thubert、P.、Ed。、Dwars、S。、およびT. Phinney、「低電力および損失の多いネットワークにおける産業用ルーティング要件」、RFC 5673、DOI 10.17487 / RFC5673、 2009年10月、<http://www.rfc-editor.org/info/rfc5673>。

[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, DOI 10.17487/RFC5826, April 2010, <http://www.rfc-editor.org/info/rfc5826>.

[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」、RFC 5826、DOI 10.17487 / RFC5826、2010年4月、<http：// www。 rfc-editor.org/info/rfc5826>。

[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June 2010, <http://www.rfc-editor.org/info/rfc5867>.

[RFC5867] Martocci、J.、Ed。、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、DOI 10.17487 / RFC5867、June 2010、<http://www.rfc-editor.org/info/rfc5867>。

[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.

[RFC6282]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。

[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.

[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーイク、R。、ヴァッサー、JP。、およびR.アレクサンダー、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<http://www.rfc-editor.org/info/ rfc6550>。

[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <http://www.rfc-editor.org/info/rfc6606>.

[RFC6606] Kim、E.、Kaspar、D.、Gomez、C。、およびC. Bormann、「Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）Routing」、RFC 6606、DOI 10.17487 / RFC6606、2012年5月、<http://www.rfc-editor.org/info/rfc6606>。

[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <http://www.rfc-editor.org/info/rfc7102>.

[RFC7102] Vasseur、JP。、「低電力および損失の多いネットワークのルーティングに使用される用語」、RFC 7102、DOI 10.17487 / RFC7102、2014年1月、<http://www.rfc-editor.org/info/rfc7102> 。

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.

[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.

[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。

[RPL] Phinney, T., Thubert, P., and R. Assimiti, "RPL applicability in industrial networks", Work in Progress, draft-ietf-roll-rpl-industrial-applicability-02, October 2013.

[RPL] Phinney、T.、Thubert、P。、およびR. Assimiti、「産業ネットワークにおけるRPLの適用性」、Work in Progress、draft-ietf-roll-rpl-industrial-applicability-02、2013年10月。

[SUBLAYER-6top] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top)", Work in Progress, draft-wang-6tisch-6top-sublayer-01, July 2014.

[SUBLAYER-6top] Wang、Q.、Vilajosana、X。、およびT. Watteyne、「6TiSCH Operation Sublayer（6top）」、Work in Progress、draft-wang-6tisch-6top-sublayer-01、2014年7月。

[TASA-PIMRC] Palattella, MR., Accettura, N., Dohler, M., Grieco, LA., and G. Boggia, "Traffic Aware Scheduling Algorithm for reliable low-power multi-hop IEEE 802.15.4e networks", IEEE 23rd International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC), pp. 327-332, September 2012.

[TASA-PIMRC] Palattella、MR。、Acettura、N.、Dohler、M.、Grieco、LA、およびG. Boggia、「信頼性のある低電力マルチホップIEEE 802.15.4eネットワーク用のトラフィック認識スケジューリングアルゴリズム」、 IEEE 23rd International Symposium on Personal、Indoor and Mobile Radio Communications（PIMRC）、pp。327-332、September 2012。

[TERMS-6TISCH] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Work in Progress, draft-ietf-6tisch-terminology-04, March 2015.

[TERMS-6TISCH] Palattella、M.、Thubert、P.、Watteyne、T。、およびQ. Wang、「IEEE 802.15.4eのTSCHモードでのIPv6の用語」、作業中、draft-ietf-6tisch-用語集-04、2015年3月。

[Tinka10decentralized] Tinka, A., Watteyne, T., and K. Pister, "A Decentralized Scheduling Algorithm for Time Synchronized Channel Hopping", Ad Hoc Networks, 2010.

[Tinka10decentralized] Tinka、A.、Watteyne、T.、and K. Pister、 "A decentralized Scheduling Algorithm for Time Synchronized Channel Hopping"、Ad Hoc Networks、2010。

[Watteyne09reliability] Watteyne, T., Mehta, A., and K. Pister, "Reliability Through Frequency Diversity: Why Channel Hopping Makes Sense", Proceedings of the 6th ACM Symposium on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-WASUN), pp. 116-123, October 2009.

[Watteyne09reliability] Watteyne、T.、Mehta、A。、およびK. Pister、「周波数ダイバーシティによる信頼性：チャネルホッピングが意味をなす理由」、ワイヤレスアドホック、センサー、およびユビキタスネットワークのパフォーマンス評価に関する第6回ACMシンポジウムの議事録（PE-WASUN）、pp.116-123、2009年10月。

Appendix A. TSCH Protocol Highlights

付録A. TSCHプロトコルのハイライト

This appendix gives an overview of the key features of the IEEE 802.15.4e TSCH amendment. It makes no attempt at repeating the standard, rather it focuses on the following:

この付録では、IEEE 802.15.4e TSCH修正の主要な機能の概要を示します。それは標準を繰り返すことを試みません、むしろそれは以下に焦点を合わせます：

o Concepts that are sufficiently different from other IEEE 802.15.4 networking that they may need to be defined and presented precisely.

o 他のIEEE 802.15.4ネットワーキングと十分に異なる概念は、それらを正確に定義および提示する必要がある場合があります。

o Techniques and ideas that are part of IEEE 802.15.4e and that might be useful for the work of the 6TiSCH WG.

o IEEE 802.15.4eの一部であり、6TiSCH WGの作業に役立つ技術とアイデア。

A.1. Time Slots

A.1. タイムスロット

All nodes in a TSCH network are synchronized. Time is sliced up into time slots. A time slot is long enough for a MAC frame of maximum size to be sent from node A to node B, and for node B to reply with an acknowledgment (ACK) frame indicating successful reception.

TSCHネットワーク内のすべてのノードが同期されます。時間はタイムスロットに分割されます。タイムスロットは、ノードAからノードBに最大サイズのMACフレームを送信し、ノードBが受信の成功を示す確認応答（ACK）フレームで応答するのに十分な長さです。

The duration of a time slot is not defined by the standard. With radios that are compliant with IEEE 802.15.4 operating in the 2.4 GHz frequency band, a maximum-length frame of 127 bytes takes about 4 ms to transmit; a shorter ACK takes about 1 ms. With a 10 ms slot (a typical duration), this leaves 5 ms to radio turnaround, packet processing, and security operations.

タイムスロットの期間は、標準では定義されていません。 2.4 GHz周波数帯域で動作するIEEE 802.15.4に準拠した無線の場合、127バイトの最大長のフレームの送信には約4ミリ秒かかります。 ACKが短いほど、約1ミリ秒かかります。 10ミリ秒のスロット（通常の期間）では、無線のターンアラウンド、パケット処理、およびセキュリティ操作に5ミリ秒かかります。

A.2. Slotframes

A.2. スロットフレーム

Time slots are grouped into one of more slotframes. A slotframe continuously repeats over time. TSCH does not impose a slotframe size. Depending on the application needs, these can range from 10's to 1000's of time slots. The shorter the slotframe, the more often a time slot repeats, resulting in more available bandwidth, but also in a higher power consumption.

タイムスロットは、1つ以上のスロットフレームにグループ化されます。スロットフレームは、時間の経過とともに継続的に繰り返されます。 TSCHはスロットフレームサイズを強制しません。アプリケーションのニーズに応じて、これらは10から1000のタイムスロットの範囲になります。スロットフレームが短いほど、タイムスロットが繰り返される頻度が高くなり、使用可能な帯域幅が増加しますが、消費電力も高くなります。

A.3. Node TSCH Schedule

A.3. ノードTSCHスケジュール

A TSCH schedule instructs each node what to do in each time slot: transmit, receive, or sleep. The schedule indicates, for each scheduled (transmit or receive) cell, a channelOffset and the address of the neighbor with which to communicate.

TSCHスケジュールは、各ノードに各タイムスロットで実行する処理（送信、受信、またはスリープ）を指示します。スケジュールは、スケジュールされた（送信または受信）セルごとに、channelOffsetと通信するネイバーのアドレスを示します。

Once a node obtains its schedule, it executes it:

ノードはそのスケジュールを取得すると、それを実行します。

o For each transmit cell, the node checks whether there is a packet in the outgoing buffer that matches the neighbor written in the schedule information for that time slot. If there is none, the node keeps its radio off for the duration of the time slot. If there is one, the node can ask for the neighbor to acknowledge it, in which case it has to listen for the acknowledgment after transmitting.

o ノードは送信セルごとに、そのタイムスロットのスケジュール情報に書き込まれたネイバーと一致するパケットが発信バッファにあるかどうかを確認します。ない場合、ノードはタイムスロットの期間中、無線をオフのままにします。存在する場合、ノードはネイバーに確認応答を要求できます。その場合、ノードは送信後に確認応答をリッスンする必要があります。

o For each receive cell, the node listens for possible incoming packets. If none is received after some listening period, it shuts down its radio. If a packet is received, addressed to the node, and passes security checks, the node can send back an acknowledgment.

o 各受信セルについて、ノードは可能な着信パケットをリッスンします。リスニング期間の後に何も受信されない場合、無線をシャットダウンします。パケットが受信され、ノード宛てに送信され、セキュリティチェックに合格すると、ノードは確認応答を返すことができます。

How the schedule is built, updated, and maintained, and by which entity, is outside of the scope of the IEEE 802.15.4e standard.

スケジュールがどのように構築、更新、および維持されるか、またどのエンティティによって行われるかは、IEEE 802.15.4e標準の範囲外です。

A.4. Cells and Bundles

A.4. 細胞とバンドル

Assuming the schedule is well built, if node A is scheduled to transmit to node B at slotOffset 5 and channelOffset 11, node B will be scheduled to receive from node A at the same slotOffset and channelOffset.

スケジュールが適切に構築されていると仮定すると、ノードAがslotOffset 5およびchannelOffset 11でノードBに送信するようにスケジュールされている場合、ノードBは同じスロットオフセットおよびチャネルオフセットでノードAから受信するようにスケジュールされます。

A single element of the schedule characterized by a slotOffset and channelOffset, and reserved for node A to transmit to node B (or for node B to receive from node A) within a given slotframe, is called a "scheduled cell".

slotOffsetとchannelOffsetによって特徴付けられ、特定のスロットフレーム内でノードAがノードBに送信する（またはノードBがノードAから受信する）ために予約されているスケジュールの単一要素は、「スケジュールセル」と呼ばれます。

If there is a lot of data flowing from node A to node B, the schedule might contain multiple cells from A to B, at different times. Multiple cells scheduled to the same neighbor can be equivalent, i.e., the MAC layer sends the packet on whichever of these cells shows up first after the packet was put in the MAC queue. The union of all cells between two neighbors, A and B, is called a "bundle". Since the slotframe repeats over time (and the length of the slotframe is typically constant), each cell gives a "quantum" of bandwidth to a given neighbor. Modifying the number of equivalent cells in a bundle modifies the amount of resources allocated between two neighbors.

ノードAからノードBに大量のデータフローがある場合、スケジュールには、AからBへの複数のセルが異なる時間に含まれる場合があります。同じネイバーにスケジュールされた複数のセルは同等である可能性があります。つまり、MAC層は、パケットがMACキューに入れられた後に最初に表示されたこれらのセルのいずれかにパケットを送信します。 2つの隣接セルAとBの間のすべてのセルの結合は、「バンドル」と呼ばれます。スロットフレームは時間の経過とともに繰り返されるため（そしてスロットフレームの長さは通常一定です）、各セルは指定されたネイバーに帯域幅の「量子」を与えます。バンドル内の同等のセルの数を変更すると、2つのネイバー間に割り当てられたリソースの量が変更されます。

A.5. Dedicated vs. Shared Cells

A.5. 専用セルと共有セル

By default, each scheduled transmit cell within the TSCH schedule is dedicated, i.e., reserved only for node A to transmit to node B. IEEE 802.15.4e also allows a cell to be marked as shared. In a shared cell, multiple nodes can transmit at the same time, on the same frequency. To avoid contention, TSCH defines a backoff algorithm for shared cells.

デフォルトでは、TSCHスケジュール内のスケジュールされた各送信セルは専用です。つまり、ノードAがノードBに送信するためにのみ予約されています。IEEE802.15.4eは、セルを共有としてマークすることもできます。共有セルでは、複数のノードが同じ周波数で同時に送信できます。競合を回避するために、TSCHは共有セルのバックオフアルゴリズムを定義します。

A scheduled cell can be marked as both transmitting and receiving. In this case, a node transmits if it has an appropriate packet in its output buffer, or listens otherwise. Marking a cell as [transmit,receive,shared] results in slotted-Aloha behavior.

スケジュールされたセルは、送信と受信の両方としてマークできます。この場合、ノードは、出力バッファーに適切なパケットがある場合は送信し、そうでない場合はリッスンします。セルを[送信、受信、共有]としてマークすると、スロット付きアロハ動作になります。

A.6. Absolute Slot Number

A.6. 絶対スロット番号

TSCH defines a timeslot counter called Absolute Slot Number (ASN). When a new network is created, the ASN is initialized to 0; from then on, it increments by 1 at each timeslot. In detail:

TSCHは、Absolute Slot Number（ASN）と呼ばれるタイムスロットカウンターを定義します。新しいネットワークが作成されると、ASNは0に初期化されます。それ以降は、タイムスロットごとに1ずつ増加します。詳細に：

   ASN = (k*S+t)

where k is the slotframe cycle (i.e., the number of slotframe repetitions since the network was started), S the slotframe size, and t the slotOffset. A node learns the current ASN when it joins the network. Since nodes are synchronized, they all know the current value of the ASN, at any time. The ASN is encoded as a 5-byte number: this allows it to increment for hundreds of years (the exact value depends on the duration of a timeslot) without wrapping over. The ASN is used to calculate the frequency to communicate on and can be used for security-related operations.

ここで、kはスロットフレームサイクル（つまり、ネットワークが開始されてからのスロットフレームの繰り返し数）、Sはスロットフレームサイズ、tはslotOffsetです。ノードは、ネットワークに参加するときに現在のASNを学習します。ノードは同期されているため、すべてのノードがいつでもASNの現在の値を知っています。 ASNは5バイトの数値としてエンコードされます。これにより、何百年もの間（正確な値はタイムスロットの期間に依存します）、折り返すことなく増分できます。 ASNは、通信する頻度の計算に使用され、セキュリティ関連の操作に使用できます。

A.7. Channel Hopping

A.7. チャネルホッピング

For each scheduled cell, the schedule specifies a slotOffset and a channelOffset. In a well-built schedule, when node A has a transmit cell to node B on channelOffset 5, node B has a receive cell from node A on the same channelOffset. The channelOffset is translated by both nodes into a frequency using the following function:

スケジュールされたセルごとに、スケジュールはslotOffsetとchannelOffsetを指定します。適切に構築されたスケジュールでは、ノードAがチャネルオフセット5でノードBへの送信セルを持っている場合、ノードBは同じチャネルオフセットでノードAからの受信セルを持っています。 channelOffsetは、次の関数を使用して、両方のノードによって周波数に変換されます。

   frequency = F {(ASN + channelOffset) mod nFreq}

The function F consists of a lookup table containing the set of available channels. The value nFreq (the number of available frequencies) is the size of this lookup table. There are as many channelOffset values as there are frequencies available (e.g., 16 when using radios that are compliant with IEEE 802.15.4 at 2.4 GHz, when all channels are used). Since both nodes have the same channelOffset written in their schedule for that scheduled cell, and the same ASN counter, they compute the same frequency. At the next iteration (cycle) of the slotframe, however, while the channelOffset is the same, the ASN has changed, resulting in the computation of a different frequency.

関数Fは、使用可能なチャネルのセットを含むルックアップテーブルで構成されています。値nFreq（使用可能な周波数の数）は、このルックアップテーブルのサイズです。使用可能な周波数と同じ数のchannelOffset値があります（たとえば、2.4 GHzでIEEE 802.15.4に準拠する無線を使用する場合は16、すべてのチャネルが使用される場合）。両方のノードは、そのスケジュールされたセルのスケジュールに書き込まれた同じchannelOffsetと同じASNカウンターを持っているため、同じ周波数を計算します。ただし、スロットフレームの次の反復（サイクル）では、channelOffsetは同じであるが、ASNが変更されたため、異なる周波数が計算されています。

This results in "channel hopping": even with a static schedule, pairs of neighbors "hop" between the different frequencies when communicating. A way of ensuring communication happens on all available frequencies is to set the number of timeslots in a slotframe to a prime number. Channel hopping is a technique known to efficiently combat multi-path fading and external interference [Watteyne09reliability].

これにより、「チャネルホッピング」が発生します。静的なスケジュールを使用しても、通信するときに、隣接するノードのペアは異なる周波数間で「ホップ」します。利用可能なすべての周波数で通信が行われるようにする方法は、スロットフレーム内のタイムスロットの数を素数に設定することです。チャネルホッピングは、マルチパスフェージングと外部干渉に効果的に対抗することが知られている技術です[Watteyne09reliability]。

A.8. Time Synchronization

A.8. 時間同期

Because of the slotted nature of communication in a TSCH network, nodes have to maintain tight synchronization. All nodes are assumed to be equipped with clocks to keep track of time. Yet, because clocks in different nodes drift with respect to one another, neighbor nodes need to periodically resynchronize.

TSCHネットワークにおける通信のスロット化された性質のため、ノードは緊密な同期を維持する必要があります。すべてのノードには、時間を追跡するためのクロックが装備されていると想定されます。しかし、異なるノードのクロックは互いにずれているため、隣接ノードは定期的に再同期する必要があります。

Each node needs to periodically synchronize its network clock to another node, and it also provides its network time to its neighbors. It is up to the entity that manages the schedule to assign an adequate time source neighbor to each node, i.e., to indicate in the schedule which neighbor is its "time source neighbor". While setting the time source neighbor, it is important to avoid synchronization loops, which could result in the formation of independent clusters of synchronized nodes.

各ノードは、ネットワーククロックを別のノードに定期的に同期させる必要があり、また、ネットワーク時間を隣接ノードに提供します。スケジュールを管理して、各ノードに適切なタイムソースネイバーを割り当てる、つまり、どのネイバーが「タイムソースネイバー」であるかをスケジュールで示すのは、エンティティです。タイムソースネイバーを設定する間、同期ループを回避することが重要です。同期ループは、同期ノードの独立したクラスターの形成をもたらす可能性があります。

TSCH adds timing information in all packets that are exchanged (both data and ACK frames). This means that neighbor nodes can resynchronize to one another whenever they exchange data. In detail, two methods are defined in IEEE 802.15.4e (of 2012) for allowing a device to synchronize in a TSCH network: (i) Acknowledgment-based and (ii) Frame-based synchronization. In both cases, the receiver calculates the difference in time between the expected time of frame arrival and its actual arrival. In Acknowledgment-based synchronization, the receiver provides such information to the sender node in its acknowledgment. In this case, it is the sender node that synchronizes to the clock of the receiver. In Frame-based synchronization, the receiver uses the computed delta for adjusting its own clock. In this case, it is the receiver node that synchronizes to the clock of the sender.

TSCHは、交換されるすべてのパケット（データとACKフレームの両方）にタイミング情報を追加します。これは、隣接ノードがデータを交換するときはいつでも、相互に再同期できることを意味します。詳細には、デバイスがTSCHネットワークで同期できるようにするために、IEEE 802.15.4e（2012年）で2つの方法が定義されています。（i）確認応答ベースの同期と（ii）フレームベースの同期。どちらの場合も、受信機はフレーム到着の予想時間と実際の到着との時間差を計算します。確認応答ベースの同期では、受信者はそのような情報を確認応答で送信者ノードに提供します。この場合、受信者のクロックに同期するのは送信者ノードです。フレームベースの同期では、受信機は自身のクロックを調整するために計算されたデルタを使用します。この場合、送信側のクロックに同期するのは受信側ノードです。

Different synchronization policies are possible. Nodes can keep synchronization exclusively by exchanging EBs. Nodes can also keep synchronized by periodically sending valid frames to a time source neighbor and use the acknowledgment to resynchronize. Both methods (or a combination thereof) are valid synchronization policies; which one to use depends on network requirements.

異なる同期ポリシーが可能です。ノードは、EBを交換することによって排他的に同期を維持できます。ノードは、有効なフレームを定期的にタイムソースネイバーに送信することで同期を維持し、確認応答を使用して再同期することもできます。両方の方法（またはそれらの組み合わせ）は有効な同期ポリシーです。どちらを使用するかは、ネットワーク要件によって異なります。

A.9. Power Consumption

A.9. 消費電力

There are only a handful of activities a node can perform during a timeslot: transmit, receive, or sleep. Each of these operations has some energy cost associated to them; the exact value depends on the hardware used. Given the schedule of a node, it is straightforward to calculate the expected average power consumption of that node.

ノードがタイムスロット中に実行できるアクティビティは、送信、受信、またはスリープのほんの一部です。これらの各操作には、いくつかのエネルギーコストが関連付けられています。正確な値は、使用するハードウェアによって異なります。ノードのスケジュールが与えられれば、そのノードの予想される平均消費電力を計算することは簡単です。

A.10. Network TSCH Schedule

A.10. ネットワークTSCHスケジュール

The schedule entirely defines the synchronization and communication between nodes. By adding/removing cells between neighbors, one can adapt a schedule to the needs of the application. Intuitive examples are:

スケジュールは、ノード間の同期と通信を完全に定義します。隣接セル間でセルを追加/削除することにより、アプリケーションのニーズに合わせてスケジュールを調整できます。直感的な例は次のとおりです。

o Make the schedule "sparse" for applications where nodes need to consume as little energy as possible, at the price of reduced bandwidth.

o 帯域幅を削減する代わりに、ノードが可能な限り少ないエネルギーを消費する必要があるアプリケーションのスケジュールを「スパース」にします。

o Make the schedule "dense" for applications where nodes generate a lot of data, at the price of increased power consumption.

o 消費電力の増加を犠牲にして、ノードが大量のデータを生成するアプリケーションのスケジュールを「高密度」にします。

o Add more cells along a multi-hop route over which many packets flow.

o 多くのパケットが流れるマルチホップルートに沿ってセルを追加します。

A.11. Join Process

A.11. 参加プロセス

Nodes already part of the network can periodically send EB frames to announce the presence of the network. These contain information about the size of the timeslot used in the network, the current ASN, information about the slotframes and timeslots the beaconing node is listening on, and a 1-byte join priority. The join priority field gives information to make a better decision of which node to join. Even if a node is configured to send all EB frames on the same channelOffset, because of the channel hopping nature of TSCH described in Appendix A.7, this channelOffset translates into a different frequency at different slotframe cycles. As a result, EB frames are sent on all frequencies.

すでにネットワークの一部であるノードは、EBフレームを定期的に送信して、ネットワークの存在を通知できます。これらには、ネットワークで使用されているタイムスロットのサイズに関する情報、現在のASN、ビーコンノードがリッスンしているスロットフレームとタイムスロットに関する情報、および1バイトの結合優先順位が含まれています。結合優先度フィールドは、どのノードを結合するかをより適切に決定するための情報を提供します。ノードが同じchannelOffsetですべてのEBフレームを送信するように構成されている場合でも、付録A.7で説明されているTSCHのチャネルホッピングの性質により、このchannelOffsetは異なるスロットフレームサイクルで異なる周波数に変換されます。その結果、EBフレームはすべての周波数で送信されます。

A node wishing to join the network listens for EBs. Since EBs are sent on all frequencies, the joining node can listen on any frequency until it hears an EB. What frequency it listens on is implementation specific. Once it has received one or more EBs, the new node enables the TSCH mode and uses the ASN and the other timing information from the EB to synchronize to the network. Using the slotframe and cell information from the EB, it knows how to contact other nodes in the network.

ネットワークへの参加を希望するノードは、EBをリッスンします。 EBはすべての周波数で送信されるため、参加ノードはEBを聞くまで、任意の周波数でリッスンできます。リッスンする頻度は実装固有です。 1つ以上のEBを受信すると、新しいノードはTSCHモードを有効にし、EBからのASNおよび他のタイミング情報を使用してネットワークに同期します。 EBからのスロットフレームとセル情報を使用して、ネットワーク内の他のノードに接続する方法を認識しています。

The IEEE 802.15.4e TSCH standard does not define the steps beyond this network "bootstrap".

IEEE 802.15.4e TSCH標準は、このネットワークの「ブートストラップ」を超える手順を定義していません。

A.12. Information Elements

A.12. 情報要素

TSCH introduces the concept of Information Elements (IEs). An IE is a list of Type-Length-Value containers placed at the end of the MAC header. A small number of types are defined for TSCH (e.g., the ASN in the EB is contained in an IE), and an unmanaged range is available for extensions.

TSCHは情報要素（IE）の概念を導入しています。 IEは、MACヘッダーの最後に配置されるType-Length-Valueコンテナーのリストです。 TSCHには少数のタイプが定義されており（たとえば、EBのASNはIEに含まれています）、管理されていない範囲を拡張に使用できます。

A data bit in the MAC header indicates whether the frame contains IEs. IEs are grouped into Header IEs, consumed by the MAC layer and therefore typically invisible to the next higher layer, and Payload IEs, which are passed untouched to the next higher layer, possibly followed by regular payload. Payload IEs can therefore be used for the next higher layers of two neighbor nodes to exchange information.

MACヘッダーのデータビットは、フレームにIEが含まれているかどうかを示します。 IEは、ヘッダーIEにグループ化され、MACレイヤーによって消費されるため、通常は次の上位レイヤーからは見えません。ペイロードIEはそのまま次の上位レイヤーに渡され、通常のペイロードが続く場合があります。したがって、ペイロードIEは、2つの隣接ノードの次の上位層で情報を交換するために使用できます。

A.13. Extensibility

A.13. 拡張性

The TSCH standard is designed to be extensible. It introduces the mechanisms as "building block" (e.g., cells, bundles, slotframes, etc.), but leaves entire freedom to the upper layer to assemble those. The MAC protocol can be extended by defining new Header IEs. An intermediate layer can be defined to manage the MAC layer by defining new Payload IEs.

TSCH標準は拡張可能に設計されています。それは「ビルディングブロック」（例えば、セル、バンドル、スロットフレームなど）としてメカニズムを導入しますが、それらを組み立てる自由を上位層に任せます。 MACプロトコルは、新しいヘッダーIEを定義することで拡張できます。中間層を定義して、新しいペイロードIEを定義することにより、MAC層を管理できます。

Appendix B. TSCH Features

付録B. TSCHの機能

This section details features of TSCH, which might be interesting for the work of the 6TiSCH WG. It does not define any requirements.

このセクションでは、6TiSCH WGの作業にとって興味深いと思われるTSCHの機能について詳しく説明します。要件は定義されていません。

B.1. Collision-Free Communication

B.1. 衝突のないコミュニケーション

TSCH allows one to design a schedule that yields collision-free communication. This is done by building the schedule with dedicated cells in such a way that at most, one node communicates with a specific neighbor in each slotOffset/channelOffset cell. Multiple pairs of neighbor nodes can exchange data at the same time, but on different frequencies.

TSCHを使用すると、衝突のない通信を実現するスケジュールを設計できます。これは、最大で1つのノードが各slotOffset / channelOffsetセル内の特定のネイバーと通信するように、専用セルを使用してスケジュールを作成することによって行われます。複数の隣接ノードのペアが同時にデータを交換できますが、周波数は異なります。

B.2. Multi-Channel vs. Channel Hopping

B.2. マルチチャネルとチャネルホッピング

A TSCH schedule looks like a matrix of width "slotframe size", S, and of height "number of frequencies", nFreq. For a scheduling algorithm, cells can be considered atomic "units" to schedule. In particular, because of the channel hopping nature of TSCH, the scheduling algorithm should not worry about the actual frequency communication happens on, since it changes at each slotframe iteration.

TSCHスケジュールは、幅「スロットフレームサイズ」Sの行列と高さ「周波数数」nFreqの行列のように見えます。スケジューリングアルゴリズムの場合、セルは、スケジューリングするアトミックな「ユニット」と見なすことができます。特に、TSCHのチャネルホッピングの性質により、スケジューリングアルゴリズムはスロットフレームの反復ごとに変化するため、実際の周波数通信が発生することについて心配する必要はありません。

B.3. Cost of (Continuous) Synchronization

B.3. （継続的な）同期のコスト

When there is traffic in the network, nodes that are communicating implicitly resynchronize using the data frames they exchange. In the absence of data traffic, nodes are required to synchronize to their time source neighbor(s) periodically not to drift in time. If they have not been communicating for some time (typically 30 s), nodes can exchange a dummy data frame to resynchronize. The frequency at which such messages need to be transmitted depends on the stability of the clock source and on how "early" each node starts listening for data (the "guard time"). Theoretically, with a 10 ppm clock and a 1 ms guard time, this period can be 100 s. Assuming this exchange causes the node's radio to be on for 5 ms, this yields a radio duty cycle needed to keep synchronized of 5 ms / 100 s = 0.005%. While TSCH does require nodes to resynchronize periodically, the cost of doing so is very low.

ネットワークにトラフィックがある場合、通信しているノードは、交換するデータフレームを使用して暗黙的に再同期します。データトラフィックがない場合、ノードは時間的にドリフトしないように定期的にタイムソースネイバーと同期する必要があります。しばらく通信していなかった場合（通常30秒）、ノードはダミーデータフレームを交換して再同期できます。このようなメッセージを送信する必要がある頻度は、クロックソースの安定性と、各ノードがデータのリスニングを「早期に」開始する方法（「ガードタイム」）によって異なります。理論的には、10 ppmのクロックと1 msのガードタイムの場合、この期間は100秒になる可能性があります。この交換によってノードの無線が5ミリ秒間オンになると仮定すると、同期を維持するために必要な無線デューティサイクルは5ミリ秒/ 100秒= 0.005％になります。 TSCHでは定期的にノードを再同期する必要がありますが、そのためのコストは非常に低くなります。

B.4. Topology Stability

B.4. トポロジーの安定性

The channel hopping nature of TSCH causes links to be very "stable". Wireless phenomena such as multi-path fading and external interference impact a wireless link between two nodes differently on each frequency. If a transmission from node A to node B fails, retransmitting on a different frequency has a higher likelihood of succeeding that retransmitting on the same frequency. As a result, even when some frequencies are "behaving bad", channel hopping "smoothens" the contribution of each frequency, resulting in more stable links and therefore a more stable topology.

TSCHのチャネルホッピングの性質により、リンクは非常に「安定」します。マルチパスフェージングや外部干渉などの無線現象は、2つのノード間の無線リンクに各周波数で異なる影響を与えます。ノードAからノードBへの送信が失敗した場合、異なる周波数での再送信は、同じ周波数での再送信に成功する可能性が高くなります。その結果、一部の周波数が「動作が悪い」場合でも、チャネルホッピングは各周波数の寄与を「滑らかに」し、その結果、リンクがより安定し、トポロジがより安定します。

B.5. Multiple Concurrent Slotframes

B.5. 複数の同時スロットフレーム

The TSCH standard allows for multiple slotframes to coexist in a node's schedule. It is possible that, at some timeslot, a node has multiple activities scheduled (e.g., transmit to node B on slotframe 2, receive from node C on slotframe 1). To handle this situation, the TSCH standard defines the following precedence rules:

TSCH標準では、ノードのスケジュールで複数のスロットフレームを共存させることができます。あるタイムスロットで、ノードに複数のアクティビティがスケジュールされている可能性があります（たとえば、スロットフレーム2でノードBに送信し、スロットフレーム1でノードCから受信します）。この状況に対処するために、TSCH標準では次の優先ルールを定義しています。

1. Transmissions take precedence over receptions;

1. 送信は受信より優先されます。

2. Lower slotframe identifiers take precedence over higher slotframe identifiers.

2. 低いスロットフレーム識別子は、高いスロットフレーム識別子よりも優先されます。

In the example above, the node would transmit to node B on slotframe 2.

上記の例では、ノードはスロットフレーム2でノードBに送信します。

Acknowledgments

謝辞

Special thanks to Dominique Barthel, Patricia Brett, Guillaume Gaillard, Pat Kinney, Ines Robles, Timothy J. Salo, Jonathan Simon, Rene Struik, and Xavi Vilajosana for reviewing the document and providing valuable feedback. Thanks to the IoT6 European Project (STREP) of the 7th Framework Program (Grant 288445).

ドキュメントをレビューし、貴重なフィードバックを提供してくれたDominique Barthel、Patricia Brett、Guillaume Gaillard、Pat Kinney、Ines Robles、Timothy J. Salo、Jonathan Simon、Rene Struik、Xavi Vilajosanaに特に感謝します。第7フレームワークプログラム（グラント288445）のIoT6 European Project（STREP）に感謝します。

Authors' Addresses

著者のアドレス

Thomas Watteyne (editor) Linear Technology 32990 Alvarado-Niles Road, Suite 910 Union City, CA 94587 United States

Thomas Watteyne（編集者）Linear Technology 32990 Alvarado-Niles Road、Suite 910 Union City、CA 94587アメリカ合衆国

   Phone: +1 (510) 400-2978
   EMail: twatteyne@linear.com

Maria Rita Palattella University of Luxembourg Interdisciplinary Centre for Security, Reliability and Trust 4, rue Alphonse Weicker Luxembourg L-2721 Luxembourg

マリアリタパラットテラルクセンブルク大学学際的セキュリティ、信頼性、信頼センター4、rue Alphonse WeickerルクセンブルクL-2721ルクセンブルク

   Phone: +352 46 66 44 5841
   EMail: maria-rita.palattella@uni.lu

Luigi Alfredo Grieco Politecnico di Bari Department of Electrical and Information Engineering Via Orabona 4 Bari 70125 Italy

Luigi Alfredo Grieco Politecnico di Bari電気情報工学部Via Orabona 4 Bari 70125イタリア

   Phone: +39 08 05 96 3911
   EMail: a.grieco@poliba.it