lpwan Working Group                                             E. Ramos
Internet-Draft                                                  Ericsson
Intended status: Informational                               A. Minaburo
Expires: January 26, April 25, 2022                                           Acklio
                                                           July 25,
                                                        October 22, 2021

                            SCHC over NB-IoT
                  draft-ietf-lpwan-schc-over-nbiot-05
                  draft-ietf-lpwan-schc-over-nbiot-06

Abstract

   The Static Context Header Compression (SCHC) specification describes
   a
   header compression and fragmentation functionalities for LPWAN (Low
   Power Wide Area Networks) technologies.
   The Narrow Band Internet of Things (NB-IoT) architecture may adapt
   SCHC was designed to be
   adapted over any of the LPWAN technologies. improve its capacities.

   This document describes the use of SCHC over the NB-IoT wireless
   access,
   access and provides elements for an efficient parameterization.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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 http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 26, April 25, 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Data Transmission . . . . . . . . . . . . . . . . . . . . . .   6   5
   5.  IP based Data Transmission  . . . . . . . . . . . . . . . . .   7   6
     5.1.  SCHC over User Plane transmissions the Radio link  . . . . . . . . . . .   7
       5.1.1.  SCHC Entities Placing . . . . .   6
       5.1.1.  SCHC Entities Placing . . . . . . . . . . .   8
     5.2.  Data Over Control Plane . . . . .   6
     5.2.  SCHC over No-Access Stratum (NAS) . . . . . . . . . . . .   8   7
       5.2.1.  SCHC Entities Placing . . . . . . . . . . . . . . . .   9   8
     5.3.  Parameters for Static Context Header Compression (SCHC) .  10   9
       5.3.1.  SCHC Context initialization . . . . . . . . . . . . .  10   9
       5.3.2.  SCHC Rules  . . . . . . . . . . . . . . . . . . . . .  10   9
       5.3.3.  Rule ID . . . . . . . . . . . . . . . . . . . . . . .  11   9
       5.3.4.  SCHC MAX_PACKET_SIZE  . . . . . . . . . . . . . . . .  11  10
       5.3.5.  Fragmentation . . . . . . . . . . . . . . . . . . . .  11  10
   6.  Non-IP based Data Transmission  End-to-End Compression  . . . . . . . . . . . . . . .  12 . . . .  10
     6.1.  SCHC Entities Placing . . . . . . . . . . . . . . . . . .  12  11
     6.2.  Parameters for Static Context Header Compression  . . . .  13  11
       6.2.1.  SCHC Context initialization . . . . . . . . . . . . .  13  11
       6.2.2.  SCHC Rules  . . . . . . . . . . . . . . . . . . . . .  13  12
       6.2.3.  Rule ID . . . . . . . . . . . . . . . . . . . . . . .  14  12
       6.2.4.  SCHC MAX_PACKET_SIZE  . . . . . . . . . . . . . . . .  14  12
     6.3.  Fragmentation . . . . . . . . . . . . . . . . . . . . . .  14  12
       6.3.1.  Fragmentation modes . . . . . . . . . . . . . . . . .  14  12
       6.3.2.  Fragmentation Parameters  . . . . . . . . . . . . . .  15  13
   7.  Padding . . . . . . . . . . . . . . . . . . . . . . . . . . .  15  13
   8.  Security considerations . . . . . . . . . . . . . . . . . . .  15  13
   9.  3GPP References . . . . . . . . . . . . . . . . . . . . . . .  15  14
   10. Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  16  14
     10.1.  NB-IoT User Plane protocol architecture  . . . . . . . .  16  14
       10.1.1.  Packet Data Convergence Protocol (PDCP)  . . . . . .  16  14
       10.1.2.  Radio Link Protocol (RLC)  . . . . . . . . . . . . .  17  15
       10.1.3.  Medium Access Control (MAC)  . . . . . . . . . . . .  18  16
     10.2.  NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . .  19  17
   11. Normative References  . . . . . . . . . . . . . . . . . . . .  21  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22  21

1.  Introduction

   The Static Context Header Compression (SCHC) [RFC8724] defines a
   header compression scheme scheme, and fragmentation functionality, both
   specially tailored functionality suitable
   for the Low Power Wide Area Networks (LPWAN) networks defined in
   [RFC8376].

   Header

   In an NB-IoT network, header compression is needed to efficiently bring brings Internet
   connectivity to the node within an NB-IoT network. node.  This document describes the SCHC uses a
   static context
   parameters used to performs the static context header compression with specific
   parameters that need to be adapted
   into the NB-IoT wireless access.  This document assumes functionality
   for NB-IoT of 3GPP release 15.
   Otherwise  Otherwise, the text explicitly
   mentions other versions' functionality is explicitly mentioned in
   the text.

   This document describes the use of SCHC and its parameterizing over
   the NB-IoT wireless access. functionality.

