rfc9442.original		rfc9442.txt
	lpwan Working Group JC. Zuniga		Internet Engineering Task Force (IETF) JC. Zúñiga
	Internet-Draft		Request for Comments: 9442
	Intended status: Standards Track C. Gomez		Category: Standards Track C. Gomez
	Expires: 7 August 2023 S. Aguilar		ISSN: 2070-1721 S. Aguilar
	Universitat Politecnica de Catalunya		Universitat Politècnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	S. Cespedes		S. Céspedes
	Concordia University		Concordia University
	D. Wistuba		D. Wistuba
	NIC Labs, Universidad de Chile		NIC Labs, Universidad de Chile
	J. Boite		J. Boite
	Unabiz (Sigfox)		Unabiz (Sigfox)
	3 February 2023		July 2023
	SCHC over Sigfox LPWAN		Static Context Header Compression (SCHC) over Sigfox Low-Power Wide Area
	draft-ietf-lpwan-schc-over-sigfox-23		Network (LPWAN)
	Abstract		Abstract
	The Static Context Header Compression and fragmentation (SCHC)		The Static Context Header Compression (SCHC) and fragmentation
	specification (RFC8724) describes a generic framework for application		specification (RFC 8724) describes a generic framework for
	header compression and fragmentation modes designed for Low Power		application header compression and fragmentation modes designed for
	Wide Area Network (LPWAN) technologies. The present document defines		Low-Power Wide Area Network (LPWAN) technologies. This document
	a profile of SCHC over Sigfox LPWAN, and provides optimal parameter		defines a profile of SCHC over Sigfox LPWAN and provides optimal
	values and modes of operation.		parameter values and modes of operation.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on 7 August 2023.		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 Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2023 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as		to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are		include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.		Trust Legal Provisions and are provided without warranty as described
			in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology
	3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4		3. SCHC over Sigfox
	3.1. Network Architecture . . . . . . . . . . . . . . . . . . 4		3.1. Network Architecture
	3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Uplink
	3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Downlink
	3.3.1. SCHC ACK on Downlink . . . . . . . . . . . . . . . . 8		3.3.1. SCHC ACK on Downlink
	3.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 9		3.4. SCHC Rules
	3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9		3.5. Fragmentation
	3.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 10		3.5.1. Uplink Fragmentation
	3.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 15		3.5.2. Downlink Fragmentation
	3.6. SCHC over Sigfox F/R Message Formats . . . . . . . . . . 16		3.6. SCHC over Sigfox F/R Message Formats
	3.6.1. Uplink No-ACK Mode: Single-byte SCHC Header . . . . . 16		3.6.1. Uplink No-ACK Mode: Single-Byte SCHC Header
	3.6.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 18		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		3.6.3. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1
	1 . . . . . . . . . . . . . . . . . . . . . . . . . . 20		3.6.4. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2
	3.6.4. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option		3.6.5. Downlink ACK-Always Mode: Single-Byte SCHC Header
	2 . . . . . . . . . . . . . . . . . . . . . . . . . . 22		3.7. Padding
	3.6.5. Downlink ACK-Always Mode: Single-byte SCHC Header . . 25		4. Fragmentation Rules Examples
	3.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 27		4.1. Uplink Fragmentation Rules Examples
	4. Fragmentation Rules Examples . . . . . . . . . . . . . . . . 27		4.2. Downlink Fragmentation Rules Example
	4.1. Uplink Fragmentation Rules Examples . . . . . . . . . . . 27		5. Fragmentation Sequence Examples
	4.2. Downlink Fragmentation Rules Example . . . . . . . . . . 29		5.1. Uplink No-ACK Examples
	5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 29		5.2. Uplink ACK-on-Error Examples: Single-Byte SCHC Header
	5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 29		5.3. SCHC Abort Examples
	5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 30		6. Security Considerations
	5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 36		7. IANA Considerations
	6. Security considerations . . . . . . . . . . . . . . . . . . . 37		8. References
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38		8.1. Normative References
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38		8.2. Informative References
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		Acknowledgements
	9.1. Normative References . . . . . . . . . . . . . . . . . . 38		Authors' Addresses
	9.2. Informative References . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
	1. Introduction		1. Introduction
	The Generic Framework for Static Context Header Compression and		The Generic Framework for Static Context Header Compression (SCHC)
	Fragmentation (SCHC) specification [RFC8724] can be used in		and Fragmentation specification [RFC8724] can be used in conjunction
	conjunction with any of the four LPWAN technologies described in		with any of the four LPWAN technologies described in [RFC8376].
	[RFC8376]. These LPWANs have similar characteristics such as star-		These LPWANs have similar characteristics, such as star-oriented
	oriented topologies, network architecture, connected devices with		topologies, network architecture, connected devices with built-in
	built-in applications, etc.		applications, etc.
	SCHC offers a considerable degree of flexibility to accommodate all		SCHC offers a considerable degree of flexibility to accommodate all
	these LPWAN technologies. Even though there are a great number of		these LPWAN technologies. Even though there are a great number of
	similarities between them, some differences exist with respect to the		similarities between them, some differences exist with respect to the
	transmission characteristics, payload sizes, etc. Hence, there are		transmission characteristics, payload sizes, etc. Hence, there are
	optimal parameters and modes of operation that can be used when SCHC		optimal parameters and modes of operation that can be used when SCHC
	is used in conjunction with a specific LPWAN technology.		is used in conjunction with a specific LPWAN technology.
	Sigfox is an LPWAN technology that offers energy-efficient		Sigfox is an LPWAN technology that offers energy-efficient
	connectivity for devices at a very low cost. Sigfox complete		connectivity for devices at a very low cost. Complete Sigfox
	documentation can be found in [sigfox-docs]. Sigfox aims to provide		documentation can be found in [sigfox-docs]. Sigfox aims to provide
	a very wide area network composed of Base Stations that receive short		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		Uplink messages (up to 12 bytes in size) sent by devices over the
	long-range Sigfox radio protocol, as described in [RFC8376]. Base		long-range Sigfox radio protocol, as described in [RFC8376]. Base
	Stations then forward messages to the Sigfox Cloud infrastructure for		Stations then forward messages to the Sigfox Cloud infrastructure for
	further processing (e.g., to offer geolocation services) and final		further processing (e.g., to offer geolocation services) and final
	delivery to the customer. Base Stations also relay downlink messages		delivery to the customer. Base Stations also relay Downlink messages
	(with a fixed 8 bytes size) sent by the Sigfox Cloud to the devices,		(with a fixed 8-byte size) sent by the Sigfox Cloud to the devices,
	downlink messages being generated when devices explicitly request for		i.e., Downlink messages are being generated when devices explicitly
	it with a flag in an uplink message. With SCHC functionalities, the		request these messages with a flag in an Uplink message. With SCHC
	Sigfox network offers more reliable communications (including		functionalities, the Sigfox network offers more reliable
	recovery of lost messages) and is able to convey extended-size		communications (including recovery of lost messages) and is able to
	payloads (allowing for fragmentation/reassembly of messages)		convey extended-size payloads (allowing for fragmentation/reassembly
	[sigfox-spec].		of messages) [sigfox-spec].
	This document describes the parameters, settings, and modes of		This document describes the parameters, settings, and modes of
	operation to be used when SCHC is implemented over a Sigfox LPWAN.		operation to be used when SCHC is implemented over a Sigfox LPWAN.
	The set of parameters forms a "SCHC over Sigfox profile". The SCHC		The set of parameters forms a "SCHC over Sigfox Profile". The SCHC
	over Sigfox Profile is applicable to the Sigfox Radio specification		over Sigfox Profile is applicable to the Sigfox Radio specification
	versions up to v1.6/March 2022 [sigfox-spec] (support for future		versions up to v1.6/March 2022 [sigfox-spec] (support for future
	versions would have to be assessed).		versions would have to be assessed).
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	It is assumed that the reader is familiar with the terms and		It is assumed that the reader is familiar with the terms and
	mechanisms defined in [RFC8376] and in [RFC8724]. Also, it is		mechanisms defined in [RFC8376] and [RFC8724]. Also, it is assumed
	assumed that the reader is familiar with Sigfox terminology		that the reader is familiar with Sigfox terminology [sigfox-spec].
	[sigfox-spec].
	3. SCHC over Sigfox		3. SCHC over Sigfox
	The Generic SCHC Framework described in [RFC8724] takes advantage of		The Generic SCHC Framework described in [RFC8724] takes advantage of
	previous knowledge of traffic flows existing in LPWAN applications to		previous knowledge of traffic flows existing in LPWAN applications to
	avoid context synchronization.		avoid context synchronization.
	Contexts need to be stored and pre-configured on both ends. This can		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		be done either by using a provisioning protocol, by out-of-band
	means, or by pre-provisioning them (e.g., at manufacturing time).		means, or by pre-provisioning them (e.g., at manufacturing time).
	For example, the context exchange can be done by using		For example, the context exchange can be done by using the Network
	NETCONF[RFC6241] with SSH, RESTCONF[RFC8040] with HTTPs, and		Configuration Protocol (NETCONF) [RFC6241] with Secure Shell (SSH),
	CORECONF[I-D.ietf-core-comi] with CoAP[RFC7252] as provisioning		RESTCONF [RFC8040] with secure HTTP methods, and CoAP Management
	protocols. The contexts can be encoded in XML under NETCONF, in		Interface (CORECONF) [CORE-COMI] with the Constrained Application
	JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF.		Protocol (CoAP) [RFC7252] as provisioning protocols. The contexts
	The way contexts are configured and stored on both ends is out of the		can be encoded in XML under NETCONF, in JSON [RFC8259] under
	scope of this document.		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		3.1. Network Architecture
	Figure 1 represents the architecture for Compression/Decompression		Figure 1 represents the architecture for Compression/Decompression
	(C/D) and Fragmentation/Reassembly (F/R) based on the terminology		(C/D) and Fragmentation/Reassembly (F/R) based on the terminology
	defined in [RFC8376], where the Radio Gateway (RGW) is a Sigfox Base		defined in [RFC8376], where the Radio Gateway (RGW) is a Sigfox Base
	Station and the Network Gateway (NGW) is the Sigfox cloud-based		Station and the Network Gateway (NGW) is the Sigfox cloud-based
	Network.		Network.
	Sigfox Device Application		Sigfox Device Application
	skipping to change at page 5, line 31 ¶		skipping to change at line 198 ¶
	+---------+ +--------------+ +---------+ Network		+---------+ +--------------+ +---------+ Network
	------- Uplink message ------>		------- Uplink message ------>
	<------- Downlink message ------		<------- Downlink message ------
	Legend:		Legend:
	$, ~ : Radio link		$, ~ : Radio link
	= : Internal Sigfox Network		= : Internal Sigfox Network
	. : External IP-based Network		. : External IP-based Network
	Figure 1: Network Architecture		Figure 1: Network Architecture
	In the case of the global Sigfox Network, RGWs (or Base Stations) are		In the case of the global Sigfox network, RGWs (or Base Stations) are
	distributed over multiple countries wherever the Sigfox LPWAN service		distributed over multiple countries wherever the Sigfox LPWAN service
	is provided. The NGW (or cloud-based Sigfox Core Network) is a		is provided. The NGW (or cloud-based Sigfox Core Network) is a
	single entity that connects to all RGWs (Sigfox Base Stations) in the		single entity that connects to all RGWs (Sigfox Base Stations) in the
	world, providing hence a global single star network topology.		world, hence providing a global single star Network topology.
	The Sigfox Device sends application packets that are compressed and/		The Sigfox Device sends application packets that are compressed and/
	or fragmented by a SCHC C/D + F/R to reduce headers size and/or		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		fragment the packet. The resulting SCHC message is sent over a layer
	two (L2) Sigfox frame to the Sigfox Base Stations, which then		two (L2) Sigfox frame to the Sigfox Base Stations, which then forward
	forwards the SCHC Message to the Network Gateway (NGW). The NGW then		the SCHC message to the NGW. The NGW then delivers the SCHC message
	delivers the SCHC Message and associated gathered metadata to the		and associated gathered metadata to the Network SCHC C/D + F/R.
	Network SCHC C/D + F/R.
	The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R		The Sigfox cloud-based Network communicates with the Network SCHC C/D
	for compression/decompression and/or for fragmentation/reassembly.		+ F/R for compression/decompression and/or for fragmentation/
	The Network SCHC C/D + F/R shares the same set of rules as the Device		reassembly. The Network SCHC C/D + F/R shares the same set of Rules
	SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with		as the device SCHC C/D + F/R. The Network SCHC C/D + F/R can be
	the NGW or it could be located in a different place, as long as a		collocated with the NGW or it could be located in a different place,
	tunnel or secured communication is established between the NGW and		as long as a tunnel or secured communication is established between
	the SCHC C/D + F/R functions. After decompression and/or reassembly,		the NGW and the SCHC C/D + F/R functions. After decompression and/or
	the packet can be forwarded over the Internet to one (or several)		reassembly, the packet can be forwarded over the Internet to one (or
	LPWAN Application Server(s) (App).		several) LPWAN Application Server(s) (App(s)).
	The SCHC C/D + F/R processes are bidirectional, so the same		The SCHC C/D + F/R processes are bidirectional, so the same
	principles are applicable on both Uplink (UL) and Downlink (DL).		principles are applicable on both Uplink (UL) and Downlink (DL).
	3.2. Uplink		3.2. Uplink
	Uplink Sigfox transmissions occur in repetitions over different times		Uplink Sigfox transmissions occur in repetitions over different times
	and frequencies. Besides time and frequency diversities, the Sigfox		and frequencies. Besides time and frequency diversities, the Sigfox
	network also provides spatial diversity, as potentially an Uplink		network also provides spatial diversity, as potentially an Uplink
	message will be received by several base stations. The uplink		message will be received by several Base Stations. The Uplink
	message application payload size can be up to 12 bytes.		message application payload size can be up to 12 bytes.
	Since all messages are self-contained and base stations forward all		Since all messages are self-contained and Base Stations forward all
	these messages back to the same Sigfox Network, multiple input copies		these messages back to the same Sigfox network, multiple input copies
	can be combined at the NGW providing for extra reliability based on		can be combined at the NGW, providing for extra reliability based on
	the triple diversity (i.e., time, space and frequency).		the triple diversity (i.e., time, space, and frequency).
	A detailed description of the Sigfox Radio Protocol can be found in		A detailed description of the Sigfox radio protocol can be found in
	[sigfox-spec].		[sigfox-spec].
	Messages sent from the Device to the Network are delivered by the		Messages sent from the device to the Network are delivered by the
	Sigfox network (NGW) to the Network SCHC C/D + F/R through a		Sigfox cloud-based Network to the Network SCHC C/D + F/R through a
	callback/API with the following information:		callback/API with the following information:
	* Device ID		* Device ID
	* Message Sequence Number		* Message Sequence Number
	* Message Payload		* Message Payload
	* Message Timestamp		* Message Timestamp
	* Device Geolocation (optional)		* Device Geolocation (optional)
	* Received Signal Strength Indicator (RSSI) (optional)		* Received Signal Strength Indicator (RSSI) (optional)
	* Device Temperature (optional)		* Device Temperature (optional)
	* Device Battery Voltage (optional)		* Device Battery Voltage (optional)
	The Device ID is a globally unique identifier assigned to the Device,
			The Device ID is a globally unique identifier assigned to the device,
	which is included in the Sigfox header of every message. The Message		which is included in the Sigfox header of every message. The Message
	Sequence Number is a monotonically increasing number identifying the		Sequence Number is a monotonically increasing number identifying the
	specific transmission of this Uplink message, and it is also part of		specific transmission of this Uplink message, and it is also part of
	the Sigfox header. The Message Payload corresponds to the payload		the Sigfox header. The Message Payload corresponds to the payload
	that the Device has sent in the Uplink transmission. Battery		that the device has sent in the Uplink transmission. Battery
	Voltage, temperature and RSSI values are sent in the confirmation		Voltage, Device Temperature, and RSSI values are sent in the
	control message, which is mandatorially sent by the device after the		confirmation control message, which is mandatorily sent by the device
	successful reception of a downlink message (see [sigfox-callbacks]		after the successful reception of a Downlink message (see
	Section 5.2).		[sigfox-callbacks], Section 5.2).
	The Message Timestamp, Device Geolocation, RSSI, Device Temperature		The Message Timestamp, Device Geolocation, RSSI, Device Temperature,
	and Device Battery Voltage are metadata parameters provided by the		and Device Battery Voltage are metadata parameters provided by the
	Network.		Network.
	A detailed description of the Sigfox callbacks/APIs can be found in		A detailed description of the Sigfox callbacks/APIs can be found in
	[sigfox-callbacks].		[sigfox-callbacks].
	Only messages that have passed the L2 Cyclic Redundancy Check (CRC)		Only messages that have passed the L2 Cyclic Redundancy Check (CRC)
	at network reception are delivered by the Sigfox Network to the		at Network reception are delivered by the Sigfox network to the
	Network SCHC C/D + F/R.		Network SCHC C/D + F/R.
	The L2 Word Size used by Sigfox is 1 byte (8 bits).		The L2 Word size used by Sigfox is 1 byte (8 bits).
	Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC		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		message could be a full SCHC Packet (e.g., compressed) or a SCHC
	Fragment (e.g., a piece of a bigger SCHC Packet).		Fragment (e.g., a piece of a bigger SCHC Packet).
	| Sigfox Header | Sigfox payload |		| Sigfox Header | Sigfox Payload |
	+---------------+---------------- +		+---------------+---------------- +
	| SCHC message |		| SCHC Message |
	Figure 2: SCHC Message in Sigfox		Figure 2: SCHC Message in Sigfox
	3.3. Downlink		3.3. Downlink
	Downlink transmissions are Device-driven and can only take place		Downlink transmissions are device-driven and can only take place
	following an Uplink communication that so indicates. Hence, a Sigfox		following an Uplink communication that indicates Downlink
	Device explicitly indicates its intention to receive a Downlink		communication can be performed. Hence, a Sigfox Device explicitly
	message (with a size of 8 bytes) using a Downlink request flag when		indicates its intention to receive a Downlink message (with a size of
	sending the preceding Uplink message to the network. The Downlink		8 bytes) using a Downlink request flag when sending the preceding
	request flag is part of the Sigfox protocol headers. After		Uplink message to the Network. The Downlink request flag is part of
	completing the Uplink transmission, the Device opens a fixed window		the Sigfox protocol headers. After completing the Uplink
	for Downlink reception. The delay and duration of the reception		transmission, the device opens a fixed window for Downlink reception.
	opportunity window have fixed values. If there is a Downlink message		The delay and duration of the reception opportunity window have fixed
	to be sent for this given Device (e.g., either a response to the		values. If there is a Downlink message to be sent for this given
	Uplink message or queued information waiting to be transmitted), the		device (e.g., either a response to the Uplink message or queued
	network transmits this message to the Device during the reception		information waiting to be transmitted), the Network transmits this
	window. If no message is received by the Device after the reception		message to the device during the reception window. If no message is
	opportunity window has elapsed, the Device closes the reception		received by the device after the reception opportunity window has
	window opportunity and gets back to the normal mode (e.g., continue		elapsed, the device closes the reception window opportunity and gets
	Uplink transmissions, sleep, stand-by, etc.)		back to the normal mode (e.g., continue Uplink transmissions, sleep,
			standby, etc.).
	When a Downlink message is sent to a Device, a reception		When a Downlink message is sent to a device, a reception
	acknowledgement is generated by the Device and sent back to the		acknowledgement is generated by the device, sent back to the Network
	Network through the Sigfox radio protocol and reported in the Sigfox		through the Sigfox radio protocol, and reported in the Sigfox network
	Network backend.		backend.
	A detailed description of the Sigfox Radio Protocol can be found in		A detailed description of the Sigfox radio protocol can be found in
	[sigfox-spec] and a detailed description of the Sigfox callbacks/APIs		[sigfox-spec], and a detailed description of the Sigfox callbacks/
	can be found in [sigfox-callbacks]. A Downlink request flag can be		APIs can be found in [sigfox-callbacks]. A Downlink request flag can
	included in the information exchange between the Sigfox Network and		be included in the information exchange between the Sigfox network
	Network SCHC.		and Network SCHC.
	3.3.1. SCHC ACK on Downlink		3.3.1. SCHC ACK on Downlink
	As explained previously, Downlink transmissions are Device-driven and		As explained previously, Downlink transmissions are driven by devices
	can only take place following a specific Uplink transmission that		and can only take place following a specific Uplink transmission that
	indicates and allows a following Downlink opportunity. For this		indicates and allows a following Downlink opportunity. For this
	reason, when SCHC bidirectional services are used (e.g., Ack-on-Error		reason, when SCHC bidirectional services are used (e.g., ACK-on-Error
	fragmentation mode) the SCHC protocol implementation needs to		fragmentation mode), the SCHC protocol implementation needs to
	consider the times when a Downlink message (e.g., SCHC ACK) can be		consider the times when a Downlink message (e.g., SCHC
	sent and/or received.		Acknowledgement (ACK)) can be sent and/or received.
	For the Uplink ACK-on-Error fragmentation mode, a Downlink		For the Uplink ACK-on-Error fragmentation mode, a Downlink
	opportunity MUST be indicated by the last fragment of every window,		opportunity MUST be indicated by the last fragment of every window,
	which is signalled by a specific value of the Fragment Compressed		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		Number (FCN) value, i.e., FCN = All-0 or FCN = All-1. The FCN is the
	the tile index in a specific window. The combination of the FCN and		tile index in a specific window. The combination of the FCN and the
	the window number uniquely identifies a SCHC Fragment as explained in		window number uniquely identifies a SCHC Fragment, as explained in
	[RFC8724]. The Device sends the fragments in sequence and, after		[RFC8724]. The device sends the fragments in sequence and, after
	transmitting the FCN = All-0 or FCN = All-1, it opens up a reception		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. The Network SCHC can then decide to respond at that
	opportunity (or wait for a further one) with a SCHC ACK indicating		opportunity (or wait for a further one) with a SCHC ACK, indicating
	that there are missing fragments from the current or previous		that there are missing fragments from the current or previous
	windows. If there is no SCHC ACK to be sent, or if the network		windows. If there is no SCHC ACK to be sent, or if the Network
	decides to wait for a further Downlink transmission opportunity, then		decides to wait for a further Downlink transmission opportunity, then
	no Downlink transmission takes place at that opportunity and after a		no Downlink transmission takes place at that opportunity and the
	timeout the Uplink transmissions continue. Intermediate SCHC		Uplink transmissions continue after a timeout. Intermediate SCHC
	fragments with FCN different from All-0 or All-1 MUST NOT use the		Fragments with FCNs that are different from All-0 or All-1 MUST NOT
	Downlink request flag to request a SCHC ACK.		use the Downlink request flag to request a SCHC ACK.
	3.4. SCHC Rules		3.4. SCHC Rules
	The RuleID MUST be included in the SCHC header. The total number of		The RuleID MUST be included in the SCHC header. The total number of
	rules to be used affects directly the RuleID field size, and		Rules to be used directly affects the RuleID field size, and
	therefore the total size of the fragmentation header. For this		therefore the total size of the fragmentation header. For this
	reason, it is RECOMMENDED to keep the number of rules that are		reason, it is RECOMMENDED to keep the number of Rules that are
	defined for a specific device to the minimum possible. Large RuleID		defined for a specific device to the minimum possible. Large RuleID
	sizes (and thus larger fragmentation header) is acceptable for		sizes (and thus larger fragmentation headers) are acceptable for
	devices without significant energy constraints (e.g., a sensor that		devices without significant energy constraints (e.g., a sensor that
	is powered by the electricity grid).		is powered by the electricity grid).
	RuleIDs can be used to differentiate data traffic classes (e.g., QoS,		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		control vs. data, etc.) and data sessions. They can also be used to
	interleave simultaneous fragmentation sessions between a Device and		interleave simultaneous fragmentation sessions between a device and
	the Network.		the Network.
	3.5. Fragmentation		3.5. Fragmentation
	The SCHC specification [RFC8724] defines a generic fragmentation		The SCHC specification [RFC8724] defines a generic fragmentation
	functionality that allows sending data packets or files larger than		functionality that allows sending data packets or files larger than
	the maximum size of a Sigfox payload. The functionality also defines		the maximum size of a Sigfox payload. The functionality also defines
	a mechanism to send reliably multiple messages, by allowing to resend		a mechanism to reliably send multiple messages by allowing to
	selectively any lost fragments.		selectively resend any lost fragments.
	The SCHC fragmentation supports several modes of operation. These		The SCHC fragmentation supports several modes of operation. These
	modes have different advantages and disadvantages depending on the		modes have different advantages and disadvantages, depending on the
	specifics of the underlying LPWAN technology and application Use		specifics of the underlying LPWAN technology and application use
	Case. This section describes how the SCHC fragmentation		case. This section describes how the SCHC fragmentation
	functionality should optimally be implemented when used over a Sigfox		functionality should optimally be implemented when used over a Sigfox
	LPWAN for the most typical Use Case applications.		LPWAN for the most typical use case applications.
	As described in section 8.2.3 of [RFC8724], the integrity of the		As described in Section 8.2.3 of [RFC8724], the integrity of the
	fragmentation-reassembly process of a SCHC Packet MUST be checked at		fragmentation-reassembly process of a SCHC Packet MUST be checked at
	the receiver end. Since only Uplink/Downlink messages/fragments that		the receiver end. Since only Uplink/Downlink messages/fragments that
	have passed the Sigfox CRC-check are delivered to the Network/Sigfox		have passed the Sigfox CRC-check are delivered to the Network/Sigfox
	Device SCHC C/D + F/R, integrity can be guaranteed when no		Device SCHC C/D + F/R, integrity can be guaranteed when no
	consecutive messages are missing from the sequence and all FCN		consecutive messages are missing from the sequence and all FCN
	bitmaps are complete. With this functionality in mind, and in order		bitmaps are complete. With this functionality in mind, and in order
	to save protocol and processing overhead, the use of a Reassembly		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.		Check Sequence (RCS), as described in Section 3.5.1.5, MUST be used.
	3.5.1. Uplink Fragmentation		3.5.1. Uplink Fragmentation
	Sigfox Uplink transmissions are completely asynchronous and take		Sigfox Uplink transmissions are completely asynchronous and take
	place in any random frequency of the allowed Uplink bandwidth		place in any random frequency of the allowed Uplink bandwidth
	allocation. In addition, devices may go to deep sleep mode, and then		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		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,		the Network, as there is no need to perform any Network attachment,
	synchronization, or other procedure before transmitting a data		synchronization, or other procedures before transmitting a data
	packet.		packet.
	Since Uplink transmissions are asynchronous, a SCHC fragment can be		Since Uplink transmissions are asynchronous, a SCHC Fragment can be
	transmitted at any given time by the Device. Sigfox Uplink messages		transmitted at any given time by the device. Sigfox Uplink messages
	are fixed in size, and as described in [RFC8376] they can carry 0-12		are fixed in size, and as described in [RFC8376], they can carry a
	bytes payload. Hence, a single SCHC Tile size per fragmentation mode		payload of 0-12 bytes (0-96 bits). Hence, a single SCHC Tile size,
	can be defined so that every Sigfox message always carries one SCHC		per fragmentation mode, can be defined so that every Sigfox message
	Tile.		always carries one SCHC Tile.
	When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC		When the ACK-on-Error mode is used for Uplink fragmentation, the SCHC
	Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]) MUST be		Compound ACK defined in [RFC9441] MUST be used in the Downlink
	used in the Downlink responses.		responses.
	3.5.1.1. SCHC Sender-Abort		3.5.1.1. SCHC Sender-Abort
	As defined in [RFC8724], a SCHC Sender-Abort can be triggered when		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		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-		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,		Abort MUST be sent if the number of repeated All-1s sent in sequence,
	without a Compound ACK reception inbetween, is greater than or equal		without a Compound ACK reception in between, is greater than or equal
	to MAX_ACK_REQUESTS.		to MAX_ACK_REQUESTS.
	3.5.1.2. SCHC Receiver-Abort		3.5.1.2. SCHC Receiver-Abort
	As defined in [RFC8724], a SCHC Receiver-Abort is triggered when the		As defined in [RFC8724], a SCHC Receiver-Abort is triggered when the
	receiver has no RuleID and DTag pairs available for a new session.		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,		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		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		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.		one is requested or if the RuleID of the fragment is not valid.
	A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer		A SCHC Receiver-Abort MUST be triggered when the Inactivity Timer
	expires.		expires.
	MAX_ACK_REQUESTS can be increased when facing high error rates.		MAX_ACK_REQUESTS can be increased when facing high error rates.
	Although a SCHC Receiver-Abort can be triggered at any point in time,		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		a SCHC Receiver-Abort Downlink message MUST only be sent when there
	is a Downlink transmission opportunity.		is a Downlink transmission opportunity.
	3.5.1.3. Single-byte SCHC Header for Uplink Fragmentation		3.5.1.3. Single-Byte SCHC Header for Uplink Fragmentation
	3.5.1.3.1. Uplink No-ACK Mode: Single-byte SCHC Header		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		Single-byte SCHC Header No-ACK mode MUST be used for transmitting
	short, non-critical packets that require fragmentation and do not		short, non-critical packets that require fragmentation and do not
	require full reliability. This mode can be used by Uplink-only		require full reliability. This mode can be used by Uplink-only
	devices that do not support Downlink communications, or by		devices that do not support Downlink communications or by
	bidirectional devices when they send non-critical data. Note that		bidirectional devices when they send non-critical data. Note that
	sending non-critical data by using a reliable fragmentation mode		sending non-critical data by using a reliable fragmentation mode
	(which is only possible for bidirectional devices) may incur		(which is only possible for bidirectional devices) may incur
	unnecessary overhead.		unnecessary overhead.
	Since there are no multiple windows in the No-ACK mode, the W bit is		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		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		of the data packet. In this sense, the data packet would need to be
	split into X fragments and, similarly to the other fragmentation		split into X fragments and, similarly to the other fragmentation
	modes, the first transmitted fragment would need to be marked with		modes, the first transmitted fragment would need to be marked with
	FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN		FCN = X-1. Consecutive fragments MUST be marked with decreasing FCN
	values, having the last fragment marked with FCN = (All-1). Hence,		values, having the last fragment marked with FCN = (All-1). Hence,
	even though the No-ACK mode does not allow recovering missing		even though the No-ACK mode does not allow recovering missing
	fragments, it allows indicating implicitly the size of the expected		fragments, it allows implicitly indicating the size of the expected
	packet to the Network and hence detect at the receiver side whether		packet to the Network and hence detects whether all fragments have
	all fragments have been received or not. In case the FCN field is		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		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		detect whether all fragments have been received or not by using the
	integrity check.		integrity check.
	When using the Single-byte SCHC Header for Uplink Fragmentation, the		When using the Single-byte SCHC Header for Uplink fragmentation, the
	Fragmentation Header MUST be of 8 bit size, and the Fragment header		fragmentation header MUST be 8 bits in size and is composed as
	is composed as follows:		follows:
	* RuleID size: 3 bits		* RuleID size: 3 bits
	* DTag size (T): 0 bit		* DTag size (T): 0 bits
	* Fragment Compressed Number (FCN) size (N): 5 bits		* Fragment Compressed Number (FCN) size (N): 5 bits
	Other F/R parameters MUST be configured as follows:		Other F/R parameters MUST be configured as follows:
	* As per [RFC8724], in the No-ACK mode the W (window) field is not		* As per [RFC8724], in the No-ACK mode, the W (window) field is not
	present.		present.
	* Regular tile size: 11 bytes		* Regular tile size: 11 bytes
	* All-1 tile size: 0 to 10 bytes		* All-1 tile size: 0 to 10 bytes
	* Inactivity Timer: Application-dependent. The default value is 12		* Inactivity Timer: Application-dependent. The default value is 12
	hours.		hours.
	* RCS size: 5 bits		* RCS size: 5 bits
	The maximum SCHC Packet size is 340 bytes.		The maximum SCHC Packet size is 340 bytes.
	Section 3.6.1 presents SCHC Fragment format examples and Section 5.1		Section 3.6.1 presents SCHC Fragment format examples, and Section 5.1
	provides fragmentation examples, using Single-byte SCHC Header No-ACK		provides fragmentation examples, using Single-byte SCHC Header No-ACK
	mode.		mode.
	3.5.1.3.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header		3.5.1.3.2. Uplink ACK-on-Error Mode: Single-Byte SCHC Header
	ACK-on-Error with single-byte header MUST be used for short to medium		ACK-on-Error with a single-byte header MUST be used for short- to
	size packets that need to be sent reliably. ACK-on-Error is optimal		medium-sized packets that need to be sent reliably. ACK-on-Error is
	for reliable SCHC Packet transmission over Sigfox transmissions,		optimal for reliable SCHC Packet transmission over Sigfox
	since it leads to a reduced number of ACKs in the lower capacity		transmissions, since it leads to a reduced number of ACKs in the
	Downlink channel. Also, Downlink messages can be sent asynchronously		lower-capacity Downlink channel. Also, Downlink messages can be sent
	and opportunistically. In contrast, ACK-Always would not minimize		asynchronously and opportunistically. In contrast, ACK-Always would
	the number of ACKs, and No-ACK would not allow reliable transmission.		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		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		Uplink fragmentation header size is 8 bits in size and is composed as
	follows:		follows:
	* RuleID size: 3 bits		* RuleID size: 3 bits
	* DTag size (T): 0 bit		* DTag size (T): 0 bits
	* Window index (W) size (M): 2 bits		* Window index (W) size (M): 2 bits
	* Fragment Compressed Number (FCN) size (N): 3 bits		* Fragment Compressed Number (FCN) size (N): 3 bits
	Other F/R parameters MUST be configured as follows:		Other F/R parameters MUST be configured as follows:
	* MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	* WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)		* WINDOW_SIZE: 7 (i.e., the maximum FCN value is 0b110)
	skipping to change at page 13, line 7 ¶		skipping to change at line 541 ¶
	* All-1 tile size: 0 to 10 bytes		* All-1 tile size: 0 to 10 bytes
	* Retransmission Timer: Application-dependent. The default value is		* Retransmission Timer: Application-dependent. The default value is
	12 hours.		12 hours.
	* Inactivity Timer: Application-dependent. The default value is 12		* Inactivity Timer: Application-dependent. The default value is 12
	hours.		hours.
	* RCS size: 3 bits		* RCS size: 3 bits
	Section 3.6.2 presents SCHC Fragment format examples and Section 5.2		Section 3.6.2 presents SCHC Fragment format examples, and Section 5.2
	provides fragmentation examples, using ACK-on-Error with single-byte		provides fragmentation examples, using ACK-on-Error with a single-
	header.		byte header.
	3.5.1.4. Two-byte SCHC Header for Uplink Fragmentation		3.5.1.4. Two-Byte SCHC Header for Uplink Fragmentation
	ACK-on-Error with two-byte header MUST be used for medium-large size		ACK-on-Error with a two-byte header MUST be used for medium- to
	packets that need to be sent reliably. ACK-on-Error is optimal for		large-sized packets that need to be sent reliably. ACK-on-Error is
	reliable SCHC Packet transmission over Sigfox, since it leads to a		optimal for reliable SCHC Packet transmission over Sigfox, since it
	reduced number of ACKs in the lower capacity Downlink channel. Also,		leads to a reduced number of ACKs in the lower-capacity Downlink
	Downlink messages can be sent asynchronously and opportunistically.		channel. Also, Downlink messages can be sent asynchronously and
	In contrast, ACK-Always would not minimize the number of ACKs, and		opportunistically. In contrast, ACK-Always would not minimize the
	No-ACK would not allow reliable transmission.		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		3.5.1.4.1. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1
	In order to allow transmission of medium-large packets/files up to		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		480 bytes long, the SCHC Uplink fragmentation header size is 16 bits
	in size and composed as follows:		in size and is composed as follows:
	* RuleID size is: 6 bits		* RuleID size: 6 bits
	* DTag size (T) is: 0 bit		* DTag size (T): 0 bits
	* Window index (W) size (M): 2 bits		* Window index (W) size (M): 2 bits
	* Fragment Compressed Number (FCN) size (N): 4 bits.		* Fragment Compressed Number (FCN) size (N): 4 bits
	* RCS size: 4 bits		* RCS size: 4 bits
	Other F/R parameters MUST be configured as follows:		Other F/R parameters MUST be configured as follows:
	* MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	* WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)		* WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)
	* Regular tile size: 10 bytes		* Regular tile size: 10 bytes
	* All-1 tile size: 1 to 10 bytes		* All-1 tile size: 1 to 10 bytes
	* Retransmission Timer: Application-dependent. The default value is		* Retransmission Timer: Application-dependent. The default value is
	12 hours.		12 hours.
	* Inactivity Timer: Application-dependent. The default value is 12		* Inactivity Timer: Application-dependent. The default value is 12
	hours.		hours.
	Note that WINDOW_SIZE is limited to 12. This because, 4 windows (M =		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		= 2) with bitmaps of size 12 can be fitted in a single SCHC Compound
	ACK.		ACK.
	Section 3.6.3 presents SCHC Fragment format examples, using ACK-on-		Section 3.6.3 presents SCHC Fragment format examples, using ACK-on-
	Error with two-byte header Option 1.		Error with two-byte header Option 1.
	3.5.1.4.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2		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		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		bytes long, the SCHC Uplink fragmentation header size is 16 bits in
	size and composed as follows:		size and is composed as follows:
	* RuleID size is: 8 bits		* RuleID size: 8 bits
	* DTag size (T) is: 0 bit		* DTag size (T): 0 bits
	* Window index (W) size (M): 3 bits		* Window index (W) size (M): 3 bits
	* Fragment Compressed Number (FCN) size (N): 5 bits.		* Fragment Compressed Number (FCN) size (N): 5 bits
	* RCS size: 5 bits		* RCS size: 5 bits
	Other F/R parameters MUST be configured as follows:		Other F/R parameters MUST be configured as follows:
	* MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)		* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	* Regular tile size: 10 bytes		* Regular tile size: 10 bytes
	* All-1 tile size: 0 to 9 bytes		* All-1 tile size: 0 to 9 bytes
	* Retransmission Timer: Application-dependent. The default value is		* Retransmission Timer: Application-dependent. The default value is
	12 hours.		12 hours.
	* Inactivity Timer: Application-dependent. The default value is 12		* Inactivity Timer: Application-dependent. The default value is 12
	hours.		hours.
	Section 3.6.4 presents SCHC Fragment format examples, using ACK-on-		Section 3.6.4 presents SCHC Fragment format examples, using ACK-on-
	Error with two-byte header Option 1.		Error with two-byte header Option 2.
	3.5.1.5. All-1 SCHC Fragment and RCS behaviour		3.5.1.5. All-1 SCHC Fragment and RCS Behavior
	For ACK-on-Error, as defined in [RFC8724], it is expected that the		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		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		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		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		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		receiver cannot determine from the FCN values alone whether there are
	or not any missing fragments right before the All-1 fragment.		or are not any missing fragments right before the All-1 fragment.
	For Rules where the number of fragments in the last window is		For Rules where the number of fragments in the last window is
	unknown, an RCS field MUST be used, indicating the number of		unknown, an RCS field MUST be used, indicating the number of
	fragments in the last window, including the All-1. With this RCS		fragments in the last window, including the All-1. With this RCS
	value, the receiver can detect if there are missing fragments before		value, the receiver can detect if there are missing fragments before
	the All-1 and hence construct the corresponding SCHC ACK Bitmap		the All-1 and hence construct the corresponding SCHC ACK Bitmap
	accordingly, and send it in response to the All-1.		accordingly and send it in response to the All-1.
	3.5.2. Downlink Fragmentation		3.5.2. Downlink Fragmentation
	In some LPWAN technologies, as part of energy-saving techniques,		In some LPWAN technologies, as part of energy-saving techniques,
	Downlink transmission is only possible immediately after an Uplink		Downlink transmission is only possible immediately after an Uplink
	transmission. This allows the device to go in a very deep sleep mode		transmission. This allows the device to go in a very deep sleep mode
	and preserve battery, without the need to listen to any information		and preserve battery without the need to listen to any information
	from the network. This is the case for Sigfox-enabled devices, which		from the Network. This is the case for Sigfox-enabled devices, which
	can only listen to Downlink communications after performing an Uplink		can only listen to Downlink communications after performing an Uplink
	transmission and requesting a Downlink.		transmission and requesting a Downlink.
	When there are fragments to be transmitted in the Downlink, an Uplink		When there are fragments to be transmitted in the Downlink, an Uplink
	message is required to trigger the Downlink communication. In order		message is required to trigger the Downlink communication. In order
	to avoid potentially high delay for fragmented datagram transmission		to avoid a potentially high delay for fragmented datagram
	in the Downlink, the fragment receiver MAY perform an Uplink		transmission in the Downlink, the fragment receiver MAY perform an
	transmission as soon as possible after reception of a Downlink		Uplink transmission as soon as possible after reception of a Downlink
	fragment that is not the last one. Such Uplink transmission MAY be		fragment that is not the last one. Such an Uplink transmission MAY
	triggered by sending a SCHC message, such as a SCHC ACK. However,		be triggered by sending a SCHC message, such as a SCHC ACK. However,
	other data messages can equally be used to trigger Downlink		other data messages can equally be used to trigger Downlink
	communications. The fragment receiver MUST send an Uplink		communications. The fragment receiver MUST send an Uplink
	transmission (e.g., empty message) and request a Downlink every 24		transmission (e.g., empty message) and request a Downlink every 24
	hours when no SCHC session is started. The use or not of this Uplink		hours when no SCHC session is started. Whether this Uplink
	transmission (and the transmission rate, if used) will depend on		transmission is used (and the transmission rate, if used) depends on
	application specific requirements.		application-specific requirements.
	Sigfox Downlink messages are fixed in size, and as described in		Sigfox Downlink messages are fixed in size, and as described in
	[RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC		[RFC8376] they can carry a payload of 0-8 bytes (0-64 bits). Hence,
	Tile size per mode can be defined so that every Sigfox message always		a single SCHC Tile size per mode can be defined so that every Sigfox
	carries one SCHC Tile.		message always carries one SCHC Tile.
	For reliable Downlink fragment transmission, the ACK-Always mode		For reliable Downlink fragment transmission, the ACK-Always mode
	SHOULD be used. Note that ACK-on-Error does not guarantee Uplink		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		feedback (since no SCHC ACK will be sent when no errors occur in a
	window), and No-ACK would not allow reliable transmission.		window), and No-ACK would not allow reliable transmission.
	The SCHC Downlink Fragmentation Header size is 8 bits in size and is		The SCHC Downlink fragmentation header size is 8 bits in size and is
	composed as follows:		composed as follows:
	* RuleID size: 3 bits		* RuleID size: 3 bits
	* DTag size (T): 0 bit		* DTag size (T): 0 bits
	* Window index (W) size (M) is: 0 bit		* Window index (W) size (M): 0 bits
	* Fragment Compressed Number (FCN) size (N): 5 bits		* Fragment Compressed Number (FCN) size (N): 5 bits
	Other F/R parameters MUST be configured as follows:		Other F/R parameters MUST be configured as follows:
	* MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)		* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	* Regular tile size: 7 bytes		* Regular tile size: 7 bytes
	skipping to change at page 16, line 42 ¶		skipping to change at line 712 ¶
	12 hours.		12 hours.
	* Inactivity Timer: Application-dependent. The default value is 12		* Inactivity Timer: Application-dependent. The default value is 12
	hours.		hours.
	* RCS size: 5 bits		* RCS size: 5 bits
	3.6. SCHC over Sigfox F/R Message Formats		3.6. SCHC over Sigfox F/R Message Formats
	This section depicts the different formats of SCHC Fragment, SCHC ACK		This section depicts the different formats of SCHC Fragment, SCHC ACK
	(including the SCHC Compound ACK defined in		(including the SCHC Compound ACK defined in [RFC9441]), and SCHC
	[I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over		Abort used in SCHC over Sigfox.
	Sigfox.
			3.6.1. Uplink No-ACK Mode: Single-Byte SCHC Header
	3.6.1. Uplink No-ACK Mode: Single-byte SCHC Header
	3.6.1.1. Regular SCHC Fragment		3.6.1.1. Regular SCHC Fragment
	Figure 3 shows an example of a regular SCHC fragment for all		Figure 3 shows an example of a Regular SCHC Fragment for all
	fragments except the last one. As tiles are of 11 bytes, padding		fragments except the last one. As tiles are 11 bytes in size,
	MUST NOT be added. The penultimate tile of a SCHC Packet is of		padding MUST NOT be added. The penultimate tile of a SCHC Packet is
	regular size.		of regular size.
	|- SCHC Fragment Header -|		|- SCHC Fragment Header -|
	+------------------------+---------+		+------------------------+---------+
	| RuleID | FCN | Payload |		| RuleID | FCN | Payload |
	+------------+-----------+---------+		+------------+-----------+---------+
	| 3 bits | 5 bits | 88 bits |		| 3 bits | 5 bits | 88 bits |
	Figure 3: Regular SCHC Fragment format for all fragments except		Figure 3: Regular SCHC Fragment Format for All Fragments except
	the last one		the Last One
	3.6.1.2. All-1 SCHC Fragment		3.6.1.2. All-1 SCHC Fragment
	Figure 4 shows an example of the All-1 message. The All-1 message		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		MAY contain the last tile of the SCHC Packet. Padding MUST NOT be
	added, as the resulting size is L2-word-multiple.		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		The All-1 messages Fragment Header includes a 5-bit RCS, and 3 bits
	are added as padding to complete two bytes. The payload size of the		are added as padding to complete 2 bytes. The payload size of the
	All-1 message ranges from 0 to 80 bits.		All-1 message ranges from 0 to 80 bits.
	|-------- SCHC Fragment Header -------|		|-------- SCHC Fragment Header -------|
	+--------------------------------------+--------------+		+--------------------------------------+--------------+
	| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |		| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
	+--------+-----------+--------+--------+--------------+		+--------+-----------+--------+--------+--------------+
	| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits |		| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 80 bits |
	Figure 4: All-1 SCHC Message format with last tile		Figure 4: All-1 SCHC Message Format with the Last Tile
	As per [RFC8724] the All-1 must be distinguishable from a SCHC		As per [RFC8724], the All-1 must be distinguishable from a SCHC
	Sender-Abort message (with same RuleID, and N values). The All-1 MAY		Sender-Abort message (with the same RuleID and N values). The All-1
	have the last tile of the SCHC Packet. The SCHC Sender-Abort message		MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort
	header size is 1 byte, with no padding bits.		message header size is 1 byte with no padding bits.
	For the All-1 message to be distinguishable from the Sender-Abort		For the All-1 message to be distinguishable from the Sender-Abort
	message, the Sender-Abort message MUST be of 1 byte (only header with		message, the Sender-Abort message MUST be 1 byte (only header with no
	no padding). This way, the minimum size of the All-1 is 2 bytes, and		padding). This way, the minimum size of the All-1 is 2 bytes, and
	the Sender-Abort message is 1 byte.		the Sender-Abort message is 1 byte.
	3.6.1.3. SCHC Sender-Abort Message format		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		Sender-Abort
			|------ Header ------|
			+--------------------+
			| RuleID | FCN=ALL-1 |
			+--------+-----------+
			| 3 bits | 5 bits |
	3.6.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header		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		3.6.2.1. Regular SCHC Fragment
	Figure 6 shows an example of a regular SCHC fragment for all		Figure 6 shows an example of a Regular SCHC Fragment for all
	fragments except the last one. As tiles are of 11 bytes, padding		fragments except the last one. As tiles are 11 bytes in size,
	MUST NOT be added.		padding MUST NOT be added.
	|-- SCHC Fragment Header --|		|-- SCHC Fragment Header --|
	+--------------------------+---------+		+--------------------------+---------+
	| RuleID | W | FCN | Payload |		| RuleID | W | FCN | Payload |
	+--------+--------+--------+---------+		+--------+--------+--------+---------+
	| 3 bits | 2 bits | 3 bits | 88 bits |		| 3 bits | 2 bits | 3 bits | 88 bits |
	Figure 6: Regular SCHC Fragment format for all fragments except		Figure 6: Regular SCHC Fragment Format for All Fragments except
	the last one		the Last One
	The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment		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).		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		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		ACK REQ (All-1 message). The penultimate tile of a SCHC Packet is of
	regular size.		regular size.
	3.6.2.2. All-1 SCHC Fragment		3.6.2.2. All-1 SCHC Fragment
	Figure 7 shows an example of the All-1 message. The All-1 message		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		MAY contain the last tile of the SCHC Packet. Padding MUST NOT be
	added, as the resulting size is L2-word-multiple.		added, as the resulting size is L2-word-multiple.
	|------------- SCHC Fragment Header -----------|		|------------- SCHC Fragment Header -----------|
	+-----------------------------------------------+--------------+		+-----------------------------------------------+--------------+
	| RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload |		| RuleID | W | FCN=ALL-1 | RCS |b'00000 | Payload |
	+--------+--------+-----------+--------+--------+--------------+		+--------+--------+-----------+--------+--------+--------------+
	| 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits |		| 3 bits | 2 bits | 3 bits | 3 bits | 5 bits | 0 to 80 bits |
	Figure 7: All-1 SCHC Message format with last tile		Figure 7: All-1 SCHC Message Format with the Last Tile
	As per [RFC8724] the All-1 must be distinguishable from a SCHC		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		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		MAY have the last tile of the SCHC Packet. The SCHC Sender-Abort
	message header size is 1 byte, with no padding bits.		message header size is 1 byte with no padding bits.
	For the All-1 message to be distinguishable from the Sender-Abort		For the All-1 message to be distinguishable from the Sender-Abort
	message, the Sender-Abort message MUST be of 1 byte (only header with		message, the Sender-Abort message MUST be 1 byte (only header with no
	no padding). This way, the minimum size of the All-1 is 2 bytes, and		padding). This way, the minimum size of the All-1 is 2 bytes, and
	the Sender-Abort message is 1 byte.		the Sender-Abort message is 1 byte.
	3.6.2.3. SCHC ACK Format		3.6.2.3. SCHC ACK Format
	Figure 8 shows the SCHC ACK format when all fragments have been		Figure 8 shows the SCHC ACK format when all fragments have been
	correctly received (C=1). Padding MUST be added to complete the		correctly received (C=1). Padding MUST be added to complete the
	64-bit Sigfox Downlink frame payload size.		64-bit Sigfox Downlink frame payload size.
	|---- SCHC ACK Header ----|		|---- SCHC ACK Header ----|
	+-------------------------+---------+		+-------------------------+---------+
	| RuleID | W | C=b'1 | b'0-pad |		| RuleID | W | C=b'1 | b'0-pad |
	+--------+--------+-------+---------+		+--------+--------+-------+---------+
	| 3 bits | 2 bits | 1 bit | 58 bits |		| 3 bits | 2 bits | 1 bit | 58 bits |
	Figure 8: SCHC Success ACK message format		Figure 8: SCHC Success ACK Message Format
	In case SCHC fragment losses are found in any of the windows of the		In case SCHC Fragment losses are found in any of the windows of the
	SCHC Packet (C=0), the SCHC Compound ACK defined in		SCHC Packet (C=0), the SCHC Compound ACK defined in [RFC9441] MUST be
	[I-D.ietf-lpwan-schc-compound-ack] MUST be used. The SCHC Compound		used. The SCHC Compound ACK message format is shown in Figure 9.
	ACK message format is shown in Figure 9.
	|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|		|--- SCHC ACK Header ---|- W=w1 -|...|----- W=wi ------|
	+------+--------+-------+--------+...+--------+--------+------+-------+		+------+--------+-------+--------+...+--------+--------+------+-------+
	|RuleID| W=b'w1 | C=b'0 | Bitmap |...| W=b'wi | Bitmap | b'00 |b'0-pad|		|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|		|3 bits| 2 bits | 1 bit | 7 bits |...| 2 bits | 7 bits |2 bits|
	Losses are found in windows W = w1,...,wi; where w1<w2<...<wi		Figure 9: SCHC Compound ACK Message Format
	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		3.6.2.4. SCHC Sender-Abort Message Format
	|---- Sender-Abort Header ----|		|---- Sender-Abort Header ----|
	+-----------------------------+		+-----------------------------+
	| RuleID | W=b'11 | FCN=ALL-1 |		| RuleID | W=b'11 | FCN=ALL-1 |
	+--------+--------+-----------+		+--------+--------+-----------+
	| 3 bits | 2 bits | 3 bits |		| 3 bits | 2 bits | 3 bits |
	Figure 10: SCHC Sender-Abort message format		Figure 10: SCHC Sender-Abort Message Format
	3.6.2.5. SCHC Receiver-Abort Message format		3.6.2.5. SCHC Receiver-Abort Message Format
	|- Receiver-Abort Header -|		|- Receiver-Abort Header -|
	+---------------------------------+-----------------+---------+		+---------------------------------+-----------------+---------+
	| RuleID | W=b'11 | C=b'1 | b'11 | 0xFF (all 1's) | b'0-pad |		| 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 |		| 3 bits | 2 bits | 1 bit | 2 bit | 8 bit | 48 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 11: SCHC Receiver-Abort message format		Figure 11: SCHC Receiver-Abort Message Format
	3.6.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1		3.6.3. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 1
	3.6.3.1. Regular SCHC Fragment		3.6.3.1. Regular SCHC Fragment
	Figure 12 shows an example of a regular SCHC fragment for all		Figure 12 shows an example of a Regular SCHC Fragment for all
	fragments except the last one. The penultimate tile of a SCHC Packet		fragments except the last one. The penultimate tile of a SCHC Packet
	is of the regular size.		is of the regular size.
	|------- SCHC Fragment Header ------|		|------- SCHC Fragment Header ------|
	+-----------------------------------+---------+		+-----------------------------------+---------+
	| RuleID | W | FCN | b'0000 | Payload |		| RuleID | W | FCN | b'0000 | Payload |
	+--------+--------+--------+--------+---------+		+--------+--------+--------+--------+---------+
	| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |		| 6 bits | 2 bits | 4 bits | 4 bits | 80 bits |
	Figure 12: Regular SCHC Fragment format for all fragments except		Figure 12: Regular SCHC Fragment Format for All Fragments except
	the last one		the Last One
	The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment		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).		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		As per [RFC8724], the All-0 message is distinguishable from the SCHC
	ACK REQ (All-1 message).		ACK REQ (All-1 message).
	3.6.3.2. All-1 SCHC Fragment		3.6.3.2. All-1 SCHC Fragment
	Figure 13 shows an example of the All-1 message. The All-1 message		Figure 13 shows an example of the All-1 message. The All-1 message
	MUST contain the last tile of the SCHC Packet.		MUST contain the last tile of the SCHC Packet.
	The All-1 message Fragment Header contains an RCS of 4 bits to		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		complete the two-byte size. The size of the last tile ranges from 8
	to 80 bits.		to 80 bits.
	|--------- SCHC Fragment Header -------|		|--------- SCHC Fragment Header -------|
	+--------------------------------------+--------------+		+--------------------------------------+--------------+
	| RuleID | W | FCN=ALL-1 | RCS | Payload |		| RuleID | W | FCN=ALL-1 | RCS | Payload |
	+--------+--------+-----------+--------+--------------+		+--------+--------+-----------+--------+--------------+
	| 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits |		| 6 bits | 2 bits | 4 bits | 4 bits | 8 to 80 bits |
	Figure 13: All-1 SCHC message format with last tile
	As per [RFC8724] the All-1 must be distinguishable from the SCHC		Figure 13: All-1 SCHC Message Format with the Last Tile
	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 of at least		As per [RFC8724], the All-1 must be distinguishable from the SCHC
	1 byte. The SCHC Sender-Abort message header size is 2 byte, with no		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.		padding bits.
	For the All-1 message to be distinguishable from the Sender-Abort		For the All-1 message to be distinguishable from the Sender-Abort
	message, the Sender-Abort message MUST be of 2 byte (only header with		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		no padding). This way, the minimum size of the All-1 is 3 bytes, and
	the Sender-Abort message is 2 bytes.		the Sender-Abort message is 2 bytes.
	3.6.3.3. SCHC ACK Format		3.6.3.3. SCHC ACK Format
	Figure 14 shows the SCHC ACK format when all fragments have been		Figure 14 shows the SCHC ACK format when all fragments have been
	correctly received (C=1). Padding MUST be added to complete the		correctly received (C=1). Padding MUST be added to complete the
	64-bit Sigfox Downlink frame payload size.		64-bit Sigfox Downlink frame payload size.
	|---- SCHC ACK Header ----|		|---- SCHC ACK Header ----|
	+-------------------------+---------+		+-------------------------+---------+
	| RuleID | W | C=b'1 | b'0-pad |		| RuleID | W | C=b'1 | b'0-pad |
	+--------+--------+-------+---------+		+--------+--------+-------+---------+
	| 6 bits | 2 bits | 1 bit | 55 bits |		| 6 bits | 2 bits | 1 bit | 55 bits |
	Figure 14: SCHC Success ACK message format		Figure 14: SCHC Success ACK Message Format
	The SCHC Compound ACK message MUST be used in case SCHC fragment		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		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		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.		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		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		(padding bits must be 0) to complement the 64 bits required by the
	Sigfox payload.		Sigfox payload.
	|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|		|--- SCHC ACK Header ---|- W=w1 -|...|---- W=wi -----|
	+--------+------+-------+--------+...+------+--------+------+-------+		+--------+------+-------+--------+...+------+--------+------+-------+
	| RuleID |W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | b'00 |b'0-pad|		| 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|		| 6 bits |2 bits| 1 bit | 12 bits|...|2 bits| 12 bits|2 bits|
	Losses are found in windows W = w1,...,wi; where w1<w2<...<wi		Figure 15: SCHC Compound ACK Message Format
	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 -|...		|- SCHC ACK Header -|- W=0 -| |- W=1 -|...
	+------+------+-----+-------+------+-------+...		+------+------+-----+-------+------+-------+...
	|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...		|RuleID|W=b'00|C=b'0|Bitmap |W=b'01|Bitmap |...
	+------+------+-----+-------+------+-------+...		+------+------+-----+-------+------+-------+...
	|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...		|6 bits|2 bits|1 bit|12 bits|2 bits|12 bits|...
	... |- W=2 -| |- W=3 -|		... |- W=2 -| |- W=3 -|
	...+------+-------+------+-------+---+		...+------+-------+------+-------+---+
	...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|		...|W=b'10|Bitmap |W=b'11|Bitmap |b'0|
	...+------+-------+------+-------+---+		...+------+-------+------+-------+---+
	...|2 bits|12 bits|2 bits|12 bits|		...|2 bits|12 bits|2 bits|12 bits|
	Losses are found in windows W = w1,...,wi; where w1<w2<...<wi		Figure 16: SCHC Compound ACK Message Format Example with Losses
			in All Windows
	Figure 16: SCHC Compound ACK message format example with losses		Losses are found in windows W = w1,...,wi, where w1 < w2 <...< wi.
	in all windows
	3.6.3.4. SCHC Sender-Abort Message Format		3.6.3.4. SCHC Sender-Abort Message Format
	|---- Sender-Abort Header ----|		|---- Sender-Abort Header ----|
	+-----------------------------+		+-----------------------------+
	| RuleID | W | FCN=ALL-1 |		| RuleID | W | FCN=ALL-1 |
	+--------+--------+-----------+		+--------+--------+-----------+
	| 6 bits | 2 bits | 4 bits |		| 6 bits | 2 bits | 4 bits |
	Figure 17: SCHC Sender-Abort message format		Figure 17: SCHC Sender-Abort Message Format
	3.6.3.5. SCHC Receiver-Abort Message Format		3.6.3.5. SCHC Receiver-Abort Message Format
	|- Receiver-Abort Header -|		|- Receiver-Abort Header -|
	+---------------------------------+-----------------+---------+		+---------------------------------+-----------------+---------+
	| RuleID | W=b'11 | C=b'1 | 0x7F | 0xFF (all 1's) | b'0-pad |		| 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 |		| 6 bits | 2 bits | 1 bit | 7 bit | 8 bit | 40 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 18: SCHC Receiver-Abort message format		Figure 18: SCHC Receiver-Abort Message Format
	3.6.4. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2		3.6.4. Uplink ACK-on-Error Mode: Two-Byte SCHC Header Option 2
	3.6.4.1. Regular SCHC Fragment		3.6.4.1. Regular SCHC Fragment
	Figure 19 shows an example of a regular SCHC fragment for all		Figure 19 shows an example of a Regular SCHC Fragment for all
	fragments except the last one. The penultimate tile of a SCHC Packet		fragments except the last one. The penultimate tile of a SCHC Packet
	is of the regular size.		is of the regular size.
	|-- SCHC Fragment Header --|		|-- SCHC Fragment Header --|
	+--------------------------+---------+		+--------------------------+---------+
	| RuleID | W | FCN | Payload |		| RuleID | W | FCN | Payload |
	+--------+--------+--------+---------+		+--------+--------+--------+---------+
	| 8 bits | 3 bits | 5 bits | 80 bits |		| 8 bits | 3 bits | 5 bits | 80 bits |
	Figure 19: Regular SCHC Fragment format for all fragments except		Figure 19: Regular SCHC Fragment Format for All Fragments except
	the last one		the Last One
	The SCHC ACK REQ MUST NOT be used, instead the All-1 SCHC Fragment		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).		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		As per [RFC8724], the All-0 message is distinguishable from the SCHC
	ACK REQ (All-1 message).		ACK REQ (All-1 message).
	3.6.4.2. All-1 SCHC Fragment		3.6.4.2. All-1 SCHC Fragment
	Figure 20 shows an example of the All-1 message. The All-1 message		Figure 20 shows an example of the All-1 message. The All-1 message
	MAY contain the last tile of the SCHC Packet.		MAY contain the last tile of the SCHC Packet.
	The All-1 message Fragment Header contains an RCS of 5 bits, and 3		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		padding bits to complete a 3-byte Fragment Header. The size of the
	last tile, if present, ranges from 8 to 72 bits.		last tile, if present, ranges from 8 to 72 bits.
	|-------------- SCHC Fragment Header -----------|		|-------------- SCHC Fragment Header -----------|
	+-----------------------------------------------+--------------+		+-----------------------------------------------+--------------+
	| RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload |		| RuleID | W | FCN=ALL-1 | RCS | b'000 | Payload |
	+--------+--------+-----------+--------+--------+--------------+		+--------+--------+-----------+--------+--------+--------------+
	| 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits |		| 8 bits | 3 bits | 5 bits | 5 bits | 3 bits | 8 to 72 bits |
	Figure 20: All-1 SCHC message format with last tile		Figure 20: All-1 SCHC Message Format with the Last Tile
	As per [RFC8724] the All-1 must be distinguishable from the SCHC		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 (with same RuleID, M, and N values). The SCHC
	Sender-Abort message header size is 2 byte, with no padding bits.		Sender-Abort message header size is 2 bytes with no padding bits.
	For the All-1 message to be distinguishable from the Sender-Abort		For the All-1 message to be distinguishable from the Sender-Abort
	message, the Sender-Abort message MUST be of 2 byte (only header with		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		no padding). This way, the minimum size of the All-1 is 3 bytes, and
	the Sender-Abort message is 2 bytes.		the Sender-Abort message is 2 bytes.
	3.6.4.3. SCHC ACK Format		3.6.4.3. SCHC ACK Format
	Figure 21 shows the SCHC ACK format when all fragments have been		Figure 21 shows the SCHC ACK format when all fragments have been
	correctly received (C=1). Padding MUST be added to complete the		correctly received (C=1). Padding MUST be added to complete the
	64-bit Sigfox Downlink frame payload size.		64-bit Sigfox Downlink frame payload size.
	|---- SCHC ACK Header ----|		|---- SCHC ACK Header ----|
	+-------------------------+---------+		+-------------------------+---------+
	| RuleID | W | C=b'1 | b'0-pad |		| RuleID | W | C=b'1 | b'0-pad |
	+--------+--------+-------+---------+		+--------+--------+-------+---------+
	| 8 bits | 3 bits | 1 bit | 52 bits |		| 8 bits | 3 bits | 1 bit | 52 bits |
	Figure 21: SCHC Success ACK message format		Figure 21: SCHC Success ACK Message Format
	The SCHC Compound ACK message MUST be used in case SCHC fragment		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		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		Compound ACK message format is shown in Figure 22. The SCHC Compound
	ACK can report up to 3 windows with losses.		ACK can report up to 3 windows with losses.
	When sent in the Downlink, the SCHC Compound ACK MUST be 0 padded		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		(padding bits must be 0) to complement the 64 bits required by the
	Sigfox payload.		Sigfox payload.
	|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|		|-- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
	+------+------+-------+--------+...+------+--------+------+-------+		+------+------+-------+--------+...+------+--------+------+-------+
	|RuleID|W=b'w1| C=b'0 | Bitmap |...|W=b'wi| Bitmap | 000 |b'0-pad|		|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|		|8 bits|3 bits| 1 bit | 31 bits|...|3 bits| 31 bits|3 bits|
	Losses are found in windows W = w1,...,wi; where w1<w2<...<wi		Figure 22: SCHC Compound ACK Message Format
	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		3.6.4.4. SCHC Sender-Abort Message Format
	|---- Sender-Abort Header ----|		|---- Sender-Abort Header ----|
	+-----------------------------+		+-----------------------------+
	| RuleID | W | FCN=ALL-1 |		| RuleID | W | FCN=ALL-1 |
	+--------+--------+-----------+		+--------+--------+-----------+
	| 8 bits | 3 bits | 5 bits |		| 8 bits | 3 bits | 5 bits |
	Figure 23: SCHC Sender-Abort message format		Figure 23: SCHC Sender-Abort Message Format
	3.6.4.5. SCHC Receiver-Abort Message Format		3.6.4.5. SCHC Receiver-Abort Message Format
	|-- Receiver-Abort Header -|		|-- Receiver-Abort Header -|
	+-----------------------------------+-----------------+---------+		+-----------------------------------+-----------------+---------+
	| RuleID | W=b'111 | C=b'1 | b'1111 | 0xFF (all 1's) | b'0-pad |		| 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 |		| 8 bits | 3 bits | 1 bit | 4 bit | 8 bit | 40 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 24: SCHC Receiver-Abort message format		Figure 24: SCHC Receiver-Abort Message Format
	3.6.5. Downlink ACK-Always Mode: Single-byte SCHC Header		3.6.5. Downlink ACK-Always Mode: Single-Byte SCHC Header
	3.6.5.1. Regular SCHC Fragment		3.6.5.1. Regular SCHC Fragment
	Figure 25 shows an example of a regular SCHC fragment for all		Figure 25 shows an example of a Regular SCHC Fragment for all
	fragments except the last one. The penultimate tile of a SCHC Packet		fragments except the last one. The penultimate tile of a SCHC Packet
	is of the regular size.		is of the regular size.
	SCHC Fragment		SCHC Fragment
	|-- Header --|		|-- Header --|
	+-----------------+---------+		+-----------------+---------+
	| RuleID | FCN | Payload |		| RuleID | FCN | Payload |
	+--------+--------+---------+		+--------+--------+---------+
	| 3 bits | 5 bits | 56 bits |		| 3 bits | 5 bits | 56 bits |
	Figure 25: Regular SCHC Fragment format for all fragments except		Figure 25: Regular SCHC Fragment Format for All Fragments except
	the last one		the Last One
	The SCHC ACK MUST NOT be used, instead the All-1 SCHC Fragment MUST		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],		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		the All-0 message is distinguishable from the SCHC ACK REQ (All-1
	message).		message).
	3.6.5.2. All-1 SCHC Fragment		3.6.5.2. All-1 SCHC Fragment
	Figure 26 shows an example of the All-1 message. The All-1 message		Figure 26 shows an example of the All-1 message. The All-1 message
	MAY contain the last tile of the SCHC Packet.		MAY contain the last tile of the SCHC Packet.
	The All-1 message Fragment Header contains an RCS of 5 bits, and 3		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		padding bits to complete a 2-byte Fragment Header. The size of the
	last tile, if present, ranges from 8 to 48 bits.		last tile, if present, ranges from 8 to 48 bits.
	|--------- SCHC Fragment Header -------|		|--------- SCHC Fragment Header -------|
	+--------------------------------------+--------------+		+--------------------------------------+--------------+
	| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |		| RuleID | FCN=ALL-1 | RCS | b'000 | Payload |
	+--------+-----------+--------+--------+--------------+		+--------+-----------+--------+--------+--------------+
	| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits |		| 3 bits | 5 bits | 5 bits | 3 bits | 0 to 48 bits |
	Figure 26: All-1 SCHC message format with last tile		Figure 26: All-1 SCHC Message Format with the Last Tile
	As per [RFC8724] the All-1 must be distinguishable from the SCHC		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 (with same RuleID and N values). The SCHC
	Sender-Abort message header size is 1 byte, with no padding bits.		Sender-Abort message header size is 1 byte with no padding bits.
	For the All-1 message to be distinguishable from the Sender-Abort		For the All-1 message to be distinguishable from the Sender-Abort
	message, the Sender-Abort message MUST be of 1 byte (only header with		message, the Sender-Abort message MUST be 1 byte (only header with no
	no padding). This way, the minimum size of the All-1 is 2 bytes, and		padding). This way, the minimum size of the All-1 is 2 bytes, and
	the Sender-Abort message is 1 bytes.		the Sender-Abort message is 1 bytes.
	3.6.5.3. SCHC ACK Format		3.6.5.3. SCHC ACK Format
	Figure 27 shows the SCHC ACK format when all fragments have been		Figure 27 shows the SCHC ACK format when all fragments have been
	correctly received (C=1). Padding MUST be added to complete 2 bytes.		correctly received (C=1). Padding MUST be added to complete 2 bytes.
	SCHC ACK		SCHC ACK
	|-- Header --|		|-- Header --|
	+----------------+---------+		+----------------+---------+
	| RuleID | C=b'1 | b'0-pad |		| RuleID | C=b'1 | b'0-pad |
	+--------+-------+---------+		+--------+-------+---------+
	| 3 bits | 1 bit | 4 bits |		| 3 bits | 1 bit | 4 bits |
	Figure 27: SCHC Success ACK message format		Figure 27: SCHC Success ACK Message Format
	The SCHC ACK message format is shown in Figure 28.		The SCHC ACK message format is shown in Figure 28.
	|---- SCHC ACK Header ----|		|---- SCHC ACK Header ----|
	+--------+-------+--------+---------+		+--------+-------+--------+---------+
	| RuleID | C=b'0 | Bitmap | b'0-pad |		| RuleID | C=b'0 | Bitmap | b'0-pad |
	+--------+-------+--------+---------+		+--------+-------+--------+---------+
	| 3 bits | 1 bit | 31 bits| 5 bits |		| 3 bits | 1 bit | 31 bits| 5 bits |
	Figure 28: SCHC Compound ACK message format		Figure 28: SCHC Compound ACK Message Format
	3.6.5.4. SCHC Sender-Abort Message Format		3.6.5.4. SCHC Sender-Abort Message Format
	Sender-Abort		Sender-Abort
	|---- Header ----|		|---- Header ----|
	+--------------------+		+--------------------+
	| RuleID | FCN=ALL-1 |		| RuleID | FCN=ALL-1 |
	+--------+-----------+		+--------+-----------+
	| 3 bits | 5 bits |		| 3 bits | 5 bits |
	Figure 29: SCHC Sender-Abort message format		Figure 29: SCHC Sender-Abort Message Format
	3.6.5.5. SCHC Receiver-Abort Message Format		3.6.5.5. SCHC Receiver-Abort Message Format
	Receiver-Abort		Receiver-Abort
	|--- Header ---|		|--- Header ---|
	+----------------+--------+-----------------+		+----------------+--------+-----------------+
	| RuleID | C=b'1 | b'1111 | 0xFF (all 1's) |		| RuleID | C=b'1 | b'1111 | 0xFF (all 1's) |
	+--------+-------+--------+-----------------+		+--------+-------+--------+-----------------+
	| 3 bits | 1 bit | 4 bit | 8 bit |		| 3 bits | 1 bit | 4 bit | 8 bit |
	Figure 30: SCHC Receiver-Abort message format		Figure 30: SCHC Receiver-Abort Message Format
	3.7. Padding		3.7. Padding
	The Sigfox payload fields have different characteristics in Uplink		The Sigfox payload fields have different characteristics in Uplink
	and Downlink.		and Downlink.
	Uplink messages can contain a payload size from 0 to 12 bytes. The		Uplink messages can contain a payload size from 0 to 12 bytes. The
	Sigfox radio protocol allows sending zero bits, one single bit of		Sigfox radio protocol allows sending zero bits, one single bit of
	information for binary applications (e.g., status), or an integer		information for binary applications (e.g., status), or an integer
	number of bytes. Therefore, for 2 or more bits of payload it is		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		required to add padding to the next integer number of bytes. The
	reason for this flexibility is to optimize transmission time and		reason for this flexibility is to optimize transmission time and
	hence save battery consumption at the device.		hence save battery consumption at the device.
	Downlink frames on the other hand have a fixed length. The payload		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		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		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		0. The receiver MUST remove the added padding bits before the SCHC
	reassembly process.		reassembly process.
	4. Fragmentation Rules Examples		4. Fragmentation Rules Examples
	This section provides an example of RuleIDs configuration for		This section provides an example of RuleID configuration for
	interoperability between the F/R modes presented in this document.		interoperability between the F/R modes presented in this document.
	Note that the RuleID space for Uplink F/R is different than the one		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		for Downlink F/R; therefore, this section is divided in two
	subsections: Rules for Uplink fragmentation and Rules for Downlink		subsections: Rules for Uplink fragmentation and Rules for Downlink
	fragmentation.		fragmentation.
	For Uplink F/R, multiple header length were described in Section 3.5.		For Uplink F/R, multiple header lengths were described in
	All of them are part of the SCHC over Sigfox Profile, and offer not		Section 3.5. All of them are part of the SCHC over Sigfox Profile
	only low protocol overhead for small payloads (single byte header)		and offer not only low protocol overhead for small payloads (single
	but also extensibility to transport larger payloads with more		byte header) but also extensibility to transport larger payloads with
	overhead (2 bytes header, option 1 and 2). The usage of the RuleID		more overhead (2-byte header, Options 1 and 2). The usage of the
	space for each header length is an implementation choice, but we		RuleID space for each header length is an implementation choice, but
	provide an example of it in the following section. This illustrates		we provide an example of it in the following section. This
	implementation choices made in order to 1) identify the different		illustrates implementation choices made in order to 1) identify the
	header length, and 2) finally parse the RuleID field to identify the		different header length and 2) finally parse the RuleID field to
	RuleID value and execute the associated treatment.		identify the RuleID value and execute the associated treatment.
	4.1. Uplink Fragmentation Rules Examples		4.1. Uplink Fragmentation Rules Examples
	The RuleID field for Uplink F/R modes have different sizes depending		The RuleID field for Uplink F/R modes has different sizes depending
	on the header length. In order to identify the header length and		on the header length. In order to identify the header length and
	then the value of the RuleID, the RuleID field is interpreted as		then the value of the RuleID, the RuleID field is interpreted as
	follows:		follows:
	* The RuleID field is the first one to be parsed in the SCHC header,		* The RuleID field is the first one to be parsed in the SCHC header,
	starting from the leftmost bits.		starting from the leftmost bits.
	* For Single-byte SCHC Header F/R modes, it is expected a RuleID		* For Single-byte SCHC Header F/R modes, a RuleID field of 3 bits is
	field of 3 bits:		expected:
	- if the first 3 leftmost bits have a value different than		- If the first 3 leftmost bits have a value different than
	0b'111, then it signals a Single-byte SCHC Header F/R mode,		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		- If their value is 0b'111, then it signals a Two-byte SCHC
	Header F/R mode.		Header F/R mode.
	* For Single-byte SCHC Header F/R modes:		* For Single-byte SCHC Header F/R modes:
	- there are 7 RuleIDs available (with values from 0b'000-0b'110),		- 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		the RuleID with value 0b'111 is reserved to indicate a Two-byte
	SCHC Header.		SCHC Header.
	- This set of rules is called "standard rules", and it is used to		- This set of Rules is called "standard rules", and it is used to
	implement Single-byte SCHC header modes.		implement Single-byte SCHC Header modes.
	- Each RuleID is associated with a set of properties defining if		- 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		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:		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		Single-byte SCHC Header, and the RuleIDs 0b'001 and 0b'002 are
	mapped onto Uplink ACK-on-Error Mode: Single-byte SCHC Header		mapped onto Uplink ACK-on-Error mode: Single-byte SCHC Header
	(2 RuleIDs to allow for SCHC Packet interleaving).		(2 RuleIDs to allow for SCHC Packet interleaving).
	* For Two-byte SCHC Header F/R modes at least 6 bits for the RuleID		* For Two-byte SCHC Header F/R modes, at least 6 bits for the RuleID
	field are expected:		field are expected:
	- the 3 first leftmost bits are always 0b'111,		- The 3 first leftmost bits are always 0b'111.
	o if the following 3 bits have a different value than 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,		then it signals the Two-byte SCHC Header Option 1.
	o if the following 3 bits are 0b'111, then it signals the Two-		o If the following 3 bits are 0b'111, then it signals the Two-
	byte SCHC Header Option 2.		byte SCHC Header Option 2.
	- For the Two-byte SCHC Header Option 1, there are 7 RuleIDs		- For the Two-byte SCHC Header Option 1, there are 7 RuleIDs
	available (0b'111000-0b'111110), 0b'111111 being reserved to		available (0b'111000-0b'111110), 0b'111111 being reserved to
	indicate the Two-byte SCHC Header Option 2. This set of rules		indicate the Two-byte SCHC Header Option 2. This set of Rules
	is called "extended rules", and it is used to implement the		is called "extended rules", and it is used to implement the
	Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1.		Uplink ACK-on-Error mode: Two-byte SCHC Header Option 1.
	- For the Two-byte SCHC Header Option 2, there are 2 additional		- For the Two-byte SCHC Header Option 2, there are 2 additional
	bits to parse as the RuleID, so 4 RuleIDs available		bits to parse as the RuleID, so 4 RuleIDs are available
	(0b'11111100-0b'11111111). This set of rules is used to cover		(0b'11111100-0b'11111111). This set of Rules is used to cover
	specific cases that previous RuleIDs do not cover. As an		specific cases that previous RuleIDs do not cover. As an
	example, RuleID 0b'00111111 is used to transport uncompressed		example, RuleID 0b'00111111 is used to transport uncompressed
	IPv6 packets using the Uplink ACK-on-Error Mode: Two-byte SCHC		IPv6 packets using the Uplink ACK-on-Error mode: Two-byte SCHC
	Header Option 2.		Header Option 2.
	4.2. Downlink Fragmentation Rules Example		4.2. Downlink Fragmentation Rules Example
	* For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs		For the Downlink ACK-Always Mode: Single-byte SCHC Header, RuleIDs
	can get values in ranges from 0b'000 to 0b'111.		can get values in ranges from 0b'000 to 0b'111.
	5. Fragmentation Sequence Examples		5. Fragmentation Sequence Examples
	In this section, some sequence diagrams depicting messages exchanges		In this section, some sequence diagrams depict message exchanges for
	for different fragmentation modes and use cases are shown. In the		different fragmentation modes and use cases are shown. In the
	examples, 'Seq' indicates the Sigfox Sequence Number of the frame		examples, 'Seq' indicates the Sigfox Sequence Number of the frame
	carrying a fragment.		carrying a fragment.
	5.1. Uplink No-ACK Examples		5.1. Uplink No-ACK Examples
	The FCN field indicates the size of the data packet. The first		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		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		the message is split into. All fragments are marked with decreasing
	FCN values. Last packet fragment is marked with the FCN = All-1		FCN values. The last packet fragment is marked with FCN = All-1
	(1111).		(1111).
	Case No losses - All fragments are sent and received successfully.		*Case No Losses - All fragments are sent and received successfully.*
	Sender Receiver		Sender Receiver
	|-------FCN=6,Seq=1-------->|		|-------FCN=6,Seq=1-------->|
	|-------FCN=5,Seq=2-------->|		|-------FCN=5,Seq=2-------->|
	|-------FCN=4,Seq=3-------->|		|-------FCN=4,Seq=3-------->|
	|-------FCN=3,Seq=4-------->|		|-------FCN=3,Seq=4-------->|
	|-------FCN=2,Seq=5-------->|		|-------FCN=2,Seq=5-------->|
	|-------FCN=1,Seq=6-------->|		|-------FCN=1,Seq=6-------->|
	|-------FCN=15,Seq=7------->| All fragments received		|-------FCN=15,Seq=7------->| All fragments received
	(End)		(End)
	Figure 31: Uplink No-ACK No-Losses		Figure 31: Uplink No-ACK No-Losses
	When the first SCHC fragment is received, the Receiver can calculate		When the first SCHC Fragment is received, the receiver can calculate
	the total number of SCHC fragments that the SCHC Packet is composed		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		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		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).		from 5 downwards and the last fragment with an FCN equal to 15).
	Case losses on any fragment except the first.		*Case Losses on Any Fragment except the First*
	Sender Receiver		Sender Receiver
	|-------FCN=6,Seq=1-------->|		|-------FCN=6,Seq=1-------->|
	|-------FCN=5,Seq=2----X |		|-------FCN=5,Seq=2----X |
	|-------FCN=4,Seq=3-------->|		|-------FCN=4,Seq=3-------->|
	|-------FCN=3,Seq=4-------->|		|-------FCN=3,Seq=4-------->|
	|-------FCN=2,Seq=5-------->|		|-------FCN=2,Seq=5-------->|
	|-------FCN=1,Seq=6-------->|		|-------FCN=1,Seq=6-------->|
	|-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble		|-------FCN=15,Seq=7------->| Missing Fragment Unable to reassemble
	(End)		(End)
	Figure 32: Uplink No-ACK Losses (scenario 1)		Figure 32: Uplink No-ACK Losses (Scenario 1)
	5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header		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		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		fragments and packet sizes up to 300 bytes. The SCHC Fragments may
	be delivered asynchronously and Downlink ACK can be sent		be delivered asynchronously, and Downlink ACK can be sent
	opportunistically.		opportunistically.
	Case No losses		*Case No Losses*
	The Downlink flag must be enabled in the sender Uplink message to		The Downlink flag must be enabled in the sender Uplink message to
	allow a Downlink message from the receiver. The Downlink Enable in		allow a Downlink message from the receiver. The Downlink Enable in
	the figures shows where the sender MUST enable the Downlink, and wait		the figures shows where the sender MUST enable the Downlink and wait
	for an ACK.		for an ACK.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2----->|		|-----W=0,FCN=5,Seq=2----->|
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4----->|		|-----W=0,FCN=3,Seq=4----->|
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->|		|-----W=0,FCN=1,Seq=6----->|
	DL Enable |-----W=0,FCN=0,Seq=7----->|		DL Enable |-----W=0,FCN=0,Seq=7----->|
	(no ACK)		(no ACK)
	|-----W=1,FCN=6,Seq=8----->|		|-----W=1,FCN=6,Seq=8----->|
	|-----W=1,FCN=5,Seq=9----->|		|-----W=1,FCN=5,Seq=9----->|
	|-----W=1,FCN=4,Seq=10---->|		|-----W=1,FCN=4,Seq=10---->|
	DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received		DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
	|<- Compound ACK,W=1,C=1 --| C=1		|<- Compound ACK,W=1,C=1 --| C=1
	(End)		(End)
	Figure 33: Uplink ACK-on-Error No-Losses		Figure 33: Uplink ACK-on-Error No-Losses
	Case Fragment losses in first window		*Case Fragment Losses in the First Window*
	In this case, fragments are lost in the first window (W=0). After		In this case, fragments are lost in the first window (W=0). After
	the first All-0 message arrives, the Receiver leverages the		the first All-0 message arrives, the receiver leverages the
	opportunity and sends a SCHC ACK with the corresponding bitmap and		opportunity and sends a SCHC ACK with the corresponding bitmap and
	C=0.		C=0.
	After the loss fragments from the first window (W=0) are resent, the		After the loss fragments from the first window (W=0) are resent, the
	sender continues transmitting the fragments of the following window		sender continues transmitting the fragments of the following window
	(W=1) without opening a reception opportunity. Finally, the All-1		(W=1) without opening a reception opportunity. Finally, the All-1
	fragment is sent, the Downlink is enabled, and the SCHC ACK is		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		received with C=1. Note that the SCHC Compound ACK also uses a
	Sequence Number.		Sequence Number.
	skipping to change at page 31, line 37 ¶		skipping to change at line 1403 ¶
	|<- Compound ACK,W=0,C=0 --| Bitmap:1011011 | FCN=2,Seq=5		|<- Compound ACK,W=0,C=0 --| Bitmap:1011011 | FCN=2,Seq=5
	|-----W=0,FCN=5,Seq=9----->| --		|-----W=0,FCN=5,Seq=9----->| --
	|-----W=0,FCN=2,Seq=10---->|		|-----W=0,FCN=2,Seq=10---->|
	|-----W=1,FCN=6,Seq=11---->|		|-----W=1,FCN=6,Seq=11---->|
	|-----W=1,FCN=5,Seq=12---->|		|-----W=1,FCN=5,Seq=12---->|
	|-----W=1,FCN=4,Seq=13---->|		|-----W=1,FCN=4,Seq=13---->|
	DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received		DL Enable |-----W=1,FCN=7,Seq=14---->| All fragments received
	|<-Compound ACK,W=1,C=1 ---| C=1		|<-Compound ACK,W=1,C=1 ---| C=1
	(End)		(End)
	Figure 34: Uplink ACK-on-Error Losses on First Window		Figure 34: Uplink ACK-on-Error Losses in the First Window
	Case Fragment All-0 lost in first window (W=0)		*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.		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		Therefore, the receiver waits for the next All-0 message of
	intermediate windows, or All-1 message of last window to generate the		intermediate windows or All-1 message of last window to generate the
	corresponding SCHC ACK, notifying the absence of the All-0 of window		corresponding SCHC ACK, which indicates that the All-0 of window 0 is
	0.		absent.
	The sender resends the missing All-0 messages (with any other missing		The sender resends the missing All-0 messages (with any other missing
	fragment from window 0) without opening a reception opportunity.		fragment from window 0) without opening a reception opportunity.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2----->|		|-----W=0,FCN=5,Seq=2----->|
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4----->|		|-----W=0,FCN=3,Seq=4----->|
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->| DL Enable		|-----W=0,FCN=1,Seq=6----->| DL Enable
	|-----W=0,FCN=0,Seq=7--X |		|-----W=0,FCN=0,Seq=7--X |
	(no ACK)		(no ACK)
	|-----W=1,FCN=6,Seq=8----->|		|-----W=1,FCN=6,Seq=8----->|
	|-----W=1,FCN=5,Seq=9----->| __		|-----W=1,FCN=5,Seq=9----->| __
	|-----W=1,FCN=4,Seq=10---->| |W=0		|-----W=1,FCN=4,Seq=10---->| |W=0
	DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7		DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=0,Seq=7
	|<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__		|<-Compound ACK,W=0,C=0 ---| Bitmap:1111110 |__
	|-----W=0,FCN=0,Seq=13---->| All fragments received		|-----W=0,FCN=0,Seq=13---->| All fragments received
	DL Enable |-----W=1,FCN=7,Seq=14---->|		DL Enable |-----W=1,FCN=7,Seq=14---->|
	|<-Compound ACK,W=1,C=1 ---| C=1		|<-Compound ACK,W=1,C=1 ---| C=1
	(End)		(End)
	Figure 35: Uplink ACK-on-Error All-0 Lost on First Window		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		In the following diagram, besides the All-0, there are other fragment
	losses in the first window (W=0).		losses in the first window (W=0).
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2--X |		|-----W=0,FCN=5,Seq=2--X |
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4--X |		|-----W=0,FCN=3,Seq=4--X |
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->|		|-----W=0,FCN=1,Seq=6----->|
	DL Enable |-----W=0,FCN=0,Seq=7--X |		DL Enable |-----W=0,FCN=0,Seq=7--X |
	skipping to change at page 33, line 5 ¶		skipping to change at line 1461 ¶
	|-----W=1,FCN=4,Seq=10---->| |W=0		|-----W=1,FCN=4,Seq=10---->| |W=0
	DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<- FCN=5,Seq=2		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		|<--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=5,Seq=13---->| |FCN=0,Seq=7
	|-----W=0,FCN=3,Seq=14---->| --		|-----W=0,FCN=3,Seq=14---->| --
	|-----W=0,FCN=0,Seq=15---->| All fragments received		|-----W=0,FCN=0,Seq=15---->| All fragments received
	DL Enable |-----W=1,FCN=7,Seq=16---->|		DL Enable |-----W=1,FCN=7,Seq=16---->|
	|<-Compound ACK,W=1,C=1 ---| C=1		|<-Compound ACK,W=1,C=1 ---| C=1
	(End)		(End)
	Figure 36: Uplink ACK-on-Error All-0 and other Fragments Lost on		Figure 36: Uplink ACK-on-Error All-0 and Other Fragments Lost in
	First Window		the First Window
	In the next examples, there are fragment losses in both the first		In the next examples, there are fragment losses in both the first
	(W=0) and second (W=1) windows. The retransmission cycles after the		(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		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		with an All-1, as it serves as an ACK Request message to confirm the
	correct reception of the retransmitted fragments.		correct reception of the retransmitted fragments.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2--X |		|-----W=0,FCN=5,Seq=2--X |
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4--X | __		|-----W=0,FCN=3,Seq=4--X | __
	|-----W=0,FCN=2,Seq=5----->| |W=0		|-----W=0,FCN=2,Seq=5----->| |W=0
	|-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2		|-----W=0,FCN=1,Seq=6----->| |FCN=5,Seq=2
	DL enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4		DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=3,Seq=4
	(no ACK) |FCN=0,Seq=7		(no ACK) |FCN=0,Seq=7
	|-----W=1,FCN=6,Seq=8--X | |W=1		|-----W=1,FCN=6,Seq=8--X | |W=1
	|-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8		|-----W=1,FCN=5,Seq=9----->| |FCN=6,Seq=8
	|-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10		|-----W=1,FCN=4,Seq=10-X | |FCN=4,Seq=10
	DL enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__		DL Enable |-----W=1,FCN=7,Seq=11---->| Missing Fragment<-|__
	|<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110		|<-Compound ACK,W=0,1,C=0--| Bitmap W=0:1010110
	|-----W=0,FCN=5,Seq=13---->| W=1:0100001		|-----W=0,FCN=5,Seq=13---->| W=1:0100001
	|-----W=0,FCN=3,Seq=14---->|		|-----W=0,FCN=3,Seq=14---->|
	|-----W=0,FCN=0,Seq=15---->|		|-----W=0,FCN=0,Seq=15---->|
	|-----W=1,FCN=6,Seq=16---->|		|-----W=1,FCN=6,Seq=16---->|
	|-----W=1,FCN=4,Seq=17---->| All fragments received		|-----W=1,FCN=4,Seq=17---->| All fragments received
	DL enable |-----W=1,FCN=7,Seq=18---->|		DL Enable |-----W=1,FCN=7,Seq=18---->|
	|<-Compound ACK,W=1,C=1----| C=1		|<-Compound ACK,W=1,C=1----| C=1
	(End)		(End)
	Figure 37: Uplink ACK-on-Error All-0 and other Fragments Lost on		Figure 37: Uplink ACK-on-Error All-0 and Other Fragments Lost in
	First and Second Windows (1)		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).
	Similar case as above, but with fewer fragments in the second window
	(W=1)
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2--X |		|-----W=0,FCN=5,Seq=2--X |
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4--X |		|-----W=0,FCN=3,Seq=4--X |
	|-----W=0,FCN=2,Seq=5----->| __		|-----W=0,FCN=2,Seq=5----->| __
	|-----W=0,FCN=1,Seq=6----->| |W=0		|-----W=0,FCN=1,Seq=6----->| |W=0
	DL enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2		DL Enable |-----W=0,FCN=0,Seq=7--X | |FCN=5,Seq=2
	(no ACK) |FCN=3,Seq=4		(no ACK) |FCN=3,Seq=4
	|-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7		|-----W=1,FCN=6,Seq=8--X | |FCN=0,Seq=7
	DL enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment--> W=1		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		|<-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=5,Seq=11---->| W=1:0000001 |__
	|-----W=0,FCN=3,Seq=12---->|		|-----W=0,FCN=3,Seq=12---->|
	|-----W=0,FCN=0,Seq=13---->|		|-----W=0,FCN=0,Seq=13---->|
	|-----W=1,FCN=6,Seq=14---->| All fragments received		|-----W=1,FCN=6,Seq=14---->| All fragments received
	DL enable |-----W=1,FCN=7,Seq=15---->|		DL Enable |-----W=1,FCN=7,Seq=15---->|
	|<-Compound ACK, W=1,C=1---| C=1		|<-Compound ACK, W=1,C=1---| C=1
	(End)		(End)
	Figure 38: Uplink ACK-on-Error All-0 and other Fragments Lost on		Figure 38: Uplink ACK-on-Error All-0 and Other Fragments Lost in
	First and Second Windows (2)		the First and Second Windows (2)
	Case SCHC ACK is lost		*Case SCHC ACK is Lost*
	SCHC over Sigfox does not implement the SCHC ACK REQ message.		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		Instead, it uses the SCHC All-1 message to request a SCHC ACK when
	required.		required.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2----->|		|-----W=0,FCN=5,Seq=2----->|
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4----->|		|-----W=0,FCN=3,Seq=4----->|
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->|		|-----W=0,FCN=1,Seq=6----->|
	DL Enable |-----W=0,FCN=0,Seq=7----->|		DL Enable |-----W=0,FCN=0,Seq=7----->|
	(no ACK)		(no ACK)
	|-----W=1,FCN=6,Seq=8----->|		|-----W=1,FCN=6,Seq=8----->|
	|-----W=1,FCN=5,Seq=9----->|		|-----W=1,FCN=5,Seq=9----->|
	|-----W=1,FCN=4,Seq=10---->|		|-----W=1,FCN=4,Seq=10---->|
	DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received		DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK		DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK
	|<-Compound ACK,W=1,C=1 ---| C=1		|<-Compound ACK,W=1,C=1 ---| C=1
	(End)		(End)
	Figure 39: Uplink ACK-on-Error ACK Lost		Figure 39: Uplink ACK-on-Error ACK Lost
	Case SCHC Compound ACK at the end		*Case SCHC Compound ACK at the End*
	In this example, SCHC Fragment losses are found in both window 0 and		In this example, SCHC Fragment losses are found in both windows 0 and
	1. However, the sender does not send a SCHC ACK after the All-0 of		1. However, the sender does not send a SCHC Compound ACK after the
	window 0. Instead, it sends a SCHC Compound ACK notifying losses of		All-0 of window 0. Instead, it sends a SCHC Compound ACK indicating
	both windows.		fragment losses on both windows.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2--X |		|-----W=0,FCN=5,Seq=2--X |
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4--X |		|-----W=0,FCN=3,Seq=4--X |
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->| __		|-----W=0,FCN=1,Seq=6----->| __
	DL enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0		DL Enable |-----W=0,FCN=0,Seq=7----->| Waits for |W=0
	(no ACK) next DL opportunity |FCN=5,Seq=2		(no ACK) next DL opportunity |FCN=5,Seq=2
	|-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4		|-----W=1,FCN=6,Seq=8--X | |FCN=3,Seq=4
	DL enable |-----W=1,FCN=7,Seq=9----->| Missing Fragment<-- W=1		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		|<-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=5,Seq=11---->| W=1:0000001 --
	|-----W=0,FCN=3,Seq=12---->|		|-----W=0,FCN=3,Seq=12---->|
	|-----W=1,FCN=6,Seq=13---->| All fragments received		|-----W=1,FCN=6,Seq=13---->| All fragments received
	DL enable |-----W=1,FCN=7,Seq=14---->|		DL Enable |-----W=1,FCN=7,Seq=14---->|
	|<-Compound ACK, W=1, C=1 -| C=1		|<-Compound ACK, W=1, C=1 -| C=1
	(End)		(End)
	Figure 40: Uplink ACK-on-Error Fragments Lost on First and Second		Figure 40: Uplink ACK-on-Error Fragments Lost in the First and
	Windows with one Compound ACK		Second Windows with One Compound ACK
	The number of times the same SCHC ACK message will be retransmitted		The number of times the same SCHC ACK message will be retransmitted
	is determined by the MAX_ACK_REQUESTS.		is determined by the MAX_ACK_REQUESTS.
	5.3. SCHC Abort Examples		5.3. SCHC Abort Examples
	Case SCHC Sender-Abort		*Case SCHC Sender-Abort*
	The sender may need to send a Sender-Abort to stop the current		The sender may need to send a Sender-Abort to stop the current
	communication. This may happen, for example, if the All-1 has been		communication. For example, this may happen if the All-1 has been
	sent MAX_ACK_REQUESTS times.		sent MAX_ACK_REQUESTS times.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2----->|		|-----W=0,FCN=5,Seq=2----->|
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4----->|		|-----W=0,FCN=3,Seq=4----->|
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->|		|-----W=0,FCN=1,Seq=6----->|
	DL Enable |-----W=0,FCN=0,Seq=7----->|		DL Enable |-----W=0,FCN=0,Seq=7----->|
	(no ACK)		(no ACK)
	|-----W=1,FCN=6,Seq=8----->|		|-----W=1,FCN=6,Seq=8----->|
	|-----W=1,FCN=5,Seq=9----->|		|-----W=1,FCN=5,Seq=9----->|
	|-----W=1,FCN=4,Seq=10---->|		|-----W=1,FCN=4,Seq=10---->|
	DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received		DL Enable |-----W=1,FCN=7,Seq=11---->| All fragments received
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK (1)		DL Enable |-----W=1,FCN=7,Seq=13---->| RESEND ACK (1)
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2)		DL Enable |-----W=1,FCN=7,Seq=15---->| RESEND ACK (2)
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3)		DL Enable |-----W=1,FCN=7,Seq=17---->| RESEND ACK (3)
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4)		DL Enable |-----W=1,FCN=7,Seq=18---->| RESEND ACK (4)
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5)		DL Enable |-----W=1,FCN=7,Seq=19---->| RESEND ACK (5)
	| X--Compound ACK,W=1,C=1 -| C=1		| X--Compound ACK,W=1,C=1 -| C=1
	DL Enable |----Sender-Abort,Seq=20-->| exit with error condition		DL Enable |----Sender-Abort,Seq=20-->| exit with error condition
	(End)		(End)
	Figure 41: Uplink ACK-on-Error Sender-Abort		Figure 41: Uplink ACK-on-Error Sender-Abort
	Case Receiver-Abort		*Case Receiver-Abort*
	The receiver may need to send a Receiver-Abort to stop the current		The receiver may need to send a Receiver-Abort to stop the current
	communication. This message can only be sent after a Downlink		communication. This message can only be sent after a Downlink
	enable.		Enable.
	Sender Receiver		Sender Receiver
	|-----W=0,FCN=6,Seq=1----->|		|-----W=0,FCN=6,Seq=1----->|
	|-----W=0,FCN=5,Seq=2----->|		|-----W=0,FCN=5,Seq=2----->|
	|-----W=0,FCN=4,Seq=3----->|		|-----W=0,FCN=4,Seq=3----->|
	|-----W=0,FCN=3,Seq=4----->|		|-----W=0,FCN=3,Seq=4----->|
	|-----W=0,FCN=2,Seq=5----->|		|-----W=0,FCN=2,Seq=5----->|
	|-----W=0,FCN=1,Seq=6----->|		|-----W=0,FCN=1,Seq=6----->|
	DL Enable |-----W=0,FCN=0,Seq=7----->|		DL Enable |-----W=0,FCN=0,Seq=7----->|
	|<------ RECV ABORT ------| under-resourced		|<------ RECV ABORT ------| under-resourced
	(Error)		(Error)
	Figure 42: Uplink ACK-on-Error Receiver-Abort		Figure 42: Uplink ACK-on-Error Receiver-Abort
	6. Security considerations		6. Security Considerations
	The radio protocol authenticates and ensures the integrity of each		The radio protocol authenticates and ensures the integrity of each
	message. This is achieved by using a unique device ID and an AES-128		message. This is achieved by using a unique Device ID and an AES-
	based message authentication code, ensuring that the message has been		128-based message authentication code, ensuring that the message has
	generated and sent by the device (see [sigfox-spec] Section 3.8) or		been generated and sent by the device (see [sigfox-spec],
	network (see [sigfox-spec] Section 4.3) with the ID claimed in the		Section 3.8) or Network (see [sigfox-spec], Section 4.3) with the ID
	message [sigfox-spec].		claimed in the message [sigfox-spec].
	Application data can be encrypted at the application layer or not,		Application data may or may not be encrypted at the application
	depending on the criticality of the use case. This flexibility		layer, depending on the criticality of the use case. This
	allows providing a balance between cost and effort vs. risk. AES-128		flexibility allows a balance between cost and effort versus risk.
	in counter mode is used for encryption. Cryptographic keys are		AES-128 in counter mode is used for encryption. Cryptographic keys
	independent for each device. These keys are associated with the		are independent for each device. These keys are associated with the
	device ID and separate integrity and encryption keys are pre-		Device ID, and separate integrity and encryption keys are pre-
	provisioned. An encryption key is only provisioned if		provisioned. An encryption key is only provisioned if
	confidentiality is to be used (see [sigfox-spec] Section 5.3. Note		confidentiality is to be used (see [sigfox-spec], Section 5.3; note
	that further documentation is available at Sigfox upon request).		that further documentation is available at Sigfox upon request).
	The radio protocol has protections against replay attacks, and the		The radio protocol has protections against replay attacks, and the
	cloud-based core network provides firewalling protection against		cloud-based core Network provides firewall protection against
	undesired incoming communications [sigfox-spec].		undesired incoming communications [sigfox-spec].
	The previously described security mechanisms do not guarantee an E2E		The previously described security mechanisms do not guarantee end-to-
	security between the Device SCHC C/D + F/R and the Network SCHC C/D +		end security between the device SCHC C/D + F/R and the Network SCHC
	F/R: potential security threats described in [RFC8724] are applicable		C/D + F/R; potential security threats described in [RFC8724] are
	to the profile specified in this document.		applicable to the profile specified in this document.
	In some circumstances, sending device location information is		In some circumstances, sending device location information is privacy
	privacy-sensitive. The Device Geolocation parameter provided by the		sensitive. The Device Geolocation parameter provided by the Network
	Network is optional, therefore it can be omitted to protect this		is optional; therefore, it can be omitted to protect this aspect of
	aspect of the device privacy.		the device privacy.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. Acknowledgements		8. References
	Carles Gomez has been funded in part by the Spanish Government
	through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
	grant, and the PID2019-106808RA-I00 grant, and by Secretaria
	d'Universitats i Recerca del Departament d'Empresa i Coneixement de
	la Generalitat de Catalunya 2017 through grant SGR 376.
	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.
	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.
	9. References
	9.1. Normative References
	[I-D.ietf-lpwan-schc-compound-ack]		8.1. Normative References
	Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,
	Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in
	Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
	ack-10, January 2023, <httpsout-://www.ietf.org/internet-
	drafts/draft-ietf-lpwan-schc-compound-ack-10.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/info/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, July 2023,
			<https://www.rfc-editor.org/info/rfc9441>.
	[sigfox-spec]		[sigfox-spec]
	Sigfox, "Sigfox Radio Specifications",		Sigfox, "Sigfox Device Radio Specifications",
	<https://build.sigfox.com/sigfox-device-radio-		<https://build.sigfox.com/sigfox-device-radio-
	specifications>.		specifications>.
	9.2. Informative References		8.2. Informative References
	[I-D.ietf-core-comi]		[CORE-COMI]
	Veillette, M., Stok, P. V. D., Pelov, A., Bierman, A., and		Veillette, M., Ed., van der Stok, P., Ed., Pelov, A.,
	I. Petrov, "CoAP Management Interface (CORECONF)", Work in		Bierman, A., and C. Bormann, Ed., "CoAP Management
	Progress, Internet-Draft, draft-ietf-core-comi-11, 17		Interface (CORECONF)", Work in Progress, Internet-Draft,
	January 2021, <https://www.ietf.org/archive/id/draft-ietf-		draft-ietf-core-comi-12, 13 March 2023,
	core-comi-11.txt>.		<https://datatracker.ietf.org/doc/html/draft-ietf-core-
			comi-12>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	skipping to change at page 40, line 18 ¶		skipping to change at line 1749 ¶
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	[sigfox-callbacks]		[sigfox-callbacks]
	Sigfox, "Sigfox Callbacks",		Sigfox, "Sigfox Callbacks",
	<https://support.sigfox.com/docs/callbacks-documentation>.		<https://support.sigfox.com/docs/callbacks-documentation>.
	[sigfox-docs]		[sigfox-docs]
	Sigfox, "Sigfox Documentation",		Sigfox, "Sigfox Documentation",
	<https://support.sigfox.com/docs>.		<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		Authors' Addresses
	Juan Carlos Zuniga		Juan Carlos Zúñiga
	Montreal QC		Montreal QC
	Canada		Canada
	Email: j.c.zuniga@ieee.org		Email: j.c.zuniga@ieee.org
	Carles Gomez		Carles Gomez
	Universitat Politecnica de Catalunya		Universitat Politècnica de Catalunya
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	08860 Castelldefels		08860 Castelldefels
	Spain		Spain
	Email: carles.gomez@upc.edu		Email: carles.gomez@upc.edu
	Sergio Aguilar		Sergio Aguilar
	Universitat Politecnica de Catalunya		Universitat Politècnica de Catalunya
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	08860 Castelldefels		08860 Castelldefels
	Spain		Spain
	Email: sergio.aguilar.romero@upc.edu		Email: sergio.aguilar.romero@upc.edu
	Laurent Toutain		Laurent Toutain
	IMT-Atlantique		IMT-Atlantique
	2 rue de la Chataigneraie
	CS 17607		CS 17607
			2 rue de la Chataigneraie
	35576 Cesson-Sevigne Cedex		35576 Cesson-Sevigne Cedex
	France		France
	Email: Laurent.Toutain@imt-atlantique.fr		Email: Laurent.Toutain@imt-atlantique.fr
	Sandra Cespedes
			Sandra Céspedes
	Concordia University		Concordia University
	1455 De Maisonneuve Blvd. W.		1455 De Maisonneuve Blvd. W.
	Montreal QC, H3G 1M8		Montreal QC H3G 1M8
	Canada		Canada
	Email: sandra.cespedes@concordia.ca		Email: sandra.cespedes@concordia.ca
	Diego Wistuba		Diego Wistuba
	NIC Labs, Universidad de Chile		NIC Labs, Universidad de Chile
	Av. Almte. Blanco Encalada 1975		Av. Almte. Blanco Encalada 1975
	Santiago		Santiago
	Chile		Chile
	Email: wistuba@niclabs.cl		Email: research@witu.cl
	Julien Boite		Julien Boite
	Unabiz (Sigfox)		Unabiz (Sigfox)
	Labege		Labege
	France		France
	Email: julien.boite@unabiz.com		Email: juboite@free.fr
	URI: https://www.sigfox.com/		URI: https://www.sigfox.com/
End of changes. 276 change blocks.
	724 lines changed or deleted		729 lines changed or added
This html diff was produced by rfcdiff 1.48.