< draft-ietf-lpwan-schc-over-sigfox-07.txt		draft-ietf-lpwan-schc-over-sigfox-08.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: January 10, 2022 S. Aguilar		Expires: April 26, 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
	July 9, 2021		October 23, 2021
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-07		draft-ietf-lpwan-schc-over-sigfox-08
	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 January 10, 2022.		This Internet-Draft will expire on April 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		3. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3		3.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7		3.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7
	3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7		3.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
	3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7		3.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8		3.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8
	3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11		3.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11
	3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12		3.7. SCHC-over-Sigfox F/R Message Formats . . . . . . . . . . 12
	3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 12		3.7.1. Uplink ACK-on-Error Mode: Single-byte SCHC Header . . 12
	3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 16		3.7.2. Uplink ACK-on-Error Mode: Two-byte SCHC Header . . . 16
	3.8. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 18		3.8. SCHC-Sender Abort . . . . . . . . . . . . . . . . . . . . 18
	4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 19		3.9. SCHC-Receiver Abort . . . . . . . . . . . . . . . . . . . 19
	4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 19		3.10. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 19
	4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 20		4. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 20
	4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 27		4.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 20
	5. Security considerations . . . . . . . . . . . . . . . . . . . 29		4.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 21
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29		4.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 28
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		5. Security considerations . . . . . . . . . . . . . . . . . . . 30
	7.1. Normative References . . . . . . . . . . . . . . . . . . 30		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	7.2. Informative References . . . . . . . . . . . . . . . . . 30		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		7.1. Normative References . . . . . . . . . . . . . . . . . . 31
			7.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) a frame fragmentation and loss recovery functionality,		mechanisms: i) a frame fragmentation and loss recovery functionality,
	and ii) an application header compression scheme. Either can be used		and ii) an application header compression scheme. Either can be used
	on top of all the four LWPAN technologies defined in [RFC8376].		on top of all the four LWPAN technologies defined in [RFC8376].
	These LPWANs have similar characteristics such as star-oriented		These LPWANs have similar characteristics such as star-oriented
	topologies, network architecture, connected devices with built-in		topologies, network architecture, connected devices with built-in
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 26 ¶
	SCHC offers a great level of flexibility to accommodate all these		SCHC offers a great level of flexibility to accommodate all these
	LPWAN technologies. Even though there are a great number of		LPWAN technologies. Even though there are a great number of
	similarities between them, some differences exist with respect to the		similarities between them, some differences exist with respect to the
	transmission characteristics, payload sizes, etc. Hence, there are		transmission characteristics, payload sizes, etc. Hence, there are
	optimal parameters and modes of operation that can be used when SCHC		optimal parameters and modes of operation that can be used when SCHC
	is used on top of a specific LPWAN technology.		is used on top of a specific LPWAN technology.
	This document describes the recommended parameters, settings, and		This document describes the recommended parameters, settings, and
	modes of operation to be used when SCHC is implemented over a Sigfox		modes of operation to be used when SCHC is implemented over a Sigfox
	LPWAN. This set of parameters are also known as a "SCHC over Sigfox		LPWAN. This set of parameters are also known as a "SCHC over Sigfox
	profile."		profile" or simply "SCHC/Sigfox."
	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 over Sigfox		3. SCHC over Sigfox
	The Generic SCHC Framework described in [RFC8724] takes advantage of		The Generic SCHC Framework described in [RFC8724] takes advantage of
	the predictability of data flows existing in LPWAN applications to		the predictability of data flows existing in LPWAN applications to
	skipping to change at page 18, line 41 ¶		skipping to change at page 18, line 41 ¶
	3.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
	3.8. Padding		3.8. SCHC-Sender Abort
			o As defined in [RFC8724], a SCHC-Sender Abort can be triggered when
			the number of SCHC ACK REQ attempts is greater than or equal to
			MAX_ACK_REQUESTS. In the case of SCHC/Sigfox, a SCHC-Sender Abort
			MUST be sent if the number of repeated All-1s sent in a row is
			greater than or equal to MAX_ACK_REQUESTS.
			o The MAX_ACK_REQUEST counter MUST be reset when a SCHC ACK is
			successfully received.
			3.9. SCHC-Receiver Abort
			o As defined in [RFC8724], a SCHC-Receiver Abort is triggered when
			the receiver has no RuleID and DTag pairs available for a new
			session. In the case of SCHC/Sigfox a SCHC-Receiver Abort MUST be
			sent if, for a single device, all the RuleIDs are being processed
			by the receiver (i.e., have an active session) at a certain time,
			or if the RuleID of the fragment is not valid.
			o A SCHC-Receiver Abort MUST be triggered when the Inactivity Timer
			expires.
			o A SCHC-Receiver Abort can be triggered when the number of ACK
			attempts is not strictly less than MAX_ACK_REQUESTS. In the case
			of SCHC/Sigfox, a SCHC-Receiver Abort MUST be sent if the number
			of repeated SCHC ACKs sent in a row (i.e., synchronized with the
			ACK REQ case) is greater than or equal to MAX_ACK_REQUESTS.
			o For SCHC/Sigfox implementations, the MAX_ACK_REQUESTS counter MUST
			be reset when a SCHC ACK is successfully received.
			o Although a SCHC-Receiver Abort can be triggered at any point in
			time, a SCHC-Receiver Abort downlink message MUST only be sent
			when there is a downlink transmission opportunity.
			3.10. Padding
	The Sigfox payload fields have different characteristics in uplink		The Sigfox payload fields have different characteristics in uplink
	and downlink.		and downlink.
	Uplink frames can contain a payload size from 0 to 12 bytes. The		Uplink frames can contain a payload size from 0 to 12 bytes. The
	Sigfox radio protocol allows sending zero bits, one single bit of		Sigfox radio protocol allows sending zero bits, one single bit of
	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
	skipping to change at page 21, line 23 ¶		skipping to change at page 22, line 5 ¶
	(no ACK)		(no ACK)
	|-----W=1, FCN=6, Seq=8----->|		|-----W=1, FCN=6, Seq=8----->|
	|-----W=1, FCN=5, Seq=9----->|		|-----W=1, FCN=5, Seq=9----->|
	|-----W=1, FCN=4, Seq=10---->|		|-----W=1, FCN=4, Seq=10---->|
	DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received		DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 22: UL ACK-on-Error No-Losses		Figure 22: UL ACK-on-Error No-Losses
	Case Fragments lost in first window		Case Fragment losses in first window
	In this case, fragments are lost in the first window (W=0). After		In this case, fragments are lost in the first window (W=0). After
	the first All-0 message arrives, the Receiver leverages the		the first All-0 message arrives, the Receiver leverages the
	opportunity and sends an ACK with the corresponding bitmap and C=0.		opportunity and sends a SCHC ACK with the corresponding bitmap and
			C=0.
	After the missing fragments from the first window (W=0) are resent,		After the loss fragments from the first window (W=0) are resent, the
	the sender continues transmitting the fragments of the following		sender continues transmitting the fragments of the following window
	window (W=1) without opening a reception opportunity. Finally, the		(W=1) without opening a reception opportunity. Finally, the All-1
	All-1 fragment is sent, the downlink is enabled, and the ACK is		fragment is sent, the downlink is enabled, and the SCHC ACK is
	received with C=1.		received with C=1.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2--X-->|		|-----W=0, FCN=5, Seq=2--X-->|
	|-----W=0, FCN=4, Seq=3----->|		|-----W=0, FCN=4, Seq=3----->|
	|-----W=0, FCN=3, Seq=4----->|		|-----W=0, FCN=3, Seq=4----->|
	|-----W=0, FCN=2, Seq=5--X-->|		|-----W=0, FCN=2, Seq=5--X-->|
	|-----W=0, FCN=1, Seq=6----->|		|-----W=0, FCN=1, Seq=6----->|
	DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5		DL Enable |-----W=0, FCN=0, Seq=7----->| Missing Fragments W=0 => FCN=5, Seq=2 and FCN=2, Seq=5
	skipping to change at page 22, line 25 ¶		skipping to change at page 22, line 38 ¶
	|-----W=0, FCN=2, Seq=9----->|		|-----W=0, FCN=2, Seq=9----->|
	|-----W=1, FCN=6, Seq=10---->|		|-----W=1, FCN=6, Seq=10---->|
	|-----W=1, FCN=5, Seq=11---->|		|-----W=1, FCN=5, Seq=11---->|
	|-----W=1, FCN=4, Seq=12---->|		|-----W=1, FCN=4, Seq=12---->|
	DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received		DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 23: UL ACK-on-Error Losses on First Window		Figure 23: UL ACK-on-Error Losses on First Window
	Case Fragments All-0 lost in first window (W=0)		Case Fragment All-0 lost in first window (W=0)
	In this example, the All-0 of the first window (W=0) is lost.		In this example, the All-0 of the first window (W=0) is lost.
	Therefore, the Receiver waits for the next All-X message to generate		Therefore, the Receiver waits for the next All-0 message of
	the corresponding ACK, notifying the absence of the All-0 of window		intermediate windows, or All-1 message of last window to generate the
			corresponding SCHC ACK, notifying the absence of the All-0 of window
	0.		0.
	The sender resends the missing All-0 messages (with any other missing		The sender resends the missing All-0 messages (with any other missing
	fragment from window 0). Note that this behaviour can take place in		fragment from window 0) without opening a reception opportunity.
	any intermediate window if the All-0 message is lost.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2----->|		|-----W=0, FCN=5, Seq=2----->|
	|-----W=0, FCN=4, Seq=3----->|		|-----W=0, FCN=4, Seq=3----->|
	|-----W=0, FCN=3, Seq=4----->|		|-----W=0, FCN=3, Seq=4----->|
	|-----W=0, FCN=2, Seq=5----->|		|-----W=0, FCN=2, Seq=5----->|
	|-----W=0, FCN=1, Seq=6----->| DL Enable		|-----W=0, FCN=1, Seq=6----->| DL Enable
	|-----W=0, FCN=0, Seq=7--X-->|		|-----W=0, FCN=0, Seq=7--X-->|
	(no ACK)		(no ACK)
	skipping to change at page 23, line 26 ¶		skipping to change at page 23, line 26 ¶
	|-----W=1, FCN=4, Seq=10---->|		|-----W=1, FCN=4, Seq=10---->|
	DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7		DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7
	|<------ ACK, W=0, C=0 ------| Bitmap:1111110		|<------ ACK, W=0, C=0 ------| Bitmap:1111110
	|-----W=0, FCN=0, Seq=13---->| All fragments received		|-----W=0, FCN=0, Seq=13---->| All fragments received
	DL Enable |-----W=1, FCN=7, Seq=14---->|		DL Enable |-----W=1, FCN=7, Seq=14---->|
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 24: UL ACK-on-Error All-0 Lost on First Window		Figure 24: UL ACK-on-Error All-0 Lost on First Window
	In the following diagram, besides the All-0 there are other lost		In the following diagram, besides the All-0 there are other fragment
	fragments in the first window (W=0).		losses in the first window (W=0).
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2--X-->|		|-----W=0, FCN=5, Seq=2--X-->|
	|-----W=0, FCN=4, Seq=3----->|		|-----W=0, FCN=4, Seq=3----->|
	|-----W=0, FCN=3, Seq=4--X-->|		|-----W=0, FCN=3, Seq=4--X-->|
	|-----W=0, FCN=2, Seq=5----->|		|-----W=0, FCN=2, Seq=5----->|
	|-----W=0, FCN=1, Seq=6----->|		|-----W=0, FCN=1, Seq=6----->|
	DL Enable |-----W=0, FCN=0, Seq=7--X-->|		DL Enable |-----W=0, FCN=0, Seq=7--X-->|
	(no ACK)		(no ACK)
	skipping to change at page 24, line 29 ¶		skipping to change at page 24, line 29 ¶
	|-----W=0, FCN=5, Seq=13---->|		|-----W=0, FCN=5, Seq=13---->|
	|-----W=0, FCN=3, Seq=14---->|		|-----W=0, FCN=3, Seq=14---->|
	|-----W=0, FCN=0, Seq=15---->| All fragments received		|-----W=0, FCN=0, Seq=15---->| All fragments received
	DL Enable |-----W=1, FCN=7, Seq=16---->|		DL Enable |-----W=1, FCN=7, Seq=16---->|
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 25: UL ACK-on-Error All-0 and other Fragments Lost on First
	Window		Window
	In the next examples, there are losses in both the first (W=0) and		In the next examples, there are fragment losses in both the first
	second (W=1) windows. The retransmission cycles after the All-1 is		(W=0) and second (W=1) windows. The retransmission cycles after the
	sent (i.e., not in intermediate windows) should always finish with an		All-1 is sent (i.e., not in intermediate windows) should always
	with an All-1. In case an intermediate All-0 is lost and then		finish with an with an All-1, as it serves as an ACK Request message
	retransmitted, the All-1 is resent after, as it serves as an ACK		to confirm the correct reception of the retransmitted fragments.
	Request message to confirm the correct reception of the retransmitted
	fragments.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6 (110), Seq=1----->|		|-----W=0, FCN=6 (110), Seq=1----->|
	|-----W=0, FCN=5 (101), Seq=2--X-->|		|-----W=0, FCN=5 (101), Seq=2--X-->|
	|-----W=0, FCN=4 (100), Seq=3----->|		|-----W=0, FCN=4 (100), Seq=3----->|
	|-----W=0, FCN=3 (011), Seq=4--X-->|		|-----W=0, FCN=3 (011), Seq=4--X-->|
	|-----W=0, FCN=2 (010), Seq=5----->|		|-----W=0, FCN=2 (010), Seq=5----->|
	|-----W=0, FCN=1 (001), Seq=6----->|		|-----W=0, FCN=1 (001), Seq=6----->|
	DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|		DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|
	(no ACK)		(no ACK)
	|-----W=1, FCN=6 (110), Seq=8--X-->|		|-----W=1, FCN=6 (110), Seq=8--X-->|
	|-----W=1, FCN=5 (101), Seq=9----->|		|-----W=1, FCN=5 (101), Seq=9----->|
	|-----W=1, FCN=4 (011), Seq=10-X-->|		|-----W=1, FCN=4 (011), Seq=10-X-->|
	DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0		DL enable |-----W=1, FCN=7 (111), Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4
	|<--------- ACK, W=0, C=0 ---------| Bitmap:1010110		|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0100001
	|-----W=0, FCN=5 (101), Seq=13---->|		|-----W=0, FCN=5 (101), Seq=13---->|
	|-----W=0, FCN=3 (011), Seq=14---->|		|-----W=0, FCN=3 (011), Seq=14---->|
	|-----W=0, FCN=0 (000), Seq=15---->|		|-----W=0, FCN=0 (000), Seq=15---->|
	DL enable |-----W=1, FCN=7 (111), Seq=16---->| Missing Fragment W=1 => FCN= 6 and 4		|-----W=1, FCN=6 (110), Seq=16---->|
	|<--------- ACK, W=1, C=0 ---------| Bitmap:0100001		|-----W=1, FCN=4 (011), Seq=17---->| All fragments received
	|-----W=1, FCN=6 (110), Seq=18---->|		DL enable |-----W=1, FCN=7 (111), Seq=18---->|
	|-----W=1, FCN=4 (011), Seq=19---->| All fragments received
	DL enable |-----W=1, FCN=7 (111), Seq=20---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 26: UL ACK-on-Error All-0 and other Fragments Lost on First
	and Second Windows (1)		and Second Windows (1)
	Similar case as above, but with less fragments in the second window		Similar case as above, but with less fragments in the second window
	(W=1)		(W=1)
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6 (110), Seq=1----->|		|-----W=0, FCN=6 (110), Seq=1----->|
	|-----W=0, FCN=5 (101), Seq=2--X-->|		|-----W=0, FCN=5 (101), Seq=2--X-->|
	|-----W=0, FCN=4 (100), Seq=3----->|		|-----W=0, FCN=4 (100), Seq=3----->|
	|-----W=0, FCN=3 (011), Seq=4--X-->|		|-----W=0, FCN=3 (011), Seq=4--X-->|
	|-----W=0, FCN=2 (010), Seq=5----->|		|-----W=0, FCN=2 (010), Seq=5----->|
	|-----W=0, FCN=1 (001), Seq=6----->|		|-----W=0, FCN=1 (001), Seq=6----->|
	DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|		DL enable |-----W=0, FCN=0 (000), Seq=7--X-->|
	(no ACK)		(no ACK)
	|-----W=1, FCN=6 (110), Seq=8--X-->|		|-----W=1, FCN=6 (110), Seq=8--X-->|
	DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0		DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4
	|<--------- ACK, W=0, C=0 ---------| Bitmap:1010110		|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001
	|-----W=0, FCN=5 (101), Seq=10---->|		|-----W=0, FCN=5 (101), Seq=10---->|
	|-----W=0, FCN=3 (011), Seq=11---->|		|-----W=0, FCN=3 (011), Seq=11---->|
	DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4		|-----W=0, FCN=0 (000), Seq=12---->|
	|<--------- ACK, W=1, C=0 ---------| Bitmap:0000001		|-----W=1, FCN=6 (110), Seq=13---->| All fragments received
	|-----W=1, FCN=6 (110), Seq=15---->| All fragments received		DL enable |-----W=1, FCN=7 (111), Seq=14---->|
	DL enable |-----W=1, FCN=7 (111), Seq=17---->|
	|<--------- ACK, W=1, C=1 ---------| C=1		|<--------- ACK, W=1, C=1 ---------| C=1
	(End)		(End)
	Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First		Figure 27: UL ACK-on-Error All-0 and other Fragments Lost on First
	and Second Windows (2)		and Second Windows (2)
	Case ACK is lost		Case SCHC ACK is lost
	SCHC over Sigfox does not implement the SCHC ACK REQ message.		SCHC over Sigfox does not implement the SCHC ACK REQ message.
	Instead it uses the SCHC All-1 message to request an ACK, when		Instead it uses the SCHC All-1 message to request a SCHC ACK, when
	required.		required.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2----->|		|-----W=0, FCN=5, Seq=2----->|
	|-----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----->|
	skipping to change at page 27, line 25 ¶		skipping to change at page 27, line 25 ¶
	|-----W=1, FCN=5, Seq=9----->|		|-----W=1, FCN=5, Seq=9----->|
	|-----W=1, FCN=4, Seq=10---->|		|-----W=1, FCN=4, Seq=10---->|
	DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received		DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK		DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK
	|<------ ACK, W=1, C=1 ------| C=1		|<------ ACK, W=1, C=1 ------| C=1
	(End)		(End)
	Figure 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		Case SCHC Compound ACK at the end
	MAX_ACK_REQUESTS.
			In this example, SCHC Fragment losses are found in both windows 0 and
			1. However, the sender does not send a SCHC ACK after the All-0 of
			window 0. Instead, it sends a SCHC Compound ACK notifying losses of
			both windows.
			Sender Receiver
			|-----W=0, FCN=6 (110), Seq=1----->|
			|-----W=0, FCN=5 (101), Seq=2--X-->|
			|-----W=0, FCN=4 (100), Seq=3----->|
			|-----W=0, FCN=3 (011), Seq=4--X-->|
			|-----W=0, FCN=2 (010), Seq=5----->|
			|-----W=0, FCN=1 (001), Seq=6----->|
			DL enable |-----W=0, FCN=0 (000), Seq=7----->| Waits for next DL opportunity
			(no ACK)
			|-----W=1, FCN=6 (110), Seq=8--X-->|
			DL enable |-----W=1, FCN=7 (111), Seq=9----->| Missing Fragment W=0 => FCN= 5, 3 and 0, W=1 => FCN= 6 and 4
			|<--- Compound ACK, W=0,1, C=0 ----| Bitmap W=0:1010110, Bitmap W=1:0000001
			|-----W=0, FCN=5 (101), Seq=10---->|
			|-----W=0, FCN=3 (011), Seq=11---->|
			|-----W=1, FCN=6 (110), Seq=12---->| All fragments received
			DL enable |-----W=1, FCN=7 (111), Seq=13---->|
			|<--------- ACK, W=1, C=1 ---------| C=1
			(End)
			Figure 29: UL ACK-on-Error Fragments Lost on First and Second Windows
			with one Compound ACK
			The number of times the same SCHC ACK message will be retransmitted
			is determined by the MAX_ACK_REQUESTS.
	4.3. SCHC Abort Examples		4.3. SCHC Abort Examples
	Case SCHC Sender-Abort		Case SCHC Sender-Abort
	The sender may need to send a Sender-Abort to stop the current		The sender may need to send a Sender-Abort to stop the current
	communication. This may happen, for example, if the All-1 has been		communication. This may happen, for example, if the All-1 has been
	sent MAX_ACK_REQUESTS times.		sent MAX_ACK_REQUESTS times.
	Sender Receiver		Sender Receiver
	skipping to change at page 28, line 32 ¶		skipping to change at page 29, line 32 ¶
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3)		DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4)		DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5)		DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5)
	|<------ ACK, W=1, C=1 ---X--| C=1		|<------ ACK, W=1, C=1 ---X--| C=1
	DL Enable |----Sender-Abort, Seq=19--->| exit with error condition		DL Enable |----Sender-Abort, Seq=19--->| exit with error condition
	(End)		(End)
	Figure 29: UL ACK-on-Error Sender-Abort		Figure 30: UL ACK-on-Error Sender-Abort
	Case Receiver-Abort		Case Receiver-Abort
	The reciever may need to send a Receiver-Abort to stop the current		The receiver may need to send a Receiver-Abort to stop the current
	communication. This message can only be sent after a DL enable.		communication. This message can only be sent after a DL enable.
	Sender Receiver		Sender Receiver
	|-----W=0, FCN=6, Seq=1----->|		|-----W=0, FCN=6, Seq=1----->|
	|-----W=0, FCN=5, Seq=2----->|		|-----W=0, FCN=5, Seq=2----->|
	|-----W=0, FCN=4, Seq=3----->|		|-----W=0, FCN=4, Seq=3----->|
	|-----W=0, FCN=3, Seq=4----->|		|-----W=0, FCN=3, Seq=4----->|
	|-----W=0, FCN=2, Seq=5----->|		|-----W=0, FCN=2, Seq=5----->|
	|-----W=0, FCN=1, Seq=6----->|		|-----W=0, FCN=1, Seq=6----->|
	DL Enable |-----W=0, FCN=0, Seq=7----->|		DL Enable |-----W=0, FCN=0, Seq=7----->|
	|<------- RECV ABORT -------| under-resourced		|<------- RECV ABORT -------| under-resourced
	(Error)		(Error)
	Figure 30: UL ACK-on-Error Receiver-Abort		Figure 31: UL ACK-on-Error Receiver-Abort
	5. 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
End of changes. 26 change blocks.
	58 lines changed or deleted		121 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/