[要約] RFC 8352は、インターネット・オブ・シングス（IoT）プロトコルのエネルギー効率の特徴に関する要約です。このRFCの目的は、IoTデバイスのエネルギー消費を最適化し、持続可能なIoTネットワークの構築を促進することです。
Internet Engineering Task Force (IETF) C. Gomez
Request for Comments: 8352 UPC
Category: Informational M. Kovatsch
ISSN: 2070-1721 ETH Zurich
H. Tian
China Academy of Telecommunication Research
Z. Cao, Ed.
Huawei Technologies
April 2018
Energy-Efficient Features of Internet of Things Protocols
モノのインターネットプロトコルのエネルギー効率に優れた機能
Abstract
概要
This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.
このドキュメントでは、制約のあるデバイスでのエネルギー効率の高いプロトコル操作の課題と、それらの課題を克服するために使用される現在のプラクティスについて説明します。エネルギー効率の高いネットワーキングに使用される主なリンク層技術を要約し、そのような技術が上位層プロトコルに与える影響を強調して、エネルギー効率の高い動作を一緒に実現できるようにします。このドキュメントは、制約付きノードネットワーク用に指定されたIETFプロトコルスイートの各レイヤーで利用可能なエネルギー効率の高いメカニズムの概要も提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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 https://www.rfc-editor.org/info/rfc8352.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8352で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Medium Access Control and Radio Duty Cycling . . . . . . . . 6
3.1. Techniques for Radio Duty Cycling . . . . . . . . . . . . 6
3.2. Latency and Buffering . . . . . . . . . . . . . . . . . . 7
3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Radio Interface Tuning . . . . . . . . . . . . . . . . . 8
3.5. Packet Bundling . . . . . . . . . . . . . . . . . . . . . 8
3.6. Power Save Services Available in Example Low-Power Radios 8
3.6.1. Power Save Services Provided by IEEE 802.11 . . . . . 8
3.6.2. Power Save Services Provided by Bluetooth LE . . . . 10
3.6.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 11
3.6.4. Power Save Services in DECT ULE . . . . . . . . . . . 12
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 14
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 15
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Energy-Efficient Features in CoAP . . . . . . . . . . . . 16
6.2. Sleepy Node Support . . . . . . . . . . . . . . . . . . . 17
6.3. CoAP Timers . . . . . . . . . . . . . . . . . . . . . . . 17
6.4. Data Compression . . . . . . . . . . . . . . . . . . . . 18
7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Network systems for monitoring the physical world contain many battery-powered or energy-harvesting devices. For example, in an environmental monitoring system or a temperature and humidity monitoring system, there may not be always on and sustained power supplies for the potentially large number of constrained devices. In such deployment scenarios, it is necessary to optimize the energy consumption of the constrained devices. In this document, we describe techniques that are in common use at Layer 2 and at Layer 3, and we indicate the need for higher-layer awareness of lower-layer features.
現実の世界を監視するためのネットワークシステムには、多くのバッテリ駆動デバイスまたは環境発電デバイスが含まれています。たとえば、環境監視システムまたは温度と湿度の監視システムでは、制約を受ける可能性のある多数のデバイスの電源が常にオンで持続しているとは限りません。このような展開シナリオでは、制約されたデバイスのエネルギー消費を最適化する必要があります。このドキュメントでは、レイヤー2とレイヤー3で一般的に使用されている手法について説明し、下位層の機能を上位層で認識する必要性を示します。
Many research efforts have studied this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption in certain deployment scenarios or how an existing network function such as routing or security could be more energy efficient. Only few efforts have focused on energy-efficient designs for IETF protocols and standardized network stacks for such constrained devices [CLASS1-CoAP].
多くの研究努力がこの「エネルギー効率」の問題を研究してきました。この調査のほとんどは、特定の展開シナリオでシステムの電力消費を最適化する方法、またはルーティングやセキュリティなどの既存のネットワーク機能のエネルギー効率を高める方法に焦点を当てています。 IETFプロトコルのエネルギー効率の高い設計と、そのような制約されたデバイスの標準化されたネットワークスタック[CLASS1-CoAP]に焦点を当てた取り組みはほとんどありません。
The IETF has developed a suite of Internet protocols suitable for such constrained devices, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC6282] [RFC6775] [RFC4944], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. This document tries to summarize the design considerations for making the IETF constrained protocol suite as energy efficient as possible. While this document does not provide detailed and systematic solutions to the energy-efficiency problem, it summarizes the design efforts and analyzes the design space of this problem. In particular, it provides an overview of the techniques used by the lower layers to save energy and how these may impact on the upper layers. Cross-layer interaction is therefore considered in this document from this specific point of view. Providing further design recommendations that go beyond the layered protocol architecture is out of the scope of this document.
IETFは、IPv6 over Low-Power Wireless Personal Area Networks（6LoWPAN）[RFC6282] [RFC6775] [RFC4944]、低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル（ RPL）[RFC6550]、および制約付きアプリケーションプロトコル（CoAP）[RFC7252]。このドキュメントでは、IETF制約付きプロトコルスイートを可能な限りエネルギー効率の良いものにするための設計上の考慮事項を要約しようとしています。このドキュメントでは、エネルギー効率の問題に対する詳細かつ体系的な解決策は提供していませんが、設計の取り組みを要約し、この問題の設計空間を分析しています。特に、エネルギーを節約するために下位層で使用される技術の概要と、これらが上位層にどのように影響するかを説明します。したがって、このドキュメントでは、この特定の観点から、レイヤー間の相互作用について検討します。階層化プロトコルアーキテクチャを超える設計の推奨事項をさらに提供することは、このドキュメントの範囲外です。
After reviewing the energy-efficient designs of each layer, we summarize the document by presenting some overall conclusions. Though the lower-layer communication optimization is the key part of energy-efficient design, the protocol design at the upper layers is also important to make the device energy efficient.
各層のエネルギー効率の良い設計を確認した後、いくつかの全体的な結論を提示することにより、ドキュメントを要約します。下位層の通信最適化はエネルギー効率の高い設計の重要な部分ですが、上位層のプロトコル設計もデバイスのエネルギー効率を高めるために重要です。
Terms used in this document are defined in [RFC7228] [CNN-TERMS].
このドキュメントで使用される用語は、[RFC7228] [CNN-TERMS]で定義されています。
The IETF has developed protocols to enable end-to-end IP communication between constrained nodes and fully capable nodes. This work has expedited the evolution of the traditional Internet protocol stack to a lightweight Internet protocol stack. As shown in Figure 1 below, the IETF has developed CoAP as the application layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 [IEEE802.15.4] and Bluetooth Low Energy (also referred to as Bluetooth LE and BTLE), with the support of routing by RPL and efficient neighbor discovery by 6LoWPAN Neighbor Discovery (6LoWPAN-ND). 6LoWPAN is currently being adapted by the 6lo Working Group to support IPv6 over various other technologies, such as ITU-T G.9959 [G9959], Digital Enhanced Cordless Telecommunications Ultra Low Energy (DECT ULE) [TS102], Building Automation and Control Networks Master-Slave/Token-Passing (BACnet MS/TP) [MSTP], and Near Field Communication [NFC].
IETFは、制約されたノードと完全に機能するノード間のエンドツーエンドのIP通信を可能にするプロトコルを開発しました。この作業により、従来のインターネットプロトコルスタックから軽量のインターネットプロトコルスタックへの進化が促進されました。下の図1に示すように、IETFはアプリケーション層としてCoAPを、IEEE 802.15.4 [IEEE802.15.4]およびBluetooth Low Energy（Bluetooth LEおよびBTLEとも呼ばれる）でIPv6を実行するための適応層として6LoWPANを開発しました。 RPLによるルーティングと6LoWPAN近隣探索（6LoWPAN-ND）による効率的な近隣探索のサポート。 6LoWPANは現在、6loワーキンググループによって、ITU-T G.9959 [G9959]、Digital Enhanced Cordless Telecommunications Ultra Low Energy（DECT ULE）[TS102]、ビルディングオートメーションおよび制御ネットワークなどのさまざまなテクノロジーでIPv6をサポートするように適合されています。マスタースレーブ/トークン渡し（BACnet MS / TP）[MSTP]、および近距離無線通信[NFC]。
+-----+ +-----+ +-----+ +------+
|HTTP | | FTP | |SNMP | | CoAP |
+-----+ +-----+ +-----+ +------+
\ / / / \
+-----+ +-----+ +-----+ +-----+
| TCP | | UDP | | TCP | | UDP |
+-----+ +-----+ ===> +-----+ +-----+
\ / \ /
+-----+ +------+ +-------+ +------+ +-----+
| RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RTG |
+-----+ +------+ +-------+ +------+ +-----+
| |
+-------+ +-------+ +----------+
|MAC/PHY| | 6Lo |--|6LoWPAN-ND|
+-------+ +-------+ +----------+
|
+-------+
|MAC/PHY|
+-------+
Figure 1: Traditional and Lightweight Internet Protocol Stack
図1：従来の軽量のインターネットプロトコルスタック
There are numerous published studies reporting comprehensive measurements of wireless communication platforms [Powertrace]. As an example, below we list the energy-consumption profile of the most common operations involved in communication on a prevalent sensor node platform. The measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] as the Radio Duty Cycling algorithm. From this and many other measurement reports (e.g., [AN079]), we can see that the energy consumption of optimized transmission and reception are in the same order. For IEEE 802.15.4 [IEEE802.15.4] and Ultra WideBand (UWB) links, transmitting may actually be even cheaper than receiving. It also shows that broadcast and non-synchronized communication transmissions are energy costly because they need to acquire the medium for a long time.
ワイヤレス通信プラットフォーム[Powertrace]の包括的な測定値を報告する多数の発表済みの研究があります。例として、一般的なセンサーノードプラットフォームでの通信に関連する最も一般的な操作のエネルギー消費プロファイルを以下に示します。測定は、無線デューティサイクリングアルゴリズムとしてContikiMAC [ContikiMAC]を使用したTmote Skyに基づいています。これと他の多くの測定レポート（[AN079]など）から、最適化された送信と受信のエネルギー消費が同じ順序であることがわかります。 IEEE 802.15.4 [IEEE802.15.4]およびUltra WideBand（UWB）リンクの場合、実際には送信よりも受信の方が安くなる場合があります。また、ブロードキャストおよび非同期通信の送信は、媒体を長期間取得する必要があるため、エネルギーコストがかかることも示しています。
+---------------------------------------+---------------+
| Activity | Energy |
| | (microjoules) |
+---------------------------------------+---------------+
| Broadcast reception | 178 |
+---------------------------------------+---------------+
| Unicast reception | 222 |
+---------------------------------------+---------------+
| Broadcast transmission | 1790 |
+---------------------------------------+---------------+
| Non-synchronized unicast transmission | 1090 |
+---------------------------------------+---------------+
| Synchronized unicast transmission | 120 |
+---------------------------------------+---------------+
| Unicast TX to awake receiver | 96 |
+---------------------------------------+---------------+
| Listening (for 1000 ms) | 63000 |
+---------------------------------------+---------------+
Figure 2: Power Consumption of Common Operations Involved in Communication on the Tmote Sky with ContikiMAC
図2：ContikiMACを使用したTmote Skyでの通信に関連する一般的な操作の消費電力
At the Physical layer, one approach that may reduce the energy consumption of a device that uses a wireless interface is based on reducing the device transmit power level, as long as the intended next hop(s) is still within range of the device. In some cases, if node A has to transmit a message to node B, a solution to reduce node A transmit power is to leverage an intermediate device, e.g., node C as a message forwarder. Let d be the distance between node A and node B. Assuming free-space propagation, where path loss is proportional to d^2, if node C is placed right in the middle of the path between A and B (that is, at a distance d/2 from both node A and node B), the minimum transmit power to be used by node A (and by node C) is reduced by a factor of 4. However, this solution requires additional devices, it requires a routing solution, and it also increases transmission delay between A and B.
物理層で、ワイヤレスインターフェイスを使用するデバイスのエネルギー消費を削減できるアプローチの1つは、目的のネクストホップがデバイスの範囲内にある限り、デバイスの送信電力レベルを削減することです。場合によっては、ノードAがメッセージをノードBに送信する必要がある場合、ノードAの送信電力を削減する解決策は、メッセージフォワーダとしてノードCなどの中間デバイスを活用することです。ノードAとノードBの間の距離をdとします。ノードCがAとBの間のパスの真ん中に（つまり、aで）配置されている場合、パス損失がd ^ 2に比例する自由空間伝搬を仮定します。ノードAとノードBの両方から距離d / 2）、ノードA（およびノードC）が使用する最小送信電力は4分の1に削減されます。ただし、このソリューションには追加のデバイスが必要であり、ルーティングソリューションが必要です、AとB間の伝送遅延も増加します。
In networks, communication and power consumption are interdependent. The communication device is typically the most power-consuming component, but merely refraining from transmissions is not enough to achieve a low power consumption: the radio may consume as much power in listen mode as when actively transmitting. This illustrates the key problem known as idle listening, whereby the radio of a device may be in receive mode (ready to receive any message), even if no message is being transmitted to that device. Idle listening can consume a huge amount of energy unnecessarily. To reduce power consumption, the radio must be switched completely off -- duty-cycled -- as much as possible. By applying duty cycling, the lifetime of a device operating on a common button battery may be on the order of years, whereas otherwise the battery may be exhausted in a few days or even hours. Duty cycling is a technique generally employed by devices that use the P1 strategy [RFC7228], which need to be able to communicate on a relatively frequent basis. Note that a more aggressive approach to save energy relies on the P0 (Normally-off) strategy, whereby devices sleep for very long periods and communicate infrequently, even though they spend energy in network reattachment procedures.
ネットワークでは、通信と電力消費は相互に依存しています。通信デバイスは通常、最も電力を消費するコンポーネントですが、送信を控えるだけでは低電力消費を達成するのに十分ではありません。ラジオは、アクティブに送信するときと同じくらい多くの電力をリッスンモードで消費する場合があります。これは、アイドルリスニングと呼ばれる重要な問題を示しています。これにより、デバイスにメッセージが送信されていなくても、デバイスの無線が受信モード（メッセージを受信する準備ができている）になる場合があります。アイドルリスニングは、不必要に大量のエネルギーを消費する可能性があります。電力消費量を減らすには、無線機を可能な限り完全にオフに切り替え、デューティサイクルをかけなければなりません。デューティサイクルを適用すると、一般的なボタンバッテリーで動作するデバイスの寿命は数年になる可能性がありますが、それ以外の場合、バッテリーは数日または数時間で消耗します。デューティサイクルは、P1戦略[RFC7228]を使用するデバイスで一般的に採用されている手法であり、比較的頻繁に通信できる必要があります。エネルギーを節約するためのより積極的なアプローチはP0（ノーマリーオフ）戦略に依存することに注意してください。これにより、デバイスは非常に長い間スリープし、ネットワークの再接続手順にエネルギーを費やしても、通信の頻度が低くなります。
From the perspective of Medium Access Control (MAC) and Radio Duty Cycling (RDC), all upper-layer protocols, such as routing, RESTful communication, adaptation, and management flows, are applications. Since the duty-cycling algorithm is the key to energy efficiency of the wireless medium, it synchronizes transmission and/or reception requests from the higher layers.
メディアアクセスコントロール（MAC）と無線デューティサイクリング（RDC）の観点から見ると、ルーティング、RESTful通信、適応、管理フローなど、すべての上位層プロトコルがアプリケーションです。デューティサイクルアルゴリズムは、ワイヤレスメディアのエネルギー効率の鍵となるため、上位層からの送信および/または受信要求を同期させます。
MAC and RDC are not in the scope of the IETF, yet lower-layer designers and chipset manufacturers take great care to save energy. By knowing the behaviors of these lower layers, engineers can design protocols that work well with them. The IETF protocols to be discussed in the following sections are the customers of the lower layers.
MACとRDCはIETFの範囲外ですが、下位層の設計者とチップセットメーカーは、エネルギーを節約するために細心の注意を払っています。これらの下位層の動作を知ることにより、エンジニアはそれらとうまく機能するプロトコルを設計できます。以下のセクションで説明するIETFプロトコルは、下位層の顧客です。
This subsection describes three main RDC techniques. Note that more than one of these techniques may be available or can even be combined in a specific radio technology:
このサブセクションでは、3つの主要なRDC手法について説明します。これらの技術は複数利用できる場合や、特定の無線技術に組み合わせることもできることに注意してください。
a) Channel sampling: In this solution, the radio interface of a device periodically monitors the channel for very short time intervals (i.e., with a low duty cycle) with the aim of detecting incoming transmissions. In order to make sure that a receiver can correctly receive a transmitted data unit, the sender may prepend a preamble of a duration at least the sampling period to the data unit to be sent. Another option for the sender is to repeatedly transmit the data unit instead of sending a preamble before the data unit. Once a transmission is detected by a receiver, the receiver may stay awake until the complete reception of the data unit. Examples of radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e [IEEE802.15.4], and the Frequently Listening (FL) mode of ITU-T G.9959 [G9959].
a）チャネルサンプリング：このソリューションでは、デバイスの無線インターフェイスが非常に短い時間間隔（つまり、デューティサイクルが低い）でチャネルを定期的に監視し、着信送信を検出します。受信機が送信されたデータユニットを正しく受信できることを確認するために、送信機は、送信されるデータユニットに少なくともサンプリング期間の持続時間のプリアンブルを付加することができる。送信側の別のオプションは、データユニットの前にプリアンブルを送信する代わりに、データユニットを繰り返し送信することです。送信が受信機によって検出されると、受信機は、データユニットの完全な受信まで目を覚まし続けることができます。プリアンブルサンプリングを使用する無線テクノロジーの例には、ContikiMAC、IEEE 802.15.4eのCoordinated Sampled Listening（CSL）モード[IEEE802.15.4]、およびITU-T G.9959 [G9959]のFrequently Listening（FL）モードが含まれます。
b) Scheduled transmissions: This approach allows a device to know the particular time at which it should be awake (during some time interval) in order to receive data. Otherwise, the device may remain in sleep mode. The decision on the times at which communication is attempted relies on some form of negotiation between the involved devices. Such negotiation may be performed per transmission or per session/connection. Bluetooth Low Energy (Bluetooth LE) is an example of a radio technology based on this mechanism.
b) スケジュールされた送信：このアプローチにより、デバイスは、データを受信するために（一定の時間間隔で）起動する必要がある特定の時間を知ることができます。そうしないと、デバイスがスリープモードのままになることがあります。通信が試行される時間に関する決定は、関係するデバイス間の何らかの形のネゴシエーションに依存します。そのような交渉は、送信ごとに、またはセッション/接続ごとに実行されます。 Bluetooth Low Energy（Bluetooth LE）は、このメカニズムに基づく無線技術の例です。
c) Listen after send: This technique allows a node to remain in sleep mode by default, then wake up and poll a sender (which must be ready to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode and is ready for a potential incoming transmission. After a certain time interval, the node may go back to sleep. For example, this technique is used in the Receiver Initiated Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4] and in the transmission of data between a coordinator and a device in the 2003 version of IEEE 802.15.4 [IEEE802.15.4].
c) 送信後にリッスンする：この手法では、ノードがデフォルトでスリープモードに留まり、ウェイクアップして送信者（ポーリングメッセージを受信する準備ができている必要があります）をポーリングして、保留中の送信を探します。ポーリングメッセージを送信した後、ノードは受信モードのままで、潜在的な着信送信の準備ができています。特定の時間間隔の後、ノードはスリープ状態に戻る場合があります。たとえば、この手法は、IEEE 802.15.4e [IEEE802.15.4]のReceiver Initiated Transmission（RIT）モード、および2003バージョンのIEEE 802.15.4 [IEEE802。 15.4]。
The latency of a data unit transmission to a duty-cycled device is equal to or greater than the latency of transmitting to an always-on device. Therefore, duty cycling leads to a trade-off between energy consumption and latency. Note that in addition to a latency increase, RDC may introduce latency variance since the latency increase is a random variable (which is uniformly distributed if duty cycling follows a periodic behavior).
デューティサイクルデバイスへのデータユニット送信のレイテンシは、常時接続デバイスへの送信のレイテンシ以上です。したがって、デューティサイクルは、エネルギー消費と遅延の間のトレードオフにつながります。レイテンシの増加はランダムな変数であるため、RDCはレイテンシの増加に加えて、レイテンシの変化をもたらす可能性があることに注意してください（デューティサイクルが定期的な動作に従う場合、これは均一に分散されます）。
On the other hand, due to the latency increase introduced by duty cycling, a sender waiting for a transmission opportunity may need to store subsequent outgoing packets in a buffer. This buffering would increase memory requirements and potentially incur queuing wait times. Such wait times would in turn contribute to packet transmission delay and increase the probability of buffer overflow, leading to losses.
一方、デューティサイクルによって発生するレイテンシの増加により、送信機会を待っている送信者は、後続の発信パケットをバッファに格納する必要がある場合があります。このバッファリングにより、メモリ要件が増加し、キューの待機時間が発生する可能性があります。そのような待機時間は、パケット送信遅延の原因となり、バッファオーバーフローの可能性を高め、損失につながります。
Although throughput is not typically a key concern in constrained-node network applications, it is indeed important in some services in such networks, such as over-the-air software updates or when off-line sensors accumulate measurements that have to be quickly transferred when there is an opportunity for connectivity.
スループットは通常、制約付きノードのネットワークアプリケーションでは重要な問題ではありませんが、無線ソフトウェアの更新やオフラインセンサーが測定値を蓄積する場合など、そのようなネットワークの一部のサービスでは実際に重要です。接続の機会があります。
Since RDC introduces inactive intervals in energy-constrained devices, it reduces the throughput that can be achieved when communicating with such devices. There exists a trade-off between the achievable throughput and energy consumption.
RDCはエネルギーに制約のあるデバイスに非アクティブな間隔を導入するため、そのようなデバイスと通信するときに達成できるスループットが低下します。達成可能なスループットとエネルギー消費の間にはトレードオフがあります。
The parameters controlling the radio duty cycle have to be carefully tuned to achieve the intended application and/or network requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection provides details on key parameters controlling RDC mechanisms, and thus fundamental trade-offs, for various examples of relevant low-power radio technologies.
無線のデューティサイクルを制御するパラメータは、意図したアプリケーションやネットワーク要件を実現するために注意深く調整する必要があります。一方、上位層では、RDCに起因する予想される待ち時間やスループットの動作を考慮する必要があります。次のサブセクションでは、関連する低電力無線技術のさまざまな例について、RDCメカニズムを制御する主要なパラメーターの詳細、つまり基本的なトレードオフについて説明します。
Another technique that may be useful to increase communication energy efficiency is packet bundling. This technique, which is available in several radio interfaces (e.g., LTE and some 802.11 variants), allows for aggregation of several small packets into a single large packet. Header and communication overhead is therefore reduced.
通信のエネルギー効率を高めるために役立つ可能性のあるもう1つの手法は、パケットバンドリングです。この手法は、いくつかの無線インターフェース（LTEや一部の802.11バリアントなど）で利用でき、いくつかの小さなパケットを1つの大きなパケットに集約することができます。したがって、ヘッダーと通信のオーバーヘッドが削減されます。
This subsection presents power save services and techniques used in a few relevant examples of wireless low-power radios: IEEE 802.11 [IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4]. For a more detailed overview of each technology, the reader may refer to the literature or to the corresponding specifications.
このサブセクションでは、IEEE 802.11 [IEEE802.11]、Bluetooth LE、IEEE 802.15.4 [IEEE802.15.4]など、ワイヤレス低電力無線のいくつかの関連する例で使用されている省電力サービスと手法について説明します。各テクノロジーのより詳細な概要については、読者が文献または対応する仕様を参照する場合があります。
IEEE 802.11 [IEEE802.11] defines the Power Save Mode (PSM) whereby a station may indicate to an Access Point (AP) that it will enter a sleep mode state. While the station is sleeping, the AP buffers any frames that should be sent to the sleeping station. The station wakes up every listen interval (which can be a multiple of the beacon interval) in order to receive beacons. The AP signals, by means of a beacon field, whether there is data pending for the station or not.
IEEE 802.11 [IEEE802.11]は、省電力モード（PSM）を定義しています。これにより、ステーションはアクセスポイント（AP）にスリープモード状態になることを示すことができます。ステーションがスリープしている間、APはスリープステーションに送信する必要のあるフレームをすべてバッファリングします。ステーションは、ビーコンを受信するために、すべてのリッスン間隔（ビーコン間隔の倍数にすることができます）でウェイクアップします。 APは、ビーコンフィールドを使用して、ステーションに保留中のデータがあるかどうかを通知します。
If there are not frames to be sent to the station, the latter may get back to sleep mode. Otherwise, the station may send a message requesting the transmission of the buffered data and stay awake in receive mode.
ステーションに送信するフレームがない場合、ステーションはスリープモードに戻ることがあります。そうでない場合、ステーションは、バッファリングされたデータの送信を要求するメッセージを送信し、受信モードで起動したままになります。
IEEE 802.11v [IEEE802.11] further defines mechanisms and services for power save of stations/nodes that include Flexible Multicast Service (FMS), Proxy ARP advertisement, extended sleep modes, and traffic filtering. Upper-layer protocol's knowledge of such capabilities, provided by the lower layer, enables better interworking.
IEEE 802.11v [IEEE802.11]は、フレキシブルマルチキャストサービス（FMS）、プロキシARPアドバタイズ、拡張スリープモード、およびトラフィックフィルタリングを含む、ステーション/ノードの省電力のためのメカニズムとサービスをさらに定義します。下位層によって提供されるそのような機能に関する上位層プロトコルの知識は、より良いインターワーキングを可能にします。
These services include:
これらのサービスは次のとおりです。
Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to indicate that the non-AP station (STA) will not receive ARP frames. The Proxy ARP capability enables the non-AP STA to remain in power save mode for longer periods of time.
プロキシARP：プロキシARP機能により、アクセスポイント（AP）は、非APステーション（STA）がARPフレームを受信しないことを示すことができます。プロキシARP機能により、非AP STAがより長い時間省電力モードを維持できるようになります。
Basic Service Set (BSS) Max Idle Period Management: Enables an AP to indicate a time period during which the AP does not disassociate a STA due to non-receipt of frames from the STA. This supports improved STA power saving and AP resource management.
基本サービスセット（BSS）最大アイドル期間管理：APが、STAからのフレームを受信しないためにAPがSTAの関連付けを解除しない期間を示すことができるようにします。これにより、STAの省電力とAPリソース管理の改善がサポートされます。
FMS: A service in which a non-AP STA can request a multicast delivery interval longer than the Delivery Traffic Indication Message (DTIM) interval for the purposes of lengthening the period of time a STA may be in a power save state.
FMS：非AP STAが、STAが省電力状態である期間を長くする目的で、配信トラフィック表示メッセージ（DTIM）間隔よりも長いマルチキャスト配信間隔を要求できるサービス。
Traffic Filtering Service (TFS): A service provided by an AP to a non-AP STA that can reduce the number of frames sent to the STA by dropping individually addressed frames that do not match traffic filters specified by the STA.
トラフィックフィルタリングサービス（TFS）：APによって非AP STAに提供されるサービス。STAによって指定されたトラフィックフィルターと一致しないアドレス指定されたフレームを個別にドロップすることにより、STAに送信されるフレームの数を減らすことができます。
Using the above services provided by the lower layer, the constrained nodes can achieve either client-initiated power save (via TFS) or network-assisted power save (Proxy ARP, BSS Max Idle Period, and FMS).
下位層によって提供される上記のサービスを使用して、制約付きノードは、クライアントが開始する省電力（TFS経由）またはネットワークが支援する省電力（プロキシARP、BSS最大アイドル期間、およびFMS）を実現できます。
Upper-layer protocols should synchronize with the parameters such as FMS interval and BSS MAX Idle Period so that the wireless transmissions are not triggered periodically.
上位層プロトコルは、無線送信が定期的にトリガーされないように、FMS間隔やBSS MAX Idle Periodなどのパラメーターと同期する必要があります。
Bluetooth LE is a wireless low-power communications technology that is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 specifications [Bluetooth42]. BTLE has been designed for the goal of ultra-low power consumption. IPv6 can be run IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to BTLE [RFC7668].
Bluetooth LEは、Bluetooth 4.0、4.1、4.2仕様[Bluetooth42]の特徴的なコンポーネントであるワイヤレス低電力通信技術です。 BTLEは、超低消費電力を目標に設計されています。 IPv6は、BTLE [RFC7668]に適合した6LoWPANバリアントを使用して、Bluetooth LEネットワーク上でIPv6を実行できます。
Bluetooth LE networks comprise a master and one or more slaves, which are connected to the master. The Bluetooth LE master is assumed to be a relatively powerful device, whereas a slave is typically a constrained device (e.g., a Class 1 device).
Bluetooth LEネットワークは、マスターと、マスターに接続された1つ以上のスレーブで構成されます。 Bluetooth LEマスターは比較的強力なデバイスであると想定されていますが、スレーブは通常、制約されたデバイス（クラス1デバイスなど）です。
Medium access in Bluetooth LE is based on a Time-Division Multiple Access (TDMA) scheme that is coordinated by the master. This device determines the start of connection events in which communication between the master and a slave takes place. At the beginning of a connection event, the master sends a poll message, which may encapsulate data, to the slave. The latter must send a response, which may also contain data. The master and the slave may continue exchanging data until the end of the connection event. The next opportunity for communication between the master and the slave will be in the next connection event scheduled for the slave.
Bluetooth LEのミディアムアクセスは、マスターによって調整される時分割多重アクセス（TDMA）スキームに基づいています。このデバイスは、マスターとスレーブ間の通信が行われる接続イベントの開始を決定します。接続イベントの開始時に、マスターはデータをカプセル化する可能性のあるポーリングメッセージをスレーブに送信します。後者は応答を送信する必要があり、これにはデータも含まれる場合があります。マスターとスレーブは、接続イベントが終了するまでデータの交換を続けることができます。マスターとスレーブ間の通信の次の機会は、スレーブにスケジュールされた次の接続イベントになります。
The time between consecutive connection events is defined by the connInterval parameter, which may range between 7.5 ms and 4 s. The slave may remain in sleep mode from the end of its last connection event until the beginning of its next connection event. Therefore, Bluetooth LE is duty-cycled by design. Furthermore, after having replied to the master, a slave is not required to listen to the master (and thus may keep the radio in sleep mode) for connSlaveLatency consecutive connection events. connSlaveLatency is an integer parameter between 0 and 499 that should not cause link inactivity for more than connSupervisionTimeout time. The connSupervisionTimeout parameter is in the range between 100 ms and 32 s.
連続する接続イベント間の時間は、connIntervalパラメータによって定義されます。このパラメータの範囲は7.5ミリ秒から4秒です。スレーブは、最後の接続イベントの終わりから次の接続イベントの始まりまで、スリープモードのままになる場合があります。したがって、Bluetooth LEは設計によりデューティサイクルされます。さらに、マスターに応答した後、スレーブはconnSlaveLatencyの連続した接続イベントについてマスターをリッスンする必要がありません（したがって、無線をスリープモードに保つことができます）。 connSlaveLatencyは、0〜499の整数パラメーターで、connSupervisionTimeout時間を超えてもリンクが非アクティブになることはありません。 connSupervisionTimeoutパラメーターの範囲は100ミリ秒から32秒です。
Upper-layer protocols should take into account the medium access and duty-cycling behavior of Bluetooth LE. In particular, connInterval, connSlaveLatency, and connSupervisionTimeout determine the time between two consecutive connection events for a given slave. The upper-layer packet generation pattern and rate should be consistent with the settings of the aforementioned parameters (and vice versa). For example, assume connInterval = 4 seconds, connSlaveLatency = 7 seconds, and connSupervisionTimeout = 32 seconds. With these settings, communication opportunities between a master and a slave will occur during a given interval every 32 seconds. Duration of the interval will depend on several factors, including number of connected slaves, amount of data to be transmitted, etc. In the worst case, only one data unit can be sent from master to slave (and vice versa) every 32 seconds.
上位層プロトコルは、Bluetooth LEのメディアアクセスとデューティサイクル動作を考慮する必要があります。特に、connInterval、connSlaveLatency、およびconnSupervisionTimeoutは、特定のスレーブの2つの連続した接続イベント間の時間を決定します。上位層のパケット生成パターンとレートは、前述のパラメータの設定と一致している必要があります（逆も同様）。たとえば、connInterval = 4秒、connSlaveLatency = 7秒、connSupervisionTimeout = 32秒と仮定します。これらの設定により、マスターとスレーブ間の通信機会は、32秒ごとの一定の間隔で発生します。間隔の長さは、接続されているスレーブの数、送信されるデータの量など、いくつかの要因に依存します。最悪の場合、32秒ごとにマスターからスレーブに（およびその逆に）送信できるデータユニットは1つだけです。
IEEE 802.15.4 [IEEE802.15.4] is a family of standard radio interfaces for low-rate, low-power wireless networking. Since the publication of its first version in 2003, IEEE 802.15.4 [IEEE802.15.4] has become the de facto choice for a wide range of constrained-node network application domains and has been a primary target technology of various IETF working groups such as 6LoWPAN [RFC6282] [RFC6775] [RFC4944] and 6TiSCH [ARCH-6TiSCH]. IEEE 802.15.4 [IEEE802.15.4] specifies a variety of related Physical layer (PHY) and MAC layer functionalities.
IEEE 802.15.4 [IEEE802.15.4]は、低レート、低電力のワイヤレスネットワーキング用の標準無線インターフェースのファミリーです。 2003年に最初のバージョンが公開されて以来、IEEE 802.15.4 [IEEE802.15.4]は、さまざまな制約ノードネットワークアプリケーションドメインの事実上の選択になり、以下のようなさまざまなIETFワーキンググループの主要なターゲットテクノロジーとなっています。 6LoWPAN [RFC6282] [RFC6775] [RFC4944]および6TiSCH [ARCH-6TiSCH]。 IEEE 802.15.4 [IEEE802.15.4]は、関連するさまざまな物理層（PHY）およびMAC層の機能を規定しています。
IEEE 802.15.4 [IEEE802.15.4] defines three roles called device, coordinator, and Personal Area Network (PAN) coordinator. The device role is adequate for nodes that do not implement the complete IEEE 802.15.4 [IEEE802.15.4] functionality and is mainly targeted for constrained nodes with a limited energy source. The coordinator role includes synchronization capabilities and is suitable for nodes that do not suffer severe constraints (e.g., a mains-powered node). The PAN coordinator is a special type of coordinator that acts as a principal controller in an IEEE 802.15.4 [IEEE802.15.4] network.
IEEE 802.15.4 [IEEE802.15.4]は、デバイス、コーディネーター、およびパーソナルエリアネットワーク（PAN）コーディネーターと呼ばれる3つの役割を定義します。デバイスの役割は、完全なIEEE 802.15.4 [IEEE802.15.4]機能を実装していないノードに適し、主にエネルギー源が限られている制約されたノードを対象としています。コーディネーターの役割には同期機能が含まれており、深刻な制約を受けないノード（例えば、商用電源のノード）に適しています。 PANコーディネーターは、IEEE 802.15.4 [IEEE802.15.4]ネットワークで主要なコントローラーとして機能する特別なタイプのコーディネーターです。
IEEE 802.15.4 [IEEE802.15.4] defines two main types of networks depending on their configuration: beacon-enabled and non-beacon-enabled networks. In the first network type, coordinators periodically transmit beacons. The time between beacons is divided in three main parts: the Contention Access Period (CAP), the Contention Free Period (CFP), and an inactive period. In the first period, nodes use slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for data communication. In the second one, a TDMA scheme controls medium access. During the idle period, communication does not take place, and thus the inactive period is a good opportunity for nodes to turn the radio off and save energy. The coordinator announces in each beacon the list of nodes for which data will be sent in the subsequent period. Therefore, devices may remain in sleep mode by default and wake up periodically to listen to the beacons sent by their coordinator. If a device wants to transmit data, or learns from a beacon that it is an intended destination, then it will exchange messages with the coordinator (and thus consume energy). An underlying assumption is that when a message is sent to a coordinator, the radio of the coordinator will be ready to receive the message.
IEEE 802.15.4 [IEEE802.15.4]は、構成に応じて2つの主要なタイプのネットワークを定義します。ビーコン対応ネットワークと非ビーコン対応ネットワークです。最初のネットワークタイプでは、コーディネーターが定期的にビーコンを送信します。ビーコン間の時間は、3つの主要な部分に分けられます：競合アクセス期間（CAP）、競合フリー期間（CFP）、および非アクティブ期間。最初の期間では、ノードはデータ通信に衝突回避を備えたスロット付きキャリアセンス多重アクセス（CSMA / CA）を使用します。 2つ目は、TDMAスキームがメディアアクセスを制御します。アイドル期間中は通信が行われないため、非アクティブ期間はノードが無線をオフにしてエネルギーを節約する良い機会です。コーディネーターは、後続の期間にデータが送信されるノードのリストを各ビーコンで通知します。したがって、デバイスはデフォルトではスリープモードのままで、コーディネーターによって送信されたビーコンをリッスンするために定期的にウェイクアップする場合があります。デバイスがデータを送信したい場合、またはビーコンから目的の宛先であることを学習した場合、コーディネーターとメッセージを交換します（したがってエネルギーを消費します）。基本的な前提は、メッセージがコーディネーターに送信されると、コーディネーターの無線がメッセージを受信する準備ができることです。
The beacon interval and the duration of the active portion of the beacon interval (i.e., the CAP and the CFP), and thus the duty cycle, can be configured. The parameters that control these times are called macBeaconOrder and macSuperframeOrder, respectively. As an example, when IEEE 802.15.4 [IEEE802.15.4] operates in the 2.4 GHz PHY, both times can be (independently) set to values in the range between 15.36 ms and 251.6 s.
ビーコン間隔と、ビーコン間隔のアクティブな部分（つまり、CAPとCFP）の持続時間、したがってデューティサイクルを構成できます。これらの時間を制御するパラメーターは、それぞれmacBeaconOrderおよびmacSuperframeOrderと呼ばれます。例として、IEEE 802.15.4 [IEEE802.15.4]が2.4 GHz PHYで動作する場合、両方の時間を（独立して）15.36 msから251.6 sの範囲の値に設定できます。
In the beaconless mode, nodes use unslotted CSMA/CA for data transmission. The device may be in sleep mode by default and may activate its radio to either i) request to the coordinator whether there is pending data for the device, or to ii) transmit data to the coordinator. The wake-up pattern of the device, if any, is out of the scope of IEEE 802.15.4 [IEEE802.15.4].
ビーコンレスモードでは、ノードはデータ送信にスロットなしのCSMA / CAを使用します。デバイスはデフォルトでスリープモードになっている可能性があり、その無線をアクティブにして、i）デバイスの保留データがあるかどうかをコーディネーターに要求するか、ii）コーディネーターにデータを送信します。デバイスのウェイクアップパターンは、存在する場合、IEEE 802.15.4 [IEEE802.15.4]の範囲外です。
Communication between the two ends of an IEEE 802.15.4 [IEEE802.15.4] link may also take place in a peer-to-peer configuration, whereby both link ends assume the same role. In this case, data transmission can happen at any moment. Nodes must have their radio in receive mode and be ready to listen to the medium by default (which for battery-enabled nodes may lead to a quick battery depletion) or apply synchronization techniques. The latter are out of the scope of IEEE 802.15.4 [IEEE802.15.4].
IEEE 802.15.4 [IEEE802.15.4]リンクの両端間の通信は、ピアツーピア構成でも行われる場合があり、両方のリンク端が同じ役割を引き受けます。この場合、データ転送はいつでも発生する可能性があります。ノードは無線を受信モードにして、デフォルトでメディアを聞く準備ができている必要があります（バッテリーが有効なノードの場合、バッテリーがすぐに消耗する可能性があります）、または同期技術を適用します。後者は、IEEE 802.15.4 [IEEE802.15.4]の範囲外です。
The main MAC layer IEEE 802.15.4 [IEEE802.15.4] amendment to date is IEEE 802.15.4e. This amendment includes various new MAC layer modes, some of which include mechanisms for low energy consumption. Among these, the Time-Slotted Channel Hopping (TSCH) is an outstanding mode that offers robust features for industrial environments, among others. In order to provide the functionality needed to enable IPv6 over TSCH, the 6TiSCH Working Group was created. TSCH is based on a TDMA schedule whereby a set of timeslots are used for frame transmission and reception, and other timeslots are unscheduled. The latter timeslots may be used by a dynamic scheduling mechanism, otherwise, nodes may keep the radio off during the unscheduled timeslots, thus saving energy. The minimal schedule configuration specified in [RFC8180] comprises 101 timeslots; 95 of these timeslots are unscheduled and the timeslot duration is 15 ms.
これまでの主要なMAC層IEEE 802.15.4 [IEEE802.15.4]の改正は、IEEE 802.15.4eです。この修正には、さまざまな新しいMACレイヤーモードが含まれており、その一部には低エネルギー消費のメカニズムが含まれています。これらの中でも、タイムスロットチャネルホッピング（TSCH）は、とりわけ産業環境向けの堅牢な機能を提供する優れたモードです。 TSCHでIPv6を有効にするために必要な機能を提供するために、6TiSCHワーキンググループが作成されました。 TSCHはTDMAスケジュールに基づいており、フレームの送受信に一連のタイムスロットが使用され、他のタイムスロットはスケジュールされません。後者のタイムスロットは、動的スケジューリングメカニズムによって使用される場合があります。そうでない場合、ノードは、スケジュールされていないタイムスロットの間、無線をオフに保ち、エネルギーを節約します。 [RFC8180]で指定されている最小スケジュール構成は101タイムスロットで構成されています。これらのタイムスロットのうち95はスケジュールされておらず、タイムスロット期間は15ミリ秒です。
The previously mentioned CSL and RIT are also 802.15.4e modes designed for low energy.
前述のCSLおよびRITは、低エネルギー用に設計された802.15.4eモードでもあります。
DECT Ultra Low Energy (DECT ULE) is a wireless technology building on the key fundamentals of traditional DECT / Cordless Advanced Technology - internet and quality (CAT-iq) [EN300] but with specific changes to significantly reduce the power consumption at the expense of data throughput [TS102]. DECT ULE devices typically operate on special power-optimized silicon but can connect to a DECT Gateway supporting traditional DECT/CAT-iq for cordless telephony and data as well as the DECT ULE extensions. IPv6 can be run over DECT ULE by using a 6LoWPAN variant [RFC8105].
DECT超低エネルギー（DECT ULE）は、従来のDECT /コードレスアドバンストテクノロジー-インターネットと品質（CAT-iq）[EN300]の主要な基本要素をベースにしたワイヤレステクノロジーですが、特定の変更により、消費電力を大幅に削減します。データスループット[TS102]。 DECT ULEデバイスは通常、電力が最適化された特別なシリコンで動作しますが、コードレステレフォニーとデータ、およびDECT ULE拡張用の従来のDECT / CAT-iqをサポートするDECTゲートウェイに接続できます。 IPv6は、6LoWPANバリアント[RFC8105]を使用してDECT ULEで実行できます。
DECT defines two major roles: the Portable Part (PP) is the power constrained device while the Fixed Part (FP) is the Gateway or base station in a star topology. Because TDMA/FDMA and Time-Division Duplex (TDD) using dynamic channel allocation for interference, DECT operates in license-free and reserved frequency bands. It provides good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length of 10 ms divided into 24 timeslots, and it supports connection-oriented packet data and connection-less services.
DECTは2つの主要な役割を定義します。ポータブルパーツ（PP）は電力に制約のあるデバイスであり、固定パーツ（FP）はスター型トポロジーのゲートウェイまたはベースステーションです。 TDMA / FDMAおよび時分割複信（TDD）は干渉に動的チャネル割り当てを使用するため、DECTはライセンス不要の予約済み周波数帯域で動作します。屋内（約50 m）および屋外（約300 m）のカバレッジを提供します。 24タイムスロットに分割された10 msのフレーム長を使用し、コネクション型のパケットデータとコネクションレスサービスをサポートします。
The FP usually transmits a so-called dummy bearer (beacon) that is used to broadcast synchronization, system, and paging information. The slot/carrier position of this dummy bearer can automatically be reallocated in order to avoid mutual interference with other DECT signals.
FPは通常、同期、システム、およびページング情報をブロードキャストするために使用される、いわゆるダミーベアラー（ビーコン）を送信します。このダミーベアラのスロット/キャリア位置は、他のDECT信号との相互干渉を回避するために自動的に再割り当てできます。
At the MAC level, DECT ULE communications between FP and PP are initiated by the PP. An FP can initiate communication indirectly by sending a paging signal to a PP. The PP determines the timeslot and frequency in which the communication between FP and PP takes place. The PP verifies the radio timeslot/frequency position is unoccupied before it initiates its transmitter. An access-request message, which usually carries data, is sent to the FP. The FP sends a confirm message, which also may carry data. More data can be sent in subsequent frames. A MAC-level automatic retransmission scheme significantly improves the reliability of data transfer. A segmentation and reassembly scheme supports transfer of larger, higher-layer Service Data Units (SDUs) and provides data integrity checks. The DECT ULE packet data service ensures data integrity, proper sequencing, and duplicate protection but not guaranteed delivery. Higher-layer protocols have to take this into consideration.
MACレベルでは、FPとPP間のDECT ULE通信はPPによって開始されます。 FPは、PPにページング信号を送信することにより、間接的に通信を開始できます。 PPは、FPとPPの間の通信が行われるタイムスロットと頻度を決定します。 PPは、送信機を開始する前に、無線タイムスロット/周波数位置が空いていることを確認します。通常はデータを運ぶアクセス要求メッセージがFPに送信されます。 FPは確認メッセージを送信します。これにはデータも含まれる場合があります。後続のフレームでより多くのデータを送信できます。 MACレベルの自動再送信スキームにより、データ転送の信頼性が大幅に向上します。セグメンテーションおよび再構成スキームは、より大規模で上位層のサービスデータユニット（SDU）の転送をサポートし、データの整合性チェックを提供します。 DECT ULEパケットデータサービスは、データの整合性、適切な順序付け、重複保護を保証しますが、配信は保証されません。上位層プロトコルでは、これを考慮に入れる必要があります。
The FP may send paging information to PPs to trigger connection setup and indicate the required service type. The interval between paging information to a specific PP can be defined in the range of 10 ms to 327 s. The PP may enter sleep mode to save power. The listening interval is defined by the PP application. For short sleep intervals (below ~10 seconds), the PP may be able to retain synchronization to the FP dummy bearer and only turn on the receiver during the expected timeslot. For longer sleep intervals, the PP can't keep synchronization and has to search for, and resynchronize to, the FP dummy bearer. Hence, longer sleep intervals reduce the average energy consumption but add an energy consumption penalty for acquiring synchronization to the FP dummy bearer. The PP can obtain all information to determine paging and acquire synchronization information in a single reception of one full timeslot.
FPはページング情報をPPに送信して、接続セットアップをトリガーし、必要なサービスタイプを示します。特定のPPへのページング情報の間隔は、10ミリ秒から327秒の範囲で定義できます。 PPは、節電のためにスリープモードに入る場合があります。リスニング間隔は、PPアプリケーションによって定義されます。短いスリープ間隔（約10秒未満）の場合、PPはFPダミーベアラへの同期を維持でき、予想されるタイムスロット中にのみ受信機をオンにすることができます。より長いスリープ間隔の場合、PPは同期を維持できず、FPダミーベアラーを検索して再同期する必要があります。したがって、スリープ間隔を長くすると、平均エネルギー消費量は減少しますが、FPダミーベアラへの同期を取得するためのエネルギー消費量のペナルティが追加されます。 PPは、すべての情報を取得してページングを決定し、1つの完全なタイムスロットの1回の受信で同期情報を取得できます。
Packet data latency is normally 30 ms for short packets (below or equal to 32 octets), however, if retry and back-off scenarios occur, the latency is increased. The latency can actually be reduced to about 10 ms by doing energy consuming Received Signal Strength Indication (RSSI) scanning in advance. In the direction from FP to PP, the latency is usually increased by the used paging interval and the sleep interval. The MAC layer can piggyback commands to improve efficiency (reduce latency) of higher-layer protocols. Such commands can instruct the PP to initiate a new packet transfer in N frames without the need for resynchronization and can listen to paging or instruct the PP to stay in a higher duty-cycle paging detection mode.
パケットデータのレイテンシは、短いパケット（32オクテット以下）の場合、通常30ミリ秒ですが、再試行とバックオフのシナリオが発生すると、レイテンシが増加します。待機時間は、エネルギーを消費する受信信号強度表示（RSSI）を事前にスキャンすることで、実際には約10ミリ秒に短縮できます。 FPからPPへの方向では、待ち時間は通常、使用されるページング間隔とスリープ間隔によって増加します。 MAC層は、コマンドを便乗させて、上位層プロトコルの効率を向上（待ち時間を短縮）できます。このようなコマンドは、再同期を必要とせずにNフレームで新しいパケット転送を開始するようにPPに指示したり、ページングをリッスンしたり、より高いデューティサイクルのページング検出モードに留まるようにPPに指示したりできます。
The DECT ULE technology allows a per-PP configuration of paging interval, MTU size, reassembly window size, and higher-layer service negotiation and protocol.
DECT ULEテクノロジーでは、ページング間隔、MTUサイズ、再構成ウィンドウサイズ、および上位層のサービスネゴシエーションとプロトコルをPPごとに構成できます。
6LoWPAN provides an adaptation layer designed to support IPv6 over IEEE 802.15.4 [IEEE802.15.4]. 6LoWPAN affects the energy-efficiency problem in three aspects, as follows.
6LoWPANは、IEEE 802.15.4 [IEEE802.15.4]でIPv6をサポートするように設計された適応層を提供します。 6LoWPANは、次の3つの側面でエネルギー効率の問題に影響を与えます。
First, 6LoWPAN provides one fragmentation and reassembly mechanism, which is aimed at solving the packet size issue in IPv6 and could also affect energy efficiency. IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6 [RFC8200]. 6LoWPAN provides fragmentation and reassembly below the IP layer to solve the problem. One of the benefits from placing fragmentation at a lower layer such as the 6LoWPAN layer is that it can avoid the presence of more IP headers because fragmentation at the IP layer will produce more IP packets, each one carrying its own IP header. However, performance can be severely affected if, after IP layer fragmentation, then 6LoWPAN fragmentation happens as well (e.g., when the upper layer is not aware of the existence of the fragmentation at the 6LoWPAN layer). One solution is to require that the higher layers have an awareness of the lower-layer features and generate small enough packets to avoid fragmentation. In this regard, the Block option in CoAP can be useful when CoAP is used at the application layer [RFC7959].
まず、6LoWPANは、IPv6のパケットサイズの問題を解決することを目的とした1つの断片化および再構成メカニズムを提供し、エネルギー効率にも影響を与える可能性があります。 IPv6では、インターネットのすべてのリンクのMTUが1280オクテット以上である必要があります。 1280オクテットのパケットを1つにまとめて送信できないリンクでは、リンク固有のフラグメンテーションと再構成をIPv6 [RFC8200]の下のレイヤーで提供する必要があります。 6LoWPANは、問題を解決するために、IPレイヤーの下で断片化と再構成を提供します。 6LoWPANレイヤーなどの下位レイヤーにフラグメンテーションを配置することの利点の1つは、IPレイヤーでのフラグメンテーションにより、それぞれが独自のIPヘッダーを運ぶより多くのIPパケットを生成するため、より多くのIPヘッダーの存在を回避できることです。ただし、IP層の断片化の後に6LoWPANの断片化が発生した場合（たとえば、上位層が6LoWPAN層での断片化の存在を認識していない場合）、パフォーマンスに深刻な影響が及ぶ可能性があります。 1つの解決策は、上位層が下位層の機能を認識し、断片化を回避するのに十分な小さいパケットを生成することを要求することです。この点で、CoAPの[ブロック]オプションは、CoAPがアプリケーション層で使用されている場合に役立ちます[RFC7959]。
Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. Subject to the packet size limit of IEEE 802.15.4 [IEEE802.15.4], a 40-octet-long IPv6 header and an 8 or 20-octet-long UDP and TCP header will consume even more packet space than the data itself. 6LoWPAN provides IPv6 and UDP header compression at the adaptation layer. Therefore, a lower amount of data will be handled by the lower layers, whereas both the sender and receiver will spend more computing power on the compression and decompression of the packets over the air. Compression can also be performed at higher layers (see Section 6.4).
次に、6LoWPANはコンピューティングと通信を交換します。 6LoWPANはIPv6ヘッダーの圧縮を適用します。 IEEE 802.15.4 [IEEE802.15.4]のパケットサイズ制限に従い、40オクテット長のIPv6ヘッダーと8または20オクテット長のUDPおよびTCPヘッダーは、データ自体よりもさらに多くのパケットスペースを消費します。 6LoWPANは、アダプテーション層でIPv6およびUDPヘッダー圧縮を提供します。したがって、送信者と受信者の両方が無線でのパケットの圧縮と圧縮解除により多くの計算能力を費やす一方で、より少ない量のデータが下位層で処理されます。上位層でも圧縮を実行できます（6.4節を参照）。
Finally, the 6LoWPAN Working Group developed the energy-efficient Neighbor Discovery called 6LoWPAN-ND, which is an energy-efficient replacement of the IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, as its heavy use of multicast makes it inefficient and sometimes impractical in a low-power and lossy network. 6LoWPAN-ND describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low-Power Wireless Personal Area Networks and similar networks. However, 6LoWPAN-ND does not modify Neighbor Unreachability Detection (NUD) timeouts, which are very short (by default three transmissions spaced 1 second apart). NUD timeout settings should be tuned to take into account the latency that may be introduced by duty-cycled mechanisms at the link layer or the alternative, less impatient NUD algorithms should be considered [RFC7048].
最後に、6LoWPANワーキンググループは、6LoWPAN-NDと呼ばれるエネルギー効率の高い近隣探索を開発しました。これは、制約のある環境におけるIPv6 NDのエネルギー効率の高い代替品です。 IPv6 Neighbor Discoveryは、非推移的なワイヤレスリンク用に設計されていません。マルチキャストを多用することにより、効率が低下し、低電力で損失の多いネットワークでは実用的でない場合があります。 6LoWPAN-NDは、IPv6近隣探索、そのアドレッシングメカニズム、および低電力ワイヤレスパーソナルエリアネットワークと同様のネットワークの重複アドレス検出に対する単純な最適化について説明しています。ただし、6LoWPAN-NDは、非常に短い（デフォルトでは1秒間隔の3つの送信）ネイバー到達不能検出（NUD）タイムアウトを変更しません。 NUDタイムアウト設定は、リンクレイヤーのデューティサイクルメカニズムによって導入される可能性のあるレイテンシを考慮に入れて調整する必要があります。代わりに、それほど気にしないNUDアルゴリズムを検討する必要があります[RFC7048]。
IPv6 underlies the higher-layer protocols, including both TCP/UDP transport and applications. By design, the higher-layer protocols do not typically have specific information about the lower layers and thus cannot solve the energy-efficiency problem.
IPv6は、TCP / UDPトランスポートとアプリケーションの両方を含む、上位層のプロトコルの基礎となります。設計上、上位層のプロトコルには通常、下位層に関する特定の情報がないため、エネルギー効率の問題を解決できません。
The network stack can be designed to save computing power. For example, the Contiki implementation has multiple cross-layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software implementation techniques and are out of the scope of the IETF and the LWIG Working Group.
ネットワークスタックは、計算能力を節約するように設計できます。たとえば、Contiki実装には、バッファーとエネルギー管理のための複数のクロスレイヤー最適化があります。たとえば、別のレイヤーからIPヘッダーを読み取る必要がないUDP / TCPチェックサムの計算と検証です。これらの最適化はソフトウェア実装技術であり、IETFおよびLWIGワーキンググループの範囲外です。
RPL [RFC6550] is a routing protocol designed by the IETF for constrained environments. RPL exchanges messages periodically and keeps routing states for each destination. RPL is optimized for the many-to-one communication pattern (where network nodes primarily send data towards the border router) but has provisions for any-to-any routing as well.
RPL [RFC6550]は、IETFによって制約された環境用に設計されたルーティングプロトコルです。 RPLは定期的にメッセージを交換し、各宛先のルーティング状態を維持します。 RPLは多対1の通信パターン（ネットワークノードが主に境界ルーターにデータを送信する）向けに最適化されていますが、any-to-anyルーティングにも対応しています。
The authors of the Powertrace tool [Powertrace] studied the power profile of RPL. Their analysis divides the routing protocol into control and data traffic. The control plane carries ICMP messages to establish and maintain the routing states. The data plane carries any application that uses RPL for routing packets. The study has shown that the power consumption of the control traffic goes down over time in a relatively stable network. The study also reflects that the routing protocol should keep the control traffic as low as possible to make it energy friendly. The amount of RPL control traffic can be tuned by setting the Trickle [RFC6206] algorithm parameters (i.e., Imin, Imax, and k) to appropriate values. However, there exists a trade-off between energy consumption and other performance parameters such as network convergence time and robustness.
Powertraceツール[Powertrace]の作成者は、RPLの電力プロファイルを調査しました。それらの分析により、ルーティングプロトコルが制御トラフィックとデータトラフィックに分割されます。コントロールプレーンはICMPメッセージを伝送して、ルーティング状態を確立および維持します。データプレーンは、RPLを使用してパケットをルーティングするアプリケーションを伝送します。この調査では、比較的安定したネットワークでは、制御トラフィックの電力消費が時間の経過とともに低下することが示されています。また、この調査は、ルーティングプロトコルが制御トラフィックを可能な限り低く抑えて、エネルギーフレンドリーにすることを反映しています。 RPL制御トラフィックの量は、Trickle [RFC6206]アルゴリズムパラメーター（つまり、Imin、Imax、k）を適切な値に設定することで調整できます。ただし、エネルギー消費と、ネットワークの収束時間や堅牢性などの他のパフォーマンスパラメータの間にはトレードオフがあります。
RFC 6551 [RFC6551] defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node Energy object that allows to provide information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics may help to balance energy consumption of network nodes, minimize network partitioning, and increase network lifetime.
RFC 6551 [RFC6551]は、RPLがルート計算で使用するルーティングメトリックと制約を定義しています。特に、RFC 6551は、エネルギー源のタイプや残存エネルギーの推定割合など、ノードエネルギーに関連する情報を提供できるノードエネルギーオブジェクトを指定しています。エネルギーベースのルーティングメトリックの適切な使用は、ネットワークノードのエネルギー消費のバランスを取り、ネットワークの分割を最小限に抑え、ネットワークの寿命を延ばすのに役立ちます。
CoAP [RFC7252] is designed as a RESTful application protocol that connects the services of smart devices to the World Wide Web. CoAP is not a chatty protocol. It provides basic communication services such as service discovery and GET/POST/PUT/DELETE methods with a binary header.
CoAP [RFC7252]は、スマートデバイスのサービスをWorld Wide Webに接続するRESTfulアプリケーションプロトコルとして設計されています。 CoAPはおしゃべりなプロトコルではありません。バイナリヘッダーを使用して、サービスディスカバリやGET / POST / PUT / DELETEメソッドなどの基本的な通信サービスを提供します。
Energy efficiency is part of the CoAP protocol design. CoAP uses a fixed-length binary header of only four bytes that may be followed by binary options. To reduce regular and frequent queries of the resources, CoAP provides an observe mode in which the requester registers its interest of a certain resource and the responder will report the value whenever it was updated. This reduces the request/ response round trips while keeping information exchange an ubiquitous service; an energy-constrained server can remain in sleep mode during the period between observe notification transmissions.
エネルギー効率は、CoAPプロトコル設計の一部です。 CoAPは、バイナリオプションが後に続く可能性がある4バイトのみの固定長バイナリヘッダーを使用します。リソースの定期的かつ頻繁なクエリを削減するために、CoAPは、リクエスターが特定のリソースの関心を登録し、レスポンダーが更新されるたびに値を報告する監視モードを提供します。これにより、ユビキタスサービスで情報交換を維持しながら、要求/応答のラウンドトリップが減少します。エネルギーに制約のあるサーバーは、通知の送信を監視するまでの期間、スリープモードを維持できます。
Furthermore, [RFC7252] defines CoAP proxies that can cache resource representations previously provided by sleepy CoAP servers. The proxies themselves may respond to client requests if the corresponding server is sleeping and the resource representation is recent enough. Otherwise, a proxy may attempt to obtain the resource from the sleepy server.
さらに、[RFC7252]は、以前はスリープ状態のCoAPサーバーによって提供されていたリソース表現をキャッシュできるCoAPプロキシを定義しています。対応するサーバーがスリープ状態にあり、リソース表現が十分に新しい場合、プロキシ自体がクライアント要求に応答する場合があります。そうしないと、プロキシがスリープ状態のサーバーからリソースを取得しようとする場合があります。
CoAP proxy and cache functionality may also be used to perform data aggregation. This technique allows a node to receive data messages (e.g., carrying sensor readings) from other nodes in the network, perform an operation based on the content in those messages, and transmit the result of the operation. Such operation may simply be intended to use one packet to carry the readings transported in several packets (which reduces header and transmission overhead), or it may be a more sophisticated operation, possibly based on mathematical, logical, or filtering principles (which reduces the payload size to be transmitted).
CoAPプロキシおよびキャッシュ機能を使用して、データ集約を実行することもできます。この技術により、ノードはネットワーク内の他のノードからデータメッセージ（センサーの読み取り値を運ぶなど）を受信し、それらのメッセージの内容に基づいて操作を実行し、操作の結果を送信できます。このような操作は、1つのパケットを使用して複数のパケットで転送された読み取り値を運ぶ（ヘッダーと送信のオーバーヘッドを削減する）ことを単に意図しているか、または数学、論理、またはフィルタリングの原則（これにより、送信されるペイロードサイズ）。
Beyond these features of CoAP, there have been a number of proposals to further support sleepy nodes at the application layer by leveraging CoAP mechanisms. A good summary of such proposals can be found in [SLEEPY-DEVICES], while an example application (in the context of illustrating several security mechanisms) in a scenario with sleepy devices has been described [CRYPTO-SENSORS]. Approaches to support sleepy nodes include exploiting the use of proxies, leveraging the resource directory [CoRE-RD], or signaling when a node is awake to the interested nodes. Recent work defines publish-subscribe and message queuing extensions to CoAP and the resource directory in order to support devices that spend most of their time asleep [CoAP-BROKER]. Notably, this work has been adopted by the CoRE Working Group.
CoAPのこれらの機能に加えて、CoAPメカニズムを活用することにより、アプリケーションレイヤーでスリープ状態のノードをさらにサポートするための多くの提案があります。そのような提案の優れた要約は[SLEEPY-DEVICES]にありますが、スリープ状態のデバイスを使用したシナリオでの（いくつかのセキュリティメカニズムを示すコンテキストでの）アプリケーションの例は[CRYPTO-SENSORS]で説明されています。スリープ状態のノードをサポートするアプローチには、プロキシの使用、リソースディレクトリ[CoRE-RD]の活用、またはノードが関係するノードに対してウェイクしているときのシグナリングが含まれます。最近の作業では、CoAPおよびリソースディレクトリのパブリッシュサブスクライブとメッセージキューイングの拡張機能を定義して、ほとんどの時間をスリープ状態で過ごすデバイスをサポートしています[CoAP-BROKER]。特に、この作業はCoREワーキンググループで採用されています。
In addition to the work within the scope of CoAP to support sleepy nodes, other specifications define application-layer functionality for the same purpose. The Lightweight Machine-to-Machine (LwM2M) specification from the Open Mobile Alliance (OMA) defines a queue mode whereby an LwM2M Server queues requests to an LwM2M Client until the latter (which may often stay in sleep mode) is online. LwM2M functionality operates on top of CoAP.
CoAPの範囲内でスリープ状態のノードをサポートする作業に加えて、他の仕様では、同じ目的でアプリケーション層の機能を定義しています。 Open Mobile Alliance（OMA）のLightweight Machine-to-Machine（LwM2M）仕様は、LwM2MサーバーがLwM2Mクライアントへの要求をキューに入れるキューモードを定義します（後者は（スリープモードに留まることが多い）がオンラインになるまで）。 LwM2M機能はCoAPの上で動作します。
oneM2M defines a CoAP binding with an application-layer mechanism for sleepy nodes [oneM2M].
oneM2Mは、スリープ状態のノードのアプリケーション層メカニズムを備えたCoAPバインディングを定義します[oneM2M]。
CoAP offers mechanisms for reliable communication between two CoAP endpoints. A CoAP message may be signaled as a confirmable (CON) message, and an acknowledgment (ACK) is issued by the receiver if the CON message is correctly received. The sender starts a Retransmission Timeout (RTO) for every CON message sent. The initial RTO value is chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value is doubled (unless a limit on the number of retransmissions has been reached). Since duty cycling at the link layer may lead to long latency (i.e., even greater than the initial RTO value), CoAP RTO parameters should be tuned accordingly in order to avoid spurious RTOs that would unnecessarily waste node energy and other resources. On the other hand, note that CoAP can also run on top of TCP [RFC8323]. In that case, similar guidance applies to TCP timers, albeit with greater motivation to carefully configure TCP RTO parameters since [RFC6298] reduced the default initial TCP RTO to 1 second, which may interact more negatively with duty-cycled links than default CoAP RTO values.
CoAPは、2つのCoAPエンドポイント間の信頼できる通信のためのメカニズムを提供します。 CoAPメッセージは確認可能（CON）メッセージとして通知され、CONメッセージが正しく受信された場合、受信者によって確認（ACK）が発行されます。送信者は、送信されるCONメッセージごとに再送信タイムアウト（RTO）を開始します。初期RTO値は、2〜3秒の間でランダムに選択されます。 RTOが期限切れになると、新しいRTO値は2倍になります（再送信の数の制限に達していない場合）。リンクレイヤーでのデューティサイクルは、レイテンシが長くなる（つまり、初期RTO値よりも大きくなる）可能性があるため、ノードエネルギーやその他のリソースを不必要に浪費する偽のRTOを回避するために、CoAP RTOパラメータを適宜調整する必要があります。一方、CoAPはTCP [RFC8323]の上でも実行できることに注意してください。その場合、同様のガイダンスがTCPタイマーに適用されますが、[RFC6298]はデフォルトの初期TCP RTOを1秒に減らし、デフォルトのCoAP RTO値よりも負荷サイクルリンクに悪影響を与える可能性があるため、TCP RTOパラメータを慎重に設定する動機はあります。 。
Another method intended to reduce the size of the data units to be communicated in constrained-node networks is data compression, which allows to encode data using fewer bits than the original data representation. Data compression is more efficient at higher layers, particularly before encryption is used. In fact, encryption mechanisms may generate an output that does not contain redundancy, making it almost impossible to reduce the data representation size. In CoAP, messages may be encrypted by using Datagram Transport Layer Security (DTLS) or TLS when CoAP over TCP is used, which is the default mechanism for securing CoAP exchanges.
制約付きノードネットワークで通信されるデータユニットのサイズを削減することを目的とした別の方法は、データ圧縮です。これにより、元のデータ表現よりも少ないビットを使用してデータをエンコードできます。特に暗号化が使用される前は、データ圧縮は上位層でより効率的です。実際、暗号化メカニズムは冗長性を含まない出力を生成する可能性があり、データ表現サイズを削減することはほとんど不可能です。 CoAPでは、CoAP over TCPを使用する場合、データグラムトランスポート層セキュリティ（DTLS）またはTLSを使用してメッセージを暗号化できます。これは、CoAP交換を保護するためのデフォルトのメカニズムです。
We summarize the key takeaways of this document:
このドキュメントの要点をまとめます。
a. Internet protocols designed by the IETF can be considered the customer of the lower layers (PHY, MAC, and duty cycling). To reduce power consumption, it is recommended that Layer 3 designs should operate based on awareness of lower-level parameters rather than treating the lower layer as a black box (see Sections 4, 5, and 6).
a. IETFによって設計されたインターネットプロトコルは、下位層（PHY、MAC、およびデューティサイクル）の顧客と見なすことができます。消費電力を削減するには、下位層をブラックボックスとして扱うのではなく、下位レベルのパラメーターの認識に基づいてレイヤー3設計を動作させることをお勧めします（セクション4、5、および6を参照）。
b. It is always useful to compress the protocol headers in order to reduce the transmission/reception power. This design principle has been employed by many protocols in the 6lo and CoRE Working Groups (see Sections 4 and 6).
b. 送受信電力を削減するために、プロトコルヘッダーを圧縮すると常に役立ちます。この設計原則は、6loおよびCoREワーキンググループの多くのプロトコルで採用されています（セクション4および6を参照）。
c. Broadcast and non-synchronized transmissions consume more than other TX/RX operations. If protocols must use these ways to collect information, reduction of their usage by aggregating similar messages together will be helpful in saving power (see Sections 2 and 6.1).
c. ブロードキャストおよび非同期の送信は、他のTX / RX操作よりも多くの電力を消費します。プロトコルがこれらの方法を使用して情報を収集する必要がある場合、同様のメッセージをまとめて使用量を削減すると、節電に役立ちます（セクション2および6.1を参照）。
d. Saving power by sleeping as much as possible is used widely (Section 3).
d. 可能な限り睡眠をとることによる節電は広く使用されています（セクション3）。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document discusses energy-efficient protocol design and does not incur any changes or challenges on security issues besides what the protocol specifications have analyzed.
このドキュメントでは、エネルギー効率の高いプロトコル設計について説明し、プロトコル仕様で分析したもの以外に、セキュリティの問題に関する変更や課題を発生させません。
[Bluetooth42] Bluetooth Special Interest Group, "Core Version 4.2", available from "Legacy Core Specifications", December 2014, <https://www.bluetooth.com/specifications/ bluetooth-core-specification/legacy-specifications>.
[Bluetooth42] Bluetooth特別興味グループ、「コアバージョン4.2」、「レガシーコア仕様」、2014年12月<https://www.bluetooth.com/specifications/ bluetooth-core-specification / legacy-specifications>から入手可能。
[EN300] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 1: Overview", ETSI EN 300 175-1 V2.6.1, July 2015, <https://www.etsi.org/deliver/ etsi_en/300100_300199/30017501/02.06.01_60/ en_30017501v020601p.pdf>.
[EN300] ETSI、「Digital Enhanced Cordless Telecommunications（DECT）; Common Interface（CI）; Part 1：Overview」、ETSI EN 300 175-1 V2.6.1、2015年7月、<https://www.etsi.org/ deliver / etsi_en / 300100_300199 / 30017501 / 02.06.01_60 / en_30017501v020601p.pdf>。
[G9959] ITU-T, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G9959] ITU-T、「短距離狭帯域デジタル無線通信トランシーバー-PHY、MAC、SAR、およびLLCレイヤー仕様」、ITU-T勧告G.9959、2015年1月、<http://www.itu.int/ rec / T-REC-G.9959>。
[IEEE802.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, DOI 10.1109/IEEESTD.2016.7786995, <http://ieeexplore.ieee.org/document/7786995/versions>.
[IEEE802.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、DOI 10.1109 / IEEESTD.2016.7786995、<http://ieeexplore.ieee.org/document/7786995/versions>。
[IEEE802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>.
[IEEE802.15.4] IEEE、「低速無線ネットワークのIEEE規格」、IEEE 802.15.4、DOI 10.1109 / IEEESTD.2016.7460875、<https://standards.ieee.org/findstds/ standard / 802.15.4-2015 .html>。
[MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication Protocol for Building Automation and Control Networks ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to ANSI/ASHRAE Standard 135-2012", July 2014, <https://www.ashrae.org/technical-resources/standards-and-guidelines/standards-addenda/ addenda-to-standard-135-2012>.
[MSTP] ANSI / ASHRAE、「補遺：BACnet-ビルディングオートメーションおよび制御ネットワーク用のデータ通信プロトコルANSI / ASHRAE補遺ANSI / ASHRAE標準135-2012への、an、at、au、av、aw、ax、およびaz」 、2014年7月、<https://www.ashrae.org/technical-resources/standards-and-guidelines/standards-addenda/ addenda-to-standard-135-2012>。
[NFC] NFC Forum, "NFC Logical Link Control Protocol", Technical Specification, Version 1.3, March 2016.
[NFC] NFCフォーラム、「NFC論理リンク制御プロトコル」、技術仕様、バージョン1.3、2016年3月。
[oneM2M] oneM2M, "oneM2M - Published Specifications", <http://www.onem2m.org/technical/published-documents>.
[oneM2M] oneM2M、「oneM2M-公開仕様」、<http://www.onem2m.org/technical/published-documents>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<https： //www.rfc-editor.org/info/rfc4944>。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <https://www.rfc-editor.org/info/rfc6206>.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「トリクルアルゴリズム」、RFC 6206、DOI 10.17487 / RFC6206、2011年3月、<https：// 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, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282]ホイ、J。、エド。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、DOI 10.17487 / RFC6282、2011年9月、<https://www.rfc-editor.org/info/rfc6282>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>。
[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, <https://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月、<https://www.rfc-editor.org/info/ rfc6550>。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://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月、<https://www.rfc-editor.org/info/rfc6551>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775]シェルビー、Z。、編、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「ローパワーワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、DOI 10.17487 / RFC6775、2012年11月、<https://www.rfc-editor.org/info/rfc6775>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<https://www.rfc-editor.org / info / rfc7228>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.
[RFC7668] Nieminen、J.、Savolainen、T.、Isomaki、M.、Patil、B.、Shelby、Z。、およびC. Gomez、「IPv6 over BLUETOOTH（R）Low Energy」、RFC 7668、DOI 10.17487 / RFC7668、2015年10月、<https://www.rfc-editor.org/info/rfc7668>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[TS102] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 2: Home Automation Network (phase 2", ETSI TS 102 939-2 V1.1.1, March 2015, <https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293902/01.01.01_60/ ts_10293902v010101p.pdf>.
[TS102] ETSI、「Digital Enhanced Cordless Telecommunications（DECT）; Ultra Low Energy（ULE）; Machine to Machine Communications; Part 2：Home Automation Network（phase 2 "、ETSI TS 102 939-2 V1.1.1、March 2015、 <https://www.etsi.org/deliver/ etsi_ts / 102900_102999 / 10293902 / 01.01.01_60 / ts_10293902v010101p.pdf>。
[AN079] Kim, C., "Measuring Power Consumption of CC2530 With Z-Stack", Application Note AN079, SWRA292, September 2012, <http://www.ti.com/lit/an/swra292/swra292.pdf>.
[AN079] Kim、C。、「Measuring Power Consumption of CC2530 With Z-Stack」、アプリケーションノートAN079、SWRA292、2012年9月、<http://www.ti.com/lit/an/swra292/swra292.pdf> 。
[ARCH-6TiSCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-13, November 2017.
[ARCH-6TiSCH] Thubert、P。、「IEEE 802.15.4のTSCHモードを介したIPv6のアーキテクチャ」、作業中、draft-ietf-6tisch-architecture-13、2017年11月。
[CLASS1-CoAP] Kovatsch, M., "Implementing CoAP for Class 1 Devices", Work in Progress, draft-kovatsch-lwig-class1-coap-00, October 2012.
[CLASS1-CoAP] Kovatsch、M。、「クラス1デバイスのCoAPの実装」、作業中、draft-kovatsch-lwig-class1-coap-00、2012年10月。
[CNN-TERMS] Bormann, C., Ersue, M., Keranen, A., and C. Gomez, "Terminology for Constrained-Node Networks", Work in Progress, draft-bormann-lwig-7228bis-02, October 2017.
[CNN-TERMS] Bormann、C.、Ersue、M.、Kerenen、A。、およびC. Gomez、「Constrained-Node Networks」の用語、進行中の作業、draft-bormann-lwig-7228bis-02、2017年10月。
[CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, March 2018.
[CoAP-BROKER]コスター、M。、ケラネン、A.、J。ヒメネス、「制約付きアプリケーションプロトコル（CoAP）のパブリッシュ-サブスクライブブローカー」、作業中、draft-ietf-core-coap-pubsub-04 、2018年3月。
[ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", SICS Technical Report T2011:13, December 2011, <http://soda.swedishict.se/5128/>.
[ContikiMAC] Dunkels、A。、「The ContikiMAC Radio Duty Cycling Protocol」、SICS Technical Report T2011：13、2011年12月、<http://soda.swedishict.se/5128/>。
[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, Ed., "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-13, March 2018.
[CoRE-RD]シェルビー、Z。、コスター、M。、ボルマン、C。、ストック、P。、およびC.アムス、編、「CoREリソースディレクトリ」、作業中、draft-ietf-core-resource -directory-13、2018年3月。
[CRYPTO-SENSORS] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Work in Progress, draft-ietf-lwig-crypto-sensors-06, February 2018.
[CRYPTO-SENSORS] Sethi、M.、Arkko、J.、Kerenen、A。、およびH. Back、「実用的な考慮事項とスマートオブジェクトネットワークの保護における実装経験」、進行中の作業、draft-ietf-lwig-crypto-センサー-06、2018年2月。
[Powertrace] Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", SICS Technical Report T2011:05, March 2011, <http://soda.swedishict.se/4112/>.
[Powertrace] Dunkels、A.、Eriksson、J.、Finne、N。、およびN. Tsiftes、「Powertrace：低電力ワイヤレスネットワークのネットワークレベルの電力プロファイリング」、SICSテクニカルレポートT2011：05、2011年3月、< http://soda.swedishict.se/4112/>。
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014, <https://www.rfc-editor.org/info/rfc7048>.
[RFC7048] Nordmark、E。およびI. Gashinsky、「Neighbor Unreachability Detection Is Too Inpatient」、RFC 7048、DOI 10.17487 / RFC7048、2014年1月、<https://www.rfc-editor.org/info/rfc7048>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C.およびZ. Shelby、Ed。、「Block-Wise Transfers in the Constrained Application Protocol（CoAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<https：//www.rfc- editor.org/info/rfc7959>。
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8105] Mariager、P.、Petersen、J.、Ed。、Shelby、Z.、Van de Logt、M。、およびD. Barthel、「Digital Enhanced Cordless Telecommunications（DECT）超低エネルギーでのIPv6パケットの送信（ ULE） "、RFC 8105、DOI 10.17487 / RFC8105、2017年5月、<https://www.rfc-editor.org/info/rfc8105>。
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8180] Vilajosana、X.、Ed。、Pister、K。、およびT. Watteyne、「IEEE 802.15.4e（6TiSCH）構成のTSCHモードでの最小IPv6」、BCP 210、RFC 8180、DOI 10.17487 / RFC8180、 2017年5月、<https://www.rfc-editor.org/info/rfc8180>。
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323] Bormann、C.、Lemay、S.、Tschofenig、H.、Hartke、K.、Silverajan、B.、and B. Raymor、Ed。、 "CoAP（Constrained Application Protocol）over TCP、TLS、and WebSockets "、RFC 8323、DOI 10.17487 / RFC8323、2018年2月、<https://www.rfc-editor.org/info/rfc8323>。
[SLEEPY-DEVICES] Rahman, A., "Sleepy Devices: Do we need to Support them in CORE?", Work in Progress, draft-rahman-core-sleepy-nodes-do-we-need-01, February 2014.
[SLEEPY-DEVICES] Rahman、A.、「スリープ状態のデバイス：COREでサポートする必要がありますか？」、作業中、draft-rahman-core-sleepy-nodes-do-we-need-01、2014年2月。
Acknowledgments
謝辞
Carles Gomez has been supported by the Spanish Government, FEDER, and the ERDF through projects TEC2012-32531 and TEC2016-79988-P.
カルレスゴメスは、プロジェクトTEC2012-32531およびTEC2016-79988-Pを通じてスペイン政府、FEDER、およびERDFによってサポートされています。
The authors would like to give thanks for the review and feedback from a number of experts in this area: Carsten Bormann, Ari Keranen, Hannes Tschofenig, Dominique Barthel, Bernie Volz, and Charlie Perkins.
著者は、この領域の多くの専門家からのレビューとフィードバックに感謝します：Carsten Bormann、Ari Keranen、Hannes Tschofenig、Dominique Barthel、Bernie Volz、およびCharlie Perkins。
The text of this document was improved based on an IESG document editing session during IETF 87. Thanks to Ted Lemon and Joel Jaeggli for initiating and facilitating this editing session.
このドキュメントのテキストは、IETF 87のIESGドキュメント編集セッションに基づいて改善されました。この編集セッションを開始および促進してくれたTed LemonとJoel Jaeggliに感謝します。
Contributors
貢献者
Jens T. Petersen, RTX, contributed the section on power save services in DECT ULE.
RTXのJens T. Petersenが、DECT ULEの節電サービスに関するセクションに貢献しました。
Authors' Addresses
著者のアドレス
Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 Castelldefels 08860 Spain
Carles Gomez Universitat Politecnica de Catalunya C / Esteve Terradas、7 Castelldefels 08860 Spain
Email: carlesgo@entel.upc.edu
Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland
Matthias Kovatsch ETHチューリッヒUniversitaetstrasse 6チューリッヒ、CH-8092スイス
Email: ietf@kovatsch.net
Hui Tian China Academy of Telecommunication Research Huayuanbeilu No. 52 Beijing, Haidian District 100191 China
Hui TIプレス通信研究の中国アカデミー胡阿源北路52号北京、Hドワーフ地区100191中国
Email: tianhui@ritt.cn
Zhen Cao (editor) Huawei Technologies China
ZおよびNCオーストリア（編集者）hu A（テクノロジー中国向け）
Email: zhencao.ietf@gmail.com