< draft-ietf-lpwan-schc-over-nbiot-03.txt   draft-ietf-lpwan-schc-over-nbiot-04.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: 14 January 2021 Acklio Expires: July 23, 2021 Acklio
13 July 2020 January 19, 2021
SCHC over NB-IoT SCHC over NB-IoT
draft-ietf-lpwan-schc-over-nbiot-03 draft-ietf-lpwan-schc-over-nbiot-04
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at http://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 14 January 2021. This Internet-Draft will expire on July 23, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6 4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6
5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7 5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7
5.1. SCHC over User Plane transmissions . . . . . . . . . . . 8 5.1. SCHC over User Plane transmissions . . . . . . . . . . . 7
5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 9 5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 8
5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 10 5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 9
5.3. Parameters for Static Context Header Compression 5.3. Parameters for Static Context Header Compression (SCHC) . 10
(SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. SCHC Context initialization . . . . . . . . . . . . . 10
5.3.1. SCHC Context initialization . . . . . . . . . . . . . 11 5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 11
5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12 5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 11
5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12 5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 11
6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 13 6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 12
6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 13 6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 12
6.2. Parameters for Static Context Header Compression . . . . 13 6.2. Parameters for Static Context Header Compression . . . . 13
6.2.1. SCHC Context initialization . . . . . . . . . . . . . 14 6.2.1. SCHC Context initialization . . . . . . . . . . . . . 13
6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 14 6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14 6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 15 6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 14
6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 15 6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 15
7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security considerations . . . . . . . . . . . . . . . . . . . 16 8. Security considerations . . . . . . . . . . . . . . . . . . . 15
9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 16 9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 15
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. NB-IoT User Plane protocol architecture . . . . . . . . 17 10.1. NB-IoT User Plane protocol architecture . . . . . . . . 16
10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 17 10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 16
10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17 10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17
10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18 10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18
10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19 10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 22 11. Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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, both header compression scheme and fragmentation functionality, both
specially tailored for Low Power Wide Area Networks (LPWAN) networks specially tailored for Low Power Wide Area Networks (LPWAN) networks
defined in [RFC8376]. defined in [RFC8376].
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 a connectivity to the node within an NB-IoT network. SCHC uses a
skipping to change at page 3, line 26 skipping to change at page 3, line 21
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 [RFC8724], in This document will follow the terms defined in [RFC8724], in
[RFC8376], and the [TGPP23720]. [RFC8376], and the TGPP23720.
* CIoT. Cellular IoT o CIoT. Cellular IoT
* C-SGN. CIoT Serving Gateway Node o C-SGN. CIoT Serving Gateway Node
* UE. User Equipment o UE. User Equipment
* eNB. Node B. Base Station that controls the UE o eNB. Node B. Base Station that controls the UE
* EPC. Evolved Packet Connectivity. Core network of 3GPP LTE o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
systems. systems.
* 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.
* MME. Mobility Management Entity. Handle mobility of the UE o MME. Mobility Management Entity. Handle mobility of the UE
* 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 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.
* 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
* 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
* PGW. Packet Data Node Gateway. An interface between the internal o PGW. Packet Data Node Gateway. An interface between the internal
with the external network with the external network
* 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.
* 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 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.
* 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
* 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
&nbsp; +--+ +--+
|UE| \ +-----+ +------+ D |UE| \ +-----+ +------+
+--+ \ | MME |-----| HSS | +--+ \ | MME |-----| HSS |
\ / +-----+ +------+ E \ / +-----+ +------+
+--+ \+-----+ / | +--+ \+-----+ / |
|UE| ----| eNB |- | V |UE| ----| RGW |- |
+--+ /+-----+ \ | +--+ |(eNB)| |
I /+-----+ \ |
/ \ +------+ / \ +------+
/ \| | +------+ Service PDN C / \| NGW | +------+ Service PDN
+--+ / | S-GW |--| P-GW |-- e.g. Internet +--+ / |(S-GW)|--| NGW |-- e.g. Internet
|UE| | | +------+ E |UE| | | |(P-GW)|
+--+ +------+ +--+ +------+ +------+
S
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: CIoT EPS Optimizations:
* Control Plane CIoT EPS Optimization for small data transmission. o Control Plane CIoT EPS Optimization for small data transmission.
* User Plane CIoT EPS Optimization for small data transmission. o User Plane CIoT EPS Optimization for small data transmission.
* Necessary security procedures for efficient small data o Necessary security procedures for efficient small data
transmission. transmission.
* SMS without combined attach for NB-IoT only UEs. o SMS without combined attach for NB-IoT only UEs.
* Paging optimizations for coverage enhancements. o Paging optimizations for coverage enhancements.
* Support for non-IP data transmission via SGi tunneling and/or o Support for non-IP data transmission via SGi tunneling and/or
SCEF. SCEF.
* Support for Attach without PDN (Packet Data Network) connectivity. 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: main functions of a SCEF are:
* Non-IP Data Delivery (NIDD) established through the SCEF. o Non-IP Data Delivery (NIDD) established through the SCEF.
* Monitoring and exposure of event related to UE reachability, loss o Monitoring and exposure of event related to UE reachability, loss
of connectivity, location reporting, roaming status, communication of connectivity, location reporting, roaming status, communication
failure and change of IMEI-IMSI association. failure and change of IMEI-IMSI association.
+-------+ +-------+
| HSS | | HSS |
+-+-----+ +-+-----+
/ NGW /
+---------+ __/S6a DEV RGW +---------+ __/S6a
+--------+ | +-----+ +_/ +--------+ | +-----+ +_/ NGW
+----+ C-Uu | +---+-+ MME | | 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| | |C-SGN| |
| |S11| | |S11|
+------+ | | | +------+ | | |
+--------+LTE-Uu| | | +--+-+ | +--------+LTE-Uu| | | +--+-+ |
|LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+ |LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+
| UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application| | UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application|
+--------+ +------+ | +----+ | | +----+Server (AS)| +--------+ +------+ | +----+ | | +----+Server (AS)|
+---------+ +---+ +-----------+ +---------+ +---+ +-----------+
DEV RGW NGW NGW App
Figure 2: 3GPP optimized CIOT network architecture Figure 2: 3GPP optimized CIOT network architecture
4. Data Transmission 4. Data Transmission
3GPP networks deal not only with data transmitted end-to-end but also 3GPP networks deal not only with data transmitted end-to-end but also
with in-band signaling that is used between the nodes and functions with in-band signaling that is used between the nodes and functions
to configure, control and monitor the system functions and behaviors. to configure, control and monitor the system functions and behaviors.
The control data is handled using a Control Plane which has a The control data is handled using a Control Plane which has a
specific set of protocols, handling processes and entities. In specific set of protocols, handling processes and entities. 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
skipping to change at page 8, line 4 skipping to change at page 7, line 28
used in the NB-IoT architecture. IP header compression on the data used in the NB-IoT architecture. IP header compression on the data
transmission over User Plane, IP header compression on the optimized transmission over User Plane, IP header compression on the optimized
transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions
of SCHC packets by IP tunneling, and non-IP transmissions of SCHC of SCHC packets by IP tunneling, and non-IP transmissions of SCHC
packets by SCEF forwarding. The following sections describe each of packets by SCEF forwarding. The following sections describe each of
them in more detail. The first two scenarios refer to transmissions them in more detail. The first two scenarios refer to transmissions
using the 3GPP IP transmission capabilities and the last two refers using the 3GPP IP transmission capabilities and the last two refers
to transmission using the Non-IP capabilities. to transmission using the Non-IP capabilities.
5. IP based Data Transmission 5. IP based Data Transmission
5.1. SCHC over User Plane transmissions 5.1. SCHC over User Plane transmissions
Deploying SCHC only over the radio link would require to place it as Deploying SCHC only over the radio link would require to place it as
part of the User Plane data transmission. The User Plane utilizes part of the User Plane data transmission. The User Plane utilizes
the protocol stack of the Access Stratum (AS) for data transfer. AS the protocol stack of the Access Stratum (AS) for data transfer. AS
(Access Stratum) is the functional layer responsible for transporting (Access Stratum) is the functional layer responsible for transporting
data over wireless connection and managing radio resources. The user data over wireless connection and managing radio resources. The user
plane AS has support for features such as reliability, segmentation plane AS has support for features such as reliability, segmentation
and concatenation. The transmissions of the AS make use of link and concatenation. The transmissions of the AS make use of link
adaptation, meaning that the transport format utilized for the adaptation, meaning that the transport format utilized for the
transmissions are optimized according to the radio conditions, the transmissions are optimized according to the radio conditions, the
number of bits to transmit and the power and interference constrains. number of bits to transmit and the power and interference constrains.
That means that the number of bits transmitted over the air depends That means that the number of bits transmitted over the air depends
of the Modulation and Coding Schemes (MCS) selected. The of the Modulation and Coding Schemes (MCS) selected. The
transmissions in the physical layer happens at network synchronized transmissions in the physical layer happens at network synchronized
intervals of times called TTI (Transmission Time Interval). The intervals of times called TTI (Transmission Time Interval). The
transmission of a Transport Block (TB) is completed during, at least, transmission of a Transport Block (TB) is completed during, at least,
one TTI. Each Transport Block has a different MCS and number of bits one TTI. Each Transport Block has a different MCS and number of bits
available to transmit. The Transport Blocks characteristics are available to transmit. The Transport Blocks characteristics are
defined by the MAC technical specification [TGPP36321]. The Access defined by the MAC technical specification TGPP36321. The Access
Stratum for User Plane is comprised by Packet Data Convergence Stratum for User Plane is comprised by Packet Data Convergence
Protocol (PDCP) [TGPP36323], Radio Link Protocol (RLC)[TGPP36322], Protocol (PDCP) TGPP36323, Radio Link Protocol (RLC) TGPP36322,
Medium Access Control protocol (MAC)[TGPP36321] and the Physical Medium Access Control protocol (MAC) TGPP36321 and the Physical Layer
Layer [TGPP36201]. More details of this protocols are given in the TGPP36201. More details of this protocols are given in the Appendix.
Appendix.
5.1.1. SCHC Entities Placing 5.1.1. SCHC Entities Placing
The current architecture provides support for header compression in The current architecture provides support for header compression in
PDCP utilizing RoHC [RFC5795]. Therefore SCHC entities can be PDCP utilizing RoHC [RFC5795]. Therefore SCHC entities can be
deployed in similar fashion without need for major changes in the deployed in similar fashion without need for major changes in the
3GPP specifications. 3GPP specifications.
In this scenario, RLC takes care of the handling of fragmentation (if In this scenario, RLC takes care of the handling of fragmentation (if
transparent mode is not configured) when packets exceeds the transparent mode is not configured) when packets exceeds the
skipping to change at page 9, line 28 skipping to change at page 8, line 45
CIOT/ LTE+Uu C-BS/eNB C-SGN CIOT/ LTE+Uu C-BS/eNB C-SGN
LTE eMTC LTE eMTC
UE UE
Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol
architecture for data over user plane architecture for data over user plane
5.2. 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 mentioned in transported on top of the Access Stratum (AS) already mentioned in
the previous section. the previous section.
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. receive downlink small data response.
skipping to change at page 10, line 40 skipping to change at page 10, line 27
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| 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
CIOT/ LTE-Uu C-BS/eNB C-SGN PGW CIOT/ LTE-Uu C-BS/eNB C-SGN PGW
LTE eMTC LTE eMTC
UE UE
*PDCP is bypassed until AS security is activated [TGPP36300]. *PDCP is bypassed until AS security is activated TGPP36300.
Figure 4 Figure 4
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 operation parameters of the AS transmissions for 3GPP configure the operation parameters of the AS transmissions for 3GPP
technologies. RoHC operation is configured with this protocol and it technologies. RoHC operation is configured with this protocol and it
is to expect that SCHC will be configured and the static context is to expect that SCHC will be configured and the static context
distributed in similar fashion for these scenarios. distributed in similar fashion for these scenarios.
5.3.2. SCHC Rules 5.3.2. SCHC Rules
skipping to change at page 13, line 45 skipping to change at page 13, line 25
| | 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 5: SCHC entities placed when using Non-IP Delivery (NIDD) Figure 5: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP
3GPP Sevices 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 static context is handled in the application layer level, The static context is handled in the application layer level,
consequently the contexts are required to be distributed according to consequently the contexts are required to be distributed according to
the applications own capabilities, perhaps utilizing IP data the applications own capabilities, perhaps utilizing IP data
transmissions up to context initialization. Also the same IP transmissions up to context initialization. Also the same IP
tunneling or SCEF services used later for the SCHC packets transport tunneling or SCEF services used later for the SCHC packets transport
may be used by the applications in both ends to deliver the static may be used by the applications in both ends to deliver the static
contexts to be used. contexts to be used.
skipping to change at page 15, line 37 skipping to change at page 15, line 16
The Fragmentation Rule ID is given when choosing the profile The Fragmentation Rule ID is given when choosing the profile
according to the fragmentation mode, 1 bit can be used to recognize according to the fragmentation mode, 1 bit can be used to recognize
each mode. each mode.
To adapt SCHC to the NB-IoT constraints, two configuration are To adapt SCHC to the NB-IoT constraints, two configuration are
proposed to fill the best the transfer block (TB). The Header size proposed to fill the best the transfer block (TB). The Header size
needs to be multiple of 4 and the Tiles can keep a fix value of 4 or needs to be multiple of 4 and the Tiles can keep a fix value of 4 or
8 bits to avoid the need of padding. 8 bits to avoid the need of padding.
* 8 bits-Header_size configuration, with the size of the header o 8 bits-Header_size configuration, with the size of the header
fields as follow: Rule ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 fields as follow: Rule ID 3 bits, DTag 1 bit, FCN 3 bits, W 1
bits. This configuration may ne used with TB less than 300 bits. bits. This configuration may ne used with TB less than 300 bits.
* 16 bits-Header_size configuration, with the size of the header o 16 bits-Header_size configuration, with the size of the header
fields as follow: Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 fields as follow: Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3
bits, W 2 or 3 bits. This configuration may be used with TB above bits, W 2 or 3 bits. This configuration may be used with TB above
300 bits. 300 bits.
The IoT devices communicates with small data transfer and have a The IoT devices communicates with small data transfer and have a
battery life of 10 years. To minise the power consumption these battery life of 10 years. To minise the power consumption these
devices use the Power Save Mode and the Idle Mode DRX which govern devices use the Power Save Mode and the Idle Mode DRX which govern
how often the device wakes up, stays up and are reachable. The how often the device wakes up, stays up and are reachable. The
Table 10.5.163a in {3GPP-TS_24.088} specifies a range for the radio 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 the units of N can be 1 timers as N to 3N in increments of one where the units of N can be 1
skipping to change at page 16, line 27 skipping to change at page 15, line 47
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.
8. Security considerations 8. Security considerations
3GPP access security is specified in (TGPP33203). 3GPP access security is 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.
* [TGPP33203] 3GPP, "TS 33.203 v13.1.0 - 3G security; Access o TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
security for IP-based services", 2016. for IP-based services", 2016.
* [TGPP36321] 3GPP, "TS 36.321 v13.2.0 - Evolved Universal o TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial
Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Radio Access (E-UTRA); Medium Access Control (MAC) protocol
protocol specification", 2016 specification", 2016
* [TGPP36323] 3GPP, "TS 36.323 v13.2.0 - Evolved Universal o TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial
Terrestrial Radio Access (E-UTRA); Packet Data Convergence Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
Protocol (PDCP) specification", 2016. specification", 2016.
* [TGPP36331] 3GPP, "TS 36.331 v13.2.0 - Evolved Universal o TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial
Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol
Protocol specification", 2016. specification", 2016.
* [TGPP36300] 3GPP, "TS 36.300 v15.1.0 - Evolved Universal o TGPP36300 3GPP, "TS 36.300 v15.1.0 - Evolved Universal Terrestrial
Terrestrial Radio Access (E-UTRA) and Evolved Universal Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio
Terrestrial Radio Access Network (E-UTRAN); Overall description; Access Network (E-UTRAN); Overall description; Stage 2", 2018
Stage 2", 2018
* [TGPP24301] 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) o 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
* [TGPP24088] 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface o TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer
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) are associated with one PDCP entity. Each of the Radio Bearers (RB) are associated with one PDCP entity.
And a PDCP entity is associated with one or two RLC entities And a PDCP entity is associated with one or two RLC entities
depending of the unidirectional or bi-directional characteristics of depending of the unidirectional or bi-directional characteristics of
the RB and RLC mode used. A PDCP entity is associated either control the RB and RLC mode used. A PDCP entity is associated either control
plane or user plane which independent configuration and functions. plane or user plane which independent configuration and functions.
The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. 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 main services and functions of the PDCP sublayer for NB-IoT for
the user plane include: the user plane include:
* Header compression and decompression by means of ROHC (Robust o Header compression and decompression by means of ROHC (Robust
Header Compression) Header Compression)
* Transfer of user and control data to higher and lower layers o 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)
* Ciphering and deciphering o 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 that are transmitted over the air optimizing the MAC creating packets that are 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 set of entities, one Therefore to configure bi-directional flows, two set of entities, one
in each direction (downlink and uplink) must be configured and they in each direction (downlink and uplink) must be configured and they
are effectively peered to each other. The peering allows the are 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:
* Transparent Mode (TM). In this mode RLC do not segment or o Transparent Mode (TM). In this mode RLC do not segment or
concatenate SDUs from higher layers and do not include any header concatenate SDUs from higher layers and do not include any header
to the payload. When acting as a transmitter, RLC receives SDUs to the payload. When acting as a transmitter, RLC receives SDUs
from upper layers and transmit directly to its flow RLC receiver from upper layers and transmit directly to its flow RLC receiver
via lower layers. Similarly, an TM RLC receiver would only via lower layers. Similarly, an TM RLC receiver would only
deliver without additional processing the packets to higher layers deliver without additional processing the packets to higher layers
upon reception. upon reception.
* Unacknowledged Mode (UM). This mode provides support for o Unacknowledged Mode (UM). This mode provides support for
segmentation and concatenation of payload. The size of the RLC segmentation and concatenation of payload. The size of the RLC
packet depends of the indication given at a particular packet depends of the indication given at a particular
transmission opportunity by the lower layer (MAC) and are octets transmission opportunity by the lower layer (MAC) and are octets
aligned. The packet delivery to the receiver do not include aligned. The packet delivery to the receiver do not include
support for reliability and the lost of a segment from a packet support for reliability and the lost of a segment from a packet
means a whole packet loss. Also in case of lower layer means a whole packet loss. Also in case of lower layer
retransmissions there is no support for re-segmentation in case of retransmissions there is no support for re-segmentation in case of
change of the radio conditions triggering the selection of a change of the radio conditions triggering the selection of a
smaller transport block. Additionally it provides PDU duplication smaller transport block. Additionally it provides PDU duplication
detection and discard, reordering of out of sequence and loss detection and discard, reordering of out of sequence and loss
detection. detection.
* Acknowledged Mode (AM). Additional to the same functions o Acknowledged Mode (AM). Additional to the same functions
supported from UM, this mode also adds a moving windows based supported from 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
provides support for re-segmentation and it requires bidirectional provides support for 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 is needed. Protocol error Report and trigger retransmissions is needed. Protocol error
detection is also supported by this mode. The mode uses depends detection is also supported by this mode. The mode uses depends
of the operator configuration for the type of data to be of the operator configuration for the type of data to be
transmitted. For example, data transmissions supporting mobility transmitted. For example, data transmissions supporting mobility
or requiring high reliability would be most likely configured or requiring high reliability would be most likely configured
using AM, meanwhile streaming and real time data would be map to a using AM, meanwhile streaming and real time data would be map to a
skipping to change at page 19, line 32 skipping to change at page 18, line 48
/ / / _/ _// _/ _/ / 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 6: Example of User Plane packet encapsulation for two Figure 6: 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 AS protocol stack used by DoNAS is somehow special. Since the The AS protocol stack used by DoNAS is somehow special. Since the
security associations are not established yet in the radio network, security associations are not established yet in the radio network,
to reduce the protocol overhead, PDCP (Packet Data Convergence to reduce the protocol overhead, PDCP (Packet Data Convergence
Protocol) is bypassed until AS security is activated. RLC (Radio Protocol) is bypassed until AS security is activated. RLC (Radio
Link Control protocol) is configured by default in AM mode, but Link Control protocol) is configured by default in AM mode, but
depending of the features supported by the network and the terminal depending of the features supported by the network and the terminal
it may be configured in other modes by the network operator. For it may be configured in other modes by the network operator. For
example, the transparent mode does not add any header or does not example, the transparent mode does not add any header or does not
process the payload in any way reducing the overhead, but the MTU process the payload in any way reducing the overhead, but the MTU
would be limited by the transport block used to transmit the data 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 which is couple of thousand of bits maximum. If UM (only Release 15
compatible terminals) is used, the RLC mechanisms of reliability is compatible terminals) is used, the RLC mechanisms of reliability is
disabled and only the reliability provided by the MAC layer by Hybrid disabled and only the reliability provided by the MAC layer by Hybrid
Automatic Repeat reQuest (HARQ) is available. In this case, the Automatic Repeat reQuest (HARQ) is available. In this case, the
protocol overhead might be smaller than for the AM case because the protocol overhead might be smaller than for the AM case because the
lack of status reporting but with the same support for segmentation lack of status reporting but with the same support for segmentation
up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio
Resource Control)[TGPP36331] message. Resource Control) TGPP36331 message.
Depending of the data type indication signaled (IP or non-IP data), Depending of the data type indication signaled (IP or non-IP data),
the network allocates an IP address or just establish a direct the network allocates an IP address or just establish a direct
forwarding path. DoNAS is regulated under rate control upon previous forwarding path. DoNAS is regulated under rate control upon previous
agreement, meaning that a maximum number of bits per unit of time is agreement, meaning that a maximum number of bits per unit of time is
agreed per device subscription beforehand and configured in the agreed per device subscription beforehand and configured in the
device. The use of DoNAS is typically expected when a terminal in a 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 power saving state requires to do a short transmission and receive an
acknowledgment or short feedback from the network. Depending of the acknowledgment or short feedback from the network. Depending of 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
skipping to change at page 22, line 32 skipping to change at page 21, 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 8: Example of User Plane packet encapsulation for Data Figure 8: Example of User Plane packet encapsulation for Data over
over NAS NAS
11. Informative 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, DOI 10.17487/RFC5795, March 2010, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc5795>. 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.
Zúñiga, "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, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-
<https://www.rfc-editor.org/info/rfc8724>. editor.org/info/rfc8724>.
Authors' Addresses Authors' Addresses
Edgar Ramos Edgar Ramos
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI- 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
 End of changes. 80 change blocks. 
126 lines changed or deleted 129 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/