2.  Terminology

   This document will follow the terms defined in [RFC8724], in
   [RFC8376], and the TGPP23720.

   o  CIoT.  Cellular IoT

   o  C-SGN.  NGW-C-SGN.  Network Gateway - CIoT Serving Gateway Node

   o  UE.  Dev-UE.  Device - User Equipment

   o  eNB.  RGW-eNB.  Radio Gateway - Node B.  Base Station that controls the
      UE

   o  EPC.  Evolved Packet Connectivity.  Core network of 3GPP LTE
      systems.

   o  EUTRAN.  Evolved Universal Terrestrial Radio Access Network.
      Radio network from LTE based systems.

   o  MME.  NGW-MME.  Network Gateway - Mobility Management Entity.  Handle
      mobility of the UE

   o  NB-IoT.  Narrow Band IoT.  Referring to 3GPP LPWAN technology
      based in LTE architecture but with additional optimization for IoT
      and using a Narrow Band spectrum frequency.

   o  SGW.  NGW-SGW.  Network Gateway - Serving Gateway.  Routes and forwards
      the user data packets through the access network

   o  HSS.  Home Subscriber Server.  It is a database that performs
      mobility management

   o  PGW.  NGW-PGW.  Network Gateway - Packet Data Node Gateway.  An
      interface between the internal with the external network

   o  PDU.  Protocol Data Unit.  Data packets including headers that are
      transmitted between entities through a protocol.

   o  SDU.  Service Data Unit.  Data packets (PDUs) from higher layers
      protocols used by lower layer protocols as a payload of their own
      PDUs that has not yet been encapsulated.

   o  IWK-SCEF.  InterWorking Service Capabilities Exposure Function.
      Used in roaming scenarios and serves for interconnection with the
      SCEF of the Home PLMN and is located in the Visited PLMN

   o  SCEF.  NGW-SCEF.  Network Gateway - Service Capability Exposure Function.
      EPC node for exposure of 3GPP network service capabilities to 3rd
      party applications.

3.  Architecture

      +--+
    D |UE|

     +---+                            +------+
     |Dev| \              +-----+     +------+
      +--+ ----| HSS  |
     +---+  \             | MME |-----| HSS NGW |     +------+
            |
    E             |-MME |\__
             \          / +-----+     +------+
      +--+   \
     +---+    \+-----+ /    |
    V |UE|       +------+
     |Dev| ----| RGW |-     |
      +--+     |(eNB)|       |
    I NGW- |
     +---+     |-eNB |      |       | SCEF |---------+
              /+-----+ \    |       +------+         |
             /          \ +------+
    C                   |
            /            \|  NGW NGW- |  +------+   Service PDN
      +--+  +-----+   +-----------+
     +---+ /              |(S-GW)|--|  NGW |-- e.g. Internet
    E |UE|              | CSGW |--| NGW-|---|Application|
     |Dev|                |  |(P-GW)|
      +--+                +------+      |  | PGW |   |   Server  |
     +---+                +------+
    S  +-----+   +-----------+

                    Figure 1: 3GPP network architecture

   The Narrow Band Internet of Things (NB-IoT) architecture for 3GPP LTE network has been reused for NB-IoT with
   some optimizations a more
   complex structure.  It relies on different NGWs from different
   providers and simplifications known can send data by different paths, each path with
   different characteristics such as Cellular IoT (CIoT).
   Considering bandwidths, acknowledgments, and
   layer two reliability and segmentation.

   Figure 1 shows this architecture where the typical use cases for CIoT devices here are described
   some Network Gateway Cellular
   Internet of the additions to the LTE architecture specific for CIoT.
   C-SGN(CIoT Things Serving Gateway Node) is a deployment option co-locating
   EPS Node (NGW-CSGN) optimizes co-
   locating entities in the control plane and user plane paths (for different paths.  For example,
   MME + SGW + P-GW) and a Dev using the external interfaces of
   path form by the entities
   supported.  The C-SGN also supports at least some of Network Gateway Mobility Management Entity (NGW-
   MME), the following
   CIoT EPS Optimizations:

   o  Control Plane CIoT EPS Optimization for small data transmission.

   o  User Plane CIoT EPS Optimization for small data transmission.

   o  Necessary security procedures for efficient small data
      transmission.

   o  SMS without combined attach for NB-IoT only UEs.

   o  Paging optimizations for coverage enhancements.

   o  Support for non-IP data transmission via SGi tunneling and/or
      SCEF.

   o  Support for Attach without PDN (Packet NGW-CSGW, and Network Gateway Packet Data Network) connectivity. Node Gateway
   (NGW-PGW) may get a limited bandwidth transmission from few bytes/s
   to one thousand bytes/s only.

   Another node introduced in the CIOT NBIoT architecture is the SCEF (Service Network
   Gateway Service Capability Exposure Function) that provide means to Function (NGW-SCEF), which
   securely expose exposes service and network capabilities to entities
   external to the network operator.  The northbound APIS are defined by  OMA and OneM2M. OneM2M define the
   northbound APIS [TGPP33203].  In this case, the path is small for
   data transmission.  The main functions of a SCEF the NGW-SCEF are:

   o  Non-IP Data Delivery (NIDD) established through the SCEF.  Connectivity path

   o  Device Monitoring and exposure of event related to UE reachability, loss
      of connectivity, location reporting, roaming status, communication
      failure and change of IMEI-IMSI association.

                                             +-------+
                                             |  HSS  |
                                             +-+-----+
                                  NGW         /
    DEV              RGW      +---------+  __/S6a
                 +--------+   | +-----+ +_/                  NGW
   +----+ C-Uu   |        +---+-+ MME | | T6i+--------+ T7 +----+
   |CIOT+--------+  eNB   |S1 | |     +-+----+IWK-SCEF+----+SCEF|
   |UE  |        |(NB-IoT)|   | +---+-+ |    +--------+    +----+
   +----+        +--------+   |     |   |
                              |C-SGN|   |
                              |     |S11|
                   +------+   |     |   |
   +--------+LTE-Uu|      |   |  +--+-+ |
   |LTE eMTC|(eMTC)|eNB   +---+--+SGW | | S8+---+    +-----------+
   |   UE   +------+(eMTC)|S1 |  |    +-+---+PGW|SGi |Application|
   +--------+      +------+   |  +----+ |   |   +----+Server (AS)|
                              +---------+   +---+    +-----------+
      DEV            RGW          NGW        NGW         App

            Figure 2: 3GPP optimized CIOT network architecture

