rfc9011xml2.original.xml   rfc9011.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.24 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc symrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-lpwan-schc-over-lorawan-14" category= "std"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-lpwan-schc-over-lorawan-14" number="9011" obsoletes="" updates="" submissi onType="IETF" category="std" consensus="true" xml:lang="en" symRefs="true" sortR efs="true" tocInclude="true" version="3">
<front> <front>
<title abbrev="SCHC-over-LoRaWAN">Static Context Header Compression (SCHC) o <title abbrev="SCHC over LoRaWAN">Static Context Header Compression and Frag
ver LoRaWAN</title> mentation (SCHC) over LoRaWAN</title>
<seriesInfo name="RFC" value="9011"/>
<author initials="O." surname="Gimenez" fullname="Olivier Gimenez" role="edi tor"> <author initials="O." surname="Gimenez" fullname="Olivier Gimenez" role="edi tor">
<organization>Semtech</organization> <organization>Semtech</organization>
<address> <address>
<postal> <postal>
<street>14 Chemin des Clos</street> <street>14 Chemin des Clos</street>
<city>Meylan</city> <city>Meylan</city>
<country>France</country> <country>France</country>
</postal> </postal>
<email>ogimenez@semtech.com</email> <email>ogimenez@semtech.com</email>
</address> </address>
</author> </author>
<author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor "> <author initials="I." surname="Petrov" fullname="Ivaylo Petrov" role="editor ">
<organization>Acklio</organization> <organization>Acklio</organization>
<address> <address>
<postal> <postal>
<street>1137A Avenue des Champs Blancs</street> <street>1137A Avenue des Champs Blancs</street>
<city>35510 Cesson-Sevigne Cedex</city> <city>Cesson-Sévigné Cedex</city>
<code>35510</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>ivaylo@ackl.io</email> <email>ivaylo@ackl.io</email>
</address> </address>
</author> </author>
<date year="2021" month="April"/>
<date year="2021" month="February" day="01"/>
<workgroup>lpwan Working Group</workgroup> <workgroup>lpwan Working Group</workgroup>
<abstract> <keyword>header compression</keyword>
<keyword>compression</keyword>
<t>The Static Context Header Compression (SCHC) specification describes generic <keyword>fragmentation</keyword>
header compression and fragmentation techniques for Low Power Wide Area <keyword>static context</keyword>
Networks (LPWAN) technologies. SCHC is a generic mechanism designed for great <keyword>rule-based</keyword>
flexibility so that it can be adapted for any of the LPWAN technologies.</t> <keyword>LPWAN</keyword>
<keyword>LPWANs</keyword>
<keyword>low power</keyword>
<keyword>low-power</keyword>
<keyword>LoRa</keyword>
<keyword>LoRaWAN</keyword>
<keyword>IoT</keyword>
<keyword>Internet of Things</keyword>
<keyword>adaptation layer</keyword>
<keyword>UDP</keyword>
<keyword>IPv6</keyword>
<keyword>sensor network</keyword>
<keyword>wireless sensor network</keyword>
<keyword>802.15.4</keyword>
<keyword>constrained network</keyword>
<keyword>constrained node</keyword>
<keyword>constrained-node network</keyword>
<keyword>SCHC</keyword>
<t>This document specifies a profile of RFC8724 to use SCHC in LoRaWAN® networks <abstract>
, <t>The Static Context Header Compression and fragmentation (SCHC) specific
and provides elements such as efficient parameterization and modes of ation (RFC 8724) describes
operation.</t> generic header compression and fragmentation techniques for Low-Power
Wide Area Network (LPWAN) technologies. SCHC is a generic mechanism
designed for great flexibility so that it can be adapted for any of the
LPWAN technologies.</t>
<t>This document specifies a profile of RFC 8724 to use SCHC in
LoRaWAN networks and provides elements such as efficient
parameterization and modes of operation.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" numbered="true" toc="default">
<section anchor="Introduction" title="Introduction"> <name>Introduction</name>
<t>The SCHC specification <xref target="RFC8724" format="default"/> descri
<t>SCHC specification <xref target="RFC8724"></xref> describes bes
generic header compression and fragmentation techniques that can be used on all generic header compression and fragmentation techniques that can be used on all
Low Power Wide Area Networks (LPWAN) technologies defined in Low-Power Wide Area Network (LPWAN) technologies defined in
<xref target="RFC8376"/>. Even though those technologies share a great <xref target="RFC8376" format="default"/>. Even though those technologies share
a great
number of common features like star-oriented topologies, network architecture, number of common features like star-oriented topologies, network architecture,
devices with mostly quite predictable communications, etc; they do have some devices with communications that are mostly quite predictable, etc., they do hav e some
slight differences with respect to payload sizes, reactiveness, etc.</t> slight differences with respect to payload sizes, reactiveness, etc.</t>
<t>SCHC provides a generic framework that enables those devices to communi
<t>SCHC provides a generic framework that enables those devices to communicate o cate on
n
IP networks. However, for efficient performance, some parameters IP networks. However, for efficient performance, some parameters
and modes of operation need to be set appropriately for each of the LPWAN and modes of operation need to be set appropriately for each of the LPWAN
technologies.</t> technologies.</t>
<t>This document describes the parameters and modes of operation when
SCHC is used over LoRaWAN networks. The LoRaWAN protocol is specified by
the LoRa Alliance in <xref target="LORAWAN-SPEC" format="default"/>.</t>
</section>
<section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<t>This document describes the parameters and modes of operation when <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
SCHC is used over LoRaWAN networks. LoRaWAN protocol is specified by the "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
LoRa Alliance® in <xref target="lora-alliance-spec"/></t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"
format="default"/> <xref target="RFC8174" format="default"/> when, and
only when, they appear in all capitals, as shown here.</t>
</section> <t>This section defines the terminology and abbreviations used in this doc
<section anchor="terminology" title="Terminology"> ument. For
all other definitions, please look up the SCHC specification
<xref target="RFC8724" format="default"/>.</t>
<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, <aside><t>
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this Note: The SCHC acronym is pronounced like "sheek" in English (or "chic" in Frenc
document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> < h).
xref target="RFC8174"/> Therefore, this document writes "a SCHC Packet" instead of "an SCHC Packet".
when, and only when, they appear in all capitals, as shown here.</t> </t></aside>
<t>This section defines the terminology and acronyms used in this document. For <dl>
all other definitions, please look up the SCHC specification
<xref target="RFC8724"></xref>.</t>
<t><list style="symbols"> <dt>AppKey:
<t>DevEUI: Device Extended Unique Identifier, an IEEE EUI-64 identifier </dt>
used to identify the device during the <dd>Application Key. An AES-128 root key specific to each device.
procedure while joining the network (Join Procedure). It is assigned by the </dd>
manufacturer or the device owner and provisioned on the Network Gateway.</t>
<t>DevAddr: a 32-bit non-unique identifier assigned to a device either: <list
style="symbols">
<t>Statically: by the device manufacturer in <spanx style="emph">Activatio
n by Personalization</spanx>
mode.</t>
<t>Dynamically: after a Join Procedure by the Network Gateway in <spanx st
yle="emph">Over The
Air Activation</spanx> mode.</t>
</list></t>
<t>Downlink: LoRaWAN term for a frame transmitted by the network and
received by the device.</t>
<t>EUI: Extended Unique Identifier</t>
<t>LoRaWAN: LoRaWAN is a wireless technology based on Industrial,
Scientific, and Medical (ISM) radio bands that is used for long-range,
low-power, low-data-rate applications developed by the LoRa Alliance, a
membership consortium: <eref target="https://www.lora-alliance.org">https://www.
lora-alliance.org</eref>.</t>
<t>FRMPayload: Application data in a LoRaWAN frame.</t>
<t>MSB: Most Significant Byte</t>
<t>OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI.</t>
<t>RCS: Reassembly Check Sequence. Used to verify the integrity of the
fragmentation-reassembly process.</t>
<t>RX: Device’s reception window.</t>
<t>RX1/RX2: LoRaWAN class A devices open two RX windows following an
uplink, called RX1 and RX2.</t>
<t>SCHC gateway: The LoRaWAN Application Server that manages translation
between IPv6 network and the Network Gateway (LoRaWAN Network
Server).</t>
<t>Tile: Piece of a fragmented packet as described in <xref target="RFC8724"><
/xref> section 8.2.2.1</t>
<t>Uplink: LoRaWAN term for a frame transmitted by the device and received
by the network.</t>
</list></t>
</section> <dt>AppSKey:
<section anchor="static-context-header-compression-overview" title="Static Conte </dt>
xt Header Compression Overview"> <dd>Application Session Key. An AES-128 key derived from the AppKey for
each new session. It is used to encrypt the payload field of a LoRaWAN
applicative frame.
</dd>
<t>This section contains a short overview of SCHC. For a detailed description, <dt>DevAddr:
refer to the full specification <xref target="RFC8724"></xref>.</t> </dt>
<dd><t>A 32-bit non-unique identifier assigned to a device either:</t>
<dl>
<dt>Statically:
</dt>
<dd>by the device manufacturer in "Activation-by-Personalization"
mode, or
</dd>
<dt>Dynamically:
</dt>
<dd>after a LoRaWAN "Join Procedure" by the Network Gateway in "Over-the-Air
-Activation" mode.
</dd>
</dl>
</dd>
<t>It defines:</t> <dt>DevEUI:
</dt>
<dd>Device Extended Unique Identifier, an IEEE EUI-64 identifier used to
identify the device during the procedure while joining the network (Join
Procedure). It is assigned by the manufacturer or the device owner and
provisioned on the Network Gateway.
</dd>
<t><list style="numbers"> <dt>Downlink:
<t>Compression mechanisms to avoid transporting information known by both </dt>
sender and receiver over the air. Known information is part of the <dd>A LoRaWAN term for a frame transmitted by the network and received by the de
“context”. This component is called SCHC Compressor/Decompressor (SCHC C/D).</t> vice.
<t>Fragmentation mechanisms to allow SCHC Packet transportation on small, and </dd>
potentially variable, MTU. This component is called SCHC Fragmentation/Reassembl
y
(SCHC F/R).</t>
</list></t>
<t>Context exchange or pre-provisioning is out of scope of this document.</t> <dt>EUI:
</dt>
<dd>Extended Unique Identifier
</dd>
<figure title="Architecture" anchor="Fig-archi"><artwork><![CDATA[ <dt>FRMPayload:
</dt>
<dd>Application data in a LoRaWAN frame
</dd>
<dt>IID:
</dt>
<dd>Interface Identifier
</dd>
<dt>LoRaWAN:
</dt>
<dd>LoRaWAN is a wireless technology based on Industrial, Scientific, and
Medical (ISM) radio bands that is used for long-range, low-power,
low-data-rate applications developed by the LoRa Alliance, a membership
consortium: <eref
brackets="angle" target="https://www.lora-alliance.org"/>.
</dd>
<dt>MSB:
</dt>
<dd>Most Significant Byte
</dd>
<dt>NGW:
</dt>
<dd>Network Gateway
</dd>
<dt>OUI:
</dt>
<dd>Organizationally Unique Identifier. IEEE-assigned prefix for EUI.
</dd>
<dt>RCS:
</dt>
<dd>Reassembly Check Sequence. Used to verify the integrity of the fragmentation
-reassembly process.
</dd>
<dt>RGW:
</dt>
<dd>Radio Gateway
</dd>
<dt>RX:
</dt>
<dd>A device's reception window.
</dd>
<dt>RX1/RX2:
</dt>
<dd>LoRaWAN class A devices open two RX windows following an uplink, called "RX1
" and "RX2".
</dd>
<dt>SCHC C/D:
</dt>
<dd>SCHC Compression/Decompression
</dd>
<dt>SCHC F/R:
</dt>
<dd>SCHC Fragmentation/Reassembly
</dd>
<dt>SCHC gateway:
</dt>
<dd>The LoRaWAN Application Server that manages translation between an IPv6
network and the Network Gateway (LoRaWAN Network Server).
</dd>
<dt>Tile:
</dt>
<dd>A piece of a fragmented packet as described in <xref target="RFC8724"
sectionFormat="of" section="8.2.2.1" format="default"/>.
</dd>
<dt>Uplink:
</dt>
<dd>LoRaWAN term for a frame transmitted by the device and received by the netwo
rk.
</dd>
</dl>
</section>
<section anchor="static-context-header-compression-overview" numbered="true"
toc="default">
<name>SCHC Overview</name>
<t>This section contains a short overview of SCHC. For a detailed
description, refer to the full specification <xref target="RFC8724"
format="default"/>.</t>
<t>It defines:</t>
<ol spacing="normal" type="1"><li>Compression mechanisms to avoid
transporting information known by both sender and receiver over the
air. Known information is part of the "context". This component is
called the "SCHC Compression/Decompression" (SCHC C/D).</li>
<li>Fragmentation mechanisms to allow SCHC Packet transportation on a
small, and potentially variable, MTU. This component is called the "SCHC
Fragmentation/Reassembly" (SCHC F/R).</li>
</ol>
<t>Context exchange or pre-provisioning is out of scope of this document.<
/t>
<figure anchor="Fig-archi">
<name>Architecture</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Device App Device App
+----------------+ +----+ +----+ +----+ +----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3| | App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | | | | | | | | | |
| UDP | |UDP | |UDP | |UDP | | UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6| | IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | | | | | | | | | |
|SCHC C/D and F/R| | | | | | | |SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+ +--------+-------+ +----+ +----+ +----+
| +---+ +----+ +----+ +----+ . . . | +---+ +----+ +----+ +----+ . . .
+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet .... +~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....
+---+ +----+ |F/R | |C/D | +---+ +----+ |F/R | |C/D |
+----+ +----+ +----+ +----+
|<- - - - LoRaWAN - - ->| |<- - - - LoRaWAN - - ->|
]]></artwork></figure> ]]></artwork>
</figure>
<t><xref target="Fig-archi"/> represents the architecture for compression/decomp <t><xref target="Fig-archi" format="default"/> represents the
ression, it is architecture for compression/decompression; it is based on the terminology
based on <xref target="RFC8376"/> terminology. The device is sending application from <xref
s flows target="RFC8376" format="default"/>. The device is sending
using IPv6 or IPv6/UDP protocols. These flows might be compressed by a Static application flows using IPv6 or IPv6/UDP protocols. These flows might
Context Header Compression Compressor/Decompressor (SCHC C/D) to reduce headers be compressed by a SCHC C/D to reduce header size, and fragmented
size and fragmented by the SCHC Fragmentation/Reassembly (SCHC F/R). by the SCHC F/R. The resulting
The resulting information is sent on a layer two information is sent on a Layer 2 (L2) frame to an LPWAN Radio Gateway
(L2) frame to an LPWAN Radio Gateway (RGW) that forwards the frame to a Network (RGW) that forwards the frame to a Network Gateway (NGW). The NGW sends
Gateway (NGW). The NGW sends the data to a SCHC F/R for reassembly, if the data to a SCHC F/R for reassembly, if required, then to a SCHC C/D for
required, then to SCHC C/D for decompression. The SCHC C/D shares the same rules decompression. The SCHC C/D shares the same rules with the device. The
with the SCHC C/D and SCHC F/R can be located on the NGW or in
device. The SCHC C/D and F/R can be located on the Network Gateway (NGW) or in another place as long as a communication is established between the NGW
another place as long as a communication is established between the NGW and the and the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D and SCHC F/R in
SCHC the
F/R, then SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC gate device and the SCHC gateway <bcp14>MUST</bcp14> share the same set of
way MUST rules. After decompression, the packet can be sent on the Internet to
share the same set of rules. After decompression, the packet can be sent on the one or several LPWAN Application Servers (App).</t>
Internet to <t>The SCHC C/D and SCHC F/R process is bidirectional, so the same princip
one or several LPWAN Application Servers (App).</t> les
can be applied to the other direction.</t>
<t>The SCHC C/D and F/R process is bidirectional, so the same principles can <t>In a LoRaWAN network, the RGW is called a "Gateway", the NGW is a
be applied to the other direction.</t> "Network Server", and the SCHC C/D and SCHC F/R are one or more
"Application Servers".
<t>In a LoRaWAN network, the RGW is called a Gateway, the NGW is Network Server, Application servers can be provided by the NGW or any third-party
and the SCHC C/D and F/R are an Application Server. It can be provided by software. <xref target="Fig-archi" format="default"/> can be mapped in
the Network Gateway or any third party software. <xref target="Fig-archi"/> can LoRaWAN terminology to:</t>
be mapped in
LoRaWAN terminology to:</t>
<figure title="SCHC Architecture mapped to LoRaWAN" anchor="Fig-archi-lorawan">< <figure anchor="Fig-archi-lorawan">
artwork><![CDATA[ <name>SCHC Architecture Mapped to LoRaWAN</name>
End Device App <artwork name="" type="" align="left" alt=""><![CDATA[
+--------------+ +----+ +----+ +----+ End Device App
|App1 App2 App3| |App1| |App2| |App3| +--------------+ +----+ +----+ +----+
| | | | | | | | |App1 App2 App3| |App1| |App2| |App3|
| UDP | |UDP | |UDP | |UDP | | | | | | | | |
| IPv6 | |IPv6| |IPv6| |IPv6| | UDP | |UDP | |UDP | |UDP |
| | | | | | | | | IPv6 | |IPv6| |IPv6| |IPv6|
|SCHC C/D & F/R| | | | | | | | | | | | | | |
+-------+------+ +----+ +----+ +----+ |SCHC C/D & F/R| | | | | | |
| +-------+ +-------+ +-----------+ . . . +-------+------+ +----+ +----+ +----+
+~ |Gateway| === |Network| == |Application|..... Internet .... | +-------+ +-------+ +-----------+ . . .
+-------+ |server | |server | +~ |Gateway| == |Network| == |Application|..... Internet ....
+-------+ | F/R - C/D | +-------+ |server | |server |
+-----------+ +-------+ | F/R - C/D |
+-----------+
|<- - - - - LoRaWAN - - - ->| |<- - - - - LoRaWAN - - - ->|
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="lorawan-architecture" title="LoRaWAN Architecture"> <section anchor="lorawan-architecture" numbered="true" toc="default">
<name>LoRaWAN Architecture</name>
<t>An overview of LoRaWAN <xref target="lora-alliance-spec"/> protocol and archi <t>An overview of the LoRaWAN protocol and architecture <xref target="LORA
tecture is WAN-SPEC"
described in <xref target="RFC8376"/>. The mapping between the LPWAN format="default"/> is described in <xref
architecture entities as described in <xref target="RFC8724"></xref> target="RFC8376" format="default"/>. The mapping between the LPWAN
and the ones in <xref target="lora-alliance-spec"/> is as follows:</t> architecture entities as described in <xref target="RFC8724"
format="default"/> and the ones in <xref target="LORAWAN-SPEC"
<t>o Devices are LoRaWAN End Devices (e.g. sensors, format="default"/> is as follows:</t>
actuators, etc.). There can be a very high density of devices per <ul>
radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN end-device.< <li>Devices are LoRaWAN End Devices (e.g., sensors, actuators, etc.). There
/t> can be a very high density of devices per radio gateway (LoRaWAN
gateway). This entity maps to the LoRaWAN end device.
</li>
<t>o The Radio Gateway (RGW), which is the endpoint of the constrained <li>The RGW is the endpoint of the constrained
link. This entity maps to the LoRaWAN Gateway.</t> link. This entity maps to the LoRaWAN Gateway.
</li>
<t>o The Network Gateway (NGW) is the interconnection node between the <li>The NGW is the interconnection node between the Radio
Radio Gateway and the SCHC gateway (LoRaWAN Application server). This Gateway and the SCHC gateway (LoRaWAN Application Server). This entity maps to
entity maps to the LoRaWAN Network Server.</t> the LoRaWAN Network Server.
</li>
<t>o SCHC C/D and F/R are handled by LoRaWAN Application Server; ie the LoRaWAN <li>The SCHC C/D and SCHC F/R are handled by the LoRaWAN Application Server.
application server will do the SCHC C/D and F/R.</t> </li>
<t>o The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to manage and <li>The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to manage and
deliver security keys in a secure way, so that the devices root key is never deliver security keys in a secure way so that the devices root key is never
exposed.</t> exposed.
</li>
</ul>
<figure title="LPWAN Architecture" anchor="Fig-LPWANarchi"><artwork><![CDATA[ <figure anchor="Fig-LPWANarchi">
<name>LPWAN Architecture</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
(LPWAN-AAA Server) (LPWAN-AAA Server)
() () () | +------+ () () () | +------+
() () () () / \ +---------+ | Join | () () () () / \ +---------+ | Join |
() () () () () / \======| ^ |===|Server| +-----------+ () () () () () / \======| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |Application| () () () | | <--|--> | +------+ |Application|
() () () () / \==========| v |=============| Server | () () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
End-devices Gateways Network Server (SCHC C/D and F/R) End devices Gateways Network Server (SCHC C/D and F/R)
(devices) (RGW) (NGW) (devices) (RGW) (NGW)
]]></artwork></figure> ]]></artwork>
</figure>
<t><spanx style="emph">Note</spanx>: <xref target="Fig-LPWANarchi"/> terms are f <aside> <t>Note: <xref target="Fig-LPWANarchi" format="default"/> terms
rom LoRaWAN, with <xref target="RFC8376"/> terminology in brackets.</t> are from LoRaWAN, with <xref target="RFC8376" format="default"/>
terminology in brackets.</t></aside>
<t>The SCHC C/D and SCHC F/R are performed on the LoRaWAN end
device and the Application Server (called the SCHC gateway). While the
point-to-point link between the device and the Application Server
constitutes a single IP hop, the ultimate endpoint of the IP
communication may be an Internet node beyond the Application Server. In
other words, the LoRaWAN Application Server (SCHC gateway) acts as the
first-hop IP router for the device. The Application Server and Network
Server may be co-located, which effectively turns the
Network/Application Server into the first-hop IP router.</t>
<section anchor="device-classes-a-b-c-and-interactions" numbered="true" to
c="default">
<name>Device Classes (A, B, C) and Interactions</name>
<t>SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/Reassembly (SC <t>The LoRaWAN Medium Access Control (MAC) layer supports three
HC F/R) classes of devices named A, B, and C. All devices implement Class
are performed on the LoRaWAN end-device and the Application Server (called A, and some devices may implement Class B or Class C. Class B and Class
SCHC gateway). While the point-to-point link between the device and the C
Application Server constitutes a single IP hop, the ultimate end-point of the are mutually exclusive.</t>
IP communication may be an Internet node beyond the Application Server.
In other words, the LoRaWAN Application Server (SCHC gateway) acts as the
first hop IP router for the device. The Application Server and Network
Server may be co-located, which effectively turns the Network/Application
Server into the first hop IP router.</t>
<section anchor="device-classes-a-b-c-and-interactions" title="Device classes (A , B, C) and interactions"> <dl>
<t>The LoRaWAN MAC layer supports 3 classes of devices named A, B and C. All <dt>Class A:
devices implement the Class A, some devices may implement Class B or </dt>
Class C. Class B and Class C are mutually exclusive.</t> <dd>Class A is the simplest class of devices. The device is allowed to
transmit at any time, randomly selecting a communication channel. The Network
Gateway may reply with a downlink in one of the two receive windows immediately
following the uplinks. Therefore, the Network Gateway cannot initiate a
downlink; it has to wait for the next uplink from the device to get a downlink
opportunity. Class A is the lowest power consumption class.
</dd>
<t><list style="symbols"> <dt>Class B:
<t>Class A: The Class A is the simplest class of devices. The device is </dt>
allowed to transmit at any time, randomly selecting a communication channel. <dd><t>Class B devices implement all the functionalities of Class A devices but
The Network Gateway may reply with a downlink in one of the 2 receive windows also schedule periodic listen windows. Therefore, as opposed to Class A
immediately following the uplinks. Therefore, the Network Gateway cannot initiat devices, Class B devices can receive downlinks that are initiated by the
e a
downlink, it has to wait for the next uplink from the device to get a
downlink opportunity. The Class A is the lowest power consumption class.</t>
<t>Class B: Class B devices implement all the functionalities of Class A
devices, but also schedule periodic listen windows. Therefore, opposed to the
Class A devices, Class B devices can receive downlinks that are initiated by the
Network Gateway and not following an uplink. There is a trade-off between the Network Gateway and not following an uplink. There is a trade-off between the
periodicity of those scheduled Class B listen windows and the power periodicity of those scheduled Class B listen windows and the power
consumption of the device: if the periodicity is high downlinks from the NGW consumption of the device: </t>
will be sent faster, but the device wakes up more often: it will have higher
power consumption.</t>
<t>Class C: Class C devices implement all the functionalities of Class A
devices, but keep their receiver open whenever they are not transmitting.
Class C devices can receive downlinks at any time at the expense of a higher
power consumption. Battery-powered devices can only operate in Class C for a
limited amount of time (for example for a firmware upgrade over-the-air).
Most of the Class C devices are grid powered (for example Smart Plugs).</t>
</list></t>
</section> <dl>
<section anchor="device-addressing" title="Device addressing">
<t>LoRaWAN end-devices use a 32-bit network address (devAddr) to communicate wit <dt>High periodicity:</dt>
h <dd>Downlinks from the NGW will be sent faster but the device wakes up more
the Network Gateway over-the-air, this address might not be unique in a LoRaWAN often and power consumption is increased.</dd>
network. Devices using the same devAddr are distinguished by the Network
Gateway based on the cryptographic signature appended to every LoRaWAN frame.</t
>
<t>To communicate with the SCHC gateway, the Network Gateway MUST identify the <dt>Low periodicity:</dt>
devices by a unique 64-bit device identifier called the DevEUI.</t> <dd>Downlinks from the NGW will have higher latency but lower power consumption.
</dd>
</dl>
<t>The DevEUI is assigned to the device during the manufacturing process by the </dd>
device’s manufacturer. It is built like an Ethernet MAC address by
concatenating the manufacturer’s IEEE OUI field with a vendor unique number.
e.g.: 24-bit OUI is concatenated with a 40-bit serial number.
The Network Gateway translates the devAddr into a DevEUI in the uplink
direction and reciprocally on the downlink direction.</t>
<figure title="LoRaWAN addresses" anchor="Fig-LoRaWANaddresses"><artwork><![CDAT <dt>Class C:
A[ </dt>
<dd>Class C devices implement all the functionalities of Class A devices but
keep their receiver open whenever they are not transmitting. Class C devices
can receive downlinks at any time at the expense of a higher power
consumption. Battery-powered devices can only operate in Class C for a limited
amount of time (for example, for a firmware upgrade over-the-air). Most of the
Class C devices are grid powered (for example, Smart Plugs).
</dd>
</dl>
</section>
<section anchor="device-addressing" numbered="true" toc="default">
<name>Device Addressing</name>
<t>LoRaWAN end devices use a 32-bit network address (DevAddr) to
communicate with the Network Gateway over the air; this address might
not be unique in a LoRaWAN network. Devices using the same DevAddr are
distinguished by the Network Gateway based on the cryptographic
signature appended to every LoRaWAN frame.</t>
<t>To communicate with the SCHC gateway, the Network Gateway
<bcp14>MUST</bcp14> identify the devices by a unique 64-bit device
identifier called the "DevEUI".</t>
<t>The DevEUI is assigned to the device during the manufacturing
process by the device's manufacturer. It is built like an Ethernet MAC
address by concatenating the manufacturer's IEEE OUI field with a
vendor unique number. For example, a 24-bit OUI is concatenated with a
40-bit
serial number. The Network Gateway translates the DevAddr into a
DevEUI in the uplink direction and reciprocally on the downlink
direction.</t>
<figure anchor="Fig-LoRaWANaddresses">
<name>LoRaWAN Addresses</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +---------+ +---------+ +----------+ +--------+ +---------+ +---------+ +----------+
| Device | <=====> | Network | <====> | SCHC | <======> | Internet | | Device | <=====> | Network | <====> | SCHC | <======> | Internet |
| | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | | | | DevAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |
+--------+ +---------+ +---------+ +----------+ +--------+ +---------+ +---------+ +----------+
]]></artwork>
</figure>
</section>
<section anchor="general-frame-types" numbered="true" toc="default">
<name>General Frame Types</name>
<t>LoRaWAN implements the possibility to send confirmed or unconfirmed f
rames:</t>
]]></artwork></figure> <dl>
</section>
<section anchor="general-frame-types" title="General Frame Types">
<t>LoRaWAN implements the possibility to send confirmed or unconfirmed frames:</
t>
<t><list style="symbols"> <dt>Confirmed frame:
<t>Confirmed frame: </dt>
The sender asks the receiver to acknowledge the frame.</t> <dd>The sender asks the receiver to acknowledge the frame.
<t>Unconfirmed frame: </dd>
The sender does not ask the receiver to acknowledge the frame.</t>
</list></t>
<t>As SCHC defines its own acknowledgment mechanisms, SCHC does not require <dt>Unconfirmed frame:
the use of LoRaWAN Confirmed frames (MType=0b100 as per </dt>
<xref target="lora-alliance-spec"/>)</t> <dd>The sender does not ask the receiver to acknowledge the frame.
</dd>
</section> </dl>
<section anchor="lorawan-mac-frames" title="LoRaWAN MAC Frames">
<t>In addition to regular data frames, LoRaWAN implements JoinRequest and JoinAc <t>As SCHC defines its own acknowledgment mechanisms, SCHC does not requ
cept ire
the use of LoRaWAN Confirmed frames (FType = 0b100 as per
<xref target="LORAWAN-SPEC" format="default"/>).</t>
</section>
<section anchor="lorawan-mac-frames" numbered="true" toc="default">
<name>LoRaWAN MAC Frames</name>
<t>In addition to regular data frames, LoRaWAN implements JoinRequest an
d JoinAccept
frame types, which are used by a device to join a network:</t> frame types, which are used by a device to join a network:</t>
<dl>
<t><list style="symbols"> <dt>JoinRequest:
<t>JoinRequest: </dt>
This frame is used by a device to join a network. It contains the device’s <dd>This frame is used by a device to join a network. It contains the device's
unique identifier DevEUI and a random nonce that will be used for session key unique identifier DevEUI and a random nonce that will be used for session key
derivation.</t> derivation.
<t>JoinAccept: </dd>
To on-board a device, the Network Gateway responds to the JoinRequest
issued by a device with a JoinAccept frame. That frame is
encrypted with the device’s AppKey and contains (amongst other fields)
the network’s major settings and a random nonce used to derive the session
keys.</t>
<t>Data:
MAC and application data. Application data are protected with AES-128
encryption. MAC related data are AES-128 encrypted with another key.</t>
</list></t>
</section>
<section anchor="lorawan-fport" title="LoRaWAN FPort">
<t>The LoRaWAN MAC layer features a frame port field in all frames. This field
(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows
LoRaWAN networks and applications to identify data.</t>
</section>
<section anchor="lorawan-empty-frame" title="LoRaWAN empty frame">
<t>A LoRaWAN empty frame is a LoRaWAN frame without FPort (cf <xref target="lora
wan-schc-payload"/>)
and FRMPayload.</t>
</section> <dt>JoinAccept:
<section anchor="unicast-and-multicast-technology" title="Unicast and multicast </dt>
technology"> <dd>To onboard a device, the Network Gateway responds to the JoinRequest
issued by a device with a JoinAccept frame. That frame is encrypted with the
device's AppKey and contains (among other fields) the network's major
settings and a random nonce used to derive the session keys.
</dd>
<t>LoRaWAN technology supports unicast downlinks, but also multicast: a packet <dt>Data:
sent over LoRaWAN radio link can be received by several devices. It is </dt>
useful to address many devices with same content, either a large binary <dd>This refers to MAC and application data. Application data is protected with
file (firmware upgrade), or same command (e.g: lighting control). AES-128
As IPv6 is also a multicast technology this feature can be used to address a encryption. MAC-related data is AES-128 encrypted with another key.
group of devices.</t> </dd>
<t><spanx style="emph">Note 1</spanx>: IPv6 multicast addresses must be defined </dl>
as per <xref target="RFC4291"></xref>. LoRaWAN
multicast group definition in a Network Gateway and the relation between those
groups and IPv6 groupID are out of scope of this document.</t>
<t><spanx style="emph">Note 2</spanx>: LoRa Alliance defined <xref target="lora- </section>
alliance-remote-multicast-set"/> as <section anchor="lorawan-fport" numbered="true" toc="default">
the RECOMMENDED way to setup multicast groups on devices and create a synchroniz <name>LoRaWAN FPort</name>
ed <t>The LoRaWAN MAC layer features a frame port field in all frames. This
reception window.</t> field
(FPort) is 8 bits long and the values from 1 to 223 can be used. It allows
LoRaWAN networks and applications to identify data.</t>
</section>
<section anchor="lorawan-empty-frame" numbered="true" toc="default">
<name>LoRaWAN Empty Frame</name>
<t>A LoRaWAN empty frame is a LoRaWAN frame without FPort (cf. <xref
target="lorawan-schc-payload" format="default"/>) and FRMPayload.</t>
</section>
</section> <section anchor="unicast-and-multicast-technology" numbered="true" toc="de
</section> fault">
<section anchor="schc-over-lorawan" title="SCHC-over-LoRaWAN"> <name>Unicast and Multicast Technology</name>
<t>LoRaWAN technology supports unicast downlinks but also multicast; a
multicast packet sent over a LoRaWAN radio link can be received by sever
al
devices. It is useful to address many devices with the same content:
either a large binary file (firmware upgrade) or the same command (e.g.,
lighting control). As IPv6 is also a multicast technology, this
feature can be used to address a group of devices.</t>
<section anchor="lorawan-schc-payload" title="LoRaWAN FPort and RuleID"> <aside>
<t>Note 1: IPv6 multicast addresses must be defined as per
<xref target="RFC4291" format="default"/>. The LoRaWAN multicast group
definition in a Network Gateway and the relation between those groups
and IPv6 groupID are out of scope of this document.</t>
</aside>
<aside> <t>Note 2: The LoRa Alliance defined <xref
target="LORAWAN-REMOTE-MULTICAST-SET" format="default"/> as the
<bcp14>RECOMMENDED</bcp14> way to set up multicast groups on devices
and create a synchronized reception window.</t>
</aside>
<t>The FPort field is part of the SCHC Message, as shown in </section>
<xref target="Fig-lorawan-schc-payload"/>. The SCHC C/D and the SCHC F/R SHALL c </section>
oncatenate <section anchor="schc-over-lorawan" numbered="true" toc="default">
<name>SCHC over LoRaWAN</name>
<section anchor="lorawan-schc-payload" numbered="true" toc="default">
<name>LoRaWAN FPort and RuleID</name>
<t>The FPort field is part of the SCHC Message, as shown in
<xref target="Fig-lorawan-schc-payload" format="default"/>. The SCHC C/D and the
SCHC F/R <bcp14>SHALL</bcp14> concatenate
the FPort field with the LoRaWAN payload to recompose the SCHC Message.</t> the FPort field with the LoRaWAN payload to recompose the SCHC Message.</t>
<figure anchor="Fig-lorawan-schc-payload">
<figure title="SCHC Message in LoRaWAN" anchor="Fig-lorawan-schc-payload"><artwo <name>SCHC Message in LoRaWAN</name>
rk><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------------------------ + + ------------------------ +
| SCHC Message | | SCHC Message |
]]></artwork>
]]></artwork></figure> </figure>
<aside><t>Note: The SCHC Message is any datagram sent by the SCHC C/D or
<t>Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers.</t> F/R layers.</t></aside>
<t>A fragmented datagram with application payload transferred from devic
<t>A fragmented datagram with application payload transferred from device to e to
Network Gateway, is called an uplink fragmented datagram. It uses an FPort for d Network Gateway is called an "uplink-fragmented datagram". It uses an FPort for
ata uplink data uplink
and its associated SCHC control downlinks, named FPortUp in this document. The and its associated SCHC control downlinks, named "FPortUp" in this document. The
other way, a fragmented datagram with application payload transferred from other way, a fragmented datagram with application payload transferred from
Network Gateway to device, is called downlink fragmented datagram. It uses anoth Network Gateway to device is called a "downlink-fragmented datagram". It uses an
er other
FPort for data downlink and its associated SCHC control uplinks, named FPortDown FPort for data downlink and its associated SCHC control uplinks, named "FPortDow
n"
in this document.</t> in this document.</t>
<t>All RuleID can use arbitrary values inside the FPort range allowed by LoRaWAN <t>All RuleIDs can use arbitrary values inside the FPort range allowed
specification and MUST be shared by the device and SCHC gateway prior to by the LoRaWAN specification <xref target="LORAWAN-SPEC"/> and
the communication with the selected rule. <bcp14>MUST</bcp14> be shared by the device and SCHC gateway prior to
The uplink and downlink fragmentation FPorts MUST be different.</t> the communication with the selected rule. The uplink and downlink
fragmentation FPorts <bcp14>MUST</bcp14> be different.</t>
</section> </section>
<section anchor="rule-id-management" title="Rule ID management"> <section anchor="rule-id-management" numbered="true" toc="default">
<name>RuleID Management</name>
<t>RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in <t>The RuleID <bcp14>MUST</bcp14> be 8 bits and encoded in the LoRaWAN
<xref target="lorawan-schc-payload"/>. LoRaWAN supports up to 223 application FP FPort as described in <xref target="lorawan-schc-payload"
orts in format="default"/>.
the range [1;223] as defined in section 4.3.2 of <xref target="lora-alliance-spe
c"/>, it implies
that RuleID MSB SHOULD be inside this range. An application can send non SCHC
traffic by using FPort values different from the ones used for SCHC.</t>
<t>In order to improve interoperability, RECOMMENDED fragmentation RuleID values
are:</t>
<t><list style="symbols">
<t>RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.</t>
<t>RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.</t>
<t>RuleID = 22 (8-bit) for which SCHC compression was not possible (i.e., no m
atching
compression Rule was found), as described in <xref target="RFC8724"/> section 6.
</t>
</list></t>
<t>FPortUp value MUST be different from FPortDown.
The remaining RuleIDs are available for compression. RuleIDs are shared between
uplink and downlink sessions. A RuleID not in the set(s) of FPortUp or FPortDow
n
means that the fragmentation is not used, thus, on reception, the SCHC Message
MUST be sent to the SCHC C/D layer.</t>
<t>The only uplink frames using the FPortDown port are the fragmentation SCHC LoRaWAN supports up to 223 application FPorts in
control messages of a downlink fragmented datagram (for example, SCHC ACKs). the range [1..223] as defined in Section 4.3.2 of <xref
Similarly, the only downlink frames using the FPortUp port are the target="LORAWAN-SPEC" format="default"/>; it implies that the RuleID MSB
fragmentation SCHC control messages of an uplink fragmented datagram.</t> <bcp14>SHOULD</bcp14> be inside this range. An application can send
non-SCHC traffic by using FPort values different from the ones used
for SCHC.</t>
<t>In order to improve interoperability, <bcp14>RECOMMENDED</bcp14> frag
mentation RuleID values are:</t>
<ul spacing="normal">
<li>RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.</li>
<li>RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.</
li>
<li>RuleID = 22 (8-bit) for which SCHC compression was not possible (i
.e., no matching
compression Rule was found), as described in <xref target="RFC8724" sectionForma
t="of" section="6" format="default"/>.</li>
</ul>
<t>An application can have multiple fragmented datagrams between a device and on <t>The FPortUp value <bcp14>MUST</bcp14> be different from the FPortDown
e value. The
or several SCHC gateways. A set of FPort values is REQUIRED for each SCHC gatew remaining RuleIDs are available for compression. RuleIDs are shared
ay between uplink and downlink sessions. A RuleID not in the set(s) of
FPortUp or FPortDown means that the fragmentation is not used; thus,
on reception, the SCHC Message <bcp14>MUST</bcp14> be sent to the SCHC
C/D layer.</t>
<t>The only uplink frames using the FPortDown port are the
fragmentation SCHC control messages of a downlink-fragmented datagram
(for example, SCHC ACKs). Similarly, the only downlink frames using
the FPortUp port are the fragmentation SCHC control messages of an
uplink-fragmented datagram.</t>
<t>An application can have multiple fragmented datagrams between a devic
e and one
or several SCHC gateways. A set of FPort values is <bcp14>REQUIRED</bcp14> for
each SCHC gateway
instance the device is required to communicate with. The application can use instance the device is required to communicate with. The application can use
additional uplinks or downlink fragmented parameters but SHALL implement at additional uplinks or downlink-fragmented parameters but <bcp14>SHALL</bcp14> im plement at
least the parameters defined in this document.</t> least the parameters defined in this document.</t>
<t>The mechanism for context distribution across devices and gateways is
<t>The mechanism for context distribution across devices and gateways is
outside the scope of this document.</t> outside the scope of this document.</t>
</section>
</section> <section anchor="IID" numbered="true" toc="default">
<section anchor="IID" title="Interface IDentifier (IID) computation"> <name>Interface IDentifier (IID) Computation</name>
<t>In order to mitigate the risks described in <xref target="RFC8064" fo
<t>In order to mitigate the risks described in <xref target="RFC8064"></xref> an rmat="default"/> and <xref target="RFC8065" format="default"/>,
d <xref target="RFC8065"></xref>, implementations <bcp14>MUST</bcp14> implement the following algorithm and <bcp14
implementation MUST implement the following algorithm and SHOULD use it.</t> >SHOULD</bcp14> use it.</t>
<ol spacing="normal" type="1"><li>key = LoRaWAN AppSKey</li>
<t><list style="numbers"> <li>cmac = aes128_cmac(key, DevEUI)</li>
<t>key = LoRaWAN AppSKey</t> <li>IID = cmac[0..7]</li>
<t>cmac = aes128_cmac(key, DevEUI)</t> </ol>
<t>IID = cmac[0..7]</t> <t>The aes128_cmac algorithm is described in <xref target="RFC4493"
</list></t> format="default"/>. It has been chosen as it is already used by
devices for the LoRaWAN protocol.</t>
<t>aes128_cmac algorithm is described in <xref target="RFC4493"></xref>. It has <t>As AppSKey is renewed each time a device joins or rejoins a LoRaWAN
been chosen as it is network, the IID will change over time; this
already used by devices for LoRaWAN protocol.</t> mitigates privacy concerns, for example, location tracking or correlatio
n
over time. Join periodicity is defined at the application level.</t>
<t>As AppSKey is renewed each time a device joins or rejoins a LoRaWAN network, <t>Address-scan risk is mitigated thanks to the entropy added to
the IID will change over time; this mitigates privacy, location tracking and the IID by the inclusion of AppSKey.</t>
correlation over time risks. Join periodicity is defined at the application <t>Using this algorithm will also ensure that there is no correlation
level.</t> between the hardware identifier (DevEUI) and the IID, so an
attacker cannot use the manufacturer OUI to target devices.</t>
<t>Example with:</t>
<ul spacing="normal">
<li>DevEUI: 0x1122334455667788</li>
<li>AppSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB</li>
</ul>
<figure anchor="Fig-iid-computation-example">
<name>Example of IID Computation</name>
<sourcecode><![CDATA[
1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
2. cmac: 0x4E822D9775B2649928F82066AF804FEC
3. IID: 0x4E822D9775B26499
]]></sourcecode>
<t>Address scan risk is mitigated thanks to AES-128, which provides enough entro </figure>
py
bits of the IID.</t>
<t>Using this algorithm will also ensure that there is no correlation between th <t>There is a small probability of IID collision in a LoRaWAN
e network. If this occurs, the IID can be changed by rekeying the device
hardware identifier (IEEE-64 DevEUI) and the IID, so an attacker cannot use at the L2 level (i.e., triggering a LoRaWAN join). The way the device i
manufacturer OUI to target devices.</t> s
rekeyed is out of scope of this document and left to the
implementation.</t>
<aside><t>Note: Implementations also using another IID source
<bcp14>MUST</bcp14> ensure that the same IID is shared between the
device and the SCHC gateway in the compression and decompression of
the IPv6 address of the device.</t></aside>
</section>
<section anchor="padding" numbered="true" toc="default">
<name>Padding</name>
<t>All padding bits <bcp14>MUST</bcp14> be 0.</t>
</section>
<section anchor="Decomp" numbered="true" toc="default">
<name>Decompression</name>
<t>The SCHC C/D <bcp14>MUST</bcp14> concatenate FPort and LoRaWAN payloa
d
to retrieve the SCHC Packet as per <xref target="lorawan-schc-payload"
format="default"/>.</t>
<t>RuleIDs matching FPortUp and FPortDown are reserved for SCHC fragment
ation.</t>
</section>
<section anchor="Frag" numbered="true" toc="default">
<name>Fragmentation</name>
<t>The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC
fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink
fragmentation and ACK-Always mode for downlink fragmentation. A
LoRaWAN device cannot support simultaneous interleaved fragmented
datagrams in the same direction (uplink or downlink).</t>
<t>The fragmentation parameters are different for uplink- and
downlink-fragmented datagrams and are successively described in the
next sections.</t>
<section anchor="DTag" numbered="true" toc="default">
<name>DTag</name>
<t>Example with:</t> <t><xref target="RFC8724" sectionFormat="of" section="8.2.4"
format="default"/> describes the possibility to interleave several
fragmented SCHC datagrams for the same RuleID. This is not used in
the SCHC-over-LoRaWAN profile. A device cannot interleave several
fragmented SCHC datagrams on the same FPort. This field is not used,
and its size is 0.</t>
<aside> <t>Note: The device can still have several parallel fragmented
datagrams with more than one SCHC gateway thanks to distinct sets of FPorts,
cf. <xref target="rule-id-management" format="default"/>.</t></aside>
</section>
<section anchor="uplink-fragmentation-from-device-to-schc-gateway" numbe
red="true" toc="default">
<t><list style="symbols"> <name>Uplink Fragmentation: From Device to SCHC Gateway</name>
<t>DevEUI: 0x1122334455667788</t> <t>In this case, the device is the fragment transmitter and the SCHC
<t>appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB</t> gateway is the fragment receiver. A single fragmentation rule is
</list></t> defined. The SCHC F/R <bcp14>MUST</bcp14> concatenate FPort and LoRaW
AN
payload to retrieve the SCHC Packet, as per <xref
target="lorawan-schc-payload" format="default"/>.</t>
<figure title="Example of IID computation." anchor="Fig-iid-computation-example" <dl>
><artwork><![CDATA[
1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A
3. IID: 0xBA59F4B196C6C343
]]></artwork></figure>
<t>There is a small probability of IID collision in a LoRaWAN network. If this o <dt>SCHC fragmentation reliability mode:
ccurs, </dt>
the IID can be changed by rekeying the device at L2 level (ie: trigger a LoRaWAN <dd><tt>ACK-on-Error</tt>.
join). </dd>
The way the device is rekeyed is out of scope of this document and left to the
implementation.</t>
<t>Note: Implementation also using another IID source MUST ensure that the <dt>SCHC header size:
same IID is shared between the device and the SCHC gateway in the </dt>
compression and decompression of the IPv6 address of the device.</t> <dd>2 bytes (the FPort byte + 1 additional byte).
</dd>
</section> <dt>RuleID:
<section anchor="padding" title="Padding"> </dt>
<dd>8 bits stored in the LoRaWAN FPort (cf. <xref target="rule-id-management"
format="default"/>).
</dd>
<t>All padding bits MUST be 0.</t> <dt>DTag:
</dt>
<dd>Size T = 0 bits, not used (cf. <xref target="DTag" format="default"/>).
</dd>
</section> <dt>Window index:
<section anchor="Decomp" title="Decompression"> </dt>
<dd>4 windows are used, encoded on M = 2 bits.
</dd>
<t>SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC Pack <dt>FCN:
et </dt>
as per <xref target="lorawan-schc-payload"/>.</t> <dd>The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles
are allowed in a window.
</dd>
<t>RuleIDs matching FPortUp and FPortDown are reserved for SCHC Fragmentation.</ <dt>Last tile:
t> </dt>
<dd><t>It can be carried in a Regular SCHC Fragment, alone in an All-1 SCHC
Fragment, or with any of these two methods. Implementations must ensure that:</t
>
<ul>
</section> <li>The sender <bcp14>MUST</bcp14> ascertain that the receiver will not
<section anchor="Frag" title="Fragmentation"> receive the last tile through both a Regular SCHC Fragment and an All-1
SCHC Fragment during the same session.
</li>
<li>If the last tile is in an All-1 SCHC Message, the current L2 MTU
<bcp14>MUST</bcp14> be big enough to fit the All-1 header and the last
tile.
</li>
<t>The L2 Word Size used by LoRaWAN is 1 byte (8 bits). </ul>
The SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink </dd>
fragmentation and Ack-Always mode for downlink fragmentation. A LoRaWAN
device cannot support simultaneous interleaved fragmented datagrams in
the same direction (uplink or downlink).</t>
<t>The fragmentation parameters are different for uplink and downlink <dt>Penultimate tile:
fragmented datagrams and are successively described in the next sections.</t> </dt>
<dd><bcp14>MUST</bcp14> be equal to the regular size.
</dd>
<section anchor="DTag" title="DTag"> <dt>RCS:
</dt>
<dd>Use the recommended calculation algorithm in <xref target="RFC8724"
sectionFormat="of" section="8.2.3"/>, Integrity Checking.
</dd>
<t><xref target="RFC8724"></xref> section 8.2.4 describes the possibility to int <dt>Tile:
erleave several </dt>
fragmented SCHC datagrams for the same RuleID. This is not used in SCHC over <dd>Size is 10 bytes.
LoRaWAN profile. A device cannot interleave several fragmented SCHC datagrams </dd>
on the same FPort. This field is not used and its size is 0.</t>
<t>Note: The device can still have several parallel fragmented datagrams with <dt>Retransmission timer:
more than one SCHC gateway thanks to distinct sets of FPorts, cf <xref target="r </dt>
ule-id-management"/>.</t> <dd>Set by the implementation depending on the application
requirements. The default <bcp14>RECOMMENDED</bcp14> duration of this
timer is 12 hours; this value is mainly driven by application requirements
and <bcp14>MAY</bcp14> be changed by the application.
</dd>
</section> <dt>Inactivity timer:
<section anchor="uplink-fragmentation-from-device-to-schc-gateway" title="Uplink </dt>
fragmentation: From device to SCHC gateway"> <dd>The SCHC gateway implements an "inactivity timer". The default
<bcp14>RECOMMENDED</bcp14> duration of this timer is 12 hours; this value
is mainly driven by application requirements and <bcp14>MAY</bcp14> be
changed by the application.
</dd>
<t>In this case, the device is the fragment transmitter, and the SCHC gateway <dt>MAX_ACK_REQUESTS:
the fragment receiver. A single fragmentation rule is defined. </dt>
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC <dd> 8. With this set of parameters, the SCHC Fragment Header is 16 bits,
Packet, as per <xref target="lorawan-schc-payload"/>.</t> including FPort; payload overhead will be 8 bits as FPort is already a
part of LoRaWAN payload. MTU is: 4 windows * 63 tiles * 10 bytes per
tile = 2520 bytes.
</dd>
<t><list style="symbols"> </dl>
<t>SCHC fragmentation reliability mode: <spanx style="verb">ACK-on-Error</span
x>.</t>
<t>SCHC header size is two bytes (the FPort byte + 1 additional byte).</t>
<t>RuleID: 8 bits stored in LoRaWAN FPort. cf <xref target="rule-id-management
"/></t>
<t>DTag: Size T=0 bit, not used. cf <xref target="DTag"/></t>
<t>Window index: 4 windows are used, encoded on M = 2 bits</t>
<t>FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles
are allowed in a window.</t>
<t>Last tile: it can be carried in a Regular SCHC Fragment, alone in an All-1
SCHC
Fragment or with any of these two methods. Implementation must ensure that:
<list style="symbols">
<t>The sender MUST ascertain that the receiver will not receive
the last tile through both a Regular SCHC Fragment and an All-1 SCHC
Fragment during the same session.</t>
<t>If the last tile is in All-1 SCHC message: current L2 MTU MUST be big e
nough to fit
the All-1 header and the last tile.</t>
</list></t>
<t>Penultimate tile MUST be equal to the regular size.</t>
<t>RCS: Use recommended calculation algorithm in <xref target="RFC8724"></xref
> (§8.2.3. Integrity Checking).</t>
<t>Tile: size is 10 bytes.</t>
<t>Retransmission timer: Set by the implementation depending on the applicatio
n
requirements. The default RECOMMENDED duration of this timer is 12 hours;
this value is mainly driven by application requirements and MAY be
changed by the application.</t>
<t>Inactivity timer: The SCHC gateway implements an “inactivity timer”. The
default RECOMMENDED duration of this timer is 12 hours; this value is mainly
driven by application requirements and MAY be changed by the application.</t>
<t>MAX_ACK_REQUESTS: 8.
With this set of parameters, the SCHC fragment header is 16 bits,
including FPort; payload overhead will be 8 bits as FPort is already a part of
LoRaWAN payload. MTU is: <spanx style="emph">4 windows * 63 tiles * 10 bytes per
tile = 2520 bytes</spanx></t>
</list></t>
<t>In addition to the per-rule context parameters specified in <xref target="RFC 8724"></xref>, <t>In addition to the per-rule context parameters specified in <xref t arget="RFC8724" format="default"/>,
for uplink rules, an additional context parameter is added: whether or for uplink rules, an additional context parameter is added: whether or
not to ack after each window.<vspace /> not to ack after each window.
For battery powered devices, it is RECOMMENDED to use the ACK mechanism at the For battery powered devices, it is <bcp14>RECOMMENDED</bcp14> to use the ACK mec
hanism at the
end of each window instead of waiting until the end of all windows:</t> end of each window instead of waiting until the end of all windows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The SCHC receiver <bcp14>SHOULD</bcp14> send a SCHC ACK after ev
<t>The SCHC receiver SHOULD send a SCHC ACK after every window even if there i ery window even if there is no
s no missing tile.</li>
missing tile.</t> <li>The SCHC sender <bcp14>SHOULD</bcp14> wait for the SCHC ACK
<t>The SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver before from the SCHC receiver before sending tiles from the next
sending window. If the SCHC ACK is not received, it <bcp14>SHOULD</bcp14>
tiles from the next window. If the SCHC ACK is not received, it SHOULD send a SC send a SCHC ACK REQ up to MAX_ACK_REQUESTS times, as described
HC previously.</li>
ACK REQ up to MAX_ACK_REQUESTS times, as described previously.</t> </ul>
</list></t> <t>This will avoid useless uplinks if the device has lost network cove
rage.</t>
<t>This will avoid useless uplinks if the device has lost network coverage.</t> <t>For non-battery powered devices, the SCHC receiver
<bcp14>MAY</bcp14> also choose to send a SCHC ACK only at the end
<t>For non-battery powered devices, the SCHC receiver MAY also choose to send a of all windows. This will reduce downlink load on the LoRaWAN
SCHC network by reducing the number of downlinks.</t>
ACK only at the end of all windows. This will reduce downlink load on the LoRaWA <t>SCHC implementations <bcp14>MUST</bcp14> be compatible with both be
N haviors, and this selection is
network, by reducing the number of downlinks.</t>
<t>SCHC implementations MUST be compatible with both behaviors, and this selecti
on is
part of the rule context.</t> part of the rule context.</t>
<section anchor="regular-fragments" numbered="true" toc="default">
<section anchor="regular-fragments" title="Regular fragments"> <name>Regular Fragments</name>
<t><xref target="Fig-fragmentation-header-long-all0" format="default
<figure title="All fragments except the last one. SCHC header size is 16 bits, i "/>
ncluding LoRaWAN FPort." anchor="Fig-fragmentation-header-long-all0"><artwork><! is an example of a regular fragment for all fragments except
[CDATA[ the last one. SCHC Header Size is 16 Bits, including the
LoRaWAN FPort.
</t>
<figure anchor="Fig-fragmentation-header-long-all0">
<name>All Fragments Except the Last One.</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ------------------------- + + ------ + ------------------------- +
| RuleID | W | FCN | Payload | | RuleID | W | FCN | Payload |
+ ------ + ------ + ------ + ------- + + ------ + ------ + ------ + ------- +
| 8 bits | 2 bits | 6 bits | | | 8 bits | 2 bits | 6 bits | |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="last-fragment-all-1" numbered="true" toc="default">
<section anchor="last-fragment-all-1" title="Last fragment (All-1)"> <name>Last Fragment (All-1)</name>
<t>Following figures are examples of All-1 messages. <xref target="F
<figure title="All-1 SCHC Message: the last fragment without last tile." anchor= ig-fragmentation-header-all1-no-tile" format="default"/>
"Fig-fragmentation-header-all1-no-tile"><artwork><![CDATA[ is without the last tile, <xref target="Fig-fragmentation-header-all
1-last-tile" format="default"/>
is with the last tile.
</t>
<figure anchor="Fig-fragmentation-header-all1-no-tile">
<name>All-1 SCHC Message without Last Tile</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ---------------------------- + + ------ + ---------------------------- +
| RuleID | W | FCN=All-1 | RCS | | RuleID | W | FCN=All-1 | RCS |
+ ------ + ------ + --------- + ------- + + ------ + ------ + --------- + ------- +
| 8 bits | 2 bits | 6 bits | 32 bits | | 8 bits | 2 bits | 6 bits | 32 bits |
]]></artwork>
]]></artwork></figure> </figure>
<figure anchor="Fig-fragmentation-header-all1-last-tile">
<figure title="All-1 SCHC Message: the last fragment with last tile." anchor="Fi <name>All-1 SCHC Message with Last Tile</name>
g-fragmentation-header-all1-last-tile"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------------------- + + ------ + ---------------------------------------------------------- +
| RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding | | RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding |
+ ------ + ------ + --------- + ------- + ------------ + ------------ + + ------ + ------ + --------- + ------- + ------------ + ------------ +
| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 0 to 7 bits | | 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 0 to 7 bits |
]]></artwork>
</figure>
</section>
<section anchor="schc-ack" numbered="true" toc="default">
]]></artwork></figure> <name>SCHC ACK</name>
<figure anchor="Fig-frag-header-long-schc-ack-rcs-ok">
</section> <name>SCHC ACK Format - Correct RCS Check</name>
<section anchor="schc-ack" title="SCHC ACK"> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure title="SCHC ACK format, correct RCS check." anchor="Fig-frag-header-long
-schc-ack-rcs-ok"><artwork><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + --------------------------+ + ------ + --------------------------+
| RuleID | W | C = 1 | padding | | RuleID | W | C = 1 | padding |
| | | | (b'00000) | | | | | (b'00000) |
+ ------ + ----- + ----- + --------- + + ------ + ----- + ----- + --------- +
| 8 bits | 2 bit | 1 bit | 5 bits | | 8 bits | 2 bit | 1 bit | 5 bits |
]]></artwork>
]]></artwork></figure> </figure>
<figure anchor="Fig-frag-header-long-schc-ack-rcs-fail">
<figure title="SCHC ACK format, failed RCS check." anchor="Fig-frag-header-long- <name>SCHC ACK Format - Incorrect RCS Check</name>
schc-ack-rcs-fail"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + --------------------------------- + ---------------- + + ------ + --------------------------------- + ---------------- +
| RuleID | W | C = 0 | Compressed bitmap | Optional padding | | RuleID | W | C = 0 | Compressed bitmap | Optional padding |
| | | | (C = 0) | (b'0...0) | | | | | (C = 0) | (b'0...0) |
+ ------ + ----- + ----- + ----------------- + ---------------- + + ------ + ----- + ----- + ----------------- + ---------------- +
| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits | | 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6, or 7 bits |
]]></artwork>
]]></artwork></figure> </figure>
<aside><t>Note: Because of the bitmap compression mechanism and L2 byte alignmen
<t>Note: Because of the bitmap compression mechanism and L2 byte alignment, only t, only
the following discrete values are possible for the compressed bitmap size: 5, 13 the following discrete values are possible for the compressed bitmap size: 5, 13
, 21, 29, 37, 45, 53, 61, 62 and 63. , 21, 29, 37, 45, 53, 61, 62, and 63.
Bitmaps of 63 bits will require 6 bits of padding.</t> Bitmaps of 63 bits will require 6 bits of padding.</t></aside>
</section>
</section> <section anchor="receiver-abort" numbered="true" toc="default">
<section anchor="receiver-abort" title="Receiver-Abort"> <name>Receiver-Abort</name>
<figure anchor="Fig-fragmentation-receiver-abort">
<figure title="Receiver-Abort format." anchor="Fig-fragmentation-receiver-abort" <name>Receiver-Abort Format</name>
><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + -------------------------------------------- + + ------ + -------------------------------------------- +
| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) | | RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |
+ ------ + -------- + ------+-------- + ----------------+ + ------ + -------- + ------+-------- + ----------------+
| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits | | 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> | next L2 Word boundary ->| <-- L2 Word --> |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="schc-acknowledge-request" numbered="true" toc="defaul
<section anchor="schc-acknowledge-request" title="SCHC acknowledge request"> t">
<name>SCHC Acknowledge Request</name>
<figure title="SCHC ACK REQ format." anchor="Fig-fragmentation-schc-ack-req"><ar <figure anchor="Fig-fragmentation-schc-ack-req">
twork><![CDATA[ <name>SCHC ACK REQ Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+------- +------------------------- + +------- +------------------------- +
| RuleID | W | FCN = b'000000 | | RuleID | W | FCN = b'000000 |
+ ------ + ------ + --------------- + + ------ + ------ + --------------- +
| 8 bits | 2 bits | 6 bits | | 8 bits | 2 bits | 6 bits |
]]></artwork>
</figure>
</section>
</section>
<section anchor="downlink-fragmentation-from-schc-gateway-to-device" num
bered="true" toc="default">
<name>Downlink Fragmentation: From SCHC Gateway to Device</name>
<t>In this case, the device is the fragmentation receiver and the
SCHC gateway is the fragmentation transmitter. The following fields ar
e
common to all devices. The SCHC F/R <bcp14>MUST</bcp14> concatenate
FPort and LoRaWAN payload to retrieve the SCHC Packet as described
in <xref target="lorawan-schc-payload" format="default"/>.</t>
]]></artwork></figure> <dl>
</section> <dt>SCHC fragmentation reliability mode:
</section> </dt>
<section anchor="downlink-fragmentation-from-schc-gateway-to-device" title="Down <dd>
link fragmentation: From SCHC gateway to device"> <ul empty="true">
<li>
<dl>
<t>In this case, the device is the fragmentation receiver, and the SCHC gateway <dt >Unicast downlinks:
the </dt>
fragmentation transmitter. The following fields are common to all devices. <dd>ACK-Always.
SCHC F/R MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC </dd>
Packet as described in <xref target="lorawan-schc-payload"/>.</t> <dt>Multicast downlinks:
</dt>
<t><list style="symbols"> <dd>No-ACK; reliability has to be ensured by the upper layer. This feature is
<t>SCHC fragmentation reliability mode: <bcp14>OPTIONAL</bcp14> for the SCHC gateway and <bcp14>REQUIRED</bcp14> for the
<list style="symbols"> device.
<t>Unicast downlinks: ACK-Always.</t> </dd>
<t>Multicast downlinks: No-ACK, reliability has to be ensured by the upper
layer. This feature is OPTIONAL and may not be implemented by SCHC gateway.</t>
</list></t>
<t>RuleID: 8 bits stored in LoRaWAN FPort. cf <xref target="rule-id-management
"/></t>
<t>DTag: Size T=0 bit, not used. cf <xref target="DTag"/></t>
<t>FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile.</t>
<t>RCS: Use recommended calculation algorithm in <xref target="RFC8724"></xref
> (§8.2.3. Integrity Checking).</t>
<t>Inactivity timer: The default RECOMMENDED duration of this timer is 12 hour
s;
this value is mainly driven by application requirements and MAY be changed by
the application.</t>
</list></t>
<t>The following parameters apply to ACK-Always (Unicast) only:</t> </dl>
</li>
</ul>
<t><list style="symbols"> </dd>
<t>Retransmission timer: See <xref target="downlink-retransmission-timer"/>.<
/t>
<t>MAX_ACK_REQUESTS: 8.</t>
<t>Window index (unicast only): encoded on M=1 bit, as per <xref target="RFC87
24"></xref>.</t>
</list></t>
<t>As only 1 tile is used, its size can change for each downlink, and will be <dt>RuleID:
the currently available MTU.</t> </dt>
<dd>8 bits stored in the LoRaWAN FPort (cf. <xref
target="rule-id-management" format="default"/>).
</dd>
<t>Class A devices can only receive during an RX slot, following the transmissio <dt>DTag:
n of an </dt>
uplink. Therefore the SCHC gateway cannot initiate communication (e.g., start a <dd>Size T = 0 bit, not used (cf. <xref target="DTag" format="default"/>).
new SCHC </dd>
session). In order to create a downlink opportunity it is RECOMMENDED for
Class A devices to send an uplink every 24 hours when no SCHC session is
started, this is application specific and can be disabled. The RECOMMENDED uplin
k
is a LoRaWAN empty frame as defined <xref target="lorawan-empty-frame"/>.
As this uplink is to open an RX window, any LoRaWAN uplink frame from the device
MAY reset this counter.</t>
<t><spanx style="emph">Note</spanx>: The Fpending bit included in LoRaWAN protoc <dt>FCN:
ol SHOULD NOT be used for </dt>
SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other <dd>The FCN field is encoded on N = 1 bit, so WINDOW_SIZE = 1 tile.
purposes but not SCHC needs.</t> </dd>
<section anchor="regular-fragments-1" title="Regular fragments"> <dt>RCS:
</dt>
<dd>Use the recommended calculation algorithm in <xref target="RFC8724" sectionF
ormat="of"
format="default" section="8.2.3"/>, Integrity Checking.
</dd>
<figure title="All fragments but the last one. Header size 10 bits, including Lo <dt>Inactivity timer:
RaWAN FPort." anchor="Fig-fragmentation-downlink-header-all0"><artwork><![CDATA[ </dt>
<dd>The default <bcp14>RECOMMENDED</bcp14> duration of this timer is 12 hours;
this value is mainly driven by application requirements and <bcp14>MAY</bcp14>
be changed by the application.
</dd>
</dl>
<t>The following parameters apply to ACK-Always (Unicast) only:</t>
<dl>
<dt>Retransmission timer:
</dt>
<dd>See <xref target="downlink-retransmission-timer" format="default"/>.
</dd>
<dt>MAX_ACK_REQUESTS:
</dt>
<dd>8.
</dd>
<dt>Window index (unicast only):
</dt>
<dd>encoded on M = 1 bit, as per <xref target="RFC8724" format="default"/>.
</dd>
</dl>
<t>As only one tile is used, its size can change for each downlink and
will be the currently available MTU.</t>
<t>Class A devices can only receive during an RX slot, following the
transmission of an uplink. Therefore, the SCHC gateway cannot
initiate communication (e.g., start a new SCHC session). In order to
create a downlink opportunity, it is <bcp14>RECOMMENDED</bcp14> for
Class A devices to send an uplink every 24 hours when no SCHC
session is started; this is application specific and can be
disabled. The <bcp14>RECOMMENDED</bcp14> uplink is a LoRaWAN empty
frame as defined in <xref target="lorawan-empty-frame"
format="default"/>. As this uplink is sent only to open an RX window,
any
LoRaWAN uplink frame from the device <bcp14>MAY</bcp14> reset this
counter.</t>
<aside><t>Note: The FPending bit included in the LoRaWAN protocol <bcp14>SHOULD
NOT</bcp14> be used for the SCHC-over-LoRaWAN protocol. It might be set by the
Network Gateway for other purposes but not SCHC needs.</t></aside>
<section anchor="regular-fragments-1" numbered="true" toc="default">
<name>Regular Fragments</name>
<t><xref target="Fig-fragmentation-downlink-header-all0" format="def
ault"/>
is an example of a regular fragment for all fragments except
the last one. SCHC Header Size is 10 Bits, including the
LoRaWAN FPort.
</t>
<figure anchor="Fig-fragmentation-downlink-header-all0">
<name>All Fragments but the Last One.</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ------------------------------------ + + ------ + ------------------------------------ +
| RuleID | W | FCN = b'0 | Payload | | RuleID | W | FCN = b'0 | Payload |
+ ------ + ----- + --------- + ---------------- + + ------ + ----- + --------- + ---------------- +
| 8 bits | 1 bit | 1 bit | X bytes + 6 bits | | 8 bits | 1 bit | 1 bit | X bytes + 6 bits |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="last-fragment-all-1-1" numbered="true" toc="default">
<section anchor="last-fragment-all-1-1" title="Last fragment (All-1)"> <name>Last Fragment (All-1)</name>
<figure anchor="Fig-fragmentation-downlink-header-all1">
<figure title="All-1 SCHC Message: the last fragment." anchor="Fig-fragmentation <name>All-1 SCHC Message: The Last Fragment</name>
-downlink-header-all1"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + --------------------------- + ------------------------- + + ------ + --------------------------- + ------------------------- +
| RuleID | W | FCN = b'1 | RCS | Payload | Opt padding | | RuleID | W | FCN = b'1 | RCS | Payload | Opt padding |
+ ------ + ----- + --------- + ------- + ----------- + ----------- + + ------ + ----- + --------- + ------- + ----------- + ----------- +
| 8 bits | 1 bit | 1 bit | 32 bits | 6 to X bits | 0 to 7 bits | | 8 bits | 1 bit | 1 bit | 32 bits | 6 to X bits | 0 to 7 bits |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="schc-ack-1" numbered="true" toc="default">
<section anchor="schc-ack-1" title="SCHC ACK"> <name>SCHC ACK</name>
<figure anchor="Fig-frag-downlink-header-schc-ack-rcs-ok">
<figure title="SCHC ACK format, RCS is correct." anchor="Fig-frag-downlink-heade <name>SCHC ACK Format - Correct RCS Check</name>
r-schc-ack-rcs-ok"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ---------------------------------- + + ------ + ---------------------------------- +
| RuleID | W | C = b'1 | Padding b'000000 | | RuleID | W | C = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ---------------- + + ------ + ----- + ------- + ---------------- +
| 8 bits | 1 bit | 1 bit | 6 bits | | 8 bits | 1 bit | 1 bit | 6 bits |
]]></artwork>
]]></artwork></figure> </figure>
<figure anchor="Fig-frag-downlink-header-schc-ack-rcs-fail">
<figure title="SCHC ACK format, RCS is incorrect." anchor="Fig-frag-downlink-hea <name>SCHC ACK Format - Incorrect RCS Check</name>
der-schc-ack-rcs-fail"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ------------------------------------------------- + + ------ + ------------------------------------------------- +
| RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 | | RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ------------ + ---------------- + + ------ + ----- + ------- + ------------ + ---------------- +
| 8 bits | 1 bit | 1 bit | 1 bit | 5 bits | | 8 bits | 1 bit | 1 bit | 1 bit | 5 bits |
]]></artwork>
]]></artwork></figure> </figure>
</section>
</section> <section anchor="receiver-abort-1" numbered="true" toc="default">
<section anchor="receiver-abort-1" title="Receiver-Abort"> <name>Receiver-Abort</name>
<t><xref target="Fig-fragmentation-downlink-header-abort" format="d
<figure title="Receiver-Abort packet (following an All-1 SCHC Fragment with inco efault"/>
rrect RCS)." anchor="Fig-fragmentation-downlink-header-abort"><artwork><![CDATA[ is an example of a Receiver-Abort packet, following an All-1
SCHC Fragment with incorrect RCS.
</t>
<figure anchor="Fig-fragmentation-downlink-header-abort">
<name>Receiver-Abort Packet</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------- + + ------ + ---------------------------------------------- +
| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) | | RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |
+ ------ + ------- + ------- + -------- + --------------- + + ------ + ------- + ------- + -------- + --------------- +
| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits | | 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> | next L2 Word boundary ->| <-- L2 Word --> |
]]></artwork>
</figure>
</section>
<section anchor="downlink-retransmission-timer" numbered="true" toc="d
efault">
<name>Downlink Retransmission Timer</name>
]]></artwork></figure> <t>Class A, Class B, and Class C devices do not manage
retransmissions and timers the same way.</t>
</section>
<section anchor="downlink-retransmission-timer" title="Downlink retransmission t
imer">
<t>Class A and Class B or Class C devices do not manage retransmissions and time
rs
the same way.</t>
<section anchor="class-a-devices" title="Class A devices">
<t>Class A devices can only receive in an RX slot following the transmission of
an
uplink.</t>
<t>The SCHC gateway implements an inactivity timer with a RECOMMENDED duration
of 36 hours. For devices with very low transmission rates (example 1 packet a
day in normal operation), that duration may be extended: it is application
specific.</t>
<t>RETRANSMISSION_TIMER is application specific and its RECOMMENDED value is
INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).</t>
<t><spanx style="strong">SCHC All-0 (FCN=0)</spanx></t>
<t>All fragments but the last have an FCN=0 (because window size is 1). Followi
ng
an All-0 SCHC Fragment, the device MUST transmit the SCHC ACK message. It MUST t
ransmit up to
MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to progress the
fragmented datagram, the SCHC layer should immediately queue for transmission
those SCHC ACK if no SCHC downlink have been received during RX1 and RX2 window.
LoRaWAN layer will respect the applicable local spectrum regulation.</t>
<t><spanx style="emph">Note</spanx>: The ACK bitmap is 1 bit long and is always
1.</t>
<t><spanx style="strong">SCHC All-1 (FCN=1)</spanx></t>
<t>SCHC All-1 is the last fragment of a datagram, the corresponding SCHC ACK
message might be lost; therefore the SCHC gateway MUST request a retransmission
of this ACK when the retransmission timer expires. To open a downlink
opportunity the device MUST transmit an uplink every
RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS * SCHC_ACK_REQ_DN_OPPORTUNITY).
The format of this uplink is application specific. It is RECOMMENDED for a
device to send an empty frame (see <xref target="lorawan-empty-frame"/>) but it
is application
specific and will be used by the NGW to transmit a potential SCHC ACK REQ.<vspac
e />
SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its recommended value
is 2. It MUST be greater than 1. This allows to open a downlink opportunity to
any downlink with higher priority than the SCHC ACK REQ message.</t>
<t><spanx style="emph">Note</spanx>: The device MUST keep this SCHC ACK message
in memory until it receives
a downlink SCHC Fragmentation Message (with FPort == FPortDown) that is not a SC
HC ACK REQ: it indicates that
the SCHC gateway has received the SCHC ACK message.</t>
</section>
</section>
<section anchor="class-b-or-class-c-devices" title="Class B or Class C devices">
<t>Class B devices can receive in scheduled RX slots or in RX slots following th
e
transmission of an uplink. Class C devices are almost in constant reception.</t>
<t>RECOMMENDED retransmission timer value:</t>
<t><list style="symbols">
<t>Class B: 3 times the ping slot periodicity.</t>
<t>Class C: 30 seconds.</t>
</list></t>
<t>The RECOMMENDED inactivity timer value is 12 hours for both Class B and Class
C devices.</t>
</section>
</section>
</section>
<section anchor="schc-fragment-format" title="SCHC Fragment Format">
<section anchor="all-0-schc-fragment" title="All-0 SCHC fragment">
<t><spanx style="strong">Uplink fragmentation (Ack-On-Error)</spanx>:</t>
<t>All-0 is distinguishable from a SCHC ACK REQ as <xref target="RFC8724"></xref <section anchor="class-a-devices" numbered="true" toc="default">
> states <spanx style="emph">This condition <name>Class A Devices</name>
is also met if the SCHC Fragment Header is a multiple of L2 Words</spanx>; this <t>Class A devices can only receive in an RX slot following the
condition met: SCHC header is 2 bytes.</t> transmission of an uplink.</t>
<t>The SCHC gateway implements an inactivity timer with a
<bcp14>RECOMMENDED</bcp14> duration of 36 hours. For devices
with very low transmission rates (for example, 1 packet a day in
normal operation), that duration may be extended; it is
application specific.</t>
<t>RETRANSMISSION_TIMER is application specific and its
<bcp14>RECOMMENDED</bcp14> value is
INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).</t>
<t><strong>SCHC All-0 (FCN = 0)</strong></t>
<t>All fragments but the last have an FCN = 0 (because the window
size
is 1). Following an All-0 SCHC Fragment, the device
<bcp14>MUST</bcp14> transmit the SCHC ACK message. It
<bcp14>MUST</bcp14> transmit up to MAX_ACK_REQUESTS SCHC ACK
messages before aborting. In order to progress the fragmented
datagram, the SCHC layer should immediately queue for
transmission those SCHC ACK messages if no SCHC downlink has been
received during the RX1 and RX2 windows. The LoRaWAN layer will r
espect
the applicable local spectrum regulation.</t>
<t><spanx style="strong">Downlink fragmentation (Ack-always)</spanx>:</t> <aside> <t>Note: The ACK bitmap is 1 bit long and is always 1.</t><
/aside>
<t><strong>SCHC All-1 (FCN = 1)</strong></t>
<t>As per <xref target="RFC8724"></xref> the SCHC All-1 MUST contain the last ti <t>SCHC All-1 is the last fragment of a datagram, and the
le, implementation must corresponding SCHC ACK message might be lost; therefore, the SCHC
ensure that SCHC All-0 message Payload will be at least the size of an L2 Word.< gateway <bcp14>MUST</bcp14> request a retransmission of this ACK
/t> when the retransmission timer expires. To open a downlink
opportunity, the device <bcp14>MUST</bcp14> transmit an uplink
every interval of RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS *
SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is
application specific. It is <bcp14>RECOMMENDED</bcp14> for a
device to send an empty frame (see <xref
target="lorawan-empty-frame" format="default"/>), but it is
application specific and will be used by the NGW to transmit a
potential SCHC ACK REQ. SCHC_ACK_REQ_DN_OPPORTUNITY is
application specific and its recommended value is 2. It
<bcp14>MUST</bcp14> be greater than 1. This allows the opening of
a
downlink opportunity to any downlink with higher priority than
the SCHC ACK REQ message.</t>
<aside> <t>Note: The device <bcp14>MUST</bcp14> keep this SCHC
ACK message in memory until it receives a downlink SCHC
Fragmentation Message (with FPort == FPortDown) that is not a
SCHC ACK REQ; this indicates that the SCHC gateway has received
the SCHC ACK message.</t></aside>
</section>
</section>
<section anchor="class-b-or-class-c-devices" numbered="true" toc="defa
ult">
<name>Class B or Class C Devices</name>
<t>Class B devices can receive in scheduled RX slots or in RX
slots following the transmission of an uplink. Class C devices are
almost in constant reception.</t>
<t><bcp14>RECOMMENDED</bcp14> retransmission timer values are:</t>
</section> <dl>
<section anchor="all-1-schc-fragment" title="All-1 SCHC fragment">
<t>All-1 is distinguishable from a SCHC Sender-Abort as <xref target="RFC8724">< <dt>Class B:
/xref> states <spanx style="emph">This </dt>
condition is met if the RCS is present and is at least the size of an L2 Word</s <dd>3 times the ping slot periodicity.
panx>; </dd>
this condition met: RCS is 4 bytes.</t>
</section> <dt>Class C:
<section anchor="delay-after-each-lorawan-frame-to-respect-local-regulation" tit </dt>
le="Delay after each LoRaWAN frame to respect local regulation"> <dd>30 seconds.
</dd>
<t>This profile does not define a delay to be added after each LoRaWAN frame, lo </dl>
cal
regulation compliance is expected to be enforced by LoRaWAN stack.</t>
</section> <t>The <bcp14>RECOMMENDED</bcp14> inactivity timer value is 12
</section> hours for both Class B and Class C devices.</t>
</section> </section>
<section anchor="security-considerations" title="Security Considerations"> </section>
</section>
<section anchor="schc-fragment-format" numbered="true" toc="default">
<name>SCHC Fragment Format</name>
<section anchor="all-0-schc-fragment" numbered="true" toc="default">
<name>All-0 SCHC Fragment</name>
<t><strong>Uplink Fragmentation (Ack-on-Error)</strong>:</t>
<t>All-0 is distinguishable from a SCHC ACK REQ, as <xref
target="RFC8724" format="default"/> states "This condition is also
met if the SCHC Fragment Header is a multiple of L2 Words", the
following condition being met: SCHC header is 2 bytes.</t>
<t><strong>Downlink fragmentation (ACK-Always)</strong>:</t>
<t>As per <xref target="RFC8724" format="default"/>, SCHC All-1
<bcp14>MUST</bcp14> contain the last tile, and implementations
<bcp14>MUST</bcp14> ensure that SCHC All-0 message Payload will be
at least the size of an L2 Word.</t>
</section>
<section anchor="all-1-schc-fragment" numbered="true" toc="default">
<name>All-1 SCHC Fragment</name>
<t>All-1 is distinguishable from a SCHC Sender-Abort, as <xref
target="RFC8724" format="default"/> states "This condition is met
if the RCS is present and is at least the size of an L2 Word",
the following condition being met: RCS is 4 bytes.</t>
</section>
<section anchor="delay-after-each-lorawan-frame-to-respect-local-regulat
ion" numbered="true" toc="default">
<name>Delay after Each LoRaWAN Frame to Respect Local Regulation</name
>
<t>This profile does not define a delay to be added after each
LoRaWAN frame; local regulation compliance is expected to be
enforced by the LoRaWAN stack.</t>
</section>
<t>This document is only providing parameters that are expected to be best </section>
suited for LoRaWAN networks for <xref target="RFC8724"></xref>. IID </section>
security is discussed in <xref target="IID"/>. As such, this document does not c <section anchor="security-considerations" numbered="true" toc="default">
ontribute to <name>Security Considerations</name>
<t>This document is only providing parameters that are expected to be best
suited for LoRaWAN networks for <xref target="RFC8724" format="default"/>. IID
security is discussed in <xref target="IID" format="default"/>. As such, this do
cument does not contribute to
any new security issues beyond those already identified in any new security issues beyond those already identified in
<xref target="RFC8724"></xref>. <xref target="RFC8724" format="default"/>.
Moreover, SCHC data (LoRaWAN payload) are protected at the LoRaWAN level by an A ES-128 Moreover, SCHC data (LoRaWAN payload) are protected at the LoRaWAN level by an A ES-128
encryption with a session key shared by the device and the SCHC gateway. These s ession keys are renewed at each encryption with a session key shared by the device and the SCHC gateway. These s ession keys are renewed at each
LoRaWAN session (ie: each join or rejoin to the LoRaWAN network)</t> LoRaWAN session (i.e., each join or rejoin to the LoRaWAN network).</t>
</section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
<t>This document has no IANA actions.</t> </section>
</section>
<section numbered="false" anchor="acknowledgements" title="Acknowledgements">
<t>Thanks to all those listed in the Contributors section for the excellent text
,
insightful discussions, reviews and suggestions, and also to (in
alphabetical order) Dominique Barthel, Arunprabhu Kandasamy, Rodrigo Muñoz,
Alexander Pelov, Pascal Thubert, Laurent Toutain for useful design
considerations, reviews and comments.</t>
</section>
<section numbered="false" anchor="contributors" title="Contributors">
<t>Contributors ordered by family name.</t>
<t>Vincent Audebert<vspace />
EDF R&amp;D<vspace />
Email: vincent.audebert@edf.fr</t>
<t>Julien Catalano<vspace />
Kerlink<vspace />
Email: j.catalano@kerlink.fr</t>
<t>Michael Coracin<vspace />
Semtech<vspace />
Email: mcoracin@semtech.com</t>
<t>Marc Le Gourrierec<vspace />
Sagemcom<vspace />
Email: marc.legourrierec@sagemcom.com</t>
<t>Nicolas Sornin<vspace />
Semtech<vspace />
Email: nsornin@semtech.com</t>
<t>Alper Yegin<vspace />
Actility<vspace />
Email: alper.yegin@actility.com</t>
</section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4493.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8724.xml"/>
<references title='Normative References'> <reference anchor="LORAWAN-SPEC" target="https://lora-alliance.org/resou
rce_hub/lorawan-104-specification-package/">
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> <front>
<front> <title>LoRaWAN 1.0.4 Specification Package</title>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <author>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ <organization>LoRa Alliance</organization>
author> </author>
<date year='1997' month='March' /> <date/>
<abstract><t>In many standards track documents several words are used to signify </front>
the requirements in the specification. These words are often capitalized. This </reference>
document defines these words as they should be interpreted in IETF documents. </references>
This document specifies an Internet Best Current Practices for the Internet Comm <references>
unity, and requests discussion and suggestions for improvements.</t></abstract> <name>Informative References</name>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='BCP' value='14'/> FC.8064.xml"/>
<seriesInfo name='RFC' value='2119'/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name='DOI' value='10.17487/RFC2119'/> FC.8065.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8376.xml"/>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC4291" target='https://www.rfc-editor.org/info/rfc4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials='R.' surname='Hinden' fullname='R. Hinden'><organization /></au
thor>
<author initials='S.' surname='Deering' fullname='S. Deering'><organization /></
author>
<date year='2006' month='February' />
<abstract><t>This specification defines the addressing architecture of the IP Ve
rsion 6 (IPv6) protocol. The document includes the IPv6 addressing model, text
representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast
addresses, and multicast addresses, and an IPv6 node's required addresses.</t><
t>This document obsoletes RFC 3513, &quot;IP Version 6 Addressing Architecture&q
uot;. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4291'/>
<seriesInfo name='DOI' value='10.17487/RFC4291'/>
</reference>
<reference anchor="RFC4493" target='https://www.rfc-editor.org/info/rfc4493'>
<front>
<title>The AES-CMAC Algorithm</title>
<author initials='JH.' surname='Song' fullname='JH. Song'><organization /></auth
or>
<author initials='R.' surname='Poovendran' fullname='R. Poovendran'><organizatio
n /></author>
<author initials='J.' surname='Lee' fullname='J. Lee'><organization /></author>
<author initials='T.' surname='Iwata' fullname='T. Iwata'><organization /></auth
or>
<date year='2006' month='June' />
<abstract><t>The National Institute of Standards and Technology (NIST) has recen
tly specified the Cipher-based Message Authentication Code (CMAC), which is equi
valent to the One-Key CBC MAC1 (OMAC1) submitted by Iwata and Kurosawa. This me
mo specifies an authentication algorithm based on CMAC with the 128-bit Advanced
Encryption Standard (AES). This new authentication algorithm is named AES-CMAC.
The purpose of this document is to make the AES-CMAC algorithm conveniently ava
ilable to the Internet Community. This memo provides information for the Intern
et community.</t></abstract>
</front>
<seriesInfo name='RFC' value='4493'/>
<seriesInfo name='DOI' value='10.17487/RFC4493'/>
</reference>
<reference anchor="RFC8724" target='https://www.rfc-editor.org/info/rfc8724'>
<front>
<title>SCHC: Generic Framework for Static Context Header Compression and Fragmen
tation</title>
<author initials='A.' surname='Minaburo' fullname='A. Minaburo'><organization />
</author>
<author initials='L.' surname='Toutain' fullname='L. Toutain'><organization /></
author>
<author initials='C.' surname='Gomez' fullname='C. Gomez'><organization /></auth
or>
<author initials='D.' surname='Barthel' fullname='D. Barthel'><organization /></
author>
<author initials='JC.' surname='Zúñiga' fullname='JC. Zúñiga'><organization /></
author>
<date year='2020' month='April' />
<abstract><t>This document defines the Static Context Header Compression and fra
gmentation (SCHC) framework, which provides both a header compression mechanism
and an optional fragmentation mechanism. SCHC has been designed with Low-Power W
ide Area Networks (LPWANs) in mind.</t><t>SCHC compression is based on a common
static context stored both in the LPWAN device and in the network infrastructure
side. This document defines a generic header compression mechanism and its appl
ication to compress IPv6/UDP headers.</t><t>This document also specifies an opti
onal fragmentation and reassembly mechanism. It can be used to support the IPv6
MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 da
tagrams that, after SCHC compression or when such compression was not possible,
still exceed the Layer 2 maximum payload size.</t><t>The SCHC header compression
and fragmentation mechanisms are independent of the specific LPWAN technology o
ver which they are used. This document defines generic functionalities and offer
s flexibility with regard to parameter settings and mechanism choices. This docu
ment standardizes the exchange over the LPWAN between two SCHC entities. Setting
s and choices specific to a technology or a product are expected to be grouped i
nto profiles, which are specified in other documents. Data models for the contex
t and profiles are out of scope.</t></abstract>
</front>
<seriesInfo name='RFC' value='8724'/>
<seriesInfo name='DOI' value='10.17487/RFC8724'/>
</reference>
<reference anchor="lora-alliance-spec" target="https://lora-alliance.org/resourc
e_hub/lorawan-104-specification-package/">
<front>
<title>LoRaWAN Specification Version V1.0.4</title>
<author initials="L." surname="Alliance" fullname="LoRa Alliance">
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
<references title='Informative References'>
<reference anchor="RFC8064" target='https://www.rfc-editor.org/info/rfc8064'>
<front>
<title>Recommendation on Stable IPv6 Interface Identifiers</title>
<author initials='F.' surname='Gont' fullname='F. Gont'><organization /></author
>
<author initials='A.' surname='Cooper' fullname='A. Cooper'><organization /></au
thor>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></au
thor>
<author initials='W.' surname='Liu' fullname='W. Liu'><organization /></author>
<date year='2017' month='February' />
<abstract><t>This document changes the recommended default Interface Identifier
(IID) generation scheme for cases where Stateless Address Autoconfiguration (SLA
AC) is used to generate a stable IPv6 address. It recommends using the mechanism
specified in RFC 7217 in such cases, and recommends against embedding stable li
nk-layer addresses in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 24
70, RFC 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC 43
38, RFC 4391, RFC 5072, and RFC 5121. This document does not change any existin
g recommendations concerning the use of temporary addresses as specified in RFC
4941.</t></abstract>
</front>
<seriesInfo name='RFC' value='8064'/>
<seriesInfo name='DOI' value='10.17487/RFC8064'/>
</reference>
<reference anchor="RFC8065" target='https://www.rfc-editor.org/info/rfc8065'>
<front>
<title>Privacy Considerations for IPv6 Adaptation-Layer Mechanisms</title>
<author initials='D.' surname='Thaler' fullname='D. Thaler'><organization /></au
thor>
<date year='2017' month='February' />
<abstract><t>This document discusses how a number of privacy threats apply to te
chnologies designed for IPv6 over various link-layer protocols, and it provides
advice to protocol designers on how to address such threats in adaptation-layer
specifications for IPv6 over such links.</t></abstract>
</front>
<seriesInfo name='RFC' value='8065'/>
<seriesInfo name='DOI' value='10.17487/RFC8065'/>
</reference>
<reference anchor="RFC8376" target='https://www.rfc-editor.org/info/rfc8376'> <reference anchor="LORAWAN-REMOTE-MULTICAST-SET" target="https://lora-al
<front> liance.org/resource_hub/lorawan-remote-multicast-setup-specification-v1-0-0/">
<title>Low-Power Wide Area Network (LPWAN) Overview</title> <front>
<author initials='S.' surname='Farrell' fullname='S. Farrell' role='editor'><org <title>LoRaWAN Remote Multicast Setup Specification v1.0.0</title>
anization /></author> <author>
<date year='2018' month='May' /> <organization>LoRa Alliance</organization>
<abstract><t>Low-Power Wide Area Networks (LPWANs) are wireless technologies wit </author>
h characteristics such as large coverage areas, low bandwidth, possibly very sma <date/>
ll packet and application-layer data sizes, and long battery life operation. Th </front>
is memo is an informational overview of the set of LPWAN technologies being cons </reference>
idered in the IETF and of the gaps that exist between the needs of those technol
ogies and the goal of running IP in LPWANs.</t></abstract>
</front>
<seriesInfo name='RFC' value='8376'/>
<seriesInfo name='DOI' value='10.17487/RFC8376'/>
</reference>
<reference anchor="lora-alliance-remote-multicast-set" target="https://lora-alli </references>
ance.org/sites/default/files/2018-09/remote_multicast_setup_v1.0.0.pdf">
<front>
<title>LoRaWAN Remote Multicast Setup Specification Version 1.0.0</title>
<author initials="L." surname="Alliance" fullname="LoRa Alliance">
<organization></organization>
</author>
<date />
</front>
</reference>
</references> </references>
<section anchor="examples" numbered="true" toc="default">
<name>Examples</name>
<t>In the following examples, "applicative data" refers to the IPv6 payloa
d
sent by the application to the SCHC layer.</t>
<section anchor="uplink-compression-example-no-fragmentation" numbered="tr
ue" toc="default">
<name>Uplink - Compression Example - No Fragmentation</name>
<t>This example represents an applicative data going through SCHC over
LoRaWAN; no fragmentation required.</t>
<t>An applicative data of 78 bytes is passed to the SCHC compression
layer. Rule 1 is used by the SCHC C/D layer, allowing to compress it
to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes
payload.</t>
<section anchor="examples" title="Examples"> <figure anchor="Fig-example-uplink-no-fragmentation-payload-schc-message
">
<t>In following examples “applicative data” refers to the IPv6 payload sent by t <name>Uplink Example: SCHC Message</name>
he <artwork name="" type="" align="left" alt=""><![CDATA[
application to the SCHC layer.</t>
<section anchor="uplink-compression-example-no-fragmentation" title="Uplink - Co
mpression example - No fragmentation">
<t>This example represents an applicative data going through SCHC over LoRaWAN,
no fragmentation required</t>
<t>An applicative data of 78 bytes is passed to SCHC compression layer. Rule 1
is used by SCHC C/D layer, allowing to compress it to 40 bytes and 5 bits: 1 byt
e
RuleID, 21 bits residue + 37 bytes payload.</t>
<figure title="Uplink example: SCHC Message" anchor="Fig-example-uplink-no-fragm
entation-payload-schc-message"><artwork><![CDATA[
| RuleID | Compression residue | Payload | Padding=b'000 | | RuleID | Compression residue | Payload | Padding=b'000 |
+ ------ + ------------------- + --------- + ------------- + + ------ + ------------------- + --------- + ------------- +
| 1 | 21 bits | 37 bytes | 3 bits | | 1 | 21 bits | 37 bytes | 3 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used by <t>The current LoRaWAN MTU is 51 bytes, although 2-byte FOpts are
LoRaWAN protocol: 49 bytes are available for SCHC payload; no need for used by the LoRaWAN protocol: 49 bytes are available for SCHC payload; n
fragmentation. The payload will be transmitted through FPort = 1.</t> o
need for fragmentation. The payload will be transmitted through FPort
= 1.</t>
<figure title="Uplink example: LoRaWAN packet" anchor="Fig-example-uplink-no-fra <figure anchor="Fig-example-uplink-no-fragmentation-compression">
gmentation-compression"><artwork><![CDATA[ <name>Uplink Example: LoRaWAN Packet</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (40 bytes) | | LoRaWAN Header | LoRaWAN payload (40 bytes) |
+ ------------------------- + --------------------------------------- + + ------------------------- + --------------------------------------- +
| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 | | | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |
| | | | residue | | | | | | | residue | | |
+ ---- + ------- + -------- + ----------- + --------- + ------------- + + ---- + ------- + -------- + ----------- + --------- + ------------- +
| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits | | XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="uplink-compression-and-fragmentation-example" title="Uplink - C <section anchor="uplink-compression-and-fragmentation-example" numbered="t
ompression and fragmentation example"> rue" toc="default">
<name>Uplink - Compression and Fragmentation Example</name>
<t>This example represents an applicative data going through SCHC, with <t>This example represents an applicative data going through SCHC, with
fragmentation.</t> fragmentation.</t>
<t>An applicative data of 300 bytes is passed to the SCHC compression la
<t>An applicative data of 300 bytes is passed to SCHC compression layer. Rule 1 yer. Rule 1
is used by SCHC C/D layer, allowing to compress it to 282 bytes and 5 bits: 1 b is used by the SCHC C/D layer, allowing to compress it to 282 bytes and 5 bits:
yte 1 byte
RuleID, 21 bits residue + 279 bytes payload.</t> RuleID, 21 bits residue + 279 bytes payload.</t>
<figure anchor="Fig-example-uplink-fragmentation-schc-message">
<figure title="Uplink example: SCHC Message" anchor="Fig-example-uplink-fragment <name>Uplink Example: SCHC Message</name>
ation-schc-message"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- +
| 1 | 21 bits | 279 bytes | | 1 | 21 bits | 279 bytes |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by LoRaWAN <t>The current LoRaWAN MTU is 11 bytes; 0-byte FOpts are used by
protocol: 11 bytes are available for SCHC payload + 1 byte FPort field. the LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte
SCHC header is 2 bytes (including FPort) so 1 tile is sent in first FPort field. The SCHC header is 2 bytes (including FPort), so 1 tile is
fragment.</t> sent in the first fragment.</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-1">
<figure title="Uplink example: LoRaWAN packet 1" anchor="Fig-example-uplink-frag <name>Uplink Example: LoRaWAN Packet 1</name>
mentation-lorawan-packet-1"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (11 bytes) | | LoRaWAN Header | LoRaWAN payload (11 bytes) |
+ -------------------------- + -------------------------- + + -------------------------- + -------------------------- +
| | RuleID=20 | W | FCN | 1 tile | | | RuleID=20 | W | FCN | 1 tile |
+ -------------- + --------- + ----- + ------ + --------- + + -------------- + --------- + ----- + ------ + --------- +
| XXXX | 1 byte | 0 0 | 62 | 10 bytes | | XXXX | 1 byte | 0 0 | 62 | 10 bytes |
]]></artwork></figure> ]]></artwork>
</figure>
<figure title="Uplink example: LoRaWAN packet 1 - Tile content" anchor="Fig-exam <t>The tile content is described in <xref target="Fig-example-uplink-fra
ple-uplink-fragmentation-lorawan-packet-1-tile-content"><artwork><![CDATA[ gmentation-lorawan-packet-1-tile-content" format="default"/>
</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-1-tile-c
ontent">
<name>Uplink Example: First Tile Content</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
Content of the tile is: Content of the tile is:
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + ----------------- + + ------ + ------------------- + ----------------- +
| 1 | 21 bits | 6 bytes + 3 bits | | 1 | 21 bits | 6 bytes + 3 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by <t>Next transmission MTU is 11 bytes, although 2-byte FOpts are used
LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte FPort by the LoRaWAN protocol: 9 bytes are available for SCHC payload + 1
field, a tile does not fit inside so LoRaWAN stack will send only FOpts.</t> byte FPort field, a tile does not fit inside so the LoRaWAN stack will
send only FOpts.</t>
<t>Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are transmitted:< <t>Next transmission MTU is 242 bytes, 4-byte FOpts. 23 tiles are transm
/t> itted:</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-2">
<figure title="Uplink example: LoRaWAN packet 2" anchor="Fig-example-uplink-frag <name>Uplink Example: LoRaWAN Packet 2</name>
mentation-lorawan-packet-2"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (231 bytes) | | LoRaWAN Header | LoRaWAN payload (231 bytes) |
+ --------------------------------------+ --------------------------- + + --------------------------------------+ --------------------------- +
| | FOpts | RuleID=20 | W | FCN | 23 tiles | | | FOpts | RuleID=20 | W | FCN | 23 tiles |
+ -------------- + ------- + ---------- + ----- + ----- + ----------- + + -------------- + ------- + ---------- + ----- + ----- + ----------- +
| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes | | XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |
]]></artwork></figure> ]]></artwork>
</figure>
<t>Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles are <t>Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles a
re
transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for transmitted, the last tile is only 2 bytes + 5 bits. Padding is added for
the remaining 3 bits.</t> the remaining 3 bits.</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-3">
<figure title="Uplink example: LoRaWAN packet 3" anchor="Fig-example-uplink-frag <name>Uplink Example: LoRaWAN Packet 3</name>
mentation-lorawan-packet-3"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (44 bytes) | | LoRaWAN Header | LoRaWAN payload (44 bytes) |
+ ---- + ---------- + ----------------------------------------------- + + ---- + ---------- + ----------------------------------------------- +
| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 | | | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 |
+ ---- + ---------- + ----- + ----- + --------------- + ------------- + + ---- + ---------- + ----- + ----- + --------------- + ------------- +
| XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits | | XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>Then All-1 message can be transmitted:</t> <t>Then All-1 message can be transmitted:</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-4">
<figure title="Uplink example: LoRaWAN packet 4 - All-1 SCHC message" anchor="Fi <name>Uplink Example: LoRaWAN Packet 4 - All-1 SCHC Message</name>
g-example-uplink-fragmentation-lorawan-packet-4"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (44 bytes) | | LoRaWAN Header | LoRaWAN payload (44 bytes) |
+ ---- + -----------+ -------------------------- + + ---- + -----------+ -------------------------- +
| | RuleID=20 | W | FCN | RCS | | | RuleID=20 | W | FCN | RCS |
+ ---- + ---------- + ----- + ----- + ---------- + + ---- + ---------- + ----- + ----- + ---------- +
| XXXX | 1 byte | 0 0 | 63 | 4 bytes | | XXXX | 1 byte | 0 0 | 63 | 4 bytes |
]]></artwork></figure> ]]></artwork>
</figure>
<t>All packets have been received by the SCHC gateway, computed RCS is <t>All packets have been received by the SCHC gateway, computed RCS is
correct so the following ACK is sent to the device by the SCHC receiver:</t> correct so the following ACK is sent to the device by the SCHC receiver:</t>
<figure anchor="Fig-example-uplink-fragmentation-lorawan-packet-5">
<figure title="Uplink example: LoRaWAN packet 5 - SCHC ACK" anchor="Fig-example- <name>Uplink Example: LoRaWAN Packet 5 - SCHC ACK</name>
uplink-fragmentation-lorawan-packet-5"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload | | LoRaWAN Header | LoRaWAN payload |
+ -------------- + --------- + ------------------- + + -------------- + --------- + ------------------- +
| | RuleID=20 | W | C | Padding | | | RuleID=20 | W | C | Padding |
+ -------------- + --------- + ----- + - + ------- + + -------------- + --------- + ----- + - + ------- +
| XXXX | 1 byte | 0 0 | 1 | 5 bits | | XXXX | 1 byte | 0 0 | 1 | 5 bits |
]]></artwork></figure> ]]></artwork>
</figure>
</section> </section>
<section anchor="downlink" title="Downlink"> <section anchor="downlink" numbered="true" toc="default">
<name>Downlink</name>
<t>An applicative data of 155 bytes is passed to SCHC compression layer. Rule 1 <t>An applicative data of 155 bytes is passed to the SCHC compression la
is used by SCHC C/D layer, allowing to compress it to 130 bytes and 5 bits: 1 by yer. Rule 1
te is used by the SCHC C/D layer, allowing to compress it to 130 bytes and 5 bits:
1 byte
RuleID, 21 bits residue + 127 bytes payload.</t> RuleID, 21 bits residue + 127 bytes payload.</t>
<figure anchor="Fig-example-downlink-fragmentation-schc-message">
<figure title="Downlink example: SCHC Message" anchor="Fig-example-downlink-frag <name>Downlink Example: SCHC Message</name>
mentation-schc-message"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- +
| 1 | 21 bits | 127 bytes | | 1 | 21 bits | 127 bytes |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN <t>The current LoRaWAN MTU is 51 bytes; no FOpts are used by the
protocol: 51 bytes are available for SCHC payload + FPort field =&gt; it LoRaWAN protocol: 51 bytes are available for SCHC payload + FPort
has to be fragmented.</t> field; the applicative data has to be fragmented.</t>
<figure title="Downlink example: LoRaWAN packet 1 - SCHC Fragment 1" anchor="Fig <figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-1">
-example-downlink-fragmentation-lorawan-packet-1"><artwork><![CDATA[ <name>Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (51 bytes) | | LoRaWAN Header | LoRaWAN payload (51 bytes) |
+ ---- + ---------- + -------------------------------------- + + ---- + ---------- + -------------------------------------- +
| | RuleID=21 | W = 0 | FCN = 0 | 1 tile | | | RuleID=21 | W = 0 | FCN = 0 | 1 tile |
+ ---- + ---------- + ------ + ------- + ------------------- + + ---- + ---------- + ------ + ------- + ------------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits | | XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>Content of the tile is:</t> <t>The tile content is described in <xref target="Fig-example-downlink-f
ragmentation-lorawan-packet-1-tile-content" format="default"/>
</t>
<figure title="Downlink example: LoRaWAN packet 1: Tile content" anchor="Fig-exa <figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-1-tile
mple-downlink-fragmentation-lorawan-packet-1-tile-content"><artwork><![CDATA[ -content">
<name>Downlink Example: First Tile Content</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + ------------------ + + ------ + ------------------- + ------------------ +
| 1 | 21 bits | 48 bytes and 1 bit | | 1 | 21 bits | 48 bytes and 1 bit |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The receiver answers with a SCHC ACK:</t> <t>The receiver answers with a SCHC ACK:</t>
<figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-2">
<figure title="Downlink example: LoRaWAN packet 2 - SCHC ACK" anchor="Fig-examp <name>Downlink Example: LoRaWAN Packet 2 - SCHC ACK</name>
le-downlink-fragmentation-lorawan-packet-2"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload | | LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- + + ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- + + ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | | XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The second downlink is sent, two FOpts:</t> <t>The second downlink is sent, two FOpts:</t>
<figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-3">
<figure title="Downlink example: LoRaWAN packet 3 - SCHC Fragment 2" anchor="Fig <name>Downlink Example: LoRaWAN Packet 3 - SCHC Fragment 2</name>
-example-downlink-fragmentation-lorawan-packet-3"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (49 bytes) | | LoRaWAN Header | LoRaWAN payload (49 bytes) |
+ --------------------------- + ------------------------------------- + + --------------------------- + ------------------------------------- +
| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile | | | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |
+ ---- + ------- + ---------- + ----- + ------- + ------------------- + + ---- + ------- + ---------- + ----- + ------- + ------------------- +
| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits | | XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The receiver answers with an SCHC ACK:</t> <t>The receiver answers with a SCHC ACK:</t>
<figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-4">
<figure title="Downlink example: LoRaWAN packet 4 - SCHC ACK" anchor="Fig-examp <name>Downlink Example: LoRaWAN Packet 4 - SCHC ACK</name>
le-downlink-fragmentation-lorawan-packet-4"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload | | LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- + + ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 | | | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- + + ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | | XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The last downlink is sent, no FOpts:</t> <t>The last downlink is sent, no FOpts:</t>
<figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-5">
<figure title="Downlink example: LoRaWAN packet 5 - All-1 SCHC message" anchor=" <name>Downlink Example: LoRaWAN Packet 5 - All-1 SCHC Message</name>
Fig-example-downlink-fragmentation-lorawan-packet-5"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload (37 bytes) | | LoRaWAN Header | LoRaWAN payload (37 bytes) |
+ ---- + ------- + --------------------------------------------------- + + ---- + ------- + -------------------------------------------------- +
| | RuleID | W | FCN | RCS | 1 tile | Padding | | | RuleID | W | FCN | RCS | 1 tile | Padding |
| | 21 | 0 | 1 | | | b'00000 | | | 21 | 0 | 1 | | | b'00000 |
+ ---- + ------- + ----- + ----- + ------- + --------------- + ------- + + ---- + ------- + ----- + ----- + ------- + -------------- + ------- +
| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bits | 5 bits | | XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bit | 5 bits |
]]></artwork></figure> ]]></artwork>
</figure>
<t>The receiver answers to the sender with an SCHC ACK:</t> <t>The receiver answers to the sender with a SCHC ACK:</t>
<figure anchor="Fig-example-downlink-fragmentation-lorawan-packet-6">
<figure title="Downlink example: LoRaWAN packet 6 - SCHC ACK" anchor="Fig-exampl <name>Downlink Example: LoRaWAN Packet 6 - SCHC ACK</name>
e-downlink-fragmentation-lorawan-packet-6"><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
| LoRaWAN Header | LoRaWAN payload | | LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- + + ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 | | | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- + + ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits | | XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
]]></artwork></figure> ]]></artwork>
</figure>
</section>
</section>
</section> <section numbered="false" anchor="acknowledgements" toc="default">
</section> <name>Acknowledgements</name>
<t>Thanks to all those listed in the Contributors Section for the
excellent text, insightful discussions, reviews, and suggestions, and
also to (in alphabetical order) <contact fullname="Dominique Barthel"/>,
<contact fullname="Arunprabhu Kandasamy"/>, <contact fullname="Rodrigo
Munoz"/>, <contact fullname="Alexander Pelov"/>, <contact
fullname="Pascal Thubert"/>, and <contact fullname="Laurent Toutain"/> for
useful design considerations, reviews, and comments.</t>
<t>LoRaWAN is a registered trademark of the LoRa Alliance.</t>
</section>
</back> <section numbered="false" anchor="contributors" toc="default">
<name>Contributors</name>
<t>Contributors ordered by family name.</t>
<contact fullname="Vincent Audebert">
<organization>EDF R&amp;D</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>vincent.audebert@edf.fr</email>
</address>
</contact>
<contact fullname="Julien Catalano">
<organization>Kerlink</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>j.catalano@kerlink.fr</email>
</address>
</contact>
<contact fullname="Michael Coracin">
<organization>Semtech</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>mcoracin@semtech.com</email>
</address>
</contact>
<contact fullname="Marc Le Gourrierec">
<organization>Sagemcom</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>marc.legourrierec@sagemcom.com</email>
</address>
</contact>
<contact fullname="Nicolas Sornin">
<organization>Chirp Foundation</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>nicolas.sornin@chirpfoundation.org</email>
</address>
</contact>
<contact fullname="Alper Yegin">
<organization>Actility</organization>
<address>
<postal>
<city></city>
<country></country>
</postal>
<email>alper.yegin@actility.com</email>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 172 change blocks. 
1161 lines changed or deleted 1356 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/