<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-lpwan-schc-over-sigfox-23" number="9442" submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" prepTime="2023-07-26T16:33:29" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lpwan-schc-over-sigfox-23" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9442" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="SCHC over Sigfox LPWAN">Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)</title>
    <seriesInfo name="RFC" value="9442" stream="IETF"/>
    <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
      <address>
        <postal>
          <street/>
          <city>Montreal</city>
          <region>QC</region>
          <country>Canada</country>
        </postal>
        <email>j.c.zuniga@ieee.org</email>
      </address>
    </author>
    <author initials="C." surname="Gomez" fullname="Carles Gomez">
      <organization showOnFrontPage="true">Universitat Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <city>Castelldefels</city>
          <code>08860</code>
          <country>Spain</country>
        </postal>
        <email>carles.gomez@upc.edu</email>
      </address>
    </author>
    <author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
      <organization showOnFrontPage="true">Universitat Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <city>Castelldefels</city>
          <code>08860</code>
          <country>Spain</country>
        </postal>
        <email>sergio.aguilar.romero@upc.edu</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization showOnFrontPage="true">IMT-Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <extaddr>CS 17607</extaddr>
          <city>Cesson-Sevigne Cedex</city>
          <code>35576</code>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
      <organization showOnFrontPage="true">Concordia University</organization>
      <address>
        <postal>
          <street>1455 De Maisonneuve Blvd. W.</street>
          <city>Montreal</city>
          <region>QC</region>
          <code>H3G 1M8</code>
          <country>Canada</country>
        </postal>
        <email>sandra.cespedes@concordia.ca</email>
      </address>
    </author>
    <author initials="D." surname="Wistuba" fullname="Diego Wistuba">
      <organization showOnFrontPage="true">NIC Labs, Universidad de Chile</organization>
      <address>
        <postal>
          <street>Av. Almte. Blanco Encalada 1975</street>
          <city>Santiago</city>
          <country>Chile</country>
        </postal>
        <email>research@witu.cl</email>
      </address>
    </author>
    <author fullname="Julien Boite" initials="J." surname="Boite">
      <organization showOnFrontPage="true">Unabiz (Sigfox)</organization>
      <address>
        <postal>
          <street/>
          <city>Labege</city>
          <country>France</country>
        </postal>
        <email>juboite@free.fr</email>
        <uri>https://www.sigfox.com/</uri>
      </address>
    </author>
    <date month="07" year="2023"/>
    <area>int</area>
    <workgroup>lpwan</workgroup>
    <keyword>IoT</keyword>
    <keyword>Sigfox</keyword>
    <keyword>SCHC</keyword>
    <keyword>LPWAN</keyword>
    <keyword>fragmentation</keyword>
    <keyword>Reliable Delivery</keyword>
    <keyword>Link Layer Protocols</keyword>
    <keyword>Cross-Layer Protocols</keyword>
    <keyword>Adaptation Layer</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed for Low-Power Wide Area Network (LPWAN) technologies.
        This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="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).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="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
            <eref target="https://www.rfc-editor.org/info/rfc9442" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schc-over-sigfox">SCHC over Sigfox</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-network-architecture">Network Architecture</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink">Uplink</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-downlink">Downlink</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.3.2">
                  <li pn="section-toc.1-1.3.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.3.2.1.1"><xref derivedContent="3.3.1" format="counter" sectionFormat="of" target="section-3.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schc-ack-on-downlink">SCHC ACK on Downlink</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schc-rules">SCHC Rules</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.5">
                <t indent="0" pn="section-toc.1-1.3.2.5.1"><xref derivedContent="3.5" format="counter" sectionFormat="of" target="section-3.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fragmentation">Fragmentation</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.5.2">
                  <li pn="section-toc.1-1.3.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.1.1"><xref derivedContent="3.5.1" format="counter" sectionFormat="of" target="section-3.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-fragmentation">Uplink Fragmentation</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.5.2.2.1"><xref derivedContent="3.5.2" format="counter" sectionFormat="of" target="section-3.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-downlink-fragmentation">Downlink Fragmentation</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.6">
                <t indent="0" pn="section-toc.1-1.3.2.6.1"><xref derivedContent="3.6" format="counter" sectionFormat="of" target="section-3.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schc-over-sigfox-f-r-messag">SCHC over Sigfox F/R Message Formats</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2.6.2">
                  <li pn="section-toc.1-1.3.2.6.2.1">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.1.1"><xref derivedContent="3.6.1" format="counter" sectionFormat="of" target="section-3.6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-no-ack-mode-single-by">Uplink No-ACK Mode: Single-Byte SCHC Header</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.2">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.2.1"><xref derivedContent="3.6.2" format="counter" sectionFormat="of" target="section-3.6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-ack-on-error-mode-sin">Uplink ACK-on-Error Mode: Single-Byte SCHC Header</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.3">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.3.1"><xref derivedContent="3.6.3" format="counter" sectionFormat="of" target="section-3.6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-ack-on-error-mode-two-">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.4">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.4.1"><xref derivedContent="3.6.4" format="counter" sectionFormat="of" target="section-3.6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-ack-on-error-mode-two-b">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2</xref></t>
                  </li>
                  <li pn="section-toc.1-1.3.2.6.2.5">
                    <t indent="0" pn="section-toc.1-1.3.2.6.2.5.1"><xref derivedContent="3.6.5" format="counter" sectionFormat="of" target="section-3.6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-downlink-ack-always-mode-si">Downlink ACK-Always Mode: Single-Byte SCHC Header</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.3.2.7">
                <t indent="0" pn="section-toc.1-1.3.2.7.1"><xref derivedContent="3.7" format="counter" sectionFormat="of" target="section-3.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-padding">Padding</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fragmentation-rules-example">Fragmentation Rules Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-fragmentation-rules-">Uplink Fragmentation Rules Examples</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-downlink-fragmentation-rule">Downlink Fragmentation Rules Example</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fragmentation-sequence-exam">Fragmentation Sequence Examples</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-no-ack-examples">Uplink No-ACK Examples</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uplink-ack-on-error-example">Uplink ACK-on-Error Examples: Single-Byte SCHC Header</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-schc-abort-examples">SCHC Abort Examples</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="Introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation specification <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/> can be used in conjunction with any of the four LPWAN technologies
described in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/>. These LPWANs have similar characteristics, such as star-oriented
topologies, network architecture, connected devices with built-in applications, etc. 
</t>
      <t indent="0" pn="section-1-2">SCHC offers a considerable degree of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between
them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation 
that can be used when SCHC is used in conjunction with a specific LPWAN technology.
</t>
      <t indent="0" pn="section-1-3">
    Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost.
    Complete Sigfox documentation can be found in <xref target="sigfox-docs" format="default" sectionFormat="of" derivedContent="sigfox-docs"/>.
    Sigfox aims to provide a very wide area network composed of Base Stations that receive short Uplink messages (up to 12 bytes in size) sent by devices over the long-range Sigfox radio protocol, as described in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/>.
    Base Stations then forward messages to the Sigfox Cloud infrastructure for further processing (e.g., to offer geolocation services) and final delivery to the customer.
        Base Stations also relay Downlink messages (with a fixed 8-byte size) sent by the Sigfox Cloud to the devices,  i.e., Downlink messages are being generated when devices explicitly request these messages with a flag in an Uplink message.
    With SCHC functionalities, the Sigfox network offers more reliable communications (including recovery of lost messages) and is able to convey extended-size payloads (allowing for fragmentation/reassembly of
messages) <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>.
</t>
      <t indent="0" pn="section-1-4">This document describes the parameters, settings, and modes of operation to be used when SCHC is implemented over a Sigfox LPWAN. The set of parameters forms a "SCHC over Sigfox Profile".
    The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March
2022 <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>  (support for future versions would have to be assessed).

</t>
    </section>
    <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> 
    when, and only when, they appear in all capitals, as shown here.
      </t>
      <t indent="0" pn="section-2-2">It is assumed that the reader is familiar with the terms and mechanisms defined in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/> and <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>. Also, it is assumed that the reader is familiar with Sigfox terminology <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>.
</t>
    </section>
    <section anchor="schc-over-sigfox" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-schc-over-sigfox">SCHC over Sigfox</name>
      <t indent="0" pn="section-3-1">The Generic SCHC Framework described in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/> takes advantage of previous knowledge of traffic flows existing in LPWAN applications to avoid context synchronization.</t>
      <t indent="0" pn="section-3-2">Contexts need to be stored and pre-configured on both ends.
    This can be done either by using a provisioning protocol, by out-of-band means, or by
    pre-provisioning them (e.g., at manufacturing time).
    For example, the context exchange can be done by using the Network Configuration Protocol (NETCONF) <xref target="RFC6241" format="default" sectionFormat="of" derivedContent="RFC6241"/> with Secure Shell (SSH), RESTCONF <xref target="RFC8040" format="default" sectionFormat="of" derivedContent="RFC8040"/> with secure HTTP methods, and CoAP Management Interface (CORECONF) <xref target="I-D.ietf-core-comi" format="default" sectionFormat="of" derivedContent="CORE-COMI"/> with the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> as provisioning protocols. The contexts can be encoded in XML under NETCONF, in JSON <xref target="RFC8259" format="default" sectionFormat="of" derivedContent="RFC8259"/> under RESTCONF, and in Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/> under CORECONF.
    The way contexts are configured and stored on both ends is out of the scope of this document.</t>
      <section anchor="network-arch" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-network-architecture">Network Architecture</name>
        <t indent="0" pn="section-3.1-1"><xref target="Fig-archi" format="default" sectionFormat="of" derivedContent="Figure 1"/> represents the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based
on the terminology defined in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/>, where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the
Sigfox cloud-based Network. </t>
        <figure anchor="Fig-archi" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-network-architecture-2">Network Architecture</name>
          <artwork name="" type="" align="center" alt="" pn="section-3.1-2.1">
  Sigfox Device                                           Application
+----------------+                                     +--------------+
| APP1 APP2 APP3 |                                     |APP1 APP2 APP3|
+----------------+                                     +--------------+
|   UDP  |       |                                     |     |  UDP   | 
|  IPv6  |       |                                     |     | IPv6   |   
+--------+       |                                     |     +--------+  
| SCHC C/D &amp; F/R |                                     |              |  
|                |                                     |              | 
+-------+--------+                                     +--------+-----+ 
        $                                                       .
        $   +---------+     +--------------+     +---------+    .
        $   |         |     |   Network    |     | Network |    .
        +~~ |Sigfox BS|     |   Gateway    |     |  SCHC   |    .
            |  (RGW)  | === |    (NGW)     | ... |C/D &amp; F/R|.....
            |         |     | Sigfox Cloud |     |         |   IP-based
            +---------+     +--------------+     +---------+   Network
------- Uplink message ------&gt;
                                       &lt;------- Downlink message ------
Legend:
$, ~ : Radio link
= : Internal Sigfox Network
. : External IP-based Network
</artwork>
        </figure>
        <t indent="0" pn="section-3.1-3">In the case of the global Sigfox network, RGWs (or Base Stations) are distributed over multiple countries wherever the Sigfox LPWAN service is provided.
The NGW (or cloud-based Sigfox Core Network) is a single entity that connects to all RGWs (Sigfox Base Stations) in the world, hence providing a global single star Network topology.</t>
        <t indent="0" pn="section-3.1-4">The Sigfox Device sends application packets that are compressed and/or fragmented by a SCHC C/D + F/R to reduce header size and/or fragment the packet.
The resulting SCHC message is sent over a layer two (L2) Sigfox frame to the Sigfox Base Stations, which then forward the SCHC message to the NGW.
The NGW then delivers the SCHC message and associated gathered metadata to the Network SCHC C/D + F/R.</t>
        <t indent="0" pn="section-3.1-5">The Sigfox cloud-based Network communicates with the Network SCHC C/D + F/R for compression/decompression and/or for fragmentation/reassembly. The Network SCHC C/D + F/R shares the same set of Rules 
