< draft-ietf-lpwan-schc-over-nbiot-06.txt		draft-ietf-lpwan-schc-over-nbiot-07.txt >
	lpwan Working Group E. Ramos		lpwan Working Group E. Ramos
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational A. Minaburo		Intended status: Informational A. Minaburo
	Expires: April 25, 2022 Acklio		Expires: 26 August 2022 Acklio
	October 22, 2021		22 February 2022
	SCHC over NB-IoT		SCHC over NB-IoT
	draft-ietf-lpwan-schc-over-nbiot-06		draft-ietf-lpwan-schc-over-nbiot-07
	Abstract		Abstract
	The Static Context Header Compression (SCHC) specification describes		The Static Context Header Compression (SCHC) specification describes
	header compression and fragmentation functionalities for LPWAN (Low		header compression and fragmentation functionalities for LPWAN (Low
	Power Wide Area Networks) technologies.		Power Wide Area Networks) technologies. The Narrow Band Internet of
	The Narrow Band Internet of Things (NB-IoT) architecture may adapt		Things (NB-IoT) architecture may adapt SCHC to improve its
	SCHC to improve its capacities.		capacities.
	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 efficient parameterization.		access and provides elements for efficient parameterization.
	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 http://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 April 25, 2022.		This Internet-Draft will expire on 26 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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/
	(http://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 5		4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 5
	5. IP based Data Transmission . . . . . . . . . . . . . . . . . 6		5. IP based Data Transmission . . . . . . . . . . . . . . . . . 6
	5.1. SCHC over the Radio link . . . . . . . . . . . . . . . . 6		5.1. SCHC over the Radio link . . . . . . . . . . . . . . . . 6
	5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6		5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6
	5.2. SCHC over No-Access Stratum (NAS) . . . . . . . . . . . . 7		5.2. SCHC over No-Access Stratum (NAS) . . . . . . . . . . . . 7
	5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8		5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
	5.3. Parameters for Static Context Header Compression (SCHC) . 9		5.3. Parameters for Static Context Header Compression
			(SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3.1. SCHC Context initialization . . . . . . . . . . . . . 9		5.3.1. SCHC Context initialization . . . . . . . . . . . . . 9
	5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 9		5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 9
	5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 9		5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 9
	5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 10		5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 10
	5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 10		5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 10
	6. End-to-End Compression . . . . . . . . . . . . . . . . . . . 10		6. End-to-End Compression . . . . . . . . . . . . . . . . . . . 10
	6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 11		6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 11
	6.2. Parameters for Static Context Header Compression . . . . 11		6.2. Parameters for Static Context Header Compression . . . . 11
	6.2.1. SCHC Context initialization . . . . . . . . . . . . . 11		6.2.1. SCHC Context initialization . . . . . . . . . . . . . 11
	6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 12		6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 12
	6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 12		6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 12
	6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12		6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12
	6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12		6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
	6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 12		6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 12
	6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 13		6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 13
	7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Security considerations . . . . . . . . . . . . . . . . . . . 13		8. Security considerations . . . . . . . . . . . . . . . . . . . 13
	9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 14		9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 13
	10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. NB-IoT User Plane protocol architecture . . . . . . . . 14		10.1. NB-IoT User Plane protocol architecture . . . . . . . . 14
	10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 14		10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 14
	10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 15		10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 15
	10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 16		10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 16
	10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17		10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17
	11. Normative References . . . . . . . . . . . . . . . . . . . . 20		11. Normative References . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	The Static Context Header Compression (SCHC) [RFC8724] defines a		The Static Context Header Compression (SCHC) [RFC8724] defines a
	header compression scheme, and fragmentation functionality suitable		header compression scheme, and fragmentation functionality suitable
	for the Low Power Wide Area Networks (LPWAN) networks defined in		for the Low Power Wide Area Networks (LPWAN) networks defined in
	[RFC8376].		[RFC8376].
	In an NB-IoT network, header compression efficiently brings Internet		In an NB-IoT network, header compression efficiently brings Internet
	connectivity to the node. This document describes the SCHC		connectivity to the node. This document describes the SCHC
	parameters used to performs the static context header compression		parameters used to performs the static context header compression
	into the NB-IoT wireless access. This document assumes functionality		into the NB-IoT wireless access. This document assumes functionality
	for NB-IoT of 3GPP release 15. Otherwise, the text explicitly		for NB-IoT of 3GPP release 15. Otherwise, the text explicitly
	mentions other versions' functionality.		mentions other versions' functionality.
	2. Terminology		2. Terminology
	This document will follow the terms defined in [RFC8724], in		This document will follow the terms defined in [RFC8724], in
	[RFC8376], and the TGPP23720.		[RFC8376], and the TGPP23720.
	o CIoT. Cellular IoT		* CIoT. Cellular IoT
	o NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node		* NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node
	o Dev-UE. Device - User Equipment		* Dev-UE. Device - User Equipment
	o RGW-eNB. Radio Gateway - Node B. Base Station that controls the		* RGW-eNB. Radio Gateway - Node B. Base Station that controls the
	UE		UE
	o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE		* EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
	systems.		systems.
	o EUTRAN. Evolved Universal Terrestrial Radio Access Network.		* EUTRAN. Evolved Universal Terrestrial Radio Access Network.
	Radio network from LTE based systems.		Radio network from LTE based systems.
	o NGW-MME. Network Gateway - Mobility Management Entity. Handle		* NGW-MME. Network Gateway - Mobility Management Entity. Handle
	mobility of the UE		mobility of the UE
	o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology		* NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology
	based in LTE architecture but with additional optimization 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 NGW-SGW. Network Gateway - Serving Gateway. Routes and forwards		* NGW-SGW. Network Gateway - Serving Gateway. Routes and forwards
	the user data packets through the access network		the user data packets through the access network
	o HSS. Home Subscriber Server. It is a database that performs		* HSS. Home Subscriber Server. It is a database that performs
	mobility management		mobility management
	o NGW-PGW. Network Gateway - Packet Data Node Gateway. An		* NGW-PGW. Network Gateway - Packet Data Node Gateway. An
	interface between the internal with the external network		interface between the internal with the external network
	o PDU. Protocol Data Unit. Data packets including headers that are		* 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		* SDU. Service Data Unit. Data packets (PDUs) from higher layers
	protocols used by lower layer protocols as a 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.		* 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 NGW-SCEF. Network Gateway - Service Capability Exposure Function.		* NGW-SCEF. Network Gateway - Service Capability Exposure Function.
	EPC node for exposure of 3GPP network service capabilities to 3rd		EPC node for exposure of 3GPP network service capabilities to 3rd
	party applications.		party applications.
	3. Architecture		3. Architecture
	+---+ +------+		+---+ +------+
	|Dev| \ +-----+ ----| HSS |		|Dev| \ +-----+ ----| HSS |
	+---+ \ | NGW | +------+		+---+ \ | NGW | +------+
	| |-MME |\__		| |-MME |\__
	\ / +-----+ \		\ / +-----+ \
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 20 ¶
	(NGW-PGW) may get a limited bandwidth transmission from few bytes/s		(NGW-PGW) may get a limited bandwidth transmission from few bytes/s
	to one thousand bytes/s only.		to one thousand bytes/s only.
	Another node introduced in the NBIoT architecture is the Network		Another node introduced in the NBIoT architecture is the Network
	Gateway Service Capability Exposure Function (NGW-SCEF), which		Gateway Service Capability Exposure Function (NGW-SCEF), which
	securely exposes service and network capabilities to entities		securely exposes service and network capabilities to entities
	external to the network operator. OMA and OneM2M define the		external to the network operator. OMA and OneM2M define the
	northbound APIS [TGPP33203]. In this case, the path is small for		northbound APIS [TGPP33203]. In this case, the path is small for
	data transmission. The main functions of the NGW-SCEF are:		data transmission. The main functions of the NGW-SCEF are:
	o Connectivity path		* Connectivity path
	o Device Monitoring		* Device Monitoring
	4. Data Transmission		4. Data Transmission
	NB-IoT networks deal with end-to-end user data and in-band signaling		NB-IoT networks deal with end-to-end user data and in-band signaling
	between the nodes and functions to configure, control, and monitor		between the nodes and functions to configure, control, and monitor
	the system functions and behaviors. The signaling data uses a		the system functions and behaviors. The signaling data uses a
	different path with specific protocols, handling processes, and		different path with specific protocols, handling processes, and
	entities but can transport end-to-end user data for IoT services. In		entities but can transport end-to-end user data for IoT services. In
	contrast, the end-to-end application only transports end-to-end data.		contrast, the end-to-end application only transports end-to-end data.
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 29 ¶
	+---------+ | +---------------+ | +---------+ |		+---------+ | +---------------+ | +---------+ |
	| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+		| RLC +-------+ RLC |UDP/IP +------+ UDP/IP +->+
	+---------+ | +---------------+ | +---------+ |		+---------+ | +---------------+ | +---------+ |
	| MAC +-------+ MAC | L2 +------+ L2 +->+		| MAC +-------+ MAC | L2 +------+ L2 +->+
	+---------+ | +---------------+ | +---------+ |		+---------+ | +---------------+ | +---------+ |
	| PHY +-------+ PHY | PHY +------+ PHY +->+		| PHY +-------+ PHY | PHY +------+ PHY +->+
	+---------+ +---------------+ +---------+ |		+---------+ +---------------+ +---------+ |
	C-Uu/ S1-U SGi		C-Uu/ S1-U SGi
	Dev RGW-eNB NGW-CSGN		Dev RGW-eNB NGW-CSGN
	Figure 2: SCHC over the Radio link		Figure 2: SCHC over the Radio link
	5.2. SCHC over No-Access Stratum (NAS)		5.2. SCHC over No-Access Stratum (NAS)
	The NGW-MME conveys mainly control signaling between the Dev and the		The NGW-MME conveys mainly control signaling between the Dev and the
	cellular network [TGPP24301]. The network transports this traffic on		cellular network [TGPP24301]. The network transports this traffic on
	top of the radio link.		top of the radio link.
	This kind of flow supports data transmissions to reduce the overhead		This kind of flow supports data transmissions to reduce the overhead
	when transmitting infrequent small quantities of data. This		when transmitting infrequent small quantities of data. This
	transmission is known as Data over No-Access Stratum (DoNAS) or		transmission is known as Data over No-Access Stratum (DoNAS) or
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	+--------+ | +-----------+ | +-----------------+ | +--------+		+--------+ | +-----------+ | +-----------------+ | +--------+
	| MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 |		| MAC +-----+ MAC | L2 +-----+ L2 | L2 +-----+ L2 |
	+--------+ | +-----------+ | +-----------------+ | +--------+		+--------+ | +-----------+ | +-----------------+ | +--------+
	| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |		| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |
	+--------+ +-----+-----+ +--------+--------+ | +--------+		+--------+ +-----+-----+ +--------+--------+ | +--------+
	C-Uu/ S1-lite SGi		C-Uu/ S1-lite SGi
	Dev RGW-eNB NGW-MME NGW-PGW		Dev RGW-eNB NGW-MME NGW-PGW
	*PDCP is bypassed until AS security is activated TGPP36300.		*PDCP is bypassed until AS security is activated TGPP36300.
	Figure 3		Figure 3
	5.3. Parameters for Static Context Header Compression (SCHC)		5.3. Parameters for Static Context Header Compression (SCHC)
	5.3.1. SCHC Context initialization		5.3.1. SCHC Context initialization
	RRC (Radio Resource Control) protocol is the main tool used to		RRC (Radio Resource Control) protocol is the main tool used to
	configure the parameters of the Radio link. It will configure SCHC		configure the parameters of the Radio link. It will configure SCHC
	and the static context distribution as it has made for RoHC operation		and the static context distribution as it has made for RoHC operation
	[TGPP36323].		[TGPP36323].
	5.3.2. SCHC Rules		5.3.2. SCHC Rules
	The network operator in these scenarios defines the number of rules		The network operator in these scenarios defines the number of rules
	skipping to change at page 11, line 38 ¶		skipping to change at page 11, line 36 ¶
	| | XXX 3GPP RAN & +----+ XXX +---+ UDP |		| | XXX 3GPP RAN & +----+ XXX +---+ UDP |
	| | XXX CORE NETWORK XXX | | |		| | XXX CORE NETWORK XXX | | |
	| L2 +---+XX +------------+ | +--------+		| L2 +---+XX +------------+ | +--------+
	| | XX |IP TUNNELING+--+ | |		| | XX |IP TUNNELING+--+ | |
	| | XXX +------------+ +---+ IP |		| | XXX +------------+ +---+ IP |
	+---------+ XXXX XXXX | +--------+		+---------+ XXXX XXXX | +--------+
	| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |		| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |
	+---------+ +--------+		+---------+ +--------+
	UE AS		UE AS
	Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP		Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD)
	Sevices		3GPP Sevices
	6.2. Parameters for Static Context Header Compression		6.2. Parameters for Static Context Header Compression
	6.2.1. SCHC Context initialization		6.2.1. SCHC Context initialization
	The application layer handles the static context; consequently, the		The application layer handles the static context; consequently, the
	context distribution must be according to the application's		context distribution must be according to the application's
	capabilities, perhaps utilizing IP data transmissions up to context		capabilities, perhaps utilizing IP data transmissions up to context
	initialization. Also, the static contexts delivery may use the same		initialization. Also, the static contexts delivery may use the same
	IP tunneling or NGW-SCEF services used later for the SCHC packets		IP tunneling or NGW-SCEF services used later for the SCHC packets
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 47 ¶
	6.3.1. Fragmentation modes		6.3.1. Fragmentation modes
	A global service assigns a QoS to the packets depending on the		A global service assigns a QoS to the packets depending on the
	billing. Packets with very low QoS may get lost before they arrive		billing. Packets with very low QoS may get lost before they arrive
	in the 3GPP radio network transmission, for example, in between the		in the 3GPP radio network transmission, for example, in between the
	links of a capillarity gateway or due to buffer overflow handling in		links of a capillarity gateway or due to buffer overflow handling in
	a backhaul connection. The use of SCHC fragmentation with the ACK-		a backhaul connection. The use of SCHC fragmentation with the ACK-
	on-Error mode is recommended to secure additional reliability on the		on-Error mode is recommended to secure additional reliability on the
	packets transmitted with a small trade-off on additional		packets transmitted with a small trade-off on additional
	transmissions to signal the end-to-end arrival of the packets if no		transmissions to signal the end-to-end arrival of the packets if no
	transport protocol takes care of retransmission.		transport protocol takes care of retransmission. Also, the ACK-on-
	Also, the ACK-on-Error mode is even desirable to keep track of all		Error mode is even desirable to keep track of all the SCHC packets
	the SCHC packets delivered. In that case, the fragmentation function		delivered. In that case, the fragmentation function could be active
	could be active for all packets transmitted by the applications.		for all packets transmitted by the applications. SCHC ACK-on-Error
	SCHC ACK-on-Error fragmentation may be active for the transmission of		fragmentation may be active for the transmission of non-IP packets on
	non-IP packets on the NGW-MME. If these packets are considering to		the NGW-MME. If these packets are considering to use SCHC with the
	use SCHC with the RuleID for non-compressing packets as {RFC8724}		RuleID for non-compressing packets as {RFC8724} allows it.
	allows it.
	6.3.2. Fragmentation Parameters		6.3.2. Fragmentation Parameters
	SCHC profile with the fragmentation mode will have specific Rules.		SCHC profile with the fragmentation mode will have specific Rules.
	SCHC defines the Rule ID according to the fragmentation mode; 2 bits		The Rule ID will identify the fragmentation mode used, and it is
	could recognize all the fragmentation modes or another solution		defined in section Section 5.3.3.
	depending on the Rules implementation.
	SCHC parametrization considers that NBIoT aligns the bit and uses		SCHC parametrization considers that NBIoT aligns the bit and uses
	padding and the size of the Transfer Block. SCHC will try to reduce		padding and the size of the Transfer Block. SCHC will try to reduce
	padding to optimize the compression of the information. The Header		padding to optimize the compression of the information. The Header
	size needs to be multiple of 4, and the Tiles may keep a fixed value		size needs to be multiple of 4, and the Tiles may keep a fixed value
	of 4 or 8 bits to avoid padding except for transfer block equals 16		of 4 or 8 bits to avoid padding except for transfer block equals 16
	bits where Tiles may be of 2 bits. For the other parameters, the		bits where Tiles may be of 2 bits. For the other parameters, the
	transfer block size has a wide range that needs two configurations.		transfer block size has a wide range that needs two configurations.
	o For Transfer Blocks smaller than 300bits: 8 bits-Header_size		* For Transfer Blocks smaller than 300bits: 8 bits-Header_size
	configuration, with the size of the header fields as follows: Rule		configuration, with the size of the header fields as follows: Rule
	ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits.		ID from 1 - 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits.
	o For Transfer Blocks bigger than 300 bits: 16 bits-Header_size		* For Transfer Blocks bigger than 300 bits: 16 bits-Header_size
	configuration, with the size of the header fields as follows:		configuration, with the size of the header fields as follows:
	Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2 or 3 bits.		Rules ID from 1 to 8 or 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2
			or 3 bits.
	The IoT devices communicate with small data transfer and have a		The IoT devices communicate with small data transfer and have a
	battery life of 10 years. These devices use the Power Save Mode and		battery life of 10 years. These devices use the Power Save Mode and
	the Idle Mode DRX, which govern how often the device wakes up, stays		the Idle Mode DRX, which govern how often the device wakes up, stays
	up, and is reachable. Table 10.5.163a in {3GPP-TS_24.088} specifies		up, and is reachable. Table 10.5.163a in {3GPP-TS_24.088} specifies
	a range for the radio timers as N to 3N in increments of one where		a range for the radio timers as N to 3N in increments of one where
	the units of N can be 1 hour or 10 hours. To adapt SCHC to the NB-		the units of N can be 1 hour or 10 hours. To adapt SCHC to the NB-
	IoT activities, the Inactivity Timer and the Retransmission Timer may		IoT activities, the Inactivity Timer and the Retransmission Timer may
	use these limits.		use these limits.
	7. 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 padding treatment should use this value accordingly.		and the padding treatment should use this value accordingly.
	8. Security considerations		8. Security considerations
	3GPP access security is specified in [TGPP33203].		This document does not add any security considerations and follows
			the 3GPP access security document specified in [TGPP33203].
	9. 3GPP References		9. 3GPP References
			* TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture
	o TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture
	enhancements for Cellular Internet of Things", 2016.		enhancements for Cellular Internet of Things", 2016.
	o TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security		* TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
	for IP-based services", 2016.		for IP-based services", 2016.
	o TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial		* TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial
	Radio Access (E-UTRA); Medium Access Control (MAC) protocol		Radio Access (E-UTRA); Medium Access Control (MAC) protocol
	specification", 2016		specification", 2016
	o TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial		* TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial
	Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP)		Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
	specification", 2016.		specification", 2016.
	o TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial		* TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial
	Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol		Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol
	specification", 2016.		specification", 2016.
	o TGPP36300 3GPP, "TS 36.300 v15.1.0 - Evolved Universal Terrestrial		* TGPP36300 3GPP, "TS 36.300 v15.1.0 - Evolved Universal Terrestrial
	Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio		Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio
	Access Network (E-UTRAN); Overall description; Stage 2", 2018		Access Network (E-UTRAN); Overall description; Stage 2", 2018
	o TGPP24301 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)		* TGPP24301 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)
	protocol for Evolved Packet System (EPS); Stage 3", 2018		protocol for Evolved Packet System (EPS); Stage 3", 2018
	o TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer		* TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer
	3 specification;Core network protocols; Stage 3", 2015.		3 specification;Core network protocols; Stage 3", 2015.
	10. Appendix		10. Appendix
	10.1. NB-IoT User Plane protocol architecture		10.1. NB-IoT User Plane protocol architecture
	10.1.1. Packet Data Convergence Protocol (PDCP)		10.1.1. Packet Data Convergence Protocol (PDCP)
	Each of the Radio Bearers (RB) is associated with one PDCP entity.		Each of the Radio Bearers (RB) is associated with one PDCP entity.
	Moreover, a PDCP entity is associated with one or two RLC entities		Moreover, a PDCP entity is associated with one or two RLC entities
	depending on the unidirectional or bi-directional characteristics of		depending on the unidirectional or bi-directional characteristics of
	the RB and RLC mode used. A PDCP entity is associated with either a		the RB and RLC mode used. A PDCP entity is associated with either a
	control plane or a user plane with independent configuration and		control plane or a user plane with independent configuration and
	functions. The maximum supported size for NB-IoT of a PDCP SDU is		functions. The maximum supported size for NB-IoT of a PDCP SDU is
	1600 octets. The primary services and functions of the PDCP sublayer		1600 octets. The primary services and functions of the PDCP sublayer
	for NB-IoT for the user plane include:		for NB-IoT for the user plane include:
	o Header compression and decompression using ROHC (Robust Header		* Header compression and decompression using ROHC (Robust Header
	Compression)		Compression)
	o Transfer of user and control data to higher and lower layers		* Transfer of user and control data to higher and lower layers
			* Duplicate detection of lower layer SDUs when re-establishing
	o Duplicate detection of lower layer SDUs when re-establishing
	connection (when RLC with Acknowledge Mode in use for User Plane		connection (when RLC with Acknowledge Mode in use for User Plane
	only)		only)
	o Ciphering and deciphering		* Ciphering and deciphering
	o Timer-based SDU discard in uplink		* Timer-based SDU discard in uplink
	10.1.2. Radio Link Protocol (RLC)		10.1.2. Radio Link Protocol (RLC)
	RLC is a layer-2 protocol that operates between the UE and the base		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		station (eNB). It supports the packet delivery from higher layers to
	MAC, creating packets transmitted over the air, optimizing the		MAC, creating packets transmitted over the air, optimizing the
	Transport Block utilization. RLC flow of data packets is		Transport Block utilization. RLC flow of data packets is
	unidirectional, and it is composed of a transmitter located in the		unidirectional, and it is composed of a transmitter located in the
	transmission device and a receiver located in the destination device.		transmission device and a receiver located in the destination device.
	Therefore to configure bi-directional flows, two sets of entities,		Therefore to configure bi-directional flows, two sets of entities,
	one in each direction (downlink and uplink), must be configured and		one in each direction (downlink and uplink), must be configured and
	effectively peered to each other. The peering allows the		effectively peered to each other. The peering allows the
	transmission of control packets (ex., status reports) between		transmission of control packets (ex., status reports) between
	entities. RLC can be configured for data transfer in one of the		entities. RLC can be configured for data transfer in one of the
	following modes:		following modes:
	o Transparent Mode (TM). RLC does not segment or concatenate SDUs		* Transparent Mode (TM). RLC does not segment or concatenate SDUs
	from higher layers in this mode and does not include any header to		from higher layers in this mode and does not include any header to
	the payload. RLC receives SDUs from upper layers when acting as a		the payload. RLC receives SDUs from upper layers when acting as a
	transmitter and transmits directly to its flow RLC receiver via		transmitter and transmits directly to its flow RLC receiver via
	lower layers. Similarly, a TM RLC receiver would only deliver		lower layers. Similarly, a TM RLC receiver would only deliver
	without processing the packets to higher layers upon reception.		without processing the packets to higher layers upon reception.
	o Unacknowledged Mode (UM). This mode provides support for		* Unacknowledged Mode (UM). This mode provides support for
	segmentation and concatenation of payload. The RLC packet's size		segmentation and concatenation of payload. The RLC packet's size
	depends on the indication given at a particular transmission		depends on the indication given at a particular transmission
	opportunity by the lower layer (MAC) and is octets aligned. The		opportunity by the lower layer (MAC) and is octets aligned. The
	packet delivery to the receiver does not include reliability		packet delivery to the receiver does not include reliability
	support, and the loss of a segment from a packet means a complete		support, and the loss of a segment from a packet means a complete
	packet loss. Also, in the case of lower layer retransmissions,		packet loss. Also, in the case of lower layer retransmissions,
	there is no support for re-segmentation in case of change of the		there is no support for re-segmentation in case of change of the
	radio conditions triggering the selection of a smaller transport		radio conditions triggering the selection of a smaller transport
	block. Additionally, it provides PDU duplication detection and		block. Additionally, it provides PDU duplication detection and
	discards, reordering of out-of-sequence, and loss detection.		discards, reordering of out-of-sequence, and loss detection.
	o Acknowledged Mode (AM). In addition to the same functions		* Acknowledged Mode (AM). In addition to the same functions
	supported by UM, this mode also adds a moving windows-based		supported by UM, this mode also adds a moving windows-based
	reliability service on top of the lower layer services. It also		reliability service on top of the lower layer services. It also
	supports re-segmentation, and it requires bidirectional		supports re-segmentation, and it requires bidirectional
	communication to exchange acknowledgment reports called RLC Status		communication to exchange acknowledgment reports called RLC Status
	Report and trigger retransmissions. This model also supports		Report and trigger retransmissions. This model also supports
	protocol error detection. The mode used depends on the operator		protocol error detection. The mode used depends on the operator
	configuration for the type of data to be transmitted. For		configuration for the type of data to be transmitted. For
	example, data transmissions supporting mobility or requiring high		example, data transmissions supporting mobility or requiring high
	reliability would be most likely configured using AM. Meanwhile,		reliability would be most likely configured using AM. Meanwhile,
	streaming and real-time data would be mapped to a UM		streaming and real-time data would be mapped to a UM
	skipping to change at page 17, line 32 ¶		skipping to change at page 17, line 5 ¶
	/ / / _/ _// _/ _/ / LCID2 /		/ / / _/ _// _/ _/ / LCID2 /
	| | | | | / _/ _/ / ___/		| | | | | / _/ _/ / ___/
	| | | | || | | / /		| | | | || | | / /
	+------------------------------------------+ +-----------+---+		+------------------------------------------+ +-----------+---+
	MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad|		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|		|Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din|
	|der|der|der | |der|der | |der|der | | |der|der| |g |		|der|der|der | |der|der | |der|der | | |der|der| |g |
	+------------------------------------------+ +-----------+---+		+------------------------------------------+ +-----------+---+
	TB1 TB2		TB1 TB2
	Figure 5: Example of User Plane packet encapsulation for two		Figure 5: Example of User Plane packet encapsulation for two
	transport blocks		transport blocks
	10.2. NB-IoT Data over NAS (DoNAS)		10.2. NB-IoT Data over NAS (DoNAS)
	The Access Stratum (AS) protocol stack used by DoNAS is somehow		The Access Stratum (AS) protocol stack used by DoNAS is somehow
	particular. Since the security associations are not established yet		particular. Since the security associations are not established yet
	in the radio network, to reduce the protocol overhead, PDCP (Packet		in the radio network, to reduce the protocol overhead, PDCP (Packet
	Data Convergence Protocol) is bypassed until AS security is		Data Convergence Protocol) is bypassed until AS security is
	activated. RLC (Radio Link Control protocol) uses by default the AM		activated. RLC (Radio Link Control protocol) uses by default the AM
	mode, but depending on the network's features and the terminal, it		mode, but depending on the network's features and the terminal, it
	may change to other modes by the network operator. For example, the		may change to other modes by the network operator. For example, the
	skipping to change at page 20, line 32 ¶		skipping to change at page 19, line 32 ¶
	| | LCID1 | \ | | /		| | LCID1 | \ | | /
	| | | \ \ | |		| | | \ \ | |
	| | | \ \ | |		| | | \ \ | |
	| | | \ \ \ |		| | | \ \ \ |
	+----+----+----------++-----|----+---------++----+---------|---+		+----+----+----------++-----|----+---------++----+---------|---+
	MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|		MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
	|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |		|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
	+----+----+----------++-----+----+---------++----+---------+---+		+----+----+----------++-----+----+---------++----+---------+---+
	TB1 TB2 TB3		TB1 TB2 TB3
	Figure 7: Example of User Plane packet encapsulation for Data over		Figure 7: Example of User Plane packet encapsulation for Data
	NAS		over NAS
	11. Normative References		11. Normative References
	[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, <https://www.rfc-		DOI 10.17487/RFC5795, March 2010,
	editor.org/info/rfc5795>.		<https://www.rfc-editor.org/info/rfc5795>.
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020, <https://www.rfc-		DOI 10.17487/RFC8724, April 2020,
	editor.org/info/rfc8724>.		<https://www.rfc-editor.org/info/rfc8724>.
	Authors' Addresses		Authors' Addresses
	Edgar Ramos		Edgar Ramos
	Ericsson		Ericsson
	Hirsalantie 11		Hirsalantie 11
	02420 Jorvas, Kirkkonummi		02420 Jorvas, Kirkkonummi
	Finland		Finland
	Email: edgar.ramos@ericsson.com		Email: edgar.ramos@ericsson.com
	Ana Minaburo		Ana Minaburo
	Acklio		Acklio
	1137A Avenue des Champs Blancs		1137A Avenue des Champs Blancs
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ana@ackl.io		Email: ana@ackl.io
End of changes. 59 change blocks.
	87 lines changed or deleted		82 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/