RFC 9391

Static Context Header Compression over Narrowband Internet of Things

📅 published April 2023, from ietf

Title Block and the Big Picture 🎀✨

Okay so bestie, let's start with the title block because it tells us everything. 💅 This is RFC 9391, called Static Context Header Compression over Narrowband Internet of Things. It's an IETF document, and it's a Standards Track one, which means it's meant to be actually implemented, not just a vibe. 🔥

The authors are E. Ramos from Ericsson and A. Minaburo from Acklio. It was published in April 2023. The ISSN is 2070-1721 if you want to look it up. 🦋

It doesn't obsolete or update anything listed in the header, so it's its own thing. 🌸

Abstract ✨

Okay so the big idea is this: it describes how Static Context Header Compression and fragmentation (SCHC) works together with the 3rd Generation Partnership Project (3GPP) and Narrowband Internet of Things (NB-IoT). SCHC is the compression and fragmentation spec from RFC 8724 and RFC 8824, and this doc is basically the "how do we use it in NB-IoT" guide. 🧚

It has two parts. 💖 There's one normative part, which is the stuff you have to follow when you use SCHC over NB-IoT. Then there's one informational part, which recommends some values in case 3GPP wants to use SCHC inside their architectures. Normative means strict, informational means "here's a helpful suggestion," and that's the whole split. 🫶

Status of This Memo 🌈

This is an Internet Standards Track document, so it's official. 💅 It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on what Internet Standards even are, check Section 2 of RFC 7841. 📚

For the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9391. 🎀

Copyright is held by the IETF Trust and the document authors, Copyright (c) 2023, all rights reserved. 🔒

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info. Read those carefully, because they spell out your rights and restrictions. 🙈 One important bit: any Code Components you pull out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. Those components also come without warranty, as described in the Revised BSD License. 💀

Table of Contents 🍓

  1. Introduction
  2. Conventions and Definitions
  3. Terminology
  4. NB-IoT Architecture
  5. Data Transmission in the 3GPP Architecture
    • 5.1. Normative Scenarios
      • 5.1.1. SCHC over Non-IP Data Delivery (NIDD)
    • 5.2. Informational Scenarios
      • 5.2.1. Use of SCHC over the Radio Link
      • 5.2.2. Use of SCHC over the Non-Access Stratum (NAS)
      • 5.2.3. Parameters for Static Context Header Compression and Fragmentation (SCHC) for the Radio Link and DoNAS Use Cases
  6. Padding
  7. IANA Considerations
  8. Security Considerations
  9. References
    • 9.1. Normative References
    • 9.2. Informative References
  • Appendix A. NB-IoT User Plane Protocol Architecture
    • A.1. Packet Data Convergence Protocol (PDCP)
    • A.2. Radio Link Protocol (RLC)
    • A.3. Medium Access Control (MAC)
  • Appendix B. NB-IoT Data over NAS (DoNAS)
  • Acknowledgements
  • Authors' Addresses

1. Introduction 🦋

Okay so this doc defines the scenarios where Static Context Header Compression and fragmentation (SCHC) [RFC8724] [RFC8824] is a good fit for 3rd Generation Partnership Project (3GPP) and Narrowband Internet of Things (NB-IoT) protocol stacks. 💖

In 3GPP and NB-IoT networks, header compression gets Internet connectivity to the Device UE (Dev-UE), the radio (RGW-eNB) and network (NGW-MME) gateways, and the Application Server. This document describes the SCHC parameters that support SCHC over the NB-IoT architecture. ✨

This doc assumes NB-IoT functionality from 3GPP release 15 [R15-3GPP]. If the text mentions another version's functionality, it says so explicitly. 🌸

Also, this doc has two parts. 🫶 The normative end-to-end scenarios explain how any application must use SCHC over the 3GPP public service, and the informational scenarios cover how 3GPP could use SCHC in its protocol stack network. 👑

Wait, quick correction on that last bit, because I want to keep it accurate: the original says any application "MUST" use SCHC over the 3GPP public service in the normative part, so that's a hard requirement. 🙈

2. Conventions and Definitions 💅

Here's the key-word situation. The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in ALL CAPS, exactly like that. 🔥 If they're lowercase, they're just regular English words. No cap, that's the whole rule. 💀

3. Terminology 🧚

This doc follows the terms defined in [RFC8724], [RFC8376], and [TR23720]. 📚

