Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc9178.¶

Copyright Notice

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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1.Introduction

This memo discusses the use of the Constrained Application Protocol(CoAP)[RFC7252] in buildingsensors and other devices that employ cellular networks as acommunications medium. Building communicating devices that employthese networks is obviously well known, but this memo focusesspecifically on techniques necessary to minimize power consumption.CoAP has many advantages, including being simple to implement; athousand lines of code for the entire application above the IP layer is plenty for aCoAP-based sensor, for instance. However, while many of theseadvantages are obvious and easily obtained, optimizing powerconsumption remains challenging and requires careful design[Tiny-CoAP].¶

This memo primarily targets 3GPP cellular networks in their 2G, 3G,LTE, and 5G variants and their future enhancements, including possiblepower efficiency improvements at the radio and link layers. The exactstandards or details of the link layer or radios are not relevant forour purposes, however. To be more precise, the material in this memois suitable for any large-scale, public network that employs apoint-to-point communications model and radio technology for thedevices in the network.¶

Our focus is on devices that need to be optimized for power usage anddevices that employ CoAP. As a general technology, CoAP is similarto HTTP. It can be used in various ways, and network entities may takeon different roles. This freedom allows the technology to be used inefficient and less efficient ways. Some guidance is needed tounderstand what types of communication over CoAP are recommended whenlow power usage is a critical goal.¶

The recommendations in this memo should be taken as complementaryto device hardware optimization, microelectronics improvements, andfurther evolution of the underlying link and radio layers. Furthergains in power efficiency can certainly be gained on several fronts;the approach that we take in this memo is to do what can be done atthe IP, transport, and application layers to provide the best possiblepower efficiency. Application implementors generally have to use thecurrent-generation microelectronics, currently available radionetworks and standards, and so on. This focus in our memo should by nomeans be taken as an indication that further evolution in these otherareas is unnecessary. Such evolution is useful, ongoing, and generally complementary to the techniques presented in this memo.However, the list of techniques described in this document as useful for aparticular application may change with the evolution of these underlyingtechnologies.¶

The rest of this memo is structured as follows.Section 2 discusses the need and goals for low-powerdevices.Section 3 outlines our expectations for the low-layer communications model.Section 4 describes the twoscenarios that we address. Sections 5,6,7, and8 giveguidelines for the use of CoAP in these scenarios.¶

This document was originally finalized in 2016 but is published six years later due to waiting for key references to reach RFC status. Therefore, some of the latest advancements in cellular network, CoAP, and other technologies are not discussed here, and some of the references point to documents that were state of the art in 2016.¶

2.Goals for Low-Power Operation

There are many situations where power usage optimization isunnecessary. Optimization may not be necessary on devices that can runon a power feed over wired communications media, such as inPower-over-Ethernet (PoE) solutions. These devices may require arudimentary level of power optimization techniques just to keepoverall energy costs and aggregate power feed sizes at a reasonablelevel, but more extreme techniques necessary for battery-powereddevices are not required. The situation is similar with devices thatcan easily be connected to mains power. Other types of devices mayget an occasional charge of power from energy-harvesting techniques.For instance, some environmental sensors can run on solarcells. Typically, these devices still have to regulate their powerusage in a strict manner -- for instance, to be able to use solar cells thatare as small and inexpensive as possible.¶

In battery-operated devices, power usage is even moreimportant. For instance, one of the authors employs over a hundred differentsensor devices in their home network. A majority of these devices arewired and run on PoE, but in most environments this would beimpractical because the necessary wires do not exist. The future is inwireless solutions that can cover buildings and other environmentswithout assuming a pre-existing wired infrastructure. In addition, inmany cases it is impractical to provide a mains power source. Often,there are no power sockets easily available in the locations that thedevices need to be in, and even if there were, setting up the wiresand power adapters would be more complicated than installing astandalone device without any wires.¶

Yet, with a large number of devices, the battery lifetimes becomecritical. Cost and practical limits dictate that devices can belargely just bought and left on their own. For instance, with a hundreddevices, even a ten-year battery lifetime results in a monthly batterychange for one device within the network. This may be impractical inmany environments. In addition, some devices may be physicallydifficult to reach for a battery change. Or, a large group of devices-- such as utility meters or environmental sensors -- cannot beeconomically serviced too often, even if in theory the batteries couldbe changed.¶

