RFC 9442
Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)
📬 RFC 9442: Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN) 🦋
okay bestie, let's get into it 💖 This one is an Internet Standards Track document, so it's a real spec people build against. 🔥
Here's the title block tea ☕:
- Number and title: RFC 9442, Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN) ✨
- Authors: JC. Zúñiga, C. Gomez, S. Aguilar (Universitat Politècnica de Catalunya), L. Toutain (IMT-Atlantique), S. Céspedes (Concordia University), D. Wistuba (NIC Labs, Universidad de Chile), and J. Boite (Unabiz (Sigfox)) 👑
- Category: Standards Track 💜
- Date: July 2023 🍓
- Stream: the ISSN is 2070-1721 🦋
- Obsoletes and updates: nothing listed in this title block, so no drama here 🌸
1. Introduction 🌈
So the big picture: the Generic SCHC framework from [RFC8724] works with any of the four LPWAN technologies in [RFC8376]. They're all pretty similar, with star topologies, connected devices running their own apps, and so on 🧚
BUT (and it's a big but 💅) each LPWAN has its own transmission quirks and payload sizes. So there are optimal parameters and modes of operation for each one when you pair it with SCHC. ✨
Sigfox is the one this doc is about. It's super energy-efficient and cheap for devices 💖 Full Sigfox docs are at [sigfox-docs]. Its Base Stations pick up short Uplink messages (up to 12 bytes) sent over the long-range Sigfox radio protocol from [RFC8376]. Then they forward everything to the Sigfox Cloud for things like geolocation and final delivery to the customer 🌸 Base Stations also relay Downlink messages, which are a fixed 8 bytes. Downlinks only get generated when a device explicitly asks for one using a flag in an Uplink message 🙈 With SCHC on top, Sigfox gets more reliable comms, including recovering lost messages, and it can carry bigger payloads by fragmenting and reassembling them [sigfox-spec] 🔥
This document defines the parameters, settings, and modes of operation for running SCHC over Sigfox. That set of parameters is called the "SCHC over Sigfox Profile" 🎀 It applies to Sigfox Radio specification versions up to v1.6/March 2022 [sigfox-spec]. Support for future versions would have to be assessed, so no promises there 💀
2. Terminology 📖
Okay, the key words. These are capitalized on purpose, and they carry real weight. The document uses them in the BCP 14 sense from [RFC2119] and [RFC8174], but only when they show up in all caps, exactly as listed here:
- "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 🫶
Also, the reader is expected to already know the terms and mechanisms from [RFC8376] and [RFC8724], plus Sigfox terminology from [sigfox-spec] 🧠
3. SCHC over Sigfox 🛰️
The Generic SCHC Framework from [RFC8724] uses what's already known about the traffic flows in LPWAN apps, so it can skip context synchronization 🦋
Contexts have to be stored and pre-configured at both ends. You can do that with a provisioning protocol, out-of-band, or by pre-provisioning them (for example, at manufacturing time) ✨ Some examples of provisioning protocols are NETCONF [RFC6241] over SSH, RESTCONF [RFC8040] over secure HTTP methods, and CORECONF [CORE-COMI] over CoAP [RFC7252]. Contexts can be encoded in XML under NETCONF, in JSON [RFC8259] under RESTCONF, and in CBOR [RFC8949] under CORECONF 💜 How contexts get configured and stored on both ends is out of scope for this document, so that's a different story 🙈
3.1. Network Architecture 🗺️
Figure 1 shows the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R), using the terminology from [RFC8376]. The Radio Gateway (RGW) is a Sigfox Base Station, and the Network Gateway (NGW) is the cloud-based Sigfox Network 💅
Sigfox Device Application
+----------------+ +--------------+
| APP1 APP2 APP3 | |APP1 APP2 APP3|
+----------------+ +--------------+
| UDP | | | | UDP |
| IPv6 | | | | IPv6 |
+--------+ | | +--------+
| SCHC C/D & F/R | | |
| | | |
+-------+--------+ +--------+-----+
$ .
$ +---------+ +--------------+ +---------+ .
$ | | | Network | | Network | .
+~~ |Sigfox BS| | Gateway | | SCHC | .
| (RGW) | === | (NGW) | ... |C/D & F/R|.....
| | | Sigfox Cloud | | | IP-based
+---------+ +--------------+ +---------+ Network
------- Uplink message ------>
<------- Downlink message ------
Legend:
$, ~ : Radio link
= : Internal Sigfox Network
. : External IP-based Network
Figure 1: Network ArchitectureNow, about the topology 🌍 The RGWs (Base Stations) are spread across many countries wherever Sigfox service exists. The NGW (the cloud-based Sigfox Core Network) is one single entity that connects to all the RGWs in the world. So it's a global, single star network topology 🌟
Here's the flow ✨ The Sigfox Device sends application packets that get compressed and/or fragmented by SCHC C/D + F/R, to shrink the header and/or split up the packet. The result is a SCHC message sent in a layer two (L2) Sigfox frame to the Base Stations, which forward it to the NGW. The NGW then hands the SCHC message plus its gathered metadata to the Network SCHC C/D + F/R 🎀
The Sigfox cloud Network talks to the Network SCHC C/D + F/R for compression/decompression and/or fragmentation/reassembly. The Network SCHC C/D + F/R uses the same set of Rules as the device SCHC C/D + F/R 💖 It can live in the same place as the NGW, or somewhere else, as long as there's a tunnel or secured communication between the NGW and the SCHC C/D + F/R functions 🔐 Once it's decompressed and/or reassembled, the packet can go over the Internet to one or several LPWAN Application Servers (App(s)) 🦋
Last thing in this part: the SCHC C/D + F/R processes work both ways, so the same principles apply to Uplink (UL) and Downlink (DL) 🫶
Part 1 of 8. Next up: the rest of Section 3, starting with 3.2. Uplink. Stay tuned, bestie! 💅🌈
3.5.1.3. Single-Byte SCHC Header for Uplink Fragmentation
Okay bestie, this part is where the fragmentation game gets serious 💅 Let's go through every single detail, no skipping, because the spec is the spec 🫶
3.2. Uplink
Okay so, uplink on Sigfox is giving repetition queen energy 👑 Messages go out multiple times, across different times and frequencies, and they can even get caught by several Base Stations at once. That's spatial diversity, babe 🦋 The Uplink message application payload can be up to 12 bytes 🎀
Since every message is self-contained and the Base Stations forward all of them back to the same Sigfox network, the NGW can combine those multiple copies. That gives you extra reliability from the triple diversity: time, space, and frequency 🌈 Literally so iconic ✨
For the full radio protocol deets, check [sigfox-spec] 📖
Messages going from the device to the Network get delivered by the Sigfox cloud Network to the Network SCHC C/D + F/R through a callback/API, and each one comes with this info 💌
- Device ID
- Message Sequence Number
- Message Payload
- Message Timestamp
- Device Geolocation (optional)
- Received Signal Strength Indicator (RSSI) (optional)
- Device Temperature (optional)
- Device Battery Voltage (optional)
The Device ID is a globally unique identifier assigned to the device, and it rides along in the Sigfox header of every message 🪪 The Message Sequence Number is a monotonically increasing number that identifies that specific transmission of this Uplink message, and it's also part of the Sigfox header 🔢 The Message Payload is whatever the device sent in the Uplink transmission 📦 Battery Voltage, Device Temperature, and RSSI values show up in the confirmation control message, which the device MUST send after successfully receiving a Downlink message (see [sigfox-callbacks], Section 5.2) 🔋
Wait, hold on, let me say that again slowly: the device is mandatorily sending that confirmation, so this is not optional for it 😭
The Message Timestamp, Device Geolocation, RSSI, Device Temperature, and Device Battery Voltage are all metadata parameters provided by the Network 🧚
For the callbacks/APIs in detail, see [sigfox-callbacks] 📚
Only messages that passed the L2 Cyclic Redundancy Check (CRC) at Network reception get delivered by the Sigfox network to the Network SCHC C/D + F/R. No CRC pass, no entry 🚫
The L2 Word size used by Sigfox is 1 byte (8 bits) 🍓
Figure 2 shows a SCHC message sent over Sigfox. The SCHC message could be a full SCHC Packet (like compressed) or a SCHC Fragment (a piece of a bigger SCHC Packet) 🧩
| Sigfox Header | Sigfox Payload |
+---------------+---------------- +
| SCHC Message |
Figure 2: SCHC Message in Sigfox3.3. Downlink
Downlink is device-driven, which means it can only happen right after an Uplink that says "hey, Downlink is allowed now" 🙋♀️ So a Sigfox Device explicitly indicates it wants to receive a Downlink message (8 bytes) by setting a Downlink request flag in the preceding Uplink message 🚩 That flag is part of the Sigfox protocol headers 💅
After the Uplink finishes, the device opens a fixed window for Downlink reception. The delay and duration of that window have fixed values ⏰ If there's a Downlink message waiting for this device (like a response to the Uplink, or something queued up), the Network sends it during that window 📬 If nothing arrives before the window closes, the device shuts it down and goes back to normal mode, like continuing Uplinks, sleeping, or standing by 😴
When a Downlink message is sent to a device, the device generates a reception acknowledgement, sends it back to the Network through the Sigfox radio protocol, and it gets reported in the Sigfox network backend 🫡
More details: the radio protocol is in [sigfox-spec], and the callbacks/APIs are in [sigfox-callbacks] 🌸 A Downlink request flag can also be included in the information exchange between the Sigfox network and Network SCHC 💜
3.3.1. SCHC ACK on Downlink
Okay so as we said, Downlink can only happen after a specific Uplink that opens up a Downlink opportunity 🎟️ That's why, when SCHC bidirectional services are used (like ACK-on-Error fragmentation mode), the SCHC protocol implementation has to think about when a Downlink message, such as a SCHC Acknowledgement (ACK), can be sent and/or received ⏳
For Uplink ACK-on-Error fragmentation mode, a Downlink opportunity MUST be indicated by the last fragment of every window. That's flagged by a specific Fragment Compressed Number (FCN) value, FCN = All-0 or FCN = All-1 🚨 The FCN is the tile index within a specific window. The combination of the FCN and the window number uniquely identifies a SCHC Fragment, as explained in [RFC8724] 🧁
The device sends fragments in sequence, and after transmitting FCN = All-0 or FCN = All-1, it opens up a reception opportunity 🪟 The Network SCHC can then decide to respond at that opportunity (or wait for a later one) with a SCHC ACK, which says that there are missing fragments from the current or previous windows 🕵️♀️ If there's no SCHC ACK to send, or if the Network decides to wait for another Downlink transmission opportunity, then no Downlink transmission happens at that opportunity, and the Uplink transmissions continue after a timeout ⏱️ Intermediate SCHC Fragments with FCNs other than All-0 or All-1 MUST NOT use the Downlink request flag to request a SCHC ACK 🙅♀️
3.4. SCHC Rules
The RuleID MUST be included in the SCHC header 🏷️ The total number of Rules used directly affects the RuleID field size, and therefore the total size of the fragmentation header 📏 For this reason, it is RECOMMENDED to keep the number of Rules defined for a specific device to the minimum possible 🤏 Large RuleID sizes (and thus larger fragmentation headers) are acceptable for devices without significant energy constraints, like a sensor powered by the electricity grid ⚡
RuleIDs can be used to differentiate data traffic classes (like QoS, control vs. data, etc.) and data sessions 🗂️ They can also be used to interleave simultaneous fragmentation sessions between a device and the Network 🔀
3.5. Fragmentation
The SCHC specification [RFC8724] defines a generic fragmentation functionality that lets you send data packets or files bigger than the maximum size of a Sigfox payload 📦➡️ It also defines a mechanism for reliably sending multiple messages by selectively resending any lost fragments 🔁
The SCHC fragmentation supports several modes of operation. These modes have different advantages and disadvantages, depending on the specifics of the underlying LPWAN technology and the application use case 🧐 This section describes how the SCHC fragmentation functionality should optimally be implemented when used over a Sigfox LPWAN for the most typical use case applications 💖
As described in Section 8.2.3 of [RFC8724], the integrity of the fragmentation-reassembly process of a SCHC Packet MUST be checked at the receiver end 🔍 Since only Uplink/Downlink messages/fragments that passed the Sigfox CRC-check get delivered to the Network/Sigfox Device SCHC C/D + F/R, integrity can be guaranteed when no consecutive messages are missing from the sequence and all FCN bitmaps are complete ✅ With that in mind, and to save protocol and processing overhead, the use of a Reassembly Check Sequence (RCS), as described in Section 3.5.1.5, MUST be used 🙌
3.5.1. Uplink Fragmentation
Sigfox Uplink transmissions are completely asynchronous and happen on any random frequency within the allowed Uplink bandwidth allocation 🎲 Devices may also go into deep sleep mode and wake up to transmit whenever they need to send information to the Network, because there's no need for Network attachment, synchronization, or other procedures before sending a data packet 💤
Since Uplink transmissions are asynchronous, a SCHC Fragment can be transmitted at any given time by the device ⏰ Sigfox Uplink messages are fixed in size, and as described in [RFC8376], they can carry a payload of 0-12 bytes (0-96 bits) 📐 Hence, a single SCHC Tile size, per fragmentation mode, can be defined so that every Sigfox message always carries one SCHC Tile 🧱
When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC Compound ACK defined in [RFC9441] MUST be used in the Downlink responses 🫶
3.5.1.1. SCHC Sender-Abort
As defined in [RFC8724], a SCHC Sender-Abort can be triggered when the number of SCHC ACK REQ attempts is greater than or equal to MAX_ACK_REQUESTS 🛑 For SCHC over Sigfox, a SCHC Sender-Abort MUST be sent if the number of repeated All-1s sent in sequence, without a Compound ACK reception in between, is greater than or equal to MAX_ACK_REQUESTS 😤
3.5.1.2. SCHC Receiver-Abort
As defined in [RFC8724], a SCHC Receiver-Abort is triggered when the receiver has no RuleID and DTag pairs available for a new session 🙈 In this profile, a SCHC Receiver-Abort MUST be sent if, for a single device, all the RuleIDs are being processed by the receiver (meaning they have an active session) at a certain time and a new one is requested, or if the RuleID of the fragment is not valid 🚫
A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer expires ⏳💀
MAX_ACK_REQUESTS can be increased when facing high error rates 📈
Although a SCHC Receiver-Abort can be triggered at any point in time, a SCHC Receiver-Abort Downlink message MUST only be sent when there is a Downlink transmission opportunity 🪟
3.5.1.3. Single-Byte SCHC Header for Uplink Fragmentation
3.5.1.3.1. Uplink No-ACK Mode: Single-Byte SCHC Header 🌸
okay bestie, so the Single-byte SCHC Header No-ACK mode MUST be used for sending short, non-critical packets that need fragmentation but don't need full reliability 💅 This mode works for Uplink-only devices that can't do Downlink communications, or for bidirectional devices when they're sending non-critical data. ngl, using a reliable fragmentation mode for non-critical data (which only bidirectional devices can do) may create unnecessary overhead 🙈
Since No-ACK mode doesn't have multiple windows, the W bit is not present at all 🦋 However, it MUST use the FCN field to indicate the size of the data packet. So the data packet gets split into X fragments, and just like the other fragmentation modes, the first fragment that gets sent is marked with FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN values, and the last fragment is marked with FCN = (All-1). It's giving clever 🧚 Even though No-ACK can't recover missing fragments, the FCN trick tells the Network how big the expected packet is, so the receiver can tell whether every fragment actually showed up. If the FCN field isn't used to indicate the size of the data packet, the Network can still detect whether all fragments were received by using the integrity check ✨
When using the Single-byte SCHC Header for Uplink fragmentation, the fragmentation header MUST be 8 bits in size and is composed as follows:
RuleIDsize:3bitsDTagsize (T):0bits- Fragment Compressed Number (
FCN) size (N):5bits
Other F/R parameters MUST be configured as follows:
- As per [RFC8724], in the No-ACK mode, the
W(window) field is not present. - Regular tile size:
11bytes - All-1 tile size:
0to10bytes - Inactivity Timer: Application-dependent. The default value is
12hours. - RCS size:
5bits
The maximum SCHC Packet size is 340 bytes. 💖
Section 3.6.1 presents SCHC Fragment format examples, and Section 5.1 provides fragmentation examples, using Single-byte SCHC Header No-ACK mode.
3.5.1.3.2. Uplink ACK-on-Error Mode: Single-Byte SCHC Header 🎀
ACK-on-Error with a single-byte header MUST be used for short- to medium-sized packets that need to be sent reliably. ACK-on-Error is the move for reliable SCHC Packet transmission over Sigfox, because it cuts down the number of ACKs on the lower-capacity Downlink channel 👑 Downlink messages can also be sent asynchronously and opportunistically. Meanwhile, ACK-Always wouldn't minimize the number of ACKs, and No-ACK wouldn't allow reliable transmission. not it 💀
Allowing transmission of packets/files up to 300 bytes long, the SCHC Uplink fragmentation header size is 8 bits in size and is composed as follows:
RuleIDsize:3bitsDTagsize (T):0bits- Window index (
W) size (M):2bits - Fragment Compressed Number (
FCN) size (N):3bits
Other F/R parameters MUST be configured as follows:
MAX_ACK_REQUESTS:5WINDOW_SIZE:7(i.e., the maximum FCN value is0b110)- Regular tile size:
11bytes - All-1 tile size:
0to10bytes - Retransmission Timer: Application-dependent. The default value is
12hours. - Inactivity Timer: Application-dependent. The default value is
12hours. - RCS size:
3bits
Section 3.6.2 presents SCHC Fragment format examples, and Section 5.2 provides fragmentation examples, using ACK-on-Error with a single-byte header.
3.5.1.4. Two-Byte SCHC Header for Uplink Fragmentation 🦋
ACK-on-Error with a two-byte header MUST be used for medium- to large-sized packets that need to be sent reliably. Once again, ACK-on-Error is optimal for reliable SCHC Packet transmission over Sigfox, since it leads to a reduced number of ACKs in the lower-capacity Downlink channel. Downlink messages can be sent asynchronously and opportunistically too. ACK-Always would not minimize the number of ACKs, and No-ACK would not allow reliable transmission 🫶
3.5.1.4.1. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1 🍓
So to allow transmission of medium to large packets/files up to 480 bytes long, the SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:
RuleIDsize:6bitsDTagsize (T):0bits- Window index (
W) size (M):2bits - Fragment Compressed Number (
FCN) size (N):4bits - RCS size:
4bits
Other F/R parameters MUST be configured as follows:
MAX_ACK_REQUESTS:5WINDOW_SIZE:12(with a maximum value ofFCN=0b1011)- Regular tile size:
10bytes - All-1 tile size:
1to10bytes - Retransmission Timer: Application-dependent. The default value is
12hours. - Inactivity Timer: Application-dependent. The default value is
12hours.
Note that WINDOW_SIZE is limited to 12. This is because 4 windows (M = 2) with bitmaps of size 12 can be fitted in a single SCHC Compound ACK 🧠
Section 3.6.3 presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 1.
3.5.1.4.2. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2 🌈
Now for very large packets/files up to 2400 bytes long. The SCHC Uplink fragmentation header size is 16 bits in size and is composed as follows:
RuleIDsize:8bitsDTagsize (T):0bits- Window index (
W) size (M):3bits - Fragment Compressed Number (
FCN) size (N):5bits - RCS size:
5bits
Other F/R parameters MUST be configured as follows:
MAX_ACK_REQUESTS:5WINDOW_SIZE:31(with a maximum value ofFCN=0b11110)- Regular tile size:
10bytes - All-1 tile size:
0to9bytes - Retransmission Timer: Application-dependent. The default value is
12hours. - Inactivity Timer: Application-dependent. The default value is
12hours.
Section 3.6.4 presents SCHC Fragment format examples, using ACK-on-Error with two-byte header Option 2.
3.5.1.5. All-1 SCHC Fragment and RCS Behavior 🔥
For ACK-on-Error, as defined in [RFC8724], it is expected that the last SCHC Fragment of the last window will always be delivered with an All-1 FCN. Since this last window may not be full (i.e., it may be made up of fewer than WINDOW_SIZE fragments), an All-1 fragment may follow a value of FCN higher than 1 (0b01). In this case, the receiver cannot tell from the FCN values alone whether any fragments are missing right before the All-1 fragment 😭
For Rules where the number of fragments in the last window is unknown, an RCS field MUST be used, indicating the number of fragments in the last window, including the All-1. With this RCS value, the receiver can detect whether there are missing fragments before the All-1, construct the corresponding SCHC ACK Bitmap accordingly, and send it in response to the All-1 🫶
3.5.2. Downlink Fragmentation 🍓
In some LPWAN technologies, as part of energy-saving techniques, Downlink transmission is only possible immediately after an Uplink transmission. This lets the device go into a very deep sleep mode and save battery without having to listen to the Network. This is the case for Sigfox-enabled devices, which can only listen to Downlink communications after doing an Uplink transmission and requesting a Downlink 🌙
When there are fragments to be sent in the Downlink, an Uplink message is required to trigger the Downlink communication. To avoid a potentially high delay for fragmented datagram transmission in the Downlink, the fragment receiver MAY perform an Uplink transmission as soon as possible after receiving a Downlink fragment that is not the last one. That Uplink transmission MAY be triggered by sending a SCHC message, such as a SCHC ACK. Other data messages can equally be used to trigger Downlink communications. The fragment receiver MUST send an Uplink transmission (e.g., empty message) and request a Downlink every 24 hours when no SCHC session is started. Whether this Uplink transmission is used (and the transmission rate, if used) depends on application-specific requirements 💜
Sigfox Downlink messages are fixed in size, and as described in [RFC8376] they can carry a payload of 0-8 bytes (0-64 bits). So a single SCHC Tile size per mode can be defined so that every Sigfox message always carries one SCHC Tile 🧚
For reliable Downlink fragment transmission, the ACK-Always mode SHOULD be used. Note that ACK-on-Error doesn't guarantee Uplink feedback (since no SCHC ACK gets sent when no errors occur in a window), and No-ACK wouldn't allow reliable transmission 🙈
The SCHC Downlink fragmentation header size is 8 bits in size and is composed as follows:
RuleIDsize:3bitsDTagsize (T):0bits- Window index (
W) size (M):0bits - Fragment Compressed Number (
FCN) size (N):5bits
Other F/R parameters MUST be configured as follows:
MAX_ACK_REQUESTS:5WINDOW_SIZE:31(with a maximum value ofFCN=0b11110)- Regular tile size:
7bytes - All-1 tile size:
0to6bytes - Retransmission Timer: Application-dependent. The default value is
12hours. - Inactivity Timer: Application-dependent. The default value is
12hours. - RCS size:
5bits
3.6. SCHC over Sigfox F/R Message Formats 🎀
This section shows the different formats of SCHC Fragment, SCHC ACK (including the SCHC Compound ACK defined in [RFC9441]), and SCHC Abort used in SCHC over Sigfox ✨
3.6.1. Uplink No-ACK Mode: Single-Byte SCHC Header 🌸
3.6.1.1. Regular SCHC Fragment 💅
Figure 3 shows an example of a Regular SCHC Fragment for all fragments except the last one. As tiles are 11 bytes in size, padding MUST NOT be added. The penultimate tile of a SCHC Packet is of regular size 🦋
|- SCHC Fragment Header -|
+------------------------+---------+
| RuleID | FCN | Payload |
+------------+-----------+---------+
| 3 bits | 5 bits | 88 bits |
Figure 3: Regular SCHC Fragment Format for All Fragments except
the Last One3.6.1.2. All-1 SCHC Fragment ✨
Okay bestie, so the All-1 message is giving main character energy 💅. Figure 4 shows what it looks like. The All-1 message MAY contain the last tile of the SCHC Packet 🎀. Padding MUST NOT be added, because the resulting size is already a multiple of an L2 Word 🌸.
The All-1 message's Fragment Header has a 5-bit RCS, and 3 bits get added as padding so it fills 2 bytes 🧚. The payload of the All-1 message can be anywhere from 0 to 80 bits 💜.
|-------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+-----------+--------+--------+--------------+
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits |Figure 4: All-1 SCHC Message Format with the Last Tile
Per [RFC8724], the All-1 must be distinguishable from a SCHC Sender-Abort message (with the same RuleID and N values) 👀. The All-1 MAY have the last tile of the SCHC Packet 🦋. The SCHC Sender-Abort message header is 1 byte with no padding bits 🍓.
For the All-1 to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only the header, with no padding) 🫶. That way, the minimum size of the All-1 is 2 bytes and the Sender-Abort message is 1 byte. Iconic, right? 👑
3.6.1.3. SCHC Sender-Abort Message Format 🌈
Sender-Abort
|------ Header ------|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits | 5 bits |Figure 5: SCHC Sender-Abort Message Format
3.6.2. Uplink ACK-on-Error Mode: Single-Byte SCHC Header 🦋
3.6.2.1. Regular SCHC Fragment 💖
Figure 6 shows a Regular SCHC Fragment for all fragments except the last one 🌸. Tiles are 11 bytes in size, so padding MUST NOT be added 💅.
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID | W | FCN | Payload |
+--------+--------+--------+---------+
| 3 bits | 2 bits | 3 bits | 88 bits |Figure 6: Regular SCHC Fragment Format for All Fragments except the Last One
Okay, this part is a little plot twist 😭. The SCHC ACK REQ MUST NOT be used. Instead, the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver (Network SCHC) 🔥. Per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message) 🧚. The penultimate tile of a SCHC Packet is of regular size 💜.
3.6.2.2. All-1 SCHC Fragment 🎀
Figure 7 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet ✨. Padding MUST NOT be added, because the resulting size is L2-word-multiple 🌈.
|------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload |
+--------+--------+-----------+--------+--------+--------------+
| 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits |Figure 7: All-1 SCHC Message Format with the Last Tile
Per [RFC8724], the All-1 must be distinguishable from a SCHC Sender-Abort message (with the same RuleID, M, and N values) 👀. The All-1 MAY have the last tile of the SCHC Packet 🦋. The SCHC Sender-Abort message header is 1 byte with no padding bits 🍓.
For the All-1 to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only the header, with no padding) 🫶. So the minimum size of the All-1 is 2 bytes and the Sender-Abort message is 1 byte 👑.
3.6.2.3. SCHC ACK Format 🍓
Figure 8 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size 💅.
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 3 bits | 2 bits | 1 bit | 58 bits |Figure 8: SCHC Success ACK Message Format
If SCHC Fragment losses are found in any of the windows of the SCHC Packet (C=0), the SCHC Compound ACK defined in [RFC9441] MUST be used 🔥. The SCHC Compound ACK message format is shown in Figure 9 💖.
|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
+------+--------+-------+--------+...+--------+--------+------+-------+
|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad|
+------+--------+-------+--------+...+--------+--------+------+-------+
|3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|Figure 9: SCHC Compound ACK Message Format
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi 🧚.
3.6.2.4. SCHC Sender-Abort Message Format 🌸
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W=b'11 | FCN=ALL-1 |
+--------+--------+-----------+
| 3 bits | 2 bits | 3 bits |Figure 10: SCHC Sender-Abort Message Format
3.6.2.5. SCHC Receiver-Abort Message Format 💀
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 | b'11 | 0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 3 bits | 2 bits | 1 bit | 2 bit | 8 bit | 48 bits |
next L2 Word boundary ->| <-- L2 Word --> |Figure 11: SCHC Receiver-Abort Message Format
3.6.3. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1 🌈
3.6.3.1. Regular SCHC Fragment ✨
Figure 12 shows a Regular SCHC Fragment for all fragments except the last one 🎀. The penultimate tile of a SCHC Packet is of the regular size 🦋.
|------- SCHC Fragment Header ------|
+-----------------------------------+---------+
| RuleID | W | FCN | b'0000 | Payload |
+--------+--------+--------+--------+---------+
| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |Figure 12: Regular SCHC Fragment Format for All Fragments except the Last One
The SCHC ACK REQ MUST NOT be used. Instead, the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver (Network SCHC) 🔥. Per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message) 🧚.
3.6.3.2. All-1 SCHC Fragment 💜
Figure 13 shows an example of the All-1 message. The All-1 message MUST contain the last tile of the SCHC Packet 🫶.
The All-1 message Fragment Header contains an RCS of 4 bits to complete the two-byte size. The size of the last tile ranges from 8 to 80 bits 🍓.
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS | Payload |
+--------+--------+-----------+--------+--------------+
| 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits |Figure 13: All-1 SCHC Message Format with the Last Tile
Per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with the same RuleID, M, and N values) 👀. The All-1 MUST have the last tile of the SCHC Packet, and that tile MUST be at least 1 byte 💅. The SCHC Sender-Abort message header is 2 bytes with no padding bits 🌸.
Heads up, bestie: the minimum sizes here are different from the Single-Byte modes, so don't mix them up 🙈.
For the All-1 to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only the header, with no padding) 🫶. So the minimum size of the All-1 is 3 bytes and the Sender-Abort message is 2 bytes 👑.
3.6.3.3. SCHC ACK Format 🌷
Figure 14 shows the SCHC ACK format when all fragments have been correctly received (C=1). Padding MUST be added to complete the 64-bit Sigfox Downlink frame payload size 💖.
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 6 bits | 2 bits | 1 bit | 55 bits |Figure 14: SCHC Success ACK Message Format
The SCHC Compound ACK message MUST be used in case SCHC Fragment losses are found in any window of the SCHC Packet (C=0). The SCHC Compound ACK message format is shown in Figure 15. The SCHC Compound ACK can report up to 4 windows with losses, as shown in Figure 16 🌈.
When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (padding bits must be 0) to complement the 64 bits required by the Sigfox payload 🧚.
|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
+--------+------+-------+--------+...+------+--------+------+-------+
| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad|
+--------+------+-------+--------+...+------+--------+------+-------+
| 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|Figure 15: SCHC Compound ACK Message Format
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi 🦋.
|- SCHC ACK Header -|- W=0 -| |- W=1 -|...
+------+------+-----+-------+------+-------+...
|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...
+------+------+-----+-------+------+-------+...
|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...
... |- W=2 -| |- W=3 -|
...+------+-------+------+-------+---+
...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
...+------+-------+------+-------+---+
...|2 bits|12 bits|2 bits|12 bits|Figure 16: SCHC Compound ACK Message Format Example with Losses in All Windows
Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi 🌸.
3.6.3.4. SCHC Sender-Abort Message Format 💀
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W | FCN=ALL-1 |
+--------+--------+-----------+
| 6 bits | 2 bits | 4 bits |Figure 17: SCHC Sender-Abort Message Format
3.6.3.5. SCHC Receiver-Abort Message Format 🫶
|- Receiver-Abort Header -|
+---------------------------------+-----------------+---------+
| RuleID | W=b'11 | C=b'1 | 0x7F | 0xFF (all 1's) | b'0-pad |
+--------+--------+-------+-------+-----------------+---------+
| 6 bits | 2 bits | 1 bit | 7 bit | 8 bit | 40 bits |
next L2 Word boundary ->| <-- L2 Word --> |Figure 18: SCHC Receiver-Abort Message Format
3.6.4. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2 👑
3.6.4.1. Regular SCHC Fragment ✨
okay bestie, this one shows what a Regular SCHC Fragment looks like for every fragment except the last one 🎀 The penultimate tile of a SCHC Packet is the regular size, so it fits this shape 💅
|-- SCHC Fragment Header --|
+--------------------------+---------+
| RuleID | W | FCN | Payload |
+--------+--------+--------+---------+
| 8 bits | 3 bits | 5 bits | 80 bits |
Figure 19: Regular SCHC Fragment Format for All Fragments except
the Last Onethe SCHC ACK REQ MUST NOT be used 🙅♀️ instead, the All-1 SCHC Fragment MUST be used to ask the receiver (Network SCHC) for a SCHC ACK 🦋 as per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message) ✨
3.6.4.2. All-1 SCHC Fragment 🌸
here's the All-1 message in action 👀 it MAY contain the last tile of the SCHC Packet 🍓
the All-1 message Fragment Header has an RCS of 5 bits plus 3 padding bits, which makes a 3-byte Fragment Header 🧚 the size of the last tile (if there is one) ranges from 8 to 72 bits 💖
|-------------- SCHC Fragment Header -----------|
+-----------------------------------------------+--------------+
| RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+--------+-----------+--------+--------+--------------+
| 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits |
Figure 20: All-1 SCHC Message Format with the Last Tileas per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values) 🙈 the SCHC Sender-Abort message header is 2 bytes with no padding bits 💅
so for the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only the header, no padding) ✨ that means the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes. iykyk 💜
3.6.4.3. SCHC ACK Format 🎀
Figure 21 is the SCHC ACK for when every fragment got through fine (C=1) 🥰 Padding MUST be added to fill out the 64-bit Sigfox Downlink frame payload size 🌈
|---- SCHC ACK Header ----|
+-------------------------+---------+
| RuleID | W | C=b'1 | b'0-pad |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |
Figure 21: SCHC Success ACK Message Formatnow if there are SCHC Fragment losses in any window of the SCHC Packet (C=0), the SCHC Compound ACK message MUST be used 😭 its format is in Figure 22, and it can report up to 3 windows with losses 🔥
when it's sent in the Downlink, the SCHC Compound ACK MUST be 0 padded (padding bits must be 0) so it covers the 64 bits the Sigfox payload needs 🫶
|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
+------+------+-------+--------+...+------+--------+------+-------+
|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000 |b'0-pad|
+------+------+-------+--------+...+------+--------+------+-------+
|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
Figure 22: SCHC Compound ACK Message Formatthe losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi 📋
3.6.4.4. SCHC Sender-Abort Message Format 💀
this is the Sender-Abort header, aka the one that says "we're done, bye" 👋
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID | W | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits | 5 bits |
Figure 23: SCHC Sender-Abort Message Format3.6.4.5. SCHC Receiver-Abort Message Format 🌈
and here's the receiver's version of the abort message, which is its own kind of drama 🎭
|-- Receiver-Abort Header -|
+-----------------------------------+-----------------+---------+
| RuleID | W=b'111 | C=b'1 | b'1111 | 0xFF (all 1's) | b'0-pad |
+--------+---------+-------+--------+-----------------+---------+
| 8 bits | 3 bits | 1 bit | 4 bit | 8 bit | 40 bits |
next L2 Word boundary ->| <-- L2 Word --> |
Figure 24: SCHC Receiver-Abort Message Format3.6.5. Downlink ACK-Always Mode: Single-Byte SCHC Header 🦋
3.6.5.1. Regular SCHC Fragment 💖
same energy as before, but this time it's the single-byte header version 🌸 Figure 25 shows a Regular SCHC Fragment for all fragments except the last one, and the penultimate tile is the regular size 🧚
SCHC Fragment
|-- Header --|
+-----------------+---------+
| RuleID | FCN | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |
Figure 25: Regular SCHC Fragment Format for All Fragments except
the Last Onethe SCHC ACK MUST NOT be used 🚫 instead, the All-1 SCHC Fragment MUST be used to request a SCHC ACK from the receiver ✨ as per [RFC8724], the All-0 message is distinguishable from the SCHC ACK REQ (All-1 message) 💅
3.6.5.2. All-1 SCHC Fragment 🍓
Figure 26 is the All-1 message, and it MAY contain the last tile of the SCHC Packet 👀
its Fragment Header has an RCS of 5 bits plus 3 padding bits, so it's a 2-byte Fragment Header 🫶 the size of the last tile (if present) ranges from 8 to 48 bits 💜
|--------- SCHC Fragment Header -------|
+--------------------------------------+--------------+
| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
+--------+-----------+--------+--------+--------------+
| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits |
Figure 26: All-1 SCHC Message Format with the Last Tileas per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID and N values) 🙈 the SCHC Sender-Abort message header is 1 byte with no padding bits 🌸
so for the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only the header, no padding) ✨ the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes 💅
3.6.5.3. SCHC ACK Format 🎀
Figure 27 is the SCHC ACK for when all fragments were correctly received (C=1) 🥰 Padding MUST be added to complete 2 bytes 🌈
SCHC ACK
|-- Header --|
+----------------+---------+
| RuleID | C=b'1 | b'0-pad |
+--------+-------+---------+
| 3 bits | 1 bit | 4 bits |
Figure 27: SCHC Success ACK Message Formatand the SCHC ACK message format is shown in Figure 28 🦋
|---- SCHC ACK Header ----|
+--------+-------+--------+---------+
| RuleID | C=b'0 | Bitmap | b'0-pad |
+--------+-------+--------+---------+
| 3 bits | 1 bit | 31 bits| 5 bits |
Figure 28: SCHC Compound ACK Message Format3.6.5.4. SCHC Sender-Abort Message Format 💀
the Sender-Abort header in its single-byte form 👋
Sender-Abort
|---- Header ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits | 5 bits |
Figure 29: SCHC Sender-Abort Message Format3.6.5.5. SCHC Receiver-Abort Message Format 🌸
and the receiver's single-byte abort, same drama, smaller outfit 🎭
Receiver-Abort
|--- Header ---|
+----------------+--------+-----------------+
| RuleID | C=b'1 | b'1111 | 0xFF (all 1's) |
+--------+-------+--------+-----------------+
| 3 bits | 1 bit | 4 bit | 8 bit |
Figure 30: SCHC Receiver-Abort Message Format3.7. Padding 🧚
the Sigfox payload fields act differently in Uplink and Downlink, so let's talk about it 💅
Uplink messages can carry a payload size from 0 to 12 bytes 🌈 the Sigfox radio protocol lets you send zero bits, one single bit of information for binary applications (e.g., status), or a whole number of bytes ✨ so for 2 or more bits of payload, it is required to add padding up to the next whole number of bytes 🍓 the reason for this flexibility is to optimize transmission time and hence save battery consumption at the device 🔋💖
Downlink frames are different, though, because they have a fixed length 🎀 the payload length MUST be 64 bits (i.e., 8 bytes) 💜 so if fewer information bits are being sent, padding MUST be used with bits equal to 0 🫶 and the receiver MUST remove the added padding bits before the SCHC reassembly process 😭✨
4. Fragmentation Rules Examples 🌈
this section gives an example of RuleID configuration so the F/R modes in this document can work together nicely 🦋 heads up that the RuleID space for Uplink F/R is different from the one for Downlink F/R, so this section is split into two subsections: Rules for Uplink fragmentation and Rules for Downlink fragmentation 💅
for Uplink F/R, multiple header lengths were described in Section 3.5 🎀 they're all part of the SCHC over Sigfox Profile, and they give you low protocol overhead for small payloads (single byte header) plus room to carry larger payloads with more overhead (2-byte header, Options 1 and 2) 🧚 how you use the RuleID space for each header length is up to the implementation, but the following section has an example 🌸 it shows implementation choices made to 1) identify the different header length and 2) then parse the RuleID field to find the RuleID value and run the matching treatment 👑
4.1. Uplink Fragmentation Rules Examples 🎀
okay so the RuleID field for Uplink F/R modes comes in different sizes depending on the header length 💅 To figure out the header length, and then the actual RuleID value, we read the RuleID field like this:
- The RuleID field is the first one parsed in the SCHC header, starting from the leftmost bits ✨
- For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits is expected:
- If the first 3 leftmost bits are not
0b'111, it signals a Single-byte SCHC Header F/R mode 🦋 - If they're
0b'111, it signals a Two-byte SCHC Header F/R mode 💜
- If the first 3 leftmost bits are not
- For Single-byte SCHC Header F/R modes:
- There are 7 RuleIDs available (values
0b'000through0b'110). The RuleID0b'111is reserved to indicate a Two-byte SCHC Header 🙈 - This set of Rules is called "standard rules", and it's used to implement Single-byte SCHC Header modes 🌸
- Each RuleID is linked to a set of properties that define whether Uplink F/R is used and which Uplink F/R mode is used. As an example, RuleID
0b'000is mapped onto Uplink No-ACK Mode: Single-byte SCHC Header, and RuleIDs0b'001and0b'002are mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header (2 RuleIDs, so SCHC Packet interleaving is possible) 🍓
- There are 7 RuleIDs available (values
- For Two-byte SCHC Header F/R modes, at least 6 bits for the RuleID field are expected:
- The 3 first leftmost bits are always
0b'111.- If the following 3 bits have a different value than
0b'111, it signals the Two-byte SCHC Header Option 1 ⭐ - If the following 3 bits are
0b'111, it signals the Two-byte SCHC Header Option 2 🔥
- If the following 3 bits have a different value than
- For the Two-byte SCHC Header Option 1, there are 7 RuleIDs available (
0b'111000through0b'111110), with0b'111111reserved to indicate the Two-byte SCHC Header Option 2. This set of Rules is called "extended rules", and it's used to implement the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1 👑 - For the Two-byte SCHC Header Option 2, there are 2 additional bits to parse as the RuleID, so 4 RuleIDs are available (
0b'11111100through0b'11111111). This set of Rules is used to cover specific cases that the previous RuleIDs don't cover. As an example, RuleID0b'00111111is used to transport uncompressed IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC Header Option 2 🧚
- The 3 first leftmost bits are always
4.2. Downlink Fragmentation Rules Example 🌈
For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs can get values in the range from 0b'000 to 0b'111 🫶
5. Fragmentation Sequence Examples ✨
In this section, we've got some sequence diagrams showing the message exchanges for different fragmentation modes and use cases 🎬 In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carrying a fragment.
5.1. Uplink No-ACK Examples 💖
The FCN field tells you the size of the data packet 📦 The first fragment is marked with FCN = X-1, where X is the number of fragments the message is split into. All fragments are marked with decreasing FCN values, and the last packet fragment is marked with FCN = All-1 (1111) 💅
Case No Losses - All fragments are sent and received successfully. 🦋
Sender Receiver
|-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2-------->|
|-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| All fragments received
(End)
Figure 31: Uplink No-ACK No-LossesWhen the first SCHC Fragment is received, the receiver can work out the total number of SCHC Fragments that the SCHC Packet is made of 🧮 For example, if the first fragment is numbered with FCN=6, the receiver can expect six more messages/fragments (i.e., with FCN going from 5 downwards, and the last fragment with an FCN equal to 15) 🌸
Case Losses on Any Fragment except the First 🙈
Sender Receiver
|-------FCN=6,Seq=1-------->|
|-------FCN=5,Seq=2----X |
|-------FCN=4,Seq=3-------->|
|-------FCN=3,Seq=4-------->|
|-------FCN=2,Seq=5-------->|
|-------FCN=1,Seq=6-------->|
|-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
(End)
Figure 32: Uplink No-ACK Losses (Scenario 1)5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header 💖
Okay so, the Single-Byte SCHC Header ACK-on-Error mode can handle up to 28 fragments and packets up to 300 bytes 📦✨ The SCHC Fragments can show up asynchronously (aka out of order, whenever they feel like it 🙃), and the Downlink ACK can be sent opportunistically, meaning whenever the receiver gets a chance. Iconic flexibility 💅
Case No Losses 🦋
So first, the Downlink flag has to be switched on in the sender's Uplink message so the receiver is allowed to send a Downlink message back 🎀 In the figures, the "DL Enable" label shows where the sender MUST enable the Downlink and wait for an ACK 👀
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
|<- Compound ACK,W=1,C=1 --| C=1
(End)Figure 33: Uplink ACK-on-Error No-Losses
Case Fragment Losses in the First Window 🌸
Here the fragments get lost in the first window (W=0) 😭 As soon as the first All-0 message arrives, the receiver takes the opportunity and sends a SCHC ACK with the matching bitmap and C=0 💜
Once the lost fragments from the first window (W=0) get resent, the sender keeps going with the fragments of the next window (W=1) without opening a reception opportunity 🏃♀️ Finally, the All-1 fragment goes out, the Downlink gets enabled, and the SCHC ACK comes back with C=1 🎉 Also, the SCHC Compound ACK uses a Sequence Number too, so don't forget that bestie 🧚
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5--X | __
|-----W=0,FCN=1,Seq=6----->| | W=0
DL Enable |-----W=0,FCN=0,Seq=7----->| Missing Fragments<- FCN=5,Seq=2
|<- Compound ACK,W=0,C=0 --| Bitmap:1011011 | FCN=2,Seq=5
|-----W=0,FCN=5,Seq=9----->| --
|-----W=0,FCN=2,Seq=10---->|
|-----W=1,FCN=6,Seq=11---->|
|-----W=1,FCN=5,Seq=12---->|
|-----W=1,FCN=4,Seq=13---->|
DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
|<-Compound ACK,W=1,C=1 ---| C=1
(End)Figure 34: Uplink ACK-on-Error Losses in the First Window
Case Fragment All-0 Lost in the First Window (W=0) 🙈
In this example, the All-0 of the first window (W=0) goes missing 💀 So the receiver waits for the next All-0 message of an intermediate window, or the All-1 message of the last window, before it generates the matching SCHC ACK. That ACK tells the sender the All-0 of window 0 is absent 🫣
The sender then resends the missing All-0 messages (along with any other missing fragment from window 0) without opening a reception opportunity 🔁
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| DL Enable
|-----W=0,FCN=0,Seq=7--X |
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
|<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__
|-----W=0,FCN=0,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK,W=1,C=1 ---| C=1
(End)Figure 35: Uplink ACK-on-Error All-0 Lost in the First Window
In the next diagram, there's the All-0 gone missing, plus some other fragment losses in the first window (W=0) 😵💫
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7--X |
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->| __
|-----W=1,FCN=4,Seq=10---->| |W=0
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2
|<--Compound ACK,W=0,C=0 --| Bitmap:1010110 |FCN=3,Seq=4
|-----W=0,FCN=5,Seq=13---->| |FCN=0,Seq=7
|-----W=0,FCN=3,Seq=14---->| --
|-----W=0,FCN=0,Seq=15---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=16---->|
|<-Compound ACK,W=1,C=1 ---| C=1
(End)Figure 36: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First Window
Case Fragment Losses in Both the First and Second Windows 🌈
In the next examples, the fragments get lost in both the first (W=0) and second (W=1) windows 😱 Here's the key bit: the retransmission cycles that happen after the All-1 is sent (so, not in the intermediate windows) MUST always finish with an All-1, because that's the ACK Request message that confirms the retransmitted fragments were received correctly 🫶
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X | __
|-----W=0,FCN=2,Seq=5----->| |W=0
|-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2
DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4
(no ACK) |FCN=0,Seq=7
|-----W=1,FCN=6,Seq=8--X | |W=1
|-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8
|-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10
DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
|<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
|-----W=0,FCN=5,Seq=13---->| W=1:0100001
|-----W=0,FCN=3,Seq=14---->|
|-----W=0,FCN=0,Seq=15---->|
|-----W=1,FCN=6,Seq=16---->|
|-----W=1,FCN=4,Seq=17---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=18---->|
|<-Compound ACK,W=1,C=1----| C=1
(End)Figure 37: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (1)
This next figure is a similar case as above, just with fewer fragments in the second window (W=1) ✨
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->| __
|-----W=0,FCN=1,Seq=6----->| |W=0
DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2
(no ACK) |FCN=3,Seq=4
|-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1
|<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110,|FCN=6,Seq=8
|-----W=0,FCN=5,Seq=11---->| W=1:0000001 |__
|-----W=0,FCN=3,Seq=12---->|
|-----W=0,FCN=0,Seq=13---->|
|-----W=1,FCN=6,Seq=14---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=15---->|
|<-Compound ACK, W=1,C=1---| C=1
(End)Figure 38: Uplink ACK-on-Error All-0 and Other Fragments Lost in the First and Second Windows (2)
Case SCHC ACK is Lost 🥺
SCHC over Sigfox doesn't implement the SCHC ACK REQ message 🙅♀️ Instead, it uses the SCHC All-1 message to request a SCHC ACK whenever one is needed 📨
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
|<-Compound ACK,W=1,C=1 ---| C=1
(End)Figure 39: Uplink ACK-on-Error ACK Lost
Case SCHC Compound ACK at the End 🎀
In this one, SCHC Fragment losses show up in both window 0 and window 1 😵 The twist? The sender doesn't send a SCHC Compound ACK after the All-0 of window 0. It waits, and then sends one SCHC Compound ACK that reports the losses on both windows at once 🧠
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2--X |
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4--X |
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->| __
DL Enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0
(no ACK) next DL opportunity |FCN=5,Seq=2
|-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4
DL Enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1
|<-Compound ACK,W=0,1, C=0-| Bitmap W=0:1010110 |FCN=6,Seq=8
|-----W=0,FCN=5,Seq=11---->| W=1:0000001 --
|-----W=0,FCN=3,Seq=12---->|
|-----W=1,FCN=6,Seq=13---->| All fragments received
DL Enable |-----W=1,FCN=7,Seq=14---->|
|<-Compound ACK, W=1, C=1 -| C=1
(End)Figure 40: Uplink ACK-on-Error Fragments Lost in the First and Second Windows with One Compound ACK
The number of times the same SCHC ACK message gets retransmitted is decided by MAX_ACK_REQUESTS 🔢✨
5.3. SCHC Abort Examples ✨
Case SCHC Sender-Abort 💀
Sometimes the sender needs to send a Sender-Abort to end the current communication, like when the All-1 has already been sent MAX_ACK_REQUESTS times. Here's how that looks in the diagram 👀
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
(no ACK)
|-----W=1,FCN=6,Seq=8----->|
|-----W=1,FCN=5,Seq=9----->|
|-----W=1,FCN=4,Seq=10---->|
DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK (1)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5)
| X--Compound ACK,W=1,C=1 -| C=1
DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
(End)Figure 41: Uplink ACK-on-Error Sender-Abort
Case Receiver-Abort 🫶
The receiver can also send a Receiver-Abort to stop things. This message can only be sent after a Downlink Enable, so it's always a response to that moment 🦋
Sender Receiver
|-----W=0,FCN=6,Seq=1----->|
|-----W=0,FCN=5,Seq=2----->|
|-----W=0,FCN=4,Seq=3----->|
|-----W=0,FCN=3,Seq=4----->|
|-----W=0,FCN=2,Seq=5----->|
|-----W=0,FCN=1,Seq=6----->|
DL Enable |-----W=0,FCN=0,Seq=7----->|
|<------ RECV ABORT ------| under-resourced
(Error)Figure 42: Uplink ACK-on-Error Receiver-Abort
6. Security Considerations 🔐
The radio protocol authenticates and makes sure each message is intact 🔥 It does this with a unique Device ID and an AES-128-based message authentication code, so the message really was generated and sent by the device (see [sigfox-spec], Section 3.8) or the Network (see [sigfox-spec], Section 4.3) using the ID it claims, as described in [sigfox-spec].
Application data may or may not be encrypted at the application layer, depending on how critical the use case is. This flexibility lets you balance cost and effort against risk 💅 AES-128 in counter mode is used for encryption. Cryptographic keys are independent for each device. These keys are tied to the Device ID, and separate integrity and encryption keys are pre-provisioned. An encryption key is only provisioned if confidentiality is going to be used (see [sigfox-spec], Section 5.3; note that further documentation is available at Sigfox upon request).
The radio protocol has protections against replay attacks, and the cloud-based core Network provides firewall protection against undesired incoming communications [sigfox-spec] 🛡️
The security mechanisms above do NOT guarantee end-to-end security between the device SCHC C/D + F/R and the Network SCHC C/D + F/R. Potential security threats described in [RFC8724] still apply to the profile specified in this document. Bestie, this part is serious 😭
In some circumstances, sending device location information is privacy sensitive 🙈 The Device Geolocation parameter provided by the Network is optional, so it can be left out to protect this part of device privacy 🌸
7. IANA Considerations 🎀
This document has no IANA actions. Nothing to register here, bestie ✨
8. References 📚
8.1. Normative References
[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.
[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. Zuniga, "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.
[RFC9441] Zúñiga, JC., Gomez, C., Aguilar, S., Toutain, L., Céspedes, S., and D. Wistuba, "Static Context Header Compression (SCHC) Compound Acknowledgement (ACK)", RFC 9441, DOI 10.17487/RFC9441, July 2023, https://www.rfc-editor.org/info/rfc9441.
[sigfox-spec] Sigfox, "Sigfox Device Radio Specifications", https://build.sigfox.com/sigfox-device-radio-specifications.
8.2. Informative References
[CORE-COMI] Veillette, M., Ed., van der Stok, P., Ed., Pelov, A., Bierman, A., and C. Bormann, Ed., "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-12, 13 March 2023, https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-12.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, https://www.rfc-editor.org/info/rfc6241.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, https://www.rfc-editor.org/info/rfc7252.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, https://www.rfc-editor.org/info/rfc8040.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, https://www.rfc-editor.org/info/rfc8259.
[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.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, https://www.rfc-editor.org/info/rfc8949.
[sigfox-callbacks] Sigfox, "Sigfox Callbacks", https://support.sigfox.com/docs/callbacks-documentation.
[sigfox-docs] Sigfox, "Sigfox Documentation", https://support.sigfox.com/docs.
Acknowledgements 🌈
Carles Gomez has been funded in part by the Spanish Government through the TEC2016-79988-P grant and the PID2019-106808RA-I00 grant (funded by MCIN / AEI / 10.13039/501100011033) and by Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat de Catalunya through 2017 grant SGR 376 and 2021 grant SGR 00330. 👑
Sergio Aguilar has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00, AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033). 💜
Sandra Cespedes has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008. 🍓
Diego Wistuba has been funded by the ANID Chile Project FONDECYT Regular 1201893. 🧚
The authors would like to thank Ana Minaburo, Clement Mannequin, Rafael Vidal, Julien Boite, Renaud Marty, and Antonis Platis for their useful comments and implementation design considerations. Thank you all, you're literally the best 🫶
Authors' Addresses 💖
Juan Carlos Zúñiga
Montreal QC
Canada
Email: j.c.zuniga@ieee.orgCarles Gomez
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: carles.gomez@upc.eduSergio Aguilar
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Email: sergio.aguilar.romero@upc.eduLaurent Toutain
IMT-Atlantique
CS 17607
2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.frSandra Céspedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC H3G 1M8
Canada
Email: sandra.cespedes@concordia.caDiego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Email: research@witu.clJulien Boite
Unabiz (Sigfox)
Labege
France
Email: juboite@free.fr
URI: https://www.sigfox.com/📦 where this page comes from
- ietf: rfc9442 2023-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms