RFC 8352

Energy-Efficient Features of Internet of Things Protocols

📅 published April 2018, from ietf

RFC 8352 🎀: Energy-Efficient Features of Internet of Things Protocols

okay bestie, this is RFC 8352 🔋✨ It's titled Energy-Efficient Features of Internet of Things Protocols, and it was published in April 2018 as an Informational doc, so it's for info and not a standards track spec 💅 The ISSN is 2070-1721. The authors are C. Gomez (UPC), M. Kovatsch (ETH Zurich), H. Tian (China Academy of Telecommunication Research), and Z. Cao, Ed. (Huawei Technologies). That "Ed." means Z. Cao was the editor 🫶 The header doesn't list any Obsoletes or Updates, so it doesn't replace or update any other RFC 🦋

Abstract 🌈

this doc is all about the challenges of keeping protocols energy-efficient on constrained devices, plus the things people actually do to deal with them 🔋 it breaks down the main link-layer techniques for saving energy, and it shows how those techniques affect upper-layer protocols, so everything can work together and behave efficiently 🧚 it also gives you an overview of the energy-saving mechanisms at each layer of the IETF protocol suite for constrained-node networks 💜

Status of This Memo 🍓

this doc is not an Internet Standards Track spec. it's published for informational purposes 💅

this doc is a product of the IETF 🌸 it reflects the consensus of the IETF community, got public review, and was approved for publication by the IESG. not every doc the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 7841 for more on that 🧐

for the latest status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8352 🔗

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were in effect on the publication date. please read these carefully, since they explain your rights and restrictions for this doc 📜 any Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶

Table of Contents 🗂️

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

1. Introduction 🌸

network systems that monitor the physical world have tons of battery-powered or energy-harvesting devices 🔋 for example, in an environmental monitoring system or a temperature and humidity monitoring system, there may not always be a sustained power supply for the potentially large number of constrained devices 😭 in those deployments, it's necessary to optimize how much energy the constrained devices use 💖 this doc describes techniques that are common at Layer 2 and Layer 3, and it points out why higher layers need to be aware of what lower layers can do 🧚

so many research efforts have looked at this "energy efficiency" problem 🔬 most of that work focuses on optimizing a system's power use in certain deployment scenarios, or on how an existing network function, like routing or security, could be more energy efficient 🙈 only a few efforts have focused on energy-efficient designs for IETF protocols and standardized network stacks for these constrained devices [CLASS1-CoAP] 👑

the IETF has built a suite of Internet protocols that suit constrained devices, including IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) [RFC6282] [RFC6775] [RFC4944], the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252] 🦋 this doc tries to sum up the design considerations for making the IETF constrained protocol suite as energy efficient as possible ✨ it doesn't give detailed, systematic solutions to the energy-efficiency problem, but it does sum up the design efforts and analyze the design space 🎀 specifically, it gives an overview of the techniques lower layers use to save energy and how those can affect upper layers 💅 that's why cross-layer interaction is considered in this doc from that specific point of view 🫶 giving further design recommendations that go beyond the layered protocol architecture is out of scope here 🙅‍♀️

after going through the energy-efficient designs of each layer, we wrap up with some overall conclusions 🌈 the lower-layer communication optimization is the key part of energy-efficient design, but protocol design at the upper layers is also important for making a device energy efficient 💜

1.1. Terminology 🧚

terms used in this doc are defined in [RFC7228] [CNN-TERMS] 📖

ok that's Part 1 of 6, bestie! more parts are coming, so stay tuned 💖🫶

  1. Overview

Okay so bestie, this section is where the IETF goes "we built a whole new lightweight internet stack for tiny devices" and I'm obsessed 🦋✨. Traditional stacks were giving HTTP, FTP and SNMP on top of TCP or UDP, then IPv6 and routing. The lightweight version swaps in CoAP as the application layer and 6LoWPAN as the adaptation layer so IPv6 can run over IEEE 802.15.4 [IEEE802.15.4] and Bluetooth Low Energy (also called Bluetooth LE and BTLE) 🌸. Routing comes from RPL, and neighbor discovery comes from 6LoWPAN Neighbor Discovery (6LoWPAN-ND) 💅. The 6lo Working Group is also adapting 6LoWPAN for other stuff like ITU-T G.9959 [G9959], DECT ULE [TS102], BACnet MS/TP [MSTP] and Near Field Communication [NFC] 🫶.

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

