[要約] 要約：RFC 8376は、低消費電力広域ネットワーク（LPWAN）の概要を提供しており、LPWANの特徴、利点、および使用事例について説明しています。目的：このRFCの目的は、LPWAN技術の理解を深め、その利用可能性を広めることで、IoTデバイスやセンサーネットワークの接続性を向上させることです。
Internet Engineering Task Force (IETF) S. Farrell, Ed.
Request for Comments: 8376 Trinity College Dublin
Category: Informational May 2018
ISSN: 2070-1721
Low-Power Wide Area Network (LPWAN) Overview
低電力広域ネットワーク（LPWAN）の概要
Abstract
概要
Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.
低電力ワイドエリアネットワーク（LPWAN）は、広いカバレッジエリア、低帯域幅、場合によっては非常に小さいパケットおよびアプリケーションレイヤーのデータサイズ、長いバッテリ寿命での動作などの特徴を持つワイヤレステクノロジーです。このメモは、IETFで検討されている一連のLPWANテクノロジーの概要と、これらのテクノロジーのニーズとLPWANでIPを実行するという目標の間に存在するギャップの概要です。
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/rfc8376.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8376で入手できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LPWAN Technologies . . . . . . . . . . . . . . . . . . . . . 3
2.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Provenance and Documents . . . . . . . . . . . . . . 4
2.1.2. Characteristics . . . . . . . . . . . . . . . . . . . 4
2.2. Narrowband IoT (NB-IoT) . . . . . . . . . . . . . . . . . 10
2.2.1. Provenance and Documents . . . . . . . . . . . . . . 10
2.2.2. Characteristics . . . . . . . . . . . . . . . . . . . 11
2.3. Sigfox . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1. Provenance and Documents . . . . . . . . . . . . . . 15
2.3.2. Characteristics . . . . . . . . . . . . . . . . . . . 16
2.4. Wi-SUN Alliance Field Area Network (FAN) . . . . . . . . 20
2.4.1. Provenance and Documents . . . . . . . . . . . . . . 20
2.4.2. Characteristics . . . . . . . . . . . . . . . . . . . 21
3. Generic Terminology . . . . . . . . . . . . . . . . . . . . . 24
4. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. Naive Application of IPv6 . . . . . . . . . . . . . . . . 26
4.2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2.1. Header Compression . . . . . . . . . . . . . . . . . 27
4.2.2. Address Autoconfiguration . . . . . . . . . . . . . . 27
4.2.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 27
4.2.4. Neighbor Discovery . . . . . . . . . . . . . . . . . 28
4.3. 6lo . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4. 6tisch . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5. RoHC . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6. ROLL . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.7. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9. DNS and LPWAN . . . . . . . . . . . . . . . . . . . . . . 31
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Informative References . . . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 43
This document provides background material and an overview of the technologies being considered in the IETF's IPv6 over Low Power Wide-Area Networks (LPWAN) Working Group (WG). It also provides a gap analysis between the needs of these technologies and currently available IETF specifications.
このドキュメントでは、IETFのIPv6 over Low Power Wide-Area Networks（LPWAN）Working Group（WG）で検討されている技術の背景資料と概要について説明します。また、これらのテクノロジーのニーズと現在利用可能なIETF仕様の間のギャップ分析も提供します。
Most technologies in this space aim for a similar goal of supporting large numbers of very low-cost, low-throughput devices with very low power consumption, so that even battery-powered devices can be deployed for years. LPWAN devices also tend to be constrained in their use of bandwidth, for example, with limited frequencies being allowed to be used within limited duty cycles (usually expressed as a percentage of time per hour that the device is allowed to transmit). As the name implies, coverage of large areas is also a common goal. So, by and large, the different technologies aim for deployment in very similar circumstances.
この分野のほとんどのテクノロジーは、非常に低消費電力で非常に低コスト、低スループットのデバイスを多数サポートするという同様の目標を目指しているため、バッテリ駆動のデバイスでさえ何年も配備できます。 LPWANデバイスは、たとえば、限られた周波数が限られたデューティサイクル（通常、デバイスが送信を許可する時間あたりの時間のパーセンテージとして表される）内での使用を許可されるなど、帯域幅の使用に制約される傾向があります。名前が示すように、広い領域をカバーすることも一般的な目標です。したがって、概して、さまざまなテクノロジーは非常に類似した状況での展開を目的としています。
While all constrained networks must balance power consumption / battery life, cost, and bandwidth, LPWANs prioritize power and cost benefits by accepting severe bandwidth and duty cycle constraints when making the required trade-offs. This prioritization is made in order to get the multiple-kilometer radio links implied by "Wide Area" in LPWAN's name.
制約のあるすべてのネットワークは電力消費/バッテリー寿命、コスト、および帯域幅のバランスをとる必要がありますが、LPWANは必要なトレードオフを行うときに厳しい帯域幅とデューティサイクルの制約を受け入れることにより、電力とコストの利点を優先します。この優先順位付けは、LPWANの名前の「広域」によって示される複数キロメートルの無線リンクを取得するために行われます。
Existing pilot deployments have shown huge potential and created much industrial interest in these technologies. At the time of writing, essentially no LPWAN end devices (other than for Wi-SUN) have IP capabilities. Connecting LPWANs to the Internet would provide significant benefits to these networks in terms of interoperability, application deployment, and management (among others). The goal of the LPWAN WG is to, where necessary, adapt IETF-defined protocols, addressing schemes, and naming conventions to this particular constrained environment.
既存のパイロット展開は大きな可能性を示しており、これらのテクノロジーに対する多くの産業的関心を生み出しています。執筆時点では、IP機能を持つLPWANエンドデバイス（Wi-SUN以外のデバイス）は基本的にありません。 LPWANをインターネットに接続すると、相互運用性、アプリケーションの展開、および管理（特に）に関して、これらのネットワークに大きな利点がもたらされます。 LPWAN WGの目標は、必要に応じて、IETF定義のプロトコル、アドレス指定スキーム、および命名規則をこの特定の制約された環境に適合させることです。
This document is largely the work of the people listed in the Contributors section.
このドキュメントは、主に「貢献者」セクションにリストされている人々の作業です。
This section provides an overview of the set of LPWAN technologies that are being considered in the LPWAN WG. The text for each was mainly contributed by proponents of each technology.
このセクションでは、LPWAN WGで検討されている一連のLPWANテクノロジーの概要を説明します。それぞれのテキストは、主に各テクノロジーの支持者によって寄稿されました。
Note that this text is not intended to be normative in any sense; it simply exists to help the reader in finding the relevant Layer 2 (L2) specifications and in understanding how those integrate with IETF-defined technologies. Similarly, there is no attempt here to set out the pros and cons of the relevant technologies.
このテキストは、いかなる意味でも規範的であることを意図していないことに注意してください。これは単に、関連するレイヤー2（L2）仕様を見つけ、それらがIETF定義のテクノロジーとどのように統合されるかを理解するのに役立つように存在しています。同様に、関連する技術の長所と短所をここに示す試みはありません。
LoRaWAN is a wireless technology based on Industrial, Scientific, and Medical (ISM) that is used for long-range low-power low-data-rate applications developed by the LoRa Alliance, a membership consortium <https://www.lora-alliance.org/>. This document is based on Version 1.0.2 of the LoRa specification [LoRaSpec]. That specification is publicly available and has already seen several deployments across the globe.
LoRaWANは、メンバーシップコンソーシアムであるLoRa Allianceが開発した長距離低電力低データレートアプリケーションに使用される産業、科学、医療（ISM）に基づくワイヤレステクノロジーです。<https：//www.lora- alliance.org/>。このドキュメントは、LoRa仕様のバージョン1.0.2 [LoRaSpec]に基づいています。その仕様は公開されており、すでに世界中でいくつかの展開が見られます。
LoRaWAN aims to support end devices operating on a single battery for an extended period of time (e.g., 10 years or more), extended coverage through 155 dB maximum coupling loss, and reliable and efficient file download (as needed for remote software/firmware upgrade).
LoRaWANは、単一のバッテリで長時間（たとえば、10年以上）動作するエンドデバイス、155 dBの最大結合損失による拡張カバレッジ、および信頼性の高い効率的なファイルダウンロード（リモートソフトウェア/ファームウェアのアップグレードに必要な場合）をサポートすることを目的としています）。
LoRaWAN networks are typically organized in a star-of-stars topology in which Gateways relay messages between end devices and a central "network server" in the backend. Gateways are connected to the network server via IP links while end devices use single-hop LoRaWAN communication that can be received at one or more Gateways. Communication is generally bidirectional; uplink communication from end devices to the network server is favored in terms of overall bandwidth availability.
LoRaWANネットワークは通常、スター型のトポロジで構成され、ゲートウェイはエンドデバイスとバックエンドの中央「ネットワークサーバー」の間でメッセージを中継します。ゲートウェイはIPリンクを介してネットワークサーバーに接続され、エンドデバイスは1つ以上のゲートウェイで受信できるシングルホップLoRaWAN通信を使用します。通信は通常双方向です。全体的な帯域幅の可用性の観点から、エンドデバイスからネットワークサーバーへのアップリンク通信が優先されます。
Figure 1 shows the entities involved in a LoRaWAN network.
図1は、LoRaWANネットワークに関係するエンティティを示しています。
+----------+
|End Device| * * *
+----------+ * +---------+
* | Gateway +---+
+----------+ * +---------+ | +---------+
|End Device| * * * +---+ Network +--- Application
+----------+ * | | Server |
* +---------+ | +---------+
+----------+ * | Gateway +---+
|End Device| * * * * +---------+
+----------+
Key: * LoRaWAN Radio
+---+ IP connectivity
Figure 1: LoRaWAN Architecture
図1：LoRaWANアーキテクチャ
o End Device: a LoRa client device, sometimes called a "mote". Communicates with Gateways.
o エンドデバイス：LoRaクライアントデバイス。「モート」と呼ばれることもあります。ゲートウェイと通信します。
o Gateway: a radio on the infrastructure side, sometimes called a "concentrator" or "base station". Communicates with end devices and, via IP, with a network server.
o ゲートウェイ：インフラストラクチャ側の無線。「コンセントレータ」または「基地局」と呼ばれることもあります。エンドデバイスと通信し、IPを介してネットワークサーバーと通信します。
o Network Server: The Network Server (NS) terminates the LoRaWAN Medium Access Control (MAC) layer for the end devices connected to the network. It is the center of the star topology.
o ネットワークサーバー：ネットワークサーバー（NS）は、ネットワークに接続されたエンドデバイスのLoRaWANミディアムアクセスコントロール（MAC）レイヤーを終端します。スター型トポロジーの中心です。
o Join Server: The Join Server (JS) is a server on the Internet side of an NS that processes join requests from an end devices.
o 参加サーバー：参加サーバー（JS）は、エンドデバイスからの参加要求を処理するNSのインターネット側のサーバーです。
o Uplink message: refers to communications from an end device to a network server or application via one or more Gateways.
o アップリンクメッセージ：1つ以上のゲートウェイを介したエンドデバイスからネットワークサーバーまたはアプリケーションへの通信を指します。
o Downlink message: refers to communications from a network server or application via one Gateway to a single end device or a group of end devices (considering multicasting).
o ダウンリンクメッセージ：1つのゲートウェイを介してネットワークサーバーまたはアプリケーションから単一のエンドデバイスまたはエンドデバイスのグループ（マルチキャストを考慮）への通信を指します。
o Application: refers to application-layer code both on the end device and running "behind" the NS. For LoRaWAN, there will generally only be one application running on most end devices. Interfaces between the NS and the application are not further described here.
o アプリケーション：エンドデバイス上およびNSの「背後」で実行されているアプリケーションレイヤーコードを指します。 LoRaWANの場合、通常、ほとんどのエンドデバイスで実行されるアプリケーションは1つだけです。 NSとアプリケーション間のインターフェースについては、ここでは詳しく説明しません。
In LoRaWAN networks, end device transmissions may be received at multiple Gateways, so, during nominal operation, a network server may see multiple instances of the same uplink message from an end device.
LoRaWANネットワークでは、エンドデバイスの送信が複数のゲートウェイで受信される可能性があるため、通常の動作中に、ネットワークサーバーはエンドデバイスからの同じアップリンクメッセージの複数のインスタンスを確認できます。
The LoRaWAN network infrastructure manages the data rate and Radio Frequency (RF) output power for each end device individually by means of an Adaptive Data Rate (ADR) scheme. End devices may transmit on any channel allowed by local regulation at any time.
LoRaWANネットワークインフラストラクチャは、適応データレート（ADR）スキームを使用して、各エンドデバイスのデータレートと無線周波数（RF）出力電力を個別に管理します。エンドデバイスは、ローカル規制で許可されている任意のチャネルでいつでも送信できます。
LoRaWAN radios make use of ISM bands, for example, 433 MHz and 868 MHz within the European Union and 915 MHz in the Americas.
LoRaWAN無線は、ISM帯域を使用します。たとえば、EUでは433 MHzと868 MHz、南北アメリカでは915 MHzです。
The end device changes channels in a pseudorandom fashion for every transmission to help make the system more robust to interference and/ or to conform to local regulations.
エンドデバイスは、送信ごとに疑似ランダムな方法でチャネルを変更して、システムの干渉に対する耐性を高めたり、地域の規制に準拠したりできるようにします。
Figure 2 shows that after a transmission slot, a Class A device turns on its receiver for two short receive windows that are offset from the end of the transmission window. End devices can only transmit a subsequent uplink frame after the end of the associated receive windows. When a device joins a LoRaWAN network, there are similar timeouts on parts of that process.
図2は、送信スロットの後、クラスAのデバイスが、送信ウィンドウの端からオフセットされた2つの短い受信ウィンドウの受信機をオンにすることを示しています。エンドデバイスは、関連する受信ウィンドウの終了後にのみ、後続のアップリンクフレームを送信できます。デバイスがLoRaWANネットワークに参加すると、そのプロセスの一部で同様のタイムアウトが発生します。
|----------------------------| |--------| |--------|
| Tx | | Rx | | Rx |
|----------------------------| |--------| |--------|
|---------|
Rx delay 1
|------------------------|
Rx delay 2
Figure 2: LoRaWAN Class A Transmission and Reception Window
図2：LoRaWANクラスA送受信ウィンドウ
Given the different regional requirements, the detailed specification for the LoRaWAN Physical layer (PHY) (taking up more than 30 pages of the specification) is not reproduced here. Instead, and mainly to illustrate the kinds of issue encountered, Table 1 presents some of the default settings for one ISM band (without fully explaining those here); Table 2 describes maxima and minima for some parameters of interest to those defining ways to use IETF protocols over the LoRaWAN MAC layer.
地域の要件が異なるため、LoRaWAN物理層（PHY）の詳細な仕様（仕様の30ページ以上を占める）は、ここでは再現されません。代わりに、主に発生する問題の種類を説明するために、表1は1つのISM帯域のデフォルト設定の一部を示しています（ここではそれらを完全に説明していません）。表2は、LoRaWAN MACレイヤーでIETFプロトコルを使用する方法を定義するパラメーターに関係するいくつかのパラメーターの最大値と最小値を示しています。
+-----------------------+-------------------------------------------+
| Parameters | Default Value |
+-----------------------+-------------------------------------------+
| Rx delay 1 | 1 s |
| | |
| Rx delay 2 | 2 s (must be RECEIVE_DELAY1 + 1 s) |
| | |
| join delay 1 | 5 s |
| | |
| join delay 2 | 6 s |
| | |
| 868MHz Default | 3 (868.1,868.2,868.3), data rate: 0.3-50 |
| channels | kbit/s |
+-----------------------+-------------------------------------------+
Table 1: Default Settings for EU 868 MHz Band
表1：EU 868 MHz帯域のデフォルト設定
+------------------------------------------------+--------+---------+
| Parameter/Notes | Min | Max |
+------------------------------------------------+--------+---------+
| Duty Cycle: some but not all ISM bands impose | 1% | no |
| a limit in terms of how often an end device | | limit |
| can transmit. In some cases, LoRaWAN is more | | |
| restrictive in an attempt to avoid congestion. | | |
| | | |
| EU 868 MHz band data rate/frame size | 250 | 50000 |
| | bits/s | bits/s |
| | : 59 | : 250 |
| | octets | octets |
| | | |
| US 915 MHz band data rate/frame size | 980 | 21900 |
| | bits/s | bits/s |
| | : 19 | : 250 |
| | octets | octets |
+------------------------------------------------+--------+---------+
Table 2: Minima and Maxima for Various LoRaWAN Parameters
表2：さまざまなLoRaWANパラメータの最小値と最大値
Note that, in the case of the smallest frame size (19 octets), 8 octets are required for LoRa MAC layer headers, leaving only 11 octets for payload (including MAC layer options). However, those settings do not apply for the join procedure -- end devices are required to use a channel and data rate that can send the 23-byte Join-Request message for the join procedure.
最小フレームサイズ（19オクテット）の場合、LoRa MACレイヤーヘッダーには8オクテットが必要であり、ペイロード（MACレイヤーオプションを含む）には11オクテットのみが残ることに注意してください。ただし、これらの設定は参加手順には適用されません。エンドデバイスは、参加手順の23バイトのJoin-Requestメッセージを送信できるチャネルとデータレートを使用する必要があります。
Uplink and downlink higher-layer data is carried in a MACPayload. There is a concept of "ports" (an optional 8-bit value) to handle different applications on an end device. Port zero is reserved for LoRaWAN-specific messaging, such as the configuration of the end device's network parameters (available channels, data rates, ADR parameters, Rx Delay 1 and 2, etc.).
アップリンクおよびダウンリンクの上位層データは、MACPayloadで伝送されます。エンドデバイスでさまざまなアプリケーションを処理するための「ポート」（オプションの8ビット値）の概念があります。ポート0は、エンドデバイスのネットワークパラメータ（使用可能なチャネル、データレート、ADRパラメータ、Rx遅延1および2など）の構成など、LoRaWAN固有のメッセージング用に予約されています。
In addition to carrying higher-layer PDUs, there are Join-Request and Join-Response (aka Join-Accept) messages for handling network access. And so-called "MAC commands" (see below) up to 15 bytes long can be piggybacked in an options field ("FOpts").
上位層のPDUに加えて、ネットワークアクセスを処理するためのJoin-RequestおよびJoin-Response（別名Join-Accept）メッセージがあります。また、いわゆる「MACコマンド」（下記参照）は、オプションフィールド（「FOpts」）で最大15バイトまでピギーバックできます。
There are a number of MAC commands for link and device status checking, ADR and duty cycle negotiation, and managing the RX windows and radio channel settings. For example, the link check response message allows the NS (in response to a request from an end device) to inform an end device about the signal attenuation seen most recently at a Gateway and to tell the end device how many Gateways received the corresponding link request MAC command.
リンクとデバイスのステータスチェック、ADRとデューティサイクルのネゴシエーション、RXウィンドウと無線チャネル設定の管理のためのMACコマンドがいくつかあります。たとえば、リンクチェック応答メッセージにより、NSは（エンドデバイスからの要求に応じて）ゲートウェイで最後に見られた信号減衰についてエンドデバイスに通知し、対応するリンクを受信したゲートウェイの数をエンドデバイスに通知できます。 MACコマンドを要求します。
Some MAC commands are initiated by the network server. For example, one command allows the network server to ask an end device to reduce its duty cycle to only use a proportion of the maximum allowed in a region. Another allows the network server to query the end device's power status with the response from the end device specifying whether it has an external power source or is battery powered (in which case, a relative battery level is also sent to the network server).
一部のMACコマンドは、ネットワークサーバーによって開始されます。たとえば、1つのコマンドで、ネットワークサーバーはエンドデバイスにデューティサイクルを減らして、リージョンで許可されている最大値の割合のみを使用するように要求できます。もう1つは、ネットワークサーバーがエンドデバイスからの電源ステータスをクエリすることを可能にします。エンドデバイスからの応答は、外部電源を備えているか、またはバッテリー駆動ですか（この場合、相対的なバッテリーレベルもネットワークサーバーに送信されます）。
In order to operate nominally on a LoRaWAN network, a device needs a 32-bit device address, which is assigned when the device "joins" the network (see below for the join procedure) or that is pre-provisioned into the device. In case of roaming devices, the device address is assigned based on the 24-bit network identifier (NetID) that is allocated to the network by the LoRa Alliance. Non-roaming devices can be assigned device addresses by the network without relying on a NetID assigned by the LoRa Alliance.
LoRaWANネットワークで名目上動作するためには、デバイスが32ビットのデバイスアドレスを必要とします。これは、デバイスがネットワークに「参加」したときに割り当てられる（参加手順については以下を参照）、またはデバイスに事前プロビジョニングされています。ローミングデバイスの場合、デバイスアドレスは、LoRa Allianceによってネットワークに割り当てられた24ビットのネットワーク識別子（NetID）に基づいて割り当てられます。非ローミングデバイスは、LoRa Allianceによって割り当てられたNetIDに依存することなく、ネットワークによってデバイスアドレスを割り当てることができます。
End devices are assumed to work with one or quite a limited number of applications, identified by a 64-bit AppEUI, which is assumed to be a registered IEEE EUI64 value [EUI64]. In addition, a device needs to have two symmetric session keys, one for protecting network artifacts (port=0), the NwkSKey, and another for protecting application-layer traffic, the AppSKey. Both keys are used for 128-bit AES cryptographic operations. So, one option is for an end device to have all of the above plus channel information, somehow (pre-)provisioned; in that case, the end device can simply start transmitting. This is achievable in many cases via out-of-band means given the nature of LoRaWAN networks. Table 3 summarizes these values.
エンドデバイスは、64ビットAppEUIによって識別される1つまたは非常に限られた数のアプリケーションで動作すると想定されています。これは、登録済みのIEEE EUI64値[EUI64]であると想定されています。さらに、デバイスには2つの対称セッションキーが必要です。1つはネットワークアーティファクト（port = 0）を保護するためのNwkSKey、もう1つはアプリケーションレイヤートラフィックを保護するためのAppSKeyです。両方のキーは、128ビットのAES暗号化操作に使用されます。したがって、1つのオプションは、エンドデバイスが上記のすべてとチャネル情報を何らかの方法で（事前に）プロビジョニングすることです。その場合、エンドデバイスは単に送信を開始できます。これは多くの場合、LoRaWANネットワークの性質上、帯域外手段を介して実現できます。表3に、これらの値を要約します。
+---------+---------------------------------------------------------+
| Value | Description |
+---------+---------------------------------------------------------+
| DevAddr | DevAddr (32 bits) = device-specific network address |
| | generated from the NetID |
| | |
| AppEUI | IEEE EUI64 value corresponding to the join server for |
| | an application |
| | |
| NwkSKey | 128-bit network session key used with AES-CMAC |
| | |
| AppSKey | 128-bit application session key used with AES-CTR |
| | |
| AppKey | 128-bit application session key used with AES-ECB |
+---------+---------------------------------------------------------+
Table 3: Values Required for Nominal Operation
表3：公称操作に必要な値
As an alternative, end devices can use the LoRaWAN join procedure with a join server behind the NS in order to set up some of these values and dynamically gain access to the network. To use the join procedure, an end device must still know the AppEUI and a different (long-term) symmetric key that is bound to the AppEUI (this is the application key (AppKey), and it is distinct from the application session key (AppSKey)). The AppKey is required to be specific to the device; that is, each end device should have a different AppKey value. Finally, the end device also needs a long-term identifier for itself, which is syntactically also an EUI-64 and is known as the device EUI or DevEUI. Table 4 summarizes these values.
別の方法として、エンドデバイスは、NSの背後にある結合サーバーでLoRaWAN結合手順を使用して、これらの値のいくつかを設定し、ネットワークに動的にアクセスできます。結合手順を使用するには、エンドデバイスは、AppEUIと、AppEUIにバインドされている別の（長期）対称キー（アプリケーションキー（AppKey）であり、アプリケーションセッションキーとは異なる（ AppSKey））。 AppKeyはデバイスに固有である必要があります。つまり、各エンドデバイスには異なるAppKey値が必要です。最後に、エンドデバイスにも長期的な識別子が必要です。これは構文的にもEUI-64であり、デバイスEUIまたはDevEUIとして知られています。表4は、これらの値を要約したものです。
+---------+----------------------------------------------------+
| Value | Description |
+---------+----------------------------------------------------+
| DevEUI | IEEE EUI64 naming the device |
| | |
| AppEUI | IEEE EUI64 naming the application |
| | |
| AppKey | 128-bit long-term application key for use with AES |
+---------+----------------------------------------------------+
Table 4: Values Required for Join Procedure
表4：結合手順に必要な値
The join procedure involves a special exchange where the end device asserts the AppEUI and DevEUI (integrity protected with the long-term AppKey, but not encrypted) in a Join-Request uplink message. This is then routed to the network server, which interacts with an entity that knows that AppKey to verify the Join-Request. If all is going well, a Join-Accept downlink message is returned from the network server to the end device. That message specifies the 24-bit NetID, 32-bit DevAddr, and channel information and from which the AppSKey and NwkSKey can be derived based on knowledge of the AppKey. This provides the end device with all the values listed in Table 3.
参加手順には、エンドデバイスがJoin-RequestアップリンクメッセージでAppEUIとDevEUI（長期間のAppKeyで保護されているが暗号化されていない完全性）をアサートする特別な交換が含まれます。次に、これはネットワークサーバーにルーティングされます。ネットワークサーバーは、そのAppKeyを知っているエンティティと対話して、Join-Requestを確認します。すべてが順調であれば、Join-Acceptダウンリンクメッセージがネットワークサーバーからエンドデバイスに返されます。このメッセージは、24ビットのNetID、32ビットのDevAddr、およびチャネル情報を指定し、AppKeyの知識に基づいてAppSKeyおよびNwkSKeyをそこから導き出すことができます。これにより、表3にリストされているすべての値がエンドデバイスに提供されます。
All payloads are encrypted and have data integrity. MAC commands, when sent as a payload (port zero), are therefore protected. However, MAC commands piggybacked as frame options ("FOpts") are sent in clear. Any MAC commands sent as frame options and not only as payload, are visible to a passive attacker, but they are not malleable for an active attacker due to the use of the Message Integrity Check (MIC) described below.
すべてのペイロードは暗号化されており、データの整合性があります。したがって、MACコマンドは、ペイロード（ポート0）として送信されると保護されます。ただし、フレームオプションとしてピギーバックされたMACコマンド（「FOpts」）はクリアテキストで送信されます。ペイロードとしてだけでなく、フレームオプションとして送信されたMACコマンドは、パッシブな攻撃者に表示されますが、以下に説明するメッセージ整合性チェック（MIC）を使用しているため、アクティブな攻撃者には適合しません。
For LoRaWAN version 1.0.x, the NwkSKey session key is used to provide data integrity between the end device and the network server. The AppSKey is used to provide data confidentiality between the end device and network server, or to the application "behind" the network server, depending on the implementation of the network.
LoRaWANバージョン1.0.xの場合、NwkSKeyセッションキーを使用して、エンドデバイスとネットワークサーバー間のデータ整合性を提供します。 AppSKeyは、ネットワークの実装に応じて、エンドデバイスとネットワークサーバー間、またはネットワークサーバーの「背後にある」アプリケーションにデータの機密性を提供するために使用されます。
All MAC-layer messages have an outer 32-bit MIC calculated using AES-CMAC with the input being the ciphertext payload and other headers and using the NwkSkey. Payloads are encrypted using AES-128, with a counter-mode derived from [IEEE.802.15.4] using the AppSKey. Gateways are not expected to be provided with the AppSKey or NwkSKey, all of the infrastructure-side cryptography happens in (or "behind") the network server. When session keys are derived from the AppKey as a result of the join procedure, the Join-Accept message payload is specially handled.
すべてのMAC層メッセージには、AES-CMACを使用して計算された外部32ビットMICがあり、入力は暗号文ペイロードとその他のヘッダーであり、NwkSkeyを使用します。ペイロードはAES-128を使用して暗号化され、カウンターモードは[IEEE.802.15.4]から派生したAppSKeyを使用します。ゲートウェイにAppSKeyまたはNwkSKeyが提供されることは想定されていません。インフラストラクチャ側の暗号化はすべてネットワークサーバー内（または「背後」）で行われます。結合手順の結果としてセッションキーがAppKeyから派生した場合、Join-Acceptメッセージペイロードは特別に処理されます。
The long-term AppKey is directly used to protect the Join-Accept message content, but the function used is not an AES-encrypt operation, but rather an AES-decrypt operation. The justification is that this means that the end device only needs to implement the AES-encrypt operation. (The counter-mode variant used for payload decryption means the end device doesn't need an AES-decrypt primitive.)
長期間のAppKeyは、Join-Acceptメッセージの内容を保護するために直接使用されますが、使用される機能はAES暗号化操作ではなく、AES復号操作です。これは、エンドデバイスがAES暗号化操作を実装するだけでよいことを意味します。 （ペイロードの復号化に使用されるカウンターモードのバリアントは、エンドデバイスがAES復号化プリミティブを必要としないことを意味します。）
The Join-Accept plaintext is always less than 16 bytes long, so Electronic Code Book (ECB) mode is used for protecting Join-Accept messages. The Join-Accept message contains an AppNonce (a 24-bit value) that is recovered on the end device along with the other Join-Accept content (e.g., DevAddr) using the AES-encrypt operation. Once the Join-Accept payload is available to the end device, the session keys are derived from the AppKey, AppNonce, and other values, again using an ECB mode AES-encrypt operation, with the plaintext input being a maximum of 16 octets.
Join-Acceptプレーンテキストは常に16バイト未満の長さであるため、Join-Acceptメッセージの保護にはElectronic Code Book（ECB）モードが使用されます。 Join-Acceptメッセージには、AES暗号化操作を使用して他のJoin-Acceptコンテンツ（DevAddrなど）とともにエンドデバイスで回復されるAppNonce（24ビット値）が含まれています。 Join-Acceptペイロードがエンドデバイスで使用可能になると、セッションキーはAppKey、AppNonce、およびその他の値から導出され、再びECBモードのAES暗号化操作を使用して、プレーンテキスト入力が最大16オクテットになります。
Narrowband Internet of Things (NB-IoT) has been developed and standardized by 3GPP. The standardization of NB-IoT was finalized with 3GPP Release 13 in June 2016, and further enhancements for NB-IoT are specified in 3GPP Release 14 in 2017 (for example, in the form of multicast support). Further features and improvements will be developed in the following releases, but NB-IoT has been ready to be deployed since 2016; it is rather simple to deploy, especially in the existing LTE networks with a software upgrade in the operator's base stations. For more information of what has been specified for NB-IoT, 3GPP specification 36.300 [TGPP36300] provides an overview and overall description of the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) radio interface protocol architecture, while specifications 36.321 [TGPP36321], 36.322 [TGPP36322], 36.323 [TGPP36323], and 36.331 [TGPP36331] give more detailed descriptions
狭帯域モノのインターネット（NB-IoT）は、3GPPによって開発および標準化されています。 NB-IoTの標準化は2016年6月の3GPPリリース13で完了し、NB-IoTのさらなる機能強化は2017年の3GPPリリース14で指定されています（たとえば、マルチキャストサポートの形式で）。さらなる機能と改善は次のリリースで開発される予定ですが、NB-IoTは2016年から展開する準備が整っています。特に、事業者の基地局でソフトウェアをアップグレードする既存のLTEネットワークでは、導入がかなり簡単です。 NB-IoTの仕様の詳細については、3GPP仕様36.300 [TGPP36300]でEvolved Universal Terrestrial Radio Access Network（E-UTRAN）無線インターフェースプロトコルアーキテクチャの概要と全体的な説明を提供し、仕様36.321 [TGPP36321]では、 36.322 [TGPP36322]、36.323 [TGPP36323]、および36.331 [TGPP36331]は、より詳細な説明を提供します
of MAC, Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and Radio Resource Control (RRC) protocol layers, respectively. Note that the description below assumes familiarity with numerous 3GPP terms.
MAC、無線リンク制御（RLC）、パケットデータ収束プロトコル（PDCP）、および無線リソース制御（RRC）プロトコル層のそれぞれ。以下の説明は、多数の3GPP用語に精通していることを前提としています。
For a general overview of NB-IoT, see [nbiot-ov].
NB-IoTの一般的な概要については、[nbiot-ov]を参照してください。
Specific targets for NB-IoT include: module cost that is Less than US $5, extended coverage of 164 dB maximum coupling loss, battery life of over 10 years, ~55000 devices per cell, and uplink reporting latency of less than 10 seconds.
NB-IoTの具体的な目標には、5ドル未満のモジュールコスト、最大結合損失164 dBの拡張カバレッジ、10年を超えるバッテリー寿命、セルあたり最大55000デバイス、および10秒未満のアップリンクレポート遅延があります。
NB-IoT supports Half Duplex Frequency Division Duplex (FDD) operation mode with 60 kbit/s peak rate in uplink and 30 kbit/s peak rate in downlink, and a Maximum Transmission Unit (MTU) size of 1600 bytes, limited by PDCP layer (see Figure 4 for the protocol structure), which is the highest layer in the user plane, as explained later. Any packet size up to the said MTU size can be passed to the NB-IoT stack from higher layers, segmentation of the packet is performed in the RLC layer, which can segment the data to transmission blocks with a size as small as 16 bits. As the name suggests, NB-IoT uses narrowbands with bandwidth of 180 kHz in both downlink and uplink. The multiple access scheme used in the downlink is Orthogonal Frequency-Division Multiplex (OFDMA) with 15 kHz sub-carrier spacing. In uplink, Sub-Carrier Frequency-Division Multiplex (SC-FDMA) single tone with either 15kHz or 3.75 kHz tone spacing is used, or optionally multi-tone SC-FDMA can be used with 15 kHz tone spacing.
NB-IoTは、半二重周波数分割二重（FDD）動作モードをサポートします。アップリンクでは60 kbit / sピークレート、ダウンリンクでは30 kbit / sピークレート、PDCPレイヤーによって制限される最大伝送ユニット（MTU）サイズは1600バイトです。 （プロトコル構造については、図4を参照）。これは、後で説明するように、ユーザープレーンの最上位層です。上記のMTUサイズまでの任意のパケットサイズを上位レイヤーからNB-IoTスタックに渡すことができます。パケットのセグメント化はRLCレイヤーで実行され、データを16ビット程度のサイズの送信ブロックにセグメント化できます。名前が示すように、NB-IoTはダウンリンクとアップリンクの両方で帯域幅180 kHzの狭帯域を使用します。ダウンリンクで使用される多元接続方式は、15 kHzサブキャリア間隔の直交周波数分割多重（OFDMA）です。アップリンクでは、15 kHzまたは3.75 kHzのトーン間隔のサブキャリア周波数分割多重（SC-FDMA）シングルトーンが使用されます。または、オプションでマルチトーンのSC-FDMAを15 kHzのトーン間隔で使用できます。
NB-IoT can be deployed in three ways. In-band deployment means that the narrowband is deployed inside the LTE band and radio resources are flexibly shared between NB-IoT and normal LTE carrier. In Guard-band deployment, the narrowband uses the unused resource blocks between two adjacent LTE carriers. Standalone deployment is also supported, where the narrowband can be located alone in dedicated spectrum, which makes it possible, for example, to reframe a GSM carrier at 850/900 MHz for NB-IoT. All three deployment modes are used in licensed frequency bands. The maximum transmission power is either 20 or 23 dBm for uplink transmissions, while for downlink transmission the eNodeB may use higher transmission power, up to 46 dBm depending on the deployment.
NB-IoTは3つの方法で展開できます。帯域内配備とは、狭帯域がLTE帯域内に配備され、無線リソースがNB-IoTと通常のLTEキャリアの間で柔軟に共有されることを意味します。ガードバンド展開では、ナローバンドは2つの隣接するLTEキャリア間の未使用のリソースブロックを使用します。スタンドアロン展開もサポートされており、狭帯域を専用スペクトル内に単独で配置できるため、たとえば、NB-IoTのGSMキャリアを850/900 MHzでリフレームできます。 3つの展開モードはすべて、認可された周波数帯で使用されます。最大送信電力は、アップリンク送信の場合は20または23 dBmですが、ダウンリンク送信の場合、eNodeBは展開に応じて最大46 dBmのより高い送信電力を使用できます。
A Maximum Coupling Loss (MCL) target for NB-IoT coverage enhancements defined by 3GPP is 164 dB. With this MCL, the performance of NB-IoT in downlink varies between 200 bps and 2-3 kbit/s, depending on the deployment mode. Stand-alone operation may achieve the highest data rates, up to a few kbit/s, while in-band and guard-band operations may reach several hundreds of bps. NB-IoT may even operate with an MCL higher than 170 dB with very low bit rates.
3GPPで定義されたNB-IoTカバレッジ拡張の最大結合損失（MCL）ターゲットは164 dBです。このMCLを使用すると、ダウンリンクでのNB-IoTのパフォーマンスは、展開モードに応じて、200 bpsと2-3 kbit / sの間で変化します。スタンドアロン動作では、数kbit / sまでの最高のデータレートを実現できますが、インバンドおよびガードバンド動作では、数百bpsに達する場合があります。 NB-IoTは、非常に低いビットレートで170 dBを超えるMCLで動作する場合もあります。
For signaling optimization, two options are introduced in addition to the legacy LTE RRC connection setup; mandatory Data-over-NAS (Control Plane optimization, solution 2 in [TGPP23720]) and optional RRC Suspend/Resume (User Plane optimization, solution 18 in [TGPP23720]). In the control-plane optimization, the data is sent over Non-Access Stratum (NAS), directly to/from the Mobile Management Entity (MME) (see Figure 3 for the network architecture) in the core network to the User Equipment (UE) without interaction from the base station. This means there is no Access Stratum security or header compression provided by the PDCP layer in the eNodeB, as the Access Stratum is bypassed, and only limited RRC procedures. Header compression based on Robust Header Compression (RoHC) may still optionally be provided and terminated in the MME.
シグナリングの最適化のために、レガシーLTE RRC接続設定に加えて2つのオプションが導入されています。必須のData-over-NAS（コントロールプレーンの最適化、[TGPP23720]のソリューション2）およびオプションのRRCサスペンド/再開（ユーザープレーンの最適化、[TGPP23720]のソリューション18）。コントロールプレーン最適化では、データはNon-Access Stratum（NAS）を介して、コアネットワークのモバイル管理エンティティ（MME）（ネットワークアーキテクチャについては図3を参照）からユーザー機器（UE）に直接送信されます。 ）ベースステーションからの相互作用なし。これは、アクセス層がバイパスされ、限られたRRC手順のみであるため、eNodeBのPDCP層によって提供されるアクセス層セキュリティまたはヘッダー圧縮がないことを意味します。 Robust Header Compression（RoHC）に基づくヘッダー圧縮は、オプションでMMEで提供および終了できます。
The RRC Suspend/Resume procedures reduce the signaling overhead required for UE state transition from RRC Idle to RRC Connected mode compared to a legacy LTE operation in order to have quicker user-plane transaction with the network and return to RRC Idle mode faster.
RRCサスペンド/レジューム手順は、従来のLTE操作と比較して、UE状態のRRCアイドルからRRCコネクテッドモードへの移行に必要なシグナリングオーバーヘッドを削減し、ネットワークとのユーザープレーントランザクションを高速化し、RRCアイドルモードにすばやく戻すことができます。
In order to prolong device battery life, both Power-Saving Mode (PSM) and extended DRX (eDRX) are available to NB-IoT. With eDRX, the RRC Connected mode DRX cycle is up to 10.24 seconds; in RRC Idle, the eDRX cycle can be up to 3 hours. In PSM, the device is in a deep sleep state and only wakes up for uplink reporting. After the reporting, there is a window (configured by the network) during which the device receiver is open for downlink connectivity or for periodical "keep-alive" signaling (PSM uses periodic TAU signaling with additional reception windows for downlink reachability).
デバイスのバッテリー寿命を延ばすために、省電力モード（PSM）と拡張DRX（eDRX）の両方をNB-IoTで利用できます。 eDRXでは、RRC接続モードのDRXサイクルは最大10.24秒です。 RRCアイドルでは、eDRXサイクルは最大3時間です。 PSMでは、デバイスはディープスリープ状態にあり、アップリンクレポートのためにのみウェイクアップします。レポート後、ウィンドウ（ネットワークによって構成されます）があり、その間、デバイスレシーバーはダウンリンク接続または定期的な "キープアライブ"シグナリングのために開いています（PSMは、ダウンリンクの到達可能性のために追加の受信ウィンドウで定期的なTAUシグナリングを使用します）。
Since NB-IoT operates in a licensed spectrum, it has no channel access restrictions allowing up to a 100% duty cycle.
NB-IoTは、認可されたスペクトルで動作するため、最大100％のデューティサイクルを可能にするチャネルアクセス制限がありません。
3GPP access security is specified in [TGPP33203].
3GPPアクセスセキュリティは[TGPP33203]で指定されています。
+--+
|UE| \ +------+ +------+
+--+ \ | MME |------| HSS |
\ / +------+ +------+
+--+ \+--------+ / |
|UE| ----| eNodeB |- |
+--+ /+--------+ \ |
/ \ +--------+
/ \| | +------+ Service Packet
+--+ / | S-GW |----| P-GW |---- Data Network (PDN)
|UE| | | +------+ e.g., Internet
+--+ +--------+
Figure 3: 3GPP Network Architecture
図3：3GPPネットワークアーキテクチャ
Figure 3 shows the 3GPP network architecture, which applies to NB-IoT. The MME is responsible for handling the mobility of the UE. The MME tasks include tracking and paging UEs, session management, choosing the Serving Gateway for the UE during initial attachment and authenticating the user. At the MME, the NAS signaling from the UE is terminated.
図3は、NB-IoTに適用される3GPPネットワークアーキテクチャを示しています。 MMEは、UEのモビリティの処理を担当します。 MMEタスクには、UEの追跡とページング、セッション管理、初期接続時のUEのサービングゲートウェイの選択、およびユーザーの認証が含まれます。 MMEでは、UEからのNASシグナリングが終了します。
The Serving Gateway (S-GW) routes and forwards the user data packets through the access network and acts as a mobility anchor for UEs during handover between base stations known as eNodeBs and also during handovers between NB-IoT and other 3GPP technologies.
サービングゲートウェイ（S-GW）は、アクセスネットワークを介してユーザーデータパケットをルーティングおよび転送し、eNodeBと呼ばれる基地局間のハンドオーバー中、およびNB-IoTと他の3GPPテクノロジー間のハンドオーバー中のUEのモビリティアンカーとして機能します。
The Packet Data Network Gateway (P-GW) works as an interface between the 3GPP network and external networks.
パケットデータネットワークゲートウェイ（P-GW）は、3GPPネットワークと外部ネットワーク間のインターフェースとして機能します。
The Home Subscriber Server (HSS) contains user-related and subscription-related information. It is a database that performs mobility management, session-establishment support, user authentication, and access authorization.
Home Subscriber Server（HSS）には、ユーザー関連およびサブスクリプション関連の情報が含まれています。これは、モビリティ管理、セッション確立サポート、ユーザー認証、およびアクセス許可を実行するデータベースです。
E-UTRAN consists of components of a single type, eNodeB. eNodeB is a base station that controls the UEs in one or several cells.
E-UTRANは、単一のタイプeNodeBのコンポーネントで構成されています。 eNodeBは、1つまたは複数のセルでUEを制御する基地局です。
The 3GPP radio protocol architecture is illustrated in Figure 4.
3GPP無線プロトコルアーキテクチャを図4に示します。
+---------+ +---------+
| NAS |----|-----------------------------|----| NAS |
+---------+ | +---------+---------+ | +---------+
| RRC |----|----| RRC | S1-AP |----|----| S1-AP |
+---------+ | +---------+---------+ | +---------+
| PDCP |----|----| PDCP | SCTP |----|----| SCTP |
+---------+ | +---------+---------+ | +---------+
| RLC |----|----| RLC | IP |----|----| IP |
+---------+ | +---------+---------+ | +---------+
| MAC |----|----| MAC | L2 |----|----| L2 |
+---------+ | +---------+---------+ | +---------+
| PHY |----|----| PHY | PHY |----|----| PHY |
+---------+ +---------+---------+ +---------+
LTE-Uu S1-MME
UE eNodeB MME
Figure 4: 3GPP Radio Protocol Architecture for the Control Plane
図4：コントロールプレーンの3GPP無線プロトコルアーキテクチャ
The radio protocol architecture of NB-IoT (and LTE) is separated into the control plane and the user plane. The control plane consists of protocols that control the radio-access bearers and the connection between the UE and the network. The highest layer of control plane is called the Non-Access Stratum (NAS), which conveys the radio signaling between the UE and the Evolved Packet Core (EPC), passing transparently through the radio network. The NAS is responsible for authentication, security control, mobility management, and bearer management.
NB-IoT（およびLTE）の無線プロトコルアーキテクチャは、コントロールプレーンとユーザープレーンに分かれています。コントロールプレーンは、無線アクセスベアラと、UEとネットワーク間の接続を制御するプロトコルで構成されています。コントロールプレーンの最上位層は、Non-Access Stratum（NAS）と呼ばれ、UEとEvolved Packet Core（EPC）の間で無線シグナリングを伝達し、無線ネットワークを透過的に通過します。 NASは、認証、セキュリティ制御、モビリティ管理、およびベアラ管理を担当します。
The Access Stratum (AS) is the functional layer below the NAS; in the control plane, it consists of the Radio Resource Control (RRC) protocol [TGPP36331], which handles connection establishment and release functions, broadcast of system information, radio-bearer establishment, reconfiguration, and release. The RRC configures the user and control planes according to the network status. There exist two RRC states, RRC_Idle or RRC_Connected, and the RRC entity controls the switching between these states. In RRC_Idle, the network knows that the UE is present in the network, and the UE can be reached in case of an incoming call/downlink data. In this state, the UE monitors paging, performs cell measurements and cell selection, and acquires system information. Also, the UE can receive broadcast and multicast data, but it is not expected to transmit or receive unicast data. In RRC_Connected state, the UE has a connection to the eNodeB, the network knows the UE location on the cell level, and the UE may receive and transmit unicast data. An RRC connection is established when the UE is expected to be active in the network, to transmit or receive data. The RRC connection is released, switching back to RRC_Idle, when there is no more traffic; this is in order to preserve UE battery life and radio resources.
アクセス層（AS）は、NASの下の機能層です。コントロールプレーンでは、接続の確立と解放の機能、システム情報のブロードキャスト、無線ベアラの確立、再構成、および解放を処理するRadio Resource Control（RRC）プロトコル[TGPP36331]で構成されます。 RRCは、ネットワークステータスに従ってユーザープレーンとコントロールプレーンを構成します。 RRC_IdleまたはRRC_Connectedの2つのRRC状態が存在し、RRCエンティティはこれらの状態間の切り替えを制御します。 RRC_Idleでは、ネットワークはUEがネットワークに存在することを認識しており、着信/ダウンリンクデータの場合はUEに到達できます。この状態で、UEはページングを監視し、セル測定とセル選択を実行し、システム情報を取得します。また、UEはブロードキャストおよびマルチキャストデータを受信できますが、ユニキャストデータを送信または受信することは想定されていません。 RRC_Connected状態では、UEはeNodeBに接続しており、ネットワークはセルレベルでのUEの位置を認識しており、UEはユニキャストデータを送受信できます。 RRC接続は、データを送信または受信するために、UEがネットワーク内でアクティブであることが期待されるときに確立されます。トラフィックがなくなると、RRC接続が解放され、RRC_Idleに戻ります。これは、UEのバッテリ寿命と無線リソースを維持するためです。
However, as mentioned earlier, a new feature was introduced for NB-IoT that allows data to be transmitted from the MME directly to the UE and then transparently to the eNodeB, thus bypassing AS functions.
ただし、前述のように、NB-IoTに新しい機能が導入され、MMEから直接UEに、次に透過的にeNodeBにデータを送信できるため、AS機能がバイパスされます。
The PDCP's [TGPP36323] main services in the control plane are transfer of control-plane data, ciphering, and integrity protection.
コントロールプレーンにおけるPDCPの[TGPP36323]主なサービスは、コントロールプレーンデータの転送、暗号化、および完全性保護です。
The RLC protocol [TGPP36322] performs transfer of upper-layer PDUs and, optionally, error correction with Automatic Repeat reQuest (ARQ), concatenation, segmentation, and reassembly of RLC Service Data Units (SDUs), in-sequence delivery of upper-layer PDUs, duplicate detection, RLC SDU discarding, RLC-re-establishment, and protocol error detection and recovery.
RLCプロトコル[TGPP36322]は、上位層PDUの転送を実行し、オプションで、自動繰り返し要求（ARQ）、連結、セグメント化、およびRLCサービスデータユニット（SDU）の再組み立てによるエラー訂正、上位層の順次配信を実行します。 PDU、重複検出、RLC SDU破棄、RLC再確立、プロトコルエラーの検出と回復。
The MAC protocol [TGPP36321] provides mapping between logical channels and transport channels, multiplexing of MAC SDUs, scheduling information reporting, error correction with Hybrid ARQ (HARQ), priority handling, and transport format selection.
MACプロトコル[TGPP36321]は、論理チャネルとトランスポートチャネル間のマッピング、MAC SDUの多重化、スケジューリング情報レポート、ハイブリッドARQ（HARQ）によるエラー修正、優先度の処理、およびトランスポートフォーマットの選択を提供します。
The PHY [TGPP36201] provides data-transport services to higher layers. These include error detection and indication to higher layers, Forward Error Correction (FEC) encoding, HARQ soft-combining, rate-matching, mapping of the transport channels onto physical channels, power-weighting and modulation of physical channels, frequency and time synchronization, and radio characteristics measurements.
PHY [TGPP36201]は、上位層にデータ転送サービスを提供します。これらには、エラー検出と上位層への表示、前方誤り訂正（FEC）エンコーディング、HARQソフト結合、レートマッチング、物理チャネルへのトランスポートチャネルのマッピング、物理チャネルの電力重み付けと変調、周波数と時間の同期、および無線特性測定。
The user plane is responsible for transferring the user data through the Access Stratum. It interfaces with IP and the highest layer of the user plane is the PDCP, which, in the user plane, performs header compression using RoHC, transfer of user-plane data between eNodeB and the UE, ciphering, and integrity protection. Similar to the control plane, lower layers in the user plane include RLC, MAC, and the PHY performing the same tasks as they do in the control plane.
ユーザープレーンは、アクセス層を介してユーザーデータを転送する責任があります。 IPとインターフェイスし、ユーザープレーンの最上位層はPDCPです。これは、ユーザープレーンで、RoHCを使用したヘッダー圧縮、eNodeBとUE間のユーザープレーンデータの転送、暗号化、および整合性保護を実行します。コントロールプレーンと同様に、ユーザープレーンの下位層には、RLC、MAC、およびPHYが含まれ、コントロールプレーンと同じタスクを実行します。
The Sigfox LPWAN is in line with the terminology and specifications being defined by ETSI [etsi_unb]. As of today, Sigfox's network has been fully deployed in 12 countries, with ongoing deployments in 26 other countries, giving in total a geography of 2 million square kilometers, containing 512 million people.
Sigfox LPWANは、ETSI [etsi_unb]によって定義されている用語と仕様に準拠しています。今日の時点で、Sigfoxのネットワークは12か国に完全に配備されており、他の26か国で継続的に配備されており、合計5億1,000万人を含む200万平方キロメートルの地理を提供しています。
Sigfox LPWAN autonomous battery-operated devices send only a few bytes per day, week, or month, in principle, allowing them to remain on a single battery for up to 10-15 years. Hence, the system is designed as to allow devices to last several years, sometimes even buried underground.
Sigfox LPWAN自律バッテリー式デバイスは、原則として、1日、1週間、または1か月あたり数バイトのみを送信し、最大10〜15年間、単一のバッテリーにとどまることができます。したがって、このシステムは、デバイスが数年持続できるように設計されています。
Since the radio protocol is connectionless and optimized for uplink communications, the capacity of a Sigfox base station depends on the number of messages generated by devices, and not on the actual number of devices. Likewise, the battery life of devices depends on the number of messages generated by the device. Depending on the use case, devices can vary from sending less than one message per device per day to dozens of messages per device per day.
無線プロトコルはコネクションレスであり、アップリンク通信用に最適化されているため、Sigfoxベースステーションの容量は、デバイスによって生成されるメッセージの数に依存し、実際のデバイスの数には依存しません。同様に、デバイスのバッテリー寿命は、デバイスによって生成されるメッセージの数に依存します。ユースケースに応じて、デバイスは1日にデバイスあたり1通未満のメッセージを送信することから、デバイスごとに1日あたり数十のメッセージを送信することまでさまざまです。
The coverage of the cell depends on the link budget and on the type of deployment (urban, rural, etc.). The radio interface is compliant with the following regulations:
セルのカバレッジは、リンクバジェットと展開のタイプ（都市、地方など）によって異なります。無線インターフェイスは、次の規制に準拠しています。
Spectrum allocation in the USA [fcc_ref]
米国でのスペクトル割り当て[fcc_ref]
Spectrum allocation in Europe [etsi_ref1] [etsi_ref2]
ヨーロッパでのスペクトル割り当て[etsi_ref1] [etsi_ref2]
Spectrum allocation in Japan [arib_ref]
日本のスペクトル割り当て[arib_ref]
The Sigfox radio interface is also compliant with the local regulations of the following countries: Australia, Brazil, Canada, Kenya, Lebanon, Mauritius, Mexico, New Zealand, Oman, Peru, Singapore, South Africa, South Korea, and Thailand.
Sigfox無線インターフェースは、オーストラリア、ブラジル、カナダ、ケニア、レバノン、モーリシャス、メキシコ、ニュージーランド、オマーン、ペルー、シンガポール、南アフリカ、韓国、タイの現地の規制にも準拠しています。
The radio interface is based on Ultra Narrow Band (UNB) communications, which allow an increased transmission range by spending a limited amount of energy at the device. Moreover, UNB allows a large number of devices to coexist in a given cell without significantly increasing the spectrum interference.
無線インターフェースはウルトラナローバンド（UNB）通信に基づいており、デバイスで限られた量のエネルギーを消費することにより、伝送範囲を拡大できます。さらに、UNBを使用すると、スペクトル干渉を大幅に増加させることなく、特定のセルに多数のデバイスを共存させることができます。
Both uplink and downlink are supported, although the system is optimized for uplink communications. Due to spectrum optimizations, different uplink and downlink frames and time synchronization methods are needed.
システムはアップリンク通信用に最適化されていますが、アップリンクとダウンリンクの両方がサポートされています。スペクトルの最適化のため、異なるアップリンクフレームとダウンリンクフレーム、および時間同期方法が必要です。
The main radio characteristics of the UNB uplink transmission are:
UNBアップリンク送信の主な無線特性は次のとおりです。
o Channelization mask: 100 Hz / 600 Hz (depending on the region)
o チャネライゼーションマスク：100 Hz / 600 Hz（地域による）
o Uplink baud rate: 100 baud / 600 baud (depending on the region) o Modulation scheme: DBPSK
oアップリンクボーレート：100ボー/ 600ボー（地域による）o変調方式：DBPSK
o Uplink transmission power: compliant with local regulation
o アップリンク送信電力：地域の規制に準拠
o Link budget: 155 dB (or better)
o リンクバジェット：155 dB（またはそれ以上）
o Central frequency accuracy: not relevant, provided there is no significant frequency drift within an uplink packet transmission
o 中心周波数の精度：アップリンクパケット送信内に大きな周波数ドリフトがない場合、関連性はありません
For example, in Europe, the UNB uplink frequency band is limited to 868.00 to 868.60 MHz, with a maximum output power of 25 mW and a duty cycle of 1%.
たとえば、ヨーロッパでは、UNBアップリンク周波数帯域は868.00〜868.60 MHzに制限されており、最大出力電力は25 mW、デューティサイクルは1％です。
The format of the uplink frame is the following:
アップリンクフレームの形式は次のとおりです。
+--------+--------+--------+------------------+-------------+-----+
|Preamble| Frame | Dev ID | Payload |Msg Auth Code| FCS |
| | Sync | | | | |
+--------+--------+--------+------------------+-------------+-----+
Figure 5: Uplink Frame Format
図5：アップリンクフレーム形式
The uplink frame is composed of the following fields:
アップリンクフレームは、次のフィールドで構成されています。
o Preamble: 19 bits
o プリアンブル：19ビット
o Frame sync and header: 29 bits
o フレーム同期とヘッダー：29ビット
o Device ID: 32 bits
o デバイスID：32ビット
o Payload: 0-96 bits
o ペイロード：0-96ビット
o Authentication: 16-40 bits
o 認証：16-40ビット
o Frame check sequence: 16 bits (Cyclic Redundancy Check (CRC))
o フレームチェックシーケンス：16ビット（巡回冗長検査（CRC））
The main radio characteristics of the UNB downlink transmission are:
UNBダウンリンク伝送の主な無線特性は次のとおりです。
o Channelization mask: 1.5 kHz
o チャネライゼーションマスク：1.5 kHz
o Downlink baud rate: 600 baud
o ダウンリンクボーレート：600ボー
o Modulation scheme: GFSK
o 変調方式：GFSK
o Downlink transmission power: 500 mW / 4W (depending on the region)
o ダウンリンク送信電力：500 mW / 4W（地域による）
o Link budget: 153 dB (or better) o Central frequency accuracy: the center frequency of downlink transmission is set by the network according to the corresponding uplink transmission.
oリンクバジェット：153 dB（またはそれ以上）o中心周波数の精度：ダウンリンク送信の中心周波数は、対応するアップリンク送信に従ってネットワークによって設定されます。
For example, in Europe, the UNB downlink frequency band is limited to 869.40 to 869.65 MHz, with a maximum output power of 500 mW with 10% duty cycle.
たとえば、ヨーロッパでは、UNBダウンリンク周波数帯域は869.40〜869.65 MHzに制限され、最大出力電力は500 mW、デューティサイクルは10％です。
The format of the downlink frame is the following:
ダウンリンクフレームの形式は次のとおりです。
+------------+-----+---------+------------------+-------------+-----+
| Preamble |Frame| ECC | Payload |Msg Auth Code| FCS |
| |Sync | | | | |
+------------+-----+---------+------------------+-------------+-----+
Figure 6: Downlink Frame Format
図6：ダウンリンクフレーム形式
The downlink frame is composed of the following fields:
ダウンリンクフレームは、次のフィールドで構成されます。
o Preamble: 91 bits
o プリアンブル：91ビット
o Frame sync and header: 13 bits
o フレーム同期とヘッダー：13ビット
o Error Correcting Code (ECC): 32 bits
o エラー訂正コード（ECC）：32ビット
o Payload: 0-64 bits
o ペイロード：0〜64ビット
o Authentication: 16 bits
o 認証：16ビット
o Frame check sequence: 8 bits (CRC)
o フレームチェックシーケンス：8ビット（CRC）
The radio interface is optimized for uplink transmissions, which are asynchronous. Downlink communications are achieved by devices querying the network for available data.
無線インターフェースは、非同期のアップリンク送信用に最適化されています。ダウンリンク通信は、利用可能なデータをネットワークに照会するデバイスによって実現されます。
A device willing to receive downlink messages opens a fixed window for reception after sending an uplink transmission. The delay and duration of this window have fixed values. The network transmits the downlink message for a given device during the reception window, and the network also selects the BS for transmitting the corresponding downlink message.
ダウンリンクメッセージの受信を希望するデバイスは、アップリンク送信を送信した後、固定ウィンドウを開いて受信します。このウィンドウの遅延と期間は固定値です。ネットワークは、受信ウィンドウ中に特定のデバイスのダウンリンクメッセージを送信し、ネットワークは対応するダウンリンクメッセージを送信するためのBSも選択します。
Uplink and downlink transmissions are unbalanced due to the regulatory constraints on ISM bands. Under the strictest regulations, the system can allow a maximum of 140 uplink messages and 4 downlink messages per device per day. These restrictions can be slightly relaxed depending on system conditions and the specific regulatory domain of operation.
ISM帯域の規制上の制約により、アップリンクとダウンリンクの送信は不均衡です。最も厳しい規制の下で、システムは1日あたりデバイスあたり最大140のアップリンクメッセージと4つのダウンリンクメッセージを許可できます。これらの制限は、システムの状態と特定の規制ドメインの運用に応じて、少し緩和することができます。
+---+
|DEV| * +------+
+---+ * | RA |
* +------+
+---+ * |
|DEV| * * * * |
+---+ * +----+ |
* | BS | \ +--------+
+---+ * +----+ \ | |
DA -----|DEV| * * * | SC |----- NA
+---+ * / | |
* +----+ / +--------+
+---+ * | BS |/
|DEV| * * * * +----+
+---+ *
*
+---+ *
|DEV| * *
+---+
Figure 7: Sigfox Network Architecture
図7：Sigfoxネットワークアーキテクチャ
Figure 7 depicts the different elements of the Sigfox network architecture.
図7は、Sigfoxネットワークアーキテクチャのさまざまな要素を示しています。
Sigfox has a "one-contract one-network" model allowing devices to connect in any country, without any need or notion of either roaming or handover.
Sigfoxは「1契約1ネットワーク」モデルを備えており、ローミングやハンドオーバーの必要性や概念を必要とせずに、デバイスを任意の国で接続できます。
The architecture consists of a single cloud-based core network, which allows global connectivity with minimal impact on the end device and radio access network. The core network elements are the Service Center (SC) and the Registration Authority (RA). The SC is in charge of the data connectivity between the BS and the Internet, as well as the control and management of the BSs and End Points (EPs). The RA is in charge of the EP network access authorization.
アーキテクチャは単一のクラウドベースのコアネットワークで構成されており、エンドデバイスと無線アクセスネットワークへの影響を最小限に抑えてグローバル接続を可能にします。コアネットワーク要素は、サービスセンター（SC）と登録局（RA）です。 SCは、BSとインターネット間のデータ接続、およびBSとエンドポイント（EP）の制御と管理を担当します。 RAはEPネットワークアクセス許可を担当します。
The radio access network is comprised of several BSs connected directly to the SC. Each BS performs complex L1/L2 functions, leaving some L2 and L3 functionalities to the SC.
無線アクセスネットワークは、SCに直接接続されたいくつかのBSで構成されています。各BSは複雑なL1 / L2機能を実行し、一部のL2およびL3機能をSCに残します。
The Devices (DEVs) or EPs are the objects that communicate application data between local Device Applications (DAs) and Network Applications (NAs).
デバイス（DEV）またはEPは、ローカルデバイスアプリケーション（DA）とネットワークアプリケーション（NA）の間でアプリケーションデータを通信するオブジェクトです。
Devices (or EPs) can be static or nomadic, as they associate with the SC and they do not attach to any specific BS. Hence, they can communicate with the SC through one or multiple BSs.
デバイス（またはEP）は、SCに関連付けられ、特定のBSに接続しないため、静的または遊牧である可能性があります。したがって、1つまたは複数のBSを介してSCと通信できます。
Due to constraints in the complexity of the Device, it is assumed that Devices host only one or very few device applications, which most of the time communicate each to a single network application at a time.
デバイスの複雑さの制約により、デバイスは1つまたは非常に少数のデバイスアプリケーションのみをホストし、ほとんどの場合、一度に1つのネットワークアプリケーションと通信します。
The radio protocol authenticates and ensures the integrity of each message. This is achieved by using a unique device ID and an AES-128-based message authentication code, ensuring that the message has been generated and sent by the device with the ID claimed in the message. Application data can be encrypted at the application level or not, depending on the criticality of the use case, to provide a balance between cost and effort versus risk. AES-128 in counter mode is used for encryption. Cryptographic keys are independent for each device. These keys are associated with the device ID and separate integrity and confidentiality keys are pre-provisioned. A confidentiality key is only provisioned if confidentiality is to be used. At the time of writing, the algorithms and keying details for this are not published.
無線プロトコルは、各メッセージの認証と整合性を保証します。これは、一意のデバイスIDとAES-128ベースのメッセージ認証コードを使用して実現され、メッセージで要求されたIDを持つデバイスによってメッセージが生成および送信されたことを確認します。アプリケーションデータは、ユースケースの重要度に応じて、アプリケーションレベルで暗号化することも暗号化しないこともでき、コストと労力とリスクのバランスをとることができます。暗号化には、カウンターモードのAES-128が使用されます。暗号化キーは、デバイスごとに独立しています。これらのキーはデバイスIDに関連付けられており、個別の整合性キーと機密性キーが事前にプロビジョニングされています。機密性キーは、機密性を使用する場合にのみプロビジョニングされます。執筆時点では、このアルゴリズムとキーイングの詳細は公開されていません。
Text here is via personal communication from Bob Heile (bheile@ieee.org) and was authored by Bob and Sum Chin Sean. Paul Duffy (paduffy@cisco.com) also provided additional comments/input on this section.
ここのテキストは、Bob Heile（bheile@ieee.org）からの個人的なコミュニケーションによるもので、BobとSum Chin Seanによって作成されました。 Paul Duffy（paduffy@cisco.com）もこのセクションに追加のコメント/入力を提供しました。
The Wi-SUN Alliance <https://www.wi-sun.org/> is an industry alliance for smart city, smart grid, smart utility, and a broad set of general IoT applications. The Wi-SUN Alliance Field Area Network (FAN) profile is open-standards based (primarily on IETF and IEEE 802 standards) and was developed to address applications like smart municipality/city infrastructure monitoring and management, Electric Vehicle (EV) infrastructure, Advanced Metering Infrastructure (AMI), Distribution Automation (DA), Supervisory Control and Data Acquisition (SCADA) protection/management, distributed generation monitoring and management, and many more IoT applications. Additionally, the Alliance has created a certification program to promote global multi-vendor interoperability.
Wi-SUNアライアンス<https://www.wi-sun.org/>は、スマートシティ、スマートグリッド、スマートユーティリティ、および一般的なIoTアプリケーションの幅広いセットのための業界アライアンスです。 Wi-SUNアライアンスフィールドエリアネットワーク（FAN）プロファイルは（主にIETFおよびIEEE 802標準に基づく）オープンスタンダードであり、スマート自治体/都市インフラの監視と管理、電気自動車（EV）インフラ、高度なアプリケーションなどのアプリケーションに対応するために開発されましたメータリングインフラストラクチャ（AMI）、配電自動化（DA）、監視制御およびデータ収集（SCADA）保護/管理、分散型発電の監視と管理、その他多くのIoTアプリケーション。さらに、アライアンスはグローバルなマルチベンダー相互運用性を促進するための認定プログラムを作成しました。
The FAN profile is specified within ANSI/TIA as an extension of work previously done on Smart Utility Networks [ANSI-4957-000]. Updates to those specifications intended to be published in 2017 will contain details of the FAN profile. A current snapshot of the work to produce that profile is presented in [wisun-pressie1] and [wisun-pressie2].
FANプロファイルは、以前にSmart Utility Networks [ANSI-4957-000]で行われた作業の拡張として、ANSI / TIA内で指定されています。 2017年に公開される予定の仕様の更新には、FANプロファイルの詳細が含まれます。そのプロファイルを作成する作業の現在のスナップショットは、[wisun-pressie1]と[wisun-pressie2]に示されています。
The FAN profile is an IPv6 wireless mesh network with support for enterprise-level security. The frequency-hopping wireless mesh topology aims to offer superior network robustness, reliability due to high redundancy, good scalability due to the flexible mesh configuration, and good resilience to interference. Very low power modes are in development permitting long-term battery operation of network nodes.
FANプロファイルは、エンタープライズレベルのセキュリティをサポートするIPv6ワイヤレスメッシュネットワークです。周波数ホッピングワイヤレスメッシュトポロジは、優れたネットワークの堅牢性、高い冗長性による信頼性、柔軟なメッシュ構成による優れたスケーラビリティ、および干渉に対する優れた復元力を提供することを目的としています。非常に低電力のモードが開発中であり、ネットワークノードの長期間のバッテリ動作が可能です。
The following list contains some overall characteristics of Wi-SUN that are relevant to LPWAN applications.
次のリストには、LPWANアプリケーションに関連するWi-SUNの全体的な特性がいくつか含まれています。
o Coverage: The range of Wi-SUN FAN is typically 2 - 3 km in line of sight, matching the needs of neighborhood area networks, campus area networks, or corporate area networks. The range can also be extended via multi-hop networking.
o 対象範囲：Wi-SUN FANの範囲は通常、見通し内で2〜3 kmであり、近隣エリアネットワーク、キャンパスエリアネットワーク、または企業エリアネットワークのニーズに一致しています。範囲は、マルチホップネットワークを介して拡張することもできます。
o High-bandwidth, low-link latency: Wi-SUN supports relatively high bandwidth, i.e., up to 300 kbit/s [FANOV], enables remote update and upgrade of devices so that they can handle new applications, extending their working life. Wi-SUN supports LPWAN IoT applications that require on-demand control by providing low link latency (0.02 s) and bidirectional communication.
o 高帯域幅、低リンク遅延：Wi-SUNは比較的高い帯域幅、つまり最大300 kbit / s [FANOV]をサポートし、デバイスのリモート更新とアップグレードを可能にするため、デバイスは新しいアプリケーションを処理して作業寿命を延ばすことができます。 Wi-SUNは、低リンク遅延（0.02秒）と双方向通信を提供することでオンデマンド制御を必要とするLPWAN IoTアプリケーションをサポートします。
o Low-power consumption: FAN devices draw less than 2 uA when resting and only 8 mA when listening. Such devices can maintain a long lifetime, even if they are frequently listening. For instance, suppose the device transmits data for 10 ms once every 10 s; theoretically, a battery of 1000 mAh can last more than 10 years.
o 低消費電力：FANデバイスの消費電流は、休息時に2 uA未満、聴取時にわずか8 mAです。このようなデバイスは、頻繁にリスニングしている場合でも、長い寿命を維持できます。たとえば、デバイスが10秒ごとに1回、10 msのデータを送信するとします。理論的には、1000 mAhのバッテリーは10年以上持続できます。
o Scalability: Tens of millions of Wi-SUN FAN devices have been deployed in urban, suburban, and rural environments, including deployments with more than 1 million devices.
o スケーラビリティ：数千万のWi-SUN FANデバイスが、100万台を超えるデバイスを含む展開を含め、都市、郊外、地方の環境に展開されています。
A FAN contains one or more networks. Within a network, nodes assume one of three operational roles. First, each network contains a Border Router providing WAN connectivity to the network. The Border Router maintains source-routing tables for all nodes within its network, provides node authentication and key management services, and disseminates network-wide information such as broadcast schedules. Second, Router nodes, which provide upward and downward packet forwarding (within a network). A Router also provides services for relaying security and address management protocols. Finally, Leaf nodes provide minimum capabilities: discovering and joining a network, sending/receiving IPv6 packets, etc. A low-power network may contain a mesh topology with Routers at the edges that construct a star topology with Leaf nodes.
FANには1つ以上のネットワークが含まれています。ネットワーク内では、ノードは3つの運用上の役割の1つを担います。まず、各ネットワークには、ネットワークへのWAN接続を提供する境界ルーターが含まれています。ボーダールーターは、ネットワーク内のすべてのノードのソースルーティングテーブルを維持し、ノード認証とキー管理サービスを提供し、ブロードキャストスケジュールなどのネットワーク全体の情報を配布します。 2つ目は、（ネットワーク内で）上向きおよび下向きのパケット転送を提供するルーターノードです。ルーターは、セキュリティおよびアドレス管理プロトコルを中継するためのサービスも提供します。最後に、リーフノードは、ネットワークの検出と参加、IPv6パケットの送受信など、最小限の機能を提供します。低電力ネットワークには、エッジにルーターを備えたメッシュトポロジが含まれ、リーフノードを備えたスタートポロジを構築します。
The FAN profile is based on various open standards developed by the IETF (including [RFC768], [RFC2460], [RFC4443], and [RFC6282]). Related IEEE 802 standards include [IEEE.802.15.4] and [IEEE.802.15.9]. For Low-Power and Lossy Networks (LLNs), see ANSI/ TIA [ANSI-4957-210].
FANプロファイルは、IETFによって開発されたさまざまなオープンスタンダードに基づいています（[RFC768]、[RFC2460]、[RFC4443]、および[RFC6282]を含む）。関連するIEEE 802標準には、[IEEE.802.15.4]と[IEEE.802.15.9]が含まれます。低電力および損失の多いネットワーク（LLN）については、ANSI / TIA [ANSI-4957-210]を参照してください。
The FAN profile specification provides an application-independent IPv6-based transport service. There are two possible methods for establishing IPv6 packet routing: the Routing Protocol for Low-Power and Lossy Networks (RPL) at the Network layer is mandatory, and Multi-Hop Delivery Service (MHDS) is optional at the Data Link layer. Figure 8 provides an overview of the FAN network stack.
FANプロファイル仕様は、アプリケーションに依存しないIPv6ベースのトランスポートサービスを提供します。 IPv6パケットルーティングを確立するには、2つの方法があります。ネットワーク層での低電力および損失の多いネットワーク（RPL）のルーティングプロトコルは必須であり、データリンク層でのマルチホップ配信サービス（MHDS）はオプションです。図8に、FANネットワークスタックの概要を示します。
The Transport service is based on UDP (defined in [RFC768]) or TCP (defined in [RFC793].
トランスポートサービスは、UDP（[RFC768]で定義）またはTCP（[RFC793]で定義）に基づいています。
The Network service is provided by IPv6 as defined in [RFC2460] with an IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) adaptation as defined in [RFC4944] and [RFC6282]. ICMPv6, as defined in [RFC4443], is used for the control plane during information exchange.
ネットワークサービスは、[RFC2460]で定義されているIPv6によって提供され、[RFC4944]および[RFC6282]で定義されているIPv6 over Low-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）に適合しています。 [RFC4443]で定義されているICMPv6は、情報交換中にコントロールプレーンに使用されます。
The Data Link service provides both control/management of the PHY and data transfer/management services to the Network layer. These services are divided into MAC and Logical Link Control (LLC) sub-layers. The LLC sub-layer provides a protocol dispatch service that supports 6LoWPAN and an optional MAC sub-layer mesh service. The MAC sub-layer is constructed using data structures defined in [IEEE.802.15.4]. Multiple modes of frequency hopping are defined. The entire MAC payload is encapsulated in an [IEEE.802.15.9] Information Element to enable LLC protocol dispatch between upper-layer 6LoWPAN processing and MAC sub-layer mesh processing, etc. These areas will be expanded once [IEEE.802.15.12] is completed.
データリンクサービスは、PHYの制御/管理と、ネットワーク層へのデータ転送/管理サービスの両方を提供します。これらのサービスは、MACと論理リンク制御（LLC）サブレイヤーに分かれています。 LLCサブレイヤーは、6LoWPANとオプションのMACサブレイヤーメッシュサービスをサポートするプロトコルディスパッチサービスを提供します。 MACサブレイヤーは、[IEEE.802.15.4]で定義されたデータ構造を使用して構築されます。周波数ホッピングの複数のモードが定義されています。 MACペイロード全体が[IEEE.802.15.9]情報要素にカプセル化され、上位層6LoWPAN処理とMACサブ層メッシュ処理などの間でLLCプロトコルディスパッチが可能になります。これらの領域は、[IEEE.802.15.12 ] 完成されました。
The PHY service is derived from a subset of the SUN FSK specification in [IEEE.802.15.4]. The 2-FSK modulation schemes, with a channel-spacing range from 200 to 600 kHz, are defined to provide data rates from 50 to 300 kbit/s, with FEC as an optional feature. Towards enabling ultra-low-power applications, the PHY layer design is also extendable to low-energy and critical infrastructure-monitoring networks.
PHYサービスは、[IEEE.802.15.4]のSUN FSK仕様のサブセットから派生しています。チャネル間隔が200〜600 kHzの2-FSK変調方式は、50〜300 kbit / sのデータレートを提供するように定義されており、FECはオプション機能です。超低電力アプリケーションの実現に向けて、PHYレイヤー設計は、低エネルギーで重要なインフラストラクチャ監視ネットワークにも拡張できます。
+----------------------+--------------------------------------------+
| Layer | Description |
+----------------------+--------------------------------------------+
| IPv6 protocol suite | TCP/UDP |
| | |
| | 6LoWPAN Adaptation + Header Compression |
| | |
| | DHCPv6 for IP address management |
| | |
| | Routing using RPL |
| | |
| | ICMPv6 |
| | |
| | Unicast and Multicast forwarding |
+----------------------+--------------------------------------------+
| MAC based on | Frequency hopping |
| [IEEE.802.15.4e] + | |
| IE extensions | Discovery and Join |
| | |
| | Protocol Dispatch ([IEEE.802.15.9]) |
| | |
| | Several Frame Exchange patterns |
| | |
| | Optional Mesh Under routing |
| | ([ANSI-4957-210]) |
+----------------------+--------------------------------------------+
| PHY based on | Various data rates and regions |
| [IEEE.802.15.4g] | |
+----------------------+--------------------------------------------+
| Security | [IEEE.802.1x]/EAP-TLS/PKI Authentication |
| | TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 |
| | required for EAP-TLS |
| | |
| | 802.11i Group Key Management |
| | |
| | Frame security is implemented as AES-CCM* |
| | as specified in [IEEE.802.15.4] |
| | |
| | Optional [ETSI-TS-102-887-2] Node 2 Node |
| | Key Management |
+----------------------+--------------------------------------------+
Figure 8: Wi-SUN Stack Overview
図8：Wi-SUNスタックの概要
The FAN security supports Data Link layer network access control, mutual authentication, and establishment of a secure pairwise link between a FAN node and its Border Router, which is implemented with an adaptation of [IEEE.802.1x] and EAP-TLS as described in [RFC5216] using secure device identity as described in [IEEE.802.1AR]. Certificate formats are based upon [RFC5280]. A secure group link between a Border Router and a set of FAN nodes is established using an adaptation of the [IEEE.802.11] Four-Way Handshake. A set of four group keys are maintained within the network, one of which is the current transmit key. Secure node-to-node links are supported between one-hop FAN neighbors using an adaptation of [ETSI-TS-102-887-2]. FAN nodes implement Frame Security as specified in [IEEE.802.15.4].
FANセキュリティは、データリンク層ネットワークアクセス制御、相互認証、およびFANノードとその境界ルーター間の安全なペアワイズリンクの確立をサポートします。これは、[IEEE.802.1x]の適応とEAP-TLSで実装されています。 [RFC5216] [IEEE.802.1AR]で説明されている安全なデバイスIDを使用。証明書の形式は[RFC5280]に基づいています。ボーダールーターと一連のFANノード間の安全なグループリンクは、[IEEE.802.11] 4ウェイハンドシェイクの適応を使用して確立されます。 4つのグループキーのセットがネットワーク内で維持され、そのうちの1つが現在の送信キーです。安全なノード間リンクは、[ETSI-TS-102-887-2]のアダプテーションを使用して、1ホップのFANネイバー間でサポートされます。 FANノードは、[IEEE.802.15.4]で指定されているフレームセキュリティを実装します。
LPWAN technologies, such as those discussed above, have similar architectures but different terminology. We can identify different types of entities in a typical LPWAN network:
上記のようなLPWANテクノロジーは、アーキテクチャは似ていますが、用語が異なります。一般的なLPWANネットワークでは、さまざまなタイプのエンティティを識別できます。
o End devices are the devices or the "things" (e.g., sensors, actuators, etc.); they are named differently in each technology (End Device, User Equipment, or EP). There can be a high density of end devices per Radio Gateway.
o エンドデバイスとは、デバイスまたは「モノ」（センサー、アクチュエーターなど）です。それらは、テクノロジーごとに異なる名前が付けられています（エンドデバイス、ユーザー機器、またはEP）。無線ゲートウェイごとに高密度のエンドデバイスが存在する可能性があります。
o The Radio Gateway, which is the EP of the constrained link. It is known as: Gateway, Evolved Node B or base station.
o 制約付きリンクのEPである無線ゲートウェイ。ゲートウェイ、Evolved Node Bまたはベースステーションとして知られています。
o The Network Gateway or Router is the interconnection node between the Radio Gateway and the Internet. It is known as the Network Server, Serving GW, or Service Center.
o ネットワークゲートウェイまたはルーターは、無線ゲートウェイとインターネット間の相互接続ノードです。これは、Network Server、Serving GW、またはService Centerとして知られています。
o LPWAN-AAA server, which controls user authentication. It is known as the Join-Server, Home Subscriber Server, or Registration Authority. (We use the term LPWAN-AAA server because we're not assuming that this entity speaks RADIUS or Diameter as many/most AAA servers do; but, equally, we don't want to rule that out, as the functionality will be similar.)
o ユーザー認証を制御するLPWAN-AAAサーバー。これは、Join-Server、Home Subscriber Server、またはRegistration Authorityとして知られています。 （LPWAN-AAAサーバーという用語を使用します。これは、このエンティティがRADIUSまたはDiameterを話すことが多く/ほとんどのAAAサーバーのように想定しているわけではないためです。ただし、機能は同様であるため、除外しないでください。 。）
o At last we have the Application Server, known also as Packet Data Node Gateway or Network Application.
o ついに、Packet Data Node GatewayまたはNetwork Applicationとしても知られるApplication Serverができました。
+---------------------------------------------------------------------+
| Function/ | | | | | |
|Technology | LoRaWAN | NB-IoT | Sigfox | Wi-SUN | IETF |
+-----------+-----------+-----------+------------+--------+-----------+
|Sensor, | | | | | |
|Actuator, | End | User | End | Leaf | Device |
|device, | Device | Equipment | Point | Node | (DEV) |
|object | | | | | |
+-----------+-----------+-----------+------------+--------+-----------+
|Transceiver| | Evolved | Base | Router | Radio |
|Antenna | Gateway | Node B | Station | Node | Gateway |
+-----------+-----------+-----------+------------+--------+-----------+
|Server | Network | PDN GW/ | Service | Border | Network |
| | Server | SCEF* | Center | Router | Gateway |
| | | | | | (NGW) |
+-----------+-----------+-----------+------------+--------+-----------+
|Security | Join | Home |Registration|Authent.| LPWAN- |
|Server | Server | Subscriber| Authority | Server | AAA |
| | | Server | | | Server |
+-----------+-----------+-----------+------------+--------+-----------+
|Application|Application|Application| Network |Appli- |Application|
| | Server | Server | Application| cation | (App) |
+---------------------------------------------------------------------+
* SCEF = Service Capability Exposure Function
* SCEF = Service Capability Exposure Function
Figure 9: LPWAN Architecture Terminology
図9：LPWANアーキテクチャの用語
+------+
() () () | |LPWAN-|
() () () () / \ +---------+ | AAA |
() () () () () () / \========| /\ |====|Server| +-----------+
() () () | | <--|--> | +------+ |APPLICATION|
() () () () / \============| v |==============| (App) |
() () () / \ +---------+ +-----------+
DEV Radio Gateways NGW
Figure 10: LPWAN Architecture
図10：LPWANアーキテクチャ
In addition to the names of entities, LPWANs are also subject to possibly regional frequency-band regulations. Those may include restrictions on the duty cycle, for example, requiring that hosts only transmit for a certain percentage of each hour.
エンティティの名前に加えて、LPWANも地域の周波数帯域規制の対象になります。これらには、デューティサイクルの制限が含まれる場合があります。たとえば、ホストが毎時の特定の割合でのみ送信することを要求します。
This section considers some of the gaps between current LPWAN technologies and the goals of the LPWAN WG. Many of the generic considerations described in [RFC7452] will also apply in LPWANs, as end devices can also be considered to be a subclass of (so-called) "smart objects". In addition, LPWAN device implementers will also need to consider the issues relating to firmware updates described in [RFC8240].
このセクションでは、現在のLPWANテクノロジーとLPWAN WGの目標との間のギャップのいくつかを検討します。 [RFC7452]で説明されている一般的な考慮事項の多くは、LPWANにも適用されます。これは、エンドデバイスも（いわゆる）「スマートオブジェクト」のサブクラスと見なすことができるためです。さらに、LPWANデバイスの実装者は、[RFC8240]で説明されているファームウェアの更新に関連する問題も考慮する必要があります。
IPv6 [RFC8200] has been designed to allocate addresses to all the nodes connected to the Internet. Nevertheless, the header overhead of at least 40 bytes introduced by the protocol is incompatible with LPWAN constraints. If IPv6 with no further optimization were used, several LPWAN frames could be needed just to carry the IP header. Another problem arises from IPv6 MTU requirements, which require the layer below to support at least 1280 byte packets [RFC2460].
IPv6 [RFC8200]は、インターネットに接続されているすべてのノードにアドレスを割り当てるように設計されています。それにもかかわらず、プロトコルによって導入された少なくとも40バイトのヘッダーオーバーヘッドは、LPWAN制約と互換性がありません。それ以上最適化されていないIPv6が使用された場合、IPヘッダーを伝送するためだけにいくつかのLPWANフレームが必要になる可能性があります。別の問題は、IPv6 MTU要件から発生します。IPv6MTU要件では、下の層が少なくとも1280バイトのパケットをサポートする必要があります[RFC2460]。
IPv6 has a configuration protocol: Neighbor Discovery Protocol (NDP) [RFC4861]). For a node to learn network parameters, NDP generates regular traffic with a relatively large message size that does not fit LPWAN constraints.
IPv6には構成プロトコルがあります：近隣探索プロトコル（NDP）[RFC4861]）。ノードがネットワークパラメータを学習するために、NDPは、LPWANの制約に適合しない比較的大きなメッセージサイズの通常のトラフィックを生成します。
In some LPWAN technologies, L2 multicast is not supported. In that case, if the network topology is a star, the solution and considerations from Section 3.2.5 of [RFC7668] may be applied.
一部のLPWANテクノロジーでは、L2マルチキャストはサポートされていません。その場合、ネットワークトポロジがスターの場合、[RFC7668]のセクション3.2.5のソリューションと考慮事項が適用される場合があります。
Other key protocols (such as DHCPv6 [RFC3315], IPsec [RFC4301] and TLS [RFC5246]) have similarly problematic properties in this context. Each protocol requires relatively frequent round-trips between the host and some other host on the network. In the case of cryptographic protocols (such as IPsec and TLS), in addition to the round-trips required for secure session establishment, cryptographic operations can require padding and addition of authenticators that are problematic when considering LPWAN lower layers. Note that mains powered Wi-SUN mesh router nodes will typically be more resource capable than the other LPWAN technologies discussed. This can enable use of more "chatty" protocols for some aspects of Wi-SUN.
他の主要なプロトコル（DHCPv6 [RFC3315]、IPsec [RFC4301]、TLS [RFC5246]など）には、このコンテキストで同様に問題のあるプロパティがあります。各プロトコルでは、ホストとネットワーク上の他のホストとの間で比較的頻繁なラウンドトリップが必要です。暗号化プロトコル（IPsecやTLSなど）の場合、安全なセッションの確立に必要なラウンドトリップに加えて、暗号化操作では、LPWAN下位層を検討するときに問題となるオーセンティケーターのパディングと追加が必要になる場合があります。主電源のWi-SUNメッシュルーターノードは、通常、説明されている他のLPWANテクノロジーよりもリソースに対応します。これにより、Wi-SUNのいくつかの側面でより「おしゃべりな」プロトコルを使用できるようになります。
Several technologies that exhibit significant constraints in various dimensions have exploited the 6LoWPAN suite of specifications ([RFC4944], [RFC6282], and [RFC6775]) to support IPv6 [USES-6LO]. However, the constraints of LPWANs, often more extreme than those typical of technologies that have (re-)used 6LoWPAN, constitute a challenge for the 6LoWPAN suite in order to enable IPv6 over LPWAN. LPWANs are characterized by device constraints (in terms of processing capacity, memory, and energy availability), and especially, link constraints, such as:
さまざまな次元で重要な制約を示すいくつかのテクノロジーは、6LoWPAN仕様のスイート（[RFC4944]、[RFC6282]、および[RFC6775]）を利用してIPv6 [USES-6LO]をサポートしています。ただし、LPWANの制約は、多くの場合、6LoWPANを（再）使用した一般的なテクノロジーよりも極端であり、LPWANでIPv6を有効にするための6LoWPANスイートの課題です。 LPWANは、デバイスの制約（処理能力、メモリ、エネルギーの利用可能性に関する）、特に次のようなリンクの制約によって特徴付けられます。
o tiny L2 payload size (from ~10 to ~100 bytes),
o 小さなL2ペイロードサイズ（〜10から〜100バイト）、
o very low bit rate (from ~10 bit/s to ~100 kbit/s), and
o 非常に低いビットレート（〜10ビット/秒から〜100 kbit /秒）、および
o in some specific technologies, further message rate constraints (e.g., between ~0.1 message/minute and ~1 message/minute) due to regional regulations that limit the duty cycle.
o 一部の特定のテクノロジーでは、デューティサイクルを制限する地域の規制により、さらにメッセージレートの制約（例：〜0.1メッセージ/分から〜1メッセージ/分）。
6LoWPAN header compression reduces IPv6 (and UDP) header overhead by eliding header fields when they can be derived from the link layer and by assuming that some of the header fields will frequently carry expected values. 6LoWPAN provides both stateless and stateful header compression. In the latter, all nodes of a 6LoWPAN are assumed to share compression context. In the best case, the IPv6 header for link-local communication can be reduced to only 2 bytes. For global communication, the IPv6 header may be compressed down to 3 bytes in the most extreme case. However, in more practical situations, the smallest IPv6 header size may be 11 bytes (one address prefix compressed) or 19 bytes (both source and destination prefixes compressed). These headers are large considering the link-layer payload size of LPWAN technologies, and in some cases, are even bigger than the LPWAN PDUs. 6LoWPAN was initially designed for [IEEE.802.15.4] networks with a frame size up to 127 bytes and a throughput of up to 250 kbit/s, which may or may not be duty cycled.
6LoWPANヘッダー圧縮は、リンクレイヤーから派生できるヘッダーフィールドを省略し、一部のヘッダーフィールドが期待値を頻繁に運ぶと想定することで、IPv6（およびUDP）ヘッダーのオーバーヘッドを削減します。 6LoWPANは、ステートレスとステートフルの両方のヘッダー圧縮を提供します。後者では、6LoWPANのすべてのノードが圧縮コンテキストを共有すると想定されます。最良のケースでは、リンクローカル通信のIPv6ヘッダーを2バイトに減らすことができます。グローバル通信の場合、最も極端な場合、IPv6ヘッダーが3バイトに圧縮されることがあります。ただし、より実際的な状況では、最小のIPv6ヘッダーサイズは11バイト（圧縮された1つのアドレスプレフィックス）または19バイト（圧縮されたソースプレフィックスと宛先プレフィックスの両方）になる場合があります。これらのヘッダーは、LPWANテクノロジーのリンク層ペイロードサイズを考慮して大きく、場合によってはLPWAN PDUよりも大きくなります。 6LoWPANは当初、フレームサイズが最大127バイト、スループットが最大250 kbit / sの[IEEE.802.15.4]ネットワーク用に設計されたものであり、デューティサイクルの有無は問われません。
Traditionally, Interface Identifiers (IIDs) have been derived from link-layer identifiers [RFC4944]. This allows optimizations such as header compression. Nevertheless, recent guidance has given advice on the fact that, due to privacy concerns, 6LoWPAN devices should not be configured to embed their link-layer addresses in the IID by default. [RFC8065] provides guidance on better methods for generating IIDs.
従来、インターフェース識別子（IID）はリンク層識別子[RFC4944]から派生してきました。これにより、ヘッダー圧縮などの最適化が可能になります。それにもかかわらず、最近のガイダンスでは、プライバシーの問題のため、6LoWPANデバイスはリンクレイヤーアドレスをデフォルトでIIDに埋め込むように構成すべきではないという事実についてのアドバイスを提供しています。 [RFC8065]は、IIDを生成するためのより良い方法に関するガイダンスを提供します。
As stated above, IPv6 requires the layer below to support an MTU of 1280 bytes [RFC8200]. Therefore, given the low maximum payload size of LPWAN technologies, fragmentation is needed.
上記のように、IPv6は1280バイトのMTU [RFC8200]をサポートするために、下の層を必要とします。したがって、LPWANテクノロジーの最大ペイロードサイズが小さい場合、フラグメンテーションが必要です。
If a layer of an LPWAN technology supports fragmentation, proper analysis has to be carried out to decide whether the fragmentation functionality provided by the lower layer or fragmentation at the adaptation layer should be used. Otherwise, fragmentation functionality shall be used at the adaptation layer.
LPWANテクノロジのレイヤーが断片化をサポートしている場合、適切な分析を実行して、下位レイヤーによって提供される断片化機能を使用するか、アダプテーション層での断片化を使用するかを決定する必要があります。それ以外の場合は、断片化機能がアダプテーション層で使用されます。
6LoWPAN defined a fragmentation mechanism and a fragmentation header to support the transmission of IPv6 packets over IEEE.802.15.4 networks [RFC4944]. While the 6LoWPAN fragmentation header is appropriate for the 2003 version of [IEEE.802.15.4] (which has a frame payload size of 81-102 bytes), it is not suitable for several LPWAN technologies, many of which have a maximum payload size that is one order of magnitude below that of the 2003 version of [IEEE.802.15.4]. The overhead of the 6LoWPAN fragmentation header is high, considering the reduced payload size of LPWAN technologies, and the limited energy availability of the devices using such technologies. Furthermore, its datagram offset field is expressed in increments of eight octets. In some LPWAN technologies, the 6LoWPAN fragmentation header plus eight octets from the original datagram exceeds the available space in the layer two payload. In addition, the MTU in the LPWAN networks could be variable, which implies a variable fragmentation solution.
6LoWPANは、IEEE.802.15.4ネットワーク[RFC4944]を介したIPv6パケットの送信をサポートするために、断片化メカニズムと断片化ヘッダーを定義しました。 6LoWPANフラグメンテーションヘッダーは[IEEE.802.15.4]の2003バージョン（81〜102バイトのフレームペイロードサイズ）に適していますが、最大ペイロードサイズを持つLPWANテクノロジーには適していません。これは、[IEEE.802.15.4]の2003バージョンよりも1桁低い数値です。 6LoWPANフラグメンテーションヘッダーのオーバーヘッドは、LPWANテクノロジーのペイロードサイズの削減と、そのようなテクノロジーを使用するデバイスの限られたエネルギー可用性を考慮すると高くなります。さらに、そのデータグラムオフセットフィールドは、8オクテットの増分で表されます。一部のLPWANテクノロジーでは、6LoWPANフラグメンテーションヘッダーと元のデータグラムからの8オクテットが、レイヤー2ペイロードで利用可能なスペースを超えています。さらに、LPWANネットワークのMTUは可変である可能性があり、これは可変の断片化ソリューションを意味します。
6LoWPAN Neighbor Discovery [RFC6775] defines optimizations to IPv6 ND [RFC4861], in order to adapt functionality of the latter for networks of devices using [IEEE.802.15.4] or similar technologies. The optimizations comprise host-initiated interactions to allow for sleeping hosts, replacement of multicast-based address resolution for hosts by an address registration mechanism, multihop extensions for prefix distribution and duplicate address detection (note that these are not needed in a star topology network), and support for 6LoWPAN header compression.
6LoWPAN近隣探索[RFC6775]は、IPv6 ND [RFC4861]の最適化を定義して、[IEEE.802.15.4]または同様のテクノロジーを使用するデバイスのネットワークに後者の機能を適応させます。最適化は、スリープ状態のホスト、アドレス登録メカニズムによるホストのマルチキャストベースのアドレス解決の置き換え、プレフィックス配布用のマルチホップ拡張、および重複アドレス検出を可能にするためにホストが開始する相互作用で構成されます（スタートポロジネットワークでは必要ありません）。 、および6LoWPANヘッダー圧縮のサポート。
6LoWPAN ND may be used in not so severely constrained LPWAN networks. The relative overhead incurred will depend on the LPWAN technology used (and on its configuration, if appropriate). In certain LPWAN setups (with a maximum payload size above ~60 bytes and duty-cycle-free or equivalent operation), an RS/RA/NS/NA exchange may be completed in a few seconds, without incurring packet fragmentation.
6LoWPAN NDはそれほど制約の少ないLPWANネットワークで使用できます。発生する相対的なオーバーヘッドは、使用されるLPWANテクノロジー（および適切な場合はその構成）によって異なります。特定のLPWAN設定（最大ペイロードサイズが60バイトを超え、デューティサイクルフリーまたは同等の操作）では、RS / RA / NS / NA交換は、パケットの断片化を引き起こすことなく、数秒で完了する場合があります。
In other LPWANs (with a maximum payload size of ~10 bytes and a message rate of ~0.1 message/minute), the same exchange may take hours or even days, leading to severe fragmentation and consuming a significant amount of the available network resources. 6LoWPAN ND behavior may be tuned through the use of appropriate values for the default Router Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in the 6LoWPAN Context Option (6CO), as well as the address Registration Lifetime. However, for the latter LPWANs mentioned above, 6LoWPAN ND is not suitable.
他のLPWAN（最大ペイロードサイズ〜10バイト、メッセージレート〜0.1メッセージ/分）では、同じ交換に数時間または数日かかる場合があり、深刻な断片化につながり、利用可能なネットワークリソースのかなりの量を消費します。 6LoWPAN NDの動作は、デフォルトのルーターライフタイム、PIOの有効ライフタイム、6LoWPANコンテキストオプション（6CO）の有効ライフタイム、およびアドレス登録ライフタイムの適切な値を使用して調整できます。ただし、上記の後者のLPWANでは、6LoWPAN NDは適していません。
The 6lo WG has been reusing and adapting 6LoWPAN to enable IPv6 support over link-layer technologies such as Bluetooth Low Energy (BTLE), ITU-T G.9959 [G9959], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE), MS/TP-RS485, Near Field Communication (NFC) IEEE 802.11ah. (See <https://datatracker.ietf.org/wg/6lo/> for details on the 6lo WG.) These technologies are similar in several aspects to [IEEE.802.15.4], which was the original 6LoWPAN target technology.
6lo WGは、6LoWPANを再利用および適合させて、Bluetooth Low Energy（BTLE）、ITU-T G.9959 [G9959]、Digital Enhanced Cordless Telecommunications（DECT）Ultra Low Energy（ULE）などのリンク層テクノロジーでIPv6サポートを有効にします、MS / TP-RS485、近距離無線通信（NFC）IEEE 802.11ah。 （6lo WGの詳細については、<https://datatracker.ietf.org/wg/6lo/>を参照してください。）これらのテクノロジーは、いくつかの点で、元の6LoWPANターゲットテクノロジーである[IEEE.802.15.4]に似ています。
6lo has mostly used the subset of 6LoWPAN techniques best suited for each lower-layer technology and has provided additional optimizations for technologies where the star topology is used, such as BTLE or DECT-ULE.
6loは主に、各下位層テクノロジーに最適な6LoWPAN技術のサブセットを使用しており、BTLEやDECT-ULEなどのスタートポロジーが使用されるテクノロジーに追加の最適化を提供しています。
The main constraint in these networks comes from the nature of the devices (constrained devices); whereas, in LPWANs, it is the network itself that imposes the most stringent constraints.
これらのネットワークの主な制約は、デバイス（制約されたデバイス）の性質によるものです。一方、LPWANでは、最も厳しい制約を課しているのはネットワーク自体です。
The IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) solution is dedicated to mesh networks that operate using [IEEE.802.15.4e] MAC with a deterministic slotted channel. Time-Slotted Channel Hopping (TSCH) can help to reduce collisions and to enable a better balance over the channels. It improves the battery life by avoiding the idle listening time for the return channel.
IEEE 802.15.4e（6tisch）ソリューションのTSCHモードでのIPv6は、確定的スロットチャネルを備えた[IEEE.802.15.4e] MACを使用して動作するメッシュネットワーク専用です。タイムスロットチャネルホッピング（TSCH）は、衝突を減らし、チャネル全体のバランスを改善するのに役立ちます。リターンチャネルのアイドルリスニング時間を回避することにより、バッテリ寿命を改善します。
A key element of 6tisch is the use of synchronization to enable determinism. TSCH and 6tisch may provide a standard scheduling function. The LPWAN networks probably will not support synchronization like the one used in 6tisch.
6tischの重要な要素は、同期を使用して決定論を有効にすることです。 TSCHおよび6tischは、標準のスケジューリング機能を提供する場合があります。 LPWANネットワークは、6tischで使用されるような同期をおそらくサポートしません。
RoHC is a header compression mechanism [RFC3095] developed for multimedia flows in a point-to-point channel. RoHC uses three levels of compression, each level having its own header format. In the first level, RoHC sends 52 bytes of header; in the second level, the header could be from 34 to 15 bytes; and in the third level, header size could be from 7 to 2 bytes. The level of compression is managed by a Sequence Number (SN), which varies in size from 2 bytes to 4 bits in the minimal compression. SN compression is done with an algorithm called Window-Least Significant Bits (W-LSB). This window has a 4-bit size representing 15 packets, so every 15 packets, RoHC needs to slide the window in order to receive the correct SN, and sliding the window implies a reduction of the level of compression. When packets are lost or errored, the decompressor loses context and drops packets until a bigger header is sent with more complete information. To estimate the performance of RoHC, an average header size is used. This average depends on the transmission conditions, but most of the time is between 3 and 4 bytes.
RoHCは、ポイントツーポイントチャネルのマルチメディアフロー用に開発されたヘッダー圧縮メカニズム[RFC3095]です。 RoHCは3つのレベルの圧縮を使用し、各レベルには独自のヘッダー形式があります。最初のレベルでは、RoHCは52バイトのヘッダーを送信します。第2レベルでは、ヘッダーは34〜15バイトです。 3番目のレベルでは、ヘッダーサイズは7〜2バイトです。圧縮のレベルは、シーケンス番号（SN）によって管理されます。SNは、最小圧縮でサイズが2バイトから4ビットまで変化します。 SN圧縮は、ウィンドウ最下位ビット（W-LSB）と呼ばれるアルゴリズムで行われます。このウィンドウは15パケットを表す4ビットサイズであるため、15パケットごとに、RoHCは正しいSNを受信するためにウィンドウをスライドさせる必要があり、ウィンドウをスライドさせると圧縮レベルが低下します。パケットが失われるかエラーが発生すると、デコンプレッサはコンテキストを失い、より完全な情報を含む大きなヘッダーが送信されるまでパケットをドロップします。 RoHCのパフォーマンスを推定するには、平均ヘッダーサイズを使用します。この平均は送信条件に依存しますが、ほとんどの場合3〜4バイトです。
RoHC has not been adapted specifically to the constrained hosts and networks of LPWANs: it does not take into account energy limitations nor the transmission rate. Additionally, RoHC context is synchronized during transmission, which does not allow better compression.
RoHCは、LPWANの制約されたホストおよびネットワークに特に適応されていません。エネルギー制限や伝送速度は考慮されていません。さらに、RoHCコンテキストは送信中に同期されるため、圧縮率は向上しません。
Most technologies considered by the LPWAN WG are based on a star topology, which eliminates the need for routing at that layer. Future work may address additional use cases that may require adaptation of existing routing protocols or the definition of new ones. As of the time of writing, work similar to that done in the Routing Over Low-Power and Lossy Network (ROLL) WG and other routing protocols are out of scope of the LPWAN WG.
LPWAN WGで検討されているほとんどのテクノロジは、スタートポロジに基づいているため、その層でルーティングする必要がありません。今後の作業では、既存のルーティングプロトコルの適合または新しいプロトコルの定義が必要になる可能性がある追加のユースケースに対処する可能性があります。これを書いている時点では、Routing Over Low-Power and Lossy Network（ROLL）WGや他のルーティングプロトコルで行われる作業と同様の作業は、LPWAN WGの範囲外です。
The Constrained Application Protocol (CoAP) [RFC7252] provides a RESTful framework for applications intended to run on constrained IP networks. It may be necessary to adapt CoAP or related protocols to take into account the extreme duty cycles and the potentially extremely limited throughput of LPWANs.
制約付きアプリケーションプロトコル（CoAP）[RFC7252]は、制約付きIPネットワークで実行することを目的としたアプリケーションにRESTfulフレームワークを提供します。 LPWANの極端なデューティサイクルと潜在的に極端に制限されたスループットを考慮に入れるために、CoAPまたは関連プロトコルを適合させる必要がある場合があります。
For example, some of the timers in CoAP may need to be redefined. Taking into account CoAP acknowledgments may allow the reduction of L2 acknowledgments. On the other hand, the current work in progress in the CoRE WG where the Constrained Management Interface (COMI) / Constrained Objects Language (CoOL) network management interface which, uses Structured Identifiers (SIDs) to reduce payload size over CoAP may prove to be a good solution for the LPWAN technologies. The overhead is reduced by adding a dictionary that matches a URI to a small identifier and a compact mapping of the YANG data model into the Concise Binary Object Representation (CBOR).
たとえば、CoAPの一部のタイマーを再定義する必要がある場合があります。 CoAP確認応答を考慮すると、L2確認応答を削減できる場合があります。一方、CoAP上のペイロードサイズを削減するために構造化識別子（SID）を使用するConstrained Management Interface（COMI）/ Constrained Objects Language（CoOL）ネットワーク管理インターフェイスであるCoRE WGで現在進行中の作業は、 LPWANテクノロジの優れたソリューション。 URIを小さな識別子に一致させるディクショナリを追加し、YANGデータモデルをコンパクトバイナリオブジェクト表現（CBOR）にコンパクトにマッピングすることにより、オーバーヘッドが削減されます。
LPWAN nodes can be mobile. However, LPWAN mobility is different from the one specified for Mobile IP. LPWAN implies sporadic traffic and will rarely be used for high-frequency, real-time communications. The applications do not generate a flow; they need to save energy and, most of the time, the node will be down.
LPWANノードはモバイルにすることができます。ただし、LPWANモビリティは、モバイルIPに指定されたものとは異なります。 LPWANは散発的なトラフィックを意味し、高頻度のリアルタイム通信にはほとんど使用されません。アプリケーションはフローを生成しません。彼らはエネルギーを節約する必要があり、ほとんどの場合、ノードはダウンします。
In addition, LPWAN mobility may mostly apply to groups of devices that represent a network; in which case, mobility is more a concern for the Gateway than the devices. Network Mobility (NEMO) [RFC3963] or other mobile Gateway solutions (such as a Gateway with an LTE uplink) may be used in the case where some end devices belonging to the same network Gateway move from one point to another such that they are not aware of being mobile.
さらに、LPWANモビリティは、主にネットワークを表すデバイスのグループに適用されます。その場合、モビリティはデバイスよりもゲートウェイにとってより重要です。ネットワークモビリティ（NEMO）[RFC3963]または他のモバイルゲートウェイソリューション（LTEアップリンクを備えたゲートウェイなど）は、同じネットワークゲートウェイに属する一部のエンドデバイスが1つのポイントから別のポイントに移動して、移動できない場合に使用できます。モバイルであることを認識しています。
The Domain Name System (DNS) [RFC1035], enables applications to name things with a globally resolvable name. Many protocols use the DNS to identify hosts, for example, applications using CoAP.
ドメインネームシステム（DNS）[RFC1035]により、アプリケーションはグローバルに解決可能な名前で名前を付けることができます。 CoAPを使用するアプリケーションなど、多くのプロトコルはDNSを使用してホストを識別します。
The DNS query/answer protocol as a precursor to other communication within the Time-To-Live (TTL) of a DNS answer is clearly problematic in an LPWAN, say where only one round-trip per hour can be used, and with a TTL that is less than 3600 seconds. It is currently unclear whether and how DNS-like functionality might be provided in LPWANs.
DNS回答の存続可能時間（TTL）内の他の通信の前兆としてのDNSクエリ/回答プロトコルは、LPWANで明らかに問題があります。たとえば、1時間あたり1回の往復しか使用できず、TTLこれは3600秒未満です。現在、LPWANでDNSのような機能が提供されるかどうか、またどのように提供されるかは不明です。
Most LPWAN technologies integrate some authentication or encryption mechanisms that were defined outside the IETF. The LPWAN WG may need to do work to integrate these mechanisms to unify management. A standardized Authentication, Authorization, and Accounting (AAA) infrastructure [RFC2904] may offer a scalable solution for some of the security and management issues for LPWANs. AAA offers centralized management that may be of use in LPWANs, for example [LoRaWAN-AUTH] and [LoRaWAN-RADIUS] suggest possible security processes for a LoRaWAN network. Similar mechanisms may be useful to explore for other LPWAN technologies.
ほとんどのLPWANテクノロジーは、IETFの外部で定義されたいくつかの認証または暗号化メカニズムを統合しています。 LPWAN WGは、これらのメカニズムを統合して管理を統一するための作業を行う必要がある場合があります。標準化された認証、承認、およびアカウンティング（AAA）インフラストラクチャ[RFC2904]は、LPWANのセキュリティと管理の問題の一部に対してスケーラブルなソリューションを提供する場合があります。 AAAは、LPWANで使用できる集中管理を提供します。たとえば、[LoRaWAN-AUTH]と[LoRaWAN-RADIUS]は、LoRaWANネットワークに可能なセキュリティプロセスを提案します。同様のメカニズムは、他のLPWANテクノロジーを探索するのに役立つ場合があります。
Some applications using LPWANs may raise few or no privacy considerations. For example, temperature sensors in a large office building may not raise privacy issues. However, the same sensors, if deployed in a home environment, and especially if triggered due to human presence, can raise significant privacy issues: if an end device emits a (encrypted) packet every time someone enters a room in a home, then that traffic is privacy sensitive. And the more that the existence of that traffic is visible to network entities, the more privacy sensitivities arise. At this point, it is not clear whether there are workable mitigations for problems like this. In a more typical network, one would consider defining padding mechanisms and allowing for cover traffic. In some LPWANs, those mechanisms may not be feasible. Nonetheless, the privacy challenges do exist and can be real; therefore, some solutions will be needed. Note that many aspects of solutions in this space may not be visible in IETF specifications but can be, e.g., implementation or deployment specific.
LPWANを使用する一部のアプリケーションでは、プライバシーに関する考慮事項がほとんどないか、まったくない場合があります。たとえば、大きなオフィスビルの温度センサーはプライバシーの問題を引き起こさない場合があります。ただし、同じセンサーを家庭環境に配置した場合、特に人間の存在によってトリガーされた場合、プライバシーの重大な問題が発生する可能性があります。エンドデバイスが誰かが家の部屋に入るたびに（暗号化された）パケットを送信すると、トラフィックはプライバシーに敏感です。そして、そのトラフィックの存在がネットワークエンティティに見えるほど、プライバシーの機密性が高まります。現時点では、このような問題に対して有効な緩和策があるかどうかは明らかではありません。より一般的なネットワークでは、パディングメカニズムを定義し、カバートラフィックを許可することを検討します。一部のLPWANでは、これらのメカニズムが実現できない場合があります。それにもかかわらず、プライバシーの課題は実際に存在し、現実になり得ます。したがって、いくつかのソリューションが必要になります。このスペースのソリューションの多くの側面はIETF仕様では表示されない場合がありますが、たとえば、実装や展開に固有である可能性があることに注意してください。
Another challenge for LPWANs will be how to handle key management and associated protocols. In a more traditional network (e.g., the Web), servers can "staple" Online Certificate Status Protocol (OCSP) responses in order to allow browsers to check revocation status for presented certificates [RFC6961]. While the stapling approach is likely something that would help in an LPWAN, as it avoids an RTT, certificates and OCSP responses are bulky items and will prove challenging to handle in LPWANs with bounded bandwidth.
LPWANのもう1つの課題は、キー管理と関連プロトコルの処理方法です。より伝統的なネットワーク（Webなど）では、サーバーはオンライン証明書ステータスプロトコル（OCSP）の応答を「ステープル」して、ブラウザーが提示された証明書の失効ステータスを確認できるようにします[RFC6961]。ステープルアプローチはLPWANで役立つ可能性が高いものですが、RTTを回避するため、証明書とOCSP応答はかさばるアイテムであり、帯域幅が制限されているLPWANでの処理は困難です。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[ANSI-4957-000] ANSI/TIA, "Architecture Overview for the Smart Utility Network", ANSI/TIA-4957.0000 , May 2013.
[ANSI-4957-000] ANSI / TIA、「Architecture Overview for the Smart Utility Network」、ANSI / TIA-4957.0000、2013年5月。
[ANSI-4957-210] ANSI/TIA, "Multi-Hop Delivery Specification of a Data Link Sub-Layer", ANSI/TIA-4957.210 , May 2013.
[ANSI-4957-210] ANSI / TIA、「Multi-Hop Delivery Specification of a Data Link Sub-Layer」、ANSI / TIA-4957.210、2013年5月。
[arib_ref] ARIB, "920MHz-Band Telemeter, Telecontrol and Data Transmission Radio Equipment", ARIB STD-T108 Version 1.0, February 2012.
[arib_ref] ARIB、「920MHz帯テレメータ、テレコントロールおよびデータ伝送無線機器」、ARIB STD-T108バージョン1.0、2012年2月。
[ETSI-TS-102-887-2] ETSI, "Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range Devices; Smart Metering Wireless Access Protocol; Part 2: Data Link Layer (MAC Sub-layer)", ETSI TS 102 887-2, Version V1.1.1, September 2013.
[ETSI-TS-102-887-2] ETSI、「電磁両立性および無線スペクトル問題（ERM）;短距離デバイス;スマートメータリングワイヤレスアクセスプロトコル;パート2：データリンク層（MACサブ層）」、ETSI TS 102 887-2、バージョンV1.1.1、2013年9月。
[etsi_ref1] ETSI, "Short Range Devices (SRD) operating in the frequency range 25 MHz to 1 000 MHz; Part 1: Technical characteristics and methods of measurement", Draft ETSI EN 300-220-1, Version V3.1.0, May 2016.
[etsi_ref1] ETSI、「25 MHzから1000 MHzの周波数範囲で動作する短距離デバイス（SRD）、パート1：技術特性と測定方法」、ETSI EN 300-220-1、バージョンV3.1.0、5月2016。
[etsi_ref2] ETSI, "Short Range Devices (SRD) operating in the frequency range 25 MHz to 1 000 MHz; Part 2: Harmonised Standard covering the essential requirements of article 3.2 of Directive 2014/53/EU for non specific radio equipment", Final draft ETSI EN 300-220-2 P300-220-2, Version V3.1.1, November 2016.
[etsi_ref2] ETSI、「25 MHzから1000 MHzの周波数範囲で動作する短距離デバイス（SRD）、パート2：非特定の無線機器に関する指令2014/53 / EUの第3.2条の必須要件をカバーする調和規格」、最終ドラフトETSI EN 300-220-2 P300-220-2、バージョンV3.1.1、2016年11月。
[etsi_unb] ETSI ERM, "System Reference document (SRdoc); Short Range Devices (SRD); Technical characteristics for Ultra Narrow Band (UNB) SRDs operating in the UHF spectrum below 1 GHz", ETSI TR 103 435, Version V1.1.1, February 2017.
[etsi_unb] ETSI ERM、「システムリファレンスドキュメント（SRdoc）;短距離デバイス（SRD）; 1 GHz未満のUHFスペクトルで動作する超狭帯域（UNB）SRDの技術特性」、ETSI TR 103 435、バージョンV1.1.1 、2017年2月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI),Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017, <http://standards.ieee.org/develop/regauth/tut/eui.pdf>.
[EUI64] IEEE、「64ビットグローバル識別子（EUI）、組織的に一意の識別子（OUI）、および企業ID（CID）のガイドライン」、2017年8月、<http://standards.ieee.org/develop/regauth/ tut / eui.pdf>。
[FANOV] IETF, "Wi-SUN Alliance Field Area Network (FAN) Overview", IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35-wi-sun-presentation-00.pdf>.
[FANOV] IETF、「Wi-SUNアライアンスフィールドエリアネットワーク（FAN）の概要」、IETF 97、2016年11月、<https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35- wi-sun-presentation-00.pdf>。
[fcc_ref] "Telecommunication Radio Frequency Devices - Operation within the bands 902-928 MHz, 2400-2483.5 MHz, and 5725-5850 MHz.", FCC CFR 47 15.247, June 2016.
[fcc_ref]「Telecommunication Radio Frequency Devices-Operation within the band 902-928 MHz、2400-2483.5 MHz、and 5725-5850 MHz。」、FCC CFR 47 15.247、2016年6月。
[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>。
[IEEE.802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11.
[IEEE.802.11] IEEE、「IEEE Standard for Information technology-Telecommunications and information exchange between system Local and metropolitan area network--Specific requirements Part 11：Wireless LAN Medium Access Control（MAC）and Physical Layer（PHY）Specifications」、 IEEE 802.11。
[IEEE.802.15.12] IEEE, "Upper Layer Interface (ULI) for IEEE 802.15.4 Low-Rate Wireless Networks", IEEE 802.15.12.
[IEEE.802.15.12] IEEE、「IEEE 802.15.4 Low-Rate Wireless Networksの上位層インターフェイス（ULI）」、IEEE 802.15.12。
[IEEE.802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>.
[IEEE.802.15.4] IEEE、「IEEE Standard for Low-Rate Wireless Networks」、IEEE 802.15.4、<https://standards.ieee.org/findstds/standard/802.15.4-2015.html>。
[IEEE.802.15.4e] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", IEEE 802.15.4e.
[IEEE.802.15.4e] IEEE、「IEEE Standard for Local and Metropolitan Area Network--Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）Amendment 1：MAC sublayer」、IEEE 802.15.4e。
[IEEE.802.15.4g] IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 3: Physical Layer (PHY) Specifications for Low-Data-Rate, Wireless, Smart Metering Utility Networks", IEEE 802.15.4g.
[IEEE.802.15.4g] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Part 15.4：Low-Rate Wireless Personal Area Networks（LR-WPANs）Amendment 3：Physical Layer（PHY）Specifications for Low-Data-Rate 、ワイヤレス、スマートメータリングユーティリティネットワーク」、IEEE 802.15.4g。
[IEEE.802.15.9] IEEE, "IEEE Recommended Practice for Transport of Key Management Protocol (KMP) Datagrams", IEEE Standard 802.15.9, 2016, <https://standards.ieee.org/findstds/ standard/802.15.9-2016.html>.
[IEEE.802.15.9] IEEE、「キー管理プロトコル（KMP）データグラムのトランスポートに関するIEEE推奨プラクティス」、IEEE標準802.15.9、2016、<https://standards.ieee.org/findstds/ standard / 802.15。 9-2016.html>。
[IEEE.802.1AR] ANSI/IEEE, "IEEE Standard for Local and metropolitan area networks - Secure Device Identity", IEEE 802.1AR.
[IEEE.802.1AR] ANSI / IEEE、「IEEE Standard for Local and Metropolitan Area Network-Secure Device Identity」、IEEE 802.1AR。
[IEEE.802.1x] IEEE, "Port Based Network Access Control", IEEE 802.1x.
[IEEE.802.1x] IEEE、「ポートベースのネットワークアクセスコントロール」、IEEE 802.1x。
[LoRaSpec] LoRa Alliance, "LoRaWAN Specification Version V1.0.2", July 2016, <https://lora-alliance.org/sites/default/ files/2018-05/lorawan1_0_2-20161012_1398_1.pdf>.
[LoRaSpec] LoRa Alliance、「LoRaWAN仕様バージョンV1.0.2」、2016年7月、<https://lora-alliance.org/sites/default/ files / 2018-05 / lorawan1_0_2-20161012_1398_1.pdf>。
[LoRaWAN] Farrell, S. and A. Yegin, "LoRaWAN Overview", Work in Progress, draft-farrell-lpwan-lora-overview-01, October 2016.
[LoRaWAN] Farrell、S。およびA. Yegin、「LoRaWANの概要」、進行中の作業、draft-farrell-lpwan-lora-overview-01、2016年10月。
[LoRaWAN-AUTH] Garcia, D., Marin, R., Kandasamy, A., and A. Pelov, "LoRaWAN Authentication in Diameter", Work in Progress, draft-garcia-dime-diameter-lorawan-00, May 2016.
[LoRaWAN-AUTH]ガルシアD.、マリンR.、カンダサミーA.、およびA.ペロフ、「DiameterでのLoRaWAN認証」、作業中、draft-garcia-dime-diameter-lorawan-00、2016年5月。
[LoRaWAN-RADIUS] Garcia, D., Lopez, R., Kandasamy, A., and A. Pelov, "LoRaWAN Authentication in RADIUS", Work in Progress, draft-garcia-radext-radius-lorawan-03, May 2017.
[LoRaWAN-RADIUS]ガルシアD.、ロペスR.、カンダサミーA.、およびA.ペロフ、「RADIUSでのLoRaWAN認証」、作業中、draft-garcia-radext-radius-lorawan-03、2017年5月。
[LPWAN-GAP] Minaburo, A., Ed., Gomez, C., Ed., Toutain, L., Paradells, J., and J. Crowcroft, "LPWAN Survey and GAP Analysis", Work in Progress, draft-minaburo-lpwan-gap-analysis-02, October 2016.
[LPWAN-GAP] Minaburo、A。、編、Gomez、C。、編、Toutain、L.、Paradells、J.、J。Crowcroft、「LPWAN調査とGAP分析」、作業中、ドラフト- minaburo-lpwan-gap-analysis-02、2016年10月。
[NB-IoT] Ratilainen, A., "NB-IoT characteristics", Work in Progress, draft-ratilainen-lpwan-nb-iot-00, July 2016.
[NB-IoT] Ratilainen、A。、「NB-IoTの特徴」、Work in Progress、draft-Ratilainen-lpwan-nb-iot-00、2016年7月。
[nbiot-ov] IEEE, "NB-IoT Technology Overview and Experience from Cloud-RAN Implementation", Volume 24, Issue 3 Pages 26-32, DOI 10.1109/MWC.2017.1600418, June 2017.
[nbiot-ov] IEEE、「NB-IoTテクノロジーの概要とCloud-RAN実装からの経験」、第24巻、第3号、26〜32ページ、DOI 10.1109 / MWC.2017.1600418、2017年6月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https://www.rfc-editor.org/info/rfc1035>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<https://www.rfc-editor.org/info/ rfc2460>。
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Framework", RFC 2904, DOI 10.17487/RFC2904, August 2000, <https://www.rfc-editor.org/info/rfc2904>.
[RFC2904] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、de Bruijn、B.、de Laat、C.、Holdrege、M。、およびD. Spence、 「AAA Authorization Framework」、RFC 2904、DOI 10.17487 / RFC2904、2000年8月、<https://www.rfc-editor.org/info/rfc2904>。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, DOI 10.17487/RFC3095, July 2001, <https://www.rfc-editor.org/info/rfc3095>.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：RTP、UDP、 ESP、および非圧縮」、RFC 3095、DOI 10.17487 / RFC3095、2001年7月、<https://www.rfc-editor.org/info/rfc3095>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<https://www.rfc-editor.org/info/rfc3315>。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.
[RFC3963] Devarapalli、V。、脇川、R.、Petrescu、A。、およびP. Thubert、「Network Mobility（NEMO）Basic Support Protocol」、RFC 3963、DOI 10.17487 / RFC3963、2005年1月、<https：// www.rfc-editor.org/info/rfc3963>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https://www.rfc-editor.org/info/rfc4301>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443]コンタ、A。、ディアリング、S。、およびM.グプタ編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、STD 89、RFC 4443、DOI 10.17487 / RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：/ /www.rfc-editor.org/info/rfc4861>。
[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>。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5216]サイモン、D。、アボバ、B。、およびR.ハースト、「EAP-TLS認証プロトコル」、RFC 5216、DOI 10.17487 / RFC5216、2008年3月、<https://www.rfc-editor.org / info / rfc5216>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[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>。
[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>。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961] Pettersen、Y。、「The Transport Layer Security（TLS）Multiple Certificate Status Request Extension」、RFC 6961、DOI 10.17487 / RFC6961、2013年6月、<https://www.rfc-editor.org/info/rfc6961 >。
[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>。
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <https://www.rfc-editor.org/info/rfc7452>.
[RFC7452] Tschofenig、H.、Arkko、J.、Thaler、D。、およびD. McPherson、「Architectural Considerations in Smart Object Networking」、RFC 7452、DOI 10.17487 / RFC7452、2015年3月、<https：// www。 rfc-editor.org/info/rfc7452>。
[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>。
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8065]ターラー、D。、「IPv6アダプテーションレイヤーメカニズムのプライバシーに関する考慮事項」、RFC 8065、DOI 10.17487 / RFC8065、2017年2月、<https://www.rfc-editor.org/info/rfc8065>。
[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>。
[RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet of Things Software Update (IoTSU) Workshop 2016", RFC 8240, DOI 10.17487/RFC8240, September 2017, <https://www.rfc-editor.org/info/rfc8240>.
[RFC8240] Tschofenig、H。およびS. Farrell、「Internet of Things Software Update（IoTSU）Workshop 2016」、RFC 8240、DOI 10.17487 / RFC8240、2017年9月、<https：//www.rfc-editor。 org / info / rfc8240>。
[Sigfox] Zuniga, J. and B. PONSARD, "Sigfox System Description", Work in Progress, draft-zuniga-lpwan-sigfox-system-description-04, December 2017.
[Sigfox] Zuniga、J.およびB. PONSARD、「Sigfox System Description」、進行中の作業、draft-zuniga-lpwan-sigfox-system-description-04、2017年12月。
[TGPP23720] 3GPP, "Study on architecture enhancements for Cellular Internet of Things", 3GPP TS 23.720 13.0.0, 2016.
[TGPP23720] 3GPP、「Cellular Internet of Thingsのアーキテクチャー拡張に関する研究」、3GPP TS 23.720 13.0.0、2016。
[TGPP33203] 3GPP, "3G security; Access security for IP-based services", 3GPP TS 23.203 13.1.0, 2016.
[TGPP33203] 3GPP、「3Gセキュリティ、IPベースのサービスのアクセスセキュリティ」、3GPP TS 23.203 13.1.0、2016。
[TGPP36201] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical layer; General description", 3GPP TS 36.201 13.2.0, 2016.
[TGPP36201] 3GPP、「Evolved Universal Terrestrial Radio Access（E-UTRA）; LTE physical layer; General description」、3GPP TS 36.201 13.2.0、2016。
[TGPP36300] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2", 3GPP TS 36.300 13.4.0, 2016, <http://www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>.
[TGPP36300] 3GPP、「進化したユニバーサル地上無線アクセス（E-UTRA）および進化したユニバーサル地上無線アクセスネットワーク（E-UTRAN）、全体的な説明、ステージ2」、3GPP TS 36.300 13.4.0、2016、<http：// www.3gpp.org/ftp/Specs/2016-09/Rel-14/36_series/>。
[TGPP36321] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification", 3GPP TS 36.321 13.2.0, 2016.
[TGPP36321] 3GPP、「Evolved Universal Terrestrial Radio Access（E-UTRA）; Medium Access Control（MAC）protocol specification」、3GPP TS 36.321 13.2.0、2016。
[TGPP36322] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification", 3GPP TS 36.322 13.2.0, 2016.
[TGPP36322] 3GPP、「Evolved Universal Terrestrial Radio Access（E-UTRA）; Radio Link Control（RLC）protocol specification」、3GPP TS 36.322 13.2.0、2016。
[TGPP36323] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification (Not yet available)", 3GPP TS 36.323 13.2.0, 2016.
[TGPP36323] 3GPP、「Evolved Universal Terrestrial Radio Access（E-UTRA）; Packet Data Convergence Protocol（PDCP）specification（Not available）」、3GPP TS 36.323 13.2.0、2016。
[TGPP36331] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification", 3GPP TS 36.331 13.2.0, 2016.
[TGPP36331] 3GPP、「進化したユニバーサル地上無線アクセス（E-UTRA）;無線リソース制御（RRC）;プロトコル仕様」、3GPP TS 36.331 13.2.0、2016。
[USES-6LO] Hong, Y., Gomez, C., Choi, Y-H., and D-Y. Ko, "IPv6 over Constrained Node Networks(6lo) Applicability & Use cases", Work in Progress, draft-hong-6lo-use-cases-03, October 2016.
[USES-6LO] Hong、Y.、Gomez、C.、Choi、Y-H。、D-Y。 Ko、「IPv6 over Constrained Node Networks（6lo）Applicability＆Use Cases」、Work in Progress、draft-hong-6lo-use-cases-03、2016年10月。
[wisun-pressie1] Beecher, P., "Wi-SUN Alliance", March 2017, <http://indiasmartgrid.org/event2017/10-03-2017/4.%20Round table%20on%20Communication%20and%20Cyber%20Security/1.%20P hil%20Beecher.pdf>.
[wisun-pressie1] Beecher、P。、「Wi-SUN Alliance」、2017年3月、<http://indiasmartgrid.org/event2017/10-03-2017/4.%20Round table％20on％20Communication％20and％20Cyber ％20Security / 1.％20P hil％20Beecher.pdf>。
[wisun-pressie2] Heile, B., "Wi-SUN Alliance Field Area Network (FAN)Overview", As presented at IETF 97, November 2016, <https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35-wi-sun-presentation-00.pdf>.
[wisun-pressie2] Heile、B。、「Wi-SUNアライアンスフィールドエリアネットワーク（FAN）の概要」、IETF 97、2016年11月に発表されたとおり、<https://www.ietf.org/proceedings/97/slides/ slides-97-lpwan-35-wi-sun-presentation-00.pdf>。
Acknowledgments
謝辞
Thanks to all those listed in the Contributors section for the excellent text. Errors in the handling of that are solely the editor's fault.
優れたテキストを提供してくれた貢献者のセクションにリストされているすべての人に感謝します。その処理のエラーは、単に編集者の責任です。
In addition to those in the Contributors section, thanks are due to (in alphabetical order) the following for comments:
「貢献者」セクションのコメントに加えて、コメントの（アルファベット順）以下に感謝します。
Abdussalam Baryun Andy Malis Arun (arun@acklio.com) Behcet SariKaya Dan Garcia Carrillo Jiazi Yi Mirja Kuhlewind Paul Duffy Russ Housley Samita Chakrabarti Thad Guidry Warren Kumari
Abdussalam Baryun Andy Malis Arun（arun@acklio.com）Behcet SariKaya Dan Garcia Carrillo Jiazi Yi Mirja Kuhlewind Paul Duffy Russ Housley Samita Chakrabarti Thad Guidry Warren Kumari
Alexander Pelov and Pascal Thubert were the LPWAN WG Chairs while this document was developed.
このドキュメントが作成されている間、Alexander PelovとPascal ThubertがLPWAN WGの議長を務めました。
Stephen Farrell's work on this memo was supported by Pervasive Nation, the Science Foundation Ireland's CONNECT centre national IoT network <https://connectcentre.ie/pervasive-nation/>.
このメモに関するスティーブンファレルの作業は、アイルランド科学基金のCONNECTセンター全国IoTネットワーク<https://connectcentre.ie/pervasive-nation/>であるPervasive Nationによってサポートされました。
Contributors
貢献者
As stated above, this document is mainly a collection of content developed by the full set of contributors listed below. The main input documents and their authors were:
上記のように、このドキュメントは主に以下にリストされたコントリビューターのフルセットによって開発されたコンテンツのコレクションです。主な入力ドキュメントとその作成者は次のとおりです。
o Text for Section 2.1 was provided by Alper Yegin and Stephen Farrell in [LoRaWAN].
o セクション2.1のテキストは、[LoRaWAN]でAlper YeginとStephen Farrellによって提供されました。
o Text for Section 2.2 was provided by Antti Ratilainen in [NB-IoT].
o セクション2.2のテキストは、Antti Ratilainenによって[NB-IoT]で提供されました。
o Text for Section 2.3 was provided by Juan Carlos Zuniga and Benoit Ponsard in [Sigfox].
o セクション2.3のテキストは、[Sigfox]のJuan Carlos ZunigaとBenoit Ponsardによって提供されました。
o Text for Section 2.4 was provided via personal communication from Bob Heile and was authored by Bob and Sum Chin Sean. There is no Internet-Draft for that at the time of writing.
o セクション2.4のテキストは、Bob Heileからの個人的なコミュニケーションによって提供され、BobとSum Chin Seanによって作成されました。執筆時点では、そのためのインターネットドラフトはありません。
o Text for Section 4 was provided by Ana Minabiru, Carles Gomez, Laurent Toutain, Josep Paradells, and Jon Crowcroft in [LPWAN-GAP]. Additional text from that document is also used elsewhere above.
o セクション4のテキストは、Ana Minabiru、Carles Gomez、Laurent Toutain、Josep Paradells、Jon Crowcroftによって[LPWAN-GAP]で提供されました。そのドキュメントからの追加のテキストは、上記の他の場所でも使用されます。
The full list of contributors is as follows:
貢献者の完全なリストは次のとおりです。
Jon Crowcroft University of Cambridge JJ Thomson Avenue Cambridge, CB3 0FD United Kingdom
ジョンクロウクロフトケンブリッジ大学JJトムソンアベニューケンブリッジ、CB3 0FDイギリス
Email: jon.crowcroft@cl.cam.ac.uk
Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain
カルレスゴメスUPC / i2CAT C / Esteve Terradas、7カステルデフェルス08860スペイン
Email: carlesgo@entel.upc.edu Bob Heile Wi-Sun Alliance 11 Robert Toner Blvd, Suite 5-301 North Attleboro, MA 02763 United States of America
メール：carlesgo@entel.upc.eduボブハイルWi-Sunアライアンス11 Robert Toner Blvd、Suite 5-301 North Attleboro、MA 02763アメリカ合衆国
Phone: +1-781-929-4832
Email: bheile@ieee.org
Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex France
Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510セッソンセビニェセデックスフランス
Email: ana@ackl.io
Josep PAradells UPC/i2CAT C/Jordi Girona, 1-3 Barcelona 08034 Spain
Josep PAradells UPC / i2CAT C / Jordi Girona、1-3バルセロナ08034スペイン
Email: josep.paradells@entel.upc.edu
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara、CA 95050アメリカ合衆国
Email: charliep@computer.org
Benoit Ponsard Sigfox 425 rue Jean Rostand Labege 31670 France
Benoit Ponsard Sigfox 425 rue Jean Rostand Labege 31670フランス
Email: Benoit.Ponsard@sigfox.com
URI: http://www.sigfox.com/
Antti Ratilainen Ericsson Hirsalantie 11 Jorvas 02420 Finland
Antti Ratilainen Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: antti.ratilainen@ericsson.com
Chin-Sean SUM Wi-Sun Alliance 20, Science Park Rd 117674 Singapore
Chin-Sean SUM Wi-Sun Alliance 20、Science Park Rd 117674 Singapore
Phone: +65 6771 1011
Email: sum@wi-sun.org
Laurent Toutain Institut MINES TELECOM ; TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
Laurent Toutain Institute MINES TELECOM; TELECOM Bretagne 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France
Email: Laurent.Toutain@telecom-bretagne.eu
Alper Yegin Actility Paris France
Alper Yegin Actility Paris France
Email: alper.yegin@actility.com
Juan Carlos Zuniga Sigfox 425 rue Jean Rostand Labege 31670 France
フアンカルロスズニーガSigfox 425 rue Jean Rostand Labege 31670フランス
Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/
Author's Address
Stephen Farrell (editor) Trinity College Dublin Dublin 2 Ireland
スティーブンファレル（編集者）トリニティカレッジダブリンダブリン2アイルランド
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie