< draft-ietf-lpwan-schc-over-nbiot-07.txt   draft-ietf-lpwan-schc-over-nbiot-08.txt >
lpwan Working Group E. Ramos lpwan Working Group E. Ramos
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational A. Minaburo Intended status: Standards Track A. Minaburo
Expires: 26 August 2022 Acklio Expires: 20 November 2022 Acklio
22 February 2022 19 May 2022
SCHC over NB-IoT SCHC over NBIoT
draft-ietf-lpwan-schc-over-nbiot-07 draft-ietf-lpwan-schc-over-nbiot-08
Abstract Abstract
The Static Context Header Compression (SCHC) specification describes The Static Context Header Compression and Fragmentation (SCHC)
header compression and fragmentation functionalities for LPWAN (Low specification describes header compression and fragmentation
Power Wide Area Networks) technologies. The Narrow Band Internet of functionalities for LPWAN (Low Power Wide Area Networks)
Things (NB-IoT) architecture may adapt SCHC to improve its technologies. The Narrowband Internet of Things (NB-IoT)
capacities. architecture may adapt SCHC to improve its 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 use-cases 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 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 26 August 2022. This Internet-Draft will expire on November 20, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . 5 4. Data Transmission in the 3GPP Architecture . . . . . . . . . 5
5. IP based Data Transmission . . . . . . . . . . . . . . . . . 6 4.1. Use of SCHC over the Radio link . . . . . . . . . . . . . 6
5.1. SCHC over the Radio link . . . . . . . . . . . . . . . . 6 4.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6
5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6 4.2. Use of SCHC over the No-Access Stratum (NAS) . . . . . . 7
5.2. SCHC over No-Access Stratum (NAS) . . . . . . . . . . . . 7 4.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 4.2.2. Parameters for Static Context Header Compression and
5.3. Parameters for Static Context Header Compression Fragmentation (SCHC) for the Section 4.1 and
(SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 8 Section 4.2. . . . . . . . . . . . . . . . . . . . . 9
5.3.1. SCHC Context initialization . . . . . . . . . . . . . 9 4.3. End-to-End Compression . . . . . . . . . . . . . . . . . 11
5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 11
5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 9 4.3.2. Parameters for Static Context Header Compression and
5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 10 Fragmentation (SCHC) . . . . . . . . . . . . . . . . 12
5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 10 5. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. End-to-End Compression . . . . . . . . . . . . . . . . . . . 10 6. Security considerations . . . . . . . . . . . . . . . . . . . 14
6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 11 7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Parameters for Static Context Header Compression . . . . 11 7.1. NB-IoT User Plane protocol architecture . . . . . . . . . 14
6.2.1. SCHC Context initialization . . . . . . . . . . . . . 11 7.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . . 14
6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 12 7.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . . 15
6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.3. Medium Access Control (MAC) . . . . . . . . . . . . . 16
6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12 7.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . 19
6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 12
6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 13
7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security considerations . . . . . . . . . . . . . . . . . . . 13
9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 13
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. NB-IoT User Plane protocol architecture . . . . . . . . 14
10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 14
10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 15
10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 16
10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 described in
[RFC8376]. [RFC8376].
In an NB-IoT network, header compression efficiently brings Internet In a Narrowband Internet of Things (NB-IoT) network, header
connectivity to the node. This document describes the SCHC compression efficiently brings Internet connectivity to the Device -
parameters used to performs the static context header compression User Equipment (Dev-UE). This document describes the SCHC parameters
into the NB-IoT wireless access. This document assumes functionality used to support the static context header compression and
for NB-IoT of 3GPP release 15. Otherwise, the text explicitly fragmentation over the NB-IoT wireless access. This document assumes
mentions other versions' functionality. functionality for NB-IoT of 3GPP release 15 (3GPPR15). Otherwise,
the text explicitly 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].
* CIoT. Cellular IoT * CIoT. Cellular IoT.
* NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node * NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node.
* Dev-UE. Device - User Equipment * Dev-UE. Device - User Equipment.
* RGW-eNB. Radio Gateway - Node B. Base Station that controls the * RGW-eNB. Radio Gateway - Node B. Base Station that controls the
UE UE.
* EPC. Evolved Packet Connectivity. Core network of 3GPP LTE * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
systems. systems.
* EUTRAN. Evolved Universal Terrestrial Radio Access Network. * EUTRAN. Evolved Universal Terrestrial Radio Access Network.
Radio network from LTE based systems. Radio access network of LTE-based systems.
* NGW-MME. Network Gateway - Mobility Management Entity. Handle * NGW-MME. Network Gateway - Mobility Management Entity. An entity
mobility of the UE in charge of handling mobility of the Dev-UE.
* NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology * NB-IoT. Narrowband IoT. A 3GPP LPWAN technology based on the LTE
based in LTE architecture but with additional optimization for IoT architecture but with additional optimization for IoT and using a
and using a Narrow Band spectrum frequency. Narrowband spectrum frequency.
* NGW-SGW. Network Gateway - Serving Gateway. Routes and forwards * NGW-SGW. Network Gateway - Serving Gateway. It routes and
the user data packets through the access network forwards the user data packets through the access network.
* HSS. Home Subscriber Server. It is a database that performs * HSS. Home Subscriber Server. It is a database that performs
mobility management mobility management.
* 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.
* PDU. Protocol Data Unit. Data packets including headers that are * PDU. Protocol Data Unit. A data packet including headers that
transmitted between entities through a protocol. are transmitted between entities through a protocol.
* SDU. Service Data Unit. Data packets (PDUs) from higher layers * SDU. Service Data Unit. A data packet (PDU) from higher layer
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.
* IWK-SCEF. InterWorking Service Capabilities Exposure Function. * IWK-SCEF. InterWorking Service Capabilities Exposure Function.
Used in roaming scenarios and serves for interconnection with the It is used in roaming scenarios, it is located in the Visited PLMN
SCEF of the Home PLMN and is located in the Visited PLMN and serves for interconnection with the SCEF of the Home PLMN.
* 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
+---+ +------+ The Narrowband Internet of Things (NB-IoT) architecture has a complex
|Dev| \ +-----+ ----| HSS | structure. It relies on different NGWs from different providers and
+---+ \ | NGW | +------+ can send data via different paths, each path with different
| |-MME |\__ characteristics in terms of bandwidths, acknowledgments, and layer
\ / +-----+ \ two reliability and segmentation.
+---+ \+-----+ / | +------+
|Dev| ----| RGW |- | | NGW- |
+---+ |-eNB | | | SCEF |---------+
/+-----+ \ | +------+ |
/ \ +------+ |
/ \| NGW- | +-----+ +-----------+
+---+ / | CSGW |--| NGW-|---|Application|
|Dev| | | | PGW | | Server |
+---+ +------+ +-----+ +-----------+
Figure 1: 3GPP network architecture
The Narrow Band Internet of Things (NB-IoT) architecture has a more
complex structure. It relies on different NGWs from different
providers and can send data by different paths, each path with
different characteristics such as bandwidths, acknowledgments, and
layer two reliability and segmentation.
Figure 1 shows this architecture where the Network Gateway Cellular Figure 1 shows this architecture, where the Network Gateway Cellular
Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co- Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co-
locating entities in different paths. For example, a Dev using the locating entities in different paths. For example, a Dev-UE using
path form by the Network Gateway Mobility Management Entity (NGW- the path formed by the Network Gateway Mobility Management Entity
MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway (NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway
(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 NB-IoT 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:
Connectivity path and Device Monitoring.
* Connectivity path +---+ +------+
|Dev| \ +-----+ ----| HSS |
|-UE| \ | NGW | +------+
+---+ | |-MME |\__
\ / +-----+ \
+---+ \+-----+ / | +------+
|Dev| ----| RGW |- | | NGW- |
|-UE| |-eNB | | | SCEF |---------+
+---+ /+-----+ \ | +------+ |
/ \ +------+ |
/ \| NGW- | +-----+ +-----------+
+---+ / | CSGW |--| NGW-|---|Application|
|Dev| | | | PGW | | Server |
|-UE| +------+ +-----+ +-----------+
+---+
* Device Monitoring Figure 1: 3GPP network architecture
4. Data Transmission 4. Data Transmission in the 3GPP Architecture
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 signalling
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 signalling 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.
The maximum recommended MTU size is 1358 Bytes. The radio network The maximum recommended 3GPP MTU size is 1358 Bytes. The radio
protocols limit the packet sizes over the air, including radio network protocols limit the packet sizes over the air, including
protocol overhead to 1600 Bytes. However, the MTU is smaller to radio protocol overhead, to 1600 Bytes. However, the recommended MTU
avoid fragmentation in the network backbone due to the payload is smaller to avoid fragmentation in the network backbone due to the
encryption size (multiple of 16) and the additional core transport payload encryption size (multiple of 16) and the additional core
overhead handling. transport overhead handling.
3GPP standardizes NB-IoT and, in general, the cellular technologies 3GPP standardizes NB-IoT and, in general, the cellular technologies
interfaces and functions. Therefore the introduction of SCHC interfaces and functions. Therefore the introduction of SCHC
entities to Dev, RGW-eNB, and NGW-CSGN needs to be specified in the entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in
NB-IoT standard, which implies that standard specifying SCHC support the NB-IoT standard, which implies that standard specifying SCHC
would not be backward compatible. A terminal or a network supporting support would not be backward compatible. A terminal or a network
a version of the standard without SCHC or without capability supporting a version of the standard without SCHC or without an
implementation (in case of not being standardized as mandatory implementation capability (in case of not being standardized as
capability) cannot utilize the compression services with this mandatory capability) cannot utilize SCHC with this approach.
approach.
SCHC could be deployed differently depending on where the header SCHC could be deployed differently depending on where the header
compression and the fragmentation are applied. The SCHC compression and the fragmentation are applied. The SCHC
functionalities can be used over the radio transmission only, between functionalities can be used over the radio transmission only, between
the Dev and the RGW-eNB. Alternatively, the packets transmitted over the Dev-UE and the RGW-eNB. Alternatively, the packets transmitted
the end-to-end link can use SCHC. Else, when the transmissions over over the path can use SCHC. Else, when the transmissions go over the
the NGW-MME or NGW-SCEF, the NGW-CSGN uses SCHC entity. For these NGW-MME or NGW-SCEF, the NGW-CSGN uses SCHC entity. For these two
two cases, the functions are to be standardized by 3GPP. cases, the functions need to be standardized by 3GPP.
Another possibility is to apply SCHC functionalities to the end-to- Another possibility is to apply SCHC functionalities to the end-to-
end connection or at least up to the operator network edge. SCHC end connection or at least up to the operator network edge. SCHC
functionalities are available in the application layer of the Dev and functionalities are available in the application layer of the Dev-UE
the Application Servers or a broker function at the edge of the and the Application Servers or a broker function at the edge of the
operator network. The radio network transmits the packets as non-IP operator network. The radio network transmits the packets as non-IP
traffic using IP tunneling or SCEF services. Since this option does traffic using IP tunnelling or SCEF services. Since this option does
not necessarily require 3GPP standardization, it is possible to also not necessarily require 3GPP standardization, it is possible to also
benefit legacy devices with SCHC by using the non-IP transmission benefit legacy devices with SCHC by using the non-IP transmission
features of the operator network. features of the operator network.
5. IP based Data Transmission 4.1. Use of SCHC over the Radio link
5.1. SCHC over the Radio link
Deploying SCHC only over the radio link would require placing it as Deploying SCHC only over the radio link would require placing it as
part of the protocol stack for data transfer between the Dev and the part of the protocol stack for data transfer between the Dev-UE and
RGW-eNB. This stack is the functional layer responsible for the RGW-eNB. This stack is the functional layer responsible for
transporting data over the wireless connection and managing radio transporting data over the wireless connection and managing radio
resources. There is support for features such as reliability, resources. There is support for features such as reliability,
segmentation, and concatenation. The transmissions use link segmentation, and concatenation. The transmissions use link
adaptation, meaning that the system will optimize the transport adaptation, meaning that the system will optimize the transport
format used according to the radio conditions, the number of bits to format used according to the radio conditions, the number of bits to
transmit, and the power and interference constraints. That means transmit, and the power and interference constraints. That means
that the number of bits transmitted over the air depends on the that the number of bits transmitted over the air depends on the
Modulation and Coding Schemes (MCS) selected. A Transport Block (TB) Modulation and Coding Schemes (MCS) selected. The transmissions of
transmissions happen in the physical layer at network synchronized Transport Block (TB) happen in the physical layer at network
intervals called Transmission Time Interval (TTI). Each Transport synchronized intervals called Transmission Time Interval (TTI). Each
Block has a different MCS and number of bits available to transmit. Transport Block has a different MCS and number of bits available to
The MAC layer [TGPP36321] defines the Transport Blocks transmit. The MAC layer [TGPP36321] defines the Transport Blocks
characteristics. The Radio link Figure 2 stack comprises the Packet characteristics. The Radio link stack shown in Figure 2 comprises
Data Convergence Protocol (PDCP) [TGPP36323], Radio Link Protocol the Packet Data Convergence Protocol (PDCP) [TGPP36323], Radio Link
(RLC) [TGPP36322], Medium Access Control protocol (MAC) [TGPP36321], Protocol (RLC) [TGPP36322], Medium Access Control protocol (MAC)
and the Physical Layer [TGPP36201]. The Appendix gives more details [TGPP36321], and the Physical Layer [TGPP36201]. The
of these protocols. Appendix gives more details of these protocols.
5.1.1. SCHC Entities Placing 4.1.1. SCHC Entities Placing
The current architecture provides support for header compression in The current architecture provides support for header compression in
PDCP with RoHC [RFC5795]. Therefore SCHC entities can be deployed the PDCP layer using RoHC [RFC5795]. Therefore SCHC header
similarly without the need for significant changes in the 3GPP compression entities can be deployed similarly without the need for
specifications. significant changes in the 3GPP specifications.
In this scenario, RLC takes care of fragmentation unless for the In this scenario, the RLC layer takes care of fragmentation unless
transparent mode. When packets exceed the transport block size at for the Transparent Mode. When packets exceed the Transport Block
the time of transmission, SCHC fragmentation is unnecessary and size at transmission, SCHC fragmentation is unnecessary and should
should not be used to avoid the additional protocol overhead. It is not be used to avoid the additional protocol overhead. The RLC
not common to configure RLC in Transparent Mode for IP-based data. Transparent Mode is not commonly used while sending IP packets in the
However, given the case in the future, SCHC fragmentation may be Radio link. However, given the case in the future, SCHC
used. In that case, a SCHC tile would match the minimum transport fragmentation may be used. In that case, a SCHC tile would match the
block size minus the PDCP and MAC headers. minimum transport block size minus the PDCP and MAC headers.
+---------+ +---------+ | +---------+ +---------+ |
|IP/non-IP+------------------------------+IP/non-IP+->+ |IP/non-IP+------------------------------+IP/non-IP+->+
+---------+ | +---------------+ | +---------+ | +---------+ | +---------------+ | +---------+ |
| PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+ | PDCP +-------+ PDCP | GTP|U +------+ GTP-U |->+
| (SCHC) + + (SCHC)| + + | | | (SCHC) + + (SCHC)| + + | |
+---------+ | +---------------+ | +---------+ | +---------+ | +---------------+ | +---------+ |
| 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-UE RGW-eNB NGW-CSGN
Radio Link
Figure 2: SCHC over the Radio link Figure 2: SCHC over the Radio link
5.2. SCHC over No-Access Stratum (NAS) 4.2. Use of SCHC over the 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-UE and
cellular network [TGPP24301]. The network transports this traffic on the cellular network [TGPP24301]. The network transports this
top of the radio link. traffic on 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
Control Plane CIoT EPS optimization. In DoNAS, the Dev uses the pre- Control Plane CIoT EPS optimization. In DoNAS, the Dev-UE uses the
established security and piggyback small uplink data into the initial pre-established security and can piggyback small uplink data into the
uplink message and uses an additional message to receive downlink initial uplink message and uses an additional message to receive a
small data response. downlink small data response.
The NGW-MME performs the data encryption from the network side in a The NGW-MME performs the data encryption from the network side in a
DoNAS PDU. Depending on the data type signaled indication (IP or DoNAS PDU. Depending on the data type signaled indication (IP or
non-IP data), the network allocates an IP address or establishes a non-IP data), the network allocates an IP address or establishes a
direct forwarding path. DoNAS is regulated under rate control upon direct forwarding path. DoNAS is regulated under rate control upon
previous agreement, meaning that a maximum number of bits per unit of previous agreement, meaning that a maximum number of bits per unit of
time is agreed upon per device subscription beforehand and configured time is agreed upon per device subscription beforehand and configured
in the device. in the device.
The system will use DoNAS when a terminal in a power-saving state The system will use DoNAS when a terminal in a power-saving state
requires a short transmission and receives an acknowledgment or short requires a short transmission and receives an acknowledgment or short
feedback from the network. Depending on the size of buffered data to feedback from the network. Depending on the size of buffered data to
transmit, the Dev might deploy the connected mode transmissions transmit, the Dev-UE might deploy the connected mode transmissions
instead, limiting and controlling the DoNAS transmissions to instead, limiting and controlling the DoNAS transmissions to
predefined thresholds and a good resource optimization balance for predefined thresholds and a good resource optimization balance for
the terminal and the network. The support for mobility of DoNAS is the terminal and the network. The support for mobility of DoNAS is
present but produces additional overhead. The Appendix gives present but produces additional overhead. The Appendix gives
additional details of DoNAS. additional details of DoNAS.
5.2.1. SCHC Entities Placing 4.2.1. SCHC Entities Placing
SCHC may reside in the Non-Access Stratum (NAS) protocol layer in In this scenario, SCHC may reside in the Non-Access Stratum (NAS)
this scenario. The same principles as for Radio link transmissions protocol layer. The same principles as for Radio link transmissions
apply here as well. The main difference is the physical placing of apply here as well. Because the NAS protocol already uses RoHC it
the SCHC entities on the network side as the NGW-MME resides in the can adapt SCHC for header compression too. The main difference
core network and is the terminating node for NAS instead of the eNB. compared to the radio link is the physical placing of the SCHC
entities. On the network side, the NGW-MME resides in the core
network and is the terminating node for NAS instead of the RGW-eNB.
+--------+ +--------+--------+ + +--------+ +--------+ +--------+--------+ + +--------+
| IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ | | IP/ +--+-----------------+--+ IP/ | IP/ +-----+ IP/ |
| Non-IP | | | | Non-IP | Non-IP | | | Non-IP | | Non-IP | | | | Non-IP | Non-IP | | | Non-IP |
+--------+ | | +-----------------+ | +--------+ +--------+ | | +-----------------+ | +--------+
| NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U | | NAS +-----------------------+ NAS |GTP-C/U +-----+GTP-C/U |
|(SCHC) | | | | (SCHC) | | | | | |(SCHC) | | | | (SCHC) | | | | |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | | | RRC +-----+RRC |S1|AP+-----+ S1|AP | | | | |
+--------+ | +-----------+ | +--------+ UDP +-----+ UDP | +--------+ | +-----------+ | +--------+ UDP +-----+ UDP |
| PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | | | PDCP* +-----+PDCP*|SCTP +-----+ SCTP | | | | |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP | | RLC +-----+ RLC | IP +-----+ IP | IP +-----+ IP |
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| 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-UE 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: SCHC entities placement in the 3GPP CIOT radio protocol
architecture for DoNAS transmissions
5.3. Parameters for Static Context Header Compression (SCHC)
5.3.1. SCHC Context initialization
RRC (Radio Resource Control) protocol is the main tool used to
configure the parameters of the Radio link. It will configure SCHC
and the static context distribution as it has made for RoHC operation
[TGPP36323].
5.3.2. SCHC Rules
The network operator in these scenarios defines the number of rules
in a context. The operator must be aware of the type of IP traffic
that the device will carry out. Implying that the operator might use
provision sets of rules compatible with the use case of the device.
For devices acting as gateways of other devices, several rules may
match the diversity of devices and protocols used by the devices
associated with the gateway. Meanwhile, simpler devices (for
example, an electricity meter) may have a predetermined set of fixed
protocols and parameters. Additionally, the deployment of IPv4
addresses and IPv6 may force different rules to deal with each case.
5.3.3. Rule ID 4.2.2. Parameters for Static Context Header Compression and
Fragmentation (SCHC) for the Section 4.1 and Section 4.2.
There is a reasonable assumption of 9 bytes of radio protocol These scenarios MUST use SCHC header compresion capability to improve
overhead for these transmission scenarios in NB-IoT, where PDCP uses the transmission of IPv6 packets. The 3GPP Architecture currently
5 bytes due to header and integrity protection, and RLC and MAC use 4 provides Header Compression using the [RFC5795] but the use of SCHC
bytes. The minimum physical Transport Blocks (TB) that can withhold for IoT application MUST be considered to improve the devices
this overhead value according to 3GPP Release 15 specifications are connectivity.
88, 104, 120, and 144 bits. A transmission optimization may require
only one physical layer transmission. SCHC overhead should not
exceed the available number of effective bits of the smallest
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 use the smallest TB, the
maximum SCHC header is 12 bits. These 12 bits must include the
Compression Residue in addition to the Rule ID. On the other hand,
more complex NB-IoT devices (such as a capillarity gateway) might
require additional bits to handle the variety and multiple parameters
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, these scenarios require
a configurable value. The configuration may be part of the operation
profile agreed together with the content distribution. The Rule ID
field size may range from 2 bits, resulting in 4 rules to an 8 bits
value that would yield up to 256 rules that 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
consider the byte-alignment of the expected Compression Residue. In
the minimum TB size case, 2 bits of Rule Id leave only 6 bits
available for Compression Residue.
5.3.4. SCHC MAX_PACKET_SIZE * SCHC Context initialization RRC (Radio Resource Control) protocol
is the main tool used to configure the parameters of the Radio
link. It will configure SCHC and the static context distribution
as it has made for RoHC operation [TGPP36323].
The Radio Link can handle the fragmentation of SCHC packets if * SCHC Rules The network operator in these scenarios defines the
needed, including reliability. Hence the packet size is limited by number of rules in a context. The operator must be aware of the
the MTU handled by the radio protocols that correspond to 1600 bytes type of IP traffic that the device will carry out. Implying that
for 3GPP Release 15. the operator might use provision sets of rules compatible with the
use case of the device. For devices acting as gateways of other
devices, several rules may match the diversity of devices and
protocols used by the devices associated with the gateway.
Meanwhile, simpler devices (for example, an electricity meter) may
have a predetermined set of fixed protocols and parameters.
Additionally, the deployment of IPv6 addresses may force different
rules to deal with each case.
5.3.5. Fragmentation * RuleID There is a reasonable assumption of 9 bytes of radio
protocol overhead for these transmission scenarios in NB-IoT,
where PDCP uses 5 bytes due to header and integrity protection,
and RLC and MAC use 4 bytes. The minimum physical Transport
Blocks (TB) that can withhold this overhead value according to
3GPP Release 15 specifications are 88, 104, 120, and 144 bits. A
transmission optimization may require only one physical layer
transmission. SCHC overhead should not exceed the available
number of effective bits of the smallest 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 use the smallest TB, the maximum SCHC
header size is 12 bits. These 12 bits must include the
Compression Residue in addition to the RuleID. On the other hand,
more complex NB-IoT devices (such as a capillarity gateway) might
require additional bits to handle the variety and multiple
parameters 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,
these scenarios require a configurable value. The configuration
may be part of the operation profile agreed together with the
content distribution. The RuleID field size may range from 2
bits, resulting in 4 rules to an 8-bit value that would yield up
to 256 rules that 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 consider the
byte-alignment of the expected Compression Residue. In the
minimum TB size case, 2 bits of RuleID leave only 6 bits available
for Compression Residue.
For these scenarios, the SCHC fragmentation functions are disabled. * SCHC MAX_PACKET_SIZE The Radio Link can handle the fragmentation
The RLC layer of NB-IoT can segment packets in suitable units that of SCHC packets if needed, including reliability. Hence the
fit the selected transport blocks for transmissions of the physical packet size is limited by the MTU handled by the radio protocols
layer. The blocks selection is made according to the link adaptation which corresponds to 1600 bytes for 3GPP Release 15.
input 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 depend on the network load, interference,
number of bits transmitted, and QoS. Even if setting a value that
allows the construction of data units following the SCHC tiles
principle, the protocol overhead may be greater or equal than
allowing the Radio link protocols to take care of the fragmentation
natively.
5.3.5.1. Fragmentation in Transparent Mode * Fragmentation For the Section 4.1 and Section 4.2 scenarios, the
SCHC fragmentation functions are 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
blocks selection is made according to the link adaptation input
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 depend on the network load, interference,
number of bits transmitted, and QoS. Even if setting a value that
allows the construction of data units following the SCHC tiles
principle, the protocol overhead may be greater or equal than
allowing the Radio link protocols to take care of the
fragmentation natively.
If RLC operates in Transparent Mode, there could be a case to * Fragmentation in RLC Transparent Mode If RLC operates in
activate a fragmentation function together with a light reliability Transparent Mode, there could be a case to activate a
function such as the ACK-Always mode. In practice, it is uncommon to fragmentation function together with a light reliability function
transmit radio link data using this configuration. It mainly targets such as the ACK-Always mode. In practice, it is uncommon to
signaling transmissions. In those cases, the MAC layer mechanisms transmit radio link data using this configuration. It mainly
ensure reliability, such as repetitions or automatic retransmissions, targets signaling transmissions. In those cases, the MAC layer
and additional reliability might only generate protocol overhead. mechanisms ensure reliability, such as repetitions or automatic
retransmissions, and additional reliability might only generate
protocol overhead.
SCHC may reduce radio network protocols overhead in future SCHC may reduce radio network protocols overhead in future
operations, support reliable transmissions, and transmit small data operations, support reliable transmissions, and transmit compressed
with fewer possible transmissions by using fixed or limited transport data with fewer possible transmissions by using fixed or limited
blocks compatible with the tiling SCHC fragmentation handling. transport blocks compatible with the tiling SCHC fragmentation
handling. For SCHC fragmentation parameters see section
Section 4.3.2.
6. End-to-End Compression 4.3. End-to-End Compression
The Non-IP Data Delivery (NIDD) services of 3GPP enable the The Non-IP Data Delivery (NIDD) services of 3GPP enable the
transmission of SCHC packets compressed by the application layer. transmission of SCHC packets compressed by the application layer.
The packets can be delivered using IP-tunnels to the 3GPP network or The packets can be delivered using IP-tunnels to the 3GPP network or
NGW-SCEF functions (i.e., API calls). In both cases, as compression NGW-SCEF functions (i.e., API calls). In both cases, as compression
occurs before transmission, the network will not understand the occurs before transmission, the network will not understand the
packet, and the network does not have context information of this packet, and the network does not have context information of this
compression. Therefore the network will treat the packet as Non-IP compression. Therefore the network will treat the packet as Non-IP
traffic and deliver it to the Dev without any other stack element, traffic and deliver it to the other side without any other protocol
directly under the L2. stack element, directly under the L2.
6.1. SCHC Entities Placing 4.3.1. SCHC Entities Placing
In the two scenarios using End-to-End compression, SCHC entities are In the two scenarios using End-to-End compression, SCHC entities are
located almost on top of the stack. In the Dev, an application using located almost on top of the stack. The NB-IoT connectivity services
the NB-IoT connectivity services may implement SCHC and the implement SCHC in the Dev, an in the Application Server. The IP
Application Server. The IP tunneling scenario requires that the tunneling scenario requires that the Application Server send the
Application Server send the compressed packet over an IP connection compressed packet over an IP connection terminated by the 3GPP core
terminated by the 3GPP core network. If the transmission uses the network. If the transmission uses the NGW-SCEF services, it is
NGW-SCEF services, it is possible to utilize an API call to transfer possible to utilize an API call to transfer the SCHC packets between
the SCHC packets between the core network and the Application Server. the core network and the Application Server. Also, an IP tunnel
Also, an IP tunnel could be established by the Application Server if could be established by the Application Server if negotiated with the
negotiated with the NGW-SCEF. NGW-SCEF.
+---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+ +---------+ XXXXXXXXXXXXXXXXXXXXXXXX +--------+
| SCHC | XXX XXX | SCHC | | SCHC | XXX XXX | SCHC |
|(Non-IP) +-----XX........................XX....+--*---+(Non-IP)| |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)|
+---------+ XX +----+ XX | | +--------+ +---------+ XX +----+ XX | | +--------+
| | XX |SCEF+-------+ | | | | | XX |SCEF+-------+ | | |
| | 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) Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD)
3GPP Sevices 3GPP Sevices
6.2. Parameters for Static Context Header Compression 4.3.2. Parameters for Static Context Header Compression and
Fragmentation (SCHC)
6.2.1. SCHC Context initialization These scenarios may use SCHC header compresion capability to improve
the transmission of IPv6 packets. The use of SCHC for IoT
application MUST be considered to improve the devices connectivity.
The application layer handles the static context; consequently, the * SCHC Context initialization. The application layer handles the
context distribution must be according to the application's static context; consequently, the context distribution must be
capabilities, perhaps utilizing IP data transmissions up to context according to the application's capabilities, perhaps utilizing IP
initialization. Also, the static contexts delivery may use the same data transmissions up to context initialization. Also, the static
IP tunneling or NGW-SCEF services used later for the SCHC packets contexts delivery may use the same IP tunneling or NGW-SCEF
transport. services used later for the SCHC packets transport.
6.2.2. SCHC Rules * SCHC Rules. Even when the transmission content is not visible for
the 3GPP network, the same limitations as for Section 4.1 and
Section 4.2 transmissions apply in these scenarios in terms of
aiming to use the minimum number of transmissions and minimize the
protocol overhead.
Even when the transmission content is not visible for the 3GPP * Rule ID Similar to the case of Section 4.1 and Section 4.2, the
network, the same limitations as for IP-based data transmissions RuleID size can be dynamically set before the context delivery.
applies in these scenarios in terms of aiming to use the minimum For example, negotiated between the applications when choosing a
number of transmission and minimize the protocol overhead. profile according to the type of traffic and application deployed.
The same considerations related to the transport block size and
performance mentioned for the Section 4.1 and Section 4.2 must be
followed when choosing a size value for the RuleID field.
6.2.3. Rule ID * 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), not only the radio as the IP transmissions case.
Similar to the case of IP transmissions, the Rule ID size can be * Fragmentation Packets larger than 1358 bytes need the SCHC
dynamically set before the context delivery. For example, negotiated fragmentation function. Since the 3GPP uses reliability
between the applications when choosing a profile according to the functions, the No-ACK fragmentation mode may be enough in point-
type of traffic and application deployed. The same considerations to-point connections. Nevertheless, additional considerations are
related to the transport block size and performance mentioned for the described below for more complex cases.
IP type of traffic must be followed when choosing a size value for
the Rule ID field.
6.2.4. SCHC MAX_PACKET_SIZE * Fragmentation modes A global service assigns a QoS to the packets
depending on the billing. Packets with very low QoS may get lost
before they arrive in the 3GPP radio network transmission, for
example, in between the links of a capillarity gateway or due to
buffer overflow handling in a backhaul connection. The use of
SCHC fragmentation with the ACK-on-Error mode is recommended to
secure additional reliability on the packets transmitted with a
small trade-off on additional transmissions to signal the end-to-
end arrival of the packets if no transport protocol takes care of
retransmission.
Also, the ACK-on-Error mode 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 ACK-on-Error fragmentation may be active in
transmitting non-IP packets on the NGW-MME. A non-IP packet will
use SCHC reserved RuleID for non-compressing packets as [RFC8724]
allows it.
In these scenarios, the maximum recommended MTU size that applies is * Fragmentation Parameters SCHC profile will have specific Rules for
1358 Bytes since the SCHC packets (and fragments) are traversing the the fragmentation modes. The rule will identify, which
whole 3GPP network infrastructure (core and radio), not only the fragmentation mode is in use, and section Section 4.2.2 defines
radio as the IP transmissions case. the RuleID size.
6.3. Fragmentation SCHC parametrization considers that NBIoT aligns the bit and uses
padding and the size of the Transfer Block. SCHC will try to reduce
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
of 4 or 8 bits to avoid padding except for transfer block equals 16
bits where Tiles may be of 2 bits. The transfer block size has a
wide range of values. Two configurations may be used for the
fragmentation parameters.
In principle, packets larger than 1358 bytes need the fragmentation * For Transfer Blocks smaller or equal to 300bits using a 8 bits-
function. Since the 3GPP uses reliability functions, the No-ACK Header_size configuration, with the size of the header fields as
fragmentation mode may be enough in point-to-point connections. follows:
Nevertheless, additional considerations are described below for more
complex cases.
6.3.1. Fragmentation modes - RuleID from 1 - 3 bits,
A global service assigns a QoS to the packets depending on the - DTag 1 bit,
billing. Packets with very low QoS may get lost before they arrive
in the 3GPP radio network transmission, for example, in between the
links of a capillarity gateway or due to buffer overflow handling in
a backhaul connection. The use of SCHC fragmentation with the ACK-
on-Error mode is recommended to secure additional reliability on the
packets transmitted with a small trade-off on additional
transmissions to signal the end-to-end arrival of the packets if no
transport protocol takes care of retransmission. Also, the ACK-on-
Error mode 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 ACK-on-Error
fragmentation may be active for the transmission of non-IP packets on
the NGW-MME. If these packets are considering to use SCHC with the
RuleID for non-compressing packets as {RFC8724} allows it.
6.3.2. Fragmentation Parameters - FCN 3 bits,
SCHC profile with the fragmentation mode will have specific Rules. - W 1 bits.
The Rule ID will identify the fragmentation mode used, and it is
defined in section Section 5.3.3.
SCHC parametrization considers that NBIoT aligns the bit and uses * For Transfer Blocks bigger than 300 bits using a 16 bits-
padding and the size of the Transfer Block. SCHC will try to reduce Header_size configuration, with the size of the header fields as
padding to optimize the compression of the information. The Header follows:
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
bits where Tiles may be of 2 bits. For the other parameters, the
transfer block size has a wide range that needs two configurations.
* For Transfer Blocks smaller than 300bits: 8 bits-Header_size - RulesID from 1 to 8 or 10 bits,
configuration, with the size of the header fields as follows: Rule
ID from 1 - 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits.
* For Transfer Blocks bigger than 300 bits: 16 bits-Header_size - DTag 1 or 2 bits,
configuration, with the size of the header fields as follows:
Rules ID from 1 to 8 or 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2 - FCN 3 bits,
or 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 be
use these limits. set based on these limits.
7. Padding 5. 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 6. Security considerations
This document does not add any security considerations and follows This document does not add any security considerations and follows
the 3GPP access security document specified in [TGPP33203]. the [RFC8724] and the 3GPP access security document specified in
[TGPP33203].
9. 3GPP References
* TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture
enhancements for Cellular Internet of Things", 2016.
* TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
for IP-based services", 2016.
* TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial
Radio Access (E-UTRA); Medium Access Control (MAC) protocol
specification", 2016
* TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial
Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
specification", 2016.
* TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol
specification", 2016.
* TGPP36300 3GPP, "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", 2018
* TGPP24301 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)
protocol for Evolved Packet System (EPS); Stage 3", 2018
* TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer
3 specification;Core network protocols; Stage 3", 2015.
10. Appendix 7. Appendix
10.1. NB-IoT User Plane protocol architecture 7.1. NB-IoT User Plane protocol architecture
10.1.1. Packet Data Convergence Protocol (PDCP) 7.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:
skipping to change at page 15, line 4 skipping to change at page 14, line 45
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:
* Header compression and decompression using ROHC (Robust Header * Header compression and decompression using ROHC (Robust Header
Compression) Compression)
* 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 * 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 * Ciphering and deciphering
* Timer-based SDU discard in uplink * Timer-based SDU discard in uplink
10.1.2. Radio Link Protocol (RLC) 7.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
skipping to change at page 16, line 11 skipping to change at page 16, line 5
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
configuration. configuration.
10.1.3. Medium Access Control (MAC) 7.1.3. Medium Access Control (MAC)
MAC provides a mapping between the higher layers abstraction called MAC provides a mapping between the higher layers abstraction called
Logical Channels comprised by the previously described protocols to Logical Channels comprised by the previously described protocols to
the Physical layer channels (transport channels). Additionally, MAC the Physical layer channels (transport channels). Additionally, MAC
may multiplex packets from different Logical Channels and prioritize may multiplex packets from different Logical Channels and prioritize
what to fit into one Transport Block if there is data and space what to fit into one Transport Block if there is data and space
available to maximize data transmission efficiency. MAC also available to maximize data transmission efficiency. MAC also
provides error correction and reliability support through HARQ, provides error correction and reliability support through HARQ,
transport format selection, and scheduling information reporting from transport format selection, and scheduling information reporting from
the terminal to the network. MAC also adds the necessary padding and the terminal to the network. MAC also adds the necessary padding and
skipping to change at page 17, line 8 skipping to change at page 17, line 5
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
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) 7.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
transparent mode does not add any header or process the payload to transparent mode does not add any header or process the payload to
reduce the overhead, but the MTU would be limited by the transport reduce the overhead, but the MTU would be limited by the transport
skipping to change at page 19, line 35 skipping to change at page 19, line 35
| | | \ \ \ | | | | \ \ \ |
+----+----+----------++-----|----+---------++----+---------|---+ +----+----+----------++-----|----+---------++----+---------|---+
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 Figure 7: Example of User Plane packet encapsulation for Data
over NAS over NAS
11. Normative References 8. 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-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, DOI 10.17487/RFC8724, April 2020,
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
[TGPP23720] Meredith, J., "TR 23.720 v13.0.0 - Study on architecture
enhancements for Cellular Internet of Things", TR 23.720
v13.0.0, 2015,
<https://www.3gpp.org/ftp/Specs/archive/23_series/23.720
/23720-d00.zip>.
[TGPP33203] Soveri, M., "TR 33.203 v13.0.1 : 3G security; Access
security fro IP-based services", TR 33.203 v13.0.1, 2020
<https://www.3gpp.org/ftp/Specs/archive/33_series/33.203
/33203-d10.zip>.
[TGPP36321] Chung, Y., "TR 36.321 v13.2.0 : Evolved Universal
Terrestrial Radio Access (E-UTRA); Medium Access Control
(MAC) protocol specification", TR 36.321 V13.2.0, 2016,
<https://www.3gpp.org/ftp/Specs/archive/36_series/36.321
/36321-d20.zip>.
[TGPP36323] Chung, Y., "TS 36.323 v13.2.0 : Evolved Universal
Terrestrial Radio Access (E-UTRA); Packet Data Convergence
Protocol (PDCP) specification", TS 36.323 v13.2.0, 2016,
<https://www.3gpp.org/ftp/Specs/archive/36_series/36.323
/36323-d20.zip>.
[TGPP24301] Firmin. F., "TS 24.301 v13.2.0 : Non-Access-Stratum (NAS)
protocol for Evolved Packet System (EPS); Stage 3, TS
24.301 v13.2.0, 2015.
<https://www.3gpp.org/ftp/Specs/archive/24_series/24.301
/24301-d20.zip
Authors' Addresses Authors' Addresses
Edgar Ramos Edgar Ramos
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas, Kirkkonummi FI- 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. 99 change blocks. 
372 lines changed or deleted 377 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/