One document matched: draft-ietf-lwig-energy-efficient-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no"?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-lwig-energy-efficient-05"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Lwig Energy Efficient">
Energy-Efficient Features of Internet of Things Protocols
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Carles Gomez" initials="C.G" surname="Gomez">
<organization>Universitat Politecnica de Catalunya/i2CAT</organization>
<address>
<postal>
<street>C/Esteve Terradas, 7</street>
<city>Castelldefels</city>
<region/>
<code>08860</code>
<country>Spain</country>
</postal>
<phone/>
<facsimile/>
<email>carlesgo@entel.upc.edu</email>
<uri/>
</address>
</author>
<author fullname="Matthias Kovatsch" initials="M.K" surname="Kovatsch">
<organization>ETH Zurich</organization>
<address>
<postal>
<street>Universitaetstrasse 6</street>
<city>Zurich</city>
<region>CH-8092</region>
<code/>
<country>Switzerland</country>
</postal>
<phone/>
<facsimile/>
<email>kovatsch@inf.ethz.ch</email>
<uri/>
</address>
</author>
<author fullname="Hui Tian" initials="H.T" surname="Tian">
<organization>China Academy of Telecommunication Research</organization>
<address>
<postal>
<street>Huayuanbeilu No.52</street>
<city>Beijing</city>
<region>Haidian District</region>
<code>100191</code>
<country>China</country>
</postal>
<phone/>
<facsimile/>
<email>tianhui@mail.ritt.com.cn</email>
<uri/>
</address>
</author>
<author fullname="Zhen Cao" initials="Z.C" surname="Cao" role="editor">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<!-- Reorder these if your country does things differently -->
<city></city>
<region/>
<code></code>
<country>China</country>
</postal>
<phone/>
<email>zhencao.ietf@gmail.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2016"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>INT</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!---->
<abstract>
<t> This document describes the problems and current practices of energy
efficient protocol operation on constrained devices. It summarizes the main link layer techniques
for energy efficient networking, and it highlights the impact of such techniques on the upper layer protocols,
so that they can coordinately achieve an energy efficient behavior. The document also provides an overview of energy
efficient mechanisms available at each layer of the constrained node network IETF protocol suite.
</t>
</abstract>
</front>
<middle>
<section title="Introduction ">
<t> Network systems for physical world monitoring contain many battery-
powered or energy-harvesting devices. For example, in an
environmental monitoring system, or a temperature and humidity
monitoring system, there are no always-on and sustained power
supplies for the potentially large number of constrained devices. In
such deployment scenarios, it is necessary to optimize the energy
consumption of the constrained devices.
</t>
<t>A large body of research efforts have been put on this "energy efficiency"
problem. Most of this research has focused on how to optimize the
system's power consumption regarding a certain deployment scenario or
how could an existing network function such as routing or security be
more energy-efficient. Only few efforts focused on energy-efficient
designs for IETF protocols and standardized network stacks for such
constrained devices <xref target="I-D.kovatsch-lwig-class1-coap"/>.</t>
<t>The IETF has developed a suite of Internet protocols suitable for
such constrained devices, including 6LoWPAN <xref
target="RFC6282">(</xref>,<xref target="RFC6775"/>,<xref
target="RFC4944"/> ), RPL<xref target="RFC6550"/>, and CoAP<xref
target="I-D.ietf-core-coap"/>. This document tries to summarize the
design considerations of making the IETF contrained protocol suite as
energy-efficient as possible. While this document does not provide
detailed and systematic solutions to the energy efficiency problem, it
summarizes the design efforts and analyzes the design space of this
problem. In particular, it provides a comprehensive overview of the
techniques used by the lower layers to save energy and how these may impact on the upper layers.</t>
<t>After reviewing the energy-efficient design of each layer, an overall
conclusion is summarized. 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.</t>
<section title="Conventions used in this document">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/></t>
</section>
<section title="Terminology ">
<t>The terminologies used in this document can be referred to <xref target="RFC7228"/>.</t>
</section>
</section>
<section title="Overview ">
<t>The IETF has developed protocols to enable end-to-end IP
communication between constrained nodes and fully capable nodes. This
work has witnessed the evolution of the traditional Internet protocol
stack to a light-weight Internet protocol stack. As shown in <xref
target="fig.stack"/> below, the IETF has developed CoAP as the
application 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 and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently being adapted by the 6lo working group to support IPv6 over various other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and NFC.</t>
<figure anchor="fig.stack"
title="Traditional and Light-weight Internet Protocol Stack">
<artwork><![CDATA[
+-----+ +-----+ +-----+ +------+
|HTTP | | FTP | |SNMP | | CoAP |
+-----+ +-----+ +-----+ +------+
\ / / / \
+-----+ +-----+ +-----+ +-----+
| TCP | | UDP | | TCP | | UDP |
+-----+ +-----+ ===> +-----+ +-----+
\ / \ /
+-----+ +------+ +-------+ +------+ +-----+
| RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL |
+-----+ +------+ +-------+ +------+ +-----+
| |
+-------+ +-------+ +----------+
|MAC/PHY| | 6Lo |--|6LoWPAN-ND|
+-------+ +-------+ +----------+
|
+-------+
|MAC/PHY|
+-------+
]]></artwork>
</figure>
<t>There are numerous published studies reporting comprehensive measurements of wireless communication platforms <xref
target="Powertrace"/>. As an example, below we list the energy consumption profile of
the most common atom operations on a prevalent sensor node platform. The
measurement was based on the Tmote Sky with ContikiMAC <xref
target="ContikiMAC"/> as the radio duty
cycling algorithm. From this and many other measurement reports (e.g. <xref
target="AN053"/>), we can see that the energy consumption of optimized
transmission and reception are in the same order.
For IEEE 802.15.4 and UWB links, transmitting may actually be even cheaper
than receiving. It also shows that broadcast and non-synchronized communication
transmissions are energy costly because they need to
acquire the medium for a long time.</t>
<t><figure anchor="fig.evaluate"
title="Power consumption of atom operations on the Tmote Sky with ContikiMAC">
<artwork><![CDATA[+---------------------------------------+---------------+
| Activity | Energy (uJ) |
+---------------------------------------+---------------+
| Broadcast reception | 178 |
+---------------------------------------+---------------+
| Unicast reception | 222 |
+---------------------------------------+---------------+
| Broadcast transmission | 1790 |
+---------------------------------------+---------------+
| Non-synchronized unicast transmission | 1090 |
+---------------------------------------+---------------+
| Synchronized unicast transmission | 120 |
+---------------------------------------+---------------+
| Unicast TX to awake receiver | 96 |
+---------------------------------------+---------------+]]></artwork>
</figure></t>
</section>
<section title="MAC and Radio Duty Cycling">
<t>In low-power wireless networks, communication and power consumption
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 <xref target="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.
</t>
<t>From the perspective of MAC&RDC, all upper layer protocols, such
as routing, RESTful communication, adaptation, and management flows, are
all applications. Since the duty cycling algorithm is the key to
energy-efficiency of the wireless medium, it synchronizes the transmission and/or reception
request from the higher layer.</t>
<t>The MAC&RDC are not in the scope of the IETF, yet lower layer
designers and chipset manufactures take great care of the problem. For
the IETF protocol designers, however, it is good to know the behaviors
of lower layers so that the designed protocols can work perfectly with
them. </t>
<t>Once again, the IETF protocols we are going to talk about in the
following sections are the customers of the lower layers. If the different protocol layers want to
get better service in a cooperative way, they should be considerate and
understand each other.</t>
<section title="Radio Duty Cycling techniques">
<t>This subsection describes the main three RDC techniques. Note that more than one of the presented techniques may be available or can even be combined in a specific radio technology:</t>
<t>a) Channel sampling. In this solution, the radio interface of a device periodically monitors the channel for very short time intervals (i.e. with a low duty cycle) with the aim of detecting incoming transmissions. In order to make sure that a receiver can correctly receive a transmitted data unit, the sender may prepend a preamble of a duration at least the sampling period to the data unit to be sent. Another option for the sender is to repeatedly transmit the data unit, instead of sending a preamble before the data unit. Once a transmission is detected by a receiver, the receiver may stay awake until the complete reception of the data unit. Examples of radio technologies that use preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the Frequently Listening (FL) mode of ITU-T G.9959.</t>
<t>b) Scheduled transmissions. This approach allows a device to know the instants in which it should be awake (during some time interval) in order to receive data units. Otherwise, the device may remain in sleep mode. The decision on the instants that will be used for communication is reached by means of some form of negotation between the involved devices. Such negotiation may be performed per transmission or per session/connection. Bluetooth Low Energy (Bluetooth LE) is an example of a radio technology based on this mechanism.</t>
<t>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 to receive a poll message) for pending transmissions. After sending the poll message, the node remains in receive mode, ready for a potential incoming transmission. After a certain time interval, the node may go back to sleep. For example, the Receiver Initated 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 technique.</t>
</section>
<section title="Latency and buffering">
<t>The latency of a data unit transmission to a duty-cycled device is equal to or greater than the latency of transmitting to an always-on device. Therefore, duty-cycling leads to a trade-off between energy consumption and latency. Note that in addition to a latency increase, RDC may introduce latency variance, since the latency increase is a random variable (which is uniformly distributed if duty-cycling follows a periodical behavior).</t>
<t>On the other hand, due to the latency increase of duty-cycling, a sender waiting for a transmission opportunity may need to store subsequent outgoing packets in a buffer, increasing memory requirements and potentially incurring queuing waiting time that contributes to the packet overall delay and increases the probability of buffer overflow, leading to losses.</t>
</section>
<section title="Throughput">
<t>Although throughput is not typically a key concern in constrained node network
applications, it is indeed important in some services in this kind of networks,
such as over-the-air software updates or when off-line sensors accumulate
measurements that have to be quickly transferred when there is a connectivity
opportunity.
</t>
<t>Since RDC introduces inactive intervals in energy-constrained devices, it reduces
the throughput that can achieved when communicating with such devices. There exists
a trade-off between the achievable throughput and energy consumption.</t>
</section>
<section title="Radio interface tuning">
<t>The parameters controlling the radio duty cycle have to be carefully tuned to achieve the intended application and/or network requirements. On the other hand, upper layers should take into account the expected latency and/or throughput behavior due to RDC. The next subsection
provides details on key parameters controlling RDC mechanisms, and thus fundamental
trade-offs, for various examples of relevant low-power radio technologies.</t>
</section>
<section title="Power save services available in example low-power radios">
<t>This subsection presents power save services and techniques used in a 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 technology, the reader may refer to the literature or to the corresponding specifications.</t>
<section title="Power Save Services Provided by IEEE 802.11">
<t>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 state. While the station is
sleeping, the AP buffers any frames that should be sent to the sleeping station. The
station wakes up every Listen Interval (which can be a multiple of the Beacon
Interval) in order to receive beacons. The AP signals in the beacon whether there 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. Otherwise, the station may send a
message requesting the transmission of the buffered data and stay awake in receive
mode.</t>
<t>IEEE 802.11v <xref target="IEEE80211v"/> further defines mechanisms and
services for power save of stations/nodes that include flexible
multicast service (FMS), proxy ARP advertisement, extended sleep
modes, traffic filtering. It would be useful if upper layer protocols
knows such capabilities provided by the lower layer, so that they can
coordinate with each other.</t>
<t>These services include:</t>
<t>Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to
indicate that the non-AP station (STA) will not receive ARP frames.
The Proxy ARP capability enables the non-AP STA to remain in
power-save for longer periods of time.</t>
<t>Basic Service Set (BSS) Max Idle Period management enables an AP to
indicate a time period during which the AP does not disassociate a STA
due to non-receipt of frames from the STA. This supports improved STA
power saving and AP resource management.</t>
<t>FMS: A service in which a non-access point (non-AP) station (STA)
can request a multicast delivery interval longer than the delivery
traffic indication message (DTIM) interval for the purposes of
lengthening the period of time a STA may be in a power save state.</t>
<t>Traffic Filtering Service (TFS): A service provided by an access
point (AP) to a non-AP station (STA) that can reduce the number of
frames sent to the non-AP STA by not forwarding individually addressed
frames addressed to the non-AP STA that do not match traffic filters
specified by the non-AP STA.</t>
<t>Using the above services provided by the lower layer, the
constrained nodes can achieve either client initiated power save (via
TFS) or network assisted power save (Proxy-ARP, BSS Max Idel Period
and FMS).</t>
<t>Upper layer protocols would better synchronize with the parameters
such as FMS interval and BSS MAX Idle Period, so that the wireless
transmissions are not triggered periodically.</t>
</section>
<section title="Power Save Services Provided by Bluetooth LE">
<t>Bluetooth LE is a wireless low-power communications
technology that is the hallmark component of the Bluetooth 4.0, 4.1 and 4.2
specifications <xref target="Bluetooth42"/>. BT-LE has been designed for the goal of ultra-low-power
consumption. Currently, it is possible to run IPv6 over Bluetooth LE networks
by using a 6LoWPAN variant adapted to BT-LE <xref
target="I-D.ietf-6lowpan-btle"/>.</t>
<t>Bluetooth LE networks comprise a master and one or more slaves which are
connected to the master. The Bluetooth LE master is assumed to be a
relatively powerful device, whereas a slave is typically a constrained
device (e.g. a class 1 device).</t>
<t>Medium access in Bluetooth LE is based on a TDMA scheme which is
coordinated by the master. This device determines the start of
connection events, in which communication between the master and a
slave takes place. At the beginning of a connection event, the master
sends a poll message, which may encapsulate data, to the slave. The
latter must send a response, which may also contain data. The master
and the slave may continue exchanging data until the end of the
connection event. The next opportunity for communication between the
master and the slave will be in the next connection event scheduled
for the slave.</t>
<t>The time between consecutive connection events is defined by the
connInterval parameter, which may range between 7.5 ms and 4 s. The
slave may remain in sleep mode since the end of its last connection
event until the beginning of its next connection event. Therefore,
Bluetooth LE is duty-cycled by nature. Furthermore, after having replied to
the master, a slave is not required to listen to the master (and thus
may keep the radio in sleep mode) for connSlaveLatency consecutive
connection events. connSlaveLatency is an integer parameter between 0
and 499 which should not cause link inactivity for more than
connSupervisionTimeout time. The connSupervisionTimeout parameter is
in the range between 100 ms and 32 s.</t>
<t>Upper layer protocols should take into account the medium access
and duty-cycling behavior of Bluetooth LE. In particular, connInterval,
connSlaveLatency and connSupervisionTimeout determine the time between
two consecutive connection events for a given slave. The upper layer
packet generation pattern and rate should be consistent with the
settings of the aforementioned parameters (and vice versa).</t>
</section>
<section title="Power Save Services in IEEE 802.15.4">
<t>IEEE 802.15.4 is a family of standard radio interfaces for
low-rate, low-power wireless networking <xref
target="fifteendotfour"/>. Since the 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 application domains and
has been a primary target technology of various IETF working groups
such as 6LoWPAN <xref target="RFC6282"/>,<xref
target="RFC6775"/>,<xref target="RFC4944"/> and 6TiSCH <xref
target="I-D.ietf-6tisch-architecture"/>. IEEE 802.15.4 specifies PHY
and MAC layer functionality.</t>
<t>IEEE 802.15.4 defines three roles called device, coordinator and
PAN coordinator. The device role is adequate for nodes that do not
implement the complete IEEE 802.15.4 functionality, and is mainly
targeted for constrained nodes with a limited energy source. The
coordinator role includes synchronization capabilities and is suitable
for nodes that do not suffer severe constraints (e.g. a mains-powered
node). The PAN coordinator is a special type of coordinator that acts
as a principal controller in an IEEE 802.15.4 network.</t>
<t>IEEE 802.15.4 has mainly defined two types of networks depending on
their configuration: beacon-enabled and nonbeacon-enabled networks. In
the first network type, coordinators periodically transmit beacons.
The time between beacons is divided in three main parts: the
Contention Access Period (CAP), the Contention Free Period (CFP) and
an inactive period. In the first period, nodes use slotted CSMA/CA for
data communication. In the second one, a TDMA scheme controls medium
access. During the idle period, communication does not take place,
thus the inactive period is a good opportunity for nodes to turn the
radio off and save energy. The coordinator announces in each beacon
the list of nodes for which data will be sent in the subsequent
period. Therefore, devices may remain in sleep mode by default and
wake up periodically to listen to the beacons sent by their
coordinator. If a device wants to transmit data, or learns from a
beacon that it is an intended destination, then it will exchange
messages with the coordinator and 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 message.</t>
<t>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
configured. The parameters that control these times are called
macBeaconOrder and macSuperframeOrder, respectively. As an example,
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
s.</t>
<t>In the beaconless mode, nodes use unslotted CSMA/CA for data
transmission. The device may be in sleep mode by default and may
activate its radio to either i) request to the coordinator whether
there is pending data for the device, or ii) to transmit data to the
coordinator. The wake-up pattern of the device, if any, is out of the
scope of IEEE 802.15.4.</t>
<t>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 assume the same role. In this case, data transmission can happen
at any moment. Nodes must have their radio in receive mode, and be
ready to listen to the medium by default (which for battery-enabled
nodes may lead to a quick battery depletion), or apply synchronization
techniques. The latter are out of the scope of IEEE 802.15.4.</t>
<t>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 include mechanisms for low energy consumption. Among these,
the Time-Slotted Channel Hopping (TSCH) is an outstanding mode which
offers robust features for industrial environments, among others. In
order to provide the functionality needed to enable IPv6 over TSCH,
the 6TiSCH working group has been recently created. TSCH is based on a
TDMA schedule whereby a set of time slots are used for frame
transmission and reception, and other time slots are unscheduled. The
latter time slots may be used by a dynamic scheduling mechanism,
otherwise nodes may keep the radio off during the unscheduled time
slots, thus saving energy. The minimal schedule configuration
specified in <xref target="I-D.ietf-6tisch-minimal"/> comprises 101
time slots, whereby 95 of these time slots are unscheduled and the
time slot duration is 15 ms.</t>
<t>Other 802.15.4e modes, which are in fact designed for low energy, are the previously mentioned CSL and RIT.</t>
</section>
<section title="Power Save Services in DECT ULE">
<t>DECT Ultra Low Energy (DECT ULE) is a wireless technology building on the key
fundamentals of traditional DECT / CAT-iq <xref target="EN300"/> but with specific
changes to significantly reduce the power consumption on the expense of data
throughput as specified in <xref target="TS102"/>. DECT ULE devices typically operates on
special power optimized silicon, but can connect to a DECT Gateway supporting
traditional DECT / CAT-iq for cordless telephony and data as well as the DECT ULE
extensions. It is possible to run IPv6 over DECT ULE by using a 6LoWPAN variant
adapted for DECT ULE <xref target="I-D.ietf-6lo-dect-ule"/>.</t>
<t>DECT terminology operates with two major role definitions: The Portable Part (PP) is
the power constrained device, while the Fixed Part (FP) is the Gateway or base
station in a star topology. DECT is operating in license free and reserved frequency
bands based on TDMA/FDMA and TDD using dynamic channel allocation for interference
avoidance. It provides good indoor (~50 m) and outdoor (~300 m) coverage. It is using
a frame length of 10 ms, which is divided into 24 timeslots and it is supporting
connection oriented, packet data and connection less services.</t>
<t>The FP usually transmits a so-called dummy bearer (beacon) that is used to broadcast
synchronization, system and paging information. The slot/carrier position of this
dummy bearer can automatically be reallocated in order to avoid mutual interference
with other DECT signals.</t>
<t>At MAC level DECT ULE communications between FP and PP are initiated by the PP. A FP
can initiate communication indirectly by sending paging signal to a PP. The PP
determines the timeslot and frequency on which the communication between FP and PP
takes place. The PP verifies the radio timeslot/frequency position is unoccupied
before it initiates its transmitter. An access-request message, which usually
carries data, is sent to the FP. The FP sends a confirm message, which also may
carry data. More data can be sent in subsequent frames. A MAC level automatic
retransmission scheme improves data transfer reliability significant. A segmentation
and reassembly scheme supports transfer of larger higher layer SDUs and provides
data integrity check. The DECT ULE packet data service ensures data integrity,
proper sequencing, duplicate protection, but does not guaranteed delivery. Higher
layers protocols have to take this into considerations. </t>
<t>The FP may send paging information to PPs to trigger connection setup and indicate
required service type. The interval between paging 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 interval is defined by the PP application. For short sleep intervals
(below ~10 seconds) the PP may be able to retain synchronization to the FP dummy bearer
and only turn on the receiver during the expected timeslot. For longer sleep
intervals the PP can't keep synchronization and has to search for and resynchronize
to the FP dummybearer. Hence, longer sleep interval reduces the average energy
consumption, but adds a energy consumption penalty for acquiring synchronization to
the FP dummy bearer. The PP can obtain all information to determine paging and
acquire synchronization information in a single reception of one full timeslot.</t>
<t> Packet data latency is normally 30 ms for short packets (below or equal to 32
octets), however if retry and back-off scenarios occur, the latency is increased.
The latency can actually be reduced to about 10 ms by doing energy consuming RSSI
scanning in advance. In the direction from FP to PP the latency is usually increased
by the used paging interval and the sleep interval. The MAC layer can piggyback
commands to improve efficiency (reduce latency) of higher layer protocols. Such
commands can instruct the PP to initiate a new packet transfer in N frames without
the need for resynchronization and listening to paging or instruct the PP to stay in
a higher duty cycle paging detection mode.</t>
<t>The DECT ULE technology allows per PP configuration of paging interval, MTU size,
reassembly window size and higher layer service negotiation and protocol.</t>
</section>
</section>
</section>
<section title="IP Adaptation and Transport Layer">
<t>6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4
MAC&PHY. It was born to fill the gap that the IPv6 layer does not
support fragmentation and assembly of <1280-byte packets while IEEE
802.15.4 only supports a MTU of 127 bytes.</t>
<t>IPv6 is the basis for the higher layer protocols, including both
TCP/UDP transport and applications. So they are quite ignorant of the
lower layers, and are almost neutral to the energy-efficiency
problem.</t>
<t>What the network stack can optimize is to save the computing power.
For example the Contiki implementation has multiple cross layer
optimizations for buffers and energy management, e.g., the computing and
validation of UDP/TCP checksums without the need of reading IP headers
from a different layer. These optimizations are software implementation
techniques, and out of the scope of IETF and the LWIG working group.</t>
<t>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 <xref
target="I-D.ietf-6man-impatient-nud"/>.</t>
</section>
<section title="Routing Protocols ">
<t>The routing protocol designed by the IETF for constrained
environments is called RPL <xref target="RFC6550"/>. As a routing
protocol, RPL has to exchange messages periodically and keep routing
states for each destination. RPL is optimized for the many-to-one
communication pattern, where network nodes primarily send data towards
the border router, but has provisions for any-to-any routing as
well.</t>
<t>The authors of the Powertrace tool <xref target="Powertrace"/>
studied the power profile of RPL. It divides the routing protocol into
control and data traffic. The control channel uses ICMP messages to
establish and maintain the routing states. The data channel is any
application that uses RPL for routing packets. The study has shown that
the power consumption of the control traffic goes down over time in a relatively stable network. The study also reflects that the
routing protocol should keep the control traffic as low as possible to
make it energy-friendly. The amount of RPL control traffic can be tuned
by setting the Trickle algorithm parameters (i.e. Imin, Imax and k) to
adequate values. However, there exists a trade-off between energy
consumption and other performance parameters such as network convergence
time and robustness.</t>
<t>RFC 6551 <xref target="RFC6551"/> defines routing metrics and constraints to be used by RPL in route computation. Among others, RFC 6551 specifies a Node Energy object that allows to provide information related to node energy, such as the energy source type or the estimated percentage of remaining energy. Appropriate use of energy-based routing metrics may help to balance energy consumption of network nodes, minimize network partitioning and increase network lifetime.</t>
</section>
<section title="Application Layer">
<section title="Energy efficient features in CoAP">
<t>CoAP <xref target="RFC7252"/> is designed as a RESTful
application protocol, connecting the services of smart devices to the
World Wide Web. CoAP is not a chatty protocol, it provides basic
communication services such as service discovery and GET/POST/PUT/DELETE
methods with a binary header.</t>
<t>The energy-efficient design is implicitly included in the CoAP
protocol design. CoAP uses a fixed-length binary header of only four bytes that may be followed by binary options. To reduce regular and frequent queries of the
resources, CoAP provides an observe mode, in which the requester
registers its interest of a certain resource and the responder will
report the value whenever it was updated. This reduces the request
response round trips while keeping information exchange a ubiquitous
service and, most importantly, it allows an energy-constrained server to remain in sleep mode during the period between observe notification transmissions.</t>
<t>Furthermore, <xref target="RFC7252"/> defines CoAP proxies which can cache resource representations previously provided by sleepy CoAP servers. The proxies themselves may respond to client requests if the corresponding server is sleeping and the resource representation is recent enough. Otherwise, a proxy may attempt to obtain the resource from the sleepy server.</t>
</section>
<section title="Sleepy node support">
<t>Beyond these features of CoAP, there have been a number of proposals to further support sleepy nodes at the application layer by leveraging CoAP mechanisms. A good summary of such proposals can be found in <xref
target="I-D.rahman-core-sleepy-nodes-do-we-need"/>. The different approaches include exploiting the use of proxies, leveraging the Resource Directory <xref target="I-D.ietf-core-resource-directory"/> or signaling when a node is awake to the interested nodes. A more recent work defines publish-subscribe and message queuing extensions to CoAP and the Resource Directory in order
to support devices that spend most of their time in a sleeping state <xref
target="I-D.koster-core-coap-pubsub"/>. As of the writing, none of these proposals has been adopted by the CoRE working group.</t>
<t>In addition to the work within the scope of CoAP to support sleepy nodes, other
specifications define application layer functionality for the same purpose. The
Lightweight Machine-to-Machine (LWM2M) specification from the Open Mobile Alliance
(OMA) defines a Queue Mode whereby an LWM2M Server queues requests to an LWM2M
Client until the latter (which may often stay in sleep mode) is online. LWM2M
functionality operates on top of CoAP.</t>
<t>On the other hand, oneM2M defines a CoAP binding with an application layer mechanism
for sleepy nodes.</t>
</section>
<section title="CoAP timers">
<t>CoAP offers mechanisms for reliable communication between two CoAP
endpoints. A CoAP message may be signaled as a confirmable (CON)
message, and an acknowledgment (ACK) is issued by the receiver if the
CON message is correctly received. The sender starts a Retransmission
TimeOut (RTO) for every CON message sent. The initial RTO value is
chosen randomly between 2 and 3 s. If an RTO expires, the new RTO value
is doubled (unless a limit on the number of retransmissions has been
reached). Since duty-cycling at the link layer may lead to long latency
(i.e. even greater than the initial RTO value), CoAP RTO parameters
should be tuned accordingly in order to avoid spurious RTOs which would
unnecessarily waste node energy and other resources.</t>
</section>
</section>
<section title="Summary">
<t>We summarize the key takeaways in this document:
</t>
<t><list style="letters">
<t>Internet protocols designed by IETF can be considered as the
customer of the lower layers (PHY, MAC, and Duty-cycling).
To save power consumption,
it is recommended to synergize with the lower layer other than treating the lower layer as a black box.</t>
<!--
<t>The IETF has developed multiple protocols for constrained
networked devices. A lot of implicit energy efficient design
principles have been used in these protocols. The latter should be fine-tuned to
exploit the collaboration with the lower layer protocols. Layers should offer
interfaces that can be exploited by other layers in order to optimize global
protocol stack performance.</t>
-->
<t> It is always useful to compresss the protocol headers in order to reduce the transmission/reception power.
This design principles have been employed by many protocols in 6Lo and CoRE working group.
</t>
<t>Broadcast and non-synchronzed transmissions consume more than other TX/RX operations.
If protocols must use these ways to collect information, reduction of their usage by aggregating similar messages together will be helpful in saving power. </t>
<t>
Saving power by sleeping occasionally is used widely. Reduction of states is also an effective method to
be energy efficient.</t>
</list></t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<!-- Possibly a 'Contributors' section ... -->
<section title="Contributors">
<t>Jens T. Petersen, RTX, contributed the section on power save services in DECT ULE.</t>
</section>
<section anchor="ACKs" title="Acknowledgments">
<t>Carles Gomez has been supported by Ministerio de Economia y
Competitividad and FEDER through project TEC2012-32531.</t>
<t>Authors would like to thank the review and feedback from a number of
experts in this area: Carsten Bormann, Ari Keranen, Hannes Tschofenig, Dominique Barthel.</t>
<t>The text of this document was improved based on IESG Document Editing
session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to
initiate this facilities.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document has no IANA requests.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document discusses the energy efficient protocol design, and
does not incur any changes or challenges on security issues besides what
the protocol specifications have analyzed.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<reference anchor="IEEE80211v">
<front>
<title>Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) specifications, Amendment 8: IEEE 802.11
Wireless Network Management.</title>
<author fullname="IEEE Standard for Information Technology"
surname="IEEE">
<organization/>
</author>
<date day="9" month="February" year="2012"/>
</front>
</reference>
<reference anchor="Bluetooth42">
<front>
<title>Bluetooth Core Specification Version 4.2</title>
<author fullname="Bluetooth Special Interest Group" initials="" surname="">
<organization/>
</author>
<date year="2014"/>
</front>
</reference>
<reference anchor="fifteendotfour">
<front>
<title>802.15.4-2011</title>
<author fullname="IEEE Computer Society" initials="" surname="">
<organization/>
</author>
<date year="2011"/>
</front>
</reference>
<?rfc include='reference.RFC.2119.xml'?>
<?rfc include='reference.RFC.4944.xml'?>
<?rfc include='reference.RFC.6282.xml'?>
<?rfc include='reference.RFC.6550.xml'?>
<?rfc include='reference.RFC.6551.xml'?>
<?rfc include='reference.RFC.6690.xml'?>
<?rfc include='reference.RFC.6775.xml'?>
<?rfc include='reference.RFC.7228.xml'?>
<?rfc include='reference.RFC.7252.xml'?>
<reference anchor="EN300">
<front>
<title>"Digital Enhanced Cordless Telecommunications
(DECT); Common Interface (CI);"</title>
<author fullname="ETSI" initials="" surname="">
<organization/>
</author>
<date year="2013"/>
</front>
</reference>
<reference anchor="TS102">
<front>
<title>"Digital Enhanced Cordless Telecommunications
(DECT); Ultra Low Energy (ULE); Machine to Machine
Communications; Part 1: Home Automation Network (phase
1)"</title>
<author fullname="ETSI" initials="" surname="">
<organization/>
</author>
<date year="2013"/>
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<reference anchor="Powertrace">
<front>
<title>Powertrace: Network-level Power Profiling for Low-power
Wireless Networks</title>
<author fullname="Adam Dunkels" initials="" surname="Dunkels">
<organization/>
</author>
<author fullname="Joakim Eriksson" surname="Eriksson">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Niclas Finne" surname="Finne">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Nicolas Tsiftes" surname="Tsiftes">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date month="March" year="2011"/>
</front>
</reference>
<reference anchor="Announcementlayer">
<front>
<title>The Announcement Layer: Beacon Coordination for the Sensornet
Stack. In Proceedings of EWSN 2011</title>
<author fullname="Adam Dunkels" initials="A.D" surname="Dunkels">
<organization/>
</author>
<date/>
</front>
</reference>
<reference anchor="ContikiMAC">
<front>
<title>The ContikiMAC Radio Duty Cycling Protocol, SICS Technical
Report T2011:13</title>
<author fullname="Adam Dunkels" initials="A.D" surname="Dunkels">
<organization/>
</author>
<date month="December" year="2011"/>
</front>
</reference>
<reference anchor="AN053">
<front>
<title>Measuring power consumption with CC2430 and Z-Stack</title>
<author fullname="B. Selvig" initials="B." surname="Selvig">
<organization/>
</author>
<date/>
</front>
</reference>
<?rfc include='reference.I-D.ietf-lwig-terminology'?>
<?rfc include='reference.I-D.ietf-core-coap'?>
<?rfc include='reference.I-D.kovatsch-lwig-class1-coap'?>
<?rfc include='reference.I-D.ietf-6lowpan-btle'?>
<?rfc include='reference.I-D.ietf-6man-impatient-nud'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-minimal'?>
<?rfc include='reference.I-D.rahman-core-sleepy-nodes-do-we-need'?>
<?rfc include='reference.I-D.ietf-core-resource-directory'?>
<?rfc include='reference.I-D.ietf-6lo-dect-ule'?>
<?rfc include='reference.I-D.koster-core-coap-pubsub'?>
<!-- A reference written by by an organization not a person. -->
</references>
<!-- -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:53:16 |