Internet Engineering Task Force (IETF)                          C. Gomez
Request for Comments: 8352                                           UPC
Category: Informational                                      M. Kovatsch
ISSN: 2070-1721                                               ETH Zurich
                                                                 H. Tian
                             China Academy of Telecommunication Research
                                                             Z. Cao, Ed.
                                                     Huawei Technologies
                                                              April 2018
        
Internet Engineering Task Force (IETF)                          C. Gomez
Request for Comments: 8352                                           UPC
Category: Informational                                      M. Kovatsch
ISSN: 2070-1721                                               ETH Zurich
                                                                 H. Tian
                             China Academy of Telecommunication Research
                                                             Z. Cao, Ed.
                                                     Huawei Technologies
                                                              April 2018
        

Energy-Efficient Features of Internet of Things Protocols

物联网协议的节能特性

Abstract

摘要

This document describes the challenges for energy-efficient protocol operation on constrained devices and the current practices used to overcome those challenges. It summarizes the main link-layer techniques used for energy-efficient networking, and it highlights the impact of such techniques on the upper-layer protocols so that they can together achieve an energy-efficient behavior. The document also provides an overview of energy-efficient mechanisms available at each layer of the IETF protocol suite specified for constrained-node networks.

本文档描述了在受限设备上进行节能协议操作的挑战以及当前用于克服这些挑战的实践。它总结了用于节能网络的主要链路层技术,并强调了这些技术对上层协议的影响,以便它们能够共同实现节能行为。本文件还概述了为受限节点网络指定的IETF协议套件各层可用的节能机制。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

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/rfc8352.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问https://www.rfc-editor.org/info/rfc8352.

Copyright Notice

版权公告

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Medium Access Control and Radio Duty Cycling  . . . . . . . .   6
     3.1.  Techniques for Radio Duty Cycling . . . . . . . . . . . .   6
     3.2.  Latency and Buffering . . . . . . . . . . . . . . . . . .   7
     3.3.  Throughput  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Radio Interface Tuning  . . . . . . . . . . . . . . . . .   8
     3.5.  Packet Bundling . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  Power Save Services Available in Example Low-Power Radios   8
       3.6.1.  Power Save Services Provided by IEEE 802.11 . . . . .   8
       3.6.2.  Power Save Services Provided by Bluetooth LE  . . . .  10
       3.6.3.  Power Save Services in IEEE 802.15.4  . . . . . . . .  11
       3.6.4.  Power Save Services in DECT ULE . . . . . . . . . . .  12
   4.  IP Adaptation and Transport Layer . . . . . . . . . . . . . .  14
   5.  Routing Protocols . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Application Layer . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Energy-Efficient Features in CoAP . . . . . . . . . . . .  16
     6.2.  Sleepy Node Support . . . . . . . . . . . . . . . . . . .  17
     6.3.  CoAP Timers . . . . . . . . . . . . . . . . . . . . . . .  17
     6.4.  Data Compression  . . . . . . . . . . . . . . . . . . . .  18
   7.  Summary and Conclusions . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Medium Access Control and Radio Duty Cycling  . . . . . . . .   6
     3.1.  Techniques for Radio Duty Cycling . . . . . . . . . . . .   6
     3.2.  Latency and Buffering . . . . . . . . . . . . . . . . . .   7
     3.3.  Throughput  . . . . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Radio Interface Tuning  . . . . . . . . . . . . . . . . .   8
     3.5.  Packet Bundling . . . . . . . . . . . . . . . . . . . . .   8
     3.6.  Power Save Services Available in Example Low-Power Radios   8
       3.6.1.  Power Save Services Provided by IEEE 802.11 . . . . .   8
       3.6.2.  Power Save Services Provided by Bluetooth LE  . . . .  10
       3.6.3.  Power Save Services in IEEE 802.15.4  . . . . . . . .  11
       3.6.4.  Power Save Services in DECT ULE . . . . . . . . . . .  12
   4.  IP Adaptation and Transport Layer . . . . . . . . . . . . . .  14
   5.  Routing Protocols . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Application Layer . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Energy-Efficient Features in CoAP . . . . . . . . . . . .  16
     6.2.  Sleepy Node Support . . . . . . . . . . . . . . . . . . .  17
     6.3.  CoAP Timers . . . . . . . . . . . . . . . . . . . . . . .  17
     6.4.  Data Compression  . . . . . . . . . . . . . . . . . . . .  18
   7.  Summary and Conclusions . . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
     10.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  23
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24
        
1. Introduction
1. 介绍

Network systems for monitoring the physical world contain many battery-powered or energy-harvesting devices. For example, in an environmental monitoring system or a temperature and humidity monitoring system, there may not be always on and sustained power supplies for the potentially large number of constrained devices. In such deployment scenarios, it is necessary to optimize the energy consumption of the constrained devices. In this document, we describe techniques that are in common use at Layer 2 and at Layer 3, and we indicate the need for higher-layer awareness of lower-layer features.

用于监测物理世界的网络系统包含许多电池供电或能量收集设备。例如,在环境监测系统或温度和湿度监测系统中,可能不会为潜在的大量受限设备始终提供持续的电源。在这种部署场景中,有必要优化受约束设备的能耗。在本文档中,我们描述了在第2层和第3层常用的技术,并指出了对较低层功能的较高层感知的需求。

Many research efforts have studied this "energy efficiency" problem. Most of this research has focused on how to optimize the system's power consumption in certain deployment scenarios or how an existing network function such as routing or security could be more energy efficient. Only few efforts have focused on energy-efficient designs for IETF protocols and standardized network stacks for such constrained devices [CLASS1-CoAP].

许多研究工作都在研究这一“能源效率”问题。大部分研究都集中在如何在某些部署场景中优化系统的功耗,或者现有网络功能(如路由或安全)如何更节能。只有很少的工作专注于IETF协议的节能设计和此类受限设备的标准化网络堆栈[CLASS1 CoAP]。

The IETF has developed a suite of Internet protocols suitable for such constrained devices, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC6282] [RFC6775] [RFC4944], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. This document tries to summarize the design considerations for making the IETF constrained protocol suite as energy efficient as possible. While this document does not provide detailed and systematic solutions to the energy-efficiency problem, it summarizes the design efforts and analyzes the design space of this problem. In particular, it provides an overview of the techniques used by the lower layers to save energy and how these may impact on the upper layers. Cross-layer interaction is therefore considered in this document from this specific point of view. Providing further design recommendations that go beyond the layered protocol architecture is out of the scope of this document.

IETF开发了一套适用于此类受限设备的互联网协议,包括低功率无线个人区域网络(6LoWPAN)[RFC6282][RFC6775][RFC4944]、低功率和有损网络的IPv6路由协议(RPL)[RFC6550]和受限应用协议(CoAP)[RFC7252]。本文档试图总结使IETF约束协议套件尽可能节能的设计考虑。虽然本文件没有提供能源效率问题的详细和系统的解决方案,但它总结了设计工作并分析了该问题的设计空间。特别是,它概述了下层为节约能源而使用的技术,以及这些技术对上层的影响。因此,本文件从这一特定角度考虑了跨层交互。提供超出分层协议体系结构的进一步设计建议超出了本文档的范围。

After reviewing the energy-efficient designs of each layer, we summarize the document by presenting some overall conclusions. Though the lower-layer communication optimization is the key part of energy-efficient design, the protocol design at the upper layers is also important to make the device energy efficient.

在回顾了每一层的节能设计之后,我们通过提出一些总体结论对文件进行了总结。虽然底层通信优化是节能设计的关键部分,但上层协议设计对设备节能也很重要。

1.1. Terminology
1.1. 术语

Terms used in this document are defined in [RFC7228] [CNN-TERMS].

本文件中使用的术语定义见[RFC7228][CNN-Terms]。

2. Overview
2. 概述

The IETF has developed protocols to enable end-to-end IP communication between constrained nodes and fully capable nodes. This work has expedited the evolution of the traditional Internet protocol stack to a lightweight Internet protocol stack. As shown in Figure 1 below, the IETF has developed CoAP as the application layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 [IEEE802.15.4] and Bluetooth Low Energy (also referred to as Bluetooth LE and BTLE), with the support of routing by RPL and efficient neighbor discovery by 6LoWPAN Neighbor Discovery (6LoWPAN-ND). 6LoWPAN is currently being adapted by the 6lo Working Group to support IPv6 over various other technologies, such as ITU-T G.9959 [G9959], Digital Enhanced Cordless Telecommunications Ultra Low Energy (DECT ULE) [TS102], Building Automation and Control Networks Master-Slave/Token-Passing (BACnet MS/TP) [MSTP], and Near Field Communication [NFC].

IETF已经开发了协议,以实现受限节点和完全功能节点之间的端到端IP通信。这项工作加速了传统互联网协议栈向轻量级互联网协议栈的演变。如下图1所示,IETF开发了CoAP作为应用层,6LoWPAN作为适配层,在支持RPL路由和6LoWPAN邻居发现(6LoWPAN ND)高效邻居发现的情况下,在IEEE 802.15.4[IEEE802.15.4]和蓝牙低能耗(也称为蓝牙LE和BTLE)上运行IPv6。6LoWPAN目前正由6lo工作组进行调整,以通过各种其他技术支持IPv6,如ITU-T G.9959[G9959]、数字增强无绳通信超低能(DECT ULE)[TS102]、楼宇自动化和控制网络主从/令牌传递(BACnet MS/TP)[MSTP]和近场通信[NFC]。

   +-----+   +-----+    +-----+                +------+
   |HTTP |   | FTP |    |SNMP |                | CoAP |
   +-----+   +-----+    +-----+                +------+
         \    /           /                   /        \
        +-----+     +-----+              +-----+      +-----+
        | TCP |     | UDP |              | TCP |      | UDP |
        +-----+     +-----+       ===>   +-----+      +-----+
               \   /                          \        /
    +-----+  +------+  +-------+               +------+   +-----+
    | RTG |--| IPv6 |--|ICMP/ND|               | IPv6 |---| RTG |
    +-----+  +------+  +-------+               +------+   +-----+
                 |                                 |
             +-------+                         +-------+  +----------+
             |MAC/PHY|                         |  6Lo  |--|6LoWPAN-ND|
             +-------+                         +-------+  +----------+
                                                   |
                                               +-------+
                                               |MAC/PHY|
                                               +-------+
        
   +-----+   +-----+    +-----+                +------+
   |HTTP |   | FTP |    |SNMP |                | CoAP |
   +-----+   +-----+    +-----+                +------+
         \    /           /                   /        \
        +-----+     +-----+              +-----+      +-----+
        | TCP |     | UDP |              | TCP |      | UDP |
        +-----+     +-----+       ===>   +-----+      +-----+
               \   /                          \        /
    +-----+  +------+  +-------+               +------+   +-----+
    | RTG |--| IPv6 |--|ICMP/ND|               | IPv6 |---| RTG |
    +-----+  +------+  +-------+               +------+   +-----+
                 |                                 |
             +-------+                         +-------+  +----------+
             |MAC/PHY|                         |  6Lo  |--|6LoWPAN-ND|
             +-------+                         +-------+  +----------+
                                                   |
                                               +-------+
                                               |MAC/PHY|
                                               +-------+
        