Figure 1: Traditional and Lightweight Internet Protocol Stack

Now the vibe check 🔥: there are loads of published studies measuring wireless platforms [Powertrace]. The example here is the energy profile of common operations on a popular sensor node, the Tmote Sky running ContikiMAC [ContikiMAC] as its Radio Duty Cycling algorithm. Other reports (e.g., [AN079]) back this up, and the takeaway is that optimized transmission and reception cost about the same energy 😭. For IEEE 802.15.4 [IEEE802.15.4] and Ultra WideBand (UWB) links, transmitting can actually be even cheaper than receiving 🙈. Broadcast and non-synchronized transmissions are the energy villains because they have to grab the medium for a long time 💀.

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

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

Last bit, at the Physical layer 🦋: one way to cut energy use is to lower the device's transmit power, as long as the intended next hop(s) is still in range. Say node A needs to send to node B. A smart move is to use an intermediate device, like node C, as a message forwarder. If d is the distance between A and B, and free-space propagation applies (path loss is proportional to d^2), then putting C right in the middle (d/2 from both A and B) cuts the minimum transmit power for A (and for C) by a factor of 4. The catch? That needs extra devices, a routing solution, and it adds transmission delay between A and B 😅.

3. Medium Access Control and Radio Duty Cycling ✨

Here's the big tea: communication and power use are totally intertwined 🍓. The radio is usually the biggest power hog, and just not transmitting isn't enough, because the radio can burn as much power listening as it does sending. That's idle listening: the radio sits in receive mode, ready for any message, even when nothing is being sent to that device. It can waste a huge amount of energy 💀. So to save power, the radio has to be switched completely off, which is what duty cycling means, and you want to do it as much as possible 🫶. With duty cycling, a device on a common button battery can last on the order of years. Without it, that battery might be dead in a few days or even hours 😭.

Duty cycling is what devices using the P1 strategy [RFC7228] usually do, since they need to communicate on a fairly frequent basis 💅. There's also a more aggressive option, the P0 (Normally-off) strategy, where devices sleep for very long periods and only communicate now and then. The catch is they spend energy on network reattachment procedures 🙈.

From the Medium Access Control (MAC) and Radio Duty Cycling (RDC) point of view, all the upper-layer protocols (routing, RESTful communication, adaptation and management flows) are just applications 🧚. The duty-cycling algorithm is the key to wireless energy efficiency, so it syncs up transmission and/or reception requests coming from the higher layers 👑.

MAC and RDC are not in the scope of the IETF, but lower-layer designers and chipset manufacturers really do care about saving energy 🌈. Once you know how those lower layers behave, you can design protocols that vibe with them. The IETF protocols in the following sections are the customers of those lower layers 💖.

3.1. Techniques for Radio Duty Cycling

Three main RDC techniques are covered here. More than one of them may be available, or they can even be combined in a specific radio technology 🎀:

  • a) Channel sampling: The radio interface periodically checks the channel for very short intervals (so, a low duty cycle) to catch incoming transmissions 👀. To make sure a receiver can correctly receive a data unit, the sender may prepend a preamble lasting at least the sampling period. The other option is for the sender to repeatedly transmit the data unit instead of sending a preamble first. Once a receiver detects a transmission, it may stay awake until the whole data unit arrives ⭐. Radio technologies using preamble sampling include ContikiMAC, the Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e [IEEE802.15.4], and the Frequently Listening (FL) mode of ITU-T G.9959 [G9959] 🦋.
  • b) Scheduled transmissions: The device knows exactly when it should be awake (during some time interval) to receive data. Otherwise it can stay in sleep mode 😴. When communication is attempted is decided through some form of negotiation between the devices involved. That negotiation may happen per transmission or per session/connection 🫶. Bluetooth Low Energy (Bluetooth LE) is an example of a radio technology built on this mechanism 💜.
  • c) Listen after send: The node stays in sleep mode by default, then wakes up and polls a sender (which must be ready to receive a poll message) for pending transmissions 🌸. After sending the poll, the node stays in receive mode, ready for a possible incoming transmission. After a certain time interval, it may go back to sleep 💤. This is used in the Receiver Initiated Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4], and in data transmission between a coordinator and a device in the 2003 version of IEEE 802.15.4 [IEEE802.15.4] 🍓.