4.  Data Transmission

   3GPP

   NB-IoT networks deal not only with data transmitted end-to-end but also
   with user data and in-band signaling that is used
   between the nodes and functions to configure, control control, and monitor
   the system functions and behaviors.  The control signaling data is handled using a Control Plane which has uses a
   different path with specific set of protocols, handling processes processes, and entities.  In
   contrast, the
   entities but can transport end-to-end or user data utilize a User Plane with
   characteristics of its own separated from the Control Plane.  The
   handling and setup of the Control Plane and User Plane spans over the
   whole 3GPP network and it has particular implications in the radio
   network (i.e., EUTRAN) and in the packet core (ex., EPC).

   For the CIOT cases, additionally to transmissions of data over User
   Plane, 3GPP has specified optimizations for small data transmissions,
   allowing to transport user data (IP, Non-IP) within signaling on IoT services.  In
   contrast, the
   access network (Data transmission over Control Plane or Data Over
   NAS). end-to-end application only transports end-to-end data.

   The maximum recommended MTU size is 1358 Bytes.  The radio network
   protocols limit the packet sizes to be transmitted over the air air, including radio
   protocol overhead to 1600 Octets.  But Bytes.  However, the value MTU is
   reduced further smaller to
   avoid fragmentation in the backbone of the network backbone due to the payload
   encryption size (multiple of 16) and handling of the additional core transport overhead.
   overhead handling.

   3GPP standardizes NB-IoT and and, in general general, the cellular technologies
   interfaces and
   functions are standardized by 3GPP. functions.  Therefore the introduction of SCHC
   entities to UE, eNB Dev, RGW-eNB, and C-SGN does need NGW-CSGN needs to be specified in the
   NB-IoT standard.  This standard, which implies that standard specified specifying SCHC support
   would not be backwards backward compatible.  A terminal or a network supporting
   a version of the standard without support of SCHC or without capability
   implementation (in case of not being standardized as mandatory
   capability) is not able to cannot utilize the compression services with this
   approach.

   SCHC could be deployed differently depending on where the header
   compression and the fragmentation are applied.  The SCHC
   functionalities could be applied to the packets about to can be
   transmitted used over the air, or to the whole end-to-end link.  To
   accomplish radio transmission only, between
   the first, it is required to place SCHC compression Dev and
   decompression entities in the eNB and in RGW-eNB.  Alternatively, the UE for transmissions packets transmitted over
   the User Plane.  Additionally, to handle the case of end-to-end link can use SCHC.  Else, when the transmissions over Control Plane
   the NGW-MME or Data Over NAS, NGW-SCEF, the network NGW-CSGN uses SCHC
   entity has to be placed in the C-SGN as well. entity.  For these
   two cases, the functions are to be standardized by 3GPP.

   Another possibility is to apply SCHC functionalities to the end-to-
   end connection or at least up to the operator network edge.  In that
   case, the  SCHC entities would be placed
   functionalities are available in the application layer of the terminal in one end, Dev and either in
   the application servers Application Servers or in a broker function in at the edge of the
   operator network in the other
   end.  For the network.  The radio network, network transmits the packets are transmitted as non-IP
   traffic, which can be currently served utilizing
   traffic using IP tunneling or SCEF services.  Since this option does
   not necessarily require 3GPP standardization, it is possible to also
   benefit legacy devices with SCHC by utilizing using the non-IP transmission
   features of the operator network.

   Accordingly, there are four different scenarios where SCHC can be
   used in the NB-IoT architecture.  IP header compression on the data
   transmission over User Plane, IP header compression on the optimized
   transmissions over Control Plane (i.e.,DoNAS), non-IP transmissions
   of SCHC packets by IP tunneling, and non-IP transmissions of SCHC
   packets by SCEF forwarding.  The following sections describe each of
   them in more detail.  The first two scenarios refer to transmissions
   using the 3GPP IP transmission capabilities and the last two refers
   to transmission using the Non-IP capabilities.

5.  IP based Data Transmission

