idnits 2.17.1 draft-ietf-lwig-cellular-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 date (January 4, 2016) is 3035 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-05 == Outdated reference: A later version (-06) exists of draft-jennings-core-senml-02 == Outdated reference: A later version (-01) exists of draft-aks-lwig-crypto-sensors-00 == Outdated reference: A later version (-05) exists of draft-koster-core-coap-pubsub-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft A. Eriksson 4 Intended status: Informational A. Keranen 5 Expires: July 7, 2016 Ericsson 6 January 4, 2016 8 Building Power-Efficient CoAP Devices for Cellular Networks 9 draft-ietf-lwig-cellular-06 11 Abstract 13 This memo discusses the use of the Constrained Application Protocol 14 (CoAP) protocol in building sensors and other devices that employ 15 cellular networks as a communications medium. Building communicating 16 devices that employ these networks is obviously well known, but this 17 memo focuses specifically on techniques necessary to minimize power 18 consumption. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 7, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Goals for Low-Power Operation . . . . . . . . . . . . . . . . 3 56 3. Link-Layer Assumptions . . . . . . . . . . . . . . . . . . . 5 57 4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. Discovery and Registration . . . . . . . . . . . . . . . . . 8 59 6. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 60 7. Real-Time Reachable Devices . . . . . . . . . . . . . . . . . 10 61 8. Sleepy Devices . . . . . . . . . . . . . . . . . . . . . . . 11 62 8.1. Implementation Considerations . . . . . . . . . . . . . . 12 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 67 11.2. Informative References . . . . . . . . . . . . . . . . . 14 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 This memo discusses the use of the Constrained Application Protocol 74 (CoAP) protocol [RFC7252] in building sensors and other devices that 75 employ cellular networks as a communications medium. Building 76 communicating devices that employ these networks is obviously well 77 known, but this memo focuses specifically on techniques necessary to 78 minimize power consumption. CoAP has many advantages, including 79 being simple to implement; a thousand lines for the entire software 80 above IP layer is plenty for a CoAP-based sensor, for instance. 81 However, while many of these advantages are obvious and easily 82 obtained, optimizing power consumption remains challenging and 83 requires careful design [I-D.arkko-core-sleepy-sensors]. 85 The memo targets primarily 3GPP cellular networks in their 2G, 3G, 86 and LTE variants and their future enhancements, including possible 87 power efficiency improvements at the radio and link layers. The 88 exact standards or details of the link layer or radios are not 89 relevant for our purposes, however. To be more precise, the material 90 in this memo is suitable for any large-scale, public network that 91 employs point-to-point communications model and radio technology for 92 the devices in the network. 94 Our focus is devices that need to be optimized for power usage, and 95 on devices that employ CoAP. As a general technology, CoAP is 96 similar to HTTP. It can be used in various ways and network entities 97 may take on different roles. This freedom allows the technology to 98 be used in efficient and less efficient ways. Some guidance is 99 needed to understand what communication models over CoAP are 100 recommended when low power usage is a critical goal. 102 The recommendations in this memo should be taken as complementary to 103 device hardware optimization, microelectronics improvements, and 104 further evolution of the underlying link and radio layers. Further 105 gains in power efficiency can certainly be gained on several fronts; 106 the approach that we take in this memo is to do what can be done at 107 the IP, transport, and application layers to provide the best 108 possible power efficiency. Application implementors generally have 109 to use the current generation microelectronics, currently available 110 radio networks and standards, and so on. This focus in our memo 111 should by no means be taken as an indication that further evolution 112 in these other areas is unnecessary. Such evolution is useful, is 113 ongoing, and is generally complementary to the techniques presented 114 in this memo. The evolution of underlying technologies may change 115 what techniques described here are useful for a particular 116 application, however. 118 The rest of this memo is structured as follows. Section 2 discusses 119 the need and goals for low-power devices. Section 3 outlines our 120 expectations for the low layer communications model. Section 4 121 describes the two scenarios that we address, and Section 5, 122 Section 6, Section 7 and Section 8 give guidelines for use of CoAP in 123 these scenarios. 125 2. Goals for Low-Power Operation 127 There are many situations where power usage optimization is 128 unnecessary. Optimization may not be necessary on devices that can 129 run on power feed over wired communications media, such as in Power- 130 over-Ethernet (PoE) solutions. These devices may require a 131 rudimentary level of power optimization techniques just to keep 132 overall energy costs and aggregate power feed sizes at a reasonable 133 level, but more extreme techniques necessary for battery powered 134 devices are not required. The situation is similar with devices that 135 can easily be connected to mains power. Other types of devices may 136 get an occasional charge of power from energy harvesting techniques. 137 For instance, some environmental sensors can run on solar cells. 138 Typically, these devices still have to regulate their power usage in 139 a strict manner, for instance to be able to use as small and 140 inexpensive solar cells as possible. 142 In battery operated devices the power usage is even more important. 143 For instance, one of the authors employs over a hundred different 144 sensor devices in his home network. A majority of these devices are 145 wired and run on PoE, but in most environments this would be 146 impractical because the necessary wires do not exist. The future is 147 in wireless solutions that can cover buildings and other environments 148 without assuming a pre-existing wired infrastructure. In addition, 149 in many cases it is impractical to provide a mains power source. 150 Often there are no power sockets easily available in the locations 151 that the devices need to be in, and even if there were, setting up 152 the wires and power adapters would be more complicated than 153 installing a standalone device without any wires. 155 Yet, with a large number of devices the battery lifetimes become 156 critical. Cost and practical limits dictate that devices can be 157 largely just bought and left on their own. For instance, with 158 hundred devices, even a ten-year battery lifetime results in a 159 monthly battery change for one device within the network. This may 160 be impractical in many environments. In addition, some devices may 161 be physically difficult to reach for a battery change. Or, a large 162 group of devices -- such as utility meters or environmental sensors 163 -- cannot be economically serviced too often, even if in theory the 164 batteries could be changed. 166 Many of these situations lead to a requirement for minimizing power 167 usage and/or maximizing battery lifetimes. Using the power usage 168 strategies described in [RFC7228], mains-powered sensor-type devices 169 can use the Always-on strategy whereas battery or energy harvesting 170 devices need to adjust behavior based on the communication interval. 171 For intervals in the order of seconds, Low-power strategy is 172 appropriate. For intervals ranging from minutes to hours either Low- 173 power or Normally-off strategies are suitable. Finally, for 174 intervals lasting days and longer, Normally-off is usually the best 175 choice. Unfortunately, much of our current technology has been built 176 with different objectives in mind. Networked devices that are 177 "always on", gadgets that require humans to recharge them every 178 couple of days, and protocols that have been optimized to maximize 179 throughput rather than conserve resources. 181 Long battery lifetimes are required for many applications, however. 182 In some cases these lifetimes should be in the order of years or even 183 a decade or longer. Some communication devices already reach multi- 184 year lifetimes, and continuous improvement in low-power electronics 185 and advances in radio technology keep pushing these lifetimes longer. 186 However, it is perhaps fair to say that battery lifetimes are 187 generally too short at present time. 189 Power usage can not be evaluated solely based on lower layer 190 communications. The entire system, including upper layer protocols 191 and applications is responsible for the power consumption as a whole. 192 The lower communication layers have already adopted many techniques 193 that can be used to reduce power usage, such as scheduling device 194 wake-up times. Further reductions will likely need some co-operation 195 from the upper layers so that unnecessary communications, denial-of- 196 service attacks on power consumption, and other power drains are 197 eliminated. 199 Of course, application requirements ultimately determine what kinds 200 of communications are necessary. For instance, some applications 201 require more data to be sent than others. The purpose of the 202 guidelines in this memo is not to prefer one or the other 203 application, but to provide guidance on how to minimize the amount of 204 communications overhead that is not directly required by the 205 application. While such optimization is generally useful, it is 206 relatively speaking most noticeable in applications that transfer 207 only a small amount of data, or operate only infrequently. 209 3. Link-Layer Assumptions 211 We assume that the underlying communications network can be any 212 large-scale, public network that employs point-to-point 213 communications model and radio technology. 2G, 3G, and LTE networks 214 are examples of such networks, but not the only possible networks 215 with these characteristics. 217 In the following we look at some of these characteristics and their 218 implications. Note that in most cases these characteristics are not 219 properties of the specific networks but rather inherent in the 220 concept of public networks. 222 Public networks 224 Using a public network service implies that applications can be 225 deployed without having to build a network to go with them. For 226 economic reasons, only the largest users (such as utility 227 companies) could afford to build their own network, and even they 228 would not be able to provide a world-wide coverage. This means 229 that applications where coverage is important can be built. For 230 instance, most transport sector applications require national or 231 even world-wide coverage to work. 233 But there are other implications, as well. By definition, the 234 network is not tailored for this application and with some 235 exceptions, the traffic passes through the Internet. One 236 implication of this is that there are generally no application- 237 specific network configurations or discovery support. For 238 instance, the public network helps devices to get on the Internet, 239 set up default routers, configure DNS servers, and so on, but does 240 nothing for configuring possible higher-layer functions, such as 241 servers the device might need to contact to perform its 242 application functions. 244 Public networks often provide web proxies and other functionality 245 that can in some cases make a significant improvement for delays 246 and cost of communication over the wireless link. For instance, 247 resolving server DNS names in a proxy instead of the user's device 248 may cut down on the general chattiness of the communications, 249 therefore reducing overall delay in completing the entire 250 transaction. Likewise, a CoAP proxy or pub/sub broker 251 [I-D.koster-core-coap-pubsub] can assist a CoAP device in 252 communication. However, unlike HTTP web proxies, CoAP proxies and 253 brokers are not yet widely deployed in public networks. 255 Similarly, given the lack of available IPv4 addresses, the chances 256 are that many devices are behind a network address translation 257 (NAT) device. This means that they are not easily reachable as 258 servers. Alternatively, the devices may be directly on the global 259 Internet (either on IPv4 or IPv6) and easily reachable as servers. 260 Unfortunately, this may mean that they also receive unwanted 261 traffic, which may have implications for both power consumption 262 and service costs. 264 Point-to-point link model 266 This is a common link model in cellular networks. One implication 267 of this model is that there will be no other nodes on the same 268 link, except maybe for the service provider's router. As a 269 result, multicast discovery can not be reasonably used for any 270 local discovery purposes. While the configuration of the service 271 provider's router for specific users is theoretically possible, in 272 practice this is difficult to achieve, at least for any small user 273 that can not afford a network-wide contract for a private APN 274 (Access Point Name). The public network access service has little 275 per-user tailoring. 277 Radio technology 279 The use of radio technology means that power is needed to operate 280 the radios. Transmission generally requires more power than 281 reception. However, radio protocols have generally been designed 282 so that a device checks periodically whether it has messages. In 283 a situation where messages arrive seldom or not at all, this 284 checking consumes energy. Research has shown that these periodic 285 checks (such as LTE paging message reception) are often a far 286 bigger contributor to energy consumption than message 287 transmission. 289 Note that for situations where there are several applications on 290 the same device wishing to communicate with the Internet in some 291 manner, bundling those applications together so that they can 292 communicate at the same time can be very useful. Some guidance 293 for these techniques in the smartphone context can be found in 294 [Android-Bundle]. 296 Naturally, each device has a freedom to decide when it sends 297 messages. In addition, we assume that there is some way for the 298 devices to control when or how often it wants to receive messages. 299 Specific methods for doing this depend on the specific network being 300 used and also tend to change as improvements in the design of these 301 networks are incorporated. The reception control methods generally 302 come in two variants, fine grained mechanisms that deal with how 303 often the device needs to wake-up for paging messages, and more crude 304 mechanisms where the device simply disconnects from the network for a 305 period of time. There are associated costs and benefits to each 306 method, but those are not relevant for this memo, as long as some 307 control method exists. Furthermore, devices could use Delay-Tolerant 308 Networking (DTN) [RFC4838] mechanisms to relax the requirements for 309 timeliness of connectivity and message delivery. 311 4. Scenarios 313 Not all applications or situations are equal. They may require 314 different solutions or communication models. This memo focuses on 315 two common scenarios at cellular networks: 317 Real-Time Reachable Devices 319 This scenario involves all communication that requires real-time 320 or near real-time communications with a device. That is, a 321 network entity must be able to reach the device with a small time 322 lag at any time, and no pre-agreed wake-up schedule can be 323 arranged. By "real-time" we mean any reasonable end-to-end 324 communications latency, be it measured in milliseconds or seconds. 325 However, unpredictable sleep states are not expected. 327 Examples of devices in this category include sensors that must be 328 measurable from a remote source at any instant in time, such as 329 process automation sensors and actuators that require immediate 330 action, such as light bulbs or door locks. 332 Sleepy Devices 334 This scenario involves freedom to choose when device communicates. 335 The device is often expected to be able to be in a sleep state for 336 much of its time. The device itself can choose when it 337 communicates, or it lets the network assist in this task. 339 Examples of devices in this category include sensors that track 340 slowly changing values, such as temperature sensors and actuators 341 that control a relatively slow process, such as heating systems. 343 Note that there may be hard real-time requirements, but they are 344 expressed in terms of how fast the device can communicate, not in 345 terms of how fast it can respond to a network stimuli. For 346 instance, a fire detector can be classified as a sleepy device as 347 long as it can internally quickly wake up on detecting fire and 348 initiate the necessary communications without delay. 350 5. Discovery and Registration 352 In both scenarios the device will be attached to a public network. 353 Without special arrangements, the device will also get a dynamically 354 assigned IP address or an IPv6 prefix. At least one but typically 355 several router hops separate the device from its communicating peers 356 such as application servers. As a result, the address or even the 357 existence of the device is typically not immediately obvious to the 358 other nodes participating in the application. As discussed earlier, 359 multicast discovery has limited value in public networks; network 360 nodes cannot practically discover individual devices in a large 361 public network. And the devices can not discover who they need to 362 talk, as the public network offers just basic Internet connectivity. 364 Our recommendation is to initiate a discovery and registration 365 process. This allows each device to inform its peers that it has 366 connected to the network and that it is reachable at a given IP 367 address. Registration also facilitates low-power operation since a 368 device can delegate part of the discovery signaling and reachability 369 requirements to another node. 371 The registration part is easy e.g., with a resource directory. The 372 device should perform the necessary registration with these devices, 373 for instance, as specified in [I-D.ietf-core-resource-directory]. In 374 order to do this registration, the device needs to know its CoRE Link 375 Format description, as specified in [RFC6690]. In essence, the 376 registration process involves performing a GET on .well-known/ 377 core/?rt=core-rd at the address of the resource directory, and then 378 doing a POST on the path of the discovered resource. 380 Other mechanisms enabling device discovery and delegation of 381 functionality to a non-sleepy node include 382 [I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub]. 384 However, current CoAP specifications provide only limited support for 385 discovering the resource directory or other registration services. 386 Local multicast discovery only works in LAN-type networks, but not in 387 these public cellular networks. Our recommended alternate methods 388 for discovery are the following: 390 Manual Configuration 392 The DNS name of the resource directory is manually configured. 393 This approach is suitable in situations where the owner of the 394 devices has the resources and capabilities to do the 395 configuration. For instance, a utility company can typically 396 program its metering devices to point to the company servers. 398 Manufacturer Server 400 The DNS name of the directory or proxy is hardwired to the 401 software by the manufacturer, and the directory or proxy is 402 actually run by the manufacturer. This approach is suitable in 403 many consumer usage scenarios, where it would be unreasonable to 404 assume that the consumer runs any specific network services. The 405 manufacturer's web interface and the directory/proxy servers can 406 co-operate to provide the desired functionality to the end user. 407 For instance, the end user can register a device identity in the 408 manufacturer's web interface and ask specific actions to be taken 409 when the device does something. 411 Delegating Manufacturer Server 413 The DNS name of the directory or proxy is hardwired to the 414 software by the manufacturer, but this directory or proxy merely 415 redirects the request to a directory or proxy run by the whoever 416 bought the device. This approach is suitable in many enterprise 417 environments, as it allows the enterprise to be in charge of 418 actual data collection and device registries; only the initial 419 bootstrap goes through the manufacturer. In many cases there are 420 even legal requirements (such as EU privacy laws) that prevent 421 providing unnecessary information to third parties. 423 Common Global Resolution Infrastructure 425 The delegating manufacturer server model could be generalized into 426 a reverse-DNS -like discovery infrastructure that could answer the 427 question "this is device with identity ID, where is my home 428 registration server?". However, at present no such resolution 429 system exists. (Note: The EPCGlobal system for RFID resolution is 430 reminiscent of this approach.) 432 Besides manual configuration, these alternate mechanisms are mostly 433 suitable for large manufacturers and deployments. Good automated 434 mechanism for discovery of devices that are manufactured and deployed 435 in small quantities are still needed. 437 6. Data Formats 439 A variety of data formats exist for passing around data. These data 440 formats include XML, JavaScript Object Notation (JSON) [RFC7159], 441 Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text 442 formats. Message lengths can have a significant effect on the amount 443 of energy required for the communications, and such it is highly 444 desirable to keep message lengths minimal. At the same time, extreme 445 optimization can affect flexibility and ease of programming. The 446 authors recommend [I-D.jennings-core-senml] as a compact, yet easily 447 processed and extendable textual format. 449 7. Real-Time Reachable Devices 451 These devices are often best modeled as CoAP servers. The device 452 will have limited control on when it receives messages, and it will 453 have to listen actively for messages, up to the limits of the 454 underlying link layer. If the device acts also in client role in 455 some phase of its operation, it can control how many transmissions it 456 makes on its own behalf. 458 The packet reception checks should be tailored according to the 459 requirements of the application. If sub-second response time is not 460 needed, a more infrequent checking process may save some power. 462 For sensor-type devices, the CoAP Observe extension [RFC7641] may be 463 supported. This allows the sensor to track changes to the sensed 464 value, and make an immediate observation response upon a change. 465 This may reduce the amount of polling needed to be done by the 466 client. Unfortunately, it does not reduce the time that the device 467 needs to be listening for requests. Subscription requests from other 468 clients than the currently registered one may come at any time, the 469 current client may change its request, and the device still needs to 470 respond to normal queries as a server. As a result, the sensor can 471 not rely having to communicate only on its own choice of observation 472 interval. 474 In order to act as a server, the device needs to be placed in a 475 public IPv4 address, be reachable over IPv6, or hosted in a private 476 network. If the the device is hosted on a private network, then all 477 other nodes need to access this device also need to reside in the 478 same private network. There are multiple ways to provide private 479 networks over public cellular networks. One approach is to dedicate 480 a special APN for the private network. Corporate access via cellular 481 networks has often been arranged in this manner, for instance. 482 Another approach is to use Virtual Private Networking (VPN) 483 technology, for instance IPsec-based VPNs. 485 Power consumption from unwanted traffic is problematic in these 486 devices, unless placed in a private network or protected by a 487 operator-provided firewall service. Devices on an IPv6 network will 488 have some protection through the nature of the 2^64 address 489 allocation for a single terminal in a 3GPP cellular network; the 490 attackers will be unable to guess the full IP address of the device. 491 However, this protects only the device from processing a packet, but 492 since the network will still deliver the packet to any of the 493 addresses within the assigned 64-bit prefix, packet reception costs 494 are still incurred. 496 Note that the the VPN approach can not prevent unwanted traffic 497 received at the tunnel endpoint address, and may require keep-alive 498 traffic. Special APNs can solve this issue, but require explicit 499 arrangement with the service provider. 501 8. Sleepy Devices 503 These devices are best modeled as devices that can delegate queries 504 to some other node. For instance, as mirror proxy 505 [I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe 506 [I-D.koster-core-coap-pubsub] clients. When the device initializes 507 itself, it makes a registration of itself in a proxy as described 508 above in Section 5 and then continues to send periodic updates of 509 sensor values. 511 As a result, the device acts only as a client, not a server, and can 512 shut down all communication channels while it is during its sleeping 513 period. The length of the sleeping period depends on power and 514 application requirements. Some environmental sensors might use a day 515 or a week as the period, while other devices may use a smaller values 516 ranging from minutes to hours. 518 Other approaches for delegation include CoAP-options described in 519 [I-D.castellani-core-alive] 520 [I-D.fossati-core-publish-monitor-options]. In this memo we use 521 mirror proxies as an example, because of their ability to work with 522 both HTTP and CoAP implementations; but the concepts are similar and 523 the IETF work is still in progress so the final protocol details are 524 yet to be decided. 526 The ability to shut down communications and act as only a client has 527 four impacts: 529 o Radio transmission and reception can be turned off during the 530 sleeping period, reducing power consumption significantly. 532 o However, some power and time is consumed by having to re-attach to 533 the network after the end of a sleep period. 535 o The window of opportunity for unwanted traffic to arrive is much 536 smaller, as the device is listening for traffic only part of the 537 time. Note that networks may cache packets for some time though. 538 On the other hand, stateful firewalls can effectively remove much 539 of unwanted traffic for client type devices. 541 o The device may exist behind a NAT or a firewall without being 542 impacted. Note that "Simple Security" basic IPv6 firewall 543 capability [RFC6092] blocks inbound UDP traffic by default, so 544 just moving to IPv6 is not direct solution to this problem. 546 For sleepy devices that represent actuators, it is also possible to 547 use the mirror proxy model. The device can make periodic polls to 548 the proxy to determine if a variable has changed. 550 8.1. Implementation Considerations 552 There are several challenges in implementing sleepy devices. They 553 need hardware that can be put to an appropriate sleep mode but yet 554 awakened when it is time to do something again. This is not always 555 easy in all hardware platforms. It is important to be able to shut 556 down as much of the hardware as possible, preferably down to 557 everything else except a clock circuit. The platform also needs to 558 support re-awakening at suitable time scales, as otherwise the device 559 needs to be powered up too frequently. 561 Most commercial cellular modem platforms do not allow applications to 562 suspend the state of the communications stack. Hence, after a power- 563 off period they need to re-establish communications, which takes some 564 amount of time and extra energy. 566 Implementations should have a coordinated understanding of the state 567 and sleeping schedule. For instance, it makes no sense to keep a CPU 568 powered up, waiting for a message when the lower layer has been told 569 that the next possible paging opportunity is some time away. 571 The cellular networks have a number of adjustable configuration 572 parameters, such as the maximum used paging interval. Proper setting 573 of these values has an impact on the power consumption of the device, 574 but with the current business practices, such settings are rarely 575 negotiated when the user's subscription is provisioned. 577 9. Security Considerations 579 There are no particular security aspects with what has been discussed 580 in this memo, except for the ability to delegate queries for a 581 resource to another node. Depending on how this is done, there are 582 obvious security issues which have largely NOT yet been addressed in 583 the relevant Internet Drafts [I-D.vial-core-mirror-proxy] 584 [I-D.castellani-core-alive] 585 [I-D.fossati-core-publish-monitor-options]. However, we point out 586 that in general, security issues in delegation can be solved either 587 through reliance on your local network support nodes (which may be 588 quite reasonable in many environments) or explicit end-to-end 589 security. Explicit end-to-end security through nodes that are awake 590 at different times means in practice end-to-end data object security. 591 We have implemented one such mechanism for sleepy nodes as described 592 in [I-D.aks-lwig-crypto-sensors]. 594 The security considerations relating to CoAP [RFC7252] and the 595 relevant link layers should apply. Note that cellular networks 596 universally employ per-device authentication, integrity protection, 597 and for most of the world, encryption of all their communications. 598 Additional protection of transport sessions is possible through 599 mechanisms described in [RFC7252] or data objects. 601 10. IANA Considerations 603 There are no IANA impacts in this memo. 605 11. References 607 11.1. Normative References 609 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 610 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 611 2014, . 613 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 614 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 615 . 617 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 618 Application Protocol (CoAP)", RFC 7252, 619 DOI 10.17487/RFC7252, June 2014, 620 . 622 [RFC7641] Hartke, K., "Observing Resources in the Constrained 623 Application Protocol (CoAP)", RFC 7641, 624 DOI 10.17487/RFC7641, September 2015, 625 . 627 [I-D.ietf-core-resource-directory] 628 Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE 629 Resource Directory", draft-ietf-core-resource-directory-05 630 (work in progress), October 2015. 632 [W3C.REC-exi-20110310] 633 Kamiya, T. and J. Schneider, "Efficient XML Interchange 634 (EXI) Format 1.0", World Wide Web Consortium 635 Recommendation REC- 636 exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310, 637 March 2011. 639 [I-D.jennings-core-senml] 640 Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, 641 "Media Types for Sensor Markup Language (SENML)", draft- 642 jennings-core-senml-02 (work in progress), October 2015. 644 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 645 Constrained-Node Networks", RFC 7228, 646 DOI 10.17487/RFC7228, May 2014, 647 . 649 11.2. Informative References 651 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 652 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 653 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 654 April 2007, . 656 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 657 Capabilities in Customer Premises Equipment (CPE) for 658 Providing Residential IPv6 Internet Service", RFC 6092, 659 DOI 10.17487/RFC6092, January 2011, 660 . 662 [I-D.arkko-core-sleepy-sensors] 663 Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. 664 Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- 665 sleepy-sensors-01 (work in progress), July 2011. 667 [I-D.aks-lwig-crypto-sensors] 668 Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical 669 Considerations and Implementation Experiences in Securing 670 Smart Object Networks", draft-aks-lwig-crypto-sensors-00 671 (work in progress), October 2015. 673 [I-D.castellani-core-alive] 674 Castellani, A. and S. Loreto, "CoAP Alive Message", draft- 675 castellani-core-alive-00 (work in progress), March 2012. 677 [I-D.fossati-core-publish-monitor-options] 678 Fossati, T., Giacomin, P., and S. Loreto, "Publish and 679 Monitor Options for CoAP", draft-fossati-core-publish- 680 monitor-options-01 (work in progress), March 2012. 682 [I-D.vial-core-mirror-proxy] 683 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 684 proxy-01 (work in progress), July 2012. 686 [I-D.koster-core-coap-pubsub] 687 Koster, M., Keranen, A., and J. Jimenez, "Publish- 688 Subscribe Broker for the Constrained Application Protocol 689 (CoAP)", draft-koster-core-coap-pubsub-04 (work in 690 progress), November 2015. 692 [Android-Bundle] 693 "Optimizing Downloads for Efficient Network Access", 694 Android developer note 695 http://developer.android.com/training/efficient-downloads/ 696 efficient-network-access.html, February 2013. 698 Appendix A. Acknowledgments 700 The authors would like to thank Zach Shelby, Jan Holler, Salvatore 701 Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim 702 Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, 703 Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes 704 Tschofenig, and Anna Larmo for interesting discussions in this 705 problem space. 707 Authors' Addresses 709 Jari Arkko 710 Ericsson 711 Jorvas 02420 712 Finland 714 Email: jari.arkko@piuha.net 715 Anders Eriksson 716 Ericsson 717 Stockholm 164 83 718 Sweden 720 Email: anders.e.eriksson@ericsson.com 722 Ari Keranen 723 Ericsson 724 Jorvas 02420 725 Finland 727 Email: ari.keranen@ericsson.com