< draft-ietf-lpwan-schc-over-nbiot-02.txt   draft-ietf-lpwan-schc-over-nbiot-03.txt >
lpwan Working Group E. Ramos lpwan Working Group E. Ramos
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational A. Minaburo Intended status: Informational A. Minaburo
Expires: November 18, 2020 Acklio Expires: 14 January 2021 Acklio
May 17, 2020 13 July 2020
SCHC over NB-IoT SCHC over NB-IoT
draft-ietf-lpwan-schc-over-nbiot-02 draft-ietf-lpwan-schc-over-nbiot-03
Abstract Abstract
The Static Context Header Compression (SCHC) specification describes The Static Context Header Compression (SCHC) specification describes
a header compression and fragmentation functionalities for LPWAN (Low a header compression and fragmentation functionalities for LPWAN (Low
Power Wide Area Networks) technologies. SCHC was designed to be Power Wide Area Networks) technologies. SCHC was designed to be
adapted over any of the LPWAN technologies. adapted over any of the LPWAN technologies.
This document describes the use of SCHC over the NB-IoT wireless This document describes the use of SCHC over the NB-IoT wireless
access, and provides elements for an efficient parameterization. access, and provides elements for an efficient parameterization.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 18, 2020. This Internet-Draft will expire on 14 January 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6 4. Data Transmission . . . . . . . . . . . . . . . . . . . . . . 6
5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7 5. IP based Data Transmission . . . . . . . . . . . . . . . . . 7
5.1. SCHC over User Plane transmissions . . . . . . . . . . . 7 5.1. SCHC over User Plane transmissions . . . . . . . . . . . 8
5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8 5.1.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 8
5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 8 5.2. Data Over Control Plane . . . . . . . . . . . . . . . . . 9
5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 9 5.2.1. SCHC Entities Placing . . . . . . . . . . . . . . . . 10
5.3. Parameters for Static Context Header Compression (SCHC) . 10 5.3. Parameters for Static Context Header Compression
5.3.1. SCHC Context initialization . . . . . . . . . . . . . 10 (SCHC) . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 10 5.3.1. SCHC Context initialization . . . . . . . . . . . . . 11
5.3.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 11
5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11 5.3.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 11
5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 11 5.3.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 12
5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 11 5.3.5. Fragmentation . . . . . . . . . . . . . . . . . . . . 12
6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 12 6. Non-IP based Data Transmission . . . . . . . . . . . . . . . 13
6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 12 6.1. SCHC Entities Placing . . . . . . . . . . . . . . . . . . 13
6.2. Parameters for Static Context Header Compression . . . . 13 6.2. Parameters for Static Context Header Compression . . . . 13
6.2.1. SCHC Context initialization . . . . . . . . . . . . . 13 6.2.1. SCHC Context initialization . . . . . . . . . . . . . 14
6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. SCHC Rules . . . . . . . . . . . . . . . . . . . . . 14
6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Rule ID . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14 6.2.4. SCHC MAX_PACKET_SIZE . . . . . . . . . . . . . . . . 14
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 14
6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 14 6.3.1. Fragmentation modes . . . . . . . . . . . . . . . . . 15
6.3.2. Fragmentation Parameters(TBD) . . . . . . . . . . . . 14 6.3.2. Fragmentation Parameters . . . . . . . . . . . . . . 15
7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Security considerations . . . . . . . . . . . . . . . . . . . 16 8. Security considerations . . . . . . . . . . . . . . . . . . . 16
9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 16 9. 3GPP References . . . . . . . . . . . . . . . . . . . . . . . 16
10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. NB-IoT User Plane protocol architecture . . . . . . . . 17 10.1. NB-IoT User Plane protocol architecture . . . . . . . . 17
10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 17 10.1.1. Packet Data Convergence Protocol (PDCP) . . . . . . 17
10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17 10.1.2. Radio Link Protocol (RLC) . . . . . . . . . . . . . 17
10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18 10.1.3. Medium Access Control (MAC) . . . . . . . . . . . . 18
10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19 10.2. NB-IoT Data over NAS (DoNAS) . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 22 11. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The Static Context Header Compression (SCHC) The Static Context Header Compression (SCHC) {RFC8724} defines a
[RFC8724] defines a header compression header compression scheme and fragmentation functionality, both
scheme and fragmentation functionality, both specially tailored for specially tailored for Low Power Wide Area Networks (LPWAN) networks
Low Power Wide Area Networks (LPWAN) networks defined in [RFC8376]. defined in [RFC8376].
Header compression is needed to efficiently bring Internet Header compression is needed to efficiently bring Internet
connectivity to the node within an NB-IoT network. SCHC uses a connectivity to the node within an NB-IoT network. SCHC uses a
static context to performs header compression with specific static context to performs header compression with specific
parameters that need to be adapted into the NB-IoT wireless access. parameters that need to be adapted into the NB-IoT wireless access.
This document assumes functionality for NB-IoT of 3GPP release 15 This document assumes functionality for NB-IoT of 3GPP release 15
otherwise other versions functionality is explicitly mentioned in the otherwise other versions functionality is explicitly mentioned in the
text. text.
This document describes the use of SCHC and its parameterizing over This document describes the use of SCHC and its parameterizing over
the NB-IoT wireless access. the NB-IoT wireless access.
2. Terminology 2. Terminology
This document will follow the terms defined in This document will follow the terms defined in [RFC8724], in
[RFC8724], in [RFC8376], and the [RFC8376], and the [TGPP23720].
[TGPP23720].
o CIoT. Cellular IoT * CIoT. Cellular IoT
o C-SGN. CIoT Serving Gateway Node * C-SGN. CIoT Serving Gateway Node
o UE. User Equipment * UE. User Equipment
o eNB. Node B. Base Station that controls the UE * eNB. Node B. Base Station that controls the UE
o EPC. Evolved Packet Connectivity. Core network of 3GPP LTE * EPC. Evolved Packet Connectivity. Core network of 3GPP LTE
systems. systems.
o EUTRAN. Evolved Universal Terrestrial Radio Access Network. * EUTRAN. Evolved Universal Terrestrial Radio Access Network.
Radio network from LTE based systems. Radio network from LTE based systems.
o MME. Mobility Management Entity. Handle mobility of the UE * MME. Mobility Management Entity. Handle mobility of the UE
o NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology * NB-IoT. Narrow Band IoT. Referring to 3GPP LPWAN technology
based in LTE architecture but with additional optimization for IoT based in LTE architecture but with additional optimization for IoT
and using a Narrow Band spectrum frequency. and using a Narrow Band spectrum frequency.
o SGW. Serving Gateway. Routes and forwards the user data packets * SGW. Serving Gateway. Routes and forwards the user data packets
through the access network through the access network
o HSS. Home Subscriber Server. It is a database that performs * HSS. Home Subscriber Server. It is a database that performs
mobility management mobility management
o PGW. Packet Data Node Gateway. An interface between the internal * PGW. Packet Data Node Gateway. An interface between the internal
with the external network with the external network
o PDU. Protocol Data Unit. Data packets including headers that are * PDU. Protocol Data Unit. Data packets including headers that are
transmitted between entities through a protocol. transmitted between entities through a protocol.
o SDU. Service Data Unit. Data packets (PDUs) from higher layers * SDU. Service Data Unit. Data packets (PDUs) from higher layers
protocols used by lower layer protocols as a payload of their own protocols used by lower layer protocols as a payload of their own
PDUs that has not yet been encapsulated. PDUs that has not yet been encapsulated.
o IWK-SCEF. InterWorking Service Capabilities Exposure Function. * IWK-SCEF. InterWorking Service Capabilities Exposure Function.
Used in roaming scenarios and serves for interconnection with the Used in roaming scenarios and serves for interconnection with the
SCEF of the Home PLMN and is located in the Visited PLMN SCEF of the Home PLMN and is located in the Visited PLMN
o SCEF. Service Capability Exposure Function. EPC node for * SCEF. Service Capability Exposure Function. EPC node for
exposure of 3GPP network service capabilities to 3rd party exposure of 3GPP network service capabilities to 3rd party
applications. applications.
3. Architecture 3. Architecture
+--+ &nbsp; +--+
|UE| \ +-----+ +------+ |UE| \ +-----+ +------+
+--+ \ | MME |-----| HSS | +--+ \ | MME |-----| HSS |
\ / +-----+ +------+ \ / +-----+ +------+
+--+ \+-----+ / | +--+ \+-----+ / |
|UE| ----| eNB |- | |UE| ----| eNB |- |
+--+ /+-----+ \ | +--+ /+-----+ \ |
/ \ +------+ / \ +------+
/ \| | +------+ Service PDN / \| | +------+ Service PDN
+--+ / | S-GW |--| P-GW |-- e.g. Internet +--+ / | S-GW |--| P-GW |-- e.g. Internet
|UE| | | +------+ |UE| | | +------+
skipping to change at page 4, line 47 skipping to change at page 4, line 50
The architecture for 3GPP LTE network has been reused for NB-IoT with The architecture for 3GPP LTE network has been reused for NB-IoT with
some optimizations and simplifications known as Cellular IoT (CIoT). some optimizations and simplifications known as Cellular IoT (CIoT).
Considering the typical use cases for CIoT devices here are described Considering the typical use cases for CIoT devices here are described
some of the additions to the LTE architecture specific for CIoT. some of the additions to the LTE architecture specific for CIoT.
C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating C-SGN(CIoT Serving Gateway Node) is a deployment option co-locating
EPS entities in the control plane and user plane paths (for example, EPS entities in the control plane and user plane paths (for example,
MME + SGW + P-GW) and the external interfaces of the entities MME + SGW + P-GW) and the external interfaces of the entities
supported. The C-SGN also supports at least some of the following supported. The C-SGN also supports at least some of the following
CIoT EPS Optimizations: CIoT EPS Optimizations:
o Control Plane CIoT EPS Optimization for small data transmission. * Control Plane CIoT EPS Optimization for small data transmission.
o User Plane CIoT EPS Optimization for small data transmission. * User Plane CIoT EPS Optimization for small data transmission.
o Necessary security procedures for efficient small data * Necessary security procedures for efficient small data
transmission. transmission.
o SMS without combined attach for NB-IoT only UEs. * SMS without combined attach for NB-IoT only UEs.
o Paging optimizations for coverage enhancements. * Paging optimizations for coverage enhancements.
o Support for non-IP data transmission via SGi tunneling and/or * Support for non-IP data transmission via SGi tunneling and/or
SCEF. SCEF.
o Support for Attach without PDN (Packet Data Network) connectivity. * Support for Attach without PDN (Packet Data Network) connectivity.
Another node introduced in the CIOT architecture is the SCEF (Service Another node introduced in the CIOT architecture is the SCEF (Service
Capability Exposure Function) that provide means to securely expose Capability Exposure Function) that provide means to securely expose
service and network capabilities to entities external to the network service and network capabilities to entities external to the network
operator. The northbound APIS are defined by OMA and OneM2M. The operator. The northbound APIS are defined by OMA and OneM2M. The
main functions of a SCEF are: main functions of a SCEF are:
o Non-IP Data Delivery (NIDD) established through the SCEF. * Non-IP Data Delivery (NIDD) established through the SCEF.
o Monitoring and exposure of event related to UE reachability, loss * Monitoring and exposure of event related to UE reachability, loss
of connectivity, location reporting, roaming status, communication of connectivity, location reporting, roaming status, communication
failure and change of IMEI-IMSI association. failure and change of IMEI-IMSI association.
+-------+ +-------+
| HSS | | HSS |
+-+-----+ +-+-----+
/ /
+---------+ __/S6a +---------+ __/S6a
+--------+ | +-----+ +_/ +--------+ | +-----+ +_/
+----+ C-Uu | +---+-+ MME | | T6i+--------+ T7 +----+ +----+ C-Uu | +---+-+ MME | | T6i+--------+ T7 +----+
skipping to change at page 5, line 48 skipping to change at page 5, line 48
+----+ +--------+ | | | +----+ +--------+ | | |
|C-SGN| | |C-SGN| |
| |S11| | |S11|
+------+ | | | +------+ | | |
+--------+LTE-Uu| | | +--+-+ | +--------+LTE-Uu| | | +--+-+ |
|LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+ |LTE eMTC|(eMTC)|eNB +---+--+SGW | | S8+---+ +-----------+
| UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application| | UE +------+(eMTC)|S1 | | +-+---+PGW|SGi |Application|
+--------+ +------+ | +----+ | | +----+Server (AS)| +--------+ +------+ | +----+ | | +----+Server (AS)|
+---------+ +---+ +-----------+ +---------+ +---+ +-----------+
Figure 2: 3GPP optimized CIOT network architecture Figure 2: 3GPP optimized CIOT network architecture
4. Data Transmission 4. Data Transmission
3GPP networks deal not only with data transmitted end-to-end but also 3GPP networks deal not only with data transmitted end-to-end but also
with in-band signaling that is used between the nodes and functions with in-band signaling that is used between the nodes and functions
to configure, control and monitor the system functions and behaviors. to configure, control and monitor the system functions and behaviors.
The control data is handled using a Control Plane which has a The control data is handled using a Control Plane which has a
specific set of protocols, handling processes and entities. In specific set of protocols, handling processes and entities. In
contrast, the end-to-end or user data utilize a User Plane with contrast, the end-to-end or user data utilize a User Plane with
characteristics of its own separated from the Control Plane. The characteristics of its own separated from the Control Plane. The
skipping to change at page 10, line 29 skipping to change at page 10, line 42
+--------+ | +-----------+ | +-----------------+ | +--------+ +--------+ | +-----------+ | +-----------------+ | +--------+
| PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY | | PHY +--+--+ PHY | PHY +--+--+ PHY | PHY +-----+ PHY |
+--------+ +-----+-----+ +--------+--------+ | +--------+ +--------+ +-----+-----+ +--------+--------+ | +--------+
C-Uu/ S1-lite SGi C-Uu/ S1-lite SGi
CIOT/ LTE-Uu C-BS/eNB C-SGN PGW CIOT/ LTE-Uu C-BS/eNB C-SGN PGW
LTE eMTC LTE eMTC
UE UE
*PDCP is bypassed until AS security is activated [TGPP36300]. *PDCP is bypassed until AS security is activated [TGPP36300].
Figure 4 Figure 4
5.3. Parameters for Static Context Header Compression (SCHC) 5.3. Parameters for Static Context Header Compression (SCHC)
5.3.1. SCHC Context initialization 5.3.1. SCHC Context initialization
RRC (Radio Resource Control) protocol is the main tool used to RRC (Radio Resource Control) protocol is the main tool used to
configure the operation parameters of the AS transmissions for 3GPP configure the operation parameters of the AS transmissions for 3GPP
technologies. RoHC operation is configured with this protocol and it technologies. RoHC operation is configured with this protocol and it
is to expect that SCHC will be configured and the static context is to expect that SCHC will be configured and the static context
distributed in similar fashion for these scenarios. distributed in similar fashion for these scenarios.
5.3.2. SCHC Rules 5.3.2. SCHC Rules
skipping to change at page 13, line 25 skipping to change at page 13, line 45
| | XXX 3GPP RAN & +----+ XXX +---+ UDP | | | XXX 3GPP RAN & +----+ XXX +---+ UDP |
| | XXX CORE NETWORK XXX | | | | | XXX CORE NETWORK XXX | | |
| L2 +---+XX +------------+ | +--------+ | L2 +---+XX +------------+ | +--------+
| | XX |IP TUNNELING+--+ | | | | XX |IP TUNNELING+--+ | |
| | XXX +------------+ +---+ IP | | | XXX +------------+ +---+ IP |
+---------+ XXXX XXXX | +--------+ +---------+ XXXX XXXX | +--------+
| PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY | | PHY +------+ XXXXXXXXXXXXXXXXXXXXXXX +---+ PHY |
+---------+ +--------+ +---------+ +--------+
UE AS UE AS
Figure 5: SCHC entities placed when using Non-IP Delivery (NIDD) 3GPP Figure 5: SCHC entities placed when using Non-IP Delivery (NIDD)
Sevices 3GPP Sevices
6.2. Parameters for Static Context Header Compression 6.2. Parameters for Static Context Header Compression
6.2.1. SCHC Context initialization 6.2.1. SCHC Context initialization
The static context is handled in the application layer level, The static context is handled in the application layer level,
consequently the contexts are required to be distributed according to consequently the contexts are required to be distributed according to
the applications own capabilities, perhaps utilizing IP data the applications own capabilities, perhaps utilizing IP data
transmissions up to context initialization. Also the same IP transmissions up to context initialization. Also the same IP
tunneling or SCEF services used later for the SCHC packets transport tunneling or SCEF services used later for the SCHC packets transport
may be used by the applications in both ends to deliver the static may be used by the applications in both ends to deliver the static
contexts to be used. contexts to be used.
skipping to change at page 14, line 46 skipping to change at page 15, line 20
capillarity gateway, or due to buffer overflow handling in a backhaul capillarity gateway, or due to buffer overflow handling in a backhaul
connection. In consequence, it is possible to secure additional connection. In consequence, it is possible to secure additional
reliability on the packets transmitted with a small trade-off on reliability on the packets transmitted with a small trade-off on
additional transmissions to signal the packets arrival indication additional transmissions to signal the packets arrival indication
end-to-end if no transport protocol takes care of retransmission. To end-to-end if no transport protocol takes care of retransmission. To
achieve this, the packets fragmentation is activated with the ACK-on- achieve this, the packets fragmentation is activated with the ACK-on-
Error mode enabled. In some cases, it is even desirable to keep Error mode enabled. In some cases, it is even desirable to keep
track of all the SCHC packets delivered, in that case, the track of all the SCHC packets delivered, in that case, the
fragmentation function could be active for all packets transmitted by fragmentation function could be active for all packets transmitted by
the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on- the applications (SCHC MAX_PACKET_SIZE == 1 Byte) and the ACK-on-
Error mode. Error mode. In the NAS stratum, the use of only fragmentation when a
non-IP packet is transmitted is possible if this packet is considered
6.3.2. Fragmentation Parameters(TBD) as a SCHC packet and is identifyed using the RuleID for non-
compressing packets as {RFC8724} allows it, depending on the
o Rule ID. The Fragmentation Rule ID is given when choosing the application an ACK-onError mode may be used.
profile according to the fragmentation mode require. 1 bit can be
used to recognize each mode.
o DTag.
No_ACK. May take 1 bit.
ACK_on_Error. May take 1 bit.
o FCN (N value).
No_ACK. The value of N is 1.
ACK_on_Error. The value of N depends on the
o W (M value)
No_ACK. This field is not used in this mode
ACK_on_Error.
o WINDOW_SIZE
No_ACK. This mode does not use windows
ACK_on_Error.
o Retransmission Timer
No_ACK. This timmer is not used in this mode
ACK_on_Error. This timer needs to be set to 1h or 10h
o Inactivity Timer
No_ACK. Must be maintained and needs to be bigger than 1h or 10h
ACK_on_Error. Must be bigger than 1h or 10h
o MAX_ACK_REQUESTS
No_ACK. Not used in this mode.
ACK_on_Error.
o MIC (size and algorithm)
No_ACK.
ACK_on_Error.
o RCS 6.3.2. Fragmentation Parameters
No_ACK The Fragmentation Rule ID is given when choosing the profile
according to the fragmentation mode, 1 bit can be used to recognize
each mode.
ACK_on_Error. To adapt SCHC to the NB-IoT constraints, two configuration are
proposed to fill the best the transfer block (TB). The Header size
needs to be multiple of 4 and the Tiles can keep a fix value of 4 or
8 bits to avoid the need of padding.
o Tiles size * 8 bits-Header_size configuration, with the size of the header
fields as follow: Rule ID 3 bits, DTag 1 bit, FCN 3 bits, W 1
bits. This configuration may ne used with TB less than 300 bits.
No_ACK. Not used in this mode. * 16 bits-Header_size configuration, with the size of the header
fields as follow: 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.
ACK_on_Error. (also mention if the last tile is carried in a The IoT devices communicates with small data transfer and have a
regular fragment or in All-1 fragment) battery life of 10 years. To minise the power consumption these
devices use the Power Save Mode and the Idle Mode DRX which govern
how often the device wakes up, stays up and are 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 activities, the
Innactivity Timer may be above 1h or 10h and the Retransmission Timer
may be below than 1h or 10h.
7. Padding 7. Padding
NB-IoT and 3GPP wireless access, in general, assumes byte aligned NB-IoT and 3GPP wireless access, in general, assumes byte aligned
payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits payload. Therefore the L2 word for NB-IoT MUST be considered 8 bits
and the treatment of padding should use this value accordingly. and the treatment of padding should use this value accordingly.
8. Security considerations 8. Security considerations
3GPP access security is specified in (TGPP33203). 3GPP access security is specified in (TGPP33203).
9. 3GPP References 9. 3GPP References
o [TGPP23720] 3GPP, "TR 23.720 v13.0.0 - Study on architecture * [TGPP23720] 3GPP, "TR 23.720 v13.0.0 - Study on architecture
enhancements for Cellular Internet of Things", 2016. enhancements for Cellular Internet of Things", 2016.
o [TGPP33203] 3GPP, "TS 33.203 v13.1.0 - 3G security; Access * [TGPP33203] 3GPP, "TS 33.203 v13.1.0 - 3G security; Access
security for IP-based services", 2016. security for IP-based services", 2016.
o [TGPP36321] 3GPP, "TS 36.321 v13.2.0 - Evolved Universal * [TGPP36321] 3GPP, "TS 36.321 v13.2.0 - Evolved Universal
Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC)
protocol specification", 2016 protocol specification", 2016
o [TGPP36323] 3GPP, "TS 36.323 v13.2.0 - Evolved Universal * [TGPP36323] 3GPP, "TS 36.323 v13.2.0 - Evolved Universal
Terrestrial Radio Access (E-UTRA); Packet Data Convergence Terrestrial Radio Access (E-UTRA); Packet Data Convergence
Protocol (PDCP) specification", 2016. Protocol (PDCP) specification", 2016.
o [TGPP36331] 3GPP, "TS 36.331 v13.2.0 - Evolved Universal * [TGPP36331] 3GPP, "TS 36.331 v13.2.0 - Evolved Universal
Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC);
Protocol specification", 2016. Protocol specification", 2016.
o [TGPP36300] 3GPP, "TS 36.300 v15.1.0 - Evolved Universal * [TGPP36300] 3GPP, "TS 36.300 v15.1.0 - Evolved Universal
Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal
Terrestrial Radio Access Network (E-UTRAN); Overall description; Terrestrial Radio Access Network (E-UTRAN); Overall description;
Stage 2", 2018 Stage 2", 2018
o [TGPP24301] 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS) * [TGPP24301] 3GPP "TS 24.301 v15.2.0 - Non-Access-Stratum (NAS)
protocol for Evolved Packet System (EPS); Stage 3", 2018 protocol for Evolved Packet System (EPS); Stage 3", 2018
* [TGPP24088] 3GPP, "TS 24.088 v12.9.0 - Mobile radio interface
Layer 3 specification;Core network protocols; Stage 3", 2015.
10. Appendix 10. Appendix
10.1. NB-IoT User Plane protocol architecture 10.1. NB-IoT User Plane protocol architecture
10.1.1. Packet Data Convergence Protocol (PDCP) 10.1.1. Packet Data Convergence Protocol (PDCP)
Each of the Radio Bearers (RB) are associated with one PDCP entity. Each of the Radio Bearers (RB) are associated with one PDCP entity.
And a PDCP entity is associated with one or two RLC entities And a PDCP entity is associated with one or two RLC entities
depending of the unidirectional or bi-directional characteristics of depending of the unidirectional or bi-directional characteristics of
the RB and RLC mode used. A PDCP entity is associated either control the RB and RLC mode used. A PDCP entity is associated either control
plane or user plane which independent configuration and functions. plane or user plane which independent configuration and functions.
The maximum supported size for NB-IoT of a PDCP SDU is 1600 octets. 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 main services and functions of the PDCP sublayer for NB-IoT for
the user plane include: the user plane include:
o Header compression and decompression by means of ROHC (Robust * Header compression and decompression by means of ROHC (Robust
Header Compression) Header Compression)
o Transfer of user and control data to higher and lower layers * Transfer of user and control data to higher and lower layers
o Duplicate detection of lower layer SDUs when re-establishing * Duplicate detection of lower layer SDUs when re-establishing
connection (when RLC with Acknowledge Mode in use for User Plane connection (when RLC with Acknowledge Mode in use for User Plane
only) only)
o Ciphering and deciphering * Ciphering and deciphering
o Timer-based SDU discard in uplink * Timer-based SDU discard in uplink
10.1.2. Radio Link Protocol (RLC) 10.1.2. Radio Link Protocol (RLC)
RLC is a layer-2 protocol that operates between the UE and the base 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 station (eNB). It supports the packet delivery from higher layers to
MAC creating packets that are transmitted over the air optimizing the MAC creating packets that are transmitted over the air optimizing the
Transport Block utilization. RLC flow of data packets is Transport Block utilization. RLC flow of data packets is
unidirectional and it is composed of a transmitter located in the unidirectional and it is composed of a transmitter located in the
transmission device and a receiver located in the destination device. transmission device and a receiver located in the destination device.
Therefore to configure bi-directional flows, two set of entities, one Therefore to configure bi-directional flows, two set of entities, one
in each direction (downlink and uplink) must be configured and they in each direction (downlink and uplink) must be configured and they
are effectively peered to each other. The peering allows the are effectively peered to each other. The peering allows the
transmission of control packets (ex., status reports) between transmission of control packets (ex., status reports) between
entities. RLC can be configured for data transfer in one of the entities. RLC can be configured for data transfer in one of the
following modes: following modes:
o Transparent Mode (TM). In this mode RLC do not segment or * Transparent Mode (TM). In this mode RLC do not segment or
concatenate SDUs from higher layers and do not include any header concatenate SDUs from higher layers and do not include any header
to the payload. When acting as a transmitter, RLC receives SDUs to the payload. When acting as a transmitter, RLC receives SDUs
from upper layers and transmit directly to its flow RLC receiver from upper layers and transmit directly to its flow RLC receiver
via lower layers. Similarly, an TM RLC receiver would only via lower layers. Similarly, an TM RLC receiver would only
deliver without additional processing the packets to higher layers deliver without additional processing the packets to higher layers
upon reception. upon reception.
o Unacknowledged Mode (UM). This mode provides support for * Unacknowledged Mode (UM). This mode provides support for
segmentation and concatenation of payload. The size of the RLC segmentation and concatenation of payload. The size of the RLC
packet depends of the indication given at a particular packet depends of the indication given at a particular
transmission opportunity by the lower layer (MAC) and are octets transmission opportunity by the lower layer (MAC) and are octets
aligned. The packet delivery to the receiver do not include aligned. The packet delivery to the receiver do not include
support for reliability and the lost of a segment from a packet support for reliability and the lost of a segment from a packet
means a whole packet loss. Also in case of lower layer means a whole packet loss. Also in case of lower layer
retransmissions there is no support for re-segmentation in case of retransmissions there is no support for re-segmentation in case of
change of the radio conditions triggering the selection of a change of the radio conditions triggering the selection of a
smaller transport block. Additionally it provides PDU duplication smaller transport block. Additionally it provides PDU duplication
detection and discard, reordering of out of sequence and loss detection and discard, reordering of out of sequence and loss
detection. detection.
o Acknowledged Mode (AM). Additional to the same functions * Acknowledged Mode (AM). Additional to the same functions
supported from UM, this mode also adds a moving windows based supported from UM, this mode also adds a moving windows based
reliability service on top of the lower layer services. It also reliability service on top of the lower layer services. It also
provides support for re-segmentation and it requires bidirectional provides support for re-segmentation and it requires bidirectional
communication to exchange acknowledgment reports called RLC Status communication to exchange acknowledgment reports called RLC Status
Report and trigger retransmissions is needed. Protocol error Report and trigger retransmissions is needed. Protocol error
detection is also supported by this mode. The mode uses depends detection is also supported by this mode. The mode uses depends
of the operator configuration for the type of data to be of the operator configuration for the type of data to be
transmitted. For example, data transmissions supporting mobility transmitted. For example, data transmissions supporting mobility
or requiring high reliability would be most likely configured or requiring high reliability would be most likely configured
using AM, meanwhile streaming and real time data would be map to a using AM, meanwhile streaming and real time data would be map to a
skipping to change at page 19, line 32 skipping to change at page 19, line 32
/ / / _/ _// _/ _/ / LCID2 / / / / _/ _// _/ _/ / LCID2 /
| | | | | / _/ _/ / ___/ | | | | | / _/ _/ / ___/
| | | | || | | / / | | | | || | | / /
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad| MAC |MAC|RLC|PDCP|AP1|RLC|PDCP|AP1|RLC|PDCP|AP2| |MAC|RLC|AP2|Pad|
|Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din| |Hea|Hea|Hea |PDU|Hea|Hea |PDU|Hea|Hea |PDU| |Hea|Hea|PDU|din|
|der|der|der | |der|der | |der|der | | |der|der| |g | |der|der|der | |der|der | |der|der | | |der|der| |g |
+------------------------------------------+ +-----------+---+ +------------------------------------------+ +-----------+---+
TB1 TB2 TB1 TB2
Figure 6: Example of User Plane packet encapsulation for two Figure 6: Example of User Plane packet encapsulation for two
transport blocks transport blocks
10.2. NB-IoT Data over NAS (DoNAS) 10.2. NB-IoT Data over NAS (DoNAS)
The AS protocol stack used by DoNAS is somehow special. Since the The AS protocol stack used by DoNAS is somehow special. Since the
security associations are not established yet in the radio network, security associations are not established yet in the radio network,
to reduce the protocol overhead, PDCP (Packet Data Convergence to reduce the protocol overhead, PDCP (Packet Data Convergence
Protocol) is bypassed until AS security is activated. RLC (Radio Protocol) is bypassed until AS security is activated. RLC (Radio
Link Control protocol) is configured by default in AM mode, but Link Control protocol) is configured by default in AM mode, but
depending of the features supported by the network and the terminal depending of the features supported by the network and the terminal
it may be configured in other modes by the network operator. For it may be configured in other modes by the network operator. For
skipping to change at page 22, line 32 skipping to change at page 22, line 32
| | LCID1 | \ | | / | | LCID1 | \ | | /
| | | \ \ | | | | | \ \ | |
| | | \ \ | | | | | \ \ | |
| | | \ \ \ | | | | \ \ \ |
+----+----+----------++-----|----+---------++----+---------|---+ +----+----+----------++-----|----+---------++----+---------|---+
MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad| MAC |MAC |RLC | RLC ||MAC |RLC | RLC ||MAC | RLC |Pad|
|Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | | |Head|Head| PAYLOAD ||Head |Head| PAYLOAD ||Head| PDU | |
+----+----+----------++-----+----+---------++----+---------+---+ +----+----+----------++-----+----+---------++----+---------+---+
TB1 TB2 TB3 TB1 TB2 TB3
Figure 8: Example of User Plane packet encapsulation for Data over Figure 8: Example of User Plane packet encapsulation for Data
NAS over NAS
11. Informative References 11. Informative References
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
Zuniga, "SCHC: Generic Framework for Static Context Header
Compression and Fragmentation", April 2020,
<https://www.rfc-editor.org/infor/rfc8724>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust
Header Compression (ROHC) Framework", RFC 5795, Header Compression (ROHC) Framework", RFC 5795,
DOI 10.17487/RFC5795, March 2010, <https://www.rfc- DOI 10.17487/RFC5795, March 2010,
editor.org/info/rfc5795>. <https://www.rfc-editor.org/info/rfc5795>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>. <https://www.rfc-editor.org/info/rfc8376>.
[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
Zúñiga, "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 Authors' Addresses
Edgar Ramos Edgar Ramos
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
02420 Jorvas, Kirkkonummi FI- 02420 Jorvas, Kirkkonummi
Finland Finland
Email: edgar.ramos@ericsson.com Email: edgar.ramos@ericsson.com
Ana Minaburo Ana Minaburo
Acklio Acklio
1137A Avenue des Champs Blancs 1137A Avenue des Champs Blancs
35510 Cesson-Sevigne Cedex 35510 Cesson-Sevigne Cedex
France France
 End of changes. 72 change blocks. 
155 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/