rfc9178xml2.original.xml   rfc9178.xml 
<?xml version="1.0" encoding="iso-8859-1" ?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902"
docName="draft-ietf-lwig-cellular-06"
category="info">
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>
<front>
<title abbrev="Power-Efficient Cellular CoAP devices">Building Power-Efficient C
oAP Devices for Cellular Networks</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="A" surname="Eriksson" fullname="Anders Eriksson">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Stockholm</city> <code>164 83</code>
<country>Sweden</country>
</postal>
<email>anders.e.eriksson@ericsson.com</email>
</address>
</author>
<author initials="A" surname="Keranen" fullname="Ari Keranen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<date year="2016" />
<keyword>CoAP</keyword>
<keyword>cellular networks</keyword>
<abstract> <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<t>This memo discusses the use of the Constrained Application Protocol <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902"
(CoAP) protocol in building sensors and other devices that employ docName="draft-ietf-lwig-cellular-06" number="9178" category="info"
obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en
" tocInclude="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.1.1 -->
<front>
<title abbrev="Power-Efficient Cellular CoAP Devices">Building
Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular
Networks</title>
<seriesInfo name="RFC" value="9178"/>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="A" surname="Eriksson" fullname="Anders Eriksson">
<organization>Independent</organization>
<address>
<postal>
<street/>
<city>Stockholm</city>
<code>164 83</code>
<country>Sweden</country>
</postal>
<email>anders.e.eriksson@posthem.se</email>
</address>
</author>
<author initials="A" surname="Keränen" fullname="Ari Keränen">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>ari.keranen@ericsson.com</email>
</address>
</author>
<date month="May" year="2022"/>
<keyword>CoAP</keyword>
<keyword>cellular networks</keyword>
<abstract>
<t>This memo discusses the use of the Constrained Application Protocol
(CoAP) in building sensors and other devices that employ
cellular networks as a communications medium. Building communicating cellular networks as a communications medium. Building communicating
devices that employ these networks is obviously well known, but this devices that employ these networks is obviously well known, but this
memo focuses specifically on techniques necessary to minimize power memo focuses specifically on techniques necessary to minimize power
consumption.</t> consumption.</t>
</abstract>
</abstract> </front>
<middle>
</front> <section anchor="intro" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>This memo discusses the use of the Constrained Application Protocol
<section anchor="intro" title="Introduction"> (CoAP) <xref target="RFC7252" format="default"/> in building
<t>This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol <xref target="RFC7252"/> in building
sensors and other devices that employ cellular networks as a sensors and other devices that employ cellular networks as a
communications medium. Building communicating devices that employ communications medium. Building communicating devices that employ
these networks is obviously well known, but this memo focuses these networks is obviously well known, but this memo focuses
specifically on techniques necessary to minimize power consumption. specifically on techniques necessary to minimize power consumption.
CoAP has many advantages, including being simple to implement; a CoAP has many advantages, including being simple to implement; a
thousand lines for the entire software above IP layer is plenty for a thousand lines of code for the entire application above the IP layer is plenty f or a
CoAP-based sensor, for instance. However, while many of these CoAP-based sensor, for instance. However, while many of these
advantages are obvious and easily obtained, optimizing power advantages are obvious and easily obtained, optimizing power
consumption remains challenging and requires careful design <xref consumption remains challenging and requires careful design <xref target="I-D.ar
target="I-D.arkko-core-sleepy-sensors"/>.</t> kko-core-sleepy-sensors" format="default"/>.</t>
<t>This memo primarily targets 3GPP cellular networks in their 2G, 3G,
<t>The memo targets primarily 3GPP cellular networks in their 2G, 3G, LTE, and 5G variants and their future enhancements, including possible
and LTE variants and their future enhancements, including possible
power efficiency improvements at the radio and link layers. The exact power efficiency improvements at the radio and link layers. The exact
standards or details of the link layer or radios are not relevant for standards or details of the link layer or radios are not relevant for
our purposes, however. To be more precise, the material in this memo our purposes, however. To be more precise, the material in this memo
is suitable for any large-scale, public network that employs is suitable for any large-scale, public network that employs a
point-to-point communications model and radio technology for the point-to-point communications model and radio technology for the
devices in the network.</t> devices in the network.</t>
<t>Our focus is on devices that need to be optimized for power usage and
<t>Our focus is devices that need to be optimized for power usage, and devices that employ CoAP. As a general technology, CoAP is similar
on devices that employ CoAP. As a general technology, CoAP is similar to HTTP. It can be used in various ways, and network entities may take
to HTTP. It can be used in various ways and network entities may take
on different roles. This freedom allows the technology to be used in on different roles. This freedom allows the technology to be used in
efficient and less efficient ways. Some guidance is needed to efficient and less efficient ways. Some guidance is needed to
understand what communication models over CoAP are recommended when understand what types of communication over CoAP are recommended when
low power usage is a critical goal.</t> low power usage is a critical goal.</t>
<t>The recommendations in this memo should be taken as complementary
<t>The recommendations in this memo should be taken as complementary
to device hardware optimization, microelectronics improvements, and to 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 possible the IP, transport, and application layers to provide the best possible
power efficiency. Application implementors generally have to use the power efficiency. Application implementors generally have to use the
current generation microelectronics, currently available radio current-generation microelectronics, currently available radio
networks and standards, and so on. This focus in our memo should by no networks and standards, and so on. This focus in our memo should by no
means be taken as an indication that further evolution in these other means be taken as an indication that further evolution in these other
areas is unnecessary. Such evolution is useful, is ongoing, and is areas is unnecessary. Such evolution is useful, ongoing, and
generally complementary to the techniques presented in this memo. The generally complementary to the techniques presented in this memo.
evolution of underlying technologies may change what techniques However, the list of techniques described in this document as useful for a
described here are useful for a particular application, however.</t> particular application may change with the evolution of these underlying
technologies.</t>
<t>The rest of this memo is structured as follows. <xref <t>The rest of this memo is structured as follows. <xref target="lowpow" f
target="lowpow"/> discusses the need and goals for low-power ormat="default"/> discusses the need and goals for low-power
devices. <xref target="model"/> outlines our expectations for the low devices. <xref target="model" format="default"/> outlines our expectations for t
layer communications model. <xref target="scen"/> describes the two he low-layer communications model. <xref target="scen" format="default"/> descri
scenarios that we address, and <xref target="disc"/>, <xref bes the two
target="data"/>, <xref target="rt"/> and <xref target="sens"/> give scenarios that we address. Sections&nbsp;<xref target="disc" format="counter"/>,
guidelines for use of CoAP in these scenarios.</t> <xref target="data" format="counter"/>, <xref target="rt" format="counter"/>, a
nd <xref target="sens" format="counter"/> give
</section> guidelines for the use of CoAP in these scenarios.</t>
<t>This document was originally finalized in 2016 but is published six years lat
<section anchor="lowpow" title="Goals for Low-Power Operation"> er 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 d
<t>There are many situations where power usage optimization is iscussed here, and some of the references point to documents that were state of
the art in 2016.</t>
</section>
<section anchor="lowpow" numbered="true" toc="default">
<name>Goals for Low-Power Operation</name>
<t>There are many situations where power usage optimization is
unnecessary. Optimization may not be necessary on devices that can run unnecessary. Optimization may not be necessary on devices that can run
on power feed over wired communications media, such as in on a power feed over wired communications media, such as in
Power-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 For instance, some environmental sensors can run on solar
cells. Typically, these devices still have to regulate their power cells. Typically, these devices still have to regulate their power
usage in a strict manner, for instance to be able to use as small and usage in a strict manner -- for instance, to be able to use solar cells that
inexpensive solar cells as possible.</t> are as small and inexpensive as possible.</t>
<t>In battery-operated devices, power usage is even more
<t>In battery operated devices the power usage is even more
important. For instance, one of the authors employs over a hundred different important. For instance, one of the authors employs over a hundred different
sensor devices in his home network. A majority of these devices are sensor devices in their home network. A majority of these devices are
wired and run on PoE, but in most environments this would be wired and run on PoE, but in most environments this would be
impractical because the necessary wires do not exist. The future is in impractical because the necessary wires do not exist. The future is in
wireless solutions that can cover buildings and other environments wireless solutions that can cover buildings and other environments
without assuming a pre-existing wired infrastructure. In addition, in without assuming a pre-existing wired infrastructure. In addition, in
many cases it is impractical to provide a mains power source. Often many cases it is impractical to provide a mains power source. Often,
there are no power sockets easily available in the locations that the there are no power sockets easily available in the locations that the
devices need to be in, and even if there were, setting up the wires devices need to be in, and even if there were, setting up the wires
and power adapters would be more complicated than installing a and power adapters would be more complicated than installing a
standalone device without any wires.</t> standalone device without any wires.</t>
<t>Yet, with a large number of devices, the battery lifetimes become
<t>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 hundred largely just bought and left on their own. For instance, with a hundred
devices, even a ten-year battery lifetime results in a monthly battery devices, even a ten-year battery lifetime results in a monthly battery
change for one device within the network. This may be impractical in change for one device within the network. This may be impractical in
many environments. In addition, some devices may be physically many environments. In addition, some devices may be physically
difficult to reach for a battery change. Or, a large group of devices difficult to reach for a battery change. Or, a large group of devices
-- such as utility meters or environmental sensors -- cannot be -- such as utility meters or environmental sensors -- cannot be
economically serviced too often, even if in theory the batteries could economically serviced too often, even if in theory the batteries could
be changed. </t> be changed. </t>
<t>Many of these situations lead to a requirement for minimizing power
<t>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 <xref target="RFC7228"/>, mains-powered strategies described in <xref target="RFC7228" format="default"/>, mains-powered
sensor-type devices can use the Always-on strategy whereas battery or sensor-type devices can use the Always-on strategy, whereas battery-operated or
energy harvesting devices need to adjust behavior based on the energy-harvesting devices need to adjust behavior based on the
communication interval. For intervals in the order of seconds, communication interval. For intervals on the order of seconds, the
Low-power strategy is appropriate. For intervals ranging from minutes Low-power strategy is appropriate. For intervals ranging from minutes
to hours either Low-power or Normally-off strategies are to hours, either the Low-power or Normally-off strategy is
suitable. Finally, for intervals lasting days and longer, Normally-off suitable. Finally, for intervals lasting days or longer, Normally-off
is usually the best choice. Unfortunately, much of our current is usually the best choice. Unfortunately, much of our current technology has be
technology has been built with different objectives in mind. Networked en built with different objectives in mind -- for instance, networked devices th
devices that are "always on", gadgets that require humans to recharge at are "always on", gadgets that require humans to recharge them every couple of
them every couple of days, and protocols that have been optimized to days, and protocols that have been optimized to maximize throughput rather than
maximize throughput rather than conserve resources.</t> conserve
resources.</t>
<t>Long battery lifetimes are required for many applications, <t>Long battery lifetimes are required for many applications,
however. In some cases these lifetimes should be in the order of years however. In some cases, these lifetimes should be on the order of years
or even a decade or longer. Some communication devices already reach or even a decade or longer. Some communication devices already reach
multi-year lifetimes, and continuous improvement in low-power multi-year lifetimes, and continuous improvements in low-power
electronics and advances in radio technology keep pushing these electronics and advances in radio technology keep pushing these
lifetimes longer. However, it is perhaps fair to say that battery lifetimes longer. However, it is perhaps fair to say that battery
lifetimes are generally too short at present time.</t> lifetimes are generally too short at present.</t>
<t>Power usage cannot be evaluated based solely on lower-layer
<t>Power usage can not be evaluated solely based on lower layer communications. The entire system, including upper-layer protocols and
communications. The entire system, including upper layer protocols and applications, is responsible for the power consumption as a whole. The
applications is responsible for the power consumption as a whole. The
lower communication layers have already adopted many techniques that lower communication layers have already adopted many techniques that
can be used to reduce power usage, such as scheduling device wake-up can be used to reduce power usage, such as scheduling device wake-up
times. Further reductions will likely need some co-operation from the times. Further reductions will likely need some cooperation from the
upper layers so that unnecessary communications, denial-of-service upper layers so that unnecessary communications, denial-of-service
attacks on power consumption, and other power drains are attacks on power consumption, and other power drains are
eliminated.</t> eliminated.</t>
<t>Of course, application requirements ultimately determine what kinds
<t>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 application, guidelines in this memo is not to prefer one or the other application,
but to provide guidance on how to minimize the amount of 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 only relatively speaking, most noticeable in applications that transfer only
a small amount of data, or operate only infrequently.</t> a small amount of data or operate only infrequently.</t>
</section>
</section> <section anchor="model" numbered="true" toc="default">
<name>Link-Layer Assumptions</name>
<section anchor="model" title="Link-Layer Assumptions"> <t>We assume that the underlying communications network can be any
large-scale, public network that employs a point-to-point communications
<t>We assume that the underlying communications network can be any model and radio technology. &nbsp;2G, 3G, LTE, and 5G networks are examples of s
large-scale, public network that employs point-to-point communications uch
model and radio technology. 2G, 3G, and LTE networks are examples of such networks but are not the only possible networks with these characteristics.</t>
networks, but not the only possible networks with these characteristics.</t> <t>In the following, we look at some of these characteristics and their
<t>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 concept properties of the specific networks but rather are inherent in the concept
of public networks. of public networks.
</t>
<list style="hanging"> <ul spacing="normal">
<li>
<t hangText="Public networks"><vspace blankLines="1"/> <t>Public Networks</t>
<t>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 companies) economic reasons, only the largest users (such as utility companies)
could afford to build their own network, and even they would not be could afford to build their own network, and even they would not be
able to provide a world-wide coverage. This means that applications able to provide worldwide coverage. This means that applications
where coverage is important can be built. For instance, most transport where coverage is important can be built. For instance, most
sector applications require national or even world-wide coverage to transport-sector applications require national or even worldwide coverage to
work. work.</t>
<t>But there are other implications as well. By definition, the networ
<vspace blankLines="1"/> k
But there are other implications, as well. By definition, the network is not tailored for this application, and, with some exceptions, the
is not tailored for this application and with some exceptions, the
traffic passes through the Internet. One implication of this is that traffic passes through the Internet. One implication of this is that
there are generally no application-specific network configurations or there are generally no application-specific network configurations or
discovery support. For instance, the public network helps devices to discovery support. For instance, the public network helps devices to
get on the Internet, set up default routers, configure DNS servers, get on the Internet, set up default routers, configure DNS servers,
and so on, but does nothing for configuring possible higher-layer and so on, but does nothing for configuring possible higher-layer
functions, such as servers the device might need to contact to perform functions, such as servers that a device might need to contact to perform
its application functions. its application functions.
</t>
<vspace blankLines="1"/> <t>Public networks often provide web proxies and other functionality t
Public networks often provide web proxies and other functionality that hat
can in some cases make a significant improvement for delays and cost can, in some cases, make significant improvements related to delays and costs
of communication over the wireless link. For instance, resolving of communication over the wireless link. For instance, resolving
server DNS names in a proxy instead of the user's device may cut down server DNS names in a proxy instead of the user's device may cut down
on the general chattiness of the communications, therefore reducing on the general chattiness of the communications, therefore reducing
overall delay in completing the entire transaction. Likewise, a CoAP overall delay in completing the entire transaction. Likewise, a CoAP
proxy or pub/sub broker <xref target="I-D.koster-core-coap-pubsub"/> proxy or Publish-Subscribe (pub&wj;/sub) Broker <xref target="I-D.ietf-core-coap -pubsub" format="default"/>
can assist a CoAP device in communication. However, unlike HTTP web can assist a CoAP device in communication. However, unlike HTTP web
proxies, CoAP proxies and brokers are not yet widely deployed in proxies, CoAP proxies and brokers are not yet widely deployed in
public networks. public networks.</t>
<t>Similarly, given the lack of available IPv4 addresses, chances are
<vspace blankLines="1"/> that many devices are behind a Network Address Translation (NAT)
Similarly, given the lack of available IPv4 addresses, the chances are
that many devices are behind a network address translation (NAT)
device. This means that they are not easily reachable as servers. device. This means that they are not easily reachable as servers.
Alternatively, the devices may be directly on the global Internet Alternatively, the devices may be directly on the global Internet
(either on IPv4 or IPv6) and easily reachable as (on either IPv4 or IPv6) and easily reachable as
servers. Unfortunately, this may mean that they also receive unwanted servers. Unfortunately, this may mean that they also receive unwanted
traffic, which may have implications for both power consumption and traffic, which may have implications for both power consumption and
service costs.</t> service costs.</t>
</li>
<t hangText="Point-to-point link model"><vspace blankLines="1"/> <li><t>Point-to-Point Link Model</t>
<t>This is a common link model in cellular networks. One implication of
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 link, this model is that there will be no other nodes on the same link,
except maybe for the service provider's router. As a result, multicast except maybe for the service provider's router. As a result, multicast
discovery can not be reasonably used for any local discovery purposes. discovery cannot be reasonably used for any local discovery purposes.
While the configuration of the service provider's router for specific While the configuration of the service provider's router for specific
users is theoretically possible, in practice this is difficult to users is theoretically possible, this is difficult to
achieve, at least for any small user that can not afford a achieve in practice, at least for any small user that cannot afford a
network-wide contract for a private APN (Access Point Name). The network-wide contract for a private APN (Access Point Name). The
public network access service has little per-user tailoring.</t> public network access service has little per-user tailoring.</t>
</li>
<t hangText="Radio technology"><vspace blankLines="1"/> <li>
<t>Radio Technology</t>
The use of radio technology means that power is needed to operate the <t>The use of radio technology means that power is needed to operate the
radios. Transmission generally requires more power radios. Transmission generally requires more power
than reception. However, radio protocols have generally been designed than reception. However, radio protocols have generally been designed
so that a device checks periodically whether it has messages. In a so that a device checks periodically to see whether it has messages. In a
situation where messages arrive seldom or not at all, this checking situation where messages arrive seldom or not at all, this checking
consumes energy. Research has shown that these periodic checks (such consumes energy. Research has shown that these periodic checks (such
as LTE paging message reception) are often a far bigger contributor to as LTE paging message reception) are often a far bigger contributor to
energy consumption than message transmission. energy consumption than message transmission.</t>
<t>Note that for situations where there are several applications on the
<vspace blankLines="1"/>
Note that for situations where there are several applications on the
same device wishing to communicate with the Internet in some manner, same device wishing to communicate with the Internet in some manner,
bundling those applications together so that they can communicate at bundling those applications together so that they can communicate at
the same time can be very useful. Some guidance for these techniques the same time can be very useful. Some guidance for these techniques
in the smartphone context can be found in <xref in the smartphone context can be found in <xref target="Android-Bundle" format="
target="Android-Bundle"/>. default"/>.</t>
</t> </li>
</ul>
</list>
</t>
<t>Naturally, each device has a freedom to decide when it sends <t>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 often come in two variants: (1)&nbsp;fine-grained mechanisms that deal with how often
the device needs to wake-up for paging messages, and more crude the device needs to wake up for paging messages and (2)&nbsp;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) <xref target="RFC4838"/> mechanisms to relax the Networking (DTN) mechanisms <xref target="RFC4838" format="default"/> to relax t he
requirements for timeliness of connectivity and message delivery. </t> requirements for timeliness of connectivity and message delivery. </t>
</section>
</section> <section anchor="scen" numbered="true" toc="default">
<name>Scenarios</name>
<section anchor="scen" title="Scenarios"> <t>Not all applications or situations are equal. They may require
<t>Not all applications or situations are equal. They may require
different solutions or communication models. This memo focuses on two different solutions or communication models. This memo focuses on two
common scenarios at cellular networks: common scenarios in cellular networks:
</t>
<list style="hanging">
<t hangText="Real-Time Reachable Devices"><vspace blankLines="1"/>
This scenario involves all communication that requires real-time or <ul spacing="normal">
near real-time communications with a device. That is, a network entity <li>
<t>Real-Time Reachable Devices</t>
<t>This scenario involves all communication that requires real-time or
near-real-time communications with a device. That is, a network entity
must be able to reach the device with a small time lag at any time, must be able to reach the device with a small time lag at any time,
and no pre-agreed wake-up schedule can be arranged. By "real-time" we and no previously agreed-upon wake-up schedule can be arranged. By "real-time", we
mean any reasonable end-to-end communications latency, be it measured mean any reasonable end-to-end communications latency, be it measured
in milliseconds or seconds. However, unpredictable sleep states are in milliseconds or seconds. However, unpredictable sleep states are
not expected. not expected.</t>
<t>Examples of devices in this category include sensors that must be measurable
<vspace blankLines="1"/>
Examples of devices in this category include sensors that must be measurable
from a remote source at any instant in time, such as process automation sensors from a remote source at any instant in time, such as process automation sensors
and actuators that require immediate action, such as light bulbs or door locks. and actuators that require immediate action, such as light bulbs or door locks.<
</t> /t>
</li>
<t hangText="Sleepy Devices"><vspace blankLines="1"/> <li>
This scenario involves freedom to choose when device communicates. The <t>Sleepy Devices</t>
<t>This scenario involves the freedom to choose when a device communicates. The
device is often expected to be able to be in a sleep state for much of device is often expected to be able to be in a sleep state for much of
its time. The device itself can choose when it communicates, or it lets its time. The device itself can choose when it communicates, or it lets
the network assist in this task. the network assist in this task.</t>
<t>Examples of devices in this category include sensors that track slowly
<vspace blankLines="1"/>
Examples of devices in this category include sensors that track slowly
changing values, such as temperature sensors and actuators that changing values, such as temperature sensors and actuators that
control a relatively slow process, such as heating systems. control a relatively slow process, such as heating systems.</t>
<t>Note that there may be hard real-time requirements, but they are
<vspace blankLines="1"/> expressed in terms of how fast the device can communicate -- not in
Note that there may be hard real-time requirements, but they are terms of how fast it can respond to network stimuli. For instance,
expressed in terms of how fast the device can communicate, not in
terms of how fast it can respond to a network stimuli. For instance,
a fire detector can be classified as a sleepy device as long as it a fire detector can be classified as a sleepy device as long as it
can internally quickly wake up on detecting fire and initiate the necessary can internally quickly wake up on detecting fire and initiate the necessary
communications without delay.</t> communications without delay.</t>
</li>
</list> </ul>
</t> </section>
<section anchor="disc" numbered="true" toc="default">
</section> <name>Discovery and Registration</name>
<t>In both scenarios, the device will be attached to a public network.
<section anchor="disc" title="Discovery and Registration">
<t>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 public nodes cannot practically discover individual devices in a large public
network. And the devices can not discover who they need to talk, as network. And the devices cannot discover who they need to talk to, as
the public network offers just basic Internet connectivity.</t> the public network offers just basic Internet connectivity.</t>
<t>Our recommendation is to initiate a discovery and registration
<t>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. </t> requirements to another node.</t>
<t>The registration part is easy, e.g., with a resource directory. The
<t>The registration part is easy e.g., with a resource directory. The device should perform the necessary registration with such a resource directory
device should perform the necessary registration with these devices, --
for instance, as specified in <xref for instance, as specified in <xref target="RFC9176" format="default"/>. In orde
target="I-D.ietf-core-resource-directory"/>. In order to do this r to do this
registration, the device needs to know its CoRE Link Format registration, the device needs to know its Constrained RESTful Environments (CoR
description, as specified in <xref target="RFC6690"/>. In essence, the E) Link Format
description, as specified in <xref target="RFC6690" format="default"/>. In essen
ce, the
registration process involves performing a GET on registration process involves performing a GET on
.well-known/core/?rt=core-rd at the address of the resource directory, .well-known/core/?rt=core-rd at the address of the resource directory
and then doing a POST on the path of the discovered resource.</t> and then doing a POST on the path of the discovered resource.</t>
<t>Other mechanisms enabling device discovery and delegation of
<t>Other mechanisms enabling device discovery and delegation of functionality to a non-sleepy node include those discussed in <xref target="I-D.
functionality to a non-sleepy node include <xref vial-core-mirror-proxy" format="default"/> and <xref target="I-D.ietf-core-coap-
target="I-D.vial-core-mirror-proxy"/> and <xref pubsub" format="default"/>.</t>
target="I-D.koster-core-coap-pubsub"/>.</t> <t>However, current CoAP specifications provide only limited support
<t>However, current CoAP specifications provide only limited support
for discovering the resource directory or other registration for discovering the resource directory or other registration
services. Local multicast discovery only works in LAN-type networks, services. Local multicast discovery only works in LAN-type networks; it does
but not in these public cellular networks. Our recommended alternate not work in the public cellular networks discussed in this document. We recommen
methods for discovery are the following: d the following alternate methods for discovery:</t>
<list style="hanging">
<t hangText="Manual Configuration"><vspace blankLines="1"/> <ul spacing="normal">
<li>
<t>Manual Configuration</t>
The DNS name of the resource directory is manually configured. This <t>The DNS name of the resource directory is manually configured. This
approach is suitable in situations where the owner of the devices has approach is suitable in situations where the owner of the devices has
the resources and capabilities to do the configuration. For instance, the resources and capabilities to do the configuration. For instance,
a utility company can typically program its metering devices to point a utility company can typically program its metering devices to point
to the company servers.</t> to the company servers.</t>
</li>
<t hangText="Manufacturer Server"><vspace blankLines="1"/> <li>
<t>Manufacturer Server</t>
The DNS name of the directory or proxy is hardwired to the software by <t>The DNS name of the directory or proxy is hardwired to the
the manufacturer, and the directory or proxy is actually run by the software by the manufacturer, and the directory or proxy is actually ru
n by the
manufacturer. This approach is suitable in many consumer usage manufacturer. This approach is suitable in many consumer usage
scenarios, where it would be unreasonable to assume that the consumer scenarios, where it would be unreasonable to assume that the consumer
runs any specific network services. The manufacturer's web interface runs any specific network services. The manufacturer's web interface
and the directory/proxy servers can co-operate to provide the desired and the directory/proxy servers can cooperate to provide the desired
functionality to the end user. For instance, the end user can register functionality to the end user. For instance, the end user can register
a device identity in the manufacturer's web interface and ask specific a device identity in the manufacturer's web interface and ask that specific
actions to be taken when the device does something. actions be taken when the device does something.</t>
</li>
</t>
<t hangText="Delegating Manufacturer Server"><vspace blankLines="1"/>
The DNS name of the directory or proxy is hardwired to the software by <li>
<t>Delegating Manufacturer Server</t>
<t>The DNS name of the directory or proxy is hardwired to the software by
the manufacturer, but this directory or proxy merely redirects the the manufacturer, but this directory or proxy merely redirects the
request to a directory or proxy run by the whoever bought the request to a directory or proxy run by whoever bought the
device. This approach is suitable in many enterprise environments, as device. This approach is suitable in many enterprise environments, as
it allows the enterprise to be in charge of actual data collection and it allows the enterprise to be in charge of actual data collection and
device registries; only the initial bootstrap goes through the device registries; only the initial bootstrap goes through the
manufacturer. In many cases there are even legal requirements (such as manufacturer. In many cases, there are even legal requirements (such as
EU privacy laws) that prevent providing unnecessary information to EU privacy laws) that prevent providing unnecessary information to
third parties. third parties.</t>
</t> </li>
<t hangText="Common Global Resolution Infrastructure"><vspace blankLines="1"/>
The delegating manufacturer server model could be generalized into a
reverse-DNS -like discovery infrastructure that could answer the question
"this is device with identity ID, where is my home registration server?".
However, at present no such resolution system exists.
(Note: The EPCGlobal system for RFID resolution is reminiscent
of this approach.)
</t>
</list> <li>
</t> <t>Common Global Resolution Infrastructure</t>
<t> <t>The delegating manufacturer server model could be generalized into
Besides manual configuration, these alternate mechanisms are mostly a reverse-DNS-like discovery infrastructure that could, for example, answer the
question "This is a device with identity ID 2456; where is my home registration
server?" However, at present, no such resolution system exists.
(Note: The EPCGlobal system for Radio Frequency Identification (RFID) resolution
is reminiscent
of this approach.)</t>
</li>
</ul>
<t>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 deployed
in small quantities are still needed. in small quantities are still needed.</t>
</t> </section>
<section anchor="data" numbered="true" toc="default">
</section> <name>Data Formats</name>
<t>A variety of data formats exist for passing around data. These data
<section anchor="data" title="Data Formats"> formats include XML, JavaScript Object Notation (JSON) <xref target="RFC8259"
format="default"/>, Efficient XML Interchange (EXI) <xref
<t>A variety of data formats exist for passing around data. These data target="W3C.REC-exi-20140211" format="default"/>, Concise Binary Object Represen
formats include XML, JavaScript Object Notation (JSON) <xref tation (CBOR) <xref target="RFC8949"/>, and various text formats. Message length
target="RFC7159"/>, Efficient XML Interchange (EXI) <xref s can
target="W3C.REC-exi-20110310"/>, and text formats. Message lengths can
have a significant effect on the amount of energy required for the have a significant effect on the amount of energy required for the
communications, and such it is highly desirable to keep message communications, and as such it is highly desirable to keep message
lengths minimal. At the same time, extreme optimization can affect lengths minimal. At the same time, extreme optimization can affect
flexibility and ease of programming. The authors recommend <xref flexibility and ease of programming. The authors recommend that readers refer
target="I-D.jennings-core-senml"/> as a compact, yet easily processed to <xref target="RFC8428" format="default"/> for a compact but easily processed
and extendable textual format.</t> and extendable format.</t>
</section>
</section> <section anchor="rt" numbered="true" toc="default">
<name>Real-Time Reachable Devices</name>
<section anchor="rt" title="Real-Time Reachable Devices"> <t>These devices are often best modeled as CoAP servers. The device
will have limited control over when it receives messages, and it will
<t>These devices are often best modeled as CoAP servers. The device
will have limited control on 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 some underlying link layer. If in some phase of its operation the device also acts in
phase of its operation, it can control how many transmissions it makes the role of a client, it can control how many transmissions it makes
on its own behalf.</t> on its own behalf.</t>
<t>The packet reception checks should be tailored according to the
<t>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.</t> needed, a more infrequent checking process may save some power.</t>
<t>For sensor-type devices, the CoAP Observe extension (Observe option) <x
<t>For sensor-type devices, the CoAP Observe extension <xref ref target="RFC7641" format="default"/> may be supported. This allows the sensor
target="RFC7641"/> may be supported. This allows the sensor to track to track
changes to the sensed value, and make an immediate observation changes to the sensed value and make an immediate observation
response upon a change. This may reduce the amount of polling needed response upon a change. This may reduce the amount of polling needed
to be done by the client. Unfortunately, it does not reduce the time to be done by the client. Unfortunately, it does not reduce the time
that the device needs to be listening for requests. Subscription that the device needs to be listening for requests. Subscription
requests from other clients than the currently registered one may come requests from clients other than the currently registered client may come
at any time, the current client may change its request, and the device in at any time, the current client may change its request, and the device
still needs to respond to normal queries as a server. As a result, the still needs to respond to normal queries as a server. As a result, the
sensor can not rely having to communicate only on its own choice of sensor cannot rely on having to communicate only on its own choice of
observation interval.</t> observation interval.</t>
<t>In order to act as a server, the device needs to be placed in a
<t>In order to act as a server, the device needs to be placed in a public IPv4 address, be reachable over IPv6, or be hosted in a private
public IPv4 address, be reachable over IPv6, or hosted in a private network. If the device is hosted on a private network, then all
network. If the the device is hosted on a private network, then all other nodes that need to access this device also need to reside in the same
other nodes need to access this device also need to reside in the same
private network. There are multiple ways to provide private networks private network. There are multiple ways to provide private networks
over public cellular networks. One approach is to dedicate a special over public cellular networks. One approach is to dedicate a special
APN for the private network. Corporate access via cellular networks APN for the private network. Corporate access via cellular networks
has often been arranged in this manner, for instance. Another approach has often been arranged in this manner, for instance. Another approach
is to use Virtual Private Networking (VPN) technology, for instance is to use Virtual Private Network (VPN) technology -- for instance,
IPsec-based VPNs.</t> IPsec-based VPNs.</t>
<t>Power consumption from unwanted traffic is problematic in these
<t>Power consumption from unwanted traffic is problematic in these devices, unless they are placed in a private network or protected by an
devices, unless placed in a private network or protected by a
operator-provided firewall service. Devices on an IPv6 network will operator-provided firewall service. Devices on an IPv6 network will
have some protection through the nature of the 2^64 address allocation be afforded some protection due to the nature of the 2<sup>64</sup> address allo cation
for a single terminal in a 3GPP cellular network; the attackers will for a single terminal in a 3GPP cellular network; the attackers will
be unable to guess the full IP address of the device. However, this be unable to guess the full IP address of the device. However, this
protects only the device from processing a packet, but since the protects only the device from processing a packet, but since the
network will still deliver the packet to any of the addresses within network will still deliver the packet to any of the addresses within
the assigned 64-bit prefix, packet reception costs are still the assigned 64-bit prefix, packet reception costs are still
incurred.</t> incurred.</t>
<t>Note that the VPN approach cannot prevent unwanted traffic
<t>Note that the the VPN approach can not prevent unwanted traffic received at the tunnel endpoint address and may require keep-alive
received at the tunnel endpoint address, and may require keep-alive traffic. Special APNs can solve this issue but require an explicit
traffic. Special APNs can solve this issue, but require explicit
arrangement with the service provider.</t> arrangement with the service provider.</t>
</section>
</section> <section anchor="sens" numbered="true" toc="default">
<name>Sleepy Devices</name>
<section anchor="sens" title="Sleepy Devices"> <t>These devices are best modeled as devices that can delegate queries
to some other node -- for instance, as mirror servers <xref
<t>These devices are best modeled as devices that can delegate queries target="I-D.vial-core-mirror-proxy" format="default"/> or CoAP
to some other node. For instance, as mirror proxy <xref pub&wj;/sub Clients <xref target="I-D.ietf-core-coap-pubsub"
target="I-D.vial-core-mirror-proxy"/> or CoAP Publish-Subscribe <xref format="default"/>. When the device initializes
target="I-D.koster-core-coap-pubsub"/> clients. When the device initializes itself, it makes a registration of itself in a server or broker as described
itself, it makes a registration of itself in a proxy as described above in <xref target="disc" format="default"/> and then continues to send perio
above in <xref target="disc"/> and then continues to send periodic dic
updates of sensor values.</t> updates of sensor values.</t>
<t>As a result, the device acts only as a client and not as a server, and
<t>As a result, the device acts only as a client, not a server, and can shut down all communication channels during its
can shut down all communication channels while it is during its
sleeping period. The length of the sleeping period depends on power sleeping period. The length of the sleeping period depends on power
and application requirements. Some environmental sensors might use a and application requirements. Some environmental sensors might use a
day or a week as the period, while other devices may use a smaller day or a week as the period, while other devices may use smaller
values ranging from minutes to hours.</t> values ranging from minutes to hours.</t>
<t>The ability to shut down communications and act as only a client
<t>Other approaches for delegation include CoAP-options described in has four impacts:</t>
<xref target="I-D.castellani-core-alive"/> <xref <ul spacing="normal">
target="I-D.fossati-core-publish-monitor-options"/>. In this memo we <li>Radio transmission and reception can be turned off during the
use mirror proxies as an example, because of their ability to work sleeping period, reducing power consumption significantly.</li>
with both HTTP and CoAP implementations; but the concepts are similar <li>However, some power and time are consumed by having to reattach to
and the IETF work is still in progress so the final protocol details the network after the end of a sleep period.</li>
are yet to be decided.</t> <li>The window of opportunity for unwanted traffic to arrive is much
<t>The ability to shut down communications and act as only a client
has four impacts:
<list style="symbols">
<t>Radio transmission and reception can be turned off during the
sleeping period, reducing power consumption significantly.</t>
<t>However, some power and time is consumed by having to re-attach to
the network after the end of a sleep period.</t>
<t>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. On time. Note, however, that networks may cache packets for some time. On
the other hand, stateful firewalls can effectively remove much of the other hand, stateful firewalls can effectively remove much of the
unwanted traffic for client type devices.</t> unwanted traffic for client-type devices.</li>
<li>The device may exist behind a NAT or a firewall without being
<t>The device may exist behind a NAT or a firewall without being impacted. Note that the "simple security" basic IPv6 firewall capability
impacted. Note that "Simple Security" basic IPv6 firewall capability <xref target="RFC6092" format="default"/> blocks inbound UDP traffic by default,
<xref target="RFC6092"/> blocks inbound UDP traffic by default, so just so just
moving to IPv6 is not direct solution to this problem.</t> moving to IPv6 is not a direct solution to this problem.</li>
</ul>
</list> <t>For sleepy devices that represent actuators, it is also possible to
use the mirror server or pub/sub broker model. A device can receive information
</t> from the server or broker about variable changes via either polling or notificat
ions.</t>
<t>For sleepy devices that represent actuators, it is also possible to <section numbered="true" toc="default">
use the mirror proxy model. The device can make periodic polls to the <name>Implementation Considerations</name>
proxy to determine if a variable has changed.</t> <t>There are several challenges related to implementing sleepy devices.
They
<section title="Implementation Considerations"> need hardware that can be placed in an appropriate sleep mode but
<t>There are several challenges in implementing sleepy devices. They
need hardware that can be put to an appropriate sleep mode but yet
awakened when it is time to do something again. This is not always awakened when it is time to do something again. This is not always
easy in all hardware platforms. It is important to be able to shut easy in all hardware platforms. It is important to be able to shut
down as much of the hardware as possible, preferably down to down as much of the hardware as possible, preferably down to
everything else except a clock circuit. The platform also needs to support everything else except a clock circuit. The platform also needs to support
re-awakening at suitable time scales, as otherwise the device needs to be reawakening at suitable timescales, as otherwise the device needs to be
powered up too frequently.</t> powered up too frequently.</t>
<t>Most commercial cellular modem platforms do not allow applications
<t>Most commercial cellular modem platforms do not allow applications
to suspend the state of the communications stack. Hence, after a to suspend the state of the communications stack. Hence, after a
power-off period they need to re-establish communications, which takes power-off period, they need to re-establish communications, which takes
some amount of time and extra energy.</t> some amount of time and extra energy.</t>
<t>Implementations should have a coordinated understanding of the
<t>Implementations should have a coordinated understanding of the
state and sleeping schedule. For instance, it makes no sense to keep a state and sleeping schedule. For instance, it makes no sense to keep a
CPU powered up, waiting for a message when the lower layer has been CPU powered up, waiting for a message when the lower layer has been
told that the next possible paging opportunity is some time away.</t> told that the next possible paging opportunity is some time away.</t>
<t>The cellular networks have a number of adjustable configuration
<t>The cellular networks have a number of adjustable configuration parameters, such as the maximum used paging interval. Proper settings
parameters, such as the maximum used paging interval. Proper setting of these values have an impact on the power consumption of the device,
of these values has an impact on the power consumption of the device, but with current business practices, such settings are rarely
but with the current business practices, such settings are rarely
negotiated when the user's subscription is provisioned.</t> negotiated when the user's subscription is provisioned.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>There are no particular security aspects related to what has been
<section title="Security Considerations">
<t>There are no particular security aspects with what has been
discussed in this memo, except for the ability to delegate queries for discussed in this memo, except for the ability to delegate queries for
a resource to another node. Depending on how this is done, there are a resource to another node. Depending on how this is done, there are
obvious security issues which have largely NOT yet been addressed in obvious security issues that have largely NOT yet been addressed in
the relevant Internet Drafts <xref the relevant Internet-Drafts <xref target="I-D.vial-core-mirror-proxy" format="d
target="I-D.vial-core-mirror-proxy"/> efault"/>
<xref target="I-D.castellani-core-alive"/> <xref target="I-D.castellani-core-alive" format="default"/>
<xref target="I-D.fossati-core-publish-monitor-options"/>. However, <xref target="I-D.fossati-core-publish-monitor-options" format="default"
we point out that in general, security issues in delegation can be />. However,
solved either through reliance on your local network support nodes we point out that, in general, security issues in delegation can be
solved through either reliance on your local network support nodes
(which may be quite reasonable in many environments) or explicit (which may be quite reasonable in many environments) or explicit
end-to-end security. Explicit end-to-end security through nodes that end-to-end security. Explicit end-to-end security through nodes that
are awake at different times means in practice end-to-end data object are awake at different times means, in practice, end-to-end data object
security. We have implemented one such mechanism for sleepy nodes as security. We have implemented one such mechanism for sleepy nodes as
described in <xref described in <xref target="RFC8387" format="default"/>.</t>
target="I-D.aks-lwig-crypto-sensors"/>.</t> <t>The security considerations relating to CoAP <xref target="RFC7252" for
mat="default"/> and the relevant link layers should
<t>The security considerations relating to CoAP <xref
target="RFC7252"/> and the relevant link layers should
apply. Note that cellular networks universally employ per-device apply. Note that cellular networks universally employ per-device
authentication, integrity protection, and for most of the world, authentication, integrity protection, and, for most of the world,
encryption of all their communications. Additional protection of encryption of all their communications. Additional protection of
transport sessions is possible through mechanisms described in <xref transport sessions is possible through mechanisms described in <xref target="RFC
target="RFC7252"/> or data objects.</t> 7252" format="default"/> or data objects.</t>
</section>
</section> <section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<section anchor="iana" title="IANA Considerations"> <displayreference target="I-D.arkko-core-sleepy-sensors" to="Tiny-CoAP"/>
<displayreference target="I-D.castellani-core-alive" to="CoAP-Alive"/>
<displayreference target="I-D.fossati-core-publish-monitor-options" to="CoAP-Pub
l-Monitor"/>
<displayreference target="I-D.vial-core-mirror-proxy" to="CoRE-Mirror"/>
<displayreference target="I-D.ietf-core-coap-pubsub" to="CoAP-PubSub"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6690.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.
xml"/>
<t>There are no IANA impacts in this memo.</t> <!-- draft-ietf-core-resource-directory (RFC 9176 - published 2022-04-25) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9176.
xml"/>
</section> <reference anchor="W3C.REC-exi-20140211" target="https://www.w3.org/TR/e
xi/">
<front>
<title>Efficient XML Interchange (EXI) Format 1.0 (Second Edition)</
title>
<author initials="J" surname="Schneider">
<organization/>
</author>
<author initials="T" surname="Kamiya">
<organization/>
</author>
<author initials="D" surname="Peintner">
<organization/>
</author>
<author initials="R" surname="Kyusakov">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<refcontent>World Wide Web Consortium Recommendation REC-exi-20140211<
/refcontent>
</reference>
</middle> <!-- draft-jennings-core-senml (replaced by draft-ietf-core-senml, then
published as RFC 8428) -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.
xml"/>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7228.
xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4838.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6092.
xml"/>
<references title="Normative References"> <!-- draft-arkko-core-sleepy-sensors (Expired) -->
<?rfc include="reference.RFC.7159.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-arkko-core-slee
<?rfc include="reference.RFC.6690.xml"?> py-sensors.xml"/>
<?rfc include="reference.RFC.7252.xml"?>
<?rfc include="reference.RFC.7641.xml"?>
<?rfc include="reference.I-D.ietf-core-resource-directory.xml"?>
<reference anchor="W3C.REC-exi-20110310"> <!-- draft-aks-lwig-crypto-sensors (replaced by draft-ietf-lwig-crypto-sensors,
<front> then published as RFC 8387) -->
<title>Efficient XML Interchange (EXI) Format 1.0</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8387.
<author initials='T' surname='Kamiya'> xml"/>
<organization />
</author>
<author initials='J' surname='Schneider'>
<organization />
</author>
<date month='March' year='2011' />
</front>
<seriesInfo name='World Wide Web Consortium
Recommendation REC-exi-20110310' value='http://www.w3.org/TR/2011/
REC-exi-20110310' />
<format type='HTML' target='http://www.w3.org/TR/2011/REC-exi-20110310' /
>
</reference>
<?rfc include="reference.I-D.jennings-core-senml.xml"?> <!-- draft-castellani-core-alive (Expired)
<?rfc include="reference.RFC.7228.xml"?> Have to do "long way" to fix author initials -->
</references> <reference anchor="I-D.castellani-core-alive">
<front>
<title>CoAP Alive Message</title>
<author fullname="Angelo P. Castellani" surname="Castellani" initials="A">
</author>
<author fullname="Salvatore Loreto" surname="Loreto" initials="S">
</author>
<date month="March" day="29" year="2012" />
</front>
<seriesInfo name="Internet-Draft" value="draft-castellani-core-alive-00" />
</reference>
<references title="Informative References"> <!-- draft-fossati-core-publish-monitor-options (Expired) -->
<?rfc include="reference.RFC.4838.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-fossati-core-pu
<?rfc include="reference.RFC.6092.xml"?> blish-monitor-options.xml"/>
<?rfc include="reference.I-D.arkko-core-sleepy-sensors.xml"?>
<?rfc include="reference.I-D.aks-lwig-crypto-sensors.xml"?>
<?rfc include="reference.I-D.castellani-core-alive.xml"?>
<?rfc include="reference.I-D.fossati-core-publish-monitor-options.xml"?>
<?rfc include="reference.I-D.vial-core-mirror-proxy.xml"?>
<?rfc include="reference.I-D.koster-core-coap-pubsub.xml"?>
<reference anchor='Android-Bundle'>
<front>
<title>Optimizing Downloads for Efficient Network Access</title>
<author fullname='Developer.Android.Com'>
<organization />
</author>
<date month='February' year='2013' />
</front>
<seriesInfo name='Android developer note' value='http://developer.android
.com/training/efficient-downloads/efficient-network-access.html' />
<format type='HTML' target='http://developer.android.com/training/efficie
nt-downloads/efficient-network-access.html' />
</reference>
</references> <!-- draft-vial-core-mirror-proxy (Expired) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-vial-core-mirro
r-proxy.xml"/>
<section title="Acknowledgments"> <!-- draft-koster-core-coap-pubsub (replaced by draft-ietf-core-coap-pubsub;
Expired. Since it's a "replaced by," had to change
"I-D.koster-core-coap-pubsub" to "I-D.ietf-core-coap-pubsub" to get
<displayreference> to work) (I-D Exists) -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-core-coap-
pubsub.xml"/>
<t>The authors would like to thank Zach Shelby, Jan Holler, Salvatore <reference anchor="Android-Bundle"
Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim target="https://developer.android.com/training/efficient-downloads/efficient-net
Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran, work-access.html">
Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes <front>
Tschofenig, and Anna Larmo for interesting discussions in this problem <title>Optimize network access</title>
<author/>
<date month="May" year="2022"/>
</front>
<refcontent>Android developer note</refcontent>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Zach Shelby"/>,
<contact fullname="Jan Holler"/>, <contact fullname="Salvatore
Loreto"/>, <contact fullname="Matthew Vial"/>, <contact fullname="Thomas
Fossati"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Jan
Melen"/>, <contact fullname="Joachim Sachs"/>, <contact
fullname="Heidi-Maria Rissanen"/>, <contact fullname="Sebastien
Pierrel"/>, <contact fullname="Kumar Balachandran"/>, <contact
fullname="Muhammad Waqas Mir"/>, <contact fullname="Cullen Jennings"/>,
<contact fullname="Markus Isomaki"/>, <contact fullname="Hannes Tschofenig
"/>, and <contact fullname="Anna Larmo"/> for interesting discussions in this pr
oblem
space.</t> space.</t>
</section>
</section> </back>
</back>
</rfc> </rfc>
 End of changes. 122 change blocks. 
508 lines changed or deleted 511 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/