File: rfc9178.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2024 lines) | stat: -rw-r--r-- 85,602 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9178: Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks</title>
<meta content="Jari Arkko" name="author">
<meta content="Anders Eriksson" name="author">
<meta content="Ari Keränen" name="author">
<meta content="
       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
devices that employ these networks is obviously well known, but this
memo focuses specifically on techniques necessary to minimize power
consumption. 
    " name="description">
<meta content="xml2rfc 3.12.8" name="generator">
<meta content="CoAP" name="keyword">
<meta content="cellular networks" name="keyword">
<meta content="9178" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.8
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    MarkupSafe 2.0.1
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9178.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9178" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lwig-cellular-06" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9178</td>
<td class="center">Power-Efficient Cellular CoAP Devices</td>
<td class="right">May 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Arkko, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9178" class="eref">9178</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-05" class="published">May 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">J. Arkko</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">A. Eriksson</div>
<div class="org">Independent</div>
</div>
<div class="author">
      <div class="author-name">A. Keränen</div>
<div class="org">Ericsson</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9178</h1>
<h1 id="title">Building Power-Efficient Constrained Application Protocol (CoAP) Devices for Cellular Networks</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">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
devices that employ these networks is obviously well known, but this
memo focuses specifically on techniques necessary to minimize power
consumption.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by the
            Internet Engineering Steering Group (IESG).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9178">https://www.rfc-editor.org/info/rfc9178</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-goals-for-low-power-operati" class="xref">Goals for Low-Power Operation</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-link-layer-assumptions" class="xref">Link-Layer Assumptions</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-scenarios" class="xref">Scenarios</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-discovery-and-registration" class="xref">Discovery and Registration</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-data-formats" class="xref">Data Formats</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-real-time-reachable-devices" class="xref">Real-Time Reachable Devices</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-sleepy-devices" class="xref">Sleepy Devices</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-implementation-consideratio" class="xref">Implementation Considerations</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This memo discusses the use of the Constrained Application Protocol
