<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-lpwan-schc-over-sigfox-23" category="std"> number="9442" submissionType="IETF" category="std" consensus="true" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="SCHC over Sigfox LPWAN">
     SCHC
     Static Context Header Compression (SCHC) over Sigfox LPWAN Low-Power Wide Area Network (LPWAN)
    </title>
    <seriesInfo name="RFC" value="9442"/>
    <author fullname="Juan Carlos Zuniga" Zúñiga" initials="JC." surname="Zuniga"> surname="Zúñiga">
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Montreal</city>
          <code> QC</code>
          <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>Universitat Politecnica Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</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>Universitat Politecnica Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</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>IMT-Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street> <street>CS 17607</street>
          <city>35576 Cesson-Sevigne
          <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="Cespedes" surname="Céspedes" fullname="Sandra Cespedes"> Céspedes">
      <organization>Concordia University</organization>
      <address>
        <postal>
          <street>1455 De Maisonneuve Blvd. W.</street>
            <city>Montreal QC, H3G 1M8</city>
          <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>NIC Labs, Universidad de Chile</organization>
      <address>
        <postal>
          <street>Av. Almte. Blanco Encalada 1975</street> <street>Santiago</street>
          <city>Santiago</city>
          <country>Chile</country>
        </postal>
        <email>wistuba@niclabs.cl</email>
        <email>research@witu.cl</email>
      </address>
    </author>
    <author fullname="Julien Boite" initials="J." surname="Boite">
      <organization>
        Unabiz (Sigfox)
      </organization>
      <organization>Unabiz (Sigfox)</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Labege</city>
          <country>France</country>
        </postal>
        <email>julien.boite@unabiz.com</email>
        <email>juboite@free.fr</email>
        <uri>https://www.sigfox.com/</uri>
      </address>
    </author>
    <date year="2023" month="February" day="3"/>

    <workgroup>lpwan Working Group</workgroup> month="July"/>
    <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>

<!--<t>The Generic Framework for Static Context Header Compression and Fragmentation (SCHC) specification describes two mechanisms: i) an application header -->
<!--compression scheme, and ii) a frame fragmentation and loss recovery functionality. SCHC offers a great level of flexibility that can be tailored for different -->
<!--Low Power Wide Area Network (LPWAN) technologies.</t>-->
        <t>The Static Context Header Compression (SCHC) and fragmentation (SCHC) specification (RFC8724) (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed for Low Power Low-Power Wide Area Network (LPWAN) technologies.
        The present
        This document defines a profile of SCHC over Sigfox LPWAN, LPWAN and provides optimal parameter values and modes of operation.
<!--            This set of parameters are also known as a "SCHC over Sigfox profile. -->
      </t>

<!--
<t>when processing the header fields. SCHC compression is based on a common static context stored in a LPWAN device and in the network. Static context means
that the stored information does not change during the packet transmission. The context describes the field values and keeps information that will not be
transmitted through the constrained network.</t>

<t>SCHC must be used for LPWAN networks because it avoids complex resynchronization mechanisms, which are incompatible
with LPWAN characteristics. And also because in most cases, IPv6/UDP headers are reduced
to a small identifier called RuleID. Eventhough sometimes, a SCHC compressed packet will not fit in one L2 PDU, and the SCHC fragmentation protocol
will be used. The SCHC fragmentation and reassembly mechanism is used in two situations: for SCHC-compressed packets that still exceed the L2 PDU size;
and for the case where the SCHC compression cannot be performed.</t>

<t>This document describes the SCHC compression/decompression framework and applies it
to IPv6/UDP headers. This document also specifies a fragmentation and reassembly mechanism that is used to support the IPv6 MTU requirement over LPWAN technologies.
Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or when it has not been possible to apply such compression, still exceed the L2 maximum
payload size. Similar solutions for other protocols such as CoAP will be described in separate documents.</t>
-->
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation (SCHC) specification <xref target="RFC8724"/> target="RFC8724" format="default"/> can be used in conjunction with any of the four LPWAN technologies
described in <xref target="RFC8376"/>. target="RFC8376" format="default"/>. These LPWANs have similar characteristics characteristics, such as star-oriented
topologies, network architecture, connected devices with built-in applications, etc.
</t>
      <t>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>
    Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost.
    Complete Sigfox complete documentation can be found in <xref target="sigfox-docs"/>. target="sigfox-docs" format="default"/>.
    Sigfox aims to provide a very wide area network composed of Base Stations that receive short uplink Uplink messages (up to 12 bytes in size) sent by devices over the long-range Sigfox radio protocol, as described in <xref target="RFC8376"/>. target="RFC8376" format="default"/>.
    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 Downlink messages (with a fixed 8 bytes 8-byte size) sent by the Sigfox Cloud to the devices, downlink  i.e., Downlink messages are being generated when devices explicitly request for it these messages with a flag in an uplink 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"/>. target="sigfox-spec" format="default"/>.
</t>
      <t>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". Profile".
    The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March
2022 <xref target="sigfox-spec"/> target="sigfox-spec" format="default"/>  (support for future versions would have to be assessed).

</t>
    </section>
    <section anchor="terminology" title="Terminology">
<t>The numbered="true" toc="default">
      <name>Terminology</name>
              <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      <t>It is assumed that the reader is familiar with the terms and mechanisms defined in <xref target="RFC8376"/> target="RFC8376" format="default"/> and
in <xref target="RFC8724"/>. target="RFC8724" format="default"/>. Also, it is assumed that the reader is familiar with Sigfox terminology <xref target="sigfox-spec"/>. target="sigfox-spec" format="default"/>.
</t>
    </section>
    <section anchor="schc-over-sigfox" title="SCHC numbered="true" toc="default">
      <name>SCHC over Sigfox"> Sigfox</name>
      <t>The Generic SCHC Framework described in <xref target="RFC8724"/> target="RFC8724" format="default"/> takes advantage of previous knowledge of traffic flows existing in LPWAN applications to avoid context synchronization.</t>
      <t>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 NETCONF<xref target="RFC6241"/> the Network Configuration Protocol (NETCONF) <xref target="RFC6241" format="default"/> with SSH, RESTCONF<xref target="RFC8040"/> Secure Shell (SSH), RESTCONF <xref target="RFC8040" format="default"/> with HTTPs, secure HTTP methods, and CORECONF<xref target="I-D.ietf-core-comi"/> CoAP Management Interface (CORECONF) <xref target="I-D.ietf-core-comi" format="default"/> with CoAP<xref target="RFC7252"/> the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default"/> as provisioning protocols. The contexts can be encoded in XML under NETCONF, in JSON<xref target="RFC8259"/> JSON <xref target="RFC8259" format="default"/> under RESTCONF RESTCONF, and in CBOR<xref target="RFC8949"/> Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default"/> 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" title="Network Architecture"> numbered="true" toc="default">
        <name>Network Architecture</name>

        <t><xref target="Fig-archi"/> target="Fig-archi" format="default"/> represents the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based
on the terminology defined in <xref target="RFC8376"/>, target="RFC8376" format="default"/>, where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the
Sigfox cloud-based Network. </t>
        <figure title="Network Architecture" anchor="Fig-archi"><artwork><![CDATA[ anchor="Fig-archi">
          <name>Network Architecture</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
  Sigfox Device                                           Application
+----------------+                                     +--------------+
| APP1 APP2 APP3 |                                     |APP1 APP2 APP3|
+----------------+                                     +--------------+
|   UDP  |       |                                     |     |  UDP   |
|  IPv6  |       |                                     |     | IPv6   |
+--------+       |                                     |     +--------+
| SCHC C/D & F/R |                                     |              |
|                |                                     |              |
+-------+--------+                                     +--------+-----+
        $                                                       .
        $   +---------+     +--------------+     +---------+    .
        $   |         |     |   Network    |     | Network |    .
        +~~ |Sigfox BS|     |   Gateway    |     |  SCHC   |    .
            |  (RGW)  | === |    (NGW)     | ... |C/D & F/R|.....
            |         |     | Sigfox Cloud |     |         |   IP-based
            +---------+     +--------------+     +---------+   Network
------- Uplink message ------>
                                       <------- Downlink message ------
Legend:
$, ~ : Radio link
= : Internal Sigfox Network
. : External IP-based Network

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In the case of the global Sigfox Network, 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, providing hence providing a global single star network Network topology.</t>
        <t>The Sigfox Device sends application packets that are compressed and/or fragmented by a SCHC C/D + F/R to reduce headers header size and/or fragment the packet.
The resulting SCHC Message message is sent over a layer two (L2) Sigfox frame to the Sigfox Base Stations, which then forwards forward the SCHC Message message to the Network Gateway (NGW). NGW.
The NGW then delivers the SCHC Message message and associated gathered metadata to the Network SCHC C/D + F/R.</t>
        <t>The Sigfox cloud-based Network (NGW) 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 Rules
as the Device 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).</t> (App(s)).</t>
        <t>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" title="Uplink"> numbered="true" toc="default">
        <name>Uplink</name>
        <t>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. Base Stations. The uplink Uplink message application payload size can be up to 12 bytes.</t>
        <t>Since all messages are self-contained and base stations Base Stations forward all these messages back to the same Sigfox Network, network, multiple input copies can be
combined at the NGW NGW, providing for extra reliability based on the triple diversity (i.e., time, space space, and frequency).
</t>
        <t>
A detailed description of the Sigfox Radio Protocol radio protocol can be found in <xref target="sigfox-spec"/>. target="sigfox-spec" format="default"/>.
</t>
        <t>Messages sent from the Device device to the Network are delivered by the Sigfox network (NGW) cloud-based Network to the Network SCHC C/D + F/R through a  callback/API with the following information:</t>

<t><list style="symbols">
<t>Device ID</t>
<t>Message
        <ul spacing="normal">
          <li>Device ID</li>
          <li>Message Sequence Number</t>
<t>Message Payload</t>
<t>Message Timestamp</t>
<t>Device Number</li>
          <li>Message Payload</li>
          <li>Message Timestamp</li>
          <li>Device Geolocation (optional)</t>
<t>Received (optional)</li>
          <li>Received Signal Strength Indicator (RSSI) (optional)</t>
<t>Device (optional)</li>
          <li>Device Temperature (optional)</t>
<t>Device (optional)</li>
          <li>Device Battery Voltage (optional)</t>
</list></t> (optional)</li>
         </ul>
        <t>The Device ID is a globally unique identifier assigned to the Device, 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
device has sent in the Uplink transmission.
	Battery Voltage, temperature Device Temperature, and RSSI values are sent in the confirmation control message, which is mandatorially mandatorily sent by the device after the successful reception of a downlink Downlink message (see <xref target="sigfox-callbacks"/> target="sigfox-callbacks" format="default"/>, Section 5.2).</t>
        <t>The Message Timestamp, Device Geolocation, RSSI, Device Temperature Temperature, and Device Battery Voltage are metadata parameters provided by the Network.</t>
        <t>A detailed description of the Sigfox callbacks/APIs can be found in <xref target="sigfox-callbacks"/>.</t> target="sigfox-callbacks" format="default"/>.</t>
        <t>Only messages that have passed the L2 Cyclic Redundancy Check (CRC) at network Network reception are delivered by the Sigfox Network network to the Network SCHC C/D + F/R.</t>
        <t>The L2 Word Size size used by Sigfox is 1 byte (8 bits). </t>
        <t><xref target="SCHC-Message"/> target="SCHC-Message" format="default"/> shows a SCHC Message message sent over Sigfox, where the SCHC Message 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 title="SCHC anchor="SCHC-Message">
          <name>SCHC Message in Sigfox" anchor="SCHC-Message"><artwork><![CDATA[ Sigfox</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
| Sigfox Header | Sigfox payload Payload  |
+---------------+---------------- +
                |   SCHC message Message  |

]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
      <section anchor="downlink" title="Downlink"> numbered="true" toc="default">
        <name>Downlink</name>
        <t>
   Downlink transmissions are Device-driven device-driven and can only take place
   following an Uplink communication that so indicates. 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. Network. The Downlink request flag is part of the Sigfox protocol headers. After completing the Uplink transmission, the Device 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 device (e.g., either
a response to the Uplink message or queued information waiting to be transmitted), the network Network transmits this message to the Device device during the reception window. If no message is received by the Device device after
the reception opportunity window has elapsed, the Device device closes the reception window opportunity and gets back to the normal mode (e.g., continue Uplink transmissions, sleep, stand-by, etc.) standby, etc.).
</t>
        <t>When a Downlink message is sent to a Device, device, a reception acknowledgement is generated by the Device and device, sent back to the Network through the Sigfox radio protocol protocol, and reported in the Sigfox Network network backend.</t>
        <t>
A detailed description of the Sigfox Radio Protocol radio protocol can be found in <xref target="sigfox-spec"/> target="sigfox-spec" format="default"/>, and a detailed description of the Sigfox callbacks/APIs can be found in <xref target="sigfox-callbacks"/>. target="sigfox-callbacks" format="default"/>. A Downlink request flag can be included in the information exchange between the Sigfox Network network and Network SCHC.
</t>
        <section anchor="dl_ack" title="SCHC numbered="true" toc="default">
          <name>SCHC ACK on Downlink"> Downlink</name>
          <t>
As explained previously, Downlink transmissions are Device-driven 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 ACK-on-Error fragmentation mode) mode), the SCHC protocol implementation needs to consider the times when a Downlink message
(e.g., SCHC ACK) Acknowledgement (ACK)) can be sent and/or received.
</t>
          <t>
For the Uplink ACK-on-Error fragmentation mode, a Downlink opportunity MUST <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, 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 Fragment, as explained in <xref target="RFC8724"/>. target="RFC8724" format="default"/>.
    The Device device sends the fragments in sequence and, after
transmitting the 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 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 Network decides to wait for a further Downlink transmission opportunity, then no
Downlink transmission takes place at that opportunity and after a timeout the Uplink transmissions continue. continue after a timeout.
   Intermediate SCHC fragments Fragments with FCN FCNs that are different from All-0 or All-1 MUST NOT <bcp14>MUST NOT</bcp14> use the Downlink request flag to request a SCHC ACK.
</t>
        </section>
      </section>
      <section anchor="schc-rules" title="SCHC Rules"> numbered="true" toc="default">
        <name>SCHC Rules</name>
        <t>
The RuleID MUST <bcp14>MUST</bcp14> be included in the SCHC header. The total number of rules Rules to be used affects directly affects the RuleID field size, and therefore
the total size of the fragmentation header. For this reason, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> to keep the number of rules Rules that are defined for a specific device to the minimum possible.
    Large RuleID sizes (and thus larger fragmentation header) is headers) are acceptable for devices without significant energy constraints (e.g., a sensor that is powered by the electricity grid).
</t>
        <t>
RuleIDs can be used to differentiate data traffic classes (e.g.,  QoS, control vs. data, etc.), etc.) and data sessions.
They can also be used to interleave simultaneous fragmentation sessions between a Device device and the Network.
</t>
      </section>
      <section anchor="Frag" title="Fragmentation"> numbered="true" toc="default">
        <name>Fragmentation</name>
        <t>
The SCHC specification <xref target="RFC8724"/> target="RFC8724" format="default"/> 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 send reliably send multiple messages, messages by allowing to resend selectively resend any lost fragments. </t> fragments.</t>
        <t>
The SCHC fragmentation supports several modes of operation. These modes have different advantages and disadvantages disadvantages, depending
on the specifics of the underlying LPWAN technology and application Use Case. 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 use case applications.</t>
        <t>As described in section 8.2.3 of <xref target="RFC8724"/>, target="RFC8724" format="default" sectionFormat="of" section="8.2.3"/>, the integrity of the fragmentation-reassembly process of a SCHC Packet MUST <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) (RCS), as described in
<xref target="all-1-behaviour"/> MUST target="all-1-behaviour" format="default"/>, <bcp14>MUST</bcp14> be used.

</t>

<!--<t>The L2 Word Size used by Sigfox is 1 byte (8 bits). </t>-->

<!--
<section anchor="schc-compound-ack" title="SCHC Compound ACK">

<t>
The present SCHC over Sigfox specification extends SCHC ACK format defined in <xref target="RFC8724"/> with the SCHC Compound ACK concept.</t>
<t>
The SCHC Compound ACK is a SCHC ACK message that can contain several bitmaps, each bitmap being identified by its
corresponding window number.
The SCHC Compound ACK concept is meant to reduce the number of Downlink transmissions (i.e., SCHC ACKs) by including bitmaps of several
windows in a single SCHC message (i.e., the SCHC Compound ACK), and hence making an efficient use of Downlink channel transmissions.
</t>
<t>When the ACK-on-Error mode is used for Uplink fragmentation, SCHC Compound ACKs MUST be used in the Downlink responses.</t>
<t>The SCHC Compound ACK:</t>
<t><list style="symbols">
<t>provides feedback only for windows with fragment losses,</t>
<t>has a variable size that depends on the number of windows with fragment losses being reported in the single Compound SCHC ACK,</t>
<t>includes the window number (i.e., W) for each bitmap,</t>
<t>has a format coincident with that of a SCHC ACK (RFC 8724) when only one window with losses is reported,</t>
<t>might not cover all windows with fragment losses of a SCHC Packet,</t>
<t>is distinguishable from the SCHC Receiver-Abort.</t>
</list></t>
<t>
The SCHC Compound ACK groups the window number (W) with its corresponding bitmap.
The included window numbers and corresponding bitmap MUST be ordered from the lowest-numbered to the highest-numbered window.
 </t>
</section>
-->
<section anchor="uplink-fragmentation" title="Uplink Fragmentation"> numbered="true" toc="default">
          <name>Uplink Fragmentation</name>
          <t>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, mode and then wake up and transmit whenever there is a need to send information to the network, Network, as there is no need to perform any network Network attachment, synchronization, or other procedure procedures before transmitting a data packet.
<!--Data packets are self-contained (aka “message in a bottle”) with all the required information for the network to process them accordingly.-->
<!--Hence, there is no need to perform any network attachment, synchronization, or other procedure before transmitting a data packet.-->
	  </t>
          <t>Since Uplink transmissions are asynchronous, a SCHC fragment Fragment can be transmitted at any given time by the Device. device. Sigfox Uplink messages
are fixed in size, and as described in <xref target="RFC8376"/> target="RFC8376" format="default"/>, they can carry a payload of 0-12 bytes payload. (0-96 bits). Hence, a single SCHC Tile size size, per fragmentation
mode
mode, can be defined so that every Sigfox message always carries one SCHC Tile.</t>
          <t>When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC Compound ACK defined in <xref target="I-D.ietf-lpwan-schc-compound-ack"/>) MUST target="RFC9441" format="default"/> <bcp14>MUST</bcp14> be used in the Downlink responses.</t>
          <section anchor="schc_sender_abort" title="SCHC Sender-Abort"> numbered="true" toc="default">
            <name>SCHC Sender-Abort</name>
            <t>As defined in <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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 MUST <bcp14>MUST</bcp14> be sent if the number of repeated All-1s sent in sequence, without a Compound ACK reception inbetween, is greater than or equal to MAX_ACK_REQUESTS.
<!--    be sent if the number of repeated All-1s (i.e., with the same bitmap) sent in sequence between, is greater than or equal to MAX_ACK_REQUESTS. -->
</t>
<!--<t>The Attempts counter MUST be reset when a SCHC ACK is successfully received.</t>-->
</section>
          <section anchor="schc_receiver_abort" title="SCHC Receiver-Abort"> numbered="true" toc="default">
            <name>SCHC Receiver-Abort</name>
            <t>As defined in <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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 profile, a SCHC Receiver-Abort MUST <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, requested or if the RuleID of the fragment is not valid.</t>
            <t>A SCHC Receiver-Abort MUST <bcp14>MUST</bcp14> be triggered when the Inactivity Timer expires. </t>
            <t>MAX_ACK_REQUESTS can be increased when facing high error rates. </t>

<!--<t>A SCHC-Receiver Abort can be triggered when the number of ACK attempts is not strictly less than MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, -->
<!--a SCHC-Receiver Abort MUST be sent if the number of repeated SCHC ACKs sent in a row (i.e., synchronized with the ACK REQ case, and with identical bitmaps) -->
<!--is greater than or equal to MAX_ACK_REQUESTS.</t>-->
<t>Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC Receiver-Abort Downlink message MUST <bcp14>MUST</bcp14> only be sent when there is a Downlink transmission opportunity.</t>
          </section>
          <section anchor="single-byte-schc-header" title="Single-byte numbered="true" toc="default">
            <name>Single-Byte SCHC Header for Uplink Fragmentation"> Fragmentation</name>
            <section anchor="no-ack-mode" title="Uplink numbered="true" toc="default">
              <name>Uplink No-ACK Mode: Single-byte Single-Byte SCHC Header"> Header</name>
              <t>Single-byte SCHC Header No-ACK mode MUST <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, 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>Since there are no multiple windows in the No-ACK mode, the W bit is not present.
    However, it MUST <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 MUST <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 indicating implicitly indicating
