[要約] 要約：RFC 7733は、低消費電力ネットワーク（LLN）におけるルーティングプロトコル（RPL）プロトコルスイートのホームオートメーションとビル制御への適用について説明しています。目的：このRFCの目的は、RPLプロトコルスイートがホームオートメーションとビル制御にどのように適用されるかを示し、その利点と制約を説明することです。
Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7733 Sigma Designs
Category: Standards Track E. Baccelli
ISSN: 2070-1721 INRIA
R. Cragie
ARM Ltd.
P. van der Stok
Consultant
February 2016
Applicability Statement: The Use of the Routing Protocol for Low-Power and Lossy Networks (RPL) Protocol Suite in Home Automation and Building Control
適用性声明：ホームオートメーションおよびビルディングコントロールにおける低電力および損失の多いネットワーク（RPL）プロトコルスイートのルーティングプロトコルの使用
Abstract
概要
The purpose of this document is to provide guidance in the selection and use of protocols from the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite to implement the features required for control in building and home environments.
このドキュメントの目的は、建物および家庭環境での制御に必要な機能を実装するために、低電力および損失の多いネットワーク（RPL）プロトコルスイートのルーティングプロトコルからプロトコルを選択および使用する際のガイダンスを提供することです。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc7733.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7733で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
1.1. Relationship to Other Documents ............................5
1.2. Terminology ................................................6
1.3. Required Reading ...........................................6
1.4. Requirements That Are Out of Scope .........................6
2. Deployment Scenario .............................................6
2.1. Network Topologies .........................................7
2.2. Traffic Characteristics ....................................8
2.2.1. General .............................................9
2.2.2. Source-Sink (SS) Communication Paradigm ............10
2.2.3. Publish-Subscribe (PS, or Pub/Sub)
Communication Paradigm .............................10
2.2.4. Peer-to-Peer (P2P) Communication Paradigm ..........10
2.2.5. Peer-to-Multipeer (P2MP) Communication Paradigm ....11
2.2.6. Additional Considerations: Duocast and N-Cast ......11
2.2.7. RPL Applicability per Communication Paradigm .......11
2.3. Layer 2 Applicability .....................................13
3. Using RPL to Meet Functional Requirements ......................13
4. RPL Profile ....................................................14
4.1. RPL Features ..............................................14
4.1.1. RPL Instances ......................................15
4.1.2. Storing vs. Non-Storing Mode .......................15
4.1.3. DAO Policy .........................................15
4.1.4. Path Metrics .......................................15
4.1.5. Objective Function .................................16
4.1.6. DODAG Repair .......................................16
4.1.7. Multicast ..........................................16
4.1.8. Security ...........................................17
4.1.9. P2P Communications .................................21
4.1.10. IPv6 Address Configuration ........................21
4.2. Layer 2 Features ..........................................21
4.2.1. Specifics about Layer 2 ............................21
4.2.2. Services Provided at Layer 2 .......................21
4.2.3. IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Options Assumed ..................21
4.2.4. Mesh Link Establishment (MLE) and Other Things .....21
4.3. Recommended Configuration Defaults and Ranges .............21
4.3.1. Trickle Parameters .................................22
4.3.2. Other Parameters ...................................22
5. MPL Profile ....................................................23
5.1. Recommended Configuration Defaults and Ranges .............23
5.1.1. Real-Time Optimizations ............................23
5.1.2. Trickle Parameters .................................23
5.1.3. Other Parameters ...................................24
6. Manageability Considerations ...................................25
7. Security Considerations ........................................25
7.1. Security Considerations during Initial Deployment .........26
7.2. Security Considerations during Incremental Deployment .....27
7.3. Security Considerations for P2P Implementations ...........27
7.4. MPL Routing ...............................................27
7.5. RPL Security Features .....................................27
8. Other Related Protocols ........................................28
9. References .....................................................28
9.1. Normative References ......................................28
9.2. Informative References ....................................32
Appendix A. RPL Shortcomings in Home and Building Deployments .....35
A.1. Risk of Undesirable Long P2P Routes ........................35
A.1.1. Traffic Concentration at the Root ......................35
A.1.2. Excessive Battery Consumption in Source Nodes ..........35
A.2. Risk of Delayed Route Repair ...............................35
A.2.1. Broken Service .........................................36
Appendix B. Communication Failures ................................36
Acknowledgements ..................................................38
Authors' Addresses ................................................38
The primary purpose of this document is to give guidance in the use of the Routing Protocol for Low-Power and Lossy Networks (RPL) protocol suite in two application domains:
このドキュメントの主な目的は、2つのアプリケーションドメインでの低電力および損失の多いネットワーク（RPL）プロトコルスイートのルーティングプロトコルの使用に関するガイダンスを提供することです。
o Home automation
o ホームオートメーション
o Building automation
o ビルオートメーション
The guidance is based on the features required by the requirements documents "Home Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5826] and "Building Automation Routing Requirements in Low-Power and Lossy Networks" [RFC5867], respectively. The Advanced Metering Infrastructure is also considered where appropriate. The applicability domains distinguish themselves in the way they are operated, their performance requirements, and the most likely network structures. An abstract set of distinct communication paradigms is then used to frame the applicability domains.
このガイダンスは、要件ドキュメント「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」[RFC5826]および「低電力および損失の多いネットワークにおけるビルディングオートメーションルーティング要件」[RFC5867]でそれぞれ要求される機能に基づいています。 Advanced Metering Infrastructureも適切な場合に考慮されます。適用性ドメインは、運用方法、パフォーマンス要件、および最も可能性の高いネットワーク構造で区別されます。次に、異なる一連の通信パラダイムの抽象的なセットを使用して、適用性ドメインを構成します。
Home automation and building automation application domains share a substantial number of properties:
ホームオートメーションとビルディングオートメーションアプリケーションのドメインは、次のような多くのプロパティを共有しています。
o In both domains, the network can be disconnected from the ISP and must still continue to provide control to the occupants of the home or building. Routing needs to be possible independent of the existence of a border router.
o どちらのドメインでも、ネットワークをISPから切断することができますが、引き続き家や建物の居住者に制御を提供する必要があります。ボーダールーターの存在に関係なく、ルーティングが可能である必要があります。
o Both domains are subject to unreliable links but require instant and very reliable reactions. This has an impact on routing because of timeliness and multipath routing.
o 両方のドメインは信頼性の低いリンクの影響を受けますが、即時の非常に信頼できる反応が必要です。適時性とマルチパスルーティングのため、これはルーティングに影響を与えます。
The differences between the two application domains mostly appear in commissioning, maintenance, and the user interface, which do not typically affect routing. Therefore, the focus of this applicability document is on reliability, timeliness, and local routing.
2つのアプリケーションドメインの違いは、主に試運転、メンテナンス、およびユーザーインターフェイスにあり、通常はルーティングに影響しません。したがって、この適用性ドキュメントの焦点は、信頼性、適時性、ローカルルーティングにあります。
It should be noted that adherence to the guidance in this document does not necessarily guarantee fully interoperable solutions in home automation networks and building control networks and that additional rigorous and managed programs will be needed to ensure interoperability.
このドキュメントのガイダンスの順守は、ホームオートメーションネットワークおよびビル制御ネットワークにおける完全に相互運用可能なソリューションを必ずしも保証するものではなく、相互運用性を確保するために、さらに厳密で管理されたプログラムが必要になることに注意してください。
The Routing Over Low power and Lossy networks (ROLL) working group has specified a set of routing protocols for Low-Power and Lossy Networks (LLNs) [RFC6550]. This applicability text describes a subset of those protocols and the conditions under which the subset is appropriate, and it provides recommendations and requirements for the accompanying parameter value ranges.
低電力および損失の多いネットワーク（ROLL）ワーキンググループは、低電力および損失の多いネットワーク（LLN）[RFC6550]用のルーティングプロトコルのセットを指定しています。この適用可能性テキストは、これらのプロトコルのサブセットと、サブセットが適切である条件を説明し、付随するパラメーター値の範囲に関する推奨事項と要件を提供します。
In addition, [RFC6997] was written specifically as an extension to core RPL [RFC6550] and provides a solution for reactive discovery of point-to-point routes in LLNs. The present applicability document provides recommendations and requirements for the accompanying parameter value ranges.
さらに、[RFC6997]はコアRPL [RFC6550]の拡張として特別に作成され、LLN内のポイントツーポイントルートのリアクティブディスカバリのためのソリューションを提供します。現在の適用性ドキュメントは、付随するパラメーター値の範囲に関する推奨事項と要件を提供します。
[RFC7416] describes a common set of security threats. The applicability statements provided in Section 4.1.8.2.2 of this document complement [RFC7416] by describing preferred security settings and solutions within the applicability statement conditions. This applicability statement recommends lighter-weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
[RFC7416]は、セキュリティの脅威の一般的なセットについて説明しています。このドキュメントのセクション4.1.8.2.2で提供される適用性ステートメントは、[RFC7416]を補完して、適用性ステートメントの条件内で優先されるセキュリティ設定とソリューションを説明します。この適用性に関する声明では、住宅および建築環境に適した軽量のセキュリティソリューションを推奨し、これらのソリューションが適切である理由を示しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Additionally, this document uses terminology from [RFC6997], [RFC7731], [RFC7102], [IEEE802.15.4], and [RFC6550].
さらに、このドキュメントでは、[RFC6997]、[RFC7731]、[RFC7102]、[IEEE802.15.4]、および[RFC6550]の用語を使用しています。
Applicable requirements are described in [RFC5826] and [RFC5867]. A survey of the application field is described in [BC-Survey].
適用可能な要件は、[RFC5826]と[RFC5867]で説明されています。応用分野の調査は[BC-調査]に記載されています。
The considered network diameter is limited to a maximum diameter of 10 hops and a typical diameter of five hops; this captures the most common cases in home automation and building control networks.
考慮されるネットワークの直径は、最大直径が10ホップ、通常の直径が5ホップに制限されています。これは、ホームオートメーションとビル制御ネットワークの最も一般的なケースを示しています。
This document does not consider the applicability of RPL-related specifications for urban and industrial applications [RFC5548] [RFC5673], which may exhibit significantly larger network diameters.
このドキュメントでは、都市部および産業用アプリケーション[RFC5548] [RFC5673]のRPL関連の仕様の適用性については考慮していません。
The use of communications networks in buildings is essential to satisfy energy-saving regulations. Environmental conditions of buildings can be adapted to suit the comfort of the individuals present inside. Consequently, when no one is present, energy consumption can be reduced. Cost is the main driving factor behind deployment of wireless networking in buildings, especially in the case of retrofitting, where wireless connectivity saves costs incurred due to cabling and building modifications.
建物での通信ネットワークの使用は、省エネ規制を満たすために不可欠です。建物の環境条件は、内部にいる個人の快適さに合わせて調整できます。これにより、人がいない場合のエネルギー消費を抑えることができる。コストは建物にワイヤレスネットワークを展開する主な推進要因です。特に、レトロフィットの場合、ワイヤレス接続により、ケーブルや建物の改造により発生するコストが節約されます。
A typical home automation network is comprised of less than 100 nodes. Large building deployments may span 10,000 nodes, but to ensure uninterrupted service of light and air conditioning systems in individual zones of the building, nodes are typically organized in subnetworks. Each subnetwork in a building automation deployment typically contains tens to hundreds of nodes and, for critical operations, may operate independently from the other subnetworks.
典型的なホームオートメーションネットワークは、100未満のノードで構成されます。大規模な建物の展開は10,000ノードに及ぶ場合がありますが、建物の個々のゾーンで照明および空調システムのサービスが中断されないようにするために、ノードは通常サブネットワークに編成されます。ビルディングオートメーション展開の各サブネットワークには、通常、数十から数百のノードが含まれ、重要な操作のために、他のサブネットワークとは独立して動作する場合があります。
The main purpose of the home or building automation network is to provide control over light and heating/cooling resources. User intervention via wall controllers is combined with movement, light and temperature sensors to enable automatic adjustment of window blinds, reduction of room temperature, etc. In general, the sensors and actuators in a home or building typically have fixed physical locations and will remain in the same home or building automation network.
ホームオートメーションまたはビルディングオートメーションネットワークの主な目的は、照明および冷暖房のリソースを制御することです。壁のコントローラーを介したユーザー介入は、動き、光、温度センサーと組み合わされて、ブラインドの自動調整、室温の低下などを可能にします。一般に、家や建物のセンサーとアクチュエーターは、通常、物理的な場所が固定されており、同じホームまたはビルディングオートメーションネットワーク。
People expect an immediate and reliable response to their presence or actions. For example, a light not switching on after entry into a room may lead to confusion and a profound dissatisfaction with the lighting product.
人々は、自分の存在や行動に対して即座に信頼できる応答を期待します。たとえば、部屋に入った後に照明がオンにならない場合、混乱が生じ、照明製品に対する深刻な不満が生じる可能性があります。
Monitoring of functional correctness is at least as important as timely responses. Devices typically communicate their status regularly and send alarm messages to notify users or implementers that a malfunction of controlled equipment or a controlled network has occurred.
機能の正確さの監視は、少なくともタイムリーな応答と同じくらい重要です。デバイスは通常、ステータスを定期的に通信し、アラームメッセージを送信して、制御対象の機器または制御対象のネットワークの誤動作が発生したことをユーザーまたは実装者に通知します。
In building control, the infrastructure of the building management network can be shared with security/access, Internet Protocol (IP) telephony, and fire/alarm networks. This approach has a positive impact on the operation and cost of the network; however, care should be taken to ensure that the availability of the building management network does not become compromised beyond the ability of critical functions to perform adequately.
ビル管理では、ビル管理ネットワークのインフラストラクチャを、セキュリティ/アクセス、インターネットプロトコル（IP）テレフォニー、および火災/警報ネットワークと共有できます。このアプローチは、ネットワークの運用とコストにプラスの影響を与えます。ただし、建物管理ネットワークの可用性が、重要な機能が適切に機能する能力を超えて損なわれないように注意する必要があります。
In homes, the entertainment network for audio/video streaming and gaming has different requirements, where the most important requirement is the need for high bandwidth not typically needed for home or building control. It is therefore expected that the entertainment network in the home will mostly be separate from the control network, as this will also lessen the impact on the availability of the control network.
家庭では、オーディオ/ビデオストリーミングとゲームのエンターテイメントネットワークにはさまざまな要件がありますが、最も重要な要件は、家庭やビルの制御に通常必要とされない高帯域幅の必要性です。したがって、家庭内のエンターテインメントネットワークは、制御ネットワークの可用性への影響が少なくなるため、ほとんどが制御ネットワークから分離されることが予想されます。
In general, the home automation network or building control network consists of wired and wireless subnetworks. In large buildings in particular, the wireless subnetworks can be connected to an IP backbone network where all infrastructure services (e.g., Domain Name System (DNS), automation servers) are located.
一般に、ホームオートメーションネットワークまたはビルディングコントロールネットワークは、有線および無線サブネットワークで構成されています。特に大きな建物では、すべてのインフラストラクチャサービス（ドメインネームシステム（DNS）、オートメーションサーバーなど）が配置されているIPバックボーンネットワークにワイヤレスサブネットワークを接続できます。
The wireless subnetwork can be configured according to any of the following topologies:
ワイヤレスサブネットワークは、次のトポロジのいずれかに従って構成できます。
o A stand-alone network of 10-100 nodes without a border router. This typically occurs in the home with a stand-alone control network, in low-cost buildings, and during installation of high-end control systems in buildings.
o ボーダールーターのない10〜100ノードのスタンドアロンネットワーク。これは通常、スタンドアロンの制御ネットワークを備えた家庭、低コストの建物、および建物にハイエンドの制御システムを設置しているときに発生します。
o A connected network with one border router. This configuration will happen in homes where home appliances are controlled from outside the home, possibly via a smart phone, and in many building control scenarios.
o 1つの境界ルーターを持つ接続されたネットワーク。この構成は、おそらくスマートフォンを介して、家の外から家電製品が制御されている家や、多くのビル制御シナリオで発生します。
o A connected network with multiple border routers. This will typically happen in installations of large buildings.
o 複数の境界ルーターが接続されたネットワーク。これは通常、大きな建物の設置で発生します。
Many of the nodes are battery powered and may be sleeping nodes that wake up according to clock signals or external events.
ノードの多くは電池式であり、クロック信号または外部イベントに従ってウェイクアップするスリープノードである場合があります。
In a building control network, for a large installation with multiple border routers, subnetworks often overlap both geographically and from a wireless coverage perspective. Due to two purposes of the network -- (i) direct control and (ii) monitoring -- there may exist two types of routing topologies in a given subnetwork: (i) a tree-shaped collection of routes spanning from a central building controller via the border router, on to destination nodes in the subnetwork, and (ii) a flat, undirected collection of intra-network routes between functionally related nodes in the subnetwork.
ビル管理ネットワークでは、複数の境界ルーターを備えた大規模な設置の場合、サブネットワークは地理的にもワイヤレスカバレッジの観点からも重複することがよくあります。ネットワークの2つの目的-（i）直接制御と（ii）監視-が原因で、特定のサブネットワークに2種類のルーティングトポロジが存在する可能性があります。（i）中央の建物のコントローラーから伸びるツリー状のルートのコレクション境界ルーターを経由して、サブネットワーク内の宛先ノード、および（ii）サブネットワーク内の機能的に関連するノード間のイントラネットワークルートのフラットな無向のコレクション。
The majority of nodes in home and building automation networks are typically Class 0 devices [RFC7228], such as individual wall switches. Only a few nodes (such as multi-purpose remote controls) are more expensive Class 1 devices, which can afford more memory capacity.
ホームおよびビルディングオートメーションネットワークのノードの大部分は、通常、個別の壁スイッチなどのクラス0デバイス[RFC7228]です。少数のノード（多目的リモコンなど）だけがより高価なクラス1デバイスであり、より多くのメモリ容量を提供できます。
Traffic may enter the network originating from a central controller, or it may originate from an intra-network node. The majority of traffic is of a lightweight point-to-point control style, e.g., Put-Ack or Get-Response. There are, however, exceptions. Bulk data transfer is used for firmware updates and logging, where firmware updates enter the network and logs leave the network. Group communication is used for service discovery or to control groups of nodes, such as light fixtures.
トラフィックは、中央コントローラーから発信されたネットワークに入る場合と、ネットワーク内ノードから発信された場合があります。トラフィックの大部分は、Put-AckやGet-Responseなどの軽量のポイントツーポイントコントロールスタイルです。ただし、例外があります。一括データ転送は、ファームウェアの更新とロギングに使用されます。ファームウェアの更新はネットワークに入り、ログはネットワークを離れます。グループ通信は、サービスの検出、または照明器具などのノードのグループの制御に使用されます。
Often, there is a direct physical relationship between a controlling sensor and the controlled equipment. For example, the temperature sensor and room controller are located in the same room, sharing the same climate conditions. Consequently, the bulk of senders and receivers are separated by a distance that allows one-hop direct path communication. A graph of the communication will show several fully connected subsets of nodes. However, due to interference, multipath fading, reflection, and other transmission mechanisms, the one-hop direct path may be temporarily disconnected. For reliability purposes, it is therefore essential that alternative n-hop communication routes exist for quick error recovery. (See Appendix B for motivation.)
多くの場合、制御センサーと制御機器の間には直接的な物理的関係があります。たとえば、温度センサーとルームコントローラーは同じ部屋にあり、同じ気候条件を共有しています。その結果、送信側と受信側の大部分は、1ホップのダイレクトパス通信を可能にする距離だけ離れています。通信のグラフには、完全に接続されたノードのサブセットがいくつか表示されます。ただし、干渉、マルチパスフェージング、反射、およびその他の伝送メカニズムにより、1ホップのダイレクトパスが一時的に切断される場合があります。したがって、信頼性を確保するためには、迅速なエラー回復のために代替のnホップ通信経路が存在することが不可欠です。 （動機については、付録Bを参照してください。）
Looking over time periods of a day, the networks are very lightly loaded. However, bursts of traffic can be generated by, for example, incessant pushing of the button of a remote control, the occurrence of a defect, and other unforeseen events. Under those conditions, the timeliness must nevertheless be maintained. Therefore, measures are necessary to remove any unnecessary traffic. Short routes are preferred. Long multi-hop routes via the border router should be avoided whenever possible.
1日の期間を見ると、ネットワークの負荷は非常に軽くなっています。しかし、トラフィックのバーストは、たとえば、リモートコントロールのボタンの絶え間ない押し、欠陥の発生、および他の予期しないイベントによって生成される可能性があります。これらの状況下でも、適時性を維持する必要があります。したがって、不要なトラフィックを排除するための対策が必要です。短いルートが推奨されます。境界ルータ経由の長いマルチホップルートは、可能な限り回避する必要があります。
Group communication is essential for lighting control. For example, once the presence of a person is detected in a given room, lighting control applies to that room only, and no other lights should be dimmed or switched on/off. In many cases, this means that a multicast message with a one-hop and two-hop radius would suffice to control the required lights. The same argument holds for Heating, Ventilating, and Air Conditioning (HVAC) and other climate-control devices. To reduce network load, it is advisable that messages to the lights in a room are not distributed any further in the mesh than necessary, based on intended receivers.
照明制御にはグループ通信が不可欠です。たとえば、特定の部屋で人の存在が検出されると、照明制御はその部屋にのみ適用され、他の照明を暗くしたり、オン/オフを切り替えたりすることはできません。多くの場合、これは、1ホップと2ホップの半径を持つマルチキャストメッセージで、必要なライトを制御するのに十分であることを意味します。同じことが、暖房、換気、および空調（HVAC）やその他の空調装置にも当てはまります。ネットワークの負荷を軽減するために、部屋の照明へのメッセージは、意図された受信者に基づいて、必要以上にメッシュ内で分散されないことが推奨されます。
[Office-Light] provides an example of an office space, and [OccuSwitch] describes the current use of wireless lighting control products.
[Office-Light]はオフィススペースの例を示し、[OccuSwitch]はワイヤレス照明制御製品の現在の使用法を示しています。
Although air conditioning and other environmental-control applications may accept response delays of tens of seconds or longer, alarm and light control applications may be regarded as soft real-time systems. A slight delay is acceptable, but the perceived quality of service degrades significantly if response times exceed 250 ms. If the light does not turn on at short notice, a user may activate the controls again, thus causing a sequence of commands such as Light{on,off,on,off,...} or Volume{up,up,up,up,up,...}. In addition, the repetitive sending of commands creates an unnecessary loading of the network, which in turn increases the poor responsiveness of the network.
空調およびその他の環境制御アプリケーションは、数十秒以上の応答遅延を受け入れる場合がありますが、警報および照明制御アプリケーションは、ソフトリアルタイムシステムと見なすことができます。わずかな遅延は許容できますが、応答時間が250ミリ秒を超えると、認識されるサービス品質が大幅に低下します。ライトがすぐにオンにならない場合、ユーザーはコントロールを再度アクティブにして、Light {on、off、on、off、...}やVolume {up、up、up、 up、up、...}。また、コマンドを繰り返し送信すると、ネットワークに不要な負荷がかかり、ネットワークの応答性が低下します。
This paradigm translates to many sources sending messages to the same sink, sometimes reachable via the border router. As such, Source-Sink (SS) traffic can be present in home and building networks. The traffic may be generated by environmental sensors (often present in a wireless subnetwork) that push periodic readings to a central server. The readings may be used for pure logging or, more often, processed to adjust light, heating, and ventilation. Alarm sensors may also generate SS-style traffic. The central server in a home automation network will be connected mostly to a wired network segment of the home network, although it is likely that cloud services will also be used. The central server in a building automation network may be connected to a backbone or placed outside the building.
このパラダイムは、メッセージを同じシンクに送信する多くのソースに変換されます。ボーダールーター経由で到達できることもあります。そのため、Source-Sink（SS）トラフィックは、ホームネットワークおよびビルディングネットワークに存在する可能性があります。トラフィックは、定期的な読み取り値を中央サーバーにプッシュする環境センサー（多くの場合、ワイヤレスサブネットワークに存在）によって生成されます。読み取り値は、純粋な検層に使用できますが、多くの場合、光、暖房、換気を調整するために処理されます。アラームセンサーは、SSスタイルのトラフィックも生成します。ホームオートメーションネットワークの中央サーバーは、ほとんどがホームネットワークの有線ネットワークセグメントに接続されますが、クラウドサービスも使用される可能性があります。ビルディングオートメーションネットワークの中央サーバーは、バックボーンに接続するか、建物の外に配置できます。
With regard to message latency, most SS transmissions can tolerate worst-case delays measured in tens of seconds. Fire detectors, however, represent an exception; for example, special provisions with respect to the location of the fire detectors and smoke dampers need to be put in place to meet stringent delay requirements that are measured in seconds.
メッセージの遅延に関しては、ほとんどのSS送信は、数十秒で測定される最悪の場合の遅延を許容できます。ただし、火災検知器は例外です。たとえば、秒単位で測定される厳しい遅延要件を満たすために、火災検知器と煙ダンパーの場所に関する特別な対策を講じる必要があります。
This paradigm translates to a number of devices expressing their interest in a service provided by a server device. For example, a server device can be a sensor delivering temperature readings on the basis of delivery criteria, like changes in acquisition value or age of the latest acquisition. In building automation networks, this paradigm may be closely related to the SS paradigm, given that servers, which are connected to the backbone or outside the building, can subscribe to data collectors that are present at strategic places in the building automation network. The use of PS will probably differ significantly from installation to installation.
このパラダイムは、サーバーデバイスによって提供されるサービスへの関心を表す多くのデバイスに変換されます。たとえば、サーバーデバイスは、取得値の変化や最新の取得の経過時間など、配信基準に基づいて温度測定値を配信するセンサーである場合があります。ビルディングオートメーションネットワークでは、このパラダイムはSSパラダイムと密接に関連している可能性があります。これは、バックボーンまたはビルディングの外部に接続されているサーバーが、ビルディングオートメーションネットワークの戦略的な場所にあるデータコレクターにサブスクライブできることを前提としています。 PSの使用は、インストールごとに大きく異なります。
This paradigm translates to a device transferring data to another device often connected to the same subnetwork. Peer-to-Peer (P2P) traffic is a common traffic type in home automation networks. Most building automation networks rely on P2P traffic as described in the next paragraph. Other building automation networks rely on P2P control traffic between controls and a local controller box for advanced group control. A local controller box can be further connected to service control boxes, thus generating more SS or PS traffic.
このパラダイムは、同じサブネットワークに接続されていることが多い別のデバイスにデータを転送するデバイスに変換されます。ピアツーピア（P2P）トラフィックは、ホームオートメーションネットワークで一般的なトラフィックタイプです。次の段落で説明するように、ほとんどのビルディングオートメーションネットワークはP2Pトラフィックに依存しています。他のビルディングオートメーションネットワークは、高度なグループコントロールのために、コントロールとローカルコントローラーボックス間のP2Pコントロールトラフィックに依存しています。ローカルコントローラボックスをサービスコントロールボックスにさらに接続して、より多くのSSまたはPSトラフィックを生成できます。
P2P traffic is typically generated by remote controls and wall controllers that push Control Messages directly to light or heat sources. P2P traffic has a stringent requirement for low latency, since P2P traffic often carries application messages that are invoked by humans. As mentioned in Section 2.2.1, application messages should be delivered within a few hundred milliseconds, even when connections fail momentarily.
P2Pトラフィックは、通常、コントロールメッセージを光源または熱源に直接プッシュするリモートコントロールおよびウォールコントローラーによって生成されます。 P2Pトラフィックは、人間が呼び出すアプリケーションメッセージを運ぶことが多いため、P2Pトラフィックには低遅延の厳しい要件があります。 2.2.1項で述べたように、アプリケーションメッセージは、接続が一時的に失敗した場合でも、数百ミリ秒以内に配信される必要があります。
This paradigm translates to a device sending a message as many times as there are destination devices. Peer-to-Multipeer (P2MP) traffic is common in home and building automation networks. Often, a thermostat in a living room responds to temperature changes by sending temperature acquisitions to several fans and valves consecutively. This paradigm is also closely related to the PS paradigm in the case where a single server device has multiple subscribers.
このパラダイムは、宛先デバイスと同じ回数だけメッセージを送信するデバイスに変換されます。ピアツーマルチピア（P2MP）トラフィックは、ホームおよびビルディングオートメーションネットワークで一般的です。多くの場合、リビングルームのサーモスタットは、温度の取得を複数のファンとバルブに連続して送信することにより、温度変化に応答します。このパラダイムは、単一のサーバーデバイスに複数のサブスクライバーがある場合のPSパラダイムとも密接に関連しています。
This paradigm translates to a device sending a message to many destinations in one network transfer invocation. Multicast is well suited for lighting where a presence sensor sends a presence message to a set of lighting devices. Multicast increases the probability that the message is delivered within strict time constraints. The recommended multicast algorithm (e.g., [RFC7731]) provides a mechanism for delivering messages to all intended destinations.
このパラダイムは、デバイスが1つのネットワーク転送呼び出しで多くの宛先にメッセージを送信することを意味します。マルチキャストは、存在センサーが一連の照明デバイスに存在メッセージを送信する照明に適しています。マルチキャストは、メッセージが厳しい時間制約内で配信される確率を高めます。推奨されるマルチキャストアルゴリズム（[RFC7731]など）は、意図したすべての宛先にメッセージを配信するメカニズムを提供します。
In the case of the SS paradigm applied to a wireless subnetwork to a server reachable via a border router, the use of RPL [RFC6550] in non-storing mode is appropriate. Given the low resources of the devices, source routing will be used from the border router to the destination in the wireless subnetwork for messages generated outside the mesh network. No specific timing constraints are associated with the SS-type messages, so network repair does not violate the operational constraints. When no SS traffic takes place, it is good practice to load only RPL code that enables the P2P mode of operation [RFC6997] to reduce the code size and satisfy memory requirements.
ボーダールーター経由で到達可能なサーバーへの無線サブネットワークに適用されるSSパラダイムの場合、非保存モードでのRPL [RFC6550]の使用が適切です。デバイスのリソースが少ない場合、メッシュサブネットワークの外部で生成されたメッセージには、境界ルーターからワイヤレスサブネットワークの宛先へのソースルーティングが使用されます。 SSタイプのメッセージには特定のタイミング制約が関連付けられていないため、ネットワークの修復は運用上の制約に違反しません。 SSトラフィックが発生しない場合は、P2P動作モード[RFC6997]を有効にするRPLコードのみをロードして、コードサイズを縮小し、メモリ要件を満たすことをお勧めします。
To assure responsiveness, P2P-RPL [RFC6997] is required for all P2P and P2MP traffic taking place between nodes within a wireless subnetwork (excluding the border router). Source and destination devices are typically physically close, based on room layout. Consequently, most P2P and P2MP traffic is one-hop or two-hop traffic. Appendix A identifies shortcomings of using RPL for this type of communication; these shortcomings are counteracted through the use of P2P-RPL. Appendix B explains why reliability measures such as multipath routing are necessary even when one-hop communication dominates.
応答性を保証するために、ワイヤレスサブネットワーク（境界ルーターを除く）内のノード間で発生するすべてのP2PおよびP2MPトラフィックにはP2P-RPL [RFC6997]が必要です。部屋のレイアウトに基づいて、送信元デバイスと宛先デバイスは通常、物理的に近接しています。したがって、ほとんどのP2PおよびP2MPトラフィックは1ホップまたは2ホップのトラフィックです。付録Aは、このタイプの通信にRPLを使用する場合の欠点を示しています。これらの欠点は、P2P-RPLを使用することで解消されます。付録Bでは、1ホップ通信が支配的である場合でも、マルチパスルーティングなどの信頼性対策が必要な理由について説明します。
Examples of additional advantages of P2P-RPL for home and building automation networks are as follows:
ホームおよびビルディングオートメーションネットワークのP2P-RPLのその他の利点の例は次のとおりです。
o Individual wall switches are typically inexpensive Class 0 devices [RFC7228] with extremely low memory capacities. Multi-purpose remote controls for use in a home environment typically have more memory, but such devices are asleep when there is no user activity. P2P-RPL reactive discovery allows a node to wake up and find new routes within a few seconds, while memory-constrained nodes only have to keep routes to relevant targets.
o 個々の壁スイッチは、通常、メモリ容量が非常に少ない安価なクラス0デバイス[RFC7228]です。家庭環境で使用する多目的リモートコントロールは、通常、より多くのメモリを備えていますが、そのようなデバイスは、ユーザーアクティビティがないときはスリープ状態です。 P2P-RPLリアクティブディスカバリにより、ノードはウェイクアップして数秒以内に新しいルートを見つけることができますが、メモリに制約のあるノードは関連するターゲットへのルートを維持するだけで済みます。
o The reactive discovery features of P2P-RPL ensure that commands are normally delivered within the 250 ms time window. When connectivity needs to be restored, discovery is typically completed within seconds. In most cases, an alternative route (a route that was discovered earlier) will work and route rediscovery is not necessary.
o P2P-RPLのリアクティブディスカバリ機能により、コマンドは通常250ミリ秒の時間枠内で配信されます。接続を復元する必要がある場合、通常、検出は数秒以内に完了します。ほとんどの場合、代替ルート（以前に発見されたルート）が機能し、ルートの再検出は必要ありません。
o Broadcast storms typically associated with route discovery for the Ad hoc On-Demand Distance Vector (AODV) [RFC3561] are less disruptive for P2P-RPL. P2P-RPL has a "Stop" bit, which is set by the target of a route discovery to notify all other nodes that no more Destination-Oriented Directed Acyclic Graph (DODAG) Information Object (DIO) messages should be forwarded for this temporary DAG. Something that looks like a broadcast storm may happen when no target is responding; however, in this case, the Trickle suppression mechanism kicks in, limiting the number of DIO forwards in dense networks.
o アドホックオンデマンド距離ベクトル（AODV）[RFC3561]のルートディスカバリに通常関連付けられているブロードキャストストームは、P2P-RPLの中断が少ないです。 P2P-RPLには「ストップ」ビットがあり、これはルート検出のターゲットによって設定され、他のすべてのノードに、この一時的なDAGに宛先指向の非循環グラフ（DODAG）情報オブジェクト（DIO）メッセージを転送する必要がないことを通知します。ターゲットが応答していないときに、ブロードキャストストームのように見えることが発生する可能性があります。ただし、この場合、トリクル抑制メカニズムが作動し、高密度ネットワークでのDIO転送の数が制限されます。
Due to the limited memory of the majority of devices, P2P-RPL SHOULD be deployed with source routing in non-storing mode, as explained in Section 4.1.2.
大部分のデバイスのメモリは限られているため、P2P-RPLは、セクション4.1.2で説明されているように、非保存モードのソースルーティングで展開する必要があります（SHOULD）。
Multicast with the Multicast Protocol for Low-Power and Lossy Networks (MPL) [RFC7731] is preferably deployed for N-cast over the wireless network. Configuration constraints that are necessary to meet reliability and timeliness with MPL are discussed in Section 4.1.7.
低電力および損失の多いネットワーク（MPL）のマルチキャストプロトコルを使用したマルチキャスト[RFC7731]は、ワイヤレスネットワークを介したNキャスト用に展開することが好ましい。 MPLで信頼性と適時性を満たすために必要な構成の制約については、セクション4.1.7で説明します。
This document applies to [IEEE802.15.4] and [G.9959], which are adapted to IPv6 by the adaptation layers [RFC4944] and [RFC7428]. Other Layer 2 technologies, accompanied by an "IP-over-Foo" specification, are also relevant, provided there is no frame size issue and there are link-layer acknowledgements.
このドキュメントは、アダプテーション層[RFC4944]および[RFC7428]によってIPv6に適応された[IEEE802.15.4]および[G.9959]に適用されます。 「IP-over-Foo」仕様を伴う他のレイヤー2テクノロジーも関連します。ただし、フレームサイズの問題がなく、リンクレイヤーの確認応答がある場合に限ります。
The above-mentioned adaptation layers leverage on the compression capabilities of [RFC6554] and [RFC6282]. Header compression allows small IP packets to fit into a single Layer 2 frame, even when source routing is used. A network diameter limited to five hops helps to achieve this, even while using source routing.
上記のアダプテーション層は、[RFC6554]と[RFC6282]の圧縮機能を活用しています。ヘッダー圧縮により、ソースルーティングが使用されている場合でも、小さなIPパケットを1つのレイヤー2フレームに収めることができます。 5ホップに制限されたネットワークの直径は、ソースルーティングを使用している場合でも、これを達成するのに役立ちます。
Dropped packets are often experienced in the targeted environments. Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), and even Transmission Control Protocol (TCP) flows may benefit from link-layer unicast acknowledgements and retransmissions. Link-layer unicast acknowledgements SHOULD be enabled when [IEEE802.15.4] or [G.9959] is used with RPL and P2P-RPL.
ドロップされたパケットは、ターゲット環境でよく発生します。インターネット制御メッセージプロトコル（ICMP）、ユーザーデータグラムプロトコル（UDP）、さらには伝送制御プロトコル（TCP）のフローでも、リンク層のユニキャスト受信確認と再送信の恩恵を受けることができます。 [IEEE802.15.4]または[G.9959]がRPLおよびP2P-RPLで使用される場合、リンク層ユニキャスト確認応答を有効にする必要があります（SHOULD）。
Several features required by [RFC5826] and [RFC5867] challenge the P2P paths provided by RPL. Appendix A reviews these challenges. In some cases, a node may need to spontaneously initiate the discovery of a path towards a desired destination that is neither the root of a DAG nor a destination originating Destination Advertisement Object (DAO) signaling. Furthermore, P2P paths provided by RPL are not satisfactory in all cases because they involve too many intermediate nodes before reaching the destination.
[RFC5826]と[RFC5867]が必要とするいくつかの機能は、RPLが提供するP2Pパスに挑戦します。付録Aでは、これらの課題について説明します。場合によっては、ノードは、DAGのルートでも宛先である宛先アドバタイズメントオブジェクト（DAO）シグナリングでもない、目的の宛先へのパスの検出を自発的に開始する必要があります。さらに、RPLが提供するP2Pパスは、宛先に到達する前に中間ノードが多すぎるため、すべての場合に満足できるものではありません。
P2P-RPL [RFC6997] SHOULD be used in home automation and building control networks, as traffic of a point-to-point style is substantial and route repair needs to be completed within seconds. P2P-RPL provides a reactive mechanism for quick, efficient, and root-independent route discovery/repair. The use of P2P-RPL furthermore allows data traffic to avoid having to go through a central region around the root of the tree and drastically reduces path length [SOFT11] [INTEROP12]. These characteristics are desirable in home and building automation networks because they substantially decrease unnecessary network congestion around the root of the tree.
P2P-RPL [RFC6997]ポイントツーポイントスタイルのトラフィックが大量であり、ルートの修復を数秒で完了する必要があるため、ホームオートメーションおよびビルディングコントロールネットワークで使用する必要があります（SHOULD）。 P2P-RPLは、ルートに依存しない迅速で効率的なルート検出/修復のための反応メカニズムを提供します。さらに、P2P-RPLを使用すると、データトラフィックがツリーのルートの周りの中央領域を通過する必要がなくなり、パス長が大幅に短縮されます[SOFT11] [INTEROP12]。これらの特性は、ツリーのルート周辺の不要なネットワーク輻輳を大幅に減らすため、ホームおよびビルディングオートメーションネットワークに適しています。
When more reliability is required, P2P-RPL enables the establishment of multiple independent paths. For one-hop destinations, this means that one one-hop communication and a second two-hop communication take place via a neighboring node. Such a pair of redundant communication paths can be achieved by using MPL, where the source is an MPL Forwarder while a second MPL Forwarder is one hop away from both the source and the destination node. When the source multicasts the message, it may be received by both the destination and the second MPL Forwarder. The second MPL Forwarder forwards the message to the destination, thus providing two routes from sender to destination.
より高い信頼性が必要な場合、P2P-RPLは複数の独立したパスの確立を可能にします。 1ホップの宛先の場合、これは、1つの1ホップ通信と2番目の2ホップ通信が隣接ノードを介して行われることを意味します。このような冗長通信パスのペアは、MPLを使用して実現できます。この場合、ソースはMPLフォワーダーであり、2番目のMPLフォワーダーはソースノードと宛先ノードの両方から1ホップ離れています。ソースがメッセージをマルチキャストすると、宛先と2番目のMPLフォワーダーの両方がメッセージを受信する可能性があります。 2番目のMPLフォワーダーはメッセージを宛先に転送し、送信者から宛先への2つのルートを提供します。
To provide more reliability with multiple paths, P2P-RPL can maintain two independent P2P source routes per destination, at the source. Good practice is to use the paths alternately to assess their existence. When one P2P path has failed (possibly only temporarily), as described in Appendix B, the alternative P2P path can be used without discarding the failed path. The failed P2P path, unless proven to work again, can be safely discarded after a timeout (typically 15 minutes). A new route discovery is done when the number of P2P paths is exhausted due to persistent link failures.
複数のパスで信頼性を高めるために、P2P-RPLは送信元で宛先ごとに2つの独立したP2Pソースルートを維持できます。パスを交互に使用して、それらの存在を評価することをお勧めします。付録Bで説明されているように、1つのP2Pパスに障害が発生した場合（おそらく一時的にのみ）、障害が発生したパスを破棄せずに代替P2Pパスを使用できます。障害が発生したP2Pパスは、再び機能することが証明されない限り、タイムアウト（通常は15分）後に安全に破棄できます。永続的なリンク障害が原因でP2Pパスの数が使い果たされると、新しいルート検出が行われます。
P2P-RPL SHOULD be used in home automation and building control networks. Its reactive discovery allows for low application response times, even when on-the-fly route repair is needed. Non-storing mode SHOULD be used to reduce memory consumption in repeaters with constrained memory when source routing is used.
P2P-RPLは、ホームオートメーションおよびビルディングコントロールネットワークで使用する必要があります（SHOULD）。そのリアクティブディスカバリにより、オンザフライルート修復が必要な場合でも、アプリケーションの応答時間を短縮できます。非格納モードは、ソースルーティングが使用されている場合に、メモリが制限されているリピーターのメモリ消費を減らすために使用する必要があります。
An important constraint on the application of RPL is the presence of sleeping nodes.
RPLの適用に関する重要な制約は、スリープ状態のノードの存在です。
For example, in a stand-alone network, the master node (or coordinator) providing the logical Layer 2 identifier and unique node identifiers to connected nodes may be a remote control that returns to sleep once new nodes have been added. Due to the absence of the border router, there may be no global routable prefixes at all. Likewise, there may be no authoritative always-on root node, since there is no border router to host this function.
たとえば、スタンドアロンネットワークでは、接続されたノードに論理レイヤー2識別子と一意のノード識別子を提供するマスターノード（またはコーディネーター）は、新しいノードが追加されるとスリープ状態に戻るリモートコントロールになる場合があります。ボーダールーターがないため、ルーティング可能なグローバルプレフィックスがまったくない場合があります。同様に、この機能をホストする境界ルーターがないため、信頼できる常時ルートノードがない可能性があります。
In a network with a border router and many sleeping nodes, there may be battery-powered sensors and wall controllers configured to contact other nodes in response to events and then return to sleep. Such nodes may never detect the announcement of new prefixes via multicast.
境界ルーターと多くのスリープノードがあるネットワークでは、イベントに応答して他のノードに接続し、スリープに戻るように構成されたバッテリー駆動のセンサーとウォールコントローラーが存在する場合があります。そのようなノードは、マルチキャストを介して新しいプレフィックスのアナウンスを検出することはありません。
In each of the above-mentioned constrained deployments, a link-layer node (e.g., coordinator or master) SHOULD assume the role of an authoritative root node, transmitting unicast Router Advertisement (RA) messages with a Unique Local Address (ULA) prefix information option to nodes during the joining process to prepare the nodes for a later operational phase, where a border router is added.
上記の制約された展開のそれぞれにおいて、リンク層ノード（たとえば、コーディネーターまたはマスター）は、信頼できるルートノードの役割を担い、一意のローカルアドレス（ULA）プレフィックス情報を含むユニキャストルーターアドバタイズ（RA）メッセージを送信する必要があります。参加プロセス中にノードにオプションを追加して、ノードを後の運用段階に備え、境界ルーターを追加します。
A border router SHOULD be designed to be aware of sleeping nodes in order to support the distribution of updated global prefixes to such sleeping nodes.
境界ルーターは、更新されたグローバルプレフィックスのそのようなスリープノードへの配布をサポートするために、スリープノードを認識するように設計する必要があります（SHOULD）。
When operating P2P-RPL on a stand-alone basis, there is no authoritative root node maintaining a permanent RPL DODAG. A node MUST be able to join at least one RPL Instance, as a new, temporary instance is created during each P2P-RPL route discovery operation. A node MAY be designed to join multiple RPL Instances.
P2P-RPLをスタンドアロンで操作する場合、永続的なRPL DODAGを維持する権限のあるルートノードはありません。各P2P-RPLルートディスカバリ操作中に新しい一時的なインスタンスが作成されるため、ノードは少なくとも1つのRPLインスタンスに参加できる必要があります。ノードは、複数のRPLインスタンスに参加するように設計される場合があります。
Non-storing mode MUST be used to cope with the extremely constrained memory of a majority of nodes in the network (such as individual light switches).
非保存モードは、ネットワーク内の大多数のノード（個々のライトスイッチなど）の非常に制約されたメモリに対処するために使用する必要があります。
Nodes send DAO messages to establish downward paths from the root to themselves. In order to minimize the power consumption overhead associated with path discovery, DAO messages are not acknowledged in networks composed of battery-operated field devices. The DAO messages build up a source route because the nodes MUST be in non-storing mode.
ノードはDAOメッセージを送信して、ルートから自身への下りパスを確立します。パス検出に関連する電力消費のオーバーヘッドを最小限に抑えるために、DAOメッセージは、バッテリ駆動のフィールドデバイスで構成されるネットワークでは確認されません。ノードは非保存モードでなければならないため、DAOメッセージはソースルートを構築します。
If devices in LLNs participate in multiple RPL Instances and DODAGs, both the RPLInstance ID and the DODAGID SHOULD be included in the DAO.
LLNのデバイスが複数のRPLインスタンスとDODAGに参加している場合、RPLInstance IDとDODAGIDの両方をDAOに含める必要があります（SHOULD）。
Expected Transmission Count (ETX) is the RECOMMENDED metric. [RFC6551] provides other options.
Expected Transmission Count（ETX）はRECOMMENDEDメトリックです。 [RFC6551]は他のオプションを提供します。
Packets from asymmetric and/or unstable links SHOULD be deleted at Layer 2.
非対称および/または不安定なリンクからのパケットは、レイヤー2で削除する必要があります。
Objective Function Zero (OF0) [RFC6552] MUST be the Objective Function. Other Objective Functions MAY be used when dictated by circumstances.
目的関数ゼロ（OF0）[RFC6552]は目的関数でなければなりません。その他の目的関数は、状況に応じて使用できる場合があります。
Since P2P-RPL only creates DODAGs on a temporary basis during route repair or route discovery, there is no need to repair DODAGs.
P2P-RPLは、ルートの修復またはルートの検出中に一時的にDODAGを作成するだけなので、DODAGを修復する必要はありません。
For SS traffic, local repair is sufficient. The accompanying process is known as "poisoning" and is described in Section 8.2.2.5 of [RFC6550]. Given that the majority of nodes in the building do not physically move around, creating new DODAGs should not happen frequently.
SSトラフィックの場合、ローカルの修復で十分です。付随するプロセスは「ポイズニング」と呼ばれ、[RFC6550]のセクション8.2.2.5で説明されています。建物内のノードの大部分は物理的に移動しないので、新しいDODAGの作成は頻繁に行われるべきではありません。
Commercial lighting deployments may have a need for multicast to distribute commands to a group of lights in a timely fashion. Several mechanisms exist for achieving such functionality; [RFC7731] is the RECOMMENDED protocol for home and building deployments. This section relies heavily on the conclusions of [RT-MPL].
商用照明の導入では、コマンドを適時に照明のグループに配信するためにマルチキャストが必要になる場合があります。このような機能を実現するためのメカニズムがいくつかあります。 [RFC7731]は、住宅および建物の導入に推奨されるプロトコルです。このセクションは、[RT-MPL]の結論に大きく依存しています。
At reception of a packet, the MPL Forwarder starts a series of consecutive Trickle timer intervals, where the first interval has a minimum size of Imin. Each consecutive interval is twice as long as the former, with a maximum value of Imax. There is a maximum number of intervals given by max_expiration. For each interval of length I, a time t is randomly chosen in the period [I/2, I]. For a given packet, p, MPL counts the number of times it receives p during the period [0, t] in a counter c. At time t, MPL rebroadcasts p when c < k, where k is a predefined constant with a value k > 0.
パケットの受信時に、MPLフォワーダーは一連の連続したトリクルタイマー間隔を開始します。最初の間隔の最小サイズはIminです。連続する各間隔は前者の2倍の長さで、最大値はImaxです。 max_expirationによって指定される間隔の最大数があります。長さIの各間隔について、期間[I / 2、I]で時間tがランダムに選択されます。所定のパケットpについて、MPLは[0、t]の期間中にカウンターcでpを受信した回数をカウントします。時間tで、MPLはc <kのときにpを再ブロードキャストします。ここで、kは値k> 0の事前定義された定数です。
The density of forwarders and the frequency of message generation are important aspects to obtain timeliness during control operations. A high frequency of message generation can be expected when a remote-control button is incessantly pressed or when alarm situations arise.
フォワーダーの密度とメッセージ生成の頻度は、制御操作中に適時性を得るための重要な側面です。リモコンのボタンを押し続けるか、アラームが発生すると、メッセージが頻繁に生成されることが予想されます。
Guaranteeing timeliness is intimately related to the density of the MPL routers. In ideal circumstances, the message is propagated as a single wave through the network, such that the maximum delay is related to the number of hops times the smallest repetition interval of MPL. Each forwarder that receives the message passes the message on to the next hop by repeating the message. When several copies of a message reach the forwarder, it is specified that the copy need not be repeated. Repetition of the message can be inhibited by a small value of k. To assure timeliness, the chosen value of k should be high enough to make sure that messages are repeated at the first arrival of the message in the forwarder. However, a network that is too dense leads to a saturation of the medium that can only be prevented by selecting a low value of k. Consequently, timeliness is assured by choosing a relatively high value of k but assuring at the same time a low enough density of forwarders to reduce the risk of medium saturation. Depending on the reliability of the network links, it is advisable to configure the density of the network such that at least two forwarders per hop repeat messages to the same set of destinations.
適時性の保証は、MPLルーターの密度に密接に関連しています。理想的な状況では、メッセージはネットワークを介して単一の波として伝播されるため、最大遅延はホップ数にMPLの最小繰り返し間隔を掛けた値に関連しています。メッセージを受信する各フォワーダーは、メッセージを繰り返すことにより、メッセージを次のホップに渡します。メッセージの複数のコピーがフォワーダーに到達した場合、コピーを繰り返す必要がないことが指定されています。メッセージの繰り返しは、小さな値kによって抑制できます。適時性を保証するために、選択されたkの値は、フォワーダーにメッセージが最初に到着したときにメッセージが繰り返されることを確実にするのに十分な高さにする必要があります。ただし、密度が高すぎるネットワークは媒体の飽和を招き、kの低い値を選択することによってのみ防止できます。したがって、比較的高い値のkを選択することで適時性が保証されますが、同時に、中程度の飽和のリスクを減らすために十分に低いフォワーダー密度が保証されます。ネットワークリンクの信頼性に応じて、ホップごとに少なくとも2つのフォワーダーが同じ宛先セットにメッセージを繰り返すようにネットワークの密度を構成することをお勧めします。
There are no rules about selecting forwarders for MPL. In buildings with central management tools, the forwarders can be selected, but at the time of this writing it is not possible to automatically configure the forwarder topology in the home.
MPLのフォワーダーの選択に関する規則はありません。集中管理ツールを備えた建物では、フォワーダーを選択できますが、これを書いている時点では、ホームにフォワーダートポロジを自動的に構成することはできません。
RPL MAY use unsecured RPL messages to reduce message size. If there is a single node that uses unsecured RPL messages, link-layer security MUST be used on all nodes. Therefore, all RPL messages MUST be secured using:
RPLは、メッセージのサイズを減らすために、セキュリティで保護されていないRPLメッセージを使用する場合があります。安全でないRPLメッセージを使用する単一のノードがある場合は、すべてのノードでリンク層セキュリティを使用する必要があります。したがって、すべてのRPLメッセージは以下を使用して保護する必要があります。
o RPL message security, or
o RPLメッセージセキュリティ、または
o Link-layer security, or
o リンク層セキュリティ、または
o Both RPL message security and link-layer security
o RPLメッセージセキュリティとリンク層セキュリティの両方
A symmetric key is used to secure a RPL message using either RPL message security or link-layer security. The symmetric key MUST be distributed or established in a secure fashion. There may be more than one symmetric key in use by any node at any one time. The same symmetric key MUST NOT be used for both RPL message security and link-layer security between two peer nodes.
対称キーは、RPLメッセージセキュリティまたはリンク層セキュリティのいずれかを使用してRPLメッセージを保護するために使用されます。対称鍵は、安全な方法で配布または確立する必要があります。どのノードでも同時に複数の対称鍵が使用されている場合があります。 2つのピアノード間のRPLメッセージセキュリティとリンク層セキュリティの両方に同じ対称鍵を使用してはなりません（MUST NOT）。
The scope of symmetric key distribution MUST be no greater than the network itself, i.e., a group key. This document describes what needs to be implemented to meet this requirement. The scope of symmetric key distribution MAY be smaller than the network -- for example:
対称鍵配布の範囲は、ネットワーク自体、つまりグループ鍵以下でなければなりません（MUST）。このドキュメントでは、この要件を満たすために実装する必要があるものについて説明します。対称鍵配布の範囲は、ネットワークよりも小さくてもかまいません-たとえば：
o A pairwise symmetric key between two peers.
o 2つのピア間のペアワイズ対称キー。
o A group key shared between a subset of nodes in the network.
o ネットワーク内のノードのサブセット間で共有されるグループキー。
The authentication mechanism as described in Section 6.9 of [ZigBeeIP] SHALL be used to securely distribute a network-wide symmetric key.
[ZigBeeIP]のセクション6.9で説明されている認証メカニズムを使用して、ネットワーク全体の対称鍵を安全に配布する必要があります。
The purpose of the authentication procedure is to provide mutual authentication resulting in:
認証手順の目的は、次のような相互認証を提供することです。
o Preventing untrusted nodes without appropriate credentials from joining the trusted network.
o 適切な資格情報のない信頼されていないノードが信頼されたネットワークに参加するのを防ぎます。
o Preventing trusted nodes with appropriate credentials from joining an untrusted network.
o 適切な資格情報を持つ信頼されたノードが信頼されていないネットワークに参加するのを防ぎます。
There is an Authentication Server, which is responsible for authenticating the nodes on the network. If the authentication is successful, the Authentication Server sends the network security material to the joining node through the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] [RFC6345]. The joining node becomes a full participating node in the network and is able to apply Layer 2 security to RPL messages using the distributed network key.
ネットワーク上のノードの認証を担当する認証サーバーがあります。認証が成功した場合、認証サーバーは、ネットワークアクセスの認証を行うためのプロトコル（PANA）[RFC5191] [RFC6345]を介して、ネットワークセキュリティ資料を参加ノードに送信します。参加するノードは、ネットワークの完全な参加ノードになり、分散ネットワークキーを使用してRPLメッセージにレイヤ2セキュリティを適用できます。
The joining node does not initially have access to the network security material. Therefore, it is not able to apply Layer 2 security to the packets exchanged during the authentication process. The enforcement point rules at the edge of the network ensure that the packets involved in PANA authentication are processed even though they are unsecured at the Medium Access Control (MAC) layer. The rules also ensure that any other incoming traffic that is not secured at the MAC layer is discarded and is not forwarded.
参加ノードは、最初はネットワークセキュリティ資料にアクセスできません。したがって、認証プロセス中に交換されるパケットにレイヤ2セキュリティを適用することはできません。ネットワークの端にある強制ポイントルールにより、PANA認証に関係するパケットは、Medium Access Control（MAC）レイヤーで保護されていなくても確実に処理されます。また、このルールにより、MAC層で保護されていない他の着信トラフィックが破棄され、転送されなくなります。
Authentication can be viewed as a protocol stack as a layer encapsulates the layers above it.
レイヤーはその上のレイヤーをカプセル化するため、認証はプロトコルスタックと見なすことができます。
o Transport Layer Security (TLS) [RFC5246] MUST be used at the highest layer of the authentication stack and carries the authentication exchange. There is one cipher suite based on a Pre-Shared Key (PSK) [RFC6655] and one cipher suite based on Elliptic Curve Cryptography (ECC) [RFC7251].
o トランスポート層セキュリティ（TLS）[RFC5246]は、認証スタックの最上位層で使用する必要があり、認証交換を伝送します。事前共有キー（PSK）[RFC6655]に基づく暗号スイートと、楕円曲線暗号（ECC）[RFC7251]に基づく暗号スイートがあります。
o Extensible Authentication Protocol-TLS (EAP-TLS) [RFC5216] MUST be used at the next layer to carry the TLS records for the authentication protocol.
o 拡張認証プロトコル-TLS（EAP-TLS）[RFC5216]は、認証プロトコルのTLSレコードを運ぶために次の層で使用されなければなりません（MUST）。
o EAP [RFC3748] MUST be used to provide the mechanisms for mutual authentication. EAP requires a way to transport EAP packets between the joining node and the node on which the Authentication Server resides. These nodes are not necessarily in radio range of each other, so it is necessary to have multi-hop support in the EAP transport method. PANA [RFC5191] [RFC6345], which operates over UDP, MUST be used for this purpose. [RFC3748] specifies the derivation of a session key using the EAP key hierarchy; only the EAP Master Session Key shall be derived, as [RFC5191] specifies that it is used to set up keys for PANA authentication and encryption.
o EAP [RFC3748]を使用して、相互認証のメカニズムを提供する必要があります。 EAPには、参加ノードと認証サーバーが常駐するノードの間でEAPパケットを転送する方法が必要です。これらのノードは必ずしも互いに無線範囲内にあるとは限らないため、EAPトランスポート方式でマルチホップをサポートする必要があります。この目的には、UDPで動作するPANA [RFC5191] [RFC6345]を使用する必要があります。 [RFC3748]は、EAPキー階層を使用してセッションキーの派生を指定します。 [RFC5191]は、PANA認証および暗号化用のキーを設定するために使用されると指定しているため、EAPマスターセッションキーのみが導出されます。
o PANA [RFC5191] and a PANA relay [RFC6345] MUST be used at the next layer:
o PANA [RFC5191]とPANAリレー[RFC6345]を次のレイヤーで使用する必要があります。
* The joining node MUST act as the PANA Client (PaC).
* 参加ノードは、PANAクライアント（PaC）として機能する必要があります。
* The parent edge router node MUST act as a PANA Relay Element (PRE) according to [RFC6345], unless it is also the Authentication Server. All routers at the edge of the network MUST be capable of functioning in the PRE role.
* 親エッジルーターノードは、認証サーバーでもない限り、[RFC6345]に従ってPANAリレーエレメント（PRE）として機能する必要があります。ネットワークの端にあるすべてのルーターは、PREの役割で機能する必要があります。
* The Authentication Server node MUST act as the PANA Authentication Agent (PAA). The Authentication Server MUST be able to handle packets relayed according to [RFC6345].
* 認証サーバーノードは、PANA認証エージェント（PAA）として機能する必要があります。認証サーバーは、[RFC6345]に従ってリレーされたパケットを処理できる必要があります。
This network authentication process uses link-local IPv6 addresses for transport between the new node and its parent. If the parent is not the Authentication Server, it MUST then relay packets from the joining node to the Authentication Server and vice versa, using the PANA relay mechanism [RFC6345]. The joining node MUST use a link-local address based on its EUI-64 as the source address for initial PANA authentication message exchanges.
このネットワーク認証プロセスは、新しいノードとその親の間のトランスポートにリンクローカルIPv6アドレスを使用します。親が認証サーバーでない場合、PANAリレーメカニズム[RFC6345]を使用して、参加ノードから認証サーバーへ、およびその逆でパケットをリレーする必要があります。参加ノードは、最初のPANA認証メッセージ交換の送信元アドレスとして、EUI-64に基づくリンクローカルアドレスを使用する必要があります。
The following applicability statements describe the relationship between the various specifications.
以下の適用性ステートメントは、さまざまな仕様間の関係を説明しています。
[RFC6655] contains Authenticated Encryption with Associated Data (AEAD) TLS cipher suites that are very similar to [RFC5487], whose AEAD part is detailed in [RFC5116]. [RFC5487] references both [RFC5288] and the original PSK cipher suite document [RFC4279], which references RFC 2246, which was eventually replaced by [RFC5246], which defines the TLS 1.2 messages.
[RFC6655]には、[RFC5487]によく似た、関連データを伴う認証済み暗号化（AEAD）TLS暗号スイートが含まれており、そのAEAD部分は[RFC5116]で詳しく説明されています。 [RFC5487]は、[RFC5288]と元のPSK暗号スイートドキュメント[RFC4279]の両方を参照します。これは、RFC 2246を参照しますが、最終的には、TLS 1.2メッセージを定義する[RFC5246]に置き換えられました。
[RFC7251] contains AEAD TLS cipher suites that are very similar to [RFC5289], whose AEAD part is detailed in [RFC5116]. [RFC5289] references the original ECC cipher suite document [RFC4492], which references RFC 2246, which was eventually replaced by [RFC5246], which defines the TLS 1.2 messages.
[RFC7251]には、[RFC5289]によく似たAEAD TLS暗号スイートが含まれています。そのAEAD部分については[RFC5116]で詳しく説明されています。 [RFC5289]は元のECC暗号スイートドキュメント[RFC4492]を参照します。これはRFC 2246を参照し、最終的にはTLS 1.2メッセージを定義する[RFC5246]に置き換えられました。
[RFC5216] specifies how [RFC3748] is used to package [RFC5246] TLS records into EAP packets. [RFC5191] provides transportation for the EAP packets and the network-wide key carried in an encrypted Attribute-Value Pair (AVP) as specified in [RFC6786]. The proposed Pseudorandom Function (PRF) and authentication (AUTH) hashes based on SHA-256 are represented as specified in [RFC7296] and detailed in [RFC4868].
[RFC5216]は、[RFC3748]を使用して[RFC5246] TLSレコードをEAPパケットにパッケージ化する方法を指定します。 [RFC5191]は、[RFC6786]で指定されている暗号化された属性値ペア（AVP）で運ばれるEAPパケットとネットワーク全体のキーの転送を提供します。 SHA-256に基づく提案された疑似ランダム関数（PRF）と認証（AUTH）ハッシュは、[RFC7296]で指定され、[RFC4868]で詳述されているように表されます。
If RPL is used with secured messages [RFC6550], the following RPL security parameter values SHOULD be used:
保護されたメッセージでRPLを使用する場合[RFC6550]、次のRPLセキュリティパラメータ値を使用する必要があります（SHOULD）。
o Counter is Time (T) flag = 0: Do not use the timestamp in the Counter field. Counters based on timestamps are typically more applicable to industrial networks, where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization; therefore, a monotonically increasing counter is more appropriate.
o カウンターは時間（T）フラグ= 0：カウンターフィールドでタイムスタンプを使用しないでください。タイムスタンプに基づくカウンタは、通常、ノード間の厳密なタイミング同期が実装されることが多い産業用ネットワークにより適しています。ホームネットワークとビルディングネットワークは通常、このような厳密なタイミング同期を実装していません。したがって、単調増加するカウンターの方が適切です。
o Algorithm = 0: Use Counter with the Cipher Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with AES-128. This is the only assigned mode at present.
o アルゴリズム= 0：AES-128で暗号ブロック連鎖メッセージ認証コード（CBC-MACモード）（CCM）でカウンターを使用します。これが現在割り当てられている唯一のモードです。
o Key Identifier Mode (KIM) = 10: Use a group key, Key Source present, and Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.
o キー識別子モード（KIM）= 10：グループキーを使用し、キーソースが存在し、キーインデックスが存在します。ホームネットワークまたはビルディングネットワークの比較的限定された境界を考えると、ノード間で送信されるRPLメッセージを保護するには、通常グループキーで十分です。 Key Sourceフィールドを使用すると、ネットワーク内で複数のグループキーを使用できます。
o Security Level (LVL) = 0: Use MAC-32. This is recommended, as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary, given the relatively non-confidential nature of RPL message payloads.
o セキュリティレベル（LVL）= 0：MAC-32を使用します。 RPLメッセージの整合性保護が基本的な要件であるため、これが推奨されます。 RPLメッセージのペイロードは比較的機密性が低いため、暗号化が必要になることはほとんどありません。
[RFC6997] MUST be used to accommodate P2P traffic, which is typically substantial in home and building automation networks.
[RFC6997]は、P2Pトラフィックに対応するために使用する必要があります。これは、通常、ホームおよびビルディングオートメーションネットワークで重要です。
Assigned IP addresses MUST be routable and unique within the routing domain [RFC5889].
割り当てられたIPアドレスはルーティング可能で、ルーティングドメイン内で一意である必要があります[RFC5889]。
No particular requirements exist for Layer 2, except for those cited in the "IP-over-Foo" RFCs (see Section 2.3).
「IP-over-Foo」RFCで引用されているものを除いて、レイヤー2には特定の要件はありません（セクション2.3を参照）。
Not applicable
適用できません
Not applicable
適用できません
4.2.3. IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Options Assumed
4.2.3. IPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）オプションを想定
Not applicable
適用できません
Not applicable
適用できません
The following sections describe the recommended parameter values for P2P-RPL and Trickle.
以下のセクションでは、P2P-RPLおよびTrickleの推奨パラメーター値について説明します。
Trickle is used to distribute network parameter values to all nodes without stringent time restrictions. The recommended Trickle parameter values are:
トリクルは、厳しい時間制限なしにすべてのノードにネットワークパラメータ値を配布するために使用されます。推奨されるトリクルパラメータ値は次のとおりです。
o DIOIntervalMin 4, which translates to 16 ms
o DIOIntervalMin 4、16ミリ秒に変換
o DIOIntervalDoublings 14
o DIOIntervalDoublings 14
o DIORedundancyConstant 1
o DIORedundancyConstant 1
When a node sends a changed DIO, this is an inconsistency and forces the receiving node to respond within Imin. So, when something happens that affects the DIO, the change is ideally communicated to a node that is n hops away, within n times Imin. Often, depending on the node density, packets are lost or are not sent, leading to larger delays.
ノードが変更されたDIOを送信する場合、これは不整合であり、受信ノードがImin内で応答するように強制します。したがって、DIOに影響を与える何かが発生した場合、変更は、n倍のImin以内にnホップ離れたノードに伝達されるのが理想的です。多くの場合、ノードの密度によっては、パケットが失われたり送信されなかったりして、遅延が大きくなります。
In general, we can expect DIO changes to propagate within 1 to 3 seconds within the envisaged networks.
一般的に、DIOの変更は想定されるネットワーク内で1〜3秒以内に伝播することが期待できます。
When nothing happens, the DIO sending interval increases to 4.37 minutes, thus drastically reducing the network load. When a node does not receive DIO messages for more than 10 minutes, it can safely conclude that the connection with other nodes has been lost.
何も起こらない場合、DIO送信間隔は4.37分に増加し、ネットワーク負荷が大幅に軽減されます。ノードが10分以上DIOメッセージを受信しない場合、他のノードとの接続が失われたと安全に結論付けることができます。
This section discusses the P2P-RPL parameters.
このセクションでは、P2P-RPLパラメータについて説明します。
P2P-RPL [RFC6997] provides the features requested by [RFC5826] and [RFC5867]. P2P-RPL uses a subset of the frame formats and features defined for RPL [RFC6550] but may be combined with RPL frame flows in advanced deployments.
P2P-RPL [RFC6997]は、[RFC5826]および[RFC5867]によって要求された機能を提供します。 P2P-RPLは、RPL [RFC6550]に定義されているフレーム形式と機能のサブセットを使用しますが、高度な展開ではRPLフレームフローと組み合わせることができます。
The recommended parameter values for P2P-RPL are:
P2P-RPLの推奨パラメーター値は次のとおりです。
o MinHopRankIncrease 1
o MinHopRankIncrease 1
o MaxRankIncrease 0
o MaxRankIncrease 0
o MaxRank 6
o MaxRank 6
o Objective Function: OF0
o 目的関数：OF0
MPL is used to distribute values to groups of devices. Using MPL, based on the Trickle algorithm, timeliness should also be guaranteed. A deadline of 200 ms needs to be met when human action is followed by an immediately observable action such as switching on lights. The deadline needs to be met in a building where the number of hops from seed to destination varies between 1 and 10.
MPLは、デバイスのグループに値を配布するために使用されます。 Trickleアルゴリズムに基づくMPLを使用すると、適時性も保証されます。 200 msの期限は、人間の行動に続いて、ライトのスイッチをオンにするなど、すぐに観察可能な行動が続く場合に満たす必要があります。期限は、シードから宛先へのホップ数が1〜10の間で変化する建物で満たす必要があります。
When the network is heavily loaded, MAC delays contribute significantly to the end-to-end delays when MPL intervals between 10 and 100 ms are used to meet the 200 ms deadline. It is possible to set the number of buffers in the MAC to 1 and set the number of back-off repetitions to 1. The number of MPL repetitions compensates for the reduced probability of transmission per MAC invocation [RT-MPL].
ネットワークの負荷が高い場合、200ミリ秒の期限を満たすために10〜100ミリ秒のMPL間隔を使用すると、MAC遅延がエンドツーエンドの遅延に大きく影響します。 MACのバッファ数を1に設定し、バックオフの繰り返し数を1に設定することができます。MPLの繰り返し数は、MAC呼び出しごとの送信確率の低下を補います[RT-MPL]。
In addition, end-to-end delays and message losses are reduced by adding a real-time layer between MPL and MAC to throw away the earliest messages (exploiting the MPL message numbering) and favor the most recent ones.
さらに、MPLとMACの間にリアルタイムレイヤーを追加して、最も古いメッセージを破棄し（MPLメッセージの番号付けを利用）、最新のメッセージを優先することで、エンドツーエンドの遅延とメッセージ損失が削減されます。
This section proposes values for the Trickle parameters used by MPL for the distribution of packets that need to meet a 200 ms deadline. The probability of meeting the deadline is increased by (1) choosing a small Imin value, (2) reducing the number of MPL intervals, thus reducing the load, and (3) reducing the number of MPL Forwarders to also reduce the load.
このセクションでは、200ミリ秒の期限を満たす必要のあるパケットの配信のためにMPLによって使用されるトリクルパラメータの値を提案します。 （1）小さいImin値を選択し、（2）MPL間隔の数を減らして負荷を減らし、（3）MPLフォワーダーの数を減らして負荷も減らすことで、期限に達する可能性が高くなります。
The consequence of this approach is that the value of k can be larger than 1 because network load reduction is already guaranteed by the network configuration.
このアプローチの結果は、ネットワーク構成によってネットワーク負荷の軽減がすでに保証されているため、kの値が1より大きくなる可能性があることです。
Under the condition that the density of MPL repeaters can be limited, it is possible to choose low MPL repeat intervals (Imin) connected to k values such that k > 1. The minimum value of k is related to:
MPLリピーターの密度を制限できる条件下では、k> 1になるようにk値に接続された低いMPLリピート間隔（Imin）を選択できます。kの最小値は、
o The value of Imin. The length of Imin determines the number of packets that can be received within the listening period of Imin.
o Iminの値。 Iminの長さは、Iminのリスニング期間内に受信できるパケットの数を決定します。
o The number of repeaters receiving the broadcast message from the same forwarder or seed. These repeaters repeat within the same Imin interval, thus increasing the c counter.
o 同じフォワーダーまたはシードからブロードキャストメッセージを受信するリピーターの数。これらのリピーターは同じImin間隔内で繰り返すため、cカウンターが増加します。
Within the first MPL interval, a limited number, q, of messages can be transmitted. Assuming a 3 ms transmission interval, q is given by q = Imin / 3. Assuming that at most q message copies can reach a given forwarder within the first repeat interval of length Imin, the related MPL parameter values are suggested in the following sections.
最初のMPL間隔内で、限られた数qのメッセージを送信できます。 3 msの送信間隔を想定すると、qはq = Imin / 3で与えられます。長さがIminの最初の繰り返し間隔内に最大でq個のメッセージコピーが特定のフォワーダーに到達できると想定すると、関連するMPLパラメーター値が次のセクションで提案されます。
The recommended value is Imin = 10 to 50 ms.
推奨値はImin = 10〜50 msです。
When the chosen Imin value is much smaller, the interference between the copies leads to significant losses, given that q is much smaller than the number of repeated packets. With much larger intervals, the probability that the deadline will be met decreases with increasing hop count.
選択されたImin値がはるかに小さい場合、qが繰り返されるパケットの数よりもはるかに小さいとすると、コピー間の干渉により重大な損失が生じます。間隔がはるかに大きい場合、ホップカウントが増えると、期限が満たされる可能性が低くなります。
The recommended value is Imax = 100 to 400 ms.
推奨値はImax = 100〜400 msです。
The value of Imax is less important than the value of max_expiration. Given an Imin value of 10 ms, the third MPL interval has a value of 10 * 2 * 2 = 40 ms. When Imin has a value of 40 ms, the third interval has a value of 160 ms. Given that more than three intervals are unnecessary, Imax does not contribute much to performance.
Imaxの値は、max_expirationの値ほど重要ではありません。 Ims値が10ミリ秒の場合、3番目のMPL間隔の値は10 * 2 * 2 = 40ミリ秒です。 Iminの値が40ミリ秒の場合、3番目の間隔の値は160ミリ秒になります。 4つ以上の間隔が不要な場合、Imaxはパフォーマンスにあまり貢献しません。
Other parameters are the k parameter and the max_expiration parameter.
その他のパラメーターは、kパラメーターとmax_expirationパラメーターです。
k > q (see condition above). Under this condition, and for a small Imin value, a value of k = 2 or k = 3 is usually sufficient to minimize the losses of packets in the first repeat interval.
k> q（上記の条件を参照）。この条件下で、Imin値が小さい場合、通常、最初の繰り返し間隔でのパケットの損失を最小限に抑えるには、k = 2またはk = 3の値で十分です。
max_expiration = 2 - 4. Higher values lead to more network load while generating copies that will probably not meet their deadline.
max_expiration = 2-4.値が大きいほど、おそらく期限に間に合わないコピーを生成する際のネットワーク負荷が高くなります。
At this time, it is not clear how homenets will be managed. Consequently, it is not clear which tools will be used and which parameters must be visible for management.
現時点では、ホームネットがどのように管理されるかは明らかではありません。したがって、どのツールを使用するか、どのパラメーターを管理のために表示する必要があるかは明確ではありません。
In building control, management is mandatory. It is expected that installations will be managed using the set of currently available tools (including IETF tools like Management Information Base (MIB) modules, Network Configuration Protocol (NETCONF) modules, Dynamic Host Configuration Protocol (DHCP), and others), with large differences between the ways an installation is managed.
建物管理では、管理は必須です。インストールは、現在利用可能な一連のツール（管理情報ベース（MIB）モジュール、ネットワーク構成プロトコル（NETCONF）モジュール、動的ホスト構成プロトコル（DHCP）などのIETFツールを含む）を使用して管理され、大規模なインストールの管理方法の違い。
This section refers to the security considerations of [RFC6997], [RFC6550], and [RFC7731], as well as some attacks and countermeasures as discussed in Sections 6 and 7, respectively, of [RFC7416].
このセクションでは、[RFC6997]、[RFC6550]、および[RFC7731]のセキュリティの考慮事項、および[RFC7416]のセクション6および7でそれぞれ説明されているいくつかの攻撃と対策について説明します。
Communications network security is based on providing integrity protection and encryption to messages. This can be applied at various layers in the network protocol stack, based on using various credentials and a network identity.
通信ネットワークのセキュリティは、メッセージに整合性保護と暗号化を提供することに基づいています。これは、さまざまな資格情報とネットワークIDの使用に基づいて、ネットワークプロトコルスタックのさまざまな層に適用できます。
The credentials that are relevant in the case of RPL are (i) the credential used at the link layer in the case where link-layer security is applied (see Section 7.1) or (ii) the credential used for securing RPL messages. In both cases, the assumption is that the credential is a shared key. Therefore, there MUST be a mechanism in place that allows secure distribution of a shared key and configuration of a network identity. Both MAY be done using (i) pre-installation using an out-of-band method, (ii) secure delivery when a device is introduced into the network, or (iii) secure delivery by a trusted neighboring device, as described in Section 4.1.8.1. The shared key MUST be stored in a secure fashion that will make it difficult to be read by an unauthorized party.
RPLの場合に関連する資格情報は、（i）リンク層セキュリティが適用されている場合にリンク層で使用される資格情報（セクション7.1を参照）または（ii）RPLメッセージを保護するために使用される資格情報です。どちらの場合も、認証情報は共有キーであると想定されています。したがって、共有キーの安全な配布とネットワークIDの構成を可能にするメカニズムが配置されている必要があります。どちらも、（i）アウトオブバンド方式を使用したプレインストール、（ii）デバイスがネットワークに導入されたときの安全な配信、または（iii）セクションで説明されている信頼できる隣接デバイスによる安全な配信を使用して実行できます。 4.1.8.1。共有キーは安全な方法で保存する必要があり、無許可の第三者による読み取りを困難にします。
This document mandates that a Layer 2 mechanism be used during initial and incremental deployment. Please see the following sections.
このドキュメントでは、初期展開と増分展開の際にレイヤー2メカニズムを使用することを義務付けています。以下のセクションをご覧ください。
Wireless mesh networks are typically secured at the link layer in order to prevent unauthorized parties from accessing the information exchanged over the links. It is a basic practice to create a network of nodes that share the same keys for link-layer security and exclude nodes sending unsecured messages. With per-message data origin authentication, it is possible to prevent unauthorized nodes from joining the mesh.
ワイヤレスメッシュネットワークは通常、不正な当事者がリンクを介して交換される情報にアクセスできないようにするために、リンク層で保護されています。リンク層セキュリティのために同じキーを共有するノードのネットワークを作成し、セキュリティで保護されていないメッセージを送信するノードを除外することが基本的な方法です。メッセージごとのデータ発信元認証を使用すると、不正なノードがメッシュに参加するのを防ぐことができます。
At initial deployment, the network is secured by consecutively securing nodes at the link layer, thus building a network of secured nodes. Section 4.1.8.2 describes a mechanism for building a network of secured nodes.
最初の展開では、リンク層でノードを連続的に保護することでネットワークが保護され、保護されたノードのネットワークが構築されます。セクション4.1.8.2では、保護されたノードのネットワークを構築するためのメカニズムについて説明します。
This document does not specify a multicast security solution. Networks deployed with this specification will depend upon Layer 2 security to prevent outsiders from sending multicast traffic. It is recognized that this does not protect this control traffic from impersonation by already-trusted devices. This is an area for a future specification.
このドキュメントでは、マルチキャストセキュリティソリューションを指定していません。この仕様で展開されたネットワークは、外部からのマルチキャストトラフィックの送信を防ぐために、レイヤー2セキュリティに依存します。これは、すでに信頼されているデバイスによる偽装からこの制御トラフィックを保護しないことが認識されています。これは将来の仕様のための領域です。
For building control, an installer will use an installation tool that establishes a secure communication path with the joining node. It is recognized that the recommendations for initial deployment as discussed in this section do not cover all building requirements, such as selecting -- independent of network topology -- the node to be secured.
インストーラーは、制御を構築するために、参加ノードとの安全な通信パスを確立するインストールツールを使用します。このセクションで説明する初期展開の推奨事項は、ネットワークトポロジとは関係なく、セキュリティで保護するノードの選択など、すべての構築要件を網羅しているわけではありません。
It is expected that a set of protocol combinations will evolve within currently existing alliances of building control manufacturers. Each set satisfies the installation requirements of installers, operators, and manufacturers of building control networks in a given installation context, e.g., lighting deployment in offices, HVAC installation, incremental addition of equipment in homes, and others.
一連のプロトコルの組み合わせは、ビル管理メーカーの現在存在する同盟内で発展することが期待されています。各セットは、特定の設置状況での建物制御ネットワークの設置者、オペレーター、および製造業者の設置要件を満たしています。
In the home, nodes can be visually inspected by the home owner. Also, a simple procedure, e.g., pushing buttons simultaneously on an already-secured device and an unsecured joining device, is usually sufficient to ensure that the unsecured joining device is authenticated securely, configured securely, and paired appropriately.
家では、家の所有者がノードを視覚的に検査できます。また、通常は、既にセキュリティで保護されたデバイスとセキュリティで保護されていない参加デバイスで同時にボタンを押すなどの簡単な手順で、セキュリティで保護されていない参加デバイスが安全に認証され、安全に構成され、適切にペアリングされます。
This recommendation is in line with the countermeasures described in Section 7.1 of [RFC7416].
この推奨事項は、[RFC7416]のセクション7.1で説明されている対策と一致しています。
Once a network is operational, new nodes need to be added, or nodes fail and need to be replaced. When a new node needs to be added to the network, the new node is added to the network via an assisting node in the manner described in Section 7.1.
ネットワークが動作可能になったら、新しいノードを追加するか、ノードに障害が発生して交換する必要があります。新しいノードをネットワークに追加する必要がある場合、新しいノードは、7.1節で説明した方法で支援ノードを介してネットワークに追加されます。
On detection of a compromised node, all trusted nodes need to have their symmetric keys that are known to be shared with the compromised node rekeyed, and the trusted network is built up as described in Section 7.1.
危険にさらされたノードを検出すると、すべての信頼されたノードは、危険にさらされたノードと共有されることがわかっている対称鍵を再生成する必要があり、信頼されたネットワークはセクション7.1で説明されているように構築されます。
Refer to the security considerations of [RFC6997].
[RFC6997]のセキュリティに関する考慮事項を参照してください。
The routing of MPL is determined by the enabling of the interfaces for specified multicast addresses. The specification of these addresses can be done via a Constrained Application Protocol (CoAP) application as specified in [RFC7390]. An alternative is the creation of an MPL MIB and the use of the Simple Network Management Protocol (SNMPv3) [RFC3411] or equivalent techniques to specify the multicast addresses in the MIB. For secure dissemination of MPL packets, Layer 2 security SHOULD be used, and the configuration of multicast addresses as described in this section MUST be secure.
MPLのルーティングは、指定されたマルチキャストアドレスのインターフェイスを有効にすることによって決定されます。これらのアドレスの指定は、[RFC7390]で指定されている制約付きアプリケーションプロトコル（CoAP）アプリケーションを介して行うことができます。代替手段は、MPL MIBの作成と、MIBでマルチキャストアドレスを指定するための簡易ネットワーク管理プロトコル（SNMPv3）[RFC3411]または同等の技術の使用です。 MPLパケットを安全に配布するには、レイヤー2セキュリティを使用する必要があり（SHOULD）、このセクションで説明するマルチキャストアドレスの構成は安全でなければなりません（MUST）。
This section refers to the structure of Section 8 ("RPL Security Features") of [RFC7416]. [RFC7416] provides a thorough analysis of security threats and proposed countermeasures relevant to RPL and MPL.
このセクションは、[RFC7416]のセクション8（ "RPLセキュリティ機能"）の構造を参照します。 [RFC7416]は、セキュリティ脅威の徹底的な分析とRPLおよびMPLに関連する提案された対策を提供します。
In accordance with Section 8.1 ("Confidentiality Features") of [RFC7416], RPL message security implements payload protection, as explained in Section 7 of this document. The attributes for key length and lifetime of the keys depend on operational conditions, maintenance, and installation procedures.
[RFC7416]のセクション8.1（「機密性機能」）に従って、RPLメッセージセキュリティは、このドキュメントのセクション7で説明されているように、ペイロード保護を実装します。キーの長さとキーの寿命の属性は、操作条件、メンテナンス、およびインストール手順によって異なります。
Sections 7.1 and 7.2 of this document recommend link-layer security to assure integrity in accordance with Section 8.2 ("Integrity Features") of [RFC7416].
このドキュメントのセクション7.1および7.2は、[RFC7416]のセクション8.2（「整合性機能」）に従って整合性を保証するために、リンク層セキュリティを推奨しています。
The provision of multiple paths recommended in Section 8.3 ("Availability Features") of [RFC7416] is also recommended from a reliability point of view. Randomly choosing paths MAY be supported.
[RFC7416]のセクション8.3（「可用性機能」）で推奨されている複数のパスのプロビジョニングも、信頼性の観点から推奨されます。パスをランダムに選択することはサポートされるかもしれません。
A mechanism for key management, as discussed in Section 8.4 ("Key Management") of [RFC7416], is provided in Section 4.1.8.2 of this document.
[RFC7416]のセクション8.4（「キー管理」）で説明されているキー管理のメカニズムは、このドキュメントのセクション4.1.8.2で提供されています。
Application and transport protocols used in home and building automation domains are expected to mostly consist of CoAP over UDP, or equivalents. Typically, UDP is used for IP transport to keep down the application response time and bandwidth overhead. CoAP is used at the application layer to reduce memory footprint and bandwidth requirements.
ホームおよびビルディングオートメーションドメインで使用されるアプリケーションおよび転送プロトコルは、ほとんどがUDP上のCoAP、または同等のもので構成されることが期待されています。通常、UDPはIPトランスポートに使用され、アプリケーションの応答時間と帯域幅のオーバーヘッドを抑えます。アプリケーション層でCoAPを使用して、メモリのフットプリントと帯域幅の要件を削減します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J。、およびH. Levkowetz、編、「Extensible Authentication Protocol（EAP）」、RFC 3748、DOI 10.17487 / RFC3748、2004年6月、<http://www.rfc-editor.org/info/rfc3748>。
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>.
[RFC4279] Eronen、P.、Ed。およびH. Tschofenig、Ed。、 "Pre-Shared Key Ciphersuites for Transport Layer Security（TLS）"、RFC 4279、DOI 10.17487 / RFC4279、December 2005、<http：// www.rfc-editor.org/info/rfc4279>。
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.
[RFC4492] Blake-Wilson、S.、Bolyard、N.、Gupta、V.、Hawk、C。、およびB. Moeller、「Elliptic Curve Cryptography（ECC）Cipher Suites for Transport Layer Security（TLS）」、RFC 4492 、DOI 10.17487 / RFC4492、2006年5月、<http://www.rfc-editor.org/info/rfc4492>。
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[RFC4868]ケリー、S。、およびS.フランケル、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<http： //www.rfc-editor.org/info/rfc4868>。
[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>。
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>.
[RFC5116] McGrew、D。、「認証された暗号化のためのインターフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<http://www.rfc-editor.org/info/rfc5116>。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <http://www.rfc-editor.org/info/rfc5191>.
[RFC5191] Forsberg、D.、Ohba、Y.、Ed。、Patil、B.、Tschofenig、H。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）」、RFC 5191、DOI 10.17487 / RFC5191、2008年5月、<http://www.rfc-editor.org/info/rfc5191>。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>.
[RFC5216]サイモン、D。、アボバ、B。、およびR.ハースト、「EAP-TLS認証プロトコル」、RFC 5216、DOI 10.17487 / RFC5216、2008年3月、<http://www.rfc-editor.org / info / rfc5216>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, DOI 10.17487/RFC5288, August 2008, <http://www.rfc-editor.org/info/rfc5288>.
[RFC5288] Salowey、J.、Choudhury、A。、およびD. McGrew、「TLS用のAES Galois Counter Mode（GCM）Cipher Suites for TLS」、RFC 5288、DOI 10.17487 / RFC5288、2008年8月、<http：// www。 rfc-editor.org/info/rfc5288>。
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.
[RFC5289] Rescorla、E。、「SHA-256 / 384およびAES Galois Counter Mode（GCM）を使用したTLS楕円曲線暗号スイート」、RFC 5289、DOI 10.17487 / RFC5289、2008年8月、<http：//www.rfc- editor.org/info/rfc5289>。
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.
[RFC5487] Badra、M。、「SHA-256 / 384およびAES Galoisカウンターモードを使用したTLSの事前共有鍵暗号スイート」、RFC 5487、DOI 10.17487 / RFC5487、2009年3月、<http：//www.rfc- editor.org/info/rfc5487>。
[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] Hui、J.、Ed。、およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http：// www。 rfc-editor.org/info/rfc6282>。
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Relay Element", RFC 6345, DOI 10.17487/RFC6345, August 2011, <http://www.rfc-editor.org/info/rfc6345>.
[RFC6345] Duffy、P.、Chakrabarti、S.、Cragie、R.、Ohba、Y.、Ed。、およびA. Yegin、「Protocol for Carrying Authentication for Network Access（PANA）Relay Element」、RFC 6345、DOI 10.17487 / RFC6345、2011年8月、<http://www.rfc-editor.org/info/rfc6345>。
[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>。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <http://www.rfc-editor.org/info/rfc6551>.
[RFC6551] Vasseur、JP。、Ed。、Kim、M.、Ed。、Pister、K.、Dejean、N.、and D. Barthel、 "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks"、 RFC 6551、DOI 10.17487 / RFC6551、2012年3月、<http://www.rfc-editor.org/info/rfc6551>。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, DOI 10.17487/RFC6554, March 2012, <http://www.rfc-editor.org/info/rfc6554>.
[RFC6554] Hui、J.、Vasseur、JP。、Culler、D.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、RFC 6554、 DOI 10.17487 / RFC6554、2012年3月、<http://www.rfc-editor.org/info/rfc6554>。
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>.
[RFC6655] McGrew、D。およびD. Bailey、「トランスポート層セキュリティ（TLS）のAES-CCM暗号スイート」、RFC 6655、DOI 10.17487 / RFC6655、2012年7月、<http://www.rfc-editor.org / info / rfc6655>。
[RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for Carrying Authentication for Network Access (PANA) Attribute-Value Pairs", RFC 6786, DOI 10.17487/RFC6786, November 2012, <http://www.rfc-editor.org/info/rfc6786>.
[RFC6786] Yegin、A。およびR. Cragie、「ネットワークアクセスの認証を運ぶためのプロトコルの暗号化（PANA）属性と値のペア」、RFC 6786、DOI 10.17487 / RFC6786、2012年11月、<http：//www.rfc -editor.org/info/rfc6786>。
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, DOI 10.17487/RFC6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.
[RFC6997] Goyal、M.、Ed。、Baccelli、E.、Philipp、M.、Brandt、A。、およびJ. Martocci、「低電力で損失の多いネットワークにおけるポイントツーポイントルートのリアクティブディスカバリ」、 RFC 6997、DOI 10.17487 / RFC6997、2013年8月、<http://www.rfc-editor.org/info/rfc6997>。
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network", RFC 6998, DOI 10.17487/RFC6998, August 2013, <http://www.rfc-editor.org/info/rfc6998>.
[RFC6998] Goyal、M.、Ed。、Baccelli、E.、Brandt、A。、およびJ. Martocci、「低電力で損失の多いネットワークでポイントツーポイントルートに沿ってルーティングメトリックを測定するメカニズム"、RFC 6998、DOI 10.17487 / RFC6998、2013年8月、<http://www.rfc-editor.org/info/rfc6998>。
[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> 。
[RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, <http://www.rfc-editor.org/info/rfc7251>.
[RFC7251] McGrew、D.、Bailey、D.、Campagna、M。、およびR. Dugal、「AES-CCM Elliptic Curve Cryptography（ECC）Cipher Suites for TLS」、RFC 7251、DOI 10.17487 / RFC7251、2014年6月、 <http://www.rfc-editor.org/info/rfc7251>。
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296] Kaufman、C.、Hoffman、P.、Nir、Y.、Eronen、P。、およびT. Kivinen、「Internet Key Exchange Protocol Version 2（IKEv2）」、STD 79、RFC 7296、DOI 10.17487 / RFC7296 、2014年10月、<http://www.rfc-editor.org/info/rfc7296>。
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <http://www.rfc-editor.org/info/rfc7416>.
[RFC7416] Tsao、T.、Alexander、R.、Dohler、M.、Daza、V.、Lozano、A。、およびM. Richardson、編、「低電力のルーティングプロトコルのセキュリティ脅威分析Lossy Networks（RPLs）」、RFC 7416、DOI 10.17487 / RFC7416、2015年1月、<http://www.rfc-editor.org/info/rfc7416>。
[RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, February 2016, <http://www.rfc-editor.org/info/rfc7731>.
[RFC7731] Hui、J。およびR. Kelsey、「低電力および損失の多いネットワーク（MPL）のマルチキャストプロトコル」、RFC 7731、DOI 10.17487 / RFC7731、2016年2月、<http://www.rfc-editor.org / info / rfc7731>。
[IEEE802.15.4] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4, DOI 10.1109/ieeestd.2011.6012487, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.
[IEEE802.15.4] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）」、IEEE 802.15.4、DOI 10.1109 / ieeestd.2011.6012487、<http： //ieeexplore.ieee.org/servlet/ opac？punumber = 6012485>。
[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G.9959]国際電気通信連合、「短距離狭帯域デジタル無線通信トランシーバー-PHY、MAC、SARおよびLLCレイヤー仕様」、ITU-T勧告G.9959、2015年1月、<http：//www.itu。 int / rec / T-REC-G.9959>。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <http://www.rfc-editor.org/info/rfc3411>.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、DOI 10.17487 / RFC3411、2002年12月、<http ：//www.rfc-editor.org/info/rfc3411>。
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, <http://www.rfc-editor.org/info/rfc3561>.
[RFC3561] Perkins、C.、Belding-Royer、E。、およびS. Das、「Ad hoc On-Demand Distance Vector（AODV）Routing」、RFC 3561、DOI 10.17487 / RFC3561、2003年7月、<http：// www.rfc-editor.org/info/rfc3561>。
[RFC5889] Baccelli, E., Ed., and M. Townsley, Ed., "IP Addressing Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, September 2010, <http://www.rfc-editor.org/info/rfc5889>.
[RFC5889] Baccelli、E.、Ed。、and M. Townsley、Ed。、 "IP Addressing Model in Ad Hoc Networks"、RFC 5889、DOI 10.17487 / RFC5889、September 2010、<http：//www.rfc-editor .org / info / rfc5889>。
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, DOI 10.17487/RFC6552, March 2012, <http://www.rfc-editor.org/info/rfc6552>.
[RFC6552] Thubert、P。、編、「低電力および損失の多いネットワーク（RPL）のルーティングプロトコルの目的関数ゼロ」、RFC 6552、DOI 10.17487 / RFC6552、2012年3月、<http：//www.rfc -editor.org/info/rfc6552>。
[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>。
[RFC7390] Rahman, A., Ed., and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>.
[RFC7390] Rahman、A.、Ed。およびE. Dijk、Ed。、 "Group Communication for the Constrained Application Protocol（CoAP）"、RFC 7390、DOI 10.17487 / RFC7390、October 2014、<http：// www。 rfc-editor.org/info/rfc7390>。
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, <http://www.rfc-editor.org/info/rfc7428>.
[RFC7428] Brandt、A。およびJ. Buron、「ITU-T G.9959ネットワークを介したIPv6パケットの送信」、RFC 7428、DOI 10.17487 / RFC7428、2015年2月、<http://www.rfc-editor.org / info / rfc7428>。
[SOFT11] Baccelli, E., Philipp, M., and M. Goyal, "The P2P-RPL Routing Protocol for IPv6 Sensor Networks: Testbed Experiments", Proceedings of the 19th Annual Conference on Software Telecommunications and Computer Networks, Split, Croatia, September 2011.
[SOFT11] Baccelli、E.、Philipp、M。、およびM. Goyal、「IPv6センサーネットワークのP2P-RPLルーティングプロトコル：テストベッド実験」、ソフトウェア通信とコンピュータネットワークに関する第19回年次会議の議事録、クロアチア、スプリット、2011年9月。
[INTEROP12] Philipp, M., Baccelli, E., Brandt, A., Valev, H., and J. Buron, "Report on P2P-RPL Interoperability Testing", INRIA Research Report RR-7864, January 2012.
[INTEROP12] Philipp、M.、Baccelli、E.、Brandt、A.、Valev、H。、およびJ. Buron、「P2P-RPL相互運用性テストに関するレポート」、INRIA研究レポートRR-7864、2012年1月。
[RT-MPL] van der Stok, P., "Real-Time multicast for wireless mesh networks using MPL", White paper, April 2014, <http://www.vanderstok.org/papers/Real-time-MPL.pdf>.
[RT-MPL] van der Stok、P。、「MPLを使用したワイヤレスメッシュネットワークのリアルタイムマルチキャスト」、ホワイトペーパー、2014年4月、<http://www.vanderstok.org/papers/Real-time-MPL。 pdf>。
[OccuSwitch] Philips lighting Electronics, "OccuSwitch Wireless (brochure)", May 2012, <http://www.philipslightingcontrols.com/assets/ cms/uploads/files/osw/MK_OSWNETBROC_5.pdf>.
[OccuSwitch]フィリップスライティングエレクトロニクス、「OccuSwitchワイヤレス（パンフレット）」、2012年5月、<http://www.philipslightingcontrols.com/assets/ cms / uploads / files / osw / MK_OSWNETBROC_5.pdf>。
[Office-Light] Clanton and Associates, Inc., "Wireless Lighting Control - A Life Cycle Cost Evaluation of Multiple Lighting Control Strategies", February 2014, <http://www.daintree.net/ wp-content/uploads/2014/02/ clanton_lighting_control_report_0411.pdf>.
[Office-Light] Clanton and Associates、Inc。、「Wireless Lighting Control-A Life Cycle Cost Evaluation of Multiple Lighting Control Strategies」、2014年2月、<http://www.daintree.net/ wp-content / uploads / 2014 / 02 / clanton_lighting_control_report_0411.pdf>。
[RTN2011] Holtman, K. and P. van der Stok, "Real-time routing for low-latency 802.15.4 control networks", 23rd Euromicro Conference on Real-Time Systems, Porto, Portugal, July 2011.
[RTN2011] Holtman、K.およびP. van der Stok、「低遅延の802.15.4制御ネットワークのリアルタイムルーティング」、23回目のEuromicro Conference on Real-Time Systems、ポルト、ポルトガル、2011年7月。
[MEAS] Holtman, K., "Connectivity loss in large scale IEEE 802.15.4 network", Private Communication, November 2013.
[MEAS] Holtman、K.、「大規模なIEEE 802.15.4ネットワークでの接続損失」、プライベートコミュニケーション、2013年11月。
[BC-Survey] Kastner, W., Neugschwandtner, G., Soucek, S., and H. Newmann, "Communication Systems for Building Automation and Control", Proceedings of the IEEE, Vol. 93, No. 6, DOI 10.1109/JPROC.2005.849726, June 2005.
[BC-Survey] Kastner、W.、Neugschwandtner、G.、Soucek、S.、and H. Newmann、 "Communication Systems for Building Automation and Control"、Proceedings of the IEEE、Vol。 93、No。6、DOI 10.1109 / JPROC.2005.849726、2005年6月。
[ZigBeeIP] ZigBee Alliance, "ZigBee IP specification", ZigBee document 095023r34, March 2014, <http://www.zigbee.org/>.
[ZigBeeIP] ZigBee Alliance、「ZigBee IP仕様」、ZigBeeドキュメント095023r34、2014年3月、<http://www.zigbee.org/>。
The DAG, being a tree structure, is formed from a root. If nodes residing in different branches need to communicate internally, DAG mechanisms provided in RPL [RFC6550] will propagate traffic towards the root, potentially all the way to the root, and down along another branch [RFC6998]. In a typical example, two nodes could reach each other via only two router nodes, but in some unfortunate cases, RPL may send traffic three hops up and three hops down again. This leads to several undesirable phenomena, as described in the following sections.
DAGはツリー構造であり、ルートから形成されます。異なるブランチにあるノードが内部で通信する必要がある場合、RPL [RFC6550]で提供されるDAGメカニズムは、ルートに向かって、場合によってはルートに至るまで、別のブランチに沿ってトラフィックを伝搬します[RFC6998]。典型的な例では、2つのノードは2つのルーターノードだけを介して互いに到達できますが、残念なことに、RPLはトラフィックを3ホップ上、3ホップ下に送信する場合があります。これにより、次のセクションで説明するように、いくつかの望ましくない現象が発生します。
If many P2P data flows have to move up towards the root to get down again in another branch, there is an increased risk of congestion the nearer to the root of the DAG the data flows. Due to the broadcast nature of radio frequency (RF) systems, any child node of the root is not only directing RF power downwards in its sub-tree but just as much upwards towards the root, potentially jamming other MP2P traffic leaving the tree or preventing the root of the DAG from sending P2MP traffic into the DAG because the listen-before-talk link-layer protection kicks in.
多くのP2Pデータフローがルートに向かって上に移動して別のブランチで再びダウンする必要がある場合、データフローのDAGのルートに近い場所で輻輳のリスクが高まります。無線周波数（RF）システムのブロードキャストの性質により、ルートの子ノードは、サブツリーでRF電力を下向きに向けるだけでなく、ルートに向かって上向きに向け、他のMP2Pトラフィックを妨害したり、ツリーから出たりする可能性があります。 listen-before-talkリンク層保護が作動するため、DAGがP2MPトラフィックをDAGに送信することからのルート。
Battery-powered nodes originating P2P traffic depend on the route length. Long routes cause source nodes to stay awake for longer periods before returning to sleep. Thus, a longer route translates proportionally (more or less) into higher battery consumption.
P2Pトラフィックを発信するバッテリ駆動のノードは、ルートの長さに依存します。ルートが長くなると、ソースノードがスリープ状態に戻る前に、長時間起床したままになります。したがって、より長いルートは、比例して（多かれ少なかれ）より高いバッテリー消費に変換されます。
The RPL DAG mechanism uses DIO and DAO messages to monitor the health of the DAG. On rare occasions, changed radio conditions may render routes unusable just after a destination node has returned a DAO indicating that the destination is reachable. Given enough time, the next Trickle timer-controlled DIO/DAO update will eventually repair the broken routes; however, this may not occur in a timely manner appropriate to the application. In an apparently stable DAG, Trickle timer dynamics may reduce the update rate to a few times every hour. If a user issues an actuator command, e.g., light on in the time interval between the time that the last DAO message was issued the destination module and the time that one of the parents sends the next DIO, the destination cannot be reached. There is no mechanism in RPL to initiate the restoration of connectivity in a reactive fashion. The consequence is a broken service in home and building applications.
RPL DAGメカニズムは、DIOおよびDAOメッセージを使用してDAGの状態を監視します。まれに、宛先ノードが到達可能であることを示すDAOを返した直後に、無線条件が変更されるとルートが使用できなくなることがあります。十分な時間が与えられると、次のトリクルタイマー制御のDIO / DAOアップデートにより、最終的には壊れたルートが修復されます。ただし、これはアプリケーションに適したタイミングで発生しない場合があります。見かけ上安定したDAGでは、トリクルタイマーダイナミクスにより、更新レートが毎時間数回に低下することがあります。ユーザーがアクチュエータコマンドを発行した場合、たとえば、最後のDAOメッセージが宛先モジュールが発行されてから親の1人が次のDIOを送信するまでの時間間隔で点灯すると、宛先に到達できません。 RPLには、リアクティブな方法で接続の復元を開始するメカニズムはありません。その結果、家庭用および建築用アプリケーションのサービスが壊れます。
Experience from the telecom industry shows that if the voice delay exceeds 250 ms, users start getting confused, frustrated, and/or annoyed. In the same way, if the light does not turn on within the same period of time, a home control user will activate the controls again, causing a sequence of commands such as Light{on,off,off,on,off,...} or Volume{up,up,up,up,up,...}. Whether the outcome is nothing or some unintended response, this is unacceptable. A controlling system must be able to restore connectivity to recover from the error situation. Waiting for an unknown period of time is not an option. Although this issue was identified during the P2P analysis, it applies just as well to application scenarios where an IP application outside the LLN controls actuators, lights, etc.
通信業界の経験によると、音声の遅延が250ミリ秒を超えると、ユーザーは混乱したり、イライラしたり、迷惑になったりします。同様に、ライトが同じ時間内にオンにならない場合、ホームコントロールユーザーはコントロールを再度アクティブにして、Light {on、off、off、on、off、..などの一連のコマンドを発生させます。 。}またはVolume {up、up、up、up、up、...}。結果が何もないか、意図しない応答であっても、これは受け入れられません。制御システムは、エラー状態から回復するために接続を復元できる必要があります。不明な期間待機することはできません。この問題はP2P分析中に特定されましたが、LLN外のIPアプリケーションがアクチュエーター、ライトなどを制御するアプリケーションシナリオにも同様に適用されます。
Measurements of connectivity between neighboring nodes are discussed in [RTN2011] and [MEAS].
隣接ノード間の接続性の測定については、[RTN2011]と[MEAS]で説明されています。
The work is motivated by the measurements in literature that affirm that the range of an antenna is not circle symmetric but that the signal strength of a given level follows an intricate pattern around the antenna, and there may be holes within the area delineated by a polar plot. It is reported that communication is not symmetric: reception of messages from node A by node B does not imply reception of messages from node B by node A. The quality of the signal fluctuates over time, and also the height of the antenna within a room can have consequences for the range. As a function of the distance from the source, three regions are generally recognized: (1) a clear region with excellent signal quality, (2) a region with fluctuating signal quality, and (3) a region without reception. Installation of meshes with neighbors in the clear region is not sufficient, as described below.
アンテナの範囲は円対称ではないが、所定のレベルの信号強度はアンテナの周りの複雑なパターンに従い、極によって描写された領域内に穴がある可能性があることを確認する文献の測定により、この作業は動機付けられていますプロット。通信が対称的ではないことが報告されています。ノードBによるノードAからのメッセージの受信は、ノードAによるノードBからのメッセージの受信を意味しません。信号の品質は時間とともに変動し、部屋内のアンテナの高さも変動します範囲に影響を与える可能性があります。ソースからの距離の関数として、3つの領域が一般に認識されます。（1）信号品質が優れている明確な領域、（2）信号品質が変動している領域、（3）受信がない領域です。以下に説明するように、クリアな領域に隣接するメッシュをインストールするだけでは不十分です。
[RTN2011] extends existing work by:
[RTN2011]は、既存の作業を次のように拡張します。
o Observations over periods of at least a week,
o 少なくとも1週間の観察
o Testing links that are in the clear region,
o 明確な領域にあるリンクをテストし、
o Observation in an office building during working hours, and
o 勤務時間中のオフィスビルの観察、および
o Concentrating on one-hop and two-hop routes.
o 1ホップと2ホップのルートに集中します。
Eight nodes were distributed over a surface of 30 square meters. All nodes are at a one-hop distance from each other, and all are situated in each other's clear region. Each node sends messages to each of its neighbors and repeats the message until it arrives. The latency of the message was measured over periods of at least a week. It was noticed that latencies longer than a second occurred without any apparent reason, but only during working days and never during the weekends. Bad periods could last for minutes. By sending messages via two paths -- (1) a one-hop path directly and (2) a two-hop path via a randomly chosen neighbor -- the probability of delays larger than 100 ms decreased significantly.
8つのノードが30平方メートルの表面に分散されました。すべてのノードは相互に1ホップの距離にあり、すべてのノードは互いの明確な領域にあります。各ノードはメッセージを各ネイバーに送信し、到着するまでメッセージを繰り返します。メッセージの待ち時間は、少なくとも1週間にわたって測定されました。 1秒よりも長いレイテンシは明らかな理由もなく発生しましたが、営業日のみで週末には発生しませんでした。悪い期間は数分間続くことがあります。 2つのパスを介してメッセージを送信することにより、（1）1ホップパスを直接、（2）ランダムに選択したネイバーを介して2ホップパスを、100ミリ秒を超える遅延の確率が大幅に減少しました。
The conclusion is that even for one-hop communication between not-too-distant "line of sight" nodes, there are periods of low reception in which communication deadlines of 200 ms are exceeded. It pays to send a second message over a two-hop path to increase the reliability of timely message transfer.
結論として、それほど遠くない「見通し線」ノード間の1ホップ通信であっても、200ミリ秒の通信期限を超える低受信期間があります。タイムリーなメッセージ転送の信頼性を向上させるために、2ホップのパスを介して2番目のメッセージを送信することはお金になります。
[MEAS] confirms that temporary bad reception by close neighbors can occur within other types of areas. Nodes were installed on the ceiling in a grid with a distance of 30-50 cm between them. Two hundred nodes were distributed over an area of 10 m x 5 m. It clearly transpired that with increasing distance the probability of reception decreased. At the same time, a few nodes furthest away from the sender had a high probability of message reception, while some close neighbors of the sender did not receive messages. The patterns of nodes experiencing good reception evolved over time.
[MEAS]は、他のタイプのエリア内で、近接するネイバーによる一時的な受信不良が発生する可能性があることを確認しています。ノードは、それらの間の距離が30〜50 cmのグリッドの天井に設置されました。 200ノードが10 m x 5 mの領域に分散されました。距離が長くなると、受信の確率が低下することが明らかになった。同時に、送信者から最も離れたいくつかのノードはメッセージを受信する可能性が高く、送信者の一部の近接ノードはメッセージを受信しませんでした。良好な受信を経験しているノードのパターンは、時間とともに進化しました。
The conclusion here is that even for direct neighbors reception can temporarily be bad for periods of several minutes. For reliable and timely communication, it is imperative to have at least two communication paths available (e.g., two-hop paths next to the one-hop path for direct neighbors).
ここでの結論は、直接隣人であったとしても、数分間、一時的に受信が悪くなる可能性があるということです。信頼性の高いタイムリーな通信のためには、少なくとも2つの通信パスを使用できるようにすることが不可欠です（たとえば、直接隣接ルーターの1ホップパスの隣にある2ホップパス）。
Acknowledgements
謝辞
This document reflects discussions and remarks from several individuals, including (in alphabetical order) Stephen Farrell, Mukul Goyal, Sandeep Kumar, Jerry Martocci, Catherine Meadows, Yoshihiro Ohba, Charles Perkins, Yvonne-Anne Pignolet, Michael Richardson, Ines Robles, Zach Shelby, and Meral Sherazipour.
このドキュメントは、（アルファベット順で）スティーブンファレル、ムクルゴヤル、サンディープクマール、ジェリーマルトッチ、キャサリンメドウズ、大場義博、チャールズパーキンス、イボンヌアンピニョーレ、マイケルリチャードソン、イネスロブレス、ザックシェルビーを含むいくつかの個人からの議論と意見を反映しています、およびMeral Sherazipour。
Authors' Addresses
著者のアドレス
Anders Brandt Sigma Designs
Anders Brandt Sigma Designs
Email: anders_Brandt@sigmadesigns.com
Emmanuel Baccelli INRIA
エマニュエルバチェリINRIA
Email: Emmanuel.Baccelli@inria.fr
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJ United Kingdom
Robert Cragie ARM Ltd. 110 Fulbourn Road Cambridge CB1 9NJイギリス
Email: robert.cragie@arm.com
Peter van der Stok Consultant
Peter van der Stokコンサルタント
Email: consultancy@vanderstok.org