rfc9011v3.txt		rfc9011.txt
	skipping to change at line 111 ¶		skipping to change at line 111 ¶
	some slight differences with respect to payload sizes, reactiveness,		some slight differences with respect to payload sizes, reactiveness,
	etc.		etc.
	SCHC provides a generic framework that enables those devices to		SCHC provides a generic framework that enables those devices to
	communicate on IP networks. However, for efficient performance, some		communicate on IP networks. However, for efficient performance, some
	parameters and modes of operation need to be set appropriately for		parameters and modes of operation need to be set appropriately for
	each of the LPWAN technologies.		each of the LPWAN technologies.
	This document describes the parameters and modes of operation when		This document describes the parameters and modes of operation when
	SCHC is used over LoRaWAN networks. The LoRaWAN protocol is		SCHC is used over LoRaWAN networks. The LoRaWAN protocol is
	specified by the LoRa Alliance in [LORA-SPEC].		specified by the LoRa Alliance in [LORAWAN-SPEC].
	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		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 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 abbreviations used in this		This section defines the terminology and abbreviations 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].
			| Note: The SCHC acronym is pronounced like "sheek" in English
			| (or "chic" in French). Therefore, this document writes "a SCHC
			| Packet" instead of "an SCHC Packet".
	AppKey: Application Key. An AES-128 root key specific to each		AppKey: Application Key. An AES-128 root key specific to each
	device.		device.
	AppSKey: Application Session Key. An AES-128 key derived from the		AppSKey: Application Session Key. An AES-128 key derived from the
	AppKey for each new session. It is used to encrypt the payload		AppKey for each new session. It is used to encrypt the payload
	field of a LoRaWAN applicative frame.		field of a LoRaWAN applicative frame.
	DevAddr: A 32-bit non-unique identifier assigned to a device either:		DevAddr: A 32-bit non-unique identifier assigned to a device either:
	Statically: by the device manufacturer in "Activation-by-		Statically: by the device manufacturer in "Activation-by-
	skipping to change at line 230 ¶		skipping to change at line 234 ¶
	+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....		+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....
	+---+ +----+ |F/R | |C/D |		+---+ +----+ |F/R | |C/D |
	+----+ +----+		+----+ +----+
	|<- - - - LoRaWAN - - ->|		|<- - - - LoRaWAN - - ->|
	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 the terminology from [RFC8376]. The device is sending		it is based on the terminology from [RFC8376]. The device is sending
	application flows using IPv6 or IPv6/UDP protocols. These flows		application flows using IPv6 or IPv6/UDP protocols. These flows
	might be compressed by an SCHC C/D to reduce header size, and		might be compressed by a SCHC C/D to reduce header size, and
	fragmented by the SCHC F/R. The resulting information is sent on a		fragmented by the SCHC F/R. The resulting information is sent on a
	Layer 2 (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the		Layer 2 (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the
	frame to a Network Gateway (NGW). The NGW sends the data to an SCHC		frame to a Network Gateway (NGW). The NGW sends the data to a SCHC
	F/R for reassembly, if required, then to an SCHC C/D for		F/R for reassembly, if required, then to a SCHC C/D for
	decompression. The SCHC C/D shares the same rules with the device.		decompression. The SCHC C/D shares the same rules with the device.
	The SCHC C/D and SCHC F/R can be located on the NGW or in another		The SCHC C/D and SCHC F/R can be located on the NGW or in another
	place as long as a communication is established between the NGW and		place as long as a communication is established between the NGW and
	the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D and SCHC F/R		the SCHC F/R, then SCHC F/R and SCHC C/D. The SCHC C/D and SCHC F/R
	in the device and the SCHC gateway MUST share the same set of rules.		in the device and the SCHC gateway MUST share the same set of rules.
	After decompression, the packet can be sent on the Internet to one or		After decompression, the packet can be sent on the Internet to one or
	several LPWAN Application Servers (App).		several LPWAN Application Servers (App).
	The SCHC C/D and SCHC F/R process is bidirectional, so the same		The SCHC C/D and SCHC F/R process is bidirectional, so the same
	principles can be applied to the other direction.		principles can be applied to the other direction.
	skipping to change at line 272 ¶		skipping to change at line 276 ¶
	+~ |Gateway| == |Network| == |Application|..... Internet ....		+~ |Gateway| == |Network| == |Application|..... Internet ....
	+-------+ |server | |server |		+-------+ |server | |server |
	+-------+ | F/R - C/D |		+-------+ | F/R - C/D |
	+-----------+		+-----------+
	|<- - - - - LoRaWAN - - - ->|		|<- - - - - LoRaWAN - - - ->|
	Figure 2: SCHC Architecture Mapped to LoRaWAN		Figure 2: SCHC Architecture Mapped to LoRaWAN
	4. LoRaWAN Architecture		4. LoRaWAN Architecture
	An overview of the LoRaWAN protocol and architecture [LORA-SPEC] is		An overview of the LoRaWAN protocol and architecture [LORAWAN-SPEC]
	described in [RFC8376]. The mapping between the LPWAN architecture		is described in [RFC8376]. The mapping between the LPWAN
	entities as described in [RFC8724] and the ones in [LORA-SPEC] is as		architecture entities as described in [RFC8724] and the ones in
	follows:		[LORAWAN-SPEC] is as follows:
	* Devices are LoRaWAN End Devices (e.g., sensors, actuators, etc.).		* 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.
	* The RGW is the endpoint of the constrained link. This entity maps		* The RGW is the endpoint of the constrained link. This entity maps
	to the LoRaWAN Gateway.		to the LoRaWAN Gateway.
	* The NGW is the interconnection node between the Radio Gateway and		* The NGW is the interconnection node between the Radio Gateway and
	the SCHC gateway (LoRaWAN Application Server). This entity maps		the SCHC gateway (LoRaWAN Application Server). This entity maps
	skipping to change at line 361 ¶		skipping to change at line 365 ¶
	Class C: Class C devices implement all the functionalities of Class		Class C: Class C devices implement all the functionalities of Class
	A devices but keep their receiver open whenever they are not		A devices but keep their receiver open whenever they are not
	transmitting. Class C devices can receive downlinks at any time		transmitting. Class C devices can receive downlinks at any time
	at the expense of a higher power consumption. Battery-powered		at the expense of a higher power consumption. Battery-powered
	devices can only operate in Class C for a limited amount of time		devices can only operate in Class C for a limited amount of time
	(for example, for a firmware upgrade over-the-air). Most of the		(for example, for a firmware upgrade over-the-air). Most of the
	Class C devices are grid powered (for example, Smart Plugs).		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. For example, a 24-bit OUI is concatenated with		vendor unique number. For example, a 24-bit OUI is concatenated with
	a 40-bit serial number. The Network Gateway translates the devAddr		a 40-bit serial number. The Network Gateway translates the DevAddr
	into a DevEUI in the uplink direction and reciprocally on the		into a DevEUI in the uplink direction and reciprocally on the
	downlink direction.		downlink 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
	frames:		frames:
	Confirmed frame: The sender asks the receiver to acknowledge the		Confirmed frame: The sender asks the receiver to acknowledge the
	frame.		frame.
	Unconfirmed frame: The sender does not ask the receiver to		Unconfirmed frame: The sender does not ask the receiver to
	acknowledge the frame.		acknowledge the frame.
	As SCHC defines its own acknowledgment mechanisms, SCHC does not		As SCHC defines its own acknowledgment mechanisms, SCHC does not
	require the use of LoRaWAN Confirmed frames (FType = 0b100 as per		require the use of LoRaWAN Confirmed frames (FType = 0b100 as per
	[LORA-SPEC]).		[LORAWAN-SPEC]).
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	In addition to regular data frames, LoRaWAN implements JoinRequest		In addition to regular data frames, LoRaWAN implements JoinRequest
	and JoinAccept frame types, which are used by a device to join a		and JoinAccept frame types, which are used by a device to join a
	network:		network:
	JoinRequest: This frame is used by a device to join a network. It		JoinRequest: This frame is used by a device to join a network. It
	contains the device's unique identifier DevEUI and a random nonce		contains the device's unique identifier DevEUI and a random nonce
	that will be used for session key derivation.		that will be used for session key derivation.
	skipping to change at line 446 ¶		skipping to change at line 450 ¶
	several devices. It is useful to address many devices with the same		several devices. It is useful to address many devices with the same
	content: either a large binary file (firmware upgrade) or the same		content: either a large binary file (firmware upgrade) or the same
	command (e.g., lighting control). As IPv6 is also a multicast		command (e.g., lighting control). As IPv6 is also a multicast
	technology, this feature can be used to address a group of devices.		technology, this feature can be used to address a group of devices.
	| Note 1: IPv6 multicast addresses must be defined as per		| Note 1: IPv6 multicast addresses must be defined as per
	| [RFC4291]. The LoRaWAN multicast group definition in a Network		| [RFC4291]. The LoRaWAN multicast group definition in a Network
	| Gateway and the relation between those groups and IPv6 groupID		| Gateway and the relation between those groups and IPv6 groupID
	| are out of scope of this document.		| are out of scope of this document.
	| Note 2: The LoRa Alliance defined [LORA-REMOTE-MULTICAST-SET]		| Note 2: The LoRa Alliance defined
	| as the RECOMMENDED way to set up multicast groups on devices		| [LORAWAN-REMOTE-MULTICAST-SET] as the RECOMMENDED way to set up
	| and create a synchronized reception window.		| multicast groups on devices and 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 recompose the SCHC Message.		the LoRaWAN payload to recompose the SCHC Message.
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	skipping to change at line 477 ¶		skipping to change at line 482 ¶
	A fragmented datagram with application payload transferred from		A fragmented datagram with application payload transferred from
	device to Network Gateway is called an "uplink-fragmented datagram".		device to Network Gateway is called an "uplink-fragmented datagram".
	It uses an FPort for data uplink and its associated SCHC control		It uses an FPort for data uplink and its associated SCHC control
	downlinks, named "FPortUp" in this document. The other way, a		downlinks, named "FPortUp" in this document. The other way, a
	fragmented datagram with application payload transferred from Network		fragmented datagram with application payload transferred from Network
	Gateway to device is called a "downlink-fragmented datagram". It		Gateway to device is called a "downlink-fragmented datagram". It
	uses another FPort for data downlink and its associated SCHC control		uses another FPort for data downlink and its associated SCHC control
	uplinks, named "FPortDown" in this document.		uplinks, named "FPortDown" in this document.
	All RuleIDs can use arbitrary values inside the FPort range allowed		All RuleIDs can use arbitrary values inside the FPort range allowed
	by the LoRaWAN specification [LORA-SPEC] and MUST be shared by the		by the LoRaWAN specification [LORAWAN-SPEC] and MUST be shared by the
	device and SCHC gateway prior to the communication with the selected		device and SCHC gateway prior to the communication with the selected
	rule. The uplink and downlink fragmentation FPorts MUST be		rule. The uplink and downlink fragmentation FPorts MUST be
	different.		different.
	5.2. RuleID Management		5.2. RuleID Management
	The RuleID MUST be 8 bits and encoded in the LoRaWAN FPort as		The RuleID MUST be 8 bits and encoded in the LoRaWAN FPort as
	described in Section 5.1. LoRaWAN supports up to 223 application		described in Section 5.1. LoRaWAN supports up to 223 application
	FPorts in the range [1..223] as defined in Section 4.3.2 of		FPorts in the range [1..223] as defined in Section 4.3.2 of
	[LORA-SPEC]; it implies that the RuleID MSB SHOULD be inside this		[LORAWAN-SPEC]; it implies that the RuleID MSB SHOULD be inside this
	range. An application can send non-SCHC traffic by using FPort		range. An application can send non-SCHC traffic by using FPort
	values different from the ones used for SCHC.		values different from the ones used for SCHC.
	In order to improve interoperability, RECOMMENDED fragmentation		In order to improve interoperability, RECOMMENDED fragmentation
	RuleID values are:		RuleID values are:
	* RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.		* RuleID = 20 (8-bit) for uplink fragmentation, named FPortUp.
	* RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.		* RuleID = 21 (8-bit) for downlink fragmentation, named FPortDown.
	skipping to change at line 670 ¶		skipping to change at line 675 ¶
	Header is 16 bits, including FPort; payload overhead will be 8		Header is 16 bits, including FPort; payload overhead will be 8
	bits as FPort is already a part of LoRaWAN payload. MTU is: 4		bits as FPort is already a part of LoRaWAN payload. MTU is: 4
	windows * 63 tiles * 10 bytes per tile = 2520 bytes.		windows * 63 tiles * 10 bytes per tile = 2520 bytes.
	In addition to the per-rule context parameters specified in		In addition to the per-rule context parameters specified in
	[RFC8724], for uplink rules, an additional context parameter is		[RFC8724], for uplink rules, an additional context parameter is
	added: whether or not to ack after each window. For battery powered		added: whether or not to ack after each window. For battery powered
	devices, it is RECOMMENDED to use the ACK mechanism at the end of		devices, it is RECOMMENDED to use the ACK mechanism at the end of
	each window instead of waiting until the end of all windows:		each window instead of waiting until the end of all windows:
	* The SCHC receiver SHOULD send an SCHC ACK after every window even		* The SCHC receiver SHOULD send a SCHC ACK after every window even
	if there is no missing tile.		if there is no missing tile.
	* The SCHC sender SHOULD wait for the SCHC ACK from the SCHC		* The SCHC sender SHOULD wait for the SCHC ACK from the SCHC
	receiver before sending tiles from the next window. If the SCHC		receiver before sending tiles from the next window. If the SCHC
	ACK is not received, it SHOULD send an SCHC ACK REQ up to		ACK is not received, it SHOULD send a SCHC ACK REQ up to
	MAX_ACK_REQUESTS times, as described previously.		MAX_ACK_REQUESTS times, as described previously.
	This will avoid useless uplinks if the device has lost network		This will avoid useless uplinks if the device has lost network
	coverage.		coverage.
	For non-battery powered devices, the SCHC receiver MAY also choose to		For non-battery powered devices, the SCHC receiver MAY also choose to
	send an SCHC ACK only at the end of all windows. This will reduce		send a SCHC ACK only at the end of all windows. This will reduce
	downlink load on the LoRaWAN network by reducing the number of		downlink load on the LoRaWAN network by reducing the number of
	downlinks.		downlinks.
	SCHC implementations MUST be compatible with both behaviors, and this		SCHC implementations MUST be compatible with both behaviors, and this
	selection is part of the rule context.		selection is part of the rule context.
	5.6.2.1. Regular Fragments		5.6.2.1. Regular Fragments
	Figure 7 is an example of a regular frament for all fragments except		Figure 7 is an example of a regular fragment for all fragments except
	the last one. SCHC Header Size is 16 Bits, including the LoRaWAN		the last one. SCHC Header Size is 16 Bits, including the LoRaWAN
	FPort.		FPort.
	| 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.		Figure 7: All Fragments Except the Last One.
	skipping to change at line 826 ¶		skipping to change at line 831 ¶
	uplink is sent only to open an RX window, any LoRaWAN uplink frame		uplink is sent only to open an RX window, any LoRaWAN uplink frame
	from the device MAY reset this counter.		from the device MAY reset this counter.
	| Note: The FPending bit included in the LoRaWAN protocol SHOULD		| Note: The FPending bit included in the LoRaWAN protocol SHOULD
	| NOT be used for the SCHC-over-LoRaWAN protocol. It might be		| NOT be used for the SCHC-over-LoRaWAN protocol. It might be
	| set by the Network Gateway for other purposes but not SCHC		| set by the Network Gateway for other purposes but not SCHC
	| needs.		| needs.
	5.6.3.1. Regular Fragments		5.6.3.1. Regular Fragments
	Figure 14 is an example of a regular frament for all fragments except		Figure 14 is an example of a regular fragment for all fragments
	the last one. SCHC Header Size is 10 Bits, including the LoRaWAN		except the last one. SCHC Header Size is 10 Bits, including the
	FPort.		LoRaWAN FPort.
	| 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 14: All Fragments but the Last One.		Figure 14: All Fragments but the Last One.
	5.6.3.2. Last Fragment (All-1)		5.6.3.2. Last Fragment (All-1)
	skipping to change at line 929 ¶		skipping to change at line 934 ¶
	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		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.		will 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 the		recommended value is 2. It MUST be greater than 1. This allows the
	opening of a downlink opportunity to any downlink with higher		opening of a downlink opportunity to any downlink with higher
	priority than the SCHC ACK REQ message.		priority than the SCHC ACK REQ message.
	| Note: The device MUST keep this SCHC ACK message in memory		| Note: The device MUST keep this SCHC ACK message in memory
	| until it receives a downlink SCHC Fragmentation Message (with		| until it receives a downlink SCHC Fragmentation Message (with
	| FPort == FPortDown) that is not an SCHC ACK REQ; this indicates		| FPort == FPortDown) that is not a SCHC ACK REQ; this indicates
	| that the SCHC gateway has received the SCHC ACK message.		| 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 values are:		RECOMMENDED retransmission timer values are:
	skipping to change at line 953 ¶		skipping to change at line 958 ¶
	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)*:
	All-0 is distinguishable from an 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", the following condition being met: SCHC header is 2		of L2 Words", the following condition being met: SCHC header is 2
	bytes.		bytes.
	*Downlink fragmentation (ACK-Always)*:		*Downlink fragmentation (ACK-Always)*:
	As per [RFC8724], SCHC All-1 MUST contain the last tile, and		As per [RFC8724], SCHC All-1 MUST contain the last tile, and
	implementations must ensure that SCHC All-0 message Payload will be		implementations MUST ensure that SCHC All-0 message Payload will be
	at least the size of an L2 Word.		at 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 an SCHC Sender-Abort, as [RFC8724]		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		states "This condition is met if the RCS is present and is at least
	the size of an L2 Word", the following condition being met: RCS is 4		the size of an L2 Word", the following condition being met: RCS is 4
	bytes.		bytes.
	5.7.3. Delay after Each LoRaWAN Frame 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 LoRaWAN		This profile does not define a delay to be added after each LoRaWAN
	frame; local regulation compliance is expected to be enforced by the		frame; local regulation compliance is expected to be enforced by the
	LoRaWAN stack.		LoRaWAN stack.
	skipping to change at line 997 ¶		skipping to change at line 1002 ¶
	network).		network).
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[LORA-SPEC]		[LORAWAN-SPEC]
	LoRa Alliance, "LoRaWAN 1.0.4 Specification Package",		LoRa Alliance, "LoRaWAN 1.0.4 Specification Package",
	<https://lora-alliance.org/resource_hub/lorawan-104-		<https://lora-alliance.org/resource_hub/lorawan-104-
	specification-package/>.		specification-package/>.
	[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
	skipping to change at line 1027 ¶		skipping to change at line 1032 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zúñiga, "SCHC: Generic Framework for Static Context Header		Zúñiga, "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>.
	8.2. Informative References		8.2. Informative References
	[LORA-REMOTE-MULTICAST-SET]		[LORAWAN-REMOTE-MULTICAST-SET]
	LoRa Alliance, "LoRaWAN Remote Multicast Setup		LoRa Alliance, "LoRaWAN Remote Multicast Setup
	Specification v1.0.0", <https://lora-		Specification v1.0.0", <https://lora-
	alliance.org/resource_hub/lorawan-remote-multicast-setup-		alliance.org/resource_hub/lorawan-remote-multicast-setup-
	specification-v1-0-0/>.		specification-v1-0-0/>.
	[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>.
	skipping to change at line 1202 ¶		skipping to change at line 1207 ¶
	Figure 29: Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1		Figure 29: Downlink Example: LoRaWAN Packet 1 - SCHC Fragment 1
	The tile content is described in Figure 30		The tile content is described in Figure 30
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + ------------------ +		+ ------ + ------------------- + ------------------ +
	| 1 | 21 bits | 48 bytes and 1 bit |		| 1 | 21 bits | 48 bytes and 1 bit |
	Figure 30: Downlink Example: First Tile Content		Figure 30: Downlink Example: First Tile Content
	The receiver answers with an SCHC ACK:		The receiver answers with a SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 31: Downlink Example: LoRaWAN Packet 2 - SCHC ACK		Figure 31: Downlink Example: LoRaWAN Packet 2 - SCHC ACK
	The second downlink is sent, two FOpts:		The second downlink is sent, two FOpts:
	| LoRaWAN Header | LoRaWAN payload (49 bytes) |		| LoRaWAN Header | LoRaWAN payload (49 bytes) |
	+ --------------------------- + ------------------------------------- +		+ --------------------------- + ------------------------------------- +
	| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |		| | FOpts | RuleID=21 | W = 1 | FCN = 0 | 1 tile |
	+ ---- + ------- + ---------- + ----- + ------- + ------------------- +		+ ---- + ------- + ---------- + ----- + ------- + ------------------- +
	| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |		| XXXX | 2 bytes | 1 byte | 1 bit | 1 bit | 48 bytes and 6 bits |
	Figure 32: Downlink Example: LoRaWAN Packet 3 - SCHC Fragment 2		Figure 32: Downlink Example: LoRaWAN Packet 3 - SCHC Fragment 2
	The receiver answers with an SCHC ACK:		The receiver answers with a SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 33: Downlink Example: LoRaWAN Packet 4 - SCHC ACK		Figure 33: Downlink Example: LoRaWAN Packet 4 - SCHC ACK
	The last downlink is sent, no FOpts:		The last downlink is sent, no FOpts:
	| LoRaWAN Header | LoRaWAN payload (37 bytes) |		| LoRaWAN Header | LoRaWAN payload (37 bytes) |
	+ ---- + ------- + -------------------------------------------------- +		+ ---- + ------- + -------------------------------------------------- +
	| | RuleID | W | FCN | RCS | 1 tile | Padding |		| | RuleID | W | FCN | RCS | 1 tile | Padding |
	| | 21 | 0 | 1 | | | b'00000 |		| | 21 | 0 | 1 | | | b'00000 |
	+ ---- + ------- + ----- + ----- + ------- + -------------- + ------- +		+ ---- + ------- + ----- + ----- + ------- + -------------- + ------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bit | 5 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 4 bytes | 31 bytes+1 bit | 5 bits |
	Figure 34: Downlink Example: LoRaWAN Packet 5 - All-1 SCHC Message		Figure 34: Downlink Example: LoRaWAN Packet 5 - All-1 SCHC Message
	The receiver answers to the sender with an SCHC ACK:		The receiver answers to the sender with a SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 35: Downlink Example: LoRaWAN Packet 6 - SCHC ACK		Figure 35: Downlink Example: LoRaWAN Packet 6 - SCHC ACK
	Acknowledgements		Acknowledgements
	skipping to change at line 1311 ¶		skipping to change at line 1316 ¶
	Semtech		Semtech
	14 Chemin des Clos		14 Chemin des Clos
	Meylan		Meylan
	France		France
	Email: ogimenez@semtech.com		Email: ogimenez@semtech.com
	Ivaylo Petrov (editor)		Ivaylo Petrov (editor)
	Acklio		Acklio
	1137A Avenue des Champs Blancs		1137A Avenue des Champs Blancs
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sévigné Cedex
	France		France
	Email: ivaylo@ackl.io		Email: ivaylo@ackl.io
End of changes. 28 change blocks.
	35 lines changed or deleted		40 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/