as the device SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with the NGW or it could be located in a different place, as long as a tunnel or secured communication is established between
the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly, the packet can be forwarded over the Internet to one (or several) LPWAN Application Server(s) (App(s)).</t>
        <t indent="0" pn="section-3.1-6">The SCHC C/D + F/R processes are bidirectional, so the same principles are applicable on both Uplink (UL) and Downlink (DL).</t>
      </section>
      <section anchor="uplink" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-uplink">Uplink</name>
        <t indent="0" pn="section-3.2-1">Uplink Sigfox transmissions occur in repetitions over different times and frequencies. 
Besides time and frequency diversities, the Sigfox network also provides spatial diversity, as potentially an Uplink message will be received by several Base Stations. The Uplink message application payload size can be up to 12 bytes.</t>
        <t indent="0" pn="section-3.2-2">Since all messages are self-contained and Base Stations forward all these messages back to the same Sigfox network, multiple input copies can be 
combined at the NGW, providing for extra reliability based on the triple diversity (i.e., time, space, and frequency). 
</t>
        <t indent="0" pn="section-3.2-3">
A detailed description of the Sigfox radio protocol can be found in <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>.
</t>
        <t indent="0" pn="section-3.2-4">Messages sent from the device to the Network are delivered by the Sigfox cloud-based Network to the Network SCHC C/D + F/R through a  callback/API with the following information:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-5">
          <li pn="section-3.2-5.1">Device ID</li>
          <li pn="section-3.2-5.2">Message Sequence Number</li>
          <li pn="section-3.2-5.3">Message Payload</li>
          <li pn="section-3.2-5.4">Message Timestamp</li>
          <li pn="section-3.2-5.5">Device Geolocation (optional)</li>
          <li pn="section-3.2-5.6">Received Signal Strength Indicator (RSSI) (optional)</li>
          <li pn="section-3.2-5.7">Device Temperature (optional)</li>
          <li pn="section-3.2-5.8">Device Battery Voltage (optional)</li>
        </ul>
        <t indent="0" pn="section-3.2-6">The Device ID is a globally unique identifier assigned to the device, which is included in the Sigfox header of every message. The Message Sequence Number is a monotonically 
increasing number identifying the specific transmission of this Uplink message, and it is also part of the Sigfox header. The Message Payload corresponds to the payload that the
device has sent in the Uplink transmission.
	Battery Voltage, Device Temperature, and RSSI values are sent in the confirmation control message, which is mandatorily sent by the device after the successful reception of a Downlink message (see <xref target="sigfox-callbacks" format="default" sectionFormat="of" derivedContent="sigfox-callbacks"/>, Section 5.2).</t>
        <t indent="0" pn="section-3.2-7">The Message Timestamp, Device Geolocation, RSSI, Device Temperature, and Device Battery Voltage are metadata parameters provided by the Network.</t>
        <t indent="0" pn="section-3.2-8">A detailed description of the Sigfox callbacks/APIs can be found in <xref target="sigfox-callbacks" format="default" sectionFormat="of" derivedContent="sigfox-callbacks"/>.</t>
        <t indent="0" pn="section-3.2-9">Only messages that have passed the L2 Cyclic Redundancy Check (CRC) at Network reception are delivered by the Sigfox network to the Network SCHC C/D + F/R.</t>
        <t indent="0" pn="section-3.2-10">The L2 Word size used by Sigfox is 1 byte (8 bits). </t>
        <t indent="0" pn="section-3.2-11"><xref target="SCHC-Message" format="default" sectionFormat="of" derivedContent="Figure 2"/> shows a SCHC message sent over Sigfox, where the SCHC message could be a full SCHC Packet (e.g., compressed)
or a SCHC Fragment (e.g., a piece of a bigger SCHC Packet).</t>
        <figure anchor="SCHC-Message" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-schc-message-in-sigfox">SCHC Message in Sigfox</name>
          <artwork name="" type="" align="center" alt="" pn="section-3.2-12.1">
| Sigfox Header | Sigfox Payload  |
+---------------+---------------- +
                |   SCHC Message  |
</artwork>
        </figure>
      </section>
      <section anchor="downlink" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-downlink">Downlink</name>
        <t indent="0" pn="section-3.3-1">
   Downlink transmissions are device-driven and can only take place
   following an Uplink communication that indicates Downlink communication can be performed. Hence, a Sigfox Device explicitly indicates its intention to receive a Downlink message (with a size of 8 bytes)
using a Downlink request flag when sending the preceding Uplink message to the Network. The Downlink request flag is part of the Sigfox protocol headers. After completing the Uplink transmission, the device opens a fixed window for Downlink reception.
The delay and duration of the reception opportunity window have fixed values. If there is a Downlink message to be sent for this given device (e.g., either
a response to the Uplink message or queued information waiting to be transmitted), the Network transmits this message to the device during the reception window. If no message is received by the device after
the reception opportunity window has elapsed, the device closes the reception window opportunity and gets back to the normal mode (e.g., continue Uplink transmissions, sleep, standby, etc.).
</t>
        <t indent="0" pn="section-3.3-2">When a Downlink message is sent to a device, a reception acknowledgement is generated by the device, sent back to the Network through the Sigfox radio protocol, and reported in the Sigfox network backend.</t>
        <t indent="0" pn="section-3.3-3">
A detailed description of the Sigfox radio protocol can be found in <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>, and a detailed description of the Sigfox callbacks/APIs can be found in <xref target="sigfox-callbacks" format="default" sectionFormat="of" derivedContent="sigfox-callbacks"/>. A Downlink request flag can be included in the information exchange between the Sigfox network and Network SCHC.
</t>
        <section anchor="dl_ack" numbered="true" toc="include" removeInRFC="false" pn="section-3.3.1">
          <name slugifiedName="name-schc-ack-on-downlink">SCHC ACK on Downlink</name>
          <t indent="0" pn="section-3.3.1-1">
As explained previously, Downlink transmissions are driven by devices and can only take place following a specific Uplink transmission that indicates and allows a following Downlink opportunity.
For this reason, when SCHC bidirectional services are used (e.g., ACK-on-Error fragmentation mode), the SCHC protocol implementation needs to consider the times when a Downlink message
(e.g., SCHC Acknowledgement (ACK)) can be sent and/or received.
</t>
          <t indent="0" pn="section-3.3.1-2">
For the Uplink ACK-on-Error fragmentation mode, a Downlink opportunity <bcp14>MUST</bcp14> be indicated by the last fragment of every window, which is signalled by a specific value of the Fragment Compressed Number (FCN) value, i.e., FCN = All-0 or FCN = All-1. The FCN is the tile index in a specific window. The combination of the FCN and the window number uniquely identifies a SCHC Fragment, as explained in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>.
    The device sends the fragments in sequence and, after
transmitting FCN = All-0 or FCN = All-1, it opens up a reception opportunity. The Network SCHC can then decide to respond at that opportunity (or wait for a further one) with a SCHC ACK, indicating that there are missing fragments from the current or previous windows. If there is no SCHC ACK to be sent, or if the Network decides to wait for a further Downlink transmission opportunity, then no
Downlink transmission takes place at that opportunity and the Uplink transmissions continue after a timeout.
   Intermediate SCHC Fragments with FCNs that are different from All-0 or All-1 <bcp14>MUST NOT</bcp14> use the Downlink request flag to request a SCHC ACK.
</t>
        </section>
      </section>
      <section anchor="schc-rules" numbered="true" toc="include" removeInRFC="false" pn="section-3.4">
        <name slugifiedName="name-schc-rules">SCHC Rules</name>
        <t indent="0" pn="section-3.4-1">
The RuleID <bcp14>MUST</bcp14> be included in the SCHC header. The total number of Rules to be used directly affects the RuleID field size, and therefore
the total size of the fragmentation header. For this reason, it is <bcp14>RECOMMENDED</bcp14> to keep the number of Rules that are defined for a specific device to the minimum possible.
    Large RuleID sizes (and thus larger fragmentation headers) are acceptable for devices without significant energy constraints (e.g., a sensor that is powered by the electricity grid).
</t>
        <t indent="0" pn="section-3.4-2">
RuleIDs can be used to differentiate data traffic classes (e.g.,  QoS, control vs. data, etc.) and data sessions.
They can also be used to interleave simultaneous fragmentation sessions between a device and the Network.
</t>
      </section>
      <section anchor="Frag" numbered="true" toc="include" removeInRFC="false" pn="section-3.5">
        <name slugifiedName="name-fragmentation">Fragmentation</name>
        <t indent="0" pn="section-3.5-1">
The SCHC specification <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/> defines a generic fragmentation functionality that
allows sending data packets or files larger than the maximum size of a Sigfox payload. The functionality also defines a mechanism to reliably send multiple messages by allowing to selectively resend any lost fragments.</t>
        <t indent="0" pn="section-3.5-2">
The SCHC fragmentation supports several modes of operation. These modes have different advantages and disadvantages, depending 
on the specifics of the underlying LPWAN technology and application use case. This section describes how the SCHC fragmentation functionality 
should optimally be implemented when used over a Sigfox LPWAN for the most typical use case applications.</t>
        <t indent="0" pn="section-3.5-3">As described in <xref target="RFC8724" format="default" sectionFormat="of" section="8.2.3" derivedLink="https://rfc-editor.org/rfc/rfc8724#section-8.2.3" derivedContent="RFC8724"/>, the integrity of the fragmentation-reassembly process of a SCHC Packet <bcp14>MUST</bcp14> be 
checked at the receiver end. Since only Uplink/Downlink messages/fragments that have passed the Sigfox CRC-check are delivered to the Network/Sigfox Device SCHC C/D + F/R,
integrity can be guaranteed when no consecutive messages are missing from the sequence and all FCN bitmaps are complete.  With this functionality
in mind, and in order to save protocol and processing overhead, the use of a Reassembly Check Sequence (RCS), as described in 
<xref target="all-1-behaviour" format="default" sectionFormat="of" derivedContent="Section 3.5.1.5"/>, <bcp14>MUST</bcp14> be used.

</t>
        <section anchor="uplink-fragmentation" numbered="true" toc="include" removeInRFC="false" pn="section-3.5.1">
          <name slugifiedName="name-uplink-fragmentation">Uplink Fragmentation</name>
          <t indent="0" pn="section-3.5.1-1">Sigfox Uplink transmissions are completely asynchronous and take place in any random frequency of the allowed Uplink bandwidth allocation.
In addition, devices may go to deep sleep mode and then wake up and transmit whenever there is a need to send information to the Network, as there is no need to perform any Network attachment, synchronization, or other procedures before transmitting a data packet.
          </t>
          <t indent="0" pn="section-3.5.1-2">Since Uplink transmissions are asynchronous, a SCHC Fragment can be transmitted at any given time by the device. Sigfox Uplink messages
are fixed in size, and as described in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/>, they can carry a payload of 0-12 bytes (0-96 bits). Hence, a single SCHC Tile size, per fragmentation 
mode, can be defined so that every Sigfox message always carries one SCHC Tile.</t>
          <t indent="0" pn="section-3.5.1-3">When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC Compound ACK defined in <xref target="RFC9441" format="default" sectionFormat="of" derivedContent="RFC9441"/> <bcp14>MUST</bcp14> be used in the Downlink responses.</t>
          <section anchor="schc_sender_abort" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.1">
            <name slugifiedName="name-schc-sender-abort">SCHC Sender-Abort</name>
            <t indent="0" pn="section-3.5.1.1-1">As defined in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, a SCHC Sender-Abort can be triggered when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK_REQUESTS.
In the case of SCHC over Sigfox, a SCHC Sender-Abort <bcp14>MUST</bcp14> be sent if the number of repeated All-1s sent in sequence, without a Compound ACK reception in between, is greater than or equal to MAX_ACK_REQUESTS.
</t>
          </section>
          <section anchor="schc_receiver_abort" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.2">
            <name slugifiedName="name-schc-receiver-abort">SCHC Receiver-Abort</name>
            <t indent="0" pn="section-3.5.1.2-1">As defined in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, a SCHC Receiver-Abort is triggered when the receiver has no RuleID and DTag pairs available for a new session.
