5G NR MBS MAC
5G NR MBS MAC is the MAC-layer view of multicast and broadcast delivery over NR. It stays within the same MAC framework as ordinary downlink operation, but it changes how MTCH traffic, PDCCH monitoring, DRX, HARQ handling, retransmission context, and service continuity should be read.
This page explains where MBS fits in the NR MAC picture, how broadcast and multicast traffic are carried, how MBS DRX changes monitoring behavior, how MBS SPS changes assignment handling, and which identifiers and procedures matter most when reading traces or decodes. Use it together with 5G NR MAC Overview, DRX, and the related MBS RRC configuration pages.
| Technology | 5G NR MBS |
|---|---|
| Protocol area | MAC downlink multicast and broadcast behaviour |
| Main specification | 3GPP TS 38.321 |
| Architecture context | 3GPP TS 38.300 and 3GPP TS 38.331 |
| Release baseline | Release 18 |
| Main logical channel | MTCH with multicast and broadcast control context |
| Main transport channel | DL-SCH carrying MBS PTM transmissions |
| Key context | G-RNTI, G-CS-RNTI, MBS DRX, MBS SPS, multicast HARQ and retransmission handling |
Definition and purpose
MBS MAC covers the MAC-side behaviour used for NR multicast and broadcast service delivery. Instead of treating traffic only as per-UE dedicated downlink data, MBS MAC handles point-to-multipoint traffic delivery, related monitoring rules, MAC PDU reception, retransmission context, and service continuity for multicast and broadcast use cases.
The important difference is that MBS traffic is not read only through the usual unicast scheduler model. The service may be broadcast or multicast, the PDCCH monitoring path may use MBS-specific identifiers, and DRX or retransmission interpretation can differ from ordinary dedicated downlink reading.
Where MBS MAC fits
| Layer or context | Relation to MBS MAC |
|---|---|
| RRC | Configures MBS reception, DRX, scheduling context, MBS SPS, and service-related MAC behaviour. |
| MAC | Handles downlink assignment interpretation, MBS monitoring state, HARQ-related behaviour, and disassembly of received MAC PDUs for multicast or broadcast traffic. |
| PHY | Carries the actual PDCCH and PDSCH reception used for MBS transmission and feedback-related timing. |
| Service layer context | Defines whether the delivery is broadcast or multicast and how continuity should be interpreted at the receiver side. |
Channels and identifiers
At MAC level, MBS traffic is mainly tied to MTCH carried on DL-SCH. The traffic is still received as MAC PDUs and parsed through the ordinary downlink MAC mechanisms, but the assignment and monitoring context changes because MBS uses point-to-multipoint identifiers and service scheduling rules.
The most important identifiers to keep visible are the identifiers used for broadcast or multicast scheduling and activation. Those identifiers shape whether a transmission is read as broadcast PTM, multicast PTM, configured scheduling, or retransmission support for an earlier PTM transmission. Use MBS identifiers for the dedicated identifier view.
| Item | Role in MBS MAC | Why it matters |
|---|---|---|
| MTCH | Carries multicast or broadcast traffic content | It is the logical channel most directly associated with MBS payload delivery. |
| DL-SCH | Transport channel used for MBS traffic delivery | MBS traffic is still carried in MAC PDUs over the downlink shared channel. |
| G-RNTI | Broadcast PTM scheduling and monitoring context | It is central when reading MBS broadcast assignment and broadcast DRX. |
| G-CS-RNTI | Configured scheduled multicast transmission context | It is central for activation, deactivation, and retransmission in multicast MBS SPS. |
| CS-RNTI | Used in configured scheduling and point-to-point retransmission support for initial PTM transmission | It helps explain how multicast retransmission support can appear in traces. |
Broadcast and multicast MAC view
Broadcast and multicast share the same broad MBS MAC family, but the identifier path, DRX reading, and retransmission interpretation are not identical. Use broadcast and multicast MAC behaviour for the dedicated comparison page.
| Aspect | MBS broadcast | MBS multicast |
|---|---|---|
| Delivery scope | Point-to-multipoint broadcast service delivery | Point-to-multipoint multicast delivery with multicast-specific scheduling context |
| Main identifier view | G-RNTI is the main scheduling reference | G-RNTI and G-CS-RNTI become important depending on configured scheduling and feedback context |
| DRX behaviour | Broadcast DRX can control PDCCH monitoring per G-RNTI | Multicast DRX can control monitoring per G-RNTI or G-CS-RNTI |
| Retransmission reading | Read against broadcast scheduling and HARQ process handling for received TBs | May include multicast HARQ feedback and retransmission context, including configured multicast assignments |
MBS DRX
MBS has its own DRX reading at MAC level. Broadcast DRX controls PDCCH monitoring activity per G-RNTI, while multicast DRX can be configured per G-RNTI or per G-CS-RNTI. This DRX operation is separate from ordinary unicast DRX, even though the same general idea of active time and monitoring windows still applies.
That means an apparently missing MBS transmission or delayed service visibility may be explained first by the MBS monitoring state. Broadcast DRX and multicast DRX are among the most important first checks before calling an MBS delivery problem a scheduler or radio problem.
| MBS DRX area | What to read |
|---|---|
| Broadcast DRX | Check whether the UE is in active time for the relevant G-RNTI before expecting PDCCH monitoring and broadcast reception. |
| Multicast DRX | Check whether the UE is in active time for the relevant G-RNTI or G-CS-RNTI and whether multicast HARQ timing is active. |
| Interaction with ordinary DRX | Do not assume ordinary unicast DRX explains MBS visibility. MBS DRX may be operating independently. |
MBS Semi-Persistent Scheduling
MBS Semi-Persistent Scheduling adds a configured downlink assignment model for multicast delivery. In this mode, a downlink assignment is provided by PDCCH and stored or cleared through activation or deactivation signalling, and multiple assignments can be active in the same BWP.
The practical reading point is that MBS SPS changes the simple “new DCI means new ordinary downlink event” assumption. Once configured, the receiver has to track the configured assignment lifecycle, periodicity, HARQ process context, and activation or deactivation state.
| MBS SPS item | Meaning |
|---|---|
| Activation and deactivation | The configured multicast assignment is created or cleared through signalling rather than treated as a one-off assignment only. |
| Periodicity | The downlink assignment repeats according to the configured timing pattern. |
| HARQ process context | Configured HARQ process numbering and offsets matter for reception and retransmission handling. |
| Serving cell and BWP scope | MBS SPS is configured on one serving cell per BWP. |
HARQ and retransmission context
MBS MAC still uses HARQ process handling on the downlink side, but the reading changes because the traffic is multicast or broadcast and the retransmission path may include multicast-specific feedback or configured-assignment reuse. In multicast cases, retransmission context may involve G-CS-RNTI or CS-RNTI depending on the scheduling and retransmission mode.
When a transport block is received for broadcast MTCH or multicast MCCH or MTCH, the MAC entity still allocates the TB and associated HARQ information to a HARQ process. That means MBS traces still need HARQ reading, but the process must be interpreted in point-to-multipoint service context rather than as a normal per-UE downlink retransmission only.
MAC PDU reading for MBS
MBS traffic is still received as a MAC PDU, so the downlink MAC PDU and disassembly rules still matter. The difference is the service context around the PDU: which MBS identifier addressed it, which MTCH schedule applied, whether the transmission was part of configured multicast assignment, and whether DRX or retransmission timers were active.
Use the MAC PDU Format page when the packet structure is the main question, then return here to interpret why that PDU appeared under MBS delivery rather than ordinary dedicated downlink.
Reading notes
- Start with the service type: broadcast or multicast.
- Keep G-RNTI, G-CS-RNTI, and CS-RNTI context visible while reading assignments and retransmissions.
- Check whether MBS DRX, not ordinary unicast DRX, explains missing monitoring or delayed service visibility.
- Read configured multicast assignments differently from one-off dynamic downlink events.
- Correlate MTCH scheduling, HARQ process handling, and service continuity before calling it a payload loss problem.
Troubleshooting
| Symptom | MBS MAC area to inspect | Why |
|---|---|---|
| Expected service does not appear | MBS DRX state, G-RNTI or G-CS-RNTI monitoring context, and service schedule | The UE may not have been in active monitoring state for the relevant MBS transmission. |
| MBS traffic looks sparse or periodic | Configured assignment periodicity and DRX timing | That pattern may be expected under MBS SPS or MBS DRX rather than a failure. |
| Retransmission behaviour is unclear | HARQ process context and multicast retransmission mode | MBS retransmission handling does not look exactly like ordinary dedicated downlink. |
| Trace looks like ordinary DL-SCH but service continuity is wrong | MTCH schedule, service type, and MBS identifier context | The transport channel is familiar, but the service model is different. |
| Broadcast works but multicast looks unstable | Multicast DRX, G-CS-RNTI handling, feedback configuration, and configured multicast assignment state | Multicast adds more identifier and retransmission context than pure broadcast. |
References
- ETSI TS 138 321 V18.2.0 / 3GPP TS 38.321 Release 18 - MBS DRX, MBS SPS, MTCH handling, multicast and broadcast reception, and related MAC behaviour.
- ETSI TS 138 300 / 3GPP TS 38.300 - NR and NG-RAN architecture context for MBS.
- ETSI TS 138 331 / 3GPP TS 38.331 - RRC configuration context for MBS broadcast and multicast.
- ETSI TS 138 213 / 3GPP TS 38.213 - control-channel and HARQ feedback timing context used by MBS monitoring and retransmission handling.
- ETSI TS 138 214 / 3GPP TS 38.214 - downlink data procedure context for MBS transport and scheduling behaviour.
FAQ
What is 5G NR MBS MAC?
It is the MAC-side behaviour used for multicast and broadcast service delivery in NR, including MTCH reception, monitoring, DRX, assignment handling, and retransmission context.
How is MBS MAC different from ordinary downlink MAC?
It still uses the downlink MAC framework, but the service model, identifiers, DRX behaviour, and retransmission interpretation are different because the traffic is multicast or broadcast rather than ordinary unicast only.
Which channel matters most in MBS MAC?
MTCH is the main logical channel to keep in view, carried on DL-SCH for MBS traffic delivery.
What identifiers matter most in MBS MAC?
G-RNTI is central for broadcast PTM, while G-CS-RNTI and sometimes CS-RNTI matter in configured multicast scheduling and retransmission context.
Why is MBS DRX important?
Because missing service visibility can be caused by MBS-specific monitoring state rather than by a radio failure or missing traffic.
Why does MBS MAC need its own page?
Because multicast and broadcast delivery change how monitoring, assignment handling, service continuity, and retransmission behaviour should be interpreted at MAC level.