RFC 9178

Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks

📅 published May 2022, from ietf

RFC 9178: Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks 💖

  • Who wrote it: J. Arkko (Ericsson), A. Eriksson (Independent), and A. Keränen (Ericsson) 🫶
  • Stream: Internet Engineering Task Force (IETF) 🌈
  • Category: Informational, so it's published for information and isn't a standards-track spec 📚
  • Date: May 2022 📅
  • ISSN: 2070-1721
  • Obsoletes/Updates: its title block doesn't list any RFC it obsoletes or updates 🙅‍♀️

Abstract 🦋

okay so this doc is all about using the Constrained Application Protocol (CoAP) for sensors and other devices that talk over cellular networks 📡. Building devices like this is totally well known at this point, but this one zooms in on the tricks you need to keep power use as low as possible 🔋✨.

Status of This Memo 📜

ngl the status part is kind of a formal vibe, but here's the tea 🍵. This is not a standards-track spec. It's just published for info 💅.

It's an IETF product and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🎀. Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full picture 🤓.

For the latest status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9178 🔗.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info as they stand on the publication date. Please actually read them, because they spell out your rights and restrictions 🙈. Any Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 🧚.

Table of Contents 🗂️

   1.  Introduction
   2.  Goals for Low-Power Operation
   3.  Link-Layer Assumptions
   4.  Scenarios
   5.  Discovery and Registration
   6.  Data Formats
   7.  Real-Time Reachable Devices
   8.  Sleepy Devices
     8.1.  Implementation Considerations
   9.  Security Considerations
   10. IANA Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction 🌸

okay so this memo is about using CoAP [RFC7252] for sensors and other devices that use cellular networks as their communication medium 📶. Building communicating devices on these networks is super well known, but this memo is laser-focused on the techniques you need to minimize power consumption 🔋💖. CoAP has a bunch of perks, like being simple to implement. Like, a thousand lines of code for the whole application above the IP layer is plenty for a CoAP-based sensor 🤏. That said, even though lots of these perks are obvious and easy to get, optimizing power consumption is still hard and needs careful design [Tiny-CoAP] 😭.

This memo mainly targets 3GPP cellular networks in their 2G, 3G, LTE, and 5G variants, plus their future enhancements. That includes possible power-efficiency improvements at the radio and link layers ⚡. The exact standards or details of the link layer or radios don't matter for our purposes, though 🤷‍♀️. To be more precise, the stuff in this memo works for any large-scale, public network that uses a point-to-point communications model and radio technology for its devices 🌐.

Our focus is on devices that need to be optimized for power usage and that use CoAP 🎯. As a general technology, CoAP is kind of like HTTP 🧁. It can be used in a bunch of ways, and network entities can play different roles. That freedom means the tech can be used in efficient ways or less efficient ways, so some guidance is needed to figure out which kinds of CoAP communication are recommended when low power usage is a critical goal 👑.

The recommendations in this memo are meant to complement device hardware optimization, microelectronics improvements, and further evolution of the link and radio layers 🫶. Gains in power efficiency can definitely come from several fronts. The approach here is to do what can be done at the IP, transport, and application layers to get the best possible power efficiency 💅. App implementors generally have to work with current-generation microelectronics, the radio networks and standards that exist right now, and so on 🔧. This focus should by no means be read as saying further evolution in those other areas is unnecessary. That evolution is useful, ongoing, and generally complementary to the techniques in this memo ✨. However, the list of techniques described here as useful for a particular application may change as those underlying technologies evolve 🦋.

The rest of this memo is structured like this. Section 2 covers the need and goals for low-power devices 🔋. Section 3 outlines what we expect from the low-layer communications model 📐. Section 4 describes the two scenarios we address 🎭. Sections 5, 6, 7, and 8 give guidelines for using CoAP in these scenarios 📝.

This document was originally finalized in 2016, but it got published six years later because it was waiting for key references to reach RFC status 😅. So some of the newest advancements in cellular networks, CoAP, and other tech aren't discussed here, and some references point to docs that were state of the art in 2016 🕰️. Just keep that in mind, bestie 🫶.