Figure 1: Traditional and Lightweight Internet Protocol Stack

图1:传统和轻量级互联网协议栈

There are numerous published studies reporting comprehensive measurements of wireless communication platforms [Powertrace]. As an example, below we list the energy-consumption profile of the most common operations involved in communication on a prevalent sensor node platform. The measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] as the Radio Duty Cycling algorithm. From this and many other measurement reports (e.g., [AN079]), we can see that the energy consumption of optimized transmission and reception

有许多已发表的研究报告了对无线通信平台的全面测量[Powertrace]。作为一个例子,下面我们列出了在一个流行的传感器节点平台上进行通信所涉及的最常见操作的能耗概况。测量基于Tmote天空,ContikiMAC[ContikiMAC]作为无线电工作循环算法。从这个和许多其他测量报告(例如[AN079])中,我们可以看到优化传输和接收的能耗

are in the same order. For IEEE 802.15.4 [IEEE802.15.4] and Ultra WideBand (UWB) links, transmitting may actually be even cheaper than receiving. It also shows that broadcast and non-synchronized communication transmissions are energy costly because they need to acquire the medium for a long time.

它们的顺序是一样的。对于IEEE 802.15.4[IEEE802.15.4]和超宽带(UWB)链路,传输实际上可能比接收更便宜。它还表明,广播和非同步通信传输的能源成本很高,因为它们需要长时间获取媒体。

   +---------------------------------------+---------------+
   | Activity                              | Energy        |
   |                                       | (microjoules) |
   +---------------------------------------+---------------+
   | Broadcast reception                   |           178 |
   +---------------------------------------+---------------+
   | Unicast reception                     |           222 |
   +---------------------------------------+---------------+
   | Broadcast transmission                |          1790 |
   +---------------------------------------+---------------+
   | Non-synchronized unicast transmission |          1090 |
   +---------------------------------------+---------------+
   | Synchronized unicast transmission     |           120 |
   +---------------------------------------+---------------+
   | Unicast TX to awake receiver          |            96 |
   +---------------------------------------+---------------+
   | Listening (for 1000 ms)               |         63000 |
   +---------------------------------------+---------------+
        
   +---------------------------------------+---------------+
   | Activity                              | Energy        |
   |                                       | (microjoules) |
   +---------------------------------------+---------------+
   | Broadcast reception                   |           178 |
   +---------------------------------------+---------------+
   | Unicast reception                     |           222 |
   +---------------------------------------+---------------+
   | Broadcast transmission                |          1790 |
   +---------------------------------------+---------------+
   | Non-synchronized unicast transmission |          1090 |
   +---------------------------------------+---------------+
   | Synchronized unicast transmission     |           120 |
   +---------------------------------------+---------------+
   | Unicast TX to awake receiver          |            96 |
   +---------------------------------------+---------------+
   | Listening (for 1000 ms)               |         63000 |
   +---------------------------------------+---------------+
        

Figure 2: Power Consumption of Common Operations Involved in Communication on the Tmote Sky with ContikiMAC

图2:Tmote Sky上与ContikiMAC通信所涉及的常见操作功耗

At the Physical layer, one approach that may reduce the energy consumption of a device that uses a wireless interface is based on reducing the device transmit power level, as long as the intended next hop(s) is still within range of the device. In some cases, if node A has to transmit a message to node B, a solution to reduce node A transmit power is to leverage an intermediate device, e.g., node C as a message forwarder. Let d be the distance between node A and node B. Assuming free-space propagation, where path loss is proportional to d^2, if node C is placed right in the middle of the path between A and B (that is, at a distance d/2 from both node A and node B), the minimum transmit power to be used by node A (and by node C) is reduced by a factor of 4. However, this solution requires additional devices, it requires a routing solution, and it also increases transmission delay between A and B.

在物理层,可以降低使用无线接口的设备的能量消耗的一种方法基于降低设备发射功率电平,只要预期的下一跳仍在设备的范围内。在某些情况下,如果节点A必须向节点B发送消息,则降低节点A发送功率的解决方案是利用中间设备,例如节点C作为消息转发器。设D是节点A与节点B之间的距离。假设自由空间传播,其中路径损耗正比于d^ 2,如果节点C正好放置在A和B之间的路径的中间(即,在节点A和节点B的距离D / 2),由节点A(和节点C)使用的最小发射功率被减少了4倍。然而,该解决方案需要额外的设备,它需要路由解决方案,并且它还增加了a和B之间的传输延迟。

3. Medium Access Control and Radio Duty Cycling
3. 介质访问控制和无线电负载循环

In networks, communication and power consumption are interdependent. The communication device is typically the most power-consuming component, but merely refraining from transmissions is not enough to achieve a low power consumption: the radio may consume as much power in listen mode as when actively transmitting. This illustrates the key problem known as idle listening, whereby the radio of a device may be in receive mode (ready to receive any message), even if no message is being transmitted to that device. Idle listening can consume a huge amount of energy unnecessarily. To reduce power consumption, the radio must be switched completely off -- duty-cycled -- as much as possible. By applying duty cycling, the lifetime of a device operating on a common button battery may be on the order of years, whereas otherwise the battery may be exhausted in a few days or even hours. Duty cycling is a technique generally employed by devices that use the P1 strategy [RFC7228], which need to be able to communicate on a relatively frequent basis. Note that a more aggressive approach to save energy relies on the P0 (Normally-off) strategy, whereby devices sleep for very long periods and communicate infrequently, even though they spend energy in network reattachment procedures.

在网络中,通信和功耗是相互依存的。通信设备通常是最耗电的组件,但是仅仅避免传输不足以实现低功耗:无线电在收听模式下可能消耗与主动传输时相同的功率。这说明了被称为空闲监听的关键问题,即设备的无线电可能处于接收模式(准备接收任何消息),即使没有消息被发送到该设备。空闲的倾听会消耗大量不必要的能量。为了降低功耗,收音机必须尽可能地完全关闭(占空比循环)。通过应用占空比循环,使用普通按钮电池的设备的使用寿命可能为年,否则电池可能在几天甚至几小时内耗尽。占空比循环是使用P1策略[RFC7228]的设备通常采用的一种技术,需要能够在相对频繁的基础上进行通信。请注意,更积极的节能方法依赖于P0(正常关闭)策略,即设备睡眠时间很长,通信频率很低,即使它们在网络重新连接过程中花费了能量。

From the perspective of Medium Access Control (MAC) and Radio Duty Cycling (RDC), all upper-layer protocols, such as routing, RESTful communication, adaptation, and management flows, are applications. Since the duty-cycling algorithm is the key to energy efficiency of the wireless medium, it synchronizes transmission and/or reception requests from the higher layers.

从媒体访问控制(MAC)和无线电任务循环(RDC)的角度来看,所有上层协议,如路由、RESTful通信、自适应和管理流,都是应用程序。由于占空比循环算法是无线介质能量效率的关键,因此它同步来自更高层的传输和/或接收请求。

MAC and RDC are not in the scope of the IETF, yet lower-layer designers and chipset manufacturers take great care to save energy. By knowing the behaviors of these lower layers, engineers can design protocols that work well with them. The IETF protocols to be discussed in the following sections are the customers of the lower layers.

MAC和RDC不在IETF的范围内,但低层设计师和芯片组制造商非常注意节能。通过了解这些较低层的行为,工程师可以设计与它们配合良好的协议。以下章节将讨论的IETF协议是较低层的客户。

3.1. Techniques for Radio Duty Cycling
3.1. 无线电工作循环技术

This subsection describes three main RDC techniques. Note that more than one of these techniques may be available or can even be combined in a specific radio technology:

本小节描述了三种主要的RDC技术。注意,这些技术中的一种以上可用,或者甚至可以组合到特定的无线电技术中:

a) Channel sampling: In this solution, the radio interface of a device periodically monitors the channel for very short time intervals (i.e., with a low duty cycle) with the aim of detecting incoming transmissions. In order to make sure that a receiver can correctly receive a transmitted data unit, the sender may

a) 信道采样:在该解决方案中,设备的无线电接口定期监测信道非常短的时间间隔(即低占空比),目的是检测传入传输。为了确保接收机能够正确地接收发送的数据单元,发送方可以:

prepend a preamble of a duration at least the sampling period to the data unit to be sent. Another option for the sender is to repeatedly transmit the data unit instead of sending a preamble before the data unit. Once a transmission is detected by a receiver, the receiver may stay awake until the complete reception of the data unit. Examples of radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e [IEEE802.15.4], and the Frequently Listening (FL) mode of ITU-T G.9959 [G9959].

将持续时间至少为采样周期的前导码预先发送到要发送的数据单元。发送方的另一个选择是重复发送数据单元,而不是在数据单元之前发送前导。一旦接收机检测到传输,接收机可以保持清醒,直到数据单元完全接收。使用前导采样的无线电技术的示例包括ContikiMAC、IEEE 802.15.4e[IEEE802.15.4]的协调采样监听(CSL)模式以及ITU-T G.9959[G9959]的频繁监听(FL)模式。

