idnits 2.17.1 draft-ietf-lwig-energy-efficient-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2017) is 2379 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 7959' is mentioned on line 640, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-bormann-lwig-7228bis-01 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-12 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-02 == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 == Outdated reference: A later version (-06) exists of draft-ietf-lwig-crypto-sensors-04 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Gomez 3 Internet-Draft Universitat Politecnica de Catalunya 4 Intended status: Informational M. Kovatsch 5 Expires: April 24, 2018 ETH Zurich 6 H. Tian 7 China Academy of Telecommunication Research 8 Z. Cao, Ed. 9 Huawei Technologies 10 October 21, 2017 12 Energy-Efficient Features of Internet of Things Protocols 13 draft-ietf-lwig-energy-efficient-08 15 Abstract 17 This document describes the challenges for energy-efficient protocol 18 operation on constrained devices and the current practices used to 19 overcome those challenges. It summarizes the main link-layer 20 techniques used for energy-efficient networking, and it highlights 21 the impact of such techniques on the upper layer protocols so that 22 they can together achieve an energy efficient behavior. The document 23 also provides an overview of energy-efficient mechanisms available at 24 each layer of the IETF protocol suite specified for constrained node 25 networks. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 24, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Medium Access Control and Radio Duty Cycling . . . . . . . . 5 65 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 66 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 67 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 8 69 3.5. Packet bundling . . . . . . . . . . . . . . . . . . . . . 8 70 3.6. Power save services available in example low-power radios 8 71 3.6.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 72 3.6.2. Power Save Services Provided by Bluetooth LE . . . . 9 73 3.6.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 74 3.6.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 75 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 14 76 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 15 77 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 16 78 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 16 79 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 16 80 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.4. Data compression . . . . . . . . . . . . . . . . . . . . 17 82 7. Summary and Conclusions . . . . . . . . . . . . . . . . . . . 18 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 12.2. Informative References . . . . . . . . . . . . . . . . . 21 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 92 1. Introduction 94 Network systems for physical world monitoring contain many battery- 95 powered or energy-harvesting devices. For example, in an 96 environmental monitoring system, or a temperature and humidity 97 monitoring system, there may not be always-on and sustained power 98 supplies for the potentially large number of constrained devices. In 99 such deployment scenarios, it is necessary to optimize the energy 100 consumption of the constrained devices. In this document we describe 101 techniques that are in common use at Layer 2 and at Layer 3, and we 102 indicate the need for higher-layer awareness of lower-layer features. 104 Many research efforts have studied this "energy efficiency" problem. 105 Most of this research has focused on how to optimize the system's 106 power consumption in certain deployment scenarios, or how an existing 107 network function such as routing or security could be more energy- 108 efficient. Only few efforts have focused on energy-efficient designs 109 for IETF protocols and standardized network stacks for such 110 constrained devices [I-D.kovatsch-lwig-class1-coap]. 112 The IETF has developed a suite of Internet protocols suitable for 113 such constrained devices, including IPv6 over Low-Power Wireless 114 Personal Area Networks (6LoWPAN) [RFC6282],[RFC6775],[RFC4944], the 115 IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) 116 [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. 117 This document tries to summarize the design considerations for making 118 the IETF constrained protocol suite as energy-efficient as possible. 119 While this document does not provide detailed and systematic 120 solutions to the energy efficiency problem, it summarizes the design 121 efforts and analyzes the design space of this problem. In 122 particular, it provides an overview of the techniques used by the 123 lower layers to save energy and how these may impact on the upper 124 layers. Cross-layer interaction is therefore considered in this 125 document from this specific point of view. Providing further design 126 recommendations that go beyond the layered protocol architecture is 127 out of the scope of this document. 129 After reviewing the energy-efficient designs of each layer, we 130 summarize the document by presenting some overall conclusions. 131 Though the lower layer communication optimization is the key part of 132 energy efficient design, the protocol design at the upper layers is 133 also important to make the device energy-efficient. 135 1.1. Terminology 137 Terms used in this document are defined in [RFC7228] 138 [I-D.bormann-lwig-7228bis]. 140 2. Overview 142 The IETF has developed protocols to enable end-to-end IP 143 communication between constrained nodes and fully capable nodes. 144 This work has expedited the evolution of the traditional Internet 145 protocol stack to a light-weight Internet protocol stack. As shown 146 in Figure 1 below, the IETF has developed CoAP as the application 147 layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 148 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL 149 and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently 150 being adapted by the 6lo working group to support IPv6 over various 151 other technologies, such as ITU-T G.9959 [G9959], DECT ULE [TS102], 152 MS/TP-BACnet [MSTP], and Near Field Communication (NFC) [NFC]. 154 +-----+ +-----+ +-----+ +------+ 155 |HTTP | | FTP | |SNMP | | CoAP | 156 +-----+ +-----+ +-----+ +------+ 157 \ / / / \ 158 +-----+ +-----+ +-----+ +-----+ 159 | TCP | | UDP | | TCP | | UDP | 160 +-----+ +-----+ ===> +-----+ +-----+ 161 \ / \ / 162 +-----+ +------+ +-------+ +------+ +-----+ 163 | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RTG | 164 +-----+ +------+ +-------+ +------+ +-----+ 165 | | 166 +-------+ +-------+ +----------+ 167 |MAC/PHY| | 6Lo |--|6LoWPAN-ND| 168 +-------+ +-------+ +----------+ 169 | 170 +-------+ 171 |MAC/PHY| 172 +-------+ 174 Figure 1: Traditional and Light-weight Internet Protocol Stack 176 There are numerous published studies reporting comprehensive 177 measurements of wireless communication platforms [Powertrace]. As an 178 example, below we list the energy consumption profile of the most 179 common operations involved in communication on a prevalent sensor 180 node platform. The measurement was based on the Tmote Sky with 181 ContikiMAC [ContikiMAC] as the radio duty cycling algorithm. From 182 this and many other measurement reports (e.g.[AN079]), we can see 183 that the energy consumption of optimized transmission and reception 184 are in the same order. For IEEE 802.15.4 and Ultra WideBand (UWB) 185 links, transmitting may actually be even cheaper than receiving. It 186 also shows that broadcast and non-synchronized communication 187 transmissions are energy costly because they need to acquire the 188 medium for a long time. 190 +---------------------------------------+---------------+ 191 | Activity | Energy (uJ) | 192 +---------------------------------------+---------------+ 193 | Broadcast reception | 178 | 194 +---------------------------------------+---------------+ 195 | Unicast reception | 222 | 196 +---------------------------------------+---------------+ 197 | Broadcast transmission | 1790 | 198 +---------------------------------------+---------------+ 199 | Non-synchronized unicast transmission | 1090 | 200 +---------------------------------------+---------------+ 201 | Synchronized unicast transmission | 120 | 202 +---------------------------------------+---------------+ 203 | Unicast TX to awake receiver | 96 | 204 +---------------------------------------+---------------+ 205 | Listening (for 1000 ms) | 63000 | 206 +---------------------------------------+---------------+ 208 Figure 2: Power consumption of common operations involved in 209 communication on the Tmote Sky with ContikiMAC 211 At the Physical layer, one approach that may allow reducing energy 212 consumption of a device that uses a wireless interface is based on 213 reducing the device transmit power level as long as the intended next 214 hop(s) are still within range of the device. In some cases, if node 215 A has to transmit a message to node B, a solution to reduce node A 216 transmit power is to leverage an intermediate device, e.g. node C as 217 a message forwarder. Let d be the distance between node A and node 218 B. Assuming free-space propagation, where path loss is proportional 219 to d^2, if node C is placed right in the middle of the path between A 220 and B (that is, at a distance d/2 from both node A and node B), the 221 minimum transmit power to be used by node A (and by node C) is 222 reduced by a factor of 4. However, this solution requires additional 223 devices, it requires a routing solution, and it also increases 224 transmission delay between A and B. 226 3. Medium Access Control and Radio Duty Cycling 228 In networks, communication and power consumption are interdependent. 229 The communication device is typically the most power-consuming 230 component, but merely refraining from transmissions is not enough to 231 achieve a low power consumption: the radio may consume as much power 232 in listen mode as when actively transmitting. This illustrates the 233 key problem known as idle listening, whereby the radio of a device 234 may be in receive mode (ready to receive any message), even if no 235 message is being transmitted to that device. Idle listening can 236 consume a huge amount of energy unnecessarily. To reduce power 237 consumption, the radio must be switched completely off -- duty-cycled 238 -- as much as possible. By applying duty-cycling, the lifetime of a 239 device operating on a common button battery may be on the order of 240 years, whereas otherwise the battery may be exhausted in a few days 241 or even hours. Duty-cycling is a technique generally employed by 242 devices that use the P1 strategy [RFC7228], which need to be able to 243 communicate on a relatively frequent basis. Note that a more 244 aggressive approach to save energy relies on the P0, Normally-off 245 strategy, whereby devices sleep for very long periods and communicate 246 infrequently, even though they spend energy in network reattachment 247 procedures. 249 From the perspective of Medium Access Control (MAC) and Radio Duty 250 Cycling (RDC), all upper layer protocols, such as routing, RESTful 251 communication, adaptation, and management flows, are applications. 252 Since the duty cycling algorithm is the key to energy-efficiency of 253 the wireless medium, it synchronizes transmission and/or reception 254 requests from the higher layers. 256 MAC and RDC are not in the scope of the IETF, yet lower layer 257 designers and chipset manufacturers take great care to save energy. 258 By knowing the behaviors of these lower layers, IETF engineers can 259 design protocols that work well with them. The IETF protocols to be 260 discussed in the following sections are the customers of the lower 261 layers. 263 3.1. Radio Duty Cycling techniques 265 This subsection describes three main three RDC techniques. Note that 266 more than one of these techniques may be available or can even be 267 combined in a specific radio technology: 269 a) Channel sampling. In this solution, the radio interface of a 270 device periodically monitors the channel for very short time 271 intervals (i.e. with a low duty cycle) with the aim of detecting 272 incoming transmissions. In order to make sure that a receiver can 273 correctly receive a transmitted data unit, the sender may prepend a 274 preamble of a duration at least the sampling period to the data unit 275 to be sent. Another option for the sender is to repeatedly transmit 276 the data unit, instead of sending a preamble before the data unit. 277 Once a transmission is detected by a receiver, the receiver may stay 278 awake until the complete reception of the data unit. Examples of 279 radio technologies that use preamble sampling include ContikiMAC, the 280 Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the 281 Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. 283 b) Scheduled transmissions. This approach allows a device to know 284 the particular time at which it should be awake (during some time 285 interval) in order to receive data. Otherwise, the device may remain 286 in sleep mode. The decision on the times at which communication is 287 attempted relies on some form of negotation between the involved 288 devices. Such negotiation may be performed per transmission or per 289 session/connection. Bluetooth Low Energy (Bluetooth LE) is an 290 example of a radio technology based on this mechanism. 292 c) Listen after send. This technique allows a node to remain in 293 sleep mode by default, wake up and poll a sender (which must be ready 294 to receive a poll message) for pending transmissions. After sending 295 the poll message, the node remains in receive mode, ready for a 296 potential incoming transmission. After a certain time interval, the 297 node may go back to sleep. For example, the Receiver Initiated 298 Transmission (RIT) mode of 802.15.4e, and the transmission of data 299 between a coordinator and a device in IEEE 802.15.4-2003 use this 300 technique. 302 3.2. Latency and buffering 304 The latency of a data unit transmission to a duty-cycled device is 305 equal to or greater than the latency of transmitting to an always-on 306 device. Therefore, duty-cycling leads to a trade-off between energy 307 consumption and latency. Note that in addition to a latency 308 increase, RDC may introduce latency variance, since the latency 309 increase is a random variable (which is uniformly distributed if 310 duty-cycling follows a periodical behavior). 312 On the other hand, due to the latency increase of duty-cycling, a 313 sender waiting for a transmission opportunity may need to store 314 subsequent outgoing packets in a buffer, increasing memory 315 requirements and potentially incurring queuing waiting time that 316 contributes to the packet's overall delay and increases the 317 probability of buffer overflow, leading to losses. 319 3.3. Throughput 321 Although throughput is not typically a key concern in constrained 322 node network applications, it is indeed important in some services in 323 such networks, such as over-the-air software updates or when off-line 324 sensors accumulate measurements that have to be quickly transferred 325 when there is an opportunity for connectivity. 327 Since RDC introduces inactive intervals in energy-constrained 328 devices, it reduces the throughput that can be achieved when 329 communicating with such devices. There exists a trade-off between 330 the achievable throughput and energy consumption. 332 3.4. Radio interface tuning 334 The parameters controlling the radio duty cycle have to be carefully 335 tuned to achieve the intended application and/or network 336 requirements. On the other hand, upper layers should take into 337 account the expected latency and/or throughput behavior due to RDC. 338 The next subsection provides details on key parameters controlling 339 RDC mechanisms, and thus fundamental trade-offs, for various examples 340 of relevant low-power radio technologies. 342 3.5. Packet bundling 344 Another technique that may be useful to increase communication energy 345 efficiency is packet bundling. This technique, which is available in 346 several radio interfaces (e.g. LTE and some 802.11 variants), allows 347 to aggregate several small packets into a single large packet. 348 Header and communication overhead is therefore reduced. 350 3.6. Power save services available in example low-power radios 352 This subsection presents power save services and techniques used in a 353 few relevant examples of wireless low-power radios: IEEE 802.11, 354 Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each 355 technology, the reader may refer to the literature or to the 356 corresponding specifications. 358 3.6.1. Power Save Services Provided by IEEE 802.11 360 IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may 361 indicate to an Access Point (AP) that it will enter a sleep mode 362 state. While the station is sleeping, the AP buffers any frames that 363 should be sent to the sleeping station. The station wakes up every 364 Listen Interval (which can be a multiple of the Beacon Interval) in 365 order to receive beacons. The AP signals in the beacon whether there 366 is data pending for the station or not. If there are not frames to 367 be sent to the station, the latter may get back to sleep mode. 368 Otherwise, the station may send a message requesting the transmission 369 of the buffered data and stay awake in receive mode. 371 IEEE 802.11v [IEEE80211v] further defines mechanisms and services for 372 power save of stations/nodes that include flexible multicast service 373 (FMS), proxy ARP advertisement, extended sleep modes, and traffic 374 filtering. Upper layer protocols knowledge of such capabilities 375 provided by the lower layer enables better interworking. 377 These services include: 379 Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to 380 indicate that the non-AP station (STA) will not receive ARP frames. 381 The Proxy ARP capability enables the non-AP STA to remain in power- 382 save for longer periods of time. 384 Basic Service Set (BSS) Max Idle Period management enables an AP to 385 indicate a time period during which the AP does not disassociate a 386 STA due to non-receipt of frames from the STA. This supports 387 improved STA power saving and AP resource management. 389 FMS: A service in which a non-access point (non-AP) STA can request a 390 multicast delivery interval longer than the delivery traffic 391 indication message (DTIM) interval for the purposes of lengthening 392 the period of time a STA may be in a power save state. 394 Traffic Filtering Service (TFS): A service provided by an access 395 point (AP) to a non-AP STA that can reduce the number of frames sent 396 to the STA by dropping individually addressed frames that do not 397 match traffic filters specified by the STA. 399 Using the above services provided by the lower layer, the constrained 400 nodes can achieve either client initiated power save (via TFS) or 401 network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). 403 Upper layer protocols should synchronize with the parameters such as 404 FMS interval and BSS MAX Idle Period, so that the wireless 405 transmissions are not triggered periodically. 407 3.6.2. Power Save Services Provided by Bluetooth LE 409 Bluetooth LE is a wireless low-power communications technology that 410 is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 411 specifications [Bluetooth42]. BT-LE has been designed for the goal 412 of ultra-low-power consumption. IPv6 can be run IPv6 over Bluetooth 413 LE networks by using a 6LoWPAN variant adapted to BT-LE [RFC7668]. 415 Bluetooth LE networks comprise a master and one or more slaves which 416 are connected to the master. The Bluetooth LE master is assumed to 417 be a relatively powerful device, whereas a slave is typically a 418 constrained device (e.g. a class 1 device). 420 Medium access in Bluetooth LE is based on a Time Division Multiple 421 Access (TDMA) scheme which is coordinated by the master. This device 422 determines the start of connection events, in which communication 423 between the master and a slave takes place. At the beginning of a 424 connection event, the master sends a poll message, which may 425 encapsulate data, to the slave. The latter must send a response, 426 which may also contain data. The master and the slave may continue 427 exchanging data until the end of the connection event. The next 428 opportunity for communication between the master and the slave will 429 be in the next connection event scheduled for the slave. 431 The time between consecutive connection events is defined by the 432 connInterval parameter, which may range between 7.5 ms and 4 s. The 433 slave may remain in sleep mode since the end of its last connection 434 event until the beginning of its next connection event. Therefore, 435 Bluetooth LE is duty-cycled by design. Furthermore, after having 436 replied to the master, a slave is not required to listen to the 437 master (and thus may keep the radio in sleep mode) for 438 connSlaveLatency consecutive connection events. connSlaveLatency is 439 an integer parameter between 0 and 499 which should not cause link 440 inactivity for more than connSupervisionTimeout time. The 441 connSupervisionTimeout parameter is in the range between 100 ms and 442 32 s. 444 Upper layer protocols should take into account the medium access and 445 duty-cycling behavior of Bluetooth LE. In particular, connInterval, 446 connSlaveLatency and connSupervisionTimeout determine the time 447 between two consecutive connection events for a given slave. The 448 upper layer packet generation pattern and rate should be consistent 449 with the settings of the aforementioned parameters (and vice versa). 450 For example, assume connInterval=4 seconds, connSlaveLatency=7 and 451 connSupervisionTimeout=32 seconds. With these settings, 452 communication opportunities between a master and a slave will occur 453 during a given interval every 32 seconds. Duration of the interval 454 will depend on several factors, including number of connected slaves, 455 amount of data to be transmitted, etc. In the worst case, only one 456 data unit can be sent from master to slave and vice versa every 32 457 seconds. 459 3.6.3. Power Save Services in IEEE 802.15.4 461 IEEE 802.15.4 is a family of standard radio interfaces for low-rate, 462 low-power wireless networking [fifteendotfour]. Since the 463 publication of its first version in 2003, IEEE 802.15.4 has become 464 the de-facto choice for a wide range of constrained node network 465 application domains and has been a primary target technology of 466 various IETF working groups such as 6LoWPAN [RFC6282], [RFC6775], 467 [RFC4944] and 6TiSCH [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 468 specifies a variety of related PHY and MAC layer functionalites. 470 IEEE 802.15.4 defines three roles called device, coordinator and 471 Personal Area Network (PAN) coordinator. The device role is adequate 472 for nodes that do not implement the complete IEEE 802.15.4 473 functionality, and is mainly targeted for constrained nodes with a 474 limited energy source. The coordinator role includes synchronization 475 capabilities and is suitable for nodes that do not suffer severe 476 constraints (e.g. a mains-powered node). The PAN coordinator is a 477 special type of coordinator that acts as a principal controller in an 478 IEEE 802.15.4 network. 480 IEEE 802.15.4 defines two main types of networks depending on their 481 configuration: beacon-enabled and nonbeacon-enabled networks. In the 482 first network type, coordinators periodically transmit beacons. The 483 time between beacons is divided in three main parts: the Contention 484 Access Period (CAP), the Contention Free Period (CFP) and an inactive 485 period. In the first period, nodes use slotted Carrier Sense 486 Multiple Access / Collision Avoidance (CSMA/CA) for data 487 communication. In the second one, a TDMA scheme controls medium 488 access. During the idle period, communication does not take place, 489 thus the inactive period is a good opportunity for nodes to turn the 490 radio off and save energy. The coordinator announces in each beacon 491 the list of nodes for which data will be sent in the subsequent 492 period. Therefore, devices may remain in sleep mode by default and 493 wake up periodically to listen to the beacons sent by their 494 coordinator. If a device wants to transmit data, or learns from a 495 beacon that it is an intended destination, then it will exchange 496 messages with the coordinator (and thus consume energy). An 497 underlying assumption is that when a message is sent to a 498 coordinator, the radio of the coordinator will be ready to receive 499 the message. 501 The beacon interval and the duration of the beacon interval active 502 portion (i.e. the CAP and the CFP), and thus the duty cycle, can be 503 configured. The parameters that control these times are called 504 macBeaconOrder and macSuperframeOrder, respectively. As an example, 505 when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be 506 (independently) set to values in the range between 15.36 ms and 251.6 507 seconds. 509 In the beaconless mode, nodes use unslotted CSMA/CA for data 510 transmission. The device may be in sleep mode by default and may 511 activate its radio to either i) request to the coordinator whether 512 there is pending data for the device, or ii) to transmit data to the 513 coordinator. The wake-up pattern of the device, if any, is out of 514 the scope of IEEE 802.15.4. 516 Communication between the two ends of an IEEE 802.15.4 link may also 517 take place in a peer-to-peer configuration, whereby both link ends 518 assume the same role. In this case, data transmission can happen at 519 any moment. Nodes must have their radio in receive mode, and be 520 ready to listen to the medium by default (which for battery-enabled 521 nodes may lead to a quick battery depletion), or apply 522 synchronization techniques. The latter are out of the scope of IEEE 523 802.15.4. 525 The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. 526 This amendment includes various new MAC layer modes, some of which 527 include mechanisms for low energy consumption. Among these, the 528 Time-Slotted Channel Hopping (TSCH) is an outstanding mode which 529 offers robust features for industrial environments, among others. In 530 order to provide the functionality needed to enable IPv6 over TSCH, 531 the 6TiSCH working group was created. TSCH is based on a TDMA 532 schedule whereby a set of time slots are used for frame transmission 533 and reception, and other time slots are unscheduled. The latter time 534 slots may be used by a dynamic scheduling mechanism, otherwise nodes 535 may keep the radio off during the unscheduled time slots, thus saving 536 energy. The minimal schedule configuration specified in 537 [I-D.ietf-6tisch-minimal] comprises 101 time slots; 95 of these time 538 slots are unscheduled and the time slot duration is 15 ms. 540 The previously mentioned CSL and RIT are also 802.15.4e modes 541 designed for low energy. 543 3.6.4. Power Save Services in DECT ULE 545 DECT Ultra Low Energy (DECT ULE) is a wireless technology building on 546 the key fundamentals of traditional DECT / CAT-iq [EN300] but with 547 specific changes to significantly reduce the power consumption at the 548 expense of data throughput [TS102]. DECT ULE devices typically 549 operate on special power optimized silicon, but can connect to a DECT 550 Gateway supporting traditional DECT / CAT-iq for cordless telephony 551 and data as well as the DECT ULE extensions. IPv6 can be run over 552 DECT ULE by using a 6LoWPAN variant [I-D.ietf-6lo-dect-ule]. 554 DECT defines two major roles: the Portable Part (PP) is the power 555 constrained device, while the Fixed Part (FP) is the Gateway or base 556 station in a star topology. DECT operates in license free and 557 reserved frequency bands based on TDMA/FDMA and TDD using dynamic 558 channel allocation for interference avoidance. It provides good 559 indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame length 560 of 10 ms divided into 24 timeslots, and it supports connection 561 oriented, packet data and connection-less services. 563 The FP usually transmits a so-called dummy bearer (beacon) that is 564 used to broadcast synchronization, system and paging information. 565 The slot/carrier position of this dummy bearer can automatically be 566 reallocated in order to avoid mutual interference with other DECT 567 signals. 569 At the MAC level DECT ULE communications between FP and PP are 570 initiated by the PP. A FP can initiate communication indirectly by 571 sending paging signal to a PP. The PP determines the timeslot and 572 frequency on which the communication between FP and PP takes place. 573 The PP verifies the radio timeslot/frequency position is unoccupied 574 before it initiates its transmitter. An access-request message, 575 which usually carries data, is sent to the FP. The FP sends a 576 confirm message, which also may carry data. More data can be sent in 577 subsequent frames. A MAC level automatic retransmission scheme 578 significantly improves data transfer reliability. A segmentation and 579 reassembly scheme supports transfer of larger higher layer SDUs and 580 provides data integrity check. The DECT ULE packet data service 581 ensures data integrity, proper sequencing, duplicate protection, but 582 not guaranteed delivery. Higher layers protocols have to take this 583 into consideration. 585 The FP may send paging information to PPs to trigger connection setup 586 and indicate the required service type. The interval between paging 587 information to a specific PP can be defined in range 10 ms to 327 588 seconds. The PP may enter sleep mode to save power. The listening 589 interval is defined by the PP application. For short sleep intervals 590 (below ~10 seconds) the PP may be able to retain synchronization to 591 the FP dummy bearer and only turn on the receiver during the expected 592 timeslot. For longer sleep intervals the PP can't keep 593 synchronization and has to search for and resynchronize to the FP 594 dummybearer. Hence, longer sleep interval reduces the average energy 595 consumption, but adds a energy consumption penalty for acquiring 596 synchronization to the FP dummy bearer. The PP can obtain all 597 information to determine paging and acquire synchronization 598 information in a single reception of one full timeslot. 600 Packet data latency is normally 30 ms for short packets (below or 601 equal to 32 octets), however if retry and back-off scenarios occur, 602 the latency is increased. The latency can actually be reduced to 603 about 10 ms by doing energy consuming RSSI scanning in advance. In 604 the direction from FP to PP the latency is usually increased by the 605 used paging interval and the sleep interval. The MAC layer can 606 piggyback commands to improve efficiency (reduce latency) of higher 607 layer protocols. Such commands can instruct the PP to initiate a new 608 packet transfer in N frames without the need for resynchronization 609 and listening to paging or instruct the PP to stay in a higher duty 610 cycle paging detection mode. 612 The DECT ULE technology allows per PP configuration of paging 613 interval, MTU size, reassembly window size and higher layer service 614 negotiation and protocol. 616 4. IP Adaptation and Transport Layer 618 6LoWPAN provides an adaptation layer designed to support IPv6 over 619 IEEE 802.15.4. 6LoWPAN affects the energy-efficiency problem in three 620 aspects, as follows. 622 First, 6LoWPAN provides one fragmentation and reassembly mechanism 623 which is aimed at solving the packet size issue in IPv6 and could 624 also affect energy-efficiency. IPv6 requires that every link in the 625 internet have an MTU of 1280 octets or greater. On any link that 626 cannot convey a 1280-octet packet in one piece, link-specific 627 fragmentation and reassembly must be provided at a layer below IPv6 628 [RFC2460]. 6LoWPAN provides fragmentation and reassembly below the 629 IP layer to solve the problem. One of the benefits from placing 630 fragmentation at a lower layer such as the 6LoWPAN layer is that it 631 can avoid the presence of more IP headers, because fragmentation at 632 the IP layer will produce more IP packets, each one carrying its own 633 IP header. However, performance can be severely affected if, after 634 IP layer fragmentation, then 6LoWPAN fragmentation happens as well 635 (e.g. when the upper layer is not aware of the existence of the 636 fragmentation at the 6LoWPAN layer). One solution is to require 637 higher layers awareness of lower layer features and generate small 638 enough packets to avoid fragmentation. In this regard, the Block 639 option in CoAP can be useful when CoAP is used at the application 640 layer [RFC 7959]. 642 Secondly, 6LoWPAN swaps computing with communication. 6LoWPAN applies 643 compression of the IPv6 header. Subject to the packet size limit of 644 IEEE 802.15.4, 40 octets long IPv6 header and 8 octets or 20 octets 645 long UDP and TCP header will consume even more packet space than the 646 data itself. 6LoWPAN provides IPv6 and UDP header compression at the 647 adaptation layer. Therefore, a lower amount of data will be handled 648 by the lower layers, whereas both the sender and receiver will spend 649 more computing power on the compression and decompression of the 650 packets over the air. Compression can also be performed at higher 651 layers (see Section 6.4). 653 Finally, the 6LoWPAN working group developed the energy-efficient 654 Neighbor Discovery called 6LoWPAN-ND, which is an energy efficient 655 replacement of the IPv6 ND in constrained environments. IPv6 656 Neighbor Discovery was not designed for non-transitive wireless 657 links, as its heavy use of multicast makes it inefficient and 658 sometimes impractical in a low-power and lossy network. 6LoWPAN-ND 659 describes simple optimizations to IPv6 Neighbor Discovery, its 660 addressing mechanisms, and duplicate address detection for Low-power 661 Wireless Personal Area Networks and similar networks. However, 662 6LoWPAN ND does not modify Neighbor Unreachability Detection (NUD) 663 timeouts, which are very short (by default three transmissions spaced 664 one second apart). NUD timeout settings should be tuned taking into 665 account the latency that may be introduced by duty-cycled mechanisms 666 at the link layer, or alternative, less impatient NUD algorithms 667 should be considered [I-D.ietf-6man-impatient-nud]. 669 IPv6 underlies the higher layer protocols, including both TCP/UDP 670 transport and applications. By design, the higher-layer protocols do 671 not typically have specific information about the lower layers, and 672 thus cannot solve the energy-efficiency problem. 674 The network stack can be designed to save computing power. For 675 example the Contiki implementation has multiple cross layer 676 optimizations for buffers and energy management, e.g., the computing 677 and validation of UDP/TCP checksums without the need of reading IP 678 headers from a different layer. These optimizations are software 679 implementation techniques, and out of the scope of IETF and the LWIG 680 working group. 682 5. Routing Protocols 684 RPL [RFC6550] is a routing protocol designed by the IETF for 685 constrained environments. RPL exchanges messages periodically and 686 keeps routing states for each destination. RPL is optimized for the 687 many-to-one communication pattern, where network nodes primarily send 688 data towards the border router, but has provisions for any-to-any 689 routing as well. 691 The authors of the Powertrace tool [Powertrace] studied the power 692 profile of RPL. Their analysis divides the routing protocol into 693 control and data traffic. The control plane carries ICMP messages to 694 establish and maintain the routing states. The data plane carries 695 any application that uses RPL for routing packets. The study has 696 shown that the power consumption of the control traffic goes down 697 over time in a relatively stable network. The study also reflects 698 that the routing protocol should keep the control traffic as low as 699 possible to make it energy-friendly. The amount of RPL control 700 traffic can be tuned by setting the Trickle [RFC6206] algorithm 701 parameters (i.e. Imin, Imax and k) to appropriate values. However, 702 there exists a trade-off between energy consumption and other 703 performance parameters such as network convergence time and 704 robustness. 706 RFC 6551 [RFC6551] defines routing metrics and constraints to be used 707 by RPL in route computation. Among others, RFC 6551 specifies a Node 708 Energy object that allows to provide information related to node 709 energy, such as the energy source type or the estimated percentage of 710 remaining energy. Appropriate use of energy-based routing metrics 711 may help to balance energy consumption of network nodes, minimize 712 network partitioning and increase network lifetime. 714 6. Application Layer 716 6.1. Energy efficient features in CoAP 718 CoAP [RFC7252] is designed as a RESTful application protocol, 719 connecting the services of smart devices to the World Wide Web. CoAP 720 is not a chatty protocol. It provides basic communication services 721 such as service discovery and GET/POST/PUT/DELETE methods with a 722 binary header. 724 Energy efficiency is part of the CoAP protocol design. CoAP uses a 725 fixed-length binary header of only four bytes that may be followed by 726 binary options. To reduce regular and frequent queries of the 727 resources, CoAP provides an observe mode, in which the requester 728 registers its interest of a certain resource and the responder will 729 report the value whenever it was updated. This reduces the request 730 response round trips while keeping information exchange a ubiquitous 731 service; an energy-constrained server can remain in sleep mode during 732 the period between observe notification transmissions. 734 Furthermore, [RFC7252] defines CoAP proxies which can cache resource 735 representations previously provided by sleepy CoAP servers. The 736 proxies themselves may respond to client requests if the 737 corresponding server is sleeping and the resource representation is 738 recent enough. Otherwise, a proxy may attempt to obtain the resource 739 from the sleepy server. 741 CoAP proxy and cache functionality may also be used to perform data 742 aggregation. This technique allows a node to receive data messages 743 (e.g. carrying sensor readings) from other nodes in the network, 744 perform an operation based on the content in those messages, and 745 transmit the result of the operation. Such operation may simply be 746 intended to use one packet to carry the readings transported in 747 several packets (which reduces header and transmission overhead), or 748 it may be a more sophisticated operation, possibly based on 749 mathematical, logical or filtering principles (which reduces the 750 payload size to be transmitted). 752 6.2. Sleepy node support 754 Beyond these features of CoAP, there have been a number of proposals 755 to further support sleepy nodes at the application layer by 756 leveraging CoAP mechanisms. A good summary of such proposals can be 757 found in [I-D.rahman-core-sleepy-nodes-do-we-need], while an example 758 application (in the context of illustrating several security 759 mechanisms) in a scenario with sleepy devices has been described 760 [I-D.ietf-lwig-crypto-sensors]. Approaches to support sleepy nodes 761 include exploiting the use of proxies, leveraging the Resource 762 Directory [I-D.ietf-core-resource-directory] or signaling when a node 763 is awake to the interested nodes. Recent work defines publish- 764 subscribe and message queuing extensions to CoAP and the Resource 765 Directory in order to support devices that spend most of their time 766 in asleep [I-D.ietf-core-coap-pubsub]. Notably, this work has been 767 adopted by the CoRE Working Group. 769 In addition to the work within the scope of CoAP to support sleepy 770 nodes, other specifications define application layer functionality 771 for the same purpose. The Lightweight Machine-to-Machine (LWM2M) 772 specification from the Open Mobile Alliance (OMA) defines a Queue 773 Mode whereby an LWM2M Server queues requests to an LWM2M Client until 774 the latter (which may often stay in sleep mode) is online. LWM2M 775 functionality operates on top of CoAP. 777 oneM2M defines a CoAP binding with an application layer mechanism for 778 sleepy nodes [oneM2M]. 780 6.3. CoAP timers 782 CoAP offers mechanisms for reliable communication between two CoAP 783 endpoints. A CoAP message may be signaled as a confirmable (CON) 784 message, and an acknowledgment (ACK) is issued by the receiver if the 785 CON message is correctly received. The sender starts a 786 Retransmission TimeOut (RTO) for every CON message sent. The initial 787 RTO value is chosen randomly between 2 and 3 s. If an RTO expires, 788 the new RTO value is doubled (unless a limit on the number of 789 retransmissions has been reached). Since duty-cycling at the link 790 layer may lead to long latency (i.e. even greater than the initial 791 RTO value), CoAP RTO parameters should be tuned accordingly in order 792 to avoid spurious RTOs which would unnecessarily waste node energy 793 and other resources. On the other hand, note that CoAP can also run 794 on top of TCP [I-D.ietf-core-coap-tcp-tls]. In that case, similar 795 guidance applies to TCP timers, albeit with greater motivation to 796 carefully configure TCP RTO parameters, since [RFC6298] reduced the 797 default initial TCP RTO to 1 second, which may interact more 798 negatively with duty-cycled links than default CoAP RTO values. 800 6.4. Data compression 802 Another method intended to reduce the size of the data units to be 803 communicated in constrained-node networks is data compression, which 804 allows to encode data using less bits than the original data 805 representation. Data compression is more efficient at higher layers, 806 particularly before encryption is used. In fact, encryption 807 mechanisms may generate an output that does not contain redundancy, 808 making it almost impossible to reduce the data representation size. 809 In CoAP, messages may be encrypted by using DTLS (or TLS when CoAP 810 over TCP is used), which is the default mechanism for securing CoAP 811 exchanges. 813 7. Summary and Conclusions 815 We summarize the key takeaways in this document: 817 a. Internet protocols designed by IETF can be considered as the 818 customer of the lower layers (PHY, MAC, and Duty-cycling). To 819 reduce power consumption, it is recommended that Layer 3 designs 820 should operate based on awareness of lower-level parameters 821 rather than treating the lower layer as a black box (Sections 4, 822 5 and 6). 824 b. It is always useful to compress the protocol headers in order to 825 reduce the transmission/reception power. This design principle 826 has been employed by many protocols in 6Lo and CoRE working group 827 (Sections 4 and 6). 829 c. Broadcast and non-synchronized transmissions consume more than 830 other TX/RX operations. If protocols must use these ways to 831 collect information, reduction of their usage by aggregating 832 similar messages together will be helpful in saving power 833 (Sections 2 and 6.1). 835 d. Saving power by sleeping as much as possible is used widely 836 (Section 3). 838 8. Contributors 840 Jens T. Petersen, RTX, contributed the section on power save 841 services in DECT ULE. 843 9. Acknowledgments 845 Carles Gomez has been supported by the Spanish Government, FEDER and 846 the ERDF through projects TEC2012-32531 and TEC2016-79988-P. 848 Authors would like to thank the review and feedback from a number of 849 experts in this area: Carsten Bormann, Ari Keranen, Hannes 850 Tschofenig, Dominique Barthel, Bernie Volz and Charlie Perkins. 852 The text of this document was improved based on IESG Document Editing 853 session during IETF87. Thanks to Ted Lemon and Joel Jaeglli for 854 initiating and facilitating this editing session. 856 10. IANA Considerations 858 This document has no IANA requests. 860 11. Security Considerations 862 This document discusses the energy efficient protocol design, and 863 does not incur any changes or challenges on security issues besides 864 what the protocol specifications have analyzed. 866 12. References 868 12.1. Normative References 870 [Bluetooth42] 871 Bluetooth Special Interest Group, "Bluetooth Core 872 Specification Version 4.2", December 2014, 873 . 876 [EN300] ETSI, "Digital Enhanced Cordless Telecommunications 877 (DECT); Common Interface (CI)", March 2015, 878 . 882 [fifteendotfour] 883 IEEE Computer Society, "IEEE Std. 802.15.4-2015 IEEE 884 Standard for Local and metropolitan area networks--Part 885 15.4: Low-Rate Wireless Personal Area Networks (LR- 886 WPANs)", 2015, . 889 [G9959] International Telecommunication Union, "Short range 890 narrow-band digital radiocommunication transceivers - PHY 891 and MAC layer specifications, ITU-T Recommendation 892 G.9959", January 2015, 893 . 895 [IEEE80211v] 896 IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) 897 and Physical Layer (PHY) specifications, Amendment 8: IEEE 898 802.11 Wireless Network Management.", February 2012. 900 [MSTP] ANSI/ASHRAE, "Addenda: BACnet -- A Data Communication 901 Protocol for Building Automation and Control Networks, 902 ANSI/ASHRAE Addenda an, at, au, av, aw, ax, and az to 903 ANSI/ASHRAE Standard 135-2012", July 2014, 904 . 907 [NFC] NFC Forum, "NFC Logical Link Control Protocol version 1.3, 908 NFC Forum Technical Specification", March 2016. 910 [oneM2M] oneM2M, "oneM2M specifications", 911 . 913 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 914 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 915 December 1998, . 917 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 918 "Transmission of IPv6 Packets over IEEE 802.15.4 919 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 920 . 922 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 923 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 924 March 2011, . 926 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 927 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 928 DOI 10.17487/RFC6282, September 2011, 929 . 931 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 932 "Computing TCP's Retransmission Timer", RFC 6298, 933 DOI 10.17487/RFC6298, June 2011, 934 . 936 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 937 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 938 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 939 Low-Power and Lossy Networks", RFC 6550, 940 DOI 10.17487/RFC6550, March 2012, 941 . 943 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 944 and D. Barthel, "Routing Metrics Used for Path Calculation 945 in Low-Power and Lossy Networks", RFC 6551, 946 DOI 10.17487/RFC6551, March 2012, 947 . 949 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 950 Bormann, "Neighbor Discovery Optimization for IPv6 over 951 Low-Power Wireless Personal Area Networks (6LoWPANs)", 952 RFC 6775, DOI 10.17487/RFC6775, November 2012, 953 . 955 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 956 Constrained-Node Networks", RFC 7228, 957 DOI 10.17487/RFC7228, May 2014, 958 . 960 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 961 Application Protocol (CoAP)", RFC 7252, 962 DOI 10.17487/RFC7252, June 2014, 963 . 965 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 966 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 967 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 968 . 970 [TS102] ETSI, "Digital Enhanced Cordless Telecommunications 971 (DECT); Ultra Low Energy (ULE); Machine to Machine 972 Communications; Part 2: Home Automation Network (phase 2", 973 March 2015, . 977 12.2. Informative References 979 [AN079] Kim, C., "Measuring Power Consumption of CC2530 With 980 Z-Stack", September 2012, 981 . 983 [ContikiMAC] 984 Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, 985 SICS Technical Report T2011:13", December 2011, 986 . 990 [I-D.bormann-lwig-7228bis] 991 Bormann, C., Ersue, M., Keranen, A., and C. Gomez, 992 "Terminology for Constrained-Node Networks", draft- 993 bormann-lwig-7228bis-01 (work in progress), May 2017. 995 [I-D.ietf-6lo-dect-ule] 996 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 997 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 998 Energy", draft-ietf-6lo-dect-ule-09 (work in progress), 999 December 2016. 1001 [I-D.ietf-6man-impatient-nud] 1002 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 1003 Detection is too impatient", draft-ietf-6man-impatient- 1004 nud-07 (work in progress), October 2013. 1006 [I-D.ietf-6tisch-architecture] 1007 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1008 of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work 1009 in progress), August 2017. 1011 [I-D.ietf-6tisch-minimal] 1012 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 1013 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 1014 in progress), February 2017. 1016 [I-D.ietf-core-coap-pubsub] 1017 Koster, M., Keranen, A., and J. Jimenez, "Publish- 1018 Subscribe Broker for the Constrained Application Protocol 1019 (CoAP)", draft-ietf-core-coap-pubsub-02 (work in 1020 progress), July 2017. 1022 [I-D.ietf-core-coap-tcp-tls] 1023 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1024 Silverajan, B., and B. Raymor, "CoAP (Constrained 1025 Application Protocol) over TCP, TLS, and WebSockets", 1026 draft-ietf-core-coap-tcp-tls-09 (work in progress), May 1027 2017. 1029 [I-D.ietf-core-resource-directory] 1030 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 1031 Amsuess, "CoRE Resource Directory", draft-ietf-core- 1032 resource-directory-11 (work in progress), July 2017. 1034 [I-D.ietf-lwig-crypto-sensors] 1035 Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical 1036 Considerations and Implementation Experiences in Securing 1037 Smart Object Networks", draft-ietf-lwig-crypto-sensors-04 1038 (work in progress), August 2017. 1040 [I-D.kovatsch-lwig-class1-coap] 1041 Kovatsch, M., "Implementing CoAP for Class 1 Devices", 1042 draft-kovatsch-lwig-class1-coap-00 (work in progress), 1043 October 2012. 1045 [I-D.rahman-core-sleepy-nodes-do-we-need] 1046 Rahman, A., "Sleepy Devices: Do we need to Support them in 1047 CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work 1048 in progress), February 2014. 1050 [Powertrace] 1051 Dunkels, Eriksson, Finne, and Tsiftes, "Powertrace: 1052 Network-level Power Profiling for Low-power Wireless 1053 Networks", March 2011, . 1056 Authors' Addresses 1058 Carles Gomez 1059 Universitat Politecnica de Catalunya 1060 C/Esteve Terradas, 7 1061 Castelldefels 08860 1062 Spain 1064 Email: carlesgo@entel.upc.edu 1066 Matthias Kovatsch 1067 ETH Zurich 1068 Universitaetstrasse 6 1069 Zurich, CH-8092 1070 Switzerland 1072 Email: kovatsch@inf.ethz.ch 1074 Hui Tian 1075 China Academy of Telecommunication Research 1076 Huayuanbeilu No.52 1077 Beijing, Haidian District 100191 1078 China 1080 Email: tianhui@ritt.cn 1081 Zhen Cao (editor) 1082 Huawei Technologies 1083 China 1085 Email: zhencao.ietf@gmail.com