2. Goals for Low-Power Operation 💅

okay so there are lots of situations where optimizing power usage isn't necessary 🙌. You might not need it on devices that run off a power feed over wired media, like in Power-over-Ethernet (PoE) setups 🔌. Those devices might still need a basic level of power optimization to keep overall energy costs and aggregate power feed sizes reasonable, but the more extreme techniques needed for battery-powered devices aren't required 🙅‍♀️. It's a similar story for devices that can easily plug into mains power 🏠. Other devices get an occasional charge from energy-harvesting techniques. For example, some environmental sensors run on solar cells ☀️. Those devices usually still have to regulate their power usage super strictly, like so they can use solar cells that are as small and cheap as possible 🤏💸.

Battery-operated devices are where power usage matters even more 🔋😤. For example, one of the authors has over a hundred different sensor devices in their home network 🏡. Most of them are wired and run on PoE, but in most environments that just wouldn't be practical, because the wires don't already exist 🧵. The future is in wireless solutions that can cover buildings and other environments without needing pre-existing wired infrastructure 🌈. Plus, in lots of cases, providing a mains power source is impractical 🙃. There are often no power sockets easily available where the devices need to be. And even if there were, setting up wires and power adapters would be way more complicated than just installing a standalone device with no wires at all 💀.

Yet with a huge number of devices, battery lifetimes become critical 😭. Cost and practical limits mean devices can be mostly bought and just left alone. For example, with a hundred devices, even a ten-year battery lifetime means one device in the network needs a battery change every month 📆. That's probably impractical in lots of environments 😬. Some devices are also physically hard to reach for a battery change 🧗‍♀️. And a big group of devices, like utility meters or environmental sensors, can't be economically serviced too often, even if in theory the batteries could be swapped 🔧.

All of this leads to a requirement to minimize power usage and/or maximize battery lifetimes 💜. Using the power usage strategies described in [RFC7228], mains-powered sensor-type devices can use the Always-on strategy 🔌. Battery-operated or energy-harvesting devices instead need to adjust their behavior based on the communication interval ⏱️. For intervals on the order of seconds, the Low-power strategy is appropriate ⚡. For intervals ranging from minutes to hours, either the Low-power or Normally-off strategy is suitable 🌙. And for intervals lasting days or longer, Normally-off is usually the best choice 😴. Unfortunately, a lot of our current tech was built with different goals in mind 😩. Think networked devices that are "always on," gadgets that humans have to recharge every couple of days, and protocols optimized to maximize throughput instead of conserving resources 🙄.

Long battery lifetimes are required for many applications, though 🔋✨. In some cases, these lifetimes should be on the order of years, or even a decade or longer 🗓️. Some communication devices already reach multi-year lifetimes, and steady improvements in low-power electronics and advances in radio tech keep pushing those lifetimes longer 📈. Still, it's perhaps fair to say that battery lifetimes are generally too short right now 🥺.

Power usage can't be evaluated based only on lower-layer communications 🙅‍♀️. The whole system, including upper-layer protocols and applications, is responsible for power consumption as a whole 🧩. The lower communication layers have already adopted lots of techniques that reduce power usage, like scheduling device wake-up times ⏰. Further reductions will likely need some cooperation from the upper layers, so that unnecessary communications, denial-of-service attacks on power consumption, and other power drains get eliminated 🛡️. Pretty iconic teamwork, honestly 🫶.

Of course, application requirements ultimately decide what kinds of communication are necessary 🎀. For example, some applications need to send more data than others 📦. The purpose of the guidelines in this memo is not to prefer one application over another 🙅‍♀️. The goal is to give guidance on how to minimize the amount of communications overhead that the application doesn't directly require 🧹. That kind of optimization is useful pretty much everywhere, but it's, relatively speaking, most noticeable in applications that only transfer a small amount of data or only operate infrequently 🌸. Main character energy for the low-data crowd 👑💖.

