draft-ietf-lwig-energy-efficient-05.txt   draft-ietf-lwig-energy-efficient-06.txt 
Internet Engineering Task Force C. Gomez Internet Engineering Task Force C. Gomez
Internet-Draft Universitat Politecnica de Catalunya/i2CAT Internet-Draft Universitat Politecnica de Catalunya/i2CAT
Intended status: Informational M. Kovatsch Intended status: Informational M. Kovatsch
Expires: April 16, 2017 ETH Zurich Expires: August 12, 2017 ETH Zurich
H. Tian H. Tian
China Academy of Telecommunication Research China Academy of Telecommunication Research
Z. Cao, Ed. Z. Cao, Ed.
Huawei Technologies Huawei Technologies
October 13, 2016 February 8, 2017
Energy-Efficient Features of Internet of Things Protocols Energy-Efficient Features of Internet of Things Protocols
draft-ietf-lwig-energy-efficient-05 draft-ietf-lwig-energy-efficient-06
Abstract Abstract
This document describes the problems and current practices of energy This document describes the challenges for energy-efficient protocol
efficient protocol operation on constrained devices. It summarizes operation on constrained devices and the current practices used to
the main link layer techniques for energy efficient networking, and overcome those challenges. It summarizes the main link-layer
it highlights the impact of such techniques on the upper layer techniques used for energy-efficient networking, and it highlights
protocols, so that they can coordinately achieve an energy efficient the impact of such techniques on the upper layer protocols so that
behavior. The document also provides an overview of energy efficient they can together achieve an energy efficient behavior. The document
mechanisms available at each layer of the constrained node network also provides an overview of energy-efficient mechanisms available at
IETF protocol suite. each layer of the IETF protocol suite specified for constrained node
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 http://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 April 16, 2017. This Internet-Draft will expire on August 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://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. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MAC 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 . . . . . . . . . . . . . . . . . 7
3.5. Power save services available in example low-power radios 7 3.5. Power save services available in example low-power radios 8
3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8
3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9
3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10
3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 11 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 12
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15
6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15
6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
skipping to change at page 3, line 18 skipping to change at page 3, line 18
A large body of research efforts have been put on this "energy A large body of research efforts have been put on this "energy
efficiency" problem. Most of this research has focused on how to efficiency" problem. Most of this research has focused on how to
optimize the system's power consumption regarding a certain optimize the system's power consumption regarding a certain
deployment scenario or how could an existing network function such as deployment scenario or how could an existing network function such as
routing or security be more energy-efficient. Only few efforts routing or security be more energy-efficient. Only few efforts
focused on energy-efficient designs for IETF protocols and focused on energy-efficient designs for IETF protocols and
standardized network stacks for such constrained devices standardized network stacks for such 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 6LoWPAN ( such constrained devices, including IPv6 over Low-Power Wireless
[RFC6282],[RFC6775],[RFC4944] ), RPL[RFC6550], and Personal Area Networks (6LoWPAN) [RFC6282],[RFC6775],[RFC4944], the
CoAP[I-D.ietf-core-coap]. This document tries to summarize the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL)
design considerations of making the IETF contrained protocol suite as [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252].
energy-efficient as possible. While this document does not provide This document tries to summarize the design considerations for making
detailed and systematic solutions to the energy efficiency problem, the IETF constrained protocol suite as energy-efficient as possible.
it summarizes the design efforts and analyzes the design space of While this document does not provide detailed and systematic
this problem. In particular, it provides a comprehensive overview of solutions to the energy efficiency problem, it summarizes the design
the techniques used by the lower layers to save energy and how these efforts and analyzes the design space of this problem. In
may impact on the upper layers. particular, it provides an overview of the techniques used by the
lower layers to save energy and how these may impact on the upper
layers.
After reviewing the energy-efficient design of each layer, an overall After reviewing the energy-efficient design of each layer, an overall
conclusion is summarized. Though the lower layer communication conclusion is summarized. Though the lower layer communication
optimization is the key part of energy efficient design, the protocol optimization is the key part of energy efficient design, the protocol
design at the upper layers is also important to make the device design at the upper layers is also important to make the device
energy-efficient. energy-efficient.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
1.2. Terminology 1.2. Terminology
The terminologies used in this document can be referred to [RFC7228]. The terminologies used in this document can be referred to [RFC7228]
[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 witnessed 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
skipping to change at page 4, line 36 skipping to change at page 4, line 44
| |
+-------+ +-------+
|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 atom operations on a prevalent sensor node platform. The common operations involved in communication on a prevalent sensor
measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC] node platform. The measurement was based on the Tmote Sky with
as the radio duty cycling algorithm. From this and many other ContikiMAC [ContikiMAC] as the radio duty cycling algorithm. From
measurement reports (e.g. [AN053]), we can see that the energy this and many other measurement reports (e.g. [AN053]), we can see
consumption of optimized transmission and reception are in the same that the energy consumption of optimized transmission and reception
order. For IEEE 802.15.4 and UWB links, transmitting may actually be are in the same order. For IEEE 802.15.4 and Ultra WideBand (UWB)
even cheaper than receiving. It also shows that broadcast and non- links, transmitting may actually be even cheaper than receiving. It
synchronized communication transmissions are energy costly because also shows that broadcast and non-synchronized communication
they need to acquire the medium for a long time. transmissions are energy costly because they need to acquire the
medium for a long time.
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Activity | Energy (uJ) | | Activity | Energy (uJ) |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Broadcast reception | 178 | | Broadcast reception | 178 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Unicast reception | 222 | | Unicast reception | 222 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Broadcast transmission | 1790 | | Broadcast transmission | 1790 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Non-synchronized unicast transmission | 1090 | | Non-synchronized unicast transmission | 1090 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Synchronized unicast transmission | 120 | | Synchronized unicast transmission | 120 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Unicast TX to awake receiver | 96 | | Unicast TX to awake receiver | 96 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
Figure 2: Power consumption of atom operations on the Tmote Sky with Figure 2: Power consumption of common operations involved in
ContikiMAC communication on the Tmote Sky with ContikiMAC
3. MAC and Radio Duty Cycling 3. MAC and Radio Duty Cycling
In low-power wireless networks, communication and power consumption In low-power wireless networks, communication and power consumption
are intertwined. The communication device is typically the most are intertwined. The communication device is typically the most
power-consuming component, but merely refraining from transmissions power-consuming component, but merely refraining from transmissions
is not enough to attain a low power consumption: the radio may is not enough to attain a low power consumption: the radio may
consume as much power in listen mode as when actively transmitting. consume as much power in listen mode as when actively transmitting.
This augments the key problem known as idle listening, whereby the This augments the key problem known as idle listening, whereby the
radio of a device may be in receive mode (ready to receive any radio of a device may be in receive mode (ready to receive any
skipping to change at page 6, line 51 skipping to change at page 7, line 5
the involved devices. Such negotiation may be performed per the involved devices. Such negotiation may be performed per
transmission or per session/connection. Bluetooth Low Energy transmission or per session/connection. Bluetooth Low Energy
(Bluetooth LE) is an example of a radio technology based on this (Bluetooth LE) is an 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 Initated 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.
3.2. Latency and buffering 3.2. Latency and buffering
The latency of a data unit transmission to a duty-cycled device is The latency of a data unit transmission to a duty-cycled device is
equal to or greater than the latency of transmitting to an always-on equal to or greater than the latency of transmitting to an always-on
device. Therefore, duty-cycling leads to a trade-off between energy device. Therefore, duty-cycling leads to a trade-off between energy
consumption and latency. Note that in addition to a latency consumption and latency. Note that in addition to a latency
skipping to change at page 9, line 20 skipping to change at page 9, line 22
such as FMS interval and BSS MAX Idle Period, so that the wireless such as 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.5.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. Currently, it is possible to run
IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to
BT-LE [I-D.ietf-6lowpan-btle]. 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 TDMA scheme which is Medium access in Bluetooth LE is based on a Time Division Multiple
coordinated by the master. This device determines the start of Access (TDMA) scheme which is coordinated by the master. This device
connection events, in which communication between the master and a determines the start of connection events, in which communication
slave takes place. At the beginning of a connection event, the between the master and a slave takes place. At the beginning of a
master sends a poll message, which may encapsulate data, to the connection event, the master sends a poll message, which may
slave. The latter must send a response, which may also contain data. encapsulate data, to the slave. The latter must send a response,
The master and the slave may continue exchanging data until the end which may also contain data. The master and the slave may continue
of the connection event. The next opportunity for communication exchanging data until the end of the connection event. The next
between the master and the slave will be in the next connection event opportunity for communication between the master and the slave will
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 nature. 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
skipping to change at page 10, line 21 skipping to change at page 10, line 24
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],[RFC4944] and 6TiSCH [RFC6282],[RFC6775],[RFC4944] and 6TiSCH
[I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC
layer functionality. layer functionality.
IEEE 802.15.4 defines three roles called device, coordinator and PAN IEEE 802.15.4 defines three roles called device, coordinator and
coordinator. The device role is adequate for nodes that do not Personal Area Network (PAN) coordinator. The device role is adequate
implement the complete IEEE 802.15.4 functionality, and is mainly for nodes that do not implement the complete IEEE 802.15.4
targeted for constrained nodes with a limited energy source. The functionality, and is mainly targeted for constrained nodes with a
coordinator role includes synchronization capabilities and is limited energy source. The coordinator role includes synchronization
suitable for nodes that do not suffer severe constraints (e.g. a capabilities and is suitable for nodes that do not suffer severe
mains-powered node). The PAN coordinator is a special type of constraints (e.g. a mains-powered node). The PAN coordinator is a
coordinator that acts as a principal controller in an IEEE 802.15.4 special type of coordinator that acts as a principal controller in an
network. IEEE 802.15.4 network.
IEEE 802.15.4 has mainly defined two types of networks depending on IEEE 802.15.4 has mainly defined two types of networks depending on
their configuration: beacon-enabled and nonbeacon-enabled networks. their configuration: beacon-enabled and nonbeacon-enabled networks.
In the first network type, coordinators periodically transmit In the first network type, coordinators periodically transmit
beacons. The time between beacons is divided in three main parts: beacons. The time between beacons is divided in three main parts:
the Contention Access Period (CAP), the Contention Free Period (CFP) the Contention Access Period (CAP), the Contention Free Period (CFP)
and an inactive period. In the first period, nodes use slotted CSMA/ and an inactive period. In the first period, nodes use slotted
CA for data communication. In the second one, a TDMA scheme controls Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for
medium access. During the idle period, communication does not take data communication. In the second one, a TDMA scheme controls medium
place, thus the inactive period is a good opportunity for nodes to access. During the idle period, communication does not take place,
turn the radio off and save energy. The coordinator announces in thus the inactive period is a good opportunity for nodes to turn the
each beacon the list of nodes for which data will be sent in the radio off and save energy. The coordinator announces in each beacon
subsequent period. Therefore, devices may remain in sleep mode by the list of nodes for which data will be sent in the subsequent
default and wake up periodically to listen to the beacons sent by period. Therefore, devices may remain in sleep mode by default and
their coordinator. If a device wants to transmit data, or learns wake up periodically to listen to the beacons sent by their
from a beacon that it is an intended destination, then it will coordinator. If a device wants to transmit data, or learns from a
exchange messages with the coordinator and will thus consume energy. beacon that it is an intended destination, then it will exchange
An underlying assumption is that when a message is sent to a messages with the coordinator and will thus consume energy. An
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 latter will be ready to receive the
message. 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. s.
skipping to change at page 11, line 35 skipping to change at page 11, line 37
nodes may lead to a quick battery depletion), or apply nodes may lead to a quick battery depletion), or apply
synchronization techniques. The latter are out of the scope of IEEE synchronization techniques. The latter are out of the scope of IEEE
802.15.4. 802.15.4.
The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e.
This amendment includes various new MAC layer modes, some of which This amendment includes various new MAC layer modes, some of which
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 has been recently created. TSCH is based on the 6TiSCH working group was created. TSCH is based on a TDMA
a TDMA schedule whereby a set of time slots are used for frame schedule whereby a set of time slots are used for frame transmission
transmission and reception, and other time slots are unscheduled. and reception, and other time slots are unscheduled. The latter time
The latter time slots may be used by a dynamic scheduling mechanism, slots may be used by a dynamic scheduling mechanism, otherwise nodes
otherwise nodes may keep the radio off during the unscheduled time may keep the radio off during the unscheduled time slots, thus saving
slots, thus saving energy. The minimal schedule configuration energy. The minimal schedule configuration specified in
specified in [I-D.ietf-6tisch-minimal] comprises 101 time slots, [I-D.ietf-6tisch-minimal] comprises 101 time slots, whereby 95 of
whereby 95 of these time slots are unscheduled and the time slot these time slots are unscheduled and the time slot duration is 15 ms.
duration is 15 ms.
Other 802.15.4e modes, which are in fact designed for low energy, are Other 802.15.4e modes, which are in fact designed for low energy, are
the previously mentioned CSL and RIT. the previously mentioned CSL and RIT.
3.5.4. Power Save Services in DECT ULE 3.5.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 on the specific changes to significantly reduce the power consumption on the
expense of data throughput as specified in [TS102]. DECT ULE devices expense of data throughput as specified in [TS102]. DECT ULE devices
skipping to change at page 15, line 38 skipping to change at page 15, line 42
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.
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]. The different found in [I-D.rahman-core-sleepy-nodes-do-we-need], while an example
approaches include exploiting the use of proxies, leveraging the application (in the context of illustrating several security
mechanisms) in a scenario with sleepy devices has been described
[I-D.ietf-lwig-crypto-sensors]. The different approaches to support
sleepy nodes include exploiting the use of proxies, leveraging the
Resource Directory [I-D.ietf-core-resource-directory] or signaling Resource Directory [I-D.ietf-core-resource-directory] or signaling
when a node is awake to the interested nodes. A more recent work when a node is awake to the interested nodes. A more recent work
defines publish-subscribe and message queuing extensions to CoAP and defines publish-subscribe and message queuing extensions to CoAP and
the Resource Directory in order to support devices that spend most of the Resource Directory in order to support devices that spend most of
their time in a sleeping state [I-D.koster-core-coap-pubsub]. As of their time in a sleeping state [I-D.ietf-core-coap-pubsub]. Notably,
the writing, none of these proposals has been adopted by the CoRE this work has been adopted by the CoRE Working Group.
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 On the other hand, oneM2M defines a CoAP binding with an application
skipping to change at page 16, line 31 skipping to change at page 16, line 39
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.
7. Summary 7. Summary
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 synergize with the save power consumption, it is recommended to operate based on the
lower layer other than treating the lower layer as a black box. lower layer behavior rather than treating the lower layer as a
black box.
b. It is always useful to compresss 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 principles
have been employed by many protocols in 6Lo and CoRE working have been employed by many protocols in 6Lo and CoRE working
group. group.
c. Broadcast and non-synchronzed 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.
d. Saving power by sleeping occasionally is used widely. Reduction d. Saving power by sleeping occasionally is used widely. Reduction
of states is also an effective method to be energy efficient. of states is also an effective method to be energy efficient.
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 Ministerio de Economia y Carles Gomez has been supported by the Spanish Government, FEDER and
Competitividad and FEDER through project TEC2012-32531. 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.
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. Thank Ted Lemon, Joel Jaeggli, and efforts to
initiate this facilities. initiate this facilities.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 18, line 48 skipping to change at page 19, line 5
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7252>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>.
[TS102] ""Digital Enhanced Cordless Telecommunications (DECT); [TS102] ""Digital Enhanced Cordless Telecommunications (DECT);
Ultra Low Energy (ULE); Machine to Machine Communications; Ultra Low Energy (ULE); Machine to Machine Communications;
Part 1: Home Automation Network (phase 1)"", 2013. Part 1: Home Automation Network (phase 1)"", 2013.
12.2. Informative References 12.2. Informative References
[AN053] Selvig, B., "Measuring power consumption with CC2430 and [AN053] Selvig, B., "Measuring power consumption with CC2430 and
Z-Stack". Z-Stack".
[Announcementlayer] [Announcementlayer]
Dunkels, A., "The Announcement Layer: Beacon Coordination Dunkels, A., "The Announcement Layer: Beacon Coordination
for the Sensornet Stack. In Proceedings of EWSN 2011". for the Sensornet Stack. In Proceedings of EWSN 2011".
[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.
[I-D.bormann-lwig-7228bis]
Bormann, C. and C. Gomez, "Terminology for Constrained-
Node Networks", draft-bormann-lwig-7228bis-00 (work in
progress), October 2016.
[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-06 (work in progress), Energy", draft-ietf-6lo-dect-ule-09 (work in progress),
October 2016. December 2016.
[I-D.ietf-6lowpan-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013.
[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-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
in progress), June 2016. in progress), January 2017.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X., Pister, K., and T. Watteyne, "Minimal
Configuration", draft-ietf-6tisch-minimal-16 (work in 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work
progress), June 2016. in progress), January 2017.
[I-D.ietf-core-coap] [I-D.ietf-core-coap-pubsub]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Koster, M., Keranen, A., and J. Jimenez, "Publish-
Application Protocol (CoAP)", draft-ietf-core-coap-18 Subscribe Broker for the Constrained Application Protocol
(work in progress), June 2013. (CoAP)", draft-ietf-core-coap-pubsub-00 (work in
progress), October 2016.
[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., and P. Stok, "CoRE
Resource Directory", draft-ietf-core-resource-directory-08 Resource Directory", draft-ietf-core-resource-directory-09
(work in progress), July 2016. (work in progress), October 2016.
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-07
(work in progress), February 2014.
[I-D.koster-core-coap-pubsub] [I-D.ietf-lwig-crypto-sensors]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
Subscribe Broker for the Constrained Application Protocol Considerations and Implementation Experiences in Securing
(CoAP)", draft-koster-core-coap-pubsub-05 (work in Smart Object Networks", draft-ietf-lwig-crypto-sensors-01
progress), July 2016. (work in progress), October 2016.
[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.
 End of changes. 34 change blocks. 
121 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/