b) Scheduled transmissions: This approach allows a device to know the particular time at which it should be awake (during some time interval) in order to receive data. Otherwise, the device may remain in sleep mode. The decision on the times at which communication is attempted relies on some form of negotiation between the involved devices. Such negotiation may be performed per transmission or per session/connection. Bluetooth Low Energy (Bluetooth LE) is an example of a radio technology based on this mechanism.

b) 定时传输:这种方法允许设备知道为了接收数据而应该唤醒(在某个时间间隔内)的特定时间。否则,设备可能保持在睡眠模式。关于尝试通信的时间的决定依赖于相关设备之间某种形式的协商。这种协商可以在每次传输或每次会话/连接时执行。蓝牙低能量(Bluetooth LE)是基于此机制的无线电技术的一个示例。

c) Listen after send: This technique allows a node to remain in sleep mode by default, then wake up and poll a sender (which must be ready to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode and is ready for a potential incoming transmission. After a certain time interval, the node may go back to sleep. For example, this technique is used in the Receiver Initiated Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4] and in the transmission of data between a coordinator and a device in the 2003 version of IEEE 802.15.4 [IEEE802.15.4].

c) 发送后侦听:此技术允许节点在默认情况下保持睡眠模式,然后唤醒并轮询发送方(必须准备好接收轮询消息)以等待传输。发送轮询消息后,节点仍处于接收模式,并准备进行可能的传入传输。在某个时间间隔之后,节点可能返回睡眠状态。例如,在IEEE 802.15.4e[IEEE802.15.4]的接收器发起传输(RIT)模式中以及在IEEE 802.15.4[IEEE802.15.4]的2003版本中的协调器和设备之间的数据传输中使用该技术。

3.2. Latency and Buffering
3.2. 延迟和缓冲

The latency of a data unit transmission to a duty-cycled device is equal to or greater than the latency of transmitting to an always-on device. Therefore, duty cycling leads to a trade-off between energy consumption and latency. Note that in addition to a latency increase, RDC may introduce latency variance since the latency increase is a random variable (which is uniformly distributed if duty cycling follows a periodic behavior).

数据单元传输到占空比设备的延迟等于或大于传输到常开设备的延迟。因此,任务循环导致能量消耗和延迟之间的权衡。请注意,除了延迟增加之外,RDC还可能引入延迟变化,因为延迟增加是一个随机变量(如果负载循环遵循周期性行为,则该随机变量是均匀分布的)。

On the other hand, due to the latency increase introduced by duty cycling, a sender waiting for a transmission opportunity may need to store subsequent outgoing packets in a buffer. This buffering would increase memory requirements and potentially incur queuing wait times. Such wait times would in turn contribute to packet transmission delay and increase the probability of buffer overflow, leading to losses.

另一方面,由于由占空比循环引入的延迟增加,等待传输机会的发送方可能需要将随后的传出分组存储在缓冲器中。这种缓冲会增加内存需求,并可能导致排队等待时间。这样的等待时间反过来会导致数据包传输延迟,并增加缓冲区溢出的概率,从而导致丢失。

3.3. Throughput
3.3. 吞吐量

Although throughput is not typically a key concern in constrained-node network applications, it is indeed important in some services in such networks, such as over-the-air software updates or when off-line sensors accumulate measurements that have to be quickly transferred when there is an opportunity for connectivity.

虽然吞吐量在受限节点网络应用中通常不是一个关键问题,但它在此类网络中的某些服务中确实很重要,例如空中软件更新或离线传感器积累测量值时,当存在连接机会时,必须快速传输测量值。

Since RDC introduces inactive intervals in energy-constrained devices, it reduces the throughput that can be achieved when communicating with such devices. There exists a trade-off between the achievable throughput and energy consumption.

由于RDC在能量受限的设备中引入了非活动间隔,因此降低了与此类设备通信时可以实现的吞吐量。在可实现的吞吐量和能源消耗之间存在一种权衡。

3.4. Radio Interface Tuning
3.4. 无线电接口调谐

The parameters controlling the radio duty cycle have to be carefully tuned to achieve the intended application and/or network requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection provides details on key parameters controlling RDC mechanisms, and thus fundamental trade-offs, for various examples of relevant low-power radio technologies.

必须仔细调整控制无线电占空比的参数,以达到预期的应用和/或网络要求。另一方面,上层应考虑RDC带来的预期延迟和/或吞吐量行为。下一小节详细介绍了控制RDC机制的关键参数,以及相关低功率无线电技术的各种示例的基本权衡。

3.5. Packet Bundling
3.5. 包捆绑

Another technique that may be useful to increase communication energy efficiency is packet bundling. This technique, which is available in several radio interfaces (e.g., LTE and some 802.11 variants), allows for aggregation of several small packets into a single large packet. Header and communication overhead is therefore reduced.

另一种可能有助于提高通信能量效率的技术是分组捆绑。该技术可用于多个无线电接口(例如,LTE和一些802.11变体),允许将多个小数据包聚合为单个大数据包。因此减少了报头和通信开销。

3.6. Power Save Services Available in Example Low-Power Radios
3.6. 示例低功率无线电中提供的节能服务

This subsection presents power save services and techniques used in a few relevant examples of wireless low-power radios: IEEE 802.11 [IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4]. For a more detailed overview of each technology, the reader may refer to the literature or to the corresponding specifications.

本小节介绍了无线低功率无线电的几个相关示例中使用的节能服务和技术:IEEE 802.11[IEEE802.11]、蓝牙LE和IEEE 802.15.4[IEEE802.15.4]。对于每项技术的更详细概述,读者可参考文献或相应规范。

3.6.1. Power Save Services Provided by IEEE 802.11
3.6.1. IEEE 802.11提供的节能服务

IEEE 802.11 [IEEE802.11] defines the Power Save Mode (PSM) whereby a station may indicate to an Access Point (AP) that it will enter a sleep mode state. While the station is sleeping, the AP buffers any frames that should be sent to the sleeping station. The station wakes up every listen interval (which can be a multiple of the beacon interval) in order to receive beacons. The AP signals, by means of a beacon field, whether there is data pending for the station or not.

IEEE 802.11[IEEE802.11]定义了省电模式(PSM),其中站点可向接入点(AP)指示其将进入睡眠模式状态。当站点处于睡眠状态时,AP缓冲应发送到睡眠站点的任何帧。电台在每个监听间隔(可以是信标间隔的倍数)唤醒,以便接收信标。AP通过信标场发出信号,指示站点是否有待处理的数据。

If there are not frames to be sent to the station, the latter may get back to sleep mode. Otherwise, the station may send a message requesting the transmission of the buffered data and stay awake in receive mode.

如果没有要发送到站点的帧,后者可能会返回睡眠模式。否则,站点可发送请求传输缓冲数据的消息,并在接收模式下保持清醒。

IEEE 802.11v [IEEE802.11] further defines mechanisms and services for power save of stations/nodes that include Flexible Multicast Service (FMS), Proxy ARP advertisement, extended sleep modes, and traffic filtering. Upper-layer protocol's knowledge of such capabilities, provided by the lower layer, enables better interworking.

IEEE 802.11v[IEEE802.11]进一步定义了用于站点/节点节能的机制和服务,包括灵活多播服务(FMS)、代理ARP广告、扩展睡眠模式和流量过滤。上层协议对底层提供的此类功能的了解,可以实现更好的互通。

These services include:

这些服务包括:

Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to indicate that the non-AP station (STA) will not receive ARP frames. The Proxy ARP capability enables the non-AP STA to remain in power save mode for longer periods of time.

代理ARP:代理ARP功能使接入点(AP)能够指示非AP站(STA)不会接收ARP帧。代理ARP功能使非AP STA能够在更长时间内保持省电模式。

Basic Service Set (BSS) Max Idle Period Management: Enables an AP to indicate a time period during which the AP does not disassociate a STA due to non-receipt of frames from the STA. This supports improved STA power saving and AP resource management.

基本服务集(BSS)最大空闲周期管理:使AP能够指示一个时间段,在此时间段内,AP不会由于没有从STA接收到帧而解除STA的关联。这支持改进的STA节能和AP资源管理。

FMS: A service in which a non-AP STA can request a multicast delivery interval longer than the Delivery Traffic Indication Message (DTIM) interval for the purposes of lengthening the period of time a STA may be in a power save state.

FMS:一种服务,其中非AP STA可以请求比传送业务指示报文(DTIM)间隔更长的多播传送间隔,以延长STA可能处于省电状态的时间段。

Traffic Filtering Service (TFS): A service provided by an AP to a non-AP STA that can reduce the number of frames sent to the STA by dropping individually addressed frames that do not match traffic filters specified by the STA.

流量过滤服务(TFS):AP向非AP STA提供的一种服务,通过丢弃与STA指定的流量过滤器不匹配的单独寻址帧,可以减少发送给STA的帧数。

Using the above services provided by the lower layer, the constrained nodes can achieve either client-initiated power save (via TFS) or network-assisted power save (Proxy ARP, BSS Max Idle Period, and FMS).

通过使用下层提供的上述服务,受约束的节点可以实现客户端启动的节能(通过TFS)或网络辅助节能(代理ARP、BSS最大空闲时间和FMS)。

Upper-layer protocols should synchronize with the parameters such as FMS interval and BSS MAX Idle Period so that the wireless transmissions are not triggered periodically.

上层协议应与FMS间隔和BSS最大空闲周期等参数同步,以便无线传输不会定期触发。

3.6.2. Power Save Services Provided by Bluetooth LE
3.6.2. 蓝牙LE提供的节能服务

Bluetooth LE is a wireless low-power communications technology that is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 specifications [Bluetooth42]. BTLE has been designed for the goal of ultra-low power consumption. IPv6 can be run IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to BTLE [RFC7668].

蓝牙LE是一种无线低功耗通信技术,是蓝牙4.0、4.1和4.2规范的标志性组件[Bluetooth 42]。BTLE的设计目标是超低功耗。通过使用适用于BTLE的6LoWPAN变体[RFC7668],IPv6可以在蓝牙LE网络上运行IPv6。