the size of the expected packet to the Network and hence detect at the receiver side detects whether all fragments have been received or not. 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>When using the Single-byte SCHC Header for Uplink Fragmentation, fragmentation, the
     Fragmentation Header MUST
	      fragmentation header <bcp14>MUST</bcp14> be of 8 bit size, bits in size and the Fragment header is composed as follows:</t>

<t><list style="symbols">

<t>RuleID
              <ul spacing="normal">
                <li>RuleID size: 3 bits</t>

<t>DTag bits</li>
                <li>DTag size (T): 0 bit</t>

<t>Fragment bits</li>
                <li>Fragment Compressed Number (FCN) size (N): 5 bits</t>

</list></t> bits</li>
              </ul>
              <t>Other F/R parameters MUST <bcp14>MUST</bcp14> be configured as follows:</t>
 <t><list style="symbols">

<t>As
              <ul spacing="normal">
                <li>As per <xref target="RFC8724"/>, target="RFC8724" format="default"/>, in the No-ACK mode mode, the W (window) field is not present. </t>

<t>Regular </li>
                <li>Regular tile size: 11 bytes</t>

<t>All-1 bytes</li>
                <li>All-1 tile size: 0 to 10 bytes</t>

<t>Inactivity bytes</li>
                <li>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>

<t>RCS hours.</li>
                <li>RCS size: 5 bits </t>

</list></t> </li>
              </ul>
              <t>The maximum SCHC Packet size is 340 bytes.</t>
              <t><xref target="UL-NoACK-single-byte"/> target="UL-NoACK-single-byte" format="default"/> presents SCHC Fragment format examples examples, and <xref target="no-ack-examples"/> target="no-ack-examples" format="default"/> provides fragmentation examples, using Single-byte SCHC Header No-ACK mode.</t>
            </section>
            <section anchor="ack-on-error-mode-1" title="Uplink numbered="true" toc="default">
              <name>Uplink ACK-on-Error Mode: Single-byte Single-Byte SCHC Header"> Header</name>
              <t>ACK-on-Error with a single-byte header MUST <bcp14>MUST</bcp14> be used for short short- to medium size 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 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>Allowing transmission of packets/files up to 300 bytes long, the SCHC Uplink Fragmentation Header fragmentation header size is 8 bits in size and is composed as follows:
</t>

<!--
<t><list style="symbols">
<t>Single-byte SCHC Uplink header</t>
</list></t>
-->

<t><list style="symbols">

<t>RuleID
<ul spacing="normal">
                <li>RuleID size: 3 bits</t>

<t>DTag bits</li>
                <li>DTag size (T): 0 bit</t>

<t>Window bits</li>
                <li>Window index (W) size (M): 2 bits </t>

<t>Fragment </li>
                <li>Fragment Compressed Number (FCN) size (N): 3 bits</t>
</list></t> bits</li>
              </ul>
              <t>Other F/R parameters MUST <bcp14>MUST</bcp14> be configured as follows:</t>
 <t><list style="symbols">
<t>MAX_ACK_REQUESTS: 5</t>

<t>WINDOW_SIZE:
              <ul spacing="normal">
                <li>MAX_ACK_REQUESTS: 5</li>
                <li>WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)</t>

<t>Regular 0b110)</li>
                <li>Regular tile size: 11 bytes</t>

<t>All-1 bytes</li>
                <li>All-1 tile size: 0 to 10 bytes</t>

<t>Retransmission bytes</li>
                <li>Retransmission Timer: Application-dependent. The default value is 12 hours.</t>

<t>Inactivity hours.</li>
                <li>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>

<t>RCS hours.</li>
                <li>RCS size: 3 bits</t>

</list></t> bits</li>
              </ul>
              <t><xref target="UL-ACKoE-single-byte"/> target="UL-ACKoE-single-byte" format="default"/> presents SCHC Fragment format examples examples, and <xref target="ack-on-error-examples-1B-header"/> target="ack-on-error-examples-1B-header" format="default"/> provides fragmentation examples, using ACK-on-Error with a single-byte header.</t>
            </section>
          </section>
          <section anchor="two-byte-schc-header" title="Two-byte numbered="true" toc="default">
            <name>Two-Byte SCHC Header for Uplink Fragmentation"> Fragmentation</name>
            <t>ACK-on-Error with a two-byte header MUST <bcp14>MUST</bcp14> be used for medium-large size 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 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" title="Uplink numbered="true" toc="default">
              <name>Uplink ACK-on-Error Mode: Two-byte Two-Byte SCHC Header Option 1"> 1</name>
              <t>In order to allow transmission of medium-large medium to large packets/files up to 480 bytes long, the SCHC Uplink Fragmentation Header fragmentation header size is 16 bits in size and is composed as follows:</t>

<t><list style="symbols">

<t>RuleID size is:
              <ul spacing="normal">
                <li>RuleID size: 6 bits</t>

<t>DTag bits</li>
                <li>DTag size (T) is: (T): 0 bit</t>

<t>Window bits</li>
                <li>Window index (W) size (M): 2 bits </t>

<t>Fragment </li>
                <li>Fragment Compressed Number (FCN) size (N): 4 bits.</t>

<t>RCS bits</li>
                <li>RCS size: 4 bits</t>
</list></t> bits</li>
              </ul>
              <t>Other F/R parameters MUST <bcp14>MUST</bcp14> be configured as follows:</t>
 <t><list style="symbols">
<t>MAX_ACK_REQUESTS: 5</t>

<t>WINDOW_SIZE:
              <ul spacing="normal">
                <li>MAX_ACK_REQUESTS: 5</li>
                <li>WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)</t>

<t>Regular FCN=0b1011)</li>
                <li>Regular tile size: 10 bytes</t>

<t>All-1 bytes</li>
                <li>All-1 tile size: 1 to 10 bytes</t>

<t>Retransmission bytes</li>
                <li>Retransmission Timer: Application-dependent. The default value is 12 hours.</t>

<t>Inactivity hours.</li>
                <li>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>

</list></t> hours.</li>
              </ul>
              <t>Note that WINDOW_SIZE is limited to 12. This because, is because 4 windows (M = 2) with bitmaps of size 12 can be fitted in a
single SCHC Compound ACK.</t>
              <t><xref target="UL-ACKoE-two-byte-opt-1"/> target="UL-ACKoE-two-byte-opt-1" format="default"/> presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 1.</t>
            </section>
            <section anchor="ack-on-error-mode-3" title="Uplink numbered="true" toc="default">
              <name>Uplink ACK-on-Error Mode: Two-byte Two-Byte SCHC Header Option 2"> 2</name>
              <t>In order to allow transmission of very large packets/files up to 2400 bytes long, the SCHC Uplink Fragmentation Header fragmentation header size is 16 bits in size and is composed as follows:</t>

<t><list style="symbols">

<t>RuleID size is:
              <ul spacing="normal">
                <li>RuleID size: 8 bits</t>

<t>DTag bits</li>
                <li>DTag size (T) is: (T): 0 bit</t>

<t>Window bits</li>
                <li>Window index (W) size (M): 3 bits </t>

<t>Fragment </li>
                <li>Fragment Compressed Number (FCN) size (N): 5 bits.</t>

<t>RCS bits</li>
                <li>RCS size: 5 bits</t>

</list></t> bits</li>
              </ul>
              <t>Other F/R parameters MUST <bcp14>MUST</bcp14> be configured as follows:</t>
 <t><list style="symbols">
<t>MAX_ACK_REQUESTS: 5</t>

<t>WINDOW_SIZE:
              <ul spacing="normal">
                <li>MAX_ACK_REQUESTS: 5</li>
                <li>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</t>

<t>Regular FCN=0b11110)</li>
                <li>Regular tile size: 10 bytes</t>

<t>All-1 bytes</li>
                <li>All-1 tile size: 0 to 9 bytes</t>

<t>Retransmission bytes</li>
                <li>Retransmission Timer: Application-dependent. The default value is 12 hours.</t>

<t>Inactivity hours.</li>
                <li>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>

</list></t> hours.</li>
              </ul>
              <t><xref target="UL-ACKoE-two-byte"/> target="UL-ACKoE-two-byte" format="default"/> presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 1.</t> 2.</t>
            </section>
          </section>
          <section anchor="all-1-behaviour" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment and RCS behaviour"> Behavior</name>
            <t>For ACK-on-Error, as defined in <xref target="RFC8724"/>, target="RFC8724" format="default"/>, it is expected that the last SCHC fragment 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>For Rules where the number of fragments in the last window is unknown, an RCS field MUST <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, accordingly and send it in response to the All-1.
</t>
          </section>
        </section>
        <section anchor="downlink-fragmentation" title="Downlink Fragmentation"> numbered="true" toc="default">
          <name>Downlink Fragmentation</name>
          <t>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, battery without the need to listen to any information
from the network. 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>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 MAY <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
MAY
<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 MUST <bcp14>MUST</bcp14> send an Uplink transmission (e.g., empty message) and request a Downlink every 24 hours when no SCHC session is started. The use or not of Whether this Uplink transmission is used (and the transmission rate, if used) will depend depends on application specific application-specific requirements.
</t>
          <t>Sigfox Downlink messages are fixed in size, and as described in <xref target="RFC8376"/> target="RFC8376" format="default"/> they can carry up to 8 a payload of 0-8 bytes payload. (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>For reliable Downlink fragment transmission, the ACK-Always mode SHOULD <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>The SCHC Downlink Fragmentation Header fragmentation header size is 8 bits in size and is composed as follows:</t>

<t><list style="symbols">
<t>RuleID
          <ul spacing="normal">
            <li>RuleID size: 3 bits</t>

<t>DTag bits</li>
            <li>DTag size (T): 0 bit</t>

<t>Window bits</li>
            <li>Window index (W) size (M) is: (M): 0 bit </t>

<t>Fragment bits </li>
            <li>Fragment Compressed Number (FCN) size (N): 5 bits</t>
</list></t> bits</li>
          </ul>
          <t>Other F/R parameters MUST <bcp14>MUST</bcp14> be configured as follows:</t>
 <t><list style="symbols">
<t>MAX_ACK_REQUESTS: 5</t>

<t>WINDOW_SIZE:
          <ul spacing="normal">
            <li>MAX_ACK_REQUESTS: 5</li>
            <li>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</t>

<t>Regular FCN=0b11110)</li>
            <li>Regular tile size: 7 bytes</t>

<t>All-1 bytes</li>
            <li>All-1 tile size: 0 to 6 bytes</t>

<t>Retransmission bytes</li>
            <li>Retransmission Timer: Application-dependent. The default value is 12 hours.</t>

<t>Inactivity hours.</li>
            <li>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>

<t>RCS hours.</li>
            <li>RCS size: 5 bits </t>
</list></t>

<!--
<t>Sigfox Downlink frames have a fixed length of 8 bytes, which means that default SCHC algorithm for padding cannot be used.
Therefore, the 3 last bits of the fragmentation header are used to indicate in bytes the size of the padding.
A size of 000 means that the full remaining frame is used to carry payload, a value of 001 indicates that the last byte contains padding, and so on.</t>
--> </li>
          </ul>
</section>
      </section>
      <section anchor="schc-sigfox-message-formats" title="SCHC numbered="true" toc="default">
        <name>SCHC over Sigfox F/R Message Formats"> Formats</name>
        <t>This section depicts the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK
defined in <xref target="I-D.ietf-lpwan-schc-compound-ack"/>), target="RFC9441" format="default"/>), and SCHC Abort used in SCHC over Sigfox.</t>
        <section anchor="UL-NoACK-single-byte" title="Uplink numbered="true" toc="default">
          <name>Uplink No-ACK Mode: Single-byte Single-Byte SCHC Header"> Header</name>
          <section anchor="no-ack-regular-1byte-schc-fragment" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t><xref target="no-ack-reg-1byte-frag"/> target="no-ack-reg-1byte-frag" format="default"/> shows an example of a regular Regular SCHC fragment Fragment for all fragments except the last one.
	    As tiles are of 11 bytes, bytes in size, padding MUST NOT <bcp14>MUST NOT</bcp14> be added.
The penultimate tile of a SCHC Packet is of regular size.</t>

<t><figure title="Regular
            <figure anchor="no-ack-reg-1byte-frag">
              <name>Regular SCHC Fragment format Format for all fragments All Fragments except the last one" anchor="no-ack-reg-1byte-frag"><artwork><![CDATA[ Last One</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|- SCHC Fragment Header -|
+------------------------+---------+
|   RuleID   |    FCN    | Payload |
+------------+-----------+---------+
|   3 bits   |  5 bits   | 88 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
          <section anchor="no-ack-all-1-1byte-schc-fragment" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t><xref target="no-ack-all-1-1byte"/> target="no-ack-all-1-1byte" format="default"/> shows an example of the All-1 message.
The All-1 message MAY <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
  Padding MUST NOT <bcp14>MUST NOT</bcp14> be
  added, as the resulting size is L2-word-multiple.</t> a multiple of an L2 Word.</t>
            <t>
   The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added as padding to complete two 2 bytes.
    The payload size of the All-1 message ranges from 0 to 80 bits.
</t>

<t><figure title="All-1
            <figure anchor="no-ack-all-1-1byte">
              <name>All-1 SCHC Message format Format with last tile" anchor="no-ack-all-1-1byte"><artwork><![CDATA[ the Last Tile</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|--------  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>
]]></artwork>
            </figure>
            <t>As per <xref target="RFC8724"/> target="RFC8724" format="default"/>, the All-1 must be distinguishable from a SCHC Sender-Abort message (with the same RuleID, RuleID and N values).
The All-1 MAY <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is 1 byte, byte with no padding bits.</t>
            <t>For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST <bcp14>MUST</bcp14> be of 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" title="SCHC numbered="true" toc="default">
            <name>SCHC Sender-Abort Message format">

<t><figure title="SCHC Format</name>
            <figure anchor="no-ack-snd-abort-msg">
              <name>SCHC Sender-Abort message format" anchor="no-ack-snd-abort-msg"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
     Sender-Abort
|------ Header ------|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-single-byte" title="Uplink numbered="true" toc="default">
          <name>Uplink ACK-on-Error Mode: Single-byte Single-Byte SCHC Header"> Header</name>
          <section anchor="regular-1byte-schc-fragment" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t><xref target="reg-1byte-frag"/> target="reg-1byte-frag" format="default"/> shows an example of a regular Regular SCHC fragment Fragment for all fragments except the last one.
As tiles are of 11 bytes, bytes in size, padding MUST NOT <bcp14>MUST NOT</bcp14> be added.</t>

<t><figure title="Regular
            <figure anchor="reg-1byte-frag">
              <name>Regular SCHC Fragment format Format for all fragments All Fragments except the last one" anchor="reg-1byte-frag"><artwork><![CDATA[ Last One</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    |  FCN   | Payload |
+--------+--------+--------+---------+
| 3 bits | 2 bits | 3 bits | 88 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC ACK REQ MUST NOT <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment MUST <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t><xref target="all-1-1byte"/> target="all-1-1byte" format="default"/> shows an example of the All-1 message.
The All-1 message MAY <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
Padding MUST NOT <bcp14>MUST NOT</bcp14> be added, as the resulting size is L2-word-multiple.</t>

<t><figure title="All-1
            <figure anchor="all-1-1byte">
              <name>All-1 SCHC Message format Format with last tile" anchor="all-1-1byte"><artwork><![CDATA[ the Last Tile</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-------------  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>
]]></artwork>
            </figure>
            <t>As per <xref target="RFC8724"/> target="RFC8724" format="default"/>, the All-1 must be distinguishable from a SCHC Sender-Abort message (with same RuleID, M, and N values).
The All-1 MAY <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is 1 byte, byte with no padding bits.</t>
            <t>For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST <bcp14>MUST</bcp14> be of 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" title="SCHC numbered="true" toc="default">
            <name>SCHC ACK Format"> Format</name>
            <t><xref target="success-ack-1byte"/> target="success-ack-1byte" format="default"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>

<t><figure title="SCHC
            <figure anchor="success-ack-1byte">
              <name>SCHC Success ACK message format" anchor="success-ack-1byte"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 3 bits | 2 bits | 1 bit | 58 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>In case SCHC fragment Fragment losses are found in any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK defined in <xref target="I-D.ietf-lpwan-schc-compound-ack"/> MUST target="RFC9441" format="default"/> <bcp14>MUST</bcp14> be used.
The SCHC Compound ACK message format is shown in <xref target="compound-ack-1byte"/>. target="compound-ack-1byte" format="default"/>.
</t>

<t><figure title="SCHC
            <figure anchor="compound-ack-1byte">
              <name>SCHC Compound ACK message format" anchor="compound-ack-1byte"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|--- 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|

     Losses
]]></artwork>
            </figure>
	      <t>Losses are found in windows W = w1,...,wi; w1,...,wi, where w1<w2<...<wi
]]></artwork></figure></t> w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="snd-abort-msg-format" title="SCHC numbered="true" toc="default">
            <name>SCHC Sender-Abort Message format">

<t><figure title="SCHC Format</name>
            <figure anchor="snd-abort-msg">
              <name>SCHC Sender-Abort message format" anchor="snd-abort-msg"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W=b'11 | FCN=ALL-1 |
+--------+--------+-----------+
| 3 bits | 2 bits |  3 bits   |

]]></artwork></figure></t>
		]]></artwork>
            </figure>
          </section>
          <section anchor="rcv-abort-msg-format" title="SCHC numbered="true" toc="default">
            <name>SCHC Receiver-Abort Message format">

<t><figure title="SCHC Format</name>
            <figure anchor="rcv-abort-msg">
              <name>SCHC Receiver-Abort message format" anchor="rcv-abort-msg"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|- 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 ->| <-- L2 Word --> |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-two-byte-opt-1" title="Uplink numbered="true" toc="default">
          <name>Uplink ACK-on-Error Mode: Two-byte Two-Byte SCHC Header Option 1"> 1</name>
          <section anchor="opt-1-regular-2byte-schc-fragment" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t><xref target="opt-1-reg-2byte-frag"/> target="opt-1-reg-2byte-frag" format="default"/> shows an example of a regular Regular SCHC fragment Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>

<t><figure title="Regular
            <figure anchor="opt-1-reg-2byte-frag">
              <name>Regular SCHC Fragment format Format for all fragments All Fragments except the last one" anchor="opt-1-reg-2byte-frag"><artwork><![CDATA[ Last One</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|------- SCHC Fragment Header ------|
+-----------------------------------+---------+
| RuleID |    W   |  FCN   | b'0000 | Payload |
+--------+--------+--------+--------+---------+
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |
]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC ACK REQ MUST NOT <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment MUST <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t><xref target="opt-1-all-1-2B"/> target="opt-1-all-1-2B" format="default"/> shows an example of the All-1 message.
The All-1 message MUST <bcp14>MUST</bcp14> contain the last tile of the SCHC Packet.</t>
            <t>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>

<t><figure title="All-1
            <figure anchor="opt-1-all-1-2B">
              <name>All-1 SCHC message format Message Format with last tile" anchor="opt-1-all-1-2B"><artwork><![CDATA[ the Last Tile</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|--------- 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>
]]></artwork>
            </figure>
            <t>As per <xref target="RFC8724"/> target="RFC8724" format="default"/>, the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M M, and N values).
The All-1 MUST <bcp14>MUST</bcp14> have the last tile of the SCHC Packet, Packet that MUST <bcp14>MUST</bcp14> be of at least 1 byte.
The SCHC Sender-Abort message header size is 2 byte, bytes with no padding bits.</t>
            <t>For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST <bcp14>MUST</bcp14> be of 2 byte 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" title="SCHC numbered="true" toc="default">
            <name>SCHC ACK Format"> Format</name>
            <t> <xref target="opt-1-success-ack-2B"/> target="opt-1-success-ack-2B" format="default"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>

