draft-ietf-lwig-energy-efficient-08.txt | rfc8352.txt | |||
---|---|---|---|---|
Internet Engineering Task Force C. Gomez | Internet Engineering Task Force (IETF) C. Gomez | |||
Internet-Draft Universitat Politecnica de Catalunya | Request for Comments: 8352 UPC | |||
Intended status: Informational M. Kovatsch | Category: Informational M. Kovatsch | |||
Expires: April 24, 2018 ETH Zurich | ISSN: 2070-1721 ETH Zurich | |||
H. Tian | H. Tian | |||
China Academy of Telecommunication Research | China Academy of Telecommunication Research | |||
Z. Cao, Ed. | Z. Cao, Ed. | |||
Huawei Technologies | Huawei Technologies | |||
October 21, 2017 | April 2018 | |||
Energy-Efficient Features of Internet of Things Protocols | Energy-Efficient Features of Internet of Things Protocols | |||
draft-ietf-lwig-energy-efficient-08 | ||||
Abstract | Abstract | |||
This document describes the challenges for energy-efficient protocol | This document describes the challenges for energy-efficient protocol | |||
operation on constrained devices and the current practices used to | operation on constrained devices and the current practices used to | |||
overcome those challenges. It summarizes the main link-layer | overcome those challenges. It summarizes the main link-layer | |||
techniques used for energy-efficient networking, and it highlights | techniques used for energy-efficient networking, and it highlights | |||
the impact of such techniques on the upper layer protocols so that | the impact of such techniques on the upper-layer protocols so that | |||
they can together achieve an energy efficient behavior. The document | they can together achieve an energy-efficient behavior. The document | |||
also provides an overview of energy-efficient mechanisms available at | also provides an overview of energy-efficient mechanisms available at | |||
each layer of the IETF protocol suite specified for constrained node | each layer of the IETF protocol suite specified for constrained-node | |||
networks. | networks. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | 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. | ||||
This Internet-Draft will expire on April 24, 2018. | 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. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Medium Access Control and Radio Duty Cycling . . . . . . . . 5 | 3. Medium Access Control and Radio Duty Cycling . . . . . . . . 6 | |||
3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 | 3.1. Techniques for Radio Duty Cycling . . . . . . . . . . . . 6 | |||
3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 | 3.2. Latency and Buffering . . . . . . . . . . . . . . . . . . 7 | |||
3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 8 | 3.4. Radio Interface Tuning . . . . . . . . . . . . . . . . . 8 | |||
3.5. Packet bundling . . . . . . . . . . . . . . . . . . . . . 8 | 3.5. Packet Bundling . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.6. Power save services available in example low-power radios 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.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 | |||
3.6.2. Power Save Services Provided by Bluetooth LE . . . . 9 | 3.6.2. Power Save Services Provided by Bluetooth LE . . . . 10 | |||
3.6.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 | 3.6.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 11 | |||
3.6.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 | 3.6.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 | |||
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 14 | 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 14 | |||
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 15 | 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 16 | 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 16 | |||
6.1. Energy efficient features in CoAP . . . . . . . . . . . . 16 | 6.1. Energy-Efficient Features in CoAP . . . . . . . . . . . . 16 | |||
6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 16 | 6.2. Sleepy Node Support . . . . . . . . . . . . . . . . . . . 17 | |||
6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.3. CoAP Timers . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6.4. Data compression . . . . . . . . . . . . . . . . . . . . 17 | 6.4. Data Compression . . . . . . . . . . . . . . . . . . . . 18 | |||
7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 18 | 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 18 | |||
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 10.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 19 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 21 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
1. Introduction | 1. Introduction | |||
Network systems for physical world monitoring contain many battery- | Network systems for monitoring the physical world contain many | |||
powered or energy-harvesting devices. For example, in an | battery-powered or energy-harvesting devices. For example, in an | |||
environmental monitoring system, or a temperature and humidity | environmental monitoring system or a temperature and humidity | |||
monitoring system, there may not be always-on and sustained power | monitoring system, there may not be always on and sustained power | |||
supplies for the potentially large number of constrained devices. In | supplies for the potentially large number of constrained devices. In | |||
such deployment scenarios, it is necessary to optimize the energy | such deployment scenarios, it is necessary to optimize the energy | |||
consumption of the constrained devices. In this document we describe | consumption of the constrained devices. In this document, we | |||
techniques that are in common use at Layer 2 and at Layer 3, and we | describe techniques that are in common use at Layer 2 and at Layer 3, | |||
indicate the need for higher-layer awareness of lower-layer features. | and we indicate the need for higher-layer awareness of lower-layer | |||
features. | ||||
Many research efforts have studied this "energy efficiency" problem. | Many research efforts have studied this "energy efficiency" problem. | |||
Most of this research has focused on how to optimize the system's | Most of this research has focused on how to optimize the system's | |||
power consumption in certain deployment scenarios, or how an existing | power consumption in certain deployment scenarios or how an existing | |||
network function such as routing or security could be more energy- | network function such as routing or security could be more energy | |||
efficient. Only few efforts have focused on energy-efficient designs | efficient. Only few efforts have focused on energy-efficient designs | |||
for IETF protocols and standardized network stacks for such | for IETF protocols and standardized network stacks for such | |||
constrained devices [I-D.kovatsch-lwig-class1-coap]. | constrained devices [CLASS1-CoAP]. | |||
The IETF has developed a suite of Internet protocols suitable for | The IETF has developed a suite of Internet protocols suitable for | |||
such constrained devices, including IPv6 over Low-Power Wireless | such constrained devices, including IPv6 over Low-Power Wireless | |||
Personal Area Networks (6LoWPAN) [RFC6282],[RFC6775],[RFC4944], the | Personal Area Networks (6LoWPAN) [RFC6282] [RFC6775] [RFC4944], the | |||
IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) | IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) | |||
[RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. | [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. | |||
This document tries to summarize the design considerations for making | This document tries to summarize the design considerations for making | |||
the IETF constrained protocol suite as energy-efficient as possible. | the IETF constrained protocol suite as energy efficient as possible. | |||
While this document does not provide detailed and systematic | While this document does not provide detailed and systematic | |||
solutions to the energy efficiency problem, it summarizes the design | solutions to the energy-efficiency problem, it summarizes the design | |||
efforts and analyzes the design space of this problem. In | efforts and analyzes the design space of this problem. In | |||
particular, it provides an overview of the techniques used by the | particular, it provides an overview of the techniques used by the | |||
lower layers to save energy and how these may impact on the upper | lower layers to save energy and how these may impact on the upper | |||
layers. Cross-layer interaction is therefore considered in this | layers. Cross-layer interaction is therefore considered in this | |||
document from this specific point of view. Providing further design | document from this specific point of view. Providing further design | |||
recommendations that go beyond the layered protocol architecture is | recommendations that go beyond the layered protocol architecture is | |||
out of the scope of this document. | out of the scope of this document. | |||
After reviewing the energy-efficient designs of each layer, we | After reviewing the energy-efficient designs of each layer, we | |||
summarize the document by presenting some overall conclusions. | summarize the document by presenting some overall conclusions. | |||
Though the lower layer communication optimization is the key part of | Though the lower-layer communication optimization is the key part of | |||
energy efficient design, the protocol design at the upper layers is | energy-efficient design, the protocol design at the upper layers is | |||
also important to make the device energy-efficient. | also important to make the device energy efficient. | |||
1.1. Terminology | 1.1. Terminology | |||
Terms used in this document are defined in [RFC7228] | Terms used in this document are defined in [RFC7228] [CNN-TERMS]. | |||
[I-D.bormann-lwig-7228bis]. | ||||
2. Overview | 2. Overview | |||
The IETF has developed protocols to enable end-to-end IP | The IETF has developed protocols to enable end-to-end IP | |||
communication between constrained nodes and fully capable nodes. | communication between constrained nodes and fully capable nodes. | |||
This work has expedited the evolution of the traditional Internet | This work has expedited the evolution of the traditional Internet | |||
protocol stack to a light-weight Internet protocol stack. As shown | protocol stack to a lightweight Internet protocol stack. As shown in | |||
in Figure 1 below, the IETF has developed CoAP as the application | Figure 1 below, the IETF has developed CoAP as the application layer | |||
layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE | and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 | |||
802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL | [IEEE802.15.4] and Bluetooth Low Energy (also referred to as | |||
and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently | Bluetooth LE and BTLE), with the support of routing by RPL and | |||
being adapted by the 6lo working group to support IPv6 over various | efficient neighbor discovery by 6LoWPAN Neighbor Discovery (6LoWPAN- | |||
other technologies, such as ITU-T G.9959 [G9959], DECT ULE [TS102], | ND). 6LoWPAN is currently being adapted by the 6lo Working Group to | |||
MS/TP-BACnet [MSTP], and Near Field Communication (NFC) [NFC]. | 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]. | ||||
+-----+ +-----+ +-----+ +------+ | +-----+ +-----+ +-----+ +------+ | |||
|HTTP | | FTP | |SNMP | | CoAP | | |HTTP | | FTP | |SNMP | | CoAP | | |||
+-----+ +-----+ +-----+ +------+ | +-----+ +-----+ +-----+ +------+ | |||
\ / / / \ | \ / / / \ | |||
+-----+ +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+ +-----+ | |||
| TCP | | UDP | | TCP | | UDP | | | TCP | | UDP | | TCP | | UDP | | |||
+-----+ +-----+ ===> +-----+ +-----+ | +-----+ +-----+ ===> +-----+ +-----+ | |||
\ / \ / | \ / \ / | |||
+-----+ +------+ +-------+ +------+ +-----+ | +-----+ +------+ +-------+ +------+ +-----+ | |||
skipping to change at page 4, line 33 ¶ | skipping to change at page 4, line 43 ¶ | |||
+-----+ +------+ +-------+ +------+ +-----+ | +-----+ +------+ +-------+ +------+ +-----+ | |||
| | | | | | |||
+-------+ +-------+ +----------+ | +-------+ +-------+ +----------+ | |||
|MAC/PHY| | 6Lo |--|6LoWPAN-ND| | |MAC/PHY| | 6Lo |--|6LoWPAN-ND| | |||
+-------+ +-------+ +----------+ | +-------+ +-------+ +----------+ | |||
| | | | |||
+-------+ | +-------+ | |||
|MAC/PHY| | |MAC/PHY| | |||
+-------+ | +-------+ | |||
Figure 1: Traditional and Light-weight Internet Protocol Stack | Figure 1: Traditional and Lightweight Internet Protocol Stack | |||
There are numerous published studies reporting comprehensive | There are numerous published studies reporting comprehensive | |||
measurements of wireless communication platforms [Powertrace]. As an | measurements of wireless communication platforms [Powertrace]. As an | |||
example, below we list the energy consumption profile of the most | example, below we list the energy-consumption profile of the most | |||
common operations involved in communication on a prevalent sensor | common operations involved in communication on a prevalent sensor | |||
node platform. The measurement was based on the Tmote Sky with | node platform. The measurement was based on the Tmote Sky with | |||
ContikiMAC [ContikiMAC] as the radio duty cycling algorithm. From | ContikiMAC [ContikiMAC] as the Radio Duty Cycling algorithm. From | |||
this and many other measurement reports (e.g.[AN079]), we can see | this and many other measurement reports (e.g., [AN079]), we can see | |||
that the energy consumption of optimized transmission and reception | that the energy consumption of optimized transmission and reception | |||
are in the same order. For IEEE 802.15.4 and Ultra WideBand (UWB) | are in the same order. For IEEE 802.15.4 [IEEE802.15.4] and Ultra | |||
links, transmitting may actually be even cheaper than receiving. It | WideBand (UWB) links, transmitting may actually be even cheaper than | |||
also shows that broadcast and non-synchronized communication | receiving. It also shows that broadcast and non-synchronized | |||
transmissions are energy costly because they need to acquire the | communication transmissions are energy costly because they need to | |||
medium for a long time. | acquire the medium for a long time. | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Activity | Energy (uJ) | | | Activity | Energy | | |||
| | (microjoules) | | ||||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Broadcast reception | 178 | | | Broadcast reception | 178 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Unicast reception | 222 | | | Unicast reception | 222 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Broadcast transmission | 1790 | | | Broadcast transmission | 1790 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Non-synchronized unicast transmission | 1090 | | | Non-synchronized unicast transmission | 1090 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Synchronized unicast transmission | 120 | | | Synchronized unicast transmission | 120 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Unicast TX to awake receiver | 96 | | | Unicast TX to awake receiver | 96 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
| Listening (for 1000 ms) | 63000 | | | Listening (for 1000 ms) | 63000 | | |||
+---------------------------------------+---------------+ | +---------------------------------------+---------------+ | |||
Figure 2: Power consumption of common operations involved in | Figure 2: Power Consumption of Common Operations Involved in | |||
communication on the Tmote Sky with ContikiMAC | Communication on the Tmote Sky with ContikiMAC | |||
At the Physical layer, one approach that may allow reducing energy | At the Physical layer, one approach that may reduce the energy | |||
consumption of a device that uses a wireless interface is based on | consumption of a device that uses a wireless interface is based on | |||
reducing the device transmit power level as long as the intended next | reducing the device transmit power level, as long as the intended | |||
hop(s) are still within range of the device. In some cases, if node | next hop(s) is still within range of the device. In some cases, if | |||
A has to transmit a message to node B, a solution to reduce node A | node A has to transmit a message to node B, a solution to reduce node | |||
transmit power is to leverage an intermediate device, e.g. node C as | A transmit power is to leverage an intermediate device, e.g., node C | |||
a message forwarder. Let d be the distance between node A and node | as a message forwarder. Let d be the distance between node A and | |||
B. Assuming free-space propagation, where path loss is proportional | node B. Assuming free-space propagation, where path loss is | |||
to d^2, if node C is placed right in the middle of the path between A | proportional to d^2, if node C is placed right in the middle of the | |||
and B (that is, at a distance d/2 from both node A and node B), the | path between A and B (that is, at a distance d/2 from both node A and | |||
minimum transmit power to be used by node A (and by node C) is | node B), the minimum transmit power to be used by node A (and by node | |||
reduced by a factor of 4. However, this solution requires additional | C) is reduced by a factor of 4. However, this solution requires | |||
devices, it requires a routing solution, and it also increases | additional devices, it requires a routing solution, and it also | |||
transmission delay between A and B. | increases transmission delay between A and B. | |||
3. Medium Access Control and Radio Duty Cycling | 3. Medium Access Control and Radio Duty Cycling | |||
In networks, communication and power consumption are interdependent. | In networks, communication and power consumption are interdependent. | |||
The communication device is typically the most power-consuming | The communication device is typically the most power-consuming | |||
component, but merely refraining from transmissions is not enough to | component, but merely refraining from transmissions is not enough to | |||
achieve a low power consumption: the radio may consume as much power | achieve a low power consumption: the radio may consume as much power | |||
in listen mode as when actively transmitting. This illustrates the | in listen mode as when actively transmitting. This illustrates the | |||
key problem known as idle listening, whereby the radio of a device | 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 | may be in receive mode (ready to receive any message), even if no | |||
message is being transmitted to that device. Idle listening can | message is being transmitted to that device. Idle listening can | |||
consume a huge amount of energy unnecessarily. To reduce power | consume a huge amount of energy unnecessarily. To reduce power | |||
consumption, the radio must be switched completely off -- duty-cycled | consumption, the radio must be switched completely off -- duty-cycled | |||
-- as much as possible. By applying duty-cycling, the lifetime of a | -- 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 | 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 | years, whereas otherwise the battery may be exhausted in a few days | |||
or even hours. Duty-cycling is a technique generally employed by | or even hours. Duty cycling is a technique generally employed by | |||
devices that use the P1 strategy [RFC7228], which need to be able to | devices that use the P1 strategy [RFC7228], which need to be able to | |||
communicate on a relatively frequent basis. Note that a more | communicate on a relatively frequent basis. Note that a more | |||
aggressive approach to save energy relies on the P0, Normally-off | aggressive approach to save energy relies on the P0 (Normally-off) | |||
strategy, whereby devices sleep for very long periods and communicate | strategy, whereby devices sleep for very long periods and communicate | |||
infrequently, even though they spend energy in network reattachment | infrequently, even though they spend energy in network reattachment | |||
procedures. | procedures. | |||
From the perspective of Medium Access Control (MAC) and Radio Duty | From the perspective of Medium Access Control (MAC) and Radio Duty | |||
Cycling (RDC), all upper layer protocols, such as routing, RESTful | Cycling (RDC), all upper-layer protocols, such as routing, RESTful | |||
communication, adaptation, and management flows, are applications. | communication, adaptation, and management flows, are applications. | |||
Since the duty cycling algorithm is the key to energy-efficiency of | Since the duty-cycling algorithm is the key to energy efficiency of | |||
the wireless medium, it synchronizes transmission and/or reception | the wireless medium, it synchronizes transmission and/or reception | |||
requests from the higher layers. | requests from the higher layers. | |||
MAC and RDC are not in the scope of the IETF, yet lower layer | MAC and RDC are not in the scope of the IETF, yet lower-layer | |||
designers and chipset manufacturers take great care to save energy. | designers and chipset manufacturers take great care to save energy. | |||
By knowing the behaviors of these lower layers, IETF engineers can | By knowing the behaviors of these lower layers, engineers can design | |||
design protocols that work well with them. The IETF protocols to be | protocols that work well with them. The IETF protocols to be | |||
discussed in the following sections are the customers of the lower | discussed in the following sections are the customers of the lower | |||
layers. | layers. | |||
3.1. Radio Duty Cycling techniques | 3.1. Techniques for Radio Duty Cycling | |||
This subsection describes three main three RDC techniques. Note that | This subsection describes three main RDC techniques. Note that more | |||
more than one of these techniques may be available or can even be | than one of these techniques may be available or can even be combined | |||
combined in a specific radio technology: | in a specific radio technology: | |||
a) Channel sampling. In this solution, the radio interface of a | a) Channel sampling: In this solution, the radio interface of a | |||
device periodically monitors the channel for very short time | device periodically monitors the channel for very short time | |||
intervals (i.e. with a low duty cycle) with the aim of detecting | intervals (i.e., with a low duty cycle) with the aim of detecting | |||
incoming transmissions. In order to make sure that a receiver can | incoming transmissions. In order to make sure that a receiver | |||
correctly receive a transmitted data unit, the sender may prepend a | can correctly receive a transmitted data unit, the sender may | |||
preamble of a duration at least the sampling period to the data unit | prepend a preamble of a duration at least the sampling period to | |||
to be sent. Another option for the sender is to repeatedly transmit | the data unit to be sent. Another option for the sender is to | |||
the data unit, instead of sending a preamble before the data unit. | repeatedly transmit the data unit instead of sending a preamble | |||
Once a transmission is detected by a receiver, the receiver may stay | before the data unit. Once a transmission is detected by a | |||
awake until the complete reception of the data unit. Examples of | receiver, the receiver may stay awake until the complete | |||
radio technologies that use preamble sampling include ContikiMAC, the | reception of the data unit. Examples of radio technologies that | |||
Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the | use preamble sampling include ContikiMAC, the Coordinated Sampled | |||
Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. | Listening (CSL) mode of IEEE 802.15.4e [IEEE802.15.4], and the | |||
Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. | ||||
b) Scheduled transmissions. This approach allows a device to know | b) Scheduled transmissions: This approach allows a device to know | |||
the particular time at which it should be awake (during some time | the particular time at which it should be awake (during some time | |||
interval) in order to receive data. Otherwise, the device may remain | interval) in order to receive data. Otherwise, the device may | |||
in sleep mode. The decision on the times at which communication is | remain in sleep mode. The decision on the times at which | |||
attempted relies on some form of negotation between the involved | communication is attempted relies on some form of negotiation | |||
devices. Such negotiation may be performed per transmission or per | between the involved devices. Such negotiation may be performed | |||
session/connection. Bluetooth Low Energy (Bluetooth LE) is an | per transmission or per session/connection. Bluetooth Low Energy | |||
example of a radio technology based on this mechanism. | (Bluetooth LE) is an example of a radio technology based on this | |||
mechanism. | ||||
c) Listen after send. This technique allows a node to remain in | c) Listen after send: This technique allows a node to remain in | |||
sleep mode by default, wake up and poll a sender (which must be ready | sleep mode by default, then wake up and poll a sender (which must | |||
to receive a poll message) for pending transmissions. After sending | be ready to receive a poll message) for pending transmissions. | |||
the poll message, the node remains in receive mode, ready for a | After sending the poll message, the node remains in receive mode | |||
potential incoming transmission. After a certain time interval, the | and is ready for a potential incoming transmission. After a | |||
node may go back to sleep. For example, the Receiver Initiated | certain time interval, the node may go back to sleep. For | |||
Transmission (RIT) mode of 802.15.4e, and the transmission of data | example, this technique is used in the Receiver Initiated | |||
between a coordinator and a device in IEEE 802.15.4-2003 use this | Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4] and in | |||
technique. | the transmission of data between a coordinator and a device in | |||
the 2003 version of IEEE 802.15.4 [IEEE802.15.4]. | ||||
3.2. Latency and buffering | 3.2. Latency and Buffering | |||
The latency of a data unit transmission to a duty-cycled device is | 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 | equal to or greater than the latency of transmitting to an always-on | |||
device. Therefore, duty-cycling leads to a trade-off between energy | device. Therefore, duty cycling leads to a trade-off between energy | |||
consumption and latency. Note that in addition to a latency | consumption and latency. Note that in addition to a latency | |||
increase, RDC may introduce latency variance, since the latency | increase, RDC may introduce latency variance since the latency | |||
increase is a random variable (which is uniformly distributed if | increase is a random variable (which is uniformly distributed if duty | |||
duty-cycling follows a periodical behavior). | cycling follows a periodic behavior). | |||
On the other hand, due to the latency increase of duty-cycling, a | On the other hand, due to the latency increase introduced by duty | |||
sender waiting for a transmission opportunity may need to store | cycling, a sender waiting for a transmission opportunity may need to | |||
subsequent outgoing packets in a buffer, increasing memory | store subsequent outgoing packets in a buffer. This buffering would | |||
requirements and potentially incurring queuing waiting time that | increase memory requirements and potentially incur queuing wait | |||
contributes to the packet's overall delay and increases the | times. Such wait times would in turn contribute to packet | |||
probability of buffer overflow, leading to losses. | transmission delay and increase the probability of buffer overflow, | |||
leading to losses. | ||||
3.3. Throughput | 3.3. Throughput | |||
Although throughput is not typically a key concern in constrained | Although throughput is not typically a key concern in constrained- | |||
node network applications, it is indeed important in some services in | node network applications, it is indeed important in some services in | |||
such networks, such as over-the-air software updates or when off-line | such networks, such as over-the-air software updates or when off-line | |||
sensors accumulate measurements that have to be quickly transferred | sensors accumulate measurements that have to be quickly transferred | |||
when there is an opportunity for connectivity. | when there is an opportunity for connectivity. | |||
Since RDC introduces inactive intervals in energy-constrained | Since RDC introduces inactive intervals in energy-constrained | |||
devices, it reduces the throughput that can be achieved when | devices, it reduces the throughput that can be achieved when | |||
communicating with such devices. There exists a trade-off between | communicating with such devices. There exists a trade-off between | |||
the achievable throughput and energy consumption. | the achievable throughput and energy consumption. | |||
3.4. Radio interface tuning | 3.4. Radio Interface Tuning | |||
The parameters controlling the radio duty cycle have to be carefully | The parameters controlling the radio duty cycle have to be carefully | |||
tuned to achieve the intended application and/or network | tuned to achieve the intended application and/or network | |||
requirements. On the other hand, upper layers should take into | requirements. On the other hand, upper layers should take into | |||
account the expected latency and/or throughput behavior due to RDC. | account the expected latency and/or throughput behavior due to RDC. | |||
The next subsection provides details on key parameters controlling | The next subsection provides details on key parameters controlling | |||
RDC mechanisms, and thus fundamental trade-offs, for various examples | RDC mechanisms, and thus fundamental trade-offs, for various examples | |||
of relevant low-power radio technologies. | of relevant low-power radio technologies. | |||
3.5. Packet bundling | 3.5. Packet Bundling | |||
Another technique that may be useful to increase communication energy | Another technique that may be useful to increase communication energy | |||
efficiency is packet bundling. This technique, which is available in | efficiency is packet bundling. This technique, which is available in | |||
several radio interfaces (e.g. LTE and some 802.11 variants), allows | several radio interfaces (e.g., LTE and some 802.11 variants), allows | |||
to aggregate several small packets into a single large packet. | for aggregation of several small packets into a single large packet. | |||
Header and communication overhead is therefore reduced. | Header and communication overhead is therefore reduced. | |||
3.6. Power save services available in example low-power radios | 3.6. Power Save Services Available in Example Low-Power Radios | |||
This subsection presents power save services and techniques used in a | This subsection presents power save services and techniques used in a | |||
few relevant examples of wireless low-power radios: IEEE 802.11, | few relevant examples of wireless low-power radios: IEEE 802.11 | |||
Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each | [IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4]. For a | |||
technology, the reader may refer to the literature or to the | more detailed overview of each technology, the reader may refer to | |||
corresponding specifications. | the literature or to the corresponding specifications. | |||
3.6.1. Power Save Services Provided by IEEE 802.11 | 3.6.1. Power Save Services Provided by IEEE 802.11 | |||
IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may | IEEE 802.11 [IEEE802.11] defines the Power Save Mode (PSM) whereby a | |||
indicate to an Access Point (AP) that it will enter a sleep mode | station may indicate to an Access Point (AP) that it will enter a | |||
state. While the station is sleeping, the AP buffers any frames that | sleep mode state. While the station is sleeping, the AP buffers any | |||
should be sent to the sleeping station. The station wakes up every | frames that should be sent to the sleeping station. The station | |||
Listen Interval (which can be a multiple of the Beacon Interval) in | wakes up every listen interval (which can be a multiple of the beacon | |||
order to receive beacons. The AP signals in the beacon whether there | interval) in order to receive beacons. The AP signals, by means of a | |||
is data pending for the station or not. If there are not frames to | beacon field, whether there is data pending for the station or not. | |||
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 [IEEE80211v] further defines mechanisms and services for | If there are not frames to be sent to the station, the latter may get | |||
power save of stations/nodes that include flexible multicast service | back to sleep mode. Otherwise, the station may send a message | |||
(FMS), proxy ARP advertisement, extended sleep modes, and traffic | requesting the transmission of the buffered data and stay awake in | |||
filtering. Upper layer protocols knowledge of such capabilities | receive mode. | |||
provided by the lower layer enables better interworking. | ||||
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. | ||||
These services include: | These services include: | |||
Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to | Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to | |||
indicate that the non-AP station (STA) will not receive ARP frames. | indicate that the non-AP station (STA) will not receive ARP | |||
The Proxy ARP capability enables the non-AP STA to remain in power- | frames. The Proxy ARP capability enables the non-AP STA to remain | |||
save for longer periods of time. | in power save mode for longer periods of time. | |||
Basic Service Set (BSS) Max Idle Period management enables an AP to | Basic Service Set (BSS) Max Idle Period Management: Enables an AP to | |||
indicate a time period during which the AP does not disassociate a | indicate a time period during which the AP does not disassociate a | |||
STA due to non-receipt of frames from the STA. This supports | STA due to non-receipt of frames from the STA. This supports | |||
improved STA power saving and AP resource management. | improved STA power saving and AP resource management. | |||
FMS: A service in which a non-access point (non-AP) STA can request a | FMS: A service in which a non-AP STA can request a multicast | |||
multicast delivery interval longer than the delivery traffic | delivery interval longer than the Delivery Traffic Indication | |||
indication message (DTIM) interval for the purposes of lengthening | Message (DTIM) interval for the purposes of lengthening the period | |||
the period of time a STA may be in a power save state. | of time a STA may be in a power save state. | |||
Traffic Filtering Service (TFS): A service provided by an access | Traffic Filtering Service (TFS): A service provided by an AP to a | |||
point (AP) to a non-AP STA that can reduce the number of frames sent | non-AP STA that can reduce the number of frames sent to the STA by | |||
to the STA by dropping individually addressed frames that do not | dropping individually addressed frames that do not match traffic | |||
match traffic filters specified by the STA. | filters specified by the STA. | |||
Using the above services provided by the lower layer, the constrained | Using the above services provided by the lower layer, the constrained | |||
nodes can achieve either client initiated power save (via TFS) or | nodes can achieve either client-initiated power save (via TFS) or | |||
network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). | network-assisted power save (Proxy ARP, BSS Max Idle Period, and | |||
FMS). | ||||
Upper layer protocols should synchronize with the parameters such as | Upper-layer protocols should synchronize with the parameters such as | |||
FMS interval and BSS MAX Idle Period, so that the wireless | FMS interval and BSS MAX Idle Period so that the wireless | |||
transmissions are not triggered periodically. | transmissions are not triggered periodically. | |||
3.6.2. Power Save Services Provided by Bluetooth LE | 3.6.2. Power Save Services Provided by Bluetooth LE | |||
Bluetooth LE is a wireless low-power communications technology that | Bluetooth LE is a wireless low-power communications technology that | |||
is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 | is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 | |||
specifications [Bluetooth42]. BT-LE has been designed for the goal | specifications [Bluetooth42]. BTLE has been designed for the goal of | |||
of ultra-low-power consumption. IPv6 can be run IPv6 over Bluetooth | ultra-low power consumption. IPv6 can be run IPv6 over Bluetooth LE | |||
LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668]. | networks by using a 6LoWPAN variant adapted to BTLE [RFC7668]. | |||
Bluetooth LE networks comprise a master and one or more slaves which | Bluetooth LE networks comprise a master and one or more slaves, which | |||
are connected to the master. The Bluetooth LE master is assumed to | are connected to the master. The Bluetooth LE master is assumed to | |||
be a relatively powerful device, whereas a slave is typically a | be a relatively powerful device, whereas a slave is typically a | |||
constrained device (e.g. a class 1 device). | constrained device (e.g., a Class 1 device). | |||
Medium access in Bluetooth LE is based on a Time Division Multiple | Medium access in Bluetooth LE is based on a Time-Division Multiple | |||
Access (TDMA) scheme which is coordinated by the master. This device | Access (TDMA) scheme that is coordinated by the master. This device | |||
determines the start of connection events, in which communication | determines the start of connection events in which communication | |||
between the master and a slave takes place. At the beginning of a | between the master and a slave takes place. At the beginning of a | |||
connection event, the master sends a poll message, which may | connection event, the master sends a poll message, which may | |||
encapsulate data, to the slave. The latter must send a response, | encapsulate data, to the slave. The latter must send a response, | |||
which may also contain data. The master and the slave may continue | which may also contain data. The master and the slave may continue | |||
exchanging data until the end of the connection event. The next | exchanging data until the end of the connection event. The next | |||
opportunity for communication between the master and the slave will | opportunity for communication between the master and the slave will | |||
be in the next connection event scheduled for the slave. | be in the next connection event scheduled for the slave. | |||
The time between consecutive connection events is defined by the | The time between consecutive connection events is defined by the | |||
connInterval parameter, which may range between 7.5 ms and 4 s. The | connInterval parameter, which may range between 7.5 ms and 4 s. The | |||
slave may remain in sleep mode since the end of its last connection | slave may remain in sleep mode from the end of its last connection | |||
event until the beginning of its next connection event. Therefore, | event until the beginning of its next connection event. Therefore, | |||
Bluetooth LE is duty-cycled by design. Furthermore, after having | Bluetooth LE is duty-cycled by design. Furthermore, after having | |||
replied to the master, a slave is not required to listen to the | replied to the master, a slave is not required to listen to the | |||
master (and thus may keep the radio in sleep mode) for | master (and thus may keep the radio in sleep mode) for | |||
connSlaveLatency consecutive connection events. connSlaveLatency is | connSlaveLatency consecutive connection events. connSlaveLatency is | |||
an integer parameter between 0 and 499 which should not cause link | an integer parameter between 0 and 499 that should not cause link | |||
inactivity for more than connSupervisionTimeout time. The | inactivity for more than connSupervisionTimeout time. The | |||
connSupervisionTimeout parameter is in the range between 100 ms and | connSupervisionTimeout parameter is in the range between 100 ms and | |||
32 s. | 32 s. | |||
Upper layer protocols should take into account the medium access and | Upper-layer protocols should take into account the medium access and | |||
duty-cycling behavior of Bluetooth LE. In particular, connInterval, | duty-cycling behavior of Bluetooth LE. In particular, connInterval, | |||
connSlaveLatency and connSupervisionTimeout determine the time | connSlaveLatency, and connSupervisionTimeout determine the time | |||
between two consecutive connection events for a given slave. The | between two consecutive connection events for a given slave. The | |||
upper layer packet generation pattern and rate should be consistent | upper-layer packet generation pattern and rate should be consistent | |||
with the settings of the aforementioned parameters (and vice versa). | with the settings of the aforementioned parameters (and vice versa). | |||
For example, assume connInterval=4 seconds, connSlaveLatency=7 and | For example, assume connInterval = 4 seconds, connSlaveLatency = | |||
connSupervisionTimeout=32 seconds. With these settings, | 7 seconds, and connSupervisionTimeout = 32 seconds. With these | |||
communication opportunities between a master and a slave will occur | settings, communication opportunities between a master and a slave | |||
during a given interval every 32 seconds. Duration of the interval | will occur during a given interval every 32 seconds. Duration of the | |||
will depend on several factors, including number of connected slaves, | interval will depend on several factors, including number of | |||
amount of data to be transmitted, etc. In the worst case, only one | connected slaves, amount of data to be transmitted, etc. In the | |||
data unit can be sent from master to slave and vice versa every 32 | worst case, only one data unit can be sent from master to slave (and | |||
seconds. | vice versa) every 32 seconds. | |||
3.6.3. Power Save Services in IEEE 802.15.4 | 3.6.3. Power Save Services in IEEE 802.15.4 | |||
IEEE 802.15.4 is a family of standard radio interfaces for low-rate, | IEEE 802.15.4 [IEEE802.15.4] is a family of standard radio interfaces | |||
low-power wireless networking [fifteendotfour]. Since the | for low-rate, low-power wireless networking. Since the publication | |||
publication of its first version in 2003, IEEE 802.15.4 has become | 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 | the de facto choice for a wide range of constrained-node network | |||
application domains and has been a primary target technology of | application domains and has been a primary target technology of | |||
various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775], | various IETF working groups such as 6LoWPAN [RFC6282] [RFC6775] | |||
[RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 | [RFC4944] and 6TiSCH [ARCH-6TiSCH]. IEEE 802.15.4 [IEEE802.15.4] | |||
specifies a variety of related PHY and MAC layer functionalites. | specifies a variety of related Physical layer (PHY) and MAC layer | |||
functionalities. | ||||
IEEE 802.15.4 defines three roles called device, coordinator and | IEEE 802.15.4 [IEEE802.15.4] defines three roles called device, | |||
Personal Area Network (PAN) coordinator. The device role is adequate | coordinator, and Personal Area Network (PAN) coordinator. The device | |||
for nodes that do not implement the complete IEEE 802.15.4 | role is adequate for nodes that do not implement the complete IEEE | |||
functionality, and is mainly targeted for constrained nodes with a | 802.15.4 [IEEE802.15.4] functionality and is mainly targeted for | |||
limited energy source. The coordinator role includes synchronization | constrained nodes with a limited energy source. The coordinator role | |||
capabilities and is suitable for nodes that do not suffer severe | includes synchronization capabilities and is suitable for nodes that | |||
constraints (e.g. a mains-powered node). The PAN coordinator is a | do not suffer severe constraints (e.g., a mains-powered node). The | |||
special type of coordinator that acts as a principal controller in an | PAN coordinator is a special type of coordinator that acts as a | |||
IEEE 802.15.4 network. | principal controller in an IEEE 802.15.4 [IEEE802.15.4] network. | |||
IEEE 802.15.4 defines two main types of networks depending on their | IEEE 802.15.4 [IEEE802.15.4] defines two main types of networks | |||
configuration: beacon-enabled and nonbeacon-enabled networks. In the | depending on their configuration: beacon-enabled and non-beacon- | |||
first network type, coordinators periodically transmit beacons. The | enabled networks. In the first network type, coordinators | |||
time between beacons is divided in three main parts: the Contention | periodically transmit beacons. The time between beacons is divided | |||
Access Period (CAP), the Contention Free Period (CFP) and an inactive | in three main parts: the Contention Access Period (CAP), the | |||
period. In the first period, nodes use slotted Carrier Sense | Contention Free Period (CFP), and an inactive period. In the first | |||
Multiple Access / Collision Avoidance (CSMA/CA) for data | period, nodes use slotted Carrier Sense Multiple Access with | |||
communication. In the second one, a TDMA scheme controls medium | Collision Avoidance (CSMA/CA) for data communication. In the second | |||
access. During the idle period, communication does not take place, | one, a TDMA scheme controls medium access. During the idle period, | |||
thus the inactive period is a good opportunity for nodes to turn the | communication does not take place, and thus the inactive period is a | |||
radio off and save energy. The coordinator announces in each beacon | good opportunity for nodes to turn the radio off and save energy. | |||
the list of nodes for which data will be sent in the subsequent | The coordinator announces in each beacon the list of nodes for which | |||
period. Therefore, devices may remain in sleep mode by default and | data will be sent in the subsequent period. Therefore, devices may | |||
wake up periodically to listen to the beacons sent by their | remain in sleep mode by default and wake up periodically to listen to | |||
coordinator. If a device wants to transmit data, or learns from a | the beacons sent by their coordinator. If a device wants to transmit | |||
beacon that it is an intended destination, then it will exchange | data, or learns from a beacon that it is an intended destination, | |||
messages with the coordinator (and thus consume energy). An | then it will exchange messages with the coordinator (and thus consume | |||
underlying assumption is that when a message is sent to a | energy). An underlying assumption is that when a message is sent to | |||
coordinator, the radio of the coordinator will be ready to receive | a coordinator, the radio of the coordinator will be ready to receive | |||
the message. | the message. | |||
The beacon interval and the duration of the beacon interval active | The beacon interval and the duration of the active portion of the | |||
portion (i.e. the CAP and the CFP), and thus the duty cycle, can be | beacon interval (i.e., the CAP and the CFP), and thus the duty cycle, | |||
configured. The parameters that control these times are called | can be configured. The parameters that control these times are | |||
macBeaconOrder and macSuperframeOrder, respectively. As an example, | called macBeaconOrder and macSuperframeOrder, respectively. As an | |||
when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be | example, when IEEE 802.15.4 [IEEE802.15.4] operates in the 2.4 GHz | |||
(independently) set to values in the range between 15.36 ms and 251.6 | PHY, both times can be (independently) set to values in the range | |||
seconds. | between 15.36 ms and 251.6 s. | |||
In the beaconless mode, nodes use unslotted CSMA/CA for data | In the beaconless mode, nodes use unslotted CSMA/CA for data | |||
transmission. The device may be in sleep mode by default and may | transmission. The device may be in sleep mode by default and may | |||
activate its radio to either i) request to the coordinator whether | activate its radio to either i) request to the coordinator whether | |||
there is pending data for the device, or ii) to transmit data to the | 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 | coordinator. The wake-up pattern of the device, if any, is out of | |||
the scope of IEEE 802.15.4. | the scope of IEEE 802.15.4 [IEEE802.15.4]. | |||
Communication between the two ends of an IEEE 802.15.4 link may also | Communication between the two ends of an IEEE 802.15.4 [IEEE802.15.4] | |||
take place in a peer-to-peer configuration, whereby both link ends | link may also take place in a peer-to-peer configuration, whereby | |||
assume the same role. In this case, data transmission can happen at | both link ends assume the same role. In this case, data transmission | |||
any moment. Nodes must have their radio in receive mode, and be | can happen at any moment. Nodes must have their radio in receive | |||
ready to listen to the medium by default (which for battery-enabled | mode and be ready to listen to the medium by default (which for | |||
nodes may lead to a quick battery depletion), or apply | battery-enabled nodes may lead to a quick battery depletion) or apply | |||
synchronization techniques. The latter are out of the scope of IEEE | synchronization techniques. The latter are out of the scope of IEEE | |||
802.15.4. | 802.15.4 [IEEE802.15.4]. | |||
The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. | The main MAC layer IEEE 802.15.4 [IEEE802.15.4] amendment to date is | |||
This amendment includes various new MAC layer modes, some of which | IEEE 802.15.4e. This amendment includes various new MAC layer modes, | |||
include mechanisms for low energy consumption. Among these, the | some of which include mechanisms for low energy consumption. Among | |||
Time-Slotted Channel Hopping (TSCH) is an outstanding mode which | these, the Time-Slotted Channel Hopping (TSCH) is an outstanding mode | |||
offers robust features for industrial environments, among others. In | that offers robust features for industrial environments, among | |||
order to provide the functionality needed to enable IPv6 over TSCH, | others. In order to provide the functionality needed to enable IPv6 | |||
the 6TiSCH working group was created. TSCH is based on a TDMA | over TSCH, the 6TiSCH Working Group was created. TSCH is based on a | |||
schedule whereby a set of time slots are used for frame transmission | TDMA schedule whereby a set of timeslots are used for frame | |||
and reception, and other time slots are unscheduled. The latter time | transmission and reception, and other timeslots are unscheduled. The | |||
slots may be used by a dynamic scheduling mechanism, otherwise nodes | latter timeslots may be used by a dynamic scheduling mechanism, | |||
may keep the radio off during the unscheduled time slots, thus saving | otherwise, nodes may keep the radio off during the unscheduled | |||
energy. The minimal schedule configuration specified in | timeslots, thus saving energy. The minimal schedule configuration | |||
[I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time | specified in [RFC8180] comprises 101 timeslots; 95 of these timeslots | |||
slots are unscheduled and the time slot duration is 15 ms. | are unscheduled and the timeslot duration is 15 ms. | |||
The previously mentioned CSL and RIT are also 802.15.4e modes | The previously mentioned CSL and RIT are also 802.15.4e modes | |||
designed for low energy. | designed for low energy. | |||
3.6.4. Power Save Services in DECT ULE | 3.6.4. Power Save Services in DECT ULE | |||
DECT Ultra Low Energy (DECT ULE) is a wireless technology building on | DECT Ultra Low Energy (DECT ULE) is a wireless technology building on | |||
the key fundamentals of traditional DECT / CAT-iq [EN300] but with | the key fundamentals of traditional DECT / Cordless Advanced | |||
specific changes to significantly reduce the power consumption at the | Technology - internet and quality (CAT-iq) [EN300] but with specific | |||
expense of data throughput [TS102]. DECT ULE devices typically | changes to significantly reduce the power consumption at the expense | |||
operate on special power optimized silicon, but can connect to a DECT | of data throughput [TS102]. DECT ULE devices typically operate on | |||
Gateway supporting traditional DECT / CAT-iq for cordless telephony | special power-optimized silicon but can connect to a DECT Gateway | |||
and data as well as the DECT ULE extensions. IPv6 can be run over | supporting traditional DECT/CAT-iq for cordless telephony and data as | |||
DECT ULE by using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule]. | well as the DECT ULE extensions. IPv6 can be run over DECT ULE by | |||
using a 6LoWPAN variant [RFC8105]. | ||||
DECT defines two major roles: the Portable Part (PP) is the power | DECT defines two major roles: the Portable Part (PP) is the power | |||
constrained device, while the Fixed Part (FP) is the Gateway or base | constrained device while the Fixed Part (FP) is the Gateway or base | |||
station in a star topology. DECT operates in license free and | station in a star topology. Because TDMA/FDMA and Time-Division | |||
reserved frequency bands based on TDMA/FDMA and TDD using dynamic | Duplex (TDD) using dynamic channel allocation for interference, DECT | |||
channel allocation for interference avoidance. It provides good | operates in license-free and reserved frequency bands. It provides | |||
indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length | good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame | |||
of 10 ms divided into 24 timeslots, and it supports connection | length of 10 ms divided into 24 timeslots, and it supports | |||
oriented, packet data and connection-less services. | connection-oriented packet data and connection-less services. | |||
The FP usually transmits a so-called dummy bearer (beacon) that is | The FP usually transmits a so-called dummy bearer (beacon) that is | |||
used to broadcast synchronization, system and paging information. | used to broadcast synchronization, system, and paging information. | |||
The slot/carrier position of this dummy bearer can automatically be | The slot/carrier position of this dummy bearer can automatically be | |||
reallocated in order to avoid mutual interference with other DECT | reallocated in order to avoid mutual interference with other DECT | |||
signals. | signals. | |||
At the MAC level DECT ULE communications between FP and PP are | At the MAC level, DECT ULE communications between FP and PP are | |||
initiated by the PP. A FP can initiate communication indirectly by | initiated by the PP. An FP can initiate communication indirectly by | |||
sending paging signal to a PP. The PP determines the timeslot and | sending a paging signal to a PP. The PP determines the timeslot and | |||
frequency on which the communication between FP and PP takes place. | frequency in which the communication between FP and PP takes place. | |||
The PP verifies the radio timeslot/frequency position is unoccupied | The PP verifies the radio timeslot/frequency position is unoccupied | |||
before it initiates its transmitter. An access-request message, | before it initiates its transmitter. An access-request message, | |||
which usually carries data, is sent to the FP. The FP sends a | 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 | confirm message, which also may carry data. More data can be sent in | |||
subsequent frames. A MAC level automatic retransmission scheme | subsequent frames. A MAC-level automatic retransmission scheme | |||
significantly improves data transfer reliability. A segmentation and | significantly improves the reliability of data transfer. A | |||
reassembly scheme supports transfer of larger higher layer SDUs and | segmentation and reassembly scheme supports transfer of larger, | |||
provides data integrity check. The DECT ULE packet data service | higher-layer Service Data Units (SDUs) and provides data integrity | |||
ensures data integrity, proper sequencing, duplicate protection, but | checks. The DECT ULE packet data service ensures data integrity, | |||
not guaranteed delivery. Higher layers protocols have to take this | proper sequencing, and duplicate protection but not guaranteed | |||
into consideration. | delivery. Higher-layer protocols have to take this into | |||
consideration. | ||||
The FP may send paging information to PPs to trigger connection setup | The FP may send paging information to PPs to trigger connection setup | |||
and indicate the required service type. The interval between paging | and indicate the required service type. The interval between paging | |||
information to a specific PP can be defined in range 10 ms to 327 | information to a specific PP can be defined in the range of 10 ms to | |||
seconds. The PP may enter sleep mode to save power. The listening | 327 s. The PP may enter sleep mode to save power. The listening | |||
interval is defined by the PP application. For short sleep intervals | interval is defined by the PP application. For short sleep intervals | |||
(below ~10 seconds) the PP may be able to retain synchronization to | (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 | the FP dummy bearer and only turn on the receiver during the expected | |||
timeslot. For longer sleep intervals the PP can't keep | timeslot. For longer sleep intervals, the PP can't keep | |||
synchronization and has to search for and resynchronize to the FP | synchronization and has to search for, and resynchronize to, the FP | |||
dummybearer. Hence, longer sleep interval reduces the average energy | dummy bearer. Hence, longer sleep intervals reduce the average | |||
consumption, but adds a energy consumption penalty for acquiring | energy consumption but add an energy consumption penalty for | |||
synchronization to the FP dummy bearer. The PP can obtain all | acquiring synchronization to the FP dummy bearer. The PP can obtain | |||
information to determine paging and acquire synchronization | all information to determine paging and acquire synchronization | |||
information in a single reception of one full timeslot. | information in a single reception of one full timeslot. | |||
Packet data latency is normally 30 ms for short packets (below or | Packet data latency is normally 30 ms for short packets (below or | |||
equal to 32 octets), however if retry and back-off scenarios occur, | equal to 32 octets), however, if retry and back-off scenarios occur, | |||
the latency is increased. The latency can actually be reduced to | the latency is increased. The latency can actually be reduced to | |||
about 10 ms by doing energy consuming RSSI scanning in advance. In | about 10 ms by doing energy consuming Received Signal Strength | |||
the direction from FP to PP the latency is usually increased by the | Indication (RSSI) scanning in advance. In the direction from FP to | |||
used paging interval and the sleep interval. The MAC layer can | PP, the latency is usually increased by the used paging interval and | |||
piggyback commands to improve efficiency (reduce latency) of higher | the sleep interval. The MAC layer can piggyback commands to improve | |||
layer protocols. Such commands can instruct the PP to initiate a new | efficiency (reduce latency) of higher-layer protocols. Such commands | |||
packet transfer in N frames without the need for resynchronization | can instruct the PP to initiate a new packet transfer in N frames | |||
and listening to paging or instruct the PP to stay in a higher duty | without the need for resynchronization and can listen to paging or | |||
cycle paging detection mode. | instruct the PP to stay in a higher duty-cycle paging detection mode. | |||
The DECT ULE technology allows per PP configuration of paging | The DECT ULE technology allows a per-PP configuration of paging | |||
interval, MTU size, reassembly window size and higher layer service | interval, MTU size, reassembly window size, and higher-layer service | |||
negotiation and protocol. | negotiation and protocol. | |||
4. IP Adaptation and Transport Layer | 4. IP Adaptation and Transport Layer | |||
6LoWPAN provides an adaptation layer designed to support IPv6 over | 6LoWPAN provides an adaptation layer designed to support IPv6 over | |||
IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three | IEEE 802.15.4 [IEEE802.15.4]. 6LoWPAN affects the energy-efficiency | |||
aspects, as follows. | problem in three aspects, as follows. | |||
First, 6LoWPAN provides one fragmentation and reassembly mechanism | First, 6LoWPAN provides one fragmentation and reassembly mechanism, | |||
which is aimed at solving the packet size issue in IPv6 and could | which is aimed at solving the packet size issue in IPv6 and could | |||
also affect energy-efficiency. IPv6 requires that every link in the | also affect energy efficiency. IPv6 requires that every link in the | |||
internet have an MTU of 1280 octets or greater. On any link that | Internet have an MTU of 1280 octets or greater. On any link that | |||
cannot convey a 1280-octet packet in one piece, link-specific | cannot convey a 1280-octet packet in one piece, link-specific | |||
fragmentation and reassembly must be provided at a layer below IPv6 | fragmentation and reassembly must be provided at a layer below IPv6 | |||
[RFC2460]. 6LoWPAN provides fragmentation and reassembly below the | [RFC8200]. 6LoWPAN provides fragmentation and reassembly below the | |||
IP layer to solve the problem. One of the benefits from placing | 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 | fragmentation at a lower layer such as the 6LoWPAN layer is that it | |||
can avoid the presence of more IP headers, because fragmentation at | can avoid the presence of more IP headers because fragmentation at | |||
the IP layer will produce more IP packets, each one carrying its own | the IP layer will produce more IP packets, each one carrying its own | |||
IP header. However, performance can be severely affected if, after | IP header. However, performance can be severely affected if, after | |||
IP layer fragmentation, then 6LoWPAN fragmentation happens as well | IP layer fragmentation, then 6LoWPAN fragmentation happens as well | |||
(e.g. when the upper layer is not aware of the existence of the | (e.g., when the upper layer is not aware of the existence of the | |||
fragmentation at the 6LoWPAN layer). One solution is to require | fragmentation at the 6LoWPAN layer). One solution is to require that | |||
higher layers awareness of lower layer features and generate small | the higher layers have an awareness of the lower-layer features and | |||
enough packets to avoid fragmentation. In this regard, the Block | generate small enough packets to avoid fragmentation. In this | |||
option in CoAP can be useful when CoAP is used at the application | regard, the Block option in CoAP can be useful when CoAP is used at | |||
layer [RFC 7959]. | the application layer [RFC7959]. | |||
Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies | Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies | |||
compression of the IPv6 header. Subject to the packet size limit of | compression of the IPv6 header. Subject to the packet size limit of | |||
IEEE 802.15.4, 40 octets long IPv6 header and 8 octets or 20 octets | IEEE 802.15.4 [IEEE802.15.4], a 40-octet-long IPv6 header and an 8 or | |||
long UDP and TCP header will consume even more packet space than the | 20-octet-long UDP and TCP header will consume even more packet space | |||
data itself. 6LoWPAN provides IPv6 and UDP header compression at the | than the data itself. 6LoWPAN provides IPv6 and UDP header | |||
adaptation layer. Therefore, a lower amount of data will be handled | compression at the adaptation layer. Therefore, a lower amount of | |||
by the lower layers, whereas both the sender and receiver will spend | data will be handled by the lower layers, whereas both the sender and | |||
more computing power on the compression and decompression of the | receiver will spend more computing power on the compression and | |||
packets over the air. Compression can also be performed at higher | decompression of the packets over the air. Compression can also be | |||
layers (see Section 6.4). | performed at higher layers (see Section 6.4). | |||
Finally, the 6LoWPAN working group developed the energy-efficient | Finally, the 6LoWPAN Working Group developed the energy-efficient | |||
Neighbor Discovery called 6LoWPAN-ND, which is an energy efficient | Neighbor Discovery called 6LoWPAN-ND, which is an energy-efficient | |||
replacement of the IPv6 ND in constrained environments. IPv6 | replacement of the IPv6 ND in constrained environments. IPv6 | |||
Neighbor Discovery was not designed for non-transitive wireless | Neighbor Discovery was not designed for non-transitive wireless | |||
links, as its heavy use of multicast makes it inefficient and | links, as its heavy use of multicast makes it inefficient and | |||
sometimes impractical in a low-power and lossy network. 6LoWPAN-ND | sometimes impractical in a low-power and lossy network. 6LoWPAN-ND | |||
describes simple optimizations to IPv6 Neighbor Discovery, its | describes simple optimizations to IPv6 Neighbor Discovery, its | |||
addressing mechanisms, and duplicate address detection for Low-power | addressing mechanisms, and duplicate address detection for Low-Power | |||
Wireless Personal Area Networks and similar networks. However, | Wireless Personal Area Networks and similar networks. However, | |||
6LoWPAN ND does not modify Neighbor Unreachability Detection (NUD) | 6LoWPAN-ND does not modify Neighbor Unreachability Detection (NUD) | |||
timeouts, which are very short (by default three transmissions spaced | timeouts, which are very short (by default three transmissions spaced | |||
one second apart). NUD timeout settings should be tuned taking into | 1 second apart). NUD timeout settings should be tuned to take into | |||
account the latency that may be introduced by duty-cycled mechanisms | account the latency that may be introduced by duty-cycled mechanisms | |||
at the link layer, or alternative, less impatient NUD algorithms | at the link layer or the alternative, less impatient NUD algorithms | |||
should be considered [I-D.ietf-6man-impatient-nud]. | should be considered [RFC7048]. | |||
IPv6 underlies the higher layer protocols, including both TCP/UDP | IPv6 underlies the higher-layer protocols, including both TCP/UDP | |||
transport and applications. By design, the higher-layer protocols do | transport and applications. By design, the higher-layer protocols do | |||
not typically have specific information about the lower layers, and | not typically have specific information about the lower layers and | |||
thus cannot solve the energy-efficiency problem. | thus cannot solve the energy-efficiency problem. | |||
The network stack can be designed to save computing power. For | The network stack can be designed to save computing power. For | |||
example the Contiki implementation has multiple cross layer | example, the Contiki implementation has multiple cross-layer | |||
optimizations for buffers and energy management, e.g., the computing | optimizations for buffers and energy management, e.g., the computing | |||
and validation of UDP/TCP checksums without the need of reading IP | and validation of UDP/TCP checksums without the need of reading IP | |||
headers from a different layer. These optimizations are software | headers from a different layer. These optimizations are software | |||
implementation techniques, and out of the scope of IETF and the LWIG | implementation techniques and are out of the scope of the IETF and | |||
working group. | the LWIG Working Group. | |||
5. Routing Protocols | 5. Routing Protocols | |||
RPL [RFC6550] is a routing protocol designed by the IETF for | RPL [RFC6550] is a routing protocol designed by the IETF for | |||
constrained environments. RPL exchanges messages periodically and | constrained environments. RPL exchanges messages periodically and | |||
keeps routing states for each destination. RPL is optimized for the | keeps routing states for each destination. RPL is optimized for the | |||
many-to-one communication pattern, where network nodes primarily send | many-to-one communication pattern (where network nodes primarily send | |||
data towards the border router, but has provisions for any-to-any | data towards the border router) but has provisions for any-to-any | |||
routing as well. | routing as well. | |||
The authors of the Powertrace tool [Powertrace] studied the power | The authors of the Powertrace tool [Powertrace] studied the power | |||
profile of RPL. Their analysis divides the routing protocol into | profile of RPL. Their analysis divides the routing protocol into | |||
control and data traffic. The control plane carries ICMP messages to | control and data traffic. The control plane carries ICMP messages to | |||
establish and maintain the routing states. The data plane carries | establish and maintain the routing states. The data plane carries | |||
any application that uses RPL for routing packets. The study has | any application that uses RPL for routing packets. The study has | |||
shown that the power consumption of the control traffic goes down | shown that the power consumption of the control traffic goes down | |||
over time in a relatively stable network. The study also reflects | over time in a relatively stable network. The study also reflects | |||
that the routing protocol should keep the control traffic as low as | that the routing protocol should keep the control traffic as low as | |||
possible to make it energy-friendly. The amount of RPL control | possible to make it energy friendly. The amount of RPL control | |||
traffic can be tuned by setting the Trickle [RFC6206] algorithm | traffic can be tuned by setting the Trickle [RFC6206] algorithm | |||
parameters (i.e. Imin, Imax and k) to appropriate values. However, | parameters (i.e., Imin, Imax, and k) to appropriate values. However, | |||
there exists a trade-off between energy consumption and other | there exists a trade-off between energy consumption and other | |||
performance parameters such as network convergence time and | performance parameters such as network convergence time and | |||
robustness. | robustness. | |||
RFC 6551 [RFC6551] defines routing metrics and constraints to be used | RFC 6551 [RFC6551] defines routing metrics and constraints to be used | |||
by RPL in route computation. Among others, RFC 6551 specifies a Node | by RPL in route computation. Among others, RFC 6551 specifies a Node | |||
Energy object that allows to provide information related to node | Energy object that allows to provide information related to node | |||
energy, such as the energy source type or the estimated percentage of | energy, such as the energy source type or the estimated percentage of | |||
remaining energy. Appropriate use of energy-based routing metrics | remaining energy. Appropriate use of energy-based routing metrics | |||
may help to balance energy consumption of network nodes, minimize | may help to balance energy consumption of network nodes, minimize | |||
network partitioning and increase network lifetime. | network partitioning, and increase network lifetime. | |||
6. Application Layer | 6. Application Layer | |||
6.1. Energy efficient features in CoAP | 6.1. Energy-Efficient Features in CoAP | |||
CoAP [RFC7252] is designed as a RESTful application protocol, | CoAP [RFC7252] is designed as a RESTful application protocol that | |||
connecting the services of smart devices to the World Wide Web. CoAP | connects the services of smart devices to the World Wide Web. CoAP | |||
is not a chatty protocol. It provides basic communication services | is not a chatty protocol. It provides basic communication services | |||
such as service discovery and GET/POST/PUT/DELETE methods with a | such as service discovery and GET/POST/PUT/DELETE methods with a | |||
binary header. | binary header. | |||
Energy efficiency is part of the CoAP protocol design. CoAP uses a | 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 | fixed-length binary header of only four bytes that may be followed by | |||
binary options. To reduce regular and frequent queries of the | binary options. To reduce regular and frequent queries of the | |||
resources, CoAP provides an observe mode, in which the requester | resources, CoAP provides an observe mode in which the requester | |||
registers its interest of a certain resource and the responder will | registers its interest of a certain resource and the responder will | |||
report the value whenever it was updated. This reduces the request | report the value whenever it was updated. This reduces the request/ | |||
response round trips while keeping information exchange a ubiquitous | response round trips while keeping information exchange an ubiquitous | |||
service; an energy-constrained server can remain in sleep mode during | service; an energy-constrained server can remain in sleep mode during | |||
the period between observe notification transmissions. | the period between observe notification transmissions. | |||
Furthermore, [RFC7252] defines CoAP proxies which can cache resource | Furthermore, [RFC7252] defines CoAP proxies that can cache resource | |||
representations previously provided by sleepy CoAP servers. The | representations previously provided by sleepy CoAP servers. The | |||
proxies themselves may respond to client requests if the | proxies themselves may respond to client requests if the | |||
corresponding server is sleeping and the resource representation is | corresponding server is sleeping and the resource representation is | |||
recent enough. Otherwise, a proxy may attempt to obtain the resource | recent enough. Otherwise, a proxy may attempt to obtain the resource | |||
from the sleepy server. | from the sleepy server. | |||
CoAP proxy and cache functionality may also be used to perform data | CoAP proxy and cache functionality may also be used to perform data | |||
aggregation. This technique allows a node to receive data messages | aggregation. This technique allows a node to receive data messages | |||
(e.g. carrying sensor readings) from other nodes in the network, | (e.g., carrying sensor readings) from other nodes in the network, | |||
perform an operation based on the content in those messages, and | perform an operation based on the content in those messages, and | |||
transmit the result of the operation. Such operation may simply be | transmit the result of the operation. Such operation may simply be | |||
intended to use one packet to carry the readings transported in | intended to use one packet to carry the readings transported in | |||
several packets (which reduces header and transmission overhead), or | several packets (which reduces header and transmission overhead), or | |||
it may be a more sophisticated operation, possibly based on | it may be a more sophisticated operation, possibly based on | |||
mathematical, logical or filtering principles (which reduces the | mathematical, logical, or filtering principles (which reduces the | |||
payload size to be transmitted). | payload size to be transmitted). | |||
6.2. Sleepy node support | 6.2. Sleepy Node Support | |||
Beyond these features of CoAP, there have been a number of proposals | Beyond these features of CoAP, there have been a number of proposals | |||
to further support sleepy nodes at the application layer by | to further support sleepy nodes at the application layer by | |||
leveraging CoAP mechanisms. A good summary of such proposals can be | leveraging CoAP mechanisms. A good summary of such proposals can be | |||
found in [I-D.rahman-core-sleepy-nodes-do-we-need], while an example | found in [SLEEPY-DEVICES], while an example application (in the | |||
application (in the context of illustrating several security | context of illustrating several security mechanisms) in a scenario | |||
mechanisms) in a scenario with sleepy devices has been described | with sleepy devices has been described [CRYPTO-SENSORS]. Approaches | |||
[I-D.ietf-lwig-crypto-sensors]. Approaches to support sleepy nodes | to support sleepy nodes include exploiting the use of proxies, | |||
include exploiting the use of proxies, leveraging the Resource | leveraging the resource directory [CoRE-RD], or signaling when a node | |||
Directory [I-D.ietf-core-resource-directory] or signaling when a node | ||||
is awake to the interested nodes. Recent work defines publish- | is awake to the interested nodes. Recent work defines publish- | |||
subscribe and message queuing extensions to CoAP and the Resource | subscribe and message queuing extensions to CoAP and the resource | |||
Directory in order to support devices that spend most of their time | directory in order to support devices that spend most of their time | |||
in asleep [I-D.ietf-core-coap-pubsub]. Notably, this work has been | asleep [CoAP-BROKER]. Notably, this work has been adopted by the | |||
adopted by the CoRE Working Group. | CoRE Working Group. | |||
In addition to the work within the scope of CoAP to support sleepy | In addition to the work within the scope of CoAP to support sleepy | |||
nodes, other specifications define application layer functionality | nodes, other specifications define application-layer functionality | |||
for the same purpose. The Lightweight Machine-to-Machine (LWM2M) | for the same purpose. The Lightweight Machine-to-Machine (LwM2M) | |||
specification from the Open Mobile Alliance (OMA) defines a Queue | specification from the Open Mobile Alliance (OMA) defines a queue | |||
Mode whereby an LWM2M Server queues requests to an LWM2M Client until | mode whereby an LwM2M Server queues requests to an LwM2M Client until | |||
the latter (which may often stay in sleep mode) is online. LWM2M | the latter (which may often stay in sleep mode) is online. LwM2M | |||
functionality operates on top of CoAP. | functionality operates on top of CoAP. | |||
oneM2M defines a CoAP binding with an application layer mechanism for | oneM2M defines a CoAP binding with an application-layer mechanism for | |||
sleepy nodes [oneM2M]. | sleepy nodes [oneM2M]. | |||
6.3. CoAP timers | 6.3. CoAP Timers | |||
CoAP offers mechanisms for reliable communication between two CoAP | CoAP offers mechanisms for reliable communication between two CoAP | |||
endpoints. A CoAP message may be signaled as a confirmable (CON) | endpoints. A CoAP message may be signaled as a confirmable (CON) | |||
message, and an acknowledgment (ACK) is issued by the receiver if the | message, and an acknowledgment (ACK) is issued by the receiver if the | |||
CON message is correctly received. The sender starts a | CON message is correctly received. The sender starts a | |||
Retransmission TimeOut (RTO) for every CON message sent. The initial | Retransmission Timeout (RTO) for every CON message sent. The initial | |||
RTO value is chosen randomly between 2 and 3 s. If an RTO expires, | 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 | the new RTO value is doubled (unless a limit on the number of | |||
retransmissions has been reached). Since duty-cycling at the link | retransmissions has been reached). Since duty cycling at the link | |||
layer may lead to long latency (i.e. even greater than the initial | layer may lead to long latency (i.e., even greater than the initial | |||
RTO value), CoAP RTO parameters should be tuned accordingly in order | RTO value), CoAP RTO parameters should be tuned accordingly in order | |||
to avoid spurious RTOs which would unnecessarily waste node energy | to avoid spurious RTOs that would unnecessarily waste node energy and | |||
and other resources. On the other hand, note that CoAP can also run | other resources. On the other hand, note that CoAP can also run on | |||
on top of TCP [I-D.ietf-core-coap-tcp-tls]. In that case, similar | top of TCP [RFC8323]. In that case, similar guidance applies to TCP | |||
guidance applies to TCP timers, albeit with greater motivation to | timers, albeit with greater motivation to carefully configure TCP RTO | |||
carefully configure TCP RTO parameters, since [RFC6298] reduced the | parameters since [RFC6298] reduced the default initial TCP RTO to 1 | |||
default initial TCP RTO to 1 second, which may interact more | second, which may interact more negatively with duty-cycled links | |||
negatively with duty-cycled links than default CoAP RTO values. | than default CoAP RTO values. | |||
6.4. Data compression | 6.4. Data Compression | |||
Another method intended to reduce the size of the data units to be | Another method intended to reduce the size of the data units to be | |||
communicated in constrained-node networks is data compression, which | communicated in constrained-node networks is data compression, which | |||
allows to encode data using less bits than the original data | allows to encode data using fewer bits than the original data | |||
representation. Data compression is more efficient at higher layers, | representation. Data compression is more efficient at higher layers, | |||
particularly before encryption is used. In fact, encryption | particularly before encryption is used. In fact, encryption | |||
mechanisms may generate an output that does not contain redundancy, | mechanisms may generate an output that does not contain redundancy, | |||
making it almost impossible to reduce the data representation size. | making it almost impossible to reduce the data representation size. | |||
In CoAP, messages may be encrypted by using DTLS (or TLS when CoAP | In CoAP, messages may be encrypted by using Datagram Transport Layer | |||
over TCP is used), which is the default mechanism for securing CoAP | Security (DTLS) or TLS when CoAP over TCP is used, which is the | |||
exchanges. | default mechanism for securing CoAP exchanges. | |||
7. Summary and Conclusions | 7. Summary and Conclusions | |||
We summarize the key takeaways in this document: | We summarize the key takeaways of this document: | |||
a. Internet protocols designed by IETF can be considered as the | a. Internet protocols designed by the IETF can be considered the | |||
customer of the lower layers (PHY, MAC, and Duty-cycling). To | customer of the lower layers (PHY, MAC, and duty cycling). To | |||
reduce power consumption, it is recommended that Layer 3 designs | reduce power consumption, it is recommended that Layer 3 designs | |||
should operate based on awareness of lower-level parameters | should operate based on awareness of lower-level parameters | |||
rather than treating the lower layer as a black box (Sections 4, | rather than treating the lower layer as a black box (see Sections | |||
5 and 6). | 4, 5, and 6). | |||
b. It is always useful to compress the protocol headers in order to | b. It is always useful to compress the protocol headers in order to | |||
reduce the transmission/reception power. This design principle | reduce the transmission/reception power. This design principle | |||
has been employed by many protocols in 6Lo and CoRE working group | has been employed by many protocols in the 6lo and CoRE Working | |||
(Sections 4 and 6). | Groups (see Sections 4 and 6). | |||
c. Broadcast and non-synchronized transmissions consume more than | c. Broadcast and non-synchronized transmissions consume more than | |||
other TX/RX operations. If protocols must use these ways to | other TX/RX operations. If protocols must use these ways to | |||
collect information, reduction of their usage by aggregating | collect information, reduction of their usage by aggregating | |||
similar messages together will be helpful in saving power | similar messages together will be helpful in saving power (see | |||
(Sections 2 and 6.1). | Sections 2 and 6.1). | |||
d. Saving power by sleeping as much as possible is used widely | d. Saving power by sleeping as much as possible is used widely | |||
(Section 3). | (Section 3). | |||
8. Contributors | 8. IANA Considerations | |||
Jens T. Petersen, RTX, contributed the section on power save | ||||
services in DECT ULE. | ||||
9. Acknowledgments | ||||
Carles Gomez has been supported by the Spanish Government, FEDER and | ||||
the ERDF through projects TEC2012-32531 and TEC2016-79988-P. | ||||
Authors would like to thank 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. | ||||
The text of this document was improved based on IESG Document Editing | ||||
session during IETF87. Thanks to Ted Lemon and Joel Jaeglli for | ||||
initiating and facilitating this editing session. | ||||
10. IANA Considerations | ||||
This document has no IANA requests. | This document has no IANA actions. | |||
11. Security Considerations | 9. Security Considerations | |||
This document discusses the energy efficient protocol design, and | This document discusses energy-efficient protocol design and does not | |||
does not incur any changes or challenges on security issues besides | incur any changes or challenges on security issues besides what the | |||
what the protocol specifications have analyzed. | protocol specifications have analyzed. | |||
12. References | 10. References | |||
12.1. Normative References | 10.1. Normative References | |||
[Bluetooth42] | [Bluetooth42] | |||
Bluetooth Special Interest Group, "Bluetooth Core | Bluetooth Special Interest Group, "Core Version 4.2", | |||
Specification Version 4.2", December 2014, | available from "Legacy Core Specifications", December | |||
<https://www.bluetooth.org/en-us/specification/ | 2014, <https://www.bluetooth.com/specifications/ | |||
adopted-specifications>. | bluetooth-core-specification/legacy-specifications>. | |||
[EN300] ETSI, "Digital Enhanced Cordless Telecommunications | [EN300] ETSI, "Digital Enhanced Cordless Telecommunications | |||
(DECT); Common Interface (CI)", March 2015, | (DECT); Common Interface (CI); Part 1: Overview", ETSI EN | |||
300 175-1 V2.6.1, July 2015, | ||||
<https://www.etsi.org/deliver/ | <https://www.etsi.org/deliver/ | |||
etsi_en/300100_300199/30017501/02.06.01_60/ | etsi_en/300100_300199/30017501/02.06.01_60/ | |||
en_30017501v020601p.pdf>. | en_30017501v020601p.pdf>. | |||
[fifteendotfour] | [G9959] ITU-T, "Short range narrow-band digital radiocommunication | |||
IEEE Computer Society, "IEEE Std. 802.15.4-2015 IEEE | transceivers - PHY, MAC, SAR and LLC layer | |||
Standard for Local and metropolitan area networks--Part | specifications", ITU-T Recommendation G.9959, January | |||
15.4: Low-Rate Wireless Personal Area Networks (LR- | 2015, <http://www.itu.int/rec/T-REC-G.9959>. | |||
WPANs)", 2015, <https://standards.ieee.org/findstds/ | ||||
standard/802.15.4-2015.html>. | ||||
[G9959] International Telecommunication Union, "Short range | [IEEE802.11] | |||
narrow-band digital radiocommunication transceivers - PHY | IEEE, "IEEE Standard for Information technology-- | |||
and MAC layer specifications, ITU-T Recommendation | Telecommunications and information exchange between | |||
G.9959", January 2015, | systems Local and metropolitan area networks--Specific | |||
<http://www.itu.int/rec/T-REC-G.9959>. | 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>. | ||||
[IEEE80211v] | [IEEE802.15.4] | |||
IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) | IEEE, "IEEE Standard for Low-Rate Wireless Networks", | |||
and Physical Layer (PHY) specifications, Amendment 8: IEEE | IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, | |||
802.11 Wireless Network Management.", February 2012. | <https://standards.ieee.org/findstds/ | |||
standard/802.15.4-2015.html>. | ||||
[MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication | [MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication | |||
Protocol for Building Automation and Control Networks, | Protocol for Building Automation and Control Networks | |||
ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to | ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to | |||
ANSI/ASHRAE Standard 135-2012", July 2014, | ANSI/ASHRAE Standard 135-2012", July 2014, | |||
<https://www.ashrae.org/File%20Library/docLib/StdsAddenda/ | <https://www.ashrae.org/technical-resources/standards-and- | |||
07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>. | guidelines/standards-addenda/ | |||
addenda-to-standard-135-2012>. | ||||
[NFC] NFC Forum, "NFC Logical Link Control Protocol version 1.3, | [NFC] NFC Forum, "NFC Logical Link Control Protocol", Technical | |||
NFC Forum Technical Specification", March 2016. | Specification, Version 1.3, March 2016. | |||
[oneM2M] oneM2M, "oneM2M specifications", | [oneM2M] oneM2M, "oneM2M - Published Specifications", | |||
<http://www.onem2m.org/technical/published-documents>. | <http://www.onem2m.org/technical/published-documents>. | |||
[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>. | ||||
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
"Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
<https://www.rfc-editor.org/info/rfc4944>. | <https://www.rfc-editor.org/info/rfc4944>. | |||
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, | |||
"The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, | "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, | |||
March 2011, <https://www.rfc-editor.org/info/rfc6206>. | March 2011, <https://www.rfc-editor.org/info/rfc6206>. | |||
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 | |||
skipping to change at page 21, line 26 ¶ | skipping to change at page 21, line 32 ¶ | |||
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained | |||
Application Protocol (CoAP)", RFC 7252, | Application Protocol (CoAP)", RFC 7252, | |||
DOI 10.17487/RFC7252, June 2014, | DOI 10.17487/RFC7252, June 2014, | |||
<https://www.rfc-editor.org/info/rfc7252>. | <https://www.rfc-editor.org/info/rfc7252>. | |||
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., | [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., | |||
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low | Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low | |||
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, | Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, | |||
<https://www.rfc-editor.org/info/rfc7668>. | <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>. | ||||
[TS102] ETSI, "Digital Enhanced Cordless Telecommunications | [TS102] ETSI, "Digital Enhanced Cordless Telecommunications | |||
(DECT); Ultra Low Energy (ULE); Machine to Machine | (DECT); Ultra Low Energy (ULE); Machine to Machine | |||
Communications; Part 2: Home Automation Network (phase 2", | Communications; Part 2: Home Automation Network (phase 2", | |||
March 2015, <https://www.etsi.org/deliver/ | ETSI TS 102 939-2 V1.1.1, March 2015, | |||
<https://www.etsi.org/deliver/ | ||||
etsi_ts/102900_102999/10293902/01.01.01_60/ | etsi_ts/102900_102999/10293902/01.01.01_60/ | |||
ts_10293902v010101p.pdf>. | ts_10293902v010101p.pdf>. | |||
12.2. Informative References | 10.2. Informative References | |||
[AN079] Kim, C., "Measuring Power Consumption of CC2530 With | [AN079] Kim, C., "Measuring Power Consumption of CC2530 With | |||
Z-Stack", September 2012, | Z-Stack", Application Note AN079, SWRA292, September 2012, | |||
<http://www.ti.com/lit/an/swra292/swra292.pdf>. | <http://www.ti.com/lit/an/swra292/swra292.pdf>. | |||
[ContikiMAC] | [ARCH-6TiSCH] | |||
Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, | ||||
SICS Technical Report T2011:13", December 2011, | ||||
<https://www.mysciencework.com/publication/download/2f406d | ||||
3c4cc1eda32a234f7a1ad2cc3b/7eb199e4f8b00857e21af2b7d2b31c0 | ||||
d>. | ||||
[I-D.bormann-lwig-7228bis] | ||||
Bormann, C., Ersue, M., Keranen, A., and C. Gomez, | ||||
"Terminology for Constrained-Node Networks", draft- | ||||
bormann-lwig-7228bis-01 (work in progress), May 2017. | ||||
[I-D.ietf-6lo-dect-ule] | ||||
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. | ||||
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low | ||||
Energy", draft-ietf-6lo-dect-ule-09 (work in progress), | ||||
December 2016. | ||||
[I-D.ietf-6man-impatient-nud] | ||||
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability | ||||
Detection is too impatient", draft-ietf-6man-impatient- | ||||
nud-07 (work in progress), October 2013. | ||||
[I-D.ietf-6tisch-architecture] | ||||
Thubert, P., "An Architecture for IPv6 over the TSCH mode | Thubert, P., "An Architecture for IPv6 over the TSCH mode | |||
of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work | of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch- | |||
in progress), August 2017. | architecture-13, November 2017. | |||
[I-D.ietf-6tisch-minimal] | [CLASS1-CoAP] | |||
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal | Kovatsch, M., "Implementing CoAP for Class 1 Devices", | |||
6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work | Work in Progress, draft-kovatsch-lwig-class1-coap-00, | |||
in progress), February 2017. | October 2012. | |||
[I-D.ietf-core-coap-pubsub] | [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. | ||||
[CoAP-BROKER] | ||||
Koster, M., Keranen, A., and J. Jimenez, "Publish- | Koster, M., Keranen, A., and J. Jimenez, "Publish- | |||
Subscribe Broker for the Constrained Application Protocol | Subscribe Broker for the Constrained Application Protocol | |||
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in | (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, | |||
progress), July 2017. | March 2018. | |||
[I-D.ietf-core-coap-tcp-tls] | [ContikiMAC] | |||
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., | Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", | |||
Silverajan, B., and B. Raymor, "CoAP (Constrained | SICS Technical Report T2011:13, December 2011, | |||
Application Protocol) over TCP, TLS, and WebSockets", | <http://soda.swedishict.se/5128/>. | |||
draft-ietf-core-coap-tcp-tls-09 (work in progress), May | ||||
2017. | ||||
[I-D.ietf-core-resource-directory] | [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. | |||
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. | Amsuess, Ed., "CoRE Resource Directory", Work in | |||
Amsuess, "CoRE Resource Directory", draft-ietf-core- | Progress, draft-ietf-core-resource-directory-13, March | |||
resource-directory-11 (work in progress), July 2017. | 2018. | |||
[I-D.ietf-lwig-crypto-sensors] | [CRYPTO-SENSORS] | |||
Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical | Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical | |||
Considerations and Implementation Experiences in Securing | Considerations and Implementation Experiences in Securing | |||
Smart Object Networks", draft-ietf-lwig-crypto-sensors-04 | Smart Object Networks", Work in Progress, draft-ietf-lwig- | |||
(work in progress), August 2017. | crypto-sensors-06, February 2018. | |||
[I-D.kovatsch-lwig-class1-coap] | [Powertrace] | |||
Kovatsch, M., "Implementing CoAP for Class 1 Devices", | Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes, | |||
draft-kovatsch-lwig-class1-coap-00 (work in progress), | "Powertrace: Network-level Power Profiling for Low-power | |||
October 2012. | Wireless Networks", SICS Technical Report T2011:05, March | |||
2011, <http://soda.swedishict.se/4112/>. | ||||
[I-D.rahman-core-sleepy-nodes-do-we-need] | [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>. | ||||
[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>. | ||||
[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>. | ||||
[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>. | ||||
[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>. | ||||
[SLEEPY-DEVICES] | ||||
Rahman, A., "Sleepy Devices: Do we need to Support them in | Rahman, A., "Sleepy Devices: Do we need to Support them in | |||
CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work | CORE?", Work in Progress, draft-rahman-core-sleepy-nodes- | |||
in progress), February 2014. | do-we-need-01, February 2014. | |||
[Powertrace] | Acknowledgments | |||
Dunkels, Eriksson, Finne, and Tsiftes, "Powertrace: | ||||
Network-level Power Profiling for Low-power Wireless | Carles Gomez has been supported by the Spanish Government, FEDER, and | |||
Networks", March 2011, <https://core.ac.uk/download/ | the ERDF through projects TEC2012-32531 and TEC2016-79988-P. | |||
pdf/11435067.pdf?repositoryId=362>. | ||||
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. | ||||
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. | ||||
Contributors | ||||
Jens T. Petersen, RTX, contributed the section on power save services | ||||
in DECT ULE. | ||||
Authors' Addresses | Authors' Addresses | |||
Carles Gomez | Carles Gomez | |||
Universitat Politecnica de Catalunya | Universitat Politecnica de Catalunya | |||
C/Esteve Terradas, 7 | C/Esteve Terradas, 7 | |||
Castelldefels 08860 | Castelldefels 08860 | |||
Spain | Spain | |||
Email: carlesgo@entel.upc.edu | Email: carlesgo@entel.upc.edu | |||
Matthias Kovatsch | Matthias Kovatsch | |||
ETH Zurich | ETH Zurich | |||
Universitaetstrasse 6 | Universitaetstrasse 6 | |||
Zurich, CH-8092 | Zurich, CH-8092 | |||
Switzerland | Switzerland | |||
Email: kovatsch@inf.ethz.ch | Email: ietf@kovatsch.net | |||
Hui Tian | Hui Tian | |||
China Academy of Telecommunication Research | China Academy of Telecommunication Research | |||
Huayuanbeilu No.52 | Huayuanbeilu No. 52 | |||
Beijing, Haidian District 100191 | Beijing, Haidian District 100191 | |||
China | China | |||
Email: tianhui@ritt.cn | Email: tianhui@ritt.cn | |||
Zhen Cao (editor) | Zhen Cao (editor) | |||
Huawei Technologies | Huawei Technologies | |||
China | China | |||
Email: zhencao.ietf@gmail.com | Email: zhencao.ietf@gmail.com | |||
End of changes. 173 change blocks. | ||||
534 lines changed or deleted | 556 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |