[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

lpwan Working Group                                          A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Informational                                  E. Ramos
Expires: March 8, 2019                                          Ericsson
                                                       S. Shanmugalingam
                                                                  Acklio
                                                      September 04, 2018


       LPWAN Static Context Header Compression (SCHC) over NB-IoT
                    draft-minaburo-lpwan-nbiot-hc-01

Abstract

   The Static Context Header Compression (SCHC) specification describes
   a header compression and fragmentation functionalities for LPWAN (Low
   Power Wide Area Networks) technologies.  SCHC was designed to be
   adapted over any of the LPWAN technologies.

   This document describes the use of SCHC over the NB-IoT wireless
   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 https://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 March 8, 2019.

Copyright Notice

   Copyright (c) 2018 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Minaburo, et al.          Expires March 8, 2019                 [Page 1]


Internet-Draft                 SCHC NB-IoT                September 2018


   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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Data Transmission . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Data Transmission over User Plane . . . . . . . . . . . .   6
       3.2.1.  Packet Data Convergence Protocol (PDCP) . . . . . . .   7
       3.2.2.  Radio Link Protocol (RLC) . . . . . . . . . . . . . .   7
       3.2.3.  Medium Access Control (MAC) . . . . . . . . . . . . .   8
     3.3.  Data Over Control Plane . . . . . . . . . . . . . . . . .   9
     3.4.  SCHC entities . . . . . . . . . . . . . . . . . . . . . .  13
   4.  Static Context Header Compression . . . . . . . . . . . . . .  13
     4.1.  SCHC Rules  . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Packet processing . . . . . . . . . . . . . . . . . . . .  13
     4.3.  SCHC Context  . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Fragmentation . . . . . . . . . . . . . . . . . . . . . . . .  13
     5.1.  Fragmentation modes . . . . . . . . . . . . . . . . . . .  14
     5.2.  Fragmentation Parameters  . . . . . . . . . . . . . . . .  14
   6.  Padding . . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security considerations . . . . . . . . . . . . . . . . . . .  14
   8.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  NB-IoT example with mobility  . . . . . . . . . . . . . .  15
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The Static Context Header Compression (SCHC)
   [I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
   scheme and fragmentation functionality, both specially tailored for
   Low Power Wide Area Networks (LPWAN) networks defined in
   [I-D.ietf-lpwan-overview].

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




Minaburo, et al.          Expires March 8, 2019                 [Page 2]


Internet-Draft                 SCHC NB-IoT                September 2018


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

2.  Terminology

   This document will follow the terms defined in
   [I-D.ietf-lpwan-ipv6-static-context-hc], in
   [I-D.ietf-lpwan-overview], and the TGPP23720.

   o  CIoT.  Cellular IoT

   o  C-SGN.  CIoT Serving Gateway Node

   o  UE.  User Equipment

   o  eNB.  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.  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 optmization for IoT
      and using a Narrow Band spectrum frequency.

   o  SGW.  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.  Packet Data Node Gateway.  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 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



Minaburo, et al.          Expires March 8, 2019                 [Page 3]


Internet-Draft                 SCHC NB-IoT                September 2018


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

3.  Architecture

   ## NB-IoT entities


      +--+
      |UE| \              +------+      +------+
      +--+  \             | MME  |------| HSS  |
             \          / +------+      +------+
      +--+    \+-----+ /      |
      |UE| ----| eNB |-       |
      +--+    /+-----+ \      |
             /          \ +--------+
            /            \|        |    +------+     Service PDN
      +--+ /              |  S-GW  |----| P-GW |---- e.g. Internet
      |UE|                |        |    +------+
      +--+                +--------+


                    Figure 1: 3GPP network architecture

   The architecture for 3GPP LTE network has been reused for NB-IoT with
   some optimizations and simplifications known as Cellular IoT (CIoT).
   Considering the typical use cases for CIoT devices here are described
   some of the additions to the LTE architecture specific for CIoT.
   C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating
   EPS entities in the control plane and user plane paths (for example,
   MME + SGW + P-GW) and the external interfaces of the entities
   supported.  The C-SGN also supports at least some of the following
   CIoT EPS Optimizations: * Control Plane CIoT EPS Optimization for
   small data transmission.  * User Plane CIoT EPS Optimization for
   small data transmission.  * Necessary security procedures for
   efficient small data transmission.  * SMS without combined attach for
   NB-IoT only UEs.  * Paging optimizations for coverage enhancements.
   * Support for non-IP data transmission via SGi tunneling and/or SCEF.
   * Support for Attach without PDN (Packet Data Network) connectivity.

   Another node introduced in the CIOT architecture is the SCEF (Service
   Capability Exposure Function) that provide means to securely expose
   service and network capabilities to entities external to the network
   operator.  The northbound APIS are defined by OMA and OneM2M.  The
   main functions of a SCEF are: * Non-IP Data Delivery (NIDD)
   established through the SCEF.  * Monitoring and exposure of event
   related to UE reachability, loss of connectivity, location reporting,



Minaburo, et al.          Expires March 8, 2019                 [Page 4]


Internet-Draft                 SCHC NB-IoT                September 2018


   roaming status, communication failure and change of IMEI-IMSI
   association.


                                               +---------+
                                               |   HSS   |
                                               +---------+
                                              /
                               +-----------+ /S6a
                 +--------+    |           |/
   +----+  C-Uu  |        +----+           | T6i  +--------+ T7 +----+
   |CIOT+--------+  eNB   | S1 |           +------+IWK-SCEF+----+SCEF|
   |UE  |        |(NB-IoT)|    |           |      +--------+    +----+
   +----+        +--------+    |           |      +------------+
                               |   C-SGN   |SGd   |  SMS-GMSC/ |
                               |           +------+  IWMSC/SMS |
                  +--------+   |           |      |  router    |
   +----+  LTE-Uu |        |   |           |      +------------+
   |LTE |  (eMTC) |  eNB   +---+           |  S8  +---+    +------+
   |eMTC+---------+(eMTC)  | S1|           +------+PGW|SGi |Appli.|
   | UE |         +--------+   |           |      |   +----+Server|
   +----+                      +-----------+      +---+    | (AS) |
                                                           +------+


            Figure 2: 3GPP optimized CIOT network architecture

3.1.  Data Transmission

   3GPP networks deals not only with data transmitted end-to-end but
   also with in-band signaling that is used between the nodes and
   functions to configure, control and monitor the system functions and
   behaviors.  The control data is handled using a Control Plane which
   has an specific set of protocols, handling processes and entities.
   In contrast the 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
   that allows to transport user data (IP, Non-IP) within signaling on
   the access network (Data transmission over Control Plane or Data Over
   NAS).

   The maximum recommended MTU size is 1358 Bytes.  The radio network
   protocols limits the packet sizes to be transmitted over the air



Minaburo, et al.          Expires March 8, 2019                 [Page 5]


Internet-Draft                 SCHC NB-IoT                September 2018


   including radio protocol overhead to 1600 Octets.  But the value is
   reduced further to avoid fragmentation in the backbone of the network
   due to the payload encryption size (multiple of 16) and handling of
   the additional core transport overhead.

3.2.  Data Transmission over User Plane

   The User Plane utilizes the protocol stack of the Access Stratum (AS)
   for data transfer.  AS (Access Stratum) is the functional layer
   responsible for transporting data over wireless connection and
   managing radio resources.  The user plane AS has support for features
   such as reliability, segmentation and concatenation.  The
   transmissions of the AS utilize link adaptation, meaning that the
   transport format utilized for the transmissions are optimized
   according to the radio conditions, the number of bits to transmit and
   the power and interference constrains.  That means that the number of
   bits transmitted over the air depends of the Modulation and Coding
   Schemes (MCS) selected.  The transmissions in the physical layer
   happens at network synchronized intervals of times called TTI
   (Transmission Time Interval).  The transmission of a Transport Block
   (TB) is completed during, at least, one TTI.  Each Transport Block
   has a different MCS and number of bits available to transmit.  The
   Transport Blocks characteristics are defined by the MAC technical
   specification {TGPP36321}.  The Access Stratum for User Plane is
   comprised by Packet Data Convergence Protocol (PDCP) {TGPP36323},
   Radio Link Protocol (RLC){TGPP36322}, Medium Access Control protocol
   (MAC){TGPP36321} and the Physical Layer {TGPP36201}.


     +---------+                                +---------+  |
     |IP/non-IP+--------------------------------+IP/non-IP+->+
     +---------+   |   +----------------+   |   +---------+  |
     | PDCP    +-------+ PDCP  | GTP|U  +-------+ GTP-U   |->+
     +---------+   |   +----------------+   |   +---------+  |
     | 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

    Figure 3: 3GPP CIOT radio protocol architecture for data over user
                                   plane




Minaburo, et al.          Expires March 8, 2019                 [Page 6]


Internet-Draft                 SCHC NB-IoT                September 2018


3.2.1.  Packet Data Convergence Protocol (PDCP)

   Each of the Radio Bearers (RB) are associated with one PDCP entity.
   And a PDCP entity is associated with one or two RLC entities
   depending of the unidirectional or bi-directional characteristics of
   the RB and RLC mode used.  A PDCP entity is associated either control
   plane or user plane which 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 include: * Header compression and decompression by
   means of ROHC (Robust Header Compression) * 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 in use for User Plane only) * Ciphering and
   deciphering * Timer-based SDU discard in uplink

3.2.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 creating packets that are transmitted over the air optimizing the
   Transport Block utilization.  RLC flow of data packets is
   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 of entities, one
   in each direction (downlink and 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: * Transparent Mode (TM).  In this mode RLC do not
   segment or concatenate SDUs from higher layers and do not include any
   header to the payload.  When acting as a transmitter, RLC receives
   SDUs from upper layers and transmit directly to its flow RLC receiver
   via lower layers.  Similarly, an TM RLC receiver would only deliver
   without additional processing the packets to higher layers upon
   reception.  * Unacknowledged Mode (UM).  This mode provides support
   for segmentation and concatenation of payload.  The size of the RLC
   packet depends of the indication given at a particular transmission
   opportunity by the lower layer (MAC) and are octets aligned.  The
   packet delivery to the receiver do not include support for
   reliability and the lost of a segment from a packet means a whole
   packet loss.  Also in case of lower layer retransmissions there is no
   support for re-segmentation in case of change of the radio conditions
   triggring the selection of a smaller transport block.  Additionally
   it provides PDU duplication detection and discard, reordering of out
   of sequence and loss detection.  * Acknowledged Mode (AM).
   Additional to the same functions supported from UM, this mode also
   adds a moving windows based reliability service on top of the lower



Minaburo, et al.          Expires March 8, 2019                 [Page 7]


Internet-Draft                 SCHC NB-IoT                September 2018


   layer services.  It also provides support for re-segmentation and it
   requires bidirectional communication to exchange acknowledgment
   reports called RLC Status Report and trigger retransmissions is
   needed.  Protocol error detection is also supported by this mode.
   The mode uses depends of the operator configuration for the type of
   data to be transmitted.  For example, data transmissions supporting
   mobility or requiring high reliability would be most likely
   configured using AM, meanwhile streaming and real time data would be
   map to a UM configuration.

3.2.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.  MAC also
   provides error correction and reliability support by means of HARQ,
   transport format 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 the higher
   layers data.




























Minaburo, et al.          Expires March 8, 2019                 [Page 8]


Internet-Draft                 SCHC NB-IoT                September 2018


                                                  <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|         |
         |        |     |         |   |         |   |      |         |
         |        |     |         |   |         |   |      |         |
     +----------------------------------------------+ +---------+------+
   M |MAC|RLC|PDCP| AP1 |RLC |PDCP|AP1|RLC |PDCP|AP2| |MAC |RLC | AP2|P|
   A |Hea|Hea|Hea-| PDU |Hea-|Hea-|PDU|Hea-|Hea-|PDU| |Hea-|Hea-| PDU|a|
   C |der|der| der|     |der |der |   |der |der |PDU| |der |der |    |d|
     +----------------------------------------------+ +--------------+-+
                         TB1                                    TB2

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

3.3.  Data Over Control Plane

   The Non-Access Stratum (NAS), conveys mainly control signaling
   between the UE and the cellular network {TGPP24301}. NAS is
   transported on top of the Access Stratum (AS) already presented in
   the previous sections.














Minaburo, et al.          Expires March 8, 2019                 [Page 9]


Internet-Draft                 SCHC NB-IoT                September 2018


   +---------+                               +---------+---------+  |
   |IP/non-IP|---|-----------------------|---|IP/non-IP|IP/non-IP|->|
   +---------+   |                       |   +---------+---------+ >|
   | NAS     |---|-----------------------|---| NAS     | GTP-C/U |->|
   +---------+   |    +------+------+    |   +---------+---------+  |
   | RRC     |---|----| RRC  | S1-AP|----|---| S1-AP   |         |  |
   +---------+   |    +------+------+    |   +---------+  UDP    |->|
   | PDCP*   |---|----| PDCP*| SCTP |----|---| SCTP    |         |  |
   +---------+   |    +------+------+    |   +---------+---------+  |
   | RLC     |---|----| RLC  | IP   |----|---| IP      | IP      |->|
   +---------+   |    +------+------+    |   +---------+---------+  |
   | MAC     |---|----| MAC  | L2   |----|---| L2      | L2      |->|
   +---------+   |    +------+------+    |   +---------+---------+  |
   | PHY     |---|----| PHY  | PHY  |----|---| PHY     | PHY     |->|
   +---------         +------+------+        +---------+---------+  |
                C-Uu/                 S1-lite                     SGi
      CIOT/     LTE-Uu      C-BS/eNB                 C-SGN
     LTE eMTC
       UE

           *PDCP is bypassed until AS security is activated TGPP36300.

         Figure 5: 3GPP CIOT radio protocol architecture for DoNAS
                               transmissions

   NAS has been adapted to provide support for user plane data
   transmissions to reduce the overhead when transmitting infrequent
   small quantities of data.  This is known as Data over NAS (DoNAS) or
   Control Plane CIoT EPS optimization.  In DoNAS the UE makes use of
   the pre-established NAS security and piggyback uplink small data into
   the initial NAS uplink message, and uses an additional NAS message to
   receive downlink small data response.  The data encryption from the
   network side is performed by the C-SGN in a NAS PDU.  The AS protocol
   stack used by DoNAS is somehow special.  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 by default in AM mode, but depending of the
   features supported by the network and the terminal it may be
   configured in 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 the overhead, but the MTU would be
   limited by the transport block used to transmit the data which is
   couple of thousand of bits maximum.  If UM (only Release 15
   compatible terminals) is used, the RLC mechanisms of reliability is
   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 the



Minaburo, et al.          Expires March 8, 2019                [Page 10]


Internet-Draft                 SCHC NB-IoT                September 2018


   lack of status reporting but with the same support for segmentation
   up to 16000 Bytes.  NAS packet are encapsulated within a RRC (Radio
   Resource Control){TGPP36331} message.

   Depending of the data type indication signaled (IP or non-IP data),
   the network allocates an IP address or just establish 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 per device subscription beforehand and configured in the
   device.  The use of DoNAS is typically expected when a terminal in a
   power saving state requires to do a short transmission and receive an
   acknowledgment or short feedback from the network.  Depending of 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.

































Minaburo, et al.          Expires March 8, 2019                [Page 11]


Internet-Draft                 SCHC NB-IoT                September 2018


       +--------+   +--------+   +--------+
       |        |   |        |   |        |       +------------------+
       |   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






Minaburo, et al.          Expires March 8, 2019                [Page 12]


Internet-Draft                 SCHC NB-IoT                September 2018


3.4.  SCHC entities

   SCHC could be deployed differently depending of the placing of the
   entities in the architecture.  NB-IoT and in general the cellular
   technologies interfaces are standardized by 3GPP.  Therefore the
   introduction of SCHC entities in the RAN (Radio Access Network) would
   require support from both the network and terminal entities.  If SCHC
   entities are to be placed in RAN it would require to be added to be
   specified as an option for the UE - Base Station/C-SGN interfaces.
   Another option is to place the SCHC entities in the applications
   layer, and the SCHC packets would be transmitted as non-IP packets.
   The first option allows the deployment of IP for routing and
   addressing as well.

4.  Static Context Header Compression

   TBD (Edgar)

4.1.  SCHC Rules

   TBD (Ana) * Depending of SCHC deployment case * End-2-end * Global
   rules to fetch customized rules * Minimum rule set for applying
   functions * Fragmentation, compression, NATing

   o  Size of rule id

   o  1 fragment rule And at least one Rule ID may be reserved to the
      case where no SCHC C/D nor SCHC fragmentation were possible.

4.2.  Packet processing

   (Ana) *Operation over top vs 3gpp entities how to recognize a schc
   packet

4.3.  SCHC Context

   o  NATing

   o  What protocols can be identified for compression depending of the
      deployument

5.  Fragmentation

   The RLC layer of NB-IoT can segment packets in suitable units that
   fits the selected transport blocks for transmissions of the physical
   layer.  The selection of the blocks is done according to the input of
   the link adaptation function in the MAC layer and the quantity of
   data in the buffer.  The link adaptation layer may produce different



Minaburo, et al.          Expires March 8, 2019                [Page 13]


Internet-Draft                 SCHC NB-IoT                September 2018


   results at each Time Transmission Interval (TTI) for what is very
   difficult to set a fragmentation value according to the transport
   block that is selected for each transmission.  Instead for NB-IoT
   SCHC must take care of keeping the application packets with a
   suitable size that do not exceed the MTU (1600 bytes).

5.1.  Fragmentation modes

   (Sothy) Look a the different options of reliability and see the
   implications for NB-IoT for the different deployment modes

5.2.  Fragmentation Parameters

   (Edgar) Headers sizes Example for the end2end case and check what is
   operator defined * Rule ID

   o  DTag

   o  FCN

   o  Retransmission Timer

   o  Inactivity Timer

   o  MAX_ACK_Retries

   o  MAX_ATTEMPS

   o  MIC (Ana)

   TBD

6.  Padding

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

7.  Security considerations

   3GPP access security is specified in [TGPP33203].

8.  Appendix

   ## NB-IoT with data over NAS






Minaburo, et al.          Expires March 8, 2019                [Page 14]


Internet-Draft                 SCHC NB-IoT                September 2018


                       +---+ +---+ +----+                   +--+
   Applications        |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  | |Head | PDU (2/2)|         |RLC |NAS/RRC|
             |     | (1/2) | |Head | PDU (2/2)|         |RLC |NAS/RRC|
             +-------------+ +-----+----------+         |Head|PDU    |
             |     |       | \                 \        +------------+
             |     | LCID1 |  \                 \       |            |
             |     |       |   \                 \      |            |
             |     |       |    \                 \      \           |
             |     |       |     \                 \      \          |
       +-------------------+ +----|-----------------+ +----+---------|-+
   MAC |MAC  |RLC  |  RLC  | |MAC |RLC |    RLC     | |MAC |    RLC  |P|
       |Head |Head |PAYLOAD| |Head|Head|   PAYLOAD  | |Head|    PDU  |a|
       |     |     |       | |    |    |            | |    |         |d|
       +-------------------+ +----------------------+ +----+---------+-+
             TB1                       TB2                     TB3


    Figure 7: Example of User Plane packet encapsulation for Data over
                                    NAS

8.1.  NB-IoT example with mobility

   ## LTE-M considerations

9.  Informative References

   [I-D.ietf-lpwan-ipv6-static-context-hc]
              Minaburo, A., Toutain, L., Gomez, C., and D. Barthel,
              "LPWAN Static Context Header Compression (SCHC) and
              fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6-
              static-context-hc-16 (work in progress), June 2018.






Minaburo, et al.          Expires March 8, 2019                [Page 15]


Internet-Draft                 SCHC NB-IoT                September 2018


   [I-D.ietf-lpwan-overview]
              Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
              overview-10 (work in progress), February 2018.

   [TGPP24301]
              "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) protocol for
              Evolved Packet System (EPS); Stage 3", n.d..

   [TGPP33203]
              "TS 33.203 v13.1.0 - 3G security; Access security for IP-
              based services", n.d..

   [TGPP36300]
              "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",
              n.d..

   [TGPP36321]
              "TS 36.321 v13.2.0 - Evolved Universal Terrestrial Radio
              Access (E-UTRA); Medium Access Control (MAC) protocol
              specification", n.d..

   [TGPP36323]
              "TS 36.323 v13.2.0 - Evolved Universal Terrestrial Radio
              Access (E-UTRA); Packet Data Convergence Protocol (PDCP)
              specification", n.d..

   [TGPP36331]
              "TS 36.331 v13.2.0 - Evolved Universal Terrestrial Radio
              Access (E-UTRA); Radio Resource Control (RRC); Protocol
              specification", n.d..

Authors' Addresses

   Ana Minaburo
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io









Minaburo, et al.          Expires March 8, 2019                [Page 16]


Internet-Draft                 SCHC NB-IoT                September 2018


   Edgar Ramos
   Ericsson
   Hirsalantie 11
   02420 Jorvas
   Finland

   Email: edgar.ramos@ericsson.com


   Sivasothy Shanmugalingam
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: sothy@ackl.io



































Minaburo, et al.          Expires March 8, 2019                [Page 17]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/