<t><figure title="SCHC
            <figure anchor="opt-1-success-ack-2B">
              <name>SCHC Success ACK message format" anchor="opt-1-success-ack-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 6 bits | 2 bits | 1 bit | 55 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC Compound ACK message MUST <bcp14>MUST</bcp14> be used in case SCHC fragment 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"/>. target="opt-1-schc-compound-ack-2B" format="default"/>.
The SCHC Compound ACK can report up to 4 windows with losses. losses, as shown in <xref target="opt-1-schc-compound-ack-2B-example-losses-all-windows"/>.</t> target="opt-1-schc-compound-ack-2B-example-losses-all-windows" format="default"/>.</t>
            <t>When sent in the Downlink, the SCHC Compound ACK MUST <bcp14>MUST</bcp14> be 0 padded (Padding (padding bits must be 0) to complement the 64 bits required by the Sigfox payload.</t>

<t><figure title="SCHC
            <figure anchor="opt-1-schc-compound-ack-2B">
              <name>SCHC Compound ACK message format" anchor="opt-1-schc-compound-ack-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|--- 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|

   Losses
]]></artwork>
            </figure>
	    <t>Losses are found in windows W = w1,...,wi; w1,...,wi, where w1<w2<...<wi

]]></artwork></figure></t>

<t><figure title="SCHC w1 &lt; w2 &lt;...&lt; wi.</t>
            <figure anchor="opt-1-schc-compound-ack-2B-example-losses-all-windows">
              <name>SCHC Compound ACK message format example Message Format Example with losses Losses in all windows" anchor="opt-1-schc-compound-ack-2B-example-losses-all-windows"><artwork><![CDATA[ All Windows</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|- 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|

    Losses
]]></artwork>
            </figure>
<t>Losses are found in windows W = w1,...,wi; w1,...,wi, where w1<w2<...<wi

]]></artwork></figure></t> w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="opt-1-snd-abort-msg-2B" title="SCHC numbered="true" toc="default">
            <name>SCHC Sender-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="opt-1-snd-abort-msg-format-2B">
              <name>SCHC Sender-Abort message format" anchor="opt-1-snd-abort-msg-format-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 6 bits | 2 bits |  4 bits   |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
          <section anchor="opt-1-rcv-abort-msg-2B" title="SCHC numbered="true" toc="default">
            <name>SCHC Receiver-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="opt-1-rcv-abort-msg-format-2B">
              <name>SCHC Receiver-Abort message format" anchor="opt-1-rcv-abort-msg-format-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|- 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 ->| <-- L2 Word --> |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="UL-ACKoE-two-byte" title="Uplink numbered="true" toc="default">
          <name>Uplink ACK-on-Error Mode: Two-byte Two-Byte SCHC Header Option 2"> 2</name>
          <section anchor="opt-2regular-2byte-schc-fragment" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t><xref target="opt-2-reg-2byte-frag"/> target="opt-2-reg-2byte-frag" format="default"/> shows an example of a regular Regular SCHC fragment Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>

<t><figure title="Regular
            <figure anchor="opt-2-reg-2byte-frag">
              <name>Regular SCHC Fragment format Format for all fragments All Fragments except the last one" anchor="opt-2-reg-2byte-frag"><artwork><![CDATA[ Last One</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID |   W    | FCN    | Payload |
+--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC ACK REQ MUST NOT <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment MUST <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t><xref target="opt-2-all-1-2B"/> target="opt-2-all-1-2B" format="default"/> shows an example of the All-1 message.
The All-1 message MAY <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</t>
            <t>The All-1 message Fragment Header contains an RCS of 5 bits, 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>

<t><figure title="All-1
            <figure anchor="opt-2-all-1-2B">
              <name>All-1 SCHC message format Message Format with last tile" anchor="opt-2-all-1-2B"><artwork><![CDATA[ the Last Tile</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-------------- 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>
]]></artwork>
            </figure>
            <t>As per <xref target="RFC8724"/> target="RFC8724" format="default"/>, the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M M, and N values).
The SCHC Sender-Abort message header size is 2 byte, bytes with no padding bits.</t>
            <t>For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST <bcp14>MUST</bcp14> be of 2 byte 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" title="SCHC numbered="true" toc="default">
            <name>SCHC ACK Format"> Format</name>
            <t> <xref target="opt-2-success-ack-2B"/> target="opt-2-success-ack-2B" format="default"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink frame payload size.</t>

<t><figure title="SCHC
            <figure anchor="opt-2-success-ack-2B">
              <name>SCHC Success ACK message format" anchor="opt-2-success-ack-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID |    W   | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC Compound ACK message MUST <bcp14>MUST</bcp14> be used in case SCHC fragment 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"/>. target="opt-2-schc-compound-ack-2B" format="default"/>.
The SCHC Compound ACK can report up to 3 windows with losses.</t>
            <t>When sent in the Downlink, the SCHC Compound ACK MUST <bcp14>MUST</bcp14> be 0 padded (Padding (padding bits must be 0) to complement the 64 bits required by
the Sigfox payload.</t>

<t><figure title="SCHC
            <figure anchor="opt-2-schc-compound-ack-2B">
              <name>SCHC Compound ACK message format" anchor="opt-2-schc-compound-ack-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-- 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|

     Losses
]]></artwork>
            </figure>
	    <t>Losses are found in windows W = w1,...,wi; w1,...,wi, where w1<w2<...<wi

]]></artwork></figure></t> w1 &lt; w2 &lt;...&lt; wi.</t>
          </section>
          <section anchor="snd-abort-msg-2B" title="SCHC numbered="true" toc="default">
            <name>SCHC Sender-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="snd-abort-msg-format-2B">
              <name>SCHC Sender-Abort message format" anchor="snd-abort-msg-format-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits |  5 bits   |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
          <section anchor="rcv-abort-msg-2B" title="SCHC numbered="true" toc="default">
            <name>SCHC Receiver-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="rcv-abort-msg-format-2B">
              <name>SCHC Receiver-Abort message format" anchor="rcv-abort-msg-format-2B"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|-- 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 ->| <-- L2 Word --> |

]]></artwork></figure></t>
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="DL-ACK-Always" title="Downlink numbered="true" toc="default">
          <name>Downlink ACK-Always Mode: Single-byte Single-Byte SCHC Header"> Header</name>
          <section anchor="DL-ACK-Always-1byte-schc-fragment" title="Regular numbered="true" toc="default">
            <name>Regular SCHC Fragment"> Fragment</name>
            <t><xref target="DL-ACK-Always-1byte-frag"/> target="DL-ACK-Always-1byte-frag" format="default"/> shows an example of a regular Regular SCHC fragment Fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t>

<t><figure title="Regular
            <figure anchor="DL-ACK-Always-1byte-frag">
              <name>Regular SCHC Fragment format Format for all fragments All Fragments except the last one" anchor="DL-ACK-Always-1byte-frag"><artwork><![CDATA[ Last One</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
   SCHC Fragment
|--    Header   --|
+-----------------+---------+
| RuleID |  FCN   | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>The SCHC ACK MUST NOT <bcp14>MUST NOT</bcp14> be used, instead the All-1 SCHC Fragment MUST <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver.
As per <xref target="RFC8724"/>, target="RFC8724" format="default"/>, 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" title="All-1 numbered="true" toc="default">
            <name>All-1 SCHC Fragment"> Fragment</name>
            <t><xref target="DL-ACK-Always-1B-all-1"/> target="DL-ACK-Always-1B-all-1" format="default"/> shows an example of the All-1 message.
The All-1 message MAY <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</t>
            <t>The All-1 message Fragment Header contains an RCS of 5 bits, 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>

<t><figure title="All-1
            <figure anchor="DL-ACK-Always-1B-all-1">
              <name>All-1 SCHC message format Message Format with last tile" anchor="DL-ACK-Always-1B-all-1"><artwork><![CDATA[ the Last Tile</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|--------- 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>
]]></artwork>
            </figure>
            <t>As per <xref target="RFC8724"/> target="RFC8724" format="default"/>, 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, byte with no padding bits.</t>
            <t>For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST <bcp14>MUST</bcp14> be of 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" title="SCHC numbered="true" toc="default">
            <name>SCHC ACK Format"> Format</name>
            <t> <xref target="DL-ACK-Always-1B-success-ack"/> target="DL-ACK-Always-1B-success-ack" format="default"/> shows the SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST <bcp14>MUST</bcp14> be added to complete 2 bytes.</t>

<t><figure title="SCHC
            <figure anchor="DL-ACK-Always-1B-success-ack">
              <name>SCHC Success ACK message format" anchor="DL-ACK-Always-1B-success-ack"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
     SCHC ACK
|--   Header   --|
+----------------+---------+
| RuleID | C=b'1 | b'0-pad |
+--------+-------+---------+
| 3 bits | 1 bit |  4 bits |

]]></artwork></figure></t>
]]></artwork>
            </figure>
            <t>
The SCHC ACK message format is shown in <xref target="DL-ACK-Always-1B-schc-compound-ack"/>. target="DL-ACK-Always-1B-schc-compound-ack" format="default"/>.
</t>

<t><figure title="SCHC
            <figure anchor="DL-ACK-Always-1B-schc-compound-ack">
              <name>SCHC Compound ACK message format" anchor="DL-ACK-Always-1B-schc-compound-ack"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----|
+--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits|  5 bits |
]]></artwork></figure></t>
        <!--    End Section SCHC ACK Format-->
]]></artwork>
            </figure>
</section>
          <section anchor="DL-ACK-Always-1B-snd-abort-msg" title="SCHC numbered="true" toc="default">
            <name>SCHC Sender-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="DL-ACK-Always-1B-snd-abort-msg-format">
              <name>SCHC Sender-Abort message format" anchor="DL-ACK-Always-1B-snd-abort-msg-format"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
     Sender-Abort
|----   Header   ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |

]]></artwork></figure></t>

<!-- End Section SCHC Sender-Abort Message Format-->
]]></artwork>
            </figure>
</section>
          <section anchor="DL-ACK-Always-1B-rcv-abort-msg" title="SCHC numbered="true" toc="default">
            <name>SCHC Receiver-Abort Message Format">

<t><figure title="SCHC Format</name>
            <figure anchor="DL-ACK-Always-1B-rcv-abort-msg-format">
              <name>SCHC Receiver-Abort message format" anchor="DL-ACK-Always-1B-rcv-abort-msg-format"><artwork><![CDATA[ Message Format</name>
              <artwork name="" type="" align="center" alt=""><![CDATA[
  Receiver-Abort
|---  Header  ---|
+----------------+--------+-----------------+
| RuleID | C=b'1 | b'1111 |  0xFF (all 1's) |
+--------+-------+--------+-----------------+
| 3 bits | 1 bit | 4 bit  |  8 bit          |

]]></artwork></figure></t>

<!-- End Section SCHC Receiver-Abort Message Format-->
]]></artwork>
            </figure>
</section>

<!--    End Section Downlink ACK-ALways Mode-->
</section>

<!--    End of Section SCHC Fragment Message Formats-->
</section>

<!--<section anchor="schc_sender_abort" title="SCHC Sender-Abort">-->

<!--<t><list style="symbols">-->
<!--<t>As defined in <xref target="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/Sigfox, a SCHC Sender-Abort MUST be sent if the number of repeated All-1s (i.e., with the same bitmap) sent in sequence is greater than or equal to MAX_ACK_REQUESTS. </t>-->

<!--&lt;!&ndash;<t>The Attempts counter MUST be reset when a SCHC ACK is successfully received.</t>&ndash;&gt;-->
<!--</list></t>-->

<!--</section>-->

<!--<section anchor="schc_receiver_abort" title="SCHC Receiver-Abort">-->

<!--<t><list style="symbols">-->
<!--<t>As defined in <xref target="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 SCHC/Sigfox a SCHC Receiver-Abort MUST 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>A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer expires. </t>-->

<!--<t>MAX_ACK_REQUESTS can be increase when facing high error rates. </t>-->

<!--&lt;!&ndash;<t>A SCHC-Receiver Abort can be triggered when the number of ACK attempts is not strictly less than MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, &ndash;&gt;-->
<!--&lt;!&ndash;a SCHC-Receiver Abort MUST be sent if the number of repeated SCHC ACKs sent in a row (i.e., synchronized with the ACK REQ case, and with identical bitmaps) &ndash;&gt;-->
<!--&lt;!&ndash;is greater than or equal to MAX_ACK_REQUESTS.</t>&ndash;&gt;-->

<!--<t>Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC Receiver-Abort Downlink message MUST only be sent when there is a Downlink transmission opportunity.</t>-->
<!--</list></t>-->

<!--</section>-->
<section anchor="padding" title="Padding"> numbered="true" toc="default">
        <name>Padding</name>
        <t>The Sigfox payload fields have different characteristics in Uplink and Downlink.</t>
        <t>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 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>Downlink frames on
        <t>On the other hand hand, Downlink frames have a fixed length. The payload length MUST <bcp14>MUST</bcp14> be 64 bits (i.e., 8 bytes). Hence, if less
information bits are to be transmitted, padding MUST <bcp14>MUST</bcp14> be used with bits equal to 0.
    The receiver MUST <bcp14>MUST</bcp14> remove the added padding bits before the SCHC reassembly process.</t>
      </section>
    </section>
    <section anchor="fragmentation-rules-examples" title="Fragmentation numbered="true" toc="default">
      <name>Fragmentation Rules Examples"> Examples</name>
      <t>This section provides an example of RuleIDs 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 F/R; therefore, this section is divided in two subsections: Rules for Uplink fragmentation and Rules for Downlink fragmentation.
</t>
      <t>For Uplink F/R, multiple header length lengths were described in <xref target="Frag"/>. target="Frag" format="default"/>.
    All of them are part of the SCHC over Sigfox Profile, 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 bytes (2-byte header, option 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, 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" title="Uplink numbered="true" toc="default">
        <name>Uplink Fragmentation Rules Examples"> Examples</name>
        <t>
      The RuleID field for Uplink F/R modes have 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>
 <t><list style="symbols">
     <t>The
        <ul spacing="normal">
          <li>The RuleID field is the first one to be parsed in the SCHC header, starting from the leftmost bits.</t>
     <t>For bits.</li>
          <li><t>For Single-byte SCHC Header F/R modes, it is expected a RuleID field of 3 bits:</t>
          <t><list style="symbols">
        <t>
            if bits is expected:</t>
            <ul spacing="normal">
              <li>If the first 3 leftmost bits have a value different than 0b'111, then it signals a Single-byte SCHC Header F/R mode,
        </t>
              <t>
                  if mode.</li>
              <li>If their value is 0b'111, then it signals a Two-byte SCHC Header F/R mode.
              </t>
        </list></t>
    </list></t>

    <t><list style="symbols">
        <t>For
              </li>
            </ul>
          </li>
          <li><t>For Single-byte SCHC Header F/R modes:</t>
         <t><list style="symbols">
         <t>there
            <ul spacing="normal">
              <li>There are 7 RuleIDs available (with values from 0b'000-0b'110), 0b'000-0b'110); the RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.</t>
             <t>This Header.</li>
              <li>This set of rules Rules is called “standard rules”, "standard rules", and it is used to implement Single-byte SCHC header modes.</t>
             <t>Each Header modes.</li>
              <li>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: mode: Single-byte SCHC Header (2 RuleIDs to allow for SCHC Packet interleaving).</t>
        </list></t>
        <t>For interleaving).</li>
            </ul>
          </li>
          <li><t>For Two-byte SCHC Header F/R modes modes, at least 6 bits for the RuleID field are expected:</t>
                 <t><list style="symbols">
                     <t>the
            <ul spacing="normal">
              <li><t>The 3 first leftmost bits are always 0b'111,</t>
                     <t><list style="symbols">
                     <t>if 0b'111.</t>
                <ul spacing="normal">
                  <li>If the following 3 bits have a different value than 0b'111, then it signals the Two-byte SCHC Header Option 1, </t>
                     <t>if 1.</li>
                  <li>If the following 3 bits are 0b'111, then it signals the Two-byte SCHC Header Option 2.</t>
                         </list></t>
     <t>For 2.</li>
                </ul>
              </li>
              <li>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 Rules is called “extended rules”, "extended rules", and it is used to implement the Uplink ACK-on-Error Mode: mode: Two-byte SCHC Header Option 1.</t>
     <t>For 1.</li>
              <li>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 Rules is used to cover specific cases that previous RuleIDs do not cover. As an example, RuleID 0b’00111111 0b'00111111 is used to transport uncompressed IPv6 packets using the Uplink ACK-on-Error Mode: mode: Two-byte SCHC Header Option 2.</t>
        </list></t>
 </list></t> 2.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="downlink-fragmentation-rules-examples" title="Downlink numbered="true" toc="default">
        <name>Downlink Fragmentation Rules Example">
 <t><list style="symbols"> Example</name>
        <t>For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get values in ranges from 0b'000 to 0b'111.</t>

</list></t>
      </section>
    </section>
    <section anchor="sequence-examples" title="Fragmentation numbered="true" toc="default">
      <name>Fragmentation Sequence Examples"> Examples</name>
      <t>In this section, some sequence diagrams depicting messages 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" title="Uplink numbered="true" toc="default">
        <name>Uplink No-ACK Examples"> Examples</name>
        <t>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.
Last
	The last packet fragment is marked with the FCN = All-1 (1111). </t>

<t>Case
        <t><strong>Case No losses Losses - All fragments are sent and received successfully.</t> successfully.</strong></t>
        <figure title="Uplink anchor="UL-No-ACK-NL">
          <name>Uplink No-ACK No-Losses" anchor="UL-No-ACK-NL"><artwork><![CDATA[ No-Losses</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
Sender                     Receiver
  |-------FCN=6,Seq=1-------->|
  |-------FCN=5,Seq=2-------->|
  |-------FCN=4,Seq=3-------->|
  |-------FCN=3,Seq=4-------->|
  |-------FCN=2,Seq=5-------->|
  |-------FCN=1,Seq=6-------->|
  |-------FCN=15,Seq=7------->| All fragments received
(End)

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>When the first SCHC fragment Fragment is received, the Receiver receiver can calculate the
total number of SCHC fragments 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, downwards and the last fragment with an
FCN equal to 15).</t>

<t>Case losses
        <t><strong>Case Losses on any fragment Any Fragment except the first.</t> First</strong></t>
        <figure title="Uplink anchor="UL-No-ACK-L-1">
          <name>Uplink No-ACK Losses (scenario 1)" anchor="UL-No-ACK-L-1"><artwork><![CDATA[ (Scenario 1)</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
Sender                     Receiver
  |-------FCN=6,Seq=1-------->|
  |-------FCN=5,Seq=2----X    |
  |-------FCN=4,Seq=3-------->|
  |-------FCN=3,Seq=4-------->|
  |-------FCN=2,Seq=5-------->|
  |-------FCN=1,Seq=6-------->|
  |-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
(End)

]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
      <section anchor="ack-on-error-examples-1B-header" title="Uplink numbered="true" toc="default">
        <name>Uplink ACK-on-Error Examples: Single-byte Single-Byte SCHC Header"> Header</name>
        <t>The single-byte Single-byte SCHC header Header ACK-on-Error mode allows sending up to 28 fragments and packet sizes up to
300 bytes. The SCHC fragments Fragments may be delivered asynchronously asynchronously, and Downlink ACK can be sent opportunistically. </t>

<t>Case
        <t><strong>Case No losses</t> Losses</strong></t>
        <t>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 MUST <bcp14>MUST</bcp14> enable the Downlink, Downlink and
	wait for an ACK.</t>

        <figure title="Uplink anchor="UL-ACKoE-NL">
          <name>Uplink ACK-on-Error No-Losses" anchor="UL-ACKoE-NL"><artwork><![CDATA[ No-Losses</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          |<- Compound ACK,W=1,C=1 --| C=1
        (End)

]]></artwork></figure>

<t>Case
]]></artwork>
        </figure>
        <t><strong>Case Fragment losses Losses in first window</t> the First Window</strong></t>
        <t>In this case, fragments are lost in the first window (W=0).
After the first All-0 message arrives, the Receiver receiver
leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.</t>
        <t>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 title="Uplink anchor="UL-ACKoE-LW1">
          <name>Uplink ACK-on-Error Losses on in the First Window" anchor="UL-ACKoE-LW1"><artwork><![CDATA[ Window</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5--X   |                    __
          |-----W=0,FCN=1,Seq=6----->|                   | W=0