In the case of this profile, a SCHC Receiver-Abort <bcp14>MUST</bcp14> be sent if, for a single device, all the RuleIDs are being processed by the receiver (i.e., have an active session)
at a certain time and a new one is requested or if the RuleID of the fragment is not valid.</t>
            <t indent="0" pn="section-3.5.1.2-2">A SCHC Receiver-Abort <bcp14>MUST</bcp14> be triggered when the Inactivity Timer expires. </t>
            <t indent="0" pn="section-3.5.1.2-3">MAX_ACK_REQUESTS can be increased when facing high error rates. </t>
            <t indent="0" pn="section-3.5.1.2-4">Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC Receiver-Abort Downlink message <bcp14>MUST</bcp14> only be sent when there is a Downlink transmission opportunity.</t>
          </section>
          <section anchor="single-byte-schc-header" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.3">
            <name slugifiedName="name-single-byte-schc-header-for">Single-Byte SCHC Header for Uplink Fragmentation</name>
            <section anchor="no-ack-mode" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.3.1">
              <name slugifiedName="name-uplink-no-ack-mode-single-b">Uplink No-ACK Mode: Single-Byte SCHC Header</name>
              <t indent="0" pn="section-3.5.1.3.1-1">Single-byte SCHC Header No-ACK mode <bcp14>MUST</bcp14> be used for transmitting short, non-critical packets that require fragmentation and do not require full reliability.
This mode can be used by Uplink-only devices that do not support Downlink communications or by bidirectional devices when they send non-critical
data.
Note that sending non-critical data by using a reliable fragmentation mode (which is only possible for bidirectional devices) may incur unnecessary overhead. </t>
              <t indent="0" pn="section-3.5.1.3.1-2">Since there are no multiple windows in the No-ACK mode, the W bit is not present.
    However, it <bcp14>MUST</bcp14> use the FCN field to indicate the
size of the data packet. In this sense, the data packet would need to be split into X fragments and, similarly to the other fragmentation modes,
the first transmitted fragment would need to be marked with FCN = X-1. Consecutive fragments <bcp14>MUST</bcp14> be marked with decreasing FCN values, having the 
last fragment marked with FCN = (All-1). Hence, even though the No-ACK mode does not allow recovering missing fragments, it allows implicitly indicating 
the size of the expected packet to the Network and hence detects whether all fragments have been received or not at the receiver side.
In case the FCN field is not used to indicate the size of the data packet, the Network can detect whether all fragments have been received or not by using the integrity check.
              </t>
              <t indent="0" pn="section-3.5.1.3.1-3">When using the Single-byte SCHC Header for Uplink fragmentation, the
	      fragmentation header <bcp14>MUST</bcp14> be 8 bits in size and is composed as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.3.1-4">
                <li pn="section-3.5.1.3.1-4.1">RuleID size: 3 bits</li>
                <li pn="section-3.5.1.3.1-4.2">DTag size (T): 0 bits</li>
                <li pn="section-3.5.1.3.1-4.3">Fragment Compressed Number (FCN) size (N): 5 bits</li>
              </ul>
              <t indent="0" pn="section-3.5.1.3.1-5">Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.3.1-6">
                <li pn="section-3.5.1.3.1-6.1">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, in the No-ACK mode, the W (window) field is not present. </li>
                <li pn="section-3.5.1.3.1-6.2">Regular tile size: 11 bytes</li>
                <li pn="section-3.5.1.3.1-6.3">All-1 tile size: 0 to 10 bytes</li>
                <li pn="section-3.5.1.3.1-6.4">Inactivity Timer: Application-dependent. The default value is 12 hours.</li>
                <li pn="section-3.5.1.3.1-6.5">RCS size: 5 bits </li>
              </ul>
              <t indent="0" pn="section-3.5.1.3.1-7">The maximum SCHC Packet size is 340 bytes.</t>
              <t indent="0" pn="section-3.5.1.3.1-8"><xref target="UL-NoACK-single-byte" format="default" sectionFormat="of" derivedContent="Section 3.6.1"/> presents SCHC Fragment format examples, and <xref target="no-ack-examples" format="default" sectionFormat="of" derivedContent="Section 5.1"/> provides fragmentation examples, using Single-byte SCHC Header No-ACK mode.</t>
            </section>
            <section anchor="ack-on-error-mode-1" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.3.2">
              <name slugifiedName="name-uplink-ack-on-error-mode-si">Uplink ACK-on-Error Mode: Single-Byte SCHC Header</name>
              <t indent="0" pn="section-3.5.1.3.2-1">ACK-on-Error with a single-byte header <bcp14>MUST</bcp14> be used for short- to medium-sized packets that need to be sent
   reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox transmissions, since it leads to a reduced number of ACKs
   in the lower-capacity Downlink channel. Also, Downlink messages can be sent asynchronously and opportunistically.
    In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK would not allow reliable transmission.
</t>
              <t indent="0" pn="section-3.5.1.3.2-2">Allowing transmission of packets/files up to 300 bytes long, the SCHC Uplink fragmentation header size is 8 bits in size and is composed as follows:
</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.3.2-3">
                <li pn="section-3.5.1.3.2-3.1">RuleID size: 3 bits</li>
                <li pn="section-3.5.1.3.2-3.2">DTag size (T): 0 bits</li>
                <li pn="section-3.5.1.3.2-3.3">Window index (W) size (M): 2 bits </li>
                <li pn="section-3.5.1.3.2-3.4">Fragment Compressed Number (FCN) size (N): 3 bits</li>
              </ul>
              <t indent="0" pn="section-3.5.1.3.2-4">Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.3.2-5">
                <li pn="section-3.5.1.3.2-5.1">MAX_ACK_REQUESTS: 5</li>
                <li pn="section-3.5.1.3.2-5.2">WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)</li>
                <li pn="section-3.5.1.3.2-5.3">Regular tile size: 11 bytes</li>
                <li pn="section-3.5.1.3.2-5.4">All-1 tile size: 0 to 10 bytes</li>
                <li pn="section-3.5.1.3.2-5.5">Retransmission Timer: Application-dependent. The default value is 12 hours.</li>
                <li pn="section-3.5.1.3.2-5.6">Inactivity Timer: Application-dependent. The default value is 12 hours.</li>
                <li pn="section-3.5.1.3.2-5.7">RCS size: 3 bits</li>
              </ul>
              <t indent="0" pn="section-3.5.1.3.2-6"><xref target="UL-ACKoE-single-byte" format="default" sectionFormat="of" derivedContent="Section 3.6.2"/> presents SCHC Fragment format examples, and <xref target="ack-on-error-examples-1B-header" format="default" sectionFormat="of" derivedContent="Section 5.2"/> provides fragmentation examples, using ACK-on-Error with a single-byte header.</t>
            </section>
          </section>
          <section anchor="two-byte-schc-header" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.4">
            <name slugifiedName="name-two-byte-schc-header-for-up">Two-Byte SCHC Header for Uplink Fragmentation</name>
            <t indent="0" pn="section-3.5.1.4-1">ACK-on-Error with a two-byte header <bcp14>MUST</bcp14> be used for medium- to large-sized packets that need to be sent
   reliably.  ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox, since it
   leads to a reduced number of ACKs in the lower-capacity Downlink
   channel. Also, Downlink messages can be sent asynchronously and
   opportunistically. In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK would not allow reliable transmission.
</t>
            <section anchor="ack-on-error-mode-2" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.4.1">
              <name slugifiedName="name-uplink-ack-on-error-mode-tw">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1</name>
              <t indent="0" pn="section-3.5.1.4.1-1">In order to allow transmission of medium to large packets/files up to 480 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.4.1-2">
                <li pn="section-3.5.1.4.1-2.1">RuleID size: 6 bits</li>
                <li pn="section-3.5.1.4.1-2.2">DTag size (T): 0 bits</li>
                <li pn="section-3.5.1.4.1-2.3">Window index (W) size (M): 2 bits </li>
                <li pn="section-3.5.1.4.1-2.4">Fragment Compressed Number (FCN) size (N): 4 bits</li>
                <li pn="section-3.5.1.4.1-2.5">RCS size: 4 bits</li>
              </ul>
              <t indent="0" pn="section-3.5.1.4.1-3">Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.4.1-4">
                <li pn="section-3.5.1.4.1-4.1">MAX_ACK_REQUESTS: 5</li>
                <li pn="section-3.5.1.4.1-4.2">WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)</li>
                <li pn="section-3.5.1.4.1-4.3">Regular tile size: 10 bytes</li>
                <li pn="section-3.5.1.4.1-4.4">All-1 tile size: 1 to 10 bytes</li>
                <li pn="section-3.5.1.4.1-4.5">Retransmission Timer: Application-dependent. The default value is 12 hours.</li>
                <li pn="section-3.5.1.4.1-4.6">Inactivity Timer: Application-dependent. The default value is 12 hours.</li>
              </ul>
              <t indent="0" pn="section-3.5.1.4.1-5">Note that WINDOW_SIZE is limited to 12. This is because 4 windows (M = 2) with bitmaps of size 12 can be fitted in a
single SCHC Compound ACK.</t>
              <t indent="0" pn="section-3.5.1.4.1-6"><xref target="UL-ACKoE-two-byte-opt-1" format="default" sectionFormat="of" derivedContent="Section 3.6.3"/> presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 1.</t>
            </section>
            <section anchor="ack-on-error-mode-3" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.4.2">
              <name slugifiedName="name-uplink-ack-on-error-mode-two">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2</name>
              <t indent="0" pn="section-3.5.1.4.2-1">In order to allow transmission of very large packets/files up to 2400 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.4.2-2">
                <li pn="section-3.5.1.4.2-2.1">RuleID size: 8 bits</li>
                <li pn="section-3.5.1.4.2-2.2">DTag size (T): 0 bits</li>
                <li pn="section-3.5.1.4.2-2.3">Window index (W) size (M): 3 bits </li>
                <li pn="section-3.5.1.4.2-2.4">Fragment Compressed Number (FCN) size (N): 5 bits</li>
                <li pn="section-3.5.1.4.2-2.5">RCS size: 5 bits</li>
              </ul>
              <t indent="0" pn="section-3.5.1.4.2-3">Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:</t>
              <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.1.4.2-4">
                <li pn="section-3.5.1.4.2-4.1">MAX_ACK_REQUESTS: 5</li>
                <li pn="section-3.5.1.4.2-4.2">WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</li>
                <li pn="section-3.5.1.4.2-4.3">Regular tile size: 10 bytes</li>
                <li pn="section-3.5.1.4.2-4.4">All-1 tile size: 0 to 9 bytes</li>
                <li pn="section-3.5.1.4.2-4.5">Retransmission Timer: Application-dependent. The default value is 12 hours.</li>
                <li pn="section-3.5.1.4.2-4.6">Inactivity Timer: Application-dependent. The default value is 12 hours.</li>
              </ul>
              <t indent="0" pn="section-3.5.1.4.2-5"><xref target="UL-ACKoE-two-byte" format="default" sectionFormat="of" derivedContent="Section 3.6.4"/> presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 2.</t>
            </section>
          </section>
          <section anchor="all-1-behaviour" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.5.1.5">
            <name slugifiedName="name-all-1-schc-fragment-and-rcs">All-1 SCHC Fragment and RCS Behavior</name>
            <t indent="0" pn="section-3.5.1.5-1">For ACK-on-Error, as defined in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, it is expected that the last SCHC Fragment of the last window will always be delivered 