okay so bestie, first we need to talk about what the network under all this is gonna look like 🌸 We assume the underlying network can be any large-scale, public network that uses a point-to-point communications model and radio technology. 2G, 3G, LTE, and 5G networks are examples, but they're not the only networks with these vibes 📡

Next we look at some of these characteristics and what they mean for us. Quick heads-up: in most cases these aren't quirks of one specific network. They come with the whole idea of a public network 💅

3.1. Big Public Networks, Big Feelings 🌈

  • Public Networks

Using a public network service means apps can get deployed without anyone having to build a network to go with them 🦋 For economic reasons, only the biggest users (think utility companies) could afford to build their own, and even they couldn't cover the whole planet. So applications that need coverage can actually be built! Most transport-sector apps need national or even worldwide coverage to work at all, so this is a big deal 🙌

But there are other implications too 👀 The network isn't tailored for this application, and, with some exceptions, the traffic goes through the Internet. What this means is that there are generally no application-specific network configurations or discovery support. The public network helps devices get on the Internet, set up default routers, configure DNS servers, and so on. But it does nothing to configure higher-layer functions, like the servers a device might need to contact to do its application stuff. Not it, bestie 💀

Public networks often provide web proxies and other functionality that can, in some cases, make real improvements to delays and costs over the wireless link ✨ For example, resolving server DNS names in a proxy instead of on the user's device can cut down on the general chattiness, which reduces overall delay for the whole transaction. Likewise, a CoAP proxy or Publish-Subscribe (pub/sub) Broker [CoAP-PubSub] can help a CoAP device communicate. Plot twist, though: unlike HTTP web proxies, CoAP proxies and brokers aren't yet widely deployed in public networks 😭

Also, because of the lack of available IPv4 addresses, chances are that many devices are behind a Network Address Translation (NAT) device. That means they aren't easily reachable as servers 🙈 The other option is that devices sit directly on the global Internet (on either IPv4 or IPv6) and are easily reachable as servers. Unfortunately, this may mean they also receive unwanted traffic, which can have implications for both power consumption and service costs. Rude 💅

  • Point-to-Point Link Model

This is a common link model in cellular networks 📶 One implication is that there won't be any other nodes on the same link, except maybe the service provider's router. So multicast discovery can't really be used for any local discovery purposes. Could you configure the service provider's router for specific users? In theory, yes, but in practice it's hard to pull off, especially for any small user who can't afford a network-wide contract for a private APN (Access Point Name). Bottom line: the public network access service has very little per-user tailoring 🫠

  • Radio Technology

Using radio technology means power is needed to run the radios ⚡ Transmission generally takes more power than reception. Here's the tea, though: radio protocols have generally been designed so that a device checks periodically to see whether it has messages. When messages arrive rarely or not at all, all that checking still eats energy 😤 Research has shown that these periodic checks (like LTE paging message reception) are often a way bigger contributor to energy consumption than message transmission. Wild, right? 🤯

Also, when several applications on the same device want to talk to the Internet, bundling them so they can communicate at the same time can be super useful 🧚 Some guidance for these techniques in the smartphone context can be found in [Android-Bundle].

Naturally, each device gets to decide when it sends messages 💖 We also assume there's some way for devices to control when, or how often, they want to receive messages. The specific methods depend on the network being used, and they tend to change as the networks get improved. The reception control methods generally come in two variants: (1) fine-grained mechanisms that deal with how often the device has to wake up for paging messages, and (2) cruder mechanisms where the device simply disconnects from the network for a period of time. Each comes with costs and benefits, but those aren't relevant for this memo, as long as some control method exists 🦋 And if devices want to chill even more, they could use Delay-Tolerant Networking (DTN) mechanisms [RFC4838] to relax the requirements for timeliness of connectivity and message delivery. Main character energy 👑

4. Scenarios 🎀

Not all applications or situations are equal, bestie 💅 They may need different solutions or communication models. This memo focuses on two common scenarios in cellular networks:

4.1. Real-Time Reachable Devices ⚡

  • Real-Time Reachable Devices

