< draft-ietf-lpwan-schc-over-sigfox-08.txt		draft-ietf-lpwan-schc-over-sigfox-09.txt >
	lpwan Working Group JC. Zuniga		lpwan Working Group JC. Zuniga
	Internet-Draft SIGFOX		Internet-Draft
	Intended status: Standards Track C. Gomez		Intended status: Standards Track C. Gomez
	Expires: April 26, 2022 S. Aguilar		Expires: 25 August 2022 S. Aguilar
	Universitat Politecnica de Catalunya		Universitat Politècnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	S. Cespedes		S. Cespedes
	D. Wistuba		D. Wistuba
	NIC Labs, Universidad de Chile		NIC Labs, Universidad de Chile
	October 23, 2021		J. Boite
			SIGFOX
			21 February 2022
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-08		draft-ietf-lpwan-schc-over-sigfox-09
	Abstract		Abstract
	The Generic Framework for Static Context Header Compression and		The Generic Framework for Static Context Header Compression and
	Fragmentation (SCHC) specification describes two mechanisms: i) an		Fragmentation (SCHC) specification describes two mechanisms: i) an
	application header compression scheme, and ii) a frame fragmentation		application header compression scheme, and ii) a frame fragmentation
	and loss recovery functionality. SCHC offers a great level of		and loss recovery functionality. SCHC offers a great level of
	flexibility that can be tailored for different Low Power Wide Area		flexibility that can be tailored for different Low Power Wide Area
	Network (LPWAN) technologies.		Network (LPWAN) technologies.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 26, 2022.		This Internet-Draft will expire on 25 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3		3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7		3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7
	3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7		3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
	3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7		3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8		3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8
	3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11		3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11
	3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12		3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12
	3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 12		3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 13
	3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 16		3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option
			2 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.8. SCHC-Sender Abort . . . . . . . . . . . . . . . . . . . . 18		3.8. SCHC-Sender Abort . . . . . . . . . . . . . . . . . . . . 18
	3.9. SCHC-Receiver Abort . . . . . . . . . . . . . . . . . . . 19		3.9. SCHC-Receiver Abort . . . . . . . . . . . . . . . . . . . 19
	3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19		3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19
	4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20		4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20
	4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20		4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20
	4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21		4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21
	4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28		4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 27
	5. Security considerations . . . . . . . . . . . . . . . . . . . 30		5. Security considerations . . . . . . . . . . . . . . . . . . . 28
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	7.1. Normative References . . . . . . . . . . . . . . . . . . 31		7.1. Normative References . . . . . . . . . . . . . . . . . . 29
	7.2. Informative References . . . . . . . . . . . . . . . . . 31		7.2. Informative References . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	The Generic Framework for Static Context Header Compression and		The Generic Framework for Static Context Header Compression and
	Fragmentation (SCHC) specification [RFC8724] describes two		Fragmentation (SCHC) specification [RFC8724] describes two
	mechanisms: i) a frame fragmentation and loss recovery functionality,		mechanisms: i) a frame fragmentation and loss recovery functionality,
	and ii) an application header compression scheme. Either can be used		and ii) an application header compression scheme. Either can be used
	on top of all the four LWPAN technologies defined in [RFC8376].		on top of all the four LWPAN technologies defined in [RFC8376].
	These LPWANs have similar characteristics such as star-oriented		These LPWANs have similar characteristics such as star-oriented
	topologies, network architecture, connected devices with built-in		topologies, network architecture, connected devices with built-in
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 22 ¶
	| SCHC C/D & F/R | | |		| SCHC C/D & F/R | | |
	| | | |		| | | |
	+-------+--------+ +--------+-----+		+-------+--------+ +--------+-----+
	$ .		$ .
	$ +---------+ +--------------+ +---------+ .		$ +---------+ +--------------+ +---------+ .
	$ | | | | | Network | .		$ | | | | | Network | .
	+~~ |Sigfox BS| |Sigfox Network| | SCHC | .		+~~ |Sigfox BS| |Sigfox Network| | SCHC | .
	| (RG) | === | (NGW) | === |C/D & F/R|.....		| (RG) | === | (NGW) | === |C/D & F/R|.....
	+---------+ +--------------+ +---------+		+---------+ +--------------+ +---------+
	Figure 1: Network Architecture		Figure 1: Network Architecture
	In the case of the global Sigfox Network, RGs (or Base Stations) are		In the case of the global Sigfox Network, RGs (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 Sigfox base stations in the world,		single entity that connects to all Sigfox base stations in the world,
	providing hence a global single star network topology.		providing hence a global single star network topology.
	The Device sends application flows that are compressed and/or		The Device sends application flows that are compressed and/or
	fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to		fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to
	reduce headers size and/or fragment the packet. The resulting SCHC		reduce headers size and/or fragment the packet. The resulting SCHC
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 24 ¶
	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 network (NGW) to the Network SCHC C/D + F/R through a
	callback/API with the following information:		callback/API with the following information:
	o Device ID		* Device ID
	o Message Sequence Number		* Message Sequence Number
	o Message Payload		* Message Payload
	o Message Timestamp		* Message Timestamp
	o Device Geolocation (optional)		* Device Geolocation (optional)
	o RSSI (optional)		* RSSI (optional)
	o Device Temperature (optional)		* Device Temperature (optional)
	o 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.		that the Device has sent in the uplink transmission.
	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
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	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.
	+---------------+-----------------+		+---------------+-----------------+
	| Sigfox Header | Sigfox payload |		| Sigfox Header | Sigfox payload |
	+---------------+---------------- +		+---------------+---------------- +
	| SCHC message |		| SCHC message |
	+-----------------+		+-----------------+
	Figure 2: SCHC Message in Sigfox		Figure 2: SCHC Message in Sigfox
	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).
	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 Device		following an uplink communication that so indicates. Hence, a Device
	explicitly indicates its intention to receive a downlink message		explicitly indicates its intention to receive a downlink message
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	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 receive end. Since only UL messages/fragments that have passed		the receive end. Since only UL messages/fragments that have passed
	the CRC-check are delivered to the Network SCHC C/D + F/R, and each		the Sigfox CRC-check are delivered to the Network SCHC C/D + F/R,
	one has an associated Sigfox Message Sequence Number (see		integrity can be guaranteed when no consecutive messages are missing
	Section 3.2), integrity can be guaranteed when no consecutive		from the sequence and all FCN bitmaps are complete. With this
	messages are missing from the sequence and all FCN bitmaps are		functionality in mind, and in order to save protocol and processing
	complete. In order to support multiple flows/RuleIDs (potentially		overhead, the use of a Reassembly Check Sequence (RCS) as described
	interleaved), the implementation of a central message sequence		in Section 3.6.1.5 is RECOMMENDED.
	counter at the Network SCHC C/D + F/R is required. With this
	functionality and in order to save protocol overhead, the use of a
	dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED.
	The L2 Word Size used by Sigfox is 1 byte (8 bits).		The L2 Word Size used by Sigfox is 1 byte (8 bits).
	3.6.1. Uplink Fragmentation		3.6.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. Data packets are self-contained (aka "message in a		the network. Data packets are self-contained (aka "message in a
	skipping to change at page 9, line 22 ¶		skipping to change at page 9, line 20 ¶
	to be marked with FCN = X-1. Consecutive fragments MUST be marked		to be marked with FCN = X-1. Consecutive fragments MUST be marked
	with decreasing FCN values, having the last fragment marked with FCN		with decreasing FCN values, having the last fragment marked with FCN
	= (All-1). Hence, even though the No-ACK mode does not allow		= (All-1). Hence, even though the No-ACK mode does not allow
	recovering missing fragments, it allows indicating implicitly the		recovering missing fragments, it allows indicating implicitly the
	size of the expected packet to the Network and hence detect at the		size of the expected packet to the Network and hence detect at the
	receiver side whether all fragments have been received or not.		receiver side whether all fragments have been received or not.
	The RECOMMENDED Fragmentation Header size is 8 bits, and it is		The RECOMMENDED Fragmentation Header size is 8 bits, and it is
	composed as follows:		composed as follows:
	o RuleID size: 4 bits		* RuleID size: 4 bits
	o DTag size (T): 0 bits		* DTag size (T): 0 bits
	o Fragment Compressed Number (FCN) size (N): 4 bits		* Fragment Compressed Number (FCN) size (N): 4 bits
	o 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.
	o RCS size: 0 bits (Not used)		* RCS size: 0 bits (Not used)
	3.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header		3.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	ACK-on-Error with single-byte header is RECOMMENDED for medium to		ACK-on-Error with single-byte header is RECOMMENDED for medium to
	large size packets that need to be sent reliably. ACK-on-Error is		large size packets that need to be sent reliably. ACK-on-Error is
	optimal for Sigfox transmissions, since it leads to a reduced number		optimal for Sigfox transmissions, since it leads to a reduced number
	of ACKs in the lower capacity downlink channel. Also, downlink		of ACKs in the lower capacity downlink channel. Also, downlink
	messages can be sent asynchronously and opportunistically.		messages can be sent asynchronously and opportunistically.
	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 RECOMMENDED to be 8 bits in size		uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size
	and is composed as follows:		and is composed as follows:
	o Rule ID size: 3 bits		* Rule ID size: 3 bits
	o DTag size (T): 0 bits
	o Window index (W) size (M): 2 bits		* DTag size (T): 0 bits
	o Fragment Compressed Number (FCN) size (N): 3 bits		* Window index (W) size (M): 2 bits
	o MAX_ACK_REQUESTS: 5
	o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)		* Fragment Compressed Number (FCN) size (N): 3 bits
	o Tile size: 11 bytes		* MAX_ACK_REQUESTS: 5
			* WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)
	o Retransmission Timer: Application-dependent		* Tile size: 11 bytes
	o Inactivity Timer: Application-dependent		* Retransmission Timer: Application-dependent
	o RCS size: 0 bits (Not used)		* Inactivity Timer: Application-dependent
	The correspondent SCHC ACK in the downlink is 13 bits long, so		* RCS size: 3 bits
	padding is needed to complete the required 64 bits of Sigfox payload.
	3.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header		3.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 1
	ACK-on-Error with two-byte header is RECOMMENDED for very large size		ACK-on-Error with two-byte header is RECOMMENDED for very large size
	packets that need to be sent reliably. ACK-on-Error is optimal for		packets that need to be sent reliably. ACK-on-Error is optimal for
	Sigfox transmissions, since it leads to a reduced number of ACKs in		Sigfox transmissions, since it leads to a reduced number of ACKs in
	the lower capacity downlink channel. Also, downlink messages can be		the lower capacity downlink channel. Also, downlink messages can be
	sent asynchronously and opportunistically.		sent asynchronously and opportunistically.
			In order to allow transmission of large packets/files up to 480 bytes
			long, the SCHC uplink Fragmentation Header size is RECOMMENDED to be
			16 bits in size and composed as follows:
			* Rule ID size is: 6 bits
			* DTag size (T) is: 0 bits
			* Window index (W) size (M): 2 bits
			* Fragment Compressed Number (FCN) size (N): 4 bits.
			* MAX_ACK_REQUESTS: 5
			* WINDOW_SIZE: 12 (with a maximum value of FCN=0b1011)
			* Tile size: 10 bytes
			* Retransmission Timer: Application-dependent
			* Inactivity Timer: Application-dependent
			* RCS size: 4 bits
			3.6.1.4. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2
	In order to allow transmission of very large packets/files up to 2250		In order to allow transmission of very large packets/files up to 2250
	bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED		bytes long, the SCHC uplink Fragmentation Header size is RECOMMENDED
	to be 16 bits in size and composed as follows:		to be 16 bits in size and composed as follows:
	o Rule ID size is: 8 bits		* Rule ID size is: 8 bits
	o DTag size (T) is: 0 bits		* DTag size (T) is: 0 bits
	o Window index (W) size (M): 3 bits		* Window index (W) size (M): 3 bits
	o Fragment Compressed Number (FCN) size (N): 5 bits.		* Fragment Compressed Number (FCN) size (N): 5 bits.
	o MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)		* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	o Tile size: 10 bytes		* Tile size: 10 bytes
	o Retransmission Timer: Application-dependent		* Retransmission Timer: Application-dependent
	o Inactivity Timer: Application-dependent		* Inactivity Timer: Application-dependent
	o RCS size: 0 bits (Not used)		* RCS size: 5 bits
	The correspondent SCHC ACK in the downlink is 43 bits long, so
	padding is needed to complete the required 64 bits of Sigfox payload.
	3.6.1.4. All-1 behaviour + Sigfox Sequence Number		3.6.1.5. All-1 and RCS behaviour
	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 be		an All-1 FCN. Since this last window may not be full (i.e. it may be
	comprised of less than WINDOW_SIZE fragments), an All-1 fragment may		comprised of less than WINDOW_SIZE fragments), an All-1 fragment may
	follow a value of FCN higher than 1 (0b01). In this case, the		follow a value of FCN higher than 1 (0b01). In this case, the
	receiver could not derive from the FCN values alone whether there are		receiver could not derive from the FCN values alone whether there are
	any missing fragments right before the All-1 fragment or not.		any missing fragments right before the All-1 fragment or not.
	However, since a Message Sequence Number is provided by the Sigfox		For Rules where the number of fragments in the last window is
	protocol together with the Sigfox Payload, the receiver can detect if		unknown, an RCS field MUST be used, indicating the number of
	there are missing fragments before the All-1 and hence construct the		fragments in the last window, including the All-1. With this RCS
	corresponding SCHC ACK Bitmap accordingly.		value, the receiver can detect if there are missing fragments before
			the All-1 and hence construct the corresponding SCHC ACK Bitmap
			accordingly, and send it in response to the All-1.
	3.6.2. Downlink Fragmentation		3.6.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.
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 25 ¶
	[RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC		[RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC
	Tile size per mode can be defined so that every Sigfox message always		Tile size per mode can be defined so that every Sigfox message always
	carries one SCHC Tile.		carries one SCHC Tile.
	For reliable downlink fragment transmission, the ACK-Always mode is		For reliable downlink fragment transmission, the ACK-Always mode is
	RECOMMENDED.		RECOMMENDED.
	The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8		The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8
	bits in size and is composed as follows:		bits in size and is composed as follows:
	o RuleID size: 3 bits		* RuleID size: 3 bits
	o DTag size (T): 0 bits		* DTag size (T): 0 bits
	o Window index (W) size (M) is: 0 bits		* Window index (W) size (M) is: 0 bits
	o Fragment Compressed Number (FCN) size (N): 5 bits		* Fragment Compressed Number (FCN) size (N): 5 bits
	o MAX_ACK_REQUESTS: 5		* MAX_ACK_REQUESTS: 5
	o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)		* WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	o Tile size: 7 bytes		* Tile size: 7 bytes
	o Retransmission Timer: Application-dependent		* Retransmission Timer: Application-dependent
	o Inactivity Timer: Application-dependent		* Inactivity Timer: Application-dependent
	o RCS size: 0 bits (Not used)		* RCS size: 0 bits (Not used)
	3.7. SCHC-over-Sigfox F/R Message Formats		3.7. 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
	[I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over		[I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over
	Sigfox.		Sigfox.
	3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header		3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 19 ¶
	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 of 11 bytes, padding
	MUST NOT be added.		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 3: Regular SCHC Fragment format for all fragments except the		Figure 3: Regular SCHC Fragment format for all fragments except
	last one		the last one
	The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC		The use of SCHC ACK REQ is NOT RECOMMENDED, instead the All-1 SCHC
	Fragment SHOULD be used to request a SCHC ACK from the receiver		Fragment SHOULD be used to request a SCHC ACK from the receiver
	(Network SCHC). As per [RFC8724], the All-0 message is		(Network SCHC). As per [RFC8724], the All-0 message is
	distinguishable from the SCHC ACK REQ (All-1 message). The		distinguishable from the SCHC ACK REQ (All-1 message). The
	penultimate tile of a SCHC Packet is of regular size.		penultimate tile of a SCHC Packet is of regular size.
	3.7.1.2. All-1 SCHC Fragment		3.7.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
	MUST contain the last tile of the SCHC Packet. The last tile MUST be		MUST contain the last tile of the SCHC Packet. The last tile MUST be
	of at least 1 byte (one L2 word). Padding MUST NOT be added, as the		of at least 1 byte (one L2 word). Padding MUST NOT be added, as the
	resulting size is L2-word-multiple.		resulting size is L2-word-multiple.
	|--- SCHC Fragment Header ---|		|--- SCHC Fragment Header ---|
	+ --------------------------- + ------------ +		+ --------------------------- + ------------ +
	| RuleID | W | FCN=ALL-1 | Payload |		| RuleID | W | FCN=ALL-1 | Payload |
	+ ------ + ------ + --------- + ------------ +		+ ------ + ------ + --------- + ------------ +
	| 3 bits | 2 bits | 3 bits | 8 to 88 bits |		| 3 bits | 2 bits | 3 bits | 8 to 88 bits |
	Figure 4: All-1 SCHC Message format with last tile		Figure 4: All-1 SCHC Message format with 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 Rule ID, M, and N values). The All-1		Sender-Abort message (with same Rule ID, M, and N values). The All-1
	MUST have the last tile of the SCHC Packet, which MUST be of at least		MUST have the last tile of the SCHC Packet, which MUST be of at least
	1 byte. The SCHC Sender-Abort message header size is of 1 byte, with		1 byte. The SCHC Sender-Abort message header size is of 1 byte, with
	no padding bits.		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 of 1 byte (only header with
	no padding). This way, the minimum size of the All-1 is 2 bytes, and		no padding). This way, the minimum size of the All-1 is 2 bytes, and
	skipping to change at page 14, line 23 ¶		skipping to change at page 14, line 37 ¶
	|---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---|		|---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---|
	+ ----------------------- + ------ +...+ ------- + ------ + ------- +		+ ----------------------- + ------ +...+ ------- + ------ + ------- +
	| RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad |		| RuleID | W=b'x | C=b'0 | Bitmap |...| W=b'x+i | Bitmap | b'0-pad |
	+ ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- +		+ ------ + ------ + ----- + ------ +...+ ------- + ------ + ------- +
	| 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits |		| 3 bits | 2 bits | 1 bit | 7 bits | | 2 bits | 7 bits |
	On top are noted the window number of the corresponding bitmap.		On top are noted the window number of the corresponding bitmap.
	Losses are found in windows x,...,x+i.		Losses are found in windows x,...,x+i.
	Figure 6: SCHC Compound ACK message format		Figure 6: SCHC Compound ACK message format
	The following figures show examples of the SCHC Compound ACK message		The following figures show examples of the SCHC Compound ACK message
	format, when used on SCHC over Sigfox.		format, when used on SCHC over Sigfox.
	|---- SCHC ACK Header ----|- W=00 -|----- W=01 ------|		|---- SCHC ACK Header ----|- W=00 -|----- W=01 ------|
	+ ----------------------- + ------ + ------ + ------ + ------- +		+ ----------------------- + ------ + ------ + ------ + ------- +
	| RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad |		| RuleID | W=b'00 | C=b'0 | Bitmap | W=b'01 | Bitmap | b'0-pad |
	+ ------ + ------ + ----- + ------ + ------ + ------ + ------- +		+ ------ + ------ + ----- + ------ + ------ + ------ + ------- +
	| 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits |		| 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits |
	skipping to change at page 15, line 34 ¶		skipping to change at page 15, line 44 ¶
	|3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|		|3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|
	|--- W=b'10 --|--- W=b'11 --|		|--- W=b'10 --|--- W=b'11 --|
	|------+------+------+------+-------+		|------+------+------+------+-------+
	... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad|		... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad|
	|------+------+------+------+-------+		|------+------+------+------+-------+
	|2 bits|7 bits|2 bits|7 bits|24 bits|		|2 bits|7 bits|2 bits|7 bits|24 bits|
	Losses are found in windows 00, 01, 10 and 11.		Losses are found in windows 00, 01, 10 and 11.
	Figure 10: SCHC Compound ACK example 4		Figure 10: SCHC Compound ACK example 4
	|- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --|		|- SCHC ACK Header -|W=b'00|-- W=b'01 ---|--- W=b'10 --|
	+-------------------+------+------+------+------+------+-------+		+-------------------+------+------+------+------+------+-------+
	|RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad|		|RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap|W=b'10|Bitmap|b'0-pad|
	+------+------+-----+------+------+------+------+------+-------+		+------+------+-----+------+------+------+------+------+-------+
	|3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits|		|3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|2 bits|7 bits|33 bits|
	Losses are found in windows 00, 01 and 10.		Losses are found in windows 00, 01 and 10.
	Figure 11: SCHC Compound ACK example 5		Figure 11: SCHC Compound ACK example 5
	3.7.1.4. SCHC Sender-Abort Message format		3.7.1.4. SCHC Sender-Abort Message format
	|---- Sender-Abort Header ----|		|---- Sender-Abort Header ----|
	+ --------------------------- +		+ --------------------------- +
	| RuleID | W | FCN=ALL-1 |		| RuleID | W | FCN=ALL-1 |
	+ ------ + ------ + --------- +		+ ------ + ------ + --------- +
	| 3 bits | 2 bits | 3 bits |		| 3 bits | 2 bits | 3 bits |
	Figure 12: SCHC Sender-Abort message format		Figure 12: SCHC Sender-Abort message format
	skipping to change at page 16, line 25 ¶		skipping to change at page 16, line 35 ¶
	3.7.1.5. SCHC Receiver-Abort Message format		3.7.1.5. SCHC Receiver-Abort Message format
	|- Receiver-Abort Header -|		|- Receiver-Abort Header -|
	+ ----------------------- + ------- +		+ ----------------------- + ------- +
	| RuleID | W=b'11 | C=b'1 | b'1-pad |		| RuleID | W=b'11 | C=b'1 | b'1-pad |
	+ ------ + ------ + ----- + ------- +		+ ------ + ------ + ----- + ------- +
	| 3 bits | 2 bits | 1 bit | 58 bits |		| 3 bits | 2 bits | 1 bit | 58 bits |
	Figure 13: SCHC Receiver-Abort message format		Figure 13: SCHC Receiver-Abort message format
	3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header		3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header Option 2
	3.7.2.1. Regular SCHC Fragment		3.7.2.1. Regular SCHC Fragment
	Figure 14 shows an example of a regular SCHC fragment for all		Figure 14 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 14: Regular SCHC Fragment format for all fragments except the		Figure 14: Regular SCHC Fragment format for all fragments except
	last one		the last one
	The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC		The use of SCHC ACK is NOT RECOMMENDED, instead the All-1 SCHC
	Fragment SHOULD be used to request a SCHC ACK from the receiver		Fragment SHOULD be used to request a SCHC ACK from the receiver
	(Network SCHC). As per [RFC8724], the All-0 message is		(Network SCHC). As per [RFC8724], the All-0 message is
	distinguishable from the SCHC ACK REQ (All-1 message).		distinguishable from the SCHC ACK REQ (All-1 message).
	3.7.2.2. All-1 SCHC Fragment		3.7.2.2. All-1 SCHC Fragment
	Figure 15 shows an example of the All-1 message. The All-1 message		Figure 15 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.
	skipping to change at page 17, line 41 ¶		skipping to change at page 17, line 46 ¶
	Figure 16 shows the SCHC ACK format when all fragments have been		Figure 16 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 16: SCHC Success ACK message format		Figure 16: 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 17. The SCHC Compound		Compound ACK message format is shown in Figure 17. The SCHC Compound
	ACK can report up to 3 windows with losses. The window number (W)		ACK can report up to 3 windows with losses. The window number (W)
	and its corresponding bitmap MUST be ordered from the lowest-numbered		and its corresponding bitmap MUST be ordered from the lowest-numbered
	window number to the highest-numbered window. If window numbered 000		window number to the highest-numbered window. If window numbered 000
	is present in the SCHC Compound ACK, the window number 000 MUST be		is present in the SCHC Compound ACK, the window number 000 MUST be
	placed between the Rule ID and C bit to avoid confusion with padding		placed between the Rule ID and C bit to avoid confusion with padding
	bits. The SCHC Compound ACK MUST be 0 padded (Padding bits must be		bits.
	0).
			When sent in the downlink, the SCHC Compound ACK MUST be 0 padded
			(Padding bits must be 0) to complement the 64 bits required by the
			Sigfox payload.
	|- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---|		|- SCHC ACK Header -| W=b'x |...|--- W=b'x+i ---|
	+-------------------+-------+...+-------+-------+-------+		+-------------------+-------+...+-------+-------+-------+
	|RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad|		|RuleID|W=b'x |C=b'0|Bitmap |...|W=b'x+i|Bitmap |b'0-pad|
	+------+------+-----+-------+...|-------+-------+-------+		+------+------+-----+-------+...|-------+-------+-------+
	|8 bits|3 bits|1 bit|31 bits| | 3 bits|31 bits|		|8 bits|3 bits|1 bit|31 bits| | 3 bits|31 bits|
	On top are noted the window number		On top are noted the window number
	of the corresponding bitmap.		of the corresponding bitmap.
	Losses are found in windows x,...,x+i.		Losses are found in windows x,...,x+i.
	skipping to change at page 18, line 42 ¶		skipping to change at page 19, line 4 ¶
	|-- Receiver-Abort Header -|		|-- Receiver-Abort Header -|
	+ ------------------------ + ------- +		+ ------------------------ + ------- +
	| RuleID | W=b'111 | C=b'1 | b'1-pad |		| RuleID | W=b'111 | C=b'1 | b'1-pad |
	+ ------ + ------- + ----- + ------- +		+ ------ + ------- + ----- + ------- +
	| 8 bits | 3 bits | 1 bit | 52 bits |		| 8 bits | 3 bits | 1 bit | 52 bits |
	Figure 19: SCHC Receiver-Abort message format		Figure 19: SCHC Receiver-Abort message format
	3.8. SCHC-Sender Abort		3.8. SCHC-Sender Abort
			* As defined in [RFC8724], a SCHC-Sender Abort can be triggered when
	o 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/Sigfox, a SCHC-Sender Abort		MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, a SCHC-Sender Abort
	MUST be sent if the number of repeated All-1s sent in a row is		MUST be sent if the number of repeated All-1s (i.e., with the same
	greater than or equal to MAX_ACK_REQUESTS.		bitmap) sent in sequence is greater than or equal to
			MAX_ACK_REQUESTS.
	o The MAX_ACK_REQUEST counter MUST be reset when a SCHC ACK is		* The MAX_ACK_REQUEST counter MUST be reset when a SCHC ACK is
	successfully received.		successfully received.
	3.9. SCHC-Receiver Abort		3.9. SCHC-Receiver Abort
	o As defined in [RFC8724], a SCHC-Receiver Abort is triggered when		* As defined in [RFC8724], a SCHC-Receiver Abort is triggered when
	the receiver has no RuleID and DTag pairs available for a new		the receiver has no RuleID and DTag pairs available for a new
	session. In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be		session. In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be
	sent if, for a single device, all the RuleIDs are being processed		sent if, for a single device, all the RuleIDs are being processed
	by the receiver (i.e., have an active session) at a certain time,		by the receiver (i.e., have an active session) at a certain time
	or if the RuleID of the fragment is not valid.		and a new one is requested, or if the RuleID of the fragment is
			not valid.
	o A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer		* A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer
	expires.		expires.
	o A SCHC-Receiver Abort can be triggered when the number of ACK		* A SCHC-Receiver Abort can be triggered when the number of ACK
	attempts is not strictly less than MAX_ACK_REQUESTS. In the case		attempts is not strictly less than MAX_ACK_REQUESTS. In the case
	of SCHC/Sigfox, a SCHC-Receiver Abort MUST be sent if the number		of SCHC/Sigfox, a SCHC-Receiver Abort MUST be sent if the number
	of repeated SCHC ACKs sent in a row (i.e., synchronized with the		of repeated SCHC ACKs sent in a row (i.e., synchronized with the
	ACK REQ case) is greater than or equal to MAX_ACK_REQUESTS.		ACK REQ case, and with identical bitmaps) is greater than or equal
			to MAX_ACK_REQUESTS.
	o For SCHC/Sigfox implementations, the MAX_ACK_REQUESTS counter MUST
	be reset when a SCHC ACK is successfully received.
	o Although a SCHC-Receiver Abort can be triggered at any point in		* Although a SCHC-Receiver Abort can be triggered at any point in
	time, a SCHC-Receiver Abort downlink message MUST only be sent		time, a SCHC-Receiver Abort downlink message MUST only be sent
	when there is a downlink transmission opportunity.		when there is a downlink transmission opportunity.
	3.10. Padding		3.10. Padding
	The Sigfox payload fields have different characteristics in uplink		The Sigfox payload fields have different characteristics in uplink
	and downlink.		and downlink.
	Uplink frames can contain a payload size from 0 to 12 bytes. The		Uplink frames 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
	skipping to change at page 21, line 15 ¶		skipping to change at page 21, line 15 ¶
	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 21: UL No-ACK Losses (scenario 1)		Figure 21: UL No-ACK Losses (scenario 1)
	4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header		4.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 DL ACK can be sent opportunistically.		be delivered asynchronously and DL ACK can be sent opportunistically.
	Case No losses		Case No losses
	The downlink flag must be enabled in the sender UL message to allow a		The downlink flag must be enabled in the sender UL message to allow a
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 45 ¶
	|-----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
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 22: UL ACK-on-Error No-Losses		Figure 22: UL ACK-on-Error No-Losses
	Case Fragment losses in first window		Case Fragment losses in 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.		received with C=1.
	skipping to change at page 22, line 36 ¶		skipping to change at page 22, line 33 ¶
	|<------ ACK, W=0, C=0 ------| Bitmap:1011011		|<------ ACK, W=0, C=0 ------| Bitmap:1011011
	|-----W=0, FCN=5, Seq=8----->|		|-----W=0, FCN=5, Seq=8----->|
	|-----W=0, FCN=2, Seq=9----->|		|-----W=0, FCN=2, Seq=9----->|
	|-----W=1, FCN=6, Seq=10---->|		|-----W=1, FCN=6, Seq=10---->|
	|-----W=1, FCN=5, Seq=11---->|		|-----W=1, FCN=5, Seq=11---->|
	|-----W=1, FCN=4, Seq=12---->|		|-----W=1, FCN=4, Seq=12---->|
	DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received		DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 23: UL ACK-on-Error Losses on First Window		Figure 23: UL ACK-on-Error Losses on First Window
	Case Fragment All-0 lost in first window (W=0)		Case Fragment All-0 lost in 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, notifying the absence of the All-0 of window
	0.		0.
	The sender resends the missing All-0 messages (with any other missing		The sender resends the missing All-0 messages (with any other missing
	skipping to change at page 23, line 24 ¶		skipping to change at page 23, line 24 ¶
	|-----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---->| Missing Fragment W=0, FCN=0, Seq=7		DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7
	|<------ ACK, W=0, C=0 ------| Bitmap:1111110		|<------ 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---->|
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 24: UL ACK-on-Error All-0 Lost on First Window		Figure 24: UL ACK-on-Error All-0 Lost on 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----->|
	skipping to change at page 24, line 26 ¶		skipping to change at page 24, line 5 ¶
	|-----W=1, FCN=4, Seq=10---->|		|-----W=1, FCN=4, Seq=10---->|
	DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0		DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0
	|<------ ACK, W=0, C=0 ------| Bitmap:1010110		|<------ ACK, W=0, C=0 ------| Bitmap:1010110
	|-----W=0, FCN=5, Seq=13---->|		|-----W=0, FCN=5, Seq=13---->|
	|-----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---->|
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on
	Window		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) should always		All-1 is sent (i.e., not in intermediate windows) should always
	finish with an with an All-1, as it serves as an ACK Request message		finish with an with an All-1, as it serves as an ACK Request message
	to confirm the correct reception of the retransmitted fragments.		to confirm the correct reception of the retransmitted fragments.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6 (110), Seq=1----->|		|-----W=0, FCN=6 (110), Seq=1----->|
	|-----W=0, FCN=5 (101), Seq=2--X-->|		|-----W=0, FCN=5 (101), Seq=2--X-->|
	skipping to change at page 25, line 28 ¶		skipping to change at page 24, line 37 ¶
	|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0100001		|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0100001
	|-----W=0, FCN=5 (101), Seq=13---->|		|-----W=0, FCN=5 (101), Seq=13---->|
	|-----W=0, FCN=3 (011), Seq=14---->|		|-----W=0, FCN=3 (011), Seq=14---->|
	|-----W=0, FCN=0 (000), Seq=15---->|		|-----W=0, FCN=0 (000), Seq=15---->|
	|-----W=1, FCN=6 (110), Seq=16---->|		|-----W=1, FCN=6 (110), Seq=16---->|
	|-----W=1, FCN=4 (011), Seq=17---->| All fragments received		|-----W=1, FCN=4 (011), Seq=17---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=18---->|		DL enable |-----W=1, FCN=7 (111), Seq=18---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on
	and Second Windows (1)		First and Second Windows (1)
	Similar case as above, but with less fragments in the second window		Similar case as above, but with less fragments in the second window
	(W=1)		(W=1)
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6 (110), Seq=1----->|		|-----W=0, FCN=6 (110), Seq=1----->|
	|-----W=0, FCN=5 (101), Seq=2--X-->|		|-----W=0, FCN=5 (101), Seq=2--X-->|
	|-----W=0, FCN=4 (100), Seq=3----->|		|-----W=0, FCN=4 (100), Seq=3----->|
	|-----W=0, FCN=3 (011), Seq=4--X-->|		|-----W=0, FCN=3 (011), Seq=4--X-->|
	|-----W=0, FCN=2 (010), Seq=5----->|		|-----W=0, FCN=2 (010), Seq=5----->|
	|-----W=0, FCN=1 (001), Seq=6----->|		|-----W=0, FCN=1 (001), Seq=6----->|
	skipping to change at page 26, line 24 ¶		skipping to change at page 25, line 24 ¶
	DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4		DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4
	|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001		|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001
	|-----W=0, FCN=5 (101), Seq=10---->|		|-----W=0, FCN=5 (101), Seq=10---->|
	|-----W=0, FCN=3 (011), Seq=11---->|		|-----W=0, FCN=3 (011), Seq=11---->|
	|-----W=0, FCN=0 (000), Seq=12---->|		|-----W=0, FCN=0 (000), Seq=12---->|
	|-----W=1, FCN=6 (110), Seq=13---->| All fragments received		|-----W=1, FCN=6 (110), Seq=13---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=14---->|		DL enable |-----W=1, FCN=7 (111), Seq=14---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on
	and Second Windows (2)		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----->|
	skipping to change at page 28, line 24 ¶		skipping to change at page 27, line 5 ¶
	|-----W=1, FCN=6 (110), Seq=8--X-->|		|-----W=1, FCN=6 (110), Seq=8--X-->|
	DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4		DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4
	|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001		|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001
	|-----W=0, FCN=5 (101), Seq=10---->|		|-----W=0, FCN=5 (101), Seq=10---->|
	|-----W=0, FCN=3 (011), Seq=11---->|		|-----W=0, FCN=3 (011), Seq=11---->|
	|-----W=1, FCN=6 (110), Seq=12---->| All fragments received		|-----W=1, FCN=6 (110), Seq=12---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=13---->|		DL enable |-----W=1, FCN=7 (111), Seq=13---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 29: UL ACK-on-Error Fragments Lost on First and Second Windows		Figure 29: UL ACK-on-Error Fragments Lost on First and Second
	with one Compound ACK		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.
	4.3. SCHC Abort Examples		4.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. This may happen, for example, if the All-1 has been
	skipping to change at page 31, line 21 ¶		skipping to change at page 29, line 18 ¶
	The authors would like to thank Clement Mannequin, Rafael Vidal,		The authors would like to thank Clement Mannequin, Rafael Vidal,
	Julien Boite, Renaud Marty, and Antonis Platis for their useful		Julien Boite, Renaud Marty, and Antonis Platis for their useful
	comments and implementation design considerations.		comments and implementation design considerations.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-lpwan-schc-compound-ack]		[I-D.ietf-lpwan-schc-compound-ack]
	Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,		Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,
	Cespedes, S., and D. Wistuba, "SCHC Compound ACK", draft-		Cespedes, S., and D. Wistuba, "SCHC Compound ACK", Work in
	ietf-lpwan-schc-compound-ack-00 (work in progress), July		Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
	2021.		ack-00, July 2021, <http://www.ietf.org/internet-drafts/
			draft-ietf-lpwan-schc-compound-ack-00.txt>.
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	[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>.
	skipping to change at page 32, line 4 ¶		skipping to change at page 29, line 45 ¶
	[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-spec]		[sigfox-spec]
	Sigfox, "Sigfox Radio Specifications",		Sigfox, "Sigfox Radio Specifications",
	<https://build.sigfox.com/sigfox-device-radio-		<https://build.sigfox.com/sigfox-device-radio-
	specifications>.		specifications>.
	Authors' Addresses		Authors' Addresses
	Juan Carlos Zuniga
	SIGFOX		Juan Carlos Zúñiga
	Montreal QC		Montreal QC
	Canada		Canada
			Email: j.c.zuniga@ieee.org
	Email: JuanCarlos.Zuniga@sigfox.com
	URI: http://www.sigfox.com/
	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: carlesgo@entel.upc.edu		Email: carlesgo@entel.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		2 rue de la Chataigneraie
	CS 17607		CS 17607
	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 Cespedes
	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: scespedes@niclabs.cl		Email: scespedes@niclabs.cl
	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: wistuba@niclabs.cl
			Julien Boite
			SIGFOX
			Labege
			France
			Email: julien.boite@sigfox.com
			URI: http://www.sigfox.com/
End of changes. 97 change blocks.
	145 lines changed or deleted		162 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/