LPWAN Static Context Header Compression (SCHC) over NB-IoT
draft-minaburo-lpwan-nbiot-hc-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Ana Minaburo , Edgar Ramos , Sivasothy Shanmugalingam | ||
| Last updated | 2018-09-04 (Latest revision 2018-03-05) | ||
| Replaced by | draft-ietf-lpwan-schc-over-nbiot, draft-ietf-lpwan-schc-over-nbiot, draft-ietf-lpwan-schc-over-nbiot, RFC 9391 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-minaburo-lpwan-nbiot-hc-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]