< draft-ietf-lpwan-schc-over-sigfox-06.txt		draft-ietf-lpwan-schc-over-sigfox-07.txt >
	lpwan Working Group JC. Zuniga		lpwan Working Group JC. Zuniga
	Internet-Draft SIGFOX		Internet-Draft SIGFOX
	Intended status: Standards Track C. Gomez		Intended status: Standards Track C. Gomez
	Expires: December 13, 2021 S. Aguilar		Expires: January 10, 2022 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
	June 11, 2021		July 9, 2021
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-06		draft-ietf-lpwan-schc-over-sigfox-07
	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 December 13, 2021.		This Internet-Draft will expire on January 10, 2022.
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCHC: Generic Framework for Static Context Header Compression		3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Network Architecture . . . . . . . . . . . . . . . . . . 4		3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7
	4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
	4.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7		3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7		3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8
	4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8		3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11
	4.6.1. SCHC Compound ACK . . . . . . . . . . . . . . . . . . 8		3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12
	4.6.2. Uplink Fragmentation . . . . . . . . . . . . . . . . 9		3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 12
	4.6.3. Downlink Fragmentation . . . . . . . . . . . . . . . 12		3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 16
	4.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 13		3.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 13		4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 19
	4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 17		4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 19
	4.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19		4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 20
	5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20		4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 27
	5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20		5. Security considerations . . . . . . . . . . . . . . . . . . . 29
	5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
	5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	6. Security considerations . . . . . . . . . . . . . . . . . . . 30		7.1. Normative References . . . . . . . . . . . . . . . . . . 30
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		7.2. Informative References . . . . . . . . . . . . . . . . . 30
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
	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) a frame fragmentation and loss recovery functionality,
	frame fragmentation and loss recovery functionality. Either can be		and ii) an application header compression scheme. Either can be used
	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
	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.
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 27 ¶
	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 over Sigfox
	Fragmentation
	The Generic Framework for Static Context Header Compression and		The Generic SCHC Framework described in [RFC8724] takes advantage of
	Fragmentation (SCHC) described in [RFC8724] takes advantage of the		the predictability of data flows existing in LPWAN applications to
	predictability of data flows existing in LPWAN applications to avoid		avoid context synchronization.
	context synchronization.
	Contexts must be stored and pre-configured on both ends. This can be		Contexts need to be stored and pre-configured on both ends. This can
	done either by using a provisioning protocol, by out of band means,		be done either by using a provisioning protocol, by out of band
	or by pre-provisioning them (e.g. at manufacturing time). The way		means, or by pre-provisioning them (e.g. at manufacturing time). The
	contexts are configured and stored on both ends is out of the scope		way contexts are configured and stored on both ends is out of the
	of this document.		scope of this document.
	4. SCHC over Sigfox		3.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.
	Sigfox Device Application		Sigfox Device Application
	+----------------+ +--------------+		+----------------+ +--------------+
	| APP1 APP2 APP3 | |APP1 APP2 APP3|		| APP1 APP2 APP3 | |APP1 APP2 APP3|
	skipping to change at page 5, line 13 ¶		skipping to change at page 5, line 5 ¶
	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		3.2. Uplink
	Uplink Sigfox transmissions occur in repetitions over different times		Uplink Sigfox transmissions occur in repetitions over different times
	and frequencies. Besides time and frequency diversities, the Sigfox		and frequencies. Besides time and frequency diversities, the Sigfox
	network also provides space diversity, as potentially an uplink		network also provides space diversity, as potentially an 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 Sigfox Network, multiple input copies		these messages back to the same Sigfox Network, multiple input copies
	can be combined at the NGW providing for extra reliability based on		can be combined at the NGW providing for extra reliability based on
	the triple diversity (i.e., time, space and frequency).		the triple diversity (i.e., time, space and frequency).
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 21 ¶
	+---------------+---------------- +		+---------------+---------------- +
	| 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).
	4.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
	using a donwlink request flag when sending the preceding uplink		using a donwlink request flag when sending the preceding uplink
	message to the network. After completing the uplink transmission,		message to the network. After completing the uplink transmission,
	the Device opens a fixed window for downlink reception. The delay		the Device opens a fixed window for downlink reception. The delay
	and duration of the reception opportunity window have fixed values.		and duration of the reception opportunity window have fixed values.
	If there is a downlink message to be sent for this given Device (e.g.		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
	skipping to change at page 7, line 11 ¶		skipping to change at page 7, line 5 ¶
	When a downlink message is sent to a Device, a reception		When a downlink message is sent to a Device, a reception
	acknowledgement is generated by the Device and sent back to the		acknowledgement is generated by the Device and sent back to the
	Network through the Sigfox radio protocol and reported in the Sigfox		Network through the Sigfox radio protocol and reported in the Sigfox
	Network backend.		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		3.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
	reason, when SCHC bi-directional services are used (e.g. Ack-on-		reason, when SCHC bi-directional services are used (e.g. Ack-on-
	Error fragmentation mode) the SCHC protocol implementation needs to		Error fragmentation mode) the SCHC protocol implementation needs to
	consider the times when a downlink message (e.g. SCHC-ACK) can be		consider the times when a downlink message (e.g. SCHC-ACK) can be
	sent and/or received.		sent and/or received.
	For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be		For the UL ACK-on-Error fragmentation mode, a DL opportunity MUST be
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 29 ¶
	opportunity. The Network SCHC can then decide to respond at that		opportunity. The Network SCHC can then decide to respond at that
	opportunity (or wait for a further one) with a SCHC-ACK indicating in		opportunity (or wait for a further one) with a SCHC-ACK indicating in
	case there are missing fragments from the current or previous		case there are missing fragments from the current or previous
	windows. If there is no SCHC-ACK to be sent, or if the network		windows. If there is no SCHC-ACK to be sent, or if the network
	decides to wait for a further DL transmission opportunity, then no DL		decides to wait for a further DL transmission opportunity, then no DL
	transmission takes place at that opportunity and after a timeout the		transmission takes place at that opportunity and after a timeout the
	UL transmissions continue. Intermediate SCHC fragments with FCN		UL transmissions continue. Intermediate SCHC fragments with FCN
	different from All-0 or All-1 MUST NOT use the DL request flag to		different from All-0 or All-1 MUST NOT use the DL request flag to
	request a SCHC-ACK.		request a SCHC-ACK.
	4.5. SCHC Rules		3.5. SCHC Rules
	The RuleID MUST be included in the SCHC header. The total number of		The RuleID MUST be included in the SCHC header. The total number of
	rules to be used affects directly the Rule ID field size, and		rules to be used affects directly the Rule ID field size, and
	therefore the total size of the fragmentation header. For this		therefore the total size of the fragmentation header. For this
	reason, it is recommended to keep the number of rules that are		reason, it is recommended to keep the number of rules that are
	defined for a specific device to the minimum possible.		defined for a specific device to the minimum possible.
	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		3.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 payload. The functionality also defines		the maximum size of a Sigfox payload. The functionality also defines
	a mechanism to send reliably multiple messages, by allowing to resend		a mechanism to send reliably multiple messages, by allowing 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
	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 CRC-check are delivered to the Network SCHC C/D + F/R, and each
	one has an associated Sigfox Message Sequence Number (see		one has an associated Sigfox Message Sequence Number (see
	Section 4.2), integrity can be guaranteed when no consecutive		Section 3.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. SCHC Compound ACK		3.6.1. Uplink Fragmentation
	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		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
	bottle") with all the required information for the network to process		bottle") with all the required information for the network to process
	them accordingly. Hence, there is no need to perform any network		them accordingly. Hence, there is no need to perform any network
	attachment, synchronization, or other procedure before transmitting a		attachment, synchronization, or other procedure before transmitting a
	data packet.		data packet.
	Since uplink transmissions are asynchronous, a SCHC fragment can be		Since uplink transmissions are asynchronous, a SCHC fragment can be
	transmitted at any given time by the Device. Sigfox uplink messages		transmitted at any given time by the Device. Sigfox uplink messages
	are fixed in size, and as described in [RFC8376] they can carry 0-12		are fixed in size, and as described in [RFC8376] they can carry 0-12
	bytes payload. Hence, a single SCHC Tile size per fragmentation mode		bytes payload. Hence, a single SCHC Tile size per fragmentation mode
	can be defined so that every Sigfox message always carries one SCHC		can be defined so that every Sigfox message always carries one SCHC
	Tile.		Tile.
	4.6.2.1. Uplink No-ACK Mode		When the ACK-on-Error mode is used for uplink fragmentation, the SCHC
			Compound ACK defined in [I-D.ietf-lpwan-schc-compound-ack]) MUST be
			used in the downlink responses.
			3.6.1.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 10, line 28 ¶		skipping to change at page 9, line 33 ¶
	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.2.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:
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 4 ¶
	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
	o Fragment Compressed Number (FCN) size (N): 3 bits		o Fragment Compressed Number (FCN) size (N): 3 bits
	o MAX_ACK_REQUESTS: 5		o MAX_ACK_REQUESTS: 5
	o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)		o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)
	o Tile size: 11 bytes		o Tile size: 11 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)
	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.2.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header		3.6.1.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 46 ¶		skipping to change at page 11, line 4 ¶
	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: 10 bytes		o Tile size: 10 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)
	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.2.4. All-1 behaviour + Sigfox Sequence Number		3.6.1.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.3. 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.
	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 13, line 4 ¶		skipping to change at page 12, line 8 ¶
	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		o RuleID size: 3 bits
	o DTag size (T): 0 bits		o DTag size (T): 0 bits
	o Window index (W) size (M) is: 0 bits		o Window index (W) size (M) is: 0 bits
	o Fragment Compressed Number (FCN) size (N): 5 bits		o Fragment Compressed Number (FCN) size (N): 5 bits
	o MAX_ACK_REQUESTS: 5		o MAX_ACK_REQUESTS: 5
	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. 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 Section 4.6.1), and SCHC		(including the SCHC Compound ACK defined in
	Abort used in SCHC over Sigfox.		[I-D.ietf-lpwan-schc-compound-ack]), and SCHC Abort used in SCHC over
			Sigfox.
	4.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header		3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	4.7.1.1. Regular SCHC Fragment		3.7.1.1. Regular SCHC Fragment
	Figure 3 shows an example of a regular SCHC fragment for all		Figure 3 shows an example of a regular SCHC fragment for all
	fragments except the last one. As tiles are of 11 bytes, padding		fragments except the last one. As tiles are 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 the
	last one		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.
	4.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 |
	+ ------ + ------ + --------- + ------------ +		+ ------ + ------ + --------- + ------------ +
	skipping to change at page 14, line 31 ¶		skipping to change at page 13, line 34 ¶
	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
	the Sender-Abort message is 1 byte.		the Sender-Abort message is 1 byte.
	4.7.1.3. SCHC ACK Format		3.7.1.3. SCHC ACK Format
	Figure 5 shows the SCHC ACK format when all fragments have been		Figure 5 shows the SCHC ACK format when all fragments have been
	correctly received (C=1). Padding MUST be added to complete the		correctly received (C=1). Padding MUST be added to complete the
	64-bit Sigfox downlink frame payload size.		64-bit Sigfox downlink frame payload size.
	|---- SCHC ACK Header ----|		|---- SCHC ACK Header ----|
	+ ----------------------- + ------- +		+ ----------------------- + ------- +
	| RuleID | W | C=b'1 | b'0-pad |		| RuleID | W | C=b'1 | b'0-pad |
	+ ------ + ------ + ----- + ------- +		+ ------ + ------ + ----- + ------- +
	| 3 bits | 2 bits | 1 bit | 58 bits |		| 3 bits | 2 bits | 1 bit | 58 bits |
	Figure 5: SCHC Success ACK message format		Figure 5: SCHC Success ACK message format
	In case SCHC fragment losses are found in any of the windows of the		In case SCHC fragment losses are found in any of the windows of the
	SCHC Packet (C=0), the SCHC Compound ACK MUST be used. The SCHC		SCHC Packet (C=0), the SCHC Compound ACK defined in
	Compound ACK message format is shown in Figure 6. The window		[I-D.ietf-lpwan-schc-compound-ack] MUST be used. The SCHC Compound
	numbered 00, if present in the SCHC Compound ACK, MUST be placed		ACK message format is shown in Figure 6. The window numbered 00, if
	between the Rule ID and the C bit to avoid confusion with padding		present in the SCHC Compound ACK, MUST be placed between the Rule ID
	bits. If padding is needed for the SCHC Compound ACK, padding bits		and the C bit to avoid confusion with padding bits. As padding is
	MUST be 0 to make subsequent window numbers and bitmaps		needed for the SCHC Compound ACK, padding bits MUST be 0 to make
	distinguishable.		subsequent window numbers and bitmaps distinguishable.
	|---- 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 Compound ACK message		The following figures show examples of the SCHC Compound ACK message
	format.		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 |
	Losses are found in windows 00 and 01.		Losses are found in windows 00 and 01.
	Figure 7: SCHC Compound ACK example 1		Figure 7: SCHC Compound ACK example 1
	skipping to change at page 16, line 15 ¶		skipping to change at page 15, line 15 ¶
	|---- SCHC ACK Header ----|- W=00 -|----- W=10 ------|		|---- SCHC ACK Header ----|- W=00 -|----- W=10 ------|
	+ ----------------------- + ------ + ------ + ------ + ------- +		+ ----------------------- + ------ + ------ + ------ + ------- +
	| RuleID | W=b'00 | C=b'0 | Bitmap | W=b'10 | Bitmap | b'0-pad |		| 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 |		| 3 bits | 2 bits | 1 bit | 7 bits | 2 bits | 7 bits | 42 bits |
	Losses are found in windows 00 and 10.		Losses are found in windows 00 and 10.
	Figure 9: SCHC Compound ACK example 3		Figure 9: SCHC Compound ACK example 3
	Figure 10 shows the Compound ACK message format when losses are found		Figure 10 shows the SCHC Compound ACK message format when losses are
	in all windows. The window numbers and its corresponding bitmaps are		found in all windows. The window numbers and its corresponding
	ordered from window numbered 00 to 11, notifying all four possible		bitmaps are ordered from window numbered 00 to 11, notifying all four
	windows.		possible windows.
	|- SCHC ACK Header -|W=b'00|-- W=b'01 ---|		|- SCHC ACK Header -|W=b'00|-- W=b'01 ---|
	+-------------------+------+ ---- +------+		+-------------------+------+ ---- +------+
	|RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ...		|RuleID|W=b'00|C=b'0|Bitmap|W=b'01|Bitmap| ...
	+------+------+-----+------+------+------+		+------+------+-----+------+------+------+
	|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|
	skipping to change at page 17, line 5 ¶		skipping to change at page 16, line 5 ¶
	|- 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
	4.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
	4.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
	4.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header		3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header
	4.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 the
	last one		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).
	4.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.
	|--- SCHC Fragment Header ---|		|--- SCHC Fragment Header ---|
	+ --------------------------- + ------------ +		+ --------------------------- + ------------ +
	| RuleID | W | FCN=ALL-1 | Payload |		| RuleID | W | FCN=ALL-1 | Payload |
	+ ------ + ------ + --------- + ------------ +		+ ------ + ------ + --------- + ------------ +
	| 8 bits | 3 bits | 5 bits | 8 to 80 bits |		| 8 bits | 3 bits | 5 bits | 8 to 80 bits |
	skipping to change at page 18, line 29 ¶		skipping to change at page 17, line 29 ¶
	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, that MUST be of at least		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		1 byte. The SCHC Sender-Abort message header size is of 2 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 2 byte (only header with		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		no padding). This way, the minimum size of the All-1 is 3 bytes, and
	the Sender-Abort message is 2 bytes.		the Sender-Abort message is 2 bytes.
	4.7.2.3. SCHC ACK Format		3.7.2.3. SCHC ACK Format
	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 |
	skipping to change at page 19, line 13 ¶		skipping to change at page 18, line 13 ¶
	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. The SCHC Compound ACK MUST be 0 padded (Padding bits must be
	0).		0).
	|- 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|15 bits| | 3 bits|15 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.
	Figure 17: SCHC Compound ACK message format		Figure 17: SCHC Compound ACK message format
	4.7.2.4. SCHC Sender-Abort Messages		3.7.2.4. SCHC Sender-Abort Messages
	|---- Sender-Abort Header ----|		|---- Sender-Abort Header ----|
	+ --------------------------- +		+ --------------------------- +
	| RuleID | W | FCN=ALL-1 |		| RuleID | W | FCN=ALL-1 |
	+ ------ + ------ + --------- +		+ ------ + ------ + --------- +
	| 8 bits | 3 bits | 5 bits |		| 8 bits | 3 bits | 5 bits |
	Figure 18: SCHC Sender-Abort message format		Figure 18: SCHC Sender-Abort message format
	4.7.2.5. SCHC Receiver-Abort Message		3.7.2.5. SCHC Receiver-Abort Message
	|-- 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
	4.8. Padding		3.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
	Sigfox radio protocol allows sending zero bits, one single bit of		Sigfox radio protocol allows sending zero bits, one single bit of
	information for binary applications (e.g. status), or an integer		information for binary applications (e.g. status), or an integer
	number of bytes. Therefore, for 2 or more bits of payload it is		number of bytes. Therefore, for 2 or more bits of payload it is
	required to add padding to the next integer number of bytes. The		required to add padding to the next integer number of bytes. The
	reason for this flexibility is to optimize transmission time and		reason for this flexibility is to optimize transmission time and
	hence save battery consumption at the device.		hence save battery consumption at the device.
	Downlink frames on the other hand have a fixed length. The payload		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 MUST be used with bits equal to		bits are to be transmitted, padding MUST be used with bits equal to
	0.		0.
	5. Fragmentation Sequence Examples		4. 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		4.1. Uplink No-ACK Examples
	The FCN field indicates the size of the data packet. The first		The FCN field indicates the size of the data packet. The first
	fragment is marked with FCN = X-1, where X is the number of fragments		fragment is marked with FCN = X-1, where X is the number of fragments
	the message is split into. All fragments are marked with decreasing		the message is split into. All fragments are marked with decreasing
	FCN values. Last packet fragment is marked with the FCN = All-1		FCN values. Last packet fragment is marked with the FCN = All-1
	(1111).		(1111).
	Case No losses - All fragments are sent and received successfully.		Case No losses - All fragments are sent and received successfully.
	Sender Receiver		Sender Receiver
	skipping to change at page 21, line 22 ¶		skipping to change at page 20, line 22 ¶
	|-------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)
	5.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
	DL message from the receiver. The DL Enable in the figures shows		DL message from the receiver. The DL Enable in the figures shows
	where the sender should enable the downlink, and wait for an ACK.		where the sender should enable the downlink, and wait for an ACK.
	skipping to change at page 28, line 28 ¶		skipping to change at page 27, line 28 ¶
	|<------ 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 28: 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		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
	sent MAX_ACK_REQUESTS times.		sent MAX_ACK_REQUESTS times.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2----->|		|-----W=0, FCN=5, Seq=2----->|
	skipping to change at page 30, line 18 ¶		skipping to change at page 29, line 18 ¶
	|-----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 30: UL ACK-on-Error Receiver-Abort		Figure 30: UL ACK-on-Error Receiver-Abort
	6. Security considerations		5. 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
	allows providing a balance between cost and effort vs. risk. AES-128		allows providing a balance between cost and effort vs. risk. AES-128
	in counter mode is used for encryption. Cryptographic keys are		in counter mode is used for encryption. Cryptographic keys are
	independent for each device. These keys are associated with the		independent for each device. These keys are associated with the
	device ID and separate integrity and confidentiality keys are pre-		device ID and separate integrity and confidentiality keys are pre-
	provisioned. A confidentiality key is only provisioned if		provisioned. A confidentiality key is only provisioned if
	confidentiality is to be used.		confidentiality is to be used.
	The radio protocol has protections against reply attacks, and the		The radio protocol has protections against reply attacks, and the
	cloud-based core network provides firewalling protection against		cloud-based core network provides firewalling protection against
	undesired incoming communications.		undesired incoming communications.
	7. Acknowledgements		6. Acknowledgements
	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		Sandra Cespedes has been funded in part by the ANID Chile Project
	FONDECYT Regular 1201893 and Basal Project FB0008.		FONDECYT Regular 1201893 and Basal Project FB0008.
	Diego Wistuba has been funded by the ANID Chile Project FONDECYT		Diego Wistuba has been funded by the ANID Chile Project FONDECYT
	Regular 1201893.		Regular 1201893.
	The authors would like to thank Clement Mannequin, Rafael Vidal and		The authors would like to thank Clement Mannequin, Rafael Vidal,
	Antonis Platis for their useful comments and implementation design		Julien Boite, Renaud Marty, and Antonis Platis for their useful
	considerations.		comments and implementation design considerations.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
			[I-D.ietf-lpwan-schc-compound-ack]
			Zuniga, JC., Gomez, C., Aguilar, S., Toutain, L.,
			Cespedes, S., and D. Wistuba, "SCHC Compound ACK", draft-
			ietf-lpwan-schc-compound-ack-00 (work in progress), July
			2021.
	[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>.
	8.2. Informative References		7.2. Informative References
	[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>.
End of changes. 56 change blocks.
	140 lines changed or deleted		108 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/