DL Enable |-----W=0,FCN=0,Seq=7----->| Missing Fragments<- FCN=5,Seq=2
          |<- Compound ACK,W=0,C=0 --| Bitmap:1011011    | FCN=2,Seq=5
          |-----W=0,FCN=5,Seq=9----->|                    --
          |-----W=0,FCN=2,Seq=10---->|
          |-----W=1,FCN=6,Seq=11---->|
          |-----W=1,FCN=5,Seq=12---->|
          |-----W=1,FCN=4,Seq=13---->|
DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

]]></artwork></figure>

<t>Case
]]></artwork>
        </figure>
        <t><strong>Case Fragment All-0 lost Lost in first window (W=0)</t> the First Window (W=0)</strong></t>
        <t>In this example, the All-0 of the first window (W=0) is lost. Therefore,
the Receiver receiver waits for the next All-0 message of intermediate windows, windows or All-1 message of last window to generate
the corresponding SCHC ACK, notifying the absence of which indicates that the All-0 of window 0.</t> 0 is absent.</t>
        <t>The sender resends the missing All-0 messages (with any other missing
fragment from window 0) without opening a reception opportunity.</t>
        <figure title="Uplink anchor="UL-ACKoE-LA0W1">
          <name>Uplink ACK-on-Error All-0 Lost on in the First Window" anchor="UL-ACKoE-LA0W1"><artwork><![CDATA[ Window</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->| DL Enable
	  |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|                    __
          |-----W=1,FCN=4,Seq=10---->|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
          |<-Compound ACK,W=0,C=0 ---| Bitmap:1111110    |__
          |-----W=0,FCN=0,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>In the following diagram, besides the All-0 All-0, there are other fragment losses in the first window (W=0).</t>
        <figure title="Uplink anchor="UL-ACKoE-LA0FW1">
          <name>Uplink ACK-on-Error All-0 and other Other Fragments Lost on in the First Window" anchor="UL-ACKoE-LA0FW1"><artwork><![CDATA[ Window</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7--X   |
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|                    __
          |-----W=1,FCN=4,Seq=10---->|                   |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2
          |<--Compound ACK,W=0,C=0 --| Bitmap:1010110    |FCN=3,Seq=4
          |-----W=0,FCN=5,Seq=13---->|                   |FCN=0,Seq=7
          |-----W=0,FCN=3,Seq=14---->|                    --
          |-----W=0,FCN=0,Seq=15---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16---->|
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>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) MUST <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 title="Uplink anchor="UL-ACKoE-LFW12-1">
          <name>Uplink ACK-on-Error All-0 and other Other Fragments Lost on in the First and Second Windows (1)" anchor="UL-ACKoE-LFW12-1"><artwork><![CDATA[ (1)</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |                    __
          |-----W=0,FCN=2,Seq=5----->|                   |W=0
          |-----W=0,FCN=1,Seq=6----->|                   |FCN=5,Seq=2
DL enable 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----->|                   |FCN=6,Seq=8
          |-----W=1,FCN=4,Seq=10-X   |                   |FCN=4,Seq=10
DL enable Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
          |<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
          |-----W=0,FCN=5,Seq=13---->|        W=1:0100001
          |-----W=0,FCN=3,Seq=14---->|
          |-----W=0,FCN=0,Seq=15---->|
          |-----W=1,FCN=6,Seq=16---->|
          |-----W=1,FCN=4,Seq=17---->| All fragments received
DL enable Enable |-----W=1,FCN=7,Seq=18---->|
          |<-Compound ACK,W=1,C=1----| C=1
        (End)

]]></artwork></figure>

<t>Similar
]]></artwork>
        </figure>
        <t>The figure below is a similar case as above, above but with fewer fragments in the second window (W=1)</t> (W=1).</t>
        <figure title="Uplink anchor="UL-ACKoE-LFW12-2">
          <name>Uplink ACK-on-Error All-0 and other Other Fragments Lost on in the First and Second Windows (2)" anchor="UL-ACKoE-LFW12-2"><artwork><![CDATA[ (2)</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|                     __
          |-----W=0,FCN=1,Seq=6----->|                    |W=0
DL enable 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 Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1
          |<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110,|FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11---->|        W=1:0000001 |__
          |-----W=0,FCN=3,Seq=12---->|
          |-----W=0,FCN=0,Seq=13---->|
          |-----W=1,FCN=6,Seq=14---->| All fragments received
DL enable Enable |-----W=1,FCN=7,Seq=15---->|
          |<-Compound ACK, W=1,C=1---| C=1
        (End)

]]></artwork></figure>

<t>Case
]]></artwork>
        </figure>
        <t><strong>Case SCHC ACK is lost</t> Lost</strong></t>
        <t>SCHC over Sigfox does not implement the SCHC ACK REQ message. Instead, it uses the SCHC All-1 message to request a SCHC ACK, ACK when required.</t>
        <figure title="Uplink anchor="UL-ACKoE-ACKL">
          <name>Uplink ACK-on-Error ACK Lost" anchor="UL-ACKoE-ACKL"><artwork><![CDATA[ Lost</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
       Sender                     Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
          |<-Compound ACK,W=1,C=1 ---| C=1
        (End)

]]></artwork></figure>

<t>Case
]]></artwork>
        </figure>
        <t><strong>Case SCHC Compound ACK at the end</t> End</strong></t>
        <t>In this example, SCHC Fragment losses are found in both window 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 notifying indicating fragment losses of on both windows.
</t>
        <figure title="Uplink anchor="UL-ACKoE-LFW12-3">
          <name>Uplink ACK-on-Error Fragments Lost on in the First and Second Windows with one One Compound ACK" anchor="UL-ACKoE-LFW12-3"><artwork><![CDATA[ ACK</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2--X   |
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4--X   |
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|                     __
DL enable Enable |-----W=0,FCN=0,Seq=7----->| 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 Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1
          |<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110 |FCN=6,Seq=8
          |-----W=0,FCN=5,Seq=11---->|        W=1:0000001  --
          |-----W=0,FCN=3,Seq=12---->|
          |-----W=1,FCN=6,Seq=13---->| All fragments received
DL enable Enable |-----W=1,FCN=7,Seq=14---->|
          |<-Compound ACK, W=1, C=1 -| C=1
        (End)

]]></artwork></figure>
]]></artwork>
        </figure>
        <t>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" title="SCHC numbered="true" toc="default">
        <name>SCHC Abort Examples">

 <t>Case Examples</name>
        <t><strong>Case SCHC Sender-Abort</t> Sender-Abort</strong></t>
        <t>The sender may need to send a Sender-Abort to stop the current communication.
This may happen, for For example, this may happen if the All-1 has been sent MAX_ACK_REQUESTS times.</t>
        <figure title="Uplink anchor="UL-ACKoE-SndAbt">
          <name>Uplink ACK-on-Error Sender-Abort" anchor="UL-ACKoE-SndAbt"><artwork><![CDATA[ Sender-Abort</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
      (no ACK)
          |-----W=1,FCN=6,Seq=8----->|
          |-----W=1,FCN=5,Seq=9----->|
          |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK  (1)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK  (2)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK  (3)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK  (4)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK  (5)
          | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
        (End)

]]></artwork></figure>

<t>Case Receiver-Abort</t>
]]></artwork>
        </figure>
        <t><strong>Case Receiver-Abort</strong></t>
        <t>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> Enable.</t>
        <figure title="Uplink anchor="UL-ACKoE-RcvAbt">
          <name>Uplink ACK-on-Error Receiver-Abort" anchor="UL-ACKoE-RcvAbt"><artwork><![CDATA[ Receiver-Abort</name>
          <artwork name="" type="" align="center" alt=""><![CDATA[
        Sender                    Receiver
          |-----W=0,FCN=6,Seq=1----->|
          |-----W=0,FCN=5,Seq=2----->|
          |-----W=0,FCN=4,Seq=3----->|
          |-----W=0,FCN=3,Seq=4----->|
          |-----W=0,FCN=2,Seq=5----->|
          |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
          |<------  RECV ABORT ------| under-resourced
       (Error)

]]></artwork></figure>
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="security-considerations" title="Security considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The radio protocol authenticates and ensures the integrity of each message.
    This is achieved by using a unique device Device ID and an AES-128 based AES-128-based message authentication code,
ensuring that the message has been generated and sent by the device (see <xref target="sigfox-spec"/> target="sigfox-spec" format="default"/>, Section 3.8)  or network Network (see <xref target="sigfox-spec"/> target="sigfox-spec" format="default"/>, Section 4.3) with the ID claimed in the message <xref target="sigfox-spec"/>.</t> target="sigfox-spec" format="default"/>.</t>
      <t>Application data can may or may  not  be encrypted at the application layer or not, layer, depending on the criticality of the use case.
This flexibility allows providing a balance between cost and effort vs. 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 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"/> target="sigfox-spec" format="default"/>, Section 5.3. Note 5.3; note that further documentation is available at Sigfox upon request).</t>
      <t>The radio protocol has protections against replay attacks, and the cloud-based core network Network provides firewalling firewall protection against undesired incoming communications <xref target="sigfox-spec"/>.</t> target="sigfox-spec" format="default"/>.</t>
      <t>The previously described security mechanisms do not guarantee an E2E end-to-end security between the Device device SCHC C/D + F/R and the Network SCHC C/D + F/R: F/R; potential security threats described in <xref target="RFC8724"/> target="RFC8724" format="default"/> are applicable to the profile specified in this document.</t>
      <t>In some circumstances, sending device location information is
privacy-sensitive.
privacy sensitive. The Device Geolocation parameter provided by the
Network
   is optional, therefore optional; therefore, it can be omitted to protect this aspect of
the device privacy.</t>
<!--

<section anchor="security-considerations-for-header-compression" title="Security considerations for header compression">
<t>A malicious header compression could cause the reconstruction of a
wrong packet that does not match with the original one, such corruption
may be detected with end-to-end authentication and integrity mechanisms.
Denial of Service may be produced but its arise other security problems
that may be solved with or without header compression.</t>

</section>
<section anchor="security-considerations-for-fragmentation" title="Security considerations for fragmentation">
<t>This subsection describes potential attacks to LPWAN fragmentation
and suggests possible countermeasures.</t>

<t>A node can perform a buffer reservation attack by sending a first
fragment to a target.  Then, the receiver will reserve buffer space
for the IPv6 packet.  Other incoming fragmented packets will be
dropped while the reassembly buffer is occupied during the reassembly
timeout.  Once that timeout expires, the attacker can repeat the same
procedure, and iterate, thus creating a denial of service attack.
The (low) cost to mount this attack is linear with the number of
buffers at the target node.  However, the cost for an attacker can be
increased if individual fragments of multiple packets can be stored
in the reassembly buffer.  To further increase the attack cost, the
reassembly buffer can be split into fragment-sized buffer slots.
Once a packet is complete, it is processed normally.  If buffer
overload occurs, a receiver can discard packets based on the sender
behavior, which may help identify which fragments have been sent by
an attacker.</t>

<t>In another type of attack, the malicious node is required to have
overhearing capabilities.  If an attacker can overhear a fragment, it
can send a spoofed duplicate (e.g., with random payload) to the
destination. If the LPWAN technology does not support suitable protection
(e.g., source authentication and frame counters to prevent replay attacks),
a receiver cannot distinguish legitimate from spoofed fragments.  Therefore,
the original IPv6 packet will be considered corrupt and will be dropped.
To protect resource-constrained nodes from this attack, it has been proposed
to establish a binding among the fragments to be transmitted by a node,
by applying content-chaining to the different fragments, based on cryptographic
hash functionality.  The aim of this technique is to allow a receiver to
identify illegitimate fragments.</t>

<t>Further attacks may involve sending overlapped fragments (i.e.,
comprising some overlapping parts of the original IPv6 datagram).
Implementers should make sure that correct operation is not affected
by such event.</t>

<t>In Window mode – ACK on error, a malicious node may force a fragment sender to resend a fragment a number of times, with the aim to increase consumption of the fragment sender’s resources. To this end, the malicious node may repeatedly send a fake ACK to the fragment sender, with a bitmap that reports that one or more fragments have been lost. In order to mitigate this possible attack, MAX_FRAG_RETRIES may be set to a safe value which allows to limit the maximum damage of the attack to an acceptable extent. However, note that a high setting for MAX_FRAG_RETRIES benefits fragment delivery reliability, therefore the trade-off needs to be carefully considered.</t>

</section>
-->
</section>
    <section anchor="ianaconsiderations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

<section anchor="acknowledgements" title="Acknowledgements">

<t>Carles Gomez has been funded in part by the Spanish Government
   through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
   grant, and the PID2019-106808RA-I00 grant, and by Secretaria
   d'Universitats i Recerca del Departament d'Empresa i Coneixement de
   la Generalitat de Catalunya 2017 through grant SGR 376.</t>
<t>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.</t>
<t>Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
<t>Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893.</t>
<t>The authors would like to thank Ana Minaburo, Clement Mannequin, Rafael Vidal, Julien Boite, Renaud Marty, and Antonis Platis for their useful comments and implementation design considerations.</t>

</section>
  </middle>
  <back>

  <!--
    <references title='Normative References'>

<reference  anchor="RFC4944" target='https://www.rfc-editor.org/info/rfc4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'><organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></author>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4944'/>
<seriesInfo name='DOI' value='10.17487/RFC4944'/>
</reference>

<reference  anchor="RFC2460" target='https://www.rfc-editor.org/info/rfc2460'>
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></author>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></author>
<date year='1998' month='December' />
<abstract><t>This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2460'/>
<seriesInfo name='DOI' value='10.17487/RFC2460'/>
</reference>

<reference  anchor="RFC7136" target='https://www.rfc-editor.org/info/rfc7136'>
<front>
<title>Significance of IPv6 Interface Identifiers</title>
<author initials='B.' surname='Carpenter' fullname='B. Carpenter'><organization /></author>
<author initials='S.' surname='Jiang' fullname='S. Jiang'><organization /></author>
<date year='2014' month='February' />
<abstract><t>The IPv6 addressing architecture includes a unicast interface identifier that is used in the creation of many IPv6 addresses. Interface identifiers are formed by a variety of methods.  This document clarifies that the bits in an interface identifier have no meaning and that the entire identifier should be treated as an opaque value.  In particular, RFC 4291 defines a method by which the Universal and Group bits of an IEEE link-layer address are mapped into an IPv6 unicast interface identifier.  This document clarifies that those two bits are significant only in the process of deriving interface identifiers from an IEEE link-layer address, and it updates RFC 4291 accordingly.</t></abstract>
</front>
<seriesInfo name='RFC' value='7136'/>
<seriesInfo name='DOI' value='10.17487/RFC7136'/>
</reference>

<reference  anchor="RFC5795" target='https://www.rfc-editor.org/info/rfc5795'>
<front>
<title>The RObust Header Compression (ROHC) Framework</title>
<author initials='K.' surname='Sandlund' fullname='K. Sandlund'><organization /></author>
<author initials='G.' surname='Pelletier' fullname='G. Pelletier'><organization /></author>
<author initials='L-E.' surname='Jonsson' fullname='L-E. Jonsson'><organization /></author>
<date year='2010' month='March' />
<abstract><t>The Robust Header Compression (ROHC) protocol provides an efficient, flexible, and future-proof header compression concept.  It is designed to operate efficiently and robustly over various link technologies with different characteristics.</t><t>The ROHC framework, along with a set of compression profiles, was initially defined in RFC 3095.  To improve and simplify the ROHC specifications, this document explicitly defines the ROHC framework and the profile for uncompressed separately.  More specifically, the definition of the framework does not modify or update the definition of the framework specified by RFC 3095.</t><t>This specification obsoletes RFC 4995.  It fixes one interoperability issue that was erroneously introduced in RFC 4995, and adds some minor clarifications.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5795'/>
<seriesInfo name='DOI' value='10.17487/RFC5795'/>
</reference>

    </references>

-->

   <references title='Normative References'>

<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>

<!--
<reference anchor="I-D.ietf-lpwan-overview">
<front>
<title>LPWAN Overview</title>

<author initials='S Ed' surname='Farrell' fullname='Stephen Farrell'>
    <organization />
</author>

<date month='May' year='2018' />

<abstract><t>Low Power Wide Area Networks (LPWAN) 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='Internet-Draft' value='draft-ietf-lpwan-overview-07' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lpwan-overview-07.txt' />
</reference>
-->

<?rfc include='reference.RFC.8724'?>
<!--

<displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml"/>

<reference anchor="I-D.ietf-lpwan-ipv6-static-context-hc"> anchor='RFC9441' target='https://www.rfc-editor.org/info/rfc9441'>
<front>
<title>LPWAN Static Context Header Compression (SCHC) and fragmentation for IPv6 and UDP</title>

<author initials='A' surname='Minaburo' fullname='Ana Minaburo'>
    <organization />
</author>
<author initials='L' surname='Toutain' fullname='Laurent Toutain'>
    <organization />
</author>
<author initials='C' surname='Gomez' fullname='Carles Gomez'>
    <organization />
</author>
<author initials='D' surname='Barthel' fullname='Dominique Barthel'>
    <organization />
</author>
<author initials='JC' surname='Zuniga' fullname='Juan Carlos Zuniga'>
    <organization />
</author>

<date month='October' day='22' year='2018' />

<abstract><t>   This document describes a header compression scheme and fragmentation
   functionality for very low bandwidth networks.  These techniques are
   specially tailored for LPWAN (Low Power Wide Area Network) networks.

   The Static
<title>Static Context Header Compression (SCHC) offers a great level of
   flexibility when processing the header fields.  SCHC compression is
   based on a common static context stored in a LPWAN device and in the
   network.  Static context means that the stored information does not
   change during the packet transmission.  The context describes the
   field values and keeps information that will not be transmitted
   through the constrained network.

   SCHC must be used for LPWAN networks because it avoids complex
   resynchronization mechanisms, which are incompatible with LPWAN
   characteristics.  And also because in most cases, IPv6/UDP headers
   are reduced to a small identifier called RuleID.  Eventhough
   sometimes, a SCHC compressed packet will not fit in one L2 PDU, and
   the SCHC fragmentation protocol will be used.  The SCHC fragmentation
   and reassembly mechanism is used in two situations: for SCHC-
   compressed packets that still exceed the L2 PDU size; and for the
   case where the SCHC compression cannot be performed.

   This document describes the SCHC compression/decompression framework
   and applies it to IPv6/UDP headers.  This document also specifies a
   fragmentation and reassembly mechanism that is used to support the
   IPv6 MTU requirement over LPWAN technologies.  Fragmentation is
   mandatory for IPv6 datagrams that, after SCHC compression or when it
   has not been possible to apply such compression, still exceed the L2
   maximum payload size.  Similar solutions for other protocols such as
   CoAP will be described in separate documents.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-lpwan-ipv6-static-context-hc-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-lpwan-ipv6-static-context-hc-16.txt' />
</reference>
-->

<reference anchor="I-D.ietf-lpwan-schc-compound-ack">
<front>
<title>SCHC Compound ACK</title> Acknowledgement (ACK)</title>
<author initials='JC' surname='Zuniga' fullname='Juan Carlos Zuniga'>
    <organization /> initials="JC." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
<organization>Cisco</organization>
</author>
<author initials='C' surname='Gomez' fullname='Carles Gomez'>
    <organization /> initials="C." surname="Gomez" fullname="Carles Gomez">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<author initials='S' surname='Aguilar' fullname='Sergio Aguilar'>
    <organization /> initials="S." surname="Aguilar" fullname="Sergio Aguilar">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<author initials='L' surname='Toutain' fullname='Laurent Toutain'>
    <organization /> initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization>IMT-Atlantique</organization>
</author>
<author initials='S' surname='Cespedes' fullname='Sandra Cespedes'>
    <organization /> initials="S." surname="Céspedes" fullname="Sandra Céspedes">
<organization>Concordia University</organization>
</author>
<author initials='D' surname='Wistuba' fullname='Diego Wistuba'>
    <organization /> initials="D." surname="Wistuba" fullname="Diego S. Wistuba La Torre">
<organization>NIC Labs, Universidad de Chile</organization>
</author>
<date month='January' year='2023' />

<abstract><t>The present document describes an extension to the SCHC (Static Header Compression and Fragmentation) protocol. It defines a SCHC Compound ACK message
format, which is intended to reduce the number of Downlink transmissions (i.e., SCHC ACKs) by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK). </t>
<t>The message format is generic, and can be used for instance by any the four LWPAN technologies defined in <xref target="RFC8376"/>, being Sigfox, LoRaWAN, NB-IoT and IEEE 802.15.4w. </t></abstract> month="July" year="2023"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-lpwan-schc-compound-ack-10' />
<format type='TXT'
        target='httpsout-://www.ietf.org/internet-drafts/draft-ietf-lpwan-schc-compound-ack-10.txt' /> 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">
          <front>
            <title>Sigfox Device Radio Specifications</title>
    <author initials="" surname="Sigfox" fullname="Sigfox">
      <organization></organization>
            <author>
              <organization>Sigfox</organization>
            </author>
    <date />
          </front>
        </reference>
      </references>

	<references title='Informative References'>

<?rfc include='reference.RFC.8376'?>
      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml"/>

        <reference anchor="sigfox-docs" target="https://support.sigfox.com/docs">
          <front>
            <title>Sigfox Documentation</title>
    <author initials="" surname="Sigfox" fullname="Sigfox">
      <organization></organization>
            <author>
              <organization>Sigfox</organization>
            </author>
    <date />
          </front>
        </reference>

        <reference anchor="sigfox-callbacks" target="https://support.sigfox.com/docs/callbacks-documentation">
          <front>
            <title>Sigfox Callbacks</title>
    <author initials="" surname="Sigfox" fullname="Sigfox">
      <organization></organization>
            <author>
              <organization>Sigfox</organization>
            </author>
    <date />
          </front>
        </reference>

<reference anchor='I-D.ietf-core-comi'> anchor="I-D.ietf-core-comi" target="https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-12">
<front>
<title>CoAP Management Interface (CORECONF)</title>
<author fullname='Michel Veillette'> initials="M." surname="Veillette" fullname="Michel Veillette" role="editor">
<organization>Trilliant Networks Inc.</organization>
</author>
<author fullname='Peter initials="P." surname="van der Stok" fullname="Peter van der Stok'> Stok" role="editor">
<organization>consultant</organization>
</author>
<author fullname='Alexander Pelov'> initials="A." surname="Pelov" fullname="Alexander Pelov">
<organization>Acklio</organization>
</author>
<author fullname='Andy Bierman'> initials="A." surname="Bierman" fullname="Andy Bierman">
<organization>YumaWorks</organization>
</author>
<author fullname='Ivaylo Petrov'>
	 <organization>Acklio</organization> initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
<organization>Universität Bremen TZI</organization>
</author>
<date day='17' month='January' year='2021'/>
      <abstract>
	 <t>   This document describes a network management interface for
   constrained devices and networks, called CoAP Management Interface
   (CORECONF).  The Constrained Application Protocol (CoAP) is used to
   access datastore and data node resources specified in YANG, or SMIv2
   converted to YANG.  CORECONF uses the YANG to CBOR mapping and
   converts YANG identifier strings to numeric identifiers for payload
   size reduction.  CORECONF extends the set of YANG based protocols,
   NETCONF and RESTCONF, with the capability to manage constrained
   devices and networks.

	 </t>
      </abstract> month="March" day="13" year="2023"/>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-core-comi-11'/>
   <format target='https://www.ietf.org/archive/id/draft-ietf-core-comi-11.txt' type='TXT'/>
</reference>

<reference anchor='RFC7252' target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname='Z. Shelby' initials='Z.' surname='Shelby'><organization/></author>
<author fullname='K. Hartke' initials='K.' surname='Hartke'><organization/></author>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<date month='June' year='2014'/>
<abstract><t>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>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='RFC6241' target='https://www.rfc-editor.org/info/rfc6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author fullname='R. Enns' initials='R.' role='editor' surname='Enns'><organization/></author>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'><organization/></author>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenwaelder'><organization/></author>
<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><organization/></author>
<date month='June' year='2011'/>
<abstract><t>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='RFC8040' target='https://www.rfc-editor.org/info/rfc8040'>
<front>
<title>RESTCONF Protocol</title>
<author fullname='A. Bierman' initials='A.' surname='Bierman'><organization/></author>
<author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'><organization/></author>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></author>
<date month='January' year='2017'/>
<abstract><t>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'>
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author fullname='T. Bray' initials='T.' role='editor' surname='Bray'><organization/></author>
<date month='December' year='2017'/>
<abstract><t>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>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='RFC8949' target='https://www.rfc-editor.org/info/rfc8949'>
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></author>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></author>
<date month='December' year='2020'/>
<abstract><t>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>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'/> name="Internet-Draft" value="draft-ietf-core-comi-12"/>
</reference>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
      </references>
    </references>

<!--
    <section anchor="note" title="Note">
<t>Carles Gomez anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t><contact fullname="Carles Gomez"/> has been funded in part by the Spanish Government
(Ministerio de Educacion, Cultura y Deporte)
   through the Jose
Castillejo 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 CAS15/00336, SGR 376 and 2021 grant SGR 00330.</t>
      <t><contact fullname="Sergio Aguilar"/> has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P.  Part of his contribution to this work TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).</t>
      <t><contact fullname="Sandra Cespedes"/> has been carried out during his stay as a visiting scholar at funded in part by the
Computer Laboratory of ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
      <t><contact fullname="Diego Wistuba"/> has been funded by the University of Cambridge.</t> ANID Chile Project FONDECYT Regular 1201893.</t>
      <t>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>
-->
  </back>

