Small Data Transmission (SDT) in LTE and 5G NR

One of the features that was introduced part of 5G NR 3GPP Release 17 is known as Small Data Transmission (SDT). When small amount of data, in case of an IoT device, needs to be sent, there is no need to establish data radio bearers. The information can be sent as part of signalling message. A similar approach is available in case of 4G LTE. 

Quoting from Ofinno whitepaper 'Small Data Transmission: PHY/MAC', 

The SDT in the 3GPP simply refers to data transmission in an inactive state. Specifically, the SDT is a transmission for a short data burst in a connectionless state where a device does not need to establish and teardown connections when small amounts of data need to be sent.

In the 3GPP standards, the inactive state had not supported data transmission until Release 15. The 3GPP standards basically allowed the data transmission when ciphering and integrity protection are achieved during the connection establishment procedure. Therefore, the data transmission can occur after the successful completion of the establishment procedure between the device and network.

The problem arises as a device stays in the connected state for a short period of time and subsequently releases the connection once the small size data is sent. Generally, the device needs to perform multiple transmissions and receptions of control signals to initiate and maintain the connection with a network. As a payload size of the data is relatively smaller compared with the amounts of the control signals, making a connection for the small data transmission becomes more of a concern for both the network and the device due to the control signaling overhead.

The 3GPP has developed the SDT procedure to enable data transmission in the inactive state over the existing LTE and NR standards. The device initiates the SDT procedure by transmitting an RRC request message (e.g., SDT request message) and data in parallel instead of transmitting the data after the RRC request message processed by a network. Additional transmission and/or reception are optional. The device performs this SDT procedure without transition to the connected state (i.e., without making a connection to the network).

The SDT enables for the network to accept data transmission without signaling intensive bearer establishment and authentication procedure required for the RRC connection establishment or resume procedure. For example, in the SDT procedure, the device needs only one immediate transmission of a transport block (TB) that contains data and RRC request message. Furthermore, the device does not need to perform procedures (e.g., radio link monitoring) defined in the connected state since the RRC state is kept as the inactive state. This results in improving the battery life of the device by avoiding control signaling unnecessary for transmission of small size data.

The principle of the SDT is very simple. The network configures radio resources beforehand for the data transmission in the inactive state. For example, if the conditions to use the configured radio resources satisfy, the device transmits data and the RRC request message together via the configured radio resources. In the 3GPP standards, there are two types of the SDT depending on the ways to configure the radio resources: (1) SDT using a random access (RA) and (2) SDT using preconfigured radio resources. 

Figure 2 (top) illustrates different types of the SDT referred in 3GPP LTE and NR standards. The SDT using the random access in LTE and NR standards is referred to as an EDT (early data transmission) and RA-SDT (Random Access based SDT), respectively. For both the EDT and the RA-SDT, the device performs data transmission using shared radio resources of the random access procedure. Thus, the contention with other devices can occur over the access to the shared radio resources. The shared radio resources for the SDT are broadcast by system information and are configured as isolated from the one for a nonSDT RA procedure, i.e., the legacy RA procedure. On the other hands, the CG-SDT uses the preconfigured radio resources dedicated to the device. The SDT using the preconfigured radio resource is referred to as transmission via PUR (Preconfigured Uplink Resource) in the LTE standards. The NR standards refers the SDT using the preconfigured radio resource as CG-SDT (Configured Grant based SDT). The network configures the configuration parameters of the preconfigured radio resources when transiting the device in the connected state to the inactive state. For example, an RRC release message transmitted from the network for a connection release contains the configuration parameters of PUR or CG-SDT. No contention is expected for the SDT using the preconfigured radio resource since the configuration parameters are dedicated to the device. 

You can continue reading the details in whitepaper here. Ofinno has another whitepaper on this topic, 'Small Data Transmission (SDT): Protocol Aspects' here.

3GPP also recently published an article on this topic here. Quoting from the article:

With SDT it is possible for the device to send small amounts of data while remaining in the inactive state. Note that this idea resembles the early GSM systems where SMS messages where sent via the control signalling; that is, transferring small amounts of data while the mobile did not have a (voice) connection.

