< draft-ietf-lpwan-schc-over-lorawan-00.txt		draft-ietf-lpwan-schc-over-lorawan-01.txt >
	lpwan Working Group N. Sornin, Ed.		lpwan Working Group O. Gimenez, Ed.
	Internet-Draft M. Coracin		Internet-Draft Semtech
	Intended status: Informational Semtech		Intended status: Informational I. Petrov, Ed.
	Expires: October 21, 2019 I. Petrov		Expires: December 28, 2019 Acklio
	Acklio		June 26, 2019
	A. Yegin
	Actility
	J. Catalano
	Kerlink
	V. Audebert
	EDF R&D
	April 19, 2019
	Static Context Header Compression (SCHC) over LoRaWAN		Static Context Header Compression (SCHC) over LoRaWAN
	draft-ietf-lpwan-schc-over-lorawan-00		draft-ietf-lpwan-schc-over-lorawan-01
	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
	networks, and provides elements such as efficient parameterization		networks, and provides elements such as efficient parameterization
	and modes of operation.		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 October 21, 2019.		This Internet-Draft will expire on December 28, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 25 ¶		skipping to change at page 2, line 15 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Static Context Header Compression Overview . . . . . . . . . 3		3. Static Context Header Compression Overview . . . . . . . . . 3
	4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 4		4. LoRaWAN Architecture . . . . . . . . . . . . . . . . . . . . 5
	4.1. Device classes (A, B, C) and interactions . . . . . . . . 5		4.1. End-Device classes (A, B, C) and interactions . . . . . . 6
	4.2. Device addressing . . . . . . . . . . . . . . . . . . . . 6		4.2. End-Device addressing . . . . . . . . . . . . . . . . . . 7
	4.3. General Message Types . . . . . . . . . . . . . . . . . . 7		4.3. General Message Types . . . . . . . . . . . . . . . . . . 7
	4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 7		4.4. LoRaWAN MAC Frames . . . . . . . . . . . . . . . . . . . 8
	5. SCHC over LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 7		5. SCHC-over-LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Rule ID management . . . . . . . . . . . . . . . . . . . 7		5.1. LoRaWAN FPort . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. IID computation . . . . . . . . . . . . . . . . . . . . . 8		5.2. Rule ID management . . . . . . . . . . . . . . . . . . . 9
	5.3. No compression packets are sent using Rule ID 7. . . . . 8		5.3. IID computation . . . . . . . . . . . . . . . . . . . . . 9
	5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8		5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9
	5.4.1. Uplink fragmentation: From device to gateway . . . . 8		5.5. DTag . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.4.2. Downlinks: From gateway to device . . . . . . . . . . 9		5.5.1. Uplink fragmentation: From device to SCHC gateway . . 10
	6. Security considerations . . . . . . . . . . . . . . . . . . . 13		5.5.2. Downlink fragmentation: From SCHC gateway to device . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		6. Security considerations . . . . . . . . . . . . . . . . . . . 16
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
			A.1. Uplink - Compression example - No fragmentation . . . . . 18
			A.2. Uplink - Compression and fragmentation example . . . . . 19
			A.3. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 20
			Appendix B. Note . . . . . . . . . . . . . . . . . . . . . . . . 20
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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
	[I-D.ietf-lpwan-overview]. Even though those technologies share a		[RFC8376]. Even though those technologies share a great number of
	great number of common features like start-oriented topologies,		common features like star-oriented topologies, network architecture,
	network architecture, devices with mostly quite predictable		devices with mostly quite predictable communications, etc; they do
	communications, etc; they do have some slight differences in respect		have some slight differences in respect of payload sizes,
	of payload sizes, reactiveness, etc.		reactiveness, etc.
	SCHC gives a generic framework that enables those devices to		SCHC gives 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
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	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 [I-D.ietf-lpwan-ipv6-static-context-hc].		specification [I-D.ietf-lpwan-ipv6-static-context-hc].
	o DevEUI: an IEEE EUI-64 identifier used to identify the device		o DevEUI: an IEEE EUI-64 identifier used to identify the end-device
	during the procedure while joining the network (Join Procedure)		during the procedure while joining the network (Join Procedure)
	o DevAddr: a 32-bit non-unique identifier assigned to a device		o DevAddr: a 32-bit non-unique identifier assigned to a end-device
	statically or dynamically after a Join Procedure (depending on the		statically or dynamically after a Join Procedure (depending on the
	activation mode)		activation mode)
	o TBD: all significant LoRaWAN-related terms.		o TBD: all significant LoRaWAN-related terms.
	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 Static Context Header
	Compression (SCHC). For a detailed description, refer to the full		Compression (SCHC). For a detailed description, refer to the full
	specification [I-D.ietf-lpwan-ipv6-static-context-hc].		specification [I-D.ietf-lpwan-ipv6-static-context-hc].
	Static Context Header Compression (SCHC) avoids context		Static Context Header Compression (SCHC) avoids context
	synchronization, which is the most bandwidth-consuming operation in		synchronization, based on the fact that the nature of data flows is
	other header compression mechanisms such as RoHC [RFC5795]. Based on		highly predictable in LPWAN networks, some static contexts may be
	the fact that the nature of data flows is highly predictable in LPWAN		stored on the Device (Dev). The contexts must be stored in both
	networks, some static contexts may be stored on the Device (Dev).		ends, and it can either be learned by a provisioning protocol or by
	The contexts must be stored in both ends, and it can either be		out-of-band means or it can be pre-provisioned, etc. The way the
	learned by a provisioning protocol or by out of band means or it can		context is learned on both sides is out of the scope of this
	be pre-provisioned, etc. The way the context is learned on both		document.
	sides is out of the scope of this document.
	Dev App		Dev App
	+--------------+ +--------------+		+----------------+ +----+ +----+ +----+
	|APP1 APP2 APP3| |APP1 APP2 APP3|		| App1 App2 App3 | |App1| |App2| |App3|
	| | | |		| | | | | | | |
	| UDP | | UDP |		| UDP | |UDP | |UDP | |UDP |
	| IPv6 | | IPv6 |		| IPv6 | |IPv6| |IPv6| |IPv6|
	| | | |		| | | | | | | |
	| SCHC C/D | | |		|SCHC C/D and F/R| | | | | | |
	| (context) | | |		+--------+-------+ +----+ +----+ +----+
	+-------+------+ +-------+------+		| +--+ +----+ +----+ +----+ . . .
	| +--+ +----+ +---------+ .		+~ |RG| === |NGW | == |SCHC| == |SCHC|...... Internet ....
	+~~ |RG| === |NGW | === |SCHC C/D |... Internet ..		+--+ +----+ |F/R | |C/D |
	+--+ +----+ |(context)|		+----+ +----+
	+---------+
	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 [I-D.ietf-lpwan-overview] terminology. The Device is		it is based on [RFC8376] terminology. The Device is sending
	sending applications flows using IPv6 or IPv6/UDP protocols. These		applications flows using IPv6 or IPv6/UDP protocols. These flow
	flows are compressed by an Static Context Header Compression		might be fragemented (SCHC F/R), and compressed by an Static Context
	Compressor/Decompressor (SCHC C/D) to reduce headers size. Resulting		Header Compression Compressor/Decompressor (SCHC C/D) to reduce
	information is sent on a layer two (L2) frame to a LPWAN Radio		headers size. Resulting information is sent on a layer two (L2)
	Network (RG) which forwards the frame to a Network Gateway (NGW).		frame to a LPWAN Radio Network (RG) which forwards the frame to a
	The NGW sends the data to a SCHC C/D for decompression which shares		Network Gateway (NGW). The NGW sends the data to a SCHC F/R for
	the same rules with the Dev. The SCHC C/D can be located on the		defragmentation, if required, then C/D for decompression which shares
	Network Gateway (NGW) or in another place as long as a tunnel is		the same rules with the device. The SCHC F/R and C/D can be located
	established between the NGW and the SCHC C/D. The SCHC C/D in both		on the Network Gateway (NGW) or in another place as long as a tunnel
	sides must share the same set of Rules. After decompression, the		is established between the NGW and the SCHC F/R, then SCHC F/R and
	packet can be sent on the Internet to one or several LPWAN		SCHC C/D. The SCHC C/D in both sides must share the same set of
	Application Servers (App).		Rules. After decompression, the packet can be sent on the Internet
			to one or several LPWAN Application Servers (App).
	The SCHC C/D process is bidirectional, so the same principles can be		The SCHC F/R and SCHC C/D process is bidirectional, so the same
	applied in the other direction.		principles 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 can be embedded in different places, for		Server, and the SCHC C/D is an Application Server. It can be
	example in the Network Server and/or the Application Server.		provided by the Network Server or any third party software. Figure 1
			can be map in LoRaWAN terminology to:
	Next steps for this section: detailed overview of the LoRaWAN		Dev App
	architecture and its mapping to the SCHC architecture.		+----------------+ +----+ +----+ +----+
			| App1 App2 App3 | |App1| |App2| |App3|
			| | | | | | | |
			| UDP | |UDP | |UDP | |UDP |
			| IPv6 | |IPv6| |IPv6| |IPv6|
			| | | | | | | |
			|SCHC C/D and F/R| | | | | | |
			+--------+-------+ +----+ +----+ +----+
			| +-------+ +-------+ +----------------+ . . .
			+~ |Gateway| === |Network| == |Application |...... Internet ....
			+-------+ |server | |server F/R - C/D|
			+-------+ +----------------+
			Figure 2: Architecture
	4. LoRaWAN Architecture		4. LoRaWAN Architecture
	An overview of LoRaWAN [lora-alliance-spec] protocol and architecture		An overview of LoRaWAN [lora-alliance-spec] protocol and architecture
	is described in [I-D.ietf-lpwan-overview]. Mapping between the LPWAN		is described in [RFC8376]. Mapping between the LPWAN architecture
	architecture entities as described in		entities as described in [I-D.ietf-lpwan-ipv6-static-context-hc] and
			the ones in [lora-alliance-spec] is as follows:
	[I-D.ietf-lpwan-ipv6-static-context-hc] and the ones in
	[lora-alliance-spec] is as follows:
	o Devices (Dev) are the end-devices or hosts (e.g. sensors,		o Devices (Dev) are the end-devices or hosts (e.g. sensors,
	actuators, etc.). There can be a very high density of devices per		actuators, etc.). There can be a very high density of devices per
	radio gateway. This entity maps to the LoRaWAN End-device.		radio gateway (LoRaWAN gateway). This entity maps to the LoRaWAN
			End-Device.
	o The Radio Gateway (RGW), which is the end point of the constrained		o The Radio Gateway (RGW), which is the end point 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 LPWAN-AAA Server, which controls the user authentication and the		o LPWAN-AAA Server, which controls the user authentication and the
	applications. This entity maps to the LoRaWAN Join Server.		applications. This entity maps to the LoRaWAN Join Server.
	o Application Server (App). The same terminology is used in LoRaWAN.		o Application Server (App). The same terminology is used in LoRaWAN.
			In that case, the application server will be the SCHC gateway, doing
			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 2: LPWAN Architecture		Figure 3: LPWAN Architecture
	SCHC C/D (Compressor/Decompressor) and SCHC Fragmentation are		SCHC C/D (Compressor/Decompressor) and SCHC F/R (Fragmentation/
	performed on the LoRaWAN End-device and the Application Server.		Reassembly) are performed on the LoRaWAN End-Device and the
	While the point-to-point link between the End-device and the		Application Server (called SCHC gateway). While the point-to-point
	Application Server constitutes single IP hop, the ultimate end-point		link between the End-Device and the Application Server constitutes
	of the IP communication may be an Internet node beyond the		single IP hop, the ultimate end-point of the IP communication may be
	Application Server. In other words, the LoRaWAN Application Server		an Internet node beyond the Application Server. In other words, the
	acts as the first hop IP router for the End-device. Note that the		LoRaWAN Application Server (SCHC gateway) acts as the first hop IP
	Application Server and Network Server may be co-located, which		router for the End-Device. The Application Server and Network Server
	effectively turns the Network/Application Server into the first hop		may be co-located, which effectively turns the Network/Application
	IP router.		Server into the first hop IP router.
	4.1. Device classes (A, B, C) and interactions		4.1. End-Device classes (A, B, C) and interactions
	The LoRaWAN MAC layer supports 3 classes of devices named A,B and C.		The LoRaWAN MAC layer supports 3 classes of end-devices named A, B
	All devices implement the classA, some devices implement classA+B or		and C. All end-devices implement the classA, some end-devices
	class A+C. ClassB and classC are mutually exclusive.		implement classA+B or class A+C. ClassB and classC are mutually
			exclusive.
	o *ClassA*: The classA is the simplest class of devices. The device		o *ClassA*: The classA is the simplest class of end-devices. The
	is allowed to transmit at any time, randomly selecting a		end-device is allowed to transmit at any time, randomly selecting
	communication channel. The network may reply with a downlink in		a communication channel. The network may reply with a downlink in
	one of the 2 receive windows immediately following the uplinks.		one of the 2 receive windows immediately following the uplinks.
	Therefore, the network cannot initiate a downlink, it has to wait		Therefore, the network cannot initiate a downlink, it has to wait
	for the next uplink from the device to get a downlink opportunity.		for the next uplink from the end-device to get a downlink
	The classA is the lowest power device class.		opportunity. The classA is the lowest power end-device class.
	o *ClassB*: classB devices implement all the functionalities of		o *ClassB*: classB end-devices implement all the functionalities of
	classA devices, but also schedule periodic listen windows.		classA end-devices, but also schedule periodic listen windows.
	Therefore, as opposed the classA devices, classB devices can		Therefore, as opposed the classA end-devices, classB end-devices
	receive downlink that are initiated by the network and not		can receive downlink that are initiated by the network and not
	following an uplink. There is a trade-off between the periodicity		following an uplink. There is a trade-off between the periodicity
	of those scheduled classB listen windows and the power consumption		of those scheduled classB listen windows and the power consumption
	of the device. The lower the downlink latency, the higher the		of the end-device. The lower the downlink latency, the higher the
	power consumption.		power consumption.
	o *ClassC*: classC devices implement all the functionalities of		o *ClassC*: classC end-devices implement all the functionalities of
	classA devices, but keep their receiver open whenever they are not		classA end-devices, but keep their receiver open whenever they are
	transmitting. ClassC devices can receive downlinks at any time at		not transmitting. ClassC end-devices can receive downlinks at any
	the expense of a higher power consumption. Battery powered		time at the expense of a higher power consumption. Battery
	devices can only operate in classC for a limited amount of time		powered end-devices can only operate in classC for a limited
	(for example for a firmware upgrade over the air). Most of the		amount of time (for example for a firmware upgrade over-the-air).
	classC devices are main powered (for example Smart Plugs).		Most of the classC end-devices are main powered (for example Smart
			Plugs).
	4.2. Device addressing		4.2. End-Device addressing
	LoRaWAN devices use a 32bits network address (devAddr) to communicate		LoRaWAN end-devices use a 32 bits network address (devAddr) to
	with the network over the air. However that address might be reused		communicate with the network over-the-air. However, that address
	several time on the same network at the same time for different		might be reused several time on the same network at the same time for
	devices. Devices using the same devAddr are distinguish by the		different end-devices. End-devices using the same devAddr are
	network server based on the cryptographic signature appended to every		distinguish by the Network Server based on the cryptographic
	single LoRaWAN MAC frame, as all devices use different security keys.		signature appended to every single LoRaWAN MAC frame, as all end-
	To communicate with the SCHC gateway the network server MUST identify		devices use different security keys. To communicate with the SCHC
	the devices by a unique 64bits device ID called the devEUI. Unlike		gateway the Network Server MUST identify the end-devices by a unique
	devAddr, devEUI is guaranteed to be unique for every single device		64bits device ID called the devEUI. Unlike devAddr, devEUI is
	across all networks. The devEUI is assigned to the device during the		guaranteed to be unique for every single end-device across all
	manufacturing process by the device's manufacturer. The devEUI is		networks. The devEUI is assigned to the end-device during the
	built like an Ethernet MAC address by concatenating the		manufacturing process by the end-device's manufacturer. It is built
	manufacturer's IEEE 24bits OUI field with a 40bits serial number.		like an Ethernet MAC address by concatenating the manufacturer's IEEE
	The network server translates the devAddr into a devEUI in the uplink		OUI field with a vendor unique number. ex: 24bits OUI is
	direction and reciprocally on the downlink direction.		concatenated with a 40 bits serial number. The Network Server
			translates the devAddr into a devEUI in the uplink direction and
			reciprocally on the downlink direction.
	+--------+ +---------------+ +--------------------+		+--------+ +----------+ +---------+ +----------+
	| device | <=====> | Network Server| <====> | Application Server |		| End- | <=====> | Network | <====> | SCHC | <========> | Internet |
	+--------+ devAddr +---------------+ devEUI +--------------------+		| Device | devAddr | Server | devEUI | Gateway | IPv6/UDP | |
			+--------+ +----------+ +---------+ +----------+
	Figure 3: LoRaWAN addresses		Figure 4: LoRaWAN addresses
	4.3. General Message Types		4.3. General Message Types
	o Confirmed messages:		o *Confirmed messages*: The sender asks the receiver to acknowledge
			the message.
	o Unconfirmed messages:		o *Unconfirmed messages*: The sender does not ask the receiver to
			acknowledge the message.
			As SCHC defines its own acknowledgment mechanisms, SCHC does not
			require to use confirmed messages.
	4.4. LoRaWAN MAC Frames		4.4. LoRaWAN MAC Frames
	o JoinRequest		o *JoinRequest*: This message is used by a end-device to join a
			network. It contains the end-device's unique identifier devEUI
			and a random nonce that will be used for session key derivation.
	o JoinAccept		o *JoinAccept*: To on-board a end-device, the Network Server
			responds to the JoinRequest end-device's message with a JoinAccept
			message. That message is encrypted with the end-device's AppKey
			and contains (amongst other fields) the major network's settings
			and a network random nonce used to derive the session keys.
	o Data		o *Data*
	5. SCHC over LoRaWAN		5. SCHC-over-LoRaWAN
	5.1. Rule ID management		5.1. LoRaWAN FPort
	The LoRaWAN MAC layers features a port field in all frames. This		The LoRaWAN MAC layers features a frame port field in all frames.
	port field (FPort) is 8bit long and the values from 1 to 220 can be		This field (FPort) is 8-bit long and the values from 1 to 223 can be
	used. SCHC over LoRaWAN uses 2 contiguous FPort value to separate		used. It allows LoRaWAN network and application to identify data.
	the uplink SCHC traffic from the downlink and avoid any confusion.
	Those FPorts are called FPortUp and FPortDwn. Those FPorts can use
	arbitrary values inside the allowed Fport range but must be shared by
	the end-device and SCHC gateway.
	SCHC over LoRAWAN SHOULD support encoding RuleID on 3 bits, there are		A fragmentation session with application payload transferred from
	therefore 8 possible RuleIds on both uplink and downlink direction.		device to server, is called uplink fragmentation session. It uses
			FPortUpShort or FPortUpDefault for data uplink and its associated
			SCHC control downlinks. The other way, a fragmentation session with
			application payload transferred from server to device, is called
			downlink fragmentation session. It uses FPortDown for data downlink
			and its associated SCHC control uplinks.
	The RuleID 0 is reserved for fragmentation in both directions. The 7		FPorts can use arbitrary values inside the allowed FPort range and
	remaining RuleIDs are available for IPV6 header compression. Uplink		must be shared by the end-device, the Network Server and SCHC
	(on FPortUp) and downlink (on FportDwn) RuleIDs are independent. The		gateway. The uplink and downlink SCHC ports must be different. In
	same RuleID may have different meanings on the uplink and downlink		order to improve interoperability, it is recommended to use:
	paths.
	The only uplink messages using the FportDwn port are the		o FPortUpShort = 20
	fragmentation SCHC ACKs messages of a downlink fragmentation session.
	Similarly, the only downlink messages using the FportUp port are the
	fragmentation SCHC ACKs messages of an uplink fragmentation session
	5.2. IID computation		o FPortUpDefault = 21
	TBD (To discuss with the SCHC authors).		o FPortDown = 22
	5.3. No compression packets are sent using Rule ID 7.		Those are recommended values and are application defined. Also
			application can have multiple fragmentation session between a device
			and one or several SCHC gateways. A set of three FPort values is
			required for each gateway instance the device is required to
			communicate with.
			The only uplink messages using the FPortDown port are the
			fragmentation SCHC control messages of a downlink fragmentation
			session (ex ACKs). Similarly, the only downlink messages using the
			FPortUpShort or FPortUpDefault ports are the fragmentation SCHC
			control messages of an uplink fragmentation session.
			5.2. Rule ID management
			SCHC-over-LoRaWAN SHOULD support encoding RuleID on 6 bits (64
			possible rules).
			The RuleID 0 is reserved for fragmentation. The RuleID 63 is used to
			tag packets for which SCHC compression was not possible (no matching
			Rule was found).
			The remaining RuleIDs are available for compression. RuleIDs are
			shared between uplink and downlink sessions. A RuleID different from
			0 means that the fragmentation is not used, thus the packet should be
			send to C/D layer.
			5.3. IID computation
			As LoRaWAN network uses unique EUI-64 per end-device, the Interface
			IDentifier is the LoRaWAN DevEUI. It is compliant with [RFC4291] and
			IID starting with binary 000 must enforce the 64-bits rule. TODO:
			Derive IID from DevEUI with privacy constraints ? Ask working group ?
	5.4. Fragmentation		5.4. Fragmentation
	The L2 word size used by LoRaWAN is 1 octet (8 bits). The SCHC		The L2 word size used by LoRaWAN is 1 byte (8 bits). The SCHC
	fragmentation over LoRaWAN exclusively uses the ACK-always mode. A		fragmentation over LoRaWAN uses the ACK-on-Error for uplink
	LoRaWAN device cannot support simultaneous interleaved fragmentation		fragmentation and Ack-Always for downlink fragmentation. A LoRaWAN
			end-device cannot support simultaneous interleaved fragmentation
	sessions in the same direction (uplink or downlink). This means that		sessions in the same direction (uplink or downlink). This means that
	only a single fragmented IPV6 datagram may be transmitted and/or		only a single fragmented IPv6 datagram may be transmitted and/or
	received by the device at a given moment. The fragmentation		received by the end-device at a given moment.
	parameters are different for uplink and downlink fragmentation
	sessions and are successively described in the next sections.
	5.4.1. Uplink fragmentation: From device to gateway		The fragmentation parameters are different for uplink and downlink
			fragmentation sessions and are successively described in the next
			sections.
			5.5. DTag
			A LoRaWAN device cannot interleave several fragmented SCHC datagrams.
			This one bit field is used to distinguish two consecutive
			fragmentation sessions.
			_Note_: While it is used to recover faster from transmission errors,
			it SHALL not be considered as the only way to distinguish two
			fragmentation sessions.
			5.5.1. Uplink fragmentation: From device to SCHC gateway
	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.		SCHC gateway the fragmentation receiver. Two fragmentation rules are
			defined regarding the *FPort*:
	o SCHC fragmentation reliability mode : "ACK_ALWAYS"		o *FPortUpShort*: SCHC header is only one byte. Used when
			fragmentation is required and payload size is less than 381 bytes.
	o Window size: 8, the FCN field is encoded on 3 bits		o *FPortUpDefault*: SCHC header is two bytes. Used for all other
			cases: no fragmentation required or payload size is between 382
			and 1524 byte.
	o DTag : 1bit. this field is used to clearly separate two		*Both rules share common parameters:*
	consecutive fragmentation sessions. A LoRaWAN device cannot
	interleave several fragmented SCHC datagrams.
	o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the		o *SCHC fragmentation reliability mode*: "ACK-on-Error"
			o *DTag*: size is 1 bit.
			o *FCN*: The FCN field is encoded on N = 7 bits, so WINDOW_SIZE =
			127 tiles are allowed in a window (FCN=All-1 is reserved for
			SCHC).
			o *MIC calculation algorithm*: CRC32 using 0xEDB88320 (i.e. the
	reverse representation of the polynomial used e.g. in the Ethernet		reverse representation of the polynomial used e.g. in the Ethernet
	standard [RFC3385])		standard [RFC3385]) as suggested in
			[I-D.ietf-lpwan-ipv6-static-context-hc].
	o Retransmission Timer and inactivity Timer: LoRaWAN devices do not		o *MAX_ACK_REQUESTS*: 8
	implement a "retransmission timer". At the end of a window the
	ACK corresponding to this window is transmitted by the network
	gateway in the RX1 or RX2 receive slot of the device. If this ACK
	is not received the device sends an all-0 (or an all-1) fragment
	with no payload to request an ACK retransmission. The periodicity
	between retransmission of the all-0/all-1 fragments is device/
	application specific and may be different for each device (not
	specified). The gateway implements an "inactivity timer". The
	default recommended duration of this timer is 12h. This value is
	mainly driven by application requirements and may be changed.
	| RuleID | DTag | W | FCN | Payload |		o *Tile*: size is 3 bytes (24 bits)
	+ ------ + ----- + ----- | ------ + ------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | |
	Figure 4: All fragment except the last one. Header size is 8 bits.		o *Retransmission and inactivity timers*: LoRaWAN end-devices do not
			implement a "retransmission timer". At the end of a window or a
			fragmentation session, corresponding ACK(s) is (are) transmitted
			by the network gateway (LoRaWAN application server) in the RX1 or
			RX2 receive slot of end-device. If this ACK is not received the
			end-device sends an all-0 (or an all-1) fragment with no payload
			to request an SCHC ACK retransmission. The periodicity between
			retransmission of the all-0/all-1 fragments is device/application
			specific and may be different for each device (not specified).
			The SCHC gateway implements an "inactivity timer". The default
			recommended duration of this timer is 12 hours. This value is
			mainly driven by application requirements and may be changed by
			the application.
	| RuleID | DTag | W | FCN | MIC | Payload |		*The following fields are different:*
	+ ------ + ----- + ----- | ------ + ------- + ------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | 32 bits | |
	Figure 5: All-1 fragment detailed format for the last fragment.		o RuleID size
	Header size is 8 bits.
	The format of an all-0 or all-1 acknowledge is:		o Window index size W
	| RuleID | DTag | W | Encoded bitmap | Padding (0s) |		5.5.1.1. FPortUpShort - 1 byte header
	+ ------ + ----- + ----- | -------------- + ------------ +
	| 3 bits | 1 bit | 1 bit | 3 or 8 bits | 0 or 3 bits |
	Figure 6: ACK format for All-0 windows. Header size is 1 or 2 bytes.		In that case RuleID size is 0, the rule is the FPort=FPortUpShort and
			only fragmented payload can be transported.
			o *RuleID*: size is 0 bit in SCHC header, not used.
			o *Window index*: encoded on W = 0 bit, not used
			With this set of parameters, the SCHC fragment header overhead is 1
			byte (8 bits). MTU is: _127 tiles * 3 bytes per tile = 381 bytes_
			*Regular fragments*
			| DTag | FCN | Payload |
			+ ----- + ------ + ------- +
			| 1 bit | 7 bits | |
			Figure 5: All fragment except the last one. Header size is 8 bits (1
			byte).
			*SCHC ACK*
	| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) |		| RuleID | DTag | W | C | Encoded bitmap (if C = 0) | Padding (0s) |
	+ ------ + ----- + ----- + ----- + ------------------------- + ------------ +		+ ------ + ----- + ----- + ----- + ------------------------- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bit | 2 or 8 bits | 0 or 2 bits |		| 6 bits | 1 bit | 2 bit | 1 bit | 0 to 127 bits | 7 or 0 bits |
	Figure 7: ACK format for All-1 windows. Header size is 1 or 2 bytes.		Figure 6: SCHC ACK format, failed mic check.
	5.4.2. Downlinks: From gateway to device		5.5.1.2. FPortUpDefault - 2 bytes header
			o *RuleID*: size is 6 bits (64 possible rules, 62 available for
			compression)
			o *Window index*: encoded on W = 2 bits. So 4 windows are
			available.
			With this set of parameters, the SCHC fragment header overhead is 2
			bytes (16 bits). MTU is: _4 windows * 127 tiles * 3 bytes per tile =
			1524 bytes_
			_Note_: Even if it is less efficient, this rule can also be used for
			fragmented payload size less than 382 bytes.
			*Regular fragments*
			| RuleID | DTag | W | FCN | Payload |
			+ ------ + ----- + ------ + ------ + ------- +
			| 6 bits | 1 bit | 2 bits | 7 bits | |
			Figure 7: All fragment except the last one. Header size is 16 bits
			(2 bytes).
			*Last fragment (All-1)*
			| RuleID | DTag | W | FCN=All-1 | MIC | Payload |
			+ ------ + ----- + ------ + --------- + ------- + ----------------- +
			| 6 bits | 1 bit | 2 bits | 7 bits | 32 bits | Last tile, if any |
			Figure 8: All-1 fragment detailed format for the last fragment.
			*SCHC ACK*
			| RuleID | DTag | W | C | Encoded bitmap (if C = 0) |
			+ ------ + ----- + ----- + ----- + ------------------------- +
			| 6 bits | 1 bit | 2 bit | 1 bit | 0 to 127 bits |
			Figure 9: SCHC formats, failed MIC check.
			*Receiver-Abort*
			| RuleID | DTag | W = b'11 | C = 1 | b'111111 | 0xFF (all 1's) |
			+ ------ + ----- + -------- + ------+--------- + ---------------+
			| 6 bits | 1 bit | 2 bits | 1 bit | 6 bits | 8 bits |
			Figure 10: Receiver-Abort format.
			*SCHC acknowledge request*
			| RuleID | DTag | W | FCN = b'0000000 |
			+ ------ + ----- + ------ + --------------- +
			| 6 bits | 1 bit | 2 bits | 7 bits |
			Figure 11: SCHC ACK REQ format.
			5.5.2. Downlink fragmentation: From SCHC gateway to 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.		common to all devices.
	o SCHC fragmentation reliability mode : ACK_ALWAYS		o *SCHC fragmentation reliability mode*: ACK-Always.
	o Window size : 1 , The FCN field is encoded on 1 bits		o *RuleID*: size is 6 bits (64 possible rules, 62 for compression).
	o DTag : 1bit. This field is used to clearly separate two		o *Window index*: encoded on W=1 bit, as per
	consecutive fragmentation sessions. A LoRaWAN device cannot		[I-D.ietf-lpwan-ipv6-static-context-hc].
	interleave several fragmented SCHC datagrams.
	o MIC calculation algorithm: CRC32 using 0xEDB88320 (i.e. the		o *DTag*: Not used, so its size is 0 bit.
			o *FCN*: The FCN field is encoded on N=1 bits, so WINDOW_SIZE = 1
			tile (FCN=All-1 is reserved for SCHC).
			o *MIC calculation algorithm*: CRC32 using 0xEDB88320 (i.e. the
	reverse representation of the polynomial used e.g. in the Ethernet		reverse representation of the polynomial used e.g. in the Ethernet
	standard [RFC3385])		standard [RFC3385]), as per
			[I-D.ietf-lpwan-ipv6-static-context-hc].
	o MAX_ACK_REQUESTS : 8		o *MAX_ACK_REQUESTS*: 8
	| RuleID | DTag | W | FCN | Payload |		As only 1 tile is used, its size can change for each downlink, and
	+ ------ + ----- + ----- | ------ + ------- + ------- +		will be maximum available MTU minus header (1 byte)
	| 3 bits | 1 bit | 1 bit | 1 bits | X bytes + 2 bits |
	Figure 8: All fragments but the last one. Header size is 6 bits.		_Note_: The Fpending bit included in LoRaWAN protocol SHOULD not be
			used for SCHC-over-LoRaWAN protocol. It might be set by the Network
			Server for other purposes in but not SCHC needs.
	| RuleID | DTag | W | FCN | MIC | Payload | Padding (0s) |		*Regular fragments*
	+ ------ + ----- + ----- | ------ + ------- + ------- + ------------ +		| RuleID | W | FCN = b'0 | Payload |
	| 3 bits | 1 bit | 1 bit | 1 bits | 32 bits | X bytes | 0 to 7 bits |		+ ------ + ----- + --------- + ------- +
			| 6 bits | 1 bit | 1 bits | X bytes |
	Figure 9: All-1 Fragment Detailed Format for the Last Fragment.		Figure 12: All fragments but the last one. Header size 1 byte (8
	Header size is 6 bits.		bits).
	The format of an all-0 or all-1 acknowledge is:		*Last fragment (All-1)*
	| RuleID | DTag | W | Encoded bitmap | Padding (0s) |		| RuleID | W | FCN = b'1 | MIC | Payload |
	+ ------ + ----- + ----- | -------------- + ------------ +		+ ------ + ----- + --------- + ------- + ----------------- +
	| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |		| 6 bits | 1 bit | 1 bit | 32 bits | Last tile, if any |
	Figure 10: ACK format for All-0 windows. Header size is 8 bits.		Figure 13: All-1 SCHC ACK detailed format for the last fragment.
	| RuleID | DTag | W | C = 1 | Padding (0s) |		*SCHC acknowledge*
	+ ------ + ----- + ----- + ----- + ------------ +
	| 3 bits | 1 bit | 1 bit | 1 bit | 2 bits |
	Figure 11: ACK format for All-1 windows, MIC is correct. Header size		| RuleID | W | C = b'1 |
	is 8 bits.		+ ------ + ----- + ------- +
			| 6 bits | 1 bit | 1 bit |
	| RuleID | DTag | W | b'111 | 0xFF (all 1's) |		Figure 14: SCHC ACK format, MIC is correct.
	+ ------ + ----- + ----- + ------ + -------------- +
	| 3 bits | 1 bit | 1 bit | 3 bits | 8 bits |
	Figure 12: Receiver ABORT packet (following an all-1 packet with		*Receiver-Abort*
	incorrect MIC). Header size is 16 bits.
	Class A and classB&C devices do not manage retransmissions and timers		| RuleID | W | C = b'0 | b'11111111 |
	in the same way.		+ ------ + ----- + ------- + ---------- +
			| 6 bits | 1 bit | 1 bits | 8 bits |
	5.4.2.1. Class A devices		Figure 15: Receiver-Abort packet (following an all-1 packet with
			incorrect MIC).
	Class A devices can only receive in an RX slot following the		Class A and classB&C end-devices do not manage retransmissions and
			timers in the same way.
			5.5.2.1. ClassA end-devices
			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 a gateway talking to classA devices for		"retransmission timer" for an SCHC gateway. The SCHC gateway cannot
	downlink fragmentation.		initiate communication to a classA end-device.
	The device replies with an ACK fragment to every single fragment		The device replies with an ACK message to every single fragment
	received from the gateway (because the window size is 1). Following		received from the SCHC gateway (because the window size is 1).
	the reception of a FCN=0 fragment (fragment that is not the last
	fragment of the packet or ACK-request), the device MUST transmit the
	ACK fragment until it receives the fragment of the next window. The
	device shall transmit up to MAX_ACK_REQUESTS ACK fragments before
	aborting. The device should transmit those ACK as soon as possible
	while taking into consideration eventual local radio regulation on
	duty-cycle, to progress the fragmentation session as quickly as
	possible. The ACK bitmap is 1 bit long and is always 1.
	Following the reception of a FCN=1 fragment (the last fragment of a		Following the reception of a FCN=0 fragment (fragment that is not the
	datagram) and if the MIC is correct, the device shall transmit the		last fragment of the packet or ACK-request, but the end of a window),
	ACK with the "MIC is correct" indicator bit set. This message might		the device MUST transmit the SCHC ACK fragment until it receives the
	be lost therefore the gateway may request a retransmission of this		fragment of the next window. The device shall transmit up to
	ACK in the next downlink. The device SHALL keep this ACK message in		MAX_ACK_REQUESTS ACK messages before aborting. The device should
	memory until it receives a downlink from the gateway different from		transmit those ACK as soon as possible while taking into
	an ACK-request indicating that the gateway has received the ACK		consideration potential local radio regulation on duty-cycle, to
	message.		progress the fragmentation session as quickly as possible. The ACK
			bitmap is 1 bit long and is always 1.
	Following the reception of a FCN=1 fragment (the last fragment of a		Following the reception of a FCN=All-1 fragment (the last fragment of
	datagram) and if the MIC is NOT correct, the device shall transmit a		a datagram) and if the MIC is correct, the device shall transmit the
	receiver-ABORT fragment. The device SHALL keep this ABORT message in		ACK with the "MIC is correct" indicator bit set (C=1). This message
	memory until it receives a downlink from the gateway different from		might be lost therefore the SCHC gateway may request a retransmission
	an ACK-request indicating that the gateway has received the ABORT		of this ACK in the next downlink. The device SHALL keep this ACK
			message in memory until it receives a downlink, on SCHC FPortDown
			from the SCHC gateway different from an ACK-request: it indicates
			that the SCHC gateway has received the ACK message.
			Following the reception of a FCN=All-1 fragment (the last fragment of
			a datagram), if all fragments have been received and the MIC is NOT
			correct, the device shall transmit a Receiver-Abort fragment. The
			device SHALL keep this Abort message in memory until it receives a
			downlink, on SCHC FPortDown, from the SCHC gateway different from an
			ACK-request indicating that the SCHC gateway has received the Abort
	message. The fragmentation receiver (device) does not implement		message. The fragmentation receiver (device) does not implement
	retransmission timer and inactivity timer.		retransmission timer and inactivity timer.
	The fragmentation sender (the gateway) implements an inactivity timer		The fragmentation sender (the SCHC gateway) implements an inactivity
	with default duration 12 hours. Once a fragmentation session is		timer with default duration of 12 hours. Once a fragmentation
	started, if the gateway has not received any ACK or receiver-ABORT		session is started, if the SCHC gateway has not received any ACK or
	message 12 hours after the last message from the device was received,		Receiver-Abort message 12 hours after the last message from the
	the gateway may flush the fragmentation context. For devices with		device was received, the SCHC gateway may flush the fragmentation
	very low transmission rates (example 1 packet a day in normal		context. For devices with very low transmission rates (example 1
	operation) , that duration may be extended, but this is application		packet a day in normal operation) , that duration may be extended,
	specific.		but this is application specific.
	5.4.2.2. Class B or C devices		5.5.2.2. Class B or C end-devices
	Class B&C devices can receive in scheduled RX slots or in RX slots		Class B&C end-devices can receive in scheduled RX slots or in RX
	following the transmission of an uplink. The device replies with an		slots following the transmission of an uplink. The device replies
	ACK fragment to every single fragment received from the gateway		with an ACK message to every single fragment received from the SCHC
	(because the window size is 1). Following the reception of a FCN=0		gateway (because the window size is 1). Following the reception of a
	fragment (fragment that is not the last fragment of the packet or		FCN=0 fragment (fragment that is not the last fragment of the packet
	ACK-request), the device MUST always transmit the corresponding ACK		or ACK-request), the device MUST always transmit the corresponding
	fragment even if that fragment has already been received. The ACK		SCHC ACK message even if that fragment has already been received.
	bitmap is 1 bit long and is always 1. If the gateway receives this		The ACK bitmap is 1 bit long and is always 1. If the SCHC gateway
	ACK, it proceeds to send the next window fragment If the		receives this ACK, it proceeds to send the next window fragment. If
	retransmission timer elapses and the gateway has not received the ACK		the retransmission timer elapses and the SCHC gateway has not
	of the current window it retransmits the last fragment. The gateway		received the ACK of the current window it retransmits the last
	tries retransmitting up to MAX_ACK_REQUESTS times before aborting.		fragment. The SCHC gateway tries retransmitting up to
			MAX_ACK_REQUESTS times before aborting.
	Following the reception of a FCN=1 fragment (the last fragment of a		Following the reception of a FCN=All-1 fragment (the last fragment of
	datagram) and if the MIC is correct, the device shall transmit the		a datagram) and if the MIC is correct, the device shall transmit the
	ACK with the "MIC is correct" indicator bit set. If the gateway		ACK with the "MIC is correct" indicator bit set. If the SCHC gateway
	receives this ACK, the current fragmentation session has succeeded		receives this ACK, the current fragmentation session has succeeded
	and its context can be cleared.		and its context can be cleared.
	If the retransmission timer elapses and the gateway has not received		If the retransmission timer elapses and the SCHC gateway has not
	the all-1 ACK it retransmits the last fragment with the payload (not		received the SCHC ACK it retransmits the last fragment with the
	an ACK-request without payload). The gateway tries retransmitting up		payload (not an ACK-request without payload). The SCHC gateway tries
	to MAX_ACK_REQUESTS times before aborting.		retransmitting up to MAX_ACK_REQUESTS times before aborting.
	The device SHALL keep the all-1 ACK message in memory until it		The device SHALL keep the SCHC ACK message in memory until it
	receives a downlink from the gateway different from the last (FCN=1)		receives a downlink from the SCHC gateway different from the last
	fragment indicating that the gateway has received the ACK message.		(FCN>0 and different DTag) fragment indicating that the SCHC gateway
	Following the reception of a FCN=1 fragment (the last fragment of a		has received the ACK message.
	datagram) and if the MIC is NOT correct, the device shall transmit a
	receiver-ABORT fragment. The retransmission timer is used by the		Following the reception of a FCN=All-1 fragment (the last fragment of
	gateway (the sender), the optimal value is very much application		a datagram), if all fragments have been received and if the MIC is
	specific but here are some recommended default values. For classB		NOT correct, the device shall transmit a Receiver-Abort fragment.
	devices, this timer trigger is a function of the periodicity of the		The retransmission timer is used by the SCHC gateway (the sender),
	classB ping slots. The recommended value is equal to 3 times the		the optimal value is very much application specific but here are some
	classB ping slot periodicity. For classC devices which are nearly		recommended default values. For classB end-devices, this timer
	constantly receiving, the recommended value is 30 seconds. This		trigger is a function of the periodicity of the classB ping slots.
	means that the device shall try to transmit the ACK within 30 seconds		The recommended value is equal to 3 times the classB ping slot
	of the reception of each fragment. The inactivity timer is		periodicity. For classC end-devices which are nearly constantly
	implemented by the device to flush the context in-case it receives		receiving, the recommended value is 30 seconds. This means that the
	nothing from the gateway over an extended period of time. The		end-device shall try to transmit the ACK within 30 seconds of the
	recommended value is 12 hours for both classB&C devices.		reception of each fragment. The inactivity timer is implemented by
			the end-device to flush the context in-case it receives nothing from
			the SCHC gateway over an extended period of time. The recommended
			value is 12 hours for both classB&C end-devices.
	6. Security considerations		6. Security considerations
	As 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]. As such, this parameters		[I-D.ietf-lpwan-ipv6-static-context-hc]. As such, this parameters
	does not contribute to any new security issues in addition of those		does not contribute to any new security issues in addition of those
	identified in [I-D.ietf-lpwan-ipv6-static-context-hc].		identified in [I-D.ietf-lpwan-ipv6-static-context-hc].
	7. Acknowledgements		Acknowledgements
	TBD		Thanks to all those listed in the Contributors section for the
			excellent text, insightful discussions, reviews and suggestions.
	8. References		Contributors
	8.1. Normative References		Contributors ordered by family name.
			o ins: V. Audebert name: Vincent AUDEBERT org: EDF R&D street: 7 bd
			Gaspard Monge city: 91120 PALAISEAU country: FRANCE email:
			vincent.audebert@edf.fr
			o ins: J. Catalano name: Julien Catalano org: Kerlink street: 1 rue
			Jacqueline Auriol city: 35235 Thorigne-Fouillard country: France
			email: j.catalano@kerlink.fr
			o ins: M. Coracin name: Michael Coracin org: Semtech street: 14
			Chemin des Clos city: Meylan country: France email:
			mcoracin@semtech.com
			o ins: M. Le Gourrierec name: Marc Le Gourrierec org: SagemCom
			street: 250 Route de l'Empereur city: 92500 Rueil Malmaison
			country: FRANCE email: marc.legourrierec@sagemcom.com
			o ins: N. Sornin name: Nicolas Sornin org: Semtech street: 14
			Chemin des Clos city: Meylan country: France email:
			nsornin@semtech.com
			o ins: A. Yegin name: Alper Yegin org: Actility street: . city:
			Paris, Paris country: France email: alper.yegin@actility.com
			9. References
			9.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,		[RFC3385] Sheinwald, D., Satran, J., Thaler, P., and V. Cavanna,
	"Internet Protocol Small Computer System Interface (iSCSI)		"Internet Protocol Small Computer System Interface (iSCSI)
	Cyclic Redundancy Check (CRC)/Checksum Considerations",		Cyclic Redundancy Check (CRC)/Checksum Considerations",
	RFC 3385, DOI 10.17487/RFC3385, September 2002,		RFC 3385, DOI 10.17487/RFC3385, September 2002,
	<https://www.rfc-editor.org/info/rfc3385>.		<https://www.rfc-editor.org/info/rfc3385>.
			[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
			Architecture", RFC 4291, DOI 10.17487/RFC4291, February
			2006, <https://www.rfc-editor.org/info/rfc4291>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
	[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust		[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
	Header Compression (ROHC) Framework", RFC 5795,		Header Compression (ROHC) Framework", RFC 5795,
	DOI 10.17487/RFC5795, March 2010,		DOI 10.17487/RFC5795, March 2010,
	<https://www.rfc-editor.org/info/rfc5795>.		<https://www.rfc-editor.org/info/rfc5795>.
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6		[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,		Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
	February 2014, <https://www.rfc-editor.org/info/rfc7136>.		February 2014, <https://www.rfc-editor.org/info/rfc7136>.
	8.2. Informative References		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
			Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
			<https://www.rfc-editor.org/info/rfc8376>.
			9.2. Informative References
	[I-D.ietf-lpwan-ipv6-static-context-hc]		[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "LPWAN Static Context Header Compression (SCHC)		Zuniga, "LPWAN Static Context Header Compression (SCHC)
	and fragmentation for IPv6 and UDP", draft-ietf-lpwan-		and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
	ipv6-static-context-hc-18 (work in progress), December		ipv6-static-context-hc-18 (work in progress), December
	2018.		2018.
	[I-D.ietf-lpwan-overview]
	Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
	overview-10 (work in progress), February 2018.
	[lora-alliance-spec]		[lora-alliance-spec]
	Alliance, L., "LoRaWAN Specification Version V1.0.2",		Alliance, L., "LoRaWAN Specification Version V1.0.3",
	<http://portal.lora-		<https://lora-alliance.org/sites/default/files/2018-07/
	alliance.org/DesktopModules/Inventures_Document/		lorawan1.0.3.pdf>.
	FileDownload.aspx?ContentID=1398>.
	Appendix A. Examples		Appendix A. Examples
	Appendix B. Note		A.1. Uplink - Compression example - No fragmentation
	Authors' Addresses		Figure 16 is representing an applicative payload going through SCHC,
			no fragmentation required
	Nicolas Sornin (editor)		An applicative payload of 78 bytes is passed to SCHC compression layer using
	Semtech		rule 1, allowing to compress it to 40 bytes: 2 bytes residue + 38 bytes
	14 Chemin des Clos		payload.
	Meylan
	France
	Email: nsornin@semtech.com		| RuleID | Compression residue | Payload |
			+ ------ + ------------------- + --------- +
			| 1 | 18 bits | 38 bytes |
	Michael Coracin		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 for
			fragmentation. The payload will be transmitted through FPortUpDefault
			| LoRaWAN Header | RuleID | Compression residue | Payload |
			+ -------------- + ------ + ------------------- + --------- +
			| XXXX | 1 | 18 bits | 38 bytes |
			Figure 16: Uplink example: compression without fragmentation
			A.2. Uplink - Compression and fragmentation example
			Figure 17 is representing an applicative payload going through SCHC,
			with fragmentation.
			An applicative payload of 478 bytes is passed to SCHC compression layer using
			rule 1, allowing to compress it to 440 bytes: 18 bits residue + 138 bytes
			payload.
			| RuleID | Compression residue | Payload |
			+ ------ + ------------------- + --------- +
			| 1 | 18 bits | 138 bytes |
			Given the size of the payload, FPortUpDefault will be used.
			The current LoRaWAN MTU is 11 bytes, although 2 bytes FOpts are used by
			LoRaWAN protocol: 9 bytes are available for SCHC payload.
			SCHC header is 2 bytes so 2 tiles are send in first fragment.
			| LoRaWAN Header | FOpts | RuleID | DTag | W | FCN | 2 tiles |
			+ -------------- + ------- + ------ + ----- + ------ + ------ + ------- +
			| XXXX | 2 bytes | 0 | 0 | 0 | 126 | 6 bytes |
			Content of the two tiles is:
			| RuleID | Compression residue | Payload |
			+ ------ + ------------------- + --------- +
			| 1 | 18 bits | 3 bytes |
			Next transmission MTU is 242 bytes, no FOpts. 80 tiles are transmitted:
			| LoRaWAN Header | RuleID | DTag | W | FCN | 80 tiles |
			+ -------------- + ------ + ----- + ------ + ------ + --------- +
			| XXXX | 0 | 0 | 0 | 124 | 240 bytes |
			Next transmission MTU is 242 bytes, no FOpts. All 65 remaining tiles are
			transmitted, last tile is only 2 bytes.
			| LoRaWAN Header | RuleID | DTag | W | FCN | MIC | 65 tiles |
			+ -------------- + ------ + ----- + ------ + ------ + ----- + --------- +
			| XXXX | 0 | 0 | 0 | 127 | CRC32 | 194 bytes |
			All packets have been received by the SCHC gateway, computed MIC is correct so
			the following ACK is send to the device:
			| LoRaWAN Header | RuleID | DTag | W | C |
			+ -------------- + ------ + ----- + ------ + --- +
			| XXXX | 0 | 0 | 0 | 1 |
			Figure 17: Uplink example: compression and fragmentation
			A.3. Downlink
			TODO
			Appendix B. Note
			Authors' Addresses
			Olivier Gimenez (editor)
	Semtech		Semtech
	14 Chemin des Clos		14 Chemin des Clos
	Meylan		Meylan
	France		France
	Email: mcoracin@semtech.com		Email: ogimenez@semtech.com
			Ivaylo Petrov (editor)
	Ivaylo Petrov
	Acklio		Acklio
	2bis rue de la Chataigneraie		2bis rue de la Chataigneraie
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ivaylo@ackl.io		Email: ivaylo@ackl.io
	Alper Yegin
	Actility
	.
	Paris, Paris
	France
	Email: alper.yegin@actility.com
	Julien Catalano
	Kerlink
	1 rue Jacqueline Auriol
	35235 Thorigne-Fouillard
	France
	Email: j.catalano@kerlink.fr
	Vincent AUDEBERT
	EDF R&D
	7 bd Gaspard Monge
	91120 PALAISEAU
	FRANCE
	Email: vincent.audebert@edf.fr
End of changes. 111 change blocks.
	344 lines changed or deleted		608 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/