This scenario covers all communication that needs real-time or near-real-time communications with a device. That means a network entity must be able to reach the device with a small time lag at any time, and no previously agreed-upon wake-up schedule can be arranged 📅 By "real-time," we mean any reasonable end-to-end communications latency, whether it's measured in milliseconds or seconds. However, unpredictable sleep states are not expected. No ghosting here 😭

Examples of devices in this category include sensors that have to be measurable from a remote source at any instant, like process automation sensors and actuators that need to take immediate action, such as light bulbs or door locks 💡

4.2. Sleepy Devices 😴

  • Sleepy Devices

This scenario is all about the freedom to choose when a device communicates 🌙 The device is often expected to spend much of its time in a sleep state. The device itself can choose when it communicates, or it can let the network help with that task.

Examples of devices in this category include sensors that track slowly changing values, like temperature sensors, and actuators that control a relatively slow process, like heating systems 🔥

Note that there may be hard real-time requirements, but they're expressed in terms of how fast the device can communicate, not in terms of how fast it can respond to network stimuli. For instance, a fire detector can be classified as a sleepy device as long as it can internally wake up quickly on detecting fire and start the necessary communications without delay 🚨 That's giving reliable and efficient vibes 🫶

5. Discovery and Registration ✨

okay so in both scenarios the device is gonna be attached to a public network 🌐. Without special arrangements it also gets a dynamically assigned IP address or an IPv6 prefix 🎀. At least one but typically several router hops separate the device from its communicating peers, like application servers 🛣️. So literally the address or even the existence of the device is usually not obvious to the other nodes in the application 🙈. As we talked about earlier, multicast discovery has limited value in public networks, because network nodes can't practically discover individual devices in a large public network 💀. And the devices can't figure out who they need to talk to either, since the public network only offers basic Internet connectivity 😭.

Our recommendation is to kick off a discovery and registration process 💖. This lets each device tell its peers that it has connected to the network and that it's reachable at a given IP address 📣. Registration also makes low-power operation easier, since a device can hand off part of the discovery signaling and reachability requirements to another node 🔋✨.

Registration is the easy part, e.g., with a resource directory 💅. The device should perform the necessary registration with such a resource directory, for instance as specified in [RFC9176]. To pull this off, the device needs to know its Constrained RESTful Environments (CoRE) Link Format description, as specified in [RFC6690] 📚. Basically, the registration process is a GET on .well-known/core/?rt=core-rd at the address of the resource directory, and then a POST on the path of the discovered resource 🧚.

Other mechanisms for device discovery and for handing functionality off to a non-sleepy node include the ones discussed in [CoRE-Mirror] and [CoAP-PubSub] 🦋.

However, current CoAP specifications give only limited support for discovering the resource directory or other registration services 🥲. Local multicast discovery only works in LAN-type networks, so it doesn't work in the public cellular networks this document is about. We recommend the following alternate methods for discovery:

  • Manual Configuration: The DNS name of the resource directory is configured by hand 🛠️. This works when the device owner has the resources and capabilities to do the configuration. For instance, a utility company can typically program its metering devices to point to the company servers 🏭.
  • Manufacturer Server: The DNS name of the directory or proxy is hardwired into the software by the manufacturer, and the directory or proxy is actually run by the manufacturer 🏢. This is great for many consumer scenarios, where it would be unreasonable to assume the consumer runs any specific network services 🏠. The manufacturer's web interface and the directory/proxy servers can team up to give the end user the functionality they want 🤝. For instance, the end user can register a device identity in the manufacturer's web interface and ask that specific actions be taken when the device does something 🔔.
  • Delegating Manufacturer Server: The DNS name of the directory or proxy is hardwired into the software by the manufacturer, but this directory or proxy just redirects the request to a directory or proxy run by whoever bought the device 🔀. This is a big deal in many enterprise environments, because it lets the enterprise be in charge of actual data collection and device registries, with only the initial bootstrap going through the manufacturer 🏛️. In many cases there are even legal requirements (such as EU privacy laws) that prevent giving unnecessary information to third parties 🔐.
  • Common Global Resolution Infrastructure: The delegating manufacturer server model could be generalized into a reverse-DNS-like discovery infrastructure that could, for example, answer the question "This is a device with identity ID 2456; where is my home registration server?" 🌍. However, at present, no such resolution system exists 🥺. (Note: The EPCGlobal system for Radio Frequency Identification (RFID) resolution is reminiscent of this approach.) 🏷️

