rfc9442xml2.original.xml   rfc9442.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc [
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 --> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc symrefs="yes"?> <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lpwan-schc-over-sigfox-23" category=" std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-lpwan-schc-over-sigfox-23" number="9442" submissionType="IETF" category="s td" consensus="true" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRe fs="true" tocInclude="true" version="3">
<!-- xml2rfc v2v3 conversion 3.16.0 -->
<front> <front>
<title abbrev="SCHC over Sigfox LPWAN"> <title abbrev="SCHC over Sigfox LPWAN">
SCHC over Sigfox LPWAN Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Ne
</title> twork (LPWAN)
</title>
<author fullname="Juan Carlos Zuniga" initials="JC." surname="Zuniga"> <seriesInfo name="RFC" value="9442"/>
<author fullname="Juan Carlos Zúñiga" initials="JC." surname="Zúñiga">
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Montreal</city> <city>Montreal</city>
<code> QC</code> <region>QC</region>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>j.c.zuniga@ieee.org</email> <email>j.c.zuniga@ieee.org</email>
</address> </address>
</author> </author>
<author initials="C." surname="Gomez" fullname="Carles Gomez">
<author initials="C." surname="Gomez" fullname="Carles Gomez"> <organization>Universitat Politècnica de Catalunya</organization>
<organization>Universitat Politecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</str <street>C/Esteve Terradas, 7</street>
eet> <city>Castelldefels</city>
<code>08860</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>carles.gomez@upc.edu</email> <email>carles.gomez@upc.edu</email>
</address> </address>
</author> </author>
<author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
<author initials="S." surname="Aguilar" fullname="Sergio Aguilar"> <organization>Universitat Politècnica de Catalunya</organization>
<organization>Universitat Politecnica de Catalunya</organization>
<address> <address>
<postal> <postal>
<street>C/Esteve Terradas, 7</street> <street>08860 Castelldefels</str <street>C/Esteve Terradas, 7</street>
eet> <city>Castelldefels</city>
<code>08860</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>sergio.aguilar.romero@upc.edu</email> <email>sergio.aguilar.romero@upc.edu</email>
</address> </address>
</author> </author>
<author initials="L." surname="Toutain" fullname="Laurent Toutain">
<author initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization>IMT-Atlantique</organization> <organization>IMT-Atlantique</organization>
<address> <address>
<postal> <postal>
<street>2 rue de la Chataigneraie</street> <street>CS 17607</street> <street>2 rue de la Chataigneraie</street>
<city>35576 Cesson-Sevigne Cedex</city> <extaddr>CS 17607</extaddr>
<city>Cesson-Sevigne Cedex</city>
<code>35576</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>Laurent.Toutain@imt-atlantique.fr</email> <email>Laurent.Toutain@imt-atlantique.fr</email>
</address> </address>
</author> </author>
<author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
<author initials="S." surname="Cespedes" fullname="Sandra Cespedes"> <organization>Concordia University</organization>
<organization>Concordia University</organization>
<address> <address>
<postal> <postal>
<street>1455 De Maisonneuve Blvd. W.</street> <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> <country>Canada</country>
</postal> </postal>
<email>sandra.cespedes@concordia.ca</email> <email>sandra.cespedes@concordia.ca</email>
</address> </address>
</author> </author>
<author initials="D." surname="Wistuba" fullname="Diego Wistuba">
<author initials="D." surname="Wistuba" fullname="Diego Wistuba"> <organization>NIC Labs, Universidad de Chile</organization>
<organization>NIC Labs, Universidad de Chile</organization>
<address> <address>
<postal> <postal>
<street>Av. Almte. Blanco Encalada 1975</street> <street>Santiago</str <street>Av. Almte. Blanco Encalada 1975</street>
eet> <city>Santiago</city>
<country>Chile</country> <country>Chile</country>
</postal> </postal>
<email>wistuba@niclabs.cl</email> <email>research@witu.cl</email>
</address> </address>
</author> </author>
<author fullname="Julien Boite" initials="J." surname="Boite"> <author fullname="Julien Boite" initials="J." surname="Boite">
<organization> <organization>Unabiz (Sigfox)</organization>
Unabiz (Sigfox)
</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Labege</city> <city>Labege</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>julien.boite@unabiz.com</email> <email>juboite@free.fr</email>
<uri>https://www.sigfox.com/</uri> <uri>https://www.sigfox.com/</uri>
</address> </address>
</author> </author>
<date year="2023" month="July"/>
<date year="2023" month="February" day="3"/> <area>int</area>
<workgroup>lpwan</workgroup>
<workgroup>lpwan Working Group</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> <abstract>
<t>The Static Context Header Compression (SCHC) and fragmentation specif
<!--<t>The Generic Framework for Static Context Header Compression and Fragmenta ication (RFC 8724) describes a generic framework for application header compress
tion (SCHC) specification describes two mechanisms: i) an application header --> ion and fragmentation modes designed for Low-Power Wide Area Network (LPWAN) tec
<!--compression scheme, and ii) a frame fragmentation and loss recovery function hnologies.
ality. SCHC offers a great level of flexibility that can be tailored for differe This document defines a profile of SCHC over Sigfox LPWAN and provides o
nt --> ptimal parameter values and modes of operation.
<!--Low Power Wide Area Network (LPWAN) technologies.</t>--> </t>
<t>The Static Context Header Compression and fragmentation (SCHC) specif
ication (RFC8724) describes a generic framework for application header compressi
on and fragmentation modes designed for Low Power Wide Area Network (LPWAN) tech
nologies.
The present document defines a profile of SCHC over Sigfox LPWAN, and pr
ovides optimal parameter values and modes of operation.
<!-- This set of parameters are also known as a "SCHC over Sigfox pro
file. -->
</t>
<!--
<t>when processing the header fields. SCHC compression is based on a common stat
ic 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 resynchronizat
ion 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 pac
ket 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 sit
uations: 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 appl
ies 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 technolog
ies.
Fragmentation is mandatory for IPv6 datagrams that, after SCHC compression or wh
en it has not been possible to apply such compression, still exceed the L2 maxim
um
payload size. Similar solutions for other protocols such as CoAP will be describ
ed in separate documents.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t>The Generic Framework for Static Context Header Compression (SCHC) and
<t>The Generic Framework for Static Context Header Compression and Fragmentation Fragmentation specification <xref target="RFC8724" format="default"/> can be use
(SCHC) specification <xref target="RFC8724"/> can be used in conjunction with a d in conjunction with any of the four LPWAN technologies
ny of the four LPWAN technologies described in <xref target="RFC8376" format="default"/>. These LPWANs have simila
described in <xref target="RFC8376"/>. These LPWANs have similar characteristics r characteristics, such as star-oriented
such as star-oriented
topologies, network architecture, connected devices with built-in applications, etc. topologies, network architecture, connected devices with built-in applications, etc.
</t> </t>
<t>SCHC offers a considerable degree of flexibility to accommodate all these LPW AN technologies. Even though there are a great number of similarities between <t>SCHC offers a considerable degree of flexibility to accommodate all the se LPWAN technologies. Even though there are a great number of similarities betw een
them, some differences exist with respect to the transmission characteristics, p ayload sizes, etc. Hence, there are optimal parameters and modes of operation them, some differences exist with respect to the transmission characteristics, p ayload 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 technolo gy. that can be used when SCHC is used in conjunction with a specific LPWAN technolo gy.
</t> </t>
<t> <t>
Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost. Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost.
Sigfox complete documentation can be found in <xref target="sigfox-docs"/>. Complete Sigfox documentation can be found in <xref target="sigfox-docs" for
Sigfox aims to provide a very wide area network composed of Base Stations th mat="default"/>.
at receive short uplink messages (up to 12 bytes in size) sent by devices over t Sigfox aims to provide a very wide area network composed of Base Stations th
he long-range Sigfox radio protocol, as described in <xref target="RFC8376"/>. at receive short Uplink messages (up to 12 bytes in size) sent by devices over t
he long-range Sigfox radio protocol, as described in <xref target="RFC8376" form
at="default"/>.
Base Stations then forward messages to the Sigfox Cloud infrastructure for f urther processing (e.g., to offer geolocation services) and final delivery to th e customer. Base Stations then forward messages to the Sigfox Cloud infrastructure for f urther processing (e.g., to offer geolocation services) and final delivery to th e customer.
Base Stations also relay downlink messages (with a fixed 8 bytes size) s ent by the Sigfox Cloud to the devices, downlink messages being generated when d evices explicitly request for it with a flag in an uplink message. Base Stations also relay Downlink messages (with a fixed 8-byte size) se nt by the Sigfox Cloud to the devices, i.e., Downlink messages are being genera ted when devices explicitly request these messages with a flag in an Uplink mess age.
With SCHC functionalities, the Sigfox network offers more reliable communica tions (including recovery of lost messages) and is able to convey extended-size payloads (allowing for fragmentation/reassembly of With SCHC functionalities, the Sigfox network offers more reliable communica tions (including recovery of lost messages) and is able to convey extended-size payloads (allowing for fragmentation/reassembly of
messages) <xref target="sigfox-spec"/>. messages) <xref target="sigfox-spec" format="default"/>.
</t> </t>
<t>This document describes the parameters, settings, and modes of operation to b e used when SCHC is implemented over a Sigfox LPWAN. The set of parameters forms a "SCHC over Sigfox profile". <t>This document describes the parameters, settings, and modes of operatio n to be used when SCHC is implemented over a Sigfox LPWAN. The set of parameters forms a "SCHC over Sigfox Profile".
The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March
2022 <xref target="sigfox-spec"/> (support for future versions would have to be assessed). 2022 <xref target="sigfox-spec" format="default"/> (support for future versions would have to be assessed).
</t> </t>
</section>
</section> <section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="terminology" title="Terminology"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
they appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
capitals, as shown here.</t> be interpreted as
<t>It is assumed that the reader is familiar with the terms and mechanisms defin described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
ed in <xref target="RFC8376"/> and when, and only when, they appear in all capitals, as shown here.
in <xref target="RFC8724"/>. Also, it is assumed that the reader is familiar wit </t>
h Sigfox terminology <xref target="sigfox-spec"/>. <t>It is assumed that the reader is familiar with the terms and mechanisms
defined in <xref target="RFC8376" format="default"/> and <xref target="RFC8724"
format="default"/>. Also, it is assumed that the reader is familiar with Sigfox
terminology <xref target="sigfox-spec" format="default"/>.
</t> </t>
</section>
</section> <section anchor="schc-over-sigfox" numbered="true" toc="default">
<name>SCHC over Sigfox</name>
<section anchor="schc-over-sigfox" title="SCHC over Sigfox"> <t>The Generic SCHC Framework described in <xref target="RFC8724" format="
default"/> takes advantage of previous knowledge of traffic flows existing in LP
<t>The Generic SCHC Framework described in <xref target="RFC8724"/> takes advant WAN applications to avoid context synchronization.</t>
age of previous knowledge of traffic flows existing in LPWAN applications to avo <t>Contexts need to be stored and pre-configured on both ends.
id 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 mea ns, or by This can be done either by using a provisioning protocol, by out-of-band mea ns, or by
pre-provisioning them (e.g., at manufacturing time). pre-provisioning them (e.g., at manufacturing time).
For example, the context exchange can be done by using NETCONF<xref target=" For example, the context exchange can be done by using the Network Configura
RFC6241"/> with SSH, RESTCONF<xref target="RFC8040"/> with HTTPs, and CORECONF<x tion Protocol (NETCONF) <xref target="RFC6241" format="default"/> with Secure Sh
ref target="I-D.ietf-core-comi"/> with CoAP<xref target="RFC7252"/> as provision ell (SSH), RESTCONF <xref target="RFC8040" format="default"/> with secure HTTP m
ing protocols. The contexts can be encoded in XML under NETCONF, in JSON<xref ta ethods, and CoAP Management Interface (CORECONF) <xref target="I-D.ietf-core-com
rget="RFC8259"/> under RESTCONF and in CBOR<xref target="RFC8949"/> under CORECO i" format="default"/> with the Constrained Application Protocol (CoAP) <xref tar
NF. get="RFC7252" format="default"/> as provisioning protocols. The contexts can be
encoded in XML under NETCONF, in JSON <xref target="RFC8259" format="default"/>
under RESTCONF, and in 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> The way contexts are configured and stored on both ends is out of the scope of this document.</t>
<section anchor="network-arch" numbered="true" toc="default">
<name>Network Architecture</name>
<section anchor="network-arch" title="Network Architecture"> <t><xref target="Fig-archi" format="default"/> represents the architectu
re for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based
<t><xref target="Fig-archi"/> represents the architecture for Compression/Decomp on the terminology defined in <xref target="RFC8376" format="default"/>, where t
ression (C/D) and Fragmentation/Reassembly (F/R) based he Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is
on the terminology defined in <xref target="RFC8376"/>, where the Radio Gateway the
(RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the
Sigfox cloud-based Network. </t> Sigfox cloud-based Network. </t>
<figure title="Network Architecture" anchor="Fig-archi"><artwork><![CDATA[ <figure anchor="Fig-archi">
<name>Network Architecture</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
Sigfox Device Application Sigfox Device Application
+----------------+ +--------------+ +----------------+ +--------------+
| APP1 APP2 APP3 | |APP1 APP2 APP3| | APP1 APP2 APP3 | |APP1 APP2 APP3|
+----------------+ +--------------+ +----------------+ +--------------+
| UDP | | | | UDP | | UDP | | | | UDP |
| IPv6 | | | | IPv6 | | IPv6 | | | | IPv6 |
+--------+ | | +--------+ +--------+ | | +--------+
| SCHC C/D & F/R | | | | SCHC C/D & F/R | | |
| | | | | | | |
+-------+--------+ +--------+-----+ +-------+--------+ +--------+-----+
skipping to change at line 222 skipping to change at line 199
+~~ |Sigfox BS| | Gateway | | SCHC | . +~~ |Sigfox BS| | Gateway | | SCHC | .
| (RGW) | === | (NGW) | ... |C/D & F/R|..... | (RGW) | === | (NGW) | ... |C/D & F/R|.....
| | | Sigfox Cloud | | | IP-based | | | Sigfox Cloud | | | IP-based
+---------+ +--------------+ +---------+ Network +---------+ +--------------+ +---------+ Network
------- Uplink message ------> ------- Uplink message ------>
<------- Downlink message ------ <------- Downlink message ------
Legend: Legend:
$, ~ : Radio link $, ~ : Radio link
= : Internal Sigfox Network = : Internal Sigfox Network
. : External IP-based Network . : External IP-based Network
]]></artwork>
]]></artwork></figure> </figure>
<t>In the case of the global Sigfox network, RGWs (or Base Stations) are
<t>In the case of the global Sigfox Network, RGWs (or Base Stations) are distrib distributed over multiple countries wherever the Sigfox LPWAN service is provid
uted over multiple countries wherever the Sigfox LPWAN service is provided. ed.
The NGW (or cloud-based Sigfox Core Network) is a single entity that connects to 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 a global single s all RGWs (Sigfox Base Stations) in the world, hence providing a global single s
tar network topology.</t> tar Network topology.</t>
<t>The Sigfox Device sends application packets that are compressed and/o
<t>The Sigfox Device sends application packets that are compressed and/or fragme r fragmented by a SCHC C/D + F/R to reduce header size and/or fragment the packe
nted by a SCHC C/D + F/R to reduce headers size and/or fragment the packet. t.
The resulting SCHC Message is sent over a layer two (L2) Sigfox frame to the Sig The resulting SCHC message is sent over a layer two (L2) Sigfox frame to the Sig
fox Base Stations, which then forwards the SCHC Message to the Network Gateway ( fox Base Stations, which then forward the SCHC message to the NGW.
NGW). The NGW then delivers the SCHC message and associated gathered metadata to the N
The NGW then delivers the SCHC Message and associated gathered metadata to the N etwork SCHC C/D + F/R.</t>
etwork SCHC C/D + F/R.</t> <t>The Sigfox cloud-based Network communicates with the Network SCHC C/D
+ F/R for compression/decompression and/or for fragmentation/reassembly. The Ne
<t>The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R for com twork SCHC C/D + F/R shares the same set of Rules
pression/decompression and/or for fragmentation/reassembly. The Network SCHC C/D as the device SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with
+ F/R shares the same set of rules the NGW or it could be located in a different place, as long as a tunnel or secu
as the Device SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with red communication is established between
the NGW or it could be located in a different place, as long as a tunnel or secu the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly,
red communication is established between the packet can be forwarded over the Internet to one (or several) LPWAN Applica
the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly, tion Server(s) (App(s)).</t>
the packet can be forwarded over the Internet to one (or several) LPWAN Applica <t>The SCHC C/D + F/R processes are bidirectional, so the same principle
tion Server(s) (App).</t> s are applicable on both Uplink (UL) and Downlink (DL).</t>
</section>
<t>The SCHC C/D + F/R processes are bidirectional, so the same principles are ap <section anchor="uplink" numbered="true" toc="default">
plicable on both Uplink (UL) and Downlink (DL).</t> <name>Uplink</name>
<t>Uplink Sigfox transmissions occur in repetitions over different times
</section> and frequencies.
Besides time and frequency diversities, the Sigfox network also provides spatial
<section anchor="uplink" title="Uplink"> diversity, as potentially an Uplink message will be received by several Base St
ations. The Uplink message application payload size can be up to 12 bytes.</t>
<t>Uplink Sigfox transmissions occur in repetitions over different times and fre <t>Since all messages are self-contained and Base Stations forward all t
quencies. hese messages back to the same Sigfox network, multiple input copies can be
Besides time and frequency diversities, the Sigfox network also provides spatial combined at the NGW, providing for extra reliability based on the triple diversi
diversity, as potentially an Uplink message will be received by several base st ty (i.e., time, space, and frequency).
ations. The uplink message application payload size can be up to 12 bytes.</t>
<t>Since all messages are self-contained and base stations forward all these mes
sages back to the same Sigfox Network, multiple input copies can be
combined at the NGW providing for extra reliability based on the triple diversit
y (i.e., time, space and frequency).
</t> </t>
<t> <t>
A detailed description of the Sigfox Radio Protocol can be found in <xref target A detailed description of the Sigfox radio protocol can be found in <xref target
="sigfox-spec"/>. ="sigfox-spec" format="default"/>.
</t> </t>
<t>Messages sent from the device to the Network are delivered by the Sig
<t>Messages sent from the Device to the Network are delivered by the Sigfox netw fox cloud-based Network to the Network SCHC C/D + F/R through a callback/API wi
ork (NGW) to the Network SCHC C/D + F/R through a th the following information:</t>
callback/API with the following information:</t> <ul spacing="normal">
<li>Device ID</li>
<t><list style="symbols"> <li>Message Sequence Number</li>
<t>Device ID</t> <li>Message Payload</li>
<t>Message Sequence Number</t> <li>Message Timestamp</li>
<t>Message Payload</t> <li>Device Geolocation (optional)</li>
<t>Message Timestamp</t> <li>Received Signal Strength Indicator (RSSI) (optional)</li>
<t>Device Geolocation (optional)</t> <li>Device Temperature (optional)</li>
<t>Received Signal Strength Indicator (RSSI) (optional)</t> <li>Device Battery Voltage (optional)</li>
<t>Device Temperature (optional)</t> </ul>
<t>Device Battery Voltage (optional)</t> <t>The Device ID is a globally unique identifier assigned to the device,
</list></t> which is included in the Sigfox header of every message. The Message Sequence N
umber is a monotonically
<t>The Device ID is a globally unique identifier assigned to the Device, which i
s 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 increasing number identifying the specific transmission of this Uplink message, and it is also part of the Sigfox header. The Message Payload corresponds to the payload that the
Device has sent in the Uplink transmission. device has sent in the Uplink transmission.
Battery Voltage, temperature and RSSI values are sent in the confirmation contro Battery Voltage, Device Temperature, and RSSI values are sent in the conf
l message, which is mandatorially sent by the device after the successful recept irmation control message, which is mandatorily sent by the device after the succ
ion of a downlink message (see <xref target="sigfox-callbacks"/> Section 5.2).</ essful reception of a Downlink message (see <xref target="sigfox-callbacks" form
t> at="default"/>, Section 5.2).</t>
<t>The Message Timestamp, Device Geolocation, RSSI, Device Temperature,
<t>The Message Timestamp, Device Geolocation, RSSI, Device Temperature and Devic and Device Battery Voltage are metadata parameters provided by the Network.</t>
e 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" format="default"/>.</t>
<t>A detailed description of the Sigfox callbacks/APIs can be found in <xref tar <t>Only messages that have passed the L2 Cyclic Redundancy Check (CRC) a
get="sigfox-callbacks"/>.</t> t Network reception are delivered by the Sigfox network to the Network SCHC C/D
+ F/R.</t>
<t>Only messages that have passed the L2 Cyclic Redundancy Check (CRC) at networ <t>The L2 Word size used by Sigfox is 1 byte (8 bits). </t>
k reception are delivered by the Sigfox Network to the Network SCHC C/D + F/R.</ <t><xref target="SCHC-Message" format="default"/> shows a SCHC message s
t> ent over Sigfox, where the SCHC message could be a full SCHC Packet (e.g., compr
essed)
<t>The L2 Word Size used by Sigfox is 1 byte (8 bits). </t>
<t><xref target="SCHC-Message"/> shows a SCHC Message sent over Sigfox, where th
e SCHC Message could be a full SCHC Packet (e.g., compressed)
or a SCHC Fragment (e.g., a piece of a bigger SCHC Packet).</t> or a SCHC Fragment (e.g., a piece of a bigger SCHC Packet).</t>
<figure anchor="SCHC-Message">
<figure title="SCHC Message in Sigfox" anchor="SCHC-Message"><artwork><![CDATA[ <name>SCHC Message in Sigfox</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
| Sigfox Header | Sigfox payload | | Sigfox Header | Sigfox Payload |
+---------------+---------------- + +---------------+---------------- +
| SCHC message | | SCHC Message |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="downlink" numbered="true" toc="default">
<name>Downlink</name>
<section anchor="downlink" title="Downlink"> <t>
Downlink transmissions are device-driven and can only take place
<t> following an Uplink communication that indicates Downlink communication can b
Downlink transmissions are Device-driven and can only take place following an Up e performed. Hence, a Sigfox Device explicitly indicates its intention to receiv
link communication that so indicates. Hence, a Sigfox Device explicitly indicate e a Downlink message (with a size of 8 bytes)
s 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 N
using a Downlink request flag when sending the preceding Uplink message to the n etwork. The Downlink request flag is part of the Sigfox protocol headers. After
etwork. The Downlink request flag is part of the Sigfox protocol headers. After completing the Uplink transmission, the device opens a fixed window for Downlink
completing the Uplink transmission, the Device opens a fixed window for Downlink reception.
reception. The delay and duration of the reception opportunity window have fixed values. If
The delay and duration of the reception opportunity window have fixed values. If there is a Downlink message to be sent for this given device (e.g., either
there is a Downlink message to be sent for this given Device (e.g., either a response to the Uplink message or queued information waiting to be transmitted
a response to the Uplink message or queued information waiting to be transmitted ), the Network transmits this message to the device during the reception window.
), the network transmits this message to the Device during the reception window. If no message is received by the device after
If no message is received by the Device after the reception opportunity window has elapsed, the device closes the reception wi
the reception opportunity window has elapsed, the Device closes the reception wi ndow opportunity and gets back to the normal mode (e.g., continue Uplink transmi
ndow opportunity and gets back to the normal mode (e.g., continue Uplink transmi ssions, sleep, standby, etc.).
ssions, sleep, stand-by, etc.)
</t> </t>
<t>When a Downlink message is sent to a device, a reception acknowledgem
<t>When a Downlink message is sent to a Device, a reception acknowledgement is g ent is generated by the device, sent back to the Network through the Sigfox radi
enerated by the Device and sent back to the Network through the Sigfox radio pro o protocol, and reported in the Sigfox network backend.</t>
tocol and reported in the Sigfox Network backend.</t> <t>
A detailed description of the Sigfox radio protocol can be found in <xref target
<t> ="sigfox-spec" format="default"/>, and a detailed description of the Sigfox call
A detailed description of the Sigfox Radio Protocol can be found in <xref target backs/APIs can be found in <xref target="sigfox-callbacks" format="default"/>. A
="sigfox-spec"/> and a detailed description of the Sigfox callbacks/APIs can be Downlink request flag can be included in the information exchange between the S
found in <xref target="sigfox-callbacks"/>. A Downlink request flag can be inclu igfox network and Network SCHC.
ded in the information exchange between the Sigfox Network and Network SCHC.
</t> </t>
<section anchor="dl_ack" numbered="true" toc="default">
<section anchor="dl_ack" title="SCHC ACK on Downlink"> <name>SCHC ACK on Downlink</name>
<t>
<t> As explained previously, Downlink transmissions are driven by devices and can on
As explained previously, Downlink transmissions are Device-driven and can only t ly take place following a specific Uplink transmission that indicates and allows
ake place following a specific Uplink transmission that indicates and allows a f a following Downlink opportunity.
ollowing Downlink opportunity. For this reason, when SCHC bidirectional services are used (e.g., ACK-on-Error f
For this reason, when SCHC bidirectional services are used (e.g., Ack-on-Error f ragmentation mode), the SCHC protocol implementation needs to consider the times
ragmentation mode) the SCHC protocol implementation needs to consider the times when a Downlink message
when a Downlink message (e.g., SCHC Acknowledgement (ACK)) can be sent and/or received.
(e.g., SCHC ACK) can be sent and/or received.
</t> </t>
<t>
<t> For the Uplink ACK-on-Error fragmentation mode, a Downlink opportunity <bcp14>MU
For the Uplink ACK-on-Error fragmentation mode, a Downlink opportunity MUST be i ST</bcp14> be indicated by the last fragment of every window, which is signalled
ndicated by the last fragment of every window, which is signalled by a specific by a specific value of the Fragment Compressed Number (FCN) value, i.e., FCN =
value of the Fragment Compressed Number (FCN) value, i.e., FCN = All-0, or FCN = All-0 or FCN = All-1. The FCN is the tile index in a specific window. The combin
All-1. The FCN is the tile index in a specific window. The combination of the F ation of the FCN and the window number uniquely identifies a SCHC Fragment, as e
CN and the window number uniquely identifies a SCHC Fragment as explained in <xr xplained in <xref target="RFC8724" format="default"/>.
ef target="RFC8724"/>. The device sends the fragments in sequence and, after
The Device sends the fragments in sequence and, after transmitting FCN = All-0 or FCN = All-1, it opens up a reception opportunity. Th
transmitting the FCN = All-0 or FCN = All-1, it opens up a reception opportunity e Network SCHC can then decide to respond at that opportunity (or wait for a fur
. The Network SCHC can then decide to respond at that opportunity (or wait for a ther one) with a SCHC ACK, indicating that there are missing fragments from the
further one) with a SCHC ACK indicating that there are missing fragments from t current or previous windows. If there is no SCHC ACK to be sent, or if the Netwo
he current or previous windows. If there is no SCHC ACK to be sent, or if the ne rk decides to wait for a further Downlink transmission opportunity, then no
twork decides to wait for a further Downlink transmission opportunity, then no Downlink transmission takes place at that opportunity and the Uplink transmissio
Downlink transmission takes place at that opportunity and after a timeout the Up ns continue after a timeout.
link transmissions continue. Intermediate SCHC fragments with FCN different from Intermediate SCHC Fragments with FCNs that are different from All-0 or All-1
All-0 or All-1 MUST NOT use the Downlink request flag <bcp14>MUST NOT</bcp14> use the Downlink request flag to request a SCHC ACK.
to request a SCHC ACK.
</t> </t>
</section>
</section> </section>
<section anchor="schc-rules" numbered="true" toc="default">
</section> <name>SCHC Rules</name>
<t>
<section anchor="schc-rules" title="SCHC Rules"> The RuleID <bcp14>MUST</bcp14> be included in the SCHC header. The total number
of Rules to be used directly affects the RuleID field size, and therefore
<t> the total size of the fragmentation header. For this reason, it is <bcp14>RECOMM
The RuleID MUST be included in the SCHC header. The total number of rules to be ENDED</bcp14> to keep the number of Rules that are defined for a specific device
used affects directly the RuleID field size, and therefore to the minimum possible.
the total size of the fragmentation header. For this reason, it is RECOMMENDED t Large RuleID sizes (and thus larger fragmentation headers) are acceptable fo
o keep the number of rules that are defined for a specific device to the minimum r devices without significant energy constraints (e.g., a sensor that is powered
possible. by the electricity grid).
Large RuleID sizes (and thus larger fragmentation header) is acceptable for
devices without significant energy constraints (e.g., a sensor that is powered b
y the electricity grid).
</t> </t>
<t> <t>
RuleIDs can be used to differentiate data traffic classes (e.g., QoS, control v RuleIDs can be used to differentiate data traffic classes (e.g., QoS, control v
s. data, etc.), and data sessions. s. data, etc.) and data sessions.
They can also be used to interleave simultaneous fragmentation sessions between They can also be used to interleave simultaneous fragmentation sessions between
a Device and the Network. a device and the Network.
</t> </t>
</section>
</section> <section anchor="Frag" numbered="true" toc="default">
<name>Fragmentation</name>
<section anchor="Frag" title="Fragmentation"> <t>
The SCHC specification <xref target="RFC8724" format="default"/> defines a gener
<t> ic fragmentation functionality that
The SCHC specification <xref target="RFC8724"/> defines a generic fragmentation allows sending data packets or files larger than the maximum size of a Sigfox pa
functionality that yload. The functionality also defines a mechanism to reliably send multiple mess
allows sending data packets or files larger than the maximum size of a Sigfox pa ages by allowing to selectively resend any lost fragments.</t>
yload. The functionality also defines a mechanism to send <t>
reliably multiple messages, by allowing to resend selectively any lost fragments The SCHC fragmentation supports several modes of operation. These modes have dif
. </t> ferent advantages and disadvantages, depending
on the specifics of the underlying LPWAN technology and application use case. Th
<t> is section describes how the SCHC fragmentation functionality
The SCHC fragmentation supports several modes of operation. These modes have dif should optimally be implemented when used over a Sigfox LPWAN for the most typic
ferent advantages and disadvantages depending al use case applications.</t>
on the specifics of the underlying LPWAN technology and application Use Case. Th <t>As described in <xref target="RFC8724" format="default" sectionFormat
is section describes how the SCHC fragmentation functionality ="of" section="8.2.3"/>, the integrity of the fragmentation-reassembly process o
should optimally be implemented when used over a Sigfox LPWAN for the most typic f a SCHC Packet <bcp14>MUST</bcp14> be
al Use Case applications.</t>
<t>As described in section 8.2.3 of <xref target="RFC8724"/>, the integrity of t
he fragmentation-reassembly process of a SCHC Packet MUST 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, 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 se quence and all FCN bitmaps are complete. With this functionality integrity can be guaranteed when no consecutive messages are missing from the se quence and all FCN bitmaps are complete. With this functionality
in mind, and in order to save protocol and processing overhead, the use of a Rea in mind, and in order to save protocol and processing overhead, the use of a Rea
ssembly Check Sequence (RCS) as described in ssembly Check Sequence (RCS), as described in
<xref target="all-1-behaviour"/> MUST be used. <xref 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 <x
ref target="RFC8724"/> with the SCHC Compound ACK concept.</t>
<t>
The SCHC Compound ACK is a SCHC ACK message that can contain several bitmaps, ea
ch bitmap being identified by its
corresponding window number.
The SCHC Compound ACK concept is meant to reduce the number of Downlink transmis
sions (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 AC
Ks 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 losse
s 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 wind
ow 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 lo
west-numbered to the highest-numbered window.
</t>
</section>
<section anchor="uplink-fragmentation" title="Uplink Fragmentation">
<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, and then wake up and transmit wh
enever there is a need to send information to the network, as there is no need t
o perform any network attachment, synchronization, or other procedure before tra
nsmitting a data packet.
<!--Data packets are self-contained (aka “message in a bottle”) with all the req
uired 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>
<section anchor="uplink-fragmentation" numbered="true" toc="default">
<t>Since Uplink transmissions are asynchronous, a SCHC fragment can be transmitt <name>Uplink Fragmentation</name>
ed at any given time by the Device. Sigfox Uplink messages <t>Sigfox Uplink transmissions are completely asynchronous and take pl
are fixed in size, and as described in <xref target="RFC8376"/> they can carry 0 ace in any random frequency of the allowed Uplink bandwidth allocation.
-12 bytes payload. Hence, a single SCHC Tile size per fragmentation In addition, devices may go to deep sleep mode and then wake up and transmit whe
mode can be defined so that every Sigfox message always carries one SCHC Tile.</ never there is a need to send information to the Network, as there is no need to
t> perform any Network attachment, synchronization, or other procedures before tra
nsmitting a data packet.
<t>When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC Compoun </t>
d ACK defined in <xref target="I-D.ietf-lpwan-schc-compound-ack"/>) MUST be used <t>Since Uplink transmissions are asynchronous, a SCHC Fragment can be
in the Downlink responses.</t> transmitted at any given time by the device. Sigfox Uplink messages
are fixed in size, and as described in <xref target="RFC8376" format="default"/>
<section anchor="schc_sender_abort" title="SCHC Sender-Abort"> , they can carry a payload of 0-12 bytes (0-96 bits). Hence, a single SCHC Tile
size, per fragmentation
<t>As defined in <xref target="RFC8724"/>, a SCHC Sender-Abort can be triggered mode, can be defined so that every Sigfox message always carries one SCHC Tile.<
when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK_REQ /t>
UESTS. <t>When the ACK-on-Error mode is used for Uplink fragmentation, the SC
In the case of SCHC over Sigfox, a SCHC Sender-Abort MUST be sent if the number HC Compound ACK defined in <xref target="RFC9441" format="default"/> <bcp14>MUST
of repeated All-1s sent in sequence, without a Compound ACK reception inbetween, </bcp14> be used in the Downlink responses.</t>
is greater than or equal to MAX_ACK_REQUESTS. <section anchor="schc_sender_abort" numbered="true" toc="default">
<!-- be sent if the number of repeated All-1s (i.e., with the same bitmap) se <name>SCHC Sender-Abort</name>
nt in sequence is greater than or equal to MAX_ACK_REQUESTS. --> <t>As defined in <xref target="RFC8724" format="default"/>, a SCHC S
ender-Abort can be triggered when the number of SCHC ACK REQ attempts is greater
than or equal to MAX_ACK_REQUESTS.
In the case of SCHC over Sigfox, a SCHC Sender-Abort <bcp14>MUST</bcp14> be sent
if the number of repeated All-1s sent in sequence, without a Compound ACK recep
tion in between, is greater than or equal to MAX_ACK_REQUESTS.
</t> </t>
<!--<t>The Attempts counter MUST be reset when a SCHC ACK is successfully receiv
ed.</t>-->
</section> </section>
<section anchor="schc_receiver_abort" numbered="true" toc="default">
<section anchor="schc_receiver_abort" title="SCHC Receiver-Abort"> <name>SCHC Receiver-Abort</name>
<t>As defined in <xref target="RFC8724" format="default"/>, a SCHC R
<t>As defined in <xref target="RFC8724"/>, a SCHC Receiver-Abort is triggered wh eceiver-Abort is triggered when the receiver has no RuleID and DTag pairs availa
en the receiver has no RuleID and DTag pairs available for a new session. ble for a new session.
In the case of this profile a SCHC Receiver-Abort MUST be sent if, for a single In the case of this profile, a SCHC Receiver-Abort <bcp14>MUST</bcp14> be sent i
device, all the RuleIDs are being processed by the receiver (i.e., have an activ f, for a single device, all the RuleIDs are being processed by the receiver (i.e
e session) ., have an active session)
at a certain time and a new one is requested, or if the RuleID of the fragment i at a certain time and a new one is requested or if the RuleID of the fragment is
s not valid.</t> not valid.</t>
<t>A SCHC Receiver-Abort <bcp14>MUST</bcp14> be triggered when the I
<t>A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer expires. </ nactivity Timer expires. </t>
t> <t>MAX_ACK_REQUESTS can be increased when facing high error rates. <
/t>
<t>MAX_ACK_REQUESTS can be increased when facing high error rates. </t> <t>Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC
Receiver-Abort Downlink message <bcp14>MUST</bcp14> only be sent when there is a
<!--<t>A SCHC-Receiver Abort can be triggered when the number of ACK attempts is Downlink transmission opportunity.</t>
not strictly less than MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, --> </section>
<!--a SCHC-Receiver Abort MUST be sent if the number of repeated SCHC ACKs sent <section anchor="single-byte-schc-header" numbered="true" toc="default
in a row (i.e., synchronized with the ACK REQ case, and with identical bitmaps) ">
--> <name>Single-Byte SCHC Header for Uplink Fragmentation</name>
<!--is greater than or equal to MAX_ACK_REQUESTS.</t>--> <section anchor="no-ack-mode" numbered="true" toc="default">
<name>Uplink No-ACK Mode: Single-Byte SCHC Header</name>
<t>Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC <t>Single-byte SCHC Header No-ACK mode <bcp14>MUST</bcp14> be used
Receiver-Abort Downlink message MUST only be sent when there is a Downlink trans for transmitting short, non-critical packets that require fragmentation and do
mission opportunity.</t> not require full reliability.
This mode can be used by Uplink-only devices that do not support Downlink commun
</section> ications or by bidirectional devices when they send non-critical
<section anchor="single-byte-schc-header" title="Single-byte SCHC Header for Upl
ink Fragmentation">
<section anchor="no-ack-mode" title="Uplink No-ACK Mode: Single-byte SCHC Header
">
<t>Single-byte SCHC Header No-ACK mode MUST 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 commun
ications, or by bidirectional devices when they send non-critical
data. data.
Note that sending non-critical data by using a reliable fragmentation mode (whic h is only possible for bidirectional devices) may incur unnecessary overhead. </ t> Note that sending non-critical data by using a reliable fragmentation mode (whic h 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 b
<t>Since there are no multiple windows in the No-ACK mode, the W bit is not pres it is not present.
ent. However, it <bcp14>MUST</bcp14> use the FCN field to indicate the
However, it MUST use the FCN field to indicate the
size of the data packet. In this sense, the data packet would need to be split i nto X fragments and, similarly to the other fragmentation modes, size of the data packet. In this sense, the data packet would need to be split i nto X fragments and, similarly to the other fragmentation modes,
the first transmitted fragment would need to be marked with FCN = X-1. Consecuti the first transmitted fragment would need to be marked with FCN = X-1. Consecuti
ve fragments MUST be marked with decreasing FCN values, having the ve fragments <bcp14>MUST</bcp14> be marked with decreasing FCN values, having th
last fragment marked with FCN = (All-1). Hence, even though the No-ACK mode does e
not allow recovering missing fragments, it allows indicating implicitly last fragment marked with FCN = (All-1). Hence, even though the No-ACK mode does
the size of the expected packet to the Network and hence detect at the receiver not allow recovering missing fragments, it allows implicitly indicating
side whether all fragments have been received or not. the size of the expected packet to the Network and hence detects whether all fra
gments have been received or not at the receiver side.
In case the FCN field is not used to indicate the size of the data packet, the N etwork can detect whether all fragments have been received or not by using the i ntegrity check. In case the FCN field is not used to indicate the size of the data packet, the N etwork can detect whether all fragments have been received or not by using the i ntegrity check.
</t> </t>
<t>When using the Single-byte SCHC Header for Uplink fragmentation
<t>When using the Single-byte SCHC Header for Uplink Fragmentation, the , the
Fragmentation Header MUST be of 8 bit size, and the Fragment header is comp fragmentation header <bcp14>MUST</bcp14> be 8 bits in size and is c
osed as omposed as follows:</t>
follows:</t> <ul spacing="normal">
<li>RuleID size: 3 bits</li>
<t><list style="symbols"> <li>DTag size (T): 0 bits</li>
<li>Fragment Compressed Number (FCN) size (N): 5 bits</li>
<t>RuleID size: 3 bits</t> </ul>
<t>Other F/R parameters <bcp14>MUST</bcp14> be configured as follo
<t>DTag size (T): 0 bit</t> ws:</t>
<ul spacing="normal">
<t>Fragment Compressed Number (FCN) size (N): 5 bits</t> <li>As per <xref target="RFC8724" format="default"/>, in the No-
ACK mode, the W (window) field is not present. </li>
</list></t> <li>Regular tile size: 11 bytes</li>
<t>Other F/R parameters MUST be configured as follows:</t> <li>All-1 tile size: 0 to 10 bytes</li>
<t><list style="symbols"> <li>Inactivity Timer: Application-dependent. The default value i
s 12 hours.</li>
<t>As per <xref target="RFC8724"/>, in the No-ACK mode the W (window) field is n <li>RCS size: 5 bits </li>
ot present. </t> </ul>
<t>The maximum SCHC Packet size is 340 bytes.</t>
<t>Regular tile size: 11 bytes</t> <t><xref target="UL-NoACK-single-byte" format="default"/> presents
SCHC Fragment format examples, and <xref target="no-ack-examples" format="defau
<t>All-1 tile size: 0 to 10 bytes</t> lt"/> provides fragmentation examples, using Single-byte SCHC Header No-ACK mode
.</t>
<t>Inactivity Timer: Application-dependent. The default value is 12 hours.</t> </section>
<section anchor="ack-on-error-mode-1" numbered="true" toc="default">
<t>RCS size: 5 bits </t> <name>Uplink ACK-on-Error Mode: Single-Byte SCHC Header</name>
<t>ACK-on-Error with a single-byte header <bcp14>MUST</bcp14> be u
</list></t> sed for short- to medium-sized packets that need to be sent
<t>The maximum SCHC Packet size is 340 bytes.</t>
<t><xref target="UL-NoACK-single-byte"/> presents SCHC Fragment format examples
and <xref target="no-ack-examples"/> provides fragmentation examples, using Sin
gle-byte SCHC Header No-ACK mode.</t>
</section>
<section anchor="ack-on-error-mode-1" title="Uplink ACK-on-Error Mode: Single-by
te SCHC Header">
<t>ACK-on-Error with single-byte header MUST be used for short to medium size pa
ckets 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 reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox transmissions, since it leads to a reduced number of ACKs
in the lower capacity Downlink channel. Also, Downlink messages can be sent a synchronously and opportunistically. in the lower-capacity Downlink channel. Also, Downlink messages can be sent a synchronously and opportunistically.
In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK wo uld not allow reliable transmission. In contrast, ACK-Always would not minimize the number of ACKs, and No-ACK wo uld not allow reliable transmission.
</t> </t>
<t>Allowing transmission of packets/files up to 300 bytes long, th
<t>Allowing transmission of packets/files up to 300 bytes long, the SCHC Uplink e SCHC Uplink fragmentation header size is 8 bits in size and is composed as fol
Fragmentation Header size is 8 bits in size and is composed as follows: lows:
</t> </t>
<ul spacing="normal">
<!-- <li>RuleID size: 3 bits</li>
<t><list style="symbols"> <li>DTag size (T): 0 bits</li>
<t>Single-byte SCHC Uplink header</t> <li>Window index (W) size (M): 2 bits </li>
</list></t> <li>Fragment Compressed Number (FCN) size (N): 3 bits</li>
</ul>
<t><list style="symbols"> <t>Other F/R parameters <bcp14>MUST</bcp14> be configured as follo
ws:</t>
<t>RuleID size: 3 bits</t> <ul spacing="normal">
<li>MAX_ACK_REQUESTS: 5</li>
<t>DTag size (T): 0 bit</t> <li>WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)</li>
<li>Regular tile size: 11 bytes</li>
<t>Window index (W) size (M): 2 bits </t> <li>All-1 tile size: 0 to 10 bytes</li>
<li>Retransmission Timer: Application-dependent. The default val
<t>Fragment Compressed Number (FCN) size (N): 3 bits</t> ue is 12 hours.</li>
</list></t> <li>Inactivity Timer: Application-dependent. The default value i
<t>Other F/R parameters MUST be configured as follows:</t> s 12 hours.</li>
<t><list style="symbols"> <li>RCS size: 3 bits</li>
<t>MAX_ACK_REQUESTS: 5</t> </ul>
<t><xref target="UL-ACKoE-single-byte" format="default"/> presents
<t>WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)</t> SCHC Fragment format examples, and <xref target="ack-on-error-examples-1B-heade
r" format="default"/> provides fragmentation examples, using ACK-on-Error with a
<t>Regular tile size: 11 bytes</t> single-byte header.</t>
</section>
<t>All-1 tile size: 0 to 10 bytes</t> </section>
<section anchor="two-byte-schc-header" numbered="true" toc="default">
<t>Retransmission Timer: Application-dependent. The default value is 12 hours.</ <name>Two-Byte SCHC Header for Uplink Fragmentation</name>
t> <t>ACK-on-Error with a two-byte header <bcp14>MUST</bcp14> be used f
or medium- to large-sized packets that need to be sent
<t>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>
<t>RCS size: 3 bits</t>
</list></t>
<t><xref target="UL-ACKoE-single-byte"/> presents SCHC Fragment format e
xamples and <xref target="ack-on-error-examples-1B-header"/> provides fragmentat
ion examples, using ACK-on-Error with single-byte header.</t>
</section>
</section>
<section anchor="two-byte-schc-header" title="Two-byte SCHC Header for Uplink Fr
agmentation">
<t>ACK-on-Error with two-byte header MUST be used for medium-large size packets
that need to be sent
reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox, since it reliably. ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox, since it
leads to a reduced number of ACKs in the lower capacity Downlink leads to a reduced number of ACKs in the lower-capacity Downlink
channel. Also, Downlink messages can be sent asynchronously and channel. Also, Downlink messages can be sent asynchronously and
opportunistically. In contrast, ACK-Always would not minimize the number of A CKs, and No-ACK would not allow reliable transmission. opportunistically. In contrast, ACK-Always would not minimize the number of A CKs, and No-ACK would not allow reliable transmission.
</t> </t>
<section anchor="ack-on-error-mode-2" title="Uplink ACK-on-Error Mode: Two-byte <section anchor="ack-on-error-mode-2" numbered="true" toc="default">
SCHC Header Option 1"> <name>Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1</nam
e>
<t>In order to allow transmission of medium-large packets/files up to 480 bytes <t>In order to allow transmission of medium to large packets/files
long, the SCHC Uplink Fragmentation Header size is 16 bits in size and composed up to 480 bytes long, the SCHC Uplink fragmentation header size is 16 bits in s
as follows:</t> ize and is composed as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>RuleID size: 6 bits</li>
<li>DTag size (T): 0 bits</li>
<t>RuleID size is: 6 bits</t> <li>Window index (W) size (M): 2 bits </li>
<li>Fragment Compressed Number (FCN) size (N): 4 bits</li>
<t>DTag size (T) is: 0 bit</t> <li>RCS size: 4 bits</li>
</ul>
<t>Window index (W) size (M): 2 bits </t> <t>Other F/R parameters <bcp14>MUST</bcp14> be configured as follo
ws:</t>
<t>Fragment Compressed Number (FCN) size (N): 4 bits.</t> <ul spacing="normal">
<li>MAX_ACK_REQUESTS: 5</li>
<t>RCS size: 4 bits</t> <li>WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)</li>
</list></t> <li>Regular tile size: 10 bytes</li>
<t>Other F/R parameters MUST be configured as follows:</t> <li>All-1 tile size: 1 to 10 bytes</li>
<t><list style="symbols"> <li>Retransmission Timer: Application-dependent. The default val
<t>MAX_ACK_REQUESTS: 5</t> ue is 12 hours.</li>
<li>Inactivity Timer: Application-dependent. The default value i
<t>WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)</t> s 12 hours.</li>
</ul>
<t>Regular tile size: 10 bytes</t> <t>Note that WINDOW_SIZE is limited to 12. This is because 4 windo
ws (M = 2) with bitmaps of size 12 can be fitted in a
<t>All-1 tile size: 1 to 10 bytes</t>
<t>Retransmission Timer: Application-dependent. The default value is 12 hours.</
t>
<t>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>
</list></t>
<t>Note that WINDOW_SIZE is limited to 12. This because, 4 windows (M = 2) with
bitmaps of size 12 can be fitted in a
single SCHC Compound ACK.</t> single SCHC Compound ACK.</t>
<t><xref target="UL-ACKoE-two-byte-opt-1"/> presents SCHC Fragment format examp <t><xref target="UL-ACKoE-two-byte-opt-1" format="default"/> prese
les, using ACK-on-Error with two-byte header Option 1.</t> nts SCHC Fragment format examples, using ACK-on-Error with two-byte header Optio
</section> n 1.</t>
</section>
<section anchor="ack-on-error-mode-3" title="Uplink ACK-on-Error Mode: Two-byte <section anchor="ack-on-error-mode-3" numbered="true" toc="default">
SCHC Header Option 2"> <name>Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2</nam
e>
<t>In order to allow transmission of very large packets/files up to 2400 bytes l <t>In order to allow transmission of very large packets/files up t
ong, the SCHC Uplink Fragmentation Header size is 16 bits in size and composed a o 2400 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size
s follows:</t> and is composed as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>RuleID size: 8 bits</li>
<li>DTag size (T): 0 bits</li>
<t>RuleID size is: 8 bits</t> <li>Window index (W) size (M): 3 bits </li>
<li>Fragment Compressed Number (FCN) size (N): 5 bits</li>
<t>DTag size (T) is: 0 bit</t> <li>RCS size: 5 bits</li>
</ul>
<t>Window index (W) size (M): 3 bits </t> <t>Other F/R parameters <bcp14>MUST</bcp14> be configured as follo
ws:</t>
<t>Fragment Compressed Number (FCN) size (N): 5 bits.</t> <ul spacing="normal">
<li>MAX_ACK_REQUESTS: 5</li>
<t>RCS size: 5 bits</t> <li>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</li>
<li>Regular tile size: 10 bytes</li>
</list></t> <li>All-1 tile size: 0 to 9 bytes</li>
<t>Other F/R parameters MUST be configured as follows:</t> <li>Retransmission Timer: Application-dependent. The default val
<t><list style="symbols"> ue is 12 hours.</li>
<t>MAX_ACK_REQUESTS: 5</t> <li>Inactivity Timer: Application-dependent. The default value i
s 12 hours.</li>
<t>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</t> </ul>
<t><xref target="UL-ACKoE-two-byte" format="default"/> presents SC
<t>Regular tile size: 10 bytes</t> HC Fragment format examples, using ACK-on-Error with two-byte header Option 2.</
t>
<t>All-1 tile size: 0 to 9 bytes</t> </section>
</section>
<t>Retransmission Timer: Application-dependent. The default value is 12 hours.</ <section anchor="all-1-behaviour" numbered="true" toc="default">
t> <name>All-1 SCHC Fragment and RCS Behavior</name>
<t>For ACK-on-Error, as defined in <xref target="RFC8724" format="de
<t>Inactivity Timer: Application-dependent. The default value is 12 hours.</t> fault"/>, it is expected that the last SCHC Fragment of the last window will alw
ays be delivered
</list></t>
<t><xref target="UL-ACKoE-two-byte"/> presents SCHC Fragment format examples, u
sing ACK-on-Error with two-byte header Option 1.</t>
</section>
</section>
<section anchor="all-1-behaviour" title="All-1 SCHC Fragment and RCS behaviour">
<t>For ACK-on-Error, as defined in <xref target="RFC8724"/>, it is expected that
the last SCHC fragment of the last window will always be delivered
with an All-1 FCN. Since this last window may not be full (i.e., it may be compo sed of fewer than WINDOW_SIZE fragments), an All-1 fragment with an All-1 FCN. Since this last window may not be full (i.e., it may be compo sed 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 canno t determine from the FCN values alone may follow a value of FCN higher than 1 (0b01). In this case, the receiver canno t determine from the FCN values alone
whether there are or not any missing fragments right before the All-1 fragment. whether there are or are not any missing fragments right before the All-1 fragme nt.
</t> </t>
<t>For Rules where the number of fragments in the last window is unk
<t>For Rules where the number of fragments in the last window is unknown, an RCS nown, an RCS field <bcp14>MUST</bcp14> be used, indicating the number of fragmen
field MUST be used, indicating the number of fragments ts
in the last window, including the All-1. With this RCS value, the receiver can d etect if there are missing fragments before the All-1 and hence in the last window, including the All-1. With this RCS value, the receiver can d etect if there are missing fragments before the All-1 and hence
construct the corresponding SCHC ACK Bitmap accordingly, and send it in response to the All-1. construct the corresponding SCHC ACK Bitmap accordingly and send it in response to the All-1.
</t> </t>
</section>
</section> </section>
<section anchor="downlink-fragmentation" numbered="true" toc="default">
</section> <name>Downlink Fragmentation</name>
<t>In some LPWAN technologies, as part of energy-saving techniques, Do
<section anchor="downlink-fragmentation" title="Downlink Fragmentation"> wnlink transmission is only possible immediately after an Uplink
transmission. This allows the device to go in a very deep sleep mode and preserv
<t>In some LPWAN technologies, as part of energy-saving techniques, Downlink tra e battery without the need to listen to any information
nsmission is only possible immediately after an Uplink from the Network. This is the case for Sigfox-enabled devices, which can only li
transmission. This allows the device to go in a very deep sleep mode and preserv sten to Downlink communications after performing an
e battery, without the need to listen to any information
from the network. This is the case for Sigfox-enabled devices, which can only li
sten to Downlink communications after performing an
Uplink transmission and requesting a Downlink.</t> Uplink transmission and requesting a Downlink.</t>
<t>When there are fragments to be transmitted in the Downlink, an Upli
<t>When there are fragments to be transmitted in the Downlink, an Uplink message nk message is required to trigger the Downlink communication.
is required to trigger the Downlink communication. In order to avoid a potentially high delay for fragmented datagram transmission
In order to avoid potentially high delay for fragmented datagram transmission in in the Downlink, the fragment receiver <bcp14>MAY</bcp14> perform an
the Downlink, the fragment receiver MAY perform an Uplink transmission as soon as possible after reception of a Downlink fragment t
Uplink transmission as soon as possible after reception of a Downlink fragment t hat is not the last one. Such an Uplink transmission
hat is not the last one. Such Uplink transmission <bcp14>MAY</bcp14> be triggered by sending a SCHC message, such as a SCHC ACK. H
MAY be triggered by sending a SCHC message, such as a SCHC ACK. However, other d owever, other data messages can equally be used to trigger Downlink
ata messages can equally be used to trigger Downlink
communications. communications.
The fragment receiver MUST send an Uplink transmission (e.g., empty message) and request a Downlink every 24 hours when no SCHC session is started. The use or n ot of this Uplink transmission (and the transmission rate, if used) will depend on application specific requirements. The fragment receiver <bcp14>MUST</bcp14> send an Uplink transmission (e.g., emp ty message) and request a Downlink every 24 hours when no SCHC session is starte d. Whether this Uplink transmission is used (and the transmission rate, if used) depends on application-specific requirements.
</t> </t>
<t>Sigfox Downlink messages are fixed in size, and as described in <xr
<t>Sigfox Downlink messages are fixed in size, and as described in <xref target= ef target="RFC8376" format="default"/> they can carry a payload of 0-8 bytes (0-
"RFC8376"/> they can carry up to 8 bytes payload. Hence, a 64 bits). Hence, a
single SCHC Tile size per mode can be defined so that every Sigfox message alway s carries one SCHC Tile. single SCHC Tile size per mode can be defined so that every Sigfox message alway s carries one SCHC Tile.
</t> </t>
<t>For reliable Downlink fragment transmission, the ACK-Always mode <b
<t>For reliable Downlink fragment transmission, the ACK-Always mode SHOULD be us cp14>SHOULD</bcp14> be used.
ed.
Note that ACK-on-Error does not guarantee Uplink feedback (since no SCHC ACK wil l be sent when no errors occur in a window), and No-ACK would not allow reliable transmission.</t> Note that ACK-on-Error does not guarantee Uplink feedback (since no SCHC ACK wil l be sent when no errors occur in a window), and No-ACK would not allow reliable transmission.</t>
<t>The SCHC Downlink fragmentation header size is 8 bits in size and i
<t>The SCHC Downlink Fragmentation Header size is 8 bits in size and is composed s composed as follows:</t>
as follows:</t> <ul spacing="normal">
<li>RuleID size: 3 bits</li>
<t><list style="symbols"> <li>DTag size (T): 0 bits</li>
<t>RuleID size: 3 bits</t> <li>Window index (W) size (M): 0 bits </li>
<li>Fragment Compressed Number (FCN) size (N): 5 bits</li>
<t>DTag size (T): 0 bit</t> </ul>
<t>Other F/R parameters <bcp14>MUST</bcp14> be configured as follows:<
<t>Window index (W) size (M) is: 0 bit </t> /t>
<ul spacing="normal">
<t>Fragment Compressed Number (FCN) size (N): 5 bits</t> <li>MAX_ACK_REQUESTS: 5</li>
</list></t> <li>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</li>
<t>Other F/R parameters MUST be configured as follows:</t> <li>Regular tile size: 7 bytes</li>
<t><list style="symbols"> <li>All-1 tile size: 0 to 6 bytes</li>
<t>MAX_ACK_REQUESTS: 5</t> <li>Retransmission Timer: Application-dependent. The default value i
s 12 hours.</li>
<t>WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)</t> <li>Inactivity Timer: Application-dependent. The default value is 12
hours.</li>
<t>Regular tile size: 7 bytes</t> <li>RCS size: 5 bits </li>
</ul>
<t>All-1 tile size: 0 to 6 bytes</t>
<t>Retransmission Timer: Application-dependent. The default value is 12 hours.</
t>
<t>Inactivity Timer: Application-dependent. The default value is 12 hours.</t>
<t>RCS size: 5 bits </t>
</list></t>
<!--
<t>Sigfox Downlink frames have a fixed length of 8 bytes, which means that defau
lt SCHC algorithm for padding cannot be used.
Therefore, the 3 last bits of the fragmentation header are used to indicate in b
ytes the size of the padding.
A size of 000 means that the full remaining frame is used to carry payload, a va
lue of 001 indicates that the last byte contains padding, and so on.</t>
</section>
</section> </section>
</section>
<section anchor="schc-sigfox-message-formats" title="SCHC over Sigfox F/R Messag <section anchor="schc-sigfox-message-formats" numbered="true" toc="default
e Formats"> ">
<name>SCHC over Sigfox F/R Message Formats</name>
<t>This section depicts the different formats of SCHC Fragment, SCHC ACK (includ <t>This section depicts the different formats of SCHC Fragment, SCHC ACK
ing the SCHC Compound ACK (including the SCHC Compound ACK
defined in <xref target="I-D.ietf-lpwan-schc-compound-ack"/>), and SCHC Abort us defined in <xref target="RFC9441" format="default"/>), and SCHC Abort used in SC
ed in SCHC over Sigfox.</t> HC over Sigfox.</t>
<section anchor="UL-NoACK-single-byte" numbered="true" toc="default">
<section anchor="UL-NoACK-single-byte" title="Uplink No-ACK Mode: Single-byte SC <name>Uplink No-ACK Mode: Single-Byte SCHC Header</name>
HC Header"> <section anchor="no-ack-regular-1byte-schc-fragment" numbered="true" t
oc="default">
<section anchor="no-ack-regular-1byte-schc-fragment" title="Regular SCHC Fragmen <name>Regular SCHC Fragment</name>
t"> <t><xref target="no-ack-reg-1byte-frag" format="default"/> shows an
example of a Regular SCHC Fragment for all fragments except the last one.
<t><xref target="no-ack-reg-1byte-frag"/> shows an example of a regular SCHC fra As tiles are 11 bytes in size, padding <bcp14>MUST NOT</bcp14> be add
gment for all fragments except the last one. ed.
As tiles are of 11 bytes, padding MUST NOT be added.
The penultimate tile of a SCHC Packet is of regular size.</t> The penultimate tile of a SCHC Packet is of regular size.</t>
<figure anchor="no-ack-reg-1byte-frag">
<t><figure title="Regular SCHC Fragment format for all fragments except the last <name>Regular SCHC Fragment Format for All Fragments except the La
one" anchor="no-ack-reg-1byte-frag"><artwork><![CDATA[ st One</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
|- SCHC Fragment Header -| |- SCHC Fragment Header -|
+------------------------+---------+ +------------------------+---------+
| RuleID | FCN | Payload | | RuleID | FCN | Payload |
+------------+-----------+---------+ +------------+-----------+---------+
| 3 bits | 5 bits | 88 bits | | 3 bits | 5 bits | 88 bits |
]]></artwork>
]]></artwork></figure></t> </figure>
</section>
</section> <section anchor="no-ack-all-1-1byte-schc-fragment" numbered="true" toc
<section anchor="no-ack-all-1-1byte-schc-fragment" title="All-1 SCHC Fragment ="default">
"> <name>All-1 SCHC Fragment</name>
<t><xref target="no-ack-all-1-1byte" format="default"/> shows an exa
<t><xref target="no-ack-all-1-1byte"/> shows an example of the All-1 message. mple of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet. The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
Padding MUST NOT be added, as the resulting size is L2-word-multiple.</t> Padding <bcp14>MUST NOT</bcp14> be
<t> added, as the resulting size is a multiple of an L2 Word.</t>
The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added <t>
as padding to complete two bytes. The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added
as padding to complete 2 bytes.
The payload size of the All-1 message ranges from 0 to 80 bits. The payload size of the All-1 message ranges from 0 to 80 bits.
</t> </t>
<figure anchor="no-ack-all-1-1byte">
<t><figure title="All-1 SCHC Message format with last tile" anchor="no-ack-all-1 <name>All-1 SCHC Message Format with the Last Tile</name>
-1byte"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|-------- SCHC Fragment Header -------|
|-------- SCHC Fragment Header -------| +--------------------------------------+--------------+
+--------------------------------------+--------------+ | RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload | +--------+-----------+--------+--------+--------------+
+--------+-----------+--------+--------+--------------+ | 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits |
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> <t>As per <xref target="RFC8724" format="default"/>, the All-1 must
be distinguishable from a SCHC Sender-Abort message (with the same RuleID and N
<t>As per <xref target="RFC8724"/> the All-1 must be distinguishable from a SCHC values).
Sender-Abort message (with same RuleID, and N values). The All-1 <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The All-1 MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
The SCHC Sender-Abort message header size is 1 byte, with no padding bits.</t> <t>For the All-1 message to be distinguishable from the Sender-Abort
message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header wi
<t>For the All-1 message to be distinguishable from the Sender-Abort message, th th no padding).
e Sender-Abort message MUST 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> This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.</t>
</section>
</section> <section anchor="no-ack-snd-abort-msg-format" numbered="true" toc="def
ault">
<section anchor="no-ack-snd-abort-msg-format" title="SCHC Sender-Abort Message f <name>SCHC Sender-Abort Message Format</name>
ormat"> <figure anchor="no-ack-snd-abort-msg">
<name>SCHC Sender-Abort Message Format</name>
<t><figure title="SCHC Sender-Abort message format" anchor="no-ack-snd-abort-msg <artwork name="" type="" align="center" alt=""><![CDATA[
"><artwork><![CDATA[ Sender-Abort
|------ Header ------|
Sender-Abort +--------------------+
|------ Header ------| | RuleID | FCN=ALL-1 |
+--------------------+ +--------+-----------+
| RuleID | FCN=ALL-1 | | 3 bits | 5 bits |
+--------+-----------+ ]]></artwork>
| 3 bits | 5 bits | </figure>
</section>
]]></artwork></figure></t> </section>
<section anchor="UL-ACKoE-single-byte" numbered="true" toc="default">
</section> <name>Uplink ACK-on-Error Mode: Single-Byte SCHC Header</name>
<section anchor="regular-1byte-schc-fragment" numbered="true" toc="def
</section> ault">
<section anchor="UL-ACKoE-single-byte" title="Uplink ACK-on-Error Mode: Single-b <name>Regular SCHC Fragment</name>
yte SCHC Header"> <t><xref target="reg-1byte-frag" format="default"/> shows an example
of a Regular SCHC Fragment for all fragments except the last one.
<section anchor="regular-1byte-schc-fragment" title="Regular SCHC Fragment"> As tiles are 11 bytes in size, padding <bcp14>MUST NOT</bcp14> be added.</t>
<figure anchor="reg-1byte-frag">
<t><xref target="reg-1byte-frag"/> shows an example of a regular SCHC fragment f <name>Regular SCHC Fragment Format for All Fragments except the La
or all fragments except the last one. st One</name>
As tiles are of 11 bytes, padding MUST NOT be added.</t> <artwork name="" type="" align="center" alt=""><![CDATA[
|-- SCHC Fragment Header --|
<t><figure title="Regular SCHC Fragment format for all fragments except the last +--------------------------+---------+
one" anchor="reg-1byte-frag"><artwork><![CDATA[ | RuleID | W | FCN | Payload |
+--------+--------+--------+---------+
|-- SCHC Fragment Header --| | 3 bits | 2 bits | 3 bits | 88 bits |
+--------------------------+---------+ ]]></artwork>
| RuleID | W | FCN | Payload | </figure>
+--------+--------+--------+---------+ <t>The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All
| 3 bits | 2 bits | 3 bits | 88 bits | -1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the rece
iver (Network SCHC).
]]></artwork></figure></t> As per <xref target="RFC8724" format="default"/>, the All-0 message is distingui
shable from the SCHC ACK REQ (All-1 message).
<t>The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be us
ed to request a SCHC ACK from the receiver (Network SCHC).
As per <xref target="RFC8724"/>, the All-0 message is distinguishable from the S
CHC ACK REQ (All-1 message).
The penultimate tile of a SCHC Packet is of regular size.</t> The penultimate tile of a SCHC Packet is of regular size.</t>
</section>
</section> <section anchor="all-1-1byte-schc-fragment" numbered="true" toc="defau
lt">
<section anchor="all-1-1byte-schc-fragment" title="All-1 SCHC Fragment"> <name>All-1 SCHC Fragment</name>
<t><xref target="all-1-1byte" format="default"/> shows an example of
<t><xref target="all-1-1byte"/> shows an example of the All-1 message. the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet. The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.
Padding MUST NOT be added, as the resulting size is L2-word-multiple.</t> Padding <bcp14>MUST NOT</bcp14> be added, as the resulting size is L2-word-multi
ple.</t>
<t><figure title="All-1 SCHC Message format with last tile" anchor="all-1-1byte" <figure anchor="all-1-1byte">
><artwork><![CDATA[ <name>All-1 SCHC Message Format with the Last Tile</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
|------------- SCHC Fragment Header -----------| |------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+ +-----------------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload | | RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload |
+--------+--------+-----------+--------+--------+--------------+ +--------+--------+-----------+--------+--------+--------------+
| 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits | | 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits |
]]></artwork>
]]></artwork></figure></t> </figure>
<t>As per <xref target="RFC8724" format="default"/>, the All-1 must
<t>As per <xref target="RFC8724"/> the All-1 must be distinguishable from a SCHC be distinguishable from a SCHC Sender-Abort message (with same RuleID, M, and N
Sender-Abort message (with same RuleID, M, and N values). values).
The All-1 MAY have the last tile of the SCHC Packet. The All-1 <bcp14>MAY</bcp14> have the last tile of the SCHC Packet.
The SCHC Sender-Abort message header size is 1 byte, with no padding bits.</t> The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
<t>For the All-1 message to be distinguishable from the Sender-Abort
<t>For the All-1 message to be distinguishable from the Sender-Abort message, th message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header wi
e Sender-Abort message MUST be of 1 byte (only header with no padding). th no padding).
This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.</t> This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.</t>
</section>
</section> <section anchor="schc-ack-format-1B" numbered="true" toc="default">
<name>SCHC ACK Format</name>
<section anchor="schc-ack-format-1B" title="SCHC ACK Format"> <t><xref target="success-ack-1byte" format="default"/> shows the SCH
C ACK format when all fragments have been correctly received (C=1).
<t><xref target="success-ack-1byte"/> shows the SCHC ACK format when all fragmen Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink fram
ts have been correctly received (C=1). e payload size.</t>
Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size. <figure anchor="success-ack-1byte">
</t> <name>SCHC Success ACK Message Format</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
<t><figure title="SCHC Success ACK message format" anchor="success-ack-1byte"><a |---- SCHC ACK Header ----|
rtwork><![CDATA[ +-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
|---- SCHC ACK Header ----| +--------+--------+-------+---------+
+-------------------------+---------+ | 3 bits | 2 bits | 1 bit | 58 bits |
| RuleID | W | C=b'1 | b'0-pad | ]]></artwork>
+--------+--------+-------+---------+ </figure>
| 3 bits | 2 bits | 1 bit | 58 bits | <t>In case SCHC Fragment losses are found in any of the windows of t
he SCHC Packet (C=0), the SCHC Compound ACK defined in <xref target="RFC9441" fo
]]></artwork></figure></t> rmat="default"/> <bcp14>MUST</bcp14> be used.
The SCHC Compound ACK message format is shown in <xref target="compound-ack-1byt
<t>In case SCHC fragment losses are found in any of the windows of the SCHC Pack e" format="default"/>.
et (C=0), the SCHC Compound ACK defined in <xref target="I-D.ietf-lpwan-schc-com
pound-ack"/> MUST be used.
The SCHC Compound ACK message format is shown in <xref target="compound-ack-1byt
e"/>.
</t> </t>
<figure anchor="compound-ack-1byte">
<t><figure title="SCHC Compound ACK message format" anchor="compound-ack-1byte"> <name>SCHC Compound ACK Message Format</name>
<artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------| |--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
+------+--------+-------+--------+...+--------+--------+------+-------+ +------+--------+-------+--------+...+--------+--------+------+-------+
|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad| |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| |3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|
]]></artwork>
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi </figure>
]]></artwork></figure></t> <t>Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;
...&lt; wi.</t>
</section> </section>
<section anchor="snd-abort-msg-format" numbered="true" toc="default">
<section anchor="snd-abort-msg-format" title="SCHC Sender-Abort Message format"> <name>SCHC Sender-Abort Message Format</name>
<figure anchor="snd-abort-msg">
<t><figure title="SCHC Sender-Abort message format" anchor="snd-abort-msg"><artw <name>SCHC Sender-Abort Message Format</name>
ork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|---- Sender-Abort Header ----|
|---- Sender-Abort Header ----| +-----------------------------+
+-----------------------------+ | RuleID | W=b'11 | FCN=ALL-1 |
| RuleID | W=b'11 | FCN=ALL-1 | +--------+--------+-----------+
+--------+--------+-----------+ | 3 bits | 2 bits | 3 bits |
| 3 bits | 2 bits | 3 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> </section>
<section anchor="rcv-abort-msg-format" numbered="true" toc="default">
</section> <name>SCHC Receiver-Abort Message Format</name>
<figure anchor="rcv-abort-msg">
<section anchor="rcv-abort-msg-format" title="SCHC Receiver-Abort Message format <name>SCHC Receiver-Abort Message Format</name>
"> <artwork name="" type="" align="center" alt=""><![CDATA[
|- Receiver-Abort Header -|
<t><figure title="SCHC Receiver-Abort message format" anchor="rcv-abort-msg"><ar +---------------------------------+-----------------+---------+
twork><![CDATA[ | RuleID | W=b'11 | C=b'1 | b'11 | 0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
|- Receiver-Abort Header -| | 3 bits | 2 bits | 1 bit | 2 bit | 8 bit | 48 bits |
+---------------------------------+-----------------+---------+ next L2 Word boundary ->| <-- L2 Word --> |
| RuleID | W=b'11 | C=b'1 | b'11 | 0xFF (all 1's) | b'0-pad | ]]></artwork>
+--------+--------+-------+-------+-----------------+---------+ </figure>
| 3 bits | 2 bits | 1 bit | 2 bit | 8 bit | 48 bits | </section>
next L2 Word boundary ->| <-- L2 Word --> | </section>
<section anchor="UL-ACKoE-two-byte-opt-1" numbered="true" toc="default">
]]></artwork></figure></t> <name>Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1</name>
<section anchor="opt-1-regular-2byte-schc-fragment" numbered="true" to
</section> c="default">
<name>Regular SCHC Fragment</name>
</section> <t><xref target="opt-1-reg-2byte-frag" format="default"/> shows an e
<section anchor="UL-ACKoE-two-byte-opt-1" title="Uplink ACK-on-Error Mode: Two-b xample of a Regular SCHC Fragment for all fragments except the last one.
yte SCHC Header Option 1">
<section anchor="opt-1-regular-2byte-schc-fragment" title="Regular SCHC Frag
ment">
<t><xref target="opt-1-reg-2byte-frag"/> shows an example of a regular SCHC frag
ment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t> The penultimate tile of a SCHC Packet is of the regular size.</t>
<figure anchor="opt-1-reg-2byte-frag">
<t><figure title="Regular SCHC Fragment format for all fragments except the last <name>Regular SCHC Fragment Format for All Fragments except the La
one" anchor="opt-1-reg-2byte-frag"><artwork><![CDATA[ st One</name>
|------- SCHC Fragment Header ------| <artwork name="" type="" align="center" alt=""><![CDATA[
+-----------------------------------+---------+ |------- SCHC Fragment Header ------|
| RuleID | W | FCN | b'0000 | Payload | +-----------------------------------+---------+
+--------+--------+--------+--------+---------+ | RuleID | W | FCN | b'0000 | Payload |
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits | +--------+--------+--------+--------+---------+
]]></artwork></figure></t> | 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |
]]></artwork>
<t>The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be us </figure>
ed to request a SCHC ACK from the receiver (Network SCHC). <t>The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All
As per <xref target="RFC8724"/>, the All-0 message is distinguishable from the S -1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the rece
CHC ACK REQ (All-1 message).</t> iver (Network SCHC).
As per <xref target="RFC8724" format="default"/>, the All-0 message is distingui
</section> shable from the SCHC ACK REQ (All-1 message).</t>
<section anchor="opt-1-all-1-2B-schc-fragment" title="All-1 SCHC Fragment"> </section>
<section anchor="opt-1-all-1-2B-schc-fragment" numbered="true" toc="de
<t><xref target="opt-1-all-1-2B"/> shows an example of the All-1 message. fault">
The All-1 message MUST contain the last tile of the SCHC Packet.</t> <name>All-1 SCHC Fragment</name>
<t><xref target="opt-1-all-1-2B" format="default"/> shows an example
<t>The All-1 message Fragment Header contains an RCS of 4 bits to complete t of the All-1 message.
he two-byte size. The All-1 message <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 co
mplete the two-byte size.
The size of the last tile ranges from 8 to 80 bits.</t> The size of the last tile ranges from 8 to 80 bits.</t>
<figure anchor="opt-1-all-1-2B">
<t><figure title="All-1 SCHC message format with last tile" anchor="opt-1-all-1- <name>All-1 SCHC Message Format with the Last Tile</name>
2B"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|--------- SCHC Fragment Header -------|
|--------- SCHC Fragment Header -------| +--------------------------------------+--------------+
+--------------------------------------+--------------+ | RuleID | W | FCN=ALL-1 | RCS | Payload |
| RuleID | W | FCN=ALL-1 | RCS | Payload | +--------+--------+-----------+--------+--------------+
+--------+--------+-----------+--------+--------------+ | 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits |
| 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> <t>As per <xref target="RFC8724" format="default"/>, the All-1 must
be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and
<t>As per <xref target="RFC8724"/> the All-1 must be distinguishable from the SC N values).
HC Sender-Abort message (with same RuleID, M and N values). The All-1 <bcp14>MUST</bcp14> have the last tile of the SCHC Packet that <bcp14>
The All-1 MUST have the last tile of the SCHC Packet, that MUST be of at least 1 MUST</bcp14> be at least 1 byte.
byte. The SCHC Sender-Abort message header size is 2 bytes with no padding bits.</t>
The SCHC Sender-Abort message header size is 2 byte, with no padding bits.</t> <t>For the All-1 message to be distinguishable from the Sender-Abort
message, the Sender-Abort message <bcp14>MUST</bcp14> be 2 bytes (only header w
<t>For the All-1 message to be distinguishable from the Sender-Abort message, th ith no padding).
e Sender-Abort message MUST be of 2 byte (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> This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.</t>
</section>
</section> <section anchor="opt-1-schc-ack-format-2B" numbered="true" toc="defaul
<section anchor="opt-1-schc-ack-format-2B" title="SCHC ACK Format"> t">
<name>SCHC ACK Format</name>
<t> <xref target="opt-1-success-ack-2B"/> shows the SCHC ACK format when all fra <t> <xref target="opt-1-success-ack-2B" format="default"/> shows the
gments have been correctly received (C=1). SCHC ACK format when all fragments have been correctly received (C=1).
Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size. Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink fram
</t> e payload size.</t>
<figure anchor="opt-1-success-ack-2B">
<t><figure title="SCHC Success ACK message format" anchor="opt-1-success-ack-2B" <name>SCHC Success ACK Message Format</name>
><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----|
|---- SCHC ACK Header ----| +-------------------------+---------+
+-------------------------+---------+ | RuleID | W | C=b'1 | b'0-pad |
| RuleID | W | C=b'1 | b'0-pad | +--------+--------+-------+---------+
+--------+--------+-------+---------+ | 6 bits | 2 bits | 1 bit | 55 bits |
| 6 bits | 2 bits | 1 bit | 55 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> <t>The SCHC Compound ACK message <bcp14>MUST</bcp14> be used in case
SCHC Fragment losses are found in any window of the SCHC Packet (C=0).
<t>The SCHC Compound ACK message MUST be used in case SCHC fragment losses are f The SCHC Compound ACK message format is shown in <xref target="opt-1-schc-compou
ound in any window of the SCHC Packet (C=0). nd-ack-2B" format="default"/>.
The SCHC Compound ACK message format is shown in <xref target="opt-1-schc-compou The SCHC Compound ACK can report up to 4 windows with losses, as shown in <xref
nd-ack-2B"/>. target="opt-1-schc-compound-ack-2B-example-losses-all-windows" format="default"/
The SCHC Compound ACK can report up to 4 windows with losses. as shown in <xref >.</t>
target="opt-1-schc-compound-ack-2B-example-losses-all-windows"/>.</t> <t>When sent in the Downlink, the SCHC Compound ACK <bcp14>MUST</bcp
14> be 0 padded (padding bits must be 0) to complement the 64 bits required by t
<t>When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (Padding bi he Sigfox payload.</t>
ts must be 0) to complement the 64 bits required by the Sigfox payload.</t> <figure anchor="opt-1-schc-compound-ack-2B">
<name>SCHC Compound ACK Message Format</name>
<t><figure title="SCHC Compound ACK message format" anchor="opt-1-schc-compound- <artwork name="" type="" align="center" alt=""><![CDATA[
ack-2B"><artwork><![CDATA[
|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----| |--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
+--------+------+-------+--------+...+------+--------+------+-------+ +--------+------+-------+--------+...+------+--------+------+-------+
| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad| | 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| | 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|
]]></artwork>
</figure>
<t>Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;..
.&lt; wi.</t>
<figure anchor="opt-1-schc-compound-ack-2B-example-losses-all-window
s">
<name>SCHC Compound ACK Message Format Example with Losses in 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|...
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi ... |- W=2 -| |- W=3 -|
...+------+-------+------+-------+---+
]]></artwork></figure></t> ...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
...+------+-------+------+-------+---+
<t><figure title="SCHC Compound ACK message format example with losses in all wi ...|2 bits|12 bits|2 bits|12 bits|
ndows" anchor="opt-1-schc-compound-ack-2B-example-losses-all-windows"><artwork>< ]]></artwork>
![CDATA[ </figure>
|- SCHC ACK Header -|- W=0 -| |- W=1 -|... <t>Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</
+------+------+-----+-------+------+-------+... t>
|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |... </section>
+------+------+-----+-------+------+-------+... <section anchor="opt-1-snd-abort-msg-2B" numbered="true" toc="default"
|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|... >
<name>SCHC Sender-Abort Message Format</name>
... |- W=2 -| |- W=3 -| <figure anchor="opt-1-snd-abort-msg-format-2B">
...+------+-------+------+-------+---+ <name>SCHC Sender-Abort Message Format</name>
...|W=b'10|Bitmap |W=b'11|Bitmap |b'0| <artwork name="" type="" align="center" alt=""><![CDATA[
...+------+-------+------+-------+---+ |---- Sender-Abort Header ----|
...|2 bits|12 bits|2 bits|12 bits| +-----------------------------+
| RuleID | W | FCN=ALL-1 |
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi +--------+--------+-----------+
| 6 bits | 2 bits | 4 bits |
]]></artwork></figure></t> ]]></artwork>
</figure>
</section> </section>
<section anchor="opt-1-snd-abort-msg-2B" title="SCHC Sender-Abort Message Format <section anchor="opt-1-rcv-abort-msg-2B" numbered="true" toc="default"
"> >
<name>SCHC Receiver-Abort Message Format</name>
<t><figure title="SCHC Sender-Abort message format" anchor="opt-1-snd-abort-msg- <figure anchor="opt-1-rcv-abort-msg-format-2B">
format-2B"><artwork><![CDATA[ <name>SCHC Receiver-Abort Message Format</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
|---- Sender-Abort Header ----| |- Receiver-Abort Header -|
+-----------------------------+ +---------------------------------+-----------------+---------+
| RuleID | W | FCN=ALL-1 | | RuleID | W=b'11 | C=b'1 | 0x7F | 0xFF (all 1's) | b'0-pad |
+--------+--------+-----------+ +--------+--------+-------+-------+-----------------+---------+
| 6 bits | 2 bits | 4 bits | | 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>
<section anchor="opt-1-rcv-abort-msg-2B" title="SCHC Receiver-Abort Message Form <section anchor="UL-ACKoE-two-byte" numbered="true" toc="default">
at"> <name>Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2</name>
<section anchor="opt-2regular-2byte-schc-fragment" numbered="true" toc
<t><figure title="SCHC Receiver-Abort message format" anchor="opt-1-rcv-abort-ms ="default">
g-format-2B"><artwork><![CDATA[ <name>Regular SCHC Fragment</name>
<t><xref target="opt-2-reg-2byte-frag" format="default"/> shows an e
|- Receiver-Abort Header -| xample of a Regular SCHC Fragment for all fragments except the last one.
+---------------------------------+-----------------+---------+
| 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>
</section>
</section>
<section anchor="UL-ACKoE-two-byte" title="Uplink ACK-on-Error Mode: Two-byte SC
HC Header Option 2">
<section anchor="opt-2regular-2byte-schc-fragment" title="Regular SCHC Fragment"
>
<t><xref target="opt-2-reg-2byte-frag"/> shows an example of a regular SCHC frag
ment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t> The penultimate tile of a SCHC Packet is of the regular size.</t>
<figure anchor="opt-2-reg-2byte-frag">
<t><figure title="Regular SCHC Fragment format for all fragments except the last <name>Regular SCHC Fragment Format for All Fragments except the La
one" anchor="opt-2-reg-2byte-frag"><artwork><![CDATA[ st One</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
|-- SCHC Fragment Header --| |-- SCHC Fragment Header --|
+--------------------------+---------+ +--------------------------+---------+
| RuleID | W | FCN | Payload | | RuleID | W | FCN | Payload |
+--------+--------+--------+---------+ +--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits | | 8 bits | 3 bits | 5 bits | 80 bits |
]]></artwork>
]]></artwork></figure></t> </figure>
<t>The SCHC ACK REQ <bcp14>MUST NOT</bcp14> be used, instead the All
<t>The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment MUST be us -1 SCHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the rece
ed to request a SCHC ACK from the receiver (Network SCHC). iver (Network SCHC).
As per <xref target="RFC8724"/>, the All-0 message is distinguishable from the S As per <xref target="RFC8724" format="default"/>, the All-0 message is distingui
CHC ACK REQ (All-1 message).</t> shable from the SCHC ACK REQ (All-1 message).</t>
</section>
</section> <section anchor="opt-2-all-1-2B-schc-fragment" numbered="true" toc="de
fault">
<section anchor="opt-2-all-1-2B-schc-fragment" title="All-1 SCHC Fragment"> <name>All-1 SCHC Fragment</name>
<t><xref target="opt-2-all-1-2B" format="default"/> shows an example
<t><xref target="opt-2-all-1-2B"/> shows an example of the All-1 message. of the All-1 message.
The All-1 message MAY contain the last tile of the SCHC Packet.</t> The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</
<t>The All-1 message Fragment Header contains an RCS of 5 bits, and 3 padding bi t>
ts to complete a 3-byte Fragment Header. <t>The All-1 message Fragment Header contains an RCS of 5 bits and 3
padding bits to complete a 3-byte Fragment Header.
The size of the last tile, if present, ranges from 8 to 72 bits.</t> The size of the last tile, if present, ranges from 8 to 72 bits.</t>
<figure anchor="opt-2-all-1-2B">
<t><figure title="All-1 SCHC message format with last tile" anchor="opt-2-all-1- <name>All-1 SCHC Message Format with the Last Tile</name>
2B"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|-------------- SCHC Fragment Header -----------|
|-------------- SCHC Fragment Header -----------| +-----------------------------------------------+--------------+
+-----------------------------------------------+--------------+ | RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload |
| RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload | +--------+--------+-----------+--------+--------+--------------+
+--------+--------+-----------+--------+--------+--------------+ | 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits |
| 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> <t>As per <xref target="RFC8724" format="default"/>, the All-1 must
be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and
<t>As per <xref target="RFC8724"/> the All-1 must be distinguishable from the SC N values).
HC Sender-Abort message (with same RuleID, M and N values). The SCHC Sender-Abort message header size is 2 bytes with no padding bits.</t>
The SCHC Sender-Abort message header size is 2 byte, with no padding bits.</t> <t>For the All-1 message to be distinguishable from the Sender-Abort
message, the Sender-Abort message <bcp14>MUST</bcp14> be 2 bytes (only header w
<t>For the All-1 message to be distinguishable from the Sender-Abort message, th ith no padding).
e Sender-Abort message MUST be of 2 byte (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> This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.</t>
</section>
</section> <section anchor="opt-2-schc-ack-format-2B" numbered="true" toc="defaul
t">
<section anchor="opt-2-schc-ack-format-2B" title="SCHC ACK Format"> <name>SCHC ACK Format</name>
<t> <xref target="opt-2-success-ack-2B" format="default"/> shows the
<t> <xref target="opt-2-success-ack-2B"/> shows the SCHC ACK format when all fra SCHC ACK format when all fragments have been correctly received (C=1).
gments have been correctly received (C=1). Padding <bcp14>MUST</bcp14> be added to complete the 64-bit Sigfox Downlink fram
Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size. e payload size.</t>
</t> <figure anchor="opt-2-success-ack-2B">
<name>SCHC Success ACK Message Format</name>
<t><figure title="SCHC Success ACK message format" anchor="opt-2-success-ack-2B" <artwork name="" type="" align="center" alt=""><![CDATA[
><artwork><![CDATA[ |---- SCHC ACK Header ----|
+-------------------------+---------+
|---- SCHC ACK Header ----| | RuleID | W | C=b'1 | b'0-pad |
+-------------------------+---------+ +--------+--------+-------+---------+
| RuleID | W | C=b'1 | b'0-pad | | 8 bits | 3 bits | 1 bit | 52 bits |
+--------+--------+-------+---------+ ]]></artwork>
| 8 bits | 3 bits | 1 bit | 52 bits | </figure>
<t>The SCHC Compound ACK message <bcp14>MUST</bcp14> be used in case
]]></artwork></figure></t> SCHC Fragment losses are found in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in <xref target="opt-2-schc-compou
<t>The SCHC Compound ACK message MUST be used in case SCHC fragment losses are f nd-ack-2B" format="default"/>.
ound in any window of the SCHC Packet (C=0).
The SCHC Compound ACK message format is shown in <xref target="opt-2-schc-compou
nd-ack-2B"/>.
The SCHC Compound ACK can report up to 3 windows with losses.</t> The SCHC Compound ACK can report up to 3 windows with losses.</t>
<t>When sent in the Downlink, the SCHC Compound ACK <bcp14>MUST</bcp
<t>When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (Padding bi 14> be 0 padded (padding bits must be 0) to complement the 64 bits required by
ts must be 0) to complement the 64 bits required by
the Sigfox payload.</t> the Sigfox payload.</t>
<figure anchor="opt-2-schc-compound-ack-2B">
<t><figure title="SCHC Compound ACK message format" anchor="opt-2-schc-compound- <name>SCHC Compound ACK Message Format</name>
ack-2B"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----| |-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
+------+------+-------+--------+...+------+--------+------+-------+ +------+------+-------+--------+...+------+--------+------+-------+
|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000 |b'0-pad| |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| |8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
]]></artwork>
Losses are found in windows W = w1,...,wi; where w1<w2<...<wi </figure>
<t>Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;..
]]></artwork></figure></t> .&lt; wi.</t>
</section>
</section> <section anchor="snd-abort-msg-2B" numbered="true" toc="default">
<name>SCHC Sender-Abort Message Format</name>
<section anchor="snd-abort-msg-2B" title="SCHC Sender-Abort Message Format"> <figure anchor="snd-abort-msg-format-2B">
<name>SCHC Sender-Abort Message Format</name>
<t><figure title="SCHC Sender-Abort message format" anchor="snd-abort-msg-format <artwork name="" type="" align="center" alt=""><![CDATA[
-2B"><artwork><![CDATA[ |---- Sender-Abort Header ----|
+-----------------------------+
|---- Sender-Abort Header ----| | RuleID | W | FCN=ALL-1 |
+-----------------------------+ +--------+--------+-----------+
| RuleID | W | FCN=ALL-1 | | 8 bits | 3 bits | 5 bits |
+--------+--------+-----------+ ]]></artwork>
| 8 bits | 3 bits | 5 bits | </figure>
</section>
]]></artwork></figure></t> <section anchor="rcv-abort-msg-2B" numbered="true" toc="default">
<name>SCHC Receiver-Abort Message Format</name>
</section> <figure anchor="rcv-abort-msg-format-2B">
<name>SCHC Receiver-Abort Message Format</name>
<section anchor="rcv-abort-msg-2B" title="SCHC Receiver-Abort Message Format"> <artwork name="" type="" align="center" alt=""><![CDATA[
|-- Receiver-Abort Header -|
<t><figure title="SCHC Receiver-Abort message format" anchor="rcv-abort-msg-form +-----------------------------------+-----------------+---------+
at-2B"><artwork><![CDATA[ | RuleID | W=b'111 | C=b'1 | b'1111 | 0xFF (all 1's) | b'0-pad |
+--------+---------+-------+--------+-----------------+---------+
|-- Receiver-Abort Header -| | 8 bits | 3 bits | 1 bit | 4 bit | 8 bit | 40 bits |
+-----------------------------------+-----------------+---------+ next L2 Word boundary ->| <-- L2 Word --> |
| RuleID | W=b'111 | C=b'1 | b'1111 | 0xFF (all 1's) | b'0-pad | ]]></artwork>
+--------+---------+-------+--------+-----------------+---------+ </figure>
| 8 bits | 3 bits | 1 bit | 4 bit | 8 bit | 40 bits | </section>
next L2 Word boundary ->| <-- L2 Word --> | </section>
<section anchor="DL-ACK-Always" numbered="true" toc="default">
]]></artwork></figure></t> <name>Downlink ACK-Always Mode: Single-Byte SCHC Header</name>
<section anchor="DL-ACK-Always-1byte-schc-fragment" numbered="true" to
</section> c="default">
<name>Regular SCHC Fragment</name>
</section> <t><xref target="DL-ACK-Always-1byte-frag" format="default"/> shows
an example of a Regular SCHC Fragment for all fragments except the last one.
<section anchor="DL-ACK-Always" title="Downlink ACK-Always Mode: Single-byte SCH
C Header">
<section anchor="DL-ACK-Always-1byte-schc-fragment" title="Regular SCHC Frag
ment">
<t><xref target="DL-ACK-Always-1byte-frag"/> shows an example of a regular SCHC
fragment for all fragments except the last one.
The penultimate tile of a SCHC Packet is of the regular size.</t> The penultimate tile of a SCHC Packet is of the regular size.</t>
<figure anchor="DL-ACK-Always-1byte-frag">
<t><figure title="Regular SCHC Fragment format for all fragments except the last <name>Regular SCHC Fragment Format for All Fragments except the La
one" anchor="DL-ACK-Always-1byte-frag"><artwork><![CDATA[ st One</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
SCHC Fragment SCHC Fragment
|-- Header --| |-- Header --|
+-----------------+---------+ +-----------------+---------+
| RuleID | FCN | Payload | | RuleID | FCN | Payload |
+--------+--------+---------+ +--------+--------+---------+
| 3 bits | 5 bits | 56 bits | | 3 bits | 5 bits | 56 bits |
]]></artwork>
]]></artwork></figure></t> </figure>
<t>The SCHC ACK <bcp14>MUST NOT</bcp14> be used, instead the All-1 S
<t>The SCHC ACK MUST NOT be used, instead the All-1 SCHC Fragment MUST be used t CHC Fragment <bcp14>MUST</bcp14> be used to request a SCHC ACK from the receiver
o request a SCHC ACK from the receiver. .
As per <xref target="RFC8724"/>, the All-0 message is distinguishable from the S As per <xref target="RFC8724" format="default"/>, the All-0 message is distingui
CHC ACK REQ (All-1 message).</t> shable from the SCHC ACK REQ (All-1 message).</t>
</section>
</section> <section anchor="DL-ACK-Always-1B-all-1-schc-fragment" numbered="true"
toc="default">
<section anchor="DL-ACK-Always-1B-all-1-schc-fragment" title="All-1 SCHC Fra <name>All-1 SCHC Fragment</name>
gment"> <t><xref target="DL-ACK-Always-1B-all-1" format="default"/> shows an
example of the All-1 message.
<t><xref target="DL-ACK-Always-1B-all-1"/> shows an example of the All-1 message The All-1 message <bcp14>MAY</bcp14> contain the last tile of the SCHC Packet.</
. t>
The All-1 message MAY contain the last tile of the SCHC Packet.</t> <t>The All-1 message Fragment Header contains an RCS of 5 bits and 3
<t>The All-1 message Fragment Header contains an RCS of 5 bits, and 3 padding bi padding bits to complete a 2-byte Fragment Header.
ts to complete a 2-byte Fragment Header.
The size of the last tile, if present, ranges from 8 to 48 bits.</t> The size of the last tile, if present, ranges from 8 to 48 bits.</t>
<figure anchor="DL-ACK-Always-1B-all-1">
<t><figure title="All-1 SCHC message format with last tile" anchor="DL-ACK-Alway <name>All-1 SCHC Message Format with the Last Tile</name>
s-1B-all-1"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|--------- SCHC Fragment Header -------|
|--------- SCHC Fragment Header -------| +--------------------------------------+--------------+
+--------------------------------------+--------------+ | RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload | +--------+-----------+--------+--------+--------------+
+--------+-----------+--------+--------+--------------+ | 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits |
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits | ]]></artwork>
</figure>
]]></artwork></figure></t> <t>As per <xref target="RFC8724" format="default"/>, the All-1 must
be distinguishable from the SCHC Sender-Abort message (with same RuleID and N va
<t>As per <xref target="RFC8724"/> the All-1 must be distinguishable from the SC lues).
HC Sender-Abort message (with same RuleID and N values). The SCHC Sender-Abort message header size is 1 byte with no padding bits.</t>
The SCHC Sender-Abort message header size is 1 byte, with no padding bits.</t> <t>For the All-1 message to be distinguishable from the Sender-Abort
message, the Sender-Abort message <bcp14>MUST</bcp14> be 1 byte (only header wi
<t>For the All-1 message to be distinguishable from the Sender-Abort message, th th no padding).
e Sender-Abort message MUST 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> This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes.</t>
</section>
</section> <section anchor="DL-ACK-Always-1B-schc-ack-format" numbered="true" toc
="default">
<section anchor="DL-ACK-Always-1B-schc-ack-format" title="SCHC ACK Format"> <name>SCHC ACK Format</name>
<t> <xref target="DL-ACK-Always-1B-success-ack" format="default"/> s
<t> <xref target="DL-ACK-Always-1B-success-ack"/> shows the SCHC ACK format when hows the SCHC ACK format when all fragments have been correctly received (C=1).
all fragments have been correctly received (C=1). Padding <bcp14>MUST</bcp14> be added to complete 2 bytes.</t>
Padding MUST be added to complete 2 bytes.</t> <figure anchor="DL-ACK-Always-1B-success-ack">
<name>SCHC Success ACK Message Format</name>
<t><figure title="SCHC Success ACK message format" anchor="DL-ACK-Always-1B-succ <artwork name="" type="" align="center" alt=""><![CDATA[
ess-ack"><artwork><![CDATA[ SCHC ACK
|-- Header --|
SCHC ACK +----------------+---------+
|-- Header --| | RuleID | C=b'1 | b'0-pad |
+----------------+---------+ +--------+-------+---------+
| RuleID | C=b'1 | b'0-pad | | 3 bits | 1 bit | 4 bits |
+--------+-------+---------+ ]]></artwork>
| 3 bits | 1 bit | 4 bits | </figure>
<t>
]]></artwork></figure></t> The SCHC ACK message format is shown in <xref target="DL-ACK-Always-1B-schc-comp
ound-ack" format="default"/>.
<t>
The SCHC ACK message format is shown in <xref target="DL-ACK-Always-1B-schc-comp
ound-ack"/>.
</t> </t>
<figure anchor="DL-ACK-Always-1B-schc-compound-ack">
<t><figure title="SCHC Compound ACK message format" anchor="DL-ACK-Always-1B-sch <name>SCHC Compound ACK Message Format</name>
c-compound-ack"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
|---- SCHC ACK Header ----| |---- SCHC ACK Header ----|
+--------+-------+--------+---------+ +--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad | | RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+ +--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits| 5 bits | | 3 bits | 1 bit | 31 bits| 5 bits |
]]></artwork></figure></t> ]]></artwork>
<!-- End Section SCHC ACK Format--> </figure>
</section> </section>
<section anchor="DL-ACK-Always-1B-snd-abort-msg" numbered="true" toc="
<section anchor="DL-ACK-Always-1B-snd-abort-msg" title="SCHC Sender-Abort Me default">
ssage Format"> <name>SCHC Sender-Abort Message Format</name>
<figure anchor="DL-ACK-Always-1B-snd-abort-msg-format">
<t><figure title="SCHC Sender-Abort message format" anchor="DL-ACK-Always-1B-snd <name>SCHC Sender-Abort Message Format</name>
-abort-msg-format"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Sender-Abort
Sender-Abort |---- Header ----|
|---- Header ----| +--------------------+
+--------------------+ | RuleID | FCN=ALL-1 |
| RuleID | FCN=ALL-1 | +--------+-----------+
+--------+-----------+ | 3 bits | 5 bits |
| 3 bits | 5 bits | ]]></artwork>
</figure>
]]></artwork></figure></t>
<!-- End Section SCHC Sender-Abort Message Format-->
</section> </section>
<section anchor="DL-ACK-Always-1B-rcv-abort-msg" numbered="true" toc="
<section anchor="DL-ACK-Always-1B-rcv-abort-msg" title="SCHC Receiver-Abort Mess default">
age Format"> <name>SCHC Receiver-Abort Message Format</name>
<figure anchor="DL-ACK-Always-1B-rcv-abort-msg-format">
<t><figure title="SCHC Receiver-Abort message format" anchor="DL-ACK-Always-1B-r <name>SCHC Receiver-Abort Message Format</name>
cv-abort-msg-format"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Receiver-Abort
Receiver-Abort |--- Header ---|
|--- Header ---| +----------------+--------+-----------------+
+----------------+--------+-----------------+ | RuleID | C=b'1 | b'1111 | 0xFF (all 1's) |
| RuleID | C=b'1 | b'1111 | 0xFF (all 1's) | +--------+-------+--------+-----------------+
+--------+-------+--------+-----------------+ | 3 bits | 1 bit | 4 bit | 8 bit |
| 3 bits | 1 bit | 4 bit | 8 bit | ]]></artwork>
</figure>
]]></artwork></figure></t>
<!-- End Section SCHC Receiver-Abort Message Format-->
</section> </section>
<!-- End Section Downlink ACK-ALways Mode-->
</section> </section>
<!-- End of Section SCHC Fragment Message Formats-->
</section> </section>
<section anchor="padding" numbered="true" toc="default">
<!--<section anchor="schc_sender_abort" title="SCHC Sender-Abort">--> <name>Padding</name>
<t>The Sigfox payload fields have different characteristics in Uplink an
<!--<t><list style="symbols">--> d Downlink.</t>
<!--<t>As defined in <xref target="RFC8724"/>, a SCHC Sender-Abort can be trigge <t>Uplink messages can contain a payload size from 0 to 12 bytes. The Si
red when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK gfox radio protocol allows sending zero bits,
_REQUESTS. -->
<!--In the case of SCHC/Sigfox, a SCHC Sender-Abort MUST be sent if the number o
f 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 success
fully 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 triggere
d 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 sing
le device, all the RuleIDs are being processed by the receiver (i.e., have an ac
tive session) -->
<!--at a certain time and a new one is requested, or if the RuleID of the fragme
nt 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 SCH
C ACKs sent in a row (i.e., synchronized with the ACK REQ case, and with identic
al 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 S
CHC Receiver-Abort Downlink message MUST only be sent when there is a Downlink t
ransmission opportunity.</t>-->
<!--</list></t>-->
<!--</section>-->
<section anchor="padding" title="Padding">
<t>The Sigfox payload fields have different characteristics in Uplink and Downli
nk.</t>
<t>Uplink messages can contain a payload size from 0 to 12 bytes. The Sigfox rad
io protocol allows sending zero bits,
one single bit of information for binary applications (e.g., status), or an inte ger number of bytes. one single bit of information for binary applications (e.g., status), or an inte ger number of bytes.
Therefore, for 2 or more bits of payload it is required to add padding to the ne xt integer number of bytes. The reason for this Therefore, for 2 or more bits of payload, it is required to add padding to the n ext integer number of bytes. The reason for this
flexibility is to optimize transmission time and hence save battery consumption at the device.</t> flexibility is to optimize transmission time and hence save battery consumption at the device.</t>
<t>On the other hand, Downlink frames have a fixed length. The payload l
<t>Downlink frames on the other hand have a fixed length. The payload length MUS ength <bcp14>MUST</bcp14> be 64 bits (i.e., 8 bytes). Hence, if less
T be 64 bits (i.e., 8 bytes). Hence, if less information bits are to be transmitted, padding <bcp14>MUST</bcp14> be used with
information bits are to be transmitted, padding MUST be used with bits equal to bits equal to 0.
0. The receiver <bcp14>MUST</bcp14> remove the added padding bits before the SC
The receiver MUST remove the added padding bits before the SCHC reassembly p HC reassembly process.</t>
rocess.</t> </section>
</section>
</section> <section anchor="fragmentation-rules-examples" numbered="true" toc="default"
>
</section> <name>Fragmentation Rules Examples</name>
<t>This section provides an example of RuleID configuration for interopera
<section anchor="fragmentation-rules-examples" title="Fragmentation Rules Exampl bility between the F/R modes presented in this document.
es"> Note that the RuleID space for Uplink F/R is different than the one for Down
link F/R; therefore, this section is divided in two subsections: Rules for Uplin
<t>This section provides an example of RuleIDs configuration for interoperabilit k fragmentation and Rules for Downlink fragmentation.
y between the F/R modes presented in this document.
Note that the RuleID space for Uplink F/R is different than the one for Down
link F/R, therefore this section is divided in two subsections: Rules for Uplink
fragmentation and Rules for Downlink fragmentation.
</t> </t>
<t>For Uplink F/R, multiple header length were described in <xref target="Frag"/ <t>For Uplink F/R, multiple header lengths were described in <xref target=
>. "Frag" format="default"/>.
All of them are part of the SCHC over Sigfox Profile, and offer not only low All of them are part of the SCHC over Sigfox Profile and offer not only low
protocol overhead for small payloads (single byte header) but also extensibilit protocol overhead for small payloads (single byte header) but also extensibility
y to transport larger payloads with more overhead (2 bytes header, option 1 and to transport larger payloads with more overhead (2-byte header, Options 1 and 2
2). ).
The usage of the RuleID space for each header length is an implementation ch oice, but we provide an example of it in the following section. The usage of the RuleID space for each header length is an implementation ch oice, but we provide an example of it in the following section.
This illustrates implementation choices made in order to 1) identify the dif ferent header length, and 2) finally parse the RuleID field to identify the Rule ID value and execute the associated treatment. This illustrates implementation choices made in order to 1) identify the dif ferent header length and 2) finally parse the RuleID field to identify the RuleI D value and execute the associated treatment.
</t> </t>
<section anchor="uplink-fragmentation-rules-examples" numbered="true" toc=
<section anchor="uplink-fragmentation-rules-examples" title="Uplink Fragmentatio "default">
n Rules Examples"> <name>Uplink Fragmentation Rules Examples</name>
<t> <t>
The RuleID field for Uplink F/R modes have different sizes depending on th The RuleID field for Uplink F/R modes has different sizes depending on the
e header length. header length.
In order to identify the header length and then the value of the RuleID, the Rul eID field In order to identify the header length and then the value of the RuleID, the Rul eID field
is interpreted as follows: is interpreted as follows:
</t>
<t><list style="symbols">
<t>The RuleID field is the first one to be parsed in the SCHC header, start
ing from the leftmost bits.</t>
<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 the first 3 leftmost bits have a value different than 0b'111, the
n it signals a Single-byte SCHC Header F/R mode,
</t> </t>
<t> <ul spacing="normal">
if their value is 0b'111, then it signals a Two-byte SCHC Head <li>The RuleID field is the first one to be parsed in the SCHC header,
er F/R mode. starting from the leftmost bits.</li>
</t> <li><t>For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits
</list></t> is expected:</t>
</list></t> <ul spacing="normal">
<li>If the first 3 leftmost bits have a value different than 0b'11
<t><list style="symbols"> 1, then it signals a Single-byte SCHC Header F/R mode.</li>
<t>For Single-byte SCHC Header F/R modes:</t> <li>If their value is 0b'111, then it signals a Two-byte SCHC Head
<t><list style="symbols"> er F/R mode.
<t>there are 7 RuleIDs available (with values from 0b'000-0b'110), the </li>
RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.</t> </ul>
<t>This set of rules is called “standard rules”, and it is used to </li>
implement Single-byte SCHC header modes.</t> <li><t>For Single-byte SCHC Header F/R modes:</t>
<t>Each RuleID is associated with a set of properties defining if U <ul spacing="normal">
plink F/R is used and which Uplink F/R mode is used. As an example, the RuleID 0 <li>There are 7 RuleIDs available (with values from 0b'000-0b'110)
b'000 is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and the RuleID ; the RuleID with value 0b'111 is reserved to indicate a Two-byte SCHC Header.</
s 0b'001 and 0b'002 are mapped onto Uplink ACK-on-Error Mode: Single-byte SCHC H li>
eader (2 RuleIDs to allow for SCHC Packet interleaving).</t> <li>This set of Rules is called "standard rules", and it is used t
</list></t> o implement Single-byte SCHC Header modes.</li>
<t>For Two-byte SCHC Header F/R modes at least 6 bits for the RuleID fie <li>Each RuleID is associated with a set of properties defining if
ld are expected:</t> Uplink F/R is used and which Uplink F/R mode is used. As an example, the RuleID
<t><list style="symbols"> 0b'000 is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and the Rule
<t>the 3 first leftmost bits are always 0b'111,</t> IDs 0b'001 and 0b'002 are mapped onto Uplink ACK-on-Error mode: Single-byte SCHC
<t><list style="symbols"> Header (2 RuleIDs to allow for SCHC Packet interleaving).</li>
<t>if the following 3 bits have a different value than 0b'1 </ul>
11, then it signals the Two-byte SCHC Header Option 1, </t> </li>
<t>if the following 3 bits are 0b'111, then it signals the <li><t>For Two-byte SCHC Header F/R modes, at least 6 bits for the Rul
Two-byte SCHC Header Option 2.</t> eID field are expected:</t>
</list></t> <ul spacing="normal">
<t>For the Two-byte SCHC Header Option 1, there are 7 RuleIDs available (0b <li><t>The 3 first leftmost bits are always 0b'111.</t>
'111000-0b'111110), 0b'111111 being reserved to indicate the Two-byte SCHC Heade <ul spacing="normal">
r Option 2. This set of rules is called “extended rules”, and it is used to impl <li>If the following 3 bits have a different value than 0b'111
ement the Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1.</t> , then it signals the Two-byte SCHC Header Option 1.</li>
<t>For the Two-byte SCHC Header Option 2, there are 2 additional bits to pa <li>If the following 3 bits are 0b'111, then it signals the Tw
rse as the RuleID, so 4 RuleIDs available (0b'11111100-0b'11111111). This set of o-byte SCHC Header Option 2.</li>
rules is used to cover specific cases that previous RuleIDs do not cover. As an </ul>
example, RuleID 0b’00111111 is used to transport uncompressed IPv6 packets usin </li>
g the Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2.</t> <li>For the Two-byte SCHC Header Option 1, there are 7 RuleIDs ava
</list></t> ilable (0b'111000-0b'111110), 0b'111111 being reserved to indicate the Two-byte
</list></t> SCHC Header Option 2. This set of Rules is called "extended rules", and it is us
ed to implement the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1.</li
</section> >
<li>For the Two-byte SCHC Header Option 2, there are 2 additional
<section anchor="downlink-fragmentation-rules-examples" title="Downlink Frag bits to parse as the RuleID, so 4 RuleIDs are available (0b'11111100-0b'11111111
mentation Rules Example"> ). This set of Rules is used to cover specific cases that previous RuleIDs do no
<t><list style="symbols"> t cover. As an example, RuleID 0b'00111111 is used to transport uncompressed IPv
<t>For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get va 6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 2.</li
lues in ranges from 0b'000 to 0b'111.</t> >
</ul>
</list></t> </li>
</section> </ul>
</section>
</section> <section anchor="downlink-fragmentation-rules-examples" numbered="true" to
c="default">
<section anchor="sequence-examples" title="Fragmentation Sequence Examples"> <name>Downlink Fragmentation Rules Example</name>
<t>For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs ca
<t>In this section, some sequence diagrams depicting messages exchanges for diff n get values in ranges from 0b'000 to 0b'111.</t>
erent fragmentation modes and use cases are shown. </section>
</section>
<section anchor="sequence-examples" numbered="true" toc="default">
<name>Fragmentation Sequence Examples</name>
<t>In this section, some sequence diagrams depict message exchanges for di
fferent fragmentation modes and use cases are shown.
In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carryin g a fragment.</t> In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carryin g a fragment.</t>
<section anchor="no-ack-examples" numbered="true" toc="default">
<section anchor="no-ack-examples" title="Uplink No-ACK Examples"> <name>Uplink No-ACK Examples</name>
<t>The FCN field indicates the size of the data packet.
<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. 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. All fragments are marked with decreasing FCN values.
Last packet fragment is marked with the FCN = All-1 (1111). </t> The last packet fragment is marked with FCN = All-1 (1111). </t>
<t><strong>Case No Losses - All fragments are sent and received successf
<t>Case No losses - All fragments are sent and received successfully.</t> ully.</strong></t>
<figure anchor="UL-No-ACK-NL">
<figure title="Uplink No-ACK No-Losses" anchor="UL-No-ACK-NL"><artwork><![CDATA[ <name>Uplink No-ACK No-Losses</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-------FCN=6,Seq=1-------->| |-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2-------->| |-------FCN=5,Seq=2-------->|
|-------FCN=4,Seq=3-------->| |-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->| |-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->| |-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->| |-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| All fragments received |-------FCN=15,Seq=7------->| All fragments received
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t>When the first SCHC Fragment is received, the receiver can calculate
<t>When the first SCHC fragment is received, the Receiver can calculate the the
total number of SCHC fragments that the SCHC Packet is composed of. total number of SCHC Fragments that the SCHC Packet is composed of.
For example, if the first fragment is numbered with FCN=6, the receiver can For example, if the first fragment is numbered with FCN=6, the receiver can
expect six more messages/fragments (i.e., with FCN going from 5 downwards, and t he last fragment with an expect six more messages/fragments (i.e., with FCN going from 5 downwards and th e last fragment with an
FCN equal to 15).</t> FCN equal to 15).</t>
<t><strong>Case Losses on Any Fragment except the First</strong></t>
<t>Case losses on any fragment except the first.</t> <figure anchor="UL-No-ACK-L-1">
<name>Uplink No-ACK Losses (Scenario 1)</name>
<figure title="Uplink No-ACK Losses (scenario 1)" anchor="UL-No-ACK-L-1"><artwor <artwork name="" type="" align="center" alt=""><![CDATA[
k><![CDATA[
Sender Receiver Sender Receiver
|-------FCN=6,Seq=1-------->| |-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2----X | |-------FCN=5,Seq=2----X |
|-------FCN=4,Seq=3-------->| |-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->| |-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->| |-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->| |-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble |-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
(End) (End)
]]></artwork>
</figure>
</section>
<section anchor="ack-on-error-examples-1B-header" numbered="true" toc="def
ault">
<name>Uplink ACK-on-Error Examples: Single-Byte SCHC Header</name>
<t>The Single-byte SCHC Header ACK-on-Error mode allows sending up to 28
fragments and packet sizes up to
300 bytes. The SCHC Fragments may be delivered asynchronously, and Downlink ACK
can be sent opportunistically. </t>
<t><strong>Case No Losses</strong></t>
<t>The Downlink flag must be enabled in the sender Uplink message to all
ow a Downlink message from the receiver.
The Downlink Enable in the figures shows where the sender <bcp14>MUST</bcp14> en
able the Downlink and
wait for an ACK.</t>
]]></artwork></figure> <figure anchor="UL-ACKoE-NL">
<name>Uplink ACK-on-Error No-Losses</name>
</section> <artwork name="" type="" align="center" alt=""><![CDATA[
<section anchor="ack-on-error-examples-1B-header" title="Uplink ACK-on-Error Exa
mples: Single-byte SCHC Header">
<t>The single-byte SCHC header ACK-on-Error mode allows sending up to 28 fragmen
ts and packet sizes up to
300 bytes. The SCHC fragments may be delivered asynchronously and Downlink ACK c
an be sent opportunistically. </t>
<t>Case No losses</t>
<t>The Downlink flag must be enabled in the sender Uplink message to allow a Dow
nlink message from the receiver.
The Downlink Enable in the figures shows where the sender MUST enable the Downli
nk, and
wait for an ACK.</t>
<figure title="Uplink ACK-on-Error No-Losses" anchor="UL-ACKoE-NL"><artwork><![C
DATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->| |-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->| DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK) (no ACK)
|-----W=1,FCN=6,Seq=8----->| |-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| |-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->| |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
|<- Compound ACK,W=1,C=1 --| C=1 |<- Compound ACK,W=1,C=1 --| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t><strong>Case Fragment Losses in the First Window</strong></t>
<t>Case Fragment losses in first window</t> <t>In this case, fragments are lost in the first window (W=0).
After the first All-0 message arrives, the receiver
<t>In this case, fragments are lost in the first window (W=0).
After the first All-0 message arrives, the Receiver
leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.</t> 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
<t>After the loss fragments from the first window (W=0) are resent, the sender c sender continues
ontinues
transmitting the fragments of the following window (W=1) without opening a recep tion opportunity. transmitting the fragments of the following window (W=1) without opening a recep tion opportunity.
Finally, the All-1 fragment is sent, the Downlink is enabled, and the SCHC ACK i s received with C=1. Finally, the All-1 fragment is sent, the Downlink is enabled, and the SCHC ACK i s received with C=1.
Note that the SCHC Compound ACK also uses a Sequence Number. </t> Note that the SCHC Compound ACK also uses a Sequence Number. </t>
<figure anchor="UL-ACKoE-LW1">
<figure title="Uplink ACK-on-Error Losses on First Window" anchor="UL-ACKoE-LW1" <name>Uplink ACK-on-Error Losses in the First Window</name>
><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X | |-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5--X | __ |-----W=0,FCN=2,Seq=5--X | __
|-----W=0,FCN=1,Seq=6----->| | W=0 |-----W=0,FCN=1,Seq=6----->| | W=0
DL Enable |-----W=0,FCN=0,Seq=7----->| Missing Fragments<- FCN=5,Seq=2 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 |<- Compound ACK,W=0,C=0 --| Bitmap:1011011 | FCN=2,Seq=5
|-----W=0,FCN=5,Seq=9----->| -- |-----W=0,FCN=5,Seq=9----->| --
|-----W=0,FCN=2,Seq=10---->| |-----W=0,FCN=2,Seq=10---->|
|-----W=1,FCN=6,Seq=11---->| |-----W=1,FCN=6,Seq=11---->|
|-----W=1,FCN=5,Seq=12---->| |-----W=1,FCN=5,Seq=12---->|
|-----W=1,FCN=4,Seq=13---->| |-----W=1,FCN=4,Seq=13---->|
DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
|<-Compound ACK,W=1,C=1 ---| C=1 |<-Compound ACK,W=1,C=1 ---| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t><strong>Case Fragment All-0 Lost in the First Window (W=0)</strong></
<t>Case Fragment All-0 lost in first window (W=0)</t> t>
<t>In this example, the All-0 of the first window (W=0) is lost. Therefo
<t>In this example, the All-0 of the first window (W=0) is lost. Therefore, re,
the Receiver waits for the next All-0 message of intermediate windows, or All-1 the receiver waits for the next All-0 message of intermediate windows or All-1 m
message of last window to generate essage of last window to generate
the corresponding SCHC ACK, notifying the absence of the All-0 of window 0.</t> the corresponding SCHC ACK, which indicates that the All-0 of window 0 is absent
.</t>
<t>The sender resends the missing All-0 messages (with any other missing <t>The sender resends the missing All-0 messages (with any other missing
fragment from window 0) without opening a reception opportunity.</t> fragment from window 0) without opening a reception opportunity.</t>
<figure anchor="UL-ACKoE-LA0W1">
<figure title="Uplink ACK-on-Error All-0 Lost on First Window" anchor="UL-ACKoE- <name>Uplink ACK-on-Error All-0 Lost in the First Window</name>
LA0W1"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->| |-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| DL Enable |-----W=0,FCN=1,Seq=6----->| DL Enable
|-----W=0,FCN=0,Seq=7--X | |-----W=0,FCN=0,Seq=7--X |
(no ACK) (no ACK)
|-----W=1,FCN=6,Seq=8----->| |-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __ |-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0 |-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7 DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
|<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__ |<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__
|-----W=0,FCN=0,Seq=13---->| All fragments received |-----W=0,FCN=0,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->| DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK,W=1,C=1 ---| C=1 |<-Compound ACK,W=1,C=1 ---| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t>In the following diagram, besides the All-0, there are other fragment
<t>In the following diagram, besides the All-0 there are other fragment losses i losses in the first window (W=0).</t>
n the first window (W=0).</t> <figure anchor="UL-ACKoE-LA0FW1">
<name>Uplink ACK-on-Error All-0 and Other Fragments Lost in the First
<figure title="Uplink ACK-on-Error All-0 and other Fragments Lost on First Windo Window</name>
w" anchor="UL-ACKoE-LA0FW1"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X | |-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | |-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7--X | DL Enable |-----W=0,FCN=0,Seq=7--X |
(no ACK) (no ACK)
|-----W=1,FCN=6,Seq=8----->| |-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __ |-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0 |-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2 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 |<--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=5,Seq=13---->| |FCN=0,Seq=7
|-----W=0,FCN=3,Seq=14---->| -- |-----W=0,FCN=3,Seq=14---->| --
|-----W=0,FCN=0,Seq=15---->| All fragments received |-----W=0,FCN=0,Seq=15---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16---->| DL Enable |-----W=1,FCN=7,Seq=16---->|
|<-Compound ACK,W=1,C=1 ---| C=1 |<-Compound ACK,W=1,C=1 ---| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t>In the next examples, there are fragment losses in both the first (W=
<t>In the next examples, there are fragment losses in both the first (W=0) and s 0) and second (W=1) windows.
econd (W=1) windows. The retransmission cycles after the All-1 is sent (i.e., not in intermediate win
The retransmission cycles after the All-1 is sent (i.e., not in intermediate win dows) <bcp14>MUST</bcp14>
dows) MUST
always finish with an All-1, as it serves as an ACK Request message to confirm t he correct reception always finish with an All-1, as it serves as an ACK Request message to confirm t he correct reception
of the retransmitted fragments. </t> of the retransmitted fragments. </t>
<figure anchor="UL-ACKoE-LFW12-1">
<figure title="Uplink ACK-on-Error All-0 and other Fragments Lost on First and S <name>Uplink ACK-on-Error All-0 and Other Fragments Lost in the First
econd Windows (1)" anchor="UL-ACKoE-LFW12-1"><artwork><![CDATA[ and Second Windows (1)</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X | |-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | __ |-----W=0,FCN=3,Seq=4--X | __
|-----W=0,FCN=2,Seq=5----->| |W=0 |-----W=0,FCN=2,Seq=5----->| |W=0
|-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2 |-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2
DL enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4 DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4
(no ACK) |FCN=0,Seq=7 (no ACK) |FCN=0,Seq=7
|-----W=1,FCN=6,Seq=8--X | |W=1 |-----W=1,FCN=6,Seq=8--X | |W=1
|-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8 |-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8
|-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10 |-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10
DL enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__ DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
|<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110 |<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
|-----W=0,FCN=5,Seq=13---->| W=1:0100001 |-----W=0,FCN=5,Seq=13---->| W=1:0100001
|-----W=0,FCN=3,Seq=14---->| |-----W=0,FCN=3,Seq=14---->|
|-----W=0,FCN=0,Seq=15---->| |-----W=0,FCN=0,Seq=15---->|
|-----W=1,FCN=6,Seq=16---->| |-----W=1,FCN=6,Seq=16---->|
|-----W=1,FCN=4,Seq=17---->| All fragments received |-----W=1,FCN=4,Seq=17---->| All fragments received
DL enable |-----W=1,FCN=7,Seq=18---->| DL Enable |-----W=1,FCN=7,Seq=18---->|
|<-Compound ACK,W=1,C=1----| C=1 |<-Compound ACK,W=1,C=1----| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t>The figure below is a similar case as above but with fewer fragments
<t>Similar case as above, but with fewer fragments in the second window (W=1)</t in the second window (W=1).</t>
> <figure anchor="UL-ACKoE-LFW12-2">
<name>Uplink ACK-on-Error All-0 and Other Fragments Lost in the First
<figure title="Uplink ACK-on-Error All-0 and other Fragments Lost on First and S and Second Windows (2)</name>
econd Windows (2)" anchor="UL-ACKoE-LFW12-2"><artwork><![CDATA[ <artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X | |-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | |-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->| __ |-----W=0,FCN=2,Seq=5----->| __
|-----W=0,FCN=1,Seq=6----->| |W=0 |-----W=0,FCN=1,Seq=6----->| |W=0
DL enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2 DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2
(no ACK) |FCN=3,Seq=4 (no ACK) |FCN=3,Seq=4
|-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7 |-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7
DL enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1 DL 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 |<-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=5,Seq=11---->| W=1:0000001 |__
|-----W=0,FCN=3,Seq=12---->| |-----W=0,FCN=3,Seq=12---->|
|-----W=0,FCN=0,Seq=13---->| |-----W=0,FCN=0,Seq=13---->|
|-----W=1,FCN=6,Seq=14---->| All fragments received |-----W=1,FCN=6,Seq=14---->| All fragments received
DL enable |-----W=1,FCN=7,Seq=15---->| DL Enable |-----W=1,FCN=7,Seq=15---->|
|<-Compound ACK, W=1,C=1---| C=1 |<-Compound ACK, W=1,C=1---| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t><strong>Case SCHC ACK is Lost</strong></t>
<t>Case SCHC ACK is lost</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 when required.</t>
<t>SCHC over Sigfox does not implement the SCHC ACK REQ message. Instead, it use <figure anchor="UL-ACKoE-ACKL">
s the SCHC All-1 message to request a SCHC ACK, when required.</t> <name>Uplink ACK-on-Error ACK Lost</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
<figure title="Uplink ACK-on-Error ACK Lost" anchor="UL-ACKoE-ACKL"><artwork><![
CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->| |-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->| DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK) (no ACK)
|-----W=1,FCN=6,Seq=8----->| |-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| |-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->| |-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
| X--Compound ACK,W=1,C=1 -| C=1 | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
|<-Compound ACK,W=1,C=1 ---| C=1 |<-Compound ACK,W=1,C=1 ---| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t><strong>Case SCHC Compound ACK at the End</strong></t>
<t>Case SCHC Compound ACK at the end</t> <t>In this example, SCHC Fragment losses are found in both windows 0 and
1. However, the sender does not send a
<t>In this example, SCHC Fragment losses are found in both window 0 and 1. Howev SCHC Compound ACK after the All-0 of window 0. Instead, it sends a SCHC Compound
er, the sender does not send a ACK indicating fragment losses on both windows.
SCHC ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK noti
fying losses of both
windows.
</t> </t>
<figure anchor="UL-ACKoE-LFW12-3">
<figure title="Uplink ACK-on-Error Fragments Lost on First and Second Windows wi <name>Uplink ACK-on-Error Fragments Lost in the First and Second Windo
th one Compound ACK" anchor="UL-ACKoE-LFW12-3"><artwork><![CDATA[ ws with One Compound ACK</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X | |-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | |-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| __ |-----W=0,FCN=1,Seq=6----->| __
DL enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0 DL Enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0
(no ACK) next DL opportunity |FCN=5,Seq=2 (no ACK) next DL opportunity |FCN=5,Seq=2
|-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4 |-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4
DL enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1 DL 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 |<-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=5,Seq=11---->| W=1:0000001 --
|-----W=0,FCN=3,Seq=12---->| |-----W=0,FCN=3,Seq=12---->|
|-----W=1,FCN=6,Seq=13---->| All fragments received |-----W=1,FCN=6,Seq=13---->| All fragments received
DL enable |-----W=1,FCN=7,Seq=14---->| DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK, W=1, C=1 -| C=1 |<-Compound ACK, W=1, C=1 -| C=1
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t>The number of times the same SCHC ACK message will be retransmitted i
<t>The number of times the same SCHC ACK message will be retransmitted is determ s determined by the
ined by the
MAX_ACK_REQUESTS.</t> MAX_ACK_REQUESTS.</t>
</section>
</section> <section anchor="abort-examples" numbered="true" toc="default">
<name>SCHC Abort Examples</name>
<section anchor="abort-examples" title="SCHC Abort Examples"> <t><strong>Case SCHC Sender-Abort</strong></t>
<t>The sender may need to send a Sender-Abort to stop the current commun
<t>Case SCHC Sender-Abort</t> ication. For example, this may happen if the All-1 has been sent MAX_ACK_REQUEST
S times.</t>
<t>The sender may need to send a Sender-Abort to stop the current communication. <figure anchor="UL-ACKoE-SndAbt">
This may happen, for example, if the All-1 has been sent MAX_ACK_REQUESTS times. <name>Uplink ACK-on-Error Sender-Abort</name>
</t> <artwork name="" type="" align="center" alt=""><![CDATA[
Sender Receiver
<figure title="Uplink ACK-on-Error Sender-Abort" anchor="UL-ACKoE-SndAbt"><artwo
rk><![CDATA[
Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->| |-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->| DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK) (no ACK)
|-----W=1,FCN=6,Seq=8----->| |-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| |-----W=1,FCN=5,Seq=9----->|
skipping to change at line 1663 skipping to change at line 1341
DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2) DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2)
| X--Compound ACK,W=1,C=1 -| C=1 | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3) DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3)
| X--Compound ACK,W=1,C=1 -| C=1 | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4) DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4)
| X--Compound ACK,W=1,C=1 -| C=1 | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5) DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5)
| X--Compound ACK,W=1,C=1 -| C=1 | X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20-->| exit with error condition DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
(End) (End)
]]></artwork>
]]></artwork></figure> </figure>
<t><strong>Case Receiver-Abort</strong></t>
<t>Case Receiver-Abort</t> <t>The receiver may need to send a Receiver-Abort to stop the current co
mmunication.
<t>The receiver may need to send a Receiver-Abort to stop the current communicat This message can only be sent after a Downlink Enable.</t>
ion. <figure anchor="UL-ACKoE-RcvAbt">
This message can only be sent after a Downlink enable.</t> <name>Uplink ACK-on-Error Receiver-Abort</name>
<artwork name="" type="" align="center" alt=""><![CDATA[
<figure title="Uplink ACK-on-Error Receiver-Abort" anchor="UL-ACKoE-RcvAbt"><art Sender Receiver
work><![CDATA[
Sender Receiver
|-----W=0,FCN=6,Seq=1----->| |-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->| |-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->| |-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->| |-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->| |-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| |-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->| DL Enable |-----W=0,FCN=0,Seq=7----->|
|<------ RECV ABORT ------| under-resourced |<------ RECV ABORT ------| under-resourced
(Error) (Error)
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>The radio protocol authenticates and ensures the integrity of each mess
<section anchor="security-considerations" title="Security considerations"> age.
This is achieved by using a unique Device ID and an AES-128-based message au
<t>The radio protocol authenticates and ensures the integrity of each message. thentication code,
This is achieved by using a unique device ID and an AES-128 based message au ensuring that the message has been generated and sent by the device (see <xref t
thentication code, arget="sigfox-spec" format="default"/>, Section 3.8) or Network (see <xref targ
ensuring that the message has been generated and sent by the device (see <xref t et="sigfox-spec" format="default"/>, Section 4.3) with the ID claimed in the mes
arget="sigfox-spec"/> Section 3.8) or network (see <xref target="sigfox-spec"/> sage <xref target="sigfox-spec" format="default"/>.</t>
Section 4.3) with the ID claimed in the message <xref target="sigfox-spec"/>.</ <t>Application data may or may not be encrypted at the application layer
t> , depending on the criticality of the use case.
This flexibility allows a balance between cost and effort versus risk.
<t>Application data can be encrypted at the application layer or not, depending AES-128 in counter mode is used for encryption. Cryptographic keys are independ
on the criticality of the use case. ent for each device. These keys are associated with the Device ID, and separate
This flexibility allows providing a balance between cost and effort vs. risk. integrity and
AES-128 in counter mode is used for encryption. Cryptographic keys are independ
ent for each device. These keys are associated with the device ID and separate i
ntegrity and
encryption keys are pre-provisioned. encryption keys are pre-provisioned.
An encryption key is only provisioned if confidentiality is to be used (see An encryption key is only provisioned if confidentiality is to be used (see
<xref target="sigfox-spec"/> Section 5.3. Note that further documentation is ava <xref target="sigfox-spec" format="default"/>, Section 5.3; note that further do
ilable at Sigfox upon request).</t> cumentation is available at Sigfox upon request).</t>
<t>The radio protocol has protections against replay attacks, and the clou
<t>The radio protocol has protections against replay attacks, and the cloud-base d-based core Network provides firewall protection against undesired incoming com
d core network provides firewalling protection against undesired incoming commun munications <xref target="sigfox-spec" format="default"/>.</t>
ications <xref target="sigfox-spec"/>.</t> <t>The previously described security mechanisms do not guarantee end-to-en
d security between the device SCHC C/D + F/R and the Network SCHC C/D + F/R; pot
<t>The previously described security mechanisms do not guarantee an E2E security ential security threats described in <xref target="RFC8724" format="default"/> a
between the Device SCHC C/D + F/R and the Network SCHC C/D + F/R: potential sec re applicable to the profile specified in this document.</t>
urity threats described in <xref target="RFC8724"/> are applicable to the profil <t>In some circumstances, sending device location information is
e specified in this document.</t> privacy sensitive. The Device Geolocation parameter provided by the
<t>In some circumstances, sending device location information is
privacy-sensitive. The Device Geolocation parameter provided by the
Network Network
is optional, therefore it can be omitted to protect this aspect of is optional; therefore, it can be omitted to protect this aspect of
the device privacy.</t> 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>
<section anchor="security-considerations-for-fragmentation" title="Security cons <section anchor="ianaconsiderations" numbered="true" toc="default">
iderations for fragmentation"> <name>IANA Considerations</name>
<t>This subsection describes potential attacks to LPWAN fragmentation <t>This document has no IANA actions.</t>
and suggests possible countermeasures.</t> </section>
<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 t
o resend a fragment a number of times, with the aim to increase consumption of t
he fragment sender’s resources. To this end, the malicious node may repeatedly s
end a fake ACK to the fragment sender, with a bitmap that reports that one or mo
re 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_FR
AG_RETRIES benefits fragment delivery reliability, therefore the trade-off needs
to be carefully considered.</t>
</section>
</section>
<section anchor="ianaconsiderations" title="IANA Considerations">
<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 Re
gular 1201893 and Basal Project FB0008.</t>
<t>Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201
893.</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 i
mplementation design considerations.</t>
</section>
</middle> </middle>
<back> <back>
<!-- <displayreference target="I-D.ietf-core-comi" to="CORE-COMI"/>
<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'><organizatio
n /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'><organizat
ion /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'><organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'><organization /></au
thor>
<date year='2007' month='September' />
<abstract><t>This document describes the frame format for transmission of IPv6 p
ackets and the method of forming IPv6 link-local addresses and statelessly autoc
onfigured addresses on IEEE 802.15.4 networks. Additional specifications include
a simple header compression scheme using shared context and provisions for pack
et 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 /></au
thor>
<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 /></auth
or>
<date year='2014' month='February' />
<abstract><t>The IPv6 addressing architecture includes a unicast interface ident
ifier 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 a
n 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 t
he Universal and Group bits of an IEEE link-layer address are mapped into an IPv
6 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 oper
ate efficiently and robustly over various link technologies with different chara
cteristics.</t><t>The ROHC framework, along with a set of compression profiles,
was initially defined in RFC 3095. To improve and simplify the ROHC specificati
ons, this document explicitly defines the ROHC framework and the profile for unc
ompressed separately. More specifically, the definition of the framework does n
ot modify or update the definition of the framework specified by RFC 3095.</t><t
>This specification obsoletes RFC 4995. It fixes one interoperability issue tha
t 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'?> <references>
<?rfc include='reference.RFC.8174'?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.87
24.xml"/>
<!-- <reference anchor='RFC9441' target='https://www.rfc-editor.org/info/rfc9441'>
<reference anchor="I-D.ietf-lpwan-overview">
<front> <front>
<title>LPWAN Overview</title> <title>Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)</
title>
<author initials='S Ed' surname='Farrell' fullname='Stephen Farrell'> <author initials="JC." surname="Zúñiga" fullname="Juan-Carlos Zúñiga">
<organization /> <organization>Cisco</organization>
</author> </author>
<author initials="C." surname="Gomez" fullname="Carles Gomez">
<date month='May' year='2018' /> <organization>Universitat Politecnica de Catalunya</organization>
<abstract><t>Low Power Wide Area Networks (LPWAN) are wireless technologies with
characteristics such as large coverage areas, low bandwidth, possibly very smal
l packet and application layer data sizes and long battery life operation. This
memo is an informational overview of the set of LPWAN technologies being consid
ered in the IETF and of the gaps that exist between the needs of those technolog
ies 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'?>
<!--
<reference anchor="I-D.ietf-lpwan-ipv6-static-context-hc">
<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>
<author initials='L' surname='Toutain' fullname='Laurent Toutain'> <author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
<organization /> <organization>Universitat Politecnica de Catalunya</organization>
</author> </author>
<author initials='C' surname='Gomez' fullname='Carles Gomez'> <author initials="L." surname="Toutain" fullname="Laurent Toutain">
<organization /> <organization>IMT-Atlantique</organization>
</author> </author>
<author initials='D' surname='Barthel' fullname='Dominique Barthel'> <author initials="S." surname="Céspedes" fullname="Sandra Céspedes">
<organization /> <organization>Concordia University</organization>
</author> </author>
<author initials='JC' surname='Zuniga' fullname='Juan Carlos Zuniga'> <author initials="D." surname="Wistuba" fullname="Diego S. Wistuba La Torre">
<organization /> <organization>NIC Labs, Universidad de Chile</organization>
</author> </author>
<date month="July" year="2023"/>
</front>
<seriesInfo name="RFC" value="9441"/>
<seriesInfo name="DOI" value="10.17487/RFC9441"/>
</reference>
<date month='October' day='22' year='2018' /> <reference anchor="sigfox-spec" target="https://build.sigfox.com/sigfox-
device-radio-specifications">
<abstract><t> This document describes a header compression scheme and fragment <front>
ation <title>Sigfox Device Radio Specifications</title>
functionality for very low bandwidth networks. These techniques are <author>
specially tailored for LPWAN (Low Power Wide Area Network) networks. <organization>Sigfox</organization>
</author>
The Static Context Header Compression (SCHC) offers a great level of </front>
flexibility when processing the header fields. SCHC compression is </reference>
based on a common static context stored in a LPWAN device and in the </references>
network. Static context means that the stored information does not <references>
change during the packet transmission. The context describes the <name>Informative References</name>
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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
and applies it to IPv6/UDP headers. This document also specifies a 376.xml"/>
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> <reference anchor="sigfox-docs" target="https://support.sigfox.com/docs"
>
<front>
<title>Sigfox Documentation</title>
<author>
<organization>Sigfox</organization>
</author>
</front>
</reference>
<seriesInfo name='Internet-Draft' value='draft-ietf-lpwan-ipv6-static-context-hc <reference anchor="sigfox-callbacks" target="https://support.sigfox.com/
-17' /> docs/callbacks-documentation">
<format type='TXT' <front>
target='http://www.ietf.org/internet-drafts/draft-ietf-lpwan-ipv6-static <title>Sigfox Callbacks</title>
-context-hc-16.txt' /> <author>
</reference> <organization>Sigfox</organization>
</author>
</front>
</reference>
<reference anchor="I-D.ietf-lpwan-schc-compound-ack"> <reference anchor="I-D.ietf-core-comi" target="https://datatracker.ietf.org/doc/ html/draft-ietf-core-comi-12">
<front> <front>
<title>SCHC Compound ACK</title> <title>CoAP Management Interface (CORECONF)</title>
<author initials="M." surname="Veillette" fullname="Michel Veillette" role="edit
<author initials='JC' surname='Zuniga' fullname='Juan Carlos Zuniga'> or">
<organization /> <organization>Trilliant Networks Inc.</organization>
</author>
<author initials='C' surname='Gomez' fullname='Carles Gomez'>
<organization />
</author> </author>
<author initials='S' surname='Aguilar' fullname='Sergio Aguilar'> <author initials="P." surname="van der Stok" fullname="Peter van der Stok" role=
<organization /> "editor">
<organization>consultant</organization>
</author> </author>
<author initials='L' surname='Toutain' fullname='Laurent Toutain'> <author initials="A." surname="Pelov" fullname="Alexander Pelov">
<organization /> <organization>Acklio</organization>
</author> </author>
<author initials='S' surname='Cespedes' fullname='Sandra Cespedes'> <author initials="A." surname="Bierman" fullname="Andy Bierman">
<organization /> <organization>YumaWorks</organization>
</author> </author>
<author initials='D' surname='Wistuba' fullname='Diego Wistuba'> <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor"
<organization /> >
<organization>Universität Bremen TZI</organization>
</author> </author>
<date month="March" day="13" year="2023"/>
<date month='January' year='2023' />
<abstract><t>The present document describes an extension to the SCHC (Static Hea
der Compression and Fragmentation) protocol. It defines a SCHC Compound ACK mess
age
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 L
WPAN technologies defined in <xref target="RFC8376"/>, being Sigfox, LoRaWAN, NB
-IoT and IEEE 802.15.4w. </t></abstract>
</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-c
ompound-ack-10.txt' />
</reference>
<reference anchor="sigfox-spec" target="https://build.sigfox.com/sigfox-devic
e-radio-specifications">
<front>
<title>Sigfox Radio Specifications</title>
<author initials="" surname="Sigfox" fullname="Sigfox">
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<references title='Informative References'>
<?rfc include='reference.RFC.8376'?>
<reference anchor="sigfox-docs" target="https://support.sigfox.com/docs">
<front>
<title>Sigfox Documentation</title>
<author initials="" surname="Sigfox" fullname="Sigfox">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor="sigfox-callbacks" target="https://support.sigfox.com/docs/cal
lbacks-documentation">
<front>
<title>Sigfox Callbacks</title>
<author initials="" surname="Sigfox" fullname="Sigfox">
<organization></organization>
</author>
<date />
</front>
</reference>
<reference anchor='I-D.ietf-core-comi'>
<front>
<title>CoAP Management Interface (CORECONF)</title>
<author fullname='Michel Veillette'>
<organization>Trilliant Networks Inc.</organization>
</author>
<author fullname='Peter van der Stok'>
<organization>consultant</organization>
</author>
<author fullname='Alexander Pelov'>
<organization>Acklio</organization>
</author>
<author fullname='Andy Bierman'>
<organization>YumaWorks</organization>
</author>
<author fullname='Ivaylo Petrov'>
<organization>Acklio</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>
</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/></aut
hor>
<author fullname='K. Hartke' initials='K.' surname='Hartke'><organization/></aut
hor>
<author fullname='C. Bormann' initials='C.' surname='Bormann'><organization/></a
uthor>
<date month='June' year='2014'/>
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web tr
ansfer protocol for use with constrained nodes and constrained (e.g., low-power,
lossy) networks. The nodes often have 8-bit microcontrollers with small amount
s of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireles
s Personal Area Networks (6LoWPANs) often have high packet error rates and a typ
ical throughput of 10s of kbit/s. The protocol is designed for machine- to-mach
ine (M2M) applications such as smart energy and building automation.</t><t>CoAP
provides a request/response interaction model between application endpoints, sup
ports 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 inte
rface with HTTP for integration with the Web while meeting specialized requireme
nts 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'><organizat
ion/></author>
<author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'>
<organization/></author>
<author fullname='J. Schoenwaelder' initials='J.' role='editor' surname='Schoenw
aelder'><organization/></author>
<author fullname='A. Bierman' initials='A.' role='editor' surname='Bierman'><org
anization/></author>
<date month='June' year='2011'/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this docume
nt provides mechanisms to install, manipulate, and delete the configuration of n
etwork devices. It uses an Extensible Markup Language (XML)-based data encoding
for the configuration data as well as the protocol messages. The NETCONF proto
col operations are realized as remote procedure calls (RPCs). This document obs
oletes 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/></a
uthor>
<author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'><organization/
></author>
<author fullname='K. Watsen' initials='K.' surname='Watsen'><organization/></aut
hor>
<date month='January' year='2017'/>
<abstract><t>This document describes an HTTP-based protocol that provides a prog
rammatic interface for accessing data defined in YANG, using the datastore conce
pts 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'><organizat
ion/></author>
<date month='December' year='2017'/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, lan
guage-independent data interchange format. It was derived from the ECMAScript P
rogramming Language Standard. JSON defines a small set of formatting rules for
the portable representation of structured data.</t><t>This document removes inco
nsistencies 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/></a
uthor>
<author fullname='P. Hoffman' initials='P.' surname='Hoffman'><organization/></a
uthor>
<date month='December' year='2020'/>
<abstract><t>The Concise Binary Object Representation (CBOR) is a data format wh
ose design goals include the possibility of extremely small code size, fairly sm
all message size, and extensibility without the need for version negotiation. Th
ese design goals make it different from earlier binary serializations such as AS
N.1 and MessagePack.</t><t>This document obsoletes RFC 7049, providing editorial
improvements, new details, and errata fixes while keeping full compatibility wi
th the interchange format of RFC 7049. It does not create a new version of the
format.</t></abstract>
</front> </front>
<seriesInfo name='STD' value='94'/> <seriesInfo name="Internet-Draft" value="draft-ietf-core-comi-12"/>
<seriesInfo name='RFC' value='8949'/>
<seriesInfo name='DOI' value='10.17487/RFC8949'/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
252.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
949.xml"/>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false" toc="default">
<!-- <name>Acknowledgements</name>
<section anchor="note" title="Note"> <t><contact fullname="Carles Gomez"/> has been funded in part by the Spani
<t>Carles Gomez has been funded in part by the Spanish Government sh Government
(Ministerio de Educacion, Cultura y Deporte) through the Jose through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant
Castillejo grant CAS15/00336, and by the ERDF and the Spanish Government (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria
through project TEC2016-79988-P. Part of his contribution to this work d'Universitats i Recerca del Departament d'Empresa i Coneixement de
has been carried out during his stay as a visiting scholar at the la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant SGR 003
Computer Laboratory of the University of Cambridge.</t> 30.</t>
<t><contact fullname="Sergio Aguilar"/> has been funded by the ERDF and th
</section> e Spanish Government through project TEC2016-79988-P and project PID2019-106808R
A-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).</t>
<t><contact fullname="Sandra Cespedes"/> has been funded in part by the AN
ID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
<t><contact fullname="Diego Wistuba"/> has been funded by the ANID Chile P
roject FONDECYT Regular 1201893.</t>
<t>The authors would like to thank <contact fullname="Ana Minaburo"/>, <co
ntact fullname="Clement Mannequin"/>, <contact fullname="Rafael Vidal"/>, <conta
ct fullname="Julien Boite"/>, <contact fullname="Renaud Marty"/>, and <contact f
ullname="Antonis Platis"/> for their useful comments and implementation design c
onsiderations.</t>
</section>
</back> </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> </rfc>
 End of changes. 171 change blocks. 
2753 lines changed or deleted 1498 lines changed or added

This html diff was produced by rfcdiff 1.48.