SDT

Service Description Table

Services →
Introduced in Rel-5 Also in: Services, Core Network

SDT is a data structure in broadcast/multicast services that provides a complete listing and description of available services to enable receivers to discover, select, and decode streams.

Category
Services
Introduced
Rel-5
Where
Radio Access Network › NG-RAN (5G)
Also touches
2 segments
Specifications
17 specs
SDT Description Purpose Related Classification Detected Changes Specifications

Description

The Service Description Table (SDT) is a key signaling table used in 3GPP broadcast and multicast service delivery frameworks, such as Multimedia Broadcast Multicast Service (MBMS) and 5G Media Streaming (5GMS). It is a structured dataset that provides descriptive metadata about the services available within a broadcast stream. The SDT lists each service, assigns it a unique identifier, and provides information necessary for a receiver to access and interpret that service, such as the service name, service type, and references to other essential tables or components.

Architecturally, the SDT is generated by the broadcast service provider or network and is multiplexed into the transport stream (e.g., FLUTE/ALC session in MBMS) or delivered via an application layer protocol. It works in conjunction with other tables like the Program Map Table (PMT) or Media Presentation Description (MPD) in DASH-based streaming. Key components of an SDT entry include the service_id, service_descriptors (which can contain text names, provider info, and service type classification), and pointers to other descriptors that may indicate the location of electronic service guide (ESG) data or component streams. The receiver parses the SDT to build a user-presentable list of available services.

Its role is to act as the primary service discovery mechanism within a broadcast/multicast session. Without the SDT, a receiver would only see a raw data stream without knowledge of what services (e.g., TV channel, radio station, file delivery session) it contains or how to decode them. It is therefore fundamental for user interaction, enabling channel surfing, service selection, and ensuring the receiver configures the correct decoders for audio, video, or data components associated with the chosen service.

Purpose & Motivation

The SDT was created to solve the problem of service discovery and identification in IP-based broadcast and multicast systems. In traditional digital TV broadcasting (like DVB), similar tables (e.g., DVB-SI) serve this purpose. As 3GPP developed MBMS to deliver multimedia over cellular networks, a standardized, efficient method was needed to describe services within an IP multicast flow, motivating the adoption and adaptation of the SDT concept.

The core problem it addresses is informing the user equipment about 'what is available' in a broadcast service area. Prior to its standardization, proprietary or non-interoperable methods would have hindered the widespread adoption of broadcast services, as each vendor's receiver might need custom logic to find services. The SDT provides a universal, well-defined format that ensures any compliant receiver can discover all services offered by any network operator.

It overcomes the limitations of pure IP multicast, where a receiver might join a multicast group but have no inherent information about the content's nature or how to present it. The SDT adds this essential service layer metadata, making broadcast services user-friendly and interoperable. Its evolution through releases reflects the expansion of broadcast use cases from MBMS/TV services to include public warning, automotive, and 5G broadcast, requiring more sophisticated service descriptions and integration with streaming protocols like DASH.

Classification

Part ofMBMS
Specific typesNIT
Related approachesFLUTE

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (102 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-17 59 changes

In Release 17, 3GPP introduced the SDT (Small Data Transmission) function, including both RACH-based (RA-SDT) and Configured Grant-based (CG-SDT) procedures. The release also defined specific SDT configurations for Reduced Capability (RedCap) devices and addressed corrections and clarifications for security, triggering, and RRC handling within the SDT framework.

+ 53 more changes

Rel-18 42 changes

In Release 18, the key new SDT features included the introduction of Mobile-Terminated SDT (MT-SDT) and enhancements for both Configured Grant SDT (CG-SDT) and Random Access SDT (RA-SDT). Specifically, these enhancements covered support for oversize uplink data arrival, a procedure for switching from an SDT state to a connected state, and the introduction of beam failure recovery for RA-SDT. Furthermore, the release defined a maximum time duration to initiate CG-SDT and specified an RRCRelease message with a resume indication for SDT procedures.

  • 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

Rel-19 1 change

In Release 19, the primary update to the Service Description Table (SDT) function involved making corrections to its associated measurements. This work was specifically documented in a Change Request for the relevant management specification.

  • Rel-19 CR TS 28.552 Corrections on SDT measurements TS 28.552CR0716

Explore further

Broader topics and technologies where SDT plays a role.

Defining Specifications

3GPP specifications that define or reference SDT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 23.273 vj50 5G Location Services Stage 2 Architecture Rel-19
TS 23.887 vc00 Architectural enhancements for MTC and mobile data Rel-12
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 25.705 vd00 UMTS Small Data Transmission Enhancements Study Rel-13
TR 26.917 vj00 TV Service Enhancements over 3GPP Rel-19
TS 28.552 vk10 5G Performance Management Measurements Rel-20
TS 37.483 vj10 E1 Application Protocol (E1AP) Rel-19
TS 38.300 vj00 NG-RAN Overall Description Rel-19
TS 38.304 vj00 UE RRC_IDLE and RRC_INACTIVE Procedures Rel-19
TS 38.305 vj00 NG-RAN UE Positioning Stage 2 Rel-19
TS 38.321 vj00 NR MAC Protocol Specification Rel-19
TS 38.331 vj00 NR Radio Resource Control (RRC) Protocol Specification Rel-19
TS 38.401 vj10 NG-RAN Architecture Specification Rel-19
TS 38.423 vj10 Xn Application Protocol (XnAP) specification Rel-19
TS 38.473 vj10 5G F1 Application Protocol (F1AP) Rel-19
TS 38.523 vj20 5G NR UE Conformance Testing: Idle/Inactive Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.