Skip to content

RFC 9442: Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)

  • J. Zúñiga,  
  • C. Gomez,  
  • S. Aguilar,  
  • L. Toutain,  
  • S. Céspedes,  
  • D. Wistuba,  
  • J. Boite
Proposed Standard
RFC Tips

Abstract

The Static Context Header Compression (SCHC) and fragmentation specification (RFC 8724) describes a generic framework for application header compression and fragmentation modes designed for Low-Power Wide Area Network (LPWAN) technologies. This document defines a profile of SCHC over Sigfox LPWAN and provides optimal parameter values and modes of operation.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9442.

1. Introduction

The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation specification [RFC8724] can be used in conjunction with any of the four LPWAN technologies described in [RFC8376]. These LPWANs have similar characteristics, such as star-oriented topologies, network architecture, connected devices with built-in applications, etc.

SCHC offers a considerable degree of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation that can be used when SCHC is used in conjunction with a specific LPWAN technology.

Sigfox is an LPWAN technology that offers energy-efficient connectivity for devices at a very low cost. Complete Sigfox documentation can be found in [sigfox-docs]. Sigfox aims to provide a very wide area network composed of Base Stations that receive short Uplink messages (up to 12 bytes in size) sent by devices over the long-range Sigfox radio protocol, as described in [RFC8376]. Base Stations then forward messages to the Sigfox Cloud infrastructure for further processing (e.g., to offer geolocation services) and final delivery to the customer. Base Stations also relay Downlink messages (with a fixed 8-byte size) sent by the Sigfox Cloud to the devices, i.e., Downlink messages are being generated when devices explicitly request these messages with a flag in an Uplink message. With SCHC functionalities, the Sigfox network offers more reliable communications (including recovery of lost messages) and is able to convey extended-size payloads (allowing for fragmentation/reassembly of messages) [sigfox-spec].

This document describes the parameters, settings, and modes of operation to be used when SCHC is implemented over a Sigfox LPWAN. The set of parameters forms a "SCHC over Sigfox Profile". The SCHC over Sigfox Profile is applicable to the Sigfox Radio specification versions up to v1.6/March 2022 [sigfox-spec] (support for future versions would have to be assessed).

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.

It is assumed that the reader is familiar with the terms and mechanisms defined in [RFC8376] and [RFC8724]. Also, it is assumed that the reader is familiar with Sigfox terminology [sigfox-spec].

3. SCHC over Sigfox

The Generic SCHC Framework described in [RFC8724] takes advantage of previous knowledge of traffic flows existing in LPWAN applications to avoid context synchronization.

Contexts need to be stored and pre-configured on both ends. This can be done either by using a provisioning protocol, by out-of-band means, or by pre-provisioning them (e.g., at manufacturing time). For example, the context exchange can be done by using the Network Configuration Protocol (NETCONF) [RFC6241] with Secure Shell (SSH), RESTCONF [RFC8040] with secure HTTP methods, and CoAP Management Interface (CORECONF) [CORE-COMI] with the Constrained Application Protocol (CoAP) [RFC7252] as provisioning protocols. The contexts can be encoded in XML under NETCONF, in JSON [RFC8259] under RESTCONF, and in Concise Binary Object Representation (CBOR) [RFC8949] under CORECONF. The way contexts are configured and stored on both ends is out of the scope of this document.

3.1. Network Architecture

Figure 1 represents the architecture for Compression/Decompression (C/D) and Fragmentation/Reassembly (F/R) based on the terminology defined in [RFC8376], where the Radio Gateway (RGW) is a Sigfox Base Station and the Network Gateway (NGW) is the Sigfox cloud-based 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 Architecture

In the case of the global Sigfox network, RGWs (or Base Stations) are distributed over multiple countries wherever the Sigfox LPWAN service is provided. The NGW (or cloud-based Sigfox Core Network) is a single entity that connects to all RGWs (Sigfox Base Stations) in the world, hence providing a global single star Network topology.

