< draft-ietf-lpwan-schc-over-lorawan-08.txt		draft-ietf-lpwan-schc-over-lorawan-09.txt >
	lpwan Working Group O. Gimenez, Ed.		lpwan Working Group O. Gimenez, Ed.
	Internet-Draft Semtech		Internet-Draft Semtech
	Intended status: Informational I. Petrov, Ed.		Intended status: Informational I. Petrov, Ed.
	Expires: January 13, 2021 Acklio		Expires: March 15, 2021 Acklio
	July 12, 2020		September 11, 2020
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-08		draft-ietf-lpwan-schc-over-lorawan-09
	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 LPWAN		generic header compression and fragmentation techniques for Low Power
	(Low Power Wide Area Networks) technologies. SCHC is a generic		Wide Area Networks (LPWAN) technologies. SCHC is a generic mechanism
	mechanism designed for great flexibility so that it can be adapted		designed for great flexibility so that it can be adapted for any of
	for any of the LPWAN technologies.		the LPWAN technologies.
	This document provides the adaptation of SCHC for use in LoRaWAN		This document provides the adaptation of SCHC for use 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. This is called a profile.
	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 January 13, 2021.		This Internet-Draft will expire on March 15, 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 18 ¶		skipping to change at page 2, line 18 ¶
	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 . . . . . . . . . . . . . . . . . . . . 5
	4.1. Device classes (A, B, C) and interactions . . . . . . . . 6		4.1. Device classes (A, B, C) and interactions . . . . . . . . 6
	4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 7		4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 7
	4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 7		4.3. General Frame Types . . . . . . . . . . . . . . . . . . . 8
	4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8		4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8
	4.5. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 8		4.5. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8
	4.6. Unicast and multicast technology . . . . . . . . . . . . 8		4.6. LoRaWAN empty frame . . . . . . . . . . . . . . . . . . . 9
	5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8		4.7. Unicast and multicast technology . . . . . . . . . . . . 9
	5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8		5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9		5.1. LoRaWAN FPort and RuleID . . . . . . . . . . . . . . . . 9
	5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10		5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 10
			5.3. Interface IDentifier (IID) computation . . . . . . . . . 11
	5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11		5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 12
	5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11		5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
	5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11		5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12		5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12
	5.6.3. Downlink fragmentation: From SCHC gateway to device . 15		5.6.3. Downlink fragmentation: From SCHC gateway to device . 15
	5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 18		5.7. SCHC Fragment Format . . . . . . . . . . . . . . . . . . 19
	5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 18		5.7.1. All-0 SCHC fragment . . . . . . . . . . . . . . . . . 19
	5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 18		5.7.2. All-1 SCHC fragment . . . . . . . . . . . . . . . . . 19
	5.7.3. Delay after each message to respect local regulation 18		5.7.3. Delay after each message to respect local regulation 19
	6. Security considerations . . . . . . . . . . . . . . . . . . . 18		6. Security considerations . . . . . . . . . . . . . . . . . . . 19
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		10.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Uplink - Compression example - No fragmentation . . . . . 21		A.1. Uplink - Compression example - No fragmentation . . . . . 21
	A.2. Uplink - Compression and fragmentation example . . . . . 22		A.2. Uplink - Compression and fragmentation example . . . . . 22
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification [RFC8724]		SCHC specification [RFC8724] describes generic header compression and
	describes generic header compression and fragmentation techniques		fragmentation techniques that can be used on all LPWAN technologies
	that can be used on all LPWAN (Low Power Wide Area Networks)		defined in [RFC8376]. Even though those technologies share a great
	technologies defined in [RFC8376]. Even though those technologies		number of common features like star-oriented topologies, network
	share a great number of common features like star-oriented		architecture, devices with mostly quite predictable communications,
	topologies, network architecture, devices with mostly quite		etc; they do have some slight differences in respect to payload
	predictable communications, etc; they do have some slight differences		sizes, reactiveness, etc.
	in respect to payload 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 with other Internet networks. However, for efficient
	performance, some parameters and modes of operation need to be set		performance, some parameters and modes of operation need to be set
	appropriately for each of the LPWAN technologies.		appropriately for each of the LPWAN technologies.
	This document describes the efficient parameters and modes of		This document describes the efficient parameters and modes of
	operation when SCHC is used over LoRaWAN networks.		operation when SCHC is used over LoRaWAN networks.
	2. Terminology		2. Terminology
	skipping to change at page 3, line 36 ¶		skipping to change at page 3, line 35 ¶
	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
	document. For all other definitions, please look up the SCHC		document. For all other definitions, please look up the SCHC
	specification [RFC8724].		specification [RFC8724].
	o DevEUI: an IEEE EUI-64 identifier used to identify the device		o DevEUI: an IEEE EUI-64 identifier used to identify the device
	during the procedure while joining the network (Join Procedure)		during the procedure while joining the network (Join Procedure).
			It is assigned by the manufacturer or the device owner and
			provisioned on the Network Gateway.
	o DevAddr: a 32-bit non-unique identifier assigned to a device		o DevAddr: a 32-bit non-unique identifier assigned to a device
	statically or dynamically after a Join Procedure (depending on the		either:
	activation mode)
	o RCS: Reassembly Check Sequence. Used to verify the integrity of		* Statically: by the device manufacturer in _Activation by
	the fragmentation-reassembly process		Personalization_ mode.
	o OUI: Organisation Unique Identifier. IEEE assigned prefix for EUI		* Dynamically: after a Join Procedure by the Network Gateway in
			_Over The Air Activation_ mode.
	o SCHC gateway: It corresponds to the LoRaWAN Application Server. It		o Downlink: LoRaWAN term for a message transmitted by the network
	manages translation between IPv6 network and the Network Gateway		and received by the device.
	(LoRaWAN Network Server)
			o OUI: Organisation Unique Identifier. IEEE assigned prefix for
			EUI.
			o RCS: Reassembly Check Sequence. Used to verify the integrity of
			the fragmentation-reassembly process.
			o SCHC gateway: It corresponds to the LoRaWAN Application Server.
			It manages translation between IPv6 network and the Network
			Gateway (LoRaWAN Network Server).
			o Uplink: LoRaWAN term for a message transmitted by the device and
			received by the network.
	3. Static Context Header Compression Overview		3. Static Context Header Compression Overview
	This section contains a short overview of Static Context Header		This section contains a short overview of SCHC. For a detailed
	Compression (SCHC). For a detailed description, refer to the full		description, refer to the full specification [RFC8724].
	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 are
	part of the "context"		part of the "context". This component is called SCHC Compressor/
			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		small, and potentially variable, MTU. This component called 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 4, line 44 ¶		skipping to change at page 5, line 10 ¶
	+---+ +----+ |F/R | |C/D |		+---+ +----+ |F/R | |C/D |
	+----+ +----+		+----+ +----+
	Figure 1: Architecture		Figure 1: Architecture
	Figure 1 represents the architecture for compression/decompression,		Figure 1 represents the architecture for compression/decompression,
	it is based on [RFC8376] terminology. The device is sending		it is based on [RFC8376] terminology. The device is sending
	applications flows using IPv6 or IPv6/UDP protocols. These flows		applications flows using IPv6 or IPv6/UDP protocols. These flows
	might be compressed by a Static Context Header Compression		might be compressed by a Static Context Header Compression
	Compressor/Decompressor (SCHC C/D) to reduce headers size and		Compressor/Decompressor (SCHC C/D) to reduce headers size and
	fragmented (SCHC F/R). The resulting information is sent on a layer		fragmented by the SCHC Fragmentation/Reassembly (SCHC F/R). The
	two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the		resulting information is sent on a layer two (L2) frame to an LPWAN
	frame to a Network Gateway (NGW). The NGW sends the data to a SCHC		Radio Gateway (RGW) that forwards the frame to a Network Gateway
	F/R for reassembly, if required, then to SCHC C/D for decompression.		(NGW). The NGW sends the data to a SCHC F/R for reassembly, if
	The C/D shares the same rules with the device. The SCHC F/R and C/D		required, then to SCHC C/D for decompression. The SCHC C/D shares
	can be located on the Network Gateway (NGW) or in another place as		the same rules with the device. The SCHC C/D and F/R can be located
	long as a tunnel is established between the NGW and the SCHC F/R,		on the Network Gateway (NGW) or in another place as long as a
	then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share		communication is established between the NGW and the SCHC F/R, then
	the same set of rules. After decompression, the packet can be sent		SCHC F/R and C/D. The SCHC C/D and F/R in the device and the SCHC
	on the Internet to one or several LPWAN Application Servers (App).		gateway MUST share the same set of rules. After decompression, the
			packet can be sent on the Internet to one or several LPWAN
			Application Servers (App).
	The SCHC F/R and SCHC C/D process is bidirectional, so the same		The SCHC C/D and F/R process is bidirectional, so the same principles
	principles can be applied in the other direction.		can be applied in the other direction.
	In a LoRaWAN network, the RG is called a Gateway, the NGW is Network		In a LoRaWAN network, the RG is called a Gateway, the NGW is Network
	Server, and the SCHC C/D and SCHC F/R are an Application Server. It		Server, and the SCHC C/D and F/R are an Application Server. It can
	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|
	| | | | | | | |		| | | | | | | |
	|SCHC C/D & F/R| | | | | | |		|SCHC C/D & F/R| | | | | | |
	skipping to change at page 5, line 50 ¶		skipping to change at page 6, line 18 ¶
	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 Internet. This entity maps to the LoRaWAN
	Network Server.		Network Server.
	o SCHC F/R and SCHC C/D are LoRaWAN Application Server; ie the		o SCHC C/D and F/R are LoRaWAN Application Server; ie the LoRaWAN
	LoRaWAN application server will do the C/D and F/R.		application server will do the SCHC C/D and F/R.
	() () () | +------+		() () () | +------+
	() () () () / \ +---------+ | Join |		() () () () / \ +---------+ | Join |
	() () () () () / \======| ^ |===|Server| +-----------+		() () () () () / \======| ^ |===|Server| +-----------+
	() () () | | <--|--> | +------+ |Application|		() () () | | <--|--> | +------+ |Application|
	() () () () / \==========| v |=============| Server |		() () () () / \==========| v |=============| Server |
	() () () / \ +---------+ +-----------+		() () () / \ +---------+ +-----------+
	End Devices Gateways Network Server		End Devices Gateways Network Server
	Figure 3: LPWAN Architecture		Figure 3: LPWAN Architecture
	SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/		SCHC Compressor/Decompressor (SCHC C/D) and SCHC Fragmentation/
	Reassembly) 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 single
	IP hop, the ultimate end-point of the IP communication may be an		IP hop, the ultimate end-point of the IP communication may be an
	Internet node beyond the Application Server. In other words, the		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
	skipping to change at page 6, line 39 ¶		skipping to change at page 7, line 8 ¶
	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.
	o Class A: The Class A is the simplest class of devices. The device		o Class A: The Class A is the simplest class of devices. The device
	is allowed to transmit at any time, randomly selecting a		is allowed to transmit at any time, randomly selecting a
	communication channel. The Network Gateway may reply with a		communication channel. The Network Gateway may reply with a
	downlink in one of the 2 receive windows immediately following the		downlink in one of the 2 receive windows immediately following the
	uplinks. Therefore, the Network Gateway cannot initiate a		uplinks. Therefore, the Network Gateway cannot initiate a
	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
	device 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. The lower the downlink latency,
	the higher the power consumption.		the higher the power consumption.
	skipping to change at page 7, line 39 ¶		skipping to change at page 8, line 14 ¶
	+--------+ +---------+ +---------+ +----------+		+--------+ +---------+ +---------+ +----------+
	| 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
	o LoRaWAN Confirmed message: The sender asks the receiver to		LoRaWAN implements the possibility to send confirmed or unconfirmed
	acknowledge the message.		messages:
	o LoRaWAN Unconfirmed message: The sender does not ask the receiver		o Confirmed message: The sender asks the receiver to acknowledge the
	to acknowledge the message.		message.
			o Unconfirmed message: The sender does not ask the receiver to
			acknowledge the message.
	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 messages.
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
			In addition to regular data frames LoRaWAN implements JoinRequest and
			JoinAccept frame types, used by a device to join a network:
	o JoinRequest: This message is used by a device to join a network.		o JoinRequest: This message is used by a device to join a network.
	It contains the device's unique identifier DevEUI and a random		It contains the device's unique identifier DevEUI and a random
	nonce that will be used for session key derivation.		nonce 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 message.
	That message is encrypted with the device's AppKey and contains		That message is encrypted with the device's AppKey and contains
	(amongst other fields) the major network's settings and a random		(amongst other fields) the major network's settings and a random
	nonce used to derive the session keys.		nonce used 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 empty frame		4.5. LoRaWAN FPort
	A LoRaWAN empty frame is a LoRaWAN message without FPort and		The LoRaWAN MAC layer features a frame port field in all frames.
	FRMPayload.		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.
	4.6. Unicast and multicast technology		4.6. LoRaWAN empty frame
			A LoRaWAN empty frame is a LoRaWAN message without FPort (cf
			Section 5.1) and FRMPayload.
			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 send 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 RECOMMENDED way to setup multicast groups on devices and create a
	synchronized reception window.		synchronized reception window.
	5. SCHC-over-LoRaWAN		5. SCHC-over-LoRaWAN
	5.1. LoRaWAN FPort		5.1. LoRaWAN FPort and RuleID
	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
	used. It allows LoRaWAN networks and applications to identify data.
	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 retrieve their payload as it is used as a part
	of the RuleID field.		of the RuleID field.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------------------------ +		+ ------------------------ +
	| SCHC packet |		| SCHC packet |
	skipping to change at page 9, line 42 ¶		skipping to change at page 10, line 22 ¶
	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 RuleID
	values are:		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)		(no matching rule was found).
	The remaining RuleIDs are available for compression. RuleIDs are		The remaining RuleIDs are available for compression. RuleIDs are
	shared between uplink and downlink sessions. A RuleID not in the		shared between uplink and downlink sessions. A RuleID not in the
	set(s) of FPortUp or FPortDown means that the fragmentation is not		set(s) of FPortUp or FPortDown means that the fragmentation is not
	used, thus, on reception, the SCHC Message MUST be sent to the C/D		used, thus, on reception, the SCHC Message MUST be sent to the SCHC
	layer.		C/D layer.
	The only uplink messages using the FPortDown port are the		The only uplink messages using the FPortDown port are the
	fragmentation SCHC control messages of a downlink fragmentation		fragmentation SCHC control messages of a downlink fragmentation
	datagram (for example, SCHC ACKs). Similarly, the only downlink		datagram (for example, SCHC ACKs). Similarly, the only downlink
	messages using the FPortUp port are the fragmentation SCHC control		messages using the FPortUp port are the fragmentation SCHC control
	messages of an uplink fragmentation datagram.		messages of an uplink fragmentation datagram.
	An application can have multiple fragmentation datagrams between a		An application can have multiple fragmentation 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 fragmentation 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 sharing those RuleID values is outside the scope of
	this document.		this document.
	5.3. IID computation		5.3. Interface IDentifier (IID) computation
	In order to mitigate risks described in [RFC8064] and [RFC8065] IID		In order to mitigate risks described in [RFC8064] and [RFC8065] IID
	MUST be created regarding the following algorithm:		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]
	skipping to change at page 12, line 17 ¶		skipping to change at page 12, line 46 ¶
	In that case the device is the fragmentation transmitter, and the		In that case the device is the fragmentation transmitter, and the
	SCHC gateway the fragmentation receiver. A single fragmentation rule		SCHC gateway the fragmentation receiver. A single fragmentation rule
	is defined. SCHC F/R MUST concatenate FPort and LoRaWAN payload to		is 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.
	o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63		o FCN: The FCN field is encoded on N = 6 bits, so WINDOW_SIZE = 63
	tiles are allowed in a window		tiles are allowed in a window.
	o Window index: encoded on W = 2 bits. So 4 windows are available.		o Window index: encoded on W = 2 bits. So 4 windows are available.
	o RCS: Use recommended calculation algorithm in [RFC8724].		o RCS: Use recommended calculation algorithm in [RFC8724].
	o MAX_ACK_REQUESTS: 8		o MAX_ACK_REQUESTS: 8.
	o Tile: size is 10 bytes		o Tile: size is 10 bytes.
	o Retransmission timer: Set by the implementation depending on the		o Retransmission timer: Set by the implementation depending on the
	application requirements.		application requirements.
	o Inactivity timer: The SCHC gateway implements an "inactivity		o Inactivity timer: The SCHC gateway implements an "inactivity
	timer". The default RECOMMENDED duration of this timer is 12		timer". The default RECOMMENDED duration of this timer is 12
	hours; this value is mainly driven by application requirements and		hours; this value is mainly driven by application requirements and
	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.
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 5 ¶
	* 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
	implemented by SCHC gateway.		implemented by SCHC gateway.
	o RuleID: 8 bits stored in LoRaWAN FPort.		o RuleID: 8 bits stored in LoRaWAN FPort.
	o Window index (unicast only): encoded on W=1 bit, as per [RFC8724].		o Window index (unicast only): encoded on W=1 bit, as per [RFC8724].
	o DTag: Size is 0 bit, not used		o DTag: Size is 0 bit, not used.
	o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile		o FCN: The FCN field is encoded on N=1 bit, so WINDOW_SIZE = 1 tile.
	o RCS: Use recommended calculation algorithm in [RFC8724].		o RCS: Use recommended calculation algorithm in [RFC8724].
	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 maximum 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 (ex: new SCHC session); in order to create a
	downlink opportunity it is RECOMMENDED for Class A devices to send an		downlink opportunity it is RECOMMENDED for Class A devices to send an
	uplink every 24 hours when no SCHC session is started, this is		uplink every 24 hours when no SCHC session is started, this is
	application specific and can be disabled. RECOMMENDED uplink is a		application specific and can be disabled. RECOMMENDED uplink is a
	LoRaWAN empty frame as defined Section 4.5. As this uplink is to		LoRaWAN empty frame as defined Section 4.6. As this uplink is to
	open an RX window any applicative uplink MAY reset this counter.		open an RX window any applicative uplink 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 |
	+ ------ + ------------------------------------ +		+ ------ + ------------------------------------ +
	skipping to change at page 17, line 23 ¶		skipping to change at page 18, line 8 ¶
	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 fragment but the last have an FCN=0 (because		*SCHC All-0 (FCN=0)* All fragments but the last have an FCN=0
	window size is 1). Following it the device MUST transmit the SCHC		(because window size is 1). Following it the device MUST transmit
	ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC ACK		the SCHC ACK message. It MUST transmit up to MAX_ACK_REQUESTS SCHC
	messages before aborting. In order to progress the fragmentation		ACK messages before aborting. In order to progress the fragmentation
	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 regulation if required.
	_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.5) 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 is 2, it MUST be greater than 1. This allows to
	open downlink opportunity to other eventual downlink with higher		open downlink opportunity to other eventual downlink with higher
	priority than SCHC ACK REQ message.		priority than SCHC ACK REQ message.
	_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, on SCHC FPortDown different from an SCHC ACK
	REQ: it indicates that the SCHC gateway has received the ACK message.		REQ: it indicates that the SCHC gateway has received the 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.
	o Class C: 30 seconds		o Class C: 30 seconds.
	The RECOMMENDED inactivity timer value is 12 hours for both Class B		The RECOMMENDED inactivity timer value is 12 hours for both Class B
	and Class C devices.		and Class C devices.
	5.7. SCHC Fragment Format		5.7. SCHC Fragment Format
	5.7.1. All-0 SCHC fragment		5.7.1. All-0 SCHC fragment
	*Uplink fragmentation (Ack-On-Error)*:		*Uplink fragmentation (Ack-On-Error)*:
	skipping to change at page 19, line 10 ¶		skipping to change at page 19, line 44 ¶
	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 in addition to those identified in
	[RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on		[RFC8724]. Moreover, SCHC data (LoRaWAN payload) are protected on
	LoRaWAN level by an AES-128 encryption with key shared by device and		LoRaWAN level by an AES-128 encryption with key shared by device and
	SCHC gateway. Those keys are renewed at each LoRaWAN session (ie:		SCHC gateway. Those keys are renewed at each LoRaWAN session (ie:
	each join or rejoin to the LoRaWAN network)		each join or rejoin to the LoRaWAN network)
			7. IANA Considerations
			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
	Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent		Kandasamy, Rodrigo Munoz, Alexander Pelov, Pascal Thubert, Laurent
	Toutain for useful design considerations, reviews and comments.		Toutain for useful design considerations, reviews and comments.
	Contributors		Contributors
	skipping to change at page 19, line 46 ¶		skipping to change at page 20, line 35 ¶
	Email: marc.legourrierec@sagemcom.com		Email: marc.legourrierec@sagemcom.com
	Nicolas Sornin		Nicolas Sornin
	Semtech		Semtech
	Email: nsornin@semtech.com		Email: nsornin@semtech.com
	Alper Yegin		Alper Yegin
	Actility		Actility
	Email: alper.yegin@actility.com		Email: alper.yegin@actility.com
	9. References		10. References
	9.1. Normative References
			10.1. Normative References
	[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>.
	[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
	"Internet Protocol Small Computer System Interface (iSCSI)
	Cyclic Redundancy Check (CRC)/Checksum Considerations",
	RFC 3385, DOI 10.17487/RFC3385, September 2002,
	<https://www.rfc-editor.org/info/rfc3385>.
	[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		[RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
	AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June		AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June
	2006, <https://www.rfc-editor.org/info/rfc4493>.		2006, <https://www.rfc-editor.org/info/rfc4493>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.
	[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
	Header Compression (ROHC) Framework", RFC 5795,
	DOI 10.17487/RFC5795, March 2010,
	<https://www.rfc-editor.org/info/rfc5795>.
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	[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-		[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
	Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,		Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
	February 2017, <https://www.rfc-editor.org/info/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
	skipping to change at page 21, line 15 ¶		skipping to change at page 21, line 28 ¶
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/info/rfc8724>.		<https://www.rfc-editor.org/info/rfc8724>.
	9.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>.
	Appendix A. Examples		Appendix A. Examples
	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 C/D layer, allowing to compress it to 40		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload.		40 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes
			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 17: 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 =
	skipping to change at page 22, line 20 ¶		skipping to change at page 22, line 31 ¶
	| 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 18: 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 C/D layer, allowing to compress it to 282		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload.		282 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes
			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 19: 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
	skipping to change at page 22, line 45 ¶		skipping to change at page 23, line 8 ¶
	+ -------------------------- + -------------------------- +		+ -------------------------- + -------------------------- +
	| | 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 20: 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 byte + 3 bits |		| 1 | 21 bits | 6 bytes + 3 bits |
	Figure 21: Uplink example: LoRaWAN packet 1 - Tile content		Figure 21: 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:
	skipping to change at page 24, line 8 ¶		skipping to change at page 24, line 16 ¶
	+ -------------- + --------- + ------------------- +		+ -------------- + --------- + ------------------- +
	| | 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 25: 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 C/D layer, allowing to compress it to 130		layer. Rule 1 is used by SCHC C/D layer, allowing to compress it to
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload.		130 bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes
			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 26: 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.
End of changes. 59 change blocks.
	136 lines changed or deleted		150 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/