Here's the glossary, bestie. 🎀

  • Capillary Gateway: This one's iconic because it gives you seamless integration. It has wide-area connectivity through cellular and acts as a proxy for other devices using LAN technologies (BT, Wi-Fi, Zigbee, or others). 🌈
  • Cellular IoT Evolved Packet System (CIoT EPS): A functionality that improves support for small data transfers. 🦋
  • Device UE (Dev-UE): As defined in [RFC8376], Section 3. 💜
  • Data over Non-Access Stratum (DoNAS): Sending user data inside signaling messages over the NAS functional layer. 🍓
  • Evolved Packet Connectivity (EPC): The core network of 3GPP LTE systems. ✨
  • Evolved Universal Terrestrial Radio Access Network (EUTRAN): The radio access network of LTE-based systems. 🌸
  • Hybrid Automatic Repeat reQuest (HARQ): A combo of high-rate Forward Error Correction (FEC) and Automatic Repeat reQuest (ARQ) error control. 🔥
  • Home Subscriber Server (HSS): A database holding users' subscription data, including what's needed for mobility management. 👑
  • IP address: IPv6 or IPv4 address used. 🫶
  • InterWorking Service Capabilities Exposure Function (IWK-SCEF): Used in roaming scenarios. It's located in the Visited PLMN and handles interconnection with the Service Capabilities Exposure Function (SCEF) of the Home PLMN. 🌈
  • Layer 2 (L2): In the 3GPP architectures, L2 includes the MAC, RLC, and PDCP layers. See Appendix A. 💖
  • Logical Channel ID (LCID): The logical channel instance of the corresponding MAC SDU. 🎀
  • Medium Access Control (MAC) protocol: Part of L2. 🦋
  • Non-Access Stratum (NAS): The functional layer for signaling messages that sets up communication sessions and keeps them going while the user moves. 🧚
  • Narrowband IoT (NB-IoT): A 3GPP Low-Power WAN (LPWAN) technology based on the LTE architecture, but with extra optimization for IoT and using a narrowband spectrum frequency. ✨
  • Network Gateway - CIoT Serving Gateway Node (NGW-CSGN): As defined in [RFC8376], Section 3. 💜
  • Network Gateway - Cellular Serving Gateway (NGW-CSGW): Routes and forwards user data packets through the access network. 🌸
  • Network Gateway - Mobility Management Entity (NGW-MME): The entity in charge of handling mobility of the Dev-UE. 👑
  • Network Gateway - Packet Data Network Gateway (NGW-PGW): An interface between the internal and external network. 🍓
  • Network Gateway - Service Capability Exposure Function (NGW-SCEF): An EPC node for exposing 3GPP network service capabilities to third-party applications. 🔥
  • Non-IP Data Delivery (NIDD): End-to-end communication between the UE and the Application Server. 🫶
  • Packet Data Convergence Protocol (PDCP): Part of L2. 🌈
  • Public Land-based Mobile Network (PLMN): A combo of wireless communication services offered by a specific operator. 💅
  • Protocol Data Unit (PDU): A data packet, including headers, that gets sent between entities through a protocol. 🎀
  • Radio Link Protocol (RLC): Part of L2. 🦋
  • Radio Gateway - evolved Node B (RGW-eNB): A base station that controls the UE. 💖
  • Service Data Unit (SDU): A data packet (PDU) from higher-layer protocols, used by lower-layer protocols as the payload of their own PDUs. 🧚

4. NB-IoT Architecture ✨

Okay so the NB-IoT architecture is honestly complicated. 💀 It relies on different Network Gateways (NGWs) from different providers. Data can travel along different paths, and each path has its own characteristics for bandwidth, acknowledgments, and L2 reliability and segmentation. 🌸

Figure 1 shows the architecture. The Network Gateway - Cellular IoT Serving Gateway Node (NGW-CSGN) helps co-locate entities across the different paths. For example, a Dev-UE using the path formed by the NGW-MME, the NGW-CSGW, and the NGW-PGW might only get limited bandwidth, anywhere from a few bytes/s to one thousand bytes/s only. 🙈

Another node in the NB-IoT architecture is the Network Gateway - Service Capability Exposure Function (NGW-SCEF), which securely exposes service and network capabilities to entities outside the network operator. 🔒 The Open Mobile Alliance (OMA) [OMA0116] and the One Machine to Machine (OneM2M) [TR-0024] define the northbound APIs. [TS23222] defines the architecture for the common API framework for 3GPP northbound APIs, and [TS33122] defines the security aspects of that same framework. 👑 In this case the path is small for data transmission. The main functions of the NGW-SCEF are path connectivity and device monitoring. 💜

Here's the diagram, bestie. 🎀

   +---+              +---------+    +------+
   |Dev| \            | +-----+ | ---| HSS  |
   |-UE|  \           | | NGW | |    +------+
   +---+  |           | |-MME |\__
           \          / +-----+ | \
   +---+    \+-----+ /|   |     | +------+
   |Dev| ----| RGW |- |   |     | | NGW- |
   |-UE|     |-eNB |  |   |     | | SCEF |---------+
   +---+    /+-----+ \|   |     | +------+         |
           /          \ +------+|                  |
          /           |\| NGW- || +-----+   +-----------+
   +---+ /            | | CSGW |--| NGW-|---|Application|
   |Dev|              | |      || | PGW |   |   Server  |
   |-UE|              | +------+| +-----+   +-----------+
   +---+              |         |
                      |NGW-CSGN |
                      +---------+

                    Figure 1: 3GPP Network Architecture

That's the whole picture so far, and we've got more to cover in the next part. 🧚💖

5. Data Transmission in the 3GPP Architecture ✨

okay so NB-IoT networks handle two kinds of stuff: the actual end-to-end user data, and in-band signaling. The signaling is the behind-the-scenes chatter that configures, controls, and monitors what the system is doing 🔧. It takes a different path, with its own protocols, handling processes, and entities, but it can still carry end-to-end user data for IoT services. The end-to-end application, meanwhile, only moves end-to-end data 💅.

The recommended 3GPP MTU size is 1358 bytes 🎀. The radio network protocols cap packet sizes over the air at 1600 bytes, radio protocol overhead included (see Section 5.2.3). But the recommended 3GPP MTU is smaller on purpose, so packets don't get fragmented in the network backbone. The reasons are the payload encryption size (a multiple of 16) and the extra overhead the core transport has to handle 🫶.

3GPP standardizes NB-IoT and, in general, the interfaces and functions of cellular technologies. So if SCHC entities are going to show up on Dev-UE, RGW-eNB, and NGW-CSGN, that has to be specified in the NB-IoT standard 📜.

This document identifies the use cases of SCHC over the NB-IoT architecture 🦋.

The first use case is radio transmission (see Section 5.2.1), where the Dev-UE and the RGW-eNB can use the SCHC functionalities 📡.

The second is where packets sent over the control path can also use SCHC, when the transmission goes over the NGW-MME or NGW-SCEF (see Section 5.2.2) 🌸.

Both of these use cases are also valid for any 3GPP architecture, not only NB-IoT. Because the 3GPP internal network is involved, they've been put in the informational part of this section 🙈.

The third covers SCHC over Non-IP Data Delivery (NIDD) connections, or at least up to the operator network edge (see Section 5.1.1). Here, SCHC functionalities live in the application layer of the Dev-UE and the Application Servers, or in a broker function at the edge of the operator network. NGW-PGW or NGW-SCEF carry the Non-IP traffic, using IP tunneling or API calls. It's also possible to give legacy devices SCHC benefits by using the Non-IP transmission features of the operator network 🧚.

A Non-IP transmission refers to an L2 transport that is different from NB-IoT ✨.

5.1. Normative Scenarios

These scenarios don't modify the 3GPP architecture or any of its components. They only use the architecture as an L2 transmission 💜.

5.1.1. SCHC over Non-IP Data Delivery (NIDD)

This section specifies the use of SCHC over the NIDD services of 3GPP. Those services let SCHC packets compressed by the application layer travel through the network 🚀. The packets can be delivered between the NGW-PGW and the Application Server, or between the NGW-SCEF and the Application Server, using IP tunnels or API calls. In both cases, compression happens before transmission, so the network won't understand the packet and has no context information about the compression. That means the network treats the packet as Non-IP traffic and delivers it to the other side without any other protocol stack element, directly over L2 💅.

5.1.1.1. SCHC Entities Placing over NIDD

In the two scenarios that use NIDD compression, the SCHC entities sit almost right on top of the stack 🥞. The NB-IoT connectivity services implement SCHC in the Dev-UE and in the Application Server. The IP tunneling scenario requires the Application Server to send the compressed packet over an IP connection terminated by the 3GPP core network 🔐. If the transmission uses the NGW-SCEF services, an API call can be used to move the SCHC packets between the core network and the Application Server 📞. An IP tunnel can also be set up by the Application Server, if it's negotiated with the NGW-SCEF 🤝.

  +---------+       XXXXXXXXXXXXXXXXXXXXXXXX             +--------+
  | SCHC    |      XXX                    XXX            | SCHC   |
  |(Non-IP) +-----XX........................XX....+--*---+(Non-IP)|
  +---------+    XX                  +----+  XX   |  |   +--------+
  |         |    XX                  |SCEF+-------+  |   |        |
  |         |   XXX     3GPP RAN &   +----+  XXX     +---+  UDP   |
  |         |   XXX    CORE NETWORK          XXX     |   |        |
  |  L2     +---+XX                  +------------+  |   +--------+
  |         |     XX                 |IP TUNNELING+--+   |        |
  |         |      XXX               +------------+  +---+  IP    |
  +---------+       XXXX                 XXXX        |   +--------+
  | PHY     +------+ XXXXXXXXXXXXXXXXXXXXXXX         +---+  PHY   |
  +---------+                                            +--------+
    Dev-UE                                              Application
                                                           Server

    Figure 2: End-to-End Compression: SCHC Entities Placed when Using
                   Non-IP Delivery (NIDD) 3GPP Services

5.1.1.2. Parameters for Static Context Header Compression and Fragmentation (SCHC)