The Sigfox Device sends application packets that are compressed and/or fragmented by a SCHC C/D + F/R to reduce header size and/or fragment the packet. The resulting SCHC message is sent over a layer two (L2) Sigfox frame to the Sigfox Base Stations, which then forward the SCHC message to the NGW. The NGW then delivers the SCHC message and associated gathered metadata to the Network SCHC C/D + F/R.

The Sigfox cloud-based Network communicates with the Network SCHC C/D + F/R for compression/decompression and/or for fragmentation/reassembly. The Network SCHC C/D + F/R shares the same set of Rules as the device SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with the NGW or it could be located in a different place, as long as a tunnel or secured communication is established between the NGW and the SCHC C/D + F/R functions. After decompression and/or reassembly, the packet can be forwarded over the Internet to one (or several) LPWAN Application Server(s) (App(s)).

The SCHC C/D + F/R processes are bidirectional, so the same principles are applicable on both Uplink (UL) and Downlink (DL).

3.4. SCHC Rules

The RuleID MUST be included in the SCHC header. The total number of Rules to be 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 that are 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 (e.g., a sensor that is powered by the electricity grid).

RuleIDs can be used to differentiate data traffic classes (e.g., 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 allows sending data packets or files larger than the maximum size of a Sigfox payload. The functionality also defines a mechanism to reliably send multiple messages by allowing to selectively resend 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 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 have passed the Sigfox CRC-check are delivered to the Network/Sigfox Device SCHC C/D + F/R, integrity can be guaranteed when no consecutive messages are missing from the sequence and all FCN bitmaps are complete. With this functionality in mind, and in order 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.6. SCHC over Sigfox F/R Message Formats

This section depicts 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.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 One
3.6.1.2. All-1 SCHC Fragment

Figure 4 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, as the resulting size is a multiple of an L2 Word.

The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits are added as padding to complete 2 bytes. The payload size of the All-1 message ranges from 0 to 80 bits.

|--------  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

As 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 size is 1 byte with no padding bits.

For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.

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.1. Regular SCHC Fragment

Figure 6 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.

|-- 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

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). As 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, as 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

As per [RFC8724], the All-1 must be distinguishable from a SCHC Sender-Abort message (with same RuleID, M, and N values). The All-1 MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort message header size is 1 byte with no padding bits.

For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 byte.

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

In case 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 an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.

|------- 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). As 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

As per [RFC8724], the All-1 must be distinguishable from the SCHC Sender-Abort message (with same RuleID, M, and N values). The All-1 MUST have the last tile of the SCHC Packet that MUST be at least 1 byte. The SCHC Sender-Abort message header size is 2 bytes with no padding bits.

For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only header with no padding). This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.

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.1. Regular SCHC Fragment

Figure 19 shows an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.

|-- 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 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). 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

Figure 20 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet.

The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete a 3-byte Fragment Header. The size of the last tile, if present, ranges from 8 to 72 bits.

|-------------- 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 Tile

As 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 size is 2 bytes with no padding bits.

For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 2 bytes (only header with no padding). This way, the minimum size of the All-1 is 3 bytes, and the Sender-Abort message is 2 bytes.

3.6.4.3. SCHC ACK Format

Figure 21 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 |
+--------+--------+-------+---------+
| 8 bits | 3 bits | 1 bit | 52 bits |
Figure 21: 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 22. The SCHC Compound ACK can report up to 3 windows with losses.

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 | 000  |b'0-pad|
+------+------+-------+--------+...+------+--------+------+-------+
|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
Figure 22: SCHC Compound ACK Message Format

Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.

3.6.4.4. SCHC Sender-Abort Message Format 
|---- Sender-Abort Header ----|
+-----------------------------+
| RuleID |   W    | FCN=ALL-1 |
+--------+--------+-----------+
| 8 bits | 3 bits |  5 bits   |
Figure 23: SCHC Sender-Abort Message Format
3.6.4.5. SCHC Receiver-Abort Message Format 
|-- 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 Format
3.6.5.1. Regular SCHC Fragment

