< draft-ietf-lpwan-schc-over-lorawan-05.txt		draft-ietf-lpwan-schc-over-lorawan-06.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: June 22, 2020 Acklio		Expires: October 2, 2020 Acklio
	December 20, 2019		March 31, 2020
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-05		draft-ietf-lpwan-schc-over-lorawan-06
	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 LPWAN
	(Low Power Wide Area Networks) technologies. SCHC is a generic		(Low Power Wide Area Networks) technologies. SCHC is a generic
	mechanism designed for great flexibility so that it can be adapted		mechanism designed for great flexibility so that it can be adapted
	for any of the LPWAN technologies.		for any of 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
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 22, 2020.		This Internet-Draft will expire on October 2, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8		4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8
	4.5. Unicast and multicast technology . . . . . . . . . . . . 8		4.5. Unicast and multicast technology . . . . . . . . . . . . 8
	5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8		5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8		5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9		5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9
	5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10		5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11		5.5. Decompression . . . . . . . . . . . . . . . . . . . . . . 11
	5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11		5.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 11
	5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11		5.6.1. DTag . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.6.2. Uplink fragmentation: From device to SCHC gateway . . 11		5.6.2. Uplink fragmentation: From device to SCHC gateway . . 12
	5.6.3. Downlink fragmentation: From SCHC gateway to a device 14		5.6.3. Downlink fragmentation: From SCHC gateway to a device 15
	6. Security considerations . . . . . . . . . . . . . . . . . . . 17		6. Security considerations . . . . . . . . . . . . . . . . . . . 18
	Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
	Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 18		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Uplink - Compression example - No fragmentation . . . . . 20		A.1. Uplink - Compression example - No fragmentation . . . . . 21
	A.2. Uplink - Compression and fragmentation example . . . . . 21		A.2. Uplink - Compression and fragmentation example . . . . . 22
	A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 22		A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) specification		The Static Context Header Compression (SCHC) specification
	[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header		[I-D.ietf-lpwan-ipv6-static-context-hc] describes generic header
	compression and fragmentation techniques that can be used on all		compression and fragmentation techniques that can be used on all
	LPWAN (Low Power Wide Area Networks) technologies defined in		LPWAN (Low Power Wide Area Networks) technologies defined in
	[RFC8376]. Even though those technologies share a great number of		[RFC8376]. Even though those technologies share a great number of
	common features like star-oriented topologies, network architecture,		common features like star-oriented topologies, network architecture,
	devices with mostly quite predictable communications, etc; they do		devices with mostly quite predictable communications, etc; they do
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	+--------+-------+ +----+ +----+ +----+		+--------+-------+ +----+ +----+ +----+
	| +---+ +----+ +----+ +----+ . . .		| +---+ +----+ +----+ +----+ . . .
	+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....		+~ |RGW| === |NGW | == |SCHC| == |SCHC|...... Internet ....
	+---+ +----+ |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 flow		applications flows using IPv6 or IPv6/UDP protocols. These flows
	might be compressed by an Static Context Header Compression		might be compressed by an 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 (SCHC F/R). The resulting information is sent on a layer
	two (L2) frame to an LPWAN Radio Gateway (RGW) which forwards the		two (L2) frame to an LPWAN Radio Gateway (RGW) that forwards the
	frame to a Network Gateway (NGW). The NGW sends the data to a SCHC		frame to a Network Gateway (NGW). The NGW sends the data to a SCHC
	F/R for defragmentation, if required, then C/D for decompression		F/R for defragmentation, if required, then C/D for decompression
	which shares the same rules with the device. The SCHC F/R and C/D		which shares the same rules with the device. The SCHC F/R and C/D
	can be located on the Network Gateway (NGW) or in another place as		can be located on the Network Gateway (NGW) or in another place as
	long as a tunnel is established between the NGW and the SCHC F/R,		long as a tunnel is established between the NGW and the SCHC F/R,
	then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share		then SCHC F/R and SCHC C/D. The SCHC C/D in both sides MUST share
	the same set of rules. After decompression, the packet can be sent		the same set of rules. After decompression, the packet can be sent
	on the Internet to one or several LPWAN Application Servers (App).		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 F/R and SCHC C/D process is bidirectional, so the same
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	As SCHC defines its own acknowledgment mechanisms, SCHC does not		As SCHC defines its own acknowledgment mechanisms, SCHC does not
	require to use confirmed messages.		require to use confirmed messages.
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	o JoinRequest: This message is used by an end-device to join a		o JoinRequest: This message is used by an end-device to join a
	network. It contains the end-device's unique identifier devEUI		network. It contains the end-device's unique identifier devEUI
	and a random nonce that will be used for session key derivation.		and a random nonce that will be used for session key derivation.
	o JoinAccept: To on-board an end-device, the Network Server responds		o JoinAccept: To on-board an end-device, the Network Server responds
	to the JoinRequest end-device's message with a JoinAccept message.		to the JoinRequest issued by end-device's message with a
	That message is encrypted with the end-device's AppKey and		JoinAccept message. That message is encrypted with the end-
	contains (amongst other fields) the major network's settings and a		device's AppKey and contains (amongst other fields) the major
	network random nonce used to derive the session keys.		network's settings and a network random 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. Unicast and multicast technology		4.5. 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 end-devices with same content,		devices. It is useful to address many end-devices with same content,
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	LoRaWAN specification and MUST be shared by the end-device and SCHC		LoRaWAN specification and MUST be shared by the end-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 differents 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
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	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 procotol.		as it is already used by devices for LoRaWAN procotol.
	As AppSKey is renewed each time a device joins or rejoins a network,		As AppSKey is renewed each time a device joins or rejoins a network,
	the IID will change over time; this mitigates privacy, location		the IID will change over time; this mitigates privacy, location
	tracking and correlation over time risks. Rejoin periodicity is		tracking and correlation over time risks. Join periodicity is
	defined at the application level.		defined at the application level.
	Address scan risk is mitigated thanks to AES-128, which provides		Address scan risk is mitigated thanks to AES-128, which provides
	enough entropy bits of the IID.		enough entropy bits of the IID.
	Using this algorithm will also ensure that there is not correlation		Using this algorithm will also ensure that there is no correlation
	between the hardware identifier (IEEE-64 devEUI) and the IID, so an		between the hardware identifier (IEEE-64 devEUI) and the IID, so an
	attacker can not use manufacturer OUI to target devices.		attacker cannot use manufacturer OUI to target devices.
	Exemple with:		Example with:
	o devEui: 0x1122334455667788		o devEui: 0x1122334455667788
	o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB		o appSKey: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
	1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB		1. key: 0x00AABBCCDDEEFF00AABBCCDDEEFFAABB
	2. cmac: 0x4E822D9775B2649928F82066AF804FEC		2. cmac: 0x4E822D9775B2649928F82066AF804FEC
	3. IID: 0x28F82066AF804FEC		3. IID: 0x28F82066AF804FEC
			Figure 6: Example of IID computation.
			There is a small probability of IID collision in a network, if such
			event occurs the IID can be changed by rekeying the device on L2
			level (ie: trigger a LoRaWAN join). The way the device is rekeyed is
			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
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 46 ¶
	must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own		must transmit MAX_ACK_REQUESTS time the SCHC ACK REQ at it own
	timing; ie the periodicity between retransmission of SCHC ACK REQs		timing; ie the periodicity between retransmission of SCHC ACK REQs
	is device specific and can vary depending on other application		is device specific and can vary depending on other application
	uplinks and regulations.		uplinks and regulations.
	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 Last tile: The last tile MUST NOT be carried in the All-1
	fragment.
	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
			an All-1 SCHC Fragment or with any of these two methods:
			implementation must ensure that:
			* The sender MUST ascertain that the receiver will not receive
			the last tile through both a Regular SCHC Fragment and an All-1
			SCHC Fragment.
			* If last tile is in All-1 message: current L2 MTU MUST be big
			enough to fit the All-1 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_
	_Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an		_Note_: As LoRaWAN is a radio communication, it is RECOMMENDED for an
	implementation to use ACK mechanism at the end of each window:		implementation to use ACK mechanism at the end of each window:
	o SCHC receiver sends an SCHC ACK after every window even if there		o SCHC receiver sends an SCHC ACK after every window even if there
	is no missing tiles.		is no missing tiles.
	o SCHC sender waits for the SCHC ACK from the SCHC receiver before		o SCHC sender waits for the SCHC ACK from the SCHC receiver before
	sending tiles from next window. If the SCHC ACK is not received		sending tiles from next window. If the SCHC ACK is not received,
	it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as		it should send an SCHC ACK REQ up to MAX_ACK_REQUESTS time as
	described previously.		described previously.
	This OPTIONAL feature will prevent a device to transmit full payload		This OPTIONAL feature allows the implementation to select between: *
	if the network can not be reach, thus save battery life.		SCHC ACK after every window: Save battery life by preventing a device
			to transmit full payload if the network cannot be reached *
			Otherwise: Reduce downlink load on the network by reducing the number
			of downlinks
	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 6: All fragments except the last one. SCHC header size is 16		Figure 7: All fragments except the last one. SCHC header size is 16
	bits, including LoRaWAN FPort.		bits, including LoRaWAN FPort.
	5.6.2.2. Last fragment (All-1)		5.6.2.2. Last fragment (All-1)
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------- +		+ ------ + ---------------------------- +
	| RuleID | W | FCN=All-1 | RCS |		| RuleID | W | FCN=All-1 | RCS |
	+ ------ + ------ + --------- + ------- +		+ ------ + ------ + --------- + ------- +
	| 8 bits | 2 bits | 6 bits | 32 bits |		| 8 bits | 2 bits | 6 bits | 32 bits |
	Figure 7: All-1 fragment detailed format for the last fragment.		Figure 8: All-1 fragment detailed format for the last fragment.
	5.6.2.3. SCHC ACK		5.6.2.3. SCHC ACK
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ----------------------------------------- +		+ ------ + ----------------------------------------- +
	| RuleID | W | C | Encoded bitmap (if C = 0) |		| RuleID | W | C | Encoded bitmap (if C = 0) |
	+ ------ + ----- + ----- + ------------------------- +		+ ------ + ----- + ----- + ------------------------- +
	| 8 bits | 2 bit | 1 bit | 0 to 63 bits |		| 8 bits | 2 bit | 1 bit | 0 to 63 bits |
	Figure 8: SCHC ACK format, failed RCS check.		Figure 9: SCHC ACK format, failed RCS check.
	5.6.2.4. Receiver-Abort		5.6.2.4. Receiver-Abort
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + -------------------------------------------- +		+ ------ + -------------------------------------------- +
	| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |		| RuleID | W = b'11 | C = 1 | b'11111 | 0xFF (all 1's) |
	+ ------ + -------- + ------+-------- + ----------------+		+ ------ + -------- + ------+-------- + ----------------+
	| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |		| 8 bits | 2 bits | 1 bit | 5 bits | 8 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 9: Receiver-Abort format.		Figure 10: Receiver-Abort format.
	5.6.2.5. SCHC acknowledge request		5.6.2.5. SCHC acknowledge request
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+------- +------------------------- +		+------- +------------------------- +
	| RuleID | W | FCN = b'000000 |		| RuleID | W | FCN = b'000000 |
	+ ------ + ------ + --------------- +		+ ------ + ------ + --------------- +
	| 8 bits | 2 bits | 6 bits |		| 8 bits | 2 bits | 6 bits |
	Figure 10: SCHC ACK REQ format.		Figure 11: SCHC ACK REQ format.
	5.6.3. Downlink fragmentation: From SCHC gateway to a device		5.6.3. Downlink fragmentation: From SCHC gateway to a device
	In that case the device is the fragmentation receiver, and the SCHC		In that case the device is the fragmentation receiver, and the SCHC
	gateway the fragmentation transmitter. The following fields are		gateway the fragmentation transmitter. The following fields are
	common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN		common to all devices. SCHC F/R MUST concatenate FPort and LoRaWAN
	payload to retrieve the SCHC Packet as described in Section 5.1.		payload to retrieve the SCHC Packet as described in Section 5.1.
	o SCHC fragmentation reliability mode:		o SCHC fragmentation reliability mode:
	skipping to change at page 15, line 13 ¶		skipping to change at page 15, line 50 ¶
	Server for other purposes but not SCHC needs.		Server 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 11: All fragments but the last one. Header size 10 bits,		Figure 12: 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 |		| RuleID | W | FCN = b'1 | RCS |
	+ ------ + ----- + --------- + ------- +		+ ------ + ----- + --------- + ------- +
	| 8 bits | 1 bit | 1 bit | 32 bits |		| 8 bits | 1 bit | 1 bit | 32 bits |
	Figure 12: All-1 SCHC Message: the last fragment.		Figure 13: All-1 SCHC Message: the last fragment.
	5.6.3.3. SCHC acknowledge		5.6.3.3. SCHC acknowledge
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------------- +		+ ------ + ---------------------------------- +
	| RuleID | W | C = b'1 | Padding b'000000 |		| RuleID | W | C = b'1 | Padding b'000000 |
	+ ------ + ----- + ------- + ---------------- +		+ ------ + ----- + ------- + ---------------- +
	| 8 bits | 1 bit | 1 bit | 6 bits |		| 8 bits | 1 bit | 1 bit | 6 bits |
	Figure 13: SCHC ACK format, RCS is correct.		Figure 14: SCHC ACK format, RCS is correct.
	5.6.3.4. Receiver-Abort		5.6.3.4. Receiver-Abort
	| FPort | LoRaWAN payload |		| FPort | LoRaWAN payload |
	+ ------ + ---------------------------------------------- +		+ ------ + ---------------------------------------------- +
	| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |		| RuleID | W = b'1 | C = b'1 | b'111111 | 0xFF (all 1's) |
	+ ------ + ------- + ------- + -------- + --------------- +		+ ------ + ------- + ------- + -------- + --------------- +
	| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |		| 8 bits | 1 bit | 1 bits | 6 bits | 8 bits |
	next L2 Word boundary ->| <-- L2 Word --> |		next L2 Word boundary ->| <-- L2 Word --> |
	Figure 14: Receiver-Abort packet (following an All-1 SCHC Fragment		Figure 15: Receiver-Abort packet (following an All-1 SCHC Fragment
	with incorrect RCS).		with incorrect RCS).
	Class A and Class B or Class C end-devices do not manage		Class A and Class B or Class C end-devices do not manage
	retransmissions and timers in the same way.		retransmissions and timers in the same way.
	5.6.3.5. Class A end-devices		5.6.3.5. Class A end-devices
	Class A end-devices can only receive in an RX slot following the		Class A end-devices can only receive in an RX slot following the
	transmission of an uplink. Therefore there cannot be a concept of		transmission of an uplink. Therefore there cannot be a concept of
	"retransmission timer" for an SCHC gateway. The SCHC gateway cannot		"retransmission timer" for an SCHC gateway. The SCHC gateway cannot
	skipping to change at page 17, line 44 ¶		skipping to change at page 18, line 33 ¶
	reception of each fragment. The inactivity timer is implemented by		reception of each fragment. The inactivity timer is implemented by
	the end-device to flush the context in case it receives nothing from		the end-device to flush the context in case it receives nothing from
	the SCHC gateway over an extended period of time. The RECOMMENDED		the SCHC gateway over an extended period of time. The RECOMMENDED
	value is 12 hours for both Class B and Class C end-devices.		value is 12 hours for both Class B and Class C end-devices.
	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
	better suited for LoRaWAN networks for		better suited for LoRaWAN networks for
	[I-D.ietf-lpwan-ipv6-static-context-hc]. IID security is discussed		[I-D.ietf-lpwan-ipv6-static-context-hc]. IID security is discussed
	in Section 5.3.As such, this document does not contribute to any new		in Section 5.3. As such, this document does not contribute to any
	security issues in addition to those identified in		new security issues in addition to those identified in
	[I-D.ietf-lpwan-ipv6-static-context-hc].		[I-D.ietf-lpwan-ipv6-static-context-hc]. Moreover SCHC data (LoRaWAN
			payload) are protected on LoRaWAN level by an AES-128 encryption with
			key shared by device and SCHC gateway. Those keys are renew each
			LoRaWAN session (ie: each join or rejoin to the network)
	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 20, line 37 ¶		skipping to change at page 21, line 33 ¶
	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 C/D layer, allowing to compress it to 40
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 37 bytes payload.		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 15: Uplink example: SCHC Message		Figure 16: Uplink example: SCHC Message
	The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used		The current LoRaWAN MTU is 51 bytes, although 2 bytes FOpts are used
	by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need		by LoRaWAN protocol: 49 bytes are available for SCHC payload; no need
	for fragmentation. The payload will be transmitted through FPort =		for fragmentation. The payload will be transmitted through FPort =
	1.		1.
	| LoRaWAN Header | LoRaWAN payload (40 bytes) |		| LoRaWAN Header | LoRaWAN payload (40 bytes) |
	+ ------------------------- + --------------------------------------- +		+ ------------------------- + --------------------------------------- +
	| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |		| | FOpts | RuleID=1 | Compression | Payload | Padding=b'000 |
	| | | | residue | | |		| | | | residue | | |
	+ ---- + ------- + -------- + ----------- + --------- + ------------- +		+ ---- + ------- + -------- + ----------- + --------- + ------------- +
	| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |		| XXXX | 2 bytes | 1 byte | 21 bits | 37 bytes | 3 bits |
	Figure 16: Uplink example: LoRaWAN packet		Figure 17: 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 C/D layer, allowing to compress it to 282
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 279 bytes payload.		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 17: Uplink example: SCHC Message		Figure 18: Uplink example: SCHC Message
	The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by		The current LoRaWAN MTU is 11 bytes, 0 bytes FOpts are used by
	LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte		LoRaWAN protocol: 11 bytes are available for SCHC payload + 1 byte
	FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is		FPort field. SCHC header is 2 bytes (including FPort) so 1 tile is
	sent in first fragment.		sent in first fragment.
	| LoRaWAN Header | LoRaWAN payload (11 bytes) |		| LoRaWAN Header | LoRaWAN payload (11 bytes) |
	+ -------------------------- + -------------------------- +		+ -------------------------- + -------------------------- +
	| | RuleID=20 | W | FCN | 1 tile |		| | RuleID=20 | W | FCN | 1 tile |
	+ -------------- + --------- + ----- + ------ + --------- +		+ -------------- + --------- + ----- + ------ + --------- +
	| XXXX | 1 byte | 0 0 | 62 | 10 bytes |		| XXXX | 1 byte | 0 0 | 62 | 10 bytes |
	Figure 18: Uplink example: LoRaWAN packet 1		Figure 19: 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 byte + 3 bits |
	Figure 19: Uplink example: LoRaWAN packet 1 - Tile content		Figure 20: Uplink example: LoRaWAN packet 1 - Tile content
	Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by		Next transmission MTU is 11 bytes, although 2 bytes FOpts are used by
	LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte		LoRaWAN protocol: 9 bytes are available for SCHC payload + 1 byte
	FPort field, a tile does not fit inside so LoRaWAN stack will send		FPort field, a tile does not fit inside so LoRaWAN stack will send
	only FOpts.		only FOpts.
	Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are		Next transmission MTU is 242 bytes, 4 bytes FOpts. 23 tiles are
	transmitted:		transmitted:
	| LoRaWAN Header | LoRaWAN payload (231 bytes) |		| LoRaWAN Header | LoRaWAN payload (231 bytes) |
	+ --------------------------------------+ --------------------------- +		+ --------------------------------------+ --------------------------- +
	| | FOpts | RuleID=20 | W | FCN | 23 tiles |		| | FOpts | RuleID=20 | W | FCN | 23 tiles |
	+ -------------- + ------- + ---------- + ----- + ----- + ----------- +		+ -------------- + ------- + ---------- + ----- + ----- + ----------- +
	| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |		| XXXX | 4 bytes | 1 byte | 0 0 | 61 | 230 bytes |
	Figure 20: Uplink example: LoRaWAN packet 2		Figure 21: 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 21: Uplink example: LoRaWAN packet 3		Figure 22: 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 22: Uplink example: LoRaWAN packet 4 - All-1 message		Figure 23: Uplink example: LoRaWAN packet 4 - All-1 message
	All packets have been received by the SCHC gateway, computed RCS is		All packets have been received by the SCHC gateway, computed RCS is
	correct so the following ACK is sent to the device by the SCHC		correct so the following ACK is sent to the device by the SCHC
	receiver:		receiver:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ -------------- + --------- + ------------------- +		+ -------------- + --------- + ------------------- +
	| | RuleID=20 | W | C | Padding |		| | RuleID=20 | W | C | Padding |
	+ -------------- + --------- + ----- + - + ------- +		+ -------------- + --------- + ----- + - + ------- +
	| XXXX | 1 byte | 0 0 | 1 | 5 bits |		| XXXX | 1 byte | 0 0 | 1 | 5 bits |
	Figure 23: Uplink example: LoRaWAN packet 5 - SCHC ACK		Figure 24: 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 C/D layer, allowing to compress it to 130
	bytes and 5 bits: 1 byte RuleID, 21 bits residue + 127 bytes payload.		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 24: Downlink example: SCHC Message		Figure 25: Downlink example: SCHC Message
	The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN		The current LoRaWAN MTU is 51 bytes, no FOpts are used by LoRaWAN
	protocol: 51 bytes are available for SCHC payload + FPort field => it		protocol: 51 bytes are available for SCHC payload + FPort field => it
	has to be fragmented.		has to be fragmented.
	| LoRaWAN Header | LoRaWAN payload (51 bytes) |		| LoRaWAN Header | LoRaWAN payload (51 bytes) |
	+ ---- + ---------- + -------------------------------------- +		+ ---- + ---------- + -------------------------------------- +
	| | RuleID=21 | W = 0 | FCN = 0 | 1 tile |		| | RuleID=21 | W = 0 | FCN = 0 | 1 tile |
	+ ---- + ---------- + ------ + ------- + ------------------- +		+ ---- + ---------- + ------ + ------- + ------------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 50 bytes and 6 bits |
	Figure 25: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1		Figure 26: Downlink example: LoRaWAN packet 1 - SCHC Fragment 1
	Content of the tile is:		Content of the tile is:
	| RuleID | Compression residue | Payload |		| RuleID | Compression residue | Payload |
	+ ------ + ------------------- + ------------------ +		+ ------ + ------------------- + ------------------ +
	| 1 | 21 bits | 48 bytes and 1 bit |		| 1 | 21 bits | 48 bytes and 1 bit |
	Figure 26: Downlink example: LoRaWAN packet 1: Tile content		Figure 27: Downlink example: LoRaWAN packet 1: Tile content
	The receiver answers with a SCHC ACK:		The receiver answers with a SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 0 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 27: Downlink example: LoRaWAN packet 2 - SCHC ACK		Figure 28: 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 28: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2		Figure 29: Downlink example: LoRaWAN packet 3 - SCHC Fragment 2
	The receiver answers with an SCHC ACK:		The receiver answers with an SCHC ACK:
	| LoRaWAN Header | LoRaWAN payload |		| LoRaWAN Header | LoRaWAN payload |
	+ ---- + --------- + -------------------------------- +		+ ---- + --------- + -------------------------------- +
	| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |		| | RuleID=21 | W = 1 | C = 1 | Padding=b'000000 |
	+ ---- + --------- + ----- + ----- + ---------------- +		+ ---- + --------- + ----- + ----- + ---------------- +
	| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |		| XXXX | 1 byte | 1 bit | 1 bit | 6 bits |
	Figure 29: Downlink example: LoRaWAN packet 4 - SCHC ACK		Figure 30: 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=21 | W = 0 | FCN = 1 | RCS | 1 tile | Padding=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 30: Uplink example: LoRaWAN packet 5 - All-1 message		Figure 31: Uplink example: LoRaWAN packet 5 - All-1 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 31: Uplink example: LoRaWAN packet 6 - SCHC ACK		Figure 32: Uplink example: LoRaWAN packet 6 - SCHC ACK
	Authors' Addresses		Authors' Addresses
	Olivier Gimenez (editor)		Olivier Gimenez (editor)
	Semtech		Semtech
	14 Chemin des Clos		14 Chemin des Clos
	Meylan		Meylan
	France		France
	Email: ogimenez@semtech.com		Email: ogimenez@semtech.com
End of changes. 48 change blocks.
	65 lines changed or deleted		85 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/