These scenarios MAY use the SCHC header compression capability to improve the transmission of IPv6 packets 🎀.

  • SCHC Context Initialization: The application layer handles the static context, so the context distribution MUST follow the application's capabilities, maybe using IP data transmissions up until context initialization 🫶. The static context delivery may also use the same IP tunneling or NGW-SCEF services that are used later for carrying SCHC packets.
  • SCHC Rules: For devices acting as a capillary gateway, several rules are needed to match the variety of devices and protocols connected to the gateway 🌈. Simpler devices, meanwhile, may have predetermined protocols and fixed parameters 🍓.
  • RuleID: This scenario can set the RuleID size dynamically before the context delivery, for example by negotiating between the applications and picking a profile based on the type of traffic and application deployed 💖. Transmission optimization may require only one Physical Layer transmission. SCHC overhead SHOULD NOT exceed the number of effective bits in the smallest physical Transport Block (TB) available, so the transmission stays optimized 🔥. The packets handled by 3GPP networks are byte-aligned, so to use the smallest TB, the maximum SCHC header size is 12 bits 🙈. More complex NB-IoT devices, like a capillary gateway, might need extra bits to handle the variety and multiple parameters of higher-layer protocols deployed 👑. The configuration may be part of the agreed operation profile and content distribution. The RuleID field size may range from 2 bits (4 rules) up to an 8-bit value (up to 256 rules) for use by operators 💅. A 256-rule maximum seems quite reasonable, even for a device acting as a NAT ✨. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue. In the minimum TB size case, 2 bits of RuleID leave only 6 bits for Compression Residue 😭.
  • SCHC MAX_PACKET_SIZE: In these scenarios, the maximum RECOMMENDED MTU size is 1358 bytes, since SCHC packets (and fragments) travel across the whole 3GPP network infrastructure (core and radio), not only the radio like in IP transmissions 🛰️.
  • Fragmentation: Packets larger than 1358 bytes need the SCHC fragmentation function 🧩. Since 3GPP uses reliability functions, the No-ACK fragmentation mode MAY be enough in point-to-point connections 🦋. Still, there are some extra considerations for more complex cases, described below 👀.
  • Fragmentation Modes: A global service assigns a QoS to packets, for example depending on billing 💸. Packets with very low QoS may get lost before they reach the 3GPP radio network transmission, for instance between the links of a capillary gateway, or because of buffer overflow handling in a backhaul connection 😱. Using SCHC fragmentation with the ACK-on-Error mode is RECOMMENDED for extra reliability on packets sent with a small trade-off in further transmissions, used to signal the end-to-end arrival of packets when no transport protocol takes care of retransmission 🔁. The ACK-on-Error mode could also be useful for keeping track of all the SCHC packets delivered. In that case, the fragmentation function could be activated for all packets the applications transmit 📋. SCHC ACK-on-Error fragmentation MAY be activated when transmitting Non-IP packets on the NGW-MME. A Non-IP packet will use the SCHC reserved RuleID for non-compressing packets, since [RFC8724] allows it 🌸.
  • Fragmentation Parameters: The SCHC profile will have specific Rules for the fragmentation modes. Each rule identifies which fragmentation mode is in use, and Section 5.2.3 defines the RuleID size 📏.

SCHC parametrization takes into account that NB-IoT aligns the bits and uses padding, along with the size of the Transfer Block. SCHC will try to reduce padding so the information is compressed as well as possible 🧠. The header size needs to be a multiple of 4. The Tiles MAY keep a fixed value of 4 or 8 bits to avoid padding, except when the transfer block equals 16 bits, since the Tiles may then be 2 bits 🧱. The transfer block size has a wide range of values, so two configurations are RECOMMENDED for the fragmentation parameters 💜:

  • For Transfer Blocks smaller than or equal to 304 bits using an 8-bit Header_size configuration, with the size of the header fields as follows:
    • RuleID from 1 - 3 bits
    • DTag 1 bit
    • FCN 3 bits
    • W 1 bits
  • For Transfer Blocks bigger than 304 bits using a 16-bit Header_size configuration, with the size of the header fields as follows:
    • RulesID from 8 - 10 bits
    • DTag 1 or 2 bits
    • FCN 3 bits
    • W 2 or 3 bits
  • WINDOW_SIZE of (2^N)-1 is RECOMMENDED 🪟.
  • The Reassembly Check Sequence (RCS) will follow the default size 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 this value based on transmission conditions 🎚️.

IoT devices communicate with small data transfers and use the Power Save Mode and the Idle Mode Discontinuous Reception (DRX). These govern how often the device wakes up, how long it stays up, and when it's reachable ⏰. Using the different modes lets the battery last ten years 🔋. Table 10.5.163a in [TS24008] defines the radio timer values, with units incrementing by N. The units of N can be 1 hour or 10 hours. The range used for IoT is N to 3N, where N increments by one. The Inactivity Timer and the Retransmission Timer can be set based on these limits ⭐.

5.2. Informational Scenarios

These scenarios show how 3GPP could use SCHC for its transmissions 🌟.

Okay bestie, deploying SCHC over just the Radio Link means slotting it into the protocol stack that moves data between the Dev-UE and the RGW-eNB 💖. This layer is in charge of getting data across the wireless connection and managing radio resources, and it already has reliability, segmentation, and concatenation 💅. Then there's link adaptation, which is honestly iconic 🔥. The system tunes the transport format to the radio conditions, the number of bits to send, and the power and interference limits. So the number of bits that actually go over the air depends on which Modulation and Coding Schemes (MCSs) get picked.

Transport Block (TB) transmissions happen in the Physical Layer at network-synchronized intervals called Transmission Time Interval (TTI) ⏱️. Every TB can have its own MCS and its own number of bits available. The MAC layer [TR36321] is where the TB characteristics get defined 🧚. The Radio Link stack in Figure 3 is made up of the Packet Data Convergence Protocol (PDCP) [TS36323], the Radio Link Protocol (RLC) [TS36322], the Medium Access Control protocol (MAC) [TR36321], and the Physical Layer [TS36201]. Appendix A has all the deets 🎀.