SDT is a procedure which allows data and/or signalling transmission while the device remains in inactive state without transitioning to connected state. SDT is enabled on a radio bearer basis and is initiated by the UE only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled. Otherwise the normal data transmission scheme is used.

With SDT the data is transmitted quickly on the allocated resource. The IoT device initiates the SDT procedure by transmitting an RRC request message and payload data in parallel, instead of the usual procedure where the data is transmitted after the RRC request message is processed by a network.

It is not only the speed and the reduced size of the transmitted data which make SDT such a suitable process for IoT devices. Since the device stays in the inactive state, it does not have to perform many tasks associated with the active state. This further improves the battery life of the IoT device. Additional transmission and/or reception are optional.

There are two ways of performing SDT:

1. via random access (RA-SDT)
2. via preconfigured radio resources (CG-SDT)

Random Access SDT

With RA-SDT, the IoT device does not have a dedicated radio resource, and it is possible that the random access message clashes with similar RA-SDT random access messages from other IoT devices. The device gets to know the radio resources for the RA procedure from system information messages, in a similar way to non RA-SDT devices. However, the RA radio resources for SDT and non SDT devices are kept separate; that is, these device types do not interfere with each other in random access

The RA-SDT procedure can be a two-step or a four-step random access procedure. In two-step procedure the payload data is already sent with the initial random access message, whereas in four-step procedure the device first performs contention resolution with the random access request - random access response message pair, and then sends the UL payload with RRC Resume Request. The procedure may continue with further uplink and downlink small data transmissions, and then it is terminated with an RRC Release from the network.

Below are the signalling diagrams for both two-step and four-step RA-SDT procedures. Note that in both cases the UE stays in the RRC inactive state during the whole process.

Configured Grant SDT

For CG-SDT, the radio resources are allocated periodically based on the estimation of the UE’s traffic requirements. This uplink scheduling method is called Configured Grant (CG). With CG-SDT there will be no message clashes with other IoT devices since the radio resources are dedicated for each device. The resource allocation is signalled to the IoT device by the network when the device leaves the connected state.

If the amount of data in the UE's tx buffer is larger than a defined limit, then the data transmission is done using the normal non-SDT procedure.

For SDT process, the device selects the CG-SDT as the SDT type if the resources for the CG-SDT are configured on the selected uplink carrier. If the resources for the CG-SDT are unavailable or invalid, the RA-SDT or the non-SDT RA procedure will be chosen if those are configured. If no SDT type configuration is available then a normal non-SDT data transmission is performed.

With IoT devices proliferating, it makes sense to optimise data transfer and anything else that will reduce the power consumption and let the battery in the devices last for much longer.

Related Posts: 

• The 3G4G Blog: 3GPP Release 17 Description and Summary of Work Items
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: Energy Consumption in Mobile Networks and RAN Power Saving Schemes
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Are there 50 Billion IoT Devices yet?
• The 3G4G Blog: 5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD
• The 3G4G Blog: Introduction to 5G Reduced Capability (RedCap) Devices
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)
• Connectivity Technology Blog: Is LTE Cat 1bis Uniting the Fragmented Cellular IoT Market? 

A Technical Introduction to 5G NR RRC Inactive State

I looked at the RRC Inactive state back in 2017, but the standards were not completely defined. In the meantime standards have evolved and commercial 5G networks are rolling out left, right and centre. I made a short technical introduction to the RRC_INACTIVE state, comparing it with the 4G states in RRC and NAS. I also looked at some basic signalling examples and there are lots of relevant references at the end. Video and slides embedded below.

Advanced: 5G NR RRC Inactive State from 3G4G

Related Posts:

• The 3G4G Blog: Comparison Layer 2 Measurements LTE vs. 5G NR
• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend
• The 3G4G Blog: How LTE RRC (4G) and NR RRC (5G) Protocols are used in Parallel in EN-DC (5G NSA)
• The 3G4G Blog: EPS Fallback in 5G Standalone Deployments
• The 3G4G Blog: RRC states in 5G