Many of these situations lead to a requirement for minimizing powerusage and/or maximizing battery lifetimes. Using the power usagestrategies described in[RFC7228], mains-poweredsensor-type devices can use the Always-on strategy, whereas battery-operated orenergy-harvesting devices need to adjust behavior based on thecommunication interval. For intervals on the order of seconds, theLow-power strategy is appropriate. For intervals ranging from minutesto hours, either the Low-power or Normally-off strategy issuitable. Finally, for intervals lasting days or longer, Normally-offis usually the best choice. Unfortunately, much of our current technology has been built with different objectives in mind -- for instance, networked devices that are "always on", gadgets that require humans to recharge them every couple of days, and protocols that have been optimized to maximize throughput rather than conserveresources.¶

Long battery lifetimes are required for many applications,however. In some cases, these lifetimes should be on the order of yearsor even a decade or longer. Some communication devices already reachmulti-year lifetimes, and continuous improvements in low-powerelectronics and advances in radio technology keep pushing theselifetimes longer. However, it is perhaps fair to say that batterylifetimes are generally too short at present.¶

Power usage cannot be evaluated based solely on lower-layercommunications. The entire system, including upper-layer protocols andapplications, is responsible for the power consumption as a whole. Thelower communication layers have already adopted many techniques thatcan be used to reduce power usage, such as scheduling device wake-uptimes. Further reductions will likely need some cooperation from theupper layers so that unnecessary communications, denial-of-serviceattacks on power consumption, and other power drains areeliminated.¶

Of course, application requirements ultimately determine what kindsof communications are necessary. For instance, some applicationsrequire more data to be sent than others. The purpose of theguidelines in this memo is not to prefer one or the other application,but to provide guidance on how to minimize the amount ofcommunications overhead that is not directly required by theapplication. While such optimization is generally useful, it is,relatively speaking, most noticeable in applications that transfer onlya small amount of data or operate only infrequently.¶

3.Link-Layer Assumptions

We assume that the underlying communications network can be anylarge-scale, public network that employs a point-to-point communicationsmodel and radio technology.  2G, 3G, LTE, and 5G networks are examples of suchnetworks but are not the only possible networks with these characteristics.¶

In the following, we look at some of these characteristics and theirimplications. Note that in most cases these characteristics are notproperties of the specific networks but rather are inherent in the conceptof public networks.¶

• Public Networks¶

  Using a public network service implies that applications can bedeployed without having to build a network to go with them. Foreconomic reasons, only the largest users (such as utility companies)could afford to build their own network, and even they would not beable to provide worldwide coverage. This means that applicationswhere coverage is important can be built. For instance, mosttransport-sector applications require national or even worldwide coverage towork.¶

  But there are other implications as well. By definition, the networkis not tailored for this application, and, with some exceptions, thetraffic passes through the Internet. One implication of this is thatthere are generally no application-specific network configurations ordiscovery support. For instance, the public network helps devices toget on the Internet, set up default routers, configure DNS servers,and so on, but does nothing for configuring possible higher-layerfunctions, such as servers that a device might need to contact to performits application functions.¶

  Public networks often provide web proxies and other functionality thatcan, in some cases, make significant improvements related to delays and costsof communication over the wireless link. For instance, resolvingserver DNS names in a proxy instead of the user's device may cut downon the general chattiness of the communications, therefore reducingoverall delay in completing the entire transaction. Likewise, a CoAPproxy or Publish-Subscribe (pub⁠/sub) Broker[CoAP-PubSub]can assist a CoAP device in communication. However, unlike HTTP webproxies, CoAP proxies and brokers are not yet widely deployed inpublic networks.¶

  Similarly, given the lack of available IPv4 addresses, chances arethat many devices are behind a Network Address Translation (NAT)device. This means that they are not easily reachable as servers.Alternatively, the devices may be directly on the global Internet(on either IPv4 or IPv6) and easily reachable asservers. Unfortunately, this may mean that they also receive unwantedtraffic, which may have implications for both power consumption andservice costs.¶

• Point-to-Point Link Model¶

  This is a common link model in cellular networks. One implication ofthis model is that there will be no other nodes on the same link,except maybe for the service provider's router. As a result, multicastdiscovery cannot be reasonably used for any local discovery purposes.While the configuration of the service provider's router for specificusers is theoretically possible, this is difficult toachieve in practice, at least for any small user that cannot afford anetwork-wide contract for a private APN (Access Point Name). Thepublic network access service has little per-user tailoring.¶

• Radio Technology¶

  The use of radio technology means that power is needed to operate theradios. Transmission generally requires more powerthan reception. However, radio protocols have generally been designedso that a device checks periodically to see whether it has messages. In asituation where messages arrive seldom or not at all, this checkingconsumes energy. Research has shown that these periodic checks (suchas LTE paging message reception) are often a far bigger contributor toenergy consumption than message transmission.¶

  Note that for situations where there are several applications on thesame device wishing to communicate with the Internet in some manner,bundling those applications together so that they can communicate atthe same time can be very useful. Some guidance for these techniquesin the smartphone context can be found in[Android-Bundle].¶

