diff options
Diffstat (limited to 'doc/rfc/rfc8352.txt')
| -rw-r--r-- | doc/rfc/rfc8352.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc8352.txt b/doc/rfc/rfc8352.txt new file mode 100644 index 0000000..0fad332 --- /dev/null +++ b/doc/rfc/rfc8352.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Gomez +Request for Comments: 8352 UPC +Category: Informational M. Kovatsch +ISSN: 2070-1721 ETH Zurich + H. Tian + China Academy of Telecommunication Research + Z. Cao, Ed. + Huawei Technologies + April 2018 + + + Energy-Efficient Features of Internet of Things Protocols + +Abstract + + This document describes the challenges for energy-efficient protocol + operation on constrained devices and the current practices used to + overcome those challenges. It summarizes the main link-layer + techniques used for energy-efficient networking, and it highlights + the impact of such techniques on the upper-layer protocols so that + they can together achieve an energy-efficient behavior. The document + also provides an overview of energy-efficient mechanisms available at + each layer of the IETF protocol suite specified for constrained-node + networks. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8352. + + + + + + + + + + + +Gomez, et al. Informational [Page 1] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided 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 + + + + +Gomez, et al. Informational [Page 2] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +1. Introduction + + Network systems for monitoring the physical world contain many + battery-powered or energy-harvesting devices. For example, in an + environmental monitoring system or a temperature and humidity + monitoring system, there may not be 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. In this document, we + describe techniques that are in common use at Layer 2 and at Layer 3, + and we indicate the need for higher-layer awareness of lower-layer + features. + + Many research efforts have studied this "energy efficiency" problem. + Most of this research has focused on how to optimize the system's + power consumption in certain deployment scenarios or how an existing + network function such as routing or security could be more energy + efficient. Only few efforts have focused on energy-efficient designs + for IETF protocols and standardized network stacks for such + constrained devices [CLASS1-CoAP]. + + The IETF has developed a suite of Internet protocols suitable for + such 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 document tries to summarize the design considerations for making + the IETF constrained 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 an overview of the techniques used by the + lower layers to save energy and how these may impact on the upper + layers. Cross-layer interaction is therefore considered in this + document from this specific point of view. Providing further design + recommendations that go beyond the layered protocol architecture is + out of the scope of this document. + + After reviewing the energy-efficient designs of each layer, we + summarize the document by presenting some overall conclusions. + Though the lower-layer communication optimization is the key part of + energy-efficient design, the protocol design at the upper layers is + also important to make the device energy efficient. + +1.1. Terminology + + Terms used in this document are defined in [RFC7228] [CNN-TERMS]. + + + + +Gomez, et al. Informational [Page 3] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +2. Overview + + The IETF has developed protocols to enable end-to-end IP + communication between constrained nodes and fully capable nodes. + This work has expedited the evolution of the traditional Internet + protocol stack to a lightweight Internet protocol stack. As shown in + Figure 1 below, the IETF has developed CoAP as the application layer + and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 + [IEEE802.15.4] and Bluetooth Low Energy (also referred to as + Bluetooth LE and BTLE), with the support of routing by RPL and + efficient neighbor discovery by 6LoWPAN Neighbor Discovery (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 + [G9959], Digital Enhanced Cordless Telecommunications Ultra Low + Energy (DECT ULE) [TS102], Building Automation and Control Networks + Master-Slave/Token-Passing (BACnet MS/TP) [MSTP], and Near Field + Communication [NFC]. + + +-----+ +-----+ +-----+ +------+ + |HTTP | | FTP | |SNMP | | CoAP | + +-----+ +-----+ +-----+ +------+ + \ / / / \ + +-----+ +-----+ +-----+ +-----+ + | 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 + + There are numerous published studies reporting comprehensive + measurements of wireless communication platforms [Powertrace]. As an + example, below we list the energy-consumption profile of the most + common operations involved in communication on a prevalent sensor + node platform. The measurement was based on the Tmote Sky with + ContikiMAC [ContikiMAC] as the Radio Duty Cycling algorithm. From + this and many other measurement reports (e.g., [AN079]), we can see + that the energy consumption of optimized transmission and reception + + + +Gomez, et al. Informational [Page 4] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + are in the same order. For IEEE 802.15.4 [IEEE802.15.4] and Ultra + WideBand (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. + + +---------------------------------------+---------------+ + | 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 + + At the Physical layer, one approach that may reduce the energy + consumption of a device that uses a wireless interface is based on + reducing the device transmit power level, as long as the intended + next hop(s) is still within range of the device. In some cases, if + node A has to transmit a message to node B, a solution to reduce node + A transmit power is to leverage an intermediate device, e.g., node C + as a message forwarder. Let d be the distance between node A and + node B. Assuming free-space propagation, where path loss is + proportional to d^2, if node C is placed right in the middle of the + path between A and B (that is, at a distance d/2 from both node A and + node B), the minimum transmit power to be used by node A (and by node + C) is reduced by a factor of 4. However, this solution requires + additional devices, it requires a routing solution, and it also + increases transmission delay between A and B. + + + + + + + + + +Gomez, et al. Informational [Page 5] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +3. Medium Access Control and Radio Duty Cycling + + In networks, communication and power consumption are interdependent. + The communication device is typically the most power-consuming + component, but merely refraining from transmissions is not enough to + achieve a low power consumption: the radio may consume as much power + in listen mode as when actively transmitting. This illustrates the + key problem known as idle listening, whereby the radio of a device + may be in receive mode (ready to receive any message), even if no + message is being transmitted to that device. Idle listening can + consume a huge amount of energy unnecessarily. To reduce power + consumption, the radio must be switched completely off -- duty-cycled + -- as much as possible. By applying duty cycling, the lifetime of a + device operating on a common button battery may be on the order of + years, whereas otherwise the battery may be exhausted in a few days + or even hours. Duty cycling is a technique generally employed by + devices that use the P1 strategy [RFC7228], which need to be able to + communicate on a relatively frequent basis. Note that a more + aggressive approach to save energy relies on the P0 (Normally-off) + strategy, whereby devices sleep for very long periods and communicate + infrequently, even though they spend energy in network reattachment + procedures. + + From the perspective of Medium Access Control (MAC) and Radio Duty + Cycling (RDC), all upper-layer protocols, such as routing, RESTful + communication, adaptation, and management flows, are applications. + Since the duty-cycling algorithm is the key to energy efficiency of + the wireless medium, it synchronizes transmission and/or reception + requests from the higher layers. + + MAC and RDC are not in the scope of the IETF, yet lower-layer + designers and chipset manufacturers take great care to save energy. + By knowing the behaviors of these lower layers, engineers can design + protocols that work well with them. The IETF protocols to be + discussed in the following sections are the customers of the lower + layers. + +3.1. Techniques for Radio Duty Cycling + + This subsection describes three main RDC techniques. Note that more + than one of these techniques may be available or can even be combined + in a specific radio technology: + + 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 + + + +Gomez, et al. Informational [Page 6] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + 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 [IEEE802.15.4], and the + Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. + + b) Scheduled transmissions: This approach allows a device to know + the particular time at which it should be awake (during some time + interval) in order to receive data. Otherwise, the device may + remain in sleep mode. The decision on the times at which + communication is attempted relies on some form of negotiation + 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. + + c) Listen after send: This technique allows a node to remain in + sleep mode by default, then 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 + and is ready for a potential incoming transmission. After a + certain time interval, the node may go back to sleep. For + example, this technique is used in the Receiver Initiated + Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4] and in + the transmission of data between a coordinator and a device in + the 2003 version of IEEE 802.15.4 [IEEE802.15.4]. + +3.2. Latency and Buffering + + 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 periodic behavior). + + On the other hand, due to the latency increase introduced by duty + cycling, a sender waiting for a transmission opportunity may need to + store subsequent outgoing packets in a buffer. This buffering would + increase memory requirements and potentially incur queuing wait + times. Such wait times would in turn contribute to packet + transmission delay and increase the probability of buffer overflow, + leading to losses. + + + +Gomez, et al. Informational [Page 7] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +3.3. Throughput + + Although throughput is not typically a key concern in constrained- + node network applications, it is indeed important in some services in + such networks, such as over-the-air software updates or when off-line + sensors accumulate measurements that have to be quickly transferred + when there is an opportunity for connectivity. + + Since RDC introduces inactive intervals in energy-constrained + devices, it reduces the throughput that can be achieved when + communicating with such devices. There exists a trade-off between + the achievable throughput and energy consumption. + +3.4. Radio Interface Tuning + + 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. + +3.5. Packet Bundling + + Another technique that may be useful to increase communication energy + efficiency is packet bundling. This technique, which is available in + several radio interfaces (e.g., LTE and some 802.11 variants), allows + for aggregation of several small packets into a single large packet. + Header and communication overhead is therefore reduced. + +3.6. Power Save Services Available in Example Low-Power Radios + + This subsection presents power save services and techniques used in a + few relevant examples of wireless low-power radios: IEEE 802.11 + [IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4]. For a + more detailed overview of each technology, the reader may refer to + the literature or to the corresponding specifications. + +3.6.1. Power Save Services Provided by IEEE 802.11 + + IEEE 802.11 [IEEE802.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, by means of a + beacon field, whether there is data pending for the station or not. + + + +Gomez, et al. Informational [Page 8] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + 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. + + IEEE 802.11v [IEEE802.11] further defines mechanisms and services for + power save of stations/nodes that include Flexible Multicast Service + (FMS), Proxy ARP advertisement, extended sleep modes, and traffic + filtering. Upper-layer protocol's knowledge of such capabilities, + provided by the lower layer, enables better interworking. + + These services include: + + 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 mode for longer periods of time. + + 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. + + FMS: A service in which a non-AP 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. + + Traffic Filtering Service (TFS): A service provided by an AP to a + non-AP STA that can reduce the number of frames sent to the STA by + dropping individually addressed frames that do not match traffic + filters specified by the STA. + + 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 Idle Period, and + FMS). + + Upper-layer protocols should synchronize with the parameters such as + FMS interval and BSS MAX Idle Period so that the wireless + transmissions are not triggered periodically. + + + + + + + + + + +Gomez, et al. Informational [Page 9] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +3.6.2. Power Save Services Provided by Bluetooth LE + + 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 [Bluetooth42]. BTLE has been designed for the goal of + ultra-low power consumption. IPv6 can be run IPv6 over Bluetooth LE + networks by using a 6LoWPAN variant adapted to BTLE [RFC7668]. + + 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). + + Medium access in Bluetooth LE is based on a Time-Division Multiple + Access (TDMA) scheme that 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. + + 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 from the end of its last connection + event until the beginning of its next connection event. Therefore, + Bluetooth LE is duty-cycled by design. 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 that should not cause link + inactivity for more than connSupervisionTimeout time. The + connSupervisionTimeout parameter is in the range between 100 ms and + 32 s. + + 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). + For example, assume connInterval = 4 seconds, connSlaveLatency = + 7 seconds, and connSupervisionTimeout = 32 seconds. With these + settings, communication opportunities between a master and a slave + will occur during a given interval every 32 seconds. Duration of the + interval will depend on several factors, including number of + + + +Gomez, et al. Informational [Page 10] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + connected slaves, amount of data to be transmitted, etc. In the + worst case, only one data unit can be sent from master to slave (and + vice versa) every 32 seconds. + +3.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 the publication + of its first version in 2003, IEEE 802.15.4 [IEEE802.15.4] has become + the de facto choice for a wide range of constrained-node network + application domains and has been a primary target technology of + various IETF working groups such as 6LoWPAN [RFC6282] [RFC6775] + [RFC4944] and 6TiSCH [ARCH-6TiSCH]. IEEE 802.15.4 [IEEE802.15.4] + specifies a variety of related Physical layer (PHY) and MAC layer + functionalities. + + IEEE 802.15.4 [IEEE802.15.4] defines three roles called device, + coordinator, and Personal Area Network (PAN) coordinator. The device + role is adequate for nodes that do not implement the complete IEEE + 802.15.4 [IEEE802.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 [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 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 Carrier Sense Multiple Access with + Collision Avoidance (CSMA/CA) for data communication. In the second + one, a TDMA scheme controls medium access. During the idle period, + communication does not take place, and 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 thus consume + energy). An underlying assumption is that when a message is sent to + a coordinator, the radio of the coordinator will be ready to receive + the message. + + + + + +Gomez, et al. Informational [Page 11] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + The beacon interval and the duration of the active portion of the + beacon interval (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 [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 to the coordinator whether + there is pending data for the device, or to ii) transmit data to the + coordinator. The wake-up pattern of the device, if any, is out of + 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 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 [IEEE802.15.4]. + + The main MAC layer IEEE 802.15.4 [IEEE802.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 + that offers robust features for industrial environments, among + others. In order to provide the functionality needed to enable IPv6 + over TSCH, the 6TiSCH Working Group was created. TSCH is based on a + TDMA schedule whereby a set of timeslots are used for frame + transmission and reception, and other timeslots are unscheduled. The + latter timeslots may be used by a dynamic scheduling mechanism, + otherwise, nodes may keep the radio off during the unscheduled + timeslots, thus saving energy. The minimal schedule configuration + specified in [RFC8180] comprises 101 timeslots; 95 of these timeslots + 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 + + DECT Ultra Low Energy (DECT ULE) is a wireless technology building on + the key fundamentals of traditional DECT / Cordless Advanced + Technology - internet and quality (CAT-iq) [EN300] but with specific + changes to significantly reduce the power consumption at the expense + + + +Gomez, et al. Informational [Page 12] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + of data throughput [TS102]. DECT ULE devices typically operate 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. IPv6 can be run over DECT ULE by + using a 6LoWPAN variant [RFC8105]. + + DECT defines two major roles: the Portable Part (PP) is the power + constrained device while the Fixed Part (FP) is the Gateway or base + station in a star topology. Because TDMA/FDMA and Time-Division + Duplex (TDD) using dynamic channel allocation for interference, DECT + operates in license-free and reserved frequency bands. It provides + 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. + + 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. + + At the MAC level, DECT ULE communications between FP and PP are + initiated by the PP. An FP can initiate communication indirectly by + sending a paging signal to a PP. The PP determines the timeslot and + frequency in 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 + significantly improves the reliability of data transfer. A + segmentation and reassembly scheme supports transfer of larger, + higher-layer Service Data Units (SDUs) and provides data integrity + checks. The DECT ULE packet data service ensures data integrity, + proper sequencing, and duplicate protection but not guaranteed + delivery. Higher-layer protocols have to take this into + consideration. + + 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 defined in the range of 10 ms to + 327 s. 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 + dummy bearer. Hence, longer sleep intervals reduce the average + + + +Gomez, et al. Informational [Page 13] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + energy consumption but add an 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. + + 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 Received Signal Strength + Indication (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 can listen to paging or + instruct the PP to stay in a higher duty-cycle paging detection mode. + + The DECT ULE technology allows a per-PP configuration of paging + interval, MTU size, reassembly window size, and higher-layer service + negotiation and protocol. + +4. IP Adaptation and Transport Layer + + 6LoWPAN provides an adaptation layer designed to support IPv6 over + IEEE 802.15.4 [IEEE802.15.4]. 6LoWPAN affects the energy-efficiency + problem in three aspects, as follows. + + First, 6LoWPAN provides one fragmentation and reassembly mechanism, + which is aimed at solving the packet size issue in IPv6 and 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 + cannot convey a 1280-octet packet in one piece, link-specific + fragmentation and reassembly must be provided at a layer below IPv6 + [RFC8200]. 6LoWPAN provides fragmentation and reassembly below the + IP layer to solve the problem. One of the benefits from placing + fragmentation at a lower layer such as the 6LoWPAN layer is that it + can avoid the presence of more IP headers because fragmentation at + the IP layer will produce more IP packets, each one carrying its own + IP header. However, performance can be severely affected if, after + IP layer fragmentation, then 6LoWPAN fragmentation happens as well + (e.g., when the upper layer is not aware of the existence of the + fragmentation at the 6LoWPAN layer). One solution is to require that + the higher layers have an awareness of the lower-layer features and + generate small enough packets to avoid fragmentation. In this + regard, the Block option in CoAP can be useful when CoAP is used at + the application layer [RFC7959]. + + + + + +Gomez, et al. Informational [Page 14] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN 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 consume even more packet space + than the data itself. 6LoWPAN provides IPv6 and UDP header + compression at the adaptation layer. Therefore, a lower amount of + data will be handled by the lower layers, whereas both the sender and + receiver will spend more computing power on the compression and + decompression of the packets over the air. Compression can also be + performed at higher layers (see Section 6.4). + + Finally, the 6LoWPAN Working Group developed the energy-efficient + Neighbor Discovery called 6LoWPAN-ND, which is an energy-efficient + replacement of the IPv6 ND in constrained environments. IPv6 + Neighbor Discovery was not designed for non-transitive wireless + links, as its heavy use of multicast makes it inefficient and + sometimes impractical in a low-power and lossy network. 6LoWPAN-ND + describes simple optimizations to IPv6 Neighbor Discovery, its + addressing mechanisms, and duplicate address detection for Low-Power + Wireless Personal Area Networks and similar networks. However, + 6LoWPAN-ND does not modify Neighbor Unreachability Detection (NUD) + timeouts, which are very short (by default three transmissions spaced + 1 second apart). NUD timeout settings should be tuned to take into + account the latency that may be introduced by duty-cycled mechanisms + at the link layer 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, the higher-layer protocols do + not typically have specific information about the lower layers and + thus cannot solve the energy-efficiency problem. + + The network stack can be designed to save computing power. For + example, the Contiki implementation has multiple cross-layer + optimizations for buffers and energy management, e.g., the computing + and validation of UDP/TCP checksums without the need of reading 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 designed by the IETF for + constrained environments. RPL exchanges messages periodically and + keeps 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. + + + +Gomez, et al. Informational [Page 15] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + The authors of the Powertrace tool [Powertrace] studied the power + profile of RPL. Their analysis divides the routing protocol into + control and data traffic. The control plane carries ICMP messages to + establish and maintain the routing states. The data plane carries + 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 [RFC6206] algorithm + parameters (i.e., Imin, Imax, and k) to appropriate values. However, + there exists 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 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. + +6. Application Layer + +6.1. Energy-Efficient Features in CoAP + + CoAP [RFC7252] is designed as a RESTful application protocol that + connects 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. + + Energy efficiency is part of the CoAP protocol design. CoAP uses a + fixed-length binary header of only four bytes that may be followed by + 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 an ubiquitous + service; an energy-constrained server can remain in sleep mode during + the period between observe notification transmissions. + + Furthermore, [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 + + + + + +Gomez, et al. Informational [Page 16] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + 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 allows a node to receive data messages + (e.g., carrying sensor readings) from other nodes in the network, + perform an operation based on the content in those messages, and + transmit the result of the operation. Such operation may simply be + intended to use one packet to carry the readings transported in + several packets (which reduces header and transmission overhead), or + it may be a more sophisticated operation, possibly based on + mathematical, logical, or filtering principles (which reduces the + payload size to be transmitted). + +6.2. Sleepy Node Support + + 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 [SLEEPY-DEVICES], while an example application (in the + context of illustrating several security mechanisms) in a scenario + with sleepy devices has been described [CRYPTO-SENSORS]. Approaches + to support sleepy nodes include exploiting the use of 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 in order to support devices that spend most of their time + asleep [CoAP-BROKER]. Notably, this work has been adopted by the + CoRE Working Group. + + 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. + + 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 + + + +Gomez, et al. Informational [Page 17] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + 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 that would unnecessarily waste node energy and + other resources. On the other hand, note that CoAP can also run on + top of TCP [RFC8323]. In that case, similar guidance applies to TCP + timers, albeit with greater motivation to carefully configure TCP RTO + parameters since [RFC6298] reduced the default initial TCP RTO to 1 + second, which may interact more negatively with duty-cycled links + than default CoAP RTO values. + +6.4. Data Compression + + Another method intended to reduce the size of the data units to be + communicated in constrained-node networks is data compression, which + allows to encode data using fewer bits than the original data + representation. Data compression is more efficient at higher layers, + particularly before encryption is used. In fact, encryption + mechanisms may generate an output that does not contain redundancy, + making it almost impossible to reduce the data representation size. + In CoAP, messages may be encrypted by using Datagram Transport Layer + Security (DTLS) or TLS when CoAP over TCP is used, which is the + default mechanism for securing CoAP exchanges. + +7. Summary and Conclusions + + We summarize the key takeaways 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, reduction of their usage by aggregating + similar messages together will be helpful in saving power (see + Sections 2 and 6.1). + + + +Gomez, et al. Informational [Page 18] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + 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. + +10. References + +10.1. Normative References + + [Bluetooth42] + Bluetooth Special Interest Group, "Core Version 4.2", + available from "Legacy Core Specifications", December + 2014, <https://www.bluetooth.com/specifications/ + bluetooth-core-specification/legacy-specifications>. + + [EN300] ETSI, "Digital Enhanced Cordless Telecommunications + (DECT); Common Interface (CI); Part 1: Overview", ETSI EN + 300 175-1 V2.6.1, July 2015, + <https://www.etsi.org/deliver/ + etsi_en/300100_300199/30017501/02.06.01_60/ + en_30017501v020601p.pdf>. + + [G9959] ITU-T, "Short range narrow-band digital radiocommunication + transceivers - PHY, MAC, SAR and LLC layer + specifications", ITU-T Recommendation G.9959, January + 2015, <http://www.itu.int/rec/T-REC-G.9959>. + + [IEEE802.11] + IEEE, "IEEE Standard for Information technology-- + Telecommunications and information exchange between + systems Local and metropolitan area networks--Specific + requirements - Part 11: Wireless LAN Medium Access Control + (MAC) and Physical Layer (PHY) Specifications", + IEEE 802.11, DOI 10.1109/IEEESTD.2016.7786995, + <http://ieeexplore.ieee.org/document/7786995/versions>. + + + + + + + + +Gomez, et al. Informational [Page 19] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + [IEEE802.15.4] + IEEE, "IEEE Standard for Low-Rate Wireless Networks", + IEEE 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, + <https://standards.ieee.org/findstds/ + standard/802.15.4-2015.html>. + + [MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication + Protocol for Building Automation and Control Networks + ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to + ANSI/ASHRAE Standard 135-2012", July 2014, + <https://www.ashrae.org/technical-resources/standards-and- + guidelines/standards-addenda/ + addenda-to-standard-135-2012>. + + [NFC] NFC Forum, "NFC Logical Link Control Protocol", Technical + Specification, Version 1.3, March 2016. + + [oneM2M] oneM2M, "oneM2M - Published Specifications", + <http://www.onem2m.org/technical/published-documents>. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, + <https://www.rfc-editor.org/info/rfc4944>. + + [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, + "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, + March 2011, <https://www.rfc-editor.org/info/rfc6206>. + + [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 + Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, + DOI 10.17487/RFC6282, September 2011, + <https://www.rfc-editor.org/info/rfc6282>. + + [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, + "Computing TCP's Retransmission Timer", RFC 6298, + DOI 10.17487/RFC6298, June 2011, + <https://www.rfc-editor.org/info/rfc6298>. + + [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., + Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, + JP., and R. Alexander, "RPL: IPv6 Routing Protocol for + Low-Power and Lossy Networks", RFC 6550, + DOI 10.17487/RFC6550, March 2012, + <https://www.rfc-editor.org/info/rfc6550>. + + + + + + +Gomez, et al. Informational [Page 20] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., + and D. Barthel, "Routing Metrics Used for Path Calculation + in Low-Power and Lossy Networks", RFC 6551, + DOI 10.17487/RFC6551, March 2012, + <https://www.rfc-editor.org/info/rfc6551>. + + [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. + Bormann, "Neighbor Discovery Optimization for IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs)", + RFC 6775, DOI 10.17487/RFC6775, November 2012, + <https://www.rfc-editor.org/info/rfc6775>. + + [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, + <https://www.rfc-editor.org/info/rfc7228>. + + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, + <https://www.rfc-editor.org/info/rfc7252>. + + [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., + Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low + Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, + <https://www.rfc-editor.org/info/rfc7668>. + + [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", STD 86, RFC 8200, + DOI 10.17487/RFC8200, July 2017, + <https://www.rfc-editor.org/info/rfc8200>. + + [TS102] ETSI, "Digital Enhanced Cordless Telecommunications + (DECT); Ultra Low Energy (ULE); Machine to Machine + Communications; Part 2: Home Automation Network (phase 2", + ETSI TS 102 939-2 V1.1.1, March 2015, + <https://www.etsi.org/deliver/ + etsi_ts/102900_102999/10293902/01.01.01_60/ + ts_10293902v010101p.pdf>. + + + + + + + + + + + + +Gomez, et al. Informational [Page 21] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +10.2. Informative References + + [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/>. + + + +Gomez, et al. Informational [Page 22] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + + [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 + + Carles Gomez has been supported by the Spanish Government, FEDER, and + the ERDF through projects TEC2012-32531 and TEC2016-79988-P. + + The authors would like to give thanks for the review and feedback + from a number of experts in this area: Carsten Bormann, Ari Keranen, + Hannes Tschofenig, Dominique Barthel, Bernie Volz, and Charlie + Perkins. + + The text of this document was improved based on an IESG document + editing session during IETF 87. Thanks to Ted Lemon and Joel Jaeggli + for initiating and facilitating this editing session. + + + + + + +Gomez, et al. Informational [Page 23] + +RFC 8352 Energy-Efficient Features for IoT April 2018 + + +Contributors + + Jens T. Petersen, RTX, contributed the section on power save services + in DECT ULE. + +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 + + + + + + + + + + + + +Gomez, et al. Informational [Page 24] + |