Bluetooth LE networks comprise a master and one or more slaves, which are connected to the master. The Bluetooth LE master is assumed to be a relatively powerful device, whereas a slave is typically a constrained device (e.g., a Class 1 device).

蓝牙LE网络包括一个主设备和一个或多个连接到主设备的从属设备。蓝牙LE主设备被认为是相对强大的设备,而从设备通常是受约束的设备(例如,1类设备)。

Medium access in Bluetooth LE is based on a Time-Division Multiple Access (TDMA) scheme that is coordinated by the master. This device determines the start of connection events in which communication between the master and a slave takes place. At the beginning of a connection event, the master sends a poll message, which may encapsulate data, to the slave. The latter must send a response, which may also contain data. The master and the slave may continue exchanging data until the end of the connection event. The next opportunity for communication between the master and the slave will be in the next connection event scheduled for the slave.

蓝牙LE中的媒体接入基于由主机协调的时分多址(TDMA)方案。此设备确定主设备和从设备之间发生通信的连接事件的开始。在连接事件开始时,主设备向从设备发送轮询消息,该消息可能会封装数据。后者必须发送一个响应,该响应也可能包含数据。主设备和从设备可以继续交换数据,直到连接事件结束。主设备和从设备之间的下一次通信机会将出现在为从设备安排的下一次连接事件中。

The time between consecutive connection events is defined by the connInterval parameter, which may range between 7.5 ms and 4 s. The slave may remain in sleep mode from the end of its last connection event until the beginning of its next connection event. Therefore, Bluetooth LE is duty-cycled by design. Furthermore, after having replied to the master, a slave is not required to listen to the master (and thus may keep the radio in sleep mode) for connSlaveLatency consecutive connection events. connSlaveLatency is an integer parameter between 0 and 499 that should not cause link inactivity for more than connSupervisionTimeout time. The connSupervisionTimeout parameter is in the range between 100 ms and 32 s.

连续连接事件之间的时间由connInterval参数定义,其范围可能在7.5 ms和4 s之间。从设备从上一次连接事件结束到下一次连接事件开始,可以保持睡眠模式。因此,蓝牙LE设计为占空比循环。此外,在回复主设备后,从设备不需要收听主设备(因此可能会使无线电保持在睡眠模式)的连续连接事件。connSlaveLatency是一个介于0和499之间的整数参数,它不应导致链接不活动超过CONNSMOVISOTIONTIMEOUT时间。connSupervisionTimeout参数在100 ms和32 s之间。

Upper-layer protocols should take into account the medium access and duty-cycling behavior of Bluetooth LE. In particular, connInterval, connSlaveLatency, and connSupervisionTimeout determine the time between two consecutive connection events for a given slave. The upper-layer packet generation pattern and rate should be consistent with the settings of the aforementioned parameters (and vice versa). For example, assume connInterval = 4 seconds, connSlaveLatency = 7 seconds, and connSupervisionTimeout = 32 seconds. With these settings, communication opportunities between a master and a slave will occur during a given interval every 32 seconds. Duration of the interval will depend on several factors, including number of

上层协议应考虑蓝牙LE的介质访问和负载循环行为。特别是,connInterval、connSlaveLatency和connSupervisionTimeout确定给定从机的两个连续连接事件之间的时间。上层包生成模式和速率应与上述参数的设置一致(反之亦然)。例如,假设connInterval=4秒,connSlaveLatency=7秒,ConnServisionTimeout=32秒。通过这些设置,主设备和从设备之间的通信机会将在给定的间隔内每32秒发生一次。间隔的持续时间取决于几个因素,包括

connected slaves, amount of data to be transmitted, etc. In the worst case, only one data unit can be sent from master to slave (and vice versa) every 32 seconds.

连接的从机、要传输的数据量等。在最坏的情况下,每32秒只能从主设备向从设备发送一个数据单元(反之亦然)。

3.6.3. Power Save Services in IEEE 802.15.4
3.6.3. ieee802.15.4中的节能服务

IEEE 802.15.4 [IEEE802.15.4] is a family of standard radio interfaces for low-rate, low-power wireless networking. Since the publication of its first version in 2003, IEEE 802.15.4 [IEEE802.15.4] has become the de facto choice for a wide range of constrained-node network application domains and has been a primary target technology of various IETF working groups such as 6LoWPAN [RFC6282] [RFC6775] [RFC4944] and 6TiSCH [ARCH-6TiSCH]. IEEE 802.15.4 [IEEE802.15.4] specifies a variety of related Physical layer (PHY) and MAC layer functionalities.

IEEE 802.15.4[IEEE802.15.4]是一系列用于低速率、低功耗无线网络的标准无线电接口。自2003年第一版发布以来,IEEE 802.15.4[IEEE802.15.4]已成为各种受限节点网络应用领域的事实选择,并已成为各种IETF工作组的主要目标技术,如6LoWPAN[RFC6282][RFC6775][RFC4944]和6Disch[ARCH-6Disch]。IEEE 802.15.4[IEEE802.15.4]规定了各种相关的物理层(PHY)和MAC层功能。

IEEE 802.15.4 [IEEE802.15.4] defines three roles called device, coordinator, and Personal Area Network (PAN) coordinator. The device role is adequate for nodes that do not implement the complete IEEE 802.15.4 [IEEE802.15.4] functionality and is mainly targeted for constrained nodes with a limited energy source. The coordinator role includes synchronization capabilities and is suitable for nodes that do not suffer severe constraints (e.g., a mains-powered node). The PAN coordinator is a special type of coordinator that acts as a principal controller in an IEEE 802.15.4 [IEEE802.15.4] network.

IEEE 802.15.4[IEEE802.15.4]定义了三个角色,称为设备、协调器和个人局域网(PAN)协调器。设备角色对于未实现完整IEEE 802.15.4[IEEE802.15.4]功能的节点来说是足够的,并且主要针对具有有限能源的受限节点。协调器角色包括同步功能,适用于不受严重约束的节点(例如,电源供电的节点)。PAN协调器是一种特殊类型的协调器,在IEEE 802.15.4[IEEE802.15.4]网络中充当主控制器。

IEEE 802.15.4 [IEEE802.15.4] defines two main types of networks depending on their configuration: beacon-enabled and non-beacon-enabled networks. In the first network type, coordinators periodically transmit beacons. The time between beacons is divided in three main parts: the Contention Access Period (CAP), the Contention Free Period (CFP), and an inactive period. In the first period, nodes use slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for data communication. In the second one, a TDMA scheme controls medium access. During the idle period, communication does not take place, and thus the inactive period is a good opportunity for nodes to turn the radio off and save energy. The coordinator announces in each beacon the list of nodes for which data will be sent in the subsequent period. Therefore, devices may remain in sleep mode by default and wake up periodically to listen to the beacons sent by their coordinator. If a device wants to transmit data, or learns from a beacon that it is an intended destination, then it will exchange messages with the coordinator (and thus consume energy). An underlying assumption is that when a message is sent to a coordinator, the radio of the coordinator will be ready to receive the message.

IEEE 802.15.4[IEEE802.15.4]根据其配置定义了两种主要类型的网络:信标启用网络和非信标启用网络。在第一种网络类型中,协调员定期发送信标。信标之间的时间分为三个主要部分:竞争访问周期(CAP)、无竞争周期(CFP)和非活动周期。在第一阶段,节点使用时隙载波侦听多址(CSMA/CA)进行数据通信。在第二种方案中,TDMA方案控制介质访问。在空闲期间,通信不会发生,因此非活动期间是节点关闭无线电并节省能量的好机会。协调器在每个信标中宣布将在后续时间段中为其发送数据的节点列表。因此,设备在默认情况下可能保持在睡眠模式,并定期醒来以监听其协调器发送的信标。如果设备想要传输数据,或者从信标得知它是预定目的地,那么它将与协调器交换消息(从而消耗能量)。一个基本的假设是,当一条消息被发送到协调器时,协调器的无线电将准备好接收该消息。

The beacon interval and the duration of the active portion of the beacon interval (i.e., the CAP and the CFP), and thus the duty cycle, can be configured. The parameters that control these times are called macBeaconOrder and macSuperframeOrder, respectively. As an example, when IEEE 802.15.4 [IEEE802.15.4] operates in the 2.4 GHz PHY, both times can be (independently) set to values in the range between 15.36 ms and 251.6 s.

可以配置信标间隔和信标间隔的活动部分(即CAP和CFP)的持续时间,从而配置占空比。控制这些时间的参数分别称为macBeaconOrder和macSuperframeOrder。例如,当IEEE 802.15.4[IEEE802.15.4]在2.4 GHz物理层中运行时,这两个时间可以(独立地)设置为15.36 ms和251.6 s之间的值。

In the beaconless mode, nodes use unslotted CSMA/CA for data transmission. The device may be in sleep mode by default and may activate its radio to either i) request to the coordinator whether there is pending data for the device, or to ii) transmit data to the coordinator. The wake-up pattern of the device, if any, is out of the scope of IEEE 802.15.4 [IEEE802.15.4].

在无信标模式下,节点使用非时隙CSMA/CA进行数据传输。默认情况下,设备可能处于睡眠模式,并且可以激活其无线电,以i)向协调器请求是否存在设备的挂起数据,或者ii)向协调器发送数据。设备的唤醒模式(如果有)不在IEEE 802.15.4[IEEE802.15.4]的范围内。

Communication between the two ends of an IEEE 802.15.4 [IEEE802.15.4] link may also take place in a peer-to-peer configuration, whereby both link ends assume the same role. In this case, data transmission can happen at any moment. Nodes must have their radio in receive mode and be ready to listen to the medium by default (which for battery-enabled nodes may lead to a quick battery depletion) or apply synchronization techniques. The latter are out of the scope of IEEE 802.15.4 [IEEE802.15.4].

IEEE 802.15.4[IEEE802.15.4]链路的两端之间的通信也可以在对等配置中发生,其中,两个链路端承担相同的角色。在这种情况下,数据传输随时可能发生。节点必须使其无线电处于接收模式,并在默认情况下准备好收听媒体(对于启用电池的节点,这可能会导致电池快速耗尽)或应用同步技术。后者不属于IEEE 802.15.4[IEEE802.15.4]的范围。

