diff options
Diffstat (limited to 'doc/rfc/rfc9442.txt')
| -rw-r--r-- | doc/rfc/rfc9442.txt | 1830 |
1 files changed, 1830 insertions, 0 deletions
diff --git a/doc/rfc/rfc9442.txt b/doc/rfc/rfc9442.txt new file mode 100644 index 0000000..1861021 --- /dev/null +++ b/doc/rfc/rfc9442.txt @@ -0,0 +1,1830 @@ + + + + +Internet Engineering Task Force (IETF) JC. Zúñiga +Request for Comments: 9442 +Category: Standards Track C. Gomez +ISSN: 2070-1721 S. Aguilar + Universitat Politècnica de Catalunya + L. Toutain + IMT-Atlantique + S. Céspedes + Concordia University + D. Wistuba + NIC Labs, Universidad de Chile + J. Boite + Unabiz (Sigfox) + July 2023 + + +Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area + Network (LPWAN) + +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. + +Copyright Notice + + Copyright (c) 2023 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. SCHC over Sigfox + 3.1. Network Architecture + 3.2. Uplink + 3.3. Downlink + 3.3.1. SCHC ACK on Downlink + 3.4. SCHC Rules + 3.5. Fragmentation + 3.5.1. Uplink Fragmentation + 3.5.2. Downlink Fragmentation + 3.6. SCHC over Sigfox F/R Message Formats + 3.6.1. Uplink No-ACK Mode: Single-Byte SCHC Header + 3.6.2. Uplink ACK-on-Error Mode: Single-Byte SCHC Header + 3.6.3. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1 + 3.6.4. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2 + 3.6.5. Downlink ACK-Always Mode: Single-Byte SCHC Header + 3.7. Padding + 4. Fragmentation Rules Examples + 4.1. Uplink Fragmentation Rules Examples + 4.2. Downlink Fragmentation Rules Example + 5. Fragmentation Sequence Examples + 5.1. Uplink No-ACK Examples + 5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header + 5.3. SCHC Abort Examples + 6. Security Considerations + 7. IANA Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Authors' Addresses + +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.2. Uplink + + Uplink Sigfox transmissions occur in repetitions over different times + and frequencies. Besides time and frequency diversities, the Sigfox + network also provides spatial diversity, as potentially an Uplink + message will be received by several Base Stations. The Uplink + message application payload size can be up to 12 bytes. + + Since all messages are self-contained and Base Stations forward all + these messages back to the same Sigfox network, multiple input copies + can be combined at the NGW, providing for extra reliability based on + the triple diversity (i.e., time, space, and frequency). + + A detailed description of the Sigfox radio protocol can be found in + [sigfox-spec]. + + Messages sent from the device to the Network are delivered by the + Sigfox cloud-based Network to the Network SCHC C/D + F/R through a + callback/API with the following information: + + * 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, + which is included in the Sigfox header of every message. The Message + Sequence Number is a monotonically increasing number identifying the + specific transmission of this Uplink message, and it is also part of + the Sigfox header. The Message Payload corresponds to the payload + that the device has sent in the Uplink transmission. Battery + Voltage, Device Temperature, and RSSI values are sent in the + confirmation control message, which is mandatorily sent by the device + after the successful reception of a Downlink message (see + [sigfox-callbacks], Section 5.2). + + The Message Timestamp, Device Geolocation, RSSI, Device Temperature, + and Device Battery Voltage are metadata parameters provided by the + Network. + + A detailed description of the Sigfox callbacks/APIs can be found in + [sigfox-callbacks]. + + Only messages that have passed the L2 Cyclic Redundancy Check (CRC) + at Network reception are delivered by the Sigfox network to the + Network SCHC C/D + F/R. + + The L2 Word size used by Sigfox is 1 byte (8 bits). + + Figure 2 shows a SCHC message sent over Sigfox, where the SCHC + message could be a full SCHC Packet (e.g., compressed) or a SCHC + Fragment (e.g., a piece of a bigger SCHC Packet). + + | Sigfox Header | Sigfox Payload | + +---------------+---------------- + + | SCHC Message | + + Figure 2: SCHC Message in Sigfox + +3.3. Downlink + + Downlink transmissions are device-driven and can only take place + following an Uplink communication that indicates Downlink + communication can be performed. Hence, a Sigfox Device explicitly + indicates its intention to receive a Downlink message (with a size of + 8 bytes) using a Downlink request flag when sending the preceding + Uplink message to the Network. The Downlink request flag is part of + the Sigfox protocol headers. After completing the Uplink + transmission, the device opens a fixed window for Downlink reception. + The delay and duration of the reception opportunity window have fixed + values. If there is a Downlink message to be sent for this given + device (e.g., either a response to the Uplink message or queued + information waiting to be transmitted), the Network transmits this + message to the device during the reception window. If no message is + received by the device after the reception opportunity window has + elapsed, the device closes the reception window opportunity and gets + back to the normal mode (e.g., continue Uplink transmissions, sleep, + standby, etc.). + + When a Downlink message is sent to a device, a reception + acknowledgement is generated by the device, sent back to the Network + through the Sigfox radio protocol, and reported in the Sigfox network + backend. + + A detailed description of the Sigfox radio protocol can be found in + [sigfox-spec], and a detailed description of the Sigfox callbacks/ + APIs can be found in [sigfox-callbacks]. A Downlink request flag can + be included in the information exchange between the Sigfox network + and Network SCHC. + +3.3.1. SCHC ACK on Downlink + + As explained previously, Downlink transmissions are driven by devices + and can only take place following a specific Uplink transmission that + indicates and allows a following Downlink opportunity. For this + reason, when SCHC bidirectional services are used (e.g., ACK-on-Error + fragmentation mode), the SCHC protocol implementation needs to + consider the times when a Downlink message (e.g., SCHC + Acknowledgement (ACK)) can be sent and/or received. + + For the Uplink ACK-on-Error fragmentation mode, a Downlink + opportunity MUST be indicated by the last fragment of every window, + which is signalled by a specific value of the Fragment Compressed + Number (FCN) value, i.e., FCN = All-0 or FCN = All-1. The FCN is the + tile index in a specific window. The combination of the FCN and the + window number uniquely identifies a SCHC Fragment, as explained in + [RFC8724]. The device sends the 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 further one) with a SCHC ACK, indicating + that there are missing fragments from the current or previous + windows. If there is no SCHC ACK to be sent, or if the Network + decides to wait for a further Downlink transmission opportunity, then + no Downlink transmission takes place at that opportunity and the + Uplink transmissions continue after a timeout. Intermediate SCHC + Fragments with FCNs that are different from 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 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.5.1. Uplink Fragmentation + + Sigfox Uplink transmissions are completely asynchronous and take + place in any random frequency of the allowed Uplink bandwidth + allocation. In addition, devices may go to deep sleep mode and then + wake up and transmit whenever there is a need to send information to + the Network, as there is no need to perform any Network attachment, + synchronization, or other procedures before transmitting 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. In the case of 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 the case of this profile, a SCHC Receiver-Abort MUST be sent if, + for a single device, all the RuleIDs are being processed by the + receiver (i.e., 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 + + Single-byte SCHC Header No-ACK mode MUST be used for transmitting + short, non-critical packets that require fragmentation and do not + require full reliability. This mode can be used by Uplink-only + devices that do not support Downlink communications or by + bidirectional devices when they send non-critical data. Note that + sending non-critical data by using a reliable fragmentation mode + (which is only possible for bidirectional devices) may incur + unnecessary overhead. + + Since there are no multiple windows in the No-ACK mode, the W bit is + not present. However, it MUST use the FCN field to indicate the size + of the data packet. In this sense, the data packet would need to be + split into X fragments and, similarly to the other fragmentation + modes, the first transmitted fragment would need to be marked with + FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN + values, having the last fragment marked with FCN = (All-1). Hence, + even though the No-ACK mode does not allow recovering missing + fragments, it allows implicitly indicating the size of the expected + packet to the Network and hence detects whether all fragments have + been received or not at the receiver side. In case the FCN field is + not used to indicate the size of the data packet, the Network can + detect whether all fragments have been received or not 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: + + * RuleID size: 3 bits + + * DTag size (T): 0 bits + + * Fragment Compressed Number (FCN) size (N): 5 bits + + 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: 11 bytes + + * All-1 tile size: 0 to 10 bytes + + * Inactivity Timer: Application-dependent. The default value is 12 + hours. + + * RCS size: 5 bits + + 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 + optimal for reliable SCHC Packet transmission over Sigfox + transmissions, since it leads to a reduced number of ACKs in the + lower-capacity Downlink channel. Also, Downlink messages can be sent + asynchronously and opportunistically. In contrast, ACK-Always would + not minimize the number of ACKs, and No-ACK would not allow reliable + transmission. + + 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: + + * RuleID size: 3 bits + + * DTag size (T): 0 bits + + * Window index (W) size (M): 2 bits + + * Fragment Compressed Number (FCN) size (N): 3 bits + + Other F/R parameters MUST be configured as follows: + + * MAX_ACK_REQUESTS: 5 + + * WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110) + + * Regular tile size: 11 bytes + + * All-1 tile size: 0 to 10 bytes + + * Retransmission Timer: Application-dependent. The default value is + 12 hours. + + * Inactivity Timer: Application-dependent. The default value is 12 + hours. + + * RCS size: 3 bits + + 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. 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. Also, Downlink messages can be sent asynchronously and + opportunistically. In contrast, 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 + + In order 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: + + * RuleID size: 6 bits + + * DTag size (T): 0 bits + + * Window index (W) size (M): 2 bits + + * Fragment Compressed Number (FCN) size (N): 4 bits + + * RCS size: 4 bits + + Other F/R parameters MUST be configured as follows: + + * MAX_ACK_REQUESTS: 5 + + * WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011) + + * Regular tile size: 10 bytes + + * All-1 tile size: 1 to 10 bytes + + * Retransmission Timer: Application-dependent. The default value is + 12 hours. + + * Inactivity Timer: Application-dependent. The default value is 12 + hours. + + 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 + + In order to allow transmission of 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: + + * RuleID size: 8 bits + + * DTag size (T): 0 bits + + * Window index (W) size (M): 3 bits + + * Fragment Compressed Number (FCN) size (N): 5 bits + + * RCS size: 5 bits + + Other F/R parameters MUST be configured as follows: + + * MAX_ACK_REQUESTS: 5 + + * WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) + + * Regular tile size: 10 bytes + + * All-1 tile size: 0 to 9 bytes + + * Retransmission Timer: Application-dependent. The default value is + 12 hours. + + * Inactivity Timer: Application-dependent. The default value is 12 + hours. + + 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 composed 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 determine from the FCN values alone whether there are + or are not any missing fragments 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 if there are missing fragments before + the All-1 and hence 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 allows the device to go in a very deep sleep mode + and preserve battery without the need to listen to any information + from the Network. This is the case for Sigfox-enabled devices, which + can only listen to Downlink communications after performing an Uplink + transmission and requesting a Downlink. + + When there are fragments to be transmitted in the Downlink, an Uplink + message is required to trigger the Downlink communication. In order + 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 reception of a Downlink + fragment that is not the last one. Such an Uplink transmission MAY + be triggered by sending a SCHC message, such as a SCHC ACK. However, + 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). Hence, + 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 does not guarantee Uplink + feedback (since no SCHC ACK will be sent when no errors occur in a + window), and No-ACK would not allow reliable transmission. + + The SCHC Downlink fragmentation header size is 8 bits in size and is + composed as follows: + + * RuleID size: 3 bits + + * DTag size (T): 0 bits + + * Window index (W) size (M): 0 bits + + * Fragment Compressed Number (FCN) size (N): 5 bits + + Other F/R parameters MUST be configured as follows: + + * MAX_ACK_REQUESTS: 5 + + * WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110) + + * Regular tile size: 7 bytes + + * All-1 tile size: 0 to 6 bytes + + * Retransmission Timer: Application-dependent. The default value is + 12 hours. + + * Inactivity Timer: Application-dependent. The default value is 12 + hours. + + * RCS size: 5 bits + +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. 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 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. Uplink ACK-on-Error Mode: Single-Byte SCHC Header + +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. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2 + +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. Downlink ACK-Always Mode: Single-Byte SCHC Header + +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. + +4.1. Uplink Fragmentation Rules Examples + + The RuleID field for Uplink F/R modes has different sizes depending + on the header length. In order to identify the header length and + then the value of the RuleID, the RuleID field is interpreted as + follows: + + * The RuleID field is the first one to be 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 have a value different than + 0b'111, then it signals a Single-byte SCHC Header F/R mode. + + - If their value is 0b'111, then it signals a Two-byte SCHC + Header F/R mode. + + * For Single-byte SCHC Header F/R modes: + + - There are 7 RuleIDs available (with values from 0b'000-0b'110); + the RuleID with value 0b'111 is reserved to indicate a Two-byte + SCHC Header. + + - This set of Rules is called "standard rules", and it is used to + implement Single-byte SCHC Header modes. + + - Each RuleID is associated with a set of properties defining if + Uplink F/R is used and which Uplink F/R mode is used. As an + example, the RuleID 0b'000 is mapped onto Uplink No-ACK Mode: + Single-byte SCHC Header, and the RuleIDs 0b'001 and 0b'002 are + mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header + (2 RuleIDs to allow for SCHC Packet interleaving). + + * 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. + + o If the following 3 bits have a different value than 0b'111, + then it signals the Two-byte SCHC Header Option 1. + + o If the following 3 bits are 0b'111, then it signals the Two- + byte SCHC Header Option 2. + + - For the Two-byte SCHC Header Option 1, there are 7 RuleIDs + available (0b'111000-0b'111110), 0b'111111 being reserved to + indicate the Two-byte SCHC Header Option 2. This set of Rules + is called "extended rules", and it is 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'11111100-0b'11111111). This set of Rules is used to cover + specific cases that previous RuleIDs do not cover. As an + example, RuleID 0b'00111111 is used to transport uncompressed + IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC + Header Option 2. + +4.2. Downlink Fragmentation Rules Example + + For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs + can get values in ranges from 0b'000 to 0b'111. + +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. + +5.1. Uplink No-ACK Examples + + 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) + +5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header + + 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, 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. + +Authors' Addresses + + Juan Carlos Zúñiga + Montreal QC + Canada + Email: j.c.zuniga@ieee.org + + + Carles Gomez + Universitat Politècnica de Catalunya + C/Esteve Terradas, 7 + 08860 Castelldefels + Spain + Email: carles.gomez@upc.edu + + + Sergio Aguilar + Universitat Politècnica de Catalunya + C/Esteve Terradas, 7 + 08860 Castelldefels + Spain + Email: sergio.aguilar.romero@upc.edu + + + Laurent Toutain + IMT-Atlantique + CS 17607 + 2 rue de la Chataigneraie + 35576 Cesson-Sevigne Cedex + France + Email: Laurent.Toutain@imt-atlantique.fr + + + Sandra Céspedes + Concordia University + 1455 De Maisonneuve Blvd. W. + Montreal QC H3G 1M8 + Canada + Email: sandra.cespedes@concordia.ca + + + Diego Wistuba + NIC Labs, Universidad de Chile + Av. Almte. Blanco Encalada 1975 + Santiago + Chile + Email: research@witu.cl + + + Julien Boite + Unabiz (Sigfox) + Labege + France + Email: juboite@free.fr + URI: https://www.sigfox.com/ |