with an All-1 FCN. Since this last window may not be full (i.e., it may be composed of fewer than WINDOW_SIZE fragments), an All-1 fragment
may follow a value of FCN higher than 1 (0b01). In this case, the receiver cannot determine from the FCN values alone
whether there are or are not any missing fragments right before the All-1 fragment.
</t>
            <t indent="0" pn="section-3.5.1.5-2">For Rules where the number of fragments in the last window is unknown, an RCS field <bcp14>MUST</bcp14> be used, indicating the number of fragments 
in the last window, including the All-1. With this RCS value, the receiver can detect if there are missing fragments before the All-1 and hence
construct the corresponding SCHC ACK Bitmap accordingly and send it in response to the All-1. 
</t>
          </section>
        </section>
        <section anchor="downlink-fragmentation" numbered="true" toc="include" removeInRFC="false" pn="section-3.5.2">
          <name slugifiedName="name-downlink-fragmentation">Downlink Fragmentation</name>
          <t indent="0" pn="section-3.5.2-1">In some LPWAN technologies, as part of energy-saving techniques, Downlink transmission is only possible immediately after an Uplink
transmission. This allows the device to go in a very deep sleep mode and preserve battery without the need to listen to any information 
from the Network. This is the case for Sigfox-enabled devices, which can only listen to Downlink communications after performing an
Uplink transmission and requesting a Downlink.</t>
          <t indent="0" pn="section-3.5.2-2">When there are fragments to be transmitted in the Downlink, an Uplink message is required to trigger the Downlink communication.
In order to avoid a potentially high delay for fragmented datagram transmission in the Downlink, the fragment receiver <bcp14>MAY</bcp14> perform an
Uplink transmission as soon as possible after reception of a Downlink fragment that is not the last one. Such an Uplink transmission
<bcp14>MAY</bcp14> be triggered by sending a SCHC message, such as a SCHC ACK. However, other data messages can equally be used to trigger Downlink
communications.
The fragment receiver <bcp14>MUST</bcp14> send an Uplink transmission (e.g., empty message) and request a Downlink every 24 hours when no SCHC session is started. Whether this Uplink transmission is used (and the transmission rate, if used) depends on application-specific requirements.
</t>
          <t indent="0" pn="section-3.5.2-3">Sigfox Downlink messages are fixed in size, and as described in <xref target="RFC8376" format="default" sectionFormat="of" derivedContent="RFC8376"/> they can carry a payload of 0-8 bytes (0-64 bits). Hence, a
single SCHC Tile size per mode can be defined so that every Sigfox message always carries one SCHC Tile. 
</t>
          <t indent="0" pn="section-3.5.2-4">For reliable Downlink fragment transmission, the ACK-Always mode <bcp14>SHOULD</bcp14> be used.
Note that ACK-on-Error does not guarantee Uplink feedback (since no SCHC ACK will be sent when no errors occur in a window), and No-ACK would not allow reliable transmission.</t>
          <t indent="0" pn="section-3.5.2-5">The SCHC Downlink fragmentation header size is 8 bits in size and is composed as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.2-6">
            <li pn="section-3.5.2-6.1">RuleID size: 3 bits</li>
            <li pn="section-3.5.2-6.2">DTag size (T): 0 bits</li>
            <li pn="section-3.5.2-6.3">Window index (W) size (M): 0 bits </li>
            <li pn="section-3.5.2-6.4">Fragment Compressed Number (FCN) size (N): 5 bits</li>
          </ul>
          <t indent="0" pn="section-3.5.2-7">Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.5.2-8">
            <li pn="section-3.5.2-8.1">MAX_ACK_REQUESTS: 5</li>
            <li pn="section-3.5.2-8.2">WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</li>
            <li pn="section-3.5.2-8.3">Regular tile size: 7 bytes</li>
            <li pn="section-3.5.2-8.4">All-1 tile size: 0 to 6 bytes</li>
            <li pn="section-3.5.2-8.5">Retransmission Timer: Application-dependent. The default value is 12 hours.</li>
            <li pn="section-3.5.2-8.6">Inactivity Timer: Application-dependent. The default value is 12 hours.</li>
            <li pn="section-3.5.2-8.7">RCS size: 5 bits </li>
          </ul>
        </section>
      </section>
      <section anchor="schc-sigfox-message-formats" numbered="true" toc="include" removeInRFC="false" pn="section-3.6">
        <name slugifiedName="name-schc-over-sigfox-f-r-messag">SCHC over Sigfox F/R Message Formats</name>
        <t indent="0" pn="section-3.6-1">This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK 
defined in <xref target="RFC9441" format="default" sectionFormat="of" derivedContent="RFC9441"/>), and SCHC Abort used in SCHC over Sigfox.</t>
        <section anchor="UL-NoACK-single-byte" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.1">
          <name slugifiedName="name-uplink-no-ack-mode-single-by">Uplink No-ACK Mode: Single-Byte SCHC Header</name>
          <section anchor="no-ack-regular-1byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.1.1">
            <name slugifiedName="name-regular-schc-fragment">Regular SCHC Fragment</name>
            <t indent="0" pn="section-3.6.1.1-1"><xref target="no-ack-reg-1byte-frag" format="default" sectionFormat="of" derivedContent="Figure 3"/> shows an example of a Regular SCHC Fragment for all fragments except the last one.
	    As tiles are 11 bytes in size, padding <bcp14>MUST NOT</bcp14> be added.
The penultimate tile of a SCHC Packet is of regular size.</t>
            <figure anchor="no-ack-reg-1byte-frag" align="left" suppress-title="false" pn="figure-3">
              <name slugifiedName="name-regular-schc-fragment-forma">Regular SCHC Fragment Format for All Fragments except the Last One</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.1.1-2.1">
|- SCHC Fragment Header -|
+------------------------+---------+
|   RuleID   |    FCN    | Payload |
+------------+-----------+---------+
|   3 bits   |  5 bits   | 88 bits |
</artwork>
            </figure>
          </section>
          <section anchor="no-ack-all-1-1byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.1.2">
            <name slugifiedName="name-all-1-schc-fragment">All-1 SCHC Fragment</name>
            <t indent="0" pn="section-3.6.1.2-1"><xref target="no-ack-all-1-1byte" format="default" sectionFormat="of" derivedContent="Figure 4"/> shows an example of the All-1 message.
The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
  Padding <bcp14>MUST NOT</bcp14> be
  added, as the resulting size is a multiple of an L2 Word.</t>
            <t indent="0" pn="section-3.6.1.2-2">
   The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added as padding to complete 2 bytes.
    The payload size of the All-1 message ranges from 0 to 80 bits.
</t>
            <figure anchor="no-ack-all-1-1byte" align="left" suppress-title="false" pn="figure-4">
              <name slugifiedName="name-all-1-schc-message-format-w">All-1 SCHC Message Format with the Last Tile</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.1.2-3.1">
|--------  SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 |  RCS   |  b'000 |   Payload    |
+--------+-----------+--------+--------+--------------+
| 3 bits |  5 bits   | 5 bits | 3 bits | 0 to 80 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.1.2-4">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-1 must be distinguishable from a SCHC Sender-Abort message (with the same RuleID and N values).
The All-1 <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
            <t indent="0" pn="section-3.6.1.2-5">For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.</t>
          </section>
          <section anchor="no-ack-snd-abort-msg-format" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.1.3">
            <name slugifiedName="name-schc-sender-abort-message-f">SCHC Sender-Abort Message Format</name>
            <figure anchor="no-ack-snd-abort-msg" align="left" suppress-title="false" pn="figure-5">
              <name slugifiedName="name-schc-sender-abort-message-fo">SCHC Sender-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.1.3-1.1">
     Sender-Abort
|------ Header ------|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-single-byte" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.2">
          <name slugifiedName="name-uplink-ack-on-error-mode-sin">Uplink ACK-on-Error Mode: Single-Byte SCHC Header</name>
          <section anchor="regular-1byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2.1">
            <name slugifiedName="name-regular-schc-fragment-2">Regular SCHC Fragment</name>
            <t indent="0" pn="section-3.6.2.1-1"><xref target="reg-1byte-frag" format="default" sectionFormat="of" derivedContent="Figure 6"/> shows an example of a Regular SCHC Fragment for all fragments except the last one. 
As tiles are 11 bytes in size, padding <bcp14>MUST NOT</bcp14> be added.</t>
            <figure anchor="reg-1byte-frag" align="left" suppress-title="false" pn="figure-6">
              <name slugifiedName="name-regular-schc-fragment-format">Regular SCHC Fragment Format for All Fragments except the Last One</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.1-2.1">
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    |  FCN   | Payload |
+--------+--------+--------+---------+
| 3 bits | 2 bits | 3 bits | 88 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.2.1-3">The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message). 
The penultimate tile of a SCHC Packet is of regular size.</t>
          </section>
          <section anchor="all-1-1byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2.2">
            <name slugifiedName="name-all-1-schc-fragment-2">All-1 SCHC Fragment</name>
            <t indent="0" pn="section-3.6.2.2-1"><xref target="all-1-1byte" format="default" sectionFormat="of" derivedContent="Figure 7"/> shows an example of the All-1 message. 
The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
Padding <bcp14>MUST NOT</bcp14> be added, as the resulting size is L2-word-multiple.</t>
            <figure anchor="all-1-1byte" align="left" suppress-title="false" pn="figure-7">
              <name slugifiedName="name-all-1-schc-message-format-wi">All-1 SCHC Message Format with the Last Tile</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.2-2.1">
|-------------  SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID |   W    | FCN=ALL-1 |  RCS   |b'00000 |   Payload    |
+--------+--------+-----------+--------+--------+--------------+
| 3 bits | 2 bits |  3 bits   | 3 bits | 5 bits | 0 to 80 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.2.2-3">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-1 must be distinguishable from a SCHC Sender-Abort message (with same RuleID, M, and N values).
The All-1 <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
            <t indent="0" pn="section-3.6.2.2-4">For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.</t>
          </section>
          <section anchor="schc-ack-format-1B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2.3">
            <name slugifiedName="name-schc-ack-format">SCHC ACK Format</name>
            <t indent="0" pn="section-3.6.2.3-1"><xref target="success-ack-1byte" format="default" sectionFormat="of" derivedContent="Figure 8"/> shows the SCHC ACK format when all fragments have been correctly received (C=1). 
Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>
            <figure anchor="success-ack-1byte" align="left" suppress-title="false" pn="figure-8">
              <name slugifiedName="name-schc-success-ack-message-fo">SCHC Success ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.3-2.1">
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 3 bits | 2 bits | 1 bit | 58 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.2.3-3">In case SCHC Fragment losses are found in any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK defined in <xref target="RFC9441" format="default" sectionFormat="of" derivedContent="RFC9441"/> <bcp14>MUST</bcp14> be used.
The SCHC Compound ACK message format is shown in <xref target="compound-ack-1byte" format="default" sectionFormat="of" derivedContent="Figure 9"/>.
</t>
            <figure anchor="compound-ack-1byte" align="left" suppress-title="false" pn="figure-9">
              <name slugifiedName="name-schc-compound-ack-message-f">SCHC Compound ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.3-4.1">
