draft-ietf-lwig-energy-efficient-07.txt   draft-ietf-lwig-energy-efficient-08.txt 
Internet Engineering Task Force C. Gomez Internet Engineering Task Force C. Gomez
Internet-Draft Universitat Politecnica de Catalunya Internet-Draft Universitat Politecnica de Catalunya
Intended status: Informational M. Kovatsch Intended status: Informational M. Kovatsch
Expires: September 6, 2017 ETH Zurich Expires: April 24, 2018 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
March 5, 2017 October 21, 2017
Energy-Efficient Features of Internet of Things Protocols Energy-Efficient Features of Internet of Things Protocols
draft-ietf-lwig-energy-efficient-07 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
networks. networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2017. This Internet-Draft will expire on April 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Medium Access Control and Radio Duty Cycling . . . . . . . . 5
3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5
3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6
3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7
3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 8
3.5. Power save services available in example low-power radios 8 3.5. Packet bundling . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 3.6. Power save services available in example low-power radios 8
3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 3.6.1. Power Save Services Provided by IEEE 802.11 . . . . . 8
3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 3.6.2. Power Save Services Provided by Bluetooth LE . . . . 9
3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 3.6.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 3.6.4. Power Save Services in DECT ULE . . . . . . . . . . . 12
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 14
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 16
6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 16
6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 16
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 17
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4. Data compression . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Network systems for physical world monitoring contain many battery- Network systems for physical world monitoring contain many battery-
powered or energy-harvesting devices. For example, in an 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 are no 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. consumption of the constrained devices. In this document we describe
techniques that are in common use at Layer 2 and at Layer 3, and we
indicate the need for higher-layer awareness of lower-layer features.
A large body of research efforts have been put on this "energy Many research efforts have studied this "energy efficiency" problem.
efficiency" problem. Most of this research has focused on how to Most of this research has focused on how to optimize the system's
optimize the system's power consumption regarding a certain power consumption in certain deployment scenarios, or how an existing
deployment scenario or how could an existing network function such as network function such as routing or security could be more energy-
routing or security be more energy-efficient. Only few efforts efficient. Only few efforts have focused on energy-efficient designs
focused on energy-efficient designs for IETF protocols and for IETF protocols and standardized network stacks for such
standardized network stacks for such constrained devices constrained devices [I-D.kovatsch-lwig-class1-coap].
[I-D.kovatsch-lwig-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. layers. Cross-layer interaction is therefore considered in this
document from this specific point of view. Providing further design
After reviewing the energy-efficient design of each layer, an overall recommendations that go beyond the layered protocol architecture is
conclusion is summarized. Though the lower layer communication out of the scope of this document.
optimization is the key part of energy efficient design, the protocol
design at the upper layers is also important to make the device
energy-efficient.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", After reviewing the energy-efficient designs of each layer, we
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this summarize the document by presenting some overall conclusions.
document are to be interpreted as described in [RFC2119] Though the lower layer communication optimization is the key part of
energy efficient design, the protocol design at the upper layers is
also important to make the device energy-efficient.
1.2. Terminology 1.1. Terminology
The terminologies used in this document can be referred to [RFC7228] Terms used in this document are defined in [RFC7228]
[I-D.bormann-lwig-7228bis]. [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 witnessed 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 light-weight Internet protocol stack. As shown
in Figure 1 below, the IETF has developed CoAP as the application in Figure 1 below, the IETF has developed CoAP as the application
layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE
802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL
and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently
being adapted by the 6lo working group to support IPv6 over various being adapted by the 6lo working group to support IPv6 over various
other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and other technologies, such as ITU-T G.9959 [G9959], DECT ULE [TS102],
NFC. MS/TP-BACnet [MSTP], and Near Field Communication (NFC) [NFC].
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
|HTTP | | FTP | |SNMP | | CoAP | |HTTP | | FTP | |SNMP | | CoAP |
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
\ / / / \ \ / / / \
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| TCP | | UDP | | TCP | | UDP | | TCP | | UDP | | TCP | | UDP |
+-----+ +-----+ ===> +-----+ +-----+ +-----+ +-----+ ===> +-----+ +-----+
\ / \ / \ / \ /
+-----+ +------+ +-------+ +------+ +-----+ +-----+ +------+ +-------+ +------+ +-----+
| RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL | | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RTG |
+-----+ +------+ +-------+ +------+ +-----+ +-----+ +------+ +-------+ +------+ +-----+
| | | |
+-------+ +-------+ +----------+ +-------+ +-------+ +----------+
|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 Light-weight 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 and Ultra WideBand (UWB)
links, transmitting may actually be even cheaper than receiving. It links, transmitting may actually be even cheaper than receiving. It
also shows that broadcast and non-synchronized communication also shows that broadcast and non-synchronized communication
transmissions are energy costly because they need to acquire the transmissions are energy costly because they need to acquire the
medium for a long time. medium for a long time.
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Activity | Energy (uJ) | | Activity | Energy (uJ) |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
skipping to change at page 5, line 22 skipping to change at page 5, line 20
| 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 |
+---------------------------------------+---------------+
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
3. MAC and Radio Duty Cycling At the Physical layer, one approach that may allow reducing energy
consumption of a device that uses a wireless interface is based on
reducing the device transmit power level as long as the intended next
hop(s) are still within range of the device. In some cases, if node
A has to transmit a message to node B, a solution to reduce node A
transmit power is to leverage an intermediate device, e.g. node C as
a message forwarder. Let d be the distance between node A and node
B. Assuming free-space propagation, where path loss is proportional
to d^2, if node C is placed right in the middle of the path between A
and B (that is, at a distance d/2 from both node A and node B), the
minimum transmit power to be used by node A (and by node C) is
reduced by a factor of 4. However, this solution requires additional
devices, it requires a routing solution, and it also increases
transmission delay between A and B.
In low-power wireless networks, communication and power consumption 3. Medium Access Control and Radio Duty Cycling
are intertwined. The communication device is typically the most
power-consuming component, but merely refraining from transmissions
is not enough to attain a low power consumption: the radio may
consume as much power in listen mode as when actively transmitting.
This augments the key problem known as idle listening, whereby the
radio of a device may be in receive mode (ready to receive any
message), even if no message is being transmitted to that device.
Idle listening consumes a huge amount of energy unnecessarily. To
reduce power consumption, the radio must be switched completely off
-- duty-cycled -- as much as possible. By applying duty-cycling, the
lifetime of a device operating on a common button battery may be in
the order of years, whereas otherwise the battery may be exhausted in
a few days or even hours. Duty-cycling is a technique generally
employed by devices that use the P1 strategy [RFC7228], which need to
be able to communicate on a relatively frequent basis. Note that a
more aggressive approach to save energy relies on the P0, Normally-
off strategy, whereby devices sleep for very long periods and
communicate infrequently, even though they spend energy in network
reattachment procedures.
From the perspective of MAC&RDC, all upper layer protocols, such as In networks, communication and power consumption are interdependent.
routing, RESTful communication, adaptation, and management flows, are The communication device is typically the most power-consuming
all applications. Since the duty cycling algorithm is the key to component, but merely refraining from transmissions is not enough to
energy-efficiency of the wireless medium, it synchronizes the achieve a low power consumption: the radio may consume as much power
transmission and/or reception request from the higher layer. in listen mode as when actively transmitting. This illustrates the
key problem known as idle listening, whereby the radio of a device
may be in receive mode (ready to receive any message), even if no
message is being transmitted to that device. Idle listening can
consume a huge amount of energy unnecessarily. To reduce power
consumption, the radio must be switched completely off -- duty-cycled
-- as much as possible. By applying duty-cycling, the lifetime of a
device operating on a common button battery may be on the order of
years, whereas otherwise the battery may be exhausted in a few days
or even hours. Duty-cycling is a technique generally employed by
devices that use the P1 strategy [RFC7228], which need to be able to
communicate on a relatively frequent basis. Note that a more
aggressive approach to save energy relies on the P0, Normally-off
strategy, whereby devices sleep for very long periods and communicate
infrequently, even though they spend energy in network reattachment
procedures.
The MAC&RDC are not in the scope of the IETF, yet lower layer From the perspective of Medium Access Control (MAC) and Radio Duty
designers and chipset manufactures take great care of the problem. Cycling (RDC), all upper layer protocols, such as routing, RESTful
For the IETF protocol designers, however, it is good to know the communication, adaptation, and management flows, are applications.
behaviors of lower layers so that the designed protocols can work Since the duty cycling algorithm is the key to energy-efficiency of
perfectly with them. the wireless medium, it synchronizes transmission and/or reception
requests from the higher layers.
Once again, the IETF protocols we are going to talk about in the MAC and RDC are not in the scope of the IETF, yet lower layer
following sections are the customers of the lower layers. If the designers and chipset manufacturers take great care to save energy.
different protocol layers want to get better service in a cooperative By knowing the behaviors of these lower layers, IETF engineers can
way, they should be considerate and understand each other. design protocols that work well with them. The IETF protocols to be
discussed in the following sections are the customers of the lower
layers.
3.1. Radio Duty Cycling techniques 3.1. Radio Duty Cycling techniques
This subsection describes the main three RDC techniques. Note that This subsection describes three main three RDC techniques. Note that
more than one of the presented techniques may be available or can more than one of these techniques may be available or can even be
even be combined in a specific radio technology: combined 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 can
correctly receive a transmitted data unit, the sender may prepend a correctly receive a transmitted data unit, the sender may prepend a
preamble of a duration at least the sampling period to the data unit preamble of a duration at least the sampling period to the data unit
to be sent. Another option for the sender is to repeatedly transmit to be sent. Another option for the sender is to repeatedly transmit
the data unit, instead of sending a preamble before the data unit. the data unit, instead of sending a preamble before the data unit.
Once a transmission is detected by a receiver, the receiver may stay Once a transmission is detected by a receiver, the receiver may stay
awake until the complete reception of the data unit. Examples of awake until the complete reception of the data unit. Examples of
radio technologies that use preamble sampling include ContikiMAC, the radio technologies that use preamble sampling include ContikiMAC, the
Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the
Frequently Listening (FL) mode of ITU-T G.9959. 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 instants in which it should be awake (during some time interval) the particular time at which it should be awake (during some time
in order to receive data units. Otherwise, the device may remain in interval) in order to receive data. Otherwise, the device may remain
sleep mode. The decision on the instants that will be used for in sleep mode. The decision on the times at which communication is
communication is reached by means of some form of negotation between attempted relies on some form of negotation between the involved
the involved devices. Such negotiation may be performed per devices. Such negotiation may be performed per transmission or per
transmission or per session/connection. Bluetooth Low Energy session/connection. Bluetooth Low Energy (Bluetooth LE) is an
(Bluetooth LE) is an example of a radio technology based on this example of a radio technology based on this mechanism.
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, wake up and poll a sender (which must be ready
to receive a poll message) for pending transmissions. After sending to receive a poll message) for pending transmissions. After sending
the poll message, the node remains in receive mode, ready for a the poll message, the node remains in receive mode, ready for a
potential incoming transmission. After a certain time interval, the potential incoming transmission. After a certain time interval, the
node may go back to sleep. For example, the Receiver Initiated node may go back to sleep. For example, the Receiver Initiated
Transmission (RIT) mode of 802.15.4e, and the transmission of data Transmission (RIT) mode of 802.15.4e, and the transmission of data
between a coordinator and a device in IEEE 802.15.4-2003 use this between a coordinator and a device in IEEE 802.15.4-2003 use this
technique. technique.
skipping to change at page 7, line 24 skipping to change at page 7, line 34
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-cycling follows a periodical behavior). duty-cycling follows a periodical behavior).
On the other hand, due to the latency increase of duty-cycling, a On the other hand, due to the latency increase of duty-cycling, a
sender waiting for a transmission opportunity may need to store sender waiting for a transmission opportunity may need to store
subsequent outgoing packets in a buffer, increasing memory subsequent outgoing packets in a buffer, increasing memory
requirements and potentially incurring queuing waiting time that requirements and potentially incurring queuing waiting time that
contributes to the packet overall delay and increases the probability contributes to the packet's overall delay and increases the
of buffer overflow, leading to losses. 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
this kind of networks, such as over-the-air software updates or when such networks, such as over-the-air software updates or when off-line
off-line sensors accumulate measurements that have to be quickly sensors accumulate measurements that have to be quickly transferred
transferred when there is a connectivity opportunity. 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 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. Power save services available in example low-power radios 3.5. Packet bundling
Another technique that may be useful to increase communication energy
efficiency is packet bundling. This technique, which is available in
several radio interfaces (e.g. LTE and some 802.11 variants), allows
to aggregate several small packets into a single large packet.
Header and communication overhead is therefore reduced.
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 Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each
technology, the reader may refer to the literature or to the technology, the reader may refer to the literature or to the
corresponding specifications. corresponding specifications.
3.5.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 defines the Power Save Mode (PSM) whereby a station may
indicate to an Access Point (AP) that it will enter a sleep mode indicate to an Access Point (AP) that it will enter a sleep mode
state. While the station is sleeping, the AP buffers any frames that state. While the station is sleeping, the AP buffers any frames that
should be sent to the sleeping station. The station wakes up every should be sent to the sleeping station. The station wakes up every
Listen Interval (which can be a multiple of the Beacon Interval) in Listen Interval (which can be a multiple of the Beacon Interval) in
order to receive beacons. The AP signals in the beacon whether there order to receive beacons. The AP signals in the beacon whether there
is data pending for the station or not. If there are not frames to is data pending for the station or not. If there are not frames to
be sent to the station, the latter may get back to sleep mode. be sent to the station, the latter may get back to sleep mode.
Otherwise, the station may send a message requesting the transmission Otherwise, the station may send a message requesting the transmission
of the buffered data and stay awake in receive mode. of the buffered data and stay awake in receive mode.
IEEE 802.11v [IEEE80211v] further defines mechanisms and services for IEEE 802.11v [IEEE80211v] further defines mechanisms and services for
power save of stations/nodes that include flexible multicast service power save of stations/nodes that include flexible multicast service
(FMS), proxy ARP advertisement, extended sleep modes, traffic (FMS), proxy ARP advertisement, extended sleep modes, and traffic
filtering. It would be useful if upper layer protocols knows such filtering. Upper layer protocols knowledge of such capabilities
capabilities provided by the lower layer, so that they can coordinate provided by the lower layer enables better interworking.
with each other.
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 frames.
The Proxy ARP capability enables the non-AP STA to remain in power- The Proxy ARP capability enables the non-AP STA to remain in power-
save for longer periods of time. save 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) station (STA) can FMS: A service in which a non-access point (non-AP) STA can request a
request a multicast delivery interval longer than the delivery multicast delivery interval longer than the delivery traffic
traffic indication message (DTIM) interval for the purposes of indication message (DTIM) interval for the purposes of lengthening
lengthening the period of time a STA may be in a power save state. the period 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 access
point (AP) to a non-AP station (STA) that can reduce the number of point (AP) to a non-AP STA that can reduce the number of frames sent
frames sent to the non-AP STA by not forwarding individually to the STA by dropping individually addressed frames that do not
addressed frames addressed to the non-AP STA that do not match match traffic filters specified by the STA.
traffic filters specified by the non-AP 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 Idel Period and FMS).
Upper layer protocols would better synchronize with the parameters Upper layer protocols should synchronize with the parameters such as
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.5.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]. BT-LE has been designed for the goal
of ultra-low-power consumption. Currently, it is possible to run of ultra-low-power consumption. IPv6 can be run IPv6 over Bluetooth
IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668].
BT-LE [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 which 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
skipping to change at page 9, line 44 skipping to change at page 10, line 12
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 since 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 nature. 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 which 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
connSupervisionTimeout=32 seconds. With these settings,
communication opportunities between a master and a slave will occur
during a given interval every 32 seconds. Duration of the interval
will depend on several factors, including number of connected slaves,
amount of data to be transmitted, etc. In the worst case, only one
data unit can be sent from master to slave and vice versa every 32
seconds.
3.5.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 is a family of standard radio interfaces for low-rate,
low-power wireless networking [fifteendotfour]. Since the low-power wireless networking [fifteendotfour]. Since the
publication of its first version in 2003, IEEE 802.15.4 has become publication of its first version in 2003, IEEE 802.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 various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775],
[RFC6282],[RFC6775],[RFC4944] and 6TiSCH [RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4
[I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC specifies a variety of related PHY and MAC layer functionalites.
layer functionality.
IEEE 802.15.4 defines three roles called device, coordinator and IEEE 802.15.4 defines three roles called device, coordinator and
Personal Area Network (PAN) coordinator. The device role is adequate Personal Area Network (PAN) coordinator. The device role is adequate
for nodes that do not implement the complete IEEE 802.15.4 for nodes that do not implement the complete IEEE 802.15.4
functionality, and is mainly targeted for constrained nodes with a functionality, and is mainly targeted for constrained nodes with a
limited energy source. The coordinator role includes synchronization limited energy source. The coordinator role includes synchronization
capabilities and is suitable for nodes that do not suffer severe capabilities and is suitable for nodes that do not suffer severe
constraints (e.g. a mains-powered node). The PAN coordinator is a constraints (e.g. a mains-powered node). The PAN coordinator is a
special type of coordinator that acts as a principal controller in an special type of coordinator that acts as a principal controller in an
IEEE 802.15.4 network. IEEE 802.15.4 network.
IEEE 802.15.4 has mainly defined two types of networks depending on IEEE 802.15.4 defines two main types of networks depending on their
their configuration: beacon-enabled and nonbeacon-enabled networks. configuration: beacon-enabled and nonbeacon-enabled networks. In the
In the first network type, coordinators periodically transmit first network type, coordinators periodically transmit beacons. The
beacons. The time between beacons is divided in three main parts: time between beacons is divided in three main parts: the Contention
the Contention Access Period (CAP), the Contention Free Period (CFP) Access Period (CAP), the Contention Free Period (CFP) and an inactive
and an inactive period. In the first period, nodes use slotted period. In the first period, nodes use slotted Carrier Sense
Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for Multiple Access / Collision Avoidance (CSMA/CA) for data
data communication. In the second one, a TDMA scheme controls medium communication. In the second one, a TDMA scheme controls medium
access. During the idle period, communication does not take place, access. During the idle period, communication does not take place,
thus the inactive period is a good opportunity for nodes to turn the thus the inactive period is a good opportunity for nodes to turn the
radio off and save energy. The coordinator announces in each beacon radio off and save energy. The coordinator announces in each beacon
the list of nodes for which data will be sent in the subsequent the list of nodes for which data will be sent in the subsequent
period. Therefore, devices may remain in sleep mode by default and period. Therefore, devices may remain in sleep mode by default and
wake up periodically to listen to the beacons sent by their wake up periodically to listen to the beacons sent by their
coordinator. If a device wants to transmit data, or learns from a coordinator. If a device wants to transmit data, or learns from a
beacon that it is an intended destination, then it will exchange beacon that it is an intended destination, then it will exchange
messages with the coordinator and will thus consume energy. An messages with the coordinator (and thus consume energy). An
underlying assumption is that when a message is sent to a underlying assumption is that when a message is sent to a
coordinator, the radio of the latter will be ready to receive the coordinator, the radio of the coordinator will be ready to receive
message. the message.
The beacon interval and the duration of the beacon interval active The beacon interval and the duration of the beacon interval active
portion (i.e. the CAP and the CFP), and thus the duty cycle, can be portion (i.e. the CAP and the CFP), and thus the duty cycle, can be
configured. The parameters that control these times are called configured. The parameters that control these times are called
macBeaconOrder and macSuperframeOrder, respectively. As an example, macBeaconOrder and macSuperframeOrder, respectively. As an example,
when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be
(independently) set to values in the range between 15.36 ms and 251.6 (independently) set to values in the range between 15.36 ms and 251.6
s. seconds.
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 ii) to 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.
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 link may also
take place in a peer-to-peer configuration, whereby both link ends take place in a peer-to-peer configuration, whereby both link ends
skipping to change at page 11, line 43 skipping to change at page 12, line 19
include mechanisms for low energy consumption. Among these, the include mechanisms for low energy consumption. Among these, the
Time-Slotted Channel Hopping (TSCH) is an outstanding mode which Time-Slotted Channel Hopping (TSCH) is an outstanding mode which
offers robust features for industrial environments, among others. In offers robust features for industrial environments, among others. In
order to provide the functionality needed to enable IPv6 over TSCH, order to provide the functionality needed to enable IPv6 over TSCH,
the 6TiSCH working group was created. TSCH is based on a TDMA the 6TiSCH working group was created. TSCH is based on a TDMA
schedule whereby a set of time slots are used for frame transmission schedule whereby a set of time slots are used for frame transmission
and reception, and other time slots are unscheduled. The latter time and reception, and other time slots are unscheduled. The latter time
slots may be used by a dynamic scheduling mechanism, otherwise nodes slots may be used by a dynamic scheduling mechanism, otherwise nodes
may keep the radio off during the unscheduled time slots, thus saving may keep the radio off during the unscheduled time slots, thus saving
energy. The minimal schedule configuration specified in energy. The minimal schedule configuration specified in
[I-D.ietf-6tisch-minimal] comprises 101 time slots, whereby 95 of [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time
these time slots are unscheduled and the time slot duration is 15 ms. slots are unscheduled and the time slot duration is 15 ms.
Other 802.15.4e modes, which are in fact designed for low energy, are The previously mentioned CSL and RIT are also 802.15.4e modes
the previously mentioned CSL and RIT. designed for low energy.
3.5.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 / CAT-iq [EN300] but with
specific changes to significantly reduce the power consumption at the specific changes to significantly reduce the power consumption at the
expense of data throughput as specified in [TS102]. DECT ULE devices expense of data throughput [TS102]. DECT ULE devices typically
typically operates on special power optimized silicon, but can operate on special power optimized silicon, but can connect to a DECT
connect to a DECT Gateway supporting traditional DECT / CAT-iq for Gateway supporting traditional DECT / CAT-iq for cordless telephony
cordless telephony and data as well as the DECT ULE extensions. It and data as well as the DECT ULE extensions. IPv6 can be run over
is possible to run IPv6 over DECT ULE by using a 6LoWPAN variant DECT ULE by using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule].
adapted for DECT ULE [I-D.ietf-6lo-dect-ule].
DECT terminology operates with two major role definitions: The DECT defines two major roles: the Portable Part (PP) is the power
Portable Part (PP) is the power constrained device, while the Fixed constrained device, while the Fixed Part (FP) is the Gateway or base
Part (FP) is the Gateway or base station in a star topology. DECT is station in a star topology. DECT operates in license free and
operating in license free and reserved frequency bands based on TDMA/ reserved frequency bands based on TDMA/FDMA and TDD using dynamic
FDMA and TDD using dynamic channel allocation for interference channel allocation for interference avoidance. It provides good
avoidance. It provides good indoor (~50 m) and outdoor (~300 m) indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length
coverage. It is using a frame length of 10 ms, which is divided into of 10 ms divided into 24 timeslots, and it supports connection
24 timeslots and it is supporting connection oriented, packet data oriented, packet data and connection-less services.
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 MAC level DECT ULE communications between FP and PP are initiated At the MAC level DECT ULE communications between FP and PP are
by the PP. A FP can initiate communication indirectly by sending initiated by the PP. A FP can initiate communication indirectly by
paging signal to a PP. The PP determines the timeslot and frequency sending paging signal to a PP. The PP determines the timeslot and
on which the communication between FP and PP takes place. The PP frequency on which the communication between FP and PP takes place.
verifies the radio timeslot/frequency position is unoccupied before The PP verifies the radio timeslot/frequency position is unoccupied
it initiates its transmitter. An access-request message, which before it initiates its transmitter. An access-request message,
usually carries data, is sent to the FP. The FP sends a confirm which usually carries data, is sent to the FP. The FP sends a
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
improves data transfer reliability significant. A segmentation and significantly improves data transfer reliability. A segmentation and
reassembly scheme supports transfer of larger higher layer SDUs and reassembly scheme supports transfer of larger higher layer SDUs and
provides data integrity check. The DECT ULE packet data service provides data integrity check. The DECT ULE packet data service
ensures data integrity, proper sequencing, duplicate protection, but ensures data integrity, proper sequencing, duplicate protection, but
does not guaranteed delivery. Higher layers protocols have to take not guaranteed delivery. Higher layers protocols have to take this
this into considerations. 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 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 range 10 ms to 327
seconds. The PP may enter sleep mode to save power. The listening seconds. 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 dummybearer. Hence, longer sleep interval reduces the average energy
consumption, but adds a energy consumption penalty for acquiring consumption, but adds a energy consumption penalty for acquiring
synchronization to the FP dummy bearer. The PP can obtain all synchronization to the FP dummy bearer. The PP can obtain all
skipping to change at page 13, line 33 skipping to change at page 14, line 7
packet transfer in N frames without the need for resynchronization packet transfer in N frames without the need for resynchronization
and listening to paging or instruct the PP to stay in a higher duty and listening to paging or instruct the PP to stay in a higher duty
cycle paging detection mode. cycle paging detection mode.
The DECT ULE technology allows per PP configuration of paging The DECT ULE technology allows 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 is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. 6LoWPAN provides an adaptation layer designed to support IPv6 over
It was born to fill the gap that the IPv6 layer does not support IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three
fragmentation and assembly of <1280-byte packets while IEEE 802.15.4 aspects, as follows.
only supports a MTU of 127 bytes.
IPv6 is the basis for the higher layer protocols, including both TCP/ First, 6LoWPAN provides one fragmentation and reassembly mechanism
UDP transport and applications. So they are quite ignorant of the which is aimed at solving the packet size issue in IPv6 and could
lower layers, and are almost neutral to the energy-efficiency also affect energy-efficiency. IPv6 requires that every link in the
problem. internet have an MTU of 1280 octets or greater. On any link that
cannot convey a 1280-octet packet in one piece, link-specific
fragmentation and reassembly must be provided at a layer below IPv6
[RFC2460]. 6LoWPAN provides fragmentation and reassembly below the
IP layer to solve the problem. One of the benefits from placing
fragmentation at a lower layer such as the 6LoWPAN layer is that it
can avoid the presence of more IP headers, because fragmentation at
the IP layer will produce more IP packets, each one carrying its own
IP header. However, performance can be severely affected if, after
IP layer fragmentation, then 6LoWPAN fragmentation happens as well
(e.g. when the upper layer is not aware of the existence of the
fragmentation at the 6LoWPAN layer). One solution is to require
higher layers awareness of lower layer features and generate small
enough packets to avoid fragmentation. In this regard, the Block
option in CoAP can be useful when CoAP is used at the application
layer [RFC 7959].
What the network stack can optimize is to save the computing power. Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies
For example the Contiki implementation has multiple cross layer 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
long UDP and TCP header will consume even more packet space than the
data itself. 6LoWPAN provides IPv6 and UDP header compression at the
adaptation layer. Therefore, a lower amount of data will be handled
by the lower layers, whereas both the sender and receiver will spend
more computing power on the compression and decompression of the
packets over the air. Compression can also be performed at higher
layers (see Section 6.4).
Finally, the 6LoWPAN working group developed the energy-efficient
Neighbor Discovery called 6LoWPAN-ND, which is an energy efficient
replacement of the IPv6 ND in constrained environments. IPv6
Neighbor Discovery was not designed for non-transitive wireless
links, as its heavy use of multicast makes it inefficient and
sometimes impractical in a low-power and lossy network. 6LoWPAN-ND
describes simple optimizations to IPv6 Neighbor Discovery, its
addressing mechanisms, and duplicate address detection for Low-power
Wireless Personal Area Networks and similar networks. However,
6LoWPAN ND does not modify Neighbor Unreachability Detection (NUD)
timeouts, which are very short (by default three transmissions spaced
one second apart). NUD timeout settings should be tuned taking into
account the latency that may be introduced by duty-cycled mechanisms
at the link layer, or alternative, less impatient NUD algorithms
should be considered [I-D.ietf-6man-impatient-nud].
IPv6 underlies the higher layer protocols, including both TCP/UDP
transport and applications. By design, the higher-layer protocols do
not typically have specific information about the lower layers, and
thus cannot solve the energy-efficiency problem.
The network stack can be designed to save computing power. For
example the Contiki implementation has multiple cross layer
optimizations for buffers and energy management, e.g., the computing 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 out of the scope of IETF and the LWIG
working group. working group.
6LoWPAN contributes to the energy-efficiency problem in two ways.
First of all, it swaps computing with communication. 6LoWPAN applies
compression of the IPv6 header. This means less amount of data will
be handled by the lower layer, but both the sender and receiver
should spend more computing power on the compression and
decompression of the packets over the air. Secondly, the 6LoWPAN
working group developed the energy-efficient Neighbor Discovery
called 6LoWPAN-ND, which is an energy efficient replacement of the
IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not
designed for non-transitive wireless links, as its heavy use of
multicast makes it inefficient and sometimes impractical in a low-
power and lossy network. 6LoWPAN-ND describes simple optimizations to
IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate
address detection for Low-power Wireless Personal Area Networks and
similar networks. However, 6LoWPAN ND does not modify Neighbor
Unreachability Detection (NUD) timeouts, which are very short (by
default three transmissions spaced one second apart). NUD timeout
settings should be tuned taking into account the latency that may be
introduced by duty-cycled mechanisms at the link layer, or
alternative, less impatient NUD algorithms should be considered
[I-D.ietf-6man-impatient-nud].
5. Routing Protocols 5. Routing Protocols
The routing protocol designed by the IETF for constrained RPL [RFC6550] is a routing protocol designed by the IETF for
environments is called RPL [RFC6550]. As a routing protocol, RPL has constrained environments. RPL exchanges messages periodically and
to exchange messages periodically and keep routing states for each keeps routing states for each destination. RPL is optimized for the
destination. RPL is optimized for the many-to-one communication many-to-one communication pattern, where network nodes primarily send
pattern, where network nodes primarily send data towards the border data towards the border router, but has provisions for any-to-any
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. It divides the routing protocol into control and profile of RPL. Their analysis divides the routing protocol into
data traffic. The control channel uses ICMP messages to establish control and data traffic. The control plane carries ICMP messages to
and maintain the routing states. The data channel is any application establish and maintain the routing states. The data plane carries
that uses RPL for routing packets. The study has shown that the any application that uses RPL for routing packets. The study has
power consumption of the control traffic goes down over time in a shown that the power consumption of the control traffic goes down
relatively stable network. The study also reflects that the routing over time in a relatively stable network. The study also reflects
protocol should keep the control traffic as low as possible to make that the routing protocol should keep the control traffic as low as
it energy-friendly. The amount of RPL control traffic can be tuned possible to make it energy-friendly. The amount of RPL control
by setting the Trickle algorithm parameters (i.e. Imin, Imax and k) traffic can be tuned by setting the Trickle [RFC6206] algorithm
to adequate values. However, there exists a trade-off between energy parameters (i.e. Imin, Imax and k) to appropriate values. However,
consumption and other performance parameters such as network there exists a trade-off between energy consumption and other
convergence time and robustness. performance parameters such as network convergence time and
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,
connecting the services of smart devices to the World Wide Web. CoAP connecting 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.
The energy-efficient design is implicitly included in the CoAP Energy efficiency is part of the CoAP protocol design. CoAP uses a
protocol design. CoAP uses a fixed-length binary header of only four fixed-length binary header of only four bytes that may be followed by
bytes that may be followed by binary options. To reduce regular and binary options. To reduce regular and frequent queries of the
frequent queries of the resources, CoAP provides an observe mode, in resources, CoAP provides an observe mode, in which the requester
which the requester registers its interest of a certain resource and registers its interest of a certain resource and the responder will
the responder will report the value whenever it was updated. This report the value whenever it was updated. This reduces the request
reduces the request response round trips while keeping information response round trips while keeping information exchange a ubiquitous
exchange a ubiquitous service and, most importantly, it allows an service; an energy-constrained server can remain in sleep mode during
energy-constrained server to remain in sleep mode during the period the period between observe notification transmissions.
between observe notification transmissions.
Furthermore, [RFC7252] defines CoAP proxies which can cache resource Furthermore, [RFC7252] defines CoAP proxies which 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
aggregation. This technique allows a node to receive data messages
(e.g. carrying sensor readings) from other nodes in the network,
perform an operation based on the content in those messages, and
transmit the result of the operation. Such operation may simply be
intended to use one packet to carry the readings transported in
several packets (which reduces header and transmission overhead), or
it may be a more sophisticated operation, possibly based on
mathematical, logical or filtering principles (which reduces the
payload size to be transmitted).
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 [I-D.rahman-core-sleepy-nodes-do-we-need], while an example
application (in the context of illustrating several security application (in the context of illustrating several security
mechanisms) in a scenario with sleepy devices has been described mechanisms) in a scenario with sleepy devices has been described
[I-D.ietf-lwig-crypto-sensors]. The different approaches to support [I-D.ietf-lwig-crypto-sensors]. Approaches to support sleepy nodes
sleepy nodes include exploiting the use of proxies, leveraging the include exploiting the use of proxies, leveraging the Resource
Resource Directory [I-D.ietf-core-resource-directory] or signaling Directory [I-D.ietf-core-resource-directory] or signaling when a node
when a node is awake to the interested nodes. A more recent work is awake to the interested nodes. Recent work defines publish-
defines publish-subscribe and message queuing extensions to CoAP and subscribe and message queuing extensions to CoAP and the Resource
the Resource Directory in order to support devices that spend most of Directory in order to support devices that spend most of their time
their time in a sleeping state [I-D.ietf-core-coap-pubsub]. Notably, in asleep [I-D.ietf-core-coap-pubsub]. Notably, this work has been
this work has been adopted by the CoRE Working Group. adopted by the 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.
On the other hand, oneM2M defines a CoAP binding with an application oneM2M defines a CoAP binding with an application layer mechanism for
layer mechanism for sleepy nodes. 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 which would unnecessarily waste node energy
and other resources. and other resources. On the other hand, note that CoAP can also run
on top of TCP [I-D.ietf-core-coap-tcp-tls]. In that case, similar
guidance applies to TCP timers, albeit with greater motivation to
carefully configure TCP RTO parameters, since [RFC6298] reduced the
default initial TCP RTO to 1 second, which may interact more
negatively with duty-cycled links than default CoAP RTO values.
7. Summary 6.4. Data compression
Another method intended to reduce the size of the data units to be
communicated in constrained-node networks is data compression, which
allows to encode data using less bits than the original data
representation. Data compression is more efficient at higher layers,
particularly before encryption is used. In fact, encryption
mechanisms may generate an output that does not contain redundancy,
making it almost impossible to reduce the data representation size.
In CoAP, messages may be encrypted by using DTLS (or TLS when CoAP
over TCP is used), which is the default mechanism for securing CoAP
exchanges.
7. Summary and Conclusions
We summarize the key takeaways in this document: We summarize the key takeaways in this document:
a. Internet protocols designed by IETF can be considered as the a. Internet protocols designed by IETF can be considered as the
customer of the lower layers (PHY, MAC, and Duty-cycling). To customer of the lower layers (PHY, MAC, and Duty-cycling). To
save power consumption, it is recommended to operate based on the reduce power consumption, it is recommended that Layer 3 designs
lower layer behavior rather than treating the lower layer as a should operate based on awareness of lower-level parameters
black box. rather than treating the lower layer as a black box (Sections 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 principles reduce the transmission/reception power. This design principle
have been employed by many protocols in 6Lo and CoRE working has been employed by many protocols in 6Lo and CoRE working group
group. (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
(Sections 2 and 6.1).
d. Saving power by sleeping occasionally is used widely. Reduction d. Saving power by sleeping as much as possible is used widely
of states is also an effective method to be energy efficient. (Section 3).
8. Contributors 8. Contributors
Jens T. Petersen, RTX, contributed the section on power save Jens T. Petersen, RTX, contributed the section on power save
services in DECT ULE. services in DECT ULE.
9. Acknowledgments 9. Acknowledgments
Carles Gomez has been supported by the Spanish Government, FEDER and Carles Gomez has been supported by the Spanish Government, FEDER and
the ERDF through projects TEC2012-32531 and TEC2016-79988-P. the ERDF through projects TEC2012-32531 and TEC2016-79988-P.
Authors would like to thank the review and feedback from a number of Authors would like to thank the review and feedback from a number of
experts in this area: Carsten Bormann, Ari Keranen, Hannes experts in this area: Carsten Bormann, Ari Keranen, Hannes
Tschofenig, Dominique Barthel. Tschofenig, Dominique Barthel, Bernie Volz and Charlie Perkins.
The text of this document was improved based on IESG Document Editing The text of this document was improved based on IESG Document Editing
session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to session during IETF87. Thanks to Ted Lemon and Joel Jaeglli for
initiate this facilities. initiating and facilitating this editing session.
10. IANA Considerations 10. IANA Considerations
This document has no IANA requests. This document has no IANA requests.
11. Security Considerations 11. Security Considerations
This document discusses the energy efficient protocol design, and This document discusses the energy efficient protocol design, and
does not incur any changes or challenges on security issues besides does not incur any changes or challenges on security issues besides
what the protocol specifications have analyzed. what the protocol specifications have analyzed.
12. References 12. References
12.1. Normative References 12.1. Normative References
[Bluetooth42] [Bluetooth42]
Bluetooth Special Interest Group, "Bluetooth Core Bluetooth Special Interest Group, "Bluetooth Core
Specification Version 4.2", December 2014, Specification Version 4.2", December 2014,
<https://www.bluetooth.org/en-us/specification/adopted- <https://www.bluetooth.org/en-us/specification/
specifications>. adopted-specifications>.
[EN300] ""Digital Enhanced Cordless Telecommunications (DECT); [EN300] ETSI, "Digital Enhanced Cordless Telecommunications
Common Interface (CI);"", March 2015, (DECT); Common Interface (CI)", March 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] [fifteendotfour]
IEEE Computer Society, "IEEE Std. 802.15.4-2015 IEEE IEEE Computer Society, "IEEE Std. 802.15.4-2015 IEEE
Standard for Local and metropolitan area networks--Part Standard for Local and metropolitan area networks--Part
15.4: Low-Rate Wireless Personal Area Networks (LR- 15.4: Low-Rate Wireless Personal Area Networks (LR-
WPANs)", 2015, <https://standards.ieee.org/findstds/ WPANs)", 2015, <https://standards.ieee.org/findstds/
standard/802.15.4-2015.html>. standard/802.15.4-2015.html>.
[G9959] International Telecommunication Union, "Short range
narrow-band digital radiocommunication transceivers - PHY
and MAC layer specifications, ITU-T Recommendation
G.9959", January 2015,
<http://www.itu.int/rec/T-REC-G.9959>.
[IEEE80211v] [IEEE80211v]
IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC) IEEE, "Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications, Amendment 8: IEEE and Physical Layer (PHY) specifications, Amendment 8: IEEE
802.11 Wireless Network Management.", February 2012. 802.11 Wireless Network Management.", February 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication
Requirement Levels", BCP 14, RFC 2119, Protocol for Building Automation and Control Networks,
DOI 10.17487/RFC2119, March 1997, ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to
<http://www.rfc-editor.org/info/rfc2119>. ANSI/ASHRAE Standard 135-2012", July 2014,
<https://www.ashrae.org/File%20Library/docLib/StdsAddenda/
07-31-2014_135_2012_an_at_au_av_aw_ax_az_Final.pdf>.
[NFC] NFC Forum, "NFC Logical Link Control Protocol version 1.3,
NFC Forum Technical Specification", March 2016.
[oneM2M] oneM2M, "oneM2M specifications",
<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,
<http://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,
"The Trickle Algorithm", RFC 6206, DOI 10.17487/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
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<http://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[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,
<http://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,
<http://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[TS102] ""Digital Enhanced Cordless Telecommunications (DECT); [TS102] ETSI, "Digital Enhanced Cordless Telecommunications
Ultra Low Energy (ULE); Machine to Machine Communications; (DECT); Ultra Low Energy (ULE); Machine to Machine
Part 2: Home Automation Network (phase 2"", March 2015, Communications; Part 2: Home Automation Network (phase 2",
<https://www.etsi.org/deliver/ 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 12.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", September 2012,
<http://www.ti.com/lit/an/swra292/swra292.pdf>. <http://www.ti.com/lit/an/swra292/swra292.pdf>.
[Announcementlayer]
Dunkels, A., "The Announcement Layer: Beacon Coordination
for the Sensornet Stack. In Proceedings of EWSN 2011",
February 2011,
<http://dunkels.com/adam/dunkels11announcement.pdf>.
[ContikiMAC] [ContikiMAC]
Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol,
SICS Technical Report T2011:13", December 2011, SICS Technical Report T2011:13", December 2011,
<https://www.mysciencework.com/publication/download/2f406d <https://www.mysciencework.com/publication/download/2f406d
3c4cc1eda32a234f7a1ad2cc3b/7eb199e4f8b00857e21af2b7d2b31c0 3c4cc1eda32a234f7a1ad2cc3b/7eb199e4f8b00857e21af2b7d2b31c0
d>. d>.
[I-D.bormann-lwig-7228bis] [I-D.bormann-lwig-7228bis]
Bormann, C. and C. Gomez, "Terminology for Constrained- Bormann, C., Ersue, M., Keranen, A., and C. Gomez,
Node Networks", draft-bormann-lwig-7228bis-00 (work in "Terminology for Constrained-Node Networks", draft-
progress), October 2016. bormann-lwig-7228bis-01 (work in progress), May 2017.
[I-D.ietf-6lo-dect-ule] [I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-09 (work in progress), Energy", draft-ietf-6lo-dect-ule-09 (work in progress),
December 2016. December 2016.
[I-D.ietf-6man-impatient-nud] [I-D.ietf-6man-impatient-nud]
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient", draft-ietf-6man-impatient- Detection is too impatient", draft-ietf-6man-impatient-
nud-07 (work in progress), October 2013. nud-07 (work in progress), October 2013.
[I-D.ietf-6tisch-architecture] [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-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 2017.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X., Pister, K., and T. Watteyne, "Minimal Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work
in progress), February 2017. in progress), February 2017.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
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-00 (work in (CoAP)", draft-ietf-core-coap-pubsub-02 (work in
progress), October 2016. progress), July 2017.
[I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-09 (work in progress), May
2017.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Resource Directory", draft-ietf-core-resource-directory-09 Amsuess, "CoRE Resource Directory", draft-ietf-core-
(work in progress), October 2016. resource-directory-11 (work in progress), July 2017.
[I-D.ietf-lwig-crypto-sensors] [I-D.ietf-lwig-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-02 Smart Object Networks", draft-ietf-lwig-crypto-sensors-04
(work in progress), February 2017. (work in progress), August 2017.
[I-D.kovatsch-lwig-class1-coap] [I-D.kovatsch-lwig-class1-coap]
Kovatsch, M., "Implementing CoAP for Class 1 Devices", Kovatsch, M., "Implementing CoAP for Class 1 Devices",
draft-kovatsch-lwig-class1-coap-00 (work in progress), draft-kovatsch-lwig-class1-coap-00 (work in progress),
October 2012. October 2012.
[I-D.rahman-core-sleepy-nodes-do-we-need] [I-D.rahman-core-sleepy-nodes-do-we-need]
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?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work
in progress), February 2014. in progress), February 2014.
[Powertrace] [Powertrace]
Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: Dunkels, Eriksson, Finne, and Tsiftes, "Powertrace:
Network-level Power Profiling for Low-power Wireless Network-level Power Profiling for Low-power Wireless
Networks", March 2011, <https://core.ac.uk/download/ Networks", March 2011, <https://core.ac.uk/download/
pdf/11435067.pdf?repositoryId=362>. pdf/11435067.pdf?repositoryId=362>.
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
 End of changes. 97 change blocks. 
313 lines changed or deleted 414 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/