< draft-ietf-lpwan-schc-over-lorawan-10.txt		draft-ietf-lpwan-schc-over-lorawan-11.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: March 22, 2021 Acklio		Expires: April 18, 2021 Acklio
	September 18, 2020		October 15, 2020
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-10		draft-ietf-lpwan-schc-over-lorawan-11
	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 provides the adaptation of SCHC for use in LoRaWAN		This document specifies a profile of RFC8724 to use SCHC in LoRaWAN
	networks, and provides elements such as efficient parameterization		networks, and provides elements such as efficient parameterization
	and modes of operation. This is called a profile.		and modes of operation.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 22, 2021.		This Internet-Draft will expire on April 18, 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 15 ¶		skipping to change at page 2, line 15 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Static Context Header Compression Overview . . . . . . . . . 4		3. Static Context Header Compression Overview . . . . . . . . . 4
	4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5		4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 6
	4.1. Device classes (A, B, C) and interactions . . . . . . . . 6		4.1. Device classes (A, B, C) and interactions . . . . . . . . 7
	4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 7		4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 8
	4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 8		4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 8
	4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8		4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 9
	4.5. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8		4.5. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 9
	4.6. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 9		4.6. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 9
	4.7. Unicast and multicast technology . . . . . . . . . . . . 9		4.7. Unicast and multicast technology . . . . . . . . . . . . 9
	5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 9		5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. LoRaWAN FPort and RuleID . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12		5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12
	5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12		5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
	5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 12		5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12		5.6.2. Uplink fragmentation: From device to SCHC gateway . . 13
	5.6.3. Downlink fragmentation: From SCHC gateway to device . 15		5.6.3. Downlink fragmentation: From SCHC gateway to device . 16
	5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 19		5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 19
	5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 19		5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 19
	5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 19		5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 20
	5.7.3. Delay after each message to respect local regulation 19		5.7.3. Delay after each LoRaWAN frame to respect local
	6. Security considerations . . . . . . . . . . . . . . . . . . . 19		regulation . . . . . . . . . . . . . . . . . . . . . 20
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
			Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
	10.1. Normative References . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . 21
	10.2. Informative References . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 22
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 22
	A.1. Uplink - Compression example - No fragmentation . . . . . 21		A.1. Uplink - Compression example - No fragmentation . . . . . 22
	A.2. Uplink - Compression and fragmentation example . . . . . 22		A.2. Uplink - Compression and fragmentation example . . . . . 23
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	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 in respect to payload		etc; they do have some slight differences with respect to payload
	sizes, reactiveness, etc.		sizes, reactiveness, etc.
	SCHC provides a generic framework that enables those devices to		SCHC provides a generic framework that enables those devices to
	communicate with other Internet networks. However, for efficient		communicate on IP networks. However, for efficient performance, some
	performance, some parameters and modes of operation need to be set		parameters and modes of operation need to be set appropriately for
	appropriately for each of the LPWAN technologies.		each of the LPWAN technologies.
	This document describes the efficient parameters and modes of		This document describes the parameters and modes of operation when
	operation when SCHC is used over LoRaWAN networks.		SCHC is used over LoRaWAN networks.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This section defines the terminology and acronyms used in this		This section defines the terminology and acronyms used in this
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 49 ¶
	o DevAddr: a 32-bit non-unique identifier assigned to a device		o DevAddr: a 32-bit non-unique identifier assigned to a device
	either:		either:
	* Statically: by the device manufacturer in _Activation by		* Statically: by the device manufacturer in _Activation by
	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 message transmitted by the network		o Downlink: LoRaWAN term for a frame transmitted by the network and
	and received by the device.		received by the device.
			o FRMPayload: Application data in a LoRaWAN frame.
	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 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 Uplink: LoRaWAN term for a message transmitted by the device and		o Tile: Piece of a fragmented packet as described in [RFC8724]
			section 8.2.2.1
			o Uplink: LoRaWAN term for a frame transmitted by the device and
	received by the network.		received by the network.
	3. Static Context Header Compression Overview		3. Static Context Header Compression Overview
	This section contains a short overview of SCHC. For a detailed		This section contains a short overview of SCHC. For a detailed
	description, refer to the full specification [RFC8724].		description, refer to the full specification [RFC8724].
	It defines:		It defines:
	1. Compression mechanisms to avoid transporting information known by		1. Compression mechanisms to avoid transporting information known by
	both sender and receiver over the air. Known information are		both sender and receiver over the air. Known information is part
	part of the "context". This component is called SCHC Compressor/		of the "context". This component is called SCHC Compressor/
	Decompressor (SCHC C/D)		Decompressor (SCHC C/D).
	2. Fragmentation mechanisms to allow SCHC Packet transportation on		2. Fragmentation mechanisms to allow SCHC Packet transportation on
	small, and potentially variable, MTU. This component called SCHC		small, and potentially variable, MTU. This component is called
	Fragmentation/Reassembly (SCHC F/R)		SCHC Fragmentation/Reassembly (SCHC F/R).
	Context exchange or pre-provisioning is out of scope of this		Context exchange or pre-provisioning is out of scope of this
	document.		document.
	Device App		Device App
	+----------------+ +----+ +----+ +----+		+----------------+ +----+ +----+ +----+
	| App1 App2 App3 | |App1| |App2| |App3|		| App1 App2 App3 | |App1| |App2| |App3|
	| | | | | | | |		| | | | | | | |
	| UDP | |UDP | |UDP | |UDP |		| UDP | |UDP | |UDP | |UDP |
	| IPv6 | |IPv6| |IPv6| |IPv6|		| IPv6 | |IPv6| |IPv6| |IPv6|
	skipping to change at page 5, line 24 ¶		skipping to change at page 5, line 40 ¶
	required, then to SCHC C/D for decompression. The SCHC C/D shares		required, then to SCHC C/D for decompression. The SCHC C/D shares
	the same rules with the device. The SCHC C/D and F/R can be located		the same rules with the device. The SCHC C/D and F/R can be located
	on the Network Gateway (NGW) or in another place as long as a		on the Network Gateway (NGW) or in another place as long as a
	communication is established between the NGW and the SCHC F/R, then		communication is established between the NGW and the SCHC F/R, then
	SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC		SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC
	gateway MUST share the same set of rules. After decompression, the		gateway MUST share the same set of rules. After decompression, the
	packet can be sent on the Internet to one or several LPWAN		packet can be sent on the Internet to one or several LPWAN
	Application Servers (App).		Application Servers (App).
	The SCHC C/D and F/R process is bidirectional, so the same principles		The SCHC C/D and F/R process is bidirectional, so the same principles
	can be applied in the other direction.		can be applied to the other direction.
	In a LoRaWAN network, the RG is called a Gateway, the NGW is Network		In a LoRaWAN network, the RGW is called a Gateway, the NGW is Network
	Server, and the SCHC C/D and F/R are an Application Server. It can		Server, and the SCHC C/D and F/R are an Application Server. It can
	be provided by the Network Gateway or any third party software.		be provided by the Network Gateway or any third party software.
	Figure 1 can be mapped in LoRaWAN terminology to:		Figure 1 can be mapped in LoRaWAN terminology to:
	End Device App		End Device App
	+--------------+ +----+ +----+ +----+		+--------------+ +----+ +----+ +----+
	|App1 App2 App3| |App1| |App2| |App3|		|App1 App2 App3| |App1| |App2| |App3|
	| | | | | | | |		| | | | | | | |
	| UDP | |UDP | |UDP | |UDP |		| UDP | |UDP | |UDP | |UDP |
	| IPv6 | |IPv6| |IPv6| |IPv6|		| IPv6 | |IPv6| |IPv6| |IPv6|
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 37 ¶
	[lora-alliance-spec] is as follows:		[lora-alliance-spec] is as follows:
	o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.).		o Devices are LoRaWAN End Devices (e.g. sensors, actuators, etc.).
	There can be a very high density of devices per radio gateway		There can be a very high density of devices per radio gateway
	(LoRaWAN gateway). This entity maps to the LoRaWAN end-device.		(LoRaWAN gateway). This entity maps to the LoRaWAN end-device.
	o The Radio Gateway (RGW), which is the endpoint of the constrained		o The Radio Gateway (RGW), which is the endpoint of the constrained
	link. This entity maps to the LoRaWAN Gateway.		link. This entity maps to the LoRaWAN Gateway.
	o The Network Gateway (NGW) is the interconnection node between the		o The Network Gateway (NGW) is the interconnection node between the
	Radio Gateway and the Internet. This entity maps to the LoRaWAN		Radio Gateway and the SCHC gateway (LoRaWAN Application server).
	Network Server.		This entity maps to the LoRaWAN Network Server.
	o SCHC C/D and F/R are LoRaWAN Application Server; ie the LoRaWAN		o SCHC C/D and F/R are handled by LoRaWAN Application Server; ie the
	application server will do the SCHC C/D and F/R.		LoRaWAN application server will do the SCHC C/D and F/R.
	() () () | +------+		o The LPWAN-AAA Server is the LoRaWAN Join Server. Its role is to
	() () () () / \ +---------+ | Join |		manage and deliver security keys in a secure way, so that the devices
	() () () () () / \======| ^ |===|Server| +-----------+		root key is never exposed.
	() () () | | <--|--> | +------+ |Application|
	() () () () / \==========| v |=============| Server |		(LPWAN-AAA Server)
	() () () / \ +---------+ +-----------+		() () () | +------+
	End Devices Gateways Network Server		() () () () / \ +---------+ | Join |
			() () () () () / \======| ^ |===|Server| +-----------+
			() () () | | <--|--> | +------+ |Application|
			() () () () / \==========| v |=============| Server |
			() () () / \ +---------+ +-----------+
			End-devices Gateways Network Server (SCHC C/D and F/R)
			(devices) (RGW) (NGW)
	Figure 3: LPWAN Architecture		Figure 3: LPWAN Architecture
			_Note_: Figure 3 terms are from LoRaWAN, with [RFC8376] terminology
			in brackets.
	SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/		SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/
	Reassembly (SCHC F/R) are performed on the LoRaWAN end-device and the		Reassembly (SCHC F/R) are performed on the LoRaWAN end-device and the
	Application Server (called SCHC gateway). While the point-to-point		Application Server (called SCHC gateway). While the point-to-point
	link between the device and the Application Server constitutes single		link between the device and the Application Server constitutes a
	IP hop, the ultimate end-point of the IP communication may be an		single IP hop, the ultimate end-point of the IP communication may be
	Internet node beyond the Application Server. In other words, the		an Internet node beyond the Application Server. In other words, the
	LoRaWAN Application Server (SCHC gateway) acts as the first hop IP		LoRaWAN Application Server (SCHC gateway) acts as the first hop IP
	router for the device. The Application Server and Network Server may		router for the device. The Application Server and Network Server may
	be co-located, which effectively turns the Network/Application Server		be co-located, which effectively turns the Network/Application Server
	into the first hop IP router.		into the first hop IP router.
	4.1. Device classes (A, B, C) and interactions		4.1. Device classes (A, B, C) and interactions
	The LoRaWAN MAC layer supports 3 classes of devices named A, B and C.		The LoRaWAN MAC layer supports 3 classes of devices named A, B and C.
	All devices implement the Class A, some devices may implement Class B		All devices implement the Class A, some devices may implement Class B
	or Class C. Class B and Class C are mutually exclusive.		or Class C. Class B and Class C are mutually exclusive.
	skipping to change at page 7, line 16 ¶		skipping to change at page 7, line 52 ¶
	downlink, it has to wait for the next uplink from the device to		downlink, it has to wait for the next uplink from the device to
	get a downlink opportunity. The Class A is the lowest power		get a downlink opportunity. The Class A is the lowest power
	consumption class.		consumption class.
	o Class B: Class B devices implement all the functionalities of		o Class B: Class B devices implement all the functionalities of
	Class A devices, but also schedule periodic listen windows.		Class A devices, but also schedule periodic listen windows.
	Therefore, opposed to the Class A devices, Class B devices can		Therefore, opposed to the Class A devices, Class B devices can
	receive downlinks that are initiated by the Network Gateway and		receive downlinks that are initiated by the Network Gateway and
	not following an uplink. There is a trade-off between the		not following an uplink. There is a trade-off between the
	periodicity of those scheduled Class B listen windows and the		periodicity of those scheduled Class B listen windows and the
	power consumption of the device. The lower the downlink latency,		power consumption of the device: if the periodicity is high
	the higher the power consumption.		downlinks from the NGW will be sent faster, but the device wakes
			up more often: it will have higher power consumption.
	o Class C: Class C devices implement all the functionalities of		o Class C: Class C devices implement all the functionalities of
	Class A devices, but keep their receiver open whenever they are		Class A devices, but keep their receiver open whenever they are
	not transmitting. Class C devices can receive downlinks at any		not transmitting. Class C devices can receive downlinks at any
	time at the expense of a higher power consumption. Battery-		time at the expense of a higher power consumption. Battery-
	powered devices can only operate in Class C for a limited amount		powered devices can only operate in Class C for a limited amount
	of time (for example for a firmware upgrade over-the-air). Most		of time (for example for a firmware upgrade over-the-air). Most
	of the Class C devices are grid powered (for example Smart Plugs).		of the Class C devices are grid powered (for example Smart Plugs).
	4.2. Device addressing		4.2. Device addressing
	LoRaWAN end-devices use a 32-bit network address (devAddr) to		LoRaWAN end-devices use a 32-bit network address (devAddr) to
	communicate with the Network Gateway over-the-air, this address might		communicate with the Network Gateway over-the-air, this address might
	not be unique in a LoRaWAN network; devices using the same devAddr		not be unique in a LoRaWAN network; devices using the same devAddr
	are distinguished by the Network Gateway based on the cryptographic		are distinguished by the Network Gateway based on the cryptographic
	signature appended to every LoRaWAN frame.		signature appended to every LoRaWAN frame.
	To communicate with the SCHC gateway the Network Gateway MUST		To communicate with the SCHC gateway, the Network Gateway MUST
	identify the devices by a unique 64-bit device identifier called the		identify the devices by a unique 64-bit device identifier called the
	DevEUI.		DevEUI.
	The DevEUI is assigned to the device during the manufacturing process		The DevEUI is assigned to the device during the manufacturing process
	by the device's manufacturer. It is built like an Ethernet MAC		by the device's manufacturer. It is built like an Ethernet MAC
	address by concatenating the manufacturer's IEEE OUI field with a		address by concatenating the manufacturer's IEEE OUI field with a
	vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit		vendor unique number. e.g.: 24-bit OUI is concatenated with a 40-bit
	serial number. The Network Gateway translates the devAddr into a		serial number. The Network Gateway translates the devAddr into a
	DevEUI in the uplink direction and reciprocally on the downlink		DevEUI in the uplink direction and reciprocally on the downlink
	direction.		direction.
	+--------+ +---------+ +---------+ +----------+		+--------+ +---------+ +---------+ +----------+
	| Device | <=====> | Network | <====> | SCHC | <========> | Internet |		| Device | <=====> | Network | <====> | SCHC | <======> | Internet |
	| | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |		| | devAddr | Gateway | DevEUI | Gateway | IPv6/UDP | |
	+--------+ +---------+ +---------+ +----------+		+--------+ +---------+ +---------+ +----------+
	Figure 4: LoRaWAN addresses		Figure 4: LoRaWAN addresses
	4.3. General Frame Types		4.3. General Frame Types
	LoRaWAN implements the possibility to send confirmed or unconfirmed		LoRaWAN implements the possibility to send confirmed or unconfirmed
	messages:		frames:
	o Confirmed message: The sender asks the receiver to acknowledge the		o Confirmed frame: The sender asks the receiver to acknowledge the
	message.		frame.
	o Unconfirmed message: The sender does not ask the receiver to		o Unconfirmed frame: The sender does not ask the receiver to
	acknowledge the message.		acknowledge the frame.
	As SCHC defines its own acknowledgment mechanisms, SCHC does not		As SCHC defines its own acknowledgment mechanisms, SCHC does not
	require to use LoRaWAN Confirmed messages.		require to use LoRaWAN Confirmed frames.
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	In addition to regular data frames LoRaWAN implements JoinRequest and		In addition to regular data frames, LoRaWAN implements JoinRequest
	JoinAccept frame types, used by a device to join a network:		and JoinAccept frame types, which are used by a device to join a
			network:
	o JoinRequest: This message is used by a device to join a network.		o JoinRequest: This frame is used by a device to join a network. It
	It contains the device's unique identifier DevEUI and a random		contains the device's unique identifier DevEUI and a random nonce
	nonce that will be used for session key derivation.		that will be used for session key derivation.
	o JoinAccept: To on-board a device, the Network Gateway responds to		o JoinAccept: To on-board a device, the Network Gateway responds to
	the JoinRequest issued by a device with a JoinAccept message.		the JoinRequest issued by a device with a JoinAccept frame. That
	That message is encrypted with the device's AppKey and contains		frame is encrypted with the device's AppKey and contains (amongst
	(amongst other fields) the major network's settings and a random		other fields) the network's major settings and a random nonce used
	nonce used to derive the session keys.		to derive the session keys.
	o Data: MAC and application data. Application data are protected		o Data: MAC and application data. Application data are protected
	with AES-128 encryption, MAC related data are AES-128 encrypted		with AES-128 encryption, MAC related data are AES-128 encrypted
	with another key.		with another key.
	4.5. LoRaWAN FPort		4.5. LoRaWAN FPort
	The LoRaWAN MAC layer features a frame port field in all frames.		The LoRaWAN MAC layer features a frame port field in all frames.
	This field (FPort) is 8 bits long and the values from 1 to 223 can be		This field (FPort) is 8 bits long and the values from 1 to 223 can be
	used. It allows LoRaWAN networks and applications to identify data.		used. It allows LoRaWAN networks and applications to identify data.
	4.6. LoRaWAN empty frame		4.6. LoRaWAN empty frame
	A LoRaWAN empty frame is a LoRaWAN message without FPort (cf		A LoRaWAN empty frame is a LoRaWAN frame without FPort (cf
	Section 5.1) and FRMPayload.		Section 5.1) and FRMPayload.
	4.7. Unicast and multicast technology		4.7. Unicast and multicast technology
	LoRaWAN technology supports unicast downlinks, but also multicast: a		LoRaWAN technology supports unicast downlinks, but also multicast: a
	packet send over LoRaWAN radio link can be received by several		packet sent over LoRaWAN radio link can be received by several
	devices. It is useful to address many devices with same content,		devices. It is useful to address many devices with same content,
	either a large binary file (firmware upgrade), or same command (e.g:		either a large binary file (firmware upgrade), or same command (e.g:
	lighting control). As IPv6 is also a multicast technology this		lighting control). As IPv6 is also a multicast technology this
	feature can be used to address a group of devices.		feature can be used to address a group of devices.
	_Note 1_: IPv6 multicast addresses must be defined as per [RFC4291].		_Note 1_: IPv6 multicast addresses must be defined as per [RFC4291].
	LoRaWAN multicast group definition in a Network Gateway and the		LoRaWAN multicast group definition in a Network Gateway and the
	relation between those groups and IPv6 groupID are out of scope of		relation between those groups and IPv6 groupID are out of scope of
	this document.		this document.
	_Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set]		_Note 2_: LoRa Alliance defined [lora-alliance-remote-multicast-set]
	as RECOMMENDED way to setup multicast groups on devices and create a		as the RECOMMENDED way to setup multicast groups on devices and
	synchronized reception window.		create a synchronized reception window.
	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 retrieve their payload as it is used as a part		the LoRaWAN payload to recompose the SCHC Message.
	of the RuleID field.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------------------------ +		+ ------------------------ +
	| SCHC packet |		| SCHC packet |
	Figure 5: SCHC Message in LoRaWAN		Figure 5: SCHC Message in LoRaWAN
	A fragmentation datagram with application payload transferred from		A fragmented datagram with application payload transferred from
	device to Network Gateway, is called uplink fragmentation datagram.		device to Network Gateway, is called uplink fragmented datagram. It
	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
	fragmentation datagram with application payload transferred from		fragmented datagram with application payload transferred from Network
	Network Gateway to device, is called downlink fragmentation datagram.		Gateway to device, is called downlink fragmented datagram. It uses
	It uses another FPort for data downlink and its associated SCHC		another FPort for data downlink and its associated SCHC control
	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
	LoRaWAN specification and MUST be shared by the device and SCHC		LoRaWAN specification and MUST be shared by the device and SCHC
	gateway prior to the communication with the selected rule. The		gateway prior to the communication with the selected rule. The
	uplink and downlink fragmentation FPorts MUST be different.		uplink and downlink fragmentation FPorts MUST be different.
	5.2. Rule ID management		5.2. Rule ID management
	RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in		RuleID MUST be 8 bits, encoded in the LoRaWAN FPort as described in
	Section 5.1. LoRaWAN supports up to 223 application FPorts in the		Section 5.1. LoRaWAN supports up to 223 application FPorts in the
	range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it		range [1;223] as defined in section 4.3.2 of [lora-alliance-spec], it
	implies that RuleID MSB SHOULD be inside this range. An application		implies that RuleID MSB SHOULD be inside this range. An application
	can send non SCHC traffic by using FPort values different from the		can send non SCHC traffic by using FPort values different from the
	ones used for SCHC.		ones used for SCHC.
	In order to improve interoperability RECOMMENDED fragmentation RuleID		In order to improve interoperability, RECOMMENDED fragmentation
	values are:		RuleID values are:
	o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.		o RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.
	o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.		o RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.
	o RuleID = 22 (8-bit) for which SCHC compression was not possible		o RuleID = 22 (8-bit) for which SCHC compression was not possible
	(no matching rule was found).		(i.e., no matching compression Rule was found), as described in
			[RFC8724] section 6.
	The remaining RuleIDs are available for compression. RuleIDs are		FPortUp value MUST be different from FPortDown. The remaining
	shared between uplink and downlink sessions. A RuleID not in the		RuleIDs are available for compression. RuleIDs are shared between
	set(s) of FPortUp or FPortDown means that the fragmentation is not		uplink and downlink sessions. A RuleID not in the set(s) of FPortUp
	used, thus, on reception, the SCHC Message MUST be sent to the SCHC		or FPortDown means that the fragmentation is not used, thus, on
	C/D layer.		reception, the SCHC Message MUST be sent to the SCHC C/D layer.
	The only uplink messages using the FPortDown port are the		The only uplink frames using the FPortDown port are the fragmentation
	fragmentation SCHC control messages of a downlink fragmentation		SCHC control messages of a downlink fragmented datagram (for example,
	datagram (for example, SCHC ACKs). Similarly, the only downlink		SCHC ACKs). Similarly, the only downlink frames using the FPortUp
	messages using the FPortUp port are the fragmentation SCHC control		port are the fragmentation SCHC control messages of an uplink
	messages of an uplink fragmentation datagram.		fragmented datagram.
	An application can have multiple fragmentation datagrams between a		An application can have multiple fragmented datagrams between a
	device and one or several SCHC gateways. A set of FPort values is		device and one or several SCHC gateways. A set of FPort values is
	REQUIRED for each SCHC gateway instance the device is required to		REQUIRED for each SCHC gateway instance the device is required to
	communicate with. The application can use additional uplinks or		communicate with. The application can use additional uplinks or
	downlink fragmentation parameters but SHALL implement at least the		downlink fragmented parameters but SHALL implement at least the
	parameters defined in this document.		parameters defined in this document.
	The mechanism for sharing those RuleID values is outside the scope of		The mechanism for context distribution across devices and gateways is
	this document.		outside the scope of this document.
	5.3. Interface IDentifier (IID) computation		5.3. Interface IDentifier (IID) computation
	In order to mitigate risks described in [RFC8064] and [RFC8065] IID		In order to mitigate the risks described in [RFC8064] and [RFC8065],
	MUST be created regarding the following algorithm:		IID MUST be created regarding the following algorithm:
	1. key = LoRaWAN AppSKey		1. key = LoRaWAN AppSKey
	2. cmac = aes128_cmac(key, DevEUI)		2. cmac = aes128_cmac(key, DevEUI)
	3. IID = cmac[0..7]		3. IID = cmac[0..7]
	aes128_cmac algorithm is described in [RFC4493]. It has been chosen		aes128_cmac algorithm is described in [RFC4493]. It has been chosen
	as it is already used by devices for LoRaWAN protocol.		as it is already used by devices for LoRaWAN protocol.
	skipping to change at page 11, line 43 ¶		skipping to change at page 12, line 24 ¶
	o DevEUI: 0x1122334455667788		o DevEUI: 0x1122334455667788
	o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB		o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
	1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB		1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
	2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A		2. cmac: 0xBA59F4B196C6C3432D9383C145AD412A
	3. IID: 0xBA59F4B196C6C343		3. IID: 0xBA59F4B196C6C343
	Figure 6: Example of IID computation.		Figure 6: Example of IID computation.
	There is a small probability of IID collision in a LoRaWAN network,		There is a small probability of IID collision in a LoRaWAN network.
	if such event occurs the IID can be changed by rekeying the device on		If this occurs, the IID can be changed by rekeying the device at L2
	L2 level (ie: trigger a LoRaWAN join). The way the device is rekeyed		level (ie: trigger a LoRaWAN join). The way the device is rekeyed is
	is out of scope of this document and left to the implementation.		out of scope of this document and left to the implementation.
	5.4. Padding		5.4. Padding
	All padding bits MUST be 0.		All padding bits MUST be 0.
	5.5. Decompression		5.5. Decompression
	SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the		SCHC C/D MUST concatenate FPort and LoRaWAN payload to retrieve the
	SCHC Packet as per Section 5.1.		SCHC Packet as per Section 5.1.
	RuleIDs matching FPortUp and FPortDown are reserved for SCHC		RuleIDs matching FPortUp and FPortDown are reserved for SCHC
	Fragmentation.		Fragmentation.
	5.6. Fragmentation		5.6. Fragmentation
	The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC		The L2 Word Size used by LoRaWAN is 1 byte (8 bits). The SCHC
	fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink		fragmentation over LoRaWAN uses the ACK-on-Error mode for uplink
	fragmentation and Ack-Always mode for downlink fragmentation. A		fragmentation and Ack-Always mode for downlink fragmentation. A
	LoRaWAN device cannot support simultaneous interleaved fragmentation		LoRaWAN device cannot support simultaneous interleaved fragmented
	datagrams in the same direction (uplink or downlink).		datagrams in the same direction (uplink or downlink).
	The fragmentation parameters are different for uplink and downlink		The fragmentation parameters are different for uplink and downlink
	fragmentation datagrams and are successively described in the next		fragmented datagrams and are successively described in the next
	sections.		sections.
	5.6.1. DTag		5.6.1. DTag
	A Device cannot interleave several fragmented SCHC datagrams on the		[RFC8724] section 8.2.4 describes the possibility to interleave
	same FPort. This field is not used and its size is 0.		several fragmented SCHC datagrams for the same RuleID. This is not
			used in SCHC over LoRaWAN profile. A device cannot interleave
			several fragmented SCHC datagrams on the same FPort. This field is
			not used and its size is 0.
	Note: The device can still have several parallel fragmentation		Note: The device can still have several parallel fragmented datagrams
	datagrams with one or more SCHC gateway(s) thanks to distinct sets of		with more than one SCHC gateway thanks to distinct sets of FPorts, cf
	FPorts, cf Section 5.2		Section 5.2.
	5.6.2. Uplink fragmentation: From device to SCHC gateway		5.6.2. Uplink fragmentation: From device to SCHC gateway
	In that case the device is the fragmentation transmitter, and the		In this case, the device is the fragment transmitter, and the SCHC
	SCHC gateway the fragmentation receiver. A single fragmentation rule		gateway the fragment receiver. A single fragmentation rule is
	is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to		defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to
	retrieve the SCHC Packet, as per Section 5.1.		retrieve the SCHC Packet, as per Section 5.1.
	o SCHC header size is two bytes (the FPort byte + 1 additional		o SCHC header size is two bytes (the FPort byte + 1 additional
	byte).		byte).
	o RuleID: 8 bits stored in LoRaWAN FPort.		o RuleID: 8 bits stored in LoRaWAN FPort.
	o SCHC fragmentation reliability mode: "ACK-on-Error".		o SCHC fragmentation reliability mode: "ACK-on-Error".
	o DTag: Size is 0 bit, not used.		o DTag: Size is 0 bit, not used.
	skipping to change at page 13, line 29 ¶		skipping to change at page 14, line 11 ¶
	MAY be changed by the application.		MAY be changed by the application.
	o Penultimate tile MUST be equal to the regular size.		o Penultimate tile MUST be equal to the regular size.
	o Last tile: it can be carried in a Regular SCHC Fragment, alone in		o Last tile: it can be carried in a Regular SCHC Fragment, alone in
	an All-1 SCHC Fragment or with any of these two methods.		an All-1 SCHC Fragment or with any of these two methods.
	Implementation must ensure that:		Implementation must ensure that:
	* The sender MUST ascertain that the receiver will not receive		* The sender MUST ascertain that the receiver will not receive
	the last tile through both a Regular SCHC Fragment and an All-1		the last tile through both a Regular SCHC Fragment and an All-1
	SCHC Fragment.		SCHC Fragment during the same session.
	* If last tile is in All-1 message: current L2 MTU MUST be big		* If the last tile is in All-1 SCHC message: current L2 MTU MUST
	enough to fit the All-1 and the last tile.		be big enough to fit the All-1 header and the last tile.
	With this set of parameters, the SCHC fragment header is 16 bits,		With this set of parameters, the SCHC fragment header is 16 bits,
	including FPort; payload overhead will be 8 bits as FPort is already		including FPort; payload overhead will be 8 bits as FPort is already
	a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes		a part of LoRaWAN payload. MTU is: _4 windows * 63 tiles * 10 bytes
	per tile = 2520 bytes_		per tile = 2520 bytes_
	For battery powered devices, it is RECOMMENDED to use the ACK		For battery powered devices, it is RECOMMENDED to use the ACK
	mechanism at the end of each window instead of waiting until the end		mechanism at the end of each window instead of waiting until the end
	of all windows:		of all windows:
	o SCHC receiver SHOULD send a SCHC ACK after every window even if		o the SCHC receiver SHOULD send a SCHC ACK after every window even
	there is no missing tile.		if there is no missing tile.
	o SCHC sender SHOULD wait for the SCHC ACK from the SCHC receiver		o the SCHC sender SHOULD wait for the SCHC ACK from the SCHC
	before sending tiles from the next window. If the SCHC ACK is not		receiver before sending tiles from the next window. If the SCHC
	received, it SHOULD send an SCHC ACK REQ up to MAX_ACK_REQUESTS,		ACK is not received, it SHOULD send a SCHC ACK REQ up to
	time as described previously.		MAX_ACK_REQUESTS times, as described previously.
	For non-battery powered devices, 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. It 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 behavior, and		SCHC implementations MUST be compatible with both behaviors, and this
	selection is a part of the rule context.		selection is part of the rule context.
	5.6.2.1. Regular fragments		5.6.2.1. Regular fragments
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ------------------------- +		+ ------ + ------------------------- +
	| RuleID | W | FCN | Payload |		| RuleID | W | FCN | Payload |
	+ ------ + ------ + ------ + ------- +		+ ------ + ------ + ------ + ------- +
	| 8 bits | 2 bits | 6 bits | |		| 8 bits | 2 bits | 6 bits | |
	Figure 7: All fragments except the last one. SCHC header size is 16		Figure 7: All fragments except the last one. SCHC header size is 16
	skipping to change at page 14, line 41 ¶		skipping to change at page 15, line 25 ¶
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ------------------------------------------- +		+ ------ + ------------------------------------------- +
	| RuleID | W | FCN=All-1 | RCS | Last tile |		| RuleID | W | FCN=All-1 | RCS | Last tile |
	+ ------ + ------ + --------- + ------- + ------------ +		+ ------ + ------ + --------- + ------- + ------------ +
	| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 bits |		| 8 bits | 2 bits | 6 bits | 32 bits | 1 to 80 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 |		| FPort | LoRaWAN payload |
	+ ------ + -------------------------------------------------------------------- +		+ ------ + --------------------------------- + ---------------- +
	| RuleID | W | C | Compressed bitmap(C = 0) | Optional padding(b'0...0) |		| RuleID | W | C | Compressed bitmap | Optional padding |
	+ ------ + ----- + ----- + ------------------------ + ------------------------- +		| | | | (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 10: 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 few discrete values are possible: 5, 13, 21, 29, 37,		alignment, only the following discrete values are possible for the
	45, 53, 61, 62, 63. Bitmaps of 63 bits will require 6 bits of		compressed bitmap size: 5, 13, 21, 29, 37, 45, 53, 61, 62 and 63.
	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 --> |
	skipping to change at page 15, line 33 ¶		skipping to change at page 16, line 17 ¶
	| 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 12: 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 that 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:
	* Unicast downlinks: ACK-Always.		* Unicast downlinks: ACK-Always.
	* Multicast downlinks: No-ACK, reliability has to be ensured by		* Multicast downlinks: No-ACK, reliability has to be ensured by
	the upper layer. This feature is OPTIONAL and may not be		the upper layer. This feature is OPTIONAL and may not be
	skipping to change at page 16, line 20 ¶		skipping to change at page 16, line 49 ¶
	o MAX_ACK_REQUESTS: 8.		o MAX_ACK_REQUESTS: 8.
	o Retransmission timer: See Section 5.6.3.5.		o Retransmission timer: See Section 5.6.3.5.
	o Inactivity timer: The default RECOMMENDED duration of this timer		o Inactivity timer: The default RECOMMENDED duration of this timer
	is 12 hours; this value is mainly driven by application		is 12 hours; this value is mainly driven by application
	requirements and MAY be changed by the application.		requirements and MAY be changed by the application.
	As only 1 tile is used, its size can change for each downlink, and		As only 1 tile is used, its size can change for each downlink, and
	will be maximum available MTU.		will be the currently available MTU.
	Class A devices can only receive during an RX slot, following the		Class A devices can only receive during an RX slot, following the
	transmission of an uplink. Therefore the SCHC gateway cannot		transmission of an uplink. Therefore the SCHC gateway cannot
	initiate communication (ex: new SCHC session); in order to create a		initiate communication (e.g., start a new SCHC session). In order to
	downlink opportunity it is RECOMMENDED for Class A devices to send an		create a downlink opportunity it is RECOMMENDED for Class A devices
	uplink every 24 hours when no SCHC session is started, this is		to send an uplink every 24 hours when no SCHC session is started,
	application specific and can be disabled. RECOMMENDED uplink is a		this is application specific and can be disabled. The RECOMMENDED
	LoRaWAN empty frame as defined Section 4.6. As this uplink is to		uplink is a LoRaWAN empty frame as defined Section 4.6. As this
	open an RX window any applicative uplink MAY reset this counter.		uplink is to open an RX window, any LoRaWAN uplink frame from the
			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 13: 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 |
	+ ------ + ----- + --------- + ------- + ----------------- +		+ ------ + ----- + --------- + ------- + ----------------- +
	| 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes |		| 8 bits | 1 bit | 1 bit | 32 bits | 6 bits to X bytes |
	Figure 14: All-1 SCHC Message: the last fragment.		Figure 14: All-1 SCHC Message: the last fragment.
	5.6.3.3. SCHC ACK		5.6.3.3. SCHC ACK
	skipping to change at page 17, line 37 ¶		skipping to change at page 18, line 20 ¶
	+ ------ + ------- + ------- + -------- + --------------- +		+ ------ + ------- + ------- + -------- + --------------- +
	| 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 16: 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 in 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
	transmission of an uplink.		transmission of an uplink.
	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 it, the device MUST transmit
	the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC		the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC
	ACK messages before aborting. In order to progress the fragmentation		ACK messages before aborting. In order to progress the fragmented
	datagram, the SCHC layer should immediately queue for transmission		datagram, the SCHC layer should immediately queue for transmission
	those SCHC ACK if no SCHC downlink have been received during RX1 and		those SCHC ACK if no SCHC downlink have been received during RX1 and
	RX2 window. LoRaWAN layer will respect the regulation if required.		RX2 window. LoRaWAN layer will respect the 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
	application specific. It is RECOMMENDED for a device to send an		application specific. It is RECOMMENDED for a device to send an
	empty frame (see Section 4.6) but it is application specific and will		empty frame (see Section 4.6) but it is application specific and will
	be used by the NGW to transmit a potential SCHC ACK REQ.		be used by the NGW to transmit a potential SCHC ACK REQ.
	SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its		SCHC_ACK_REQ_DN_OPPORTUNITY is application specific and its
	recommended value is 2, it MUST be greater than 1. This allows to		recommended value <<<<<<< HEAD is 2, it MUST be greater than 1. This
	open downlink opportunity to other eventual downlink with higher		allows for more downlink opportunities than required by SCHC control
	priority than SCHC ACK REQ message.		traffic, leaving opportunity for any other downlink with higher
			priority than SCHC ACK REQ message. ======= is 2. It MUST be
			greater than 1. This allows to open a downlink opportunity to any
			downlink with higher priority than the SCHC ACK REQ message. >>>>>>>
			0b92a54cc8a5551fcf289f74e1ae3637a2f1c217
	_Note_: The device MUST keep this SCHC ACK message in memory until it		_Note_: The device MUST keep this SCHC ACK message in memory until it
	receives a downlink, on SCHC FPortDown different from an SCHC ACK		receives a downlink SCHC Fragmentation Message (with FPort ==
	REQ: it indicates that the SCHC gateway has received the ACK message.		FPortDown) that is not a SCHC ACK REQ: it indicates that the SCHC
			gateway has received the SCHC ACK message.
	5.6.3.6. Class B or Class C devices		5.6.3.6. Class B or Class C devices
	Class B devices can receive in scheduled RX slots or in RX slots		Class B devices can receive in scheduled RX slots or in RX slots
	following the transmission of an uplink. Class C devices are almost		following the transmission of an uplink. Class C devices are almost
	in constant reception.		in constant reception.
	RECOMMENDED retransmission timer value:		RECOMMENDED retransmission timer value:
	o Class B: 3 times the ping slot periodicity.		o Class B: 3 times the ping slot periodicity.
	skipping to change at page 19, line 18 ¶		skipping to change at page 20, line 6 ¶
	*Uplink fragmentation (Ack-On-Error)*:		*Uplink fragmentation (Ack-On-Error)*:
	All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states		All-0 is distinguishable from a SCHC ACK REQ as [RFC8724] states
	_This condition is also met if the SCHC Fragment Header is a multiple		_This condition is also met if the SCHC Fragment Header is a multiple
	of L2 Words_; this condition met: SCHC header is 2 bytes.		of L2 Words_; this condition met: SCHC header is 2 bytes.
	*Downlink fragmentation (Ack-always)*:		*Downlink fragmentation (Ack-always)*:
	As per [RFC8724] the SCHC All-1 MUST contain the last tile,		As per [RFC8724] the SCHC All-1 MUST contain the last tile,
	implementation must ensure that All-0 message Payload will be at		implementation must ensure that SCHC All-0 message Payload will be at
	least the size of an L2 Word.		least the size of an L2 Word.
	5.7.2. All-1 SCHC fragment		5.7.2. All-1 SCHC fragment
	All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states		All-1 is distinguishable from a SCHC Sender-Abort as [RFC8724] states
	_This condition is met if the RCS is present and is at least the size		_This condition is met if the RCS is present and is at least the size
	of an L2 Word_; this condition met: RCS is 4 bytes.		of an L2 Word_; this condition met: RCS is 4 bytes.
	5.7.3. Delay after each message to respect local regulation		5.7.3. Delay after each LoRaWAN frame to respect local regulation
	This profile does not define a delay to be added after each SCHC		This profile does not define a delay to be added after each LoRaWAN
	message, local regulation compliance is expected to be enforced by		frame, local regulation compliance is expected to be enforced by
	LoRaWAN stack.		LoRaWAN stack.
	6. Security considerations		6. Security Considerations
	This document is only providing parameters that are expected to be		This document is only providing parameters that are expected to be
	best suited for LoRaWAN networks for [RFC8724]. IID security is		best suited for LoRaWAN networks for [RFC8724]. IID security is
	discussed in Section 5.3. As such, this document does not contribute		discussed in Section 5.3. As such, this document does not contribute
	to any new security issues in addition to those identified in		to any new security issues beyond those already identified in
	[RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on		[RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected at
	LoRaWAN level by an AES-128 encryption with key shared by device and		the LoRaWAN level by an AES-128 encryption with a session key shared
	SCHC gateway. Those keys are renewed at each LoRaWAN session (ie:		by the device and the SCHC gateway. These session keys are renewed
	each join or rejoin to the LoRaWAN network)		at each LoRaWAN session (ie: each join or rejoin to the LoRaWAN
			network)
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	Acknowledgements		Acknowledgements
	Thanks to all those listed in the Contributors section for the		Thanks to all those listed in the Contributors section for the
	excellent text, insightful discussions, reviews and suggestions, and		excellent text, insightful discussions, reviews and suggestions, and
	also to (in alphabetical order) Dominique Barthel, Arunprabhu		also to (in alphabetical order) Dominique Barthel, Arunprabhu
	skipping to change at page 20, line 48 ¶		skipping to change at page 21, line 37 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
	[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
	AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
	2006, <https://www.rfc-editor.org/info/rfc4493>.
	[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,		[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	RFC 8064, DOI 10.17487/RFC8064, February 2017,		RFC 8064, DOI 10.17487/RFC8064, February 2017,
	<https://www.rfc-editor.org/info/rfc8064>.		<https://www.rfc-editor.org/info/rfc8064>.
	[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
	Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
	February 2017, <https://www.rfc-editor.org/info/rfc8065>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<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>.
	10.2. Informative References		10.2. Informative References
	[lora-alliance-remote-multicast-set]		[lora-alliance-remote-multicast-set]
	Alliance, L., "LoRaWAN Remote Multicast Setup		Alliance, L., "LoRaWAN Remote Multicast Setup
	Specification Version 1.0.0", <https://lora-		Specification Version 1.0.0", <https://lora-
	alliance.org/sites/default/files/2018-09/		alliance.org/sites/default/files/2018-09/
	remote_multicast_setup_v1.0.0.pdf>.		remote_multicast_setup_v1.0.0.pdf>.
	[lora-alliance-spec]		[lora-alliance-spec]
	Alliance, L., "LoRaWAN Specification Version V1.0.3",		Alliance, L., "LoRaWAN Specification Version V1.0.3",
	<https://lora-alliance.org/sites/default/files/2018-07/		<https://lora-alliance.org/sites/default/files/2018-07/
	lorawan1.0.3.pdf>.		lorawan1.0.3.pdf>.
			[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
			AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
			2006, <https://www.rfc-editor.org/info/rfc4493>.
			[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
			Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
			February 2017, <https://www.rfc-editor.org/info/rfc8065>.
			[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
			Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
			<https://www.rfc-editor.org/info/rfc8376>.
	Appendix A. Examples		Appendix A. Examples
			In following examples "applicative payload" refers to the IPv6
			payload sent by the application to the SCHC layer.
	A.1. Uplink - Compression example - No fragmentation		A.1. Uplink - Compression example - No fragmentation
	This example represents an applicative payload going through SCHC		This example represents an applicative payload going through SCHC
	over LoRaWAN, no fragmentation required		over LoRaWAN, no fragmentation required
	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.
	skipping to change at page 23, line 32 ¶		skipping to change at page 24, line 25 ¶
	| | 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 22: 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 23: 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 message		Figure 24: 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 |
	skipping to change at page 25, line 35 ¶		skipping to change at page 26, line 35 ¶
	| 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 31: 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=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=b'00000 |		| | RuleID | W | FCN | RCS | 1 tile | Padding |
	+ ---- + --------- + ------- + ------- + ------- + ----------------- + --------------- +		| | 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 message		Figure 32: 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 33: Downlink example: LoRaWAN packet 6 - SCHC ACK
End of changes. 89 change blocks.
	201 lines changed or deleted		235 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/