|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
+------+--------+-------+--------+...+--------+--------+------+-------+
|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad|
+------+--------+-------+--------+...+--------+--------+------+-------+
|3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.2.3-5">Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="snd-abort-msg-format" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2.4">
            <name slugifiedName="name-schc-sender-abort-message-for">SCHC Sender-Abort Message Format</name>
            <figure anchor="snd-abort-msg" align="left" suppress-title="false" pn="figure-10">
              <name slugifiedName="name-schc-sender-abort-message-form">SCHC Sender-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.4-1.1">
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W=b'11 | FCN=ALL-1 |
+--------+--------+-----------+
| 3 bits | 2 bits |  3 bits   |
		</artwork>
            </figure>
          </section>
          <section anchor="rcv-abort-msg-format" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.2.5">
            <name slugifiedName="name-schc-receiver-abort-message">SCHC Receiver-Abort Message Format</name>
            <figure anchor="rcv-abort-msg" align="left" suppress-title="false" pn="figure-11">
              <name slugifiedName="name-schc-receiver-abort-message-">SCHC Receiver-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.2.5-1.1">
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 |  b'11 |  0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 3 bits | 2 bits | 1 bit | 2 bit |  8 bit          | 48 bits |
          next L2 Word boundary -&gt;| &lt;-- L2 Word --&gt; |	
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-two-byte-opt-1" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.3">
          <name slugifiedName="name-uplink-ack-on-error-mode-two-">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1</name>
          <section anchor="opt-1-regular-2byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3.1">
            <name slugifiedName="name-regular-schc-fragment-3">Regular SCHC Fragment</name>
            <t indent="0" pn="section-3.6.3.1-1"><xref target="opt-1-reg-2byte-frag" format="default" sectionFormat="of" derivedContent="Figure 12"/> shows an example of a Regular SCHC Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>
            <figure anchor="opt-1-reg-2byte-frag" align="left" suppress-title="false" pn="figure-12">
              <name slugifiedName="name-regular-schc-fragment-format-">Regular SCHC Fragment Format for All Fragments except the Last One</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.1-2.1">
|------- SCHC Fragment Header ------|
+-----------------------------------+---------+
| RuleID |    W   |  FCN   | b'0000 | Payload |
+--------+--------+--------+--------+---------+
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.3.1-3">The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).</t>
          </section>
          <section anchor="opt-1-all-1-2B-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3.2">
            <name slugifiedName="name-all-1-schc-fragment-3">All-1 SCHC Fragment</name>
            <t indent="0" pn="section-3.6.3.2-1"><xref target="opt-1-all-1-2B" format="default" sectionFormat="of" derivedContent="Figure 13"/> shows an example of the All-1 message.
The All-1 message <bcp14>MUST</bcp14> contain the last tile of the SCHC Packet.</t>
            <t indent="0" pn="section-3.6.3.2-2">The All-1 message Fragment Header contains an RCS of 4 bits to complete the two-byte size.
   The size of the last tile ranges from 8 to 80 bits.</t>
            <figure anchor="opt-1-all-1-2B" align="left" suppress-title="false" pn="figure-13">
              <name slugifiedName="name-all-1-schc-message-format-wit">All-1 SCHC Message Format with the Last Tile</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.2-3.1">
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID |    W   | FCN=ALL-1 |  RCS   |    Payload   |
+--------+--------+-----------+--------+--------------+
| 6 bits | 2 bits |  4 bits   | 4 bits | 8 to 80 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.3.2-4">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values).
The All-1 <bcp14>MUST</bcp14> have the last tile of the SCHC Packet that <bcp14>MUST</bcp14> be at least 1 byte.
The SCHC Sender-Abort message header size is 2 bytes with no padding bits.</t>
            <t indent="0" pn="section-3.6.3.2-5">For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message <bcp14>MUST</bcp14> be 2 bytes (only header with no padding).
This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.</t>
          </section>
          <section anchor="opt-1-schc-ack-format-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3.3">
            <name slugifiedName="name-schc-ack-format-2">SCHC ACK Format</name>
            <t indent="0" pn="section-3.6.3.3-1"> <xref target="opt-1-success-ack-2B" format="default" sectionFormat="of" derivedContent="Figure 14"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>
            <figure anchor="opt-1-success-ack-2B" align="left" suppress-title="false" pn="figure-14">
              <name slugifiedName="name-schc-success-ack-message-for">SCHC Success ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.3-2.1">
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 6 bits | 2 bits | 1 bit | 55 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.3.3-3">The SCHC Compound ACK message <bcp14>MUST</bcp14> be used in case SCHC Fragment losses are found in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in <xref target="opt-1-schc-compound-ack-2B" format="default" sectionFormat="of" derivedContent="Figure 15"/>.
The SCHC Compound ACK can report up to 4 windows with losses, as shown in <xref target="opt-1-schc-compound-ack-2B-example-losses-all-windows" format="default" sectionFormat="of" derivedContent="Figure 16"/>.</t>
            <t indent="0" pn="section-3.6.3.3-4">When sent in the Downlink, the SCHC Compound ACK <bcp14>MUST</bcp14> be 0 padded (padding bits must be 0) to complement the 64 bits required by the Sigfox payload.</t>
            <figure anchor="opt-1-schc-compound-ack-2B" align="left" suppress-title="false" pn="figure-15">
              <name slugifiedName="name-schc-compound-ack-message-fo">SCHC Compound ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.3-5.1">
|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
+--------+------+-------+--------+...+------+--------+------+-------+
| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad|
+--------+------+-------+--------+...+------+--------+------+-------+
| 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.3.3-6">Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</t>
            <figure anchor="opt-1-schc-compound-ack-2B-example-losses-all-windows" align="left" suppress-title="false" pn="figure-16">
              <name slugifiedName="name-schc-compound-ack-message-for">SCHC Compound ACK Message Format Example with Losses in All Windows</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.3-7.1">
|- SCHC ACK Header -|- W=0 -|      |- W=1 -|...
+------+------+-----+-------+------+-------+...
|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...
+------+------+-----+-------+------+-------+...
|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...

            ...       |- W=2 -|      |- W=3 -|
            ...+------+-------+------+-------+---+
            ...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
            ...+------+-------+------+-------+---+
            ...|2 bits|12 bits|2 bits|12 bits|
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.3.3-8">Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="opt-1-snd-abort-msg-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3.4">
            <name slugifiedName="name-schc-sender-abort-message-forma">SCHC Sender-Abort Message Format</name>
            <figure anchor="opt-1-snd-abort-msg-format-2B" align="left" suppress-title="false" pn="figure-17">
              <name slugifiedName="name-schc-sender-abort-message-format">SCHC Sender-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.4-1.1">
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 6 bits | 2 bits |  4 bits   |
</artwork>
            </figure>
          </section>
          <section anchor="opt-1-rcv-abort-msg-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.3.5">
            <name slugifiedName="name-schc-receiver-abort-message-f">SCHC Receiver-Abort Message Format</name>
            <figure anchor="opt-1-rcv-abort-msg-format-2B" align="left" suppress-title="false" pn="figure-18">
              <name slugifiedName="name-schc-receiver-abort-message-fo">SCHC Receiver-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.3.5-1.1">
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 |  0x7F |  0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 6 bits | 2 bits | 1 bit | 7 bit |  8 bit          | 40 bits |
          next L2 Word boundary -&gt;| &lt;-- L2 Word --&gt; |
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-two-byte" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.4">
          <name slugifiedName="name-uplink-ack-on-error-mode-two-b">Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2</name>
          <section anchor="opt-2regular-2byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4.1">
            <name slugifiedName="name-regular-schc-fragment-4">Regular SCHC Fragment</name>
            <t indent="0" pn="section-3.6.4.1-1"><xref target="opt-2-reg-2byte-frag" format="default" sectionFormat="of" derivedContent="Figure 19"/> shows an example of a Regular SCHC Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>
            <figure anchor="opt-2-reg-2byte-frag" align="left" suppress-title="false" pn="figure-19">
              <name slugifiedName="name-regular-schc-fragment-format-f">Regular SCHC Fragment Format for All Fragments except the Last One</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.1-2.1">
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    | FCN    | Payload |
+--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.4.1-3">The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).</t>
          </section>
          <section anchor="opt-2-all-1-2B-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4.2">
            <name slugifiedName="name-all-1-schc-fragment-4">All-1 SCHC Fragment</name>
            <t indent="0" pn="section-3.6.4.2-1"><xref target="opt-2-all-1-2B" format="default" sectionFormat="of" derivedContent="Figure 20"/> shows an example of the All-1 message.
The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</t>
            <t indent="0" pn="section-3.6.4.2-2">The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete a 3-byte Fragment Header.
   The size of the last tile, if present, ranges from 8 to 72 bits.</t>
            <figure anchor="opt-2-all-1-2B" align="left" suppress-title="false" pn="figure-20">
              <name slugifiedName="name-all-1-schc-message-format-with">All-1 SCHC Message Format with the Last Tile</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.2-3.1">
|-------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID |    W   | FCN=ALL-1 |  RCS   | b'000  |    Payload   |
+--------+--------+-----------+--------+--------+--------------+
| 8 bits | 3 bits |  5 bits   | 5 bits | 3 bits | 8 to 72 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.4.2-4">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values).
The SCHC Sender-Abort message header size is 2 bytes with no padding bits.</t>
            <t indent="0" pn="section-3.6.4.2-5">For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message <bcp14>MUST</bcp14> be 2 bytes (only header with no padding).
This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.</t>
          </section>
          <section anchor="opt-2-schc-ack-format-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4.3">
            <name slugifiedName="name-schc-ack-format-3">SCHC ACK Format</name>
            <t indent="0" pn="section-3.6.4.3-1"> <xref target="opt-2-success-ack-2B" format="default" sectionFormat="of" derivedContent="Figure 21"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>
            <figure anchor="opt-2-success-ack-2B" align="left" suppress-title="false" pn="figure-21">
              <name slugifiedName="name-schc-success-ack-message-form">SCHC Success ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.3-2.1">
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.4.3-3">The SCHC Compound ACK message <bcp14>MUST</bcp14> be used in case SCHC Fragment losses are found in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in <xref target="opt-2-schc-compound-ack-2B" format="default" sectionFormat="of" derivedContent="Figure 22"/>.
The SCHC Compound ACK can report up to 3 windows with losses.</t>
            <t indent="0" pn="section-3.6.4.3-4">When sent in the Downlink, the SCHC Compound ACK <bcp14>MUST</bcp14> be 0 padded (padding bits must be 0) to complement the 64 bits required by
the Sigfox payload.</t>
            <figure anchor="opt-2-schc-compound-ack-2B" align="left" suppress-title="false" pn="figure-22">
              <name slugifiedName="name-schc-compound-ack-message-form">SCHC Compound ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.3-5.1">
|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
+------+------+-------+--------+...+------+--------+------+-------+
|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000  |b'0-pad|
+------+------+-------+--------+...+------+--------+------+-------+
|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.4.3-6">Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="snd-abort-msg-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4.4">
            <name slugifiedName="name-schc-sender-abort-message-format-2">SCHC Sender-Abort Message Format</name>
            <figure anchor="snd-abort-msg-format-2B" align="left" suppress-title="false" pn="figure-23">
              <name slugifiedName="name-schc-sender-abort-message-format-3">SCHC Sender-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.4-1.1">
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits |  5 bits   |
</artwork>
            </figure>
          </section>
          <section anchor="rcv-abort-msg-2B" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.4.5">
            <name slugifiedName="name-schc-receiver-abort-message-for">SCHC Receiver-Abort Message Format</name>
            <figure anchor="rcv-abort-msg-format-2B" align="left" suppress-title="false" pn="figure-24">
              <name slugifiedName="name-schc-receiver-abort-message-form">SCHC Receiver-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.4.5-1.1">
|-- Receiver-Abort Header -|
+-----------------------------------+-----------------+---------+
| RuleID | W=b'111 | C=b'1 | b'1111 |  0xFF (all 1's) | b'0-pad |
+--------+---------+-------+--------+-----------------+---------+
| 8 bits |  3 bits | 1 bit | 4 bit  |  8 bit          | 40 bits |
            next L2 Word boundary -&gt;| &lt;-- L2 Word --&gt; |
</artwork>
            </figure>
          </section>
        </section>
        <section anchor="DL-ACK-Always" numbered="true" toc="include" removeInRFC="false" pn="section-3.6.5">
          <name slugifiedName="name-downlink-ack-always-mode-si">Downlink ACK-Always Mode: Single-Byte SCHC Header</name>
          <section anchor="DL-ACK-Always-1byte-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5.1">
            <name slugifiedName="name-regular-schc-fragment-5">Regular SCHC Fragment</name>
            <t indent="0" pn="section-3.6.5.1-1"><xref target="DL-ACK-Always-1byte-frag" format="default" sectionFormat="of" derivedContent="Figure 25"/> shows an example of a Regular SCHC Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>
            <figure anchor="DL-ACK-Always-1byte-frag" align="left" suppress-title="false" pn="figure-25">
              <name slugifiedName="name-regular-schc-fragment-format-fo">Regular SCHC Fragment Format for All Fragments except the Last One</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.1-2.1">
   SCHC Fragment
