Description
Small Data Transmission is a 3GPP mechanism for 5G New Radio that allows a user equipment to exchange a limited amount of uplink or downlink data while remaining in RRC_INACTIVE instead of performing a full transition to RRC_CONNECTED. The concept is especially important for sporadic traffic and IoT devices, where the cost of signaling, radio resource control, and state transition can be larger than the payload itself. By reusing the suspended access stratum context, security keys, and existing session information, SDT reduces control-plane overhead, shortens data delivery latency, and improves battery life. In the radio access network, SDT is primarily an RRC and MAC procedure, but it interacts with core-network session context because the UE still has a valid PDU session and security association. The procedure can be triggered by uplink data, downlink data notification, or periodic small reports, and the network decides whether the amount of data and radio conditions are suitable for SDT. If the payload exceeds configured thresholds or the UE needs dedicated resources, the network can resume the UE to RRC_CONNECTED. This makes SDT a controlled optimization rather than a replacement for normal connected-mode operation. Operationally, SDT is commonly associated with two NR approaches: random-access SDT and configured-grant SDT. In random-access SDT, the UE initiates a random-access procedure and includes a small amount of data in an RRC resume request or early data container, often carried in Msg3 for four-step random access or in MsgA for two-step random access. The network can respond with an RRC release, a resume message, or a message that carries downlink data, allowing the UE to return to or remain in RRC_INACTIVE. In configured-grant SDT, the network preconfigures uplink resources that the UE may use when it has small data, avoiding the full random-access exchange when the UE is already in a suitable cell and the resources are valid. Both methods require the UE to have a valid suspended context, a valid security context, and an allowed small-data condition. The network may also use paging or notification mechanisms to inform the UE that downlink data is available, and it may deliver that data during the SDT exchange rather than forcing a full resume. Key architectural elements include the UE, the serving gNB, the AMF, and the existing PDU session context. The UE stores an RRC_INACTIVE context that includes security parameters, radio capability information, and session-related data. The last serving gNB may keep a copy of the UE context, enabling faster handling of small data without involving the core network in a full resume. The AMF remains aware of the UE state and can participate in paging, notification, or context retrieval if the UE moves. The UPF may already have user-plane tunnels associated with the PDU session, so small packets can be forwarded when the radio layer permits transmission. The RAN decides whether to use SDT based on data volume, radio conditions, cell configuration, and UE capability. The core network may provide session and policy information that constrains which services or network slices can use SDT. SDT is constrained by several practical limits. The amount of data must be small enough to fit in the signaling container or preconfigured resources, and the UE must remain in a cell where SDT is allowed and resources are available. Cell reselection, handover, or invalid security contexts can require a full resume. The network must also balance power saving with reliability: if a packet is important, large, or requires guaranteed delivery, the UE should transition to RRC_CONNECTED. SDT may not provide the same level of scheduling flexibility, QoS enforcement, or mobility robustness as connected mode. Therefore, it is best suited for best-effort small payloads, periodic telemetry, simple control messages, and IoT traffic that can tolerate occasional retransmission or fallback. In the broader 5G ecosystem, SDT complements network slicing, power saving, and IoT optimizations. It allows operators to support massive numbers of low-activity devices without overwhelming the control plane with resume procedures. It also helps extend device battery life, which is critical for sensors, wearables, trackers, and utility meters. By keeping the UE in RRC_INACTIVE while still permitting data exchange, SDT provides a middle ground between dormant state and fully connected state, making the network more efficient for real-world traffic patterns.
Purpose & Motivation
SDT exists because many 5G devices generate traffic that is short, infrequent, and small, yet traditional mobile procedures assume that data exchange requires a full radio resource control connection. In LTE and earlier 5G deployments, even a few bytes could trigger random access, RRC resume, core-network signaling, and state transitions. For IoT and sporadic mobile applications, this overhead can dominate energy consumption and network capacity. Previous approaches, such as early data transmission in LTE, improved the situation but did not fully address the NR RRC_INACTIVE state and the need for a unified small-data mechanism in 5G. The motivation for SDT is to reduce signaling congestion, lower device power consumption, and shorten latency for small payloads while preserving security and mobility. It allows the network to handle massive numbers of devices with intermittent traffic without forcing each of them into connected mode. It also supports business cases for IoT, where battery life and low operational cost are essential. By making small-data exchange a native capability of RRC_INACTIVE, SDT helps 5G move from a connectivity model optimized for continuous mobile broadband toward a more efficient model for diverse service types, including sensors, telemetry, and background updates.
What changed in its specifications
The latest release-to-release comparison of specifications that define SDT. Each summary describes the whole specification, not only this term.
Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TR 21.905 →Rel-19 adds LMF-based AI/ML positioning support with Nlmf_DataExposure services. It also adds periodic location event procedures based on NRPPa measurements, MWAB location service clauses, and enhanced network automation enablers.
Full comparison in TS 23.273 →Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (110 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.
- Introduction of MT-SDT TS 37.483CR0054
- Introduction of MT-SDT in Stage-2 TS 38.300CR0711
- Introduction of maximum time duration to initiate CG-SDT in Stage-2 [CG-SDT-Enh] TS 38.300CR0743
- Support of oversize UL SDT Data Arrival [Large SDT Uplink Data] TS 38.300CR0748
- Introduction on MT-SDT TS 38.300CR0751
- Correction on SDT RRC Release with resume indication [SDT_ReleaseEnh] TS 38.300CR0872
+ 36 more changes
Defining Specifications
3GPP specifications that define or reference SDT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj20 | 3GPP Terminology and Definitions | Rel-19 read |
| TS 23.273 vj70 | 5G Location Services Architecture Stage 2 | Rel-19 read |
| TS 23.887 vc00 | Architectural enhancements for MTC and mobile data | Rel-12 read |
| TS 24.501 vk10 | 5GS NAS Protocol Specification | Rel-20 read |
| TS 25.705 vd00 | UMTS Small Data Transmission Enhancements Study | Rel-13 read |
| TR 26.917 vj00 | TV Service Enhancements over 3GPP | Rel-19 read |
| TS 28.552 vk40 | 5G Network Performance Measurements | Rel-20 read |
| TS 37.483 vj40 | E1 Application Protocol (E1AP) | Rel-19 read |
| TS 38.133 vk10 | NR Radio Resource Management Requirements | Rel-20 read |
| TS 38.300 vj40 | NR and NG-RAN Overall Description | Rel-19 read |
| TS 38.304 vj30 | NR UE Idle and Inactive State Procedures | Rel-19 read |
| TS 38.305 vj30 | NG-RAN UE Positioning Stage 2 | Rel-19 read |
| TS 38.321 vj40 | NR MAC Protocol Specification | Rel-19 read |
| TS 38.331 vj40 | NR Radio Resource Control (RRC) | Rel-19 read |
| TS 38.401 vj30 | NG-RAN Architecture Description | Rel-19 read |
| TS 38.423 vj40 | NG-RAN Xn Application Protocol | Rel-19 read |
| TS 38.473 vj40 | F1 Application Protocol (F1AP) | Rel-19 read |
| TS 38.523 vj40 | UE Conformance Specification for 5G NR | Rel-19 read |