Naturally, each device has the freedom to decide when it sendsmessages. In addition, we assume that there is some way for thedevices to control when or how often they want to receive messages.Specific methods for doing this depend on the specific network beingused and also tend to change as improvements in the design of thesenetworks are incorporated. The reception control methods generallycome in two variants: (1) fine-grained mechanisms that deal with how oftenthe device needs to wake up for paging messages and (2) crudermechanisms where the device simply disconnects from the network for aperiod of time. There are costs and benefits associated with eachmethod, but those are not relevant for this memo, as long as somecontrol method exists. Furthermore, devices could use Delay-TolerantNetworking (DTN) mechanisms[RFC4838] to relax therequirements for timeliness of connectivity and message delivery.¶

4.Scenarios

Not all applications or situations are equal. They may requiredifferent solutions or communication models. This memo focuses on twocommon scenarios in cellular networks:¶

• Real-Time Reachable Devices¶

  This scenario involves all communication that requires real-time ornear-real-time communications with a device. That is, a network entitymust 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", wemean any reasonable end-to-end communications latency, be it measuredin milliseconds or seconds. However, unpredictable sleep states arenot expected.¶

  Examples of devices in this category include sensors that must be measurablefrom a remote source at any instant in time, such as process automation sensorsand actuators that require immediate action, such as light bulbs or door locks.¶

• Sleepy Devices¶

  This scenario involves the freedom to choose when a device communicates. Thedevice is often expected to be able to be in a sleep state for much ofits time. The device itself can choose when it communicates, or it letsthe network assist in this task.¶

  Examples of devices in this category include sensors that track slowlychanging values, such as temperature sensors and actuators thatcontrol a relatively slow process, such as heating systems.¶

  Note that there may be hard real-time requirements, but they areexpressed in terms of how fast the device can communicate -- not interms of how fast it can respond to network stimuli. For instance,a fire detector can be classified as a sleepy device as long as itcan internally quickly wake up on detecting fire and initiate the necessarycommunications without delay.¶

5.Discovery and Registration

In both scenarios, the device will be attached to a public network.Without special arrangements, the device will also get a dynamicallyassigned IP address or an IPv6 prefix. At least one but typicallyseveral router hops separate the device from its communicating peerssuch as application servers. As a result, the address or even theexistence of the device is typically not immediately obvious to theother nodes participating in the application. As discussed earlier,multicast discovery has limited value in public networks; networknodes cannot practically discover individual devices in a large publicnetwork. And the devices cannot discover who they need to talk to, asthe public network offers just basic Internet connectivity.¶

Our recommendation is to initiate a discovery and registrationprocess. This allows each device to inform its peers that it hasconnected to the network and that it is reachable at a given IPaddress. Registration also facilitates low-power operation, since adevice can delegate part of the discovery signaling and reachabilityrequirements to another node.¶

The registration part is easy, e.g., with a resource directory. Thedevice should perform the necessary registration with such a resource directory --for instance, as specified in[RFC9176]. In order to do thisregistration, the device needs to know its Constrained RESTful Environments (CoRE) Link Formatdescription, as specified in[RFC6690]. In essence, theregistration process involves performing a GET on.well-known/core/?rt=core-rd at the address of the resource directoryand then doing a POST on the path of the discovered resource.¶

Other mechanisms enabling device discovery and delegation offunctionality to a non-sleepy node include those discussed in[CoRE-Mirror] and[CoAP-PubSub].¶

However, current CoAP specifications provide only limited supportfor discovering the resource directory or other registrationservices. Local multicast discovery only works in LAN-type networks; it doesnot work in the public cellular networks discussed in this document. We recommend the following alternate methods for discovery:¶

• Manual Configuration¶

  The DNS name of the resource directory is manually configured. Thisapproach is suitable in situations where the owner of the devices hasthe resources and capabilities to do the configuration. For instance,a utility company can typically program its metering devices to pointto the company servers.¶

• Manufacturer Server¶

  The DNS name of the directory or proxy is hardwired to the software by the manufacturer, and the directory or proxy is actually run by themanufacturer. This approach is suitable in many consumer usagescenarios, where it would be unreasonable to assume that the consumerruns any specific network services. The manufacturer's web interfaceand the directory/proxy servers can cooperate to provide the desiredfunctionality to the end user. For instance, the end user can registera device identity in the manufacturer's web interface and ask that specificactions be taken when the device does something.¶