|--    Header   --|
+-----------------+---------+
| RuleID |  FCN   | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.5.1-3">The SCHC ACK <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver.
As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message).</t>
          </section>
          <section anchor="DL-ACK-Always-1B-all-1-schc-fragment" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5.2">
            <name slugifiedName="name-all-1-schc-fragment-5">All-1 SCHC Fragment</name>
            <t indent="0" pn="section-3.6.5.2-1"><xref target="DL-ACK-Always-1B-all-1" format="default" sectionFormat="of" derivedContent="Figure 26"/> shows an example of the All-1 message.
The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</t>
            <t indent="0" pn="section-3.6.5.2-2">The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete a 2-byte Fragment Header.
   The size of the last tile, if present, ranges from 8 to 48 bits.</t>
            <figure anchor="DL-ACK-Always-1B-all-1" align="left" suppress-title="false" pn="figure-26">
              <name slugifiedName="name-all-1-schc-message-format-with-">All-1 SCHC Message Format with the Last Tile</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.2-3.1">
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 |  RCS   | b'000  |    Payload   |
+--------+-----------+--------+--------+--------------+
| 3 bits |  5 bits   | 5 bits | 3 bits | 0 to 48 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.5.2-4">As per <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/>, the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID and N values).
The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
            <t indent="0" pn="section-3.6.5.2-5">For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header with no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes.</t>
          </section>
          <section anchor="DL-ACK-Always-1B-schc-ack-format" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5.3">
            <name slugifiedName="name-schc-ack-format-4">SCHC ACK Format</name>
            <t indent="0" pn="section-3.6.5.3-1"> <xref target="DL-ACK-Always-1B-success-ack" format="default" sectionFormat="of" derivedContent="Figure 27"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding <bcp14>MUST</bcp14> be added to complete 2 bytes.</t>
            <figure anchor="DL-ACK-Always-1B-success-ack" align="left" suppress-title="false" pn="figure-27">
              <name slugifiedName="name-schc-success-ack-message-forma">SCHC Success ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.3-2.1">
     SCHC ACK
|--   Header   --|
+----------------+---------+
| RuleID | C=b'1 | b'0-pad |
+--------+-------+---------+
| 3 bits | 1 bit |  4 bits |
</artwork>
            </figure>
            <t indent="0" pn="section-3.6.5.3-3">
The SCHC ACK message format is shown in <xref target="DL-ACK-Always-1B-schc-compound-ack" format="default" sectionFormat="of" derivedContent="Figure 28"/>.
</t>
            <figure anchor="DL-ACK-Always-1B-schc-compound-ack" align="left" suppress-title="false" pn="figure-28">
              <name slugifiedName="name-schc-compound-ack-message-forma">SCHC Compound ACK Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.3-4.1">
|---- SCHC ACK Header ----|
+--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits|  5 bits |
</artwork>
            </figure>
          </section>
          <section anchor="DL-ACK-Always-1B-snd-abort-msg" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5.4">
            <name slugifiedName="name-schc-sender-abort-message-format-4">SCHC Sender-Abort Message Format</name>
            <figure anchor="DL-ACK-Always-1B-snd-abort-msg-format" align="left" suppress-title="false" pn="figure-29">
              <name slugifiedName="name-schc-sender-abort-message-format-5">SCHC Sender-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.4-1.1">
     Sender-Abort
|----   Header   ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |
</artwork>
            </figure>
          </section>
          <section anchor="DL-ACK-Always-1B-rcv-abort-msg" numbered="true" toc="exclude" removeInRFC="false" pn="section-3.6.5.5">
            <name slugifiedName="name-schc-receiver-abort-message-forma">SCHC Receiver-Abort Message Format</name>
            <figure anchor="DL-ACK-Always-1B-rcv-abort-msg-format" align="left" suppress-title="false" pn="figure-30">
              <name slugifiedName="name-schc-receiver-abort-message-format">SCHC Receiver-Abort Message Format</name>
              <artwork name="" type="" align="center" alt="" pn="section-3.6.5.5-1.1">
  Receiver-Abort
|---  Header  ---|
+----------------+--------+-----------------+
| RuleID | C=b'1 | b'1111 |  0xFF (all 1's) |
+--------+-------+--------+-----------------+
| 3 bits | 1 bit | 4 bit  |  8 bit          |
</artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="padding" numbered="true" toc="include" removeInRFC="false" pn="section-3.7">
        <name slugifiedName="name-padding">Padding</name>
        <t indent="0" pn="section-3.7-1">The Sigfox payload fields have different characteristics in Uplink and Downlink.</t>
        <t indent="0" pn="section-3.7-2">Uplink messages can contain a payload size from 0 to 12 bytes. The Sigfox radio protocol allows sending zero bits,
one single bit of information for binary applications (e.g., status), or an integer number of bytes.
Therefore, for 2 or more bits of payload, it is required to add padding to the next integer number of bytes. The reason for this 
flexibility is to optimize transmission time and hence save battery consumption at the device.</t>
        <t indent="0" pn="section-3.7-3">On the other hand, Downlink frames have a fixed length. The payload length <bcp14>MUST</bcp14> be 64 bits (i.e., 8 bytes). Hence, if less
information bits are to be transmitted, padding <bcp14>MUST</bcp14> be used with bits equal to 0.
    The receiver <bcp14>MUST</bcp14> remove the added padding bits before the SCHC reassembly process.</t>
      </section>
    </section>
    <section anchor="fragmentation-rules-examples" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-fragmentation-rules-example">Fragmentation Rules Examples</name>
      <t indent="0" pn="section-4-1">This section provides an example of RuleID configuration for interoperability between the F/R modes presented in this document.
    Note that the RuleID space for Uplink F/R is different than the one for Downlink F/R; therefore, this section is divided in two subsections: Rules for Uplink fragmentation and Rules for Downlink fragmentation.
</t>
      <t indent="0" pn="section-4-2">For Uplink F/R, multiple header lengths were described in <xref target="Frag" format="default" sectionFormat="of" derivedContent="Section 3.5"/>.
    All of them are part of the SCHC over Sigfox Profile and offer not only low protocol overhead for small payloads (single byte header) but also extensibility to transport larger payloads with more overhead (2-byte header, Options 1 and 2).
    The usage of the RuleID space for each header length is an implementation choice, but we provide an example of it in the following section.
    This illustrates implementation choices made in order to 1) identify the different header length and 2) finally parse the RuleID field to identify the RuleID value and execute the associated treatment.
</t>
      <section anchor="uplink-fragmentation-rules-examples" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-uplink-fragmentation-rules-">Uplink Fragmentation Rules Examples</name>
        <t indent="0" pn="section-4.1-1">
      The RuleID field for Uplink F/R modes has different sizes depending on the header length.
In order to identify the header length and then the value of the RuleID, the RuleID field
 is interpreted as follows:
        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2">
          <li pn="section-4.1-2.1">The RuleID field is the first one to be parsed in the SCHC header, starting from the leftmost bits.</li>
          <li pn="section-4.1-2.2">
            <t indent="0" pn="section-4.1-2.2.1">For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits is expected:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2.2.2">
              <li pn="section-4.1-2.2.2.1">If the first 3 leftmost bits have a value different than 0b'111, then it signals a Single-byte SCHC Header F/R mode.</li>
              <li pn="section-4.1-2.2.2.2">If their value is 0b'111, then it signals a Two-byte SCHC Header F/R mode.
              </li>
            </ul>
          </li>
          <li pn="section-4.1-2.3">
            <t indent="0" pn="section-4.1-2.3.1">For Single-byte SCHC Header F/R modes:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2.3.2">
              <li pn="section-4.1-2.3.2.1">There are 7 RuleIDs available (with values from 0b'000-0b'110); the RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.</li>
              <li pn="section-4.1-2.3.2.2">This set of Rules is called "standard rules", and it is used to implement Single-byte SCHC Header modes.</li>
              <li pn="section-4.1-2.3.2.3">Each RuleID is associated with a set of properties defining if Uplink F/R is used and which Uplink F/R mode is used. As an example, the RuleID 0b'000 is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and the RuleIDs 0b'001 and 0b'002 are mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header (2 RuleIDs to allow for SCHC Packet interleaving).</li>
            </ul>
          </li>
          <li pn="section-4.1-2.4">
            <t indent="0" pn="section-4.1-2.4.1">For Two-byte SCHC Header F/R modes, at least 6 bits for the RuleID field are expected:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2.4.2">
              <li pn="section-4.1-2.4.2.1">
                <t indent="0" pn="section-4.1-2.4.2.1.1">The 3 first leftmost bits are always 0b'111.</t>
                <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-2.4.2.1.2">
                  <li pn="section-4.1-2.4.2.1.2.1">If the following 3 bits have a different value than 0b'111, then it signals the Two-byte SCHC Header Option 1.</li>
                  <li pn="section-4.1-2.4.2.1.2.2">If the following 3 bits are 0b'111, then it signals the Two-byte SCHC Header Option 2.</li>
                </ul>
              </li>
              <li pn="section-4.1-2.4.2.2">For the Two-byte SCHC Header Option 1, there are 7 RuleIDs available (0b'111000-0b'111110), 0b'111111 being reserved to indicate the Two-byte SCHC Header Option 2. This set of Rules is called "extended rules", and it is used to implement the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1.</li>
              <li pn="section-4.1-2.4.2.3">For the Two-byte SCHC Header Option 2, there are 2 additional bits to parse as the RuleID, so 4 RuleIDs are available (0b'11111100-0b'11111111). This set of Rules is used to cover specific cases that previous RuleIDs do not cover. As an example, RuleID 0b'00111111 is used to transport uncompressed IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 2.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="downlink-fragmentation-rules-examples" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-downlink-fragmentation-rule">Downlink Fragmentation Rules Example</name>
        <t indent="0" pn="section-4.2-1">For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get values in ranges from 0b'000 to 0b'111.</t>
      </section>
    </section>
    <section anchor="sequence-examples" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-fragmentation-sequence-exam">Fragmentation Sequence Examples</name>
      <t indent="0" pn="section-5-1">In this section, some sequence diagrams depict message exchanges for different fragmentation modes and use cases are shown. 
In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carrying a fragment.</t>
      <section anchor="no-ack-examples" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-uplink-no-ack-examples">Uplink No-ACK Examples</name>
        <t indent="0" pn="section-5.1-1">The FCN field indicates the size of the data packet. 
The first fragment is marked with FCN = X-1, where X is the number of fragments the message is split into.
All fragments are marked with decreasing FCN values.
	The last packet fragment is marked with FCN = All-1 (1111). </t>
        <t indent="0" pn="section-5.1-2"><strong>Case No Losses - All fragments are sent and received successfully.</strong></t>
        <figure anchor="UL-No-ACK-NL" align="left" suppress-title="false" pn="figure-31">
          <name slugifiedName="name-uplink-no-ack-no-losses">Uplink No-ACK No-Losses</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.1-3.1">
Sender                     Receiver
  |-------FCN=6,Seq=1--------&gt;|
  |-------FCN=5,Seq=2--------&gt;|
  |-------FCN=4,Seq=3--------&gt;|
  |-------FCN=3,Seq=4--------&gt;|
  |-------FCN=2,Seq=5--------&gt;|
  |-------FCN=1,Seq=6--------&gt;|
  |-------FCN=15,Seq=7-------&gt;| All fragments received