+---------+                              +---------+  |
|IP/Non-IP+------------------------------+IP/Non-IP+->+
+---------+   |   +---------------+   |  +---------+  |
| PDCP    +-------+ PDCP  | GTP|U +------+ GTP-U   |->+
| (SCHC)  +       + (SCHC)|       +      +         |  |
+---------+   |   +---------------+   |  +---------+  |
| RLC     +-------+ RLC   |UDP/IP +------+ UDP/IP  +->+
+---------+   |   +---------------+   |  +---------+  |
| MAC     +-------+ MAC   | L2    +------+ L2      +->+
+---------+   |   +---------------+   |  +---------+  |
| PHY     +-------+ PHY   | PHY   +------+ PHY     +->+
+---------+       +---------------+      +---------+  |
           C-Uu/                    S1-U             SGi
  Dev-UE               RGW-eNB             NGW-CSGN
          Radio Link

                  Figure 3: SCHC over the Radio Link

The 3GPP architecture already supports Robust Header Compression (ROHC) [RFC5795] in the PDCP layer 🌸. That means SCHC header compression entities can be placed in a similar way without needing big changes to the 3GPP specifications 🫶.

The RLC layer has three functional modes: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The mode of operation is what controls what RLC can do 👑. TM only applies to signaling packets, while AM or UM carry signaling and data packets.

The RLC layer takes care of fragmentation except for TM. In AM or UM, SCHC fragmentation is unnecessary and SHOULD NOT be used 🙅. When it comes to sending IP packets, the Radio Link doesn't commonly use RLC TM 🤷. Still, if other protocol overhead optimizations get targeted for NB-IoT traffic, SCHC fragmentation may be used for TM transmission in the future 🔮.

5.2.2. Use of SCHC over the Non-Access Stratum (NAS) 🌈

This section is made up of IETF suggestions to the 3GPP 💌. The NGW-MME mostly handles signaling between the Dev-UE and the cellular network [TR24301], and the network carries this traffic on top of the Radio Link 🛣️.

This kind of flow supports data transmissions that cut down on overhead when you're sending small amounts of data now and then. It's known as Data over Non-Access Stratum (DoNAS) or Control Plane CIoT EPS optimizations 🍓. With DoNAS, the Dev-UE reuses the pre-established security, can piggyback small uplink data onto the initial uplink message, and uses one extra message to receive a small downlink data response 🎁.

The NGW-MME does the data encryption from the network side in a DoNAS PDU 🔐. Depending on the data type signaled indication (IP or Non-IP data), the network either allocates an IP address or sets up a direct forwarding path ✨. DoNAS runs under rate control that was agreed on beforehand, which means a maximum number of bits per unit of time is agreed upon per device subscription in advance and then configured in the device 📏.

The system will use DoNAS when a terminal in a power-saving state needs a short transmission and gets an acknowledgment or short feedback from the network 💤. Depending on the size of the buffered data, the Dev-UE might use connected mode transmission instead 🔄. Connected mode would limit and control DoNAS transmissions to predefined thresholds, which makes it a great resource optimization balance for both the terminal and the network ⚖️. DoNAS does support mobility, but that comes with additional overhead 🐢. Appendix B has more DoNAS details 📚.

5.2.2.1. Placing SCHC Entities over DoNAS 💜

SCHC lives in this scenario's Non-Access Stratum (NAS) protocol layer 🏠. The same principles from Section 5.2.1 apply here too 🙌. Since the NAS protocol already uses ROHC [RFC5795], it can also adapt SCHC for header compression 🧩. The main difference compared to the Radio Link (Section 5.2.1) is where the SCHC entities physically sit. On the network side, the NGW-MME lives in the core network and is the terminating node for NAS instead of the RGW-eNB 🏰.

+--------+                       +--------+--------+  +  +--------+
| IP/    +--+-----------------+--+  IP/   |   IP/  +-----+   IP/  |
| Non-IP |  |                 |  | Non-IP | Non-IP |  |  | Non-IP |
+--------+  |                 |  +-----------------+  |  +--------+
| NAS    +-----------------------+   NAS  |GTP-C/U +-----+GTP-C/U |
|(SCHC)  |  |                 |  | (SCHC) |        |  |  |        |
+--------+  |  +-----------+  |  +-----------------+  |  +--------+
| RRC    +-----+RRC  |S1|AP+-----+ S1|AP  |        |  |  |        |
+--------+  |  +-----------+  |  +--------+  UDP   +-----+  UDP   |
| PDCP*  +-----+PDCP*|SCTP +-----+ SCTP   |        |  |  |        |
+--------+  |  +-----------+  |  +-----------------+  |  +--------+
| RLC    +-----+ RLC | IP  +-----+ IP     | IP     +-----+ IP     |
+--------+  |  +-----------+  |  +-----------------+  |  +--------+
| MAC    +-----+ MAC | L2  +-----+ L2     | L2     +-----+ L2     |
+--------+  |  +-----------+  |  +-----------------+  |  +--------+
| PHY    +--+--+ PHY | PHY +--+--+ PHY    | PHY    +-----+ PHY    |
+--------+     +-----+-----+     +--------+--------+  |  +--------+
           C-Uu/             S1                   SGi
 Dev-UE           RGW-eNB               NGW-MME             NGW-PGW

    *PDCP is bypassed until AS security is activated TGPP36300.

  Figure 4: SCHC Entities Placement in the 3GPP CIOT Radio Protocol
                 Architecture for DoNAS Transmissions