5.1.  SCHC over User Plane transmissions the Radio link

   Deploying SCHC only over the radio link would require to place placing it as
   part of the User Plane data transmission.  The User Plane utilizes
   the protocol stack of the Access Stratum (AS) for data transfer.  AS
   (Access Stratum) transfer between the Dev and the
   RGW-eNB.  This stack is the functional layer responsible for
   transporting data over the wireless connection and managing radio
   resources.  The user
   plane AS has  There is support for features such as reliability, segmentation
   segmentation, and concatenation.  The transmissions of the AS make use of link
   adaptation, meaning that the system will optimize the transport
   format utilized for the
   transmissions are optimized used according to the radio conditions, the number of bits to transmit
   transmit, and the power and interference constrains. constraints.  That means
   that the number of bits transmitted over the air depends
   of on the
   Modulation and Coding Schemes (MCS) selected.  The  A Transport Block (TB)
   transmissions happen in the physical layer happens at network synchronized
   intervals of times called TTI (Transmission Transmission Time Interval).  The
   transmission of a Transport Block (TB) is completed during, at least,
   one TTI. Interval (TTI).  Each Transport
   Block has a different MCS and number of bits available to transmit.
   The MAC layer [TGPP36321] defines the Transport Blocks characteristics are
   defined by the MAC technical specification TGPP36321.
   characteristics.  The Access
   Stratum for User Plane is comprised by Radio link Figure 2 stack comprises the Packet
   Data Convergence Protocol (PDCP) TGPP36323, [TGPP36323], Radio Link Protocol
   (RLC) TGPP36322, [TGPP36322], Medium Access Control protocol (MAC) TGPP36321 [TGPP36321],
   and the Physical Layer
   TGPP36201.  More [TGPP36201].  The Appendix gives more details
   of this protocols are given in the Appendix. these protocols.

5.1.1.  SCHC Entities Placing

   The current architecture provides support for header compression in
   PDCP utilizing with RoHC [RFC5795].  Therefore SCHC entities can be deployed in similar fashion
   similarly without the need for major significant changes in the 3GPP
   specifications.

   In this scenario, RLC takes care of the handling of fragmentation (if unless for the
   transparent mode is not configured) when mode.  When packets exceeds exceed the transport block size at
   the time of transmission.  Therefore transmission, SCHC fragmentation is not needed unnecessary and
   should not be used to avoid the additional protocol overhead.  It is
   not common to configure RLC in Transparent Mode for IP based user plane IP-based data.  But
   However, given the case in the future, SCHC fragmentation may be
   used.  In that case, a SCHC tile would match the minimum transport
   block size minus the PDCP and MAC headers.

     +---------+                              +---------+  |
     |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
        CIOT/     LTE+Uu     C-BS/eNB             C-SGN
       LTE eMTC
         UE
        Dev                RGW-eNB             NGW-CSGN

                    Figure 3: 2: SCHC entities placement in the 3GPP CIOT radio protocol
                   architecture for data over user plane the Radio link

5.2.  Data Over Control Plane

   The Non-Access  SCHC over No-Access Stratum (NAS), (NAS)

   The NGW-MME conveys mainly control signaling between the UE Dev and the
   cellular network TGPP24301.  NAS is
   transported [TGPP24301].  The network transports this traffic on
   top of the Access Stratum (AS) already mentioned in
   the previous section.

   NAS has been adapted to provide support for user plane radio link.

   This kind of flow supports data transmissions to reduce the overhead
   when transmitting infrequent small quantities of data.  This
   transmission is known as Data over NAS No-Access Stratum (DoNAS) or
   Control Plane CIoT EPS optimization.  In DoNAS DoNAS, the UE makes use of Dev uses the pre-established NAS pre-
   established security and piggyback uplink small uplink data into the initial NAS
   uplink message, message and uses an additional NAS message to receive downlink
   small data response.

   The NGW-MME performs the data encryption from the network side is performed by the C-SGN in a NAS
   DoNAS PDU.  Depending on the data type signaled indication (IP or
   non-IP data), the network allocates an IP address or just establish establishes a
   direct forwarding path.  DoNAS (Data over NAS) is regulated under rate control upon
   previous agreement, meaning that a maximum number of bits per unit of
   time is agreed upon per device subscription beforehand and configured
   in the device.

   The system will use of DoNAS is typically expected when a terminal in a power
   saving power-saving state
   requires to do a short transmission and receive receives an acknowledgment or short
   feedback from the network.  Depending on the size of buffered data to
   transmit, the UE Dev might be instructed to deploy the connected mode transmissions
   instead, limiting and controlling the DoNAS transmissions to
   predefined thresholds and a good resource optimization balance for
   the terminal and the network.  The support for mobility of DoNAS is
   present but produces additional overhead.  Additional  The Appendix gives
   additional details of DoNAS are given in the Appendix. DoNAS.

5.2.1.  SCHC Entities Placing

   In this scenario

   SCHC can be applied may reside in the NAS Non-Access Stratum (NAS) protocol layer
   instead of PDCP. in
   this scenario.  The same principles than as for user plane Radio link transmissions applies
   apply here as well.  The main difference is the physical placing of
   the SCHC entities in on the network side as the
   C-SGN (placed NGW-MME resides in the
   core network) network and is the terminating node for NAS instead of the eNB.

   +--------+                       +--------+--------+  +  +--------+
   | IP/    +--+-----------------+--+  IP/   |   IP/  +-----+   IP/  |
   | Non-IP |  |                 |  | Non-IP | Non-IP |  |  | Non-IP |
   +--------+  |                 |  +-----------------+  |  +--------+
   | NAS    +-----------------------+   NAS  |GTP|C/U +-----+GTP|C/U  |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-lite                   SGi
      CIOT/  LTE-Uu   C-BS/eNB            C-SGN                PGW
    LTE eMTC
      UE
      Dev           RGW-eNB               NGW-MME             NGW-PGW

       *PDCP is bypassed until AS security is activated TGPP36300.

                                 Figure 4 3