• Delegating Manufacturer Server¶

  The DNS name of the directory or proxy is hardwired to the software bythe manufacturer, but this directory or proxy merely redirects therequest to a directory or proxy run by whoever bought thedevice. This approach is suitable in many enterprise environments, asit allows the enterprise to be in charge of actual data collection anddevice registries; only the initial bootstrap goes through themanufacturer. In many cases, there are even legal requirements (such asEU privacy laws) that prevent providing unnecessary information tothird parties.¶

• Common Global Resolution Infrastructure¶

  The delegating manufacturer server model could be generalized intoa 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 mostlysuitable for large manufacturers and deployments. Good automatedmechanisms for discovery of devices that are manufactured and deployedin small quantities are still needed.¶

6.Data Formats

A variety of data formats exist for passing around data. These dataformats 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 canhave a significant effect on the amount of energy required for thecommunications, and as such it is highly desirable to keep messagelengths minimal. At the same time, extreme optimization can affectflexibility and ease of programming. The authors recommend that readers referto[RFC8428] for a compact but easily processed and extendable format.¶

7.Real-Time Reachable Devices

These devices are often best modeled as CoAP servers. The devicewill have limited control over when it receives messages, and it willhave to listen actively for messages, up to the limits of theunderlying link layer. If in some phase of its operation the device also acts in the role of a client, it can control how many transmissions it makeson its own behalf.¶

The packet reception checks should be tailored according to therequirements of the application. If sub-second response time is notneeded, a more infrequent checking process may save some power.¶

For sensor-type devices, the CoAP Observe extension (Observe option)[RFC7641] may be supported. This allows the sensor to trackchanges to the sensed value and make an immediate observationresponse upon a change. This may reduce the amount of polling neededto be done by the client. Unfortunately, it does not reduce the timethat the device needs to be listening for requests. Subscriptionrequests from clients other than the currently registered client may comein at any time, the current client may change its request, and the devicestill needs to respond to normal queries as a server. As a result, thesensor cannot rely on having to communicate only on its own choice ofobservation interval.¶

In order to act as a server, the device needs to be placed in apublic IPv4 address, be reachable over IPv6, or be hosted in a privatenetwork. If the device is hosted on a private network, then allother nodes that need to access this device also need to reside in the sameprivate network. There are multiple ways to provide private networksover public cellular networks. One approach is to dedicate a specialAPN for the private network. Corporate access via cellular networkshas often been arranged in this manner, for instance. Another approachis to use Virtual Private Network (VPN) technology -- for instance,IPsec-based VPNs.¶

Power consumption from unwanted traffic is problematic in thesedevices, unless they are placed in a private network or protected by anoperator-provided firewall service. Devices on an IPv6 network willbe afforded some protection due to the nature of the 2⁶⁴ address allocationfor a single terminal in a 3GPP cellular network; the attackers willbe unable to guess the full IP address of the device. However, thisprotects only the device from processing a packet, but since thenetwork will still deliver the packet to any of the addresses withinthe assigned 64-bit prefix, packet reception costs are stillincurred.¶

Note that the VPN approach cannot prevent unwanted trafficreceived at the tunnel endpoint address and may require keep-alivetraffic. Special APNs can solve this issue but require an explicitarrangement with the service provider.¶

8.Sleepy Devices

These devices are best modeled as devices that can delegate queriesto some other node -- for instance, as mirror servers[CoRE-Mirror] or CoAPpub⁠/sub Clients[CoAP-PubSub]. When the device initializesitself, it makes a registration of itself in a server or broker as describedabove inSection 5 and then continues to send periodicupdates of sensor values.¶

As a result, the device acts only as a client and not as a server, andcan shut down all communication channels during itssleeping period. The length of the sleeping period depends on powerand application requirements. Some environmental sensors might use aday or a week as the period, while other devices may use smallervalues ranging from minutes to hours.¶

The ability to shut down communications and act as only a clienthas four impacts:¶

• Radio transmission and reception can be turned off during thesleeping period, reducing power consumption significantly.¶
• However, some power and time are consumed by having to reattach tothe network after the end of a sleep period.¶
• The window of opportunity for unwanted traffic to arrive is muchsmaller, as the device is listening for traffic only part of thetime. Note, however, that networks may cache packets for some time. Onthe other hand, stateful firewalls can effectively remove much of theunwanted traffic for client-type devices.¶
• The device may exist behind a NAT or a firewall without beingimpacted. Note that the "simple security" basic IPv6 firewall capability[RFC6092] blocks inbound UDP traffic by default, so justmoving to IPv6 is not a direct solution to this problem.¶

For sleepy devices that represent actuators, it is also possible touse 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.¶

10.IANA Considerations

This document has no IANA actions.¶

Authors' Addresses