< draft-ietf-lpwan-schc-over-sigfox-02.txt		draft-ietf-lpwan-schc-over-sigfox-03.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: November 16, 2020 Universitat Politecnica de Catalunya		Expires: January 14, 2021 Universitat Politecnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	May 15, 2020		July 13, 2020
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-02		draft-ietf-lpwan-schc-over-sigfox-03
	Abstract		Abstract
	The Generic Framework for Static Context Header Compression and		The Generic Framework for Static Context Header Compression and
	Fragmentation (SCHC) specification describes both, an application		Fragmentation (SCHC) specification describes both, an application
	header compression scheme, and a frame fragmentation and loss		header compression scheme, and a frame fragmentation and loss
	recovery functionality for Low Power Wide Area Network (LPWAN)		recovery functionality for Low Power Wide Area Network (LPWAN)
	technologies. SCHC offers a great level of flexibility that can be		technologies. SCHC offers a great level of flexibility that can be
	tailored for different LPWAN technologies.		tailored for different LPWAN technologies.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 November 16, 2020.		This Internet-Draft will expire on January 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3		4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6		4.4. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 6
	4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7		4.5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7		4.5.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 7
	4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10		4.5.2. Downlink Fragmentation . . . . . . . . . . . . . . . 10
	4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security considerations . . . . . . . . . . . . . . . . . . . 11		5. Security considerations . . . . . . . . . . . . . . . . . . . 11
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . 12
	7.2. Informative References . . . . . . . . . . . . . . . . . 12		7.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	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] defines both, a higher		Fragmentation (SCHC) specification [RFC8724] defines both, a higher
	layer header compression scheme and a fragmentation and loss recovery		layer header compression scheme and a fragmentation and loss recovery
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	+---------------+-----------------+		+---------------+-----------------+
	| Sigfox Header | Sigfox payload |		| Sigfox Header | Sigfox payload |
	+---------------+---------------- +		+---------------+---------------- +
	| SCHC message |		| SCHC message |
	+-----------------+		+-----------------+
	Figure 2: SCHC Message in Sigfox		Figure 2: SCHC Message in Sigfox
	Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC		Figure 2 shows a SCHC Message sent over Sigfox, where the SCHC
	Message could be a SCHC Packet (e.g. compressed) or a SCHC Fragment		Message could be a full SCHC Packet (e.g. compressed) or a SCHC
	(e.g. a piece of a bigger SCHC Packet).		Fragment (e.g. a piece of a bigger SCHC Packet).
	4.3. Downlink		4.3. Downlink
	Downlink transmissions are Device-driven and can only take place		Downlink transmissions are Device-driven and can only take place
	following an uplink communication. Hence, a Device willing to		following an uplink communication. Hence, a Device willing to
	receive downlink messages indicates so to the network in the		receive downlink messages indicates so to the network in the
	preceding uplink message with a downlink request flag, and then it		preceding uplink message with a downlink request flag, and then it
	opens a fixed window for downlink reception after the uplink		opens a fixed window for downlink reception after the uplink
	transmission. The delay and duration of the reception window have		transmission. The delay and duration of the reception window have
	fixed values. If there is a downlink message to be sent for this		fixed values. If there is a downlink message to be sent for this
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	can be found in [sigfox-callbacks].		can be found in [sigfox-callbacks].
	4.4. SCHC Rules		4.4. SCHC Rules
	The RuleID MUST be included in the SCHC header. The total number of		The RuleID MUST be included in the SCHC header. The total number of
	rules to be used affects directly the 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 differenciate data traffic classes (e.g. QoS,
			control vs. data, etc.), and data sessions. They can also be used to
			interleave simultaneous fragmentation sessions between a Device and
			the Network.
	4.5. Fragmentation		4.5. Fragmentation
	The SCHC specification [RFC8724] defines a generic fragmentation		The SCHC specification [RFC8724] defines a generic fragmentation
	functionality that allows sending data packets or files larger than		functionality that allows sending data packets or files larger than
	the maximum size of a Sigfox data frame. The functionality also		the maximum size of a Sigfox data frame. The functionality also
	defines a mechanism to send reliably multiple messages, by allowing		defines a mechanism to send reliably multiple messages, by allowing
	to resend selectively any lost fragments.		to resend 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.
			The L2 Word Size used by Sigfox is 1 byte (8 bits).
	4.5.1. Uplink Fragmentation		4.5.1. Uplink Fragmentation
	Sigfox uplink transmissions are completely asynchronous and can take		Sigfox uplink transmissions are completely asynchronous and can take
	place in any random frequency of the allowed uplink bandwidth		place in any random frequency of the allowed uplink bandwidth
	allocation. Hence, devices can go to deep sleep mode, and then wake		allocation. Hence, devices can go to deep sleep mode, and then wake
	up and transmit whenever there is a need to send any information to		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		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.
	skipping to change at page 7, line 46 ¶		skipping to change at page 8, line 5 ¶
	Tile.		Tile.
	4.5.1.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.
			Since there are no multiple windows in the No-ACK mode, the W bit is
			not present. However it is RECOMMENDED to use FCN to indicate the
			size of the data packet. In this sense, the data packet would need
			to be splitted into X fragments and, similarly to the other
			fragmentation modes, the first transmitted fragment would need to be
			marked with FCN = X-1. Consecutive fragments MUST be marked with
			decreasing FCN values, having the last fragment marked with FCN =
			(All-1). Hence, even though the No-ACK mode does not allow
			recovering missing fragments, it allows indicating implicitly to the
			Network the size of the expected packet and whether all fragments
			have been received or not.
	The RECOMMENDED Fragmentation Header size is 8 bits, and it is		The RECOMMENDED Fragmentation Header size is 8 bits, and it is
	composed as follows:		composed as follows:
	o RuleID size: 4 bits		o RuleID size: 4 bits
	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: Not used		o RCS: Not used
	4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header		4.5.1.2. Uplink ACK-on-Error Mode: Single-byte SCHC Header
	ACK-on-Error with single-byte header is RECOMMENDED for medium-large		ACK-on-Error with single-byte header is RECOMMENDED for medium-large
End of changes. 10 change blocks.
	7 lines changed or deleted		27 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/