If 3GPP incorporates SCHC, it is recommended that these scenarios use the SCHC header compression [RFC8724] capability to optimize data transmission 💅.

  • SCHC Context Initialization 🌷

The Radio Resource Control (RRC) protocol is the main tool for configuring the parameters of the Radio Link 🎛️. It will configure SCHC and the static context distribution the same way it was built for ROHC operation [RFC5795] [TS36323] 🫧.

  • SCHC Rules 📜

The network operator defines the number of rules in these scenarios, and to do that, the network operator must know the IP traffic the device will carry 🕵️. The operator might supply rules that match the device's use case. For devices acting as a capillary gateway, several rules are needed to cover the diversity of devices and protocols associated with the gateway 🌐. Simpler devices may have predetermined protocols and fixed parameters 🧸. Using IPv6 and IPv4 may force the operator to develop more rules to handle each case 😵‍💫.

  • RuleID 🔑

There is a reasonable assumption of 9 bytes of radio protocol overhead for these transmission scenarios in NB-IoT. PDCP uses 5 bytes for header and integrity protection, and RLC and MAC use 4 bytes 📐. The minimum physical TBs that can hold this overhead, according to the 3GPP Release 15 specification [R15-3GPP], are 88, 104, 120, and 144 bits 🧮. As for Section 5.1.1.2, these scenarios must optimize the Physical Layer, where the smallest TB is 12 bits 🤏. Those 12 bits must include the Compression Residue in addition to the RuleID 🧃. More complex NB-IoT devices (such as a capillary gateway) might need additional bits to handle the variety and multiple parameters of the higher-layer protocols deployed 🏗️. So the operator may want flexibility in the number and type of rules each device supports independently, which is why these scenarios require a configurable value ⚙️. The configuration may be part of the operation profile agreed on with the content distribution 🤝.

The RuleID field size can range from 2 bits, giving 4 rules, all the way up to an 8-bit value, yielding up to 256 rules for use with the operators 🌈. A 256-rule maximum seems quite reasonable, even for a device acting as a NAT 🙆. An application may use a larger RuleID, but it should consider the byte alignment of the expected Compression Residue 📏. In the minimum TB size case, 2 bits of RuleID leave only 6 bits available for Compression Residue 🥺.

  • SCHC MAX_PACKET_SIZE 📦

The Radio Link can handle fragmentation of SCHC packets if needed, including reliability 🛡️. So the packet size is limited by the MTU that the radio protocols handle, which corresponds to 1600 bytes for 3GPP Release 15 📏.

  • Fragmentation ✂️

For the Radio Link (Section 5.2.1) and DoNAS (Section 5.2.2) scenarios, the SCHC fragmentation functions are disabled 🚫. The RLC layer of NB-IoT can segment packets into suitable units that fit the selected TB for Physical Layer transmissions 🧩. The block selection is made according to the link adaptation input function in the MAC layer and the amount of data in the buffer 📊. The link adaptation layer may give different results at each TTI, which means the physical TBs can vary depending on network load, interference, number of bits transmitted, and QoS 🎢. Even if you set a value that allows building data units following the SCHC tiles principle, the protocol overhead may be greater than or equal to letting the Radio Link protocols take care of fragmentation intrinsically 🤔.

  • Fragmentation in RLC TM 🧱

The RLC TM mostly applies to control signaling transmissions 📡. When RLC operates in TM, the MAC layer mechanisms ensure reliability and generate overhead 😩. This additional reliability implies sending repetitions or automatic retransmissions 🔁.

The ACK-Always fragmentation mode of SCHC may reduce this overhead in future operations, when data transmissions may use this mode ✨. The ACK-Always mode may transmit compressed data with fewer possible transmissions by using fixed or limited TBs that are compatible with the tiling SCHC fragmentation handling 🧠. For SCHC fragmentation parameters, see Section 5.1.1.2 💖.

6. Padding 🎀

Okay so, NB-IoT and 3GPP wireless access basically assume everything is byte-aligned 🫶. That means the L2 Word for NB-IoT MUST be considered 8 bits 💅, and your padding treatment should use that value.

7. IANA Considerations 🦋

No IANA actions here, bestie. This document has no IANA actions at all 🙈

8. Security Considerations 🛡️

Okay, this one is short but important 😭 This document does not add any security considerations of its own. It follows [RFC8724] and the 3GPP access security document specified in [TS33122], so make sure you read those too 📚

9. References ✨

9.1. Normative References

9.2. Informative References

Appendix A. NB-IoT User Plane Protocol Architecture 🌈

A.1. Packet Data Convergence Protocol (PDCP) 💜