5.3.  Parameters for Static Context Header Compression (SCHC)

5.3.1.  SCHC Context initialization

   RRC (Radio Resource Control) protocol is the main tool used to
   configure the operation parameters of the AS transmissions for 3GPP
   technologies.  RoHC operation is configured with this protocol and it
   is to expect that SCHC Radio link.  It will be configured configure SCHC
   and the static context
   distributed in similar fashion distribution as it has made for these scenarios. RoHC operation
   [TGPP36323].

5.3.2.  SCHC Rules

   The number of rules in a context are defined by the network operator in these scenarios.  For this, scenarios defines the number of rules
   in a context.  The operator must be aware of the type of IP traffic
   that the device will carry out.  This means  Implying that the operator might use
   provision sets of rules compatible with the use case of the device.
   For devices acting as gateways of other devices devices, several rules that may
   match the diversity of devices and protocols used by the devices
   associated to with the gateway.  Meanwhile than  Meanwhile, simpler devices (for example
   example, an electricity meter) may have a predetermined set of fixed
   protocols and parameters fixed. parameters.  Additionally, the deployment of IPV4 IPv4
   addresses in addition to IPV6 and IPv6 may force to provision separate different rules to deal with each of the cases. case.

5.3.3.  Rule ID

   For these transmission scenarios in NB-IoT,

   There is a reasonable assumption of 9 bytes of radio protocol
   overhead can be expected. for these transmission scenarios in NB-IoT, where PDCP uses
   5 bytes due to header and integrity protection, and 4 bytes of RLC and MAC. MAC use 4
   bytes.  The minimum physical Transport Block Blocks (TB) that can withhold
   this overhead value according to 3GPP Release 15 specifications are: are
   88, 104, 120 120, and 144 bits.  If it is wished to optimize the number of
   transmissions of a very small application packet so that in some
   cases can be transmitted using  A transmission optimization may require
   only one physical layer transmission,
   then the transmission.  SCHC overhead should not
   exceed the available number of effective bits of the smallest utile
   physical TB available.  The packets handled by 3GPP networks are
   byte-aligned, and therefore the minimum payload possible (including
   padding) is 8 bits.  Therefore in order to
   utilize use the smallest TB TB, the
   maximum SCHC header is 8 12 bits.  This  These 12 bits must include the
   Compression Residue in addition to the Rule ID.  In  On the other hand, it is possible that
   more complex NB-IoT devices (such as a capillarity gateway) might
   require additional bits to handle the variety and multiple parameters the
   of higher layer higher-layer protocols deployed.  In that sense, the operator may
   want to have flexibility on the number and type of rules supported by
   each device independently, and consequently consequently, these scenarios require
   a configurable value is preferred for
   these scenarios. value.  The configuration may be set as part of the operation
   profile agreed together with the context content distribution.  The Rule Id ID
   field size may range for example from 2 bits bits, resulting in 4 rules to a an 8 bits
   value that would yield up to 256 rules which that can be used together with
   the operators and seems quite a reasonable maximum limit even for a
   device acting as a NAT.  More bits could be configured, but it should take in account
   consider the byte-alignment of the expected Compression Residue too. Residue.  In
   the minimum TB size case, 2 bits size of Rule Id leave only 6 bits
   available for Compression Residue.

5.3.4.  SCHC MAX_PACKET_SIZE

   The Access Stratum Radio Link can handle the fragmentation of SCHC packets if
   needed
   needed, including reliability.  Hence the packet size is limited by
   the MTU possible to be handled by the AS radio protocols that
   corresponds correspond to 1600 bytes
   for 3GPP Release 15.

5.3.5.  Fragmentation

   For these scenarios scenarios, the SCHC fragmentation functions are recommend to
   be disabled.
   The RLC layer of NB-IoT can segment packets in suitable units that
   fit the selected transport blocks for transmissions of the physical
   layer.  The selection of the blocks selection is done made according to the
   input of the link adaptation
   input function in the MAC layer and the quantity of data in the
   buffer.  The link adaptation layer may produce different results at
   each Time Transmission Interval (TTI) (TTI), resulting in varying physical
   transport blocks that depends of depend on the network load, interference and interference,
   number of bits to be transmitted transmitted, and QoS.  Even if setting a value that
   allows the construction of data units following the SCHC tiles
   principle, the protocol overhead may be greater or equal than
   allowing the AS radio Radio link protocols to take care of the fragmentation
   natively.

5.3.5.1.  Fragmentation in Transparent Mode

   If RLC is configured to operate operates in Transparent Mode, there could be a case to
   activate a fragmentation function together with a light reliability
   function such as the ACK-Always mode.  In practice , practice, it is very rare uncommon to
   transmit user plane radio link data using this configuration and
   it is configuration.  It mainly targeting control plane targets
   signaling transmissions.  In those cases cases, the reliability is normally ensured by MAC based mechanisms, layer mechanisms
   ensure reliability, such as repetitions or automatic retransmissions,
   and additional reliability might only generate protocol overhead.

   In future operations, it could be devised the utilization of

   SCHC to may reduce radio network protocols overhead and in future
   operations, support the reliability
   of the reliable transmissions, and targeting transmit small data
   with the fewer possible transmissions.  This could be realized transmissions by using fixed or limited set of transport
   blocks compatible with the tiling SCHC fragmentation handling.