The main MAC layer IEEE 802.15.4 [IEEE802.15.4] amendment to date is IEEE 802.15.4e. This amendment includes various new MAC layer modes, some of which include mechanisms for low energy consumption. Among these, the Time-Slotted Channel Hopping (TSCH) is an outstanding mode that offers robust features for industrial environments, among others. In order to provide the functionality needed to enable IPv6 over TSCH, the 6TiSCH Working Group was created. TSCH is based on a TDMA schedule whereby a set of timeslots are used for frame transmission and reception, and other timeslots are unscheduled. The latter timeslots may be used by a dynamic scheduling mechanism, otherwise, nodes may keep the radio off during the unscheduled timeslots, thus saving energy. The minimal schedule configuration specified in [RFC8180] comprises 101 timeslots; 95 of these timeslots are unscheduled and the timeslot duration is 15 ms.

迄今为止,主要的MAC层IEEE 802.15.4[IEEE802.15.4]修正案是IEEE 802.15.4e。该修正案包括各种新的MAC层模式,其中一些包括用于低能耗的机制。其中,时隙信道跳频(TSCH)是一种出色的模式,它为工业环境等提供了强大的功能。为了提供通过TSCH启用IPv6所需的功能,创建了6TiSCH工作组。TSCH基于TDMA调度,其中一组时隙用于帧传输和接收,而其他时隙是非调度的。后一个时隙可由动态调度机制使用,否则,节点可在未调度的时隙期间保持无线电关闭,从而节省能量。[RFC8180]中规定的最小调度配置包括101个时隙;这些时隙中有95个是非计划的,时隙持续时间为15毫秒。

The previously mentioned CSL and RIT are also 802.15.4e modes designed for low energy.

前面提到的CSL和RIT也是为低能耗设计的802.15.4e模式。

3.6.4. Power Save Services in DECT ULE
3.6.4. 12月份的节能服务

DECT Ultra Low Energy (DECT ULE) is a wireless technology building on the key fundamentals of traditional DECT / Cordless Advanced Technology - internet and quality (CAT-iq) [EN300] but with specific changes to significantly reduce the power consumption at the expense

DECT超低能量(DECT ULE)是一种无线技术,它建立在传统DECT/无绳高级技术的关键基础上-互联网和质量(CAT iq)[EN300],但进行了具体更改,以显著降低功耗为代价

of data throughput [TS102]. DECT ULE devices typically operate on special power-optimized silicon but can connect to a DECT Gateway supporting traditional DECT/CAT-iq for cordless telephony and data as well as the DECT ULE extensions. IPv6 can be run over DECT ULE by using a 6LoWPAN variant [RFC8105].

数据吞吐量的计算[TS102]。DECT-ULE设备通常在专用电源优化硅上运行,但可以连接到支持传统DECT/CAT iq的DECT网关,用于无绳电话和数据以及DECT-ULE扩展。IPv6可以通过使用6LoWPAN变体[RFC8105]在DECT ULE上运行。

DECT defines two major roles: the Portable Part (PP) is the power constrained device while the Fixed Part (FP) is the Gateway or base station in a star topology. Because TDMA/FDMA and Time-Division Duplex (TDD) using dynamic channel allocation for interference, DECT operates in license-free and reserved frequency bands. It provides good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length of 10 ms divided into 24 timeslots, and it supports connection-oriented packet data and connection-less services.

DECT定义了两个主要角色:便携部分(PP)是功率受限设备,而固定部分(FP)是星形拓扑中的网关或基站。由于TDMA/FDMA和时分双工(TDD)使用动态信道分配进行干扰,因此DECT在无许可证和保留频带中工作。它提供良好的室内(约50米)和室外(约300米)覆盖。它使用10毫秒的帧长,分为24个时隙,支持面向连接的分组数据和无连接服务。

The FP usually transmits a so-called dummy bearer (beacon) that is used to broadcast synchronization, system, and paging information. The slot/carrier position of this dummy bearer can automatically be reallocated in order to avoid mutual interference with other DECT signals.

FP通常发送所谓的虚拟承载(信标),用于广播同步、系统和寻呼信息。该虚拟承载的时隙/载波位置可以自动重新分配,以避免与其他DECT信号的相互干扰。

At the MAC level, DECT ULE communications between FP and PP are initiated by the PP. An FP can initiate communication indirectly by sending a paging signal to a PP. The PP determines the timeslot and frequency in which the communication between FP and PP takes place. The PP verifies the radio timeslot/frequency position is unoccupied before it initiates its transmitter. An access-request message, which usually carries data, is sent to the FP. The FP sends a confirm message, which also may carry data. More data can be sent in subsequent frames. A MAC-level automatic retransmission scheme significantly improves the reliability of data transfer. A segmentation and reassembly scheme supports transfer of larger, higher-layer Service Data Units (SDUs) and provides data integrity checks. The DECT ULE packet data service ensures data integrity, proper sequencing, and duplicate protection but not guaranteed delivery. Higher-layer protocols have to take this into consideration.

在MAC层,FP和PP之间的数据通信由PP发起。FP可以通过向PP发送寻呼信号间接发起通信。PP确定FP和PP之间发生通信的时隙和频率。PP在启动其发射机之前验证无线电时隙/频率位置是否未被占用。通常携带数据的访问请求消息被发送到FP。FP发送确认消息,该消息也可能携带数据。可以在后续帧中发送更多数据。MAC层自动重传方案显著提高了数据传输的可靠性。分段和重组方案支持传输更大、更高层的服务数据单元(SDU),并提供数据完整性检查。DECT ULE数据包服务确保数据完整性、正确排序和重复保护,但不保证交付。高层协议必须考虑到这一点。

The FP may send paging information to PPs to trigger connection setup and indicate the required service type. The interval between paging information to a specific PP can be defined in the range of 10 ms to 327 s. The PP may enter sleep mode to save power. The listening interval is defined by the PP application. For short sleep intervals (below ~10 seconds), the PP may be able to retain synchronization to the FP dummy bearer and only turn on the receiver during the expected timeslot. For longer sleep intervals, the PP can't keep synchronization and has to search for, and resynchronize to, the FP dummy bearer. Hence, longer sleep intervals reduce the average

FP可向PPs发送寻呼信息,以触发连接设置并指示所需的服务类型。可以在10 ms到327 s的范围内定义分页信息到特定PP之间的间隔。PP可进入睡眠模式以节省电源。侦听间隔由PP应用程序定义。对于短睡眠间隔(低于~10秒),PP可能能够保持与FP虚拟承载的同步,并且仅在预期时隙期间开启接收器。对于较长的睡眠间隔,PP无法保持同步,必须搜索并重新同步到FP虚拟承载。因此,较长的睡眠间隔会降低平均睡眠时间

energy consumption but add an energy consumption penalty for acquiring synchronization to the FP dummy bearer. The PP can obtain all information to determine paging and acquire synchronization information in a single reception of one full timeslot.

能量消耗,但增加获取FP虚拟承载同步的能量消耗惩罚。PP可以在一个完整时隙的单次接收中获得确定寻呼和获取同步信息的所有信息。

Packet data latency is normally 30 ms for short packets (below or equal to 32 octets), however, if retry and back-off scenarios occur, the latency is increased. The latency can actually be reduced to about 10 ms by doing energy consuming Received Signal Strength Indication (RSSI) scanning in advance. In the direction from FP to PP, the latency is usually increased by the used paging interval and the sleep interval. The MAC layer can piggyback commands to improve efficiency (reduce latency) of higher-layer protocols. Such commands can instruct the PP to initiate a new packet transfer in N frames without the need for resynchronization and can listen to paging or instruct the PP to stay in a higher duty-cycle paging detection mode.

对于短数据包(低于或等于32个八位字节),数据包数据延迟通常为30毫秒,但是,如果出现重试和退避情况,延迟会增加。通过提前进行能耗接收信号强度指示(RSSI)扫描,延迟实际上可以减少到大约10毫秒。在从FP到PP的方向上,延迟通常随使用的分页间隔和睡眠间隔而增加。MAC层可以搭载命令来提高更高层协议的效率(减少延迟)。此类命令可以指示PP在N帧中发起新的分组传输,而无需重新同步,并且可以侦听寻呼或指示PP保持在更高的占空比寻呼检测模式。

The DECT ULE technology allows a per-PP configuration of paging interval, MTU size, reassembly window size, and higher-layer service negotiation and protocol.

DECT ULE技术允许分页间隔、MTU大小、重组窗口大小以及更高层服务协商和协议的每PP配置。

4. IP Adaptation and Transport Layer
4. IP适配和传输层

6LoWPAN provides an adaptation layer designed to support IPv6 over IEEE 802.15.4 [IEEE802.15.4]. 6LoWPAN affects the energy-efficiency problem in three aspects, as follows.

6LoWPAN提供了一个适配层,旨在支持通过IEEE 802.15.4[IEEE802.15.4]的IPv6。6LoWPAN从以下三个方面影响能源效率问题。

First, 6LoWPAN provides one fragmentation and reassembly mechanism, which is aimed at solving the packet size issue in IPv6 and could also affect energy efficiency. IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6 [RFC8200]. 6LoWPAN provides fragmentation and reassembly below the IP layer to solve the problem. One of the benefits from placing fragmentation at a lower layer such as the 6LoWPAN layer is that it can avoid the presence of more IP headers because fragmentation at the IP layer will produce more IP packets, each one carrying its own IP header. However, performance can be severely affected if, after IP layer fragmentation, then 6LoWPAN fragmentation happens as well (e.g., when the upper layer is not aware of the existence of the fragmentation at the 6LoWPAN layer). One solution is to require that the higher layers have an awareness of the lower-layer features and generate small enough packets to avoid fragmentation. In this regard, the Block option in CoAP can be useful when CoAP is used at the application layer [RFC7959].

