< draft-ietf-lpwan-schc-over-lorawan-12.txt		draft-ietf-lpwan-schc-over-lorawan-13.txt >
	lpwan Working Group O. Gimenez, Ed.		lpwan Working Group O. Gimenez, Ed.
	Internet-Draft Semtech		Internet-Draft Semtech
	Intended status: Standards Track I. Petrov, Ed.		Intended status: Standards Track I. Petrov, Ed.
	Expires: April 27, 2021 Acklio		Expires: May 3, 2021 Acklio
	October 24, 2020		October 30, 2020
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-12		draft-ietf-lpwan-schc-over-lorawan-13
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Static Context Header Compression (SCHC) specification describes
	generic header compression and fragmentation techniques for Low Power		generic header compression and fragmentation techniques for Low Power
	Wide Area Networks (LPWAN) technologies. SCHC is a generic mechanism		Wide Area Networks (LPWAN) technologies. SCHC is a generic mechanism
	designed for great flexibility so that it can be adapted for any of		designed for great flexibility so that it can be adapted for any of
	the LPWAN technologies.		the LPWAN technologies.
	This document specifies a profile of RFC8724 to use SCHC in LoRaWAN		This document specifies a profile of RFC8724 to use SCHC in LoRaWAN
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 April 27, 2021.		This Internet-Draft will expire on May 3, 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 33 ¶		skipping to change at page 2, line 33 ¶
	5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 10		5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. LoRaWAN FPort and RuleID . . . . . . . . . . . . . . . . 10		5.1. LoRaWAN FPort and RuleID . . . . . . . . . . . . . . . . 10
	5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 10		5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 10
	5.3. Interface IDentifier (IID) computation . . . . . . . . . 11		5.3. Interface IDentifier (IID) computation . . . . . . . . . 11
	5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12		5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12
	5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12		5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
	5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 13		5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.6.2. Uplink fragmentation: From device to SCHC gateway . . 13		5.6.2. Uplink fragmentation: From device to SCHC gateway . . 13
	5.6.3. Downlink fragmentation: From SCHC gateway to device . 16		5.6.3. Downlink fragmentation: From SCHC gateway to device . 16
	5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 19		5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 20
	5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 19		5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 20
	5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 20		5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 21
	5.7.3. Delay after each LoRaWAN frame to respect local		5.7.3. Delay after each LoRaWAN frame to respect local
	regulation . . . . . . . . . . . . . . . . . . . . . 20		regulation . . . . . . . . . . . . . . . . . . . . . 21
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
	10.1. Normative References . . . . . . . . . . . . . . . . . . 21		10.1. Normative References . . . . . . . . . . . . . . . . . . 22
	10.2. Informative References . . . . . . . . . . . . . . . . . 22		10.2. Informative References . . . . . . . . . . . . . . . . . 23
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
	A.1. Uplink - Compression example - No fragmentation . . . . . 22		A.1. Uplink - Compression example - No fragmentation . . . . . 23
	A.2. Uplink - Compression and fragmentation example . . . . . 23		A.2. Uplink - Compression and fragmentation example . . . . . 24
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 25		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	SCHC specification [RFC8724] describes generic header compression and		SCHC specification [RFC8724] describes generic header compression and
	fragmentation techniques that can be used on all LPWAN technologies		fragmentation techniques that can be used on all LPWAN technologies
	defined in [RFC8376]. Even though those technologies share a great		defined in [RFC8376]. Even though those technologies share a great
	number of common features like star-oriented topologies, network		number of common features like star-oriented topologies, network
	architecture, devices with mostly quite predictable communications,		architecture, devices with mostly quite predictable communications,
	etc; they do have some slight differences with respect to payload		etc; they do have some slight differences with respect to payload
	sizes, reactiveness, etc.		sizes, reactiveness, etc.
	skipping to change at page 4, line 5 ¶		skipping to change at page 4, line 5 ¶
	Personalization_ mode.		Personalization_ mode.
	* Dynamically: after a Join Procedure by the Network Gateway in		* Dynamically: after a Join Procedure by the Network Gateway in
	_Over The Air Activation_ mode.		_Over The Air Activation_ mode.
	o Downlink: LoRaWAN term for a frame transmitted by the network and		o Downlink: LoRaWAN term for a frame transmitted by the network and
	received by the device.		received by the device.
	o FRMPayload: Application data in a LoRaWAN frame.		o FRMPayload: Application data in a LoRaWAN frame.
			o MSB: Most Significant Byte
	o OUI: Organisation Unique Identifier. IEEE assigned prefix for		o OUI: Organisation Unique Identifier. IEEE assigned prefix for
	EUI.		EUI.
	o RCS: Reassembly Check Sequence. Used to verify the integrity of		o RCS: Reassembly Check Sequence. Used to verify the integrity of
	the fragmentation-reassembly process.		the fragmentation-reassembly process.
			o RX: Device's reception window.
			o RX1/RX2: LoRaWAN class A end-devices open two RX windows following
			an uplink, called RX1 and RX2.
	o SCHC gateway: It corresponds to the LoRaWAN Application Server.		o SCHC gateway: It corresponds to the LoRaWAN Application Server.
	It manages translation between IPv6 network and the Network		It manages translation between IPv6 network and the Network
	Gateway (LoRaWAN Network Server).		Gateway (LoRaWAN Network Server).
	o Tile: Piece of a fragmented packet as described in [RFC8724]		o Tile: Piece of a fragmented packet as described in [RFC8724]
	section 8.2.2.1		section 8.2.2.1
	o Uplink: LoRaWAN term for a frame transmitted by the device and		o Uplink: LoRaWAN term for a frame transmitted by the device and
	received by the network.		received by the network.
	skipping to change at page 10, line 21 ¶		skipping to change at page 10, line 21 ¶
	5. SCHC-over-LoRaWAN		5. SCHC-over-LoRaWAN
	5.1. LoRaWAN FPort and RuleID		5.1. LoRaWAN FPort and RuleID
	The FPort field is part of the SCHC Message, as shown in Figure 5.		The FPort field is part of the SCHC Message, as shown in Figure 5.
	The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with		The SCHC C/D and the SCHC F/R SHALL concatenate the FPort field with
	the LoRaWAN payload to recompose the SCHC Message.		the LoRaWAN payload to recompose the SCHC Message.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------------------------ +		+ ------------------------ +
	| SCHC packet |		| SCHC Message |
	Figure 5: SCHC Message in LoRaWAN		Figure 5: SCHC Message in LoRaWAN
			Note: SCHC Message is any datagram sent by SCHC C/D or F/R layers.
	A fragmented datagram with application payload transferred from		A fragmented datagram with application payload transferred from
	device to Network Gateway, is called uplink fragmented datagram. It		device to Network Gateway, is called uplink fragmented datagram. It
	uses an FPort for data uplink and its associated SCHC control		uses an FPort for data uplink and its associated SCHC control
	downlinks, named FPortUp in this document. The other way, a		downlinks, named FPortUp in this document. The other way, a
	fragmented datagram with application payload transferred from Network		fragmented datagram with application payload transferred from Network
	Gateway to device, is called downlink fragmented datagram. It uses		Gateway to device, is called downlink fragmented datagram. It uses
	another FPort for data downlink and its associated SCHC control		another FPort for data downlink and its associated SCHC control
	uplinks, named FPortDown in this document.		uplinks, named FPortDown in this document.
	All RuleID can use arbitrary values inside the FPort range allowed by		All RuleID can use arbitrary values inside the FPort range allowed by
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 37 ¶
	of all windows:		of all windows:
	o the SCHC receiver SHOULD send a SCHC ACK after every window even		o the SCHC receiver SHOULD send a SCHC ACK after every window even
	if there is no missing tile.		if there is no missing tile.
	o the SCHC sender SHOULD wait for the SCHC ACK from the SCHC		o the SCHC sender SHOULD wait for the SCHC ACK from the SCHC
	receiver before sending tiles from the next window. If the SCHC		receiver before sending tiles from the next window. If the SCHC
	ACK is not received, it SHOULD send a SCHC ACK REQ up to		ACK is not received, it SHOULD send a SCHC ACK REQ up to
	MAX_ACK_REQUESTS times, as described previously.		MAX_ACK_REQUESTS times, as described previously.
			This will avoid useless uplinks if the device has lost network
			coverage.
	For non-battery powered devices, the SCHC receiver MAY also choose to		For non-battery powered devices, the SCHC receiver MAY also choose to
	send a SCHC ACK only at the end of all windows. This will reduce		send a SCHC ACK only at the end of all windows. This will reduce
	downlink load on the LoRaWAN network, by reducing the number of		downlink load on the LoRaWAN network, by reducing the number of
	downlinks.		downlinks.
	SCHC implementations MUST be compatible with both behaviors, and this		SCHC implementations MUST be compatible with both behaviors, and this
	selection is part of the rule context.		selection is part of the rule context.
	5.6.2.1. Regular fragments		5.6.2.1. Regular fragments
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 26 ¶
	5.6.2.2. Last fragment (All-1)		5.6.2.2. Last fragment (All-1)
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------- +		+ ------ + ---------------------------- +
	| RuleID | W | FCN=All-1 | RCS |		| RuleID | W | FCN=All-1 | RCS |
	+ ------ + ------ + --------- + ------- +		+ ------ + ------ + --------- + ------- +
	| 8 bits | 2 bits | 6 bits | 32 bits |		| 8 bits | 2 bits | 6 bits | 32 bits |
	Figure 8: All-1 SCHC Message: the last fragment without last tile.		Figure 8: All-1 SCHC Message: the last fragment without last tile.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ------------------------------------------- +		+ ------ + ---------------------------------------------------------- +
	| RuleID | W | FCN=All-1 | RCS | Last tile |		| RuleID | W | FCN=All-1 | RCS | Last tile | Opt. padding |
	+ ------ + ------ + --------- + ------- + ------------ +		+ ------ + ------ + --------- + ------- + ------------ + ------------ +
	| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits |		| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits | 0 to 7 bits |
	Figure 9: All-1 SCHC Message: the last fragment with last tile.		Figure 9: All-1 SCHC Message: the last fragment with last tile.
	5.6.2.3. SCHC ACK		5.6.2.3. SCHC ACK
			| FPort | LoRaWAN payload |
			+ ------ + --------------------------+
			| RuleID | W | C = 1 | padding |
			| | | | (b'00000) |
			+ ------ + ----- + ----- + --------- +
			| 8 bits | 2 bit | 1 bit | 5 bits |
			Figure 10: SCHC ACK format, correct RCS check.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + --------------------------------- + ---------------- +		+ ------ + --------------------------------- + ---------------- +
	| RuleID | W | C | Compressed bitmap | Optional padding |		| RuleID | W | C = 0 | Compressed bitmap | Optional padding |
	| | | | (C = 0) | (b'0...0) |		| | | | (C = 0) | (b'0...0) |
	+ ------ + ----- + ----- + ----------------- + ---------------- +		+ ------ + ----- + ----- + ----------------- + ---------------- +
	| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits |		| 8 bits | 2 bit | 1 bit | 5 to 63 bits | 0, 6 or 7 bits |
	Figure 10: SCHC ACK format, failed RCS check.		Figure 11: SCHC ACK format, failed RCS check.
	Note: Because of the bitmap compression mechanism and L2 byte		Note: Because of the bitmap compression mechanism and L2 byte
	alignment, only the following discrete values are possible for the		alignment, only the following discrete values are possible for the
	compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62 and 63.		compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62 and 63.
	Bitmaps of 63 bits will require 6 bits of padding.		Bitmaps of 63 bits will require 6 bits of padding.
	5.6.2.4. Receiver-Abort		5.6.2.4. Receiver-Abort
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + -------------------------------------------- +		+ ------ + -------------------------------------------- +
	| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |		| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |
	+ ------ + -------- + ------+-------- + ----------------+		+ ------ + -------- + ------+-------- + ----------------+
	| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |		| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 11: Receiver-Abort format.		Figure 12: Receiver-Abort format.
	5.6.2.5. SCHC acknowledge request		5.6.2.5. SCHC acknowledge request
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+------- +------------------------- +		+------- +------------------------- +
	| RuleID | W | FCN = b'000000 |		| RuleID | W | FCN = b'000000 |
	+ ------ + ------ + --------------- +		+ ------ + ------ + --------------- +
	| 8 bits | 2 bits | 6 bits |		| 8 bits | 2 bits | 6 bits |
	Figure 12: SCHC ACK REQ format.		Figure 13: SCHC ACK REQ format.
	5.6.3. Downlink fragmentation: From SCHC gateway to device		5.6.3. Downlink fragmentation: From SCHC gateway to device
	In this case, the device is the fragmentation receiver, and the SCHC		In this case, the device is the fragmentation receiver, and the SCHC
	gateway the fragmentation transmitter. The following fields are		gateway the fragmentation transmitter. The following fields are
	common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN		common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN
	payload to retrieve the SCHC Packet as described in Section 5.1.		payload to retrieve the SCHC Packet as described in Section 5.1.
	o SCHC fragmentation reliability mode:		o SCHC fragmentation reliability mode:
	skipping to change at page 17, line 20 ¶		skipping to change at page 18, line 4 ¶
	this is application specific and can be disabled. The RECOMMENDED		this is application specific and can be disabled. The RECOMMENDED
	uplink is a LoRaWAN empty frame as defined Section 4.6. As this		uplink is a LoRaWAN empty frame as defined Section 4.6. As this
	uplink is to open an RX window, any LoRaWAN uplink frame from the		uplink is to open an RX window, any LoRaWAN uplink frame from the
	device MAY reset this counter.		device MAY reset this counter.
	_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be		_Note_: The Fpending bit included in LoRaWAN protocol SHOULD NOT be
	used for SCHC-over-LoRaWAN protocol. It might be set by the Network		used for SCHC-over-LoRaWAN protocol. It might be set by the Network
	Gateway for other purposes but not SCHC needs.		Gateway for other purposes but not SCHC needs.
	5.6.3.1. Regular fragments		5.6.3.1. Regular fragments
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ------------------------------------ +		+ ------ + ------------------------------------ +
	| RuleID | W | FCN = b'0 | Payload |		| RuleID | W | FCN = b'0 | Payload |
	+ ------ + ----- + --------- + ---------------- +		+ ------ + ----- + --------- + ---------------- +
	| 8 bits | 1 bit | 1 bit | X bytes + 6 bits |		| 8 bits | 1 bit | 1 bit | X bytes + 6 bits |
	Figure 13: All fragments but the last one. Header size 10 bits,		Figure 14: All fragments but the last one. Header size 10 bits,
	including LoRaWAN FPort.		including LoRaWAN FPort.
	5.6.3.2. Last fragment (All-1)		5.6.3.2. Last fragment (All-1)
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + --------------------------- + ----------------- +		+ ------ + --------------------------- + ------------------------- +
	| RuleID | W | FCN = b'1 | RCS | Payload |		| RuleID | W | FCN = b'1 | RCS | Payload | Opt padding |
	+ ------ + ----- + --------- + ------- + ----------------- +		+ ------ + ----- + --------- + ------- + ----------- + ----------- +
	| 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes |		| 8 bits | 1 bit | 1 bit | 32 bits | 6 to X bits | 0 to 7 bits |
	Figure 14: All-1 SCHC Message: the last fragment.		Figure 15: All-1 SCHC Message: the last fragment.
	5.6.3.3. SCHC ACK		5.6.3.3. SCHC ACK
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------------- +		+ ------ + ---------------------------------- +
	| RuleID | W | C = b'1 | Padding b'000000 |		| RuleID | W | C = b'1 | Padding b'000000 |
	+ ------ + ----- + ------- + ---------------- +		+ ------ + ----- + ------- + ---------------- +
	| 8 bits | 1 bit | 1 bit | 6 bits |		| 8 bits | 1 bit | 1 bit | 6 bits |
	Figure 15: SCHC ACK format, RCS is correct.		Figure 16: SCHC ACK format, RCS is correct.
	5.6.3.4. Receiver-Abort		| FPort | LoRaWAN payload |
			+ ------ + ------------------------------------------------- +
			| RuleID | W | C = b'0 | Bitmap = b'1 | Padding b'000000 |
			+ ------ + ----- + ------- + ------------ + ---------------- +
			| 8 bits | 1 bit | 1 bit | 1 bit | 5 bits |
			Figure 17: SCHC ACK format, RCS is incorrect.
			5.6.3.4. Receiver-Abort
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------------------------- +		+ ------ + ---------------------------------------------- +
	| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |		| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |
	+ ------ + ------- + ------- + -------- + --------------- +		+ ------ + ------- + ------- + -------- + --------------- +
	| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |		| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 16: Receiver-Abort packet (following an All-1 SCHC Fragment		Figure 18: Receiver-Abort packet (following an All-1 SCHC Fragment
	with incorrect RCS).		with incorrect RCS).
	5.6.3.5. Downlink retransmission timer		5.6.3.5. Downlink retransmission timer
	Class A and Class B or Class C devices do not manage retransmissions		Class A and Class B or Class C devices do not manage retransmissions
	and timers the same way.		and timers the same way.
	5.6.3.5.1. Class A devices		5.6.3.5.1. Class A devices
	Class A devices can only receive in an RX slot following the		Class A devices can only receive in an RX slot following the
	skipping to change at page 18, line 36 ¶		skipping to change at page 19, line 33 ¶
	The SCHC gateway implements an inactivity timer with a RECOMMENDED		The SCHC gateway implements an inactivity timer with a RECOMMENDED
	duration of 36 hours. For devices with very low transmission rates		duration of 36 hours. For devices with very low transmission rates
	(example 1 packet a day in normal operation), that duration may be		(example 1 packet a day in normal operation), that duration may be
	extended: it is application specific.		extended: it is application specific.
	RETRANSMISSION_TIMER is application specific and its RECOMMENDED		RETRANSMISSION_TIMER is application specific and its RECOMMENDED
	value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).		value is INACTIVITY_TIMER/(MAX_ACK_REQUESTS + 1).
	*SCHC All-0 (FCN=0)* All fragments but the last have an FCN=0		*SCHC All-0 (FCN=0)* All fragments but the last have an FCN=0
	(because window size is 1). Following it, the device MUST transmit		(because window size is 1). Following an All-0 SCHC Fragment, the
	the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC		device MUST transmit the SCHC ACK message. It MUST transmit up to
	ACK messages before aborting. In order to progress the fragmented		MAX_ACK_REQUESTS SCHC ACK messages before aborting. In order to
	datagram, the SCHC layer should immediately queue for transmission		progress the fragmented datagram, the SCHC layer should immediately
	those SCHC ACK if no SCHC downlink have been received during RX1 and		queue for transmission those SCHC ACK if no SCHC downlink have been
	RX2 window. LoRaWAN layer will respect the applicable local spectrum		received during RX1 and RX2 window. LoRaWAN layer will respect the
	regulation.		applicable local spectrum regulation.
	_Note_: The ACK bitmap is 1 bit long and is always 1.		_Note_: The ACK bitmap is 1 bit long and is always 1.
	*SCHC All-1 (FCN=1)* SCHC All-1 is the last fragment of a datagram,		*SCHC All-1 (FCN=1)* SCHC All-1 is the last fragment of a datagram,
	the corresponding SCHC ACK message might be lost; therefore the SCHC		the corresponding SCHC ACK message might be lost; therefore the SCHC
	gateway MUST request a retransmission of this ACK when the		gateway MUST request a retransmission of this ACK when the
	retransmission timer expires. To open a downlink opportunity the		retransmission timer expires. To open a downlink opportunity the
	device MUST transmit an uplink every		device MUST transmit an uplink every
	RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS *		RETRANSMISSION_TIMER/(MAX_ACK_REQUESTS *
	SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is		SCHC_ACK_REQ_DN_OPPORTUNITY). The format of this uplink is
	skipping to change at page 22, line 49 ¶		skipping to change at page 23, line 49 ¶
	An applicative payload of 78 bytes is passed to SCHC compression		An applicative payload of 78 bytes is passed to SCHC compression
	layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes		40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes
	payload.		payload.
	| RuleID | Compression residue | Payload | Padding=b'000 |		| RuleID | Compression residue | Payload | Padding=b'000 |
	+ ------ + ------------------- + --------- + ------------- +		+ ------ + ------------------- + --------- + ------------- +
	| 1 | 21 bits | 37 bytes | 3 bits |		| 1 | 21 bits | 37 bytes | 3 bits |
	Figure 17: Uplink example: SCHC Message		Figure 19: Uplink example: SCHC Message
	The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used		The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used
	by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need		by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need
	for fragmentation. The payload will be transmitted through FPort =		for fragmentation. The payload will be transmitted through FPort =
	1.		1.
	| LoRaWAN Header | LoRaWAN payload (40 bytes) |		| LoRaWAN Header | LoRaWAN payload (40 bytes) |
	+ ------------------------- + --------------------------------------- +		+ ------------------------- + --------------------------------------- +
	| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |		| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |
	| | | | residue | | |		| | | | residue | | |
	+ ---- + ------- + -------- + ----------- + --------- + ------------- +		+ ---- + ------- + -------- + ----------- + --------- + ------------- +
	| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |		| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |
	Figure 18: Uplink example: LoRaWAN packet		Figure 20: Uplink example: LoRaWAN packet
	A.2. Uplink - Compression and fragmentation example		A.2. Uplink - Compression and fragmentation example
	This example represents an applicative payload going through SCHC,		This example represents an applicative payload going through SCHC,
	with fragmentation.		with fragmentation.
	An applicative payload of 478 bytes is passed to SCHC compression		An applicative payload of 478 bytes is passed to SCHC compression
	layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes		282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes
	payload.		payload.
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + --------- +		+ ------ + ------------------- + --------- +
	| 1 | 21 bits | 279 bytes |		| 1 | 21 bits | 279 bytes |
	Figure 19: Uplink example: SCHC Message		Figure 21: Uplink example: SCHC Message
	The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by		The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by
	LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte		LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte
	FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is		FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is
	sent in first fragment.		sent in first fragment.
	| LoRaWAN Header | LoRaWAN payload (11 bytes) |		| LoRaWAN Header | LoRaWAN payload (11 bytes) |
	+ -------------------------- + -------------------------- +		+ -------------------------- + -------------------------- +
	| | RuleID=20 | W | FCN | 1 tile |		| | RuleID=20 | W | FCN | 1 tile |
	+ -------------- + --------- + ----- + ------ + --------- +		+ -------------- + --------- + ----- + ------ + --------- +
	| XXXX | 1 byte | 0 0 | 62 | 10 bytes |		| XXXX | 1 byte | 0 0 | 62 | 10 bytes |
	Figure 20: Uplink example: LoRaWAN packet 1		Figure 22: Uplink example: LoRaWAN packet 1
	Content of the tile is:		Content of the tile is:
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + ----------------- +		+ ------ + ------------------- + ----------------- +
	| 1 | 21 bits | 6 bytes + 3 bits |		| 1 | 21 bits | 6 bytes + 3 bits |
	Figure 21: Uplink example: LoRaWAN packet 1 - Tile content		Figure 23: Uplink example: LoRaWAN packet 1 - Tile content
	Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by		Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by
	LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte		LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte
	FPort field, a tile does not fit inside so LoRaWAN stack will send		FPort field, a tile does not fit inside so LoRaWAN stack will send
	only FOpts.		only FOpts.
	Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are		Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are
	transmitted:		transmitted:
	| LoRaWAN Header | LoRaWAN payload (231 bytes) |		| LoRaWAN Header | LoRaWAN payload (231 bytes) |
	+ --------------------------------------+ --------------------------- +		+ --------------------------------------+ --------------------------- +
	| | FOpts | RuleID=20 | W | FCN | 23 tiles |		| | FOpts | RuleID=20 | W | FCN | 23 tiles |
	+ -------------- + ------- + ---------- + ----- + ----- + ----------- +		+ -------------- + ------- + ---------- + ----- + ----- + ----------- +
	| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |		| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |
	Figure 22: Uplink example: LoRaWAN packet 2		Figure 24: Uplink example: LoRaWAN packet 2
	Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles		Next transmission MTU is 242 bytes, no FOpts. All 5 remaining tiles
	are transmitted, the last tile is only 2 bytes + 5 bits. Padding is		are transmitted, the last tile is only 2 bytes + 5 bits. Padding is
	added for the remaining 3 bits.		added for the remaining 3 bits.
	| LoRaWAN Header | LoRaWAN payload (44 bytes) |		| LoRaWAN Header | LoRaWAN payload (44 bytes) |
	+ ---- + ---------- + ----------------------------------------------- +		+ ---- + ---------- + ----------------------------------------------- +
	| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 |		| | RuleID=20 | W | FCN | 5 tiles | Padding=b'000 |
	+ ---- + ---------- + ----- + ----- + --------------- + ------------- +		+ ---- + ---------- + ----- + ----- + --------------- + ------------- +
	| XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits |		| XXXX | 1 byte | 0 0 | 38 | 42 bytes+5 bits | 3 bits |
	Figure 23: Uplink example: LoRaWAN packet 3		Figure 25: Uplink example: LoRaWAN packet 3
	Then All-1 message can be transmitted:		Then All-1 message can be transmitted:
	| LoRaWAN Header | LoRaWAN payload (44 bytes) |		| LoRaWAN Header | LoRaWAN payload (44 bytes) |
	+ ---- + -----------+ -------------------------- +		+ ---- + -----------+ -------------------------- +
	| | RuleID=20 | W | FCN | RCS |		| | RuleID=20 | W | FCN | RCS |
	+ ---- + ---------- + ----- + ----- + ---------- +		+ ---- + ---------- + ----- + ----- + ---------- +
	| XXXX | 1 byte | 0 0 | 63 | 4 bytes |		| XXXX | 1 byte | 0 0 | 63 | 4 bytes |
	Figure 24: Uplink example: LoRaWAN packet 4 - All-1 SCHC message		Figure 26: Uplink example: LoRaWAN packet 4 - All-1 SCHC message
	All packets have been received by the SCHC gateway, computed RCS is		All packets have been received by the SCHC gateway, computed RCS is
	correct so the following ACK is sent to the device by the SCHC		correct so the following ACK is sent to the device by the SCHC
	receiver:		receiver:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ -------------- + --------- + ------------------- +		+ -------------- + --------- + ------------------- +
	| | RuleID=20 | W | C | Padding |		| | RuleID=20 | W | C | Padding |
	+ -------------- + --------- + ----- + - + ------- +		+ -------------- + --------- + ----- + - + ------- +
	| XXXX | 1 byte | 0 0 | 1 | 5 bits |		| XXXX | 1 byte | 0 0 | 1 | 5 bits |
	Figure 25: Uplink example: LoRaWAN packet 5 - SCHC ACK		Figure 27: Uplink example: LoRaWAN packet 5 - SCHC ACK
	A.3. Downlink		A.3. Downlink
	An applicative payload of 443 bytes is passed to SCHC compression		An applicative payload of 443 bytes is passed to SCHC compression
	layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes		130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes
	payload.		payload.
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + --------- +		+ ------ + ------------------- + --------- +
	| 1 | 21 bits | 127 bytes |		| 1 | 21 bits | 127 bytes |
	Figure 26: Downlink example: SCHC Message		Figure 28: Downlink example: SCHC Message
	The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN		The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN
	protocol: 51 bytes are available for SCHC payload + FPort field => it		protocol: 51 bytes are available for SCHC payload + FPort field => it
	has to be fragmented.		has to be fragmented.
	| LoRaWAN Header | LoRaWAN payload (51 bytes) |		| LoRaWAN Header | LoRaWAN payload (51 bytes) |
	+ ---- + ---------- + -------------------------------------- +		+ ---- + ---------- + -------------------------------------- +
	| | RuleID=21 | W = 0 | FCN = 0 | 1 tile |		| | RuleID=21 | W = 0 | FCN = 0 | 1 tile |
	+ ---- + ---------- + ------ + ------- + ------------------- +		+ ---- + ---------- + ------ + ------- + ------------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |
	Figure 27: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1		Figure 29: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1
	Content of the tile is:		Content of the tile is:
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + ------------------ +		+ ------ + ------------------- + ------------------ +
	| 1 | 21 bits | 48 bytes and 1 bit |		| 1 | 21 bits | 48 bytes and 1 bit |
	Figure 28: Downlink example: LoRaWAN packet 1: Tile content		Figure 30: Downlink example: LoRaWAN packet 1: Tile content
	The receiver answers with a SCHC ACK:		The receiver answers with a SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 29: Downlink example: LoRaWAN packet 2 - SCHC ACK		Figure 31: Downlink example: LoRaWAN packet 2 - SCHC ACK
	The second downlink is sent, two FOpts:		The second downlink is sent, two FOpts:
	| LoRaWAN Header | LoRaWAN payload (49 bytes) |		| LoRaWAN Header | LoRaWAN payload (49 bytes) |
	+ --------------------------- + ------------------------------------- +		+ --------------------------- + ------------------------------------- +
	| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |		| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |
	+ ---- + ------- + ---------- + ----- + ------- + ------------------- +		+ ---- + ------- + ---------- + ----- + ------- + ------------------- +
	| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |		| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |
	Figure 30: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2		Figure 32: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2
	The receiver answers with an SCHC ACK:		The receiver answers with an SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 31: Downlink example: LoRaWAN packet 4 - SCHC ACK		Figure 33: Downlink example: LoRaWAN packet 4 - SCHC ACK
	The last downlink is sent, no FOpts:		The last downlink is sent, no FOpts:
	| LoRaWAN Header | LoRaWAN payload (37 bytes) |		| LoRaWAN Header | LoRaWAN payload (37 bytes) |
	+ ---- + ------- + --------------------------------------------------- +		+ ---- + ------- + --------------------------------------------------- +
	| | RuleID | W | FCN | RCS | 1 tile | Padding |		| | RuleID | W | FCN | RCS | 1 tile | Padding |
	| | 21 | 0 | 1 | | | b'00000 |		| | 21 | 0 | 1 | | | b'00000 |
	+ ---- + ------- + ----- + ----- + ------- + --------------- + ------- +		+ ---- + ------- + ----- + ----- + ------- + --------------- + ------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bits | 5 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bits | 5 bits |
	Figure 32: Downlink example: LoRaWAN packet 5 - All-1 SCHC message		Figure 34: Downlink example: LoRaWAN packet 5 - All-1 SCHC message
	The receiver answers to the sender with an SCHC ACK:		The receiver answers to the sender with an SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 33: Downlink example: LoRaWAN packet 6 - SCHC ACK		Figure 35: Downlink example: LoRaWAN packet 6 - SCHC ACK
	Authors' Addresses		Authors' Addresses
	Olivier Gimenez (editor)		Olivier Gimenez (editor)
	Semtech		Semtech
	14 Chemin des Clos		14 Chemin des Clos
	Meylan		Meylan
	France		France
	Email: ogimenez@semtech.com		Email: ogimenez@semtech.com
End of changes. 42 change blocks.
	65 lines changed or deleted		92 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/