Figure 25 shows an example of a Regular SCHC Fragment for all fragments except the last one. The penultimate tile of a SCHC Packet is of the regular size.

   SCHC Fragment
|--    Header   --|
+-----------------+---------+
| RuleID |  FCN   | Payload |
+--------+--------+---------+
| 3 bits | 5 bits | 56 bits |
Figure 25: Regular SCHC Fragment Format for All Fragments except the Last One

The 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 shows an example of the All-1 message. The All-1 message MAY contain the last tile of the SCHC Packet.

The All-1 message Fragment Header contains an RCS of 5 bits and 3 padding bits to complete 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 Tile

As 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 size is 1 byte with no padding bits.

For the All-1 message to be distinguishable from the Sender-Abort message, the Sender-Abort message MUST be 1 byte (only header with no padding). This way, the minimum size of the All-1 is 2 bytes, and the Sender-Abort message is 1 bytes.

3.6.5.3. SCHC ACK Format

Figure 27 shows the SCHC ACK format when all fragments have been 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 Format

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 Format
3.6.5.4. SCHC Sender-Abort Message Format 
     Sender-Abort
|----   Header   ----|
+--------------------+
| RuleID | FCN=ALL-1 |
+--------+-----------+
| 3 bits |  5 bits   |
Figure 29: SCHC Sender-Abort Message Format
3.6.5.5. SCHC Receiver-Abort Message Format 
  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 Format

3.7. Padding

The Sigfox payload fields have different characteristics in Uplink and Downlink.

Uplink messages can contain a payload size from 0 to 12 bytes. The Sigfox radio protocol allows sending zero bits, one single bit of information for binary applications (e.g., status), or an integer number of bytes. Therefore, for 2 or more bits of payload, it is required to add padding to the next integer number of bytes. The reason for this flexibility is to optimize transmission time and hence save battery consumption at the device.

On the other hand, Downlink frames have a fixed length. The payload length MUST be 64 bits (i.e., 8 bytes). Hence, if less information bits are to be transmitted, padding MUST be used with bits equal to 0. The receiver MUST remove the added padding bits before the SCHC reassembly process.

4. Fragmentation Rules Examples

This section provides an example of RuleID configuration for interoperability between the F/R modes presented in this document. Note that the RuleID space for Uplink F/R is different than the one for Downlink F/R; therefore, this section is divided in two subsections: Rules for Uplink fragmentation and Rules for Downlink fragmentation.

For Uplink F/R, multiple header lengths were described in Section 3.5. All of them are part of the SCHC over Sigfox Profile and offer not only low protocol overhead for small payloads (single byte header) but also extensibility to transport larger payloads with more overhead (2-byte header, Options 1 and 2). The usage of the RuleID space for each header length is an implementation choice, but we provide an example of it in the following section. This illustrates implementation choices made in order to 1) identify the different header length and 2) finally parse the RuleID field to identify the RuleID value and execute the associated treatment.

5. Fragmentation Sequence Examples

In this section, some sequence diagrams depict message exchanges for different fragmentation modes and use cases are shown. In the examples, 'Seq' indicates the Sigfox Sequence Number of the frame carrying a fragment.

The FCN field indicates the size of the data packet. The first fragment is marked with FCN = X-1, where X is the number of fragments the message is split into. All fragments are marked with decreasing FCN values. 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-Losses

When the first SCHC Fragment is received, the receiver can calculate the total number of SCHC Fragments that the SCHC Packet is composed of. For example, if the first fragment is numbered with FCN=6, the receiver can 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)

The Single-byte SCHC Header ACK-on-Error mode allows sending up to 28 fragments and packet sizes up to 300 bytes. The SCHC Fragments may be delivered asynchronously, and Downlink ACK can be sent opportunistically.

