See also: Developer Exchange.
Category: IETF Implementations
What This Project Implements
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 content 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.
Deployment Configurations
5G Broadcast with Content Delivery Protocols
The diagram below shows the content delivery protocol tools used with the LTE-based 5G Broadcast system, with links to the contributing component repositories.
5G Multicast Broadcast Services (MBS) with Content 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.
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 |
Coded Multisource Media Format (CMMF)
rt-cmmf-encoder is an early-stage reference implementation of ETSI TS 103 973 (Coded Multisource Media Format), packaging content for delivery from more than one network source at once. It is not yet feature-complete against the published standard — this is one of this project's more open areas, so check the repository's own issues and README for current status, and open an issue or pull request there if you want to help close the gap.
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 content delivery repositories; the Tutorials page has a demo video and repository pointers.
Related
- Repositories & Releases
- Slide deck: Content Delivery Protocols overview
- Tech: 5G Broadcast: TV, Radio and Emergency Alerts and Multicast & Broadcast in 5G — the delivery systems these transports run over
Refer to the content delivery repositories on GitHub to use or contribute to these Reference Tools. See How to Contribute for the process.