Comparison Layer 2 Measurements LTE vs. 5G NR

Yesterday (2020-06-22) 3GPP uploaded the version 1.0 of TS 38.314 "Layer 2 Measurements" for 5G New Radio Rel. 16.

I was wondering about the difference compared to the same LTE standard defined in 3GPP TS 36.314.

The initial look at the table of contents shows significantly less measurements in the NR spec, but a new counter for the number of stored inactive UE contexts. This is due to the introduction of RRC Inactive state in NR RRC specified in 3GPP TS 38.331)

All other differences in the NR standard are related to chapter number 4.2.1.6 "Other measurements defined in TS 28.552".

Here one finds the references to Data Volume, Average Throughput Measurement per UE and DRB as well as PRB usage measurements.

Adding these additional measurements to the list we see in the table of contents it emerges that indeed the number of stored inactive UE contexts is the only major difference in comparison with the LTE standard. 

A Look into 5G Virtual/Open RAN - Part 3: Connection Release and Suspend

The 3rd post of this series introduces the details of connection release in the 5G RAN.

Indeed, we find most of the release causes known from E-UTRAN in the 5G specs and it is clear that all protocols that have been involved in the connection setup need to be perform a release procedure at the end of the connection.

However, again the split into different virtual functions brings the demand for some addition messages.

This is illustrated in figure 1 for the a release due to "user inactivity", which means: the gNB-CU UP detected that for a define time (typical settings for the user inactivity timer are expected to be between 10 and 20 seconds) no downlink payload packets have been arrived from the UPF to be transmitted.

So the gNB-CU UP sends an E1AP Bearer Context Inactivity Notification message to the gNB-CU CP that triggers the release procedures on NGAP, F1AP, RRC and E1AP. The RRC Releases message is transported over the F1 interface to the gNB-DU where is forwarded across the radio interface to the UE.

Figure 1: Connection Release due to "user inacativity"

An alternative to the connection release is the RRC Suspend procedure shown in figure 2. Here the UE is ordered to switch to the RRC Inactive state, which allows a very quick resume of the RRC connection when necessary.

Figure 2: RRC Connection Suspend

In case of suspending the RRC connection the RRC Release message contains a set of suspend configuration parameters. The probably most important one is the I-RNTI, the (RRC) Inactive Radio Network Temporary Identity.

If the RRC connection is suspended, F1AP and E1AP Contexts are released, but the NGAP UE Context remains active. Just NGAP RRC Inactivity Transition Report is sent to the AMF.

Related Posts:

• A Look into 5G Virtual/Open RAN - Part 4: Intra-gNB DU Handover
• 3G4G: Open RAN, OpenRAN and O-RAN

RRC states in 5G

Looking back at my old post about UMTS & LTE (re)selection/handovers, I wonder how many different kinds of handovers and (re)selection options may be needed now.

In another earlier post, I talked about the 5G specifications. This can also be seen in the picture above and may be easy to remember. The 25 series for UMTS mapped the same way to 36 series for LTE. Now the same mapping will be applied to 38 series for 5G. RRC specs would thus be 38.331.

A simple comparison of 5G and LTE RRC states can be seen in the picture above. As can be seen, a new state 'RRC Inactive' has been introduced. The main aim is to maintain the RRC connection while at the same time minimize signalling and power consumption.

Looking at the RRC specs you can see how 5G RRC states will work with 4G RRC states. There are still for further studies (FFS) items. Hopefully we will get more details soon.

3GPP TS 22.261, Service requirements for the 5G system; Stage 1 suggests the following with regards to inter-working with 2G & 3G

5.1.2.2 Legacy service support
The 5G system shall support all EPS capabilities (e.g., from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173) with the following exceptions:
- CS voice service continuity and/or fallback to GERAN or UTRAN,
- seamless handover between NG-RAN and GERAN,
- seamless handover between NG-RAN and UTRAN, and
- access to a 5G core network via GERAN or UTRAN.