idnits 2.17.1 draft-ietf-lwig-energy-efficient-06.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 doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (February 8, 2017) is 2632 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6690' is defined on line 835, but no explicit reference was found in the text == Unused Reference: 'Announcementlayer' is defined on line 869, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-bormann-lwig-7228bis-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-19 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-09 == Outdated reference: A later version (-06) exists of draft-ietf-lwig-crypto-sensors-01 Summary: 0 errors (**), 0 flaws (~~), 10 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/i2CAT 4 Intended status: Informational M. Kovatsch 5 Expires: August 12, 2017 ETH Zurich 6 H. Tian 7 China Academy of Telecommunication Research 8 Z. Cao, Ed. 9 Huawei Technologies 10 February 8, 2017 12 Energy-Efficient Features of Internet of Things Protocols 13 draft-ietf-lwig-energy-efficient-06 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 http://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 August 12, 2017. 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 (http://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. Conventions used in this document . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5 66 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 67 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 68 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7 70 3.5. Power save services available in example low-power radios 8 71 3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8 72 3.5.2. Power Save Services Provided by Bluetooth LE . . . . 9 73 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10 74 3.5.4. Power Save Services in DECT ULE . . . . . . . . . . . 12 75 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 13 76 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 15 79 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 15 80 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 16 81 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 84 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 12.2. Informative References . . . . . . . . . . . . . . . . . 19 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 91 1. Introduction 93 Network systems for physical world monitoring contain many battery- 94 powered or energy-harvesting devices. For example, in an 95 environmental monitoring system, or a temperature and humidity 96 monitoring system, there are no always-on and sustained power 97 supplies for the potentially large number of constrained devices. In 98 such deployment scenarios, it is necessary to optimize the energy 99 consumption of the constrained devices. 101 A large body of research efforts have been put on this "energy 102 efficiency" problem. Most of this research has focused on how to 103 optimize the system's power consumption regarding a certain 104 deployment scenario or how could an existing network function such as 105 routing or security be more energy-efficient. Only few efforts 106 focused on energy-efficient designs for IETF protocols and 107 standardized network stacks for such constrained devices 108 [I-D.kovatsch-lwig-class1-coap]. 110 The IETF has developed a suite of Internet protocols suitable for 111 such constrained devices, including IPv6 over Low-Power Wireless 112 Personal Area Networks (6LoWPAN) [RFC6282],[RFC6775],[RFC4944], the 113 IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) 114 [RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. 115 This document tries to summarize the design considerations for making 116 the IETF constrained protocol suite as energy-efficient as possible. 117 While this document does not provide detailed and systematic 118 solutions to the energy efficiency problem, it summarizes the design 119 efforts and analyzes the design space of this problem. In 120 particular, it provides an overview of the techniques used by the 121 lower layers to save energy and how these may impact on the upper 122 layers. 124 After reviewing the energy-efficient design of each layer, an overall 125 conclusion is summarized. Though the lower layer communication 126 optimization is the key part of energy efficient design, the protocol 127 design at the upper layers is also important to make the device 128 energy-efficient. 130 1.1. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119] 136 1.2. Terminology 138 The terminologies used in this document can be referred to [RFC7228] 139 [I-D.bormann-lwig-7228bis]. 141 2. Overview 143 The IETF has developed protocols to enable end-to-end IP 144 communication between constrained nodes and fully capable nodes. 145 This work has witnessed the evolution of the traditional Internet 146 protocol stack to a light-weight Internet protocol stack. As shown 147 in Figure 1 below, the IETF has developed CoAP as the application 148 layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE 149 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL 150 and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently 151 being adapted by the 6lo working group to support IPv6 over various 152 other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and 153 NFC. 155 +-----+ +-----+ +-----+ +------+ 156 |HTTP | | FTP | |SNMP | | CoAP | 157 +-----+ +-----+ +-----+ +------+ 158 \ / / / \ 159 +-----+ +-----+ +-----+ +-----+ 160 | TCP | | UDP | | TCP | | UDP | 161 +-----+ +-----+ ===> +-----+ +-----+ 162 \ / \ / 163 +-----+ +------+ +-------+ +------+ +-----+ 164 | RTG |--| IPv6 |--|ICMP/ND| | IPv6 |---| RPL | 165 +-----+ +------+ +-------+ +------+ +-----+ 166 | | 167 +-------+ +-------+ +----------+ 168 |MAC/PHY| | 6Lo |--|6LoWPAN-ND| 169 +-------+ +-------+ +----------+ 170 | 171 +-------+ 172 |MAC/PHY| 173 +-------+ 175 Figure 1: Traditional and Light-weight Internet Protocol Stack 177 There are numerous published studies reporting comprehensive 178 measurements of wireless communication platforms [Powertrace]. As an 179 example, below we list the energy consumption profile of the most 180 common operations involved in communication on a prevalent sensor 181 node platform. The measurement was based on the Tmote Sky with 182 ContikiMAC [ContikiMAC] as the radio duty cycling algorithm. From 183 this and many other measurement reports (e.g. [AN053]), we can see 184 that the energy consumption of optimized transmission and reception 185 are in the same order. For IEEE 802.15.4 and Ultra WideBand (UWB) 186 links, transmitting may actually be even cheaper than receiving. It 187 also shows that broadcast and non-synchronized communication 188 transmissions are energy costly because they need to acquire the 189 medium for a long time. 191 +---------------------------------------+---------------+ 192 | Activity | Energy (uJ) | 193 +---------------------------------------+---------------+ 194 | Broadcast reception | 178 | 195 +---------------------------------------+---------------+ 196 | Unicast reception | 222 | 197 +---------------------------------------+---------------+ 198 | Broadcast transmission | 1790 | 199 +---------------------------------------+---------------+ 200 | Non-synchronized unicast transmission | 1090 | 201 +---------------------------------------+---------------+ 202 | Synchronized unicast transmission | 120 | 203 +---------------------------------------+---------------+ 204 | Unicast TX to awake receiver | 96 | 205 +---------------------------------------+---------------+ 207 Figure 2: Power consumption of common operations involved in 208 communication on the Tmote Sky with ContikiMAC 210 3. MAC and Radio Duty Cycling 212 In low-power wireless networks, communication and power consumption 213 are intertwined. The communication device is typically the most 214 power-consuming component, but merely refraining from transmissions 215 is not enough to attain a low power consumption: the radio may 216 consume as much power in listen mode as when actively transmitting. 217 This augments the key problem known as idle listening, whereby the 218 radio of a device may be in receive mode (ready to receive any 219 message), even if no message is being transmitted to that device. 220 Idle listening consumes a huge amount of energy unnecessarily. To 221 reduce power consumption, the radio must be switched completely off 222 -- duty-cycled -- as much as possible. By applying duty-cycling, the 223 lifetime of a device operating on a common button battery may be in 224 the order of years, whereas otherwise the battery may be exhausted in 225 a few days or even hours. Duty-cycling is a technique generally 226 employed by devices that use the P1 strategy [RFC7228], which need to 227 be able to communicate on a relatively frequent basis. Note that a 228 more aggressive approach to save energy relies on the P0, Normally- 229 off strategy, whereby devices sleep for very long periods and 230 communicate infrequently, even though they spend energy in network 231 reattachment procedures. 233 From the perspective of MAC&RDC, all upper layer protocols, such as 234 routing, RESTful communication, adaptation, and management flows, are 235 all applications. Since the duty cycling algorithm is the key to 236 energy-efficiency of the wireless medium, it synchronizes the 237 transmission and/or reception request from the higher layer. 239 The MAC&RDC are not in the scope of the IETF, yet lower layer 240 designers and chipset manufactures take great care of the problem. 241 For the IETF protocol designers, however, it is good to know the 242 behaviors of lower layers so that the designed protocols can work 243 perfectly with them. 245 Once again, the IETF protocols we are going to talk about in the 246 following sections are the customers of the lower layers. If the 247 different protocol layers want to get better service in a cooperative 248 way, they should be considerate and understand each other. 250 3.1. Radio Duty Cycling techniques 252 This subsection describes the main three RDC techniques. Note that 253 more than one of the presented techniques may be available or can 254 even be combined in a specific radio technology: 256 a) Channel sampling. In this solution, the radio interface of a 257 device periodically monitors the channel for very short time 258 intervals (i.e. with a low duty cycle) with the aim of detecting 259 incoming transmissions. In order to make sure that a receiver can 260 correctly receive a transmitted data unit, the sender may prepend a 261 preamble of a duration at least the sampling period to the data unit 262 to be sent. Another option for the sender is to repeatedly transmit 263 the data unit, instead of sending a preamble before the data unit. 264 Once a transmission is detected by a receiver, the receiver may stay 265 awake until the complete reception of the data unit. Examples of 266 radio technologies that use preamble sampling include ContikiMAC, the 267 Coordinated Sampled Listening (CSL) mode of IEEE 802.15.4e, and the 268 Frequently Listening (FL) mode of ITU-T G.9959. 270 b) Scheduled transmissions. This approach allows a device to know 271 the instants in which it should be awake (during some time interval) 272 in order to receive data units. Otherwise, the device may remain in 273 sleep mode. The decision on the instants that will be used for 274 communication is reached by means of some form of negotation between 275 the involved devices. Such negotiation may be performed per 276 transmission or per session/connection. Bluetooth Low Energy 277 (Bluetooth LE) is an example of a radio technology based on this 278 mechanism. 280 c) Listen after send. This technique allows a node to remain in 281 sleep mode by default, wake up and poll a sender (which must be ready 282 to receive a poll message) for pending transmissions. After sending 283 the poll message, the node remains in receive mode, ready for a 284 potential incoming transmission. After a certain time interval, the 285 node may go back to sleep. For example, the Receiver Initiated 286 Transmission (RIT) mode of 802.15.4e, and the transmission of data 287 between a coordinator and a device in IEEE 802.15.4-2003 use this 288 technique. 290 3.2. Latency and buffering 292 The latency of a data unit transmission to a duty-cycled device is 293 equal to or greater than the latency of transmitting to an always-on 294 device. Therefore, duty-cycling leads to a trade-off between energy 295 consumption and latency. Note that in addition to a latency 296 increase, RDC may introduce latency variance, since the latency 297 increase is a random variable (which is uniformly distributed if 298 duty-cycling follows a periodical behavior). 300 On the other hand, due to the latency increase of duty-cycling, a 301 sender waiting for a transmission opportunity may need to store 302 subsequent outgoing packets in a buffer, increasing memory 303 requirements and potentially incurring queuing waiting time that 304 contributes to the packet overall delay and increases the probability 305 of buffer overflow, leading to losses. 307 3.3. Throughput 309 Although throughput is not typically a key concern in constrained 310 node network applications, it is indeed important in some services in 311 this kind of networks, such as over-the-air software updates or when 312 off-line sensors accumulate measurements that have to be quickly 313 transferred when there is a connectivity opportunity. 315 Since RDC introduces inactive intervals in energy-constrained 316 devices, it reduces the throughput that can achieved when 317 communicating with such devices. There exists a trade-off between 318 the achievable throughput and energy consumption. 320 3.4. Radio interface tuning 322 The parameters controlling the radio duty cycle have to be carefully 323 tuned to achieve the intended application and/or network 324 requirements. On the other hand, upper layers should take into 325 account the expected latency and/or throughput behavior due to RDC. 326 The next subsection provides details on key parameters controlling 327 RDC mechanisms, and thus fundamental trade-offs, for various examples 328 of relevant low-power radio technologies. 330 3.5. Power save services available in example low-power radios 332 This subsection presents power save services and techniques used in a 333 few relevant examples of wireless low-power radios: IEEE 802.11, 334 Bluetooth LE and IEEE 802.15.4. For a more detailed overview of each 335 technology, the reader may refer to the literature or to the 336 corresponding specifications. 338 3.5.1. Power Save Services Provided by IEEE 802.11 340 IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may 341 indicate to an Access Point (AP) that it will enter a sleep mode 342 state. While the station is sleeping, the AP buffers any frames that 343 should be sent to the sleeping station. The station wakes up every 344 Listen Interval (which can be a multiple of the Beacon Interval) in 345 order to receive beacons. The AP signals in the beacon whether there 346 is data pending for the station or not. If there are not frames to 347 be sent to the station, the latter may get back to sleep mode. 348 Otherwise, the station may send a message requesting the transmission 349 of the buffered data and stay awake in receive mode. 351 IEEE 802.11v [IEEE80211v] further defines mechanisms and services for 352 power save of stations/nodes that include flexible multicast service 353 (FMS), proxy ARP advertisement, extended sleep modes, traffic 354 filtering. It would be useful if upper layer protocols knows such 355 capabilities provided by the lower layer, so that they can coordinate 356 with each other. 358 These services include: 360 Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to 361 indicate that the non-AP station (STA) will not receive ARP frames. 362 The Proxy ARP capability enables the non-AP STA to remain in power- 363 save for longer periods of time. 365 Basic Service Set (BSS) Max Idle Period management enables an AP to 366 indicate a time period during which the AP does not disassociate a 367 STA due to non-receipt of frames from the STA. This supports 368 improved STA power saving and AP resource management. 370 FMS: A service in which a non-access point (non-AP) station (STA) can 371 request a multicast delivery interval longer than the delivery 372 traffic indication message (DTIM) interval for the purposes of 373 lengthening the period of time a STA may be in a power save state. 375 Traffic Filtering Service (TFS): A service provided by an access 376 point (AP) to a non-AP station (STA) that can reduce the number of 377 frames sent to the non-AP STA by not forwarding individually 378 addressed frames addressed to the non-AP STA that do not match 379 traffic filters specified by the non-AP STA. 381 Using the above services provided by the lower layer, the constrained 382 nodes can achieve either client initiated power save (via TFS) or 383 network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). 385 Upper layer protocols would better synchronize with the parameters 386 such as FMS interval and BSS MAX Idle Period, so that the wireless 387 transmissions are not triggered periodically. 389 3.5.2. Power Save Services Provided by Bluetooth LE 391 Bluetooth LE is a wireless low-power communications technology that 392 is the hallmark component of the Bluetooth 4.0, 4.1 and 4.2 393 specifications [Bluetooth42]. BT-LE has been designed for the goal 394 of ultra-low-power consumption. Currently, it is possible to run 395 IPv6 over Bluetooth LE networks by using a 6LoWPAN variant adapted to 396 BT-LE [RFC7668]. 398 Bluetooth LE networks comprise a master and one or more slaves which 399 are connected to the master. The Bluetooth LE master is assumed to 400 be a relatively powerful device, whereas a slave is typically a 401 constrained device (e.g. a class 1 device). 403 Medium access in Bluetooth LE is based on a Time Division Multiple 404 Access (TDMA) scheme which is coordinated by the master. This device 405 determines the start of connection events, in which communication 406 between the master and a slave takes place. At the beginning of a 407 connection event, the master sends a poll message, which may 408 encapsulate data, to the slave. The latter must send a response, 409 which may also contain data. The master and the slave may continue 410 exchanging data until the end of the connection event. The next 411 opportunity for communication between the master and the slave will 412 be in the next connection event scheduled for the slave. 414 The time between consecutive connection events is defined by the 415 connInterval parameter, which may range between 7.5 ms and 4 s. The 416 slave may remain in sleep mode since the end of its last connection 417 event until the beginning of its next connection event. Therefore, 418 Bluetooth LE is duty-cycled by nature. Furthermore, after having 419 replied to the master, a slave is not required to listen to the 420 master (and thus may keep the radio in sleep mode) for 421 connSlaveLatency consecutive connection events. connSlaveLatency is 422 an integer parameter between 0 and 499 which should not cause link 423 inactivity for more than connSupervisionTimeout time. The 424 connSupervisionTimeout parameter is in the range between 100 ms and 425 32 s. 427 Upper layer protocols should take into account the medium access and 428 duty-cycling behavior of Bluetooth LE. In particular, connInterval, 429 connSlaveLatency and connSupervisionTimeout determine the time 430 between two consecutive connection events for a given slave. The 431 upper layer packet generation pattern and rate should be consistent 432 with the settings of the aforementioned parameters (and vice versa). 434 3.5.3. Power Save Services in IEEE 802.15.4 436 IEEE 802.15.4 is a family of standard radio interfaces for low-rate, 437 low-power wireless networking [fifteendotfour]. Since the 438 publication of its first version in 2003, IEEE 802.15.4 has become 439 the de-facto choice for a wide range of constrained node network 440 application domains and has been a primary target technology of 441 various IETF working groups such as 6LoWPAN 442 [RFC6282],[RFC6775],[RFC4944] and 6TiSCH 443 [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC 444 layer functionality. 446 IEEE 802.15.4 defines three roles called device, coordinator and 447 Personal Area Network (PAN) coordinator. The device role is adequate 448 for nodes that do not implement the complete IEEE 802.15.4 449 functionality, and is mainly targeted for constrained nodes with a 450 limited energy source. The coordinator role includes synchronization 451 capabilities and is suitable for nodes that do not suffer severe 452 constraints (e.g. a mains-powered node). The PAN coordinator is a 453 special type of coordinator that acts as a principal controller in an 454 IEEE 802.15.4 network. 456 IEEE 802.15.4 has mainly defined two types of networks depending on 457 their configuration: beacon-enabled and nonbeacon-enabled networks. 458 In the first network type, coordinators periodically transmit 459 beacons. The time between beacons is divided in three main parts: 460 the Contention Access Period (CAP), the Contention Free Period (CFP) 461 and an inactive period. In the first period, nodes use slotted 462 Carrier Sense Multiple Access / Collision Avoidance (CSMA/CA) for 463 data communication. In the second one, a TDMA scheme controls medium 464 access. During the idle period, communication does not take place, 465 thus the inactive period is a good opportunity for nodes to turn the 466 radio off and save energy. The coordinator announces in each beacon 467 the list of nodes for which data will be sent in the subsequent 468 period. Therefore, devices may remain in sleep mode by default and 469 wake up periodically to listen to the beacons sent by their 470 coordinator. If a device wants to transmit data, or learns from a 471 beacon that it is an intended destination, then it will exchange 472 messages with the coordinator and will thus consume energy. An 473 underlying assumption is that when a message is sent to a 474 coordinator, the radio of the latter will be ready to receive the 475 message. 477 The beacon interval and the duration of the beacon interval active 478 portion (i.e. the CAP and the CFP), and thus the duty cycle, can be 479 configured. The parameters that control these times are called 480 macBeaconOrder and macSuperframeOrder, respectively. As an example, 481 when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be 482 (independently) set to values in the range between 15.36 ms and 251.6 483 s. 485 In the beaconless mode, nodes use unslotted CSMA/CA for data 486 transmission. The device may be in sleep mode by default and may 487 activate its radio to either i) request to the coordinator whether 488 there is pending data for the device, or ii) to transmit data to the 489 coordinator. The wake-up pattern of the device, if any, is out of 490 the scope of IEEE 802.15.4. 492 Communication between the two ends of an IEEE 802.15.4 link may also 493 take place in a peer-to-peer configuration, whereby both link ends 494 assume the same role. In this case, data transmission can happen at 495 any moment. Nodes must have their radio in receive mode, and be 496 ready to listen to the medium by default (which for battery-enabled 497 nodes may lead to a quick battery depletion), or apply 498 synchronization techniques. The latter are out of the scope of IEEE 499 802.15.4. 501 The main MAC layer IEEE 802.15.4 amendment to date is IEEE 802.15.4e. 502 This amendment includes various new MAC layer modes, some of which 503 include mechanisms for low energy consumption. Among these, the 504 Time-Slotted Channel Hopping (TSCH) is an outstanding mode which 505 offers robust features for industrial environments, among others. In 506 order to provide the functionality needed to enable IPv6 over TSCH, 507 the 6TiSCH working group was created. TSCH is based on a TDMA 508 schedule whereby a set of time slots are used for frame transmission 509 and reception, and other time slots are unscheduled. The latter time 510 slots may be used by a dynamic scheduling mechanism, otherwise nodes 511 may keep the radio off during the unscheduled time slots, thus saving 512 energy. The minimal schedule configuration specified in 513 [I-D.ietf-6tisch-minimal] comprises 101 time slots, whereby 95 of 514 these time slots are unscheduled and the time slot duration is 15 ms. 516 Other 802.15.4e modes, which are in fact designed for low energy, are 517 the previously mentioned CSL and RIT. 519 3.5.4. Power Save Services in DECT ULE 521 DECT Ultra Low Energy (DECT ULE) is a wireless technology building on 522 the key fundamentals of traditional DECT / CAT-iq [EN300] but with 523 specific changes to significantly reduce the power consumption on the 524 expense of data throughput as specified in [TS102]. DECT ULE devices 525 typically operates on special power optimized silicon, but can 526 connect to a DECT Gateway supporting traditional DECT / CAT-iq for 527 cordless telephony and data as well as the DECT ULE extensions. It 528 is possible to run IPv6 over DECT ULE by using a 6LoWPAN variant 529 adapted for DECT ULE [I-D.ietf-6lo-dect-ule]. 531 DECT terminology operates with two major role definitions: The 532 Portable Part (PP) is the power constrained device, while the Fixed 533 Part (FP) is the Gateway or base station in a star topology. DECT is 534 operating in license free and reserved frequency bands based on TDMA/ 535 FDMA and TDD using dynamic channel allocation for interference 536 avoidance. It provides good indoor (~50 m) and outdoor (~300 m) 537 coverage. It is using a frame length of 10 ms, which is divided into 538 24 timeslots and it is supporting connection oriented, packet data 539 and connection less services. 541 The FP usually transmits a so-called dummy bearer (beacon) that is 542 used to broadcast synchronization, system and paging information. 543 The slot/carrier position of this dummy bearer can automatically be 544 reallocated in order to avoid mutual interference with other DECT 545 signals. 547 At MAC level DECT ULE communications between FP and PP are initiated 548 by the PP. A FP can initiate communication indirectly by sending 549 paging signal to a PP. The PP determines the timeslot and frequency 550 on which the communication between FP and PP takes place. The PP 551 verifies the radio timeslot/frequency position is unoccupied before 552 it initiates its transmitter. An access-request message, which 553 usually carries data, is sent to the FP. The FP sends a confirm 554 message, which also may carry data. More data can be sent in 555 subsequent frames. A MAC level automatic retransmission scheme 556 improves data transfer reliability significant. A segmentation and 557 reassembly scheme supports transfer of larger higher layer SDUs and 558 provides data integrity check. The DECT ULE packet data service 559 ensures data integrity, proper sequencing, duplicate protection, but 560 does not guaranteed delivery. Higher layers protocols have to take 561 this into considerations. 563 The FP may send paging information to PPs to trigger connection setup 564 and indicate required service type. The interval between paging 565 information to a specific PP can be defined in range 10 ms to 327 566 seconds. The PP may enter sleep mode to save power. The listening 567 interval is defined by the PP application. For short sleep intervals 568 (below ~10 seconds) the PP may be able to retain synchronization to 569 the FP dummy bearer and only turn on the receiver during the expected 570 timeslot. For longer sleep intervals the PP can't keep 571 synchronization and has to search for and resynchronize to the FP 572 dummybearer. Hence, longer sleep interval reduces the average energy 573 consumption, but adds a energy consumption penalty for acquiring 574 synchronization to the FP dummy bearer. The PP can obtain all 575 information to determine paging and acquire synchronization 576 information in a single reception of one full timeslot. 578 Packet data latency is normally 30 ms for short packets (below or 579 equal to 32 octets), however if retry and back-off scenarios occur, 580 the latency is increased. The latency can actually be reduced to 581 about 10 ms by doing energy consuming RSSI scanning in advance. In 582 the direction from FP to PP the latency is usually increased by the 583 used paging interval and the sleep interval. The MAC layer can 584 piggyback commands to improve efficiency (reduce latency) of higher 585 layer protocols. Such commands can instruct the PP to initiate a new 586 packet transfer in N frames without the need for resynchronization 587 and listening to paging or instruct the PP to stay in a higher duty 588 cycle paging detection mode. 590 The DECT ULE technology allows per PP configuration of paging 591 interval, MTU size, reassembly window size and higher layer service 592 negotiation and protocol. 594 4. IP Adaptation and Transport Layer 596 6LoWPAN is the adaption layer to run IPv6 over IEEE 802.15.4 MAC&PHY. 597 It was born to fill the gap that the IPv6 layer does not support 598 fragmentation and assembly of <1280-byte packets while IEEE 802.15.4 599 only supports a MTU of 127 bytes. 601 IPv6 is the basis for the higher layer protocols, including both TCP/ 602 UDP transport and applications. So they are quite ignorant of the 603 lower layers, and are almost neutral to the energy-efficiency 604 problem. 606 What the network stack can optimize is to save the computing power. 607 For example the Contiki implementation has multiple cross layer 608 optimizations for buffers and energy management, e.g., the computing 609 and validation of UDP/TCP checksums without the need of reading IP 610 headers from a different layer. These optimizations are software 611 implementation techniques, and out of the scope of IETF and the LWIG 612 working group. 614 6LoWPAN contributes to the energy-efficiency problem in two ways. 615 First of all, it swaps computing with communication. 6LoWPAN applies 616 compression of the IPv6 header. This means less amount of data will 617 be handled by the lower layer, but both the sender and receiver 618 should spend more computing power on the compression and 619 decompression of the packets over the air. Secondly, the 6LoWPAN 620 working group developed the energy-efficient Neighbor Discovery 621 called 6LoWPAN-ND, which is an energy efficient replacement of the 622 IPv6 ND in constrained environments. IPv6 Neighbor Discovery was not 623 designed for non-transitive wireless links, as its heavy use of 624 multicast makes it inefficient and sometimes impractical in a low- 625 power and lossy network. 6LoWPAN-ND describes simple optimizations to 626 IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate 627 address detection for Low-power Wireless Personal Area Networks and 628 similar networks. However, 6LoWPAN ND does not modify Neighbor 629 Unreachability Detection (NUD) timeouts, which are very short (by 630 default three transmissions spaced one second apart). NUD timeout 631 settings should be tuned taking into account the latency that may be 632 introduced by duty-cycled mechanisms at the link layer, or 633 alternative, less impatient NUD algorithms should be considered 634 [I-D.ietf-6man-impatient-nud]. 636 5. Routing Protocols 638 The routing protocol designed by the IETF for constrained 639 environments is called RPL [RFC6550]. As a routing protocol, RPL has 640 to exchange messages periodically and keep routing states for each 641 destination. RPL is optimized for the many-to-one communication 642 pattern, where network nodes primarily send data towards the border 643 router, but has provisions for any-to-any routing as well. 645 The authors of the Powertrace tool [Powertrace] studied the power 646 profile of RPL. It divides the routing protocol into control and 647 data traffic. The control channel uses ICMP messages to establish 648 and maintain the routing states. The data channel is any application 649 that uses RPL for routing packets. The study has shown that the 650 power consumption of the control traffic goes down over time in a 651 relatively stable network. The study also reflects that the routing 652 protocol should keep the control traffic as low as possible to make 653 it energy-friendly. The amount of RPL control traffic can be tuned 654 by setting the Trickle algorithm parameters (i.e. Imin, Imax and k) 655 to adequate values. However, there exists a trade-off between energy 656 consumption and other performance parameters such as network 657 convergence time and robustness. 659 RFC 6551 [RFC6551] defines routing metrics and constraints to be used 660 by RPL in route computation. Among others, RFC 6551 specifies a Node 661 Energy object that allows to provide information related to node 662 energy, such as the energy source type or the estimated percentage of 663 remaining energy. Appropriate use of energy-based routing metrics 664 may help to balance energy consumption of network nodes, minimize 665 network partitioning and increase network lifetime. 667 6. Application Layer 669 6.1. Energy efficient features in CoAP 671 CoAP [RFC7252] is designed as a RESTful application protocol, 672 connecting the services of smart devices to the World Wide Web. CoAP 673 is not a chatty protocol, it provides basic communication services 674 such as service discovery and GET/POST/PUT/DELETE methods with a 675 binary header. 677 The energy-efficient design is implicitly included in the CoAP 678 protocol design. CoAP uses a fixed-length binary header of only four 679 bytes that may be followed by binary options. To reduce regular and 680 frequent queries of the resources, CoAP provides an observe mode, in 681 which the requester registers its interest of a certain resource and 682 the responder will report the value whenever it was updated. This 683 reduces the request response round trips while keeping information 684 exchange a ubiquitous service and, most importantly, it allows an 685 energy-constrained server to remain in sleep mode during the period 686 between observe notification transmissions. 688 Furthermore, [RFC7252] defines CoAP proxies which can cache resource 689 representations previously provided by sleepy CoAP servers. The 690 proxies themselves may respond to client requests if the 691 corresponding server is sleeping and the resource representation is 692 recent enough. Otherwise, a proxy may attempt to obtain the resource 693 from the sleepy server. 695 6.2. Sleepy node support 697 Beyond these features of CoAP, there have been a number of proposals 698 to further support sleepy nodes at the application layer by 699 leveraging CoAP mechanisms. A good summary of such proposals can be 700 found in [I-D.rahman-core-sleepy-nodes-do-we-need], while an example 701 application (in the context of illustrating several security 702 mechanisms) in a scenario with sleepy devices has been described 703 [I-D.ietf-lwig-crypto-sensors]. The different approaches to support 704 sleepy nodes include exploiting the use of proxies, leveraging the 705 Resource Directory [I-D.ietf-core-resource-directory] or signaling 706 when a node is awake to the interested nodes. A more recent work 707 defines publish-subscribe and message queuing extensions to CoAP and 708 the Resource Directory in order to support devices that spend most of 709 their time in a sleeping state [I-D.ietf-core-coap-pubsub]. Notably, 710 this work has been adopted by the CoRE Working Group. 712 In addition to the work within the scope of CoAP to support sleepy 713 nodes, other specifications define application layer functionality 714 for the same purpose. The Lightweight Machine-to-Machine (LWM2M) 715 specification from the Open Mobile Alliance (OMA) defines a Queue 716 Mode whereby an LWM2M Server queues requests to an LWM2M Client until 717 the latter (which may often stay in sleep mode) is online. LWM2M 718 functionality operates on top of CoAP. 720 On the other hand, oneM2M defines a CoAP binding with an application 721 layer mechanism for sleepy nodes. 723 6.3. CoAP timers 725 CoAP offers mechanisms for reliable communication between two CoAP 726 endpoints. A CoAP message may be signaled as a confirmable (CON) 727 message, and an acknowledgment (ACK) is issued by the receiver if the 728 CON message is correctly received. The sender starts a 729 Retransmission TimeOut (RTO) for every CON message sent. The initial 730 RTO value is chosen randomly between 2 and 3 s. If an RTO expires, 731 the new RTO value is doubled (unless a limit on the number of 732 retransmissions has been reached). Since duty-cycling at the link 733 layer may lead to long latency (i.e. even greater than the initial 734 RTO value), CoAP RTO parameters should be tuned accordingly in order 735 to avoid spurious RTOs which would unnecessarily waste node energy 736 and other resources. 738 7. Summary 740 We summarize the key takeaways in this document: 742 a. Internet protocols designed by IETF can be considered as the 743 customer of the lower layers (PHY, MAC, and Duty-cycling). To 744 save power consumption, it is recommended to operate based on the 745 lower layer behavior rather than treating the lower layer as a 746 black box. 748 b. It is always useful to compress the protocol headers in order to 749 reduce the transmission/reception power. This design principles 750 have been employed by many protocols in 6Lo and CoRE working 751 group. 753 c. Broadcast and non-synchronized transmissions consume more than 754 other TX/RX operations. If protocols must use these ways to 755 collect information, reduction of their usage by aggregating 756 similar messages together will be helpful in saving power. 758 d. Saving power by sleeping occasionally is used widely. Reduction 759 of states is also an effective method to be energy efficient. 761 8. Contributors 763 Jens T. Petersen, RTX, contributed the section on power save 764 services in DECT ULE. 766 9. Acknowledgments 768 Carles Gomez has been supported by the Spanish Government, FEDER and 769 the ERDF through projects TEC2012-32531 and TEC2016-79988-P. 771 Authors would like to thank the review and feedback from a number of 772 experts in this area: Carsten Bormann, Ari Keranen, Hannes 773 Tschofenig, Dominique Barthel. 775 The text of this document was improved based on IESG Document Editing 776 session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to 777 initiate this facilities. 779 10. IANA Considerations 781 This document has no IANA requests. 783 11. Security Considerations 785 This document discusses the energy efficient protocol design, and 786 does not incur any changes or challenges on security issues besides 787 what the protocol specifications have analyzed. 789 12. References 791 12.1. Normative References 793 [Bluetooth42] 794 "Bluetooth Core Specification Version 4.2", 2014. 796 [EN300] ""Digital Enhanced Cordless Telecommunications (DECT); 797 Common Interface (CI);"", 2013. 799 [fifteendotfour] 800 "802.15.4-2011", 2011. 802 [IEEE80211v] 803 IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC) 804 and Physical Layer (PHY) specifications, Amendment 8: IEEE 805 802.11 Wireless Network Management.", February 2012. 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, 809 DOI 10.17487/RFC2119, March 1997, 810 . 812 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 813 "Transmission of IPv6 Packets over IEEE 802.15.4 814 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 815 . 817 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 818 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 819 DOI 10.17487/RFC6282, September 2011, 820 . 822 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 823 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 824 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 825 Low-Power and Lossy Networks", RFC 6550, 826 DOI 10.17487/RFC6550, March 2012, 827 . 829 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 830 and D. Barthel, "Routing Metrics Used for Path Calculation 831 in Low-Power and Lossy Networks", RFC 6551, 832 DOI 10.17487/RFC6551, March 2012, 833 . 835 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 836 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 837 . 839 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 840 Bormann, "Neighbor Discovery Optimization for IPv6 over 841 Low-Power Wireless Personal Area Networks (6LoWPANs)", 842 RFC 6775, DOI 10.17487/RFC6775, November 2012, 843 . 845 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 846 Constrained-Node Networks", RFC 7228, 847 DOI 10.17487/RFC7228, May 2014, 848 . 850 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 851 Application Protocol (CoAP)", RFC 7252, 852 DOI 10.17487/RFC7252, June 2014, 853 . 855 [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 856 Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low 857 Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, 858 . 860 [TS102] ""Digital Enhanced Cordless Telecommunications (DECT); 861 Ultra Low Energy (ULE); Machine to Machine Communications; 862 Part 1: Home Automation Network (phase 1)"", 2013. 864 12.2. Informative References 866 [AN053] Selvig, B., "Measuring power consumption with CC2430 and 867 Z-Stack". 869 [Announcementlayer] 870 Dunkels, A., "The Announcement Layer: Beacon Coordination 871 for the Sensornet Stack. In Proceedings of EWSN 2011". 873 [ContikiMAC] 874 Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, 875 SICS Technical Report T2011:13", December 2011. 877 [I-D.bormann-lwig-7228bis] 878 Bormann, C. and C. Gomez, "Terminology for Constrained- 879 Node Networks", draft-bormann-lwig-7228bis-00 (work in 880 progress), October 2016. 882 [I-D.ietf-6lo-dect-ule] 883 Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. 884 Barthel, "Transmission of IPv6 Packets over DECT Ultra Low 885 Energy", draft-ietf-6lo-dect-ule-09 (work in progress), 886 December 2016. 888 [I-D.ietf-6man-impatient-nud] 889 Nordmark, E. and I. Gashinsky, "Neighbor Unreachability 890 Detection is too impatient", draft-ietf-6man-impatient- 891 nud-07 (work in progress), October 2013. 893 [I-D.ietf-6tisch-architecture] 894 Thubert, P., "An Architecture for IPv6 over the TSCH mode 895 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 896 in progress), January 2017. 898 [I-D.ietf-6tisch-minimal] 899 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 900 6TiSCH Configuration", draft-ietf-6tisch-minimal-19 (work 901 in progress), January 2017. 903 [I-D.ietf-core-coap-pubsub] 904 Koster, M., Keranen, A., and J. Jimenez, "Publish- 905 Subscribe Broker for the Constrained Application Protocol 906 (CoAP)", draft-ietf-core-coap-pubsub-00 (work in 907 progress), October 2016. 909 [I-D.ietf-core-resource-directory] 910 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 911 Resource Directory", draft-ietf-core-resource-directory-09 912 (work in progress), October 2016. 914 [I-D.ietf-lwig-crypto-sensors] 915 Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical 916 Considerations and Implementation Experiences in Securing 917 Smart Object Networks", draft-ietf-lwig-crypto-sensors-01 918 (work in progress), October 2016. 920 [I-D.kovatsch-lwig-class1-coap] 921 Kovatsch, M., "Implementing CoAP for Class 1 Devices", 922 draft-kovatsch-lwig-class1-coap-00 (work in progress), 923 October 2012. 925 [I-D.rahman-core-sleepy-nodes-do-we-need] 926 Rahman, A., "Sleepy Devices: Do we need to Support them in 927 CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work 928 in progress), February 2014. 930 [Powertrace] 931 Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace: 932 Network-level Power Profiling for Low-power Wireless 933 Networks", March 2011. 935 Authors' Addresses 937 Carles Gomez 938 Universitat Politecnica de Catalunya/i2CAT 939 C/Esteve Terradas, 7 940 Castelldefels 08860 941 Spain 943 Email: carlesgo@entel.upc.edu 944 Matthias Kovatsch 945 ETH Zurich 946 Universitaetstrasse 6 947 Zurich, CH-8092 948 Switzerland 950 Email: kovatsch@inf.ethz.ch 952 Hui Tian 953 China Academy of Telecommunication Research 954 Huayuanbeilu No.52 955 Beijing, Haidian District 100191 956 China 958 Email: tianhui@mail.ritt.com.cn 960 Zhen Cao (editor) 961 Huawei Technologies 962 China 964 Email: zhencao.ietf@gmail.com