< draft-ietf-lpwan-schc-over-sigfox-04.txt		draft-ietf-lpwan-schc-over-sigfox-05.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 4, 2021 Universitat Politecnica de Catalunya		Expires: August 26, 2021 S. Aguilar
			Universitat Politecnica de Catalunya
	L. Toutain		L. Toutain
	IMT-Atlantique		IMT-Atlantique
	October 31, 2020		S. Cespedes
			D. Wistuba
			NIC Labs, Universidad de Chile
			February 22, 2021
	SCHC over Sigfox LPWAN		SCHC over Sigfox LPWAN
	draft-ietf-lpwan-schc-over-sigfox-04		draft-ietf-lpwan-schc-over-sigfox-05
	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 42 ¶		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 May 4, 2021.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 30 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. SCHC: Generic Framework for Static Context Header Compression		3. SCHC: Generic Framework for Static Context Header Compression
	and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3		and Fragmentation . . . . . . . . . . . . . . . . . . . . . . 3
	4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3		4. SCHC over Sigfox . . . . . . . . . . . . . . . . . . . . . . 3
	4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3		4.1. Network Architecture . . . . . . . . . . . . . . . . . . 3
	4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Uplink . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6		4.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.4. ACK on Downlink . . . . . . . . . . . . . . . . . . . . . 7		4.4. SCHC-ACK on Downlink . . . . . . . . . . . . . . . . . . 7
	4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7		4.5. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 7
	4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7		4.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 7
	4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8		4.6.1. Uplink Fragmentation . . . . . . . . . . . . . . . . 8
	4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11		4.6.2. Downlink Fragmentation . . . . . . . . . . . . . . . 11
	4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5. Security considerations . . . . . . . . . . . . . . . . . . . 12		5. Fragmentation Sequence Examples . . . . . . . . . . . . . . . 12
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Uplink No-ACK Examples . . . . . . . . . . . . . . . . . 12
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header . . 13
	7.1. Normative References . . . . . . . . . . . . . . . . . . 13		5.3. SCHC Abort Examples . . . . . . . . . . . . . . . . . . . 19
	7.2. Informative References . . . . . . . . . . . . . . . . . 13		6. Security considerations . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
			8.1. Normative References . . . . . . . . . . . . . . . . . . 21
			8.2. Informative References . . . . . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The Generic Framework for Static Context Header Compression and		The Generic Framework for Static Context Header Compression and
	Fragmentation (SCHC) specification [RFC8724] describes two		Fragmentation (SCHC) specification [RFC8724] describes two
	mechanisms: i) an application header compression scheme, and ii) a		mechanisms: i) an application header compression scheme, and ii) a
	frame fragmentation and loss recovery functionality. Both can be		frame fragmentation and loss recovery functionality. Both can be
	used on top of all the four LWPAN technologies defined in [RFC8376] .		used on top of all the four LWPAN technologies defined in [RFC8376] .
	These LPWANs have similar characteristics such as star-oriented		These LPWANs have similar characteristics such as star-oriented
	topologies, network architecture, connected devices with built-in		topologies, network architecture, connected devices with built-in
	skipping to change at page 7, line 5 ¶		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 back to the Network		acknowledgement is generated by the Device back to the Network
	through the Sigfox protocol and reported by the Sigfox Network. This		through the Sigfox protocol and reported by the Sigfox Network. This
	acknowledgement can be retrieved through callbacks by the customer.		acknowledgement can be retrieved through callbacks by the customer.
	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. ACK on Downlink		4.4. SCHC-ACK on Downlink
	As explained previously, downlink transmissions are Device-driven and		As explained previously, downlink transmissions are Device-driven and
	can only take place following a specific uplink transmission that		can only take place following a specific uplink transmission that
	indicates and allows a following downlink opportunity. For this		indicates and allows a following downlink opportunity. For this
	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. ACK) can be sent		consider the times when a downlink message (e.g. SCHC-ACK) can be
	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
	indicated by the last fragment of every window (i.e. FCN = All-0, or		indicated by the last fragment of every window (i.e. FCN = All-0, or
	FCN = All-1). The Device sends the fragments in sequence and, after		FCN = All-1). The Device sends the fragments in sequence and, after
	transmitting the FCN = All-0 or FCN = All-1, it opens up a reception		transmitting the FCN = All-0 or FCN = All-1, it opens up a reception
	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
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 37 ¶
	information for binary applications (e.g. status), or an integer		information for binary applications (e.g. status), or an integer
	number of bytes. Therefore, for 2 or more bits of payload it is		number of bytes. Therefore, for 2 or more bits of payload it is
	required to add padding to the next integer number of bytes. The		required to add padding to the next integer number of bytes. The
	reason for this flexibility is to optimize transmission time and		reason for this flexibility is to optimize transmission time and
	hence save battery consumption at the device.		hence save battery consumption at the device.
	Downlink frames on the other hand have a fixed length. The payload		Downlink frames on the other hand have a fixed length. The payload
	length must be 64 bits (i.e. 8 bytes). Hence, if less information		length must be 64 bits (i.e. 8 bytes). Hence, if less information
	bits are to be transmitted, padding would be necessary.		bits are to be transmitted, padding would be necessary.
	5. Security considerations		5. Fragmentation Sequence Examples
			In this section, some sequence diagrams depicting messages exchanges
			for different fragmentation modes and use cases are shown. In the
			examples, 'Seq' indicates the Sigfox Sequence Number of the frame
			carrying a fragment.
			5.1. Uplink No-ACK Examples
			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
			the message is split into. All fragments are marked with decreasing
			FCN values. Last packet fragment is marked with the FCN = All-1
			(1111).
			Case No losses - All fragments are sent and received successfully.
			Sender Receiver
			|-------FCN=6 (0110), Seq=1-------->|
			|-------FCN=5 (0101), Seq=2-------->|
			|-------FCN=4 (0100), Seq=3-------->|
			|-------FCN=3 (0011), Seq=4-------->|
			|-------FCN=2 (0010), Seq=5-------->|
			|-------FCN=1 (0001), Seq=6-------->|
			|-------FCN=15 (1111), Seq=7------->| All fragments received
			(End)
			Figure 3: UL No-ACK No-Losses
			When the first SCHC fragment is received, the Receiver can calculate
			the total number of SCHC fragments that the SCHC Packet is composed
			of. For example, if the first fragment is numbered with FCN=6, the
			receiver can expect more 6 messages (with FCN going from 5 downward,
			and the last with a FCN equal to 15).
			Case losses on any fragment except the first.
			Sender Receiver
			|-------FCN=6, Seq=1-------->|
			|-------FCN=5, Seq=2----X--->|
			|-------FCN=4, Seq=3-------->|
			|-------FCN=3, Seq=4-------->|
			|-------FCN=2, Seq=5-------->|
			|-------FCN=1, Seq=6-------->|
			|-------FCN=15, Seq=7------->| Missing Fragment - Unable to reassemble
			(End)
			Figure 4: UL No-ACK Losses (scenario 1)
			5.2. Uplink ACK-on-Error Examples: Single-byte SCHC Header
			The single-byte SCHC header ACK-on-Error mode allows sending up to 28
			fragments and packet sizes up to 300 bytes. The SCHC fragments may
			be delivered asynchronously and DL ACK can be sent opportunistically.
			Case No losses
			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
			where the sender should enable the downlink, and wait for an ACK.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2----->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7----->|
			(no ACK)
			|-----W=1, FCN=6, Seq=8----->|
			|-----W=1, FCN=5, Seq=9----->|
			|-----W=1, FCN=4, Seq=10---->|
			DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received
			|<------ ACK, W=1, C=1 ------| C=1
			(End)
			Figure 5: UL ACK-on-Error No-Losses
			Case Fragments lost in first window
			In this case, fragments are lost in the first window (W=0). After
			the first All-0 message arrives, the Receiver leverages the
			opportunity and sends an ACK with the corresponding bitmap and C=0.
			After the missing fragments from the first window (W=0) are resent,
			the sender without opening a reception window, continues transmitting
			the following window. Finally, the All-1 fragment is sent, the
			downlink is enabled and the ACK received with a C=1.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2--X-->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5--X-->|
			|-----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
			|<------ ACK, W=0, C=0 ------| Bitmap:1011011
			|-----W=0, FCN=5, Seq=8----->|
			|-----W=0, FCN=2, Seq=9----->|
			(no ACK)
			|-----W=1, FCN=6, Seq=10---->|
			|-----W=1, FCN=5, Seq=11---->|
			|-----W=1, FCN=4, Seq=12---->|
			DL Enable |-----W=1, FCN=7, Seq=13---->| All fragments received
			|<------ ACK, W=1, C=1 ------| C=1
			(End)
			Figure 6: UL ACK-on-Error Losses on First Window
			Case Fragments All-0 lost in first window (W=0)
			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
			the corresponding ACK, notifying the absence of the All-0 of window
			0.
			The sender resends the missing All-0 messages (with any other missing
			fragment from window 0). Note that this behaviour can take place in
			any intermediate window if the All-0 message is lost.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2----->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7--X-->|
			(no ACK)
			|-----W=1, FCN=6, Seq=8----->|
			|-----W=1, FCN=5, Seq=9----->|
			|-----W=1, FCN=4, Seq=10---->|
			DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0, FCN=0, Seq=7
			|<------ ACK, W=0, C=0 ------| Bitmap:1111110
			DL Enable |-----W=0, FCN=0, Seq=12---->| All fragments received
			|<------ ACK, W=1, C=1 ------| C=1
			(End)
			Figure 7: UL ACK-on-Error All-0 Lost on First Window
			In the following diagram, besides the All-0 there are other lost
			fragments in the first window (W=0).
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2--X-->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4--X-->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7--X-->|
			(no ACK)
			|-----W=1, FCN=6, Seq=8----->|
			|-----W=1, FCN=5, Seq=9----->|
			|-----W=1, FCN=4, Seq=10---->|
			DL Enable |-----W=1, FCN=7, Seq=11---->| Missing Fragment W=0 => FCN= 5, 3 and 0
			|<------ ACK, W=0, C=0 ------| Bitmap:1010110
			|-----W=0, FCN=5, Seq=12---->|
			|-----W=0, FCN=3, Seq=13---->|
			DL Enable |-----W=0, FCN=0, Seq=14---->| All fragments received
			|<------ ACK, W=1, C=1 ------| C=1
			(End)
			Figure 8: UL ACK-on-Error All-0 and other Fragments Lost on First
			Window
			In the following case, there are losses in both the first (W=0) and
			second (W=1) window. The retransmission cycles (after the All-1 is
			sent, not in intermediate windows) should always finish with an All-0
			(if this message was lost) or with an All-1. This is required for
			the sender to open a reception window so the receiver can send an
			ACK. Else, there is no way for the Receiver to send an ACK, if All-1
			message is lost, then an ACK timeout happen and an ACK is resent.
			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--X-->|
			(no ACK)
			|-----W=1, FCN=6 (110), Seq=8--X-->|
			|-----W=1, FCN=5 (101), Seq=9----->|
			|-----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
			|<--------- ACK, W=0, C=0 ---------| Bitmap:1010110
			|-----W=0, FCN=5 (101), Seq=12---->|
			|-----W=0, FCN=3 (011), Seq=13---->|
			DL enable |-----W=0, FCN=0 (000), Seq=14---->| Missing Fragment W=1 => FCN= 6 and 4
			|<--------- ACK, W=1, C=0 ---------| Bitmap:0100001
			|-----W=1, FCN=6 (110), Seq=15---->|
			|-----W=1, FCN=4 (011), Seq=16---->| All fragments received
			DL enable |-----W=1, FCN=7 (111), Seq=17---->|
			|<--------- ACK, W=1, C=1 ---------| C=1
			(End)
			Figure 9: UL ACK-on-Error All-0 and other Fragments Lost on First and
			Second Windows (1)
			Similar case as above, but with less fragments in the second window
			(W=1)
			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--X-->|
			(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
			|<--------- ACK, W=0, C=0 ---------| Bitmap:1010110
			|-----W=0, FCN=5 (101), Seq=10---->|
			|-----W=0, FCN=3 (011), Seq=11---->|
			DL enable |-----W=0, FCN=0 (000), Seq=12---->| Missing Fragment W=1 => FCN= 6 and 4
			|<--------- ACK, W=1, C=0 ---------| Bitmap:0000001
			|-----W=1, FCN=6 (110), Seq=15---->| All fragments received
			DL enable |-----W=1, FCN=7 (111), Seq=17---->|
			|<--------- ACK, W=1, C=1 ---------| C=1
			(End)
			Figure 10: UL ACK-on-Error All-0 and other Fragments Lost on First
			and Second Windows (2)
			Case ACK is lost
			SCHC over Sigfox does not implement the SCHC ACK REQ message.
			Instead it uses the SCHC All-1 message to request an ACK, when
			required.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2----->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7----->|
			(no ACK)
			|-----W=1, FCN=6, Seq=8----->|
			|-----W=1, FCN=5, Seq=9----->|
			|-----W=1, FCN=4, Seq=10---->|
			DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=13---->| RESEND ACK
			|<------ ACK, W=1, C=1 ------| C=1
			(End)
			Figure 11: UL ACK-on-Error ACK Lost
			The number of times an ACK will be requested is determined by the
			MAX_ACK_REQUESTS.
			5.3. SCHC Abort Examples
			Case SCHC Sender-Abort
			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
			sent MAX_ACK_REQUESTS times.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2----->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7----->|
			(no ACK)
			|-----W=1, FCN=6, Seq=8----->|
			|-----W=1, FCN=5, Seq=9----->|
			|-----W=1, FCN=4, Seq=10---->|
			DL Enable |-----W=1, FCN=7, Seq=11---->| All fragments received
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=14---->| RESEND ACK (1)
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=15---->| RESEND ACK (2)
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=16---->| RESEND ACK (3)
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=17---->| RESEND ACK (4)
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |-----W=1, FCN=7, Seq=18---->| RESEND ACK (5)
			|<------ ACK, W=1, C=1 ---X--| C=1
			DL Enable |----Sender-Abort, Seq=19--->| exit with error condition
			(End)
			Figure 12: UL ACK-on-Error Sender-Abort
			Case Receiver-Abort
			The reciever may need to send a Receiver-Abort to stop the current
			communication. This message can only be sent after a DL enable.
			Sender Receiver
			|-----W=0, FCN=6, Seq=1----->|
			|-----W=0, FCN=5, Seq=2----->|
			|-----W=0, FCN=4, Seq=3----->|
			|-----W=0, FCN=3, Seq=4----->|
			|-----W=0, FCN=2, Seq=5----->|
			|-----W=0, FCN=1, Seq=6----->|
			DL Enable |-----W=0, FCN=0, Seq=7----->|
			|<------- RECV ABORT -------| under-resourced
			(Error)
			Figure 13: UL ACK-on-Error Receiver-Abort
			6. Security considerations
	The radio protocol authenticates and ensures the integrity of each		The radio protocol authenticates and ensures the integrity of each
	message. This is achieved by using a unique device ID and an AES-128		message. This is achieved by using a unique device ID and an AES-128
	based message authentication code, ensuring that the message has been		based message authentication code, ensuring that the message has been
	generated and sent by the device with the ID claimed in the message.		generated and sent by the device with the ID claimed in the message.
	Application data can be encrypted at the application level or not,		Application data can be encrypted at the application level or not,
	depending on the criticality of the use case. This flexibility		depending on the criticality of the use case. This flexibility
	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.
	6. Acknowledgements		7. Acknowledgements
	Carles Gomez has been funded in part by the ERDF and the Spanish		Carles Gomez has been funded in part by the Spanish Government
	Government through project TEC2016-79988-P.		through the Jose Castillejo CAS15/00336 grant, the TEC2016-79988-P
			grant, and the PID2019-106808RA-I00 grant, and by Secretaria
			d'Universitats i Recerca del Departament d'Empresa i Coneixement de
			la Generalitat de Catalunya 2017 through grant SGR 376.
	The authors would like to thank Diego Wistuba, Sergio Aguilar,		Sergio Aguilar has been funded by the ERDF and the Spanish Government
	Clement Mannequin, Sandra Cespedes and Rafel Vidal for their useful		through project TEC2016-79988-P and project PID2019-106808RA-I00,
	comments and implementation design considerations.		AEI/FEDER, EU.
	7. References		The authors would like to thank Clement Mannequin, Rafael Vidal and
			Antonis Platis for their useful comments and implementation design
			considerations.
	7.1. Normative References		8. References
			8.1. Normative References
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<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>.
	7.2. Informative References		8.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>.
	skipping to change at page 14, line 4 ¶		skipping to change at page 22, line 31 ¶
	Authors' Addresses		Authors' Addresses
	Juan Carlos Zuniga		Juan Carlos Zuniga
	SIGFOX		SIGFOX
	Montreal QC		Montreal QC
	Canada		Canada
	Email: JuanCarlos.Zuniga@sigfox.com		Email: JuanCarlos.Zuniga@sigfox.com
	URI: http://www.sigfox.com/		URI: http://www.sigfox.com/
	Carles Gomez		Carles Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	08860 Castelldefels		08860 Castelldefels
	Spain		Spain
	Email: carlesgo@entel.upc.edu		Email: carlesgo@entel.upc.edu
			Sergio Aguilar
			Universitat Politecnica de Catalunya
			C/Esteve Terradas, 7
			08860 Castelldefels
			Spain
			Email: sergio.aguilar.romero@upc.edu
	Laurent Toutain		Laurent Toutain
	IMT-Atlantique		IMT-Atlantique
	2 rue de la Chataigneraie		2 rue de la Chataigneraie
	CS 17607		CS 17607
	35576 Cesson-Sevigne Cedex		35576 Cesson-Sevigne Cedex
	France		France
	Email: Laurent.Toutain@imt-atlantique.fr		Email: Laurent.Toutain@imt-atlantique.fr
			Sandra Cespedes
			NIC Labs, Universidad de Chile
			Av. Almte. Blanco Encalada 1975
			Santiago
			Chile
			Email: scespedes@niclabs.cl
			Diego Wistuba
			NIC Labs, Universidad de Chile
			Av. Almte. Blanco Encalada 1975
			Santiago
			Chile
			Email: wistuba@niclabs.cl
End of changes. 19 change blocks.
	25 lines changed or deleted		361 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/