[要約] RFC 9178は、セルラーネットワーク用の省電力かつ制約のあるアプリケーションプロトコル（CoAP）デバイスの構築に関するガイドラインを提供します。この文書の目的は、電力消費を最小限に抑えつつ、効率的な通信を実現するための技術的な推奨事項を示すことです。主に、IoTデバイスやセンサーなど、電力資源が限られている環境での利用が想定されています。
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 9178 Ericsson
Category: Informational A. Eriksson
ISSN: 2070-1721 Independent
A. Keränen
Ericsson
May 2022
Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks
セルラーネットワーク向けの電力効率の高い制約アプリケーションプロトコル（COAP）デバイスの構築
Abstract
概要
This memo discusses the use of the Constrained Application Protocol (CoAP) in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption.
このメモでは、通信媒体としてセルラーネットワークを採用する構築センサーおよびその他のデバイスでの制約付きアプリケーションプロトコル（COAP）の使用について説明します。これらのネットワークを採用する通信デバイスの構築は明らかによく知られていますが、このメモは、消費電力を最小限に抑えるために必要な技術に特に焦点を当てています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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）の製品です。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/rfc9178.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9178で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Goals for Low-Power Operation
3. Link-Layer Assumptions
4. Scenarios
5. Discovery and Registration
6. Data Formats
7. Real-Time Reachable Devices
8. Sleepy Devices
8.1. Implementation Considerations
9. Security Considerations
10. IANA Considerations
11. References
11.1. Normative References
11.2. Informative References
Acknowledgments
Authors' Addresses
This memo discusses the use of the Constrained Application Protocol (CoAP) [RFC7252] in building sensors and other devices that employ cellular networks as a communications medium. Building communicating devices that employ these networks is obviously well known, but this memo focuses specifically on techniques necessary to minimize power consumption. CoAP has many advantages, including being simple to implement; a thousand lines of code for the entire application above the IP layer is plenty for a CoAP-based sensor, for instance. However, while many of these advantages are obvious and easily obtained, optimizing power consumption remains challenging and requires careful design [Tiny-CoAP].
このメモでは、通信媒体としてセルラーネットワークを使用するセンサーやその他のデバイスでの制約付きアプリケーションプロトコル（COAP）[RFC7252]の使用について説明します。これらのネットワークを採用する通信デバイスの構築は明らかによく知られていますが、このメモは、消費電力を最小限に抑えるために必要な技術に特に焦点を当てています。COAPには、簡単に実装できるなど、多くの利点があります。たとえば、Coapベースのセンサーには、IPレイヤーの上のアプリケーション全体の1000行のコードが十分です。ただし、これらの利点の多くは明らかで簡単に取得できますが、消費電力の最適化は依然として困難であり、慎重な設計を必要とします[Tiny-Coap]。
This memo primarily targets 3GPP cellular networks in their 2G, 3G, LTE, and 5G variants and their future enhancements, including possible power efficiency improvements at the radio and link layers. The exact standards or details of the link layer or radios are not relevant for our purposes, however. To be more precise, the material in this memo is suitable for any large-scale, public network that employs a point-to-point communications model and radio technology for the devices in the network.
このメモは、主に、2G、3G、LTE、および5Gバリアントの3GPPセルラーネットワークと、無線およびリンク層での電力効率の改善の可能性を含む将来の強化を対象としています。ただし、リンクレイヤーまたはラジオの正確な標準または詳細は、当社の目的には関係ありません。より正確には、このメモの資料は、ネットワーク内のデバイスにポイントツーポイント通信モデルと無線技術を採用する大規模なパブリックネットワークに適しています。
Our focus is on devices that need to be optimized for power usage and devices that employ CoAP. As a general technology, CoAP is similar to HTTP. It can be used in various ways, and network entities may take on different roles. This freedom allows the technology to be used in efficient and less efficient ways. Some guidance is needed to understand what types of communication over CoAP are recommended when low power usage is a critical goal.
私たちの焦点は、COAPを使用する電力使用量とデバイスに最適化する必要があるデバイスにあります。一般的な技術として、COAPはHTTPに似ています。さまざまな方法で使用でき、ネットワークエンティティはさまざまな役割を引き受ける場合があります。この自由により、技術を効率的で効率の低い方法で使用することができます。低電力使用量が重要な目標である場合、COAPを介したコミュニケーションの種類を理解するには、いくつかのガイダンスが必要です。
The recommendations in this memo should be taken as complementary to device hardware optimization, microelectronics improvements, and further evolution of the underlying link and radio layers. Further gains in power efficiency can certainly be gained on several fronts; the approach that we take in this memo is to do what can be done at the IP, transport, and application layers to provide the best possible power efficiency. Application implementors generally have to use the current-generation microelectronics, currently available radio networks and standards, and so on. This focus in our memo should by no means be taken as an indication that further evolution in these other areas is unnecessary. Such evolution is useful, ongoing, and generally complementary to the techniques presented in this memo. However, the list of techniques described in this document as useful for a particular application may change with the evolution of these underlying technologies.
このメモの推奨事項は、デバイスハードウェアの最適化、マイクロエレクトロニクスの改善、および基礎となるリンクおよび無線層のさらなる進化を補完するものとする必要があります。電力効率のさらなる利益は、確かにいくつかの面で得られる可能性があります。このメモで取るアプローチは、可能な限り最高の電力効率を提供するために、IP、トランスポート、およびアプリケーション層でできることを行うことです。アプリケーションの実装者は、通常、現在利用可能な無線ネットワークや標準など、現在の世代のマイクロエレクトロニクスを使用する必要があります。私たちのメモのこの焦点は、これらの他の領域でのさらなる進化が不要であることを示すものとして決してとられるべきではありません。このような進化は有用であり、継続的であり、一般的にこのメモに示されている技術を補完します。ただし、特定のアプリケーションに役立つこのドキュメントで説明されている技術のリストは、これらの基礎となるテクノロジーの進化により変化する可能性があります。
The rest of this memo is structured as follows. Section 2 discusses the need and goals for low-power devices. Section 3 outlines our expectations for the low-layer communications model. Section 4 describes the two scenarios that we address. Sections 5, 6, 7, and 8 give guidelines for the use of CoAP in these scenarios.
このメモの残りは次のように構成されています。セクション2では、低電力デバイスのニーズと目標について説明します。セクション3では、低層通信モデルに対する期待の概要を説明します。セクション4では、対処する2つのシナリオについて説明します。セクション5、6、7、および8は、これらのシナリオでCOAPを使用するためのガイドラインを示しています。
This document was originally finalized in 2016 but is published six years later due to waiting for key references to reach RFC status. Therefore, some of the latest advancements in cellular network, CoAP, and other technologies are not discussed here, and some of the references point to documents that were state of the art in 2016.
このドキュメントは元々2016年に確定されましたが、6年後にRFCステータスに到達する重要な参照が待っているため発行されました。したがって、セルラーネットワーク、COAP、およびその他の技術の最新の進歩のいくつかはここでは議論されておらず、参考文献の一部は2016年に最先端の文書を指しています。
There are many situations where power usage optimization is unnecessary. Optimization may not be necessary on devices that can run on a power feed over wired communications media, such as in Power-over-Ethernet (PoE) solutions. These devices may require a rudimentary level of power optimization techniques just to keep overall energy costs and aggregate power feed sizes at a reasonable level, but more extreme techniques necessary for battery-powered devices are not required. The situation is similar with devices that can easily be connected to mains power. Other types of devices may get an occasional charge of power from energy-harvesting techniques. For instance, some environmental sensors can run on solar cells. Typically, these devices still have to regulate their power usage in a strict manner -- for instance, to be able to use solar cells that are as small and inexpensive as possible.
電力使用量の最適化が不要な多くの状況があります。Power-over-Ethernet（POE）ソリューションなど、有線通信メディア上の電源フィードで実行できるデバイスでは、最適化は必要ない場合があります。これらのデバイスは、全体的なエネルギーコストと総電力供給サイズを妥当なレベルに維持するためだけに、初歩的なレベルの電力最適化手法を必要とする場合がありますが、バッテリー駆動のデバイスに必要な極端な技術は必要ありません。状況は、主電源に簡単に接続できるデバイスと同様です。他のタイプのデバイスは、エネルギーハーベストテクニックから時折電力の充電を受ける可能性があります。たとえば、一部の環境センサーは太陽電池で実行できます。通常、これらのデバイスは、可能な限り小さくて安価な太陽電池を使用できるようにするために、厳格な方法で電力使用量を調整する必要があります。
In battery-operated devices, power usage is even more important. For instance, one of the authors employs over a hundred different sensor devices in their home network. A majority of these devices are wired and run on PoE, but in most environments this would be impractical because the necessary wires do not exist. The future is in wireless solutions that can cover buildings and other environments without assuming a pre-existing wired infrastructure. In addition, in many cases it is impractical to provide a mains power source. Often, there are no power sockets easily available in the locations that the devices need to be in, and even if there were, setting up the wires and power adapters would be more complicated than installing a standalone device without any wires.
バッテリー操作デバイスでは、電力使用量がさらに重要です。たとえば、著者の1人は、ホームネットワークで100を超えるセンサーデバイスを採用しています。これらのデバイスの大部分は配線されており、POEで実行されていますが、ほとんどの環境では、必要なワイヤが存在しないため、これは実用的ではありません。未来は、既存の有線インフラストラクチャを想定せずに建物やその他の環境をカバーできるワイヤレスソリューションにあります。さらに、多くの場合、主電源を提供することは非現実的です。多くの場合、デバイスが必要な場所に簡単に利用できる電源ソケットはありません。たとえあったとしても、ワイヤーと電源アダプターのセットアップは、ワイヤなしでスタンドアロンデバイスを設置するよりも複雑になります。
Yet, with a large number of devices, the battery lifetimes become critical. Cost and practical limits dictate that devices can be largely just bought and left on their own. For instance, with a hundred devices, even a ten-year battery lifetime results in a monthly battery change for one device within the network. This may be impractical in many environments. In addition, some devices may be physically difficult to reach for a battery change. Or, a large group of devices -- such as utility meters or environmental sensors -- cannot be economically serviced too often, even if in theory the batteries could be changed.
しかし、多数のデバイスを使用すると、バッテリーの寿命が重要になります。コストと実用的な制限により、デバイスは主に購入して自分で残しておくことができることが規定されています。たとえば、100のデバイスを使用すると、10年のバッテリーの寿命でさえ、ネットワーク内の1つのデバイスの月間バッテリーが変更されます。これは多くの環境では非現実的かもしれません。さらに、一部のデバイスは、バッテリーの変更に到達するのが物理的に困難な場合があります。または、ユーティリティメーターや環境センサーなどの大規模なデバイスグループは、理論的にバッテリーを変更できる場合でも、経済的に頻繁にサービスを提供することはできません。
Many of these situations lead to a requirement for minimizing power usage and/or maximizing battery lifetimes. Using the power usage strategies described in [RFC7228], mains-powered sensor-type devices can use the Always-on strategy, whereas battery-operated or energy-harvesting devices need to adjust behavior based on the communication interval. For intervals on the order of seconds, the Low-power strategy is appropriate. For intervals ranging from minutes to hours, either the Low-power or Normally-off strategy is suitable. Finally, for intervals lasting days or longer, Normally-off is usually the best choice. Unfortunately, much of our current technology has been built with different objectives in mind -- for instance, networked devices that are "always on", gadgets that require humans to recharge them every couple of days, and protocols that have been optimized to maximize throughput rather than conserve resources.
これらの状況の多くは、電力使用量を最小限に抑え、バッテリーの寿命を最大化するための要件につながります。[RFC7228]で説明されている電力使用戦略を使用すると、メイン駆動のセンサータイプのデバイスは、常にオンになっている戦略を使用できますが、バッテリー操作またはエネルギーハーベストデバイスは、通信間隔に基づいて動作を調整する必要があります。数秒の間隔では、低電力戦略が適切です。数分から数時間の範囲の間隔では、低電力または通常の戦略のいずれかが適しています。最後に、間隔で長続きする間、通常は通常の選択が最良の選択です。残念ながら、私たちの現在の技術の多くは、さまざまな目的を念頭に置いて構築されています。たとえば、「常にオン」のネットワークデバイス、人間に数日ごとにそれらを充電する必要があるガジェット、スループットを最大化するために最適化されたプロトコルリソースを節約するのではなく。
Long battery lifetimes are required for many applications, however. In some cases, these lifetimes should be on the order of years or even a decade or longer. Some communication devices already reach multi-year lifetimes, and continuous improvements in low-power electronics and advances in radio technology keep pushing these lifetimes longer. However, it is perhaps fair to say that battery lifetimes are generally too short at present.
ただし、多くのアプリケーションには長いバッテリーの寿命が必要です。場合によっては、これらの寿命は数年または10年以上にわたってある必要があります。一部の通信デバイスはすでに複数年の寿命に到達しており、低電力電子機器の継続的な改善と無線技術の進歩により、これらの寿命が長くなり続けています。ただし、現在、バッテリーの寿命が一般的に短すぎると言うのはおそらく公平です。
Power usage cannot be evaluated based solely on lower-layer communications. The entire system, including upper-layer protocols and applications, is responsible for the power consumption as a whole. The lower communication layers have already adopted many techniques that can be used to reduce power usage, such as scheduling device wake-up times. Further reductions will likely need some cooperation from the upper layers so that unnecessary communications, denial-of-service attacks on power consumption, and other power drains are eliminated.
低層通信のみに基づいて、電力使用量を評価することはできません。上層層プロトコルやアプリケーションを含むシステム全体が、消費電力全体に責任を負います。低い通信層は、スケジューリングデバイスのモーニング時間など、電力使用量を削減するために使用できる多くの手法をすでに採用しています。不必要な通信、消費電力に関するサービス拒否攻撃、およびその他の電力排水溝が排除されるように、さらなる削減により上層からの協力が必要になる可能性があります。
Of course, application requirements ultimately determine what kinds of communications are necessary. For instance, some applications require more data to be sent than others. The purpose of the guidelines in this memo is not to prefer one or the other application, but to provide guidance on how to minimize the amount of communications overhead that is not directly required by the application. While such optimization is generally useful, it is, relatively speaking, most noticeable in applications that transfer only a small amount of data or operate only infrequently.
もちろん、アプリケーションの要件は、最終的にどのような通信が必要かを決定します。たとえば、一部のアプリケーションでは、他のアプリケーションよりも多くのデータを送信する必要があります。このメモのガイドラインの目的は、いずれかのアプリケーションを好むことではなく、アプリケーションで直接要求されていない通信オーバーヘッドの量を最小限に抑える方法に関するガイダンスを提供することです。このような最適化は一般的に有用ですが、比較的言えば、少量のデータのみを転送するか、まれにしか動作しないアプリケーションで最も顕著です。
We assume that the underlying communications network can be any large-scale, public network that employs a point-to-point communications model and radio technology. 2G, 3G, LTE, and 5G networks are examples of such networks but are not the only possible networks with these characteristics.
基礎となる通信ネットワークは、ポイントツーポイント通信モデルとラジオテクノロジーを採用する大規模なパブリックネットワークになる可能性があると想定しています。2G、3G、LTE、および5Gネットワークは、このようなネットワークの例ですが、これらの特性を持つ唯一の可能なネットワークではありません。
In the following, we look at some of these characteristics and their implications. Note that in most cases these characteristics are not properties of the specific networks but rather are inherent in the concept of public networks.
以下では、これらの特性のいくつかとその意味を見ていきます。ほとんどの場合、これらの特性は特定のネットワークのプロパティではなく、パブリックネットワークの概念に固有のものであることに注意してください。
* Public Networks
* パブリックネットワーク
Using a public network service implies that applications can be deployed without having to build a network to go with them. For economic reasons, only the largest users (such as utility companies) could afford to build their own network, and even they would not be able to provide worldwide coverage. This means that applications where coverage is important can be built. For instance, most transport-sector applications require national or even worldwide coverage to work.
パブリックネットワークサービスを使用すると、アプリケーションがネットワークを構築するために使用することなく展開できることを意味します。経済的な理由から、最大のユーザー（ユーティリティ会社など）のみが独自のネットワークを構築する余裕があり、世界中のカバレッジを提供することもできません。これは、カバレッジが重要なアプリケーションを構築できることを意味します。たとえば、ほとんどの輸送部門のアプリケーションでは、機能するために全国的または世界的なカバレッジさえ必要とします。
But there are other implications as well. By definition, the network is not tailored for this application, and, with some exceptions, the traffic passes through the Internet. One implication of this is that there are generally no application-specific network configurations or discovery support. For instance, the public network helps devices to get on the Internet, set up default routers, configure DNS servers, and so on, but does nothing for configuring possible higher-layer functions, such as servers that a device might need to contact to perform its application functions.
しかし、他の意味もあります。定義上、ネットワークはこのアプリケーションに合わせて調整されておらず、いくつかの例外を除いて、トラフィックはインターネットを通過します。これの1つの意味は、一般にアプリケーション固有のネットワーク構成や発見サポートがないことです。たとえば、パブリックネットワークは、デバイスがインターネットにアクセスしたり、デフォルトのルーターを設定したり、DNSサーバーを構成したりするなどを支援しますが、デバイスが実行するために連絡する必要があるサーバーなど、可能な高レイヤー関数を構成するためには何もしません。そのアプリケーション機能。
Public networks often provide web proxies and other functionality that can, in some cases, make significant improvements related to delays and costs of communication over the wireless link. For instance, resolving server DNS names in a proxy instead of the user's device may cut down on the general chattiness of the communications, therefore reducing overall delay in completing the entire transaction. Likewise, a CoAP proxy or Publish-Subscribe (pub/sub) Broker [CoAP-PubSub] can assist a CoAP device in communication. However, unlike HTTP web proxies, CoAP proxies and brokers are not yet widely deployed in public networks.
パブリックネットワークは、多くの場合、Webプロキシやその他の機能を提供し、場合によっては、ワイヤレスリンクを介した通信の遅延とコストに関連する大幅な改善を行うことができます。たとえば、ユーザーのデバイスではなくプロキシ内のサーバーDNS名を解決すると、通信の一般的なおしゃべりが削減されるため、トランザクション全体の完了が全体的な遅延を減らすことができます。同様に、Coap ProxyまたはPublish-Subscribe（Pub/Sub）Broker [Coap-PubSub]は、COAPデバイスの通信を支援できます。ただし、HTTP Webプロキシとは異なり、COAPプロキシとブローカーはまだパブリックネットワークに広く展開されていません。
Similarly, given the lack of available IPv4 addresses, chances are that many devices are behind a Network Address Translation (NAT) device. This means that they are not easily reachable as servers. Alternatively, the devices may be directly on the global Internet (on either IPv4 or IPv6) and easily reachable as servers. Unfortunately, this may mean that they also receive unwanted traffic, which may have implications for both power consumption and service costs.
同様に、利用可能なIPv4アドレスがないことを考えると、多くのデバイスがネットワークアドレス変換（NAT）デバイスの背後にある可能性があります。これは、サーバーとして簡単に到達できないことを意味します。あるいは、デバイスはグローバルインターネット（IPv4またはIPv6のいずれか）に直接搭載され、サーバーとして簡単にアクセスできます。残念ながら、これは彼らが不要なトラフィックも受け取ることを意味するかもしれません。これは、消費電力とサービスコストの両方に影響を与える可能性があります。
* Point-to-Point Link Model
* ポイントツーポイントリンクモデル
This is a common link model in cellular networks. One implication of this model is that there will be no other nodes on the same link, except maybe for the service provider's router. As a result, multicast discovery cannot be reasonably used for any local discovery purposes. While the configuration of the service provider's router for specific users is theoretically possible, this is difficult to achieve in practice, at least for any small user that cannot afford a network-wide contract for a private APN (Access Point Name). The public network access service has little per-user tailoring.
これは、セルラーネットワークの一般的なリンクモデルです。このモデルの意味の1つは、サービスプロバイダーのルーターを除き、同じリンクに他のノードがないことです。その結果、マルチキャストの発見は、地元の発見の目的で合理的に使用することはできません。特定のユーザー向けのサービスプロバイダーのルーターの構成は理論的に可能ですが、少なくともプライベートAPN（アクセスポイント名）のネットワーク全体の契約を購入できない小さなユーザーにとって、これは実際に達成することが困難です。パブリックネットワークアクセスサービスには、ユーザーごとの仕立てがほとんどありません。
* Radio Technology
* ラジオテクノロジー
The use of radio technology means that power is needed to operate the radios. Transmission generally requires more power than reception. However, radio protocols have generally been designed so that a device checks periodically to see whether it has messages. In a situation where messages arrive seldom or not at all, this checking consumes energy. Research has shown that these periodic checks (such as LTE paging message reception) are often a far bigger contributor to energy consumption than message transmission.
無線技術の使用は、無線を操作するために電力が必要であることを意味します。通常、トランスミッションには受信よりも多くの電力が必要です。ただし、ラジオプロトコルは通常、デバイスが定期的にチェックしてメッセージがあるかどうかを確認するように設計されています。メッセージがまったく到着するかまったく到着しない状況では、このチェックはエネルギーを消費します。調査によると、これらの定期的なチェック（LTEページングメッセージ受信など）は、メッセージ伝達よりもエネルギー消費にはるかに大きな貢献者であることが多いことが示されています。
Note that for situations where there are several applications on the same device wishing to communicate with the Internet in some manner, bundling those applications together so that they can communicate at the same time can be very useful. Some guidance for these techniques in the smartphone context can be found in [Android-Bundle].
同じデバイスにいくつかのアプリケーションがある状況では、何らかの方法でインターネットと通信したい状況では、それらが同時に通信できるようにそれらのアプリケーションを一緒にバンドルすることが非常に便利であることに注意してください。スマートフォンのコンテキストでのこれらの手法のいくつかのガイダンスは、[Android-Bundle]にあります。
Naturally, each device has the freedom to decide when it sends messages. In addition, we assume that there is some way for the devices to control when or how often they want to receive messages. Specific methods for doing this depend on the specific network being used and also tend to change as improvements in the design of these networks are incorporated. The reception control methods generally come in two variants: (1) fine-grained mechanisms that deal with how often the device needs to wake up for paging messages and (2) cruder mechanisms where the device simply disconnects from the network for a period of time. There are costs and benefits associated with each method, but those are not relevant for this memo, as long as some control method exists. Furthermore, devices could use Delay-Tolerant Networking (DTN) mechanisms [RFC4838] to relax the requirements for timeliness of connectivity and message delivery.
当然のことながら、各デバイスにはメッセージが送信されるときに自由に決定できます。さらに、デバイスがメッセージを受信する頻度、または頻度でデバイスが制御する方法があると想定しています。これを行うための特定の方法は、使用されている特定のネットワークに依存し、これらのネットワークの設計の改善が組み込まれるにつれて変化する傾向があります。受信制御方法には、一般に2つのバリエーションがあります。（1）デバイスがページングメッセージのために目覚める必要がある頻度を扱う細かいメカニズムと（2）デバイスが一定期間ネットワークから単純に切断する単純な粗いメカニズム。各方法に関連するコストと利点がありますが、一部の制御方法が存在する限り、これらはこのメモには関係ありません。さらに、デバイスは、遅延耐性ネットワーキング（DTN）メカニズム[RFC4838]を使用して、接続性とメッセージ配信の適時性の要件を緩和できます。
Not all applications or situations are equal. They may require different solutions or communication models. This memo focuses on two common scenarios in cellular networks:
すべてのアプリケーションや状況が等しいわけではありません。さまざまなソリューションまたは通信モデルが必要になる場合があります。このメモは、セルラーネットワークの2つの一般的なシナリオに焦点を当てています。
* Real-Time Reachable Devices
* リアルタイムの到達可能なデバイス
This scenario involves all communication that requires real-time or near-real-time communications with a device. That is, a network entity must be able to reach the device with a small time lag at any time, and no previously agreed-upon wake-up schedule can be arranged. By "real-time", we mean any reasonable end-to-end communications latency, be it measured in milliseconds or seconds. However, unpredictable sleep states are not expected.
このシナリオには、デバイスとのリアルタイムまたはほぼリアルタイム通信が必要なすべての通信が含まれます。つまり、ネットワークエンティティは、いつでも小さな時間遅れでデバイスに到達できる必要があり、以前に合意したモーニングスケジュールを手配することはできません。「リアルタイム」とは、ミリ秒または秒で測定されていても、合理的なエンドツーエンドの通信レイテンシを意味します。ただし、予測不可能な睡眠状態は予想されていません。
Examples of devices in this category include sensors that must be measurable from a remote source at any instant in time, such as process automation sensors and actuators that require immediate action, such as light bulbs or door locks.
このカテゴリのデバイスの例には、プロセス自動化センサーや、電球やドアロックなどの即時アクションを必要とするアクチュエーターなど、任意の瞬間にリモートソースから測定できるセンサーが含まれます。
* Sleepy Devices
* 眠そうなデバイス
This scenario involves the freedom to choose when a device communicates. The device is often expected to be able to be in a sleep state for much of its time. The device itself can choose when it communicates, or it lets the network assist in this task.
このシナリオには、デバイスが通信するときに選択する自由が含まれます。このデバイスは、多くの場合、睡眠状態に陥ることができることがよくあります。デバイス自体は、通信時期を選択するか、ネットワークがこのタスクを支援できるようにすることができます。
Examples of devices in this category include sensors that track slowly changing values, such as temperature sensors and actuators that control a relatively slow process, such as heating systems.
このカテゴリのデバイスの例には、温度センサーや加熱システムなどの比較的遅いプロセスを制御するアクチュエーターなど、ゆっくりと変化する値を追跡するセンサーが含まれます。
Note that there may be hard real-time requirements, but they are expressed in terms of how fast the device can communicate -- not in terms of how fast it can respond to network stimuli. For instance, a fire detector can be classified as a sleepy device as long as it can internally quickly wake up on detecting fire and initiate the necessary communications without delay.
リアルタイムの要件は難しいかもしれませんが、ネットワーク刺激にどれだけ速く応答できるかという点ではなく、デバイスがどれだけ速く通信できるかという点で表現されています。たとえば、火災検出器は、火災の検出を内部的に目覚めさせ、遅滞なく必要な通信を開始できる限り、眠そうなデバイスとして分類できます。
In both scenarios, the device will be attached to a public network. Without special arrangements, the device will also get a dynamically assigned IP address or an IPv6 prefix. At least one but typically several router hops separate the device from its communicating peers such as application servers. As a result, the address or even the existence of the device is typically not immediately obvious to the other nodes participating in the application. As discussed earlier, multicast discovery has limited value in public networks; network nodes cannot practically discover individual devices in a large public network. And the devices cannot discover who they need to talk to, as the public network offers just basic Internet connectivity.
両方のシナリオで、デバイスはパブリックネットワークに接続されます。特別な配置がなければ、デバイスは動的に割り当てられたIPアドレスまたはIPv6プレフィックスも取得します。少なくとも1つですが、通常、いくつかのルーターホップは、アプリケーションサーバーなどの通信ピアからデバイスを分離します。その結果、デバイスのアドレスまたは存在さえ、通常、アプリケーションに参加する他のノードに対してすぐには明らかではありません。前述のように、マルチキャストの発見は、公共ネットワークの価値が限られています。ネットワークノードは、大規模なパブリックネットワークで個々のデバイスを実際に発見することはできません。パブリックネットワークは基本的なインターネット接続を提供するため、デバイスは誰と話す必要があるかを発見することはできません。
Our recommendation is to initiate a discovery and registration process. This allows each device to inform its peers that it has connected to the network and that it is reachable at a given IP address. Registration also facilitates low-power operation, since a device can delegate part of the discovery signaling and reachability requirements to another node.
私たちの推奨事項は、発見と登録プロセスを開始することです。これにより、各デバイスは、ネットワークに接続されていること、および特定のIPアドレスで到達可能であることをピアに通知できます。また、登録は低電力操作を容易にします。これは、デバイスがディスカバリーシグナリングとリーチ可能性要件の一部を別のノードに委任できるためです。
The registration part is easy, e.g., with a resource directory. The device should perform the necessary registration with such a resource directory -- for instance, as specified in [RFC9176]. In order to do this registration, the device needs to know its Constrained RESTful Environments (CoRE) Link Format description, as specified in [RFC6690]. In essence, the registration process involves performing a GET on .well-known/core/?rt=core-rd at the address of the resource directory and then doing a POST on the path of the discovered resource.
登録部品は簡単です。たとえば、リソースディレクトリを備えています。[RFC9176]で指定されているように、このようなリソースディレクトリを使用して必要な登録を実行する必要があります。この登録を行うには、[RFC6690]で指定されているように、デバイスは制約されたRESTFUL環境（CORE）リンク形式の説明を知る必要があります。本質的に、登録プロセスでは、リソースディレクトリのアドレスで.well-known/core/？rt = core-rdでget on .well-known/core/？rt = core-rdを実行し、発見されたリソースのパスに関する投稿を行うことが含まれます。
Other mechanisms enabling device discovery and delegation of functionality to a non-sleepy node include those discussed in [CoRE-Mirror] and [CoAP-PubSub].
デバイスの発見を可能にする他のメカニズムと、スリープ状のノードへの機能の委任には、[Core-Mirror]および[Coap-Pubsub]で議論されているメカニズムが含まれます。
However, current CoAP specifications provide only limited support for discovering the resource directory or other registration services. Local multicast discovery only works in LAN-type networks; it does not work in the public cellular networks discussed in this document. We recommend the following alternate methods for discovery:
ただし、現在のCOAP仕様は、リソースディレクトリまたはその他の登録サービスを発見するための限られたサポートのみを提供します。ローカルマルチキャストディスカバリーは、LANタイプのネットワークでのみ機能します。このドキュメントで説明されているパブリックセルラーネットワークでは機能しません。発見のための次の代替方法をお勧めします。
* Manual Configuration
* 手動構成
The DNS name of the resource directory is manually configured. This approach is suitable in situations where the owner of the devices has the resources and capabilities to do the configuration. For instance, a utility company can typically program its metering devices to point to the company servers.
リソースディレクトリのDNS名は手動で構成されています。このアプローチは、デバイスの所有者が構成を行うリソースと機能を備えている状況で適しています。たとえば、ユーティリティ会社は通常、メーターデバイスをプログラムして会社サーバーを指すことができます。
* Manufacturer Server
* メーカーサーバー
The DNS name of the directory or proxy is hardwired to the software by the manufacturer, and the directory or proxy is actually run by the manufacturer. This approach is suitable in many consumer usage scenarios, where it would be unreasonable to assume that the consumer runs any specific network services. The manufacturer's web interface and the directory/proxy servers can cooperate to provide the desired functionality to the end user. For instance, the end user can register a device identity in the manufacturer's web interface and ask that specific actions be taken when the device does something.
ディレクトリまたはプロキシのDNS名は、メーカーによってソフトウェアに固執しており、ディレクトリまたはプロキシは実際にメーカーによって実行されます。このアプローチは、消費者が特定のネットワークサービスを実行していると仮定するのは不合理な多くの消費者使用シナリオに適しています。メーカーのWebインターフェイスとディレクトリ/プロキシサーバーは、エンドユーザーに目的の機能を提供するために協力できます。たとえば、エンドユーザーは、メーカーのWebインターフェイスにデバイスのIDを登録し、デバイスが何かをしたときに特定のアクションを実行することを尋ねることができます。
* Delegating Manufacturer Server
* メーカーサーバーの委任
The DNS name of the directory or proxy is hardwired to the software by the manufacturer, but this directory or proxy merely redirects the request to a directory or proxy run by whoever bought the device. This approach is suitable in many enterprise environments, as it allows the enterprise to be in charge of actual data collection and device registries; only the initial bootstrap goes through the manufacturer. In many cases, there are even legal requirements (such as EU privacy laws) that prevent providing unnecessary information to third parties.
ディレクトリまたはプロキシのDNS名はメーカーによってソフトウェアに固執していますが、このディレクトリまたはプロキシは、デバイスを購入した人が実行するディレクトリまたはプロキシにリクエストをリダイレクトするだけです。このアプローチは、企業が実際のデータ収集とデバイスレジストリを担当できるため、多くのエンタープライズ環境で適しています。最初のブートストラップのみがメーカーを通過します。多くの場合、第三者に不必要な情報を提供することを妨げる法的要件（EUプライバシー法など）さえあります。
* Common Global Resolution Infrastructure
* 一般的なグローバル解像度インフラストラクチャ
The delegating manufacturer server model could be generalized into a reverse-DNS-like discovery infrastructure that could, for example, answer the question "This is a device with identity ID 2456; where is my home registration server?" However, at present, no such resolution system exists. (Note: The EPCGlobal system for Radio Frequency Identification (RFID) resolution is reminiscent of this approach.)
委任メーカーサーバーモデルは、たとえば、「これはID 2456を持つデバイスです。家の登録サーバーはどこですか？」という質問に答えることができる逆DNSのようなディスカバリーインフラストラクチャに一般化できます。ただし、現在、そのような解像度システムは存在しません。（注：無線周波数識別（RFID）解像度のためのEPCGLOBALシステムは、このアプローチを連想させます。）
Besides manual configuration, these alternate mechanisms are mostly suitable for large manufacturers and deployments. Good automated mechanisms for discovery of devices that are manufactured and deployed in small quantities are still needed.
手動構成に加えて、これらの代替メカニズムは、大規模なメーカーと展開に主に適しています。少量で製造および展開されているデバイスを発見するための優れた自動メカニズムがまだ必要です。
A variety of data formats exist for passing around data. These data formats include XML, JavaScript Object Notation (JSON) [RFC8259], Efficient XML Interchange (EXI) [W3C.REC-exi-20140211], Concise Binary Object Representation (CBOR) [RFC8949], and various text formats. Message lengths can have a significant effect on the amount of energy required for the communications, and as such it is highly desirable to keep message lengths minimal. At the same time, extreme optimization can affect flexibility and ease of programming. The authors recommend that readers refer to [RFC8428] for a compact but easily processed and extendable format.
データを渡すためのさまざまなデータ形式が存在します。これらのデータ形式には、XML、JavaScriptオブジェクト表記（JSON）[RFC8259]、効率的なXMLインターチェンジ（EXI）[W3C.REC-EXI-20140211]、簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]、およびさまざまなテキスト形式が含まれます。メッセージの長さは、通信に必要なエネルギー量に大きな影響を与える可能性があり、そのため、メッセージの長さを最小限に抑えることが非常に望ましいです。同時に、極端な最適化は、柔軟性とプログラミングの容易さに影響を与える可能性があります。著者は、読者がコンパクトだが簡単に処理され、拡張可能な形式について[RFC8428]を参照することを推奨しています。
These devices are often best modeled as CoAP servers. The device will have limited control over when it receives messages, and it will have to listen actively for messages, up to the limits of the underlying link layer. If in some phase of its operation the device also acts in the role of a client, it can control how many transmissions it makes on its own behalf.
これらのデバイスは、多くの場合、COAPサーバーとして最もよくモデル化されています。このデバイスは、メッセージを受信する時期を制御することが制限されており、基礎となるリンクレイヤーの限界まで、メッセージを積極的に聞く必要があります。操作のある段階で、デバイスがクライアントの役割にも作用する場合、独自に行う伝達の数を制御できます。
The packet reception checks should be tailored according to the requirements of the application. If sub-second response time is not needed, a more infrequent checking process may save some power.
パケット受信チェックは、アプリケーションの要件に従って調整する必要があります。サブセカンドの応答時間が必要ない場合、より頻繁なチェックプロセスでは、いくらかのパワーを節約する可能性があります。
For sensor-type devices, the CoAP Observe extension (Observe option) [RFC7641] may be supported. This allows the sensor to track changes to the sensed value and make an immediate observation response upon a change. This may reduce the amount of polling needed to be done by the client. Unfortunately, it does not reduce the time that the device needs to be listening for requests. Subscription requests from clients other than the currently registered client may come in at any time, the current client may change its request, and the device still needs to respond to normal queries as a server. As a result, the sensor cannot rely on having to communicate only on its own choice of observation interval.
センサータイプのデバイスの場合、COAP観測拡張（Observe Option）[RFC7641]がサポートされる場合があります。これにより、センサーは検知値の変更を追跡し、変更時に即時の観察応答を行うことができます。これにより、クライアントが行うために必要なポーリングの量が減少する場合があります。残念ながら、デバイスがリクエストを聞く必要がある時間を短縮しません。現在登録されているクライアント以外のクライアントからのサブスクリプション要求は、いつでも登場する場合があり、現在のクライアントはその要求を変更する場合があり、デバイスはサーバーとして通常のクエリに応答する必要があります。その結果、センサーは、独自の選択の間隔でのみ通信する必要があることに依存することはできません。
In order to act as a server, the device needs to be placed in a public IPv4 address, be reachable over IPv6, or be hosted in a private network. If the device is hosted on a private network, then all other nodes that need to access this device also need to reside in the same private network. There are multiple ways to provide private networks over public cellular networks. One approach is to dedicate a special APN for the private network. Corporate access via cellular networks has often been arranged in this manner, for instance. Another approach is to use Virtual Private Network (VPN) technology -- for instance, IPsec-based VPNs.
サーバーとして機能するには、デバイスをパブリックIPv4アドレスに配置するか、IPv6を介して到達可能であるか、プライベートネットワークでホストする必要があります。デバイスがプライベートネットワークでホストされている場合、このデバイスにアクセスする必要がある他のすべてのノードも同じプライベートネットワークに存在する必要があります。パブリックセルラーネットワークを介してプライベートネットワークを提供する方法は複数あります。1つのアプローチは、プライベートネットワークに特別なAPNを専用することです。たとえば、セルラーネットワークを介したコーポレートアクセスは、この方法でしばしば配置されています。別のアプローチは、仮想プライベートネットワーク（VPN）テクノロジーを使用することです。たとえば、IPSECベースのVPN。
Power consumption from unwanted traffic is problematic in these devices, unless they are placed in a private network or protected by an operator-provided firewall service. Devices on an IPv6 network will be afforded some protection due to the nature of the 2^64 address allocation for a single terminal in a 3GPP cellular network; the attackers will be unable to guess the full IP address of the device. However, this protects only the device from processing a packet, but since the network will still deliver the packet to any of the addresses within the assigned 64-bit prefix, packet reception costs are still incurred.
これらのデバイスがプライベートネットワークに配置されたり、オペレーターが提供するファイアウォールサービスによって保護されたりしない限り、これらのデバイスでは不要なトラフィックからの消費電力は問題があります。IPv6ネットワーク上のデバイスは、3GPPセルラーネットワーク内の単一端子の2^64アドレス割り当ての性質のために、ある程度の保護が提供されます。攻撃者は、デバイスの完全なIPアドレスを推測できません。ただし、これによりパケットの処理からデバイスのみが保護されますが、ネットワークは割り当てられた64ビットプレフィックス内のアドレスのいずれかにパケットを配信するため、パケット受信コストは引き続き発生します。
Note that the VPN approach cannot prevent unwanted traffic received at the tunnel endpoint address and may require keep-alive traffic. Special APNs can solve this issue but require an explicit arrangement with the service provider.
VPNアプローチでは、トンネルエンドポイントアドレスで受け取った不要なトラフィックを防ぐことができず、維持用のトラフィックが必要になる場合があることに注意してください。特別なAPNはこの問題を解決できますが、サービスプロバイダーとの明示的な取り決めが必要です。
These devices are best modeled as devices that can delegate queries to some other node -- for instance, as mirror servers [CoRE-Mirror] or CoAP pub/sub Clients [CoAP-PubSub]. When the device initializes itself, it makes a registration of itself in a server or broker as described above in Section 5 and then continues to send periodic updates of sensor values.
これらのデバイスは、たとえば、ミラーサーバー[Core-Mirror]またはCoap Pub/サブクライアント[Coap-Pubsub]など、他のノードにクエリを委任できるデバイスとして最適にモデル化されています。デバイスが初期化すると、セクション5で上記のようにサーバーまたはブローカーに登録し、センサー値の定期的な更新を送信し続けます。
As a result, the device acts only as a client and not as a server, and can shut down all communication channels during its sleeping period. The length of the sleeping period depends on power and application requirements. Some environmental sensors might use a day or a week as the period, while other devices may use smaller values ranging from minutes to hours.
その結果、デバイスはクライアントとしてのみ動作し、サーバーとしてではなく、睡眠期間中にすべての通信チャネルをシャットダウンできます。睡眠期間の長さは、電力とアプリケーションの要件によって異なります。一部の環境センサーは、期間として1日または1週間を使用する場合がありますが、他のデバイスは数分から数時間の範囲の小さな値を使用する場合があります。
The ability to shut down communications and act as only a client has four impacts:
コミュニケーションをシャットダウンし、クライアントのみとして機能する能力には4つの影響があります。
* Radio transmission and reception can be turned off during the sleeping period, reducing power consumption significantly.
* 睡眠期間中に無線の送信と受信をオフにすることができ、消費電力が大幅に削減されます。
* However, some power and time are consumed by having to reattach to the network after the end of a sleep period.
* ただし、睡眠期間が終了した後、ネットワークにリタッチしなければならないことにより、いくらかのパワーと時間が消費されます。
* The window of opportunity for unwanted traffic to arrive is much smaller, as the device is listening for traffic only part of the time. Note, however, that networks may cache packets for some time. On the other hand, stateful firewalls can effectively remove much of the unwanted traffic for client-type devices.
* 不要なトラフィックが到着する機会の窓ははるかに小さく、デバイスは時間の一部しかトラフィックを聞いていません。ただし、ネットワークはしばらくの間パケットをキャッシュする場合があることに注意してください。一方、ステートフルファイアウォールは、クライアントタイプのデバイスの不要なトラフィックの多くを効果的に削除できます。
* The device may exist behind a NAT or a firewall without being impacted. Note that the "simple security" basic IPv6 firewall capability [RFC6092] blocks inbound UDP traffic by default, so just moving to IPv6 is not a direct solution to this problem.
* デバイスは、影響を受けずにNATまたはファイアウォールの後ろに存在する場合があります。「Simple Security」Basic IPv6ファイアウォール機能[RFC6092]は、デフォルトでインバウンドUDPトラフィックをブロックするため、IPv6に移動することはこの問題に対する直接的な解決策ではないことに注意してください。
For sleepy devices that represent actuators, it is also possible to use the mirror server or pub/sub broker model. A device can receive information from the server or broker about variable changes via either polling or notifications.
アクチュエーターを表す眠そうなデバイスの場合、ミラーサーバーまたはPUB/サブブローカーモデルを使用することもできます。デバイスは、投票または通知のいずれかを介して変動する変更に関する情報をサーバーまたはブローカーから受信できます。
There are several challenges related to implementing sleepy devices. They need hardware that can be placed in an appropriate sleep mode but awakened when it is time to do something again. This is not always easy in all hardware platforms. It is important to be able to shut down as much of the hardware as possible, preferably down to everything else except a clock circuit. The platform also needs to support reawakening at suitable timescales, as otherwise the device needs to be powered up too frequently.
眠そうなデバイスの実装に関連するいくつかの課題があります。適切な睡眠モードに配置できるハードウェアが必要ですが、再び何かをする時が来たら目覚めました。これは、すべてのハードウェアプラットフォームで必ずしも簡単ではありません。できるだけ多くのハードウェアをシャットダウンできることが重要です。また、プラットフォームは、適切なタイムスケールでの再確認をサポートする必要があります。そうしないと、デバイスを頻繁に電源で供給する必要があります。
Most commercial cellular modem platforms do not allow applications to suspend the state of the communications stack. Hence, after a power-off period, they need to re-establish communications, which takes some amount of time and extra energy.
ほとんどの市販のセルラーモデムプラットフォームでは、アプリケーションが通信スタックの状態を停止することを許可していません。したがって、パワーオフ期間の後、彼らはコミュニケーションを再確立する必要があります。これには、ある程度の時間と余分なエネルギーが必要です。
Implementations should have a coordinated understanding of the state and sleeping schedule. For instance, it makes no sense to keep a CPU powered up, waiting for a message when the lower layer has been told that the next possible paging opportunity is some time away.
実装には、州と睡眠スケジュールの調整された理解が必要です。たとえば、CPUの電源を維持することは意味がありません。次の可能性のあるページングの機会が少し離れていると言われたときに、メッセージを待っています。
The cellular networks have a number of adjustable configuration parameters, such as the maximum used paging interval. Proper settings of these values have an impact on the power consumption of the device, but with current business practices, such settings are rarely negotiated when the user's subscription is provisioned.
セルラーネットワークには、最大使用されたページング間隔など、いくつかの調整可能な構成パラメーターがあります。これらの値の適切な設定は、デバイスの電力消費に影響を及ぼしますが、現在のビジネス慣行では、ユーザーのサブスクリプションがプロビジョニングされている場合、そのような設定はめったに交渉されません。
There are no particular security aspects related to what has been discussed in this memo, except for the ability to delegate queries for a resource to another node. Depending on how this is done, there are obvious security issues that have largely NOT yet been addressed in the relevant Internet-Drafts [CoRE-Mirror] [CoAP-Alive] [CoAP-Publ-Monitor]. However, we point out that, in general, security issues in delegation can be solved through either reliance on your local network support nodes (which may be quite reasonable in many environments) or explicit end-to-end security. Explicit end-to-end security through nodes that are awake at different times means, in practice, end-to-end data object security. We have implemented one such mechanism for sleepy nodes as described in [RFC8387].
リソースのクエリを別のノードに委任する機能を除いて、このメモで議論されているものに関連する特定のセキュリティの側面はありません。これがどのように行われるかに応じて、関連するインターネットドラフト[Core-Mirror] [Coap-Alive] [Coap-Publ-Monitor]でほとんど対処されていない明らかなセキュリティの問題があります。ただし、一般に、委任のセキュリティ問題は、ローカルネットワークサポートノード（多くの環境で非常に合理的かもしれない）または明示的なエンドツーエンドセキュリティへの依存によって解決できることを指摘します。さまざまな時期に目覚めているノードを介した明示的なエンドツーエンドのセキュリティは、実際にはエンドツーエンドのデータオブジェクトセキュリティを意味します。[RFC8387]に記載されているように、眠そうなノードのそのようなメカニズムの1つを実装しました。
The security considerations relating to CoAP [RFC7252] and the relevant link layers should apply. Note that cellular networks universally employ per-device authentication, integrity protection, and, for most of the world, encryption of all their communications. Additional protection of transport sessions is possible through mechanisms described in [RFC7252] or data objects.
COAP [RFC7252]に関連するセキュリティ上の考慮事項と関連するリンクレイヤーが適用されるはずです。セルラーネットワークは、デバイスごとの認証、整合性保護、そして世界のほとんどですべての通信の暗号化を普遍的に採用していることに注意してください。[RFC7252]またはデータオブジェクトに記載されているメカニズムを通じて、輸送セッションの追加の保護が可能です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ed。、「JavaScriptオブジェクト表記（JSON）データインターチェンジ形式」、STD 90、RFC 8259、DOI 10.17487/RFC8259、2017年12月、<https：//www.rfc-editor.org/info/rfc8259>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690]シェルビー、Z。、「制約付き安静環境（コア）リンク形式」、RFC 6690、DOI 10.17487/RFC6690、2012年8月、<https://www.rfc-editor.org/info/rfc690>
[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、「制約付きアプリケーションプロトコル（COAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https：//www.rfc-editor。org/info/rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「制約付きアプリケーションプロトコル（COAP）のリソースの観察」、RFC 7641、DOI 10.17487/RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C。and P. Hoffman、「Concise binary Object Lepressation（CBOR）」、STD 94、RFC 8949、DOI 10.17487/RFC8949、2020年12月、<https://www.rfc-editor.org/info/RFC8949>。
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2022, <https://www.rfc-editor.org/info/rfc9176>.
[RFC9176]Amsüss、C.、ed。、Shelby、Z.、Koster、M.、Bormann、C.、およびP. van der Stok、「制約付きRestful環境（コア）リソースディレクトリ」、RFC 9176、doi 10.17487/RFC9176、2022年4月、<https://www.rfc-editor.org/info/rfc9176>。
[W3C.REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-exi-20140211, February 2014, <https://www.w3.org/TR/exi/>.
[W3C.REC-EXI-20140211] Schneider、J.、Kamiya、T.、Peintner、D。、およびR. Kyusakov、「効率的なXMLインターチェンジ（EXI）形式1.0（第2版）」-exi-20140211、2014年2月、<https://www.w3.org/tr/exi/>。
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428] Jennings、C.、Shelby、Z.、Arkko、J.、Keranen、A。、およびC. Bormann、「センサー測定リスト（SENML）」、RFC 8428、DOI 10.17487/RFC8428、2018年8月、<httpsps：//www.rfc-editor.org/info/rfc8428>。
[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。、およびA. Keranen、「制約ノードネットワークの用語」、RFC 7228、DOI 10.17487/RFC7228、2014年5月、<https://www.rfc-editor.org/info/rfc7228>。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4838] Cerf、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K。、およびH. Weiss、「遅延耐性ネットワーキングアーキテクチャ」、RFC 4838、DOI 10.17487/RFC4838、2007年4月、<https://www.rfc-editor.org/info/rfc4838>。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <https://www.rfc-editor.org/info/rfc6092>.
[RFC6092] Woodyatt、J.、ed。、「住宅IPv6インターネットサービスを提供するための顧客施設機器（CPE）の推奨される簡単なセキュリティ機能」、RFC 6092、DOI 10.17487/RFC6092、2011年1月、<https：//www.rfcc-editor.org/info/rfc6092>。
[Tiny-CoAP] Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, "Implementing Tiny COAP Sensors", Work in Progress, Internet-Draft, draft-arkko-core-sleepy-sensors-01, 5 July 2011, <https://datatracker.ietf.org/doc/html/draft-arkko-core-sleepy-sensors-01>.
[Tiny-Coap] Arkko、J.、Rissanen、H.、Loreto、S.、Turanyi、Z。、およびO. Novo、「Tiny Coapセンサーの実装」、進行中の作業、インターネットドラフト、ドラフトアークコア-Sleepy-Sensors-01、2011年7月5日、<https://datatracker.ietf.org/doc/html/draft-arkko-core-seepy-sensors-01>。
[RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387, May 2018, <https://www.rfc-editor.org/info/rfc8387>.
[RFC8387] Sethi、M.、Arkko、J.、Keranen、A。、およびH. Back、「スマートオブジェクトネットワークの保護における実用的な考慮事項と実装経験」、RFC 8387、DOI 10.17487/RFC8387、2018年5月、<HTTPS：//www.rfc-editor.org/info/rfc8387>。
[CoAP-Alive] Castellani, A. and S. Loreto, "CoAP Alive Message", Work in Progress, Internet-Draft, draft-castellani-core-alive-00, 29 March 2012, <https://datatracker.ietf.org/doc/html/ draft-castellani-core-alive-00>.
[Coap-Alive] Castellani、A。and S. Loreto、「Coap Alive Message」、Work in Progress、Internet-Draft、Draft-Castellani-Core-Alive-00、2012年3月29日、<https：//datatracker.ietf.org/doc/html/draft-castellani-core-alive-00>。
[CoAP-Publ-Monitor] Fossati, T., Giacomin, P., and S. Loreto, "Publish and Monitor Options for CoAP", Work in Progress, Internet-Draft, draft-fossati-core-publish-monitor-options-01, 10 March 2012, <https://datatracker.ietf.org/doc/html/draft-fossati-core-publish-monitor-options-01>.
[Coap-Publ-Monitor] Fossati、T.、Giacomin、P。、およびS. Loreto、「COAPのオプションを公開および監視する」、進行中の作業、インターネットドラフト、ドラフトフォッサティコアパブリッシュモニターオプション-01、2012年3月10日、<https://datatracker.ietf.org/doc/html/draft-fossati-core-publish-monitor-options-01>。
[CoRE-Mirror] Vial, M., "CoRE Mirror Server", Work in Progress, Internet-Draft, draft-vial-core-mirror-proxy-01, 13 July 2012, <https://datatracker.ietf.org/doc/html/draft-vial-core-mirror-proxy-01>.
[Core-Mirror] Vial、M。、「Core Mirror Server "、Work in Progress、Internet-Draft、Draft-Vial-Core-Mirror-Proxy-01、2012年7月13日、<https://datatracker.ietf.org/doc/html/draft-vial-core-mirror-proxy-01>。
[CoAP-PubSub] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-core-coap-pubsub-10, 4 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-10>.
[coap-pubsub] Koster、M.、Keranen、A。、およびJ. Jimenez、「制約付きアプリケーションプロトコル（COAP）の出版ブローカー」、作業中の進行、インターネットドラフト、ドラフト-ITEF-CORE-COAP-pubsub-10、2022年5月4日、<https://datatracker.ietf.org/doc/html/draft-icore-core-coap-pubsub-10>。
[Android-Bundle] "Optimize network access", Android developer note, May 2022, <https://developer.android.com/training/efficient-downloads/efficient-network-access.html>.
[Android-Bundle]「Network Accessの最適化」、Android Developer Note、2022年5月、<https://developer.android.com/training/efficient-downloads/efficient-network-access.html>。
Acknowledgments
謝辞
The authors would like to thank Zach Shelby, Jan Holler, Salvatore Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Tschofenig, and Anna Larmo for interesting discussions in this problem space.
著者は、ザック・シェルビー、ヤン・ホラー、サルヴァトーレ・ロレト、マシュー・ヴィアル、トーマス・フォッサティ、モヒト・セティ、ヤン・メレン、ヨアヒム・サックス、ハイジ・マリア・リサネン、セバスチャン・ピエレル、クマール・バラチャンドラン、ムハマド・ワカ・ミル、カレン・ヘンニン、マーク、Hannes Tschofenig、およびAnna Larmoは、この問題の分野で興味深い議論をしてくれました。
Authors' Addresses
著者のアドレス
Jari Arkko Ericsson FI-02420 Jorvas Finland Email: jari.arkko@piuha.net
Jari Arkko Ericsson FI-02420 Jorvas Finland Email：jari.arkko@piuha.net
Anders Eriksson Independent SE-164 83 Stockholm Sweden Email: anders.e.eriksson@posthem.se
Anders Eriksson Independent SE-164 83 Stockholm Swedenメール：Anders.E.eriksson@posthem.se
Ari Keränen Ericsson FI-02420 Jorvas Finland Email: ari.keranen@ericsson.com
AriKeränenEricssonFI-02420 Jorvas Finland Email：ari.keranen@ericsson.com