< draft-minaburo-lpwan-nbiot-hc-01.txt		draft-minaburo-lpwan-nbiot-hc-02.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational E. Ramos		Intended status: Informational E. Ramos
	Expires: March 8, 2019 Ericsson		Expires: September 8, 2019 Ericsson
	S. Shanmugalingam		S. Shanmugalingam
	Acklio		Acklio
	September 04, 2018		March 07, 2019
	LPWAN Static Context Header Compression (SCHC) over NB-IoT		LPWAN Static Context Header Compression (SCHC) over NB-IoT
	draft-minaburo-lpwan-nbiot-hc-01		draft-minaburo-lpwan-nbiot-hc-02
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Static Context Header Compression (SCHC) specification describes
	a header compression and fragmentation functionalities for LPWAN (Low		a header compression and fragmentation functionalities for LPWAN (Low
	Power Wide Area Networks) technologies. SCHC was designed to be		Power Wide Area Networks) technologies. SCHC was designed to be
	adapted over any of the LPWAN technologies.		adapted over any of the LPWAN technologies.
	This document describes the use of SCHC over the NB-IoT wireless		This document describes the use of SCHC over the NB-IoT wireless
	access, and provides elements for an efficient parameterization.		access, and provides elements for an efficient parameterization.
	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 March 8, 2019.		This Internet-Draft will expire on September 8, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Data Transmission . . . . . . . . . . . . . . . . . . . . 5		4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Data Transmission over User Plane . . . . . . . . . . . . 6		5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7
	3.2.1. Packet Data Convergence Protocol (PDCP) . . . . . . . 7		5.1. SCHC over User Plane transmissions . . . . . . . . . . . 8
	3.2.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . . 7		5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
	3.2.3. Medium Access Control (MAC) . . . . . . . . . . . . . 8		5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 9
	3.3. Data Over Control Plane . . . . . . . . . . . . . . . . . 9		5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 10
	3.4. SCHC entities . . . . . . . . . . . . . . . . . . . . . . 13		5.3. Parameters for Static Context Header Compression (SCHC) . 10
	4. Static Context Header Compression . . . . . . . . . . . . . . 13		5.3.1. SCHC Context initialization . . . . . . . . . . . . . 11
	4.1. SCHC Rules . . . . . . . . . . . . . . . . . . . . . . . 13		5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 11
	4.2. Packet processing . . . . . . . . . . . . . . . . . . . . 13		5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. SCHC Context . . . . . . . . . . . . . . . . . . . . . . 13		5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12
	5. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 13		5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
	5.1. Fragmentation modes . . . . . . . . . . . . . . . . . . . 14		6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 13
	5.2. Fragmentation Parameters . . . . . . . . . . . . . . . . 14		6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 13
	6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.2. Parameters for Static Context Header Compression . . . . 14
	7. Security considerations . . . . . . . . . . . . . . . . . . . 14		6.2.1. SCHC Context initialization . . . . . . . . . . . . . 14
	8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 14
	8.1. NB-IoT example with mobility . . . . . . . . . . . . . . 15		6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14
	9. Informative References . . . . . . . . . . . . . . . . . . . 15		6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14
			6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 15
			6.3.2. Fragmentation Parameters(TBD) . . . . . . . . . . . . 15
			7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
			8. Security considerations . . . . . . . . . . . . . . . . . . . 16
			9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 16
			10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16
			10.1. NB-IoT User Plane protocol architecture . . . . . . . . 16
			10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 16
			10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17
			10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18
			10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19
			11. Informative References . . . . . . . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC)		The Static Context Header Compression (SCHC)
	[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression		[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
	scheme and fragmentation functionality, both specially tailored for		scheme and fragmentation functionality, both specially tailored for
	Low Power Wide Area Networks (LPWAN) networks defined in		Low Power Wide Area Networks (LPWAN) networks defined in [RFC8376].
	[I-D.ietf-lpwan-overview].
	Header compression is needed to efficiently bring Internet		Header compression is needed to efficiently bring Internet
	connectivity to the node within an NB-IoT network. SCHC uses an		connectivity to the node within an NB-IoT network. SCHC uses a
	static context to performs header compression with specific		static context to performs header compression with specific
	parameters that need to be adapted into the NB-IoT wireless access.		parameters that need to be adapted into the NB-IoT wireless access.
	This document assumes functionality for NB-IoT of 3GPP release 15		This document assumes functionality for NB-IoT of 3GPP release 15
	otherwise other versions functionality is explicitly mentioned in the		otherwise other versions functionality is explicitly mentioned in the
	text.		text.
	This document describes the use of SCHC and its parameterizing over		This document describes the use of SCHC and its parameterizing over
	the NB-IoT wireless access.		the NB-IoT wireless access.
	2. Terminology		2. Terminology
	This document will follow the terms defined in		This document will follow the terms defined in
	[I-D.ietf-lpwan-ipv6-static-context-hc], in		[I-D.ietf-lpwan-ipv6-static-context-hc], in [RFC8376], and the
	[I-D.ietf-lpwan-overview], and the TGPP23720.		[TGPP23720].
	o CIoT. Cellular IoT		o CIoT. Cellular IoT
	o C-SGN. CIoT Serving Gateway Node		o C-SGN. CIoT Serving Gateway Node
	o UE. User Equipment		o UE. User Equipment
	o eNB. Node B. Base Station that controls the UE		o eNB. Node B. Base Station that controls the UE
	o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE		o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
	systems.		systems.
	o EUTRAN. Evolved Universal Terrestrial Radio Access Network.		o EUTRAN. Evolved Universal Terrestrial Radio Access Network.
	Radio network from LTE based systems.		Radio network from LTE based systems.
	o MME. Mobility Management Entity. Handle mobility of the UE		o MME. Mobility Management Entity. Handle mobility of the UE
	o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology		o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology
	based in LTE architecture but with additional optmization for IoT		based in LTE architecture but with additional optimization for IoT
	and using a Narrow Band spectrum frequency.		and using a Narrow Band spectrum frequency.
	o SGW. Serving Gateway. Routes and forwards the user data packets		o SGW. Serving Gateway. Routes and forwards the user data packets
	through the access network		through the access network
	o HSS. Home Subscriber Server. It is a database that performs		o HSS. Home Subscriber Server. It is a database that performs
	mobility management		mobility management
	o PGW. Packet Data Node Gateway. Interface between the internal		o PGW. Packet Data Node Gateway. An interface between the internal
	with the external network		with the external network
	o PDU. Protocol Data Unit. Data packets including headers that are		o PDU. Protocol Data Unit. Data packets including headers that are
	transmitted between entities through a protocol.		transmitted between entities through a protocol.
	o SDU. Service Data Unit. Data packets (PDUs) from higher layers		o SDU. Service Data Unit. Data packets (PDUs) from higher layers
	protocols used by lower layer protocols as payload of their own		protocols used by lower layer protocols as a payload of their own
	PDUs that has not yet been encapsulated.		PDUs that has not yet been encapsulated.
	o IWK-SCEF. InterWorking Service Capabilities Exposure Function.		o IWK-SCEF. InterWorking Service Capabilities Exposure Function.
	Used in roaming scenarios and serves for interconnection with the		Used in roaming scenarios and serves for interconnection with the
	SCEF of the Home PLMN and is located in the Visited PLMN		SCEF of the Home PLMN and is located in the Visited PLMN
	o SCEF. Service Capability Exposure Function. EPC node for		o SCEF. Service Capability Exposure Function. EPC node for
	exposure of 3GPP network service capabilities to 3rd party		exposure of 3GPP network service capabilities to 3rd party
	applications.		applications.
	3. Architecture		3. Architecture
	## NB-IoT entities
	+--+		+--+
	|UE| \ +------+ +------+		|UE| \ +-----+ +------+
	+--+ \ | MME |------| HSS |		+--+ \ | MME |-----| HSS |
	\ / +------+ +------+		\ / +-----+ +------+
	+--+ \+-----+ / |		+--+ \+-----+ / |
	|UE| ----| eNB |- |		|UE| ----| eNB |- |
	+--+ /+-----+ \ |		+--+ /+-----+ \ |
	/ \ +--------+		/ \ +------+
	/ \| | +------+ Service PDN		/ \| | +------+ Service PDN
	+--+ / | S-GW |----| P-GW |---- e.g. Internet		+--+ / | S-GW |--| P-GW |-- e.g. Internet
	|UE| | | +------+		|UE| | | +------+
	+--+ +--------+		+--+ +------+
	Figure 1: 3GPP network architecture		Figure 1: 3GPP network architecture
	The architecture for 3GPP LTE network has been reused for NB-IoT with		The architecture for 3GPP LTE network has been reused for NB-IoT with
	some optimizations and simplifications known as Cellular IoT (CIoT).		some optimizations and simplifications known as Cellular IoT (CIoT).
	Considering the typical use cases for CIoT devices here are described		Considering the typical use cases for CIoT devices here are described
	some of the additions to the LTE architecture specific for CIoT.		some of the additions to the LTE architecture specific for CIoT.
	C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating		C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating
	EPS entities in the control plane and user plane paths (for example,		EPS entities in the control plane and user plane paths (for example,
	MME + SGW + P-GW) and the external interfaces of the entities		MME + SGW + P-GW) and the external interfaces of the entities
	supported. The C-SGN also supports at least some of the following		supported. The C-SGN also supports at least some of the following
	CIoT EPS Optimizations: * Control Plane CIoT EPS Optimization for		CIoT EPS Optimizations:
	small data transmission. * User Plane CIoT EPS Optimization for
	small data transmission. * Necessary security procedures for		o Control Plane CIoT EPS Optimization for small data transmission.
	efficient small data transmission. * SMS without combined attach for
	NB-IoT only UEs. * Paging optimizations for coverage enhancements.		o User Plane CIoT EPS Optimization for small data transmission.
	* Support for non-IP data transmission via SGi tunneling and/or SCEF.
	* Support for Attach without PDN (Packet Data Network) connectivity.		o Necessary security procedures for efficient small data
			transmission.
			o SMS without combined attach for NB-IoT only UEs.
			o Paging optimizations for coverage enhancements.
			o Support for non-IP data transmission via SGi tunneling and/or
			SCEF.
			o Support for Attach without PDN (Packet Data Network) connectivity.
	Another node introduced in the CIOT architecture is the SCEF (Service		Another node introduced in the CIOT architecture is the SCEF (Service
	Capability Exposure Function) that provide means to securely expose		Capability Exposure Function) that provide means to securely expose
	service and network capabilities to entities external to the network		service and network capabilities to entities external to the network
	operator. The northbound APIS are defined by OMA and OneM2M. The		operator. The northbound APIS are defined by OMA and OneM2M. The
	main functions of a SCEF are: * Non-IP Data Delivery (NIDD)		main functions of a SCEF are:
	established through the SCEF. * Monitoring and exposure of event
	related to UE reachability, loss of connectivity, location reporting,
	roaming status, communication failure and change of IMEI-IMSI
	association.
	+---------+		o Non-IP Data Delivery (NIDD) established through the SCEF.
	| HSS |
	+---------+		o Monitoring and exposure of event related to UE reachability, loss
			of connectivity, location reporting, roaming status, communication
			failure and change of IMEI-IMSI association.
			+-------+
			| HSS |
			+-+-----+
	/		/
	+-----------+ /S6a		+---------+ __/S6a
	+--------+ | |/		+--------+ | +-----+ +_/
	+----+ C-Uu | +----+ | T6i +--------+ T7 +----+		+----+ C-Uu | +---+-+ MME | | T6i+--------+ T7 +----+
	|CIOT+--------+ eNB | S1 | +------+IWK-SCEF+----+SCEF|		|CIOT+--------+ eNB |S1 | | +-+----+IWK-SCEF+----+SCEF|
	|UE | |(NB-IoT)| | | +--------+ +----+		|UE | |(NB-IoT)| | +---+-+ | +--------+ +----+
	+----+ +--------+ | | +------------+		+----+ +--------+ | | |
	| C-SGN |SGd | SMS-GMSC/ |		|C-SGN| |
	| +------+ IWMSC/SMS |		| |S11|
	+--------+ | | | router |		+------+ | | |
	+----+ LTE-Uu | | | | +------------+		+--------+LTE-Uu| | | +--+-+ |
	|LTE | (eMTC) | eNB +---+ | S8 +---+ +------+		|LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+
	|eMTC+---------+(eMTC) | S1| +------+PGW|SGi |Appli.|		| UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application|
	| UE | +--------+ | | | +----+Server|		+--------+ +------+ | +----+ | | +----+Server (AS)|
	+----+ +-----------+ +---+ | (AS) |		+---------+ +---+ +-----------+
	+------+
	Figure 2: 3GPP optimized CIOT network architecture		Figure 2: 3GPP optimized CIOT network architecture
	3.1. Data Transmission		4. Data Transmission
	3GPP networks deals not only with data transmitted end-to-end but		3GPP networks deal not only with data transmitted end-to-end but also
	also with in-band signaling that is used between the nodes and		with in-band signaling that is used between the nodes and functions
	functions to configure, control and monitor the system functions and		to configure, control and monitor the system functions and behaviors.
	behaviors. The control data is handled using a Control Plane which		The control data is handled using a Control Plane which has a
	has an specific set of protocols, handling processes and entities.		specific set of protocols, handling processes and entities. In
	In contrast the end-to-end or user data utilize a User Plane with		contrast, the end-to-end or user data utilize a User Plane with
	characteristics of its own separated from the Control Plane. The		characteristics of its own separated from the Control Plane. The
	handling and setup of the Control Plane and User Plane spans over the		handling and setup of the Control Plane and User Plane spans over the
	whole 3GPP network and it has particular implications in the radio		whole 3GPP network and it has particular implications in the radio
	network (i.e., EUTRAN) and in the packet core (ex., EPC).		network (i.e., EUTRAN) and in the packet core (ex., EPC).
	For the CIOT cases, additionally to transmissions of data over User		For the CIOT cases, additionally to transmissions of data over User
	Plane, 3GPP has specified optimizations for small data transmissions		Plane, 3GPP has specified optimizations for small data transmissions,
	that allows to transport user data (IP, Non-IP) within signaling on		allowing to transport user data (IP, Non-IP) within signaling on the
	the access network (Data transmission over Control Plane or Data Over		access network (Data transmission over Control Plane or Data Over
	NAS).		NAS).
	The maximum recommended MTU size is 1358 Bytes. The radio network		The maximum recommended MTU size is 1358 Bytes. The radio network
	protocols limits the packet sizes to be transmitted over the air		protocols limit the packet sizes to be transmitted over the air
	including radio protocol overhead to 1600 Octets. But the value is		including radio protocol overhead to 1600 Octets. But the value is
	reduced further to avoid fragmentation in the backbone of the network		reduced further to avoid fragmentation in the backbone of the network
	due to the payload encryption size (multiple of 16) and handling of		due to the payload encryption size (multiple of 16) and handling of
	the additional core transport overhead.		the additional core transport overhead.
	3.2. Data Transmission over User Plane		NB-IoT and in general the cellular technologies interfaces and
			functions are standardized by 3GPP. Therefore the introduction of
	The User Plane utilizes the protocol stack of the Access Stratum (AS)		SCHC entities to UE, eNB and C-SGN does need to be specified in the
	for data transfer. AS (Access Stratum) is the functional layer		NB-IoT standard. This implies that standard specified SCHC support
	responsible for transporting data over wireless connection and		would not be backwards compatible. A terminal or a network
	managing radio resources. The user plane AS has support for features		supporting a version of the standard without support of SCHC or
	such as reliability, segmentation and concatenation. The		without capability implementation (in case of not being standardized
	transmissions of the AS utilize link adaptation, meaning that the		as mandatory capability) is not able to utilize the compression
	transport format utilized for the transmissions are optimized		services with this approach.
	according to the radio conditions, the number of bits to transmit and
	the power and interference constrains. That means that the number of
	bits transmitted over the air depends of the Modulation and Coding
	Schemes (MCS) selected. The transmissions in the physical layer
	happens at network synchronized intervals of times called TTI
	(Transmission Time Interval). The transmission of a Transport Block
	(TB) is completed during, at least, one TTI. Each Transport Block
	has a different MCS and number of bits available to transmit. The
	Transport Blocks characteristics are defined by the MAC technical
	specification {TGPP36321}. The Access Stratum for User Plane is
	comprised by Packet Data Convergence Protocol (PDCP) {TGPP36323},
	Radio Link Protocol (RLC){TGPP36322}, Medium Access Control protocol
	(MAC){TGPP36321} and the Physical Layer {TGPP36201}.
	+---------+ +---------+ |		SCHC could be deployed differently depending on where the header
	|IP/non-IP+--------------------------------+IP/non-IP+->+		compression and the fragmentation are applied. The SCHC
	+---------+ | +----------------+ | +---------+ |		functionalities could be applied to the packets about to be
	| PDCP +-------+ PDCP | GTP|U +-------+ GTP-U |->+		transmitted over the air, or to the whole end-to-end link. To
	+---------+ | +----------------+ | +---------+ |		accomplish the first, it is required to place SCHC compression and
	| RLC +-------+ RLC |UDP/IP +-------+ UDP/IP +->+		decompression entities in the eNB and in the UE for transmissions
	+---------+ | +----------------+ | +---------+ |		over the User Plane. Additionally, to handle the case of the
	| MAC +-------+ MAC | L2 +-------+ L2 +->+		transmissions over Control Plane or Data Over NAS, the network SCHC
	+---------+ | +----------------+ | +---------+ |		entity has to be placed in the C-SGN as well. For these two cases,
	| PHY +-------+ PHY | PHY +-------+ PHY +->+		the functions are to be standardized by 3GPP.
	+---------+ +----------------+ +---------+ |
	C-Uu/ S1-U SGi
	CIOT/ LTE+Uu C-BS/eNB C-SGN
	LTE eMTC
	UE
	Figure 3: 3GPP CIOT radio protocol architecture for data over user		Another possibility is to apply SCHC functionalities to the end-to-
	plane		end connection or at least up to the operator network edge. In that
			case, the SCHC entities would be placed in the application layer of
			the terminal in one end, and either in the application servers or in
			a broker function in the edge of the operator network in the other
			end. For the radio network, the packets are transmitted as non-IP
			traffic, which can be currently served utilizing IP tunneling or SCEF
			services. Since this option does not necessarily require 3GPP
			standardization, it is possible to also benefit legacy devices with
			SCHC by utilizing the non-IP transmission features of the operator
			network.
	3.2.1. Packet Data Convergence Protocol (PDCP)		Accordingly, there are four different scenarios where SCHC can be
			used in the NB-IoT architecture. IP header compression on the data
			transmission over User Plane, IP header compression on the optimized
			transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions
			of SCHC packets by IP tunneling, and non-IP transmissions of SCHC
			packets by SCEF forwarding. The following sections describe each of
			them in more detail. The first two scenarios refer to transmissions
			using the 3GPP IP transmission capabilities and the last two refers
			to transmission using the Non-IP capabilities.
	Each of the Radio Bearers (RB) are associated with one PDCP entity.		5. IP based Data Transmission
	And a PDCP entity is associated with one or two RLC entities		5.1. SCHC over User Plane transmissions
	depending of the unidirectional or bi-directional characteristics of
	the RB and RLC mode used. A PDCP entity is associated either control
	plane or user plane which independent configuration and functions.
	The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets.
	The main services and functions of the PDCP sublayer for NB-IoT for
	the user plane include: * Header compression and decompression by
	means of ROHC (Robust Header Compression) * Transfer of user and
	control data to higher and lower layers * Duplicate detection of
	lower layer SDUs when re-establishing connection (when RLC with
	Acknowledge Mode in use for User Plane only) * Ciphering and
	deciphering * Timer-based SDU discard in uplink
	3.2.2. Radio Link Protocol (RLC)		Deploying SCHC only over the radio link would require to place it as
			part of the User Plane data transmission. The User Plane utilizes
			the protocol stack of the Access Stratum (AS) for data transfer. AS
			(Access Stratum) is the functional layer responsible for transporting
			data over wireless connection and managing radio resources. The user
			plane AS has support for features such as reliability, segmentation
			and concatenation. The transmissions of the AS make use of link
			adaptation, meaning that the transport format utilized for the
			transmissions are optimized according to the radio conditions, the
			number of bits to transmit and the power and interference constrains.
			That means that the number of bits transmitted over the air depends
			of the Modulation and Coding Schemes (MCS) selected. The
			transmissions in the physical layer happens at network synchronized
			intervals of times called TTI (Transmission Time Interval). The
			transmission of a Transport Block (TB) is completed during, at least,
			one TTI. Each Transport Block has a different MCS and number of bits
			available to transmit. The Transport Blocks characteristics are
			defined by the MAC technical specification [TGPP36321]. The Access
			Stratum for User Plane is comprised by Packet Data Convergence
			Protocol (PDCP) [TGPP36323], Radio Link Protocol (RLC)[TGPP36322],
			Medium Access Control protocol (MAC)[TGPP36321] and the Physical
			Layer [TGPP36201]. More details of this protocols are given in the
			Appendix.
	RLC is a layer-2 protocol that operates between the UE and the base		5.1.1. SCHC Entities Placing
	station (eNB). It supports the packet delivery from higher layers to
	MAC creating packets that are transmitted over the air optimizing the
	Transport Block utilization. RLC flow of data packets is
	unidirectional and it is composed of a transmitter located in the
	transmission device and a receiver located in the destination device.
	Therefore to configure bi-directional flows, two set of entities, one
	in each direction (downlink and uplink) must be configured and they
	are effectively peered to each other. The peering allows the
	transmission of control packets (ex., status reports) between
	entities. RLC can be configured for data transfer in one of the
	following modes: * Transparent Mode (TM). In this mode RLC do not
	segment or concatenate SDUs from higher layers and do not include any
	header to the payload. When acting as a transmitter, RLC receives
	SDUs from upper layers and transmit directly to its flow RLC receiver
	via lower layers. Similarly, an TM RLC receiver would only deliver
	without additional processing the packets to higher layers upon
	reception. * Unacknowledged Mode (UM). This mode provides support
	for segmentation and concatenation of payload. The size of the RLC
	packet depends of the indication given at a particular transmission
	opportunity by the lower layer (MAC) and are octets aligned. The
	packet delivery to the receiver do not include support for
	reliability and the lost of a segment from a packet means a whole
	packet loss. Also in case of lower layer retransmissions there is no
	support for re-segmentation in case of change of the radio conditions
	triggring the selection of a smaller transport block. Additionally
	it provides PDU duplication detection and discard, reordering of out
	of sequence and loss detection. * Acknowledged Mode (AM).
	Additional to the same functions supported from UM, this mode also
	adds a moving windows based reliability service on top of the lower
	layer services. It also provides support for re-segmentation and it
	requires bidirectional communication to exchange acknowledgment
	reports called RLC Status Report and trigger retransmissions is
	needed. Protocol error detection is also supported by this mode.
	The mode uses depends of the operator configuration for the type of
	data to be transmitted. For example, data transmissions supporting
	mobility or requiring high reliability would be most likely
	configured using AM, meanwhile streaming and real time data would be
	map to a UM configuration.
	3.2.3. Medium Access Control (MAC)		The current architecture provides support for header compression in
			PDCP utilizing RoHC [RFC5795]. Therefore SCHC entities can be
			deployed in similar fashion without need for major changes in the
			3GPP specifications.
	MAC provides a mapping between the higher layers abstraction called		In this scenario, RLC takes care of the handling of fragmentation (if
	Logical Channels comprised by the previously described protocols to		transparent mode is not configured) when packets exceeds the
	the Physical layer channels (transport channels). Additionally, MAC		transport block size at the time of transmission. Therefore SCHC
	may multiplex packets from different Logical Channels and prioritize		fragmentation is not needed and should not be used to avoid
	what to fit into one Transport Block if there is data and space		additional protocol overhead. It is not common to configure RLC in
	available to maximize the efficiency of data transmission. MAC also		Transparent Mode for IP based user plane data. But given the case in
	provides error correction and reliability support by means of HARQ,		the future, SCHC fragmentation may be used. In that case, a SCHC
	transport format selection and scheduling information reporting from		tile would match the minimum transport block size minus the PDCP and
	the terminal to the network. MAC also adds the necessary padding and		MAC headers.
	piggyback control elements when possible additional to the higher
	layers data.
	<Max. 1600 bytes>		+---------+ +---------+ |
	+-----+ +---+ +---------+		|IP/non-IP+------------------------------+IP/non-IP+->+
	Application | AP1 | |AP1| | AP2 |		+---------+ | +---------------+ | +---------+ |
	(IP/non-IP) | PDU | |PDU| | PDU |		| PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+
	+-----+ +---+ +---------+		| (SCHC) + + (SCHC)| + + | |
	| | | | | |		+---------+ | +---------------+ | +---------+ |
	PDCP +----------+ +--------+ +--------------+		| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+
	|PDCP| AP1 | |PDCP|AP1| |PDCP| AP2 |		+---------+ | +---------------+ | +---------+ |
	|Head| PDU | |Head|PDU| |Head| PDU |		| MAC +-------+ MAC | L2 +------+ L2 +->+
	+----------+ +--------+ +---------+----\		+---------+ | +---------------+ | +---------+ |
	| | | | | | | | |\ \_____		| PHY +-------+ PHY | PHY +------+ PHY +->+
	| | | | | | | | | \ \		+---------+ +---------------+ +---------+ |
	+----------------------------+ | | (1)| \_____(2) \		C-Uu/ S1-U SGi
	RLC |RLC|PDCP| AP1 |RLC |PDCP|AP1| +--------------+ +----|----+		CIOT/ LTE+Uu C-BS/eNB C-SGN
	|Head|Head|PDU |Head|Head|PDU| |RLC |PDCP| AP2| |RLC | AP2|		LTE eMTC
	+--------------|-------------+ |Head|Head| PDU| |Head| PDU|		UE
	| | | | | +---------|----+ +---------+
	| | | LCID1 | | / / / | |
	| | | | |/ / /LCID2| |
	| | | | | | | | |
	| | | | | | | | |
	+----------------------------------------------+ +---------+------+
	M |MAC|RLC|PDCP| AP1 |RLC |PDCP|AP1|RLC |PDCP|AP2| |MAC |RLC | AP2|P|
	A |Hea|Hea|Hea-| PDU |Hea-|Hea-|PDU|Hea-|Hea-|PDU| |Hea-|Hea-| PDU|a|
	C |der|der| der| |der |der | |der |der |PDU| |der |der | |d|
	+----------------------------------------------+ +--------------+-+
	TB1 TB2
	Figure 4: Example of User Plane packet encapsulation for two		Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol
	transport blocks		architecture for data over user plane
	3.3. Data Over Control Plane		5.2. Data Over Control Plane
	The Non-Access Stratum (NAS), conveys mainly control signaling		The Non-Access Stratum (NAS), conveys mainly control signaling
	between the UE and the cellular network {TGPP24301}. NAS is		between the UE and the cellular network [TGPP24301]. NAS is
	transported on top of the Access Stratum (AS) already presented in		transported on top of the Access Stratum (AS) already mentioned in
	the previous sections.		the previous section.
	+---------+ +---------+---------+ |
	|IP/non-IP|---|-----------------------|---|IP/non-IP|IP/non-IP|->|
	+---------+ | | +---------+---------+ >|
	| NAS |---|-----------------------|---| NAS | GTP-C/U |->|
	+---------+ | +------+------+ | +---------+---------+ |
	| RRC |---|----| RRC | S1-AP|----|---| S1-AP | | |
	+---------+ | +------+------+ | +---------+ UDP |->|
	| PDCP* |---|----| PDCP*| SCTP |----|---| SCTP | | |
	+---------+ | +------+------+ | +---------+---------+ |
	| RLC |---|----| RLC | IP |----|---| IP | IP |->|
	+---------+ | +------+------+ | +---------+---------+ |
	| MAC |---|----| MAC | L2 |----|---| L2 | L2 |->|
	+---------+ | +------+------+ | +---------+---------+ |
	| PHY |---|----| PHY | PHY |----|---| PHY | PHY |->|
	+--------- +------+------+ +---------+---------+ |
	C-Uu/ S1-lite SGi
	CIOT/ LTE-Uu C-BS/eNB C-SGN
	LTE eMTC
	UE
	*PDCP is bypassed until AS security is activated TGPP36300.
	Figure 5: 3GPP CIOT radio protocol architecture for DoNAS
	transmissions
	NAS has been adapted to provide support for user plane data		NAS has been adapted to provide support for user plane data
	transmissions to reduce the overhead when transmitting infrequent		transmissions to reduce the overhead when transmitting infrequent
	small quantities of data. This is known as Data over NAS (DoNAS) or		small quantities of data. This is known as Data over NAS (DoNAS) or
	Control Plane CIoT EPS optimization. In DoNAS the UE makes use of		Control Plane CIoT EPS optimization. In DoNAS the UE makes use of
	the pre-established NAS security and piggyback uplink small data into		the pre-established NAS security and piggyback uplink small data into
	the initial NAS uplink message, and uses an additional NAS message to		the initial NAS uplink message, and uses an additional NAS message to
	receive downlink small data response. The data encryption from the		receive downlink small data response.
	network side is performed by the C-SGN in a NAS PDU. The AS protocol
	stack used by DoNAS is somehow special. Since the security
	associations are not established yet in the radio network, to reduce
	the protocol overhead, PDCP (Packet Data Convergence Protocol) is
	bypassed until AS security is activated. RLC (Radio Link Control
	protocol) is configured by default in AM mode, but depending of the
	features supported by the network and the terminal it may be
	configured in other modes by the network operator. For example, the
	transparent mode does not add any header or does not process the
	payload in any way reducing the overhead, but the MTU would be
	limited by the transport block used to transmit the data which is
	couple of thousand of bits maximum. If UM (only Release 15
	compatible terminals) is used, the RLC mechanisms of reliability is
	disabled and only the reliability provided by the MAC layer by Hybrid
	Automatic Repeat reQuest (HARQ) is available. In this case, the
	protocol overhead might be smaller than for the AM case because the
	lack of status reporting but with the same support for segmentation
	up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio
	Resource Control){TGPP36331} message.
	Depending of the data type indication signaled (IP or non-IP data),		The data encryption from the network side is performed by the C-SGN
	the network allocates an IP address or just establish a direct		in a NAS PDU. Depending on the data type signaled indication (IP or
	forwarding path. DoNAS is regulated under rate control upon previous		non-IP data), the network allocates an IP address or just establish a
	agreement, meaning that a maximum number of bits per unit of time is		direct forwarding path. DoNAS (Data over NAS) is regulated under
	agreed per device subscription beforehand and configured in the		rate control upon previous agreement, meaning that a maximum number
	device. The use of DoNAS is typically expected when a terminal in a		of bits per unit of time is agreed per device subscription beforehand
	power saving state requires to do a short transmission and receive an		and configured in the device.
	acknowledgment or short feedback from the network. Depending of the
			The use of DoNAS is typically expected when a terminal in a power
			saving state requires to do a short transmission and receive an
			acknowledgment or short feedback from the network. Depending on the
	size of buffered data to transmit, the UE might be instructed to		size of buffered data to transmit, the UE might be instructed to
	deploy the connected mode transmissions instead, limiting and		deploy the connected mode transmissions instead, limiting and
	controlling the DoNAS transmissions to predefined thresholds and a		controlling the DoNAS transmissions to predefined thresholds and a
	good resource optimization balance for the terminal and the network.		good resource optimization balance for the terminal and the network.
	The support for mobility of DoNAS is present but produces additional		The support for mobility of DoNAS is present but produces additional
	overhead.		overhead. Additional details of DoNAS are given in the Appendix.
	+--------+ +--------+ +--------+		5.2.1. SCHC Entities Placing
	| | | | | | +------------------+
	| UE | | C-BS | | C-SGN | | Roaming Scenarios|
	+----|---+ +--------+ +--------+ | +--------+ |
	| | | | | | |
	+----------------|------------|+ | | P-GW | |
	| Attach | | +--------+ |
	+------------------------------+ | | |
	| | | | | |
	+------|------------|--------+ | | | |
	|RRC Connection Establishment| | | | |
	|with NAS PDU transmission | | | | |
	|& Ack Rsp | | | | |
	+----------------------------+ | | | |
	| | | | | |
	| |Initial UE | | | |
	| |message | | | |
	| |----------->| | | |
	| | | | | |
	| | +---------------------+| | |
	| | |Checks Integrity || | |
	| | |protection, decrypts || | |
	| | |data || | |
	| | +---------------------+| | |
	| | | Small data packet |
	| | |-------------------------------->
	| | | Small data packet |
	| | |<--------------------------------
	| | +----------|---------+ | | |
	| | Integrity protection,| | | |
	| | encrypts data | | | |
	| | +--------------------+ | | |
	| | | | | |
	| |Downlink NAS| | | |
	| |message | | | |
	| |<-----------| | | |
	+-----------------------+ | | | |
	|Small Data Delivery, | | | | |
	|RRC connection release | | | | |
	+-----------------------+ | | | |
	| |
	| |
	+------------------+
	Figure 6: DoNAS transmission sequence from an Uplink initiated access		In this scenario SCHC can be applied in the NAS protocol layer
			instead of PDCP. The same principles than for user plane
			transmissions applies here as well. The main difference is the
			physical placing of the SCHC entities in the network side as the
			C-SGN (placed in the core network) is the terminating node for NAS
			instead of the eNB.
	3.4. SCHC entities		+--------+ +--------+--------+ + +--------+
			| IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ |
			| Non-IP | | | | Non-IP | Non-IP | | | Non-IP |
			+--------+ | | +-----------------+ | +--------+
			| NAS +-----------------------+ NAS |GTP|C/U +-----+GTP|C/U |
			|(SCHC) | | | | (SCHC) | | | | |
			+--------+ | +-----------+ | +-----------------+ | +--------+
			| RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | |
			+--------+ | +-----------+ | +--------+ UDP +-----+ UDP |
			| PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | |
			+--------+ | +-----------+ | +-----------------+ | +--------+
			| RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP |
			+--------+ | +-----------+ | +-----------------+ | +--------+
			| MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 |
			+--------+ | +-----------+ | +-----------------+ | +--------+
			| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |
			+--------+ +-----+-----+ +--------+--------+ | +--------+
			C-Uu/ S1-lite SGi
			CIOT/ LTE-Uu C-BS/eNB C-SGN PGW
			LTE eMTC
			UE
	SCHC could be deployed differently depending of the placing of the		*PDCP is bypassed until AS security is activated [TGPP36300].
	entities in the architecture. NB-IoT and in general the cellular
	technologies interfaces are standardized by 3GPP. Therefore the
	introduction of SCHC entities in the RAN (Radio Access Network) would
	require support from both the network and terminal entities. If SCHC
	entities are to be placed in RAN it would require to be added to be
	specified as an option for the UE - Base Station/C-SGN interfaces.
	Another option is to place the SCHC entities in the applications
	layer, and the SCHC packets would be transmitted as non-IP packets.
	The first option allows the deployment of IP for routing and
	addressing as well.
	4. Static Context Header Compression		Figure 4
	TBD (Edgar)		5.3. Parameters for Static Context Header Compression (SCHC)
			5.3.1. SCHC Context initialization
	4.1. SCHC Rules		RRC (Radio Resource Control) protocol is the main tool used to
			configure the operation parameters of the AS transmissions for 3GPP
			technologies. RoHC operation is configured with this protocol and it
			is to expect that SCHC will be configured and the static context
			distributed in similar fashion for these scenarios.
	TBD (Ana) * Depending of SCHC deployment case * End-2-end * Global		5.3.2. SCHC Rules
	rules to fetch customized rules * Minimum rule set for applying
	functions * Fragmentation, compression, NATing
	o Size of rule id		The number of rules in a context are defined by the network operator
			in these scenarios. For this, the operator must be aware of the type
			of IP traffic that the device will carry out. This means that the
			operator might provision sets of rules compatible with the use case
			of the device. For devices acting as gateways of other devices
			several rules that match the diversity of devices and protocols used
			by the devices associated to the gateway. Meanwhile than simpler
			devices (for example an electricity meter) may have a predetermined
			set of protocols and parameters fixed. Additionally, the deployment
			of IPV4 addresses in addition to IPV6 may force to provision separate
			rules to deal with each of the cases.
	o 1 fragment rule And at least one Rule ID may be reserved to the		5.3.3. Rule ID
	case where no SCHC C/D nor SCHC fragmentation were possible.
	4.2. Packet processing		For these transmission scenarios in NB-IoT, a reasonable assumption
			of 9 bytes of radio protocol overhead can be expected. PDCP 5 bytes
			due to header and integrity protection, and 4 bytes of RLC and MAC.
			The minimum physical Transport Block (TB) that can withhold this
			overhead value according to 3GPP Release 15 specifications are: 88,
			104, 120 and 144 bits. If it is wished to optimize the number of
			transmissions of a very small application packet so that in some
			cases can be transmitted using only one physical layer transmission,
			then the SCHC overhead should not exceed the available number of bits
			of the smallest utile physical TB available. The packets handled by
			3GPP networks are byte-aligned, and therefore the minimum payload
			possible (including padding) is 8 bits. Therefore in order to
			utilize the smallest TB the maximum SCHC is 8 bits. This must
			include the Compression Residue in addition to the Rule ID. In the
			other hand, it is possible that more complex NB-IoT devices (such as
			a capillarity gateway) might require additional bits to handle the
			variety and multiple parameters the of higher layer protocols
			deployed. In that sense, the operator may want to have flexibility
			on the number and type of rules supported by each device
			independently, and consequently a configurable value is preferred for
			these scenarios. The configuration may be set as part of the
			operation profile agreed together with the context distribution. The
			Rule Id field size may range for example from 2 bits resulting in 4
			rules to a 8 bits value that would yield up to 256 rules which can be
			used together with the operators and seems quite a reasonable maximum
			limit even for a device acting as a NAT. More bits could be
			configured, but it should take in account the byte-alignment of the
			expected Compression Residue too. In the minimum TB size case, 2
			bits size of Rule Id leave only 6 bits available for Compression
			Residue.
	(Ana) *Operation over top vs 3gpp entities how to recognize a schc		5.3.4. SCHC MAX_PACKET_SIZE
	packet
	4.3. SCHC Context		The Access Stratum can handle the fragmentation of SCHC packets if
			needed including reliability. Hence the packet size is limited by
			the MTU possible to be handled by the AS radio protocols that
			corresponds to 1600 bytes for 3GPP Release 15.
	o NATing		5.3.5. Fragmentation
	o What protocols can be identified for compression depending of the		For these scenarios the SCHC fragmentation functions are recommend to
	deployument		be disabled. The RLC layer of NB-IoT can segment packets in suitable
			units that fit the selected transport blocks for transmissions of the
			physical layer. The selection of the blocks is done according to the
			input of the link adaptation function in the MAC layer and the
			quantity of data in the buffer. The link adaptation layer may
			produce different results at each Time Transmission Interval (TTI)
			resulting in varying physical transport blocks that depends of the
			network load, interference and number of bits to be transmitted and
			QoS. Even if setting a value that allows the construction of data
			units following SCHC tiles principle, the protocol overhead may be
			greater or equal than allowing the AS radio protocols to take care of
			the fragmentation natively.
	5. Fragmentation		5.3.5.1. Fragmentation in Transparent Mode
	The RLC layer of NB-IoT can segment packets in suitable units that		If RLC is configured to operate in Transparent Mode, there could be a
	fits the selected transport blocks for transmissions of the physical		case to activate a fragmentation function together with a light
	layer. The selection of the blocks is done according to the input of		reliability function such as the ACK-Always mode. In practice , it
	the link adaptation function in the MAC layer and the quantity of		is very rare to transmit user plane data using this configuration and
	data in the buffer. The link adaptation layer may produce different		it is mainly targeting control plane transmissions. In those cases
	results at each Time Transmission Interval (TTI) for what is very		the reliability is normally ensured by MAC based mechanisms, such as
	difficult to set a fragmentation value according to the transport		repetitions or automatic retransmissions, and additional reliability
	block that is selected for each transmission. Instead for NB-IoT		might only generate protocol overhead.
	SCHC must take care of keeping the application packets with a
	suitable size that do not exceed the MTU (1600 bytes).
	5.1. Fragmentation modes		In future operations, it could be devised the utilization of SCHC to
			reduce radio network protocols overhead and support the reliability
			of the transmissions, and targeting small data with the fewer
			possible transmissions. This could be realized by using fixed or
			limited set of transport blocks compatible with the tiling SCHC
			fragmentation handling.
	(Sothy) Look a the different options of reliability and see the		6. Non-IP based Data Transmission
	implications for NB-IoT for the different deployment modes
	5.2. Fragmentation Parameters		The Non-IP Data Delivery (NIDD) services of 3GPP enable the
			possibility of transmitting SCHC packets compressed by the
			application layer. The packets can be delivered by means of IP-
			tunnels to the 3GPP network or using SCEF functions (i.e., API
			calls). In both cases the packet IP is not understood by the 3GPP
			network since it is already compressed and the network does not has
			information of the context used for compression. Therefore the
			network will treat the packet as a Non-IP traffic and deliver it to
			the UE without any other stack element, directly under the L2.
	(Edgar) Headers sizes Example for the end2end case and check what is		6.1. SCHC Entities Placing
	operator defined * Rule ID
			In the two scenarios using NIDD, SCHC entities are located almost in
			top of the stack. In the terminal, it may be implemented by a
			application utilizing the NB-IoT connectivity services. In the
			network side, the SCHC entities are located in the Application Server
			(AS). The IP tunneling scenario requires that the Application Server
			sends the compressed packet over an IP connection that is terminated
			by the 3GPP core network. If instead the SCEF services are used,
			then it is possible to utilize a API call to transfer the SCHC
			packets between the core network and the AS, also an IP tunnel could
			be established by the AS, if negotiated with the SCEF.
			+---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+
			| SCHC | XXX XXX | SCHC |
			|(Non-IP) +-----XX........................XX....+--*---+(Non-IP)|
			+---------+ XX +----+ XX | | +--------+
			| | XX |SCEF+-------+ | | |
			| | XXX 3GPP RAN & +----+ XXX +---+ UDP |
			| | XXX CORE NETWORK XXX | | |
			| L2 +---+XX +------------+ | +--------+
			| | XX |IP TUNNELING+--+ | |
			| | XXX +------------+ +---+ IP |
			+---------+ XXXX XXXX | +--------+
			| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |
			+---------+ +--------+
			UE AS
			Figure 5: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP
			Sevices
			6.2. Parameters for Static Context Header Compression
			6.2.1. SCHC Context initialization
			The static context is handled in the application layer level,
			consequently the contexts are required to be distributed according to
			the applications own capabilities, perhaps utilizing IP data
			transmissions up to context initialization. Also the same IP
			tunneling or SCEF services used later for the SCHC packets transport
			may be used by the applications in both ends to deliver the static
			contexts to be used.
			6.2.2. SCHC Rules
			Even when the transmissions content are not visible for the 3GPP
			network, the same limitations than for IP based data transmissions
			applies in these scenarios in terms of aiming to use the minimum
			number of transmission and minimize the protocol overhead.
			6.2.3. Rule ID
			Similarly to the case of IP transmissions, the Rule ID size can be
			dynamically set prior the context delivery. For example negotiated
			between the applications when choosing a profile according to the
			type of traffic and type of application deployed. Same
			considerations related to the transport block size and performance
			mentioned for the IP type of traffic has to be follow when choosing a
			size value for the Rule ID field.
			6.2.4. SCHC MAX_PACKET_SIZE
			In these scenarios the maximum recommended MTU size that applies is
			1358 Bytes, since the SCHC packets (and fragments) are traversing the
			whole 3GPP network infrastructure (core and radio), and not only the
			radio as the IP transmissions case.
			6.3. Fragmentation
			In principle the fragmentation function should be activated for
			packets greater than 1358 Bytes. Since the 3GPP reliability
			functions take great deal care of it, for simple point to point
			connections may be enough a NO-ACK mode. Nevertheless additional
			considerations for more complex cases are mentioned in the next
			subsection to be taken in account.
			6.3.1. Fragmentation modes
			Depending of the QoS that has been assigned to the packets, it is
			possible that packets are lost before they arrive to 3GPP radio
			network transmission, for example in between the links of a
			capillarity gateway, or due to buffer overflow handling in a backhaul
			connection. In consequence, it is possible to secure additional
			reliability on the packets transmitted with a small trade-off on
			additional transmissions to signal the packets arrival indication
			end-to-end if no transport protocol takes care of retransmission. To
			achieve this, the packets fragmentation is activated with the ACK-on-
			Error mode enabled. In some cases, it is even desirable to keep
			track of all the SCHC packets delivered, in that case, the
			fragmentation function could be active for all packets transmitted by
			the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on-
			Error mode.
			6.3.2. Fragmentation Parameters(TBD)
			o Rule ID
	o DTag		o DTag
	o FCN		o FCN
			o W (number of bits)
			o WINDOW_SIZE
	o Retransmission Timer		o Retransmission Timer
	o Inactivity Timer		o Inactivity Timer
	o MAX_ACK_Retries		o MAX_ACK_Retries
	o MAX_ATTEMPS		o MAX_ATTEMPS
	o MIC (Ana)		o MIC (size and algorithm)
	TBD
	6. Padding		7. Padding
	NB-IoT and 3GPP wireless access in general assumes byte aligned		NB-IoT and 3GPP wireless access, in general, assumes byte aligned
	payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits		payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits
	and the treatment of padding should use this value accordingly.		and the treatment of padding should use this value accordingly.
	7. Security considerations		8. Security considerations
	3GPP access security is specified in [TGPP33203].		3GPP access security is specified in (TGPP33203).
	8. Appendix		9. 3GPP References
	## NB-IoT with data over NAS		o [TGPP23720] 3GPP, "TR 23.720 v13.0.0 - Study on architecture
	+---+ +---+ +----+ +--+		enhancements for Cellular Internet of Things", 2016.
	Applications |AP1| |AP1| | AP2| |AP2|
	(IP/non-IP) |PDU| |PDU| | PDU|~~~~~~~~~~~~~~~~~~~|PDU|
	+---+ +---+ +----+ +---+
	| |/ / / | |
	NAS /RRC +-------+---|-----+-----+ +--------+
	|NAS|AP1|AP1| AP2 |NAS/ | |NAS/|AP2|
	|RRC|PDU|PDU| PDU |RRC | |RRC |PDU|
	+---+---|---+-----+-----+ +--------|
	| | \ | | |
	|<----Max. 1600 bytes-->| |_ |_
	| | \ \ \ \
	| | --\ -\ \_ \_
	+-------------| +-----|----------+ \ \
	RLC |RLC |NAS/RRC| |RLC | NAS/RRC | +----|-------+
	|Head | PDU | |Head | PDU (2/2)| |RLC |NAS/RRC|
	| | (1/2) | |Head | PDU (2/2)| |RLC |NAS/RRC|
	+-------------+ +-----+----------+ |Head|PDU |
	| | | \ \ +------------+
	| | LCID1 | \ \ | |
	| | | \ \ | |
	| | | \ \ \ |
	| | | \ \ \ |
	+-------------------+ +----|-----------------+ +----+---------|-+
	MAC |MAC |RLC | RLC | |MAC |RLC | RLC | |MAC | RLC |P|
	|Head |Head |PAYLOAD| |Head|Head| PAYLOAD | |Head| PDU |a|
	| | | | | | | | | | |d|
	+-------------------+ +----------------------+ +----+---------+-+
	TB1 TB2 TB3
	Figure 7: Example of User Plane packet encapsulation for Data over		o [TGPP33203] 3GPP, "TS 33.203 v13.1.0 - 3G security; Access
	NAS		security for IP-based services", 2016.
	8.1. NB-IoT example with mobility		o [TGPP36321] 3GPP, "TS 36.321 v13.2.0 - Evolved Universal
			Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC)
			protocol specification", 2016
	## LTE-M considerations		o [TGPP36323] 3GPP, "TS 36.323 v13.2.0 - Evolved Universal
			Terrestrial Radio Access (E-UTRA); Packet Data Convergence
			Protocol (PDCP) specification", 2016.
	9. Informative References		o [TGPP36331] 3GPP, "TS 36.331 v13.2.0 - Evolved Universal
			Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC);
			Protocol specification", 2016.
	[I-D.ietf-lpwan-ipv6-static-context-hc]		o [TGPP36300] 3GPP, "TS 36.300 v15.1.0 - Evolved Universal
	Minaburo, A., Toutain, L., Gomez, C., and D. Barthel,		Terrestrial Radio Access (E-UTRA) and Evolved Universal
	"LPWAN Static Context Header Compression (SCHC) and		Terrestrial Radio Access Network (E-UTRAN); Overall description;
	fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6-		Stage 2", 2018
	static-context-hc-16 (work in progress), June 2018.
	[I-D.ietf-lpwan-overview]		o [TGPP24301] 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)
	Farrell, S., "LPWAN Overview", draft-ietf-lpwan-		protocol for Evolved Packet System (EPS); Stage 3", 2018
	overview-10 (work in progress), February 2018.
	[TGPP24301]		10. Appendix
	"TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) protocol for
	Evolved Packet System (EPS); Stage 3", n.d..
	[TGPP33203]		10.1. NB-IoT User Plane protocol architecture
	"TS 33.203 v13.1.0 - 3G security; Access security for IP-
	based services", n.d..
	[TGPP36300]		10.1.1. Packet Data Convergence Protocol (PDCP)
	"TS 36.300 v15.1.0 - Evolved Universal Terrestrial Radio
	Access (E-UTRA) and Evolved Universal Terrestrial Radio
	Access Network (E-UTRAN); Overall description; Stage 2",
	n.d..
	[TGPP36321]		Each of the Radio Bearers (RB) are associated with one PDCP entity.
	"TS 36.321 v13.2.0 - Evolved Universal Terrestrial Radio		And a PDCP entity is associated with one or two RLC entities
	Access (E-UTRA); Medium Access Control (MAC) protocol		depending of the unidirectional or bi-directional characteristics of
	specification", n.d..		the RB and RLC mode used. A PDCP entity is associated either control
			plane or user plane which independent configuration and functions.
			The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets.
			The main services and functions of the PDCP sublayer for NB-IoT for
			the user plane include:
	[TGPP36323]		o Header compression and decompression by means of ROHC (Robust
	"TS 36.323 v13.2.0 - Evolved Universal Terrestrial Radio		Header Compression)
	Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
	specification", n.d..
	[TGPP36331]		o Transfer of user and control data to higher and lower layers
	"TS 36.331 v13.2.0 - Evolved Universal Terrestrial Radio
	Access (E-UTRA); Radio Resource Control (RRC); Protocol		o Duplicate detection of lower layer SDUs when re-establishing
	specification", n.d..		connection (when RLC with Acknowledge Mode in use for User Plane
			only)
			o Ciphering and deciphering
			o Timer-based SDU discard in uplink
			10.1.2. Radio Link Protocol (RLC)
			RLC is a layer-2 protocol that operates between the UE and the base
			station (eNB). It supports the packet delivery from higher layers to
			MAC creating packets that are transmitted over the air optimizing the
			Transport Block utilization. RLC flow of data packets is
			unidirectional and it is composed of a transmitter located in the
			transmission device and a receiver located in the destination device.
			Therefore to configure bi-directional flows, two set of entities, one
			in each direction (downlink and uplink) must be configured and they
			are effectively peered to each other. The peering allows the
			transmission of control packets (ex., status reports) between
			entities. RLC can be configured for data transfer in one of the
			following modes:
			o Transparent Mode (TM). In this mode RLC do not segment or
			concatenate SDUs from higher layers and do not include any header
			to the payload. When acting as a transmitter, RLC receives SDUs
			from upper layers and transmit directly to its flow RLC receiver
			via lower layers. Similarly, an TM RLC receiver would only
			deliver without additional processing the packets to higher layers
			upon reception.
			o Unacknowledged Mode (UM). This mode provides support for
			segmentation and concatenation of payload. The size of the RLC
			packet depends of the indication given at a particular
			transmission opportunity by the lower layer (MAC) and are octets
			aligned. The packet delivery to the receiver do not include
			support for reliability and the lost of a segment from a packet
			means a whole packet loss. Also in case of lower layer
			retransmissions there is no support for re-segmentation in case of
			change of the radio conditions triggering the selection of a
			smaller transport block. Additionally it provides PDU duplication
			detection and discard, reordering of out of sequence and loss
			detection.
			o Acknowledged Mode (AM). Additional to the same functions
			supported from UM, this mode also adds a moving windows based
			reliability service on top of the lower layer services. It also
			provides support for re-segmentation and it requires bidirectional
			communication to exchange acknowledgment reports called RLC Status
			Report and trigger retransmissions is needed. Protocol error
			detection is also supported by this mode. The mode uses depends
			of the operator configuration for the type of data to be
			transmitted. For example, data transmissions supporting mobility
			or requiring high reliability would be most likely configured
			using AM, meanwhile streaming and real time data would be map to a
			UM configuration.
			10.1.3. Medium Access Control (MAC)
			MAC provides a mapping between the higher layers abstraction called
			Logical Channels comprised by the previously described protocols to
			the Physical layer channels (transport channels). Additionally, MAC
			may multiplex packets from different Logical Channels and prioritize
			what to fit into one Transport Block if there is data and space
			available to maximize the efficiency of data transmission. MAC also
			provides error correction and reliability support by means of HARQ,
			transport format selection and scheduling information reporting from
			the terminal to the network. MAC also adds the necessary padding and
			piggyback control elements when possible additional to the higher
			layers data.
			<Max. 1600 bytes>
			+---+ +---+ +------+
			Application |AP1| |AP1| | AP2 |
			(IP/non-IP) |PDU| |PDU| | PDU |
			+---+ +---+ +------+
			| | | | | |
			PDCP +--------+ +--------+ +-----------+
			|PDCP|AP1| |PDCP|AP1| |PDCP| AP2 |
			|Head|PDU| |Head|PDU| |Head| PDU |
			+--------+ +--------+ +--------+--\
			| | | | | | | | |\ `----\
			+---------------------------+ | |(1)| `-----\(2)'-\
			RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+
			|Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2|
			+-------------|-------------+ |Head|Head|PDU| |Head|PDU|
			| | | | | +---------|---+ +--------+
			| | | LCID1 | | / / / / /
			/ / / _/ _// _/ _/ / LCID2 /
			| | | | | / _/ _/ / ___/
			| | | | || | | / /
			+------------------------------------------+ +-----------+---+
			MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad|
			|Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din|
			|der|der|der | |der|der | |der|der | | |der|der| |g |
			+------------------------------------------+ +-----------+---+
			TB1 TB2
			Figure 6: Example of User Plane packet encapsulation for two
			transport blocks
			10.2. NB-IoT Data over NAS (DoNAS)
			The AS protocol stack used by DoNAS is somehow special. Since the
			security associations are not established yet in the radio network,
			to reduce the protocol overhead, PDCP (Packet Data Convergence
			Protocol) is bypassed until AS security is activated. RLC (Radio
			Link Control protocol) is configured by default in AM mode, but
			depending of the features supported by the network and the terminal
			it may be configured in other modes by the network operator. For
			example, the transparent mode does not add any header or does not
			process the payload in any way reducing the overhead, but the MTU
			would be limited by the transport block used to transmit the data
			which is couple of thousand of bits maximum. If UM (only Release 15
			compatible terminals) is used, the RLC mechanisms of reliability is
			disabled and only the reliability provided by the MAC layer by Hybrid
			Automatic Repeat reQuest (HARQ) is available. In this case, the
			protocol overhead might be smaller than for the AM case because the
			lack of status reporting but with the same support for segmentation
			up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio
			Resource Control)[TGPP36331] message.
			Depending of the data type indication signaled (IP or non-IP data),
			the network allocates an IP address or just establish a direct
			forwarding path. DoNAS is regulated under rate control upon previous
			agreement, meaning that a maximum number of bits per unit of time is
			agreed per device subscription beforehand and configured in the
			device. The use of DoNAS is typically expected when a terminal in a
			power saving state requires to do a short transmission and receive an
			acknowledgment or short feedback from the network. Depending of the
			size of buffered data to transmit, the UE might be instructed to
			deploy the connected mode transmissions instead, limiting and
			controlling the DoNAS transmissions to predefined thresholds and a
			good resource optimization balance for the terminal and the network.
			The support for mobility of DoNAS is present but produces additional
			overhead.
			+--------+ +--------+ +--------+
			| | | | | | +-----------------+
			| UE | | C-BS | | C-SGN | |Roaming Scenarios|
			+----|---+ +--------+ +--------+ | +--------+ |
			| | | | | | |
			+----------------|------------|+ | | P-GW | |
			| Attach | | +--------+ |
			+------------------------------+ | | |
			| | | | | |
			+------|------------|--------+ | | | |
			|RRC Connection Establishment| | | | |
			|with NAS PDU transmission | | | | |
			|& Ack Rsp | | | | |
			+----------------------------+ | | | |
			| | | | | |
			| |Initial UE | | | |
			| |message | | | |
			| |----------->| | | |
			| | | | | |
			| | +---------------------+| | |
			| | |Checks Integrity || | |
			| | |protection, decrypts || | |
			| | |data || | |
			| | +---------------------+| | |
			| | | Small data packet |
			| | |------------------------------->
			| | | Small data packet |
			| | |<-------------------------------
			| | +----------|---------+ | | |
			| | Integrity protection,| | | |
			| | encrypts data | | | |
			| | +--------------------+ | | |
			| | | | | |
			| |Downlink NAS| | | |
			| |message | | | |
			| |<-----------| | | |
			+-----------------------+ | | | |
			|Small Data Delivery, | | | | |
			|RRC connection release | | | | |
			+-----------------------+ | | | |
			| |
			| |
			+-----------------+
			Figure 7: DoNAS transmission sequence from an Uplink initiated access
			+---+ +---+ +---+ +----+
			Application |AP1| |AP1| |AP2| |AP2 |
			(IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU |
			+---+ +---+ +---+ +----+
			| |/ / | \ | |
			NAS /RRC +--------+---|---+----+ +---------+
			|NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 |
			|RRC |PDU|PDU|PDU|RRC | |RRC |PDU |
			+--------+-|-+---+----+ +---------|
			| |\ | | |
			|<--Max. 1600 bytes-->|__ |_ |
			| | \__ \___ \_ \_
			| | \ \ \__ \_
			+---------------|+-----|----------+ \ \
			RLC |RLC | NAS/RRC ||RLC | NAS/RRC | +----|-------+
			|Head| PDU(1/2)||Head | PDU (2/2)| |RLC |NAS/RRC|
			+---------------++----------------+ |Head|PDU |
			| | | \ | +------------+
			| | LCID1 | \ | | /
			| | | \ \ | |
			| | | \ \ | |
			| | | \ \ \ |
			+----+----+----------++-----|----+---------++----+---------|---+
			MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
			|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
			+----+----+----------++-----+----+---------++----+---------+---+
			TB1 TB2 TB3
			Figure 8: Example of User Plane packet encapsulation for Data over
			NAS
			11. Informative References
			[I-D.ietf-lpwan-ipv6-static-context-hc]
			Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
			Zuniga, "LPWAN Static Context Header Compression (SCHC)
			and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
			ipv6-static-context-hc-18 (work in progress), December
			2018.
			[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
			Header Compression (ROHC) Framework", RFC 5795,
			DOI 10.17487/RFC5795, March 2010,
			<https://www.rfc-editor.org/info/rfc5795>.
			[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>.
	Authors' Addresses		Authors' Addresses
	Ana Minaburo		Ana Minaburo
	Acklio		Acklio
	2bis rue de la Chataigneraie		2bis rue de la Chataigneraie
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ana@ackl.io		Email: ana@ackl.io
	skipping to change at page 17, line 4 ¶		skipping to change at page 23, line 18 ¶
	Authors' Addresses		Authors' Addresses
	Ana Minaburo		Ana Minaburo
	Acklio		Acklio
	2bis rue de la Chataigneraie		2bis rue de la Chataigneraie
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ana@ackl.io		Email: ana@ackl.io
	Edgar Ramos		Edgar Ramos
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	02420 Jorvas		02420 Jorvas, Kirkkonummi
	Finland		Finland
	Email: edgar.ramos@ericsson.com		Email: edgar.ramos@ericsson.com
	Sivasothy Shanmugalingam		Sivasothy Shanmugalingam
	Acklio		Acklio
	2bis rue de la Chataigneraie		2bis rue de la Chataigneraie
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
End of changes. 83 change blocks.
	441 lines changed or deleted		715 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/