Internet Engineering Task Force (IETF) S. Farrell, Ed.
Request for Comments: 8376 Trinity College Dublin
Category: Informational May 2018
ISSN: 2070-1721
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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（LPWAN）工作组（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.
现有的试点部署已显示出巨大的潜力，并在这些技术中产生了很大的工业兴趣。在撰写本文时，基本上没有任何LPWAN终端设备（Wi-SUN除外）具有IP功能。将LPWAN连接到Internet将在互操作性、应用程序部署和管理（以及其他方面）方面为这些网络提供重大好处。LPWAN工作组的目标是，在必要时，使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工作组正在考虑的一组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是一种基于工业、科学和医疗（ISM）的无线技术，用于LoRa联盟（一个成员联盟）开发的远程低功耗低数据速率应用<https://www.lora-alliance.org/>. 本文件基于LoRa规范[LoRaSpec]的1.0.2版。该规范是公开的，并且已经在全球范围内进行了多次部署。
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链路连接到网络服务器，而终端设备使用可在一个或多个网关接收的单跳WAN通信。通信通常是双向的；就整体带宽可用性而言，从终端设备到网络服务器的上行链路通信是有利的。
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
+----------+
|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客户端设备，有时称为“mote”。与网关通信。
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的Internet端的服务器，用于处理来自终端设备的加入请求。
o Uplink message: refers to communications from an end device to a network server or application via one or more Gateways.
o 上行消息：指通过一个或多个网关从终端设备到网络服务器或应用程序的通信。
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 下行链路消息：指从网络服务器或应用程序通过一个网关到单个终端设备或一组终端设备的通信（考虑多播）。
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，大多数终端设备上通常只运行一个应用程序。此处不再进一步描述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.
罗兰万无线电使用ISM频段，例如，在欧盟内使用433兆赫和868兆赫，在美洲使用915兆赫。
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类设备开启其接收器两个短接收窗口，该窗口与传输窗口的末端偏移。终端设备只能在相关接收窗口结束后发送后续上行链路帧。当设备加入LoRaWAN网络时，该过程的某些部分也会出现类似的超时。
|----------------------------| |--------| |--------|
| Tx | | Rx | | Rx |
|----------------------------| |--------| |--------|
|---------|
Rx delay 1
|------------------------|
Rx delay 2
|----------------------------| |--------| |--------|
| 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给出了一个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 |
+-----------------------+-------------------------------------------+
+-----------------------+-------------------------------------------+
| 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 |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| 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个八位字节，有效负载只剩下11个八位字节（包括MAC层选项）。但是，这些设置不适用于连接过程——终端设备需要使用可以为连接过程发送23字节连接请求消息的通道和数据速率。
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保留用于特定于LoRaWAN的消息传递，例如终端设备网络参数的配置（可用信道、数据速率、ADR参数、Rx延迟1和2等）。
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，还有用于处理网络访问的加入请求和加入响应（也称为加入接受）消息。而所谓的“MAC命令”（见下文）最长可达15字节，可以在选项字段（“FOpts”）中使用。
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.
有许多MAC命令用于链路和设备状态检查、ADR和占空比协商，以及管理RX窗口和无线信道设置。例如，链路检查响应消息允许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命令由网络服务器启动。例如，一个命令允许网络服务器请求终端设备减少其占空比，以仅使用区域中允许的最大值的一部分。另一种方法允许网络服务器通过终端设备的响应查询终端设备的电源状态，该响应指定终端设备是否具有外部电源或由电池供电（在这种情况下，还将相对电池电量发送到网络服务器）。
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联盟分配给网络的24位网络标识符（NetID）分配设备地址。非漫游设备可以由网络分配设备地址，而无需依赖LoRa联盟分配的网络ID。
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标识，该AppEUI被假定为注册的IEEE EUI64值[EUI64]。此外，设备需要有两个对称会话密钥，一个用于保护网络工件（端口=0），一个用于保护NwkSKey，另一个用于保护应用层流量，即AppSKey。这两个密钥都用于128位AES加密操作。因此，一个选项是终端设备以某种方式（预先）提供上述所有加信道信息；在这种情况下，终端设备可以简单地开始传输。鉴于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 |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| 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 |
+---------+----------------------------------------------------+
+---------+----------------------------------------------------+
| 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.
连接过程涉及一个特殊的交换，终端设备在连接请求上行链路消息中断言appui和devui（完整性受长期AppKey保护，但未加密）。然后将其路由到网络服务器，网络服务器与知道该AppKey的实体交互以验证加入请求。如果一切顺利，则从网络服务器向终端设备返回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）发送时受到保护。但是，作为帧选项（“FOPT”）的MAC命令以明文形式发送。被动攻击者可以看到任何作为帧选项发送的MAC命令，而不仅仅是作为有效负载发送的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对有效载荷进行加密，并使用AppSKey从[IEEE.802.15.4]派生的计数器模式。网关不需要提供AppSKey或NwkSKey，所有基础设施端加密都发生在网络服务器中（或“后面”）。当会话密钥作为连接过程的结果从AppKey派生时，将专门处理连接接受消息负载。
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.
连接接受明文的长度始终小于16字节，因此使用电子码本（ECB）模式来保护连接接受消息。Join Accept消息包含一个AppNonce（24位值），该AppNonce与其他Join Accept内容（如DevAddr）一起使用AES加密操作在终端设备上恢复。一旦连接接受有效负载可用于终端设备，会话密钥将从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版中完成，2017年3GPP第14版中规定了NB IoT的进一步增强（例如，以多播支持的形式）。后续版本将开发更多功能和改进，但NB IoT已准备好自2016年开始部署；它的部署相当简单，尤其是在运营商基站中进行软件升级的现有LTE网络中。有关为NB IoT指定的内容的更多信息，3GPP规范36.300[TGPP36300]提供了演进的通用地面无线电接入网络（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，最大传输单元（MTU）大小为1600字节，受PDCP层（协议结构见图4）限制，PDCP层是用户平面中的最高层，稍后解释。最大到所述MTU大小的任何分组大小都可以从更高层传递到NB-IoT堆栈，分组的分段在RLC层中执行，RLC层可以将数据分段到大小为16位的传输块。顾名思义，NB IoT在下行和上行都使用带宽为180 kHz的窄带。下行链路中使用的多址方案是具有15khz子载波间隔的正交频分复用（OFDMA）。在上行链路中，使用具有15kHz或3.75kHz音调间隔的子载波频分复用（SC-FDMA）单音，或者可选地，可以使用具有15kHz音调间隔的多音SC-FDMA。
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物联网可通过三种方式部署。带内部署是指窄带部署在LTE频段内，无线资源在NB IoT和普通LTE载波之间灵活共享。在保护带部署中，窄带使用两个相邻LTE载波之间未使用的资源块。还支持独立部署，其中窄带可以单独位于专用频谱中，这使得可以在850/900 MHz的频率下为NB IoT重新配置GSM载波。所有三种部署模式均在许可频段中使用。对于上行链路传输，最大传输功率为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
3GPP定义的NB-IoT覆盖增强的最大耦合损耗（MCL）目标为164db。使用此MCL，NB IoT在下行链路中的性能在200 bps和2-3 kbit/s之间变化，具体取决于部署模式。独立操作可获得最高的数据
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.
速率高达几kbit/s，而带内和保护带操作可能达到数百bps。NB IoT甚至可以在MCL高于170 dB且比特率非常低的情况下运行。
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连接设置之外，还引入了两个选项；NAS上的强制数据（控制平面优化，[TGPP23720]中的解决方案2）和可选RRC挂起/恢复（用户平面优化，[TGPP23720]中的解决方案18））。在控制平面优化中，数据通过非接入层（NAS）直接发送到/从核心网络中的移动管理实体（MME）（网络架构见图3）发送到用户设备（UE），而无需与基站交互。这意味着在eNodeB中没有由PDCP层提供的访问层安全性或报头压缩，因为访问层被绕过，并且只有有限的RRC过程。基于鲁棒报头压缩（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.
与传统LTE操作相比，RRC挂起/恢复过程减少了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).
为了延长设备电池寿命，NB IoT可使用节能模式（PSM）和扩展DRX（eDRX）。使用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].
[TGPP33203]中规定了3GPP访问安全性。
+--+
|UE| \ +------+ +------+
+--+ \ | MME |------| HSS |
\ / +------+ +------+
+--+ \+--------+ / |
|UE| ----| eNodeB |- |
+--+ /+--------+ \ |
/ \ +--------+
/ \| | +------+ Service Packet
+--+ / | S-GW |----| P-GW |---- Data Network (PDN)
|UE| | | +------+ e.g., Internet
+--+ +--------+
+--+
|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物联网的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）通过接入网络路由和转发用户数据分组，并在称为eNodeBs的基站之间的切换期间以及在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.
家庭订户服务器（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是控制一个或多个小区中的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
+---------+ +---------+
| 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与网络之间的连接的协议组成。控制平面的最高层称为非接入层（NAS），它在UE和演进包核心（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下的功能层；在控制平面中，它由无线资源控制（RRC）协议[TGPP36331]组成，该协议处理连接建立和释放功能、系统信息广播、无线承载建立、重新配置和释放。RRC根据网络状态配置用户和控制平面。存在两种RRC状态，RRC_空闲或RRC_连接，RRC实体控制这些状态之间的切换。在RRC_Idle中，网络知道UE存在于网络中，并且在传入呼叫/下行链路数据的情况下可以到达UE。在此状态下，UE监视寻呼，执行小区测量和小区选择，并获取系统信息。此外，UE可以接收广播和多播数据，但不期望发送或接收单播数据。在RRC_连接状态下，UE具有到eNodeB的连接，网络知道UE在小区级别上的位置，并且UE可以接收和发送单播数据。当预期UE在网络中处于活动状态以发送或接收数据时，建立RRC连接。当不再有流量时，RRC连接被释放，切换回RRC_空闲；这是为了保护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.
物理层[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，在用户平面中，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个国家部署，总面积为200万平方公里，拥有5.12亿人口。
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自主电池操作设备每天、每周或每月只发送几个字节，允许它们在单个电池上使用长达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基站的容量取决于设备生成的消息数量，而不是设备的实际数量。同样，设备的电池寿命取决于设备生成的消息数量。根据使用情况，设备可以从每天每个设备发送不到一条消息到每天每个设备发送几十条消息不等。
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 上行波特率：100波特/600波特（取决于地区）
o Modulation scheme: DBPSK
o 调制方案：DBPSK
o Uplink transmission power: compliant with local regulation
o 上行传输功率：符合当地法规
o Link budget: 155 dB (or better)
o 链路预算：155dB（或更高）
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 | | | | |
+--------+--------+--------+------------------+-------------+-----+
+--------+--------+--------+------------------+-------------+-----+
|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 下行传输功率：500MW/4W（取决于地区）
o Link budget: 153 dB (or better)
o 链接预算：153分贝（或更好）
o Central frequency accuracy: the center frequency of downlink transmission is set by the network according to the corresponding uplink transmission.
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 | | | | |
+------------+-----+---------+------------------+-------------+-----+
+------------+-----+---------+------------------+-------------+-----+
| 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
由于ISM频段的监管限制，上行链路和下行链路传输不平衡。在最严格的规定下，系统最多可允许140条上行消息
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.
以及每天每个设备4条下行链路消息。这些限制可以根据系统条件和具体的操作监管领域稍微放宽。
+---+
|DEV| * +------+
+---+ * | RA |
* +------+
+---+ * |
|DEV| * * * * |
+---+ * +----+ |
* | BS | \ +--------+
+---+ * +----+ \ | |
DA -----|DEV| * * * | SC |----- NA
+---+ * / | |
* +----+ / +--------+
+---+ * | BS |/
|DEV| * * * * +----+
+---+ *
*
+---+ *
|DEV| * *
+---+
+---+
|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采用“一个合同一个网络”模式，允许设备在任何国家连接，而无需漫游或切换。
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负责基站和互联网之间的数据连接，以及基站和端点（EPs）的控制和管理。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的基站组成。每个基站执行复杂的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）或EPs是在本地设备应用程序（DAs）和网络应用程序（NAs）之间通信应用程序数据的对象。
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.
设备（或EPs）可以是静态的，也可以是游牧的，因为它们与SC关联，并且不连接到任何特定的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.
由于设备复杂性的限制，假设设备仅承载一个或很少的设备应用程序，这些设备应用程序在大多数情况下一次与单个网络应用程序通信。
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)这本书的作者是鲍勃和森·金肖恩。保罗·达菲(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/>是智能城市、智能电网、智能公用事业和广泛的通用物联网应用的行业联盟。Wi-SUN联盟现场区域网络（FAN）配置文件基于开放标准（主要基于IETF和IEEE 802标准），旨在解决智能城市/城市基础设施监控和管理、电动汽车（EV）基础设施、先进计量基础设施（AMI）、配电自动化（DA）等应用，监控和数据采集（SCADA）保护/管理、分布式发电监控和管理以及更多物联网应用。此外，联盟还创建了一个认证计划，以促进全球多供应商互操作性。
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
ANSI/TIA中规定了风扇配置文件，作为之前在智能公用设施网络上所做工作的扩展[ANSI-4957-000]。计划于2017年发布的这些规范的更新将包含
details of the FAN profile. A current snapshot of the work to produce that profile is presented in [wisun-pressie1] and [wisun-pressie2].
风扇配置文件的详细信息。[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.
风扇配置文件是支持企业级安全的IPv6无线网状网络。跳频无线mesh拓扑旨在提供卓越的网络鲁棒性、高冗余带来的可靠性、灵活的mesh配置带来的良好可扩展性以及良好的抗干扰能力。极低功耗模式正在开发中，允许网络节点的电池长期运行。
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公里，与邻里区域网络、校园区域网络或企业区域网络的需求相匹配。该范围还可以通过多跳网络扩展。
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物联网应用。
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 低功耗：风扇设备在休息时消耗不到2 uA，在收听时仅消耗8 mA。这样的设备可以保持很长的使用寿命，即使它们经常监听。例如，假设设备每10秒发送一次10毫秒的数据；理论上，1000毫安时的电池可以使用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
风扇包含一个或多个网络。在网络中，节点承担三种操作角色之一。首先，每个网络都包含一个边界路由器，为网络提供WAN连接。边界路由器为其网络内的所有节点维护源路由表，提供节点身份验证和密钥管理服务，并传播网络范围的信息，如广播时间表。第二，路由器节点，提供向上和向下的数据包转发（在网络内）。路由器还提供
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.
用于中继安全和地址管理协议的服务。最后，叶节点提供最低能力：发现和加入网络、发送/接收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].
风扇配置文件基于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.
风扇配置文件规范提供了独立于应用程序的基于IPv6的传输服务。建立IPv6数据包路由有两种可能的方法：网络层的低功耗有损网络路由协议（RPL）是强制性的，而数据链路层的多跳传送服务（MHDS）是可选的。图8提供了风扇网络堆栈的概述。
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]中定义的低功率无线个人区域网络（6LoWPAN）上的IPv6适配。[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.
数据链路服务提供物理层的控制/管理和到网络层的数据传输/管理服务。这些服务分为MAC和逻辑链路控制（LLC）子层。LLC子层提供支持6LoWPAN的协议调度服务和可选的MAC子层mesh服务。MAC子层使用[IEEE.802.15.4]中定义的数据结构构建。定义了多种跳频模式。整个MAC有效载荷封装在[IEEE.802.15.9]信息元素中，以实现上层6LoWPAN处理和MAC子层mesh处理等之间的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 |
+----------------------+--------------------------------------------+
+----------------------+--------------------------------------------+
| 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].
风扇安全性支持数据链路层网络访问控制、相互认证和在风扇节点及其边界路由器之间建立安全的成对链路，这是通过[IEEE.802.1x]和[RFC5216]中所述的EAP-TLS自适应实现的，使用[IEEE.802.1AR]中所述的安全设备标识。证书格式基于[RFC5280]。边界路由器和一组风扇节点之间的安全组链路是使用[IEEE.802.11]四路握手的自适应建立的。在网络中维护一组四个组密钥，其中一个是当前传输密钥。使用[ETSI-TS-102-887-2]的自适应功能，支持单跳风扇邻居之间的安全节点到节点链路。风扇节点实现[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。它被称为：网关、演进节点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 网络网关或路由器是无线电网关和因特网之间的互连节点。它被称为网络服务器、服务GW或服务中心。
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服务器，用于控制用户身份验证。它被称为加入服务器、家庭订户服务器或注册机构。（我们使用术语LPWAN-AAA服务器，因为我们不认为该实体像许多/大多数AAA服务器那样使用RADIUS或Diameter；但同样，我们也不想排除这种可能性，因为其功能类似。）
o At last we have the Application Server, known also as Packet Data Node Gateway or Network Application.
o 最后是应用服务器，也称为分组数据节点网关或网络应用程序。
+---------------------------------------------------------------------+
| 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) |
+---------------------------------------------------------------------+
+---------------------------------------------------------------------+
| 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=服务能力暴露功能
Figure 9: LPWAN Architecture Terminology
图9：LPWAN架构术语
+------+
() () () | |LPWAN-|
() () () () / \ +---------+ | AAA |
() () () () () () / \========| /\ |====|Server| +-----------+
() () () | | <--|--> | +------+ |APPLICATION|
() () () () / \============| v |==============| (App) |
() () () / \ +---------+ +-----------+
DEV Radio Gateways NGW
+------+
() () () | |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工作组目标之间的一些差距。[RFC7452]中描述的许多通用注意事项也将适用于LPWAN，因为终端设备也可以被视为（所谓的）“智能对象”的子类。此外，LPWAN设备实现者还需要考虑与[RCF8240]中描述的固件更新有关的问题。
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]设计用于为连接到Internet的所有节点分配地址。然而，协议引入的至少40字节的报头开销与LPWAN约束不兼容。如果使用没有进一步优化的IPv6，可能只需要几个LPWAN帧来承载IP报头。另一个问题来自IPv6 MTU要求，要求下面的层至少支持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 mesh路由器节点通常比讨论的其他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
一些在各个方面表现出重大限制的技术利用了6LoWPAN规范套件（[RFC4944]、[RFC6282]和[RFC6775]）来支持IPv6[USES-6LO]。然而，LPWAN的限制通常比（重新）使用6LoWPAN的典型技术更为极端，构成了
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套件，以便通过LPWAN启用IPv6。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千比特/秒），以及
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字节（一个地址前缀压缩）或19字节（源前缀和目标前缀都压缩）。考虑到LPWAN技术的链路层有效负载大小，这些报头非常大，在某些情况下甚至比LPWAN PDU还要大。6LoWPAN最初是为[IEEE.802.15.4]网络设计的，其帧大小高达127字节，吞吐量高达250 kbit/s，这可能是占空比，也可能不是占空比。
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网络传输IPv6数据包[RFC4944]。虽然6LoWPAN分段标头适用于[IEEE.802.15.4]的2003版本（其帧有效负载大小为81-102字节），但它不适用于几种LPWAN技术，其中许多LPWAN技术的最大有效负载大小比[IEEE.802.15.4]的2003版本低一个数量级。考虑到LPWAN技术的有效负载大小减小，以及使用此类技术的设备的能量可用性有限，6LoWPAN分段报头的开销很高。此外，其数据报偏移字段以八个八位字节的增量表示。在某些LPWAN技术中，6LoWPAN碎片报头加上原始数据报中的8个八位字节超出了第二层有效负载中的可用空间。此外，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]或类似技术的设备网络。优化包括允许休眠主机的主机启动交互、用地址注册机制替换基于多播的主机地址解析、前缀分发的多跳扩展和重复地址检测（注意，星形拓扑网络中不需要这些功能），和6 Lowpan收割台压缩支架。
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
在其他LPWAN中（最大有效负载大小约为10字节，消息速率约为0.1条消息/分钟），相同的交换可能需要数小时甚至数天，导致严重的碎片化，并消耗大量可用网络资源。6LoWPAN ND行为可以通过使用默认路由器生存期、PIO中的有效生存期和
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.
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工作组一直在重用和调整6LoWPAN，以支持链路层技术上的IPv6支持，如蓝牙低能（BTLE）、ITU-T G.9959[G9959]、数字增强无绳通信（DECT）超低能（ULE）、MS/TP-RS485、近场通信（NFC）IEEE 802.11ah。（见<https://datatracker.ietf.org/wg/6lo/>这些技术在几个方面与[IEEE.802.15.4]相似，后者是最初的6LoWPAN目标技术。
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.
6Disch的一个关键元素是使用同步来实现确定性。TSCH和6tisch可提供标准调度功能。LPWAN网络可能不会像6Disch中使用的那样支持同步。
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
RoHC是一种头压缩机制[RFC3095]，用于点对点信道中的多媒体流。RoHC使用三个级别的压缩，每个级别都有自己的头格式。在第一级，RoHC发送52字节的报头；在第二级，头可以是34到15个字节；在第三级，头大小可以是7到2个字节。压缩级别由序列号（SN）管理，在最小压缩中，序列号的大小从2字节到4位不等。SN压缩是使用
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.
称为窗口最低有效位（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工作组考虑的大多数技术都基于星型拓扑结构，这样就不需要在该层进行路由。未来的工作可能涉及可能需要修改现有路由协议或定义新路由协议的其他用例。截至撰写本文之时，类似于低功耗有损网络路由（ROLL）工作组和其他路由协议中所做的工作已超出LPWAN工作组的范围。
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框架。可能有必要调整CoAP或相关协议，以考虑LPWAN的极端占空比和潜在的极其有限的吞吐量。
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确认。另一方面，核心工作组目前正在进行的工作，其中约束管理接口（COMI）/约束对象语言（CoOL）网络管理接口使用结构化标识符（SID）减少CoAP上的有效负载大小，可能是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上行链路的网关）可用于属于同一网络网关的一些终端设备从一点移动到另一点使得它们不知道是移动的情况。
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]允许应用程序使用全局可解析的名称命名事物。许多协议使用DNS来识别主机，例如，使用CoAP的应用程序。
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查询/应答协议作为DNS应答生存时间（TTL）内其他通信的先驱，在LPWAN中显然存在问题，例如，在LPWAN中每小时只能使用一次往返，并且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工作组可能需要整合这些机制以统一管理。标准化的身份验证、授权和计费（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
某些使用LPWAN的应用程序可能很少或根本不考虑隐私问题。例如，大型办公大楼中的温度传感器可能不会引起隐私问题。然而，同样的传感器，如果部署在家庭环境中，尤其是由于人的存在而触发，可能会引发重大的隐私问题：如果终端设备在每次有人进入家庭房间时都会发出（加密）数据包，则该通信量对隐私敏感。越是
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中，这些机制可能不可行。尽管如此，隐私挑战确实存在，而且可能是真实的；因此，需要一些解决办法。请注意，该领域解决方案的许多方面在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面临的另一个挑战是如何处理密钥管理和相关协议。在更传统的网络（如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，“智能公用事业网络的架构概述”，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，“数据链路子层的多跳交付规范”，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.11913年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，2016年5月。
[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 972016年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]“电信射频设备-在902-928 MHz、2400-2483.5 MHz和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，“短程窄带数字无线电通信收发器-物理层、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信息技术标准——系统局域网和城域网之间的电信和信息交换——具体要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范”，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低速无线网络的上层接口（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标准”，IEEE 802.15.4<https://standards.ieee.org/findstds/ 标准/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标准——第15.4部分：低速无线个人区域网（LR WPAN）修改件1:MAC子层”，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标准——第15.4部分：低速无线个人区域网（LR WPAN）修改件3：低速无线智能计量公用设施网络的物理层（PHY）规范”，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，“IEEE密钥管理协议（KMP）数据报传输推荐规程”，IEEE标准802.15.92016<https://standards.ieee.org/findstds/ 标准/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标准-安全设备标识”，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联盟，“LoRaWAN规范版本V1.0.2”，2016年7月<https://lora-alliance.org/sites/default/ 文件/2018-05/lorawan1\u 0\u 2-20161012\u 1398\u 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概览”，正在进行的工作，草稿-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]Garcia，D.，Marin，R.，Kandasamy，A.，和A.Pelov，“直径中的LoRaWAN认证”，正在进行的工作，草稿-Garcia-dime-DIAMER-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]Garcia，D.，Lopez，R.，Kandasamy，A.和A.Pelov，“RADIUS中的LoRaWAN认证”，正在进行的工作，草稿-Garcia-RADIUS-LoRaWAN-032017年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.，Ed.，Gomez，C.，Ed.，Toutain，L.，Paradells，J.，和J.Crowcroft，“LPWAN调查和差距分析”，正在进行的工作，草稿-Minaburo-LPWAN-GAP-Analysis-022016年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特征”，正在进行的工作，草案-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技术概述和云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.，“用户数据报协议”，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.，“传输控制协议”，标准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授权框架”，RFC 2904，DOI 10.17487/RFC29042000年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.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，内政部10.17487/RFC30952001年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.，和M.Carney，“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.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，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]Conta，A.，Deering，S.和M.Gupta，Ed.“互联网协议版本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，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年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.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过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]Simon，D.，Aboba，B.和R.Hurst，“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，“传输层安全（TLS）协议版本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公钥基础设施证书和证书撤销列表（CRL）配置文件”，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]Hui，J.，Ed.和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]Shelby，Z.，Ed.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功率无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 6775，DOI 10.17487/RFC67752012年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，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年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，“受限应用协议（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，“智能对象网络中的架构考虑”，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，“蓝牙（R）低能量IPv6”，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]Thaler，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，“2016年物联网软件更新（IoTSU）研讨会报告”，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系统描述”，正在进行的工作，草稿-Zuniga-lpwan-Sigfox-System-Description-042017年12月。
[TGPP23720] 3GPP, "Study on architecture enhancements for Cellular Internet of Things", 3GPP TS 23.720 13.0.0, 2016.
[TGPP23720]3GPP，“蜂窝式物联网架构增强研究”，3GPP TS 23.720 13.0.012016。
[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.012016。
[TGPP36201] 3GPP, "Evolved Universal Terrestrial Radio Access (E-UTRA); LTE physical layer; General description", 3GPP TS 36.201 13.2.0, 2016.
[TGPP36201]3GPP，“演进通用地面无线接入（E-UTRA）；LTE物理层；一般说明”，3GPP TS 36.201 13.2.012016。
[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.012016<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，“演进型通用地面无线接入（E-UTRA）；媒体接入控制（MAC）协议规范”，3GPP TS 36.321 13.2.012016。
[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，“演进型通用地面无线接入（E-UTRA）；无线链路控制（RLC）协议规范”，3GPP TS 36.322 13.2.012016。
[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，“演进型通用地面无线接入（E-UTRA）；分组数据汇聚协议（PDCP）规范（尚未提供）”，3GPP TS 36.323 13.2.012016。
[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.012016。
[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（6LO）适用性和用例”，正在进行的工作，草稿-Hong-6LO-用例-032016年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联盟”，2017年3月<http://indiasmartgrid.org/event2017/10-03-2017/4.%20Round %20通信%20和%20网络%20安全/1.%20P hil%20Beecher.pdf>上的表%20。
[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
阿布杜萨兰国巴伦安迪·马利斯·阿伦(arun@acklio.com)贝塞特·萨里卡亚和加西亚·卡里略·加齐·米里娅·库莱温德·保罗·达菲·鲁斯·霍斯利·萨米塔·查克拉巴蒂·塔德·吉德里·沃伦·库马里
Alexander Pelov and Pascal Thubert were the LPWAN WG Chairs while this document was developed.
亚历山大·佩洛夫（Alexander Pelov）和帕斯卡·苏伯特（Pascal Thubert）是本文件编制期间LPWAN工作组的主席。
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/>.
Stephen Farrell在这个备忘录上的工作得到了普及的国家，科学基金会爱尔兰连接中心全国物联网的支持。https://connectcentre.ie/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节的文本由Alper Yegin和Stephen Farrell在[LoRaWAN]提供。
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节的文本由Juan Carlos Zuniga和Benoit Ponsard在[Sigfox]中提供。
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
Email: jon.crowcroft@cl.cam.ac.uk
Carles Gomez UPC/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain
Carles Gomez UPC/i2CAT C/Esteve Terradas，7 Castelldefels 08860西班牙
Email: carlesgo@entel.upc.edu
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
Bob Heile Wi Sun Alliance 11 Robert Toner大道5-301室北阿特勒伯勒，马萨诸塞州02763
Phone: +1-781-929-4832
Email: bheile@ieee.org
Phone: +1-781-929-4832
Email: bheile@ieee.org
Ana Minaburo Acklio 2bis rue de la Chataigneraie 35510 Cesson-Sevigne Cedex France
安娜·米纳布鲁·阿克利奥2号法国塞森塞维涅赛德克斯城堡大道35510号
Email: ana@ackl.io
Email: ana@ackl.io
Josep PAradells UPC/i2CAT C/Jordi Girona, 1-3 Barcelona 08034 Spain
约塞普·帕拉代尔斯UPC/i2CAT C/Jordi Girona，巴塞罗那1-3号，西班牙08034
Email: josep.paradells@entel.upc.edu
Email: josep.paradells@entel.upc.edu
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, CA 95050 United States of America
Charles E.Perkins Futurewi 2330美国加利福尼亚州圣克拉拉中央高速公路95050号
Email: charliep@computer.org
Email: charliep@computer.org
Benoit Ponsard Sigfox 425 rue Jean Rostand Labege 31670 France
法国Jean Rostand Labege街425号Benoit Ponsard Sigfox 31670
Email: Benoit.Ponsard@sigfox.com
URI: http://www.sigfox.com/
Email: Benoit.Ponsard@sigfox.com
URI: http://www.sigfox.com/
Antti Ratilainen Ericsson Hirsalantie 11 Jorvas 02420 Finland
安蒂·拉蒂莱宁爱立信Hirsalantie 11 Jorvas 02420芬兰
Email: antti.ratilainen@ericsson.com
Email: antti.ratilainen@ericsson.com
Chin-Sean SUM Wi-Sun Alliance 20, Science Park Rd 117674 Singapore
新加坡科学园路117674号金尚森太阳联盟20号
Phone: +65 6771 1011
Email: sum@wi-sun.org
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
洛朗图坦矿业研究所电信；法国塞森塞维涅塞德克斯电信公司
Email: Laurent.Toutain@telecom-bretagne.eu
Email: Laurent.Toutain@telecom-bretagne.eu
Alper Yegin Actility Paris France
法国巴黎阿尔珀·耶金活动酒店
Email: alper.yegin@actility.com
Email: alper.yegin@actility.com
Juan Carlos Zuniga Sigfox 425 rue Jean Rostand Labege 31670 France
胡安·卡洛斯·祖尼加·西格福克斯法国让·罗斯坦德·拉贝格街425号31670
Email: JuanCarlos.Zuniga@sigfox.com
URI: http://www.sigfox.com/
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
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie