< draft-ietf-lpwan-schc-over-nbiot-05.txt   draft-ietf-lpwan-schc-over-nbiot-06.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: January 26, 2022 Acklio Expires: April 25, 2022 Acklio
July 25, 2021 October 22, 2021
SCHC over NB-IoT SCHC over NB-IoT
draft-ietf-lpwan-schc-over-nbiot-05 draft-ietf-lpwan-schc-over-nbiot-06
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 header compression and fragmentation functionalities for LPWAN (Low
Power Wide Area Networks) technologies. SCHC was designed to be Power Wide Area Networks) technologies.
adapted over any of the LPWAN technologies. The Narrow Band Internet of Things (NB-IoT) 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 an efficient parameterization. access and provides elements for efficient parameterization.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at 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 January 26, 2022. This Internet-Draft will expire on April 25, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6 4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 5
5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7 5. IP based Data Transmission . . . . . . . . . . . . . . . . . 6
5.1. SCHC over User Plane transmissions . . . . . . . . . . . 7 5.1. SCHC over the Radio link . . . . . . . . . . . . . . . . 6
5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 6
5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 8 5.2. SCHC over No-Access Stratum (NAS) . . . . . . . . . . . . 7
5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 9 5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
5.3. Parameters for Static Context Header Compression (SCHC) . 10 5.3. Parameters for Static Context Header Compression (SCHC) . 9
5.3.1. SCHC Context initialization . . . . . . . . . . . . . 10 5.3.1. SCHC Context initialization . . . . . . . . . . . . . 9
5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 10 5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 9
5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 11 5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 10
5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 11 5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 10
6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 12 6. End-to-End Compression . . . . . . . . . . . . . . . . . . . 10
6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 12 6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 11
6.2. Parameters for Static Context Header Compression . . . . 13 6.2. Parameters for Static Context Header Compression . . . . 11
6.2.1. SCHC Context initialization . . . . . . . . . . . . . 13 6.2.1. SCHC Context initialization . . . . . . . . . . . . . 11
6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 12
6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14 6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 14 6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 12
6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 15 6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 13
7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security considerations . . . . . . . . . . . . . . . . . . . 15 8. Security considerations . . . . . . . . . . . . . . . . . . . 13
9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 15 9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 14
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. NB-IoT User Plane protocol architecture . . . . . . . . 16 10.1. NB-IoT User Plane protocol architecture . . . . . . . . 14
10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 16 10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 14
10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17 10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 15
10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18 10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 16
10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19 10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 17
11. Normative References . . . . . . . . . . . . . . . . . . . . 21 11. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 suitable
specially tailored for Low Power Wide Area Networks (LPWAN) networks for the Low Power Wide Area Networks (LPWAN) networks defined in
defined in [RFC8376]. [RFC8376].
Header compression is needed to efficiently bring Internet
connectivity to the node within an NB-IoT network. SCHC uses a
static context to performs header compression with specific
parameters that need to be adapted into the NB-IoT wireless access.
This document assumes functionality for NB-IoT of 3GPP release 15.
Otherwise other versions' functionality is explicitly mentioned in
the text.
This document describes the use of SCHC and its parameterizing over In an NB-IoT network, header compression efficiently brings Internet
the NB-IoT wireless access. connectivity to the node. This document describes the SCHC
parameters used to performs the static context header compression
into the NB-IoT wireless access. This document assumes functionality
for NB-IoT of 3GPP release 15. 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.
o CIoT. Cellular IoT o CIoT. Cellular IoT
o C-SGN. CIoT Serving Gateway Node o NGW-C-SGN. Network Gateway - CIoT Serving Gateway Node
o UE. User Equipment o Dev-UE. Device - User Equipment
o eNB. Node B. Base Station that controls the UE o RGW-eNB. Radio Gateway - Node B. Base Station that controls the
UE
o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
systems. systems.
o EUTRAN. Evolved Universal Terrestrial Radio Access Network. o EUTRAN. Evolved Universal Terrestrial Radio Access Network.
Radio network from LTE based systems. Radio network from LTE based systems.
o MME. Mobility Management Entity. Handle mobility of the UE o NGW-MME. Network Gateway - Mobility Management Entity. Handle
mobility of the UE
o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology
based in LTE architecture but with additional optimization for IoT based in LTE architecture but with additional optimization for IoT
and using a Narrow Band spectrum frequency. and using a Narrow Band spectrum frequency.
o SGW. Serving Gateway. Routes and forwards the user data packets o NGW-SGW. Network Gateway - Serving Gateway. Routes and forwards
through the access network the user data packets through the access network
o HSS. Home Subscriber Server. It is a database that performs o HSS. Home Subscriber Server. It is a database that performs
mobility management mobility management
o PGW. Packet Data Node Gateway. An interface between the internal o NGW-PGW. Network Gateway - Packet Data Node Gateway. An
with the external network interface between the internal with the external network
o PDU. Protocol Data Unit. Data packets including headers that are o PDU. Protocol Data Unit. Data packets including headers that are
transmitted between entities through a protocol. transmitted between entities through a protocol.
o SDU. Service Data Unit. Data packets (PDUs) from higher layers o SDU. Service Data Unit. Data packets (PDUs) from higher layers
protocols used by lower layer protocols as a payload of their own protocols used by lower layer protocols as a payload of their own
PDUs that has not yet been encapsulated. PDUs that has not yet been encapsulated.
o IWK-SCEF. InterWorking Service Capabilities Exposure Function. o IWK-SCEF. InterWorking Service Capabilities Exposure Function.
Used in roaming scenarios and serves for interconnection with the Used in roaming scenarios and serves for interconnection with the
SCEF of the Home PLMN and is located in the Visited PLMN SCEF of the Home PLMN and is located in the Visited PLMN
o SCEF. Service Capability Exposure Function. EPC node for o NGW-SCEF. Network Gateway - Service Capability Exposure Function.
exposure of 3GPP network service capabilities to 3rd party EPC node for exposure of 3GPP network service capabilities to 3rd
applications. party applications.
3. Architecture 3. Architecture
+--+ +---+ +------+
D |UE| \ +-----+ +------+ |Dev| \ +-----+ ----| HSS |
+--+ \ | MME |-----| HSS | +---+ \ | NGW | +------+
E \ / +-----+ +------+ | |-MME |\__
+--+ \+-----+ / | \ / +-----+ \
V |UE| ----| RGW |- | +---+ \+-----+ / | +------+
+--+ |(eNB)| | |Dev| ----| RGW |- | | NGW- |
I /+-----+ \ | +---+ |-eNB | | | SCEF |---------+
/ \ +------+ /+-----+ \ | +------+ |
C / \| NGW | +------+ Service PDN / \ +------+ |
+--+ / |(S-GW)|--| NGW |-- e.g. Internet / \| NGW- | +-----+ +-----------+
E |UE| | | |(P-GW)| +---+ / | CSGW |--| NGW-|---|Application|
+--+ +------+ +------+ |Dev| | | | PGW | | Server |
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 Narrow Band Internet of Things (NB-IoT) architecture has a more
some optimizations and simplifications known as Cellular IoT (CIoT). complex structure. It relies on different NGWs from different
Considering the typical use cases for CIoT devices here are described providers and can send data by different paths, each path with
some of the additions to the LTE architecture specific for CIoT. different characteristics such as bandwidths, acknowledgments, and
C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating layer two reliability and segmentation.
EPS entities in the control plane and user plane paths (for example,
MME + SGW + P-GW) and the external interfaces of the entities
supported. The C-SGN also supports at least some of the following
CIoT EPS Optimizations:
o Control Plane CIoT EPS Optimization for small data transmission.
o User Plane CIoT EPS Optimization for small data transmission.
o Necessary security procedures for efficient small data
transmission.
o SMS without combined attach for NB-IoT only UEs.
o Paging optimizations for coverage enhancements.
o Support for non-IP data transmission via SGi tunneling and/or
SCEF.
o Support for Attach without PDN (Packet Data Network) connectivity.
Another node introduced in the CIOT architecture is the SCEF (Service
Capability Exposure Function) that provide means to securely expose
service and network capabilities to entities external to the network
operator. The northbound APIS are defined by OMA and OneM2M. The
main functions of a SCEF are:
o Non-IP Data Delivery (NIDD) established through the SCEF. Figure 1 shows this architecture where the Network Gateway Cellular
Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co-
locating entities in different paths. For example, a Dev using the
path form by the Network Gateway Mobility Management Entity (NGW-
MME), the NGW-CSGW, and Network Gateway Packet Data Node Gateway
(NGW-PGW) may get a limited bandwidth transmission from few bytes/s
to one thousand bytes/s only.
o Monitoring and exposure of event related to UE reachability, loss Another node introduced in the NBIoT architecture is the Network
of connectivity, location reporting, roaming status, communication Gateway Service Capability Exposure Function (NGW-SCEF), which
failure and change of IMEI-IMSI association. securely exposes service and network capabilities to entities
external to the network operator. OMA and OneM2M define the
northbound APIS [TGPP33203]. In this case, the path is small for
data transmission. The main functions of the NGW-SCEF are:
+-------+ o Connectivity path
| HSS |
+-+-----+
NGW /
DEV RGW +---------+ __/S6a
+--------+ | +-----+ +_/ NGW
+----+ C-Uu | +---+-+ MME | | T6i+--------+ T7 +----+
|CIOT+--------+ eNB |S1 | | +-+----+IWK-SCEF+----+SCEF|
|UE | |(NB-IoT)| | +---+-+ | +--------+ +----+
+----+ +--------+ | | |
|C-SGN| |
| |S11|
+------+ | | |
+--------+LTE-Uu| | | +--+-+ |
|LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+
| UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application|
+--------+ +------+ | +----+ | | +----+Server (AS)|
+---------+ +---+ +-----------+
DEV RGW NGW NGW App
Figure 2: 3GPP optimized CIOT network architecture o Device Monitoring
4. Data Transmission 4. Data Transmission
3GPP networks deal not only with data transmitted end-to-end but also NB-IoT networks deal with end-to-end user data and in-band signaling
with in-band signaling that is used between the nodes and functions between the nodes and functions to configure, control, and monitor
to configure, control and monitor the system functions and behaviors. the system functions and behaviors. The signaling data uses a
The control data is handled using a Control Plane which has a different path with specific protocols, handling processes, and
specific set of protocols, handling processes and entities. In entities but can transport end-to-end user data for IoT services. In
contrast, the end-to-end or user data utilize a User Plane with contrast, the end-to-end application only transports end-to-end data.
characteristics of its own separated from the Control Plane. The
handling and setup of the Control Plane and User Plane spans over the
whole 3GPP network and it has particular implications in the radio
network (i.e., EUTRAN) and in the packet core (ex., EPC).
For the CIOT cases, additionally to transmissions of data over User
Plane, 3GPP has specified optimizations for small data transmissions,
allowing to transport user data (IP, Non-IP) within signaling on the
access network (Data transmission over Control Plane or Data Over
NAS).
The maximum recommended MTU size is 1358 Bytes. The radio network The maximum recommended MTU size is 1358 Bytes. The radio network
protocols limit the packet sizes to be transmitted over the air protocols limit the packet sizes over the air, including radio
including radio protocol overhead to 1600 Octets. But the value is protocol overhead to 1600 Bytes. However, the MTU is smaller to
reduced further to avoid fragmentation in the backbone of the network avoid fragmentation in the network backbone due to the payload
due to the payload encryption size (multiple of 16) and handling of encryption size (multiple of 16) and the additional core transport
the additional core transport overhead. overhead handling.
NB-IoT and in general the cellular technologies interfaces and 3GPP standardizes NB-IoT and, in general, the cellular technologies
functions are standardized by 3GPP. Therefore the introduction of interfaces and functions. Therefore the introduction of SCHC
SCHC entities to UE, eNB and C-SGN does need to be specified in the entities to Dev, RGW-eNB, and NGW-CSGN needs to be specified in the
NB-IoT standard. This implies that standard specified SCHC support NB-IoT standard, which implies that standard specifying SCHC support
would not be backwards compatible. A terminal or a network would not be backward compatible. A terminal or a network supporting
supporting a version of the standard without support of SCHC or a version of the standard without SCHC or without capability
without capability implementation (in case of not being standardized implementation (in case of not being standardized as mandatory
as mandatory capability) is not able to utilize the compression capability) cannot utilize the compression services with this
services 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 could be applied to the packets about to be functionalities can be used over the radio transmission only, between
transmitted over the air, or to the whole end-to-end link. To the Dev and the RGW-eNB. Alternatively, the packets transmitted over
accomplish the first, it is required to place SCHC compression and the end-to-end link can use SCHC. Else, when the transmissions over
decompression entities in the eNB and in the UE for transmissions the NGW-MME or NGW-SCEF, the NGW-CSGN uses SCHC entity. For these
over the User Plane. Additionally, to handle the case of the two cases, the functions are to be standardized by 3GPP.
transmissions over Control Plane or Data Over NAS, the network SCHC
entity has to be placed in the C-SGN as well. For these two cases,
the functions are 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. In that end connection or at least up to the operator network edge. SCHC
case, the SCHC entities would be placed in the application layer of functionalities are available in the application layer of the Dev and
the terminal in one end, and either in the application servers or in the Application Servers or a broker function at the edge of the
a broker function in the edge of the operator network in the other operator network. The radio network transmits the packets as non-IP
end. For the radio network, the packets are transmitted as non-IP traffic using IP tunneling or SCEF services. Since this option does
traffic, which can be currently served utilizing IP tunneling or SCEF not necessarily require 3GPP standardization, it is possible to also
services. Since this option does not necessarily require 3GPP benefit legacy devices with SCHC by using the non-IP transmission
standardization, it is possible to also benefit legacy devices with features of the operator network.
SCHC by utilizing the non-IP transmission features of the operator
network.
Accordingly, there are four different scenarios where SCHC can be
used in the NB-IoT architecture. IP header compression on the data
transmission over User Plane, IP header compression on the optimized
transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions
of SCHC packets by IP tunneling, and non-IP transmissions of SCHC
packets by SCEF forwarding. The following sections describe each of
them in more detail. The first two scenarios refer to transmissions
using the 3GPP IP transmission capabilities and the last two refers
to transmission using the Non-IP capabilities.
5. IP based Data Transmission 5. IP based Data Transmission
5.1. SCHC over User Plane transmissions 5.1. SCHC over the Radio link
Deploying SCHC only over the radio link would require to place it as Deploying SCHC only over the radio link would require placing it as
part of the User Plane data transmission. The User Plane utilizes part of the protocol stack for data transfer between the Dev and the
the protocol stack of the Access Stratum (AS) for data transfer. AS RGW-eNB. This stack is the functional layer responsible for
(Access Stratum) is the functional layer responsible for transporting transporting data over the wireless connection and managing radio
data over wireless connection and managing radio resources. The user resources. There is support for features such as reliability,
plane AS has support for features such as reliability, segmentation segmentation, and concatenation. The transmissions use link
and concatenation. The transmissions of the AS make use of link adaptation, meaning that the system will optimize the transport
adaptation, meaning that the transport format utilized for the format used according to the radio conditions, the number of bits to
transmissions are optimized according to the radio conditions, the transmit, and the power and interference constraints. That means
number of bits to transmit and the power and interference constrains. that the number of bits transmitted over the air depends on the
That means that the number of bits transmitted over the air depends Modulation and Coding Schemes (MCS) selected. A Transport Block (TB)
of the Modulation and Coding Schemes (MCS) selected. The transmissions happen in the physical layer at network synchronized
transmissions in the physical layer happens at network synchronized intervals called Transmission Time Interval (TTI). Each Transport
intervals of times called TTI (Transmission Time Interval). The Block has a different MCS and number of bits available to transmit.
transmission of a Transport Block (TB) is completed during, at least, The MAC layer [TGPP36321] defines the Transport Blocks
one TTI. Each Transport Block has a different MCS and number of bits characteristics. The Radio link Figure 2 stack comprises the Packet
available to transmit. The Transport Blocks characteristics are Data Convergence Protocol (PDCP) [TGPP36323], Radio Link Protocol
defined by the MAC technical specification TGPP36321. The Access (RLC) [TGPP36322], Medium Access Control protocol (MAC) [TGPP36321],
Stratum for User Plane is comprised by Packet Data Convergence and the Physical Layer [TGPP36201]. The Appendix gives more details
Protocol (PDCP) TGPP36323, Radio Link Protocol (RLC) TGPP36322, of these protocols.
Medium Access Control protocol (MAC) TGPP36321 and the Physical Layer
TGPP36201. More details of this protocols are given in the 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 with RoHC [RFC5795]. Therefore SCHC entities can be deployed
deployed in similar fashion without need for major changes in the similarly without the need for significant changes in the 3GPP
3GPP specifications. specifications.
In this scenario, RLC takes care of the handling of fragmentation (if In this scenario, RLC takes care of fragmentation unless for the
transparent mode is not configured) when packets exceeds the transparent mode. When packets exceed the transport block size at
transport block size at the time of transmission. Therefore SCHC the time of transmission, SCHC fragmentation is unnecessary and
fragmentation is not needed and should not be used to avoid should not be used to avoid the additional protocol overhead. It is
additional protocol overhead. It is not common to configure RLC in not common to configure RLC in Transparent Mode for IP-based data.
Transparent Mode for IP based user plane data. But given the case in However, given the case in the future, SCHC fragmentation may be
the future, SCHC fragmentation may be used. In that case, a SCHC used. In that case, a SCHC tile would match the minimum transport
tile would match the minimum transport block size minus the PDCP and block size minus the PDCP and MAC headers.
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
CIOT/ LTE+Uu C-BS/eNB C-SGN Dev RGW-eNB NGW-CSGN
LTE eMTC
UE
Figure 3: SCHC entities placement in the 3GPP CIOT radio protocol Figure 2: SCHC over the Radio link
architecture for data over user plane
5.2. Data Over Control Plane 5.2. SCHC over No-Access Stratum (NAS)
The Non-Access Stratum (NAS), conveys mainly control signaling The NGW-MME conveys mainly control signaling between the Dev and the
between the UE and the cellular network TGPP24301. NAS is cellular network [TGPP24301]. The network transports this traffic on
transported on top of the Access Stratum (AS) already mentioned in top of the radio link.
the previous section.
NAS has been adapted to provide support for user plane data This kind of flow supports data transmissions to reduce the overhead
transmissions to reduce the overhead when transmitting infrequent when transmitting infrequent small quantities of data. This
small quantities of data. This is known as Data over NAS (DoNAS) or transmission is known as Data over No-Access Stratum (DoNAS) or
Control Plane CIoT EPS optimization. In DoNAS the UE makes use of Control Plane CIoT EPS optimization. In DoNAS, the Dev uses the pre-
the pre-established NAS security and piggyback uplink small data into established security and piggyback small uplink data into the initial
the initial NAS uplink message, and uses an additional NAS message to uplink message and uses an additional message to receive downlink
receive downlink small data response. small data response.
The data encryption from the network side is performed by the C-SGN The NGW-MME performs the data encryption from the network side in a
in a NAS 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 just establish a non-IP data), the network allocates an IP address or establishes a
direct forwarding path. DoNAS (Data over NAS) is regulated under direct forwarding path. DoNAS is regulated under rate control upon
rate control upon previous agreement, meaning that a maximum number previous agreement, meaning that a maximum number of bits per unit of
of bits per unit of time is agreed per device subscription beforehand time is agreed upon per device subscription beforehand and configured
and configured in the device. in the device.
The use of DoNAS is typically expected when a terminal in a power The system will use DoNAS when a terminal in a power-saving state
saving state requires to do a short transmission and receive an requires a short transmission and receives an acknowledgment or short
acknowledgment or short feedback from the network. Depending on the feedback from the network. Depending on the size of buffered data to
size of buffered data to transmit, the UE might be instructed to transmit, the Dev might deploy the connected mode transmissions
deploy the connected mode transmissions instead, limiting and instead, limiting and controlling the DoNAS transmissions to
controlling the DoNAS transmissions to predefined thresholds and a predefined thresholds and a good resource optimization balance for
good resource optimization balance for the terminal and the network. the terminal and the network. The support for mobility of DoNAS is
The support for mobility of DoNAS is present but produces additional present but produces additional overhead. The Appendix gives
overhead. Additional details of DoNAS are given in the Appendix. additional details of DoNAS.
5.2.1. SCHC Entities Placing 5.2.1. SCHC Entities Placing
In this scenario SCHC can be applied in the NAS protocol layer SCHC may reside in the Non-Access Stratum (NAS) protocol layer in
instead of PDCP. The same principles than for user plane this scenario. The same principles as for Radio link transmissions
transmissions applies here as well. The main difference is the apply here as well. The main difference is the physical placing of
physical placing of the SCHC entities in the network side as the the SCHC entities on the network side as the NGW-MME resides in the
C-SGN (placed in the core network) is the terminating node for NAS core network and is the terminating node for NAS instead of the eNB.
instead of the 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
CIOT/ LTE-Uu C-BS/eNB C-SGN PGW Dev RGW-eNB NGW-MME NGW-PGW
LTE eMTC
UE
*PDCP is bypassed until AS security is activated TGPP36300. *PDCP is bypassed until AS security is activated TGPP36300.
Figure 4 Figure 3
5.3. Parameters for Static Context Header Compression (SCHC) 5.3. Parameters for Static Context Header Compression (SCHC)
5.3.1. SCHC Context initialization 5.3.1. SCHC Context initialization
RRC (Radio Resource Control) protocol is the main tool used to RRC (Radio Resource Control) protocol is the main tool used to
configure the operation parameters of the AS transmissions for 3GPP configure the parameters of the Radio link. It will configure SCHC
technologies. RoHC operation is configured with this protocol and it and the static context distribution as it has made for RoHC operation
is to expect that SCHC will be configured and the static context [TGPP36323].
distributed in similar fashion for these scenarios.
5.3.2. SCHC Rules 5.3.2. SCHC Rules
The number of rules in a context are defined by the network operator The network operator in these scenarios defines the number of rules
in these scenarios. For this, the operator must be aware of the type in a context. The operator must be aware of the type of IP traffic
of IP traffic that the device will carry out. This means that the that the device will carry out. Implying that the operator might use
operator might provision sets of rules compatible with the use case provision sets of rules compatible with the use case of the device.
of the device. For devices acting as gateways of other devices For devices acting as gateways of other devices, several rules may
several rules that match the diversity of devices and protocols used match the diversity of devices and protocols used by the devices
by the devices associated to the gateway. Meanwhile than simpler associated with the gateway. Meanwhile, simpler devices (for
devices (for example an electricity meter) may have a predetermined example, an electricity meter) may have a predetermined set of fixed
set of protocols and parameters fixed. Additionally, the deployment protocols and parameters. Additionally, the deployment of IPv4
of IPV4 addresses in addition to IPV6 may force to provision separate addresses and IPv6 may force different rules to deal with each case.
rules to deal with each of the cases.
5.3.3. Rule ID 5.3.3. Rule ID
For these transmission scenarios in NB-IoT, a reasonable assumption There is a reasonable assumption of 9 bytes of radio protocol
of 9 bytes of radio protocol overhead can be expected. PDCP 5 bytes overhead for these transmission scenarios in NB-IoT, where PDCP uses
due to header and integrity protection, and 4 bytes of RLC and MAC. 5 bytes due to header and integrity protection, and RLC and MAC use 4
The minimum physical Transport Block (TB) that can withhold this bytes. The minimum physical Transport Blocks (TB) that can withhold
overhead value according to 3GPP Release 15 specifications are: 88, this overhead value according to 3GPP Release 15 specifications are
104, 120 and 144 bits. If it is wished to optimize the number of 88, 104, 120, and 144 bits. A transmission optimization may require
transmissions of a very small application packet so that in some only one physical layer transmission. SCHC overhead should not
cases can be transmitted using only one physical layer transmission, exceed the available number of effective bits of the smallest
then the SCHC overhead should not exceed the available number of bits physical TB available. The packets handled by 3GPP networks are
of the smallest utile physical TB available. The packets handled by byte-aligned, and therefore the minimum payload possible (including
3GPP networks are byte-aligned, and therefore the minimum payload padding) is 8 bits. Therefore in order to use the smallest TB, the
possible (including padding) is 8 bits. Therefore in order to maximum SCHC header is 12 bits. These 12 bits must include the
utilize the smallest TB the maximum SCHC is 8 bits. This must Compression Residue in addition to the Rule ID. On the other hand,
include the Compression Residue in addition to the Rule ID. In the more complex NB-IoT devices (such as a capillarity gateway) might
other hand, it is possible that more complex NB-IoT devices (such as require additional bits to handle the variety and multiple parameters
a capillarity gateway) might require additional bits to handle the of higher-layer protocols deployed. In that sense, the operator may
variety and multiple parameters the of higher layer protocols want to have flexibility on the number and type of rules supported by
deployed. In that sense, the operator may want to have flexibility each device independently, and consequently, these scenarios require
on the number and type of rules supported by each device a configurable value. The configuration may be part of the operation
independently, and consequently a configurable value is preferred for profile agreed together with the content distribution. The Rule ID
these scenarios. The configuration may be set as part of the field size may range from 2 bits, resulting in 4 rules to an 8 bits
operation profile agreed together with the context distribution. The value that would yield up to 256 rules that can be used together with
Rule Id field size may range for example from 2 bits resulting in 4 the operators and seems quite a reasonable maximum limit even for a
rules to a 8 bits value that would yield up to 256 rules which can be device acting as a NAT. More bits could be configured, but it should
used together with the operators and seems quite a reasonable maximum consider the byte-alignment of the expected Compression Residue. In
limit even for a device acting as a NAT. More bits could be the minimum TB size case, 2 bits of Rule Id leave only 6 bits
configured, but it should take in account the byte-alignment of the available for Compression Residue.
expected Compression Residue too. In the minimum TB size case, 2
bits size of Rule Id leave only 6 bits available for Compression
Residue.
5.3.4. SCHC MAX_PACKET_SIZE 5.3.4. SCHC MAX_PACKET_SIZE
The Access Stratum can handle the fragmentation of SCHC packets if The Radio Link can handle the fragmentation of SCHC packets if
needed including reliability. Hence the packet size is limited by needed, including reliability. Hence the packet size is limited by
the MTU possible to be handled by the AS radio protocols that the MTU handled by the radio protocols that correspond to 1600 bytes
corresponds to 1600 bytes for 3GPP Release 15. for 3GPP Release 15.
5.3.5. Fragmentation 5.3.5. Fragmentation
For these scenarios the SCHC fragmentation functions are recommend to For these scenarios, the SCHC fragmentation functions are disabled.
be disabled. The RLC layer of NB-IoT can segment packets in suitable The RLC layer of NB-IoT can segment packets in suitable units that
units that fit the selected transport blocks for transmissions of the fit the selected transport blocks for transmissions of the physical
physical layer. The selection of the blocks is done according to the layer. The blocks selection is made according to the link adaptation
input of the link adaptation function in the MAC layer and the input function in the MAC layer and the quantity of data in the
quantity of data in the buffer. The link adaptation layer may buffer. The link adaptation layer may produce different results at
produce different results at each Time Transmission Interval (TTI) each Time Transmission Interval (TTI), resulting in varying physical
resulting in varying physical transport blocks that depends of the transport blocks that depend on the network load, interference,
network load, interference and number of bits to be transmitted and number of bits transmitted, and QoS. Even if setting a value that
QoS. Even if setting a value that allows the construction of data allows the construction of data units following the SCHC tiles
units following SCHC tiles principle, the protocol overhead may be principle, the protocol overhead may be greater or equal than
greater or equal than allowing the AS radio protocols to take care of allowing the Radio link protocols to take care of the fragmentation
the fragmentation natively. natively.
5.3.5.1. Fragmentation in Transparent Mode 5.3.5.1. Fragmentation in Transparent Mode
If RLC is configured to operate in Transparent Mode, there could be a If RLC operates in Transparent Mode, there could be a case to
case to activate a fragmentation function together with a light activate a fragmentation function together with a light reliability
reliability function such as the ACK-Always mode. In practice , it function such as the ACK-Always mode. In practice, it is uncommon to
is very rare to transmit user plane data using this configuration and transmit radio link data using this configuration. It mainly targets
it is mainly targeting control plane transmissions. In those cases signaling transmissions. In those cases, the MAC layer mechanisms
the reliability is normally ensured by MAC based mechanisms, such as ensure reliability, such as repetitions or automatic retransmissions,
repetitions or automatic retransmissions, and additional reliability and additional reliability might only generate protocol overhead.
might only generate protocol overhead.
In future operations, it could be devised the utilization of SCHC to SCHC may reduce radio network protocols overhead in future
reduce radio network protocols overhead and support the reliability operations, support reliable transmissions, and transmit small data
of the transmissions, and targeting small data with the fewer with fewer possible transmissions by using fixed or limited transport
possible transmissions. This could be realized by using fixed or blocks compatible with the tiling SCHC fragmentation handling.
limited set of transport blocks compatible with the tiling SCHC
fragmentation handling.
6. Non-IP based Data Transmission 6. 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
possibility of transmitting SCHC packets compressed by the transmission of SCHC packets compressed by the application layer.
application layer. The packets can be delivered by means of IP- The packets can be delivered using IP-tunnels to the 3GPP network or
tunnels to the 3GPP network or using SCEF functions (i.e., API NGW-SCEF functions (i.e., API calls). In both cases, as compression
calls). In both cases the packet IP is not understood by the 3GPP occurs before transmission, the network will not understand the
network since it is already compressed and the network does not has packet, and the network does not have context information of this
information of the context used for compression. Therefore the compression. Therefore the network will treat the packet as Non-IP
network will treat the packet as a Non-IP traffic and deliver it to traffic and deliver it to the Dev without any other stack element,
the UE without any other stack element, directly under the L2. directly under the L2.
6.1. SCHC Entities Placing 6.1. SCHC Entities Placing
In the two scenarios using NIDD, SCHC entities are located almost in In the two scenarios using End-to-End compression, SCHC entities are
top of the stack. In the terminal, it may be implemented by a located almost on top of the stack. In the Dev, an application using
application utilizing the NB-IoT connectivity services. In the the NB-IoT connectivity services may implement SCHC and the
network side, the SCHC entities are located in the Application Server Application Server. The IP tunneling scenario requires that the
(AS). The IP tunneling scenario requires that the Application Server Application Server send the compressed packet over an IP connection
sends the compressed packet over an IP connection that is terminated terminated by the 3GPP core network. If the transmission uses the
by the 3GPP core network. If instead the SCEF services are used, NGW-SCEF services, it is possible to utilize an API call to transfer
then it is possible to utilize a API call to transfer the SCHC the SCHC packets between the core network and the Application Server.
packets between the core network and the AS, also an IP tunnel could Also, an IP tunnel could be established by the Application Server if
be established by the AS, if negotiated with the SCEF. negotiated with the 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 5: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP Figure 4: SCHC entities placed when using Non-IP Delivery (NIDD) 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 application layer handles the static context; consequently, the
consequently the contexts are required to be distributed according to context distribution must be according to the application's
the applications own capabilities, perhaps utilizing IP data capabilities, perhaps utilizing IP data transmissions up to context
transmissions up to context initialization. Also the same IP initialization. Also, the static contexts delivery may use the same
tunneling or SCEF services used later for the SCHC packets transport IP tunneling or NGW-SCEF services used later for the SCHC packets
may be used by the applications in both ends to deliver the static transport.
contexts to be used.
6.2.2. SCHC Rules 6.2.2. SCHC Rules
Even when the transmissions content are not visible for the 3GPP Even when the transmission content is not visible for the 3GPP
network, the same limitations than for IP based data transmissions network, the same limitations as for IP-based data transmissions
applies in these scenarios in terms of aiming to use the minimum applies in these scenarios in terms of aiming to use the minimum
number of transmission and minimize the protocol overhead. number of transmission and minimize the protocol overhead.
6.2.3. Rule ID 6.2.3. Rule ID
Similarly to the case of IP transmissions, the Rule ID size can be Similar to the case of IP transmissions, the Rule ID size can be
dynamically set prior the context delivery. For example negotiated dynamically set before the context delivery. For example, negotiated
between the applications when choosing a profile according to the between the applications when choosing a profile according to the
type of traffic and type of application deployed. Same type of traffic and application deployed. The same considerations
considerations related to the transport block size and performance related to the transport block size and performance mentioned for the
mentioned for the IP type of traffic has to be follow when choosing a IP type of traffic must be followed when choosing a size value for
size value for the Rule ID field. the Rule ID field.
6.2.4. SCHC MAX_PACKET_SIZE 6.2.4. SCHC MAX_PACKET_SIZE
In these scenarios the maximum recommended MTU size that applies is In these scenarios, the maximum recommended MTU size that applies is
1358 Bytes, since the SCHC packets (and fragments) are traversing the 1358 Bytes since the SCHC packets (and fragments) are traversing the
whole 3GPP network infrastructure (core and radio), and not only the whole 3GPP network infrastructure (core and radio), not only the
radio as the IP transmissions case. radio as the IP transmissions case.
6.3. Fragmentation 6.3. Fragmentation
In principle the fragmentation function should be activated for In principle, packets larger than 1358 bytes need the fragmentation
packets greater than 1358 Bytes. Since the 3GPP reliability function. Since the 3GPP uses reliability functions, the No-ACK
functions take great deal care of it, for simple point to point fragmentation mode may be enough in point-to-point connections.
connections may be enough a NO-ACK mode. Nevertheless additional Nevertheless, additional considerations are described below for more
considerations for more complex cases are mentioned in the next complex cases.
subsection to be taken in account.
6.3.1. Fragmentation modes 6.3.1. Fragmentation modes
Depending of the QoS that has been assigned to the packets, it is A global service assigns a QoS to the packets depending on the
possible that packets are lost before they arrive to 3GPP radio billing. Packets with very low QoS may get lost before they arrive
network transmission, for example in between the links of a in the 3GPP radio network transmission, for example, in between the
capillarity gateway, or due to buffer overflow handling in a backhaul links of a capillarity gateway or due to buffer overflow handling in
connection. In consequence, it is possible to secure additional a backhaul connection. The use of SCHC fragmentation with the ACK-
reliability on the packets transmitted with a small trade-off on on-Error mode is recommended to secure additional reliability on the
additional transmissions to signal the packets arrival indication packets transmitted with a small trade-off on additional
end-to-end if no transport protocol takes care of retransmission. To transmissions to signal the end-to-end arrival of the packets if no
achieve this, the packets fragmentation is activated with the ACK-on- transport protocol takes care of retransmission.
Error mode enabled. In some cases, it is even desirable to keep Also, the ACK-on-Error mode is even desirable to keep track of all
track of all the SCHC packets delivered, in that case, the the SCHC packets delivered. In that case, the fragmentation function
fragmentation function could be active for all packets transmitted by could be active for all packets transmitted by the applications.
the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on- SCHC ACK-on-Error fragmentation may be active for the transmission of
Error mode. In the NAS stratum, the use of only fragmentation when a non-IP packets on the NGW-MME. If these packets are considering to
non-IP packet is transmitted is possible if this packet is considered use SCHC with the RuleID for non-compressing packets as {RFC8724}
as a SCHC packet and is identifyed using the RuleID for non- allows it.
compressing packets as {RFC8724} allows it, depending on the
application an ACK-onError mode may be used.
6.3.2. Fragmentation Parameters 6.3.2. Fragmentation Parameters
The Fragmentation Rule ID is given when choosing the profile SCHC profile with the fragmentation mode will have specific Rules.
according to the fragmentation mode, 1 bit can be used to recognize SCHC defines the Rule ID according to the fragmentation mode; 2 bits
each mode. could recognize all the fragmentation modes or another solution
depending on the Rules implementation.
To adapt SCHC to the NB-IoT constraints, two configuration are SCHC parametrization considers that NBIoT aligns the bit and uses
proposed to fill the best the transfer block (TB). The Header size padding and the size of the Transfer Block. SCHC will try to reduce
needs to be multiple of 4 and the Tiles can keep a fix value of 4 or padding to optimize the compression of the information. The Header
8 bits to avoid the need of padding. 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.
o 8 bits-Header_size configuration, with the size of the header o For Transfer Blocks smaller than 300bits: 8 bits-Header_size
fields as follow: Rule ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 configuration, with the size of the header fields as follows: Rule
bits. This configuration may ne used with TB less than 300 bits. ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits.
o 16 bits-Header_size configuration, with the size of the header o For Transfer Blocks bigger than 300 bits: 16 bits-Header_size
fields as follow: Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 configuration, with the size of the header fields as follows:
bits, W 2 or 3 bits. This configuration may be used with TB above Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2 or 3 bits.
300 bits.
The IoT devices communicates with small data transfer and have a The IoT devices communicate with small data transfer and have a
battery life of 10 years. To minise the power consumption these battery life of 10 years. These devices use the Power Save Mode and
devices use the Power Save Mode and the Idle Mode DRX which govern the Idle Mode DRX, which govern how often the device wakes up, stays
how often the device wakes up, stays up and are reachable. The up, and is reachable. Table 10.5.163a in {3GPP-TS_24.088} specifies
Table 10.5.163a in {3GPP-TS_24.088} specifies a range for the radio a range for the radio timers as N to 3N in increments of one where
timers as N to 3N in increments of one where the units of N can be 1 the units of N can be 1 hour or 10 hours. To adapt SCHC to the NB-
hour or 10 hours. To adapt SCHC to the NB-IoT activities, the IoT activities, the Inactivity Timer and the Retransmission Timer may
Innactivity Timer may be above 1h or 10h and the Retransmission Timer use these limits.
may be below than 1h or 10h.
7. Padding 7. Padding
NB-IoT and 3GPP wireless access, in general, assumes byte aligned NB-IoT and 3GPP wireless access, in general, assumes byte-aligned
payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits,
and the treatment of padding should use this value accordingly. and the padding treatment should use this value accordingly.
8. Security considerations 8. Security considerations
3GPP access security is specified in (TGPP33203). 3GPP access security is specified in [TGPP33203].
9. 3GPP References 9. 3GPP References
o TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture o TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture
enhancements for Cellular Internet of Things", 2016. enhancements for Cellular Internet of Things", 2016.
o TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security o TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
for IP-based services", 2016. for IP-based services", 2016.
o TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial o TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial
skipping to change at page 16, line 33 skipping to change at page 14, line 41
o TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer o TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer
3 specification;Core network protocols; Stage 3", 2015. 3 specification;Core network protocols; Stage 3", 2015.
10. Appendix 10. Appendix
10.1. NB-IoT User Plane protocol architecture 10.1. NB-IoT User Plane protocol architecture
10.1.1. Packet Data Convergence Protocol (PDCP) 10.1.1. Packet Data Convergence Protocol (PDCP)
Each of the Radio Bearers (RB) are associated with one PDCP entity. Each of the Radio Bearers (RB) is associated with one PDCP entity.
And a PDCP entity is associated with one or two RLC entities Moreover, a PDCP entity is associated with one or two RLC entities
depending of 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 either control the RB and RLC mode used. A PDCP entity is associated with either a
plane or user plane which independent configuration and functions. control plane or a user plane with independent configuration and
The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. functions. The maximum supported size for NB-IoT of a PDCP SDU is
The main services and functions of the PDCP sublayer for NB-IoT for 1600 octets. The primary services and functions of the PDCP sublayer
the user plane include: for NB-IoT for the user plane include:
o Header compression and decompression by means of ROHC (Robust o Header compression and decompression using ROHC (Robust Header
Header Compression) Compression)
o Transfer of user and control data to higher and lower layers o Transfer of user and control data to higher and lower layers
o Duplicate detection of lower layer SDUs when re-establishing o Duplicate detection of lower layer SDUs when re-establishing
connection (when RLC with Acknowledge Mode in use for User Plane connection (when RLC with Acknowledge Mode in use for User Plane
only) only)
o Ciphering and deciphering o Ciphering and deciphering
o Timer-based SDU discard in uplink o 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 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 sets of entities,
in each direction (downlink and uplink) must be configured and they one in each direction (downlink and uplink), must be configured and
are effectively peered to each other. The peering allows the effectively peered to each other. The peering allows the
transmission of control packets (ex., status reports) between transmission of control packets (ex., status reports) between
entities. RLC can be configured for data transfer in one of the entities. RLC can be configured for data transfer in one of the
following modes: following modes:
o Transparent Mode (TM). In this mode RLC do not segment or o Transparent Mode (TM). RLC does not segment or concatenate SDUs
concatenate SDUs from higher layers and do not include any header from higher layers in this mode and does not include any header to
to the payload. When acting as a transmitter, RLC receives SDUs the payload. RLC receives SDUs from upper layers when acting as a
from upper layers and transmit directly to its flow RLC receiver transmitter and transmits directly to its flow RLC receiver via
via lower layers. Similarly, an TM RLC receiver would only lower layers. Similarly, a TM RLC receiver would only deliver
deliver without additional processing the packets to higher layers without processing the packets to higher layers upon reception.
upon reception.
o 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 RLC packet's size
packet depends of the indication given at a particular depends on the indication given at a particular transmission
transmission opportunity by the lower layer (MAC) and are octets opportunity by the lower layer (MAC) and is octets aligned. The
aligned. The packet delivery to the receiver do not include packet delivery to the receiver does not include reliability
support for reliability and the lost of a segment from a packet support, and the loss of a segment from a packet means a complete
means a whole packet loss. Also in case of lower layer packet loss. Also, in the case of lower layer retransmissions,
retransmissions there is no support for re-segmentation in case of there is no support for re-segmentation in case of change of the
change of the radio conditions triggering the selection of a radio conditions triggering the selection of a smaller transport
smaller transport block. Additionally it provides PDU duplication block. Additionally, it provides PDU duplication detection and
detection and discard, reordering of out of sequence and loss discards, reordering of out-of-sequence, and loss detection.
detection.
o Acknowledged Mode (AM). Additional to the same functions o Acknowledged Mode (AM). In addition to the same functions
supported from UM, this mode also adds a moving windows based supported by UM, this mode also adds a moving windows-based
reliability service on top of the lower layer services. It also reliability service on top of the lower layer services. It also
provides support for 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 is needed. Protocol error Report and trigger retransmissions. This model also supports
detection is also supported by this mode. The mode uses depends protocol error detection. The mode used depends on the operator
of the operator configuration for the type of data to be configuration for the type of data to be transmitted. For
transmitted. For example, data transmissions supporting mobility example, data transmissions supporting mobility or requiring high
or requiring high reliability would be most likely configured reliability would be most likely configured using AM. Meanwhile,
using AM, meanwhile streaming and real time data would be map to a streaming and real-time data would be mapped to a UM
UM configuration. configuration.
10.1.3. Medium Access Control (MAC) 10.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 the efficiency of data transmission. MAC also available to maximize data transmission efficiency. MAC also
provides error correction and reliability support by means of 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
piggyback control elements when possible additional to the higher piggyback control elements when possible and the higher layers data.
layers data.
<Max. 1600 bytes> <Max. 1600 bytes>
+---+ +---+ +------+ +---+ +---+ +------+
Application |AP1| |AP1| | AP2 | Application |AP1| |AP1| | AP2 |
(IP/non-IP) |PDU| |PDU| | PDU | (IP/non-IP) |PDU| |PDU| | PDU |
+---+ +---+ +------+ +---+ +---+ +------+
| | | | | | | | | | | |
PDCP +--------+ +--------+ +-----------+ PDCP +--------+ +--------+ +-----------+
|PDCP|AP1| |PDCP|AP1| |PDCP| AP2 | |PDCP|AP1| |PDCP|AP1| |PDCP| AP2 |
|Head|PDU| |Head|PDU| |Head| PDU | |Head|PDU| |Head|PDU| |Head| PDU |
skipping to change at page 18, line 48 skipping to change at page 17, line 32
/ / / _/ _// _/ _/ / 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 5: Example of User Plane packet encapsulation for two
transport blocks transport blocks
10.2. NB-IoT Data over NAS (DoNAS) 10.2. NB-IoT Data over NAS (DoNAS)
The AS protocol stack used by DoNAS is somehow special. Since the The Access Stratum (AS) protocol stack used by DoNAS is somehow
security associations are not established yet in the radio network, particular. Since the security associations are not established yet
to reduce the protocol overhead, PDCP (Packet Data Convergence in the radio network, to reduce the protocol overhead, PDCP (Packet
Protocol) is bypassed until AS security is activated. RLC (Radio Data Convergence Protocol) is bypassed until AS security is
Link Control protocol) is configured by default in AM mode, but activated. RLC (Radio Link Control protocol) uses by default the AM
depending of the features supported by the network and the terminal mode, but depending on the network's features and the terminal, it
it may be configured in other modes by the network operator. For may change to other modes by the network operator. For example, the
example, the transparent mode does not add any header or does not transparent mode does not add any header or process the payload to
process the payload in any way reducing the overhead, but the MTU reduce the overhead, but the MTU would be limited by the transport
would be limited by the transport block used to transmit the data block used to transmit the data, which is a couple of thousand bits
which is couple of thousand of bits maximum. If UM (only Release 15 maximum. If UM (only Release 15 compatible terminals) is used, the
compatible terminals) is used, the RLC mechanisms of reliability is RLC mechanisms of reliability are disabled, and only the reliability
disabled and only the reliability provided by the MAC layer by Hybrid provided by the MAC layer by Hybrid Automatic Repeat reQuest (HARQ)
Automatic Repeat reQuest (HARQ) is available. In this case, the is available. In this case, the protocol overhead might be smaller
protocol overhead might be smaller than for the AM case because the than the AM case because of the lack of status reporting but with the
lack of status reporting but with the same support for segmentation same support for segmentation up to 16000 Bytes. NAS packets are
up to 16000 Bytes. NAS packet are encapsulated within a RRC (Radio encapsulated within an RRC (Radio Resource Control) TGPP36331
Resource Control) TGPP36331 message. message.
Depending of the data type indication signaled (IP or non-IP data), Depending on 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 establishes 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 upon 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 a short transmission and receiving an
acknowledgment or short feedback from the network. Depending of the acknowledgment or short feedback from the network. Depending on the
size of buffered data to transmit, the UE might be instructed to size of buffered data to transmit, the UE might be instructed to
deploy the connected mode transmissions instead, limiting and deploy the connected mode transmissions instead, limiting and
controlling the DoNAS transmissions to predefined thresholds and a controlling the DoNAS transmissions to predefined thresholds and a
good resource optimization balance for the terminal and the network. good resource optimization balance for the terminal the network. The
The support for mobility of DoNAS is present but produces additional support for mobility of DoNAS is present but produces additional
overhead. overhead.
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| | | | | | +-----------------+ | | | | | | +-----------------+
| UE | | C-BS | | C-SGN | |Roaming Scenarios| | UE | | C-BS | | C-SGN | |Roaming Scenarios|
+----|---+ +--------+ +--------+ | +--------+ | +----|---+ +--------+ +--------+ | +--------+ |
| | | | | | | | | | | | | |
+----------------|------------|+ | | P-GW | | +----------------|------------|+ | | P-GW | |
| Attach | | +--------+ | | Attach | | +--------+ |
+------------------------------+ | | | +------------------------------+ | | |
skipping to change at page 20, line 49 skipping to change at page 19, line 49
| |message | | | | | |message | | | |
| |<-----------| | | | | |<-----------| | | |
+-----------------------+ | | | | +-----------------------+ | | | |
|Small Data Delivery, | | | | | |Small Data Delivery, | | | | |
|RRC connection release | | | | | |RRC connection release | | | | |
+-----------------------+ | | | | +-----------------------+ | | | |
| | | |
| | | |
+-----------------+ +-----------------+
Figure 7: DoNAS transmission sequence from an Uplink initiated access Figure 6: DoNAS transmission sequence from an Uplink initiated access
+---+ +---+ +---+ +----+ +---+ +---+ +---+ +----+
Application |AP1| |AP1| |AP2| |AP2 | Application |AP1| |AP1| |AP2| |AP2 |
(IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU | (IP/non-IP) |PDU| |PDU| |PDU| ............... |PDU |
+---+ +---+ +---+ +----+ +---+ +---+ +---+ +----+
| |/ / | \ | | | |/ / | \ | |
NAS /RRC +--------+---|---+----+ +---------+ NAS /RRC +--------+---|---+----+ +---------+
|NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 | |NAS/|AP1|AP1|AP2|NAS/| |NAS/|AP2 |
|RRC |PDU|PDU|PDU|RRC | |RRC |PDU | |RRC |PDU|PDU|PDU|RRC | |RRC |PDU |
+--------+-|-+---+----+ +---------| +--------+-|-+---+----+ +---------|
| |\ | | | | |\ | | |
skipping to change at page 21, line 32 skipping to change at page 20, 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 over Figure 7: Example of User Plane packet encapsulation for Data over
NAS NAS
11. Normative References 11. Normative References
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010, <https://www.rfc- DOI 10.17487/RFC5795, March 2010, <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)
 End of changes. 88 change blocks. 
514 lines changed or deleted 431 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/