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