[要約] 要約：RFC 8036は、低消費電力および損失の多いネットワーク（RPL）のルーティングプロトコルを先進的な計量インフラ（AMI）ネットワークで使用するための適用性に関する声明です。 目的：このRFCの目的は、AMIネットワークでRPLを使用する際の適用性と利点を明確にすることです。
Internet Engineering Task Force (IETF) N. Cam-Winget, Ed.
Request for Comments: 8036 Cisco Systems
Category: Standards Track J. Hui
ISSN: 2070-1721 Nest
D. Popa
Itron, Inc
January 2017
Applicability Statement for the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) Networks
Advanced Metering Infrastructure（AMI）ネットワークにおける低電力および損失の多いネットワーク（RPL）のルーティングプロトコルの適用性に関する声明
Abstract
概要
This document discusses the applicability of the Routing Protocol for Low-Power and Lossy Networks (RPL) in Advanced Metering Infrastructure (AMI) networks.
このドキュメントでは、高度なメータリングインフラストラクチャ（AMI）ネットワークにおける低電力および損失の多いネットワーク（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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8036.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8036で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Required Reading . . . . . . . . . . . . . . . . . . . . 3
1.3. Out-of-Scope Requirements . . . . . . . . . . . . . . . . 4
2. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . . . 4
3. Description of AMI Networks for Electric Meters . . . . . . . 4
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . 5
4. Smart Grid Traffic Description . . . . . . . . . . . . . . . 7
4.1. Smart Grid Traffic Characteristics . . . . . . . . . . . 7
4.2. Smart Grid Traffic QoS Requirements . . . . . . . . . . . 8
4.3. RPL Applicability per Smart Grid Traffic Characteristics 9
5. Layer-2 Applicability . . . . . . . . . . . . . . . . . . . . 9
5.1. IEEE Wireless Technology . . . . . . . . . . . . . . . . 9
5.2. IEEE Power Line Communication (PLC) Technology . . . . . 9
6. Using RPL to Meet Functional Requirements . . . . . . . . . . 10
7. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 11
7.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 11
7.1.2. DAO Policy . . . . . . . . . . . . . . . . . . . . . 11
7.1.3. Path Metrics . . . . . . . . . . . . . . . . . . . . 11
7.1.4. Objective Function . . . . . . . . . . . . . . . . . 12
7.1.5. DODAG Repair . . . . . . . . . . . . . . . . . . . . 12
7.1.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 12
7.1.7. Security . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Description of Layer-2 Features . . . . . . . . . . . . . 13
7.2.1. IEEE 1901.2 PHY and MAC Sub-layer Features . . . . . 13
7.2.2. IEEE 802.15.4 (Amendments G and E) PHY and MAC
Features . . . . . . . . . . . . . . . . . . . . . . 14
7.2.3. IEEE MAC Sub-layer Security Features . . . . . . . . 15
7.3. 6LowPAN Options . . . . . . . . . . . . . . . . . . . . . 17
7.4. Recommended Configuration Defaults and Ranges . . . . . . 17
7.4.1. Trickle Parameters . . . . . . . . . . . . . . . . . 17
7.4.2. Other Parameters . . . . . . . . . . . . . . . . . . 18
8. Manageability Considerations . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Security Considerations during Initial Deployment . . . . 20
9.2. Security Considerations during Incremental Deployment . . 20
9.3. Security Considerations Based on RPL's Threat Analysis . 20
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21
11.2. Informative references . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Advanced Metering Infrastructure (AMI) systems enable the measurement; configuration; and control of energy, gas, and water consumption and distribution; through two-way scheduled, on-exception, and on-demand communication.
Advanced Metering Infrastructure（AMI）システムは測定を可能にします。構成;エネルギー、ガス、水の消費と分配の制御。双方向のスケジュールされた、例外的な、およびオンデマンドのコミュニケーションを通じて。
AMI networks are composed of millions of endpoints, including meters, distribution automation elements, and eventually Home Area Network (HAN) devices. They are typically interconnected using some combination of wireless and power line communications, thus forming the so-called Neighbor Area Network (NAN) along with a backhaul network providing connectivity to "command-and-control" management software applications at the utility company back office.
AMIネットワークは、メーター、配電自動化要素、最終的にはホームエリアネットワーク（HAN）デバイスを含む数百万のエンドポイントで構成されています。これらは通常、ワイヤレス通信と電力線通信のいくつかの組み合わせを使用して相互接続され、いわゆるネイバーエリアネットワーク（NAN）とバックホールネットワークを形成し、公益会社のバックオフィスで「コマンドアンドコントロール」管理ソフトウェアアプリケーションへの接続を提供します。 。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
[surveySG] gives an overview of Smart Grid architecture and related applications.
[surveySG]は、スマートグリッドアーキテクチャと関連アプリケーションの概要を示しています。
A NAN can use wireless communication technology, which is based on the IEEE 802.15.4 standard family: more specifically, the Physical Layer (PHY) amendment [IEEE.802.15.4g] and the Media Access Control (MAC) sub-layer amendment [IEEE.802.15.4e], which are adapted to smart grid networks.
NANは、IEEE 802.15.4標準ファミリーに基づく無線通信技術を使用できます。具体的には、物理層（PHY）修正[IEEE.802.15.4g]およびメディアアクセス制御（MAC）サブ層修正[ IEEE.802.15.4e]、スマートグリッドネットワークに適合しています。
NAN can also use Power Line Communication (PLC) technology as an alternative to wireless communications. Several standards for PLC technology have emerged, such as [IEEE.1901.2].
NANは、ワイヤレス通信の代わりに電力線通信（PLC）テクノロジーを使用することもできます。 [IEEE.1901.2]など、PLCテクノロジのいくつかの標準が登場しました。
NAN can further use a mix of wireless and PLC technologies to increase the network coverage ratio, which is a critical requirement for AMI networks.
NANはさらに、ワイヤレステクノロジーとPLCテクノロジーの組み合わせを使用して、AMIネットワークの重要な要件であるネットワークカバレッジ率を高めることができます。
The following are outside the scope of this document:
以下は、このドキュメントの範囲外です。
o Applicability statement for RPL [RFC6550] in AMI networks composed of battery-powered devices (i.e., gas/water meters).
o バッテリ駆動のデバイス（ガス/水道メーターなど）で構成されるAMIネットワークにおけるRPL [RFC6550]の適用性ステートメント。
o Applicability statement for RPL in AMI networks composed of a mix of devices powered by alternating current (i.e., electric meters) and battery-powered meters (i.e., gas/water meters).
o 交流（つまり、電気メーター）と電池式メーター（すなわち、ガス/水道メーター）によって電力を供給されるデバイスの組み合わせで構成されるAMIネットワークにおけるRPLの適用性声明。
o Applicability statement for RPL storing mode of operation in AMI networks.
o AMIネットワークでのRPL保管動作モードの適用性ステートメント。
RPL provides routing functionality for mesh networks that can scale up to thousands of resource-constrained devices that are interconnected by low-power and lossy links and communicate with the external network infrastructure through a common aggregation point(s) (e.g., an LLN Border Router, or LBR).
RPLは、メッシュネットワークにルーティング機能を提供します。これは、低電力で損失の多いリンクによって相互接続され、共通の集約ポイント（LLNボーダールーターなど）を介して外部ネットワークインフラストラクチャと通信する、リソースに制約のある何千ものデバイスをスケールアップできます。 、またはLBR）。
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at an LBR, ensures loop-free routing, and provides support for alternate routes as well as for a wide range of routing metrics and policies.
RPLは、LBRをルートとする有向非巡回グラフ（DAG）ルーティング構造を構築し、ループのないルーティングを保証し、代替ルート、および幅広いルーティングメトリックとポリシーをサポートします。
RPL was designed to operate in energy-constrained environments and includes energy-saving mechanisms (e.g., Trickle timers) and energy-aware metrics. RPL's ability to support multiple different metrics and constraints at the same time enables it to run efficiently in heterogeneous networks composed of nodes and links with vastly different characteristics [RFC6551].
RPLは、エネルギーに制約のある環境で動作するように設計されており、省エネメカニズム（トリクルタイマーなど）とエネルギーを意識したメトリックが含まれています。複数の異なるメトリックと制約を同時にサポートするRPLの機能は、非常に異なる特性を持つノードとリンクで構成される異種ネットワーク[RFC6551]で効率的に実行できるようにします。
This document describes the applicability of RPL non-storing mode (as defined in [RFC6550]) to AMI deployments. The Routing Requirements for Urban Low-Power and Lossy Networks [RFC5548] are applicable to AMI networks as well. The terminology used in this document is defined in [RFC7102].
このドキュメントでは、AMI展開へのRPL非保存モード（[RFC6550]で定義）の適用性について説明します。都市の低電力および損失の多いネットワークのルーティング要件[RFC5548]は、AMIネットワークにも適用できます。このドキュメントで使用される用語は、[RFC7102]で定義されています。
In many deployments, in addition to measuring energy consumption, the electric meter network plays a central role in the Smart Grid since the device enables the utility company to control and query the electric meters themselves and can serve as a backhaul for all other devices in the Smart Grid, e.g., water and gas meters, distribution automation, and HAN devices. Electric meters may also be used as sensors to monitor electric grid quality and to support applications such as electric vehicle charging.
多くの導入では、電力消費量の測定に加えて、電気メーターネットワークはスマートグリッドで中心的な役割を果たします。これは、このデバイスによりユーティリティ会社が電気メーター自体を制御および照会し、その他のすべてのデバイスのバックホールとして機能できるためです。スマートグリッド、たとえば、水道およびガスメーター、配電オートメーション、HANデバイス。電気メーターは、送電網の品質を監視し、電気自動車の充電などのアプリケーションをサポートするセンサーとしても使用できます。
Electric meter networks can be composed of millions of smart meters (or nodes), each of which is resource constrained in terms of processing power, storage capabilities, and communication bandwidth due to a combination of factors including regulations on spectrum use; on meter behavior and performance; and on heat emissions within the meter, form factor, and cost considerations. These constraints result in a compromise between range and throughput with effective link throughput of tens to a few hundred kilobits per second per link, a potentially significant portion of which is taken up by protocol and encryption overhead when strong security measures are in place.
電気メーターネットワークは、数百万のスマートメーター（またはノード）で構成できます。各メーターは、スペクトルの使用に関する規制を含む要因の組み合わせにより、処理能力、ストレージ機能、および通信帯域幅の点でリソースに制約があります。メーターの動作とパフォーマンス;メーター内の熱放出、フォームファクター、およびコストに関する考慮事項。これらの制約により、範囲とスループットの妥協がもたらされ、リンクあたり1秒あたり数十キロビットから数百キロビットの実効リンクスループットが得られます。強力なセキュリティ対策が講じられている場合、プロトコルと暗号化のオーバーヘッドがその潜在的な重要部分を占めます。
Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility company network through a network aggregation point, e.g., an LBR.
電気メーターは多くの場合、マルチホップメッシュネットワークに相互接続されており、それぞれがLBRなどのネットワーク集約ポイントを介して公益事業会社のネットワークにつながるバックホールネットワークに接続されています。
AMI networks are composed of millions of endpoints distributed across both urban and rural environments. Such endpoints can include electric, gas, and water meters; distribution automation elements; and HAN devices.
AMIネットワークは、都市環境と農村環境の両方に分散した数百万のエンドポイントで構成されています。このようなエンドポイントには、電気、ガス、水道メーターを含めることができます。流通自動化要素;およびHANデバイス。
Devices in the network communicate directly with other devices in close proximity using a variety of low-power and/or lossy link technologies that are both wireless and wired (e.g., IEEE 802.15.4g, IEEE 802.15.4e, IEEE 1901.2, and [IEEE.802.11]). In addition to serving as sources and destinations of packets, many network elements typically also forward packets and thus form a mesh topology.
ネットワーク内のデバイスは、無線と有線の両方であるさまざまな低電力および/または損失のあるリンク技術（IEEE 802.15.4g、IEEE 802.15.4e、IEEE 1901.2、および[IEEE）を使用して、近接する他のデバイスと直接通信します。 .802.11]）。パケットの送信元および宛先として機能することに加えて、多くのネットワーク要素は通常、パケットも転送し、メッシュトポロジを形成します。
In a typical AMI deployment, groups of meters within physical proximity form routing domains, each in the order of a 1,000 to 10,000 meters. Thus, each electric meter mesh typically has several thousand wireless endpoints with densities varying based on the area and the terrain.
典型的なAMI展開では、物理的近接内のメーターのグループがルーティングドメインを形成し、それぞれが約1,000〜10,000メートルです。したがって、各電気メーターメッシュには通常、数千のワイヤレスエンドポイントがあり、エリアと地形に基づいて密度が異なります。
|
+M
|
M M M M | M
/-----------\ /---+---+---+---+--+-+- phase 1
+----+ ( Internet ) +-----+ / M M M M
|MDMS|---( )----| LBR |/----+----+----+----+---- phase 2
+----+ ( WAN ) +-----+\
\----------/ \ M M M M
\--+--+----+-+---+----- phase 3
\ M M
+--+---+--
<----------------------------->
RPL
Figure 1: Typical NAN Topology
ふぃぐれ １： Ｔｙぴかｌ なん とぽぉｇｙ
A typical AMI network architecture (see Figure 1) is composed of a Meter Data Management System (MDMS) connected through an IP network to an LBR, which can be located in the power substation or somewhere else in the field. The power substation connects the households and buildings. The physical topology of the electrical grid is a tree structure, either due to the three different power phases coming through the substation or just to the electrical network topology. Meters (represented by a M in the previous figure) can also participate in a HAN. The scope of this document is the communication between the LBR and the meters, i.e., the NAN segment.
典型的なAMIネットワークアーキテクチャ（図1を参照）は、IPネットワークを介してLBRに接続されたメーターデータ管理システム（MDMS）で構成されます。LBRは、変電所またはフィールドの他の場所に配置できます。変電所は、世帯と建物を接続します。配電網の物理トポロジはツリー構造です。これは、変電所を経由する3つの異なる電力フェーズ、または電気ネットワークトポロジによるものです。メーター（前の図ではMで表されています）もHANに参加できます。このドキュメントの範囲は、LBRとメーター間の通信、つまりNANセグメントです。
Node density can vary significantly. For example, apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and may include nodes that only have a small number of network neighbors. Each routing domain is connected to the larger IP infrastructure through one or more LBRs, which provide Wide Area Network (WAN) connectivity through various traditional network technologies, e.g., Ethernet, cellular, private WAN based on Worldwide Interoperability for Microwave Access (WiMAX), and optical fiber. Paths in the mesh between a network node and the nearest LBR may be composed of several hops or even several tens of hops. Powered from the main line, electric meters have less energy constraints than battery powered devices, such as gas and water meters, and can afford the additional resources required to route packets.
ノード密度は大幅に異なる場合があります。たとえば、都市の中心部にあるアパートの建物は数百メートル近くあり、農村部のノードの分布はまばらで、隣接するネットワークの数が少ないノードが含まれている場合があります。各ルーティングドメインは、1つまたは複数のLBRを介して大規模なIPインフラストラクチャに接続され、さまざまな従来のネットワークテクノロジー（たとえば、マイクロ波アクセスの世界規模の相互運用性（WiMAX）に基づくイーサネット、セルラー、プライベートWAN）を介して広域ネットワーク（WAN）接続を提供します。そして光ファイバー。ネットワークノードと最も近いLBRの間のメッシュ内のパスは、数ホップまたは数十ホップで構成される場合があります。メインラインから電力を供給される電気メーターは、ガスや水道メーターなどのバッテリー駆動のデバイスよりもエネルギーの制約が少なく、パケットのルーティングに必要な追加のリソースを提供できます。
As a function of the technology used to exchange information, the logical network topology will not necessarily match the electric grid topology. If meters exchange information through radio technologies such as in the IEEE 802.15.4 family, then the topology is a meshed network where nodes belonging to the same Destination-Oriented DAG (DODAG) can be connected to the grid through different substations. If narrowband PLC technology is used, it will more or less follow the physical tree structure since crosstalk may allow one phase to communicate with the other. This is particularly true near the LBR. Some mixed topology can also be observed since some LBRs may be strategically installed in the field to avoid all the communications going through a single LBR. Nevertheless, the short propagation range forces meters to relay the information.
情報の交換に使用されるテクノロジーの機能として、論理ネットワークトポロジーは、必ずしも電力グリッドトポロジーと一致するとは限りません。メーターがIEEE 802.15.4ファミリなどの無線技術を介して情報を交換する場合、トポロジはメッシュ化されたネットワークであり、同じDestination-Oriented DAG（DODAG）に属するノードを異なる変電所を介してグリッドに接続できます。狭帯域PLCテクノロジーが使用されている場合、クロストークによって1つのフェーズが別のフェーズと通信できるため、物理ツリー構造にほぼ従います。これはLBRの近くで特に当てはまります。一部のLBRは戦略的にフィールドにインストールされ、すべての通信が単一のLBRを通過することを回避するため、いくつかの混合トポロジーも観察できます。それにもかかわらず、伝播範囲が短いため、メーターは情報を中継する必要があります。
In current AMI deployments, metering applications typically require all smart meters to communicate with a few head-end servers that are deployed in the utility company data center. Head-end servers generate data traffic to configure smart data reading or initiate queries and use unicast and multicast to efficiently communicate with a single device (i.e., Point-to-Point (P2P) communications) or groups of devices respectively (i.e., Point-to-Multipoint (P2MP) communication). The head-end server may send a single small packet at a time to the meters (e.g., a meter read request, a small configuration change, or a service-switch command) or a series of large packets (e.g., a firmware download across one or even thousands of devices). The frequency of large file transfers (e.g., firmware download of all metering devices) is typically much lower than the frequency of sending configuration messages or queries. Each smart meter generates Smart Metering Data (SMD) traffic according to a schedule (e.g., periodic meter reads) in response to on-demand queries (e.g., on-demand meter reads) or in response to some local event (e.g., power outage or leak detection). Such traffic is typically destined to a single head-end server. The SMD traffic is thus highly asymmetric, where the majority of the traffic volume generated by the smart meters typically goes through the LBRs, and is directed from the smart meter devices to the head-end servers in a Mesh Peer-to-Peer (MP2P) fashion. Current SMD traffic patterns are fairly uniform and well understood. The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads while traffic generated by the metering devices is typically uniformly spread over some periodic read time-window.
現在のAMI展開では、メータリングアプリケーションは通常、すべてのスマートメーターが公益事業会社のデータセンターに展開されているいくつかのヘッドエンドサーバーと通信する必要があります。ヘッドエンドサーバーは、データトラフィックを生成してスマートデータ読み取りを構成するか、クエリを開始し、ユニキャストとマルチキャストを使用して、単一のデバイス（つまり、ポイントツーポイント（P2P）通信）またはデバイスのグループ（つまり、ポイントマルチポイント（P2MP）への通信）。ヘッドエンドサーバーは、一度に1つの小さなパケットをメーター（たとえば、メーターの読み取り要求、小さな構成の変更、またはサービススイッチコマンド）または一連の大きなパケット（たとえば、 1つまたは数千のデバイス）。大きなファイル転送の頻度（すべての計測デバイスのファームウェアのダウンロードなど）は、通常、構成メッセージやクエリを送信する頻度よりもはるかに低くなります。各スマートメーターは、オンデマンドクエリ（たとえば、オンデマンドメーターの読み取り）への応答またはローカルイベント（たとえば、停電）への応答として、スケジュール（定期的なメーターの読み取りなど）に従ってスマートメータリングデータ（SMD）トラフィックを生成しますまたはリーク検出）。このようなトラフィックは通常、単一のヘッドエンドサーバーに送信されます。したがって、SMDトラフィックは非常に非対称であり、スマートメーターによって生成されるトラフィック量の大部分は通常LBRを通過し、スマートメーターデバイスからメッシュピアツーピア（MP2P）のヘッドエンドサーバーに送信されます。 ） ファッション。現在のSMDトラフィックパターンはかなり均一で、よく理解されています。ヘッドエンドサーバーによって生成され、計測デバイスに送信されるトラフィックは、定期的なメーターの読み取りによって支配されますが、計測デバイスによって生成されるトラフィックは、通常、いくつかの定期的な読み取り時間ウィンドウに均一に分散されます。
Smart metering applications typically do not have hard real-time constraints, but they are often subject to bounded latency and stringent service level agreements about reliability.
スマートメータリングアプリケーションには通常、ハードリアルタイムの制約はありませんが、多くの場合、制限されたレイテンシと信頼性に関する厳しいサービスレベル契約が適用されます。
Distribution Automation (DA) applications typically involve a small number of devices that communicate with each other in a P2P fashion and may or may not be in close physical proximity. DA applications typically have more stringent latency requirements than SMD applications.
ディストリビューションオートメーション（DA）アプリケーションは通常、P2P方式で相互に通信する少数のデバイスを含み、物理的に近接している場合とそうでない場合があります。 DAアプリケーションは通常、SMDアプリケーションよりも厳しいレイテンシ要件を持っています。
There are also a number of emerging applications such as electric vehicle charging. These applications may require P2P communication and may eventually have more stringent latency requirements than SMD applications.
電気自動車の充電など、新しいアプリケーションも数多くあります。これらのアプリケーションはP2P通信を必要とする場合があり、最終的にはSMDアプリケーションよりも厳しいレイテンシ要件になる可能性があります。
As described previously, the two main traffic families in a NAN are:
前述のように、NANの2つの主要なトラフィックファミリは次のとおりです。
A) Meter-initiated traffic (Meter-to-Head-End - M2HE)
A）メーターで開始されたトラフィック（メーターからヘッドエンド-M2HE）
B) Head-end-initiated traffic (Head-End-to-Meter - HE2M)
B）ヘッドエンドで開始されたトラフィック（ヘッドエンドからメーター-HE2M）
B1) request is sent in P2P to a specific meter
B1）リクエストがP2Pで特定のメーターに送信される
B2) request is sent in multicast to a subset of meters
B2）リクエストがマルチキャストでメーターのサブセットに送信される
B3) request is sent in multicast to all meters
B3）リクエストがマルチキャストですべてのメーターに送信される
The M2HE are event based while the HE2M are mostly command response. In most cases, M2HE traffic is more critical than HE2M one, but there can be exceptions.
HE2Mはほとんどコマンド応答ですが、M2HEはイベントベースです。ほとんどの場合、M2HEトラフィックはHE2Mトラフィックよりも重要ですが、例外がある場合もあります。
Regarding priority, traffic may also be divided into several classes:
優先度に関しては、トラフィックはいくつかのクラスに分類されることもあります。
C1) High-Priority Critical traffic for Power System Outage, Pricing Events, and Emergency Messages require a 98%+ packet delivery under 5 s (payload size < 100 bytes)
C1）電力系統の停止、価格設定イベント、および緊急メッセージのための高優先度のクリティカルトラフィックでは、5秒未満の98％以上のパケット配信が必要です（ペイロードサイズ<100バイト）
C2) Critical Priority traffic for Power Quality Events and Meter Service Connection and Disconnection requires 98%+ packet delivery under 10s (payload size < 150 bytes)
C2）電力品質イベントおよびメーターサービスの接続と切断のための重要な優先トラフィックには、10％未満の98％以上のパケット配信が必要です（ペイロードサイズ<150バイト）
C3) Normal Priority traffic for System Events including Faults, Configuration, and Security requires 98%+ packet delivery under 30 s (payload size < 200 bytes)
C3）障害、構成、セキュリティを含むシステムイベントの通常優先トラフィックは、30秒未満（ペイロードサイズ<200バイト）で98％以上のパケット配信が必要
C4) Low Priority traffic for Recurrent Meter Reading requires 98%+ packet 2-hour delivery window 6 times per day (payload size < 400 bytes)
C4）定期的なメーター読み取りの優先度の低いトラフィックには、98％以上のパケット2時間の配信ウィンドウが1日に6回必要です（ペイロードサイズ<400バイト）
C5) Background Priority traffic for firmware/software updates processed to 98%+ of devices within 7 days (average firmware update is 1 MB)
C5）7日以内にデバイスの98％以上に処理されたファームウェア/ソフトウェア更新のバックグラウンド優先トラフィック（平均ファームウェア更新は1 MB）
The RPL non-storing mode of operation naturally supports upstream and downstream forwarding of unicast traffic between the DODAG root and each DODAG node, and between DODAG nodes and the DODAG root, respectively.
RPL非保存動作モードは、当然、それぞれDODAGルートと各DODAGノード間、およびDODAGノードとDODAGルート間のユニキャストトラフィックのアップストリームおよびダウンストリーム転送をサポートします。
The group communication model used in smart grid requires the RPL non-storing mode of operation to support downstream forwarding of multicast traffic with a scope larger than link-local. The DODAG root is the single device that injects multicast traffic, with a scope larger than link-local, into the DODAG.
スマートグリッドで使用されるグループ通信モデルでは、リンクローカルよりも大きなスコープを持つマルチキャストトラフィックのダウンストリーム転送をサポートするために、RPL非保存動作モードが必要です。 DODAGルートは、リンクローカルより大きなスコープを持つマルチキャストトラフィックをDODAGに注入する単一のデバイスです。
IEEE amendments 802.15.4g and 802.15.4e to the standard IEEE 802.15.4 have been specifically developed for smart grid networks. They are the most common PHY and MAC layers used for wireless AMI networks. IEEE 802.15.4g specifies multiple modes of operation (FSK, OQPSK, and OFDM modulations) with speeds from 50 kbps to 600 kbps and allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper-layer segmentation and reassembly.
標準のIEEE 802.15.4に対するIEEE修正802.15.4gおよび802.15.4eは、スマートグリッドネットワーク用に特別に開発されました。これらは、ワイヤレスAMIネットワークで使用される最も一般的なPHYおよびMAC層です。 IEEE 802.15.4gは、50 kbpsから600 kbpsの速度で複数の動作モード（FSK、OQPSK、およびOFDM変調）を指定し、上位層のセグメンテーションを必要とせずに完全なIPv6パケット（つまり、1280オクテット）の転送を可能にします。再組み立て。
IEEE Std 802.15.4e is an amendment to IEEE Std 802.15.4 that specifies additional Media Access Control (MAC) behaviors and frame formats that allow IEEE 802.15.4 devices to support a wide range of industrial and commercial applications that were not adequately supported prior to the release of this amendment. It is important to notice that IEEE 802.15.4e does not change the link-layer security scheme defined in the last two updates to IEEE Std 802.15.4 (e.g., 2006 and 2011 amendments).
IEEE Std 802.15.4eは、IEEE 802.15.4デバイスが以前は適切にサポートされていなかった幅広い産業および商用アプリケーションをサポートできるようにする追加のメディアアクセス制御（MAC）動作とフレームフォーマットを指定するIEEE Std 802.15.4の修正版です。この修正のリリースに。 IEEE 802.15.4eは、IEEE Std 802.15.4への最後の2つの更新で定義されたリンク層セキュリティスキームを変更しないことに注意することが重要です（例：2006および2011の修正）。
IEEE Std 1901.2 specifies communications for low frequency (less than 500 kHz) narrowband power line devices via alternating current and direct current electric power lines. IEEE Std 1901.2 supports indoor and outdoor communications over a low voltage line (the line between transformer and meter, which is less than 1000 V) through a transformer of low-voltage to medium-voltage (1000 V up to 72 kV) and through a transformer of medium-voltage to low-voltage power lines in both urban and in long distance (multi-kilometer) rural communications.
IEEE Std 1901.2は、交流および直流電力線を介した低周波数（500 kHz未満）狭帯域電力線デバイスの通信を規定しています。 IEEE Std 1901.2は、低電圧から中電圧（1000 Vから72 kVまで）の変圧器を介した低電圧ライン（変圧器とメーター間のライン、1000 V未満）を介した屋内および屋外の通信をサポートします。都市および長距離（数キロメートル）の農村通信における中電圧から低電圧の送電線の変圧器。
IEEE Std 1901.2 defines the PHY layer and the MAC sub-layer of the data link layer. The MAC sub-layer endorses a subset of IEEE Std 802.15.4 and IEEE 802.15.4e MAC sub-layer features.
IEEE Std 1901.2は、データリンク層のPHY層とMACサブ層を定義しています。 MACサブレイヤーは、IEEE Std 802.15.4およびIEEE 802.15.4e MACサブレイヤー機能のサブセットを承認します。
The IEEE Std 1901.2 PHY layer bit rates are scalable up to 500 kbps depending on the application requirements and type of encoding used.
IEEE Std 1901.2 PHY層のビットレートは、アプリケーションの要件と使用するエンコーディングのタイプに応じて、最大500 kbpsまで拡張可能です。
The IEEE Std 1901.2 MAC layer allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper-layer segmentation and reassembly.
IEEE Std 1901.2 MACレイヤーは、上位レイヤーのセグメント化と再構成を必要とせずに、完全なIPv6パケット（つまり、1280オクテット）の転送を可能にします。
IEEE Std 1901.2 specifies the necessary link-layer security features that fully endorse the IEEE 802.15.4 MAC sub-layer security scheme.
IEEE Std 1901.2は、IEEE 802.15.4 MACサブレイヤーセキュリティスキームを完全に保証するために必要なリンクレイヤーセキュリティ機能を規定しています。
The functional requirements for most AMI deployments are similar to those listed in [RFC5548]. This section informally highlights some of the similarities:
ほとんどのAMI展開の機能要件は、[RFC5548]にリストされているものと同様です。このセクションでは、非公式にいくつかの類似点を取り上げます。
o The routing protocol MUST be capable of supporting the organization of a large number of nodes into regions containing on the order of 10^2 to 10^4 nodes each.
o ルーティングプロトコルは、それぞれが10 ^ 2から10 ^ 4のノードを含む領域への多数のノードの編成をサポートできる必要があります。
o The routing protocol MUST provide mechanisms to support configuration of the routing protocol itself.
o ルーティングプロトコルは、ルーティングプロトコル自体の構成をサポートするメカニズムを提供する必要があります。
o The routing protocol SHOULD support and utilize the large number of highly directed flows to a few head-end servers to handle scalability.
o ルーティングプロトコルは、スケーラビリティを処理するために、少数のヘッドエンドサーバーへの多数の高度なフローをサポートおよび利用する必要があります（SHOULD）。
o The routing protocol MUST dynamically compute and select effective routes composed of low-power and lossy links. Local network dynamics SHOULD NOT impact the entire network. The routing protocol MUST compute multiple paths when possible.
o ルーティングプロトコルは、低電力で損失の多いリンクで構成される効果的なルートを動的に計算して選択する必要があります。ローカルネットワークのダイナミクスは、ネットワーク全体に影響を与えるべきではありません。ルーティングプロトコルは、可能な場合、複数のパスを計算する必要があります。
o The routing protocol MUST support multicast and unicast addressing. The routing protocol SHOULD support formation and identification of groups of field devices in the network.
o ルーティングプロトコルは、マルチキャストおよびユニキャストアドレス指定をサポートする必要があります。ルーティングプロトコルは、ネットワーク内のフィールドデバイスのグループの形成と識別をサポートする必要があります（SHOULD）。
RPL supports the following features:
RPLは次の機能をサポートしています。
o Scalability: Large-scale networks characterized by highly directed traffic flows between each smart meter and the head-end servers in the utility network. To this end, RPL builds a Directed Acyclic Graph (DAG) rooted at each LBR.
o スケーラビリティ：各スマートメーターとユーティリティネットワークのヘッドエンドサーバー間の高度に誘導されたトラフィックフローを特徴とする大規模ネットワーク。このため、RPLは各LBRをルートとする有向非巡回グラフ（DAG）を構築します。
o Zero-touch configuration: This is done through in-band methods for configuring RPL variables using DIO (DODAG Information Object) messages and DIO message options [RFC6550].
o ゼロタッチ構成：これは、DIO（DODAG情報オブジェクト）メッセージとDIOメッセージオプション[RFC6550]を使用してRPL変数を構成するためのインバンドメソッドを通じて行われます。
o The use of links with time-varying quality characteristics: This is accomplished by allowing the use of metrics that effectively capture the quality of a path (e.g., Expected Transmission Count (ETX)) and by limiting the impact of changing local conditions by discovering and maintaining multiple DAG parents (and by using local repair mechanisms when DAG links break).
o 時変品質特性を備えたリンクの使用：これは、パスの品質を効果的にキャプチャするメトリック（たとえば、予想送信数（ETX））の使用を許可し、発見および複数のDAG親を維持する（およびDAGリンクが切断されたときにローカル修復メカニズムを使用する）。
RPL operation is defined for a single RPL instance. However, multiple RPL instances can be supported in multi-service networks where different applications may require the use of different routing metrics and constraints, e.g., a network carrying both SMD and DA traffic.
RPL操作は、単一のRPLインスタンスに対して定義されます。ただし、マルチサービスネットワークでは複数のRPLインスタンスをサポートできますが、SMDとDAの両方のトラフィックを伝送するネットワークなど、異なるアプリケーションでは異なるルーティングメトリックと制約を使用する必要がある場合があります。
Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send Destination Advertisement Object (DAO) messages to establish downward paths from the root to themselves.
AMIシステムでは、双方向通信が必須です。その結果、ノードは、ルートから自身への下りパスを確立するために、Destination Advertisement Object（DAO）メッセージを送信する必要があります（SHOULD）。
Smart metering deployments utilize link technologies that may exhibit significant packet loss and thus require routing metrics that take packet loss into account. To characterize a path over such link technologies, AMI deployments can use the ETX metric as defined in [RFC6551].
スマートメータリング配置は、大きなパケット損失を示す可能性のあるリンクテクノロジーを利用しているため、パケット損失を考慮するルーティングメトリックが必要です。このようなリンクテクノロジー上のパスを特徴付けるために、AMIの導入では、[RFC6551]で定義されているETXメトリックを使用できます。
Additional metrics may be defined in companion RFCs.
追加のメトリックは、関連するRFCで定義できます。
RPL relies on an Objective Function for selecting parents and computing path costs and rank. This objective function is decoupled from the core RPL mechanisms and also from the metrics in use in the network. Two objective functions for RPL have been defined at the time of this writing, Objective Function 0 (OF0) [RFC6552] and Minimum Rank with Hysteresis Objective Function (MRHOF) [RFC6719], both of which define the selection of a preferred parent and backup parents and are suitable for AMI deployments.
RPLは、目的関数を使用して、親を選択し、パスのコストとランクを計算します。この目的関数は、コアRPLメカニズムとネットワークで使用されているメトリックから分離されています。この記事の執筆時点でRPLの2つの目的関数が定義されています。目的関数0（OF0）[RFC6552]とヒステリシス目的関数の最小ランク（MRHOF）[RFC6719]の両方で、優先される親とバックアップの選択を定義します親およびAMIの展開に適しています。
Additional objective functions may be defined in companion RFCs.
追加の目的関数は、関連するRFCで定義できます。
To effectively handle time-varying link characteristics and availability, AMI deployments SHOULD utilize the local repair mechanisms in RPL. Local repair is triggered by broken link detection. The first local repair mechanism consists of a node detaching from a DODAG and then reattaching to the same or to a different DODAG at a later time. While detached, a node advertises an infinite rank value so that its children can select a different parent. This process is known as "poisoning" and is described in Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a local DODAG, doing so in AMI for electric meters is of little benefit since AMI applications typically communicate through an LBR. After the detached node has made sufficient effort to send a notification to its children that it is detached, the node can rejoin the same DODAG with a higher rank value. The configured duration of the poisoning mechanism needs to take into account the disconnection time that applications running over the network can tolerate. Note that when joining a different DODAG, the node need not perform poisoning. The second local repair mechanism controls how much a node can increase its rank within a given DODAG version (e.g., after detaching from the DODAG as a result of broken link or loop detection). Setting the DAGMaxRankIncrease to a non-zero value enables this mechanism, and setting it to a value of less than infinity limits the cost of count-to-infinity scenarios when they occur, thus controlling the duration of disconnection applications may experience.
時変リンクの特性と可用性を効果的に処理するために、AMI展開はRPLのローカル修復メカニズムを利用する必要があります（SHOULD）。ローカル修復は、リンク切れの検出によってトリガーされます。最初のローカル修復メカニズムは、ノードがDODAGから切断され、後で同じまたは別のDODAGに再接続することで構成されます。デタッチされている間、ノードはその子が別の親を選択できるように、無限のランク値をアドバタイズします。このプロセスは「ポイズニング」と呼ばれ、[RFC6550]のセクション8.2.2.5で説明されています。 RPLはローカルDODAGを形成するオプションを提供しますが、AMIアプリケーションは通常LBRを介して通信するため、電気メーターのAMIでそれを行うことはほとんど利点がありません。デタッチされたノードは、デタッチされたという通知をその子に送信するのに十分な努力をした後、より高いランク値で同じDODAGに再参加できます。ポイズニングメカニズムの構成された期間は、ネットワーク上で実行されているアプリケーションが許容できる切断時間を考慮する必要があります。別のDODAGに参加する場合、ノードはポイズニングを実行する必要がないことに注意してください。 2番目のローカル修復メカニズムは、特定のDODAGバージョン内でノードがランクを上げることができる程度を制御します（たとえば、リンクの切断またはループの検出の結果としてDODAGから切り離された後）。 DAGMaxRankIncreaseをゼロ以外の値に設定すると、このメカニズムが有効になり、無限大未満の値に設定すると、発生するカウントツーインフィニティシナリオのコストが制限されるため、切断アプリケーションの継続時間が制御される可能性があります。
Multicast support for RPL in non-storing mode are being developed in companion RFCs (see [RFC7731]).
非保存モードでのRPLのマルチキャストサポートは、関連するRFCで開発されています（[RFC7731]を参照）。
AMI deployments operate in areas that do not provide any physical security. For this reason, the link-layer, transport-layer, and application-layer technologies utilized within AMI networks typically provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness. As a result, AMI deployments may not need to implement RPL's security mechanisms; they MUST include, at a minimum, link-layer security such as that defined by IEEE 1901.2 and IEEE 802.15.4.
AMI展開は、物理的なセキュリティを提供しない領域で動作します。このため、AMIネットワーク内で使用されるリンク層、トランスポート層、およびアプリケーション層のテクノロジーは、通常、認証、機密性、完全性、および鮮度を保証するセキュリティメカニズムを提供します。その結果、AMIデプロイメントはRPLのセキュリティメカニズムを実装する必要がない場合があります。それらには、最低でも、IEEE 1901.2およびIEEE 802.15.4で定義されているようなリンク層セキュリティが含まれている必要があります。
The IEEE Std 1901.2 PHY layer is based on OFDM modulation and defines a time frequency interleaver over the entire PHY frame coupled with a Reed Solomon and Viterbi Forward Error Correction for maximum robustness. Since the noise level in each OFDM subcarrier can vary significantly, IEEE 1901.2 specifies two complementary mechanisms that allow fine-tuning of the robustness/performance tradeoff implicit in such systems. More specifically, the first (coarse-grained) mechanism defines the modulation from several possible choices (robust (super-ROBO, ROBO), BPSK, QPSK, and so on). The second (fine-grained) mechanism maps the subcarriers that are too noisy and deactivates them.
IEEE Std 1901.2 PHYレイヤーはOFDM変調に基づいており、最大の堅牢性のためにリードソロモンおよびビタビ前方誤り訂正と結合されたPHYフレーム全体にわたって時間周波数インターリーバーを定義します。各OFDMサブキャリアのノイズレベルは大幅に異なる可能性があるため、IEEE 1901.2は、そのようなシステムに潜在するロバストネス/パフォーマンスのトレードオフの微調整を可能にする2つの補完的なメカニズムを規定しています。より具体的には、最初の（粗い）メカニズムは、いくつかの可能な選択肢（ロバスト（スーパーROBO、ROBO）、BPSK、QPSKなど）からの変調を定義します。 2番目の（きめ細かい）メカニズムは、ノイズが多すぎるサブキャリアをマッピングし、それらを非アクティブ化します。
The existence of multiple modulations and dynamic frequency exclusion renders the problem of selecting a path between two nodes non-trivial as the possible number of combinations increases significantly, e.g., use a direct link with slow robust modulation or use a relay meter with fast modulation and 12 disabled subcarriers. In addition, IEEE 1901.2 technology offers a mechanism (adaptive tone map) for periodic exchanges on the link quality between nodes to constantly react to channel fluctuations. Every meter keeps a state of the quality of the link to each of its neighbors by either piggybacking the tone mapping on the data traffic or by sending explicit tone map requests.
複数の変調と動的周波数除外の存在により、可能な組み合わせの数が大幅に増えると、2つのノード間のパスを選択する問題が重要になります。たとえば、低速の堅牢な変調で直接リンクを使用するか、高速の変調でリレーメーターを使用します。 12の無効なサブキャリア。さらに、IEEE 1901.2テクノロジーは、ノード間のリンク品質を定期的に交換してチャネルの変動に常に反応するメカニズム（アダプティブトーンマップ）を提供します。すべてのメーターは、データトラフィックのトーンマッピングをピギーバックするか、明示的なトーンマップ要求を送信することにより、各ネイバーへのリンクの品質の状態を維持します。
The IEEE 1901.2 MAC frame format shares most in common with the IEEE 802.15.4 MAC frame format [IEEE.802.15.4]. A few exceptions are described below.
IEEE 1901.2 MACフレーム形式は、IEEE 802.15.4 MACフレーム形式[IEEE.802.15.4]とほとんど共通しています。以下にいくつかの例外を示します。
o The IEEE 1901.2 MAC frame is obtained by prepending a Segment Control Field to the IEEE 802.15.4 MAC header. One function of the Segment Control Field is to signal the use of the MAC sub-layer segmentation and reassembly.
o IEEE 1901.2 MACフレームは、IEEE 802.15.4 MACヘッダーにセグメント制御フィールドを付加することによって取得されます。セグメント制御フィールドの1つの機能は、MACサブレイヤーのセグメント化と再構成の使用を通知することです。
o IEEE 1901.2 MAC frames use only the 802.15.4 MAC addresses with a length of 16 and 64 bits.
o IEEE 1901.2 MACフレームは、長さが16ビットおよび64ビットの802.15.4 MACアドレスのみを使用します。
o The IEEE 1901.2 MAC sub-layer endorses the concept of Information Elements, as defined in [IEEE.802.15.4e]. The format and use of Information Elements are not relevant to the RPL applicability statement.
o IEEE 1901.2 MACサブレイヤーは、[IEEE.802.15.4e]で定義されている情報要素の概念を承認します。情報要素の形式と使用は、RPLの適用に関する声明とは関係ありません。
The IEEE 1901.2 PHY frame payload size varies as a function of the modulation used to transmit the frame and the strength of the Forward Error Correction scheme.
IEEE 1901.2 PHYフレームのペイロードサイズは、フレームの送信に使用される変調とForward Error Correctionスキームの強度の関数として変化します。
The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY settings in use (e.g., bandwidth, modulation, tones, etc). As quoted from the IEEE 1901.2 specification:
IEEE 1901.2 PHY MTUサイズは可変であり、使用中のPHY設定（帯域幅、変調、トーンなど）に依存します。 IEEE 1901.2仕様からの引用：
For CENELEC A/B, if MSDU size is more than 247 octets for robust OFDM (ROBO) and Super-ROBO modulations or more than 239 octets for all other modulations, the MAC layer shall divide the MSDU into multiple segments as described in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the following conditions: a) For ROBO and Super-ROBO modulations, the MSDU size is more than 247 octets but less than 494 octets, b) For all other modulations, the MSDU size is more than 239 octets but less than 478 octets.
CENELEC A / Bの場合、MSDUサイズがロバストOFDM（ROBO）およびSuper-ROBO変調の場合は247オクテットを超えるか、他のすべての変調の場合は239オクテットを超える場合、MAC層は5.3で説明するようにMSDUを複数のセグメントに分割します。 7。 FCCおよびARIBの場合、MSDUサイズが次のいずれかの条件を満たす場合：a）ROBOおよびSuper-ROBO変調の場合、MSDUサイズは247オクテットを超え、494オクテット未満、b）その他のすべての変調の場合、MSDUサイズは239オクテットを超え、478オクテット未満です。
IEEE Std 802.15.4g defines multiple modes of operation, where each mode uses different modulation and has multiple data rates. Additionally, the 802.15.4g PHY layer includes mechanisms to improve the robustness of the radio communications, such as data whitening and Forward Error Correction coding. The 802.15.4g PHY frame payload can carry up to 2048 octets.
IEEE Std 802.15.4gは複数の動作モードを定義しており、各モードは異なる変調を使用し、複数のデータレートを持っています。さらに、802.15.4g PHY層には、データのホワイトニングや前方誤り訂正符号化など、無線通信の堅牢性を向上させるメカニズムが含まれています。 802.15.4g PHYフレームペイロードは、最大2048オクテットを伝送できます。
IEEE Std 802.15.4g defines the following modulations: Multi-Rate and Multi-Regional FSK (MR-FSK), MR-OFDM, and MR-O-QPSK. The (over-the-air) bit rates for these modulations range from 4.8 to 600 kbps for MR-FSK, from 50 to 600 kbps for MR-OFDM, and from 6.25 to 500 kbps for MR-O-QPSK.
IEEE Std 802.15.4gは、マルチレートおよびマルチリージョンFSK（MR-FSK）、MR-OFDM、およびMR-O-QPSKの変調を定義しています。これらの変調の（無線）ビットレートは、MR-FSKの場合は4.8〜600 kbps、MR-OFDMの場合は50〜600 kbps、MR-O-QPSKの場合は6.25〜500 kbpsです。
The MAC sub-layer running on top of a 4g radio link is based on IEEE 802.15.4e. The 802.15.4e MAC allows for a variety of modes for operation. These include:
4g無線リンク上で実行されるMACサブレイヤーは、IEEE 802.15.4eに基づいています。 802.15.4e MACでは、さまざまな動作モードが可能です。これらには以下が含まれます：
o Timetimeslotslotted Channel Hopping (TSCH): specifically designed for application domains such as process automation
o タイムスロットスロットチャネルホッピング（TSCH）：プロセス自動化などのアプリケーションドメイン向けに特別に設計
o Low-Latency Deterministic Networks (LLDN): for application domains such as factory automation.
o 低遅延確定的ネットワーク（LLDN）：ファクトリオートメーションなどのアプリケーションドメイン用。
o Deterministic and Synchronous Multi-channel Extension (DSME): for general industrial and commercial application domains that includes channel diversity to increase network robustness.
o Deterministic and Synchronous Multi-channel Extension（DSME）：ネットワークの堅牢性を高めるためのチャネルダイバーシティを含む、一般的な産業および商用アプリケーションドメイン向け。
o Asynchronous Multi-channel Adaptation (AMCA): for large infrastructure application domains.
o 非同期マルチチャネル適応（AMCA）：大規模なインフラストラクチャアプリケーションドメイン用。
The MAC addressing scheme supports short (16-bit) addresses along with extended (64-bit) addresses. These addresses are assigned in different ways and are specified by specific standards organizations. Information Elements, Enhanced Beacons, and frame version 2, as defined in IEEE 802.15.4e, MUST be supported.
MACアドレス指定スキームは、拡張（64ビット）アドレスとともに、短い（16ビット）アドレスをサポートします。これらのアドレスはさまざまな方法で割り当てられ、特定の標準化団体によって指定されます。 IEEE 802.15.4eで定義されている情報要素、拡張ビーコン、およびフレームバージョン2をサポートする必要があります。
Since the MAC frame payload size limitation is given by the 4g PHY frame payload size limitation (i.e., 2048 bytes) and MAC layer overhead (headers, trailers, Information Elements, and security overhead), the MAC frame payload MUST able to carry a full IPv6 packet of 1280 octets without upper-layer fragmentation and reassembly.
MACフレームのペイロードサイズ制限は4g PHYフレームのペイロードサイズ制限（つまり2048バイト）とMACレイヤーオーバーヘッド（ヘッダー、トレーラー、情報要素、およびセキュリティオーバーヘッド）によって与えられるため、MACフレームペイロードは完全な上位層の断片化と再構成のない1280オクテットのIPv6パケット。
Since the IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and fully endorses the security scheme defined in 802.15.4, we only focus on the description of the IEEE 802.15.4 security scheme.
IEEE 1901.2標準は802.15.4 MACサブレイヤーに基づいており、802.15.4で定義されたセキュリティスキームを完全に承認しているため、IEEE 802.15.4セキュリティスキームの説明にのみ焦点を当てます。
The IEEE 802.15.4 specification was designed to support a variety of applications, many of which are security sensitive. IEEE 802.15.4 provides four basic security services: message authentication, message integrity, message confidentiality, and freshness checks to avoid replay attacks.
IEEE 802.15.4仕様は、さまざまなアプリケーションをサポートするように設計されており、その多くはセキュリティに敏感です。 IEEE 802.15.4は、4つの基本的なセキュリティサービスを提供します。メッセージ認証、メッセージの整合性、メッセージの機密性、および再生チェックを回避するための鮮度チェックです。
The 802.15.4 security layer is handled at the media access control layer, below the 6LowPAN (IPv6 over Low-Power Wireless Personal Area Network) layer. The application specifies its security requirements by setting the appropriate control parameters into the radio/PLC stack. IEEE 802.15.4 defines four packet types: beacon frames, data frames, acknowledgment frames, and command frames for the media access control layer. The 802.15.4 specification does not support security for acknowledgement frames; data frames, beacon frames, and command frames can support integrity protection and confidentiality protection for the frames' data field. An application has a choice of security suites that control the type of security protection that is provided for the transmitted MAC frame. Each security suite offers a different set of security properties and guarantees, and ultimately offers different MAC frame formats. The 802.15.4 specification defines eight different security suites, outlined below. We can broadly classify the suites by the properties that they offer: no security, encryption only (AES-CTR), authentication only (AES-CBC-MAC), and encryption and authentication (AES-CCM). Each category that supports authentication comes in three variants depending on the size of the Message Authentication Code that it offers. The MAC can be either 4, 8, or 16 bytes long. Additionally, for each suite that offers encryption, the recipient can optionally enable replay protection.
802.15.4セキュリティレイヤーは、6LowPAN（低電力ワイヤレスパーソナルエリアネットワーク上のIPv6）レイヤーの下のメディアアクセスコントロールレイヤーで処理されます。アプリケーションは、適切な制御パラメータを無線/ PLCスタックに設定することにより、セキュリティ要件を指定します。 IEEE 802.15.4は、ビーコンフレーム、データフレーム、確認応答フレーム、およびメディアアクセス制御層のコマンドフレームの4つのパケットタイプを定義しています。 802.15.4仕様では、確認応答フレームのセキュリティはサポートされていません。データフレーム、ビーコンフレーム、およびコマンドフレームは、フレームのデータフィールドの整合性保護と機密保護をサポートできます。アプリケーションには、送信されるMACフレームに提供されるセキュリティ保護のタイプを制御するセキュリティスイートの選択肢があります。各セキュリティスイートは、異なるセキュリティプロパティと保証のセットを提供し、最終的には異なるMACフレーム形式を提供します。 802.15.4仕様では、以下に概説する8つの異なるセキュリティスイートを定義しています。セキュリティーなし、暗号化のみ（AES-CTR）、認証のみ（AES-CBC-MAC）、および暗号化と認証（AES-CCM）により、スイートを大まかに分類できます。認証をサポートする各カテゴリには、提供するメッセージ認証コードのサイズに応じて3つのバリエーションがあります。 MACの長さは4、8、または16バイトのいずれかです。さらに、暗号化を提供するスイートごとに、受信者はオプションで再生保護を有効にできます。
o Null = No security
o ヌル=セキュリティなし
o AES-CTR = Encryption only, CTR mode
o AES-CTR =暗号化のみ、CTRモード
o AES-CBC-MAC-128 = No encryption, 128-bit MAC
o AES-CBC-MAC-128 =暗号化なし、128ビットMAC
o AES-CBC-MAC-64 = No encryption, 64-bit MAC
o AES-CBC-MAC-64 =暗号化なし、64ビットMAC
o AES-CCM-128 = Encryption and 128-bit MAC
o AES-CCM-128 =暗号化および128ビットMAC
o AES-CCM-64 = Encryption and 64-bit MAC
o AES-CCM-64 =暗号化および64ビットMAC
o AES-CCM-32 = Encryption and 32-bit MAC
o AES-CCM-32 =暗号化および32ビットMAC
Note that AES-CCM-32 is the most commonly used cipher in these deployments today.
AES-CCM-32は、現在これらの展開で最も一般的に使用されている暗号であることに注意してください。
To achieve authentication, any device can maintain an Access Control List (ACL), which is a list of trusted nodes from which the device wishes to receive data. Data encryption is done by encryption of Message Authentication Control frame payload using the key shared between two devices or among a group of peers. If the key is to be shared between two peers, it is stored with each entry in the ACL list; otherwise, the key is stored as the default key. Thus, the device can make sure that its data cannot be read by devices that do not possess the corresponding key. However, device addresses are always transmitted unencrypted, which makes attacks that rely on device identity somewhat easier to launch. Integrity service is applied by appending a Message Integrity Code (MIC) generated from blocks of encrypted message text. This ensures that a frame cannot be modified by a receiver device that does not share a key with the sender. Finally, sequential freshness uses a frame counter and key sequence counter to ensure the freshness of the incoming frame and guard against replay attacks.
認証を実現するために、どのデバイスでもアクセス制御リスト（ACL）を維持できます。ACLは、デバイスがデータを受信したい信頼できるノードのリストです。データの暗号化は、2つのデバイス間またはピアのグループ間で共有されるキーを使用して、メッセージ認証制御フレームのペイロードを暗号化することによって行われます。キーが2つのピア間で共有される場合、キーはACLリストの各エントリと共に保存されます。それ以外の場合、キーはデフォルトキーとして保存されます。したがって、デバイスは、対応するキーを持たないデバイスがそのデータを読み取れないようにすることができます。ただし、デバイスアドレスは常に暗号化されずに送信されるため、デバイスIDに依存する攻撃の起動がやや容易になります。整合性サービスは、暗号化されたメッセージテキストのブロックから生成されたメッセージ整合性コード（MIC）を追加することによって適用されます。これにより、送信者と鍵を共有しない受信者デバイスがフレームを変更できないようにします。最後に、シーケンシャルフレッシュネスはフレームカウンターとキーシーケンスカウンターを使用して、着信フレームのフレッシュネスを保証し、リプレイアタックから保護します。
A cryptographic Message Authentication Code (or keyed MIC) is used to authenticate messages. While longer MICs lead to improved resiliency of the code, they also make the packet size larger and thus take up bandwidth in the network. In constrained environments such as metering infrastructures, an optimum balance between security requirements and network throughput must be found.
暗号化メッセージ認証コード（またはキー付きMIC）は、メッセージの認証に使用されます。 MICが長くなるとコードの復元力が向上しますが、パケットサイズが大きくなるため、ネットワークの帯域幅を占有します。計測インフラストラクチャなどの制約された環境では、セキュリティ要件とネットワークスループットの最適なバランスを見つける必要があります。
AMI implementations based on IEEE 1901.2 and 802.15.4 (amendments g and e) can utilize all of the IPv6 Header Compression schemes specified in Section 3 of [RFC6282] and all of the IPv6 Next Header compression schemes specified in Section 4 of [RFC6282], if reducing over the air/wire overhead is a requirement.
IEEE 1901.2と802.15.4（修正gおよびe）に基づくAMI実装は、[RFC6282]のセクション3で指定されたすべてのIPv6ヘッダー圧縮スキームと、[RFC6282]のセクション4で指定されたすべてのIPv6 Nextヘッダー圧縮スキームを利用できます。 、無線/有線オーバーヘッドの削減が必要な場合。
Trickle [RFC6206] was designed to be density aware and perform well in networks characterized by a wide range of node densities. The combination of DIO packet suppression and adaptive timers for sending updates allows Trickle to perform well in both sparse and dense environments. Node densities in AMI deployments can vary greatly, from nodes having only one or a handful of neighbors to nodes having several hundred neighbors. In high-density environments, relatively low values for Imin may cause a short period of congestion when an inconsistency is detected and DIO updates are sent by a large number of neighboring nodes nearly simultaneously. While the Trickle timer will exponentially backoff, some time may elapse before the congestion subsides. While some link layers employ contention mechanisms that attempt to avoid congestion, relying solely on the link layer to avoid congestion caused by a large number of DIO updates can result in increased communication latency for other control and data traffic in the network. To mitigate this kind of short-term congestion, this document recommends a more conservative set of values for the Trickle parameters than those specified in [RFC6206]. In particular, DIOIntervalMin is set to a larger value to avoid periods of congestion in dense environments, and DIORedundancyConstant is parameterized accordingly as described below. These values are appropriate for the timely distribution of DIO updates in both sparse and dense scenarios while avoiding the short-term congestion that might arise in dense scenarios. Because the actual link capacity depends on the particular link technology used within an AMI deployment, the Trickle parameters are specified in terms of the link's maximum capacity for transmitting link-local multicast messages. If the link can transmit m link-local multicast packets per second on average, the expected time it takes to transmit a link-local multicast packet is 1/m seconds.
Trickle [RFC6206]は密度を認識し、幅広いノード密度を特徴とするネットワークで適切に機能するように設計されています。 DIOパケット抑制と更新を送信するためのアダプティブタイマーの組み合わせにより、Trickleはスパース環境とデンス環境の両方で適切に実行できます。 AMI展開のノード密度は、隣接ノードが1つまたは少数しかないノードから、数百の隣接ノードがあるノードまで、大きく異なります。高密度環境では、Iminの値が比較的低いと、不整合が検出され、DIO更新が多数の隣接ノードによってほぼ同時に送信されるときに、短時間の輻輳が発生する可能性があります。トリクルタイマーは指数的にバックオフしますが、輻輳が収まるまでに時間がかかる場合があります。一部のリンクレイヤーは、輻輳を回避しようとする競合メカニズムを採用していますが、多数のDIO更新による輻輳を回避するためにリンクレイヤーのみに依存すると、ネットワーク内の他の制御およびデータトラフィックの通信遅延が増加する可能性があります。この種の短期的な輻輳を緩和するために、このドキュメントでは、[RFC6206]で指定されている値よりも、より慎重な値のトリクルパラメータの値を推奨しています。特に、DIOIntervalMinは、密な環境での輻輳の期間を回避するためにより大きな値に設定され、DIORedundancyConstantは以下に説明するようにパラメーター化されます。これらの値は、密なシナリオで発生する可能性がある短期的な輻輳を回避しながら、疎なシナリオと密なシナリオの両方でDIO更新をタイムリーに配布するのに適しています。実際のリンク容量はAMI展開内で使用される特定のリンク技術に依存するため、トリクルパラメータは、リンクローカルマルチキャストメッセージを送信するためのリンクの最大容量に関して指定されます。リンクが1秒あたり平均m個のリンクローカルマルチキャストパケットを送信できる場合、リンクローカルマルチキャストパケットの送信にかかる予想時間は1 / m秒です。
DIOIntervalMin: AMI deployments SHOULD set DIOIntervalMin such that the Trickle Imin is at least 50 times as long as it takes to transmit a link-local multicast packet. This value is larger than that recommended in [RFC6206] to avoid congestion in dense urban deployments as described above.
DIOIntervalMin：AMIデプロイメントは、リンクローカルマルチキャストパケットの送信にかかる時間の少なくとも50倍の時間で、トリクルIminが設定されるようにDIOIntervalMinを設定する必要があります（SHOULD）。この値は、[RFC6206]で推奨されている値よりも大きく、上記のような密集した都市配置での混雑を回避します。
DIOIntervalDoublings: AMI deployments SHOULD set DIOIntervalDoublings such that the Trickle Imax is at least 2 hours or more.
DIOIntervalDoublings：AMIデプロイメントは、トリクルImaxが少なくとも2時間以上になるようにDIOIntervalDoublingsを設定する必要があります（SHOULD）。
DIORedundancyConstant: AMI deployments SHOULD set DIORedundancyConstant to a value of at least 10. This is due to the larger chosen value for DIOIntervalMin and the proportional relationship between Imin and k suggested in [RFC6206]. This increase is intended to compensate for the increased communication latency of DIO updates caused by the increase in the DIOIntervalMin value, though the proportional relationship between Imin and k suggested in [RFC6206] is not preserved. Instead, DIORedundancyConstant is set to a lower value in order to reduce the number of packet transmissions in dense environments.
DIORedundancyConstant：AMIデプロイメントは、DIORedundancyConstantを少なくとも10の値に設定する必要があります。これは、DIOIntervalMinに選択された値が大きく、[RFC6206]で提案されているIminとkの比例関係が原因です。 [RFC6206]で提案されているIminとkの間の比例関係は保持されませんが、この増加は、DIOIntervalMin値の増加によって引き起こされるDIO更新の増加した通信待ち時間を補うことを目的としています。代わりに、DIORedundancyConstantをより低い値に設定して、高密度環境でのパケット送信の数を減らします。
o AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in 8 bits of resolution (e.g., for the ETX metric).
o AMIの展開では、MinHopRankIncreaseを256に設定する必要があり、8ビットの解像度になります（たとえば、ETXメトリックの場合）。
o To enable local repair, AMI deployments SHOULD set MaxRankIncrease to a value that allows a device to move a small number of hops away from the root. With a MinHopRankIncrease of 256, a MaxRankIncrease of 1024 would allow a device to move up to 4 hops away.
o ローカル修復を有効にするために、AMIデプロイメントはMaxRankIncreaseを、デバイスがルートから少数のホップを移動できる値に設定する必要があります（SHOULD）。 MinHopRankIncreaseが256の場合、MaxRankIncreaseが1024の場合、デバイスは最大4ホップ先に移動できます。
Network manageability is a critical aspect of smart grid network deployment and operation. With millions of devices participating in the smart grid network, many requiring real-time reachability, automatic configuration, and lightweight-network health monitoring and management are crucial for achieving network availability and efficient operation. RPL enables automatic and consistent configuration of RPL routers through parameters specified by the DODAG root and disseminated through DIO packets. The use of Trickle for scheduling DIO transmissions ensures lightweight yet timely propagation of important network and parameter updates and allows network operators to choose the trade-off point with which they are comfortable with respect to overhead vs. reliability and timeliness of network updates. The metrics in use in the network along with the Trickle Timer parameters used to control the frequency and redundancy of network updates can be dynamically varied by the root during the lifetime of the network. To that end, all DIO messages SHOULD contain a Metric Container option for disseminating the metrics and metric values used for DODAG setup. In addition, DIO messages SHOULD contain a DODAG Configuration option for disseminating the Trickle Timer parameters throughout the network. The possibility of dynamically updating the metrics in use in the network as well as the frequency of network updates allows deployment characteristics (e.g., network density) to be discovered during network bring-up and to be used to tailor network parameters once the network is operational rather than having to rely on precise pre-configuration. This also allows the network parameters and the overall routing protocol behavior to evolve during the lifetime of the network. RPL specifies a number of variables and events that can be tracked for purposes of network fault and performance monitoring of RPL routers. Depending on the memory and processing capabilities of each smart grid device, various subsets of these can be employed in the field.
ネットワークの管理性は、スマートグリッドネットワークの展開と運用の重要な側面です。数百万のデバイスがスマートグリッドネットワークに参加しているため、リアルタイムの到達可能性、自動構成、軽量ネットワークのヘルスモニタリングと管理を必要とするデバイスの多くは、ネットワークの可用性と効率的な運用を実現するために重要です。 RPLは、DODAGルートによって指定され、DIOパケットを介して配布されるパラメーターを介して、RPLルーターの自動で一貫した構成を可能にします。 TIOをDIO送信のスケジューリングに使用することで、重要なネットワークとパラメーターの更新を軽量かつタイムリーに伝達できるようになり、ネットワークオペレーターはオーバーヘッドと信頼性、およびネットワーク更新の適時性の点で快適なトレードオフポイントを選択できます。ネットワーク更新の頻度と冗長性を制御するために使用されるトリクルタイマーパラメータとともにネットワークで使用されているメトリックは、ネットワークのライフタイム中にルートによって動的に変更できます。そのために、すべてのDIOメッセージには、DODAGセットアップに使用されるメトリックおよびメトリック値を広めるためのメトリックコンテナオプションが含まれている必要があります。さらに、DIOメッセージには、ネットワーク全体にトリクルタイマーパラメーターを配布するためのDODAG構成オプションが含まれている必要があります（SHOULD）。ネットワークで使用中のメトリックとネットワーク更新の頻度を動的に更新する可能性により、ネットワークの起動時に展開特性（ネットワーク密度など）を検出し、ネットワークが動作可能になったらネットワークパラメーターを調整するために使用できます。正確な事前設定に依存する必要はありません。これにより、ネットワークの存続期間中にネットワークパラメータとルーティングプロトコル全体の動作を進化させることもできます。 RPLは、ネットワーク障害とRPLルーターのパフォーマンス監視のために追跡できる変数とイベントの数を指定します。各スマートグリッドデバイスのメモリと処理能力に応じて、これらのさまざまなサブセットをフィールドで使用できます。
Smart grid networks are subject to stringent security requirements, as they are considered a critical infrastructure component. At the same time, they are composed of large numbers of resource-constrained devices interconnected with limited-throughput links. As a result, the choice of security mechanisms is highly dependent on the device and network capabilities characterizing a particular deployment.
スマートグリッドネットワークは、重要なインフラストラクチャコンポーネントと見なされているため、厳しいセキュリティ要件の影響を受けます。同時に、これらは限られたスループットのリンクで相互接続された、リソースに制約のある多数のデバイスで構成されています。その結果、セキュリティメカニズムの選択は、特定の展開を特徴付けるデバイスおよびネットワーク機能に大きく依存します。
In contrast to other types of LLNs, in smart grid networks both centralized administrative control and access to a permanent secure infrastructure are available. As a result, smart grid networks are deployed with security mechanisms such as link-layer, transport-layer, and/or application-layer security mechanisms; while it is best practice to secure all layers, using RPL's secure mode may not be necessary. Failure to protect any of these layers can result in various attacks; a lack of strong authentication of devices in the infrastructure can lead to uncontrolled and unauthorized access. Similarly, failure to protect the communication layers can enable passive (in wireless mediums) attacks as well as man-in-the-middle and active attacks.
他のタイプのLLNとは対照的に、スマートグリッドネットワークでは、集中管理管理と永続的な安全なインフラストラクチャへのアクセスの両方を利用できます。その結果、スマートグリッドネットワークは、リンク層、トランスポート層、アプリケーション層のセキュリティメカニズムなどのセキュリティメカニズムを使用して展開されます。すべてのレイヤーを保護することをお勧めしますが、RPLの保護モードを使用する必要がない場合もあります。これらの層のいずれかを保護しないと、さまざまな攻撃が発生する可能性があります。インフラストラクチャ内のデバイスの強力な認証の欠如は、制御されていない不正なアクセスにつながる可能性があります。同様に、通信層の保護に失敗すると、パッシブ（ワイヤレスメディア）攻撃だけでなく、中間者攻撃やアクティブ攻撃も可能になります。
As this document describes the applicability of RPL non-storing mode, the security considerations as defined in [RFC6550] also apply to this document and to AMI deployments.
このドキュメントではRPL非保存モードの適用性について説明しているため、[RFC6550]で定義されているセキュリティの考慮事項は、このドキュメントとAMI展開にも適用されます。
During the manufacturing process, the meters are loaded with the appropriate security credentials (keys and certificates). The configured security credentials during manufacturing are used by the devices to authenticate with the system and to further negotiate operational security credentials for both network and application layers.
製造プロセス中に、メーターには適切なセキュリティ認証情報（キーと証明書）が読み込まれます。デバイスは、製造時に構成されたセキュリティ資格情報を使用してシステムで認証し、ネットワーク層とアプリケーション層の両方の運用セキュリティ資格情報をさらに交渉します。
If during the system operation a device fails or is known to be compromised, it is replaced with a new device. The new device does not take over the security identity of the replaced device. The security credentials associated with the failed/compromised device are removed from the security appliances.
システム操作中にデバイスに障害が発生するか、デバイスが危険にさらされていることが判明した場合、そのデバイスは新しいデバイスと交換されます。新しいデバイスは、交換されたデバイスのセキュリティIDを引き継ぎません。障害が発生したデバイスまたは侵害されたデバイスに関連付けられているセキュリティ資格情報がセキュリティアプライアンスから削除されます。
[RFC7416] defines a set of security considerations for RPL security. This document defines how it leverages the device's link-layer and application-layer security mechanisms to address the threats as defined in Section 6 of [RFC7416].
[RFC7416]は、RPLセキュリティに関する一連のセキュリティの考慮事項を定義しています。このドキュメントでは、[RFC7416]のセクション6で定義されている脅威に対処するために、デバイスのリンク層およびアプリケーション層のセキュリティメカニズムを活用する方法を定義しています。
Like any secure network infrastructure, an AMI deployment's ability to address node impersonation and active man-in-the-middle attacks rely on a mutual authentication and authorization process. To enable strong mutual authentication, all nodes, from smart meters to nodes in the infrastructure, must have a credential. The credential may be bootstrapped at the time the node is manufactured but must be appropriately managed and classified through the authorization process. The management and authorization process ensures that the nodes are properly authenticated and behaving or 'acting' in their assigned roles.
安全なネットワークインフラストラクチャと同様に、AMI展開のノードの偽装とアクティブな中間者攻撃に対処する機能は、相互認証と承認プロセスに依存しています。強力な相互認証を有効にするには、スマートメーターからインフラストラクチャ内のノードまで、すべてのノードに資格情報が必要です。クレデンシャルはノードの製造時にブートストラップされる可能性がありますが、承認プロセスを通じて適切に管理および分類する必要があります。管理と承認のプロセスにより、ノードが適切に認証され、割り当てられた役割で動作または「動作」することが保証されます。
Similarly, to ensure that data has not been modified, confidentiality and integrity at the suitable layers (e.g., the link layer, the application layer, or both) should be used.
同様に、データが変更されていないことを確認するには、適切なレイヤー（リンクレイヤー、アプリケーションレイヤー、またはその両方など）の機密性と整合性を使用する必要があります。
To provide the security mechanisms to address these threats, an AMI deployment MUST include the use of the security schemes as defined by IEEE 1901.2 (and IEEE 802.15.4) with IEEE 802.15.4 defining the security mechanisms to afford mutual authentication, access control (e.g., authorization), and transport confidentiality and integrity.
これらの脅威に対処するセキュリティメカニズムを提供するために、AMI展開には、相互認証、アクセス制御を提供するセキュリティメカニズムを定義するIEEE 802.15.4でIEEE 1901.2（およびIEEE 802.15.4）で定義されたセキュリティスキームの使用を含める必要があります（たとえば、承認）、および転送の機密性と整合性。
Privacy of information flowing through smart grid networks are subject to consideration. An evolving set of recommendations and requirements are being defined by different groups and consortiums; for example, the U.S. Department of Energy issued a document [DOEVCC] defining a process and set of recommendations to address privacy issues. As this document describes the applicability of RPL, the privacy considerations as defined in [PRIVACY] and [EUPR] apply to this document and to AMI deployments.
スマートグリッドネットワークを流れる情報のプライバシーは考慮の対象となります。進化する一連の推奨事項と要件は、さまざまなグループやコンソーシアムによって定義されています。たとえば、米国エネルギー省は、プライバシー問題に対処するためのプロセスと一連の推奨事項を定義する文書[DOEVCC]を発行しました。このドキュメントではRPLの適用性について説明しているため、[PRIVACY]と[EUPR]で定義されているプライバシーに関する考慮事項は、このドキュメントとAMI展開に適用されます。
[IEEE.1901.2] IEEE, "IEEE Standard for Low-Frequency (less than 500 kHz) Narrowband Power Line Communications for Smart Grid Applications", IEEE 1901.2-2013, DOI 10.1109/ieeestd.2013.6679210, December 2013, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6679208>.
[IEEE.1901.2] IEEE、「スマートグリッドアプリケーション用の低周波数（500 kHz未満）狭帯域電力線通信のIEEE規格」、IEEE 1901.2-2013、DOI 10.1109 / ieeestd.2013.6679210、2013年12月、<http：// ieeexplore.ieee.org/servlet/ opac？punumber = 6679208>。
[IEEE.802.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-2011, DOI 10.1109/ieeestd.2011.6012487, September 2011, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6012485>.
[IEEE.802.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-2011、DOI 10.1109 / ieeestd.2011.6012487 、2011年9月、<http://ieeexplore.ieee.org/servlet/ opac？punumber = 6012485>。
[IEEE.802.15.4e] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE 802.15.4e-2012, DOI 10.1109/ieeestd.2012.6185525, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6185523>.
[IEEE.802.15.4e] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）Amendment 1：MAC sublayer」、IEEE 802.15.4e-2012、DOI 10.1109 / ieeestd.2012.6185525、2012年4月、<http://ieeexplore.ieee.org/servlet/ opac？punumber = 6185523>。
[IEEE.802.15.4g] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) Specifications for Low-Data-Rate, Wireless, Smart Metering Utility Networks", IEEE 802.15.4g-2012, DOI 10.1109/ieeestd.2012.6190698, April 2012, <http://ieeexplore.ieee.org/servlet/ opac?punumber=6190696>.
[IEEE.802.15.4g] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）Amendment 3：Physical Layer（PHY）Specifications for Low-Data-Rate 、ワイヤレス、スマートメーターユーティリティネットワーク」、IEEE 802.15.4g-2012、DOI 10.1109 / ieeestd.2012.6190698、2012年4月、<http://ieeexplore.ieee.org/servlet/ opac？punumber = 6190696>。
[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>。
[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>。
[surveySG] Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C., Cecati, C., and G. Hancke, "A Survey on Smart Grid Potential Applications and Communication Requirements", IEEE Transactions on Industrial Informatics Volume 9, Issue 1, pp. 28-42, DOI 10.1109/TII.2012.2218253, February 2013.
[surveySG] Gungor、V.、Sahin、D.、Kocak、T.、Ergut、S.、Buccella、C.、Cecati、C。、およびG. Hancke、「スマートグリッドの潜在的なアプリケーションと通信要件に関する調査」 、IEEE Transactions on Industrial Informatics Volume 9、Issue 1、28-42ページ、DOI 10.1109 / TII.2012.2218253、2013年2月。
[DOEVCC] "Voluntary Code of Conduct (VCC) Final Concepts and Principles", January 2015, <http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Conc epts%20and%20Principles%202015_01_08%20FINAL.pdf>.
[DOEVCC]「自主行動規範（VCC）の最終概念と原則」、2015年1月、<http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Conc epts％20and％20Principles％ 202015_01_08％20FINAL.pdf>。
[EUPR] "Information for investors and data controllers", June 2016, <https://ec.europa.eu/energy/node/1748>.
[EUPR]「投資家およびデータ管理者向け情報」、2016年6月、<https://ec.europa.eu/energy/node/1748>。
[IEEE.802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, March 2012, <https://standards.ieee.org/getieee802/ download/802.11-2012.pdf>.
[IEEE.802.11] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、 IEEE 802.11-2012、DOI 10.1109 / ieeestd.2012.6178212、2012年3月、<https://standards.ieee.org/getieee802/ download / 802.11-2012.pdf>。
[PRIVACY] Thaler, D., "Privacy Considerations for IPv6 Adaptation Layer Mechanisms", Work in Progress, draft-ietf-6lo-privacy-considerations-04, October 2016.
[プライバシー] Thaler、D。、「IPv6アダプテーションレイヤーメカニズムのプライバシーに関する考慮事項」、進行中の作業、draft-ietf-6lo-privacy-considerations-04、2016年10月。
[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>。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <http://www.rfc-editor.org/info/rfc6206>.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「The Trickle Algorithm」、RFC 6206、DOI 10.17487 / RFC6206、2011年3月、<http：// www.rfc-editor.org/info/rfc6206>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282>。
[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>。
[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>。
[RFC6719] Gnawali, O. and P. Levis, "The Minimum Rank with Hysteresis Objective Function", RFC 6719, DOI 10.17487/RFC6719, September 2012, <http://www.rfc-editor.org/info/rfc6719>.
[RFC6719] Gnawali、O。およびP. Levis、「最小ヒステリシス目的関数のランク」、RFC 6719、DOI 10.17487 / RFC6719、2012年9月、<http://www.rfc-editor.org/info/rfc6719> 。
[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> 。
[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>。
Acknowledgements
謝辞
Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden were contributors and noted as authors in earlier versions of this document. The authors would also like to acknowledge the review, feedback, and comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP Vasseur.
Matthew Gillmore、Laurent Toutain、Ruben Salazar、およびKazuya Mondenが寄稿者であり、このドキュメントの以前のバージョンでは著者として記されていました。著者は、Jari Arkko、Dominique Barthel、Cedric Chauvenet、Yuichi Igarashi、Philip Levis、Jeorjeta Jetcheva、Nicolas Dejean、およびJP Vasseurのレビュー、フィードバック、コメントにも感謝します。
Authors' Addresses
著者のアドレス
Nancy Cam-Winget (editor) Cisco Systems 3550 Cisco Way San Jose, CA 95134 United States of America
Nancy Cam-Winget（編集者）Cisco Systems 3550 Cisco Way San Jose、CA 95134アメリカ合衆国
Email: ncamwing@cisco.com
Jonathan Hui Nest 3400 Hillview Ave Palo Alto, CA 94304 United States of America
Jonathan Hui Nest 3400 Hillview Ave Palo Alto、CA 94304アメリカ合衆国
Email: jonhui@nestlabs.com
Daniel Popa Itron, Inc 52, rue Camille Desmoulins Issy les Moulineaux 92130 France
Daniel Popa Itron、Inc 52、rue Camille Desmoulins Issy les Moulineaux 92130 France
Email: daniel.popa@itron.com