Besides manual configuration, these alternate mechanisms are mostly suitable for large manufacturers and deployments 📦. Good automated mechanisms for discovering devices that are manufactured and deployed in small quantities are still needed 🙏.

6. Data Formats 💌

A variety of data formats exist for passing data around 🗂️. These include XML, JavaScript Object Notation (JSON) [RFC8259], Efficient XML Interchange (EXI) [W3C.REC-exi-20140211], Concise Binary Object Representation (CBOR) [RFC8949], and various text formats 📝. Message lengths can have a big effect on the amount of energy needed for communications, so it's highly desirable to keep message lengths minimal 🔋. At the same time, extreme optimization can hurt flexibility and ease of programming 😵‍💫. The authors recommend that readers refer to [RFC8428] for a format that is compact but easily processed and extendable 🦋✨.

7. Real-Time Reachable Devices ⏰

These devices are often best modeled as CoAP servers 🖥️. The device has limited control over when it receives messages, so it has to listen actively for messages, up to the limits of the underlying link layer 👂. If in some phase of its operation the device also acts as a client, it can control how many transmissions it makes on its own behalf 🎛️.

The packet reception checks should be tailored to the requirements of the application 🎯. If sub-second response time isn't needed, a less frequent checking process may save some power 🔋💤.

For sensor-type devices, the CoAP Observe extension (Observe option) [RFC7641] may be supported 👀. This lets the sensor track changes to the sensed value and make an immediate observation response upon a change 📈. This may reduce the amount of polling the client needs to do 🙌. Unfortunately, it does not reduce the time the device needs to be listening for requests 😩. Subscription requests from clients other than the currently registered client may come in at any time, the current client may change its request, and the device still needs to respond to normal queries as a server 🫠. As a result, the sensor can't rely on only communicating on its own choice of observation interval 🙃.

To act as a server, the device needs to be placed on a public IPv4 address, be reachable over IPv6, or be hosted in a private network 🏰. If the device is hosted on a private network, then all other nodes that need to access this device also need to reside in the same private network 🔒. There are multiple ways to provide private networks over public cellular networks 📶. One approach is to dedicate a special APN for the private network, and corporate access via cellular networks has often been arranged this way 💼. Another approach is to use Virtual Private Network (VPN) technology, for instance IPsec-based VPNs 🛡️.

Power consumption from unwanted traffic is a real problem for these devices, unless they are placed in a private network or protected by an operator-provided firewall service 🚫🔥. Devices on an IPv6 network get some protection because of the nature of the 2^64 address allocation for a single terminal in a 3GPP cellular network 🧱: attackers won't be able to guess the full IP address of the device 🙈. However, this only protects the device from processing a packet. Since the network will still deliver the packet to any of the addresses within the assigned 64-bit prefix, packet reception costs are still incurred 😤.

Note that the VPN approach cannot prevent unwanted traffic received at the tunnel endpoint address, and it may require keep-alive traffic 🫧. Special APNs can solve this issue, but they require an explicit arrangement with the service provider 🤝.

8. Sleepy Devices 😴

These devices are best modeled as devices that can delegate queries to some other node 🧚‍♀️, for instance as mirror servers [CoRE-Mirror] or CoAP pub/sub Clients [CoAP-PubSub] 💜. When the device initializes itself, it registers itself with a server or broker as described above in Section 5, and then it keeps sending periodic updates of sensor values 📬.

As a result, the device acts only as a client and not as a server, and it can shut down all communication channels during its sleeping period 💤. The length of the sleeping period depends on power and application requirements ⏳. Some environmental sensors might use a day or a week as the period, while other devices may use smaller values ranging from minutes to hours 🌦️.

