Category: IETF Implementations
What This Project Implements
Multimedia content delivery protocols carry media files and segments to receivers over broadcast and multicast networks, where there is no per-receiver return channel. 5G-MAG provides reference tools for these application-layer protocols (including FLUTE and ROUTE for file and object delivery) so that content packaged as DASH, HLS or CMAF can be delivered efficiently over both 5G Broadcast and 5G Multicast Broadcast Services (MBS). This page lists the specifications in scope and shows how the tools fit into the broader broadcast and multicast architectures. It is aimed at developers integrating these delivery protocols into a 5G media chain.
The multimedia delivery reference tools implement two of these application-layer transports:
- FLUTE (File Delivery over Unidirectional Transport) - the file-delivery transport, including the File Delivery Table (FDT) handling and FEC-based recovery. 5G-MAG maintains an open-source FLUTE library used in the 5G Broadcast tools.
- ROUTE (Real-Time Transport Object Delivery over Unidirectional Transport) - the real-time object transport, with Source and Repair Flows for low-latency segment delivery.
The tools sit above the media format: they carry DASH/HLS/CMAF segments and manifests as transport objects and are largely agnostic to the codec inside each segment.
High-level architecture
5G Broadcast with Multimedia delivery protocols
The diagram below shows the multimedia delivery protocol tools used with the LTE-based 5G Broadcast system, with links to the contributing component repositories.
5G Broadcast: Resources Multimedia content delivery protocols: Resources Common Tools
5G Multicast Broadcast Services (MBS) with Multimedia delivery protocols
The diagram below shows the same delivery protocol tools used with 5G Multicast Broadcast Services (MBS), with links to the contributing component repositories.
5G Multicast Broadcast Services: Resources Multimedia content delivery protocols: Resources 3GPP RAN and Core Platforms: Resources Common Tools
rt-libflute: what's implemented, feature by feature
The rest of this project's specification set (ROUTE, DASH/HLS/CMAF) is tracked at the role level above. FLUTE is 5G-MAG's own library, rt-libflute, so it gets a rigorous, per-feature audit against TS 26.346 and the FLUTE RFCs instead. The board below groups the audit by protocol area, so you can jump straight to the one you care about.
- FLUTE: File Delivery over Unidirectional Transport — the protocol this library implements. ALC / LCT: the two lower-level building blocks FLUTE is built on (congestion control and packet framing, respectively).
- FDT: File Delivery Table — a special FLUTE object (always sent with TOI 0) listing every file currently available in the session and how to decode it. Resent repeatedly ("carousel") so a receiver joining mid-session can still discover everything.
- TOI / TSI: Transport Object Identifier (which file a packet belongs to) and Transport Session Identifier (which session). Every FLUTE packet carries both.
- FEC: Forward Error Correction — redundant data that lets a receiver reconstruct a file even if some packets are lost, without a return channel to ask for a resend.
This describes the rt-libflute development branch as of 2026-08-11. It is a source-level reading of the code against the specification text, not a maintainer sign-off.
Raptor FEC (RFC 5053; TS 26.346 §7.2.2, §7.2.12, Annex B) — TS 26.346 §7.2.2 states: "A UE that supports MBMS User Services shall support a decoder for the Raptor FEC scheme." That decoder does not exist in development today. Everything else in this audit is either done or a narrower gap; this is the one place the implementation falls short of a hard MUST-level requirement central to what MBMS/MBS download is for — without it, every download relies solely on Compact No-Code FEC.
RFC 3926 / TS 26.346 §7.2Protocol core: FLUTE / ALC / LCT3/6
| Feature | Status | Notes |
|---|---|---|
| FLUTE version 1 on the wire (RFC 3926; TS 26.346 §7.2.0) | Yes | every FDT-carrying packet's EXT_FDT extension is stamped with version 1 in its high nibble on transmit. The decoder additionally tolerates a version 2 nibble on receive. Matches RFC 3926's own text: "This document specifies FLUTE version 1... MUST set this field to '1'." |
| LCT header fields (TS 26.346 §7.2.7) | Yes | CCI fixed at 32 bits and always zero; TSI as a 16-bit half-word (S=0, H=1); TOI as a 16-bit half-word on transmit (the decoder accepts a wider TOI); TOI 0 reserved exclusively for FDT Instances; Sender-Current-Time and Expected-Residual-Time flags always zero; HDR_LEN in 32-bit words. |
| LCT extension headers (TS 26.346 §7.2.8) | Yes | EXT_FDT and EXT_FTI generated on every FDT Instance (TOI 0) packet, omitted from every file (TOI>0) packet. EXT_CENC decoded on receive but never generated, since §7.2.8 separately requires FDT Instances never be content encoded. EXT_NOP/EXT_AUTH/EXT_TIME accepted and ignored on receive, matching RFC 3926's default action for unrecognised extensions. |
| Close Session / Close Object flags (TS 26.346 §7.2.7) | No | parsed on receive, but not settable on transmit |
| TSI wider than 16 bits on transmit (RFC 3451 §4.2, the LCT S/H flags) | No | silently truncated rather than using the S flag's 48-bit field width. Doesn't affect a compliant MBMS session, since §7.2.7 fixes MBMS TSI at 16 bits regardless; this would only matter for a caller using the library outside that profile. |
| FDT Instance ID wraparound (RFC 3926 §3.4.1) | No | the ID increments without bound instead of wrapping within the wire format's 20-bit field |
TS 26.346 §7.2.2Forward Error Correction1/2
| Feature | Status | Notes |
|---|---|---|
| Compact No-Code FEC (RFC 3695; TS 26.346 §7.2.2, §7.2.3) | Yes | FEC Payload ID as a 16-bit Source Block Number plus a 16-bit Encoding Symbol ID (§7.2.7); source-block partitioning follows RFC 3926's "Algorithm for Computing Source Block Structure" (§7.2.3). Works correctly, but carries no redundancy at all: a lost packet loses that piece of the file until the next FDT carousel cycle. |
| Raptor FEC (RFC 5053; TS 26.346 §7.2.2, §7.2.12, Annex B) | No | the gap that matters most: §7.2.2 requires every MBMS User Services UE to support a Raptor decoder, and that decoder does not exist in the development branch today. See the caution above this board. |
| RaptorQ FEC (RFC 6330) | N/A | reference only, not part of this standard: it doesn't appear anywhere in TS 26.346's FEC scheme definitions (§7.2.2, §7.2.12). Not required, not forbidden, simply outside this standard's scope; would matter only for a non-3GPP deployment or a future 3GPP adoption. |
TS 26.346 §7.2.9FDT Instances3/6
| Feature | Status | Notes |
|---|---|---|
| Mandatory FDT attributes (TS 26.346 §7.2.9) | Yes | every FDT Instance and File entry carries Content-Location, TOI and Expires, the three elements §7.2.9 marks mandatory |
| Optional FDT attributes (TS 26.346 §7.2.9) | Yes | Content-Length, Content-Type, Content-Encoding, Content-MD5, and the FEC-OTI-* attributes are all read and written. Content-MD5 is actively checked: a mismatch on reception triggers re-reception rather than silently accepting a corrupt file. |
| 3GPP FDT extensions (TS 26.346 §7.2.10, §7.2.13) | Yes | mbms2007:Cache-Control (no-cache, Expires) and mbms2012:File-ETag, both read and written |
| FDT expiry hard enforcement (TS 26.346 §7.2.9) | Partial | §7.2.9 requires: "the UE shall not use a received FDT Instance to interpret packets received beyond the expiration time." The Expires value is parsed and made available to callers (cache-eviction logic reads it), but nothing in the packet-receive path itself checks an FDT Instance's expiry before using it to interpret an incoming packet. The common case is covered by cache eviction; the hard, spec-mandated cutoff at packet-processing time is not yet there. |
| Complete attribute (RFC 3926 §3.4.2; TS 26.346 §7.2.9) | No | marking an FDT Instance as the final, definitive file list for the session |
| Group, MBMS-Session-Identity/Expiry, FullFDT, Decryption-KEY-URI, FEC-Redundancy-Level (§7.2.6, §7.2.11, §7.2.14–7.2.16) | No | and the Rel-11/Rel-13 extensions (Alternate-Content-Location, IndependentUnitPositions) |
TS 26.346 §7.2.5, §7.2.8Content encodingall implemented
| Feature | Status | Notes |
|---|---|---|
| GZIP content encoding (RFC 1952; TS 26.346 §7.2.5) | Yes | files GZIP-encoded on transmit, decoded on receive; decoded length is checked against the declared Content-Length. Deflate also handled. |
| FDT Instances never content encoded (TS 26.346 §7.2.8) | Yes | a separate rule from the file-encoding one above; enforced on transmit |
RFC 4607 / TS 23.247Transport, session and platform3/6
| Feature | Status | Notes |
|---|---|---|
| UDP multicast, IPv4 and IPv6 | Yes | transmit and receive both work over plain UDP multicast on either protocol |
| UDP tunnel mode (TS 23.247, the N3mb transport context) | Yes | encapsulated IPv4+UDP inner headers for delivery through a GTP-U user plane, used by rt-mbs-transport-function |
| IPsec ESP protection | Yes | both transmit and receive directions, via Linux XFRM/netlink |
| Source-Specific Multicast (SSM) (RFC 4607) | Partial | implemented for IPv4; the IPv6 path isn't at parity |
| Multicast join on a specific interface | Partial | also IPv4-only; not yet at parity for IPv6 |
| Receive buffer sized to the maximum UDP datagram | No | currently fixed well below that, which can silently truncate large encoding symbols |
TS 26.346 §5.2, §7.3, §9.xWhat rt-libflute deliberately doesn't do
rt-libflute implements the FLUTE/ALC/LCT protocol layer and FEC, the transport itself. The layers around it are the consuming application's job, not the library's. They are implemented in the reference tools that sit above rt-libflute: rt-mbs-transport-function, rt-mbs-client, rt-mbms-bmsc, and rt-mbms-client.
| Feature | Status | Notes |
|---|---|---|
| SDP session descriptions for FLUTE sessions (TS 26.346 §7.3) | N/A | parsed/generated by rt-mbms-client, rt-mbs-client and the transport functions |
| Service announcement / User Service Description (§5.2) | N/A | how a receiver discovers a session exists in the first place |
| Associated delivery procedures: file repair (§9.3), reception reporting (§9.4), consumption reporting (§9.4A) | N/A | all of which need a return channel, which this protocol by design doesn't have |
| OMA Push (§7.4), RTSP session control (§7.5), Keep Updated service (§7.7), partial file handling (§7.9) | N/A | |
| MBSTF/MBS service APIs (TS 29.581) and MBMS client APIs (TS 26.347) | N/A |
Getting Started
- Choose a transport for your delivery model: FLUTE for a file/download model (as in MBMS), ROUTE for a real-time segment model.
- Package your content as DASH or HLS using CMAF segments so a single set of segments can serve both.
- Feed the segments and manifest through the delivery tool for your target system (5G Broadcast or 5G MBS), following the architectures above.
- Build from the multimedia delivery repositories; the Tutorials page has a demo video and repository pointers.
Roadmap
This page links to the public roadmap boards tracking work on the multimedia content delivery protocol tools, including transport support for the Multimedia Broadcast Multicast Service (MBMS) delivery protocols ROUTE and FLUTE.
General Project Roadmap
The Kanban board below tracks the planned and in-progress work for Multimedia Content Delivery (ROUTE and FLUTE transport support for the 5G Broadcast components). It is maintained live on GitHub.
Developer Kanban Boards
MBMS: Support for ROUTE
All issues and functionality around ROUTE support for the 5G Broadcast components
MBMS: Support for FLUTE
All issues and functionality around FLUTE support for the 5G Broadcast components. Includes functionality like Forward Error Correction (FEC).
Related
- Standards: Multimedia Delivery Protocols — the full specification list, including the 3GPP chain that mandates FLUTE version 1 rather than v2. The transports are stable IETF RFCs, so there is no 3GPP-style release cadence at the transport layer; the tools track the current RFCs and the ways 5G Broadcast and 5G MBS reference them.
- Tech: Multimedia Delivery Protocols — the LCT/ALC/FEC building blocks, FLUTE compared with ROUTE, and how DASH/HLS/CMAF are carried over them
- Tech: 5G Broadcast: TV, Radio and Emergency Alerts and Multicast & Broadcast in 5G — the delivery systems these transports run over
- Resources
- Tutorials
Refer to the multimedia delivery repositories on GitHub to use or contribute to these Reference Tools.