< draft-ietf-lpwan-schc-over-sigfox-01.txt		draft-ietf-lpwan-schc-over-sigfox-02.txt >
	lpwan Working Group JC. Zuniga		lpwan Working Group JC. Zuniga
	Internet-Draft SIGFOX		Internet-Draft SIGFOX
	Intended status: Informational C. Gomez		Intended status: Informational C. Gomez
	Expires: May 7, 2020 Universitat Politecnica de Catalunya		Expires: November 16, 2020 Universitat Politecnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	November 4, 2019		May 15, 2020
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-01		draft-ietf-lpwan-schc-over-sigfox-02
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Generic Framework for Static Context Header Compression and
	a header compression scheme and a fragmentation functionality for Low		Fragmentation (SCHC) specification describes both, an application
	Power Wide Area Network (LPWAN) technologies. SCHC offers a great		header compression scheme, and a frame fragmentation and loss
	level of flexibility that can be tailored for different LPWAN		recovery functionality for Low Power Wide Area Network (LPWAN)
	technologies.		technologies. SCHC offers a great level of flexibility that can be
			tailored for different LPWAN technologies.
	The present document provides the optimal parameters and modes of		The present document provides the optimal parameters and modes of
	operation when SCHC is implemented over a Sigfox LPWAN.		operation when SCHC is implemented over a Sigfox LPWAN. This set of
			parameters are also known as a "SCHC over Sigfox profile."
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 7, 2020.		This Internet-Draft will expire on November 16, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Static Context Header Compression . . . . . . . . . . . . . . 3		3. SCHC: Generic Framework for Static Context Header Compression
	4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 4		and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 4		4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 5		4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.1. Fragmentation headers . . . . . . . . . . . . . . . . . . 5		4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Uplink fragment transmissions . . . . . . . . . . . . . . 5		4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2.1. Uplink No-ACK mode . . . . . . . . . . . . . . . . . 5		4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	5.2.2. Uplink ACK-Always mode . . . . . . . . . . . . . . . 6		4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7
	5.2.3. Uplink ACK-on-Error mode . . . . . . . . . . . . . . 6		4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10
	5.3. Downlink fragment transmissions . . . . . . . . . . . . . 8		4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Security considerations . . . . . . . . . . . . . . . . . . . 11
	7. Security considerations . . . . . . . . . . . . . . . . . . . 9		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9. Informative References . . . . . . . . . . . . . . . . . . . 10		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		7.2. Informative References . . . . . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification		The Generic Framework for Static Context Header Compression and
	[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression		Fragmentation (SCHC) specification [RFC8724] defines both, a higher
	scheme and a fragmentation functionality. Both can be used on top of		layer header compression scheme and a fragmentation and loss recovery
	all the LWPAN systems defined in [RFC8376] . These LPWAN systems have		functionality. Both can be used on top of all the LWPAN systems
	similar characteristics such as star-oriented topologies, network		defined in [RFC8376] . These LPWAN systems have similar
			characteristics such as star-oriented topologies, network
	architecture, connected devices with built-in applications, etc.		architecture, connected devices with built-in 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 systems. Even though there are a great number of similarities		LPWAN systems. Even though there are a great number of similarities
	between LPWAN technologies, some differences exist with respect to		between LPWAN technologies, some differences exist with respect to
	the transmission characteristics, payload sizes, etc. Hence, there		the transmission characteristics, payload sizes, etc. Hence, there
	are optimal parameters and modes of operation that can be used when		are optimal parameters and modes of operation that can be used when
	SCHC is used on top of a specific LPWAN.		SCHC is used on top of a specific LPWAN.
	This document describes the recommended parameters and modes of		This document describes the recommended parameters, settings and
	operation to be used when SCHC is implemented over a Sigfox LPWAN.		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
			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		mechanisms defined in [RFC8376] and in [RFC8724].
	[I-D.ietf-lpwan-ipv6-static-context-hc].
	3. Static Context Header Compression		3. SCHC: Generic Framework for Static Context Header Compression and
			Fragmentation
	The Static Context Header Compression (SCHC) described in		The Generic Framework for Static Context Header Compression and
	[I-D.ietf-lpwan-ipv6-static-context-hc] takes advantage of the		Fragmentation (SCHC) described in [RFC8724] takes advantage of the
	predictability of data flows existing in LPWAN networks to avoid		predictability of data flows existing in LPWAN networks to avoid
	context synchronization. Nonetheless, these contexts must be stored		context synchronization.
	and configured on both ends. This can be done either by using a
	provisioning protocol, by out of band means, or by pre-provisioning
	them (for instance at manufacturing time). The way the contexts are
	configured and stored on both ends is out of the scope of this
	document.
	Dev App		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,
	| APP1 APP2 APP3 | |APP1 APP2 APP3|		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
	| UDP | | | UDP |		of this document.
	| IPv6 | | | IPv6 |
	+--------+ | | |
	|SCHC C/D and F/R| | |
	| | | |
	+--------+-------+ +-------+------+
	$ +--+ +----+ +-----------+ .
	+~~ |RG| === |NGW | === | SCHC |... Internet ..
	+--+ +----+ |F/R and C/D|
	+-----------+
	Figure 1: Architecture		4. SCHC over Sigfox
			4.1. Network Architecture
	Figure 1 represents the architecture for compression/decompression		Figure 1 represents the architecture for compression/decompression
	and fragmentation/reassembly, which is based on [RFC8376]		(C/D) and fragmentation/reassembly (F/R) based on the terminology
	terminology, where the Radio Gateway is a Sigfox Base Station and the		defined in [RFC8376], where the Radio Gateway (RG) is a Sigfox Base
	Network Gateway is the Sigfox Cloud.		Station and the Network Gateway (NGW) is the Sigfox cloud-based
			Network.
			Device Application
			+----------------+ +--------------+
			| APP1 APP2 APP3 | |APP1 APP2 APP3|
			+----------------+ +--------------+
			| UDP | | | | UDP |
			| IPv6 | | | | IPv6 |
			+--------+ | | +--------+
			| SCHC C/D & F/R | | |
			| | | |
			+-------+--------+ +--------+-----+
			$ .
			$ +---------+ +--------------+ +---------+ .
			+~~ |Sigfox BS| |Sigfox Network| | SCHC | .
			| (RG) | === | (NGW) | === |F/R & C/D|.....
			+---------+ +--------------+ +---------+
			Figure 1: Network Architecture
			In the case of the global Sigfox Network, RGs (or Base Stations) are
			distributed over multiple countries wherever the Sigfox LPWAN service
			is provided. The NGW (or cloud-based Sigfox Core Network) is a
			single entity that connects to all Sigfox base stations in the world,
			providing hence a global single star network topology.
	The Device is sending applications flows that are compressed and/or		The Device is sending applications flows that are compressed and/or
	fragmented by a Static Context Header Compression Compressor/		fragmented by a SCHC Compressor/Decompressor (SCHC C/D + F/R) to
	Decompressor (SCHC C/D) to reduce headers size and/or fragment the		reduce headers size and/or fragment the packet. The resulting SCHC
	packet. The resulting information is sent over a layer two (L2)		Message is sent over a layer two (L2) Sigfox frame to the Sigfox Base
	frame to a LPWAN Radio Gateway (RG) which forwards the frame to a		Stations, which then forward the SCHC Message to the Network Gateway
	Network Gateway (NGW).		(NGW). The NGW then delivers the SCHC Message and associated
			gathered metadata to the Network SCHC C/D + F/R.
	4. SCHC over Sigfox		The Sigfox Network (NGW) communicates with the Network SCHC C/D + F/R
			for compression/decompression and/or for fragmentation/reassembly.
			The Network SCHC C/D + F/R share the same set of rules as the Dev
			SCHC C/D + F/R. The Network SCHC C/D + F/R can be collocated with
			the NGW or it could be located in a different place, as long as a
			tunnel or secured communication is established between the NGW and
			the SCHC C/D + F/R functions. After decompression and/or reassembly,
			the packet can be forwarded over the Internet to one (or several)
			LPWAN Application Server(s) (App).
	In the case of the global Sigfox network, RGs (or base stations) are		The SCHC C/D + F/R processes are bidirectional, so the same
	distributed over the multiple countries where the Sigfox LPWAN		principles are applicable on both uplink and downlink.
	service is provided. On the other hand, the NGW (or Cloud-based Core
	network) is a single entity that connects to all Sigfox base stations		4.2. Uplink
	in the world.
	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 these time and frequency diversities, the
	Sigfox network also provides space diversity, as potentially an		Sigfox network also provides space diversity, as potentially an
	uplink message will be received by several base stations. Since all		uplink message will be received by several base stations.
	messages are self-contained and base stations forward them all back
	to the same Core network (NGW), multiple input copies can be combined
	at the NGW and hence provide for extra reliability based on the
	triple diversity (i.e. time, space and frequency).
	Downlink transmissions can only take place after an uplink		Since all messages are self-contained and base stations forward them
	communication. A device willing to receive downlink messages		all back to the same Core Network, multiple input copies can be
	indicates so to the network in the uplink message and opens a fixed		combined at the NGW and hence provide for extra reliability based on
	window for reception after the uplink transmission. The delay and		the triple diversity (i.e. time, space and frequency).
	duration of this reception window have fixed values. If there is a
	downlink message to be sent for this given device (e.g. a response to
	the uplink message or queued information), the network transmits it
	during the reception window.
	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].
	The NGW communicates with the Network SCHC C/D + F/R for compression/		Messages sent from the Device to the Network are delivered by the
	decompression and/or for fragmentation/reassembly. The Network SCHC		Sigfox network (NGW) to the Network SCHC C/D + F/R through a
	C/D + F/R share the same set of rules as the Dev SCHC C/D + F/R. The		callback/API with the following information:
	Network SCHC C/D + F/R can be collocated with the NGW or it could be
	in another place, as long as a tunnel is established between the NGW
	and the SCHC C/D + F/R functions. After decompression and/or
	reassembly, the packet can be forwarded over the Internet to one (or
	several) LPWAN Application Server(s) (App).
	The SCHC C/D + F/R processes are bidirectional, so the same		o Device ID
	principles can be applied on both uplink and downlink.
	4.1. SCHC Rules		o Message Sequence Number
	The RuleID MUST be sent at the beginning of the SCHC header. The		o Message Payload
	total number of rules to be used affects directly the Rule ID field
	size, and therefore the total size of the fragmentation header. For
	this reason, it is recommended to keep the number of rules that are
	defined for a specific device to the minimum possible.
	4.2. Packet processing		o Message Timestamp
	TBD		o Device Geolocation (optional)
	5. Fragmentation		o RSSI (optional)
	The SCHC specification [I-D.ietf-lpwan-ipv6-static-context-hc]		o Device Temperature (optional)
	defines a generic fragmentation functionality that allows sending
	data packets or files larger than the maximum size of a Sigfox data
	frame. The functionality also defines a mechanism to send reliably
	multiple messages, by allowing to resend selectively any lost
	fragments.
	The SCHC fragmentation supports several modes of operation. These		o Device Battery Voltage (optional)
	modes have different advantages and disadvantages depending on the
	specifics of the underlying LPWAN technology and Use Case. This
	section describes how the SCHC fragmentation functionality should
	optimally be implemented when used over a Sigfox LPWAN for the most
	typical use case applications.
	5.1. Fragmentation headers		The Device ID is a globally unique identifier assigned to the Device,
			which is included in the Sigfox header of every message. The Message
			Sequence Number is a monotonically increasing number identifying the
			specific transmission of this uplink message, and it is part of the
			Sigfox header. The Message Payload corresponds to the payload that
			the Device has sent in the uplink transmission.
	A list of fragmentation header fields, their sizes as well as		The Message Timestamp, Device Geolocation, RSSI, Device Temperature
	suggested modes for SCHC fragmentation over Sigfox are provided in		and Device Battery Voltage are metadata parameters provided by the
	this section.		Network.
	5.2. Uplink fragment transmissions		A detailed description of the Sigfox callbacks/APIs can be found in
			[sigfox-callbacks].
	Uplink transmissions are completely asynchronous and can take place		Only messages that have passed the L2 Cyclic Redundancy Check (CRC)
	in any random frequency of the allowed uplink bandwidth allocation.		at network reception are delivered by the Sigfox Network to the
	Hence, devices can go to deep sleep mode, and then wake up and		Network SCHC C/D + F/R.
	transmit whenever there is a need to send any information to the
	network. In that way, there is no need to perform any network		+---------------+-----------------+
			| Sigfox Header | Sigfox payload |
			+---------------+---------------- +
			| SCHC message |
			+-----------------+
			Figure 2: SCHC Message in Sigfox
			Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC
			Message could be a SCHC Packet (e.g. compressed) or a SCHC Fragment
			(e.g. a piece of a bigger SCHC Packet).
			4.3. Downlink
			Downlink transmissions are Device-driven and can only take place
			following an uplink communication. Hence, a Device willing to
			receive downlink messages indicates so to the network in the
			preceding uplink message with a downlink request flag, and then it
			opens a fixed window for downlink reception after the uplink
			transmission. The delay and duration of the reception window have
			fixed values. If there is a downlink message to be sent for this
			given Device (e.g. either a response to the uplink message or queued
			information waiting to be transmitted), the network transmits it to
			the Device during the reception window.
			When a downlink message is sent to a Device, an acknowledgement is
			generated by the Device through the Sigfox protocol and reported by
			the Sigfox Network. This acknowledgement can be retrieved through
			callbacks by the customer.
			A detailed description of the Sigfox Radio Protocol can be found in
			[sigfox-spec] and a detailed description of the Sigfox callbacks/APIs
			can be found in [sigfox-callbacks].
			4.4. SCHC Rules
			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
			therefore the total size of the fragmentation header. For this
			reason, it is recommended to keep the number of rules that are
			defined for a specific device to the minimum possible.
			4.5. Fragmentation
			The SCHC specification [RFC8724] defines a generic fragmentation
			functionality that allows sending data packets or files larger than
			the maximum size of a Sigfox data frame. The functionality also
			defines a mechanism to send reliably multiple messages, by allowing
			to resend selectively any lost fragments.
			The SCHC fragmentation supports several modes of operation. These
			modes have different advantages and disadvantages depending on the
			specifics of the underlying LPWAN technology and application Use
			Case. This section describes how the SCHC fragmentation
			functionality should optimally be implemented when used over a Sigfox
			LPWAN for the most typical Use Case applications.
			4.5.1. Uplink Fragmentation
			Sigfox uplink transmissions are completely asynchronous and can take
			place in any random frequency of the allowed uplink bandwidth
			allocation. Hence, devices can go to deep sleep mode, and then wake
			up and transmit whenever there is a need to send any information to
			the network. In that way, 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. All data packets are self contained with all the		data packet. All data packets are self-contained with all the
	required information for the network to process them accordingly.		required information for the network to process them accordingly.
	Since uplink transmissions occur asynchronously, an SCHC fragment can		Since uplink transmissions occur asynchronously, an SCHC fragment can
	be transmitted at any given time by the Dev.		be 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 bytes payload. Hence, a single SCHC Tile size per mode
			can be defined so that every Sigfox message always carries one SCHC
			Tile.
	5.2.1. Uplink No-ACK mode		4.5.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.
	The recommended Fragmentation Header size is 8 bits, and it is		The RECOMMENDED Fragmentation Header size is 8 bits, and it is
	composed as follows:		composed as follows:
	The recommended Rule ID size is: 2 bits		o RuleID size: 4 bits
	The recommended DTag size (T) is: 2 bits
	Fragment Compressed Number (FCN) size (N): 4 bits
	As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the No-ACK mode
	the W (window) field is not present.
	When fragmentation is used to transport IP frames, the Message
	Integrity Check (MIC) size, M: TBD bits
	When fragmentation is used to transport non-IP frames, the Message
	Integrity Check (MIC) size, M: TBD bits
	The algorithm for computing the MIC field MUST be TBD.
	5.2.2. Uplink ACK-Always mode
	TBD		o DTag size (T): 0 bits
			o Fragment Compressed Number (FCN) size (N): 4 bits
	5.2.3. Uplink ACK-on-Error mode		o As per [RFC8724], in the No-ACK mode the W (window) field is not
			present.
	ACK-on-Error is RECOMMENDED for larger packets that need to be sent		o RCS: Not used
	reliably. This mode is optimal for Sigfox transmissions, since it
	leads to a reduced number of ACKs in the lower capacity downlink
	channel and downlink messages can be sent asynchronously and
	opportunistically.
	o Single-byte SCHC UL header		4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	In the most generic case, and allowing transmission of packets/files		ACK-on-Error with single-byte header is RECOMMENDED for medium-large
	up to 300 bytes long, the SCHC uplink Fragmentation Header size is		size packets that need to be sent reliably. ACK-on-Error is optimal
	RECOMMENDED to be 8 bits in size and composed as follows:		for Sigfox transmissions, since it leads to a reduced number of ACKs
			in the lower capacity downlink channel. Also, downlink messages can
			be sent asynchronously and opportunistically.
	Rule ID size is: 2 bits.		Allowing transmission of packets/files up to 300 bytes long, the SCHC
			uplink Fragmentation Header size is RECOMMENDED to be 8 bits in size
			and is composed as follows:
	DTag size (T) is: 1 bit.		o Rule ID size: 3 bits
	Window (W) size is: 2 bits.		o DTag size (T): 0 bits
	Fragment Compressed Number (FCN) size (N): 3 bits.		o Window index (W) size (M): 2 bits
	For the ACK-on-Error fragmentation mode(s), a single window size		o Fragment Compressed Number (FCN) size (N): 3 bits
	is RECOMMENDED.
	MAX_ACK_REQUESTS: 3.		o MAX_ACK_REQUESTS: 5
	MAX_WIND_FCN: 6 (or 0b110, which allows a maximum window size of 7		o WINDOW_SIZE: 7 (with a maximum value of FCN=0b110)
	fragments).
	Retransmission Timer: 45 sec.		o Tile size: 11 bytes
	Inactivity Timer: [use case dependent].		o Retransmission Timer: Application-dependent
	When fragmentation is used to transport IP frames, the Message		o Inactivity Timer: Application-dependent
	Integrity Check (MIC) size, M: TBD bits
	The algorithm for computing the MIC field MUST be TBD.		o RCS: 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.
	o Two-byte SCHC UL header		4.5.1.3. Uplink ACK-on-Error Mode: Two-byte SCHC Header
			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
			Sigfox transmissions, since it leads to a reduced number of ACKs in
			the lower capacity downlink channel. Also, downlink messages can be
			sent asynchronously and opportunistically.
	In 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:
	Rule ID size is: 4 bits.		o Rule ID size is: 8 bits
	DTag size (T) is: 4 bit.		o DTag size (T) is: 0 bits
	Window (W) size is: 3 bits.		o Window index (W) size (M): 3 bits
	Fragment Compressed Number (FCN) size (N): 5 bits.		o Fragment Compressed Number (FCN) size (N): 5 bits.
	For the ACK-on-Error fragmentation mode(s), a single window size		o MAX_ACK_REQUESTS: 5
	is RECOMMENDED.
	MAX_ACK_REQUESTS: 3.		o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	Retransmission Timer: 45 sec.		o Tile size: 10 bytes
	Inactivity Timer: [use case dependent].		o Retransmission Timer: Application-dependent
	When fragmentation is used to transport IP frames, the Message		o Inactivity Timer: Application-dependent
	Integrity Check (MIC) size, M: TBD bits
	The algorithm for computing the MIC field MUST be TBD.		o RCS: 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.
	5.3. Downlink fragment transmissions		4.5.1.4. All-1 behaviour + Sigfox Sequence Number
			For ACK-on-Error, as defined in [RFC8724] it is expected that the
			last SCHC fragment of the last window will always be delivered with
			an All-1 FCN. Since this last window may not be full (i.e. it may be
			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
			receiver could not derive from the FCN values alone whether there are
			any missing fragments right before the All-1 fragment or not.
			However, since a Message Sequence Number is provided by the Sigfox
			protocol together with the Sigfox Payload, the receiver can detect if
			there are missing fragments before the All-1 and hence construct the
			corresponding SCHC ACK Bitmap accordingly.
			4.5.2. Downlink Fragmentation
	In some LPWAN technologies, as part of energy-saving techniques,		In some LPWAN technologies, as part of energy-saving techniques,
	downlink transmission is only possible immediately after an uplink		downlink transmission is only possible immediately after an uplink
	transmission. This allows the device to go in a very deep sleep mode		transmission. This allows the device to go in a very deep sleep mode
	and preserve battery, without the need to listen to any information		and preserve battery, without the need to listen to any information
	from the network. This is the case for Sigfox-enabled devices, which		from the network. This is the case for Sigfox-enabled devices, which
	can only listen to downlink communications after performing an uplink		can only listen to downlink communications after performing an uplink
	transmission and requesting a downlink.		transmission and requesting a downlink.
	When there are fragments to be transmitted in the downlink, an uplink		When there are fragments to be transmitted in the downlink, an uplink
	message is required to trigger the downlink communication. In order		message is required to trigger the downlink communication. In order
	to avoid potentially high delay for fragmented datagram transmission		to avoid potentially high delay for fragmented datagram transmission
	in the downlink, the fragment receiver MAY perform an uplink		in the downlink, the fragment receiver MAY perform an uplink
	transmission as soon as possible after reception of a downlink		transmission as soon as possible after reception of a downlink
	fragment that is not the last one. Such uplink transmission MAY be		fragment that is not the last one. Such uplink transmission MAY be
	triggered by sending a SCHC message, such as a SCHC ACK. However,		triggered by sending a SCHC message, such as a SCHC ACK. However,
	other data messages can equally be used to trigger DL communications.		other data messages can equally be used to trigger DL communications.
			Sigfox downlink messages are fixed in size, and as described in
			[RFC8376] they can carry up to 8 bytes payload. Hence, a single SCHC
			Tile size per mode can be defined so that every Sigfox message always
			carries one SCHC Tile.
	For reliable downlink fragment transmission, the ACK-Always mode is		For reliable downlink fragment transmission, the ACK-Always mode is
	RECOMMENDED.		RECOMMENDED.
	The recommended Fragmentation Header size is: 8 bits		The SCHC downlink Fragmentation Header size is RECOMMENDED to be 8
			bits in size and is composed as follows:
	The recommended Rule ID size is: 2 bits.		o RuleID size: 3 bits
	The recommended DTag size (T) is: 2 bits.		o DTag size (T): 0 bits
	Fragment Compressed Number (FCN) size (N): 3 bits.		o Window index (W) size (M) is: 0 bits
	As per [I-D.ietf-lpwan-ipv6-static-context-hc], in the ACK-Always		o Fragment Compressed Number (FCN) size (N): 5 bits
	mode a Window (W) 1-bit field must be present.
	For the ACK-Always fragmentation mode(s), a single window size is		o MAX_ACK_REQUESTS: 5
	RECOMMENDED.
	The value of MAX_ACK_REQUESTS SHOULD be 2, and the value of		o WINDOW_SIZE: 31 (with a maximum value of FCN=0b11110)
	MAX_WIND_FCN SHOULD be 6 (or 0b110, which allows a maximum window
	size of 7 fragments).
	When fragmentation is used to transport IP frames, the Message		o Tile size: 7 bytes
	Integrity Check (MIC) size, M: TBD bits
	The algorithm for computing the MIC field MUST be TBD.		o Retransmission Timer: Application-dependent
	Sigfox downlink frames have a fixed length of 8 bytes, which means		o Inactivity Timer: Application-dependent
	that default SCHC algorithm for padding cannot be used. Therefore,		o RCS: Not used
	the 3 last bits of the fragmentation header are used to indicate in
	bytes the size of the padding. A size of 000 means that the full
	ramaining frame is used to carry payload, a value of 001 indicates
	that the last byte contains padding, and so on.
	6. Padding		4.6. 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 96 bits, that is 0		Uplink frames can contain a payload size from 0 to 12 bytes. The
	to 12 bytes. The radio protocol allows sending zero bits or one		radio protocol allows sending zero bits, one single bit of
	single bit of information for binary applications (e.g. status), or		information for binary applications (e.g. status), or an integer
	an integer number of bytes. Therefore, for 2 or more bits of payload		number of bytes. Therefore, for 2 or more bits of payload it is
	it is required to add padding to the next integer number of bytes.		required to add padding to the next integer number of bytes. The
	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 and it should		bits are to be transmitted, padding would be necessary.
	be performed as described in the previous section.
	7. 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.
	8. Acknowledgements		6. Acknowledgements
	Carles Gomez has been funded in part by the ERDF and the Spanish		Carles Gomez has been funded in part by the ERDF and the Spanish
	Government through project TEC2016-79988-P.		Government through project TEC2016-79988-P.
	9. Informative References		The authors would like to thank Diego Wistuba, Clement Mannequin and
			Sandra Cespedes for their useful comments and design considerations.
	[I-D.ietf-lpwan-ipv6-static-context-hc]		7. References
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "LPWAN Static Context Header Compression (SCHC)		7.1. Normative References
	and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
	ipv6-static-context-hc-17 (work in progress), October
	2018.
	[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.
			Zuniga, "SCHC: Generic Framework for Static Context Header
			Compression and Fragmentation", RFC 8724,
			DOI 10.17487/RFC8724, April 2020,
			<https://www.rfc-editor.org/info/rfc8724>.
			7.2. Informative References
			[sigfox-callbacks]
			Sigfox, "Sigfox Callbacks",
			<https://support.sigfox.com/docs/callbacks-documentation>.
	[sigfox-spec]		[sigfox-spec]
	Sigfox, "Sigfox Radio Specifications",		Sigfox, "Sigfox Radio Specifications",
	<https://build.sigfox.com/sigfox-device-radio-		<https://build.sigfox.com/sigfox-device-radio-
	specifications>.		specifications>.
	Authors' Addresses		Authors' Addresses
	Juan Carlos Zuniga		Juan Carlos Zuniga
	SIGFOX		SIGFOX
	425 rue Jean Rostand		425 rue Jean Rostand
End of changes. 87 change blocks.
	227 lines changed or deleted		306 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/