< draft-ietf-lpwan-schc-over-sigfox-05.txt		draft-ietf-lpwan-schc-over-sigfox-06.txt >
	lpwan Working Group JC. Zuniga		lpwan Working Group JC. Zuniga
	Internet-Draft SIGFOX		Internet-Draft SIGFOX
	Intended status: Informational C. Gomez		Intended status: Standards Track C. Gomez
	Expires: August 26, 2021 S. Aguilar		Expires: December 13, 2021 S. Aguilar
	Universitat Politecnica de Catalunya		Universitat Politecnica 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
	February 22, 2021		June 11, 2021
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-05		draft-ietf-lpwan-schc-over-sigfox-06
	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 46 ¶
	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 August 26, 2021.		This Internet-Draft will expire on December 13, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCHC: Generic Framework for Static Context Header Compression		3. SCHC: Generic Framework for Static Context Header Compression
	and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3		and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3
	4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3		4.1. Network Architecture . . . . . . . . . . . . . . . . . . 4
	4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7		4.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7
	4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7		4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
	4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7		4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8
	4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8		4.6.1. SCHC Compound ACK . . . . . . . . . . . . . . . . . . 8
	4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11		4.6.2. Uplink Fragmentation . . . . . . . . . . . . . . . . 9
	4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.6.3. Downlink Fragmentation . . . . . . . . . . . . . . . 12
	5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 12		4.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 13
	5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 12		4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 13
	5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 13		4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 17
	5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 19		4.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Security considerations . . . . . . . . . . . . . . . . . . . 21		5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21
	8.1. Normative References . . . . . . . . . . . . . . . . . . 21		5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28
	8.2. Informative References . . . . . . . . . . . . . . . . . 22		6. Security considerations . . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
			8.1. Normative References . . . . . . . . . . . . . . . . . . 31
			8.2. Informative References . . . . . . . . . . . . . . . . . 31
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	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) an application header compression scheme, and ii) a		mechanisms: i) an application header compression scheme, and ii) a
	frame fragmentation and loss recovery functionality. Both can be		frame fragmentation and loss recovery functionality. Either can be
	used on top of all the four LWPAN technologies defined in [RFC8376] .		used 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
	applications, etc.		applications, etc.
	SCHC offers a great level of flexibility to accommodate all these		SCHC offers a great level of flexibility to accommodate all these
	LPWAN technologies. Even though there are a great number of		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 on top of a specific LPWAN technology.		is used on top of a specific LPWAN technology.
	This document describes the recommended parameters, settings and		This document describes the recommended parameters, settings, and
	modes of operation to be used when SCHC is implemented over a Sigfox		modes of operation to be used when SCHC is implemented over a Sigfox
	LPWAN. This set of parameters are also known as a "SCHC over Sigfox		LPWAN. This set of parameters are also known as a "SCHC over Sigfox
	profile."		profile."
	2. Terminology		2. Terminology
	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].		mechanisms defined in [RFC8376] and in [RFC8724].
	3. SCHC: Generic Framework for Static Context Header Compression and		3. SCHC: Generic Framework for Static Context Header Compression and
	skipping to change at page 3, line 41 ¶		skipping to change at page 4, line 4 ¶
	predictability of data flows existing in LPWAN applications to avoid		predictability of data flows existing in LPWAN applications to avoid
	context synchronization.		context synchronization.
	Contexts must be stored and pre-configured on both ends. This can be		Contexts must be stored and pre-configured on both ends. This can be
	done either by using a provisioning protocol, by out of band means,		done either by using a provisioning protocol, by out of band means,
	or by pre-provisioning them (e.g. at manufacturing time). The way		or by pre-provisioning them (e.g. at manufacturing time). The way
	contexts are configured and stored on both ends is out of the scope		contexts are configured and stored on both ends is out of the scope
	of this document.		of this document.
	4. SCHC over Sigfox		4. SCHC over Sigfox
	4.1. Network Architecture		4.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 (RG) is a Sigfox Base		defined in [RFC8376], where the Radio Gateway (RG) 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.
	Device Application		Sigfox Device Application
	+----------------+ +--------------+		+----------------+ +--------------+
	| APP1 APP2 APP3 | |APP1 APP2 APP3|		| APP1 APP2 APP3 | |APP1 APP2 APP3|
	+----------------+ +--------------+		+----------------+ +--------------+
	| UDP | | | | UDP |		| UDP | | | | UDP |
	| IPv6 | | | | IPv6 |		| IPv6 | | | | IPv6 |
	+--------+ | | +--------+		+--------+ | | +--------+
	| SCHC C/D & F/R | | |		| SCHC C/D & F/R | | |
	| | | |		| | | |
	+-------+--------+ +--------+-----+		+-------+--------+ +--------+-----+
	$ .		$ .
	$ +---------+ +--------------+ +---------+ .		$ +---------+ +--------------+ +---------+ .
	$ | | | | | Network | .		$ | | | | | Network | .
	+~~ |Sigfox BS| |Sigfox Network| | SCHC | .		+~~ |Sigfox BS| |Sigfox Network| | SCHC | .
	| (RG) | === | (NGW) | === |F/R & C/D|.....		| (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
	Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base		Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base
	Stations, which then forward the SCHC Message to the Network Gateway		Stations, which then forward the SCHC Message to the Network Gateway
	(NGW). The NGW then delivers the SCHC Message and associated		(NGW). The NGW then delivers the SCHC Message and associated
	gathered metadata to the Network SCHC C/D + F/R.		gathered metadata to the Network SCHC C/D + F/R.
	The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R		The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R
	for compression/decompression and/or for fragmentation/reassembly.		for compression/decompression and/or for fragmentation/reassembly.
	The Network SCHC C/D + F/R share the same set of rules as the Dev		The Network SCHC C/D + F/R shares the same set of rules as the Dev
	SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with		SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with
	the NGW or it could be located in a different place, as long as a		the NGW or it could be located in a different place, as long as a
	tunnel or secured communication is established between the NGW and		tunnel or secured communication is established between the NGW and
	the SCHC C/D + F/R functions. After decompression and/or reassembly,		the SCHC C/D + F/R functions. After decompression and/or reassembly,
	the packet can be forwarded over the Internet to one (or several)		the packet can be forwarded over the Internet to one (or several)
	LPWAN Application Server(s) (App).		LPWAN Application Server(s) (App).
	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).
	4.2. Uplink		4.2. Uplink
	Uplink Sigfox transmissions occur in repetitions over different times		Uplink Sigfox transmissions occur in repetitions over different times
	and frequencies. Besides these time and frequency diversities, the		and frequencies. Besides time and frequency diversities, the Sigfox
	Sigfox network also provides space diversity, as potentially an		network also provides space diversity, as potentially an uplink
	uplink message will be received by several base stations.		message will be received by several base stations.
	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 Core Network, multiple input copies		these messages back to the same Sigfox Network, multiple input copies
	can be combined at the NGW and hence provide for extra reliability		can be combined at the NGW providing for extra reliability based on
	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		o Device ID
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 34 ¶
	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).
	4.3. Downlink		4.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
	willing to receive a downlink message indicates explicitly its		explicitly indicates its intention to receive a downlink message
	intention to the network in the preceding uplink message with a		using a donwlink request flag when sending the preceding uplink
	downlink request flag, and then it opens a fixed window for downlink		message to the network. After completing the uplink transmission,
	reception after completing the uplink transmission. The delay and		the Device opens a fixed window for downlink reception. The delay
	duration of the reception opportunity window have fixed values. If		and duration of the reception opportunity window have fixed values.
	there is a downlink message to be sent for this given Device (e.g.		If there is a downlink message to be sent for this given Device (e.g.
	either a response to the uplink message or queued information waiting		either a response to the uplink message or queued information waiting
	to be transmitted), the network transmits it to the Device during the		to be transmitted), the network transmits this message to the Device
	reception window. If no message is received by the Device after the		during the reception window. If no message is received by the Device
	reception opportunity window has elapsed, the Device closes the		after the reception opportunity window has elapsed, the Device closes
	receiving opportunity and gets back to the normal mode (e.g. continue		the reception window opportunity and gets back to the normal mode
	UL transmissions, sleep, stand-by, etc.)		(e.g., continue UL transmissions, sleep, stand-by, 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 back to the Network		acknowledgement is generated by the Device and sent back to the
	through the Sigfox protocol and reported by the Sigfox Network. This		Network through the Sigfox radio protocol and reported in the Sigfox
	acknowledgement can be retrieved through callbacks by the customer.		Network 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/APIs
	can be found in [sigfox-callbacks].		can be found in [sigfox-callbacks].
	4.4. SCHC-ACK on Downlink		4.4. SCHC-ACK on Downlink
	As explained previously, downlink transmissions are Device-driven and		As explained previously, downlink transmissions are Device-driven and
	can only take place following a specific uplink transmission that		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
	skipping to change at page 7, line 46 ¶		skipping to change at page 8, line 9 ¶
	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.
	4.6. Fragmentation		4.6. 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 data frame. The functionality also		the maximum size of a Sigfox payload. The functionality also defines
	defines a mechanism to send reliably multiple messages, by allowing		a mechanism to send reliably multiple messages, by allowing to resend
	to resend selectively any lost fragments.		selectively 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
	skipping to change at page 8, line 23 ¶		skipping to change at page 8, line 35 ¶
	Section 4.2), integrity can be guaranteed when no consecutive		Section 4.2), integrity can be guaranteed when no consecutive
	messages are missing from the sequence and all FCN bitmaps are		messages are missing from the sequence and all FCN bitmaps are
	complete. In order to support multiple flows/RuleIDs (potentially		complete. In order to support multiple flows/RuleIDs (potentially
	interleaved), the implementation of a central message sequence		interleaved), the implementation of a central message sequence
	counter at the Network SCHC C/D + F/R is required. With this		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		functionality and in order to save protocol overhead, the use of a
	dedicated Reassembly Check Sequence (RCS) is NOT RECOMMENDED.		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).
	4.6.1. Uplink Fragmentation		4.6.1. SCHC Compound ACK
	Sigfox uplink transmissions are completely asynchronous and can take		The present SCHC over Sigfox specification extends SCHC ACK format
			defined in [RFC8724] with the SCHC Compound ACK concept.
			The SCHC Compound ACK is a SCHC ACK message that can contain several
			bitmaps, each bitmap being identified by its corresponding window
			number. The SCHC Compound ACK concept is meant to reduce the number
			of downlink transmissions (i.e., SCHC ACKs) by including bitmaps of
			several windows in a single SCHC message (i.e., the SCHC Compound
			ACK), and hence making an efficient use of downlink channel
			transmissions.
			When the ACK-on-Error mode is used for uplink fragmentation, SCHC
			Compound ACKs MUST be used in the downlink responses.
			The SCHC Compound ACK:
			o provides feedback only for windows with fragment losses,
			o has a variable size that depends on the number of windows with
			fragment losses being reported in the single Compound SCHC ACK,
			o includes the window number (i.e., W) for each bitmap,
			o has a format coincident with that of a SCHC ACK (RFC 8724) when
			only one window with losses is reported,
			o might not cover all windows with fragment losses of a SCHC Packet,
			o is distinguishable from the SCHC Receiver-Abort.
			The SCHC Compound ACK groups the window number (W) with its
			corresponding bitmap. The included window numbers and corresponding
			bitmap MUST be ordered from the lowest-numbered to the highest-
			numbered window.
			4.6.2. Uplink Fragmentation
			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. Hence, devices can go to deep sleep mode, and then wake		allocation. In addition, devices may go to deep sleep mode, and then
	up and transmit whenever there is a need to send any information to		wake up and transmit whenever there is a need to send information to
	the network. In that way, there is no need to perform any network		the network. Data packets are self-contained (aka "message in a
	attachment, synchronization, or other procedure before transmitting a
	data packet. All data packets are self-contained (aka "message in a
	bottle") with all the required information for the network to process		bottle") with all the required information for the network to process
	them accordingly.		them accordingly. Hence, there is no need to perform any network
			attachment, synchronization, or other procedure before transmitting a
			data packet.
	Since uplink transmissions occur asynchronously, an SCHC fragment can		Since uplink transmissions are asynchronous, a SCHC fragment can be
	be transmitted at any given time by the Device. Sigfox uplink		transmitted at any given time by the Device. Sigfox uplink messages
	messages are fixed in size, and as described in [RFC8376] they can		are fixed in size, and as described in [RFC8376] they can carry 0-12
	carry 0-12 bytes payload. Hence, a single SCHC Tile size per		bytes payload. Hence, a single SCHC Tile size per fragmentation mode
	fragmentation mode can be defined so that every Sigfox message always		can be defined so that every Sigfox message always carries one SCHC
	carries one SCHC Tile.		Tile.
	4.6.1.1. Uplink No-ACK Mode		4.6.2.1. Uplink No-ACK Mode
	No-ACK is RECOMMENDED to be used for transmitting short, non-critical		No-ACK is RECOMMENDED to be used for transmitting short, non-critical
	packets that require fragmentation and do not require full		packets that require fragmentation and do not require full
	reliability. This mode can be used by uplink-only devices that do		reliability. This mode can be used by uplink-only devices that do
	not support downlink communications, or by bidirectional devices when		not support downlink communications, or by bidirectional devices when
	they send non-critical data.		they send non-critical data.
	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 is RECOMMENDED to use the FCN field to		not present. However it is RECOMMENDED to use the FCN field to
	indicate the size of the data packet. In this sense, the data packet		indicate the size of the data packet. In this sense, the data packet
	skipping to change at page 9, line 28 ¶		skipping to change at page 10, line 28 ¶
	o DTag size (T): 0 bits		o DTag size (T): 0 bits
	o Fragment Compressed Number (FCN) size (N): 4 bits		o Fragment Compressed Number (FCN) size (N): 4 bits
	o As per [RFC8724], in the No-ACK mode the W (window) field is not		o As per [RFC8724], in the No-ACK mode the W (window) field is not
	present.		present.
	o RCS size: 0 bits (Not used)		o RCS size: 0 bits (Not used)
	4.6.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header		4.6.2.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	ACK-on-Error with single-byte header is RECOMMENDED for medium-large		ACK-on-Error with single-byte header is RECOMMENDED for medium to
	size packets that need to be sent reliably. ACK-on-Error is optimal		large size packets that need to be sent reliably. ACK-on-Error is
	for Sigfox transmissions, since it leads to a reduced number of ACKs		optimal for Sigfox transmissions, since it leads to a reduced number
	in the lower capacity downlink channel. Also, downlink messages can		of ACKs in the lower capacity downlink channel. Also, downlink
	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		o Rule ID size: 3 bits
	o DTag size (T): 0 bits		o DTag size (T): 0 bits
	o Window index (W) size (M): 2 bits		o Window index (W) size (M): 2 bits
	skipping to change at page 10, line 15 ¶		skipping to change at page 11, line 15 ¶
	o Retransmission Timer: Application-dependent		o Retransmission Timer: Application-dependent
	o Inactivity Timer: Application-dependent		o Inactivity Timer: Application-dependent
	o RCS size: 0 bits (Not used)		o RCS size: 0 bits (Not used)
	The correspondent SCHC ACK in the downlink is 13 bits long, so		The correspondent SCHC ACK in the downlink is 13 bits long, so
	padding is needed to complete the required 64 bits of Sigfox payload.		padding is needed to complete the required 64 bits of Sigfox payload.
	4.6.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header		4.6.2.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header
	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 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:
	skipping to change at page 11, line 5 ¶		skipping to change at page 12, line 5 ¶
	o Retransmission Timer: Application-dependent		o Retransmission Timer: Application-dependent
	o Inactivity Timer: Application-dependent		o Inactivity Timer: Application-dependent
	o RCS size: 0 bits (Not used)		o RCS size: 0 bits (Not used)
	The correspondent SCHC ACK in the downlink is 43 bits long, so		The correspondent SCHC ACK in the downlink is 43 bits long, so
	padding is needed to complete the required 64 bits of Sigfox payload.		padding is needed to complete the required 64 bits of Sigfox payload.
	4.6.1.4. All-1 behaviour + Sigfox Sequence Number		4.6.2.4. All-1 behaviour + Sigfox Sequence Number
	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		However, since a Message Sequence Number is provided by the Sigfox
	protocol together with the Sigfox Payload, the receiver can detect if		protocol together with the Sigfox Payload, the receiver can detect if
	there are missing fragments before the All-1 and hence construct the		there are missing fragments before the All-1 and hence construct the
	corresponding SCHC ACK Bitmap accordingly.		corresponding SCHC ACK Bitmap accordingly.
	4.6.2. Downlink Fragmentation		4.6.3. 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
	skipping to change at page 12, line 20 ¶		skipping to change at page 13, line 20 ¶
	o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)		o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	o Tile size: 7 bytes		o Tile size: 7 bytes
	o Retransmission Timer: Application-dependent		o Retransmission Timer: Application-dependent
	o Inactivity Timer: Application-dependent		o Inactivity Timer: Application-dependent
	o RCS size: 0 bits (Not used)		o RCS size: 0 bits (Not used)
	4.7. Padding		4.7. SCHC-over-Sigfox F/R Message Formats
			This section depicts the different formats of SCHC Fragment, SCHC ACK
			(including the SCHC Compound ACK defined in Section 4.6.1), and SCHC
			Abort used in SCHC over Sigfox.
			4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header
			4.7.1.1. Regular SCHC Fragment
			Figure 3 shows an example of a regular SCHC fragment for all
			fragments except the last one. As tiles are of 11 bytes, padding
			MUST NOT be added.
			|-- SCHC Fragment Header --|
			+ ------------------------ + ------- +
			| RuleID | W | FCN | Payload |
			+ ------ + ------ + ------ + ------- +
			| 3 bits | 2 bits | 3 bits | 88 bits |
			Figure 3: Regular SCHC Fragment format for all fragments except the
			last one
			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
			(Network SCHC). As per [RFC8724], the All-0 message is
			distinguishable from the SCHC ACK REQ (All-1 message). The
			penultimate tile of a SCHC Packet is of regular size.
			4.7.1.2. All-1 SCHC Fragment
			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
			of at least 1 byte (one L2 word). Padding MUST NOT be added, as the
			resulting size is L2-word-multiple.
			|--- SCHC Fragment Header ---|
			+ --------------------------- + ------------ +
			| RuleID | W | FCN=ALL-1 | Payload |
			+ ------ + ------ + --------- + ------------ +
			| 3 bits | 2 bits | 3 bits | 8 to 88 bits |
			Figure 4: All-1 SCHC Message format with last tile
			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
			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
			no padding bits.
			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
			no padding). This way, the minimum size of the All-1 is 2 bytes, and
			the Sender-Abort message is 1 byte.
			4.7.1.3. SCHC ACK Format
			Figure 5 shows the SCHC ACK format when all fragments have been
			correctly received (C=1). Padding MUST be added to complete the
			64-bit Sigfox downlink frame payload size.
			|---- SCHC ACK Header ----|
			+ ----------------------- + ------- +
			| RuleID | W | C=b'1 | b'0-pad |
			+ ------ + ------ + ----- + ------- +
			| 3 bits | 2 bits | 1 bit | 58 bits |
			Figure 5: SCHC Success ACK message format
			In case SCHC fragment losses are found in any of the windows of the
			SCHC Packet (C=0), the SCHC Compound ACK MUST be used. The SCHC
			Compound ACK message format is shown in Figure 6. The window
			numbered 00, if present in the SCHC Compound ACK, MUST be placed
			between the Rule ID and the C bit to avoid confusion with padding
			bits. If padding is needed for the SCHC Compound ACK, padding bits
			MUST be 0 to make subsequent window numbers and bitmaps
			distinguishable.
			|---- SCHC ACK Header ----|-W = x -|...| --- W = x + i ---|
			+ ----------------------- + ------ +...+ ------- + ------ + ------- +
			| 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 |
			On top are noted the window number of the corresponding bitmap.
			Losses are found in windows x,...,x+i.
			Figure 6: SCHC Compound ACK message format
			The following figures show examples of the Compound ACK message
			format.
			|---- SCHC ACK Header ----|- W=00 -|----- W=01 ------|
			+ ----------------------- + ------ + ------ + ------ + ------- +
			| 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 |
			Losses are found in windows 00 and 01.
			Figure 7: SCHC Compound ACK example 1
			|---- SCHC ACK Header ----|- W=01 -|----- W=11 ------|
			+ ----------------------- + ------ + ------ + ------ + ------- +
			| RuleID | W=b'01 | C=b'0 | Bitmap | W=b'11 | Bitmap | b'0-pad |
			+ ------ + ------ + ----- + ------ + ------ + ------ + ------- +
			| 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits |
			Losses are found in windows 01 and 11.
			Figure 8: SCHC Compound ACK example 2
			|---- SCHC ACK Header ----|- W=00 -|----- W=10 ------|
			+ ----------------------- + ------ + ------ + ------ + ------- +
			| RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad |
			+ ------ + ------ + ----- + ------ + ------ + ------ + ------- +
			| 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits |
			Losses are found in windows 00 and 10.
			Figure 9: SCHC Compound ACK example 3
			Figure 10 shows the Compound ACK message format when losses are found
			in all windows. The window numbers and its corresponding bitmaps are
			ordered from window numbered 00 to 11, notifying all four possible
			windows.
			|- SCHC ACK Header -|W=b'00|-- W=b'01 ---|
			+-------------------+------+ ---- +------+
			|RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ...
			+------+------+-----+------+------+------+
			|3 bits|2 bits|1 bit|7 bits|2 bits|7 bits|
			|--- W=b'10 --|--- W=b'11 --|
			|------+------+------+------+-------+
			... |W=b'10|Bitmap|W=b'11|Bitmap|b'0-pad|
			|------+------+------+------+-------+
			|2 bits|7 bits|2 bits|7 bits|24 bits|
			Losses are found in windows 00, 01, 10 and 11.
			Figure 10: SCHC Compound ACK example 4
			|- 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|
			+------+------+-----+------+------+------+------+------+-------+
			|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.
			Figure 11: SCHC Compound ACK example 5
			4.7.1.4. SCHC Sender-Abort Message format
			|---- Sender-Abort Header ----|
			+ --------------------------- +
			| RuleID | W | FCN=ALL-1 |
			+ ------ + ------ + --------- +
			| 3 bits | 2 bits | 3 bits |
			Figure 12: SCHC Sender-Abort message format
			4.7.1.5. SCHC Receiver-Abort Message format
			|- Receiver-Abort Header -|
			+ ----------------------- + ------- +
			| RuleID | W=b'11 | C=b'1 | b'1-pad |
			+ ------ + ------ + ----- + ------- +
			| 3 bits | 2 bits | 1 bit | 58 bits |
			Figure 13: SCHC Receiver-Abort message format
			4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header
			4.7.2.1. Regular SCHC Fragment
			Figure 14 shows an example of a regular SCHC fragment for all
			fragments except the last one. The penultimate tile of a SCHC Packet
			is of the regular size.
			|-- SCHC Fragment Header --|
			+ ------------------------ + ------- +
			| RuleID | W | FCN | Payload |
			+ ------ + ------ + ------ + ------- +
			| 8 bits | 3 bits | 5 bits | 80 bits |
			Figure 14: Regular SCHC Fragment format for all fragments except the
			last one
			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
			(Network SCHC). As per [RFC8724], the All-0 message is
			distinguishable from the SCHC ACK REQ (All-1 message).
			4.7.2.2. All-1 SCHC Fragment
			Figure 15 shows an example of the All-1 message. The All-1 message
			MUST contain the last tile of the SCHC Packet.
			|--- SCHC Fragment Header ---|
			+ --------------------------- + ------------ +
			| RuleID | W | FCN=ALL-1 | Payload |
			+ ------ + ------ + --------- + ------------ +
			| 8 bits | 3 bits | 5 bits | 8 to 80 bits |
			Figure 15: All-1 SCHC message format with last tile
			As per [RFC8724] the All-1 must be distinguishable from the a SCHC
			Sender-Abort message (with same Rule ID, M and N values). The All-1
			MUST have the last tile of the SCHC Packet, that MUST be of at least
			1 byte. The SCHC Sender-Abort message header size is of 2 byte, with
			no padding bits.
			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
			no padding). This way, the minimum size of the All-1 is 3 bytes, and
			the Sender-Abort message is 2 bytes.
			4.7.2.3. SCHC ACK Format
			Figure 16 shows the SCHC ACK format when all fragments have been
			correctly received (C=1). Padding MUST be added to complete the
			64-bit Sigfox downlink frame payload size.
			|----- SCHC ACK Header ----|
			+ ------------------------ + ------ +
			| RuleID | W | C=b'1 | b'0-pad |
			+ ------ + ------ + ----- + ------- +
			| 8 bits | 3 bits | 1 bit | 52 bits |
			Figure 16: SCHC Success ACK message format
			The SCHC Compound ACK message MUST be used in case SCHC fragment
			losses are found in any window of the SCHC Packet (C=0). The SCHC
			Compound ACK message format is shown in Figure 17. The SCHC Compound
			ACK can report up to 3 windows with losses. The window number (W)
			and its corresponding bitmap MUST be ordered from the lowest-numbered
			window number to the highest-numbered window. If window numbered 000
			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
			bits. The SCHC Compound ACK MUST be 0 padded (Padding bits must be
			0).
			|- 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|
			+------+------+-----+-------+...|-------+-------+-------+
			|8 bits|3 bits|1 bit|15 bits| | 3 bits|15 bits|
			On top are noted the window number
			of the corresponding bitmap.
			Losses are found in windows x,...,x+i.
			Figure 17: SCHC Compound ACK message format
			4.7.2.4. SCHC Sender-Abort Messages
			|---- Sender-Abort Header ----|
			+ --------------------------- +
			| RuleID | W | FCN=ALL-1 |
			+ ------ + ------ + --------- +
			| 8 bits | 3 bits | 5 bits |
			Figure 18: SCHC Sender-Abort message format
			4.7.2.5. SCHC Receiver-Abort Message
			|-- Receiver-Abort Header -|
			+ ------------------------ + ------- +
			| RuleID | W=b'111 | C=b'1 | b'1-pad |
			+ ------ + ------- + ----- + ------- +
			| 8 bits | 3 bits | 1 bit | 52 bits |
			Figure 19: SCHC Receiver-Abort message format
			4.8. 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
	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		Downlink frames on the other hand 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 would be necessary.		bits are to be transmitted, padding MUST be used with bits equal to
			0.
	5. Fragmentation Sequence Examples		5. Fragmentation Sequence Examples
	In this section, some sequence diagrams depicting messages exchanges		In this section, some sequence diagrams depicting messages exchanges
	for different fragmentation modes and use cases are shown. In the		for 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
	skipping to change at page 13, line 17 ¶		skipping to change at page 20, line 45 ¶
	Sender Receiver		Sender Receiver
	|-------FCN=6 (0110), Seq=1-------->|		|-------FCN=6 (0110), Seq=1-------->|
	|-------FCN=5 (0101), Seq=2-------->|		|-------FCN=5 (0101), Seq=2-------->|
	|-------FCN=4 (0100), Seq=3-------->|		|-------FCN=4 (0100), Seq=3-------->|
	|-------FCN=3 (0011), Seq=4-------->|		|-------FCN=3 (0011), Seq=4-------->|
	|-------FCN=2 (0010), Seq=5-------->|		|-------FCN=2 (0010), Seq=5-------->|
	|-------FCN=1 (0001), Seq=6-------->|		|-------FCN=1 (0001), Seq=6-------->|
	|-------FCN=15 (1111), Seq=7------->| All fragments received		|-------FCN=15 (1111), Seq=7------->| All fragments received
	(End)		(End)
	Figure 3: UL No-ACK No-Losses		Figure 20: UL 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 more 6 messages (with FCN going from 5 downward,		receiver can expect six more messages/fragments (i.e., with FCN going
	and the last with a FCN equal to 15).		from 5 downwards, and the last fragment with a 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 4: UL No-ACK Losses (scenario 1)		Figure 21: UL 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 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 14, line 21 ¶		skipping to change at page 22, line 21 ¶
	|-----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 5: UL ACK-on-Error No-Losses		Figure 22: UL ACK-on-Error No-Losses
	Case Fragments lost in first window		Case Fragments lost 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 an ACK with the corresponding bitmap and C=0.		opportunity and sends an ACK with the corresponding bitmap and C=0.
	After the missing fragments from the first window (W=0) are resent,		After the missing fragments from the first window (W=0) are resent,
	the sender without opening a reception window, continues transmitting		the sender continues transmitting the fragments of the following
	the following window. Finally, the All-1 fragment is sent, the		window (W=1) without opening a reception opportunity. Finally, the
	downlink is enabled and the ACK received with a C=1.		All-1 fragment is sent, the downlink is enabled, and the ACK is
			received with C=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----->|		|-----W=0, FCN=3, Seq=4----->|
	|-----W=0, FCN=2, Seq=5--X-->|		|-----W=0, FCN=2, Seq=5--X-->|
	|-----W=0, FCN=1, Seq=6----->|		|-----W=0, FCN=1, Seq=6----->|
	DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5		DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5
	|<------ 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----->|
	(no ACK)
	|-----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 6: UL ACK-on-Error Losses on First Window		Figure 23: UL ACK-on-Error Losses on First Window
	Case Fragments All-0 lost in first window (W=0)		Case Fragments 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-X message to generate		Therefore, the Receiver waits for the next All-X message to generate
	the corresponding ACK, notifying the absence of the All-0 of window		the corresponding 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
	fragment from window 0). Note that this behaviour can take place in		fragment from window 0). Note that this behaviour can take place in
	any intermediate window if the All-0 message is lost.		any intermediate window if the All-0 message is lost.
	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
	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=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
	DL Enable |-----W=0, FCN=0, Seq=12---->| All fragments received		|-----W=0, FCN=0, Seq=13---->| All fragments received
			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 7: 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 lost		In the following diagram, besides the All-0 there are other lost
	fragments in the first window (W=0).		fragments 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-->|
	(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---->| 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=12---->|		|-----W=0, FCN=5, Seq=13---->|
	|-----W=0, FCN=3, Seq=13---->|		|-----W=0, FCN=3, Seq=14---->|
	DL Enable |-----W=0, FCN=0, Seq=14---->| All fragments received		|-----W=0, FCN=0, Seq=15---->| All fragments received
			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 8: 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 First
	Window		Window
	In the following case, there are losses in both the first (W=0) and		In the next examples, there are losses in both the first (W=0) and
	second (W=1) window. The retransmission cycles (after the All-1 is		second (W=1) windows. The retransmission cycles after the All-1 is
	sent, not in intermediate windows) should always finish with an All-0		sent (i.e., not in intermediate windows) should always finish with an
	(if this message was lost) or with an All-1. This is required for		with an All-1. In case an intermediate All-0 is lost and then
	the sender to open a reception window so the receiver can send an		retransmitted, the All-1 is resent after, as it serves as an ACK
	ACK. Else, there is no way for the Receiver to send an ACK, if All-1		Request message to confirm the correct reception of the retransmitted
	message is lost, then an ACK timeout happen and an ACK is resent.		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-->|
	|-----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----->|
	DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|		DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|
	(no ACK)		(no ACK)
	|-----W=1, FCN=6 (110), Seq=8--X-->|		|-----W=1, FCN=6 (110), Seq=8--X-->|
	|-----W=1, FCN=5 (101), Seq=9----->|		|-----W=1, FCN=5 (101), Seq=9----->|
	|-----W=1, FCN=4 (011), Seq=10-X-->|		|-----W=1, FCN=4 (011), Seq=10-X-->|
	DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0		DL enable |-----W=1, FCN=7 (111), 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 (101), Seq=12---->|		|-----W=0, FCN=5 (101), Seq=13---->|
	|-----W=0, FCN=3 (011), Seq=13---->|		|-----W=0, FCN=3 (011), Seq=14---->|
	DL enable |-----W=0, FCN=0 (000), Seq=14---->| Missing Fragment W=1 => FCN= 6 and 4		|-----W=0, FCN=0 (000), Seq=15---->|
			DL enable |-----W=1, FCN=7 (111), Seq=16---->| Missing Fragment W=1 => FCN= 6 and 4
	|<--------- ACK, W=1, C=0 ---------| Bitmap:0100001		|<--------- ACK, W=1, C=0 ---------| Bitmap:0100001
	|-----W=1, FCN=6 (110), Seq=15---->|		|-----W=1, FCN=6 (110), Seq=18---->|
	|-----W=1, FCN=4 (011), Seq=16---->| All fragments received		|-----W=1, FCN=4 (011), Seq=19---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=17---->|		DL enable |-----W=1, FCN=7 (111), Seq=20---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 9: UL ACK-on-Error All-0 and other Fragments Lost on First and		Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First
	Second Windows (1)		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----->|
	DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|		DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|
	(no ACK)		(no ACK)
	|-----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		DL enable |-----W=1, FCN=7 (111), Seq=9----->| 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 (101), Seq=10---->|		|-----W=0, FCN=5 (101), Seq=10---->|
	|-----W=0, FCN=3 (011), Seq=11---->|		|-----W=0, FCN=3 (011), Seq=11---->|
	DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4		DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4
	|<--------- ACK, W=1, C=0 ---------| Bitmap:0000001		|<--------- ACK, W=1, C=0 ---------| Bitmap:0000001
	|-----W=1, FCN=6 (110), Seq=15---->| All fragments received		|-----W=1, FCN=6 (110), Seq=15---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=17---->|		DL enable |-----W=1, FCN=7 (111), Seq=17---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 10: 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 First
	and Second Windows (2)		and Second Windows (2)
	Case ACK is lost		Case 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 an ACK, when		Instead it uses the SCHC All-1 message to request an 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
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK		DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 11: UL ACK-on-Error ACK Lost		Figure 28: UL ACK-on-Error ACK Lost
	The number of times an ACK will be requested is determined by the		The number of times an ACK will be requested is determined by the
	MAX_ACK_REQUESTS.		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. This may happen, for example, if the All-1 has been
	skipping to change at page 20, line 32 ¶		skipping to change at page 29, line 32 ¶
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3)		DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4)		DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5)		DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |----Sender-Abort, Seq=19--->| exit with error condition		DL Enable |----Sender-Abort, Seq=19--->| exit with error condition
	(End)		(End)
	Figure 12: UL ACK-on-Error Sender-Abort		Figure 29: UL ACK-on-Error Sender-Abort
	Case Receiver-Abort		Case Receiver-Abort
	The reciever may need to send a Receiver-Abort to stop the current		The reciever may need to send a Receiver-Abort to stop the current
	communication. This message can only be sent after a DL enable.		communication. This message can only be sent after a DL 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 13: UL ACK-on-Error Receiver-Abort		Figure 30: UL 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-128
	based message authentication code, ensuring that the message has been		based message authentication code, ensuring that the message has been
	generated and sent by the device with the ID claimed in the message.		generated and sent by the device with the ID claimed in the message.
	Application data can be encrypted at the application level or not,		Application data can be encrypted at the application level or not,
	depending on the criticality of the use case. This flexibility		depending on the criticality of the use case. This flexibility
	skipping to change at page 21, line 37 ¶		skipping to change at page 31, line 5 ¶
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P		through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
	grant, and the PID2019-106808RA-I00 grant, and by Secretaria		grant, and the PID2019-106808RA-I00 grant, and by Secretaria
	d'Universitats i Recerca del Departament d'Empresa i Coneixement de		d'Universitats i Recerca del Departament d'Empresa i Coneixement de
	la Generalitat de Catalunya 2017 through grant SGR 376.		la Generalitat de Catalunya 2017 through grant SGR 376.
	Sergio Aguilar has been funded by the ERDF and the Spanish Government		Sergio Aguilar has been funded by the ERDF and the Spanish Government
	through project TEC2016-79988-P and project PID2019-106808RA-I00,		through project TEC2016-79988-P and project PID2019-106808RA-I00,
	AEI/FEDER, EU.		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 Clement Mannequin, Rafael Vidal and		The authors would like to thank Clement Mannequin, Rafael Vidal and
	Antonis Platis for their useful comments and implementation design		Antonis Platis for their useful comments and implementation design
	considerations.		considerations.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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,
End of changes. 58 change blocks.
	120 lines changed or deleted		446 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/