Each of the Radio Bearers (RBs) is associated with one PDCP entity [TS36323]. A PDCP entity can be tied to one or two RLC entities, depending on whether the RB is unidirectional or bidirectional and which RLC mode is in use. A PDCP entity is associated with either a control plane or a user plane, and each one has its own independent configuration and functions. The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. The main services and functions of the PDCP sublayer for NB-IoT for the user plane are:

  • Header compression and decompression using ROHC [RFC5795]
  • Transfer of user and control data to higher and lower layers
  • Duplicate detection of lower-layer SDUs when re-establishing connection (when RLC with Acknowledge Mode is in use for User Plane only)
  • Ciphering and deciphering
  • Timer-based SDU discard in uplink

RLC [TS36322] is an L2 protocol that operates between the User Equipment (UE) and the base station (eNB) 📡 It supports packet delivery from higher layers to MAC, creating the packets that get transmitted over the air, and it optimizes TB utilization. RLC data flow is unidirectional. It is made up of a transmitter in the sending device and a receiver in the destination device. So to set up bidirectional flows, you need two sets of entities, one in each direction (downlink and uplink), and they have to be peered with each other. The peering is what allows control packets (e.g., status reports) to be sent between entities. RLC can be configured for data transfer in one of the following modes:

  • Transparent Mode (TM) RLC does not segment or concatenate SDUs from higher layers in this mode and does not include any header with the payload. When acting as a transmitter, RLC receives SDUs from upper layers and transmits them directly to its flow RLC receiver via lower layers. Similarly, upon reception, a TM RLC receiver does not process the packets and only delivers them to higher layers.
  • Unacknowledged Mode (UM) This mode supports 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 it is octet-aligned. Packet delivery to the receiver has no reliability support, so losing a segment from a packet means losing the whole packet. Also, lower-layer retransmissions do not support re-segmentation if 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.
  • Acknowledged Mode (AM) On top of everything UM does, this mode 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 Reports, and to trigger retransmissions. This mode also supports protocol-error detection. The mode used depends on the operator configuration for the type of data being sent. For example, data transmissions that support mobility or require high reliability would most likely be configured with 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-layer abstraction called Logical Channels (which are made up of the previously described protocols) and the Physical Layer channels (transport channels). MAC may also multiplex packets from different Logical Channels and prioritize which ones 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-layer data.

Here's the packet encapsulation example, bestie. Look at how the layers stack up 👀

                                               <Max. 1600 bytes>
                       +---+         +---+          +------+
   Application         |AP1|         |AP1|          |  AP2 |
   (IP/Non-IP)         |PDU|         |PDU|          |  PDU |
                       +---+         +---+          +------+
                       |   |         |  |           |      |
   PDCP           +--------+    +--------      +-----------+
                  |PDCP|AP1|    |PDCP|AP1|     |PDCP|  AP2 |
                  |Head|PDU|    |Head|PDU|     |Head|  PDU |
                  +--------+    +--------+     +--------+--\
                  |    |   |    |     |  |     |    |   |\  `--------\
            +---------------------------+      |    |(1)| `-------\(2)\
   RLC      |RLC |PDCP|AP1|RLC |PDCP|AP1| +-------------+    +----|---+
            |Head|Head|PDU|Head|Head|PDU| |RLC |PDCP|AP2|    |RLC |AP2|
            +-------------|-------------+ |Head|Head|PDU|    |Head|PDU|
            |         |   |         |   | +---------|---+    +--------+
            |         |   | LCID1   |   | /         /   /   /         /
           /         /   /        _/  _//        _/  _/    / LCID2   /
           |        |   |        |   | /       _/  _/     /      ___/
           |        |   |        |   ||       |   |      /      /
       +------------------------------------------+ +-----------+---+
   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|
       |der|der|der |   |der|der |   |der|der |   | |der|der|   |g  |
       +------------------------------------------+ +-----------+---+
                         TB1                               TB2

   (1) Segment One
   (2) Segment Two

        Figure 5: Example of User Plane Packet Encapsulation for Two
                              Transport Blocks

Appendix B. NB-IoT Data over NAS (DoNAS) ✨

okay bestie, so the AS protocol stack for DoNAS is lowkey special 🎀 because the radio network still has to set up the security associations AND cut down the protocol overhead, so PDCP just gets bypassed until AS security is activated 🙈. By default RLC uses AM 💖. But depending on the network's features and the terminal, the network operator can switch RLC to other modes 🦋. For example, TM doesn't add any header or process the payload (less overhead, yay 🌸), but the MTU is limited by the TB used to send the data, which is a couple thousand bits max 💀. If UM is used (only terminals compatible with 3GPP Release 15 [R15-3GPP] can do this 🧚), the RLC reliability mechanisms are disabled, and the only reliability left is the MAC layer's HARQ 😭. The overhead might be smaller than the AM case since there's no status reporting, but it still has the same support for segmentation up to 1600 bytes ✨. NAS packets get wrapped inside an RRC [TS36331] message 🫶.