3.2. Latency and Buffering

The latency of sending a data unit to a duty-cycled device is equal to or greater than the latency of sending to an always-on device. So duty cycling creates a trade-off between energy consumption and latency ⚖️. Beyond that latency increase, RDC may also add latency variance, since the increase is a random variable (uniformly distributed if duty cycling follows a periodic behavior) 🎢.

Because of that latency increase, a sender waiting for a transmission opportunity may need to store later outgoing packets in a buffer 📦. That buffering raises memory requirements and can add queuing wait times. Those waits add to packet transmission delay and make buffer overflow more likely, which leads to losses 😭.

3.3. Throughput

Throughput usually isn't the main concern in constrained-node network applications 🙃. It still matters for some services, though, like over-the-air software updates, or when offline sensors pile up measurements that need to be transferred quickly once there's a chance to connect 📡.

RDC adds inactive intervals to energy-constrained devices, so it lowers the throughput you can get when talking to them 🐢. There's a real trade-off between achievable throughput and energy consumption 💅.

3.4. Radio Interface Tuning

The parameters that control the radio duty cycle have to be tuned carefully to meet the intended application and/or network requirements 🎯. Upper layers should also account for the expected latency and/or throughput behavior caused by RDC 🧠. The next subsection breaks down the key parameters controlling RDC mechanisms, and the fundamental trade-offs that come with them, for various examples of relevant low-power radio technologies 🌟.

3.5. Packet Bundling ✨

okay so here's another trick that might help your radio save energy 🔋 it's called packet bundling 🎀 it's available in a few radio interfaces (like LTE and some 802.11 variants), and it lets you squish several small packets together into one big packet 📦 that means way less header and communication overhead, so it's giving efficiency 💅

3.6. Power Save Services Available in Example Low-Power Radios 🦋

this subsection is all about the power save services and techniques in a few wireless low-power radios: IEEE 802.11 [IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4] 🌸 if you want the full tea on any one of these, go read the literature or the actual specs 📚

3.6.1. Power Save Services Provided by IEEE 802.11 💜

IEEE 802.11 [IEEE802.11] defines the Power Save Mode (PSM) 😴 this is where a station can tell an Access Point (AP) that it's about to go to sleep. while the station is sleeping, the AP buffers any frames that should be sent to it 📥 the station wakes up every listen interval (which can be a multiple of the beacon interval) to catch the beacons 📡 and the AP uses a beacon field to say whether there's data waiting for the station or not 👀

if there's nothing to be sent to the station, it can go right back to sleep 💤 if there is something, the station can send a message asking for the buffered data to be transmitted, and then it stays awake in receive mode ✨

IEEE 802.11v [IEEE802.11] goes even further and adds mechanisms and services for power save of stations/nodes, including Flexible Multicast Service (FMS), Proxy ARP advertisement, extended sleep modes, and traffic filtering 🧚 the upper-layer protocol knowing about these capabilities, which the lower layer provides, makes everything interwork better 🫶

here's what these services include 💅

  • Proxy ARP: the Proxy ARP capability lets an Access Point (AP) indicate that the non-AP station (STA) will not receive ARP frames. this lets the non-AP STA stay in power save mode for longer periods of time 😌
  • Basic Service Set (BSS) Max Idle Period Management: lets an AP indicate a time period during which it won't disassociate a STA just because it hasn't received frames from that STA 🙈 this supports improved STA power saving and AP resource management, which is honestly iconic 👑
  • FMS: a service where a non-AP STA can request a multicast delivery interval that's longer than the Delivery Traffic Indication Message (DTIM) interval, so it can stretch out how long it stays in a power save state 🌈
  • Traffic Filtering Service (TFS): a service an AP provides to a non-AP STA to cut down the number of frames sent to it. the AP drops individually addressed frames that don't match the traffic filters the STA specified 🗑️

