< draft-ietf-lpwan-schc-over-lorawan-07.txt   draft-ietf-lpwan-schc-over-lorawan-08.txt >
lpwan Working Group O. Gimenez, Ed. lpwan Working Group O. Gimenez, Ed.
Internet-Draft Semtech Internet-Draft Semtech
Intended status: Informational I. Petrov, Ed. Intended status: Informational I. Petrov, Ed.
Expires: October 19, 2020 Acklio Expires: January 13, 2021 Acklio
April 17, 2020 July 12, 2020
Static Context Header Compression (SCHC) over LoRaWAN Static Context Header Compression (SCHC) over LoRaWAN
draft-ietf-lpwan-schc-over-lorawan-07 draft-ietf-lpwan-schc-over-lorawan-08
Abstract Abstract
The Static Context Header Compression (SCHC) specification describes The Static Context Header Compression (SCHC) specification describes
generic header compression and fragmentation techniques for LPWAN generic header compression and fragmentation techniques for LPWAN
(Low Power Wide Area Networks) technologies. SCHC is a generic (Low Power Wide Area Networks) technologies. SCHC is a generic
mechanism designed for great flexibility so that it can be adapted mechanism designed for great flexibility so that it can be adapted
for any of the LPWAN technologies. for any of the LPWAN technologies.
This document provides the adaptation of SCHC for use in LoRaWAN This document provides the adaptation of SCHC for use in LoRaWAN
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2020. This Internet-Draft will expire on January 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Static Context Header Compression Overview . . . . . . . . . 3 3. Static Context Header Compression Overview . . . . . . . . . 4
4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5 4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5
4.1. End-Device classes (A, B, C) and interactions . . . . . . 6 4.1. Device classes (A, B, C) and interactions . . . . . . . . 6
4.2. End-Device addressing . . . . . . . . . . . . . . . . . . 7 4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 7
4.3. General Message Types . . . . . . . . . . . . . . . . . . 7 4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 7
4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8 4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8
4.5. Unicast and multicast technology . . . . . . . . . . . . 8 4.5. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 8
4.6. Unicast and multicast technology . . . . . . . . . . . . 8
5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8 5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8
5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8 5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9 5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9
5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10 5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10
5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11 5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11 5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11
5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11 5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11
5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12 5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12
5.6.3. Downlink fragmentation: From SCHC gateway to a device 15 5.6.3. Downlink fragmentation: From SCHC gateway to device . 15
5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 18
5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 18
5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 18
5.7.3. Delay after each message to respect local regulation 18
6. Security considerations . . . . . . . . . . . . . . . . . . . 18 6. Security considerations . . . . . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Uplink - Compression example - No fragmentation . . . . . 21 A.1. Uplink - Compression example - No fragmentation . . . . . 21
A.2. Uplink - Compression and fragmentation example . . . . . 21 A.2. Uplink - Compression and fragmentation example . . . . . 22
A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23 A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The Static Context Header Compression (SCHC) specification [RFC8724] The Static Context Header Compression (SCHC) specification [RFC8724]
describes generic header compression and fragmentation techniques describes generic header compression and fragmentation techniques
that can be used on all LPWAN (Low Power Wide Area Networks) that can be used on all LPWAN (Low Power Wide Area Networks)
technologies defined in [RFC8376]. Even though those technologies technologies defined in [RFC8376]. Even though those technologies
share a great number of common features like star-oriented share a great number of common features like star-oriented
topologies, network architecture, devices with mostly quite topologies, network architecture, devices with mostly quite
predictable communications, etc; they do have some slight differences predictable communications, etc; they do have some slight differences
in respect of payload sizes, reactiveness, etc. in respect to payload sizes, reactiveness, etc.
SCHC gives a generic framework that enables those devices to SCHC provides a generic framework that enables those devices to
communicate with other Internet networks. However, for efficient communicate with other Internet networks. However, for efficient
performance, some parameters and modes of operation need to be set performance, some parameters and modes of operation need to be set
appropriately for each of the LPWAN technologies. appropriately for each of the LPWAN technologies.
This document describes the efficient parameters and modes of This document describes the efficient parameters and modes of
operation when SCHC is used over LoRaWAN networks. operation when SCHC is used over LoRaWAN networks.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This section defines the terminology and acronyms used in this This section defines the terminology and acronyms used in this
document. For all other definitions, please look up the SCHC document. For all other definitions, please look up the SCHC
specification [RFC8724]. specification [RFC8724].
o DevEUI: an IEEE EUI-64 identifier used to identify the end-device o DevEUI: an IEEE EUI-64 identifier used to identify the device
during the procedure while joining the network (Join Procedure) during the procedure while joining the network (Join Procedure)
o DevAddr: a 32-bit non-unique identifier assigned to an end-device o DevAddr: a 32-bit non-unique identifier assigned to a device
statically or dynamically after a Join Procedure (depending on the statically or dynamically after a Join Procedure (depending on the
activation mode) activation mode)
o RCS: Reassembly Check Sequence. Used to verify the integrity of o RCS: Reassembly Check Sequence. Used to verify the integrity of
the fragmentation-reassembly process the fragmentation-reassembly process
o TBD: all significant LoRaWAN-related terms.
o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI
o SCHC gateway: It corresponds to the LoRaWAN Application Server. It
manages translation between IPv6 network and the Network Gateway
(LoRaWAN Network Server)
3. Static Context Header Compression Overview 3. Static Context Header Compression Overview
This section contains a short overview of Static Context Header This section contains a short overview of Static Context Header
Compression (SCHC). For a detailed description, refer to the full Compression (SCHC). For a detailed description, refer to the full
specification [RFC8724]. specification [RFC8724].
It defines: It defines:
1. Compression mechanisms to avoid transport of known data by both 1. Compression mechanisms to avoid transporting information known by
sender and receiver over the air. Known data are part of the both sender and receiver over the air. Known information are
"context" part of the "context"
2. Fragmentation mechanisms to allow SCHC Packet transportation on 2. Fragmentation mechanisms to allow SCHC Packet transportation on
small, and potentially variable, MTU small, and potentially variable, MTU
Context exchange or pre-provisioning is out of scope of this Context exchange or pre-provisioning is out of scope of this
document. document.
Dev 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 |
+----+ +----+ +----+ +----+
Figure 1: Architecture Figure 1: Architecture
Figure 1 represents the architecture for compression/decompression, Figure 1 represents the architecture for compression/decompression,
it is based on [RFC8376] terminology. The Device is sending it is based on [RFC8376] terminology. The device is sending
applications flows using IPv6 or IPv6/UDP protocols. These flows applications flows using IPv6 or IPv6/UDP protocols. These flows
might be compressed by an Static Context Header Compression might be compressed by a Static Context Header Compression
Compressor/Decompressor (SCHC C/D) to reduce headers size and Compressor/Decompressor (SCHC C/D) to reduce headers size and
fragmented (SCHC F/R). The resulting information is sent on a layer fragmented (SCHC F/R). The resulting information is sent on a layer
two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the
frame to a Network Gateway (NGW). The NGW sends the data to a SCHC frame to a Network Gateway (NGW). The NGW sends the data to a SCHC
F/R for defragmentation, if required, then C/D for decompression F/R for reassembly, if required, then to SCHC C/D for decompression.
which shares the same rules with the device. The SCHC F/R and C/D The C/D shares the same rules with the device. The SCHC F/R and C/D
can be located on the Network Gateway (NGW) or in another place as can be located on the Network Gateway (NGW) or in another place as
long as a tunnel is established between the NGW and the SCHC F/R, long as a tunnel is established between the NGW and the SCHC F/R,
then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share
the same set of rules. After decompression, the packet can be sent the same set of rules. After decompression, the packet can be sent
on the Internet to one or several LPWAN Application Servers (App). on the Internet to one or several LPWAN Application Servers (App).
The SCHC F/R and SCHC C/D process is bidirectional, so the same The SCHC F/R and SCHC C/D process is bidirectional, so the same
principles can be applied in the other direction. principles can be applied in the other direction.
In a LoRaWAN network, the RG is called a Gateway, the NGW is Network In a LoRaWAN network, the RG is called a Gateway, the NGW is Network
Server, and the SCHC C/D is an Application Server. It can be Server, and the SCHC C/D and SCHC F/R are an Application Server. It
provided by the Network Server or any third party software. Figure 1 can be provided by the Network Gateway or any third party software.
can be mapped in LoRaWAN terminology to: Figure 1 can be mapped in LoRaWAN terminology to:
Dev App End 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 & F/R| | | | | | | |SCHC C/D & F/R| | | | | | |
+-------+------+ +----+ +----+ +----+ +-------+------+ +----+ +----+ +----+
| +-------+ +-------+ +-----------+ . . . | +-------+ +-------+ +-----------+ . . .
+~ |Gateway| === |Network| == |Application|..... Internet .... +~ |Gateway| === |Network| == |Application|..... Internet ....
skipping to change at page 5, line 29 skipping to change at page 5, line 39
Figure 2: SCHC Architecture mapped to LoRaWAN Figure 2: SCHC Architecture mapped to LoRaWAN
4. LoRaWAN Architecture 4. LoRaWAN Architecture
An overview of LoRaWAN [lora-alliance-spec] protocol and architecture An overview of LoRaWAN [lora-alliance-spec] protocol and architecture
is described in [RFC8376]. The mapping between the LPWAN is described in [RFC8376]. The mapping between the LPWAN
architecture entities as described in [RFC8724] and the ones in architecture entities as described in [RFC8724] and the ones in
[lora-alliance-spec] is as follows: [lora-alliance-spec] is as follows:
o Devices (Dev) are the end-devices or hosts (e.g. sensors, o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.).
actuators, etc.). There can be a very high density of devices per There can be a very high density of devices per radio gateway
radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN (LoRaWAN gateway). This entity maps to the LoRaWAN end-device.
End-Device.
o The Radio Gateway (RGW), which is the endpoint of the constrained o The Radio Gateway (RGW), which is the endpoint of the constrained
link. This entity maps to the LoRaWAN Gateway. link. This entity maps to the LoRaWAN Gateway.
o The Network Gateway (NGW) is the interconnection node between the o The Network Gateway (NGW) is the interconnection node between the
Radio Gateway and the Internet. This entity maps to the LoRaWAN Radio Gateway and the Internet. This entity maps to the LoRaWAN
Network Server. Network Server.
o Application Server (App). The same terminology is used in LoRaWAN. o SCHC F/R and SCHC C/D are LoRaWAN Application Server; ie the
In that case, the application server will be the SCHC gateway, doing LoRaWAN application server will do the C/D and F/R.
C/D and F/R.
() () () | +------+ () () () | +------+
() () () () / \ +---------+ | Join | () () () () / \ +---------+ | Join |
() () () () () / \======| ^ |===|Server| +-----------+ () () () () () / \======| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |Application| () () () | | <--|--> | +------+ |Application|
() () () () / \==========| v |=============| Server | () () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+ () () () / \ +---------+ +-----------+
End-Devices Gateways Network Server End Devices Gateways Network Server
Figure 3: LPWAN Architecture Figure 3: LPWAN Architecture
SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/ SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/
Reassembly) are performed on the LoRaWAN End-Device and the Reassembly) are performed on the LoRaWAN end-device and the
Application Server (called SCHC gateway). While the point-to-point Application Server (called SCHC gateway). While the point-to-point
link between the End-Device and the Application Server constitutes link between the device and the Application Server constitutes single
single IP hop, the ultimate end-point of the IP communication may be IP hop, the ultimate end-point of the IP communication may be an
an Internet node beyond the Application Server. In other words, the Internet node beyond the Application Server. In other words, the
LoRaWAN Application Server (SCHC gateway) acts as the first hop IP LoRaWAN Application Server (SCHC gateway) acts as the first hop IP
router for the End-Device. The Application Server and Network Server router for the device. The Application Server and Network Server may
may be co-located, which effectively turns the Network/Application be co-located, which effectively turns the Network/Application Server
Server into the first hop IP router. into the first hop IP router.
4.1. End-Device classes (A, B, C) and interactions 4.1. Device classes (A, B, C) and interactions
The LoRaWAN MAC layer supports 3 classes of end-devices named A, B The LoRaWAN MAC layer supports 3 classes of devices named A, B and C.
and C. All end-devices implement the Class A, some end-devices may All devices implement the Class A, some devices may implement Class B
implement Class B or Class C. Class B and Class C are mutually or Class C. Class B and Class C are mutually exclusive.
exclusive.
o Class A: The Class A is the simplest class of end-devices. The o Class A: The Class A is the simplest class of devices. The device
end-device is allowed to transmit at any time, randomly selecting is allowed to transmit at any time, randomly selecting a
a communication channel. The network may reply with a downlink in communication channel. The Network Gateway may reply with a
one of the 2 receive windows immediately following the uplinks. downlink in one of the 2 receive windows immediately following the
Therefore, the network cannot initiate a downlink, it has to wait uplinks. Therefore, the Network Gateway cannot initiate a
for the next uplink from the end-device to get a downlink downlink, it has to wait for the next uplink from the device to
opportunity. The Class A is the lowest power end-device class. get a downlink opportunity. The Class A is the lowest power
device class.
o Class B: Class B end-devices implement all the functionalities of o Class B: Class B devices implement all the functionalities of
Class A end-devices, but also schedule periodic listen windows. Class A devices, but also schedule periodic listen windows.
Therefore, opposed to the Class A end-devices, Class B end-devices Therefore, opposed to the Class A devices, Class B devices can
can receive downlinks that are initiated by the network and not receive downlinks that are initiated by the Network Gateway and
following an uplink. There is a trade-off between the periodicity not following an uplink. There is a trade-off between the
of those scheduled Class B listen windows and the power periodicity of those scheduled Class B listen windows and the
consumption of the end-device. The lower the downlink latency, power consumption of the device. The lower the downlink latency,
the higher the power consumption. the higher the power consumption.
o Class C: Class C end-devices implement all the functionalities of o Class C: Class C devices implement all the functionalities of
Class A end-devices, but keep their receiver open whenever they Class A devices, but keep their receiver open whenever they are
are not transmitting. Class C end-devices can receive downlinks not transmitting. Class C devices can receive downlinks at any
at any time at the expense of a higher power consumption. time at the expense of a higher power consumption. Battery-
Battery-powered end-devices can only operate in Class C for a powered devices can only operate in Class C for a limited amount
limited amount of time (for example for a firmware upgrade over- of time (for example for a firmware upgrade over-the-air). Most
the-air). Most of the Class C end-devices are grid powered (for of the Class C devices are grid powered (for example Smart Plugs).
example Smart Plugs).
4.2. End-Device addressing 4.2. Device addressing
LoRaWAN end-devices use a 32-bit network address (devAddr) to LoRaWAN end-devices use a 32-bit network address (devAddr) to
communicate with the network over-the-air, this address might not be communicate with the Network Gateway over-the-air, this address might
unique in a LoRaWAN network; end-devices using the same devAddr are not be unique in a LoRaWAN network; devices using the same devAddr
distinguished by the Network Server based on the cryptographic are distinguished by the Network Gateway based on the cryptographic
signature appended to every LoRaWAN frame. signature appended to every LoRaWAN frame.
To communicate with the SCHC gateway the Network Server MUST identify To communicate with the SCHC gateway the Network Gateway MUST
the end-devices by a unique 64-bit device identifier called the identify the devices by a unique 64-bit device identifier called the
devEUI. DevEUI.
The devEUI is assigned to the end-device during the manufacturing The DevEUI is assigned to the device during the manufacturing process
process by the end-device's manufacturer. It is built like an by the device's manufacturer. It is built like an Ethernet MAC
Ethernet MAC address by concatenating the manufacturer's IEEE OUI address by concatenating the manufacturer's IEEE OUI field with a
field with a vendor unique number. e.g.: 24-bit OUI is concatenated vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit
with a 40-bit serial number. The Network Server translates the serial number. The Network Gateway translates the devAddr into a
devAddr into a devEUI in the uplink direction and reciprocally on the DevEUI in the uplink direction and reciprocally on the downlink
downlink direction. direction.
+--------+ +----------+ +---------+ +----------+ +--------+ +---------+ +---------+ +----------+
| End- | <=====> | Network | <====> | SCHC | <========> | Internet | | Device | <=====> | Network | <====> | SCHC | <========> | Internet |
| Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | | | | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |
+--------+ +----------+ +---------+ +----------+ +--------+ +---------+ +---------+ +----------+
--------+ <span class="insert">+---------+</span> +---------+ +----------+
Figure 4: LoRaWAN addresses Figure 4: LoRaWAN addresses
4.3. General Message Types 4.3. General Frame Types
o Confirmed messages: The sender asks the receiver to acknowledge
the message.
o Unconfirmed messages: The sender does not ask the receiver to o LoRaWAN Confirmed message: The sender asks the receiver to
acknowledge the message. acknowledge the message.
o LoRaWAN Unconfirmed message: The sender does not ask the receiver
to acknowledge the message.
As SCHC defines its own acknowledgment mechanisms, SCHC does not As SCHC defines its own acknowledgment mechanisms, SCHC does not
require to use confirmed messages. require to use LoRaWAN Confirmed messages.
4.4. LoRaWAN MAC Frames 4.4. LoRaWAN MAC Frames
o JoinRequest: This message is used by an end-device to join a o JoinRequest: This message is used by a device to join a network.
network. It contains the end-device's unique identifier devEUI It contains the device's unique identifier DevEUI and a random
and a random nonce that will be used for session key derivation. nonce that will be used for session key derivation.
o JoinAccept: To on-board an end-device, the Network Server responds o JoinAccept: To on-board a device, the Network Gateway responds to
to the JoinRequest issued by an end-device with a JoinAccept the JoinRequest issued by a device with a JoinAccept message.
message. That message is encrypted with the end-device's AppKey That message is encrypted with the device's AppKey and contains
and contains (amongst other fields) the major network's settings (amongst other fields) the major network's settings and a random
and a network random nonce used to derive the session keys. nonce used to derive the session keys.
o Data: MAC and application data. Application data are protected o Data: MAC and application data. Application data are protected
with AES-128 encryption, MAC related data are AES-128 encrypted with AES-128 encryption, MAC related data are AES-128 encrypted
with another key. with another key.
4.5. Unicast and multicast technology 4.5. LoRaWAN empty frame
A LoRaWAN empty frame is a LoRaWAN message without FPort and
FRMPayload.
4.6. Unicast and multicast technology
LoRaWAN technology supports unicast downlinks, but also multicast: a LoRaWAN technology supports unicast downlinks, but also multicast: a
packet send over LoRaWAN radio link can be received by several packet send over LoRaWAN radio link can be received by several
devices. It is useful to address many end-devices with same content, devices. It is useful to address many devices with same content,
either a large binary file (firmware upgrade), or same command (e.g: either a large binary file (firmware upgrade), or same command (e.g:
lighting control). As IPv6 is also a multicast technology this lighting control). As IPv6 is also a multicast technology this
feature can be used to address a group of devices. feature can be used to address a group of devices.
_Note 1_: IPv6 multicast addresses must be defined as per [RFC4291]. _Note 1_: IPv6 multicast addresses must be defined as per [RFC4291].
LoRaWAN multicast group definition in a network server and the LoRaWAN multicast group definition in a Network Gateway and the
relation between those groups and IPv6 groupID are out of scope of relation between those groups and IPv6 groupID are out of scope of
this document. this document.
_Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set] _Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set]
as RECOMMENDED way to setup multicast groups on devices and create a as RECOMMENDED way to setup multicast groups on devices and create a
synchronized reception window. synchronized reception window.
5. SCHC-over-LoRaWAN 5. SCHC-over-LoRaWAN
5.1. LoRaWAN FPort 5.1. LoRaWAN FPort
skipping to change at page 9, line 7 skipping to change at page 9, line 12
This field (FPort) is 8 bits long and the values from 1 to 223 can be 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. used. It allows LoRaWAN networks and applications to identify data.
The FPort field is part of the SCHC Message, as shown in Figure 5. The FPort field is part of the SCHC Message, as shown in Figure 5.
The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with
the LoRaWAN payload to retrieve their payload as it is used as a part the LoRaWAN payload to retrieve their payload as it is used as a part
of the RuleID field. of the RuleID field.
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------------------------ + + ------------------------ +
| SCHC payload | | SCHC packet |
Figure 5: SCHC Message in LoRaWAN Figure 5: SCHC Message in LoRaWAN
A fragmentation session with application payload transferred from A fragmentation datagram with application payload transferred from
device to server, is called uplink fragmentation session. It uses an device to Network Gateway, is called uplink fragmentation datagram.
FPort for data uplink and its associated SCHC control downlinks, It uses an FPort for data uplink and its associated SCHC control
named FPortUp in this document. The other way, a fragmentation downlinks, named FPortUp in this document. The other way, a
session with application payload transferred from server to device, fragmentation datagram with application payload transferred from
is called downlink fragmentation session. It uses another FPort for Network Gateway to device, is called downlink fragmentation datagram.
data downlink and its associated SCHC control uplinks, named It uses another FPort for data downlink and its associated SCHC
FPortDown in this document. control uplinks, named FPortDown in this document.
All ruleId can use arbitrary values inside the FPort range allowed by All RuleID can use arbitrary values inside the FPort range allowed by
LoRaWAN specification and MUST be shared by the end-device and SCHC LoRaWAN specification and MUST be shared by the device and SCHC
gateway prior to the communication with the selected rule. The gateway prior to the communication with the selected rule. The
uplink and downlink fragmentation FPorts MUST be different. uplink and downlink fragmentation FPorts MUST be different.
5.2. Rule ID management 5.2. Rule ID management
RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in
Section 5.1. LoRaWAN supports up to 223 application FPorts in the Section 5.1. LoRaWAN supports up to 223 application FPorts in the
range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it
implies that RuleID MSB SHOULD be inside this range. An application implies that RuleID MSB SHOULD be inside this range. An application
can send non SCHC traffic by using FPort values different from the can send non SCHC traffic by using FPort values different from the
skipping to change at page 10, line 4 skipping to change at page 10, line 9
(no matching rule was found) (no matching rule was found)
The remaining RuleIDs are available for compression. RuleIDs are The remaining RuleIDs are available for compression. RuleIDs are
shared between uplink and downlink sessions. A RuleID not in the shared between uplink and downlink sessions. A RuleID not in the
set(s) of FPortUp or FPortDown means that the fragmentation is not set(s) of FPortUp or FPortDown means that the fragmentation is not
used, thus, on reception, the SCHC Message MUST be sent to the C/D used, thus, on reception, the SCHC Message MUST be sent to the C/D
layer. layer.
The only uplink messages using the FPortDown port are the The only uplink messages using the FPortDown port are the
fragmentation SCHC control messages of a downlink fragmentation fragmentation SCHC control messages of a downlink fragmentation
session (for example, SCHC ACKs). Similarly, the only downlink datagram (for example, SCHC ACKs). Similarly, the only downlink
messages using the FPortUp port are the fragmentation SCHC control messages using the FPortUp port are the fragmentation SCHC control
messages of an uplink fragmentation session. messages of an uplink fragmentation datagram.
An application can have multiple fragmentation sessions between a An application can have multiple fragmentation datagrams between a
device and one or several SCHC gateways. A set of FPort values is device and one or several SCHC gateways. A set of FPort values is
REQUIRED for each SCHC gateway instance the device is required to REQUIRED for each SCHC gateway instance the device is required to
communicate with. communicate with. The application can use additional uplinks or
downlink fragmentation parameters but SHALL implement at least the
parameters defined in this document.
The mechanism for sharing those RuleID values is outside the scope of The mechanism for sharing those RuleID values is outside the scope of
this document. this document.
5.3. IID computation 5.3. IID computation
In order to mitigate risks described in [RFC8064] and [RFC8065] IID In order to mitigate risks described in [RFC8064] and [RFC8065] IID
MUST be created regarding the following algorithm: MUST be created regarding the following algorithm:
1. key = LoRaWAN AppSKey 1. key = LoRaWAN AppSKey
2. cmac = aes128_cmac(key, devEui) 2. cmac = aes128_cmac(key, DevEUI)
3. IID = cmac[0..7] 3. IID = cmac[0..7]
aes128_cmac algorithm is described in [RFC4493]. It has been chosen aes128_cmac algorithm is described in [RFC4493]. It has been chosen
as it is already used by devices for LoRaWAN protocol. as it is already used by devices for LoRaWAN protocol.
As AppSKey is renewed each time a device joins or rejoins a network, As AppSKey is renewed each time a device joins or rejoins a LoRaWAN
the IID will change over time; this mitigates privacy, location network, the IID will change over time; this mitigates privacy,
tracking and correlation over time risks. Join periodicity is location tracking and correlation over time risks. Join periodicity
defined at the application level. is defined at the application level.
Address scan risk is mitigated thanks to AES-128, which provides Address scan risk is mitigated thanks to AES-128, which provides
enough entropy bits of the IID. enough entropy bits of the IID.
Using this algorithm will also ensure that there is no correlation Using this algorithm will also ensure that there is no correlation
between the hardware identifier (IEEE-64 devEUI) and the IID, so an between the hardware identifier (IEEE-64 DevEUI) and the IID, so an
attacker cannot use manufacturer OUI to target devices. attacker cannot use manufacturer OUI to target devices.
Example with: Example with:
o devEui: 0x1122334455667788 o DevEUI: 0x1122334455667788
o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB 1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
2. cmac: 0x4E822D9775B2649928F82066AF804FEC 2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A
3. IID: 0x28F82066AF804FEC 3. IID: 0xBA59F4B196C6C343
Figure 6: Example of IID computation. Figure 6: Example of IID computation.
There is a small probability of IID collision in a network, if such There is a small probability of IID collision in a LoRaWAN network,
event occurs the IID can be changed by rekeying the device on L2 if such event occurs the IID can be changed by rekeying the device on
level (ie: trigger a LoRaWAN join). The way the device is rekeyed is L2 level (ie: trigger a LoRaWAN join). The way the device is rekeyed
out of scope of this document and left to the implementation. is out of scope of this document and left to the implementation.
5.4. Padding 5.4. Padding
All padding bits MUST be 0. All padding bits MUST be 0.
5.5. Decompression 5.5. Decompression
SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the
SCHC Packet as per Section 5.1. SCHC Packet as per Section 5.1.
RuleIDs matching FPortUp and FPortDown are reserved for SCHC RuleIDs matching FPortUp and FPortDown are reserved for SCHC
Fragmentation. Fragmentation.
5.6. Fragmentation 5.6. Fragmentation
The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC 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 over LoRaWAN uses the ACK-on-Error mode for uplink
fragmentation and Ack-Always mode for downlink fragmentation. A fragmentation and Ack-Always mode for downlink fragmentation. A
LoRaWAN end-device cannot support simultaneous interleaved LoRaWAN device cannot support simultaneous interleaved fragmentation
fragmentation sessions in the same direction (uplink or downlink). datagrams in the same direction (uplink or downlink).
The fragmentation parameters are different for uplink and downlink The fragmentation parameters are different for uplink and downlink
fragmentation sessions and are successively described in the next fragmentation datagrams and are successively described in the next
sections. sections.
5.6.1. DTag 5.6.1. DTag
A LoRaWAN device cannot interleave several fragmented SCHC datagrams A Device cannot interleave several fragmented SCHC datagrams on the
on the same FPort. This field is not used and its size is 0. same FPort. This field is not used and its size is 0.
Note: The device can still have several parallel fragmentation Note: The device can still have several parallel fragmentation
sessions with one or more SCHC gateway(s) thanks to distinct sets of datagrams with one or more SCHC gateway(s) thanks to distinct sets of
FPorts, cf Section 5.2 FPorts, cf Section 5.2
5.6.2. Uplink fragmentation: From device to SCHC gateway 5.6.2. Uplink fragmentation: From device to SCHC gateway
In that case the device is the fragmentation transmitter, and the In that case the device is the fragmentation transmitter, and the
SCHC gateway the fragmentation receiver. A single fragmentation rule SCHC gateway the fragmentation receiver. A single fragmentation rule
is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to
retrieve the SCHC Packet, as per Section 5.1. retrieve the SCHC Packet, as per Section 5.1.
o SCHC header size is two bytes (the FPort byte + 1 additional o SCHC header size is two bytes (the FPort byte + 1 additional
skipping to change at page 12, line 32 skipping to change at page 12, line 32
tiles are allowed in a window tiles are allowed in a window
o Window index: encoded on W = 2 bits. So 4 windows are available. o Window index: encoded on W = 2 bits. So 4 windows are available.
o RCS: Use recommended calculation algorithm in [RFC8724]. o RCS: Use recommended calculation algorithm in [RFC8724].
o MAX_ACK_REQUESTS: 8 o MAX_ACK_REQUESTS: 8
o Tile: size is 10 bytes o Tile: size is 10 bytes
o Retransmission timer: LoRaWAN end-devices MUST NOT implement a o Retransmission timer: Set by the implementation depending on the
"retransmission timer", this changes the specification of application requirements.
[RFC8724], see Section 5.6.3.5. It must transmit MAX_ACK_REQUESTS
time the SCHC ACK REQ at it own timing; ie the periodicity between
retransmission of SCHC ACK REQs is device specific and can vary
depending on other application uplinks and regulations.
o Inactivity timer: The SCHC gateway implements an "inactivity o Inactivity timer: The SCHC gateway implements an "inactivity
timer". The default RECOMMENDED duration of this timer is 12 timer". The default RECOMMENDED duration of this timer is 12
hours; this value is mainly driven by application requirements and hours; this value is mainly driven by application requirements and
MAY be changed by the application. MAY be changed by the application.
o Penultimate tile MUST be equal to the regular size. o Penultimate tile MUST be equal to the regular size.
o Last tile: it can be carried in a Regular SCHC Fragment, alone in o 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: an All-1 SCHC Fragment or with any of these two methods.
implementation must ensure that: Implementation must ensure that:
* The sender MUST ascertain that the receiver will not receive * The sender MUST ascertain that the receiver will not receive
the last tile through both a Regular SCHC Fragment and an All-1 the last tile through both a Regular SCHC Fragment and an All-1
SCHC Fragment. SCHC Fragment.
* If last tile is in All-1 message: current L2 MTU MUST be big * If last tile is in All-1 message: current L2 MTU MUST be big
enough to fit the All-1 and the last tile. enough to fit the All-1 and the last tile.
With this set of parameters, the SCHC fragment header is 16 bits, With this set of parameters, the SCHC fragment header is 16 bits,
including FPort; payload overhead will be 8 bits as FPort is already 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 a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes
per tile = 2520 bytes_ per tile = 2520 bytes_
For battery powered SCHC sender, it is RECOMMENDED to use ACK For battery powered devices, it is RECOMMENDED to use the ACK
mechanism at the end of each window instead of waiting the end of all mechanism at the end of each window instead of waiting until the end
windows: of all windows:
o SCHC receiver SHOULD send a SCHC ACK after every window even if o SCHC receiver SHOULD send a SCHC ACK after every window even if
there is no missing tiles. there is no missing tile.
o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver
before sending tiles from next window. If the SCHC ACK is not before sending tiles from the next window. If the SCHC ACK is not
received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS,
time as described previously. time as described previously.
For non-battery powered devices, SCHC receiver MAY also choose to For non-battery powered devices, SCHC receiver MAY also choose to
send a SCHC ACK only at the end of all windows. It will reduce send a SCHC ACK only at the end of all windows. It will reduce
downlink load on the network, by reducing the number of downlinks. downlink load on the LoRaWAN network, by reducing the number of
downlinks.
SCHC implementations MUST be compatible with both behavior, and SCHC implementations MUST be compatible with both behavior, and
selection is a part of the rule context. selection is a part of the rule context.
5.6.2.1. Regular fragments 5.6.2.1. Regular fragments
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ------------------------- + + ------ + ------------------------- +
| RuleID | W | FCN | Payload | | RuleID | W | FCN | Payload |
+ ------ + ------ + ------ + ------- + + ------ + ------ + ------ + ------- +
skipping to change at page 14, line 4 skipping to change at page 13, line 42
| 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 | |
Figure 7: All fragments except the last one. SCHC header size is 16 Figure 7: All fragments except the last one. SCHC header size is 16
bits, including LoRaWAN FPort. bits, including LoRaWAN FPort.
5.6.2.2. Last fragment (All-1) 5.6.2.2. Last fragment (All-1)
| 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 |
Figure 8: All-1 fragment detailed format for the last fragment. Figure 8: All-1 SCHC Message: the last fragment without last tile.
| FPort | LoRaWAN payload |
+ ------ + ------------------------------------------- +
| RuleID | W | FCN=All-1 | RCS | Last tile |
+ ------ + ------ + --------- + ------- + ------------ +
| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits |
Figure 9: All-1 SCHC Message: the last fragment with last tile.
5.6.2.3. SCHC ACK 5.6.2.3. SCHC ACK
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + ----------------------------------------- + + ------ + -------------------------------------------------------------------- +
| RuleID | W | C | Encoded bitmap (if C = 0) | | RuleID | W | C | Compressed bitmap(C = 0) | Optional padding(b'0...0) |
+ ------ + ----- + ----- + ------------------------- + + ------ + ----- + ----- + ------------------------ + ------------------------- +
| 8 bits | 2 bit | 1 bit | 0 to 63 bits | | 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits |
Figure 9: SCHC ACK format, failed RCS check. Figure 10: SCHC ACK format, failed RCS check.
Note: Because of the bitmap compression mechanism and L2 byte
alignment only few discrete values are possible: 5, 13, 21, 29, 37,
45, 53, 61, 62, 63. Bitmaps of 63 bits will require 6 bits of
padding.
5.6.2.4. Receiver-Abort 5.6.2.4. Receiver-Abort
| 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 --> |
Figure 10: Receiver-Abort format. Figure 11: Receiver-Abort format.
5.6.2.5. SCHC acknowledge request 5.6.2.5. SCHC acknowledge request
| 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 |
Figure 11: SCHC ACK REQ format. Figure 12: SCHC ACK REQ format.
5.6.3. Downlink fragmentation: From SCHC gateway to a device 5.6.3. Downlink fragmentation: From SCHC gateway to device
In that case the device is the fragmentation receiver, and the SCHC In that case the device is the fragmentation receiver, and the SCHC
gateway the fragmentation transmitter. The following fields are gateway the fragmentation transmitter. The following fields are
common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN
payload to retrieve the SCHC Packet as described in Section 5.1. payload to retrieve the SCHC Packet as described in Section 5.1.
o SCHC fragmentation reliability mode: o SCHC fragmentation reliability mode:
* Unicast downlinks: ACK-Always. * Unicast downlinks: ACK-Always.
skipping to change at page 15, line 27 skipping to change at page 15, line 27
the upper layer. This feature is OPTIONAL and may not be the upper layer. This feature is OPTIONAL and may not be
implemented by SCHC gateway. implemented by SCHC gateway.
o RuleID: 8 bits stored in LoRaWAN FPort. o RuleID: 8 bits stored in LoRaWAN FPort.
o Window index (unicast only): encoded on W=1 bit, as per [RFC8724]. o Window index (unicast only): encoded on W=1 bit, as per [RFC8724].
o DTag: Size is 0 bit, not used o DTag: Size is 0 bit, not used
o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile
(FCN=All-1 is reserved for SCHC).
o RCS: Use recommended calculation algorithm in [RFC8724]. o RCS: Use recommended calculation algorithm in [RFC8724].
o MAX_ACK_REQUESTS: 8 o MAX_ACK_REQUESTS: 8
o Retransmission timer: See Section 5.6.3.5
o 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.
As only 1 tile is used, its size can change for each downlink, and As only 1 tile is used, its size can change for each downlink, and
will be maximum available MTU. will be maximum available MTU.
Class A devices can only receive during an RX slot, following the
transmission of an uplink. Therefore the SCHC gateway cannot
initiate communication (ex: new SCHC 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. RECOMMENDED uplink is a
LoRaWAN empty frame as defined Section 4.5. As this uplink is to
open an RX window any applicative uplink MAY reset this counter.
_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be _Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be
used for SCHC-over-LoRaWAN protocol. It might be set by the Network used for SCHC-over-LoRaWAN protocol. It might be set by the Network
Server for other purposes but not SCHC needs. Gateway for other purposes but not SCHC needs.
5.6.3.1. Regular fragments 5.6.3.1. Regular fragments
| 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 |
Figure 12: All fragments but the last one. Header size 10 bits, Figure 13: All fragments but the last one. Header size 10 bits,
including LoraWAN FPort. including LoraWAN FPort.
5.6.3.2. Last fragment (All-1) 5.6.3.2. Last fragment (All-1)
| FPort | LoRaWAN payload | | FPort | LoRaWAN payload |
+ ------ + --------------------------- + + ------ + --------------------------- + ----------------- +
| RuleID | W | FCN = b'1 | RCS | | RuleID | W | FCN = b'1 | RCS | Payload |
+ ------ + ----- + --------- + ------- + + ------ + ----- + --------- + ------- + ----------------- +
| 8 bits | 1 bit | 1 bit | 32 bits | | 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes |
Figure 13: All-1 SCHC Message: the last fragment. Figure 14: All-1 SCHC Message: the last fragment.
5.6.3.3. SCHC acknowledge 5.6.3.3. SCHC ACK
| 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 |
Figure 14: SCHC ACK format, RCS is correct. Figure 15: SCHC ACK format, RCS is correct.
5.6.3.4. Receiver-Abort 5.6.3.4. Receiver-Abort
| 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 --> |
Figure 15: Receiver-Abort packet (following an All-1 SCHC Fragment Figure 16: Receiver-Abort packet (following an All-1 SCHC Fragment
with incorrect RCS). with incorrect RCS).
Class A and Class B or Class C end-devices do not manage 5.6.3.5. Downlink retransmission timer
retransmissions and timers in the same way.
5.6.3.5. Class A end-devices Class A and Class B or Class C devices do not manage retransmissions
and timers in the same way.
Class A end-devices can only receive in an RX slot following the 5.6.3.5.1. Class A devices
transmission of an uplink. Therefore there cannot be a concept of
"retransmission timer" for an SCHC gateway. The SCHC gateway cannot
initiate communication to a Class A end-device.
The device replies with an ACK message to every single fragment Class A devices can only receive in an RX slot following the
received from the SCHC gateway (because the window size is 1). transmission of an uplink.
Following the reception of a FCN=0 fragment (fragment that is not the The SCHC gateway implements an inactivity timer with a RECOMMENDED
last fragment of the packet or SCHC ACK REQ, but the end of a duration of 36 hours. For devices with very low transmission rates
window), the device MUST transmit the SCHC ACK fragment until it (example 1 packet a day in normal operation), that duration may be
receives the fragment of the next window. The device SHALL transmit extended: it is application specific.
up to MAX_ACK_REQUESTS ACK messages before aborting. The device
should transmit those ACK as soon as possible while taking into
consideration potential local radio regulation on duty-cycle, to
progress the fragmentation session as quickly as possible. The ACK
bitmap is 1 bit long and is always 1.
Following the reception of an FCN=All-1 fragment (the last fragment RETRANSMISSION_TIMER is application specific and its RECOMMENDED
of a datagram) and if the RCS is correct, the device SHALL transmit value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).
the ACK with the "RCS is correct" indicator bit set (C=1). This
message might be lost therefore the SCHC gateway MAY request a
retransmission of this ACK in the next downlink. The device SHALL
keep this ACK message in memory until it receives a downlink, on SCHC
FPortDown from the SCHC gateway different from an SCHC ACK REQ: it
indicates that the SCHC gateway has received the ACK message.
The fragmentation sender (the SCHC gateway) implements an inactivity *SCHC All-0 (FCN=0)* All fragment but the last have an FCN=0 (because
timer with a default duration of 12 hours. Once a fragmentation window size is 1). Following it the device MUST transmit the SCHC
session is started, if the SCHC gateway has not received any ACK or ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC ACK
Receiver-Abort message 12 hours after the last message from the messages before aborting. In order to progress the fragmentation
device was received, the SCHC gateway MAY flush the fragmentation datagram, the SCHC layer should immediately queue for transmission
context. For devices with very low transmission rates (example 1 those SCHC ACK if no SCHC downlink have been received during RX1 and
packet a day in normal operation) , that duration may be extended, RX2 window. LoRaWAN layer will respect the regulation if required.
but this is application specific.
5.6.3.6. Class B or Class C end-devices _Note_: The ACK bitmap is 1 bit long and is always 1.
Class B and Class C end-devices can receive in scheduled RX slots or *SCHC All-1 (FCN=1)* SCHC All-1 is the last fragment of a datagram,
in RX slots following the transmission of an uplink. The device the corresponding SCHC ACK message might be lost; therefore the SCHC
replies with an ACK message to every single fragment received from gateway MUST request a retransmission of this ACK when the
the SCHC gateway (because the window size is 1). Following the retransmission timer expires. To open a downlink opportunity the
reception of an FCN=0 fragment (fragment that is not the last device MUST transmit an uplink every
fragment of the packet or SCHC ACK REQ), the device MUST always RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS *
transmit the corresponding SCHC ACK message even if that fragment has SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is
already been received. The ACK bitmap is 1 bit long and is always 1. application specific. It is RECOMMENDED for a device to send an
If the SCHC gateway receives this ACK, it proceeds to send the next empty frame (see Section 4.5) but it is application specific and will
window fragment. If the retransmission timer elapses and the SCHC be used by the NGW to transmit a potential SCHC ACK REQ.
gateway has not received the ACK of the current window it retransmits SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its
the last fragment. The SCHC gateway tries retransmitting up to recommended value is 2, it MUST be greater than 1. This allows to
MAX_ACK_REQUESTS times before aborting. open downlink opportunity to other eventual downlink with higher
priority than SCHC ACK REQ message.
Following the reception of an FCN=All-1 fragment (the last fragment _Note_: The device MUST keep this SCHC ACK message in memory until it
of a datagram) and if the RCS is correct, the device SHALL transmit receives a downlink, on SCHC FPortDown different from an SCHC ACK
the ACK with the "RCS is correct" indicator bit set. If the SCHC REQ: it indicates that the SCHC gateway has received the ACK message.
gateway receives this ACK, the current fragmentation session has
succeeded and its context can be cleared.
If the retransmission timer elapses and the SCHC gateway has not 5.6.3.6. Class B or Class C devices
received the SCHC ACK it retransmits the last fragment with the
payload (not an SCHC ACK REQ without payload). The SCHC gateway
tries retransmitting up to MAX_ACK_REQUESTS times before aborting.
Following the reception of an FCN=All-1 fragment (the last fragment Class B devices can receive in scheduled RX slots or in RX slots
of a datagram), if all fragments have been received and if the RCS is following the transmission of an uplink. Class C devices are almost
NOT correct, the device SHALL transmit a Receiver-Abort fragment. in constant reception.
The retransmission timer is used by the SCHC gateway (the sender),
the optimal value is very much application specific but here are some RECOMMENDED retransmission timer value:
recommended default values. For Class B end-devices, this timer
trigger is a function of the periodicity of the Class B ping slots. o Class B: 3 times the ping slot periodicity.
The RECOMMENDED value is equal to 3 times the Class B ping slot
periodicity. For Class C end-devices which are nearly constantly o Class C: 30 seconds
receiving, the RECOMMENDED value is 30 seconds. This means that the
end-device shall try to transmit the ACK within 30 seconds of the The RECOMMENDED inactivity timer value is 12 hours for both Class B
reception of each fragment. The inactivity timer is implemented by and Class C devices.
the end-device to flush the context in case it receives nothing from
the SCHC gateway over an extended period of time. The RECOMMENDED 5.7. SCHC Fragment Format
value is 12 hours for both Class B and Class C end-devices.
5.7.1. All-0 SCHC fragment
*Uplink fragmentation (Ack-On-Error)*:
All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states
_This condition is also met if the SCHC Fragment Header is a multiple
of L2 Words_; this condition met: SCHC header is 2 bytes.
*Downlink fragmentation (Ack-always)*:
As per [RFC8724] the SCHC All-1 MUST contain the last tile,
implementation must ensure that All-0 message Payload will be at
least the size of an L2 Word.
5.7.2. All-1 SCHC fragment
All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states
_This condition is met if the RCS is present and is at least the size
of an L2 Word_; this condition met: RCS is 4 bytes.
5.7.3. Delay after each message to respect local regulation
This profile does not define a delay to be added after each SCHC
message, local regulation compliance is expected to be enforced by
LoRaWAN stack.
6. Security considerations 6. Security considerations
This document is only providing parameters that are expected to be This document is only providing parameters that are expected to be
better suited for LoRaWAN networks for [RFC8724]. IID security is best suited for LoRaWAN networks for [RFC8724]. IID security is
discussed in Section 5.3. As such, this document does not contribute discussed in Section 5.3. As such, this document does not contribute
to any new security issues in addition to those identified in to any new security issues in addition to those identified in
[RFC8724]. Moreover SCHC data (LoRaWAN payload) are protected on [RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on
LoRaWAN level by an AES-128 encryption with key shared by device and LoRaWAN level by an AES-128 encryption with key shared by device and
SCHC gateway. Those keys are renew each LoRaWAN session (ie: each SCHC gateway. Those keys are renewed at each LoRaWAN session (ie:
join or rejoin to the network) each join or rejoin to the LoRaWAN network)
Acknowledgements Acknowledgements
Thanks to all those listed in the Contributors section for the Thanks to all those listed in the Contributors section for the
excellent text, insightful discussions, reviews and suggestions, and excellent text, insightful discussions, reviews and suggestions, and
also to (in alphabetical order) Dominique Barthel, Arunprabhu also to (in alphabetical order) Dominique Barthel, Arunprabhu
Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent
Toutain for useful design considerations, reviews and comments. Toutain for useful design considerations, reviews and comments.
Contributors Contributors
skipping to change at page 21, line 25 skipping to change at page 21, line 43
over LoRaWAN, no fragmentation required over LoRaWAN, no fragmentation required
An applicative payload of 78 bytes is passed to SCHC compression An applicative payload of 78 bytes is passed to SCHC compression
layer. Rule 1 is used by C/D layer, allowing to compress it to 40 layer. Rule 1 is used by C/D layer, allowing to compress it to 40
bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload. bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload.
| 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 |
Figure 16: Uplink example: SCHC Message Figure 17: Uplink example: SCHC Message
The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used
by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need
for fragmentation. The payload will be transmitted through FPort = for fragmentation. The payload will be transmitted through FPort =
1. 1.
| 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 |
Figure 17: Uplink example: LoRaWAN packet Figure 18: Uplink example: LoRaWAN packet
A.2. Uplink - Compression and fragmentation example A.2. Uplink - Compression and fragmentation example
This example represents an applicative payload going through SCHC, This example represents an applicative payload going through SCHC,
with fragmentation. with fragmentation.
An applicative payload of 478 bytes is passed to SCHC compression An applicative payload of 478 bytes is passed to SCHC compression
layer. Rule 1 is used by C/D layer, allowing to compress it to 282 layer. Rule 1 is used by C/D layer, allowing to compress it to 282
bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload.
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- +
| 1 | 21 bits | 279 bytes | | 1 | 21 bits | 279 bytes |
Figure 18: Uplink example: SCHC Message Figure 19: Uplink example: SCHC Message
The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by
LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte
FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is
sent in first fragment. sent in first fragment.
| 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 |
Figure 19: Uplink example: LoRaWAN packet 1 Figure 20: Uplink example: LoRaWAN packet 1
Content of the tile is: Content of the tile is:
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + ----------------- + + ------ + ------------------- + ----------------- +
| 1 | 21 bits | 6 byte + 3 bits | | 1 | 21 bits | 6 byte + 3 bits |
Figure 20: Uplink example: LoRaWAN packet 1 - Tile content Figure 21: Uplink example: LoRaWAN packet 1 - Tile content
Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by
LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte
FPort field, a tile does not fit inside so LoRaWAN stack will send FPort field, a tile does not fit inside so LoRaWAN stack will send
only FOpts. only FOpts.
Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are
transmitted: transmitted:
| 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 |
Figure 21: Uplink example: LoRaWAN packet 2 Figure 22: Uplink example: LoRaWAN packet 2
Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles
are transmitted, the last tile is only 2 bytes + 5 bits. Padding is are transmitted, the last tile is only 2 bytes + 5 bits. Padding is
added for the remaining 3 bits. added for the remaining 3 bits.
| 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 |
Figure 22: Uplink example: LoRaWAN packet 3 Figure 23: Uplink example: LoRaWAN packet 3
Then All-1 message can be transmitted: Then All-1 message can be transmitted:
| 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 |
Figure 23: Uplink example: LoRaWAN packet 4 - All-1 message Figure 24: Uplink example: LoRaWAN packet 4 - All-1 message
All packets have been received by the SCHC gateway, computed RCS is 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 correct so the following ACK is sent to the device by the SCHC
receiver: receiver:
| 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 |
Figure 24: Uplink example: LoRaWAN packet 5 - SCHC ACK Figure 25: Uplink example: LoRaWAN packet 5 - SCHC ACK
A.3. Downlink A.3. Downlink
An applicative payload of 443 bytes is passed to SCHC compression An applicative payload of 443 bytes is passed to SCHC compression
layer. Rule 1 is used by C/D layer, allowing to compress it to 130 layer. Rule 1 is used by C/D layer, allowing to compress it to 130
bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload.
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- + + ------ + ------------------- + --------- +
| 1 | 21 bits | 127 bytes | | 1 | 21 bits | 127 bytes |
Figure 25: Downlink example: SCHC Message Figure 26: Downlink example: SCHC Message
The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN
protocol: 51 bytes are available for SCHC payload + FPort field => it protocol: 51 bytes are available for SCHC payload + FPort field => it
has to be fragmented. has to be fragmented.
| 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 |
Figure 26: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1 Figure 27: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1
Content of the tile is: Content of the tile is:
| RuleID | Compression residue | Payload | | RuleID | Compression residue | Payload |
+ ------ + ------------------- + ------------------ + + ------ + ------------------- + ------------------ +
| 1 | 21 bits | 48 bytes and 1 bit | | 1 | 21 bits | 48 bytes and 1 bit |
Figure 27: Downlink example: LoRaWAN packet 1: Tile content Figure 28: Downlink example: LoRaWAN packet 1: Tile content
The receiver answers with a SCHC ACK: The receiver answers with a SCHC ACK:
| 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 |
Figure 28: Downlink example: LoRaWAN packet 2 - SCHC ACK Figure 29: Downlink example: LoRaWAN packet 2 - SCHC ACK
The second downlink is sent, two FOpts: The second downlink is sent, two FOpts:
| 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 |
Figure 29: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2 Figure 30: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2
The receiver answers with an SCHC ACK: The receiver answers with an SCHC ACK:
| 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 |
Figure 30: Downlink example: LoRaWAN packet 4 - SCHC ACK Figure 31: Downlink example: LoRaWAN packet 4 - SCHC ACK
The last downlink is sent, no FOpts: The last downlink is sent, no FOpts:
| LoRaWAN Header | LoRaWAN payload (37 bytes) | | LoRaWAN Header | LoRaWAN payload (37 bytes) |
+ ---- + --------- + ----------------------------------------------------------------- + + ---- + --------- + ----------------------------------------------------------------- +
| | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 | | | RuleID=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=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 bits | 5 bits |
Figure 31: Uplink example: LoRaWAN packet 5 - All-1 message Figure 32: Downlink example: LoRaWAN packet 5 - All-1 message
The receiver answers to the sender with an SCHC ACK: The receiver answers to the sender with an SCHC ACK:
| 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 |
Figure 32: Uplink example: LoRaWAN packet 6 - SCHC ACK Figure 33: Downlink example: LoRaWAN packet 6 - SCHC ACK
Authors' Addresses Authors' Addresses
Olivier Gimenez (editor) Olivier Gimenez (editor)
Semtech Semtech
14 Chemin des Clos 14 Chemin des Clos
Meylan Meylan
France France
Email: ogimenez@semtech.com Email: ogimenez@semtech.com
 End of changes. 123 change blocks. 
277 lines changed or deleted 320 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/