The ability to shut down communications and act only as a client has four impacts 🎀:

  • Radio transmission and reception can be turned off during the sleeping period, which reduces power consumption significantly 📉🔋.
  • However, some power and time are consumed by having to reattach to the network after the end of a sleep period 😮‍💨.
  • The window of opportunity for unwanted traffic to arrive is much smaller, since the device is only listening for traffic part of the time 🪟. Note, however, that networks may cache packets for some time 🗃️. On the other hand, stateful firewalls can effectively remove much of the unwanted traffic for client-type devices 🧹.
  • The device may exist behind a NAT or a firewall without being impacted 🏡. Note that the "simple security" basic IPv6 firewall capability [RFC6092] blocks inbound UDP traffic by default, so just moving to IPv6 is not a direct solution to this problem 🙅‍♀️.

For sleepy devices that represent actuators, it's also possible to use the mirror server or pub/sub broker model 🕹️. A device can receive information from the server or broker about variable changes via either polling or notifications 🔔.

8.1. Implementation Considerations 🛠️

There are several challenges related to implementing sleepy devices 🧩. They need hardware that can be placed in an appropriate sleep mode but awakened when it's time to do something again 🌙⏰. This isn't always easy on all hardware platforms 😬. It's important to be able to shut down as much of the hardware as possible, preferably down to everything except a clock circuit ⏱️. The platform also needs to support reawakening at suitable timescales, since otherwise the device would need to be powered up too frequently 🔌.

Most commercial cellular modem platforms don't allow applications to suspend the state of the communications stack 🙅. So after a power-off period, they need to re-establish communications, which takes some amount of time and extra energy ⚡.

Implementations should have a coordinated understanding of the state and sleeping schedule 🗓️. For instance, it makes no sense to keep a CPU powered up, waiting for a message, when the lower layer has been told that the next possible paging opportunity is some time away 🤡.

The cellular networks have a number of adjustable configuration parameters, such as the maximum used paging interval 📡. Proper settings of these values have an impact on the power consumption of the device, but with current business practices, such settings are rarely negotiated when the user's subscription is provisioned 💸💀.

9. Security Considerations 🔐

okay so this section is short but it is SERIOUS 😭 The memo itself has no special security stuff of its own, EXCEPT for one thing: letting another node answer queries for a resource on your behalf (delegation). Depending on how you do that, there are some obvious security issues that are still not sorted out in the related Internet-Drafts [CoRE-Mirror] [CoAP-Alive] [CoAP-Publ-Monitor]. Not the vibe, bestie 💀

BUT the good news ✨ is that delegation security can usually be handled in one of two ways. You can lean on your local network support nodes (which is honestly pretty reasonable in lots of environments), or you can use explicit end-to-end security. When the nodes that handle your data are awake at different times, explicit end-to-end security basically turns into end-to-end data object security. The authors built one mechanism for sleepy nodes like this, described in [RFC8387] 🦋

The security considerations for CoAP [RFC7252] and the relevant link layers still apply, obviously 💅 Also, cellular networks universally use per-device authentication and integrity protection, and most of the world also gets encryption on all their traffic 📶🔒 Extra protection for transport sessions is possible through the mechanisms in [RFC7252] or through data objects.

10. IANA Considerations 🌸

No IANA actions here, so nothing to register. Simple and clean 🫶

11. References 📚

11.1. Normative References

[RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", STD 90, RFC 8259,
           DOI 10.17487/RFC8259, December 2017,
           <https://www.rfc-editor.org/info/rfc8259>.

[RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
           Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
           <https://www.rfc-editor.org/info/rfc6690>.

[RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
           Application Protocol (CoAP)", RFC 7252,
           DOI 10.17487/RFC7252, June 2014,
           <https://www.rfc-editor.org/info/rfc7252>.

[RFC7641]  Hartke, K., "Observing Resources in the Constrained
           Application Protocol (CoAP)", RFC 7641,
           DOI 10.17487/RFC7641, September 2015,
           <https://www.rfc-editor.org/info/rfc7641>.

[RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
           Representation (CBOR)", STD 94, RFC 8949,
           DOI 10.17487/RFC8949, December 2020,
           <https://www.rfc-editor.org/info/rfc8949>.

[RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
           P. van der Stok, "Constrained RESTful Environments (CoRE)
           Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
           2022, <https://www.rfc-editor.org/info/rfc9176>.

[W3C.REC-exi-20140211]
           Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
           "Efficient XML Interchange (EXI) Format 1.0 (Second
           Edition)", World Wide Web Consortium Recommendation REC-
           exi-20140211, February 2014, <https://www.w3.org/TR/exi/>.

[RFC8428]  Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
           Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
           DOI 10.17487/RFC8428, August 2018,
           <https://www.rfc-editor.org/info/rfc8428>.

[RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
           Constrained-Node Networks", RFC 7228,
           DOI 10.17487/RFC7228, May 2014,
           <https://www.rfc-editor.org/info/rfc7228>.

11.2. Informative References

[RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
           R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
           Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
           April 2007, <https://www.rfc-editor.org/info/rfc4838>.

[RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
           Capabilities in Customer Premises Equipment (CPE) for
           Providing Residential IPv6 Internet Service", RFC 6092,
           DOI 10.17487/RFC6092, January 2011,
           <https://www.rfc-editor.org/info/rfc6092>.

[Tiny-CoAP]
           Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
           Novo, "Implementing Tiny COAP Sensors", Work in Progress,
           Internet-Draft, draft-arkko-core-sleepy-sensors-01, 5 July
           2011, <https://datatracker.ietf.org/doc/html/draft-arkko-
           core-sleepy-sensors-01>.

[RFC8387]  Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
           Considerations and Implementation Experiences in Securing
           Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387,
           May 2018, <https://www.rfc-editor.org/info/rfc8387>.

[CoAP-Alive]
           Castellani, A. and S. Loreto, "CoAP Alive Message", Work
           in Progress, Internet-Draft, draft-castellani-core-alive-
           00, 29 March 2012, <https://datatracker.ietf.org/doc/html/
           draft-castellani-core-alive-00>.

[CoAP-Publ-Monitor]
           Fossati, T., Giacomin, P., and S. Loreto, "Publish and
           Monitor Options for CoAP", Work in Progress, Internet-
           Draft, draft-fossati-core-publish-monitor-options-01, 10
           March 2012, <https://datatracker.ietf.org/doc/html/draft-
           fossati-core-publish-monitor-options-01>.

[CoRE-Mirror]
           Vial, M., "CoRE Mirror Server", Work in Progress,
           Internet-Draft, draft-vial-core-mirror-proxy-01, 13 July
           2012, <https://datatracker.ietf.org/doc/html/draft-vial-
           core-mirror-proxy-01>.

[CoAP-PubSub]
           Koster, M., Keranen, A., and J. Jimenez, "Publish-
           Subscribe Broker for the Constrained Application Protocol
           (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
           core-coap-pubsub-10, 4 May 2022,
           <https://datatracker.ietf.org/doc/html/draft-ietf-core-
           coap-pubsub-10>.

[Android-Bundle]
           "Optimize network access", Android developer note, May
           2022, <https://developer.android.com/training/efficient-
           downloads/efficient-network-access.html>.

Acknowledgments 🫶

The authors gave a big shoutout to Zach Shelby, Jan Holler, Salvatore Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Tschofenig, and Anna Larmo for the interesting discussions in this problem space. Iconic group chat behavior 👑✨

Authors' Addresses 💌

Jari Arkko
Ericsson
FI-02420 Jorvas
Finland
Email: jari.arkko@piuha.net


Anders Eriksson
Independent
SE-164 83 Stockholm
Sweden
Email: anders.e.eriksson@posthem.se


Ari Keränen
Ericsson
FI-02420 Jorvas
Finland
Email: ari.keranen@ericsson.com

That's the whole RFC, bestie! 🌈💖 Thanks for staying with me through all four parts 🦋

📦 where this page comes from