using the services above from the lower layer, constrained nodes can get either client-initiated power save (via TFS) or network-assisted power save (Proxy ARP, BSS Max Idle Period, and FMS) 🦋

upper-layer protocols should sync up with parameters like the FMS interval and the BSS MAX Idle Period so the wireless transmissions aren't triggered periodically 🔥

3.6.2. Power Save Services Provided by Bluetooth LE 💙

Bluetooth LE is a wireless low-power communications technology and the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 specifications [Bluetooth42] ✨ it was designed with ultra-low power consumption as the goal 🔋 IPv6 can run over Bluetooth LE networks by using a 6LoWPAN variant adapted to BTLE [RFC7668] 🌐

Bluetooth LE networks have a master and one or more slaves, and the slaves are connected to the master 🧸 the Bluetooth LE master is assumed to be a relatively powerful device, while a slave is typically a constrained device (e.g., a Class 1 device) 🤓

medium access in Bluetooth LE is based on a Time-Division Multiple Access (TDMA) scheme coordinated by the master 🎶 the master decides when connection events start, and those are the moments when the master and a slave actually talk 🗓️ at the beginning of a connection event, the master sends a poll message, which may encapsulate data, to the slave 📨 the slave must send a response, which may also contain data 💬 the master and the slave may keep exchanging data until the end of the connection event 🫶 the next chance for them to communicate is the next connection event scheduled for that slave ⏰

the time between consecutive connection events is set by the connInterval parameter, which may range between 7.5 ms and 4 s 🕰️ the slave may stay in sleep mode from the end of its last connection event until the start of its next one, so Bluetooth LE is duty-cycled by design 🔁 on top of that, after replying to the master, a slave is not required to listen to the master (and so may keep its radio in sleep mode) for connSlaveLatency consecutive connection events 😴 connSlaveLatency is an integer parameter between 0 and 499 that should not cause link inactivity for more than connSupervisionTimeout time 🙏 and the connSupervisionTimeout parameter is in the range between 100 ms and 32 s ⏳

upper-layer protocols should take the medium access and duty-cycling behavior of Bluetooth LE into account 🧠 specifically, 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 those settings (and vice versa) 💖 for example, assume connInterval = 4 seconds, connSlaveLatency = 7 seconds, and connSupervisionTimeout = 32 seconds 🍓 with these settings, communication opportunities between a master and a slave occur during a given interval every 32 seconds 😭 how long that interval lasts depends on several factors, including the number of connected slaves, the amount of data to be transmitted, etc. 📊 in the worst case, only one data unit can be sent from master to slave (and vice versa) every 32 seconds 💀

3.6.3. Power Save Services in IEEE 802.15.4 🌈

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

IEEE 802.15.4 [IEEE802.15.4] defines three roles: device, coordinator, and Personal Area Network (PAN) coordinator 🎭 the device role is adequate for nodes that don't implement the complete IEEE 802.15.4 [IEEE802.15.4] functionality, and it's mainly aimed at constrained nodes with a limited energy source 🔋 the coordinator role includes synchronization capabilities and suits nodes that don't suffer severe constraints (e.g., a mains-powered node) 🔌 the PAN coordinator is a special type of coordinator that acts as the principal controller in an IEEE 802.15.4 [IEEE802.15.4] network 👑

IEEE 802.15.4 [IEEE802.15.4] defines two main types of networks depending on their configuration: beacon-enabled and non-beacon-enabled networks 🗂️ in the beacon-enabled type, coordinators periodically transmit beacons 📣 the time between beacons is divided into three main parts: the Contention Access Period (CAP), the Contention Free Period (CFP), and an inactive period 🧩 during the first part, nodes use slotted Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) for data communication 🗣️ during the second, a TDMA scheme controls medium access 🎶 during the idle period, no communication takes place, so 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 📋 so devices can stay in sleep mode by default and wake up periodically to listen to the beacons from their coordinator ⏰ if a device wants to transmit data, or learns from a beacon that it is an intended destination, it exchanges messages with the coordinator (and so consumes energy) ⚡ one underlying assumption is that when a message is sent to a coordinator, the coordinator's radio will be ready to receive it 📻

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

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 from the coordinator whether there is pending data for the device, or ii) transmit data to the coordinator 📬 the wake-up pattern of the device, if any, is out of the scope of IEEE 802.15.4 [IEEE802.15.4] 🤷‍♀️

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

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

