[要約] RFC 6687は、低消費電力かつ損失の多いネットワーク向けのルーティングプロトコル（RPL）の性能評価に関するものです。このRFCの目的は、RPLの性能を評価し、その改善に役立つ情報を提供することです。
Independent Submission J. Tripathi, Ed.
Request for Comments: 6687 J. de Oliveira, Ed.
Category: Informational Drexel University
ISSN: 2070-1721 JP. Vasseur, Ed.
Cisco Systems, Inc.
October 2012
Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)
低電力および損失の多いネットワーク（RPL）のルーティングプロトコルのパフォーマンス評価
Abstract
概要
This document presents a performance evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL) for a small outdoor deployment of sensor nodes and for a large-scale smart meter network. Detailed simulations are carried out to produce several routing performance metrics using these real-life deployment scenarios. Please refer to the PDF version of this document, which includes several plots for the performance metrics not shown in the plain-text version.
このドキュメントでは、センサーノードの小規模な屋外展開と大規模なスマートメーターネットワークの低電力および損失の多いネットワーク（RPL）のルーティングプロトコルのパフォーマンス評価について説明します。これらの実際の展開シナリオを使用して、いくつかのルーティングパフォーマンスメトリックを生成するために、詳細なシミュレーションが実行されます。このドキュメントのPDFバージョンを参照してください。これには、プレーンテキストバージョンには示されていないパフォーマンスメトリックのいくつかのプロットが含まれています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6687.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6687で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Methodology and Simulation Setup ................................4
4. Performance Metrics .............................................7
4.1. Common Assumptions .........................................7
4.2. Path Quality ...............................................7
4.3. Routing Table Size ........................................10
4.4. Delay Bound for P2P Routing ...............................10
4.5. Control Packet Overhead ...................................11
4.6. Loss of Connectivity ......................................13
5. RPL in a Building Automation Routing Scenario ..................18
5.1. Path Quality ..............................................18
5.2. Delay .....................................................19
6. RPL in a Large-Scale Network ...................................19
6.1. Path Quality ..............................................19
6.2. Delay .....................................................21
6.3. Control Packet Overhead ...................................21
7. Scaling Property and Routing Stability .........................22
8. Comments .......................................................24
9. Security Considerations ........................................25
10. Acknowledgements ..............................................25
11. Informative References ........................................25
Designing a routing protocol for Low-Power and Lossy Networks (LLNs) imposes great challenges, mainly due to low data rates, high probability of packet delivery failure, and strict energy constraints in the nodes. The IETF ROLL Working Group took on this task and specified the Routing Protocol for Low-Power and Lossy Networks (RPL) in [RFC6550].
Low-Power and Lossy Networks（LLNs）のルーティングプロトコルを設計すると、主にデータレートが低く、パケット配信が失敗する可能性が高く、ノードのエネルギー制限が厳しいため、大きな課題が生じます。 IETF ROLLワーキンググループはこのタスクを引き受け、[RFC6550]で低電力および損失の多いネットワーク（RPL）のルーティングプロトコルを指定しました。
RPL is designed to meet the core requirements specified in [RFC5826], [RFC5867], [RFC5673], and [RFC5548].
RPLは、[RFC5826]、[RFC5867]、[RFC5673]、および[RFC5548]で指定されているコア要件を満たすように設計されています。
This document's contribution is to provide a performance evaluation of RPL with respect to several metrics of interest. This is accomplished using real data and topologies in a discrete event simulator developed to reproduce the protocol behavior.
このドキュメントの貢献は、関心のあるいくつかのメトリックに関してRPLのパフォーマンス評価を提供することです。これは、プロトコルの動作を再現するために開発された離散イベントシミュレータで実際のデータとトポロジを使用して実現されます。
The following metrics are evaluated:
次のメトリックが評価されます。
o Path quality metrics, such as ETX path cost, ETX path stretch, ETX fractional stretch, and hop distance stretch, as defined in Section 2 ("Terminology");
o セクション2（「用語」）で定義されている、ETXパスコスト、ETXパスストレッチ、ETXフラクショナルストレッチ、ホップ距離ストレッチなどのパス品質メトリック。
o Control plane overhead;
o コントロールプレーンのオーバーヘッド。
o End-to-end delay between nodes;
o ノード間のエンドツーエンドの遅延。
o Ability to cope with unstable situations (link churns, node dying);
o 不安定な状況に対処する機能（リンクのチャーン、ノードの停止）。
o Required resource constraints on nodes (routing table size).
o ノードに必要なリソース制約（ルーティングテーブルのサイズ）。
Some of these metrics are mentioned in the aforementioned RFCs, whereas others have been introduced to consider the challenges and unique requirements of LLNs as discussed in [RFC6550]. For example, routing in a home automation deployment has strict time bounds on protocol convergence after any change in topology, as mentioned in Section 3.4 of [RFC5826]. [RFC5673] requires bounded and guaranteed end-to-end delay for routing in an industrial deployment, and [RFC5548] requires comparatively loose bounds on latency for end-to-end communication. [RFC5548] mandates scalability in terms of protocol performance for a network of size ranging from 10^2 to 10^4 nodes.
これらのメトリックの一部は前述のRFCで言及されていますが、[RFC6550]で説明されているように、LLNの課題と固有の要件を検討するために導入されているメトリックもあります。たとえば、[RFC5826]のセクション3.4で説明されているように、ホームオートメーションデプロイメントのルーティングでは、トポロジの変更後のプロトコルの収束に厳密な時間制限があります。 [RFC5673]は、産業展開でのルーティングに制限付きの保証されたエンドツーエンドの遅延を必要とし、[RFC5548]は、エンドツーエンドの通信のレイテンシに比較的緩い制限を必要とします。 [RFC5548]は、10 ^ 2から10 ^ 4ノードの範囲のサイズのネットワークのプロトコルパフォーマンスに関するスケーラビリティを義務付けています。
Although simulation cannot prove formally that a protocol operates properly in all situations, it can give a good level of confidence in protocol behavior in highly stressful conditions, if and only if real-life data are used. Simulation is particularly useful when theoretical model assumptions may not be applicable to such networks and scenarios. In this document, real deployed network data traces have been used to model link behaviors and network topologies.
シミュレーションは、プロトコルがすべての状況で適切に動作することを正式に証明することはできませんが、実際のデータが使用されている場合に限り、非常にストレスの多い状況でのプロトコルの動作に高いレベルの信頼を与えることができます。シミュレーションは、理論的なモデルの仮定がそのようなネットワークやシナリオに適用できない場合に特に役立ちます。このドキュメントでは、実際に展開されたネットワークデータトレースを使用して、リンクの動作とネットワークトポロジをモデル化しています。
Please refer to [ROLL-TERMS] and [RFC6550] for terminology. In addition, the following terms are specified:
用語については、[ROLL-TERMS]および[RFC6550]を参照してください。さらに、次の用語が指定されています。
PDR: Packet Delivery Ratio.
PDR：パケット配信率。
CDF: Cumulative Distribution Function.
CDF：累積分布関数。
Expected Transmission Count (ETX Metric): The expected number of transmissions to reach the next hop is determined as the inverse of the link PDR. Consequently, in every hop, if the link quality (PDR) is high, the expected number of transmissions to reach the next hop may be as low as 1. However, if the PDR for the particular link is low, multiple transmissions may be needed.
Expected Transmission Count（ETX Metric）：ネクストホップに到達するために予想される送信数は、リンクPDRの逆数として決定されます。その結果、すべてのホップで、リンク品質（PDR）が高い場合、次のホップに到達するために予想される送信数は1と低くなる可能性があります。ただし、特定のリンクのPDRが低い場合、複数の送信が必要になることがあります。 。
ETX Path Cost: The ETX path cost metric is determined as the summation of the ETX value for each link on the route a packet takes towards the destination.
ETXパスコスト：ETXパスコストメトリックは、パケットが宛先に向かうルート上の各リンクのETX値の合計として決定されます。
ETX Path Cost Stretch: The ETX path cost stretch is defined as the difference between the number of expected transmissions (ETX Metric) taken by a packet traveling from source to destination, following a route determined by RPL and a route determined by a hypothetical ideal shortest path routing protocol (using link ETX as the metric).
ETXパスコストストレッチ：ETXパスコストストレッチは、RPLによって決定されたルートと仮想の理想的な最短距離によって決定されたルートに従って、送信元から宛先に移動するパケットによって取得される予想送信数（ETXメトリック）の差として定義されますパスルーティングプロトコル（メトリックとしてリンクETXを使用）。
ETX Fractional Stretch (fractional stretch factor of link ETX metric against ideal shortest path): The fractional path stretch is the ratio of ETX path stretch to ETX path cost for the shortest path route for the source-destination pair.
ETXフラクショナルストレッチ（理想的な最短パスに対するリンクETXメトリックのフラクショナルストレッチファクター）：フラクショナルパスストレッチは、送信元と宛先のペアの最短パスルートのETXパスストレッチとETXパスコストの比率です。
Hop Distance Stretch (stretch factor for node hop distance against ideal shortest path): The hop distance stretch is defined as the difference between the number of hops taken by a packet traveling from source to destination, following a route determined by RPL and by a hypothetical ideal shortest path algorithm, both using ETX as the link cost. The fractional hop distance stretch is computed as the ratio of path stretch to count value between a source-destination pair for the hypothetical shortest path route optimizing ETX path cost.
ホップ距離ストレッチ（理想的な最短パスに対するノードホップ距離のストレッチファクター）：ホップ距離ストレッチは、RPLによって決定されたルートに従って、送信元から宛先に移動するパケットが通過するホップ数と仮想的なホップ数との差として定義されますETXをリンクコストとして使用する、理想的な最短パスアルゴリズム。フラクショナルホップディスタンスストレッチは、ETXパスコストを最適化する仮想の最短パスルートの送信元と宛先のペア間のカウント値に対するパスストレッチの比率として計算されます。
In the context of this document, RPL has been simulated using OMNeT++ [OMNeTpp], a well-known discrete event-based simulator written in C++ and NEtwork Description (NED). Castalia-2.2 [Castalia-2.2] has been used as a Wireless Sensor Network Simulator framework within OMNeT++. The output and events in the simulation are visualized with the help of the Network AniMator, or NAM, which is distributed with the NS (Network Simulator) [NS-2].
このドキュメントのコンテキストでは、RPLは、OMNeT ++ [OMNeTpp]を使用してシミュレートされています。OMNeTppは、C ++およびNEtwork Description（NED）で記述されたよく知られた離散イベントベースのシミュレータです。 Castalia-2.2 [Castalia-2.2]は、OMNeT ++内のワイヤレスセンサーネットワークシミュレータフレームワークとして使用されています。シミュレーションの出力とイベントは、NS（Network Simulator）[NS-2]と共に配布されるNetwork AniMator（NAM）を使用して視覚化されます。
Note that no versions of the NS itself are used in this simulation study. Only the visualization tool was borrowed for verification purposes.
このシミュレーション調査では、NS自体のバージョンは使用されていません。視覚化ツールのみが検証目的で借用されました。
In contrast with theoretical models, which may have assumptions not applicable to lossy links, real-life data was used for two aspects of the simulations:
損失のあるリンクには適用できない仮定がある理論モデルとは対照的に、実際のデータはシミュレーションの2つの側面に使用されました。
* Link Failure Model: Derived from time-varying real network traces containing packet delivery probability for each link, over all channels, for both indoor network deployment and outdoor network deployment.
* リンク障害モデル：屋内ネットワーク展開と屋外ネットワーク展開の両方について、すべてのチャネルを介した各リンクのパケット配信確率を含む時変の実際のネットワークトレースから派生。
* Topology: Gathered from real-life deployment (traces mentioned above) as opposed to random topology simulations.
* トポロジ：ランダムなトポロジシミュレーションではなく、実際の展開（上記のトレース）から収集されます。
A 45-node topology, deployed as an outdoor network and shown in Figure 1, and a 2442-node topology, gathered from a smart meter network deployment, were used in the simulations. In Figure 1, links between a most preferred parent node and child nodes are shown in red. Links that are shown in black are also part of the topology but are not between a preferred parent and child node.
シミュレーションでは、屋外ネットワークとして展開され、図1に示されている45ノードトポロジと、スマートメーターネットワーク展開から収集された2442ノードトポロジが使用されました。図1では、最も優先される親ノードと子ノードの間のリンクが赤で示されています。黒で表示されているリンクもトポロジの一部ですが、優先される親ノードと子ノードの間にありません。
Figure 1 [See the PDF.]
図1 [PDFを参照してください。]
Figure 1: Outdoor Network Topology with 45 Nodes.
図1：45ノードの屋外ネットワークトポロジ。
Note that this is just a start to validate the simulation before using large-scale networks.
これは、大規模ネットワークを使用する前にシミュレーションを検証するための開始にすぎないことに注意してください。
A set of time-varying link quality data was gathered from a real network deployment to form a database used for the simulations. Each link in the topology randomly 'picks up' a link model (trace) from the database. Each link has a Packet Delivery Ratio (PDR) that varies with time (in the simulation, a new PDR is read from the database every 10 minutes) according to the gathered data. Packets are dropped randomly from that link with probability (1 - PDR). Each time a packet is about to be sent, the module generates a random number using the Mersenne Twister random number generation method. The random number is compared to the PDR to determine whether the packet should be dropped. Note that each link uses a different random number generator to maintain true randomness in the simulator and to avoid correlation between links. Also, the packet drop applies to all kinds of data and control packets (RPL), such as the DIO, DAO, and DIS packets defined in [RFC6550]. Figure 2 shows a typical temporal characteristic of links from the indoor network traces used in the simulations. The figure shows several links with perfect connectivity, some links with a PDR as low as 10%, and several for which the PDR may vary from 30% to 80%, sharply changing back and forth between a high value (strong connectivity) and a low value (weak connectivity).
一連の時変リンク品質データが実際のネットワーク配置から収集され、シミュレーションに使用されるデータベースを形成しました。トポロジ内の各リンクは、データベースからリンクモデル（トレース）をランダムに「取得」します。各リンクには、収集されたデータに従って時間とともに変化するパケット配信率（PDR）があります（シミュレーションでは、新しいPDRがデータベースから10分ごとに読み取られます）。パケットは確率（1-PDR）でそのリンクからランダムにドロップされます。パケットが送信される直前に、モジュールはMersenne Twister乱数生成方法を使用して乱数を生成します。乱数をPDRと比較して、パケットをドロップする必要があるかどうかを判断します。各リンクは異なる乱数ジェネレータを使用して、シミュレータで真のランダム性を維持し、リンク間の相関を回避することに注意してください。また、パケットドロップは、[RFC6550]で定義されているDIO、DAO、DISパケットなど、あらゆる種類のデータおよび制御パケット（RPL）に適用されます。図2は、シミュレーションで使用された屋内ネットワークトレースからのリンクの典型的な時間特性を示しています。この図は、完全な接続性を持ついくつかのリンク、10％という低いPDRを持ついくつかのリンク、およびPDRが30％から80％に変化する可能性があるいくつかのリンクを示し、高い値（強い接続性）と低い値（弱い接続）。
Figure 2 [See the PDF.]
図2 [PDFを参照してください。]
Figure 2: Example of Link Characteristics.
図2：リンク特性の例。
In the RPL simulator, the LBR (LLN Border Router) or the Directed Acyclic Graph (DAG) root first initiates sending out DIO messages, and the DAG is gradually constructed. RPL makes use of trickle timers: the protocol sets a minimum time period with which the nodes start re-issuing DAOs, and this minimum period is denoted by the trickle parameter Imin. RPL also sets an upper limit on how many times this time period can be doubled; this is denoted by the parameter DIOIntervalDoublings, as defined in [RFC6550]. For the simulation, Imin is initially set to 1 second and DIOIntervalDoublings is equal to 16, and therefore the maximum time between two consecutive DIO emissions by a node (under a steady network condition) is 18.2 hours. The trickle time interval for emitting DIO messages assumes the initial value of 1 second and then changes over simulation time, as mentioned in [RFC6206].
RPLシミュレーターでは、LBR（LLNボーダールーター）または有向非巡回グラフ（DAG）ルートが最初にDIOメッセージの送信を開始し、DAGは徐々に構築されます。 RPLはトリクルタイマーを使用します。プロトコルは、ノードがDAOの再発行を開始する最小期間を設定します。この最小期間は、トリクルパラメーターIminで示されます。 RPLは、この期間を2倍にできる回数の上限も設定します。これは、[RFC6550]で定義されているパラメーターDIOIntervalDoublingsで示されます。シミュレーションでは、Iminは最初1秒に設定され、DIOIntervalDoublingsは16に等しいため、ノードによる2つの連続したDIOエミッション間の最大時間（安定したネットワーク条件下）は18.2時間です。 [RFC6206]で述べられているように、DIOメッセージを送信するためのトリクルタイムインターバルは、初期値が1秒であると想定しており、シミュレーション時間に変化します。
Another objective of this study is to give insight to the network administrator on how to tweak the trickle values. These recommendations could then be used in applicability statement documents.
この調査の別の目的は、トリクル値を微調整する方法についてネットワーク管理者に洞察を与えることです。これらの推奨事項は、適用性ステートメントのドキュメントで使用できます。
Each node in the network, other than the LBR or DAG root, also emits DAO messages as specified in [RFC6550], to initially populate the routing tables with the prefixes received from children via the DAO messages to support Point-to-Point (P2P) and Point-to-Multipoint (P2MP) traffic in the "down" direction. During these simulations, it is assumed that each node is capable of storing route information for other nodes in the network (storing mode of RPL).
LBRまたはDAGルート以外のネットワーク内の各ノードも、[RFC6550]で指定されているようにDAOメッセージを発行し、ポイントツーポイント（P2P）をサポートするために、DAOメッセージを介して子から受信したプレフィックスをルーティングテーブルに最初に入力します。 ）および「ダウン」方向のポイントツーマルチポイント（P2MP）トラフィック。これらのシミュレーション中、各ノードはネットワーク内の他のノードのルート情報を格納できると想定されています（RPLの保存モード）。
For nodes implementing RPL, as expected, the routing table memory requirement varies according to the position in the DODAG (Destination-Oriented DAG). The (worst-case) assumption is made that there is no route summarization (aggregation) in the network. Thus, a node closer to the DAG will have to store more entries in its routing table. It is also assumed that all nodes have equal memory capacity to store the routing states.
RPLを実装するノードでは、予想どおり、ルーティングテーブルのメモリ要件はDODAG（宛先指向DAG）内の位置によって異なります。 （最悪の場合）ネットワークにはルート集約（集約）がないと想定されています。したがって、DAGに近いノードは、ルーティングテーブルにさらに多くのエントリを格納する必要があります。また、すべてのノードがルーティング状態を保存するために等しいメモリ容量を持っていると想定されています。
For simulations of the indoor network, each node sends traffic according to a Constant Bit Rate (CBR) to all other nodes in the network, over the simulation period. Each node generates a new data packet every 10 seconds. Each data packet has a size of 127 bytes including 802.15.4 PHY/MAC headers and RPL packet headers. All control packets are also encapsulated with 802.15.4 PHY/MAC headers. To simulate a more realistic scenario, 80% of the packets generated by each node are destined to the root, and the remaining 20% of the packets are uniformly assigned as destined to nodes other than the root. Therefore, the root receives a considerably larger amount of data than other nodes. These values may be revised when studying P2P traffic so as to have a majority of traffic going to all nodes as opposed to the root. In the later part of the simulation, a typical home/building routing scenario is also simulated, and different path quality metrics are computed for that traffic pattern.
屋内ネットワークのシミュレーションの場合、各ノードは、一定のビットレート（CBR）に従って、シミュレーション期間中にネットワーク内の他のすべてのノードにトラフィックを送信します。各ノードは、10秒ごとに新しいデータパケットを生成します。各データパケットのサイズは127バイトで、802.15.4 PHY / MACヘッダーとRPLパケットヘッダーを含みます。すべての制御パケットは、802.15.4 PHY / MACヘッダーでカプセル化されます。より現実的なシナリオをシミュレートするために、各ノードによって生成されたパケットの80％はルートを宛先とし、残りの20％のパケットはルート以外のノードを宛先とするように均一に割り当てられます。したがって、ルートは他のノードよりもかなり大量のデータを受け取ります。これらの値は、ルートではなくすべてのノードに向かうトラフィックの大部分を持つように、P2Pトラフィックを調査するときに修正される場合があります。シミュレーションの後半では、一般的な住宅/建物のルーティングシナリオもシミュレーションされ、そのトラフィックパターンに対してさまざまなパス品質メトリックが計算されます。
The packets are routed through the DODAG built by RPL according to the mechanisms specified in [RFC6550].
パケットは、[RFC6550]で指定されたメカニズムに従って、RPLによって構築されたDODAGを介してルーティングされます。
A number of RPL parameters are varied (such as the packet rate from each source and the time period for emitting a new DAG sequence number) to observe their effect on the performance metric of interest.
目的のパフォーマンスメトリックへの影響を観察するために、RPLパラメータの数（各ソースからのパケットレートや、新しいDAGシーケンス番号を発行する期間など）が変更されています。
As the DAO messages are used to feed the routing tables in the network, they grow with time and size of the network. Nevertheless, no constraint was imposed on the size of the routing table nor on how much information the node can store. The routing table size is not expressed in terms of Kbytes of memory usage but measured in terms of the number of entries for each node. Each entry has the next-hop node and path cost associated with the destination node.
DAOメッセージはネットワーク内のルーティングテーブルへのフィードに使用されるため、ネットワークの時間とサイズに応じて大きくなります。それでも、ルーティングテーブルのサイズやノードが保存できる情報量に制約はありませんでした。ルーティングテーブルのサイズは、キロバイト単位のメモリ使用量ではなく、各ノードのエントリ数で測定されます。各エントリには、宛先ノードに関連付けられたネクストホップノードとパスコストがあります。
The link ETX (Expected Transmission Count) metric is used to build the DODAG and is specified in [RFC6551].
リンクETX（予想伝送カウント）メトリックはDODAGを構築するために使用され、[RFC6551]で指定されています。
Hop Count: For each source-destination pair, the number of hops for both RPL and shortest path routing is computed. Shortest path routing refers to a hypothetical ideal routing protocol that would always provide the shortest path in terms of ETX path cost (or whichever metric is used) in the network.
ホップカウント：送信元と宛先のペアごとに、RPLと最短パスルーティングの両方のホップ数が計算されます。最短パスルーティングとは、ネットワーク内のETXパスコスト（または使用されるメトリック）に関して常に最短パスを提供する仮想の理想的なルーティングプロトコルを指します。
The Cumulative Distribution Function (CDF) of the hop count for all paths (n * (n - 1) in an n-node network) in the network with respect to the hop count is plotted in Figure 3 for both RPL and shortest path routing. One can observe that the CDF corresponding to 4 hops is around 80% for RPL and 90% for shortest path routing. In other words, for the given topology, 90% of the paths have a path length of 4 hops or less with an ideal shortest path routing methodology, whereas in RPL P2P routing, 90% of the paths will have a length of no more than 5 hops. This result indicates that despite having a non-optimized P2P routing scheme, the path quality of RPL is close to an optimized P2P routing mechanism for the topology under consideration. Another reason for this may relate to the fact that the DAG root is at the center of the network; thus, routing through the DAG root is often close to an optimal (shortest path) routing. This result may be different in a topology where the DAG root is located at one end of the network.
図3に、RPLと最短パスルーティングの両方について、ホップカウントに関するネットワーク内のすべてのパス（nノードネットワークではn *（n-1））のホップカウントの累積分布関数（CDF）をプロットします。 。 4ホップに対応するCDFは、RPLの場合は約80％、最短パスルーティングの場合は90％であることがわかります。つまり、特定のトポロジでは、パスの90％が4ホップ以下のパス長であり、理想的な最短パスルーティング方法論ですが、RPL P2Pルーティングでは、90％のパスの長さが5ホップ。この結果は、最適化されていないP2Pルーティングスキームがあるにもかかわらず、RPLのパス品質は検討中のトポロジーに最適化されたP2Pルーティングメカニズムに近いことを示しています。これのもう1つの理由は、DAGルートがネットワークの中心にあるという事実に関連している可能性があります。したがって、DAGルートを介したルーティングは、最適な（最短パス）ルーティングに近いことがよくあります。この結果は、DAGルートがネットワークの一端にあるトポロジでは異なる場合があります。
Figure 3 [See the PDF.]
図3 [PDFを参照してください。]
Figure 3: CDF of Hop Count versus Hop Count.
図3：ホップ数とホップ数のCDF。
ETX Path Cost: In the simulation, the total ETX path cost (defined in the Terminology section) from source to destination for each packet is computed.
ETXパスコスト：シミュレーションでは、各パケットの送信元から宛先までの合計ETXパスコスト（用語セクションで定義）が計算されます。
Figure 4 shows the CDF of the total ETX path cost, both with RPL and shortest path routing. Here also one can observe that the ETX path cost from all sources to all destinations is close to that of shortest path routing for the network.
図4は、RPLと最短パスルーティングの両方での、ETXパスコストの合計のCDFを示しています。ここでも、すべてのソースからすべての宛先へのETXパスコストが、ネットワークの最短パスルーティングのコストに近いことがわかります。
Figure 4 [See the PDF.]
図4 [PDFを参照してください。]
Figure 4: CDF of Total ETX Path Cost along Path versus ETX Path Cost.
図4：パスに沿った合計ETXパスコストとETXパスコストのCDF。
Path Stretch: The path stretch metric encompasses the stretch factor for both hop distance and ETX path cost (as defined in the Terminology section). The hop distance stretch, which is determined as the difference between the number of hops taken by a packet while following a route built via RPL and the number of hops taken by shortest path routing (using link ETX as the metric), is computed. The ETX path cost stretch is also provided.
パスストレッチ：パスストレッチメトリックには、ホップの距離とETXパスコストの両方のストレッチファクターが含まれます（「用語」セクションで定義）。 RPLを介して構築されたルートをたどる間にパケットが取るホップ数と最短パスルーティング（メトリックとしてリンクETXを使用）が取るホップ数の差として決定されるホップ距離ストレッチが計算されます。 ETXパスコストストレッチも提供されます。
The CDF of both path stretch metrics is plotted against the value of the corresponding path stretch over all packets in Figures 5 and 6, for hop distance stretch and ETX path stretch, respectively. It can be observed that, for a few packets, the path built via RPL has fewer hops than the ideal shortest path where path ETX is minimized along the DAG. This is because there are a few source-destination pairs where the total ETX path cost is equal to or less than that of the ideal shortest path when the packet takes a longer hop count. As the RPL implementation ignores a 20% change in total ETX path cost before switching to a new parent or emitting a new DIO, it does not necessarily provide the shortest path in terms of total ETX path cost. Thus, this implementation yields a few paths with smaller hop counts but larger (or equal) total ETX path cost.
両方のパスストレッチメトリックのCDFは、図5および6のすべてのパケットの対応するパスストレッチの値に対して、それぞれホップ距離ストレッチとETXパスストレッチに対してプロットされます。いくつかのパケットでは、RPLを介して構築されたパスは、パスETXがDAGに沿って最小化される理想的な最短パスよりもホップ数が少ないことがわかります。これは、パケットのホップ数が長くなると、ETXパスコストの合計が理想的な最短パスのコスト以下になるいくつかの送信元と宛先のペアがあるためです。 RPL実装は、新しい親に切り替えるか、または新しいDIOを発行する前に、ETXパスコストの合計の20％の変更を無視するため、ETXパスコストの合計に関して必ずしも最短のパスを提供するとは限りません。したがって、この実装では、ホップ数は少ないが、ETXパスの総コストが大きい（または等しい）いくつかのパスが生成されます。
Figure 5 [See the PDF.]
図5 [PDFを参照してください。]
Figure 5: CDF of Hop Distance Stretch versus Hop Distance Stretch Value.
図5：ホップ距離ストレッチとホップ距離ストレッチ値のCDF。
Figure 6 [See the PDF.]
図6 [PDFを参照してください。]
Figure 6: CDF of ETX Path Stretch versus ETX Path Stretch Value.
図6：ETXパスストレッチの値に対するETXパスストレッチのCDF。
The data for the CDF of the hop count and ETX path cost for the ideal shortest path (SP) and a path built via RPL, along with the CDF of the routing table size, is given below in Table 1. Figures 3 to 7 relate to the data in this table.
ルーティングテーブルサイズのCDFとともに、理想的な最短パス（SP）とRPLを介して構築されたパスのホップカウントとETXパスコストのCDFのデータを、表1に示します。図3〜7は、このテーブルのデータに。
+---------+--------+---------+-----------+------------+-------------+
| CDF | Hop | Hop | ETX Cost | ETX Cost | Routing |
| (%age) | (SP) | (RPL) | (SP) | (RPL) | Table Size |
+---------+--------+---------+-----------+------------+-------------+
| 0 | 1.0 | 1.0 | 1 | 1.0 | 0 |
| 5 | 1.0 | 1.03 | 1 | 1.242 | 1 |
| 10 | 2.0 | 2.0 | 2 | 2.048 | 2 |
| 15 | 2.0 | 2.01 | 2 | 2.171 | 2 |
| 20 | 2.0 | 2.06 | 2 | 2.400 | 2 |
| 25 | 2.0 | 2.11 | 2 | 2.662 | 3 |
| 30 | 2.0 | 2.42 | 2 | 2.925 | 3 |
| 35 | 2.0 | 2.90 | 3 | 3.082 | 3 |
| 40 | 3.0 | 3.06 | 3 | 3.194 | 4 |
| 45 | 3.0 | 3.1 | 3 | 3.41 | 4 |
| 50 | 3.0 | 3.15 | 3 | 3.626 | 4 |
| 55 | 3.0 | 3.31 | 3 | 3.823 | 5 |
| 60 | 3.0 | 3.50 | 3 | 4.032 | 6 |
| 65 | 3.0 | 3.66 | 3 | 4.208 | 7 |
| 70 | 3.0 | 3.92 | 4 | 4.474 | 7 |
| 75 | 4.0 | 4.16 | 4 | 4.694 | 7 |
| 80 | 4.0 | 4.55 | 4 | 4.868 | 8 |
| 85 | 4.0 | 4.70 | 4 | 5.091 | 9 |
| 90 | 4.0 | 4.89 | 4 | 5.488 | 10 |
| 95 | 4.0 | 5.65 | 5 | 5.923 | 12 |
| 100 | 5.0 | 7.19 | 9 | 10.125 | 44 |
+---------+--------+---------+-----------+------------+-------------+
Table 1: Path Quality CDFs.
表1：パス品質CDF。
Overall, the path quality metrics give us important information about the protocol's performance when minimizing the ETX path cost is the objective to form the DAG. The protocol, as explained, does not always provide an optimum path, especially for peer-to-peer communication. However, it does end up reducing the control overhead cost, thereby reducing unnecessary parent selection and DIO message forwarding events, by choosing a non-optimized path. Despite this specific implementation technique, around 30% of the packets travel the same number of hops as an ideal shortest path routing mechanism, and 20% of the packets experience the same number of attempted transmissions to reach the destination. On average, this implementation costs only a few extra transmission attempts and saves a large number of control packet transmissions.
全体的に、ETGパスコストを最小化することがDAGを形成する目的である場合、パス品質メトリックは、プロトコルのパフォーマンスに関する重要な情報を提供します。説明したように、このプロトコルは、特にピアツーピア通信の場合、常に最適なパスを提供するとは限りません。ただし、最適化されていないパスを選択することで、制御オーバーヘッドのコストが削減され、不要な親の選択とDIOメッセージの転送イベントが削減されます。この特定の実装手法にもかかわらず、パケットの約30％が理想的な最短パスルーティングメカニズムと同じ数のホップを移動し、パケットの20％が同じ数の送信を試みて宛先に到達しようとします。平均すると、この実装では追加の送信試行が数回しか発生せず、多数の制御パケット送信が節約されます。
The objective of this metric is to observe the distribution of the number of entries per node. Figure 7 shows the CDF of the number of routing table entries for all nodes. Note that 90% of the nodes need to store less than 10 entries in their routing table for the topology under study. The LBR does not have the same power or memory constraints as regular nodes do, and hence it can accommodate entries for all the nodes in the network. The requirement to accommodate devices with low storage capacity has been mandated in [RFC5673], [RFC5826], and [RFC5867]. However, when RPL is implemented in storing mode, some nodes closer to the LBR or DAG root will require more memory to store larger routing tables.
このメトリックの目的は、ノードあたりのエントリ数の分布を観察することです。図7は、すべてのノードのルーティングテーブルエントリ数のCDFを示しています。ノードの90％は、調査中のトポロジーのルーティングテーブルに10未満のエントリを格納する必要があることに注意してください。 LBRには通常のノードと同じ電力またはメモリの制約がないため、ネットワーク内のすべてのノードのエントリに対応できます。ストレージ容量が低いデバイスに対応するための要件は、[RFC5673]、[RFC5826]、および[RFC5867]で義務付けられています。ただし、RPLが格納モードで実装されている場合、LBRまたはDAGルートに近い一部のノードは、より大きなルーティングテーブルを格納するためにより多くのメモリを必要とします。
Figure 7 [See the PDF.]
図7 [PDFを参照してください。]
Figure 7: CDF of Routing Table Size with Respect to Number of Nodes.
図7：ノード数に関するルーティングテーブルサイズのCDF
For delay-sensitive applications, such as home and building automation, it is critical to optimize the end-to-end delay. Figure 8 shows the upper bound and distributions of delay for paths between any two given nodes for different hop counts between the source and destination. Here, the hop count refers to the number of hops a packet travels to reach the destination when using RPL paths. This hop distance does not correspond to the shortest path distance between two nodes. Note that each packet has a length of 127 bytes, with a 240-kbps radio, which makes the transmission delay approximately 4 milliseconds (ms).
ホームオートメーションやビルディングオートメーションなどの遅延の影響を受けやすいアプリケーションでは、エンドツーエンドの遅延を最適化することが重要です。図8は、送信元と宛先の間の異なるホップカウントについて、任意の2つのノード間のパスの遅延の上限と分布を示しています。ここで、ホップカウントとは、RPLパスを使用している場合に、パケットが宛先に到達するために移動するホップの数を指します。このホップ距離は、2つのノード間の最短パス距離に対応していません。各パケットの長さは127バイトであり、無線は240 kbpsであるため、送信遅延は約4ミリ秒（ms）になることに注意してください。
Figure 8 [See the PDF.]
図8 [PDFを参照してください。]
Figure 8: Comparison of Packet Latency, for Different Path Lengths, Expressed in Hop Count.
図8：ホップカウントで表される、異なるパス長に対するパケット遅延の比較。
RFCs 5673 [RFC5673] and 5548 [RFC5548] mention a requirement for the end-to-end delivery delay to remain within a bounded latency. For instance, according to the industrial routing requirement, non-critical closed-loop applications may have a latency requirement that can be as low as 100 ms, whereas monitoring services may tolerate a delay in the order of seconds. The results show that about 99% of the end-to-end communication (where the maximum hop count is 7 hops) is bounded within the 100-ms requirement, for the topology under study. It should be noted that due to poor link condition, there may be packet drops triggering retransmission, which may cause larger end-to-end delivery delays. Nodes in the proximity of the LBR may become congested at high traffic loads, which can also lead to higher end-to-end delay.
RFC 5673 [RFC5673]および5548 [RFC5548]は、エンドツーエンドの配信遅延が制限されたレイテンシ内に留まるための要件について述べています。たとえば、産業用ルーティング要件によれば、重要ではない閉ループアプリケーションのレイテンシ要件は100ミリ秒にもなる可能性がありますが、監視サービスは秒単位の遅延を許容できます。結果は、調査中のトポロジのエンドツーエンド通信の約99％（最大ホップカウントが7ホップ）が100ミリ秒の要件内に収まっていることを示しています。リンク状態が悪いため、再送信をトリガーするパケットドロップがあり、エンドツーエンドの配信遅延が大きくなる可能性があることに注意してください。 LBRの近くにあるノードは、高トラフィック負荷で輻輳する可能性があり、これによりエンドツーエンドの遅延が大きくなる可能性もあります。
The control plane overhead is an important routing characteristic in LLNs. It is imperative to bound the control plane overhead. One of the distinctive characteristics of RPL is that it makes use of trickle timers so as to reduce the number of control plane packets by eliminating redundant messages. The aim of this performance metric is thus to analyze the control plane overhead both in stable conditions (no network element failure overhead) and in the presence of failures.
コントロールプレーンのオーバーヘッドは、LLNの重要なルーティング特性です。コントロールプレーンのオーバーヘッドを制限することが不可欠です。 RPLの特徴の1つは、トリクルタイマーを使用して、冗長メッセージを排除することでコントロールプレーンパケットの数を減らすことです。したがって、このパフォーマンスメトリックの目的は、安定した状態（ネットワーク要素の障害によるオーバーヘッドがない）と障害がある場合の両方で、コントロールプレーンのオーバーヘッドを分析することです。
Data and control plane traffic comparison for each node: Figure 9 shows the comparison between the amount of data packets transmitted (including forwarded packets) and control packets (DIO and DAO messages) transmitted for all individual nodes when link ETX is used to optimize the DAG. As mentioned earlier, each node generates a new data packet every 10 seconds. Here one can observe that a considerable amount of traffic is routed through the DAG root itself. The x axis indicates the node ID in the network. Also, as expected, the nodes that are closer to the DAG root and that act as routers (as opposed to leaves) handle much more data traffic than other nodes. Nodes 12, 36, and 38 are examples of nodes next to the DAG root, taking part in routing most of the data packets and hence having many more data packet transmissions than other nodes, as observed in Figure 9. We can also observe that the proportion of control traffic is negligible for those nodes. This result also reinforces the fact that the amount of control plane traffic generated by RPL is negligible on these topologies. Leaf nodes have comparable amounts of data and control packet transmissions (they do not take part in routing the data).
各ノードのデータおよびコントロールプレーントラフィックの比較：図9は、リンクETXを使用してDAGを最適化した場合に送信されるデータパケット（転送パケットを含む）と制御パケット（DIOおよびDAOメッセージ）の量の比較を示しています。 。前述のように、各ノードは10秒ごとに新しいデータパケットを生成します。ここでは、かなりの量のトラフィックがDAGルート自体を介してルーティングされていることがわかります。 x軸はネットワーク内のノードIDを示します。また、予想どおり、DAGルートに近く、ルーターとして機能するノード（リーフではなく）は、他のノードよりもはるかに多くのデータトラフィックを処理します。ノード12、36、および38は、DAGルートの隣のノードの例であり、ほとんどのデータパケットのルーティングに参加しているため、図9に見られるように、他のノードよりもはるかに多くのデータパケットが送信されます。これらのノードでは、制御トラフィックの割合は無視できます。この結果は、RPLによって生成されるコントロールプレーントラフィックの量がこれらのトポロジでは無視できるという事実を補強します。リーフノードには、同等の量のデータと制御パケット送信があります（データのルーティングには関与しません）。
Figure 9 [See the PDF.]
図9 [PDFを参照してください。]
Figure 9: Amount of Data and Control Packets Transmitted against Node Id Using Link ETX as Routing Metric.
図9：リンクETXをルーティングメトリックとして使用してノードIDに対して送信されたデータおよび制御パケットの量。
Data and control packet transmission with respect to time: In Figures 10, 11, and 12, the amount of data and control packets transmitted for node 12 (low rank in DAG, closer to the root), node 43 (in the middle), and node 31 (leaf node) are shown, respectively. These values stand for the number of data and control packets transmitted for each 10-minute interval for the particular node, to help understand what the ratio is between data and control packets exchanged in the network. One can observe that nodes closer to the DAG root have a higher proportion of data packets (as expected), and the proportion of control traffic is negligible in comparison with the data traffic. Also, the amount of data traffic handled by a node within a given interval varies largely over time for a node closer to the DAG root, because in each interval the destination of the packets from the same source changes, while 20% of the packets are destined to the DAG root. As a result, the pattern of the traffic that is handled changes widely in each interval for the nodes closer to the DAG root. For the nodes that are farther away from the DAG root, the ratio of data traffic to control traffic is smaller, since the amount of data traffic is greatly reduced.
時間に関するデータおよび制御パケットの送信：図10、11、および12では、ノード12（DAGの下位ランク、ルートに近い）、ノード43（中央）に送信されるデータおよび制御パケットの量、ノード３１（葉ノード）がそれぞれ示されている。これらの値は、特定のノードの10分間隔ごとに送信されるデータと制御パケットの数を表し、ネットワークで交換されるデータと制御パケットの比率を理解するのに役立ちます。 DAGルートに近いノードほどデータパケットの割合が高く（予想どおり）、制御トラフィックの割合はデータトラフィックと比較して無視できることがわかります。また、各間隔で同じ送信元からのパケットの宛先が変更され、パケットの20％がDAGルートを宛先としています。その結果、処理されるトラフィックのパターンは、DAGルートに近いノードの各間隔で大きく変化します。 DAGルートからさらに離れたノードでは、データトラフィックの量が大幅に削減されるため、制御トラフィックに対するデータトラフィックの比率は小さくなります。
The control traffic load exhibits a wave-like pattern. The amount of control packets for each node drops quickly as the DODAG stabilizes, due to the effect of trickle timers. However, when a new DODAG sequence is advertised (global repair of the DODAG), the trickle timers are reset and the nodes start emitting DIOs frequently again to rebuild the DODAG. For a node closer to the DAG root, the amount of data packets is much larger than that of control packets and somewhat oscillatory around a mean value. The amount of control packets exhibits a 'saw-tooth' behavior. In the case where the ETX link metric is used, when the PDR changes, the ETX link metric for a node to its child changes, which may lead to choosing a new parent and changing the DAG rank of the child. This event resets the trickle timer and triggers the emission of a new DIO. Also, the issue of a new DODAG sequence number triggers DODAG re-computation and resets the trickle timers. Therefore, one can observe that the number of control packets attains a high value for one interval and comes down to lower values for subsequent intervals. The interval with a high number of control packets denotes the interval where the timers to emit a new DIO are reset more frequently. As the network stabilizes, the control packets are less dense in volume. For leaf nodes, the amount of control packets is comparable to that of data packets, as leaf nodes are more prone to face changes in their DODAG rank as opposed to nodes closer to the DAG root when the link ETX value in the topology changes dynamically.
制御トラフィックの負荷は、波のようなパターンを示します。トリクルタイマーの効果により、DODAGが安定すると、各ノードの制御パケットの量が急速に減少します。ただし、新しいDODAGシーケンスがアドバタイズされると（DODAGのグローバル修復）、トリクルタイマーがリセットされ、ノードはDIOAGを再構築するために頻繁にDIOを頻繁に放出し始めます。 DAGルートに近いノードの場合、データパケットの量は制御パケットの量よりもはるかに多く、平均値を中心に多少振動します。制御パケットの量は「ノコギリ」の動作を示します。 ETXリンクメトリックが使用されている場合、PDRが変更されると、ノードからその子へのETXリンクメトリックが変更されます。これにより、新しい親が選択され、子のDAGランクが変更される可能性があります。このイベントは、トリクルタイマーをリセットし、新しいDIOの発行をトリガーします。また、新しいDODAGシーケンス番号の発行により、DODAGの再計算がトリガーされ、トリクルタイマーがリセットされます。したがって、制御パケットの数が1つの間隔で高い値に達し、その後の間隔で低い値になることがわかります。制御パケットの数が多い間隔は、新しいDIOを発行するタイマーがより頻繁にリセットされる間隔を示します。ネットワークが安定すると、制御パケットのボリューム密度が低くなります。リーフノードの場合、制御パケットの量はデータパケットの量に匹敵します。これは、トポロジ内のリンクETX値が動的に変化するときに、DAGルートに近いノードとは対照的に、リーフノードがDODAGランクの変化に直面する傾向があるためです。
Figure 10 [See the PDF.]
図10 [PDFを参照してください。]
Figure 10: Amount of Data and Control Packets Transmitted for Node 12.
図10：ノード12に送信されたデータと制御パケットの量
Figure 11 [See the PDF.]
図11 [PDFを参照してください。]
Figure 11: Amount of Data and Control Packets Transmitted for Node 43.
図11：ノード43に送信されたデータと制御パケットの量
Figure 12 [See the PDF.]
図12 [PDFを参照してください。]
Figure 12: Amount of Data and Control Packets Transmitted for Node 31.
図12：ノード31に送信されたデータと制御パケットの量
Upon link failures, a node may lose its parents -- preferred and backup (if any) -- thus leading to a loss of connectivity (no path to the DAG root). RPL specifies two mechanisms for DODAG repairs, referred to as global repair and local repair. In this document, simulation results are presented to evaluate the amount of time data packets are dropped due to a loss of connectivity for the following two cases: a) when only using global repair (i.e., the DODAG is rebuilt thanks to the emission of new DODAG sequence numbers by the DAG root), and b) when using local repair (poisoning the sub-DAG in case of loss of connectivity) in addition to global repair. The idea is to tune the frequency at which new DODAG sequence numbers are generated by the DAG root, and also to observe the effect of varying the frequency for global repair and the concurrent use of global and local repair. It is expected that more frequent increments of DODAG sequence numbers will lead to a shorter duration of connectivity loss at a price of a higher rate of control packets in the network. For the use of both global and local repair, the simulation results show the trade-off in amount of time that a node may remain without service and total number of control packets.
リンク障害が発生すると、ノードは親を失う可能性があります-優先およびバックアップ（存在する場合）-したがって、接続が失われます（DAGルートへのパスがない）。 RPLは、グローバル修復とローカル修復と呼ばれるDODAG修復の2つのメカニズムを指定します。このドキュメントでは、次の2つのケースで接続が失われたためにデータパケットがドロップされた時間を評価するためのシミュレーション結果が示されています。 DAGルートによるDODAGシーケンス番号）、およびb）グローバル修復に加えてローカル修復（接続が失われた場合にサブDAGを汚染する）を使用する場合。このアイデアは、DAGルートによって新しいDODAGシーケンス番号が生成される頻度を調整し、グローバル修復とグローバル修復とローカル修復を同時に使用する頻度を変化させることの影響を観察することです。 DODAGシーケンス番号のより頻繁な増分により、ネットワーク内の制御パケットのレートが高くなるという代償を払って、接続が失われる期間が短くなることが予想されます。グローバル修復とローカル修復の両方を使用する場合、シミュレーション結果は、ノードがサービスなしで維持できる時間と制御パケットの総数のトレードオフを示します。
Figure 13 shows the CDF of time spent by any node without service, when the data packet rate is one packet every 10 seconds and a new DODAG sequence number is generated every 10 minutes. This plot reflects the property of global repair without any local repair scheme. When all the parents are temporarily unreachable from a node, the time before it hears a DIO from another node is recorded, which gives the time without service. We define the DAG repair timer as the interval at which the LBR increments the DAG sequence number, thus triggering a global re-optimization. In some cases, this value might go up to the DAG repair timer value, because until a DIO is heard, the node does not have a parent and hence no route to the LBR or other nodes not in its own sub-DAG. Clearly, this situation indicates a lack of connectivity and loss of service for the node.
図13は、データパケットレートが10秒ごとに1パケットであり、新しいDODAGシーケンス番号が10分ごとに生成される、サービスのないノードが費やした時間のCDFを示しています。このプロットは、ローカル修復スキームなしのグローバル修復の特性を反映しています。すべての親がノードから一時的に到達できない場合、別のノードからのDIOを聞くまでの時間が記録されます。これにより、サービスのない時間が提供されます。 LBRがDAGシーケンス番号をインクリメントする間隔としてDAG修復タイマーを定義し、グローバルな再最適化をトリガーします。場合によっては、この値がDAG修復タイマー値に達することがあります。これは、DIOが聞こえるまで、ノードには親がないため、LBRまたは独自のサブDAGにない他のノードへのルートがないためです。明らかに、この状況は接続の欠如とノードのサービスの損失を示しています。
Figure 13 [See the PDF.]
図13 [PDFを参照してください。]
Figure 13: CDF: Loss of Connectivity with Global Repair.
図13：CDF：グローバル修復による接続の喪失。
The effect of the DAG repair timer on time without service is plotted in Figure 14, where the source rate is 20 seconds/packet and in Figure 15, where the source sends a packet every 10 seconds.
DAG修復タイマーがサービスなしの時間に与える影響を図14にプロットします。図14ではソースレートが20秒/パケットで、図15ではソースが10秒ごとにパケットを送信しています。
Figure 14 [See the PDF.]
図14 [PDFを参照してください。]
Figure 14: CDF: Loss of Connectivity for Different Global Repair Period, Source Rate 20 Seconds/Packet.
図14：CDF：さまざまなグローバル修理期間における接続の喪失、ソースレート20秒/パケット。
Figure 15 [See the PDF.]
図15 [PDFを参照してください。]
Figure 15: CDF: Loss of Connectivity for Different Global Repair Period, Source Rate 10 Seconds/Packet.
図15：CDF：さまざまなグローバル修理期間の接続性の損失、ソースレート10秒/パケット。
The data for Figures 13 and 15 can be found in Table 2. The table shows how the CDF of time without connectivity to the LBR increases while we increase the time period to emit new DAG sequence numbers, when the nodes generate a packet every 10 seconds.
図13と15のデータは表2にあります。この表は、ノードが10秒ごとにパケットを生成するときに、LBRに接続されていない時間のCDFがどのように増加して、新しいDAGシーケンス番号を発行する期間を増やしているかを示しています。 。
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.464 | 0.045 | 0.027 |
| 5 | 0.609 | 0.424 | 0.396 |
| 10 | 1.040 | 1.451 | 0.396 |
| 15 | 1.406 | 3.035 | 0.714 |
| 20 | 1.934 | 3.521 | 0.714 |
| 25 | 2.113 | 5.461 | 1.856 |
| 30 | 3.152 | 5.555 | 1.856 |
| 35 | 3.363 | 7.756 | 6.173 |
| 40 | 4.9078 | 8.604 | 6.173 |
| 45 | 8.575 | 9.181 | 14.751 |
| 50 | 9.788 | 21.974 | 14.751 |
| 55 | 13.230 | 30.017 | 14.751 |
| 60 | 17.681 | 31.749 | 16.166 |
| 65 | 29.356 | 68.709 | 16.166 |
| 70 | 34.019 | 92.974 | 302.459 |
| 75 | 49.444 | 117.869 | 302.459 |
| 80 | 75.737 | 133.653 | 488.602 |
| 85 | 150.089 | 167.828 | 488.602 |
| 90 | 180.505 | 271.884 | 488.602 |
| 95 | 242.247 | 464.047 | 488.602 |
| 100 | 273.808 | 464.047 | 488.602 |
+---------+------------------+------------------+-------------------+
Table 2: Loss of Connectivity Time, Data Rate - 10 Seconds / Packet.
表2：接続時間の損失、データレート-10秒/パケット。
The data for Figure 14 can be found in Table 3. The table shows how the CDF of time without connectivity to the LBR increases while we increase the time period to emit new DAG sequence numbers, when the nodes generate a packet every 20 seconds.
図14のデータは表3にあります。この表は、ノードが20秒ごとにパケットを生成するときに、LBRに接続されていない時間のCDFが増加し、新しいDAGシーケンス番号を発行する期間を増やす方法を示しています。
+---------+------------------+------------------+-------------------+
| CDF | Repair Period | Repair Period | Repair Period |
| (%age) | 10 Minutes | 30 Minutes | 60 Minutes |
+---------+------------------+------------------+-------------------+
| 0 | 0.071 | 0.955 | 0.167 |
| 5 | 0.126 | 2.280 | 1.377 |
| 10 | 0.403 | 2.926 | 1.409 |
| 15 | 0.902 | 3.269 | 1.409 |
| 20 | 1.281 | 16.623 | 3.054 |
| 25 | 2.322 | 21.438 | 5.175 |
| 30 | 2.860 | 48.479 | 5.175 |
| 35 | 3.316 | 49.495 | 10.30 |
| 40 | 3.420 | 93.700 | 25.406 |
| 45 | 6.363 | 117.594 | 25.406 |
| 50 | 11.500 | 243.429 | 34.379 |
| 55 | 19.703 | 277.039 | 102.141 |
| 60 | 22.216 | 284.660 | 102.141 |
| 65 | 39.211 | 285.101 | 328.293 |
| 70 | 63.197 | 376.549 | 556.296 |
| 75 | 88.986 | 443.450 | 556.296 |
| 80 | 147.509 | 452.883 | 1701.52 |
| 85 | 154.26 | 653.420 | 2076.41 |
| 90 | 244.241 | 720.032 | 2076.41 |
| 95 | 518.835 | 1760.47 | 2076.41 |
| 100 | 555.57 | 1760.47 | 2076.41 |
+---------+------------------+------------------+-------------------+
Table 3: Loss of Connectivity Time, Data Rate - 20 Seconds / Packet.
表3：接続時間の損失、データレート-20秒/パケット。
Figure 16 shows the effect of the DAG global repair timer period on control traffic. As expected, as the frequency at which new DAG sequence numbers are generated increases, the amount of control traffic decreases because DIO messages are sent less frequently to rebuild the DODAG. However, reducing the control traffic comes at a price of increased loss of connectivity when only global repair is used.
図16は、DAGグローバル修復タイマー期間が制御トラフィックに及ぼす影響を示しています。予想どおり、新しいDAGシーケンス番号が生成される頻度が高くなると、DIOAGがDODAGを再構築するために送信される頻度が低くなるため、制御トラフィックの量が減少します。ただし、グローバルな修復だけを使用すると、制御トラフィックを削減すると、接続の損失が増加するという犠牲が伴います。
Figure 16 [See the PDF.]
図16 [PDFを参照してください。]
Figure 16: Amount of Control Traffic for Different Global Repair Periods.
図16：さまざまなグローバル修理期間の制御トラフィックの量。
From the above results, it is clear that the time the protocol takes to re-establish routes and to converge, after an unexpected link or device failure happens, is fairly long. [RFC5826] mandates that "the routing protocol MUST converge within 0.5 seconds if no nodes have moved". Clearly, implementation of a repair mechanism based on new DAG sequence numbers alone would not meet the requirements. Hence, a local repair mechanism, in the form of poisoning the sub-DAG and issuing a DIS, has been adopted.
上記の結果から、予期しないリンクまたはデバイスの障害が発生した後、プロトコルがルートを再確立して収束するのにかかる時間がかなり長いことは明らかです。 [RFC5826]は、「ノードが移動していない場合、ルーティングプロトコルは0.5秒以内に収束する必要がある」ことを義務付けています。明らかに、新しいDAGシーケンス番号に基づく修復メカニズムの実装だけでは要件を満たしません。したがって、サブDAGを汚染し、DISを発行するという形のローカル修復メカニズムが採用されています。
The effect of the DAG repair timer on time without service when local repair is activated is now observed and plotted in Figure 17, where the source rate is 20 seconds/packet. A comparison of the CDF of loss of connectivity for the global repair mechanism and the global + local repair mechanism is shown in Figures 18 and 19 (semi-log plots, x axis in logarithmic scale and y axis in linear scale), where the source generates a packet every 10 seconds and 20 seconds, respectively. For these plots, the x axis shows time in log scale, and the y axis denotes the corresponding CDF in linear scale. One can observe that using local repair (with poisoning of the sub-DAG) greatly reduces loss of connectivity.
ローカル修復がアクティブになっているときのDAG修復タイマーがサービスなしの時間に与える影響が図17に示され、プロットされています。ここで、ソースレートは20秒/パケットです。グローバル修復メカニズムとグローバル+ローカル修復メカニズムの接続が失われた場合のCDFの比較を図18と19に示します（片対数プロット、対数スケールのx軸と線形スケールのy軸）。それぞれ10秒と20秒ごとにパケットを生成します。これらのプロットでは、x軸は対数目盛で時間を示し、y軸は線形目盛で対応するCDFを示します。ローカル修復（サブDAGのポイズニングを伴う）を使用すると、接続の損失が大幅に減少することがわかります。
Figure 17 [See the PDF.]
図17 [PDFを参照してください。]
Figure 17: CDF: Loss of Connectivity for Different DAG Repair Timer Values for Global+Local Repair, Source Rate 20 Seconds/Packet.
図17：CDF：グローバル+ローカル修復のさまざまなDAG修復タイマー値の接続の喪失、ソースレート20秒/パケット。
Figure 18 [See the PDF.]
図18 [PDFを参照してください。]
Figure 18: CDF: Loss of Connectivity for Global Repair and Global+Local Repair, Source Rate 10 Seconds/Packet.
図18：CDF：グローバル修復とグローバル+ローカル修復の接続性の損失、ソースレート10秒/パケット。
Figure 19 [See the PDF.]
図19 [PDFを参照してください。]
Figure 19: CDF: Loss of Connectivity for Global Repair and Global+Local Repair, Source Rate 20 Seconds/Packet.
図19：CDF：グローバル修復とグローバル+ローカル修復の接続の喪失、ソースレート20秒/パケット。
A comparison between the amount of control plane overhead used for global repair only and for the global plus local repair mechanism is shown in Figure 20, which highlights the improved performance of RPL in terms of convergence time at very little extra overhead. From Figure 19, in 85% of the cases the protocol finds connectivity to the LBR for the concerned nodes within a fraction of seconds when local repair is employed. Using only global repair leads to repair periods of 150-154 seconds, as observed in Figures 13 and 14.
グローバル修復のみとグローバルおよびローカル修復メカニズムに使用されるコントロールプレーンオーバーヘッドの量の比較を図20に示します。これは、追加オーバーヘッドがほとんどない場合のコンバージェンス時間に関してRPLのパフォーマンスが向上していることを示しています。図19から、85％のケースで、ローカル修復が採用されている場合、プロトコルは、関係するノードのLBRへの接続を数分の一秒以内に見つけます。図13と14に見られるように、グローバル修復のみを使用すると、150〜154秒の修復期間になります。
Figure 20 [See the PDF.]
図20 [PDFを参照してください。]
Figure 20: Number of Control Packets for Different DAG Sequence Number Period, for Both Global Repair and Global+Local Repair.
図20：グローバル修復とグローバル+ローカル修復の両方の、異なるDAGシーケンス番号期間の制御パケット数。
Unlike the previous traffic pattern, where a majority of the total traffic generated by any node is destined to the root, this section considers a different traffic pattern, which is more prominent in a home or building routing scenario. In the simulations shown below, the nodes send 60% of their total generated traffic to the physically 1-hop distant node and 20% of traffic to a 2-hop distant node; the other 20% of traffic is distributed among other nodes in the network. The CDF of path quality metrics such as hop count, ETX path cost, average hop distance stretch, ETX path stretch, and delay for P2P routing for all pairs of nodes is calculated. Maintaining a low delay bound for P2P traffic is of high importance, as applications in home and building routing typically have low delay tolerance.
任意のノードによって生成された総トラフィックの大部分がルートを宛先とする以前のトラフィックパターンとは異なり、このセクションでは、ホームまたはビルディングのルーティングシナリオでより目立つ、異なるトラフィックパターンについて検討します。以下に示すシミュレーションでは、ノードは生成されたトラフィック全体の60％を物理的に1ホップの遠隔ノードに送信し、20％のトラフィックを2ホップの遠隔ノードに送信します。トラフィックの残りの20％は、ネットワーク内の他のノードに分散されます。ホップカウント、ETXパスコスト、平均ホップ距離ストレッチ、ETXパスストレッチ、ノードのすべてのペアのP2Pルーティングの遅延などのパス品質メトリックのCDFが計算されます。 P2Pトラフィックの遅延限界を低く維持することは非常に重要です。これは、家庭やビルのルーティングのアプリケーションは通常、遅延の許容度が低いためです。
Figure 21 shows the CDF of the hop count for both RPL and ideal shortest path routing for the traffic pattern described above. Figure 22 shows the CDF of the expected number of transmissions (ETX) for each packet to reach its destination. Figures 23 and 24 show the CDF of the stretch factor for these two metrics. To illustrate the stretch factor, an example from Figure 24 will be given next. For all paths built by RPL, 85% of the time, the path cost is less than the path cost for the ideal shortest path plus one.
図21は、RPLと上記のトラフィックパターンの理想的な最短パスルーティングの両方のホップカウントのCDFを示しています。図22は、各パケットが宛先に到達するための予想送信数（ETX）のCDFを示しています。図23および24は、これら2つのメトリックのストレッチファクターのCDFを示しています。ストレッチファクターを説明するために、図24の例を次に示します。 RPLによって構築されたすべてのパスについて、時間の85％で、パスコストは理想的な最短パスに1を加えたパスコストよりも小さくなります。
Figure 21 [See the PDF.]
図21 [PDFを参照してください。]
Figure 21: CDF of End-to-End Hop Count for RPL and Ideal Shortest Path in Home Routing.
図21：RPLのエンドツーエンドホップカウントのCDFとホームルーティングの理想的な最短パス。
Figure 22 [See the PDF.]
図22 [PDFを参照してください。]
Figure 22: CDF of ETX Path Cost Metric for RPL and Ideal Shortest Path in Home Routing.
図22：RPLのETXパスコストメトリックのCDFおよびホームルーティングの理想的な最短パス。
Figure 23 [See the PDF.]
図23 [PDFを参照してください。]
Figure 23: CDF of Hop Distance Stretch from Ideal Shortest Path.
図23：理想的な最短経路からのホップ距離ストレッチのCDF。
Figure 24 [See the PDF.]
図24 [PDFを参照してください。]
Figure 24: CDF of ETX Metric Stretch from Ideal Shortest Path.
図24：理想的な最短経路からのETXメトリックストレッチのCDF。
To get an idea of maximum observable delay in the above-mentioned traffic pattern, the delay for different numbers of hops to the destination for RPL is considered. Figure 25 shows how the end-to-end packet latency is distributed for different packets with different hop counts in the network.
上記のトラフィックパターンで観測可能な最大遅延を把握するために、RPLの宛先までのホップ数が異なる場合の遅延を検討します。図25は、ネットワーク内のホップカウントが異なるさまざまなパケットに対して、エンドツーエンドのパケット遅延がどのように分散されるかを示しています。
Figure 25 [See the PDF.]
図25 [PDFを参照してください。]
Figure 25: Packet Latency for Different Hop Counts in RPL.
図25：RPLのさまざまなホップカウントのパケット遅延。
For this deployment scenario, 60% of the traffic has been restricted to a 1-hop neighborhood. Hence, intuitively, the protocol is expected to yield path qualities that are close to those of ideal shortest path routing for most of the paths. From the CDF of the hop count and ETX path cost, it is clear that peer-to-peer paths are more often closer to an ideal shortest path. The end-to-end delay for distances within 2 hops is less than 60 ms for 99% of the delivered packets, while packets traversing 5 hops or more are delivered within 100 ms 99% of the time. These results demonstrate that for a normal routing scenario of an LLN deployment in a building, RPL performs fairly well without incurring much control plane overhead, and it can be applied for delay-critical applications as well.
この展開シナリオでは、トラフィックの60％が1ホップの近隣に制限されています。したがって、直感的に、プロトコルは、ほとんどのパスの理想的な最短パスルーティングに近いパス品質を実現することが期待されます。ホップカウントのCDFとETXパスコストから、ピアツーピアパスが理想的な最短パスに近いことが多いことがわかります。 2ホップ以内の距離のエンドツーエンド遅延は、配信されたパケットの99％で60ミリ秒未満ですが、5ホップ以上を通過するパケットは99％の時間で100ミリ秒以内に配信されます。これらの結果は、建物内のLLN展開の通常のルーティングシナリオの場合、RPLは、コントロールプレーンのオーバーヘッドをあまり発生させずに十分に機能し、遅延が重要なアプリケーションにも適用できることを示しています。
In this section, we focus on simulating RPL in a large network and study its scalability by focusing on a few performance metrics: the latency and path cost stretch, and the amount of control packets. The 2442-node smart meter network with its corresponding link traces was used in this scalability study. To simulate a more realistic scenario for a smart meter network, 100% of the packets generated by each node are destined to the root. Therefore, no traffic is destined to nodes other than the root.
このセクションでは、大規模ネットワークでのRPLのシミュレーションに焦点を当て、レイテンシとパスコストのストレッチ、および制御パケットの量など、いくつかのパフォーマンスメトリックに焦点を当てて、そのスケーラビリティを調査します。このスケーラビリティ調査では、対応するリンクトレースを備えた2442ノードのスマートメーターネットワークが使用されました。スマートメーターネットワークのより現実的なシナリオをシミュレートするために、各ノードによって生成されたパケットの100％がルートを宛先としています。したがって、ルート以外のノード宛てのトラフィックはありません。
To investigate RPL's scalability, the CDF of the ETX path cost in the large-scale smart meter network is compared to a hypothetical ideal shortest path routing protocol that minimizes the total ETX path cost (Figure 26). In this simulation, the path stretch is also calculated for each packet that traverses the network. The path stretch is determined as the difference between the path cost taken by a packet while following a route built via RPL and a path computed using an ideal shortest path routing protocol. The CDF of the ETX fractional stretch, which is determined as the ETX metric stretch value over the ETX path cost of an ideal shortest path, is plotted in Figure 27.
RPLのスケーラビリティを調査するために、大規模なスマートメーターネットワークにおけるETXパスコストのCDFを、ETXパスコストの合計を最小化する仮想の理想的な最短パスルーティングプロトコルと比較します（図26）。このシミュレーションでは、ネットワークを通過する各パケットのパスストレッチも計算されます。パスストレッチは、RPLを介して構築されたルートをたどる間にパケットが取るパスコストと、理想的な最短パスルーティングプロトコルを使用して計算されたパスとの差として決定されます。理想的な最短パスのETXパスコストに対するETXメトリックストレッチ値として決定されるETXフラクショナルストレッチのCDFを図27にプロットします。
The fractional hop distance stretch value, as defined in the Terminology section, is shown in Figure 28.
「用語」セクションで定義されているフラクショナルホップディスタンスストレッチ値を図28に示します。
Looking at the path quality plots, it is obvious that RPL works in a non-optimal fashion in this deployment scenario as well. However, on average, for each source-destination pair, the ETX fractional stretch is limited to 30% of the ideal shortest path cost. This fraction is higher for paths with shorter distances and lower for paths where the source and destination are far apart. The negative stretch factor for the hop count is an interesting feature of this deployment and is due to RPL's decision to not switch to another parent where the improvement in path quality is not significant. As mentioned previously, in this implementation, a node will only switch to a new parent if the advertised ETX path cost to the LBR through the new candidate parent is 20% better than the old one. The nodes tend to hear DIOs from a smaller hop count first, and later do not always shift to a larger hop count and smaller ETX path cost. As the traffic is mostly to the DAG root, some P2P paths built via RPL do yield a smaller hop count from source to destination, albeit at a larger ETX path cost.
パス品質プロットを見ると、RPLがこの展開シナリオでも最適ではない方法で機能していることは明らかです。ただし、平均して、送信元と宛先のペアごとに、ETXフラクショナルストレッチは理想的な最短パスコストの30％に制限されます。この割合は、距離が短いパスでは高く、送信元と宛先が離れているパスでは低くなります。ホップカウントの負のストレッチファクターは、この展開の興味深い機能であり、RPLがパス品質の向上がそれほど重要でない別の親に切り替えないことにしたためです。前述のように、この実装では、新しい候補の親を介してLBRにアドバタイズされたETXパスコストが古いものよりも20％高い場合にのみ、ノードは新しい親に切り替わります。ノードは最初に小さいホップカウントからDIOを聞く傾向があり、後で常に大きいホップカウントおよび小さいETXパスコストにシフトするとは限りません。トラフィックは主にDAGルートに向かうため、RPLを介して構築された一部のP2Pパスは、ETXパスコストが大きくなりますが、ソースから宛先へのホップカウントが小さくなります。
As observed in Figure 26, 90% of the packets transmitted during the simulation have a (shortest) ETX path cost to destination less than or equal to 12. However, via RPL, 90% of the packets will follow paths that have a total ETX path cost of up to 14. Though all packets are destined to the LBR, it is to be noted that this implementation ignores a change of up to 20% in total ETX path cost. Figures 27 and 28 indicate that all paths have a very low ETX fractional stretch factor as far as the total ETX path cost is concerned, and some of the paths have lower hop counts to the LBR or DAG root as well when compared to the hop count of the ideal shortest path.
図26で確認できるように、シミュレーション中に送信されたパケットの90％は、宛先までのETXパスコストが（以下）12以下です。ただし、RPLを使用すると、パケットの90％が合計ETXを持つパスをたどります。パスコストは最大14です。すべてのパケットはLBR宛てですが、この実装では、合計ETXパスコストの最大20％の変更が無視されることに注意してください。図27と28は、ETXパスコスト全体に関する限り、すべてのパスのETXフラクショナルストレッチファクターが非常に低く、一部のパスのホップカウントがLBRまたはDAGルートへのホップカウントがホップカウントと比べて低いことを示しています。理想的な最短経路の。
Figure 26 [See the PDF.]
図26 [PDFを参照してください。]
Figure 26: CDF of Total ETX Path Cost versus ETX Path Cost.
図26：ETXパスコストとETXパスコストの合計のCDF。
Figure 27 [See the PDF.]
図27 [PDFを参照してください。]
Figure 27: CDF of ETX Fractional Stretch versus ETX Fractional Stretch Value.
図27：ETXフラクショナルストレッチとETXフラクショナルストレッチ値のCDF。
Figure 28 [See the PDF.]
図28 [PDFを参照してください。]
Figure 28: CDF of Fractional Hop Count Stretch.
図28：フラクショナルホップカウントストレッチのCDF。
Figure 29 shows how end-to-end packet latency is distributed for different hop counts in the network. According to [RFC5548], Urban LLNs (U-LLNs) are delay tolerant, and the information, except for critical alarms, should arrive within a fraction of the reporting interval (within a few seconds). The packet generation for this deployment has been set higher than usual to incur high traffic volume, and nodes generate data once every 30 seconds. However, the end-to-end latency for most of the packets is condensed between 500 ms and 1 s, where the upper limit corresponds to packets traversing longer (greater than or equal to 6 hops) paths.
図29は、ネットワーク内のさまざまなホップカウントに対してエンドツーエンドのパケット遅延がどのように分散されるかを示しています。 [RFC5548]によれば、Urban LLN（U-LLN）は遅延耐性があり、クリティカルアラームを除いて、情報はレポート間隔の一部（数秒以内）に到着するはずです。この展開のパケット生成は、トラフィック量が多くなるように通常より高く設定されており、ノードは30秒ごとにデータを生成します。ただし、ほとんどのパケットのエンドツーエンドのレイテンシは500ミリ秒から1秒の間に圧縮されます。上限は、より長い（6ホップ以上の）パスを通過するパケットに対応します。
Figure 29 [See the PDF.]
図29 [PDFを参照してください。]
Figure 29: End-to-End Packet Delivery Latency for Different Hop Counts.
図29：異なるホップカウントのエンドツーエンドのパケット配信遅延。
Figure 30 shows the comparison between data packets (originated and forwarded) and control packets (DIO and DAO messages) transmitted by each node (link ETX is used as the routing metric). Here one can observe that in spite of the large scale of the network, the amount of control traffic in the protocol is negligible in comparison to data packet transmission. The smaller node ID for this network actually indicates closer proximity to the DAG root, and nodes with high ID numbers are actually farther away from the DAG root. Also, as expected, we can observe in Figures 31, 32, and 33 that the (non-leaf) nodes closer to the DAG root have many more data packet transmissions than other nodes. The leaf nodes have comparable amounts of data and control packet transmissions, as they do not take part in routing the data. As seen before, the data traffic for a child node has much less variation than the nodes that are closer to the DAG root. This variation decreases with increase in DAG depth. In this topology, Nodes 1, 2, and 3, etc., are direct children of the LBR.
図30は、各ノードによって送信されたデータパケット（発信および転送）と制御パケット（DIOおよびDAOメッセージ）の比較を示しています（ルーティングメトリックとしてリンクETXが使用されています）。ここでは、ネットワークが大規模であるにもかかわらず、プロトコル内の制御トラフィックの量は、データパケット送信と比較してごくわずかであることがわかります。このネットワークの小さいノードIDは、実際にはDAGルートに近いことを示し、ID番号が大きいノードは実際にはDAGルートからより遠くにあります。また、予想どおり、図31、32、および33で、DAGルートに近い（非リーフ）ノードが他のノードよりもはるかに多くのデータパケットを送信していることがわかります。リーフノードはデータのルーティングに関与しないため、同等の量のデータと制御パケット送信を持っています。前に見たように、子ノードのデータトラフィックの変動は、DAGルートに近いノードよりもはるかに少ないです。この変動は、DAG深度の増加に伴って減少します。このトポロジでは、ノード1、2、3などがLBRの直接の子です。
Figure 30 [See the PDF.]
図30 [PDFを参照してください。]
Figure 30: Data and Control Packet Comparison.
図30：データと制御パケットの比較。
Figure 31 [See the PDF.]
図31 [PDFを参照してください。]
Figure 31: Data and Control Packets over Time for Node 1.
図31：ノード1のデータと制御パケットの経時変化。
Figure 32 [See the PDF.]
図32 [PDFを参照してください。]
Figure 32: Data and Control Packets over Time for Node 78.
図32：ノード78のデータと制御パケットの経時変化
Figure 33 [See the PDF.]
図33 [PDFを参照してください。]
Figure 33: Data and Control Packets over Time for Node 300.
図33：ノード300の経時的なデータおよび制御パケット
In Figure 34, the effect of the global repair period timer on control packet overhead is shown.
図34に、制御パケットのオーバーヘッドに対するグローバル修復期間タイマーの影響を示します。
Figure 34 [See the PDF.]
図34 [PDFを参照してください。]
Figure 34: Numbers of Control Packets for Different Global Repair Timer Periods.
図34：異なるグローバル修復タイマー期間の制御パケットの数。
An important metric of interest is the maximum load experienced by any node (CPU usage) in terms of the number of control packets transmitted by the node. Also, to get an idea of scaling properties of RPL in large-scale networks, it is also key to analyze the number of packets handled by the RPL nodes for networks of different sizes.
重要な測定基準は、ノードが送信する制御パケットの数に関して、ノードが経験する最大負荷（CPU使用率）です。また、大規模ネットワークでRPLのプロパティをスケーリングするアイデアを得るには、さまざまなサイズのネットワークのRPLノードによって処理されるパケット数を分析することも重要です。
In these simulations, at any given interval, the node with maximum control overhead load is identified. The amount of maximum control overhead processed by that node is plotted against time for three different networks under study. The first one is Network 'A', which has 45 nodes and is shown in Figure 1 (Section 3); the second is Network 'B', which is another deployed outdoor network with 86 nodes; and the third is Network 'C', which is the large deployed smart meter network with 2442 nodes as noted previously in this document.
これらのシミュレーションでは、任意の間隔で、制御オーバーヘッドの負荷が最大のノードが特定されます。そのノードによって処理される最大制御オーバーヘッドの量は、調査中の3つの異なるネットワークの時間に対してプロットされます。 1つ目はネットワーク「A」で、45個のノードがあり、図1（セクション3）に示されています。 2つ目はネットワーク「B」です。これは、86ノードの別の展開された屋外ネットワークです。 3つ目は、ネットワーク 'C'です。これは、このドキュメントで前述したように、2442ノードの大規模なスマートメーターネットワークです。
In Figure 35, the comparison of maximum control loads is shown for different network sizes. For the network with 45 nodes, the maximum number of control packets in the network stays within a limit of 50 packets (per 1-minute interval), where for the networks with 86 and 2442 nodes, this limit stretches to 100 and 2 * 10^3 packets per 1-minute interval, respectively.
図35に、最大ネットワーク負荷の比較をさまざまなネットワークサイズについて示します。 45ノードのネットワークの場合、ネットワーク内の制御パケットの最大数は（1分間隔で）50パケットの制限内にとどまります。86および2442ノードのネットワークでは、この制限は100および2 * 10に拡張されます。それぞれ1分間隔あたり^ 3パケット。
Figure 35 [See the PDF.]
図35 [PDFを参照してください。]
Figure 35: Scaling Property of Maximum Control Packets Processed by Any Node over Time.
図35：時間の経過とともに任意のノードによって処理される最大制御パケットのスケーリングプロパティ。
For a network built with low-power devices interconnected by lossy links, it is of the utmost importance to ensure that routing packets are not flooded in the entire network and that the routing topology stays as stable as possible. Any change in routing information, especially parent-child relationships, would reset the timer, leading to emitting new DIOs, and would hence change the node's path metric to reach the root. This change will trigger a series of control plane messages (RPL packets) in the DODAG. Therefore, it is important to carefully control the triggering of DIO control packets via the use of thresholds.
損失の多いリンクで相互接続された低電力デバイスで構築されたネットワークの場合、ルーティングパケットがネットワーク全体にフラッディングされないようにし、ルーティングトポロジができるだけ安定した状態を保つことが最も重要です。ルーティング情報、特に親子関係が変更されると、タイマーがリセットされ、新しいDIOが発行されるため、ノードのパスメトリックがルートに到達するように変更されます。この変更により、DODAGで一連のコントロールプレーンメッセージ（RPLパケット）がトリガーされます。したがって、しきい値を使用してDIO制御パケットのトリガーを慎重に制御することが重要です。
In this study, the effect of the tolerance value that is considered before emitting a DIO reflecting a new path cost is analyzed. Four cases are considered:
この研究では、新しいパスコストを反映するDIOを発行する前に考慮される許容値の影響を分析します。 4つのケースが考慮されます。
o No change in DAG depth of a node is ignored;
o ノードのDAG深度の変更は無視されません。
o The implementation ignores a 10% change in the ETX path cost to the DAG root. That is, if the change in total path cost to the root/LBR -- due to DIO reception from the most preferred parent or due to shifting to another parent -- is less than 10%, the node will not advertise the new metric to the root;
o 実装では、DAGルートへのETXパスコストの10％の変更は無視されます。つまり、ルート/ LBRへの合計パスコストの変化（最も優先される親からのDIO受信または別の親へのシフトによる）が10％未満の場合、ノードは新しいメトリックを次のようにアドバタイズしません。ルート;
o The implementation ignores a 20% change in ETX path cost to the DAG root for any node before deciding to advertise a new depth;
o 実装では、新しい深度のアドバタイズを決定する前に、任意のノードのDAGルートへのETXパスコストの20％の変更は無視されます。
o The implementation ignores a 30% change in the total ETX path cost to the DAG root of a node before deciding to advertise a new depth.
o 実装では、新しい深度をアドバタイズすることを決定する前に、ノードのDAGルートへの合計ETXパスコストの30％の変更は無視されます。
This decision does affect the optimum path quality to the DAG root. As observed in Figure 36, for 0% tolerance, 95% of paths used have an ETX fractional stretch factor of less than 10%. Similarly, for 10% and 20% tolerance levels, 95% of paths will have a 15% and 20% ETX fractional path stretch. However, the increased routing stability and decreased control overhead are the profit gained from the 10% extra increase in path length or ETX path cost, whichever is used as the metric to optimize the DAG.
この決定は、DAGルートへの最適なパス品質に影響を与えます。図36に見られるように、0％の許容誤差の場合、使用されるパスの95％のETXフラクショナルストレッチファクターは10％未満です。同様に、10％および20％の許容レベルでは、95％のパスに15％および20％のETX部分パスストレッチがあります。ただし、ルーティングの安定性の向上と制御オーバーヘッドの減少は、DAGを最適化するメトリックとして使用されるパス長またはETXパスコストの10％の追加増加から得られる利益です。
Figure 36 [See the PDF.]
図36 [PDFを参照してください。]
Figure 36: ETX Fractional Stretch Factor for Different Tolerance Levels.
図36：さまざまな許容レベルのETXフラクショナルストレッチファクター。
As the above-mentioned threshold also affects the path taken by a packet, this study also demonstrates the effect of the threshold on routing stability (number of times P2P paths change between a source and a destination). For Network 'A' (shown in Figure 1) and the large smart meter network 'C', the CDF of path change is plotted in Figures 37 and 38, respectively, against the fraction of path change for different thresholds (triggering the emission of a new DIO upon path cost change).
上記のしきい値は、パケットがたどるパスにも影響を与えるため、この調査では、ルーティングの安定性（送信元と宛先の間でP2Pパスが変化する回数）に対するしきい値の影響も示しています。ネットワーク 'A'（図1に示す）および大規模なスマートメーターネットワーク 'C'の場合、パスの変化のCDFは、図37および38にそれぞれ異なるしきい値のパスの変化の割合に対してプロットされます（パスコスト変更時の新しいDIO）。
If X packets are transferred from source A to destination B, and out of X times, Y times the path between this source-destination pair is changed, then we compute the fraction of path change as Y/X * 100%. This metric is computed over all source-destination pairs, and the CDF is plotted in the y axis.
Xパケットが送信元Aから宛先Bに転送され、X回のうち、Y回この送信元と宛先のペア間のパスが変更された場合、パス変更の割合をY / X * 100％として計算します。このメトリックは、すべての送信元と宛先のペアに対して計算され、CDFはy軸にプロットされます。
Figure 37 [See the PDF.]
図37 [PDFを参照してください。]
Figure 37: Distribution of Fraction of Path Change for Network A.
図37：ネットワークAのパス変更の割合の分布
Figure 38 [See the PDF.]
図38 [PDFを参照してください。]
Figure 38: Distribution of Fraction of Path Change for Large Network C.
図38：大規模ネットワークCのパス変更の割合の分布
This document also compares the CDF of the fraction of path change for three different networks -- A, B, and C. Figure 39 shows how the three networks exhibit a change of P2P path when a 30% change in metric cost to the root is ignored before shifting to a new parent.
このドキュメントでは、3つの異なるネットワーク（A、B、C）のパス変更の割合のCDFも比較しています。図39は、ルートに対するメトリックコストの30％の変化が3つのネットワークのP2Pパスの変化を示していることを示しています。新しい親にシフトする前に無視されます。
Figure 39 [See the PDF.]
図39 [PDFを参照してください。]
Figure 39: Comparison of Distribution of Fraction of Path Change.
図39：経路変化の割合の分布の比較。
All the simulation results presented in this document corroborate the expected protocol behavior for the topologies and traffic model used in the study. For the particular discussed scenarios, the protocol is shown to meet the desired delay and convergency requirements and to exhibit self-healing properties without external intervention, incurring negligible control overhead (only a small fraction of data traffic). RPL provided near-optimum path quality for most of the packets in the scenarios considered here and is able to trade off control overhead for path quality via configurable parameters (such as decisions on when to switch to a new parent), as per the application and device requirements; thus, RPL can trade off routing stability for control overhead as well. Finally, as per the requirement of urban LLN deployments, the protocol is shown to scale to larger topologies (several thousand nodes), for the topologies considered in this implementation.
このドキュメントに示されているすべてのシミュレーション結果は、調査で使用されたトポロジとトラフィックモデルの予想されるプロトコル動作を裏付けています。議論された特定のシナリオでは、プロトコルは、望ましい遅延と収束の要件を満たし、外部の介入なしに自己回復特性を示し、無視できる制御オーバーヘッド（データトラフィックのごく一部）を招くことが示されています。 RPLは、ここで検討されているシナリオのほとんどのパケットにほぼ最適なパス品質を提供し、アプリケーションと次のように、構成可能なパラメーター（新しい親に切り替えるタイミングの決定など）を介してパス品質の制御オーバーヘッドをトレードオフできます。デバイス要件;したがって、RPLはルーティングの安定性と制御オーバーヘッドのトレードオフを兼ね備えています。最後に、アーバンLLNデプロイメントの要件に従って、この実装で考慮されるトポロジについて、プロトコルはより大きなトポロジ（数千ノード）にスケーリングすることが示されています。
This document describes investigations performed in the Castalia wireless sensor network simulator; it does not consider packets on the Internet. [RFC6550] describes security considerations for RPL networks.
このドキュメントでは、Castaliaワイヤレスセンサーネットワークシミュレーターで実行される調査について説明します。インターネット上のパケットは考慮されません。 [RFC6550]は、RPLネットワークのセキュリティに関する考慮事項について説明しています。
The authors would like to acknowledge Jerald P. Martocci, Mukul Goyal, Emmanuel Monnerie, Philip Levis, Omprakash Gnawali, and Craig Partridge for their valuable and helpful suggestions over metrics to include and overall feedback.
著者は、含めるメトリックと全体的なフィードバックに関する貴重で有用な提案について、Jerald P. Martocci、Mukul Goyal、Emmanuel Monnerie、Philip Levis、Omprakash Gnawali、およびCraig Partridgeに感謝します。
[Castalia-2.2] Boulis, A., "Castalia: Revealing pitfalls in designing distributed algorithms in WSN", Proceedings of the 5th international conference on Embedded networked sensor systems (SenSys'07), pp. 407-408, 2007.
[カスタリア-2.2] Boulis、A.、「カスタリア：WSNでの分散アルゴリズムの設計における落とし穴を明らかにする」、第5回国際ネットワークセンサー会議（SenSys'07）の議事録、pp。407-408、2007。
[NS-2] "The Network Simulator version 2 (ns-2)", <http://www.isi.edu/nsnam/ns/>.
[NS-2]「ネットワークシミュレータバージョン2（ns-2）」、<http://www.isi.edu/nsnam/ns/>。
[OMNeTpp] Varga, A., "The OMNeT++ Discrete Event Simulation System", Proceedings of the European Simulation Multiconference (ESM'2001), June 2001.
[OMNeTpp] Varga、A。、「OMNeT ++離散イベントシミュレーションシステム」、Proceedings of the European Simulation Multiconference（ESM'2001）、2001年6月。
[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, May 2009.
[RFC5548] Dohler、M。、編、Watteyne、T。、編、Winter、T。、編、およびD. Barthel、編、「都市の低電力および損失の多いネットワークのルーティング要件」、RFC 5548 、2009年5月。
[RFC5673] Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673] Pister、K.、Ed。、Thubert、P.、Ed。、Dwars、S.、T。Phinney、「Industrial Routing Requirements in Low-Power and Lossy Networks」、RFC 5673、2009年10月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」、RFC 5826、2010年4月。
[RFC5867] Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867] Martocci、J.、Ed。、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、2010年6月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「トリクルアルゴリズム」、RFC 6206、2011年3月。
[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, March 2012.
[RFC6550]冬、T。、編、Thubert、P。、編、Brandt、A。、ホイ、J。、ケルシー、R。、リーバイス、P。、ピスター、K。、ストルーイク、R。、ヴァッサー、JP。、およびR. Alexander、「RPL：IPv6 Routing Protocol for Low-Power and Lossy Networks」、RFC 6550、2012年3月。
[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, March 2012.
[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、2012年3月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ROLL-TERMS] Vasseur、JP。、「Terminology in Low power And Lossy Networks」、Work in Progress、2011年9月。
Authors' Addresses
著者のアドレス
Joydeep Tripathi (editor) Drexel University 3141 Chestnut Street 7-313 Philadelphia, PA 19104 USA
Joydeep Tripathi（編集者）ドレクセル大学3141 Chestnut Street 7-313 Philadelphia、PA 19104 USA
EMail: jt369@drexel.edu
Jaudelice C. de Oliveira (editor) Drexel University 3141 Chestnut Street 7-313 Philadelphia, PA 19104 USA
Jaudelice C. de Oliveira（編集者）ドレクセル大学3141 Chestnut Street 7-313 Philadelphia、PA 19104 USA
EMail: jau@coe.drexel.edu
JP. Vasseur (editor) Cisco Systems, Inc. 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP Vasseur（editor）Cisco Systems、Inc. 11、Rue Camille Desmoulins Issy Les Moulineaux 92782 France
EMail: jpv@cisco.com