6.  Non-IP based Data Transmission  End-to-End Compression

   The Non-IP Data Delivery (NIDD) services of 3GPP enable the
   possibility
   transmission of transmitting SCHC packets compressed by the application layer.
   The packets can be delivered by means of IP-
   tunnels using IP-tunnels to the 3GPP network or using SCEF
   NGW-SCEF functions (i.e., API calls).  In both cases cases, as compression
   occurs before transmission, the packet IP is network will not understood by understand the 3GPP
   network since it is already compressed
   packet, and the network does not has have context information of the context used for this
   compression.  Therefore the network will treat the packet as a Non-IP
   traffic and deliver it to the UE Dev without any other stack element,
   directly under the L2.

6.1.  SCHC Entities Placing

   In the two scenarios using NIDD, End-to-End compression, SCHC entities are
   located almost in on top of the stack.  In the terminal, it may be implemented by a Dev, an application utilizing using
   the NB-IoT connectivity services.  In the
   network side, the services may implement SCHC entities are located in and the
   Application Server
   (AS). Server.  The IP tunneling scenario requires that the
   Application Server
   sends send the compressed packet over an IP connection that is
   terminated by the 3GPP core network.  If instead the SCEF services are used,
   then transmission uses the
   NGW-SCEF services, it is possible to utilize a an API call to transfer
   the SCHC packets between the core network and the AS, also Application Server.
   Also, an IP tunnel could be established by the AS, Application Server if
   negotiated with the SCEF. 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   |
   +---------+                                            +--------+
      UE                                                       AS

   Figure 5: 4: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP
                                  Sevices

6.2.  Parameters for Static Context Header Compression

6.2.1.  SCHC Context initialization

   The static context is handled in the application layer level,
   consequently handles the contexts are required to static context; consequently, the
   context distribution must be distributed according to the applications own application's
   capabilities, perhaps utilizing IP data transmissions up to context
   initialization.  Also  Also, the static contexts delivery may use the same
   IP tunneling or SCEF NGW-SCEF services used later for the SCHC packets transport
   may be used by the applications in both ends to deliver the static
   contexts to be used.
   transport.

6.2.2.  SCHC Rules

   Even when the transmissions transmission content are is not visible for the 3GPP
   network, the same limitations than as for IP based IP-based data transmissions
   applies in these scenarios in terms of aiming to use the minimum
   number of transmission and minimize the protocol overhead.

6.2.3.  Rule ID

   Similarly

   Similar to the case of IP transmissions, the Rule ID size can be
   dynamically set prior before the context delivery.  For example example, negotiated
   between the applications when choosing a profile according to the
   type of traffic and type of application deployed.  Same  The same considerations
   related to the transport block size and performance mentioned for the
   IP type of traffic has to must be follow followed when choosing a size value for
   the Rule ID field.

6.2.4.  SCHC MAX_PACKET_SIZE

   In these scenarios scenarios, the maximum recommended MTU size that applies is
   1358 Bytes, Bytes since the SCHC packets (and fragments) are traversing the
   whole 3GPP network infrastructure (core and radio), and not only the
   radio as the IP transmissions case.

6.3.  Fragmentation

   In principle the fragmentation function should be activated for principle, packets greater larger than 1358 Bytes. bytes need the fragmentation
   function.  Since the 3GPP uses reliability
   functions take great deal care of it, for simple point to point
   connections functions, the No-ACK
   fragmentation mode may be enough a NO-ACK mode.  Nevertheless in point-to-point connections.
   Nevertheless, additional considerations are described below for more
   complex cases are mentioned in the next
   subsection to be taken in account. cases.

6.3.1.  Fragmentation modes

   Depending of the

   A global service assigns a QoS that has been assigned to the packets, it is
   possible that packets are depending on the
   billing.  Packets with very low QoS may get lost before they arrive to
   in the 3GPP radio network transmission, for example example, in between the
   links of a capillarity gateway, gateway or due to buffer overflow handling in
   a backhaul connection.  In consequence, it  The use of SCHC fragmentation with the ACK-
   on-Error mode is possible recommended to secure additional reliability on the
   packets transmitted with a small trade-off on additional
   transmissions to signal the packets arrival indication end-to-end arrival of the packets if no
   transport protocol takes care of retransmission.  To
   achieve this, the packets fragmentation is activated with
   Also, the ACK-on-
   Error ACK-on-Error mode enabled.  In some cases, it is even desirable to keep track of all
   the SCHC packets delivered, in delivered.  In that case, the fragmentation function
   could be active for all packets transmitted by the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on-
   Error mode.  In the NAS stratum, applications.
   SCHC ACK-on-Error fragmentation may be active for the use transmission of only fragmentation when a
   non-IP packet is transmitted is possible if this packet is considered
   as a packets on the NGW-MME.  If these packets are considering to
   use SCHC packet and is identifyed using with the RuleID for non-
   compressing non-compressing packets as {RFC8724}
   allows it, depending on the
   application an ACK-onError mode may be used. it.

6.3.2.  Fragmentation Parameters

   The Fragmentation

   SCHC profile with the fragmentation mode will have specific Rules.
   SCHC defines the Rule ID is given when choosing the profile according to the fragmentation mode, 1 bit can be used to mode; 2 bits
   could recognize
   each mode.

   To adapt all the fragmentation modes or another solution
   depending on the Rules implementation.

   SCHC to parametrization considers that NBIoT aligns the NB-IoT constraints, two configuration are
   proposed bit and uses
   padding and the size of the Transfer Block.  SCHC will try to reduce
   padding to fill optimize the best compression of the transfer block (TB). information.  The Header
   size needs to be multiple of 4 4, and the Tiles can may keep a fix fixed value
   of 4 or 8 bits to avoid the need padding except for transfer block equals 16
   bits where Tiles may be of padding. 2 bits.  For the other parameters, the
   transfer block size has a wide range that needs two configurations.

   o  For Transfer Blocks smaller than 300bits: 8 bits-Header_size
      configuration, with the size of the header fields as follow: follows: Rule
      ID 3 bits, DTag 1 bit, FCN 3 bits, W 1 bits.  This configuration may ne used with TB less

   o  For Transfer Blocks bigger than 300 bits.

   o bits: 16 bits-Header_size
      configuration, with the size of the header fields as follow: follows:
      Rules ID 8 - 10 bits, DTag 1 or 2 bits, FCN 3 bits, W 2 or 3 bits.  This configuration may be used with TB above
      300 bits.

   The IoT devices communicates communicate with small data transfer and have a
   battery life of 10 years.  To minise the power consumption these  These devices use the Power Save Mode and
   the Idle Mode DRX DRX, which govern how often the device wakes up, stays up
   up, and are is reachable.  The  Table 10.5.163a in {3GPP-TS_24.088} specifies
   a range for the radio timers as N to 3N in increments of one where
   the units of N can be 1 hour or 10 hours.  To adapt SCHC to the NB-IoT NB-
   IoT activities, the
   Innactivity Inactivity Timer may be above 1h or 10h and the Retransmission Timer may be below than 1h or 10h.
   use these limits.

7.  Padding

   NB-IoT and 3GPP wireless access, in general, assumes byte aligned byte-aligned
   payload.  Therefore the L2 word for NB-IoT MUST be considered 8 bits bits,
   and the treatment of padding treatment should use this value accordingly.

8.  Security considerations

   3GPP access security is specified in (TGPP33203). [TGPP33203].

9.  3GPP References

   o  TGPP23720 3GPP, "TR 23.720 v13.0.0 - Study on architecture
      enhancements for Cellular Internet of Things", 2016.

   o  TGPP33203 3GPP, "TS 33.203 v13.1.0 - 3G security; Access security
      for IP-based services", 2016.

   o  TGPP36321 3GPP, "TS 36.321 v13.2.0 - Evolved Universal Terrestrial
      Radio Access (E-UTRA); Medium Access Control (MAC) protocol
      specification", 2016

   o  TGPP36323 3GPP, "TS 36.323 v13.2.0 - Evolved Universal Terrestrial
      Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
      specification", 2016.

   o  TGPP36331 3GPP, "TS 36.331 v13.2.0 - Evolved Universal Terrestrial
      Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol
      specification", 2016.

   o  TGPP36300 3GPP, "TS 36.300 v15.1.0 - Evolved Universal Terrestrial
      Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio
      Access Network (E-UTRAN); Overall description; Stage 2", 2018

   o  TGPP24301 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)
      protocol for Evolved Packet System (EPS); Stage 3", 2018

   o  TGPP24088 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface Layer
      3 specification;Core network protocols; Stage 3", 2015.

10.  Appendix

10.1.  NB-IoT User Plane protocol architecture

10.1.1.  Packet Data Convergence Protocol (PDCP)

   Each of the Radio Bearers (RB) are is associated with one PDCP entity.
   And
   Moreover, a PDCP entity is associated with one or two RLC entities
   depending of on the unidirectional or bi-directional characteristics of
   the RB and RLC mode used.  A PDCP entity is associated with either a
   control plane or a user plane which with independent configuration and
   functions.  The maximum supported size for NB-IoT of a PDCP SDU is
   1600 octets.  The main primary services and functions of the PDCP sublayer
   for NB-IoT for the user plane include:

   o  Header compression and decompression by means of using ROHC (Robust Header
      Compression)

   o  Transfer of user and control data to higher and lower layers

   o  Duplicate detection of lower layer SDUs when re-establishing
      connection (when RLC with Acknowledge Mode in use for User Plane
      only)

   o  Ciphering and deciphering

   o  Timer-based SDU discard in uplink

