rfc9178.original   rfc9178.txt 
Network Working Group J. Arkko Internet Engineering Task Force (IETF) J. Arkko
Internet-Draft A. Eriksson Request for Comments: 9178 Ericsson
Intended status: Informational A. Keranen Category: Informational A. Eriksson
Expires: July 7, 2016 Ericsson ISSN: 2070-1721 Independent
January 4, 2016 A. Keränen
Ericsson
May 2022
Building Power-Efficient CoAP Devices for Cellular Networks Building Power-Efficient Constrained Application Protocol (CoAP) Devices
draft-ietf-lwig-cellular-06 for Cellular Networks
Abstract Abstract
This memo discusses the use of the Constrained Application Protocol This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol in building sensors and other devices that employ (CoAP) in building sensors and other devices that employ cellular
cellular networks as a communications medium. Building communicating networks as a communications medium. Building communicating devices
devices that employ these networks is obviously well known, but this that employ these networks is obviously well known, but this memo
memo focuses specifically on techniques necessary to minimize power focuses specifically on techniques necessary to minimize power
consumption. consumption.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on July 7, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9178.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Revised BSD License text as described in Section 4.e of the
the Trust Legal Provisions and are provided without warranty as Trust Legal Provisions and are provided without warranty as described
described in the Simplified BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Goals for Low-Power Operation . . . . . . . . . . . . . . . . 3 2. Goals for Low-Power Operation
3. Link-Layer Assumptions . . . . . . . . . . . . . . . . . . . 5 3. Link-Layer Assumptions
4. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Scenarios
5. Discovery and Registration . . . . . . . . . . . . . . . . . 8 5. Discovery and Registration
6. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Data Formats
7. Real-Time Reachable Devices . . . . . . . . . . . . . . . . . 10 7. Real-Time Reachable Devices
8. Sleepy Devices . . . . . . . . . . . . . . . . . . . . . . . 11 8. Sleepy Devices
8.1. Implementation Considerations . . . . . . . . . . . . . . 12 8.1. Implementation Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References
11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1. Normative References
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction 1. Introduction
This memo discusses the use of the Constrained Application Protocol This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol [RFC7252] in building sensors and other devices that (CoAP) [RFC7252] in building sensors and other devices that employ
employ cellular networks as a communications medium. Building cellular networks as a communications medium. Building communicating
communicating devices that employ these networks is obviously well devices that employ these networks is obviously well known, but this
known, but this memo focuses specifically on techniques necessary to memo focuses specifically on techniques necessary to minimize power
minimize power consumption. CoAP has many advantages, including consumption. CoAP has many advantages, including being simple to
being simple to implement; a thousand lines for the entire software implement; a thousand lines of code for the entire application above
above IP layer is plenty for a CoAP-based sensor, for instance. the IP layer is plenty for a CoAP-based sensor, for instance.
However, while many of these advantages are obvious and easily However, while many of these advantages are obvious and easily
obtained, optimizing power consumption remains challenging and obtained, optimizing power consumption remains challenging and
requires careful design [I-D.arkko-core-sleepy-sensors]. requires careful design [Tiny-CoAP].
The memo targets primarily 3GPP cellular networks in their 2G, 3G, This memo primarily targets 3GPP cellular networks in their 2G, 3G,
and LTE variants and their future enhancements, including possible LTE, and 5G variants and their future enhancements, including
power efficiency improvements at the radio and link layers. The possible power efficiency improvements at the radio and link layers.
exact standards or details of the link layer or radios are not The exact standards or details of the link layer or radios are not
relevant for our purposes, however. To be more precise, the material relevant for our purposes, however. To be more precise, the material
in this memo is suitable for any large-scale, public network that in this memo is suitable for any large-scale, public network that
employs point-to-point communications model and radio technology for employs a point-to-point communications model and radio technology
the devices in the network. for the devices in the network.
Our focus is devices that need to be optimized for power usage, and Our focus is on devices that need to be optimized for power usage and
on devices that employ CoAP. As a general technology, CoAP is devices that employ CoAP. As a general technology, CoAP is similar
similar to HTTP. It can be used in various ways and network entities to HTTP. It can be used in various ways, and network entities may
may take on different roles. This freedom allows the technology to take on different roles. This freedom allows the technology to be
be used in efficient and less efficient ways. Some guidance is used in efficient and less efficient ways. Some guidance is needed
needed to understand what communication models over CoAP are to understand what types of communication over CoAP are recommended
recommended when low power usage is a critical goal. when low power usage is a critical goal.
The recommendations in this memo should be taken as complementary to The recommendations in this memo should be taken as complementary to
device hardware optimization, microelectronics improvements, and device hardware optimization, microelectronics improvements, and
further evolution of the underlying link and radio layers. Further further evolution of the underlying link and radio layers. Further
gains in power efficiency can certainly be gained on several fronts; gains 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 at the approach that we take in this memo is to do what can be done at
the IP, transport, and application layers to provide the best the IP, transport, and application layers to provide the best
possible power efficiency. Application implementors generally have possible power efficiency. Application implementors generally have
to use the current generation microelectronics, currently available to use the current-generation microelectronics, currently available
radio networks and standards, and so on. This focus in our memo radio networks and standards, and so on. This focus in our memo
should by no means be taken as an indication that further evolution should by no means be taken as an indication that further evolution
in these other areas is unnecessary. Such evolution is useful, is in these other areas is unnecessary. Such evolution is useful,
ongoing, and is generally complementary to the techniques presented ongoing, and generally complementary to the techniques presented in
in this memo. The evolution of underlying technologies may change this memo. However, the list of techniques described in this
what techniques described here are useful for a particular document as useful for a particular application may change with the
application, however. evolution of these underlying technologies.
The rest of this memo is structured as follows. Section 2 discusses The rest of this memo is structured as follows. Section 2 discusses
the need and goals for low-power devices. Section 3 outlines our the need and goals for low-power devices. Section 3 outlines our
expectations for the low layer communications model. Section 4 expectations for the low-layer communications model. Section 4
describes the two scenarios that we address, and Section 5, describes the two scenarios that we address. Sections 5, 6, 7, and 8
Section 6, Section 7 and Section 8 give guidelines for use of CoAP in give guidelines for the use of CoAP in these scenarios.
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 2. Goals for Low-Power Operation
There are many situations where power usage optimization is There are many situations where power usage optimization is
unnecessary. Optimization may not be necessary on devices that can unnecessary. Optimization may not be necessary on devices that can
run on power feed over wired communications media, such as in Power- run on a power feed over wired communications media, such as in
over-Ethernet (PoE) solutions. These devices may require a Power-over-Ethernet (PoE) solutions. These devices may require a
rudimentary level of power optimization techniques just to keep rudimentary level of power optimization techniques just to keep
overall energy costs and aggregate power feed sizes at a reasonable overall energy costs and aggregate power feed sizes at a reasonable
level, but more extreme techniques necessary for battery powered level, but more extreme techniques necessary for battery-powered
devices are not required. The situation is similar with devices that devices are not required. The situation is similar with devices that
can easily be connected to mains power. Other types of devices may can easily be connected to mains power. Other types of devices may
get an occasional charge of power from energy harvesting techniques. get an occasional charge of power from energy-harvesting techniques.
For instance, some environmental sensors can run on solar cells. For instance, some environmental sensors can run on solar cells.
Typically, these devices still have to regulate their power usage in Typically, these devices still have to regulate their power usage in
a strict manner, for instance to be able to use as small and a strict manner -- for instance, to be able to use solar cells that
inexpensive solar cells as possible. are as small and inexpensive as possible.
In battery operated devices the power usage is even more important. In battery-operated devices, power usage is even more important. For
For instance, one of the authors employs over a hundred different instance, one of the authors employs over a hundred different sensor
sensor devices in his home network. A majority of these devices are devices in their home network. A majority of these devices are wired
wired and run on PoE, but in most environments this would be and run on PoE, but in most environments this would be impractical
impractical because the necessary wires do not exist. The future is because the necessary wires do not exist. The future is in wireless
in wireless solutions that can cover buildings and other environments solutions that can cover buildings and other environments without
without assuming a pre-existing wired infrastructure. In addition, assuming a pre-existing wired infrastructure. In addition, in many
in many cases it is impractical to provide a mains power source. cases it is impractical to provide a mains power source. Often,
Often there are no power sockets easily available in the locations there are no power sockets easily available in the locations that the
that the devices need to be in, and even if there were, setting up devices need to be in, and even if there were, setting up the wires
the wires and power adapters would be more complicated than and power adapters would be more complicated than installing a
installing a standalone device without any wires. standalone device without any wires.
Yet, with a large number of devices the battery lifetimes become Yet, with a large number of devices, the battery lifetimes become
critical. Cost and practical limits dictate that devices can be critical. Cost and practical limits dictate that devices can be
largely just bought and left on their own. For instance, with largely just bought and left on their own. For instance, with a
hundred devices, even a ten-year battery lifetime results in a hundred devices, even a ten-year battery lifetime results in a
monthly battery change for one device within the network. This may monthly battery change for one device within the network. This may
be impractical in many environments. In addition, some devices may be impractical in many environments. In addition, some devices may
be physically difficult to reach for a battery change. Or, a large be physically difficult to reach for a battery change. Or, a large
group of devices -- such as utility meters or environmental sensors group of devices -- such as utility meters or environmental sensors
-- cannot be economically serviced too often, even if in theory the -- cannot be economically serviced too often, even if in theory the
batteries could be changed. batteries could be changed.
Many of these situations lead to a requirement for minimizing power Many of these situations lead to a requirement for minimizing power
usage and/or maximizing battery lifetimes. Using the power usage usage and/or maximizing battery lifetimes. Using the power usage
strategies described in [RFC7228], mains-powered sensor-type devices strategies described in [RFC7228], mains-powered sensor-type devices
can use the Always-on strategy whereas battery or energy harvesting can use the Always-on strategy, whereas battery-operated or energy-
devices need to adjust behavior based on the communication interval. harvesting devices need to adjust behavior based on the communication
For intervals in the order of seconds, Low-power strategy is interval. For intervals on the order of seconds, the Low-power
appropriate. For intervals ranging from minutes to hours either Low- strategy is appropriate. For intervals ranging from minutes to
power or Normally-off strategies are suitable. Finally, for hours, either the Low-power or Normally-off strategy is suitable.
intervals lasting days and longer, Normally-off is usually the best Finally, for intervals lasting days or longer, Normally-off is
choice. Unfortunately, much of our current technology has been built usually the best choice. Unfortunately, much of our current
with different objectives in mind. Networked devices that are technology has been built with different objectives in mind -- for
"always on", gadgets that require humans to recharge them every instance, networked devices that are "always on", gadgets that
couple of days, and protocols that have been optimized to maximize require humans to recharge them every couple of days, and protocols
throughput rather than conserve resources. that have been optimized to maximize throughput rather than conserve
resources.
Long battery lifetimes are required for many applications, however. Long battery lifetimes are required for many applications, however.
In some cases these lifetimes should be in the order of years or even In some cases, these lifetimes should be on the order of years or
a decade or longer. Some communication devices already reach multi- even a decade or longer. Some communication devices already reach
year lifetimes, and continuous improvement in low-power electronics multi-year lifetimes, and continuous improvements in low-power
and advances in radio technology keep pushing these lifetimes longer. electronics and advances in radio technology keep pushing these
However, it is perhaps fair to say that battery lifetimes are lifetimes longer. However, it is perhaps fair to say that battery
generally too short at present time. lifetimes are generally too short at present.
Power usage can not be evaluated solely based on lower layer Power usage cannot be evaluated based solely on lower-layer
communications. The entire system, including upper layer protocols communications. The entire system, including upper-layer protocols
and applications is responsible for the power consumption as a whole. and applications, is responsible for the power consumption as a
The lower communication layers have already adopted many techniques whole. The lower communication layers have already adopted many
that can be used to reduce power usage, such as scheduling device techniques that can be used to reduce power usage, such as scheduling
wake-up times. Further reductions will likely need some co-operation device wake-up times. Further reductions will likely need some
from the upper layers so that unnecessary communications, denial-of- cooperation from the upper layers so that unnecessary communications,
service attacks on power consumption, and other power drains are denial-of-service attacks on power consumption, and other power
eliminated. drains are eliminated.
Of course, application requirements ultimately determine what kinds Of course, application requirements ultimately determine what kinds
of communications are necessary. For instance, some applications of communications are necessary. For instance, some applications
require more data to be sent than others. The purpose of the require more data to be sent than others. The purpose of the
guidelines in this memo is not to prefer one or the other guidelines in this memo is not to prefer one or the other
application, but to provide guidance on how to minimize the amount of application, but to provide guidance on how to minimize the amount of
communications overhead that is not directly required by the communications overhead that is not directly required by the
application. While such optimization is generally useful, it is application. While such optimization is generally useful, it is,
relatively speaking most noticeable in applications that transfer relatively speaking, most noticeable in applications that transfer
only a small amount of data, or operate only infrequently. only a small amount of data or operate only infrequently.
3. Link-Layer Assumptions 3. Link-Layer Assumptions
We assume that the underlying communications network can be any We assume that the underlying communications network can be any
large-scale, public network that employs point-to-point large-scale, public network that employs a point-to-point
communications model and radio technology. 2G, 3G, and LTE networks communications model and radio technology. 2G, 3G, LTE, and 5G
are examples of such networks, but not the only possible networks networks are examples of such networks but are not the only possible
with these characteristics. networks with these characteristics.
In the following we look at some of these characteristics and their In the following, we look at some of these characteristics and their
implications. Note that in most cases these characteristics are not implications. Note that in most cases these characteristics are not
properties of the specific networks but rather inherent in the properties of the specific networks but rather are inherent in the
concept of public networks. concept of public networks.
Public networks * Public Networks
Using a public network service implies that applications can be Using a public network service implies that applications can be
deployed without having to build a network to go with them. For deployed without having to build a network to go with them. For
economic reasons, only the largest users (such as utility economic reasons, only the largest users (such as utility
companies) could afford to build their own network, and even they companies) could afford to build their own network, and even they
would not be able to provide a world-wide coverage. This means would not be able to provide worldwide coverage. This means that
that applications where coverage is important can be built. For applications where coverage is important can be built. For
instance, most transport sector applications require national or instance, most transport-sector applications require national or
even world-wide coverage to work. even worldwide coverage to work.
But there are other implications, as well. By definition, the But there are other implications as well. By definition, the
network is not tailored for this application and with some network is not tailored for this application, and, with some
exceptions, the traffic passes through the Internet. One exceptions, the traffic passes through the Internet. One
implication of this is that there are generally no application- implication of this is that there are generally no application-
specific network configurations or discovery support. For specific network configurations or discovery support. For
instance, the public network helps devices to get on the Internet, instance, the public network helps devices to get on the Internet,
set up default routers, configure DNS servers, and so on, but does set up default routers, configure DNS servers, and so on, but does
nothing for configuring possible higher-layer functions, such as nothing for configuring possible higher-layer functions, such as
servers the device might need to contact to perform its servers that a device might need to contact to perform its
application functions. application functions.
Public networks often provide web proxies and other functionality Public networks often provide web proxies and other functionality
that can in some cases make a significant improvement for delays that can, in some cases, make significant improvements related to
and cost of communication over the wireless link. For instance, delays and costs of communication over the wireless link. For
resolving server DNS names in a proxy instead of the user's device instance, resolving server DNS names in a proxy instead of the
may cut down on the general chattiness of the communications, user's device may cut down on the general chattiness of the
therefore reducing overall delay in completing the entire communications, therefore reducing overall delay in completing the
transaction. Likewise, a CoAP proxy or pub/sub broker entire transaction. Likewise, a CoAP proxy or Publish-Subscribe
[I-D.koster-core-coap-pubsub] can assist a CoAP device in (pub/sub) Broker [CoAP-PubSub] can assist a CoAP device in
communication. However, unlike HTTP web proxies, CoAP proxies and communication. However, unlike HTTP web proxies, CoAP proxies and
brokers are not yet widely deployed in public networks. brokers are not yet widely deployed in public networks.
Similarly, given the lack of available IPv4 addresses, the chances Similarly, given the lack of available IPv4 addresses, chances are
are that many devices are behind a network address translation that many devices are behind a Network Address Translation (NAT)
(NAT) device. This means that they are not easily reachable as device. This means that they are not easily reachable as servers.
servers. Alternatively, the devices may be directly on the global Alternatively, the devices may be directly on the global Internet
Internet (either on IPv4 or IPv6) and easily reachable as servers. (on either IPv4 or IPv6) and easily reachable as servers.
Unfortunately, this may mean that they also receive unwanted Unfortunately, this may mean that they also receive unwanted
traffic, which may have implications for both power consumption traffic, which may have implications for both power consumption
and service costs. and service costs.
Point-to-point link model * Point-to-Point Link Model
This is a common link model in cellular networks. One implication This is a common link model in cellular networks. One implication
of this model is that there will be no other nodes on the same of this model is that there will be no other nodes on the same
link, except maybe for the service provider's router. As a link, except maybe for the service provider's router. As a
result, multicast discovery can not be reasonably used for any result, multicast discovery cannot be reasonably used for any
local discovery purposes. While the configuration of the service local discovery purposes. While the configuration of the service
provider's router for specific users is theoretically possible, in provider's router for specific users is theoretically possible,
practice this is difficult to achieve, at least for any small user this is difficult to achieve in practice, at least for any small
that can not afford a network-wide contract for a private APN user that cannot afford a network-wide contract for a private APN
(Access Point Name). The public network access service has little (Access Point Name). The public network access service has little
per-user tailoring. per-user tailoring.
Radio technology * Radio Technology
The use of radio technology means that power is needed to operate The use of radio technology means that power is needed to operate
the radios. Transmission generally requires more power than the radios. Transmission generally requires more power than
reception. However, radio protocols have generally been designed reception. However, radio protocols have generally been designed
so that a device checks periodically whether it has messages. In so that a device checks periodically to see whether it has
a situation where messages arrive seldom or not at all, this messages. In a situation where messages arrive seldom or not at
checking consumes energy. Research has shown that these periodic all, this checking consumes energy. Research has shown that these
checks (such as LTE paging message reception) are often a far periodic checks (such as LTE paging message reception) are often a
bigger contributor to energy consumption than message far bigger contributor to energy consumption than message
transmission. transmission.
Note that for situations where there are several applications on Note that for situations where there are several applications on
the same device wishing to communicate with the Internet in some the same device wishing to communicate with the Internet in some
manner, bundling those applications together so that they can manner, bundling those applications together so that they can
communicate at the same time can be very useful. Some guidance communicate at the same time can be very useful. Some guidance
for these techniques in the smartphone context can be found in for these techniques in the smartphone context can be found in
[Android-Bundle]. [Android-Bundle].
Naturally, each device has a freedom to decide when it sends Naturally, each device has the freedom to decide when it sends
messages. In addition, we assume that there is some way for the messages. In addition, we assume that there is some way for the
devices to control when or how often it wants to receive messages. devices to control when or how often they want to receive messages.
Specific methods for doing this depend on the specific network being Specific methods for doing this depend on the specific network being
used and also tend to change as improvements in the design of these used and also tend to change as improvements in the design of these
networks are incorporated. The reception control methods generally networks are incorporated. The reception control methods generally
come in two variants, fine grained mechanisms that deal with how come in two variants: (1) fine-grained mechanisms that deal with how
often the device needs to wake-up for paging messages, and more crude often the device needs to wake up for paging messages and (2) cruder
mechanisms where the device simply disconnects from the network for a mechanisms where the device simply disconnects from the network for a
period of time. There are associated costs and benefits to each period of time. There are costs and benefits associated with each
method, but those are not relevant for this memo, as long as some method, but those are not relevant for this memo, as long as some
control method exists. Furthermore, devices could use Delay-Tolerant control method exists. Furthermore, devices could use Delay-Tolerant
Networking (DTN) [RFC4838] mechanisms to relax the requirements for Networking (DTN) mechanisms [RFC4838] to relax the requirements for
timeliness of connectivity and message delivery. timeliness of connectivity and message delivery.
4. Scenarios 4. Scenarios
Not all applications or situations are equal. They may require Not all applications or situations are equal. They may require
different solutions or communication models. This memo focuses on different solutions or communication models. This memo focuses on
two common scenarios at cellular networks: two common scenarios in cellular networks:
Real-Time Reachable Devices * Real-Time Reachable Devices
This scenario involves all communication that requires real-time This scenario involves all communication that requires real-time
or near real-time communications with a device. That is, a or near-real-time communications with a device. That is, a
network entity must be able to reach the device with a small time network entity must be able to reach the device with a small time
lag at any time, and no pre-agreed wake-up schedule can be lag at any time, and no previously agreed-upon wake-up schedule
arranged. By "real-time" we mean any reasonable end-to-end can be arranged. By "real-time", we mean any reasonable end-to-
communications latency, be it measured in milliseconds or seconds. end communications latency, be it measured in milliseconds or
However, unpredictable sleep states are not expected. seconds. However, unpredictable sleep states are not expected.
Examples of devices in this category include sensors that must be Examples of devices in this category include sensors that must be
measurable from a remote source at any instant in time, such as measurable from a remote source at any instant in time, such as
process automation sensors and actuators that require immediate process automation sensors and actuators that require immediate
action, such as light bulbs or door locks. action, such as light bulbs or door locks.
Sleepy Devices * Sleepy Devices
This scenario involves freedom to choose when device communicates. This scenario involves the freedom to choose when a device
The device is often expected to be able to be in a sleep state for communicates. The device is often expected to be able to be in a
much of its time. The device itself can choose when it sleep state for much of its time. The device itself can choose
communicates, or it lets the network assist in this task. when it communicates, or it lets the network assist in this task.
Examples of devices in this category include sensors that track Examples of devices in this category include sensors that track
slowly changing values, such as temperature sensors and actuators slowly changing values, such as temperature sensors and actuators
that control a relatively slow process, such as heating systems. that control a relatively slow process, such as heating systems.
Note that there may be hard real-time requirements, but they are Note that there may be hard real-time requirements, but they are
expressed in terms of how fast the device can communicate, not in expressed in terms of how fast the device can communicate -- not
terms of how fast it can respond to a network stimuli. For in terms of how fast it can respond to network stimuli. For
instance, a fire detector can be classified as a sleepy device as instance, a fire detector can be classified as a sleepy device as
long as it can internally quickly wake up on detecting fire and long as it can internally quickly wake up on detecting fire and
initiate the necessary communications without delay. initiate the necessary communications without delay.
5. Discovery and Registration 5. Discovery and Registration
In both scenarios the device will be attached to a public network. In both scenarios, the device will be attached to a public network.
Without special arrangements, the device will also get a dynamically Without special arrangements, the device will also get a dynamically
assigned IP address or an IPv6 prefix. At least one but typically assigned IP address or an IPv6 prefix. At least one but typically
several router hops separate the device from its communicating peers several router hops separate the device from its communicating peers
such as application servers. As a result, the address or even the such as application servers. As a result, the address or even the
existence of the device is typically not immediately obvious to the existence of the device is typically not immediately obvious to the
other nodes participating in the application. As discussed earlier, other nodes participating in the application. As discussed earlier,
multicast discovery has limited value in public networks; network multicast discovery has limited value in public networks; network
nodes cannot practically discover individual devices in a large nodes cannot practically discover individual devices in a large
public network. And the devices can not discover who they need to public network. And the devices cannot discover who they need to
talk, as the public network offers just basic Internet connectivity. talk to, as the public network offers just basic Internet
connectivity.
Our recommendation is to initiate a discovery and registration Our recommendation is to initiate a discovery and registration
process. This allows each device to inform its peers that it has process. This allows each device to inform its peers that it has
connected to the network and that it is reachable at a given IP connected to the network and that it is reachable at a given IP
address. Registration also facilitates low-power operation since a address. Registration also facilitates low-power operation, since a
device can delegate part of the discovery signaling and reachability device can delegate part of the discovery signaling and reachability
requirements to another node. requirements to another node.
The registration part is easy e.g., with a resource directory. The The registration part is easy, e.g., with a resource directory. The
device should perform the necessary registration with these devices, device should perform the necessary registration with such a resource
for instance, as specified in [I-D.ietf-core-resource-directory]. In directory -- for instance, as specified in [RFC9176]. In order to do
order to do this registration, the device needs to know its CoRE Link this registration, the device needs to know its Constrained RESTful
Format description, as specified in [RFC6690]. In essence, the Environments (CoRE) Link Format description, as specified in
registration process involves performing a GET on .well-known/ [RFC6690]. In essence, the registration process involves performing
core/?rt=core-rd at the address of the resource directory, and then a GET on .well-known/core/?rt=core-rd at the address of the resource
doing a POST on the path of the discovered resource. directory and then doing a POST on the path of the discovered
resource.
Other mechanisms enabling device discovery and delegation of Other mechanisms enabling device discovery and delegation of
functionality to a non-sleepy node include functionality to a non-sleepy node include those discussed in
[I-D.vial-core-mirror-proxy] and [I-D.koster-core-coap-pubsub]. [CoRE-Mirror] and [CoAP-PubSub].
However, current CoAP specifications provide only limited support for However, current CoAP specifications provide only limited support for
discovering the resource directory or other registration services. discovering the resource directory or other registration services.
Local multicast discovery only works in LAN-type networks, but not in Local multicast discovery only works in LAN-type networks; it does
these public cellular networks. Our recommended alternate methods not work in the public cellular networks discussed in this document.
for discovery are the following: We recommend the following alternate methods for discovery:
Manual Configuration * Manual Configuration
The DNS name of the resource directory is manually configured. The DNS name of the resource directory is manually configured.
This approach is suitable in situations where the owner of the This approach is suitable in situations where the owner of the
devices has the resources and capabilities to do the devices has the resources and capabilities to do the
configuration. For instance, a utility company can typically configuration. For instance, a utility company can typically
program its metering devices to point to the company servers. program its metering devices to point to the company servers.
Manufacturer Server * Manufacturer Server
The DNS name of the directory or proxy is hardwired to the The DNS name of the directory or proxy is hardwired to the
software by the manufacturer, and the directory or proxy is software by the manufacturer, and the directory or proxy is
actually run by the manufacturer. This approach is suitable in actually run by the manufacturer. This approach is suitable in
many consumer usage scenarios, where it would be unreasonable to many consumer usage scenarios, where it would be unreasonable to
assume that the consumer runs any specific network services. The assume that the consumer runs any specific network services. The
manufacturer's web interface and the directory/proxy servers can manufacturer's web interface and the directory/proxy servers can
co-operate to provide the desired functionality to the end user. cooperate to provide the desired functionality to the end user.
For instance, the end user can register a device identity in the For instance, the end user can register a device identity in the
manufacturer's web interface and ask specific actions to be taken manufacturer's web interface and ask that specific actions be
when the device does something. taken when the device does something.
Delegating Manufacturer Server * Delegating Manufacturer Server
The DNS name of the directory or proxy is hardwired to the The DNS name of the directory or proxy is hardwired to the
software by the manufacturer, but this directory or proxy merely software by the manufacturer, but this directory or proxy merely
redirects the request to a directory or proxy run by the whoever redirects the request to a directory or proxy run by whoever
bought the device. This approach is suitable in many enterprise bought the device. This approach is suitable in many enterprise
environments, as it allows the enterprise to be in charge of environments, as it allows the enterprise to be in charge of
actual data collection and device registries; only the initial actual data collection and device registries; only the initial
bootstrap goes through the manufacturer. In many cases there are bootstrap goes through the manufacturer. In many cases, there are
even legal requirements (such as EU privacy laws) that prevent even legal requirements (such as EU privacy laws) that prevent
providing unnecessary information to third parties. providing unnecessary information to third parties.
Common Global Resolution Infrastructure * Common Global Resolution Infrastructure
The delegating manufacturer server model could be generalized into The delegating manufacturer server model could be generalized into
a reverse-DNS -like discovery infrastructure that could answer the a reverse-DNS-like discovery infrastructure that could, for
question "this is device with identity ID, where is my home example, answer the question "This is a device with identity ID
registration server?". However, at present no such resolution 2456; where is my home registration server?" However, at present,
system exists. (Note: The EPCGlobal system for RFID resolution is no such resolution system exists. (Note: The EPCGlobal system for
reminiscent of this approach.) Radio Frequency Identification (RFID) resolution is reminiscent of
this approach.)
Besides manual configuration, these alternate mechanisms are mostly Besides manual configuration, these alternate mechanisms are mostly
suitable for large manufacturers and deployments. Good automated suitable for large manufacturers and deployments. Good automated
mechanism for discovery of devices that are manufactured and deployed mechanisms for discovery of devices that are manufactured and
in small quantities are still needed. deployed in small quantities are still needed.
6. Data Formats 6. Data Formats
A variety of data formats exist for passing around data. These data A variety of data formats exist for passing around data. These data
formats include XML, JavaScript Object Notation (JSON) [RFC7159], formats include XML, JavaScript Object Notation (JSON) [RFC8259],
Efficient XML Interchange (EXI) [W3C.REC-exi-20110310], and text Efficient XML Interchange (EXI) [W3C.REC-exi-20140211], Concise
Binary Object Representation (CBOR) [RFC8949], and various text
formats. Message lengths can have a significant effect on the amount formats. Message lengths can have a significant effect on the amount
of energy required for the communications, and such it is highly of energy required for the communications, and as such it is highly
desirable to keep message lengths minimal. At the same time, extreme desirable to keep message lengths minimal. At the same time, extreme
optimization can affect flexibility and ease of programming. The optimization can affect flexibility and ease of programming. The
authors recommend [I-D.jennings-core-senml] as a compact, yet easily authors recommend that readers refer to [RFC8428] for a compact but
processed and extendable textual format. easily processed and extendable format.
7. Real-Time Reachable Devices 7. Real-Time Reachable Devices
These devices are often best modeled as CoAP servers. The device These devices are often best modeled as CoAP servers. The device
will have limited control on when it receives messages, and it will will have limited control over when it receives messages, and it will
have to listen actively for messages, up to the limits of the have to listen actively for messages, up to the limits of the
underlying link layer. If the device acts also in client role in underlying link layer. If in some phase of its operation the device
some phase of its operation, it can control how many transmissions it also acts in the role of a client, it can control how many
makes on its own behalf. transmissions it makes on its own behalf.
The packet reception checks should be tailored according to the The packet reception checks should be tailored according to the
requirements of the application. If sub-second response time is not requirements of the application. If sub-second response time is not
needed, a more infrequent checking process may save some power. needed, a more infrequent checking process may save some power.
For sensor-type devices, the CoAP Observe extension [RFC7641] may be For sensor-type devices, the CoAP Observe extension (Observe option)
supported. This allows the sensor to track changes to the sensed [RFC7641] may be supported. This allows the sensor to track changes
value, and make an immediate observation response upon a change. to the sensed value and make an immediate observation response upon a
This may reduce the amount of polling needed to be done by the change. This may reduce the amount of polling needed to be done by
client. Unfortunately, it does not reduce the time that the device the client. Unfortunately, it does not reduce the time that the
needs to be listening for requests. Subscription requests from other device needs to be listening for requests. Subscription requests
clients than the currently registered one may come at any time, the from clients other than the currently registered client may come in
current client may change its request, and the device still needs to at any time, the current client may change its request, and the
respond to normal queries as a server. As a result, the sensor can device still needs to respond to normal queries as a server. As a
not rely having to communicate only on its own choice of observation result, the sensor cannot rely on having to communicate only on its
interval. own choice of observation interval.
In order to act as a server, the device needs to be placed in a In order to act as a server, the device needs to be placed in a
public IPv4 address, be reachable over IPv6, or hosted in a private public IPv4 address, be reachable over IPv6, or be hosted in a
network. If the the device is hosted on a private network, then all private network. If the device is hosted on a private network, then
other nodes need to access this device also need to reside in the all other nodes that need to access this device also need to reside
same private network. There are multiple ways to provide private in the same private network. There are multiple ways to provide
networks over public cellular networks. One approach is to dedicate private networks over public cellular networks. One approach is to
a special APN for the private network. Corporate access via cellular dedicate a special APN for the private network. Corporate access via
networks has often been arranged in this manner, for instance. cellular networks has often been arranged in this manner, for
Another approach is to use Virtual Private Networking (VPN) instance. Another approach is to use Virtual Private Network (VPN)
technology, for instance IPsec-based VPNs. technology -- for instance, IPsec-based VPNs.
Power consumption from unwanted traffic is problematic in these Power consumption from unwanted traffic is problematic in these
devices, unless placed in a private network or protected by a devices, unless they are placed in a private network or protected by
operator-provided firewall service. Devices on an IPv6 network will an operator-provided firewall service. Devices on an IPv6 network
have some protection through the nature of the 2^64 address will be afforded some protection due to the nature of the 2^64
allocation for a single terminal in a 3GPP cellular network; the address allocation for a single terminal in a 3GPP cellular network;
attackers will be unable to guess the full IP address of the device. the attackers will be unable to guess the full IP address of the
However, this protects only the device from processing a packet, but device. However, this protects only the device from processing a
since the network will still deliver the packet to any of the packet, but since the network will still deliver the packet to any of
addresses within the assigned 64-bit prefix, packet reception costs the addresses within the assigned 64-bit prefix, packet reception
are still incurred. costs are still incurred.
Note that the the VPN approach can not prevent unwanted traffic Note that the VPN approach cannot prevent unwanted traffic received
received at the tunnel endpoint address, and may require keep-alive at the tunnel endpoint address and may require keep-alive traffic.
traffic. Special APNs can solve this issue, but require explicit Special APNs can solve this issue but require an explicit arrangement
arrangement with the service provider. with the service provider.
8. Sleepy Devices 8. Sleepy Devices
These devices are best modeled as devices that can delegate queries These devices are best modeled as devices that can delegate queries
to some other node. For instance, as mirror proxy to some other node -- for instance, as mirror servers [CoRE-Mirror]
[I-D.vial-core-mirror-proxy] or CoAP Publish-Subscribe or CoAP pub/sub Clients [CoAP-PubSub]. When the device initializes
[I-D.koster-core-coap-pubsub] clients. When the device initializes itself, it makes a registration of itself in a server or broker as
itself, it makes a registration of itself in a proxy as described described above in Section 5 and then continues to send periodic
above in Section 5 and then continues to send periodic updates of updates of sensor values.
sensor values.
As a result, the device acts only as a client, not a server, and can As a result, the device acts only as a client and not as a server,
shut down all communication channels while it is during its sleeping and can shut down all communication channels during its sleeping
period. The length of the sleeping period depends on power and period. The length of the sleeping period depends on power and
application requirements. Some environmental sensors might use a day application requirements. Some environmental sensors might use a day
or a week as the period, while other devices may use a smaller values or a week as the period, while other devices may use smaller values
ranging from minutes to hours. ranging from minutes to hours.
Other approaches for delegation include CoAP-options described in
[I-D.castellani-core-alive]
[I-D.fossati-core-publish-monitor-options]. In this memo we use
mirror proxies as an example, because of their ability to work with
both HTTP and CoAP implementations; but the concepts are similar and
the IETF work is still in progress so the final protocol details are
yet to be decided.
The ability to shut down communications and act as only a client has The ability to shut down communications and act as only a client has
four impacts: four impacts:
o Radio transmission and reception can be turned off during the * Radio transmission and reception can be turned off during the
sleeping period, reducing power consumption significantly. sleeping period, reducing power consumption significantly.
o However, some power and time is consumed by having to re-attach to * However, some power and time are consumed by having to reattach to
the network after the end of a sleep period. the network after the end of a sleep period.
o The window of opportunity for unwanted traffic to arrive is much * The window of opportunity for unwanted traffic to arrive is much
smaller, as the device is listening for traffic only part of the smaller, as the device is listening for traffic only part of the
time. Note that networks may cache packets for some time though. time. Note, however, that networks may cache packets for some
On the other hand, stateful firewalls can effectively remove much time. On the other hand, stateful firewalls can effectively
of unwanted traffic for client type devices. remove much of the unwanted traffic for client-type devices.
o The device may exist behind a NAT or a firewall without being * The device may exist behind a NAT or a firewall without being
impacted. Note that "Simple Security" basic IPv6 firewall impacted. Note that the "simple security" basic IPv6 firewall
capability [RFC6092] blocks inbound UDP traffic by default, so capability [RFC6092] blocks inbound UDP traffic by default, so
just moving to IPv6 is not direct solution to this problem. just moving to IPv6 is not a direct solution to this problem.
For sleepy devices that represent actuators, it is also possible to For sleepy devices that represent actuators, it is also possible to
use the mirror proxy model. The device can make periodic polls to use the mirror server or pub/sub broker model. A device can receive
the proxy to determine if a variable has changed. information from the server or broker about variable changes via
either polling or notifications.
8.1. Implementation Considerations 8.1. Implementation Considerations
There are several challenges in implementing sleepy devices. They There are several challenges related to implementing sleepy devices.
need hardware that can be put to an appropriate sleep mode but yet They need hardware that can be placed in an appropriate sleep mode
awakened when it is time to do something again. This is not always but awakened when it is time to do something again. This is not
easy in all hardware platforms. It is important to be able to shut always easy in all hardware platforms. It is important to be able to
down as much of the hardware as possible, preferably down to shut down as much of the hardware as possible, preferably down to
everything else except a clock circuit. The platform also needs to everything else except a clock circuit. The platform also needs to
support re-awakening at suitable time scales, as otherwise the device support reawakening at suitable timescales, as otherwise the device
needs to be powered up too frequently. needs to be powered up too frequently.
Most commercial cellular modem platforms do not allow applications to Most commercial cellular modem platforms do not allow applications to
suspend the state of the communications stack. Hence, after a power- suspend the state of the communications stack. Hence, after a power-
off period they need to re-establish communications, which takes some off period, they need to re-establish communications, which takes
amount of time and extra energy. some amount of time and extra energy.
Implementations should have a coordinated understanding of the state Implementations should have a coordinated understanding of the state
and sleeping schedule. For instance, it makes no sense to keep a CPU 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 powered up, waiting for a message when the lower layer has been told
that the next possible paging opportunity is some time away. that the next possible paging opportunity is some time away.
The cellular networks have a number of adjustable configuration The cellular networks have a number of adjustable configuration
parameters, such as the maximum used paging interval. Proper setting parameters, such as the maximum used paging interval. Proper
of these values has an impact on the power consumption of the device, settings of these values have an impact on the power consumption of
but with the current business practices, such settings are rarely the device, but with current business practices, such settings are
negotiated when the user's subscription is provisioned. rarely negotiated when the user's subscription is provisioned.
9. Security Considerations 9. Security Considerations
There are no particular security aspects with what has been discussed There are no particular security aspects related to what has been
in this memo, except for the ability to delegate queries for a discussed in this memo, except for the ability to delegate queries
resource to another node. Depending on how this is done, there are for a resource to another node. Depending on how this is done, there
obvious security issues which have largely NOT yet been addressed in are obvious security issues that have largely NOT yet been addressed
the relevant Internet Drafts [I-D.vial-core-mirror-proxy] in the relevant Internet-Drafts [CoRE-Mirror] [CoAP-Alive]
[I-D.castellani-core-alive] [CoAP-Publ-Monitor]. However, we point out that, in general,
[I-D.fossati-core-publish-monitor-options]. However, we point out security issues in delegation can be solved through either reliance
that in general, security issues in delegation can be solved either on your local network support nodes (which may be quite reasonable in
through reliance on your local network support nodes (which may be many environments) or explicit end-to-end security. Explicit end-to-
quite reasonable in many environments) or explicit end-to-end end security through nodes that are awake at different times means,
security. Explicit end-to-end security through nodes that are awake in practice, end-to-end data object security. We have implemented
at different times means in practice end-to-end data object security. one such mechanism for sleepy nodes as described in [RFC8387].
We have implemented one such mechanism for sleepy nodes as described
in [I-D.aks-lwig-crypto-sensors].
The security considerations relating to CoAP [RFC7252] and the The security considerations relating to CoAP [RFC7252] and the
relevant link layers should apply. Note that cellular networks relevant link layers should apply. Note that cellular networks
universally employ per-device authentication, integrity protection, universally employ per-device authentication, integrity protection,
and for most of the world, encryption of all their communications. and, for most of the world, encryption of all their communications.
Additional protection of transport sessions is possible through Additional protection of transport sessions is possible through
mechanisms described in [RFC7252] or data objects. mechanisms described in [RFC7252] or data objects.
10. IANA Considerations 10. IANA Considerations
There are no IANA impacts in this memo. This document has no IANA actions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", STD 90, RFC 8259,
2014, <http://www.rfc-editor.org/info/rfc7159>. DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<http://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[I-D.ietf-core-resource-directory] [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE Representation (CBOR)", STD 94, RFC 8949,
Resource Directory", draft-ietf-core-resource-directory-05 DOI 10.17487/RFC8949, December 2020,
(work in progress), October 2015. <https://www.rfc-editor.org/info/rfc8949>.
[W3C.REC-exi-20110310] [RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
Kamiya, T. and J. Schneider, "Efficient XML Interchange P. van der Stok, "Constrained RESTful Environments (CoRE)
(EXI) Format 1.0", World Wide Web Consortium Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
Recommendation REC- 2022, <https://www.rfc-editor.org/info/rfc9176>.
exi-20110310 http://www.w3.org/TR/2011/REC-exi-20110310,
March 2011.
[I-D.jennings-core-senml] [W3C.REC-exi-20140211]
Jennings, C., Shelby, Z., Arkko, J., and A. Keranen, Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
"Media Types for Sensor Markup Language (SENML)", draft- "Efficient XML Interchange (EXI) Format 1.0 (Second
jennings-core-senml-02 (work in progress), October 2015. 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 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
11.2. Informative References 11.2. Informative References
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <http://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092, Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011, DOI 10.17487/RFC6092, January 2011,
<http://www.rfc-editor.org/info/rfc6092>. <https://www.rfc-editor.org/info/rfc6092>.
[I-D.arkko-core-sleepy-sensors] [Tiny-CoAP]
Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
Novo, "Implementing Tiny COAP Sensors", draft-arkko-core- Novo, "Implementing Tiny COAP Sensors", Work in Progress,
sleepy-sensors-01 (work in progress), July 2011. Internet-Draft, draft-arkko-core-sleepy-sensors-01, 5 July
2011, <https://datatracker.ietf.org/doc/html/draft-arkko-
core-sleepy-sensors-01>.
[I-D.aks-lwig-crypto-sensors] [RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
Considerations and Implementation Experiences in Securing Considerations and Implementation Experiences in Securing
Smart Object Networks", draft-aks-lwig-crypto-sensors-00 Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387,
(work in progress), October 2015. May 2018, <https://www.rfc-editor.org/info/rfc8387>.
[I-D.castellani-core-alive] [CoAP-Alive]
Castellani, A. and S. Loreto, "CoAP Alive Message", draft- Castellani, A. and S. Loreto, "CoAP Alive Message", Work
castellani-core-alive-00 (work in progress), March 2012. in Progress, Internet-Draft, draft-castellani-core-alive-
00, 29 March 2012, <https://datatracker.ietf.org/doc/html/
draft-castellani-core-alive-00>.
[I-D.fossati-core-publish-monitor-options] [CoAP-Publ-Monitor]
Fossati, T., Giacomin, P., and S. Loreto, "Publish and Fossati, T., Giacomin, P., and S. Loreto, "Publish and
Monitor Options for CoAP", draft-fossati-core-publish- Monitor Options for CoAP", Work in Progress, Internet-
monitor-options-01 (work in progress), March 2012. Draft, draft-fossati-core-publish-monitor-options-01, 10
March 2012, <https://datatracker.ietf.org/doc/html/draft-
fossati-core-publish-monitor-options-01>.
[I-D.vial-core-mirror-proxy] [CoRE-Mirror]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- Vial, M., "CoRE Mirror Server", Work in Progress,
proxy-01 (work in progress), July 2012. Internet-Draft, draft-vial-core-mirror-proxy-01, 13 July
2012, <https://datatracker.ietf.org/doc/html/draft-vial-
core-mirror-proxy-01>.
[I-D.koster-core-coap-pubsub] [CoAP-PubSub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-koster-core-coap-pubsub-04 (work in (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
progress), November 2015. core-coap-pubsub-10, 4 May 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-core-
coap-pubsub-10>.
[Android-Bundle] [Android-Bundle]
"Optimizing Downloads for Efficient Network Access", "Optimize network access", Android developer note, May
Android developer note 2022, <https://developer.android.com/training/efficient-
http://developer.android.com/training/efficient-downloads/ downloads/efficient-network-access.html>.
efficient-network-access.html, February 2013.
Appendix A. Acknowledgments Acknowledgments
The authors would like to thank Zach Shelby, Jan Holler, Salvatore The authors would like to thank Zach Shelby, Jan Holler, Salvatore
Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim
Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran,
Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes
Tschofenig, and Anna Larmo for interesting discussions in this Tschofenig, and Anna Larmo for interesting discussions in this
problem space. problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Anders Eriksson Anders Eriksson
Ericsson Independent
Stockholm 164 83 SE-164 83 Stockholm
Sweden Sweden
Email: anders.e.eriksson@posthem.se
Email: anders.e.eriksson@ericsson.com Ari Keränen
Ari Keranen
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: ari.keranen@ericsson.com Email: ari.keranen@ericsson.com
 End of changes. 128 change blocks. 
368 lines changed or deleted 380 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/