the previously mentioned CSL and RIT are also 802.15.4e modes designed for low energy 🌟

3.6.4. Power Save Services in DECT ULE 🔋

okay so DECT Ultra Low Energy (DECT ULE) is a wireless tech that builds on the core basics of traditional DECT / Cordless Advanced Technology - internet and quality (CAT-iq) [EN300], but with specific changes that seriously cut power consumption, and the trade-off is less data throughput [TS102]. 💖 DECT ULE devices usually run on special power-optimized silicon, but they can connect to a DECT Gateway that supports traditional DECT/CAT-iq for cordless telephony and data, plus the DECT ULE extensions. 🎀 You can even run IPv6 over DECT ULE using a 6LoWPAN variant [RFC8105]. iconic, honestly.

DECT has two main roles. The Portable Part (PP) is the power constrained device, and the Fixed Part (FP) is the Gateway or base station, so it's a star topology 🌟 Because it uses TDMA/FDMA and Time-Division Duplex (TDD) with dynamic channel allocation for interference, DECT operates in license-free and reserved frequency bands. It gives you good indoor (~50 m) and outdoor (~300 m) coverage 🦋 It uses a frame length of 10 ms divided into 24 timeslots, and it supports connection-oriented packet data and connection-less services. so many options, periodt.

The FP usually transmits a so-called dummy bearer (beacon) that broadcasts synchronization, system, and paging information 📡 The slot/carrier position of this dummy bearer can automatically be reallocated so it doesn't mutually interfere with other DECT signals. no beef, just vibes 💅

At the MAC level, DECT ULE communications between FP and PP are initiated by the PP 🙈 The FP can start a communication indirectly by sending a paging signal to a PP. The PP decides the timeslot and frequency where the FP-PP communication happens. Before it turns on its transmitter, the PP checks that the radio timeslot/frequency position is unoccupied ✨ Then an access-request message, which usually carries data, goes to the FP, and the FP replies with a confirm message that may also carry data. More data can be sent in subsequent frames. A MAC-level automatic retransmission scheme really boosts reliability of data transfer 🔥 A segmentation and reassembly scheme supports transfer of larger, higher-layer Service Data Units (SDUs) and gives you data integrity checks. The DECT ULE packet data service ensures data integrity, proper sequencing, and duplicate protection, but it does not guarantee delivery 💀 Higher-layer protocols have to take that into consideration, bestie.

The FP may send paging information to PPs to trigger connection setup and indicate the required service type 🧚 The interval between paging information to a specific PP can be set anywhere from 10 ms to 327 s. The PP may enter sleep mode to save power, and the listening interval is defined by the PP application. For short sleep intervals (below ~10 seconds), the PP may be able to keep 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, so it has to search for, and resynchronize to, the FP dummy bearer. So longer sleep intervals lower the average energy consumption, but they add an energy penalty for acquiring synchronization to the FP dummy bearer. The PP can get all the info it needs to determine paging and acquire synchronization in a single reception of one full timeslot ⭐

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

The DECT ULE technology lets you configure paging interval, MTU size, reassembly window size, and higher-layer service negotiation and protocol on a per-PP basis 🎀

4. IP Adaptation and Transport Layer ✨

okay, 6LoWPAN is the adaptation layer that's designed to support IPv6 over IEEE 802.15.4 [IEEE802.15.4]. It tackles the energy-efficiency problem in three ways 🦋

