TOI

Transmission Object Identifier

Protocol →
Introduced in Rel-8

TOI is a protocol field in FLUTE/ALC that identifies data objects within a broadcast session, enabling receivers to request specific objects for repair or to identify service components.

Category
Protocol
Introduced
Rel-8
Where
Services › Codecs
Specifications
8 specs
TOI Description Purpose Related Classification Detected Changes Specifications

Description

The Transmission Object Identifier (TOI) is a fundamental field within the Asynchronous Layered Coding (ALC) and File Delivery over Unidirectional Transport (FLUTE) protocols, which are used for reliable content delivery over broadcast and multicast networks, such as those defined in 3GPP for Multimedia Broadcast Multicast Service (MBMS) and evolved MBMS (eMBMS). The TOI is a numeric identifier, typically 16 or 32 bits in length, that uniquely identifies a 'transmission object' within the scope of a single ALC/FLUTE session. A transmission object can be a file, a file segment, or any other discrete block of data that the sender wishes to deliver. The TOI is carried in the header of every ALC packet, allowing receivers to associate incoming packets with the correct object for reassembly.

Within the FLUTE protocol, the TOI is used in conjunction with the File Delivery Table (FDT). The FDT is an XML description that maps each TOI value to metadata about the corresponding file, such as its URI, content type, size, and message digest. When a receiver joins a FLUTE session, it first acquires the FDT (which itself is delivered as an object with a known, often TOI=0). By parsing the FDT, the receiver learns which TOI corresponds to which file it needs. As packets arrive, the receiver uses the TOI to direct packets to the correct reassembly buffer. If packets are missing, the receiver can use the TOI to precisely request retransmission of specific packets for that object using a separate repair protocol like NORM or ALC with LCT Channel.

The role of the TOI is critical for scalability and efficiency in broadcast scenarios. Since multiple files or large files segmented into many objects can be transmitted in an interleaved fashion over the same multicast channel, the TOI provides the necessary demultiplexing key at the receiver. It enables selective reception and repair, where a receiver can choose to only receive objects it is interested in (e.g., specific video segments for HTTP Adaptive Streaming over broadcast) and can request repair only for missing parts of those objects. This design minimizes receiver buffer requirements and network repair traffic. In 3GPP's eMBMS architecture, FLUTE with TOI is used in the application layer of the broadcast bearer for delivering files and segments to potentially massive numbers of UEs simultaneously.

Purpose & Motivation

The TOI was created to solve the problem of identifying and reassembling multiple discrete data objects within a single, continuous multicast or broadcast data stream. Prior to standardized object-based multicast protocols, bulk data delivery over broadcast often used monolithic streams or proprietary encapsulation, making selective reception, random access, and efficient error recovery difficult. The TOI, as part of the IETF's ALC/FLUTE framework adopted by 3GPP, provides a lightweight, standardized mechanism for this identification.

Its introduction into 3GPP specifications (e.g., TS 26.346 for MBMS) was motivated by the need for an efficient application-layer protocol for MBMS and eMBMS services. Services like mobile TV, software updates, and public warning systems require reliable delivery of many files or media segments to many users. The TOI enables the MBMS system to support these services efficiently by allowing the network to statelessly transmit objects and allowing receivers to independently manage which objects they consume and how they recover from packet loss. It addresses the limitation of receiver complexity, as the network does not need to manage individual receiver states; instead, the intelligence is pushed to the edge, with the TOI providing the common reference for all parties.

Classification

Part ofFLUTE
Related approachesALC

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-8, normative work from Rel-17.

Rel-17 2 changes

In Release 17, the TOI function was enhanced by introducing a reduced FLUTE FDT schema and a new manifest format specifically for Object Collection and Carousel. This allows for more efficient description and transport of file objects and associated metadata fragments within an MBMS download session. The update provides a structured way to manage object delivery, aligning with the existing framework for transporting metadata envelopes and fragments as file objects.

  • [5MBP3]: Feature reduced FLUTE FDT Schema TS 26.346CR0661
  • [5MBP3] Manifest format for Object Collection and Carousel TS 26.517CR0007
Rel-18 4 changes

In Release 18, the TOI function was enhanced with the introduction of a media delivery session identifier applicable across the M4, M7, and M11 interfaces, and the specification of an essential object manifest schema. Furthermore, context identifiers were added to the BaseRecord, and a MIME media type was formally registered for the object manifest to standardize its identification and handling.

  • [5GMS_Pro_Ph2] Media delivery session identifier at M4+M7+M11 TS 26.512CR0066
  • Essential object manifest schema update TS 26.517CR0020
  • [EVEX, TEI18] Add context identifiers to BaseRecord TS 26.512CR0076
  • [5MBP3] MIME media type registration for object manifest TS 26.517CR0026
Rel-19 1 change

In Release 19, the TOI function was enhanced to support in-session unicast repair for the MBMS download delivery method. This new associated delivery function allows a UE to request missing data for discrete objects, such as files or metadata fragments, after the initial MBMS broadcast transmission. The repair mechanism operates as an associated delivery function invoked by the UE, complementing the existing FLUTE-based broadcast delivery.

  • [AMD_PRO-MED] In-session Unicast Repair for MBMS Object Distribution TS 26.346CR0677

Explore further

Broader topics and technologies where TOI plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 26.346 vj20 MBMS User Services Media Codecs & Protocols Rel-19
TS 26.512 vj10 5G Media Streaming Protocols & APIs Rel-19
TS 26.517 vj10 5G MBS User Service Protocols and Formats Rel-19
TS 26.802 vj20 Multicast Enhancements for 5G Media Streaming Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TS 26.852 ve20 MBMS user service profiles, APIs and transport enabler study Rel-14
TR 26.946 vj00 MBMS User Services Overview Rel-19
TR 26.947 vj00 FEC Evaluation for MBMS Enhancement Rel-19