rfc9391.original   rfc9391.txt 
lpwan Working Group E. Ramos Internet Engineering Task Force (IETF) E. Ramos
Internet-Draft Ericsson Request for Comments: 9391 Ericsson
Intended status: Standards Track A. Minaburo Category: Standards Track A. Minaburo
Expires: 18 June 2023 Acklio ISSN: 2070-1721 Acklio
15 December 2022 April 2023
Static Context Header Compression over Narrowband Internet of Things Static Context Header Compression over Narrowband Internet of Things
draft-ietf-lpwan-schc-over-nbiot-15
Abstract Abstract
This document describes Static Context Header Compression and This document describes Static Context Header Compression and
Fragmentation (SCHC) specifications, RFC 8724 and RFC 8824, fragmentation (SCHC) specifications, RFCs 8724 and 8824, in
combination with the 3rd Generation Partnership Project (3GPP) and combination with the 3rd Generation Partnership Project (3GPP) and
the Narrowband Internet of Things (NB-IoT). the Narrowband Internet of Things (NB-IoT).
This document has two parts. One normative to specify the use of This document has two parts: one normative part that specifies the
SCHC over NB-IoT. And one informational, which recommends some use of SCHC over NB-IoT and one informational part that recommends
values if 3GPP wanted to use SCHC inside their architectures. some values if 3GPP wants to use SCHC inside their architectures.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 18 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9391.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology
4. NB-IoT Architecture . . . . . . . . . . . . . . . . . . . . . 5 4. NB-IoT Architecture
5. Data Transmission in the 3GPP Architecture . . . . . . . . . 6 5. Data Transmission in the 3GPP Architecture
5.1. Normative Part. . . . . . . . . . . . . . . . . . . . . . 7 5.1. Normative Scenarios
5.1.1. SCHC over Non-IP Data Delivery (NIDD) . . . . . . . . 7 5.1.1. SCHC over Non-IP Data Delivery (NIDD)
5.2. Informational Part. . . . . . . . . . . . . . . . . . . . 10 5.2. Informational Scenarios
5.2.1. Use of SCHC over the Radio link . . . . . . . . . . . 11 5.2.1. Use of SCHC over the Radio Link
5.2.2. Use of SCHC over the Non-Access Stratum (NAS) . . . . 12 5.2.2. Use of SCHC over the Non-Access Stratum (NAS)
5.2.3. Parameters for Static Context Header Compression and 5.2.3. Parameters for Static Context Header Compression and
Fragmentation (SCHC) for the Radio link and DONAS Fragmentation (SCHC) for the Radio Link and DoNAS Use
use-cases. . . . . . . . . . . . . . . . . . . . . . 13 Cases
6. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Padding
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations
8. Security considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References
Appendix A. NB-IoT User Plane protocol architecture . . . . . . 17 Appendix A. NB-IoT User Plane Protocol Architecture
A.1. Packet Data Convergence Protocol (PDCP) TS36323 . . . . . 18 A.1. Packet Data Convergence Protocol (PDCP)
A.2. Radio Link Protocol (RLC) TS36322 . . . . . . . . . . . . 18 A.2. Radio Link Protocol (RLC)
A.3. Medium Access Control (MAC) TR36321 . . . . . . . . . . . 19 A.3. Medium Access Control (MAC)
Appendix B. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . 20 Appendix B. NB-IoT Data over NAS (DoNAS)
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 23 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
1. Introduction 1. Introduction
This document defines the scenarios where the Static Context Header This document defines scenarios where Static Context Header
Compression and fragmentation (SCHC) [RFC8724] and [RFC8824] are Compression and fragmentation (SCHC) [RFC8724] [RFC8824] are suitable
suitable for 3rd Generation Partnership Project (3GPP) and Narrowband for 3rd Generation Partnership Project (3GPP) and Narrowband Internet
Internet of Things (NB-IoT) protocol stacks. of Things (NB-IoT) protocol stacks.
In the 3GPP and the NB-IoT networks, header compression efficiently In the 3GPP and the NB-IoT networks, header compression efficiently
brings Internet connectivity to the Device-User Equipment (Dev-UE), brings Internet connectivity to the Device UE (Dev-UE), the radio
the radio (RGW-eNB) and network (NGW-MME) gateways, and the (RGW-eNB) and network (NGW-MME) gateways, and the Application Server.
Application Server. This document describes the SCHC parameters This document describes the SCHC parameters supporting SCHC over the
supporting static context header compression and fragmentation over NB-IoT architecture.
the NB-IoT architecture.
This document assumes functionality for NB-IoT of 3GPP release 15 This document assumes functionality for NB-IoT of 3GPP release 15
[_3GPPR15]. Otherwise, the text explicitly mentions other versions' [R15-3GPP]. Otherwise, the text explicitly mentions other versions'
functionality. functionality.
This document has two parts, a standard end-to-end scenario This document has two parts: normative end-to-end scenarios
describing how any application must use SCHC over the 3GPP public describing how any application must use SCHC over the 3GPP public
service. And informational scenarios about how 3GPP could use SCHC service and informational scenarios about how 3GPP could use SCHC in
in their protocol stack network. their protocol stack network.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
This document will follow the terms defined in [RFC8724], in This document will follow the terms defined in [RFC8724], [RFC8376],
[RFC8376], and the [TR23720]. and [TR23720].
* Capillary Gateway. A capillary gateway facilitates seamless Capillary Gateway: Facilitates seamless integration because it has
integration because it has wide area connectivity through cellular wide-area connectivity through cellular and provides wide-area
and provides wide area access as a proxy to other devices using access as a proxy to other devices using LAN technologies (BT, Wi-
LAN technologies (BT, Wi-Fi, Zigbee, or others.) Fi, Zigbee, or others).
* CIoT EPS. Cellular IoT Evolved Packet System. It is a Cellular IoT Evolved Packet System (CIoT EPS): A functionality to
functionality to improve the support of small data transfers. improve the support of small data transfers.
* Dev-UE. Device - User Equipment. Device UE (Dev-UE): As defined in [RFC8376], Section 3.
* DoNAS. Data over Non-Access Stratum. Data over Non-Access Stratum (DoNAS): Sending user data within
signaling messages over the NAS functional layer.
* EPC. Evolved Packet Connectivity. Core network of 3GPP LTE Evolved Packet Connectivity (EPC): Core network of 3GPP LTE systems.
systems.
* EUTRAN. Evolved Universal Terrestrial Radio Access Network. Evolved Universal Terrestrial Radio Access Network (EUTRAN): Radio
Radio access network of LTE-based systems. access network of LTE-based systems.
* HARQ. Hybrid Automatic Repeat Request. Hybrid Automatic Repeat reQuest (HARQ): A combination of high-rate
Forward Error Correction (FEC) and Automatic Repeat reQuest (ARQ)
error control.
* HSS. Home Subscriber Server. It is a database that contains Home Subscriber Server (HSS): A database that contains users'
users' subscription data, including data needed for mobility subscription data, including data needed for mobility management.
management.
* IP address. IPv6 or IPv4 address used. IP address: IPv6 or IPv4 address used.
* IWK-SCEF. InterWorking Service Capabilities Exposure Function. InterWorking Service Capabilities Exposure Function (IWK-SCEF): Used
It is used in roaming scenarios, it is located in the Visited PLMN in roaming scenarios, is located in the Visited PLMN, and serves
and serves for interconnection with the SCEF of the Home PLMN. for interconnection with the Service Capabilities Exposure
Function (SCEF) of the Home PLMN.
* L2. Layer-2 in the 3GPP architectures it includes MAC, RLC and Layer 2 (L2): L2 in the 3GPP architectures includes MAC, RLC, and
PDCP layers see Appendix A. PDCP layers; see Appendix A.
* LCID. Logical Channel ID. Is the logical channel instance of the Logical Channel ID (LCID): The logical channel instance of the
corresponding MAC SDU. corresponding MAC SDU.
* MAC. Medium Access Control protocol, part of L2. Medium Access Control (MAC) protocol: Part of L2.
* NAS. Non-Access Stratum. Non-Access Stratum (NAS): Functional layer for signaling messages
that establishes communication sessions and maintains the
communication while the user moves.
* NB-IoT. Narrowband IoT. A 3GPP LPWAN technology based on the LTE Narrowband IoT (NB-IoT): A 3GPP Low-Power WAN (LPWAN) technology
architecture but with additional optimization for IoT and using a based on the LTE architecture but with additional optimization for
Narrowband spectrum frequency. IoT and using a Narrowband spectrum frequency.
* NGW-CSGN. Network Gateway - CIoT Serving Gateway Node. Network Gateway - CIoT Serving Gateway Node (NGW-CSGN): As defined
in [RFC8376], Section 3.
* NGW-CSGW. Network Gateway - Cellular Serving Gateway. It routes Network Gateway - Cellular Serving Gateway (NGW-CSGW): Routes and
and forwards the user data packets through the access network. forwards the user data packets through the access network.
* NGW-MME. Network Gateway - Mobility Management Entity. An entity Network Gateway - Mobility Management Entity (NGW-MME): An entity in
in charge of handling mobility of the Dev-UE. charge of handling mobility of the Dev-UE.
* NGW-PGW. Network Gateway - Packet Data Network Gateway. An Network Gateway - Packet Data Network Gateway (NGW-PGW): An
interface between the internal with the external network. interface between the internal and external network.
* NGW-SCEF. Network Gateway - Service Capability Exposure Function. Network Gateway - Service Capability Exposure Function (NGW-SCEF): E
EPC node for exposure of 3GPP network service capabilities to 3rd PC node for exposure of 3GPP network service capabilities to third
party applications. party applications.
* NIDD. Non-IP Data Delivery. Non-IP Data Delivery (NIDD): End-to-end communication between the UE
and the Application Server.
* PDCP. Packet Data Convergence Protocol part of L2. Packet Data Convergence Protocol (PDCP): Part of L2.
* PLMN. Public Land Mobile Network. Combination of wireless Public Land-based Mobile Network (PLMN): A combination of wireless
communication services offered by a specific operator. communication services offered by a specific operator.
* PDU. Protocol Data Unit. A data packet including headers that Protocol Data Unit (PDU): A data packet including headers that are
are transmitted between entities through a protocol. transmitted between entities through a protocol.
* RLC. Radio Link Protocol part of L2. Radio Link Protocol (RLC): Part of L2.
* RGW-eNB. Radio Gateway - evolved Node B. Base Station that Radio Gateway - evolved Node B (RGW-eNB): Base Station that controls
controls the UE. the UE.
* SDU. Service Data Unit. A data packet (PDU) from higher layer Service Data Unit (SDU): 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. PDUs.
4. NB-IoT Architecture 4. NB-IoT Architecture
The Narrowband Internet of Things (NB-IoT) architecture has a complex The NB-IoT architecture has a complex structure. It relies on
structure. It relies on different NGWs from different providers. It different Network Gateways (NGWs) from different providers. It can
can send data via different paths, each with different send data via different paths, each with different characteristics in
characteristics in terms of bandwidth, acknowledgments, and layer-2 terms of bandwidth, acknowledgments, and L2 reliability and
reliability and segmentation. segmentation.
Figure 1 shows this architecture, where the Network Gateway Cellular Figure 1 shows this architecture, where the Network Gateway -
Internet of Things Serving Gateway Node (NGW-CSGN) optimizes co- Cellular IoT Serving Gateway Node (NGW-CSGN) optimizes co-locating
locating entities in different paths. For example, a Dev-UE using entities in different paths. For example, a Dev-UE using the path
the path formed by the Network Gateway Mobility Management Entity formed by the Network Gateway - Mobility Management Entity (NGW-MME),
(NGW-MME), the NGW-CSGW, and Network Gateway Packet Data Network the NGW-CSGW, and the Network Gateway - Packet Data Network Gateway
Gateway (NGW-PGW) may get a limited bandwidth transmission from a few (NGW-PGW) may get a limited bandwidth transmission from a few bytes/s
bytes/s to one thousand bytes/s only. to one thousand bytes/s only.
Another node introduced in the NB-IoT 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. The Open Mobile Alliance (OMA) external to the network operator. The Open Mobile Alliance (OMA)
[OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define
the northbound APIs. [TS23222] defines architecture for the common the northbound APIs. [TS23222] defines architecture for the common
API framework for 3GPP northbound APIs and [TS33122] defines security API framework for 3GPP northbound APIs. [TS33122] defines security
aspects for common API framework for 3GPP northbound APIs. In this aspects for a common API framework for 3GPP northbound APIs. In this
case, the path is small for data transmission. The main functions of case, the path is small for data transmission. The main functions of
the NGW-SCEF are Connectivity path and Device Monitoring. the NGW-SCEF are path connectivity and device monitoring.
+---+ +---------+ +------+ +---+ +---------+ +------+
|Dev| \ | +-----+ | ---| HSS | |Dev| \ | +-----+ | ---| HSS |
|-UE| \ | | NGW | | +------+ |-UE| \ | | NGW | | +------+
+---+ | | |-MME |\__ +---+ | | |-MME |\__
\ / +-----+ | \ \ / +-----+ | \
+---+ \+-----+ /| | | +------+ +---+ \+-----+ /| | | +------+
|Dev| ----| RGW |- | | | | NGW- | |Dev| ----| RGW |- | | | | NGW- |
|-UE| |-eNB | | | | | SCEF |---------+ |-UE| |-eNB | | | | | SCEF |---------+
+---+ /+-----+ \| | | +------+ | +---+ /+-----+ \| | | +------+ |
/ \ +------+| | / \ +------+| |
/ |\| NGW- || +-----+ +-----------+ / |\| NGW- || +-----+ +-----------+
+---+ / | | CSGW |--| NGW-|---|Application| +---+ / | | CSGW |--| NGW-|---|Application|
|Dev| | | || | PGW | | Server | |Dev| | | || | PGW | | Server |
|-UE| | +------+| +-----+ +-----------+ |-UE| | +------+| +-----+ +-----------+
+---+ | | +---+ | |
|NGW-CSGN | |NGW-CSGN |
+---------+ +---------+
Figure 1: 3GPP network architecture Figure 1: 3GPP Network Architecture
5. Data Transmission in the 3GPP Architecture 5. 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 signaling
between the nodes and functions to configure, control, and monitor between the nodes and functions to configure, control, and monitor
the system functions and behaviors. The signaling uses a different the system functions and behaviors. The signaling uses a different
path with specific protocols, handling processes, and entities but path with specific protocols, handling processes, and entities but
can transport end-to-end user data for IoT services. In contrast, can transport end-to-end user data for IoT services. In contrast,
the end-to-end application only transports end-to-end data. the end-to-end application only transports end-to-end data.
The recommended 3GPP MTU size is 1358 bytes. The radio network The recommended 3GPP MTU size is 1358 bytes. The radio network
protocols limit the packet sizes over the air, including radio protocols limit the packet sizes over the air, including radio
protocol overhead, to 1600 bytes, see Section 5.2.3. However, the protocol overhead, to 1600 bytes; see Section 5.2.3. However, the
recommended 3GPP MTU is smaller to avoid fragmentation in the network recommended 3GPP MTU is smaller to avoid fragmentation in the network
backbone due to the payload encryption size (multiple of 16) and the backbone due to the payload encryption size (multiple of 16) and the
additional core transport overhead handling. additional core transport overhead handling.
3GPP standardizes NB-IoT and, in general, the cellular technologies 3GPP standardizes NB-IoT and, in general, the interfaces and
interfaces and functions. Therefore, the introduction of SCHC functions of cellular technologies. Therefore, the introduction of
entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified in SCHC entities to Dev-UE, RGW-eNB, and NGW-CSGN needs to be specified
the NB-IoT standard. in the NB-IoT standard.
This document identifies the use cases of SCHC over the NB-IoT This document identifies the use cases of SCHC over the NB-IoT
architecture. architecture.
First, the radio transmission where, see Section 5.2.1, the Dev-UE The first use case is of the radio transmission (see Section 5.2.1)
and the RGW-eNB can use the SCHC functionalities. where the Dev-UE and the RGW-eNB can use the SCHC functionalities.
Second, the packets transmitted over the control path can also use The second is where the packets transmitted over the control path can
SCHC when the transmission goes over the NGW-MME or NGW-SCEF. See also use SCHC when the transmission goes over the NGW-MME or NGW-SCEF
Section 5.2.2. (see Section 5.2.2).
These two use cases are also valid for any 3GPP architecture and not These two use cases are also valid for any 3GPP architecture and not
only for NB-IoT. And as the 3GPP internal network is involved, they only for NB-IoT. And as the 3GPP internal network is involved, they
have been put in the informational part of this section. have been put in the informational part of this section.
And third, over the SCHC over Non-IP Data Delivery (NIDD) connection And the third covers the SCHC over Non-IP Data Delivery (NIDD)
or at least up to the operator network edge, see Section 5.1.1. In connection or at least up to the operator network edge (see
this case, SCHC functionalities are available in the application Section 5.1.1). In this case, SCHC functionalities are available in
layer of the Dev-UE and the Application Servers or a broker function the application layer of the Dev-UE and the Application Servers or a
at the edge of the operator network. NGW-PGW or NGW-SCEF transmit broker function at the edge of the operator network. NGW-PGW or NGW-
the packets which are non-IP traffic, using IP tunneling or API SCEF transmit the packets that are Non-IP traffic, using IP tunneling
calls. It is also possible to benefit legacy devices with SCHC by or API calls. It is also possible to benefit legacy devices with
using the non-IP transmission features of the operator network. SCHC by using the Non-IP transmission features of the operator
network.
A non-IP transmission refers to other layer-2 transport different A Non-IP transmission refers to an L2 transport that is different
from NB-IoT. from NB-IoT.
5.1. Normative Part. 5.1. Normative Scenarios
This scenarios does not modify the 3GPP architecture or any of its These scenarios do not modify the 3GPP architecture or any of its
components, it only use it as a layer-2 transmission. components. They only use the architecture as an L2 transmission.
5.1.1. SCHC over Non-IP Data Delivery (NIDD) 5.1.1. SCHC over Non-IP Data Delivery (NIDD)
This section specifies the use of SCHC over Non-IP Data Delivery This section specifies the use of SCHC over NIDD services of 3GPP.
(NIDD) services of 3GPP. The NIDD services of 3GPP enable the The NIDD services of 3GPP enable the transmission of SCHC packets
transmission of SCHC packets compressed by the application layer. compressed by the application layer. The packets can be delivered
The packets can be delivered between the NGW-PGW and the Application between the NGW-PGW and the Application Server or between the NGW-
Server or between the NGW-SCEF and the Application Server, using IP- SCEF and the Application Server, using IP-tunnels or API calls. In
tunnels or API calls. In both cases, as compression occurs before both cases, as compression occurs before transmission, the network
transmission, the network will not understand the packet, and the will not understand the packet, and the network does not have context
network does not have context information of this compression. information of this compression. Therefore, the network will treat
Therefore, the network will treat the packet as Non-IP traffic and the packet as Non-IP traffic and deliver it to the other side without
deliver it to the other side without any other protocol stack any other protocol stack element, directly over L2.
element, directly over the layer-2.
5.1.1.1. SCHC Entities Placing over NIDD 5.1.1.1. SCHC Entities Placing over NIDD
In the two scenarios using NIDD compression, SCHC entities are In the two scenarios using NIDD compression, SCHC entities are
located almost on top of the stack. The NB-IoT connectivity services located almost on top of the stack. The NB-IoT connectivity services
implement SCHC in the Dev-UE, an in the Application Server. The IP implement SCHC in the Dev-UE, an in the Application Server. The IP
tunneling scenario requires that the Application Server send the tunneling scenario requires that the Application Server send the
compressed packet over an IP connection terminated by the 3GPP core compressed packet over an IP connection terminated by the 3GPP core
network. If the transmission uses the NGW-SCEF services, it is network. If the transmission uses the NGW-SCEF services, it is
possible to utilize an API call to transfer the SCHC packets between possible to utilize an API call to transfer the SCHC packets between
skipping to change at page 8, line 5 skipping to change at line 340
| | 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 |
+---------+ +--------+ +---------+ +--------+
Dev-UE Application Dev-UE Application
Server Server
Figure 2: End-to End Compression. SCHC entities placed when Figure 2: End-to-End Compression: SCHC Entities Placed when Using
using Non-IP Delivery (NIDD) 3GPP Services Non-IP Delivery (NIDD) 3GPP Services
5.1.1.2. Parameters for Static Context Header Compression and 5.1.1.2. Parameters for Static Context Header Compression and
Fragmentation (SCHC) Fragmentation (SCHC)
These scenarios MAY use SCHC header compression capability to improve These scenarios MAY use the SCHC header compression capability to
the transmission of IPv6 packets. improve the transmission of IPv6 packets.
* SCHC Context initialization. * SCHC Context Initialization
The application layer handles the static context; consequently, the The application layer handles the static context. Consequently,
context distribution MUST be according to the application's the context distribution MUST be according to the application's
capabilities, perhaps utilizing IP data transmissions up to context capabilities, perhaps utilizing IP data transmissions up to
initialization. Also, the static contexts delivery may use the same context initialization. Also, the static context delivery may use
IP tunneling or NGW-SCEF services used later for the SCHC packets the same IP tunneling or NGW-SCEF services used later for the
transport. transport of SCHC packets.
* SCHC Rules. * SCHC Rules
For devices acting as a capillary gateway, several rules match the For devices acting as a capillary gateway, several rules match the
diversity of devices and protocols used by the devices associated diversity of devices and protocols used by the devices associated
with the gateway. Meanwhile, simpler devices may have predetermined with the gateway. Meanwhile, simpler devices may have
protocols and fixed parameters. predetermined protocols and fixed parameters.
* Rule ID. * RuleID
This scenario can dynamically set the RuleID size before the context This scenario can dynamically set the RuleID size before the
delivery. For example, negotiate between the applications when context delivery, for example, by negotiating between the
choosing a profile according to the type of traffic and application applications when choosing a profile according to the type of
deployed. Transmission optimization may require only one physical traffic and application deployed. Transmission optimization may
layer transmission. SCHC overhead SHOULD NOT exceed the available require only one Physical Layer transmission. SCHC overhead
number of effective bits of the smallest physical TB available to SHOULD NOT exceed the available number of effective bits of the
optimize the transmission. The packets handled by 3GPP networks are smallest physical TB available to optimize the transmission. The
byte-aligned. Thus, to use the smallest TB, the maximum SCHC header packets handled by 3GPP networks are byte-aligned. Thus, to use
size is 12 bits. On the other hand, more complex NB-IoT devices the smallest TB, the maximum SCHC header size is 12 bits. On the
(such as a capillary gateway) might require additional bits to handle other hand, more complex NB-IoT devices (such as a capillary
the variety and multiple parameters of higher-layer protocols gateway) might require additional bits to handle the variety and
deployed. The configuration may be part of the agreed operation multiple parameters of higher-layer protocols deployed. The
profile and content distribution. The RuleID field size may range configuration may be part of the agreed operation profile and
from 2 bits, resulting in 4 rules to an 8-bit value that would yield content distribution. The RuleID field size may range from 2
up to 256 rules that can be used with the operators and seems quite a bits, resulting in 4 rules, to an 8-bit value, yielding up to 256
reasonable maximum limit even for a device acting as a NAT. An rules for use by operators. A 256-rule maximum limit seems to be
application may use a larger RuleID, but it should consider the byte quite reasonable, even for a device acting as a NAT. An
alignment of the expected Compression Residue. In the minimum TB application may use a larger RuleID, but it should consider the
size case, 2 bits of RuleID leave only 6 bits available for byte alignment of the expected Compression Residue. In the
Compression Residue. minimum TB size case, 2 bits of RuleID leave only 6 bits available
for Compression Residue.
* SCHC MAX_PACKET_SIZE. * SCHC MAX_PACKET_SIZE
In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes
since the SCHC packets (and fragments) are traversing the whole 3GPP since the SCHC packets (and fragments) are traversing the whole
network infrastructure (core and radio), not only the radio as the IP 3GPP network infrastructure (core and radio), not only the radio
transmissions case. as in the IP transmissions case.
* Fragmentation. * Fragmentation
Packets larger than 1358 bytes need the SCHC fragmentation function. Packets larger than 1358 bytes need the SCHC fragmentation
Since the 3GPP uses reliability functions, the No-ACK fragmentation function. Since the 3GPP uses reliability functions, the No-ACK
mode MAY be enough in point-to-point connections. Nevertheless, fragmentation mode MAY be enough in point-to-point connections.
additional considerations are described below for more complex cases. Nevertheless, additional considerations are described below for
more complex cases.
* Fragmentation modes. * Fragmentation Modes
A global service assigns a QoS to the packets e.g. depending on the A global service assigns a QoS to the packets, e.g., depending on
billing. Packets with very low QoS may get lost before arriving in the billing. Packets with very low QoS may get lost before
the 3GPP radio network transmission, for example, in between the arriving in the 3GPP radio network transmission, e.g., in between
links of a capillary gateway or due to buffer overflow handling in a the links of a capillary gateway or due to buffer overflow
backhaul connection. The use of SCHC fragmentation with the ACK-on- handling in a backhaul connection. The use of SCHC fragmentation
Error mode is RECOMMENDED to secure additional reliability on the with the ACK-on-Error mode is RECOMMENDED to secure additional
packets transmitted with a small trade-off on further transmissions reliability on the packets transmitted with a small trade-off on
to signal the end-to-end arrival of the packets if no transport further transmissions to signal the end-to-end arrival of the
protocol takes care of retransmission. packets if no transport protocol takes care of retransmission.
Also, the ACK-on-Error mode could be desirable to keep track of all Also, the ACK-on-Error mode could be desirable to keep track of
the SCHC packets delivered. In that case, the fragmentation function all the SCHC packets delivered. In that case, the fragmentation
could be activated for all packets transmitted by the applications. function could be activated for all packets transmitted by the
SCHC ACK-on-Error fragmentation MAY be activated in transmitting non- applications. SCHC ACK-on-Error fragmentation MAY be activated in
IP packets on the NGW-MME. A non-IP packet will use SCHC reserved transmitting Non-IP packets on the NGW-MME. A Non-IP packet will
RuleID for non-compressing packets as [RFC8724] allows it. use SCHC reserved RuleID for non-compressing packets as [RFC8724]
allows it.
* Fragmentation Parameters. * Fragmentation Parameters
SCHC profile will have specific Rules for the fragmentation modes. SCHC profile will have specific Rules for the fragmentation modes.
The rule will identify, which fragmentation mode is in use, and The rule will identify which fragmentation mode is in use, and
section Section 5.2.3 defines the RuleID size. Section 5.2.3 defines the RuleID size.
SCHC parametrization considers that NBIoT aligns the bit and uses SCHC parametrization considers that NB-IoT aligns the bit and uses
padding and the size of the Transfer Block. SCHC will try to reduce padding and the size of the Transfer Block. SCHC will try to reduce
padding to optimize the compression of the information. The Header padding to optimize the compression of the information. The header
size needs to be multiple of 4, and the Tiles MAY keep a fixed value size needs to be a multiple of 4. The Tiles MAY keep a fixed value
of 4 or 8 bits to avoid padding except for transfer block equals 16 of 4 or 8 bits to avoid padding, except for when the transfer block
bits where Tiles may be 2 bits. The transfer block size has a wide equals 16 bits as the Tiles may be 2 bits. The transfer block size
range of values. Two configurations are RECOMMENDED for the has a wide range of values. Two configurations are RECOMMENDED for
fragmentation parameters. the fragmentation parameters.
* For Transfer Blocks smaller or equal to 304 bits using an 8-bit * For Transfer Blocks smaller than or equal to 304 bits using an
Header_size configuration, with the size of the header fields as 8-bit Header_size configuration, with the size of the header
follows: fields as follows:
- RuleID from 1 - 3 bits, - RuleID from 1 - 3 bits
- DTag 1 bit, - DTag 1 bit
- FCN 3 bits, - FCN 3 bits
- W 1 bits. - W 1 bits
* For Transfer Blocks bigger than 304 bits using a 16-bit * For Transfer Blocks bigger than 304 bits using a 16-bit
Header_size configuration, with the size of the header fields as Header_size configuration, with the size of the header fields as
follows: follows:
- RulesID from 8 - 10 bits, - RulesID from 8 - 10 bits
- DTag 1 or 2 bits, - DTag 1 or 2 bits
- FCN 3 bits, - FCN 3 bits
- W 2 or 3 bits. - W 2 or 3 bits
* WINDOW_SIZE of 2^N-1 is RECOMMENDED. * WINDOW_SIZE of (2^N)-1 is RECOMMENDED.
* RCS will follow the default size defined in section 8.2.3 of the * Reassembly Check Sequence (RCS) will follow the default size
[RFC8724], with a length equal to the L2 Word. defined in Section 8.2.3 of [RFC8724], with a length equal to the
L2 Word.
* MAX_ACK_REQ is RECOMMENDED to be 2, but applications MAY change * MAX_ACK_REQ is RECOMMENDED to be 2, but applications MAY change
this value based on transmission conditions. this value based on transmission conditions.
The IoT devices communicate with small data transfer and use the The IoT devices communicate with small data transfers and use the
Power Save Mode and the Idle Mode DRX, which govern how often the Power Save Mode and the Idle Mode Discontinuous Reception (DRX),
device wakes up, stays up, and is reachable. The use of the which govern how often the device wakes up, stays up, and is
different modes allows the battery to last ten years. reachable. The use of the different modes allows the battery to last
Table 10.5.163a in [TS24008] specifies a range for the radio timers ten years. Table 10.5.163a in [TS24008] defines the radio timer
as N to 3N in increments of one where the units of N can be 1 hour or values with units incrementing by N. The units of N can be 1 hour or
10 hours. The Inactivity Timer and the Retransmission Timer be set 10 hours. The range used for IoT is of N to 3N, where N increments
by one. The Inactivity Timer and the Retransmission Timer can be set
based on these limits. based on these limits.
5.2. Informational Part. 5.2. Informational Scenarios
These scenarios shows how 3GPP could use SCHC for their These scenarios show how 3GPP could use SCHC for their transmissions.
transmissions.
5.2.1. Use of SCHC over the Radio link 5.2.1. Use of SCHC over the Radio Link
Deploying SCHC over the radio link only would require placing it as Deploying SCHC over the Radio Link only would require placing it as
part of the protocol stack for data transfer between the Dev-UE and part of the protocol stack for data transfer between the Dev-UE and
the 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
selected Modulation and Coding Schemes (MCS). Transport Block (TB) selected Modulation and Coding Schemes (MCSs). Transport Block (TB)
transmissions happen in the physical layer at network-synchronized transmissions happen in the Physical Layer at network-synchronized
intervals called Transmission Time Interval (TTI). Each Transport intervals called Transmission Time Interval (TTI). Each TB has a
Block has a different MCS and number of bits available to transmit. different MCS and number of bits available to transmit. The MAC
The MAC layer [TR36321] defines the Transport Blocks' layer [TR36321] defines the characteristics of the TBs. The Radio
characteristics. The Radio link stack shown in Figure 3 comprises Link stack shown in Figure 3 comprises the Packet Data Convergence
the Packet Data Convergence Protocol (PDCP) [TS36323], Radio Link Protocol (PDCP) [TS36323], the Radio Link Protocol (RLC) [TS36322],
Protocol (RLC) [TS36322], Medium Access Control protocol (MAC) the Medium Access Control protocol (MAC) [TR36321], and the Physical
[TR36321], and the Physical Layer [TS36201]. The Appendix A gives Layer [TS36201]. Appendix A gives more details about these
more details about these protocols. protocols.
+---------+ +---------+ | +---------+ +---------+ |
|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-UE RGW-eNB NGW-CSGN Dev-UE RGW-eNB NGW-CSGN
Radio Link Radio Link
Figure 3: SCHC over the Radio link Figure 3: SCHC over the Radio Link
5.2.1.1. SCHC Entities Placing over the Radio Link 5.2.1.1. Placing SCHC Entities over the Radio Link
The 3GPP architecture supports Robust Header Compression (ROHC) The 3GPP architecture supports Robust Header Compression (ROHC)
[RFC5795] in the PDCP layer. Therefore, the architecture can deploy [RFC5795] in the PDCP layer. Therefore, the architecture can deploy
SCHC header compression entities similarly without the need for SCHC header compression entities similarly without the need for
significant changes in the 3GPP specifications. significant changes in the 3GPP specifications.
The RLC layer has three functional modes Transparent Mode (TM), The RLC layer has three functional modes: Transparent Mode (TM),
Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of
operation controls the functionalities of the RLC layer. TM only operation controls the functionalities of the RLC layer. TM only
applies to signaling packets, while AM or UM carry signaling and data applies to signaling packets, while AM or UM carry signaling and data
packets. packets.
The RLC layer takes care of fragmentation unless for the Transparent The RLC layer takes care of fragmentation except for the TM. In AM
Mode. In AM or UM modes, the SCHC fragmentation is unnecessary and or UM, the SCHC fragmentation is unnecessary and SHOULD NOT be used.
SHOULD NOT be used. While sending IP packets, the Radio link does While sending IP packets, the Radio Link does not commonly use the
not commonly use the RLC Transparent Mode. However, if other RLC TM. However, if other protocol overhead optimizations are
protocol overhead optimizations are targeted for NB-IoT traffic, SCHC targeted for NB-IoT traffic, SCHC fragmentation may be used for TM
fragmentation may be used for TM transmission mode in the future. transmission in the future.
5.2.2. Use of SCHC over the Non-Access Stratum (NAS) 5.2.2. Use of SCHC over the Non-Access Stratum (NAS)
This section consists of IETF suggestions to the 3GPP. The NGW-MME This section consists of IETF suggestions to the 3GPP. The NGW-MME
conveys mainly signaling between the Dev-UE and the cellular network conveys mainly signaling between the Dev-UE and the cellular network
[TR24301]. The network transports this traffic on top of the radio [TR24301]. The network transports this traffic on top of the Radio
link. 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 Non-Access Stratum (DoNAS) or transmission is known as Data over Non-Access Stratum (DoNAS) or
Control Plane Cellular Internet of Things (CIoT) evolved packet Control Plane CIoT EPS optimizations. In DoNAS, the Dev-UE uses the
system (EPS) optimizations. In DoNAS, the Dev-UE uses the pre- pre-established security, can piggyback small uplink data into the
established security and can piggyback small uplink data into the initial uplink message, and uses an additional message to receive a
initial uplink message and uses an additional message to receive a
downlink 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 the buffered
transmit, the Dev-UE might deploy the connected mode transmissions data to be transmitted, the Dev-UE might deploy the connected mode
instead, limiting and controlling the DoNAS transmissions to transmission instead. The connected mode would limit and control the
predefined thresholds and a good resource optimization balance for DoNAS transmissions to predefined thresholds, and it would be a good
the terminal and the network. The support for mobility of DoNAS is resource optimization balance for the terminal and the network. The
present but produces additional overhead. The Appendix B gives support for mobility of DoNAS is present but produces additional
additional details of DoNAS. overhead. Appendix B gives additional details of DoNAS.
5.2.2.1. SCHC Entities Placing over DoNAS 5.2.2.1. Placing SCHC Entities over DoNAS
SCHC resides in this scenario's Non-Access Stratum (NAS) protocol SCHC resides in this scenario's Non-Access Stratum (NAS) protocol
layer. The same principles as for the section Section 5.2.1 apply layer. The same principles as for Section 5.2.1 apply here as well.
here as well. Because the NAS protocol already uses ROHC [RFC5795], Because the NAS protocol already uses ROHC [RFC5795], it can also
it can also adapt SCHC for header compression. The main difference adapt SCHC for header compression. The main difference compared to
compared to the radio link, section Section 5.2.1, is the physical the Radio Link (Section 5.2.1) is the physical placing of the SCHC
placing of the SCHC entities. On the network side, the NGW-MME entities. On the network side, the NGW-MME resides in the core
resides in the core network and is the terminating node for NAS network and is the terminating node for NAS instead of the RGW-eNB.
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 |
skipping to change at page 13, line 38 skipping to change at line 611
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| 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 SGi C-Uu/ S1 SGi
Dev-UE 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 4: SCHC entities placement in the 3GPP CIOT radio protocol Figure 4: SCHC Entities Placement in the 3GPP CIOT Radio Protocol
architecture for DoNAS transmissions Architecture for DoNAS Transmissions
5.2.3. Parameters for Static Context Header Compression and 5.2.3. Parameters for Static Context Header Compression and
Fragmentation (SCHC) for the Radio link and DONAS use-cases. Fragmentation (SCHC) for the Radio Link and DoNAS Use Cases
If 3GPP incorporates SCHC, it is recommended that these scenarios use If 3GPP incorporates SCHC, it is recommended that these scenarios use
SCHC header compression [RFC8724] capability to optimize the data the SCHC header compression [RFC8724] capability to optimize the data
transmission. transmission.
* SCHC Context initialization. * SCHC Context Initialization
The RRC (Radio Resource Control) protocol is the main tool used to The Radio Resource Control (RRC) protocol is the main tool used to
configure the parameters of the Radio link. It will configure SCHC configure the parameters of the Radio Link. It will configure
and the static context distribution as it has made for ROHC [RFC5795] SCHC and the static context distribution as it has been made for
operation [TS36323]. ROHC operation [RFC5795] [TS36323].
* SCHC Rules. * SCHC Rules
The network operator in these scenarios defines the number of rules. The network operator defines the number of rules in these
For this, the network operator must know the IP traffic the device scenarios. For this, the network operator must know the IP
will carry. The operator might supply rules compatible with the traffic the device will carry. The operator might supply rules
device's use case. For devices acting as a capillary gateway, compatible with the device's use case. For devices acting as a
several rules match the diversity of devices and protocols used by capillary gateway, several rules match the diversity of devices
the devices associated with the gateway. Meanwhile, simpler devices and protocols used by the devices associated with the gateway.
may have predetermined protocols and fixed parameters. The use of Meanwhile, simpler devices may have predetermined protocols and
IPv6 and IPv4 may force to get more rules to deal with each case. fixed parameters. The use of IPv6 and IPv4 may force the operator
to develop more rules to deal with each case.
* RuleID. * RuleID
There is a reasonable assumption of 9 bytes of radio protocol There is a reasonable assumption of 9 bytes of radio protocol
overhead for these transmission scenarios in NB-IoT, where PDCP uses overhead for these transmission scenarios in NB-IoT, where PDCP
5 bytes due to header and integrity protection, and RLC and MAC use 4 uses 5 bytes due to header and integrity protection and where RLC
bytes. The minimum physical Transport Blocks (TB) that can withhold and MAC use 4 bytes. The minimum physical TBs that can withhold
this overhead value according to 3GPP Release 15 specifications are this overhead value, according to the 3GPP Release 15
88, 104, 120, and 144 bits. As for Section 5.1.1.2, these scenarios specification [R15-3GPP], are 88, 104, 120, and 144 bits. As for
must optimize the physical layer where the smallest TB is 12 bits. Section 5.1.1.2, these scenarios must optimize the Physical Layer
These 12 bits must include the Compression Residue in addition to the where the smallest TB is 12 bits. These 12 bits must include the
RuleID. On the other hand, more complex NB-IoT devices (such as a Compression Residue in addition to the RuleID. On the other hand,
capillary gateway) might require additional bits to handle the more complex NB-IoT devices (such as a capillary gateway) might
variety and multiple parameters of higher-layer protocols deployed. require additional bits to handle the variety and multiple
In that sense, the operator may want flexibility on the number and parameters of higher-layer protocols deployed. In that sense, the
type of rules independently supported by each device; consequently, operator may want flexibility on the number and type of rules
these scenarios require a configurable value. The configuration may independently supported by each device; consequently, these
be part of the agreed operation profile with the content scenarios require a configurable value. The configuration may be
distribution. The RuleID field size may range from 2 bits, resulting part of the agreed operation profile with the content
in 4 rules to an 8-bit value that would yield up to 256 rules that distribution. The RuleID field size may range from 2 bits,
can be used with the operators and seems quite a reasonable maximum resulting in 4 rules, to an 8-bit value, yielding up to 256 rules
limit even for a device acting as a NAT. An application may use a for use with the operators. A 256-rule maximum limit seems to be
larger RuleID, but it should consider the byte alignment of the quite reasonable, even for a device acting as a NAT. An
expected Compression Residue. In the minimum TB size case, 2 bits of application may use a larger RuleID, but it should consider the
RuleID leave only 6 bits available for Compression Residue. 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.
* SCHC MAX_PACKET_SIZE. * SCHC MAX_PACKET_SIZE
The Radio Link 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
the MTU handled by the radio protocols, which corresponds to 1600 by the MTU that is handled by the radio protocols, which
bytes for 3GPP Release 15. corresponds to 1600 bytes for the 3GPP Release 15.
* Fragmentation. * Fragmentation
For the Radio link Section 5.2.1 and DoNAS' Section 5.2.2 scenarios, For the Radio Link (Section 5.2.1) and DoNAS (Section 5.2.2)
the SCHC fragmentation functions are disabled. The RLC layer of NB- scenarios, the SCHC fragmentation functions are disabled. The RLC
IoT can segment packets into suitable units that fit the selected layer of NB-IoT can segment packets into suitable units that fit
transport blocks for transmissions of the physical layer. The block the selected TB for transmissions of the Physical Layer. The
selection is made according to the link adaptation input function in block selection is made according to the link adaptation input
the MAC layer and the quantity of data in the buffer. The link function in the MAC layer and the quantity of data in the buffer.
adaptation layer may produce different results at each Time The link adaptation layer may produce different results at each
Transmission Interval (TTI), resulting in varying physical transport TTI, resulting in varying physical TBs that depend on the network
blocks that depend on the network load, interference, number of bits load, interference, number of bits transmitted, and QoS. Even if
transmitted, and QoS. Even if setting a value that allows the setting a value that allows the construction of data units
construction of data units following the SCHC tiles principle, the following the SCHC tiles principle, the protocol overhead may be
protocol overhead may be greater or equal to allowing the Radio link greater or equal to allowing the Radio Link protocols to take care
protocols to take care of the fragmentation intrinsically. of the fragmentation intrinsically.
* Fragmentation in RLC Transparent Mode. * Fragmentation in RLC TM
The RLC Transparent Mode mostly applies to control signaling The RLC TM mostly applies to control signaling transmissions.
transmissions. When RLC operates in Transparent Mode, the MAC layer When RLC operates in TM, the MAC layer mechanisms ensure
mechanisms ensure reliability and generate overhead. This additional reliability and generate overhead. This additional reliability
reliability implies sending repetitions or automatic retransmissions. implies sending repetitions or automatic retransmissions.
The ACK-Always fragmentation mode of SCHC may reduce this overhead in The ACK-Always fragmentation mode of SCHC may reduce this overhead
future operations when data transmissions may use this mode. ACK- in future operations when data transmissions may use this mode.
Always mode may transmit compressed data with fewer possible The ACK-Always mode may transmit compressed data with fewer
transmissions by using fixed or limited transport blocks compatible possible transmissions by using fixed or limited TBs compatible
with the tiling SCHC fragmentation handling. For SCHC fragmentation with the tiling SCHC fragmentation handling. For SCHC
parameters see Section 5.1.1.2. fragmentation parameters, see Section 5.1.1.2.
6. Padding 6. Padding
NB-IoT and 3GPP wireless access, in general, assumes byte-aligned NB-IoT and 3GPP wireless access, in general, assumes a byte-aligned
payload. Therefore, the layer 2 word for NB-IoT MUST be considered 8 payload. Therefore, the L2 Word for NB-IoT MUST be considered 8
bits, and the padding treatment should use this value accordingly. bits, and the padding treatment should use this value accordingly.
7. IANA considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
8. Security considerations 8. Security Considerations
This document does not add any security considerations and follows This document does not add any security considerations and follows
the [RFC8724] and the 3GPP access security document specified in [RFC8724] and the 3GPP access security document specified in
[TS33122]. [TS33122].
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 16, line 29 skipping to change at line 747
<https://www.rfc-editor.org/info/rfc8724>. <https://www.rfc-editor.org/info/rfc8724>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824, Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021, DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>. <https://www.rfc-editor.org/info/rfc8824>.
9.2. Informative References 9.2. Informative References
[OMA0116] OMA, "Common definitions for RESTful Network APIs", 2018, [OMA0116] Open Mobile Alliance, "Common definitions for RESTful
Network APIs", Version 1.0, January 2018,
<https://www.openmobilealliance.org/release/ <https://www.openmobilealliance.org/release/
REST_NetAPI_Common/V1_0-20180116-A/OMA-TS- REST_NetAPI_Common/V1_0-20180116-A/OMA-TS-
REST_NetAPI_Common-V1_0-20180116-A.pdf>. REST_NetAPI_Common-V1_0-20180116-A.pdf>.
[R15-3GPP] 3GPP, "Release 15", April 2019, <https://www.3gpp.org/
specifications-technologies/releases/release-15>.
[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>.
[TR-0024] OneM2M, "3GPP_Interworking", 2020, [TR-0024] OneM2M, "3GPP_Interworking", TR-0024-V4.3.0, March 2020,
<https://ftp.onem2m.org/work%20programme/WI-0037/TR-0024- <https://ftp.onem2m.org/work%20programme/WI-0037/TR-0024-
3GPP_Interworking-V4_3_0.DOCX>. 3GPP_Interworking-V4_3_0.DOCX>.
[TR23720] 3GPP, "Study on architecture enhancements for Cellular [TR23720] 3GPP, "Study on architecture enhancements for Cellular
Internet of Things", 2015, Internet of Things", 3GPP TR 23.720 V13.0.0, March 2016,
<https://www.3gpp.org/ftp/Specs/ <https://www.3gpp.org/ftp/Specs/
archive/23_series/23.720/23720-d00.zip>. archive/23_series/23.720/23720-d00.zip>.
[TR24301] 3GPP, "Evolved Universal Terrestrial Radio Access [TR24301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
(E-UTRA); Medium Access Control (MAC) protocol Packet System (EPS); Stage 3", 3GPP TS 24.301 V15.8.0,
specification", 2019, <https://www.3gpp.org/ftp//Specs/ December 2019, <https://www.3gpp.org/ftp//Specs/
archive/24_series/24.301/24301-f80.zip>. archive/24_series/24.301/24301-f80.zip>.
[TR36321] 3GPP, "Evolved Universal Terrestrial Radio Access [TR36321] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Medium Access Control (MAC) protocol (E-UTRA); Medium Access Control (MAC) protocol
specification", 2016, <https://www.3gpp.org/ftp/Specs/ specification", 3GPP TS 36.321 V13.2.0, June 2016,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.321/36321-d20.zip>. archive/36_series/36.321/36321-d20.zip>.
[TS23222] 3GPP, "Common API Framework for 3GPP Northbound APIs", [TS23222] 3GPP, "Functional architecture and information flows to
2022, <https://www.3gpp.org/ftp/Specs/ support Common API Framework for 3GPP Northbound APIs;
Stage 2", 3GPP TS 23.222 V15.6.0, September 2022,
<https://www.3gpp.org/ftp/Specs/
archive/23_series/23.222/23222-f60.zip>. archive/23_series/23.222/23222-f60.zip>.
[TS24008] 3GPP, "Mobile radio interface layer 3 specification.", [TS24008] 3GPP, "Mobile radio interface Layer 3 specification; Core
2018, <https://www.3gpp.org/ftp//Specs/ network protocols; Stage 3", 3GPP TS 24.008 V15.5.0,
December 2018, <https://www.3gpp.org/ftp//Specs/
archive/24_series/24.008/24008-f50.zip>. archive/24_series/24.008/24008-f50.zip>.
[TS33122] 3GPP, "Security aspects of Common API Framework (CAPIF) [TS33122] 3GPP, "Security aspects of Common API Framework (CAPIF)
for 3GPP northbound APIs", 2018, for 3GPP northbound APIs", 3GPP TS 33.122 V15.3.0, March
<https://www.3gpp.org/ftp//Specs/ 2019, <https://www.3gpp.org/ftp//Specs/
archive/33_series/33.122/33122-f30.zip>. archive/33_series/33.122/33122-f30.zip>.
[TS36201] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36201] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); LTE physical layer; General description", 2018, (E-UTRA); LTE physical layer; General description", 3GPP
TS 36.201 V15.1.0, June 2018,
<https://www.3gpp.org/ftp/Specs/ <https://www.3gpp.org/ftp/Specs/
archive/36_series/36.201/36201-f10.zip>. archive/36_series/36.201/36201-f10.zip>.
[TS36322] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36322] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Radio Link Control (RLC) protocol (E-UTRA); Radio Link Control (RLC) protocol
specification", 2018, <https://www.3gpp.org/ftp/Specs/ specification", 3GPP TS 36.322 V15.0.1, April 2018,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.322/36322-f01.zip>. archive/36_series/36.322/36322-f01.zip>.
[TS36323] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36323] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Packet Data Convergence Protocol (PDCP) (E-UTRA); Packet Data Convergence Protocol (PDCP)
specification", 2016, <https://www.3gpp.org/ftp/Specs/ specification", 3GPP TS 36.323 V13.2.0, June 2016,
<https://www.3gpp.org/ftp/Specs/
archive/36_series/36.323/36323-d20.zip>. archive/36_series/36.323/36323-d20.zip>.
[TS36331] 3GPP, "Evolved Universal Terrestrial Radio Access [TS36331] 3GPP, "Evolved Universal Terrestrial Radio Access
(E-UTRA); Radio Resource Control (RRC); Protocol (E-UTRA); Radio Resource Control (RRC); Protocol
specification", 2018, <https://www.3gpp.org/ftp//Specs/ specification", 3GPP TS 36.331 V15.5.1, April 2019,
<https://www.3gpp.org/ftp//Specs/
archive/36_series/36.331/36331-f51.zip>. archive/36_series/36.331/36331-f51.zip>.
[_3GPPR15] 3GPP, "The Mobile Broadband Standard", 2019, Appendix A. NB-IoT User Plane Protocol Architecture
<https://www.3gpp.org/release-15>.
Appendix A. NB-IoT User Plane protocol architecture A.1. Packet Data Convergence Protocol (PDCP)
A.1. Packet Data Convergence Protocol (PDCP) [TS36323]
Each of the Radio Bearers (RB) is associated with one PDCP entity. Each of the Radio Bearers (RBs) is associated with one PDCP entity
Moreover, a PDCP entity is associated with one or two RLC entities [TS36323]. Moreover, a PDCP entity is associated with one or two RLC
depending on the unidirectional or bi-directional characteristics of entities, depending on the unidirectional or bidirectional
the RB and RLC mode used. A PDCP entity is associated with either a characteristics of the RB and RLC mode used. A PDCP entity is
control plane or a user plane with independent configuration and associated with either a control plane or a user plane with
functions. The maximum supported size for NB-IoT of a PDCP SDU is independent configuration and functions. The maximum supported size
1600 octets. The primary services and functions of the PDCP sublayer for NB-IoT of a PDCP SDU is 1600 octets. The primary services and
for NB-IoT for the user plane include: functions of the PDCP sublayer for NB-IoT for the user plane include:
* Header compression and decompression using ROHC [RFC5795] * Header compression and decompression using ROHC [RFC5795]
* 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 is in use for User
only) Plane only)
* Ciphering and deciphering * Ciphering and deciphering
* Timer-based SDU discard in uplink * Timer-based SDU discard in uplink
A.2. Radio Link Protocol (RLC) [TS36322] A.2. Radio Link Protocol (RLC)
RLC is a layer-2 protocol that operates between the UE and the base RLC [TS36322] is an L2 protocol that operates between the User
station (eNB). It supports the packet delivery from higher layers to Equipment (UE) and the base station (eNB). It supports the packet
MAC, creating packets transmitted over the air, optimizing the delivery from higher layers to MAC, creating packets transmitted over
Transport Block utilization. RLC flow of data packets is the air, optimizing the TB 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 bidirectional flows, two sets of entities,
one in each direction (downlink and uplink), must be configured and one in each direction (downlink and uplink), must be configured and
effectively peered to each other. The peering allows the effectively peered to each other. The peering allows the
transmission of control packets (ex., status reports) between transmission of control packets (e.g., status reports) between
entities. RLC can be configured for data transfer in one of the entities. RLC can be configured for a data transfer in one of the
following modes: following modes:
* Transparent Mode (TM). RLC does not segment or concatenate SDUs * Transparent Mode (TM)
from higher layers in this mode and does not include any header to
the payload. RLC receives SDUs from upper layers when acting as a
transmitter and transmits directly to its flow RLC receiver via
lower layers. Similarly, a TM RLC receiver would only deliver
without processing the packets to higher layers upon reception.
* Unacknowledged Mode (UM). This mode provides support for RLC does not segment or concatenate SDUs from higher layers in
segmentation and concatenation of payload. The RLC packet's size this mode and does not include any header with the payload. RLC
depends on the indication given at a particular transmission receives SDUs from upper layers when acting as a transmitter and
opportunity by the lower layer (MAC) and is octet-aligned. The transmits directly to its flow RLC receiver via lower layers.
packet delivery to the receiver does not include reliability Similarly, upon reception, a TM RLC receiver would not process the
support, and the loss of a segment from a packet means a complete packets and only deliver them to higher layers.
packet loss. Also, in the case of lower layer retransmissions,
there is no support for re-segmentation in case of change of the
radio conditions triggering the selection of a smaller transport
block. Additionally, it provides PDU duplication detection and
discards, reordering of out-of-sequence, and loss detection.
* Acknowledged Mode (AM). In addition to the same functions * Unacknowledged Mode (UM)
supported by UM, this mode also adds a moving windows-based
reliability service on top of the lower layer services. It also
supports re-segmentation, and it requires bidirectional
communication to exchange acknowledgment reports called RLC Status
Report and trigger retransmissions. This model also supports
protocol error detection. The mode used depends on the operator
configuration for the type of data to be transmitted. For
example, data transmissions supporting mobility or requiring high
reliability would be most likely configured using AM. Meanwhile,
streaming and real-time data would be mapped to a UM
configuration.
A.3. Medium Access Control (MAC) [TR36321] This mode provides support for segmentation and concatenation of
payload. The RLC packet's size depends on the indication given at
a particular transmission opportunity by the lower layer (MAC) and
is octet-aligned. The packet delivery to the receiver does not
include reliability support, and the loss of a segment from a
packet means a complete packet loss. Also, in lower-layer
retransmissions, there is no support for re-segmentation in case
the radio conditions change and trigger the selection of a smaller
TB. Additionally, it provides PDU duplication detection and
discards, out-of-sequence reordering, and loss detection.
MAC provides a mapping between the higher layers abstraction called * Acknowledged Mode (AM)
Logical Channels comprised by the previously described protocols to
the Physical layer channels (transport channels). Additionally, MAC In addition to the same functions supported by UM, this mode also
may multiplex packets from different Logical Channels and prioritize adds a moving windows-based reliability service on top of the
what to fit into one Transport Block if there is data and space lower-layer services. It also supports re-segmentation, and it
available to maximize data transmission efficiency. MAC also requires bidirectional communication to exchange acknowledgment
provides error correction and reliability support through Hybrid reports, called RLC Status Reports, and to trigger
Automatic Repeat reQuest (HARQ), transport format selection, and retransmissions. This model also supports protocol-error
scheduling information reporting from the terminal to the network. detection. The mode used depends on the operator configuration
MAC also adds the necessary padding and piggyback control elements for the type of data to be transmitted. For example, data
when possible and the higher layers data. transmissions supporting mobility or requiring high reliability
would be most likely configured using AM. Meanwhile, streaming
and real-time data would be mapped to a UM configuration.
A.3. Medium Access Control (MAC)
MAC [TR36321] provides a mapping between the higher layers
abstraction called Logical Channels (which are comprised by the
previously described protocols) and the Physical Layer channels
(transport channels). Additionally, MAC may multiplex packets from
different Logical Channels and prioritize which ones to fit into one
TB if there is data and space available to maximize data transmission
efficiency. MAC also provides error correction and reliability
support through Hybrid Automatic Repeat reQuest (HARQ), transport
format selection, and scheduling information reported from the
terminal to the network. MAC also adds the necessary padding and
piggyback control elements, when possible, as well as the higher
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 |
+--------+ +--------+ +--------+--\ +--------+ +--------+ +--------+--\
| | | | | | | | |\ `--------\ | | | | | | | | |\ `--------\
+---------------------------+ | |(1)| `-------\(2)\ +---------------------------+ | |(1)| `-------\(2)\
RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+ RLC |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+ +----|---+
|Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2| |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2| |RLC |AP2|
skipping to change at page 20, line 35 skipping to change at line 946
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
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
(1) Segment One (1) Segment One
(2) Segment Two (2) Segment Two
Figure 5: Example of User Plane packet encapsulation for two Figure 5: Example of User Plane Packet Encapsulation for Two
transport blocks Transport Blocks
Appendix B. NB-IoT Data over NAS (DoNAS) Appendix B. NB-IoT Data over NAS (DoNAS)
The Access Stratum (AS) protocol stack used by DoNAS is specific The Access Stratum (AS) protocol stack used by DoNAS is specific
because the radio network still needs to establish the security because the radio network still needs to establish the security
associations and reduce the protocol overhead, so the PDCP (Packet associations and reduce the protocol overhead so that the PDCP is
Data Convergence Protocol) is bypassed until AS security is bypassed until the AS security is activated. By default, RLC uses
activated. RLC (Radio Link Control protocol) uses, by default, the the AM. However, depending on the network's features and the
AM mode, but depending on the network's features and the terminal, it terminal, RLC may change to other modes by the network operator. For
may change to other modes by the network operator. For example, the example, the TM does not add any header nor 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 TB used to
reduce the overhead, but the MTU would be limited by the transport transmit the data, which is a couple of thousand bits maximum. If UM
block used to transmit the data, which is a couple of thousand bits (only terminals compatible with 3GPP Release 15 [R15-3GPP]) is used,
maximum. If UM (only Release 15 compatible terminals) is used, the the RLC mechanisms of reliability are disabled, and only the
RLC mechanisms of reliability are disabled, and only the reliability reliability provided by the MAC layer by HARQ is available. In this
provided by the MAC layer by HARQ is available. In this case, the case, the protocol overhead might be smaller than the AM case because
protocol overhead might be smaller than the AM case because of the of the lack of status reporting, but the overhead would have the same
lack of status reporting but with the same support for segmentation support for segmentation up to 1600 bytes. NAS packets are
up to 1600 bytes. NAS packets are encapsulated within an RRC (Radio encapsulated within an RRC [TS36331] message.
Resource Control) [TS36331] message.
Depending on 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 establishes 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 upon 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 a short transmission and receiving an power-saving state requires a short transmission and is receiving an
acknowledgment or short feedback from the network. Depending on 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 be transmitted, the UE might be instructed
deploy the connected mode transmissions instead, limiting and to 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 the network. The good resource optimization balance for the terminal and the network.
support for mobility of DoNAS is present but produces additional The 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 | | +--------+ |
+------------------------------+ | | | +------------------------------+ | | |
| | | | | | | | | | | |
+------|------------|--------+ | | | | +------|------------|--------+ | | | |
|RRC Connection Establishment| | | | | |RRC connection establishment| | | | |
|with NAS PDU transmission | | | | | |with NAS PDU transmission | | | | |
|& Ack Rsp | | | | | |& Ack Rsp | | | | |
+----------------------------+ | | | | +----------------------------+ | | | |
| | | | | | | | | | | |
| |Initial UE | | | | | |Initial UE | | | |
| |message | | | | | |message | | | |
| |----------->| | | | | |----------->| | | |
| | | | | | | | | | | |
| | +---------------------+| | | | | +---------------------+| | |
| | |Checks Integrity || | | | | |Checks Integrity || | |
| | |protection, decrypts || | | | | |protection, decrypts || | |
| | |data || | | | | |data || | |
| | +---------------------+| | | | | +---------------------+| | |
| | | Small data packet | | | | Small data packet |
| | |-------------------------------> | | |------------------------------->
| | | Small data packet | | | | Small data packet |
| | |<------------------------------- | | |<-------------------------------
| | +----------|---------+ | | | | | +----------|---------+ | | |
| | Integrity protection,| | | | | | Integrity protection,| | | |
| | encrypts data | | | | | | encrypts data | | | |
| | +--------------------+ | | | | | +--------------------+ | | |
| | | | | | | | | | | |
| |Downlink NAS| | | | | |Downlink NAS| | | |
| |message | | | | | |message | | | |
| |<-----------| | | | | |<-----------| | | |
+-----------------------+ | | | | +-----------------------+ | | | |
|Small Data Delivery, | | | | | |Small data delivery, | | | | |
|RRC connection release | | | | | |RRC connection release | | | | |
+-----------------------+ | | | | +-----------------------+ | | | |
| | | |
| | | |
+-----------------+ +-----------------+
Figure 6: 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 23, line 38 skipping to change at line 1063
| | LCID1 | \ | | / | | LCID1 | \ | | /
| | | \ \ | | | | | \ \ | |
| | | \ \ | | | | | \ \ | |
| | | \ \ \ | | | | \ \ \ |
+----+----+----------++-----|----+---------++----+---------|---+ +----+----+----------++-----|----+---------++----+---------|---+
MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
+----+----+----------++-----+----+---------++----+---------+---+ +----+----+----------++-----+----+---------++----+---------+---+
TB1 TB2 TB3 TB1 TB2 TB3
Figure 7: Example of User Plane packet encapsulation for Data Figure 7: Example of User Plane Packet Encapsulation for Data
over NAS over NAS
Appendix C. Acknowledgements Acknowledgements
The authors would like to thank (in alphabetic order): Carles Gomez, The authors would like to thank (in alphabetic order): Carles Gomez,
Antti Ratilainen, Tuomas Tirronen, Pascal Thubert, Eric Vyncke. Antti Ratilainen, Pascal Thubert, Tuomas Tirronen, and Éric Vyncke.
Authors' Addresses Authors' Addresses
Edgar Ramos Edgar Ramos
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
FI- 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. 168 change blocks. 
570 lines changed or deleted 594 lines changed or added

This html diff was produced by rfcdiff 1.48.