LPWAN Static Context Header Compression (SCHC) over NB-IoT

## NB-IoT entities

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, roaming status, communication failure and change of IMEI-IMSI association.

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

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}.

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

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

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

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.

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

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.

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

| | | | | | | | | | | | +---------------------+| | | | | |Checks Integrity || | | | | |protection, decrypts || | | | | |data || | | | | +---------------------+| | | | | | Small data packet | | | |--------------------------------> | | | Small data packet | | | |<-------------------------------- | | +----------|---------+ | | | | | Integrity protection,| | | | | | encrypts data | | | | | | +--------------------+ | | | | | | | | | | |Downlink NAS| | | | | |message | | | | | |<-----------| | | | +-----------------------+ | | | | |Small Data Delivery, | | | | | |RRC connection release | | | | | +-----------------------+ | | | | | | | | +------------------+ ]]>

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.