(CoAP) <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> in building
sensors and other devices that employ cellular networks as a
communications medium. Building communicating devices that employ
these networks is obviously well known, but this memo focuses
specifically on techniques necessary to minimize power consumption.
CoAP has many advantages, including being simple to implement; a
thousand lines of code for the entire application above the IP layer is plenty for a
CoAP-based sensor, for instance. However, while many of these
advantages are obvious and easily obtained, optimizing power
consumption remains challenging and requires careful design <span>[<a href="#I-D.arkko-core-sleepy-sensors" class="xref">Tiny-CoAP</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This memo primarily targets 3GPP cellular networks in their 2G, 3G,
LTE, and 5G variants and their future enhancements, including possible
power efficiency improvements at the radio and link layers. The exact
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
is suitable for any large-scale, public network that employs a
point-to-point communications model and radio technology for the
devices in the network.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Our focus is on devices that need to be optimized for power usage and
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
on different roles. This freedom allows the technology to be used in
efficient and less efficient ways. Some guidance is needed to
understand what types of communication over CoAP are recommended when
low power usage is a critical goal.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">The recommendations in this memo should be taken as complementary
to device hardware optimization, microelectronics improvements, and
further evolution of the underlying link and radio layers. Further
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 IP, transport, and application layers to provide the best possible
power efficiency. Application implementors generally have to use the
current-generation microelectronics, currently available radio
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
areas is unnecessary. Such evolution is useful, ongoing, and 
generally complementary to the techniques presented in this memo.
However, the list of techniques described in this document as useful for a
particular application may change with the evolution of these underlying
technologies.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The rest of this memo is structured as follows. <a href="#lowpow" class="xref">Section 2</a> discusses the need and goals for low-power
devices. <a href="#model" class="xref">Section 3</a> outlines our expectations for the low-layer communications model. <a href="#scen" class="xref">Section 4</a> describes the two
scenarios that we address. Sections <a href="#disc" class="xref">5</a>, <a href="#data" class="xref">6</a>, <a href="#rt" class="xref">7</a>, and <a href="#sens" class="xref">8</a> give
guidelines for the use of CoAP in these scenarios.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">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.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="lowpow">
<section id="section-2">
      <h2 id="name-goals-for-low-power-operati">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-goals-for-low-power-operati" class="section-name selfRef">Goals for Low-Power Operation</a>
      </h2>
<p id="section-2-1">There are many situations where power usage optimization is
unnecessary. Optimization may not be necessary on devices that can run
on a power feed over wired communications media, such as in
Power-over-Ethernet (PoE) solutions. These devices may require a
rudimentary level of power optimization techniques just to keep
overall energy costs and aggregate power feed sizes at a reasonable
level, but more extreme techniques necessary for battery-powered
devices are not required. The situation is similar with devices that
can easily be connected to mains power. Other types of devices may
get an occasional charge of power from energy-harvesting techniques.
For instance, some environmental sensors can run on solar
cells. Typically, these devices still have to regulate their power
usage in a strict manner -- for instance, to be able to use solar cells that
are as small and inexpensive as possible.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">In battery-operated devices, power usage is even more
important. For instance, one of the authors employs over a hundred different
sensor devices in their home network. A majority of these devices are
wired and run on PoE, but in most environments this would be
impractical because the necessary wires do not exist. The future is in
wireless solutions that can cover buildings and other environments
without assuming a pre-existing wired infrastructure. In addition, in
many cases it is impractical to provide a mains power source. Often,
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
and power adapters would be more complicated than installing a
standalone device without any wires.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">Yet, with a large number of devices, the battery lifetimes become
critical. Cost and practical limits dictate that devices can be
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
change for one device within the network. This may be impractical in
many environments. In addition, some devices may be physically
difficult to reach for a battery change. Or, a large group of devices
-- such as utility meters or environmental sensors -- cannot be
economically serviced too often, even if in theory the batteries could
be changed.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">Many of these situations lead to a requirement for minimizing power
usage and/or maximizing battery lifetimes.  Using the power usage
strategies described in <span>[<a href="#RFC7228" class="xref">RFC7228</a>]</span>, mains-powered
sensor-type devices can use the Always-on strategy, whereas battery-operated or
energy-harvesting devices need to adjust behavior based on the
communication interval. For intervals on the order of seconds, the
Low-power strategy is appropriate. For intervals ranging from minutes
to hours, either the Low-power or Normally-off strategy is
suitable. Finally, for intervals lasting days or longer, Normally-off
is usually the best choice. Unfortunately, much of our current technology has been built with different objectives in mind -- for instance, networked devices that are "always on", gadgets that require humans to recharge them every couple of days, and protocols that have been optimized to maximize throughput rather than conserve
resources.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">Long battery lifetimes are required for many applications,
however. In some cases, these lifetimes should be on the order of years
or even a decade or longer. Some communication devices already reach
multi-year lifetimes, and continuous improvements in low-power
electronics and advances in radio technology keep pushing these
lifetimes longer. However, it is perhaps fair to say that battery
lifetimes are generally too short at present.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">Power usage cannot be evaluated based solely on lower-layer
communications. The entire system, including upper-layer protocols and
applications, is responsible for the power consumption as a whole. The
lower communication layers have already adopted many techniques that
can be used to reduce power usage, such as scheduling device wake-up
times. Further reductions will likely need some cooperation from the
upper layers so that unnecessary communications, denial-of-service
attacks on power consumption, and other power drains are
eliminated.<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">Of course, application requirements ultimately determine what kinds
of communications are necessary. For instance, some applications
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,
but to provide guidance on how to minimize the amount of
communications overhead that is not directly required by the
application. While such optimization is generally useful, it is,
relatively speaking, most noticeable in applications that transfer only
a small amount of data or operate only infrequently.<a href="#section-2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="model">
<section id="section-3">
      <h2 id="name-link-layer-assumptions">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-link-layer-assumptions" class="section-name selfRef">Link-Layer Assumptions</a>
      </h2>
<p id="section-3-1">We assume that the underlying communications network can be any
large-scale, public network that employs a point-to-point communications
model and radio technology.  2G, 3G, LTE, and 5G networks are examples of such
networks but are not the only possible networks with these characteristics.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">In the following, we look at some of these characteristics and their
implications.  Note that in most cases these characteristics are not
properties of the specific networks but rather are inherent in the concept
of public networks.<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">
          <p id="section-3-3.1.1">Public Networks<a href="#section-3-3.1.1" class="pilcrow">¶</a></p>
<p id="section-3-3.1.2">Using a public network service implies that applications can be
deployed without having to build a network to go with them. For
economic reasons, only the largest users (such as utility companies)
could afford to build their own network, and even they would not be
able to provide worldwide coverage. This means that applications
where coverage is important can be built. For instance, most
transport-sector applications require national or even worldwide coverage to
work.<a href="#section-3-3.1.2" class="pilcrow">¶</a></p>
<p id="section-3-3.1.3">But there are other implications as well. By definition, the network
is not tailored for this application, and, with some exceptions, the
traffic passes through the Internet. One implication of this is that
there are generally no application-specific network configurations or
discovery support. For instance, the public network helps devices to
get on the Internet, set up default routers, configure DNS servers,
and so on, but does nothing for configuring possible higher-layer
functions, such as servers that a device might need to contact to perform
its application functions.<a href="#section-3-3.1.3" class="pilcrow">¶</a></p>
<p id="section-3-3.1.4">Public networks often provide web proxies and other functionality that
can, in some cases, make significant improvements related to delays and costs
of communication over the wireless link. For instance, resolving
server DNS names in a proxy instead of the user's device may cut down
on the general chattiness of the communications, therefore reducing
overall delay in completing the entire transaction. Likewise, a CoAP
proxy or Publish-Subscribe (pub⁠/sub) Broker <span>[<a href="#I-D.ietf-core-coap-pubsub" class="xref">CoAP-PubSub</a>]</span>
can assist a CoAP device in communication. However, unlike HTTP web
proxies, CoAP proxies and brokers are not yet widely deployed in
public networks.<a href="#section-3-3.1.4" class="pilcrow">¶</a></p>
<p id="section-3-3.1.5">Similarly, given the lack of available IPv4 addresses, chances are
that many devices are behind a Network Address Translation (NAT)
device. This means that they are not easily reachable as servers.
Alternatively, the devices may be directly on the global Internet
(on either IPv4 or IPv6) and easily reachable as
servers. Unfortunately, this may mean that they also receive unwanted
traffic, which may have implications for both power consumption and
service costs.<a href="#section-3-3.1.5" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-3.2">
          <p id="section-3-3.2.1">Point-to-Point Link Model<a href="#section-3-3.2.1" class="pilcrow">¶</a></p>
<p id="section-3-3.2.2">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,
except maybe for the service provider's router. As a result, multicast
discovery cannot be reasonably used for any local discovery purposes.
While the configuration of the service provider's router for specific
users is theoretically possible, this is difficult to
achieve in practice, at least for any small user that cannot afford a
network-wide contract for a private APN (Access Point Name). The
public network access service has little per-user tailoring.<a href="#section-3-3.2.2" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-3.3">
          <p id="section-3-3.3.1">Radio Technology<a href="#section-3-3.3.1" class="pilcrow">¶</a></p>
<p id="section-3-3.3.2">The use of radio technology means that power is needed to operate the
radios. Transmission generally requires more power
than reception. However, radio protocols have generally been designed
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
consumes energy. Research has shown that these periodic checks (such
as LTE paging message reception) are often a far bigger contributor to
energy consumption than message transmission.<a href="#section-3-3.3.2" class="pilcrow">¶</a></p>
<p id="section-3-3.3.3">Note that for situations where there are several applications on the
same device wishing to communicate with the Internet in some manner,
bundling those applications together so that they can communicate at
the same time can be very useful. Some guidance for these techniques
in the smartphone context can be found in <span>[<a href="#Android-Bundle" class="xref">Android-Bundle</a>]</span>.<a href="#section-3-3.3.3" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-3-4">Naturally, each device has the freedom to decide when it sends
messages. In addition, we assume that there is some way for the
devices to control when or how often they want to receive messages.
Specific methods for doing this depend on the specific network being
used and also tend to change as improvements in the design of these
networks are incorporated. The reception control methods generally
come in two variants: (1) fine-grained mechanisms that deal with how often
the device needs to wake up for paging messages and (2) cruder
mechanisms where the device simply disconnects from the network for a
period of time. There are costs and benefits associated with each
method, but those are not relevant for this memo, as long as some
control method exists. Furthermore, devices could use Delay-Tolerant
Networking (DTN) mechanisms <span>[<a href="#RFC4838" class="xref">RFC4838</a>]</span> to relax the
requirements for timeliness of connectivity and message delivery.<a href="#section-3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="scen">
<section id="section-4">
      <h2 id="name-scenarios">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-scenarios" class="section-name selfRef">Scenarios</a>
      </h2>
<p id="section-4-1">Not all applications or situations are equal. They may require
different solutions or communication models. This memo focuses on two
common scenarios in cellular networks:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-2.1">
          <p id="section-4-2.1.1">Real-Time Reachable Devices<a href="#section-4-2.1.1" class="pilcrow">¶</a></p>
<p id="section-4-2.1.2">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,
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
in milliseconds or seconds. However, unpredictable sleep states are
not expected.<a href="#section-4-2.1.2" class="pilcrow">¶</a></p>
<p id="section-4-2.1.3">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
and actuators that require immediate action, such as light bulbs or door locks.<a href="#section-4-2.1.3" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-4-2.2">
          <p id="section-4-2.2.1">Sleepy Devices<a href="#section-4-2.2.1" class="pilcrow">¶</a></p>
<p id="section-4-2.2.2">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
its time. The device itself can choose when it communicates, or it lets
the network assist in this task.<a href="#section-4-2.2.2" class="pilcrow">¶</a></p>
<p id="section-4-2.2.3">Examples of devices in this category include sensors that track slowly
changing values, such as temperature sensors and actuators that
control a relatively slow process, such as heating systems.<a href="#section-4-2.2.3" class="pilcrow">¶</a></p>
<p id="section-4-2.2.4">Note that there may be hard real-time requirements, but they are
expressed in terms of how fast the device can communicate -- not in
terms of how fast it can respond to network stimuli. For instance,
a fire detector can be classified as a sleepy device as long as it
can internally quickly wake up on detecting fire and initiate the necessary
communications without delay.<a href="#section-4-2.2.4" class="pilcrow">¶</a></p>
</li>
      </ul>
</section>
</div>
<div id="disc">
<section id="section-5">
      <h2 id="name-discovery-and-registration">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-discovery-and-registration" class="section-name selfRef">Discovery and Registration</a>
      </h2>
<p id="section-5-1">In both scenarios, the device will be attached to a public network.
Without special arrangements, the device will also get a dynamically
assigned IP address or an IPv6 prefix. At least one but typically
several router hops separate the device from its communicating peers
such as application servers. As a result, the address or even the
existence of the device is typically not immediately obvious to the
other nodes participating in the application. As discussed earlier,
multicast discovery has limited value in public networks; network
nodes cannot practically discover individual devices in a large public
network. And the devices cannot discover who they need to talk to, as
the public network offers just basic Internet connectivity.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Our recommendation is to initiate a discovery and registration
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
address. Registration also facilitates low-power operation, since a
device can delegate part of the discovery signaling and reachability
requirements to another node.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The registration part is easy, e.g., with a resource directory. The
device should perform the necessary registration with such a resource directory --
for instance, as specified in <span>[<a href="#RFC9176" class="xref">RFC9176</a>]</span>. In order to do this
registration, the device needs to know its Constrained RESTful Environments (CoRE) Link Format
description, as specified in <span>[<a href="#RFC6690" class="xref">RFC6690</a>]</span>. In essence, the
registration process involves performing a GET on
.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.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">Other mechanisms enabling device discovery and delegation of
functionality to a non-sleepy node include those discussed in <span>[<a href="#I-D.vial-core-mirror-proxy" class="xref">CoRE-Mirror</a>]</span> and <span>[<a href="#I-D.ietf-core-coap-pubsub" class="xref">CoAP-PubSub</a>]</span>.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">However, current CoAP specifications provide only limited support
for discovering the resource directory or other registration
services. Local multicast discovery only works in LAN-type networks; it does
not work in the public cellular networks discussed in this document. We recommend the following alternate methods for discovery:<a href="#section-5-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-6.1">
          <p id="section-5-6.1.1">Manual Configuration<a href="#section-5-6.1.1" class="pilcrow">¶</a></p>
<p id="section-5-6.1.2">The DNS name of the resource directory is manually configured. This
approach is suitable in situations where the owner of the devices has
the resources and capabilities to do the configuration. For instance,
a utility company can typically program its metering devices to point
to the company servers.<a href="#section-5-6.1.2" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-5-6.2">
          <p id="section-5-6.2.1">Manufacturer Server<a href="#section-5-6.2.1" class="pilcrow">¶</a></p>
<p id="section-5-6.2.2">The DNS name of the directory or proxy is hardwired to the
   software by the manufacturer, and the directory or proxy is actually run by the
manufacturer. This approach is suitable in many consumer usage
scenarios, where it would be unreasonable to assume that the consumer
runs any specific network services. The manufacturer's web interface
and the directory/proxy servers can cooperate to provide the desired
functionality to the end user. For instance, the end user can register
a device identity in the manufacturer's web interface and ask that specific
actions be taken when the device does something.<a href="#section-5-6.2.2" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-5-6.3">
          <p id="section-5-6.3.1">Delegating Manufacturer Server<a href="#section-5-6.3.1" class="pilcrow">¶</a></p>
<p id="section-5-6.3.2">The DNS name of the directory or proxy is hardwired to the software by
the manufacturer, but this directory or proxy merely redirects the
request to a directory or proxy run by whoever bought the
device. This approach is suitable in many enterprise environments, as
it allows the enterprise to be in charge of actual data collection and
device registries; only the initial bootstrap goes through the
manufacturer. In many cases, there are even legal requirements (such as
EU privacy laws) that prevent providing unnecessary information to
third parties.<a href="#section-5-6.3.2" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-5-6.4">
          <p id="section-5-6.4.1">Common Global Resolution Infrastructure<a href="#section-5-6.4.1" class="pilcrow">¶</a></p>
<p id="section-5-6.4.2">The delegating manufacturer server model could be generalized into
a reverse-DNS-like discovery infrastructure that could, for example, answer the question "This is a device with identity ID 2456; where is my home registration server?" However, at present, no such resolution system exists.
(Note: The EPCGlobal system for Radio Frequency Identification (RFID) resolution is reminiscent
 of this approach.)<a href="#section-5-6.4.2" class="pilcrow">¶</a></p>
</li>
      </ul>
<p id="section-5-7">Besides manual configuration, these alternate mechanisms are mostly
suitable for large manufacturers and deployments. Good automated
mechanisms for discovery of devices that are manufactured and deployed
in small quantities are still needed.<a href="#section-5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="data">
<section id="section-6">
      <h2 id="name-data-formats">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-data-formats" class="section-name selfRef">Data Formats</a>
      </h2>
<p id="section-6-1">A variety of data formats exist for passing around data. These data
formats include XML, JavaScript Object Notation (JSON) <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>, Efficient XML Interchange (EXI) <span>[<a href="#W3C.REC-exi-20140211" class="xref">W3C.REC-exi-20140211</a>]</span>, Concise Binary Object Representation (CBOR) <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>, and various text formats. Message lengths can
have a significant effect on the amount of energy required for the
communications, and as such it is highly desirable to keep message
lengths minimal. At the same time, extreme optimization can affect
flexibility and ease of programming. The authors recommend that readers refer
to <span>[<a href="#RFC8428" class="xref">RFC8428</a>]</span> for a compact but easily processed 
and extendable format.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rt">
<section id="section-7">
      <h2 id="name-real-time-reachable-devices">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-real-time-reachable-devices" class="section-name selfRef">Real-Time Reachable Devices</a>
      </h2>
<p id="section-7-1">These devices are often best modeled as CoAP servers. The device
will have limited control over when it receives messages, and it will
have to listen actively for messages, up to the limits of the
underlying link layer. If in some phase of its operation the device also acts in the role of a client, it can control how many transmissions it makes
on its own behalf.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">The packet reception checks should be tailored according to the
requirements of the application. If sub-second response time is not
needed, a more infrequent checking process may save some power.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">For sensor-type devices, the CoAP Observe extension (Observe option) <span>[<a href="#RFC7641" class="xref">RFC7641</a>]</span> may be supported. This allows the sensor to track
changes to the sensed value and make an immediate observation
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
that the device needs to be listening for requests. Subscription
requests from clients other than the currently registered client may come
in at any time, the current client may change its request, and the device
still needs to respond to normal queries as a server. As a result, the
sensor cannot rely on having to communicate only on its own choice of
observation interval.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">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
network.  If the device is hosted on a private network, then all
other nodes that need to access this device also need to reside in the same
private network. There are multiple ways to provide private networks
over public cellular networks. One approach is to dedicate a special
APN for the private network. Corporate access via cellular networks
has often been arranged in this manner, for instance. Another approach
is to use Virtual Private Network (VPN) technology -- for instance,
IPsec-based VPNs.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">Power consumption from unwanted traffic is problematic in these
devices, unless they are placed in a private network or protected by an
operator-provided firewall service. Devices on an IPv6 network will
be afforded some protection due to the nature of the 2<sup>64</sup> address allocation
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
protects only the device from processing a packet, but since the
network will still deliver the packet to any of the addresses within
the assigned 64-bit prefix, packet reception costs are still
incurred.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">Note that the VPN approach cannot prevent unwanted traffic
received at the tunnel endpoint address and may require keep-alive
traffic. Special APNs can solve this issue but require an explicit
arrangement with the service provider.<a href="#section-7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sens">
<section id="section-8">
      <h2 id="name-sleepy-devices">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-sleepy-devices" class="section-name selfRef">Sleepy Devices</a>
      </h2>
<p id="section-8-1">These devices are best modeled as devices that can delegate queries
to some other node -- for instance, as mirror servers <span>[<a href="#I-D.vial-core-mirror-proxy" class="xref">CoRE-Mirror</a>]</span> or CoAP
pub⁠/sub Clients <span>[<a href="#I-D.ietf-core-coap-pubsub" class="xref">CoAP-PubSub</a>]</span>. When the device initializes
itself, it makes a registration of itself in a server or broker as described
above in <a href="#disc" class="xref">Section 5</a> and then continues to send periodic
updates of sensor values.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">As a result, the device acts only as a client and not as a server, and
can shut down all communication channels during its
sleeping period. The length of the sleeping period depends on power
and application requirements. Some environmental sensors might use a
day or a week as the period, while other devices may use smaller
values ranging from minutes to hours.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">The ability to shut down communications and act as only a client
has four impacts:<a href="#section-8-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-4.1">Radio transmission and reception can be turned off during the
sleeping period, reducing power consumption significantly.<a href="#section-8-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.2">However, some power and time are consumed by having to reattach to
the network after the end of a sleep period.<a href="#section-8-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.3">The window of opportunity for unwanted traffic to arrive is much
smaller, as the device is listening for traffic only part of the
time. Note, however, that networks may cache packets for some time. On
the other hand, stateful firewalls can effectively remove much of the
unwanted traffic for client-type devices.<a href="#section-8-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-4.4">The device may exist behind a NAT or a firewall without being
impacted. Note that the "simple security" basic IPv6 firewall capability
<span>[<a href="#RFC6092" class="xref">RFC6092</a>]</span> blocks inbound UDP traffic by default, so just
moving to IPv6 is not a direct solution to this problem.<a href="#section-8-4.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-5">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 from the server or broker about variable changes via either polling or notifications.<a href="#section-8-5" class="pilcrow">¶</a></p>
<section id="section-8.1">
        <h3 id="name-implementation-consideratio">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-implementation-consideratio" class="section-name selfRef">Implementation Considerations</a>
        </h3>
<p id="section-8.1-1">There are several challenges related to implementing sleepy devices. They
need hardware that can be placed in an appropriate sleep mode but
awakened when it is time to do something again. This is not always
easy in all hardware platforms. It is important to be able to shut
down as much of the hardware as possible, preferably down to
everything else except a clock circuit. The platform also needs to support
reawakening at suitable timescales, as otherwise the device needs to be 
powered up too frequently.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">Most commercial cellular modem platforms do not allow applications
to suspend the state of the communications stack. Hence, after a
power-off period, they need to re-establish communications, which takes
some amount of time and extra energy.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3">Implementations should have a coordinated understanding of the
state and sleeping schedule. For instance, it makes no sense to keep a
CPU powered up, waiting for a message when the lower layer has been
told that the next possible paging opportunity is some time away.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">The cellular networks have a number of adjustable configuration
parameters, such as the maximum used paging interval. Proper settings
of these values have an impact on the power consumption of the device,
but with current business practices, such settings are rarely
negotiated when the user's subscription is provisioned.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">There are no particular security aspects related to what has been
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
obvious security issues that have largely NOT yet been addressed in
the relevant Internet-Drafts <span>[<a href="#I-D.vial-core-mirror-proxy" class="xref">CoRE-Mirror</a>]</span>
        <span>[<a href="#I-D.castellani-core-alive" class="xref">CoAP-Alive</a>]</span>
        <span>[<a href="#I-D.fossati-core-publish-monitor-options" class="xref">CoAP-Publ-Monitor</a>]</span>.  However,
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
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
security. We have implemented one such mechanism for sleepy nodes as
described in <span>[<a href="#RFC8387" class="xref">RFC8387</a>]</span>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">The security considerations relating to CoAP <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> and the relevant link layers should
apply. Note that cellular networks universally employ per-device
authentication, integrity protection, and, for most of the world,
encryption of all their communications. Additional protection of
transport sessions is possible through mechanisms described in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> or data objects.<a href="#section-9-2" class="pilcrow">¶</a></p>
</section>
<div id="iana">
<section id="section-10">
      <h2 id="name-iana-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-10-1">This document has no IANA actions.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-11">
      <h2 id="name-references">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-11.1">
        <h3 id="name-normative-references">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6690">[RFC6690]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Link Format"</span>, <span class="seriesInfo">RFC 6690</span>, <span class="seriesInfo">DOI 10.17487/RFC6690</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6690">https://www.rfc-editor.org/info/rfc6690</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7252">[RFC7252]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Hartke, K.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"The Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7252</span>, <span class="seriesInfo">DOI 10.17487/RFC7252</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7252">https://www.rfc-editor.org/info/rfc7252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7641">[RFC7641]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Observing Resources in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7641</span>, <span class="seriesInfo">DOI 10.17487/RFC7641</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7641">https://www.rfc-editor.org/info/rfc7641</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9176">[RFC9176]</dt>
        <dd>
<span class="refAuthor">Amsüss, C., Ed.</span>, <span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Koster, M.</span>, <span class="refAuthor">Bormann, C.</span>, and <span class="refAuthor">P. van der Stok</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Resource Directory"</span>, <span class="seriesInfo">RFC 9176</span>, <span class="seriesInfo">DOI 10.17487/RFC9176</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9176">https://www.rfc-editor.org/info/rfc9176</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C.REC-exi-20140211">[W3C.REC-exi-20140211]</dt>
        <dd>
<span class="refAuthor">Schneider, J.</span>, <span class="refAuthor">Kamiya, T.</span>, <span class="refAuthor">Peintner, D.</span>, and <span class="refAuthor">R. Kyusakov</span>, <span class="refTitle">"Efficient XML Interchange (EXI) Format 1.0 (Second Edition)"</span>, <span class="refContent">World Wide Web Consortium Recommendation REC-exi-20140211</span>, <time datetime="2014-02" class="refDate">February 2014</time>, <span>&lt;<a href="https://www.w3.org/TR/exi/">https://www.w3.org/TR/exi/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8428">[RFC8428]</dt>
        <dd>
<span class="refAuthor">Jennings, C.</span>, <span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Keranen, A.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Sensor Measurement Lists (SenML)"</span>, <span class="seriesInfo">RFC 8428</span>, <span class="seriesInfo">DOI 10.17487/RFC8428</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8428">https://www.rfc-editor.org/info/rfc8428</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7228">[RFC7228]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Ersue, M.</span>, and <span class="refAuthor">A. Keranen</span>, <span class="refTitle">"Terminology for Constrained-Node Networks"</span>, <span class="seriesInfo">RFC 7228</span>, <span class="seriesInfo">DOI 10.17487/RFC7228</span>, <time datetime="2014-05" class="refDate">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7228">https://www.rfc-editor.org/info/rfc7228</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-11.2">
        <h3 id="name-informative-references">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC4838">[RFC4838]</dt>
        <dd>
<span class="refAuthor">Cerf, V.</span>, <span class="refAuthor">Burleigh, S.</span>, <span class="refAuthor">Hooke, A.</span>, <span class="refAuthor">Torgerson, L.</span>, <span class="refAuthor">Durst, R.</span>, <span class="refAuthor">Scott, K.</span>, <span class="refAuthor">Fall, K.</span>, and <span class="refAuthor">H. Weiss</span>, <span class="refTitle">"Delay-Tolerant Networking Architecture"</span>, <span class="seriesInfo">RFC 4838</span>, <span class="seriesInfo">DOI 10.17487/RFC4838</span>, <time datetime="2007-04" class="refDate">April 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4838">https://www.rfc-editor.org/info/rfc4838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6092">[RFC6092]</dt>
        <dd>
<span class="refAuthor">Woodyatt, J., Ed.</span>, <span class="refTitle">"Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service"</span>, <span class="seriesInfo">RFC 6092</span>, <span class="seriesInfo">DOI 10.17487/RFC6092</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6092">https://www.rfc-editor.org/info/rfc6092</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.arkko-core-sleepy-sensors">[Tiny-CoAP]</dt>
        <dd>
<span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Rissanen, H.</span>, <span class="refAuthor">Loreto, S.</span>, <span class="refAuthor">Turanyi, Z.</span>, and <span class="refAuthor">O. Novo</span>, <span class="refTitle">"Implementing Tiny COAP Sensors"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-arkko-core-sleepy-sensors-01</span>, <time datetime="2011-07-05" class="refDate">5 July 2011</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-arkko-core-sleepy-sensors-01">https://datatracker.ietf.org/doc/html/draft-arkko-core-sleepy-sensors-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8387">[RFC8387]</dt>
        <dd>
<span class="refAuthor">Sethi, M.</span>, <span class="refAuthor">Arkko, J.</span>, <span class="refAuthor">Keranen, A.</span>, and <span class="refAuthor">H. Back</span>, <span class="refTitle">"Practical Considerations and Implementation Experiences in Securing Smart Object Networks"</span>, <span class="seriesInfo">RFC 8387</span>, <span class="seriesInfo">DOI 10.17487/RFC8387</span>, <time datetime="2018-05" class="refDate">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8387">https://www.rfc-editor.org/info/rfc8387</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.castellani-core-alive">[CoAP-Alive]</dt>
        <dd>
<span class="refAuthor">Castellani, A.</span> and <span class="refAuthor">S. Loreto</span>, <span class="refTitle">"CoAP Alive Message"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-castellani-core-alive-00</span>, <time datetime="2012-03-29" class="refDate">29 March 2012</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-castellani-core-alive-00">https://datatracker.ietf.org/doc/html/draft-castellani-core-alive-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.fossati-core-publish-monitor-options">[CoAP-Publ-Monitor]</dt>
        <dd>
<span class="refAuthor">Fossati, T.</span>, <span class="refAuthor">Giacomin, P.</span>, and <span class="refAuthor">S. Loreto</span>, <span class="refTitle">"Publish and Monitor Options for CoAP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-fossati-core-publish-monitor-options-01</span>, <time datetime="2012-03-10" class="refDate">10 March 2012</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-fossati-core-publish-monitor-options-01">https://datatracker.ietf.org/doc/html/draft-fossati-core-publish-monitor-options-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.vial-core-mirror-proxy">[CoRE-Mirror]</dt>
        <dd>
<span class="refAuthor">Vial, M.</span>, <span class="refTitle">"CoRE Mirror Server"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-vial-core-mirror-proxy-01</span>, <time datetime="2012-07-13" class="refDate">13 July 2012</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-vial-core-mirror-proxy-01">https://datatracker.ietf.org/doc/html/draft-vial-core-mirror-proxy-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-core-coap-pubsub">[CoAP-PubSub]</dt>
        <dd>
<span class="refAuthor">Koster, M.</span>, <span class="refAuthor">Keranen, A.</span>, and <span class="refAuthor">J. Jimenez</span>, <span class="refTitle">"Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-core-coap-pubsub-10</span>, <time datetime="2022-05-04" class="refDate">4 May 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-10">https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-10</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Android-Bundle">[Android-Bundle]</dt>
      <dd>
<span class="refTitle">"Optimize network access"</span>, <span class="refContent">Android developer note</span>, <time datetime="2022-05" class="refDate">May 2022</time>, <span>&lt;<a href="https://developer.android.com/training/efficient-downloads/efficient-network-access.html">https://developer.android.com/training/efficient-downloads/efficient-network-access.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">The authors would like to thank <span class="contact-name">Zach Shelby</span>,
      <span class="contact-name">Jan Holler</span>, <span class="contact-name">Salvatore       Loreto</span>, <span class="contact-name">Matthew Vial</span>, <span class="contact-name">Thomas       Fossati</span>, <span class="contact-name">Mohit Sethi</span>, <span class="contact-name">Jan       Melen</span>, <span class="contact-name">Joachim Sachs</span>, <span class="contact-name">Heidi-Maria Rissanen</span>, <span class="contact-name">Sebastien       Pierrel</span>, <span class="contact-name">Kumar Balachandran</span>, <span class="contact-name">Muhammad Waqas Mir</span>, <span class="contact-name">Cullen Jennings</span>,
      <span class="contact-name">Markus Isomaki</span>, <span class="contact-name">Hannes Tschofenig</span>, and <span class="contact-name">Anna Larmo</span> for interesting discussions in this problem
space.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jari Arkko</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jari.arkko@piuha.net" class="email">jari.arkko@piuha.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Anders Eriksson</span></div>
<div dir="auto" class="left"><span class="org">Independent</span></div>
<div dir="auto" class="left">SE-<span class="postal-code">164 83</span> <span class="locality">Stockholm</span>
</div>
<div dir="auto" class="left"><span class="country-name">Sweden</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:anders.e.eriksson@posthem.se" class="email">anders.e.eriksson@posthem.se</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ari Keränen</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left">FI-<span class="postal-code">02420</span> <span class="locality">Jorvas</span>
</div>
<div dir="auto" class="left"><span class="country-name">Finland</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ari.keranen@ericsson.com" class="email">ari.keranen@ericsson.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>