Category: 3GPP Implementations
What This Project Implements
These reference tools implement parts of the 3GPP 5G Multicast Broadcast Services (MBS) feature. They are aimed at developers and integrators who want to run and inspect MBS delivery over a 5G Core, using multicast and broadcast to send the same media to many devices at once. To try the tools hands-on, see the Tutorials.
- 5GC: 5G Core network. NG-RAN: the 5G radio access network. UE: User Equipment (the device).
- MBSF / MBSTF: MBS Function (control) and MBS Transport Function (media data plane), the two MBS User Services network functions.
- MB-SMF / MB-UPF: the multicast/broadcast versions of the Session Management Function and User Plane Function in the 5G Core.
- AF / AS: the Application Function and Application Server on the MBS Application Provider side.
- TMGI: Temporary Mobile Group Identity, the identifier for an MBS session. SSM: Source-Specific Multicast address.
- FLUTE / ALC: File Delivery over Unidirectional Transport, carried in Asynchronous Layered Coding packets, used to send files one-way.
- PFCP: Packet Forwarding Control Protocol (control between MB-SMF and MB-UPF). GTP-U: the user-plane tunnelling protocol between core and RAN.
- PTM: Point-to-Multipoint delivery. NTN: Non-Terrestrial Network (satellite) access.
- MRB: MBS Radio Bearer, the radio bearer carrying broadcast traffic. MCCH / MTCH: the MBS Control and Traffic logical channels — MCCH announces the live sessions over the air, MTCH carries their content. G-RNTI: the group radio identity a session's MTCH is scheduled on.
In the context of 3GPP standards, the Multicast Broadcast Services System, MBS System, is designed to support multicast and broadcast services in 5G networks. It introduces a flexible architecture that supports both Multicast (for specific groups with high reliability) and Broadcast (for wide-area distribution to all users), allowing the network to dynamically switch between point-to-point and point-to-multipoint delivery. While the MBS System handles the heavy lifting of moving data through the 5G core and radio, MBS User Services defines how that content is actually packaged, discovered, and consumed by the end-user's application.
Technical documentation providing context to this project can be found in the link below.
Tech: Multicast and Broadcast Services in 5G Networks
Relevant specifications are listed below.
Standards: 5G Multicast Broadcast Services
Standards: Content Delivery Protocols
The MBS Broadcast delivery chain exists across the MBS Application Provider side, the MBS User Services network functions (MBSF, MBSTF), the 5GC (MB-SMF, MB-UPF, AMF) and the UE side (MBSF Client, MBS-Aware Application) on their release branches — but it does not run end-to-end on real RAN hardware or software radio today. Two release-branch defects break the chain by themselves: the MB-UPF never attaches the mandatory GTP-U PDU Session Container to downlink packets, and neither RAN fork's release branch implements the MCCH/SIB20 signalling a UE needs to discover a broadcast session over the air. Several fixes for these and other defects listed below exist only on unreleased development branches. MBS Multicast is not yet implemented.
High-level architecture
Architecture as defined by 3GPP TS 23.247 (system architecture) and TS 26.502 (user services), with the repository implementing each part.
Application providerTS 26.502
Reference pointsNmb10Nmb8
MBS User ServicesTS 26.502, TS 26.517
Reference pointsNmb2Nmb1Nmb9MBS-4-MC
5G CoreTS 23.247
Reference pointsN4mbN6mbN3mbN19mbN16mbNmb5N29mbNamf_MBSBroadcast
NG-RANTS 38.300 family
Reference pointsN2 (NGAP)E1APF1APUu (MCCH/MTCH)
UETS 26.502, TS 38.331
Reference pointsUuMBS-4-MCMBS-6MBS-7
Implementation state is derived from the per-feature audit below.
The chain above is the MBS Broadcast delivery mode. MBS Multicast is defined by the same architecture: its MB-SMF/MB-UPF data path (N6mb ingest, shared GTP-U delivery) already exists, but the UE session join via the SMF, PTP/PTM switching and group paging do not yet.
Implementation status
Every functional entity in the MBS Broadcast chain is audited per feature against its defining specifications. Each section below is split into plainly labelled groups, so you can jump straight to the component you care about.
This describes each repository's release branch only — main for the MBS User Services repositories (rt-mbs-function, rt-mbs-transport-function, rt-mbs-client, rt-mbs-application, rt-libflute) and for the Open5GS fork, and 5mbs for the srsRAN Project and srsRAN 4G forks — each read at its own most recent commit as of 2026-08-18 (dates range from 2025-10-02 for the gNB fork to 2026-08-07 for the most recently updated User Services repositories). Of these, rt-mbs-client and rt-mbs-application are private today; see Early Access to request access if you want to check this audit's claims against their source yourself. It deliberately excludes feature/mbs-compliance-fixes and other development/feature branches, which carry substantial fixes and new functionality that have not reached a release branch. This is a source-level reading of the code against the specification text; it is not backed by a live end-to-end test of the full delivery chain on these branches. Several defects found below — in particular the missing GTP-U PDU Session Container on the N3mb downlink and the complete absence of MCCH/SIB20 broadcast signalling on both RAN forks — mean the chain from the MB-UPF through the gNB to a real UE does not work today on these release branches, regardless of what earlier live testing on unreleased branches may have shown.
The tools target the MBS Broadcast delivery mode. On the release branches audited here it does not yet run fully end-to-end on real RAN hardware or software radio: the MB-UPF never attaches the mandatory GTP-U PDU Session Container to downlink packets (so a real gNB rejects them), and neither RAN fork's release branch implements the MCCH/SIB20 signalling a UE needs to discover a broadcast session over the air. The Namf_MBSBroadcast/NGAP/F1AP/E1AP session-release chain is also unimplemented at every layer. See the Implementation status board and the User plane path table below for the detail; several of these fixes exist only on unreleased development branches. For MBS Multicast, only the MB-SMF/MB-UPF data path (N6mb ingest, shared GTP-U delivery) exists; the session-join control plane (UE session join via the SMF, PTP/PTM switching, group paging) is not implemented in any component of the chain.
TS 29.580MBSF services at Nmb1016/20
| Feature | Status | Notes |
|---|---|---|
| MBS User Service: create (POST `/mbs-user-services`) | Yes | |
| MBS User Service: retrieve individual (GET `.../{userServiceId}`) | Yes | |
| MBS User Service: retrieve collection (GET `/mbs-user-services`) | Yes | returns the full JSON array of active User Services; this reached the release branch since the earlier 400-rejection behaviour was recorded (release-branch commit 4780a25) |
| MBS User Service: update (PUT) | Yes | |
| MBS User Service: modify (PATCH, RFC 7396) | Yes | reached the release branch (commit b37a022), superseding the earlier hold pending Standards#182 (issue #45) |
| MBS User Service: delete | Yes | |
| CreateMBSUserDataIngSession (POST `/sessions`) | Yes | |
| RetrieveIndMBSUserDataIngSession (GET `.../{sessionId}`) | Yes | |
| RetrieveMBSUserDataIngSessions (GET `/sessions`) | No | same collection-endpoint gap as the User Service list once had; unlike that one, no fix for this endpoint has reached the release branch |
| UpdateIndMBSUserDataIngSession (PUT) | Yes | with the §5.3.2.4.2 update rules enforced: create-only attributes (`mbsSessionId`, `mbsDistSessionId`, `locationDependent`) protected; any-time attributes (`mbsServInfo`, `tgtServAreas`, `extTgtServAreas`, `nrRedCapUeInfo`, ...) applied live, correctly gated to the parent service's real servType (`nrRedCapUeInfo`/`mbsFSAId` to BROADCAST, `restrictedFlag` to MULTICAST); INACTIVE-only attributes (`objDistrInfo`, `pckDistrInfo`, `maxContBitRate`) are also rejected while active, but two related gating fixes for this pair of attributes exist only on an unreleased branch and their exact release-branch edge-case behaviour was not independently re-verified here |
| TMGI allocation trigger when an ingest session carries no MBS session identifier | No | TS 29.580 §5.3.2.2.2 requires the MBSF to request TMGI allocation when none is provided; on the release branch the entry is silently skipped instead, with no response and no TMGI request, so the request hangs rather than erroring. A fix (501 response) exists only on an unreleased branch. Separately, when SSM+locationDependent triggers a TMGI request towards MB-SMF, that request is correctly gated — but MBSF has no TMGI-allocation logic of its own in either case; allocation is delegated entirely to MB-SMF |
| ModifyIndMBSUserDataIngSession (PATCH, RFC 7396) | Partial | add/update of `mbsDisSessInfos` map entries now merges key-by-key rather than replacing the whole map (release-branch commit f3cf170); but the clause's own delete-via-null-entry case (TS 29.580 §5.3.2.4.2: "if an existing MBS Distribution Session shall be deleted, the AF shall include the corresponding map entry set to the value 'NULL'") is explicitly rejected with 400 — a stated non-implementation, not a bug |
| DeleteIndMBSUserDataIngSession | Yes | |
| Scheduled activation (`actPeriods` / `actPeriodsRepRule`, mutually exclusive) | Yes | |
| CreateMBSUserDataIngStatSubsc (POST `/status-subscriptions`) | Yes | |
| RetrieveMBSUserDataIngStatSubscs / RetrieveInd (GET) | Yes | returned objects carry no id of their own — see Standards#191 |
| UpdateIndMBSUserDataIngStatSubsc (PUT) / ModifyInd (PATCH) | Yes | |
| DeleteMBSUserDataIngStatSubsc | Yes | |
| MBSUserDataIngStatNotif (notification to the provider callback URL, §6.2.5) | Yes | failed notifications are retried rather than dropped, but the retry loop has no bound on the release branch; a retry limit exists only on an unreleased branch |
| SBI feature negotiation (`supportedFeatures` per TS 29.500 §6.6) | No | the MBS User Service service registers no features and the Ingest Session service registers only feature 1 (5MBS2/ActivePeriodsRepRule); features 2 (MBSEventsExt), 3 (MBSErrorHandling) and 4 (MBSPatchEnh) are never declared even though PATCH itself now works, and there is no per-transaction suppFeat read/compare/echo anywhere outside this static NRF registration |
TS 26.502 / TS 26.517MBS User Services procedures and formats7/12
| Feature | Where | Status | Notes |
|---|---|---|---|
| Service Announcement mode `PASSED_BACK` — bundle handed back to the Application Provider at Nmb10 for out-of-band distribution (not delivered over any MBS reference point) | MBSF | Yes | |
| Service Announcement mode `VIA_MBS_DISTRIBUTION_SESSION` — MBSF's own broadcast announcement carousel, delivered **over MBS-4-MC** (multicast/broadcast) on a fixed, configurable SSM address/port | MBSF generates + MBSTF transmits; MBSF Client receives | Yes | |
| Service Announcement mode `VIA_MBS_5` — unicast retrieval by the client **over MBS-5** | — | No | no standardized MBS-5 network API exists (no `3gpp-mbs-user-service-discovery` resource path per TS 26.517 §9.2.2). The client instead retrieves announcements from MBSF's own vendor-specific `/x-5gmag-service-announcements/v1/...` endpoint over unicast HTTP, which filters only by service-class, not by conformance profile |
| User Service Description bundle, `multipart/related` (TS 26.517 §5.3.1A): `UserServiceDescriptions` document plus one SDP per Distribution Session | MBSF generates; MBSF Client decomposes and parses | Yes | including document version ordering (§5.2.2) and relative Content-Location resolution (RFC 2557); whether the release branch's quoted-string Content-Location encoding is itself the grammar RFC 2557 requires is an unresolved dispute between two prior reviews, not adjudicated here. Separately, RFC 2557 §4.4.1's requirement to MIME-encode illegal characters in a Content-Location path is not implemented on either branch — only RFC 822 backslash-escaping of quotes/backslashes is done |
| `ServiceScheduleDescription` activation time windows (§5.2.7) | MBSF Client | Yes | |
| Cancelled MBS User Service Session handling (table 5.2.7-1: "The MBS Client shall not attempt to join an MBS User Service Session that is marked as cancelled") | MBSF Client | No | the release branch's `ServiceScheduleDescription` type has no `cancelled` field at all, and its own code comment asserts there is no such property on this data type — directly contradicting the clause quoted above. The schedule-window gate never checks any cancellation state |
| Session Description / SDP for FLUTE sessions (§6.2.2): `m=` FLUTE lines, `flute-tsi`, SSM `source-filter`, `mbs-servicetype`, timing | MBSF generates; MBSF Client parses | Partial | the core fields (`m=` lines, `flute-tsi`, SSM `source-filter`, `mbs-servicetype`, timing, multi-session SDPs) are correct; the generator also emits a forbidden `a=lang` media attribute (TS 26.517 §6.2.2.1 Restrictions: "The Service-language(s) per media ... shall not be used") — a fix exists only on an unreleased branch |
| Object distribution method over FLUTE, per the TS 26.346 Download profile (§6.2), delivered over **MBS-4-MC** | MBSTF transmit; MBSF Client receive (both via rt-libflute) | Yes | see the [rt-libflute audit](/reference-tools/content-delivery/scope) for the transport-layer detail, including the Raptor FEC gap and other release-branch findings for that library |
| MBS-6 / MBS-7 exposure to the MBS-Aware Application | MBSF Client | Yes | as local HTTP APIs: list announced services, activate/deactivate reception, inspect the received-content store, fetch received objects at their original Content-Location paths |
| MBS-Aware Application | rt-mbs-application | Yes | dashboard: announced services with play/deactivate, received-object cache, decomposed announcement bundle. Known release-branch gap: the Play link and distribution-method label only ever read the service's first Distribution Session (index 0); a service whose playable entry lives on another session renders as unplayable — a fix exists only on an unreleased branch |
| MBS-4-UC (unicast object repair) | — | No | no unicast repair path; also outside TS 29.581's own scope |
| File repair / reception reporting (associated delivery procedures) | — | No |
TS 29.581MBSTF distribution session services at Nmb28/14
| Feature | Status | Notes |
|---|---|---|
| Create Distribution Session (POST `/dist-sessions`) | Yes | including the SINGLE+PUSH validation rule (TS 29.581 table 6.1.6.2.5-1 NOTE 6): a session carrying both `objAcquisitionIdsPull`/`objAcquisitionIdPush` and PUSH+SINGLE is correctly rejected |
| Retrieve Distribution Session (GET `.../{distSessionRef}`) | No | TS 29.581 table 6.1.3.3.3.3-3 requires the response body to be the `DistSession` resource directly; on the release branch the response always wraps it inside an extra `CreateRspData`/`distSession` layer — one level of nesting more than the clause defines. A fix exists only on an unreleased branch |
| Update Distribution Session (PATCH, RFC 6902 JSON Patch) | No | TS 29.581 §5.2.2.3/§6.1.3.3.3.1 define the PATCH target as the flat `DistSession` resource, but the release branch builds JSON-Patch paths prefixed `/distSession` (whole-document) or `/distSession/distSessionState` (state-only) — pointers that don't resolve against that resource — and the response is always parsed as a `CreateRspData`, not the flat `DistSession` the clause defines. State-change (activate/deactivate) and reconfiguration PATCH requests go out with the wrong pointer shape and their responses are mis-parsed. Fixes exist only on an unreleased branch |
| Destroy Distribution Session (DELETE) | Yes | |
| StatusSubscribe / StatusUnsubscribe (`.../subscriptions`) | Yes | create, update, delete; includes the Rel-18 `DATA_INGEST_SESSION_ESTABLISHED`/`TERMINATED` event pair |
| StatusNotify (events to the MBSF callback) | Yes | failed notifications retried, not dropped |
| Object distribution method: `SINGLE` operating mode, pull and push acquisition (per-session push-ingest endpoint advertised as `objIngestBaseUrl`) | Yes | |
| Object distribution method: `STREAMING` operating mode (MPEG-DASH MPD, live profile, pull and push) | Partial | the manifest is fetched and objects are distributed, but TS 26.517 §6.2.3.5's per-object timing requirements are not implemented on the release branch: no availability-start/end-time fields exist on the object store, packaged items carry no transmission deadline so the deadline-ordered queue is inert, and the packager only ever holds one object in flight, so every FDT Instance describes exactly one object rather than the full pending object list. Fixes exist only on an unreleased branch |
| Object distribution method: `CAROUSEL` operating mode (`application/3gpp-mbs-object-manifest+json`; runs the Service Announcement channel) | Yes | |
| Object distribution method: `COLLECTION` operating mode | No | |
| Streaming manifest types other than MPEG-DASH MPD (e.g. HLS) | No | delivered as plain objects, not parsed for scheduling |
| Packet distribution method: `PACKET_FORWARD_ONLY` and `PACKET_PROXY` operating modes | Yes | |
| FLUTE/ALC delivery towards the MB-UPF at Nmb9 (unicast UDP tunnel to the MB-SMF-assigned ingress address, path-MTU detection) | Yes | |
| AL-FEC beyond Compact No-Code (Raptor, mandatory for download receivers per TS 26.346 §7.2.2) | No | in the transmission path (available in rt-libflute; not yet wired in) |
TS 29.532MB-SMF session management services at Nmb12/6
| Feature | Status | Notes |
|---|---|---|
| Nmbsmf_TMGI: Allocate (including refresh of previously allocated TMGIs) | Partial | the basic allocate/refresh path (200 OK, 400/404 for malformed or unknown TMGI) is correct; when the TMGI pool is exhausted, the release branch returns 500 Internal Server Error with a cause value that TS 29.532 table 6.1.3.2.3.1-3 does not define for this operation (the table defines only 200/403/404/307/308) — a fix exists only on an unreleased branch |
| Nmbsmf_TMGI: Deallocate (specific list or all) | Partial | the basic operation is correct (400 on a missing list, 404 on an unknown TMGI, 204 on success); but there is no check anywhere preventing deallocation of a TMGI referenced by a live MBS session — any found TMGI is deallocated unconditionally. Protection for an in-use TMGI exists only on an unreleased branch (and even there, uses a cause value the table does not define) |
| Nmbsmf_MBSSession: Create (broadcast service type) | Partial | session creation itself works, and the session-type dispatch foundation (TMGI vs SSM by service_type) is present; but the resulting Namf_MBSBroadcast_ContextCreate call to the AMF is not gated on service_type==BROADCAST as TS 23.247 §7.3.1 step 2 requires ("...if the service type is broadcast service") — it fires unconditionally, including for Multicast sessions. A fix exists only on an unreleased branch |
| Nmbsmf_MBSSession: Update (§5.3.2.3, activity status) | Yes | the activityStatus PATCH path correctly checks service_type=='MULTICAST'. A separate mbsSecurityContext PATCH path is unconditionally rejected for every session type regardless of service_type (cited against TS 29.532 §5.3.2.3.1 per the lead register, not independently re-verified this pass) — flagged for awareness rather than asserted as a confirmed defect |
| Nmbsmf_MBSSession: Release | Yes | |
| Nmbsmf_MBSSession: StatusSubscribe / StatusNotify | No |
TS 29.518Namf_MBSBroadcast0/4
| Feature | Status | Notes |
|---|---|---|
| ContextCreate (§5.6.2.2) — drives NGAP Broadcast Session Setup towards the gNB | Partial | on the release branch, the AMF sends BroadcastSessionSetupRequest to every connected gNB and immediately returns 201 Created with no wait for any gNB response, no timer, and no maxResponseTime handling — confirmed by the code's own TODO comments ("Start timer to wait for reception?", "On the first gNB response, send the 201 Created..."). Several fields are also hardcoded rather than derived (notify_uri, S-NSSAI, TAC), each marked TODO in source. A fix with real completion tracking exists only on an unreleased branch |
| ContextUpdate (broadcast session modification) | No | |
| ContextRelease — drives NGAP Broadcast Session Release | No | no DELETE handler exists on the release branch for this resource at all — any HTTP method other than POST returns 403 Forbidden, and no NGAP Broadcast Session Release request builder exists anywhere in the tree. This entire operation exists only on an unreleased branch |
| ContextStatusNotify | No |
TS 29.244N4mb PFCP1/7
| Feature | Status | Notes |
|---|---|---|
| PFCP Session Establishment, with the Release-17 MBS IEs | Yes | |
| PFCP Session Deletion for an MBS session | No | the release branch has no MBS-aware deletion path at all: session lookup is a blind hash-get with no MBS branching, and the deletion request routes unconditionally to the generic (non-MBS) deletion handler. This is confirmed, in practice, to cause MBS session-pool exhaustion under real use. A fix exists only on an unreleased branch |
| PFCP Session Modification (Multicast MBS session Activate/Deactivate) | No | no modification or report handling exists for MBS sessions on the release branch; only Establishment is implemented |
| Local Ingress Tunnel (§8.2.209; the Nmb9 ingest address returned to the MBSF) | Partial | the tunnel address/port are returned, but the wire-encoded length field is wrong: the correctly-computed address-family-specific length is computed and then discarded in favour of the full union size, padding the IPv4 encoding with trailing zero octets against §8.2.209's requirement of flags+port+address only. A fix exists only on an unreleased branch |
| Common TEID / FSSM shared-delivery forwarding behaviour (§8.2.207, §5.34.2.2) | Partial | correct for the single-PDR-per-session case the SMF side always creates today; the TEID assignment is hard-indexed to only the first created PDR/FAR rather than looped across all of them, so it would be wrong the moment more than one PDR/FAR exists per session. Currently latent, not currently observable; a fix exists only on an unreleased branch |
| MBS downlink GTP-U PDU Session Container (mandatory extension header, TS 38.415) on every N3mb downlink G-PDU | No | critical: on the release branch, QER/QFI is never associated with the MBS downlink PDR (the code carries the comment "For now QER is not being used"), so the UPF's own guard for adding the mandatory GTP-U PDU Session Container extension header never fires. In practice this causes a real gNB to reject every downlink G-PDU ("Incomplete PDU at NG-U interface: missing or invalid PDU session container"). A fix exists only on an unreleased branch — this breaks the N3mb hop of the delivery chain end-to-end on the release branch today |
| PFCP Session Report for MBS sessions | No |
TS 38.413NGAP broadcast procedures0/5
| Feature | Status | Notes |
|---|---|---|
| Broadcast Session Setup (Request/Response, with the MBS Session Setup Request Transfer carrying TMGI and shared-delivery tunnel information) | Partial | the success path is built and sent correctly, dynamically, with no pre-provisioned session configuration required; but on the release branch, three error paths (a malformed request, a duplicate session, or a CU-CP session-creation failure) simply log a warning and return, sending no NGAP message — success or failure — at all |
| Broadcast Session Release | No | no release procedure exists at any layer on the release branch: no NGAP interface method, no F1AP or E1AP release messages, and the DU-internal MAC teardown is an explicit unimplemented stub ("TODO ... implement this", the real call is commented out). This entire chain exists only on an unreleased branch |
| Broadcast Session Modification | No | |
| Broadcast Session Release Required (gNB-initiated) | No | |
| Distribution Setup/Release, Multicast Session Activation/Deactivation/Update, Multicast Group Paging | No | multicast mode |
TS 37.483 / TS 38.473E1AP and F1AP broadcast contexts1/8
| Feature | Status | Notes |
|---|---|---|
| E1AP BC Bearer Context Setup (with failure reporting) | Partial | session setup succeeds; the failure-reporting function exists with a real body but is never called anywhere in the coroutine, so per-MRB/per-QoS-flow failures are folded into the success response instead of a proper failure indication |
| E1AP BC Bearer Context Modification (per-MRB F1-U tunnel information, gNB-CU-CP initiated) | Yes | |
| E1AP BC Bearer Context Modification Required / Release Request (gNB-CU-UP initiated) | No | absent on both peers (TS 37.483 cl.8.6.1.3.2/8.6.1.5.2) |
| E1AP BC Bearer Context Release | No | no BC Bearer Context Release files exist anywhere in the tree on the release branch, at CU-CP or CU-UP; this exists only on an unreleased branch |
| F1AP Broadcast Context Setup (with per-MRB setup-failure reporting) | Partial | setup succeeds on the happy path; the failure-response builder is an entirely commented-out empty function called from 5 sites that therefore do nothing on failure, and the Broadcast MRB Failed-To-Be-Setup-List assignment is commented out and never populated. A fix exists only on an unreleased branch |
| F1AP Broadcast Context Release | No | no F1AP broadcast-context-release files exist anywhere in the tree on the release branch; this exists only on an unreleased branch |
| F1AP Broadcast Context Modification | No | not implemented on either the DU or CU-CP side (TS 38.473 cl.8.14.4.2/8.14.4.3) |
| E1AP MC Bearer Context / F1AP multicast procedures | No | multicast mode |
TS 38.331 / TS 38.321 / TS 38.322 / TS 38.323Uu broadcast radio protocols4/16
| Feature | gNB (transmit) | UE (receive) | Notes |
|---|---|---|---|
| SIB20 (MCCH configuration, TS 38.331) | No | No | critical: neither release branch implements this at all. gNB: no MCCH scheduler file exists anywhere in the tree, and the system-information packer has no SIB20/SIB21 packing function. UE: the RRC header carries a literal TODO ("add handle functions for sib20 and sib21") and there is no `handle_sib20`/`handle_mcch` anywhere. Without this, a UE cannot discover a broadcast MBS session over the air on either release branch; the mechanism exists only on an unreleased branch |
| MCCH: MBSBroadcastConfiguration-r17 covering every live session's MRBs, transmission windows | No | No | the MCCH mechanism itself is absent on both release branches (see SIB20 row above), so this cannot function regardless of any downstream code; exists only on an unreleased branch |
| MCCH change notification (DCI 4-0) | No | N/A | moot on the release branch given MCCH itself does not exist there (see above); recorded here for continuity with the underlying clause (TS 38.331 §5.9.1.3) |
| MTCH scheduling / reception per session G-RNTI, concurrent sessions independently served | No | No | gNB: scheduler files for MBS sessions exist and are not stubs (MCS/PRB computation, buffer-state tracking), but the MTCH transport-PDU assembler needed to actually build a real MTCH payload does not exist anywhere in the tree, so real over-the-air content delivery cannot function regardless of the scheduler's internal state. UE: the receive-side RNTI is a hardcoded value per the code's own comment ("Harcoded RNTI intended for MBS broadcast reception"), and there is no G-RNTI-aware code anywhere — multi-session concurrent reception does not exist. Both exist only on an unreleased branch |
| MRB LCID management | Yes | Yes | gNB (transmit): DU-wide unique LCIDs across concurrent sessions; UE (receive): all MRBs of all advertised sessions wired. This presupposes MCCH-driven session discovery to reach the UE, which is confirmed absent on the release branch (see the SIB20/MCCH rows above) — the LCID logic itself was not found to be at fault, but end-to-end it cannot be exercised without a working MCCH |
| RLC-UM (TS 38.322) | Yes | No | UE (receive): RX_Next_Highest is never bootstrapped from the first received segmented MCCH/MTCH PDU's SN (cl.7.1); affects joining mid-session when segmented SNs land in the upper half of the SN space |
| PDCP broadcast MRB (TS 38.323; 18-bit SN) | Yes | No | UE (receive): no MRB/broadcast-specific code exists in the UE PDCP entity on the release branch at all (zero related hits) — a stronger gap than a missing receive-window bootstrap alone. Broadcast MRB PDCP reception exists only on an unreleased branch |
| Delivery of received multicast IP to the MBSF Client | N/A | No | UE (receive): this presupposes working broadcast MRB PDCP reception, which is confirmed absent above; on the release branch, delivery over software TUN radio links most likely depends on the raw-capture relay path noted in the User plane path table below rather than genuine over-the-air RRC/PDCP delivery |
| Multicast MRBs, PTP/PTM switching, MBS Interest Indication, group paging | No | No |
User plane path
| Segment | Between | Status |
|---|---|---|
| Nmb8 object ingest (pull or push) | MBS Application Provider → MBSTF | Implemented |
| Nmb9 FLUTE/ALC unicast tunnel | MBSTF → MB-UPF | Implemented |
| N6mb direct multicast ingest (alternative to the MBSTF path) | AF/AS → MB-UPF | Implemented |
| N3mb shared GTP-U delivery, with the mandatory PDU Session Container extension header (TS 38.415) on every downlink G-PDU | MB-UPF → gNB(s) | Not implemented |
| Uu PTM broadcast (MCCH/MTCH) | gNB → UEs | Not implemented |
| MBS-4-MC FLUTE reception (including a raw-capture relay for software TUN radio links) | UE → MBSF Client | Implemented |
The two rows marked Not implemented are release-branch findings, not design gaps: the MB-UPF's downlink PDR never gets a QER/QFI association, so it never emits the mandatory PDU Session Container extension header a real gNB requires (TS 38.415); and neither the srsRAN Project (gNB) nor srsRAN 4G (UE) release branch implements MCCH/SIB20, so a UE has no standards-compliant way to discover a broadcast session over the air. Fixes for both exist only on unreleased development branches. The FLUTE reception row still holds because the MBSF Client's object-level FLUTE handling is independent of these two gaps and was confirmed to build and instantiate correctly on its own release branch.
Out of scope today (all components)
- MBS Multicast delivery mode (TS 23.247): multicast session join via the SMF, PTP/PTM switching, group paging — see the caution above.
- MB-PCF policy control (TS 29.537), NEF exposure (TS 29.522 / Nmb5), MBS security (TS 33.501 traffic keys — delivery is unprotected), charging (TS 32.279).
- MBS-specific NRF NFDiscovery query extensions (TS 29.510) — standard NF registration/discovery is used; discovery by TMGI or MBS-session parameters is not.
- Location-dependent (multi-area) MBS sessions — only partial plumbing exists (for example, MBSF recognises
locationDependentto gate a TMGI request), with no Area Session ID support or per-area distribution — and Xn mobility / service continuity.
Getting Started
To try the tools hands-on, follow the Tutorials: they cover the two ways to provision the 5GC (direct MBS core functions, or via the 5GC Service Consumers libraries), the Docker-Compose deployment, and the individual MBSF/MBSTF walkthroughs. For the source code, packages and releases behind each component, see Resources; for the specification background, see Standards: 5G Multicast Broadcast Services.
Roadmap
This page tracks the roadmap for the 5G Multicast Broadcast Services (5MBS) reference tools. The work is organised into two workstreams that build on each other: first the 5G Core (5GC) functions (MB-SMF, MB-UPF, AMF and basic multicast support), then the MBS User Services layer (MBSF, MBSTF and the MBS Application Function/Application Server) that runs on top of them.
General Project Roadmap
The Kanban board below tracks the planned and in-progress work for the 5G Multicast Broadcast Services (5MBS) reference tools (5G Core multicast functions and the MBS User Services layer). It is maintained live on GitHub.
Developer Kanban Boards
5MBS: 5G Core functions
Initial implementation of MB-SMF, MB-UPF, AMF and basic multicast support in the 5G Core
5MBS: MBS User Services
Initial implementation of MBSF, MBSTF, MBS AF and MBS AS for supporting media multicast/broadcast. This builds on top of the 5G Core functions indicated above.
Related
- Resources
- Tutorials
- Standards: 5G Multicast Broadcast Services — the full specification list for this topic
- Standards: Content Delivery Protocols — the FLUTE transport under the Object distribution method, and why it is FLUTE version 1
- Tech: Multicast and Broadcast Services in 5G Networks — the three-layer architecture (user service, 5G Core, NG-RAN) and the reference points the tools implement
- Implementation Blueprints: MBS Broadcast RAN acquisition, MBS Multicast RRC_INACTIVE RAN acquisition, MBS Multicast mobility, and MBS Service Layer provisioning-to-announcement — the step-by-step procedures this tool implements
- Applications: MBS End-to-End Delivery Demo — a real, assembled scenario built on this tool
- Tech: Non-Terrestrial Networks — deploying MBS over satellite access, with the MBS Multicast over NTN and MBS Broadcast over NTN analyses