Case No Losses

The Downlink flag must be enabled in the sender Uplink message to allow a Downlink message from the receiver. The Downlink Enable in the figures 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

In this case, fragments are lost in the first window (W=0). After the first All-0 message arrives, the receiver leverages the opportunity and sends a SCHC ACK with the corresponding bitmap and C=0.

After the loss fragments from the first window (W=0) are resent, the sender continues transmitting the fragments of the following window (W=1) without opening a reception opportunity. Finally, the All-1 fragment is sent, the Downlink is enabled, and the SCHC ACK is received with C=1. Note that the SCHC Compound ACK also uses a Sequence Number.

        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) is lost. Therefore, the receiver waits for the next All-0 message of intermediate windows or All-1 message of last window to generate the corresponding SCHC ACK, which indicates that the All-0 of window 0 is absent.

The sender resends the missing All-0 messages (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 following diagram, besides the All-0, there are 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

In the next examples, there are fragment losses in both the first (W=0) and second (W=1) windows. The retransmission cycles after the All-1 is sent (i.e., not in intermediate windows) MUST always finish with an All-1, as it serves as an ACK Request message to confirm the correct reception of the retransmitted fragments.

        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)

The figure below is a similar case as above but 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 does not implement the SCHC ACK REQ message. Instead, it uses the SCHC All-1 message to request a SCHC ACK when required.

       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 example, SCHC Fragment losses are found in both windows 0 and 1. However, the sender does not send a SCHC Compound ACK after the All-0 of window 0. Instead, it sends a SCHC Compound ACK indicating fragment losses on both windows.

        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 will be retransmitted is determined by the MAX_ACK_REQUESTS.

5.3. SCHC Abort Examples

Case SCHC Sender-Abort

The sender may need to send a Sender-Abort to stop the current communication. For example, this may happen if the All-1 has been sent MAX_ACK_REQUESTS times.

        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 may need to send a Receiver-Abort to stop the current communication. This message can only be sent after a Downlink Enable.

        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 ensures the integrity of each message. This is achieved by using a unique Device ID and an AES-128-based message authentication code, ensuring that the message has been generated and sent by the device (see [sigfox-spec], Section 3.8) or Network (see [sigfox-spec], Section 4.3) with the ID claimed in the message [sigfox-spec].

Application data may or may not be encrypted at the application layer, depending on the criticality of the use case. This flexibility allows a balance between cost and effort versus risk. AES-128 in counter mode is used for encryption. Cryptographic keys are independent for each device. These keys are associated with the Device ID, and separate integrity and encryption keys are pre-provisioned. An encryption key is only provisioned if confidentiality is 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 previously described security mechanisms 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] are applicable to the profile specified in this document.

In some circumstances, sending device location information is privacy sensitive. The Device Geolocation parameter provided by the Network is optional; therefore, it can be omitted to protect this aspect of the device privacy.

7. IANA Considerations

This document has no IANA actions.

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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7252>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <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, , <https://www.rfc-editor.org/info/rfc8259>.
[RFC8376]
Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, , <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, , <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.

Authors' Addresses

Juan Carlos Zúñiga
Montreal QC
Canada
Carles Gomez
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Sergio Aguilar
Universitat Politècnica de Catalunya
C/Esteve Terradas, 7
08860 Castelldefels
Spain
Laurent Toutain
IMT-Atlantique
CS 17607
2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Sandra Céspedes
Concordia University
1455 De Maisonneuve Blvd. W.
Montreal QC H3G 1M8
Canada
Diego Wistuba
NIC Labs, Universidad de Chile
Av. Almte. Blanco Encalada 1975
Santiago
Chile
Julien Boite
Unabiz (Sigfox)
Labege
France
URI: https://www.sigfox.com/
RFC 9442: Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area Network (LPWAN)
Proposed Standard