First, 6LoWPAN provides one fragmentation and reassembly mechanism. It's aimed at the packet size issue in IPv6, and it could also affect energy efficiency 💅 IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that can't carry a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6 [RFC8200]. 6LoWPAN does fragmentation and reassembly below the IP layer to solve this. One benefit of putting fragmentation at a lower layer like 6LoWPAN is that it avoids extra IP headers, since fragmentation at the IP layer produces more IP packets, and each one carries its own IP header 🙈 However, performance can be seriously hurt if IP layer fragmentation is followed by 6LoWPAN fragmentation too (for example, when the upper layer doesn't know about the fragmentation at the 6LoWPAN layer) 😭 One solution is to require that higher layers be aware of lower-layer features and generate packets small enough to avoid fragmentation. In this regard, the Block option in CoAP can be useful when CoAP is used at the application layer [RFC7959].

Secondly, 6LoWPAN swaps computing for communication 🧠 It applies compression of the IPv6 header. Subject to the packet size limit of IEEE 802.15.4 [IEEE802.15.4], a 40-octet-long IPv6 header and an 8 or 20-octet-long UDP and TCP header will eat up even more packet space than the data itself 💀 6LoWPAN provides IPv6 and UDP header compression at the adaptation layer. So the lower layers handle less data, while both the sender and receiver spend more computing power compressing and decompressing packets over the air ⚡ Compression can also be done at higher layers (see Section 6.4).

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

IPv6 underlies the higher-layer protocols, including both TCP/UDP transport and applications. By design, higher-layer protocols don't typically have specific info about the lower layers, so they can't solve the energy-efficiency problem on their own 🌸

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

5. Routing Protocols 🗺️

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

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

RFC 6551 [RFC6551] defines routing metrics and constraints that RPL uses in route computation ✨ Among others, RFC 6551 specifies a Node Energy object that provides information related to node energy, like the energy source type or the estimated percentage of remaining energy 🔋 Appropriate use of energy-based routing metrics may help balance energy consumption across network nodes, minimize network partitioning, and increase network lifetime 💖

6. Application Layer 🦋

6.1. Energy-Efficient Features in CoAP ✨

Okay bestie, CoAP [RFC7252] is a RESTful application protocol that connects smart devices' services to the World Wide Web 🌸. It is not a chatty protocol at all 🤐. It gives you basic communication services like service discovery and GET/POST/PUT/DELETE methods, all with a binary header 🎀.

Energy efficiency is literally part of the CoAP design 🔋. CoAP uses a fixed-length binary header of only four bytes, which may be followed by binary options 💅. To cut down on regular, frequent queries for resources, CoAP has an observe mode 👀. The requester registers its interest in a certain resource, and the responder reports the value whenever it gets updated. This reduces request/response round trips while keeping information exchange an ubiquitous service, and an energy-constrained server can stay in sleep mode between observe notification transmissions 😴🦋.

Also, [RFC7252] defines CoAP proxies that can cache resource representations previously provided by sleepy CoAP servers 🧚. The proxies themselves may respond to client requests if the corresponding server is sleeping and the resource representation is recent enough. Otherwise, a proxy may attempt to obtain the resource from the sleepy server 💖.

CoAP proxy and cache functionality may also be used to perform data aggregation 🍓. This technique lets a node receive data messages (like sensor readings) from other nodes in the network, perform an operation based on the content of those messages, and transmit the result. The operation may simply use one packet to carry readings that would otherwise go in several packets, which cuts down header and transmission overhead. Or it may be a more sophisticated operation, based on mathematical, logical, or filtering principles, which reduces the payload size to be transmitted 🔥.

6.2. Sleepy Node Support 💤

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

Other specifications also define application-layer functionality for the same purpose, outside the scope of CoAP itself 🌈. The Lightweight Machine-to-Machine (LwM2M) specification from the Open Mobile Alliance (OMA) defines a queue mode, where an LwM2M Server queues requests to an LwM2M Client until the latter is online. The Client may often stay in sleep mode, and LwM2M functionality operates on top of CoAP 🫶.

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

6.3. CoAP Timers ⏱️

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 it sends. 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 😤.

Here's the tricky part 🙈: since duty cycling at the link layer may lead to long latency (even greater than the initial RTO value), CoAP RTO parameters should be tuned accordingly. That way you avoid spurious RTOs, which would needlessly waste node energy and other resources.

Heads up: CoAP can also run on top of TCP [RFC8323]. In that case, similar guidance applies to TCP timers. There's even more reason to carefully configure TCP RTO parameters, because [RFC6298] reduced the default initial TCP RTO to 1 second. That may interact more negatively with duty-cycled links than the default CoAP RTO values do 🚨.

6.4. Data Compression 🗜️

Another method for shrinking the data units communicated in constrained-node networks is data compression 📦. It allows you to encode data using fewer bits than the original data representation. Data compression is more efficient at higher layers, particularly before encryption is used. Why? Encryption mechanisms may generate output that contains no redundancy, which makes it almost impossible to reduce the data representation size 🔐. In CoAP, messages may be encrypted using Datagram Transport Layer Security (DTLS), or TLS when CoAP over TCP is used. That's the default mechanism for securing CoAP exchanges 💜.

7. Summary and Conclusions ✨

We summarize the key takeaways of this document 📝:

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

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

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

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

8. IANA Considerations 🗂️

This document has no IANA actions.

9. Security Considerations 🔒

This document discusses energy-efficient protocol design and does not incur any changes or challenges on security issues besides what the protocol specifications have analyzed. Translation: the security analysis lives in the protocol specs, not here 💀.

10. References 📚

The reference entries pick up in the next part 🫶.

10.1. Normative References ✨

okay bestie, these are the docs this whole spec leans on, so they're the ones you have to have open 📚💅

10.2. Informative References 🧠🦋

these ones are the extra reading: super helpful for context, but the spec itself doesn't depend on them 🌸

  • [AN079] Kim, C., "Measuring Power Consumption of CC2530 With Z-Stack", Application Note AN079, SWRA292, September 2012, <http://www.ti.com/lit/an/swra292/swra292.pdf>.
  • [ARCH-6TiSCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-13, November 2017.
  • [CLASS1-CoAP] Kovatsch, M., "Implementing CoAP for Class 1 Devices", Work in Progress, draft-kovatsch-lwig-class1-coap-00, October 2012.
  • [CNN-TERMS] Bormann, C., Ersue, M., Keranen, A., and C. Gomez, "Terminology for Constrained-Node Networks", Work in Progress, draft-bormann-lwig-7228bis-02, October 2017.
  • [CoAP-BROKER] Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)", Work in Progress, draft-ietf-core-coap-pubsub-04, March 2018.
  • [ContikiMAC] Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol", SICS Technical Report T2011:13, December 2011, <http://soda.swedishict.se/5128/>.
  • [CoRE-RD] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, Ed., "CoRE Resource Directory", Work in Progress, draft-ietf-core-resource-directory-13, March 2018.
  • [CRYPTO-SENSORS] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks", Work in Progress, draft-ietf-lwig-crypto-sensors-06, February 2018.
  • [Powertrace] Dunkels, A., Eriksson, J., Finne, N., and N. Tsiftes, "Powertrace: Network-level Power Profiling for Low-power Wireless Networks", SICS Technical Report T2011:05, March 2011, <http://soda.swedishict.se/4112/>.
  • [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014, <https://www.rfc-editor.org/info/rfc7048>.
  • [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
  • [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.
  • [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.
  • [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
  • [SLEEPY-DEVICES] Rahman, A., "Sleepy Devices: Do we need to Support them in CORE?", Work in Progress, draft-rahman-core-sleepy-nodes-do-we-need-01, February 2014.

Acknowledgments 💖

okay the thank-you list is SO important 🫶 Carles Gomez got support from the Spanish Government, FEDER, and the ERDF through projects TEC2012-32531 and TEC2016-79988-P. The authors also want to thank the experts who reviewed the document and gave feedback: Carsten Bormann, Ari Keranen, Hannes Tschofenig, Dominique Barthel, Bernie Volz, and Charlie Perkins. The text got better thanks to an IESG document editing session during IETF 87, and big thanks to Ted Lemon and Joel Jaeggli for kicking it off and running it ✨

Contributors 🎀

Jens T. Petersen, RTX, wrote the section on power save services in DECT ULE, so he gets all the flowers for that one 🌷

Authors' Addresses 🌍

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

Email: carlesgo@entel.upc.edu


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

Email: ietf@kovatsch.net


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

Email: tianhui@ritt.cn


Zhen Cao (editor)
Huawei Technologies
China

Email: zhencao.ietf@gmail.com

that's a wrap on the whole spec, bestie!! 🌈💅👑

📦 where this page comes from