首先,6LoWPAN提供了一种碎片和重组机制,旨在解决IPv6中的数据包大小问题,并可能影响能效。IPv6要求Internet中的每条链路都有1280个八位字节或更大的MTU。在任何不能完整传输1280个八位字节数据包的链路上,必须在IPv6[RFC8200]下的一层提供特定于链路的分段和重组。6LoWPAN在IP层下提供碎片和重新组装来解决问题。将碎片放置在较低层(如6LoWPAN层)的好处之一是,它可以避免出现更多的IP头,因为IP层的碎片将产生更多的IP数据包,每个数据包都带有自己的IP头。但是,如果在IP层碎片化之后也发生6LoWPAN碎片化(例如,当上层不知道6LoWPAN层存在碎片化),则性能可能会受到严重影响。一种解决方案是要求较高的层了解较低层的特性,并生成足够小的数据包以避免碎片。在这方面,当在应用层使用CoAP时,CoAP中的块选项可能很有用[RFC7959]。

Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies compression of the IPv6 header. Subject to the packet size limit of IEEE 802.15.4 [IEEE802.15.4], a 40-octet-long IPv6 header and an 8 or 20-octet-long UDP and TCP header will consume even more packet space than the data itself. 6LoWPAN provides IPv6 and UDP header compression at the adaptation layer. Therefore, a lower amount of data will be handled by the lower layers, whereas both the sender and receiver will spend more computing power on the compression and decompression of the packets over the air. Compression can also be performed at higher layers (see Section 6.4).

第二,6LoWPAN将计算与通信交换。6LoWPAN应用IPv6标头的压缩。根据IEEE 802.15.4[IEEE802.15.4]的数据包大小限制,40个八位组长的IPv6报头和8或20个八位组长的UDP和TCP报头将消耗比数据本身更多的数据包空间。6LoWPAN在适配层提供IPv6和UDP报头压缩。因此,较低层将处理较低数量的数据,而发送方和接收方将在空中数据包的压缩和解压缩上花费更多的计算能力。压缩也可以在更高的层上进行(见第6.4节)。

Finally, the 6LoWPAN Working Group developed the energy-efficient Neighbor Discovery called 6LoWPAN-ND, which is an energy-efficient replacement of the IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not designed for non-transitive wireless links, as its heavy use of multicast makes it inefficient and sometimes impractical in a low-power and lossy network. 6LoWPAN-ND describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low-Power Wireless Personal Area Networks and similar networks. However, 6LoWPAN-ND does not modify Neighbor Unreachability Detection (NUD) timeouts, which are very short (by default three transmissions spaced 1 second apart). NUD timeout settings should be tuned to take into account the latency that may be introduced by duty-cycled mechanisms at the link layer or the alternative, less impatient NUD algorithms should be considered [RFC7048].

最后,6LoWPAN工作组开发了名为6LoWPAN ND的节能邻居发现,它是IPv6 ND在受限环境中的节能替代品。IPv6邻居发现不是为不可传输的无线链路而设计的,因为它大量使用多播使得它效率低下,有时在低功耗和有损网络中不实用。6LoWPAN ND描述了针对低功耗无线个人区域网络和类似网络的IPv6邻居发现、寻址机制和重复地址检测的简单优化。但是,6LoWPAN ND不会修改邻居不可达性检测(NUD)超时,该超时非常短(默认情况下,三次传输间隔1秒)。应调整NUD超时设置,以考虑链路层的负载循环机制可能引入的延迟,或者应考虑其他不太耐心的NUD算法[RFC7048]。

IPv6 underlies the higher-layer protocols, including both TCP/UDP transport and applications. By design, the higher-layer protocols do not typically have specific information about the lower layers and thus cannot solve the energy-efficiency problem.

IPv6是更高层协议的基础,包括TCP/UDP传输和应用程序。根据设计,高层协议通常没有关于下层的特定信息,因此无法解决能源效率问题。

The network stack can be designed to save computing power. For example, the Contiki implementation has multiple cross-layer optimizations for buffers and energy management, e.g., the computing and validation of UDP/TCP checksums without the need of reading IP headers from a different layer. These optimizations are software implementation techniques and are out of the scope of the IETF and the LWIG Working Group.

可以设计网络堆栈以节省计算能力。例如,Contiki实现对缓冲区和能量管理进行了多个跨层优化,例如,计算和验证UDP/TCP校验和,而无需从不同层读取IP报头。这些优化是软件实现技术,不属于IETF和LWIG工作组的范围。

5. Routing Protocols
5. 路由协议

RPL [RFC6550] is a routing protocol designed by the IETF for constrained environments. RPL exchanges messages periodically and keeps routing states for each destination. RPL is optimized for the many-to-one communication pattern (where network nodes primarily send data towards the border router) but has provisions for any-to-any routing as well.

RPL[RFC6550]是IETF为受限环境设计的路由协议。RPL定期交换消息,并保持每个目的地的路由状态。RPL针对多对一通信模式(网络节点主要向边界路由器发送数据)进行了优化,但也提供了任意对任意路由。

The authors of the Powertrace tool [Powertrace] studied the power profile of RPL. Their analysis divides the routing protocol into control and data traffic. The control plane carries ICMP messages to establish and maintain the routing states. The data plane carries any application that uses RPL for routing packets. The study has shown that the power consumption of the control traffic goes down over time in a relatively stable network. The study also reflects that the routing protocol should keep the control traffic as low as possible to make it energy friendly. The amount of RPL control traffic can be tuned by setting the Trickle [RFC6206] algorithm parameters (i.e., Imin, Imax, and k) to appropriate values. However, there exists a trade-off between energy consumption and other performance parameters such as network convergence time and robustness.

Powertrace工具[Powertrace]的作者研究了RPL的电源配置文件。他们的分析将路由协议分为控制流量和数据流量。控制平面承载ICMP消息以建立和维护路由状态。数据平面承载任何使用RPL路由数据包的应用程序。研究表明,在相对稳定的网络中,控制流量的功耗会随着时间的推移而下降。研究还表明,路由协议应尽可能降低控制流量,使其具有能源友好性。RPL控制通信量可通过将涓流[RFC6206]算法参数(即Imin、Imax和k)设置为适当的值来调整。然而,在能耗和其他性能参数(如网络收敛时间和鲁棒性)之间存在权衡。

RFC 6551 [RFC6551] defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node Energy object that allows to provide information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics may help to balance energy consumption of network nodes, minimize network partitioning, and increase network lifetime.

RFC 6551[RFC6551]定义RPL在路由计算中使用的路由度量和约束。除其他外,RFC 6551指定允许提供与节点能量相关的信息的节点能量对象,例如能量源类型或剩余能量的估计百分比。适当使用基于能量的路由度量有助于平衡网络节点的能量消耗,最小化网络分区,并延长网络寿命。

6. Application Layer
6. 应用层
6.1. Energy-Efficient Features in CoAP
6.1. CoAP的节能特性

CoAP [RFC7252] is designed as a RESTful application protocol that connects the services of smart devices to the World Wide Web. CoAP is not a chatty protocol. It provides basic communication services such as service discovery and GET/POST/PUT/DELETE methods with a binary header.

CoAP[RFC7252]设计为一种RESTful应用程序协议,将智能设备的服务连接到万维网。CoAP不是一个健谈的协议。它提供基本的通信服务,如服务发现和带有二进制头的GET/POST/PUT/DELETE方法。

Energy efficiency is part of the CoAP protocol design. CoAP uses a fixed-length binary header of only four bytes that may be followed by binary options. To reduce regular and frequent queries of the resources, CoAP provides an observe mode in which the requester registers its interest of a certain resource and the responder will report the value whenever it was updated. This reduces the request/ response round trips while keeping information exchange an ubiquitous service; an energy-constrained server can remain in sleep mode during the period between observe notification transmissions.

能源效率是CoAP协议设计的一部分。CoAP使用一个只有四个字节的固定长度二进制头,后面可能跟有二进制选项。为了减少对资源的定期和频繁查询,CoAP提供了一种观察模式,在这种模式下,请求者注册其对某个资源的兴趣,响应者将在更新时报告该值。这减少了请求/响应往返,同时使信息交换成为无处不在的服务;能量受限的服务器可以在两次通知传输之间保持休眠模式。

Furthermore, [RFC7252] defines CoAP proxies that can cache resource representations previously provided by sleepy CoAP servers. The proxies themselves may respond to client requests if the

此外,[RFC7252]定义了CoAP代理,这些代理可以缓存以前由沉睡的CoAP服务器提供的资源表示。如果

corresponding server is sleeping and the resource representation is recent enough. Otherwise, a proxy may attempt to obtain the resource from the sleepy server.

相应的服务器正在休眠,并且资源表示足够新。否则,代理可能会尝试从休眠服务器获取资源。

CoAP proxy and cache functionality may also be used to perform data aggregation. This technique allows a node to receive data messages (e.g., carrying sensor readings) from other nodes in the network, perform an operation based on the content in those messages, and transmit the result of the operation. Such operation may simply be intended to use one packet to carry the readings transported in several packets (which reduces header and transmission overhead), or it may be a more sophisticated operation, possibly based on mathematical, logical, or filtering principles (which reduces the payload size to be transmitted).

CoAP代理和缓存功能也可用于执行数据聚合。该技术允许节点从网络中的其他节点接收数据消息(例如,携带传感器读数),基于这些消息中的内容执行操作,并传输操作结果。这种操作可以简单地打算使用一个分组来携带在多个分组中传输的读数(这减少了报头和传输开销),也可以是更复杂的操作,可能基于数学、逻辑或过滤原理(这减少了要传输的有效载荷大小)。

6.2. Sleepy Node Support
6.2. 休眠节点支持

Beyond these features of CoAP, there have been a number of proposals to further support sleepy nodes at the application layer by leveraging CoAP mechanisms. A good summary of such proposals can be found in [SLEEPY-DEVICES], while an example application (in the context of illustrating several security mechanisms) in a scenario with sleepy devices has been described [CRYPTO-SENSORS]. Approaches to support sleepy nodes include exploiting the use of proxies, leveraging the resource directory [CoRE-RD], or signaling when a node is awake to the interested nodes. Recent work defines publish-subscribe and message queuing extensions to CoAP and the resource directory in order to support devices that spend most of their time asleep [CoAP-BROKER]. Notably, this work has been adopted by the CoRE Working Group.