(End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.1-4">When the first SCHC Fragment is received, the receiver can calculate the 
total number of SCHC Fragments that the SCHC Packet is composed of.
For example, if the first fragment is numbered with FCN=6, the receiver can 
expect six more messages/fragments (i.e., with FCN going from 5 downwards and the last fragment with an
FCN equal to 15).</t>
        <t indent="0" pn="section-5.1-5"><strong>Case Losses on Any Fragment except the First</strong></t>
        <figure anchor="UL-No-ACK-L-1" align="left" suppress-title="false" pn="figure-32">
          <name slugifiedName="name-uplink-no-ack-losses-scenar">Uplink No-ACK Losses (Scenario 1)</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.1-6.1">
Sender                     Receiver
  |-------FCN=6,Seq=1--------&gt;|
  |-------FCN=5,Seq=2----X    |
  |-------FCN=4,Seq=3--------&gt;|
  |-------FCN=3,Seq=4--------&gt;|
  |-------FCN=2,Seq=5--------&gt;|
  |-------FCN=1,Seq=6--------&gt;|
  |-------FCN=15,Seq=7-------&gt;| Missing Fragment Unable to reassemble
(End)
</artwork>
        </figure>
      </section>
      <section anchor="ack-on-error-examples-1B-header" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-uplink-ack-on-error-example">Uplink ACK-on-Error Examples: Single-Byte SCHC Header</name>
        <t indent="0" pn="section-5.2-1">The Single-byte SCHC Header ACK-on-Error mode allows sending up to 28 fragments and packet sizes up to
300 bytes. The SCHC Fragments may be delivered asynchronously, and Downlink ACK can be sent opportunistically. </t>
        <t indent="0" pn="section-5.2-2"><strong>Case No Losses</strong></t>
        <t indent="0" pn="section-5.2-3">The Downlink flag must be enabled in the sender Uplink message to allow a Downlink message from the receiver.
The Downlink Enable in the figures shows where the sender <bcp14>MUST</bcp14> enable the Downlink and
	wait for an ACK.</t>
        <figure anchor="UL-ACKoE-NL" align="left" suppress-title="false" pn="figure-33">
          <name slugifiedName="name-uplink-ack-on-error-no-loss">Uplink ACK-on-Error No-Losses</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-4.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2-----&gt;|
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;|
      (no ACK)
          |-----W=1,FCN=6,Seq=8-----&gt;|
          |-----W=1,FCN=5,Seq=9-----&gt;|
          |-----W=1,FCN=4,Seq=10----&gt;|
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| All fragments received
          |&lt;- Compound ACK,W=1,C=1 --| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-5"><strong>Case Fragment Losses in the First Window</strong></t>
        <t indent="0" pn="section-5.2-6">In this case, fragments are lost in the first window (W=0). 
After the first All-0 message arrives, the receiver
leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.</t>
        <t indent="0" pn="section-5.2-7">After the loss fragments from the first window (W=0) are resent, the sender continues 
transmitting the fragments of the following window (W=1) without opening a reception opportunity.
Finally, the All-1 fragment is sent, the Downlink is enabled, and the SCHC ACK is received with C=1.
	Note that the SCHC Compound ACK also uses a Sequence Number. </t>
        <figure anchor="UL-ACKoE-LW1" align="left" suppress-title="false" pn="figure-34">
          <name slugifiedName="name-uplink-ack-on-error-losses-">Uplink ACK-on-Error Losses in the First Window</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-8.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5--X   |                    __
          |-----W=0,FCN=1,Seq=6-----&gt;|                   | W=0
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;| Missing Fragments&lt;- FCN=5,Seq=2
          |&lt;- Compound ACK,W=0,C=0 --| Bitmap:1011011    | FCN=2,Seq=5
          |-----W=0,FCN=5,Seq=9-----&gt;|                    --
          |-----W=0,FCN=2,Seq=10----&gt;|
          |-----W=1,FCN=6,Seq=11----&gt;|
          |-----W=1,FCN=5,Seq=12----&gt;|
          |-----W=1,FCN=4,Seq=13----&gt;|
DL Enable |-----W=1,FCN=7,Seq=14----&gt;| All fragments received
          |&lt;-Compound ACK,W=1,C=1 ---| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-9"><strong>Case Fragment All-0 Lost in the First Window (W=0)</strong></t>
        <t indent="0" pn="section-5.2-10">In this example, the All-0 of the first window (W=0) is lost. Therefore, 
the receiver waits for the next All-0 message of intermediate windows or All-1 message of last window to generate 
the corresponding SCHC ACK, which indicates that the All-0 of window 0 is absent.</t>
        <t indent="0" pn="section-5.2-11">The sender resends the missing All-0 messages (with any other missing 
fragment from window 0) without opening a reception opportunity.</t>
        <figure anchor="UL-ACKoE-LA0W1" align="left" suppress-title="false" pn="figure-35">
          <name slugifiedName="name-uplink-ack-on-error-all-0-l">Uplink ACK-on-Error All-0 Lost in the First Window</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-12.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2-----&gt;|
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;| DL Enable
	  |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8-----&gt;|
          |-----W=1,FCN=5,Seq=9-----&gt;|                    __
          |-----W=1,FCN=4,Seq=10----&gt;|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| Missing Fragment&lt;- FCN=0,Seq=7
          |&lt;-Compound ACK,W=0,C=0 ---| Bitmap:1111110    |__
          |-----W=0,FCN=0,Seq=13----&gt;| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14----&gt;|
          |&lt;-Compound ACK,W=1,C=1 ---| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-13">In the following diagram, besides the All-0, there are other fragment losses in the first window (W=0).</t>
        <figure anchor="UL-ACKoE-LA0FW1" align="left" suppress-title="false" pn="figure-36">
          <name slugifiedName="name-uplink-ack-on-error-all-0-a">Uplink ACK-on-Error All-0 and Other Fragments Lost in the First Window</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-14.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|
DL Enable |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8-----&gt;|
          |-----W=1,FCN=5,Seq=9-----&gt;|                    __
          |-----W=1,FCN=4,Seq=10----&gt;|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| Missing Fragment&lt;- FCN=5,Seq=2
          |&lt;--Compound ACK,W=0,C=0 --| Bitmap:1010110    |FCN=3,Seq=4
          |-----W=0,FCN=5,Seq=13----&gt;|                   |FCN=0,Seq=7
          |-----W=0,FCN=3,Seq=14----&gt;|                    --
          |-----W=0,FCN=0,Seq=15----&gt;| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16----&gt;|
          |&lt;-Compound ACK,W=1,C=1 ---| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-15">In the next examples, there are fragment losses in both the first (W=0) and second (W=1) windows.
The retransmission cycles after the All-1 is sent (i.e., not in intermediate windows) <bcp14>MUST</bcp14>
always finish with an All-1, as it serves as an ACK Request message to confirm the correct reception
of the retransmitted fragments. </t>
        <figure anchor="UL-ACKoE-LFW12-1" align="left" suppress-title="false" pn="figure-37">
          <name slugifiedName="name-uplink-ack-on-error-all-0-an">Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (1)</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-16.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4--X   |                    __
          |-----W=0,FCN=2,Seq=5-----&gt;|                   |W=0
          |-----W=0,FCN=1,Seq=6-----&gt;|                   |FCN=5,Seq=2
DL Enable |-----W=0,FCN=0,Seq=7--X   |                   |FCN=3,Seq=4
     (no ACK)                                            |FCN=0,Seq=7
          |-----W=1,FCN=6,Seq=8--X   |                   |W=1
          |-----W=1,FCN=5,Seq=9-----&gt;|                   |FCN=6,Seq=8
          |-----W=1,FCN=4,Seq=10-X   |                   |FCN=4,Seq=10
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| Missing Fragment&lt;-|__
          |&lt;-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
          |-----W=0,FCN=5,Seq=13----&gt;|        W=1:0100001
          |-----W=0,FCN=3,Seq=14----&gt;|
          |-----W=0,FCN=0,Seq=15----&gt;|
          |-----W=1,FCN=6,Seq=16----&gt;|
          |-----W=1,FCN=4,Seq=17----&gt;| All fragments received
DL Enable |-----W=1,FCN=7,Seq=18----&gt;|
          |&lt;-Compound ACK,W=1,C=1----| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-17">The figure below is a similar case as above but with fewer fragments in the second window (W=1).</t>
        <figure anchor="UL-ACKoE-LFW12-2" align="left" suppress-title="false" pn="figure-38">
          <name slugifiedName="name-uplink-ack-on-error-all-0-and">Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (2)</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-18.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5-----&gt;|                     __
          |-----W=0,FCN=1,Seq=6-----&gt;|                    |W=0
DL Enable |-----W=0,FCN=0,Seq=7--X   |                    |FCN=5,Seq=2
       (no ACK)                                           |FCN=3,Seq=4
          |-----W=1,FCN=6,Seq=8--X   |                    |FCN=0,Seq=7
DL Enable |-----W=1,FCN=7,Seq=9-----&gt;| Missing Fragment--&gt; W=1
          |&lt;-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110,|FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11----&gt;|        W=1:0000001 |__
          |-----W=0,FCN=3,Seq=12----&gt;|
          |-----W=0,FCN=0,Seq=13----&gt;|
          |-----W=1,FCN=6,Seq=14----&gt;| All fragments received
DL Enable |-----W=1,FCN=7,Seq=15----&gt;|
          |&lt;-Compound ACK, W=1,C=1---| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-19"><strong>Case SCHC ACK is Lost</strong></t>
        <t indent="0" pn="section-5.2-20">SCHC over Sigfox does not implement the SCHC ACK REQ message. Instead, it uses the SCHC All-1 message to request a SCHC ACK when required.</t>
        <figure anchor="UL-ACKoE-ACKL" align="left" suppress-title="false" pn="figure-39">
          <name slugifiedName="name-uplink-ack-on-error-ack-los">Uplink ACK-on-Error ACK Lost</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-21.1">
       Sender                     Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2-----&gt;|
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;|
      (no ACK)
          |-----W=1,FCN=6,Seq=8-----&gt;|
          |-----W=1,FCN=5,Seq=9-----&gt;|
          |-----W=1,FCN=4,Seq=10----&gt;|
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13----&gt;| RESEND ACK
          |&lt;-Compound ACK,W=1,C=1 ---| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-22"><strong>Case SCHC Compound ACK at the End</strong></t>
        <t indent="0" pn="section-5.2-23">In this example, SCHC Fragment losses are found in both windows 0 and 1. However, the sender does not send a
SCHC Compound ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK indicating fragment losses on both windows.
</t>
        <figure anchor="UL-ACKoE-LFW12-3" align="left" suppress-title="false" pn="figure-40">
          <name slugifiedName="name-uplink-ack-on-error-fragmen">Uplink ACK-on-Error Fragments Lost in the First and Second Windows with One Compound ACK</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.2-24.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|                     __
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;| Waits for          |W=0
       (no ACK)                       next DL opportunity |FCN=5,Seq=2
          |-----W=1,FCN=6,Seq=8--X   |                    |FCN=3,Seq=4
DL Enable |-----W=1,FCN=7,Seq=9-----&gt;| Missing Fragment&lt;-- W=1
          |&lt;-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110 |FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11----&gt;|        W=1:0000001  --
          |-----W=0,FCN=3,Seq=12----&gt;|
          |-----W=1,FCN=6,Seq=13----&gt;| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14----&gt;|
          |&lt;-Compound ACK, W=1, C=1 -| C=1
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.2-25">The number of times the same SCHC ACK message will be retransmitted is determined by the
 MAX_ACK_REQUESTS.</t>
      </section>
      <section anchor="abort-examples" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-schc-abort-examples">SCHC Abort Examples</name>
        <t indent="0" pn="section-5.3-1"><strong>Case SCHC Sender-Abort</strong></t>
        <t indent="0" pn="section-5.3-2">The sender may need to send a Sender-Abort to stop the current communication. For example, this may happen if the All-1 has been sent MAX_ACK_REQUESTS times.</t>
        <figure anchor="UL-ACKoE-SndAbt" align="left" suppress-title="false" pn="figure-41">
          <name slugifiedName="name-uplink-ack-on-error-sender-">Uplink ACK-on-Error Sender-Abort</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.3-3.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2-----&gt;|
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;|
      (no ACK)
          |-----W=1,FCN=6,Seq=8-----&gt;|
          |-----W=1,FCN=5,Seq=9-----&gt;|
          |-----W=1,FCN=4,Seq=10----&gt;|
DL Enable |-----W=1,FCN=7,Seq=11----&gt;| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13----&gt;| RESEND ACK  (1)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=15----&gt;| RESEND ACK  (2)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17----&gt;| RESEND ACK  (3)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18----&gt;| RESEND ACK  (4)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19----&gt;| RESEND ACK  (5)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20--&gt;| exit with error condition
        (End)
</artwork>
        </figure>
        <t indent="0" pn="section-5.3-4"><strong>Case Receiver-Abort</strong></t>
        <t indent="0" pn="section-5.3-5">The receiver may need to send a Receiver-Abort to stop the current communication.
This message can only be sent after a Downlink Enable.</t>
        <figure anchor="UL-ACKoE-RcvAbt" align="left" suppress-title="false" pn="figure-42">
          <name slugifiedName="name-uplink-ack-on-error-receive">Uplink ACK-on-Error Receiver-Abort</name>
          <artwork name="" type="" align="center" alt="" pn="section-5.3-6.1">
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1-----&gt;|
          |-----W=0,FCN=5,Seq=2-----&gt;|
          |-----W=0,FCN=4,Seq=3-----&gt;|
          |-----W=0,FCN=3,Seq=4-----&gt;|
          |-----W=0,FCN=2,Seq=5-----&gt;|
          |-----W=0,FCN=1,Seq=6-----&gt;|
DL Enable |-----W=0,FCN=0,Seq=7-----&gt;|
          |&lt;------  RECV ABORT ------| under-resourced
       (Error)
</artwork>
        </figure>
      </section>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-6-1">The radio protocol authenticates and ensures the integrity of each message.
    This is achieved by using a unique Device ID and an AES-128-based message authentication code,
ensuring that the message has been generated and sent by the device (see <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>, Section 3.8)  or Network (see <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>, Section 4.3) with the ID claimed in the message <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>.</t>
      <t indent="0" pn="section-6-2">Application data may or may  not  be encrypted at the application layer, depending on the criticality of the use case.
This flexibility allows a balance between cost and effort versus risk.
AES-128 in counter mode is used for encryption.  Cryptographic keys are independent for each device. These keys are associated with the Device ID, and separate integrity and 
encryption keys are pre-provisioned.
    An encryption key is only provisioned if confidentiality is to be used (see <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>, Section 5.3; note that further documentation is available at Sigfox upon request).</t>
      <t indent="0" pn="section-6-3">The radio protocol has protections against replay attacks, and the cloud-based core Network provides firewall protection against undesired incoming communications <xref target="sigfox-spec" format="default" sectionFormat="of" derivedContent="sigfox-spec"/>.</t>
      <t indent="0" pn="section-6-4">The previously described security mechanisms do not guarantee end-to-end security between the device SCHC C/D + F/R and the Network SCHC C/D + F/R; potential security threats described in <xref target="RFC8724" format="default" sectionFormat="of" derivedContent="RFC8724"/> are applicable to the profile specified in this document.</t>
      <t indent="0" pn="section-6-5">In some circumstances, sending device location information is
privacy sensitive. The Device Geolocation parameter provided by the
Network
   is optional; therefore, it can be omitted to protect this aspect of
the device privacy.</t>
    </section>
    <section anchor="ianaconsiderations" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/>
    <references pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8724" target="https://www.rfc-editor.org/info/rfc8724" quoteTitle="true" derivedAnchor="RFC8724">
          <front>
            <title>SCHC: Generic Framework for Static Context Header Compression and Fragmentation</title>
            <author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
            <author fullname="L. Toutain" initials="L." surname="Toutain"/>
            <author fullname="C. Gomez" initials="C." surname="Gomez"/>
            <author fullname="D. Barthel" initials="D." surname="Barthel"/>
            <author fullname="JC. Zuniga" initials="JC." surname="Zuniga"/>
            <date month="April" year="2020"/>
            <abstract>
              <t indent="0">This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind.</t>
              <t indent="0">SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers.</t>
              <t indent="0">This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size.</t>
              <t indent="0">The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8724"/>
          <seriesInfo name="DOI" value="10.17487/RFC8724"/>
        </reference>
        <reference anchor="RFC9441" target="https://www.rfc-editor.org/info/rfc9441" quoteTitle="true" derivedAnchor="RFC9441">
          <front>
            <title>Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)</title>
            <author initials="JC." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
              <organization showOnFrontPage="true">Cisco</organization>
            </author>
            <author initials="C." surname="Gomez" fullname="Carles Gomez">
              <organization showOnFrontPage="true">Universitat Politecnica de Catalunya</organization>
            </author>
            <author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
              <organization showOnFrontPage="true">Universitat Politecnica de Catalunya</organization>
            </author>
            <author initials="L." surname="Toutain" fullname="Laurent Toutain">
              <organization showOnFrontPage="true">IMT-Atlantique</organization>
            </author>
            <author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
              <organization showOnFrontPage="true">Concordia University</organization>
            </author>
            <author initials="D." surname="Wistuba" fullname="Diego S. Wistuba La Torre">
              <organization showOnFrontPage="true">NIC Labs, Universidad de Chile</organization>
            </author>
            <date month="July" year="2023"/>
          </front>
          <seriesInfo name="RFC" value="9441"/>
          <seriesInfo name="DOI" value="10.17487/RFC9441"/>
        </reference>
        <reference anchor="sigfox-spec" target="https://build.sigfox.com/sigfox-device-radio-specifications" quoteTitle="true" derivedAnchor="sigfox-spec">
          <front>
            <title>Sigfox Device Radio Specifications</title>
            <author>
              <organization showOnFrontPage="true">Sigfox</organization>
            </author>
          </front>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="I-D.ietf-core-comi" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-12" quoteTitle="true" derivedAnchor="CORE-COMI">
          <front>
            <title>CoAP Management Interface (CORECONF)</title>
            <author initials="M." surname="Veillette" fullname="Michel Veillette" role="editor">
              <organization showOnFrontPage="true">Trilliant Networks Inc.</organization>
            </author>
            <author initials="P." surname="van der Stok" fullname="Peter van der Stok" role="editor">
              <organization showOnFrontPage="true">consultant</organization>
            </author>
            <author initials="A." surname="Pelov" fullname="Alexander Pelov">
              <organization showOnFrontPage="true">Acklio</organization>
            </author>
            <author initials="A." surname="Bierman" fullname="Andy Bierman">
              <organization showOnFrontPage="true">YumaWorks</organization>
            </author>
            <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
              <organization showOnFrontPage="true">Universität Bremen TZI</organization>
            </author>
            <date month="March" day="13" year="2023"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-12"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" quoteTitle="true" derivedAnchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t indent="0">The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t indent="0">CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259" quoteTitle="true" derivedAnchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray"/>
            <date month="December" year="2017"/>
            <abstract>
              <t indent="0">JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t indent="0">This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8376" target="https://www.rfc-editor.org/info/rfc8376" quoteTitle="true" derivedAnchor="RFC8376">
          <front>
            <title>Low-Power Wide Area Network (LPWAN) Overview</title>
            <author fullname="S. Farrell" initials="S." role="editor" surname="Farrell"/>
            <date month="May" year="2018"/>
            <abstract>
              <t indent="0">Low-Power Wide Area Networks (LPWANs) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application-layer data sizes, and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8376"/>
          <seriesInfo name="DOI" value="10.17487/RFC8376"/>
        </reference>
        <reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="sigfox-callbacks" target="https://support.sigfox.com/docs/callbacks-documentation" quoteTitle="true" derivedAnchor="sigfox-callbacks">
          <front>
            <title>Sigfox Callbacks</title>
            <author>
              <organization showOnFrontPage="true">Sigfox</organization>
            </author>
          </front>
        </reference>
        <reference anchor="sigfox-docs" target="https://support.sigfox.com/docs" quoteTitle="true" derivedAnchor="sigfox-docs">
          <front>
            <title>Sigfox Documentation</title>
            <author>
              <organization showOnFrontPage="true">Sigfox</organization>
            </author>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1"><contact fullname="Carles Gomez"/> has been funded in part by the Spanish Government
   through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant
   (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria
   d'Universitats i Recerca del Departament d'Empresa i Coneixement de
   la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant SGR 00330.</t>
      <t indent="0" pn="section-appendix.a-2"><contact fullname="Sergio Aguilar"/> has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).</t>
      <t indent="0" pn="section-appendix.a-3"><contact fullname="Sandra Cespedes"/> has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
      <t indent="0" pn="section-appendix.a-4"><contact fullname="Diego Wistuba"/> has been funded by the ANID Chile Project FONDECYT Regular 1201893.</t>
      <t indent="0" pn="section-appendix.a-5">The authors would like to thank <contact fullname="Ana Minaburo"/>, <contact fullname="Clement Mannequin"/>, <contact fullname="Rafael Vidal"/>, <contact fullname="Julien Boite"/>, <contact fullname="Renaud Marty"/>, and <contact fullname="Antonis Platis"/> for their useful comments and implementation design considerations.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
        <address>
          <postal>
            <street/>
            <city>Montreal</city>
            <region>QC</region>
            <country>Canada</country>
          </postal>
          <email>j.c.zuniga@ieee.org</email>
        </address>
      </author>
      <author initials="C." surname="Gomez" fullname="Carles Gomez">
        <organization showOnFrontPage="true">Universitat Politècnica de Catalunya</organization>
        <address>
          <postal>
            <street>C/Esteve Terradas, 7</street>
            <city>Castelldefels</city>
            <code>08860</code>
            <country>Spain</country>
          </postal>
          <email>carles.gomez@upc.edu</email>
        </address>
      </author>
      <author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
        <organization showOnFrontPage="true">Universitat Politècnica de Catalunya</organization>
        <address>
          <postal>
            <street>C/Esteve Terradas, 7</street>
            <city>Castelldefels</city>
            <code>08860</code>
            <country>Spain</country>
          </postal>
          <email>sergio.aguilar.romero@upc.edu</email>
        </address>
      </author>
      <author initials="L." surname="Toutain" fullname="Laurent Toutain">
        <organization showOnFrontPage="true">IMT-Atlantique</organization>
        <address>
          <postal>
            <street>2 rue de la Chataigneraie</street>
            <extaddr>CS 17607</extaddr>
            <city>Cesson-Sevigne Cedex</city>
            <code>35576</code>
            <country>France</country>
          </postal>
          <email>Laurent.Toutain@imt-atlantique.fr</email>
        </address>
      </author>
      <author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
        <organization showOnFrontPage="true">Concordia University</organization>
        <address>
          <postal>
            <street>1455 De Maisonneuve Blvd. W.</street>
            <city>Montreal</city>
            <region>QC</region>
            <code>H3G 1M8</code>
            <country>Canada</country>
          </postal>
          <email>sandra.cespedes@concordia.ca</email>
        </address>
      </author>
      <author initials="D." surname="Wistuba" fullname="Diego Wistuba">
        <organization showOnFrontPage="true">NIC Labs, Universidad de Chile</organization>
        <address>
          <postal>
            <street>Av. Almte. Blanco Encalada 1975</street>
            <city>Santiago</city>
            <country>Chile</country>
          </postal>
          <email>research@witu.cl</email>
        </address>
      </author>
      <author fullname="Julien Boite" initials="J." surname="Boite">
        <organization showOnFrontPage="true">Unabiz (Sigfox)</organization>
        <address>
          <postal>
            <street/>
            <city>Labege</city>
            <country>France</country>
          </postal>
          <email>juboite@free.fr</email>
          <uri>https://www.sigfox.com/</uri>
        </address>
      </author>
    </section>
  </back>
</rfc>