Depending on the data type indication signaled (IP or Non-IP data), the network either allocates an IP address or sets up a direct forwarding path 🌈. DoNAS is under rate control by previous agreement, which means a maximum number of bits per unit of time is agreed upon per device subscription beforehand and configured in the device 💅. DoNAS is typically expected when a terminal in a power-saving state needs a short transmission and is receiving an acknowledgment or short feedback from the network 🌸. Depending on how much buffered data needs to go out, the UE might be told to use connected mode transmissions instead, so DoNAS transmissions stay limited and controlled to predefined thresholds, with a good resource optimization balance for the terminal and the network 👑. The support for mobility of DoNAS is there, but it comes with additional overhead 😭.

      +--------+   +--------+   +--------+
      |        |   |        |   |        |       +-----------------+
      |   UE   |   |  C-BS  |   |  C-SGN |       |Roaming Scenarios|
      +----|---+   +--------+   +--------+       |  +--------+     |
           |            |            |           |  |        |     |
       +----------------|------------|+          |  |  P-GW  |     |
       |        Attach                |          |  +--------+     |
       +------------------------------+          |       |         |
           |            |            |           |       |         |
    +------|------------|--------+   |           |       |         |
    |RRC connection establishment|   |           |       |         |
    |with NAS PDU transmission   |   |           |       |         |
    |& Ack Rsp                   |   |           |       |         |
    +----------------------------+   |           |       |         |
           |            |            |           |       |         |
           |            |Initial UE  |           |       |         |
           |            |message     |           |       |         |
           |            |----------->|           |       |         |
           |            |            |           |       |         |
           |            | +---------------------+|       |         |
           |            | |Checks Integrity     ||       |         |
           |            | |protection, decrypts ||       |         |
           |            | |data                 ||       |         |
           |            | +---------------------+|       |         |
           |            |            |       Small data packet     |
           |            |            |------------------------------->
           |            |            |       Small data packet     |
           |            |            |<-------------------------------
           |            | +----------|---------+ |       |         |
           |            | Integrity protection,| |       |         |
           |            | encrypts data        | |       |         |
           |            | +--------------------+ |       |         |
           |            |            |           |       |         |
           |            |Downlink NAS|           |       |         |
           |            |message     |           |       |         |
           |            |<-----------|           |       |         |
   +-----------------------+         |           |       |         |
   |Small data delivery,   |         |           |       |         |
   |RRC connection release |         |           |       |         |
   +-----------------------+         |           |       |         |
                                                 |                 |
                                                 |                 |
                                                 +-----------------+

Figure 6: DoNAS Transmission Sequence from an Uplink Initiated Access 🦋

                      +---+ +---+ +---+                  +----+
    Application       |AP1| |AP1| |AP2|                  |AP2 |
   (IP/Non-IP)        |PDU| |PDU| |PDU|  ............... |PDU |
                      +---+ +---+ +---+                  +----+
                      |   | |   | |   |                  |    |
                      |   | |   | |   |                  |    |
                      |   | |   | |   |                  |    |
                      |   | |   | |   |                  |    |
                      |   |/   /  |    \                 |    |
   NAS /RRC      +--------+---|---+----+            +---------+
                 |NAS/|AP1|AP1|AP2|NAS/|            |NAS/|AP2 |
                 |RRC |PDU|PDU|PDU|RRC |            |RRC |PDU |
                 +--------+-|-+---+----+            +---------|
                 |          |         |            |         |
                 |          |\         |            |         |
                 |<--Max. 1600 bytes-->|__          |_        |
                 |          |  \__        \___        \_       \
                 |          |     \           \         \__     \
                 |          |      \          |           |      \_
            +---------------|+-----|----------+            \       \
   RLC      |RLC | NAS/RRC  ||RLC  | NAS/RRC  |       +----|-------+
            |Head|  PDU(1/2)||Head | PDU (2/2)|       |RLC |NAS/RRC|
            +---------------++----------------+       |Head|PDU    |
            |    |          | \               |       +------------+
            |    |    LCID1 |  \              |       |           /
            |    |          |   \              \      |           |
            |    |          |    \              \     |           |
            |    |          |     \              \     \          |
       +----+----+----------++-----|----+---------++----+---------|---+
   MAC |MAC |RLC |    RLC   ||MAC  |RLC |  RLC    ||MAC |  RLC    |Pad|
       |Head|Head|  PAYLOAD ||Head |Head| PAYLOAD ||Head|  PDU    |   |
       +----+----+----------++-----+----+---------++----+---------+---+
                TB1                   TB2                     TB3

Figure 7: Example of User Plane Packet Encapsulation for Data over NAS 💖

Acknowledgements 🫶

the authors wanna give a big shoutout (in alphabetic order) 📣 to Carles Gomez, Antti Ratilainen, Pascal Thubert, Tuomas Tirronen, and Éric Vyncke. 💜

Authors' Addresses 🎀

these are the bestie authors 👯‍♀️ Edgar Ramos and Ana Minaburo 🌈

Edgar Ramos
Ericsson
Hirsalantie 11
FI-02420 Jorvas, Kirkkonummi
Finland
Email: edgar.ramos@ericsson.com
Ana Minaburo
Acklio
1137A Avenue des Champs Blancs
35510 Cesson-Sevigne Cedex
France
Email: ana@ackl.io
📦 where this page comes from