除了CoAP的这些特性之外,还有许多建议通过利用CoAP机制在应用层进一步支持休眠节点。在[SLEEPY-DEVICES]中可以找到此类建议的一个很好的总结,而在使用SLEEPY-DEVICES的场景中描述了一个示例应用程序(在说明几种安全机制的上下文中)[CRYPTO-SENSORS]。支持休眠节点的方法包括利用代理的使用,利用资源目录[CoRE RD],或者在节点唤醒感兴趣的节点时发出信号。最近的工作定义了对CoAP和资源目录的发布-订阅和消息队列扩展,以支持大部分时间处于休眠状态的设备[CoAP BROKER]。值得注意的是,这项工作已被核心工作组采纳。

In addition to the work within the scope of CoAP to support sleepy nodes, other specifications define application-layer functionality for the same purpose. The Lightweight Machine-to-Machine (LwM2M) specification from the Open Mobile Alliance (OMA) defines a queue mode whereby an LwM2M Server queues requests to an LwM2M Client until the latter (which may often stay in sleep mode) is online. LwM2M functionality operates on top of CoAP.

除了在CoAP范围内支持休眠节点的工作外,其他规范也定义了用于相同目的的应用层功能。来自开放移动联盟(OMA)的轻量级机器对机器(LwM2M)规范定义了一种队列模式,其中LwM2M服务器将对LwM2M客户端的请求排队,直到后者(通常处于睡眠模式)联机。LwM2M功能在CoAP上运行。

oneM2M defines a CoAP binding with an application-layer mechanism for sleepy nodes [oneM2M].

oneM2M使用应用层机制为休眠节点定义CoAP绑定[oneM2M]。

6.3. CoAP Timers
6.3. CoAP定时器

CoAP offers mechanisms for reliable communication between two CoAP endpoints. A CoAP message may be signaled as a confirmable (CON) message, and an acknowledgment (ACK) is issued by the receiver if the CON message is correctly received. The sender starts a

CoAP为两个CoAP端点之间的可靠通信提供了机制。CoAP消息可以作为可确认(CON)消息来发信号,并且如果正确接收到CON消息,则接收机发出确认(ACK)。发送方启动一个

Retransmission Timeout (RTO) for every CON message sent. The initial RTO value is chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value is doubled (unless a limit on the number of retransmissions has been reached). Since duty cycling at the link layer may lead to long latency (i.e., even greater than the initial RTO value), CoAP RTO parameters should be tuned accordingly in order to avoid spurious RTOs that would unnecessarily waste node energy and other resources. On the other hand, note that CoAP can also run on top of TCP [RFC8323]. In that case, similar guidance applies to TCP timers, albeit with greater motivation to carefully configure TCP RTO parameters since [RFC6298] reduced the default initial TCP RTO to 1 second, which may interact more negatively with duty-cycled links than default CoAP RTO values.

发送的每个CON消息的重传超时(RTO)。初始RTO值在2到3s之间随机选择。如果RTO过期,新的RTO值将加倍(除非已达到重新传输次数的限制)。由于链路层的占空比循环可能导致长延迟(即,甚至大于初始RTO值),因此应相应地调整CoAP RTO参数,以避免不必要地浪费节点能量和其他资源的虚假RTO。另一方面,请注意,CoAP也可以在TCP[RFC8323]之上运行。在这种情况下,类似的指导也适用于TCP定时器,尽管出于更大的动机仔细配置TCP RTO参数,因为[RFC6298]将默认的初始TCP RTO减少到1秒,这可能比默认的CoAP RTO值更消极地与占空比链路交互。

6.4. Data Compression
6.4. 数据压缩

Another method intended to reduce the size of the data units to be communicated in constrained-node networks is data compression, which allows to encode data using fewer bits than the original data representation. Data compression is more efficient at higher layers, particularly before encryption is used. In fact, encryption mechanisms may generate an output that does not contain redundancy, making it almost impossible to reduce the data representation size. In CoAP, messages may be encrypted by using Datagram Transport Layer Security (DTLS) or TLS when CoAP over TCP is used, which is the default mechanism for securing CoAP exchanges.

另一种旨在减小要在受限节点网络中通信的数据单元的大小的方法是数据压缩,其允许使用比原始数据表示更少的比特来编码数据。数据压缩在更高层更有效,尤其是在使用加密之前。事实上,加密机制可能会生成不包含冗余的输出,因此几乎不可能减小数据表示大小。在CoAP中,当使用TCP上的CoAP时,可以使用数据报传输层安全性(DTLS)或TLS对消息进行加密,这是保护CoAP交换的默认机制。

7. Summary and Conclusions
7. 摘要和结论

We summarize the key takeaways of this document:

我们总结了本文件的主要要点:

a. Internet protocols designed by the IETF can be considered the customer of the lower layers (PHY, MAC, and duty cycling). To reduce power consumption, it is recommended that Layer 3 designs should operate based on awareness of lower-level parameters rather than treating the lower layer as a black box (see Sections 4, 5, and 6).

a. IETF设计的互联网协议可被视为较低层(PHY、MAC和工作循环)的客户。为了降低功耗,建议第3层设计应基于对较低层参数的了解而运行,而不是将较低层视为黑盒(见第4、5和6节)。

b. It is always useful to compress the protocol headers in order to reduce the transmission/reception power. This design principle has been employed by many protocols in the 6lo and CoRE Working Groups (see Sections 4 and 6).

b. 压缩协议头以降低发送/接收功率总是很有用的。该设计原则已被6lo和核心工作组的许多协议采用(见第4节和第6节)。

c. Broadcast and non-synchronized transmissions consume more than other TX/RX operations. If protocols must use these ways to collect information, reduction of their usage by aggregating similar messages together will be helpful in saving power (see Sections 2 and 6.1).

c. 广播和非同步传输比其他TX/RX操作消耗更多。如果协议必须使用这些方法来收集信息,那么通过将类似的消息聚合在一起来减少它们的使用将有助于节省电力(参见第2节和第6.1节)。

d. Saving power by sleeping as much as possible is used widely (Section 3).

d. 通过尽可能多的睡眠来节省电力被广泛使用(第3节)。

8. IANA Considerations
8. IANA考虑

This document has no IANA actions.

本文档没有IANA操作。

9. Security Considerations
9. 安全考虑

This document discusses energy-efficient protocol design and does not incur any changes or challenges on security issues besides what the protocol specifications have analyzed.

本文档讨论节能协议设计,除了协议规范分析的内容外,不会对安全问题产生任何更改或挑战。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[Bluetooth42] Bluetooth Special Interest Group, "Core Version 4.2", available from "Legacy Core Specifications", December 2014, <https://www.bluetooth.com/specifications/ bluetooth-core-specification/legacy-specifications>.

[Bluetooth42]蓝牙特别兴趣小组,“核心版本4.2”,可从“传统核心规范”获取,2014年12月<https://www.bluetooth.com/specifications/ 蓝牙核心规范/传统规范>。

[EN300] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Common Interface (CI); Part 1: Overview", ETSI EN 300 175-1 V2.6.1, July 2015, <https://www.etsi.org/deliver/ etsi_en/300100_300199/30017501/02.06.01_60/ en_30017501v020601p.pdf>.

[EN300]ETSI,“数字增强无绳通信(DECT);公共接口(CI);第1部分:概述”,ETSI EN 300 175-1 V2.6.11915年7月<https://www.etsi.org/deliver/ etsi_en/300100_300199/30017501/02.06.01_60/en_30017501v020601p.pdf>。

[G9959] ITU-T, "Short range narrow-band digital radiocommunication transceivers - PHY, MAC, SAR and LLC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.

[G9959]ITU-T,“短程窄带数字无线电通信收发器-物理层、MAC层、SAR层和LLC层规范”,ITU-T建议G.9959,2015年1月<http://www.itu.int/rec/T-REC-G.9959>.

[IEEE802.11] IEEE, "IEEE Standard for Information technology-- Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, <http://ieeexplore.ieee.org/document/7786995/versions>.

[IEEE802.11]IEEE,“IEEE信息技术标准——系统局域网和城域网之间的电信和信息交换——具体要求——第11部分:无线局域网介质访问控制(MAC)和物理层(PHY)规范”,IEEE 802.11,DOI 10.1109/IEEESTD.2016.7786995, <http://ieeexplore.ieee.org/document/7786995/versions>.