<!-- ##markdown-source:
H4sIAH4u6lkAA+2923bcVpIo+I6vwJHXssliZoqkZdlmW56mSNFmt0RxRMrq
M1VtLzATJFHKBLIBJCmWU7X6H87TeZvH+Y6ZP+kvmbjuHRtAXijLVa5eZpVt
MnNfY8eOe8Tu9/tRVSf56KdkXOTpXlyXszTKpiX9VtW729tfb+9Go2KYJxP4
elQml3U/S+vL/nh6m+T9bHrzuA8j1NmwPyzyOn1X96+H/e0vo2FS78VZfllE
02wviuPqblKml9Ve/NldWn2GHxRl3fikLrNh7f8eFpNpYj+oi6H+UWf1GBb0
/PTN/kl8RguID3gB8fdpMkpL+HMyLdOqyoo83jg7+P5gM4adxpdlcjVJc+wC
X1wWZXx8evOYvnp9eBolFxdleuNGhm7R7dVeTNuN3xTl2yy/ir8ri9k0Smb1
dVHuRX3YJ2xjfxC/yPLkYlYWsFYG2H6e2A+LEobaH74dZwXvN01he7sXWRUD
4ONRGo+T+OA6qZPsKk/LJEsRDFl9txd//sUXO9vxAeynyPtn6Q02gD9H6TuC
1CyvS2h1VCb5EDulkyQb78Gukn9OYL4BTCjLfD6Iz4sZzJC7VT5PZiVAxHxO
Cz1+cd7fr8dJXmf/AavzK4bf+vHukiX344OzeOfLx4AHZv1fPr73+mVlA1nZ
P2eTup+4JQ0uS93VwSD+rpikf3F7OkjKcVq5D2lDr/PsJi2rDM4+Pi3GWf3/
/T/DPBsmuIsD2MF4lt8l5mB4Jw+fVXV6k8bnaVkmo6TqxV/yN9tfffUYjiSB
r8fjUXqZjiu7l7Mpw1K2MqQFXRX/DPtJx4PZdDhIR7MoL8oJoOJNilB9dXTw
6OtHj2hm+H330eNt/f3Lnc8fS5Mvvvz6i70I75Z2jbHRcf9wYK5mAVu9ydLb
vSjq9/txcgG7gtsURefXgG5wpWd4C2Dr1bDMLgBUSXzNF2doLk41vE4nadfF
meVD/CUBMN7FEd4jmPAuHhe38QU0v81G9XWcp/Ut3JkKcO46rdK4TofXOR4d
TFemcTVNh1kyHt/FcLrjokxHdCH57m08h6FOi1tY0ZsMTmi/TJP4hAfc9CPj
htL1SUBxeQkoAJu9guHqeAwnO4YP48tx+i67yHg3t9dpHk/LYoh94b7XMIMA
5zJLxyPYD44WQAqAepFUsAP4PcFvJgg+XpaQRviT9phhC97kCG7CkOELn+I8
srGBbkn7TtIkr6AFLBqbuaEEC2CyUQFgzYs6Hl4n+RXczVmpiwc6+jaFjnC9
qklGC6YjcaN7NMDmtMn4Bi4EHhSs7W2aTqtgMlrIbTYe04wXqY5d17Cq+hoI
5NU1jQUzIOZlOXzu9hZFBL8J8BjsO6uCk9ezha+GCXwXZ3Wc3BTZqCKIw0nF
APW7fAjT5NlfeEGTFLedVRO4oLfX2fCaMCzLiYvU2cU4jW4zQEmeAtribUjL
rAIgw3nuwy6TcVX4OWHIApY3hEOFIZFJPAQGIXjA+AsnMBumo6gu4ECrCWBy
DJgKxAkACPcI/oZ9vZqN0/j4cBA/u4GvrgkwFZClOpvgwEmIStBBDssB9xK2
D6sBBh0/341PD1/36EwQuNQ1vJiAtsAnizH3F+DyYXe0xoHgIsC8kwu4hg6I
iM50KoiVt0UMRHNGPYDW4kHhUP3WmgU/AaQwdfpumKa8TF42DPKX9J+YlsAQ
hBwAXDitFGDptmMv1TDJBb2maYnIh1tZTMK6xng4Su2IsP1JithF60im03EG
HQHCeIjNQ0aw2ZkIQYhoXWZEMdcEJkFFIQrzVLPpFMQfWi9JHy/OX0PP/5hl
ZUoTIfEWTCWSWYyLK5hxgAzSTAhDTmDSBGjBnRdl4O/kCrbJpwHIcgl43oYt
NCc6B3u/Tiq5xkj3CvgergsuFOFzB8uF22S69jpPeJK8yyazCaDC3bhIRnTa
QMWySTZOSsD48Yzwh9ZZQJ/SoWrFM8AiDor9U4e4eq6EhFU6hRtbp+4wKkQE
5GyTbDSCyx1Hn8THwHkLuJIEnJ8/sX++j6Lv2+wtACDsN728zIYZjA67viDq
CWOkJRAkpGN5CkPdIIeApkSrixFTFUPRPf2GO94kaLBjQOQakQdQGzeZvpuO
i6xmvLiCeeBjtwrBw8gsGdj5H0BQmyJG3OH6gcWU/aLE5umoh8sCqRp4Q4zU
yNN+hPsYmTMxD7gD8Hl9PQC54UjuYg5nWSErrAnnUdSn4YDSDa9hhcMaZDFd
djWbTJISTpjWfUhcrIo34JdNFHneEQtC+FmeYejvPl68IX98BoIKnMsGfLbp
WIdj9fF3cOq3yV28cfLdm008dNg/LA5ABEy7uGVKjKQazuxtXtzmxF9HNyhJ
AhLiv0eyPriXsOCLWTYGLQZls8QvA/AJpYcyYUxAkM9qJPQAHiDtZT29BgoM
BDtPb4N+QqRgNDzOpMpgHSCT1kT97yueIOTTS2KWTCPhgzS/yYDRIdIPmG8C
HalIyODhmICKgGIBDp3fptNaRQsVYeh72Bf8IRROR4JfI5FZNrCHiACEFA0R
CC6iFTaIYiFL22RWjWcfrcet1+bRx8KSZTn35Mxuj45DMysRltEh/AbcMMtH
6TTNR0SeeQHCCYZNSn3H0GApJKtDThxFbbpOSybm4vcMV6sXJSBEXjG1hJ1e
3MFmSMqW7RGpj2c5ykf56CEgjCW+0c8/L9AJ3r8fxPH3IFrD3z0SRmRLKqLL
uiI5Y+VX4+QOTxnkgYDxWaqDcClyuALFVBVsuBn48WQ9zncZ7+x+tQ17rWH+
+OefRQ96/x4PAbuhcAatmszXyT0sIEegqk3lK172RYrkDyeFcz93NE7uW8Xw
b44ahXrOPXl3FDLvM+Ry4YDIeYnrArNDlXgEp4loSHS3Aio79dK2P+wypcuL
d8xJiddAk1KkzfUtjocDIJ7DHCI6Yeu2vNLdzksxgK+fKM22fODnT+jDPn34
vhOpr5MbJMDM/y0TgS3PYDsZqmIIMUB3mJVuziB+wzxGbumdbxbVd1OmRbRe
EtuQ7cLHQIrHIasFrE5hkT8fZVd9+oLmf/8e2CdgYxGHLIvuH0Ni1FdmAbfp
GqgNNEkHVwMYL68KuIXYH37gks5QbIBrmdbDwSZJ2J4/gjKdAReDTVQIWli0
DgtQjstklAG3Z8Y20CUhKXpF3ziW9+q7TdVmBPthhSChZZ4IWf1qnOVvg+E6
eagOlaFoo2INoANKMwH+hItRbFGJCEiITiWosL8vvFzXjCS3RPlO7i2gwQx+
heMbBhioMA248Ru+6tgVEcRMUrHAoJrabUrnh5eArgyxHh5R1GViooTjQLIT
kMNe7R8evz7DIz7MQBZC+TghUfDuIXEYPwvyuR7hK1xxMlXcogyafwZkPUHc
LWSqEtU8mq+YodAtmnRw25URyKVwR7VIGoqiv8KPTLDWz1affraieGMT/vT/
wp95d585Q3YecVP4h/+PPw/jP4Uj4+A0FIIonkeute/2EL7/0xP8oQl/pDnw
L97a3I7llmpXatc5j7/p9+f9/rf06ZZbwXz/9PT58cH++fHLE1pFbP95KAvw
q7jRVYSfs9CJGwkH4E00wSqbb4FbNwK0RL8J7k7lOsD9k0P9eS/+JKROMRm1
n3zWprafve8+uQiJ87mnnszWKrnPytj0BkkjVnyHIIzdTYySbxXdAQrZAJm9
trSOlhJ7UZEuorD3sEyHKShHqDIhV3QGgeLhZVlMaBFMc3nw09P+8fHhXoD6
RFkuExDYj42Mdgb6OxI9EMGV5rHFfjRCQQ15smMWxDbNiJmOiHM+zfbgnxHw
abmSPRTOhGArHC5A2CJaD9IH9Dk43N+zcvrDw8CasD/0MBl6Tp1V3l5BcjyN
amkBci/RMmgTSSBcI2GCb2GhJExkNXKjDPQpYHMkkqtEH9o2piBNMHhF0QDw
wl4IbEievAFCexnjiIrP2P0QPSByWjDECTIGYRTcn1R+RA38GrF+AgwiQ2Gf
RCAUqAcyEB8zD/aRTliMpsHhHh7DJHq0MM8IUQDAmCFsnQyR0Wd4IqABwf0i
BZU1IZwFGbdYPkh48SKKKELuLCtYUMVbPE+uYGqxucTwF88ZilrB6SqO4NEI
MEkj56PFOVBf0QFQwSzLOzXlUsvAzsPLuIVFoPL7HGSA2CE5jRaYbug2ksZz
8PBQlHcc4OjgZM+ZlxzKw3GfzEBrLtfbFK6U9BlrxChTHMr1ItkduN9VWvYr
siDoqHFOU9F+jhBrjmhkjyq0iJxUsXe4dLUQdWinckHQ+ErDPdfRnqf5VX3N
22GAW/TKLo0BHNpcZu9Suo43SZkRboypP6/xVAc9LUDME43bDdsw+rk50gTF
ObQQoG0ikckSkEzKKlTVScT6Q0w3aNHVSVv3BTElsNmQEoUOpPfvcbgXxwd7
8QtomFzxjbwqUTg5uE6Hb2HG/WWnLGaREWs5cBaG2MP1IRWwoRs6435alvDv
UVoLarJd0g5g1A7a+IuXsFC9qC+BpOL1JWpbyB8OunSfHexR8GSRmFSEYAtk
YVjQENGFjhZ/MdQzGIBpgWsWExvLreWfrjCR3J67amy0R1pZXau6QXdZxpBO
zqaAtq2BX4G0YlNB0468xDVHy9Q17K1hiNLfi9LwOoK6esQaniqyE8MRoY90
gd0dTs9Z1B3pISMW/cW8CYYRphkYYRBqAZujHZ3/sAektkSDKR0HLq/jRJUE
GHcVUAvClVQwwZm5mDDZk6aZXoMU9Hq6HlnF04Vt6Bap/5u9+A0QLHSLZvVg
+e1SIUQ6TJDvbqAiqyLd104dVEq7knnQrm5pwAHJiytRIIrWD6hQr5z4N0Mr
Xy8KVFfSrJxvGONFRFnjy8zymrgGllnjqkjdBa8KADRRN/SJo1XrqbpgiYqj
v9t5TPOEiCGq4mhIYdsxLA0VdVDrYB6QGWqi8bCM0HAvRjI2jUay3Yqkngvn
i5VZRdQhw0LgZK2cv9P7gUmYAAm6YvIg8miUZgSFC2Q3SYnITLY/uIA3GQID
oeYMXiiT3KHWiXtD+IqvGKUfJ9/C9vquOzoK0GoRk/kTlfva+IIBJjprkRtx
B7+QWQjrhnBu3l/gVQejtBqFaO0f0Agiq1e1lK7On2aPCBXEHdQzdvFfny/Q
fe1Ps0fU6LPOEI0/dQg0T99rCO0Af8oYxCfvM4brQH9+hM3III6A/5JBNgTZ
Nj9sEIcgW/dGENfDm1XEsrDl220FXVrjD3zfrb/+NZ6/+m4eP3nyJJ6Deh/L
rw5M88Fg4N2Ig0Fozumad+6gM49XG3/MKkPLQmBUCM0JUcSmUbGKehG9anv8
Gqwu9KeTCm1DX5b4HNAcbgy9555Wki5EZoTQs8Y0elY5q4K4uMnd47zHGlzk
vYEmMAHpJhDUD5Z7mNPhQW6ySo6OF+dqYh837gRaz8Y1LDRqOOAqsnAXpPOo
92Tj+e4mRyLwN8xs2GSkJlu0/Qqvh/FukxL4bERczffrdpESUUdMRJjygRLH
wy65v76XJIxbDsuzkXhqBAuWzpysBEdmoklwIOEw0biAc/N8sNv2jEwJhTqJ
ABijQgOcfIx+rgSVp3qW5+kYIZdWyI2zCkU1a5bGrQUBMChqxVGwpixgXMR3
G2K3katBlt8nXaSB2iZySt3e5ODJAzs4whVYaoR+YnSoOVdE26pbsb0x8Dvi
ap1gDRcpNFBVxjwwLbN8mE3HPniAw1ecpMswdf3RdfMJT0K75EknIByjrpIo
H28FhkjMX0YiOeKQF6MzZ/3huVKKW6tquA5xBOPpLWY/fKAusaNZR3HKUiWK
EkvoLJlXZIwXGc+Ho+CsagWL5Fx08DcYyaJKHbq9aQFw+RELIhawmFKhmyBP
Edzi6acdZnUQtNYI5WDIqXwkGgauHLDTWNc2hpcD8TkN63f1+/dw0s9Q2add
u25ZXaXjS9NbHepkzZhKUAEcSEE09dKZCIyGuXF0fLjZc9+wUQI+fW4+nKpR
YuPolD726kvm7GMbh8f0XW2UqXjj/Af60BnJnLq98eIlh1EnK62i8cbB4f6m
kQcf9n/pz5+iZeICQflkJb9EW/9HWAqMsmgpjOSrFwJLmUcfYykkZxJKtJax
s84yeCkwihGS3P/9z1Zr6uYnWzTKnI1iO/Oj5/Oj0/nh8VxU9R8Qu+Yti84c
UUlwCJFn/vHXsvubWAtKggjqwUD+D3/IZ4jY7te4+5OPtpaHDi4nvwAuH2Mp
D5t6yQf8zKM/tWa678/DUHRG8q2S82I6J9IkitPEIOjCuSjswDjtGJfwLYnB
IokrUrOAcE11l3kh1MjcRSnyJs71Z+wYhL9GCyV1mOA6ucnE/dER0X7MQgRb
LdnN4vhRVwSYs2Z4V5fIIbI52SrHmRkIUaBNGLRrBPbQjO8juW18eZlegTws
HpGsdJwuyvwefNiEM0CTFFylZZaMNQ5NZDkj76PEyEZHbA3L7Gpvz4N6yP4O
OsPpwy2xnadSl5ITrDk+EzcFXB5texTqua9OkEMh8ORhmFEShfdfsKu3NdnA
jvDcywhqkROxobBOD/HjkHxJsgk6QKRhQrZf1cRszJ3xkACPDppTTC9Hg2EA
sx1PIAKSORtmnRrKihtCieJsjNfzIsPI3x9Cb8yqgRJnE4/JyK5LZS/DftOJ
g/KSikjkIrx0kr26baoQaOk7FOUE+wAAChbGQYzcR4gTgdVgfDiyBDRGL6VB
ix3oSgtaJKnZVRntxIv8MHSZurhNvDcqP1Pk0x/i16fPj0/+Nd54Pd3k8G+/
CSELToamMD6BI+5NXfr098WdaoOqEYBm0+M5Dl++OeFZDm8/cBaexJFCGFun
wRnxCvFUT48Pj189O8AokP3n8cbTbOV8OpWYWGdTzPZKJthuBOSX/1LEsDyR
pGK9OTycdz69TR0dAdyqJNg5iu0pBTeTcCAY3t+5JL/DqDaYEV3cVxSjWWO0
X9UDgWBTg7YVF20YQ4IRz1dj59JAbJ8UYhLBUFwYaMZ2nY2kLJO7HmkhNG7P
heEn8b+cvTzh3gdPX77yvYSitMQDVgwEOB3OuTZ8VKMXGPEVZEiocm/BwwBr
z4smeIm+ZBs9jIeZAhTUBZTixUuHZLQakxTVHTqxH1iFFis21rUbsHrTASPM
ZS+NSA1W+HlTMNqKbfSojfP8qXFjqZuMt0RZEp98ou7DKAr8iHyT5SCaQzbE
h5RjO2TNaPgijd+ZBoBBiXatCTLtuCLVwV2kCDHVvvN54iYQkW8SinE2TL4Z
X3rHIgoHDHD+XnGLThQTME1pZsXEUUPrD4TVVlOyPVGwOMX6jUxqSitW5zpx
vroogHsVOvQG8cYZR57Cp2QBaMJcN0sWPLam3VIUBvuTNOax5Rv2gbBt5xjm
9IYxMsOiRJ6gI/QCa5nkenAg0IVKDjqZNfVhYo83O2A4PQgaI42zKospMNI6
Vb85INop0zqfPKm2k0V4pbYvFn8qx2mrOp2yCGRb0xorwEU6nT3CxasiGYu1
yoGAGS+23qg2gwB8yiP3gVeePn9WeSc1mZNGBSJfmDyGTt5bHOD1dAFEHXwo
F9gcAscXzcQorSsl+QKYKkVKHTpygT36mDQoUjlM51LwekzOTDOlRQOc9Jxc
85Rtmk4FLsProhC8ElGJ+XdmzIU9MbTL2hcbi8QmKQNxaLrkguB+qykGcwm3
Nkgyig+P3Umk74bj2UhWfAKrJQTN7cCUvqmohxGLMDqTg0KW3m0V4wTDtgWM
pjq2Upv72mfOug2Y9bA5hxvQ8QXG5xp5G8GbL0Ecv8SwHro/x67p0WkHcNoZ
Oz0ODqLlfVZ5oYXWwszTB+D5ASXiuWXDM45mtxHW/pLaRJpI7IEefrfVb8DQ
06yyMMyqcYOAeNVZBddQW7eGrHDMapOtm7SujWwATB47sCuFEeC8nKWbPZER
ZM5QFxWjviMkHaiy0lRZEUuH5QjDTjoUUpQiLjiyZBC/RCZxm1WiKdPxl4Im
dVrVgtgAr7wAzgm6Pyor2uKymAUIJjO46ADkykiE0dke+tpyF/2ht7mZA0O0
FKbWwUSoYFVQzPNMNg3XVh9VaNhniszkCr+xji3v7orbBgsxGARqb08Iyviu
Na7kLA2Edk05Z9MZxpsJm6oosFkFZ0jf6Vm1Ed3jHq5UTB3nJuqhCQbO8qpU
0w9zvFC3dV48k++FSOOC+634YwK6fBZxPlovlCIWQT99l6DAZOV80V6ynMmo
lBSgpe0q4Mkh5WF1mZWIEnc1ziQ3Cri7Qh+ugPNeHNE5nw7f1iLB/CGULTEa
keVFxyXggMksRVHguDLv4KEdppLWxD4W5HgcxdvPkCNzis2L/QONYWQqzoy+
6hQ3An+Ny7FHJ1Mkpu8rWMhC8xKbqOiyV1UxxGGpbeXExZBIC+rgpa5d2ngt
0rvGfnPIds7aUmD3czaBAAepr/ESMjrLEfvgY3fB+HvcV66Xh5hOoA7CVAcc
pdn/0x80REk9hRILlSL94fhLJdF875EM4iaF2FML5gwtNyHBbjTypgjOPNTo
8F11VF+nLlJZuegEaQdgNKL8V2TS6bHCw8PJmiVdkgyzGAaB1mOyiLcMyfLp
IlMz/A4NKEOD/Ed65ecmyvn7Uck6aFDmYh67fcVzWd78I60ltDj7KxemgZgl
chORsMnoDPL2izZn/fmT4XUy7b94CU1aCrMyXmSbquRUTiqlO+1kWsASSjVD
kNwU4xtPYDs0oVCsJ/y+c3lZaM0YOfUu8Fw7NB+TN7Zh8YjRrY72EPFtUxwD
DGaDLpSK+jBCnMSH0KEMgcTwKBmDjh/D9mldmmedON1jjygd5Xlh7K9xXzN9
FTuOOqklkPj8Bx87LPHjvHEaiPhudpWDHLYXn6Akng7fUpo3WgVV904WTsbi
yPkPgHSGuXVt32c0YC4rZR1hOS9awIuzpxtsKt3EndmmKtRo6DtFaWIuKjIt
zHC7yGonc1lzqyyWvsYKSy2pjPav9IChVItxXqw5Z087LDqsSSXe/NGjvQd2
T6/3M/HA2GGUfbxwrFscsEmV/uxPAO2c/ENqI4wgH/aZV1YmyqdWQ4fxwV+Q
UFvwWlBcjKvrokQyeePNVKFdrx0uoFELFBzghHyj7JDNmgYmwz9R91H6blMU
PDw2bwBjbMwum1hU+RNAXKMDIi3QqAkVjUiUZJXZqxK7l5AX+P29Oj3WspeF
PpFExkT1KRerXLRQiKycFMmVkjCWJh2LEUi5L410oSlCxkFDJ0qqUGR5spyY
EOJOP/zWkr8aP39CT6ZsOPDhWvDMGwBq+DE7faHzJX+1PKGdS7zHLraiOdBr
vgt2YNBhUMyUv2YqJRkFk1ymvAv6qjHGnMJs3F9Yg2PEgo2IjIq2NEJwJ4MR
OPcH/pJ4dxyBP6O6Wxy/DSM89xSvsQb4hv8CkvTyVXt6PQtJdekLzeuCgzSJ
bZOOEYjmV7PJkhHQl2abyQgYH5mNGgOHIzAkj9FIiLAAuYs8JCBG0wj7AMh7
j4DuFh2h07d+D4x62BB0nCeu7V6XDBl7QY5URPExqzrA+/e+Cg3TlIukyoaV
EWuUxQeZloGhPEqsP4ZVpGExnk1yoz4wgfmsotKCYv/mlEU272TlKOJOpNWN
1aC62hcPxOcg1G5JLLBubJb5SXTyoqDx73kVT2u6aHffPppwttcg1NHURqA5
j850qUyPjFFmWgJVpCYIEuQCZUQW7PIi1JDRrYShYnncyLezBj+sjIEMX721
YjFBeYMWGNhL+Oi8Ect704cF2Twoke7Sbw9jLUX62ibw7jzioiPio6BRebxH
4nWmnL+iVOhr950vqP/uF1/0jKLNnXgYPicysew4k6Cuwkz0VWMiTE1RycKO
vbPLg68eF5Bql7fFjqBPYkfegSkz/3afuKsJva9SrOY5VrdZw6nqJIyGr0dQ
AJaCnFZKwrhYTLqjqGH4WOvGlS+0IFGycCGCTtEDEm4egDg/wHNlP98DlrQf
SEUaDpYos+qtS+lNzOV3GM3b6VC4my0HoTeDfMZiOibegppKkKDdaXkwgHRR
1w0jl+hHMl8gzYgo06rU6G9aYAcOTcCa+laqw+aT2HBrhxLms8UnsQAlEBhB
+O3S4/bTNW17BnRCvhzdeLpiVCYNuAhCFSVnbrE9Zz+boPElQ91zw96dcP0U
RL5JqiiWa5MOi044copCQ2mRzGFG8GV3Tc9RsRlxnM/KykVR1NRcXFoooSKX
vUpFdfBmLjNBqI9o9FTT7d5YrcwCTRCCfrGBiiVrblyWcVG8dZZVEL8sz7FY
xLY/+SJ0c9BmBu1bQdmkZD512eFyUZqjy7JCFTJ22h9ekizPJuiCRGzg9BfO
TdGKehqSTlNRKjAeDgqWdIPwl6QJL86VdBHyOA5jmS17oNGBtFohGE27/CBq
UMhFBwLqNZPHfRVQNYuhk2iT8YUQNo2uMfsUiRnBhggnuy8rsksfB9aAptu/
6ZpvwjcKYtYB2DMR37CdfNpaItkKOlDK57g84K4P4udpAmh9ZkwYTzONW7A4
E4nz20b0OG3AgTG4DSKwBOCfwCmx8nHTFZXG0CixCjSlbTKJydkQj+W/PGAl
gZ7SdAGfDp/9AKJ7D5MRUYRX4lxZw53NBlfvD94WqlSZjn2QlkoHKNp3lRLg
Slg4D7ZkrWFT0TKy5QVQlBCtAu3XlC1aVa7iMRVcHM5KYqTtqmARWYUrtYr4
gCUZXU4YtRE+EZElXeGBRjUZtI+Y6DEyPQduEDr3iLv7pCzn+0SajlJuq4Qf
5dHC3OwPaiT3YvgIpn4BPkhAqAsdsw519idofM9FagKGOBUuVVu5g60zxdIX
VGKFscHb9BULhuOEeqCjrI0QCwwhqnB2STdq0dNcPncZjEUcxMiDRjeeVHRK
ia9qOgqMX8Q3aqf1hzr3XrBaF1QqhfKILmaV6m9hRJwLHrKuY4mDgT4dR6JT
EaprYCwHuZqSH02V3i8x8fq7Q1HrMU3GgB2jOw9UOSBfLEAsexJc3b06ayfg
dP6wIvDPn1DcERn0XkrmJSFp+yb2FPd8XUGiTVJPb3xH9AyL3tB20pxI1fUs
B0xlL7zoFcoOkJSUjdo06mTCOsLOi9SR3K/FiOl7YSjKZntYAZvN7ZZg2JWL
chSAIqje2YrdEE4rMmfLo+/Wf/b9/vPneBIXZYH2xSyvffXLqruaZ0apW1oy
AB+1AElrktWS1YqkhAvY9lxVQNLkxmk6Jf+XKXKKJVUdLRLckdB0vkRqJ56m
ZVZQuhh3Ibjbgu/MIjjUDe54Dd/fUdwYVcr0uBhCUWNNkmlC1fEzJjhd6MR6
MxayLNWikOb0G0d/J74sBewkWFrCQTEJVSjG2vywJs07cH1GQGKk+uk449Xc
NSt0O3WMQk5RggEik3F2K3J0pgs4l6TWLhtca5jau8h1bxaXfuWaflgOZoKl
WVD6QMoHtLF03IdMNY3K0P7WseVCiqZSeWdY7lSCHgV9RbPurAgq2A6aCpXr
woGwfjaG9vrnGBhsuguhUFg8MZXlNUqM4igfpcooDtRdaFTWZKqeJhwR6B0y
EsQsw+DAeBxITpx6100CWKSKX7XOtpJi8iEkbOU8b0iqKbR+HYzBuEWs63hS
xPsH/0ouFvldVYyKQmCreq3hGmY7h+OsN9aph4JJwCGn1RBVjHE6klowG7CC
atPW/q3ZlxRGwaX5dcJlszuWdJHeUQgbmRvJYOJYGZWuZTrfuhYayChg4ClV
NpaNvXh9dh6fvDwHIFUgh+BiBwxIWxCnTwOIhxN31OffNylVDkGN0PKf6/ao
+glmg2OosJYmRe6VEzKNRhkvicmYrwOXj1Cix7Dii1lZsS90XJijw+owGQde
mOpWmA2Ndy69kRpuHNTBXl+6vRqJEdS8Y75Et98QyJ7Nkce2XNDH2/qIBaQ5
BsSY48VhaBEXgCn4jARcIGQ2EgQCFCLnYsoI0VlF0Yt4UB54SHEc3poMLDlx
BQH2c8coLF/XaEi4qJJU8JjZLuimrhkO4luS6a6aXUiePs02AwVc/vYN0V8s
QhLWyYMF0y48MOmMGdMRgRjpaE8kngUBSskFhmWpjCZUBgtr40GYUnWVF/I6
tgkzvp6qAD0l6FBaB83KdeFkap4P+VQTpfyiGLgKfcncClrDfJwA784Kr3FD
0rTglZF5ljHJAsEUCRHf/k6cAim+c920+BTJEEiqGUA0KQYaAkEb8PXTxyC8
FcC0wcPFni/2/+0n+PinV8/+z9fPzs7PpK9mRrmqXM12skHC7posWu1EA6mm
hE5wYYSiaKtPSEtN0a3VNyUkEM3Trb7n9EA/LjOg2ZuLaFK/yPtU424QUCH9
VOkQXtdZxo5KVD+xaHPFpJQ54jgR3R3p1PNdWqBj9HDw9IzEhROANB5A4jKR
UVYNCwxSUkNSum6wu74iUYnMk/onmpiG4B8UoFLdTSYpCrd0DEOQ9ED+xGrY
CEB+kUDHTiWZ0rmrZlPctK3+vIR1kG5N7VEIHRJbLJ1JmPgfo9OY3oqiTA3i
RjwJEFzL8LJLc0vwFjVvWiAFNepwIp/1oMNBDD2bDdH6gjTqjjkBMU+MBN4X
CchRSAoVhasvZeQbCSSxocKKPB+fDleeDEtCAYIGX8RKKqZYedqUqly8twzp
RkFADtpUlkThdQjtUiqronAnobV0dimRZVK1jM6uJLIRF5nhqjhtNYHEF/ua
VbsQH0m/jimx0Z4yG11GFD1gwcCwdVNvXMbpqttC1qUhJjEzre5YKDSBNaoI
DXeVDMf1kq25gFfS0YIKz4QqJdLjAQq5tVRyYXzvmtoVW3ZEXMux4MspdeZj
uNAyng1n+HxA4y0QRUwPCBzn+W4bHELQveS5XL9jxEeFS5Cpa0zSJB39a61N
nrwwRE4pmIioa6usbB0ONVVDW7p0hQ2J7ZTSoC6WrBnGHsjmUfSMQ8wdYL0v
tEO7MS8zUYYxC9aqae6jhjjK3sX7onUdhbl0qnGhaKeFym1kmHHDBjkmnXUz
mUobI7hYHNj0qatcXB81kwfuVu/ZARTBhfzfxJybLIKutZKHp6sScIfGitIE
tutxmQRpndWXd03Zk7QgtNVfSAnYSSpODn7JxCnPVCcbyPoNuvrzvuHKjefC
CK/9LK6i850r2NwoPB2r+dssjYOUvWWWmETiQkpegax0Dv+cwD877PIhw5+V
plw2G4wut9YL7grpqHv0//rP/wXj479P1PHkClJUmiTPB7ik2PXG0cHJpoij
8Cu//2NSLSxhHwR2Wy0nj4SpqotiJFXNSkC6hF7oij68MnZPqIlmq4m+g497
4vNqabM976DkLFdMWYlcqqvEsDhexf4A0ok7bSkDBwsJNiB9QxyiBGiKx6jg
UDdIdcCAT1ikXOoxuuQitzzaqWOEKh+tMfo2j769anQnL+S3XG/uTsUHwjCN
wbByjcE0F17txnJLq4I0bCwnAioNFpYfx5GElqFNiyLyy5F/CuVaFPfprCTj
sHMIO2dyMrnIrmZIcvQ8nCTHtdGyq2ukdVkl6BUP05J8aFiQlq0X1aB1I3v2
LnL99FkuLhQXbC+h7HqNTiQOKbTZ8N20levpAscbJ092NgfuHTl2VGNjDaVC
5w8wy1zUdIweTZr+4Y2TTROuXPLzrCrOf+6xT4WsimpEKOxBcIiZMTroO/2c
gqjgJOkeB+LrBh+NzQ424TmlEf42+ebR5LdlMuXRt+MLQGFcsIqoC+ciqf7/
/b/dNnQawlyHuIRRsrjMaeHb7gkgcc+bZ2B9Y9BquVSiaL4SD1+1syH5HHPc
754GwuBUnJfAYWP6JCC+LsdT+LtC3j5VqjUKqJTYH67yPlAFeMlevZXBycLE
uEiMcMbzmjKLWajs0VAWG/HPJzu9juHDgAo6YmVluCaHajsE3DE/lwjU+CYr
ZpXZLK6m1RsG36YtEh8J3n7YwPcgpO4z/qpBAKBcCa3vfcSnH3rdbL7Jw4PM
Yy/mhOy/RTqEbarB2sdQ+X3hVs4lB4Nx1IV+StFT3lhwm9HlruDfFkrDYy68
3MB8g3u9jX13f0RBYqd5NelOUitpQPO43SHu8MZ6POmCSupCr+1eO2Qd2TWR
WFHP8RyQ1KmZCMgM3aDNPfidrJo7fSSbLu7YyA73r+luLV3sHhHZ7rJ9hxkr
gU4Qu/KDhwxiW63ATWgtlOl2uLT9MbNsNDbxjXxD7GE5fG2bljkDZUNklsgI
nfGMg4I5d5/MZJQzdKVGM+/zCCw1choLnr2IN14cH2zaw7B82+/0hTJGB++Z
scKIGYGfwrxWd1XtqJCkuLcefKYIRuDK5iOjYW92vquhkv5VAbu4nljFuhHl
ATtTi7CxfXaYS10Jiw4r6TITaYeFlIk/zqz0KRBnNA2OeIVT8JwvMNX3pJU2
Z/L0Mit3lY8cEMIYZE9c3OkTkc2UVcGBp1k9SaYMwAv6XZwNRHGGqZNJrMhv
LgM6qCnqXW8gBRBdZC4A6akMamvc6uER7nhXFICc6BXFAbMdhitANPiYBlQ1
DW/OgCYmmAjZkxDffZQdWEUkW37IwQ0HKlGy7FPUgSuJIfFOCh9BGHkz9nsj
5kQhNxunl42hMP4QgeNkxg4xJozxpGEdBNxepZoKPkidShq9bn8Qnb88fBlt
MB0kpxnLOxivm2ixACAhE1fI79LszT0AJSHiVBtA42hzttRusi2DWWK0+KW1
BvfsikwJctAr/5q7J7YS83UUjsWhBX4GQu2s6niJXLMwKQ7YtZdU5p5kk7B1
lERXqegiavK1PKIsxQCgO28bH9g4t1vU3Gj37JNx2KlgGYT8iLFQ3w3yhQro
fDQvzz4JpFNolPwMuI88Ce/JJTtc9gPhkqU/7qyBgbv+0QzvUdk4PXy9qVX5
KVdJ3Mhx61WJhZlOW9J+zkc20ALzmK131IRWzM8N3m/8MFncHYlmUTUwZfDZ
+xCDuhDPBS82fPKeTuAD7xIaRNI1ugQ4IErDNxcid1JZHsKYdFLUz2EYRaO6
qDXIWktfdA4Fn7/SxBg9ovBZhG8srNDE5H6+Xfx+AnQ6x3cl4b8nrYZbJr2f
q/DqL3RGlMLvTj3Ww3eFBUSexV+QmMF/9fDnHzRPePwCx+bZM9C+92kmR10H
ST1f5mkvPHaqJ4AIQcn2zHSsTU7MoL8+dsCkvwkEUfTY6USQ1rnBf1chiMUP
QY83qxBk3Xk6EeRNlv9SHDEoABiCwGUQI23x7IpjtvVdeethbfASdGkqL9lb
8LqtO6sYDipedUzSBW3KeFbt91KIpDoYOhCaT5v3OA6KhOhh0VmpzBDHzYu8
7kzBOXlwuHNqwJCuJQKc4ceSZZ/uCMGWn1pk542B/MbJk8/pqbBU8l943VGH
6BVksqLd6zJwAlyz26BuimBO8ooj5Zn3/InsYcfLD9sf8OP4i/hR/Hm8S5Xt
t/1IC6Bv/+c5dff57sy34R/+Nxne8MRJsLzXBOEZ+yPTM37mjysUsc1l6zWs
1rN8rNUKldaKNQwOGpHkF5zBuoew8BS+5Kb3OoE1j2CH6h24M/iFhzAOieI6
BxFaL1Xjs5BnWkgalupa207E8hRuMQtajvDfkK/s29jtfyk/aJC0BSxnezDY
joPaRg0YrzlHSMzG42332pQBgiMmCKw4XhII2rLgqp7QiMb3uUOLfcKq3ljr
fLd+cy+RFIcyUsfWC5ex3cHL7nfkK8/e/Sw9oEbbFRhgjn3N4VtnziGCwcFr
2GD7/D2YAuCslskUKN+ALPYt941fxKa5pQwBuopW5epyNcUzhEKTEuGHO1ps
Bc1Y3DCU0T5oxvDtdyPFMwVZKKc5sUxbdMjvfLm6Bfjq733FYC0vYB2/+KYd
+1CKy8LEbJGFrwru4T3vX/vefdNGs9XkcTGmLbqNOzuDwc4KZPtl83b/UJRD
GyPlpD4cMVtKA/6oR9C8pP4KcLgHMCf/jasVt6x8OLY02cgujfLDDNW+Ldt/
BHnWRpuVCHOPI4sWEOpO1NjIC0WPTSHh95mqScJ38BKRi8aeOJ2QfNGg5GyN
x3SlVI3LRPFVEI3udfc6+d0qHrf8JiGAyPuAbo0WrO7L4nY4xKoFHYm8anM5
hoFwqQP1Aj3FjG+BAH6HfjP56NtoPSE8UHTXkIXd/6JFKi0CTGqKHR3FSqUE
TveaoanZJgHQgFEtBBeHCeLTzVQ6yWVtsVnBuY2cf8rFz7li1KG/+yKlVBny
P7OnphG2di6pw2k+aqQgMfejyIgo/oOUekKv3mcVmo+rYlYOXa56vOG9+ps9
1wGYbZ3lidSM8sndYXNsrQdC75ngwykUQcB8GnMybNgAOtUQHnnoUTDVnChZ
3eaVr5XcyJHSQSSY4cU+GdzG3hl/uDnKQRS1orEpu8HkjwTAxtxGCquXzHB1
5zlHwCw3wYo2blqqfXB8iZou2IsDs8IPOiRuuL5j6E9rJd9zLcfCPXGFJpKb
bDRLrMNdco9XL26/7RzBc+HgES4vRaEJbSewcYj0ut3B3lvSEtrIm+EqOe/n
XYsT5wk9EnM/D3S8YfxJOBXiYlCYOjhW3DA/7BogofPkaB63fuB24ZNB44sZ
Bqloppo7I8PwEYx7igNSCFIPXRGhEQjnbFzNJaEYyuFugQmm+54R73MI+MY6
fp031gSHhiHxNoxGManXfVpJLn6uxqY7JXJMlDzxcVJNY1I7oi0Ikrx1L/fk
UkbKuJEx++rN8cnhT/AZBmvi9vMVU+kkHFdIOmFWuUTodNSti3CWv/jU2Rrd
HTuma78uxj64gqNOXaycRJMt7GzsOQNXhw4OMJtm5rir7gESj7RuXgxjoRgE
t+jMBZkUOryPcPAhXAGJRanF21ZdAHRPy/P6MaWScNui2zWLzTKoh9chJfN7
mZYZlwkJcGyzt3hcDdkaZRUQuZEsOsCIhDblCh/Tsfg3AxfloUn6kg/9UVJO
LmaKDesoJ0BJUVL7wOG8m34gaVWxJrdS0VyzujYw3UZ9xpRJ9LIwWUQvuEKR
GOb1WYdErY3qeg8TM6U0YhIMJ5gJkDYl67kAak1yhqT39xqoTEck50MiU8CT
OZoMgx8x2yZpbKpFpIWMNtZbtSdBXLtDCmIOZtXEtq1OTFpcj9jRpglWjM+y
STZOSiwCTDGoEm9g8qk5b4fnJDxwdzppXGaNNsIoFZZJEsuMsKBGKY8CkXRE
FTbSd9OsTCt3M1Muf6KPvSWVd5u0sITeC7SlEqr2RXLsyqyE0l1d08vxDCN+
B16v9gIcrdlVUpEMHb5szXIHPX2RYnGm7FpKNJZuArUBTswE3UgslI292WR5
/4wTaqjgib4HYNLaqyhCESP0QUsRjV6YL4cCRzElZiVZOr5KjE2Up8KAHTMx
AFXkJmy6xGhTqj1D0gzDT6kWFUewO6oGoTgkWRzB5LaICJ6SvqZIlCZPHdRN
KKQOY14583KFy2h1dRg7mrnnX2x6vKl9M6YAUlcp0KxXpaVZZUqcM83quSDf
mctk4fJjBCQb09ZIlAGS1nkAYcZamOfTKISEmQvJ2IouWlANg/44Os+jKG/U
WggdkhJDhAvP5VdInTf5tv8Hh3uRymrvqWV9DcPjEVWj48fL8MpStETSpJT8
qGK39nYrAe8+MxiWc0WvkAXVcuCEKTnXz7cwp4verm9dysRq4oKIm6K9hTM1
GLDrnFGptyuSXqlGJlI/yqYj4gR6ZopPFKEtGmgkac2VFs63WRarwCrRvjQn
O5vxWA41I9yrdaYThbFQ8aWuKkVAl7XiIpZPQYqW3BCIsRk+q4tvFekEATQy
fa3U1X+cgASDfBjjjjnbOte8zwDpUO5wQYaa91O78HZMG0ElPeHcn1VQUXVD
V7lI8nix/z+VZC1YGEKjKvi/PhGpLXgZjFV7AT3rYdzRwJGx0kjXJHKFa5A3
r2wCPYgsbKPlPFuUj7SOH0eDSp6UnzzNh8m0mo216ENi35mhqkVE7io/4ibi
cFa318BqOEIFQMSvOmm+aqBfkSkcQPDSvS5y6N/Fjmw4pKvvFAj0LnMsjCj3
Ty9rshUO1XQjm5QzzdxjwmxTXjVtrx1tFeLguazGPVQlsEY0ugWRo/LRv5zG
n0JvhpNkfyL9FVahwkkjjavxelb40Kfy2WbKEyyH08WobK95LwMl8/AZbxc6
zkKXpDZKfY3SRf56nsPueXGV4Vk2gh5JsKhN/pJjX5izNstFRhoYUyAD0NWn
9cx2Bvd5HMbDwepF4M+VbrD1DTZC9YndPm5pM7nfC9dU2K/s6ngcl6eZU9CC
Zqhy2jDH/JBdjFAoOG1NJQnX3RXIZ1LjkLHieJz8L/gZwgAOauDC+ACsCOiz
fOSClMj0QbLrJMFnWXxYhdd32g704N2k8GmLLXR1ZrWaq9f5iTjW7sl2e+z1
BwCsEYn0Xn2eurCx+/90vgqy1bF029Btb0vazAH5ES/coS+bxs44R8/EVvzX
jp8la3bzf0uDncnjHzIw4Y0LWd6gU9lcPFoY1bfV93HSa57cqp+ml3QeN6hU
R4P1ALFoeLxPTyh46j4dbwR0uq4tJJBN2NwXrTvmomN6dnLo//igYdZaTTNy
1VMP9R2dMdU9Y923QT8MZf/sfcNhdJtkkqVnUl887UItUdRkI51hvQBHlJkl
tLkKcQPLQRyhVBuecDGfPBQiVJgCNbCFBjR10rkZW71bpPbV8GYNUusrPL1R
lfGcti+WDFeEFb/h1WHKG2yGn0JxzCmrmxWMAl5JML6i2hXcnpbT62A8yptG
ZQFSmBgyjnOsrX2DTJKXp60CsaqzXrMbz+a52Se3bVEp98hmdxhygMJbaMZn
6WwBgm8pme2gk62r5fozbcUTb+660efVwQ9EMA3lDxdiqKLetDlLk59Sbgz/
KgtoXOk5IyyF9kYsdJXoQJXGZmlxK+6ZWvA5PXs3HXS0uOmYMApht9VqcRPx
R88IgeD3b2RbAWOLFvBxS7/acdoOZrbn0kCZxs8CkgW3UEnWK+dPXodokYh6
3ojX4lpTf55NplyDlb5x6Usk7pHWelvIl6hfg+KWayKsvGoz4IGMALftyRCL
+B3VBLjMbT4y+eXVbVaTJxX0AfYTUWMcNKfQG0/FPPnyYr5a1iNWIF2OVkgX
XX1bvsviAZMJXBozJ6oIOcG3kMM6XqjrcbFajhTiPL4W9WmS6MhlSQPhQuvF
0Um84VbGis6mrWROxYQQHOSB7Kx1QVPbVPaovY7CVH0g27oI6Vishz1//IaI
B/glwobtzVziP/KQCTigVoh1DyygFOoT9RlAxi3pzKakU0cBxdU2I2N8maSh
sd0QWK7g4ziNzO29mqp9IirJSGXI7tQVCJuSp5/YjK9aNfA7cWgDAY00/7S4
TStfO1xfZcQYk8YN45Ist7YgwkR0fWdo3tMqjggEZmY2WZPdSKJjUogLfUAz
uYQX/oy1ISzSUTf5c1j+SnDYvxB2LJgjlt7EmofEwGnMx5ULs/CXWSSKbTJM
F8Nk/NMFWUSmNnl3mw0LVgi5ZuTQoiYhTEXVp0I31v4c2ZLddNeb9gazuI3j
k+Pz+Ox8//zZpiKvAEAcMfpeir8uG2dI2blPcO1pHiU0y6qGcdiApFRH5uYp
Zmn1pH0xymm56zCURJ+yHcldl3c3sMY4WqjQPIQPq5BcxTQj4cd0qTy8s4KZ
B6D1SVCu4B6ks/IT7V5KlEo36Uitwf7lHHPd+CS98UIwT1ZOxUKY3rg7EInp
GigffEymXf0EcOaq4CKAb/bh2J4en7/YP5WToPfVlP6XCChoyWvaNlQdrTUT
W8xAqwxRqTGyGAc8yu9dd+YcW8HG9PhR5KcCfAYIXRUhnCysy24Vp5GXbjrW
ZtiaeyVGiiwEK22uK1Lqts667M6sqoL1AGWPjD3Dt7CHQ34LgOCDNj+24tkq
7XRp+PS7Swroqs3RBreL7iO9GJXmpphQmYyygh9sogaJekvPvRcSqcwIfsvR
DunLO/JeDWdrUZSO4vriwN/3DnyPFKzHUPQUJyCwERWfz2X5NzOhH+36AhRl
F7UvHWwPH5C7DitY6JszcKEvTEEJ2YqYRcVoh/GMV+41N1dt1Hmj1a/mQ0gM
jRQOth/Ucvfv4OXImVw1JjnL0gZkuOiWcG1FI2bJkwxRBYLjx8iwRF+dIyai
OYXuDjRG0meizGPYHUIYAXHk0VfWGPnCurfpeGxDYnyVWpUdREDrYoK6emhf
xoYo4PvixdTgDj2xAVJvnBmm4yUu4m9YSUdOA1aBhgF8UriRK9lYQciFPMtu
OpZU0NPzIv+VMVsg3RQzxAY/N+h4qTDzTT+dwzBnoJW+kSG7TjRrvMVhaon5
iIj2xRd02cD69nCxokRum7tsQQRE85jDOTelmEc9K/mVGWwSIZ3D9jITES+P
zISDfY+0Ha83NlGbLRUzDBqI9+saaEQllR2FlTYodxt+9kSugJs7mYxKlJ+f
P3txesZaQELPLFr66cKAyGrCNhLmplIyrcsOYQydrcQukp2c4gx893882QYV
37HXqtUj/G+XSXfRAlBF32JbBSxcpOgtmoazSFpK8psn22prmOPi+tDkgK6h
pR7a5IYQOqArfl9PJsk7kSWg6daWqZOxIMFl69vQoLDgYWyxTjNzjBe+wM1g
8JldW85YjotrAF0mnnsuw407ge0aNw/Br8PBpW8ghl1aX1AnOp9b+EcOR6pl
+k789Zb7cmeTrcitneP4bNixM/InC+EUx651NH+VDm9+wrU8eUJL+rTVBho9
H5I6Aht48qTEDvzHp6bR4velt6K5g/zChcRzC6b/8aQc3jhYRvPuWxD2j4PP
7RTR/Az5CENl4fxCbbZaNvCbaD70d+Kni8BNdKP/7gC2u5bRnJnUE+ROP92q
b2pLcZUNZW3zOxwO4cKim9FaanMR8xdMEjvsa1t+gDdJpg+4twZgeyaswD5X
RIgyd+0tRJoDeBi0Tg+/+ra1Bb67zljZsTPai0YxeqSS2+//waHbmLPY1ujN
rj/KP/DXWT7aIDl1ky6j3NLVQ3gL7vzM3UjXaL3+W92HjP351jJSPRGE+jRu
9V10I3ELC+50/KkOQS5/w1JJPghXLuIVfa3dFtzVaMEXf/3rHGuu0r88pOCP
zv83AecvtgO4qUHQuChzD/oQTbe+0UbzQEj4lp+Es13aDrcub0LXJP6vG3a1
koyxeLXqMPBktI0I4eDPXr16+SqOl+LXorlW/rRSx5zJbC0XoNcHAzdgwwDH
PrI1DHBOyXMmuPD5LTFMkdoj12Nbq1kyFTOqA7/cl2kydUDmtRoLNQ9q/JOt
BeVnJ8EyH1eLPEjXxXA4m0rZSTSeaugOvk6zn98ZtajQhDgjvDd0fxKfXfy+
c8y3ukWiGVo9Mxli8AjqCkcnYVHMziioBjDJBFVFHJRMh0ICtTcNJGRY2g/d
Fp3lkNu6ZfjYlHuwO7D7YSB5LqlKIqmL0l5cjLMrY8VP+P0ptUoHCpraPhua
WXDc6pUIq/Hiez70gvQfGlUaG5sceS/NIm3NbsUY0CPZD66+54xVQdFrSYqD
g80ul8LR11uM9tVMwLYvcxbBo2btEDQf8orRXnDody7RmzAgcg9bNp60JE9T
dcvmFzbweHNc0/9DR5bZwi6RPPjDKqQHdjNUn3fYyGnji41ly9Nb54Y6rn2I
QeQsBN5LH5pdWIHRycQk1AsV1UDhjzRONWmoy2iYDmvDU0xh84HZRFgru0lU
qgHKEm3w82CSWWoc5ZYsbvY4ox4fRY357TjKY64Cm9exQ5gI7RBhKR1TZ5QK
FgUgdafkcmE0OUYVf47mjrw9WNJiWkANS5B6O43ULG54OQVLAvoaJQ6d1UAk
bjLfd62LEaB4xKdMvdxrZp5POINdkIDG0PHWwbzhtFWjzJ0rnEsMgM0j8Vnj
CpAMZe1k0dQH+mPEJD447l+/bdqdmu896X79RVq6akPOuk4ioGTenecJmk4g
5nUgb3JIjWU2FoY3k+0tBlXJdkx2fC574geD0UPcrLyN/XIhMySou/MT442G
iYDEfPvEnfKWSEP039v4CTXzD7R2S7WBuN+WAs9U/Rf+QmYYanwj/8zlyi8K
bWmoNEsVQYxtYGkw6lbIsZmJjKRmC/VWb02xzZjJe8DhFz/GAC660J8i2cRq
DL5LN9C6NXrfi+wmwwBs+J07rCe2ZLpZH12ngKPjdwct9X3BzgV8qknQL7TT
odlbV6OOXbpG3KJjR6ii0nek+t8qCAnE3Al4o+/Dos2c/qf/6gQgA2FoTRU3
8PGN68UbAhgiCPPRQjSQWm1baFmcq2EwGFe6mmv0KfRjrV7MClvfbHVt3k1j
Zmd+b4B7ghDh3xubkl4BxNmC4hB8bgdXzmoxvC9bay8ktuv5VI6GgGc+eld3
Au5TH5xFPfhvKt/dOU8Lc+bd+BRgeQdZgW6LwdyYs3VNqHPz6iy9JLEgbic5
op4eVIxvQc9FQ1LPT4P4tuAHKRxTahlWLZbcs4uqGEMb37jG4NyzE6Z2oYjH
TUImPZuA4y0S/j8jS5k7mHoih7WAQvdDk1gHnBabv03U9Va31Uh7BtfVYefi
cX3PTrL9V0QEE33ZvdpFSLvActvYZxfGInjCe70SQvQ99+z8JmpibQAh1xW3
G251oZFaNsYEGP9pbhZ6duMe/ZjiPVtnjgQCGmnPLtyTzXT9qnMusQ8yArKh
a+ubxpfLi5UZt889AtsXmJbWD9XsMC5psJeGhEWtGDFvSKCqOxWnqqvgaJ4v
12eY14jxknCEjxjb9evFdaEaYgxwoH4gWCgEbr0YL2MZW1ZG3IUe/DZjuc69
VWuNiKtlEVTNQKQVMVJ/u4ioVpzvx4yBWieuSXHH4siSCCc1LdA6VNP/bUY5
cQY9ExRfWsdEOvFV0FtoiutQgqk+kGRAbK1SEotnvSxaQS3tunGBndEp/v/I
oUy/RzL9Hsn0eyTT3yySSUROJ8F1fT33/+3+2oU8rejNP6tDouyiXIjTeoFR
+hPEOa0Kj+qQ3n1fCZKin2WRUgtDpXTT7XipNaXsZtjUCnevgvrMea6Xyv7t
sZcqU1umlLYq/naTjZOViIhG1NWiw/yrNF+kVDWW1oy1kt7Nj12v7igs16s7
BqsbHC7oyszJGYKrVFGBcZjj+Wlnq3hhhJQJsOrKG9f+HQaHrW61td21YZLi
VVcLw6rCrs3IqnkQUTVoaq7LgqpuNJYqNAHHxmrdb4dT+UirRRb0jkik2H8y
jyUSa8ldo7WSzUf3Y2NEJBBrQX8sddye3/aXOCzu3xmLteXDRcQO1Ni/S8ds
XTee6ceAOP/YtUVZfBh8JZFktnMXjFfHr7j/rhF5tKx7J7Gw3Kh128L+LgzJ
dDkRGVzPIehi2nWDNm7yw1ZAom+2MACpuxqG79hBIIMWNMY3zRHmrWAkaq/B
ti1Q3yxbjExi45aWG4zMhBK8tIKZNedeuy4IwcPYmLy9Y+34JafpqZHpdT7O
3tqwlIb3XAqW+Y7XVMppkjrxcYiF7Y4oY/I29dX1jb4sxMS/LcQVD2wRGqoK
7OhBGBHVtO/8KhFWSf57YNWagVWsB6FcHkZLZWa77fxA8vwFp8JBC23FnZ8N
Jebqh/go8Vxcpr/WECv3EJOkcv7jh3dJGScPJ1eO1xSB6lLNSpylqNjwmGPB
vnFHM9Rt0eRU6U3wMQ8rwsoWBWP8ncLK4g+KKvs9oOtXC+iq7hPR1aQNzuLa
9Rj9WtFeb+j572ASX9THDpb4aL81I8M8xW9n8/p2niCXdATBUgKrBw/oKuLY
4yXjE9a4CV+Irn4P+/qHD/tSUfiD4r6WJYW5fzqVjV8c/LV2+FdLCiblT0O1
iGUuNETMOW5Mo2Zaqn68MFKhOSdW/5FAsIWRI3Y/NMSwEVS0KjAr/jFo0QxH
o9NoR2wxEIKe+OVPRpLpPEenSJmerS+pZ3Mf/0SgCCHREcMQLwzC8ztufGnS
KtfoaU7OWzjmy0N71NopEWn8ERV5erjech0c6U+2QK/Zk5RRptDOJrp8o1K6
Kvz+R43fWNLV1eMKIxbmgBpMH5dByVt7dDAZowNjWl0prC2IU5Pqi7TxpUuW
afQf/FDah8FqcRBDpWjUETXXIFzd5putEI07o1Xk62bM3NILYGBJPzYaaVX0
WbxgK+t17A4wXf3TjmxLhx3Abs+4MDwtBP2CjksihGK1ly7o2AVyi0ctSr4q
Ns3FtXEcVKPjgp/AT8BheJ5Mr4pMc6BBo6SN31sVmOY6btm7qZF7/LMEnbuQ
ZIVFf/Gtj1pokzaDyxZ1XIY2FFu2qONStAnNdEHHpdmjwkfEQmgjxFbZ+u5j
uFtksLtfVFjLZPcJP6t1IG9oUXU4+JoK8qNy8PrwVF9rwigoUk24iBy6pFk3
8L7fjm787hrXML1Gbz6GJEhkkX+5i8qRcXeUaWkZ2E/m5LfbJP7susDxnFjr
kmZgCZeFhEic/4Ay+GPR8V/iHw8oBuIBKGtiTnpwcLgfP0CRCPXPBw/MGs7L
BF+JAGksqSpdicj3h7Dbs7S80Qfl+F2/zIYCVS6aB+Ov4hG9PQULLe/01RK0
oORxBD2oWhUGwUg5QFi5aBf6nC1pIxiG0edefsO4M6+KtDaI+6N8NfxS9zn4
BRuBHeBrCVRnkbLbCmeZinht7Q3lJnAHC9f5euI4VCuuCKdwj/1dyke0X7Jt
cDE91BEz0mIFtOYJOG5F6EJVDHPBFfdwlAxXSEBKhaURR1KB3E1XWRRlA+ad
M0PTewoUBHX2lCrIcxTcDwoLLYab3+lkjIHy+YPsKgc8fUALxDMyX1F7xkcZ
01SWB7XZRTzqmC/Onm7822bHULA2fhhgDJdunIBK2MBj+uK5/2I9TBYL4N8F
l83X7tYOftF+BKE1MmZNlP4I2NxGZrUsDQ0lls3nvqOLVYx8sIzBX37pQwx2
7U7aZ5TqLIV5oVRQveO2tPH774rSp/LK1nN+jiJE61ZNT4ezyQjDv0Z4PpJj
yXgiNz0d02tTyi2j8E0ZG/UoT5axF4HZ58NDLqKKAGzQG30TjB/PiExCeQOi
nlV1QVUvAXIymaiPvKrP45qLEE7oz1ejnulBTAWKfcSpGLERducxUTV3hwVA
Gpf9bht+hB7jpZXFwrHFGzuP+9WmW3CEC8bv4OQe8J4/qz5DBAXGjWFgjZc3
nBg4Sd5lk9lEo/V4J7DDl/pgtqmf29gun6myvQDtBXxlSg99ElWw2Mn8n3TR
743o4uDa+uZvRzHt1B+RZNKw1/fc0YfRzPxD6UcUHFG8z29BwtR9FEDJeEyP
M4r/hg/x+2IaP8dIAS9FpqSind1VdTrB4bnKMD5klAAa3mTDNLwYQAfwfRl9
aaohYEZ+BkdiKcQ+QZfLWWGEUNwHe4WxxHsyG9eNIzQ5D3qGDYzVb+0RejN4
m85barW3FPAMd37LeTHdtu+0GgFLPeGiAJAFfjat6jJNJgLM25z/pBB8/a6H
BZuH5gWbKC9A7laQU9CpiZY/TG8cQJTa9sJdl+lYK4j7U3jJBbKZYFwn+my2
X1SQO0JOo2MMTgXyHpfAisnzm8tbyJwTL2FlXBp7fDcAgoRuiPGMNCL3VnFd
uGcVDrNS9KVj9gsCuDYOjzdJeOX3FGdZdc3XZaSNkV5HxJAMuMW/4SDsWjtJ
1wIlb27WNTd6jjzynQorBBVvn07x8fPizSlwup9/fnV08OjrR4/ev+81e5BX
bTqmh4TRzQDS0ONHGIEX00PmPOA/xVFhVFCQOS6zd7Re+zGB/RIfXz5W+gNQ
Oj4+3CSmUaWqRDI5i0LVEUufU8V3XwkcCRWdduXkeVxui7plJZw0tI82Dp/9
QLHTp6ebzrPv2rgnpnxeD1C9DXlYHS+Afz19MxQLIuVEyS2uwLuCSb/0R7jh
L4c/s0129I/RpIbdkum0LKYlPt4WEUSkijedjD7zjvfOL0dAji9TPuUn70aV
5453+fC6LPLsL+nIOxLNLK43vxVpXim8pFcYWYNaNrEKDzN6pU6yUYrSe3uR
zwEbIj8YtsXDlWdR+SH2PgcHyHC0iqtxceE+CrN7HBt1ctwKuHhp1Ct/XbKY
p8zRCsqsrjvHMeU5An33UGfGJymnU8/J5FC4Bj3iUOQNK261FFyByQAOgLBX
97TuSDkNPX4ZHx/yQH4nWHH+AXHQvky+kNno4roZjhXj/c1eDrj2LJFnMmug
MhAEb7xw9xU/JrC4ECN8R48EdSFWJhME2wpGmjcRsJYKAS7L+X1JpuYTDliR
dAYekqWlBTjXIc1Hq8V5/Rq2lGWjB7itB7Av/L35EnvU0m4CSYYeS+UyREII
RbLJPFn1oT6YkCL+YZi6oc04uUpfszDkyxFVk1SF5yHglscC0ckPhILZkX2A
EeAnYSb8mOHxs2fP4mevj/uPH5FenLeQKxnWmL5EgoDMEYpQ/PZBURrMWluU
4j3o5QQE4UumCaYGeZrLomsLIHG5qNjZXoHI36X737i4W8Yjk4J92vTYvzcL
ZHU2ZH3uMr0F/lWn1UJU1cURCWc13FoOYNiO24xKXvfqQcWDK3yEKi+mBDcu
W0ssXf8G8RTRGheopcsRMQHmwumNFUqx/s+Yc2PxrCX8Dm6QPMJEl8GZqcO3
7l9WTlyuXIwouSpvUp4Wjd+LuA76M6MlAgt1pteg/1vLLTTXZYFAQHolRzGd
jvkxWaImGIV9KsDgWEYJPrpwggwFIhL78Y04jdPadJy1JeRYpkvUQvR7aGJq
duFD09uZkVWDrmFgS7FL6Lh2K1YF92/hmsjI4rMXm1bWyr2/2outZccbGjxF
I6ODkYWicBUfQ4CwxyoRei0Scb6MKERrstUWVcAbNr6f6TDDt0uRtloDYmpH
argLonYWJL6K3MhEX0X0mtvrkjzVFghrWWwKxPb4Bu4Kk17dsugtMuV1m+IE
Fh9ufEOAHlAG9mziDgeJ+ASGoZjaRDK04XvBWfe8GFFgoPkgNCEzh+/GJPxh
HC9r7qk+/R5NUtTos2oSV/gANAgsz3fjg1cHSBQlgM+8aY9pBRzlyu8/ax9Z
gUhlYe45LGuIgsoGvs2oPtOff8Zw+vfvNzc9Arn9BAZnre2Az26jVet+3HL1
vYgCxNE1iPpiDpZ1NF2iniy+yw6QRI7JBRaW3lSdsb2goyUXNT5LgS+j50Sr
BHCJCkKUBd8R8xCDpnGkRGg1xAUXs6rjazHcDBM12jSeS6Pg54gjLDR/HM/C
kQeih16BdqZ/ijYmZEGpe8Yvk0cirHGUuapswM76ddGnoKcZSpy1fZgS6E96
Rft1iIvC92GaZzjNZYx+XBT0ZewpUytA3hm/9gJsCYNJ6VwrhR20AvYz0eft
pG9VjG90VUXp/FJtsA1WnkRwIyR6YHahl8Hn17hn5eOkrhOqv1DEXZeKbNvV
7OoqxdgDJ3dLVvkkTapZSYVp9+FcRlzBxD0mD8BAdVoeJRfg0nzWuZuwW84/
qUOPudf4ljjgOSJ63oggp/QBeelc56gAT1JXN4RIGGMODEF8kEJ6JzYjwhUn
cE+MRvLEKKY/uIhy0PXTyQVcPJkJ5QzM/kFSFWT4a8MITfRwgjgzW11RmeTP
NOePd8TAoJuPKQjTVGuP4rN6RM9gAolCz2p6ow87wp3CDH62l8KpKk5WgpM8
7IBs8Bsg8G3CeVUE1wmeGwsbchBY7hYE8MSUyXGPtUe8Y2zLwiidCR007O37
4hapfk+MSpW8G56HuwKg+noDwBgwWeMmG6F2ad42vARCN66zKclmfCTKMMl2
FWV592kggoDuNSv1iGkmA1xaGYtU7aPUObxRVdfUr8hEp8g1LjAOn04zMaWW
NDdCn3UUFpSOJAlnfAfrQ/mZhomQpZF0gPhTVj3K8NCsCFiK5mooCMKHFSl2
P1IXQM8+0JiOp6qy3LVy2RoJUBd3kTkjZj/6cmZ9N+UAePqWT9bTcbrgJFH8
xywrWevFwWlfQK3oKgyTaaLued58EyO0talfhfCL8DvJsaqmRXFJ14sLJQEa
p4OrAaMoMO1RMVFJa1M06shoVi4FZ7F8Wc2mJA9Xs0xUAhBqhExGPJkqlG3m
wFqd0EAinUChbxC4JGzdKVEFmSMKj5isMcYJMU6vAFIT3CHJr7pxU7YECSC7
wcT665idIXJd9X2EA4ZPHssTyqgQy46RkNJO+65iFeEvPi4rMrWjFj1NjCR0
QhUTy1qhpSAlzQq3hMV9hLBPikbJJfWKi+BVS5hPQtP1yD9LKikhEpqp4SIC
981sHRZb90RG7fmbMizvpnVxVSZTuAURLBVuwiync00wKIThGSfZxGldhB5k
K+cIJzUUmGfcIne5AI72yHyKzpGQIOWnEypYfoOs3Ycx4f1PiMGYhyqzQTqI
iMtnlLBHuqQ2zUgCKn2GVXj6qOLAZiebIK8iKSK2VqrbBhbxFmaflcKDNKXF
PVyq4mMCIKVkE2TLKD0RNjNtsG+h/td//q8gqBEpWIM+4L4BWYfBy5SSU6nv
4Y3sd4nnN8Qk4TS9YwSOCX2mStYRQ2eTqTXGNeb4r//835XD6Io8VXTIqToj
O5bLjDcdjV2l8UuEG25UcK4xSU+N/q7OTkJXvyhryV9CX5vkTy1LRDIPysNt
yK44jTUzgpbeO8zJP3q1/91Pr56dvzp+duZkR4l8A5HhUg2WzAD8k8yUwS+b
5yiPUTJJrpyNSRglBdBJPjGRRDLcwTIdo8+daTyhsoA4u0vKa63wIs3TS8rC
U+iN0nFGpQ5L+EWitJpxpEAaRmm/uLwMwmiALaaYKnNnCBypLL5IGOE+hcwm
Ocuzhyju0cV+mpBy2osPkhLLOsVPkT3nIFeegqCXwY2MD8bAVnGT++Usn5bJ
xfUs/lfUgUEWg0Xug3CQ38UvkvJtcVO9zeCTcfouIZZ8mo6LGxgqqdBtdn49
A2wGlvYvMwAnTAhnHf9fsxxOl0jxYZZewdpmfy5uxCELShDsDaVz0NdCqZ6T
qemp6JqM//1+H4jd8G1nHPGzdwkSgSr++RPVGpBKvI8agcRXlIVHdKYapjkw
7sLRF6uleZ1dI5Qfgu7KcuVVkYyFYAJNnCHjkEg2WpZ/mJhaT1A8xH0U4qqT
Z8nxK6dfqS3YPfQwKoYzSblk9pWo5o+OCUJEEOcQS2gvtqxiDKeYK82NDor9
U7EEIS1gMCHmlWlKjlWxSnvcYnMphQvi95TpLLqFeHgAfxJGOuY+EWwN5+Gt
Rc/x7evn5EhtuvElWpvJxc7u5/wC++4jNsRK7MX+dNrT+pIUZzGQkpgUfEhr
8lCheUkd4pIPopcx1RkhMZLYokNae7TB4OcVfPH4q8/ZlP0de3lpvfvi9vF+
0PH0OtnbOz4+fPj4EV/LGv7egb94aVxTyQALOGUyvAuPhSc2blZaglgle01B
LgCdOqTRAZdMJm7uiEtMnCERe/8+luxmdZKKqaoiEsdHCAMwHAZh+DyigMmO
ZgflqCApBXWkykfRVH5oRR0XD61lBqkYJPrTXQLoC48ycXwIrNumOWx1/Ua5
HnS6lNbhfhPQaqLEfK79Wr9FIPHQ7uBn4H6buw/n0WDFD41AgKIR2r8tT9Zw
NbmILnzftgWZtB0Rro39Ya18EFP2i8nD810v9GPo3FojuMQP8fCcfPcmCnJA
zphNSq2WDGgIe4hOFcnOHJI9P+3DOjDdw8RxAVkjOtXQSjIUeVyEO2CmCAou
Su74kC6YKgFUKoOktGCP3tfAumieoiqKMZBUYAEpq3iIOQaPvPuOqCG5iphc
6XXTr9RBhc9XMDxeYYzFdtSRpWf+30TmMPVG87AirCxFwVb2kbV4fvR8fnQ6
Pzyexz+QTEMPtL0gqx/8gkwPIIVYNKfyQTVW7WmlL83N/91HL1H4HWBW6NBh
2Hz+R/QZ/fv8nnsKG5o9BXk1OMGjeL4Tz59m88d+JVwiFH5R3xatRDFeBnE5
I/DZVzrI9j0HMZH6893tDxxEgr/ps53HMogBrEQ2zulyi2ekNYiJq/Xb2fny
fivxoaAGJrtffNFayVLAPvtBGEo8f/xIBjl69tX23h6wlXVPhyJI+DM3SBdM
bMPmIPunp798JRy/0lgJsMg1Abv1pPGzZf7vP2r8Qn/IX4j2yFIQrpRuHeAJ
ijlrHjEOgiDpGuTRfQYxCPthGBs4i9YbZHj99uMDNoqJ4u58ZIrrN9GktrEl
tgGd/DsS24Xb+Z3Y/mMS2z+SSgEkrsf+vH48txEMOMgfd/59BbJdpkIn/12D
O4PGf0OK/UdUiHA388Xb2V21HQeS+crtrIIJgGRuvlsCk0W8Y3t7ex08+bV5
ByqososP5x33HOS/De9g1rH7O+v4nXesi7q/Ju94Pb0372gPcnjbuR0fzkKD
/PGrf1/BgJTYrn3EvxrvIIPWPVbyG6fYX325uy0wwdzind3NOYYrbzzaVJj8
Efj1Cop9z0H+21Ds0OjUl0QsMTsdcPIOx++ifWlfC2ZyMx8eLRETbOPmcN9R
Os0oAIoD49zg799zAD5bPjXWoqsiibhPGb/7h8eHPiPwspjlbtbnu5HkbUTW
bM1xaFk5kgVh+JekFjn7OJvebxNnDsNqsSXH70beBMxBohwZMSymzpmlPgN0
lpzT/nU6b6OtwljYuogfUcww9ok+cQV42QKpTpWGD2VaFjeYa6veBHKgtH3T
nT6vuJiyNdy5+cRmfJFUWeUc05r6lUgOIR+ZrKf/OucRxykcn3fBVOpFM6n0
FINhowXIHMn+tZ2duFXQ8aRgLy+tsqcPgkkxmB0ElTNpG6udFJe0djz3fy2U
Y8rzzIUb4yMN28qav53/3uIjtdjxLTC+ligbvlv7bXBojSpHbeRSwnO+HKNM
7O5KjEKyFeLymyzvnxTP4Tb0T6DdR0VoG7/Qb0QvoIn75MnnPRdzKYWYPxZ2
v3myQ9fnyeNFZ+VafLGyxaOVLT5f2WJ3ZYudlS22wxYbOZ3tZkeH7ZWb3165
+e2Vm5cWXy5A9nCR3ejewL9fjvNrIB0xQwyaeHN8cvgTwamFh+2b8iod93lw
Wmkf1/z3uS4iWSy+MfHCK/M3uy//9hHuy4ox7n1fqAWXrAPo9uI3jlKDqInh
RHs7O9vwv52dX0IK9KLH7tEPvQL0x69+WRdBbfFlXQgeZXUGPPjTBZ4GsVhK
CggM3eSg65L9/WhCcM+WUgRcK5OxX5kkPGBZ8MG9iBllVu81BuxRzNlolHGE
Jr3tp3EtuBqOMpYIQa6nTWL67/x5YYv16Q3chNbTcB9MDuJlVOUXsu8lRKG9
h41n+WjN2+0vzK9xvde7JXmx9t3+Td3slfz/N3Ej/8EkgIuPLwH8xsjAryEY
XHwUwWDJBL+YyPxqJGa/cV17a97XtWhN/3lS1f39X0RyHv9KFKcnNa3GdxRs
jy/l3HHYW6pFJent9nFR2bd5XDSelkRzBSH8W1xmiOY+G7mFLlLZJwmLOTCA
mCvbRqF7vP74GhNBXKEI82SSF2/cj5DSxk8HEQ1R/uCo8+a2G3WQ0najjsvb
bvT5Oo06aGq70XJK8CHEoHNLzTn24sskG7fmau3yg/rtdvWrZkOM1Fxrc12k
WmjR2nRIbvVviRx92GW+Bw17+humYbX3j+BYmJBL2UG/k6quRr+TKkM6qELC
/SnV6m6dhIoeiWh0i+N/W0mmNPV9wfsS68H2fuQR5TLT/IMo5NPfHoVcQCru
QQgPfsOEUEm/zw22j5P+IxPF36nifxeqSNtWDVcI269O1hxECCbLIbI25f61
BcyD3x75XIPAUMpWSEtfJO9wITD0L6Kdu1/dl3h+0d7brnO+3RaBXZ1narTV
JHFJML7Vspqu2L+GnwjTxJonPZcF6xJ0pfW4uMWnm5M7TFj3JTW04hl2dkyK
o4IAHq96CNrPtTImLZWqnLoKqxhdIpSZM0j1SLQ+n6u2QuUP8pQBQNa7Ha6e
wPauH0/wRVGGHL02g2VKYCFUZ7JHz9XiXPRcraTN72yuTayX0+oduXwd9sSO
Vh2muY5WO0uJrLbqsC22W+18vVarr9ZqtYB0NVotZ1vaajnf0lYdxs6OVmvB
fmct2O902HQ7Wm2vc0Jfx+uM9dVarb5cq9XjtVp9sVarR2u1+nytVrtrtdpZ
q9X2glbM1ZbZ1d2P+XXlRVwPGe6xoE4+22bmy3F6ey16sr3WNlQy0lYLTeTt
Ta0hPDCNbQkPnrXeX1hYg5/ufxA/JREAS4uMsQ6+1pqhNAosVd0usxftEz+x
jTCcNuH+7MHWelM+QjSh0g4U7RmmvAf1irDo5TQtw3oYHCKbBOvDWTMtl2IK
aXBhL+0p0bW43Bf7/xML64xno3QvFn35DzEx2ONDrvpPpQNrHR0rfWgZJFu/
h58Xo+qcddUR5irV6yrV0FjKyEzJN1fknKrSMqSwvkvMviS/KrsElAbwlCeY
5X6VrtOaHvWV9grYM4nn/Xrw1YCOHUWUCMu2gIT3XTFJ/+ILXsHJyINNVEBY
amqcTbF8yTU0BvEgp1fUN17gI+U1yFCYeh8/G82GyZBiaQ9gz7Myie/iQ6oX
lG6inFrMrrjg0b8UFU5e1Vhn6s9FfAXXoY4P9s92vni4vf35549ZkJWZn706
PPIPtbSWgeXCeOhpWfwZCz+dPzvY3QbW/OXXX3/1Vf90EMenUgn5mp/Tqcvs
gp9WqaVwEr67FTkI6P1Dc47UPqRI5TohTE3imwwLYGMVq+F1McYibyTlRQdc
+7TE5JaCKse799le5/SqurzYdpBMLspshAf6/wNLTWZVeH4BAA==

-->
</rfc>