10.1.2.  Radio Link Protocol (RLC)

   RLC is a layer-2 protocol that operates between the UE and the base
   station (eNB).  It supports the packet delivery from higher layers to
   MAC
   MAC, creating packets that are transmitted over the air air, optimizing the
   Transport Block utilization.  RLC flow of data packets is
   unidirectional
   unidirectional, and it is composed of a transmitter located in the
   transmission device and a receiver located in the destination device.
   Therefore to configure bi-directional flows, two set sets of entities,
   one in each direction (downlink and uplink) uplink), must be configured and they
   are
   effectively peered to each other.  The peering allows the
   transmission of control packets (ex., status reports) between
   entities.  RLC can be configured for data transfer in one of the
   following modes:

   o  Transparent Mode (TM).  In this mode  RLC do does not segment or concatenate SDUs
      from higher layers in this mode and do does not include any header to
      the payload.  When acting as a transmitter,  RLC receives SDUs from upper layers when acting as a
      transmitter and transmit transmits directly to its flow RLC receiver via
      lower layers.  Similarly, an a TM RLC receiver would only deliver
      without additional processing the packets to higher layers upon reception.

   o  Unacknowledged Mode (UM).  This mode provides support for
      segmentation and concatenation of payload.  The size of the RLC
      packet packet's size
      depends of on the indication given at a particular transmission
      opportunity by the lower layer (MAC) and are is octets aligned.  The
      packet delivery to the receiver do does not include
      support for reliability
      support, and the lost loss of a segment from a packet means a whole complete
      packet loss.  Also  Also, in the case of lower layer
      retransmissions 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  Additionally, it provides PDU duplication detection and discard,
      discards, reordering of out of sequence out-of-sequence, and loss detection.

   o  Acknowledged Mode (AM).  Additional  In addition to the same functions
      supported from by UM, this mode also adds a moving windows based windows-based
      reliability service on top of the lower layer services.  It also
      provides support for re-segmentation
      supports re-segmentation, and it requires bidirectional
      communication to exchange acknowledgment reports called RLC Status
      Report and trigger retransmissions is needed.  Protocol error
      detection is retransmissions.  This model also supported by this mode. supports
      protocol error detection.  The mode uses used depends
      of 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 AM.  Meanwhile,
      streaming and real time real-time data would be map mapped to a UM
      configuration.

10.1.3.  Medium Access Control (MAC)

   MAC provides a mapping between the higher layers abstraction called
   Logical Channels comprised by the previously described protocols to
   the Physical layer channels (transport channels).  Additionally, MAC
   may multiplex packets from different Logical Channels and prioritize
   what to fit into one Transport Block if there is data and space
   available to maximize the efficiency of data transmission. transmission efficiency.  MAC also
   provides error correction and reliability support by means of through HARQ,
   transport format selection selection, and scheduling information reporting from
   the terminal to the network.  MAC also adds the necessary padding and
   piggyback control elements when possible additional to and the higher layers data.

                                               <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

       Figure 6: 5: Example of User Plane packet encapsulation for two
                             transport blocks

10.2.  NB-IoT Data over NAS (DoNAS)

   The AS Access Stratum (AS) protocol stack used by DoNAS is somehow special.
   particular.  Since the security associations are not established yet
   in the radio network, to reduce the protocol overhead, PDCP (Packet
   Data Convergence Protocol) is bypassed until AS security is
   activated.  RLC (Radio Link Control protocol) is configured uses by default in the AM
   mode, but depending of on the network's features supported by the network and the terminal terminal, it
   may be configured in change to other modes by the network operator.  For example, the
   transparent mode does not add any header or does not process the payload in any way reducing to
   reduce the overhead, but the MTU would be limited by the transport
   block used to transmit the data data, which is a couple of thousand of bits
   maximum.  If UM (only Release 15 compatible terminals) is used, the
   RLC mechanisms of reliability is
   disabled are disabled, and only the reliability
   provided by the MAC layer by Hybrid Automatic Repeat reQuest (HARQ)
   is available.  In this case, the protocol overhead might be smaller
   than for the AM case because of the lack of status reporting but with the
   same support for segmentation up to 16000 Bytes.  NAS packet packets are
   encapsulated within a an RRC (Radio Resource Control) TGPP36331
   message.

   Depending of on the data type indication signaled (IP or non-IP data),
   the network allocates an IP address or just establish establishes a direct
   forwarding path.  DoNAS is regulated under rate control upon previous
   agreement, meaning that a maximum number of bits per unit of time is
   agreed upon per device subscription beforehand and configured in the
   device.  The use of DoNAS is typically expected when a terminal in a
   power saving
   power-saving state requires to do a short transmission and receive receiving an
   acknowledgment or short feedback from the network.  Depending of on the
   size of buffered data to transmit, the UE might be instructed to
   deploy the connected mode transmissions instead, limiting and
   controlling the DoNAS transmissions to predefined thresholds and a
   good resource optimization balance for the terminal and the network.  The
   support for mobility of DoNAS is present but produces 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 7: 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 8: 7: Example of User Plane packet encapsulation for Data over
                                    NAS

11.  Normative References

   [RFC5795]  Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
              Header Compression (ROHC) Framework", RFC 5795,
              DOI 10.17487/RFC5795, March 2010, <https://www.rfc-
              editor.org/info/rfc5795>.

   [RFC8376]  Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
              Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
              <https://www.rfc-editor.org/info/rfc8376>.

   [RFC8724]  Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
              Zuniga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020, <https://www.rfc-
              editor.org/info/rfc8724>.

Authors' Addresses

   Edgar Ramos
   Ericsson
   Hirsalantie 11
   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