[IEEE802.15.4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, <https://standards.ieee.org/findstds/ standard/802.15.4-2015.html>.

[IEEE802.15.4]IEEE,“低速无线网络的IEEE标准”,IEEE 802.15.4,DOI 10.1109/IEEESTD.2016.7460875<https://standards.ieee.org/findstds/ 标准/802.15.4-2015.html>。

[MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication Protocol for Building Automation and Control Networks ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to ANSI/ASHRAE Standard 135-2012", July 2014, <https://www.ashrae.org/technical-resources/standards-and-guidelines/standards-addenda/ addenda-to-standard-135-2012>.

[MSTP]ANSI/ASHRAE,“附录:BACnet——楼宇自动化和控制网络的数据通信协议ANSI/ASHRAE附录an、at、au、av、aw、ax和az至ANSI/ASHRAE标准135-2012”,2014年7月<https://www.ashrae.org/technical-resources/standards-and-guidelines/standards-addenda/ 标准-135-2012>的附录。

[NFC] NFC Forum, "NFC Logical Link Control Protocol", Technical Specification, Version 1.3, March 2016.

[NFC]NFC论坛,“NFC逻辑链路控制协议”,技术规范,版本1.3,2016年3月。

[oneM2M] oneM2M, "oneM2M - Published Specifications", <http://www.onem2m.org/technical/published-documents>.

[oneM2M]oneM2M,“oneM2M-已发布规范”<http://www.onem2m.org/technical/published-documents>.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.

[RFC4944]黑山,G.,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>.

[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, March 2011, <https://www.rfc-editor.org/info/rfc6206>.

[RFC6206]Levis,P.,Clausen,T.,Hui,J.,Gnawali,O.,和J.Ko,“涓流算法”,RFC 6206,DOI 10.17487/RFC6206,2011年3月<https://www.rfc-editor.org/info/rfc6206>.

[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.

[RFC6282]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>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.

[RFC6298]Paxson,V.,Allman,M.,Chu,J.,和M.Sargent,“计算TCP的重传计时器”,RFC 6298,DOI 10.17487/RFC62982011年6月<https://www.rfc-editor.org/info/rfc6298>.

[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.

[RFC6550]温特,T.,Ed.,Thubert,P.,Ed.,Brandt,A.,Hui,J.,Kelsey,R.,Levis,P.,Pister,K.,Struik,R.,Vasseur,JP.,和R.Alexander,“RPL:低功耗和有损网络的IPv6路由协议”,RFC 6550,DOI 10.17487/RFC6550,2012年3月<https://www.rfc-editor.org/info/rfc6550>.

[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/RFC6551, March 2012, <https://www.rfc-editor.org/info/rfc6551>.

[RFC6551]Vasseur,JP.,Ed.,Kim,M.,Ed.,Pister,K.,Dejean,N.,和D.Barthel,“低功率和有损网络中用于路径计算的路由度量”,RFC 6551,DOI 10.17487/RFC6551,2012年3月<https://www.rfc-editor.org/info/rfc6551>.

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.

[RFC6775]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>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7228]Bormann,C.,Ersue,M.和A.Keranen,“受限节点网络的术语”,RFC 7228,DOI 10.17487/RFC7228,2014年5月<https://www.rfc-editor.org/info/rfc7228>.

[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>.

[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>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8200]Deering,S.和R.Hinden,“互联网协议,第6版(IPv6)规范”,STD 86,RFC 8200,DOI 10.17487/RFC8200,2017年7月<https://www.rfc-editor.org/info/rfc8200>.

[TS102] ETSI, "Digital Enhanced Cordless Telecommunications (DECT); Ultra Low Energy (ULE); Machine to Machine Communications; Part 2: Home Automation Network (phase 2", ETSI TS 102 939-2 V1.1.1, March 2015, <https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293902/01.01.01_60/ ts_10293902v010101p.pdf>.

[TS102]ETSI,“数字增强无绳通信(DECT);超低能耗(ULE);机器对机器通信;第2部分:家庭自动化网络(第2阶段)”,ETSI TS 102 939-2 V1.1.12015年3月<https://www.etsi.org/deliver/ etsi_ts/102900_102999/10293902/01.01.01_60/ts_10293902V01010101P.pdf>。

10.2. Informative References
10.2. 资料性引用

[AN079] Kim, C., "Measuring Power Consumption of CC2530 With Z-Stack", Application Note AN079, SWRA292, September 2012, <http://www.ti.com/lit/an/swra292/swra292.pdf>.

[AN079]Kim,C.“使用Z型堆栈测量CC2530的功耗”,应用说明AN079,SWRA292,2012年9月<http://www.ti.com/lit/an/swra292/swra292.pdf>.

[ARCH-6TiSCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-13, November 2017.

[ARCH-6TiSCH]Thubert,P.,“基于IEEE 802.15.4的TSCH模式的IPv6架构”,正在进行的工作,草稿-ietf-6TiSCH-Architecture-13,2017年11月。

[CLASS1-CoAP] Kovatsch, M., "Implementing CoAP for Class 1 Devices", Work in Progress, draft-kovatsch-lwig-class1-coap-00, October 2012.

[CLASS1 CoAP]Kovatsch,M.,“为1类设备实施CoAP”,正在进行的工作,草稿-Kovatsch-lwig-CLASS1-CoAP-00,2012年10月。

[CNN-TERMS] Bormann, C., Ersue, M., Keranen, A., and C. Gomez, "Terminology for Constrained-Node Networks", Work in Progress, draft-bormann-lwig-7228bis-02, October 2017.

[CNN-TERMS]Bormann,C.,Ersue,M.,Keranen,A.,和C.Gomez,“受限节点网络的术语”,正在进行的工作,草稿-Bormann-lwig-7228bis-022017年10月。

[CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, March 2018.

[CoAP代理]Koster,M.,Keranen,A.,和J.Jimenez,“受限应用程序协议(CoAP)的发布-订阅代理”,正在进行的工作,草稿-ietf-core-CoAP-pubsub-042018年3月。

[ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", SICS Technical Report T2011:13, December 2011, <http://soda.swedishict.se/5128/>.

[ContikiMAC]Dunkels,A.,“ContikiMAC无线电任务循环协议”,SICS技术报告T2011:13,2011年12月<http://soda.swedishict.se/5128/>.

[CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, Ed., "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-13, March 2018.

[核心研发]谢尔比,Z.,科斯特,M.,鲍曼,C.,斯托克,P.,和C.阿姆苏斯,编辑,“核心资源目录”,正在进行的工作,草稿-ietf-CoRE-Resource-Directory-13,2018年3月。

[CRYPTO-SENSORS] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Work in Progress, draft-ietf-lwig-crypto-sensors-06, February 2018.

[CRYPTO-SENSORS]Sethi,M.,Arkko,J.,Keranen,A.,和H.Back,“保护智能对象网络的实际考虑和实施经验”,正在进行的工作,草稿-ietf-lwig-CRYPTO-SENSORS-062018年2月。

[Powertrace] Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", SICS Technical Report T2011:05, March 2011, <http://soda.swedishict.se/4112/>.

[Powertrace]Dunkels,A.,Eriksson,J.,Finne,N.,和N.Tsiftes,“Powertrace:低功率无线网络的网络级功率分析”,SICS技术报告T2011:052011年3月<http://soda.swedishict.se/4112/>.

[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014, <https://www.rfc-editor.org/info/rfc7048>.

[RFC7048]Nordmark,E.和I.Gashinsky,“邻居不可达性检测太不耐烦”,RFC 7048,DOI 10.17487/RFC7048,2014年1月<https://www.rfc-editor.org/info/rfc7048>.

[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.

[RFC7959]Bormann,C.和Z.Shelby,编辑,“受限应用协议(CoAP)中的分块传输”,RFC 7959,DOI 10.17487/RFC7959,2016年8月<https://www.rfc-editor.org/info/rfc7959>.

[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.

[RFC8105]Mariager,P.,Petersen,J.,Ed.,Shelby,Z.,Van de Logt,M.,和D.Barthel,“通过数字增强无绳通信(DECT)超低能(ULE)传输IPv6数据包”,RFC 8105,DOI 10.17487/RFC8105,2017年5月<https://www.rfc-editor.org/info/rfc8105>.

[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.

[RFC8180]Vilajosana,X.,Ed.,Pister,K.,和T.Watteyne,“IEEE 802.15.4e(6TiSCH)配置TSCH模式下的最小IPv6”,BCP 210,RFC 8180,DOI 10.17487/RFC8180,2017年5月<https://www.rfc-editor.org/info/rfc8180>.

[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.

[RFC8323]Bormann,C.,Lemay,S.,Tschofenig,H.,Hartke,K.,Silverajan,B.,和B.Raymor,Ed.,“TCP,TLS和WebSocket上的CoAP(受限应用协议)”,RFC 8323,DOI 10.17487/RFC83232018年2月<https://www.rfc-editor.org/info/rfc8323>.

[SLEEPY-DEVICES] Rahman, A., "Sleepy Devices: Do we need to Support them in CORE?", Work in Progress, draft-rahman-core-sleepy-nodes-do-we-need-01, February 2014.

[SLEEPY-DEVICES]Rahman,A.,“SLEEPY-DEVICES:我们需要在CORE中支持它们吗?”,正在进行的工作,draft-Rahman-CORE-SLEEPY-nodes-Do-we-need-012014年2月。

Acknowledgments

致谢

Carles Gomez has been supported by the Spanish Government, FEDER, and the ERDF through projects TEC2012-32531 and TEC2016-79988-P.

西班牙政府、FEDER和ERDF通过TEC2012-32531和TEC2016-79988-P项目为Carles Gomez提供了支持。

The authors would like to give thanks for the review and feedback from a number of experts in this area: Carsten Bormann, Ari Keranen, Hannes Tschofenig, Dominique Barthel, Bernie Volz, and Charlie Perkins.

作者要感谢该领域专家的评论和反馈:Carsten Bormann、Ari Keranen、Hannes Tschofenig、Dominique Barthel、Bernie Volz和Charlie Perkins。

The text of this document was improved based on an IESG document editing session during IETF 87. Thanks to Ted Lemon and Joel Jaeggli for initiating and facilitating this editing session.

本文件的文本根据IETF 87期间的IESG文件编辑会议进行了改进。感谢Ted Lemon和Joel Jaeggli发起并推动本次编辑会议。

Contributors

贡献者

Jens T. Petersen, RTX, contributed the section on power save services in DECT ULE.

Jens T.Petersen,RTX,于12月发表了关于节能服务的文章。

Authors' Addresses

作者地址

Carles Gomez Universitat Politecnica de Catalunya C/Esteve Terradas, 7 Castelldefels 08860 Spain

卡莱斯·戈麦斯加泰罗尼亚理工大学C/Esteve Terradas,7 Casteldefels 08860西班牙

   Email: carlesgo@entel.upc.edu
        
   Email: carlesgo@entel.upc.edu
        

Matthias Kovatsch ETH Zurich Universitaetstrasse 6 Zurich, CH-8092 Switzerland

Matthias Kovatsch ETH苏黎世大学大街6号,瑞士苏黎世,CH-8092

   Email: ietf@kovatsch.net
        
   Email: ietf@kovatsch.net
        

Hui Tian China Academy of Telecommunication Research Huayuanbeilu No. 52 Beijing, Haidian District 100191 China

中国电信研究院中国北京市海淀区花园北路52号惠天100191

   Email: tianhui@ritt.cn
        
   Email: tianhui@ritt.cn
        

Zhen Cao (editor) Huawei Technologies China

曹震(编辑)华为技术中国

   Email: zhencao.ietf@gmail.com
        
   Email: zhencao.ietf@gmail.com