By Juha Korhonen, 3GPP MCC

The capabilities of mobile phone systems has been continuously growing, mobile system generation by generation. The development has been towards more data, faster, and with shorter delays. The progress has been remarkable. Whereas the very first GSM systems did not support any data transfer, only voice, and then only 9.6 kbps circuit-switched data, the latest 5G systems could deliver Mbps speeds, at least in theory.

This development has of course been advantageous for many applications and services. Users enjoy faster and better networked games, videos and fast access to Internet. However, with the emergence of Internet of Things (IoT), there will be in the future a very large number of physical devices, some of which will use mobile networks, and some of which may have very different data transport needs compared to traditional human users. It must be noted that Internet of Things does not mean that all IoT devices are connected to the Internet. Instead they must connected to any network via which they can communicate. These devices include sensors, watches, lighting devices, medical monitors, etc. Almost any device could be given communication capabilities with IoT technology.

However, many IoT devices do not need the very fast capabilities provided by 5G networks. They may communicate only rarely, send small amounts of data, and then stay quiet. But their numbers can be very large. For such devices the solutions provided by traditional 5G systems are unnecessary complex. For example, a temperature sensor may send only a very small amount of data at a time. The normal procedure for a 5G network in such a case would be to move the device from the inactive state to active state via control signalling, send the data in a data packet, and then move back to the inactive state using more control signalling. Since the transmission needs of the device are most probably periodical or at least frequent, the device needs to perform multiple transmission setup and release procedures to transfer relatively small amount of data each time.

As the payload data from an IoT device can be relatively small compared to the control signalling required to send it over the radio interface, making a connection for the small data transmission becomes a concern for both the network and the device due to the control signalling overhead. Because the number of IoT devices will be very large, the signalling overhead could become a serious issue; while the overall amount of payload data could be relatively small, the associated signalling could overburden the network. Moreover, control signalling consumes energy and especially many IoT devices have limited battery capacity. Therefore, less signalling translates into lower power consumption. As the NR standard supports massive number of IoT devices, SDT is needed to enable the smooth operation of NR networks.

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.