RFC 9011
Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN
RFC 9011: Static Context Header Compression and Fragmentation (SCHC) over LoRaWAN ✨
bestie, this one is the LoRaWAN profile of SCHC 🦋 It's a Standards Track doc from the IETF, published April 2021. The editors are O. Gimenez (Ed., Semtech) and I. Petrov (Ed., Acklio). It's ISSN 2070-1721 and doesn't obsolete or update anything, so it's a fresh start, no drama 💅
Abstract
okay so the SCHC spec (RFC 8724) is all about generic header compression and fragmentation for Low-Power Wide Area Network (LPWAN) tech 🌸 SCHC is built to be super flexible so it can be adapted to basically any LPWAN technology, which is iconic 👑
This doc is the bit that defines a profile of SCHC (RFC 8724) for LoRaWAN networks 🎀 It also gives you the good stuff like efficient parameterization and modes of operation ✨
Status of This Memo
this is an Internet Standards Track document 🫶
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💖 more info on Internet Standards is in Section 2 of RFC 7841.
for the current status, any errata, and how to give feedback, check https://www.rfc-editor.org/info/rfc9011 🧚
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please read them carefully, because they spell out your rights and restrictions for this doc 📜 Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🔥
Table of Contents
1. Introduction
2. Terminology
3. SCHC Overview
4. LoRaWAN Architecture
4.1. Device Classes (A, B, C) and Interactions
4.2. Device Addressing
4.3. General Frame Types
4.4. LoRaWAN MAC Frames
4.5. LoRaWAN FPort
4.6. LoRaWAN Empty Frame
4.7. Unicast and Multicast Technology
5. SCHC over LoRaWAN
5.1. LoRaWAN FPort and RuleID
5.2. RuleID Management
5.3. Interface IDentifier (IID) Computation
5.4. Padding
5.5. Decompression
5.6. Fragmentation
5.6.1. DTag
5.6.2. Uplink Fragmentation: From Device to SCHC Gateway
5.6.3. Downlink Fragmentation: From SCHC Gateway to Device
5.7. SCHC Fragment Format
5.7.1. All-0 SCHC Fragment
5.7.2. All-1 SCHC Fragment
5.7.3. Delay after Each LoRaWAN Frame to Respect Local
Regulation
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Examples
A.1. Uplink - Compression Example - No Fragmentation
A.2. Uplink - Compression and Fragmentation Example
A.3. Downlink
Acknowledgements
Contributors
Authors' Addresses1. Introduction 🌈
so the SCHC spec [RFC8724] lays out generic header compression and fragmentation techniques that work on all the LPWAN technologies defined in [RFC8376] 💅 These techs have a ton in common, like star-oriented topologies, the network architecture, and devices whose communications are pretty predictable. But they do differ a bit in payload sizes, reactiveness, and other stuff 🙈
SCHC gives you a generic framework so these devices can talk over IP networks ✨ For good performance though, some parameters and modes of operation need to be set properly for each LPWAN tech 🎀
this document is all about those parameters and modes of operation when SCHC runs over LoRaWAN networks 🫶 The LoRaWAN protocol is specified by the LoRa Alliance in [LORAWAN-SPEC] 💖
2. Terminology 💜
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 🔥 Only the capitalized versions carry that meaning, so don't go capitalizing them for vibes 😭
this section has the terminology and abbreviations used in this doc 🦋 For everything else, look up the SCHC spec [RFC8724] 🧚
Note: The SCHC acronym is pronounced like "sheek" in English (or "chic" in French). Therefore, this document writes "a SCHC Packet" instead of "an SCHC Packet". 🍓
- AppKey (Application Key): an AES-128 root key that's specific to each device 🔑
- AppSKey (Application Session Key): an AES-128 key derived from the AppKey for each new session 🔐 It's used to encrypt the payload field of a LoRaWAN applicative frame 💜
- DevAddr: a 32-bit non-unique identifier given to a device, either:
- statically, by the device manufacturer in "Activation-by-Personalization" mode, or
- dynamically, by the Network Gateway after a LoRaWAN "Join Procedure" in "Over-the-Air-Activation" mode 🌸
- DevEUI (Device Extended Unique Identifier): an IEEE EUI-64 identifier used to identify the device while it's joining the network (Join Procedure) 🎀 The manufacturer or the device owner assigns it, and it gets provisioned on the Network Gateway ✨
- Downlink: a LoRaWAN term for a frame sent by the network and received by the device 📩
- EUI: Extended Unique Identifier 🪪
- FRMPayload: the application data inside a LoRaWAN frame 🎁
- IID: Interface Identifier 🧩
- LoRaWAN: a wireless tech based on the Industrial, Scientific, and Medical (ISM) radio bands. It's built for long-range, low-power, low-data-rate apps and was developed by the LoRa Alliance, a membership consortium at
https://www.lora-alliance.org📡 - MSB: Most Significant Byte 🔢
- NGW: Network Gateway 🌐
- OUI: Organizationally Unique Identifier, which is an IEEE-assigned prefix for EUI 🏷️
- RCS: Reassembly Check Sequence. It's used to verify the integrity of the fragmentation-reassembly process 🛡️
- RGW: Radio Gateway 📻
- RX: a device's reception window 👂
- RX1/RX2: LoRaWAN class A devices open two RX windows after an uplink, called "RX1" and "RX2" 🪟🪟
- SCHC C/D: SCHC Compression/Decompression 🗜️
- SCHC F/R: SCHC Fragmentation/Reassembly 🧩
- SCHC gateway: the LoRaWAN Application Server that handles translation between an IPv6 network and the Network Gateway (LoRaWAN Network Server) 🚪
- Tile: a piece of a fragmented packet, as described in Section 8.2.2.1 of [RFC8724] 🍰
- Uplink: a LoRaWAN term for a frame sent by the device and received by the network ⬆️
3. SCHC Overview ✨
this section is a quick overview of SCHC 💖 For the full deal, check the full spec [RFC8724] 📖
SCHC defines:
- Compression mechanisms to avoid sending over the air any info that both sender and receiver already know. That known info is part of the "context". This component is called the "SCHC Compression/Decompression" (SCHC C/D) 🗜️
- Fragmentation mechanisms so a SCHC Packet can get transported over a small, and potentially variable, MTU. This component is called the "SCHC Fragmentation/Reassembly" (SCHC F/R) 🧩
context exchange or pre-provisioning is out of scope for this document 🙅♀️
Device App
+----------------+ +----+ +----+ +----+
| App1 App2 App3 | |App1| |App2| |App3|
| | | | | | | |
| UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | |
|SCHC C/D and F/R| | | | | | |
+--------+-------+ +----+ +----+ +----+
| +---+ +----+ +----+ +----+ . . .
+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....
+---+ +----+ |F/R | |C/D |
+----+ +----+
|<- - - - LoRaWAN - - ->|
Figure 1: ArchitectureFigure 1 shows the architecture for compression/decompression 🗺️ It's based on the terminology from [RFC8376] 📚 The device sends application flows using IPv6 or IPv6/UDP. Those flows might get compressed by a SCHC C/D to shrink the headers, and fragmented by the SCHC F/R 🧠 The result goes out in a Layer 2 (L2) frame to an LPWAN Radio Gateway (RGW), which forwards the frame to a Network Gateway (NGW) 📶 The NGW sends the data to a SCHC F/R for reassembly if it's needed, and then to a SCHC C/D for decompression 🎉 The SCHC C/D shares the same rules with the device 🤝
The SCHC C/D and SCHC F/R can live on the NGW or somewhere else, as long as there's communication between the NGW and the SCHC F/R, and then between the SCHC F/R and SCHC C/D 🏠 The SCHC C/D and SCHC F/R in the device and the SCHC gateway MUST share the same set of rules. That's a non-negotiable, bestie 🔒 After decompression, the packet can go out on the Internet to one or several LPWAN Application Servers (App) 🌍
the SCHC C/D and SCHC F/R process is bidirectional, so the same principles apply in the other direction 🔄
in LoRaWAN terminology, the RGW is called a "Gateway", the NGW is a "Network Server", and the SCHC C/D and SCHC F/R are one or more "Application Servers" 🎀 Application servers can be provided by the NGW or by any third-party software 🫶 Figure 1 maps to LoRaWAN terminology like this:
End Device App
+--------------+ +----+ +----+ +----+
|App1 App2 App3| |App1| |App2| |App3|
| | | | | | | |
| UDP | |UDP | |UDP | |UDP |
| IPv6 | |IPv6| |IPv6| |IPv6|
| | | | | | | |
|SCHC C/D & F/R| | | | | | |
+-------+------+ +----+ +----+ +----+
| +-------+ +-------+ +-----------+ . . .
+~ |Gateway| == |Network| == |Application|..... Internet ....
+-------+ |server | |server |
+-------+ | F/R - C/D |
+-----------+
|<- - - - - LoRaWAN - - - ->|
Figure 2: SCHC Architecture Mapped to LoRaWAN4. LoRaWAN Architecture ✨
okay so bestie, this section is where the LoRaWAN world meets the SCHC world 🦋. You can get the full LoRaWAN overview in [RFC8376], and the general LPWAN architecture entities come from [RFC8724]. Here's how the two sets of names line up 💅:
- Devices are LoRaWAN End Devices (sensors, actuators, that whole crew 🌸). A single radio gateway (LoRaWAN gateway) can have a very high density of them, which is honestly iconic. This entity maps to the LoRaWAN end device.
- The RGW is the endpoint of the constrained link. It maps to the LoRaWAN Gateway.
- The NGW is the interconnection node between the Radio Gateway and the SCHC gateway (the LoRaWAN Application Server). It maps to the LoRaWAN Network Server.
- The SCHC C/D and SCHC F/R are handled by the LoRaWAN Application Server 🫶.
- The LPWAN-AAA Server is the LoRaWAN Join Server. Its whole job is managing and delivering security keys safely, so the device's root key is never exposed 🔐.
(LPWAN-AAA Server)
() () () | +------+
() () () () / \ +---------+ | Join |
() () () () () / \======| ^ |===|Server| +-----------+
() () () | | <--|--> | +------+ |Application|
() () () () / \==========| v |=============| Server |
() () () / \ +---------+ +-----------+
End devices Gateways Network Server (SCHC C/D and F/R)
(devices) (RGW) (NGW)
Figure 3: LPWAN ArchitectureNote: Figure 3 terms are from LoRaWAN, with [RFC8376] terminology in brackets.
The SCHC C/D and SCHC F/R run on the LoRaWAN end device and on the Application Server (which is called the SCHC gateway) 🎀. The point-to-point link between the device and the Application Server is a single IP hop, but the real endpoint of the IP conversation might be an Internet node sitting past the Application Server 🌈. So basically, the LoRaWAN Application Server (SCHC gateway) acts as the first-hop IP router for the device. And if the Application Server and Network Server are co-located, that combined box becomes the first-hop IP router. Main character energy 👑.
4.1. Device Classes (A, B, C) and Interactions
The LoRaWAN Medium Access Control (MAC) layer supports three device classes, named A, B, and C 🧚. Every device implements Class A, and some devices may also implement Class B or Class C. Class B and Class C are mutually exclusive, so pick one 💜.
- Class A: this is the simplest class 🍓. The device can transmit at any time, randomly picking a communication channel. The Network Gateway may reply with a downlink in one of the two receive windows right after the uplinks. That means the Network Gateway cannot initiate a downlink on its own; it has to wait for the next uplink from the device to get a downlink opportunity. Class A is the lowest power consumption class, so it's giving efficiency 🔋.
- Class B: Class B devices do everything Class A devices do, but they also schedule periodic listen windows ⏰. Because of that, unlike Class A devices, Class B devices can receive downlinks that the Network Gateway starts without an uplink first. There's a trade-off between how often those scheduled Class B listen windows happen and how much power the device uses:
- High periodicity: downlinks from the NGW will be sent faster, but the device wakes up more often and power consumption goes up 📈.
- Low periodicity: downlinks from the NGW will have higher latency, but power consumption is lower 🌙.
- Class C: Class C devices do everything Class A devices do, but they keep their receiver open whenever they aren't transmitting 👀. They can receive downlinks at any time, but that costs more power. Battery-powered devices can only run in Class C for a limited amount of time (for example, for a firmware upgrade over-the-air) 🪫. Most Class C devices are grid powered (for example, Smart Plugs) 🔌.
4.2. Device Addressing
LoRaWAN end devices use a 32-bit network address (DevAddr) to talk to the Network Gateway over the air ✈️. This address might not be unique across a LoRaWAN network, which is a little drama 🙈. Devices that share the same DevAddr get told apart by the Network Gateway, using the cryptographic signature attached to every LoRaWAN frame.
To communicate with the SCHC gateway, the Network Gateway MUST identify the devices by a unique 64-bit device identifier called the "DevEUI" 💖. This part is non-negotiable, bestie.
The DevEUI is assigned to the device during manufacturing, by the device's manufacturer 🏭. It's 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 gets concatenated with a 40-bit serial number 🔢. The Network Gateway translates the DevAddr into a DevEUI in the uplink direction, and does the reverse in the downlink direction 🔄.
+--------+ +---------+ +---------+ +----------+
| Device | <=====> | Network | <====> | SCHC | <======> | Internet |
| | DevAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |
+--------+ +---------+ +---------+ +----------+
Figure 4: LoRaWAN Addresses4.3. General Frame Types
LoRaWAN lets you send confirmed or unconfirmed frames, and honestly both are cute in their own way 🎀.
- Confirmed frame: the sender asks the receiver to acknowledge the frame ✅.
- Unconfirmed frame: the sender does not ask the receiver to acknowledge the frame 🫠.
Since SCHC defines its own acknowledgment mechanisms, SCHC does not require the use of LoRaWAN Confirmed frames (FType = 0b100 as per [LORAWAN-SPEC]). So SCHC doesn't need them, periodt 💅.
4.4. LoRaWAN MAC Frames
On top of regular data frames, LoRaWAN has JoinRequest and JoinAccept frame types, which a device uses to join a network 🚪.
- JoinRequest: this frame is how a device joins a network. It carries the device's unique identifier, the DevEUI, plus a random nonce that gets used for session key derivation 🔑.
- JoinAccept: to onboard a device, the Network Gateway answers the device's JoinRequest with a JoinAccept frame ✨. That frame is encrypted with the device's AppKey, and it contains (among other fields) the network's major settings and a random nonce used to derive the session keys 🗝️.
- Data: this refers to MAC and application data. Application data is protected with AES-128 encryption 🔒. MAC-related data is AES-128 encrypted with another key, so it's got its own bodyguard 💪.
4.5. LoRaWAN FPort
The LoRaWAN MAC layer has 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's how LoRaWAN networks and applications tell their data apart 🧁.
4.6. LoRaWAN Empty Frame
A LoRaWAN empty frame is a LoRaWAN frame without an FPort (cf. Section 5.1) and without an FRMPayload 🫧.
4.7. Unicast and Multicast Technology
LoRaWAN supports unicast downlinks, but it also does multicast, which means one multicast packet sent over a LoRaWAN radio link can be received by several devices 📡. This is super useful for addressing lots of devices with the same content, like a big binary file (a firmware upgrade) or the same command (e.g., lighting control) 💡. And since IPv6 is also a multicast technology, this feature can be used to address a group of devices 🦋.
Note 1: IPv6 multicast addresses must be defined as per [RFC4291]. The LoRaWAN multicast group definition in a Network Gateway, and the relation between those groups and the IPv6 groupID, are out of scope of this document.
Note 2: The LoRa Alliance defined [LORAWAN-REMOTE-MULTICAST-SET] as the RECOMMENDED way to set up multicast groups on devices and create a synchronized reception window ⏱️.
5. SCHC over LoRaWAN
5.1. LoRaWAN FPort and RuleID
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 LoRaWAN payload to recompose the SCHC Message. No skipping this step, bestie 🙅.
| FPort | LoRaWAN payload |
+ ------------------------ +
| SCHC Message |
Figure 5: SCHC Message in LoRaWANNote: The SCHC Message is any datagram sent by the SCHC C/D or F/R layers.
A fragmented datagram with application payload that gets transferred from device to Network Gateway is called an "uplink-fragmented datagram" ⬆️. It uses an FPort for data uplink and its associated SCHC control downlinks, which this document calls "FPortUp". The other way around, a fragmented datagram with application payload transferred from Network Gateway to device is called a "downlink-fragmented datagram" ⬇️. It uses another FPort for data downlink and its associated SCHC control uplinks, which this document calls "FPortDown" 🎀.
All RuleIDs can use arbitrary values inside the FPort range that the LoRaWAN specification [LORAWAN-SPEC] allows, and they MUST be shared by the device and SCHC gateway before communication with the selected rule starts 🤝. The uplink and downlink fragmentation FPorts MUST be different 🙅♀️.
5.2. RuleID Management
The RuleID MUST be 8 bits and gets encoded in the LoRaWAN FPort, as described in Section 5.1 📦. LoRaWAN supports up to 223 application FPorts, in the range [1..223], as defined in Section 4.3.2 of [LORAWAN-SPEC]. That means the RuleID MSB SHOULD be inside this range 💜. An application can send non-SCHC traffic by using FPort values that differ from the ones used for SCHC 🌈.
In order to improve interoperability, these fragmentation RuleID values are RECOMMENDED ✨:
RuleID = 20(8-bit) for uplink fragmentation, named FPortUp.RuleID = 21(8-bit) for downlink fragmentation, named FPortDown.RuleID = 22(8-bit) for when SCHC compression was not possible (i.e., no matching compression Rule was found), as described in Section 6 of [RFC8724] 🙈.
The FPortUp value MUST be different from the FPortDown value 💖. The remaining RuleIDs are available for compression. RuleIDs are shared between uplink and downlink sessions. A RuleID that isn't in the set(s) of FPortUp or FPortDown means that fragmentation is not used, so on reception, the SCHC Message MUST be sent to the SCHC C/D layer 📨.
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 🙌.
An application can have multiple fragmented datagrams between a device and one or several SCHC gateways 🌸. A set of FPort values is REQUIRED for each SCHC gateway instance that the device is required to communicate with 🔑. The application can use additional uplink or downlink-fragmented parameters, but it SHALL implement at least the parameters defined in this document 💅.
The mechanism for context distribution across devices and gateways is outside the scope of this document 🫶.
5.3. Interface IDentifier (IID) Computation 🎀
okay so to protect against the risks in [RFC8064] and [RFC8065] 🫶, implementations MUST use this algorithm, and they SHOULD use it:
- key = LoRaWAN AppSKey
- cmac = aes128_cmac(key, DevEUI)
- IID = cmac[0..7]
aes128_cmac is described in [RFC4493] 💅. It was picked because devices already use it for LoRaWAN, so no new crypto needed, which is very efficient of them 🧚.
AppSKey gets renewed every time a device joins or rejoins a LoRaWAN network, so the IID changes over time too 🦋. That's a privacy win because it stops location tracking and correlation over time 😭. How often devices join is decided at the application level.
The AppSKey also adds entropy to the IID, which makes address scanning way harder 🔒.
And because of how the algorithm works, the hardware identifier (DevEUI) and the IID are not correlated at all. So an attacker can't use the manufacturer OUI to target devices 💀✨.
Here's an example with:
- DevEUI:
0x1122334455667788 - AppSKey:
0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
- key:
0x00AABBCCDDEEFF00AABBCCDDEEFFAABB - cmac:
0x4E822D9775B2649928F82066AF804FEC - IID:
0x4E822D9775B26499
Figure 6: Example of IID ComputationIID collisions are possible in a LoRaWAN network, but the chance is small 🙈. If one does happen, you can change the IID by rekeying the device at the L2 level, which means triggering a LoRaWAN join. How the device gets rekeyed is out of scope for this document and left up to the implementation 🌸.
Note: Implementations also using another IID source MUST 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.
5.4. Padding 🍓
All padding bits MUST be 0 ✨. No exceptions bestie.
5.5. Decompression 🧚
The SCHC C/D MUST concatenate FPort and LoRaWAN payload to rebuild the SCHC Packet, as per Section 5.1 💖.
RuleIDs that match FPortUp and FPortDown are reserved for SCHC fragmentation 🔥. So those are off limits for anything else.
5.6. Fragmentation 💜
The L2 Word Size used by LoRaWAN is 1 byte (8 bits) 🌈. SCHC fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink fragmentation and the ACK-Always mode for downlink fragmentation. A LoRaWAN device cannot support simultaneous interleaved fragmented datagrams in the same direction (uplink or downlink) 😭.
The fragmentation parameters are different for uplink-fragmented and downlink-fragmented datagrams, and we'll go through each one in the next sections 👑.
5.6.1. DTag 🎀
Section 8.2.4 of [RFC8724] talks about interleaving several fragmented SCHC datagrams for the same RuleID. That's not used in the SCHC-over-LoRaWAN profile, so a device cannot interleave several fragmented SCHC datagrams on the same FPort 🙅♀️. This field isn't used, and its size is 0.
Note: The device can still have several parallel fragmented datagrams with more than one SCHC gateway thanks to distinct sets of FPorts, cf. Section 5.2.
5.6.2. Uplink Fragmentation: From Device to SCHC Gateway 🦋
In this case the device is the fragment transmitter and the SCHC gateway is the fragment receiver 📡. There's a single fragmentation rule. The SCHC F/R MUST concatenate FPort and LoRaWAN payload to rebuild the SCHC Packet, as per Section 5.1 💅.
SCHC fragmentation reliability mode: "ACK-on-Error".
SCHC header size: 2 bytes (the FPort byte + 1 additional byte).
RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2).
DTag: Size T = 0 bits, not used (cf. Section 5.6.1).
Window index: 4 windows are used, encoded on M = 2 bits.
FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63 tiles are allowed in a window.
Last tile: It can be carried in a Regular SCHC Fragment, alone in an All-1 SCHC Fragment, or with either of these two methods. Implementations must ensure that:
- 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.
- If the last tile is in an All-1 SCHC Message, the current L2 MTU MUST be big enough to fit the All-1 header and the last tile.
Penultimate tile: MUST be equal to the regular size 🫶.
RCS: Use the recommended calculation algorithm in Section 8.2.3 of [RFC8724], Integrity Checking 🔍.
Tile: Size is 10 bytes.
Retransmission timer: Set by the implementation depending on the application 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 ⏰.
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 🌙.
MAX_ACK_REQUESTS: 8. With this set of parameters, the SCHC Fragment Header is 16 bits, including FPort. Payload overhead will be 8 bits, since FPort is already part of the LoRaWAN payload. MTU is: 4 windows * 63 tiles * 10 bytes per tile = 2520 bytes 🧮.
In addition to the per-rule context parameters specified in [RFC8724], uplink rules get one more context parameter: whether or not to ack after each window. For battery-powered devices, it is RECOMMENDED to use the ACK mechanism at the end of each window instead of waiting until the end of all windows 🔋:
- The SCHC receiver SHOULD send a SCHC ACK after every window, even if there is no missing tile.
- The SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver before sending tiles from the next window. If the SCHC ACK is not received, it SHOULD send a SCHC ACK REQ up to MAX_ACK_REQUESTS times, as described previously.
This avoids useless uplinks if the device has lost network coverage 📶.
For non-battery-powered devices, the SCHC receiver MAY also choose to send a SCHC ACK only at the end of all windows. This reduces downlink load on the LoRaWAN network by cutting down the number of downlinks 📉.
SCHC implementations MUST be compatible with both behaviors, and this selection is part of the rule context 💖.
5.6.2.1. Regular Fragments 🌸
Figure 7 is an example of a regular fragment, for all fragments except the last one. The SCHC Header Size is 16 bits, including the LoRaWAN FPort.
| FPort | LoRaWAN payload |
+ ------ + ------------------------- +
| RuleID | W | FCN | Payload |
+ ------ + ------ + ------ + ------- +
| 8 bits | 2 bits | 6 bits | |
Figure 7: All Fragments Except the Last One.5.6.2.2. Last Fragment (All-1) 🏁
The following figures are examples of All-1 messages. Figure 8 is without the last tile, and Figure 9 is with the last tile 🎯.
| FPort | LoRaWAN payload |
+ ------ + ---------------------------- +
| RuleID | W | FCN=All-1 | RCS |
+ ------ + ------ + --------- + ------- +
| 8 bits | 2 bits | 6 bits | 32 bits |
Figure 8: All-1 SCHC Message without Last Tile| FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------------------- +
| 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 |
Figure 9: All-1 SCHC Message with Last Tile5.6.2.3. SCHC ACK ✅
| FPort | LoRaWAN payload |
+ ------ + --------------------------+
| RuleID | W | C = 1 | padding |
| | | | (b'00000) |
+ ------ + ----- + ----- + --------- +
| 8 bits | 2 bit | 1 bit | 5 bits |
Figure 10: SCHC ACK Format - Correct RCS Check| FPort | LoRaWAN payload |
+ ------ + --------------------------------- + ---------------- +
| RuleID | W | C = 0 | Compressed bitmap | Optional padding |
| | | | (C = 0) | (b'0...0) |
+ ------ + ----- + ----- + ----------------- + ---------------- +
| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6, or 7 bits |
Figure 11: SCHC ACK Format - Incorrect RCS CheckNote: Because of the bitmap compression mechanism and L2 byte alignment, only the following discrete values are possible for the compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62, and 63. Bitmaps of 63 bits will require 6 bits of padding.
5.6.2.4. Receiver-Abort 🚨
| FPort | LoRaWAN payload |
+ ------ + -------------------------------------------- +
| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |
+ ------ + -------- + ------+-------- + ----------------+
| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> |
Figure 12: Receiver-Abort Format5.6.2.5. SCHC Acknowledge Request 🙋♀️
| FPort | LoRaWAN payload |
+------- +------------------------- +
| RuleID | W | FCN = b'000000 |
+ ------ + ------ + --------------- +
| 8 bits | 2 bits | 6 bits |
Figure 13: SCHC ACK REQ Format5.6.3. Downlink Fragmentation: From SCHC Gateway to Device 📥
In this case the device is the fragmentation receiver and the SCHC gateway is the fragmentation transmitter 📡. The following fields are common to all devices. The SCHC F/R MUST concatenate FPort and LoRaWAN payload to rebuild the SCHC Packet, as described in Section 5.1 💕.
SCHC fragmentation reliability mode:
- Unicast downlinks: ACK-Always.
- Multicast downlinks: No-ACK. Reliability has to be ensured by the upper layer. This feature is OPTIONAL for the SCHC gateway and REQUIRED for the device.
RuleID: 8 bits stored in the LoRaWAN FPort (cf. Section 5.2).
DTag: Size T = 0 bit, not used (cf. Section 5.6.1).
FCN: The FCN field is encoded on N = 1 bit, so WINDOW_SIZE = 1 tile.
RCS: Use the recommended calculation algorithm in Section 8.2.3 of [RFC8724], Integrity Checking 🔍.
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 ⏳.
The following parameters apply to ACK-Always (Unicast) only:
Retransmission timer: See Section 5.6.3.5.
MAX_ACK_REQUESTS: 8.
Window index (unicast only): encoded on M = 1 bit, as per [RFC8724].
As only one tile is used, its size can change for each downlink and will be the currently available MTU 🧩.
Class A devices can only receive during an RX slot, which follows the transmission of an uplink. So the SCHC gateway cannot initiate communication (e.g., start a new SCHC session) 🙃. 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 uplink is a LoRaWAN empty frame as defined in Section 4.6. Since this uplink is sent only to open an RX window, any LoRaWAN uplink frame from the device MAY reset this counter 🪄.
Note: The FPending bit included in the LoRaWAN protocol SHOULD NOT be used for the SCHC-over-LoRaWAN protocol. It might be set by the Network Gateway for other purposes but not SCHC needs.
5.6.3.1. Regular Fragments 💖
okay so this one is for every fragment except the last. Figure 14 shows the layout. The SCHC Header Size is 10 bits, and that includes the LoRaWAN FPort 🦋
| FPort | LoRaWAN payload |
+ ------ + ------------------------------------ +
| RuleID | W | FCN = b'0 | Payload |
+ ------ + ----- + --------- + ---------------- +
| 8 bits | 1 bit | 1 bit | X bytes + 6 bits |Figure 14: All Fragments but the Last One.
5.6.3.2. Last Fragment (All-1) 🎀
the last fragment is the main character moment 👑 Its FCN is b'1 and it carries an RCS field. Figure 15 has the whole thing.
| FPort | LoRaWAN payload |
+ ------ + --------------------------- + ------------------------- +
| 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 |Figure 15: All-1 SCHC Message: The Last Fragment
5.6.3.3. SCHC ACK 🌸
the ACK comes in two flavours depending on whether the RCS check passed 🙈 Figure 16 is the correct-RCS version and Figure 17 is the incorrect-RCS one.
| FPort | LoRaWAN payload |
+ ------ + ---------------------------------- +
| RuleID | W | C = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ---------------- +
| 8 bits | 1 bit | 1 bit | 6 bits |Figure 16: SCHC ACK Format - Correct RCS Check
| FPort | LoRaWAN payload |
+ ------ + ------------------------------------------------- +
| RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 |
+ ------ + ----- + ------- + ------------ + ---------------- +
| 8 bits | 1 bit | 1 bit | 1 bit | 5 bits |Figure 17: SCHC ACK Format - Incorrect RCS Check
5.6.3.4. Receiver-Abort 💀
Figure 18 shows a Receiver-Abort packet. It follows an All-1 SCHC Fragment whose RCS was incorrect. Honestly this is the "we're done here" packet 🫶
| FPort | LoRaWAN payload |
+ ------ + ---------------------------------------------- +
| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |
+ ------ + ------- + ------- + -------- + --------------- +
| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |
next L2 Word boundary ->| <-- L2 Word --> |Figure 18: Receiver-Abort Packet
5.6.3.5. Downlink Retransmission Timer ⏰
okay the timers are where things get spicy 🌶️ Class A, Class B, and Class C devices don't handle retransmissions and timers the same way, so we're splitting it up.
5.6.3.5.1. Class A Devices 🦋
Class A devices can only receive in an RX slot that comes right after they send an uplink. That's their whole vibe 🧚
The SCHC gateway runs an inactivity timer with a RECOMMENDED duration of 36 hours. For devices that barely transmit (say, 1 packet a day in normal operation), that duration may be extended. It's application specific, so it depends on the app 🍓
RETRANSMISSION_TIMER is application specific too. Its RECOMMENDED value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).
SCHC All-0 (FCN = 0)
All fragments but the last have an FCN = 0, because the window size is 1 ✨ After an All-0 SCHC Fragment, the device MUST transmit the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC ACK messages before aborting. To move the fragmented datagram along, the SCHC layer should immediately queue those SCHC ACK messages for transmission if no SCHC downlink has been received during the RX1 and RX2 windows. The LoRaWAN layer will respect the applicable local spectrum regulation 🌈
Note: The ACK bitmap is 1 bit long and is always 1.
SCHC All-1 (FCN = 1)
SCHC All-1 is the last fragment of a datagram, and its SCHC ACK might get lost. So 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 interval of 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 Section 4.6), but that's still application specific, and the NGW will use it to transmit a potential SCHC ACK REQ 🔥 SCHC_ACK_REQ_DN_OPPORTUNITY is application specific too, and its recommended value is 2. It MUST be greater than 1. That's what lets a downlink opportunity open for any downlink with higher priority than the SCHC ACK REQ message 👑
Note: 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 SCHC ACK REQ. That's how it knows the SCHC gateway got the SCHC ACK message 💅
5.6.3.6. Class B or Class C Devices 🌙
Class B devices can receive in scheduled RX slots or in RX slots that follow an uplink transmission. Class C devices are almost in constant reception, so they're basically always listening 👀
RECOMMENDED retransmission timer values are:
- Class B: 3 times the ping slot periodicity.
- Class C: 30 seconds.
The RECOMMENDED inactivity timer value is 12 hours for both Class B and Class C devices 🎀
5.7. SCHC Fragment Format 🧚
5.7.1. All-0 SCHC Fragment 🫧
Uplink Fragmentation (Ack-on-Error):
All-0 is distinguishable from a SCHC ACK REQ. [RFC8724] states "This condition is also met if the SCHC Fragment Header is a multiple of L2 Words", and the following condition is met: the SCHC header is 2 bytes. Ate, no notes 💜
Downlink fragmentation (ACK-Always):
As per [RFC8724], SCHC All-1 MUST contain the last tile, and implementations MUST ensure that the SCHC All-0 message Payload is at least the size of an L2 Word 🍓
5.7.2. All-1 SCHC Fragment 💅
All-1 is distinguishable from a SCHC Sender-Abort. [RFC8724] states "This condition is met if the RCS is present and is at least the size of an L2 Word", and the following condition is met: the RCS is 4 bytes ✨
5.7.3. Delay after Each LoRaWAN Frame to Respect Local Regulation 🌈
This profile doesn't define any delay to add after each LoRaWAN frame. Local regulation compliance is expected to be enforced by the LoRaWAN stack, so that's where it lives 🫶
6. Security Considerations 🔐
This document only provides parameters that are expected to be best suited for LoRaWAN networks for [RFC8724]. IID security is discussed in Section 5.3. As such, this document doesn't add any new security issues beyond the ones already identified in [RFC8724]. Moreover, SCHC data (LoRaWAN payload) is protected at the LoRaWAN level by AES-128 encryption with a session key shared by the device and the SCHC gateway. These session keys are renewed at each LoRaWAN session (that is, each join or rejoin to the LoRaWAN network). Keep your keys fresh, bestie, it's a whole vibe 🔑💖
7. IANA Considerations 🌸
This document has no IANA actions. Nothing to register here, babe ✨
8. References 📚
8.1. Normative References
- [LORAWAN-SPEC] LoRa Alliance, "LoRaWAN 1.0.4 Specification Package",
https://lora-alliance.org/resource_hub/lorawan-104-specification-package/. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
https://www.rfc-editor.org/info/rfc2119. - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
https://www.rfc-editor.org/info/rfc4291. - [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006,
https://www.rfc-editor.org/info/rfc4493. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
https://www.rfc-editor.org/info/rfc8174. - [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zúñiga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020,
https://www.rfc-editor.org/info/rfc8724.
8.2. Informative References
- [LORAWAN-REMOTE-MULTICAST-SET] LoRa Alliance, "LoRaWAN Remote Multicast Setup Specification v1.0.0",
https://lora-alliance.org/resource_hub/lorawan-remote-multicast-setup-specification-v1-0-0/. - [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017,
https://www.rfc-editor.org/info/rfc8064. - [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017,
https://www.rfc-editor.org/info/rfc8065. - [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
https://www.rfc-editor.org/info/rfc8376.
Appendix A. Examples 🧁
In the following examples, "applicative data" refers to the IPv6 payload sent by the application to the SCHC layer.
A.1. Uplink - Compression Example - No Fragmentation 🌟
This example shows applicative data going through SCHC over LoRaWAN. No fragmentation is required.
An applicative data of 78 bytes is passed to the SCHC compression layer. Rule 1 is used by the SCHC C/D layer, which compresses it to 40 bytes and 5 bits: 1 byte RuleID, 21 bits residue, and 37 bytes payload.
| RuleID | Compression residue | Payload | Padding=b'000 |
+ ------ + ------------------- + --------- + ------------- +
| 1 | 21 bits | 37 bytes | 3 bits |Figure 19: Uplink Example: SCHC Message
The current LoRaWAN MTU is 51 bytes, although the LoRaWAN protocol uses 2-byte FOpts: that leaves 49 bytes for the SCHC payload, so no fragmentation is needed. The payload will be transmitted through FPort = 1 🎀
| LoRaWAN Header | LoRaWAN payload (40 bytes) |
+ ------------------------- + --------------------------------------- +
| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |
| | | | residue | | |
+ ---- + ------- + -------- + ----------- + --------- + ------------- +
| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |Figure 20: Uplink Example: LoRaWAN Packet
A.2. Uplink - Compression and Fragmentation Example ✨
okay so this one is the big-brain example 🧠💅 we're sending applicative data through SCHC, and this time it gets fragmented too.
a 300-byte applicative data goes into the SCHC compression layer. Rule 1 is used by the SCHC C/D layer, and it compresses the data down to 282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload. 🦋
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- +
| 1 | 21 bits | 279 bytes |
Figure 21: Uplink Example: SCHC Messagethe current LoRaWAN MTU is 11 bytes 🥺 and 0-byte FOpts are used by the LoRaWAN protocol, so 11 bytes are available for SCHC payload + 1 byte FPort field. the SCHC header is 2 bytes (including FPort), so 1 tile gets sent in the first fragment. 🌸
| LoRaWAN Header | LoRaWAN payload (11 bytes) |
+ -------------------------- + -------------------------- +
| | RuleID=20 | W | FCN | 1 tile |
+ -------------- + --------- + ----- + ------ + --------- +
| XXXX | 1 byte | 0 0 | 62 | 10 bytes |
Figure 22: Uplink Example: LoRaWAN Packet 1the tile content is described in Figure 23 🎀
Content of the tile is:
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + ----------------- +
| 1 | 21 bits | 6 bytes + 3 bits |
Figure 23: Uplink Example: First Tile Contentnext up, the transmission MTU is 11 bytes, but now 2-byte FOpts are used by the LoRaWAN protocol. that leaves 9 bytes for SCHC payload + 1 byte FPort field, so a tile does not fit inside and the LoRaWAN stack will send only FOpts. it's giving "not this time" 🙈
the next transmission MTU is 242 bytes with 4-byte FOpts, and 23 tiles get transmitted. slay 🔥
| LoRaWAN Header | LoRaWAN payload (231 bytes) |
+ --------------------------------------+ --------------------------- +
| | FOpts | RuleID=20 | W | FCN | 23 tiles |
+ -------------- + ------- + ---------- + ----- + ----- + ----------- +
| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |
Figure 24: Uplink Example: LoRaWAN Packet 2the next transmission MTU is 242 bytes with no FOpts. all 5 remaining tiles get transmitted, and the last tile is only 2 bytes + 5 bits. padding is added for the remaining 3 bits, which is very much a "fill the gap" moment 🧚
| LoRaWAN Header | LoRaWAN payload (44 bytes) |
+ ---- + ---------- + ----------------------------------------------- +
| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 |
+ ---- + ---------- + ----- + ----- + --------------- + ------------- +
| XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits |
Figure 25: Uplink Example: LoRaWAN Packet 3then the All-1 message can be transmitted 🫶
| LoRaWAN Header | LoRaWAN payload (44 bytes) |
+ ---- + -----------+ -------------------------- +
| | RuleID=20 | W | FCN | RCS |
+ ---- + ---------- + ----- + ----- + ---------- +
| XXXX | 1 byte | 0 0 | 63 | 4 bytes |
Figure 26: Uplink Example: LoRaWAN Packet 4 - All-1 SCHC Messageall the packets have been received by the SCHC gateway, and the computed RCS is correct, so the SCHC receiver sends the following ACK to the device. the whole thing is so satisfying 😭💖
| LoRaWAN Header | LoRaWAN payload |
+ -------------- + --------- + ------------------- +
| | RuleID=20 | W | C | Padding |
+ -------------- + --------- + ----- + - + ------- +
| XXXX | 1 byte | 0 0 | 1 | 5 bits |
Figure 27: Uplink Example: LoRaWAN Packet 5 - SCHC ACKA.3. Downlink 🌈
okay now we flip it and go downlink 🙌 a 155-byte applicative data goes into the SCHC compression layer. Rule 1 is used by the SCHC C/D layer, which compresses it to 130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload. 💜
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + --------- +
| 1 | 21 bits | 127 bytes |
Figure 28: Downlink Example: SCHC Messagethe current LoRaWAN MTU is 51 bytes, and no FOpts are used by the LoRaWAN protocol. that means 51 bytes are available for SCHC payload + FPort field, but the applicative data still has to be fragmented 🍓
| LoRaWAN Header | LoRaWAN payload (51 bytes) |
+ ---- + ---------- + -------------------------------------- +
| | RuleID=21 | W = 0 | FCN = 0 | 1 tile |
+ ---- + ---------- + ------ + ------- + ------------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |
Figure 29: Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1the tile content is described in Figure 30 🎀
| RuleID | Compression residue | Payload |
+ ------ + ------------------- + ------------------ +
| 1 | 21 bits | 48 bytes and 1 bit |
Figure 30: Downlink Example: First Tile Contentthe receiver answers with a SCHC ACK 💅
| LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
Figure 31: Downlink Example: LoRaWAN Packet 2 - SCHC ACKthe second downlink is sent with two FOpts ✨
| LoRaWAN Header | LoRaWAN payload (49 bytes) |
+ --------------------------- + ------------------------------------- +
| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |
+ ---- + ------- + ---------- + ----- + ------- + ------------------- +
| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |
Figure 32: Downlink Example: LoRaWAN Packet 3 - SCHC Fragment 2the receiver answers with a SCHC ACK 🫧
| LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
Figure 33: Downlink Example: LoRaWAN Packet 4 - SCHC ACKthe last downlink is sent with no FOpts 🥹
| LoRaWAN Header | LoRaWAN payload (37 bytes) |
+ ---- + ------- + -------------------------------------------------- +
| | RuleID | W | FCN | RCS | 1 tile | Padding |
| | 21 | 0 | 1 | | | b'00000 |
+ ---- + ------- + ----- + ----- + ------- + -------------- + ------- +
| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bit | 5 bits |
Figure 34: Downlink Example: LoRaWAN Packet 5 - All-1 SCHC Messagethe receiver answers to the sender with a SCHC ACK, and that's the whole downlink journey 🏁
| LoRaWAN Header | LoRaWAN payload |
+ ---- + --------- + -------------------------------- +
| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
+ ---- + --------- + ----- + ----- + ---------------- +
| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
Figure 35: Downlink Example: LoRaWAN Packet 6 - SCHC ACKAcknowledgements 🙏
thank you to everyone in the Contributors Section for the excellent text, insightful discussions, reviews, and suggestions 💖 and also a huge shout-out, in alphabetical order, to Dominique Barthel, Arunprabhu Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, and Laurent Toutain for the useful design considerations, reviews, and comments. you all are literally iconic 👑
LoRaWAN is a registered trademark of the LoRa Alliance. ™
Contributors 🫶
Contributors are ordered by family name.
Vincent Audebert EDF R&D
Email: vincent.audebert@edf.fr
Julien Catalano Kerlink
Email: j.catalano@kerlink.fr
Michael Coracin Semtech
Email: mcoracin@semtech.com
Marc Le Gourrierec Sagemcom
Email: marc.legourrierec@sagemcom.com
Nicolas Sornin Chirp Foundation
Email: nicolas.sornin@chirpfoundation.org
Alper Yegin Actility
Email: alper.yegin@actility.com
Authors' Addresses 💌
Olivier Gimenez (editor) Semtech 14 Chemin des Clos Meylan France
Email: ogimenez@semtech.com
Ivaylo Petrov (editor) Acklio 1137A Avenue des Champs Blancs 35510 Cesson-Sévigné Cedex France
Email: ivaylo@ackl.io
📦 where this page comes from
- ietf: rfc9011 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms